洛阳证券公司联盟

【交易技术前沿】证券公司信息系统安全开发生命周期研究与实施 / 倪文亮

上交所技术服务2019-12-01 16:22:13



本文选自《交易技术前沿》第二十五期 (2016年12月)。

倪文亮
兴业证券股份有限公司

摘 要:随着互联网技术和“FINTECH”的兴起,信息技术在证券业务中发挥着越来越强的推动作用,越来越多的证券公司开始组建自己的开发团队,所开发的信息系统也从内部经营管理类系统逐渐扩展到为直接面向客户的系统,信息系统的安全开发生命周期就成为一个不可绕过的课题。本文通过对证券公司信息系统安全开发生命周期的研究提出了一个适合于证券公司的安全开发生命周期成熟度模型和层次化的安全开发管理框架,并结合兴业证券股份有限公司的开发安全管理经验,介绍了信息系统安全开发生命周期管理的实施。
关键字:安全开发生命周期、开发安全

一、安全开发生命周期的实施背景

(一)什么是安全开发生命周期

       信息系统开发的生命周期包括需求分析、设计、编码、测试、发布、运维等阶段,由于项目进度方面的问题,传统的信息系统开发很容易忽视安全控制,导致在各个阶段不断的引入风险,累积风险,导致信息系统在交付前已经存在大量的安全问题。安全开发生命周期的任务即将安全控制嵌入各个阶段中,在各个环节均降低安全风险,提升信息系统最终交付时的安全性。

(二)证券公司信息系统开发的特点

       证券公司信息系统开发存在着外包开发和自主开发之分。过去,绝大部分证券公司采用的是外包开发模式,证券公司的开发团队实际上只承担项目管理和需求管理的职能,具体的系统设计、编码等环节大多由外包公司来实施,证券公司对于软件开发过程的管控力度很弱,最多只能在需求环节提出安全需求,在测试环节进行一些上线前的安全检测,也谈不上安全开发生命周期管理。
       当今,越来越多的证券公司认识到外包开发的局限,开始组建或扩张自己的开发团队,采用自主开发的模式进行信息系统开发,需求、设计、编码、测试等环节均相对可控,信息安全在开发阶段即可深度介入。大部分证券公司的自主开发处于起步阶段,此时如有成熟的安全开发生命周期的管理方法借鉴,就不再需要盲目摸索,可体现出“后发优势”,还有利于培养开发团队的安全意识。但同时应该看到,证券行业的发展日新月异,无论是内部经营管理类信息系统还是直接面向客户的系统,均存在频繁迭代升级,需求变动频繁,项目周期紧,开发和安全团队的人手都很紧张的情况。因此实施和落地安全开发生命周期管理,也存在着一定的难度。
       综上,鉴于自主开发是未来证券公司信息系统开发的必然趋势和主要形式,本文主要专注于自主开发模式下信息系统发布前的安全开发生命周期管理。

(三)安全开发生命周期的目标

       将自主开发纳入安全开发生命周期管理的主要目标在于:

  1. 提升信息系统交付时的安全性,减少信息系统运维阶段的潜在风险,为信息系统运维团队“排雷”。
  2. 在安全贯穿到信息系统开发的整个生命周期中,通过良好的安全设计和预防性的过程控制措施,将风险识别和处置在萌芽期,避免在信息系统开发完成后安全才介入造成的效率低下和相互扯皮的弊端。
  3. 通过信息系统安全标准化使得信息系统安全所面临的威胁、已采取的控制措施、剩余风险均已知且可控,降低不确定性带来的潜在风险。
  4. 通过各个安全控制点和丰富的安全工具库,降低开发团队人员个人经验和开发习惯对信息系统安全的影响,降低信息系统安全对安全团队人员个人能力的依赖,使信息系统在交付时均能够达到稳定的较高的安全水平。
二、安全开发生命周期成熟度模型和层次化的安全开发管理框架

(一)业界的软件安全开发模型和方法

       目前,业界有一些软件安全开发模型,包括SDL、SAMM、CLASP等。SDL是微软的安全开发生命周期模型,提出了“5+2”个阶段和16项“必需”的安全活动,在需求、设计、实现、验证、发布等各个阶段都有相应的工具可以使用,比较适合于较大型的开发团队。SAMM是OWASP提出的软件保证成熟度模型,规定了“治理、构造、验证、部署”这4个软件开发过程中的核心业务功能和4个成熟度级别。CLASP是一个综合的轻量应用安全过程,具有30个特定的基于角色的活动,用于提升整个开发团队的安全意识。

(二)安全开发生命周期成熟度模型

       根据上述的开发模型和方法,结合证券公司信息化水平和信息系统开发能力的实际情况来看,可建立如图1所示的安全开发生命周期成熟度模型,分为自主化、专家化、标准化、服务化这4个阶段。

