security-incident-response

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

When this skill is activated, always start your first response with the 🧢 emoji.

当激活本技能时，你的第一条回复请始终以🧢表情符号开头。

Security Incident Response

安全事件响应

A practitioner's framework for detecting, containing, and recovering from security incidents. This skill covers the full NIST incident response lifecycle - preparation through lessons learned - with emphasis on when to act, what to preserve, and how to communicate under pressure. Designed for engineers and security practitioners who need to respond with speed and precision when a breach is suspected or confirmed.

这是供从业者使用的安全事件检测、遏制与恢复框架。本技能覆盖NIST事件响应全生命周期——从准备阶段到经验总结阶段，重点强调何时采取行动、需要保留什么以及在压力下如何沟通。专为需要在疑似或确认漏洞发生时快速精准响应的工程师和安全从业者设计。

When to use this skill

何时使用本技能

Trigger this skill when the user:

Suspects or confirms a security breach, intrusion, or unauthorized access
Needs to classify incident severity and decide on escalation
Is containing a threat (isolating systems, revoking credentials, blocking IPs)
Needs to preserve forensic evidence or maintain chain of custody
Is communicating an incident to stakeholders, executives, or regulators
Is eradicating malware, backdoors, or persistent access from systems
Is writing a security incident report or post-mortem

Do NOT trigger this skill for:

Proactive security hardening or architectural review (use the backend-engineering security reference instead)
Vulnerability disclosure or bug bounty triage that has not yet become an active incident

当用户出现以下需求时触发本技能：

疑似或确认存在安全漏洞、入侵或未授权访问
需要对事件严重程度进行分类并决定是否升级
正在遏制威胁（隔离系统、撤销凭证、拦截IP）
需要保留取证证据或维护监管链
需向利益相关者、高管或监管机构通报事件
正在从系统中清除恶意软件、后门或持久访问权限
正在撰写安全事件报告或事后分析报告

请勿在以下场景触发本技能：

主动安全加固或架构审查（请改用后端工程安全参考资料）
尚未演变为活跃事件的漏洞披露或漏洞赏金分类

Key principles

核心原则

Contain first, investigate second - Stopping the bleeding takes priority over understanding the wound. Isolate affected systems before collecting forensic evidence if the attacker still has active access. Evidence is recoverable; damage from continued access may not be.
Preserve evidence - Everything you do to an affected system changes it. Use read-only mounts, memory snapshots, and write blockers. Log every command you run. Courts and regulators require chain of custody.
Communicate early and often - A 30-second "we are investigating" message is better than silence for three hours. Stakeholders need to plan. Delayed notification erodes trust far more than the incident itself.
Document everything in real-time - Keep a live incident timeline. Record every action taken, every finding, every decision, and every person involved. Memory fades in 24 hours; your logs won't.
Never blame - Incidents are system failures, not individual failures. A post-mortem that names a person instead of fixing a process produces fear, not improvement. Apply the same principle as SRE blameless post-mortems.

先遏制，后调查 - 止血优先于了解伤口情况。如果攻击者仍有活跃访问权限，请先隔离受影响系统，再收集取证证据。证据可恢复，但持续访问造成的损害可能无法挽回。
保留证据 - 你对受影响系统所做的任何操作都会改变它。使用只读挂载、内存快照和写入拦截器。记录你执行的每一条命令。法院和监管机构要求完整的监管链。
尽早并持续沟通 - 一条30秒的“我们正在调查”消息，比三小时的沉默更好。利益相关者需要提前规划。延迟通报对信任的损害远大于事件本身。
实时记录所有内容 - 维护一份实时事件时间线。记录所采取的每一项行动、每一个发现、每一个决定以及涉及的每一个人。记忆会在24小时内消退，但日志不会。
绝不追责个人 - 事件是系统故障，而非个人失误。如果事后分析报告点名个人而非修复流程，只会滋生恐惧，无法带来改进。请遵循SRE无责事后分析的相同原则。

Core concepts

核心概念

NIST IR Phases

NIST事件响应阶段

The NIST SP 800-61 framework defines six phases that form the backbone of any structured incident response program:

