【君哥的体历】金融业企业安全建设之路

QCon北京2017全球软件开发大会于2017年4月16日到18日在北京国家会议中心举行，QCon是由InfoQ主办的全球顶级技术盛会,每年在伦敦、北京、东京、纽约、圣保罗、上海、旧金山召开。自2007年3月份首次举办以来,已经有超万名高级技术人员参加过QCon大会，QCon内容源于实践，以下是本次发言整理内容。

尊敬的各位来宾、同仁，下午好，我是聂君，很荣幸能有机会和大家分享企业安全建设这个话题。安全领域众多，对企业安全团队负责人而言，需要关注企业安全最后一公里的问题。互联网公司安全建设为什么能一定程度引领行业发展，主要还是因为从解决实际问题出发。今天的话题分享，偏重于安全有效性和实践，没有高大上的话题，却是解决企业安全问题过程中会实际遇到的。

一、安全观安全

今天分享讨论的内容包括三个方面，安全观安全，安全运营建设和企业安全建设的一些思考。对安全运营的难点，安全合规、安全考核等问题做一些探讨。受限于本人自身的从业经历和所处行业，可能不具有普遍代表性，希望能给有需要的同仁一些参考帮助。

安全人员最重要的一点是安全问题解决的思路，以及看待安全问题的角度和高度，而不是掌握多少漏洞，拿下多少权限，这就是安全人员的安全观。

（一）安全本质

吴瀚清先生说：互联网本来是安全的，自从有了研究安全的人，就变得不安全了。SQL注入攻击自1999年首次出现后就成为互联网安全的头号大敌，注入攻击的本质是把用户输入的数据当做代码执行，开发人员设计的正常功能被恶意的人滥用。再比如，钓鱼网站已成为很多金融机构的首要安全威胁，而在2011年以前，很多金融机构的安全人员甚至都没有考虑过这个问题。时至今日，都会觉得很无辜，企业的网站没有安全漏洞，是钓鱼网站的狡猾和用户的“傻”才会让犯罪分子有机可乘。

上面两个例子中，开发人员信任用户输入，用户信任钓鱼网站，导致安全问题。个人认为，安全问题的本质是“信任”的问题。计算机用0和1定义整个世界，而企业的信息安全问题是解决0和1之间的广大灰度数据，运用各种措施，将灰度数据识别为0（不值得信任），或1（值得信任）。信任是安全问题的本源。不同的信任假设决定了安全方案的复杂程度和实施成本，安全需要平衡。

（二）安全原则

安全观安全的第二个话题是安全原则，个人认为有三点，持续改进、纵深防御、非对称。

（1） 持续改进。如何让一台服务器不被不明武装分子攻陷，有没有一个类似“照妖镜”的工具，一旦安装上就可以高枕无忧，让恶意的攻击者无所遁形，有没有一个万能的“上帝之手”，帮我们干掉所有安全问题？很遗憾，没有。在解决安全问题的过程中，不可能一劳永逸。很多安全厂商在推销自己的安全产品时，会吹的天花乱坠，似乎无所不能，从早期的防火墙、防病毒，入侵检测，到现在的态势感知、威胁情报，智能分析，安全防御技术本身并没有革命性变化，一套入侵检测技术包装个名词，能从IDS到IPS、SIEM，再到现在的威胁情报，本质上还是开发检测规则，异常模式识别。安全产品、安全技术需要不断的随着攻击手段的发展而升级，也需要有人来运营，否则安全就是稻草人，在变化的攻击手段前不堪一击。

（2） 纵深防御。典型入侵案例场景中，攻击者利用Web应用漏洞，获得低权限WebShell，然后通过低权限的WebShell上传更多文件，并尝试执行更高权限的系统命令，进一步在服务器上提权，并进一步横向渗透，获得更多内网权限。这个典型的攻击路径中，在任何一个环节设置有效的安全检测和防御措施，攻击都可能被检测和阻止。目前在安全防护技术没有革命性发展的情况下，坚持纵深防御原则，从网络层、虚拟层、系统层、应用层，到数据层、用户层、业务层、总控层，进行层层防御，共同组成整个防御体系。

