一个10年陈酿的安全管理员：终端安全运营的实践和思考

前言

经过几次北门例行碰（扯）头（淡）会的头脑风暴，我们决定做一些经验交流的内容，主要梳理安全运营中的难点和痛点，争取寻找几个容易引起共鸣的子题目，用适合的案例介绍我方团队如何摸索和实践安全运营。

现在国内众多安全会议，各种高大上的概念模型，日新月异的新鲜词汇，真正落地时，就连最基本的终端防护是否能做好都要打上问号。近期台积电病毒事件爆发，直接造成78亿新台币损失，究其原因竟然是一个一年前已经发布的补丁。看似基础运营层面的纰漏恰恰反应出安全团队本身在风险评估和体系落地上的缺位。九层之台，起于垒土，地基打好了，楼才能盖高，否则工具再多也是浪费。

我叫欧阳昕，是一个10年陈酿的安全管理员，趟过坑，扛过雷。从去年开始，团队对单位10多万终端安全防护进行了功能梳理、整合和优化。项目建设和后期的运营工作比例约为3:7。以下将结合项目经验，采用问题场景复盘的模式，探讨政府单位或大型企业内部终端的安全运营实践。

正文

开篇先简单介绍一下终端安全的发展历程。终端安全是信息安全的一个细分领域，出现时间较早，基本上伴随着信息安全概念的出现便随之应运而生。在过去一段很长的时间里，国内的防病毒就等于终端安全，终端安全就等于信息安全。毕竟在信息技术发展的早期，网络攻击和黑客技术还没有像现在一样日新月异，大型分布式应用系统还没有广泛使用并提供社会服务，各类威胁、漏洞还没有引起从业者的广泛重视……以现在的标准衡量，那时候仅仅是刚解决了互联互通的“温饱问题”，基于这种“自然条件”的约束，黑客们的工具和手段比较原始，能做的坏事比较有限，病毒成为最直接有效的“凶器”。后来，随着技术的不断进步，终端安全威胁的边界逐步扩展，终端安全管理的方法论也逐渐成熟，在一个由海量终端组成的大型内部网络中，终端安全一般被定义成以下几个方面的工作：防病毒、补丁分发、桌面管控、网络准入以及行为监测和取证。最后，随着近几年ABC（AI,Big Data,Cloud）技术的迅猛发展，终端安全的受众范围又发生了一定的变化，从单一的计算机终端分化成办公环境的终端领域，服务器终端以及新一代的移动终端等三小类。本文将重点结合实践经验，介绍企业内网中计算机终端的安全运营实践。

探讨分三部分，包括准备篇、实践篇和展望篇。

第一部分准备篇：从运维到运营的角色转变是提升终端安全防护能力的先决条件

各位读者，如果身处这个行业，又从事甲方工作，可以先在脑海中思考几个问题：自己每天的工作内容是什么？是否亲历过影响范围波及网内80%以上终端的安全事件？有没有因为产品功能的问题怼过乙方？会不会觉得手上一直没有合适的工具或工具集去解决复杂的终端安全问题？有没有感觉到工作内容和工作职责的不匹配？

以上问题，折射出一个安全团队从运维到运营职责的转变轨迹。随着问题的陆续爆发，运维的同学会逐渐感觉到挫败和沮丧，因为似乎自己没日没夜的加班也不能消除问题的发生，反而逐渐在不断“跳坑–爬坑”的循环中迷失。我尝试解答这个问题：甲方安全团队，其本质上与一般的IT运维团队是不同的。

首先看看运维工作的定义：一般指对所负责系统的软、硬件资源优化、维护和告警处置，以确保系统提供服务过程中更好的发挥价值。对比一下安全团队的职责，他们的定位首先是系统的使用者，依据企业战略、总体规划、业务需要以及各类合规性文件，制定安全管理目标、发布安全管理要求、规划安全基础设施建设的技术路线，并以管理者和业主的身份，参与系统的建设，接管系统的使用，最终期望借此推动管理要求的落地，促进安全防护水平的提升。

显而易见，安全运营团队与传统IT运维团队的最大区别，是工作角色的差异，团队成员不但要承担系统日常巡检、策略配置和告警处置等运维层面的工作；还要作为业主方，依靠安全系统和技术手段，通盘考虑整体运行态势并作出决策性调整，以实现业务增值和管理效能的提升。概括起来就是从“我要怎么做”进化到“为了做什么我要怎么做”。因此，还在坑里的同学们应该意识到，您的工作职责显然不能仅局限于系统运维了，而是要更加关注所运维系统自身的价值和服务能力。可以说，甲方安全团队在成立之初就已经生成了运营的基因，无从选择，尽早完成思维模式的转变是做好终端安全管理的先决条件。

第二部分实践篇

如果您看到这里，说明至少对运营的概念有一定程度的接受。接下来，可以聊一些具体的案例，看看运营工作的痛点。

老生常谈的全生命周期终端资产管理是重中之重

