知其安聂君：安全验证 实现安全运营闭环实践

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%，安全设备都相同，但规则策略的不同，导致了不同的安全效果差异。
 
因为资产层有脆弱性，内外部攻击者会用各种漏洞利用方式去找资产的脆弱性，安全防御层就是对攻击者的各种漏洞利用方式进行有效的识别、检测和阻断。
 
而且安全防御层并不会因为资产层没有某个漏洞而把攻击者针对这个漏洞的利用方式放进来，不管自己保护的资产层有没有漏洞，安全防御层会尽可能的识别、检测和阻断各种攻击方式。
 
一个安全事件的发生，是因为：
 
● 资产层有脆弱性
 
● 防御体系也有脆弱性
 
● 攻击者穿透了防御体系，找到了资产层脆弱性，实施漏洞利用，造成安全事件
 
如果要达到降低安全事件发生的目的，消除两者中的任何一个都可以。
 
代码审计、漏洞扫描、渗透测试、红蓝对抗都是发现和消除资产的脆弱性，有价值但不够。发现和消除安全防御体系的脆弱性，也同样可以达到降低安全事件发生的目的，这就是安全验证。
 
2.2 安全失效点
 
先举两个安全失效点的例子：
 
● 某机构HIDS内存马防护模块未开启，攻防演习期间对生产业务区主机进行内存马攻击成功，HIDS检测失效率100%
 
● 某机构NTA探针设备性能不足，互联网DMZ区流量存在严重丢包，互联网资产遭受来自互联网的攻击时，流量告警日志丢失38%，漏检了很多攻击行为
 
实践中，我们还遇到过很多千奇百怪的失效点。我们经过了 300+ 甲方安全 PoC 测试，50+ 已成单客户实际部署和常态化运营使用后，总结了 Top30 失效点：
 
没有任何一家企业能够避免 Top30 失效点
聂君
 
比如我们在模拟攻击 100 个域名时，发现有 5 个域名 NTA 上没有任何告警，排查发现网络团队给安全团队NTA 设备镜像的流量时这 5 个域名是 https 加密流量，而 NTA设备对加密流量是没有任何检测能力。这里涉及到一个极难解决的安全困境：
 
幸存者偏差
聂君
 
当我们没有看到告警的时候，我们其实判断不出来：
 
● 没有攻击，导致没有告警？
 
● 还是有攻击没发现，导致没有告警？
 
安全性不像可用性，系统故障了业务交易就做不了，可用性故障很快就能暴露和发现，安全性失效不是，安全是隐性而非显性。但安全可以向运维学习，解决这个困境。
 
比如银行的运维同学，通过模拟转账交易，判断是否有故障点。如果转账交易成功，意味着交易依赖的：网络、系统、应用、人行二代支付系统、反洗钱系统、公安身份证系统都正常，这中间任何一个故障点都会导致转账交易的失败。模拟转账交易失败，意味着存在一个或多个故障点。
 
回到网络安全上，如果模拟主机内存马上传，最后没有收到内存马告警短信和邮件，说明主机 HIDS 端、后台、日志传输、SOC 、告警方式（短信和邮件）存在一个或多个失效点。
 


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

安全里，安全事件属于低频，但安全设备不可用或性能不足、软件版本升级导致功能丢失或引擎版本不匹配、策略配置不当等属于高频。
 
安全从业人员，在系统监控、性能监测、策略优化等工程化能力方面通常经验和意识不足，具体表现就是这些高频失效点往往都对应一些低级失误（错误），但这些低级问题通常都会导致高级威胁。
 
2.3  怎么实现
 
怎么实现通过安全验证，发现安全失效点，进而实现安全运营闭环？
 


解决思路是：
 
● 模拟各类攻击手法、工具，数据泄露方式
 
● 收集安全防御体系拦截和告警结果
 
● 自动化比对，不能拦截、不能告警的用例，告警出来
 
● 安全验证的告警也作为安全告警的一种，遵循统一的安全运营流程处理
 
这里有三个关键点：
 
● 模拟方式的完备性和实时性。除了攻击方式和攻击工具以外，还应模拟基于安全策略及绕过的规则验证，以及模拟各类数据泄露在内的数据安全用例
 
● 除了模拟方式构成的验证用例以外，更重要的是知道防御方针对这种攻击会有怎样预期的结果，“既要懂攻击，还要懂防御”，就像你去体检，除了知道要体检血糖、血脂、血压等体检项外，还要知道血糖的正常值：空腹全血血糖为3.9～6.1毫摩尔/升。只有知道了正常值，才能将检测值和正常值做自动化比对
 
