Incident Response Policy Template NIST

Standard Operating Procedure: NIST-Aligned Incident Response Policy & Execution Template

Document ID: SOP-TR-SEC-042
Effective Date: October 24, 2023
Version: 3.1.0
Review Cadence: Annual (or post-Incident Root Cause Analysis)
Author: Julian Vance, Chief Architect, Template Registry

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) operationalizes the National Institute of Standards and Technology (NIST) Special Publication 800-61 Rev. 2 (Computer Security Incident Handling Guide) framework for Template Registry infrastructure. The purpose of this document is to establish a repeatable, forensically sound, and legally defensible methodology for detecting, containing, eradicating, and recovering from information security incidents. Compliance with this SOP is mandatory for all engineering, operations, and security personnel.

---

2. Scope & Prerequisites

2.1 Scope

This policy applies to all physical, virtual, cloud-hosted (AWS/GCP), and on-premises information systems, endpoints, networks, and data repositories owned, operated, or processed by Template Registry.

2.2 Prerequisites & Tooling

Execution of this SOP requires access to and operational competency in the following toolchains:

• SIEM/Log Management: Datadog / Splunk Enterprise Security.
• Endpoint Detection & Response (EDR): CrowdStrike Falcon.
• Cloud Infrastructure Management: AWS IAM, AWS CloudTrail, GuardDuty, VPC Flow Logs.
• Forensic Capture Tools: LiME (Linux Memory Extractor), Volatility Foundation, FTK Imager.
• Collaboration & Ticketing: Jira Service Management (Incident Command channel), PagerDuty.

---

3. Roles & Responsibilities (RACI Matrix)

(R = Responsible, A = Accountable, C = Consulted, I = Informed)

---

4. Step-by-Step Procedure (NIST 6-Phase Lifecycle)

Phase 1: Preparation

• Ensure continuous logging is active across all cloud and on-prem assets with a minimum retention period of 365 days.
• Verify automated alerting rules in SIEM/EDR are synchronized with current threat intelligence feeds.
• Conduct bi-annual tabletop exercises simulating ransomware, data exfiltration, and unauthorized privilege escalation.
• Maintain an updated, off-network cryptographic backup of all critical template repositories and core databases.

Phase 2: Detection & Analysis

• Triage Alert: Acknowledge PagerDuty high-severity alerts within 15 minutes of generation.
• Initial Assessment: Query SIEM and EDR telemetry to validate indicators of compromise (IoCs)—such as abnormal egress traffic, privilege abuse, or unexpected binary execution.
• Scope Determination: Identify all impacted systems, compromised user credentials, and potentially exfiltrated data stores.
• Incident Declaration: If a threshold of unauthorized access or data compromise is met, the SOC Lead opens a critical Incident Jira ticket and pages the Incident Commander (IC).

Phase 3: Containment

• Execute Short-Term Containment: Isolate infected endpoints via EDR network-quarantine capabilities (crowdstrike:isolate).
• Credential Revocation: Immediately invalidate active sessions, rotate API keys, and force password resets for all compromised IAM accounts.
• Network Segmentation: Modify AWS Security Groups and Network ACLs to block malicious IP ranges or isolate compromised VPC subnets without destroying volatile memory.
• Preserve Evidence: Take forensic snapshots of affected virtual machine instances (AWS EBS snapshots) and capture volatile RAM prior to making runtime alterations.

Phase 4: Eradication

• Root Cause Identification: Analyze forensic artifacts to determine the initial vector of compromise (e.g., unpatched CVE, compromised credential, phishing).
• Malware Removal: Terminate malicious processes, delete unauthorized dropped binaries, and remove unauthorized scheduled tasks or cron jobs.
• Vulnerability Remediation: Patch underlying software vulnerabilities or misconfigurations that allowed the initial intrusion.
• Verify Sanitization: Run full-system EDR scans across related nodes to confirm complete removal of malicious artifacts.

Phase 5: Recovery

• System Restoration: Rebuild compromised hosts from verified, clean golden machine images (AMIs) or restore databases from pre-incident cryptographic backups.
• Integrity Verification: Execute automated functional and regression test suites against restored systems to ensure operational integrity.
• Staged Reconnection: Gradually reintroduce restored systems to production traffic under heightened monitoring for a minimum of 72 hours.
• Formal Closure: Declare the incident contained and recovered; close the PagerDuty incident and transition ticket status to "Post-Mortem Pending".

Phase 6: Post-Incident Activity (Lessons Learned)

• Schedule Post-Mortem: Convene a mandatory review meeting within 5 business days of incident closure with all core stakeholders.
• Draft Root Cause Analysis (RCA): Document the timeline, attack vector, impact radius, and response efficacy.
• Action Item Tracking: Create Jira tasks for preventive controls identified during the RCA, assigning explicit engineering owners and hard deadlines.
• Policy Update: Revise system architectures, detection signatures, or SOP documentation to prevent recurrence.

---

5. Quality Assurance, Metrics & Pro-Tips

5.1 Key Performance Indicators (KPIs) & Thresholds

• Mean Time to Detect (MTTD): Target $< 15$ minutes for High/Critical severity alerts.
• Mean Time to Acknowledge (MTTA): Target $< 15$ minutes 24/7/365.
• Mean Time to Contain (MTTC): Target $< 60$ minutes from incident validation.

5.2 Pro-Tips & Common Pitfalls

• DO NOT reboot systems prematurely. Rebooting destroys volatile RAM artifacts required for advanced forensic root-cause analysis. Always isolate the network interface first, then take a memory snapshot.
• Maintain Out-of-Band Communications. Never rely solely on corporate Slack/Teams if Active Directory or corporate identity providers are compromised. Use pre-established, out-of-band Signal channels for Incident Command discussions.

---

6. Frequently Asked Questions (FAQ)

Q: At what point must Legal and PR be notified of a security event?
A: Legal counsel and Corporate Communications must be briefed by the Incident Commander within 2 hours of confirming an incident involving PII (Personally Identifiable Information), customer data exfiltration, or regulatory compliance exposure (e.g., GDPR, CCPA). Do not release external statements without prior sign-off from Legal.

Q: What is the exact protocol if an administrator account is suspected of compromise?
A: Immediately disable the IAM user profile, terminate all active Multi-Factor Authentication (MFA) tokens, rotate the AWS Root/Master credentials if necessary, and inspect CloudTrail logs for unauthorized API calls executed within the preceding 72 hours.