Phase	Goal	Key outputs
Preparation	Build capability before incidents happen	Runbooks, contact lists, tooling, trained responders
Detection & Analysis	Identify that an incident is occurring and understand its scope	Severity classification, initial IOC list, affected asset inventory
Containment	Prevent the incident from spreading or causing more damage	Isolated systems, revoked credentials, blocked IPs/domains
Eradication	Remove the threat from all affected systems	Cleaned/reimaged hosts, patched vulnerabilities, removed persistence mechanisms
Recovery	Restore systems to normal operations safely	Verified clean systems returned to production, monitoring confirmed
Lessons Learned	Improve defenses and process based on what happened	Post-mortem report, process changes, new detections

Phases are not always strictly sequential. Containment and eradication can overlap. Detection and analysis continues throughout the entire response.

NIST SP 800-61框架定义了六个阶段，构成任何结构化事件响应计划的核心：

阶段	目标	关键输出
准备阶段	在事件发生前构建响应能力	运行手册、联系人列表、工具、经过培训的响应人员
检测与分析	识别事件正在发生并了解其范围	严重程度分类、初始IOC列表、受影响资产清单
遏制	防止事件扩散或造成更多损害	隔离的系统、已撤销的凭证、被拦截的IP/域名
根除	从所有受影响系统中清除威胁	已清理/重新镜像的主机、已修补的漏洞、已移除的持久访问机制
恢复	安全地将系统恢复到正常运行状态	已验证干净的系统回归生产、监控确认正常
经验总结	根据事件情况改进防御措施和流程	事后分析报告、流程变更、新检测规则

各阶段并非总是严格按顺序进行。遏制和根除可能重叠。检测与分析贯穿整个响应过程。

Severity Classification

严重程度分类

Assign severity at detection time. Reassess as facts emerge.

Severity	Definition	Response SLA	Example
P1 - Critical	Active breach with ongoing data exfiltration or system compromise	Immediate, 24/7 response	Attacker has shell on production DB, ransomware spreading
P2 - High	Confirmed compromise but impact is contained or unclear	Response within 1 hour	Stolen API key used, single host compromised, credential stuffing succeeding
P3 - Medium	Suspicious activity with no confirmed compromise	Response within 4 hours	Anomalous login from new country, unusual outbound traffic spike
P4 - Low	Potential indicator, no evidence of compromise	Next business day	Single failed login attempt, phishing email reported but not clicked

When in doubt, escalate to a higher severity. Downgrading is always easier than explaining why you under-responded.

在检测时分配严重程度，并随着事实的浮现重新评估。

严重程度	定义	响应SLA	示例
P1 - 关键	存在活跃漏洞，正在发生数据泄露或系统入侵	立即响应，7×24小时待命	攻击者获取生产数据库Shell、勒索软件正在扩散
P2 - 高	已确认存在漏洞，但影响已被控制或尚不明确	1小时内响应	被盗API密钥已被使用、单台主机被入侵、凭证填充攻击成功
P3 - 中	存在可疑活动，但未确认漏洞	4小时内响应	来自新国家的异常登录、出站流量异常激增
P4 - 低	存在潜在指标，但无漏洞证据	下一个工作日处理	单次登录失败尝试、收到钓鱼邮件但未点击

如有疑问，升级至更高严重程度。降级总比解释为何响应不足更容易。

Chain of Custody

监管链

Chain of custody is the documented, unbroken record of who collected, handled, and transferred evidence. Required for:

Legal proceedings or law enforcement cooperation
Regulatory compliance (HIPAA, PCI-DSS, GDPR)
Insurance claims
Internal disciplinary actions

Every piece of evidence needs: what it is, when it was collected, who collected it, where it has been stored, and who has accessed it since collection.

监管链是关于谁收集、处理和转移证据的完整、无间断记录。在以下场景中是必需的：

法律程序或与执法部门合作
合规监管（HIPAA、PCI-DSS、GDPR）
保险索赔
内部纪律处分

每件证据都需要记录：证据内容、收集时间、收集人、存储位置以及收集后所有访问过的人员。

IOC Types