（3） 非对称。对于攻击者来说，只要能够找到企业系统的一个弱点，就可以达到入侵系统的目的，而对于企业信息安全人员来说，必须找到系统的所有弱点，不能有遗漏，不能有滞后，才能保证系统不会出现问题。这种非对称导致攻击者和安全人员的思维方式不同，也是企业信息安全工作难做的根本原因，破坏比建设要容易，怎么扭转这种劣势呢？安全防护人员也需要非对称思维。解放军在和美帝对抗中发明了反介入战略，发展各类型导弹，特别是反舰弹道导弹，阻止美国航空母舰进入第一岛链，如果在国力不够的情况下，解放军耗尽国力，拼命造航空母舰和美帝对抗，搞军备竞赛，可能就落得苏联解体的下场了。发展哪些非对称的安全防护武器呢？各种“蜜”的产品应用而生了，蜜网站、蜜域名、蜜数据库、蜜表、蜜字段、蜜数据、蜜文件，在面对攻击时进行安全反制，恶意攻击者很难全身而退。据我所知，很多企业已经进行了商业化大规模部署并在实际对抗中取得不错的效果，这应该是未来安全防护发展的一个有益方向。

（三）安全世界观

我的安全世界观总结一段话是：信息安全就是博弈和对抗，是一场人与人之间的战争。交战双方所争夺的都是信息资产的控制权，也就是在博弈和对抗中，牢牢的把控住各类信息资产的控制权。

（四）正确处理几个关系

企业安全建设过程中需要正确处理几个关系：

（1） 科学与技术。科学讲究严谨，艺术讲究美。安全既是一门科学，也是一门艺术。安全的科学性体现在安全工作无论安全体系还是具体安全措施落地都是严谨和严肃的，在企业安全建设中，有的开发和运维同事觉得在内网就安全了，已经拒敌于国门外了，从而放松了安全要求，实际中攻击者通过一些边缘攻击进入内网，从而进一步渗透入内部服务器的案例比比皆是。安全的艺术性体现在安全工作的权变，不是所有情况都适用同样的安全要求，需要不断的权衡利弊，选择当前情况下的最优。比如服务器安全基线根据所处安全域不同有不同的基线标准，漏洞跟踪处理时，安全部门通过补偿措施降低风险，从而允许一些业务系统带病上线，这都是权变的体现。

（2） 管理与技术。安全管理与安全技术孰轻孰重？有的企业拼命搞ISO27001安全体系，发布各种安全制度政策，上各种安全流程控制，做各种安全审计和检查，搞得民怨沸腾，往往效果也不好。从事漏洞挖掘和攻防的人会觉得搞安全管理的人太虚，这也不会，那也不会，每天就是搞体系制度流程，能挡住我一个0day吗？会挖洞和写PoC吗？安全管理和技术更像是灯芯与灯油的关系，谁也离不开谁。安全政策和流程没有技术和自动化手段保障，无法有效落地，管理10台和10000台服务器的安全性，安全政策和流程肯定不能是一样的。在企业安全建设中，技术很多时候不是困难，至少不是最重要的点，而是需要不断的去说服影响开发运维和业务部门同事，如果技术人员能跳出技术思维，站在更高层面去思考安全问题解决方案，我相信安全人员的境界就提高了好几层。

（3） 业务与安全。这个关系话题非常有意思。刚工作时我认为安全是为业务服务的，但安全会一定程度阻碍业务发展。随着认识加深，我的认知发生一些变化，安全是为业务服务的，安全更是业务的属性之一。不安全或没有安全考虑的业务就像不合格的次品一样，终究是要被市场淘汰的。本质上，安全是一项服务，安全服务是安全团队提供给用户和客户的一种服务类别，如果安全方案和安全要求设计时没有最大化这种服务的价值，那么在充分竞争的情况下，安全团队是要被市场淘汰的。我经常问自己和团队，如果公司不是只有我们一个安全团队，我们安全团队在公司这个范围内不是垄断的，而是有其他安全团队也提供安全服务，在共同竞争的情况下，我们提供的安全服务还能被用户认可买单吗？我们传统中认为安全总是这也不能做，那也要控制，安全就是拖业务的后腿，安全总是降低业务发展效率，在企业中安全通常做成的就是这个样子。造成这种现状，企业安全主管首先要反思。这是因为安全团队设计安全方案和要求时，不是以业务和服务出发点，而是以安全团队省时省事，尽量少承担责任为出发点。后者设计出的安全方案当然是阻碍业务发展、降低效率。如果一套安全方案和要求，能够在少降低甚至不降低业务发展的情况下，又能保障安全，业务团队，开发运维当然是欢迎的，谁愿意冒着巨大的风险强行上线新的业务呢。如果安全团队能和业务、开发运维一道剖析，站对方立场设计方案和执行要求，用户从心里是认可安全团队和安全服务的。实际中，我遇到很多这种情况，坚持安全服务的做法，会让安全团队之路走的更为顺畅。

