安全运营

企业安全从安全营运方面看，基本上不存在没有被攻破的系统，从体系架构方面看，大企业基本上都是设计了完美的防护体系。

阿里的核心思想不是防护， 以前振飞的策略是轻管控，重检测，快响应；师太上马了，估计也不会改，因为互联网业务基因决定了做不到。

智慧的安全运营和完美的防护体系并重，是否可以应对一下企业面临的安全难点和痛点。

阿里内部的安全体系，是业务效率和安全平衡上做得最好的。

我对运营的理解是：“运营”的核心目标是保障已经实施的安全措施达到甚至超过预期的效果。因此，和欠钱总的观点类似。

这个话题有意思，我的理解信息安全运营就是运用一切可以用的手段，实现反渗透、反泄漏、反黑灰的目标。做好事件的运营，提升处置效率，调整好防护设施的效果，都是围绕着这个目的

我们认为安全运营包括安全监控、安全事件分析与预警、应急响应、网络攻防，定义就不知道怎么下了

从pdca或者从规划、实施、运行、改进等角度看，我个人觉得安全运营好像应该包括规划、实施、运维的东西

这段时间，我发现这个大道理和万金油的好处，是可以从这个角度思考问题，然后让我们安全做的东西更具系统性，写出来的东西逻辑性更强。 还有那自适应模型、纵深防御模型等都属于这一类。当我们朴素的自觉的要做一件事时，但是找不到理论支持时，就去找这几个东西好像都可以支撑我们的实践

不好意思，我的话有歧义，我的意思不是说纵深防御属于pdca，我说的意思纵深防御和自适应模型属于大道理和万金油

pdca是战术层面的事情 安全运维还需要解决战略层面的mission和strategy 特别是不同公司里安全运维strategy要顺势而为

投入是表象，核心是所有IT能力，包括研发和运维能力自主建设。

当it的投入和效率的提升不能构成业务的核心竞争力，边际成本壁垒的时候，可能公司投入的资源不会太重。传统行业有自己的赚钱模式，it投入只是某种意义上的成本。而有些公司，一开始就赌it的投入在未来会得到回报，看似不计成本，但是熬出头之后大家就只能望洋兴叹了。

安全运营工程师就出现在了世人的面前。他们什么都做，看起来没有技术含量，但他们的职责非常清晰：为项目的最终目标负责。这里最重要的是解决问题，一切影响目标达成的因素，都是运营的职责。”

安全运营既要有传统意义上的项目经理的能力有要有丰富的安全知识储备、具体实践及清晰的运营布局能力。

团队大小在某种意义上讲，只能体现工作量多少和分工细力度，并不能体现运营效率和运营质量。当然，运营效率一般通过平台，工具，流程等体现，运营质量一般通过监督，考核，评估等体现，仅供参考。

是的，看看规划和分工思路，一般情况下成熟度、精细化程度和人数还是正相关的吧

是的，无需理会具体价值，但这件事对行业来说应该是助力发展的，大家如此关注，也是希望安全服务价值越来越大，盘大安全市场，人，安全生态。

不是安全这个属性的价值高，是这个属性所属的主体的价值高。学习强国这个app代表了很多。

价钱有时候真的能说明一切。都知道是溢价，真给你的话，就算是最简单的工作也得想办法做出花儿来，要不就闹笑话了。人家花钱的时候，就已经想好要把事情做复杂了。

钱不到位，简单的活儿就简单做呗，复杂的活儿都能简单做，何况其他

不过甲方安全，也逐步开始细分了。尤其安全运营，从粗略的安全管理逐步运营细化了，不断深挖，金融业老板怕被安全事件通报。

#### lake2 分享（安全运营心得）

本来8月答应了君哥要在BCS上分享安全运营的，结果时间不巧放了君哥鸽子，非常不好意思，小弟就通过今天 这个形式救赎一下。我看BCS上几个大佬讲安全运营都讲得很好，我就从自己的实践经历来讲一下，准备的比较 匆忙，大家见谅。

