本文已收录至《全国计算机等级考试——信息 安全技术》专栏
1.1 软件安全开发背景
1.1.1 软件的发展和安全问题
软件是指计算机程序、方法和相关的文档资料,以及在计算机上运行时所需要的数据。
软件安全问题有以下几个方面:
(1)系统软件安全问题
(2)应用软件安全问题
(3)第三方代码安全
(4)新技术安全问题
软件的安全问题一般包含两个方面:一是软件的可靠性和可用性问题;二是软件中信息的保密性和完整性问题。
1.1.2 软件安全问题产生的原因
软件存在安全问题的根本原因有两个:一个是软件自身存在安全问题,另一个是软件在应用中存在安全威胁(即软件面临严重外部威胁)。
- 软件自身存在安全问题
软件安全漏洞持续增长的内因主要包括以下几个:
(1)软件开发安全意识淡薄。传统软件开发更倾向于软件功能,而不注重对安全风险的管理。
(2)软件开发者缺乏安全知识。项目管理和软件开发人员缺乏软件安全开发知识,不知道如何更好地开发安全的软件。
(3)软件趋向大型化,第三方扩展增多。现代软件功能越来越强,功能组件越来越多,软件也变得越来越复杂。
2.软件面临严重外部威胁
安全事件的产生必定是软件内部脆弱性和外部威胁共同作用的结果,当前软件系统面临着非常严重的外部威胁。主要有以下几个:
(1)软件使用场景更具威胁
(2)恶意代码泛滥
(3)黑客活动猖獗
安全威胁是软件问题的外因,安全漏洞则属于内因。虽然可以通过在实际运维过程中部署安全设备和控制措施,努力降低安全事件发生的可能性,但开发高质量的软件系统,尽量降低软件中的安全缺陷才是治本之策。
1.2 软件安全开发概念
1.2.1 软件安全保障
软件安全保障是指确保软件能够按照开发者的预期,提供与威胁相适应的安全能力,从而维护软件自身的安全属性,避免存在可以被利用的安全漏洞,并且能从被入侵和失败的状态中恢复。软件安全保障的目标是使软件可以规避安全漏洞,按照预期的方式执行其功能,以增强开发者和使用者的信心。
软件的安全属性包括保密性、完整性、可用性、抗抵赖性等。其中,保密性、完整性和可用性是软件的核心安全属性。
编号 | 安全属性 | 解释说明 |
---|---|---|
1 | 保密性 | 软件必须保证其内容、资源管理以及自身特性(包括其运行环境和用户之间的联系)对未授权的实体隐藏 |
2 | 完整性 | 软件以及受其管理的资源必须能够抵御主动攻击,防止被非法用户修改和破坏,并能从被破坏状态中恢复 |
3 | 可用性 | 软件可被授权用户访问并按需求使用,即保证合法用户对系统和资源的使用不会被不合理拒绝 |
在软件安全保障中,需要贯彻风险管理的思想。
1.2.2 软件安全开发生命周期
软件生命周期大致可以划分为需求分析、架构设计、代码编写、测试和运行维护等阶段。
安全软件开发生命周期(Secure Software Development Lifecycle, SSDL)是一种强调安全措施的软件生命周期,即通过软件开发的各个步骤来确保软件的安全性,其目标是最大限度地确保软件的安全。
1.3 软件安全开发方法
1.3.1 安全开发生命周期(微软)
安全开发生命周期(Security Development Lifecycle, SDL),SDL从安全角度指导软件开发过程。
SDL将软件开发生命周期划分为七个阶段,共提出了十七项重要的安全活动,如下图。
这七个阶段的主要任务和目的如下。
(1)培训
针对开发团队和高层进行安全意识与能力的培训,使之了解安全基础知识以及安全方面的最新趋势,同时能针对新的安全问题与形势持续提升团队的能力。
(2)需求
在软件开发初始阶段,确定软件安全需要遵循的安全标准和相关要求,建立安全和隐私要求的最低可接受级别。
(3)设计
设计阶段要从安全性的角度定义软件的总体结构。通过分析攻击面,设计相应的功能和策略,降低并减少不必要的安全风险,同时通过威胁建模,分析软件或系统的安全威胁,提出缓解措施。
(4)实施
按照设计要求,对软件进行编码和集成,实现相应的安全功能、策略以及缓解措施。
(5)验证
通过动态分析和安全测试手段,检测软件的安全漏洞,全面核查攻击面,检查各个关键因素上的威胁缓解措施是否得以正确实现。
(6)发布
建立可持续的安全维护响应计划,对软件进行最终安全核查。本阶段应将所有相关信息和数据存档,以便对软件进行发布与维护。
(7)响应
响应安全事件与漏洞报告,实施漏洞修复和应急响应。同时发现新的问题与安全问题模式,并将它们用于SDL的持续改进过程中。
在这七个阶段中,SDL要求前六个阶段的十六项安全活动为开发团队必须成功完成的安全活动,这些必须活动由安全和隐私专家确认有效,并且会作为年度评估过程的一部分,不断进行有效性评判。同时,SDL认为开发团队应保持灵活性,以便根据需要选择安全活动,如人工代码评析、渗透测试、应用程序漏洞分析,以确保对某些软件组件进行更高级别的安全分析。
1.3.2 内建安全
内建安全(Build Security In, BSI)的含义是将安全内建到软件开发过程中,而不是可有可无,更不是游离于软件开发生命周期之外。
BSI方法强调与开发流程无关,而是在每个开发阶段通过一些关键的安全接触点来保证软件开发的安全性,从而实现在整个软件开发生命周期中既保证软件安全,又超脱于具体的开发模型。
软件安全的三根支柱是风险管理、软件安全接触点和安全知识。风险管理是一种战略性方法,即将减轻风险作为一种贯穿整个生命周期的指导方针;软件安全接触点指结合软件开发生命周期中的一套轻量级最优工程方法,综合考虑软件安全的两个方面——攻击与防御,从不同角度提供保障安全的行为方式;安全知识强调对安全经验和专业技术进行收集汇总,对软件开发人员进行培训,并通过安全接触点实际运用到项目过程中。
软件安全接触点(touch point)一般包含七个接触点,这七个接触点和软件安全开发生命周期密切相关。
软件安全接触点是一种战术性方法,通过从“黑帽子”(攻击和破解)和“白帽子”(防御和保护)两个方面综合考察软件开发过程中可能出现的问题,结合软件开发生命周期在每一个开发阶段上尽可能地避免和消除漏洞,从而形成“安全的”软件开发生命周期。
(1)代码审核
所有软件开发都会产生代码,因此代码审核成为第一个接触点。代码审核可以使用商业或免费工具。
(2)风险分析
在架构设计中,应进行风险分析,确定可能的攻击,并提供一致的安全防护措施。
(3)渗透测试
渗透测试可以评估真实运行环境中软件的安全性。
(4)基于风险的安全测试
功能测试能够告诉软件开发人员是否能实现其功能设计,安全测试会告诉软件开发人员该功能设计能否正确而安全地实现。
(5)滥用案例
滥用案例也称为误用案例,通过设计滥用案例,可以更准确地描述系统在受到攻击时的行为表现:应该保护什么、免受谁的攻击,以及保护多长时间等。
(6)安全需求
好的安全需求包括功能安全需求和异常处理安全需求。功能安全需求包括如数据加密、隐私保护和访问控制等,而异常处理安全需求包括软件异常处理、恶意攻击处理等。
(7)安全操作
要求软件公司不同部门、不同职位人员之间进行密切合作和协同一致的工作。
1.3.3 BSI成熟度模型
BSI成熟度模型(Build Security In Maturity Model, BSIMM)是对真实的软件安全项目所开展的安全活动进行量化评估,旨在帮助软件安全相关人员了解、衡量,并对软件安全措施进行规划。
BSIMM 5根据软件安全框架(Software Security Framework, SSF)描述了软件安全开发的4大领域12项实践112个活动,以下是4大领域和12项实践的介绍:
(1)治理
治理领域包括策略与度量、合规与政策,以及培训三项基本实践。
(2)信息/情报
信息/情报领域包括攻击模式、安全特征与设计,以及标准和需求三项基本实践
(3)软件开发安全接触点
软件开发安全接触点领域包括架构分析、代码审查与安全测试三项基本实践。
(4)部署
部署领域包括渗透测试、软件环境,以及配置管理与漏洞管理三项基本实践。软件配置、维护,以及其他环境问题对软件的安全性有直接影响。
1.3.4 软件保障成熟度模型
软件保障成熟度模型(Software Assurance Maturity Model, SAMM)是一个开放的框架,帮助组织制定并实施所面临来自软件安全的特定风险策略。
SAMM从企业组织与软件开发的核心活动开始,规定了四个软件开发过程中的核心业务功能,包括治理、构造、验证以及部署(见图1-3),这四个业务功能各包括了三个安全实践。
治理专注软件开发企业组织管理软件安全开发相关的过程、活动和措施,主要包括战略与度量、策略与遵循、培训与指导三项安全实践;
构造关注于软件安全开发中需求、目标和架构方面的过程、活动和措施,主要包括威胁评估、安全需求和安全架构三个方面的安全实践;
验证注重软件检查和测试中的过程、活动和措施,主要包括设计审核、代码审查和安全测试三项安全实践;
部署强调了软件发布和部署配置时相关的过程、活动和措施,主要包括漏洞管理、环境加固和操作激活三项安全实践
SAMM的每个安全实践都是一个与安全相关的措施,保证相关业务功能的实现,这十二个安全实践都是改进软件开发业务功能的独立部分。对于每一个安全实践,SAMM设置了三个成熟度等级和一个隐含的零起点,每个等级的细节对不同实践有所不同,具体如下。
0级:隐含起点,代表实际没有实现安全实践;
1级:对安全实践有了初步了解并有专门的设计和使用;
2级:进一步提高了安全实践的效率和有效性;
3级:在一定规模上综合、有效地掌握了安全实践。
对于某个特定的软件开发项目或软件开发企业,使用SAMM对其进行评估,有两种推荐的评估方法:简单方法和详细方法。其中,前者对每项安全实践进行评估,并为得到的评估结果评定分数;后者对每项安全实践评估后,再执行额外的审计工作,以确保每个安全实践中规定的每一项措施都已执行,且已达到成功指标。
1.3.5 综合的轻量应用安全过程
综合的轻量应用安全过程(Comprehensive Lightweight Application Security Process, CLASP)最初由安全软件公司(Secure Software, Inc.)提出,后来由OWASP完善、维护并推广,该模型由一系列安全活动驱动。CLASP是一个用于构建安全软件的轻量级过程,由30个特定活动和辅助资源组成,用于提升整个开发团队的安全意识。CLASP的一个突出特点是安全活动与角色相关联,强调安全开发过程中各角色的职责。
CLASP的主要目标是构建安全的软件,其安全活动大都从安全理论的角度定义,因此,安全活动的覆盖面广。同时,CLASP通过一些安全最佳实践将安全属性以一种结构化、可重复和可测量的方式整合进软件开发组织的现有或者将要展开的软件开发生命周期中,相互独立的安全活动以结构化组织的方式集成到开发过程和运行环境中。为了具有一定的灵活性,CLASP要执行的安全活动及其执行顺序是可选择的,不同开发者可以自行裁剪,以适应待开发产品的实际情况。
1.3.6 软件安全开发方法特点分析
编号 | 开发方法 | 说明 |
---|---|---|
1 | SDL | 从需求分析阶段到测试阶段,都有较多的自动化工具支持它,如威胁建模、静态源代码分析等工具。由于SDL体系较为完善,和其他安全开发流程相比,它的实施要求严格。 |
2 | BSI | 强调了在软件生命周期中风险管理的重要性,并要求风险管理框架贯穿整个开发过程。 软件安全接触点具有较好的通用性,能够与不同的软件开发模型相结合。 |
3 | BSIMM | BSIMM收集了很多软件企业在软件安全开发方面的措施和方法,并按照软件安全开发框架进行描述,找出这些软件企业的共同点和不同点,从而给其他企业提供实践参考。 |
4 | CLASP | CLASP是一个用于构建安全软件的轻量级过程,强调安全开发过程中的角色和职责,其安全活动基于角色安排。 与SDL相比,CLASP所采用的流程属于轻量级,也能够和多种软件开发模型相结合,因此,对小型软件企业更具有吸引力 |
5 | SAMM | SAMM为软件安全开发提供了一个开放的框架,软件企业可以参考SAMM来衡量其软件安全保障计划,制定软件开发安全策略,创建明确定义和可衡量的目标,并循序渐进地改善软件开发过程。 与其他几个模型相比,SAMM的目标在于制定简单、有良好定义,且可测量的软件安全开发模型,其对安全知识的要求更低,更适于非安全专家使用 |
1.4 软件安全开发其他相关内容
1.4.1 风险管理
风险管理是信息安全保障工作的基本方法,信息安全保障应以风险管理为基础,针对可能存在的各种威胁和自身弱点,采取有针对性的防范措施。
风险的大小,与资产、威胁、脆弱性这三个引起风险的最基本要素有关。其中,
- 资产是任何对组织有价值的东西,是要保护的对象;
- 威胁是可能导致信息安全事故和组织信息资产损失的活动;
- 脆弱性则是与信息资产有关的弱点或安全隐患,是造成风险的内因。
衡量风险的两个基本要素是事件发生的概率和产生的后果。
风险评估是针对风险管理对象所面临的风险进行识别、分析和评价,通过风险评估的结果获得信息安全需求。
风险评估的过程一般包括风险评估准备、风险要素识别、风险分析和风险结果判定四个阶段。
风险评估准备阶段制订风险评估计划和方案,选择风险评估工具,为后续风险评估的实施做好准备。此阶段形成的计划书和方案需要得到信息系统和信息安全风险管理高层的认可和批准。
风险要素识别阶段识别需要保护的资产、面临的威胁以及存在的脆弱性,并分别赋值,同时确认已有的安全措施,形成需要保护的资产清单,以及面临的威胁、存在的脆弱性和已有安全措施三份列表。
风险分析阶段分析安全事件发生的可能性及造成的损失,并实施风险计算,形成风险计算报告。
风险结果判定阶段评价风险的等级和综合评价风险状况,形成风险程度等级列表和风险评估报告。
软件风险管理框架是由以下基本活动阶段组成的封闭循环过程:
- 理解业务背景。
- 确认业务和技术的风险。
- 综合评价风险并赋予优先级。
- 定义风险减轻策略。
- 实现修正并确认其正确性。
软件安全风险管理的常用实践措施是进行安全风险分析和风险评估。
威胁建模和受攻击面分析是风险分析评估的重要方法,风险管理是一种连续的、迭代的过程,在项目开发过程中需要多次响应。
1.4.2 信息系统安全工程
信息系统安全工程(Information System Security Engineering, ISSE)是采用工程的概念、原理、技术和方法,研究、开发、实施与维护信息系统安全的过程,是一门综合交叉学科,以系统工程(Systems Engineering, SE)、项目管理、质量管理体系和能力成熟度模型(Capability Maturity Model, CMM)等理论为基础发展而来。
ISSE的主要目的是确认安全风险,并且采用系统工程的方法使安全风险降到最低或得到有效控制。
ISSE实施过程划分为五个过程:发掘信息保护需求、确定系统安全要求、设计系统安全体系结构、开发详细安全设计和实现系统安全。
1.4.3 CC标准
CC标准(Common Criteria for Information Technology Security Evaluation),作为国际通用测评准则,自1993年开始提出,至1999年正式成为国际标准ISO 15408,并在随后被我国等同采用为国标GB/T 18336《信息技术安全性评估准则》。
CC标准定义了保护轮廓(Protection Profile, PP)和安全目标(Security Target,ST)两种结构来表述IT安全功能和保证要求。PP是满足特定用户需求的一类产品或系统的一组与实现无关的安全要求。ST阐述安全要求,详细说明一个既定被评估产品或系统即评估对象(Target of Evaluation, TOE)的安全功能。
安全需求有:安全审计(FAU)、通信/不可抵赖(FCO)、密码支持(FCS)、用户数据保护(FDP)、标识和鉴别(FIA)、安全管理(FMT)等。
CC标准的评估技术包括但不限于以下这些:
- 分析并检查过程和程序。
- 检查过程和程序是否正在被使用。
- 分析TOE各设计表示之间的一致性。
- 对照要求,分析TOE的设计表示。
- 验证证据。
- 分析指导性文档。
- 分析所开发的功能测试和所提供的结果。
- 独立的功能测试。
- 脆弱性分析(包括缺陷假设)。
- 渗透性测试。
在安全保障要求部分CC标准定义了7个递增的评估保证等级,保证是指对功能产生信心的方法。
CC标准对于软件安全开发有着重要的指导意义。从安全开发的角度来看,CC标准为开发者提供了以下支持:
- 为开发者在确定其产品或系统所要满足的安全需求方面提供支持。
- 为他们准备和协助对其产品或系统的评估提供支持。
- 通过评估证实产品或系统的安全功能,保证满足特定的安全需求。
- 标准中提出的安全功能可被开发者在其产品或系统中实现,促进其技术进步。
- 标准中的保证要求可帮助开发者规范其研发、生产和集成等过程,提高生产管理能力。