【君哥的体历】聂君：我们谈安全运营时在谈什么？

                                                                        一、关于安全运营的若干定义

谈及网络安全无可避免地要提及安全运营，那么究竟什么才是安全运营呢？聂君下了一个定义：一切围绕着提升安全能力开展的工作都属于安全运营。

事实上，安全运营和安全建设是对应的，安全建设仅仅是一个开始，只有运营才能有效提升企业安全防御效果。

判断甲乙方谈安全运营是否在线，一是看是否关注覆盖率、正常率两个指标，脱离这两个指标的安全措施很多都是在“耍流氓”。判断一家企业安全是否务实，就看其安全措施的覆盖率和正常率是否达到较高的水位。

二看是否有验证思路，能否在一定时间内主动发现安全措施失效。这是决定企业安全运营水平的关键点，我们日常事件复盘中就发现大量的安全检测事项都是通过安全验证来发现的。

目前企业做安全运营普遍还停留在两个阶段：一是建设安全大数据平台。这个平台可以解决两类需求，即实时计算和规则匹配的应用性问题，以及历史数据查询和模型计算的性能问题。

二是异常检测规则（UseCase）。无论是在检测规则还是安全场景中，大家在这方面依旧处于经验积累阶段，特别是根据一些新兴检测技术的发展，研究出可运营的检测规则。另外对于检测规则的制定和上线流程的标准化、可运营等研究也是一个热点方向。

目前制约安全运营发展的最大因素有两点，一是没有特别好的商业化工具，能够结合企业内部的流程和人员，提高安全运营效率。二是一万个安全负责人心中有一万个安全运营，打法思路各异，没有形成统一的安全运营标准。

                                                                          二、安全运营的框架

安全运营的框架是其核心问题，目前我们的组织架构、团队职责、人员的技能工具和流程建设都是按照这个框架来建设的。

安全运营整体框架可分为几个小框架，分别是安全防护框架、安全运维框架、安全验证框架和安全度量框架。

安全防护框架的目的是尽可能多的部署有效的安全感知器Sensor，这些安全感知器构成了信息安全的一个天网。这部分是最基础的工作，也是传统安全的主战场，需要历经多年的持续投入、积累。安全Sensor的部署应遵循纵深防御的理念，安全Sensor会产生大量的监测日志，作为安全运维框架的输入。

安全运维框架落地时企业一般会部署像SIEM安全大数据平台或类似平台，来实现安全检测信息的统一采集，分析、处理和存储，并通过两种方式进行异常检测告警。

第1种是异常检测规则。这种检测方式的优点显而易见，基于白名单、黑白名单的规则快速有效，但有一个很大的缺陷，完全基于防守方的经验，这就要求防守方要了解各种攻击手法，并且提炼出异常的检测特征，部署到Sensor安全感知器上。

第2种是基于算法分析。这类方法分析者不需要了解攻击手法，而是以特定的算法分析出最有可能是异常的top10、top100，然后再交由二线专家进行分析，判定是否异常。

安全运维框架还有很重要的一部分，是安全事件的流程化处理和定期的review汇报。安全事件的流程化处理应遵循企业的事件管理流程，然后通过自动化来下发安全的工单，发送告警的邮件、短信等方式进行安全提醒。

安全事件的确认和溯源分析，主要通过人工方式来进行分析和确认，对于百分百确定是异常的安全攻击，通过自动化的方式来进行阻断。同时通过安全事件日例会、周报、月报、年报等方式进行闭环管理，并进行必要的管理层汇报。

安全验证框架是指建立自动化的验证平台，对安全防护框架的管控措施实现百分百的全面验证，并可视化的集成到安全运维平台中，管理措施失效，能够在24小时内发现房屋框架作为运维框架的输入，预留框架处置防护框架的日志、安全验证框架来发现防护和运维框架的失效点。

理论上来说这是一套自洽的体系。我们再通过安全度量框架来衡量评价上述三个框架的水平，纵向和自己比，横向和同行业比，了解自己所处的水位。

                                                                                三、安全运营的工具

安全运营的工具主要分为三大类。

