观点农信银刘安蒙：农信银中心软件开发项目安全管理体系建设实践

CNVD的统计数据显示，大多数导致安全事件的漏洞都出自软件应用本身，而软件开发的早期采取避免漏洞的安全措施，将会极大降低软件漏洞的修复成本。如何突破传统的单纯依托事件驱动和测试驱动的漏洞管理模式，从根本上提升软件安全质量？农信银软件开发项目安全管理体系建设实践提供了很好的借鉴。

日前，在由农信银资金清算中心主办，金科创新社承办的“2019农村金融科技创新与共享发展会议暨第三届农村金融科技创新优秀案例评选”上，农信银资金清算中心项目经理刘安蒙从安全管控痛点、体系建设情况、运营情况、建设愿景四个方面分享了农信银软件开发项目安全管理体系建设实践。‍

一、安全管控的痛点‍

1. 应用软件漏洞形势非常严峻

首先分析三组统计数据，第一组数据为安全漏洞的统计数据。图1为2013-2018年CNVD收录安全漏洞数量统计，从中可以看出，2013年漏洞数量是8000多，2017-2018年为15000-16000多，年均增长率达到15%，其中高危漏洞数量从2013年的2000多个增长到2018年的5000多个。图2为2018年CNVD收录漏洞按影响对象类型分类统计，漏洞类型包括应用程序漏洞、Web应用漏洞、操作系统漏洞、网络设备漏洞、安全产品漏洞和数据库漏洞等，其中应用程序漏洞和web应用漏洞占全部漏洞的比例达到76.5% 。也就是说，大多数导致安全事件的漏洞都出自软件应用本身，这对开发安全提出严峻挑战。

第二组数据是关于漏洞修复成本的数据，在软件开发的不同阶段（研发阶段，直接由开发修复，成本低，效率高；测试阶段，测试人员提交给研发人员修复，需要一定的沟通成本，相对来说效率较高；发布阶段，系统上线后检测到漏洞，需要安全人员给出方案，与研发人员沟通，由测试人员验证，也需要承受一定可能性的线上风险，风险成本较高；运行阶段，系统运行期间由事件驱动或监管报告发现漏洞，沟通成本高，再修复时，需要运维介入，修复成本倍数的上升，给企业带来相当大的风险和成本压力）漏洞修复的成本呈现很大差异。美国标准技术发布的数据显示，系统上线后漏洞修复比在需求阶段规避漏洞成本高出30倍，IBM的研究显示，相关成本差距为30—50倍。上述数据充分表明，软件开发的早期采取避免漏洞的安全措施，将会极大降低软件漏洞的修复成本。

第三组数据来自某单位系统上线后的渗透测试结果，通过对2017年和2018年总体渗透测试结果的对比分析可以看出，尽管采取了多种安全措施，但是这两年的高危和中危漏洞的总量没有明显变化。此外，两年中排名前10的漏洞中有七种漏洞类型是一样的，这说明2017年开发出现的问题在2018年重复出现。单纯依托事件驱动和测试驱动的漏洞管理模式，难以根本提升软件安全质量。

2. 软件安全两大类问题

一是软件质量可靠性和可用性问题，指系统运行中出现错误结果、不稳定和崩溃的情况，造成服务不可用。这类情况一般是由于软件设计或编码时考虑不周，软件运行中出现无法处理的异常，或申请操作系统资源过多而释放不及时，或线程处理不同步等情况引起。二是信息安全保密性和完整性问题，指软件漏洞被恶意利用，造成严重的信息安全事件。这类问题一方面由于软件需求、设计阶段安全防护考虑不到位，威胁分析不到位，导致安全防护手段的缺失；另一方面，由于编码时代码安全没有及时修复，且有被利用的可能性。

3.三个局限性使得软件开发过程中安全漏洞难以避免

分析开发过程中漏洞产生的原因，主要在于三个局限：一是开发模式的局限性，传统软件开发强调的是功能需求；无论瀑布模式、增量模式还是敏捷模式，重点关注的是功能的正确实现，并不强调漏洞的降低；二是生命周期的局限性，传统开发生命周期是“需求-设计-编码-测试-投产”，缺乏对安全的关注 ，缺少对安全的控制环节与安全问题的解决；三是开发能力的局限性，传统开发人员大多只具备开发编码能力，缺乏信息安全知识，此外，编码人员缺乏安全意识，难以从“攻击者”的角度审视开发的软件。

