谈一谈安全运营工作是什么 – 作者:美团点评安全应急响应中心-安全小百科

本文作者：职业欠钱

自从一年前写过《我理解的安全运营》之后，这一年来，安全运营这个词有一种火了的感觉。有些乙方开始举办“安全运营”专场，大家坐一起探讨到底安全运营是个什么东西，以及有点什么“运营技巧”。甚至有一些乙方提供了“运营平台”、“运营服务”。

时间上的先后，有时候会让我有种错觉，仿佛自己点燃了这一轮创造新词的***。当然客观认知到上我个人肯定没有这么大的影响力，那到底是什么驱动了这一轮业界对“安全运营”的关注呢？

我理解可能有2个点：

1、安全的风险直观化

2、建设期已过，可以开始追求结果了

第一点的理解，其实是从 tk 教主某一次峰会分享得来的，大致的意思是，信息资产承载的价值，随着人类活动的发展，正越来越高。粗浅的理解，15 年前，我在大学宿舍的电脑中毒了，顶多就是我宿舍的同学不能打游戏了，存在上面的资料丢了就丢了，没什么影响。而前两年，Wannacry 的肆虐，让很多医院之类的基础设施系统崩坏。甚至有人弄过入侵**起搏器之类的活动，可以让移植了人工**的病人直接死去。

再加上大家的资金安全、个人隐私，几乎都在各种 App 上弄几下就可以捣鼓来捣鼓去。这里的风险其实是越来越直观的，只不过还不够有具象化，大家老以为是在电影、新闻里的，却跟自己无关。

一直到最近，国家层面举办的某些大型真人实战演练活动，把乌克兰、委内瑞拉电网之类的案例，在国内进行真实近似的呈现。很多组织的决策者发现，哎呀，原来安全不能只是雇 2，3 个人合规对付一下就行了，真出事影响还是挺大的啊。

所以，大家开始戳破了以前其乐融融的假象，不再因为买了几个安全设备往角落里一丢，半年出个报告对付一下合规检查就满足了。

一旦实实在在的去追求一些“应当可以实现的安全效果”，大多数人其实就会自觉走到“运营”这个方向上来。毕竟能力的建设只是第一步，用好它，迭代好它，才可能出结果。

第二点的理解更简单，安全从业者之前天天嚷嚷着，安全不受重视。有些企业要不是为了上市合规，真的自己业务层面都朝不保夕，肯定不会雇佣安全工程师。招俩安全工程师往往也是给业务拖后腿的，这不让干，那不让干，业务跑不快，企业生存都成问题。

但是客观的说，也有不少企业已经过了最初野蛮生长的时期，如今市值、体量、社会影响力已经不可小觑了。这个过程中，企业或多或少也招了点安全工程师来遮盖一些问题，只不过由于人数实在太少，所以大致上文档和技术沙盘图上，似乎可以假装自己做了很多工作，只是实际工作里，这些名词多数不管用（该出事还是出事）。

所以，在时代浪潮的推动下，基本的安全建设工作或多或少做完了，那安全团队也该实实在在的考虑一下，如何在日常工作中，从“有做过”，转向追求“本可以做到的更好的目标”了。这个过程，其实就是“运营”。

说到这里，我想虚构一些例子，给大家解释一下，行业里的安全工作可能是怎么迭代进化的。

比方说某一家互联网公司，已经有了不少的用户，业务模式也趋于稳定了。突然有一天被攻击，之前都是运维和开发捎带手的去解决，因为业务发展不错，他们不想自己亲自去处理了，就想干脆招个安全工程师吧。

这时候，一个人的安全部出现了。安全工程师初来乍到一看，公司啥都没有啊，文档制度上线发布流程服务器运维规范，办公网准入防病毒 SSO 双因子因素，反爬风控防作弊。。。

得了，这个工程师开始张罗一大堆的工作，写文档（拿行业里的模板素材换个公司的 LOGO），勉强算解决了文档制度，能执行多少暂且不论，聊胜于无吧，起码合规检查的时候有东东西了。

然后开始人肉去审核代码，也自己去黑一下公司的业务，发现点漏洞推动修复。日常有漏洞预警也知道开始响应了，同时张罗一些项目，逐步去解决防病毒、SDL、入侵检测、权限管理等数据安全相关的工作。

因为只有这么个把安全工程师（或者随着业务的发展，团队扩张到了 10 人以下），所以大部分的工作只能浅尝辄止，做完就算。这个阶段不追求什么最佳实践，能落地就算好的，更别说还有落地的时候被业务或者关联团队阻挠了，不配合了，无疾而终的项目呢。

当然公司因为规模也还小，没什么人盯着，所以那些事情即便不做很深，也没出啥大事（或者出不了啥大事）。被真人演习/某些对手盯上了另说……

可是，如果公司业务发展很快，成长的过程中，不断的成为垂直领域的明星。树大招风，一些典型的 case，都被行业主管部门甚至社会舆论给监督上了。老板觉得这些简单的问题怎么解决的不好，都被闹大了，安全团队就开始有压力了。

