《软件安全：从源头开始》

本书阐述什么是人类可控制管理的安全软件开发过程，给出一种基于经验的方法，来构建好用的安全软件开发模型，以应对安全问题，并在安全软件开发模型中解决安全问题。本书分为三部分，共10章。第1章简要介绍软件安全领域的主题及其重要性；第2章讲解软件安全的难点以及SDL框架。第3～8章揭示如何将SDL及其实践映射到一个通用的SDLC框架。第9章从资深软件安全架构师的角度给出关于成功方案的看法，并且解读在开发安全软件时针对典型挑战的一些真实方法。第10章结合现实世界中的安全威胁，描述如何用合理的架构设计、实现与管理的SDL程序来提高安全性。

SDL安全开发生命周期

• SDL由微软提出并应用一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程，侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

SDL的核心理念

• 安全考虑集成在软件开发的每一个阶段

安全评估A1

关键成功因素

可交付成果

架构A2

威胁建模

• 设计原则
  

安全性能

• 保密性
• 完整性
• 可用性
• 身份验证
• 授权
• 不可否认性

架构威胁分析和威胁评级

判定威胁：STRIDE（归类攻击者的目标）

• 威胁分析：输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密、异常管理、参数操作、审计和日志记录
• 威胁评级
  
  

DREAD模型

• 损害、可重复性、可利用性、受影响用户、可发现性
  
• 通过提问量化DREAD类别，再根据问题的回答给每一个DREAD类别划分威胁等级
  

PASTA模型

• 定义目标
• 定义技术范围
• 应用分解
• 威胁分析
• 漏洞和缺陷分析
• 攻击建模
• 风险及影响分析

CVSS 美国政府通用漏洞评估系统

OCTAVE 操作关键威胁、资产和漏洞评测

澳大利亚/新西兰标准 AS/NZS ISO 31000:2009

风险缓解

• 重新设计过程以消除威胁
• 作为一般性建议应用标准的缓解办法
• 发明一种新的缓解策略（高风险且耗时）
• 接受低风险、非常费劲才能解决的安全漏洞
  
  
  
  

隐私信息收集和分析

关键成功因素

可交付成果

设计和开发A3

安全测试计划构成

通用

• 定义测试脚本
• 定义用户社区
• 识别项目障碍物
• 识别内部资源
• 识别外部资源

软件安全测试技术

• 黑盒
• 灰盒
• 白盒

分类

• 源代码分析（白）
• 基于属性（白）
• 源代码错误注入（白、灰）
• 动态代码分析（灰）
• 二进制错误注入（灰、黑）
• 模糊测试（黑）
• 二进制代码分析（黑）
• 字节分析（黑）
• 黑盒调试（黑）
• 漏洞扫描（黑）
• 渗透测试（黑）

威胁模型更新

设计安全性分析和检查

• 最小权限
• 职责分离
• 纵深防御
• 故障安全
• 经济机制
• 完全仲裁
• 开放性设计
• 最小公共机制
• 心理可接受性
• 最弱环节
• 利用现有组件

隐私实现评估

关键成功因素

可交付成果

设计和开发A4

策略一致性分析

安全测试用例执行

SDLC/SDL过程中的代码审查

安全分析工具

静态分析

动态分析

模糊测试

人工审查

控制流分析、数据流分析

关键成功因素

可交付成果

发布A5

漏洞扫描

渗透测试

开源许可审查

最终安全性审查

最终隐私性审查

关键成功因素

可交付成果

发布后支持A6

合理调整软件安全组

• 正确的组织定位
• 正确的人
• 正确的过程

外部漏洞披露响应

• 发布后的PRIST（产品安全事件响应小组）响应
• 发布后的隐私响应
• 优化发布后的第三方响应

第三方审查

发布后认证

新产品组合或云部署的内部审查

安全架构审查和基于工具评估当前、遗留以及并购的产品解决方案

关键成功因素

可交付成果

《The.Security.Development.Lifecycle.CN.软件安全开发生命周期》

