It seems that the longer you spend in the cyber security business the more you see change, yet you also see the same things occurring again and again. The one thing which does not ever change is that at the root of all security incidents you will find someone who did something wrong. This could be leaving a debug service open to all, or it could be forgetting to renew the licence in a bit of critical security software, or it could be a simple typo or ‘fat finger’ event at the wrong time in the wrong place. Where ever you will find humans you will find human error, guaranteed – to err, is indeed, human.

To me, this begs the question: if human error is often the root of 99% of security incidents, then why is so little truly focussed on dealing with it specifically? So much of the investment in security seems to be around detection, with little in true prevention. Why not design out the ability for such errors to cause such incidents, or at least when they do happen the incident is minor instead of a business crippling level event?

Makes you wonder doesn’t it..

Now you could say this is what Q&A, unit testing, code scans etc are there to guard against it, but there is a problem with this – it will only find what it has been written to find, it doesn’t understand what its testing or scanning – its looking for patterns of failure it already knows about. Trouble with human error is that it can occur anywhere, it could even be in the unit tests or code scanners you are running, they are just as much suspectable to human error as your systems are.

Now, it could be AI can make such checks more effective, but I have my doubts. I suspect as the checks become better, the programmers will become more lazy, given the checks are not 100% covering (even with AI), you get back to a situation where the chance of a vulnerability ‘going live’ increases, so the net effect of employing AI is essentially unchanged wrt security risk. Call it human nature, but if you increase the safe guards, people tend to start depending on them, they get lazy.

What if there was a way to make darn sure where ever human error occurs it does not ‘blow the doors off’. Well, there is a way that I have been using for years that is effective, cheap and reliable – its called Defence in Depth design.

Defence in Depth Design

The basic idea of defence in depth design is that you acknowledge up front your security controls have a rate of failure, yet this is an individual likelihood per control – in other words the failure of one control does not imply the failure of another. So given this independence of failures, why not layer your systems so a single failure does not ‘punch a hole’ through your defences?

This is a bit like the difference between a single line of defence and layered multiple lines of defences. The multiple lines of defence provide a much more difficult defence to overcome as the undefended back is that much further way. An alternative mental model is that of a castle where you have the moat, the draw bridge, the wall, the bailey, and finally the keep with numerous defensive opportunities throughout.

In this way you gain several other advantages over a single line of defence:

• Each layer can be managed in its own right, you are not forced into having to rebuild everything; with an associated ‘through punch’ risk.
• Inner layers can be wired up only to the next outer layer, this way its a lot harder to inject an attack around an outer layer.
• Inner layers can be set up to monitor the health of the outer layers – so providing an early warning of compromise that’s independent of other monitoring.
• Layers can duplicate security controls to provide operational redundancy, say SQL injection prevention. This way if an external layer fails open, you are still protected.

So how is this done in practice?

First off, decide how many layers you want? Usually in most designs people go with 3 or 4 layers, which typically map into:

• Network Edge – this could be an internet distributed content delivery network (like CloudFront, Akamai, Azure CDN) that can have filtering rules embedded into it to control exactly what traffic is permitted to the next layer. Some call this a WAF function but it usually doesn’t do deep inspections.
• Network router with WAF (Web Application Firewall) – this usually the service right before the application that routes and examines the data packets for unusual content and blocks if found.
• Application Web Server – the web server itself can usually be configured to perform checks on the data and block if needed. This can be quite detailed and more specific than that performed by the WAF.
• Application – the code itself can contain checks for data validity and integrity. Such stopping SQL injections, or detecting embedded html that is out of place, etc.

With such a set up, you can see how it is easy to have your security controls overlapping in coverage across the layers – so if one layer fails open (or is compromised) the damage possible is greatly reduced.

A few things you need to ensure you get right…

First off, do make sure that is not possible to ‘jump’ a layer by dint of that layer being publicly visible. In particular the Application Web Server should NEVER be directly visible to the internet in such a model, you are just asking for trouble.

Secondly, the same rule follows for services the Application Web Server depends upon, such as databases, key/value stores, file stores, etc – they should not be directly visible to the public internet. Putting everything in VPC (virtual private cloud) is one way of doing it, but ensure you don’t end up with one big VPC containing all your applications. Different applications should go in their own VPC’s.

Thirdly, logging is done remotely. A layer, and its associated controls, should not log locally alone – the logs should go to some independent logging store, and also onto a SIEM or log analysis service. So when something unexpected does occur, you both know about it and have the logs to investigate.

Fourthly, each layer needs to ‘stand alone’ in terms of shared dependencies. You should not run multiple layers on the same machine or box. Even if they are virtualised. This completely removes the risk of cross talk or resource starvation being used as a mechanism to take down a service. Keeps things apart and they won’t interfere with each other.

Conclusion

I hope I have convinced you that Defence in Depth in a useful system design technique to help reduce the ‘blast radius’ and likelihood of a human caused security incident. As I said, it is one of my principal design techniques that I know just works. If you would like to know more about this security technique, and others, please first consider buying my book , available both in hardcopy and kindle e-book.

If you want to follow up with me and are considering engaging me for my security and architecture services, please use the contact form . Thank you.