原标题：信息系统生命周期生命周期安全管理体系实践与研究（一）

课题组:华泰证券、兴业证券、证券信息技术研究发展中心(上海)

课题主办人: 上交所技术有限责任公司 叶婧

课题承接方: 华泰证券、兴业证券

课题负责人： 张嵩 王玥

课题组成员：雷兵庄飞 吴佳伟 倪文亮 胡晓明 孙增 徐丹

第一章 信息系统生命周期生命周期安全管理背景和意义

一、 研究背景(一) 安全环境与威胁形式

随着互联网+热潮的不断升温互联网技术与金融行业结合越发紧密，Fintech、互聯网金融已经是金融行业发展的热点技术创新扮演着越来越重要的角色，越来越多的系统通过互联网为客户提供服务互联网金融快速發展的同时也面临诸多挑战，其安全形势仍不容乐观针对金融系统等国家基础设施的威胁环境不断变化，安全威胁的发展呈现出新的特征和形势如持续增长黑色产业规模和全业务链条，行业软件与供应链安全问题APT，内部犯罪和欺诈等随着《网络安全法》颁布，新等級保护国家标准出台强信息保护、客户金融安全和防范网络诈骗在金融行业的重要性进一步提升。

国内知名安全媒体FreeBuf(漏洞盒子)发布的《2016姩上半年金融行业应用安全态势报告》给出了证券行业应用安全态势：80%的漏洞是可以导致获取系统权限、获取数据的高危漏洞；80%的漏洞利用起来并不困难。

图1.1证券行业漏洞危害程度

图1.2证券行业漏洞利用难易程度

Report（DBIR）企业发现安全事件的时间往往滞后攻击者很多（数天、數月甚至更长），攻击者有足够多的时间来非法访问系统窃取数据。在DBIR2015收录的80000多起安全事件中2122起证实存在数据泄露，其中金融服务荇业,43%的安全事件在几天到几周内发现，38%的事件需要数个月甚至更长的时间才能发现63%的事件中，攻击者只需要花费几分钟甚至几秒钟就可鉯攻陷系统

图1.3国际金融服务行业发现、应对安全事件的时间统计

针对严峻的安全形势，大多数企业以传统的方式部署网络安全“防御”設备为主只有为数不多的企业实现了从项目可行性到部署，到持续运营的端到端方法根据英国的权威机构InformationSecurity Chaos》，通过对全球150名应用开发決策者进行调查后发现对应用安全的风险管理越早越经济--在运行阶段修复一个漏洞成本是在设计阶段修复同样问题的成本的30倍。

图1.4应用咹全的风险管理越早越经济

(二) 证券经营机构安全组织与管理现状

证券经营机构业务开展高度依赖于信息系统生命周期的稳定、安全运行伴随互联网和移动互联网的快速发展，传统信息系统生命周期的网络边界逐渐向互联网延伸导致所面对的外部威胁进一步增加；同时，茬现有信息系统生命周期的开发运维管理模式下系统的安全性并没有在系统初始阶段得到应有的规划，导致系统在运行阶段的弹性较差容易成为被攻击对象，影响系统的完整性和可用性

从证券经营机构安全管理来看，大多数证券公司专职安全人员只有1-3人，多数在系統运行管理条线下开展安全工作其工作与系统运行结合的较为紧密，与需求研发工作融合非常有限日常工作主要承担防火墙、安全检測、补丁管理、病毒管理等较为传统的网络安全工作，极少数大型证券公司有5名以上的专职信息安全人员但随着信息技术部门人员的扩張，安全团队人员占比却持续降低

另一方面，数据资产（客户数据、经营机构数据）已经成为证券经营机构的核心资产之一当前，业內普遍缺乏数据资产在信息系统生命周期全生命周期内保护机制行业内也缺少清洗的数据安全标准、操作指南和最佳实践。因此在系統运行阶段，利用系统在各阶段的漏洞批量获取客户或经营机构数据的事件日渐增多在破坏系统机密性的同时，严重影响经营机构的声譽和竞争力引发了客户纠纷。

在课题前期课题组对30家证券公司进行了调研，调研发现近80%的公司认为应用软件的缺陷和漏洞主要在其生命周期的需求、架构评审和编码阶段引入；近50%的公司认为漏洞修复周期为数周80%的公司认为是因应用软件修复难度大、影响原有架构、功能模块所致；60%以上的公司采用文本处理等原始工具来管理漏洞。

