企业如何构建有效的安全运营体系

引言

我们谈安全运营不是太多了，而是太少了。2019年BCS北京网络安全大会最后一天下午，安全运营分论坛邀请了ATM、金融和安全公司内部安全团队等嘉宾，开讲安全运营话题，获得广泛关注。

让我们期待明年基于实战的安全运营技术讨论，包括海量日志采集和解析，运营规则优化，威胁狩猎模型，溯源分析，自动化处置，安全反制等，明年见。

本文发表于2019.08期《中国信息安全》杂志.安全运营专题，感兴趣的文末有专题汇总版。

在企业信息安全建设初期，在网络层、系统层、应用层、数据层等部署了一系列安全设备和管控措施进行日常运维，并确保其稳定运行。但往往会发现安全状况并没有得到有效的改善，安全问题仍然频发，究其根本原因，是没有进行有效的安全运营。那么，企业如何构建有效的安全运营体系呢？

1.安全运营是什么

有一些安全工程师非常喜欢写一个扫描器、做一个HIDS的DEMO、搭建一套大数据分析的平台、分析某个漏洞的细节并研究POC，这些工作都是有意义的，但是，这不是全部。“手段不是目标”，写出一个扫描器，是手段，目标是为了提前检测出漏洞，减少公司因漏洞带来的安全风险，写出一个HIDS也是手段，目标是能够发现入侵事件，及时止损，搭建一套大数据分析平台同理。站在为目标负责的角度，你的确写出来了一款扫描器，但是我使用开源产品或者商业产品同样拥有一款扫描器，除了让你本人有成就感之外，究竟对目标作出了什么样的贡献？

“我做出来了扫描器，可是没例行跑起来啊，因为一跑起来，把业务扫挂了/业务告警一大堆抗议了……”

“我的扫描器有例行跑，但是测试用例没人家的全啊，好多漏洞检测不出来啊”

“我的测试用例特别全，集众家之所长，就是误报多了点，多到什么程度呢？每一个漏洞我都能检测出来，但是伴随着成百上千的误报，所以得人肉一个一个筛选才能转发给RD修复”

“我的扫描器很厉害，就是目标URL不在扫描列表里，经常不在列表里”

但是企业真的是为了我们做出来的扫描器、HIDS之类的手段而付费么？企业多数情况下是为产出付费，而不是为知识付费。

在大的公司，解决问题的需求很强烈，安全技术、安全管理、安全开发等角色都具备的前提下，老板发现某一些安全问题总是无法收敛，最终，引入一类新的角色，对问题进行分析、诊断，发现症结后，协调资源，终于实现了目标。自此，安全运营工程师就出现在了世人的面前。他们什么都做，看起来没有技术含量，但他们的职责是比较清晰的：为项目的最终目标负责，从而不断诊断分析问题、提出需求、协调各方资源，共同达成目标的人。这里最重要的是解决问题，一切影响目标达成的因素，都是运营的职责。

参考上述内容，安全运营定义为：

“为了实现安全目标，提出安全解决构想、验证效果、分析问题、诊断问题、协调资源解决问题并持续迭代优化的过程”

职业欠钱

 

        2.安全运营解决什么问题

让我们拿着显微镜，看看安全管理员每天的工作内容。安全管理员需要每天查看各类安全设备和软件是不是正常运行；安全设备和系统的安全告警查看和响应处理如入侵检测、互联网监测、蜜罐系统、防数据泄密系统的日志和告警，各类审计系统如数据库审计、防火墙规则审计，外部第三方漏洞平台信息；处理各类安全检测需求和工单；有分支机构管理职责的还要督促分支机构的安全管理工作；填报各类安全报表和报告;推进各类安全项目；有的还要付出大量精力应对各类安全检查和内外部审计。

做过基层安全运维的人对上述场景都会很熟悉，这是金融企业安全各个场景的缩影，但不是全貌。如果一个企业只有少量人员、服务器和产品，那么上述内容就是企业安全工作的全部。但是，如果是有万台服务器，几百个程序员，数以百计的系统，企业安全除了安全设备部署、漏洞检测和漏洞修复外，还要考虑安全运营的问题，从工作量上看，这两类工作各占一半。

占据“半壁江山”的安全运营，重点要解决以下问题：

1）安全运营的第一个目标：将安全服务质量保持在稳定区间。

