Security Engineering Manifesto
Introduction
At Nationwide, we consider security engineering a critical component of the way we deliver reliable systems. We treat it as a discipline focused on the tools, processes, and methods needed to design, implement and test systems and to adapt existing systems as their environment evolves.
In this article, I’ll explain how our view affects everything we’re doing to embed security into our systems. I’ll start with outlining our vision and, in the subsequent sections, will discuss our beliefs and values.
Vision
In Nationwide Technology, we aim to protect our members’ money by building dependable systems in the face of malice, error, or mischance. We strongly believe that many systems fail because their designers protect the wrong things or protect the right things but in the wrong way.
Beliefs and Values
We believe:
- Security is a systemic concern; therefore, security problems should be solved by considering their environment.
- Socio-technical systems are complex; therefore, choosing the right abstraction level and perspective is necessary to understand and protect them.
- Systems and their environment change; therefore, we value primary controls over secondary controls.
- Security solutions are context-sensitive; therefore, we value design instances over high-level design patterns.
- Prevention is better than cure; therefore, we value preventative controls over detective controls.
- Automation is not a replacement for expert knowledge; therefore, we value expert judgment over automated tools.
- Humans are fundamental to all socio-technical systems; therefore, we value enabling people to do the right thing over preventing them from doing the wrong thing.
- Code is the lowest level of abstraction; therefore, the security controls’ effective design requires working down to the code level.
Discussion
In this section, I’ll explain the above list that shapes how we engineer secure systems. It’s worth mentioning that where there is a comparison in the statements, while there is value in the items on the right, we value the items on the left more.
Security is a systemic concern; therefore, security problems should be solved by considering their environment.
A system is a collection of interrelated components working together in a particular environment to achieve the system’s objective. A system’s properties can’t be attributed to a single part but are the outcome of its part’s synergies.
To build a secure system, we need to secure the components and their interactions. The interactions occur in an environment; therefore, it is necessary to consider the environment in solving a security problem.
The tools & techniques introduced in the following sections will help us consider the environment and take a systemic approach to comprehend security problems.
Socio-technical systems are complex; therefore, choosing the right abstraction level and perspective is necessary to understand and protect them.
We need to have a solid understanding of a complex system in order to be able to secure it. Abstraction levels and perspectives are strong tools that enable us to manage the complexity of a system. They empower us to build a view of the system by changing the perspective and moving in abstraction levels.
Consider the below example. We’ll use different views to understand the object.
Some of the details are not visible in the views illustrated above and need a deeper dive into the object.
Views 1–6 give us the ability to build a better understanding of the object.
- Views are considerably different from each other.
- Not all elements are visible in every view. In fact, some views are building a unique picture of the object (e.g. View -6)
- The collective knowledge gained from different views makes it possible to comprehend the object.
We are developing an understanding of a system by looking at different views and will try to build the entire picture by changing our point of view as we don’t have access to the full picture in the beginning. The socio-technical systems are way more complex than the above example and abstraction levels and perspective allows us to build a clearer picture of the system.
In this article, a methodology has been introduced to employ these constructs to perform a threat modelling exercise. In my previous post, I demonstrated an example of how those constructs can be used to perform a threat modelling exercise.
Systems and their environment change; therefore, we value primary controls over secondary controls.
In the previous section, we discussed abstraction levels and how it helps us manage the complexity of a system. The threat modelling article demonstrates that as we identify threats in different layers of abstraction, we design controls for them and then move to the lower layer.
We deploy enterprise applications to an environment with several available controls that reside in different abstraction levels. The purpose of those controls is not to provide application-specific control but to address the threats in the respective abstraction layer and implement the defence in depth. It is essential to appreciate the scope of those controls and the level of their effectiveness.
In the below diagram, the controls are defined in three layers. Layer-1 provides controls at the highest abstraction level and have limited awareness of the downstream target applications. As we get closer to the application, we move to the lower layers of abstraction, and the controls become more specific to the application.
The primary controls will be designed close to the target systems, and as they live in the same abstraction level as the application, they can afford bespoke controls. They are aware of the application context and are designed for a specific application.
As we add more applications to our environment, the controls in higher layers of abstraction — layer 1 and 2 — might need to change, which affects the protection of other applications. The more our applications rely on secondary controls, the more frequently we will face conflicting situations, and we will end up with complicated secondary controls that are costly to maintain.
Security solutions are context-sensitive; therefore, we value design instances over high-level design patterns.
“Context” is “the situation within which something exists”. The solutions we provide to secure components are context-sensitive because they exist in different environments (situations).
A design pattern is a reusable solution to a common problem used to increase efficiency and avoid duplicating efforts. While it is important to do things right, it is more important to do the right thing. To meet the efficacy requirement, a design pattern should emerge from the solutions created within a specific environment. High-level security design patterns that are not considering the context will increase the efficiency but not necessarily efficacy!
Design instances must be developed for a specific problem in a particular environment and should be documented appropriately. Once those design instances are produced, we can extract design patterns from them to increase efficiency. It is vital to note that there is a subtle difference between the emerged design patterns and the generic high-level design patterns. The former is derived from bespoke solutions in our organisation and will reflect the environment (organisation-level controls, engineering practices, ways of working, etc.)
Prevention is better than cure; therefore, we value preventative controls over detective controls.
Security controls are protections to mitigate the risk. They can be classified as preventive, detective, or corrective control. While prevention controls limit a malicious user from compromising a system, detective and corrective controls aim to remediate an incident.
The focus of the design should be to incorporate preventive control into the system. Current practices in software development (including DevSecOps) aim to shift the security to the left to design and implement security controls from the start. While detective controls are necessary and will enable us to restore to the target state, preventative controls are equally (if not more!) important.
Automation is not a replacement for expert knowledge; therefore, we value expert judgment over automated tools.
Automation is about replacing machines with humans. It aims to increase efficiency by making use of the advantages of a machine to perform repeatable tasks. Automation — like every other tool — has a scope that should be recognised. You’ll find a detailed discussion on what can and can’t be automated here.
Machines are helpful to improve efficiency as they don’t have human limitations, but they can’t be used to improve efficacy. Without expert knowledge, automation can be used to do the wrong thing more efficiently! In other words, specialist knowledge will assist us to find out the right thing, and automation can help us do the repeatable task at a lower cost (and higher speed).
Humans are fundamental to all socio-technical systems; therefore, we value enabling people to do the right thing over preventing them from doing the wrong thing.
Humans are a central part of the socio-technical systems and shouldn’t be ignored. They will happily choose the more secure way to accomplish the task if it is usable. One of the reasons that “people are the weakest link” is that they haven’t been considered in the design of the systems.
Usability is an essential requirement of a system. If a secure solution is challenging to use, time-consuming or stops users from achieving their goal, they will likely discover their own solution. Secure solutions should act as an enabler and support people to do the right things instead of preventing them from doing the wrong thing.
Code is the lowest level of abstraction; therefore, the security controls’ effective design requires working down to the code level.
In the above, we explained how we move in the abstraction levels in both directions while developing an understanding of the system. In the virtualised world, code can be considered the lowest level of abstraction(although different programming languages do not belong to the same level).
It is necessary to work down to the code level as it ensures that
- The designed controls at a higher level of abstractions are implemented correctly.
- The vulnerabilities introduced in the code layer are studied and investigated, and the appropriate controls are designed to address their risk.
Working at least at the code level is essential for every security engineer. Leaving the implementation of the designed controls to anyone other than the security experts undermines the controls’ effectiveness and puts our systems in danger. It gives us the illusion of being secure — as we designed the control for the threats — while actually, the controls aren’t working due to poor implementation.
Summary
In this article, I explained our vision, beliefs, and values that form our approach to solving security problems. I talked about some of the tools and techniques inspired by those beliefs to embed security in our systems.
I’ll talk about how those values are reflected in other activities to build resilient systems in future posts. In the following article, I’ll explain how to develop design instances that will help you to find bespoke patterns in your environment.
References
Ross Anderson. (2020) Security Engineering A Guide to Building Dependable Distributed Systems. 3rd edition. Wiley
Russell L. Ackoff. Systems Thinking. https://youtu.be/OqEeIG8aPPk?t=625
