[BreachExchange] Planning for Mistakes: How to think about Cybersecurity in 2018

[Audrey McNeil]

https://www.scmagazine.com/planning-for-mistakes-how-to-
think-about-cybersecurity-in-2018/article/701644/

There is a wonderful web site, despair.com, who specializes in selling
posters which parody those tacky ‘fly like an eagle' motivational prints
that were once very popular. My personal favorite has a picture of a
sinking ship with the caption ‘Mistakes – It could be that the purpose of
your life is only to serve as a warning to others.'

Well, this year there have certainly been some mistakes. Let's just toll
the bell and remember…

- The huge shipping company paralyzed for days after a malware attack took
out almost their entire infrastructure. They were not alone; at least five
or six other organizations were similarly affected. Their mistake; leaving
an obsolete file access protocol enabled and sharing a common local account
and password with admin privileges across their estate, allowing the
malware to pivot with ease and blast everything to smithereens like
Hurricane Irma.
- The accounting and consulting organization who had sensitive customer
data exfiltrated on an industrial scale. Their mistake; not using
two-factor authentication to secure critical administrator accounts.
- The credit reference organization that exposed nearly 150 million
sensitive user details to unauthorised access. Their mistake; not patching
a critical subsystem in their public-facing corporate internet
infrastructure.

Cyberattacks represent a classic example of what the military call
‘asymmetrical warfare.' After the Brighton Hotel bombing, which very nearly
succeeded in assassinating Margaret Thatcher, the IRA stated “Today we were
unlucky but remember we only have to be lucky once.”

This is, of course, the nightmare that keeps CISOs awake at night. The
unpatched vulnerability, the overlooked protocol enabled unnecessarily, the
stolen mobile device with sensitive credentials, the employee who opens a
malicious attachment – how do you defend against these?

Fortunately there are answers. Answers which – hopefully – will ensure you
don't get to stare ruefully at a copy of ‘Mistakes' while creatively
rewriting your CV.

Firstly, assume you WILL be successfully attacked. Your defenses WILL be
breached. Many organizations have what I call ‘raw egg' perimeter defenses.
That is, there's a relatively tough (yet fragile) shell but if you breach
this, all is lost.

By assuming you will be breached, your focus should move to what the
attacker can then do. Assume an attacker WILL gain full administrator
access to a target device. Realistically, this isn't (hopefully) a critical
infrastructure device such as a domain controller. These devices need an
additional layer of security around them. But you can't fortify all your
endpoints. So assume it'll be a public-facing web server, or perhaps an
employee's computer, compromised by a phishing attack. These are realistic
scenarios you should plan for.

At this point you need to understand the assets that your attacker has
gained control of. There are two vulnerabilities intrinsic to Windows
devices that reside in the system registry (and thus, cannot be protected –
they are obfuscated, but this is no defense)

- The domain account names and hashes of the last ten people to log in to
the device, using a domain login. These hashes can be cracked surprisingly
easily to obtain plaintext credentials, which can then be used to attack
other devices.
- For any service running on the device using domain credentials, the
account name and plaintext password of the domain account that service is
using.

Now the first of these is a consequence of domain account caching. On
permanently-installed servers, you might want to consider whether you need
this enabled – it's only necessary if you need to log on to the device
using a domain account and the device has lost network connectivity. But if
you use a secure mechanism for managing local accounts with administrator
access (such as Microsoft LAPS) you can still regain control of the device
even after a network card failure. So you could disable caching to
eliminate this vulnerability entirely.

The second vulnerability can't be defended against directly. Even if you
run services using local accounts, these local accounts reach out across
the network in the context of the domain computer account and an attacker
can recover the password for this account from the device registry.

What you need to do is think about what an attacker can do with these
credentials. They can probably read (and write) critical databases that the
service legitimately accesses, for example, if they can connect to these
databases. So make it harder for them by ensuring all connection strings in
configuration files are fully encrypted using the DPAPI subsystem.

This isn't a perfect defense; DPAPI can be cracked by a really
sophisticated attacker, but you are putting barriers up. The attacker has
credentials but they don't know the target devices on which those
credentials are valid. If they attempt to use them elsewhere, your
perimeter defenses should pick this up; accounts used by services should
NEVER have interactive login privileges, for example.

Consider the use of Group Managed Service Accounts for service logins.
These have a complex password which changes regularly. Yes, this password
is in the registry but the actual account name itself isn't directly
available to an attacker, making reuse of these credentials just that bit
harder.

Of course, you're using trusted connections for everything, right – no
accounts and passwords in plain text anywhere? Or if you are reaching out
to a subsystem where this can't be done, you're storing sensitive
credentials in the Windows Credential Store, I hope. These are then
protected by DPAPI – not totally secure but much harder to crack.

Can your applications impose an extra layer of protection? Use HTTPS for
all internal API communication, not HTTP. And use ‘shared secrets' to
establish that the caller is a legitimate consumer. This ensures an
attacker can't just use those stolen credentials directly.

Are you leaving yourself open to cyberattacks by not staying current with
OS and application updates across your enterprise?

Finally, do you have tripwires set so that an attacker who DOES compromise
an endpoint will be detected quickly?  When anomalous access patterns are
detected on an endpoint,

can you act quickly to ‘quarantine' the endpoint and ensure it cannot be
the vector for further compromise, as well as preventing the exfiltration
of sensitive information?

Ask your pentesters to pursue a scenario where they have, say, full admin
access to a corporate web server that is publicly facing. Your defenses
should be strong enough that even in this situation, it's difficult or
impossible for an attacker to break out of that endpoint and do further
damage.

What's more, you should be able to detect any attempt to exfiltrate data
from that endpoint, or intercept traffic; public-facing endpoints should
have locked-down whitelists for all allowable software and permanent
monitoring using memory forensic tools to look for sneaky attacks via
buffer overflows, dynamic DLL injection etc. Needless to say, they should
run the most up-to-date version of Windows available and you should
implement Credential Guard, Device Guard and of course Secure Boot.

For internal endpoints, the obvious attack vector is via a phishing attack.
Apart from training staff never to open an attachment if they are in any
way suspicious, you should also be very careful to ensure that account
credentials gleaned by an attacker can't be exploited either. You might not
be able to lock down these endpoints as securely as those which are
public-facing, but you shouldn't be blasé about them either.

Have your pentesters explore a scenario where an attacker has full admin
control of the endpoint and ensure that there's no easy mechanism for an
attacker to “break out” of that endpoint and compromise other devices.
Ensure that endpoints don't hold sensitive data; if this year's business
plan is stored securely inside a cloud-based document retrieval system,
then there isn't a locally-stored Word document for the attacker to sneak
off with.

So plan for mistakes. Why not buy that poster and put it on the wall? Every
morning, plan to ensure the purpose of your life is NOT to serve as a
warning to others. That way, you'll be able to sleep at night, knowing your
defenses have been battle-hardened, rather than hoping for the best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171204/e148452d/attachment.html>