APPENDIX K:

50 SPLUNK
SOAR GUIDED
AUTOMATION

BY IZZMIER IZZUDDIN
LIST OF USE CASES

1. Automated Threat Intelligence Enrichment

2. Ransomware Detection and Mitigation
3. Phishing Email Investigation and Response
4. Malware Detection and Containment on Endpoint
5. Insider Threat Detection and Management
6. Data Exfiltration Monitoring and Response
7. Brute Force Attack Mitigation
8. Suspicious Login and Access Investigation
9. Endpoint Detection and Response (EDR) Automation
10. Cloud Security Incident Handling
11. Cryptojacking Detection and Mitigation
12. DNS Tunneling Attack Investigation
13. Advanced Persistent Threat (APT) Detection
14. Zero-Day Vulnerability Response
15. Compliance Audit Automation
16. API Abuse and Security Monitoring
17. Threat Hunting Workflow Automation
18. Denial-of-Service (DoS) Attack Response
19. Third-Party Risk Management and Monitoring
20. Automated Vulnerability Patch Management
21. Credential Harvesting Detection and Response
22. Unauthorised File Access Monitoring
23. Social Engineering Attack Prevention
24. Dark Web Monitoring and Alerting
25. Network Anomaly Detection and Response
26. Automated Privilege Escalation Detection
27. IoT Device Threat Monitoring and Mitigation
28. Supply Chain Attack Detection
29. Password Spray Attack Response
30. Mobile Device Threat Monitoring
31. Web Application Attack Mitigation
32. SIEM Alert Noise Reduction
33. Automated Incident Escalation
34. Fraudulent Transaction Detection
35. Critical Asset Access Monitoring
36. Privileged Account Misuse Detection
37. Automated Compliance Reporting
38. Third-Party Integration for Threat Intelligence
39. Account Compromise Detection and Mitigation
40. API Security Threat Analysis
41. Exploit Attempt Monitoring
42. Machine Learning Model Drift Detection
43. Automated Forensic Investigation
44. Distributed Denial-of-Service (DDoS) Response
45. Zero Trust Architecture Automation
46. Sensitive Data Access Alerting
47. Automated Risk Scoring for Incidents
48. Privileged Session Recording and Analysis
49. Rogue Access Point Detection
50. Automated Response Playbook Testing
SIMULATIONS

Use Case 1: Automated Threat Intelligence Enrichment

Step 1: Define the Use Case

• Use Case Name: Automated Threat Intelligence Enrichment

• Description: Automates enrichment of IOCs (IPs, URLs, hashes) from alerts using
external threat intelligence sources like VirusTotal.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Click Automation > Playbooks > Create New Playbook.
2. Select Visual Editor: Choose the drag-and-drop visual editor for ease of use.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger node to detect new alerts in the connected SIEM (Splunk,
QRadar).
o Configure the trigger to activate when an alert with IOCs (IPs, URLs, hashes)
is received.
2. Extract IOCs Node:
o Use the Artifact Extraction action to parse IOCs from the alert.
o Extract indicators such as suspicious IPs, URLs and hashes.
3. VirusTotal Enrichment Node:
o Add an Action node.
o Configure it to call the VirusTotal API for reputation checks on extracted
IOCs.
o Input the IOC data into the API request.
4. Decision Node:
o Add a decision node to check the threat score or reputation from VirusTotal.
o Example:
§ If the score > 75, mark it as "High Risk."
§ If the score ≤ 75, mark it as "Low Risk."
5. Update Case Node:
o Add an Update Artifact action to enrich the original alert with data retrieved
from VirusTotal.
6. Notify Analyst Node:
o Add a Send Email action to notify the SOC analyst with a summary of
findings.
Step 4: Save and Test the Playbook

1. Simulate Alert:
o Use Splunk SOAR’s simulation environment to generate a mock alert with a
malicious IP (192.168.1.100).
2. Run the Playbook:
o Observe the workflow executing step-by-step:
§ Alert triggers extraction of the IOC.
§ VirusTotal API is queried, returning the IP's reputation (malicious, with
a threat score of 85).
§ The alert is updated with enrichment data.
§ A notification email is sent to the analyst.
3. Review Output:
o Check the enriched alert in the case management system.
o Confirm data accuracy and notification delivery.

Step 5: Deploy the Playbook

1. Assign the playbook to a production environment.

2. Set the trigger to monitor SIEM alerts in real-time.

Step 6: Monitor Performance

1. Track metrics such as:

o Time to Enrich Alerts: Verify enrichment occurs in under 2 minutes.
o Analyst Feedback: Ensure the data provided helps prioritise incidents
effectively.
2. Use Splunk SOAR’s dashboard to visualise playbook performance over time.
Use Case 2: Ransomware Detection and Mitigation

Step 1: Define the Use Case

• Name: Ransomware Detection and Mitigation

• Objective: Detect ransomware activity, isolate affected endpoints and notify the
response team.
• Priority: Critical (prevent ransomware spread).

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Click on Automation > Playbooks > Create New Playbook.
2. Choose Editor:
o Select the drag-and-drop visual editor for ease of workflow creation.

Step 3: Build the Workflow

1. Trigger Node:
o Add a trigger to listen for ransomware-related alerts from the SIEM.
o Example trigger condition:
§ Alert type: File activity anomaly (mass encryption or file extensions
like .lock).
§ Alert source: Endpoint Detection and Response (EDR), e.g.,
CrowdStrike, Carbon Black or Splunk.
2. Enrichment Node:
o Use VirusTotal API to analyse suspicious file hashes or domains associated
with the alert.
o Append reputation scores and threat intelligence data to the alert.
3. Isolate Endpoint Node:
o Integrate with EDR tools (CrowdStrike) to issue a "Network
Quarantine" command for the infected endpoint.
o Configure the node to include:
§ Hostname or IP of the infected system.
§ Confirmation of isolation status.
4. File Backup/Recovery Node:
o Check if shadow copies or backups exist on the affected endpoint using
PowerShell scripts or native EDR capabilities.
o Attempt recovery if available.
5. Notification Node:
o Use the Send Email or Send Message action to notify the incident response
team about:
§ Affected endpoint details.
§ Enriched IOC data.
 § Actions taken (isolation, backup recovery attempt).
6. Decision Node:
o Add a Decision Node to escalate or close the alert:
§ Escalate: If the alert is confirmed as ransomware.
§ Close: If the alert is a false positive.
7. Forensic Collection Node (Optional):
o Use endpoint tools to collect forensic evidence, such as memory dumps or
disk images, for further analysis.

Step 4: Test the Playbook

1. Simulate a Ransomware Alert:

o Create a mock SIEM alert indicating:
§ Host: HOST123.
§ Event: Files encrypted with .encrypted extension.
§ IOC: Suspicious file hash abc123hash.
2. Run the Playbook:
o Observe the automation process:
§ Alert is enriched with VirusTotal results.
§ Endpoint is isolated.
§ Notification is sent to the incident response team.
3. Validate Results:
o Confirm endpoint isolation in the EDR dashboard.
o Check the enriched alert in the case management system.
o Review the notification for completeness.

Step 5: Deploy in Production

1. Assign the playbook to handle ransomware-related alerts automatically.

2. Monitor the playbook’s performance in live scenarios.

Step 6: Measure Success

• KPIs:
o Time to isolate endpoint: Target <1 minute.
o Ransomware spread prevention: Target 100%.
o Accuracy of detections: Target >95%.
• Use Splunk SOAR’s built-in dashboards to analyse playbook performance and make
improvements.
Use Case 3: Phishing Email Investigation and Response

Step 1: Define the Use Case

• Name: Phishing Email Investigation and Response

• Objective: Automate the identification, investigation and mitigation of phishing
emails to reduce response time and prevent malicious activity.
• Priority: High (critical to stop potential compromise).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Email Gateway (Microsoft Exchange, Proofpoint).
o Threat Intelligence platforms (VirusTotal, URLhaus).
o SIEM (to correlate email-related alerts).
• Integrations in Splunk SOAR:
o Email client (Microsoft Exchange).
o Threat intelligence (VirusTotal for IOC reputation).
o Sandbox (Cuckoo or Joe Sandbox for attachment analysis).

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In the Splunk SOAR interface, go to Automation > Playbooks and create a
new one.
2. Name the Playbook:
o Title: "Phishing Email Investigation and Response."
o Select Visual Editor for creating the workflow.

Step 4: Build the Workflow

1. Trigger Node:
o Configure a trigger to activate the playbook when an email is flagged as
suspicious.
o Trigger source: Email Gateway (Proofpoint alert or a reported phishing
email).
2. Email Parsing Node:
o Use the "Get Email" action to extract:
§ Subject.
§ Sender address.
§ Email body.
§ URLs and attachments.
3. IOC Enrichment Node:
o URL Analysis:
 § Send URLs from the email to VirusTotal or URLhaus for reputation
scoring.
o Attachment Analysis:
§ Submit suspicious attachments to a sandbox (Joe Sandbox) for
behavioral analysis.
o Append results (malicious/benign verdicts) to the email artifact.
4. Decision Node:
o Add a decision point:
§ If IOC is flagged malicious: Proceed with mitigation actions.
§ If IOC is benign: Close the ticket as a false positive.
5. Mitigation Node:
o Use email integration to:
§ Quarantine the malicious email in the user’s inbox.
§ Block the sender’s email domain in the Email Gateway.
o Use SIEM integration to:
§ Search for similar emails across the organisation and quarantine
them.
6. Notification Node:
o Notify the affected user and the Incident Response team:
§ User Notification: Warn the user about the phishing email and
confirm it is quarantined.
§ IR Team Notification: Include details of the investigation, including:
§ IOC results.
§ Actions taken.
§ Any spread within the organisation.

Step 5: Test the Playbook

1. Simulate a Phishing Email:

o Create a mock email with:
§ Subject: “URGENT: Reset Your Password.”
§ Sender: [email protected].
§ URL: http://malicious-site.com.
§ Attachment: invoice.zip.
2. Run the Playbook:
o Validate the steps:
§ Email is parsed to extract artifacts.
§ URL reputation check flags it as malicious.
§ Attachment sandbox analysis confirms malware.
§ The email is quarantined and the sender is blocked.
§ Notifications are sent to the user and IR team.

Step 6: Deploy in Production

 1. Assign the playbook to handle all phishing-related alerts from the email gateway
automatically.
2. Monitor the playbook’s execution in live scenarios.

Step 7: Measure Success

• KPIs:
o Time to quarantine phishing email: Target <5 minutes.
o Number of false positives identified.
o Total phishing attempts mitigated.
• Use Splunk SOAR’s dashboards and reports to analyse the playbook’s performance
and make necessary optimisations.
Use Case 4: Malware Detection and Containment on Endpoint

Step 1: Define the Use Case

• Name: Malware Detection and Containment on Endpoint

• Objective: Automate the detection, analysis and containment of malware on
endpoints to reduce response time and minimise damage.
• Priority: High (critical to prevent lateral movement or further compromise).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Endpoint Detection and Response (EDR), e.g., CrowdStrike, SentinelOne.
o Antivirus/Antimalware solutions, e.g., Symantec, Trend Micro.
o Threat Intelligence platforms, e.g., VirusTotal, Hybrid Analysis.
• Integrations in Splunk SOAR:
o EDR (CrowdStrike for isolating endpoints).
o Threat Intelligence (VirusTotal for IOC reputation checks).
o Sandbox (Joe Sandbox for behavioral analysis).

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "Malware Detection and Containment on Endpoint."
o Use the Visual Editor for workflow creation.

Step 4: Build the Workflow

