In these days of mass storage of data on clouds, muddied RGPD waters [ref] and regular massive data theft [ref], it has become – morally and legally – mandatory for companies to take steps to protect some or all of their data from unwanted access. This often turns into company directives or technical specifications that require that “data shall be encrypted”.
Security is a state in which your assets are protected from threats from attackers. Protection is a means to ensure security. For those who have dabbled in systems engineering, this is the security equivalent of needs versus solution[ref]. Specifying the protection without specifying the security is unconstructive because it often does not help the solution designer to come up with an effective protection scheme. “There, data shall be encrypted,” says the specifier before going home with the feeling of a job well done. Then comes the security architect with questions. “Encrypt? That’s easy. Who needs to have access to the key?”
By specifying the solution, the actual expression of needs has been left aside. In the end, encryption is nothing more than an access control mechanism, which allows the architect to work on the protection of small amounts of data – the keys – instead of protecting the data itself. The actual security questions are: what data do I need to protect? Who from? Who needs to have access to it? How long does the data need to be protected for? Specifying the solution lets us feel satisfied that the data will be secure, but we have answered none of the hard questions, and we cannot design an appropriate system without an answer to these questions.
We see this all the time. “The data shall be encrypted”. The data is stored on an AWS cloud, which we know is encrypted by Amazon. That means Amazon can (possibly) access our data. Is that OK? The data is stored in a Software-as-a-service platform hosted on AWS, so now it’s Amazon and the SaaS admins that can access the data. Is that OK? I’m using full disk encryption on my laptop, which really only protects against disk theft: is that OK, or did you want your data to be protected in case I open a malicious e-mail attachment?
Requiring encryption is akin to requiring that your house doors “shall have locks.” Is that your actual requirement? Sure, you need to be able to lock and unlock the front door, from inside and outside. Maybe you also want the bedroom doors to have a lock, but probably it doesn’t need to be as strong. Maybe you do not want a lock on your child’s bedroom at all. You may want your toilet door to have a simple keyless lock that only operates from inside, but indicates when it’s engaged outside, and with an override from outside in case your child locks himself inside. And what about the cat flap?
Unfortunately, there is no simple way out. What needs to be specified is the result of a standard risk analysis: who interacts with the system? Who needs access to the data? Which attackers might want my data? How bad is it if my data leaks? And maybe your architect will even find a solution that is cheaper than encryption.
Cybersecurity This article goes beyond the usual industry practices, focusing on less common cybersecurity tips, to address the ‘road less travelled’ kind of strategies.
Cybersecurity What is Containerisation? Containerisation – the practice of packaging software code and dependencies into a single ‘container’– has become the backbone of modern, cloud-native app development. Used in conjunction with other technologies like microservices, serverless architectures and DevOps, containerisation enables teams to quickly build, deploy, reconfigure and scale applications to run in any computing environment. […]
Cybersecurity As we’ve seen before[*], encryption is a protection means rather than a security objective. Strong of that knowledge, we have clearly defined who should have access to our data, and who should not. Is encryption a good solution, then? Security attributes are often summed in three, sometimes four, basic properties that we may need to […]
