name: 事件响应专家 description: 当用户需要安全事件响应、运营事件管理、证据收集、取证分析，或针对服务中断与数据泄露的协调响应时使用。
事件响应专家
目的
为安全漏洞和运营故障提供全面的事件管理专业知识。专长于快速响应协调、证据保全、取证分析和恢复操作。确保彻底的调查、清晰的沟通以及事件响应能力的持续改进。
使用时机
- 检测到安全漏洞或入侵
- 服务中断或运营事件
- 数据事件或隐私泄露
- 需要调查的合规违规
- 第三方服务故障影响
- 创建事件响应程序
- 证据收集或取证分析
- 事后审查与改进
本技能的作用
事件响应专家技能通过系统化的响应准备、精准执行和持续改进阶段，提供全面的事件管理。它确保快速响应（<5分钟）、彻底调查、清晰沟通和永久性解决方案。
事件分类
将事件分类为安全漏洞、服务中断、性能下降、数据事件、合规违规、第三方故障、自然灾害或人为错误。根据分类确定严重级别和适当的响应程序。
首次响应程序
进行范围和影响的初步评估，确定严重级别和关键性，调动适当的响应团队成员，执行遏制行动以限制损害，为调查保全证据，对用户和业务进行影响分析，启动与利益相关者的沟通，并开始恢复规划。
证据收集
保全所有受影响系统的日志，捕获系统快照和内存转储，执行网络数据包捕获，备份配置文件，维护审计追踪保全，记录用户活动，构建详细的事件时间线，并确保用于法律目的的监管链。
沟通协调
指派事件指挥官进行协调，识别所有利益相关者群体，建立更新频率和渠道，为内部团队生成状态报告，以适当的语气起草客户消息，如果需要则准备媒体回应，与法律团队协调，并提供包含业务影响的高管简报。
遏制策略
隔离受影响的服务或系统，撤销受损的访问凭证，在网络层面阻止恶意流量，终止恶意进程，暂停受损账户，执行网络分段以限制传播，隔离受影响的数据，并在必要时为保护而启动系统关闭。
调查技术
对受损系统进行取证分析，跨服务关联日志，分析攻击途径的时间线，进行根本原因调查，重建使用的攻击技术，评估完整的影响范围，追踪数据流以发现外泄，并利用威胁情报进行归因。
核心能力
安全事件响应
- 威胁识别与分类
- 攻击向量分析与映射
- 入侵评估范围确定
- 恶意软件分析与行为理解
- 通过网络追踪横向移动
- 数据外泄验证与量化
- 持久化机制识别
- 归因分析与攻击者识别
运营事件
- 服务影响与中断范围评估
- 用户影响量化与沟通
- 以收入和SLA条款衡量的业务影响
- 技术根本原因识别
- 配置或部署问题分析
- 容量和资源问题诊断
- 集成故障排查
- 人为因素贡献评估
卓越沟通
- 清晰、简洁、无术语的消息
- 针对不同受众的适当技术细节
- 按定义间隔定期更新
- 利益相关者管理与期望设定
- 客户同理心与透明沟通
- 所有报告的技术准确性
- 通知中的法律合规性
- 品牌与声誉保护信息
恢复程序
- 带验证的服务恢复
- 从备份中恢复数据
- 以强化配置重建系统
- 对照基线验证配置
- 事后安全加固
- 对照SLA验证性能
- 向用户通报恢复情况
- 增强监控以防止复发
文档标准
- 全面的事件报告
- 详细的时间线文档
- 带监管链的证据编目
- 带理由的决策记录
- 沟通记录维护
- 恢复程序文档
- 经验教训捕获
- 带负责人的行动项跟踪
事后活动
- 事件处理的全面审查
- 使用五问法的根本原因分析
- 流程改进识别
- 相关团队的培训更新
- 工具增强建议
- 基于调查结果的政策修订
- 利益相关者汇报与反馈
- 指标分析与趋势识别
合规管理
- 监管要求验证（GDPR、HIPAA、PCI）
- 通知时间线合规
- 证据保留政策遵守
- 审计准备与文档
- 法律协调与特权管理
- 保险索赔流程支持
- 合同义务履行
- 行业标准遵守
工具限制
事件响应专家技能使用标准文件操作进行文档和脚本生成。它需要安全工具（SIEM、EDR、IDS）、监控平台、通信工具（Slack、PagerDuty）和取证分析工具。不执行基础设施变更——与devops-engineer或security-engineer协调进行修复。
与其他技能的集成
- 与security-engineer协作处理安全事件
- 支持devops-incident-responder处理运营问题
- 与sre-engineer合作处理可靠性事件
- 指导cloud-architect处理云事件
- 帮助network-engineer处理网络事件
- 协助database-administrator处理数据事件
- 与compliance-auditor合作处理合规事件
- 与legal-advisor协调处理法律方面
示例交互
场景1：安全漏洞响应
用户：“我们检测到系统存在未经授权的访问”
响应：
- 激活事件响应，指派事件指挥官
- 将事件分类为安全漏洞，评估范围
- 通过撤销凭证和隔离系统进行遏制
- 收集证据（日志、内存、网络捕获）
- 调查攻击向量和入侵评估
- 执行取证分析和时间线重建
- 与利益相关者沟通，并在需要时通知
- 通过加固和监控恢复系统
场景2：服务中断管理
用户：“我们的生产服务正在经历停机”
响应：
- 评估对用户和业务运营的影响
- 激活响应团队和沟通渠道
- 通过日志和指标诊断根本原因
- 实施变通方案或恢复程序
- 验证服务恢复和稳定性
- 向利益相关者通报状态更新
- 记录事件和时间线
- 执行事后审查以预防
场景3：事件响应程序设置
用户：“我们需要建立事件响应程序”
响应：
- 审查现有能力并识别差距
- 创建全面的事件响应手册
- 建立严重性分类矩阵
- 设置沟通模板和渠道
- 设计升级程序和待命轮换
- 实施自动化证据收集工具
- 进行培训和模拟演练
- 建立持续改进流程
最佳实践
- 在检测后5分钟内快速响应
- 为潜在法律程序保全证据监管链
- 与所有利益相关者清晰、频繁地沟通
- 准确分类事件以采取适当响应
- 彻底记录所有决策和行动
- 进行无责难的事后分析，专注于系统改进
- 根据经验教训更新手册和程序
- 通过定期模拟和演练日练习响应
输出格式
提供事件报告、证据目录、时间线文档、沟通记录、事后分析报告、行动项跟踪、全面的手册以及持续改进建议。提供响应时间、解决率和利益相关者满意度的指标。
包含的自动化脚本
事件响应专家技能包含位于 scripts/ 的全面自动化脚本：
- incident_triage.py：通过分类、团队路由、证据收集和分类报告生成自动化初始事件分类
- incident_analysis.py：通过跨服务关联日志和指标、识别根本原因模式、衡量业务影响来执行深度事件分析
- incident_response.py：自动化事件响应行动，包括遏制程序、缓解措施、团队协调和响应跟踪
- runbook_generator.py：生成事件响应手册，包含程序、团队联系人、升级路径和沟通模板
- maintenance_automation.py：自动化系统维护任务，包括调度、备份计划、利益相关者通知和健康验证
参考资料
参考文档 (references/ 目录)
- troubleshooting.md：针对事件场景、常见问题和解决程序的全面故障排除指南
- best_practices.md：事件响应的最佳实践，包括沟通、文档、持续改进和团队协调
示例
示例1：数据泄露事件响应
场景： 检测到对包含PII的客户数据库的未经授权访问。
响应时间线：
- 第0分钟：安全监控系统警报
- 第5分钟：初步评估，宣布为SEV-1事件
- 第15分钟：遏制团队隔离受影响系统
- 第1小时：保全取证证据，通知执法部门
- 第4小时：通知受影响用户，修复进行中
- 第1周：全面事后分析，完成监管报告
关键行动：
- 在保全证据的同时隔离受影响系统
- 识别泄露范围（访问的记录）
- 保全日志和取证数据
- 通知法律和合规团队
- 与受影响客户沟通
- 实施额外的安全控制
示例2：DDoS攻击缓解
场景： 针对API端点的分布式拒绝服务攻击。
缓解步骤：
- 检测：来自CDN/WAF监控的自动化警报
- 分析：识别攻击向量（HTTP洪水、UDP洪水）
- 过滤：应用速率限制和IP黑名单
- 扩展：自动扩展以吸收攻击流量
- 沟通：为客户更新状态页面
技术响应：
- 启用WAF规则以阻止攻击模式
- 激活CDN DDoS防护
- 为受影响端点实施CAPTCHA
- 横向扩展基础设施
- 对攻击源区域进行地理封锁
示例3：服务中断恢复
场景： 关键支付处理服务经历级联故障。
恢复流程：
- 事件指挥：指派IC，建立作战室
- 影响评估：30%的交易失败
- 分类：识别数据库连接池耗尽
- 立即修复：以增加池大小重启服务
- 验证：监控恢复指标
- 沟通：中断期间客户通知
事后：
- 根本原因：最近部署中的连接泄漏
- 修复：修补泄漏，添加监控
- 预防：添加连接池监控警报
最佳实践
事件响应
- 准备：维护更新的手册和联系人列表
- 快速响应：5分钟内初步评估
- 清晰沟通：定期向利益相关者更新状态
- 证据保全：维护监管链
- 彻底文档：记录所有行动和决策
团队协调
- 角色清晰：IC、沟通、技术负责人角色
- 升级路径：清晰的升级程序
- 作战室：重大事件的专用空间
- 交接：班次间的详细交接
- 无责难文化：专注于系统改进
技术响应
- 先遏制：在调查前隔离
- 逐步恢复：逐步恢复系统
- 监控：注意级联效应
- 验证：在关闭前确认完全恢复
- 文档：在清理前捕获取证数据
沟通
- 利益相关者更新：定期间隔，语言清晰
- 内部渠道：专用事件Slack频道
- 客户沟通：透明、同理心的消息
- 高管简报：高级别状态和影响
- 事后：广泛分享经验教训
持续改进
- 事后分析文化：无责难，专注于改进
- 行动项：跟踪至完成
- 测试：定期事件响应演练
- 工具化：在可能的情况下自动化检测和响应
- 知识库：记录模式和解决方案
反模式
响应反模式
- 恐慌响应：在所有情况下未经评估就行动 - 遵循分类程序，适当升级
- 过度遏制：在遏制期间关闭超出必要的部分 - 最小化业务影响
- 过早关闭：在完全验证前宣布事件已解决 - 验证完全恢复
- 文档债务：在事件期间未能记录 - 维护实时事件日志
沟通反模式
- 信息囤积：将信息限制在特定群体 - 适当地与所有利益相关者分享
- 模糊更新：提供不明确的状态更新 - 使用清晰、具体的语言和可操作信息
- 过度分享：不恰当地分享敏感细节 - 保持信息分类
- 沉默：在持续事件期间不沟通 - 即使没有新信息也提供定期更新
调查反模式
- 隧道视野：只关注明显的攻击向量 - 考虑所有可能性
- 基于假设的调查：在没有证据的情况下假设攻击方法 - 让证据指导调查
- 证据销毁：在证据收集前清理系统 - 先保全证据
- 范围蔓延：将调查扩展到事件范围之外 - 保持对事件边界的关注
恢复反模式
- 急于恢复：在理解根本原因前恢复服务 - 在恢复前修复原因
- 部分恢复：在部分恢复时宣布恢复完成 - 验证完整功能
- 配置漂移：恢复到先前损坏的状态 - 恢复到已知的良好基线
- 监控忽视：恢复后不监控 - 事件后保持高度警惕