1. Trigger Node:
o Configure the trigger to activate the playbook when a malware detection
alert is generated by the EDR or antivirus system.
o Example source: EDR alert for suspicious file execution or flagged
processes.
2. Enrichment Node:
o File Hash Analysis:
§ Extract the hash of the suspected malware file and query VirusTotal or
Hybrid Analysis for its reputation.
o Behavioral Analysis:
§ If the file hash is unknown, submit the file to a sandbox (Joe Sandbox)
for dynamic analysis.
o Process Analysis:
 § Use EDR integration to analyse running processes on the affected
endpoint and identify anomalies.
3. Decision Node:
o Add a decision point based on enrichment results:
§ If the file/process is malicious: Proceed with containment actions.
§ If benign: Close the alert as a false positive.
4. Containment Node:
o Isolate Endpoint:
§ Use EDR to isolate the affected endpoint from the network to prevent
lateral movement.
o Terminate Malicious Processes:
§ Kill the identified malicious processes using EDR commands.
o Delete Malicious Files:
§ Use antivirus integration to remove the malicious file(s).
5. Mitigation Node:
o Update Threat Feeds:
§ Add the malicious file hash, domain or IP to the blocklist in firewalls
or EDR policies.
o Patch and Hardening Recommendations:
§ Run vulnerability scans on the endpoint and recommend patching or
configuration changes to prevent similar attacks.
6. Notification Node:
o Notify the Incident Response (IR) team and SOC:
§ Details of the malware.
§ Actions taken (isolation, process termination, file deletion).
§ Recommendations for further remediation.
7. Post-Incident Action Node:
o Run a comprehensive malware scan on the isolated endpoint.
o Collect forensic artifacts (memory dump, logs) for deeper analysis.

Step 5: Test the Playbook

1. Simulate a Malware Infection:

o Create a mock alert:
§ Endpoint: HOST002.
§ File: malicious.exe.
§ File hash: ab12cd34ef567890.
o Verify the playbook:
§ Enrichment confirms the file as malicious (reputation score on
VirusTotal).
§ Endpoint is isolated.
§ Malicious process is terminated.
§ File is deleted and threat feeds are updated.
Step 6: Deploy in Production

1. Assign the playbook to handle all malware-related alerts from EDR and antivirus
systems automatically.
2. Monitor its execution and performance in live incidents.

Step 7: Measure Success

• KPIs:
o Time to detect and contain malware: Target <10 minutes.
o Reduction in lateral movement attempts.
o Number of malware infections successfully mitigated.
• Use Splunk SOAR’s built-in dashboards to track and analyse playbook
performance.
Use Case 5: Insider Threat Detection and Management

Step 1: Define the Use Case

• Name: Insider Threat Detection and Response

• Objective: Automate detection, investigation and mitigation of insider threats to
prevent unauthorised data access, exfiltration or system compromise.
• Priority: High (due to the risk of data breaches or intentional sabotage).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o User behavior analytics (UBA) systems for anomaly detection.
o SIEM for suspicious activity alerts (unauthorised file access, abnormal
working hours).
o DLP (Data Loss Prevention) tools for data exfiltration monitoring.
o File servers and collaboration tools (SharePoint, OneDrive) for access logs.
• Integrations in Splunk SOAR:
o UBA tools for suspicious user activity detection.
o SIEM platforms like Splunk Enterprise Security.
o Endpoint detection and response (EDR) tools for monitoring user endpoints.
o Identity and access management (IAM) systems for user account details and
privilege changes.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks in Splunk SOAR and click Create Playbook.
2. Name the Playbook:
o Title: "Insider Threat Detection and Response."
o Use the Visual Editor to build the workflow.

Step 4: Build the Workflow

1. Trigger Node:
o Configure the playbook to trigger on alerts for insider threats detected by
UBA or SIEM, such as:
§ Abnormal access patterns.
§ Large file downloads.
§ Access to sensitive files outside of working hours.
2. Enrichment Nodes:
o User Profile Analysis:
§ Fetch user account details from IAM systems (role, privileges, recent
activity).
 o Behavioral Analysis:
§ Compare the user’s activity against baseline behavior using UBA
tools.
o File Access Analysis:
§ Investigate accessed files for sensitivity and classification levels.
o Endpoint Activity Check:
§ Query EDR tools for suspicious activity on the user’s endpoint.
3. Decision Node:
o Add decision points based on enrichment results:
§ If activity is confirmed malicious: Proceed to containment actions.
§ If activity is suspicious but inconclusive: Escalate for manual
investigation.
§ If activity is false positive: Close the case.
4. Containment Nodes:
o Revoke Access:
§ Disable the user account or restrict access to sensitive systems using
IAM systems.
o Isolate Endpoint:
§ Use EDR tools to isolate the user’s device from the network.
o Audit Log Retention:
§ Ensure all activity logs are stored for forensic analysis.
5. Mitigation Nodes:
o Notify Management:
§ Alert the security and HR teams for further action.
o User Education:
§ If activity was non-malicious (negligence), schedule a security
awareness training session for the user.
6. Post-Incident Action Nodes:
o Threat Intelligence Update:
§ Add any discovered IOCs or patterns to insider threat detection
systems.
o Policy Review:
§ Recommend changes to access policies or monitoring thresholds if
gaps are identified.
o Incident Reporting:
§ Automatically generate a report summarising the incident, actions
taken and outcomes.

Step 5: Test the Playbook

1. Simulate Insider Threat Scenario:

o Mock Incident:
§ User "John Doe" downloads a large number of sensitive files from
SharePoint at 2 AM.
 o Playbook Execution:
§ The user’s activity triggers an alert.
§ Enrichment reveals that John Doe is not authorised to access these
files.
§ The user account is disabled and the endpoint is isolated.
§ HR and security teams are notified and a detailed report is generated.

Step 6: Deploy in Production

1. Automate the playbook to run on UBA or SIEM alerts related to insider threats.
2. Regularly update the playbook to account for new insider threat patterns.

Step 7: Measure Success

• KPIs:
o Time to detect and contain insider threats: Target <30 minutes.
o Reduction in unauthorised data access incidents.
o Number of false positives flagged and resolved.
Use Case 6: Data Exfiltration Monitoring and Response

Step 1: Define the Use Case

• Name: Data Exfiltration Monitoring and Response

• Objective: Automate detection, investigation and mitigation of unauthorised data
exfiltration attempts to safeguard sensitive information.
• Priority: Critical (to prevent data breaches and regulatory violations).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Network monitoring tools for unusual outbound traffic (large file transfers).
o DLP systems for tracking sensitive data movement.
o SIEM for exfiltration alerts and logs.
o Firewall and proxy logs for tracking suspicious connections.
• Integrations in Splunk SOAR:
o Network traffic analysis tools (Zeek, NetFlow).
o Endpoint detection and response (EDR) tools for endpoint activity logs.
o Threat intelligence services to verify destination IPs and domains.
o Cloud storage monitoring tools for unauthorised uploads.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks in Splunk SOAR and click Create Playbook.
2. Name the Playbook:
o Title: "Data Exfiltration Monitoring and Response."
o Use the Visual Editor to build the workflow.

Step 4: Build the Workflow

1. Trigger Node:
o Configure the playbook to trigger on:
§ Alerts from DLP systems.
§ SIEM anomalies, such as large outbound data transfers or
unauthorised uploads.
2. Enrichment Nodes:
o Traffic Analysis:
§ Query network monitoring tools for details on outbound connections
flagged as suspicious.
o Destination Analysis:
§ Use threat intelligence to check if the destination IP/domain is
malicious or unusual.
 o File Analysis:
§ Examine file types, sizes and metadata to determine the sensitivity of
data being transferred.
o Endpoint Activity Check:
§ Inspect the endpoint involved in the exfiltration attempt using EDR
tools.
3. Decision Node:
o Add decision points based on enrichment results:
§ If confirmed malicious activity: Proceed to containment actions.
§ If activity is suspicious but not confirmed: Escalate for manual
investigation.
§ If activity is a false positive: Close the case.
4. Containment Nodes:
o Block Traffic:
§ Use firewalls or proxy tools to block the suspicious outbound
connection.
o Isolate Endpoint:
§ Leverage EDR tools to isolate the endpoint from the network.
o Suspend User Account:
§ Disable the associated user account in IAM systems to prevent
further activity.
5. Mitigation Nodes:
o Alert Security Team:
§ Notify the SOC team for detailed investigation and further action.
o Notify Affected Parties:
§ Alert stakeholders if sensitive customer or business data was
potentially compromised.
6. Post-Incident Action Nodes:
o Forensic Analysis:
§ Collect and analyse evidence, such as logs, to determine the extent
of the exfiltration.
o Threat Intelligence Update:
§ Add newly discovered malicious IPs, domains or file signatures to the
threat database.
o Review and Update Policies:
§ Recommend updates to access controls, DLP rules or monitoring
thresholds.

Step 5: Test the Playbook

1. Simulate Data Exfiltration Scenario:

o Mock Incident:
§ Endpoint transfers 1 GB of encrypted data to an unfamiliar IP address.
o Playbook Execution:
 § The outbound traffic is flagged by the DLP system.
§ Threat intelligence identifies the IP as malicious.
§ The endpoint is isolated and traffic is blocked.
§ Security and affected parties are notified.

Step 6: Deploy in Production

1. Automate the playbook to run on DLP and SIEM alerts for potential data exfiltration.
2. Continuously refine the playbook based on new exfiltration tactics and incident
outcomes.

Step 7: Measure Success

• KPIs:
o Time to detect and respond to exfiltration attempts: Target <15 minutes.
o Reduction in successful data exfiltration incidents.
o Volume of sensitive data protected from unauthorised transfers.
Use Case 7: Brute Force Attack Mitigation

Step 1: Define the Use Case

• Name: Brute Force Attack Mitigation

• Objective: Automate the detection, investigation and mitigation of brute force
attacks targeting user accounts, servers or other infrastructure to prevent
unauthorised access.
• Priority: High (to protect against compromised accounts and service disruption).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o SIEM for login failure alerts and anomalies in authentication logs.
o IAM systems for user account lockout status.
o EDR tools for endpoint login attempts.
o Firewall and network monitoring tools for traffic patterns indicating brute
force attempts.
• Integrations in Splunk SOAR:
o Authentication logs from services like Active Directory, Okta or Azure AD.
o Network firewalls for IP blocking.
o Threat intelligence services to verify IP reputations.
o VPN and endpoint logs to detect brute force on remote access systems.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks in Splunk SOAR and click Create Playbook.
2. Name the Playbook:
o Title: "Brute Force Attack Mitigation."
o Use the Visual Editor to build the workflow.

Step 4: Build the Workflow

1. Trigger Node:
o Configure the playbook to trigger on:
§ Multiple consecutive failed login attempts from the same IP.
§ High volume of login attempts within a short time window flagged by
SIEM.
2. Enrichment Nodes:
o User Account Analysis:
§ Check the status of the targeted user account in IAM systems (locked,
active, privileged).
o Source IP Analysis:
 § Use threat intelligence to verify if the source IP is known for malicious