资产管理是终端安全运营中最重要的基础问题，重要到没有资产管理就谈不上终端安全。试想当一个安全团队被有关方面通报了一台终端出现安全问题并要求快速处置时，一不清楚被通报的终端在哪，二不清楚具体的使用人，三不清楚这台终端的安全防护系统是否健全，四不清楚怎么快速完成修补……此时此刻，会议室里寂静无声，通报方、管理者和安全团队心里不断涌现大写的黑人问号脸……最后议定由安全团队进行扫楼式的搜查，直到找到这台终端为止。

这是一个很有代表性的场景，我们常说安全问题最终可归结为一个风险管理问题，而风险又可以量化成发生的概率乘以影响的后果。在这个场景中，最可怕的不是计算出来风险值有多大，因为多大都可以想办法去修补，真正可怕的是因为资产管理的问题导致风险未识别，最终标记为0。要知道，对大多数甲方终端安全运营团队而言，管不好和不管可是两种性质的问题了，台积电病毒事件就是最好的证明。

全生命周期的资产管理并不是一个新鲜的名词，对一个稍具规模的企业而言是体系建设的必须选项，ISO55000族标准中有相关要求和介绍，在此不做赘述。可以想象，一个具有海量终端资产的内部网络，往往预示着企业由横跨了多个业务、管理、行政条线的部门组成，因此除了制定标准规范外，如何有效打通资产生命周期内上下游的壁垒，形成动态的资产信息发布和收集，是每一个类似企业的安全运营团队所共同面临的挑战。比较常见的案例是“中间不要两头严”，例如通过强制行政效力完成了资产发放和回收过程的记录和信息共享，确保硬件资产价值本身可以被追踪回溯，但是忽略了在使用过程中对该设备使用人、物理位置以及相关软件资产的变更和记录，导致出现问题没有告警、不好定位，影响快速处置的效率。那么，回到最初的问题，怎么做好全生命周期的终端资产管理呢？我认为这是一个太大的问题，无论是理论体系还是技术实践，都不是一本书能够说清楚的，姑且用我方团队的实践经验抛砖引玉：

首先，明确需求再做规划，我方团队经过多轮次的调研和论证，提出三大类需求：一是要管理的资产要素，包括使用人、IP、MAC、位置、软件信息等；二是使用什么手段进行监测，拟采用的手段包括主机审计、网络准入控制和心跳包监测等，这样可以确保对资产的实时收集和监测，保证全生命周期资产管理的有效性；三是需要什么样的日志反馈作为管理依据，一般而言就是终端安全运营的日常指标，包含补丁下发情况、防病毒查收情况、桌面策略接受情况等。经过这几个需求的梳理，我方团队发现虽然终端资产管理涉及面非常庞杂，但是仍然有一条主线可以遵循，即：牢牢抓住全生命周期的动态安全信息资产。

其次，尽量设计出减少不同职能类型的人员交叉参与的管理流程，广泛依赖信息化、自动化工具完成信息获取。在我方运营团队前期调研过程中，发现各分支机构内部的资产验收、发放、回收、处置等流程差异较大，很难设计出一套完美兼容的流程化管理规范。此外，考虑到人员本身的能力偏差因素，即便开放一套可以共同维护的资产管理平台，也面临着一定程度的隐性错误成本。因此，我方团队最终决定通过加大技术手段的投入，减少人为参与，提升资产管理的有效性和准确性，具体措施是在网络准入层面首先针对机器的基础安全防护能力进行评估，未安装基础安全防护系统的计算机被自动断网；其次通过主机审计实现对主机名和计算机描述的自动采集和字符串校验，确保计算机规范命名且真实有效，不符合规范的被自动断网；最后是精细化运营管理要求，针对计算机的防护软件版本、补丁分发情况、病毒库升级情况进行校验，不合规的计算机均被自动隔离，在完成相关修补后再自动准入。经过以上三步递进式的运营管理，最终形成在网的全量终端资产管理库，且大幅降低了人力投入，显著提升了资产收集和管理效率，有效拓展了针对资产在使用过程中的实时监测能力，自动化的拉齐了终端的基础防御水平。

以上工作，涉及网内12万计算机终端，耗时2个月完成。

为我所用的展示和响应平台是安全运营水平的价值体现

在这个标题中，特意回避了时下比较流行的一个概念：态势感知。引用赵彦老师在《互联网企业安全高级指南》中的原话，“现在的安全行业里除了显得有些务虚的安全理论之外，要么就是一边倒的攻防，要么就是过于超前、浮在表面没有落地方案的新概念，这些声音对企业安全实操都缺乏积极的意义。”作为大神的仰慕者，简直不能同意更多……在这个会做ppt就能造车的年代，思考如何快速发声、抓住眼球、吸引资本，远比漫长的数轮次产品实践打磨，逐步完善进而形成口碑有吸引力。但是，既然身处这个行业，就免不了被各种信息碎片轰炸、洗脑，自然而然的形成了没有态势感知就不能安全运营的理念。

