软件安全开发成熟度评估技术规范 征求意见稿_第1页
软件安全开发成熟度评估技术规范 征求意见稿_第2页
软件安全开发成熟度评估技术规范 征求意见稿_第3页
软件安全开发成熟度评估技术规范 征求意见稿_第4页
软件安全开发成熟度评估技术规范 征求意见稿_第5页
已阅读5页,还剩56页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1T/ZHSIAXXX—XXXX软件研发安全成熟度评估技术规范本标准定义了软件安全开发成熟度的评估模型和评估体系,从54个基本安全实践的执行频率、覆盖度及执行质量进行量化评估,为软件研发安全成熟度评估及自主提升软件研发安全成熟度水平提供标准和依据,适用于:a.第三方对软件研发单位开展软件研发安全成熟度评估认证;b.软件研发单位自主提升软件研发安全成熟度水平。2.规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,标注日期的引用文件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。GB/T25069-2010信息安全技术术语GB/T29246-2017信息技术安全技术信息安全管理体系概述和词汇GB/T19000-2016质量管理体系基础和术语GB/T20261-2020信息安全技术系统安全工程能力成熟度模型GB/T28458-2020信息安全技术网络安全漏洞标识与描述规范GB/T24363-2009信息安全技术信息安全应急响应计划规范3.术语和定义GB/T25069-2010、GB/T29246-2017、GB/T19000-2016、GB/T20261-2020、GB/T28458-2020、GB/T24363-2009界定的以及下列术语和定义适用于本文件。3.1.软件生命周期softwarelifecycle软件产品从构思开始到软件停止使用为止的时间周期。软件生命周期在组织中典型地包括:需求阶段、设计阶段、实现阶段、测试阶段、部署阶段或发布阶段、操作和维护阶段,有时还包括销毁阶段。2T/ZHSIAXXX—XXXX3.2.软件研发安全softwaresecuritydevelopment识别软件生命周期中潜在的安全威胁,对信息和数据进行保护的一组技术状态管理活动。3.3.保密性confidentiality使信息不泄漏给未授权的个人、实体、进程,或不被其利用的特性。[来源:GB/T25069-2010,2.1.1]3.4.完整性integrity准确和完备的特性。[来源:GB/T29246-2017,2.40]3.5.可用性availability已授权实体一旦需要就可访问和使用的数据和资源的特性。[来源:GB/T25069-2010,2.1.20]3.6.安全开发能力securitydevelopmentcapability组织在组织建设、制度流程、技术工具以及人员能力等方面对安全开发的保障。3.7.能力成熟度capabilitymaturity对一个组织有条理的持续改进能力以及实现特定过程的连续性、可持续性、有效性和可信度的水平。3.8.能力成熟度模型capabilitymaturitymodel对一个组织的能力成熟度进行度量的模型,包括一系列代表能力和进展的特征、属性、指示或者模式。3.9.安全过程securityprocess用于实现某一安全目标的完整过程,该过程包含输入和输出。3T/ZHSIAXXX—XXXX3.10.基本实践basepractice实现某一安全目标的安全开发相关活动。3.11.安全域processarea实现同一安全目标的相关安全开发基本实践的集合。3.12.基础实践foundationpractice在评估中用于不能清晰界定属于某一安全安全域而重要且基础的安全开发相关活动。3.13.评估assessment对于某一产品、系统或服务,对照某一标准,采用相应的评估方法,以建立合规性并确定其所做是否得到确保的验证。3.14.过程process利用输入实现预期结果的相互关联或相互作用的一组活动。[来源:GB/T19000-2016,3.4.1]3.15.基线baseline经过一个正式评审并通过的规约或产品,作为后续开发的基础。对其变更只有通过正式的变更控制规程方可进行。[来源:GB/T20261-2020,3.11]3.16.威胁threat可能对系统或组织造成危害的不期望事件的潜在因素。3.17.组件component在系统中,实现其部分功能的可识别区分的部分。4T/ZHSIAXXX—XXXX3.18.网络安全漏洞cyberspacesecurityvulnerability网络产品和服务在需求分析、设计、实现、配置、测试、运行、维护等过程中,无意或有意产生的、有可能被利用的缺陷或薄弱点。[来源:GB/T28458-2020,3.1]3.19.应急响应emergencyresponse组织为了应对突发/重大信息安全事件的发生所做的准备,以及在事件发生后所采取的措施。[来源:GB/T24363-2009,3.4]4.缩略语下列缩略语适用于本文件。S-SDLCCMM:全称为SecureSoftwareDevelopmentLifeCycleCapabilityMaturityModel,即软件安全开发生命周期成熟度模型。S-SDLC域:软件安全开发生命周期成熟度模型共分为4个评估域:监管域、能力域、触点域、运维域。S-SDLC子域:4个评估域安全能力拆解为特定的能力域集合。BP:全称为BasePractice,即基本实践。5.安全开发体系评估模型5.1.成熟度模型架构S-SDLCCMM架构如图1所示。图1S-SDLCCMM架构图S-SDLCCMM的架构由以下三个层次构成:5T/ZHSIAXXX—XXXX5.1.1.安全域软件安全开发生命周期成熟度模型分为4个安全域:监管域、能力域、触点域、运维域,分别从如下维度对软件研发成熟度评估进行阐述:监管域:阐述软件开发组织制定软件安全开发流程、合规要求、管理制度等方面的体系化要求;能力域:阐述软件开发组织保障各种安全活动执行应具备的基础设施;触点域:阐述软件开发组织在软件开发生命周期中应如何融入恰当的安全实践;运维域:阐述软件开发组织的生产环境和软件上线需要执行的安全实践。5.1.2.子域为了便于评估工作开展,将每个安全域的安全能力拆解为多个子域,每个子域描述一个特定的软件研发安全成熟度能力集,拆解后共包含18个子域。5.1.3.基本实践基本实践是子域的进一步细分,是软件研发过程中需要实施的具体安全事项。每个基本实践包含一个或多个评价指标,对每个评价指标分别打分后得到每个基本实践的成熟度等级。6T/ZHSIAXXX—XXXX5.2.模型内容S-SDLCCMM模型定义的成熟度等级通过综合18个子域评分得到,最终评分可在模型框架下进行同行业最佳实践比较。为指导软件研发组织实施软件安全能力评估及改进,我们在子域中给出了具体的实践内容以及对应的参考指标,这些措施提炼自大量的实践经验以及业界的先进共识。组织通过实施模型提供的实践内容和参考指标进行改进,能切实提高软件安全开发的能力。S-SDLCCMM整体结构如图2。监管能力触点运维攻击模型流程与政策安全设计方案与安全开发组件安全需求分析渗透测试合规性第三方组件库管理安全设计软件环境培训标准与要求标准与要求安全实现运营支持供应链管理DevSecOps能力敏感数据处理安全测试应急响应图2S-SDLCCMM整体结构图5.3.S-SDLCCMM评估域概述安全能力量化维度S-SDLCCMM的各评估域、子域、相关安全实践以及评价指标框架如下。子域实践流程与政策建立统一的企业软件安全战略制定组织安全开发管理流程7T/ZHSIAXXX—XXXX建设和运营组织安全文化建立组织级S-SDLC量化管理体系合规性合规性法律文件和要求转化为安全需求培训对高管进行软件安全意识培训对技术人员进行安全技能培训根据公司经验教训建立并使用特定的培训材料外部优秀安全经验吸收能力供应链安全管理成立软件供应链安全风险管理委员会建立正式的软件供应链安全管理制度子域实践攻击模型识别可能存在的潜在攻击者建立攻击模型和技术知识库建设攻击团队安全设计方案与安全开发组件建立相对完善的安全设计库建立相对完善的威胁库安全开发组件第三方组件库管理建立并使用内部完整定义的第三方组件库标准与要求定义渗透测试标准建立一个有关安全信息的内网站点定义安全需求基线定义安全编码规范定义代码安全审核的标准8T/ZHSIAXXX—XXXX定义第三方开源组件分析活动的标准定义安全红线定义安全测试标准定义数据库、中间件和操作系统的安全配置基线定义漏洞管理标准DevSecOps能力使用自动化管理平台进行安全管理敏感数据处理根据数据的类别进行标识对敏感数据进行安全处理子域实践安全需求分析识别安全需求安全设计使用安全设计原则安全团队参与系统架构活动开展威胁分析根据安全需求进行安全设计安全实现执行代码安全审核执行安全编码规范检查对软件系统执行第三方组件安全扫描安全测试执行安全测试使用自研工具进行安全测试子域实践9T/ZHSIAXXX—XXXX渗透测试执行渗透测试软件环境建立环境隔离策略建立统一的标准软件库制定系统加固方案实施安全的容器化部署方案运营支持建立拥有安全能力的运营支持小组维护操作环境规范说明建立持续监控机制持续优化安全策略建立安全补丁与更新管理流程建立持续审计机制应急响应建立拥有安全能力的应急小组制定应急响应预案5.4.安全能力量化维度基本实践的评价指标是对基本实践能力进行量化评估的基础,每个基本实践对应若干个不同的评价指标,评价指标量化的安全能力分为以下3个方面:5.4.1.频率包含实践本身发生的频率、升级频率、更新频率等。如:“对高管进行安全意识培训”实践下对高管参加培训的频率有客观的量化要求;5.4.2.覆盖度指活动发生时覆盖的情况。如:“对技术人员提供安全技能培训”实践下对“安全技能课程覆盖的项目组成员比例”提出了要求,包括开发、测试、产品、项目经理等项目成员参与技能培训的人员占比项目组全部人员的比例;5.4.3.执行质量T/ZHSIAXXX—XXXX指企业在对实践进行执行的质量如何,一般从活动的角色、职责、流程、输入输出等方面评判。如:“识别可能存在的潜在攻击者”评价质量时,会评价对攻击者的识别是否从不同的角度和侧面进行识别,包括企业外侧和内测、系统的业务侧和数据侧等评价是否识别得完善和系统。5.5.能力成熟度等级维度组织的安全开发能力成熟度等级共分为5级,见表1。组织在安全开发过程中不能有效地执行相关工作,仅在部分软件和应用系统开发执行过程中根据临时的需求执行了相关工作,未形成成熟机制保证相关工作的所执行的过程称为“非正式过程”在重要软件和重要应用系在组织级别实现了安全过a)建立可测的安全目标:为组织的安全开发建T/ZHSIAXXX—XXXX立可测量目标。b)客观地管理执行:确定过程能力的量化测量,使用量化测量管理安全过程,并以量化测量作为修正行动的基础a)改进组织能力:在整个组织范围内对规程的使用进行比较,寻找改进规程的机会,并进行改进。b)改进过程有效性:制定处于持续改进状态下的规程,对规程的缺陷进行消除,并对规程进行持续改进表1安全开发能力成熟度等级共性特征能力成熟度等级与域,子域,基本实践的关系如下:a.根据每个安全子域下不同安全实践的实施难度和成效,为基本实践划定不同的成熟度等级范围,例如触点域下安全设计子域的“使用安全设计原则”这一基本实践成熟度为1级到3级,而同一子域下的基本实践“开展威胁分析”成熟度为1级到5级;b.对于每个基本实践,存在若干个评价指标用于从不同维度评估企业在这一安全实践下的成熟度等级,在能力等级评估的时可根据实际情况去除不适用的评价指标。c.对于评价指标来自于BP的3个安全能力量化维度,即频率、覆盖度、执行质量。根据基本实践内多个评价指标的综合计算结果,计算得出每个基本实践的成熟度在成熟度等级范围内的具体等级;d.每个基本实践的最终成熟度来自于该基本实践的多个评价指标的得分结果,子域的成熟度等级来源于子域内所有基本实践的计算结果,安全域的成熟度等级来自于安全域内所有安全子域成熟度的计算结果;能力成熟度等级评估参考方法,参见附录A。能力成熟度等级评估流程和模型使用方法,参见附录B。5.6.评估体系评估体系分为4个大域、18个子域,共包含54个BP:a.监管域的BP(BP01~BP11)包括:建立统一的企业软件安全战略,建立组织安全开发管理流程,建设和运营组织安全文化,建立组织级SDL量化管理,合规性法T/ZHSIAXXX—XXXX律文件要求转化为安全需求,对高管进行安全软件意识培训,对技术人员的安全技能培训,根据公司经验教训建立并使用特定的培训材料,外部优秀安全经验吸收能力,成立软件供应链安全风险管理委员会,建立正式的软件供应链安全管理制度11个BP。b.能力域的BP(BP12~BP31)包括:识别可能存在的潜在攻击者,建立攻击模式和技术知识库,构建攻击团队,建立相对完善的安全设计库,建立相对完善的威胁库,安全开发组件,建立并使用内部完整定义的第三方组件库,定义渗透测试标准,建立一个有关安全信息的内网站点,定义安全需求基线,定义安全编码规范,定义代码安全审核的标准,定义第三方开源组件分析活动的标准,定义安全红线,定义安全测试标准,定义数据库、中间件和操作系统的安全配置基线,定义漏洞管理标准,使用自动化管理平台进行安全管理,根据数据的类别进行标识,对敏感数据进行安全处理20个BPc.触点域的BP(BP32~BP41)包括:识别安全需求,使用安全设计原则,安全团队参与系统架构活动,开展威胁分析,根据安全需求进行安全设计,执行代码安全审核,执行安全编码规范检查,对软件或代码进行第三方组件安全扫描,执行安全测试,使用自动化工具进行安全测试10个BP。d.运维域的BP(BP42~BP54)执行渗透测试,建立环境隔离策略,建立统一的软件标准库,制定系统加固方案,实施安全的容器化部署方案,建立拥有安全能力的运营支持小组,维护操作环境规范说明,建立持续监控机制,持续优化安全策略,建立安全补丁与更新管理流程,建立持续审计机制,建立拥有安全能力的应急小组,制定应急响应预案13个BP。5.7.BP编码规则安全开发BP编码规则如下:每个BP有对应的编号,分别采用递增的数值01、02,...,表示。示例1:BP01,代表BP“建立统一的企业软件安全战略”。6.监管域6.1.流程与政策6.1.1.评估子域描述软件安全开发体系的实施必须是自上而下的,由高层授权,中层平衡相关利益方的诉求,T/ZHSIAXXX—XXXX从而达成组织对软件开发安全的共识,为后续的安全实践落地提供合适的土壤。组织需要对软件安全开发的流程和合规性进行监管,保证执行的效果,最终将安全内化到企业文化之中,为企业的业务产品提升安全方面的核心竞争力。“流程与政策”包括建立统一的软件安全战略、制定组织安全开发管理流程、建设和运营组织安全文化、建立组织级别的SDL量化管理体系等安全实践。6.1.2.基本实践.BP01:建立统一的企业软件安全战略(等级:1-4)该BP包含2个评价指标:1.建立明确的企业软件安全目标;2.制定围绕组织软件安全目标的实施规划。.BP02:制定组织安全开发管理流程(等级:1-4)该BP包含4个评价指标:1.明确了软件开发生命周期内的各安全卡点;2.清晰定义了安全开发生命周期管理目的、适用范围、术语定义、角色与职责、流程图、活动描述、输入、输出和文档模板;3.建立了软件系统分类管理安全策略;4.制定了系统上线前风险评估管理流程。.BP03:建设和运营组织安全文化(等级:1-5)该BP包含4个评价指标:1.建立在组织内部进行安全推广活动的宣传角色;2.制定软件开发安全相关文化活动的开展计划;3.建立企业内部对软件开发安全文化进行宣导的渠道;4.有对行业的影响力输出能力。.BP04:建立组织级SDL量化管理体系(等级:1-5)该BP包含3个评价指标:1.建立SDL系统以量化管理SDL质量指标体系;T/ZHSIAXXX—XXXX2.建立对SDL质量和SDL过程性能不达标的情况进行根因分析并改进SDL绩效的流程;3.建立定期评估和更新SDL质量目标和SDL过程性能目标的流程。6.2.合规性6.2.1.评估子域描述在研发初期就应该从需求层面考虑软件应该符合哪些相关的法律法规,对于合规性的漠视可能会让组织付出惨痛的代价。“合规性”主要描述了软件开发组织从需求就开始重视监管规则。该子域包含了转化政策法规、行业条例、监管要求为安全需求的安全实践。6.2.2.基本实践.BP05:合规性法律文件和要求转化为安全需求(等级:1-4)该BP包含5个评价指标:1.建立了合规法律文件转化为安全需求的流程2.转化了网络空间安全法律合规等法律文件为安全需求,如:网络安全法、等保及行业相关法律法规3.转化了数据安全相关法律合规等法律文件为安全需求,如:数据安全法、网络数据安全管理条例、数据分类分级指引等;4.转化了个人信息保护法律合规等法律文件为安全需求,如:个人信息保护法、个人信息安全规范、个人金融信息保护技术规范等5.转化了组织所处行业的法律合规等法律文件为安全需求,若客户所处行业为云计算行业,则需转化云计算服务安全评估办法6.3.培训6.3.1.评估子域描述安全知识的培训对软件开发组织中的每个角色都至关重要,这是做好软件开发安全实践的前提。“培训”域主要描述了组织为提升高管和技术人员安全知识水平而制定并更新软件安全培训内容和考核内容的能力。6.3.2.基本实践T/ZHSIAXXX—XXXX.BP06:对高管进行安全意识培训(等级:1-4)该BP包含3个评价指标:1.制定了对高管参加培训频率的要求2.制定了安全意识课程考核指标3.设计了针对高管的安全意识培训内容.BP07:对技术人员进行安全技能培训(等级:1-4)该BP包含4个评价指标:1.安全技能课程覆盖项目组成员的比例2.根据技术人员角色,如开发、测试、运维、入职新人等,提供了针对性的安全技能课程3.制定了安全技能课程考核指标4.考核指标与人员晋升绩效挂钩.BP08:根据公司经验教训建立并使用特定的培训材料(等级:1-4)该BP包含3个评价指标:1.定期更新了标准化的安全经验教训库用于公司培训2.安全经验教训库被覆盖到项目团队的比例3.安全经验教训库的宣讲制定了配套的考核指标.BP09:外部优秀安全经验吸收能力(等级:1-4)该BP包含2个评价指标:1.周期性组织吸收外部专家或团队优秀安全开发经验2.外部组织或专家的服务覆盖了项目组的比例6.4.供应链管理6.4.1.评估子域描述在数字化转型的大背景下,软件开发组织采购了大量的第三方软件加快组织的数字化转型,随之而来的是软件供应链安全攻击事件地成倍增长,造成了越来越严重的危害。供应商T/ZHSIAXXX—XXXX软件产品的安全性对软件开发组织而言至关重要。“软件供应链安全管理”主要是帮助企业建立正式的制度,管理软件供应链的安全风险,该子域的内容包括成立软件供应链安全风险管理委员会和建立正式的软件供应链安全管理制度。6.4.2.基本实践.BP10:成立软件供应链安全风险管理委员会(等级:1-2)该BP包含2个评价指标:1.建立了委员会其成员涵盖风险管理相关主要职能部门的高管2.明确了软件供应链安全风险管理委员会的角色、职责.BP11:建立正式的软件供应链安全管理制度(等级:1-3)该BP包含3个评价指标:1.制定了软件供应链风险审查和风险缓解流程2.建立了针对软件供应商安全开发及交付过程的安全要求和控制措施3.制定了一套管理关键供应商的流程7.能力域7.1.攻击模型7.1.1.评估子域描述软件开发组织应能主动了解可能存在的攻击者、攻击模式和相关技术,做到知己知彼、防患未然。“攻击模型”主要描述了当前软件开发组织需要具备的建立攻击者视角的主动防御能力。7.1.2.基本实践.BP12:识别可能存在的攻击者(等级:1-4)该BP包含2个评价指标:1.从不同角度识别了可能存在的攻击者2.定期更新潜在攻击者清单T/ZHSIAXXX—XXXX.BP13:建立攻击模型和技术知识库(等级:1-5)该BP包含3个评价指标:1.收集并使用了攻击情报2.收集并发布了攻击案例3.建立了相应渠道来讨论各种攻击.BP14:建设攻击团队(等级:1-5)该BP包含3个评价指标:1.建立了一支研究新攻击方法的研究团队2.创建了与特定技术相关的攻击模式3.开展了不定期的相关攻击活动来暴露相关弱点7.2.安全设计方案与安全开发组件7.2.1.评估子域描述软件开发组织可以通过安全设计方案和安全开发组件减少研发团队对安全专业知识的依赖,快速实现对研发团队的安全赋能。“安全设计方案与安全开发组件”描述了软件开发组织构建安全开发、安全设计、威胁分析知识库和安全开发组件的能力,“安全设计方案与安全开发组件”的使用可以提升安全开发效率,降低安全开发成本。7.2.2.基本实践.BP15:建立相对完善的安全设计库(等级:1-3)该BP包含1个评价指标:1.建立安全设计库,且该设计库覆盖了安全需求库中的需求.BP16:建立相对完善的威胁库(等级:1-3)该BP包含1个评价指标:1.建立了威胁库,且该威胁库覆盖了各产品使用的技术及业务场景.BP17:安全开发组件(等级:1-3)T/ZHSIAXXX—XXXX该BP包含2个评价指标:1.建立了较为全面的安全开发组件,包括常用安全功能类组件和防漏洞类组件2.安全开发组件覆盖了各项目组用到的开发语言和框架7.3.第三方组件库管理7.3.1.评估子域描述软件系统的开发往往会用到大量的开源组件,软件开发组织需要完善流程、加强安全管控,减小第三方组件库的潜在安全风险。“第三方组件库管理”描述了软件开发组织管控开源组件的能力。7.3.2.基本实践.BP18:建立并使用内部完整定义的第三方组件库(等级:1-4)该BP包含2个评价指标:1.建立团队负责按照正式的管理流程建立、更新、维护内部第三方组件库2.内部定义的第三方组件库涵盖所有产品线7.4.标准与要求7.4.1.评估子域描述“标准与要求”描述了安全活动的标准以及要求是如何定义的。在这个子域中对于安全开发流程中可能涉及到的规范标准都做了定义描述。相关实践包括:定义安全需求基线、建立安全编码规范以及定义代码安全审核标准等相关标准和要求。7.4.2.基本实践.BP19:定义渗透测试标准(等级:1-3)该BP包含1个评价指标:1.组织根据需要定义了较为全面的渗透测试标准.BP20:建立内部安全信息共享站点(等级:1-3)该BP包含3个评价指标:T/ZHSIAXXX—XXXX1.建立了安全门户网站以便相关角色获取软件安全的最新信息2.在组织内推广了网站,以便相关研发角色了解该网站并从其中获取安全信息3.建立了针对网站的评估与更新机制.BP21:定义安全需求基线(等级:1-3)该BP包含3个评价指标:1.安全需求基线包含通用的安全需求2.安全需求基线包含产品相关的合规需求3.建立了针对安全需求基线的评估和更新机制.BP22:定义安全编码规范(等级:1-3)该BP包含1个评价指标:1.安全编码规范涵盖了公司的编程语言和开发框架.BP23:定义代码安全审核标准(等级:1-3)该BP包含1个评价指标:1.定义了代码安全审核相关活动的要求和审批要求.BP24:定义第三方开源组件分析活动标准(等级:1-3)该BP包含2个评价指标:1.定义了漏洞风险等级分类标准2.定义了各种软件许可协议的法律风险等级.BP25:定义安全红线(等级:1-2)该BP包含1个评价指标:1.安全红线涵盖公司的所有软件系统.BP26:定义安全测试标准(等级:1-3)该BP包含3个评价指标:T/ZHSIAXXX—XXXX1.标准涵盖:要求设计安全测试用例2.标准涵盖:要求安全用例覆盖全部安全需求3.标准涵盖:要求把安全测试发现的问题登记在漏洞管理平台跟踪.BP27:定义数据库、中间件和操作系统的安全配置基线(等级:1-3)该BP包含2个评价指标:1.安全配置基线盖各产品开发所用到的数据库、中间件和操作系统2.建立了针对安全配置基线的评估和更新机制0.BP28:定义漏洞管理标准(等级:1-3)该BP包含2个评价指标:1.定义了漏洞分类分级的标准2.定义了基于漏洞等级的处理标准7.5.DevSecOps能力7.5.1.评估子域描述随着近些年DevSecOps推广的不断深入,越来越多的企业开始意识到需要在企业内部建立一个将整个安全研发流程顺畅管理起来的DevSecOps平台。但对于DevSecOps平台在安全性上需要做何考量,多数企业可能有少许细节的思考,但如何从更高的系统级维度进行设计,可能还没有更多可以参考的经验。在本模型中,“DevSecOps工具”子域描述了在建设DevSecOps工具时,明确了需要对DevSecOps平台做怎样设计的要求。7.5.2.基本实践.BP29:使用自动化管理平台进行安全管理(等级:1-5)该BP包含5个评价指标:1.安全工具的集成能力2.数据的管理能力3.权限控制能力5.SDL量化能力T/ZHSIAXXX—XXXX7.6.敏感数据处理7.6.1.评估子域描述为了保护敏感数据的安全性,软件开发组织需要采取一系列措施,如对敏感数据进行加密、安全传输、安全存储、密钥管理、数据脱敏等,确保敏感数据不被非法获取。加密是保证敏感数据安全性的基本手段,即使加密过的敏感数据被非法泄露到外部,也能保证内容不可读。在此基础上,将加密过后的敏感数据存储在安全的位置,并对密钥进行管理也是保护敏感数据机密性的核心工作,这将直接影响到敏感数据的安全性,因此敏感数据的访问控制和备份以及密钥的生成、存储、分发、更新和销毁,组织都必须予以重视。在数据传输方面,通常采用HTTPS或TLS等安全协议,以确保数据在传输过程中不被窃取或篡改。数据脱敏可以在保证数据可用性的前提下,隐藏或部分显示敏感数据,以保护个人隐私和数据安全。鉴于敏感数据安全处理需要从多个方面进行考虑,组织应该综合实现敏感数据从生成、传输、存储到使用的完整安全处理流程。7.6.2.基本实践在组织的开发过程中需求环节,建立针对性的安全需求分析机制,分析组织内软件或应用系统软件的安全需求,跟踪安全需求的实现情况。.BP30:根据数据的类别进行标识(等级:1-3)该BP包含1个评价指标:1.建立了针对不同类别数据的标识的技术方案.BP31:对敏感数据进行安全处理(等级:1-3)该BP包含1个评价指标:1.建立了数据加解密和数据脱敏的技术方案8.触点域8.1.安全需求分析8.1.1.评估子域描述T/ZHSIAXXX—XXXX安全基线规定了软件系统在安全、合规以及漏洞方面的基础要求,软件开发组织需要按照组织定义的安全基线,识别每一项业务需求,并将其转化为安全需求。安全需求的例子包括:为新增的重要业务功能采用多因素的方式来认证身份,收集敏感数据时弹窗提示用户收集的数据及其用途,为WEB应用订单的提交增加预防WEB安全漏洞的功能等。建立并维护一套安全需求知识库,将有助于团队准确而高效的识别安全需求。安全需求知识库的建立是一个长期的过程,并且要根据新的业务场景、使用新的技术手段,保持安全需求知识库的时效性。8.1.2.基本实践在组织的开发过程中需求环节,建立针对性的安全需求分析机制,分析组织内软件或应用系统软件的安全需求,跟踪安全需求的实现情况。.BP32:识别安全需求(等级:1-3)该BP包含3个评价指标:1.开展安全需求分析,定义了安全需求实现的计划2.安全需求的定义和分析过程经过了评审3.安全需求的实现情况得到追踪8.2.安全设计8.2.1.评估子域描述“安全设计”包括安全需求所引导的安全设计,以及从攻击者角度出发的安全威胁分析,还有软件层次的整体性架构设计。8.2.2.基本实践在组织的开发过程中需求环节,建立针对性的安全需求分析机制,分析组织内软件或应用系统软件的安全需求,跟踪安全需求的实现情况。.BP33:使用安全设计原则(等级:1-3)该BP包含1个评价指标:1.参与设计的架构师或其他角色,熟悉常见安全设计原则并充分考虑安全T/ZHSIAXXX—XXXX.BP34:安全团队参与系统架构活动(等级:1-3)该BP包含2个评价指标:1.组织内有能参与安全架构活动的安全架构师2.安全架构师参与软件系统的系统架构活动.BP35:开展威胁分析(等级:1-5)该BP包含2个评价指标:1.使用了威胁分析模型寻找系统潜在威胁2.对识别到的威胁制定了相应的策略,策略经过评审.BP36:根据安全需求进行安全设计(等级:1-3)该BP包含3个评价指标:1.开展了架构安全设计2.已知的安全需求都经过了安全设计3.针对安全需求的设计都得到了评审8.3.安全实现8.3.1.评估子域描述安全实现包含了安全代码审计和安全编码两部分,安全编码指在安全设计的指引下进行代码的实现,安全代码审计是为了防止非预期的漏洞被遗漏。8.3.2.基本实践在组织的开发过程中需求环节,建立针对性的安全需求分析机制,分析组织内软件或应用系统软件的安全需求,跟踪安全需求的实现情况。.BP37:执行代码安全审核(等级:1-3)该BP包含3个评价指标:1.进行了代码提交触发了人工或自动化的审核;2.使用了自动化工具进行代码安全检查;T/ZHSIAXXX—XXXX3.根据漏洞管理标准对代码安全审核的结果进行处理。.BP38:执行安全编码规范检查(等级:1-4)该BP包含1个评价指标:1.采用人工或自动化方式对代码进行安全检查。.BP39:对软件系统执行第三方组件安全扫描(等级:1-3)该BP包含2个评价指标:1.制定了第三方组件安全扫描策略;2.按照漏洞管理标准对SCA的扫描结果进行处理。8.4.安全测试8.4.1.评估子域描述“安全测试”是基于安全需求引导而来的对于安全实现的确认,其中包括工具的使用以及测试结果的评估。8.4.2.基本实践在组织的开发过程中需求环节,建立针对性的安全需求分析机制,分析组织内软件或应用系统软件的安全需求,跟踪安全需求的实现情况。.BP40:执行安全测试(等级:1-3)该BP包含3个评价指标:1.设计了针对安全需求的安全测试用例;2.根据安全测试用例执行了对系统的安全测试活动;3.测试用例和安全需求可双向追溯。.BP41:使用自研工具进行安全测试(等级:1-4)该BP包含2个评价指标:1.使用了IAST/DAST工具进行安全测试;2.使用了自研的安全测试工具。T/ZHSIAXXX—XXXX9.运维域9.1.渗透测试9.1.1.评估子域描述“渗透测试”是上线前对软件残余风险的最后确认。9.1.2.基本实践.BP42:执行渗透测试(等级:1-3)该BP包含2个评价指标:1.进行了系统上线前执行渗透测试;2.进行了系统上线后执行渗透测试。9.2.软件环境9.2.1.评估子域描述“软件环境”描述了软件在运行环境需要考虑的安全基线并根据基线的内容对环境进行检测和加固。9.2.2.基本实践.BP43:建立环境隔离策略(等级:1-3)该BP包含2个评价指标:1.建立并维护了公网和私网的隔离策略;2.建立了开发环境与生产环境隔离策略。.BP44:建立统一的标准软件库(等级:1-3)该BP包含1个评价指标:1.建立并维护了标准系统、数据库。.BP45:实施系统安全基线加固方案(等级:1-4)T/ZHSIAXXX—XXXX该BP包含1个评价指标:1.实施了操作系统、数据库、中间件加固方案。.BP46:实施安全的容器化部署方案(等级:1-5)该BP包含4个评价指标:1.建立了容器基础镜像;2.建立了容器架构保护策略;3.建立了容器访问和身份认证策略;4.建立了容器化编排部署平台。9.3.运营支持9.3.1.评估子域描述“运营支持”描述了软件开发组织以业务安全为目标,保障应用安全运营的相关能力。相关实践包括建立运营支持小组、维护操作环境规范说明、建立持续监控机制和持续优化安全策略等。9.3.2.基本实践.BP47:建立拥有安全能力的运营支持小组(等级:1-3)该BP包含3个评价指标:1.建立了的运营小组中有负责安全能力的人员、角色对组织的安全运营负责;2.运营流程中包含对安全事件发生的处理环节;3.建立了运营支持小组安全人员考核机制。.BP48:维护操作环境规范说明(等级:1-3)该BP包含1个评价指标:1.明确了部署运维安全操作规范。.BP49:建立持续监控机制(等级:1-4)该BP包含4个评价指标:1.建立了白帽子测试渠道;T/ZHSIAXXX—XXXX2.制定了监控发现安全漏洞后反馈跟踪流程;3.部署了入侵检测、防御系统;4.部署了防火墙。.BP50:持续优化安全策略(等级:1-5)该BP包含1个评价指标:1.优化防火墙、网关安全策略。.BP51:建立安全补丁与更新管理流程(等级:1-3)该BP包含2个评价指标:1.制定了评估和更新应用程序的要求;2.制定了评估第三方组件并审查补丁修复的要求。.BP52:建立持续审计机制(等级:1-5)该BP包含2个评价指标:1.应用程序的运行日志进行收集和归一化预处理;2.联合了日志分析进行安全告警。9.4.应急响应9.4.1.评估子域描述“应急响应”描述了软件开发组织对安全事件的响应、处理和恢复能力。其实践包括建立应急小组和制定应急响应预案。9.4.2.基本实践.BP53:建立拥有安全能力的应急小组(等级:1-3)该BP包含2个评价指标:1.建立了应急响应小组并明确组成成员及人员职责分配;2.建立了对应急响应组织人员考核机制。T/ZHSIAXXX—XXXX.BP54:制定应急响应预案(等级:1-3)该BP包含2个评价指标:1.制定了应急响应预案;2.开展了校验应急响应预案有效性的演练。T/ZHSIAXXX—XXXX(资料性附录)能力成熟度等级评估参考方法组织机构的安全开发能力成熟度等级取决于各个安全开发子域的能力成熟度等级。各个安全开发子域的成熟度等级取决于该子域中的基础实践对于目标等级的满足情况。本标准不对评级方法做具体限定,表A.1给出一种综合判定参考方法,供评估人员参考。3…域的得分范围,划出5个相等的区间,计算安全域下所有基本实践的均值,均值落入的区间即为T/ZHSIAXXX—XXXX(资料性附录)能力成熟度等级评估流程和模型使用方法(一)能力成熟度等级评估流程软件研发安全能力成熟度等级的评估从监管域、能力域、触点域和运维域4个安全领域展开。通过对各项安全过程所需具备安全能力的评估,可评估组织在每项安全过程的实现能力属于哪一等级。评估的工作流程、信息收集维度、评估方式如下文所述。评估工作流程:1)确定模型适用范围:分析需要保护的开发资产及业务范围,确定模型使用或评估范围;2)确定能力成熟度级别目标:分析组织机构安全开发风险,确定能力成熟度等级建设目标;3)选取安全子域:针对组织机构的开发相关的业务现状,选取适当的安全开发子域。例如,对于有的组织机构而言,不存在第三方组件的处理,则无需选择第三方组件的子域;4)执行基础实践:依据标准对各等级安全开发基础实践要求,从4个关键能力进行落地和不断改进提升;5)子域安全评估:基于选择的安全子域范畴,针对各项安全子域对组织机构的安全开发实践情况进行现状的调研和分析。确定该子域的等级,参见表A.1;6)确定组织机构整体等级:结合所有子域的等级,确定组织机构整体的安全开发能力成熟度等级,对安全开发能力进行持续建设和改进。信息收集维度:1)组织建设:评估是否具有开展工作的专职/兼职岗位、团队或人员,其工作职责是

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论