Promo The principle of Defence in Depth (“DiD”), says OWASP, is that “layered security mechanisms increase security of the system as a whole”. That is, if one layer of protection is breached, there’s still the opportunity for the attack to be fended off by one or more of the other layers. If anyone’s ever drawn something that looks like an onion on the whiteboard – a load of concentric layers with your infrastructure in the middle – that’s the concept we’re looking at. It’s actually a military term that’s been adopted by security types in the IT industry who want to be tank commanders when they grow up.
On the face of it it’s a pretty simple concept to understand. Rather than just having (say) anti-malware software on your desktop computers, why not also make your Web downloads go through a filter that has malware protection on it too? And yes, this helps. But to do it properly you have to step back a few strides and have an overview of your world: although it’s going to cost me 50p in the buzzword swear box, I’m going to say “holistic view”.
1. Identify the actual perimeter
I wish I had a fiver for everyone who pointed at their Internet router when I asked them where their network’s perimeter was. Anyone who does that has never been the victim of a proper Denial of Service (DoS) attack, because the bottleneck in your external connectivity will amost certainly be the bandwidth of the link, not the firewall at your end of it. If someone wants to DoS you they only need to saturate your link, not cripple the router or firewall. So the outer layer of your DiD consideration is to adopt Internet connectivity that has DoS protection at the upstream – remote – end to protect your relatively slow link against being swamped by an attacker.
2. Define the data flows
Next, understand the flows of data in and out of your network (primarily in). The basics will be Web browsing traffic and email, though you may also have some others such as file transfers (FTP/SFTP) and the like. Again, the ones that are easy to forget are removable drives (USB sticks), CDs and DVDs, and even PC-to-smartphone synchronisations. Consider every possible path you can think of via which data might go from a device that’s not part of your network to a device that is, and write down all the touch points within your world in the data flow.
For example take an inbound email message. You first have control when it hits your ISP’s network, then it touches your Internet link, router, firewall, LAN switches/routers, physical server, maybe a virtual server sitting on the latter, then finally the email server and an underlying database server (with associated database software) and fileserver. The message will also then see the LAN again, then a desktop PC and desktop email program and/or Wi-Fi controller and user’s smartphone. It’s actually quite a lot of steps when you think about it.
Finally, think about where else it could go: in this example you might choose to outsource some protection and have your mail delivered not directly to your own mail server but via an external scrubbing gateway. So include this as a possible touch point.
3. Define what you want to protect against
Now you know what the data flows are, you need to figure out the types of problem each one poses. For example, inbound email has the threat of malware-laden attachments but also harmful unsolicited email (phishing attacks, perhaps). File transfer services share the threat of malware, as do Web browsing connections; the latter also allow access to undesirable and even illegal material in their default form. But think harder: if you’re using software to access something, you might want to protect against bugs in that software allowing compromises (connection hijacks, maybe).
If you’re hosting any services internally, things are a whole lot more complicated because most of the touch points you wrote down in step 2 may be potential attack points: the firewall, the mail server, the user’s phone, the desktop operating system, the desktop email program … the list goes on. A bug in the email server could cause an outage. A misconfigured and/or vulnerable router could allow a worm into the network (a la Mirai). On your list of data stream touch points, write against each the possible attacks that could happen to it.
Then make a risk-based decision. Which basically means: you can’t protect everything against everything, so take a value judgment to protect as much as is economical.
4. Select the products and services
Now you can go out and select the products you want. And as always in computing, it’ll be a compromise. On one hand, it’s great if you can get a suite of products that you can manage from a central console and report on (see below) in a single hit. But on the other hand, adopting a single vendor runs the risk of restricting your defences.
For example, say you decide to put operating system-level anti-malware on the mail server and on the desktops, and to use the vendor’s Exchange plug-in to extend protection to the application level too on the mail server. Great idea, but all this is going to do is help you if (say) one or another of the machines has an out-of-date malware signature file. If, on the other hand, you put a different vendor’s anti-malware system on the email server application, you’re improving your chances of intercepting a virus because vendors tend constantly to alternate their position in their race to accommodate new viruses. Trouble with the latter case is that you now have two systems to manage and monitor.
And don’t forget to include software update and deployment tools in your consideration: although one component of protection for computer systems is to add software, another is to apply patches to remove security-breaking bugs.
Consider all the options, then, and bear in mind also that some vendors embrace support for others. My favourite example is Web filtering services: you’ll often find that the default setup includes malware protection from one vendor, but for a little extra cash you can add one or two others in order to benefit from the anti-malware race. Again we’re back to the holistic view, and this feature has now cost me a quid.
5. Design the reporting
Reporting is your friend. And if you want to show people that you’re taking suitable precautions it’s probably your best friend, because you can’t actually tell if anything’s working if you can’t report on it. This also means you have to have suitable logging turned on for the reporting system to consume.
I’m not going to go into a lecture on reporting because it’s a science in its own right and people have written entire books on it. (Yes, really – including one called “Measuring ITSM: Measuring, Reporting, and Modeling the IT Service Management Metrics that Matter Most to IT Senior Executives”). Suffice to say that you need four basic kinds of reports:
- Management reports that your non-technical managers will consume. They love things like stats on how much spam you’ve blocked, how many viruses have been caught before they could infect you, and so on.
- Technical reports for the tech team that show the behaviour of the system for proactive activity such as capacity management – the growth in firewall CPU load, for instance.
- Technical reports of exceptions – unusual Internet traffic levels that hint at the presence of a DoS attack, for example, or viruses that made it to a desktop despite having been through the mail server’s OS and application protection.
- Alerting to serious problems: if, say, a scheduled scan of a fileserver throws up a virus on a shared drive, you may want your pager to scream at you at 3:00am rather than waiting to look at the exception report in the morning.
When you’re designing the reporting, there’s an important rule: ask yourself how, in the event of any of the reports showing you something you don’t want to see, you will: (a) figure out what’s wrong; (b) stop it if it’s still happening; (c) get the affected service(s) back on their feet; and (d) eradicate it from the infrastructure.
6. Monitor and react
Finally, and this is immensely important: watch the reports and do something about the contents. A wise old man known to his friends as ISO 27001, Annex A, control A.12.4.1, once told me: “Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed”. There’s absolutely no point whatsoever having logs and reports if you’re doing nothing with them and you’re not reacting to the useful things – positive or negative – that they’re telling you.
Defence in depth will definitely save your bacon one day. It’s rather like insurance, though: the value is hard to demonstrate until the day your house burns down. So you need to muster your powers of persuasive reasoning to convince the bean counters that yes, you do have to protect against each type of threat in two or maybe more places if you’re going to be properly safe. And that you have to consider the whole infrastructure and every possible way in and out of it.
Oh, incidentally: if you Google the military concept of Defence in Depth, you get several responses that tell you that the approach “seeks to delay rather than prevent the advance of an attacker”. But perhaps we’ll ignore that part of the heritage definition and stick with our preferred concept of keeping the attackers out altogether. ®