[BreachExchange] Shark or not? 3 real-life security scenarios and how to tell which will really bite

[Audrey McNeil]

https://www.helpnetsecurity.com/2017/08/02/real-life-security-scenarios/

We’ve just wrapped one of my favorite weeks of television, Shark Week.
Viewers were treated to show after show of sharks stalking and attacking
helpless victims. In most shark movies, the person swims along oblivious to
the looming and hidden threat – a continuous false negative. In fact, false
negatives are very bad for both swimmers and security professionals.

Let’s consider the daily life of a security analyst. Alerts are generated
constantly: a school of little false positives that the analyst eventually
learns to ignore. Over time, these little fishies are tuned out and are
just part of the environment. Occasionally, one of these might be a real
threat, but most of the time, they are ignored. In contrast, the false
negative – i.e. where everything seems fine, but in reality a real threat
is lurking – can cause much more damage.

For example, a hacker might steal an employee’s credentials, create
multiple admin-level accounts, and then spread malicious activity across
those accounts. An analyst looking at logs for each account might believe
that each one is fine. Only when linking them all to a single identity does
the real picture become clear. We read about breaches nearly every day and
in hindsight, it seems like someone should have been able to detect the
harmful incident before is caused a breach. But in reality, it’s difficult
to detect a real threat as it’s forming; there are too many false
negatives, too many quietly lurking sharks.

Let’s look at three examples I’ve seen at customers this year. In each
case, it wasn’t clear at the time whether there was an actual risky
incident occurring, or just a set of coincidences and false positives.
Judge for yourself:

Incident #1: Phish or Pshark?

At this company, multiple employees receive phishing emails that direct
them to a fake Outlook Web Access (OWA) website, where they enter their
credentials in order to log in and manage email. Hackers then harvest and
use the stolen credentials to access the employees’ actual Outlook OWA
accounts, and use those accounts to send spear-phishing emails to large
groups of non-employees (i.e. with yahoo.com or gmail.com, etc. addresses).
The recipients think the emails are real, since they come from known
senders and a valid company address. The firm’s SIEM can’t detect this type
of attack, so all looks well. But, using better detect techniques, the
phish is exposed as a real shark.

Incident #2: Recon or code commit?

At a large e-commerce firm, the behavioral analytics system detects a user
attempting to access a server fifty times per minute. Initially, analysts
suspect some form of malware attempting to move laterally around the
network – it’s a shark! Further investigation shows that this is actually a
system administrator testing some new deployment scripts. All is well, and
the shark turned out to be a harmless minnow.

Incident #3: HR, DBA, or… SHARK?

At a large retailer, an HR specialist accesses a variety of employee files
sitting on multiple fileshares. During the same day, a DBA backs up a
payroll database containing sensitive employee information such as social
security numbers, dates of birth, addresses, etc. Initial analysis doesn’t
show any obvious problem, since there’s an HR employee managing HR files,
and a database admin managing databases – another minnow. The analytics
system indicates a different picture, however.

The DBA account was used by the HR employee’s machine; she remotely
accessed the payroll database using this DBA account. Analytics show that
she had never accessed the database before, she’d never used that
credential before, nor has anyone else in HR accessed that database
directly before. Now the situation looks very different. In fact, the HR
employee had her credentials stolen via malware before she went on
vacation, and this operation was actually a hacker using the employee’s
domain account to access the network and a stolen DBA credential to access
the database. Yet another shark, pretending to be a minnow.

Do these examples seem far-fetched, or too real?

When companies begin uncovering the events that comprise an incident, they
often discount the reality they are facing. This can’t happen, because we
use two-factor authentication. This isn’t a problem, because I’m sure the
DBA had a good reason for backing up those records. This shouldn’t happen,
because we encrypt our data — and so on.

It’s not a surprise that security teams often ignore false positives. Alert
overload is a real phenomenon, and people simply learn to ignore them. But
it’s just as likely that the team will miss the false negative, and swim
happily along until it’s too late and a breach occurs. It’s simply too
difficult to connect the dots that point to an attack, until after the
attack is complete.

Unlike the swimmer, security pros can’t afford to stay out of the water.
Instead, they need better tools to help navigate the overload of signals
that allow sharks to hide, often in plain sight.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170804/9051719a/attachment.html>