（嗯，潜台词就是，如果公司小，大概率是不会有这些压力的，所以安全团队可以相对舒服的继续干下去）

比如说，一个漏洞处理的不好，数据库被拖了，或者被入侵了，数据拿到暗网上去卖了。或者风控反爬之类的做的不好，竞对恶意的爬取数据做整合挖掘点东西呈现到了自己老板这。

老板就开始期待这一类的问题将来都得到一个好的治理。起码不能出现低级错误，本来很简单能做好的事，没尽力，漏了，这就很容易背上一些价值观不正确的锅。

我们从“有做一些事，以应对安全风险”变成了“基本功要做好，免得再出现这类风险不好解释”。大概率会发现，团队的资源和能力是不够的。

比如说，SDL，这是微软很多年前提出来的一个概念。从核心逻辑上就是把安全嵌入开发生命周期的每一个流程，这个思路帮助微软把 Windows 和 Office 系列的产品做到了后来的样子。这种思路是以项目为单位的，一个项目，从立项设计、架构评审、实现、测试、发布、运营的全周期都要安全工程师参与进去。

在国内，稍微大一点的公司，大家就知道，公司的项目多到可能成千上万甚至百万个。

而安全工程师，总共没多少人，分到 SDL 这个职责的可能更少，说不定就个把人。毕竟还有很多其它方向的安全工作要做，这几个人能整个扫描器把公司的每一个 Web 项目扫一遍，往往就对敢外宣称自己公司做了 SDL 了。更不用说白盒审计的时候那么多的误报，以及人工审查的不切实际了。

（这部分完全看公司实际情况，公司项目少，迭代少的时候，也有同行就可以每一行代码都自己人肉看过的。）

如果老板不在乎不重视（比如说偶尔出个漏洞，也没被大肆的 PR），其实这几个人也可以开开心心的做点自己喜欢的事情，有事应急一下，没事线上的漏洞就一直躺着。

但是如果老板就怕这里出事，希望因为安全工程师的存在，力所能及的减少外面能发现漏洞的可能性，每一个外部报告的漏洞都追究一下是不是真的技术上很难规避，SDL 团队就要发愁了。

一方面，人力 cover 不到全公司那么大的工作量，另一方面，不能混日子了。

这时候只能开动脑筋，抓主要矛盾啊。

分析一下历史过往案例，发现一般新项目上线的时候，没经验，被捅得最多，所以把有限的人力集中起来，新申请域名、项目上线，人工至少过一遍。一旦上线成功之后的项目再迭代（这个才是大头），团队就实在没办法了。

通过这种方法，还真是每一次新项目都能发现很多非常粗浅的漏洞，但是，毕竟覆盖率极其有限，那么多的其他项目成天的迭代，很难不出事啊。

这靠人终究不是个办法，咋办呢？整个扫描器吧，商业的还是开源的或者自研的无所谓，总而言之，有了一个扫描器，开起来，可能会被业务骂死：以前都没事的，你一扫我的业务挂了，监控告警刷屏了，数据脏了，你赶紧给我停了。

于是给业务解释：我不扫，以后黑客也会扫的啦，我会尽量规避 update/delete 相关的危险资产，有风险的 Poc 尽量不发啦。你也稍微处理一下告警监控，把我以后扫描触发的告警都屏蔽掉不要紧张啦。

好不容易达成一致，天天扫，SRC 还是天天报漏洞，尤其是一做活动就报漏洞。

以前不操心也就算了，现在每次 SRC 报的漏洞会琢磨一下，为毛扫描器就扫不出来呢？为毛人工当年看的时候就没看出来呢？

然后发现黑盒扫描器各种短板，比如 URL 不全拉（赶紧各种 NIDS、AccessLog 补救）、调度问题、POST 主动规避导致没检测到、爬虫引擎效率或者能力问题、某些资产 payload 积累问题……

这些问题以前不想管，现在老板重结果了，也不是不能解决，那就整呗。

随着自己能力的提升，某些类型的问题的确在逐渐减少，当主要矛盾解决掉之后，次要矛盾就上升为了主要矛盾，再继续解决。

这时候发现，还有很多漏洞，要是有源代码就能很轻松的扫出来。于是上个白盒审计的产品，一扫，乌压压的上万的告警，仔细一看，就 4 个有效的，还是低危的 XSS……

差点就崩溃了。

那也得整啊，跟扫描器一样，其实要弄自动化的时候，甲方就这几个人，这点时间，不可能追求解决世界上所有已知的漏洞不要出现在自己公司。追求把公司历史上出过、最常见的，而且解决起来成本不高的漏洞，做一个未来一劳永逸的控制，是更迫在眉睫的目标。

于是我们就把白盒审计自带的所有规则都干掉，从头开始，自己按照 OWASP Top 10，还有 SRC 历史数据上高频出现又很容易识别的规则开始，吭哧吭哧写了几十个规则。

根据自己的经验和人工的整理，不断迭代几个版本，这下好了，自研的白盒审计能力也有了。每次 SRC 漏报的时候，白盒的同学也开始要复盘，这事我从源码上是不是一定扫不到呢？