二、安全运营之路

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

（一）企业安全需求

金融行业是牌照行业，接受严格的监管，典型特征是业务的持续稳健发展需要安全保障，有专职的安全团队和安全人员，每年安全预算和投入有保障且逐年增加。安全需求或者安全目标主要表现为以上几点。

（二）面临的问题

在企业安全需求下，我们面临哪些问题？三个方面。

企业安全的内容是什么？企业安全的全貌是什么？我们拿着显微镜，看看安全管理员每天的工作内容，包括：每天查看各类安全设备和软件是不是正常运行；安全设备和系统的安全告警查看和响应处理如入侵检测、互联网监测、蜜罐系统、防数据泄密系统的日志和告警，各类审计系统如数据库审计、防火墙规则审计，外部第三方漏洞平台信息；处理各类安全检测需求和工单；有分支机构管理职责的还要督促分支机构的安全管理工作；填报各类安全报表和报告;推进各类安全项目；有的还要付出大量精力应对各类安全检查和内外部审计。做过基层安全运维的人对上述场景都会很熟悉，这是企业安全各个场景的缩影，但不是全貌。如果一个企业只有少量人员，服务器和产品，那么上述内容就是企业安全工作的全部。如果是有万台服务器，几百个程序员，数以百计的系统，企业安全除了安全设备部署、漏洞检测和漏洞修复外，还要考虑安全运营的问题，从工作量上看各占一半。

企业部署大量的安全防护设备和措施，在显著提升安全检测能力的同时带来问题，安全设备数量急剧增多，如何解决安全设备有效性的问题？在应对安全设备数量和安全日志告警急剧增多的同时，如何确保安全人员工作质量的稳定输出？安全运营的目标是要尽可能消除人员责任心等因素对安全团队对外提供安全服务质量的影响。举个例子，就像大餐和快餐，大餐靠的是名厨名师的发挥，如果今天这个名厨心情不好或者换个新人，可能做出的产品质量就有非常大的下降。而快餐如肯德基，所有的操作都标准化和流程化，就是初中毕业没学过烹饪，没练过的人经过短期培训和严格管理，也能确保炸出的薯条味道一模一样。快餐的标准化流程和管理几乎完全消除了人的因素，确保对外提供的服务质量能够始终稳定，不会出现大起大落的情况。安全运营的目标就是在企业变大，业务和系统日趋变复杂的情况下，在资源投入保持没有大的变化情况下，尽量确保安全团队的服务质量保持在稳定区间。

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

（三）安全运营的思路

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

为确保安全运营架构能够灵活扩展，建议建设四个框架：安全防护框架、安全运维框架、安全验证框架和安全度量框架。安全防护框架通过部署各类安全感知器，为安全运维框架提供天眼。安全运维框架采集防护框架输入，通过关联分析和数据挖掘处理并统一展示，输出的告警信息自动进入事件处理平台，人工介入。安全验证框架主要功能是综合通过黑盒白盒验证措施，确保安全防护框架和安全运维框架有效性。安全度量框架主要功能是通过一系列安全度量指标，衡量评价安全运营质量水平，并针对性持续过程改进，实现质量的螺旋上升。

