银行业安全运营平台的建设与思考

文章来源：Fintech安全之路

引言

笔者目前就职于金融行业应用安全团队，负责产品及运营相关工作。将行内原先使用的漏洞系统重构并建设安全运营平台，是我完成的第一个任务，故想把建设过程中的一些实践/思考写出来，同大家一起交流探讨，也正好算是一个阶段的总结和反思。

01 整体产品架构

基于对“安全运营”的理解（可参看职业欠钱的《我理解的安全运营》《再谈安全运营》

https://zhuanlan.zhihu.com/p/39467201），SOP安全运营平台的目标及定位：帮助团队更好地落地安全运营工作，实现流程化、规范化、可视化的目标，提升团队“安全运营”工作效率，从而提高企业整体的安全风险对抗能力。

 

平台作为应用安全管控体系建设过程中的“工具支撑”，实现了漏洞生命周期闭环、自研扫描工具集成、组件安全线上化治理、SDLC运营及线上发布版本安全管控、安全资产建设、应用安全画像及风险模型建设等模块功能。

这些功能模块之间的联动，构建了“要求—检查—管控”这样体系化的安全运营模式，解决了运营过程中人力运营成本过高、资产不清晰、安全问题处理流程不闭环、SDLC执行不到位等问题，提升了整体安全运营效率。

02 各模块建设思考

 

漏洞生命周期的闭环

不论是上线前的人工安全测试，还是自主研发的安全检测工具，都是针对不同层面风险的“检查”手段，而漏洞则是检查结果的直观反馈，是各类风险的具象反映。漏洞管理作为应用安全建设中不可或缺的部分，如何解放运营人员在这方面的工作量，提升效率，这是第一个问题。

原始

的漏洞系统，存在流程不完善、各类信息需人工维护、权限划分不清晰等问题，处理跟进一个漏洞需要花费大量人工成本。

为了解决上述问题，我们进行了如下两个改造：

1、对接CMS（Content Management System，该系统汇聚了组织、应用系统、人员等信息），将各类需要人工维护的信息统一改为系统对接，设定提交漏洞按照“应用”维度（可以拆分成的最小的一个系统，即最小单元Unit），通过应用信息则可自动关联出资产、人员及组织信息。并将执行过程中发现的数据差异反馈CMS，协助CMS自身去完善数据、矫正数据准确性，修正后的数据则可以更好被安全系统利用，从而形成良性循环。

2、在漏洞流程设计上，基于银行系统功能的迭代流程，综合考虑不同性质和环境漏洞处理的区别，设计了如下漏洞处理流程：

（在系统迭代上线前发现的漏洞称之为“版本迭代漏洞”，其他则称为“非版本迭代漏洞”。版本迭代漏洞因未上线投产故都是在测试环境；非版本迭代漏洞则可能是测试环境漏洞，也可能是生产环境漏洞）

 

在这样的模式下，一个漏洞从被提出，到定位资产以及分配至对应人员解决，再到进行验证修复关闭，在处理效率上有了大幅提升。

 

当然漏洞的闭环不仅是到修复为止，漏洞的复盘也是极其重要的一环。在观察数据的过程中，我们发现一些系统在执行了SDLC后，仍然有不少漏洞出现。这些漏洞是因为安全评估、安全需求识别、安全设计、代码审计还是安全测试环节出现了问题导致？如果能知道产生问题的环节便能更好地“对症下药”了。

顺着这个思路，我们想到可通过漏洞的版本信息反溯SDLC执行过程质量。针对版本迭代漏洞，可由安全工程师在上报漏洞时填写产生漏洞的版本和需求信息；而针对非版本迭代漏洞，目前暂时仅能通过由开发填写产生漏洞的版本和需求信息的方式（后续计划与统一接口平台进行对接，这样便能从接口信息中溯源版本信息）。有了版本和需求信息，则可查询到SDLC中安全环节的过程数据，检视SDLC执行情况。

同时，非版本迭代的版本信息也可以帮助我们了解该漏洞在线上存在的时长，对比这段时间是否进行了内部安全测试，从而检视安全测试的质量。

除了实现基础资产对接及完善漏洞闭环流程外，我们也设置了“漏洞积分”。这个分值提供了一个方式帮助定义部门及开发安全性指标：将漏洞分值累计到漏洞责任人/部门，做为评判是否需重新参加安全培训的依据，是一种“管控手段”，类似于考取驾照，扣到一定分数，就需要回炉重造。不仅如此，它还可以作为应用的安全风险值模型中的一个成分，为后续建设应用安全画像打好基础