接下来，请您思考一下，在处理终端安全事件时，基本步骤是什么？套用攻击杀伤链和反杀伤链模型，简单阐述如下：

基于情报和规则的发现->对攻击的时间和空间定位->持续的追踪->寻找有效的防御武器->定点清除威胁->评估结果。

事实上，绝大多数安全运营团队在安全基础设施相对完备的基础上，在乙方技术支持和第三方安全服务团队的帮助下，已经将这条路径趟过不止一次了，典型案例就是“WannaCry”病毒爆发过程中，一般甲方运营团队的工作流程都是：收到国家有关部门的通知后拉响内部警报，结合自身安全防护系统的日志情况摸排战损，广泛投递网络隔离、端口禁封、专杀工具、官方补丁等不同维度的防御工具，按照2小时/次（甚至更短）的要求完成第一天工作日的战果汇总，最后领导宣布事态可控，匆匆结束近60个小时的加班后回家睡觉。在整个事件处置过程中，威胁情报获取，内部威胁摸排，应急手段的推广，事件信息的汇总，这就是态势感知这种思维和处置方式在应急事件中发挥作用的体现。本文并不强调平台或产品的名称，态势感知也好，SOC也罢，SRC也可以，只要是能够有效服务于甲方的安全运营工作，并且在应急事件处置中发挥积极作用，那便是有效的。

作为甲方终端安全运营团队，应对纷繁复杂的终端安全运营工作，需要这样一个平台，用来收集内部和外部的情报信息，分析网内的威胁情况，打通各安全系统之间的竖井，自动化的精准下发各类安全防御指令或工具。这个平台，是整个团队的价值体现：首先通过平台建设能够标准化的输出团队宝贵的应急处置经验，固化内部的应急处置流程，形成知识传递；其次为了建设能用、好用的平台，势必要求甲方安全运营团队整合现有安全基础资源，制定标准化的开发接口规范，将已有的安全基础资源封装成一个统一的武器库，试想对海量终端的威胁发现、一键修补和战果评估能够在一个平台上自动化实现，能够减少咱们多少个小时的加班^_^；最后，定制化开发平台的展示、预警功能，可以帮助运营团队细致梳理安全管理的目标和现状，找短板、补差距，真正做到运营夯实管理，管理促进运营。

还有一点建议，不管平台是否建成，首先要仔细梳理过往的运营事件，找到一条适合自己、切实可行的应急处置路径，再尝试从SOC做起，逐步增加漏洞发现、威胁情报收集等功能，同步规划现有安全产品的整合问题，最终的展示细节一定要充分吸取项目主要干系人的意见，因为这是项目成败评价的关键。以上路径，适合于初步具备安全运营能力，但是受限于人员和资源压力，难以同时并发开展工作的小伙伴们。

第三部分展望篇：辩证看待终端安全运营人力资源瓶颈的问题

由于这部分内容和每一个安全运营团队所处的业务环境、企业战略规划甚至是企业规模都息息相关，因此放在展望篇进行探讨，不求大而全，尽量把几个关键因素阐述清楚。

先抛出问题，有没有安全运营团队是不缺人的？可以随机采访任何一个安全团队负责人，相信答案一定是统一且坚定的——缺！同样的问题换一个方式问，团队还需要多少人？估计这个答案就五花八门了，但是基本上比照现有规模翻倍的需求占比应该不低于80%。我和大多数同学一样，常常被这个问题所困扰，总感觉有干不完的事，加不完的班，可是工作量并不会因为前一个任务的完成而降低，就像堆栈一样，没进来仅仅是因为进不来……另一方面，我方团队负责人常常在北门例行碰头会中突发奇想的找到各种新鲜、有趣的运营理念，并要求在工作实践中检验，此举显著增加了团队成员的工作量……经过几次思维碰（互）撞（喷），大家基本上达成一致，安全运营的人力资源投放理论上不可能匹配安全管理的要求。举例来说，一个10人团队管理100台终端，一个10人团队管理10万台终端，工作量是否相差很大？答案是显而易见的。但是，有没有办法在客观、有效、确有必要的前提下，让前者的工作量努力追赶后者？答案也是确定的。因为，安全只是一个相对的概念，没有绝对的安全才是客观事实。安全运营的目标，取决于管理层给团队负责人下达的安全任务书中对安全工作的考核标准。

回到前面的问题，为什么每个团队感觉都缺人，但是很难评估需要多少人？因为到目前为止，国内大部分企业还没有形成一套有效的安全绩效考核模型，可以精准的计算出对应什么样的人力资源应该达到什么程度的安全，以及应该给安全运营团队负责人下达什么样的指标。同样的，安全运营团队负责人，给成员开会的时候往往强调的是这个不能出问题、那个不能出问题，也是被绝对安全的标准裹挟了，因为受迫于没有真正有意义的考核指标，导致即使他们清楚的知道仅凭现有资源是无法做到大而全的安全，仍然要努力的往这个方向去做。目前一般有两种方法应对这种资源瓶颈：

一种是鸵鸟法。