图1.5应用软件的缺陷和漏洞主要在其生命周期哪些阶段引入的

图1.7漏洞难以修複原因

一旦漏洞需要在部署上线后修复成本难以控制，同时针对威胁和脆弱性的改进空间相对较小安全改善的能力和灵活度受到了极夶制约，成为了企业业务安全的瓶颈而在实现阶段，甚至需求和设计阶段着手对安全活动进行管理可大幅降低实施成本，同时在控制措施的选择上也具有最大的灵活性

(三) 生命周期安全管理发展历史

微软为代表的厂商开始尝试在其公司内部针对其早期自有产品（主要是Windows操作系统）推行针对安全开发的生命周期理念（SDL），从2004年起微软首先应用于WindowsXP SP3的设计-开发-实现和发布后逐步成为公司级的主动性和强制性咹全政策并在业界推广，对微软操作系统安全性和保密性的提升起到了关键性的作用SDL是全面生命周期管理与最佳实践手段和工具相结合嘚产物，理论基于三个核心概念：教育持续的过程改进，和问责制其旨在减少应用软件的漏洞数量级和严重程度，其完整生命周期主偠阶段如下图所示：

图1.9安全开发生命周期（SDL）

（信息系统生命周期建设生命周期安全考虑）对生命周期理念在安全行业的推广和应用起箌了不可忽视的作用。

图1.10企业软件保证成熟度模型（OpenSAMM）

证券经营机构受制于IT人员规模专职安全人员非常有限，在安全上的人力投入无法囷互联网公司相比但却又和互联网公司面临一样的安全风险，因此形成能够良好运转的安全管理体系，将有限的安全资源投入到最有價值的领域对大多数证券经营机构都有着非常重要的现实意义

本课题研究着眼于信息系统生命周期的全生命周期各阶段，借鉴国内外成熟可靠的标准、方法和实践分析行业信息系统生命周期的开发和运维现状，以漏洞管理为主线以风险识别、评价和跟踪为手段，为证券行业探索一套可行性高、实操性强、注重实效的信息系统生命周期生命周期安全管理体系将信息安全的要求、标准和实践融入到系统苼命周期的各个阶段，主动防御外部威胁、有效的管理漏洞实现经济、合理管理安全风险的目标。

1.研究国际上多种安全生命周期管理方法论结合华泰证券、兴业证券等有代表性的证券经营机构在信息系统生命周期安全生命周期管理的经验，总结适用于证券行业特点、具備行业推广性的信息系统生命周期生命周期安全关键安全控制措施框架和对应的适合证券行业业务特点的最佳实践和演进路线规划。；

2.結合行业安全要求提出建设系统开发安全需求库的最佳实践，识别行业常见系统共同关心的功能性和非功能性通用安全需求并对其工程化实践进行了探讨。

3.提出在开发活动中广泛使用的各类开源组件的安全管理要点有效降低开源组件在后期运营活动中所产生的安全风險及维护成本。

4.通过对DevSecOps框架及理论的研究结合证券行业的特点，探索出了一种适合行业现状的、可以落地的DevSecOps实践方法并通过实践，证奣了该方法的实效性

5.结合安全威胁情报，提出适用于证券经营机构的安全分析参考模型和方法梳理面向经营机构的10个常见安全分析场景，为行业经营机构安全分析能力建设提供最佳实践参考

6.针对受攻击可能性较高的涉互联网资产，梳理并提出互联网资产管理、漏洞运營管理和渗透测试实践并对于信息资产的安全配置基线配置及管理流程、平台组件版本标准化提出实践建议。

7.引入软件安全成熟度评估模型为评估软件系统安全保障能力水平提供给最佳实践，并以此为基础规划合理、可以实现的演进路线为管理层提供安全能力度量、咹全投资收益、安全有效性度量等关键指标的量化数据及行业对标依据。

第二章 信息系统生命周期生命周期安全管理框架及关键活动一、信息系统生命周期生命周期安全管理框架(一) 信息系统生命周期生命周期安全管理定义

将安全活动内嵌于信息系统生命周期开发的全生命周期通过与项目相结合的重点安全活动，识别、评估、跟踪项目在各阶段存在的信息安全风险提出缓解方案建议，以达到合理、有效保護公司信息资产的目标

(二) 信息系统生命周期生命周期安全管理框架

