读书笔记

《Core.Software.Security.Security.at.the.Source.CN.软件安全.从源头开始》

第一章 引论

软件安全的重要性和相关性

软件是我们在现实世界中做任何事情的关键,同时,软件也分布在最关键的系统中,基于此,软件的安全设计是直观重要的。为了证明一个软件安全程序的合理性,必须知晓没有构建安全软件带来的金钱成本和其他风险的重要性与相关性。

软件安全和软件开发生命周期

  • 软件安全

    是关于构建安全软件的,确保软件是安全的,培训软件开发人员、架构师和用户如何构建安全到软件中。

  • 应用程序安全

    是关于保护软件和该软件发布后运行的系统,当且仅当开发完成后。

代码的质量与安全

衡量软件安全性的是机密性、完整性和可用性,衡量软件质量的是易用性、可重用性和可维护性。

  • 安全的代码并不意味着高质量的代码
  • 高质量的代码并不意味着安全代码

软件既不能只有质量没有安全,又不能只有安全没有质量。

SDL三个最重要的安全目标

  • 机密性:对信息的访问和泄露进行限制
  • 完整性:防止不正确的信息修改或销毁
  • 可用性:保证信息可以实时使用

这三个目标统称为CIA
机密性、可用性和完整性合在一起就是信息安全。

威胁建模和攻击面验证

威胁建模和攻击面验证也许是SDL中最耗时、最不易理解和困哪最大的部分。

  • 威胁建模

    理解系统的潜在威胁,确定风险,建立适当的应对措施。在项目生命周期的早期正确地进行威胁建模后,就可以在代码提交前发现软件设计的安全问题。

  • 攻击面

    测试一个应用程序至少要涵盖应用程序的入口点和出口点(攻击面),这些暴露在外很可能被攻击者利用。可访问性会增加软件的攻击面。
    攻击面的元素可以通过扫描工具来识别。最小攻击面通常在软件开发生命周期的早期进行定义,并在之后的阶段进行测试。

第2章 安全开发生命周期

克服软件安全中的挑战

SDL程序的实现,能够保证良好的企业软件设计和开发固有的安全。最著名的SDL模型是可信计算安全开发生命周期,微软已经将它应用到需要承受恶意攻击的软件开发中。微软的SDL也有一个安全开发生命周期的优化模型,使得开发精力和IT决策者能够评估开发中安全的状态。

软件安全成熟度模型

  • Cigital的内置安全成熟度模型BSIMM
  • OWASP的开放软件保证成熟模型SAMM

其他SDL最佳实践的资源

  • SAFECode
  • 美国国土阿全软件保障计划
  • 美国国家标准与技术研究院
  • MITRE公司公共计算机漏洞和暴露
  • SANS研究所高级网络安全风险
  • 美国国防部网络安全与信息系统信息分析中心
  • CERT、Bugtraq和SecurityFocus

关键工具和人才

工具

  • 模糊测试
  • 静态分析
  • 动态分析

人才

  • 软件安全架构师
  • 软件安全从业者

最小特权原则

在计算环境特定的抽象层中,每个模块(过程、用户或程序)仅能访问合法目的所必须的信息和资源。限制特权提升是威胁建模的重要部分。
确保最小特权防止敏感数据泄露,并防止未经授权的用户访问程序或者它们未曾想要访问的区域。

隐私

用户隐私安全除了问题将导致信任危机。
隐私保护措施通过SDL实现的最佳实践构建到了SDLC中。

软件开发方法

  • 瀑布开发

    迭代瀑布开发

  • 敏捷开发
    Scrum

    精益开发

第3章 安全评估(A1):SDL活动与最佳实践

安全评估(A1)是SDL的第一个阶段,是项目团队识别产品风险及所需的SDL活动的短语,成为发现阶段。在这个阶段中,时钟有思想原则问题应该得到解决:

1. 软件满足客户任务的关键程度如何?
2. 软件所必须的安全目标是什么?
3. 哪些法规和政策是适用于确定什么需要保护的?
4. 在给软件运行的环境中又可能存在什么威胁?

安全评估(A1)成功的关键因素和度量标准

成功的关键因素

可交付成果

