This is the sixth 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:
- Overview of the report
- Hidden security challenges
- Incident ingestion and enrichment
- Case management
- Incident investigation
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.
Response and Enforcement
Response and enforcement are probably the most important and least discussed step in the security incident response lifecycle. After security teams are presented with rich, high-fidelity data by a host of security tools, there’s often a ‘so what?’ question that escapes their lips. If alerts are not met with action, the rows and columns of nuanced data count for nothing.
Common Tools Used
We asked respondents what tools they commonly used for response and enforcement.
Figure 1: Common tools used for response and enforcement
The results make for somber reading and underscore the challenges that security teams face today (Figure 1). 60.5% of respondents confessed to manually performing updates and blocks on point products. While 38% of respondents cited threat intelligence platforms as mechanisms for response, the ambit of these tools is relatively narrow and can’t cover the entire spectrum of necessary response and enforcement actions.
Fortunately, we found that SOAR tools have already begun to move the needle towards coordinated and automated response. Upon filtering only for respondents that used SOAR, we found that 60.5% DID NOT need to manually perform response actions on point products. This is an appreciable shift; moreover, the 40% can partially be accounted for by limited API functionalities of third-party products that don’t allow for every response action to be remotely executed from within SOAR products.
Wish List of Capabilities
For response and enforcement, we asked respondents to create wish lists of capabilities their current tools lacked.
Almost 54% of respondents cited the need for industry-specific response templates (Figure 2). Roughly 52% wished for live runs of playbooks for each incident and 47% asked for vendors to provide best-practice playbooks. These results highlight clear areas of improvement for SOAR tools, namely the need for standardization and user guidance. SOAR tools should strive for a balance between robust out-of-the-box content and the flexibility for users to easily create their own content.
Figure 2: Tool capabilities and wish lists for response and enforcement
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.