Good Design = Good Security?

The title of this article poses a tricky question. Does good design equal good security? It is one of those questions that have no right answer. So to begin with, I will give you my personal take: maybe. Because what is a good design? If it is a database design, then the database should be designed to be fast and adequate for the particular application.

If it is a network, then it should be designed for the workloads that the network will have to accommodate. Please note the difference between the two: One is related to application design, the other to an infrastructure design. The process of embedding cybersecurity as part of the design efforts would look vastly different for these two examples, but is no less important if the application and the network is to provide us with security, as well as business value. Unfortunately, there is extraordinarily little guidance out there on incorporating security into design efforts. The National Cyber Security Centre (NCSC) in the UK provides some guidance on how to approach system design with security in mind and the rest of this article, including the practical example, is related to that guidance.

NCSC pointers

The complete guidance from NCSC would be too large for a single article, so I have reduced it to the highlights that NCSC provides in its guidance publication. Remember that there are a LOT of details associated to each of the points below and interested readers are encouraged to explore further information through the link given at end of this article. That said, first the key points are:

  1. Establish the context before designing a system.
  2. Make compromises difficult.
  3. Make disruption difficult.
  4. Make compromise detection easier.
  5. Reduce the impact of compromise.

The cybersecurity professionals among you surely agree with the above points. The difficulties arise when we try to apply these concepts to a practical design. I am sure you have been there yourselves. How do we go about actually realizing them? Or even more challenging, how do we implement them in an existing infrastructure or application, because greenfield deployments are few and far between?

I firmly believe that good design, at the very least, provides us with a solid foundation for cybersecurity, if incorporating cybersecurity has been part of the design efforts. Just like for requirements gathering, security must be an integral part of any design for foundational security to be built-in. The following is an example that I have seen several times in the wild, with one of the design changes I proposed, to make it more resilient and secure.

Example

In the figure below is an implementation that I have seen several times in cloud deployments. The example I am using here, both the original design and the redesign, was done on Microsoft Azure. First, let us see the first iteration:

Here, an entire multi-tiered application is running within a single subnet, with all the individual IP addresses able to see and communicate with each other. This design violates point 2,3, and 5 of the NCSC guidance above, as well as many of the best practices the industry has developed over the years. With this design, a compromise of one of the webservers will make communication with the application and database servers a breeze, making their compromise a much more likely scenario.

I usually tell customers that the advantage of Azure is the ease of deployment of resources, but I also tell them that the disadvantage of Azure is the ease of deployment. The figure above, I usually see when developers have spun up an environment, just to do a quick proof of concept and before long, what was just supposed to be a quick prototype, has become a business-critical application. This is not the fault of the developer! I myself have experienced this several times.

So, what is a better design option for the above scenario? I redesigned the network to reflect what you see in the figure below:

Here each tier of the application has been segmented into their own individual subnets/VLANs. With this design we can use the Network Security Groups (NSG) to control the kinds of traffic allowed between each of the VLANs. This way, we can control communication protocols and ports that are allowed between each of the VLANs, this way we can follow pints 2,3 and 5, that was violated in the initial design.

Changing the design of the tiered structure of an application, is not something that is easily done. It comes with significant challenges and possible application changes as well. This brings me back to the point I made at the end of the NCSC Design section of this article: Good design can be good security, if security has been baked into the design process! Please take a good look at the recommendations from NCSC, that you can find at the link below:

https://www.ncsc.gov.uk/collection/cyber-security-design-principles/cyber-security-design-principles

Print Friendly, PDF & Email
Tom Madsen
Senior Security Consulting Manager at | + posts

Tom Madsen has been active in the cybersecurity industry for more than 20 years. Tom graduated from the University of Aalborg and covered several technical roles in security during his professional career. He is certified as CISSP, CISA, CISM, CGEIT, CRISK, CCSP, CDSPE and CSSLP, and has published the book "The Art of War for Cybersecurity". He is currently writing a book 'Security Architecture - How & Why'.

Tom Madsen

Tom Madsen has been active in the cybersecurity industry for more than 20 years. Tom graduated from the University of Aalborg and covered several technical roles in security during his professional career. He is certified as CISSP, CISA, CISM, CGEIT, CRISK, CCSP, CDSPE and CSSLP, and has published the book "The Art of War for Cybersecurity". He is currently writing a book 'Security Architecture - How & Why'.

Leave a Reply

Your email address will not be published. Required fields are marked *