扫描工具在安全运营平台的集成

扫描工具是“检查阶段”的重要部分，我们自主研发了一些安全检测工具：

1、基于流量的被动扫描工具（被动式漏洞扫描平台建设之路）

2、基于源代码的扫描工具

3、基于字节码的扫描工具（企业快速实践部署IAST/RASP的一种新思路）

 

安全运营平台作为各类扫描工具的前端支持，用于收集扫描授权地址、设置扫描规则、展示扫描漏洞数据、对数据进行去重、以及制定扫描漏洞处理流程（包括自动处理及人工处理）。这些工具扫描的结果如何处理过滤，形成高质量的数据汇入漏洞模块中？这是第二个问题。

 

针对误报问题，既需要研发人员不断优化规则，也需要有合理的流程，对扫描结果进行分析运营。于是针对工具扫描出的漏洞我们分为三个处理阶段：

1、规则刚上线的时候，因误报较多，此时扫描到的漏洞会先存放在单独的扫描漏洞模块，负责规则的安全运营者以人工方式初步判断漏洞是否存在，并将漏洞提到漏洞审核模块（其中一部分系统无法自动对应资产的漏洞，由人工对资产进行定位），再由各业务线的安全工程师对漏洞审核模块的漏洞进行审核和处理（可进行上报/合并上报/忽略/关联历史漏洞等），最终提到漏洞管理模块，传递给开发进行确认与修复，进入既定的漏洞处理流程中。

2、规则稳定运行一段时间后，会自动将扫描到的漏洞推送到漏洞审核中，直接由各业务线的安全工程师进行审核处理，然后提至漏洞管理模块。

3、当扫描漏洞的准确率达到一定水准后，会将漏洞审核中的漏洞，由系统自动提交至漏洞管理，即直接将漏洞传递给开发进行确认与修复，无需让安全工程师先进行审核。

这样经过三个阶段，我们可以保证漏洞管理模块漏洞数据的质量，尽量真实且权威。

 

针对上述思路，每一种工具的每个插件，它的开关、扫描出的漏洞等级、去重规则、是否自动推送至漏洞审核、是否自动推送至开发等，在前端页面实现配置化管理，如此一来，运营人员可结合实际数据情况进行相应操作（例如某种检测插件准确率达到一定高度则开启自动推送，如在某段时间准确率又突然下降，则暂时关闭自动推送），在对扫描结果的处理上便更加灵活。

组件安全的治理

除了一些web漏洞之外，通用组件一直是容易被外界突破安全防线的一个关口，当前大部分公司都会面临通用组件的安全问题。针对组件漏洞，适用范围广，造成危害大，动辄成千上万的资产收到影响，修复起来并不是件容易的事情。传统case by case方式，通过线下整理数据跟进修复，收效甚微。在组件安全这个方向，如何做好问题修复及管控是第三个问题。

 

在经过讨论及技术论证，确认方案可落地后，我们根据《通用组件安全治理三步走实践》这篇文章介绍的思路，进行了开源组件模块的研发。组件漏洞处理方式区别与应用漏洞，我们将常见的一些组件漏洞放在这个模块单独跟进处理，无需开发人员在系统上操作任何按钮，只需按照修复方案完成修复后并上平台查看是否还存在受影响资产即可。

当然，除了有针对存量问题的流程及方案，我们也需考虑如何在研发流程中对组件安全问题作出检查，从而控制增量组件安全问题。

1. 通过在版本发布过程中进行控制，如果应用版本发布过程中仍然存在组件安全问题，将禁止发版强行阻断，确保新增应用无历史组件安全问题；

2. 通过在组件仓库设置组件黑名单，如果使用低版本的组件将无法打包成功，强制要求开发升级版本。

研发过程的安全管理（SDLC运营）

Sop安全运营平台通过对接需求及研发管理平台，在需求拆分到开发任务后的评审环节，将安全要求作为评审内容的一部分，引导开发人员对安全要求进行自行评审/实施安全设计。

 

有了安全评审和安全设计的数据，再结合各维度安全检测（包括人工安全测试、应用层漏洞扫描、组件安全检测、源代码安全扫描）的检查结果，我们便可以将研发流程中的安全过程数据汇聚，形成综合统一结论，并在系统层面实现“管控增量问题”。

 

