文丨弼政(职业欠钱),美团基础安全负责人

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

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

我理解可能有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 的活动要求不间断的增加奖励的力度),但是每次大家通过分析新的问题聚集性,总能找到新的主要矛盾和解决方法。

我想,这就是我想表达的安全运营了。

它和技术无关,但又息息相关,每一次诊断的时候,没有扎实的技术基本功,其实是很难给出最合适的解决思路的。有很多次,小伙伴的诊断方向其实都可能有了偏差,也是有更多的小伙伴集思广益给拉了回来。

这样的安全运营理念,它会“产品化”么?可以被“平台化”么?

我觉得可能很难,但是基于这样务实的追求,做一些方便的辅助平台,或者外包服务,应该也是挺受欢迎的吧。

今天就到这,之后结合入侵检测、应急响应、IT 安全(BeyondCorp,你们有时候也叫做零信任或者无边界),我再分享一下个人的经验。

声明:本文来自美团安全应急响应中心,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。