原文 by 职业欠钱
曾经，安全圈把从业人员分成剑宗和气宗。剑宗是掌握一些招式，不需要长年累月的积累“内力”，有时候就能出奇制胜，搞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的细节根本无法全面了解，无数的信息和细节都只是在我们自己的脑子里，记忆里，是碎片化的。如果想要给老板快速的知悉事情的全貌，我们必须自己先设计好一些能够说清楚主要矛盾的关键指标，比如：
a. 历史上总共发生了多少次有记录的入侵事件？
b. 每一次入侵事件的发现与否，不同时期的主动发现率比例是多少？
c. 每一次无法发现的根本原因定性是什么样的？
d. 已知原因解决的情况如何？
e. 举一反三之后，如何陈述公司面对入侵的主动发现能力?比如我们可以罗列出多少种攻击手法，能够发现其中的多少种？不能发现的部分什么时候能够解决，承诺的发现能力在多少覆盖范围内是有效的？
……
于是，我们把历史上的一次又一次的入侵事件记录，找了一个Excel维护起来，每一个事件的关键结论用一个字段来描述，最终形成了以下关键指标：
a. HIDS覆盖率（全部组件健康工作）曲线图
b. 主动发现率曲线图
c. 已知攻击场景覆盖率
d. 误报工单收敛曲线图
e. 每一次入侵响应时间曲线图
f. 为了发现入侵相关的基础数据完整度
g. 每一个策略模型的可用性
……
再一次，被老板要求汇报工作的时候，我终于可以比较自信的客观阐述现状了。我终于知道，原来把数据拿来看一下的含义，其实是要自己把相关的工作做好记录，并按照上述思路，抽出有价值的指标，用数据量化的方式，来描绘现状。而这些东西，一直都躺在之前一次又一次的事件记录里，一大堆的邮件或者文字的描述，变成有意义的数据之后，变成了我们和管理者沟通的桥梁。
同样的问题，我看到很多的安全工程师每天都没闲着，审计代码发现漏洞、收到SRC报告催修漏洞，好一些的还专门做了一个记录，差一点的，拉群说完事情就过了，啥也没留下。
如果让他们“把数据拿来看一下”，他们可能啥都拿不出来，或者回去一个一个聊天记录去搜索，不是缺胳膊就是少腿，大部分关键的字段当时并没有特意去确认，死无对证。
亚马逊有一个文化是，开启一个项目之前，要求先写新闻稿（想象一下，未来发布新闻稿的时候你要怎么吹牛逼，确定好这个东西的主要矛盾和目标），再写文档，最后才写代码。
我觉得，安全运营的同学，可以一开始就用上述的思维，倒逼自己要用什么指标去衡量自己一段时间的工作变化，看一看这些指标应该用哪些东西来表达比较合理，当前工作记录里有没有去确认这些指标，并把每一次事件的关键指标维护下来。在半年度的绩效总结时，往往才能更清晰的阐述自己的工作价值，写周报的时候，使用这些数据总结的结论，也更能直观的印证主要矛盾，指导下一步的工作。
我们已经知道了，企业是为你解决的安全问题付费，而不是为你的知识付费了。
所以，对于一些在技术深度上不那么有天赋或者潜力的同学，转向安全运营其实是一个不错的选择。由于能够带领项目持续取得结果上的改进，这类同学也比较容易上升到团队Leader的角色。
那么，我们安全运营工作中，一般会遇到哪些常见的问题，有什么应对的技巧呢？
a. 安全的责任划分
为了解决安全问题，很多安全工程师本能的会把安全的锅往自己的身上背。比如研发写了一个漏洞，拼命的找自己无法发现的原因，同事把代码上传到GitHub，拼命的找自己是否能监控到的改进点，或者收到一个漏洞后，拼命的设计一个解决问题的“手段”，研发照做之后，再一次被白帽子绕过打脸……
而业务同学也理直气壮的决定，我出安全问题，你们安全工程师都干什么吃的？要你们有什么用？
久而久之，锅背的多了，也就失去了同事和领导的信任，安全工程师和业务同学互道一声SB，然后各奔东西。
其实这样的合作模式安全工程师非常的冤枉，本质上，安全工程师的角色应该是医生，而不是保姆。业务是病人，你有病，我有药，你吃药配合锻炼身体，有问题大家一起找解决办法是OK的，而安全工程师开药方，病人抽烟喝酒熬夜，生病了不接受手术，怪医生无能的人有没有呢？比较少吧？
所以，同样的道理，我们应该不遗余力的跟业务达成一种医生和病人的互助关系: 首先任何安全问题出现了，安全团队都难辞其咎，但是业务方才是安全风险的主要承担和责任方。
在这个前提下，安全同学能够清晰的阐述风险的严重程度，我们希望达成的安全目标，手段可以给一些安全建议，但是业务方极有可能会基于自身的了解，找出更忧的实现目标的手段。安全的同学在事后辅以验证（用黑客的攻击方式多尝试一下各种绕过对抗），可能会更好。
否则，安全同学在稍微大一点的规模，业务多种多样，攻击场景多种多样，安全工程师不见得每一次都能胜任“可落地的具体技术手段”的工作，此时安全工程师的亚历山大，一旦业务照着实施后再出事，也很容易影响安全同学的专业口碑和信任。
b. 自上而下还是自下而上
经常有同学发现业务存在安全风险，就直接拉当事人私聊处理，双方都认为，如果不到万不得已，不要拉上级，不给上级添麻烦。
带来的一个结果就是，有时候事情处理得不合理，不及时，没闭环，导致一个已知风险被二次利用。要么就是同一个人、同一个团队反复发生类似的问题，但管理者并不知情，没有人对规避同一类风险举一反三的专项自查。
又或者有一些需要业务配合的工作，安全工程师以一当百，面向全公司所有一线员工苦口婆心劝导，往往会面对百态人生，各种各样的困难、借口、特殊原因都出来了，安全运营工程师活生生的变成了一个一线客服，花了好几个月的时间只积攒了无数的客观困难，事情反正就是进展不大，甚至员工还会想出各种各样的对抗的策略，假意配合转身卸载之类的。
而一旦拉了双方Leader，说明清楚风险、必要性和合理性，往往原来需要好几个月的工期，变成了当天就能完成，原来各种客观困难，现在都有解决的办法了。
甚至个别业务的Leader还抱怨说：这么严重的安全事件，应该早点通知我啊，你们安全同学怎么标准比我自己还低啊？
一顶责任心不足的帽子又迎面而来。
因此，其实在绝大多数场合下，我们认为，安全无小事，安全无私事。也就是说，任何安全事件，都不是一个人的事情，至少普通事件你的Leader应当知情，高危以上事件，中高层管理者应该知情，并及时对团队里类似现象进行辅导和管理。包括一些必要的安全措施，需要全员/多人配合的，往往会动用到业务的人力资源，此时都应该选择自上而下的推动方式，告知项目的背景和意义，管理者所在团队的配合进度，透明化晾晒出来，不配合的同学自然而然的会感受到压力并公开透明的反馈原因。
在抓大放小的前提下，往往能够节约自己大量的精力，也能快速的推进项目。
至于是否会过于强势，得罪一线同学，我觉得这个属于软技能范畴，最坏情况下不近人情也是为了执法，如果能有办法把事情办成了也不得罪一线，自然是更好的结局，这块我个人也没有特别万能的办法，如果有同行愿意分享经验最好。
c. 重视宣传
很多专业的安全技术从业人员特别鄙视PR，觉得PR就是吹嘘、没有技术的代言词。
但是实际上，在大规模企业里，符合价值观的宣导工作，对安全运营的效果是非常明显的。
比如推行一个项目的前期，有正式立项的kick off，能够说服高级管理人员支持，不管一线是否本能情愿的支持吧，只要事情做完了，及时的反馈感谢兄弟团队的配合，克服了什么困难，分享一些运营数据阐述效果，为公司带来的正面价值，及时形成邮件、项目总结报告、内部全员推送稿等，往往能够给项目带来一种神奇的支持效果。
在日常的运营中，选择可以引起员工、项目的关键支持者共鸣的一些素材，及时的撰写专业的解读、分析、经验总结，赢得大家实在的信任，也有助于提升安全团队的专业形象，并且给所有人一种“公司有这群人在负责我们的安全，靠谱”的印象。
（待续）