安全运营是工作的一部分
安全工作的逻辑
安全团队是怎么运作的
定义安全运营项目
项目运营的要点
计划的计划
风险的风险
运营方案尽量要评审
过程的过程
做到有法可依
沟通和组织
进度的监控
明确闭环标准
项目集的管理
怎么去开会
准备的准备
会前会中会后
复盘的复盘
PPT和WORD
帮助别人开会
遇到困难怎么办
写在最后
参考资料
本文信息量巨大，阅读大约需要二十分钟左右，建议加关注收藏后阅读。
日常工作中对接研发同学的一次漏洞答疑，写代码优化敏感数据的识别统计指标，处理应急响应，安全BP发起弱口令治理，日常的补丁管理，组织大型的国家级“HVV”专项，都属于典型的安全运营类的项目范畴。
我们做了大量的安全运营工作，这些事情以项目论起来有大有小，不同公司对这些从事这些一线运营工作的内容描述有“拿结果”、“push”、"落地"、“打法”、"主导"不同的说法，我比较认可“推动”的说法，通过运营专项推动工作达到预定的治理效果，”推“和”动“很形象地说明关于安全运营的主要工作：需要主动“推一推才动”，安全的特点确实是要做成一件事，合作方确实有很少的意愿去配合，所以需要有科学的办法去运营这些事情。
零零总总完成工作总是很容易的，但是首先要理解它为什么能完成？顺利和困难是偶然还是必然？是无意做出的决策还是有意遵循了什么逻辑？做到”知其然然后知其所以然“很难，虽然明面上运营这类事情有PMO( Program Management Officer 项目管理办公室)参与协助，但是PMO仅仅是运营项目的支持者和协调者，领域负责人必须承担全部的责任，这就考验为达成安全运营效果所要求的技术能力、沟通技巧和组织能力，参考基层安全管理者需要具备的素质。
临近年底组织内经常用运营专项的实施效果来衡量OKR和KPI的完成情况。虽然各种的安全运营专项的是安全部门运营工作的重要组成部分，但是回头看做得好坏并不仅仅取决于技术来实现，也负责人具备一些项目管理和软技能，将安全目标和企业运营逻辑“黏合”起来。
本文不讨论任何技术细节，而是以安全行业工作特点为例，系统化思考安全运营的本质，重点从项目角度介绍开展工作的基本功，仅仅是作为“井底之蛙”将浅薄的经验整理沉淀，希望通过同大家交流得到反馈。
安全工作的逻辑
在正式进入对这个问题的分析和探讨之前，我们很有必要整理下为什么我们要做这些安全专项？背后的思考逻辑是什么？公司各个团队是如何运作划分的？为什么分配你负责一个项目？
首先科普将安全作为风险管理的重要概念，各家组织最上级的安全战略决策机构，不管他们叫做什么风险委员会、首席风险官，集团安全办之类的，根据业界最佳实践会为了达到风险治理的目标从组织层面划分了三道防线完成整体安全目标：
第一道防线是业务部门自己，出现安全风险后，业务是第一责任人，安全团队承担同等责任，业务内部有负责一线研发、对接BP、专职安全测试的人员，保证一线和自己相关的层面不出现问题。
第二道防线是管理具体风险的专业安全部门。比如各家公司的业务风控和安全部门，也是安全从业者聚集最多的部门，一般划分为数据安全、风控、产品和IT安全多个团队。他们负责隐私保护、安全工具、渗透测试技术和应急响应工单系统等，构成大家最为熟知的安全管理防御战线。
第三道防线大家直接接触不多，但是有意无意都在配合，指承担审计、测评合规，做合规制度、监督、流程控制活动的部门，一般理解是为了”务虚“，实际上基本代表安全工作的目标。
那为什么组织内要运营大量安全专项呢？扫帚不到，灰尘是不会自己消失的，各个安全专项通过主动治理完成法律合规、数据安全，配合达成组织要求的战略目标。但是对于将要完成安全运营项目的压力不用自己背，公司在运营层面已经搭建好相关的治理框架，会提供三个成熟的管理体系来支撑：
风险管理通过风险的识别、改进、度量、处置来管理内外部风险。管理Owasp Top10风险，SRC复盘漏洞工作，日常黑白盒漏洞发现、添加拦截规则等工作。
运营管理通过指标体系、监督改进、报告度量、绩效考核从运营层面保证组织和人员的投入。比如日常的数据采集分析、运营漏斗模型，同业务沟通反馈风控策略，答疑安全sdk的使用等工作。
项目管理是指某些待建设的专项来支持安全治理，采用项目管理的标准方法论。比如通过改进应用程序设计和基础设施架构提升安全性，例子包括建设一个容器waf、搭建开源kms、制定iot安全审计流程规范、供应链安全管理等。
公司根据上述的逻辑来划分组织架构，提供保障资源。这个前提开展安全运营工作的基本盘，你所有的合作，沟通，管理、反馈，安全运营涉及的闪转腾挪都是基于这些体系运转的。
参考项目的定义，安全运营专项在组织层面的定义很清楚：由安全团队作为二、三道防线完成风险发现和指导技术和运营，敦促一道业务防线配合，达成安全目标而采取的运营管理要素的总和。说人话就是：除了技术之外，为达成安全的"做事逻辑和方法"，都可以归类为安全运营。
例子一：发起域控安全加固运营的安全运营项目，那么它有明确和具体的要素：
目标--解决某一领域风险（域系统）
工作范围--风险治理范围（并不仅仅是域控服务器，还包括打印机、exchange服务，但不包括未加入域的机器）
预算和时间质量要求--在攻击者利用之前修复和建设完成，保证无入侵视野盲区。
例子二：入侵检测项目运营
目标：具备入侵服务器的安全监测技术和管理系统
工作范围：IDC和办公网的资产
预算：有限
时间和质量要求：依时间计划阶段性建设基础和纵深防御和感知能力
但是没有人是主动的“长期主义者”，我们天性很喜欢写个Poc弹出个计算器，但是安全运营一般是以月度、季度和年来计算的，很难像写代码一样马上出true或者false的运营结果（相反运营做得越好，永远不会有风险在真实坏境被体现，越没有正向反馈）。
那么有什么框架可以帮助大家来梳理思路呢？就像编程有框架和范式一样，安全运营可以参考ISO27001和应急响应IIPDRR（Identify、Protect、Detect、Respond、Recover）的工作方法论，借鉴PDCA循环：通过计划（Plan）、实施（Do）,检查（Check）,处理（Action）来改善工作。
安全专项首先了解目前的安全问题或风险，对风险进行根因分析，设定目标和计划，分工完成任务，最后对检查任务执行的效果，评估风险现状，不断改进，达到闭环。
为了避免忙于具体事务而疏于运筹，安全运营计划要在实施前提前起草，这并不只是书面的计划，起码要做到心中有数，计划按照过程分为启动、组织准备、执行、结束、评估复盘阶段，计划的内容包括确定阶段划分、交付结果、里程碑、分工、沟通和决策机制和闭环条件。制定的计划要张弛有度，定稿后要公布出去。
简单的安全运营比如写一段代码提升url去重效率，也可以视为一个黑盒扫描运营中的子类小计划，只是大家平时视而不见，但其实遵循同样的计划的做事逻辑。复杂的安全运营项目的计划和开发、挖掘漏洞相比，不是可以独立加班搞定的，依赖于多个合作方的配合，所以刚启动时最好是有以周为颗粒度的计划，迅速让各参与方独立制定“小计划”配合建立工作节奏。
干系人是解决问题的关键点，承担安全运营的效果，干系人划分可以参考RACSIC模型：
谁负责（R = Responsible），负责执行任务的角色，具体负责操控项目、解决问题。
谁批准（A = Accountable），对任务负全责的角色，只有经其同意或签署之后，项目才能得以进行。
谁支持（S = Support），参与具体任务，协助R完成工作的角色。
咨询谁（C = Consulted），在任务实施前或中提供指定性意见的人员。
告知谁（I = Informed），及时被通知结果的人员，不必向其咨询、征求意见。
简单说干系人就是做安全运营需要哪些人参与，他们对工作效果有直接的影响，是活生生的人，不是代码，不能被忽视。
范围是工作要做那些事的边界，有时候对于要运营的范围存在没说清楚、没想清楚然后工作资源分配不均匀。
举个例子：理想情况下去评估一个对外采供应商的产品评估安全风险，但是做着做着发现这个外采系统依赖了大量的第三方开源组件，越评估涉及事情越多，这时候要在采购合同担保明确安全责任范围，是将系统作为一个安全管理的整体，还是仅仅关注核心交付软件。
“你无法管理你无法衡量的东西”，没有度量就没有管理，建议在确定工作范围后，第一要务是给出范围内的关键度量评价指标，明确治理的好和坏的评价标准，画出任务统计分析大盘，比如让大家看到一个安全运营的图表，不在横坐标和纵轴坐标的都是工作范围之外。一条优雅的曲线在接下来的工作可以说明很多事情，有些指标事后就不大容易收集得到，难以说清个人在项目中的工作价值。
这里的风险是指对处理”安全风险“中出现的“运营风险”进行管理，在解决这些漏洞威胁层面的风险时，运营方面经常出现项目管控风险，如同解决安全风险一样，影响安全运营项目达成的风险也依赖风险识别、分析、计划、监控的管理手段。一个安全项目的风险主要分为技术、管理、组织、外部四个方面，风险的应对措施也是大家熟悉的规避、转移、弱化、接受策略，项目的风险管理和安全漏洞的风险管理没什么不同。
假设要运营一个隐私保护的专项，那么技术“风险”可能是没有相关的隐私和数据安全计算平台、难以落地差分隐私技术、隐私保护技术要求过于超前等技术原因；
管理风险：人力不足，人员都是从数据和业务安全转过来的，不熟悉隐私保护领域；
组织风险:业务领导对隐私保护的优先级和安全给出的判断不一致；
外部风险:《个人信息保护法》和GDPR之间的法律法规关系，业务接口人离职等。
对于外部风险的处置方法你当然可以选择上面的四种策略之一--接受：不用管业务接口人会离职。
组织一个大的运营项目，如为了解决主机登录问题推广jumper server跳板机在混合云架构，这时候不能片面相信技术可以拿来即用，要关键人参与进来评审，考虑落地时的性能、稳定性、目标。一般情况下质量、成本、时间永远无法达到平衡，改变的魔法是提高生产力，提前准备好靠谱的安全运营项目方案有助于事半功倍，可行性优先于必要性，主动征求他人意见能发现操作层面细节的盲区。
除了技术方案，涉及到宣传、向上管理、跨部门的汇报也要集体决策，把控运营方案的可行性、普及性，多方配合做到心中有数。
就像很遗憾在一个安全团队中并没有任何一个完整走SDL流程的产品一样，运营的方案评审总被主动忽略。原则是可以走得稳才能走得远，没有经过调查分析的方案就没有发言权，欢迎大家对方案吵架，吵完架后坚决执行。
实施运营任务时，并不仅仅要为了结果负责，还要保证过程的相对质量。过程的积累很多是文档类型，清晰的运营文档会带来很多优点：
思考得更清楚，做事的方法论是”Think，Write，Speak，then Do“，你首先要想清楚怎么推行一件事，然后写出来，在写的过程中再次思考，确保你自己明白你要说和做的事情。
降低沟通成本，一份有详细数据、附录、FAQ的材料胜过巧舌如簧，这类文档材料包括并不局限于会议材料、方案设计、代码、专项人员联系表、宣传材料。大家基于同一份材料进行争论才不会各说各话，培训和沟通的成本能大幅减低。
历史追溯，要面向”离职“工作，以你的任务交接给别人他是否能理解的标准做事，持续运行的严格要求带来过程管理的完善性。良好的记录可以帮助查询当时的背景、决策依据，回忆是不可靠的，录屏、录音没人有耐心分析回溯。
文档材料阅读更快，如果依赖当事人的口述通常失真且抓不到重点，过程材料可以搜索、复用、归档、查看历史版本。
这里其实是属于项目管理的需求管理范畴，做安全运营隐含着要做的事情得符合制度法规要求，在运营层面可以适当整理、遵循相关的材料，以相关的制度体系作为运营工作的准绳。组织一般会制定四级文件制度，
最上一层是公司的最高安全战略纲领或者最高安全和隐私政策，这个级别一般在运营层面不会涉及，由大老板去运营。
二级文件一般是具体的标准和规范，这些材料都是开展工作的依据，如果工作中缺少大量的此类材料，甚至都没有公司层面《web系统上线规范》就要去运营一个web系统架构评审项目，建议补全后再全面实施运营。
三级文件是指南、流程、最佳实践之类的材料，，一般专项的负责人可以根据项目的情况发起新增和修改，在这个层面就是“有法可依”，不然治理时容易责任不清楚，或者责任方不清楚运营工作的评判标准是什么。
四级文件以模板、报告、汇报材料，就些在工作中涉及比较多，可以多积累作为安全专项的工作手册后续重复使用。细节材料的文档积累比代码更重要。
一级：比如对于华为的全球网络安全与用户隐私保护委员会，由任正非签发的《关于构筑全球网络安全保障体系的声明》及《华为隐私保护总体政策》就属于一级实践框架。
二级：比如字节跳动的信息安全委员会关联的安全风控部门整体负责信息安全与业务风控的建设、规划和管理工作。那么会有如《今日头条社区规范》，数据安全与隐私保护部门颁发的《字节跳动隐私保护政策》作为二级材料支撑。
三级：比如《上云最佳安全实践》、《公司密码算法术语定义》等。
四级：判断一个设计方案是否符合安全标准的checklist；一个会议沟通纪要等。
如果没有这些材料会出现什么问题呢？比如我们要做一个http鉴权的安全治理，但是缺少公司层面的统一鉴权规范，那么这件事是做还是不做呢？是等着公司出规范指引，还是大家各自问政，使用五花八门的鉴权方案呢？缺少鉴权的二级规范文件，三级的文件自然无法引用，最终业务没有办法就鉴权方案这件事达成一致，安全也不知道该怎么评审现在的BA认证鉴权是否符合安全要求，最终运营项目宣告失败。
开展工作需要同不同层级的人打交道，就像新上任的CISO需要一张组织架构图、一张IT系统设计图一样，要项目顺利运营要摸清人际和部门的关系，他们分别负责什么，实线和虚线都要了解到。
比如要做一个“云等保测评”的任务，需要同CIO、IT运营人员、开发人员、合规治理、咨询机构打交道，大家在一起合作任务时，的第一个难题一定是是：我不知道什么问题该找谁？等保测评发现的代码仓库审计日志问题，同一线开发沟通难以配合，但是他的直接上级却能完成配合改正，站位思考不一样。
另外安全是并且只能是”自上而下“。有时候为了方便我们总想绕过流程，做一些“自下而上的事情”达成短期效果，长期来看是错的，虽然此时方便做成一件事情，但是掩盖了流程的混乱和决策机制，不利于建设透明、高效、信任的业务安全文化。
找到对的人目的是达成沟通，需要与他人合作的运营项目时，我们面对的不再是代码，不是黑客，而是HR、工程技术人员、非安全领域领导，他们没有“读心术”，要大大方方说出来你要他们干什么事情，需要什么帮助，也要谦虚谨慎不懂就问，遇到分歧时耐心倾听，换位思考、坚持原则性问题的同时也要适当妥协，明白对方说话的意义，自己说出来的话也得直指问题本质。
沟通时涉及要点是并不仅仅是一遍说，有的要求得和业务方反复说，反复澄清，不要高估非安全专业人员的对你要做的事情的理解力。
**上级分配给你一个项目时内心是最焦虑的，他从此将没有数据，没有进展，没有好消息也没有坏消息，犹如石沉大海，又如“肉包子打狗”。**透明才能高效，汇报的目的是为了决策，经常出现的一个阻碍安全运营效果的事情是从事技术的一线人员对于一个风险处理没有办法做出决策，而有能力做出决策的人没有全面的信息。上级交付给其他人运营任务时，表示委托给你希望得到风险闭环，就不要在临近结束时给上级时不时的“惊喜”，宁可提前消除“期望”，也不要让“希望”破灭。
但也不是说事事都需要请示，那是传话筒。影响重大的，没有先例的，拿不准的要事先请示取得一致，有时候形势来不及的，要当机令断，但是要断得符合以往的工作风格，在事后要及时汇报清楚，看能否补救或者双方对齐情况。
汇报要避免一切顺利的假象，上级的作用是协调资源提供帮助，让他看到目前的风险和应对措施更为重要，要平衡在上级心目中”你办事，我放心“的人设，也是及时汇报相互反馈。
汇报尽量避免只有会议这一个方法，不然效率太低，尽量通过书面或者简报完成，会议一般有多人参会，你汇报的东西大家并不关心，浪费大家时间。另个原因是汇报应该表示事情实际的进展，如果上级需要得到项目的现状，为什么要等到日程表有空呢，周一发现的问题非要等周五开周会才暴露？
工作的进度依赖于团队的整体能力，技术是其一，大家都熟，管理是其二，需要探索。从项目的角度来看进度一般是难以把控的，只能监控，只有科学监控才能得到项目的准确进展。运营安全专项和写一个项目代码没有什么不同的，我们很熟DevOps的开发效率，需求变更、弹性部署概念，自然也知道实时的告警监控至关重要。进度有偏差是正常的，但是需要知道进度。
除了自动化开发的指标能反馈项目的运营进度外，编制各种报告也是常见的管理工具，有口头汇报、简报、日周月季度等多种模板，依组织习惯有邮件、文档、IM多种形式。
简报是事情发生时帮忙相关人快速理解发生了什么和进度的文字内容。一般包含背景、影响、措施、并定期汇报。周会一般是输出周报，包含上周待办完成情况，工作范围、任务完成情况、问题对策和需要的帮助，还有下周计划。
月报并不简单是周报的合并，最好对交付的进度设定里程碑目标，里程碑是完成工作的标志性时间，包括时间点、标志性、交付物、关闭条件，一般一个专项有多个里程碑作为checkpoint检查进度，然后调整计划。
在安全运营的生命周期里肯定能达成阶段性的效果，比如一个规则的漏报误报率低于30%，XDR基本建设完成，这时候需要结项评估，结项时仅仅比对当时规定的需求范围进行验收。
不要一个事情永远做不完，明确deadline和验收标准，从不断完成小的专项积累建立成就感，有了信心可以不断尝试做更大的项目，达不到预定目标是正常，这不是背锅，学习型的团队从教训中得到收获，能避免重复犯错误。
安全项目有其特有的不确定性、曲折性、复杂性、专业性，有时候会有零零总总多个项目齐头并进，互相关联，比如要运营推进一个域控补丁的管理，但是此时ITIL流程系统还未建立。从项目集角度并不仅仅关注工作如何完成的，更关心资源是否得到充分利用。项目集的要素和项目一致，包括整体进展计划，详细进展、里程碑描述、风险和问题。通过透视图、甘特图等工具能一目了然看到有延期和暂停的风险项目。
平时运营时尽量有一双慧眼能发现新的安全运营点，扩大安全团队盘子避免内卷，孵化新的安全技术项目，然后规划立项到项目集里，尝试”无中生有“锻炼运营能力。
笔者忙得时候大概每天都有两次以上的会议，不是在开会，就是在准备开会材料，或者落实会议的待办项，但是切实知道干活就得会开会。但是考虑到ROI，尤其是推动大范围的安全运营事项时的多方开会是个高成本的事情，多人开会需要对每个人发开会的工资，而且开会期间他得假装开会，不能做别的有价值的事情，然而实际上大家讨论要解决的安全问题可能并不值得花费举办多次会议的沉没和机会成本。
开会的第一个要点是安排会议不要超过40分钟，不然大家会玩手机，问题不在参会者，在于时间的控制。人的天性是难以长期集中精力会疲劳，一旦疲劳会议的质量会直线下降，当然一个会议本身这么长已经表示项目出现了问题--之前各方的沟通已经不畅通需要对齐。
开会的内容一般分为三种：
运营前：
核心指标的制定，如果误报率指标定得高了，说明漏报率指标有变动，困难是找到合适的指标，说清楚选取这个指标的逻辑，对应的反向指标是什么；
计划在时间和任务上的拆解，是代码维度、应用维度、还是部门维度；
如何达成运营目标的策略会议，是采用了新的技术方案，是增加了人力资源去运营专项，明白是怎么样完成工作任务的；
如何保证项目进展的指标汇报，是统计大盘，还是通过周会晾晒指标。
运营中：
检查进度和质量，通过汇报或者定期会议；
发现执行的问题和原因并处理；
调整项目运营计划、指标。
运营后：
安全运营效果，进展总结，比如项目建设完成验收；
下一步计划制定和调整，比如一个安全方案在内部灰度试点计划完成后的大范围实施计划；
复盘和经验总结，比如专项复盘、绩效考核、述职汇报等。
开会是推动事情进展的必须项，但是要顺利达成进展，并不仅仅需要水平和经验，也需要事前周密的考虑和准备，对会议发生的情况和困难要一一想好对策，有了心理预期就比较准备，有了信心才能成事。自己都没有信心，怎么样合作伙伴相信你配合你做事呢？建议在开会前就写好会议纪要，开会就是想办法按照发起人的意愿分派工作，漫无目的的开会是集体划水。
组织会议的目标是大家达成共识，开会的过程是达成统一思想，求同存异，结果是执行解决会上的问题。开会前收集明确议题、议程、相关材料和沟通好时间，确保关键人参会，要有礼貌”请“人开会而不是通知，因为有些事需要人家点头才能推行。在会下花的时间要多于会上，不要寄希望一次会议产生神奇的效果，所谓“功夫在诗外”，提前要和有分歧关键点达成共识想到解决的办法才能高效会议。
会中要保持秩序，先说清楚要希望大家决策什么事情，议题含义，然后看材料讨论，要避免发散性的发言。会议保持紧张感是好事，每次发愁开会时当事人才会“如芒在背”传导工作压力。
会后的待办任务要确保当事人理解任务的含义，要干什么，验收标准是什么，也一定要标注清楚责任人和完成时间。哪怕任务超期未能完成，落在纸面上的东西起码有人重视会给个说法。纪要在发出时找到当事人确认避免有分歧，损失以后合作的公信力。下次会议就首先以上次会议的待办项来开始。
复盘是常见的一种会议类型，对一个安全运营效果的复盘可能有SRC漏洞复盘、蓝军渗透测试复盘会议、公司通告等多种形式，一次复盘会议的效果好坏本身也是值得运营负责人总结经验教训的。在攻防层面大家都很菜，工作仓促应战难免有失误，纵深防御么:) 有了失误就追究责任不利于后续工作。复盘不是为了惩处甩锅，而是为了吸取经验教训，找到真正的根因点，尽量下次不犯错。
虽然按照严格的复盘方法论要“对事不对人”，但是实际中是不可能的，事总是人做的，正是因为这样坦诚复盘机会很难得，要“刨根问底”才是负责任的态度。
大部分攻防案例的复盘，讨论到具体事情都是将“资源不足”作为根因，得到这个答案时证明一般没有掌握正确的工作方法--5Why分析，混淆了复盘根因和分配任务项的区别。复盘不应该是这样的，要考虑预期是什么？为什么不符合预期？还有没有别的办法？这些别的措施能阻止事情再次发生吗？复盘不在于问得问题多，而在于深入分析根因。
举个复盘的例子：问什么客服部门的员工会点击钓鱼邮件输入账户密码，回答是我们没有预算和资源不够，然后列举一大堆原因：没有时间和精力覆盖到每个部门去宣传培训；客服人员流动大；业务部门对安全不重视。那经过培训的业务有没有点击钓鱼邮件？怎么确定培训有效果？人员流动和对安全不重视有什么数据支撑？
也许深层次的根因是培训对于上规模的公司已经成了边际效应，投入更多的培训和宣传预算也阻止不了那么多的员工偶然性的中招，正确的做法不应该是增加培训预算，而是提高止损和发现能力。
这两类材料是开会或者推动运营工作的重要交付物，共同要求都是内容要精要，布局要精美，写作方法唯有多看材料，多练多思考才能进步。ppt和word各有优劣，看汇报对象是对语言还是文字更敏感。
好的材料要突出重点，弱化次要的信息，去掉任何无关的信息。有点技术会议上会用表情包那样的PPT，符合年轻人的风格，但是本质还是通过文字来铺排，信息量还是不够突出。好的材料要区分场合。对技术人员的演示可以有精确的描述，完整的具体和段落。但是面向多人的科普可以适当简化，反正会后他们再也不会看材料了：）
ppt作为材料汇报要有情感，看材料并不仅仅有理性思考，还有共鸣产生。在black hat、RSA等国外会议上的一些攻防相关的ppt，你不会记得他的实现细节，但会记得他提出来解决了让大家捉襟见肘的难点，这就是有共鸣相通的，不用花最多时间追求PPT里的花里胡哨，因为逻辑和数据OK，前面“宣称解决了，就是真的解决了，没人在乎”。
同技术介绍类会议的PPT相比，给领导汇报的PPT的前几页首先不要解释技术难点和业务逻辑，要谈“实现效果”，领导关心取得的业绩成果而不是工作过程。
WORD的缺陷是不能指望大家逐字逐句去做阅读理解。大家都很忙，有时候大家可能只有在发起人讲开场白的间隙看下目录结构和待讨论内容。要讲结论和待决策内容在前面，然后按照逻辑铺排开来，引申材料放在附件索引。
WORD的写作站位要放过读者，每个读者都在希望艰涩的技术讨论、可怕的大段代码，陌生的技术名词之间看到自己熟悉的内容：“谢天谢地终于找到我能懂的内容了，看来我不是这间会议室里的傻子”。本文就是在大量的项目管理名词之间穿插了大家日常安全工作的案例，希望你能理解笔者的苦心：）
笔者最近观察到一个典型的案例说明不同沟通场景下，对同一个话题，IDC内的零信任，不同沟通材料的底层协作逻辑如何不同。
从时间顺序上来说首先有这篇文章《张欧：数字银行可信网络实践》，这是作为企业安全负责人角度，讲解内部的建设理念、思路和方案，重点是组织要达成的业绩和实现路径。
而《ThreatSource：Google BeyondProd安全架构详解》这个PPT讲解的项目从安全架构师角度，同具体的一线开发人员交流技术细节和实现。
《零信任实践分享》是介绍他山之石，以谷歌员工过来人的角度介绍理论和实践，所以适当忽略技术细节，重点是诠释“经验教训”。
而《A Touch of BeyondProd》是从给同行分享普及这类技术，区分对各种技术决策的理解WHY，同类方案的选型WHT，要解决的问题和展望HOW。
材料《生产网零信任，阿里云落地最佳实践》是阿里云安全的宣传文，讲了落地并实践了的什么方案，解决了生产网的隔离问题，给客户以信心。
不同材料适合不同场景下的阅读人员。比对几份材料就会发现存在明显的异同，而这些材料讲得其实几乎是同一类安全运营项目！
参加合作方的会议要展示安全团队的风貌，是宣传安全理念的机会，要团结不要分裂，要阳谋不要阴谋。有时候一个专项任务会分解为多人承担的子任务，比如一个弱口令治理，可能有人负责数据统计分析、有人出技术方案、有人对接合作方“push”进展。专项负责人要尽量参加到这些会议中，哪怕实际手头有忙的事情，你的参会给小伙伴信心，有时候关键的一两句话可以显著推动事情的进展。
如果小伙伴说错了，不严重的不需要抢过话题去纠正，大家都是在探索尽量靠近运营治理的目标，会后沟通明确下次就有经验了。
对项目有强烈责任心的人总能发现潜在风险，看得远想得透。遇到困难不要扛着，首先要寻求帮助，要相信团队的力量，个人思考有盲区，多方思考沟通总是能开阔思路。还要积极主动化劣势为优势，在工作中难免有难点，主动提出建设性的想法，先不要摆手推辞，事后有时候看来并没有当初看来那么难。
项目进行过程中有时候让你生闷气吐槽，有时候让你绝望无助，有时候让你无地自容，不用慌，对于无能无力的事情坦然应对保持健康娱乐心态，合理承受压力稳定军心。
要坚韧不拔，不达目的不罢休，任何项目只要立项了，只要没人赶你走就坚决不离开，熬着总能有收获。
限于篇幅有些章节不能说透，但安全运营的实践同网络安全的特点一样没有银弹，这项工作只有言传身教或者让公司交学费。安全运营也可以很优雅，留给你适当空间可以大胆发挥根据自家的实际情况摸索，总而言之四个字：干就完了。
在安全行业我们总是逆流而上，同旧世界不断PK，Fighting，工作惯性很强大，知易行难，要想成功需要主动克服痛苦才能引导变革，只有走在追寻更有价值和有意义的路上才能保持竞争优势，创新改变世界，愿读者们长期有耐心，做好一位安全运营的长期主义者。
职业欠钱谈安全运营 https://www.zhihu.com/column/c\_1161574152535855104
《数据安全架构设计与实战》https://item.jd.com/12731728.html
《用图表说话：麦肯锡商务沟通完全工具箱》https://item.jd.com/11324809.html
PMBOK （美国的项目管理知识体系） https://baike.baidu.com/item/PMBOK/63635
