一个小故事

没有安全验证，就没有安全运营闭环。说起安全验证的故事，有必要先回顾一下我在某股份制银行做企业安全的时间线，某种程度上，这也是国内股份制银行安全的缩影。

2008 年以前，网络安全上古阶段

安全建设基本是老三样：防病毒、防火墙、IDS。

有没有，有；有没有效，不知道。

2008 年，北京奥运会举办，政治大事件，都说网络安全是事件驱动，这是网络安全要感谢的第一件大事件。全行上下，都将业务连续性、信息系统稳定性和安全性，当做头等大事来抓。我们做了几件事：

• 把漏洞太多的不重要系统关闭，包括：行内 BBS、e-learning
• 买了三套不同的漏扫工具，每周全部扫一遍系统和应用
• 安全团队7*24 小时值班，变更全部改成晚上操作
• 如果确定是攻击 IP，直接在防火墙上封禁访问，所有域名和 IP 都不允许

奥运会之后，除了安全团队 7*24 常态化值班在 稍晚几年实现，其他都作为常态措施都继续保留了。个人认为，2008 年是很多企业安全建设的元年。

2009 年- 2013 年，安全运营 1.0阶段

2009 年开始，我们调研了国内银行和互联网公司之后，认为安全建设之后是安全运营，做企业安全一定会走上安全运营之路。

安全运营的第一步是把各类分散在不同安全工程师手里维护的安全系统的日志，统一收集起来，统一使用 UseCase规则过滤，把真正需要处理的事件，从海量日志中过滤出来，让一线人员处理，一线处理不了的升级到二线处理，这就是 SIEM/SOC。主要是解决：

• 安全设备和系统产生大量日志，哪些需要真正去处理，哪些是误报无需理会？
• 不同安全工程师维护安全设备和系统的弊端：每天的告警处理质量取决于工程师的能力和责任心
• 上述两项，不同的安全人员的处理标准并不一致，导致安全质量不稳定

从 2009 年第一期 SOC 系统建设到 2013年，日志量从 2000 EPS（events per second）增长到 2万 EPS，2021 年达到 10 万 EPS；上线并满足可运营标准的UseCase 700条，每天告警量 100 条。这期间做了大量告警降噪和日志源数据质量的工作。

2011 年，为了验证安全运营建设质量，从腾讯安全平台部挖了保哥（Mango）过来，组建我们的蓝军，每月开展一次内部红蓝对抗。保哥的很多手法让我们防守方开了眼界，叹为观止。红蓝对抗的结果，防守方自然是输多胜少。经过一段时间的复盘（关于复盘，可以看这篇文章：从“复盘”到“复仇”，谈如何正确的复盘），发现了 721 规律，对抗失败的原因归因分析：

• 10%是能力不足，无法发现。
• 20%是能力 OK，覆盖率不足。
• 70%是能力 OK，覆盖率 OK，但使用不当，包括：策略配置、日志丢失、性能不足、流量未解密等。

从实战角度去看，很多组织面临的防御困境，是防御措施失效带来的安全有效性偏低问题。

2011 年的实战攻防对抗结果，大大教育了我们防守方。在没有攻击队的时候，我们觉得自己的防守固若金汤，当攻击队一次次打脸的时候，我们也在苦苦思索解决之道。我们不能在攻击队打穿我们的时候，或安全事件发生后，我才知道我们很多防御措施失效了，不起作用了。我们可以将攻击队使用的各类攻击方式，以及触发防守方UseCase规则的告警条件都模拟一遍，如果预期的拦截或告警结果没有出现，那就意味着存在一个或多个安全失效点，再排查失效点就能发现原因和解决掉了。

2012 年，我们有 700 条左右 UseCase 检测规则，我们针对性的写了 600+ 自动化脚本，模拟各类攻击和数据泄露方式，再去人工比对拦截和告警结果，找到“应该拦截没有拦截、应该告警没有告警”的这部分失效点。

安全有效性验证，配合我们另外两个安全运营利器：

• 《企业安全建设之矩阵式监控提升安全有效性实践》 - 矩阵式监控
• 《安全资产管理中容易被忽视的几点》 - 安全资产管理s-CMDB平台

当年我们的红蓝对抗成功率就直线提升了，有机会 GCCP 闭门会议上，我可以分享当年红蓝对抗的经典掌故，当然还有安全运营 2.0 之路的故事。

安全验证

资产脆弱性和安全防御脆弱性

资产有脆弱性，包括漏洞、弱口令、未授权访问等。

安全防御体系也有脆弱性，安全防御体系由三部分组成：安全设备、安全策略、安全处置。安全设备、规则策略、安全处置等都有可能失效，比如安全设备性能不足或者宕机（夯死），规则策略可能做的不好，或者就没配置，人的处置可能会误判等，都可能导致安全失效。

再比如，我们在某个行业做了 100+ 的边界安全验证，而这个行业绝大多数边界安全都是用的 IMPERVA 的 waf，但边界安全拦截率完全不同，最高是 98%，平均 95%，最低只有 20%，安全设备都相同，但规则策略的不同，导致了不同的安全效果差异。