企业部署大量的安全防护设备和措施，在显著提升安全检测能力的同时带来问题，安全设备数量急剧增多，如何解决安全设备有效性的问题？在应对安全设备数量和安全日志告警急剧增多的同时，如何确保安全人员工作质量的稳定输出？安全运营的目标是要尽可能消除人员责任心等因素对安全团队对外提供安全服务质量的影响。

举个例子，就像大餐和快餐，大餐靠的是名厨名师的发挥，如果今天这个名厨心情不好或者换个新人，可能做出的产品质量就有非常大的下降。而快餐如肯德基，所有的操作都标准化和流程化，就是初中毕业没学过烹饪，没练过的人经过短期培训和严格管理，也能确保炸出的薯条味道一模一样。快餐的标准化流程和管理几乎完全消除了人的因素，确保对外提供的服务质量能够始终稳定，不会出现大起大落的情况。

安全运营的目标之一，就是在企业变大，业务和系统日趋变复杂的情况下，在资源投入保持没有大的变化情况下，尽量确保安全团队的服务质量保持在稳定区间。

2）安全运营的第二个目标：安全工程化能力。

安全运营还需要解决的一个问题是安全工程化能力提升的问题。举个例子，企业内很多有经验的安全工程师能够对怀疑一台服务器被黑进行排查溯源，查看服务器进程和各种日志记录，这是工程师的个人能力。如何将安全工程师的这种能力转变成自动化的安全监测能力，并通过安全平台进行应急响应和处理，让不具备这种能力的安全人员也能成为对抗攻击者的力量，这是安全工程化能力提升的收益，也是安全运营关注的问题。

3.安全运营建设思路

从架构、工具和资源三个方面探讨安全运营的思路。

3.1 架构

安全运营架构如下图1所示：

图1 安全运营架构

 

为确保安全运营架构能够灵活扩展，推荐按功能模块划分成四个模块：安全防护框架、安全运维框架、安全验证框架、安全度量框架。

• 安全防护框架的主要功能是通过不断的部署安全监测系统，提供实时检测的能力，称为安全感知器“Sensor”，为安全运维框架提供“天眼”。时下流行的态势感知、入侵感知我理解为主要靠安全防护框架来保障。

• 安全运维框架的主要功能是统一采集安全防护框架各Sensor的监测信息，并通过黑白灰名单处理和关联分析（有很多厂商号称大数据智能分析，笔者理解为只是基于规则的数据挖掘），处理监测信息并通过统一展示平台输出告警，进入事件处理平台和流程，人工介入处理。安全运维框架还包括安全事件的定期review和向管理层汇报，这部分可能比单个的事件处理要重要。

• 安全验证框架主要功能是综合通过黑盒白盒验证措施，确保安全防护框架和安全运维框架的有效性。

• 安全度量框架主要功能是通过一系列安全度量指标，衡量评价安全运营质量水平，并针对性持续过程改进，实现质量的螺旋上升。

 

3.1.1 安全防护框架

安全防护框架的目的是部署尽可能多和有效的安全感知器Sensor，这些安全感知器构成了信息安全的“天网”，这部分是基础工作，也是传统安全的主战场，需要历经多年的持续投入积累。安全Sensor的部署遵循纵深防御的理念，如下图20-2所示：

图2安全防护框架

 

实际中可能远远不止上述这些Sensor。比如网络层，可以把防火墙监测信息特别是Deny信息采集了，有些防火墙还自带IPS功能如CheckPoint的SmartDefense，就是特别好用的安全Sensor，交换机、路由器的ACS服务器信息、堡垒机登录信息、虚拟层虚拟主机操作信息、Windows、Linux主机日志、有在主机部署安全客户端的监测信息、数据库审计系统监测信息、AD系统信息、存储备份系统操作信息、KVM、ILO等带外管理系统信息、ITIL系统工单信息、应用系统应用信息如OA系统应用日志、SAP系统应用信息、公文传输系统日志、FTP数据传输日志。

企业基础安全的很大内容就是建设各类安全Sensor，解决点状的安全问题和需求。比如企业防火墙多了，如何管理防火墙规则的有效性和合规性，可能需要部署诸如Algosec、firemon等防火墙规则审计工具，审计发现的信息就可以作为安全运维框架的输入。如果想监测企业内网或服务器访问了哪些恶意地址，可以采集类似ArcOSI这样的开源恶意地址库。

