引子
曾经，安全圈把从业人员分成剑宗和气宗。剑宗是掌握一些招式，不需要长年累月的积累“内力”，有时候就能出奇制胜，搞Web安全的“脚本小子”被划为这一类，而气宗因为需要从汇编、编译原理等晦涩的知识开始，学习曲线比较陡峭，大器晚成，碰到什么不明白的地方就反编译了看看汇编源码，总能知其所以然，搞二进制的被划入这一类。
这两类人，共同看不起的是一类“文职安全工程师” —— 安全管理从业人员。
所谓的“文职安全工程师”，往往是知道一些技术的基本概念（但不需要太深入），考个CISSP、学个ISO27001，或者啃一些等级保护制度的要求，知道一些大概的安全域和常规安全概念与解决方案的名词，在企业里负责安全合规审查的配合、安全规范制度的撰写，或者对接乙方供应商，就可以了。近期GDPR的火爆，和早期上市公司对SOX404合规性的需要，也让各大咨询服务商培养了大量类似的从业人员。
业界也因此热议是三分技术，七分管理，还是七分技术，三分管理。
如今，一些大型互联网企业开始招聘一种叫做“安全运营工程师”的新物种，这是个什么角色？到底是搞技术的还是搞管理的？我打算从个人的经历做一些解读和分享，请大家指正。
一、安全运营的定义
首先看“运营”的定义，笔者曾经从事网络游戏行业，这个行业有一个专门的岗位叫做“运营”，是老板最爱找的人。
他们日常的工作是什么呢？
在项目研发的前期，运营同学会根据自己的经验，把项目常见的一些需求提给研发，此时是需求提出方，或者一定程度上的设计者，但并非产品经理。
一旦项目上线，运营会反复的体验产品，找出一些问题，小范围灰度测试，征求意见，但最重要的是分析数据（有专业的数据分析团队按需求支持），诊断问题，再针对性的反馈优化需求，研发/产品 会配合执行。
根据拉新、留存、促销的场景，不断的策划一些宣传（有市场策划同学配合）、广告投放、节假日活动等。
最终，一个产品本身做的好不好，项目收益好不好，生命力强不强，主要看运营同学是否专业。
这样的角色，可能有些同学会觉得像是“产品经理”，不一定是独立存在的组织实体，但是他们的职责是比较清晰的，这是一群为项目的最终目标负责，从而不断诊断分析问题、提出需求、协调各方资源，共同达成目标的人。
放在安全这个领域，我们也有类似的诉求：
自研或者采购一些安全产品，引入一些安全解决方案，只是手段，真正的诉求是解决我们的安全风险。
比如，有一些安全工程师非常喜欢写一个扫描器、做一个HIDS的DEMO、搭建一套大数据分析的平台、分析某个漏洞的细节并研究POC，这些工作都是有意义的，但是，这不是全部。
我的前领导经常说一句话“手段不是目标”，写出一个扫描器，是手段，目标是为了提前检测出漏洞，减少公司因漏洞带来的安全风险，写出一个HIDS也是手段，目标是能够发现入侵事件，及时止损，搭建一套大数据分析平台同理。
站在为目标负责的角度，你的确写出来了一款扫描器，但是我使用开源产品或者商业产品同样拥有一款扫描器，除了让你本人有成就感之外，增加下一份工作的求职筹码之外，究竟对目标作出了什么样的贡献？
“我做出来了扫描器，可是没例行跑起来啊，因为一跑起来，把业务扫挂了/业务告警一大堆抗议了……”
“我的扫描器有例行跑，但是测试用例没人家的全啊，好多漏洞检测不出来啊”
“我的测试用例特别全，集众家之所长，就是误报多了点，多到什么程度呢？每一个漏洞我都能检测出来，但是伴随着成百上千的误报，所以得人肉一个一个筛选才能转发给RD修复”
“我的扫描器很厉害，就是目标URL不在扫描列表里，经常不在列表里”
“我的扫描器不错，但是SRC收到的漏洞一直没减少，他们都是逻辑漏洞，越权漏洞，这个不是技术上能自动化解决的事啊，所以我不需要改进”
“我做出来了HIDS，只不过兼容性差一点，上一次搞挂了业务机器，覆盖率没上去，被入侵的机器上都没装”
“我做出来了HIDS，采集的数据特别全，后台存不下了，没法分析”
“我做出来了HIDS，入侵检测规则特别厉害，就是误报稍微多了点，一天1万单吧，所以只是看不过来恰好没发现入侵”
“我做出来了HIDS，也报警了，只不过没有人跟进，他们也看不懂我的告警是什么意思，要是我亲自处理就能抓到黑客了”
……
太多的企业里，能有一个团队拥有上述素质的安全工程师已经实属不易，但是企业真的是为了我们做出来的扫描器、HIDS之类的手段而付费么？
我想不是的，企业多数情况下是为产出付费，而不是为知识付费。
花钱雇佣一个安全工程师，而工程师仅仅沉浸在自己做出东西的愉悦感里，并不能为公司减少安全风险，这是一个很尴尬的局面。
就好像有人雇佣了一个保镖，武艺高强，但是小混混上来欺负主人的时候，保镖无动于衷，主人天天被欺负，主人应该为这个保镖付费么？
因此，企业花钱雇佣安全工程师的目标是要解决问题，而解决问题绝不仅仅是把一个安全产品买回来、把一个东西做出来就结束的事情。
在大的公司，解决问题的需求很强烈，安全技术、安全管理、安全开发等角色都具备的前提下，老板发现某一些安全问题总是无法收敛，最终，引入一类新的角色，对问题进行分析、诊断，发现症结后，协调资源，终于实现了目标。自此，安全运营工程师就出现在了世人的面前。
二、安全运营的主要职责和技能需求
参考游戏运营的角色，我将安全运营定义为：“为了实现安全目标，提出安全解决构想、验证效果、分析问题、诊断问题、协调资源解决问题并持续迭代优化的过程”。
这里最重要的是解决问题，那么一切影响目标达成的因素，都是运营的职责。
比如，我们招聘了一名优秀的安全工程师，他拥有丰富的扫描器、HIDS开发经验，喜欢沉浸在技术中无法自拔，但是，每一个扫描的结果，发给RD后，RD产生了大量的咨询，讨论，大量的占用了这名工程师的时间，以至于很多已知的Bug无法快速修复，每一个HIDS的告警，他无法抽出时间去一一闭环（找业务确认是否存在风险非常耗时），总有一些配合的团队不靠谱，比如资产列表遗漏了，某个数据同步错误了……
这时候产生了大量的“杂活”，让安全工程师去一一解决，一方面他不喜欢做这些“非技术”的工作，另一方面，他的能力模型也不一定胜任。
因此，让另一名不需要负责参与研发的同学辅助配合，可能是比较适合的一个方案。
这名同学要解决前者不乐意解决的事情，他必须具备这样的能力：
a. 拥有安全知识背景，能够比较好的理解安全场景和需要解决的问题，擅长清晰的总结表达发生了什么事；
b. 拥有研发、运维相关的背景知识，知道某一类问题的合理解决方案；
c. 拥有较好的沟通能力，可以在安全工程师、安全开发工程师、业务RD/SRE之间搭建沟通的桥梁；
d. 拥有一定的项目管理能力，较好的责任心，确保已知问题能够得到闭环的解决，涉及到跨团队的沟通，还需要有一定的大公司跨团队协作的基本经验；
e. 具备数据意识，可以提出数据埋点、统计诉求，并细心的将已发生的事件积累成数据素材，形成日常观测的指标（针对可用性、覆盖率、效果指标等）
前面的技能诉求比较容易理解，重点说一下最后一条，数据意识。
我曾经在负责入侵检测项目的时候，领导猛的一下说，把数据拿出来看一下，我懵了，什么数据？怎么看？
当时我的内心无比的抗拒，并不知道发生了什么，只记得后来反复的被批评积累不够，我也不知道到底需要积累什么。
直到隔壁团队一个看起来不那么懂安全攻防的同学对我进行了一番辅导，我终于明白了，其实老板管理的幅度大了，对每一个function的细节根本无法全面了解，无数的信息和细节都只是在我们自己的脑子里，记忆里，是碎片化的。如果想要给老板快速的知悉事情的全貌，我们必须自己先设计好一些能够说清楚主要矛盾的关键指标，比如：
b. 每一次入侵事件的发现与否，不同时期的主动发现率比例是多少？
e. 举一反三之后，如何陈述公司面对入侵的主动发现能力?比如我们可以罗列出多少种攻击手法，能够发现其中的多少种？不能发现的部分什么时候能够解决，承诺的发现能力在多少覆盖范围内是有效的？
于是，我们把历史上的一次又一次的入侵事件记录，找了一个Excel维护起来，每一个事件的关键结论用一个字段来描述，最终形成了以下关键指标：
再一次，被老板要求汇报工作的时候，我终于可以比较自信的客观阐述现状了。我终于知道，原来把数据拿来看一下的含义，其实是要自己把相关的工作做好记录，并按照上述思路，抽出有价值的指标，用数据量化的方式，来描绘现状。而这些东西，一直都躺在之前一次又一次的事件记录里，一大堆的邮件或者文字的描述，变成有意义的数据之后，变成了我们和管理者沟通的桥梁。
同样的问题，我看到很多的安全工程师每天都没闲着，审计代码发现漏洞、收到SRC报告催修漏洞，好一些的还专门做了一个记录，差一点的，拉群说完事情就过了，啥也没留下。
如果让他们“把数据拿来看一下”，他们可能啥都拿不出来，或者回去一个一个聊天记录去搜索，不是缺胳膊就是少腿，大部分关键的字段当时并没有特意去确认，死无对证。
亚马逊有一个文化是，开启一个项目之前，要求先写新闻稿（想象一下，未来发布新闻稿的时候你要怎么吹牛逼，确定好这个东西的主要矛盾和目标），再写文档，最后才写代码。
我觉得，安全运营的同学，可以一开始就用上述的思维，倒逼自己要用什么指标去衡量自己一段时间的工作变化，看一看这些指标应该用哪些东西来表达比较合理，当前工作记录里有没有去确认这些指标，并把每一次事件的关键指标维护下来。在半年度的绩效总结时，往往才能更清晰的阐述自己的工作价值，写周报的时候，使用这些数据总结的结论，也更能直观的印证主要矛盾，指导下一步的工作。
三、安全运营的基本技巧
我们已经知道了，企业是为你解决的安全问题付费，而不是为你的知识付费了。
所以，对于一些希望谋求更好的成就感和价值回报的技术同学而言，转向安全运营其实是一个不错的选择。由于能够带领项目持续取得结果上的改进，这类同学也比较容易上升到团队Leader的角色。
那么，我们安全运营工作中，一般会遇到哪些常见的问题，有什么应对的技巧呢？
a. 安全的责任划分
为了解决安全问题，很多安全工程师本能的会把安全的锅往自己的身上背。比如研发写了一个漏洞，拼命的找自己无法发现的原因，同事把代码上传到GitHub，拼命的找自己是否能监控到的改进点，或者收到一个漏洞后，拼命的设计一个解决问题的“手段”，研发照做之后，再一次被白帽子绕过打脸……
而业务同学也理直气壮的决定，我出安全问题，你们安全工程师都干什么吃的？要你们有什么用？
久而久之，锅背的多了，也就失去了同事和领导的信任，安全工程师和业务同学互道一声SB，然后各奔东西。
