安全验证，实现安全运营闭环实践

0x1 一个小故事

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

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

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

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

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

• 把漏洞太多的不重要系统关闭，包括：行内 BBS、e-learning

• 买了三套不同的漏扫工具，每周全部扫一遍系统和应用
  

• 安全团队7*24 小时值班，变更全部改成晚上操作

• 如果确定是攻击 IP，直接在防火墙上封禁访问，所有域名和 IP 都不允许
  

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

1.2 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 之路的故事。

0x2 安全验证

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

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

安全防御体系也有脆弱性，安全防御体系由三部分组成：安全设备、安全策略、安全处置。安全设备、规则策略、安全处置等都有可能失效，比如安全设备性能不足或者宕机（夯死），规则策略可能做的不好，或者就没配置，人的处置可能会误判等，都可能导致安全失效。再比如，我们在某个行业做了 100+ 的边界安全验证，而这个行业绝大多数边界安全都是用的IMPERVA 的 waf，但边界安全拦截率完全不同，最高是 98%，平均 95%，最低只有 20%，安全设备都相同，但规则策略的不同，导致了不同的安全效果差异。

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

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

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

1. 资产层有脆弱性

2. 防御体系也有脆弱性

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

如果要达到降低安全事件发生的目的，消除两者中的任何一个都可以。

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

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

聂君

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

幸存者偏差

聂君

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

• 没有攻击，导致没有告警？

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

解决思路是：

• 模拟各类攻击手法、工具，数据泄露方式

• 收集安全防御体系拦截和告警结果

• 自动化比对，不能拦截、不能告警的用例，告警出来

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

这里有三个关键点：

• 模拟方式的完备性和实时性。除了攻击方式和攻击工具以外，还应模拟基于安全策略及绕过的规则验证，以及模拟各类数据泄露在内的数据安全用例

• 除了模拟方式构成的验证用例以外，更重要的是知道防御方针对这种攻击会有怎样预期的结果，“既要懂攻击，还要懂防御”，就像你去体检，除了知道要体检血糖、血脂、血压等体检项外，还要知道血糖的正常值：空腹全血血糖为3.9～6.1毫摩尔/升。只有知道了正常值，才能将检测值和正常值做自动化比对

• 自动化比对。有的单个用例实践中会作用在一万个对象上，而大型机构的用例差不多几千，这些用例一天或一周全量执行一次，叠加起来验证结果比对是天量级任务，不可能通过人工来完成比对，而要实现这点，必须通过“自动化闭环”完成
  

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

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

0x3 落地实践

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

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

• 成本较高，难以保证频率。通常是请外部攻击队，或自建蓝军开展，频率上一年一次、两次、或者四次，难以高频开展

• 效果依赖概率和运气。邀请的攻击队擅长点和企业的薄弱点匹配上，效果最好，但这依赖邀请的攻击队实力，各方面攻击都擅长的攻击队，成本很高，概率很低，需要碰运气

• 黑盒验证通常交付资产脆弱性，而甲方安全团队更关心攻击队怎么找到这些漏洞的攻击方法，使用的工具工具和路径，这称之为作案手法，而黑盒验证较少的提供关于作案手法的内容和价值
  

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

3.2 验证对象和类型

验证对象包括：

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

验证类型，包括两类：

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

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

3.3 验证目标

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

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

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

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

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

3.4  验证频率

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

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

• 对于关键业务和区域，非常依赖的检测规则，如主机 Webshell 检测、蜜罐被访问、流量中发现 RCE 攻击且失陷等规则，每小时验证

• 对于生产网，普通规则，如 WAF 覆盖度、NTA 规则有效性，每天验证

• 对于全部的检测能力，每月验证，甚至每季度每半年验证一次

3.5 验证结果运营

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

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

聂君

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

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

3.6  应用场景

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

1.安全自动化巡检工具

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

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

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

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

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

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

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

0x4 知其安和团队

4.1 知其安做安全验证时间线

1.2011 年自建蓝军实现黑盒验证，2012 年开始通过写脚本实现白盒验证，并在某股份制银行的网上银行部署。

2.2016.10.30，我发表了本公众号第二篇文章：金融行业企业安全运营之路，将安全验证框架作为安全运营四大框架之一，提出了白盒验证（过程验证）和黑盒验证（结果验证）的具体实现，最后是图形化展示。

3.2017年，入侵和攻击模拟，简称BAS，概念首次提出，2021/22年，连续2年登顶安全运营成熟度曲线。

4.2020 年4 月，Mandiant（首个披露中国APT的公司，后被FireEye收购）出了一份报告《SECURITY EFFECTIVENESS REPORT 2020》（文末有报告下载地址），报告中提出，衡量安全控制措施的有效性并证明其合理性已成为企业的一项关键绩效指标，正在成为企业安全的一种趋势性需求。安全有效性验证可以量化安全措施的实际有效性，建议实施自动化进行持续安全验证。

相信安全有效性验证这一没人注意但隐形刚需会成为热点和标配。

聂君，安全有效性验证的发展趋势

当时我内心非常激动，有遇到知音的感觉，再也不是茫茫大海孤独探索了，对于过去近十年一直坚持做的事情终于能够得到认可并渐渐成为趋势感到欣慰。详细内容见2020.5.19公众号文章：安全有效性验证的发展趋势 ，

5.2022年，Gartner 发布八大安全与风险管理趋势，再次提到BAS

