软件安全开发生命周期

软件生命周期模型

软件的定义
软件是与计算机系统操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据

软件生命周期模型
瀑布模型
迭代模型
增量模型
快速原型模型
螺旋模型
净室模型

软件生命周期模型-瀑布模型

最早出现的软件开发模型
核心思想
按工序将问题简化
将功能的实现与设计分开
不足
没有对开发周期后期发现错误做出相应的规定
突出特点：不支持用户参与，要求预先确定需求
适合场景：需求易于完善定义且不易变更的软件系统

软件生命周期模型-迭代模型

瀑布模型的小型化应用
完整的工作流程
降低风险
增加开支的风险
产品无法按期进入市场的风险
加快开发进度
任务清晰
需求更容易随需而变
突出特点：逐步获取用户需求、完善软件产品的过程
适合场景：需求难以确定、不断变更的软件系统

软件生命周期模型-增量模型

融合了瀑布模型和迭代模型的特征
本质上是迭代，每个增量发布一个可操作产品
突出特点：软件产品是被增量式地一块块开发的，允许开发活动并行和重叠
适合场景：技术风险较大，用户需求较为稳定的软件系统

软件生命周期模型-快速原型模型

快速原型模型又称原型模型，它是增量模型的另一种形式
快速原型模型是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作
突出特点：不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认
适合场景：需求复杂、难以确定、动态变化的软件系统

软件生命周期模型-螺旋模型

兼顾快速原型的迭代的特征以及瀑布模型的系统化与严格监控
引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失
构建原型是螺旋模型用以减小风险的途径
突出特点：引入了其他模型不具备的风险分析
适合场景：需求难以获取和确定、软件开发风险较大的软件系统（比如大型的、昂贵的系统级软件应用）

软件生命周期模型-净室模型

净室是一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术。力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷
突出特点：严格的工程化预防缺陷的产生
适合场景：质量要求非常高的项目（比如航天系统、洲际导弹系统）

软件安全重要性–软件危机

第一次“软件危机”- 20世纪60年代
根源：日益庞大和复杂的程序对开发管理的要求越来越高
解决：软件工程

第二次“软件危机”- 20世纪80年代
根源：软件规模继续扩大，程序数百万行，数百人同时开发，可维护性难
解决：面向对象语言-C++/java/c#

第三次“软件危机”- 21世纪头十年
根源：软件安全
解决：软件安全开发生命周期管理

软件缺陷普遍存在

软件安全问题产生-内因

软件规模增大,功能越来越多,越来越复杂
软件模块复用，导致安全漏洞延续
软件扩展模块带来的安全问题

软件安全问题产生-外因

互联网发展对软件安全的挑战

开发环境和开发人员对软件安全的挑战
开发者缺乏安全开发的动机
• 市场和业务要求将交付期和软件功能做主要因素
• 用户方没有提供安全方面的压力
开发者缺乏相关知识
• 软件复杂性加大，开发者需要学习更多东西
• 传统软件开发不进行安全教育
缺乏安全开发工具
• 缺乏安全开发配套管理、测试等工具

软件安全保障

贯彻风险管理的思想
安全不必是完美无缺的，但风险必须是可管理的
树立对软件安全控制的信心，该信心是通过保障活动来获取的
通过在软件开发生命周期各阶段采取必要的、相适应的安全措施来避免绝大多数的安全漏洞

采取措施只能有效减少，但并不能完全杜绝所有的安全漏洞！

软件安全开发生命周期

软件安全开发覆盖软件整个生命周期
需求分析阶段考虑软件的安全需求
在设计阶段设计符合安全准则的功能
编码阶段保证开发的代码符合安全编码规范
安全测试和运行维护确保安全需求、安全设计、安全编码各个环节得以正确有效的实施

在软件的各个阶段引入安全措施！

软件安全问题越早解决成本越低

在软件开发生命周期中，后面的阶段改正错误开销比前面的阶段要高出数倍
NIST：在软件发布以后进行修复的代价是在软件设计和编码阶段即进行修复所花代价的30倍

相关模型和研究

安全软件开发生命周期
安全设计原则
安全开发方法
最佳实践
安全专家经验
多种模型被提出和研究
可信计算安全开发生命周期（微软）
CLASP（OWASP）综合的轻量应用安全过程
BSI系列模型（Gary McGraw等）
SAMM（OWASP）软件保证成熟度模型

SDL

