This is the fourth 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.
During incident response, security teams have scores of balls up in the air. As they quickly transition across consoles to gather additional context and contain the incident, it’s critical for them to have central case management capabilities and avoid fragmented documentation.
Common Tools Used
We asked respondents what tools they commonly used for case management.
Figure 1: Common tools used for case management
Results (Figure 1) show almost 70% of respondents entrusting their case management to ticketing solutions. Since ticketing systems often span across teams (IT, security, support, and so on), it makes sense for central management to occur on these tools. The caveat here is that ticketing systems sometimes lack in depth what they possess in breadth. Security-focused case management tools can make up the difference. These tools ranked second in the results, proving the tool of choice for around 36% of respondents.
‘Manual processes’ ranking third on this list with 35.4% of the vote might raise some eyebrows, but this is a reality that security organizations are resigned to as long as tool sets lack interconnectivity.
Wish List of Capabilities
For case management, we asked respondents to highlight product capabilities their tools possessed and create wish lists of capabilities their tools lacked.
More than 60% of respondents wished for tools that automatically captured information for post-incident review (Figure 2). A mobile application for incident management was also desirable, with 47% of respondents including it in their wish list and only 25% of respondents claiming to have mobile support from their current products. Other capabilities in demand included the ability to add notes and tags to individual artifacts (51.27%) and the ability to reconstruct incident timelines (51.27%).
Figure 2: Tool capabilities and wish lists for case management
We can surmise from the results that data collection and summarization during incident response is still too manual and fragmented, preventing security teams from performing at maximal efficiency. Many of the ‘wished for’ capabilities (reconstructing incident timelines, adding tags and notes to artifacts) seem like they would be better fulfilled by a more security-focused tool than general-purpose ticketing systems.
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.