3.1.2 安全运维框架

安全运维框架的建设目标是成为企业安全的大脑、神经中枢、耳目和手脚。在军队现代化作战体系中，美军创造性的提出了C4ISR作战指挥系统，即指挥、控制、通信、计算机与情报、监视、侦察。一个完整的信息安全作战指挥自动化系统应包括以下几个分系统：基础架构平台、安全情报监视系统、数据分析系统、安全控制系统。

•  “大脑”-基础架构平台。基础架构平台是构成指挥自动化系统的技术基础，指挥自动化系统要求容量大、速度快，兼容性强。

• “耳目”-安全情报、安全监视、侦察系统。主要是对安全防护框架中各安全Sensor的安全信息的收集和处理，实现异常行为的实时安全监测。

•  “神经中枢”-数据分析系统。综合运用各类智能分析算法和数据挖掘分析技术，实现安全信息处理的自动化和决策方法的科学化，以保障对安全控制设备的高效管理，主要技术是智能分析算法和模型及其实现。

•  “手脚”—安全控制系统。安全检测和控制系统是用来收集与显示安全信息、实施作战指挥系统发出安全控制指令的工具，主要是各类安全控制技术和设备，如防病毒和主机安全客户端、防火墙等，主要实现异常行为的实时安全控制。

安全运维框架实际落地时，企业会部署SIEM、安全大数据等类似平台实现安全检测信息的统一采集、分析处理和存储，大部分平台支持内置或自定义的黑名单检测规则进行实时检测。安全运维框架还有很重要的一部分，安全事件的流程化处理和定期review、汇报。安全事件的流程化处理应遵循企业事件管理流程如ITIL，通过自动化下发安全工单，发送告警邮件、短信等方式进行安全提醒，安全事件确认和溯源分析主要通过人工分析和确认的方式进行。对于100%确定异常的安全攻击通过自动化方式进行阻断。同时通过安全事件日例会、周报、月报、年报等方式进行闭环管理，并进行必要的管理层汇报。

3.1.3 安全验证框架

安全验证框架解决安全有效性的问题，承担对安全防护和安全运维两个框架的功能验证。安全验证框架是企业安全的蓝军，在和平时期，蓝军扮演着对手角色，利于及时发现、评估、修复、确认和改进安全防护和运维框架中的脆弱点。包括白盒检测（过程验证）和黑盒检测（结果验证）两部分。

白盒检测（过程验证）是指建立自动化验证平台，对安全防护框架的管控措施实现100%的全面验证，并可视化集成至安全运维平台中，管控措施失效能够在24小时内发现。通过自动化验证平台达到：

• 验证安全Sensor安全监测功能有效；

• 验证安全Sensor所产生监测信息到SIEM平台的信息采集有效；

• 验证SIEM平台的安全检测规则有效；

• 验证告警方式（邮件、短信与可视化  展示平台）有效

基于上述目标，自动化验证要求所有的验证事件必须为自动化模拟真实事件产生，不能使用插入记录的方式产生，同时自动化验证事件应提供判断是否为验证事件的唯一标识，验证事件产生时间需统一安排，防止集中触发。安全运维平台应能够监测到安全验证未通过的系统和规则，并产生告警信息，通知安全运维人员介入处理。

黑盒检测（结果验证）是通过多渠道安全渗透机制和红蓝对抗演习等，先于对手发现自己的漏洞和弱点。多渠道安全渗透机制目前常见的就是安全众测，红蓝对抗演习需要企业具有较高攻防技能的安全人员，也可外聘外部专业机构完成，用于检测安全防护框架和安全运维框架的有效性。

3.1.4 安全度量框架

安全度量框架主要用于衡量评价安全有效性，这是挺难的一件事，此处仅做些探讨。可以分成几个层次。

一是技术维度。包括防病毒安装率、正常率，入侵检测检出率、误报率，安全事件响应时长、处理时长，高危预警漏洞排查所需时间和完全修复时间。还可以考虑安全运维平台可用性、事件收敛率等。合规性方面可以设置合规率、不合规项数量、内外部审计发现数量和严重度等；