信息系统生命周期生命周期安全管理服务，全面涵盖了系统开发生命周期的各阶段包含了可行性、立项、需求、架构设计、编码、测试、上线、运行和下线等阶段。每个阶段有一个或多个安全活动来缓解咹全问题公司可对当前安全成熟度进行评估，根据评估结果全部采用，或进行相应的裁剪后使用且在整个系统开发生命周期中应制萣配套的安全制度和进行必要的安全培训等事项。

在实践信息系统生命周期生命周期安全管理体系后应定期进行安全成熟度评估，以衡量提升度、分析与先进组织在软件安全实践中的差距制定下一轮的安全建设计划，同时可向管理层展示各方面的实质性进步并证明安铨投入的实际成效，争取管理层对信息安全的长期支持为准确有效地进行安全成熟度评估，报告第三章详细介绍了安全成熟度评估实践方法

图2.1信息系统生命周期生命周期安全管理框架

二、信息系统生命周期生命周期安全管理关键活动(一) 可行性阶段

参照系统的行业监管与匼规要求、国家与行业标准规范、公司安全策略与标准对安全可行性进行评估。给出评估结论、提示合规监管要求以及存在的安全风险、給出等级保护定级与初步安全投入建议、并提出后续注意事项

对供应商的安全防护能力与水平进行评估，并将供应商的安全评估结果作為选择供应商的重要依据

参与合同安全条款的制定（涉及外包或合作开发的项目应签订正式的合同，合同中应包含保密性、信息安全以忣隐私保护等方面的条款）

项目立项完成后，参与重要事项申报中预算的编制确保安全预算投入满足建设要求；成立包括安全人员在內的项目组，安全人员应协助系统负责人制定项目安全管理计划

创建安全风险档案，记录上线系统在其生命周期阶段部署、服务、功能鉯及安全视角上问题、漏洞、历史整改情况便于项目组及时了解和确认系统当前的安全风险姿态。

安全人员根据项目组确定的IT需求进行汾析对安全需求进行完整识别，安全需求的识别范围包括但不限于：行业监管与合规安全要求、公司安全策略与标准、行业安全实践经驗等依据项目敏感数据分级分类，系统访问资源对项目进行安全保障定级。

分析业务需求的同时提出适合系统的安全需求是本环节最偅要的目标项目组参照定级的安全需求标准进行分析，与业务人员、安全人员进行沟通研究报告的第四章从构建和使用安全需求分析庫方面阐述了安全需求在需求分析阶段的实践

安全人员与项目组充分沟通后，对确定的安全需求应写入正式的需求文档形成安全需求说奣书。

安全人员根据项目情况与项目组共同制定项目上线需要交付的安全基线清单，清单中明确各阶段的交付物

(四) 架构与设计阶段

受攻击面是指应用软件任何可被人或其他程序访问的部分。而针对其进行分析的目的是为了减少应用和数据暴露在不可信用户面前的数量受攻击面将会定位各类数据的进入点，如网络输入/输出文件输入/输出等，同时更进一步针对进入点的数据类型、信道和协议、访问方法囷权限进行尽可能完备的分析为后续的威胁建模奠定基础。

威胁建模的核心是根据业务功能确定和了解各项业务功能的风险详细了解烸个业务功能实现背后的威胁和可能的攻击，推进开发团队业务实现的基础上融入安全功能使风险管理的决策更加与业务过程相协调。

Modeling）两个主要手段对业务进行数据流层的呈现和分析，将数据流以及其要素转化成威胁在应用系统的立足点最终在此基础上形成明确的基于业务流程的安全设计说明书。

4.运行环境与部署架构

明确开发测试及生产环境架构及相应的部署方案对开发测试及生产环境应进行标准化部署，报告第九章详细阐述了平台组件如何做到标准化配置

按照安全编码规范要求进行安全编码，以减少不规范的编码所造成的安铨缺陷

2.源代码滚动安全测试

安全人员制定代码检查（白盒）测试通过的标准，对编码阶段发现的安全问题提供技术支持

系统开发人员應对完成的单元代码进行检查，采用代码扫描工具进行检查,对检查中发现的代码问题应及时纠正对修正的代码进行验证确保问题得到解決，对代码检查结果与解决过程应进行记录以便后续检查跟踪。

为提高源代码滚动安全测试效率可通过工具链自动化实现安全测试自動化地无缝嵌入到流程中，具体可参照报告第六章DevSecOps实践内容

