This is the third 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 Ingestion and Enrichment
Organizations today have employees, computing resources, and customers spread across the world, resulting in a corresponding increase in the threat surface they must contend with. In order to respond to incidents, security teams need to discover that there’s an incident in the first place. This is no mean task.
Common Tools Used
We asked respondents what tools they commonly used for incident ingestion and enrichment, allowing for multiple options due to the disparate nature of incident detection in today’s security landscape.
Figure 1: Common tools used for incident ingestion and enrichment
The most striking data point from the responses (Figure 1) was the prominence of Security Information and Event Management (SIEM) tools, with around 75% of respondents citing these tools as important sources for incident ingestion and enrichment. SIEMs have a range of capabilities – monitoring machine data across sources, prioritization and aggregation, and rules for adapting detection with time – that are critical for incident ingestion and enrichment, so we believe SIEMs’ importance to be well-merited here.
However, around 67% of respondents stated that they used email tools to ingest phishing incidents and roughly 66% of respondents highlighted malware analysis tools as important ingestion and enrichment sources. These results imply some limitations that SIEM tools have, namely that SIEMs are not used as a sole detection source for all incidents and that they lack the niche capabilities that other tools (like malware analysis) possess.
Wish List of Capabilities
For incident ingestion and enrichment, we asked respondents to highlight product capabilities their tools possessed and create wish lists of capabilities their tools lacked.
The results (Figure 2) underline the need for automation and correlation while ingesting and enriching incidents. Only 34% of respondents claimed to have ‘automated data enrichment’ capabilities in their current products and 56% of respondents made it a part of their wish list. Around 48% of respondents wished for ‘automated prioritization of alerts’ and 47.5% of respondents cited the need for ‘correlation of alerts and indicators across products’.
Figure 2: Tool capabilities and wish lists for incident ingestion and enrichment
These figures throw into sharp relief the sheer amount of manual work security teams need to do while conducting incident triage. While we acknowledge all the heavy lifting that SIEMs do here, there are still two challenges to contend with:
- Too many false positives: It’s always safer to set the sensitivity levels of SIEMs higher than necessary, lest any serious incident slip through the cracks. The downside of this caution is a ballooning number of false positives that analysts must manually study and cast away.
- Multiple detection sources: The threat surface is simply too large and varied for SIEMs to be the only tool for incident ingestion. The problem with multiple tools for incident ingestion (email inboxes, malware analysis, cloud security, etc.) is the manual post-incident correlation that security teams must perform to uncover larger attack campaigns.
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.