大家都在谈运营，我理解的安全运营是什么呢，除开系统研发之外的所有工作都属于运营，比如策略的调优、事件的跟进处理、 还包括安全意识的宣导。总之，一切围绕着提升安全能力的工作都属于安全运营

我自己在腾讯的安全团队待了十二年，在互联网安全领域的不断摸索，深深感受到安全运营的重要，也感谢腾讯的领导和同事以及外部安全专家、白帽子的帮助。我经常说安全是一个过程，要不断修炼，就是持续不断运营的意思。试为群友分享一二，各位行业大佬多多批评指正。

我毕业后到腾讯做的第一件事就是跟进Web漏洞扫描器发现的漏洞，当时的Web漏洞扫描器是腾讯扫描器之父保哥（后来跟君哥是同事）写的，当时主要检测SQL注入和XSS漏洞。因为SQL注入漏洞判断逻辑是比对两次返回页面的是否不同，但是有些页面是动态变化的，所以这里会产生误报，每天大约有50单。后来处理多了我每天看一眼就知道这个是误报，我想提升这里的效率，我就提出新增一个逻辑即多一次探测先排除动态刷新的部分，保哥从谏如流迅速优化了策略，误报大幅降低了 —— 这也是互联网行业一般喜欢自研的原因，可以迅速迭代。关于更多保哥和扫描器的故事可以参考这篇文章

https://mp.weixin.qq.com/s/U6WDyx3N56ln1XMZ0PEETg

后来我又经历了多个系统的建设和运营，通过多个案例，逐步摸索出安全运营的思路，也深深感受到运营才是王道。

再举个例子，08年的时候，网站挂马攻击比较多，腾讯就做了一个挂马检测系统，原理就是模拟JavsScript解析执行去判断是否是挂马，比当时主流做法虚拟机去跑浏览器检测执行exe效率高。系统上线后也是发现了很多网站被挂马，当时经常有新的网马出来，黑特征发现不了新的网马，所以得想办法自动发现新的网马而不是等新闻。通过对所有网马样本的分析，我发现网马大体可以分为两类：逻辑漏洞和堆栈溢出，前者一般是AX控件的download、exec、update这种函数且带有二进制文件的网址，后者包含关键字符串0x0c0c0c这种，所以我就梳理这两类特征作为通用规则，每天看数据，结果就发现了flash的一个堆溢出0day漏洞正在被网马利用，报给官方后得到了CVE-2009-1862。这个过程就是运营，试想，如果没有系统上线后就只看告警而没有不断的迭代运营，就不会有0day的发现。

运营思路主要是通过分析当前情况发现主要矛盾然后解决主要矛盾，这个主要矛盾解决后就有新的主要矛盾，所以运营是个不断循环的过程。比如前面提到的SQL注入漏洞误报就是一个问题，主要矛盾是页面动态变化，所以就增加一个流程先发现动态变化的部分去掉之后再进入比较；网马0day检测的主要矛盾就是需要提炼通用检测特征。

其实我们的好几个CVE都是通过运营发现的，包括这个flash的溢出0day，还有一个绕过flash同源策略的0day，以及当年针对phpMyAdmin的供应链攻击（当时还没有软件供应链攻击这个概念）。所以运营，是非常的重要

当然主要矛盾是不断发生变化的，需要不断运营调整策略。比如腾讯06年之前是IDC对外的高危端口，经过一系列整治（规范、策略），腾讯几乎不再有高危端口开放到互联网，于是主要矛盾就集中到了业务端口，主要是Web端口（80），所以主要矛盾就转移到Web漏洞利用和上传WebShell上，于是根据主要矛盾持续运营，大力研发Web漏洞扫描器和WebShell检测系统（后来发展为服务器安全系统“洋葱”），也按照纵深防御思路不断去优化迭代这里的策略，大概如图这样的策略，这部分也可以参考这篇文章

![](/media/202201/2022-01-17_151010_209394.png)

https://mp.weixin.qq.com/s/2qsSKn970XEBtbn1swmHAQ

