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#http://meituan.com