综上，开发安全是需要顶层设计的系统性工程，管理制度不完善、支持服务跟不上、人员专业能力局限性等导致管控成效不佳。在此背景下，农信银中心开展了开发安全体系的建设。

二、体系建设情况‍

1. 明确开发安全建设目标，依据适用性原则，构建可控、可落地的管理体系

与大型金融机构上百人的安全团队相比，中小金融机构必须找到适合自身的开发安全的建设体系和思路，即以较少的投入（大概50%）解决大部分问题（70%—80%左右）。基于上述思路，我们制定了“提升安全开发专业能力，降低软件漏洞数量”的开发安全目标。在选择最佳实践方面对标当前主流软件开发模型，如微软SDL（适合瀑布模型的中型、大型软件开发项目，重点关注细节的实现，安全开发周期长）、成熟度模型BSIMM （聚焦于风险管理，关注于7个接触点在软件开发不同阶段的风险分析，为增量迭代模型提供新的安全管理思路）、OWASP的CLASP （轻量级、综合性的SDL模型，关注实施安全的实践活动，强调评估与改进，为迭代模型提供安全管理思路 ），融合各个模型中与我们需求相符合的因素“为我所用”，最终形成以“管控 服务”的方式，构建可落地的软件开发过程全生命周期安全管理体系（见图3 ），包括支撑服务、工具体系和文件体系三部分。文件体系是一系列的安全制度和保障措施，指导开发人员如何做好安全工作；支撑服务和工具体系是为减少开发人员安全相关工作量提供的工具和支持。如工具体系中的四大工具中的安全需求分析平台以工具化的思维生成知识库，为开发人员提供需求、测试服务；安全组建与标准解决方案资源库，以开箱即用的方式直接提供给研发人员使用；代码审计工具和安全配置审查工具帮助开发人员落地文件体系中的众多管理制度、技术控制和管理规范。基于目前开发人员数量少的现状，引入了四个驻场服务人员帮助整个体系的运营落地。

图3软件开发项目安全管理体系

①充实ISO27001信息安全管理制度体系，形成开发安全制度树。农信银中心2015年通过了ISO27001认证，基于该认证开发安全相关的管理制度拓展了“组织管理、开发安全过程管理、开发与测试环境管理、软件采购项目管理、软件开发项目资产管理、开发人员管理”六个方面内容，重点加强开发安全过程管理。其中，“软件开发项目安全管理过程指导书”中既有软件项目开发的相关规范也有开发安全管理的内容，是制度体系的核心。指导书中的“过程裁剪指南”和“系统风险定级指南”根据项目类型（新建类项目，系统庞大、实施周期长；变更类项目，又分为普通变更、快速上线变更、缺陷修复的变更）采取不同的裁剪和风险定级策略。如针对快速上线和缺陷修复的变更裁剪的内容相对多；针对高风险的系统裁剪的内容少一些，以确保不同类型项目在软件开发过程指导中分别落地。

②发布企业级开发安全规范，向标准化迈出坚实一步。安全规范包括应用安全开发规范和应用安全测试规范。应用安全开发规范包括安全需求、应用安全设计、数据安全设计、应用安全编码，核心内容是开发安全基线，我们没有直接采用SDR体系，因为SDR强调每一个项目在设计阶段要针对每一个功能建模，投入成本非常高。我们的做法是对项目类型进行分类，抽象出功能，提前进行SDR建模分析，相当于提前生成安全基线，后续同类系统直接采用即可。目前，安全基线涵盖了5大类32个子类178个控制类，还在不断完善中，随着新系统的建设，基线也将更加丰富。应用安全测试规范包括验证型测试和发散型测试。

③建设“开箱即用”的安全组件与标准解决方案。搭建开箱即用的安全组建，包括pthon 安全组件、C组件、JAVA安全组件等；建设了标准化的安全解决方案库， 分别用于加密应用场景（解决中心加密平台使用过程中版本不统一、共用同一套密钥问题 ）、签名验签应用场景（解决中心应用签名验签过程中使用版本不统一问题）、中心内文件传输应用场景（解决中心在敏感文件传输、共享过程中存在管理端口开发、文件不加密等问题 ）、中心与外部通信应用场景（解决中心与外部机构进行通信时技术方案不一致，存在敏感文件不加密传输，未进行有效身份验证问题 ）、对账文件应用场景（解决中心对账文件生成后存储未加密问题 ）等。

