Security Incident Recommended Actions
Overview
This skill generates structured, prioritized response actions for security incidents by analyzing threat type, severity, affected assets, and organizational playbooks. It produces phased action plans covering containment, eradication, and recovery aligned with NIST SP 800-61 and organizational SOC procedures.
Key capabilities:
- Threat-Specific Actions: Generate actions tailored to the specific threat category (malware, phishing, data exfiltration, DDoS, insider threat, etc.)
- Severity-Based Prioritization: Scale response urgency and depth based on incident severity and business criticality
- Asset-Aware Recommendations: Adjust actions based on the type, environment, and criticality of affected assets
- Playbook Alignment: Map recommended actions to existing organizational playbooks and runbooks
- Phased Response Plan: Structure actions into containment, eradication, recovery, and post-incident phases
- MITRE ATT&CK Mapping: Reference specific ATT&CK techniques to guide detection and response
When to use:
- When a new security incident is created and the analyst needs response guidance
- During incident escalation to ensure all critical actions are covered
- For junior analysts who need structured guidance on response procedures
- When reviewing incident response completeness before closure
- To generate standardized response plans for recurring threat types
Prerequisites
- Roles:
sn_si.analyst,sn_si.manager, oradmin - Plugins: Security Incident Response (
sn_si), Threat Intelligence (sn_ti), Vulnerability Response (sn_vul) - Access: Read access to
sn_si_incident,sn_si_task,sn_ti_observable,cmdb_ci,sn_vul_vulnerable_item - Knowledge: Familiarity with NIST SP 800-61, MITRE ATT&CK framework, and organizational playbook structure
Key Tables
| Table | Purpose | Key Fields |
|---|---|---|
sn_si_incident |
Security incidents | number, category, subcategory, priority, severity, state, cmdb_ci, attack_vector, kill_chain_phase, business_criticality |
sn_si_task |
Response tasks | number, short_description, state, task_type, security_incident, assigned_to, priority |
sn_ti_observable |
Threat indicators | type, value, confidence, threat_score, security_incident |
cmdb_ci |
Affected assets | name, sys_class_name, ip_address, os, environment, business_criticality |
sn_vul_vulnerable_item |
Known vulnerabilities | vulnerability, cmdb_ci, state, cvss_score, risk_score |
Procedure
Step 1: Retrieve Incident Details and Classification
Fetch the complete incident record with threat classification fields.
Using MCP (Claude Code/Desktop):
Tool: SN-Get-Record
Parameters:
table_name: sn_si_incident
sys_id: [INCIDENT_SYS_ID]
fields: sys_id,number,short_description,description,category,subcategory,priority,severity,state,cmdb_ci,attack_vector,kill_chain_phase,business_criticality,risk_score,assigned_to,assignment_group,opened_at,contact_type,affected_user
Using REST API:
GET /api/now/table/sn_si_incident?sysparm_query=number=[SIR_NUMBER]&sysparm_fields=sys_id,number,short_description,description,category,subcategory,priority,severity,state,cmdb_ci,attack_vector,kill_chain_phase,business_criticality,risk_score,assigned_to,assignment_group,opened_at&sysparm_limit=1&sysparm_display_value=all
Step 2: Gather Affected Asset Context
Retrieve configuration item details to understand the business context of affected systems.
Using MCP:
Tool: SN-Query-Table
Parameters:
table_name: cmdb_ci
query: sys_id=[CMDB_CI_SYS_ID]
fields: sys_id,name,sys_class_name,ip_address,os,environment,business_criticality,support_group,department,location,operational_status
limit: 1
Using REST API:
GET /api/now/table/cmdb_ci?sysparm_query=sys_id=[CI_SYS_ID]&sysparm_fields=sys_id,name,sys_class_name,ip_address,os,environment,business_criticality,support_group,department,location,operational_status&sysparm_limit=1&sysparm_display_value=true
Step 3: Collect Threat Indicators
Pull IOCs to inform threat-specific containment and eradication actions.
Using MCP:
Tool: SN-Query-Table
Parameters:
table_name: sn_ti_observable
query: security_incident=[INCIDENT_SYS_ID]
fields: sys_id,type,value,source,confidence,threat_score,first_seen,last_seen
limit: 100
Using REST API:
GET /api/now/table/sn_ti_observable?sysparm_query=security_incident=[INCIDENT_SYS_ID]&sysparm_fields=sys_id,type,value,source,confidence,threat_score&sysparm_limit=100
Step 4: Check Known Vulnerabilities on Affected Assets
Identify exploitable vulnerabilities that may have enabled the attack.
Using MCP:
Tool: SN-Query-Table
Parameters:
table_name: sn_vul_vulnerable_item
query: cmdb_ci=[AFFECTED_CI_SYS_ID]^stateINOpen,Under Investigation
fields: sys_id,vulnerability,cmdb_ci,state,cvss_score,risk_score,first_found
limit: 20
Using REST API:
GET /api/now/table/sn_vul_vulnerable_item?sysparm_query=cmdb_ci=[CI_SYS_ID]^stateINOpen,Under Investigation&sysparm_fields=sys_id,vulnerability,cmdb_ci,state,cvss_score,risk_score,first_found&sysparm_limit=20&sysparm_display_value=true
Step 5: Review Existing Response Tasks
Check what tasks already exist to avoid duplication.
Using MCP:
Tool: SN-Query-Table
Parameters:
table_name: sn_si_task
query: security_incident=[INCIDENT_SYS_ID]^ORDERBYopened_at
fields: sys_id,number,short_description,state,task_type,assigned_to,priority
limit: 50
Step 6: Generate Recommended Actions
Produce phased, threat-specific response actions.
Using MCP:
Tool: SN-Execute-Background-Script
Parameters:
script: |
var sirNumber = 'SIR0009100'; // Replace with target incident
var gr = new GlideRecord('sn_si_incident');
gr.addQuery('number', sirNumber);
gr.query();
if (!gr.next()) { gs.info('Incident not found'); return; }
var category = gr.category.getDisplayValue().toLowerCase();
var severity = gr.severity.getDisplayValue();
var priority = parseInt(gr.priority.toString()) || 3;
var ciSysId = gr.cmdb_ci.toString();
var actions = { containment: [], eradication: [], recovery: [], post_incident: [] };
// Get CI details
var ciType = 'unknown';
var ciEnv = 'unknown';
if (ciSysId) {
var ci = new GlideRecord('cmdb_ci');
if (ci.get(ciSysId)) {
ciType = ci.sys_class_name.toString();
ciEnv = ci.environment.getDisplayValue() || 'unknown';
}
}
// Collect IOCs
var iocCount = 0;
var iocTypes = {};
var obs = new GlideRecord('sn_ti_observable');
obs.addQuery('security_incident', gr.sys_id.toString());
obs.query();
while (obs.next()) {
iocCount++;
var t = obs.type.getDisplayValue() || 'other';
iocTypes[t] = (iocTypes[t] || 0) + 1;
}
// === CONTAINMENT ACTIONS ===
// Universal containment
actions.containment.push({
action: 'Document initial findings and preserve volatile evidence',
priority: 1, owner: 'SOC Analyst', timeline: 'Immediate',
details: 'Capture memory dump, running processes, network connections before any changes'
});
if (category.indexOf('malware') >= 0 || category.indexOf('ransomware') >= 0) {
actions.containment.push({
action: 'Isolate affected host(s) from network',
priority: 1, owner: 'Network Operations', timeline: '< 30 minutes',
details: 'Apply network isolation via EDR or switch port disable. Do NOT power off to preserve memory.'
});
actions.containment.push({
action: 'Block identified C2 IPs and domains at perimeter',
priority: 1, owner: 'SOC Analyst', timeline: '< 1 hour',
details: 'Update firewall rules and DNS sinkhole for ' + iocCount + ' identified IOCs'
});
actions.eradication.push({
action: 'Remove malware artifacts and persistence mechanisms',
priority: 1, owner: 'DFIR Team', timeline: '< 24 hours',
details: 'Scan with updated signatures, check scheduled tasks, registry run keys, WMI subscriptions'
});
actions.recovery.push({
action: 'Rebuild or restore affected systems from known-good baseline',
priority: 2, owner: 'IT Operations', timeline: '24-48 hours',
details: 'Reimage ' + (ciType.indexOf('server') >= 0 ? 'server' : 'workstation') + ' from golden image or verified backup'
});
}
if (category.indexOf('phishing') >= 0) {
actions.containment.push({
action: 'Quarantine phishing email from all mailboxes',
priority: 1, owner: 'Email Security', timeline: '< 1 hour',
details: 'Use email security tool to search and purge by sender, subject, or message ID'
});
actions.containment.push({
action: 'Reset credentials for affected user(s)',
priority: 1, owner: 'IAM Team', timeline: '< 2 hours',
details: 'Force password reset and revoke active sessions for compromised accounts'
});
actions.eradication.push({
action: 'Block sender domain and update email filtering rules',
priority: 2, owner: 'Email Security', timeline: '< 4 hours',
details: 'Add sender to blocklist and create content filtering rule for similar messages'
});
}
if (category.indexOf('data') >= 0 || category.indexOf('exfiltration') >= 0 || category.indexOf('breach') >= 0) {
actions.containment.push({
action: 'Identify and block data exfiltration channels',
priority: 1, owner: 'SOC Analyst', timeline: '< 1 hour',
details: 'Review DLP alerts, proxy logs, and cloud storage activity for ongoing exfiltration'
});
actions.containment.push({
action: 'Revoke access for compromised accounts and API keys',
priority: 1, owner: 'IAM Team', timeline: '< 2 hours',
details: 'Disable affected service accounts, rotate API keys, revoke OAuth tokens'
});
actions.recovery.push({
action: 'Assess data exposure scope and prepare regulatory notification',
priority: 1, owner: 'Legal/Privacy Team', timeline: '< 72 hours',
details: 'Determine data types affected, number of records, and applicable notification requirements'
});
}
// Universal eradication
actions.eradication.push({
action: 'Patch exploited vulnerabilities on affected and similar systems',
priority: 2, owner: 'Vulnerability Management', timeline: '< 72 hours',
details: 'Apply patches for identified CVEs; scan environment for same vulnerability'
});
// Universal recovery
actions.recovery.push({
action: 'Validate system integrity and restore to operational status',
priority: 2, owner: 'IT Operations', timeline: '48-72 hours',
details: 'Verify clean state, run integrity checks, restore network connectivity with monitoring'
});
actions.recovery.push({
action: 'Enhance monitoring on recovered systems for 30 days',
priority: 3, owner: 'SOC Analyst', timeline: 'Ongoing',
details: 'Increase logging verbosity, add detection rules for related IOCs and TTPs'
});
// Post-incident
actions.post_incident.push({
action: 'Conduct post-incident review and document lessons learned',
priority: 3, owner: 'SOC Manager', timeline: '< 2 weeks post-resolution',
details: 'Review detection time, response effectiveness, and identify process improvements'
});
actions.post_incident.push({
action: 'Update playbooks and detection rules based on findings',
priority: 3, owner: 'Detection Engineering', timeline: '< 30 days post-resolution',
details: 'Create or update detection signatures, SIEM correlation rules, and response procedures'
});
var result = {
incident: sirNumber,
category: category,
severity: severity,
total_actions: actions.containment.length + actions.eradication.length + actions.recovery.length + actions.post_incident.length,
phases: actions
};
gs.info('RECOMMENDED ACTIONS:\n' + JSON.stringify(result, null, 2));
description: "SecOps: Generate phased response actions for a security incident"
Step 7: Post Actions as Work Notes
Using MCP:
Tool: SN-Add-Work-Notes
Parameters:
table_name: sn_si_incident
sys_id: [INCIDENT_SYS_ID]
work_notes: |
=== RECOMMENDED RESPONSE ACTIONS ===
Generated: 2026-03-19 | Category: Ransomware | Severity: Critical
PHASE 1 - CONTAINMENT (Immediate):
[ ] Document findings and preserve volatile evidence (SOC Analyst, Immediate)
[ ] Isolate affected hosts from network (Network Ops, < 30 min)
[ ] Block C2 IPs/domains at perimeter (SOC Analyst, < 1 hour)
PHASE 2 - ERADICATION (24-72 hours):
[ ] Remove malware and persistence mechanisms (DFIR Team, < 24 hours)
[ ] Patch exploited vulnerabilities (Vuln Mgmt, < 72 hours)
PHASE 3 - RECOVERY (48-72 hours):
[ ] Rebuild affected systems from known-good baseline (IT Ops, 24-48 hours)
[ ] Validate system integrity (IT Ops, 48-72 hours)
[ ] Enhance monitoring for 30 days (SOC Analyst, Ongoing)
PHASE 4 - POST-INCIDENT (2-4 weeks):
[ ] Conduct lessons learned review (SOC Manager, < 2 weeks)
[ ] Update playbooks and detection rules (Detection Engineering, < 30 days)
Tool Usage
| Operation | MCP Tool | REST Endpoint |
|---|---|---|
| Read Incident | SN-Get-Record | GET /api/now/table/sn_si_incident/{sys_id} |
| Query Assets | SN-Query-Table | GET /api/now/table/cmdb_ci |
| Query IOCs | SN-Query-Table | GET /api/now/table/sn_ti_observable |
| Query Vulnerabilities | SN-Query-Table | GET /api/now/table/sn_vul_vulnerable_item |
| Generate Actions | SN-Execute-Background-Script | POST /api/now/table/sys_trigger |
| Post Actions | SN-Add-Work-Notes | PATCH /api/now/table/sn_si_incident/{sys_id} |
Best Practices
- Phase-Based Structure: Always organize actions into containment, eradication, recovery, and post-incident phases per NIST SP 800-61
- Threat-Specific Tailoring: Customize actions for the specific threat type; generic actions waste analyst time
- Evidence Preservation First: Always recommend evidence preservation before containment actions that may alter system state
- Owner Clarity: Assign each action to a specific team or role, not just "the team"
- Timeline Realism: Set timelines that account for change management requirements in production environments
- Deduplication: Check existing tasks before generating recommendations to avoid redundancy
- Escalation Triggers: Include criteria for when to escalate (e.g., lateral movement detected, data exfiltration confirmed)
Troubleshooting
Incident Category Not Recognized
Symptom: Generated actions are too generic because the category does not match expected values
Cause: Organizations may use custom category and subcategory values
Solution: Query sys_choice for sn_si_incident.category to retrieve valid values. Map custom categories to standard threat types (malware, phishing, data breach, etc.).
No IOCs Linked to Incident
Symptom: Threat-specific containment actions cannot be generated without IOCs
Cause: Threat intelligence may not be integrated or observables not yet linked
Solution: Recommend IOC collection as the first containment action. Search sn_ti_observable by date range for recently ingested indicators.
Playbook Not Found for Category
Symptom: Actions cannot be aligned to an organizational playbook
Cause: The sn_si_playbook table may not contain a playbook for the incident category
Solution: Generate actions from the built-in threat taxonomy and recommend playbook creation as a post-incident action.
Examples
Example 1: Ransomware Incident Response Plan
Scenario: SIR0009100 -- LockBit ransomware detected on finance file server
- Retrieve incident: Category "Ransomware", Severity "Critical", Production server
- Gather asset context: FILESVR-03, Windows Server 2022, Business Criticality High
- Collect 6 IOCs: 2 IPs, 1 domain, 2 file hashes, 1 email address
- Identify 2 exploitable CVEs on affected server
- Generate 12 actions across 4 phases with specific timelines and owners
- Post checklist-format actions to incident work notes
Example 2: Phishing Campaign Response
Scenario: SIR0008890 -- Credential harvesting phishing targeting 50 users
- Retrieve incident: Category "Phishing", Severity "High", 50 affected users
- No specific CI -- impacted entity is user mailboxes
- IOCs: 1 sender domain, 1 phishing URL, 1 form submission endpoint
- Generate 9 actions: email purge, credential reset, URL blocking, user notification
- Include post-incident recommendation for phishing awareness training
Related Skills
secops/incident-summarization- Summarize the incident alongside recommended actionssecops/post-incident-analysis- Assess whether recommended actions were properly executedsecops/vulnerability-deduplication- Consolidate duplicate vulnerabilities before prioritizing actionssecops/correlation-insights- Identify related incidents that may share response actionssecops/shift-handover- Include pending actions in shift handover reports