安全防护框架的目的是部署尽可能多和有效的安全感知器Sensor，这些安全感知器构成了信息安全的“天网”，这部分是基础工作，也是传统安全的主战场，需要历经多年的持续投入积累。安全Sensor的部署遵循纵深防御的理念。除了上面列的这些以外，实际中还有很多Sensor可以监测，比如企业防火墙多了，如何管理防火墙规则的有效性和合规性，可能需要部署诸如Algosec、firemon等防火墙规则审计工具，审计发现的信息就可以作为安全运维框架的输入，另外如网络层，有些防火墙还自带IPS功能如CheckPoint的SmartDefense，就是特别好用的安全Sensor，还有记录交换机、路由器登录和命令操作日志的ACS信息，堡垒机信息、虚拟层虚拟主机操作信息，主机层的安全客户端信息，KVM、ILO等带外管理系统信息、ITIL系统工单信息、应用层的OA和公文系统应用日志。企业基础安全的很大内容就是建设各类安全Sensor，解决点状的安全问题和需求，自研类的安全Sensor会越来越多。

安全防护框架中要不要做业务安全？这个问题赵彦先生关于企业安全7大领域的分类能较好的回答，这七大领域是①网络安全，②平台和业务安全，③广义的信息安全，④IT风险管理、IT审计&内控，⑤业务持续性管理，⑥安全品牌营销、渠道维护，⑦CXO们的其他需求。对于传统行业，建议做①③④⑤，对于互联网公司，建议做①②⑤，对于金融行业，我建议做①③④，能力强的安全团队，建议做①③④⑥⑦

在军队现代化作战体系中，美军创造性的提出了C4ISR作战指挥系统，即指挥、控制、通信、计算机、情报及监视与侦察。一个完整的安全运维框架包括四个部门：

1：大脑-基础架构平台，要求容量大、速度快，兼容性强；

2：耳目-安全情报、安全监视、侦察系统，主是对安全防护框架的安全信息的收集和处理，实现异常行为的实时安全监测；

3：神经中枢-数据分析系统。综合运用各类智能分析算法和数据挖掘分析技术，实现安全信息处理的自动化和决策方法的科学化；

4：手脚-安全控制系统。实施各类安全控制指令的工具。

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

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

白盒检测（过程验证）是指建立自动化验证平台，对安全防护框架的管控措施实现100%的全面验证，并可视化集成至安全运维平台中，管控措施失效能够在24小时内发现。通过自动化验证平台达到这四点，实际中有个坑要注意：自动化验证要求所有的验证事件必须为自动化模拟真实事件产生，不能使用插入记录的方式产生。安全运维平台应能够监测到安全验证未通过的系统和规则，通知安全人员介入处理。我们在这上面吃过亏。

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

安全度量框架主要用于衡量评价安全有效性，一项工作不能测量衡量，就很难提高。我觉得可以分成几个层次：

首先是技术维度。包括防病毒安装率、正常率，安全事件响应时长、处理时长，高危预警漏洞排查所需时间和完全修复时间。还可以考虑安全运维平台可用性、事件收敛率。合规性方面可以设置合规率、不合规项数量、内外部审计发现数量和严重度等；其次是安全运营成效。包括覆盖率、检出率、攻防对抗成功率。有多少业务和系统处于安全保护之下，有多少无人问津的灰色地带，安全能在企业内部推动的多深入，多快速，这是需要综合技术和软性技能的，成败主要系于安全团队负责人。检出率和攻防对抗成功率都是衡量安全有效性的重要指标，安全不能靠运气和概率活着，持续提升检出率和攻防对抗成功率就是努力的方向。最后是安全满意度和安全价值。安全价值反映在安全对业务支撑的能力，TCO、ROI，安全用多少资源，支撑了多少业务。安全价值还体现在内部的影响力以及对业务的影响力。这是对安全团队和人员的最高要求，既要满足上级领导和业务部门对安全的利益诉求，又要满足同级横向其他IT团队对安全的利益诉求，还要满足团队内部成员的利益诉求，要提供最佳的安全服务，让安全的用户成为安全的客户，让使用者满意，真的是非常有挑战的一件事情

安全如何为业务服务？可以从几个方面来汇报：

减少资损（创收）

降低系统性能压力（降本）

智能预警威胁感知（提效）

同人模型降低安全交付认证复杂度（提升用户体验）

安全应急和危机公关（保持和提升品牌公信力）

积累风险库和模型反驱动业务规则优化（反欺诈、降低坏账等）

比如风控系统做好了，以前需要发验证码的交易，现在不用发了。提升客户体验，验证码费用大幅降低。某行风控系统上线后，动码发送率降低七成。短时间节约几千万费用

