This is the fifth in a series of blogs that focus on sections of Demisto’s State of SOAR Report, 2019. You can read the other blogs by visiting the links below:
About the Report
Demisto commissioned a study with 552 respondents to find out specific challenges at each stage of the incident response lifecycle, how current product capabilities help overcome these challenges, and what capabilities are missing within security products today.
Defining the Security Incident Response Lifecycle
Every security team has its own set of security tools, competencies, common use cases, and compliance requirements. One of the few common threads that weaves across all these elements is the steps followed while responding to a security incident.
We defined the security incident response lifecycle as a continuous and cyclical process of incident ingestion and enrichment, incident management, deeper investigation, enforcement of response actions, performance measurement, and the adoption of lessons learnt to improve operational efficiency going forward.
Below, we will use phishing response as an example to outline each step in the lifecycle. This is merely illustrative; each lifecycle step can have more actions than the ones listed below.
Incident ingestion and enrichment: The email gets forwarded by a concerned employee to the organization’s quarantine mailbox. The security team studies the email and checks the reputation of indicators attached to the email (sender name and address, IP, domain, etc.).
Case management: The security team opens a ticket to capture the status for the phishing email. They mail the end user, confirming receipt of the forwarded phishing email. They add notes and comments to record their findings from the incident, measure SLAs for each step of investigation and response, and generate reports once the incident is resolved.
Incident investigation: The suspected phishing email has a PDF attachment. The security team detonates this file using a malware analysis tool and captures the results. They also check whether other end users were affected by the same phishing email, or emails that look like they’re part of the same phishing campaign.
Response and enforcement: Based on the data gathered during enrichment and investigation, the security team decides that the email is a verified phishing attempt. They send an email to the end user with this update, delete the email from all inboxes they can find, add IOCs to dynamic blocklists, and update the ticket assigned to the phishing email.
Performance measurement: The security team measures the Mean Time to Respond (MTTR) to the phishing incident and checks whether this time is within organizational SLA requirements. They also hold a debrief to discuss lessons learned from this incident: which actions were useful, which actions took the most time, and how they can better respond to similar incidents in the future.
Incident Investigation
Once incident triage has been completed, an attack investigation usually requires additional tasks such as pivoting from one suspicious indicator to another to gather critical evidence, drawing relations between incidents, poring over logs, and finalizing resolution.
Common Tools Used
We asked respondents what tools they commonly used for incident investigation.
.png?width=778&name=Fig%201%20-%20Common%20tools%20used%20(2).png)
Figure 1: Common tools used for incident investigation
SIEM tools occupied pole position in the results (Figure 1), with 66% of respondents citing them as critical consoles for investigation. Endpoint Detection and Response (EDR) tools and Network Traffic Analysis (NTA) tools also ranked well, selected by 63% and 53% of respondents respectively.
We can infer from these results that attackers leave breadcrumbs across sources. SIEMs, EDR tools, and NTA tools all ranked well for investigation, implying that attacks usually have unique signatures at different levels of security (the network level, the endpoint level, and so on). Unfortunately, it’s left to security teams to manually piece together data across these sources and create an overall picture of the attack.
Wish List of Capabilities
For incident investigation, we asked respondents to highlight product capabilities their tools possessed and create wish lists of capabilities their tools lacked.
Around 60% of respondents cited an ‘evidence board’ and ‘attack reconstruction’ as abilities they needed but currently lacked (Figure 2). Since investigation is usually a time-consuming and tool-spanning process, respondents also desired a common platform for cross-team investigation (53.54%) and automated remote execution of actions across security tools (52.36%).
.png?width=778&name=Fig%202%20-%20Tool%20capabilities%20(1).png)
Figure 2: Tool capabilities and wish lists for incident investigation
The common thread running across all these wished-for capabilities is the presence of disparate security tools that lack inter-connectivity. Security tools often provide unique value, but if these individual tool utilities don’t coalesce into a unified whole, security teams are left needing to cross-reference data across tools and lend structure to their chaotic investigations.
Stay tuned for more in-depth blogs on the State of SOAR Report, 2019. If you’re interested in learning more about SOAR, you can download our eBook – Security Orchestration for Dummies – below.
