这两种情况都是舍本逐末。因为我们工作的核心是发现和解决安全风险，不是做系统或者使用先进技术，切不可本末倒置。所以，安全运营就是踏踏实实不投机取巧地优化系统，要“扎硬寨打呆仗”。

与信息安全的“三分技术、七分管理”理论类似，安全运营也是一个“三分技术、七分管控”的活：很多时候我们遇到的问题不是技术问题，而是工程问题、沟通问题、合作问题和推动问题。所以技术好并不一定代表能做好安全运营，但是要把安全运营做到卓越，则需要对技术有深入的理解。

从标题可知，笔者把安全运营能力分为四个等级：器、术、法、道。初级阶段是能够运用相关的工具和方法来发现解决问题，是为“知器”；中级阶段是能够总结归纳创造自己的一套办法论来解决问题，是为“有术”，有学才有术，所以要不断学习；高级阶段是能根据各种不同情况提炼自己的方法论并落地，是为“循法”；最最高的阶段是“悟道”，“道可道，非常道”，是最高境界。

明确了安全运营是什么，该如何衡量安全运营工作？

首先，需要衡量指标，有指标才能判断当前距离目标的差距。

不同的安全系统指标有所不同，但大致包括两大类：系统覆盖率、策略有效率和误报率。前者是指安全系统对被保护对象的覆盖比率，关注工程落地，比如公司有一万台服务器，目前HIDS已部署了5000台，这个系统覆盖率就是50%；后者衡量安全系统对安全风险的有效应对情况，关注策略效果，比如HIDS理应发现各类WebShell，目前有样本1000个，HIDS能发现800个，策略有效率就是80%，实际运营过程中发现1000个WebShell，有1个最终确认不是，那这个策略误报率就是0.1%--一个误报率高的系统最终是没法运营的，那就等于没有。

一个好的安全系统，一定是朝着提升覆盖率、提升有效率、降低误报的目标前进的：任何脱离覆盖率谈有效率的安全系统都是纸上谈兵，任何误报率高的安全系统都是无法运营的，形同虚设。

上述只是理想情况，在实际执行过程中会遇到各种问题和特殊情况：如HIDS是支持Windows/Linux的，但是还有20台是Mac系统，这20台算不算到总数中？HIDS的一个功能插件不支持某些Linux版本，那算不算已覆盖？年初HIDS的WebShell策略有效率是80%，经过一年的规则迭代，又增加了100个样本检测，现在网上发布了新的WebShell手法，这种新手法产生的样本有120个，那么现在如何算策略有效率？HIDS今年发现了2个WebShell事件，其中1个是误报，策略误报率50%到底是好是不好呢？……

另外，量变引起质变，当基数足够大的时候，即使是一个简单的问题也会非常复杂--就像经典力学仅适用宏观世界一样，在海量面前，过去的一些做法可能都不适用。比如我们管理1000台统一配置的服务器的时候可以管理得很好，但是服务器数量增到数十万台，根据业务需要又有各种不同的硬件和软件，复杂度将呈几何级增加，到时即便是一个小小的软件版本统计需求，也会成为浩大的工程。因此，安全运营就显得更为重要。

还有一些视具体系统而定的指标，如：漏洞扫描系统检测一轮所有域名/IP的耗时、HIDS发现入侵到告警的时间、DDoS的单机防护能力、WAF性能延时、应急响应时长等等。比如我们在推动的公司网站HTTPS改造项目中，提炼的三个重要指标是覆盖率、合规率、待改造域名数（有率有量，避免偏差），然后运营人员不断推动，提升指标接近目标。

其次，需要进行实战检验。

从前一段的各种问题可以看到，衡量指标是数据，从不同角度解读数据会产生不一样的结论，所以不要轻信各种主观得出的覆盖率100%、有效率100%的这种结论（很可能前提条件是排除了某些特殊情况以及仅测试自己收集的样本，甚至还有部分情况是统计遗漏），一定要邀请独立的蓝军进行实战检验，实战是检验防护能力的唯一标准。

检验是要真正的检验，所以需要独立的蓝军。作为负责人，不要被虚假的安全感迷惑，不要听信“互惠”结论、虚假数据和PR文章，一定要切实检查。

第三，需要做好完整复盘。

每一个漏洞每一次安全事件都是一次练兵的好机会，安全团队应该抓住机会复盘，查漏补缺，举一反三，从一个问题优化一类问题。

以漏洞检测系统为例，研发安全团队对每一个外报漏洞做复盘，如漏洞检测系统为什么没有发现，是什么原因导致的（策略问题/未抓取到URL/未经过上线前/系统bug……），根据问题进行归纳分析总结优化，不断迭代系统和策略，直至问题完全解决。

下图是一段时间的外报漏洞复盘对比图，可以看到，先前存在比较多的“普通反射型XSS”被优化掉了（说明漏洞检测系统对反射性XSS的发现能力提升了），新的漏洞类型主要是逻辑漏洞、存储型XSS、权限绕过等自动化系统相对难以检测的漏洞，这便是下一阶段运营团队继续想办法解决的重点工作。

以下是笔者总结的一些常见运营方法论和具体实践。