IOC类型

Indicators of Compromise (IOCs) are artifacts that indicate a system may have been compromised. Categories:

Type	Examples	Volatility
Atomic	IP addresses, domain names, email addresses, file hashes	Low - easy to change by attacker
Computed	Network traffic patterns, YARA rules, behavioral signatures	Medium - harder to change
Behavioral	TTP patterns (MITRE ATT&CK techniques), lateral movement indicators	High - most durable signal

Prefer behavioral IOCs for detection rules. Atomic IOCs burn quickly as attackers rotate infrastructure. Map findings to MITRE ATT&CK techniques when possible - it enables cross-team communication and threat intelligence sharing.

妥协指标（IOC）是表明系统可能已被入侵的人工制品。分类如下：

类型	示例	易变性
原子型	IP地址、域名、电子邮件地址、文件哈希	低 - 攻击者易于更改
计算型	网络流量模式、YARA规则、行为特征	中 - 攻击者较难更改
行为型	TTP模式（MITRE ATT&CK技术）、横向移动指标	高 - 信号最持久

在检测规则中优先使用行为型IOC。原子型IOC会随着攻击者轮换基础设施而迅速失效。尽可能将发现映射到MITRE ATT&CK技术——这有助于跨团队沟通和威胁情报共享。

Common tasks

常见任务

Detect and classify an incident

检测并分类事件

When an alert fires or suspicious activity is reported, your first job is triage.

Initial triage checklist:

What triggered the alert or report? (alert, user report, third-party notification)
What systems and data are potentially affected?
Is the attacker likely still active (ongoing) or was this historical activity?
Is PII, PHI, PCI, or other regulated data in scope?
What is the business impact if this is confirmed?

Severity matrix (quick reference):

Is an attacker actively operating in your systems right now?
  YES -> P1. Activate incident response team immediately.
  NO  -> Is a confirmed compromise present (evidence of unauthorized access)?
    YES -> P2. Assemble response team within 1 hour.
    NO  -> Is there suspicious activity with credible threat indicators?
      YES -> P3. Assign responder, investigate within 4 hours.
      NO  -> P4. Log and monitor, review next business day.

Open an incident channel (e.g., Slack

#inc-YYYY-MM-DD-shortname

) and post the initial severity assessment within 15 minutes of detection.

当警报触发或报告可疑活动时，你的首要任务是分类筛选。

初始分类清单：

触发警报或报告的原因是什么？（警报、用户报告、第三方通知）
哪些系统和数据可能受到影响？
攻击者可能仍在活跃（持续进行）还是历史活动？
是否涉及PII、PHI、PCI或其他受监管数据？
如果确认存在漏洞，业务影响是什么？

严重程度矩阵（快速参考）：

攻击者当前是否正在你的系统中活动？
  是 -> P1。立即激活事件响应团队。
  否 -> 是否存在已确认的漏洞（未授权访问证据）？
    是 -> P2。1小时内召集响应团队。
    否 -> 是否存在带有可信威胁指标的可疑活动？
      是 -> P3。分配响应人员，4小时内展开调查。
      否 -> P4。记录并监控，下一个工作日复查。

创建事件沟通渠道（例如Slack

#inc-YYYY-MM-DD-shortname

），并在检测后15分钟内发布初始严重程度评估。

Contain a breach

遏制漏洞扩散

Containment is the most time-critical action. Execute in two stages:

Short-term containment (immediate - do not wait for full investigation):

Isolate affected hosts from the network (network segment or pull the cable) without powering them off - RAM evidence is lost on shutdown
Revoke or rotate all credentials that may have been exposed
Block attacker-controlled IPs and domains at the firewall and DNS level
Disable any compromised service accounts or API keys
Preserve a snapshot (cloud VM snapshot or disk image) before remediation begins

Long-term containment (within hours):

Move affected systems to an isolated network segment for forensic analysis
Deploy additional monitoring on systems adjacent to the compromise
Validate that backups for affected systems are clean and pre-date the intrusion
Determine if the attacker has established persistence (scheduled tasks, cron jobs, SSH authorized_keys, new user accounts, implants)
Coordinate with legal before communicating externally about the breach

