Windows [00000002] Security Incident Response Playbook

Purpose

This playbook provides a standardised procedure for responding to security incidents reported to or detected by the Information Security team. It covers the four most common incident types at this institution:

1. Phishing emails
2. Credential compromise (account takeover)
3. Malware / ransomware detection
4. Suspected unauthorised access to systems

Severity Classification

Incident Response Phases

Phase 1 — Detection & Reporting

Security incidents may be reported via:

• User-submitted ticket at it.example.edu/support
• Automated SIEM alert (Wazuh → PagerDuty)
• Email to security@example.edu
• Direct call to the SecOps on-call line: ext. 5557

All incidents must be logged in the incident tracking system within 30 minutes of detection.

Phase 2 — Triage (0–30 min)

1. Assign a severity using the table above.
2. For P1/P2: page the Security Manager immediately.
3. Gather initial context:
   • What was reported or alerted?
   • Which user(s), system(s), or data are involved?
   • Is the incident ongoing or historical?

Phase 3 — Containment

Phishing Email Campaign

1. Quarantine all copies of the phishing email across all mailboxes:

   # Exchange Online PowerShell
   Search-UnifiedAuditLog -StartDate ... -EndDate ... -FreeText "phishing subject"
   New-ComplianceSearchAction -Purge -PurgeType SoftDelete
   

2. Block the sender domain and malicious URLs in the email gateway.
3. Post a user advisory on the Beacon portal if the campaign is widespread.

Credential Compromise / Account Takeover

1. Immediately disable the affected account in Active Directory:

   Disable-ADAccount -Identity <samAccountName>
   

2. Revoke all active sessions in Azure AD / Entra ID.
3. Force a password reset.
4. Review audit logs for the account for the past 30 days (logins, resource access, email forwarding rules).
5. Check whether MFA was bypassed or not enrolled — escalate to P1 if MFA was bypassed.

Malware / Ransomware

1. Isolate the affected system immediately:
   • Disconnect from the network switch port (or shut down the port: interface gi1/0/X → shutdown)
   • Or disable the NIC if the switch port is not accessible
2. Do not reboot — volatile memory may contain forensic evidence.
3. Engage the vendor IR line if ransomware is confirmed (see Contacts).
4. Identify the infection vector from SIEM logs.
5. Scan all file shares reachable from the affected endpoint for encryption artefacts.

Phase 4 — Investigation & Evidence Collection

1. Collect relevant logs and preserve them to the \\secops-nas\incidents\<ticket-id>\ share.
2. Capture disk images of affected systems before any remediation (use FTK Imager or dd).
3. Document the attack chain: initial access → lateral movement → impact.
4. Determine whether personal data (FERPA, HIPAA) was potentially exposed.

Phase 5 — Remediation

1. Re-image or rebuild affected systems from known-good baselines.
2. Apply all outstanding patches before bringing the system back online.
3. Restore from clean backups if data was corrupted or encrypted.
4. Confirm clean state with a full AV and IOC scan before reconnecting to the network.

Phase 6 — Post-Incident Actions

1. Complete a Security Incident Report (SIR) within 5 business days.
2. If personal data was exposed, notify the Privacy Officer within 24 hours — FERPA / HIPAA breach notification timelines apply.
3. Conduct a lessons-learned review with the Security and IT Operations teams.
4. Update detection rules and playbooks based on findings.

Contacts