因为资产层有脆弱性，内外部攻击者会用各种漏洞利用方式去找资产的脆弱性，安全防御层就是对攻击者的各种漏洞利用方式进行有效的识别、检测和阻断。

而且安全防御层并不会因为资产层没有某个漏洞而把攻击者针对这个漏洞的利用方式放进来，不管自己保护的资产层有没有漏洞，安全防御层会尽可能的识别、检测和阻断各种攻击方式。

一个安全事件的发生，是因为：

• 资产层有脆弱性
• 防御体系也有脆弱性
• 攻击者穿透了防御体系，找到了资产层脆弱性，实施漏洞利用，造成安全事件

如果要达到降低安全事件发生的目的，消除两者中的任何一个都可以。代码审计、漏洞扫描、渗透测试、红蓝对抗都是发现和消除资产的脆弱性，有价值但不够。

发现和消除安全防御体系的脆弱性，也同样可以达到降低安全事件发生的目的，这就是安全验证。

安全失效点

先举两个安全失效点的例子：

• 某机构 HIDS 内存马防护模块未开启，攻防演习期间对生产业务区主机进行内存马攻击成功，HIDS检测失效率100%。
• 某机构NTA探针设备性能不足，互联网DMZ区流量存在严重丢包，互联网资产遭受来自互联网的攻击时，流量告警日志丢失38%，漏检了很多攻击行为

实践中，我们还遇到过很多千奇百怪的失效点。我们经过了 300+ 甲方安全 PoC 测试，50+ 已成单客户实际部署和常态化运营使用后，总结了 Top30 失效点：

没有任何一家企业能够避免 Top30 失效点

比如我们在模拟攻击 100 个域名时，发现有 5 个域名 NTA 上没有任何告警，排查发现网络团队给安全团队NTA 设备镜像的流量时这 5 个域名是 https 加密流量，而 NTA设备对加密流量是没有任何检测能力。这里涉及到一个极难解决的安全困境：

幸存者偏差

当我们没有看到告警的时候，我们其实判断不出来：

• 没有攻击，导致没有告警？
• 还是有攻击没发现，导致没有告警？

安全性不像可用性，系统故障了业务交易就做不了，可用性故障很快就能暴露和发现，安全性失效不是，安全是隐性而非显性。但安全可以向运维学习，解决这个困境。

比如银行的运维同学，通过模拟转账交易，判断是否有故障点。如果转账交易成功，意味着交易依赖的：网络、系统、应用、人行二代支付系统、反洗钱系统、公安身份证系统都正常，这中间任何一个故障点都会导致转账交易的失败。模拟转账交易失败，意味着存在一个或多个故障点。

回到网络安全上，如果模拟主机内存马上传，最后没有收到内存马告警短信和邮件，说明主机 HIDS 端、后台、日志传输、SOC 、告警方式（短信和邮件）存在一个或多个失效点。

运维里，系统不可用造成业务中断属于低频，而硬盘坏、磁盘空间满、电源坏属于高频。

安全里，安全事件属于低频，但安全设备不可用或性能不足、软件版本升级导致功能丢失或引擎版本不匹配、策略配置不当等属于高频。

安全从业人员，在系统监控、性能监测、策略优化等工程化能力方面通常经验和意识不足，具体表现就是这些高频失效点往往都对应一些低级失误（错误），但这些低级问题通常都会导致高级威胁。

怎么实现

怎么实现通过安全验证，发现安全失效点，进而实现安全运营闭环？

解决思路是：

• 模拟各类攻击手法、工具，数据泄露方式
• 收集安全防御体系拦截和告警结果
• 自动化比对，不能拦截、不能告警的用例，告警出来

安全验证的告警也作为安全告警的一种，遵循统一的安全运营流程处理

这里有三个关键点：

• 模拟方式的完备性和实时性。除了攻击方式和攻击工具以外，还应模拟基于安全策略及绕过的规则验证，以及模拟各类数据泄露在内的数据安全用例
• 除了模拟方式构成的验证用例以外，更重要的是知道防御方针对这种攻击会有怎样预期的结果，“既要懂攻击，还要懂防御”，就像你去体检，除了知道要体检血糖、血脂、血压等体检项外，还要知道血糖的正常值：空腹全血血糖为3.9～6.1毫摩尔/升。只有知道了正常值，才能将检测值和正常值做自动化比对
• 自动化比对。有的单个用例实践中会作用在一万个对象上，而大型机构的用例差不多几千，这些用例一天或一周全量执行一次，叠加起来验证结果比对是天量级任务，不可能通过人工来完成比对，而要实现这点，必须通过“自动化闭环”完成

除了上述关键点，实际工程化中还需要解决很多细节问题。原理很简单，工程化实现却需要很多积累。

就像飞机起飞原理很简单：只要速度足够快，机翼上下压力差就可以让飞机起飞。但实际工程化制造飞机和建立航空和民航体系，却是非常有技术含量和门槛的。

落地实践

安全验证分成黑盒验证和白盒验证