第一类是各类Sensor。企业安全建设中我们需要通过安全防护框架来建设一系列的安全Sensor感知器，才能具备较强的安全监测能力。所以安全运营建设不能代替安全防护建设，该部署的安全系统安全设备是需要的。

从早期的防病毒防火墙、IDS到基于流量检测的NTA，主机的HIDS、安全DNS再到威胁情报等，安全监测的Sensor类型不断扩大。

除了这些安全设备之外，各类被保护对象的应用日志也是非常好的Sensor感知器，比如说AD日志、邮件日志、堡垒机日志，甚至是门禁日志，EDR日志等都非常有用的。应用日志配上简单的规则就能发现非常多的异常，但要求日志本身记录的完备性。

第二类工具是分析平台。分析平台一般包括两类，第一类平台是实时计算和规则匹配的平台，这类平台的技术关键点是两个：第一是支持的日志类型，支持的类型比较多，我们在采集日志的时候就不需要做太多的日志政策化匹配；第二是制定异常检测规则是否方便。

第二类平台是历史数据查询和模型计算的平台，基本上都是基于各类的开源大数据平台。

第3类工具是标准化的流程工具。主要是一些安全基础平台，比如说事件管理平台、漏洞管理平台、安全资产管理平台等，这些标准化的流程工具能够让你的安全处置效率成倍增加，也是非常关键的。

                                                                                 四、安全运营的关键点

第一个关键点，SOP。

企业一般会在安全运营中设置一线、二线来进行安全事件的分级处置，好处是让一线技术人员专注于事件处置，二线专家专注于高级威胁分析。

一线大部分是安全技能较基础的员工，他们要依赖于良好的SOP来工作，高质量SOP是一线发挥作用的基础。

如现在很热门的SOAR，其实是根据不同的条件选择不同的处置，一步步实现告警的自动化或半自动化的处置。SOAR的前提是SOP，只有制定了足够多、足够细的SOP，才能够有希望实现SOAR。

在日常的安全事件和红蓝对抗中，我们要不断地发现SOP的缺陷，不断地进行优化。目前我们在实际中大概开发了几百个这样的SOP。

第2个关键点，有效性验证（穿透性检测）。有效性验证在安全运营中是非常关键的，主要是验证以下四个有效点：

① 验证安全Sensor安全监测功能是否有效；

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

③ 验证SIEM平台的安全检测规则是否有效；

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

实际工作中我们对有效性验证的印象非常深刻，因为这4类失效点我们都遇到过，复盘的时候能发现基本上业就是这4类失效原因。

第3个关键点，矩阵式监控。矩阵式监控是发现监控盲区的一个方法。企业会有很多的安全监测措施，我们可以通过自动化脚本在被监测设备上产生一个横向结果，然后在安全检测设备上再产生纵向结果，最后将横向结果和纵向结果进行比对。

如果横向和纵向两个结果都是Fault，说明监控项缺失，需要立即整改；如果横向和纵向结果中有一个是Fault，一个是OK，则说明其中某个结果有问题，可能是程序问题或者网络不通等原因；如果横向和纵向结果均为OK，则说明此项监控已配置，并工作正常；如果横向和纵向结果均为N/A，表示此项不适用。

在实际工作中，我们将矩阵式监控的日报和日常值班检查的监控界面进行了集成，将这种不合规的项目在监控界面上进行图形化的展示，每天值班人员进行检查，并在值班记录里面登记详细的情况。

第2天安全事件的晨会上去review值班记录，团队负责人来督导这些不合规项的整改。如果没有及时整改，以后每天都会在可视化监控平台中持续review和跟踪，确保整改到位。

通过矩阵式监控的实施和长期运营，目前除了一些PC终端偶尔出现服务停止等不稳定因素以外，监控的覆盖率接近百分百。此外，资产清单的准确性也大大提升，我们不再单纯的依赖人的责任心和运气，而是通过资产缺失的自动发现机制来督促员工及时更新资产。

五、安全运营之红蓝对抗

回顾2019，网络安全行业有一件事是值得记录的，那就是HW行动。它解决了安全工作中长期存在的两个问题。

1.安全是隐性的而非显性。因为攻击方不会到处宣扬攻击事实，很多时候不一定知道自己被攻击了，所以安全有时不能及时知晓损失的结果。

