从“复盘”到“复仇”，谈如何正确的复盘

引言

安全运营有一个很重要的环节：闭环。如何从“复盘”到“复仇”，实现问题闭环？复盘一般意味着防守方被找到了安全问题，“复仇”是指同类问题不会再犯。我们鼓励通过复盘分析，确定事件的根本原因，找到最终解决方案，并落地执行，防止此类事件再次发生，实现完美“复仇”。

本篇聊聊如何正确的复盘，抛砖引玉。

企业日常安全运营工作中，每天会处置各类安全告警。红蓝对抗也已被广泛应用于检验防守方安全水位。告警处置和红蓝对抗之后，收尾工作是复盘。通过复盘，仔细检视我们安全工作短板，提出改进加强点。

一、三个实战场景复盘案例

1.1 案例1：社工控制销售岗员工终端电脑

在这个案例里，攻击者在我们官网上收集了我们的销售渠道，伪装自己是一个大学教授，想来采购我们公司的安全系统。攻击者为了社工攻击，准备了网络拓扑图，预算表格等一系列文件，来取得我们销售的信任。同时通过拟采购标的金额较大，时间紧来给销售心理压力。前期准备做完后，攻击者给销售发了一个Word标书和一个Excel技术参数文件。Excel文件中包含了一个宏，显示的是“由于参数信息敏感，请启用宏并输入随邮件的密码进行查看”。但实际上这个宏还包含了一段vba代码，这段代码就是vba版本的CobaltStrike。

事后我们对这个一次复盘，这个攻击链中使用了两个技术点：

通过微信投递样本来绕开网络上的监控
使用office宏进行样本投递，传统但是有效

问题1我们提出解决方案：通过流量解密还原出文件来跑沙箱，但是如何能解密还原微信的文件传输数据？问题2解决起来似乎很简单，现在有成熟的组策略，来阻断域内机器的office加载宏。

但这样就足够了吗？

攻击者这次使用excel宏来投递样本，下次使用其他的投递手段，我们怎么防御？同时思考怎么防御未知的样本投递方式？

根据这个问题，我们提出两个专项，从查特征的思路转换为查行为：

第一是通过落地沙箱机制，在终端上创建的新文件，自动跑沙箱，来监测样本在运行状态中是否有异常行为，对异常样本直接进行阻断或者查杀
为了防止沙箱失效，或者样本有对抗沙箱机制，我们在终端上部署了第二道防线：通过EDR来收集主机的进程链调用顺序，对其中的异常调用进行告警。攻击者无论投递什么类型的样本，最终的目的还是要控制终端。那么我们的思路就是办公软件创建了系统命令相关的进程，就是个异常的进程链，就要进行告警和响应

1.2 案例2：钓鱼邮件执行Powershell无文件落地样本

攻击者通过伪造一个终端安全软件的升级通知，给公司某个员工发送了一封邮件，邮件附件为一个精心构造的样本。当受害者打开这个样本的时候，安装包可以正常运行，也可以正常的对软件进行升级，但是攻击者在安装过程中多修改了一个注册表项。

Windows系统在每次启动的时候，都会读取这个注册表项的内容，并尝试执行里边的指令。攻击者在这条注册表项中，写了一段Powershell指令，这段powershell指令会去攻击者的公有云VPC上，下载一个远控脚本并执行。

事后我们对这个一次复盘，我们关注两个点：

邮件安全防护，这块可以采用市面上比较成熟的邮件沙箱解决方案
另一个是对这种通过修改注册表项，来做持久化的攻击手段。依托一些主动防御和EDR功能，对这种注册表修改进行告警或者阻断

但这样足够了吗？

下次攻击者伪造邮件时，我们能不能提前发现？攻击者使用别的手段进行持久化，我们能不能实时检测？

