Incident Response Playbooks For SOC Use Case — Part 1
What is an IR Playbook?
This is a set of rules that describes at least one action to be executed with input data and triggered by one or more events.
For any Cyber Threat or Attack, the SOC team has to go through the following 3 high-level processes, sequentially: -
Detection: This phase contains a set of sub-processes with structured steps to monitor the network, SIEM, and capture indicators.
Analysis: The analysis phase will similarly have sub-processes, for example, a WHOIS IP lookup, malware analysis using a sandbox, and gathering indicators for analysis.
Remediation: This phase will contain multiple sub-processes for cleaning the assets, blocking the bad IP, and banning the malware hash in the endpoint tool. All these playbooks can be executed at once, covering all the affected assets.
When to Use an Incident Response Playbook
You should build an incident response playbook for major cybersecurity events that need clear steps and procedures. Some examples include:
- Ransomware Attacks
- Phishing Attacks
- Malware Infections
- Compromised Applications
- Distributed Denial of Service (DDoS)
Incident Response Playbook for Phishing Attacks
Incident Response to Analyze Suspicious Emails
Incident Response Process for Firewall Alert — Unknown URLs
Incident Response Process for examining and alerting on USB media use.
Incident Response Steps to Mitigate Compromised Device
The process of identifying a compromised device on a network and restoring the device to an authorized state.
Incident Response Playbook for Stolen Device
Ransomware Incident Response Playbook
Step 1: Ransomware Incident-Response-Plan-Preparation
In the preparation phase, the company or the incident response team must realize that malicious actors often use phishing to infect a system with ransomware; hence, it is very important to have a phishing policy.
Step 2: Ransomware Incident-Response-Plan-Identification
It is highly recommended as a best practice to use threat intelligence sources to detect and alert you of anomalies in your network traffic that could be associated with ransomware.
Perform continuous anti-virus and overall endpoint security scans, to detect and discover unusual registry keys, malicious files, encrypted data, unusual directories, unusual amounts of internet traffic flow, unexplained system crashes, unauthorized and unexplained installation of software. Check the anti-virus notifications, scans, and Windows Event Logs for more details about the malicious activity. Request system updates and patches.
Step 3: Ransomware Incident-Response-Plan-Containment
If any suspicious or malicious activity is detected after the identification phase, we can assume that there is a high probability that malware is present on the endpoint, and the endpoint must be quarantined and isolated from the network to prevent the spread to other endpoints and the overall infrastructure.
Identify affected assets and perform containment, you must ensure that any communication with the affected device and potential threat source is isolated and contained, for that purposes the following is recommended:
- Block external IP address
- Block external domain
- Block external URL
- Block domain on email
- Block the sender on the email
- Quarantine email message
- Physically isolate the infected computer from the network.
- Revoke the user account’s access to shares.
- No need to turn off the host, as it will not prevent anything, instead ensure that file modifications are alerted and prevented by appropriate cyber solutions such as DLP and FIM.
- Re-configure the Firewall and NAC Solution as well as the host-based firewall to block the connection with the internal network for temporary purposes, until the full identification process is done, and malicious C&C is detected and disconnected
- Identify the vulnerability that caused exploitation and contain it.
- Continue intensive monitoring to ensure any malicious activity and malicious files, and most importantly eliminate the chance of backdoor entrance for bad actors.
- Perform documentation and inform stakeholders, and users about the incident.
Step 4: Ransomware Incident-Response-Plan-Remediation
In order to remove ransomware from an IT environment, it must first be recognized using antivirus software, different malware removal programs, or manually by searching through registries and looking for unusual file extensions.
If the malicious file is not detected by signature-based detection, it can be sent to the sandbox for more effective detection. the recommended practice is to replace compromised machines rather than clean them.
Service Level Response Overview
Incident Response Priority Levels will analyze each event to determine the event’s priority level. The priority level will determine which response is appropriate for the event.
P1 — High Priority: Critical event affecting loss of client data
Examples:
- Ransomware or another malware
- Successful SQL injection with loss of data
- Successful phishing attack with verified credential compromise or malware installed
- Response: Immediate notification via phone with a follow-up email for details
P2 — Medium: Attack on likely vulnerability with no immediate loss of client data
Examples:
- Sinkhole DNS address associated with malware
- BruteForce login attempts over 100,000
- Successful phishing landing without verified credential compromise or malware
- Response: Email notification and call during business hours if no response after 30 minutes
P3 — Low: Failed attacks, concerning behavior
Examples:
- P2P Software Usage
- Unsuccessful phishing attack
- Response: Email notification
P4 — Info: Environmental events that could lead to vulnerabilities
Examples:
- NMAP Portscan
- Failed exploit attempt
- Vulnerable services and outdated software
- System processes sending unencrypted passwords internally
- Response: Include in a weekly report for client review until indicated otherwise
Service-level-responsibilities
Service-level-response-Workflow
Mitigate Compromised Local Administrator Credential
SANS Incident Response Summarized Process and Activities
Conclusion
An incident response playbook is a set of rules that describes at least one action to be executed with input data and triggered by one or more events.
To construct an incident response playbook:
- Identify the initiating condition.
- List all possible actions that could occur in response to the initiating condition.
- Categorize all possible actions into: “required” when must occur to mitigate the threat, or “optional” when considered more of a best practice.
- Build the playbook process order using only the “required” elements determined in step 3.
- Determine if steps from the “optional” category can be grouped by activity or function (e.g., monitoring, enriching, responding, verifying, or mitigating).
- Modify the process created in step 4 to indicate where any optional processes would occur.
- Insert the categorized optional actions into the options box below the process steps box.
- Identify the end state or another initiating condition to another playbook.
- List the regulatory laws and requirements that the playbook satisfies.
References
- https://swimlane.com/blog/incident-response-playbook
- https://www.incidentresponse.org/playbooks/malware-outbreak
- https://www.incidentresponse.org/open-source-playbooks/
- https://www.iacdautomate.org/playbook-and-workflow-examples
- https://www.hawk-eye.io/2020/11/ransomware-incident-response-plan-part-1/
- https://www.hawk-eye.io/2020/12/ransomware-incident-response-plan-part-2/
- https://frsecure.com/ransomware-response-playbook/
- https://frsecure.com/malware-incident-response-playbook/
- https://frsecure.com/compromised-credentials-response-playbook/