● 自动化比对。有的单个用例实践中会作用在一万个对象上，而大型机构的用例差不多几千，这些用例一天或一周全量执行一次，叠加起来验证结果比对是天量级任务，不可能通过人工来完成比对，而要实现这点，必须通过“自动化闭环”完成
 
除了上述关键点，实际工程化中还需要解决很多细节问题。原理很简单，工程化实现却需要很多积累。
 
就像飞机起飞原理很简单：只要速度足够快，机翼上下压力差就可以让飞机起飞。但实际工程化制造飞机和建立航空和民航体系，却是非常有技术含量和门槛的。
 
0x3 落地实践



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


● 成本较高，难以保证频率。通常是请外部攻击队，或自建蓝军开展，频率上一年一次、两次、或者四次，难以高频开展
 
● 效果依赖概率和运气。邀请的攻击队擅长点和企业的薄弱点匹配上，效果最好，但这依赖邀请的攻击队实力，各方面攻击都擅长的攻击队，成本很高，概率很低，需要碰运气
 
● 黑盒验证通常交付资产脆弱性，而甲方安全团队更关心攻击队怎么找到这些漏洞的攻击方法，使用的工具工具和路径，这称之为作案手法，而黑盒验证较少的提供关于作案手法的内容和价值
 
基于黑盒验证不能解决的三个不足，从 2017 年开始，国内外大型甲方，开始尝试做一些白盒验证，也称之为安全有效性验证的实践。
 
3.2 验证对象和类型
 
验证对象包括：
 
● Sensor感知器的有效性
 
● 告警日志的有效性
 
● 安全检测规则的有效性
 
● 运营处置的有效性
 
验证类型，包括两类：
 
● 基于攻击手法、工具、漏洞POC的攻防验证
 
● 基于安全策略及绕过的规则验证
 


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

3.3 验证目标
 

安全验证是目前比较新、发展比较快速的安全运营领域，未来可以看到企业安全的更多使用场景。
 
0x4 知其安和团队
 
4.1 知其安做安全验证时间线
 


01 2011 年自建蓝军实现黑盒验证，2012 年开始通过写脚本实现白盒验证，并在某股份制银行的网上银行部署。
 
02 2016.10.30，我发表了本公众号第二篇文章：金融行业企业安全运营之路，将安全验证框架作为安全运营四大框架之一，提出了白盒验证（过程验证）和黑盒验证（结果验证）的具体实现，最后是图形化展示。



03 2017年，入侵和攻击模拟，简称BAS，概念首次提出，2021/22年，连续2年登顶安全运营成熟度曲线。
 
04 2020 年4 月，Mandiant（首个披露中国APT的公司，后被FireEye收购）出了一份报告《SECURITY EFFECTIVENESS REPORT 2020》，报告中提出，衡量安全控制措施的有效性并证明其合理性已成为企业的一项关键绩效指标，正在成为企业安全的一种趋势性需求。安全有效性验证可以量化安全措施的实际有效性，建议实施自动化进行持续安全验证。
 
相信安全有效性验证这一没人注意但隐形刚需会成为热点和标配。
聂君，安全有效性验证的发展趋势
 
当时我内心非常激动，有遇到知音的感觉，再也不是茫茫大海孤独探索了，对于过去近十年一直坚持做的事情终于能够得到认可并渐渐成为趋势感到欣慰。详细内容见2020.5.19公众号文章：安全有效性验证的发展趋势 
 
05 2022年，Gartner 发布八大安全与风险管理趋势，再次提到BAS
 
06 2023 年，Gartner最新的2023年网络安全趋势提到的9大趋势中，首次提出“Cybersecurity Validation”安全验证，并列为九大趋势之一。“到2026年，超过40%的组织，包括三分之二的中型企业，将依赖于统一的平台来运行网络安全验证评估。”安全验证，将成为企业安全运营的利器。
 
4.2  知其安，知其所以安
 
企业安全经过过去二十多年的建设，大中型企业都开始转入安全运营，从甲方侧或者说需求侧来看，大中型企业都将自己的安全团队从安全处升格为安全运营中心，安全处长升级为部门副总，组织架构的变化必然会带来安全工作重心和投入的变化。
 
从乙方侧或者说供给侧来看，过去五年，内生安全、安全左移、零信任安全等都是一种理念创新，而非技术革新。本质是因为安全建设技术已经进入了技术成熟期甚至是停滞期。
 
从需求和供给两端看，安全运营是下一个十年甲乙双方都重视的风口。
聂君
 