我们思考邮件安全防护时，要做一个完整的防御方案，不能单单依赖邮件沙箱。邮件网关中一些传统的恶意邮件防御方式，可以帮我们解决一些日常的垃圾邮件和钓鱼邮件。而针对实战化的鱼叉邮件，我们更是要做专项检测，包括检测绕SPF的常见手段，尝试伪造运维邮箱的特征，发件邮箱和正常邮箱高度相似。

而对于持久化，我们启动了一个专项来进行研究，发现Windows上持久化远远不止修改注册表这一种，还包括修改Windows启动目录，注册自定义服务，修改默认Office模板和默认Outlook主修，修改本地组策略，注册异常COM项。针对这些持久化行为，我们首先进行了技术调研和攻击模拟，然后再深度定制了EDR，记录的攻击过程中的种种痕迹，最后在SOC上形成了告警规则。

1.3 案例3：物理社工进入办公区，插U盘控制办公终端

第三个场景是我们红蓝对抗中真实遇到的一个场景。攻击者前期在公司周围踩点，发现由于防火通道不能关闭，普通人可以通过公用地下车库走楼梯间进入办公区。而周末加班时楼梯间到办公区的门禁有时会被长时间打开。

其实攻击者尝试了两种物理社工方式，除了上述方式外，还伪装公司员工买了一箱零食，借口没法拿门禁卡刷门禁，请保安代为开门禁，从而进入办公区。

攻击者进入办公区后，使用自带的破解U盘，绕开了一台办公机的开机密码，并将U盘中的样本文件拷贝到了受害终端上。

样本由两个文件组成，是白加黑的套路。白文件是一个普通loader，作用就是读取文件后，解码运行。黑文件类型为文本文件，为恶意dll编译后，又将内容进行了加密和编码。具体运行就是白文件加载文本文件后运行。

现在我们复盘这个案例。对于U盘投递，我们可以制定更严格的USB管控措施，禁止终端使用U盘或者终端只能使用注册过的U盘。但对于这种白加黑的检测，我们往往只能依靠安全厂商的方案，对内存态中的行为进行分析和审计。

但仔细想一想，是不是可以让一线同事们都参与到我们的纵深防御体系中来呢？能不能检测出更多的类似于插入未知U盘的异常行为呢？能不能让运营成本更低呢？

为此，我们建立了异常行为一键推送反馈体系。同事们在自己的账号/办公机出现异常行为的时候，可以第一时间在内部IM上收到网络安全部自动推送的通知，比如你的终端插入了新的U盘，你的VPN在异地登陆，你的账号在内网搜索了敏感信息。假如用户确认不是本人操作，或者感觉有异常，他只需要点击IM通知中的链接，网络安全部运营中心就会收到一条事件工单，由一线运营人员去进一步跟进处理。

邮箱异常登录行为告警

VPN异常登录行为告警

而针对这种白加黑，异常注入，内存篡改等检测和防御的老大难问题，可以检测代码块异常执行序列。每个程序在执行的时候，他的函数调用顺序，代码运行顺序都是在固定的n条序列里的。这个是计算机代码程序的基本原理。而我们通过对底层系统API的进一步hook，抽象出了代码块执行顺序，在每台终端上进行2-4个月的无监督学习，归纳总结出正常执行顺序。这样当任何攻击，甚至0day攻击发生的时候，由于攻击代码顺序不在任何正常序列中，且偏离值很大，就能自动识别出异常行为或攻击进行阻断。

二、如何进行正确的复盘？

2.1 正确复盘的第一步，提好的问题：

我们在重新梳理和回顾

1、我们怎么防御投递路径？

邮件监测，我们怎么保证邮件100%过沙箱？
U盘管控，我们怎么保证防护策略100%生效？
我们怎么保证没有未知的终端资产？
事中监控效果如何？
对终端提权监控/防御能力如何？

2、对凭证提取监控/防御能力如何？

3、对持久化行为监控/防御能力如何？

能不能发现攻击者的下一步行为？
横向移动？
反向隧道外连？
内部信息搜集爬取？翻看敏感信息？

4、安全运营？

