Principle of Not Knowing

Forestil dig at informationssikkerhed er nyt for dig, og at du lige er begyndt at lære om det. Du vil sikkert lære om ting som kryptering, certifikater, adgang, Principle of Least Privilege, og måske noget om GDPR, HIPAA og andre regler. Alt sammen gode emner, men der er noget det kan være du kun kommer perifert omkring, som ikke bliver nævnt eksplicit. Noget som du har brug for at vide. Jeg kalder det Principle of Not Knowing (Princippet om Nul Kendskab).

Dette princip bør, efter min mening, stå øverst på enhver informationssikkerheds liste. Det burde være noget af det første man lærer om informationssikkerhed.

Hvordan skal det forstås?

Når Frederik køber en plæneklipper i Superhave webshoppen, er webshop systemet nødt til at indsamle og gemme blandt andet Frederiks navn, hans postadresse og plæneklipper modellen. Det er umuligt at levere plæneklipperen til Frederik, hvis webshoppen ikke har de tre datapunkter.

På den anden side er webshoppen ikke nødt til at kende Frederiks køn. Så det er et datapunkt den ikke bør indsamle.

Når Frederik handler, bruger webshop systemet skærmstørrelsen på hans enhed, for at vise ham de bedst mulige billeder af plæneklipperen. Når Frederik har afsendt sin ordre, er datapunktet skærmstørrelse ikke længere nødvendigt. Derfor bør systemet ikke gemme det.

Frederik er en tilfreds Superhave kunde. Han købte sin kompostkværn hos dem for tre år siden. Pengene gik igennem, kompostkværnen blev leveret og garantien udløb for et år siden. Det er ikke længere nødvendigt for Suprhave at gemme hans faktura. Så de bør slette den fra deres systemer.

I en gammel udgave af Superhave webshoppen, skulle kunderne taste deres betalingskort oplysninger ind på webshop ordresiden. Superhave indså at det af mange grunde var et dårligt design, ikke mindst fordi de indsamlede flere oplysninger end de behøvede. De ændrede det til at blive håndteret af en ekstern betalingsudbyder istedet, så nu indsamler de ikke længere kortoplysninger.

Dengang frontend teamet startede i Superhave, efterspurgte de alle mulige data om kundernes enheder. Blandt andet skærmstørrelse. Bare at begynde at gemme den ved hver lejlighed, ville give for meget information. Teamet havde ikke brug for at kende hver enkelt kundes og besøgendes skærmstørrelse. Det ville give flere detaljer end nødvendigt. Efter at have diskuteret deres behov, blev skærmstørrelser istedet talt sammen og gemt som et dagligt spektrum af skærmstørrelser.

Hvad der er meget værre er at Superhave nu har oprettet en marketingafdeling. De har efterspurgt alt det information det overhovedet er muligt at trække ud om kunderne. Det strider jo med PoNK princippet, men der er forskellige måder at angribe det på.

Først bør marketing have noget modspil. Er det virkelig nødvendigt for dem at kende ethvert datapunkt som det er muligt at indsamle? På en meget idealiseret kommerciel måde, kunne Superhave sætte en pris på datapunkterne, og så lave regnestykket. Kan marketing forventes at hive nok hjem til at retfærdiggøre at hvert eneste af datapunkterne indsamles og gemmes? I en mere realistisk verden, bør marketing give gode argumenter for hvert datapunkt de ønsker.

For det andet kunne man sammenregne de data som marketing ønsker, ligesom med skærmstørrelserne. Eller de kunne gemmes i en anden form der giver færre detaljer og umuliggør tracing.

Sidst er det sådan at ikke alle datapunkter er lige. Brug noget risk-analyse for at finde ud af hvilke datapunkter der har en høj risiko og hvilke der har en lav. Det er selvfølgelig bedst hvis højrisiko datapunkter kan undgås. Det er stadig godt at undgå lavrisiko datapunkter, men det er ikke noget man behøver gøre så meget ud af.

Forbedringer

Lad os forestille os du lavede et PoNK projekt for Superhave webshoppen, og var istand til at skære 20% af alle data væk. Det ville være en forbedring på mere end én måde.

1. Sikkerheden ville blive simplere. De data der ikke længere er der, behøver ikke blive vurderet, kortlagt, håndteret eller overhovedet tænkt på. Spørgsmål som "Hvem har adgang til de data?" eller "Hvordan tager vi bedst backup af de data?" ville være irrelevante nu.
2. Sikkerheden ville blive bedre. Simpelthen fordi der ville være færre data som kunne misbruges eller lækkes. Den del af webshop koden der håndterede de bortskårne data, kan fjernes, og derved undgås udnyttelse af de bugs den sikkert indeholdt.
3. Belastningen af systemet ville blive lavere. Der ville være mindre netværkstrafik, færre CPU cykler og færre storage operationer.