利用开源组件安全扫描工具对项目使用的开源或第三方组件进行扫描，输出開源组件安全扫描报告报告第五章着重分析了开源组件的安全风险以及开源组件的安全管理和使用。

源代码审计（Code Review后简称为代码审计）是由具备丰富的编码经验并对安全编码及应用安全具有很深刻理解的安全人员，根据一定的编码规范和标准针对应用程序源代码，从結构、脆弱性以及缺陷等方面进行审查

按照安全基线指南，对测试环境操作系统、网络设备、web及中间件等进行加固

动态应用安全测试（DAST），使用动态安全扫描工具对测试环境进行主机层以及web应用层安全扫描输出动态安全测试报告。

交互应用安全测试(IAST)使用交互式安全掃描工具，对测试环境进行web应用安全扫描输出交互式安全测试报告。

在项目进入里程碑阶段冻结版本后，进行完整的软件包（包括源玳码、配置文件、描述文件、资源文件、引用的第三方库等）安全扫描检查

对等待上线的生产环境，进行安全基线加固安装补丁、杀蝳软件等。报告第九章对安全配置基线的自主化、部署、验证和定期检测等内容进行了说明

2.安全验证与渗透测试

在上线系统部署完成之後，对外正式提供服务之前项目组应及时更新应用系统目录信息，提供完整的软硬件部署配置信息并由安全测试人员对上线系统进行咹全验证与渗透测试，包括：基线配置检测、主机层漏洞扫描、Web应用层扫描和渗透测试等

3.剩余风险评级与接受

安全人员根据安全风险档案，审视所有识别出的问题和风险确保问题和风险都得到正式的关注、修正或接受。对残余的安全问题及风险进行评估制定后继改进計划，对是否上线进行决策

提前申请端口开通，防火墙策略等IT权限安全人员根据安全风险档案，进行IT权限开通（如果没有安全风险档案项目组需要提交安全人员进行评估）。

1.持续漏洞与补丁管理

安全团队根据安全事件（出现重大漏洞、补丁更新）通知相关系统维护囚员。系统维护人员负责信息系统生命周期的日常安全维护工作(定期更新密码检查防病毒等)；收到安全团队的漏洞事件通知后，及时处置发现的安全问题；及时更新系统的安全补丁报告第八章对发现漏洞后如何进行漏洞管理进行了介绍。

2.持续威胁监控与运营

安全团队定期按照合规与基线要求对信息系统生命周期进行安全扫描，扫描发现的安全问题并及时通知各信息系统生命周期维护人员进行处置

建竝与维护互联网开放端口清单，并定期梳理开放的互联网端口信息系统生命周期维护人员应定期确认系统的互联网开放的端口使用情况，对未使用的端口及时申请关闭

使用威胁情报并对各个源的数据进行自动关联分析，全面可视化资产、漏洞、网络攻击和已攻陷态势為事件响应的指挥者提供基于优先级的信息，以采取合理的应对措施报告第七章详细描述了安全分析与情报应用的内容。

将入站访问控淛为显著技术特征的上一代被动“规则关卡”防护向更为立体和纵深更长的主动“防御阵地”演进报告第十章介绍了网络安全被动“规則关卡”到主动“防御阵地”演进的相关内容。

保护数据防止数据泄露以及保护系统业务免受安全威胁，报告第十一章重点关注了数据囷业务的安全防护

信息系统生命周期的变更和升级需求，应严格按照变更管理流程进行实施涉及到安全控制措施变更或者信息系统生命周期重大变更时应及时通知安全人员进行安全评估。

信息系统生命周期因业务或技术变化等原因终止运行时信息系统生命周期维护人員应及时提出下线申请，并经业务部门审批后实施系统下线。

安全人员对下线进行安全评估在系统下线完成之后，评估存在的风险、遺留注意事项关闭安全风险档案。

3.数据安全清理与归档

系统维护人员在对系统进行下线过程中须记录设备、介质和信息的处理、信息转迻、暂存和清除的过程包括参与的人员，转移、暂存和清除的方式以及目前信息所处的位置，并提交给安全人员进行评估确认

信息系统生命周期终止运行的处理过程中，须采用安全的方法清除要终止的信息系统生命周期中的数据确保迁移或废弃的设备、介质内不包含敏感数据。须按照要求对需要保留的相关数据进行转存并记录转存过程。同时应清理设备上与信息系统生命周期运行有关的配置避免产生残余安全风险。

安全团队对下线系统的防火墙端口等IT权限进行回收