是否有数字化指标来实时显示覆盖率？正常率？怎么维持高覆盖率？
一线运营人员处理告警的SOP？SLA？
快速溯源
怎么复盘告警能发现安全隐患？
安全隐患如何解决？

5、更多？

新攻击手法的发现跟踪？（C# Assembly）c sharp assembly
新安全技术的调研使用？（零信任 SOAR）

2.2 正确复盘的第二步，从人员、技术、流程、资源四个维度深入分析。

2.2.1 人员

分享一个安全意识的故事。当我还在金融机构的时候，信息技术部门使用项目外包开发的情况很多，由于外包带来的安全问题也屡见不鲜。当我详细了解项目外包厂商的工作模式后，我隐约感觉到：外包厂商的代码管理是个大坑。外包厂商的项目管理模式一般是：

1、由于甲方一般会提出一些个性化需求，所以外包厂商一般会安排少量开发人员到客户现场驻场开发。

2、驻场开发人员的代码，一般需要遵循厂商统一的代码管理要求，即需要将在客户现场写的代码上传到厂商的内网代码管理平台（Git、SVN等）。

3、如何让在客户现场的开发人员访问厂商内网代码管理平台？做的好点的是给驻场人员开通厂商的VPN，通过VPN连回内网，上传代码。做的一般的就是直接将内网代码管理平台发布在互联网上，也不会限定访问来源。

4、那厂商的内网代码管理平台的安全性就依赖于一层薄薄的静态密码了。而这个账户和密码，很有可能就在该项目组建好的QQ群共享文档中……

有了源码，可以做的事情很多。简单直接的就是code reveiw，发现应用层0day，然后getshell，而且是行业通用，意味着一个应用0day，可以击穿行业很多家企业的业务系统。

实际的故事比这精彩很多，危害也大很多，而且这个外包厂商是个很大很大，集中度很高的行业厂商。

在这个故事里，你会发现，安全人员对风险的感知能力很重要，就是当你在了解业务、流程、合作伙伴等等信息之后，你能不能很快的意识到这里面存不存在安全风险，风险有多大，大概在哪里，等等。而这个就是我理解的安全人员的安全意识。

安全人员的安全意识，是指对安全风险的感知能力。

君哥

在复盘时，可以从人员的安全意识、安全职责、安全技能进行分析：

人员安全意识是否足够？分三个层面：公司全体员工、信息技术部门员工、安全团队。公司全体员工的安全意识，需要通过实战化的安全意识攻击测试来提高。信息技术部门员工安全意识，需要结合开发、运维的不同特点来针对性设计提高方案。安全团队的安全意识，主要看是否具备对安全风险的感知能力。
是否清楚的知道自己的安全职责。研发认可自己需要在12个小时内确认并修复高危漏洞并发版吗？运维认可自己需要在Windows月度补丁推出后一天内批准补丁，并在3天内完成高危漏洞在生产服务器上的修复吗？公司全体员工认可自己感知到网络安全异常后应该反馈异常给信息技术部门吗？安全团队大部分时候一厢情愿的认为其他团队的安全职责划分，但实际安全事件发生后才发现分歧，并花了大量时间在管控分歧。
人员安全技能是否足够？研发人员是否具备修复漏洞的知识和技能，运维人员是否具备实施基础架构安全的技能，安全人员是否具备足够的处理告警的安全技能等等。安全事件的背后深层次原因，可能是人员的技能不足，导致无法胜任其所承担的安全职责。

2.2.2 技术

技术维度复盘，讲究点、线、面、体。

点：在终端上的攻防对抗领域，单个技术点包括：常见权限维持工具CobaltStrike检测、无文件攻击、终端插U盘等物理攻击方式，提出单点技术防护和检测方案。

线：同一类问题构成了技术线。除了CobaltStrike，我们还应该具备针对同类型的渗透测试和权限维持框架（如Nishang、Empire）进行防护和检测。除了常见渗透测试框架的防护和检测这一条线以外，还有端口转发和隧道穿越工具的防护和检测，如：proxychain,frp,lcx,ngrok,regrok,ew、FPipe,Portmap,Termite,socat,natbypass,iox,abptts,Powercat,dnscat,reGeorg,tuna,reDuh,iodine,EarthWorm,sSocks,venom。以及类似的很多技术线…