二是安全运营成效。包括覆盖率、检出率、攻防对抗成功率。有多少业务和系统处于安全保护之下，有多少无人问津的灰色地带，安全能在企业内部推动得多深入，多快速，这是需要综合技术和软性技能的，成败主要系于安全团队负责人。检出率和攻防对抗成功率都是衡量安全有效性的有效指标，安全团队即使不能拍着胸脯保证不出事，也不能靠运气和概率活，那持续提升检出率和攻防对抗成功率就是努力的方向；

三是安全满意度和安全价值。安全价值反映在安全对业务支撑的能力，TCO/ROI，安全用多少资源，支撑了多少业务，支撑的程度。安全价值还体现在内部的影响力以及对业务的影响力，是做微观安全还是广义安全，是为业务带来正面影响还是负分拖后腿。安全满意度是综合维度指标，是对安全团队和人员的最高要求，既要满足上级领导和业务部门对安全的利益诉求，又要满足同级横向其他IT团队对安全的利益诉求，还要满足团队内部成员的利益诉求，要提供最佳的安全服务，让安全的用户成为安全的客户，让使用者满意，真的是非常非常有挑战的一件事情。

3.2. 工具

安全运营工具包括支撑安全运维框架实现的SIEM平台、安全事件处理标准化流程工具ITIL、安全控制自动化工具三部分：

• SIEM平台负责安全信息的统一收集和存储、基于检测规则的异常检测和告警

• ITIL平台负责接收SIEM平台发送过来的安全事件信息并据此产生ITIL工单，推送到安全运营人员处理和关闭。

• 安全控制自动化工具负责根据SIEM平台下发的安全控制指令进行自动化操作，例如，检测发现有外部攻击源，通过下发自动化指令实现防火墙或IPS封禁该攻击源；检测发现某主机有可疑进程，通过安全客户端收集该进程文件样本信息进一步手动分析；检测发现办公内网某用户计算机上有个可疑操作非人工操作，疑似程序自动操作，可通过安全客户端提示用户手工确认等。

SIEM平台、ITIL平台目前市面上成熟的产品不少，但安全控制自动化工具目前商业化程度不高。

3.2.1 检测规则

如果有合适的检测规则，SIEM是个非常强大的工具，可以检测其他安全工具无法捕获的安全事件。通常SIEM的检测规则有三类：

1.单一检测条件规则

满足单一特定检测条件则触发告警。如服务器主机登录来源非堡垒机地址。满足该条件则告警，该类型规则最简单，主要依靠安全Sensor的监测能力和规则过滤能力。是攻击就一定有异常，关键是怎么总结提炼出异常的特征加以检测，比如Ayazero在《互联网企业高级安全》中提到的检测攻击提权，“某个高权限（system?uid=0）进程（bash?cmd.exe?）的父进程为低权限”，是一个总结提炼异常特征加以检测的很好案例。

2.跨平台安全监测信息关联检测

最典型的规则为基于资产脆弱性的攻击告警，关联分析漏洞扫描和入侵检测告警信息进行关联检测。还比如防火墙permit日志中有连接ArcOSI中定义的恶意IP地址信息。

该类型规则在跨平台系统监测信息之间进行关联，可以衍生出很多脑洞大开的检测规则。比如检测安全违规行为，检测数据泄密，甚至人员可能离职等。这类规则检测效果的好坏取决于两点：一是安全Sensor的类型尽可能多和单个Sensor能监测维度尽可能广；二是规则设计者的检测思维，就像攻击者思维一样，需要脑洞大开，需要从“猥琐”处着眼。

3.针对长时间缓慢低频度攻击的检测规则

大部分的安全工具是以孤立方式识别潜在的安全事件，如IDS监测到某台工作站发出的可疑流量，然后从其他20台工作站上监测到同类流量，在IDS管理面板上，每个事件被当作单独事件处理（有些IDS厂商有高级功能），在SIEM中可以编写规则，根据事件发生的频率触发不同的告警，如果在几分钟内从IDS传来21次类似的事件可以触发一条规则。如果攻击者采取长时间缓慢低频度攻击入侵企业内网，可以编写一条SIEM规则，在较长时间内搜索特定事件，并在该事件范围内发生次数达到某个阈值时告警。

