Question

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

1.难点

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

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

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

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

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

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

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

2.安全检测为什么会失效

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

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

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

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

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

·开放在互联网上的管理后台、高危端口、文件上传点。

·各种已被暴出漏洞的第三方应用。

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

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

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

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

3.白名单还是黑名单

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

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

4.需要什么样的安全和安全运营

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

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

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

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

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

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

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

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

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

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

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

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