Defining Data Handling Requirements

We often experience a transformation lack between security requirements on the one hand and their practical implementation on the other. Often those people defining security requirements do simply not understand how to do this in a way that they are understood and implemented in a complete and thorough way.

One vital class of security requirements are those concerning data confidentiality and privacy. Many data leaks and privacy problems result in insufficient implemented data handling mechanisms. For instance, when we look at log files of productive systems they are often leaking massive kinds of sensitive data, often without knowledge of any of the stakeholder.

To reduce this risk, I discovered a while a go the need to define exact data handling requirements for all handled types of information. As a result, all stakeholders like project management, development and the information security officer of course can discuss this and agree upon it. It is vital here, that these are detailed enough so that developers understand them and are able to follow these requirements. But also abstract enough, so that all other involved parties understand them and can agree on them too.

I ended up with the following sheet structure (you can download the full example from Google Docs by clicking on the image):

The first column lists all relevant information types (in real projects you would have some dozens of them) as well as compliance requirements that might to be taken in mind for each one. Then, the following columns define the detailed data handling requirements for data at rest (persistation in log files on db or caches) and data in motion (e.g. transferred in different part of the HTTP protocol).

Each data handling requirements

• E: Data Encryption
• HTTPS: Transport Encryption
• H: Simple Hash
• SH: Salted Hash
• M: Masking (e.g. replace all but the first 4 digits of a cc number with a "x")
• -: no persistation or transportation is allowed

In addition, I introduced specific log level requirements (e.g. INFO, DEBUG, etc.). So that a developer does exactly know what he is allowed to log in what way.  This sheet turned out to be really useful in a couple of projects now. Perhaps it might help others too.