Security at all Layers

Security in depth, defence in depth, layered security, zero trust; all terms that get spoken but often not fully understood. Mainly because much of these security principles have evolved over time and depending on the lens applied a different term has emerged.

In this, the first of a series focused on security, I'll try and unpack what security in depth means (at least for me) and why you should be considering a layered security approach. I will try and keep these posts a mix of technical and non-technical details, and where possible utilise real world examples to highlight my thoughts. Future post will focus on the implementation of security from different perspectives such as application, data, and infrastructure.

So firstly, while I agree with Andy Jassy statement during his time as CEO of AWS that "security is “job zero” at AWS", I believe this is different to security at every possible point or layer in a solution.

So why do I differentiate between security is everyone’s job and security at every level?

To me security being “Job Zero” means that firstly everyone is accountable for security, and secondly that everyone is empowered to highlight security issues. This ensure that people are not only required, and encouraged to highlight concerns, they also have the ability to remediate issues. For more details on this I'd encourage you to ready the following AWS microsite.

AWS Culture of Security

Explore AWS’s strong culture prioritizing security, with a security-first mindset ingrained from executives to engineers through disciplined practices.

Amazon Web Services, Inc.

So thats great, everyone, at all levels of the organisation are responsible for security. This should mean that all layers of solutions are secure and everyone fixes problems as they arise or become visible.

But what are these people spotting?

Often this is around vulnerabilities and misconfigurations, or as a result of audits or incidents that highlight a possibility for system or data compromise.

While this is important in software delivery, this is not what I would refer to when talking about security at every layer or security in depth.

For me security in depth is about the type of controls that are in place. It is not just about a single standalone component being secure or vulnerability free. It is about understanding component’s place in the overall system and how it interacts, or should interact, with other components.

Security in depth takes all the best practices from each security speciality and weaves them together to give a robust security posture. It pull together items such as border security and layered security and intertwines them with identity verification and zero trust. Through out the delivery lifecycle it looks for both software and hardware vulnerabilities that are present through either software/modules or insecure configurations. As a result you get security embedded at each stage of the development and each interaction of a solution.

For me it’s like the safety deposit box in bank. While you might trust the building is locked and secure at night you still want your items secure in a vault to protect from unwanted access during the day rather than leaving it on the teller’s counter. You also want to ensure your box has a unique key only you have so that other authorised people who access the vault can’t access your box. Equally you would want to feel reassured that the vault has been built to a high standard and no a virus faults that could mean it is easy to breach. Again with your box you’d also want to ensure it was robust to withstand a certain level of attack. Together the construction, management and processes come together to give you confidence that your possessions would be secure.

So we should be looking for the same with our solutions.

We need to ensure that there is robust controls at each layer, or component, within the service. Only those interactions that are needed should be allowed, and should only be allowed by the right entity, wether human or machine. The right controls and protect should be enforced based on where and when those interactions are required or occur.

In future posts I'll look at what this means for the SDLC, networking, data, and applications. The hope is it will help you to understand the things to think about when managing the security of your solutions and why a single lens is no longer adequate.