activity.
o Network Traffic Analysis:
§ Inspect network logs for patterns of brute force behavior, such as
repeated connections to authentication services.
3. Decision Node:
o Add decision points based on enrichment results:
§ If confirmed brute force attack: Proceed to containment actions.
§ If activity is inconclusive: Escalate for manual review.
§ If activity is false positive: Close the case.
4. Containment Nodes:
o Block IP Address:
§ Use firewalls to block the source IP of the attack.
o Lock User Account:
§ Automatically lock the targeted user account to prevent further
unauthorised attempts.
o Isolate Endpoint:
§ Isolate any endpoint involved in the brute force attempt using EDR
tools.
5. Mitigation Nodes:
o Notify SOC Team:
§ Alert the security team with details of the incident and actions taken.
o Password Reset:
§ Force a password reset for the targeted user account if there is a risk
of compromise.
6. Post-Incident Action Nodes:
o Update Threat Intelligence:
§ Add malicious IPs to the blocklist for future prevention.
o Audit Logs:
§ Retain logs of the brute force attack for further analysis and
compliance purposes.
o Policy Review:
§ Review and update password policies, lockout thresholds and
monitoring rules to reduce future brute force attempts.

Step 5: Test the Playbook

1. Simulate a Brute Force Attack Scenario:

o Mock Incident:
§ An IP address attempts 50 failed logins to a corporate VPN within 2
minutes.
o Playbook Execution:
§ The source IP is flagged as suspicious.
 § Threat intelligence confirms the IP is associated with known brute
force attacks.
§ The IP is blocked and the targeted user account is locked.
§ SOC is notified and logs are retained for analysis.

Step 6: Deploy in Production

1. Automate the playbook to trigger on brute force detection rules in SIEM or network
monitoring systems.
2. Regularly refine the playbook based on attack patterns and feedback from the SOC
team.

Step 7: Measure Success

• KPIs:
o Time to detect and mitigate brute force attacks: Target <10 minutes.
o Reduction in successful brute force compromises.
o Number of false positives versus legitimate detections.
Use Case 8: Suspicious Login and Access Investigation

Step 1: Define the Use Case

• Name: Suspicious Login and Access Investigation

• Objective: Automate the investigation of anomalous login activities and
unauthorised access attempts to quickly identify and mitigate potential account
compromises.
• Priority: High (to prevent unauthorised access and lateral movement).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o SIEM for anomalous login alerts (geolocation anomalies, multiple logins in
short intervals).
o IAM systems for access control logs and user account activities.
o VPN logs for unusual remote access behavior.
o Cloud monitoring tools for suspicious access in cloud environments.
• Integrations in Splunk SOAR:
o Threat intelligence platforms for validating IPs and geolocations.
o Authentication and access control logs (Active Directory, Okta, Azure AD).
o EDR solutions for endpoint activity related to suspicious logins.
o Cloud monitoring tools like AWS CloudTrail or Microsoft Azure Monitor.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks in Splunk SOAR and click Create Playbook.
2. Name the Playbook:
o Title: "Suspicious Login and Access Investigation."
o Use the Visual Editor to build the workflow.

Step 4: Build the Workflow

1. Trigger Node:
o Configure the playbook to trigger on:
§ Alerts from SIEM for login anomalies (impossible travel, unusual
geolocations).
§ Failed or repeated login attempts followed by successful access.
§ Unauthorised attempts to access critical systems or files.
2. Enrichment Nodes:
o Geolocation Check:
§ Query the login's originating IP address and compare it with the user's
usual locations.
 o User Behavior Analysis:
§ Examine recent user activities (login times, accessed systems) for
anomalies.
o Threat Intelligence Lookup:
§ Check the originating IP against threat intelligence feeds for known
malicious actors.
o Endpoint Investigation:
§ Inspect endpoints used during the suspicious login for malicious
activities or tools.
3. Decision Node:
o Add decision points based on enrichment results:
§ If confirmed suspicious login: Proceed to containment actions.
§ If inconclusive activity: Escalate for manual investigation.
§ If false positive: Close the case.
4. Containment Nodes:
o Block IP Address:
§ Use firewalls to block the suspicious IP.
o Force User Logoff:
§ Terminate the suspicious session in IAM systems.
o Lock User Account:
§ Temporarily lock the account to prevent further misuse.
5. Mitigation Nodes:
o Notify SOC Team:
§ Send detailed information about the incident to the security team.
o Force Password Reset:
§ Require the user to reset their password if the account was
compromised.
6. Post-Incident Action Nodes:
o Forensic Analysis:
§ Investigate compromised accounts and endpoints to determine the
root cause.
o Threat Intelligence Update:
§ Add malicious IPs or indicators to blocklists for future detection.
o Review Access Policies:
§ Recommend tightening access controls or adding multi-factor
authentication (MFA) if not already implemented.

Step 5: Test the Playbook

1. Simulate a Suspicious Login Scenario:

o Mock Incident:
§ A user logs in from two distant geolocations (Malaysia and the US)
within 10 minutes.
o Playbook Execution:
 § Geolocation check flags the login as suspicious.
§ Threat intelligence confirms the second IP as associated with
previous attacks.
§ The IP is blocked, the user session is terminated and the account is
locked.
§ SOC is notified and a password reset is initiated.

Step 6: Deploy in Production

1. Automate the playbook to trigger on login anomalies from SIEM or IAM alerts.
2. Continuously refine rules for identifying suspicious logins based on incident trends
and SOC feedback.

Step 7: Measure Success

• KPIs:
o Time to detect and respond to suspicious logins: Target <10 minutes.
o Number of compromised accounts successfully contained.
o Volume of false positives minimised through tuning and playbook
improvements.
Use Case 9: Endpoint Detection and Response (EDR) Automation

Step 1: Define the Use Case

• Name: Endpoint Detection and Response (EDR) Automation

• Objective: Automate the detection, investigation and remediation of suspicious
activities on endpoints to prevent potential breaches or malware infections.
• Priority: High (due to the critical role of endpoints in security breaches).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Alerts from EDR platforms (CrowdStrike Falcon, Carbon Black, SentinelOne).
o SIEM alerts for endpoint anomalies.
o Threat intelligence feeds for validating suspicious files, processes and
domains.
• Integrations in Splunk SOAR:
o EDR Tools: CrowdStrike Falcon, Carbon Black or Microsoft Defender ATP.
o Threat Intelligence: VirusTotal, Recorded Future or ThreatConnect.
o Sandboxing Tools: Joe Sandbox, Cuckoo Sandbox for malware analysis.
o Ticketing Systems: Jira or ServiceNow for incident management.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Open Splunk SOAR, go to Automation > Playbooks and select Create
Playbook.
2. Name the Playbook:
o Title: "Endpoint Detection and Response Automation."
o Use the Visual Editor for workflow creation.

Step 4: Build the Workflow

1. Trigger Node

• Configure the playbook to trigger on:

o EDR alerts for unusual process execution, file creation or registry
modifications.
o SIEM detection of lateral movement, data exfiltration or malware presence
on endpoints.

2. Enrichment Nodes

• File Reputation Lookup:

 o Check hashes of suspicious files against VirusTotal or other reputation
services.
• Process Behavior Analysis:
o Query EDR logs to determine if the process is legitimate or anomalous.
• Threat Intelligence Correlation:
o Use threat intelligence to analyse suspicious domains, IPs or indicators.

3. Decision Nodes

• Based on enrichment results, define paths for the workflow:

o If Malware is Detected: Proceed to containment and remediation.
o If Suspicious Activity is Inconclusive: Escalate to SOC for further
investigation.
o If False Positive: Close the case.

4. Containment Nodes

• Isolate Endpoint:
o Automatically quarantine the affected device via EDR tools.
• Kill Malicious Process:
o Terminate suspicious processes or services flagged during analysis.
• Block Malicious IPs or Domains:
o Update firewalls or endpoint rules to block malicious traffic.

5. Mitigation Nodes

• Remediate Files:
o Delete or quarantine malicious files.
• Patch Vulnerabilities:
o Apply patches to close known vulnerabilities exploited in the attack.

6. Notification Nodes

• Notify SOC Analysts:

o Send detailed incident reports to the SOC team.
• Open Ticket:
o Create an incident ticket in ServiceNow or Jira for further tracking.

7. Post-Incident Action Nodes

• Forensic Analysis:
o Retrieve endpoint memory and disk snapshots for detailed analysis.
• IOC Update:
 o Add newly identified indicators of compromise to the threat intelligence
database.
• Review Endpoint Policies:
o Evaluate and update endpoint protection policies as needed.

Step 5: Test the Playbook

1. Simulate a Suspicious Endpoint Activity:

o Mock Incident:
§ EDR alerts for a suspicious executable downloading additional
payloads.
o Playbook Execution:
§ File hash is sent to VirusTotal and identified as malware.
§ Endpoint is isolated automatically.
§ SOC is notified with an incident report.
§ Post-mitigation tasks are executed (IOC updates and policy review).

Step 6: Deploy in Production

1. Ensure the playbook is triggered for relevant endpoint security alerts.

2. Continuously monitor and refine playbook actions based on SOC feedback and
evolving threats.

Step 7: Measure Success

• KPIs:
o Mean time to respond (MTTR) to EDR alerts: Target <15 minutes.
o Number of incidents mitigated before causing impact.
o False positive rate for EDR alerts.
Use Case 10: Cloud Security Incident Handling

Step 1: Define the Use Case

• Name: Cloud Security Incident Handling

• Objective: Automate the detection, investigation and response to cloud security
incidents, such as unauthorised access, misconfigured resources and potential
data breaches.
• Priority: High (cloud environments host critical resources and data).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Cloud provider logs (AWS CloudTrail, Azure Monitor, Google Cloud Logging).
o Alerts from cloud security tools (AWS GuardDuty, Azure Security Center).
o SIEM alerts for cloud-specific anomalies.
• Integrations in Splunk SOAR:
o Cloud Services: AWS, Azure, Google Cloud.
o Threat Intelligence: VirusTotal, Shodan or Recorded Future for validating IPs
and domains.
o IAM Management: Tools for managing user privileges and access (AWS IAM,
Azure Active Directory).
o Ticketing Systems: Jira or ServiceNow for incident tracking.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Open Splunk SOAR, go to Automation > Playbooks and select Create
Playbook.
2. Name the Playbook:
o Title: "Cloud Security Incident Handling."
o Use the Visual Editor for workflow creation.

Step 4: Build the Workflow

1. Trigger Node

• Configure the playbook to trigger on:

o Unauthorised API calls.
o Detection of public exposure of sensitive data.
o Unusual activities, such as login attempts from anomalous geolocations.

2. Enrichment Nodes
 • IP Reputation Check:
o Validate the IP address of suspicious activities via VirusTotal or Recorded
Future.
• Resource Misconfiguration Validation:
o Use cloud provider APIs to query resource configurations for compliance.
• Access Pattern Analysis:
o Analyse IAM logs to identify unusual access attempts or privilege
escalations.

3. Decision Nodes

• Define paths for the workflow:

o If Unauthorised Access Detected: Proceed to revoke access and
investigate.
o If Misconfigured Resources Found: Update configurations automatically.
o If False Positive: Close the incident and log it for review.

4. Containment Nodes

• Revoke Access:
o Disable the compromised user account or role.
• Restrict Network Traffic:
o Apply firewall rules to block malicious IPs or regions.
• Snapshot Resource State:
o Take a snapshot of affected cloud resources for further analysis.

5. Mitigation Nodes

• Correct Misconfigurations:
o Automatically adjust resource configurations to meet security policies.
• Terminate Malicious Sessions:
o End active sessions tied to compromised accounts.

6. Notification Nodes

• Notify Cloud Security Team:

o Send detailed incident reports to relevant stakeholders.
• Open Ticket:
o Create a ticket in Jira or ServiceNow for further tracking.

7. Post-Incident Action Nodes

• Forensic Analysis:
o Analyse logs and resource states for root cause identification.
 • Compliance Verification:
o Verify cloud resources against compliance frameworks like CIS or NIST.
• Update IAM Policies:
o Revise and enforce stricter IAM policies.

Step 5: Test the Playbook