安全运营工具包括三部分。SIEM平台或类SIEM平台负责安全信息的统一收集和存储、基于检测规则的异常检测和告警。这类平台的选择有两个重要指标：一是不支持日志格式的快速开发要容易，企业内不可能再保持一个安全开发团队，二是检测规则的制定不能太复杂，要支持所见即所得模式。ITIL平台或类ITIL平台负责接收SIEM平台发送过来的安全事件信息并据此产生ITIL工单，推送到安全运营人员处理和关闭。安全控制自动化工具负责根据SIEM平台下发的安全控制指令进行自动化操作，比如检测发现有外部攻击源，通过下发自动化指令实现防火墙或IPS封禁该攻击源。检测发现某主机有可疑进程，通过安全客户端收集该进程文件样本信息进一步人工分析。安全控制自动化工具目前商业化程度不高。

如果有合适的检测规则，SIEM是个非常强大的工具，可以检测其他安全工具无法捕获的安全事件。通常SIEM的检测规则有三类，第一类是单一检测条件规则。满足单一特定检测条件则触发告警。如服务器主机登录来源非堡垒机地址。满足该条件则告警，该类型规则最简单，主要依靠安全Sensor的监测能力和规则过滤能力。是攻击就一定有异常，关键是怎么总结提炼出异常的特征加以检测。

规则一示例：某个shell进程的cwd和exe组合起来不是/usr/sbin/sshd -> 可疑shell连接

第二类规则是跨平台安全监测信息关联检测，比如防火墙permit日志中有连接威胁情报注入的恶意IP和域名信息。该类型规则能够跨平台进行关联分析，可以衍生出很多脑洞大开的检测规则。比如检测安全违规行为，检测数据泄密和人员可能离职等。这类规则检测效果的好坏取决于两点：一是安全Sensor的类型尽可能多和单个Sensor能监测维度尽可能广；二是规则设计者的检测思维要像攻击者思维一样，脑洞大开，甚至需要一些猥琐。

规则二示例：防火墙Permit日志中Dst包含威胁情报注入的恶意IP或域名->木马等恶意软件？

大部分的安全工具是以孤立方式识别潜在的安全事件，比如不同的IDS检测到同样的告警会分别当做单独事件处理，在SIEM中可以编写规则，根据事件发生的频率触发不同的告警，如果攻击者采取长时间缓慢低频度攻击入侵企业内网，可以编写一条SIEM规则，在较长时间内搜索特定事件，并在该事件范围内发生次数达到某个阈值时告警，比如检测内网DNSTunnle流量，DNSTunnel需要在网络上发送许多DNS数据包，那么制定内网单台机器对同一个域名的查询达到某个阈值（如10分钟内1000个查询）的规则可以有效检测DNSTunnel。检测规则还可以配置为在流量来源与旧模式不同时发出告警，也可以配置为在合法和以往正确的流量突然呈现指数上升或者下降时发出告警。如过去90天内产生一定数量日志的Web服务器突然开始产生于10倍于正常数量的日志。通过SIEM规则，安全团队可以根据流量的标准差制定告警，如达到10个标准差阈值就告警。

规则三示例：内网单台机器对同一个域名的查询达到某个阈值（如10分钟内1000个查询）->DNS Tunnel？

很多攻防案例中，防御方失败的原因主要归结于安全防护失效，其中SIEM平台工具健康度出了问题是比较常见的，比如我们曾经走过的一个坑，有时告警阈值设置不合理频繁告警，SIEM平台会自动禁用规则导致规则无效。这里列了四类安全防护失效的类型，实践中我们都吃过亏。特别值的一提的是安全Sensor的安全性。2013年3月20日下午韩国发生了超过32000台电脑以及部分Atm取款机在同一事件当机的事件，原因是这些计算机使用的韩国防病毒软件安博士的病毒定义更新服务器受到攻击，将恶意软件分发到用户计算机。所以安全Sensor的安全性需要特别关注。几个原则：

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

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

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

有效、高效的安全运营流程与机制是非常非常非常重要的。安全运营流程一般做好两个标准化的流程。

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

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

我们期望的大型安全部门组织架构图应该是这样子：实际工作中安全部门组织架构图是这样子：理想很丰满、现实很骨干，理想和现实总是有差距的。

