Jumpstart Incident Response

The people have spoken. “We want [real] alert relief”.

In my previous post, Never let your guard down, I emphasized the need for a security operation process to better face known and unknown attacks with automation and hunting. However, I intentionally left out a key ingredient… THE ALERT (or incident or indicator or investigation or whatever you call it). Before an analyst can make a decision and assign an appropriate course of action (automated or manual), they need to understand what they’re looking at, where the alert came from, what triggered the alert, who is involved, what is involved (e.g. server, host), were there any similar alerts in the past, … you get the point. The major challenge in answering these questions lies in the current state of siloed bursts of context-unaware alerts and the transition to context-aware incident management. There is an obvious need to give THE ALERT, some well-deserved, first-class citizen treatment!

Looking back about twenty years ago, security analysts were also outnumbered by the volume of alerts generated. However, one (huge) difference was the attack surface. The increasing attack surface across cloud infrastructure-as-a-service (IaaS) and cloud applications (SaaS), mobile, virtualization, BYOE(ndpoint), Industrial Control Systems (ICS) and general OT environments is more open than ever. This triggered an exponential growth in alerts created. The capabilities to support that explosion of alerts (what we all know as alert fatigue) lagged behind.

Which led me to ask, what are the most common actions a security analyst, regardless of skillset, performs against every alert, or at least wants to perform against every alert if they could?

SOC analyst: “Not sure I follow. Can you give me an example?”

RSA: “Sure! How often do you perform the following actions when a new alert is triggered and prioritized to the top of the SOC queue?

  • Evidence collection (e.g. authentication, DHCP, network sessions, MFT, memory dump, etc.)
  • Identify user/machine AND user/entity correlation
  • Business enrichment (e.g. GeoLocation, user department)
  • User governance (VIP, executive, privileged like admin, DBA, watch/blacklist, contractor)
  • “Back-coloring” against history data (repeat offender, related alerts)
  • Threat Intel matching (in-house and 3rd party)

Wouldn’t you want to automate several – if not all – of those actions? I am not yet referring to response actions. Rather, how can I better improve the analyst’s position by saving time in collection, enrichment, hunting, and the most critical – building the attack timeline of the before, during, and after? Leveraging alert and enrichment automation reduces analyst waste-time and provides a better jumpstart against both commodity and advanced attackers. Reading this, some might say following this methodology only results in locking the analyst in a box. I argue it’s the exact opposite. Once in possession of this critical data, creativity will thrive, as will understanding the bigger picture, enabling analysts to shift from alert “whack-a-mole” to a strategic thinker.

Two additional aspects to look for in alert automation are documentation and metrics. How much time do you spend documenting all steps taken during an alert investigation – both actions you took and the output? The answer is simple. Too much. If you have already automated all of the items listed, do you need to spend time documenting it? Aren’t those steps automatically documented as well? And as for metrics, the icing on the cake, how do you measure your success? Are you [the SOC] getting better at dealing with and managing alerts? Are you therefore capable of investigating more? Maybe, but the question concerning me the most is – are you focusing on the most critical alerts? Time will tell. However, as long as SOCs follow this methodology to jumpstart their analyst in a consistent manner, to automate what they can, we’re getting a step closer.

There is no one-size-fits-all solution, and every organization needs their own processes. However, learning from the best practices of others is a good idea. Come learn from us!

# # #

SIEM, Network-Analysis, Forensics, EDR, UEBA, Threat Intel, Orchestration and Automation. Validate that YOUR SIEM CAN DO THIS!

 



*** This is a Security Bloggers Network syndicated blog from RSA Blog authored by Maor Franco. Read the original post at: http://www.rsa.com/en-us/blog/2018-03/jumpstart-incident-response.html