从几组数据，看清日常安全工作的三大错觉

我们和大量一线安全团队一起工作，一个共同的感受是：我们每天都非常忙，但很多时候，我们努力的方向，可能和真实风险的方向，并不完全一致。

今天，我们不聊空泛的理论。我们想分享几个我们观察和总结到的数据。这几个数，可能和我们凭感觉、凭经验想的不太一样。

第一个数：60%

在我们分析过的去年国内发生的重大数据泄露事件中，超过60%的攻击，其潜伏期都超过了100天。

这意味着什么？

我们日常最担心的，往往是那种大张旗鼓的勒索软件攻击，因为它动静大、影响直接。所以，我们投入了大量的精力在实时告警和应急响应上。

但这个数据告诉我们，更危险的敌人，是那些安安静静的攻击者。他们进来之后，不求搞出大新闻，而是悄悄地进行横向移动、权限提升、数据打包，整个过程可能持续数月。等到我们发现的时候，核心数据早就被搬走了。

我们现有的、主要依赖实时告警的防御体系，对这种温水煮青蛙式的攻击，常常无能为力。因为在漫长的潜伏期里，攻击者的每一个单独动作，可能都触发不了高危告警。

还有试试换位思考一下，假如你是攻击者你会怎么做？攻击者在完成入侵后的第一目标是要在你的环境中潜伏下来，目标就是要让你现有的所有检测、防御手段都不告警都不起效，否则他们怎么潜伏下来呢？所以你应该想想假如你的安全产品、检测手段都不告警的情况下，你怎么办？

我们该怎么办？

既然防不住攻击者何时以什么方式打进来，那就要确保第一时间能发现他，而后让他寸步难行。定期用自动化的攻击剧本，去模拟攻击者在潜伏阶段会使用到的攻击手法（TTPs），模拟拿到单点权限后，所有可能的横向移动路径。

持续验证从办公网到核心区、从Web服务器到数据库的每一条潜在通路，确保这些路径在被真实利用前，就被我们发现并阻断。当然通过验证发现有技术手段缺失，就得赶紧做计划补上，比如：没有操作系统级审计日志怎么办？没有网络流量审计日志怎么办？

在我们协助客户完成的云上攻防演练中，接近70%的失分点，都不是因为0-day漏洞，而是因为一些基础的、常见的错误配置。

这意味着什么？

我们花了大量的预算，买了最先进的CWPP、CNAPP，我们相信这些高级工具能保护我们的云上资产。

但数据告诉我们，击垮我们的，往往不是什么高级的黑客技术，而是一些非常基础的失误。比如：一个忘了关闭的、对公网开放的存储共享；一个为了方便调试而设置的“any-any”安全组规则；一个被开发人员硬编码在代码里的访问密钥。

这些问题，光靠买新工具是解决不了的。因为工具的功能再强大，也挡不住一个错误的配置，直接把家门给敞开了。

我们该怎么办？

把配置核查变成一种动态的、持续的实战验证。不要再只依赖静态的配置扫描清单了。用一个自动化的平台，去持续模拟“如果一个AK/SK密钥泄露了，攻击者能用它做什么？”、“如果这个安全组规则是开放的，攻击者能访问到哪些内部服务？”。

用真实的攻击结果，来倒逼要追求配置失误的第一时间发现、修正和加固，而不能再等到下次月度或季度巡检，或等到安全事件发生后溯源时才发现原来是这样啊。

在我们复盘的客户安全事件中，有近40%的成功入侵，利用的是那些【已修复】的漏洞。

这意味着什么？

我们每周开漏洞评审会，催着运维和开发去打补丁，把漏洞列表清零，就以为万事大吉了。

但数据告诉我们，打补丁和解决风险之间，并不能完全划等号。很多时候：

补丁并没有被正确地应用到所有相关资产上。

补丁本身可能存在问题，或者与业务不兼容，被悄悄回滚了。

攻击者用了一种新的绕过技术，让这个补丁失效了。

我们满足于漏扫报告上那个漏洞消失了，却没有去验证，利用这个漏洞的攻击手法，是不是也真的失效了。

我们该怎么办？

在漏洞修复流程里，增加一个强制的验证环节。当运维或开发团队反馈一个漏洞已修复时，工作并没有结束。安全团队需要立即用平台，重跑一次针对该漏洞的攻击剧本。只有当攻击模拟显示“已无法成功利用”时，这个漏洞修复工单，才能真正地关闭。

这三个数据，指向的是同一个结论：我们安全工作的重点，正在从假设，转向证明。

我们不能再假设，没有告警就是安全的；不能再假设，部署了工具就是有效的；不能再假设，打上了补丁就是解决了风险。

塞讯智能安全验证平台的核心价值，就是帮助我们的客户，完成这个从【我觉得】到【我确定】的转变。用持续的、自动化的验证数据，来指导我们有限的资源，投入到降低最真实、最紧迫的风险影响上去。