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

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.

What does it mean?

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Improvements

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.

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.