包含内容
- 一份事先商定的技术清单，取自 MITRE ATT&CK 以及我们实际所见
- 与您的检测团队并肩、实时执行
- 逐项技术的结果：触发告警、落日志但未告警，或完全没有遥测
- 针对那些差一点就触发的规则给出调优建议
- 在时间允许时，于同一项目内对调优后仍失败的技术重新执行
您会得到
- 逐项技术的结果表，双方均附时间戳
- 具体缺失的是哪些日志源，而不只是说覆盖率低
- 用您实际在用的查询语言写成的检测逻辑建议
- 一份该优先修什么的短名单，按技术的常见程度排序
- 与检测团队的复盘
- 应要求提供面向审计师与客户的证明函
- 复测后的修复证明，作为独立文档
项目形态
- 逐案界定范围测试开始前以书面形式确定。现场或远程两到五天常规窗口。如有截止日期则围绕它安排。定价如何运作
通常会得出什么
常见的结果并不是没有检测。而是遥测有、规则也有，但两者对不上：规则查询的那张表，相关日志源根本不写入；或者它按一个该技术并不使用的进程名做过滤；又或者它把告警发到凌晨两点没人看的频道。这些问题一旦有人证明确实在发生，修起来都很便宜。
第二种常见结果，是某项技术明明留下了一条完全可用的日志，却没有任何查询在看它。这是本清单上最便宜的发现，也是单靠文档审查最容易漏掉的一个。
一次演练怎么进行
我们先把技术清单敲定，这样没人会被打个措手不及，您的团队也能提前准备查询。到了当天，我们逐项执行，边做边报出来，您的团队则报告看到了什么、什么时候看到的。双方都记录时间戳。若某项技术什么都没产生，我们就停下来，先弄清问题出在日志源、规则还是路由，再继续。
它不是什么
这是一次协作演练，不是隐蔽行动。如果您想知道您的团队能否抓住一个刻意不想被抓到的人，那是红队评估，衡量的是另一回事。我们也不会代为运营、监控或配备您的检测体系。我们测试它、帮着调优，然后交还给它真正的主人。
问题
您需要一个日志落地的地方，以及一个能查询它们的人。不必已经成熟。最有价值的几次演练，恰恰是和 SIEM 上线三个月、想知道自己哪些假设站得住的团队一起做的。
事先从 MITRE ATT&CK 中商定，并向我们实际看到被使用的那些倾斜：凭据获取、横向移动、证书滥用与持久化。如果您有特定的威胁模型，或者希望覆盖业内近期的某起事件，尽管提出来。
我们给出逻辑建议，并用您所使用的语言交付查询草稿，通常是 Microsoft Sentinel 的 KQL。规则的归属、测试与上线由您的团队负责 - 因为公司里没人看得懂的规则，就是下一个缺口。
能。只要项目时间窗口允许，我们会在同一次演练中重跑失败的技术 - 这是现有最快的反馈闭环。
逐案确定，依技术清单的规模与时间窗口的长度而定。通话之后以书面形式固定。
在购买之前，先把范围界定清楚。
通话三十分钟，24 小时内给出书面固定价格；如果这并不是您需要的项目，也会直说。