小步快跑，快速迭代：安全运营的器术法道

文｜腾讯安全平台部 lake2

一、前言

在进行安全体系建设工作的时候，人们往往容易看到的成果是新研发了一个安全系统，采用了一个新的技术，似乎做出一个系统采用一种技术就可以一劳永逸地解决某类问题了。可现实告诉我们那是不可能的，因为我们面临的安全威胁总是在变化，安全本身是一个动态的持续的过程，没有任何技术和系统能够覆盖完全一劳永逸，我们既需要有系统有技术，也需要对系统和技术做持续的、长期的、细致的、有效的运营，不断对系统和技术进行迭代优化，最终才能真正解决问题。

所以，笔者的观点是，安全系统研发完成投入使用是解决了从无到有的问题，是万里长征第一步，而之后的安全运营工作才是从有到优的不断升级之路。

本文笔者就参加安全工作十余年来，与benjurry、coolc、炽天使、plan9、chair、apple、宝哥、老牛、职业欠钱、Superhei、cy07、cnhawk、ayazero、iceyes、剑心、大波哥、flyh4t、君哥、lion_00、cnbird、avfish、xti9er等一帮师友以及与“基于量子透明计算的可信自主可控区块链式拟态安全态势感知的威胁情报联盟微信交流群”群友的学习交流并结合行业大V的一些观点，就安全运营的思路和实践试探讨之。

二、安全运营是什么

互联网业务的快速发展产生了很多新概念，最重要的就是系统/产品的“运营”，即指系统的快速迭代过程，用朴素的语言描述就是业务遇到问题“先抗住，再优化”。

那么，什么是安全运营呢？信息安全类工作只听说过写脚本、挖漏洞、黑网站、建系统，“安全运营”到底是要做什么？这个工作曾经一度让笔者很迷茫，我相信很多刚工作不久的新人都有这个困惑。记得腾讯漏洞扫描系统之父、“如入无人之境”（见聂君《企业安全建设指南：金融行业安全架构与技术实践》）的安全大神宝哥刚刚工作不久也在例会上提出过对安全运营的困惑。

经过多年的工作经验沉淀以及与圈内大佬、同事们的反复交流讨论，笔者终于大概摸到了安全运营的门道：使用系统、发现问题、解决问题 —— 使用安全系统，在使用过程中发现系统和策略的问题，分析问题提炼出优化点，反馈给系统迭代优化，最终达成完美解决安全问题的目标。相比于传统行业，互联网业务本身讲究小步快跑快速迭代，所以运营的迭代也很快，安全运营也继承了这个特性（更多关于互联网业务系统运营的思路，可以参考腾讯的海量服务之道）。

把安全系统真正用起来，发现安全系统的问题，不断去优化安全系统，提升系统能力最终解决安全风险，就是安全运营的核心思想所在。但是，知易行难，人们往往容易陷入两个误区：

1）做出一个系统更容易被看到，但运营系统需要大量的时间沉淀并且不容易被看到，人性嘛，总是趋利避害的，所以就出现了“重建设轻运营”的情况，大家都想做系统做产品蹭热点出成绩引起领导关注，而不去关注枯燥的运营工作，最终出现系统做了一大堆却无后续运营的烂尾楼项目；

2）技术人员更容易陷入到技术本身，追求高新技术的研究应用、参加各种比赛以及漏洞挖掘利用，而不乐意做更偏工程化落地的梳理类、推动类、管控类的安全运营工作。这两种情况都是舍本逐末，因为我们工作的核心是发现和解决安全风险，不是做系统或者使用先进技术，切不可本末倒置。所以，安全运营就是踏踏实实不投机取巧地优化系统，要“扎硬寨打呆仗”。

前文所述宝哥十五年前在腾讯安全中心负责研发漏洞扫描系统（内部代号“洞犀”），早期代码都出自他之手，他这部分工作是研发；笔者负责处理漏洞扫描系统发现的漏洞，在处理过程中发现SQL注入漏洞误报多，经过分析误报可以分为三大类，各自可以采用若干策略优化，提请宝哥优化系统逻辑，这部分就是安全运营（见《自研之路：腾讯漏洞扫描系统的十年历程》）。

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

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

