The Defence in Depth Security Model is one of those security concepts I often see incorrectly implemented or not used to its full potential to protect services or systems. There is way more to it than first meets the eye.
In this article you will learn:
- What the Defence in Depth Security model is,
- How to apply it to your critical systems and services,
- Specific implementation considerations to get the best benefit, and,
- Some advanced ways to set it up for high-security environments.
What is the Defence in Depth Security Model?
The basic Defence in Depth Security Model is the technique of ensuring no one security control measure on its own is responsible for ensuring the security of a system, there is always some other component performing a similar function ‘behind it’.
The idea of having such overlapping controls is to guard against the biggest single cause of security breaches, namely human error. People are not perfect and they cannot be 100% accurate in what they do all the time, mistakes are made, and things are missed or forgotten, and this can cause major problems for security integrity. By way of example, consider the Equifax security breach, one of the major contributing factors to the success of the breach was that Equifax had failed to renew a certificate on one of its network traffic monitoring tools, this single human error allowed the attackers to exfiltrate their data undetected.
The overlapping controls also help guard against probably the second biggest cause of security breaches, namely control breakdown. This is where a security control becomes nonfunctional and does not work as it’s meant to. This could be a hardware failure, a software dependency or service failure or just a simple bug; either way, the control stops working. For instance, certain brands of WAF (Web Application Firewall) will fail ‘open’, in that if their configuration or state becomes invalid, they will default to letting all traffic through regardless. So if you are depending on a WAF alone to protect you against all the ‘bad traffic’ that is out there, you could be in for a surprise.
Using the Defence in Depth security model
Application of the Defence in Depth security model requires two steps. The first is to assess your primary ‘risk vectors’, in other words, the likely routes by which you will face an attack. This is done because using Defence in Depth is expensive and you want to be applying it where you get the best protection bang for your buck.
For most businesses, the most likely primary risk vectors relate to:
- online services they provide to customers (cloud-based typically), or,
- onsite services or systems they provide to customers, or,
- internal systems and services used by the business that hold corporate sensitive data.
All of these would be considered normally high-impact targets, their compromise would have a serious impact on the business and its customers’ security and cause much damage to all parties.
You need to ensure you have adequately modelled all the mechanisms by which such attacks could occur to ensure what you intend to do has the best chance of success. I recommend the usage of the MITRE ATT&CK model to assess how an attack would progress through your infrastructure and hence determine the ‘choke points’ where Defence in Depth can be best applied.
The second step is implementation and this needs to be done carefully, as you want a solution that has an availability equal if not better than what went before. No point in improving security if the system is not as reliable as it used to be. This might mean a slight re-architecture of the system in question to improve its qualities, which is not a bad thing, this could also be an opportunity to deal with other issues with the system architecture (for instance BCP and Backups).
Implementation Points to Consider
- Be very aware of your dependencies – too often people do not look at what their systems are dependent on and create a dependency ‘short circuit’ between the Defence in Depth layers, so if that dependency is tampered with both layers fail at the same time. This could be a shared common service such as a network drive, database or configuration store. It might be a physical private ‘back network’ that needs to be operational. It might even be a common logging service that could be made to ‘choke’ and lock up all who contribute to it. Remember the attacker’s goal might be simply to take you ‘off-air’ or to allow an attack to occur somewhere else now unseen…
- Remote logging always – do not depend solely on logging in the layers themselves, copy off the logs to a remote ‘append-only’ service. This way if some attack does occur, you have a ‘clean’ copy of the logs to work with.
- Admin from the trusted network only – the administration of these layers must only be possible from a trusted network over encrypted channels. No magic admin login from the public internet, please.
To show how you should utilise Defence in Depth, please see the diagram below.
In the above diagram, you can see there is a web server that has to deal with public internet-based traffic, this could be a simple static website running WordPress all the way up to a full SaaS cloud service offering. Regardless, the principles remain the same. You see that two security services have been added (coloured in red): a WAF that is in front of the web server and intercepts all web traffic to the web server, and a module called ‘mod_security’ that runs on the web server and filters all requests before they get processed (in this case run by a Php engine).
Notice how the WAF and mod_security do not in any way share any obvious common dependencies, so if one goes down or fails, the other will keep running and protecting the site.
Note also how the logs from both the WAF and web server (which includes the logs from mod_security) are sent to an independent logging service. This way if either is compromised a hacker will be unable to cover their tracks.
If you have something that needs guaranteed security coverage you need something stronger than the standard way of implementing Defence in Depth.
The first improvement is to overcome what I call the ‘going dark’ problem with normal implementations of Defence in Depth, namely a stealthy hacker could progressively work their way into your security controls disabling them one by one. A bit like picking multiple locks to open a door, it’s just a matter of time and expertise. For a set of computer-based security controls, this is usually evident by those controls going quiet or not alerting like they used to.
So the solution to this is twofold:
- Have a monitoring system (like a SIEM) that collates the logs of the Defence in Depth controls and has specific alerts for when the ‘chatter’ from these controls reduces in frequency beyond normal bounds.
- Ensure the Defence in Depth controls produce said chatter on a regular basis. This could be as simple as making sure the logging detail is at the right level to do this, or you might need to implement a specific ‘heartbeat’ process to do some simple health checks and log them every minute.
The second improvement is to implement heartbeat checking so each security control instance has an awareness of the other’s health. Again a simple heartbeat script would suffice, this way an external service is checking to see if the services are alive and functioning as intended. This is equivalent to security guards keeping each other insight as they walk around a building.
You are also free to implement an additional security control layer, although I would suggest doing this in a way that is ‘hidden’. See the diagram below.
In the above diagram, we have added in a ‘hidden layer’ into the Defence in Depth model, namely the Traffic Monitoring. The traffic monitoring is looking for abnormal traffic patterns that get logged and then fed into the SIEM for analysis. A hacker would be unable to ‘see’ this layer, it operates on the side. If the web server was compromised and the hacker tried to ex-filtrate the data they had found or take over another server, this monitoring should detect this and produce an alert to be investigated.
Implementing Defence in Depth has to be done properly in all cases to get the maximum security impact. Overlapping controls guard against the biggest single cause of security breaches, namely human error.
Ay Aykira we find Defence in Depth to be a critical mechanism to ensure security, especially for complex online systems which have many moving parts. Such complexity ‘breeds’ human error in even the best-managed environments; far better to derisk human error and carry on by using Defence in Depth.
If you found this article interesting and like would like to know more, please get in touch.