Defence in Depth: Summary (part 7/7)

Throughout this article series we’ve touched upon a number of basic principles for how to build secure applications.

• Defense in depth — Build security in multiple layers
• CIA-A — Security is a balancing-act, don’t forget about availability
• Least Privilege — Minimum set of permissions required to perform an action
• Rotate, Repave and Repair — Secure operations and maintenance requires automation
• Secure by design — Security is part of your domain
• Zero trust — Don’t place your trust in a single actor, data or layer of defense
• Secure defaults — make mistakes hard to make

When we at Omegapoint perform security reviews we generally find more vulnerabilities in complex systems. Not only because complex systems contain more functions and provide a larger attack surface, but also because they are harder to grasp. Many weaknesses arise from the fact that the team does not fully understand their own system. For example the team might not know which APIs publicly exposed.

A system that the team understands has a greater potential for being secure. We generally find fewer weaknesses in systems where the team can draw architectural overviews and explain their system and its integrations.

At the beginning of all security reviews we ask the team responsible for the system to give a technical description of it and answer the following questions:

• What data does the system contain and which of that data is important to protect?
• Which entry points are there to the system, how are they protected and how do you handle access control?
• What integrations are there and how are they used?

In our experience a secure system can always be described by the team according to the bullets above. However, the opposite is not true, i.e a system that can be described by the team is not necessarily secure. Understanding a system enables you to make it secure, but it’s not a guarantee.

“You can’t secure what you don’t understand” — Bruce Schneier, 1999 ”

https://www.schneier.com/essays/archives/1999/11/a_plea_for_simplicit.html

It’s also important to understand different types of attacks to implement and verify your defense mechanisms. Our experience from past security reviews shows that OWASP defines a good base line that is relevant for many systems and realistic to implement. OWASP has a lot of great sub-projects with good documentation. In particular we’d like to highlight:

• OWASP TOP 10
• Cheat Sheets
• Proactive Controls
• ASVS

Securing a system over time requires a structured way of working where security is an integrated part of your process. Independent, reoccurring security reviews give you feedback that your security work makes a difference.

See Defence in Depth for additional reading materials and code examples.

More in this series:

• Defence in Depth: Identity modelling (part 1/7)
• Defence in Depth: Claims-based access control (part 2/7)
• Defence in Depth: Clients and sessions (part 3/7)
• Defence in Depth: Secure APIs (part 4/7)
• Defence in Depth: Infrastructure and data storage (part 5/7)
• Defence in Depth: Web browsers (part 6/7)
• Defence in Depth: Summary (part 7/7)