1. Simulate a Cloud Security Incident:

o Mock Incident:
§ Unauthorised API call from a suspicious IP address detected by AWS
GuardDuty.
o Playbook Execution:
§ IP address validated via VirusTotal.
§ Compromised IAM role disabled.
§ SOC notified with detailed incident report.
§ Post-mitigation actions include forensic analysis and policy updates.

Step 6: Deploy in Production

1. Integrate the playbook with live cloud security monitoring systems.

2. Monitor playbook execution logs and refine actions as necessary.

Step 7: Measure Success

• KPIs:
o Mean time to detect (MTTD) and respond (MTTR) to cloud security incidents.
o Number of misconfigured resources corrected automatically.
o Reduction in unauthorised access attempts.
Use Case 11: Cryptojacking Detection and Mitigation

Step 1: Define the Use Case

• Name: Cryptojacking Detection and Mitigation

• Objective: Detect unauthorised cryptocurrency mining activities, isolate
compromised endpoints and mitigate further exploitation.
• Priority: High (to prevent system resource abuse and financial impact).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Endpoint Detection and Response (EDR), e.g., CrowdStrike or Carbon Black.
o Network Monitoring Tools, e.g., Zeek (Bro) or Splunk Stream.
o Threat Intelligence, e.g., VirusTotal or AbuseIPDB.
• Integrations in Splunk SOAR:
o SIEM (Splunk for correlating mining-related alerts).
o Firewall (Palo Alto Networks for blocking malicious traffic).
o EDR (CrowdStrike for isolating compromised endpoints).

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "Cryptojacking Detection and Mitigation."
o Use the Visual Editor to design the workflow.

Step 4: Build the Workflow

1. Trigger Node:
o Set a trigger to activate the playbook based on:
§ High CPU usage alerts from endpoints.
§ Network traffic to known mining pools or suspicious domains.
o Example source: SIEM or EDR alerts.
2. Enrichment Node:
o Process Analysis:
§ Query the affected endpoint for processes consuming high CPU/GPU.
o Network Traffic Analysis:
§ Query network logs for connections to known cryptocurrency mining
pool IPs/domains.
o Threat Intelligence:
§ Use VirusTotal or AbuseIPDB to check if identified domains or IPs
have been flagged as malicious.
 3. Decision Node:
o Add a decision point based on enrichment data:
§ If IOC is confirmed malicious: Proceed with mitigation.
§ If IOC is benign: Close the alert as a false positive.
4. Isolation Node:
o Use EDR to isolate the compromised endpoint from the network.
o Include details such as:
§ Hostname.
§ User logged in.
§ Malicious processes identified.
5. Mitigation Node:
o Kill Malicious Processes:
§ Execute a script to terminate cryptocurrency mining processes.
o Update Firewall Rules:
§ Block malicious mining pool IPs/domains using firewall integration
(Palo Alto Networks or Fortinet).
6. Notification Node:
o Notify the Incident Response (IR) team and SOC with detailed findings:
§ Affected endpoint.
§ Malicious processes or connections identified.
§ Actions taken (isolation, process termination, firewall update).
7. Post-Incident Action Node:
o Use the Run Command action to scan the endpoint for potential
vulnerabilities (missing patches, misconfigurations).
o Suggest remediation steps such as applying security patches or resetting
credentials.

Step 5: Test the Playbook

1. Simulate a Cryptojacking Scenario:

o Mock an alert indicating:
§ Host: HOST001.
§ CPU usage: >90% over 10 minutes.
§ Network connections: Suspicious domain pool.crypto-miners.io.
§ Malicious process: xmrig.exe.
2. Run the Playbook:
o Validate the workflow steps:
§ Enrichment confirms xmrig.exe and pool.crypto-miners.io as
malicious.
§ Endpoint is isolated.
§ Mining process is terminated.
§ Firewall blocks pool.crypto-miners.io.
§ Notifications are sent to the IR team.
Step 6: Deploy in Production

1. Assign the playbook to handle cryptojacking-related alerts automatically.

2. Monitor playbook execution during live incidents.

Step 7: Measure Success

• KPIs:
o Time to detect and mitigate cryptojacking: Target <5 minutes.
o Number of false positives reduced: Target <10%.
o Overall system performance improvement.
• Use Splunk SOAR’s reporting features to analyse and improve playbook
performance.
Use Case 12: DNS Tunneling Attack Investigation

Step 1: Define the Use Case

• Name: DNS Tunneling Attack Investigation

• Objective: Automate the detection, investigation and mitigation of DNS tunneling
attacks to prevent data exfiltration or command-and-control communication.
• Priority: High (DNS tunneling is a stealthy attack vector often used for exfiltration or
malware control).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o DNS logs (BIND, Infoblox, Windows DNS Server).
o Firewall logs (Palo Alto, Cisco ASA).
o SIEM alerts for suspicious DNS activity.
• Integrations in Splunk SOAR:
o DNS Analysis Tools: Farsight DNSDB, VirusTotal or PassiveTotal.
o Network Traffic Analysis: Wireshark or Zeek (formerly Bro).
o Threat Intelligence Platforms: Recorded Future or Anomali.
o Endpoint Detection and Response (EDR): CrowdStrike or Carbon Black.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Open Splunk SOAR, go to Automation > Playbooks and select Create
Playbook.
2. Name the Playbook:
o Title: "DNS Tunneling Attack Investigation."
o Use the Visual Editor for workflow creation.

Step 4: Build the Workflow

1. Trigger Node

• Configure the playbook to trigger on:

o High volume of unusual DNS queries (frequent requests to rare or suspicious
domains).
o Detection of subdomain patterns resembling data exfiltration (base64-
encoded data).
o Alerts from SIEM or EDR tools regarding anomalous DNS activity.

2. Enrichment Nodes
 • Domain Reputation Check:
o Query the suspicious domains or subdomains through VirusTotal, Farsight
DNSDB or PassiveTotal.
• Analyse DNS Query Patterns:
o Extract and decode DNS payloads for base64 or other encoded data using
custom scripts or tools.
• Network Traffic Analysis:
o Analyse network packet captures (PCAP) for tunneling activity using
Wireshark or Zeek.

3. Decision Nodes

• Define paths for the workflow:

o If Malicious Domain Found: Proceed to block the domain and isolate the
endpoint.
o If Suspicious Traffic Needs Further Analysis: Escalate to SOC for deeper
investigation.
o If False Positive: Close the case and log findings for review.

4. Containment Nodes

• Block Domain or IP:

o Use firewall or DNS filtering tools to block communication with the identified
domain or IP.
• Isolate Compromised Endpoint:
o Leverage EDR tools to isolate the affected system from the network.

5. Mitigation Nodes

• Terminate Malicious Processes:

o Identify and terminate processes generating tunneling traffic on the
endpoint.
• Restore Normal DNS Configuration:
o Revert any changes made to DNS settings on the affected systems.

6. Notification Nodes

• Notify SOC Team:

o Send detailed incident reports, including decoded data, domain reputation
and mitigation steps.
• Open Ticket:
o Create a ticket in Jira or ServiceNow for further tracking and documentation.

7. Post-Incident Action Nodes

 • Forensic Analysis:
o Analyse system and network logs to identify the root cause and timeline of
the attack.
• IOC Sharing:
o Share Indicators of Compromise (IOCs) with threat intelligence platforms.
• Policy Updates:
o Update firewall and DNS policies to prevent recurrence.

Step 5: Test the Playbook

1. Simulate a DNS Tunneling Attack:

o Mock Scenario:
§ An endpoint generates repeated DNS queries to an unusual domain
(exfil.domain.com).
o Playbook Execution:
§ Domain reputation check identifies it as malicious.
§ DNS query pattern decoded to reveal potential data exfiltration.
§ Domain blocked and endpoint isolated.
§ SOC notified with detailed analysis report.

Step 6: Deploy in Production

1. Integrate the playbook with live DNS monitoring systems.

2. Continuously monitor execution logs and refine automation steps.

Step 7: Measure Success

• KPIs:
o Mean time to detect (MTTD) and respond (MTTR) to DNS tunneling incidents.
o Number of malicious domains identified and blocked.
o Reduction in DNS tunneling attack occurrences.
Use Case 13: Advanced Persistent Threat (APT) Detection

Step 1: Define the Use Case

• Name: APT Detection and Response

• Objective: Automate the detection, analysis and containment of Advanced
Persistent Threats (APTs) that exhibit stealthy and sophisticated tactics over
extended periods.
• Priority: Critical (APTs can lead to extensive data breaches and long-term
compromise).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o SIEM alerts for abnormal behavior (lateral movement, privilege escalation).
o EDR tools for endpoint behavior analysis.
o Threat intelligence feeds to identify IOCs related to known APT groups.
o Network traffic logs for unusual patterns (beaconing or encrypted data
exfiltration).
• Integrations in Splunk SOAR:
o Threat Intelligence Platforms: Recorded Future, Anomali or MISP.
o EDR Solutions: CrowdStrike, SentinelOne or Carbon Black.
o Network Monitoring Tools: Zeek (Bro) or Palo Alto firewall.
o Sandboxing Tools: Cuckoo Sandbox or Joe Sandbox for malware analysis.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Open Splunk SOAR, go to Automation > Playbooks and select Create
Playbook.
2. Name the Playbook:
o Title: "APT Detection and Response."
o Use the Visual Editor for workflow creation.

Step 4: Build the Workflow

1. Trigger Node

• Configure the playbook to trigger on:

o Suspicious login attempts or privilege escalation alerts.
o Beaconing activity detected in network traffic logs.
o Anomalies in file access patterns (access to sensitive data from unusual
endpoints).
2. Enrichment Nodes

• Gather Threat Intelligence:

o Query IOC information from Recorded Future or Anomali to correlate
suspicious IPs, hashes or domains with known APT campaigns.
• Analyse Network Traffic:
o Use Zeek or Wireshark to identify signs of lateral movement, C2 traffic or
encrypted exfiltration.
• Endpoint Behavior Analysis:
o Query EDR tools for unusual processes, registry changes or file
modifications on affected systems.

3. Decision Nodes

• Define paths for the workflow:

o If Indicators Match Known APT: Trigger containment and investigation
actions.
o If Suspicious Behavior Needs Further Analysis: Escalate to Tier 2/3 SOC
analysts.
o If False Positive: Close the case with a detailed report for review.

4. Containment Nodes

• Isolate Endpoint:
o Use EDR solutions to isolate the compromised endpoint.
• Block Malicious IPs/Domains:
o Add IOC-related IPs/domains to the firewall’s blocklist.

5. Investigation Nodes

• Malware Analysis:
o Submit suspicious files to a sandbox (Cuckoo) for dynamic analysis.
• Timeline Reconstruction:
o Query logs from SIEM and network monitoring tools to reconstruct the attack
lifecycle.

6. Mitigation Nodes

• Terminate Malicious Processes:

o Identify and stop malicious processes running on the affected endpoint.
• Patch Vulnerabilities:
o Recommend patching or updating software exploited during the attack.

7. Notification Nodes
 • Notify Incident Response Team:
o Send a detailed incident report to the SOC and IR team, including indicators,
affected systems and containment steps.
• Open Ticket:
o Create a ticket in ServiceNow or Jira for tracking and documentation.

8. Post-Incident Action Nodes

• Forensic Analysis:
o Perform deep-dive forensic analysis of endpoints and network logs to
uncover the root cause.
• IOC Sharing:
o Share IOCs and attack details with threat intelligence platforms.
• Policy Updates:
o Update security policies and network configurations to mitigate similar
attacks.

Step 5: Test the Playbook

