Security by design

Intro

A while ago I asked some security colleagues about their interpretation of “Security by Design”. I received two answers:

1. “Security by design” means embedding security from the start into the design and development process… or similar - the “usual answer”
2. “Security by design” is a cool, hard to disprove, marketing term that implies you did something for security even if it wasn’t really a topic during much of the design and development process.

Both are right, and both are only helpful in conveying that one should be careful with the term. I can’t describe it better in one sentence, but maybe if I write a few more:

How to define security by design

Security by design is typically (reading Wikipedia, asking an AI will give you an even longer list) defined as incorporating security into systems from the beginning of the design process by incorporating a growing number of principles and concepts:

• Threat modeling
• Least privilege
• Layered security controls
• Secure defaults
• Defense in depth
• Fail securely
• Minimize attack surface
• Assume breach
• Open design (i.e. allowing review and testing, as opposed to obscuring everything)
• Continuous validation
• ..

I have two problems with that definition. One, it sounds a bit like defining engineering as:

• [Using an existing bridge design]
• Model the bridge behaviour with the traffic expected for your bridge
• Make sure you use the correct materials
• Make sure connections are redundant and backed up by additional fastening measures in case something fails
• …

That may be what the engineer needs to do in a particular project, but it doesn’t grasp what engineering is. Neither does the security task list above.

The second problem is that it hides the most important “design” principle. Which is especially bad since some of the “hay” can be fairly deep. Doing complete threat modeling and designing layered security controls may take months and years. By the time they are finished, the design phase may be over (or the system built already).
So what is the most important security design principle (am I still allowed to ask rhetorical questions or is that too much what AI does?):
“Minimize attack surface”. What you don’t have, can’t be attacked. As simple as that. The missing interface can’t be hacked. Not using node.js alleviates 80% of the potential supply chain attack surface (I am joking of course, it’s probably >95%) and so on. It is the single most important security design choice and at the same time probably the one thought about the least. Because unfortunately the typical customer (rightly so maybe, because he is the king), wants his system with all the features and niceness he wants, and secure on top. The minimizing is an engineering task, so it has to be done intelligently and considering all sides of the problem. For example not having a hard to secure interface may lead to people developing even less secure workarounds. (Completely tangiental: this is called Perverse Incentive or Cobra Effect).

Which leads to:

My definition of security by design

A system can be secure by design if solid security engineering principles are applied from the beginning of the design process and there is a willingness to compromise between features and security aspects.
Note: This compromise goes both ways.

Discussion continued

It should be noted that that is not the only way to achieve security. Just following the list shown above can lead to a high degree of security. Ideally in the form of what I would call “Security Management”, by applying a security standard such as NIST 800-53 or ISO 27001 that mandate all those principles (among a bunch of other useful things) and by good intregration into the actualy system design (Corporate IT processes, whatever). It is much more brute force and often comes at fairly high cost (even if started early), but it could be argued that it is much better understood than the mythical “secure by design”.