什么是SDL
安全开发生命周期（Security Development Lifecycle，SDL）
SDL发展

SDL的阶段和安全活动

七个阶段
十七项必需的安全活动
核心概念：培训教育、持续过程改进和责任

正式发布软件后12个月内的漏洞对比

IE：漏洞总数下降35%，高危漏洞数下降63%

操作系统：漏洞总数降低45%

CLASP

什么是CLASP
综合的轻量应用安全过程（Comprehensive, Lightweight Application Security Process ，CLASP）
用于构建安全软件的轻量级过程，由30个特定的活动(activities)和辅助资源构成的集合
针对这些活动给出了相应的指南、导则和检查列表
特点
基于角色的安排(角色和职责)

CMMI

什么是CMMI
软件能力成熟度集成模型(Capability Maturity Model Integration)
五级

过程域（域维）/能力维

SAMM

什么是SAMM
软件保证成熟度模型（Software Assurance Maturity Mode，SAMM）
提供了一个开放的框架，用以帮助软件公司制定并实施所面临来自软件安全的特定风险的策略

BSI系列模型

BSI(Building Security IN)
使安全成为软件开发必须的部分
强调应该使用工程化的方法来保证软件安全

软件安全的三根支柱
风险管理：策略性方法
接触点：一套轻量级最优工程化方法，攻击与防御综合考虑
安全知识：强调对安全经验和专业技术进行收集汇总，对软件开发人员进行培训，并通过安全接触点实际运用

BSIMM

BSI成熟度模型
对真实的软件安全项目所开展的活动进行量化
构建和不断发展软件安全行动的指南

各模型比较

软件安全需求及设计

威胁建模

什么是威胁建模
威胁建模是了解系统面临的安全威胁，确定威胁风险并通过适当的缓解措施以降低风险，提高系统安全性的过程。
为什么要威胁建模
帮助在设计阶段充分了解各种安全威胁，并指导选择适当的应对措施
对可能的风险进行管理
可以重新验证其架构和设计
有助于软件的受攻击面降低

威胁建模流程

确定对象
识别威胁
评估威胁
消减威胁

威胁建模-确定对象

确定要保护和评估的目标（资产）

在使用实例和应用场景中分析
明确应用或系统的关键威胁场景
• 部署方式、配置信息、用户使用方式等
典型场景
• 移动或小型设备物理失窃场景
• Web应用匿名用户场景

威胁建模-识别威胁

识别每一个可能面临的威胁
理解软件可能面临的威胁是安全开发的前提
威胁不等于漏洞
威胁永远存在

理解STRIDE六类威胁

威胁建模-评估威胁

评估威胁风险值
评估被利用和攻击发生的概率
评估攻击后资产的受损后果，并计算风险

威胁建模-消减威胁

重新设计并排除这个威胁
使用标准的威胁消减技术
发明新的消减方法
根据安全Bug标准来确定是否可接受风险
把威胁作为漏洞记录下来，以后再想办法消减

要想办法消减每个威胁！

软件安全需求及安全设计的重要性

软件安全需求和设计是开发安全软件的基础
软件安全需求分析
以风险管理为基础，建立“威胁”分析计划
建立软件安全需求定义，确保软件安全需求定义正确
安全需求应文档化
软件安全设计
软件系统的每一项需求，都应该在软件安全设计阶段认真考虑

安全需求分析

安全需求分类
安全功能需求
安全保障需求
需求分析的要点
安全需求进行有效定义
不仅考虑系统功能，还要考虑系统不应该做什么
功能需求、安全需求、安全目标要达到平衡

需求工程师不要仅仅从用户的角度出发考虑系统的功能，还应从攻击者的角度出发考虑系统的漏洞

需求分析过程

系统调查
定性分析系统的脆弱点和可能遭受的安全威胁
脆弱点和安全威胁的定量分析
需求的确定

建立在风险分析的基础上！

安全设计的重要性

安全编码？安全测试？
传统方法：软件发布后测试、等待修复Bug
Gary McGraw ：50%的安全问题由设计瑕疵引起
安全提前介入，效益高，成本低
设计缺陷——举例
Microsoft Bob
明文存储口令，甚至将口令拿到客户端对比验证

软件安全设计

安全概要设计阶段
包括但不限于：安全体系结构设计、各功能块间的处理流程、与其他功能的关系、安全协议设计、安全接口设计等。
安全详细设计阶段
详细设计阶段作为安全功能的程序设计阶段，应当直接指导安全功能的编码工作。包括但不限于：模块设计、内部处理流程、数据结构、输入/输出项、算法、逻辑流程图等