1. Simulate an APT Scenario:

o Mock Scenario:
§ An attacker gains initial access through a phishing email and
performs lateral movement, leading to data exfiltration.
o Playbook Execution:
§ Detects lateral movement via SIEM.
§ Matches C2 beaconing activity to known APT domains.
§ Isolates affected endpoint and blocks malicious IPs.
§ Notifies SOC with a detailed report of the actions taken.

Step 6: Deploy in Production

1. Integrate the playbook with live monitoring systems for real-time response to APT
indicators.
2. Continuously refine and update based on new APT campaigns and IOCs.

Step 7: Measure Success

• KPIs:
o Mean time to detect (MTTD) and respond (MTTR) to APT activities.
o Number of APT-related incidents contained successfully.
o Reduction in dwell time of attackers within the network.
Use Case 14: Zero-Day Vulnerability Response

Step 1: Define the Use Case

• Name: Zero-Day Vulnerability Detection and Response

• Objective: Automate the detection, investigation and mitigation of incidents related
to zero-day vulnerabilities to minimize exploitation risks.
• Priority: Critical (Zero-day vulnerabilities pose a significant threat with no
immediate patches available).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o SIEM alerts for exploit attempts.
o Vulnerability scanners like Nessus or Qualys for known vulnerabilities.
o Threat intelligence feeds for indicators of zero-day exploits.
o EDR tools for endpoint activity and behavior monitoring.
• Integrations in Splunk SOAR:
o Threat Intelligence: Recorded Future, MISP or VirusTotal for zero-day IOCs.
o Vulnerability Management: Tenable or Qualys for scanning.
o Sandboxing Tools: Cuckoo Sandbox or Joe Sandbox for malware payload
analysis.
o EDR Tools: CrowdStrike or SentinelOne for monitoring suspicious behavior.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Open Splunk SOAR, go to Automation > Playbooks and create a new
playbook.
2. Name the Playbook:
o Title: "Zero-Day Vulnerability Response."

Step 4: Build the Workflow

1. Trigger Node

• Configure triggers for:

o Detection of unusual exploit attempts in SIEM.
o High-severity alerts from vulnerability scanners indicating potential
exposure.
o Reports from threat intelligence feeds about active exploitation of zero-day
vulnerabilities.

2. Enrichment Nodes
 • Gather Threat Intelligence:
o Query threat intelligence platforms for IPs, domains or hashes associated
with zero-day exploits.
• Endpoint Analysis:
o Query EDR tools to detect suspicious behavior on endpoints (new processes
or file changes).
• Vulnerability Context:
o Pull data from vulnerability scanners to identify systems with related
vulnerabilities.

3. Decision Nodes

• Path 1: Exploit Detected

o If the exploit attempt is detected, initiate containment actions.
• Path 2: No Exploit Detected
o If no immediate exploitation is observed, escalate to threat hunting for
further analysis.

4. Containment Nodes

• Isolate Systems:
o Automatically isolate impacted or vulnerable systems from the network
using EDR or NAC (Network Access Control).
• Block IOCs:
o Add IOCs (IPs, domains) to firewall and proxy blocklists.

5. Investigation Nodes

• Analyse Exploit Attempts:

o Submit suspicious files or payloads to a sandbox for dynamic analysis.
• Reconstruct Exploit Chain:
o Investigate logs to determine the exploit chain and attacker’s intent.
• Lateral Movement Detection:
o Check for signs of lateral movement or privilege escalation on impacted
systems.

6. Mitigation Nodes

• Apply Workarounds:
o Implement vendor-recommended mitigations or temporary fixes for the zero-
day.
• Patch Management:
o Monitor for and apply patches as soon as they are released.
7. Notification Nodes

• Notify Teams:
o Send alerts to the SOC, IT and vulnerability management teams about the
zero-day incident and actions taken.
• Incident Reporting:
o Generate a detailed report summarising the indicators, impact and
containment steps.

8. Post-Incident Action Nodes

• IOC Sharing:
o Share IOCs with threat intelligence platforms and industry ISACs.
• Policy and Rule Updates:
o Update detection rules in SIEM to identify similar exploit patterns.
• Training and Awareness:
o Conduct awareness training for staff on mitigating similar attacks.

Step 5: Test the Playbook

1. Simulate a Zero-Day Scenario:

o Mock Scenario:
§ A threat actor exploits an unpatched zero-day vulnerability in a web
application.
o Playbook Execution:
§ Detects exploit attempts via SIEM.
§ Isolates the compromised server.
§ Queries threat intelligence for IOC verification.
§ Shares findings with relevant teams.

Step 6: Deploy in Production

• Integrate the playbook into production for automatic responses to zero-day-related

incidents.
• Regularly test and refine to ensure it remains effective against evolving threats.

Step 7: Measure Success

• KPIs:
o Mean time to detect (MTTD) and respond (MTTR) to zero-day incidents.
o Percentage of vulnerable systems isolated before exploitation.
o Number of exploit attempts mitigated successfully.
Use Case 15: Compliance Audit Automation

Step 1: Define the Use Case

• Name: Compliance Audit Automation

• Objective: Automate periodic compliance checks to ensure adherence to
regulatory frameworks such as GDPR, HIPAA, PCI-DSS or ISO 27001.
• Priority: High (Regular audits are crucial for avoiding penalties and ensuring
organisational security).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Security configurations from firewalls, servers and endpoints.
o Vulnerability and patch management reports.
o User activity logs from identity and access management (IAM) tools.
o SIEM data for log aggregation.
• Integrations in Splunk SOAR:
o Compliance Tools: Tenable.sc, Nessus or Qualys for scanning.
o SIEM: Splunk Enterprise Security or QRadar for log analysis.
o Policy Management: ServiceNow or Confluence for policies and
procedures.
o IAM Tools: Okta or Azure AD for access and privilege reviews.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o Open Splunk SOAR, go to Automation > Playbooks and create a new
playbook.
2. Name the Playbook:
o Title: "Compliance Audit Automation."

Step 4: Build the Workflow

1. Trigger Node

• Set a trigger for periodic audit events, such as monthly, quarterly or annually.
• Alternatively, initiate the audit process based on external triggers, like regulatory
updates or specific audit requests.

2. Data Collection Nodes

• Collect System Configurations:

 o Use integrations with SIEM, vulnerability scanners and IAM tools to pull data
on:
§ Firewall configurations.
§ User access and permissions.
§ System vulnerabilities.
• Retrieve Logs:
o Gather logs from servers, endpoints and network devices for compliance
validation.

3. Analysis Nodes

• Check for Compliance Gaps:

o Use predefined compliance rules (PCI-DSS 12.5.2) to evaluate
configurations and logs.
• Validate Patches:
o Cross-check patch levels with vulnerability scanner reports to ensure no
critical vulnerabilities remain.
• Monitor Access Permissions:
o Review user permissions to identify unauthorised access or privilege
escalations.

4. Decision Nodes

• Path 1: Non-Compliance Detected

o If gaps are identified, initiate remediation actions.
• Path 2: Fully Compliant
o If no issues are found, generate and store the compliance report.

5. Remediation Nodes

• Assign Tasks:
o Create tickets in ServiceNow or JIRA for IT teams to address compliance
gaps.
• Automate Configurations:
o Push configuration updates to firewalls or IAM tools for detected policy
violations.
• Enforce Patches:
o Trigger patching processes using tools like WSUS or SCCM.

6. Reporting Nodes

• Generate Audit Report:

o Consolidate findings into a detailed compliance report highlighting:
§ Status of systems audited.
 § Detected gaps and actions taken.
§ Systems fully compliant.
• Distribute Reports:
o Send reports to compliance officers and stakeholders via email or
collaboration tools like Slack or Teams.

7. Notification Nodes

• Notify stakeholders of the compliance status and any required follow-up actions.

8. Post-Audit Action Nodes

• Update Compliance Rules:

o Ensure that compliance rules reflect the latest regulatory changes.
• Archive Data:
o Store compliance reports and logs securely for future reference and audits.

Step 5: Test the Playbook

1. Simulate an Audit Scenario:

o Mock Scenario:
§ Conduct an audit for GDPR compliance across servers, access
controls and patch levels.
o Playbook Execution:
§ Automatically collects logs and configurations.
§ Identifies non-compliance in patching or user permissions.
§ Generates and distributes compliance reports.

Step 6: Deploy in Production

• Enable the playbook to run on a defined schedule (quarterly).

• Ensure integrations are configured to pull real-time data for accurate compliance
checks.

Step 7: Measure Success

• KPIs:
o Reduction in manual audit effort (time saved).
o Percentage of compliant systems post-audit.
o Time to remediate identified compliance gaps.
Use Case 16: API Abuse and Security Monitoring

Step 1: Define the Use Case

• Name: API Abuse and Security Monitoring

• Objective: Detect and respond to unusual API usage patterns, such as excessive
calls, unauthorised access or malicious payloads, to mitigate potential threats.
• Priority: High (APIs are often targeted in attacks due to their exposure and access to
sensitive data).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o API Gateway Logs (e.g., AWS API Gateway, Azure API Management).
o Web Server Logs (e.g., NGINX, Apache).
o SIEM for aggregated threat detection.
o Threat Intelligence Feeds for IP/URL reputation.
• Integrations in Splunk SOAR:
o API Gateway (AWS, Azure or Google Cloud integrations).
o Threat Intelligence Platforms (e.g., VirusTotal, ThreatConnect).
o SIEM (e.g., Splunk Enterprise Security or QRadar).
o Communication Tools (e.g., Slack, Microsoft Teams or email).

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "API Abuse and Security Monitoring."

Step 4: Build the Workflow

1. Trigger Node

• Trigger Type:
o Real-time alerts from the API gateway or SIEM for unusual API activity.
• Example Triggers:
o Multiple failed authentication attempts.
o Excessive API requests from a single IP.
o Unexpected payload patterns detected.

2. Data Collection Nodes

• Retrieve Logs:
 o Pull logs from the API gateway for detailed analysis of usage patterns.
• Threat Intelligence Query:
o Check the reputation of suspicious IPs or domains using VirusTotal or other
tools.
• Correlate Logs:
o Use SIEM to correlate API events with other suspicious activities across the
network.

3. Analysis Nodes

• Analyse Usage Patterns:

o Use pre-defined thresholds for API abuse, such as request limits, to flag
anomalies.
• Inspect Payloads:
o Validate JSON/XML payloads for malicious content, such as SQL injection or
script tags.
• Match Against Threat Feeds:
o Compare IPs and domains with known bad actors.

4. Decision Nodes

• Path 1: API Abuse Confirmed

o Proceed with remediation actions.
• Path 2: False Positive
o Log the event and close the case.

5. Remediation Nodes

• Block Suspicious IPs:

o Use integrations with firewalls or API gateway to block abusive IPs or users.
• Rate Limit Requests:
o Adjust API rate limits dynamically for flagged IPs or users.
• Terminate Sessions:
o End any ongoing sessions related to the suspicious activity.

6. Reporting Nodes

• Generate Incident Report:

o Include:
§ Details of the abuse (IP, endpoints affected, payloads).
§ Actions taken (blocks, limits, alerts).
• Distribute Report:
o Share with security teams and stakeholders via email or collaboration tools.
7. Notification Nodes

• Alert the API team and SOC analysts about the detected abuse and remediation
actions via Slack, Teams or email.

8. Post-Incident Action Nodes

• Add to Threat Feeds:

o Share new malicious IPs or patterns with the threat intelligence platform.
• Update API Gateway Rules:
o Refine rules to better detect and prevent similar abuse in the future.
• Archive Data:
o Store logs and reports for compliance and auditing purposes.

