Imagine a kitchen in a fast-food restaurant. Everyone who works there knows that hand hygiene is crucial to the restaurant’s customer safety and commercial success (no one wants to eat somewhere where they risk food poisoning). But the only sink is located by the changing room outside the restaurant kitchen. During the lunch rush, the pace of the kitchen becomes crucial for colleagues at the cash register to do their jobs and to avoid angry customers. Here, the restaurant’s safety procedures come into conflict with loyalty to colleagues and with the restaurant’s business goals. Is it a knowledge problem if employees choose to ignore the procedures? Or is it a flaw in the kitchen design? Most people would answer the latter.

The same is true with security architecture. It needs to be designed so that it is as easy as possible to do the right thing. We need to be secure by design. And there are a number of well-established principles to follow.

Already in 1975, described Saltzer and Schroeder eight principles that are still central to secure system design: least privilege (Least Privilege), denied access as a default (Fail-safe defaults), simple and understandable security mechanisms (Economy of mechanism), control of every access attempt (Complete mediation), open design (Open design), division of particularly sensitive privileges (Separation of privilege), minimization of shared mechanisms (Least common mechanism) and – not least – that security must be psychologically acceptable (Psychological acceptability), i.e. work together with how people actually work. The last one is particularly important here. If security is perceived as an obstacle, it will sooner or later be circumvented.

Let's go through what the principles mean one by one:

Least Privilege

In short: No one should have access to anything they don't need. It's a simple principle that means that if you want to avoid the wrong person getting access to systems or information, you shouldn't give them rights they don't need. Avoiding unnecessarily generous permissions protects against mistakes, against attacks and against someone being suspected of acting improperly. It also makes it much easier to investigate any security flaws or attacks.

Fail-safe Defaults

It is difficult to predict everything that can go wrong, but it is all the easier to list what should be allowed. Therefore, we should also build our systems according to the principle that we list what is allowed, not what should be prohibited. In the security world, we talk about whitelisting – meaning that only what is on the list is allowed – and blacklisting – only what is included in the list is prohibited. Blacklisting means in practice that we allow everything we have forgotten or not expected. We don't want it that way.

Economy of Mechanism

This is simply about ensuring that features are built in a way that is as easy to follow as possible. Empirically, there is a direct correlation between the number of lines of code and the occurrence of bugs, and we know that complexity opens up vulnerabilities. By avoiding cumbersome processes and being economical in our use of code, we create the conditions for secure systems. And in practical terms: How many lines of code do you actually want to review?

Complete Mediation 

This means that every attempt to access each object should be checked based on authorization. This is especially important when we integrate different systems with each other or in the world we live in today where much (or all) of our data worth protecting is located in various cloud services. If controls can be bypassed or if I can get things done in someone else's name, we create potential problems.

Open Design

A good system design doesn't have to be secret. It's secure anyway. We simply shouldn't have to rely on hackers' ignorance to protect us. Instead, it's keys and passwords that we should protect. Having an open design with known algorithms also means that we can have higher trust in the systems when we know that it's not just up to us to test the systems, as developers and manufacturers can share information with each other about any flaws. 

Separation of Privileges 

Anyone who has seen enough Hollywood thrillers has seen how sensitive processes, such as the firing of nuclear weapons, require two separate keys to initiate. The same applies to particularly sensitive operations in our systems. To increase robustness, we should therefore ensure that no one can perform such operations on their own. However, here we should be careful about what kind of measures we consider to be so sensitive and worthy of protection, since this is something that naturally conflicts with accessibility. If we had placed the sink in our restaurant example above behind double locks, both keys would soon be hanging on a hook outside the door.

Least Common Mechanism

The principle of least commonality states that we should limit the number of functions or resources in a system that are shared by multiple users. This means that we should isolate users and processes from each other as much as possible to prevent unintended interactions and security breaches. It also helps us reduce the risk of domino effects if one user is exposed to an attack or malware.

Psychological Acceptability

Here we have our restaurant example again, which is the principle against which we must weigh all the other principles. If we build systems that are foolproof but that in practice prevent users from doing their jobs, they will soon look for shortcuts to get around it. That's when we risk turning loyal employees into security risks, and since your users are usually your weakest link, this can be the factor that brings the whole structure down. Ultimately, it's about UX, the user experience. If you understand how your users want to use the system, you can also build the experience, the UX, so that it doesn't throw off their feet.