但安全运营的有两个痛点：没有标准，一千个人心中有一千个安全运营；缺乏工具，全是堆人解决。而安全运营 80%是重复性的工作，可以通过自动化工具完成，难点是如何站在甲方安全视角，研发适合甲方安全运营需求的自动化工具。
 
知其安，知其所以安，是一家专注于安全运营工具链研发和落地实践的初创企业，通过离朱-安全验证平台、陆吾-安全资产管理平台，协助甲方安全团队建立精细化安全运营能力，不断提升安全运营效率。
 
4.3 知其安团队
 
网络安全行业，绝大多数从业人员是甲方企业的安全团队人员，但由于诸多主客观条件限制，这个最大的群体成为了“沉默的大多数”，但这部分沉默的大多数的心声，才是网安行业最应该被聆听的声音，这部分群体的需求和意见，才是促进网络安全行业前进的最大动力，可惜市场上没有这部分最有力量和最有价值的声音，甚至被很多乙方安全公司选择性忽略了。
 
绝大多数安全公司是从产品功能维度去满足客户需求，上来就讲自己有八大功能、十大亮点。大部分安全公司的产品经理、解决方案专家，也并没有丰富的甲方实践经验，甚至没有修过一个漏洞、处理过一次安全事件，就在指导甲方做企业安全。好比没有养育过孩子的人，在教我们怎么教育自己的孩子，这其实是个很大的问题。
 
安全运营是甲方的安全管理和安全体系流程化，最佳实践的传递和固化。
聂君
 
没有甲方实践经验去做安全产品和解决方案，这个问题在安全运营领域尤为突出。而安全运营，需要结合甲方的安全实际情况、安全风险偏好和容忍度，来确定本企业的最佳解决方案，需要有丰富的甲方实践经验才有可能落地一套可行的覆盖架构+工具平台+流程+度量的安全运营体系。
 
知其安核心成员具备在大型银行（头部股份制银行）、金融核心机构（深圳证券交易所）、大型券商（头部券商）、大型互联网公司（阿里、腾讯）、上市网络安全企业长期从事甲方安全实践，擅长从甲方视角发现和解决实际问题。
 
公司目前已经签约服务超过50家大型金融、央企、智能制造、互联网客户，在行业中获得了较好的应用反馈和用户评价。行业用户覆盖六大国有银行，十二家全国性股份制银行、券商等，同时在高端智能制造和互联网行业都有丰富的客户积累，累计PoC测试用户超过300家。
 
0x5 一个普通安全从业人员的未来
 
5.1  我的决策逻辑
 
2018 年我做了一个艰难的决定，开始了一段新的职业生涯，并举家搬迁至北京，至今我们全家仍然是北漂，想成为北京人民（拿北京户口为孩子上学）太难了。
 
好多朋友好奇的问我，从金融行业来到非金融行业，从甲方到乙方，从深圳举家搬迁到北京，是为了什么？关心我的朋友，私下开玩笑问我：后悔吗？
 
先说我的看（答）法（案）：不管选哪条路，自己走过的路就是最好的路。因为人没有办法同时走完两条路，然后到终点时回首比较，人生只有一条最好的路，就是自己走过的路。
 
我的天赋非常一般，没有特别的，只有靠勤奋和积极主动。能吃点苦，吃点亏，做别人不愿意做，没想到要去做的事情，没伞的孩子必须努力奔跑。这和我的成长经历有关：一个安全从业人员的前半生（上学篇）
 
这导致了我有非常强的不安全感，个性偏向于积极主动（爱折腾），不愿意在舒适区常待，喜欢挑战和尝试新鲜领域，对抗不确定性。很多时候连正常的休息都觉得是虚度时间。
 
而且我需要持续不断的认可（表扬）来给自己安全感。当我还是普通工程师角色的时候，我的老板可以满足我的需求，但现在我在企业里带将近一百人团队，我的身份角色有了一些变化，我应该是给团队所有成员安全感的人，我自己的安全感需求，大概率只能靠信念给自己。
2022 年底，我又做了一个艰难的决定，开始了创业生涯，说服我自己的是：
 
人不是因为做过什么遗憾，而是因为没做过什么而遗憾。
聂君



日本作家中岛敦有一句话，说：“大多数人是怎么过这一生的呢？因为害怕自己并非明珠而不敢刻苦琢磨，又因为有几分相信自己是明珠，而不能与普通的瓦砾为伍。”你看，把自己耽误了的最重要的原因，就是犹豫。我见过的厉害的人，都有一个特质，就是莫名其妙地坚信自己一定能把某件事干成，虽然细究起来，他也并没有什么理由。