面：技术点和线构成了技术面，这个技术面就是：终端安全的攻防对抗。其他技术面还有：终端安全之基础架构安全（身份认证、可信）、终端安全之数据安全等。

体：技术面构成了体。除了上述技术面之外，终端安全这个体还包括去AD化、网络安全域划分和隔离、零信任体系等等。比如复盘时考虑网络二层隔离，所有终端和终端都无法在二层通信，只能访问公共应用（OA、Mail、CRM、Git…）。复盘时还可以考虑，AD的攻击面太大，如果不进行专业加固的话，3秒就被控，可以考虑启动去AD化进程。

技术维度复盘，除了点线面体，还可以考虑是否引进新技术，从底层进行改造，从根源上解决问题，比如Google BeyondCorp、BeyondPod的引入和实践。

2.2.3 机制

复盘第三维度，是机制，机制是否缺失，以及机制执行是否有效。

在做终端安全日常运营时，我们特别重视安装率和正常率两个指标，当我们通过准入手段确保安装率和正常率快速提升到一个较高水位后发现，无论怎么努力，指标提升都停滞不前了，仔细分析原因，发现是员工的入离职流程有问题。新入职的同事，有一些使用的是自己的BYOD设备，完全没有进行任何终端安全软件相关的工作，有一些领取的公司配发的电脑，往往也没有实名，终端安全软件停留在上古时期的版本，安全基线也不合规。那么一个非常尴尬的情况是，每周二的入职日，变成了终端安全项目组的噩梦，可能前一周，好不容易我们解决了100台有问题的终端，入职日一来，前一周基本就白干了。发现问题后，我们重新梳理和改进了员工入离职流程，将终端安全的要求内嵌入入离职流程，这个问题就解决了。

所以复盘的时候，我们要追问一下：这个事件的发生，是不是机制有缺失？机制有的话，是不是执行落地没有保障？以及

灵魂发问：如果有人不遵守这个流程，我们安全团队能发现吗？

聂君

（这个问题一般复盘的员工，没想到，或者不愿意去想和解决）

在机制复盘这个维度，我特别喜欢一个流程：安全运营持续改进流程。这个流程是对安全事件的闭环管理，每笔安全事件的处理结果最终必须为误报、属实，二选一。如果是误报，必须改进SIEM安全检测规则或安全Sensor监测措施。如果属实，根据已经被突破的层进行针对性的改进。安全运营持续改进要求每天、每周、每月都坚持进行安全事件review，有可能重要事件被一时大意的一线人员放过，也可能是其他原因。

安全运营持续改进流程的质量可能决定了整个企业的安全工作质量。

君哥

2.2.4 资源

复盘的最后一个维度：资源。

1、改变理念：安全团队是因为工作干得好，才能获取资源；而不是拿到了资源才能干得好。

2、上层文化：抓住公司的文化、组织、变革的变化，及时嵌入安全，让安全从中获益。当公司有巨大变化、活动时，一定要想到加入安全的元素、成分。

3、获取资源策略：作为安全团队的负责人一定要主动去想办法争取更多的资源，常见的有将安全工作显性化，通过红蓝对抗中打胜仗、重大安全事件复盘、对标同等或更好的企业投入，以获取更多的资源。

4、主动创造资源：从管理学的角度来讲就是胡萝卜管理哲学，公司给到员工的报酬肯定是有限的，除了金钱外，可以主动创造一些荣誉，在内部进行奖励和激励，特别是很支持安全工作的部门和个人。

2.3 正确复盘第三步：复盘方法论

2.3.1 复盘目的：

同样问题不再重复
同类问题尽量避免
不要在低级错误上失败
从“复盘”到“复仇”