三、衡量标准探讨

我们明确了安全运营是什么，那么，如何衡量安全运营工作的好坏呢？

首先，需要有一系列衡量指标。

有指标才能判断当前距离目标的差距。

根据不同的安全系统，可能有的指标有所不同，但大的指标包括这两大类：系统覆盖率、策略有效率和误报率。前者是指安全系统对被保护对象的覆盖比率，关注工程落地，比如公司有一万台服务器，目前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改造项目中，提炼的三个重要指标是覆盖率、合规率、待改造域名数（有率有量，避免偏差），然后运营同学不断推动，提升指标接近目标。下图是某个时刻的HTTPS项目指标通过SOC平台（我们内部叫安全服务中心）展示：

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

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

这个检验是要真正的检验，所以提到是独立的蓝军。作为负责人，不要被虚假的安全感迷惑，不要听信“互惠”结论、虚假数据和PR文章，一定要切实检查 —— 黑客可不会管你这些的。根据实战经验，吹嘘得越厉害，脸就被打得越惨。

近期我们的WAF（内部代号“门神”，基于此的外部产品名腾讯云T-Sec Web应用防火墙）和HIDS（内部代号“洋葱”， 基于此的外部产品名腾讯云T-Sec主机安全）采用了机器学习和语义分析来做部分检测规则，AI应用到安全场景是个新东西，所以特别邀请腾讯内部安全人员和外部白帽子来测试效果，结果发现一堆问题，赶紧修复之。这个案例也说明，刚刚做出的系统一定会有各种问题，运营才是解决问题优化系统的唯一途径。那些像Nmap、Metasploit、Snort、Pangolin、ZoomEye这样的传奇安全工具和系统，哪一个不是不断运营优化磨炼出来的。

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

每一个漏洞每一次安全事件都是一次练兵的好机会，团队需要抓住机会去复盘，看看哪些点做得不够，哪些地方还可以优化的，举一反三，从一个问题优化一类问题。没有机会怎么办？那就让蓝军创造机会。

以漏洞检测系统为例，研发安全团队对每一个外报漏洞都会做复盘，也有固定指标，比如为什么漏洞检测系统发现，是什么原因导致的（策略问题/未抓取到URL/未经过上线前/系统bug……），然后根据复盘问题进行归纳分析总结优化，不断迭代系统和策略，直至完全解决。下图就是一段时间的外报漏洞复盘对比图，可以看到，先前存在比较多的“普通反射型XSS”被优化掉了（说明漏洞检测系统对反射性XSS的发现能力提升了），新的漏洞类型主要是逻辑漏洞、存储型XSS、权限绕过等自动化系统相对难以检测的漏洞，这是下一阶段运营团队继续想办法解决的重点工作。

很多时候复盘需要对若干个案进行总结归纳分析提炼，所以数据运营分析意识很重要。

四、运营方法论与实践

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

1. 关注落地

第一诫：运营要关注落地，即解决问题，一切不以解决问题为目的的运营都是渎职。时刻自省，有则改之无则加勉。

2. 抓大放小

问题总是很多的，不要眉毛胡子一把抓，先解决主要矛盾，等主要矛盾解决了，排第二的次要矛盾就成了主要矛盾，继续解决之，直到问题解决。也就是说一段时间内解决主要问题允许一定的次要问题的存在，但要解决计划。

所以，抓准主要矛盾很关键，安全负责人要对安全风险和当前状态有清晰的认知，切忌好高骛远。比如企业连高危端口隔离都还没做就不要去研究APT对抗，低级漏洞都修不完就不要去研究高精尖技术。

2005年，腾讯的安全团队刚刚成立，千头万绪，有很多需要建设的地方，分析当时的安全事件，发现主要矛盾是来自互联网的攻击，于是重点工作就被梳理出来了：对外端口管控。经过近一年的努力，各种流程规范、安全策略的推动执行，最终实现了服务器的非业务端口不对互联网开放，一下子控制了来自系统攻击的安全威胁，剩下的就是全力控制Web应用层攻击。