根据安全需求方案确定的安全目标，对初步风险评估确定的控制措施的具体技术实现而进行安全设计

安全设计的主要活动

详细风险评估
控制措施选择
安全技术实现
安全设计评审

安全设计原则

最小特权原则
权限分离原则
最少共享机制原则
完全中立原则
心理可接受度原则
默认故障处理保护原则
经济机制原则
不信任原则
纵深防御原则
保护最薄弱环节原则
公开设计原则
隐私保护原则
攻击面最小化原则

降低攻击面

作用
攻击面越小，安全风险越小

实现
取消不需要的功能
增加对功能的安全防护

示例
SQL Server2005默认关闭
xp_cmdshell存储过程

分析软件攻击面

分析产品功能的重要性（是否必须）
分析从哪里访问这些功能（本地&远程）
分析访问权限（匿名&经过认证）

降低攻击面策略

重要等级为低的功能：攻击面大，取消该功能
重要等级为中的功能：攻击面大，设置为非默认开启，需要用户配置后才予以开启
重要等级为高的功能：攻击面大，关闭或限制一些接口方式，增加一些安全的保证措施或技术

降低受攻击面对于提高软件源代码安全性至关重要!

降低软件攻击面通常做法

软件安全实现

通用安全编码原则-验证输入

对所有输入数据进行检查、验证及过滤
应用软件的“数据防火墙”，避免恶意数据进入
什么时候验证
最初接收数据时
（第一次）使用数据时

验证输入-常见输入源

命令行
参数数量、数据格式、内容

环境变量
环境变量可能超出期望
有的环境变量存储格式存在危险

文件
不信任可以被不可信用户控制的文件内容
不信任临时文件

网络
来自网络的数据是“高度不可信的”
其他来源

通用安全编码原则-避免缓冲区溢出

缓冲区溢出
缓冲区：包含相同数据类型的实例的一个连续计算机内存块
溢出：数据被添加到分配给该缓冲区的内存块之外
外部数据比目标空间大
是一个非常普遍而且严重的问题

通用编码原则-避免缓冲区溢出

解决办法
填充数据时计算边界
• 动态分配内存
• 控制输入
使用没有缓冲区溢出问题的函数
• strncpy、strncat、C++中std:string
使用替代库
• Libmib、libsafe
基于探测方法的防御
• StackGuard、ProPolice、/GS
• 将一个“探测”值插入到返回地址的前面
非执行的堆栈防御
• 不可在堆栈上执行代码

通用编码原则-程序内部安全

程序内部接口安全
程序内部接口数据的检查

异常的安全处理
检测异常，安全处理各种可能运行路径
检测到某些错误行为/数据，必须以合适的方式处理，保证程序运行安全
必要时立即拒绝服务，甚至不回送详细的错误代码

最小化反馈
避免给予不可靠用户过多的信息
• 成功或失败
• 作为跟踪检查的日志可以记录较为详细的信息
认证程序在认证前尽量少给信息
如果程序接受了密码，不要返回它

避免竞争条件
访问共享资源时（文件/变量）没有被适当地控制
使用原子操作
使用锁操作——避免死锁

安全使用临时文件

通用编码原则-安全调用组件

应用程序实际上几乎都不会是自包含的，它们通常都会调用其他组件
底层的操作系统
数据库
可重用的库
网络服务（WEB、DNS）

使用安全组件，并且只采用安全的方式
检查组件文档，搜索相关说明
• gets
• 随机数
使用经过认可的组件
尽可能不调用外部命令，如果不得已要调用，必须
严格检查参数
• system、open、exec、

正确处理返回值
一定要检查返回值，调用是否成功
成功时检查
• 返回值，是否按照期望值处理
• 数据中可能含有 NUL 字符、无效字符或其他可能产
生问题的东西
错误时检查
• 错误码

保护应用程序和组件之间传递的数据
视安全需求和安全环境
考虑传输加密，包括密码算法和安全协议

通用编码原则-禁用不安全函数

编码中禁止使用的危险函数举例

软件安全编译

确保编译环境的安全
使用最新版本编译器与支持工具
可靠的编译工具
使用编译器内置防御特性

确保运行环境的安全
将软件运行环境基于较新版本的系统

源代码审核