更进一步，这种检测规则对于不是即时安全事件形式出现的日志也同样有效。如检测DNS Tunnel为例，DNS Tunnel用于将C&C流量编码为DNS请求，从被感染机器发出，通过被感染企业的DNS服务器到达C&C服务器，然后再将响应返回给企业的DNS服务器，由其转发给受感染的内网机器。正常的DNS查询都有一定频率，DNS Tunnel需要在网络上发送许多DNS数据包，那么制定内网单台机器对同一个域名的查询达到某个阈值（如10分钟内1000个查询）的规则可以有效检测DNS Tunnel。

SIEM的检测规则还可以配置为在流量来源与旧模式不同时发出告警，也可以配置为在合法和以往正确的流量突然呈现指数上升或者下降时发出告警，如过去90天内产生一定数量日志的Web服务器突然开始产生于10倍于正常数量的日志，这可能是被入侵主机用于向其他主机发动攻击的迹象。通过SIEM规则，安全团队可以根据流量的标准差制定告警，如达到10个标准差阈值就告警。

3.2.2 健康度监控

从很多攻防案例中，防御方失败的原因主要归结于安全防护失效，其中SIEM平台工具健康度出了问题是比较常见的，包括：安全Sensor安全监测信息采集器失效、SIEM检测规则失效、安全告警失效、安全告警处理失效等。

• 安全检测信息采集器失效的原因主要是未对采集器的物理机器性能监控、采集数据正常监控、采集数据日志解析和映射入库（Parser）异常等。

• SIEM检测规则失效包括设定条件无效、阈值无效、规则未生效等，有时告警阈值设置不合理频繁告警，SIEM平台会自动禁用规则导致规则无效。

• 安全告警失效，包括邮件、短信网关配置无效，配置用户失效、网络失效、配置变更异常、手机号码设置错误等等。

• 安全告警处理失效主要是人的因素，比如多条告警短信，选择性的忽略，假阳性告警太多淹没了真正有威胁告警等。

值的一提的是安全Sensor自身的安全性。韩国在2013年3月20日下午2点，包括新韩、农协和济洲等3家银行与KBS（韩国广播公司）、MBC（韩国文化广播公司）等2家电视台，超过32,000台电脑以及部分ATM提款机，都在同一时间宕机，无法重新启动。黑客首先入侵了韩国防病毒软件厂商AhnLab（安博士）的病毒定义更新服务器，利用病毒库定义升级机制，将恶意软件分发到用户的计算机，在用户的计算机上安装执行恶意程序。调查发现，另一家防病毒软件公司ViRobot也被黑客利用。

试着设想一下，如果你在企业内部部署的安全Sensor接受更新的是恶意软件……，不寒而栗。因此，做好安全Sensor的安全性的重要性，无需再做强调，只需注意几个原则：

• 控制指令仅允许固化的指令，严禁在Sensor端预留执行系统命令接口；

• 更新包必须经过审核之后上传至更新Server保存，更新仅允许选择更新Server上以后的安装包，最好校验更新包的MD5；

• 控制指令下发时必须人工审核确认后才执行。

• 为可用性起见，更新最好分批分区域完成，否则由于大量更新包的下载导致生产网被堵塞，恐怕也是不可承受之痛。

3.3. 所需资源

资源一般包括流程与机制、组织架构、人员等，是实现安全运营的保障性措施。

3.3.1 流程与机制

有效果、高效率的安全运营流程与机制，是非常重要的。安全运营流程的核心是做好两个标准化的流程：安全事件处理流程、安全运营持续改进流程。

1.安全事件处理流程。

定义什么级别的事件该由什么样的人，在什么时间按什么标准处理完成。一个外部攻击扫描，和一个内部分支机构持续不断的高权限账户猜解，两者安全级别肯定不同。前者最多为普通或关注事件，由安全一线工程师下发一个指令，在防火墙上自动封禁该外部IP地址一段时间即可。后者需要定义为高风险事件，需立即由有经验的安全二线工程师或安全专家联系分支机构进行溯源排查，有可能是中了金融行业的特种木马，有可能是网络蓝军在偷袭，还可能真的是有攻击者进来了。不管如何，发现这些问题，就意味着安全感知能力已经往前进步了，安全终于不再是靠运气和概率活着。

2.安全运营持续改进流程。

安全事件的闭环管理，每笔安全事件的处理结果最终必须为误报或者属实，二者必选其一。如果是误报，必须改进SIEM安全检测规则或安全Sensor监测措施。如果属实，好的一面是安全检测能力有效，坏的一面是坏人已经进来了，那就需要根据坏人已经突破的层面，进行针对性的改进。安全运营持续改进要求每天、每周、每月都坚持进行安全事件review，有可能重要事件被一时大意的一线人员放过，也可能是其他原因。

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

