谈一谈安全运营工作是什么

发布者:美团SRC
发布于:2019-09-29 15:12

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


0x00. 安全运营的热议可能是怎么来的


写完《我理解的安全运营》这一年来,“安全运营”这个词恰好有一种火了的架势:

有些乙方开始在安全峰会举办“安全运营”专场,大家坐一起探讨到底安全运营是个什么东西,以及有点什么“运营技巧”,甚至有一些乙方提供了“安全运营产品”、“安全运营服务”。


时间上的先后顺序,有时让我错觉,似乎自己开创一轮安全圈创造新词活动。当然,我个人认知不失调的情况下,还是能够清醒客观的认知到,自己肯定没有这么大的影响力。那到底是什么驱动了业界对“安全运营”的关注呢?


也许有2个可能性共同作用促成的:

某活动将安全风险直观化了

业界普遍从建设期进入运营期


第一点,笔者其实是从TK教主某一次分享中记下来的。大致意思是,信息资产承载的价值正越来越高,风险也越来越大。


粗浅的解读,15年前,我在大学宿舍的电脑中毒了,顶多就是我宿舍的同学不能打游戏了,存在上面的资料丢了就丢了,没什么影响。而前两年,Wannacry的肆虐,让很多医院之类的基础设施系统崩坏,影响到的是社会民生,安全风险越来越直观,国民认知越来越具体。


除了这些基础设施和生命安全的案例,涉及到资金安全(银行卡被盗刷)、App隐私安全(权限滥用、数据泄露),甚至有人可以入侵心脏起搏器,让移植了人工心脏的病人直接死去。(安全问题作用于人身安全)。


只不过大家老以为是在电影、新闻里的才有的黑客攻防素材离自己很远。组织的决策者其实也有类似的认知。一家公司经营过程中,有风险的事情那么多,不是所有事情都会去立即马上去执行的,除非这些风险已经摆在了面前。


一直到最近,国家层面连续多年举办的某大型真人实战演练活动,把乌克兰、委内瑞拉电网之类的案例,在国内进行近似的呈现。很多组织的决策者(或者安全主管)发现,哎呀,不能只是随便雇2,3个安全工程师对付一下合规就算了,大家动真格的啊。戳破了以前其乐融融的假象,不再满足于买几个安全设备往角落里一丢,半年出个报告对付一下合规检查的敷衍工作,是关注“运营效果”的核心动力。


一旦实实在在的去追求“本来应该做好的安全效果”,大多数人其实都会自觉关注到“运营”这个方向上来。


第二点的理解更简单,安全从业者之前天天嚷嚷着,安全不受重视,其实是真的。有些企业要不是为了上市合规,说不定压根不会雇佣安全工程师。招俩安全工程师往往也觉得是给业务拖后腿的,安全工程师这不让干,那不让干,业务跑不快,在老板心中一直有着错误的认知,觉得安全是负担而不是保驾护航走的更远的帮手。


但客观的说,也有不少企业已经过了最初野蛮生长的阶段,市值、体量、社会影响力都不容儿戏了。成长的过程中,企业或多或少也招了点安全工程师,只不过由于人数实在太少,所以并不去追求安全工作是否做到了应有的效果。(虽然团队在自己的述职文档和技术沙盘图上,可以假装自己做了很多工作,只是实际工作里,这些名词并不能帮助公司处理好一些低级的风险)


所以,从建设阶段的视角来看,很多公司基本的安全建设工作或多或少做完了,也该实实在在的考虑一下,从运营的视角来看,是否可以做的更好了。此时,安全从业者关注“运营”的方法论、小技巧甚至于产品、服务,都是自然而然,理所应当的。


0x01. 以组织规模迭代过程和SDL为例简单阐述运营工作的开展


因为《我理解的安全运营》的缘故,有些人经常问我,安全运营工作到底长什么样子,在里面干活的同学都在忙点什么,有没有一些小技巧或者方法可以share。


这个话题比较大,所以今天我虚构一个故事,介绍一下,随着组织规模的不断膨胀变大,安全工作者可能面临的主要矛盾变化,并以SDL为例,说一些在人少事多的前提下可能采取的运营思路。挂一漏万,如果有什么地方说的不好,欢迎大家批评指正多交流。


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


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


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


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


因为只有个把安全工程师(也可能随着业务的发展,团队扩张到了10人以下),安全的工作量一开起头来就几乎没完没了,所以大部分的工作只能浅尝辄止,做完就算(这种现象在开发、运维等团队同样存在,毕竟企业发展阶段不同,谁都不成熟)。这个阶段不追求什么最佳实践,能落地就算好的,更别说还有无疾而终的项目呢。


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

可是,如果公司业务发展很快,成为垂直领域的明星。树大招风,被行业主管部门甚至社会舆论给监督上了。老板开始关注细节,就会觉得这些问题看起来也不难解决啊,怎么解决的不好呢?现在事情都闹大了,安全团队就开始有压力了。


(嗯,潜台词就是,如果公司小,大概率是不会有这些压力的,所以安全团队可以相对舒服的继续干下去。当然如果主管安全团队的Leader一开始就懂这些,公司即使没出什么大事,大家也会提前遭遇挑战)


老板开始期待某一类的问题将来得到一个合理的治理。起码不能出现低级错误,本来很简单能做好的事,没尽力,漏了,很容易背上责任心不好的锅。


我们从“有做一些工作,以应对安全风险”变成了“基本功要过关,免得再出现同类风险不好解释”的时候,大概率会发现,团队的资源和能力不够用。