6.2023 年，Gartner最新的2023年网络安全趋势提到的9大趋势中，首次提出“Cybersecurity Validation”安全验证，并列为九大趋势之一。“到2026年，超过40%的组织，包括三分之二的中型企业，将依赖于统一的平台来运行网络安全验证评估。”安全验证，将成为企业安全运营的利器。

4.2  知其安，知其所以安

企业安全经过过去二十多年的建设，大中型企业都开始转入安全运营，从甲方侧或者说需求侧来看，大中型企业都将自己的安全团队从安全处升格为安全运营中心，安全处长升级为部门副总，组织架构的变化必然会带来安全工作重心和投入的变化。

从乙方侧或者说供给侧来看，过去五年，内生安全、安全左移、零信任安全等都是一种理念创新，而非技术革新。本质是因为安全建设技术已经进入了技术成熟期甚至是停滞期。

从需求和供给两端看，安全运营是下一个十年甲乙双方都重视的风口。

聂君

但安全运营的有两个痛点：没有标准，一千个人心中有一千个安全运营；缺乏工具，全是堆人解决。而安全运营 80%是重复性的工作，可以通过自动化工具完成，难点是如何站在甲方安全视角，研发适合甲方安全运营需求的自动化工具。

知其安，知其所以安，是一家专注于安全运营工具链研发和落地实践的初创企业，通过离朱-安全验证平台、陆吾-安全资产管理平台，协助甲方安全团队建立精细化安全运营能力，不断提升安全运营效率。

4.3 知其安团队

网络安全行业，绝大多数从业人员是甲方企业的安全团队人员，但由于诸多主客观条件限制，这个最大的群体成为了“沉默的大多数”，但这部分沉默的大多数的心声，才是网安行业最应该被聆听的声音，这部分群体的需求和意见，才是促进网络安全行业前进的最大动力，可惜市场上没有这部分最有力量和最有价值的声音，甚至被很多乙方安全公司选择性忽略了。

绝大多数安全公司是从产品功能维度去满足客户需求，上来就讲自己有八大功能、十大亮点。大部分安全公司的产品经理、解决方案专家，也并没有丰富的甲方实践经验，甚至没有修过一个漏洞、处理过一次安全事件，就在指导甲方做企业安全。好比没有养育过孩子的人，在教我们怎么教育自己的孩子，这其实是个很大的问题。

安全运营是甲方的安全管理和安全体系流程化，最佳实践的传递和固化。

聂君

没有甲方实践经验去做安全产品和解决方案，这个问题在安全运营领域尤为突出。而安全运营，需要结合甲方的安全实际情况、安全风险偏好和容忍度，来确定本企业的最佳解决方案，需要有丰富的甲方实践经验才有可能落地一套可行的覆盖架构+工具平台+流程+度量的安全运营体系。

知其安核心成员具备在大型银行（头部股份制银行）、金融核心机构（深圳证券交易所）、大型券商（头部券商）、大型互联网公司（阿里、腾讯）、上市网络安全企业长期从事甲方安全实践，擅长从甲方视角发现和解决实际问题。

公司目前已经签约服务超过50家大型金融、央企、智能制造、互联网客户，在行业中获得了较好的应用反馈和用户评价。行业用户覆盖六大国有银行，十二家全国性股份制银行、券商等，同时在高端智能制造和互联网行业都有丰富的客户积累，累计PoC测试用户超过300家。

0x5 一个普通安全从业人员的未来

5.1  我的决策逻辑

2018 年我做了一个艰难的决定，开始了一段新的职业生涯，并举家搬迁至北京，至今我们全家仍然是北漂，想成为北京人民（拿北京户口为孩子上学）太难了。

好多朋友好奇的问我，从金融行业来到非金融行业，从甲方到乙方，从深圳举家搬迁到北京，是为了什么？关心我的朋友，私下开玩笑问我：后悔吗？

先说我的看（答）法（案）：不管选哪条路，自己走过的路就是最好的路。因为人没有办法同时走完两条路，然后到终点时回首比较，人生只有一条最好的路，就是自己走过的路。

我的天赋非常一般，没有特别的，只有靠勤奋和积极主动。能吃点苦，吃点亏，做别人不愿意做，没想到要去做的事情，没伞的孩子必须努力奔跑。这和我的成长经历有关：一个安全从业人员的前半生（上学篇）

这导致了我有非常强的不安全感，个性偏向于积极主动（爱折腾），不愿意在舒适区常待，喜欢挑战和尝试新鲜领域，对抗不确定性。很多时候连正常的休息都觉得是虚度时间。

2022 年底，我又做了一个艰难的决定，开始了创业生涯，说服我自己的是：

人不是因为做过什么遗憾，而是因为没做过什么而遗憾。

聂君

5.2 一个普通安全从业人员的未来

如果您对安全运营领域，特别是通过自动化工具解决安全运营需求感兴趣，欢迎微信联系我：kelvin2294，或者扫以下二维码，知其安虚位以待：资深产品经理、高级售前、行业解决方案专家、大客户销售。

传送门：

安全有效性验证的发展趋势

金融行业企业安全运营之路

金融业企业安全建设之路

企业如何构建有效的安全运营体系

聂君：我们谈安全运营时在谈什么？

从“复盘”到“复仇”，谈如何正确的复盘

原文始发于微信公众号（君哥的体历）：安全验证，实现安全运营闭环实践