210 lines
10 KiB
Markdown
210 lines
10 KiB
Markdown
# 软件安全需求及设计
|
||
|
||
> **一、威胁建模**<br>
|
||
> <span style="color:blue;">理解</span>威胁建模的作用及每个阶段的工作内容；<br>
|
||
> <span style="color:red;">掌握</span>STRIDE模型用于进行威胁建模实践。
|
||
>
|
||
> **二、软件安全需求分析**<br>
|
||
> <span style="color:blue;">理解</span>软件安全需求在软件安全开发过程中的重要性；<br>
|
||
> <span style="color:blue;">理解</span>安全需求分析的方法和过程。
|
||
>
|
||
> **三、软件安全设计**<br>
|
||
> <span style="color:blue;">理解</span>软件安全设计的重要性及内容和主要活动；<br>
|
||
> <span style="color:blue;">理解</span>最小特权、权限分离等安全设计的重要原则；<br>
|
||
> <span style="color:blue;">理解</span>攻击面的概念并掌握降低攻击面的方式。
|
||
|
||
### 一、威胁建模
|
||
|
||
#### 1、什么是威胁建模
|
||
|
||
威胁建模是了解系统面临的安全威胁，确定威胁风险并通过适当的缓解措施以降低风险，提高系统安全性的过程。
|
||
|
||
#### 2、为什么要威胁建模
|
||
|
||
- 帮助在设计阶段充分了解各种安全威胁，并指导选择适当的应对措施；
|
||
- 对可能的风险进行管理；
|
||
- 可以重新验证其架构和设计；
|
||
- 有助于软件的受攻击面降低。
|
||
|
||
#### 3、威胁建模流程
|
||
|
||
|
||
|
||
1. **确定对象**
|
||
- 确定要保护和评估的目标（资产）
|
||
- 在使用实例和应用场景中分析
|
||
1. 明确应用或系统的<span style="color:red;">关键威胁场景</span>
|
||
- 部署方式、配置信息、用户使用方式等
|
||
2. <span style="color:red;">典型场景</span>
|
||
- 移动或小型设备物理失窃场景
|
||
- Web应用匿名用户场景
|
||
|
||
2. **识别威胁**
|
||
|
||
- <span style="color:red;">识别每一个可能面临的威胁</span>
|
||
|
||
- 理解软件可能面临的威胁是安全开发的前提
|
||
- 威胁不等于漏洞
|
||
- 威胁永远存在
|
||
|
||
|
||
|
||
- <span style="color:red;">理解STRIDE六类威胁</span>
|
||
|
||
|
||
|
||
3. **评估威胁**
|
||
|
||
- 评估威胁风险值
|
||
- 评估被利用和攻击发生的概率
|
||
- 评估攻击后资产的受损后果，并计算风险
|
||
|
||
> 参考风险管理、安全工程中相关内容！
|
||
|
||
4. **消减威胁**
|
||
|
||
- 重新设计并排除这个威胁
|
||
- 使用标准的威胁消减技术
|
||
- 发明新的消减方法
|
||
- 根据安全Bug标准来确定是否可接受风险
|
||
- 把威胁作为漏洞记录下来，以后再想办法消减
|
||
|
||
> 要想办法消减每个威胁！
|
||
|
||
### 二、软件安全需求分析
|
||
|
||
- 软件安全需求和设计是开发安全软件的基础。
|
||
|
||
#### 1、软件安全需求分析
|
||
|
||
- 以风险管理为基础，建立“威胁”分析计划；
|
||
- 建立软件<span style="color:red;">安全需求</span>定义，确保软件安全需求定义正确；
|
||
- 安全需求应<span style="color:red;">文档化</span>。
|
||
|
||
#### 2、软件安全设计
|
||
|
||
- 软件系统的每一项需求，都应该在软件安全设计阶
|
||
段认真考虑
|
||
|
||
#### 3、安全需求分析
|
||
|
||
1. **安全需求分类**
|
||
|
||
- 安全<span style="color:blue;">功能</span>需求
|
||
|
||
- 安全<span style="color:blue;">保障</span>需求
|
||
|
||
2. **需求分析的要点**
|
||
|
||
- 安全需求进行有效定义
|
||
|
||
- 不仅考虑系统功能，还要考虑系统不应该做什么
|
||
|
||
- 功能需求、安全需求、安全目标要达到平衡
|
||
|
||
> 需求工程师<span style="color:red;">不要仅仅从用户的角度</span>出发考虑系统的功能，还应从<span style="color:red;">攻击者的角度</span>出发考虑系统的漏洞。
|
||
|
||
3. **需求分析过程**
|
||
|
||
- 系统调查
|
||
- 定性分析系统的脆弱点和可能遭受的安全威胁
|
||
- 脆弱点和安全威胁的定量分析
|
||
- 需求的确定
|
||
|
||
> 建立在风险分析的基础上！
|
||
|
||
#### 4、安全设计的重要性
|
||
|
||
- 安全编码？安全测试？
|
||
|
||
- 传统方法：软件发布后测试、等待修复Bug
|
||
- Gary McGraw：50%的安全问题由设计瑕疵引l起
|
||
- 安全提前介入，效益高，成本低
|
||
|
||
|
||
|
||
- 设计缺陷 - 举例
|
||
|
||
- Microsoft Bob
|
||
- 明文存储口令，甚至将口令拿到客户端对比验证
|
||
|
||
### 三、软件安全设计
|
||
|
||
#### 1、安全设计阶段
|
||
|
||
1. **安全<span style="color:red;">概要设计阶段</span>**
|
||
- 包括但不限于：安全体系结构设计、各功能块间的处理流程、与其他功能的关系、安全协议设计、安全接口设计等。
|
||
|
||
2. **安全<span style="color:red;">详细设计阶段</span>**
|
||
- 详细设计阶段作为安全功能的程序设计阶段，应当直接指导安全功能的编码工作。包括但不限于：模块设计、内部处理流程、数据结构、输入/输出项、算法、逻辑流程图等。
|
||
|
||
> 根据安全需求方案确定的安全目标，对初步风险评估确定的控制措施的具体技术实现而进行安全设计。
|
||
|
||
#### 2、安全设计的主要活动
|
||
|
||
- 详细风险评估
|
||
- 控制措施选择
|
||
- 安全技术实现
|
||
- 安全设计评审
|
||
|
||
#### <span style="background-color:yellow;">3、安全设计原则</span>
|
||
|
||
- **<span style="color:red;">最小特权</span>原则**
|
||
- 对于请求存储资源的主体，<span style="background-color:yellow;">只应该分配最少的必要权限</span>，而且应该保证赋予权限分配的必要时间最短。如果授予一个用户或进程、组件超过其行为必要的权限范围的许可，该用户或进程、组件就有可能获得或修改其没有权限处理的信息。
|
||
- **<span style="color:red;">权限分离</span>原则**
|
||
- 尽量把软件划分为不同独立的组件，<span style="background-color:yellow;">把权限分离成不同的权限许可和认证条件</span>，把用户分离成不同的权限角色。不要将权限一次性授予给一个用户，而是根据需要提供多重的认证与检查机制再进行授予。
|
||
- **<span style="color:red;">最少共享机制</span>原则**
|
||
- <span style="background-color:yellow;">避免多个主体共享同一个资源</span>，因为敏感的信息可能通过相同的机制在这些主体之间共享导致被其他用户获取。每个主体应该有不同的机制或不同的机制实例，在保证多用户存取访问的灵活性的同时，防止由单一的共享机制导致潜在违背安全性的行为。
|
||
- **完全中立原则**
|
||
- **心理可接受度原则**
|
||
- **默认故障处理保护原则**
|
||
- **经济机制原则**
|
||
- **<span style="color:red;">不信任</span>原则**
|
||
- <span style="background-color:yellow;">开发者应该假定系统环境是不安全的。</span>减少对用户、外部系统、其他组件的信任，对外部实体所有的输人都需要进行检查，即使对于可信的外部用户输人。另外也不应该信任每次对函数或系统的调用操作都必然会成功，如内存的分配，因此必须对每次函数或系统的调用的返回值进行检查，并进行正确的处理。
|
||
- **<span style="color:red;">纵深防御</span>原则**
|
||
- <span style="background-color:yellow;">软件应该设置多重安全措施，并充分利用操作系统提供的安全防护机制，形成纵深防御体系，以降低攻击者成功攻击的机率和危害。</span>结合多重安全措施使攻击者要绕过每一个机制才能达到目的，提高了攻击者的攻击成本和要求，降低了安全危害。
|
||
- **保护最薄弱环节原则**
|
||
- **公开设计原则**
|
||
- **<span style="color:red;">隐私保护</span>原则**
|
||
- <span style="background-color:yellow;">系统收集到的用户信息都必须实施妥善和安全的保护。</span>攻击者获得了用户的隐私数据之后，可以发起进一步针对用户的各种攻击，如欺骗等，不应该向其他用户泄露用户的隐私信息。
|
||
- **<span style="color:red;">攻击面最小化</span>原则**
|
||
- 攻击面（Attack Surface），通常也称<span style="color:blue;">受攻击面</span>，是指<span style="background-color:yellow;">对一个软件系统可以采取的攻击方法集合。</span>因为攻击者对软件的攻击是从其暴露在外部的接口、功能、服务和协议等资源来实施的，通过对每种资源计算其被攻击成功的可能性，并将这些可能性综合归纳，即可衡量软件的攻击面大小。可以看出，<span style="background-color:yellow;">一个软件的攻击面越大，其安全风险也就越大</span>。
|
||
|
||
#### 4、攻击面相关概念
|
||
|
||
- **<span style="color:red;">降低攻击面</span>**
|
||
|
||
1. 作用
|
||
- 攻击面越小，安全风险越小
|
||
2. 实现
|
||
- 取消不需要的功能
|
||
- 增加对功能的安全防护
|
||
3. 示例
|
||
- SQL Server 2005默认关闭<span style="color:red;">`xp_cmdshell`</span>存储过程
|
||
- `xp_cmdshell`使用的注意事项：
|
||
1. 必须具有sysadmin角色
|
||
2. 必须在master数据库下执行
|
||
3. SQL2000中缺省情况下xp_cmdshell是启用的
|
||
4. SQL2005及后续产品中xp_cmdshell是禁用的
|
||
|
||
- **<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>的功能：攻击面大，关闭或限制一些接口方式，增加一些安全的保证措施或技术。
|
||
|
||
> 降低受攻击面对于提高软件源代码安全性至关重要！
|
||
|
||
- **降低软件攻击面通常做法**
|
||
|
||
|
||
|