Step 5: Test the Playbook

1. Simulated Scenario:
o Mock Scenario:
§ A single IP makes 10,000 API requests within 5 minutes.
§ Payloads include suspicious SQL injection attempts.
o Playbook Execution:
§ Collects and analyses logs.
§ Flags the IP as abusive.
§ Blocks the IP in the API gateway.
§ Generates and sends the report.

Step 6: Deploy in Production

• Enable the playbook for real-time API abuse monitoring.

• Configure alerts and logs for comprehensive visibility into API activity.

Step 7: Measure Success

• KPIs:
o Time to detect and respond to API abuse incidents.
o Reduction in abusive requests post-implementation.
o Number of incidents resolved automatically versus manually.
Use Case 17: Threat Hunting Workflow Automation

Step 1: Define the Use Case

• Name: Threat Hunting Workflow Automation

• Objective: Automate repetitive tasks in threat hunting workflows, enabling analysts
to proactively search for hidden threats while saving time and reducing errors.
• Priority: High (Threat hunting is essential for identifying advanced threats missed by
automated tools).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o SIEM (e.g., Splunk Enterprise Security, QRadar).
o EDR (Endpoint Detection and Response) tools like CrowdStrike or Carbon
Black.
o Threat Intelligence Platforms (e.g., VirusTotal, Recorded Future).
o Log repositories (e.g., cloud service logs, network traffic logs).
• Integrations in Splunk SOAR:
o SIEM integration for querying logs and events.
o EDR integration for endpoint visibility.
o Threat intelligence integrations for IOC enrichment.
o OSINT tools (e.g., Shodan, theHarvester).

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "Threat Hunting Workflow Automation."

Step 4: Build the Workflow

1. Trigger Node

• Trigger Type:
o Schedule-based: Automatically run at predefined intervals (e.g., daily,
weekly).
o Manual: Analysts can trigger the playbook as part of their hunting exercise.

2. Data Collection Nodes

• Gather Logs:
 o Query recent logs from SIEM for suspicious patterns (e.g., failed logins,
privilege escalations, lateral movements).
• Retrieve EDR Data:
o Pull recent alerts and suspicious activity from EDR tools for correlation.
• Threat Intelligence Lookup:
o Enrich IOCs (e.g., IPs, hashes, domains) with threat intelligence feeds.

3. Analysis Nodes

• Pattern Analysis:
o Analyse logs and events for predefined threat patterns (e.g., beaconing
behavior, rare process executions).
• Correlate Data:
o Correlate endpoint activity, network traffic and SIEM events for a holistic
view.
• Behavior Anomalies:
o Use anomaly detection to flag deviations in user or system behavior.

4. Decision Nodes

• Path 1: Potential Threat Detected

o Proceed to deep dive investigation.
• Path 2: No Threat Detected
o Log the findings and close the task.

5. Investigation Nodes

• Endpoint Analysis:
o Isolate and analyse suspicious endpoints for unauthorised activity.
• Network Traffic Inspection:
o Inspect unusual traffic flows for signs of C2 communications or data
exfiltration.
• IOC Scanning:
o Scan the environment for artifacts matching IOCs.

6. Remediation Nodes

• Quarantine Endpoints:
o Automatically isolate compromised systems using EDR integrations.
• Block IPs/Domains:
o Use firewalls or SIEM to block malicious IPs or domains identified during
analysis.

7. Reporting Nodes
 • Generate Threat Hunt Report:
o Compile a summary of findings, including suspicious patterns, impacted
assets and actions taken.
• Share Findings:
o Distribute the report to SOC teams via email or collaboration platforms like
Slack.

8. Post-Hunt Nodes

• Update Threat Models:

o Incorporate new findings into threat detection rules and hunting strategies.
• IOC Database Update:
o Add newly identified IOCs to the threat intelligence platform.

Step 5: Test the Playbook

1. Simulated Scenario:
o Mock Data:
§ SIEM logs show a series of failed logins followed by a successful login
from a rare geolocation.
§ EDR detects a process spawning PowerShell commands atypical for
the system.
o Playbook Execution:
§ Collects logs and correlates data.
§ Flags the geolocation as suspicious and isolates the endpoint.
§ Generates and shares the report.

Step 6: Deploy in Production

• Automate the playbook for regular, proactive threat hunting in your environment.
• Ensure analysts can manually trigger the playbook during on-demand hunts.

Step 7: Measure Success

• KPIs:
o Time saved per hunting session using automation.
o Number of threats identified and mitigated during automated hunts.
o Reduction in repetitive tasks for SOC analysts.
Use Case 18: Denial-of-Service (DoS) Attack Response

Step 1: Define the Use Case

• Name: Denial-of-Service (DoS) Attack Response

• Objective: Automate the identification and mitigation of DoS attacks by analysing
network traffic and applying mitigation strategies, ensuring minimal downtime.
• Priority: Critical (DoS attacks can disrupt business operations and services).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Firewall logs (e.g., Palo Alto Networks, Cisco ASA).
o Network traffic monitoring tools (e.g., Zeek, NetFlow).
o Cloud service logs (AWS WAF, Azure Network Watcher).
o SIEM platform logs.
• Integrations in Splunk SOAR:
o Firewall APIs for blocking malicious IPs.
o SIEM integration for querying logs and correlating traffic anomalies.
o Threat intelligence feeds for identifying known malicious IPs or attack
signatures.
o Load balancers and CDN services for redirecting or throttling traffic.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "DoS Attack Response Playbook."

Step 4: Build the Workflow

1. Trigger Node

• Trigger Type:
o Event-based: Playbook triggers automatically upon detection of traffic
anomalies or alerts in SIEM/firewall logs.
o Manual: Analysts can initiate the playbook when suspecting a DoS attack.

2. Detection Nodes

• Analyse Traffic:
o Query network traffic logs for anomalies like a sudden spike in requests from
a single IP range.
 • Correlation:
o Correlate data from SIEM and network logs to confirm patterns of DoS
attacks (e.g., SYN floods, HTTP request floods).
• Threat Intelligence Lookup:
o Check source IPs against threat intelligence feeds to identify known
malicious actors.

3. Decision Nodes

• Path 1: DoS Attack Confirmed

o Proceed with mitigation steps.
• Path 2: False Positive
o Log the event and close the investigation.

4. Mitigation Nodes

• Block Malicious IPs:

o Use firewall APIs to block identified IP addresses.
• Rate Limiting:
o Apply rate-limiting rules via load balancers or CDNs to mitigate the traffic
impact.
• Enable WAF Rules:
o Activate Web Application Firewall (WAF) rules to filter malicious traffic
patterns.

5. Investigation Nodes

• Endpoint Analysis:
o Investigate if internal endpoints are participating in the DoS attack (e.g., as
part of a botnet).
• Traffic Origin Analysis:
o Identify the geographic origin of the attack and any related patterns.

6. Notification Nodes

• Alert SOC Team:

o Send notifications via email, Slack or PagerDuty to inform the team about the
attack and mitigation actions taken.
• Escalation:
o Escalate to incident management if the attack persists despite mitigation.

7. Reporting Nodes

• Generate Incident Report:

 o Include attack details, mitigated traffic patterns and response actions.
• Log Findings:
o Update case files in the ticketing system with analysis and actions
performed.

Step 5: Test the Playbook

1. Simulated Scenario:
o Mock Data:
§ Firewall logs show a sudden influx of SYN packets from a range of IPs.
§ SIEM detects a spike in HTTP requests from the same IPs, exceeding
normal thresholds.
o Playbook Execution:
§ Blocks the malicious IPs via the firewall.
§ Activates rate-limiting rules on the load balancer.
§ Generates and shares a detailed report with the SOC team.

Step 6: Deploy in Production

• Deploy the playbook to automatically mitigate DoS attacks as soon as anomalies

are detected.
• Ensure manual triggering is available for ad hoc responses to suspected DoS
incidents.

Step 7: Measure Success

• KPIs:
o Time to detect and mitigate DoS attacks.
o Reduction in downtime during attacks.
o Accuracy of detection (minimising false positives).
Use Case 19: Third-Party Risk Management and Monitoring

Step 1: Define the Use Case

• Name: Third-Party Risk Management and Monitoring

• Objective: Automate the identification, monitoring and mitigation of risks
associated with third-party vendors by integrating vendor data, alerts and
vulnerability information.
• Priority: High (Third-party breaches can expose sensitive data and create
compliance issues).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Vendor-provided security reports and SLAs.
o Threat intelligence feeds for third-party IP/domain monitoring.
o Vulnerability scanners (e.g., Nessus, Qualys) for vendor-exposed assets.
o Cloud service logs if third parties access shared environments.
• Integrations in Splunk SOAR:
o Vendor security platforms (if APIs are available).
o Threat intelligence platforms (e.g., VirusTotal, Recorded Future).
o Vulnerability scanners for assessing vendor-hosted systems.
o Ticketing systems (e.g., ServiceNow, Jira) for incident tracking.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "Third-Party Risk Monitoring Playbook."

Step 4: Build the Workflow

1. Trigger Node

• Trigger Type:
o Scheduled: Periodically check third-party systems and threat intelligence for
vulnerabilities and suspicious activity.
o Event-Based: Triggered when a vendor-related alert is detected in the SIEM.

2. Data Collection Nodes

• Query Vendor Security Reports:

o Pull regular reports via API or upload to a shared repository for analysis.
 • Check Threat Intelligence:
o Use threat intelligence feeds to monitor vendor-associated IPs, domains or
services for known vulnerabilities or malicious activities.
• Scan Vendor Systems:
o Utilise vulnerability scanners to check vendor systems exposed to your
organiation for new risks.

3. Risk Assessment Nodes

• Assess Severity:
o Correlate vulnerabilities with CVSS scores and prioritise based on
exploitability and potential impact.
• Third-Party Access Review:
o Analyse logs from shared systems to detect anomalous or unauthorised
access patterns.

4. Decision Nodes

• Path 1: High-Risk Findings

o Proceed with mitigation actions, including restricting access or escalating to
vendor.
• Path 2: Low/Medium-Risk Findings
o Log findings for future audits and notify the vendor for resolution.

5. Mitigation Nodes

• Restrict Access:
o Temporarily suspend or limit third-party access to sensitive resources until
issues are resolved.
• Notify Vendor:
o Automate notifications to the vendor with specific findings and required
action steps.

6. Vendor Communication Nodes

• Track Responses:
o Monitor vendor updates on the reported issue through email or ticketing
systems.
• Escalation:
o Escalate to vendor management team if issues are not resolved within SLA
timelines.

7. Reporting Nodes
 • Generate Risk Report:
o Compile a detailed report of risks identified, mitigation actions taken and
vendor responses.
• Update Compliance Records:
o Ensure all actions are logged for audit purposes.

Step 5: Test the Playbook

1. Simulated Scenario:
o Vendor Threat:
§ Threat intelligence flags a vendor-managed domain as part of a
phishing campaign.
o Response:
§ The playbook triggers a query to gather logs of the vendor's access,
sends automated notifications to the vendor and restricts access
temporarily until the issue is resolved.

Step 6: Deploy in Production

• Deploy the playbook with scheduled and event-based triggers.

• Regularly update the vendor list and integrate additional threat intelligence feeds to
enhance detection.

Step 7: Measure Success

• KPIs:
o Time to identify and mitigate third-party risks.
o Number of false positives versus actual incidents.
o Compliance adherence to SLA and regulatory frameworks.
Use Case 20: Automated Vulnerability Patch Management

Step 1: Define the Use Case

• Name: Automated Vulnerability Patch Management