第三章 证券行业软件安全成熟度实践一、软件安全成熟度起源囷目标

20世纪70年代初，由于软件系统的规模和复杂度的增加软件的可靠性问题变得越发突出。软件研究人员开始关注软件系统的质量属性陆续制定了一系列质量控制相关的国际标准【1】，如CMM/CMMI、ISO/IEC9000、ISO/IEC15504、ISO/IEC12207等出发点是将软件开发视为一个过程，从而对软件开发和维护进行过程监控保障软件产品的质量。但并没有将软件的安全性做为软件产品的质量标准之一标准中也没有包含相应的安全性目标和活动。因此┅个软件企业即使达到了很高的软件成熟度（比如，通过了CMMI5级评估）也无法证明其开发的软件具有足够的安全性

20世纪90年代中后期，随互聯网的发展软件系统互联与开放性增强，由于软件漏洞导致的安全事件以及造成的资产和服务功能损失急剧增加软件安全从传统的计算机安全和网络安全中分离出来，成为一门独立的学科开始发展各种软件安全开发理论、实践和标准相继推出，包括：Cigital

运用上述这些安铨成熟度模型可以达到以下目标：评估组织在软件系统安全保障能力上的现状和水平，分析与组织业务目标期望和业界平均安全水平的差距

8.根据组织的业务目标，综合考虑资源情况和信息系统生命周期开发成熟度等限制因素规划合理、可以实现的努力方向和演进路线。

9.以统一的标准定期评估组织的安全能力，向管理层展示各方面的实质性进步并证明安全投入的实际成效。争取管理层对信息安全的長期支持

10.定义并持续改进组织所采取的安全措施，形成可以执行的安全项目计划

二、软件安全成熟度评估方法

软件安全构建成熟度模型（BSIMM）是一种描述性的模型，由Cigital公司研究与维护通过量化多家不同企业的实际做法，发现共同点和不同点帮助其它组织规划、实施和衡量其软件安全计划。

2008年发布了BSIMM第1版对9家公司开展了调研和常见安全活动的识别，并基于软件安全框架对这些活动进行了组织和分类

2016姩发布了BSIMM第7版【2】，删除了数据超过2年的13家公司生成了涵盖95家公司的数据库。

2017年发布了BSIMM最新版第8版【3】，删除了5家公司生成了涵盖109镓公司的当前数据库。最新的数据包括了：金融服务机构（47家包括：美国花旗银行、美国银行、摩根大通、富达投资等著名公司）、独竝软件供应商（38家）、医疗卫生（17家）、云计算（16家）、物联网（12家）和保险（11家）。

BSIMM采用软件安全框架（SSF）和活动描述来提供一种共哃语言以解释软件安全中的关键点，并在此基础上对不同规则、不同领域、采用不同术语的软件计划进行比较

以BSIMM的软件安全框架分为4个領域（domain）:包括治理、智能、SSDL（安全软件开发生命周期）接触点和部署。每个领域又各分三项实践（practice）共形成12项安全实践。

图3.2BSIMM软件安全框架领域和实践

对于每个实践会根据统计数据给出多数公司都在从事的主要安全活动，且根据被调查公司参与安全活动的占比量排名将咹全活动分成1，23级。如下图所示的软件环境实践中的安全活动和分级

图3.3安全实践中的活动和分级（BSIMM8）

上图中值得注意的是SE3.4（使用应用嫆器）活动，是在BSIMM7中新出现的也就是说，BSIMM中的活动并不是静态的会反映出不同时期安全关注点的新变化。BSIMM8中包括了113项活动

而对每一項活动，BSIMM也给出了指导性解释如SE1.1，1.2：

图3.4活动指导性解释

对某一公司按113项活动打分，并以某实践为单位进行合并和正规化形成0-3.0的得分區间，做为某实践的最终成熟度指标并可以以蜘蛛图的方式与行业做横向差距对比或进行自身纵向对比。（但是BISMM公开文档中并没有提供具体的评分过程和打分标准，而是做为商业服务形式提供）

图3.5某公司成熟度纵向对比蜘蛛图

OpenSAMM是一种专门度量软件安全成熟度的开放式、规定性参考模型。由OWASP组织开发和维护2009年发布1.0版，2016年3月发布1.1版2017年4月发布了1.5版。相对1.0版1.1版和最新的1.5版改进与新增核心模块、指南模块、快速启动指引模块，并提供了自测评工具相应的owasp 资源等辅助工具【4】。

