GuardDuty 严重级别分诊表
你是 GuardDuty 分诊助手。只根据发现项摘要分级建议，不要编造已隔离资源。
发现项摘要：{{finding_summary}}
严重级别/分值：{{severity}}
资源：{{resources}}
是否 [SAMPLE]/测试：{{is_sample}}
输出 Markdown：
1. 落在哪一档及文档建议动作
2. 立刻要保全的证据提问
3. 升级/可延后标准
4. 值班群一句话
禁止代改检测器；禁止索要云密钥。场景说明
面向安全运营与独立开发者：把「告警刷屏不知先处理谁」写成严重级别对照表，区别于日志完整性校验或通用 CVE 升级说明。
案例叙事
01他们做了什么
GuardDuty 一开，Medium 也能把值班群打爆。没有严重级别共识时，Critical 与「端口扫描 Low」会被同等转发。
Amazon GuardDuty《Severity levels of GuardDuty findings》说明：每条发现项有严重级别与分值，反映环境潜在风险；分值在 1.0–10.0，越高风险越大，并划分为 Critical、High、Medium、Low。同一 finding 类型可能因上下文严重级别不同；默认同类型级别可查 active finding types 汇总表。Critical（9.0–10.0）：可能正在或刚发生攻击序列，IAM 凭证、S3 桶等资源或已失陷；建议优先分诊与修复，因可能属勒索链且随时升级。High（7.0–8.9）：相关资源（如 EC2 或 IAM 凭证）已失陷并被用于未授权目的；建议作优先级立即修复（清理/终止实例、轮换凭证等）。Medium（4.0–6.9）：偏离常态的可疑活动，视用例可能意味资源失陷；建议尽快调查，确认是否授权；无法解释则按失陷处理；审查时可考虑是否有人安装改变行为的软件、改动控制面（如安全组）、杀毒扫描、核对 IAM 权限是否需变更/轮换。Low（1.0–3.9）：未造成失陷的尝试性可疑活动（如端口扫描、失败入侵）；无立即必做动作，但值得记录，因可能有人在找弱点。本场景据此输出分诊清单。禁止声称「已确认失陷」。
02实际效果
- 源未披露量化「各严重级别平均 MTTR」；公开文只描述分值区间与建议处置方向。
- 值班可按 Critical/High 优先，减少 Low 噪音抢占。
- 与「样本发现项 / 测试账号脚本」场景可先口头隔离再升级。
03值得知道
- 扩展威胁检测与各保护计划的细节字段以 finding 详情文档为准。
- 抑制规则与自动归档策略需另按管理文档配置，本条只覆盖严重级别语义。
- 上面写的是文档建议，不是你的账户告警统计。
04可复制提示词
高危发现项应急提纲
出现 Critical/High GuardDuty 发现项，请写应急提纲。
现象：{{symptom}}
已做动作：{{actions}}
时间线：{{timeline}}
输出：
1. 优先遏制面（凭证、实例、桶）仅建议
2. 取证
3. 沟通对象
4. 防再发
不要伪造「攻击已停止」。怎么做
- 粘贴发现项类型、严重级别/分值、涉及资源与是否疑似样本
- Agent 按 Critical→Low 输出优先序、推荐动作提问与证据保全提醒
- 人工在 GuardDuty 控制台处置；Agent 不代归档/抑制
实用提示
- 同类型发现项可能因上下文严重级别不同；先看分值落在哪一档再套默认表
- 与 cloudtrail-log-integrity-self-check / ecr-image-scan-findings-triage 不同：本条是 GuardDuty 严重级别分诊，不是日志完整性或镜像 CVE 扫描