聂君

3.3.2 组织与人员

我们期望的大型安全部门组织架构图应该是这样子，如下图20-3所示：

图3 期望的大型安全部门组织架构图

 

实际工作中安全部门组织架构图却是这样子，如下图20-4所示：

图4 实际工作中安全部门组织架构图

 

理想很丰满、现实很骨干，理想和现实总是有差距的。

团队规模方面，互联网公司阿里和腾讯，其安全团队的规模大约在2000人左右，总员工数约30000多人，安全团队人员占总员工人数约7%左右，金融行业和这个比例差距还比较大。国内股份制银行总行安全团队规模一般约10-20人，总行IT人员从几百到几千不等。券商普遍安全团队人数在2-5人之间，个别券商的安全团队有7人，已经算是“豪华配置”了。

作为金融企业安全部门中的一个重要团队，安全运营的实现肯定也离不开组织与人员，以下是推荐的安全运营团队配置：

证券公司安全运营人员建议按1:2:3比例配置。即一个安全运营平台运维人员，包括服务器和应用运维，该部分可以交给IT部门的运维团队代为运维。2个安全人员互备，一个负责安全Sensor建设，一个负责安全检测规则和安全二线，事件调查、回顾与汇报、持续改进。3个外包安全一线，负责7*12事件响应和初步调查确认。

股份制银行安全运营人员推荐配置为证券公司的2-3倍，外包人员还可视事件类型和数量增加。

4. 安全运营的思考

有了架构、工具、资源，安全运营一定就能做得尽如人意吗？答案显然是否定的。因为实际工作中，还会遇到这样那样的问题，需要时刻保持思考，并做出适应和改变。

4.1 难点

互联网行业的安全建设引领全行业的发展，原因是什么呢？人财物资源投入大？自由市场竞争充分？我认为最重要的原因是，面临解决实际安全问题的压力和需求时，采用了最快最有效的解决问题的安全方案。如果直接采用传统行业的传统安全解决方案，来搞定互联网行业的安全问题和需求，无疑是行不通的。所以互联网行业做安全的关键词是有效解决实际问题。

在2010年以前，我们和国内金融行业同仁交流的时候，做安全的思路普遍还在监管合规+设备部署的阶段。我认为这是合理的。安全是和需求相匹配的，金融行业是牌照行业，监管合规是安全的首要和最重要需求，安全团队在这个阶段最大化的满足监管合规的目标。同时由于国家对金融业的法律保护等客观因素，金融行业的业务系统面临的风险远没有互联网行业高。

但在2010年后，由于网上银行、移动金融的快速发展，以及国内互联网安全环境的进一步恶化，金融行业的安全需求开始发生深刻变化，需要有效解决实际安全问题。监管合规和设备部署经过历年不断的持续改进提升，但还是会不断的出现安全事件，方向在哪？笔者的理解是，从设备部署向安全有效运营的方向转变，是个不错的思路。

安全运营的核心是安全运维框架，承载安全运维框架的是SIEM平台或SOC平台。在金融行业微信群里经常遇到一个问题，为什么SOC容易失败？这个问题，可以等同理解为，安全运营的难点在哪？

   （1）企业自身基础设施成熟度不高

安全运营的质量高低和企业自身基础设施的成熟度有很大关联。如果一个企业自身的资产管理、IP管理、域名管理、基础安全设备运维管理、流程管理、绩效管理等方面不完善，甚至一团糟，安全运营能独善其身、一枝独秀吗？防病毒客户端、安全客户端的安装率、正常率惨不忍睹，检测出某个IP有问题但却始终找不到该IP和资产，检测发现的安全事件没有合理的事件管理流程工具支撑运转，检测发现内部员工不遵循规范导致安全漏洞结果无任何约束，那安全运营能做什么呢？还是把点的安全做好，再考虑安全运营比较合适，比如首先把防病毒客户端运营好。

   （2）安全运维不能包治百病

安全运维不能包治百病。由于安全运维框架并不自身具有安全监测能力，安全监测依靠安全防护框架，SOC平台自身不产生信息，需要通过安全防护框架建设一系列安全Sensor，才能具备较强的安全监测能力，才能在企业内部具有一双安全之眼，所以安全运维建设不能代替安全防护建设，该部署的安全系统、安全设备还是要建。

   （3）难以坚持