团队规模方面，互联网公司如腾讯，我特定问了一下腾讯的Coolc总，员工数3万，安全团队规模大约2000，安全团队人员占总员工人数约7%左右，金融行业和这个比例差距还比较大。国内股份制银行总行安全团队规模一般约5-20人，总行IT人员从几百到几千不等。券商普遍安全团队人数在2-5人之间，有的能到7-10人，算是非常多的了。

安全运营的实现肯定离不开组织与人员，安全运营人员建议按1:2:3比例配置，一个安全运营平台运维人员，包括服务器和应用运维，该部分可以交给IT部门的运维团队代为运维。2个安全人员互备，一个负责安全Sensor建设，一个负责安全检测规则和安全二线，事件调查、回顾与汇报、持续改进。3个外包的安全一线，负责7*12事件响应和初步调查确认。股份制银行安全运营人员数量为2-3倍，外包人员还可视事件类型和数量增加。

三、企业安全建设思考

下面分享一些关于企业安全建设的思考。

（一）安全运营的思考

对安全运营的思考有四点。互联网行业的安全建设一定程度引领全行业的发展，是因为人财物资源投入大？还是自由市场竞争充分？我认为最重要的原因是面临解决实际安全问题的压力和需求，采用了最快最有效的解决问题的安全方案。互联网行业做安全的关键词是有效解决实际问题。在2010年以前，我们和国内金融行业同仁交流的时候，做安全的思路普遍还在监管合规+设备部署的阶段。这种局面有其一定的合理性。安全和需求是相匹配的，金融行业是牌照行业，监管合规是安全的首要和最重要需求，安全团队在这个阶段最大化的满足监管合规的目标。同时由于国家对金融业的法律保护等客观因素，金融行业的业务系统面临的风险没有互联网行业高。2010年后，由于网上银行、移动金融的快速发展，以及国内互联网安全环境的进一步恶化，金融行业的安全需求开始发生深刻变化，需要有效解决实际安全问题，对安全运营的需求逐渐增多。那么安全运营的难点，需要什么样的安全和安全运营呢？

我在微信群里经常遇到一个问题，为什么SOC或类SOC的项目容易失败？这个问题等同于安全运营的难点在哪？有三点：

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

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

（3） 难以坚持。这点我纠结很久，讲还是不讲？不过既然是分享，我觉得还是有必要讲出来。我们朴素的愿望总是希望能有一双上帝之手，帮我们解决所有的问题。安全问题，往往都很棘手，安全没有速成，也没有捷径。但凡和运营相关的，其实都不是高大上的事情，往往是和琐碎、棘手、平淡相关，甚至让人沮丧，所以安全运营难以坚持。坚持把每个告警跟踪到底，坚持每天的安全日例会，坚持每周的安全分析，坚持把每件事做好，是最难的。

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

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

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

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

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

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

目前绝大多数安全防护措施、安全检测规则，无论吹的多高大上，基本都还是基于黑名单原则，满足黑名单规则的则告警。黑名单的优点显而易见，假阳性较低，认知理解容易，缺点是漏报率高，能不能检测到安全威胁难听点，需要靠概率和运气。如果从安全有效性角度出发，白名单可能会越来越受到重视。白名单的缺点是假阳性较高，运营成本高，所以需要安全检测具有自学习能力（姑且称为人工智能），形成自动或半自动可收敛的安全检测规则。这块希望能尽快有成熟的商业产品，解决企业的痛点。

企业需要什么样的安全和安全运营？适合自己的就是最好的，或者说投入和收益比最大比。前段时间Google发布了一份安全方面的白皮书，系统的阐述自己安全体系的设计与实现。基本涵盖了所有领域且都是自研，有朋友分析这是企业安全未来发展趋势。那是否所有企业安全都要学习这种模式？世界的精彩就在于，除了李白、杜甫等名家外，唐朝还有2534名诗人，如高适、刘长卿等，世界的多样性才更美。

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