在经过对各业务线系统的版本发布流程以及行内研发流程的调研后，我们制定了版本安全管控的方案。将安全检测划分为不同维度（例如划分为应用层安全风险、源代码安全风险、组件安全风险），最终的安全检测结论是几个维度的结论合集。根据既定的规则，在测试完成环节，给予安全检测的结论与报告。如结论是通过并且报告正常进行了存档，才能顺利进行版本移交，进行代码冻结，从而完成版本的发布，否则将进行阻断。

如果检测实时性够高，可以将检测结论尽量前置，做到在开发环节就可以随时查看安全检测情况，从而更快速解决安全问题。并且在代码冻结之后，封板之前（也就是发布前的最后一个动作）也再一次进行安全检测结论的校验，多环节把控版本安全质量。

安全资产与安全画像

当然，以上思路的实现，少不了安全资产数据的支撑。“资产数据是安全工作的基石”，我们只有将资产梳理清晰，才能更好地站在安全风险视角去及时发现问题、溯源问题和解决问题，从而提高安全管理效率。例如前面提到的组件安全治理，需要掌握全行的组件及版本信息，以及目标（应用）所依赖的全部组件信息，才能做到当某一组件出现安全风险后，实现快速排查和定位受影响资产。

通过对接CMS/HIDS等，我们奠定了建设安全资产的基础。在此基础上，针对已有的资产数据，我们只需根据安全制定的策略给各资产打上安全标签，并根据实际情况对资产的安全标签进行动态维护和运营。针对其他现有系统未覆盖到的数据，我们可以通过主动探测和被动扫描的方式，如采集目标网络的流量,对流量中数据进行分析,从而发现未知的网络资产信息。当然这其中还涉及到关于数据采集、数据清洗、数据关联等很多功能模块，这里由于篇幅原因便不再展开。

在完善好资产的一些安全属性后（如是否面向互联网、登录认证方式等），再结合应用的各类安全风险，便可以刻画应用安全画像。

有了每个应用的安全画像，便可建设安全风险模型，定义风险阀值，通过阀值来检查各应用的整体安全情况，制作整体的安全风险看板，展示整体安全风险趋势、风险累积或风险消除等情况。

 

03 总结

通过以上几个模块的介绍和分析，我们可以发现，各模块之间围绕着“要求—检查—管控”这条线有着不可分割的紧密联系。研发安全管理中的安全评审与设计是要求，人工安全测试和各类工具扫描是检查手段，漏洞则是检查结果，通过漏洞的“复盘”“溯源”可以分析出“要求”的执行是否真正落地。漏洞的修复和漏洞积分是管控手段，各维度检查结果汇总并与研发流程结合进行的版本控制，也是管控手段，通过各类管控才能有效控制安全风险。而安全画像/风险看板则是要求-检查-管控中的过程数据，有了这些数据进而可以帮助安全运营人员更直观了解整体以及每个应用的安全风险和当前状态，准确定位安全防护的重点。

 

除了思路上的总结，在建设平台过程中，也有两点经验想要分享：

• 要对系统的定位非常清晰。时刻站在“做系统的目的是为了什么，做的这些功能到底能否真正帮助实现目的”的角度思考，并且需要有整体架构的规划，才能让系统在不断“壮大”的过程中不至于失了“重心”而坍塌；

• 产品的易用性直接决定了运营难度的高低，在充分结合各类现有的安全工具的基础上，一定要考虑尽量贴合企业自身的各类流程（如研发流程等），将安全运营的各个环节有效融入到日常的研发流程中。

 

最后，在从SDLC到DevOps的广义应用安全管控体系建设下，安全运营是贯穿整体的能力支撑。如同lakehu在《小步快跑，快速迭代：安全运营的器术法道》说到的“安全是一个动态过程，它随着形势在不断变化，运营就是发现变化趋势调整优化安全策略达到安全目标的重要手段”，安全运营平台的建设则是“帮助运营人员直观发现安全变化趋势，为优化安全策略提供数据决策能力”，是为安全运营工作做好工具支撑，提供更高效、更便捷的运营方式和途径。

☆ END ☆

联系/合作/投稿邮箱：[email protected]

你点的每个赞，我都认真当成了喜欢

本文始发于微信公众号（安全365）：银行业安全运营平台的建设与思考