271 lines
11 KiB
Markdown
271 lines
11 KiB
Markdown
# 软件安全开发生命周期
|
||
|
||
> **一、软件生命周期模型**<br>
|
||
> <span style="color:green;">了解</span>软件生命周期的概念及瀑布模型、迭代模型增量模型、快速原型模型、螺旋模型、净室模型等典型软件开发生命周期模型。
|
||
>
|
||
> **二、软件危机与安全问题**<br>
|
||
> <span style="color:green;">了解</span>三次软件危机产生的原因、特点和解决方案；<br>
|
||
> <span style="color:green;">了解</span>软件安全和软件安全保障的基本概念。
|
||
>
|
||
> **三、软件安全生命周期模型**<br>
|
||
> <span style="color:green;">了解</span>SDL、CLASP、CMMI、SAMM、BSIMM等典型的软件安全开发生命周期模型。
|
||
|
||
### 一、软件生命周期模型
|
||
|
||
#### 1、软件的定义
|
||
|
||
软件是与计算机系统操作有关的计算机程序、规程规则，以及可能有的文件、文档及数据。
|
||
|
||
#### 2、软件生命周期模型
|
||
|
||
- 瀑布模型
|
||
- 迭代模型
|
||
- 增量模型
|
||
- 快速原型模型
|
||
- 螺旋模型
|
||
- 净室模型
|
||
|
||
#### 3、瀑布模型
|
||
|
||
1. **最早出现的软件开发模型**
|
||
2. **核心思想**
|
||
- 按工序将问题简化
|
||
- 将功能的实现与设计分开
|
||
3. **不足**
|
||
- 没有对开发周期后期发现错误做出相应的规定
|
||
4. **应用场景**
|
||
- 规模较小
|
||
- 周期较短
|
||
- 需求明确
|
||
|
||
|
||
|
||
#### 4、迭代模型
|
||
|
||
1. **瀑布模型的小型化应用**
|
||
2. **<span style="color:red;">完整的工作流程</span>**
|
||
3. **降低风险**
|
||
- 增量开支的风险
|
||
- 产品无法按期进入市场的风险
|
||
4. **加快开发进度**
|
||
- 任务清晰
|
||
- 需求更容易随需而变
|
||
5. **关于迭代的认知**
|
||
- 选代模型是从深度或细化的程度来划分的，每阶段功能得到完善、增强；
|
||
- 迭代，就是在实现软件的每一功能求精的过程，是提升软件质量的过程，从模糊到清晰的过程。
|
||
6. **应用场景**
|
||
- 需求频繁变更
|
||
|
||
|
||
|
||
#### 5、增量模型
|
||
|
||
- <span style="color:red;">融合</span>了瀑布模型和迭代模型的特征；
|
||
- 本质上是迭代，每个增量发布一个可操作产品。
|
||
- 应用场景
|
||
- 周期短
|
||
- 规模大
|
||
|
||
|
||
|
||
#### 6、螺旋模型
|
||
|
||
- <span style="color:red;">兼顾</span>快速原型的选代的特征以及瀑布模型的系统化与严格监控；
|
||
- <span style="color:red;">引入</span>了其他模型不具备的<span style="color:red;">风险分析</span>，使软件在无法排除重大风险时有机会停止，以减小损失；
|
||
- 构建原型是螺旋模型用以减小风险的途径；
|
||
- <span style="background-color:yellow;">适合于大型的<span style="color:red;">昂贵的</span>系统软件开发</span>；
|
||
- <span style="background-color:yellow;">制定计划 - 风险分析 - 实施工程 - 客户评价</span>（<span style="color:red;">4个象限</span>）。
|
||
|
||
|
||
|
||
#### 7、其他软件开发方法
|
||
|
||
1. **快速原型模型**
|
||
|
||
- 快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上逐渐完成整个系统的开发工作。
|
||
|
||
- 应用场景：需求不明确
|
||
|
||
2. **净室模型**
|
||
|
||
净室是一种应用<span style="color:red;">数学</span>与<span style="color:red;">统计学理论</span>以经济的方式生产高质量软件的工程技术。力图通过严格的工程化的软件过程达到开发中的<span style="color:red;">零缺陷或接近零缺陷</span>。
|
||
|
||
|
||
|
||
### 二、软件危机与安全问题
|
||
|
||
#### 1、第一次“软件危机”
|
||
|
||
- 20世纪 60年代
|
||
- 根源：日益庞大和复杂的程序对开发管理的要求越来越高。
|
||
- <span style="color:red;">解决：软件工程</span>
|
||
|
||
#### 2、第二次“软件危机”
|
||
|
||
- 20世纪 80年代
|
||
- 根源：软件规模继续扩大，程序数百万行，数百人同时开发，可维护性难。
|
||
- <span style="color:red;">解决：面向对象语言 - `C++`、`java`、`c#`</span>
|
||
|
||
#### 3、第三次“软件危机”
|
||
|
||
- 21世纪 头十年
|
||
- 根源：软件安全
|
||
- <span style="color:red;">解决：软件安全开发生命周期管理</span>
|
||
|
||
#### 4、软件安全问题
|
||
|
||
> 软件缺陷普遍存在
|
||
|
||
- <span style="color:red;">千行代码缺陷数量（千行代码缺陷率）</span>
|
||
- 普通软件公司：4～40
|
||
- 高管理软件公司：2～4
|
||
- 美国NASA软件：0.1
|
||
- 漏洞数量
|
||
|
||
#### 5、软件安全问题产生
|
||
|
||
1. **内因**
|
||
|
||
- 软件<span style="color:red;">规模增大</span>，功能越来越多，越来越<span style="color:red;">复杂</span>
|
||
- 软件模块<span style="color:red;">复用</span>，导致安全漏洞延续
|
||
- 软件<span style="color:red;">扩展</span>模块带来的安全问题
|
||
|
||
|
||
|
||
2. **外因**
|
||
|
||
- 互联网发展对软件安全的挑战
|
||
|
||
- 开发环境和开发人员对软件安全的挑战
|
||
|
||
1. 开发者缺乏安全开发的动机
|
||
|
||
- 市场和业务要求将交付期和软件功能做主要因素
|
||
|
||
- 用户方没有提供安全方面的压力
|
||
|
||
2. 开发者缺乏相关知识
|
||
|
||
- 软件复杂性加大，开发者需要学习更多东西
|
||
|
||
- 传统软件开发不进行安全教育
|
||
|
||
3. 缺乏安全开发工具
|
||
- 缺乏安全开发配套管理、测试等工具
|
||
|
||
#### 6、软件安全保障
|
||
|
||
- <span style="color:red;">贯彻风险管理的思想</span>
|
||
- 安全不必是完美无缺的，但风险必须是可管理的；
|
||
- 树立对软件安全控制的信心，该信心是通过保障活动来获取的。
|
||
- 通过在软件开发生命周期各阶段采取必要的、相适应的安全措施来<span style="color:red;">避免绝大多数的安全漏洞</span>。
|
||
- 采取措施只能有效减少，但<span style="color:red;">并不能完全杜绝</span>所有的安全漏洞！
|
||
|
||
### 三、软件安全开发生命周期模型
|
||
|
||
#### 1、<span style="color:red;">软件安全开发覆盖软件整个生命周期</span>
|
||
|
||
- <span style="color:red;">需求分析阶段</span>考虑软件的安全需求
|
||
- <span style="color:red;">在设计阶段</span>设计符合安全准则的功能
|
||
- <span style="color:red;">编码阶段</span>保证开发的代码符合安全编码规范
|
||
- <span style="color:red;">安全测试和运行维护</span>确保安全需求、安全设计、安全编码各个环节得以正确有效的实施
|
||
|
||
> <span style="background-color:yellow;">在软件的各个阶段引入安全措施！</span>
|
||
|
||
#### 2、V模型
|
||
|
||
- **开发阶段**：需求分析、概要设计、详细设计、编码阶段
|
||
- **测试阶段**：验收测试、系统测试、集成测试、单元测试
|
||
|
||
#### 3、<span style="color:red;">软件安全问题越早解决成本越低</span>
|
||
|
||
- 在软件开发生命周期中后面的阶段改正错误开销比前面的阶段要高出数倍；
|
||
- NIST：在软件发布以后进行修复的代价是在软件设计和编码阶段即进行修复所花代价的<span style="color:red;">30倍</span>。
|
||
|
||
#### 4、相关模型和研究
|
||
|
||
1. **安全软件开发生命周期**
|
||
- 安全设计原则
|
||
- 安全开发方法
|
||
- 最佳实践
|
||
- 安全专家经验
|
||
2. **多种模型被提出和研究**
|
||
- 可信计算安全开发生命周期（微软）
|
||
- CLASP（OWASP）综合的轻量应用安全过程
|
||
- BSI系列模型（Gary McGraw等）
|
||
- SAMM（OWASP）软件保证成熟度模型
|
||
|
||
#### 5、SDL
|
||
|
||
1. **什么是SDL**
|
||
|
||
安全开发生命周期（Security Development Lifecycle，SDL）
|
||
|
||
2. **SDL发展**
|
||
|
||
|
||
|
||
3. **SDL的阶段和安全活动**
|
||
|
||
- <span style="color:red;">七个阶段</span>
|
||
- <span style="color:red;">十七项必需的安全活动</span>
|
||
|
||
|
||
|
||
#### 6、CLASP
|
||
|
||
1. **什么是CLSAP**
|
||
- 综合的轻量应用安全过程（Comprehensive，Lightweight Application Security Process，CLASP）
|
||
- 用于构建安全软件的轻量级过程，由30个特定的活动(activities)和辅助资源构成的集合
|
||
- 针对这些活动给出了相应的指南、导则和检查列表
|
||
2. **特点**
|
||
- 基于角色的安排
|
||
|
||
#### 7、CMMI
|
||
|
||
1. **什么是CMMI**
|
||
|
||
- 软件能力成熟度集成模型（Capability Maturity Model Integration）
|
||
|
||
2. **五级**
|
||
|
||
|
||
|
||
3. **过程区域**
|
||
|
||
#### 8、SAMM
|
||
|
||
1. **什么是SAMM**
|
||
|
||
- 软件保证成熟度模型（Software Assurance Maturity Mode，SAMM）
|
||
- 提供了一个开放的框架，用以帮助软件公司制定并实施所面临来自软件安全的特定风险的策略。
|
||
|
||
2. **核心业务功能**
|
||
|
||
SAMM规定了4个软件开发过程中的核心业务功能，包括<span style="color:red;">治理</span>、<span style="color:red;">构造</span>、<span style="color:red;">验证</span>以及<span style="color:red;">部署</span>，这4个业务功能各包括了3个安全实践。
|
||
|
||
- <span style="color:red;">治理</span>：专注软件开发企业组织管理其软件安全开发相关的过程、活动和措施，主要包括策略与指标、教育与指导、政策与遵守等三项安全实践。
|
||
- <span style="color:red;">构造</span>：关注与软件安全开发中需求、目标和架构方面的过程、活动和措施，主要包括安全需求、威胁评估和安全架构3个方面的安全实践。
|
||
- <span style="color:red;">验证</span>：注重软件检查和测试中的过程、活动和措施，主要包括设计审核、安全测试和代码审核三项安全实践。
|
||
- <span style="color:red;">部署</span>：强调了软件发布和部署配置时相关的过程、活动和措施，主要包括环境强化、漏洞管理和操作启用3项安全实践。
|
||
|
||
|
||
|
||
#### 9、BSI系列模型
|
||
|
||
1. **BSI （Building Security IN）**
|
||
- 使安全成为软件开发必须的部分
|
||
- 强调应该使用工程化的方法来保证软件安全
|
||
2. **<span style="background-color:yellow;">软件安全的三根支柱</span>**
|
||
- <span style="color:red;">风险管理</span>：策略性方法；
|
||
- <span style="color:red;">接触点</span>：一套轻量级最优工程化方法，攻击与防御综合考虑；
|
||
- <span style="color:red;">安全知识</span>：强调对安全经验和专业技术进行收集汇总，对软件开发人员进行培训，并通过安全接触点实际运用。
|
||
3. **BSIMM - BSI成熟度模型**
|
||
- 对真实的软件安全项目所开展的活动进行量化
|
||
- 构建和不断发展软件安全行动的指南
|
||
|
||
#### 10、各模型比较
|
||
|
||
|
||
|