Internal Indicators Of Compromise: Understanding Your Data

The threat landscape is constantly evolving.  The skillsets and techniques used by adversaries constantly evolve in terms of sophistication and efficacy.  There's an arms race going on, and offensive capabilities tend to be outstripping defensive controls.

Some ubiquitous threat actors, such as those criminal gangs running ransomware operations, may not care too much about what data you have within your network.  Most organisations are targeted by a range of threat actors, however, and some may be highly driven to gain access to your assets.

It's not enough to put preventative controls in place and assume that a compromise will not happen.  In this hostile landscape, being able to quickly detect a compromise in progress so that you and your teams can effectively respond is critical.

Perimeter detective controls tend to be well-defined.  A proxy will be used for all web traffic, which monitors connections and can be used to detect malware beaconing activity, for example.  DLP solutions will be in place which will look to analyse traffic moving out of the organisation and identify sensitive data being removed.  But what about detecting the compromise on the inside?

As information security consultants, we often find ourselves working with IT departments who are trying to implement internal detective mechanisms for indicators of compromise.  

What Are You Looking For?

The answer to that critical question is that you are seeking any kind of anomalous behaviour which can't be tracked back to legitimate business use, or correlated with change control for example.  That is an enormous set of possible events!

In large enterprises, sufficient resources might be available to map internal processes and baseline 'normal use' thoroughly; budget may exist to implement a dedicated toolkit aimed at anomaly detection, and a team to monitor and configure these toolsets.  For most businesses, though, operational technical teams are limited in time and resources, and the ideal 'gold standard' may not be a realistic goal.  Focusing effort when it comes to detective controls when you have limited resources, and limited funds, can be a challenge.  So how can you decide what is important to monitor internally?

One obvious area to look at is monitoring the use of privileged accounts.  It stands to reason that systems administrators with elevated privileges are a popular target for attack; these users are typically able to access all assets within the environment, and can grant themselves access to protected data assets at will.  When these privileged accounts start to exhibit unusual behaviour (for example, accessing new systems, logging in at unusual times, making changes to configurations without a change control record), this is an obvious red flag which begs for further investigation.  New accounts being created, or added to sensitive groups (such as the Domain Admins group) should also raise alarms in most cases.

During our consultancy work, we often work with operational system management teams who have put together a great set of rules for alerting on changes to privileged account memberships in Active Directory.  In many cases, we also work with teams who have put good logging and alerting in place to identify their privileged accounts making unusual requests or accessing systems that they don't normally access.

It's easy to focus on privileged account and groups:  they are well-defined, and universally understood.  But privilege isn't necessarily the endgame for your attacker.  In fact, if you are facing a skilled and motivated adversary, privilege, as most systems administrators use the term, is largely irrelevant.

Consider:

• A manufacturer, working on a contract for the defence industry.  Blueprints and designs of products in development have value to foreign nation states and competitors in the market.
• A retailer, handling the payment card details of thousands of customers.  Payment card details are routinely sold by criminals and hence have value.
• A healthcare provider, processing the sensitive personal information of patients within information systems.  Personal information is similarly routinely sold on.

In each case listed above, data is the key asset which has value to the attacker, not system privileges.  As an attacker, if you can compromise a standard user with access to sensitive data, there is never any need to gain elevated system privileges in order to obtain your goals.

If you want to protect your data, you need to know:

• What data do you hold, and what value might it have to an attacker?
• Who has access to that data during business as usual, and under what circumstances?
• What access routes to that data exist within your organisation?
• What does normal business access to your data look like?

This may well sound obvious, but if you understand the answers to these questions, your teams can focus their resources on setting up detective alerts which 'ringfence' your sensitive data assets and identifying the important anomalies that might indicate a compromise. 

This isn't something that operational systems teams can embark upon in isolation; you need stakeholders and system owners throughout the business to be involved in identifying and understanding what data is 'important' and how normal business 'looks'.

Privilege is important, but being able to detect an incident internally hinges on your understanding of your data.