2.安全是低频不是高频。即便是在金融机构一两年内也很难发现一起有组织持续时间较长，且针对特定目标的攻击，更不用说是高级手法。

HW行动则有效将安全从隐性变成了显性，低频变成了高频。我们2012年就组建了攻击力量，对内网系统进行渗透攻击，经过不断的对抗，防守方很快就提升了攻防对抗的成功率和检出率。

受益于这种多方的共同努力，现在领导真的重视安全，给人、给预算、给政策支持，甚至和安全团队一起制定规划，督促执行。

不论是HW红蓝对抗还是安全运营，哪怕是安全意识培训都在谈实战化。近年来甲方的实战化安全项目逐渐增多，这也是甲方安全企业转向真正务实的安全工作的方向标。

所以对于红蓝对抗这种安全形式，能找到安全问题，还能强有力的推进安全工作，建议企业有条件的赶紧上。

顺便在这里展望一下2020年的安全工作。我觉得有两点，一是甲方安全团队的组织结构会发生剧烈的变化，不少股份银行纷纷扩大安全人员编制，这种变化是企业为适应整个网络安全大环境变化下的主动变化。

未来将会有越来越多的银行以及其他企业跟进。原有的安全团队能力和事业格局能否承受这种变化，并迅速响应高级管理层的需求，从而在剧烈的变化中站稳脚跟是需要早做准备的。

二是安全“黑天鹅”事件会越来越多。不管你做了一个多么详细的安全规划，安全运营中做了多少工作，依旧难以避免安全事件发生，所以安全往往是事件性的，也很难用一个单一的事件指标来衡量安全做得好还是不好。

                                                                               六、安全运营的度量指标

安全度量框架主要用于衡量、评价安全的有效性，如果一项工作不能够测量，它就很难提高。安全度量可以分为几个维度。

1.技术维度。包括防病毒的安装率、正常率、安全事件的响应时长、处理时长、完成一次高危预警漏洞排查所需的时间和完全修复的时间等。

2.安全运营的成效。包括覆盖率、检出率、攻防、对抗、成功率等，了解企业有多少业务和系统处于安全保护之下，有多少无人问津的灰色地带。

3.安全满意度和安全价值。安全满意度和安全价值反映了安全对业务的支撑能力，即用多少资源来支撑了多少业务，以及在内部的影响力和安全对业务的影响力。这对安全的团队和安全负责人提出了很高的要求。

七、安全运营的复盘标准

每次攻防对抗后的复盘总结，我们都会获得相应的锻炼和提升。我们也总结了一套这个复盘的标准。

1.确保同样的问题不再重复，比如把规划演习里发现了单个的漏洞补好，把控制台架构中发现的弱口令改好，确保同样的问题不再重复。

2.确保同类的问题不再发生。比如怎么将所有硬件设备需要内置的弱口令进行检测并解决；比如怎么去处理并解决某次发现的某个这种应用账户权限，以及所有应用系统中账户权限的滥用问题。

3.为了实现以上的两个目标，我们需要从人、技术、流程、资源4个维度举一反三并且上挖三代。

4.坚持复盘来提升每个单点的检测率。

很多问题看起来是技术问题，其实是管理问题,最后还是死在了技术不过硬的问题上。

为什么我们要坚持复盘，提升每个单点检测率？

最近ATT&CK框架研究的人很多，我也仔细看了官网有关的材料。绕过单一TTP检测和绕过整体ATT&CK框架是完全不同的，这是个常见误区。串联系统的可靠性的概率计算大家都知道，一次成功的红队行动往往至少需要几十个环节，如果每个环节有2%的概率被检出，那每个环节的可靠性98%。10个步骤之后，可靠性降为81.7%，意味着有19.3%的概率被检出，20个步骤之后，可靠性降为66.7%，有33.3%会失败。即使中间存在几个环节能100%绕过，并不会显著提高行动成功的概率，att&ck的作用就是提高每个环节的检出概率，并不需要全覆盖。