解释最后一点：从“复盘”到“复仇”。复盘一般意味着防守方被找到了安全问题，“复仇”是指同类问题不会再犯。我们鼓励通过复盘分析，确定事件的根本原因，找到最终解决方案，并落地执行，防止此类事件再次发生，实现完美“复仇”。

2.3.2 复盘本质：跳出事件本身，对问题进行有效管理-问题管理。

我们经常提到：安全要像可用性一样运维。

君哥

数据中心运维的事实标准是ISO20000（ITIL），ISO20000有十几个流程，有一个关键流程是问题管理，就是通过问题管理流程，分析事件的根本原因，找到最终解决方案，并落地执行，防止此类事件再次发生。我们可以学习下问题管理的相关内容：

1、在问题管理流程中，如果我们定义一个问题，需要定义如下属性：问题来源、影响范围、影响度、优先级、问题状态、问题结束代码、原因分类、问题分类…

比较重要的事问题来源、问题分类，一般分Top2和非Top2问题，Top2问题属于部门级督办的重点问题，需要优先解决。

2、关键角色和职责。包括：问题经理、问题管理员、问题负责人、问题管理委员会、问题支持小组。

比较重要的角色是问题经理、问题负责人。笔者曾经担任招商银行总行数据中心问题管理员5年，分析过的运维事件超过千件，相比安全事件，运维事件的发生原因千奇百怪，而且都是击穿了一系列的防护和监控措施，最后导致可用性事件的。到后期，硬件故障和软件bug导致的可用性事件比例已经很低了，人因误操作导致的可用性事件占比较大，为了更彻底的解决这个问题，更专业的避免人为因素导致的生产故障，我们向大亚湾核电站学习交流，学习了“核电厂人因管理”，并且和国内该领域研究走在前列的南华大学的人因研究所合作，跨界学习。

3、关键步骤

关闭问题是关键步骤，必须达到一定标准，问题才能关闭。2011年我们制定的问题关闭标准如下，按照这个标准，我们当时一个人全年关闭一个Top2问题都很困难，对关闭问题的要求实在太高了。而且一旦已关闭问题的事件再次发生，已关闭问题会重新打开，并且对问题负责人进行负向激励。问题关闭标准如下：

4、衡量指标

复习完运维领域的问题管理流程，我们安全领域也可以借鉴学习。比如：

复盘质量好坏，我们可以看几个衡量指标：

问题解决率，指安全问题的解决比率，按照前述问题关闭标准，我们的问题解决率能够到什么水位？
主动发现问题数量，指安全问题中，哪些是被动发现，哪些是主动发现，主动发现问题数量和比例是多少？
重复问题数量，指安全问题中，哪些问题是重复发生？

有几个复盘注意事项：

优先解决已知问题
主动发现问题，主动解决问题
先点到线再到面体
提问式复盘，鼓励思考，多提好问题

2.3.3 提问式复盘

多问几个为什么，然后去追寻原因和答案，顺藤摸瓜就能彻底解决问题，实现正确复盘。

人员方面：

企业团队和员工清楚自己的安全职责吗？

各角色员工具备安全意识和承担安全职责所需的安全技能吗？（特别是安全团队没有安全意识和安全技能不足）

正向和负向安全激励对各团队和人员有效吗？

技术方面：

如何从技术层面，点状的防范这个问题？

有没有解决这一类问题的技术方案？

技术手段是否可以被绕过？

所有管理措施和流程是否有技术手段做落地保障？

如果这个问题无法防护或者说无法100%防护，有没有安全检测方案？

如果技术角度无法有效防护和检测，是否有管理措施代偿？

能不能从其他维度降维解决这个问题？

是不是我们解决这个为的技术方案不是最佳？有没有新技术方案解决这个问题？

机制方面：

安全事件发生，突破了我们哪些安全机制？突破的原因是什么？我们还缺乏哪些机制？

机制足够的话，落实执行是否有效？

安全管控是否被业务旁路掉？

如果有人不遵守这个流程，我们安全团队能发现吗？