度量标准

  • 软件安全团队循环的时间(单位:周)
  • 参加SDL的利益相关者的百分比
  • SDL活动映射到开发活动的百分比
  • 安全目标满足的百分比

第4章 架构(A2):SDL活动与最佳实践

在安全开发生命周期的第2阶段,安全方面的考虑被带入软件开发生命周期,以确保所有的威胁、要求、功能和继承方面的潜在制约因素军被考虑到。

威胁建模/架构安全性分析

威胁建模


威胁判定

STRIDE:

  • 欺骗 S
  • 篡改 T
  • 否认 R
  • 信息泄露 I
  • 拒绝服务 D
  • 提升权限 E

风险评估过程

威胁的评级
风险 = 概率 X 潜在损害
如果概率 = 5,潜在损害 = 10,那么风险 = 5 X 10 = 50%
如果概率 = 10,潜在损害 = 5,那么风险 = 5 X 10 = 50%

DREAD:

  • 潜在损害 D
  • 可重复性 R
  • 可利用性 E
  • 受影响的用户 A
  • 可发现性 D

风险缓解

有四种方法可以计划减缓和应对威胁:

1. 重新设计过程以消除威胁。
2. 作为一般性建议应用标准的缓解方法。
3. 发明一种新的缓解策略。
4. 接收低风险、非常费劲才能解决的安全漏洞

成功的关键因素和度量标准

成功的关键因素

可交付成果

第5章 设计和开发(A3):SDL活动与最佳实践

在这个阶段会做策略一致性分析,创建测试计划文档,更新威胁模型(根据需要),进行安全性设计分析和总结,以及做隐私实施评估等。

设计安全性分析和检查

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

成功的关键因素和度量标准

成功的关键因素

可交付成果

度量标准

第6章 设计和开发(A4):SDL活动与最佳实践

SDLC/SDL过程中的代码审查

代码生产对于发现软件开发过程中的安全缺陷非常有效。

安全分析工具

静态分析

动态分析

模糊测试

人工代码审查

  • 控制流分析
  • 数据流分析

成功的关键因素和度量标准

成功的关键因素

可交付成果

度量标准

第7章 发布(A5):SDL活动与最佳实践

现在进入了软件开发生命周期的最后阶段,需要确保软件是安全的,隐私问题已经被解决到软件发布时可以接受的程度。
在最后的SDL阶段,对软件的安全检查进行评估,所有的安全活动在这个过程中执行,包括威胁模型、工具输出、早期确定的性能需求在这个过程中会被评估,以确定软件产品是否能够发布。

漏洞扫描

渗透测试

开源许可审查

  • 开源软件协议的遵守
  • 开源软件安全性

最终安全性审查

成功的关键因素和度量标准

成功的关键因素

可交付成果

度量标准

第8章 发布后支持(PRSA1~5)

PRSA1:外部漏洞披露响应

  • 发布后的PSIRT响应
  • 发布后的隐私响应
  • 优化发布后的第三方响应

PRSA2:第三方审查

    1. 提交源代码给第三方进行检查。
    1. 对于每个新版本,与手动渗透测试服务合作,他们亦可以做深浅代码和软件架构设计评估。
    1. 购买、安装和培训开放团队使用内部部署的工具和功能。
    1. 要求代码的第三方供应商在你的应用程序中做同样的操作。

PRSA3:发布后认证

基于各种原因,产品发布后认证的添加被视为一个需求,而不是在开发过程中。

PRSA4:新产品组合后云部署的内部审查

误解:一旦软件已经通过SDL,就可以以任何方式重新使用该软件的代码。

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

  • 遗留代码
  • 兼并和收购

可交付成果

度量标准

第9章 将SDL框架应用到现实世界中

安全地构建软件

  • 编写安全地代码
  • 人工代码审查
  • 静态分析

确定每个项目的正确行为

  • 7个确定性问题

架构和设计

通常,架构流始于需求收集,源自需求,满足需求,然后提出了一个架构细化迭代。

测试

SDL的安全性测试方法的彻底性是关键,测试是SDL纵深防御的关键所在。

  • 功能测试
  • 动态测试

网络扫描、模糊测试。

  • 攻击和渗透测试
  • 独立测试

