[BreachExchange] Defence in Depth: A 'layered' strategy can repel cold attackers

[Audrey McNeil]

https://www.theregister.co.uk/2017/03/23/protect_your_
digital_enterprise_defence_in_depth/

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.

Summing up

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170323/f5557339/attachment.html>