图1 安全开发生命周期成熟度模型

       自主化阶段,是安全开发生命周期成熟度模型中的最初级阶段,IT部门已经意识到开发安全的重要,对开发团队提出了一定的开发安全的要求,但尚未建立体系化的开发安全周期管理框架,信息安全团队未能在开发阶段就介入,系统开发安全完全依赖于开发团队或开发人员的个人经验,自主进行信息系统的安全设计和安全编码。自主化阶段中,信息系统开发完成交付时,其安全状况不可控,可能安全性很低,也可能较高。从实践中看由于开发团队更关注的是功能实现,因此这样的信息系统其安全性往往很低,只有在系统上线后发生了安全事件或者收到外部预警通告时,才会匆忙加固。处在这一阶段,信息安全团队完全是一个“救火队员”的角色,无比忙碌却看不到成效。
       专家化阶段,依赖于信息安全团队安全专家的能力进行安全设计,并在信息系统交付前后进行安全检测。在这一阶段,一般已经制订相应的管理制度和流程,信息安全团队开始初步介入开发,能够在开发工作开始前,协助开发团队共同分析业务需求,提出安全需求,给出安全设计和具体的安全方案、安全策略和安全架构,并在系统交付上线前通过安全检测工具进行安全检测、渗透测试等工作。此时,信息系统的安全开发已经得到了管理,信息系统上线交付前能够达到一定的安全性,大部分常见的高危漏洞和潜在风险能够被发现和处置。但在这一阶段,开发安全的效果仍然取决于信息安全团队的介入深度、团队成员的经验和能力。
       标准化阶段,是较专家化阶段更进一步的阶段,进入标准化阶段的标志是,信息安全团队选择适当的模型和方法,结合团队经验,形成不同威胁、不同场景下的标准化的安全设计模版和安全策略,并制订了标准化的安全设计规范、安全架构规范、安全编码规范、安全测试规范等。在信息系统开发前对威胁进行分析,选择合适的安全设计模版和安全策略,在编码期间依照安全编码规范进行编码,依照安全测试规范进行标准化的测试。在这一阶段已经初步实现了将信息安全贯穿到信息系统开发过程中,信息安全团队初步实现了化被动为主动。
       服务化阶段,安全团队与开发团队共同开发安全组件并封装为安全服务,供信息系统在开发时调用。在这一阶段,安全从支撑转变为服务,开发团队更专注于业务需求的实现,安全和开发实现了有效的融合。
       从证券行业的实践来看,目前绝大部分证券公司处在专家化的阶段,少部分达到了标准化的阶段,向服务化阶段迈进。从专家化阶段到标准化阶段的提升,需要安全团队从“被动规避风险”转变为“主动管理风险”,将经验通过总结、提炼形成标准。从标准化向服务化阶段的提升,核心在于安全组件的开发和封装,需要一定的开发工作,并且公司信息系统总体的架构应该能够支持安全组件的建立和应用。

(三)层次化的安全开发管理框架

       信息系统安全开发生命周期的落地,可参照如图2所示的层次化的安全开发管理框架。

图2 安全开发管理框架

  1. 安全保障。高效的组织架构和精干的人员、完善可落地的制度和流程、全面的安全意识宣导和培训、适当的安全绩效度量和考核,共同组成了保障安全开发生命周期的基础条件。
  2. 安全控制点。在安全开发生命周期中的各个环节设置控制点,包括安全需求、安全设计、安全编码、安全配置、安全测试、安全交付。在安全需求环节,安全团队协助开发团队,对业务需求进行安全评估,同时进行威胁分析和风险评估,梳理出系统的安全需求,纳入系统需求。在安全设计环节,需要根据安全需求,确定合适的安全方案、安全策略和安全架构。安全编码环节,要求开发团队按照既定的安全编码规范进行编码,并将安全方案、安全策略落地。安全配置环节,根据安全架构和安全基线规范,完成系统部署、配置和环境安全配置。安全测试环节,通过代码审计、安全检测、渗透测试等方法对系统进行安全测试,并对发现的问题进行加固。最后,将系统移交运维,并由安全团队在网络和安全设备上配置相关安全策略,实现安全交付。
  3. 安全工具库。包括威胁分析工具、安全设计规范、安全架构规范、安全编码规范、安全组件库、安全规则和策略、安全测试场景库、安全检测工具、安全配置工具、代码审计工具等,用于支撑上一层的各个安全控制点的控制工作。
三、安全开发生命周期的实施

       在信息系统生命周期中的需求分析、设计、编码、测试、发布、运维等阶段,均有不同的安全控制,这些控制的关键工作如下:

(一)威胁分析和风险评估

       威胁分析和风险评估是一种系统性、迭代式和结构化的安全分析手段,通过威胁建模、风险评估等方法,分析信息系统面临的威胁和存在的风险,以便为后续安全设计提供依据。
       STRIDE是业界一种较为主流的威胁建模方法,将威胁分为“欺骗”、“篡改”、“抵赖”、“数据泄密”、“拒绝服务”、“权限提升”这六大类,分别对应“可鉴别性”、“完整性”、“不可抵赖性”、“机密性”、“可用性”、“授权”等安全属性。风险评估有定性和定量两种方式,在尚未达到很高的成熟度之前,建议先从定性的方式入手。
       威胁分析和风险评估均有较为成熟的具体方法可以参考,但在实施过程中,应该它们的目的是为安全和架构设计服务,注意与本单位的实际情况相结合,不能过于追求形式上的完美,导致分析和评估结果与实际需要相脱节。