OpenSAMM将软件开发分解成4个通用的核心活动（称为“业务功能”）即：治理、构建、验证和部署。对每一个核心活动定义3个安全实践这些安全实践覆盖了软件安全保障所有相关领域。在每个安全实践下定义了三个连续的目标，描述了组织如何按时间顺序来提升安全实践

每一实践都有对应的三个成熟度级别：

1.0: 默认的起点，表示实践没囿开展

2.1级：对实践有基本的理解，以自由的方式开展实践

3.2级：提升了实践的效率和/或有效性。

4.3级：大范围全面掌控实践

OpenSAMM对于每一级嘟定义了目标、活动、期望的结果（产出物）、成功度量指标、成本、干系人员职责和相关的其它级别：

图3.8实践分级、目标和活动

图3.9活动、评估、结果、成功度量指标和成本

据公开报道，截止2017年4月只有13家公司(包括：Dell，HPFortify宣称采用了OpenSAMM方法【5】。而OWASP官方站点上并没有提供全球視角的、各行业平均成熟度水平报告这样，就对横向比较带来的困难

1994年4月，美国发起约60个厂家参与，启动了称为“系统安全工程能仂成熟度模型”的项目通过对安全工作过程进行管理的途径，将系统安全工程转变为一个完好定义的、成熟的、可测量的学科【6】1996年10朤，第一版正式推出1999年4月发布第二版，后成为国际标准（ISO/IEC 21827）【7】至今SSE-CMM描述的是，为确保实施较好的安全工程一个组织的安全工程过程必须具备的特征。其描述的对象不是具体的过程或结果而是过程中的一般实施。主要涵盖以下内容：

1.SSE-CMM强调的是分布于整个安全工程生命周期中各个环节的安全工程活动包括概念定义、需求分析、设计、开发、集成、安装、运行、维护和更新。

2.SSE-CMM应用于安全产品开发者、咹全系统开发者及集成者还包括提供安全服务与安全工程的组织。

3.SSE-CMM适用于各种类型、规模的安全工程组织

SSE-CMM模型中大约含60个基础实施，汾11个过程域这些过程域覆盖了安全工程的所有主要领域。与CMM相似SSE-CMM模型也有五个能力水平，从低到高排列如下：

（1）级别1“非正式执荇级”。这一级别将焦点集中于一个组织是否将一个过程所含的所有基础实施都执行了

（2）级别2，“计划并跟踪级”主要集中于项目級别的定义、计划与实施问题。

（3）级别3“良好定义级”。集中于在组织的层次上有原则地将对已定义过程进行筛选

（4）级别4，“定量控制级”焦点在于与组织的业务目标相合的度量方法。

（5）级别5“持续改善级”。强调必须对组织文化进行适当调整以支撑所获得嘚成果

图3.10安全工程组织的成熟度级别

SSM-CMM模型及其评价方法可以达到以下目的：

1.将投资主要集中于安全工程工具开发、人员培训、过程定义、管理活动及改善等方面。

2.基于能力的保证也就是说这种可信性建立在对一个工程组织的安全实施与过程的成熟性的信任之上的。

3.通过仳较竞标者的能力水平及相关风险可有效地选择合格的安全工程实施者。

虽然关注SSE-CCM的组织大多是提供安全产品或安全服务的专业信息安铨公司但SSE-CMM标准的思想，对于一般软件（如证券行业软件）的研发和运维各阶段的安全活动同样具有指导意义。另外对于证券行业大量采用的外购系统或供应商定制的软件产品，往往没有强制性的软件安全测评标准和结果而通过运用SSE-CMM标准对供应厂家或供应商的安全能仂比较，也可以间接完成对具体产品的安全性对比

三、证券行业软件安全成熟度评估实践

相对于国际国内先进软件开发组织而言，国内證券行业软件质量和研发成熟度水平普遍较低多数证券公司在信息安全领域中仍然重点投入于传统的主机安全和网络安全方面，而对于軟件安全方面的关注度普遍低投入少，缺乏战略规划在此状况下，进行软件安全成熟度评估工作的主要目的包括：

1.从公认的软件安全領域维度评估自身软件安全现状

2.分析与先进组织在软件安全实践中的差距。

3.制定提升计划和演进路线争取信息技术部门的认同和公司管理层支持，形成公司级应用安全战略规划

4.定期评估，以衡量提升度制定下一轮的软件安全建设计划。

华泰证券于2015年起正式确立了軟件安全计划。在启始阶段首先进行了软件安全成熟度评估，并以此为基础与国际金融行业平均水平做了定性的比较，在综合考虑公司业务目标、软件开发水平、人员能力等因素后确定提升目标，分解行动计划并以项目的形式执行迭代。之后每年做一次评估，展礻取得的成效分析差距，确定下一轮迭代目标和行动方案

(一) 评估方法的确定

与软件安全，特别是软件开发安全相关度比较高的评估方法是上节中介绍的BSIMM和OpenSAMM相对而言BSIMM的社区活跃度高、参与的公司多，数据更新较快评估结果认同度高，说服力强

2016年按BSIMM6标准对华泰证券软件安全现状进行了第一次摸底性评估。

2017年中采用BSIMM7对4个领域（Domain），12个实践(Practice)113项活动（Activity）对华泰证券2016年软件安全状况进行评估，并做差距分析、制定行动计划预计2017年期望达到的成熟度结果【8】【9】。

图3.11华泰证券软件安全成熟度评估

(二) 活动进一步分解

在评估活动中我们注意箌BSIMM7共有113项活动，但关于每一项活动的描述抽象度仍然较高对此活动直接进行评价仍然有比较大的不确定和模糊性。为此我们根据自己嘚现状和关注点，进一步划分了三个、可清晰确定完成度的子活动这样共形成了339项子活动。

以治理域-战略与度量实践- 一级活动（4项）为唎（表3.1）：

在实际评分中BSIMM公开文档中并有没提供可操作的活动评分标准。我们参考了OpenSAMM的活动和实践评分规则在考虑活动执行的完整度哃时，加入了对活动完成质量的度量

每个实践分为Level1、Level2、Level3共3级，每级满分1分实践得分为3级得分总和，满分为3分

每一级分为多个活动（Activity），每个活动满分1分每一级得分为活动得分的平均分。

每个活动进一步拆分为3个子活动(Sub Activity)活动得分为子活动得分的平均分。

子活动得分按照两个维度由人工(安全团队)进行评价：

1.完整度（Completeness）：该活动是否进行进行的完整程度；

2.质量（Quality）：该活动的质量评价。

每个纬度评价汾为3级：0、0.5、1分别对应完整度的低、中、高和质量的低、中、高。

子活动的得分具体计算公式：子活动得分= 完整度得分* 质量得分；

子活動存在4个评价分：0、0.25、0.5、1

举例：以战略与度量实践为例。

第一步：计算第一级活动【SM1】的第1项活动【SM1.1】得分先人工评价各子活动的得汾，如SM1.1.1（发布并维护白皮书）实际情况是，2016年底安全团队已经按计划发布了公司的信息安全状况白皮书完整性（score I）得分为1.0，但对某些議题的论述不尽详细、专业因此质量得分0.5 (score

第二步：重复以上步骤，得出其它三个活动即：【SM1.2】【SM1.3】和【SM1.4】的活动得分分别为：0.5，0.和0.25㈣项活动平均得分(0..5+0..25)/4=0.3125 成为第一级活动【SM1】的得分。

第三步重复以上两步，计算出另两级活动的得分为：【SM2】为0.【SM3】为0.。

第四步将SM三级活动得分相加即为战略与度量实践【SM】的评分：【SM1】+【SM2】+【SM3】=0...7875。

第五步重复以上四步，可以得出12个实践的评分

表3.4安全实践总分，纵向與横向对比

从表3.4中可以看出华泰证券2016年软件安全成熟度较2015年有明显提升，主要提升领域包括：战略与度量(SM)、遵从与策略(CP)、标准要求(SR)、软件环境（SE）和配置与脆弱性管理（CMVW）但是与全球平均水平和国际一线金融公司相比还存在较大的差距。特别是在安全测试（ST）、威胁建模（AM）两个实践上存在明显不足究其原因，这两个实践的活动一方面对安全专业人员的能力要求比较高另一方面也需要深入理解应用軟件的架构和实现方案，门槛相对比较高花费时间和精力较多。短时间内多数证券公司也无能力开展相应的活动。

根据差距分析结匼实施的成本和收益，可以确定下一年度可行的改进方向和行动计划(表3.5)并预测2017年底可能达到的成熟度效果（表3.4）。

注意：由于该报告篇幅较长将分多期推送。