接下来是QQ空间这种UGC业务大发展，主要矛盾变成了XSS、CSRF、XSIO这类攻击用户端的Web安全问题，也出现了几个大的XSS/CSRF Worm，让大家见识到了Web蠕虫威力；然后又是移动互联网爆发，移动APP的安全漏洞备受关注；智能手机横空出世，安卓、iOS带来新的安全风险；接下来是智能设备涌现，然后又是AI以及AIoT、区块链……总之，不同的时期有不同的问题，每个新的主要矛盾出现，我们都是通过安全运营来不断迭代优化我们的防护措施，不断的去提升安全质量

其实我们的安全运营就是对当前情况的分析不断发现问题和改进之，这里我拿出一个案例给大家讨论：当前是否存在问题，如果有，如何优化。PS.职业欠钱不能答这个题

这一段，欠钱总曾经在群里说过。

1、视野覆盖，保障覆盖率、正常率；

2、告警降噪，保障关单率；

3、多攻击阶段的检测（包含奇技淫巧、旁门左道），保障攻防对抗成功率和检出率。

能提个问题吗 这里的运营 指的是技术运营 还是指 其他方面的宣传 影响力呀

都有的，如我前面所述，除了系统研发之外的工作，我都统称为运营

嗯，我觉得这是一个典型的安全运营&数据分析的实战问题，等会由欠钱总发布答案，我继续码字

对的，假设有个下属拿这个来给你做半年度或者年度工作汇报

研究的系统是啥，防护范围是啥，目标是啥，指标怎么定义的

欠钱讲过的覆盖率、有效率那些我就不赘述了。前面谈的是技术运营，这里谈谈意识运营。公司大了，员工多了，会带来很多问题，那些没有安全意识的员工就是木桶的短板。安全团队应该抓住机会去进行安全意识教育。机会很多，我感觉有效的方法包括事件驱动教育、红蓝对抗、结合热点等。比如今天正好有个Facebook数据泄漏的新闻，就有同事在内部论坛问这个事，这时候就该安全宣传上了，讲一下危害以及正在进行的数据保护的事情，然后再跟论坛沟通推一波。事件驱动也好理解，整出漏洞了，找过去，业务同学肯定认真积极学习；红蓝对抗经过这两次HW，群友肯定更理解了。

流量越来越大，攻击次数越来越多，防护成功率却100%？

这里是不是有什么地方不对？

你是怎么判断防护成功了的？是不是其实没防住。。。

前面那两个图其实就是攻击次数增多，但是防护率持平和略降，从安全运营的角度是能看到问题的：防护失败次数增加。应该去捞具体的case来分析为什么没有防住，然后优化系统

一是对于攻击的识别是基于规则定义出来的，所以分母就天生依赖于规则，二是攻击超出了防守能力

好的，安全运营展开讲其实可以讲很久，我今天比较仓促，准备也有限，就到这里吧，等我整理下思路，有机会在某个会议或者写篇文章来详细分享下我对安全运营的理解以及实践。谢谢大家。

请教一下大佬，安全运营中你们是如何处理特例，特别是中高级管理人员的“例外”导致的安全运营缺口？

我理解是中高级管理人员的安全风险你们不推动？不不不，我们是要推动他修复的

问个关于安全运营人员配备的问题，运营是不是偏产品思维多一些，这里技术和管理该怎么配备呢？

不一定，系统运营应该是安全技术+数据分析多一点，但是如果你的是产品运营，那就是产品纬度要多一些

CEO开始谈到持续性运营的重要性，在不断的上新项目后，但往往忘记了项目后运营的价值，此刻，想问：1、在人力不够的情况下，如何深挖持续运营（不断盯）？2、每一个项目上线后运营需要跟其他部门联动才能促成，这里面有没比较好的打法借鉴？

1、如果人力不足，你就尽量让运营工作自动化，比如尽量由程序来分析数据，非常非常可疑的才由人看，提升效能。另外就是一些老旧项目可疑下线，比如前面我提到的挂马监测系统，因为现在已经不再是主要矛盾，我们已经下线；2、这个没有好的办法，跟他们协作吧