企业安全建设有个阶段论。第一阶段：如果基本的安全体系尚不完备，处于救火阶段或者安全体系化建设捉襟见肘，APT攻击可以先放一边不管，先把安全中需要快速止血的工作做好，这就是基础安全工作，这部分工作远没有高大上，但却是最基础最有用的“保命”工作，不需要太多额外投入就可以规避80%的安全问题，让企业有一个最基础的安全保障。第二阶段是系统建设阶段，建设各种安全监测防护手段，以及各类安全规范和安全流程，一般采用27001体系+商业解决方案+少量自研可以实现。第三阶段是安全高阶建设，这阶段基本商业产品很难满足企业安全需求了，以自我研发和自动化智能化为特征，核心还是以解决企业遇到的安全问题，解决实际安全问题为目标。能进入这个阶段的企业不多，但基本代表了该行业的未来发展方向。

我个人理解安全运营有个成熟度问题，划分标准为：

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

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

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

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

（5）五级：天网级。天网恢恢疏而不漏，让所有恶意行为无所遁形。这级别的安全是什么样，我不知道，没见过。

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

（二）安全趋势

（1） 安全度量

翻译一下就是如何衡量企业安全的效果。做安全的人，遇到的最大的挑战，就是讲不清楚安全的价值。安全这个东西很微妙，不像业务可以用销售额和用户数来衡量，也不像运维可以用可用性指标（比如故障数）来衡量，也不像研发可以用bug数、项目完成率、扩展性、专利等来衡量。安全往往是事件性的，很可能你什么都不做，但一年都不出问题；也可能你花了很大力气，花了很多钱，却还是问题频出。所以我们很难用单一的事件性指标来衡量数据安全做的好还是不好，到最后就变成了拼运气。

企业做安全，最终还是要对结果负责，对于安全效果，有两个指标是最关键的核心指标，一个是漏洞数，一个是安全事件数。这两个关键安全指标，却没有一个安全厂商愿意承诺，他们通常都只愿意承诺卖出设备的功能效果，或者是服务的响应时间。由于漏洞数涉及到企业发现能力的问题，每年第三方漏洞报告平台如乌云上，漏洞数量排前十的大多是互联网公司，但不能因此而认为互联网公司安全能力靠后，相反，由于互联网公司面临安全威胁和自身发现能力（各种SRC虽然是白帽提交的安全漏洞，但可以理解为是自身发现能力提高导致）较强，所以发现的漏洞数量靠前。很多没有爆出安全漏洞的企业不是因为做的有多好，而是自身发现能力不够。在这种情况下，有必要把漏洞数分成两类，一类是通过众测与SRC，获得的外部上报漏洞数量，一类是自身安全防护和检测发现的安全漏洞数。某些金融机构已引入专业的蓝军团队进行攻防，检测红军安全防护和安全检测能力，将是未来安全度量的发展趋势。

（2） 历史问题免疫

运维管理目前事实上的标准是ISO20000服务管理体系，这套体系也叫ITIL运维流程管理，ITIL众多流程中有个核心流程：问题管理。问题管理有个有意思的做法，通过问题管理的思维模式，对企业所有曾经出现过的历史故障进行举一反三的持续改进，从而实现对历史故障免疫。既然安全性要当做可用性来运维，那么安全管理也应该能做到对历史问题免疫，而这也应该会成为安全未来趋势之一。我理解为有两个含义，一是对企业曾经出过的安全漏洞和安全事件做举一反三的彻底整改，从人、技术、流程、资源四个维度分析问题产生根源，查找差距，并建立机制进行防护，从而根本上解决已出现的安全问题，实现历史安全问题免疫。二是对已部署的安全措施的有效性做100%确认，比如已经在服务器上部署了安全客户端，那么就一定要关注客户端安装率、正常率两个指标，这两个指标能做到99.99%的应该算执行力和安全有效性不错的企业了。类似的指标也同样应该在已部署的安全措施中得到确认。第二点其实不能算安全趋势，应该是常识，在各种安全概念层出不穷的今天，希望越来越多的甲乙方能回归常识。

（3） 安全成为属性