安全运营持续改进流程运转情况？

资源方面：

安全团队是否资源足够？

安全资源的分配顺序是否合理？

除了人员编制和预算，安全政策的支持是否足够？

2.3.4 按上述复盘思路，我们再看两个案例：

2.3.4.1 案例1：白帽子提交Web安全漏洞。

安全团队收到漏洞后，进行漏洞复现确认，推动开发改代码，发版复测，上线，end。复盘开始：

问题是否已知？

1、已知问题的话，说明推修进度不足。推修进度不足可能隐含问题：

研发运维和安全对漏洞认知有偏差
研发漏洞推修有困难
在漏洞未得到修复前，安全没有提供风险补偿措施

2、未知问题的话，说明发现能力缺失。

不是0day漏洞的话，如果是框架类漏洞，说明安全资产发现能力缺失；非框架类漏洞，上线后自动化漏扫发现能力缺失。
是0day漏洞的话，看企业是否考虑需要防护0day。

有没有防护住白帽子测试？

1、从已经被白帽子报漏洞的结果来看，已知安全防护措施没有防护住，分析网络侧WAF和主机侧RASP失效的原因。

2、有没有检测发现白帽子的测试行为？如果没有，流量侧NTA、主机侧HIDS，以及其他安全检测措施为什么被绕过？

2.3.4.2 案例2：内部红蓝对抗结束后，安全团队复盘开始：

单个漏洞点复盘，参照白帽子提交Web安全漏洞思路进行
整体复盘。归纳各个单点漏洞的原因，从以下方面总结需要改进提升的面：

1、人

人员技能是否不足？人员技能不能胜任日志分析、告警响应、应急处置、溯源反制等工作
人员责任心不足。
人员意识不足。
缺乏激励

2、技术

防护和检测技术对攻击无效
没有有效防护和检测技术的同时，缺乏代偿性措施
没有尝试使用其他维度的安全新技术或新思路，进行安全防护和检测

3、机制（流程）

机制缺失
机制执行缺失，缺乏验证

4、资源

缺政策
缺支持
缺绩效
缺投入

关于复盘的分享，到这里就可以结束了。本次京东安全峰会的主题是【破壁·新生】，我增加了以下“安全建设新思路”的内容。

三、安全建设新思路

1、重塑基础架构安全

在AWS、Google为什么安全看起来做的很普通，但也没出什么事情？基础架构安全。

业界搞安全的很多都是攻防出身，不是做架构出身，而真正具有这些基础架构安全视野的工程师，又不会去做安全。整个安全界，其实很缺乏具有基础架构安全视野和能力的安全工程师。

大的银行有架构办，基本上成员都是20年以上的优秀程序猿，才能做架构师，大厂也有类似组织。研究基础安全问题。

基础安全问题包括：统一账户，如果账户和权限能够解决的好，能够给攻击队带来巨大的困难。应用鉴权、统一代码仓库等等。

lakehu提出：安全效果做到架构里去。业务提出需求时，安全就在里面。想法都类似，更高效、更彻底的解决安全问题。

只追随热点未清理自身：零信任架构，SDP等

只处理问题未深入根因：CredentialsHarvesting、账号密码泄露、FIDO等

只处理单点未考虑全局：秘钥管理、可信根身份、AAA、数据分级与处理等

只解决当下未思考未来：SOA、API化、Serverless、容器化等

2、重塑基础安全工作-SCMDB

安全资产管理已经讨论过很多次，这里不展开了。资产管理在信息安全中的地位正如 Toyota 的 Camry（很多人的第一辆车），它应该基础、扎实、好用。

3、重塑基础安全工作-安全域划分和隔离

从实战来看，网络层的访问控制被证明是最有效的（攻击者很难绕过去），不要相信应用层控制。网络层访问控制属于基础架构安全，这是最有效最重要的，整个安全防护的基础

访问控制策略原则：明细允许，默认拒绝，例外处理

从内网去互联网的访问控制