互联网行业唯一的不变就是变化，主要矛盾也不是一成不变的，负责人的技术敏锐度很重要。

2012年，struts2的一个RCE漏洞被公开，互联网一时间腥风血雨。struts2执行命令的检测突然就上升成为主要矛盾，但是洋葱团队不调整主要矛盾，还在按部就班地继续做既定策略，以致有几个使用struts2的网站被白帽子发现了漏洞提交到TSRC。后来被TSRC吊打之后，洋葱团队补齐了执行命令的检测策略，解决了这个风险（美国征信巨头Equifax 2017年的数据泄露源头就是struts2漏洞）。后来，我们按抓大放小的思路把入侵行为的核心检测能力分为WebShell、CmdShell、Scan、Malware、Backdoor、Brute、Connection、Clean八大类几十分类几百小类（与ATT&CK有异曲同工之妙），逐步完善，又建设运营了八年，时至今日勉强可以自夸。

3. 控制增量

当我们有一个新系统/策略要上线的时候，会面临从零覆盖推到全覆盖的过程，特别是大的安全系统/策略，还不是一时半会能搞完的，得打持久战。这个时候遇到的大部分不是技术问题，而是管理问题。我们可以找流程上的增量关键节点来控制，长期下去必然实现全覆盖的目标。

比如HIDS，它的关键路径就是服务器交付，当交付服务器的时候OS里面就带上HIDS，增量就控制住了，剩下的就是解决存量的问题。存量一方面按部门去推动安装，另一方面随着服务器的自然淘汰，覆盖率肯定是逐步升高的。当年我们就是通过这个关键路径实现了“洋葱”全覆盖。再比如DDoS防护，它的关键路径是机房规划，我们把DDoS防护系统（内部代号：宙斯盾，基于此的外部产品名腾讯云T-Sec DDoS防护）嵌入机房规划流程，最终也实现了全覆盖。

收敛漏洞也是一样。派人专项人工找漏洞，一下子发现了很多漏洞，乍一看是很有效果，但其实这是治标不治本的，因为新的漏洞正在源源不断的产生出来。所以人工找漏洞这种策略短期内快速收敛安全风险可以，作为长期工作持续运营是不现实的。最佳实践就是SDL，或者与时俱进采用DevSecOps，安全左移，从源头上控制漏洞产生 —— 当然，漏洞是不可能完全没有的。

4. 原生安全

原生安全（Intrinsic Security）这个概念，笔者理解它跟DevSecOps表达的把安全嵌入研发运维流程有点相似，这里表达的意思更偏重于“出厂默认安全”，也就是把一些安全策略和安全系统内置到业务架构和系统中，让系统在不作改动的情况下是安全的。

SQL注入漏洞就是典型的架构设计问题：Web技术架构不区分数据和代码，以致产生漏洞。一旦架构被广泛应用，出现安全问题修复困难。这么多年了，SQL注入漏洞还是存在而且量很大。试想，如果一开始设计时就使用SQL预编译，就不会存在SQL注入漏洞了；类似的还有缓冲区溢出、ARP攻击、SYN Flood、Tomcat默认密码等，都是最初的设计问题。

如何实施原生安全？来看实例。

旧版本的Tomcat安装后会打开8080端口作为管理端口，用户名是admin密码是空，是很方便，但是会带来安全问题，黑客只需要用admin登录发布一个war文件的jsp WebShell就可以控制服务器了。那怎么办呢？按照原生安全的运营思路，告诉运维同志你不要去官网下载Tomcat了，我给你一个定制好的Tomcat，各种安全配置都配置好了，危险的配置关掉，运维同志直接部署好就是安全的。再举一反三一下，是不是所有的第三方组件都可以这样控制起来？是的，这就有点安全运营的意思了，所以企业内部软件源就诞生了，安全在这里做管控，可以一定程度上缓解软件供应链攻击（见《源头之战，不断升级的攻防对抗技术 —— 软件供应链攻击防御探索》）。

