Every security professional knows that security depends on defence in depth. You can never rely on a single piece of security technology – if that fails, then hopefully another line of defence will catch the attack before it can succeed. I recognise therefore that what I’m about to say is a rather heretical suggestion, but are there situations where – done wrong – defence in depth can actually make security worse? Here are some ways in which that might be the case. Note: as a Brit, I would naturally write “defence” rather than “defense”, but I know that this can jar with American readers. So I’ve compromised by writing “defense” in the headline and “defence” in the text of the article!
Security products are vulnerable
Security products are themselves of course technologies, and as such, they will usually contain exploitable vulnerabilities. When the job of the security product is to detect and alert about bad things, the impact of vulnerability is limited. If an attacker manages to exploit the security product, the worst they can do is to disable the detection and alerting. That will be a pity, but all it will do is eliminate the benefit that the security product was supposed to bring. It won’t make things worse than not having the product at all. In this case, defence in depth is definitely a good idea: hopefully some other piece of security technology will fill the gap. But there are cases where that argument doesn’t hold.
Vulnerable security software on sensitive hosts
The first is where the security product is software that runs on a sensitive (“secured”) machine. In this case, it’s possible that the vulnerability in the security product is actually worse than any of the vulnerabilities in the applications and operating systems running on that machine. For example, in 2016 a vulnerability was discovered in a Symantec host agent (https://www.cvedetails.com/cve-details.php?t=1&cve_id=CVE-2016-2208) which, if exploited, could give an attacker complete root-level control over the operating system on that host. There’s a good argument that the host agent was actually reducing the overall security level of the host rather than increasing it. Enterprises typically have many security agents running on their hosts. (Indeed one bank I spoke to recently even told me that “if you’re a host agent vendor and you haven’t managed to sell to us, you’re doing something spectacularly wrong!”) Almost all these security agents run with elevated system privileges, often at the kernel level. What’s the betting that none of them has a vulnerability like the one found in the Symantec agent? Or that one of them hasn’t been subverted to provide a 3rd party with some “fringe benefits” (I observe without comment the US Government’s views on Kaspersky).
So…
…as a first step, perhaps we should be a little more careful about assuming that extra defence in depth is good where that involves software that runs with elevated privileges on the host.
Vulnerable inline security products
The second case is a bit more subtle. Some security products are designed to detect and alert on bad things. But inline security products are quite different. Historically, inline security products were designed to detect and block bad things. The earliest firewalls detected packets on “bad” ports and blocked them. Proxies with URL filtering detected “bad” URLs and blocked HTTP requests to them. These were quite simple security tools with relatively simple functionality, and consequently a relatively low attack surface. Inline security products have moved on a very long way since then. Moving well beyond inline signature scanning and blocking, the world of security technologies today provides a wide range of tools not only for content blocking, but also for content transformation. As these technologies get more and more complex, so the attack surface typically grows. All things being equal, there are likely to be more vulnerabilities in the latest next-generation firewall than in a simple packet filter.
The impact of vulnerable inline devices
So what’s the potential impact of a vulnerable inline device? Well, suppose an attacker sends you an email with a poisoned attachment. Although most of the time a combination of user vigilance plus well-patched applications and operating system will stop the attack, there’s a chance that the attachment will successfully exploit a vulnerability on the machine it’s opened with. As a result, you might choose to deploy a sophisticated mail gateway security technology that transforms attachments to a “safe” format. You’ve added a layer of defence and the risk to your machines is reduced. But what if an attacker manages to exploit that mail gateway technology? In principle, the mail gateway can now transform every inbound attachment into a poisoned attachment – even the legitimate ones! While most of the time your up-to-date patching will prevent any damage to the machines those attachments are opened with, by trying repeatedly with every attachment to every recipient, there’s a good chance that in the end, with one attachment on one machine, the attacker will ultimately succeed.
It’s not just email
My example used email, but the same principle applies for any inline technology. For example, it definitely applies in the Remote Browsing space that Garrison works in (www.garrison.com). Remote Browsing platforms have extremely large attack surfaces, and almost by definition we expect that surface to be breached at some point. An inadequately designed remote browsing platform can provide a beachhead from which an attacker can repeatedly send different maliciously designed data streams to the user’s endpoint looking for that one vulnerability that finally works. Other inline technologies with large attack surfaces include Content Disarm and Reconstruction. And while traditional firewalls and proxies may be relatively simple, the much more complex and sophisticated functionality available in the most recent devices is likely to result in equivalently more vulnerabilities.
Is this a realistic risk?
Historically, this hasn’t been a particularly serious consideration for enterprise security. But I fear it’s something that can’t be ignored very much longer.
Why?
Reason 1
Firstly, because there have historically been lots of easier ways of attacking the enterprise. But as enterprises improve their security across the board, attackers start to look for new avenues. Higher-security government organisations have always had real worries about the vulnerability of inline security devices, precisely because other routes of attack have been closed off.
Reason 2
Secondly, because inline security technologies are getting much more complicated. That increases their attack surface and makes it much more likely that an attacker can find a vulnerability to exploit.
Reason 3
And thirdly, because the diversity of inline security technologies has meant they were not particularly amenable to “mass” malware designed to compromise a wide range of potential targets. In particular, novel inline security technologies that have not yet been widely deployed were unlikely to be attractive targets for attackers. But targeted attacks are something quite different. A targeted attacker may well find the latest inline security technology to be a fantastic first step in an attack, providing a beachhead for compromising every enterprise system that communicates with them. Again, that’s something that higher security government organisations have always had to worry about, but which is going to be an ever-increasing concern for commercial organisations.
So what’s the implication?
Ironically, it’s the most security-conscious organisations that have most to worry about here. They’re the ones who have closed off the easy attack paths, who are often most at risk from targeted attacks, and who are most likely to have invested in the latest, most complex security technologies. Should they simply stop investing? Unsurprisingly, I don’t think so. It would be a counsel of despair. Innovation and technology has a huge role to play in helping improve security – without the business impact that comes from taking radical approaches such as disconnection. Instead, buyers of inline security technology need to ensure that when selecting a product they include in their evaluation criteria not only the functionality that the product can deliver, but also how the product protects itself against attack. And as with the email example, that’s the case even if the product aims to provide an “extra” outer layer of protection. If the product gets exploited, it can provide a better platform for an attacker to launch attacks against “inner” layers of protection – putting the organisation at greater risk than it would be without it. Here at Garrison this has been a key consideration for us from day 1. Our hardware-based security architecture addresses it head on – providing ultra-strong protection both against threats in web content and against targeted attempts to use the Garrison SAVI® platform as a beachhead for further attacks. That’s why we’re successfully selling into high-security government customers – but ultimately, we think it’s just as important for our mainstream commercial customers.