新项目人工审计、黑盒自动化例行化、白盒例行化，都整上来了，肯定比之前好多了。

可是，这样就好了么？

其实没有，越权这种逻辑漏洞如影随形，几乎成了各大 SRC 的心头病。如果你是个新的白帽子，不知道挖什么漏洞，你可以去试试越权，估计很快能有成就感。

而且越权漏洞这玩意吧，成本贼低，危害却高很多，比 XSS 什么的利用起来爽多了，动不动就能看别人数据，操作别人的资产。PR 风险也大。

老板咄咄逼人之后，这事也必须解决啊，黑盒白盒其实都搞不定。垂直越权黑盒相对还有点可行性，但是水平越权这种东西，有时候业务的逻辑介于公开和半公开之间，扫描器弄俩账号去看一个 ID，返回的结果是一样（证明 B 账号看到了 A 账号的数据），so what? 这事允不允许只有业务自己说了算，它是个业务逻辑强相关的。

虽然扫描器扫出一大堆的可疑 list，但是人工去闭环成本实在太高了（回到了老问题，人一个一个看是看不过来的），哪怕你临时找到了几个真的有问题的点，但是它不是个长久的事。

问题必须解决，自动化又解决不了，必须人工判断，安全工程师的人工又显然 cover 不了全公司。所以顺理成章的得出一个结论：这玩意得业务自己人工 check。

于是很开心的跟业务说：你们得交付安全的代码，这是你们自己的责任啊，越权漏洞这么难搞，风险又大，出了事不光是我们倒霉，你们也倒霉啊。你们不是有 QA 环节么，能不能每一次迭代，QA 动作把越权测试用例当成一个“必选项”啊？

业务听了听觉得也有道理，但是你怎么知道我做没做好呢？

安全工程师说，我也不知道啊，你要是做了，就在代码里留个暗号，我回头去源码仓库里扫这个暗号，谁做了就说明他知道了，没这个暗号我就发工单提醒他。

业务说，那要是有人恶意填这个暗号就是不干活呢？

安全工程师说，这我也没办法，但总比之前强点吧。

于是全公司开始吭哧吭哧照着这个办，一年之后，越权漏洞整体还真下降了 80%。（对，的确存在少部分不正直的人，或者没做好的人）但这真的是一个不错的成绩了对吧？

然而老板却仍然不满意，他觉得，剩下那 20%，难道就真的没办法了么？

安全工程师回答，有是有，就是成本贼高，得把业务直接访问数据库给拆开来，弄个中间层，中间层负责访问数据，业务每次请求都要带上用户的身份票据，根据票据权限来判断返回数据与否。这样一个数据加上中间层，大家都迁移改造出去，未来上新的业务，因为没有自由链接数据的权限，也没有自己设计权限的自由，所以就没机会再犯错误了。

微信的全程票据和 Google 的 Gmail 都是类似的思想。

那就整吧，于是吭哧吭哧开**据服务，统一全局权限管理系统，一个一个接。

至于啥时候能接完就不知道了。

一边干啊干的，突然发现团队小伙伴越来越不开心，闹离职。原来，以前挖洞很爽的小伙伴，天天人肉看业务代码，审计出来的都是那些低级漏洞，实在是没劲。于是把能自动化的都交给黑白盒自动化审计平台，偏逻辑类的漏洞交给上面“水平越权治理”类的方法。

为了让业务可以多几个 QA 环节自测的必测项目，还得结合公司发布平台弄一些自动化的问卷，结合业务特性出推荐的必备测试项，于是一个“威胁建模平台”诞生了。

在这个平台上，结合业务历史漏洞、涉及到的敏感数据字段和流向，员工参加线上安全培训和考试成绩（尤其是某员工名下漏洞特别多的时候），综合给评分，建议对应的同学、管理者有针对性的提升自己的能力。

比如说，扫描器很多主动规避风险的 URL 资产不敢扫的，可以让业务自助授权强行扫，例行化，有些白盒审计出来不一定是漏洞（仅仅是不符合安全规范），提醒业务去按规范编码。

于是很多模糊地带的东西，通过打分评价激励体系，鼓励员工去做多一些配合让步，可能会进一步提升安全性。

但是这些都是一些运营的思路，如果老板还是不满意呢？

答案可能比较简单，招更多的人，做更多的自动化项目（比如 IAST），做更多的人工介入（比如 Google 的重点项目 Chrome，当年是有 4 个安全工程师直接在项目组内从头跟到尾，沙箱之类的安全架构设计和实现都是这几个安全工程师搞出来的）。

整套组合拳打下来，最终，公司的产品安全性一定是有提升的。而这就是一个典型的 SDL 运营套路。这个套路里有什么技术含量么？其实没有，只要站在“这个问题我依然不放过，我觉得其实是可以解决掉，哪怕是解决大部分也好”的角度，那很多团队都可以做到更好。

虽然我在过程中一直给这个团队增加难度（比如 SRC 的活动要求不间断的增加奖励的力度），但是每次大家通过分析新的问题聚集性，总能找到新的主要矛盾和解决方法。