比如说漏洞管理,大家普遍号称自己使用SDL的方法论来解决。SDL是微软很多年前提出来的一个理念,有一本书来介绍这个方法论。但是一句话提炼核心逻辑,其实就是把安全嵌入开发生命周期的每一个流程,这个思路帮助微软把Windows和Office系列的产品做到了今天的样子(你会放心的使用微软家的产品)。这种思路是以项目为单位实施的,一个项目,从立项设计、架构评审、实现、测试、发布、运营的全周期都要安全工程师参与进去,才算是做好SDL,否则你知道这个项目就一定会有低级错误出现。


在国内,稍微大一点的公司,公司的项目可能成千上万甚至百万个。


而任何一家公司的安全工程师数量都是有限的,分到SDL这个职能的可能更少,很多公司说不定就个把人。这几个人能维护个扫描器把公司的每一个Web项目扫一遍,说不定就对敢外分享自己公司做SDL的心得了。白盒审计因为误报的关系、人工审计因为工作量的关系可能压根就运营不起来。


(这部分完全看公司实际情况,公司核心项目少,迭代少的时候,也有同行能做到每一行代码都亲自人肉审核的。)


如果老板不在乎不重视(比如说偶尔出个漏洞,也没被大肆的PR),其实这几个人也可以开开心心的做自己喜欢的事情,得过且过混着日子。


但是如果老板指出,因为安全工程师的存在,希望力所能及的减少外面能发现漏洞的可能性,每一个外部报告的漏洞都追究一下是不是真的技术上很难规避,负责SDL的这几个兄弟就要发愁了。因为真的有很多“本可以做好但是实在很烦的工作懒得去做”,一旦出了问题,也很难说这是一个行业难题别人都搞不定所以我们才出事的呀。


一方面,绝大多数公司的人力支撑不了全公司那么大的工作量,另一方面,不具备混日子的条件了,那就开干吧。开动脑筋,抓主要矛盾。


分析一下历史过往案例,大概率能发现一般新项目上线的时候,RD没经验,被白帽子捅得最多,所以把有限的人力集中起来审计新项目应该是比较可行的方法。(能最快速度的减少外部报告漏洞的数量)。


依附于公司的发布流程,每当有新申请域名、新项目上线,安全工程师要求人工审核完毕才允许上线,是最合理的方案。


上线成功之后的项目再迭代产生新的漏洞此时还关注不到,所以只要时间拉长,漏洞还是反复在报。这靠人肉审核终究不是个办法呀,咋办呢?整个扫描器吧,商业的还是开源的或者自研的无所谓,总而言之,有了一个扫描器,应该就能解放自己了。


可是扫描器一开起来,可能马上就被业务骂死:以前都没事的,你一扫我的业务挂了,监控告警刷屏了,数据脏了,你赶紧给我停了。


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


好不容易达成一致,天天扫,可SRC还是天天报漏洞,尤其是一做N倍积分奖励活动就报得特别欢。以前不操心也就算了,现在每次SRC报的漏洞会琢磨一下,为毛扫描器就扫不出来呢?为毛人工审核的时候就没看出来呢?


一复盘就能发现黑盒扫描器各种细节存在短板,比如URL不全拉(赶紧从NIDS、AccessLog里找数据补救)、调度问题、POST主动规避导致没检测到、爬虫引擎效率或者能力问题、某些资产Payload积累问题……


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


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


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


差点就崩溃了。


那也得接着整啊,跟扫描器一样,团队还是就这几个人(还要分出一些人处理人工审计新上线的项目)。这点资源,不要追求解决业界所有已知的漏洞不出现,追求把公司历史上出过、最常见的,而且解决起来成本不高的漏洞,做好增量控制更迫在眉睫一些。


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


根据自己的经验和人工的整理,迭代几个版本,终于在没什么误报的前提下,能够识别一些漏洞了。这下好了,自研的白盒审计能力也有了。每次SRC漏报的时候,负责白盒审计项目的同学也要复盘,这事我从源码上是不是一定扫不到呢?


新项目人工审计把关、黑盒自动化例行化扫描、白盒例行化审计(结合代码仓库和发布平台控制每一次迭代),都整上来了,公司的SDL能力肯定比之前强多了规范多了。


可是,这样就行了么?


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


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


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


虽然扫描器扫出一大堆的可疑list,但是人工去闭环成本实在太高了(回到了老问题,人一个一个看是看不过来的,中长期天天看这玩意,工程师也要崩溃),哪怕你临时人工找到了几个真的有问题的漏洞,但是它不是个长久的事。


问题必须解决,自动化又解决不了,必须人工判断,安全工程师的人工数量又显然支持不了全公司。所以顺理成章的得出一个结论:这玩意得业务自己人工搞定。


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


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


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


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


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


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


然而老板却仍然不满意,他觉得,剩下那20%隐患还是很大啊,难道就真的没办法了么?


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


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


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


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


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


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


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


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


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


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


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


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


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


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


它的本质,是我们相信有一些目标不必妥协,本身就可以解决,于是我们竭尽全力,争取资源或者看菜下饭都行,在现有的资源里,力所能及的做到最好,实实在在的保护公司的安全。


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


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


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


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



最 后,笔 者 如 是 说


嗯,最近团队在疯狂的招人。


如果你正经历着上述类似一个人的安全部的经历,有着不错的技术功底(能挖洞、会渗透、懂编程),也希望在一个相对大的平台(有挑战),做一些比较务实的安全防御工作,又或者哪怕是研究工作,可以试试来我们团队。


不看 JD 介绍,就看你个人匹配度,简历投递:zhaobizheng#meituan.com





声明:该文观点仅代表作者本人,转载请注明来自看雪