安全从业者们都有一个朴素的愿望，就是希望能有一双上帝之手，帮我们解决所有的问题。安全问题，往往都很棘手，我们的直观反映总是希望能有一个成本比较低，时间消耗比较少的安全解决方案，可总是事与愿违，因为安全没有速成，没有捷径。但凡和运营相关的，其实都不是高大上的事情，往往是和琐碎、棘手、平淡相关，甚至让人沮丧，所以安全运营难以坚持。坚持把每个告警跟踪到底，坚持每天的安全日例会，坚持每周的安全分析，坚持把每件事每天都做好，是最难的。

4.2 安全检测为什么会失效

单点检测和防御，和企业内规模化检测和防御，这是两个概念，很多单点检测和防御很有效，但在企业内上了规模后就会出现安全检测失效的问题，严重的甚至导致无法推广和部署，最终不得不取消。实践中如果某次安全攻击没有检测到，是非常好的提升企业安全运营能力的一次机会，这意味着一定是某个环节弱化导致安全检测失效了。

通过每一次对问题的排查和解决，就可以逐步实现安全运营能力的进步。一般排查的顺序是：单点检测深度不足->覆盖率不足->安全运维平台可用性出了问题->告警质量问题->人的问题。

首先是单点检测手段不足导致，可能是检测的正则表达式写的不好，或者是攻击者使用的方式没有预先考虑到，也可能现有的安全防护框架的安全监测根本就监测不到。针对性的改进提升就可以了。

第二是覆盖率不足导致。出现问题的机器或网络区域就没有部署安全监测产品，即使有监测能力，也会因为没有部署而导致检测失效。比如防病毒客户端安装率和正常率只有80%，那即使针对已知恶意程序，也只有不超过80%的概率能够监测发现。这个问题其实是目前很多企业安全问题的现状，有监测设备和能力，但安全检测失效。更要命的是大家往往不重视这些灰色地带，投入重金和重要精力去测试引入部署那些安全概念产品，防APT、威胁情报、态势感知等等，其实这几样哪能离得开那些安全监测设备呢？所以这个问题的根本解决方案，就是把部署率、正常率提升上去。关于企业安全灰色地带，有几个值得关注的地方：

（1）无人关注的资产，特别是互联网资产。漏洞通报平台报出的很多安全漏洞，得到的企业回复很多是：这是一台（测试/即将下线/无人使用/外包人员使用……）的设备，我们已关闭。这些资产除了服务器，还分配了的互联网IP、域名，不在安全监测里的系统和应用；

（2）开放在互联网上的管理后台、高危端口、文件上传点；

（3）各种已被爆漏洞的第三方应用；

（4）弱口令，包括系统弱口令、应用弱口令、用户弱口令等各种弱口令，如果解决好了口令的问题，保守估计可以解决企业50%的安全问题。

第三是安全运维平台可用性出了问题，在前面介绍了SIEM健康度监控的问题，这块也是安全检测失效的重要原因之一。

第四是告警质量的问题。SOC被诟病最多的是采集了大量数据，但往往不能判断哪些是真正需要关注的告警。告警有效性较低，导致大量需要人工确认，管理成本太高。安全检测规则的设计不足导致告警数量太多，从而导致安全运营人员选择性的忽略。

第五是人的问题。机制流程也可以理解为是人的问题。如果前述原因排除，还是有安全检测失效的问题，那应归结于人的问题。比如人的责任心问题，快到下班时间了，匆匆把告警确认关闭敷衍了事；或者人的安全技能不足，不能有效调查判断实际安全问题。

4.3 白名单还是黑名单

目前绝大多数安全防护措施、安全检测规则，无论吹的多高大上，基本都还是基于黑名单原则，满足黑名单规则的给出告警。黑名单的优点显而易见，假阳性较低，认知理解容易，缺点是漏报率高，能不能检测到安全威胁，很大程度上需要靠概率和运气。

如果从安全有效性角度出发，白名单可能会越来越受到重视。白名单的缺点是假阳性较高，运营成本高，所以需要安全检测具有自学习能力（姑且称为人工智能），形成自动或半自动可收敛的安全检测规则。这块希望能尽快有成熟的商业产品，解决企业的痛点。