Never reimage or restore a system before taking a forensic image. A clean system is useless evidence.

遏制是最具时间紧迫性的行动。分两个阶段执行：

短期遏制（立即执行 - 无需等待完整调查）：

将受影响主机与网络隔离（网络分段或拔掉网线），但不要关机——关机将丢失RAM中的证据
撤销或轮换所有可能已泄露的凭证
在防火墙和DNS层面拦截攻击者控制的IP和域名
禁用任何已被入侵的服务账户或API密钥
在开始修复前保留快照（云VM快照或磁盘镜像）

长期遏制（数小时内执行）：

将受影响系统移至隔离网络分段以进行取证分析
在与漏洞相邻的系统上部署额外监控
验证受影响系统的备份是否干净且早于入侵时间
确定攻击者是否已建立持久访问机制（计划任务、cron作业、SSH授权密钥、新用户账户、植入程序）
在向外部通报漏洞前与法务部门协调

在获取取证镜像前，切勿重新镜像或恢复系统。干净的系统无法作为证据。

Preserve forensic evidence

保留取证证据

Forensic integrity requires that you capture volatile data before it disappears and that all evidence collection is documented.

Order of volatility (capture in this order):

CPU registers and cache (already lost if you can't attach a debugger live)
RAM / memory dump - use tools like
```
avml
```
,
```
WinPmem
```
, or cloud provider memory capture APIs
Network connections -
```
ss -tnp
```
,
```
netstat -ano
```
, ARP cache
Running processes -
```
ps auxf
```
,
```
lsof
```
, process tree with hashes
File system - timestamps (MAC times), recently modified files, new files
Disk image - bit-for-bit copy using
```
dd
```
with write blocker or cloud snapshot

Chain of custody log template:

Evidence ID:     [unique ID, e.g., INC-2024-001-E01]
Description:     [e.g., Memory dump from prod-web-01]
Collected by:    [name + role]
Collection time: [ISO 8601 timestamp with timezone]
Collection tool: [tool name + version + command run]
Hash (SHA-256):  [hash of the evidence file]
Storage location:[path or bucket with access controls]
Chain of access: [who accessed it and when after collection]

Every command run on a live affected system must be logged with timestamp and operator name - these commands themselves modify the system and must be part of the record.

取证完整性要求你在易失性数据消失前捕获它，并记录所有证据收集过程。

易失性顺序（按此顺序捕获）：

CPU寄存器和缓存（如果无法实时连接调试器，数据已丢失）
RAM / 内存转储 - 使用
```
avml
```
、
```
WinPmem
```
或云提供商内存捕获API等工具
网络连接 -
```
ss -tnp
```
、
```
netstat -ano
```
、ARP缓存
运行进程 -
```
ps auxf
```
、
```
lsof
```
、带哈希的进程树
文件系统 - 时间戳（MAC时间）、最近修改的文件、新文件
磁盘镜像 - 使用带写入拦截器的
```
dd
```
或云快照进行逐位复制

监管链日志模板：

证据ID:     [唯一ID，例如INC-2024-001-E01]
描述:     [例如：来自prod-web-01的内存转储]
收集人:    [姓名 + 角色]
收集时间: [带时区的ISO 8601时间戳]
收集工具: [工具名称 + 版本 + 执行命令]
哈希(SHA-256):  [证据文件的哈希值]
存储位置:[带访问控制的路径或存储桶]
访问记录: [收集后访问过的人员及时间]

在受影响的活跃系统上执行的每一条命令都必须记录时间戳和操作人员姓名——这些命令本身会修改系统，必须作为记录的一部分。

Communicate during an incident

事件期间的沟通

Timely, accurate communication prevents panic and enables stakeholders to take protective action. Follow a tiered communication model:

Internal responders (Slack incident channel, every 30-60 minutes):

Current status, what we know, what we're doing, next update in X minutes.

Executive / management stakeholder template:

Subject: [P1 ACTIVE / P2 CONTAINED] Security Incident - [date]

What happened: [1-2 sentences, plain language]
Current status: [Investigating / Contained / Eradicating / Recovering]
Business impact: [Systems affected, services degraded, data at risk]
What we are doing: [Top 3 actions in progress]
Next update: [Time]
Contact: [IR lead name + contact]

Customer / external notification (when required by law or policy):

Consult legal before sending any external notification
GDPR requires notification to supervisory authority within 72 hours of becoming aware of a breach
State breach notification laws vary; legal must determine which apply
Be factual and specific about what data was affected; avoid speculation
Include what affected users should do to protect themselves

Never speculate in stakeholder communications. State only what is confirmed. Use "we are investigating" until you have facts.

及时、准确的沟通可防止恐慌，并使利益相关者能够采取保护措施。遵循分层沟通模型：

内部响应人员（Slack事件渠道，每30-60分钟更新一次）：

当前状态、已知信息、正在执行的操作、下次更新时间。

高管/管理层利益相关者模板：

主题: [P1 活跃 / P2 已控制] 安全事件 - [日期]

事件概况: [1-2句话，通俗易懂]
当前状态: [调查中 / 已控制 / 根除中 / 恢复中]
业务影响: [受影响系统、服务降级、面临风险的数据]
正在采取的行动: [正在进行的前3项关键行动]
下次更新: [时间]
联系人: [事件响应负责人姓名 + 联系方式]

客户/外部通报（法律或政策要求时）：

在发送任何外部通报前咨询法务部门
GDPR要求在意识到漏洞后72小时内通报监管机构
各州漏洞通报法律各不相同；法务部门必须确定适用的法律
如实、具体说明受影响的数据；避免猜测
包含受影响用户应采取的自我保护措施

切勿在与利益相关者的沟通中猜测。仅陈述已确认的事实。在掌握事实前，使用“我们正在调查”。

Eradicate the threat and recover

根除威胁并恢复系统

Write an incident report

撰写事件报告

Every P1 and P2 incident requires a written report. P3 incidents warrant a brief write-up. Reports serve three purposes: accountability, improvement, and compliance.

Incident report template:

markdown

undefined

所有P1和P2事件都需要书面报告。P3事件需要简短的书面记录。报告有三个目的：问责、改进和合规。

事件报告模板：

markdown

undefined

Incident Report: [Short title]

事件报告: [简短标题]

Incident ID: INC-YYYY-MM-DD-NNN Severity: P1 / P2 / P3 Status: Closed Date/Time Detected: [ISO 8601] Date/Time Resolved: [ISO 8601] Total Duration: [HH:MM] Report Author: [Name] Reviewed By: [Names]

事件ID: INC-YYYY-MM-DD-NNN 严重程度: P1 / P2 / P3 状态: 已关闭 检测日期/时间: [ISO 8601格式] 解决日期/时间: [ISO 8601格式] 总时长: [HH:MM] 报告作者: [姓名] 审核人: [姓名]

Executive Summary

执行摘要

[2-3 sentences: what happened, what was affected, what was done]

[2-3句话：事件概况、受影响范围、采取的行动]

Timeline

时间线

Time (UTC)	Event
HH:MM	[First indicator observed]
HH:MM	[Incident declared, responders engaged]
HH:MM	[Containment action taken]
HH:MM	[Root cause identified]
HH:MM	[Eradication complete]
HH:MM	[Systems restored to production]

时间(UTC)	事件
HH:MM	[首次观察到的指标]
HH:MM	[宣布事件，响应人员到位]
HH:MM	[采取遏制行动]
HH:MM	[确定根本原因]
HH:MM	[完成根除]
HH:MM	[系统回归生产]

Root Cause

根本原因

[What vulnerability, misconfiguration, or human factor enabled this incident?]

[是什么漏洞、配置错误或人为因素导致了此次事件？]

Impact

影响

Systems affected: [list]
Data affected: [type, volume, sensitivity]
Users affected: [count / segments]
Business impact: [downtime, revenue, SLA breach]

受影响系统: [列表]
受影响数据: [类型、数量、敏感度]
受影响用户: [数量 / 群体]
业务影响: [停机时间、收入损失、SLA违约]

What Went Well

做得好的地方

[list]

[列表]

What Could Be Improved

有待改进的地方

[list]

[列表]

Action Items

行动项

Action	Owner	Due Date	Status
[Patch CVE-XXXX-XXXX]	[Name]	[Date]	Open

行动	负责人	截止日期	状态
[修补CVE-XXXX-XXXX]	[姓名]	[日期]	待处理

Evidence References

证据参考

Evidence ID	Description	Location


Distribute the report within 5 business days of incident closure. For P1 incidents,
hold a live lessons-learned meeting before the written report is finalized.

证据ID	描述	位置


在事件关闭后5个工作日内分发报告。对于P1事件，在最终确定书面报告前召开一次实时经验总结会议。

Conduct lessons learned and improve

开展经验总结并改进

The lessons learned phase is where incidents pay dividends. Skip it and you will respond to the same incident again.

Meeting structure (60-90 minutes for P1, 30 minutes for P2):

Timeline review (15 min) - walk through the incident timeline factually
What went well (10 min) - reinforce what worked
What can improve (20 min) - identify gaps in detection, response, tools, or process
Action items (15 min) - assign specific, time-bound improvements with owners
Detection gap analysis (10 min) - what new detections would have caught this earlier?

Improvement categories to consider:

Detection: new SIEM rules, EDR signatures, alerting thresholds
Prevention: patches, hardening, access control changes
Process: runbook updates, communication templates, escalation paths
Training: tabletop exercises, awareness training for the attack vector used

Track action items in your ticketing system. Review completion at the next security review cycle. An unactioned post-mortem is a missed opportunity and a future liability.

经验总结阶段是事件带来价值的环节。跳过这一阶段，你将再次响应相同的事件。

会议结构（P1事件60-90分钟，P2事件30分钟）：

时间线回顾（15分钟）- 如实回顾事件时间线
做得好的地方（10分钟）- 强化有效的措施
有待改进的地方（20分钟）- 识别检测、响应、工具或流程中的差距
行动项（15分钟）- 分配具体、有时间限制的改进任务及负责人
检测差距分析（10分钟）- 哪些新检测规则可以更早发现此次事件？

需考虑的改进类别：

检测：新SIEM规则、EDR特征、警报阈值
预防：补丁、加固、访问控制变更
流程：运行手册更新、沟通模板、升级路径
培训：桌面演练、针对此次攻击向量的意识培训

在工单系统中跟踪行动项。在下一次安全审查周期中复查完成情况。未执行的事后分析报告是错失的改进机会，也是未来的责任隐患。

Gotchas

注意事项

Rotating credentials before isolating the system - If you rotate credentials while the attacker still has an active session, they may have already cached the token or established a persistent back-channel (e.g., reverse shell). Isolate the system from the network first, then rotate credentials.
GDPR 72-hour clock starts at awareness, not confirmation - The 72-hour notification requirement to the supervisory authority begins when you have reasonable belief a breach occurred - not when you have confirmed every detail. Filing "we are investigating" within 72 hours is required; waiting until the investigation is complete is not compliant.
"Contained" does not mean "eradicated" - Isolating a system stops active damage but the threat is still present. Attackers frequently pre-plant persistence (cron jobs, scheduled tasks, additional user accounts) before containment. Never return a system to production after containment alone - eradication must follow.
Slack incident channel membership leaks intel - Adding non-essential stakeholders to the incident Slack channel before legal review can expose information subject to privilege or create a discoverable record. Keep the responder channel tight until legal has been consulted on external communication scope.
Post-mortem action items without due dates are permanent backlogs - An action item with no owner and no deadline will be in the "backlog" forever. Every action item from a post-mortem needs a named owner, a specific due date, and a check-in at the next security review.

在隔离系统前轮换凭证 - 如果在攻击者仍有活跃会话时轮换凭证，他们可能已缓存令牌或建立了持久反向通道（例如反向Shell）。请先将系统与网络隔离，再轮换凭证。
GDPR的72小时时钟从意识到漏洞时开始，而非确认时 - 向监管机构通报的72小时要求从你有合理理由认为存在漏洞时开始——而非你确认所有细节时。在72小时内提交“我们正在调查”是合规的；等到调查完成后再通报则不合规。
“已控制”并不意味着“已根除” - 隔离系统可阻止活跃损害，但威胁仍然存在。攻击者经常在遏制前预先植入持久访问机制（cron作业、计划任务、额外用户账户）。仅完成遏制后切勿将系统回归生产——必须先完成根除。
Slack事件渠道成员会泄露情报 - 在法务审查前将非必要利益相关者添加到Slack事件渠道，可能会暴露受特权保护的信息或创建可被发现的记录。在法务部门就外部沟通范围提供意见前，保持响应人员渠道的精简。
无截止日期的事后分析行动项将成为永久积压任务 - 没有负责人和截止日期的行动项将永远留在“积压任务”中。事后分析报告中的每一项行动项都需要指定负责人、具体截止日期，并在下一次安全审查中跟进。

Anti-patterns / common mistakes

反模式/常见错误

Mistake	Why it's wrong	What to do instead
Rebooting or wiping a system immediately	Destroys volatile evidence (RAM, network state, running processes) that is critical for forensics	Isolate from network, take memory dump and disk image first, then remediate
Investigating without containment	Attacker retains access while you analyze, exfiltrating more data	Contain first (isolate, revoke creds), then investigate in parallel
Communicating speculation as fact	Creates false expectations, erodes trust when facts change	State only confirmed findings; use "we are investigating" for unknown scope
Skipping chain of custody documentation	Evidence becomes inadmissible in legal proceedings or insurance claims	Document every piece of evidence with collector, time, tool, and hash from collection
Declaring an incident closed too quickly	Attacker may have established persistence that survives remediation	Monitor recovered systems for 30+ days before considering the incident fully closed
Blaming individuals in post-mortems	Creates fear culture, people hide future incidents, root causes go unfixed	Focus on system and process failures; use blameless post-mortem framework

错误	错误原因	正确做法
立即重启或擦除系统	销毁了对取证至关重要的易失性证据（RAM、网络状态、运行进程）	先与网络隔离，获取内存转储和磁盘镜像，再进行修复
未遏制就开始调查	攻击者在你分析期间仍保留访问权限，会泄露更多数据	先遏制（隔离、撤销凭证），再并行调查
将猜测作为事实沟通	造成错误预期，当事实改变时会损害信任	仅陈述已确认的发现；对未知范围使用“我们正在调查”
跳过监管链文档记录	证据在法律程序或保险索赔中不被采纳	从收集开始，为每件证据记录收集人、时间、工具和哈希值
过早宣布事件已关闭	攻击者可能已建立可在修复后存活的持久访问机制	在考虑事件完全关闭前，监控已恢复系统30天以上
在事后分析中追责个人	营造恐惧文化，员工会隐瞒未来事件，根本原因无法解决	关注系统和流程故障；使用无责事后分析框架

References

参考资料

For detailed playbooks on specific incident types, read:

```
references/incident-playbooks.md
```
- step-by-step playbooks for ransomware, credential theft, data exfiltration, insider threat, and supply chain attacks

Only load the references file when the current incident type matches a playbook - it is detailed and will consume context.

如需特定事件类型的详细运行手册，请阅读：

```
references/incident-playbooks.md
```
- 针对勒索软件、凭证盗窃、数据泄露、内部威胁和供应链攻击的分步运行手册

仅当当前事件类型与运行手册匹配时才加载参考资料文件——内容详细，会占用上下文资源。

Companion check

配套技能检查

On first activation of this skill in a conversation: check which companion skills are installed by running
ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null
. Compare the results against the
recommended_skills
field in this file's frontmatter. For any that are missing, mention them once and offer to install:
npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>
Skip entirely if
recommended_skills
is empty or all companions are already installed.

在对话中首次激活本技能时：运行
ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null
检查已安装的配套技能。将结果与本文件前置内容中的
recommended_skills
字段进行比较。对于任何缺失的技能，提及一次并提供安装命令：
npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>
如果
recommended_skills
为空或所有配套技能已安装，请完全跳过此步骤。