越来越多的企业重视信息安全，这种重视可能是主动的，但仍然被动居多，不管怎样，今天的安全人员面对的安全环境越来越恶化，但得到的资源和支持却比任何时候都多，这一点体现在：安全将成为各类系统甚至人才的关键属性之一。举个例子，十年前，很少看到有系统需求阶段就会有安全需求，测试阶段有安全测试，开发人员需要接受专业的安全编码开发规范培训。十年后，这些都很常见自然了，甚至是标配（Default默认）。对安全知识和技能的掌握也从单纯安全人员必备变成了开发人员的必备技能，实际上，安全意识和安全开发能力较强的开发人员薪酬水平和发展空间已高于技能单一的程序员。程序员在用代码改变世界的同时，也有义务更好的保护世界。安全将成为越来越多的系统、企业、个人的属性。

（三）安全合规

国家法律法规、一行三会监管机构的监管要求、特定领域安全标准，如支付卡行业数据安全标准（PCI DSS），行业最佳实践如ISO27001、Cobit等，如何低成本的进行有效合规。从实践中我们总结了一下：一套体系，各路神仙。各个监管要求、标准和行业最佳实践的要求是交叉重叠的，我们起了一个项目，将每份制度、标准和要求分解成元要求，然后进行去重，形成安全合规元要求数据库，把内部的规章制度要求也进行分解，形成内部合规元要求数据库，两者进行比较，差异的部分分成两种，一是有冲突或不合要求的，通过修改内部求进行合规，二是缺失的，落实到已有制度中增加条款或新增制度。内规确保合规后，就要进行检查，检查尽量通过自动化和非现场方式进行。检查发现的问题需要进入到ITIL的问题管理流程进行跟踪整改，发现问题和整改落实情况需计入安全考核。如此则形成完整的合规链。

（四）安全考核

考核话题也比较大，考核的方式、考核指标、考核结果运用等。资源是有限的，如果给干活的人都发一颗钻石，无疑工作又快又好的完成了。在资源受限的情况下，在公司高管层、部门总经理那，安全考核只有一个指标，别出事情，出了事情等着背锅。说白了就是要对结果负责，所以我们的考核设计，无论是对其他团队的安全考核，还是对安全团队考核，就是结果指标要占到考核的50%以上。比如对平行团队考核，就两个指标，风险发现、安全合规要求落实。风险发现包括漏洞和事件，内外审计发现，安全合规要求落实就是安全部门部署工作的完成情况，简单有效。安全团队考核两类指标，安全事件数和安全建设工作完成率，IT部门内平行各团队对自己的安全结果负责，安全团队对整个部门的安全结果负责，承担整个部门安全事件数考核。安全建设包括安全项目、安全合规、安全宣传等工作，也都是承诺具体指标数据的。

（五）安全汇报

管理领域有个话题，如何管理你的上级，将上级作为你工作的资源之一，是非常有趣的话题。安全汇报是管理好你的上级非常非常非常重要的一环，也是我们安全人员最不擅长的。要建立面向高级管理层、IT部门和总经理、安全团队内部的安全汇报体系。一年内要和高级管理层汇报1-2次，安全规划、安全形势、重大安全决策等，汇报形式可以是IT治理委员会或总裁办公会框架下的正式会议，也可以是定期的签报阅签形式，取决于你的需求。在IT部门和安全团队内部要进行常态化的安全汇报，此类汇报的内容要围绕三个目的展开，邀功、表扬先进督促后进、要资源。

安全大环境总体来看，短时间不会有好转的迹象。做安全的人，要有一颗越挫越勇的信心，不忘初心，不惧挑战，不断经历。努力做一个有能力的好人。

金融业企业安全建设微信群，有兴趣加入的朋友请关注微信公众号“君哥的体历”，后台留言，微信号+公司名称，验证身份后入群。

本群主要用于探讨金融行业企业安全建设的实践，主要讨论如何做好安全运营、安全攻防，安全嵌入业务、安全考核、安全度量、安全如何体现价值、安全汇报，安全内控，更低的成本实现安全合规等最佳实践，解决安全在企业落地的最后一公里的问题，希望大家踊跃提问，发言，分享体历。进群的朋友先修改备注，姓名-公司。进群新人先做自我介绍，发招聘广告前请自觉发红包，其余广告禁止。为保障群质量，定期清理人员，谢谢。

人生最美好的莫过于各种经历和难忘的体验，过程比较痛苦的，结果都还比较好。如果大家和我一样，在企业做安全中遇到各种颇为“痛苦”的体历，过后你一定会感谢和怀念这份体历的。

今天的分享到此结束，谢谢大家。