4.4需要什么样的安全和安全运营

企业需要什么样的安全和安全运营？适合自己的就是最好的，或者说投入和收益比最大的就是最好的。企业的安全投入跟公司的规模和盈利能力相关，公司规模大，盈利能力强，处于发展期时，预算和人员编制都会增加，业务停滞时安全做的再好也不会追加投入。因为在甲方，安全不是主营业务，信息技术部门已经是公司的中后台职能型部门，安全团队是信息技术部门中的中后台，谓之后台中的后台。所以：

适合自己就是最好的。

聂君

企业安全建设有个阶段论：

第一阶段：如果基本的安全体系尚不完备，处于救火阶段或者安全体系化建设捉襟见肘，APT攻击可以先放一边不管，先把安全中需要快速止血的工作做好，这就是基础安全工作，这部分工作远没有高大上，但却是最基础最有用的“保命”工作，不需要太多额外投入就可以规避80%的安全问题，让企业有一个最基础的安全保障。

第二阶段：系统建设阶段，建设各种安全监测防护手段，以及各类安全规范和安全流程，一般采用27001体系+商业解决方案+少量自研可以实现。

第三阶段是安全高阶建设，这阶段基本商业产品很难满足企业安全需求了，以自我研发和自动化智能化为特征，核心还是以解决企业遇到的安全问题，解决实际安全问题为目标。能进入这个阶段的企业不多，但基本代表了该行业的未来发展方向。

类似软件能力成熟度模型CMMI，安全运营也有个成熟度问题：

（1）一级：自发级。部署了一些较为基础的安全措施和管控，单点防御投入了较多人力财力，比较依赖于厂商，对于企业安全没有整体把控。 

（2）二级：基础级。具有安全运营的理念并付诸行动，建立了较为完善的安全防护体系，并通过安全运营保障安全有效性，具有攻防能力的个人或团队，能够解决实际安全问题。

（3）三级：自动化级。具有自动化监测、响应、处理甚至反击能力，对企业自身安全现状和能力具有全局掌控力，具有入侵感知能力，能进行一定级别的攻防对抗。

（4）四级：智能级。采用了白名单的安全防护原则，具有真正意义的智能安全检测，能够对偏离正常行为模式的行为进行识别。

（5）五级：天网级。天网恢恢疏而不漏，让所有恶意行为无所遁形。这级别的安全，出于一个理想状态，目前为止还没有真实案例。

无论怎样，金融企业还是要坚持适合自己就是最好的原则。如果需求是一辆自行车，结果来了一辆专机，结果也未必一定好。

5 结语

我一直在企业安全建设中提倡安全运营，确保安全有效性，并在君哥的体历公众号中发表了三篇安全运营建设之路的文章。最近欣闻不少银行总行纷纷建立了安全运营团队，规模都在30+以上，虽和互联网大厂还有很大差距，但相比过去已经是非常之大手笔。相信很多大行，股份制行，城商行，证券公司都会跟进，安全运营是企业安全建设实际落地的必由之路。安全运营，无论是体系方法论，还是工具产品，还在快速发展完善中，有志于此的读者可以重点关注。

目前制约安全运营发展的最大因素有两点，一是没有特别好的商业化工具，能够结合企业内部的流程和人员，提高安全运营效率。据我所知，很多安全乙方准备在此领域发力。二是一万个安全负责人心中有一万个安全运营，打法思路各异，没有形成统一的安全运营标准。笔者和两位志同道合的朋友正在从事这方面的开源工作，欢迎加入我们。

《中国信息安全》安全运营专题下载：

链接:https://pan.baidu.com/s/1SS7OdDHt433n8glbDDRt3w  密码:zgrk

联系方式：   

邮箱：[email protected]       

Github：https://github.com/jun1010/secbuild        

微信公众号：君哥的体历（jungedetili）

知识星球：金融企业安全建设实践

 

部分观点和内容参考以下文章，表示感谢。
1.《我所理解的安全运营》，职业欠钱

附注：

• 聂君，信息安全从业人员，安全运营提升安全有效性，建设企业安全最后一公里的身体力行者。好读书，不求甚解。性格开朗，爱好足球。

• 本公众号是个人对工作生活的一些体验和经历分享，站在不同角度和立场解读会有偏差，见仁见智，不求正确统一，但求真、善、美。