In this series, we look at how to build security into your development process:
This week I look at how we can include security during the design phase.
Secure by Design
Secure by design (SBD) is a software engineering principle. It means we design the product from the ground up to be secure.
Secure by design starts by including well-established security principles and tactics.
This also means we accept the inevitable: we will be attacked. We expect malicious attacks, so we focus on ways to counter them and reduce their impact.
Design Guidelines
I like the approach of the UK National Cyber Security Centre. They list five categories or guidelines for design. These provide a framework and a mindset that will help us during the design:
- Establish the context. Before you can create a secure system design, you need to understand the fundamentals.
Remember what I mentioned about training in my previous article? - Make compromise difficult. Use techniques which make it harder for attackers to compromise your data or systems.
- Make disruption difficult. When critical services rely on technology for delivery, that technology must be available. 'Down time' is not acceptable.
- Make compromise detection easier. I discussed this in an earlier blog post.
- Reduce the impact of compromise. Design to minimise the severity of any compromise.
Design Principles
There are some well-established design principles for security. Each of them deserves an in-depth article, but here's a quick overview of what they are.
Least Privilege
This means that users must only have the access that they need to do their job. Every task should be executed with the least privileges possible.
Separation of Duties
This means that no single role should have too much authority. When someone has a job that’s too big, they’ll need lots of permissions — which is contrary to our first principle. And don't forget human nature. Too much responsibility can lead to poor decisions.
Defence in Depth
This design strategy involves layering security controls. This means attackers need multiple security compromises to gain access to critical resources. We want many systems — physical and cyber — that will tell us when the security fails.
Failing Securely
Once again, this principle recognises that things are going to fail. So when the components of the system fail, the system should still remain in a secure state.
Here's a physical example. If the system fails, all the locks on all the doors stop working. Do we want all the doors to unlock when the system fails, so that anyone can access anything? Or do we want the doors to lock to prevent unauthorised access? The same concept applies to software design.
Open Design
Your system security should not rely on the secrecy of your implementation. Never rely on the idea that “nobody would ever figure that out.” That's why well-designed cryptography implementations are published. They’re interrogated by the smartest people in the world before they’re put into practice.
This is also called the “principle of avoiding security by obscurity”.
Minimizing Attack Surface Area
This principle focuses on removing parts of an application to make it more secure. Think of physical data centres. They generally don't have a lot of windows, because windows are easy to break. In the same way, parts of your application are like windows. They look nice, but they might expose functionality that leads to bugs. This principle questions whether a feature is necessary. Sometimes we can improve over-all security by simplifying or redesigning a feature.
And this, once again, is why everyone needs some basic training in security. That will help users understand why they can't get certain bells and whistles.
Secure by Default
A system is secure by default when the default settings put the system in a secure state. This principle recognises the role of usability and human psychology in secure design. We don't want users to circumvent our security features for the sake of convenience.
Useful reference
I've already mentioned the guidelines listed by UK National Cyber Security Centre. Their website provides more detail on each of those guidelines, and is worth reading.
Join me in the next post: Building Better Security - Part 4: Secure Coding Standards.
What is the approach in your organisation? Please share your views and comments.