你好，感谢干货分享，受益良多！我想请教下，关于企业安全运营人员的配比问题，请问通常是如何分配的？我们可以从各种书本及论坛资料上找到最佳建议，例如100-200人建议配备多少安全运营人员，1000-2000人又有如何建议等。但是能否方便透露实际行业中，大家公司里面真实的人员配比情况吗？希望能够分享。谢谢。

看起来似乎并没有比例的问题。建议是跟同行业比，像我们就经常会跟领导汇报AT有多少人，jd、dd、B有多少人。。一对比领导就发现我们人其实是不够的,否则，你跟领导说，按比例应该有x个人，别人说工行也就这么点人，哪儿有你那么高的比例

这个我们没有特别去配置过，是按事情的多少来补充HC的

我提个问题，你怎么跟领导汇报说，我们今年做的好不好，应该拿5星还是3星啊

以及下一个半年的目标是什么？

也是类似的方法呀，进行数据运营分析，招聘相关技能的人来做，这种攻击数据里面有很多宝藏，说不定就隐藏了0day

各有所长，不懂挖洞的人也有优势，比如他可以不会局限传统的挖洞经验，往往有新的思路；我们团队也有挖洞技术相对弱一些，但是呢对数据分析算法很精通的同事，就让他做UEBA模型，效果肯定比挖洞的人强

安全运营有点像守金库，用成功率衡量结果无意义，纵然百万次防御成功，但一次失败就足以前功尽弃。所以在衡量指标方面，用0安全事件维持时间，然后横纵向对比发展会不会好点？另外，想问下有木有将防御成功次数和价值(比如减少损失值)挂钩分析的实践？

很难做到0安全事件，比如我们的入侵检测，定的是5分钟之内发现入侵，然后立即展开响应；以DDoS攻击为例，我们会按被D的损失来看价值

聂总说的规则优化这个比较技术了。要看具体是什么规则，然后去找主要矛盾。如欠钱所言，你招人就好

根据我们的经验，分母会动态变化的，只有不断去调优它，所以需要运营

关于防御成功与实际价值挂钩 这种作为安全人员确实能更直观的体现其价值 但如何去实践呢 也蛮关心的,之前工作过的一家公司就发现过一个越权的漏洞  被利用的话影响很严重 直接导致客户资金丢失,在领导看来可能就是一个小问题 修复了就没事了

问胡总一个概念的问题，对于运营和运维，是存在区别的吗？如何区分，有必要区分吗？

运营可以说是日常事务的运转过程，运维基本上就是系统的运行维护

不过，按照胡总的归类，“我理解的安全运营是什么呢，除开系统研发之外的所有工作都属于运营，比如策略的调优、事件的跟进处理、 还包括安全意识的宣导。总之，一切围绕着提升安全能力的工作都属于安全运营”，运营应该是包括运维的。

数据就是宝藏，大家以后没事多分析数据，就能出来oday和cve了。  lake总，问了组织架构的问题，就是安平和腾讯的几大实验室是什么关系？之间怎么配合

规则优化那个真的是要具体问题具体分析的，

我觉得，首先你选择的数据就要适合做这件事，选对了数据，规则做起来本身是不难的。

举个例子：

你想做黑客恶意命令执行的模型，黑客执行了一个 id ，你就想告警，那么黑客执行的id，和好人执行的id，到底区别是什么？

首先要找到的是真正有区别的地方。

比如，黑客是在php webshell或者java RCE环境下执行的id， 所以父进程是不是不同？

如果采集的字段里都没有父进程的字符串信息，仅仅是有ppid，一个数字，那你很难做出 php派生的 id 和 好人的 id的区别的

而且一个字段往往是不够的，这个id上下文的一些数据，这个机器所属的业务历史上有没有出现过，在这一个session（切片）期间，除了id，还执行了别的什么？

最后你会发现单命令可能就是很难告警的，但是：

一些特别的进程（php、java）派生的进程，业务历史上很少出现，而且上下文里还同时出现一些其他ps netstat之类的命令，一看就是有人不熟悉环境在探测。。。