④以“工程化”为导向，形成开发安全系统化、自动化平台能力。安全需求分析平台的核心思路和理念是工程化导向。工程化解决了因人能力不同而安全成效不同的问题。以工程化的思维打造自动化分析平台，辅以安全组件库、安全标准解决方案库、威胁资源库、业务场景库、合规资源库，最终实现安全需求文档、安全设计、安全开发建议、安全测试要点等的自动导出。

2. 以“可控”为根本出发点，将管理与支撑落地到开发安全各环节

基于文件体系和工具体系，为最终实现开发安全的落地，我们在软件开发的“启动/立项、需求/设计、实现/测试、发布/验收”全生命周期进行了有效管控。管控工作由安全部门和研发部门共同完成，安全部门负责安全评审、安全需求评审、安全设计评审、安全测试用例评审、安全需求符合度测试、渗透测试、系统配置核查、漏洞扫描、上线前综合安全评审等工作；研发部门负责风险定级、安全要求、安全需求分析、安全设计、安全测试用例、源代码审计、等保合规检查等工作。同时，为了减少研发人员工作量，安全人员运用安全组件库、安全解决方案库、配置核查工具、渗透测试工具、漏洞扫描等大量工具去支撑管理体系的落地。

以新建系统为例，说明安全管控的实施过程，在启动立项阶段管控重点在于，一是风险定级，明确系统的风险级别；二是提出总体安全要求。立项启动阶段，明确总体安全要求的目的是希望达到共赢，明确项目中的安全需求，以获得资源和开发时间方面的合理安排。在需求设计阶段管控要点是需求评审和设计评审，目前为线上评审方式，内容由安全人员负责，对安全需求和安全设计进行复核。自动化平台上线后，安全人员评审工作量大大降低，从以往依赖安全人员个人经验和判断到现在只需核对提交文档内容与系统导出内容是否一致即可，大大降低了对安全人员能力要求。实现测试阶段的重要安全管控是源代码审计，测试阶段安全团队介入确保测试全面覆盖。此外，这一阶段安全团队还要进行安全需求符合度测试，确保安全功能一一实现；最后的发布验收环节采取了安全管控的核心管控措施，管控要点一是渗透测试，灰盒测试，确保高、中危漏洞全修复；二是系统配置核查，确保系统配置符合基线要求，不符合配置全修改；三是漏洞扫描，确保上线前相关系统无重大安全漏洞。对于未能通过综合安全评审且须紧急上线的系统或变更，则需要明确整改时间，且需经业务需求、研发部门安全负责人签字同意才能上线。

三、体系运营情况

一是自2019年4月安全需求分析平台试运行后，项目组全程参与3个软件开发项目工作，并为25个项目提供安全需求分析与详细设计工作。安全需求分析与详细设计工作效率有明显提升，渗透测试漏洞数量明显降低。

安全需求分析、安全设计时间对比见图4，安全团队以前安全需求分析和安全设计的平均用时接近一周，现在，依托工程化平台，只需半天时间，做一个简单的调查问卷系统就可自动导出，极大缓解了安全团队的评审压力。

图4 工程化前后安全需求分析、安全设计时间对比

二是工程化后，项目安全需求分析与详细设计内容更加规范、全面。图5为某系统工程化前后安全需求对比，可以看出工程化前没有真正落地的需求，工程化后，安全需求的内容更加规范、全面。

图5某系统工程化前后安全需求对比

三是开发安全试点项目的中高危漏洞数量比例下降67%。图6是2019年4月以来运营情况。通过对三组系统渗透测试结果对比，可以看出漏洞数量最终降低到0.67个，下降了67%。

图6系统渗透测试检测成果对比

四、系统建设愿景

本着“服务农信”宗旨，发展中心“大安全”战略，我们向成员单位推出“开发安全需求分析平台共享共建计划”，截至2019年11月15日，18家联社反馈参与合作意向。

计划分两个部分，一是共享，将安全需求分析平台共享给合作成员单位使用；二是共建，未来希望进一步丰富联社特有的系统基线。

农信银中心共享共建计划本着减少重复建设、降低IT成本的初衷，实现农信体系安全开发威胁资源、业务场景、安全组件等基础安全开发数据共建共享，打造农信体系开发安全统一模型。遵循“合作共赢”思路，中心将持续输出安全能力，打造未来农信体系安全生态圈。

以上内容由李庆莉编辑整理。