cybernovaacademy/Incident-Response-Plan
GitHub: cybernovaacademy/Incident-Response-Plan
CyberNova Academy 出品的一套覆盖 12 类常见安全事件的综合 SOC 事件响应行动手册，提供从检测到恢复的全生命周期标准化处置流程和 MITRE ATT&CK 映射参考。
Stars: 0 | Forks: 0
# 事件响应计划
IR 计划
# CyberNova Academy - 精英 SOC 事件响应行动手册案例集
## 专业目的
此 Markdown 文件将上传的 SOC 事件响应行动手册示例转换为整洁的、适合作品集展示的 GitHub 风格事件响应案例集。它保留了原始的场景、分类、阶段、操作、工具和成功指标，并在此基础上添加了更深入的 SOC、DFIR、遏制、报告、MITRE ATT&CK、SIEM 和高管响应指南。
## 如何使用本行动手册
| 角色 | 如何使用 |
|---|---|
| 一线 SOC 分析师 | 确认告警，收集证据，开启事件工单，在达到严重性阈值时进行升级。 |
| 二线 SOC 分析师 | 验证影响范围，丰富 IOC，运行 SIEM 检索，协调遏制工作。 |
| 事件指挥官 | 管理决策、沟通、业务影响和高管汇报。 |
| 系统管理员 | 执行遏制、打补丁、恢复、访问重置和配置加固。 |
| GRC / 合规 | 跟踪义务、违规通知、经验教训、风险处置和策略更新。 |
## 通用事件响应生命周期
| 阶段 | 目的 | 关键产出 |
|---|---|---|
| 准备阶段 | 在事件发生前建立 readiness | 日志记录、行动手册、联系人列表、工具、备份、桌面演练 |
| 检测与分析 | 确认发生的情况并确定严重性 | 已验证的事件、时间线、受影响资产、IOC |
| 遏制 | 阻止进一步的损害 | 已隔离的主机、已撤销的 token、已封禁的 IP/域名、已禁用的账户 |
| 根除 | 移除攻击者的访问权限和恶意 artefacts | 已清理的系统、已移除的持久化、已修补的弱点 |
| 恢复 | 安全地恢复服务 | 已恢复的工作负载、已监控的系统、已恢复的用户访问 |
| 经验教训 | 改善组织 | 更新后的检测、策略、培训和风险控制 |
## 事件严重性矩阵
| 严重性 | 定义 | 响应期望 |
|---|---|---|
| 严重 | 正在进行的攻击、勒索软件、重大停机、已确认的数据被盗、特权云账户失陷 | 立即启动事件沟通桥、高管通知、立即采取遏制行动 |
| 高 | 已确认的恶意活动但范围有限，或影响了高风险资产 | 快速分诊，升级至 SOC 负责人，在商定的 SLA 内完成遏制 |
| 中 | 需要调查的可疑活动，但影响证据有限 | 调查、监控、记录、调整检测 |
| 低 | 良性或与策略相关的问题，运营风险极低 | 记录、关闭或转为改进项 |
# 行动手册 1：勒索软件感染
## 场景
端点或服务器表现出勒索软件活动迹象，例如文件加密、勒索信或来自 EDR/XDR 工具的告警。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 恶意软件 – 勒索软件 |
| 严重性 | 高 |
| 优先级 | 严重（由于潜在的业务影响和数据丢失） |
| 检测来源 | EDR/XDR, SIEM, 用户报告, 防病毒软件, NDR |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 备份和恢复策略 | 定期离线备份，测试恢复 |
| 端点保护 | 具备行为检测和回滚功能的 EDR |
| 用户安全意识培训 | 电子邮件和 USB 介质处理教育 |
| 日志覆盖范围 | Windows 日志、Sysmon、文件访问日志、网络流量 |
| IOC 和威胁情报订阅 | 包括特定于勒索软件的指标 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 确认勒索软件活动 | EDR 告警、存在勒索信、加密的文件扩展名 |
| 隔离受影响的主机 | 断开网络连接或使用 EDR 遏制功能 |
| 识别勒索软件家族 | 根据勒索信、文件哈希或文件名模式 |
| 分析日志和行为 | 追踪执行源、横向移动、可疑的计划任务或服务 |
| MITRE ATT&CK 映射 | T1486 (数据加密以造成影响), T1059 (命令执行), T1021.002 (SMB 横向移动) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 隔离受影响的系统 | 在交换机、防火墙处阻断或通过 EDR 进行隔离 |
| 禁用受感染的账户 | 特别是如果用于横向移动的账户 |
| 阻断外部通信 | 防止通过互联网的 C2 通信和密钥交换 |
| 快照受影响的系统 | 用于取证分析（如果需要） |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除恶意软件 artefacts | 删除勒索软件文件、脚本、计划任务 |
| 修补漏洞 | 修复被利用的攻击向量，如 RDP、SMB、过时的软件 |
| 执行完整的防病毒/EDR 扫描 | 覆盖受影响 VLAN/子网内的所有主机 |
| 验证移除结果 | 确保没有留下持久化机制（注册表项、启动项、服务） |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 从干净的备份中恢复 | 恢复前确认备份未受影响 |
| 如有需要则重建系统 | 针对没有干净备份的系统 |
| 监控已恢复的系统 | 使用 SIEM 和 EDR 确保不会发生再次感染 |
| 重置密码 | 特别是特权用户和受影响用户的密码 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行事后回顾 | 分析根本原因、初始访问方法和响应效率 |
| 更新检测规则 | 增强 SIEM 和 EDR 的关联规则和触发器 |
| 记录发现 | 包括指标、受影响的系统和时间线 |
| 分享 IOC | 如果允许，在内部和威胁情报社区内共享 |
## 常用工具
SIEM (例如：Splunk, QRadar, Sentinel, WAZUH)
EDR/XDR (例如：CrowdStrike, Cortex XDR, SentinelOne)
取证工具 (例如：FTK, Velociraptor, KAPE)
网络日志 (例如：Zeek, Suricata, NetFlow)
备份系统 (例如：Veeam, Rubrik, Commvault)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 加密开始后 <10 分钟 |
| 隔离时间 | 检测后 <15 分钟 |
| 恢复时间 | 取决于备份可用性，理想情况下 <24 小时 |
| 遏制范围 | 没有横向移动超出原始 VLAN |
# 行动手册 2：内部人员数据外发
## 场景
内部员工、承包商或特权用户试图或成功地通过个人电子邮件、云存储、可移动介质或文件传输工具等未经授权的渠道外发敏感数据。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 内部威胁 – 数据外发 |
| 严重性 | 高 (特别是对于受监管或机密数据) |
| 优先级 | 高到严重 |
| 检测来源 | DLP, SIEM, 代理日志, CASB, EDR, 电子邮件网关 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 定义敏感数据类别 | 文件分类：PII、财务数据、商业秘密 |
| 实施 DLP | 在端点、网络、电子邮件上设置检测策略 |
| 活动监控 | 记录用户访问、文件传输和云应用使用情况 |
| 内部风险培训 | 教育员工关于可接受的数据处理方式 |
| 访问控制执行 | 基于角色的访问、最小权限、隔离 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 触发检测告警 | DLP 违规、异常下载、大型电子邮件附件、异常文件上传 |
| 分析访问日志 | 查看文件访问、传输时间和目的地 |
| 调查用户行为 | 检查特权提升、登录时间异常、失败的访问尝试 |
| 确认意图或配置错误 | 确定行为是恶意的、意外的还是策略漏洞 |
| MITRE ATT&CK 映射 | T1020 (自动外发), T1048 (通过替代协议外发), T1537 (传输数据至云账户) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 暂停用户访问 | 如果风险很高，暂时禁用该账户 |
| --- | --- |
| 阻断外发渠道 | 撤销云共享、阻止发送到外部域名的电子邮件、禁用 USB 端口 |
| 隔离端点 | 如果怀疑用户设备上存在恶意软件 |
| 保留取证证据 | 除非必要，否则不要关闭系统；如果可能，捕获易失性数据 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除未经授权的工具 | 例如：个人文件传输应用、恶意扩展 |
| 应用更严格的策略 | 调整 DLP 规则或防火墙规则以阻止重复尝试 |
| 纠正配置错误的权限 | 减少过度暴露的数据共享、文件夹级别的访问权限 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 恢复访问权限 (如果合理) | 在确认没有持续威胁之后 |
| 通知利益相关者 | 法务、人力资源、合规和管理团队 |
| 进行影响评估 | 确认数据是否确实被外发及其敏感性 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 记录事件 | 时间线、数据类型、行为者意图、使用的系统 |
| 加强监控 | 改进对特定文件类型和传输方法的告警 |
| 进行用户培训或纪律处分 | 如果确认事件是恶意的或因疏忽造成的 |
| 向监管机构报告 | 如果法律有要求 (例如：PDPA, GDPR, HIPAA) |
| 更新内部威胁策略 | 将新的见解纳入安全程序 |
## 常用工具
SIEM (例如：Splunk, IBM QRadar, Microsoft Sentinel)
DLP 系统 (例如：Symantec, Forcepoint, Microsoft Purview)
CASB (例如：Netskope, Microsoft Defender for Cloud Apps)
端点代理 (例如：带有数据传输监控的 EDR)
代理和防火墙日志
电子邮件安全网关 (例如：Proofpoint, Mimecast)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 数据传输开始后 <10 分钟 |
| 调查时间 | 告警后 <1 小时 |
| 遏制时间 | <30 分钟 |
| 监管响应时间 | 在法定的时限内 (例如：72 小时) |
# 行动手册 3：云账户失陷
## 场景
攻击者通过网络钓鱼、密码喷洒、token 窃取或 OAuth 滥用等方式，未经授权访问用户的云账户。攻击者可能会访问电子邮件、存储、管理功能或云基础设施。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 身份失陷 – 云账户 |
| 严重性 | 高 (特别是涉及特权账户时) |
| 优先级 | 如果观察到横向移动或数据访问，则为严重 |
| 测来源 | SIEM, CASB, 云原生日志 (例如：AWS CloudTrail, Azure AD), 电子邮件网关, EDR |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 启用云日志记录 | 使用 AWS CloudTrail, Azure 登录日志, Google Workspace 审计日志 |
| 实施 MFA | 对所有用户强制执行，特别是特权账户 |
| 监控用户行为 | 将云日志集成到 SIEM 中，使用异常检测 |
| 设置地理限制和登录告警 | 对不可能的旅行或来自未知 IP 的首次访问发出告警 |
| 应用最小权限 | 使用 RBAC 策略和定期权限审计 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 检测登录异常 | 登录失败、不可能的旅行、MFA 绕过告警 |
| 关联威胁情报 | 将 IP、User-Agent 或域名与 IOC 源进行匹配 |
| 检查访问日志 | 审查失陷后的邮箱、存储、IAM 或 API 活动 |
| 寻找特权提升 | 识别攻击者是否试图获取更多访问权限或创建后门账户 |
| MITRE ATT&CK 映射 | T1078 (有效账户), T1087.004 (云账户发现), T1556.004 (伪造 Web 凭证), T1531 (账户访问移除) |
| --- | --- |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 撤销会话和 token | 使所有活动会话、OAuth token 和 refresh token 失效 |
| 重置密码 | 强制使用强密码并启用 MFA (如果之前未启用) |
| 暂停账户 | 如果确认失陷且影响很大 |
| 封禁 IP 地址 | 如果攻击者使用了已知的恶意 IP 或 TOR 出口节点 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除恶意的收件箱规则或自动化 | 清理自动转发规则、收件箱过滤器和日历共享更改 |
| 禁用恶意应用程序 | 撤销对未经授权的第三方应用的同意 |
| 审查管理员角色 | 还原未经授权的管理员访问权限或权限更改 |
| 恢复已修改的数据 | 如果发生完整性问题 (例如：邮箱删除、S3 文件替换) |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 重新启用账户访问 | 在确保完全恢复控制权且没有持久化存在之后 |
| 通知受影响的用户或利益相关者 | 特别是如果发生了商业电子邮件入侵 (BEC) |
| 监控恢复后的登录异常 | 使用 SIEM 或 CASB 检测重用尝试或相关攻击 |
| 更新访问策略 | 完善条件访问、会话超时和 MFA 执行规则 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行根本原因分析 | 网络钓鱼、弱密码、token 被盗、配置错误 |
| 更新行动手册和检测规则 | 向 SIEM 或 CASB 规则添加改进的指标和逻辑 |
| 教育用户 | 加强关于网络钓鱼和云安全实践的培训 |
| --- | --- |
| 记录事件报告 | 包括时间线、访问方法、受影响的资源以及采取的行动 |
| 履行法律报告义务 | 如果适用 (例如：PDPA, GDPR, 客户 SLAs) |
## 常用工具
SIEM (例如：Microsoft Sentinel, Splunk, QRadar)
云原生日志 (例如：AWS CloudTrail, Azure Log Analytics, Google Workspace 审计日志)
CASB (例如：Netskope, Microsoft Defender for Cloud Apps)
云安全态势管理 (例如：Wiz, Prisma Cloud)
具有身份关联的 EDR/XDR (例如：CrowdStrike, Cortex XDR)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 可疑登录后 <15 分钟 |
| 响应时间 | 锁定和重置凭证 <1 小时 |
| 遏制时间 | 确认后 <30 分钟 |
| 事件后监控期 | 至少 7-14 天 |
# 行动手册 4：Web 应用程序漏洞利用
## 场景
攻击者利用 Web 应用程序或服务器中的漏洞获取未经授权的访问、执行命令或提取敏感数据。该攻击可能通过 WAF 告警、SIEM 日志或异常行为被检测到。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 应用层攻击 |
| 严重性 | 高到严重 (取决于数据暴露或横向移动情况) |
| 优先级 | 高 |
| 检测来源 | Web 应用防火墙 (WAF), SIEM, IDS/IPS, Web 服务器日志, 云监控工具 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 进行定期的漏洞评估 | 使用 Nexpose, Tenable 或 Burp Suite 等工具 |
| 实施 WAF | 配置 OWASP Top 10 规则集 (例如：ModSecurity, Cloudflare, AWS WAF) |
| 记录 HTTP 流量 | 确保 Web 服务器、应用服务器和代理的正确日志记录 |
| 补丁管理 | 自动化 Web 框架、插件和平台的补丁周期 |
| 代码审查与 DevSecOps 集成 | 将 SAST/DAST 工具集成到 CI/CD pipeline 中 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 来自 WAF 或 SIEM 的告警 | SQL 注入、RCE、XSS、LFI/RFI 尝试 |
| 审查日志 | 分析 HTTP 请求、服务器响应、异常错误代码 (例如：500, 403) |
| 验证输入 payload | 通过 payload 确认攻击向量 (例如：' OR 1=1--, ) |
| 检查是否失陷 | 查找 webshell 上传、特权提升、异常进程执行 |
| --- | --- |
| MITRE ATT&CK 映射 | T1190 (利用面向公众的应用), T1059 (命令执行), T1505 (服务器软件组件) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 封禁攻击者 IP | 使用 WAF、防火墙或反向代理阻断源 IP |
| 禁用受影响的 Web 功能 | 暂时关闭易受攻击的模块或 API |
| 隔离应用服务器 | 如果怀疑有横向移动，则将其与内部网络断开 |
| 撤销会话 token | 如果认为用户会话或 cookie 已被劫持 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除恶意脚本或 shell | 搜索 webshell、反向 shell 监听器或后门 |
| 修补被利用的漏洞 | 更新代码、平台、插件或配置错误 |
| 加固应用程序 | 实施输入验证、过滤、参数化查询 |
| 扫描整个应用栈 | 使用更新后的漏洞扫描器重新验证以确认修复 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 恢复服务 | 在确认状态干净后将应用程序重新上线 |
| 监控恢复后情况 | 密切观察日志以防重复尝试或后门访问 |
| 通知受影响的用户或客户 | 如果发生数据泄露，请遵守披露要求 |
| 进行重新测试 | 确认没有残留的访问权限或再次被利用的风险 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 执行根本原因分析 | 识别编码缺陷、配置错误或补丁延迟 |
| 更新 SIEM 和 WAF 规则 | 根据观察到的利用向量添加自定义检测 |
| --- | --- |
| 改进安全编码实践 | 为开发人员举办 OWASP Top 10 的进修培训 |
| 记录事件时间线 | 包括检测时间、TTP、影响和缓解步骤 |
| 按要求报告 | 如果个人数据受到影响，向监管机构或客户报告 |
## 常用工具
WAF (例如：ModSecurity, AWS WAF, Cloudflare)
SIEM (例如：Splunk, Sentinel, QRadar)
Web 服务器日志 (例如：Apache, Nginx)
漏洞扫描器 (例如：Nessus, Qualys, Nikto)
EDR/XDR (如果发生了横向移动)
取证工具 (如果怀疑存在 shell 或系统失陷)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | WAF/SIEM 告警后 <5 分钟 |
| 遏制时间 | 确认后 <30 分钟 |
| 漏洞修补时间 | <24 小时 (严重) 或 <7 天 (高) |
| 事件后重新测试时间 | 恢复后 48 小时内 |
# 行动手册 5：供应链攻击
## 场景
组织通过受信任的第三方服务、软件更新、库、插件或 IT 服务提供商遭到入侵。攻击者利用受信任的关系进行横向移动、部署恶意软件或外发数据。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 供应链失陷 |
| 严重性 | 严重 (由于间接信任利用) |
| 优先级 | 严重 |
| 检测来源 | 威胁情报、SIEM、EDR、漏洞报告、系统异常 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 维护第三方清单 | 列出所有供应商、软件提供商和集成 |
| 进行风险评估 | 评估每个供应商或依赖项的关键性和访问级别 |
| 应用访问限制 | 对第三方服务使用隔离和最小权限 |
| 监控软件行为 | 为所有已安装的组件启用日志记录和行为分析 |
| 验证软件更新 | 对关键应用使用安全通道和签名的二进制文件 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 识别异常行为 | 出站连接、注册表更改、释放的文件、来自意外路径的执行 |
| 对照威胁情报进行验证 | 检查与已知供应链泄露相关的 IOC (例如：SolarWinds, MOVEit, Kaseya) |
| 检查受影响的组件 | 确定最近的更新或第三方访问是否触发了该行为 |
| 审查供应商通信 | 检查公开披露或违规通知 |
| --- | --- |
| MITRE ATT&CK 映射 | T1195.002 (破坏软件依赖关系), T1195.001 (破坏软件供应链), T1105 (入口工具传输) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 断开受影响的系统 | 阻止横向移动和外部通信 |
| 暂停集成或服务 | 禁用与受影响供应商软件、API 或模块的连接 |
| 阻止恶意二进制文件或签名 | 使用 EDR/XDR 阻止已知恶意组件的执行 |
| 隔离可疑主机 | 隔离与攻击者基础设施通信的端点 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除恶意文件或更新 | 卸载或回滚受感染或木马化的软件 |
| 验证软件完整性 | 使用哈希比较或供应商签名的二进制文件 |
| 移除后门或持久化 | 清理注册表项、计划任务、恶意账户或远程访问工具 |
| 更新检测规则 | 将新的 IOC 添加到 SIEM 和 EDR 平台，以便及早发现复发 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 从干净的来源重新安装 | 使用经过验证的安装介质或更新的软件版本 |
| 从备份恢复 | 仅当备份经过验证未受影响时 |
| 重新建立供应商连接 | 在第三方提供商进行修补或验证之后 |
| 恢复正常操作 | 在完全验证遏制和根除之后 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行事后回顾 | 确定时间线、攻击路径、供应商牵涉情况 |
| --- | --- |
| 更新第三方风险计划 | 引入更严格的入职、审计和隔离规则 |
| 通知利益相关者 | 通知管理层、法务和受影响的业务部门 |
与供应商合作 | 共享发现并要求其全面披露缓解状态 |
| 按要求报告 | 监管和合同义务 (例如：PDPA, GDPR, 客户 SLAs) |
## 常用工具
SIEM (例如：Splunk, Sentinel, QRadar)
EDR/XDR (例如：CrowdStrike, Cortex XDR)
威胁情报平台 (例如：MISP, Recorded Future)
软件完整性验证 (例如：sigcheck, 文件哈希工具)
配置管理工具 (例如：SCCM, Ansible, JAMF)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 供应商通知响应时间 | 已知供应商披露后 24 小时内 |
| 失陷检测时间 | 最初迹象出现后 <6 小时 |
| 隔离与遏制时间 | 确认后 <2 小时 |
| 补救完成时间 | 关键系统在 48-72 小时内 |
| 第三方重新评估完成 | 事件关闭后 7 天内 |
# 行动手册 6：通过 USB 设备传播的恶意软件
## 场景
受感染的 USB 存储设备将恶意软件引入环境中。这可能包括 autorun 恶意软件、勒索软件、键盘记录器或用于建立持久化或外发数据的工具。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 基于物理介质的恶意软件感染 |
| 严重性 | 中到高 (取决于恶意软件类型和传播范围) |
| 优先级 | 如果涉及横向移动或敏感数据，则为高 |
| 检测来源 | EDR、防病毒/反恶意软件、SIEM、用户报告、USB 监控工具 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 禁用 USB autorun | 组策略设置或端点加固 |
| 实施 USB 控制软件 | 只允许授权的设备；记录 USB 插入情况 |
| 强制端点保护 | 具有可移动介质保护和行为检测功能的 EDR |
| 教育用户 | 培训员工不要插入未知的 USB 驱动器 |
| 记录 USB 使用情况 | 启用针对可移动介质活动的审计策略 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 检测恶意软件活动 | 来自防病毒软件、EDR 或 SIEM 的关于从 USB 执行进程的告警 |
| 识别 USB 事件 | 查看有关 usb-storage、DevicePlugEvent 或可移动存储设备事件的日志 |
| 分析文件来源 | 确定执行是否从 USB 驱动器开始 (例如：驱动器 D:\ 或 E:) |
| 收集指标 | 哈希值、文件名、执行链、受影响的系统 |
| MITRE ATT&CK 映射 | T1200 (硬件添加), T1091 (通过可移动介质复制), T1059 (命令和脚本解释器) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 隔离受感染的系统 | 断开网络和 USB 端口以防止传播 |
| 移除 USB 设备 | 如有必要，保留以进行取证调查 |
| 在 EDR 或 AV 系统中阻止恶意文件哈希 | 在整个组织中阻止 |
| 识别其他暴露的系统 | 扫描类似的感染或共享的横向移动路径 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除恶意软件 | 使用 EDR 或 AV 工具清理受感染的文件和进程 |
| 删除可疑文件 | 删除临时文件夹、启动目录或 USB 驱动器根目录中的文件 |
| 移除持久化机制 | 检查注册表运行键、计划任务、服务 |
| 执行完整的恶意软件扫描 | 在受感染的主机和附近的系统上 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 恢复系统 | 如果必要，从干净的备份恢复 |
| 恢复连接 | 在确认主机干净之后 |
| 启用更严格的 USB 策略 | 只允许白名单设备或在高风险环境中完全禁用 USB |
| 记录根本原因 | 设备来源、涉及的用户、恶意软件类型、系统影响 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行意识培训 | 强化关于设备使用的安全策略 |
| 更新 USB 策略 | 改进端点控制和文档记录流程 |
| 与安全团队分享发现 | 审查检测漏洞、响应时间和行为指标 |
| 记录事件报告 | 包括所有采取的行动、发现和建议 |
## 常用工具
端点检测与响应 (例如：CrowdStrike, Cortex XDR)
USB 控制解决方案 (例如：DeviceLock, Endpoint Protector, Microsoft Intune 策略)
防病毒软件 (例如：Windows Defender, Bitdefender, Kaspersky)
用于 USB 和文件执行日志记录的 SIEM
Windows 事件日志 (用于设备插入的事件 ID 2003, 2102)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | USB 恶意软件执行后 <10 分钟 |
| 隔离时间 | 确认后 <15 分钟 |
| 恶意软件移除时间 | <1 小时 (如果不需要重建系统) |
| USB 策略执行 | 100% 的端点应用了策略 |
| 用户意识率 | 培训后 ≥ 90% 的用户了解 USB 风险 |
# 行动手册 7：DDoS 攻击
## 场景
外部攻击者发起分布式拒绝服务 攻击，目标是面向公众的基础设施，如网站、API、DNS 服务器或网关。其目的是破坏服务可用性、降低性能或造成声誉和经济损害。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 网络/应用层可用性攻击 |
| 严重性 | 高 (特别是面向客户或关键系统) |
| 优先级 | 如果发生持续中断或服务降级，则为严重 |
| 检测来源 | NOC 告警、SIEM、防火墙日志、应用监控工具、CDN/WAF、ISP 通知 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 实施 DDoS 防护 | 使用基于云的缓解服务 (例如：Cloudflare, AWS Shield, Akamai) |
| 部署 WAF 和速率限制 | 保护应用和 API |
| 确保基础设施的可扩展性 | 使用 autoscaling 组或 CDN 缓存来吸收激增 |
| 与 ISP 建立沟通 | 预定义升级流程和缓解支持 |
| 进行 DDoS 演练 | 模拟 DDoS 场景并验证响应程序 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 识别流量激增 | 监控带宽、请求速率或连接数超过正常阈值的情况 |
| 确定攻击向量 | 是流量型 (UDP flood)、协议型 (SYN flood) 还是应用层 (HTTP GET flood)？ |
| 关联日志 | 识别源 IP、User-Agent、Referrer、payload |
| 确认影响 | 评估性能下降、服务中断或附带损害 |
| --- | --- |
| MITRE ATT&CK 映射 | T1498 (网络拒绝服务), T1499 (端点拒绝服务), T1498.001 (直接网络洪水) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 启动云 DDoS 缓解服务 | 通过缓解提供商路由流量 (例如：Cloudflare Magic Transit) |
| 封禁恶意 IP | 使用防火墙、WAF 或地理封锁规则 |
| 实施速率限制和过滤器 | 按速率阈值或特定模式丢弃流量 |
| 重定向或重新路由流量 | 暂时将流量转移到备用 IP 或负载均衡器 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 丢弃来自已确认恶意来源的流量 | 基于 IP 信誉或行为模式 |
| 调整过滤规则 | 微调 ACL、WAF 策略、IDS/IPS 签名 |
| 移除攻击后的临时规则 | 一旦攻击平息，恢复正常访问模式 |
| 调查混合威胁 | 确认在 disruptions 期间没有发生恶意软件传播或横向移动 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 监控残余流量 | 使用 NOC 仪表板和 SIEM 追踪攻击后的异常情况 |
| 确认服务恢复 | 执行用户验收测试或 API 健康检查 |
| 通知受影响的客户或合作伙伴 | 如果 SLA 或公共服务受到影响 |
| 恢复正常路由 | 如果在攻击期间使用了临时重定向或黑洞路由 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行事件回顾 | 记录时间线、影响、攻击者策略和响应行动 |
| 评估缓解效果 | 确定哪些有效，哪些需要改进 |
| --- | --- |
| 更新响应行动手册 | 完善阈值、告警规则和沟通步骤 |
| 改善供应商协调 | 审查 ISP 和缓解合作伙伴的表现 |
| 按要求报告 | 如果影响严重或持续时间长，向监管机构、领导层或客户报告 |
## 常用工具
SIEM (例如：Splunk, Sentinel, QRadar)
网络流量分析工具 (例如：NetFlow, Zabbix, Ixia)
DDoS 防护服务 (例如：Cloudflare, AWS Shield, Akamai Kona, Arbor)
防火墙/WAF (例如：Fortinet, Palo Alto, ModSecurity)
CDN 和 DNS 服务 (例如：Cloudflare, Fastly, Akamai)
ISP 支持和协调渠道
## 成功指标
| 指标 | 目标 |
| --- | --- |
| DDoS 检测时间 | 攻击开始后 <5 分钟 |
| 缓解启动时间 | 确认后 <15 分钟 |
| 服务停机时间 | 零或 <30 分钟 |
| 客户通知时间 | 如果 SLA 受影响则在 1 小时内 |
| 事后总结完成时间 | 48 小时内 |
# 行动手册 8：商业电子邮件入侵 (BEC)
## 场景
攻击者获取合法商业电子邮件账户的访问权限或进行欺骗，以诱骗内部员工、客户或合作伙伴进行未经授权的电汇、共享凭证或更改财务记录。这可能涉及网络钓鱼、凭证窃取或滥用信任关系。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 社会工程学 / 身份失陷 |
| 严重性 | 高到严重 (由于财务和声誉风险) |
| 优先级 | 严重 |
| 检测来源 | 电子邮件网关、SIEM、EDR、用户报告、云电子邮件审计日志 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 强制执行多因素身份验证 (MFA) | 所有商业电子邮件账户，特别是高管 |
| 监控邮箱活动 | 为 Microsoft 365, Google Workspace 启用云审计日志 |
| 配置电子邮件过滤 | 阻止欺骗域名，实施 SPF, DKIM, DMARC |
| 进行防网络钓鱼培训 | 频繁的网络钓鱼模拟和意识培训 |
| 定义财务控制流程 | 电汇或发票更改需要多人验证 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 识别可疑活动 | 异常的登录地点、新的收件箱规则、意外的电子邮件内容 |
| 分析电子邮件头和元数据 | 验证发送域名、IP 信誉、回复地址 |
| 审查邮箱规则和访问日志 | 查找自动转发、删除过滤器和未经授权的登录 |
| 检查是否涉及财务或 HR | 确定攻击者是否联系了内部或外部的财务/HR 人员 |
| --- | --- |
| MITRE ATT&CK 映射 | T1078 (有效账户), T1114 (电子邮件收集), T1204 (用户执行), T1585.002 (欺骗 - 电子邮件账户) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 撤销访问权限 | 重置密码并使受影响账户的会话/token 失效 |
| 禁用收件箱规则 | 移除任何恶意的转发或删除 |
| 告警可能受影响的用户 | 通知那些收到伪造请求或被冒充的人 |
| 封禁攻击者 IP | 在电子邮件平台或防火墙级别进行封禁 (如果反复出现) |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 全面审计受影响的账户 | 审查登录历史、发送的电子邮件、日历更改、联系人操纵 |
| 移除恶意 artefacts | 删除虚假电子邮件，移除恶意权限或共享的收件箱访问权限 |
| 重新保护账户 | 强制执行强密码策略并在支持的情况下启用条件访问 |
| 进行取证 (如果需要) | 导出日志并为法律或财务调查保留证据 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 重新启用账户访问 | 在确认没有持续风险之后 |
| 恢复合法的邮件流 | 清除自动转发并确保传递设置正确 |
| 通知利益相关者 | 通知事件中涉及的内部团队、供应商或客户 |
| 监控重复活动 | 对高风险账户行为设置 14-30 天的告警 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 执行根本原因分析 | 确定入侵是如何发生的 (网络钓鱼、弱密码、未启用 MFA) |
| 报告财务影响 | 通知财务、风险管理和法务团队 |
| --- | --- |
| 联系执法部门或保险机构 | 如果发生欺诈或政策有要求 |
| 更新行动手册和告警 | 增强对电子邮件转发、IP 异常、登录速度的检测规则 |
| 培训员工防范社会工程学策略 | 重点关注财务、采购和高管人员的意识 |
## 常用工具
SIEM (例如：Sentinel, Splunk, QRadar)
电子邮件安全网关 (例如：Proofpoint, Mimecast, Microsoft Defender for Office 365)
云审计日志 (Microsoft 365 Unified Audit Log, Google Workspace Admin Console)
身份平台 (例如：Okta, Azure AD, Duo)
用于欺骗域名检测和电子邮件 TTP 的威胁情报源
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 网络钓鱼或可疑电子邮件活动发生后 <15 分钟 |
| 遏制时间 | 确认后 <1 小时 |
| 财务欺诈防范 | 阻止电汇或在 24 小时内缓解 |
| 意识宣传活动完成 | 事件发生后 100% 的高风险员工接受了培训 |
| 事件后监控期 | 受影响账户至少 30 天 |
# 行动手册 9：未经授权的特权提升
## 场景
攻击者通过漏洞、配置错误或窃取的凭证，将权限从低权限用户提升到管理员或 root 级别的账户，从而可能危及关键系统或访问敏感数据。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 访问控制违规 / 权限滥用 |
| 严重性 | 高到严重 |
| 优先级 | 严重 |
| 检测来源 | SIEM, EDR, IAM 日志, Sysmon, 用户行为分析 (UBA), 审计轨迹 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 实施 RBAC 和最小权限 | 确保用户仅拥有必要的访问权限 |
| 监控特权账户活动 | 设置针对组成员身份更改和特权提升的告警 |
| 记录特权提升尝试 | 在 Windows (Event ID 4670, 4672, 4728) 和 Linux (sudo logs, auditd) 中启用审计日志 |
| 进行定期的权限审查 | 定期审查管理员权限和组成员身份 |
| 加固端点 | 修补特权提升漏洞并监控利用尝试 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 识别特权提升告警 | 异常的管理员访问、组更改或特权 token |
| 关联用户行为 | 检查用户通常是否具有管理员权限或提升的操作是否在预期之中 |
| 分析进程树 | 查找异常的父子关系 (例如：从 Outlook 派生的 cmd.exe) |
| 验证持久化技术 | 注册表更改、计划任务、使用提升权限创建的服务 |
| --- | --- |
| MITRE ATT&CK 映射 | T1068 (利用漏洞进行特权提升), T1548 (滥用提升控制机制), T1078 (有效账户) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 禁用受影响的用户账户 | 如果提升是未经授权或已被盗用的 |
| 终止提升的会话或进程 | 结束可疑的 PowerShell、cmd 或服务进程 |
| 封禁 IP 或设备 | 如果是横向移动或已知攻击者基础设施的一部分 |
| 通知 IT 或 HR | 如果用户是内部人员且意图不明 (恶意还是失误) |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 还原权限更改 | 移除提升的权限、组成员身份或访问 token |
| 清理持久化机制 | 移除攻击者创建的计划任务、注册表修改、服务项 |
| 修补被利用的漏洞 | 应用针对内核级或操作系统级缺陷的修复 (例如：CVE-2021-36934) |
| 审查 IAM 策略和 GPO | 解决任何继承的配置错误或意外的权限继承 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 重新启用合法用户 | 审查后赋予正确的访问权限 |
| 恢复受影响的系统 | 如果在提升期间有任何配置或数据被更改 |
| 恢复操作 | 一旦验证干净且安全 |
| 进行补救后扫描 | 确认没有后门或提升路径残留 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 记录完整的提升路径 | 特权是如何获得的，访问或修改了什么 |
| 更新 SIEM 检测规则 | 针对异常的权限更改和敏感命令执行 |
| --- | --- |
| 改善身份治理 | 强制执行更严格的访问请求和审批工作流 |
| 按要求报告 | 特别是如果数据被访问或篡改 |
| 教育特权用户 | 关于正确访问卫生和安全控制的重要性 |
## 常用工具
SIEM (例如：Splunk, Sentinel, QRadar)
EDR (例如：CrowdStrike, Cortex XDR, Microsoft Defender for Endpoint)
IAM 平台 (例如：Azure AD, Okta, LDAP, Active Directory)
Windows 事件日志 (安全日志、Sysmon、GPO 审计)
Linux 审计工具 (auditd, sudo logs)
威胁检测规则 (Sigma, KQL, YARA，用于可疑的特权活动)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 提升事件发生后 <5 分钟 |
| 遏制时间 | 确认后 <30 分钟 |
| 还原时间 | 移除提升访问权限 <1 小时 |
| 审计和 RCA 完成 | 48 小时内 |
| 特权账户审查完成 | 事件后 7 天内 100% 完成 |
# 行动手册 10：云存储配置错误暴露
## 场景
由于云存储服务上的权限配置错误，敏感或机密数据 (例如：日志、数据库、个人信息) 被暴露给公众，通常是通过威胁情报源、自动化扫描器或内部审计发现的。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 数据暴露 – 配置错误 |
| 严重性 | 高到严重 (取决于数据的敏感性) |
| 优先级 | 高 |
| 检测来源 | 云安全态势管理 (CSPM), SIEM, 威胁情报, 外部通知 (例如：研究人员、媒体), 审计日志 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 强制执行默认安全策略 | 在组织级别阻止对云存储服务的公共访问 |
| 实施 CSPM 工具 | 持续监控配置错误 (例如：Wiz, Prisma Cloud, AWS Config) |
| 启用访问日志记录 | 针对云存储服务 (例如：AWS S3 访问日志, Azure 诊断) |
| 标记和分类敏感数据 | 使用数据分类工具标记高风险信息 |
| 执行定期云审计 | 审查存储桶、blob 和容器的访问设置 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 收到来自 CSPM 或威胁情报的告警 | 示例："在存储备份文件的 S3 存储桶上检测到公共读取访问" |
| 审查对象权限 | 确定哪些文件被暴露以及谁可以访问它们 (公众、匿名用户、特定用户) |
| 评估数据敏感性 | 识别暴露数据的类型 (例如：PII、财务数据、密码、API 密钥) |
| 检查访问日志 | 确定是否发生了任何未经授权的访问 (IP 地址、时间戳) |
| --- | --- |
| MITRE ATT&CK 映射 | T1530 (来自云存储对象的数据), T1562.007 (禁用或修改云存储日志记录) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 立即限制公共访问 | 移除存储桶或对象上的 'public-read', 'allUsers' 或 'anonymous' 权限 |
| 禁用共享链接 | 撤销签名 URL 或公共对象 URL |
| 通知受影响的团队 | 告警数据所有者、合规和安全团队以进行风险评估 |
| 隔离受损的凭证 | 如果暴露了 API 密钥或凭证，立即轮换 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 审查和修复 IAM 策略 | 审计并调整过于宽松的角色或存储策略 |
| 启用存储桶/块级别的保护 | 强制执行默认加密、版本控制和公共访问阻断 |
| 清理暴露的数据 | 移除或归档不必要的文件，清洗暴露的内容 |
| 重新配置安全共享机制 | 使用基于身份的访问控制而不是公共共享链接 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 验证适当的访问控制 | 确认仅限目标用户和服务进行访问 |
| 确认数据完整性 | 确保没有发生篡改或未经授权的修改 |
| 恢复操作 | 一旦云存储得到适当保护，即恢复使用 |
| 更新清单 | 在资产和数据跟踪系统中反映当前的访问控制状态 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行根本原因分析 | 确定暴露是由于人为错误、策略失效还是自动化引起的 |
| --- | --- |
| 更新 CSPM 和 SIEM 检测 | 针对权限漂移和外部访问尝试调整告警 |
| 培训开发人员和 DevOps 团队 | 在 CI/CD pipeline 中强化安全配置实践 |
| 按要求报告 | 如果 PII 或机密数据被暴露，通知监管机构或客户 |
| 记录经验教训 | 相应地更新云治理策略和事件行动手册 |
## 常用工具
CSPM 工具 (例如：Wiz, Prisma Cloud, AWS Config, Microsoft Defender for Cloud)
SIEM (例如：Sentinel, Splunk)
云审计日志 (例如：AWS CloudTrail, Azure Activity Logs, GCP Admin Activity)
IAM 系统 (例如：AWS IAM, Azure AD, Google IAM)
DLP 或分类系统 (例如：Microsoft Purview, Symantec DLP)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 暴露后 <1 小时 |
| 移除访问时间 | 告警后 <30 分钟 |
| 公共暴露持续时间 | 理想情况下 <1 小时 |
| 影响评估完成 | 24-48 小时内 |
| 策略补救时间 | 72 小时内 |
# 行动手册 11：凭证填充攻击
## 场景
攻击者使用自动化工具和僵尸网络，针对登录门户测试大量被盗凭证 (通常来自暗网泄露)，以期重复使用有效的用户名-密码组合。这可能导致未经授权访问用户账户以及潜在的数据盗窃或欺诈。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 通过凭证滥用的账户接管 |
|严重性 | 高 (特别是金融、SaaS 或个人数据服务) |
| 优先级 | 高 |
| 检测来源 | SIEM, IAM 日志, WAF, 欺诈检测系统, 应用日志, CDN 安全层 (例如：Cloudflare, Akamai) |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 强制执行 MFA | 对抗凭证重用的最强防御 |
| 限制登录尝试速率 | 使用 WAF/CDN 或应用级别的节流 |
| 监控凭证填充模式 | 失败登录激增、来自多个地理位置的登录尝试 |
| 使用 CAPTCHA 或机器人防护 | 阻止自动化工具 |
| 订阅凭证泄露源 | 集成 HaveIBeenPwned, SpyCloud 或类似来源 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 识别异常登录活动 | 来自同一 IP 的多个用户名的大量失败尝试 |
| 审查 IAM 和应用日志 | 跟踪登录频率、IP、设备指纹、User-Agent |
| 检查机器人行为 | 不可能的旅行、时间窗口内过量的登录、顺序模式 |
| 验证账户接管 | 确定使用泄露凭证的登录是否成功 |
| MITRE ATT&CK 映射 | T1110.001 (暴力破解 - 密码猜测), T1078 (有效账户), T1589.001 (凭证：用户名), T1589.002 (密码) |
| --- | --- |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 封禁 IP 或 IP 范围 | 使用 WAF, CDN 或防火墙阻止违规来源 |
| 触发强制密码重置 | 针对凭证被重用的受影响用户 |
| 节流流量 | 暂时应用更严格的速率限制或地理封锁规则 |
| 暂停受影响的会话 | 使可疑账户的活动会话和 token 失效 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除测试账户或注入的数据 | 如果攻击者创建了新用户或添加了持久化 artefacts |
| 修补登录滥用向量 | 加固登录流程，禁用用户名枚举，限制错误消息提示 |
| 强制使用更强的密码 | 如果在使用弱凭证，则更新密码策略 |
| 增强检测规则 | 微调针对凭证填充尝试的告警阈值和响应自动化 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 通知用户 | 告警受影响用户关于强制重置和可能的失陷情况 |
| 监控重复尝试 | 继续加强监控 24-72 小时 |
| 重新启用访问 | 一旦账户通过 MFA 和/或新凭证得到保护 |
| 审查和测试控制 | 确保速率限制、MFA 执行和日志记录机制有效 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行根本原因分析 | 是否滥用了特定的 API、endpoint 或薄弱的控制？ |
| 记录受影响的用户和账户 | 统计来自恶意来源的成功登录次数 |
| 向监管机构报告 | 如果账户接管导致个人或财务数据泄露 |
| --- | --- |
| 更新安全控制 | 应用地理围栏、浏览器指纹识别、CAPTCHA 和机器人缓解工具 |
| 改善用户沟通 | 提供关于密码安全和泄露告警后续跟进的指导 |
## 常用工具
WAF/CDN (例如：Cloudflare, Akamai, AWS WAF)
IAM 日志和系统 (例如：Azure AD, Okta, AWS Cognito)
SIEM (例如：Sentinel, Splunk)
Bot 检测服务 (例如：reCAPTCHA, PerimeterX, Cloudflare Bot Management)
泄露监控平台 (例如：SpyCloud, HaveIBeenPwned)
威胁情报平台 (例如：Recorded Future, MISP)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 登录尝试激增后 <5 分钟 |
| 遏制时间 | 攻击确认后 <30 分钟 |
| 用户影响缓解时间 | 强制重置和通知 <2 小时 |
| 复发率 | 应用控制后零重用 |
| 攻击后监控期 | 受影响系统或门户至少 7-14 天 |
# 行动手册 12：未经授权的内部数据库访问
## 场景
内部人员或受损系统以未经授权的方式访问数据库资源，例如绕过访问控制、查询敏感表或不当使用特权数据库账户。这可能包括数据窥探、未经授权的导出或针对数据库服务器的横向移动。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 访问控制违规 – 数据访问滥用 |
| 严重性 | 高 (特别是涉及 PII、财务数据或知识产权时) |
| 优先级 | 严重 |
| 检测来源 | SIEM, 数据库活动监控 (DAM), 用户行为分析 (UBA), EDR, 应用日志 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 实施数据库活动监控 | 使用 Imperva DAM, IBM Guardium 或原生审计日志等工具 |
| 使用最小权限限制访问 | 使用基于角色的访问并限制直接的数据库访问 |
| 启用日志记录和告警 | 记录所有特权查询、schema 访问和身份验证事件 |
| 定期审查数据库角色和权限 | 审计所有数据库用户和服务账户的权限 |
| 加密敏感数据 | 保护高价值字段 (例如：PII、密码) 的静态和传输安全 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 收到来自 DAM 或 SIEM 的告警 | 异常的查询量、直接表扫描或非工作时间访问 |
| 关联用户行为 | 审查用户的历史数据库访问模式 |
| 检查查询或事务 | 确定访问、修改或导出了哪些数据 |
| 检查横向移动 | 查看访问是否发生在端点或网络被入侵之后 |
| --- | --- |
| MITRE ATT&CK 映射 | T1071.001 (通过 Web 协议外发), T1213.003 (访问数据库中的敏感数据), T1078 (有效账户) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 撤销数据库访问权限 | 禁用或暂停违规账户或连接 |
| 隔离受损端点 | 如果访问来自被入侵的主机 |
| 阻止出站数据传输 | 如果怀疑有数据外发，通过 DLP、防火墙或代理进行阻止 |
| 通知数据所有者和 IT 安全部门 | 让利益相关者参与即时的遏制决策 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 重置凭证或 token | 针对被滥用的数据库账户 |
| 移除恶意用户或权限 | 审计数据库中的隐藏用户、触发器或提升的权限 |
| 修补漏洞 | 如果应用程序或数据库中的缺陷被利用 |
| 清理日志 | 在移除或修剪之前，归档并保护日志以供取证调查 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 恢复合法访问 | 在对用户角色进行适当的重新验证之后 |
| 监控重复访问 | 对相同的用户或主机应用增强的监控 |
| 执行完整性检查 | 验证在事件期间没有数据被更改或损坏 |
| 恢复服务 | 一旦安全并验证完毕，即恢复应用程序或数据库操作 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 进行事后分析 | 了解这是恶意的、意外的还是系统性的 |
| 增强数据库监控规则 | 添加新的模式和告警条件 |
| --- | --- |
| 培训用户和 DBA | 强化数据访问策略和日志记录期望 |
| 报告数据暴露 | 如果法律或策略有要求 (例如：PDPA, GDPR, PCI DSS) |
| 更新操作手册 | 在 SOC 文档中包含行动手册的完善和经验教训 |
## 常用工具
SIEM (例如：Splunk, Sentinel, QRadar)
数据库活动监控 (例如：Imperva, IBM Guardium, AWS RDS Logs)
用户行为分析 (例如：Exabeam, Securonix)
EDR (如果涉及端点)
应用日志 (例如：来自调用数据库的中间件或 API)
DLP 和网络代理 (用于检测潜在的数据外发)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 未经授权访问后 <5 分钟 |
| 遏制时间 | 确认后 <30 分钟 |
| 取证审查完成 | 48 小时内 |
| 角色/权限审计完成 | 7 天内 |
| 策略更新和重新验证 | 2 周内 |
# 行动手册 13：影子 IT 资产发现
## 场景
发现了以前未知或未经授权的 IT 资产 (例如：云服务、SaaS 应用程序、个人笔记本电脑、未经授权的 Wi-Fi 接入点或未获批的 Web 应用) 在公司环境内运行或连接，可能绕过安全控制并增加风险暴露。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 资产管理 / 策略违规 |
| 严重性 | 中到高 (基于访问或暴露的数据) |
| 优先级 | 如果与敏感系统或用户相关联，则为高 |
| 检测来源 | CASB, EDR, SIEM, 资产发现工具, 代理日志, DNS 日志, 员工举报 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 保持资产清单最新 | 使用 CMDB 或自动化资产发现工具 |
| 部署 CASB 和端点遥测 | 检测未经批准的 SaaS 使用或外部连接 |
| 定义可接受的使用和应用程序策略 | 包括关于允许用户使用什么的明确指导 |
| 监控出站 DNS 和代理日志 | 识别正在使用的异常域名或服务 |
| 教育员工有关影子 IT 的风险 | 定期培训和可接受使用策略 (AUP) 意识培养 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 收到来自 CASB 或网络日志的告警 | 未经批准的应用程序或云服务使用情况 |
| 发现未经授权的设备或接入点 | 来自网络扫描、NAC 告警或 EDR 遥测 |
| 关联用户或部门 | 识别负责使用的用户或业务部门 |
| 评估风险和范围 | 访问了哪些数据，存储在哪里以及谁使用了它 |
| --- | --- |
| MITRE ATT&CK 映射 | T1584 (破坏基础设施), T1087.001 (账户发现：本地账户), T1078 (有效账户) —— 影子 IT 可能是攻击者基础设施或横向移动的一部分 |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 阻止未经授权的服务或域名 | 通过防火墙、DNS 或代理控制 |
| 禁用未经授权资产的網絡访问 | 使用 NAC、交换机端口禁用或 Wi-Fi 控制 |
| 撤销用户访问权限 | 针对发现正在使用的未经授权的应用或工具 |
| 通知负责的团队 | 与引入资产的团队或用户合作，了解业务意图 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除未经批准的软件 | 从端点、服务器或内部系统 |
| 停用未经授权的基础设施 | 关闭不在清单中的 VM、容器、云服务或本地主机 |
| 清理凭证 | 如果密码或 token 与未经授权的系统共享过 |
| 更新资产发现签名 | 在未来的扫描中为类似的工具或配置添加新的检测规则 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 载入批准的替代品 | 帮助用户迁移到授权的工具或服务 |
| 恢复正常访问 | 仅在所有受影响的系统得到验证和保护之后 |
| 更新资产清单 | 将新发现的合法系统纳入官方跟踪 |
| 重新验证用户角色 | 确保没有权限蔓延或策略绕过仍然活跃 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- --- |
| 记录事件时间线 | 发现了什么，如何发现的，何时以及由谁发现的 |
| 改善用户工作流 | 为影子 IT 解决方案提供安全且受支持的替代方案 |
| 修订可接受使用策略 | 明确规则并包括异常情况的升级流程 |
| 分享事件报告 | 与 IT、安全治理和部门主管 |
| 进行后续审计 | 以验证其他地方没有使用类似的资产或服务 |
## 常用工具
CASB (例如：Netskope, Microsoft Defender for Cloud Apps, McAfee MVISION)
SIEM (例如：Splunk, Sentinel, QRadar)
端点工具 (例如：CrowdStrike, Cortex XDR)
网络扫描器 (例如：Nmap, Qualys, Nessus, Fing)
DNS/代理日志和分析 (例如：Cisco Umbrella, Squid, Zscaler)
CMDB / IT 资产管理 (例如：ServiceNow, Lansweeper)
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 资产引入后 <1 天 |
| 遏制时间 | 确认后 <4 小时 |
| 资产清单更新时间 | 事件后 24 小时内 |
| 用户再教育完成 | 涉及的用户 100% 在 7 天内完成再培训 |
| 策略合规执行 | 在下一次审计周期中对类似案例的确认 |
# 行动手册 14：RDP 暴力破解攻击
## 场景
攻击者对暴露在互联网或内部的 RDP 服务发起暴力破解或密码喷洒攻击，试图利用弱口令或重复使用的凭证获取访问权限。成功的访问可能会导致横向移动、恶意软件部署或数据外发。
## 事件分类
| 类别 | 详情 |
| --- | --- |
| 事件类型 | 凭证攻击 – RDP 登录滥用 |
| 严重性 | 高 (特别是针对特权或敏感系统) |
| 优先级 | 如果获取了访问权限，则为严重 |
| 检测来源 | SIEM, Windows 安全事件日志, EDR, IDS/IPS, 防火墙日志, 威胁情报 |
## 阶段与行动
### 1. 准备阶段 (事件前设置)
| 任务 | 工具/行动 |
| --- | --- |
| 限制 RDP 暴露 | 使用 VPN、零信任访问或通过防火墙进行限制 |
| 强制执行强身份验证 | 使用 MFA 并禁用默认管理员账户 |
| 监控 RDP 登录事件 | 启用对 Event ID 4625 (登录失败) 和 4624 (登录成功) 的日志记录 |
| 应用账户锁定策略 | 限制失败的登录尝试次数 |
| 部署蜜罐或诱饵 | 在虚假系统上主动检测暴力破解尝试 |
### 2. 检测与分析
| 步骤 | 行动 |
| --- | --- |
| 来自 SIEM 或 EDR 的告警 | RDP 登录失败尝试激增、密码喷洒行为 |
| 审查事件日志 | 按 Event ID 4625 过滤并识别常见的用户名和 IP |
| 关联成功的登录 | 确定暴力破解是否成功并且特权是否被提升 |
| 分析攻击者 IP | 检查地理位置、信誉以及在其它系统中的再次出现情况 |
| MITRE ATT&CK 映射 | T1110.001 (暴力破解 - 密码猜测), T1078 (有效账户), T1021.001 (远程服务 - RDP) |
### 3. 遏制
| 步骤 | 行动 |
| --- | --- |
| 封禁攻击者 IP | 在防火墙、IDS 或 VPN 网关处封禁 |
| 禁用受影响的账户 | 锁定或重置成为目标或被攻陷的账户 |
| 隔离受影响的主机 | 如果怀疑有横向移动或恶意软件部署 |
| 节流或禁用 RDP | 暂时禁用高风险系统上的 RDP 直到安全为止 |
### 4. 根除
| 步骤 | 行动 |
| --- | --- |
| 移除未经授权的访问 | 终止会话、重置密码并撤销 token 或证书 |
| 修补暴露的系统 | 更新 RDP 服务和操作系统以防止漏洞利用 (例如：BlueKeep) |
| 清理持久化机制 | 检查攻击者添加的新的计划任务、服务或注册表项 |
| 验证没有横向移动 | 使用 EDR 或日志审查确保攻击者没有在内部扩散 |
### 5. 恢复
| 步骤 | 行动 |
| --- | --- |
| 恢复安全的 RDP 访问 | 仅通过 VPN 或带有 MFA 的堡垒机 |
| 通知用户或 IT 团队 | 向受登录尝试或凭证重置影响的人员发出告警 |
| 密切监控事件后情况 | 观察持续的暴力破解活动或有针对性的重试 |
| 进行密码审计 | 如果使用了弱凭证，督促全公司进行密码卫生检查 |
### 6. 经验教训与报告
| 步骤 | 行动 |
| --- | --- |
| 分析时间线 | 回顾攻击开始时间、被检测到的时间以及停止的速度 |
| 更新 SIEM 规则 | 改进对暴力破解指标和高失败阈值的检测 |
| 修订访问策略 | 在整个组织中实施更严格的 RDP 使用控制 |
| 分享发现 | 与内部利益相关者，以及如果需要的话，与外部权威机构或供应商分享 |
| 测试安全控制 | 验证检测、预防和响应是否按预期工作或需要调整 |
| --- | --- |
## 常用工具
SIEM (例如：Splunk, Sentinel, QRadar)
EDR (例如：CrowdStrike, Microsoft Defender for Endpoint, Cortex XDR)
防火墙和 VPN 日志 (例如：Fortinet, Palo Alto, Cisco ASA)
Windows 事件查看器 (安全日志：4624, 4625, 4648, 4672)
威胁情报平台 (用于 IP 丰富)
暴力破解检测脚本或 SOAR 行动手册
## 成功指标
| 指标 | 目标 |
| --- | --- |
| 检测时间 | 暴力破解模式开始后 <5 分钟 |
| 遏制时间 | 确认后 <30 分钟 |
| 凭证重置时间 | 被盗或成为目标的账户 <2 小时 |
| 暴露时间 | 未经授权的 RDP 访问不超过 15 分钟 |
| RDP 锁定覆盖范围 | 100% 面向互联网的 RDP 端点已保护或移除 |
| 评估触及的数据 | 确定是否访问了源代码、pipeline 配置或 secrets |
| --- | --- |
| MITRE ATT&CK
映射 | T1087.001 (账户发现), T1059 (通过 CI 执行命令),
T1606 (伪造 Web 凭证), T1565.002 (数据操纵 - 代码仓库) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销用户/API 访问权限 | 禁用用于访问的用户账户或令牌 | | 暂停 pipeline 执行 | 暂停 CI/CD 活动以防止进一步的破坏 | | 隔离受影响的系统 | 临时阻止对关键环境或服务器的访问 | | 通知 DevOps 和安全团队 | 协调遏制和代码审查活动 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 移除未经授权的代码或脚本 | 还原恶意提交，回滚 pipeline 更改 | | 轮换密钥和凭证 | 特别是如果在代码、环境变量或配置文件中发现它们 | | 清理受损账户 | 移除旧的用户、服务账户或令牌 | | 修补工具漏洞 | 对暴露或配置错误的 DevOps 平台应用更新 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复安全状态 | 确认代码和 pipeline 是干净的，且访问仅限于授权用户 | | 恢复 CI/CD 操作 | 仅在验证系统完整性之后 | | 监控代码库和构建过程 | 建立事件发生后的增强日志记录和监控 | | 重新验证审计控制 | 确保访问日志、版本控制和变更跟踪已启用且正常工作 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行全面审查 | 了解攻击向量、涉及的用户和受影响的数据 | | 更新访问策略 | 对敏感仓库和构建系统实施更严格的控制 | | --- | --- | | 培训 DevOps 人员 | 强化安全访问管理和代码审查策略 | | 向利益相关者报告 | 如果涉及专有或受监管数据，需通知法律、合规部门和客户 | | 记录 playbook 更新 | 改进 SOC 和 DevOps 团队未来的检测和响应流程 | ## 通常涉及的工具 SIEM（例如 Sentinel、Splunk） Git 平台（例如 GitHub、GitLab、Bitbucket） CI/CD 工具（例如 Jenkins、GitLab CI、CircleCI、Azure DevOps） IAM 和 SSO（例如 Okta、Azure AD、Google Workspace） 密钥扫描器（例如 TruffleHog、Gitleaks） 容器安全工具（例如 Aqua、Prisma Cloud） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 未经授权访问后 <10 分钟 | | 访问撤销时间 | 警报后 <30 分钟 | | 密钥轮换时间 | 高价值令牌或密钥 <1 小时 | | 代码库验证时间 | <24 小时 | | 事件后审计完成时间 | 3 个工作日内 | # Playbook 16：滥用 OAuth 集成 ## 场景 攻击者通过诱骗用户授权恶意的 OAuth 应用程序（例如通过网络钓鱼或社会工程学）来获取用户的云或应用程序账户访问权限。这无需登录凭证即可获得持久访问权限，在许多情况下甚至能绕过 MFA。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 第三方应用程序滥用 / 基于令牌的账户失陷 | | 严重程度 | 高到严重（特别是如果授予了特权或敏感账户访问权限） | | 优先级 | 严重 | | 检测来源 | SIEM、OAuth 审计日志、云身份平台（例如 Google Workspace、Azure AD）、用户报告、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 监控 OAuth 授权 | 为应用程序同意和令牌授予启用日志记录 | | 限制第三方应用权限 | 实施策略以限制高权限访问 | | 强制执行管理员同意工作流 | 要求安全团队批准高风险的 OAuth 作用域 | | 教育用户网络钓鱼风险 | 强调授权未知应用程序的风险 | | 将身份日志集成到 SIEM | 关联令牌活动和应用程序安装情况 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 检测可疑的应用同意 | OAuth 应用程序请求异常权限或被大量账户广泛使用 | | 审查审计日志 | 检查是否向未知或最近创建的应用程序颁发了令牌 | | 识别受影响的用户 | 映射授权了恶意应用程序的用户并评估数据访问范围 | | 调查应用程序行为 | 确定该应用程序是否访问了电子邮件、文件、云存储或联系人 | | MITRE ATT&CK
映射 | T1525 (植入内部镜像), T1556.004 (伪造 Web 凭证), T1087 (账户发现) | # Playbook 15：对开发环境的未经授权访问 ## 场景 个人未经授权获得对开发环境（例如 Git 仓库、暂存服务器、像 Jenkins 或 GitLab CI 这样的 CI/CD 平台或测试数据库）的访问权限。这可能导致代码被盗、插入恶意代码或泄露凭证和机密。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 访问控制违规 / 内部威胁 | | 严重程度 | 高（特别是如果源代码或机密被访问或修改） | | 优先级 | 严重 | | 检测来源 | SIEM、Git 日志、IAM、DevOps 工具（例如 Jenkins、GitLab）、审计追踪、源代码版本控制系统 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制执行基于角色的访问控制 | 对所有开发工具使用 IAM 策略、SSO 和最小特权原则 | | 启用审计和日志 | 跟踪对 Git 仓库、CI/CD 系统和测试环境的访问 | | 将日志流集成到 SIEM | 从 GitHub/GitLab、Jenkins 等流式传输日志 | | 应用机密扫描工具 | 检测代码中硬编码的凭证和令牌 | | 开展 DevSecOps 培训 | 教育开发人员关于安全编码和仓库卫生的知识 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 IAM/SIEM 的警报 | 来自异常 IP 或用户的可疑登录、令牌使用或仓库访问 | | 审查 Git/CI 日志 | 检查最近的提交、合并、pipeline 执行和用户访问情况 | | 识别访问方法 | 直接登录、API 令牌、SSH 密钥或 OAuth 集成 | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销应用程序访问权限 | 通过管理门户或 API 从受影响的账户中移除 OAuth 授权/令牌 | | 在租户级别阻止应用程序 | 在 Google Workspace、Azure 或 GitHub 设置中禁止该应用程序的客户端 ID | | 禁用受影响的账户（如果需要） | 如果攻击者利用应用程序访问权限进行进一步横向移动 | | 通知用户 | 提醒他们有关撤销操作和潜在的数据泄露风险 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 轮换访问令牌和密码 | 如果应用程序访问了凭证或机密，需轮换用户和服务账户的令牌和密码 | | 清理受影响的环境 | 删除任何后门、转发规则或通过 OAuth 应用程序上传的文件 | | 加强租户范围内的策略 | 限制高风险的 OAuth 作用域（例如 offline access、mail.readwrite、drive full access） | | 更新网络钓鱼防护 | 阻止分发 OAuth 应用程序的相关钓鱼域名或链接 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复受影响的访问权限 | 在确认账户安全且已移除 OAuth 应用程序之后 | | 重新审计已连接的应用程序 | 确认用户中没有安装其他高风险应用程序 | | 强化用户 MFA 和会话控制 | 收紧身份策略（例如，撤销会话，要求重新身份验证） | | 恢复业务运营 | 一旦确认不存在来自恶意集成的进一步风险 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行影响分析 | 应用程序访问或共享了哪些数据？在什么时间段内？ | | 必要时进行报告 | 向法律、合规、监管机构（例如 PDPA、GDPR）或客户报告 | | 更新同意策略 | 要求对高风险应用作用域实行更严格的管理员控制 | | --- | --- | | 在内部共享事件详情 | 提高防范意识并更新安全意识培训材料 | | 改进检测逻辑 | 调优 SIEM 或 SOAR playbook 以检测高风险的 OAuth 授权和异常情况 | ## 通常涉及的工具 云管理控制台（例如 Google Workspace Admin、Azure AD Portal、Microsoft 365 Defender） 身份保护（例如 Okta、Duo、Conditional Access） SIEM（例如 Splunk、Sentinel、QRadar） 云安全工具（例如 Microsoft Defender for Cloud Apps、G Suite Alert Center） 用于网络钓鱼和应用信誉的威胁情报 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 高风险应用授权后 <15 分钟 | | 应用撤销时间 | 发现后 <30 分钟 | | 用户通知时间 | 受影响用户 <1 小时 | | OAuth 策略执行 | 100% 的用户处于管理员同意模式下（对于敏感作用域） | | 事件解决时间 | 发现后 24–48 小时内 | # Playbook 17：通过 DNS 隧道进行数据渗出 ## 场景 攻击者使用 DNS 作为通信信道来渗出数据或维持命令与控制。DNS 隧道将恶意 payload 或被盗数据隐藏在 DNS 查询中，由于 DNS 流量通常是被允许的，因此可以绕过传统的检测手段。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 隐蔽通道 – 数据渗出 | | 严重程度 | 高到严重（特别是如果确认有敏感数据被渗出） | | 优先级 | 严重 | | 检测来源 | DNS 日志、SIEM、NDR、威胁情报、端点警报、Zeek、Suricata | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 启用详细的 DNS 日志记录 | 从 DNS 解析器和转发器（例如 BIND、Windows DNS、Unbound）获取 | | 实施 DNS 检查 | 使用 NDR（例如 Corelight、Darktrace）、防火墙规则和模式匹配 | | 监控异常 DNS 活动 | 大量 TXT 查询、长域名、异常频率 | | 阻止已知的隧道工具 | 例如，通过威胁情报阻止 Iodine、DNScat2、DnsExfiltrator | | 对出站 DNS 强制执行最小特权 | 仅允许来自内部资产的授权 DNS 解析器 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 检测异常的 DNS 模式 | 较长的子域名长度、对罕见域名的频繁查询、base64 编码 | | 审查 DNS 日志 | 识别被查询的域名、查询类型（例如 TXT、NULL）以及涉及的端点 | | 与资产行为进行关联 | 确定发送查询的端点是否也显示出受损迹象 | | 验证域名所有权 | 检查可疑域名是否由攻击者控制或最近才注册 | | --- | --- | | MITRE ATT&CK
映射 | T1048.003 (通过非加密/混淆的非 C2 协议渗出), T1071.004 (应用层协议: DNS), T1568.002 (动态解析 - DNS) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 阻止可疑域名 | 在 DNS 解析器、防火墙和代理级别进行阻止 | | 隔离受影响的主机 | 断开网络连接以停止正在进行的渗出 | | 重定向 DNS 流量 | 强制所有出站 DNS 通过受监控的内部 DNS 服务器 | | 警报内部利益相关者 | IT、安全和管理层应立即得到通知 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 移除隧道工具或恶意软件 | 使用 EDR 或取证分析从端点中移除 | | 修补被利用的漏洞 | 如果攻击者是通过已知弱点访问权限的 | | 清理持久性机制 | 检查计划任务、注册表更改或启动脚本 | | 审查 DNS 配置 | 确保端点或服务器上不存在外部 DNS 绕过 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复网络连接 | 一旦系统被验证为干净且遏制控制已到位 | | 恢复 DNS 服务 | 强制通过带有检查功能的安全 DNS 基础设施进行转发 | | 重新验证受影响的系统 | 对以前受感染的主机执行全面扫描和流量监控 | | 更新威胁检测规则 | 使用新的指标和模式增强 SIEM、NDR 和防火墙规则 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录完整的渗出路径 | 确定哪些数据被作为目标或丢失，以及方式和时间 | | --- | --- | | 更新事件响应计划 | 增加针对 DNS 的检测和响应协议 | | 提高 DNS 可见性 | 在所有环境中强制执行结构化的 DNS 日志记录和分析 | | 如适用则报告数据泄露 | 根据 PDPA、GDPR、HIPAA 或特定行业法规进行报告 | | 共享 IOC 和发现 | 在内部以及与外部威胁情报社区（例如 ISACs）共享 | ## 通常涉及的工具 DNS 日志平台（例如 Infoblox、Bind logs、Windows DNS logs） NDR（例如 Corelight/Zeek、Darktrace、ExtraHop） SIEM（例如 Splunk、Sentinel、QRadar） EDR（例如 CrowdStrike、Cortex XDR） 威胁情报（例如 Recorded Future、MISP、AbuseIPDB） 防火墙和代理日志 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常 DNS 模式出现后 <15 分钟 | | 遏制时间 | 确认后 <30 分钟 | | 数据丢失影响报告 | 48 小时内（或在监管规定的时间内） | | DNS 日志覆盖率 | 100% 的出站 DNS 活动被记录和监控 | | 事件审查完成时间 | 解决后 72 小时内 | # Playbook 18：公共网站上未经授权的 JavaScript 注入 ## 场景 攻击者向面向公众的网站注入恶意 JavaScript 代码（通过受损的 CMS、第三方脚本、配置不当的 CDN 或直接替换文件）。这可能导致凭证收集、数据窃取（例如 Magecart）、点击劫持、重定向到恶意站点或会话劫持。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | Web 应用程序失陷 – 脚本注入 | | 严重程度 | 高到严重（特别是如果捕获了 PII、卡数据或身份验证数据） | | 优先级 | 严重 | | 检测来源 | WAF、SIEM、网站监控工具、Bug Bounty 报告、客户反馈、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 实施 CSP (内容安全策略) | 限制未经授权的脚本加载 | | 监控文件完整性 | 使用工具跟踪生产环境中 JS 文件的更改 | | 使用子资源完整性 (SRI) | 针对第三方脚本，确保它们未被篡改 | | 启用 Web 应用防火墙 (WAF) | 阻止可疑输入或漏洞利用企图 | | 定期执行代码审计 | 特别是针对 CMS 插件和第三方引入项 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 WAF 或监控工具的警报 | 检测到注入或被修改的 JavaScript | | 验证文件更改 | 将修改后的 JavaScript 与已知良好版本（Git、备份）进行比较 | | 审查注入源 | 是来自 CMS 插件、第三方来源还是直接编辑代码？ | | --- | --- | | 检查脚本行为 | 分析 payload：键盘记录、渗出、重定向、数据捕获 | | MITRE ATT&CK
映射 | T1059.007 (JavaScript), T1185 (浏览器会话劫持), T1189 (路过式入侵), T1557.002 (通过 Web 脚本进行输入捕获) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 移除或替换注入的脚本 | 立即从备份或仓库恢复干净的版本 | | 阻止恶意域名 | 如果涉及外部脚本，通过 DNS、代理或防火墙进行阻止 | | 禁用受影响的网站部分 | 如有必要，暂时关闭受损的部分或页面 | | 警报客户/用户 | 如果发生了数据收集，请快速传达泄露风险 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 确定根本原因 | 管理员凭证被盗？不安全的插件？第三方违规？ | | 修补 CMS 或插件 | 应用更新并禁用不必要或不受信任的组件 | | 替换受损组件 | 从具有经过验证的完整性的官方来源重新安装 | | 清理残留访问权限 | 更改管理员凭证，撤销令牌，检查服务器日志以查找持久性技术 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 验证网站完整性 | 重新检查所有文件和脚本的正确性和清洁度 | | 恢复正常运营 | 在确认没有残留恶意代码之后 | | 执行漏洞评估 | 特别是针对暴露的 CMS、JavaScript 包含项和 API | | 监控重复攻击尝试 | 暂时加强网络流量和行为监控 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录事件 | 包括注入向量、影响、攻击者域名和缓解步骤 | | 更新 Web 应用监控规则 | 为 JavaScript 完整性警报添加新的威胁指标 | | 培训 Web 开发人员和管理员 | 关于安全脚本实践、插件安全和变更控制的内容 | | 向监管机构报告 | 如果用户数据或支付信息受到损害 | | 改进 SDLC 安全性 | 在开发工作流中集成代码扫描、依赖项检查和 CI/CD 验证 | ## 通常涉及的工具 Web 监控工具（例如 Detectify、JSWatcher、SilentPush、Snyk、Sucuri） SIEM（例如 Splunk、Sentinel、QRadar） Web 应用防火墙（例如 Cloudflare WAF、AWS WAF、Imperva） CMS 平台和源代码仓库（例如 WordPress、GitHub） 文件完整性监控（例如 OSSEC、Tripwire） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 脚本修改或警报后 <15 分钟 | | 脚本移除时间 | 检测后 <30 分钟 | | 网站恢复时间 | 如果关键路径受到影响，<2 小时 | | 影响通知时间 | 24 小时内（或按监管 SLA） | | 重复攻击监控持续时间 | 至少 7 天的强化监视 | # Playbook 19：不安全的 API 端点利用 ## 场景 攻击者发现并利用缺乏身份验证、速率限制或适当输入验证等不安全的 API 端点，以执行未经授权的数据访问、修改业务逻辑、提升权限或发起拒绝服务 攻击。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 应用层漏洞利用 – API 滥用 | | 严重程度 | 高到严重（取决于数据敏感性和获得的访问级别） | | 优先级 | 高 | | 检测来源 | SIEM、API 网关日志、WAF、运行时应用自我保护 (RASP)、应用程序日志、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 启用 API 网关日志记录 | 跟踪请求方法、源 IP、端点和参数 | | 强制执行输入验证 | 在后端逻辑中实施严格的验证和清理 | | 部署速率限制和节流 | 防止通过批量或自动化请求进行滥用 | | 要求身份验证和授权 | 使用带有角色强制执行的 OAuth、JWT、API 密钥 | | 监控 API 行为 | 使用异常检测来标记意外的访问模式 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 接收警报 | 过多的 API 调用、未经授权的数据访问、错误激增（例如 403、500） | | 识别受影响的端点 | 分析日志以确定访问了哪些 API 以及如何访问的 | | 审查查询模式 | 寻找枚举、注入、批量抓取或业务逻辑滥用的迹象 | | 关联用户/IP | 确定行为人是内部的、已认证的还是在滥用开放 API | | --- | --- | | MITRE ATT&CK
映射 | T1190 (利用面向公众的应用), T1499 (端点 DoS),
T1001.003 (数据混淆), T1539 (窃取 Web 会话 Cookie) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 阻断违规 IP 或令牌 | 在 API 网关、WAF 或 CDN 层面进行阻断 | | 禁用脆弱的端点 | 暂时禁用或限制对受影响 API 的访问 | | 节流可疑流量 | 针对滥用模式实施更严格的速率限制 | | 警报开发和产品团队 | 协助进行遏制和业务风险评估 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 修复不安全的 API 逻辑 | 添加身份验证、访问控制和输入验证 | | 修补或重新部署后端服务 | 如果漏洞源于代码或库 | | 轮换受影响的凭证或 API 密钥 | 特别是如果发生了令牌盗窃或特权滥用 | | 移除注入的数据 | 如果攻击者使用 API 插入了恶意或损坏的数据 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复安全访问 | 在验证修复后，密切监控任何绕过或回归的迹象 | | 通知受影响的用户 | 如果个人或敏感数据被访问或更改 | | 重新测试受影响的 API | 在全面重新激活之前进行回归和安全测试 | | 恢复完整服务 | 一旦在生产环境中验证了安全性和稳定性 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行根本原因分析 | 识别设计、配置或开发中的疏忽 | | 更新 SDLC 策略 | 包括对 API 端点的安全测试（例如 OWASP API Top 10） | | 增强监控和警报 | 为枚举、过度调用或异常输入添加检测 | | --- | --- | | 培训开发人员 | 关于安全的 API 设计、适当的身份验证和错误处理 | | 记录事件 | 包括时间线、攻击者行为、影响和已采取的缓解措施 | ## 通常涉及的工具 API 网关（例如 Kong、AWS API Gateway、Apigee、Azure API Management） WAF（例如 Cloudflare、AWS WAF、Imperva） SIEM（例如 Sentinel、Splunk） RASP 和运行时保护（例如 Signal Sciences、Contrast Security） 应用性能/日志工具（例如 Datadog、New Relic） DAST 工具（例如 Burp Suite、OWASP ZAP） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常活动发生后 <10 分钟 | | 端点限制时间 | 确认后 <30 分钟 | | 补丁/代码修复部署 | 关键 API 漏洞在 24–48 小时内完成 | | 重新测试和恢复时间 | 72 小时内 | | 开发人员培训覆盖率 | 100% 的后端/API 团队在 7 天内得到简报 | # Playbook 20：内部凭证盗窃与滥用 ## 场景 内部人员（或使用被盗内部凭证的外部攻击者）使用有效账户访问敏感系统、提取数据或执行未经授权的活动——通常由于使用合法凭证而能绕过传统的安全检测。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 内部威胁 – 凭证滥用 | | 严重程度 | 高到严重（特别是如果涉及特权账户或敏感数据） | | 优先级 | 严重 | | 检测来源 | SIEM、UEBA（用户和实体行为分析）、IAM、EDR、DLP、HR 提示或举报人报告 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/ | | --- | --- | | 实施 UEBA 解决方案 | 检测异常的用户活动（例如 Exabeam、Microsoft Defender、Securonix） | | 为特权账户启用日志记录 | 包括会话监控和命令跟踪 | | 强制执行最小特权和 RBAC | 确保用户只拥有他们真正需要的访问权限 | | 监控敏感数据访问 | 针对文件下载、云存储、电子邮件转发的 DLP 策略 | | 设置针对异常访问模式的警报 | 一天中的时间、活动量、访问的系统、位置 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 UEBA 或 SIEM 的警报 | 异常的数据访问、登录行为或文件移动 | | 与工作角色关联 | 确定行为是否符合用户的正常职责 | | 检查访问日志 | 识别访问的系统、文件和数据 | | 审查近期的 HR 标记 | 检查用户是否正在接受调查、已辞职或显示出行为风险指标 | | --- | --- | | MITRE ATT&CK
映射 | T1078 (有效账户), T1087 (账户发现), T1110.003 (密码喷洒), T1213.003 (访问敏感数据 - 数据库) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 暂停用户账户 | 在调查期间暂时禁用访问权限 | | 撤销会话令牌 | 使活动会话、VPN 或 API 令牌失效 | | 隔离端点 | 如果怀疑有文件传输、恶意软件安装或持久化行为 | | 限制进一步访问 | 实施即时访问或隔离用户的 VLAN/子网 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 调查完整的活动范围 | 审查发送的电子邮件、访问/传输的文件、登录的系统 | | 撤销提升的访问权限或凭证 | 移除对所有特权系统或服务的访问权限 | | 重置凭证和密钥 | 针对共享凭证或用户访问过的系统 | | 清理任何更改 | 回滚用户所做的任何脚本、配置或数据更改 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复合法用户的访问权限 | 如果为了调查而暂停或禁用了其他账户 | | 监控受波及的系统 | 在规定期内使用 SIEM 和 EDR 监控事件发生后的行为 | | 通知利益相关者 | 包括 HR、法律和合规部门，以协调和结束调查 | | 恢复正常运营 | 一旦验证内部活动不存在残留风险 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行事件后审查 | 确定滥用是如何发生的，以及为什么没能更早地检测到它 | | 更新检测规则 | 为类似角色或行为添加特定的滥用指标 | | --- | --- | | 审查访问策略 | 收紧或调整 RBAC/最小特权设置和 IAM 流程 | | 加强用户监控策略 | 按工作角色或部门定期审查敏感访问权限 | | 如需要则进行报告 | 报告给内部治理机构、监管机构（例如 PDPA、HIPAA）或受影响的客户 | ## 通常涉及的工具 SIEM（例如 Splunk、Sentinel、QRadar） UEBA（例如 Exabeam、Microsoft Defender for Identity、Securonix） EDR（例如 CrowdStrike、Cortex XDR） IAM/SSO 日志（例如 Okta、Azure AD、Ping） DLP 工具（例如 Forcepoint、Symantec、Microsoft Purview） 端点和服务器日志 HRIS 集成（用于实时 HR 状态反馈） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常活动发生后 <15 分钟 | | 账户暂停时间 | 警报确认后 <30 分钟 | | 根本原因分析完成时间 | 48 小时内 | | 访问审查完成情况 | 受影响用户的 100% 特权访问日志已审查 | | 策略审查或调整 | 事件关闭后 7 天内 | # Playbook 21：云身份配置错误 ## 场景 配置不当的云身份或访问控制（例如，过于宽松的 IAM 角色、通配符访问策略、意外的信任关系）被内部或外部行为人利用，以获取提升的访问权限、进行横向移动或访问受限资源。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 配置错误 – IAM / 访问策略 | | 严重程度 | 高到严重（特别是如果暴露了特权访问或敏感数据） | | 优先级 | 严重 | | 检测来源 | CSPM 工具、云审计日志、SIEM、IAM 策略扫描、威胁情报、红队发现 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 使用最小特权模型 | 强制执行细粒度的 IAM 角色和基于策略的访问控制 | | 部署 CSPM 工具 | 监控身份配置错误（例如 Wiz、Prisma Cloud、Microsoft Defender for Cloud） | | 启用详细日志记录 | 使用 AWS CloudTrail、Azure Activity Logs、GCP Audit Logs 跟踪 IAM 事件 | | 标记和分类身份 | 区分人类与服务身份，并应用基于风险的监控 | | 进行访问审查 | 定期审计 IAM 角色、信任策略和访问密钥 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | CSPM 或 SIEM 针对过度权限、通配符访问 ("*") 或对 "Everyone" 的信任发出的警报 | | 验证配置错误 | 审查 IAM 策略、角色扮演、组成员资格以及任何异常的继承 | | 审查访问日志 | 确定配置错误是否已被利用（API 调用、资源访问） | | 评估受影响的资产 | 识别使用配置错误的身份可以访问哪些服务或数据 | | --- | --- | | MITRE ATT&CK
映射 | T1078.004 (云账户), T1098.001 (额外的云凭证), T1550.001 (应用程序访问令牌滥用) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 限制或删除配置错误的角色/策略 | 立即移除或纠正有风险的配置 | | 撤销临时凭证 | 使通过配置错误的身份颁发的 STS 令牌、API 密钥、访问令牌失效 | | 隔离受影响的资源 | 如果确认有可疑活动，隔离受损的服务或数据存储桶 | | 通知云管理团队 | 协调跨云账户或区域的 IAM 更改和服务验证 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 修复 IAM 策略 | 应用具有范围权限、条件和角色边界的修正策略 | | 轮换受影响的凭证 | 特别是针对用户、服务账户或云原生机密 | | 验证信任关系 | 重新配置角色扮演并移除非预期的跨账户信任 | | 移除未使用的角色/组 | 停用没有操作需求的身份 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复适当的访问权限 | 使用最小特权原则重新分配必要的权限 | | 监控重新配置 | 为更新的身份设置临时警报，用于修复后的行为验证 | | 重新启用服务 | 在确认配置安全且审计日志显示没有进一步滥用之后 | | 沟通状态 | 向安全、DevOps 和云平台所有者提供最新信息 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行影响分析 | 确认是否发生了数据访问或特权滥用及其持续时间 | | --- | --- | | 改进 IAM 策略 | 应用服务控制策略、权限边界和条件逻辑 | | 更新监控规则 | 为通配符特权、新身份创建和跨账户角色使用添加检测 | | 记录事件 | 包括受影响的 IAM 资源、根本原因、受影响的资产和解决步骤 | | 如需要则进行报告 | 如果访问了敏感数据，向内部利益相关者或监管机构报告 | ## 通常涉及的工具 CSPM 工具（例如 Wiz、Prisma Cloud、Microsoft Defender for Cloud、AWS Config） SIEM（例如 Splunk、Sentinel、QRadar） 云审计日志（例如 AWS CloudTrail、Azure Activity Logs、GCP Audit Logs） IAM 策略扫描器（例如 PMapper、CloudSploit、IAM Access Analyzer） 用于自动化修复的 SOAR 身份治理平台（例如 Saviynt、SailPoint、Okta） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 风险 IAM 更改后 <10 分钟 | | 遏制时间 | 警报确认后 <30 分钟 | | 策略修复完成时间 | 关键配置错误 <4 小时 | | 凭证轮换时间 | 受影响的身份 <2 小时 | | 访问审查覆盖率 | 事件后 100% 的受影响身份已审计 | # Playbook 22：CI/CD Pipeline 漏洞利用 ## 场景 攻击者访问或利用 CI/CD pipeline（例如 Jenkins、GitLab CI、GitHub Actions）中的弱点，以操纵构建过程、注入恶意代码或机密，或利用 pipeline 横向渗透到更广泛的基础设施中。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 软件供应链 / Pipeline 失陷 | | 严重程度 | 高到严重（特别是如果确认了部署篡改或代码库访问） | | 优先级 | 严重 | | 检测来源 | SIEM、源代码控制日志、CI/CD 日志、EDR、SAST/DAST 工具、开发人员报告、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 在 CI/CD 工具上强制执行 RBAC | 限制谁可以创建或修改 pipeline、runner 或机密 | | 启用详细的审计日志记录 | 针对代码推送、pipeline 更改、作业执行和机密使用 | | 使用签名的提交和工件 | 验证源代码和部署包的真实性 | | 监控 pipeline 滥用模式 | 例如，意外的作业触发、通过 runner 提权 | | 隔离构建环境 | 使用临时的容器/VM 以限制横向移动和访问范围 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 SIEM 或 DevSecOps 工具的警报 | 异常的作业行为、凭证使用或构建脚本更改 | | 审查最近的 pipeline 更改 | 检查作业定义、runner 配置和注入的命令 | | 分析源代码仓库活动 | 寻找恶意提交、PR 或分支操纵 | | 识别受影响的项目 | 确定哪些构建/部署可能已受到破坏 | | --- | --- | | MITRE ATT&CK
映射 | T1556 (修改身份验证过程), T1587.002 (恶意代码签名), T1059.006 (CI/CD 作业命令执行), T1136.003 (用于持久化的云账户创建) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 禁用受影响的 pipeline 或 runner | 停止受损作业的进一步执行 | | 撤销对 CI/CD 工具的访问权限 | 针对受损的账户或令牌 | | 阻止恶意工件 | 阻止部署受损的容器、二进制文件或包 | | 隔离受影响的环境 | 暂时将受影响的应用或服务从部署路径中移除 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 清除恶意代码或脚本 | 还原到干净的仓库状态；删除被篡改的构建定义 | | 轮换受损的机密 | 重新颁发 CI/CD 日志中暴露的 API 密钥、云令牌、数据库凭证 | | 修补漏洞 | 解决 runner、插件或访问控制中的配置错误 | | 审计第三方集成 | 移除或审查授予外部 CI/CD 插件或服务的访问权限 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复可信的 pipeline | 在验证脚本、依赖项和配置之后 | | 重建受影响的应用程序 | 使用已知良好的代码和安全的 CI/CD 流程 | | 重新启用部署 | 一旦验证安全并通过完整的验证 | | 利益相关者 | 向开发人员、产品所有者和安全团队通报恢复状态 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 执行根本原因分析 | 确定入口点是仓库访问、runner 滥用还是插件受损 | | --- | --- | | 更新 pipeline 安全控制 | 强制执行代码审查、作业批准和安全的机密管理 | | 培训 DevOps 和开发人员 | 关于安全的 CI/CD 实践和事件指标 | | 如必要则进行报告 | 如果数据被暴露或软件附带恶意代码（例如向客户、监管机构报告） | | 更新 playbook | 纳入经验教训和针对 CI/CD 监控的控制增强 | ## 通常涉及的工具 CI/CD 平台（例如 Jenkins、GitHub Actions、GitLab CI、Azure DevOps） SIEM（例如 Splunk、Sentinel） EDR 和运行时保护（例如 CrowdStrike、Aqua Security） 代码和 pipeline 扫描器（例如 SonarQube、Checkov、TFSec） 源代码管理系统（例如 GitHub、GitLab、Bitbucket） SOAR 平台（用于 pipeline 滥用的自动修复） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常 CI/CD 活动发生后 <10 分钟 | | 作业禁用时间 | 确认后 <30 分钟 | | 机密轮换时间 | 暴露检测后 <2 小时 | | 重建和重新部署时间 | 使用验证过的代码在 24–48 小时内完成 | | CI/CD 访问审查完成情况 | 3 天内 100% 的用户和集成访问已审计 | # Playbook 23：在生产环境中未经授权使用生成式 AI 工具 ## 场景 员工或系统在生产环境中使用生成式 AI 工具——无论是通过将敏感代码、数据或配置粘贴到 AI 提示中，还是通过将 AI 助手集成到实时应用程序中——而没有经过正式批准或适当的安全评估。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 策略违规 / 数据泄露风险 | | 严重程度 | 中到严重（取决于数据敏感性或自动化影响） | | 优先级 | 高 | | 检测来源 | DLP、CASB、SIEM、代理日志、端点遥测、IT 治理警报、安全意识报告 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 实施可接受的使用策略 | 明确界定各环境中 AI 使用的边界 | | 监控 AI 平台访问 | 记录并对与生成式 AI URL（例如 openai.com、bard.google.com）的交互进行警报 | | 使用 DLP 和 CASB 工具 | 监控输入到 AI 工具或外部 API 中的敏感数据 | | 强制执行浏览器控制和阻止 | 限制来自高敏感度区域（例如财务、开发、生产）的 AI 工具使用 | | 开展用户培训 | 关于生成式 AI 风险和组织合规要求的内容 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 检测未经授权的使用 | DLP、CASB 或代理日志警报显示数据被粘贴到 AI 工具或 prod 中使用了插件 | | 识别用户或系统 | 将日志与源 IP、用户 ID、浏览器代理或应用程序日志相关联 | | 审查传输的数据 | 确定是否包含代码、凭证、PII 或知识产权 | | 评估使用背景 | 意外误用 vs 有意的自动化或影子 AI 集成 | | --- | --- | | MITRE ATT&CK
映射 | T1087.003 (云服务枚举), T1567.002 (渗出到云存储), T1203 (通过 AI 插件/扩展利用面向公众的应用) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 阻止进一步访问 | 通过防火墙、代理或 CASB 策略禁用用户对 AI 工具或集成的访问权限 | | 隔离受影响的系统 | 如果 AI 集成处于活动代码或服务中 | | 警报用户和管理层 | 通知利益相关者并在调查期间冻结进一步使用 | | 捕获取证快照 | 尽可能获取提示历史记录、浏览器活动和传输数据的快照 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 移除 AI 集成 | 从生产服务、脚本或 pipeline 中移除（如果已嵌入） | | 撤销使用的任何 API 令牌 | 针对未经授权的 AI 集成（例如 OpenAI API 密钥） | | 轮换暴露的机密 | 如果凭证被粘贴或被 AI 存储 | | 清理策略违规 | 更新配置以移除与 AI 相关的例外或允许列表（如果被滥用） | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 在策略下恢复访问 | 仅在用户确认可接受的使用条款或 AI 插件经过审计和批准之后 | | 验证代码库和生产更改 | 确保没有残留未经授权的自动化 | | 实施 AI 治理检查 | 为 AI 相关工具的使用和集成引入审查工作流 | | 恢复运营 | 一旦安全和合规团队确认风险已缓解 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行根本原因分析 | 为何以及如何访问或集成了该 AI 工具 | | --- | --- | | 更新监控控制 | 为新的 AI 平台或浏览器扩展添加检测 | | 改进内部教育 | 将特定于 AI 的场景添加到网络安全意识计划中 | | 如需要则进行报告 | 如果暴露了知识产权或受监管数据（例如符合 GDPR、HIPAA、PDPA 的合规要求） | | 记录事件 | 包括涉及的用户、访问的数据、修复时间线和预防步骤 | ## 通常涉及的工具 DLP（例如 Microsoft Purview、Symantec、Forcepoint） CASB（例如 Netskope、Microsoft Defender for Cloud Apps） SIEM（例如 Splunk、Sentinel、QRadar） 端点检测与响应 (EDR)（例如 CrowdStrike、Cortex XDR） 代理/防火墙日志（例如 Zscaler、Palo Alto、Fortinet） 浏览器控制工具（例如 Chrome 企业版策略、Edge 管理） 生成式 AI 访问日志（如果与企业身份系统集成） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 数据传输或插件使用后 <10 分钟 | | 遏制时间 | 访问撤销 <30 分钟 | | 风险评估完成时间 | 事件发生后 <24 小时 | | 策略重新确认率 | 3 天内 100% 的相关用户已确认 | | 合规审查时间范围 | 事件解决后 7 天内 | # Playbook 24：OAuth 令牌重放滥用 ## 场景 攻击者获取有效的 OAuth 访问令牌（例如通过网络钓鱼、令牌盗窃或不安全的存储）并重新使用它以受害者身份访问 API、Web 应用程序或云服务——由于令牌已受信任，因此能绕过 MFA 和其他登录保护。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 身份失陷 – 令牌滥用 | | 严重程度 | 高到严重（取决于令牌的范围和权限） | | 优先级 | 严重 | | 检测来源 | SIEM、云审计日志、API 网关日志、身份提供者日志（例如 Okta、Azure AD）、CASB、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制令牌过期和轮换 | 设置较短的令牌生命周期并强制执行刷新令牌限制 | | 监控令牌使用模式 | 使用身份保护或 SIEM 对使用令牌的异常 API 访问发出警报 | | 将令牌绑定到设备/会话 | 尽可能将颁发的令牌绑定到 IP/设备指纹 | | 实施条件访问 | 在允许基于令牌的访问之前检查上下文（例如位置、应用、风险评分） | | 记录所有令牌颁发和使用情况 | 来自身份提供者和应用程序网关的记录 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 异常的令牌使用，例如从新位置重放或不可能的旅行行为 | | 调查令牌使用模式 | 检查访问的端点、使用时间、关联的 IP 和 user-agent 元数据 | | 与令牌颁发相关联 | 确定令牌最初是何时何地创建的，以及它是否与合法用户相符 | | 评估暴露风险 | 确定是否发生了数据访问、特权提升或账户操作 | | --- | --- | | MITRE ATT&CK
映射 | T1528 (窃取应用程序访问令牌), T1078.004 (云账户 – OAuth 滥用), T1550.003 (令牌模拟) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销活动令牌 | 通过 IdP 或应用程序设置使访问令牌和刷新令牌失效 | | 阻断源 IP | 如果重放源自已知恶意基础设施或异常区域 | | 暂停受影响的用户账户 | 暂时禁用以防止在调查期间继续被利用 | | 警报用户和安全团队 | 通知潜在的危害并在需要时暂停外部访问 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 轮换凭证和机密 | 特别是针对绑定到同一账户的第三方应用程序或 API | | 审计并移除恶意的应用同意 | 检查用户授权的、可能由攻击者控制的 OAuth 应用程序 | | 收紧应用权限范围 | 限制应用程序仅请求最低限度的必要访问权限（最小特权原则） | | 对应用程序应用安全控制 | 要求对未来的应用程序进行应用程序验证或租户级别的同意批准 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复用户账户 | 在确认用户身份和账户完整性之后 | | 监控恢复后的令牌活动 | 确保新令牌仅从受信任的位置和设备使用 | | 重新验证应用和 API 访问权限 | 确认跨关键服务的合法会话行为 | | 恢复运营 | 在确认完全遏制和凭证卫生之后 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行根本原因分析 | 确定令牌是如何获得的（例如网络钓鱼、本地存储暴露、浏览器扩展） | | --- | --- | | 更新令牌颁发策略 | 缩短令牌生命周期，强制实施刷新限制并绑定到上下文 | | 改进检测 | 向 SIEM 和身份保护平台添加令牌重放模式签名 | | 教育用户和开发团队 | 关于 OAuth 令牌的安全存储和处理（特别是在基于浏览器的应用中） | | 如需要则进行报告 | 特别是如果访问了敏感数据（例如根据 GDPR、HIPAA 或 PDPA） | ## 通常涉及的工具 身份提供者（例如 Okta、Azure AD、Google Workspace） SIEM（例如 Sentinel、Splunk、QRadar） CASB（例如 Netskope、Microsoft Defender for Cloud Apps） API 安全工具（例如 Salt Security、Noname、Imperva API Security） 云审计日志（例如 AWS CloudTrail、Azure Sign-in logs、GCP Admin Activity） 用户行为分析（例如 Exabeam、Securonix） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常令牌使用后 <10 分钟 | | 令牌撤销时间 | 确认后 <15 分钟 | | 账户风险缓解时间 | <1 小时 | | OAuth 应用审计完成情况 | 24 小时内审查 100% 的同意 | | 事件后监控期 | 最少 7 天的增强可见性 | # Playbook 25：配置不当的公共云存储访问 ## 场景 云存储桶、容器或对象被意外地公开或暴露给未经授权的用户（例如通过 public-read 或 authenticated users 访问设置）。这可能导致数据泄露、监管不合规或被威胁行为人利用。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 云配置错误 – 公开暴露 | | 严重程度 | 高到严重（取决于暴露数据的敏感性） | | 优先级 | 严重 | |检测来源 | CSPM 工具、云审计日志、SIEM、威胁情报、手动发现、Bug Bounty 报告 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 部署 CSPM 工具 | 持续扫描配置错误的存储（例如 Wiz、Prisma Cloud、orca Security） | | 实施策略即代码 | 使用 AWS Config、Azure Policies 或 GCP Org Policies 等工具来限制公共存储 | | 监控访问日志 | 启用存储桶访问和对象级别事件的日志记录 | | 启用默认加密 | 使用 KMS 密钥自动加密所有对象 | | 分类和标记敏感数据 | 应用元数据以便于执行 DLP 和访问控制 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 CSPM 或云平台的警报 | 检测到对存储的 public-read、public-write 或通配符访问 | | 验证访问级别 | 确认对象、存储桶或容器是否可被任何人或广泛的 IAM 组读取 | | 检查访问日志 | 识别访问暴露资源的 IP、用户或服务 | | 确定数据敏感性 | 数据是 PII、财务数据、源代码还是内部文档？ | | --- | --- | | MITRE ATT&CK
映射 | T1530 (来自云存储对象的数据), T1526 (云服务发现), T1213.003 (访问敏感数据) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 移除公共访问权限 | 立即撤销对存储资源的 public 或 everyone 权限 | | 应用最小特权策略 | 将访问权限锁定为仅限必需的 IAM 身份或角色 | | 撤销临时令牌（如被滥用） | 禁用用于利用该暴露的访问密钥或令牌 | | 隔离暴露的数据（可选） | 将敏感文件移动到受限存储桶以进行分析或修复 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 纠正 IAM 或 ACL 策略 | 使用策略模板或自动化来强制执行安全的访问控制 | | 轮换密钥或令牌 | 如果暴露了访问密钥、SAS 令牌或签名 URL | | 移除未经授权的文件 | 删除上传的恶意软件、后门或被篡改的内容（如适用） | | 禁用存储桶列表 | 防止攻击者将来枚举内容 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复安全访问 | 仅在验证适当的权限已到位之后 | | 通知受影响的团队 | 特别是数据所有者、应用团队，如果涉及敏感数据，需通知合规和法律部门 | | 恢复使用 | 在确认没有剩余的暴露或配置错误之后 | | 启用更强的日志记录 | 如果尚未启用，请确保 CloudTrail/S3/Azure Blob/GCP 审计日志处于活动状态 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行全面的暴露分析 | 确定暴露内容的持续时间、访问范围和数据分类 | | 更新访问控制模板 | 对新的存储资源强制执行默认拒绝的姿态 | | --- | --- | | 培训团队关于云访问策略的知识 | 教授安全存储部署和数据处理最佳实践 | | 如必要则进行报告 | 如果数据泄露涉及个人或受监管数据，需根据 PDPA、GDPR、HIPAA 等进行报告 | | 将检测集成到 CI/CD 中 | 在投入生产之前使用 IaC 扫描（例如 Checkov、tfsec）捕获公共访问设置 | ## 通常涉及的工具 CSPM（例如 Wiz、Prisma Cloud、orca） 云原生工具（例如 AWS S3 Access Analyzer、Azure Defender、GCP Security Command Center） SIEM（例如 Sentinel、Splunk） DLP 工具（例如 Microsoft Purview、Google DLP） IAM 策略分析器（例如 PMapper、CloudSploit） 用于泄露存储桶/域名的威胁情报源 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 配置错误后 <5 分钟 | | 公共访问移除时间 | 警报后 <15 分钟 | | 暴露影响报告 | 24 小时内 | | IAM 策略审计完成情况 | 48 小时内 100% 的受影响项目或存储桶 | | 合规审查完成情况 | 72 小时内（或按监管规定的截止日期） | # Playbook 26：跨云工作负载的横向移动 ## 场景 攻击者在某个云工作负载（例如 EC2、Azure VM、Kubernetes pod 或容器）中获得立足点，并通过利用过度宽松的角色、不安全的凭证、共享存储或配置错误的网络规则进行横向移动，以触及其他工作负载或服务。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 云入侵 – 横向移动 | | 严重程度 | 高到严重（取决于访问的系统和暴露的数据） | | 优先级 | 严重 | | 检测来源 | SIEM、CSPM、云工作负载上的 EDR、云审计日志、NDR、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制执行网络分段 | 使用安全组、NSG 或 VPC 防火墙来限制东西向流量 | | 启用工作负载日志记录 | 激活 OS 日志、CloudTrail、Azure Activity Logs、GCP Audit Logs 和流日志 | | 为云端部署 EDR | 安装端点保护或运行时安全工具（例如 Falcon、XDR、Wiz Runtime） | | 限制 IAM 角色重用 | 确保跨工作负载最小化地共享角色/权限 | | 强化镜像和基础设施 | 使用安全的镜像并强制执行 IaC 最佳实践 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 可疑的实例间通信、凭证使用或横向命令执行 | | 识别入口点 | 定位最初受损的工作负载或凭证来源 | | 追踪横向路径 | 审查云流日志、审计追踪和 EDR 日志以查找 SSH、API 调用、远程访问迹象 | | 分析使用的工具 | 移动是通过脚本、被盗令牌、RDP/SSH 还是云原生 API 完成的？ | | --- | --- | | MITRE ATT&CK
映射 | T1021 (远程服务), T1570 (横向工具传输), T1086.001
(云主机上的 PowerShell), T1534 (内部鱼叉式网络钓鱼或角色模拟) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 隔离受影响的工作负载 | 将受损的实例/pod 从网络中移除或缩减受影响的服务 | | 禁用涉及的凭证或角色 | 立即撤销用于横向移动的令牌、密钥或 IAM 角色 | | 暂时阻断东西向流量 | 应用严格的 ACL 以防止在分析范围期间进一步移动 | | 警报平台和应用程序所有者 | 将受影响的环境通知相关团队 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 终止受损的实例或容器 | 使用可信镜像和经过验证的 IaC 模板进行重建 | | 轮换受影响的凭证 | 重新颁发涉及的云访问密钥、服务主体和用户密码 | | 移除后门或持久性机制 | 检查 cron 作业、启动脚本、IAM 角色或已安装的恶意软件 | | 修复网络/安全组规则 | 通过强制实施最小访问模型来防止再次发生 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 重新部署干净的工作负载 | 从经过验证的 pipeline 或强化的基础镜像中进行 | | 恢复网络信任区域 | 在严格控制下逐渐重新启用东西向通信 | | 重新启用受影响的服务 | 仅在彻底验证并落实日志记录之后 | | 加强对恢复资产的监控 | 使用 SIEM 和运行时工具验证干净的运行状态 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录横向移动路径 | 包括访问的系统、使用的工具、时间线和暴露的数据 | | --- | --- | | 更新检测逻辑 | 为横向移动添加威胁指标和新的行为规则 | | 强化 IAM 和网络设计 | 应用更严格的分段、SSO 约束和令牌绑定技术 | | 进行内部总结 | 与安全、云运营、DevOps 和合规团队一起审查 | | 如必要则进行报告 | 向监管机构或客户报告，特别是如果敏感数据或生产系统受到破坏 | ## 通常涉及的工具 SIEM（例如 Sentinel、Splunk、QRadar） CSPM（例如 Wiz、Prisma Cloud、Defender for Cloud） 云 EDR（例如 CrowdStrike、Cortex XDR、用于容器的 Falco） 云审计日志 (AWS CloudTrail、Azure Activity Logs、GCP Audit Logs) 网络可见性（例如 VPC Flow Logs、Azure NSG flow logs） 用于响应编排的 SOAR 工具 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 横向移动开始后 <15 分钟 | | 隔离时间 | 检测后 <30 分钟 | | 凭证轮换时间 | 确认后 <2 小时 | | 受影响资产恢复时间 | 48 小时内 | | 事后报告完成时间 | 3 个工作日内 | # Playbook 27：未经授权的云数据库快照导出 ## 场景 云数据库快照（例如 AWS RDS 快照、Azure SQL 数据库导出、GCP Cloud SQL 备份）在未经批准的情况下被创建或共享。如果快照暴露给未经授权的用户或公开共享，这可能会导致敏感数据渗出。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 数据泄露 – 快照滥用 | | 严重程度 | 高到严重（特别是如果涉及 PII、财务数据或机密） | | 优先级 | 严重 | | 检测来源 | 云审计日志、CSPM 警报、SIEM、存储日志、数据库活动监控工具 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制快照加密 | 使用客户管理的 KMS 密钥并强制对所有快照进行加密 | | 限制快照共享 | 应用组织级策略以禁止公共或跨账户的快照共享 | | 监控快照创建 | 使用 CSPM 或 SIEM 对快照导出、共享和下载发出警报 | | 标记敏感数据库 | 对资源进行分类，以便进行有针对性的监控和 DLP 实施 | | 启用云审计日志记录 | 确保所有与快照相关的操作（创建、共享、恢复）都被记录 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 快照被共享到组织外部或在异常时间/由异常用户创建 | | 调查快照类型和目标 | 确定哪个数据库被快照，以及该快照是公开共享还是共享给了未知账户 | | 审查访问日志 | 检查快照是否已被下载、恢复或访问过 | | 与用户身份关联 | 调查执行该操作的 IAM 身份或服务账户 | | MITRE ATT&CK
映射 | T1530 (来自云存储的数据), T1005 (来自本地系统的数据), T1078.004 (云账户), T1048 (通过替代协议渗出) | | --- | --- | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销对共享快照的访问权限 | 通过控制台或 CLI 移除共享或将其设为私有 | | 暂停违规账户 | 暂时禁用负责的用户或服务账户 | | 禁用下载访问权限 | 如果快照被复制到外部的 S3 存储桶、GCS 或 Azure blob，请撤销访问权限 | | 警报合规和法律团队 | 特别是如果涉及受监管保护的数据 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 删除未经授权的快照 | 移除恶意或未经批准的副本 | | 轮换受影响的凭证 | 如果机密是数据库内容的一部分，或者服务账户被滥用 | | 审计 IAM 权限 | 确保快照创建共享被严格限制在受信任的角色上 | | 审查跨账户信任设置 | 移除任何允许在组织外部共享的风险或未受监控的权限 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复可信的备份过程 | 恢复经过验证、加密和访问控制的备份 | | 重新验证数据库和快照的完整性 | 确保没有通过恢复过程引入篡改或后门 | | 恢复数据库操作 | 一旦环境和备份安全并经过验证 | | 加强对关键数据库的日志记录 | 在规定的观察期内实施加强的监控 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录事件范围 | 时间线、暴露的数据类型、涉及的账户和解决步骤 | | --- | --- | | 更新检测规则 | 为跨边界共享或复制快照添加警报 | | 培训 DBA 和开发人员 | 关于安全的快照程序和 IAM 治理的内容 | | 向当局报告 | 如果泄露涉及个人、财务或政府监管的数据 | | 改进云护栏 | 使用基础设施即代码扫描和策略即代码进行未来的预防 | ## 通常涉及的工具 云原生日志（例如 AWS CloudTrail、Azure Activity Logs、GCP Admin Audit Logs） CSPM（例如 Wiz、Prisma Cloud、Microsoft Defender for Cloud） SIEM（例如 Sentinel、Splunk） DLP 工具（例如 Microsoft Purview、Forcepoint DLP） 用于自动化响应的 SOAR 平台 数据库活动监控（例如 Imperva、Guardicore、原生平台日志记录） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 快照创建或共享后 <10 分钟 | | 公共访问移除时间 | 确认后 <30 分钟 | | 快照删除时间 | 未经授权的快照 <1 小时 | | IAM 策略审计完成情况 | 48 小时内 100% 的受影响环境 | | 合规通知截止日期 | 72 小时内或按监管要求 | # Playbook 28：容器逃逸企图 ## 场景 攻击者获得对容器的访问权限，并试图脱离隔离环境以与宿主操作系统交互、提升权限或破坏其他容器、pod 或底层基础设施。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 容器运行时安全 – 逃逸企图 | | 严重程度 | 严重（特别是如果获得了宿主访问权限或特权提升） | | 优先级 | 严重 | | 检测来源 | 运行时安全工具、SIEM、EDR、Kubernetes 审计日志、Falco 规则、容器日志 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 实施运行时安全 | 使用 Falco、Aqua、Sysdig 或 Wiz Runtime 等工具进行实时检测 | | 启用 Kubernetes 和 Docker 审计日志记录 | 捕获容器活动和宿主级别的访问企图 | | 强化容器镜像 | 使用最小化的基础镜像，扫描漏洞并移除不必要的工具（例如 curl、bash） | | 应用 Pod 安全策略 / OPA | 防止特权提升、宿主挂载和容器特权模式 | | 监控容器间流量 | 使用 NDR 或基于 eBPF 的工具启用东西向容器流量监控 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 尝试访问宿主文件系统（/proc、/root）、提升权限或生成意外的二进制文件 | | 审查容器活动 | 检查 nsenter、chroot、mount、apt、wget 或可疑的 execs | | 识别受影响的容器和节点 | 确定 pod 名称、命名空间和底层宿主 VM/节点 | | 分析攻击者行为 | 这是配置错误利用（例如 privileged: true）还是远程代码执行？ | | --- | --- | | MITRE ATT&CK
映射 | T1611 (逃逸到宿主), T1059 (命令和脚本解释器), T1203 (利用漏洞进行特权提升) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 停止受损的 pod 或容器 | 立即强制删除或隔离该实例 | | 隔离受影响的节点 | 将该节点从集群调度中移除并限制其通信 | | 暂停服务账户访问 | 特别是如果容器有权访问 Kubernetes API 或机密 | | 对受影响的容器进行快照 | 如果需要进行取证，请尽可能保留内存和日志 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 调查根本原因 | 脆弱的镜像、过度宽松的配置还是暴露的接口 | | 修补脆弱的工作负载 | 使用修复后的配置或镜像重建并重新部署受影响的 pod | | 轮换机密和凭证 | 特别是如果存储在环境变量、configMaps 或卷中 | | 移除后门或恶意工具 | 在容器或宿主中搜索流氓二进制文件、cron 作业或注入的脚本 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 从可信镜像重建工作负载 | 使用带有镜像签名和扫描的 CI/CD 流水线 | | 清理后恢复节点 | 仅在主机系统完成全面的取证验证之后 | | 恢复服务 | 逐步重新引入 pod 并密切监控是否复发 | | 增强对受影响
命名空间或部署的监控 | 对未来的偏差应用异常检测 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行事后
分析 | 记录逃逸向量、时间线和暴露的
资产 | | 改进容器安全
策略 | 执行严格的资源隔离并防止复用
受影响的模式 | | 培训 DevOps 团队 | 关于安全容器配置、最小权限和运行时风险 | | 按要求进行报告 | 如果发生数据暴露或主机受损，请通知
监管机构或客户 | | 更新操作手册和
响应工作流 | 基于此攻击场景添加新规则和控制措施 | ## 通常涉及的工具 运行时安全（例如 Falco, Sysdig Secure, Aqua, Prisma Cloud Compute, Wiz） Kubernetes 审计日志和 RBAC 日志 SIEM（例如 Sentinel, Splunk, QRadar） EDR（用于主机节点，例如 CrowdStrike, Cortex XDR） NDR（用于容器流量可见性） 镜像扫描（例如 Trivy, Clair, Anchore） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离逃逸尝试 <5 分钟 | | Pod 终止时间 | 距离告警 <10 分钟 | | 根因修复时间 | <48 小时 | | 节点重新验证
完成 | 移除后 24 小时内 | | 镜像加固审查 | 3 个工作日内审计 100% 的类似部署 | # 剧本 29：影子 IT SaaS 使用与数据暴露 ## 场景 员工或团队使用未经批准的 SaaS 应用程序（例如个人 Google Drive, Dropbox, Notion, ChatGPT）用于工作目的，在没有安全监督的情况下传输企业数据。这可能导致未经授权的数据暴露、违规行为或内部滥用。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 策略违规 – 未经授权的 SaaS 使用 | | 严重程度 | 中到高（取决于所涉及数据的类型和敏感性） | | 优先级 | 高 | | 检测
来源 | CASB, DLP, 代理日志, SIEM, 终端代理, 影子 IT 发现
工具, 员工报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 实施 CASB 平台 | 发现并监控超出
批准范围的所有 SaaS 使用情况 | | 设定 SaaS 使用策略 | 明确定义已批准与未批准的
服务 | | 在终端和云端应用 DLP | 检测敏感文件上传或剪贴板
传输 | | 整合代理/防火墙日志 | 按域名/IP 和用户跟踪 SaaS 使用情况 | | 培训用户有关数据处理和
影子 IT 风险的知识 | 提升对合规性和
已批准工具的认知 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | CASB 或代理检测到未经批准的 SaaS 使用，或 DLP 标记了
敏感文件传输 | | 识别用户和
设备 | 匹配用于传输的 IP、用户 ID 和计算机 | | 分析共享数据 | 确定文档是否包含 PII、PHI、客户信息或内部 IP | | 调查 SaaS
应用风险状况 | 评估该应用是否存在不良安全实践或违反
服务条款的行为 | | --- | --- | | MITRE ATT&CK
映射 | T1087.003 (Cloud Service Enumeration), T1537 (Transfer Data to
Cloud Account), T1213 (Data from Information Repositories) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 阻止访问 SaaS 应用 | 使用 CASB、防火墙或代理规则防止进一步
使用 | | 暂停用户的互联网或云
访问 | 如果数据暴露严重或怀疑继续
使用，则暂时停止 | | 通知用户和经理 | 如有必要，进行初步调查面谈 | | 阻止共享数据的
下载/导出 | 删除权限或尽可能从第三方
应用中删除 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 从未经批准的平台删除公司数据 | 在可行的情况下，联系供应商或要求用户
删除 | | 撤销 SaaS OAuth 权限 | 从与未经批准服务集成的用户或企业帐户中
撤销 | | 收紧应用控制 | 配置 CASB 自动阻止高风险类别中新发现的
未批准应用 | | 移除外部各方对共享数据的
访问权限 | 如果数据是通过链接或协作功能共享的 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在监控下恢复
用户访问 | 在风险得到补救并确认策略后 | | 监控未来的 SaaS 使用情况 | 对重复违规应用更严格的控制和告警 | | 验证不存在更多数据
副本 | 搜索终端和云存储以查找副本 | | 实施正式的应用请求
工作流 | 使用户更容易安全地请求批准新
工具 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 执行用户和数据风险审查 | 了解使用影子 IT 的业务原因
及所涉数据的敏感性 | | --- | --- | | 更新 SaaS 控制策略 | 将新发现的应用包含在
未批准/阻止列表中或对其进行正式审查 | | 教育用户 | 增加有针对性的培训或事后简报 | | 向合规/管理层报告 | 如果监管数据被暴露或客户机密性遭到破坏 | | 审查并更新 DLP/CASB
配置 | 针对导致此使用行为未被检测到的
漏洞 | ## 通常涉及的工具 CASB（例如 Microsoft Defender for Cloud Apps, Netskope, Skyhigh Security） DLP（例如 Forcepoint, Microsoft Purview, Symantec DLP） SIEM（例如 Splunk, Sentinel） Web 代理和 NGFW（例如 Zscaler, Palo Alto, Fortinet） 终端监控工具（例如 CrowdStrike, Tanium） SaaS 访问治理工具（例如 BetterCloud, DoControl） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离数据上传或 SaaS 访问 <5 分钟 | | SaaS 访问阻止时间 | 距离告警 <15 分钟 | | 数据移除完成 | 公开或第三方暴露在 24 小时内 | | 用户教育完成 | 100% 的相关用户在 3 个工作日内重新简报 | | 策略审查更新 | 7 天内纳入经验教训 | # 剧本 30：通过公共 GitHub 仓库泄露 API 密钥 ## 场景 开发人员意外提交并将 API 密钥、云凭证或其他机密信息推送到公共 GitHub 仓库。这些机密信息可能会被攻击者（包括监控 GitHub 的机器人）收集，并用于访问关键系统、云资源或第三方 API。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 凭证暴露 – 源代码泄露 | | 严重程度 | 严重（特别是对于云或生产凭证） | | 优先级 | 严重 | | 检测
来源 | GitHub Secret Scanning Alerts, TruffleHog, Gitleaks, 云提供商
告警, 漏洞赏金报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 启用 GitHub 机密扫描 | 激活 GitHub Advanced Security 或第三方扫描器（例如 Gitleaks, TruffleHog） | | 使用预提交钩子 | 整合机密检测工具以防止包含
机密的提交 | | 定期轮换机密 | 使用 vault（例如 HashiCorp Vault, AWS Secrets Manager）并
强制执行密钥过期策略 | | 培训开发人员 | 关于安全编码实践和推送
机密的危险性 | | 监控公共 GitHub
仓库 | 使用威胁情报和 GitHub API 持续扫描暴露的
组织资产 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 在提交中检测到
机密 | 来自 GitHub、内部扫描或外部报告的告警 | | 识别机密类型和
范围 | API 密钥、云访问密钥、数据库密码、令牌等 | | 关联拥有者用户/仓库 | 找到提交它的开发人员并确定仓库是否公开 | | 分析暴露
窗口 | 公开了多长时间？是否有使用迹象（例如日志、突破
速率限制）？ | | --- | --- | | MITRE ATT&CK 映射 | T1552.001 (Credentials in Files), T1087 (Account Discovery),
T1528 (Steal Access Token) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 立即撤销暴露的
机密 | 从提供商处停用 API 密钥、令牌或凭证 | | 限制受影响的服务 | 如果机密授予了广泛的访问权限，请禁用依赖的
集成或流水线 | | 告警开发人员和安全
团队 | 通知以进行立即验证和补救 | | 从历史记录中删除敏感提交 | 使用 git filter-branch, BFG 或 git rebase 等工具
清除机密 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 用新密钥替换暴露的
密钥 | 通过 vault 或
机密管理器安全地生成和分发新密钥 | | 审计云/API 日志 | 在暴露期间寻找使用泄露密钥滥用的
迹象 | | 验证 GitHub 仓库卫生 | 审查提交历史并删除任何其他敏感
信息 | | 阻止仓库或标记为私有 | 如果仍然存在风险或需要重新评估 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 使用新机密恢复服务访问 | 确认集成和流水线在使用轮换后的凭证
的情况下正常工作 | | 重新启用受影响的用户或
系统 | 一旦未检测到未经授权的访问 | | 监控滥用 | 对跨服务使用已撤销凭证的任何可疑行为
设置告警 | | 记录影响并确认
仓库状态干净 | 确保开发团队遵守更新的策略 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行 RCA | 机密为何及如何暴露？人为错误、
Git 工具配置错误、没有扫描？ | | --- | --- | | 改进预提交
流水线 | 整合 Git 钩子或 CI/CD 扫描器以更早阻止此类
错误 | | 培训开发团队 | 关于安全软件开发生命周期 (SSDLC) 和
版本控制卫生 | | 更新事件文档 | 包含关键时间表、撤销的凭证和缓解工作 | | 必要时报告 | 对于涉及受监管数据或第三方系统的违规行为
(GDPR, PDPA, PCI DSS 等) | ## 通常涉及的工具 GitHub Advanced Security（机密扫描） TruffleHog, Gitleaks, GitRob HashiCorp Vault, AWS Secrets Manager, Azure Key Vault SIEM（例如 Sentinel, Splunk）和威胁检测系统 版本控制审计（例如 Git 日志解析、提交审查者） ## 成功指标 | 指标 | 目标 | | --- | --- | | 撤销时间 | 距离检测 <15 分钟 | | 提交清理时间 | 关键机密 <1 小时 | | 机密替换与重新整合 | 生产使用 <4 小时 | | 暴露窗口分析完成 | 24 小时内 | | 开发人员对策略的确认 | 100% 的相关开发人员在 2 个工作日内 | # 剧本 31：未经授权访问 CI/CD 机密 ## 场景 存储在 CI/CD 工具（例如 Jenkins, GitHub Actions, GitLab CI, Azure DevOps）中的机密（例如云凭证、API 令、SSH 密钥或环境变量）被未经授权的一方访问——无论是通过配置错误、日志泄露、受损的 runner 还是恶意的拉取请求。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 凭证暴露 – CI/CD 安全漏洞 | | 严重程度 | 严重（特别是对于生产或云基础设施访问） | | 优先级 | 严重 | | 检测
来源 | SIEM, 机密扫描工具, CI/CD 审计日志, CSPM, 威胁
情报, 漏洞赏金报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 将机密存储在 vault 中 | 使用机密管理器（例如 HashiCorp Vault, AWS Secrets Manager）代替纯文本 CI/CD 变量 | | 应用最小权限 | 将 CI 作业和服务帐户限制为仅所需的权限 | | 监控 CI/CD 审计
日志 | 在 runner、工作流和机密访问上启用日志记录 | | 扫描仓库和
流水线 | 使用 TruffleHog, Gitleaks 或 GitHub Secret Scanning 等工具
检测暴露的机密 | | 保护 CI/CD runner | 隔离、更新并保护 runner 免受篡改或权限
提升 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 从流水线日志或 vault 中访问或窃取机密 | | 识别被访问的
机密 | 暴露了哪些机密，它们控制哪些系统？ | | 审查 CI 作业和
触发来源 | 确定这是恶意作业、PR 滥用还是内部滥用 | | 分析日志和
运行时元数据 | 检查作业日志、runner 行为、环境变量和
外部回调 | | MITRE ATT&CK
映射 | T1552.004 (Credentials in CI/CD), T1529 (System
Shutdown/Reboot to Disrupt), T1078.004 (Cloud Credentials Abuse), T1059 (Script Execution) | | --- | --- | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 撤销暴露的机密 | 立即禁用或轮换凭证、令牌
和密钥 | | 禁用 CI 作业或流水线 | 特别是那些被滥用或计划
重新运行的作业或流水线 | | 锁定受影响的仓库
或 runner | 防止进一步的作业执行并隔离可疑的
PR 或提交 | | 通知受影响的平台和
安全团队 | 告警开发人员、DevOps 和 SecOps | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 删除或清理易受攻击的作业
或工作流 | 移除嵌入的机密或包含
它们的日志输出 | | 重建并保护 runner | 应用安全更新，审计 rootkit 或
持久性并重新部署 | | 收紧机密处理 | 通过安全 vault 使用环境级注入，
而不是硬编码的机密 | | 更新访问控制列表 | 移除过度宽松的角色或对外部贡献者的
默认信任 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在受影响的系统中
轮换机密 | 云帐户、API、数据库等 | | 恢复 CI/CD 操作 | 在对构建作业、runner 和配置进行全面验证和加固后 | | 对重建的环境应用监控 | 包括对机密使用和构建行为的异常检测 | | 恢复合法的 PR 和代码
提交 | 一旦验证为安全且已授权 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行 RCA | 确定根本原因——vault 配置错误、内部威胁、日志泄露
或权限滥用 | | --- | --- | | 更新 CI/CD 安全
策略 | 强制执行 PR 批准工作流、作业限制和仅限 vault 的
机密 | | 培训 DevSecOps 团队 | 关于安全的机密管理和流水线卫生 | | 向外部利益相关者报告 | 如果暴露的机密影响了客户、顾客或受监管的数据 | | 将发现记录在
操作手册中 | 包括妥协指标、时间线和检测
差距 | ## 通常涉及的工具 CI/CD 平台（例如 GitHub Actions, GitLab CI, Jenkins, Azure DevOps） 机密管理系统（例如 AWS Secrets Manager, Vault） 机密扫描工具（例如 TruffleHog, Gitleaks, GitGuardian） SIEM（例如 Splunk, Sentinel） SOAR（用于响应自动化） CSPM（用于云环境加固和机密检测） 终端监控（如果 runner 或开发人员成为目标） ## 成功指标 | 指标 | 目标 | | --- | --- | | 机密撤销时间 | 距离检测 <15 分钟 | | CI 作业暂停时间 | <30 分钟 | | 受影响机密替换时间 | <4 小时 | | 安全 Runner 重新部署时间 | <24 小时 | | 开发人员培训完成 | 100% 的相关团队在 3 个工作日内 | # 剧本 32：第三方库中的零日漏洞利用 ## 场景 您的环境中使用的第三方库或框架（例如 Log4j, OpenSSL, Apache Struts, glibc）中披露了一个严重漏洞（或在野外被积极利用）。攻击者可能会在补丁或缓解措施可用之前利用此零日漏洞，通常通过远程代码执行 (RCE)、信息泄露或权限提升来实现。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 零日漏洞利用 – 供应链 / 库 | | 严重程度 | 严重（取决于暴露程度和可利用性） | | 优先级 | 严重 | | 检测
来源 | 威胁情报源, 供应商建议, SIEM, EDR/XDR, 网络
检测, 漏洞赏金报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 维护 SBOM (软件物料清单) | 使用 CycloneDX, Syft, Anchore 等工具跟踪所使用的依赖项 | | 订阅威胁情报
和 CVE 源 | 确保安全团队获得早期告警（例如 CISA KEV,
NVD, GitHub Security Advisories） | | 标记使用受影响库的
关键工作负载 | 在发出告警时启用有针对性的日志记录和监控 | | 建立紧急补丁和
缓解流程 | 准备计划外更新和开发/测试推出
计划 | | 加固外部攻击
面 | 阻止不必要的暴露（例如管理面板、
调试端点） | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 公开披露了带有可用 PoC 或活跃利用报告的严重零日漏洞 | | 识别受影响的
系统 | 使用 SBOM 或资产管理列出使用易受攻击
库的系统 | | 评估暴露程度 | 确定服务是可从外部访问还是可从内部访问 | | 监控 IOC | 收集指标，如进程异常、网络回调、
异常日志条目 | | --- | --- | | MITRE ATT&CK
映射 | T1190 (Exploit Public-Facing Application), T1210 (Exploitation of
Remote Services), T1588.006 (Vulnerability Disclosure) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 隔离暴露的服务 | 如果没有可用的补丁，阻止对易受攻击应用程序的
互联网访问 | | 部署 WAF/IPS 虚拟
补丁 | 使用签名或有效载荷过滤阻止已知的漏洞利用模式 | | 移除或禁用
插件/模块 | 如果在不严重影响操作的情况下能降低风险，
则暂时禁用该功能 | | 通知内部利益相关者 | 在安全、开发和基础设施团队之间协调，以
开始紧急缓解 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 应用供应商补丁或升级 | 一旦可用；在推送到生产环境之前
在预发环境中进行验证 | | 替换受影响的库 | 如果无法打补丁，切换到安全版本或
替代品 | | 移除丢弃的有效载荷或
后门 | 如果已经发生利用，则从受损主机中移除 | | 清理临时缓解措施 | 一旦系统打上补丁并确认安全 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 恢复完整的应用程序
操作 | 在验证打补丁的环境之后 | | 进行全面取证 | 确定系统在打补丁前是否被利用，以及
数据是否被访问 | | 暂时增加日志记录 | 在打补丁的系统周围保持 7-14 天的
增强可见性 | | 验证第三方组件 | 确保供应商和合作伙伴也打补丁或缓解零日
风险 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 记录时间线和影响 | 从披露到缓解以及任何已确认的
事件 | | --- | --- | | 更新漏洞管理策略 | 包含对新兴威胁和零日漏洞的响应 | | 培训开发和安全团队 | 关于监控依赖项和有效使用 SBOM | | 向监管机构/客户报告 | 如果发生违规或敏感数据面临风险（例如根据 GDPR, PDPA, PCI DSS） | | 事后进行桌面演练 | 模拟类似场景以测试准备情况 | ## 通常涉及的工具 SBOM 和依赖扫描器（例如 Anchore, Snyk, OWASP Dependency-Check） 威胁情报平台（例如 MISP, Recorded Future, CISA KEV） SIEM（例如 Sentinel, Splunk） EDR/XDR（例如 CrowdStrike, Cortex XDR） WAF/IPS（例如 Cloudflare, AWS WAF, Palo Alto） 用于自动化剧本执行的 SOAR ## 成功指标 | 指标 | 目标 | | --- | --- | | 初始分诊时间 | 距离公开披露 <30 分钟 | | 暴露映射时间 | 距离识别受影响系统 <2 小时 | | 缓解部署 | 12-24 小时内 | | 补丁完成 | 关键系统 <48 小时 | | 事后报告 | 72 小时内 | # 剧本 33：SaaS 平台中滥用被盗会话令牌 ## 场景 攻击者获取了对有效会话令牌的访问权限（例如通过 XSS、网络钓鱼、恶意软件或从终端窃取令牌），并利用它在 SaaS 平台（例如 Microsoft 365, Google Workspace, Salesforce, Slack）上冒充合法用户。这允许在不触发 MFA 或登录异常告警的情况下进行访问。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 帐户劫持 – 会话令牌滥用 | | 严重程度 | 高到严重（基于数据访问和权限级别） | | 优先级 | 严重 | | 检测
来源 | CASB, SIEM, EDR, SaaS 审计日志, 用户报告, 威胁情报源 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 启用会话管理日志 | 在所有 SaaS 平台中捕获令牌重用或
可疑的 IP 登录 | | 部署 CASB 和 SaaS 安全
工具 | 监控用户行为、令牌异常和
会话重用 | | 使用条件访问策略 | 基于地理位置、设备信任和用户风险
评分 | | 教育用户有关网络钓鱼和
令牌窃取的知识 | 包括会话令牌如何被滥用 | | 整合终端保护 | 防止通过恶意软件窃取令牌 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 不寻常的会话活动（例如，来自已知 IP 但行为或位置
异常的登录） | | 检查重复
会话 | 同一令牌从不同的 IP 或地理位置重用 | | 审查最近的用户活动 | 寻找数据下载、权限更改、新的应用集成 | | 分析终端
日志 | 可能提取令牌的恶意软件或工具（例如 RedLine, Vidar） | | --- | --- | | MITRE ATT&CK
映射 | T1539 (Steal Web Session Cookie), T1078 (Valid Accounts),
T1185 (Browser Session Hijacking) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 撤销所有活动会话 | 强制受影响的用户在所有设备和应用上
登出 | | 暂时禁用用户帐户 | 如果攻击者活动正在进行或破坏严重 | | 阻止攻击者 IP 或设备 | 在 SaaS 提供商、CASB 或防火墙级别 | | 通知用户和支持团队 | 通知用户重置密码并验证 MFA
设备 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 扫描终端以查找恶意软件 | 确保用户的设备上没有仍处于活动状态的
令牌窃取程序 | | 轮换任何暴露的凭证
或令牌 | 对于链接的应用程序或集成 | | 审查会话存储
实践 | 确保会话令牌不以明文形式存储或
被不正确地缓存 | | 加强 SaaS 登录策略 | 对敏感操作或高风险登录
强制执行重新认证 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在严格监控下重新启用用户访问 | 确保终端干净并重新强制执行 MFA 后 | | 密切监控用户活动 | 对行为偏差或异常下载应用告警 | | 教育用户有关会话劫持的迹象 | 强化会话安全的最佳实践 | | 进行内部检查 | 确保没有发生横向移动或权限滥用 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 完成 RCA | 确定令牌是如何被盗的：恶意软件、网络钓鱼、
浏览器同步等 | | --- | --- | | 改进会话卫生策略 | 减少会话持续时间，防止跨设备或
地理位置重用 | | 培训员工 | 定期进行有关 SaaS 风险和会话意识的教育 | | 记录发现 | 记录在 IR 日志和经验教训报告中 | | 通知第三方或监管机构 | 如果敏感数据被访问或在外部共享 | ## 通常涉及的工具 CASB（例如 Microsoft Defender for Cloud Apps, Netskope, Lookout） SaaS 安全态势管理（例如 Obsidian, AppOmni） SIEM（例如 Sentinel, Splunk） 终端检测与响应（例如 CrowdStrike, Cortex XDR） 身份提供商（例如 Okta, Azure AD, Google Workspace） 浏览器安全工具（例如 LayerX, Seraphic） ## 成功指标 | 指标 | 目标 | | --- | --- | | 会话撤销时间 | 距离检测 <10 分钟 | | 终端验证时间 | <1 小时 | | 事后 MFA 强化 | 100% 在 24 小时内完成 | | SaaS 行为监控持续时间 | 事后 ≥ 14 天 | | RCA 和报告完成 | 3 个工作日内 | # 剧本 34：对象存储中的云原生勒索软件 ## 场景 攻击者获得对云对象存储（例如 Amazon S3, Azure Blob Storage, Google Cloud Storage）的访问权限，并执行恶意操作，例如加密文件、更改权限、删除备份或放置勒索信——而无需部署勒索软件二进制文件，纯粹使用 API 或 SDK。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 勒索软件 – 对象存储 (云原生) | | 严重程度 | 严重 | | 优先级 | 严重 | | 检测
来源 | CSPM 告警, SIEM, 云存储日志, CASB, CloudTrail, Access
Analyzer, 用户报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 应用严格的 IAM 策略 | 对存储访问（读/写/删除）使用最小权限原则 | | 启用版本控制和 MFA
删除 | 在 S3、GCS 或 Azure Blob 中保留文件历史记录并阻止
未经授权的删除 | | 启用日志记录和
监控 | CloudTrail, 存储访问日志以及对异常活动的
告警 | | 为存储设置异常检测 | 突然的写入/删除爆发、非人类行为、大规模文件访问 | | 测试恢复流程 | 确保备份和快照能够快速可靠地
恢复 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 不寻常的存储活动：大规模对象覆盖/删除，来自未知 IP 的访问或勒索信文件 | | 关联 IAM
活动 | 识别负责存储操作的用户或服务帐户 | | 确定影响范围 | 存储桶/容器的数量、受影响的数据类型以及是否存在备份 | | 搜索 IOC | 被重命名/加密的文件，勒索信（例如 README_TO_RESTORE.txt），奇怪的文件扩展名 | | --- | --- | | MITRE ATT&CK
映射 | T1485 (Data Destruction), T1486 (Data Encrypted for Impact),
T1531 (Account Access Removal) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 撤销受影响的 IAM 角色或密钥 | 立即禁用对负责的用户或
应用程序的访问 | | 阻止恶意 IP 地址 | 使用云服务提供商防火墙规则或地理围栏 | | 锁定存储桶 | 移除公共访问并应用限制性的 ACL 和策略 | | 告警云安全和事件
响应团队 | 触发紧急补救计划 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 审计所有存储策略和
访问日志 | 确保没有其他后门或恶意用户
保持活动 | | 轮换访问凭证 | 针对所有涉及的云帐户和应用程序 | | 移除攻击者植入物或文件 | 删除勒索信、木马化文件或留下的 API 日志 | | 修补外部入口点 | 如果漏洞利用来自 Web 应用程序或暴露的
访问密钥 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 从备份或对象版本控制恢复 | 使用最后已知的良好版本或自动快照 | | 验证数据完整性 | 检查恢复的文件是否完整且未被更改 | | 恢复业务服务 | 在存储和应用程序被验证为安全之后 | | 增加日志记录和检测阈值 | 针对受影响的存储桶和关联的身份 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行 RCA | 追踪攻击向量、使用的方法和时间线 | | 改进监控和访问控制 | 对对象存储访问和异常检测执行更严格的策略 | | --- | --- | | 更新操作手册和告警规则 | 包含新的攻击模式和预防指南 | | 培训 DevOps 和云管理员 | 关于安全存储配置和快速响应技术 | | 报告事件 | 如果敏感数据受到影响，向监管机构和客户报告 | ## 通常涉及的工具 云审计日志（例如 AWS CloudTrail, Azure Activity Logs, GCP Admin Logs） CSPM 工具（例如 Wiz, Prisma Cloud, Microsoft Defender for Cloud） SIEM（例如 Sentinel, Splunk, Chronicle） CASB（例如 Netskope, Defender for Cloud Apps） 备份和灾难恢复工具（例如 AWS Backup, Azure Site Recovery, GCP Snapshots） SOAR（用于自动补救） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离大规模存储修改 <5 分钟 | | IAM 密钥撤销时间 | 距离检测 <10 分钟 | | 数据恢复时间 | <6 小时（对于关键数据） | | 访问策略审查时间 | 100% 的受影响存储桶在 24 小时内审查完毕 | | RCA 和补救报告 | 72 小时内完成 | # 剧本 35：恶意内部人员在云中暂存数据 ## 场景 组织内受信任的用户滥用其对敏感数据（例如 PII、源代码、财务数据）的访问权限，并开始将其上传到未经批准的云平台（例如个人 Google Drive, Dropbox, Mega, OneDrive）以进行窃取。这可能发生在辞职、举报或商业间谍活动之前。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 内部威胁 – 数据暂存 / 窃取 | | 严重程度 | 高到严重（基于数据敏感性和暴露级别） | | 优先级 | 严重 | | 检测
来源 | DLP, CASB, SIEM, 代理日志, 终端代理, 用户报告, 内部
威胁计划 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 实施内部威胁监控 | 使用带有行为基线的 UEBA, CASB 和 DLP | | 强制执行批准的云存储
策略 | 使用 CASB 或防火墙规则阻止未经批准的 SaaS 上传 | | 监控大文件传输和压缩 | 使用终端和代理规则检测大规模打包或上传 | | 培训员工有关数据处理策略 | 强化数据滥用的纪律和法律后果 | | 对敏感文件使用标记 | 对文档进行分类以应用有针对性的监控 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | DLP 或 CASB 检测到向未经批准的云服务上传文件 | | 调查用户行为 | 寻找辞职、违反策略或异常工作时间的迹象 | | 关联数据
访问和传输 | 识别哪些文件被访问、下载、打包或上传 | | 确定目标云存储 | 个人 Google Drive, Dropbox, Mega, iCloud 等 | | MITRE ATT&CK
映射 | T1537 (Transfer Data to Cloud Account), T1081 (Credentials
from Password Stores), T1567.002 (Exfiltration to Cloud Storage) | | --- | --- | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 阻止进一步访问外部存储 | 通过 CASB 或代理强制执行云应用控制 | | 暂停或限制用户帐户 | 如果行为明显具有恶意或数据丢失
正在发生，则暂时停止 | | 隔离用户设备 | 如果还怀疑存在恶意软件或凭证窃取 | | 保留会话和文件日志 | 用于取证分析和法律用途 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 移除对敏感系统的访问 | 撤销提升的权限并从敏感组或共享中移除 | | 检索或删除暂存数据 | 如果存储在企业设备上或可从个人云中检索（在法律支持下） | | 重置凭证和令牌 | 特别是如果用户拥有 API 访问权限或正在使用自动化工具 | | 禁用影子云帐户 | 防止从企业系统进一步访问或数据同步 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 重新分配关键职责 | 如果员工处于特权角色或交接的一部分 | | 监控后续的窃取尝试 | 对用户帐户或类似配置文件使用增强的日志记录 | | 审查跨系统的审计日志 | 确保没有发生横向活动或额外的数据传输 | | 恢复正常操作 | 一旦事件范围和风险得到控制 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行全面的内部威胁 RCA | 了解动机、机会和控制弱点 | | 改进内部威胁模型 | 优化 UEBA 规则和升级剧本 | | 通知人力资源和法律部门 | 用于可能的纪律处分、法律跟进或起诉 | | --- | --- | | 审查并更新 DLP/CASB
策略 | 将新滥用的平台或策略添加到检测范围 | | 通知监管机构或客户 | 如果受监管数据被暴露或客户机密被泄露 | ## 通常涉及的工具 DLP（例如 Microsoft Purview, Forcepoint, Symantec DLP） CASB（例如 Netskope, Microsoft Defender for Cloud Apps） UEBA/内部威胁平台（例如 Splunk UBA, Exabeam, Varonis） SIEM（例如 Sentinel, Splunk） 终端监控（例如 CrowdStrike, Trellix, Tanium） 代理和 NGFW（ Zscaler, Palo Alto） 人力资源系统和法律支持工具 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离数据上传 <5 分钟 | | 帐户限制时间 | 距离告警 <15 分钟 | | 数据恢复 / 遏制时间 | <24 小时 | | 取证分析完成 | 48 小时内 | | 内部威胁剧本更新 | 3 个工作日内 | # 剧本 36：未经授权的 SaaS OAuth 应用程序集成 ## 场景 员工或攻击者使用 OAuth 范围（例如读取电子邮件、访问日历、读/写文件）授予第三方应用程序对企业 SaaS 帐户的访问权限。这些应用程序可能会窃取数据、冒充用户或维持持久访问，而不会触发标准的凭证或 MFA 告警。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | OAuth 滥用 – 未经授权的第三方应用 | | 严重程度 | 高（取决于授予的范围和访问的数据） | | 优先级 | 高到严重 | | 检测来源 | CASB, SSPM, SaaS 管理门户, SIEM, 威胁情报源 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 限制应用同意策略 | 仅允许对预先批准或已验证的应用进行 OAuth 同意 | | 监控 OAuth 活动日志 | 使用 SIEM 或 SaaS 安全工具跟踪应用授权和范围 | | 教育用户 | 关于在企业环境中授权个人或未知应用的风险 | | 整合 SSPM/CASP
工具 | 用于已授权应用程序的可见性和风险评分 | | 应用条件访问
策略 | 限制来自非托管设备的应用连接 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 检测到具有提升范围（例如读取邮件、读取驱动器、发送消息）的风险或未批准的 OAuth 应用 | | 识别用户和
应用程序 | 谁授权了它，授予了什么范围，使用了什么应用 | | 分析访问日志 | 检查应用是否访问了敏感数据或执行了操作（例如发送电子邮件、下载文件） | | 审查应用
元数据 | 声誉、风险评分、域名注册、先前的威胁报告 | | --- | --- | | MITRE ATT&CK
映射 | T1528 (Steal Access Token), T1550.001 (Application Access
Token), T1098.003 (External Account) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 立即撤销应用访问权限 | 通过管理门户（例如 Azure AD, Google Workspace,
Slack 管理员） | | 暂停受影响的用户
帐户 | 如果确认存在恶意行为或数据泄露 | | 阻止应用域名或 API
端点 | 通过防火墙、CASB 或 DNS 过滤器防止回调连接 | | 通知用户和安全团队 | 启动内部调查和遏制措施 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 移除残留的访问令牌 | 撤销授予该应用的所有令牌并刷新用户会话 | | 轮换凭证和 MFA | 如果怀疑存在冒充或令牌窃取 | | 进行全面的数据访问
审查 | 确定该应用有权访问什么以及数据是否被窃取 | | 更新 OAuth 策略 | 将该应用添加到 SSPM 或 CASB 的阻止列表或黑名单类别中 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在监控下恢复用户访问 | 确保用户知情并在链接恶意软件时清理终端 | | 应用更严格的应用审查流程 | 要求对所有新的应用集成进行内部批准 | | 监控复发情况 | 为类似的应用授权模式或行为创建检测 | | 验证 SaaS 日志和告警 | 确保对高风险 OAuth 事件的完全可见性 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 完成根因分析 | 为什么该应用被授权？是网络钓鱼、无知还是绕过了控制？ | | --- | --- | | 改进用户培训 | 关于安全的 SaaS 使用和应用程序访问警告 | | 加强 OAuth 治理 | 整合 SSPM 并自动化基于风险的应用批准/撤销 | | 记录事件 | 用于合规性、审计跟踪和策略更新 | | 通知受影响各方或监管机构 | 如果客户数据或敏感记录被访问 | ## 通常涉及的工具 SSPM/CASP（例如 AppOmni, Obsidian, Microsoft Defender for Cloud Apps） SaaS 管理门户（例如 Azure AD, Google Admin Console, Slack Admin） SIEM（例如 Sentinel, Splunk） 威胁情报（用于应用风险评分和声誉） SOAR（用于自动化检测和撤销） 终端安全（确保令牌来源干净） ## 成功指标 | 指标 | 目标 | | --- | --- | | 应用撤销时间 | 距离检测 <15 分钟 | | 用户通知和会话重置 | <30 分钟 | | 完整应用审计和 RCA 完成 | 48 小时内 | | OAuth 策略更新 | 3 个工作日内 | | 用户意识培训完成 | 100% 在 5 个工作日内 | # 精英 DFIR 增强层 ## 证据收集检查表 | 证据类型 | 示例 | 为何重要 | |---|---|---| | 身份证据 | 登录日志，MFA 事件，OAuth 授权，令牌活动 | 确认帐户泄露和访问路径 | | 终端证据 | EDR 时间线，进程树，命令行，文件哈希 | 显示执行链和持久性 | | 网络证据 | DNS，代理，防火墙，NetFlow，Zeek，Suricata | 确认通信路径和窃取指标 | | 云证据 | CloudTrail，Azure Activity Logs，M365 Unified Audit，存储日志 | 揭示云控制平面活动 | | 应用证据 | Web 服务器日志，API 网关日志，WAF 告警 | 确认漏洞利用载荷和受影响的端点 | | 业务证据 | 影响声明，受影响用户，财务风险 | 支持高管报告和风险决策 | ## SOC 分诊问题 1. 是什么触发了告警？ 2. 哪些资产、帐户、应用程序或云资源受到了影响？ 3. 该活动被确认为恶意的、可疑的、意外的还是与策略相关的？ 4. 是否存在权限提升、持久性、横向移动或窃取的证据？ 5. 什么遏制行动可以在不造成不必要的业务中断的情况下阻止损害？ 6. 必须通知谁：SOC 负责人、IT、法务、隐私、人力资源、高管、客户、监管机构？ ## 遏制决策指南 | 情况 | 建议行动 | |---|---| | 确认的勒索软件加密 | 立即隔离主机，禁用受影响的帐户，保护证据 | | 可疑的云登录 | 撤销会话，重置密码，强制执行 MFA，审查 OAuth 授权 | | BEC 或邮箱接管 | 禁用恶意规则，撤销令牌，检查已发送项目，向受影响方发出告警 | | 发现 Web shell | 隔离 Web 服务器，保留工件，阻止外部访问，修补漏洞 | | 内部窃取 | 暂停访问，保留证据，让 HR/法务介入，禁用传输渠道 | | DDoS 攻击 | 联系提供商，启动缓解措施，速率限制，验证服务健康状况 | ## 示例 KQL 检测 ### 失败登录后跟随成功 ``` SecurityEvent | where EventID in (4624, 4625) | summarize Failed=countif(EventID == 4625), Success=countif(EventID == 4624) by Account, IpAddress, bin(TimeGenerated, 30m) | where Failed >= 5 and Success >= 1 ``` ### 可疑的 PowerShell 关键字 ``` SecurityEvent | where EventID == 4688 | where CommandLine has_any ("EncodedCommand", "IEX", "DownloadString", "FromBase64String", "Invoke-WebRequest") | project TimeGenerated, Computer, Account, NewProcessName, CommandLine ``` ### 云不可能旅行概念 ``` SigninLogs | where ResultType == 0 | summarize Countries=make_set(Location), IPs=make_set(IPAddress), Count=count() by UserPrincipalName, bin(TimeGenerated, 1h) | where array_length(Countries) > 1 ``` ## 高管事件更新模板 | 字段 | 内容 | |---|---| | 事件名称 | | | 当前状态 | 调查中 / 已遏制 / 根除中 / 恢复中 / 已关闭 | | 业务影响 | | | 受影响系统 | | | 确认的数据暴露 | 是 / 否 / 调查中 | | 已完成行动 | | | 下一步行动 | | | 所需决策 | | | 下次更新时间 | | ## 技术事件报告模板 | 部分 | 所需详情 | |---|---| | 摘要 | 发生了什么，何时开始，如何被检测到 | | 范围 | 受影响的用户、主机、应用程序、云帐户、数据 | | 时间线 | 告警时间、分诊时间、遏制时间、恢复时间 | | 根本原因 | 网络钓鱼、漏洞利用、弱凭证、配置错误、内部行动 | | IOC | IP、域名、哈希、URL、用户代理、进程名 | | MITRE 映射 | 观察到的战术和技术 | | 遏制 | 为阻止进一步危害而采取的行动 | | 根除 | 移除持久性，修补漏洞，保护帐户安全 | | 恢复 | 系统恢复，监控期，业务验证 | | 经验教训 | 检测差距，控制差距，流程改进 | ## 成功指标仪表板 | 指标 | 为何重要 | |---|---| | MTTD - 平均检测时间 | 衡量可见性和检测工程的成熟度 | | MTTA - 平均确认时间 | 衡量 SOC 告警响应速度 | | MTTC - 平均遏制时间 | 衡量操作遏制准备情况 | | MTTR - 平均恢复时间 | 衡量弹性和恢复能力 | | 误报率 | 衡量检测质量和调优需求 | | 证据完整性 | 衡量调查质量和审计准备情况 | | 经验教训闭环 | 衡量改进是否真正得到实施 | ## CyberNova 专业收尾 强大的事件响应剧本不仅是一份检查清单。它是一个在压力下保护组织的决策支持系统。最优秀的 SOC 团队结合了技术证据、严谨的遏制、清晰的沟通、业务意识、法律准备和持续改进。
映射 | T1087.001 (账户发现), T1059 (通过 CI 执行命令),
T1606 (伪造 Web 凭证), T1565.002 (数据操纵 - 代码仓库) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销用户/API 访问权限 | 禁用用于访问的用户账户或令牌 | | 暂停 pipeline 执行 | 暂停 CI/CD 活动以防止进一步的破坏 | | 隔离受影响的系统 | 临时阻止对关键环境或服务器的访问 | | 通知 DevOps 和安全团队 | 协调遏制和代码审查活动 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 移除未经授权的代码或脚本 | 还原恶意提交，回滚 pipeline 更改 | | 轮换密钥和凭证 | 特别是如果在代码、环境变量或配置文件中发现它们 | | 清理受损账户 | 移除旧的用户、服务账户或令牌 | | 修补工具漏洞 | 对暴露或配置错误的 DevOps 平台应用更新 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复安全状态 | 确认代码和 pipeline 是干净的，且访问仅限于授权用户 | | 恢复 CI/CD 操作 | 仅在验证系统完整性之后 | | 监控代码库和构建过程 | 建立事件发生后的增强日志记录和监控 | | 重新验证审计控制 | 确保访问日志、版本控制和变更跟踪已启用且正常工作 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行全面审查 | 了解攻击向量、涉及的用户和受影响的数据 | | 更新访问策略 | 对敏感仓库和构建系统实施更严格的控制 | | --- | --- | | 培训 DevOps 人员 | 强化安全访问管理和代码审查策略 | | 向利益相关者报告 | 如果涉及专有或受监管数据，需通知法律、合规部门和客户 | | 记录 playbook 更新 | 改进 SOC 和 DevOps 团队未来的检测和响应流程 | ## 通常涉及的工具 SIEM（例如 Sentinel、Splunk） Git 平台（例如 GitHub、GitLab、Bitbucket） CI/CD 工具（例如 Jenkins、GitLab CI、CircleCI、Azure DevOps） IAM 和 SSO（例如 Okta、Azure AD、Google Workspace） 密钥扫描器（例如 TruffleHog、Gitleaks） 容器安全工具（例如 Aqua、Prisma Cloud） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 未经授权访问后 <10 分钟 | | 访问撤销时间 | 警报后 <30 分钟 | | 密钥轮换时间 | 高价值令牌或密钥 <1 小时 | | 代码库验证时间 | <24 小时 | | 事件后审计完成时间 | 3 个工作日内 | # Playbook 16：滥用 OAuth 集成 ## 场景 攻击者通过诱骗用户授权恶意的 OAuth 应用程序（例如通过网络钓鱼或社会工程学）来获取用户的云或应用程序账户访问权限。这无需登录凭证即可获得持久访问权限，在许多情况下甚至能绕过 MFA。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 第三方应用程序滥用 / 基于令牌的账户失陷 | | 严重程度 | 高到严重（特别是如果授予了特权或敏感账户访问权限） | | 优先级 | 严重 | | 检测来源 | SIEM、OAuth 审计日志、云身份平台（例如 Google Workspace、Azure AD）、用户报告、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 监控 OAuth 授权 | 为应用程序同意和令牌授予启用日志记录 | | 限制第三方应用权限 | 实施策略以限制高权限访问 | | 强制执行管理员同意工作流 | 要求安全团队批准高风险的 OAuth 作用域 | | 教育用户网络钓鱼风险 | 强调授权未知应用程序的风险 | | 将身份日志集成到 SIEM | 关联令牌活动和应用程序安装情况 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 检测可疑的应用同意 | OAuth 应用程序请求异常权限或被大量账户广泛使用 | | 审查审计日志 | 检查是否向未知或最近创建的应用程序颁发了令牌 | | 识别受影响的用户 | 映射授权了恶意应用程序的用户并评估数据访问范围 | | 调查应用程序行为 | 确定该应用程序是否访问了电子邮件、文件、云存储或联系人 | | MITRE ATT&CK
映射 | T1525 (植入内部镜像), T1556.004 (伪造 Web 凭证), T1087 (账户发现) | # Playbook 15：对开发环境的未经授权访问 ## 场景 个人未经授权获得对开发环境（例如 Git 仓库、暂存服务器、像 Jenkins 或 GitLab CI 这样的 CI/CD 平台或测试数据库）的访问权限。这可能导致代码被盗、插入恶意代码或泄露凭证和机密。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 访问控制违规 / 内部威胁 | | 严重程度 | 高（特别是如果源代码或机密被访问或修改） | | 优先级 | 严重 | | 检测来源 | SIEM、Git 日志、IAM、DevOps 工具（例如 Jenkins、GitLab）、审计追踪、源代码版本控制系统 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制执行基于角色的访问控制 | 对所有开发工具使用 IAM 策略、SSO 和最小特权原则 | | 启用审计和日志 | 跟踪对 Git 仓库、CI/CD 系统和测试环境的访问 | | 将日志流集成到 SIEM | 从 GitHub/GitLab、Jenkins 等流式传输日志 | | 应用机密扫描工具 | 检测代码中硬编码的凭证和令牌 | | 开展 DevSecOps 培训 | 教育开发人员关于安全编码和仓库卫生的知识 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 IAM/SIEM 的警报 | 来自异常 IP 或用户的可疑登录、令牌使用或仓库访问 | | 审查 Git/CI 日志 | 检查最近的提交、合并、pipeline 执行和用户访问情况 | | 识别访问方法 | 直接登录、API 令牌、SSH 密钥或 OAuth 集成 | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销应用程序访问权限 | 通过管理门户或 API 从受影响的账户中移除 OAuth 授权/令牌 | | 在租户级别阻止应用程序 | 在 Google Workspace、Azure 或 GitHub 设置中禁止该应用程序的客户端 ID | | 禁用受影响的账户（如果需要） | 如果攻击者利用应用程序访问权限进行进一步横向移动 | | 通知用户 | 提醒他们有关撤销操作和潜在的数据泄露风险 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 轮换访问令牌和密码 | 如果应用程序访问了凭证或机密，需轮换用户和服务账户的令牌和密码 | | 清理受影响的环境 | 删除任何后门、转发规则或通过 OAuth 应用程序上传的文件 | | 加强租户范围内的策略 | 限制高风险的 OAuth 作用域（例如 offline access、mail.readwrite、drive full access） | | 更新网络钓鱼防护 | 阻止分发 OAuth 应用程序的相关钓鱼域名或链接 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复受影响的访问权限 | 在确认账户安全且已移除 OAuth 应用程序之后 | | 重新审计已连接的应用程序 | 确认用户中没有安装其他高风险应用程序 | | 强化用户 MFA 和会话控制 | 收紧身份策略（例如，撤销会话，要求重新身份验证） | | 恢复业务运营 | 一旦确认不存在来自恶意集成的进一步风险 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行影响分析 | 应用程序访问或共享了哪些数据？在什么时间段内？ | | 必要时进行报告 | 向法律、合规、监管机构（例如 PDPA、GDPR）或客户报告 | | 更新同意策略 | 要求对高风险应用作用域实行更严格的管理员控制 | | --- | --- | | 在内部共享事件详情 | 提高防范意识并更新安全意识培训材料 | | 改进检测逻辑 | 调优 SIEM 或 SOAR playbook 以检测高风险的 OAuth 授权和异常情况 | ## 通常涉及的工具 云管理控制台（例如 Google Workspace Admin、Azure AD Portal、Microsoft 365 Defender） 身份保护（例如 Okta、Duo、Conditional Access） SIEM（例如 Splunk、Sentinel、QRadar） 云安全工具（例如 Microsoft Defender for Cloud Apps、G Suite Alert Center） 用于网络钓鱼和应用信誉的威胁情报 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 高风险应用授权后 <15 分钟 | | 应用撤销时间 | 发现后 <30 分钟 | | 用户通知时间 | 受影响用户 <1 小时 | | OAuth 策略执行 | 100% 的用户处于管理员同意模式下（对于敏感作用域） | | 事件解决时间 | 发现后 24–48 小时内 | # Playbook 17：通过 DNS 隧道进行数据渗出 ## 场景 攻击者使用 DNS 作为通信信道来渗出数据或维持命令与控制。DNS 隧道将恶意 payload 或被盗数据隐藏在 DNS 查询中，由于 DNS 流量通常是被允许的，因此可以绕过传统的检测手段。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 隐蔽通道 – 数据渗出 | | 严重程度 | 高到严重（特别是如果确认有敏感数据被渗出） | | 优先级 | 严重 | | 检测来源 | DNS 日志、SIEM、NDR、威胁情报、端点警报、Zeek、Suricata | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 启用详细的 DNS 日志记录 | 从 DNS 解析器和转发器（例如 BIND、Windows DNS、Unbound）获取 | | 实施 DNS 检查 | 使用 NDR（例如 Corelight、Darktrace）、防火墙规则和模式匹配 | | 监控异常 DNS 活动 | 大量 TXT 查询、长域名、异常频率 | | 阻止已知的隧道工具 | 例如，通过威胁情报阻止 Iodine、DNScat2、DnsExfiltrator | | 对出站 DNS 强制执行最小特权 | 仅允许来自内部资产的授权 DNS 解析器 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 检测异常的 DNS 模式 | 较长的子域名长度、对罕见域名的频繁查询、base64 编码 | | 审查 DNS 日志 | 识别被查询的域名、查询类型（例如 TXT、NULL）以及涉及的端点 | | 与资产行为进行关联 | 确定发送查询的端点是否也显示出受损迹象 | | 验证域名所有权 | 检查可疑域名是否由攻击者控制或最近才注册 | | --- | --- | | MITRE ATT&CK
映射 | T1048.003 (通过非加密/混淆的非 C2 协议渗出), T1071.004 (应用层协议: DNS), T1568.002 (动态解析 - DNS) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 阻止可疑域名 | 在 DNS 解析器、防火墙和代理级别进行阻止 | | 隔离受影响的主机 | 断开网络连接以停止正在进行的渗出 | | 重定向 DNS 流量 | 强制所有出站 DNS 通过受监控的内部 DNS 服务器 | | 警报内部利益相关者 | IT、安全和管理层应立即得到通知 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 移除隧道工具或恶意软件 | 使用 EDR 或取证分析从端点中移除 | | 修补被利用的漏洞 | 如果攻击者是通过已知弱点访问权限的 | | 清理持久性机制 | 检查计划任务、注册表更改或启动脚本 | | 审查 DNS 配置 | 确保端点或服务器上不存在外部 DNS 绕过 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复网络连接 | 一旦系统被验证为干净且遏制控制已到位 | | 恢复 DNS 服务 | 强制通过带有检查功能的安全 DNS 基础设施进行转发 | | 重新验证受影响的系统 | 对以前受感染的主机执行全面扫描和流量监控 | | 更新威胁检测规则 | 使用新的指标和模式增强 SIEM、NDR 和防火墙规则 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录完整的渗出路径 | 确定哪些数据被作为目标或丢失，以及方式和时间 | | --- | --- | | 更新事件响应计划 | 增加针对 DNS 的检测和响应协议 | | 提高 DNS 可见性 | 在所有环境中强制执行结构化的 DNS 日志记录和分析 | | 如适用则报告数据泄露 | 根据 PDPA、GDPR、HIPAA 或特定行业法规进行报告 | | 共享 IOC 和发现 | 在内部以及与外部威胁情报社区（例如 ISACs）共享 | ## 通常涉及的工具 DNS 日志平台（例如 Infoblox、Bind logs、Windows DNS logs） NDR（例如 Corelight/Zeek、Darktrace、ExtraHop） SIEM（例如 Splunk、Sentinel、QRadar） EDR（例如 CrowdStrike、Cortex XDR） 威胁情报（例如 Recorded Future、MISP、AbuseIPDB） 防火墙和代理日志 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常 DNS 模式出现后 <15 分钟 | | 遏制时间 | 确认后 <30 分钟 | | 数据丢失影响报告 | 48 小时内（或在监管规定的时间内） | | DNS 日志覆盖率 | 100% 的出站 DNS 活动被记录和监控 | | 事件审查完成时间 | 解决后 72 小时内 | # Playbook 18：公共网站上未经授权的 JavaScript 注入 ## 场景 攻击者向面向公众的网站注入恶意 JavaScript 代码（通过受损的 CMS、第三方脚本、配置不当的 CDN 或直接替换文件）。这可能导致凭证收集、数据窃取（例如 Magecart）、点击劫持、重定向到恶意站点或会话劫持。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | Web 应用程序失陷 – 脚本注入 | | 严重程度 | 高到严重（特别是如果捕获了 PII、卡数据或身份验证数据） | | 优先级 | 严重 | | 检测来源 | WAF、SIEM、网站监控工具、Bug Bounty 报告、客户反馈、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 实施 CSP (内容安全策略) | 限制未经授权的脚本加载 | | 监控文件完整性 | 使用工具跟踪生产环境中 JS 文件的更改 | | 使用子资源完整性 (SRI) | 针对第三方脚本，确保它们未被篡改 | | 启用 Web 应用防火墙 (WAF) | 阻止可疑输入或漏洞利用企图 | | 定期执行代码审计 | 特别是针对 CMS 插件和第三方引入项 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 WAF 或监控工具的警报 | 检测到注入或被修改的 JavaScript | | 验证文件更改 | 将修改后的 JavaScript 与已知良好版本（Git、备份）进行比较 | | 审查注入源 | 是来自 CMS 插件、第三方来源还是直接编辑代码？ | | --- | --- | | 检查脚本行为 | 分析 payload：键盘记录、渗出、重定向、数据捕获 | | MITRE ATT&CK
映射 | T1059.007 (JavaScript), T1185 (浏览器会话劫持), T1189 (路过式入侵), T1557.002 (通过 Web 脚本进行输入捕获) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 移除或替换注入的脚本 | 立即从备份或仓库恢复干净的版本 | | 阻止恶意域名 | 如果涉及外部脚本，通过 DNS、代理或防火墙进行阻止 | | 禁用受影响的网站部分 | 如有必要，暂时关闭受损的部分或页面 | | 警报客户/用户 | 如果发生了数据收集，请快速传达泄露风险 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 确定根本原因 | 管理员凭证被盗？不安全的插件？第三方违规？ | | 修补 CMS 或插件 | 应用更新并禁用不必要或不受信任的组件 | | 替换受损组件 | 从具有经过验证的完整性的官方来源重新安装 | | 清理残留访问权限 | 更改管理员凭证，撤销令牌，检查服务器日志以查找持久性技术 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 验证网站完整性 | 重新检查所有文件和脚本的正确性和清洁度 | | 恢复正常运营 | 在确认没有残留恶意代码之后 | | 执行漏洞评估 | 特别是针对暴露的 CMS、JavaScript 包含项和 API | | 监控重复攻击尝试 | 暂时加强网络流量和行为监控 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录事件 | 包括注入向量、影响、攻击者域名和缓解步骤 | | 更新 Web 应用监控规则 | 为 JavaScript 完整性警报添加新的威胁指标 | | 培训 Web 开发人员和管理员 | 关于安全脚本实践、插件安全和变更控制的内容 | | 向监管机构报告 | 如果用户数据或支付信息受到损害 | | 改进 SDLC 安全性 | 在开发工作流中集成代码扫描、依赖项检查和 CI/CD 验证 | ## 通常涉及的工具 Web 监控工具（例如 Detectify、JSWatcher、SilentPush、Snyk、Sucuri） SIEM（例如 Splunk、Sentinel、QRadar） Web 应用防火墙（例如 Cloudflare WAF、AWS WAF、Imperva） CMS 平台和源代码仓库（例如 WordPress、GitHub） 文件完整性监控（例如 OSSEC、Tripwire） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 脚本修改或警报后 <15 分钟 | | 脚本移除时间 | 检测后 <30 分钟 | | 网站恢复时间 | 如果关键路径受到影响，<2 小时 | | 影响通知时间 | 24 小时内（或按监管 SLA） | | 重复攻击监控持续时间 | 至少 7 天的强化监视 | # Playbook 19：不安全的 API 端点利用 ## 场景 攻击者发现并利用缺乏身份验证、速率限制或适当输入验证等不安全的 API 端点，以执行未经授权的数据访问、修改业务逻辑、提升权限或发起拒绝服务 攻击。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 应用层漏洞利用 – API 滥用 | | 严重程度 | 高到严重（取决于数据敏感性和获得的访问级别） | | 优先级 | 高 | | 检测来源 | SIEM、API 网关日志、WAF、运行时应用自我保护 (RASP)、应用程序日志、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 启用 API 网关日志记录 | 跟踪请求方法、源 IP、端点和参数 | | 强制执行输入验证 | 在后端逻辑中实施严格的验证和清理 | | 部署速率限制和节流 | 防止通过批量或自动化请求进行滥用 | | 要求身份验证和授权 | 使用带有角色强制执行的 OAuth、JWT、API 密钥 | | 监控 API 行为 | 使用异常检测来标记意外的访问模式 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 接收警报 | 过多的 API 调用、未经授权的数据访问、错误激增（例如 403、500） | | 识别受影响的端点 | 分析日志以确定访问了哪些 API 以及如何访问的 | | 审查查询模式 | 寻找枚举、注入、批量抓取或业务逻辑滥用的迹象 | | 关联用户/IP | 确定行为人是内部的、已认证的还是在滥用开放 API | | --- | --- | | MITRE ATT&CK
映射 | T1190 (利用面向公众的应用), T1499 (端点 DoS),
T1001.003 (数据混淆), T1539 (窃取 Web 会话 Cookie) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 阻断违规 IP 或令牌 | 在 API 网关、WAF 或 CDN 层面进行阻断 | | 禁用脆弱的端点 | 暂时禁用或限制对受影响 API 的访问 | | 节流可疑流量 | 针对滥用模式实施更严格的速率限制 | | 警报开发和产品团队 | 协助进行遏制和业务风险评估 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 修复不安全的 API 逻辑 | 添加身份验证、访问控制和输入验证 | | 修补或重新部署后端服务 | 如果漏洞源于代码或库 | | 轮换受影响的凭证或 API 密钥 | 特别是如果发生了令牌盗窃或特权滥用 | | 移除注入的数据 | 如果攻击者使用 API 插入了恶意或损坏的数据 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复安全访问 | 在验证修复后，密切监控任何绕过或回归的迹象 | | 通知受影响的用户 | 如果个人或敏感数据被访问或更改 | | 重新测试受影响的 API | 在全面重新激活之前进行回归和安全测试 | | 恢复完整服务 | 一旦在生产环境中验证了安全性和稳定性 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行根本原因分析 | 识别设计、配置或开发中的疏忽 | | 更新 SDLC 策略 | 包括对 API 端点的安全测试（例如 OWASP API Top 10） | | 增强监控和警报 | 为枚举、过度调用或异常输入添加检测 | | --- | --- | | 培训开发人员 | 关于安全的 API 设计、适当的身份验证和错误处理 | | 记录事件 | 包括时间线、攻击者行为、影响和已采取的缓解措施 | ## 通常涉及的工具 API 网关（例如 Kong、AWS API Gateway、Apigee、Azure API Management） WAF（例如 Cloudflare、AWS WAF、Imperva） SIEM（例如 Sentinel、Splunk） RASP 和运行时保护（例如 Signal Sciences、Contrast Security） 应用性能/日志工具（例如 Datadog、New Relic） DAST 工具（例如 Burp Suite、OWASP ZAP） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常活动发生后 <10 分钟 | | 端点限制时间 | 确认后 <30 分钟 | | 补丁/代码修复部署 | 关键 API 漏洞在 24–48 小时内完成 | | 重新测试和恢复时间 | 72 小时内 | | 开发人员培训覆盖率 | 100% 的后端/API 团队在 7 天内得到简报 | # Playbook 20：内部凭证盗窃与滥用 ## 场景 内部人员（或使用被盗内部凭证的外部攻击者）使用有效账户访问敏感系统、提取数据或执行未经授权的活动——通常由于使用合法凭证而能绕过传统的安全检测。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 内部威胁 – 凭证滥用 | | 严重程度 | 高到严重（特别是如果涉及特权账户或敏感数据） | | 优先级 | 严重 | | 检测来源 | SIEM、UEBA（用户和实体行为分析）、IAM、EDR、DLP、HR 提示或举报人报告 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/ | | --- | --- | | 实施 UEBA 解决方案 | 检测异常的用户活动（例如 Exabeam、Microsoft Defender、Securonix） | | 为特权账户启用日志记录 | 包括会话监控和命令跟踪 | | 强制执行最小特权和 RBAC | 确保用户只拥有他们真正需要的访问权限 | | 监控敏感数据访问 | 针对文件下载、云存储、电子邮件转发的 DLP 策略 | | 设置针对异常访问模式的警报 | 一天中的时间、活动量、访问的系统、位置 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 UEBA 或 SIEM 的警报 | 异常的数据访问、登录行为或文件移动 | | 与工作角色关联 | 确定行为是否符合用户的正常职责 | | 检查访问日志 | 识别访问的系统、文件和数据 | | 审查近期的 HR 标记 | 检查用户是否正在接受调查、已辞职或显示出行为风险指标 | | --- | --- | | MITRE ATT&CK
映射 | T1078 (有效账户), T1087 (账户发现), T1110.003 (密码喷洒), T1213.003 (访问敏感数据 - 数据库) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 暂停用户账户 | 在调查期间暂时禁用访问权限 | | 撤销会话令牌 | 使活动会话、VPN 或 API 令牌失效 | | 隔离端点 | 如果怀疑有文件传输、恶意软件安装或持久化行为 | | 限制进一步访问 | 实施即时访问或隔离用户的 VLAN/子网 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 调查完整的活动范围 | 审查发送的电子邮件、访问/传输的文件、登录的系统 | | 撤销提升的访问权限或凭证 | 移除对所有特权系统或服务的访问权限 | | 重置凭证和密钥 | 针对共享凭证或用户访问过的系统 | | 清理任何更改 | 回滚用户所做的任何脚本、配置或数据更改 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复合法用户的访问权限 | 如果为了调查而暂停或禁用了其他账户 | | 监控受波及的系统 | 在规定期内使用 SIEM 和 EDR 监控事件发生后的行为 | | 通知利益相关者 | 包括 HR、法律和合规部门，以协调和结束调查 | | 恢复正常运营 | 一旦验证内部活动不存在残留风险 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行事件后审查 | 确定滥用是如何发生的，以及为什么没能更早地检测到它 | | 更新检测规则 | 为类似角色或行为添加特定的滥用指标 | | --- | --- | | 审查访问策略 | 收紧或调整 RBAC/最小特权设置和 IAM 流程 | | 加强用户监控策略 | 按工作角色或部门定期审查敏感访问权限 | | 如需要则进行报告 | 报告给内部治理机构、监管机构（例如 PDPA、HIPAA）或受影响的客户 | ## 通常涉及的工具 SIEM（例如 Splunk、Sentinel、QRadar） UEBA（例如 Exabeam、Microsoft Defender for Identity、Securonix） EDR（例如 CrowdStrike、Cortex XDR） IAM/SSO 日志（例如 Okta、Azure AD、Ping） DLP 工具（例如 Forcepoint、Symantec、Microsoft Purview） 端点和服务器日志 HRIS 集成（用于实时 HR 状态反馈） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常活动发生后 <15 分钟 | | 账户暂停时间 | 警报确认后 <30 分钟 | | 根本原因分析完成时间 | 48 小时内 | | 访问审查完成情况 | 受影响用户的 100% 特权访问日志已审查 | | 策略审查或调整 | 事件关闭后 7 天内 | # Playbook 21：云身份配置错误 ## 场景 配置不当的云身份或访问控制（例如，过于宽松的 IAM 角色、通配符访问策略、意外的信任关系）被内部或外部行为人利用，以获取提升的访问权限、进行横向移动或访问受限资源。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 配置错误 – IAM / 访问策略 | | 严重程度 | 高到严重（特别是如果暴露了特权访问或敏感数据） | | 优先级 | 严重 | | 检测来源 | CSPM 工具、云审计日志、SIEM、IAM 策略扫描、威胁情报、红队发现 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 使用最小特权模型 | 强制执行细粒度的 IAM 角色和基于策略的访问控制 | | 部署 CSPM 工具 | 监控身份配置错误（例如 Wiz、Prisma Cloud、Microsoft Defender for Cloud） | | 启用详细日志记录 | 使用 AWS CloudTrail、Azure Activity Logs、GCP Audit Logs 跟踪 IAM 事件 | | 标记和分类身份 | 区分人类与服务身份，并应用基于风险的监控 | | 进行访问审查 | 定期审计 IAM 角色、信任策略和访问密钥 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | CSPM 或 SIEM 针对过度权限、通配符访问 ("*") 或对 "Everyone" 的信任发出的警报 | | 验证配置错误 | 审查 IAM 策略、角色扮演、组成员资格以及任何异常的继承 | | 审查访问日志 | 确定配置错误是否已被利用（API 调用、资源访问） | | 评估受影响的资产 | 识别使用配置错误的身份可以访问哪些服务或数据 | | --- | --- | | MITRE ATT&CK
映射 | T1078.004 (云账户), T1098.001 (额外的云凭证), T1550.001 (应用程序访问令牌滥用) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 限制或删除配置错误的角色/策略 | 立即移除或纠正有风险的配置 | | 撤销临时凭证 | 使通过配置错误的身份颁发的 STS 令牌、API 密钥、访问令牌失效 | | 隔离受影响的资源 | 如果确认有可疑活动，隔离受损的服务或数据存储桶 | | 通知云管理团队 | 协调跨云账户或区域的 IAM 更改和服务验证 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 修复 IAM 策略 | 应用具有范围权限、条件和角色边界的修正策略 | | 轮换受影响的凭证 | 特别是针对用户、服务账户或云原生机密 | | 验证信任关系 | 重新配置角色扮演并移除非预期的跨账户信任 | | 移除未使用的角色/组 | 停用没有操作需求的身份 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复适当的访问权限 | 使用最小特权原则重新分配必要的权限 | | 监控重新配置 | 为更新的身份设置临时警报，用于修复后的行为验证 | | 重新启用服务 | 在确认配置安全且审计日志显示没有进一步滥用之后 | | 沟通状态 | 向安全、DevOps 和云平台所有者提供最新信息 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行影响分析 | 确认是否发生了数据访问或特权滥用及其持续时间 | | --- | --- | | 改进 IAM 策略 | 应用服务控制策略、权限边界和条件逻辑 | | 更新监控规则 | 为通配符特权、新身份创建和跨账户角色使用添加检测 | | 记录事件 | 包括受影响的 IAM 资源、根本原因、受影响的资产和解决步骤 | | 如需要则进行报告 | 如果访问了敏感数据，向内部利益相关者或监管机构报告 | ## 通常涉及的工具 CSPM 工具（例如 Wiz、Prisma Cloud、Microsoft Defender for Cloud、AWS Config） SIEM（例如 Splunk、Sentinel、QRadar） 云审计日志（例如 AWS CloudTrail、Azure Activity Logs、GCP Audit Logs） IAM 策略扫描器（例如 PMapper、CloudSploit、IAM Access Analyzer） 用于自动化修复的 SOAR 身份治理平台（例如 Saviynt、SailPoint、Okta） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 风险 IAM 更改后 <10 分钟 | | 遏制时间 | 警报确认后 <30 分钟 | | 策略修复完成时间 | 关键配置错误 <4 小时 | | 凭证轮换时间 | 受影响的身份 <2 小时 | | 访问审查覆盖率 | 事件后 100% 的受影响身份已审计 | # Playbook 22：CI/CD Pipeline 漏洞利用 ## 场景 攻击者访问或利用 CI/CD pipeline（例如 Jenkins、GitLab CI、GitHub Actions）中的弱点，以操纵构建过程、注入恶意代码或机密，或利用 pipeline 横向渗透到更广泛的基础设施中。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 软件供应链 / Pipeline 失陷 | | 严重程度 | 高到严重（特别是如果确认了部署篡改或代码库访问） | | 优先级 | 严重 | | 检测来源 | SIEM、源代码控制日志、CI/CD 日志、EDR、SAST/DAST 工具、开发人员报告、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 在 CI/CD 工具上强制执行 RBAC | 限制谁可以创建或修改 pipeline、runner 或机密 | | 启用详细的审计日志记录 | 针对代码推送、pipeline 更改、作业执行和机密使用 | | 使用签名的提交和工件 | 验证源代码和部署包的真实性 | | 监控 pipeline 滥用模式 | 例如，意外的作业触发、通过 runner 提权 | | 隔离构建环境 | 使用临时的容器/VM 以限制横向移动和访问范围 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 SIEM 或 DevSecOps 工具的警报 | 异常的作业行为、凭证使用或构建脚本更改 | | 审查最近的 pipeline 更改 | 检查作业定义、runner 配置和注入的命令 | | 分析源代码仓库活动 | 寻找恶意提交、PR 或分支操纵 | | 识别受影响的项目 | 确定哪些构建/部署可能已受到破坏 | | --- | --- | | MITRE ATT&CK
映射 | T1556 (修改身份验证过程), T1587.002 (恶意代码签名), T1059.006 (CI/CD 作业命令执行), T1136.003 (用于持久化的云账户创建) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 禁用受影响的 pipeline 或 runner | 停止受损作业的进一步执行 | | 撤销对 CI/CD 工具的访问权限 | 针对受损的账户或令牌 | | 阻止恶意工件 | 阻止部署受损的容器、二进制文件或包 | | 隔离受影响的环境 | 暂时将受影响的应用或服务从部署路径中移除 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 清除恶意代码或脚本 | 还原到干净的仓库状态；删除被篡改的构建定义 | | 轮换受损的机密 | 重新颁发 CI/CD 日志中暴露的 API 密钥、云令牌、数据库凭证 | | 修补漏洞 | 解决 runner、插件或访问控制中的配置错误 | | 审计第三方集成 | 移除或审查授予外部 CI/CD 插件或服务的访问权限 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复可信的 pipeline | 在验证脚本、依赖项和配置之后 | | 重建受影响的应用程序 | 使用已知良好的代码和安全的 CI/CD 流程 | | 重新启用部署 | 一旦验证安全并通过完整的验证 | | 利益相关者 | 向开发人员、产品所有者和安全团队通报恢复状态 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 执行根本原因分析 | 确定入口点是仓库访问、runner 滥用还是插件受损 | | --- | --- | | 更新 pipeline 安全控制 | 强制执行代码审查、作业批准和安全的机密管理 | | 培训 DevOps 和开发人员 | 关于安全的 CI/CD 实践和事件指标 | | 如必要则进行报告 | 如果数据被暴露或软件附带恶意代码（例如向客户、监管机构报告） | | 更新 playbook | 纳入经验教训和针对 CI/CD 监控的控制增强 | ## 通常涉及的工具 CI/CD 平台（例如 Jenkins、GitHub Actions、GitLab CI、Azure DevOps） SIEM（例如 Splunk、Sentinel） EDR 和运行时保护（例如 CrowdStrike、Aqua Security） 代码和 pipeline 扫描器（例如 SonarQube、Checkov、TFSec） 源代码管理系统（例如 GitHub、GitLab、Bitbucket） SOAR 平台（用于 pipeline 滥用的自动修复） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常 CI/CD 活动发生后 <10 分钟 | | 作业禁用时间 | 确认后 <30 分钟 | | 机密轮换时间 | 暴露检测后 <2 小时 | | 重建和重新部署时间 | 使用验证过的代码在 24–48 小时内完成 | | CI/CD 访问审查完成情况 | 3 天内 100% 的用户和集成访问已审计 | # Playbook 23：在生产环境中未经授权使用生成式 AI 工具 ## 场景 员工或系统在生产环境中使用生成式 AI 工具——无论是通过将敏感代码、数据或配置粘贴到 AI 提示中，还是通过将 AI 助手集成到实时应用程序中——而没有经过正式批准或适当的安全评估。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 策略违规 / 数据泄露风险 | | 严重程度 | 中到严重（取决于数据敏感性或自动化影响） | | 优先级 | 高 | | 检测来源 | DLP、CASB、SIEM、代理日志、端点遥测、IT 治理警报、安全意识报告 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 实施可接受的使用策略 | 明确界定各环境中 AI 使用的边界 | | 监控 AI 平台访问 | 记录并对与生成式 AI URL（例如 openai.com、bard.google.com）的交互进行警报 | | 使用 DLP 和 CASB 工具 | 监控输入到 AI 工具或外部 API 中的敏感数据 | | 强制执行浏览器控制和阻止 | 限制来自高敏感度区域（例如财务、开发、生产）的 AI 工具使用 | | 开展用户培训 | 关于生成式 AI 风险和组织合规要求的内容 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 检测未经授权的使用 | DLP、CASB 或代理日志警报显示数据被粘贴到 AI 工具或 prod 中使用了插件 | | 识别用户或系统 | 将日志与源 IP、用户 ID、浏览器代理或应用程序日志相关联 | | 审查传输的数据 | 确定是否包含代码、凭证、PII 或知识产权 | | 评估使用背景 | 意外误用 vs 有意的自动化或影子 AI 集成 | | --- | --- | | MITRE ATT&CK
映射 | T1087.003 (云服务枚举), T1567.002 (渗出到云存储), T1203 (通过 AI 插件/扩展利用面向公众的应用) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 阻止进一步访问 | 通过防火墙、代理或 CASB 策略禁用用户对 AI 工具或集成的访问权限 | | 隔离受影响的系统 | 如果 AI 集成处于活动代码或服务中 | | 警报用户和管理层 | 通知利益相关者并在调查期间冻结进一步使用 | | 捕获取证快照 | 尽可能获取提示历史记录、浏览器活动和传输数据的快照 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 移除 AI 集成 | 从生产服务、脚本或 pipeline 中移除（如果已嵌入） | | 撤销使用的任何 API 令牌 | 针对未经授权的 AI 集成（例如 OpenAI API 密钥） | | 轮换暴露的机密 | 如果凭证被粘贴或被 AI 存储 | | 清理策略违规 | 更新配置以移除与 AI 相关的例外或允许列表（如果被滥用） | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 在策略下恢复访问 | 仅在用户确认可接受的使用条款或 AI 插件经过审计和批准之后 | | 验证代码库和生产更改 | 确保没有残留未经授权的自动化 | | 实施 AI 治理检查 | 为 AI 相关工具的使用和集成引入审查工作流 | | 恢复运营 | 一旦安全和合规团队确认风险已缓解 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行根本原因分析 | 为何以及如何访问或集成了该 AI 工具 | | --- | --- | | 更新监控控制 | 为新的 AI 平台或浏览器扩展添加检测 | | 改进内部教育 | 将特定于 AI 的场景添加到网络安全意识计划中 | | 如需要则进行报告 | 如果暴露了知识产权或受监管数据（例如符合 GDPR、HIPAA、PDPA 的合规要求） | | 记录事件 | 包括涉及的用户、访问的数据、修复时间线和预防步骤 | ## 通常涉及的工具 DLP（例如 Microsoft Purview、Symantec、Forcepoint） CASB（例如 Netskope、Microsoft Defender for Cloud Apps） SIEM（例如 Splunk、Sentinel、QRadar） 端点检测与响应 (EDR)（例如 CrowdStrike、Cortex XDR） 代理/防火墙日志（例如 Zscaler、Palo Alto、Fortinet） 浏览器控制工具（例如 Chrome 企业版策略、Edge 管理） 生成式 AI 访问日志（如果与企业身份系统集成） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 数据传输或插件使用后 <10 分钟 | | 遏制时间 | 访问撤销 <30 分钟 | | 风险评估完成时间 | 事件发生后 <24 小时 | | 策略重新确认率 | 3 天内 100% 的相关用户已确认 | | 合规审查时间范围 | 事件解决后 7 天内 | # Playbook 24：OAuth 令牌重放滥用 ## 场景 攻击者获取有效的 OAuth 访问令牌（例如通过网络钓鱼、令牌盗窃或不安全的存储）并重新使用它以受害者身份访问 API、Web 应用程序或云服务——由于令牌已受信任，因此能绕过 MFA 和其他登录保护。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 身份失陷 – 令牌滥用 | | 严重程度 | 高到严重（取决于令牌的范围和权限） | | 优先级 | 严重 | | 检测来源 | SIEM、云审计日志、API 网关日志、身份提供者日志（例如 Okta、Azure AD）、CASB、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制令牌过期和轮换 | 设置较短的令牌生命周期并强制执行刷新令牌限制 | | 监控令牌使用模式 | 使用身份保护或 SIEM 对使用令牌的异常 API 访问发出警报 | | 将令牌绑定到设备/会话 | 尽可能将颁发的令牌绑定到 IP/设备指纹 | | 实施条件访问 | 在允许基于令牌的访问之前检查上下文（例如位置、应用、风险评分） | | 记录所有令牌颁发和使用情况 | 来自身份提供者和应用程序网关的记录 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 异常的令牌使用，例如从新位置重放或不可能的旅行行为 | | 调查令牌使用模式 | 检查访问的端点、使用时间、关联的 IP 和 user-agent 元数据 | | 与令牌颁发相关联 | 确定令牌最初是何时何地创建的，以及它是否与合法用户相符 | | 评估暴露风险 | 确定是否发生了数据访问、特权提升或账户操作 | | --- | --- | | MITRE ATT&CK
映射 | T1528 (窃取应用程序访问令牌), T1078.004 (云账户 – OAuth 滥用), T1550.003 (令牌模拟) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销活动令牌 | 通过 IdP 或应用程序设置使访问令牌和刷新令牌失效 | | 阻断源 IP | 如果重放源自已知恶意基础设施或异常区域 | | 暂停受影响的用户账户 | 暂时禁用以防止在调查期间继续被利用 | | 警报用户和安全团队 | 通知潜在的危害并在需要时暂停外部访问 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 轮换凭证和机密 | 特别是针对绑定到同一账户的第三方应用程序或 API | | 审计并移除恶意的应用同意 | 检查用户授权的、可能由攻击者控制的 OAuth 应用程序 | | 收紧应用权限范围 | 限制应用程序仅请求最低限度的必要访问权限（最小特权原则） | | 对应用程序应用安全控制 | 要求对未来的应用程序进行应用程序验证或租户级别的同意批准 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复用户账户 | 在确认用户身份和账户完整性之后 | | 监控恢复后的令牌活动 | 确保新令牌仅从受信任的位置和设备使用 | | 重新验证应用和 API 访问权限 | 确认跨关键服务的合法会话行为 | | 恢复运营 | 在确认完全遏制和凭证卫生之后 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行根本原因分析 | 确定令牌是如何获得的（例如网络钓鱼、本地存储暴露、浏览器扩展） | | --- | --- | | 更新令牌颁发策略 | 缩短令牌生命周期，强制实施刷新限制并绑定到上下文 | | 改进检测 | 向 SIEM 和身份保护平台添加令牌重放模式签名 | | 教育用户和开发团队 | 关于 OAuth 令牌的安全存储和处理（特别是在基于浏览器的应用中） | | 如需要则进行报告 | 特别是如果访问了敏感数据（例如根据 GDPR、HIPAA 或 PDPA） | ## 通常涉及的工具 身份提供者（例如 Okta、Azure AD、Google Workspace） SIEM（例如 Sentinel、Splunk、QRadar） CASB（例如 Netskope、Microsoft Defender for Cloud Apps） API 安全工具（例如 Salt Security、Noname、Imperva API Security） 云审计日志（例如 AWS CloudTrail、Azure Sign-in logs、GCP Admin Activity） 用户行为分析（例如 Exabeam、Securonix） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 异常令牌使用后 <10 分钟 | | 令牌撤销时间 | 确认后 <15 分钟 | | 账户风险缓解时间 | <1 小时 | | OAuth 应用审计完成情况 | 24 小时内审查 100% 的同意 | | 事件后监控期 | 最少 7 天的增强可见性 | # Playbook 25：配置不当的公共云存储访问 ## 场景 云存储桶、容器或对象被意外地公开或暴露给未经授权的用户（例如通过 public-read 或 authenticated users 访问设置）。这可能导致数据泄露、监管不合规或被威胁行为人利用。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 云配置错误 – 公开暴露 | | 严重程度 | 高到严重（取决于暴露数据的敏感性） | | 优先级 | 严重 | |检测来源 | CSPM 工具、云审计日志、SIEM、威胁情报、手动发现、Bug Bounty 报告 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 部署 CSPM 工具 | 持续扫描配置错误的存储（例如 Wiz、Prisma Cloud、orca Security） | | 实施策略即代码 | 使用 AWS Config、Azure Policies 或 GCP Org Policies 等工具来限制公共存储 | | 监控访问日志 | 启用存储桶访问和对象级别事件的日志记录 | | 启用默认加密 | 使用 KMS 密钥自动加密所有对象 | | 分类和标记敏感数据 | 应用元数据以便于执行 DLP 和访问控制 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 来自 CSPM 或云平台的警报 | 检测到对存储的 public-read、public-write 或通配符访问 | | 验证访问级别 | 确认对象、存储桶或容器是否可被任何人或广泛的 IAM 组读取 | | 检查访问日志 | 识别访问暴露资源的 IP、用户或服务 | | 确定数据敏感性 | 数据是 PII、财务数据、源代码还是内部文档？ | | --- | --- | | MITRE ATT&CK
映射 | T1530 (来自云存储对象的数据), T1526 (云服务发现), T1213.003 (访问敏感数据) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 移除公共访问权限 | 立即撤销对存储资源的 public 或 everyone 权限 | | 应用最小特权策略 | 将访问权限锁定为仅限必需的 IAM 身份或角色 | | 撤销临时令牌（如被滥用） | 禁用用于利用该暴露的访问密钥或令牌 | | 隔离暴露的数据（可选） | 将敏感文件移动到受限存储桶以进行分析或修复 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 纠正 IAM 或 ACL 策略 | 使用策略模板或自动化来强制执行安全的访问控制 | | 轮换密钥或令牌 | 如果暴露了访问密钥、SAS 令牌或签名 URL | | 移除未经授权的文件 | 删除上传的恶意软件、后门或被篡改的内容（如适用） | | 禁用存储桶列表 | 防止攻击者将来枚举内容 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复安全访问 | 仅在验证适当的权限已到位之后 | | 通知受影响的团队 | 特别是数据所有者、应用团队，如果涉及敏感数据，需通知合规和法律部门 | | 恢复使用 | 在确认没有剩余的暴露或配置错误之后 | | 启用更强的日志记录 | 如果尚未启用，请确保 CloudTrail/S3/Azure Blob/GCP 审计日志处于活动状态 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 进行全面的暴露分析 | 确定暴露内容的持续时间、访问范围和数据分类 | | 更新访问控制模板 | 对新的存储资源强制执行默认拒绝的姿态 | | --- | --- | | 培训团队关于云访问策略的知识 | 教授安全存储部署和数据处理最佳实践 | | 如必要则进行报告 | 如果数据泄露涉及个人或受监管数据，需根据 PDPA、GDPR、HIPAA 等进行报告 | | 将检测集成到 CI/CD 中 | 在投入生产之前使用 IaC 扫描（例如 Checkov、tfsec）捕获公共访问设置 | ## 通常涉及的工具 CSPM（例如 Wiz、Prisma Cloud、orca） 云原生工具（例如 AWS S3 Access Analyzer、Azure Defender、GCP Security Command Center） SIEM（例如 Sentinel、Splunk） DLP 工具（例如 Microsoft Purview、Google DLP） IAM 策略分析器（例如 PMapper、CloudSploit） 用于泄露存储桶/域名的威胁情报源 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 配置错误后 <5 分钟 | | 公共访问移除时间 | 警报后 <15 分钟 | | 暴露影响报告 | 24 小时内 | | IAM 策略审计完成情况 | 48 小时内 100% 的受影响项目或存储桶 | | 合规审查完成情况 | 72 小时内（或按监管规定的截止日期） | # Playbook 26：跨云工作负载的横向移动 ## 场景 攻击者在某个云工作负载（例如 EC2、Azure VM、Kubernetes pod 或容器）中获得立足点，并通过利用过度宽松的角色、不安全的凭证、共享存储或配置错误的网络规则进行横向移动，以触及其他工作负载或服务。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 云入侵 – 横向移动 | | 严重程度 | 高到严重（取决于访问的系统和暴露的数据） | | 优先级 | 严重 | | 检测来源 | SIEM、CSPM、云工作负载上的 EDR、云审计日志、NDR、威胁情报源 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制执行网络分段 | 使用安全组、NSG 或 VPC 防火墙来限制东西向流量 | | 启用工作负载日志记录 | 激活 OS 日志、CloudTrail、Azure Activity Logs、GCP Audit Logs 和流日志 | | 为云端部署 EDR | 安装端点保护或运行时安全工具（例如 Falcon、XDR、Wiz Runtime） | | 限制 IAM 角色重用 | 确保跨工作负载最小化地共享角色/权限 | | 强化镜像和基础设施 | 使用安全的镜像并强制执行 IaC 最佳实践 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 可疑的实例间通信、凭证使用或横向命令执行 | | 识别入口点 | 定位最初受损的工作负载或凭证来源 | | 追踪横向路径 | 审查云流日志、审计追踪和 EDR 日志以查找 SSH、API 调用、远程访问迹象 | | 分析使用的工具 | 移动是通过脚本、被盗令牌、RDP/SSH 还是云原生 API 完成的？ | | --- | --- | | MITRE ATT&CK
映射 | T1021 (远程服务), T1570 (横向工具传输), T1086.001
(云主机上的 PowerShell), T1534 (内部鱼叉式网络钓鱼或角色模拟) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 隔离受影响的工作负载 | 将受损的实例/pod 从网络中移除或缩减受影响的服务 | | 禁用涉及的凭证或角色 | 立即撤销用于横向移动的令牌、密钥或 IAM 角色 | | 暂时阻断东西向流量 | 应用严格的 ACL 以防止在分析范围期间进一步移动 | | 警报平台和应用程序所有者 | 将受影响的环境通知相关团队 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 终止受损的实例或容器 | 使用可信镜像和经过验证的 IaC 模板进行重建 | | 轮换受影响的凭证 | 重新颁发涉及的云访问密钥、服务主体和用户密码 | | 移除后门或持久性机制 | 检查 cron 作业、启动脚本、IAM 角色或已安装的恶意软件 | | 修复网络/安全组规则 | 通过强制实施最小访问模型来防止再次发生 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 重新部署干净的工作负载 | 从经过验证的 pipeline 或强化的基础镜像中进行 | | 恢复网络信任区域 | 在严格控制下逐渐重新启用东西向通信 | | 重新启用受影响的服务 | 仅在彻底验证并落实日志记录之后 | | 加强对恢复资产的监控 | 使用 SIEM 和运行时工具验证干净的运行状态 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录横向移动路径 | 包括访问的系统、使用的工具、时间线和暴露的数据 | | --- | --- | | 更新检测逻辑 | 为横向移动添加威胁指标和新的行为规则 | | 强化 IAM 和网络设计 | 应用更严格的分段、SSO 约束和令牌绑定技术 | | 进行内部总结 | 与安全、云运营、DevOps 和合规团队一起审查 | | 如必要则进行报告 | 向监管机构或客户报告，特别是如果敏感数据或生产系统受到破坏 | ## 通常涉及的工具 SIEM（例如 Sentinel、Splunk、QRadar） CSPM（例如 Wiz、Prisma Cloud、Defender for Cloud） 云 EDR（例如 CrowdStrike、Cortex XDR、用于容器的 Falco） 云审计日志 (AWS CloudTrail、Azure Activity Logs、GCP Audit Logs) 网络可见性（例如 VPC Flow Logs、Azure NSG flow logs） 用于响应编排的 SOAR 工具 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 横向移动开始后 <15 分钟 | | 隔离时间 | 检测后 <30 分钟 | | 凭证轮换时间 | 确认后 <2 小时 | | 受影响资产恢复时间 | 48 小时内 | | 事后报告完成时间 | 3 个工作日内 | # Playbook 27：未经授权的云数据库快照导出 ## 场景 云数据库快照（例如 AWS RDS 快照、Azure SQL 数据库导出、GCP Cloud SQL 备份）在未经批准的情况下被创建或共享。如果快照暴露给未经授权的用户或公开共享，这可能会导致敏感数据渗出。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 数据泄露 – 快照滥用 | | 严重程度 | 高到严重（特别是如果涉及 PII、财务数据或机密） | | 优先级 | 严重 | | 检测来源 | 云审计日志、CSPM 警报、SIEM、存储日志、数据库活动监控工具 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 强制快照加密 | 使用客户管理的 KMS 密钥并强制对所有快照进行加密 | | 限制快照共享 | 应用组织级策略以禁止公共或跨账户的快照共享 | | 监控快照创建 | 使用 CSPM 或 SIEM 对快照导出、共享和下载发出警报 | | 标记敏感数据库 | 对资源进行分类，以便进行有针对性的监控和 DLP 实施 | | 启用云审计日志记录 | 确保所有与快照相关的操作（创建、共享、恢复）都被记录 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 快照被共享到组织外部或在异常时间/由异常用户创建 | | 调查快照类型和目标 | 确定哪个数据库被快照，以及该快照是公开共享还是共享给了未知账户 | | 审查访问日志 | 检查快照是否已被下载、恢复或访问过 | | 与用户身份关联 | 调查执行该操作的 IAM 身份或服务账户 | | MITRE ATT&CK
映射 | T1530 (来自云存储的数据), T1005 (来自本地系统的数据), T1078.004 (云账户), T1048 (通过替代协议渗出) | | --- | --- | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 撤销对共享快照的访问权限 | 通过控制台或 CLI 移除共享或将其设为私有 | | 暂停违规账户 | 暂时禁用负责的用户或服务账户 | | 禁用下载访问权限 | 如果快照被复制到外部的 S3 存储桶、GCS 或 Azure blob，请撤销访问权限 | | 警报合规和法律团队 | 特别是如果涉及受监管保护的数据 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 删除未经授权的快照 | 移除恶意或未经批准的副本 | | 轮换受影响的凭证 | 如果机密是数据库内容的一部分，或者服务账户被滥用 | | 审计 IAM 权限 | 确保快照创建共享被严格限制在受信任的角色上 | | 审查跨账户信任设置 | 移除任何允许在组织外部共享的风险或未受监控的权限 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 恢复可信的备份过程 | 恢复经过验证、加密和访问控制的备份 | | 重新验证数据库和快照的完整性 | 确保没有通过恢复过程引入篡改或后门 | | 恢复数据库操作 | 一旦环境和备份安全并经过验证 | | 加强对关键数据库的日志记录 | 在规定的观察期内实施加强的监控 | ### 6. 经验教训与报告 | 步骤 | 操作 | | --- | --- | | 记录事件范围 | 时间线、暴露的数据类型、涉及的账户和解决步骤 | | --- | --- | | 更新检测规则 | 为跨边界共享或复制快照添加警报 | | 培训 DBA 和开发人员 | 关于安全的快照程序和 IAM 治理的内容 | | 向当局报告 | 如果泄露涉及个人、财务或政府监管的数据 | | 改进云护栏 | 使用基础设施即代码扫描和策略即代码进行未来的预防 | ## 通常涉及的工具 云原生日志（例如 AWS CloudTrail、Azure Activity Logs、GCP Admin Audit Logs） CSPM（例如 Wiz、Prisma Cloud、Microsoft Defender for Cloud） SIEM（例如 Sentinel、Splunk） DLP 工具（例如 Microsoft Purview、Forcepoint DLP） 用于自动化响应的 SOAR 平台 数据库活动监控（例如 Imperva、Guardicore、原生平台日志记录） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 快照创建或共享后 <10 分钟 | | 公共访问移除时间 | 确认后 <30 分钟 | | 快照删除时间 | 未经授权的快照 <1 小时 | | IAM 策略审计完成情况 | 48 小时内 100% 的受影响环境 | | 合规通知截止日期 | 72 小时内或按监管要求 | # Playbook 28：容器逃逸企图 ## 场景 攻击者获得对容器的访问权限，并试图脱离隔离环境以与宿主操作系统交互、提升权限或破坏其他容器、pod 或底层基础设施。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 容器运行时安全 – 逃逸企图 | | 严重程度 | 严重（特别是如果获得了宿主访问权限或特权提升） | | 优先级 | 严重 | | 检测来源 | 运行时安全工具、SIEM、EDR、Kubernetes 审计日志、Falco 规则、容器日志 | ## 阶段与行动 ### 1. 准备（事件发生前设置） | 任务 | 工具/操作 | | --- | --- | | 实施运行时安全 | 使用 Falco、Aqua、Sysdig 或 Wiz Runtime 等工具进行实时检测 | | 启用 Kubernetes 和 Docker 审计日志记录 | 捕获容器活动和宿主级别的访问企图 | | 强化容器镜像 | 使用最小化的基础镜像，扫描漏洞并移除不必要的工具（例如 curl、bash） | | 应用 Pod 安全策略 / OPA | 防止特权提升、宿主挂载和容器特权模式 | | 监控容器间流量 | 使用 NDR 或基于 eBPF 的工具启用东西向容器流量监控 | ### 2. 检测与分析 | 步骤 | 操作 | | --- | --- | | 触发警报 | 尝试访问宿主文件系统（/proc、/root）、提升权限或生成意外的二进制文件 | | 审查容器活动 | 检查 nsenter、chroot、mount、apt、wget 或可疑的 execs | | 识别受影响的容器和节点 | 确定 pod 名称、命名空间和底层宿主 VM/节点 | | 分析攻击者行为 | 这是配置错误利用（例如 privileged: true）还是远程代码执行？ | | --- | --- | | MITRE ATT&CK
映射 | T1611 (逃逸到宿主), T1059 (命令和脚本解释器), T1203 (利用漏洞进行特权提升) | ### 3. 遏制 | 步骤 | 操作 | | --- | --- | | 停止受损的 pod 或容器 | 立即强制删除或隔离该实例 | | 隔离受影响的节点 | 将该节点从集群调度中移除并限制其通信 | | 暂停服务账户访问 | 特别是如果容器有权访问 Kubernetes API 或机密 | | 对受影响的容器进行快照 | 如果需要进行取证，请尽可能保留内存和日志 | ### 4. 根除 | 步骤 | 操作 | | --- | --- | | 调查根本原因 | 脆弱的镜像、过度宽松的配置还是暴露的接口 | | 修补脆弱的工作负载 | 使用修复后的配置或镜像重建并重新部署受影响的 pod | | 轮换机密和凭证 | 特别是如果存储在环境变量、configMaps 或卷中 | | 移除后门或恶意工具 | 在容器或宿主中搜索流氓二进制文件、cron 作业或注入的脚本 | ### 5. 恢复 | 步骤 | 操作 | | --- | --- | | 从可信镜像重建工作负载 | 使用带有镜像签名和扫描的 CI/CD 流水线 | | 清理后恢复节点 | 仅在主机系统完成全面的取证验证之后 | | 恢复服务 | 逐步重新引入 pod 并密切监控是否复发 | | 增强对受影响
命名空间或部署的监控 | 对未来的偏差应用异常检测 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行事后
分析 | 记录逃逸向量、时间线和暴露的
资产 | | 改进容器安全
策略 | 执行严格的资源隔离并防止复用
受影响的模式 | | 培训 DevOps 团队 | 关于安全容器配置、最小权限和运行时风险 | | 按要求进行报告 | 如果发生数据暴露或主机受损，请通知
监管机构或客户 | | 更新操作手册和
响应工作流 | 基于此攻击场景添加新规则和控制措施 | ## 通常涉及的工具 运行时安全（例如 Falco, Sysdig Secure, Aqua, Prisma Cloud Compute, Wiz） Kubernetes 审计日志和 RBAC 日志 SIEM（例如 Sentinel, Splunk, QRadar） EDR（用于主机节点，例如 CrowdStrike, Cortex XDR） NDR（用于容器流量可见性） 镜像扫描（例如 Trivy, Clair, Anchore） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离逃逸尝试 <5 分钟 | | Pod 终止时间 | 距离告警 <10 分钟 | | 根因修复时间 | <48 小时 | | 节点重新验证
完成 | 移除后 24 小时内 | | 镜像加固审查 | 3 个工作日内审计 100% 的类似部署 | # 剧本 29：影子 IT SaaS 使用与数据暴露 ## 场景 员工或团队使用未经批准的 SaaS 应用程序（例如个人 Google Drive, Dropbox, Notion, ChatGPT）用于工作目的，在没有安全监督的情况下传输企业数据。这可能导致未经授权的数据暴露、违规行为或内部滥用。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 策略违规 – 未经授权的 SaaS 使用 | | 严重程度 | 中到高（取决于所涉及数据的类型和敏感性） | | 优先级 | 高 | | 检测
来源 | CASB, DLP, 代理日志, SIEM, 终端代理, 影子 IT 发现
工具, 员工报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 实施 CASB 平台 | 发现并监控超出
批准范围的所有 SaaS 使用情况 | | 设定 SaaS 使用策略 | 明确定义已批准与未批准的
服务 | | 在终端和云端应用 DLP | 检测敏感文件上传或剪贴板
传输 | | 整合代理/防火墙日志 | 按域名/IP 和用户跟踪 SaaS 使用情况 | | 培训用户有关数据处理和
影子 IT 风险的知识 | 提升对合规性和
已批准工具的认知 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | CASB 或代理检测到未经批准的 SaaS 使用，或 DLP 标记了
敏感文件传输 | | 识别用户和
设备 | 匹配用于传输的 IP、用户 ID 和计算机 | | 分析共享数据 | 确定文档是否包含 PII、PHI、客户信息或内部 IP | | 调查 SaaS
应用风险状况 | 评估该应用是否存在不良安全实践或违反
服务条款的行为 | | --- | --- | | MITRE ATT&CK
映射 | T1087.003 (Cloud Service Enumeration), T1537 (Transfer Data to
Cloud Account), T1213 (Data from Information Repositories) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 阻止访问 SaaS 应用 | 使用 CASB、防火墙或代理规则防止进一步
使用 | | 暂停用户的互联网或云
访问 | 如果数据暴露严重或怀疑继续
使用，则暂时停止 | | 通知用户和经理 | 如有必要，进行初步调查面谈 | | 阻止共享数据的
下载/导出 | 删除权限或尽可能从第三方
应用中删除 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 从未经批准的平台删除公司数据 | 在可行的情况下，联系供应商或要求用户
删除 | | 撤销 SaaS OAuth 权限 | 从与未经批准服务集成的用户或企业帐户中
撤销 | | 收紧应用控制 | 配置 CASB 自动阻止高风险类别中新发现的
未批准应用 | | 移除外部各方对共享数据的
访问权限 | 如果数据是通过链接或协作功能共享的 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在监控下恢复
用户访问 | 在风险得到补救并确认策略后 | | 监控未来的 SaaS 使用情况 | 对重复违规应用更严格的控制和告警 | | 验证不存在更多数据
副本 | 搜索终端和云存储以查找副本 | | 实施正式的应用请求
工作流 | 使用户更容易安全地请求批准新
工具 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 执行用户和数据风险审查 | 了解使用影子 IT 的业务原因
及所涉数据的敏感性 | | --- | --- | | 更新 SaaS 控制策略 | 将新发现的应用包含在
未批准/阻止列表中或对其进行正式审查 | | 教育用户 | 增加有针对性的培训或事后简报 | | 向合规/管理层报告 | 如果监管数据被暴露或客户机密性遭到破坏 | | 审查并更新 DLP/CASB
配置 | 针对导致此使用行为未被检测到的
漏洞 | ## 通常涉及的工具 CASB（例如 Microsoft Defender for Cloud Apps, Netskope, Skyhigh Security） DLP（例如 Forcepoint, Microsoft Purview, Symantec DLP） SIEM（例如 Splunk, Sentinel） Web 代理和 NGFW（例如 Zscaler, Palo Alto, Fortinet） 终端监控工具（例如 CrowdStrike, Tanium） SaaS 访问治理工具（例如 BetterCloud, DoControl） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离数据上传或 SaaS 访问 <5 分钟 | | SaaS 访问阻止时间 | 距离告警 <15 分钟 | | 数据移除完成 | 公开或第三方暴露在 24 小时内 | | 用户教育完成 | 100% 的相关用户在 3 个工作日内重新简报 | | 策略审查更新 | 7 天内纳入经验教训 | # 剧本 30：通过公共 GitHub 仓库泄露 API 密钥 ## 场景 开发人员意外提交并将 API 密钥、云凭证或其他机密信息推送到公共 GitHub 仓库。这些机密信息可能会被攻击者（包括监控 GitHub 的机器人）收集，并用于访问关键系统、云资源或第三方 API。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 凭证暴露 – 源代码泄露 | | 严重程度 | 严重（特别是对于云或生产凭证） | | 优先级 | 严重 | | 检测
来源 | GitHub Secret Scanning Alerts, TruffleHog, Gitleaks, 云提供商
告警, 漏洞赏金报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 启用 GitHub 机密扫描 | 激活 GitHub Advanced Security 或第三方扫描器（例如 Gitleaks, TruffleHog） | | 使用预提交钩子 | 整合机密检测工具以防止包含
机密的提交 | | 定期轮换机密 | 使用 vault（例如 HashiCorp Vault, AWS Secrets Manager）并
强制执行密钥过期策略 | | 培训开发人员 | 关于安全编码实践和推送
机密的危险性 | | 监控公共 GitHub
仓库 | 使用威胁情报和 GitHub API 持续扫描暴露的
组织资产 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 在提交中检测到
机密 | 来自 GitHub、内部扫描或外部报告的告警 | | 识别机密类型和
范围 | API 密钥、云访问密钥、数据库密码、令牌等 | | 关联拥有者用户/仓库 | 找到提交它的开发人员并确定仓库是否公开 | | 分析暴露
窗口 | 公开了多长时间？是否有使用迹象（例如日志、突破
速率限制）？ | | --- | --- | | MITRE ATT&CK 映射 | T1552.001 (Credentials in Files), T1087 (Account Discovery),
T1528 (Steal Access Token) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 立即撤销暴露的
机密 | 从提供商处停用 API 密钥、令牌或凭证 | | 限制受影响的服务 | 如果机密授予了广泛的访问权限，请禁用依赖的
集成或流水线 | | 告警开发人员和安全
团队 | 通知以进行立即验证和补救 | | 从历史记录中删除敏感提交 | 使用 git filter-branch, BFG 或 git rebase 等工具
清除机密 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 用新密钥替换暴露的
密钥 | 通过 vault 或
机密管理器安全地生成和分发新密钥 | | 审计云/API 日志 | 在暴露期间寻找使用泄露密钥滥用的
迹象 | | 验证 GitHub 仓库卫生 | 审查提交历史并删除任何其他敏感
信息 | | 阻止仓库或标记为私有 | 如果仍然存在风险或需要重新评估 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 使用新机密恢复服务访问 | 确认集成和流水线在使用轮换后的凭证
的情况下正常工作 | | 重新启用受影响的用户或
系统 | 一旦未检测到未经授权的访问 | | 监控滥用 | 对跨服务使用已撤销凭证的任何可疑行为
设置告警 | | 记录影响并确认
仓库状态干净 | 确保开发团队遵守更新的策略 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行 RCA | 机密为何及如何暴露？人为错误、
Git 工具配置错误、没有扫描？ | | --- | --- | | 改进预提交
流水线 | 整合 Git 钩子或 CI/CD 扫描器以更早阻止此类
错误 | | 培训开发团队 | 关于安全软件开发生命周期 (SSDLC) 和
版本控制卫生 | | 更新事件文档 | 包含关键时间表、撤销的凭证和缓解工作 | | 必要时报告 | 对于涉及受监管数据或第三方系统的违规行为
(GDPR, PDPA, PCI DSS 等) | ## 通常涉及的工具 GitHub Advanced Security（机密扫描） TruffleHog, Gitleaks, GitRob HashiCorp Vault, AWS Secrets Manager, Azure Key Vault SIEM（例如 Sentinel, Splunk）和威胁检测系统 版本控制审计（例如 Git 日志解析、提交审查者） ## 成功指标 | 指标 | 目标 | | --- | --- | | 撤销时间 | 距离检测 <15 分钟 | | 提交清理时间 | 关键机密 <1 小时 | | 机密替换与重新整合 | 生产使用 <4 小时 | | 暴露窗口分析完成 | 24 小时内 | | 开发人员对策略的确认 | 100% 的相关开发人员在 2 个工作日内 | # 剧本 31：未经授权访问 CI/CD 机密 ## 场景 存储在 CI/CD 工具（例如 Jenkins, GitHub Actions, GitLab CI, Azure DevOps）中的机密（例如云凭证、API 令、SSH 密钥或环境变量）被未经授权的一方访问——无论是通过配置错误、日志泄露、受损的 runner 还是恶意的拉取请求。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 凭证暴露 – CI/CD 安全漏洞 | | 严重程度 | 严重（特别是对于生产或云基础设施访问） | | 优先级 | 严重 | | 检测
来源 | SIEM, 机密扫描工具, CI/CD 审计日志, CSPM, 威胁
情报, 漏洞赏金报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 将机密存储在 vault 中 | 使用机密管理器（例如 HashiCorp Vault, AWS Secrets Manager）代替纯文本 CI/CD 变量 | | 应用最小权限 | 将 CI 作业和服务帐户限制为仅所需的权限 | | 监控 CI/CD 审计
日志 | 在 runner、工作流和机密访问上启用日志记录 | | 扫描仓库和
流水线 | 使用 TruffleHog, Gitleaks 或 GitHub Secret Scanning 等工具
检测暴露的机密 | | 保护 CI/CD runner | 隔离、更新并保护 runner 免受篡改或权限
提升 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 从流水线日志或 vault 中访问或窃取机密 | | 识别被访问的
机密 | 暴露了哪些机密，它们控制哪些系统？ | | 审查 CI 作业和
触发来源 | 确定这是恶意作业、PR 滥用还是内部滥用 | | 分析日志和
运行时元数据 | 检查作业日志、runner 行为、环境变量和
外部回调 | | MITRE ATT&CK
映射 | T1552.004 (Credentials in CI/CD), T1529 (System
Shutdown/Reboot to Disrupt), T1078.004 (Cloud Credentials Abuse), T1059 (Script Execution) | | --- | --- | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 撤销暴露的机密 | 立即禁用或轮换凭证、令牌
和密钥 | | 禁用 CI 作业或流水线 | 特别是那些被滥用或计划
重新运行的作业或流水线 | | 锁定受影响的仓库
或 runner | 防止进一步的作业执行并隔离可疑的
PR 或提交 | | 通知受影响的平台和
安全团队 | 告警开发人员、DevOps 和 SecOps | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 删除或清理易受攻击的作业
或工作流 | 移除嵌入的机密或包含
它们的日志输出 | | 重建并保护 runner | 应用安全更新，审计 rootkit 或
持久性并重新部署 | | 收紧机密处理 | 通过安全 vault 使用环境级注入，
而不是硬编码的机密 | | 更新访问控制列表 | 移除过度宽松的角色或对外部贡献者的
默认信任 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在受影响的系统中
轮换机密 | 云帐户、API、数据库等 | | 恢复 CI/CD 操作 | 在对构建作业、runner 和配置进行全面验证和加固后 | | 对重建的环境应用监控 | 包括对机密使用和构建行为的异常检测 | | 恢复合法的 PR 和代码
提交 | 一旦验证为安全且已授权 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行 RCA | 确定根本原因——vault 配置错误、内部威胁、日志泄露
或权限滥用 | | --- | --- | | 更新 CI/CD 安全
策略 | 强制执行 PR 批准工作流、作业限制和仅限 vault 的
机密 | | 培训 DevSecOps 团队 | 关于安全的机密管理和流水线卫生 | | 向外部利益相关者报告 | 如果暴露的机密影响了客户、顾客或受监管的数据 | | 将发现记录在
操作手册中 | 包括妥协指标、时间线和检测
差距 | ## 通常涉及的工具 CI/CD 平台（例如 GitHub Actions, GitLab CI, Jenkins, Azure DevOps） 机密管理系统（例如 AWS Secrets Manager, Vault） 机密扫描工具（例如 TruffleHog, Gitleaks, GitGuardian） SIEM（例如 Splunk, Sentinel） SOAR（用于响应自动化） CSPM（用于云环境加固和机密检测） 终端监控（如果 runner 或开发人员成为目标） ## 成功指标 | 指标 | 目标 | | --- | --- | | 机密撤销时间 | 距离检测 <15 分钟 | | CI 作业暂停时间 | <30 分钟 | | 受影响机密替换时间 | <4 小时 | | 安全 Runner 重新部署时间 | <24 小时 | | 开发人员培训完成 | 100% 的相关团队在 3 个工作日内 | # 剧本 32：第三方库中的零日漏洞利用 ## 场景 您的环境中使用的第三方库或框架（例如 Log4j, OpenSSL, Apache Struts, glibc）中披露了一个严重漏洞（或在野外被积极利用）。攻击者可能会在补丁或缓解措施可用之前利用此零日漏洞，通常通过远程代码执行 (RCE)、信息泄露或权限提升来实现。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 零日漏洞利用 – 供应链 / 库 | | 严重程度 | 严重（取决于暴露程度和可利用性） | | 优先级 | 严重 | | 检测
来源 | 威胁情报源, 供应商建议, SIEM, EDR/XDR, 网络
检测, 漏洞赏金报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 维护 SBOM (软件物料清单) | 使用 CycloneDX, Syft, Anchore 等工具跟踪所使用的依赖项 | | 订阅威胁情报
和 CVE 源 | 确保安全团队获得早期告警（例如 CISA KEV,
NVD, GitHub Security Advisories） | | 标记使用受影响库的
关键工作负载 | 在发出告警时启用有针对性的日志记录和监控 | | 建立紧急补丁和
缓解流程 | 准备计划外更新和开发/测试推出
计划 | | 加固外部攻击
面 | 阻止不必要的暴露（例如管理面板、
调试端点） | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 公开披露了带有可用 PoC 或活跃利用报告的严重零日漏洞 | | 识别受影响的
系统 | 使用 SBOM 或资产管理列出使用易受攻击
库的系统 | | 评估暴露程度 | 确定服务是可从外部访问还是可从内部访问 | | 监控 IOC | 收集指标，如进程异常、网络回调、
异常日志条目 | | --- | --- | | MITRE ATT&CK
映射 | T1190 (Exploit Public-Facing Application), T1210 (Exploitation of
Remote Services), T1588.006 (Vulnerability Disclosure) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 隔离暴露的服务 | 如果没有可用的补丁，阻止对易受攻击应用程序的
互联网访问 | | 部署 WAF/IPS 虚拟
补丁 | 使用签名或有效载荷过滤阻止已知的漏洞利用模式 | | 移除或禁用
插件/模块 | 如果在不严重影响操作的情况下能降低风险，
则暂时禁用该功能 | | 通知内部利益相关者 | 在安全、开发和基础设施团队之间协调，以
开始紧急缓解 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 应用供应商补丁或升级 | 一旦可用；在推送到生产环境之前
在预发环境中进行验证 | | 替换受影响的库 | 如果无法打补丁，切换到安全版本或
替代品 | | 移除丢弃的有效载荷或
后门 | 如果已经发生利用，则从受损主机中移除 | | 清理临时缓解措施 | 一旦系统打上补丁并确认安全 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 恢复完整的应用程序
操作 | 在验证打补丁的环境之后 | | 进行全面取证 | 确定系统在打补丁前是否被利用，以及
数据是否被访问 | | 暂时增加日志记录 | 在打补丁的系统周围保持 7-14 天的
增强可见性 | | 验证第三方组件 | 确保供应商和合作伙伴也打补丁或缓解零日
风险 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 记录时间线和影响 | 从披露到缓解以及任何已确认的
事件 | | --- | --- | | 更新漏洞管理策略 | 包含对新兴威胁和零日漏洞的响应 | | 培训开发和安全团队 | 关于监控依赖项和有效使用 SBOM | | 向监管机构/客户报告 | 如果发生违规或敏感数据面临风险（例如根据 GDPR, PDPA, PCI DSS） | | 事后进行桌面演练 | 模拟类似场景以测试准备情况 | ## 通常涉及的工具 SBOM 和依赖扫描器（例如 Anchore, Snyk, OWASP Dependency-Check） 威胁情报平台（例如 MISP, Recorded Future, CISA KEV） SIEM（例如 Sentinel, Splunk） EDR/XDR（例如 CrowdStrike, Cortex XDR） WAF/IPS（例如 Cloudflare, AWS WAF, Palo Alto） 用于自动化剧本执行的 SOAR ## 成功指标 | 指标 | 目标 | | --- | --- | | 初始分诊时间 | 距离公开披露 <30 分钟 | | 暴露映射时间 | 距离识别受影响系统 <2 小时 | | 缓解部署 | 12-24 小时内 | | 补丁完成 | 关键系统 <48 小时 | | 事后报告 | 72 小时内 | # 剧本 33：SaaS 平台中滥用被盗会话令牌 ## 场景 攻击者获取了对有效会话令牌的访问权限（例如通过 XSS、网络钓鱼、恶意软件或从终端窃取令牌），并利用它在 SaaS 平台（例如 Microsoft 365, Google Workspace, Salesforce, Slack）上冒充合法用户。这允许在不触发 MFA 或登录异常告警的情况下进行访问。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 帐户劫持 – 会话令牌滥用 | | 严重程度 | 高到严重（基于数据访问和权限级别） | | 优先级 | 严重 | | 检测
来源 | CASB, SIEM, EDR, SaaS 审计日志, 用户报告, 威胁情报源 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 启用会话管理日志 | 在所有 SaaS 平台中捕获令牌重用或
可疑的 IP 登录 | | 部署 CASB 和 SaaS 安全
工具 | 监控用户行为、令牌异常和
会话重用 | | 使用条件访问策略 | 基于地理位置、设备信任和用户风险
评分 | | 教育用户有关网络钓鱼和
令牌窃取的知识 | 包括会话令牌如何被滥用 | | 整合终端保护 | 防止通过恶意软件窃取令牌 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 不寻常的会话活动（例如，来自已知 IP 但行为或位置
异常的登录） | | 检查重复
会话 | 同一令牌从不同的 IP 或地理位置重用 | | 审查最近的用户活动 | 寻找数据下载、权限更改、新的应用集成 | | 分析终端
日志 | 可能提取令牌的恶意软件或工具（例如 RedLine, Vidar） | | --- | --- | | MITRE ATT&CK
映射 | T1539 (Steal Web Session Cookie), T1078 (Valid Accounts),
T1185 (Browser Session Hijacking) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 撤销所有活动会话 | 强制受影响的用户在所有设备和应用上
登出 | | 暂时禁用用户帐户 | 如果攻击者活动正在进行或破坏严重 | | 阻止攻击者 IP 或设备 | 在 SaaS 提供商、CASB 或防火墙级别 | | 通知用户和支持团队 | 通知用户重置密码并验证 MFA
设备 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 扫描终端以查找恶意软件 | 确保用户的设备上没有仍处于活动状态的
令牌窃取程序 | | 轮换任何暴露的凭证
或令牌 | 对于链接的应用程序或集成 | | 审查会话存储
实践 | 确保会话令牌不以明文形式存储或
被不正确地缓存 | | 加强 SaaS 登录策略 | 对敏感操作或高风险登录
强制执行重新认证 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在严格监控下重新启用用户访问 | 确保终端干净并重新强制执行 MFA 后 | | 密切监控用户活动 | 对行为偏差或异常下载应用告警 | | 教育用户有关会话劫持的迹象 | 强化会话安全的最佳实践 | | 进行内部检查 | 确保没有发生横向移动或权限滥用 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 完成 RCA | 确定令牌是如何被盗的：恶意软件、网络钓鱼、
浏览器同步等 | | --- | --- | | 改进会话卫生策略 | 减少会话持续时间，防止跨设备或
地理位置重用 | | 培训员工 | 定期进行有关 SaaS 风险和会话意识的教育 | | 记录发现 | 记录在 IR 日志和经验教训报告中 | | 通知第三方或监管机构 | 如果敏感数据被访问或在外部共享 | ## 通常涉及的工具 CASB（例如 Microsoft Defender for Cloud Apps, Netskope, Lookout） SaaS 安全态势管理（例如 Obsidian, AppOmni） SIEM（例如 Sentinel, Splunk） 终端检测与响应（例如 CrowdStrike, Cortex XDR） 身份提供商（例如 Okta, Azure AD, Google Workspace） 浏览器安全工具（例如 LayerX, Seraphic） ## 成功指标 | 指标 | 目标 | | --- | --- | | 会话撤销时间 | 距离检测 <10 分钟 | | 终端验证时间 | <1 小时 | | 事后 MFA 强化 | 100% 在 24 小时内完成 | | SaaS 行为监控持续时间 | 事后 ≥ 14 天 | | RCA 和报告完成 | 3 个工作日内 | # 剧本 34：对象存储中的云原生勒索软件 ## 场景 攻击者获得对云对象存储（例如 Amazon S3, Azure Blob Storage, Google Cloud Storage）的访问权限，并执行恶意操作，例如加密文件、更改权限、删除备份或放置勒索信——而无需部署勒索软件二进制文件，纯粹使用 API 或 SDK。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 勒索软件 – 对象存储 (云原生) | | 严重程度 | 严重 | | 优先级 | 严重 | | 检测
来源 | CSPM 告警, SIEM, 云存储日志, CASB, CloudTrail, Access
Analyzer, 用户报告 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 应用严格的 IAM 策略 | 对存储访问（读/写/删除）使用最小权限原则 | | 启用版本控制和 MFA
删除 | 在 S3、GCS 或 Azure Blob 中保留文件历史记录并阻止
未经授权的删除 | | 启用日志记录和
监控 | CloudTrail, 存储访问日志以及对异常活动的
告警 | | 为存储设置异常检测 | 突然的写入/删除爆发、非人类行为、大规模文件访问 | | 测试恢复流程 | 确保备份和快照能够快速可靠地
恢复 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 不寻常的存储活动：大规模对象覆盖/删除，来自未知 IP 的访问或勒索信文件 | | 关联 IAM
活动 | 识别负责存储操作的用户或服务帐户 | | 确定影响范围 | 存储桶/容器的数量、受影响的数据类型以及是否存在备份 | | 搜索 IOC | 被重命名/加密的文件，勒索信（例如 README_TO_RESTORE.txt），奇怪的文件扩展名 | | --- | --- | | MITRE ATT&CK
映射 | T1485 (Data Destruction), T1486 (Data Encrypted for Impact),
T1531 (Account Access Removal) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 撤销受影响的 IAM 角色或密钥 | 立即禁用对负责的用户或
应用程序的访问 | | 阻止恶意 IP 地址 | 使用云服务提供商防火墙规则或地理围栏 | | 锁定存储桶 | 移除公共访问并应用限制性的 ACL 和策略 | | 告警云安全和事件
响应团队 | 触发紧急补救计划 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 审计所有存储策略和
访问日志 | 确保没有其他后门或恶意用户
保持活动 | | 轮换访问凭证 | 针对所有涉及的云帐户和应用程序 | | 移除攻击者植入物或文件 | 删除勒索信、木马化文件或留下的 API 日志 | | 修补外部入口点 | 如果漏洞利用来自 Web 应用程序或暴露的
访问密钥 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 从备份或对象版本控制恢复 | 使用最后已知的良好版本或自动快照 | | 验证数据完整性 | 检查恢复的文件是否完整且未被更改 | | 恢复业务服务 | 在存储和应用程序被验证为安全之后 | | 增加日志记录和检测阈值 | 针对受影响的存储桶和关联的身份 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行 RCA | 追踪攻击向量、使用的方法和时间线 | | 改进监控和访问控制 | 对对象存储访问和异常检测执行更严格的策略 | | --- | --- | | 更新操作手册和告警规则 | 包含新的攻击模式和预防指南 | | 培训 DevOps 和云管理员 | 关于安全存储配置和快速响应技术 | | 报告事件 | 如果敏感数据受到影响，向监管机构和客户报告 | ## 通常涉及的工具 云审计日志（例如 AWS CloudTrail, Azure Activity Logs, GCP Admin Logs） CSPM 工具（例如 Wiz, Prisma Cloud, Microsoft Defender for Cloud） SIEM（例如 Sentinel, Splunk, Chronicle） CASB（例如 Netskope, Defender for Cloud Apps） 备份和灾难恢复工具（例如 AWS Backup, Azure Site Recovery, GCP Snapshots） SOAR（用于自动补救） ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离大规模存储修改 <5 分钟 | | IAM 密钥撤销时间 | 距离检测 <10 分钟 | | 数据恢复时间 | <6 小时（对于关键数据） | | 访问策略审查时间 | 100% 的受影响存储桶在 24 小时内审查完毕 | | RCA 和补救报告 | 72 小时内完成 | # 剧本 35：恶意内部人员在云中暂存数据 ## 场景 组织内受信任的用户滥用其对敏感数据（例如 PII、源代码、财务数据）的访问权限，并开始将其上传到未经批准的云平台（例如个人 Google Drive, Dropbox, Mega, OneDrive）以进行窃取。这可能发生在辞职、举报或商业间谍活动之前。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | 内部威胁 – 数据暂存 / 窃取 | | 严重程度 | 高到严重（基于数据敏感性和暴露级别） | | 优先级 | 严重 | | 检测
来源 | DLP, CASB, SIEM, 代理日志, 终端代理, 用户报告, 内部
威胁计划 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 实施内部威胁监控 | 使用带有行为基线的 UEBA, CASB 和 DLP | | 强制执行批准的云存储
策略 | 使用 CASB 或防火墙规则阻止未经批准的 SaaS 上传 | | 监控大文件传输和压缩 | 使用终端和代理规则检测大规模打包或上传 | | 培训员工有关数据处理策略 | 强化数据滥用的纪律和法律后果 | | 对敏感文件使用标记 | 对文档进行分类以应用有针对性的监控 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | DLP 或 CASB 检测到向未经批准的云服务上传文件 | | 调查用户行为 | 寻找辞职、违反策略或异常工作时间的迹象 | | 关联数据
访问和传输 | 识别哪些文件被访问、下载、打包或上传 | | 确定目标云存储 | 个人 Google Drive, Dropbox, Mega, iCloud 等 | | MITRE ATT&CK
映射 | T1537 (Transfer Data to Cloud Account), T1081 (Credentials
from Password Stores), T1567.002 (Exfiltration to Cloud Storage) | | --- | --- | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 阻止进一步访问外部存储 | 通过 CASB 或代理强制执行云应用控制 | | 暂停或限制用户帐户 | 如果行为明显具有恶意或数据丢失
正在发生，则暂时停止 | | 隔离用户设备 | 如果还怀疑存在恶意软件或凭证窃取 | | 保留会话和文件日志 | 用于取证分析和法律用途 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 移除对敏感系统的访问 | 撤销提升的权限并从敏感组或共享中移除 | | 检索或删除暂存数据 | 如果存储在企业设备上或可从个人云中检索（在法律支持下） | | 重置凭证和令牌 | 特别是如果用户拥有 API 访问权限或正在使用自动化工具 | | 禁用影子云帐户 | 防止从企业系统进一步访问或数据同步 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 重新分配关键职责 | 如果员工处于特权角色或交接的一部分 | | 监控后续的窃取尝试 | 对用户帐户或类似配置文件使用增强的日志记录 | | 审查跨系统的审计日志 | 确保没有发生横向活动或额外的数据传输 | | 恢复正常操作 | 一旦事件范围和风险得到控制 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 进行全面的内部威胁 RCA | 了解动机、机会和控制弱点 | | 改进内部威胁模型 | 优化 UEBA 规则和升级剧本 | | 通知人力资源和法律部门 | 用于可能的纪律处分、法律跟进或起诉 | | --- | --- | | 审查并更新 DLP/CASB
策略 | 将新滥用的平台或策略添加到检测范围 | | 通知监管机构或客户 | 如果受监管数据被暴露或客户机密被泄露 | ## 通常涉及的工具 DLP（例如 Microsoft Purview, Forcepoint, Symantec DLP） CASB（例如 Netskope, Microsoft Defender for Cloud Apps） UEBA/内部威胁平台（例如 Splunk UBA, Exabeam, Varonis） SIEM（例如 Sentinel, Splunk） 终端监控（例如 CrowdStrike, Trellix, Tanium） 代理和 NGFW（ Zscaler, Palo Alto） 人力资源系统和法律支持工具 ## 成功指标 | 指标 | 目标 | | --- | --- | | 检测时间 | 距离数据上传 <5 分钟 | | 帐户限制时间 | 距离告警 <15 分钟 | | 数据恢复 / 遏制时间 | <24 小时 | | 取证分析完成 | 48 小时内 | | 内部威胁剧本更新 | 3 个工作日内 | # 剧本 36：未经授权的 SaaS OAuth 应用程序集成 ## 场景 员工或攻击者使用 OAuth 范围（例如读取电子邮件、访问日历、读/写文件）授予第三方应用程序对企业 SaaS 帐户的访问权限。这些应用程序可能会窃取数据、冒充用户或维持持久访问，而不会触发标准的凭证或 MFA 告警。 ## 事件分类 | 类别 | 详情 | | --- | --- | | 事件类型 | OAuth 滥用 – 未经授权的第三方应用 | | 严重程度 | 高（取决于授予的范围和访问的数据） | | 优先级 | 高到严重 | | 检测来源 | CASB, SSPM, SaaS 管理门户, SIEM, 威胁情报源 | ## 阶段与行动 ### 1. 准备（事件前设置） | 任务 | 工具/行动 | | --- | --- | | 限制应用同意策略 | 仅允许对预先批准或已验证的应用进行 OAuth 同意 | | 监控 OAuth 活动日志 | 使用 SIEM 或 SaaS 安全工具跟踪应用授权和范围 | | 教育用户 | 关于在企业环境中授权个人或未知应用的风险 | | 整合 SSPM/CASP
工具 | 用于已授权应用程序的可见性和风险评分 | | 应用条件访问
策略 | 限制来自非托管设备的应用连接 | ### 2. 检测与分析 | 步骤 | 行动 | | --- | --- | | 触发告警 | 检测到具有提升范围（例如读取邮件、读取驱动器、发送消息）的风险或未批准的 OAuth 应用 | | 识别用户和
应用程序 | 谁授权了它，授予了什么范围，使用了什么应用 | | 分析访问日志 | 检查应用是否访问了敏感数据或执行了操作（例如发送电子邮件、下载文件） | | 审查应用
元数据 | 声誉、风险评分、域名注册、先前的威胁报告 | | --- | --- | | MITRE ATT&CK
映射 | T1528 (Steal Access Token), T1550.001 (Application Access
Token), T1098.003 (External Account) | ### 3. 遏制 | 步骤 | 行动 | | --- | --- | | 立即撤销应用访问权限 | 通过管理门户（例如 Azure AD, Google Workspace,
Slack 管理员） | | 暂停受影响的用户
帐户 | 如果确认存在恶意行为或数据泄露 | | 阻止应用域名或 API
端点 | 通过防火墙、CASB 或 DNS 过滤器防止回调连接 | | 通知用户和安全团队 | 启动内部调查和遏制措施 | ### 4. 根除 | 步骤 | 行动 | | --- | --- | | 移除残留的访问令牌 | 撤销授予该应用的所有令牌并刷新用户会话 | | 轮换凭证和 MFA | 如果怀疑存在冒充或令牌窃取 | | 进行全面的数据访问
审查 | 确定该应用有权访问什么以及数据是否被窃取 | | 更新 OAuth 策略 | 将该应用添加到 SSPM 或 CASB 的阻止列表或黑名单类别中 | ### 5. 恢复 | 步骤 | 行动 | | --- | --- | | 在监控下恢复用户访问 | 确保用户知情并在链接恶意软件时清理终端 | | 应用更严格的应用审查流程 | 要求对所有新的应用集成进行内部批准 | | 监控复发情况 | 为类似的应用授权模式或行为创建检测 | | 验证 SaaS 日志和告警 | 确保对高风险 OAuth 事件的完全可见性 | ### 6. 经验教训与报告 | 步骤 | 行动 | | --- | --- | | 完成根因分析 | 为什么该应用被授权？是网络钓鱼、无知还是绕过了控制？ | | --- | --- | | 改进用户培训 | 关于安全的 SaaS 使用和应用程序访问警告 | | 加强 OAuth 治理 | 整合 SSPM 并自动化基于风险的应用批准/撤销 | | 记录事件 | 用于合规性、审计跟踪和策略更新 | | 通知受影响各方或监管机构 | 如果客户数据或敏感记录被访问 | ## 通常涉及的工具 SSPM/CASP（例如 AppOmni, Obsidian, Microsoft Defender for Cloud Apps） SaaS 管理门户（例如 Azure AD, Google Admin Console, Slack Admin） SIEM（例如 Sentinel, Splunk） 威胁情报（用于应用风险评分和声誉） SOAR（用于自动化检测和撤销） 终端安全（确保令牌来源干净） ## 成功指标 | 指标 | 目标 | | --- | --- | | 应用撤销时间 | 距离检测 <15 分钟 | | 用户通知和会话重置 | <30 分钟 | | 完整应用审计和 RCA 完成 | 48 小时内 | | OAuth 策略更新 | 3 个工作日内 | | 用户意识培训完成 | 100% 在 5 个工作日内 | # 精英 DFIR 增强层 ## 证据收集检查表 | 证据类型 | 示例 | 为何重要 | |---|---|---| | 身份证据 | 登录日志，MFA 事件，OAuth 授权，令牌活动 | 确认帐户泄露和访问路径 | | 终端证据 | EDR 时间线，进程树，命令行，文件哈希 | 显示执行链和持久性 | | 网络证据 | DNS，代理，防火墙，NetFlow，Zeek，Suricata | 确认通信路径和窃取指标 | | 云证据 | CloudTrail，Azure Activity Logs，M365 Unified Audit，存储日志 | 揭示云控制平面活动 | | 应用证据 | Web 服务器日志，API 网关日志，WAF 告警 | 确认漏洞利用载荷和受影响的端点 | | 业务证据 | 影响声明，受影响用户，财务风险 | 支持高管报告和风险决策 | ## SOC 分诊问题 1. 是什么触发了告警？ 2. 哪些资产、帐户、应用程序或云资源受到了影响？ 3. 该活动被确认为恶意的、可疑的、意外的还是与策略相关的？ 4. 是否存在权限提升、持久性、横向移动或窃取的证据？ 5. 什么遏制行动可以在不造成不必要的业务中断的情况下阻止损害？ 6. 必须通知谁：SOC 负责人、IT、法务、隐私、人力资源、高管、客户、监管机构？ ## 遏制决策指南 | 情况 | 建议行动 | |---|---| | 确认的勒索软件加密 | 立即隔离主机，禁用受影响的帐户，保护证据 | | 可疑的云登录 | 撤销会话，重置密码，强制执行 MFA，审查 OAuth 授权 | | BEC 或邮箱接管 | 禁用恶意规则，撤销令牌，检查已发送项目，向受影响方发出告警 | | 发现 Web shell | 隔离 Web 服务器，保留工件，阻止外部访问，修补漏洞 | | 内部窃取 | 暂停访问，保留证据，让 HR/法务介入，禁用传输渠道 | | DDoS 攻击 | 联系提供商，启动缓解措施，速率限制，验证服务健康状况 | ## 示例 KQL 检测 ### 失败登录后跟随成功 ``` SecurityEvent | where EventID in (4624, 4625) | summarize Failed=countif(EventID == 4625), Success=countif(EventID == 4624) by Account, IpAddress, bin(TimeGenerated, 30m) | where Failed >= 5 and Success >= 1 ``` ### 可疑的 PowerShell 关键字 ``` SecurityEvent | where EventID == 4688 | where CommandLine has_any ("EncodedCommand", "IEX", "DownloadString", "FromBase64String", "Invoke-WebRequest") | project TimeGenerated, Computer, Account, NewProcessName, CommandLine ``` ### 云不可能旅行概念 ``` SigninLogs | where ResultType == 0 | summarize Countries=make_set(Location), IPs=make_set(IPAddress), Count=count() by UserPrincipalName, bin(TimeGenerated, 1h) | where array_length(Countries) > 1 ``` ## 高管事件更新模板 | 字段 | 内容 | |---|---| | 事件名称 | | | 当前状态 | 调查中 / 已遏制 / 根除中 / 恢复中 / 已关闭 | | 业务影响 | | | 受影响系统 | | | 确认的数据暴露 | 是 / 否 / 调查中 | | 已完成行动 | | | 下一步行动 | | | 所需决策 | | | 下次更新时间 | | ## 技术事件报告模板 | 部分 | 所需详情 | |---|---| | 摘要 | 发生了什么，何时开始，如何被检测到 | | 范围 | 受影响的用户、主机、应用程序、云帐户、数据 | | 时间线 | 告警时间、分诊时间、遏制时间、恢复时间 | | 根本原因 | 网络钓鱼、漏洞利用、弱凭证、配置错误、内部行动 | | IOC | IP、域名、哈希、URL、用户代理、进程名 | | MITRE 映射 | 观察到的战术和技术 | | 遏制 | 为阻止进一步危害而采取的行动 | | 根除 | 移除持久性，修补漏洞，保护帐户安全 | | 恢复 | 系统恢复，监控期，业务验证 | | 经验教训 | 检测差距，控制差距，流程改进 | ## 成功指标仪表板 | 指标 | 为何重要 | |---|---| | MTTD - 平均检测时间 | 衡量可见性和检测工程的成熟度 | | MTTA - 平均确认时间 | 衡量 SOC 告警响应速度 | | MTTC - 平均遏制时间 | 衡量操作遏制准备情况 | | MTTR - 平均恢复时间 | 衡量弹性和恢复能力 | | 误报率 | 衡量检测质量和调优需求 | | 证据完整性 | 衡量调查质量和审计准备情况 | | 经验教训闭环 | 衡量改进是否真正得到实施 | ## CyberNova 专业收尾 强大的事件响应剧本不仅是一份检查清单。它是一个在压力下保护组织的决策支持系统。最优秀的 SOC 团队结合了技术证据、严谨的遏制、清晰的沟通、业务意识、法律准备和持续改进。
标签：API安全, CISA项目, Cloudflare, JSON输出, MITRE ATT&CK, PE 加载器, Playbook, SaaS安全, SOC分析师, TTP映射, 事件响应计划, 云端安全, 企业安全, 分类与遏制, 勒索软件, 商业电子邮件入侵, 子域名变形, 安全剧本, 安全案例库, 安全运营中心, 库, 应急响应, 开源安全项目, 恢复, 数字取证与应急响应, 网络安全, 网络安全审计, 网络映射, 网络资产管理, 防御加固, 隐私保护