Alert Triage

To triage an alert a analyst generally needs to answer the following five questions. We may not need to answer every one of these questions every time, nor do we always tackle them in the same order.  In general, though, this is the process that we start from, and then adapt it on-the-fly to meet our needs.^[1]

1. Was this an actual attack? (True Positive or False Positive)
2. Was the attack successful? (Impact or No Impact)
3. What other assets were compromised? (Scoping the Incident's assets)
4. What activities did the attacker carry out? (Timelining the events)
5. How should my organization respond to this attack? (Containment and Remediation)

Usually the pain points for these steps are missing:

• contextual information
• access to related guidance
• assets inventory

Was this an actual attack?

As an industry, no one has yet figured out how to eliminate all the false positive (FP) alerts while still keeping all the true positive (TP) alerts. Given that we know that there will be FPs (probably a substantial percentage of them), we need to make it as easy as possible for the analyst to distinguish between FP and TP, and to do it quickly.

Was the attack successful?

Here we need to assess if the attack was successful and whether it impacted any of the CIA Triad.

What other assets were also compromised?

The first step when determine the scope of the incident is to assemble a list of assets involved. Assets in this case is anything that an attacker would want to attack, compromise or steal: computers, network devices, user accounts, email addresses, files or directories, etc.

The asset list will almost certainly change over the course of the incident, as new information comes to light during the course of the investigation.

The keys to helping analysts deal with asset tracking are:

• Creating a template "asset list" that can be cloned for each alert/incident to track compromise status.  At a minimum, you probably need to track the following info for each asset
  • Asset name (hostname, username, email address, etc)
  • Date/time the attacker was first known to interact with that asset
  • Date/time the attack was last known to interact with that asset
  • Date/time an analyst detected the activity
  • Date/time the asset was added to the list
  • Date/time the analyst investigated the asset and determined it to be compromised or not
  • The results of that investigation (often COMPROMISED, NOT COMPROMISED, PENDING ANALYSIS)
  • Brief notes about the investigative findings
• Sharing this list with other responders, in such a way as to make it easy to interact with (e.g., via a wiki)

What activities did the attacker carry out?

What did the attacker try to do, when, and to what? The asset list answers the "to what" question, but even that needs to get put into context.

To help answer these questions, incident responders typically create timelines of the significant events that occur during the attack and the IR.  For example, you might start with a simple chart that calls out the highlights of the incident, with dates and times for:

• The attacker's first exploit attempt
• All the alerts generated by the attack
• When the alerts were triaged and escalated to incidents
• When the affected asset(s) were contained
• When the affected asset(s) were remediated
• When the incident was closed

How should my organization respond to this attack?

Once you have assembled the list of compromised assets and the timeline of events, you exit the scoping phase and are ready to begin planning your incident response strategy. A well-managed team will have a number of standard incident response plans aka playbooks ready to go, but even then they often need to be tailored to the individual incident. In most a cases, a typical strategy involves containment followed by remediation.

After the initial response, the steps Report and Improve outlined in the Defense Chain should also follow.

Relevant Note(s): Incident Response