引言
本文是根据.10.28在某证券基金行业交流会的发言的整理稿，从业十余年，除了接到一些工作任务安排外，我没有上台演讲的经历，这次算是我的第一次。分享了我对金融行业企业安全运营之路的经历和理解，包括面临的问题、安全运营架构、支撑工具和所需资源，对安全运营的难点，安全检测为什么会失效，安全运营成熟度，做了一些探讨。对企业安全灰色地带、白名单还是黑名单等问题做了一些思考。受限于本人自身的从业经历和所处行业，可能不具有普遍代表性，个人能力和视野也有限，希望大家批评指正，要是能给有需要的同仁一些参考帮助，善莫大焉。
面临的问题
1.安全需求
在企业信息安全建设初期，安全工作的主要内容是购买安全设备和部署安全管控系统并进行日常维护。从网络层、虚拟层、系统层到应用层、数据层、用户层部署了一系列安全设备或软件并确保其稳定运行，但发现安全状况并没有得到有效改善，安全问题频发，其根本原因是没有进行有效安全运营。如何建设企业有效的安全运营体系，本文抛砖引玉，做一些分享探讨。
金融行业是牌照行业，接受严格的监管，典型特征是业务的持续稳健发展需要安全来保障，有专职的安全团队和安全人员，每年安全预算和投入有保障且逐年增加。企业的安全需求表现为：
2.面临的问题
在企业安全需求下，面的问题主要是三个方面：
（1）企业安全的全貌
企业安全的全貌是什么？我们拿着显微镜，看看安全管理员每天的工作内容，包括：每天查看各类安全设备和软件是不是正常运行，硬件告警、应用程序和进程，性能容量，表空间，存储空间，系统和应用日志；安全设备和系统的安全告警查看和响应处理，包括防病毒日志和告警、防火墙日志和告警、入侵检测日志和告警、互联网监测告警、蜜罐系统、防数据泄密系统日志和告警，各类审计系统如数据库审计、防火墙规则审计报表和日志，外部第三方漏洞报告平台信息；处理各类安全检测需求和工单；各类安全漏洞修补和复核检查，有分支机构管理职责的还要督促分支机构的安全管理工作；填报各类安全报表和报告，汇报各类可疑情况并进一步追查；推进各类安全项目，有管理的，有技术的；有的还要付出大量精力应对各类安全检查和内外部审计。做过基层安全运维的人对上述场景都会很熟悉，这是企业安全各个场景的缩影，但不是全貌。如果一个企业只有少量人员，服务器和产品，那么上述内容就是企业安全工作的全部，我定义上述工作是安全防护框架。如果是有万台服务器，几百个程序员，数以百计的系统，企业安全除了漏洞检测和漏洞修复，安全检测和攻防外，还要考虑安全运营的问题，从工作量上看，安全防护和安全运营各占50%。
（2）安全服务质量保持在稳定区间
在安全防护框架建设中，会部署大量的安全防护设备和措施，在显著提升安全检测能力的同时带来问题：各类安全日志和告警如何有效响应处置？安全设备数量急剧增多的同时，如何解决安全设备有效性的问题？安全人员在应对安全设备数量和安全日志告警急剧增多的同时，如何确保人员工作质量的稳定输出？这里指的是人员工作质量的稳定性，我们的目标是要尽可能消除单个人员对安全团队对外提供安全服务质量的影响。举个例子，就像大餐和快餐的区别，大餐靠的是名厨名师的发挥，如果今天这个名厨心情不好或者换个新人，可能做出的产品质量就有非常大的下降。而快餐如肯德基，所有的操作都标准化和流程化，就是初中毕业没学过烹饪，没练过的人经过短期培训和严格管理，也能确保炸出的薯条味道一模一样。快餐的标准化流程和管理几乎完全消除了人的因素，确保对外提供的服务质量能够始终稳定，不会出现大起大落的情况。安全运营的目标或者说需要解决的问题就是在企业变大，业务和系统日趋变复杂的情况下，在资源投入保持没有大的变化情况下，尽量确保安全服务质量保持在稳定区间。
（3）安全工程化能力提升
安全运营还需要解决的一个问题是安全工程化能力提升的问题。举个例子，企业内很多有经验的安全工程师能够对怀疑一台服务器被黑进行排查溯源，查看服务器进程和各种日志记录，这是工程师的个人能力。如果能将安全工程师的这种能力转变成自动化的安全监测能力，并通过安全平台进行应急响应和处理，让不具备这种能力的安全人员也能成为对抗攻击者的力量，这是安全工程化能力提升的收益，也是安全运营需要解决的问题。
安全运营的思路
1.架构
为确保安全运营架构能够灵活扩展，推荐按功能模块划分成四个模块：安全防护框架、安全运维框架、安全验证框架、安全度量框架。安全防护框架的主要功能是通过不断的部署安全监测系统，提供实时检测的能力，称为安全感知器“Sensor”，为安全运维框架提供“天眼”。时下流行的态势告知、入侵感知我理解为主要靠安全防护框架来保障。安全运维框架的主要功能是统一采集安全防护框架各Sensor的监测信息，并通过黑白灰名单处理和关联分析（有很多厂商号称大数据智能分析，我理解为只是基于规则的数据挖掘）处理监测信息并通过统一展示平台输出告警，进入事件处理平台和流程，人工介入处理。安全运维框架还包括安全事件的定期review和向管理层汇报，这部分可能比单个单个的事件处理还要重要。安全验证框架主要功能是综合通过黑盒白盒验证措施，确保安全防护框架和安全运维框架有效性。安全度量框架主要功能是通过一系列安全度量指标，衡量评价安全运营质量水平，并针对性持续过程改进，实现质量的螺旋上升。
（1）安全防护框架
安全防护框架的目的是部署尽可能多和有效的安全感知器Sensor，这些安全感知器构成了信息安全的“天网”，这部分是基础工作，也是传统安全的主战场，需要历经多年的持续投入积累。安全Sensor的部署遵循纵深防御的理念，见以下示意图：
实际中可能远远不止上述这些Sensor。比如网络层，可以把防火墙监测信息特别是Deny信息采集了，有些防火墙还自带IPS功能如CheckPoint的SmartDefense，就是特别好用的安全Sensor，交换机、路由器的ACS服务器信息、堡垒机登录信息、虚拟层虚拟主机操作信息、Windows、Linux主机日志、有在主机部署安全客户端的监测信息、数据库审计系统监测信息、AD系统信息、存储备份系统操作信息、KVM、ILO等带外管理系统信息、ITIL系统工单信息、应用系统应用信息如OA系统应用日志、SAP系统应用信息、公文传输系统日志、FTP数据传输日志。企业基础安全的很大内容就是建设各类安全Sensor，解决点状的安全问题和需求。比如企业防火墙多了，如何管理防火墙规则的有效性和合规性，可能需要部署诸如Algosec、firemon等防火墙规则审计工具，审计发现的信息就可以作为安全运维框架的输入。如果想监测企业内网或服务器访问了哪些恶意地址，可以采集类似ArcOSI这样的开源恶意地址库。
安全防护框架建设，需要考虑两个问题。一是发送原始监测信息还是Sensor处理后的监测告警信息给安全运维框架？如果是防火墙、IPS等安全防护系统，尽量是全量原始信息。如果是Windows、linux主机日志、合规检测、登入登出等信息，考虑对原始信息做过滤，只和安全相关的信息才作为安全运维框架的输入。二是要不要做业务安全监测。华为Ayazero认为企业安全涵盖7大领域，①网络安全，②平台和业务安全，③广义的信息安全，④IT风险管理、IT审计内控，⑤业务持续性管理，⑥安全品牌营销、渠道维护，⑦CXO们的其他需求。对于传统行业，建议做①③④⑤，对于互联网公司，建议做①②⑤，对于金融行业，我建议做①③④，能力强的安全团队，建议做①③④⑥⑦。
（2）安全运维框架
安全运维框架的建设目标是成为企业安全的大脑、神经中枢、耳目和手脚。在军队现代化作战体系中，美军创造性的提出了C4ISR作战指挥系统，即指挥、控制、通信、计算机与情报、监视、侦察。一个完整的信息安全作战指挥自动化系统应包括以下几个分系统：
“大脑”-基础架构平台。基础架构平台是构成指挥自动化系统的技术基础，指挥自动化系统要求容量大、速度快，兼容性强。“耳目”-安全情报、安全监视、侦察系统。主要是对安全防护框架中各安全Sensor的安全信息的收集和处理，实现异常行为的实时安全监测。“神经中枢”-数据分析系统。综合运用各类智能分析算法和数据挖掘分析技术，实现安全信息处理的自动化和决策方法的科学化，以保障对安全控制设备的高效管理，主要技术是智能分析算法和模型及其实现。“手脚”—安全控制系统。安全检测和控制系统是用来收集与显示安全信息、实施作战指挥系统发出安全控制指令的工具，主要是各类安全控制技术和设备，如防病毒和主机安全客户端、防火墙等，主要实现异常行为的实时安全控制。
安全运维框架实际落地时，企业会部署SIEM或SOC等类似平台实现安全检测信息统一采集和存储，大部分SIEM或SOC平台支持内置或自定义的黑名单检测规则进行实施检测，也有结合智能分析平台进行安全大数据挖掘的案例，以解决SIEM和SOC平台智能分析不足的短板。遵循事件处理标准化流程，纳入ITIL事件管理流程，通过下发工单和发送告警邮件、短信等方式进行安全提醒。安全事件确认和溯源分析主要通过人工分析和确认的方式进行。对于%确定异常的安全攻击通过自动化方式进行阻断。通过安全事件日例会和周报、月报等方式对安全事件进行闭环管理。
（3）安全验证框架
安全验证框架解决安全有效性的问题，承担对安全防护和安全运维两个框架的功能验证。安全验证框架是企业安全的蓝军，在和平时期，蓝军扮演着对手角色，利于及时发现、评估、修复、确认和改进安全防护和运维框架中的脆弱点。包括白盒检测（过程验证）和黑盒检测（结果验证）两部分。
白盒检测（过程验证）是指建立自动化验证平台，对安全防护框架的管控措施实现%的全面验证，并可视化集成至安全运维平台中，管控措施失效能够在24小时内发现。通过自动化验证平台达到：
基于上述目标，自动化验证要求所有的验证事件必须为自动化模拟真实事件产生，不能使用插入记录的方式产生，同时自动化验证事件应提供判断是否为验证事件的唯一标识，验证事件产生时间需统一安排，防止集中触发。安全运维平台应能够监测到安全验证未通过的系统和规则，并产生告警信息，通知安全运维人员介入处理。
黑盒检测（结果验证）是通过多渠道安全渗透机制和红蓝对抗演习等，先于对手发现自己的漏洞和弱点。多渠道安全渗透机制目前常见的就是安全众测，红蓝对抗演习需要企业具有较高攻防技能的安全人员，也可外聘外部专业机构完成，用于检测安全防护框架和安全运维框架的有效性。
（4）安全度量框架
安全度量框架主要用于衡量评价安全有效性，这是挺难的一件事，做些探讨。我觉得可以分成几个层次：
一是技术维度。包括防病毒安装率、正常率，入侵检测检出率、误报率，安全事件响应时长、处理时长，高危预警漏洞排查所需时间和完全修复时间。还可以考虑安全运维平台可用性、事件收敛率等。合规性方面可以设置合规率、不合规项数量、内外部审计发现数量和严重度等；
二是安全运营成效。包括覆盖率、检出率、攻防对抗成功率。有多少业务和系统处于安全保护之下，有多少无人问津的灰色地带，安全能在企业内部推动的多深入，多快速，这是需要综合技术和软性技能的，成败主要系于安全团队负责人。检出率和攻防对抗成功率都是衡量安全有效性的有效指标，安全团队即使不能拍着胸脯保证不出事，也不能靠运气和概率活，那持续提升检出率和攻防对抗成功率就是努力的方向；
三是安全满意度和安全价值。安全价值反映在安全对业务支撑的能力，TCO/ROI，安全用多少资源，支撑了多少业务，支撑的程度。安全价值还体现在内部的影响力以及对业务的影响力，是做微观安全还是广义安全，是为业务带来正面影响还是负分拖后腿。安全满意度是综合维度指标，我理解为是对安全团队和人员的最高要求，既要满足上级领导和业务部门对安全的利益诉求，又要满足同级横向其他IT团队对安全的利益诉求，还要满足团队内部成员的利益诉求，要提供最佳的安全服务，让安全的用户成为安全的客户，让使用者满意，真的是非常非常有挑战的一件事情。
2.工具
安全运营工具包括支撑安全运维框架实现的SIEM平台、安全事件处理标准化流程工具ITIL、安全控制自动化工具三部分。SIEM平台负责安全信息的统一收集和存储、基于检测规则的异常检测和告警。ITIL平台负责接收SIEM平台发送过来的安全事件信息并据此产生ITIL工单，推送到安全运营人员处理和关闭。安全控制自动化工具负责根据SIEM平台下发的安全控制指令进行自动化操作，比如检测发现有外部攻击源，通过下发自动化指令实现防火墙或IPS封禁该攻击源。检测发现某主机有可疑进程，通过安全客户端收集该进程文件样本信息进一步手动分析。检测发现办公内网某用户计算机上有个可疑操作非人工操作，疑似程序自动操作，可通过安全客户端提示用户手工确认等。安全控制自动化工具目前商业化程度不高。
（1）SIEM检测规则
如果有合适的检测规则，SIEM是个非常强大的工具，可以检测其他安全工具无法捕获的安全事件。通常SIEM的检测规则有三类：
①单一检测条件规则
满足单一特定检测条件则触发告警。如服务器主机登录来源非堡垒机地址。满足该条件则告警，该类型规则最简单，主要依靠安全Sensor的监测能力和规则过滤能力。是攻击就一定有异常，关键是怎么总结提炼出异常的特征加以检测，比如Ayazero在《互联网企业高级安全》中提到的检测攻击提权（某个高权限（system?uid=0）进程（bash?cmd.exe?）的父进程为低权限）是一个总结提炼异常特征加以检测的很好案例。
②跨平台安全监测信息关联检测
最典型的规则为基于资产脆弱性的攻击告警，关联分析漏洞扫描和入侵检测告警信息进行关联检测。还比如防火墙permit日志中有连接ArcOSI中定义的恶意IP地址信息。该类型规则在跨平台系统监测信息之间进行关联，可以衍生出很多脑洞打开的检测规则。比如检测安全违规行为，检测数据泄密，甚至人员可能离职等。这类规则检测效果的好坏取决于两点：一是安全Sensor的类型尽可能多和单个Sensor能监测维度尽可能广；二是规则设计者的检测思维，就像攻击者思维一样，需要脑洞大开，需要猥琐。③针对长时间缓慢低频度攻击的检测规则
大部分的安全工具是以孤立方式识别潜在的安全事件，如IDS监测到某台工作站发出的可疑流量，然后从其他20台工作站上监测到同类流量，在IDS管理面板上，每个事件被当作单独事件处理（有些IDS厂商有高级功能），在SIEM中可以编写规则，根据事件发生的频率触发不同的告警，如果在几分钟内从IDS传来21次类似的事件可以触发一条规则。如果攻击者采取长时间缓慢低频度攻击入侵企业内网，可以编写一条SIEM规则，在较长时间内搜索特定事件，并在该事件范围内发生次数达到某个阈值时告警。更进一步，这种检测规则对于不是即时安全事件形式出现的日志也同样有效。如检测DNSTunnel为例，DNSTunnel用于将CC流量编码为DNS请求，从被感染机器发出，通过被感染企业的DNS服务器到达CC服务器，然后再将响应返回给企业的DNS服务器，由其转发给受感染的内网机器。正常的DNS查询都有一定频率，DNSTunnel需要咋网络上发送许多DNS数据包，那么制定内网单台机器对同一个域名的查询达到某个阈值（如10分钟内0个查询）的规则可以有效检测DNSTunnel。SIEM的检测规则还可以配置为在流量来源与旧模式不同时发出告警，也可以配置为在合法和以往正确的流量突然呈现指数上升或者下降时发出告警，如过去90天内产生一定数量日志的Web服务器突然开始产生于10倍于正常数量的日志，这可能是被入侵主机用于向其他主机发动攻击的迹象。通过SIEM规则，安全团队可以根据流量的标准差制定告警，如达到10个标准差阈值就告警。
（2）SIEM健康度监控
从很多攻防案例中，防御方失败的原因主要归结于安全防护失效，其中SIEM平台工具健康度出了问题是比较常见的，包括：安全Sensor安全监测信息采集器失效、SIEM检测规则失效、安全告警失效、安全告警处理失效。安全检测信息采集器失效的原因主要是未对采集器的物理机器性能监控、采集数据正常监控、采集数据日志解析和映射入库（Parser）异常等。SIEM检测规则失效包括设定条件无效、阈值无效、规则未生效等，有时告警阈值设置不合理频繁告警，SIEM平台会自动禁用规则导致规则无效。安全告警失效，包括邮件、短信网关配置无效，配置用户失效、网络失效、配置变更异常、手机号码设置错误等等。安全告警处理失效主要是人的因素，比如多条告警短信，选择性的忽略，假阳性告警太多淹没了真正有威胁告警等。
值的一提的是安全Sensor的安全性。韩国在年3月20日下午2点，包括新韩、农协和济洲等3家银行与KBS（韩国广播公司）、MBC（韩国文化广播公司）等2家电视台，超过32,台电脑以及部分ATM提款机，都在同一时间当机，无法重新启动。 黑客首先入侵了韩国防病毒软件厂商AhnLab（安博士）的病毒定义更新服务器，利用病毒库定义升级机制，将恶意软件分发到用户的计算机，在用户的计算机上安装执行恶意程序。调查发现，另一家防病毒软件公司ViRobot也被黑客利用。如果你在企业内部部署的安全Sensor接受更新的是恶意软件……，不寒而栗。做好安全Sensor的安全性的重要性，不用再强调吧。几个原则：控制指令仅允许固化的指令，严禁在Sensor端预留执行系统命令接口；更新包必须经过审核之后上传至更新Server保存，更新仅允许选择更新Server上以后的安装包，最好校验更新包的MD5；控制指令下发时必须人工审核确认后才执行。为可用性起见，更新最好分批分区域完成，否则由于大量更新包的下载导致生产网被堵塞，老大也饶不了你吧。
3.所需资源
（1）流程与机制
有效、高效的安全运营流程与机制是非常非常非常重要的。安全运营流程一般做好两个标准化的流程：安全事件处理流程、安全运营持续改进流程。安全事件处理流程是定义什么级别的事件该由什么样的人，在什么时间按什么标准处理完成。一个外部攻击扫描和内部发现的分支机构过来的持续不断的高权限账户猜解安全级别肯定不同。前者最多为普通或