只要坚持提高每个环节的检出率，就能大幅降低红队行动的成功概率。假设检出率提高到5%，20个环节后，可靠性概率降低到35.8%，64.2%的概率红队会失败。同样地，即使中间存在几个环节能100%绕过，并不会显著提高行动成功的概率。

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

聂君

这说明了单点检测和系统性检测的巨大区别。并为我们指明了安全防护建设的方向，不断优化提升每个检测点的可靠性或者说检出率，进而最终大幅度降低红队行动的成功概率。

问答环节

1：安全运营的前提条件是什么？或者具备什么基础后，在开始做安全运营比较好？

假如企业人数和规模不大，或者说企业服务器、终端数量较少时，其实不太需要运营。因此，我认为企业的规模是安全运营的第一个前提条件。第二个前提条件是企业已经做好了网络安全系统防护建设的前期工作。

需要具备的基础是一些基础设施条件，比如安全资产管理平台，IP业务系统、负责人、事件管理平台等，这个过程是可以相辅相成的。

2：有没有比较有特点的soc安全预警模型分享呢？

我理解的现在大部分检测发现异常主要有两类：一是黑白名单规则，二是算法。黑白名单规则使用的最多，基本达到99%，少数的安全厂商会有一些依靠算法的安全模型。所以实话实说没有什么好的soc安全预警模型。

3：AI现在运用在安全运营里多吗，可否举例说明怎么运用的？

据我了解，目前通过AI来进行安全运营的比较少，可能是我了解的不够多。

4：地方商业银行和中小银行的安全工作应该怎样去做安全运营入？毕竟没有大行的资源和技术实力。

其实很多的地方银行和中小银行无论是资产规模还是服务器终端的数量，应该都属于比较大的，而且经过了长时间的规范化建设，都具备了良好的安全运营基础。

实际上它们真正缺的应该是人和资金投入。缺人的问题可以通过外包来解决，我09年开始做运营的时候只投入了0.5个人来做安全运营，慢慢运营出效果后再适当引入一些外包和厂商资源。

5：企业的业务放在非私有云上，安全建设和运营框架、工具有不一样吗？

企业业务放在公有云和私有云上面差别还挺大的，因为公有云上面的日志信息拿回来是很困难的，大部分依赖公有云底层的安全Sensor感知器和公有云的SOC来运营，能做的事情比较少。

6：安全运营人员能力提升路线图这一块有什么好的建议吗？

对于安全运营人员来讲，第一个关键点就是持续改进优化或者叫对安全风险的感知能力。当你获得一个信息时能够敏锐地判断其中蕴含的风险，以及背后可能存在的安全问题，再通过事件分析来找到其中存在缺失或者执行不到位的地方，并能够举一反三持续优化改进。这样的能力非常关键。

第二点是结果导向。安全运营最终必须对结果负责。如果安全运营不成功是没有任何借口可找的，而是要积极分析不成功的原因有哪些，如员工缺乏安全意识、系统管理员犯错误或者是安全策略执行不到位等。

此外，安全运营人员还应具备以下能力：技能需求、数据意识、关键指标。

技能需求

拥有安全知识背景，能够比较好的理解安全场景和需要解决的问题；

拥有研发、运维相关的背景知识，知道某一类问题的合理解决方案；

拥有较好的沟通能力，可以在安全工程师、安全开发工程师、业务RD/SRE之间搭建沟通的桥梁；

拥有一定的项目管理能力，较好的责任心，确保已知问题能够得到闭环的解决，涉及到跨团队的沟通，还需要有一定的大公司跨团队协作的基本经验；

具备数据意识，可以提出数据埋点、统计诉求，并细心的将已发生的事件积累成数据素材，形成日常观测的指标（针对可用性、覆盖率、效果指标等）

数据意识

历史上总共发生了多少次有记录的入侵事件？

每一次入侵事件的发现与否，不同时期的主动发现率比例是多少？

每一次无法发现的根本原因定性是什么样的？

已知原因解决的情况如何？

举一反三之后，如何陈述公司面对入侵的主动发现能力?比如我们可以罗列出多少种攻击手法，能够发现其中的多少种？不能发现的部分什么时候能够解决，承诺的发现能力在多少覆盖范围内是有效的？

关键指标

HIDS覆盖率（全部组件健康工作）曲线图