• Objective: Automate the identification, prioritisation and patch deployment
process to address vulnerabilities across the organisation in a timely manner.
• Priority: High (Delays in patching can expose the organisation to exploitable
vulnerabilities).

Step 2: Configure Data Sources and Integrations

• Data Sources:
o Vulnerability scanners (e.g., Nessus, Qualys, Rapid7).
o Asset inventory systems for identifying affected devices and applications.
o Patch management tools (e.g., WSUS, SCCM, Ansible).
o SIEM for correlating vulnerability data with existing threats.
• Integrations in Splunk SOAR:
o Vulnerability scanners for detecting missing patches.
o Patch management systems for automating patch deployment.
o Ticketing systems (e.g., ServiceNow, Jira) to track and document patching
processes.

Step 3: Create the Playbook

1. Navigate to Playbooks:
o In Splunk SOAR, go to Automation > Playbooks and create a new playbook.
2. Name the Playbook:
o Title: "Automated Vulnerability Patch Management Playbook."

Step 4: Build the Workflow

1. Trigger Node

• Trigger Type:
o Scheduled: Run daily or weekly scans to identify missing patches.
o Event-Based: Triggered by vulnerability alerts from the scanner or SIEM.

2. Data Collection Nodes

• Fetch Vulnerability Data:

o Pull recent vulnerability reports from integrated scanners.
• Correlate with Threat Intelligence:
 o Use threat intelligence feeds to assess the exploitability and active threats
associated with identified vulnerabilities.

3. Risk Assessment Nodes

• Prioritise Vulnerabilities:
o Sort vulnerabilities based on CVSS scores, exploitability and criticality of
affected assets.
• Check Asset Impact:
o Query the asset inventory to assess the business impact of affected
systems.

4. Decision Nodes

• Path 1: Critical or High-Risk Vulnerabilities

o Proceed with immediate patch deployment.
• Path 2: Low/Medium-Risk Vulnerabilities
o Schedule patch deployment during maintenance windows or after business
hours.

5. Patch Deployment Nodes

• Automate Patch Installation:

o Use integrations with patch management systems to deploy patches to
affected assets.
• Rollback Preparation:
o Validate the ability to revert the patch in case of unexpected issues post-
deployment.

6. Validation Nodes

• Post-Deployment Scans:
o Re-scan systems to confirm successful patch application.
• Functionality Testing:
o Ensure patched systems are functioning correctly.

7. Reporting Nodes

• Generate Compliance Reports:

o Create a report detailing patched vulnerabilities, timelines and any
unresolved issues.
• Update Asset Records:
o Document the patched status in the asset inventory system.
Step 5: Test the Playbook

1. Simulated Scenario:
o Vulnerability Alert:
§ A vulnerability scanner detects a critical CVE affecting multiple
systems.
o Response:
§ The playbook fetches the vulnerability details, prioritises based on
risk, deploys the patch using a patch management tool and validates
the successful patching of all affected systems.

Step 6: Deploy in Production

• Schedule the playbook for daily scans and integrate it with the patch management
process.
• Establish workflows for handling exceptions, such as systems that require
downtime for patching.

Step 7: Measure Success

• KPIs:
o Time to detect and patch vulnerabilities.
o Percentage of systems patched within SLA timelines.
o Reduction in vulnerabilities detected during subsequent scans.
Use Case 21: Credential Harvesting Detection and Response
Step 1: Define the Use Case

• Use Case Name: Credential Harvesting Detection and Response

• Description: Detects potential credential harvesting attempts and responds by
blocking malicious sources, alerting analysts, and updating affected systems.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks > Create New Playbook.
2. Select Visual Editor:
o Use the drag-and-drop visual editor for intuitive workflow design.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger node to detect alerts related to credential harvesting attempts
in connected SIEM (e.g., Splunk, QRadar).
o Configure the trigger to activate on alerts flagged for phishing or abnormal
login attempts.
2. Extract IOC Node:
o Use the Artifact Extraction action to parse IOCs (URLs, IPs, email
addresses) from the alert.
o Focus on suspicious links, domains, and sender email addresses associated
with credential harvesting.
3. Phishing Domain Analysis Node:
o Add an Action node to query threat intelligence sources like VirusTotal or
OpenPhish for domain reputation.
o Input the extracted URLs and domains into the API request.
4. User Behavior Analysis Node:
o Add an action to cross-check flagged user accounts in the Identity
Management System (e.g., Active Directory).
o Identify unusual login patterns or geographical discrepancies.
5. Decision Node:
o Insert a Decision node to evaluate the risk level:
§ High Risk: If phishing domains are confirmed or login anomalies are
detected.
§ Low Risk: If no malicious indicators are found.
6. Block Malicious Source Node:
o For High Risk, add an Action node to:
§ Block URLs and IPs in the firewall or web gateway.
§ Disable compromised user accounts temporarily.
7. Update Case Node:
 o Enrich the alert with findings such as:
§ Malicious domains flagged.
§ Actions taken (e.g., blocked URLs, disabled accounts).
§ Affected users.
8. Notify Analyst Node:
o Add a Send Email action to notify SOC analysts with a summary of findings
and remediation actions.

Step 4: Save and Test the Playbook

1. Simulate Alert:
o Use Splunk SOAR’s simulation environment to generate a phishing alert with
a malicious domain (e.g., phishingsite.com).
2. Run the Playbook:
o Observe the following workflow:
§ Alert triggers IOC extraction.
§ Malicious domain phishingsite.com is flagged by VirusTotal with a
high threat score.
§ The domain is blocked in the firewall.
§ Affected user account is disabled.
§ Notification email is sent to the analyst.
3. Review Output:
o Confirm the enriched alert in the case management system.
o Verify that malicious sources are blocked and the analyst is notified.

Step 5: Deploy the Playbook

1. Assign the playbook to the production environment.

2. Configure the trigger to monitor SIEM alerts in real-time for credential harvesting
attempts.

Step 6: Monitor Performance

1. Track Key Metrics:

o Time to Detect and Respond: Ensure response time is under 3 minutes.
o False Positive Rate: Minimise false positives with better IOC validation.
o Analyst Feedback: Confirm actions taken improve incident resolution
efficiency.
2. Visualise Performance:
o Use Splunk SOAR’s dashboard to track metrics like average response time,
success rate, and feedback scores over time.
Use Case 22: Unauthorised File Access Monitoring
Step 1: Define the Use Case

• Use Case Name: Unauthorised File Access Monitoring

• Description: Detects and responds to unauthorised access attempts on sensitive
files, ensuring that proper actions are taken to protect the data and alert relevant
personnel.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks > Create New Playbook.
2. Select Visual Editor:
o Choose the drag-and-drop visual editor for ease of use.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger node to detect file access events flagged by connected SIEM
tools (e.g., Splunk, QRadar).
o Configure the trigger to activate when unusual file access patterns or
unauthorised user access is logged.
2. Extract File Access Details Node:
o Use the Artifact Extraction action to parse details from the alert, including:
§ User ID.
§ File name and location.
§ Time of access.
3. User Privilege Verification Node:
o Add an Action node to check the user's access permissions in the Identity
Management System (e.g., Active Directory).
o Identify whether the user is authorised to access the flagged file.
4. File Sensitivity Analysis Node:
o Add an Action node to validate the sensitivity of the accessed file using Data
Loss Prevention (DLP) systems or file metadata.
o Classify files as "Confidential," "Public," or "Restricted."
5. Decision Node:
o Insert a Decision node to evaluate the situation:
§ Unauthorised Access: If the user lacks proper permissions or the file
is classified as sensitive.
§ Authorised Access: If the user has legitimate access to the file.
6. Block User Node:
o For Unauthorised Access, add an Action node to:
§ Temporarily disable the user’s account.
§ Block the user's IP address or workstation if suspicious.
 7. Update Case Node:
o Enrich the original alert with details about the user, accessed file, and
actions taken.
8. Notify Analyst Node:
o Add a Send Email action to notify the SOC analyst, including:
§ The user involved.
§ The sensitive file accessed.
§ Actions performed (e.g., user blocked).

Step 4: Save and Test the Playbook

1. Simulate Alert:
o Use Splunk SOAR’s simulation environment to generate an alert for
unauthorised access to a confidential file (SensitiveFile.docx).
2. Run the Playbook:
o Observe the following:
§ File access details are extracted.
§ User privileges are checked and found unauthorised.
§ File sensitivity is verified as "Confidential."
§ The user account is disabled, and the SOC analyst is notified.
3. Review Output:
o Confirm the enriched alert in the case management system.
o Verify that unauthorised access was flagged, and appropriate actions were
taken.

Step 5: Deploy the Playbook

1. Assign the playbook to the production environment.

2. Configure the trigger to monitor file access events in real time.

Step 6: Monitor Performance

1. Track Key Metrics:

o Detection Time: Ensure unauthorised access is detected within seconds.
o Response Time: Verify that user accounts are disabled within 2 minutes.
o False Positive Rate: Minimise incorrect blocking actions through refined
rules.
o Analyst Feedback: Confirm that alerts and actions are actionable and
accurate.
2. Visualise Performance:
o Use Splunk SOAR’s dashboard to monitor metrics like time-to-detection,
success rates, and incident resolution efficiency over time.
Use Case 23: Social Engineering Attack Prevention
Step 1: Define the Use Case

• Use Case Name: Social Engineering Attack Prevention

• Description: Detects and mitigates potential social engineering attacks, such as
phishing or pretexting attempts, by identifying suspicious communications and
taking proactive measures.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks > Create New Playbook.
2. Select Visual Editor:
o Use the drag-and-drop visual editor for ease of workflow creation.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger node to monitor communication channels (e.g., email logs,
chat systems) for alerts flagged by connected SIEM tools or email security
gateways (e.g., Proofpoint, Microsoft Defender for Office 365).
o Configure the trigger to activate on emails or messages containing
suspicious content, such as fake URLs, urgent requests, or unusual sender
addresses.
2. Extract Communication Details Node:
o Use the Artifact Extraction action to parse details from the alert, including:
§ Sender address.
§ Recipient address.
§ Subject and body content.
§ Attachments or URLs.
3. Phishing URL Analysis Node:
o Add an Action node to query threat intelligence sources (e.g., VirusTotal,
OpenPhish) for reputation checks on URLs and attachments found in the
communication.
o Input the extracted data into the API request.
4. User Behavior Verification Node:
o Add an Action node to check recent activity of the recipient user in the
Identity Management System or endpoint protection platform.
o Look for anomalies such as failed login attempts or unusual access
patterns.
5. Decision Node:
o Insert a Decision node to evaluate the threat level:
§ High Risk: If the URL or attachment is flagged as malicious, or if user
behavior is abnormal.
 § Low Risk: If no malicious indicators are detected.
6. Immediate Mitigation Node:
o For High Risk, add an Action node to:
§ Quarantine the email or block the suspicious communication.
§ Notify the recipient of a potential threat and provide awareness
guidance.
7. Update Case Node:
o Enrich the original alert with details about:
§ Sender information.
§ Malicious indicators (e.g., flagged URLs or attachments).
§ Actions taken (e.g., email quarantined).
8. Notify Analyst Node:
o Add a Send Email action to notify the SOC analyst, including:
§ The sender and recipient details.
§ The flagged content.
§ Actions performed.

Step 4: Save and Test the Playbook

1. Simulate Alert:
o Use Splunk SOAR’s simulation environment to generate a phishing email
alert with a malicious link (phishingsite.com).
2. Run the Playbook:
o Observe the following:
§ Email details are extracted.
§ The malicious link is flagged by VirusTotal.
§ The email is quarantined, and the recipient is notified.
§ A summary is sent to the SOC analyst.
3. Review Output:
o Confirm that the email was successfully quarantined.
o Verify that the analyst and recipient received appropriate notifications.