什么是源代码审核
通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，报告源代码中可能隐藏的错误和缺陷
源代码审核方式
人工审核
• 费时费力
• 容易遗漏
工具审核
• 速度快，自动
• 可升级知识库

统计证明，在整个软件开发生命周期中，30%至70%的代码逻辑设计和编 码缺陷是可以通过源代码审核来发现的。

软件安全测试

软件测试

什么是软件测试
使用人工和自动化的手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差异
基本概念
测试用例
测试覆盖率度量指标

软件测试的基本概念

测试的信条
预期测试的测试结果是预先确定的
好的测试用例发现错误的概率高
成功的测试就是发现了错误的测试
测试独立于编码
需要具备应用（用户）及软件（编程）两方面的专业知识
测试人员使用不同于开发人员的工具
只检查常见的测试用例是不够的
测试文档要能够再利用

软件测试方法

单元测试、集成测试、系统测试
黑盒测试、白盒测试、灰盒测试
静态测试、动态测试
代码走查、代码审查、代码评审
回归测试
验收测试

软件安全测试

什么是软件安全测试
确定软件的安全特性实现是否与预期设计一致的过程
有关验证软件安全等级和识别潜在安全缺陷的过程
查找软件自身程序设计中存在的安全隐患，并检查应用程序对非法侵入的防范能力
为什么需要软件安全测试
传统测试仅考虑软件出错时的处理，没有考虑对软件的故意攻击

软件安全测试方法

在应用投产前，应由独立的安全团队对应用的安全性进行综合评估
功能性安全测试
对抗性安全测试
安全测试方法
模糊测试
渗透测试
静态源代码审核

模糊测试（Fuzzing）

什么是模糊测试
也称Fuzzing测试，一种通过提供非预期的输入并监视异常结果来发现软件故障的方法
黑盒测试，不关心被测试目标的内部实现，而是利用构造畸形的输入数据引发被测试目标产生异常，从而发现相应的安全漏洞

非常有效的漏洞挖掘技术，已知漏洞大部分都是通过这种技术发现的。

强制软件程序使用恶意/破坏性的数据并进行观察结果的一种测试方法
不够强壮的程序会崩溃
编码良好的程序正常运行

特性
方法学
随机值
大量测试用例
查找漏洞或可靠性错误

模糊测试过程
生成大量的畸形数据作为测试用例
将这些测试用例作为输入应用于被测对象
监测和记录由输入导致的任何崩溃或异常现象
查看测试日志，深入分析产生崩溃或异常的原因

影响模糊测试效果的关键因素
测试点
数据通道入口、可信边界点

样本选择
选择覆盖面广、便于测试的多个样本

数据关联性
智能模糊测试

自动化框架
异常监控与异常恢复
分析评估

渗透测试

渗透测试
通过模拟恶意攻击者进行攻击，来评估系统安全的一种评估方法
从攻击的角度测试软件系统是否安全
使用自动化工具或者人工的方法模拟攻击者的输入，找出运行时刻目标系统所存在的安全漏洞
优点
找出来的问题都是真实的，也是较为严重的
缺点
只能到达有限的测试点，覆盖率较低

渗透测试流程

渗透测试要点

测试目的
安全性的评估，不是摧毁或破坏
测试人员
技术、知识和经验很重要
像“坏人”一样思考问题
安全问题
系统备份和恢复措施
风险规避

如果测试参数由哪些不想发现安全问题的人所确定，那么，渗透测试就很可能变成一种毫无用处的自我满足练习！

灵活安排自己的“组合”

代码审核 + 体系结构风险评估
基于风险的安全测试 + 渗透测试
安全需求分析 + 滥用案例开发
代码审核 + 渗透测试
体系结构风险分析 + 基于风险的测试

软件安全测试思路

充分了解软件安全漏洞
评估软件安全风险
拥有高效的软件安全测试技术和工具

软件安全交付

软件供应链安全

供应链安全概念
目前软件安全开发生命周期中新的威胁，涉及到软件的代码编写、代码编译、软件分发、软件更新
代码编写：共享库
代码编译：被污染的编译软件
软件分发/更新：污染源头

供应链安全应对策略
安全流程覆盖到引入的第三方代码中
可靠的编译软件获取方式
官方渠道、发布验证

软件验收及部署

软件安全验收
正式的验收流程
安全纳入到验收考虑中

软件安全部署
提供软件部署所需要的文档和工具
软件安全加固
软件安全配置