敏捷:冲刺

成功的关键因素和度量标准

  • 安全编码培训计划
  • 安全编码框架(API)
  • 人工代码审查
  • 独立代码审查和测试(专家或第三方)
  • 静态分析
  • 风险评估法
  • SDL和SDLC的集成
  • 架构人才的发展

度量标准

第10章 集成:应用SDL防止现实的威胁

战略、战术和特定于用户的软件攻击

战略攻击

主要针对于包括规格、计划、能力、程序和知道仿真的信息资产的计划和控制,来获取战略优势。战略软件的目标是对于政府、经济和社会必不可少的基础设施功能的应用程序。这类型的攻击可以归为三大领域:

  • 间谍
  • 犯罪
  • 社会和政治

战术攻击

与战略攻击相比,战术攻击的重要性有所降低。在一些情况下,战术攻击可以用于增强攻击力或增强其他活动,如军事战役或者其他特殊利益行动小组的一个补充活动。

特定于用户的攻击

指定于用户的网络威胁本质上可以是战略性的,战术性的,或者针对个人,针对个人设备。使用战略、战术或公开可用的方法来利用特定的个人或者金融、政治、私人利益的一般用户,将它们作为特定的目标,或作为到达另一个目标的一种手段,或用户随机破解的目标。

软件安全组织的现状和影响力

软件安全的未来预测

坏消息

在大多数情况下,除了威胁建模和架构安全审查之外,这是一门艺术,而不是一门科学,软件安全并不难。
漏洞的后修复期代价是非常搞得。

好消息

来自新的ISO生产标准的压力和最近企业和政府团体安全意识的增加,会使软件安全性拥有高优先级并推动业务发展。
工具和软件安全培训不断提高。

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

对SDL的需求

为什么需要开发更安全的软件?

  • 对于主要的软件开发商

开发更安全的软件和减少来自客户的抱怨是微软启动SDL的原因和目标。SDL的实施需要花费时间、资金和精力,但所获得的收益远大于版本更新、开发和测试安全更新,以及要求客户部署更新的支出。

  • 对于内部软件开发人员

实施SDL的主要获益在于降低隐私和可靠性泄露的风险。

  • 对于小型软件开发者

对于规模较小的公司来说,要求它们承诺开发更安全的软件要困难一些,小型开发工作室通常会在其代码中体现其浓厚的个人风格以及自我行为,将安全仅视为软件质量的一个度量指标而已。

管理层的SDL

SDL成功实施的最关键因素就是管理层的支持。

管理SDL

  • 资源

影响SDL成本的因素:
1.从最初就实施SDL是成本最低的。选择语言、编码标准以及中医的攻击,尽量避免出现错误。
2.对大量“遗留代码”应用SDL的成本是高昂的。
3.同等条件先,在C#、VB.NET或Java等托管代码环境中应用SDL,相比于在C或C++等未托管代码环境而言,更为容易。
4.彻底移除某一特性总会比不断地修复更安全,成本更低。
5.工具通常情况下总是比人工查找漏洞更有效。

软件安全开发生命周期过程

第0阶段:教育和意识

微软安全教育:

第2阶段:项目启动

  • 判断软件安全开发生命周期是否覆盖应用
  • 任命安全顾问

担任开发团队与安全团队之间的沟通桥梁,召集开发团队举行SDL启动会议,对开发团队的设计与威胁模型进行评审,分析并对bug进行分类...

  • 组件安全领导团队

  • 渠道在bug追踪管理过程中包含安全、隐私类bug

SDL必须的bug跟踪域:


安全/隐私bug域应包含的预定义值:

  • 建立“bug标准”

第2阶段:定义并遵从设计最佳实践

  • 常见安全设计原则

  • 受攻击面分析与降低

受攻击面分析ASA
受攻击面降低ASR

第3阶段:产品风险评估

  • 安全风险评估

安装问题、受攻击面问题、移动代码为问题、安全特性相关问题、常规问题。

  • 隐私影响分级

    隐私分级1

    满足以下项:

    隐私分级2

    应用传输匿名数据给软件开发人员或第三方。

    隐私分级3

    应用不包含隐私分级1、2中的任何一种行为。

  • 统一各种因素