类似的，安全系统也可以嵌入业务架构。最开始我们的WAF系统是主机版（顺便缅怀一下门神之父Gino），需要一台台Web Server安装模块，还要兼容Apache、Tomcat、Nginx等各种Web Server（这些主流Web Server就算了，还有好多长尾），弄得很吃力。后来发现公司有统一的接入层，直接对接就好了，一下子就覆盖大部分，业务同事只需要在接入层管理界面点启用WAF就行，不用再去进行繁杂的Web Server兼容和部署工作了。

随着基础IT设施上云，云平台来做网络和系统层的原生安全有得天独厚的优势。当然，这对云平台本身和租户又带来了新的安全问题：虚拟机逃逸攻击、微隔离有效性、云资源滥用、云存储/docker镜像/Serverless等新技术产品带来的安全漏洞、云管理账号凭证泄漏等，这些都是安全运营要去解决的。

5. 灰度放量

灰度这个其实是借鉴互联网产品运营的思路，安全系统、安全策略也需要灰度发布，逐步放量观察，尽量减小bug带来的运营事故和运营误报影响面。

6. 群策群力

与DevSecOps宣扬的理念一样，安全不是安全团队的事，而是业务团队和安全团队共同的事，安全问题需要多方共同协作，不要孤军奋战。况且很多事情必须业务团队来执行，安全团队也做不了。

腾讯内部的安全是以“开源协同”的方式开展工作，我们在各个事业群都有相应的安全接口团队，大家一起讨论本事业群的主要矛盾，制定相应策略，然后这些策略就是靠他们去推动落地，包括上线前安全检测流程、系统覆盖、数据保护专项推进、安全工单跟进、意识宣导等。甚至我们已把部分安全系统做成平台化，定制化问题可以由业务团队来写模块和插件 —— 门神WAF即提供Web阻断能力开放平台，业务团队可以调用实现账号/IP/URL封禁、频率限制、CC攻击防护、业务防刷等能力；宙斯盾也提供四层和七层阻断能力；洞犀漏洞扫描系统可以由业务同事来写某个专用漏洞检测插件。

最近的SaltStack漏洞挖矿事件给了我们一个启示，业务使用了哪些第三方组件单靠安全系统来检测是不行的，必须依靠业务深度参与。类似的，客户端引入了哪些组件和SDK，也是需要业务主动上报的。

7. 借力复盘

这个就全靠同行衬托了。

普通人的安全意识是很薄弱的，企业里的员工一定是短板，好多攻击都是员工打开了邮件附件中木马引起的 —— 需要经常性地、反复地、实际地教育。一旦业界出现重大安全事件，瞬间会成为大家关注的热点，大家都会关注为什么会出这个事件，这时候就是绝佳的安全意识教育的机会，赶紧行动起来，指点一番，把安全意识植入进来。另外，他山之石可以攻玉，不要只看笑话，要搞清楚友商发生安全事件的原因，复盘自己是否存在问题，也是一个几乎不付出成本而获得经验的好的机会。

8. 不断学习

技术发展很快，要时刻关注新的技术发展趋势，新的攻击方式出来首先要想到自己的系统能不能防得住，新的技术架构出来要想到怎么去进行安全保障。比如基础IT系统上云、IPv6普及、远程办公兴起、AIoT大发展……这些新东西会为企业带来什么安全风险，都必须是一个卓越的安全运营人员要考虑到的。宙斯盾DDoS防护系统很早就关注到IPv6的问题，也是腾讯内部第一个支持IPv6的安全系统，接下来各个安全系统和产品都陆续支持IPv6，及时清除了防护盲点。

安全领域的新概念也很多，像最近几年兴起的AI应用、态势感知、威胁情报、零信任、自适应、红蓝对抗、SOAR、DevSecOps、XDR等非常之多，也是安全运营人员要去了解的。但也要注意甄别，因为有些新东西是基于某种目的包装出来的，本身没有实际意义，不要听信PR，一定要实地检验。当然，PR效果也是效果，类似态势感知系统，虽然感觉对安全运营没有太大意义，但是在安全值守或者领导视察的时候有个态势感知大屏感觉还是挺厉害的。