Step 5: Deploy the Playbook

1. Assign the playbook to the production environment.

2. Configure the trigger to monitor communication channels in real-time.

Step 6: Monitor Performance

1. Track Key Metrics:

o Detection Time: Ensure threats are detected within seconds.
o Response Time: Verify emails are quarantined and recipients notified within
2 minutes.
o False Positive Rate: Minimise legitimate emails flagged as malicious.
 o User Feedback: Gather insights on the effectiveness of awareness
notifications.
2. Visualise Performance:
o Use Splunk SOAR’s dashboard to track detection times, incident trends, and
analyst response rates over time.
Use Case 24: Dark Web Monitoring and Alerting
Step 1: Define the Use Case

• Use Case Name: Dark Web Monitoring and Alerting

• Description: Proactively monitors dark web forums, marketplaces, and data leaks
for mentions of the organization’s sensitive information, such as credentials, PII, or
intellectual property, and alerts the SOC team for timely action.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks > Create New Playbook.
2. Select Visual Editor:
o Use the drag-and-drop visual editor for a simplified workflow creation.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger node to activate on alerts from dark web monitoring tools (e.g.,
Recorded Future, SpyCloud, Cybersixgill) or custom scrapers.
o Configure the trigger to monitor for matches on keywords, domain names, or
employee email addresses.
2. Extract Dark Web Data Node:
o Use the Artifact Extraction action to parse data from the alert, such as:
§ Mentioned keywords or credentials.
§ Source of the dark web post.
§ Time and date of the discovery.
3. Threat Validation Node:
o Add an Action node to cross-reference the leaked information with internal
databases or SIEM tools:
§ Verify if the exposed data is valid or active.
§ Check if any exposed credentials match currently used accounts.
4. Decision Node:
o Insert a Decision node to determine the level of risk:
§ High Risk: If the leaked data is valid or highly sensitive (e.g., active
credentials).
§ Low Risk: If the data is outdated or irrelevant.
5. Immediate Mitigation Node:
o For High Risk, add an Action node to:
§ Notify affected individuals or departments to change credentials or
secure systems.
§ Temporarily disable compromised accounts.
§ Flag the source of the leak for further investigation.
6. Update Case Node:
 o Enrich the original alert with:
§ Details of the leak (e.g., forum post, marketplace listing).
§ Actions taken to mitigate the threat.
7. Notify Analyst Node:
o Add a Send Email action to notify the SOC analyst with:
§ A summary of the leaked data.
§ Actions performed and suggested next steps.

Step 4: Save and Test the Playbook

1. Simulate Alert:
o Use Splunk SOAR’s simulation environment to create a mock alert for a
leaked credential ([email protected]) detected on a dark web forum.
2. Run the Playbook:
o Observe the following:
§ Extracted data is validated and found to be active credentials.
§ The affected account is disabled, and the user is notified to reset their
password.
§ A notification is sent to the SOC analyst.
3. Review Output:
o Confirm the enriched alert in the case management system.
o Verify that mitigation actions and analyst notifications were executed
successfully.

Step 5: Deploy the Playbook

1. Assign the playbook to the production environment.

2. Configure the trigger to monitor dark web alerts in real-time.

Step 6: Monitor Performance

1. Track Key Metrics:

o Detection Time: Ensure dark web mentions are detected within minutes.
o Response Time: Verify that mitigation actions occur within 5 minutes of
detection.
o Leak Reoccurrence: Monitor if similar leaks appear in future alerts.
o Analyst Feedback: Ensure provided data helps with further investigations
and incident resolution.
2. Visualise Performance:
o Use Splunk SOAR’s dashboard to track the frequency of dark web alerts,
response times, and the effectiveness of mitigation actions over time.
Use Case 25: Network Anomaly Detection and Response
Step 1: Define the Use Case

• Use Case Name: Network Anomaly Detection and Response

• Description: Identifies and responds to unusual network activity, such as abnormal
traffic patterns, unexpected bandwidth usage, or suspicious connections, to
prevent potential threats.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks > Create New Playbook.
2. Select Visual Editor:
o Use the drag-and-drop visual editor for streamlined workflow design.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger node to activate on alerts from network monitoring tools (e.g.,
Zeek, Cisco Stealthwatch, or a SIEM like Splunk or QRadar).
o Configure the trigger to monitor for:
§ Traffic spikes.
§ Anomalous IP communications.
§ Protocol misuse or unusual port activity.
2. Extract Network Anomalies Node:
o Use the Artifact Extraction action to parse details such as:
§ Source and destination IPs.
§ Protocols and ports involved.
§ Bandwidth usage metrics.
3. Threat Intelligence Correlation Node:
o Add an Action node to query threat intelligence sources (e.g., VirusTotal,
AbuseIPDB) for reputation checks on the source/destination IPs or domains.
o Input extracted data into the API requests.
4. Decision Node:
o Add a Decision node to determine the risk level based on findings:
§ High Risk: If the IPs or domains are flagged malicious, or traffic
behavior is highly abnormal.
§ Low Risk: If no malicious indicators are found, and the anomaly
seems explainable.
5. Immediate Mitigation Node:
o For High Risk, add an Action node to:
§ Block the IP or connection via firewall automation (e.g., Palo Alto,
Fortinet).
§ Isolate the affected device from the network.
 6. Update Case Node:
o Enrich the original alert with:
§ Contextual details (e.g., suspected intent, traffic logs).
§ Actions performed (e.g., IP blocked, device isolated).
7. Notify Analyst Node:
o Add a Send Email action to notify the SOC analyst with:
§ The anomaly details.
§ Actions taken and any unresolved concerns.

Step 4: Save and Test the Playbook

1. Simulate Alert:
o Use Splunk SOAR’s simulation environment to generate a mock alert for
unusual traffic involving a suspicious IP (203.0.113.50) and high outbound
traffic on port 22.
2. Run the Playbook:
o Observe the following:
§ Network anomalies are extracted and analyzed.
§ The suspicious IP is flagged as malicious by VirusTotal.
§ The IP is blocked, and the affected device is isolated.
§ A notification is sent to the SOC analyst.
3. Review Output:
o Confirm the enriched alert and actions in the case management system.
o Verify the effectiveness of the automated response and the analyst
notification.

Step 5: Deploy the Playbook

1. Assign the playbook to the production environment.

2. Configure the trigger to monitor network anomaly alerts in real-time.

Step 6: Monitor Performance

1. Track Key Metrics:

o Detection Time: Ensure anomalies are detected within seconds.
o Response Time: Verify threats are mitigated within 5 minutes of detection.
o False Positives: Minimize unnecessary blocks or device isolations.
o Analyst Feedback: Confirm data accuracy and response efficiency.
2. Visualise Performance:
o Use Splunk SOAR’s dashboard to monitor anomaly trends, response times,
and the playbook’s success rate in mitigating network threats.
 o s effectively by providing immediate and effective mitigation actions.
2. Visualize Playbook Performance:
o Use dashboards to track metrics like the number of blocked exploit
attempts, time taken for mitigation, and the severity of incidents handled by
the playbook.
o Visualize trends and identify areas for improvement, such as response times
or the detection of new exploit patterns.
Use Case 50: Automated Response Playbook Testing
Step 1: Define the Use Case

• Use Case Name: Automated Response Playbook Testing

• Description: Automates the testing of security response playbooks to ensure that
they perform as expected in different scenarios. This playbook simulates a variety of
security incidents to validate the effectiveness and accuracy of the automated
responses defined in existing playbooks, ensuring a seamless response during
actual incidents.

Step 2: Create the Playbook

1. Navigate to Playbooks:
o Go to Automation > Playbooks > Create New Playbook.
2. Select Visual Editor:
o Choose the drag-and-drop visual editor to build the testing workflow.

Step 3: Design the Workflow in the Playbook Editor

1. Trigger Node:
o Add a Trigger Node to activate the playbook.
o Set up a manual trigger or use a scheduled time to simulate various security
incidents for testing purposes.
§ Example triggers:
§ A scheduled simulation of a ransomware attack.
§ A simulated DDoS event.
§ A mock phishing attempt alert.
2. Simulated Incident Generation Node:
o Add an Action Node that will simulate different types of security incidents
for testing purposes.
§ Use tools such as Splunk, QRadar, or other testing tools to generate
test alerts for various scenarios.
§ Example scenarios:
§ Malware detection (e.g., ransomware).
§ Unauthorized access attempt (e.g., brute force).
§ Abnormal network traffic (e.g., DDoS).
3. Run Automated Response Playbook:
o Add an Action Node to trigger the existing response playbooks based on the
simulated incidents generated in the previous step.
§ Example playbooks to test:
§ Ransomware Response Playbook.
§ DDoS Mitigation Playbook.
§ Phishing Attack Response Playbook.
4. Evaluate Response Execution Node:
 o Add a Decision Node to evaluate if the automated responses triggered by
the playbooks execute as expected.
§ Check for:
§ Alert generation and enrichment.
§ Mitigation actions (e.g., blocking IPs, isolating devices).
§ Case creation and incident management.
5. Validation Node:
o Add an Action Node to validate whether the correct actions were taken
during the playbook execution.
§ Compare the actions triggered by the playbook against a predefined
success criteria.
§ Example validation steps:
§ Ensure that alerts are generated for incidents.
§ Confirm that mitigation actions (e.g., blocking a malicious IP)
were successful.
§ Ensure that case creation or updates are properly logged.
6. Alerting and Reporting Node:
o Add an Action Node to notify stakeholders about the outcome of the testing.
§ Send an email or platform notification to SOC analysts and relevant
teams with a summary of the test results.
§ Include any issues found, such as failed actions or incomplete
responses.
7. Post-Test Analysis Node:
o Add an Action Node to collect logs and data generated during the test for
post-test analysis.
§ Gather logs from the SIEM, incident management system, and any
other relevant sources.
§ Create a detailed report summarizing the test's success and
identifying areas for improvement.

Step 4: Save and Test the Playbook

1. Simulate Incident and Run Playbook:

o Manually trigger the playbook or schedule tests to simulate different security
events (e.g., malware infection, unauthorized login attempts).
2. Run the Playbook:
o Monitor the playbook execution to ensure that it runs as expected.
§ Test various scenarios, such as ransomware, phishing, or network
anomalies.
§ Confirm that automated responses, like alerts and mitigation steps,
are triggered.
3. Review Output:
o After running the playbook, check:
§ Whether the playbook correctly executed the response actions.
 § If there are any failures or errors in the automated steps.
§ Ensure that reports and notifications were sent as expected.

Step 5: Deploy the Playbook

1. Deploy to Testing Environment:

o Once the playbook has been tested and validated, deploy it to the
production environment with a test setup.
2. Integrate with Monitoring Tools:
o Integrate the playbook testing process with SIEM, threat intelligence
platforms, and other tools to ensure seamless incident simulation and
testing in the future.

Step 6: Monitor Performance

1. Track Key Metrics:

o Test Success Rate: Monitor how often the playbooks successfully execute
without failures.
o Time to Response: Measure how quickly the automated response actions
are triggered during a simulated incident.
o False Positive/Negative Rate: Monitor how often the playbooks incorrectly
identify or fail to identify incidents.
2. Performance Reporting:
o Use dashboards and reports to visualize the effectiveness of the playbooks.
o Track trends in the testing outcomes, identifying areas that need refinement
or improvement.
o Regularly analyze the results of each test to improve response actions and
decision-making processes.