第4阶段:风险分析

  • 威胁建模产物

    数据流图(DFD)

  • 对什么进行建模

    最开始应该考虑应用的可信任边界。

  • 创建威胁模型的过程

  • 利用威胁模型辅助代码评审

  • 利用威胁模型辅助测试

第5阶段:为客户创建安全文档、工具以及最佳实践

  • 为什么需要文档和工具?
    为客户提供更为相近的安全信息很重要,一方面能安全地部署产品,另一方面使其能够切实理解所做出的安全配置策略的真实含义。
  • 创建指导性安全最佳实践文档

安装文档、主线产品使用文档、帮助文档、开发人员文档。

  • 创建工具
    安全配置向导SCW:

第6阶段:安全编码策略

  • 使用最新版本编译器与支持工具

  • 使用编译器内置防御特性
    主要防护选项:

  • 使用源代码分析工具

  • 切勿使用违禁函数

  • 减少潜在可悲利用的编码结构或设计

  • 使用安全编码检查清单

第7阶段:安全测试策略

  • 模糊(Fuzz)测试

    三种主要的解析器:

  • 渗透测试

    APPVerif之类的工具检测代码执行时的某些特定类型bug。
    Driver Verifier用于针对设备驱动程序解析类似测试。

  • 运行时(Run—Time)验证

  • 必要时审核并更新威胁模型

  • 重估软件受攻击面

第8阶段:安全推动活动

  • 准备安全推进活动

  • 培训

  • 代码审核

  • 威胁模型更新

  • 安全测试

  • 受攻击面Scrub

  • 文档Scrub

第9阶段:最终安全评审

  • 产品团队协调
  • 威胁模型评审
  • 未修复的安全bug评审
  • 工具有效性验证
  • 在最终安全评审完成之后

第10阶段:安全响应计划

  • 为什么准备响应?

    你的开发团队一定会出错

    新漏洞一定会出现

    规则一定会发生变化

  • 准备响应

    组建一个安全响应中心
    安全响应过程:

  • 安全响应与开发团队

    组建你的响应团队

    支持你的全线产品

    支持你的所有客户

    使你的产品具备更新能力

    在研究人员之前找到漏洞

第11阶段:产品发布

无论采用CD、DVD还是Web下载等方式发布产品,都必须完成整个SDL过程,才能使产品满足所规定的安全和隐私性要求。

第12阶段:执行安全响应

  • 遵从你的计划

    保持冷静

    欲速则不达

    留意可能改变计划的事件

    遵从你的计划

  • 尽你所能补救

    知道联络何人

    能创建更新

    能安装更新

    明确轻重缓急

  • 深谙取舍之道

SDL参考资料

在敏捷模式中集成SDL

  • 在敏捷模式中进行SDL实践活动

    安全教育

    项目开始

    建立并遵从设计最佳实践

    风险分析

    创建安全文档、工具以及客
    户最佳实践

    安全编码与测试策略

    安全推进

    最终安全评审

    产品发布

    安全响应执行

  • 利用SDL实践增强敏捷模式

    敏捷原则:

SDL违禁函数调用

违禁API




选择StrSafe VS Safe CRT

SDL最低加密标准

高级加密需求

  • 使用加密库

    切勿构造自己的加密库,更不要构造自己的加密算法。

加密算法的用法

数据存储以及随机数生成

  • 存储私钥以及敏感数据
  • 生成随机数与密钥
  • 使用密码或者其他密钥来生成随机数和加密密钥

SDL必备工具以及编译器选项

  • 必备工具

威胁树模式

  • 假冒外部实体或过程的威胁树

  • 篡改一个过程的威胁树

  • 篡改一个数据流的威胁树

  • 篡改一个数据存储的威胁树

  • 抵赖威胁树

  • 过程信息泄露的威胁树

  • 数据流信息泄露威胁树

  • 数据存储信息泄露的威胁树

  • 针对过程的拒绝服务威胁树

  • 针对数据流的拒绝服务威胁树

  • 针对数据存储的拒绝服务威胁树

  • 特权提升威胁树

posted @ 2023-05-07 21:25  少管我  阅读(24)  评论(0编辑  收藏  举报