第1章 适可而止∶ 威胁正在悄然改变
1.1 遍布安全和隐私冲突的世界
1.2 影响安全的另一因素∶ 可靠性
1.3 事关质量
1.4 主要的软件开发商为什么需要开发更安全的软件
1.5 内部软件开发人员为什么需要开发更安全的软件
1.6 小型软件开发者为什么需要开发更安全的软件
1.7 总结
第 2 章 当前软件开发方法不足以生成安全的软件
2.1 "只要给予足够的关注，所有的缺陷都将无处遁形"
2.1.1 审核代码的动力
2.1.2 理解安全 bug
2.1.3 人员数量
2.1.4 "关注越多"越容易失去要点
2.2 专利软件开发模式
2.3 敏捷开发模式
2.4 通用评估准则
2.5 总结
第 3 章 微软 SDL 简史
3.1 前奏
3.2 新威胁，新对策
3.3 Windows 2000 和 Secure Windows Initiative
3.4 追求可度量性∶贯穿 Windows XP
3.5 安全推进和最终安全评审（FSR）
3.6 形成软件安全开发生命周期
3.7 持续的挑战
第 4 章 管理层的 SDL
4.1 成功的承诺
4.1.1 微软的承诺
4.1.2 你是否需要 SDL?
4.1.3 有效承诺
4.2 管理 SDL
4.2.1 资源
4.2.2 项目是否步入正轨?
4.3 总结
第 5 章第 O 阶段∶教育和意识
5.1微软安全教育简史
5.2 持续教育
5.3 培训交付类型
5.4 练习与实验
5.5 追踪参与度与合规度2
5.6 度量知识3
5.7 实现自助培训
5.8 关键成功因子与量化指标4
5.9 总结
第 6章 第 1阶段∶项目启动
6.1 判断软件安全开发生命周期是否覆盖应用7
6.2 任命安全顾问8
6.2.1 担任开发团队与安全团队之间沟通的桥梁
6.22 召集开发团队举行SDL 启动会议
6.2.3 对开发团队的设计与威胁模型进行评审
6.2.4 分析并对 bug 进行分类，如安全类和隐私类
6.2.5 担任开发团队的安全传声简
6.2.6 协助开发团队准备最终安全审核
6.2.7 与相应安全团队协同工作
6.3 组建安全领导团队
6.4 确保在 bug 跟踪管理过程中包含有安全与隐私类 bug
6.5 建立"bug 标准"
6.6 总结
第7 章 第 2 阶段∶定义并遵从设计最佳实践
7.1 常见安全设计原则
7.2 受攻击面分析与降低
7.2.1 第一步∶该特性真的有那么重要么?
7.2.2 第二步∶究竟谁需要从哪里访问这些功能?
7.2.3 第三步，降低特权
7.2.4 其他受攻击面组成部分
7.3总结
第 8 章 第 3 阶段∶产品风险评估
8.1安全风险评估
8.1.1安装问题4
8.1.2 受攻击面问题
8.1.3 移动代码问题
8.1.4 安全特性相关问题
8.1.5 常规问题
8.1.6 分析问卷
8.2隐私影响分级
8.2.1 隐私分级1
8.2.2 隐私分级2
8.2.3 隐私分级3
8.3 统一各种因素（Pulling It All Together）
8.4 总结
第9章第4 阶段∶风险分析
9.1 威胁建模产物（Artifact）
9.2 对什么进行建模
9.3 创建威胁模型
9.4 威胁建模过程
9.4.1 定义应用场景
9.4.2 收集外部依赖列表
9.4.3 定义安全假设
9.4.4 创建外部安全备注
9.4.5 绘制待建模应用的一个或多个数据流图（DFD）
9.4.6 确定威胁类型
9.4.7 识别系统威胁
9.4.8 判断风险
9.4.9 规划消减措施
9.5 利用威胁模型辅助代码评审
9.6 利用威胁模型辅助测试
9.7 关键成功因子和指标
9.8 放结
第 10 章 第 5 阶段∶创建安全文档、工具以及客户最佳实践
10.1 为什么需要文档和工具?
10.2 创建指导性安全最佳实践文档
10.2.1 安装文档
10.2.2 主线产品使用文档
10.2.3 帮助文档
10.2.4 开发人员文档
10.3 创建工具
10.4 总结
第 11章 第 6 阶段∶安全编码策略
11.1 使用最新版本编译器与支持工具
11.2 使用编译器内置防御特性
11.2.1 缓冲区安全检查∶/GS
11.2.2 安全异常处理∶/SAFESEH
11.2.3 数据执行防护兼容性∶/NXCOMPAT
11.3 使用源代码分析工具
11.3.1 源代码分析工具陷阱
11.3.2 源代码分析工具的益处
11.4 切勿使用违禁函数
11.5 减少潜在可被利用的编码结构或设计
11.6 使用安全编码检查清单
11.7 总结
第12 章 第 7阶段∶安全测试策略
12.1模糊测试
12.1.1 模糊操作文件格式
12.1.2 网络协议模糊操作
12.1.3 零散模糊测试
12.1.4 通过模糊测试修复发现的 bug
12.2渗透测试
12.3 运行时验证
12.4 必要时审核并更新威胁模型
12.5 重估软件的受攻击面
12.6总结
第 13 章 第 8 阶段∶安全推进活动
第 14 章 第9 阶段∶最终安全评审
第 15 章 第 10 阶段∶安全响应规划
第 16 章第 11 阶段∶产品发布
第 17 章 第 12 阶段∶安全响应执行
第 18 章 在敏捷模式中集成 SDL
19 章 SDL 违禁函数调用
第 20 章 SDL 最低加密标准
第 21 章SDL 必备工具以及编译器选项
第 22 章 威胁树模式

标签：威胁,分析,读书笔记,9.4,安全,实验,SDL,软件
来源： https://www.cnblogs.com/ckx1212-20191308/p/16321609.html