9. 纵深防御

纵深防御是指安全策略要从多个维度去考虑，层层设防，而不要把某类安全风险的发现解决压注在单个策略/系统，否则一旦被突破，则无法防守。前文所述struts2漏洞的反面案例即是如此，当时洋葱团队的理由就是struts2漏洞有漏洞扫描系统去检测和推动修复，HIDS没必要急着去补齐漏洞利用检测策略。

笔者负责洋葱的运营的时候就发现，普通的应用层木马的检测比较容易，但是涉及到rootkit就会棘手 —— rootkit已经先一步深入内核，与之在系统层面对抗非常困难。换一个思路，高维度打击低纬度，从网络层解决就比较容易。那个样本rootkit启动后会隐藏自身的所有信息，在系统层面看不到端口开放，但是网络层却可以 —— rootkit在系统层称王称霸，但在网络层就只能束手就擒。只需要远程扫描下端口或者网络里进行流量分析即可发现异常。下图的bash脚本是另一个纵深检测思路示例，利用某Linux rootkit的疏忽，通过比对ps命令返回和/proc下的信息来发现被其隐藏的进程。

所以，我们的安全体系应该采用纵深防御思想，在建设安全策略、事件复盘的时候要从多个维度去看，避免单点。

10. 关注未知

笔者以为，“关注未知”是尽责的运营和优秀的运营的重要区别，同样是发现问题，可预期的问题就不是大问题，而未知的问题可能会是极其重要的问题。因为有个术语叫做0day，到了我们把基础安全都做得很好的时候，攻破系统的，一定是你未知的手法。当我们宣称漏洞都被修复了的时候，是不是只是指应用和系统层面，网络设备的漏洞呢？

所以，运营过程中，一定要有发现未知的意识，一定要考虑到你的策略失效或者被针对绕过的情况。笔者一直宣称，优秀的安全策略是不依赖黑名单、通用且像公钥密码算法那样可以公开的。

我们制定的运营策略，大部分是基于白名单和黑名单，但是介于黑白之间非黑非白的是灰名单。这一块就是未知，看不见才可怕，是需要重点关注的。以威胁情报提供的黑IP为例，既然都被拉黑了就说明攻击被人发现了，真正高级的攻击是不会再用被发现的IP的 —— 这并不是说黑IP没用，只是说对高级攻击者基本无效，当然高级攻击者也可能犯低级错误。

对未知始终保持敬畏之心，终极的攻防对抗（APT）一定是高维度打低维度，一定存在某种你想不到的手法，但是安全策略要尽量去覆盖，还要建立纵深防御即多点布防，APT再厉害总会触碰到一个策略 —— 当然，大多数企业连低级攻击都防不住，就不要好高骛远了。

后记

安全是一个动态过程，它随着形势在不断变化，运营就是发现变化趋势调整优化安全策略达到安全目标的重要手段。比如，今年疫情让许多企业开始支持远程办公，随之而来的是远程办公的安全威胁，短期内这部分企业的安全工作重点之一应该是远程办公安全保障。

以上只是笔者对安全运营的一些粗浅想法，欢迎探讨。

附录｜参考资料

职业欠钱，安全运营三部曲《我理解的安全运营》《谈一谈安全运营工作是什么》《再谈安全运营》

聂君，《我们谈安全运营时，在谈什么》

秦波，《大型互联网应用安全SDL体系建设实践》

谭晓生，《论CISO的个人修养》

赵彦，《两年甲方安全修炼之路》

聂君，《金融行业企业安全运营之路》

吕毅，《从运维到运营，信息安全进化论》

harite，《安全需要每个工程师的参与——DevSecOps理念理念与思考》

lake2，《胡珀谈安全运营》

附｜lake2企业安全九部曲（未完待续）

网络空间安全时代的红蓝对抗建设

Blade：企业安全研究团队建设运营思考

军备竞赛：DDoS攻击防护体系构建

自研之路：腾讯漏洞扫描系统的十年历程

企业安全应急响应中心建设理论与实践

捻乱止于河防——浅谈企业入侵防御体系建设