最终才得到一个你想要的模型

1 安平的定位是啥？能否一两句讲出来，类似teg的专业合作伙伴这种

2 安平作为一个部门，核心KPI能列两三个不」

1、保障腾讯集团的安全，如有余力，支持腾讯安全业务

2、核心KPI就是不出大事。当然我们自己要细化更多的KPI出来。哦，现在我们用的是OKR，推荐

选对了数据，想清楚核心的区别，不断的分析数据，验证迭代

才可能得到一个误报低，灵敏度高的模型

lake总，请问安全运营的O怎么定，又会包含什么kr？能否举2、3个？

我们没针对安全运营定OKR，而是对整个事情比如入侵发现定

谭校长说过，人活着是为了风流快活的，不是为了不得病的。同样企业是为了赚钱的，不是为了安全的，所以互联网容易接受一些风险，别挡我赚钱，把病在早期治好就行，不过在有的企业，还真就是不能得病，你让我干啥我干啥，但你要保我长寿。这个指标，真是因人而异无法套用了

也算在非技术类了，我理解技术运营  就是 对事件分析，策略调优，数据研究类似这样的

咱们理解的有偏差，我理解的安全运营，相当于一套体系，里面应该有技术与管理，为的是日常安全事务处理，包括很多方面，如事件管理，变更管理，以及其他安全事务处理平台化，自动化等…

ceo的分享，是真的做到了运营，持续经营，挖到宝藏，创造价值，反馈迭代，做到更好，我们有时，嘴上说运营，其实只是把它给运维了这个不求抠字眼了，叫什么都行，能达到目的结果，叫管理也无所谓

我理解每个公司都有自己的组织和职责分工方式，但是无论怎么分工，安全出问题了，还是需要找到相关的岗位一起解决。我们这边是通过虚拟运营小组的方式，安全主导，同时卷入OP、BPIT、SYS等相关岗位一起来处理。所以有的时候不太好在概念上给出清晰的边界，结合自身情况，能解决要解决的问题就行了

体系最重要的是目标，这个目标应该是运营与运维产生区别的原因。

胡总，向您咨询一个问题，腾讯有那么多用户的数据，请问在用户数据泄露检测方面有没有什么建议？

比如常用的四要素及一些敏感的个人信息，这一块的泄露还是比较容易引起Pr风险的

在可能泄漏的关键地方布防检测；数据加密；权限审计控制之类的，我们专门有个数据保护项目，规定了一系列的措施

嗯，目前我们也是通过自研的统一权限系统来管控业务的资源和数据权限、通过加密系统来推进在线离线业务数据的加密，但是有一个问题，就是有没有一种有效的手段可以 检测到所有业务系统里尚未进行加密的数据？比如存储系统扫描等

其实也算是一个分母检测的问题，就是如何发现有遗漏的或未知的『分母』存在

这是大实话啊，漏洞和安全事件处理上也有一套很健全的制度了

作为安全刚起步的小企业，天天再跟waf大量告警做斗争，感觉有点价值不大，有什么好的指导建议吗？

具体是什么误报，你要逐步消除误报规则啊

我们的WAF也有可能误拦，我们做了一些规则来解决：较多ip的同一URL拦截可能是误拦；拦截页面提供用户自助点“误拦”，较多用户点击人工查看；……

刚开始可以让厂商人肉把waf日志过一遍，把大量的误报的规则先去掉，以后添加规则尽量透明模式并灰度发布一段时间，排除日志里面的误报，然后再启动策略

一般都是扫描探测类较多，大部分都能被waf吃掉，但是也是需要排查漏过的，规则调来调去，另一方面可能是我们缺少一些手段比如对后端流量的监控，难以聚焦真正有害的信息

一样的问题，怎么发现成功的攻击，数据分析感觉要投入很大，小单位怕承受不了

最近省内hw，我们是这样干的，在网络出口处搞了一套天眼，然后流量经过绿盟waf以后，全部已经卸载后的流量又搞了一套微步的TDPS，在TDPS上能看到绿盟waf漏报的，然后在web负载均衡后面有上了一套f5的AWAF

