结论先行：判断内网安全的成色，问「买了什么设备」得不到有用答案。换个问法更有效：对每一类常见攻击手法，我们的数据覆盖到哪一档。把结论归成三档——能发现并能处置、能发现但没有处置、看不见——把看不见的那几类列成清单，投入方向就清楚了。
为什么「我们有不少告警」说明不了问题
不同安全组件的告警名称各成体系：这个叫异常进程，那个叫可疑连接，另一个叫违规访问。名称不统一带来的后果是，谁也说不清几套设备加起来覆盖了哪些攻击手法、漏掉了哪些。安全团队需要的不是更多告警，而是一张能对齐的对照表。
行业里较常见的做法是引入统一的攻击技战术框架，把每个组件能识别的手法按框架归类。框架本身不解决技术问题，它的价值在于给不同来源的告警提供同一个坐标系。
从入口到横移：把检测落到数据源上
归类之后还要往下走一步：每一类手法靠什么数据源才能看见。脱离数据源谈检测能力，容易停在纸面。
| 攻击阶段 | 典型手法 | 需要的数据源 |
|---|---|---|
| 初始进入 | 钓鱼附件执行、对外服务漏洞被利用 | 邮件与网关日志、终端进程与命令行、对外服务的访问记录 |
| 落地与持久化 | 写入自启动项、创建计划任务、驻留服务 | 终端文件与系统配置变更记录、服务与任务创建事件 |
| 凭据获取 | 凭据窃取、票据伪造 | 登录与认证事件，以及批量登录的源与时间特征 |
| 横向移动 | 远程登录探测、复用合法凭据连接其他主机 | 主机之间的全量连接记录，含被阻断的那部分 |
| 外联与渗出 | 连接外部控制端、批量外发数据 | 出向连接记录、流量与文件外发日志 |
横向移动这一行值得单独说。多数检测手段只看得见边界流量，主机之间的访问没有记录，而内网攻击恰恰发生在这段盲区里。把策略执行点放到工作负载侧之后，每台主机进出的连接尝试都会被记录下来，无论是否放行；被阻断的那部分尤其有价值，因为它记录的是一次没有成功的尝试。
三档结论怎么给
核对完数据源，每一类手法都会落到三档之一：
- 能发现并能处置——有数据源、有分析规则，并且规则后面有明确的处置动作与责任人。
- 能发现但没有处置——数据源和规则都在，告警却停在平台里没人跟。这一档的问题不在技术，在流程。
- 看不见——数据源缺失，或数据源有了但没有相应的分析规则。这一档要单独列清单，作为下一步的补点。
把三档的数量列出来，比「检测覆盖做得怎么样」这类问法更容易得到可执行的答案。多数单位盘点后的结果是第二档最多——不是看不见，而是看见了没人管。
看不见的那几类怎么补
补的顺序建议按两条线排：先补一旦发生后果严重的手法，再补数据源获取成本低的手法。有些缺口加一个数据源就能补上；有些要先解决采集点在不在的问题，比如安全组件装不上的资产、以及长期离线的主机，这两类本身就要先纳管。
另一个容易漏的环节是规则维护。盘点不是一次性工作，规则会随业务变化失效：长期零命中的规则未必代表安全，也可能是业务变了之后规则已经不匹配。
边界与前提
其一，覆盖度是相对概念，不存在覆盖全部手法的状态。盘点的目的是知道差距在哪，而不是把数字做好看。
其二，告警数量多不等于覆盖广，两者要分开统计，否则容易把噪音当成能力。
其三，盘点结果要落到具体资产与责任人。停留在框架图上的结论，下次盘点还是同样的结论。
落地清单
- 选定统一的攻击技战术框架，作为跨组件对齐的坐标系。
- 列出内网需要覆盖的攻击阶段与典型手法。
- 逐类核对现有数据源与分析规则，输出三档结论。
- 把「能发现但没有处置」的一档补上处置动作与责任人。
- 把「看不见」的一档按后果严重度与获取成本排序。
- 确认采集盲区（装不上组件的资产、长期离线主机）的纳管计划。
- 约定盘点周期，按季度回看规则命中情况。
奇摩在金融与制造客户的内网安全运营中，通常把覆盖度盘点与规则维护周期一起写进服务内容。需要梳理现有内网检测能力，欢迎 预约咨询。