The Principle of Not Knowing Principle of Not Knowing

Imagine that you are new to information security, and have just started learning about it. You will probably be learning about things like encryption, certificates, access, Principle of Least Privilege, and perhaps something about GDPR, HIPAA and other regulations. All good topics, but there is something that you might only skirt around, that is not explicitly stated. Something that you need to know about. I call it the 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).

This principle should, in my opinion, be at the top of every information security list. It should be one of the first things you learn about information security.

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.

What does it mean?

Hvordan skal det forstås?

When Frederik buys a lawnmower in the Supergarden webshop, the webshop system needs to collect and store among other things Frederiks name, his postal address and the lawnmower model. It is impossible to deliver the lawnmower to Frederik, if the webshop doesnt have those three data points.

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.

On the other hand, the webshop has no need to know Frederiks gender. So it should not collect that data point.

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.

When Frederik does the purchase, the webshop system uses the screen size of his device, to present him with the best possible pictures of the lawnmower. When Frederik has submitted his order, the data point screen size is no longer needed. Consequently the webshop should not save it.

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 is a happy Supergarden customer. He bought his garden shredder there, three years ago. The purchase was paid, the shredder delivered and the warranty expired one year ago. There is no longer any need for Supergarden to save the invoice. So they should erase it from their systems.

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.

In an old version of the Supergarden webshop, customers had to enter their payment card information on the webshop ordering page. Supergarden realized that this was a bad design for many reasons, not least that they collected more data than they had to. They changed it to be handled by an external payment processor instead, so now they no longer collect card information.

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.

Back when the frontend developer team started in Supergarden, they requested a lot of data about the customers devices. Among these was screen size. Just starting to save it at every opportunity, would provide too much information. The team did not need to know the screen size of each individual customer and visitor. That would provide more details than necessary. After some discussions about their needs, screen size data was instead collated and saved as a daily spectrum of screen sizes.

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.

What is much worse is that Supergarden now has created a marketing department. They have asked for all the information it is possible to extract about the customers. That goes against the PoNK principle to put it mildly, but there are different ways to approach it.

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å.

First, marketing should have some pushback. Is it really necessary for them to know every single data point that can be collected? In a very idealized commercial way, Supergarden could set a price on the data points, and then do the calculations. Can marketing be expected to bring home enough to justify collecting and saving each of those points? In a more realistic world, marketing should present good reasons for each data point they want.

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.

Secondly the data points that marketing wants could be collated, like the screen size data is. Alternatively they could be saved in some other way that reduces the number of details and prevents tracing.

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.

Lastly not every data point is equal. Use some risk analysis to figure out which data points are high-risk, and which are low-risk. It is of course best when high-risk data points can be avoided. It is still good to avoid low-risk data points, but not something to get hung up on.

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.

Improvements

Forbedringer

Let us say you did a PoNK project for the Supergarden webshop, and were able to cut away 20% of the data. This would be an improvement in more than one way.

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. Security would be simplified. The data that is no longer there, does not have to be assessed, mapped, handled or really thought about. Questions like "Who has access to these data?" or "How to best back up these data?" would be irrelevant now.
2. The security would improve. Simply because there would be fewer data that could be misused or leaked. The part of the webshop code that handled the data that was cut away, can be removed, thus avoiding exploits of the bugs it probably contained.
3. Load of the system would be lower. There would be less network traffic, fewer CPU cycles and fewer storage operations.

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.