整了两层waf，原来由于历史架构的原因，第一层waf对https没有防护能力，又整了一套新的waf

我们的方案也是这样，但是问题是即便漏过了有些其实也是无意义的，比如php的注入攻击漏过了，但是它攻击指向的资产是java类的，这个目前还没看到这么智能分析的，也缺少能这么灵活自定义的

关于waf告警的谈几句，waf上线前期的确有必要上去看看告警，调整策略，但是后面再看意义不大。waf是靠外侧的拦截，会有很多无关紧要的扫描，没什么意义。个人觉得拦了就完了，重点要看后面没拦截的，再去看为什么漏拦截了。要建立检测漏拦截的能力，弄个ids放在后面、建立日志分析等等

目前没能力搞红蓝对抗，只能做渗透测试和代码审计，SDL暂时也没法推动

今年搞了一次运动，基于每个业务功能做了一次梳理，主要系统解决了大部分问题。

之前做过点，主要是sql注入，越权和文件上传下载，命令执行，可以写exp验证

先拿到代码，关键函数走一波，找调用，看是否有防护，或者看框架本身是否自带防护，如果没有，尝试手工验证，成功的出 exp，https://mp.weixin.qq.com/s/AmSqsFOhsCIj2Xb1QNBtlw

集体领导、民主集中、个别酝酿、会议决定。制衡各方形成合力还是需要机制和手段。其实具体执行起来，基本都是复用网络安全领导小组。

从运营的角度来说，发公告那一周应该补丁或者缓解措施就应该做完了，出exp的时候只是验证一下

补丁没出的话，靠安全策略缓解,

## 安全运营数字化体系：

1、主机安全：

A）操作系统：分类（小版本）/每天、安全基线/每天；漏洞类型和数量/每天；

B）资产信息：ECS总数/每天；

C）Malware：恶意软件数量/每小时；

D）指纹信息：新增进程/每小时；

E）安全软件：安全软件部署的数量/每天；

F）软件升级：自动化补丁涵盖率和数量/每月；

G）漏洞信息：CVE的CVSS在9.0-10.0修复的比例和数量/每月；

2、网络安全：

A）EIP/SLB：EIP/SLB数量/每天；恶意湍口统计/每天；

B）流量：总流量大小/每天、TOP IP攻击情况/每天；

3、应用安全：

A）WAF：WAF拦截数量/每天；

B）漏洞数量：应用漏洞/每周；

4、安全事件：

A）应急响应：应急响应数量/每月；改进Action执行情况/每月；应急响应事件时间；关停时间/分钟

B）安全事件：安全事件数量/每周；

C）调查：调查响应时间；调查事件数量/每月；

5、账号管理：

A）账号：特权账号开启MFA数量/每天；普通账号数量/每天；特权账号新增数量/每天；使用账号密码的数量/每天；弱口令数量/每天；账号密码修改时间周期；

6、数据安全：

A）传输加密：高价值系统传输加密数量和比例/每月；符合FIPS的数量和比例/每季度；

B）存储加密：高价值系统/云产品存储加密数量和比例/每季度；符合FIPS的数量和比例/每季度；

7、安全培训：

A）运维：培训运维的数量和比例/每半年；

B）交付：培训交付的数量和比例/每半年；

C）网络：培训网络的数量和比例/每半年；

D）研发：培训研发的数量和比例/每半年；

8、威胁情报：

A）机读情报：机读情报更新频率/每周；机读情报准确率、机读情报时效性；

B）IoC：IoC更新频率/每周；IoC准确率、IoC时效性；

9、威胁检测：

A）基于规则：规则更新频率/每周；遇到新增规则的时间/小时；

B）基于统计：统计模型更新频率/每周；

C）基于行为：行为模型更新频率/每周；

D）基于机器学习：机器学习模型更新频率/每周；

10、时间维度：实时/每小时/每天/每周/每月/每季度/每年

11、评价体系：待补充和完善；