(二)信息系统分级分类

       信息系统的分级分类在传统的开发安全模型中很少提到,但从行业特性来看,是必须进行的一项工作。从安全角度来看,信息系统的分级分类能够有效的识别出重点系统、高风险系统,能够针对性的划分不同的安全级别和安全要求,有利于证券公司普遍不足的安全资源向重点系统、高风险系统倾斜,能够促进安全资源得到有效的利用。
       在实践中,由于系统的属性众多,不大可能将信息系统简单地定为“高风险”、“中风险”、“低风险”。应该在不同的维度对信息系统进行自评,接着得到系统在该维度下的定位。证券行业可以重点关注的几个维度包括:系统承载的业务类型、系统的用户范围和类型、系统中数据的类别、系统的实时性要求、系统的可访问区域和访问方式等,可对应到机密性、完整性、可用性等关键安全属性和后续的安全设计。
       一种信息系统分级分类自评表的示例如图3所示:

图3 一种信息系统分级分类自评表示例

(三)安全和架构设计

       在信息系统设计阶段,应该进行安全和架构设计。如果成熟度达到了标准化阶段,就可以参照信息系统的不同级别和类别,预先设定好安全设计规范模版,信息系统根据各维度下的分级分类,确定必须采用的安全机制和具体的安全策略。例如:商城类系统的客户注册环节必须采用手机验证码验证,验证码必须具有有效期、频率、总量控制,相关会话必须采用TOKEN机制等。应该注意到,架构安全也属于广义的安全范畴,因此必须将架构方面的问题一并考虑。
       在实践中,适宜采取循序渐进的方法。在实施初期,架构设计规范的粒度不宜过细,在系统自身的安全机制、架构、环境配置等方面确定必须达到的关键控制点,并确定该控制点的具体策略。再进一步,可以将策略根据不同的系统分级分类标准化为几个“套餐”,直接关联到对应级别的系统。一种安全及架构设计规范和策略的示例如图4、图5所示。

图4 一种架构设计规范示例

图5 一种安全策略示例

(四)实施阶段

       在编码阶段,安全团队应该提供安全编码规范,将规范嵌入开发团队自身的质量控制体系中,在进行代码质量检查的时候同时根据安全编码规范进行检查。
       编码完成后系统发布前的部署时,还应当注意依照安全配置规范完成包括主机、网络、监控等在内的环境安全工作。

(五)安全验证

       安全验证是检验前述安全控制有效性的手段,包括漏洞扫描、安全检测、代码审计、渗透测试等各种方式。
       代码审计通过自动化代码审计工具进行自动化检查,再配合安全团队根据安全编码规范和OWASP等最佳实践进行的审查。漏洞扫描、安全检测包括主机层的漏洞扫描,主机层、应用层、数据库层、网络设备等的配置基线检测,包括对应用的动态安全检测、逻辑安全检测等,在必要时可以请外部机构进行黑盒的渗透测试。

(六)开发安全组件库

       当自主开发达到一定的规模时,可以着手建立安全组件库,自行组织开发安全组件,或评估后使用开源的安全组件。如果实现了SOA架构,具有ESB等基础服务总线,还可以将安全组件作为服务挂在ESB上供信息系统调用,具体的安全策略配置也可以在ESB上集中进行。

四、展望

       自主开发是证券公司的必然趋势,信息系统安全开发生命周期是保障信息系统安全的重要抓手。我们将继续研究和实践信息系统安全开发生命周期管理,提高安全开发生命周期管理在各类开发场景和开发模式下的适用性,尤其是优化快速敏捷开发时的安全管理,推广移动开发安全设计规范,探索未来云环境下和DEVOPS、DOCKER等框架的融合,为提升证券行业信息安全水平贡献绵薄之力。

参考文献:

[1]吕晓强,张磊,汤志刚.信息系统开发全生命周期安全管理研究与实践[J].金融电子化,2016,8:75
[2] (美)霍华德(Howard,M.)(美)李普纳(Lipner,S.)著.李兆星,原浩,张铖译.软件安全开发生命周期.电子工业出版社,2008-1-1
[3]
[4] Mano Paul.OFFICIAL GUIDE TO THE CSSLP CBK.CRC Press,2014
[5]


 
免责声明


本公众号内容仅供参考。对任何因直接或间接使用本公众号内容而造成的损失,包括但不限于因有关内容不准确、不完整而导致的损失,本公众号不承担任何法律责任。如有问题请反馈至tech_support@sse.com.cn。

-------------------------- 上海证券交易所为证券公司、基金管理公司等市场参与者及相关行业机构提供交易技术支持与服务,包括日常交易技术支持、技术交流研讨、市场调查反馈、证券信息技术知识库、测试等服务。

点击"阅读全文"了解详情