主动发现率曲线图

已知攻击场景覆盖率

误报工单收敛曲线图

每一次入侵响应时间曲线图

为了发现入侵相关的基础数据完整度

每一个策略模型的可用

-----出自赵弼政《我所理解的安全运营》

7、安全云必须要有SOC或者SIEM平台吗？

其实平台叫什么无所谓，但是一定要有一个集中化的平台，能够把各个Sensor感知器产生的日志统一集中起来。

因为很多时候系统安全管理员是没有人进行监督的，那么事情能不能做好很大程度上依赖于员工个人的技能和责任心。所以在这样的情况下，企业如果没有集中化的统一平台，那么安全就只能靠运气了。

因此我的建议是，一定要有一个集中化的平台。

8：资产梳理，太多维度了，要怎么覆盖全面。涉及业务，数据，应用，主机，网络，访问控制等，要怎么有个网络安全的信息资产的全面地图？

建设S-CMDB来加强安全资产管理。其数据来自于五部分：

1.CMDB。基础信息如IP、所属系统、负责人等需要从CMDB中同步过来，但要注意这些数据可能不全、不准、更新不及时。

2.主机上数据。比如HIDS就是很重要的安全数据来源，可以让安全团队很快的获得服务器资产上安装的软件、中间件和版本、补丁安装情况等。当出现1day进行漏洞应急时，这部分数据就特别有用，能让安全团队的响应和排查时间缩短在分钟级别。

3.流量。通过流量**，能否发现很多安全资产属性信息，比如未登记的IP、管理后台等。

4.扫描。通过扫描，能发现未登记的资产信息，以及资产的漏洞信息等。

5.人工添加。比如每次应急时，将发现的未知资产和资产属性信息不准确的人工更新到S-CMDB中。

需要重点关注哪些安全资产信息？

1.按资产所属纬度梳理：互联网资产、分支机构资产、子公司资产、外联公司资产、公有云资产、开发商、外包商。

容易忽视的有：公有云资产。因为有的业务部门和分支机构公有云申请都不经过IT部门，上面却放了大量业务数据。

开发商/外包商的资产。开发商/外包商一般给甲方外包开发信息系统，开发商/外包商公司内部也会自建Git/SVN等源代码管理服务器，存有已经交付给甲方的信息系统源码，而开发商/外包商的源码系统管理安全能力和甲方相比可能就差几个量级了。后果就是：通过获得的源码，发现系统应用0day，从而控制甲方已上线信息系统。

2.按资产属性梳理

特别关注资产的安全属性：中间件或框架（版本）、开放在公网API接口（特别是未下线的老接口、有用户名和密码认证的接口、有敏感信息的接口）、管理后台开放在公网、高危功能（文件上传点、短信验证码、重置密码、文件下载）、远程接入点（***）、特权账户（应用管理特权账户、应用连接账户、系统管理特权账户、可以修改账户权限的账户、备份账户、高管层账户）、网页回显信息含内部IP地址或敏感信息等。

3.资产梳理中容易忽视的点

（1）所有内部文档服务器上（含OA、邮件系统、jira、wiki、知识库等）敏感信息清理或限制访问权限，不要有：网络拓扑、安全防护方案和部署位置、各类密码；

（2）资产管理平台上，蜜罐不要叫蜜罐、安全设备IP要隐藏；

（3）各类口令：弱口令、默认口令、已泄露口令。

4.其他关注点

甲方安全关注的其他技术点还包括：数据安全、终端安全、SDL、服务器安全、邮件安全、上云风险和控制、API接口管控等。每个技术点都值得展开细细讲，留在以后的交流分享中。

总结

一个半小时的直播很快就接近了尾声，听众们却意犹未尽，原定一个小时的直播时间不出意外超出了一半。总的来说，本次整个直播过程十分流畅，这很大程度上依赖于君哥的精心准备，在对安全运营进行讲解时不仅有大量的干货输出，还有相对应的实际案例分享，既容易理解也有很强的可操作性。

最后，向仍然奋战在疫情一线的医护、军队、志愿者等勇士们致敬！-----在直播开始时，君哥首先向参与抗疫一线的医生护士们致以最高敬意。