信息安全审计下的CMMI的研发

信息安全审计下的CMMI的研发

信息安全管理体系(InformationSecurityManagementSystem,以下简称为ISMS)和能力成熟度模型集成(CapabilityMaturityModelIntegration,以下简称为CMMI),是当前较为流行的并被大多数软件企业普遍接受和引入的认证体系。其中ISMS是按照ISO/IEC27001标准《信息技术安全技术信息安全管理体系要求》的要求进行建立的,要求组织机构单位制定信息安全管理方针和策略,采用风险管理的方法进行信息安全管理计划、实施、评审检查、改进的信息安全管理执行的工作体系;CMMIDEV2.0是美国卡耐基梅隆大学软件工程研究所(SoftwareEngineeringInstitute,SEI)在2018年推出的最新软件过程改进模型,着力强调高层全程参与以提升企业能力,涵盖了软件研发过程的20个实践域,是一个软件、产品和系统开发的优良实践过程改进模型,能够全方位指导组织提升绩效。当前组织在导入这两个体系时,往往将其视为独立的系统分别实施,一方面加大了企业导入的工作量和成本,另一方面也不利于组织在企业中推广和实施。但事实上ISMS中关于权责分离与访问控制、外包管理、安全需求分析、安全设计与研发、安全测试与验收,变更控制等条款的要求都与CMMI的部分实践高度相关。如何将这两个体系更好的进行融合,既能满足ISMS的审计要求,同时也能达成CMMI实践的要求并同时提升组织流程的一致性是业界一直关注的焦点问题,也是本文会阐述的重点。

1ISMS与CMMI的对应关系

按照ISMS管理体系的要求,本文整理了CMMI相关条款与之对应的实践域,从软件研发的角度而言,我们把两者之间的对应关系分为需求、设计编码与集成、测试与验收、配置管理与变更、外包管理、风险管理、治理(GOV)和过程资产开发共八个大类,如表1所示。

2基于ISMS要求的CMMI研发流程调整

2.1行动能力域。(1)ISO27000的条款4.2理解相关方的需求和期望和A.14.1.1安全需求分析和规范这两个条款要求识别信息安全管理体系的相关方及他们对信息安全相关的要求(其中包括法律,法规要求和合同义务),在当前CMMI2.0体系的实践域需求开发和管理(RDM)中有挖掘需求的实践要求,需要在需求开发和管理的过程中增加识别信息安全需求的活动,并在输出的模板调研记录和需求规格说明书中增加信息安全的需求章节的描述。(2)ISO27000的条款A.14.2开发和支持过程中的安全要求确保在整个信息系统生命周期中的信息安全设计与实施。在当前CMMI2.0体系的实践域技术解决方案(TS)中的活动中增加安全设计活动,并在输出的模板概要设计、详细设计增加基于信息安全需求进行设计的章节,在开发管理过程中增加安全编码规范和编码过程中对代码进行安全审计。(3)ISO27000的条款A.14.2.7外包开发中要求组织宜管理和监视外包系统开发活动,在当前CMMI2.0体系的实践域供方协定管理(SAM)中有针对供应商和供应商的绩效进行监视和评价,需要增加对供应商的安全管理的监控,对供应商的项目管理过程中的安全性进行监控。(4)ISO27000的条款A.14.2.8系统安全测试、A.14.2.9系统验收测试要求在开发的过程中,必须测试功能的安全性、在建立新系统,升级系统和更新版本时,必须建立验收测试程序和相关标准。在当前CMMI2.0体系的实践域验收和确认(VV)中需要增加独立的安全测试规范与安全测试模板。并输出:安全测试方案,安全测试用例,安全测试报告。(5)ISO27000的条款A.14.3测试数据要求确保测试数据的安全,需要根据数据的保密级别进行相应的处理。如需要保密的数据需要进行脱敏处理。当前CMMI2.0体系的实践域验收和确认(VV)中测试管理规范中增加对测试数据的管理规则。

2.2管理能力域。在ISO27000的条款8.2和8.3条款是针对信息安全的风险进行评估和处理,在A.6.1.5项目管理中的信息安全中特别强调在项目研发过程中要在项目管理中考虑信息安全的风险。在信息安全管理体系中识别风险需要考虑:资产价值,弱点、威胁。资产价值:首先识别资产,软件类别(重要软件、一般软件),处理的数据(绝密,机密、内部数据、公开数据)等。再次识别资产的(完整性,保密性和可用性)来计算出资产价值以识别重要资产。弱点库:例如缺乏软件分发管理机制、缺乏软件开发/采购安全保障机制、程序设计漏洞、缺乏漏洞管理机制威胁:例如蓄意破坏/篡改、非授权访问/使用、数据丢失、操作失误当前CMMI2.0体系要求中,并未对安全风险进行明确要求,为了满足ISMS的审计要求,需要在风险与管理机会实践域中定义流程时,将对安全风险的识别作为必需的选项,并在模板中明确标识需要识别安全相关的风险,修改对应风险评估参数为:资产价值、弱点、威胁以此来计算风险值,其计算公式为:风险值=资产价值×弱点值×威胁值。

2.3实现能力域。ISO27000的条款的A.14.2.3运行平台变更后对应用的技术评审、A.14.2.2系统变更控制规程、A.14.2.4软件包变更的限制要求针对变更管理有流程来进行控制、A.14.2.3运行平台变更后对应用的技术评审都要要求对变更进行影响分析并执行适当的评审。当前CMMI2.0体系的实践域配置管理(CM)要求过程已经明确定义了变更的管理过程和CCB组织的建立。需要特别指明CCB的成员应该包括公司的信息安全管理员,以平衡变更是否会引起信息安全方面的问题。ISO27000的条款A.8.2信息分类、A.9.4.5程序源码的访问控制要求按照不同的信息分类级别来进行文件和源代码的访问管理。当前CMMI2.0体系的实践域配置管理(CM)有目录角色的访谈权限列表,需要增加基于文档的秘级来进行权限列表的分配,以控制未授权的访问。

2.4提高能力域。ISO27000的条款A6.1.2职责分离,要求有冲突的职责和权限应被分开,减少对资产未经授权或无意的修改与误用。当前CMMI2.0体系的实践域治理(GOV)要求过程活动中职责分明,因此在该要求的基础上需要进一步的识别是否有冲突的职责和权限需要特别区分并识别。ISO27000的条款A.14.2.6安全的开发环境和A.12.1.4开发,测试和运行环境的分离:要求应建立并适当保护开发环境安全,并集成涵盖整个系统开发周期的工作,分别建立对应的测试和运行环境。当前CMMI2.0体系的实践域过程资产开发(PAD)中要求组织建立组织级和项目级的标准工作环境,因此需要在标准工作环境中特别分离出标准的安全开发环境、测试环境和运行环境,指导有安全开发的项目来进行环境的建设。

3小结

本文针对ISO27000的审计条款要求,结合基于CMMI建立的研发制度来进行研发管理制度改进,以满足公司信息安全管理的要求和信息安全管理体系审计要求的同时提升研发管理的信息安全。将这两种制度在一定的程度上做融合以提升企业在同时导入这两个体系时实施的效率和实施的有效性。

作者:蒲冬梅 单位:广州赛宝认证中心服务有限公司