红蓝对抗、攻防演习属于黑盒验证，攻防双方对彼此都是“黑盒”，并且尽可能的迷惑和误导对方。黑盒验证已经证明其价值并普遍被甲方接受，但不能解决以下三个不足：

• 成本较高，难以保证频率。通常是请外部攻击队，或自建蓝军开展，频率上一年一次、两次、或者四次，难以高频开展
• 效果依赖概率和运气。邀请的攻击队擅长点和企业的薄弱点匹配上，效果最好，但这依赖邀请的攻击队实力，各方面攻击都擅长的攻击队，成本很高，概率很低，需要碰运气
• 黑盒验证通常交付资产脆弱性，而甲方安全团队更关心攻击队怎么找到这些漏洞的攻击方法，使用的工具工具和路径，这称之为作案手法，而黑盒验证较少的提供关于作案手法的内容和价值

基于黑盒验证不能解决的三个不足，从 2017 年开始，国内外大型甲方，开始尝试做一些白盒验证，也称之为安全有效性验证的实践。

验证对象和类型

验证对象包括：

• Sensor 感知器的有效性
• 告警日志的有效性
• 安全检测规则的有效性
• 运营处置的有效性

验证类型，包括两类：

• 基于攻击手法、工具、漏洞POC的攻防验证
• 基于安全策略及绕过的规则验证

还有一大类是基于数据泄露方式在内的数据安全验证，后续文章再详细介绍。

验证目标

通用验证包括：边界安全、流量安全、主机安全、终端安全、应用安全、身份安全、邮件安全、集权类系统如 AD安全、防勒索能力验证等。

前沿行业比较关心：容器安全和云原生安全、自研设备安全能力和策略规则、供应链安全、新型安全技术等。

HW 场景中：Hvv 前关心过去三年 Hvv 中攻击队使用的攻击手法和攻击工具，类似高考真题模拟一样；Hvv中关心各类 TTP情 报，以及自己的防御体系在面临这些最新攻击方式和工具时是否具备拦截和告警能力。

数据安全：各类 DLP、数据库审计、API 安全、分类分级和数据脱敏等。

重大活动保障关键点验证：网页防篡改能力、互联网边界防护能力、代码泄露监测能力的验证。

验证频率

安全是基于风险偏好和容忍度，而这两点又和企业的业务和科技战略相关，没有哪家企业会脱离业务，一味的追求低风险，而是保持和业务发展规模和阶段相匹配的安全。

实践中，企业会基于自己的风险偏好和容忍度，建立安全验证机制：

• 对于关键业务和区域，非常依赖的检测规则，如主机 Webshell 检测、蜜罐被访问、流量中发现 RCE 攻击且失陷等规则，每小时验证
• 对于生产网，普通规则，如 WAF 覆盖度、NTA 规则有效性，每天验证
• 对于全部的检测能力，每月验证，甚至每季度每半年验证一次

验证结果运营

随着大中型企业安全运营成熟度提高，在原有的安全规划、安全建设、安全运营基础上，增加了持续验证。即：

同步规划、同步建设、同步运营、持续验证

一方面，持续验证的结果，也作为安全运营的告警来源之一，纳入安全运营流程处理，实现统一的安全运营流程闭环。

另一方面，通过安全验证失效点根因分析，总结纵深防御体系的薄弱点，从根源上解决问题。

应用场景

安全验证在不同企业有不同的使用方法，包括：

1.安全自动化巡检工具

通过自动化和常态化的周期性持续验证，帮助用户先于攻击者发现安全策略失效点，缩短失效点存在的时间周期，及时解决，降低失效导致的攻击风险。

2.辅助精细化安全策略运营

提供验证失效的攻击手法和攻击工具细节，辅助企业安全团队改进安全策略，建立精细化安全运营能力。特别的，提供部分防护策略配置的行业最佳实践。

3.帮助企业安全团队第一时间掌握最新的漏洞利用、攻击工具和攻击手法，检验企业针对最新的攻击手法的防护能力

当出现冰蝎 Webshell 最新版的时候，企业安全负责人想第一时间知道这个情报，以及针对最新的冰蝎 Webshell，自己现有的防御体系的拦截和告警情况。对于不能拦截和告警的防御措施，再针对性的制定方案，比如等待安全设备厂商更新规则，还是决定自己根据特征写检测规则，或是其他处置技术方案。

4. 帮助甲方可视化和量化安全效果

安全团队不太好讲清楚安全价值和效果，主要是可视化和量化安全效果比较困难。 

目前企业安全，经常提到要掌握“攻防态势”，但其实只有攻击的态势，如发现多少攻击，检测到多少告警，这都是攻击态势，并没有防御的态势。防御的态势应该展现企业有多少重要业务和关键路径，这些业务和关键路径的防御措施部署情况，能够防御多大级别攻击，防御有效性实时情况，其实比较缺乏这些方面。安全验证可以提供缺乏的防御态势数据。

同时，安全验证，有了基础的验证元数据，可以将这些验证结果作为安全规划的输入，以及未来三年规划要做哪些，要投入哪些技术领域的依据。

安全验证是目前比较新、发展比较快速的安全运营领域，未来可以看到企业安全的更多使用场景。