办公终端：除个别协议无法限制目的IP外，其余协议全部限制。特殊访问需求，快速开通。有条件的考虑：终端不能直接访问互联网，需要访问互联网的两种解决方案：另外分配一台上网终端、虚拟浏览器
办公服务器：特殊访问需求开通，默认拒绝
生产网：生产网终端禁止上互联网、服务器特殊访问需求开通，默认拒绝

从互联网访问内网的访问控制：对互联网提供服务的服务器必须在DMZ，和内网隔离u重要系统的访问控制策略

基础设施如AD、邮件系统的访问控制
别小看基础设施ACL访问控制，这是对抗应用和系统漏洞的最低成本和最有效措施。漏洞层出不穷，唯有ACL访问控制药效持久，强烈推荐
终端安全管控、自动化运维系统等集中控制系统后台登录限制访问来源。（优先使用网络访问控制、其次使用系统层限制、搭配使用应用层限制）

4、纵深防御-感知能力建设

现在很多组织面临的防御困境，从实战角度看，很多步骤基本上接近于零覆盖。

5、内生安全-安全左移

安全是一个奢侈品，从大多数企业不配备安全人员、配备但是人数很少，安全乙方产品工程质量参差不齐，可以发现，解决安全问题的理论、方法，早就被研究透。但是能落地落实的实践极少。

最后，因为大厂有钱有人，安全团队、资源投入比较多，更早的演进到了一个阶段：把安全能力内生化，融入基础设施，公司所有的产品/日常行为都通过基础设施控制，减少了对人的主动配合/安全知识/意识方面的依赖，不给大家犯错误的机会。因此，随着国内互联网头部公司市值、基础设施建设、外挂式安全建设到达一定的水位，头部的团队自然而然，也走到了这一步。

与此同时，Google把这些实践以《Google基础设施安全》、《BeyondProd》等Paper分享出来，业界开始热议“零信任”、“无边界”、“内生”、“云原生”的概念，都跟这个趋势有关系，本质上说的是一件事。

以热议的零信任、无边界为例：比如说，安装补丁，你再怎么催，也有很多人不愿意安装，拖拉。只要你做了这个所谓的beyondcorp，那不安装补丁，在网关处就直接拒绝了工作请求，你不得不停下来把补丁安装好。或者把杀毒软件升级好。“基础设施”内部生长出安全特性，基础设施是前提，基础设施也自然是卡点。

6、安全验证-失效检测

没有验证，就不是真的运营。

聂君

7、失效检测-矩阵式监控

将安全性当可用性一样运维。

有空就看看这篇：企业安全建设之矩阵式监控提升安全有效性实践

8、向上管理-要资源

安全团队要想法设法，在每次组织和文化变更中获益。

王宇@xi4oyu

细品，还真是靠谱的方法。

另外能不能要来资源，根源还是信任，信任不是凭空而来，而是来自于安全负责人带领团队做出的每一分绩效，以及展现出的能力和担当。最后一点是：拥抱变化，做好准备。

在 2020安全工作展望一文中提到：甲方安全团队组织架构会发生剧烈变化，安全团队能否承受变化。

大行、股份制银行会设置安全处和风险处负责安全。最近欣闻某大行成立安全运营中心（二级部），负责人为一级部门副总或总助级别，安全人员编制也大幅度增加。去年某股份制银行也成立了安全运营中心（二级部），不少股份制银行纷纷扩大安全人员编制，一次性增加30、50甚至过百的安全编制。这种剧烈变化，是企业为适应整个网络安全大环境变化下的主动变化，未来越来越多的银行，以及其他企业跟进。

这种变化体现了企业高级管理层为解决传统安全问题，选择从组织架构入手，牵一发而动全身，抓住首要关键问题的高瞻远瞩。但在成立了安全运营中心，人员迅速扩编后，原有安全团队能力和视野格局等，能否承受变化，迅速响应高级管理层需求，从而在剧烈变化中站稳脚跟，需要早做准备的。