实验二 电子公文传输系统安全——读书笔记

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

第2章 安全开发生命周期

• 安全开发生命周期（Secure Development Lifestyle，SDL）
• 软件开发生命周期（Software Development Lifestyle，SDLC）
• 本书的目标是：基于最少的资源和最佳实践创建SDL，而不是所需资源超出大多数软件安全团队所能接受的范围。

2.1 克服软件安全中的挑战

• SDL是软件安全演化的关键步骤，有助于人们重视构建安全的软件开发生命周期。
• 过去人们认为，一个安全的网络基础设施将会提供针对恶意攻击所需的保护级别。然而，最近几年，已经证明单纯的网络安全不足以防止这种攻击。用户已经可以通过相关技术成功渗透有效的渠道认证，相关技术包括跨站点脚本（Cross-Site Scripting，XSS）、结构化查询语言（Structured Query Language，SQL）注入和缓冲区溢出漏洞利用技术等。在这种情况下，系统资产被泄露，数据和组织的完整性也遭到破坏。
• 安全行业一直试图尝试通过应急措施来解决软件安全问题。首先是平台安全（OS安全），然后是网络/周边安全，以及现在的应用程序安全。我们确实需要深度防御来保护我们的资产，但从根本上它是一个软件安全漏洞，需要通过SDL方法进行修复。
• SDL拥有开发行业、政府标准和最佳实践强化软件所需的所有活动与安全控制，它们也是SDL的基本组件。
• 安全不再单纯是一个网络要求，它现在是一个信息技术（IT）要求，其中包括所有的软件开发意图分发、存储和处理信息。
• SDL程序的实现，能够保证良好的企业软件设计和开发固有的安全，而不是在产品发布后。
• 最著名的SDL模型是可信计算安全开发生命周期（或SDL），微软已经将它应用到需要承受恶意攻击的软件开发中。微软的SDL已经发展了十多年，被认为是排名前三的成熟模型。其他受欢迎的SDL模型有Cigital公司的软件安全触点模型（Software Security Touchpoints model）、OWASP SDL和思科的安全开发生命周期（Cisco Secure Development Lifecycle，CSDL）。

2.2 软件安全成熟度模型

• 近年来，两个非常流行的软件安全成熟度模型已先后开发并继续快速地成熟。一个是Cigital的内置安全成熟度模型（Building Security in Maturity Model，BSMM），另一个是OWASP（Open Web Application Security Project，开放Web应用安全项目）的开放软件保证成熟度模型（Software Assurance Maturity Model，SAMM）。
• BSIMM是一项面向真实软件安全措施的研究，帮助你确定软件安全措施和如何组织工作时间。BSMM是Cigital开发的一系列最佳实践，分析9个领先的软件安全措施的真实数据，并基于成功的公共区域创建框架。有12个实践组织为4个域。这些实践都用于组织109个BSIMM活动（BSIMM4共有111个活动）。通过研究这9个措施都在干些什么，BSMM的创造者能够建立一个最佳实践模型，该模型分解为软件制造商可以遵循的12个类：
  1. 策略和度量标准
  2. 符合性和政策
  3. 培训
  4. 攻击模型
  5. 安全特征和设计
  6. 标准和要求
  7. 架构分析
  8. 代码审查
  9. 安全测试
  10. 渗透测试
  11. 软件环境
  12. 配置和漏洞管理网
• OWASP的软件保证成熟度模型（SAMM）是一个灵活的规范性框架，用于把安全性融入软件开发组织。通过覆盖多于典型的SDLC基础模型的安全性，SAMM使得组织能够自行评估其安全保障程序，然后使用建议的路线图在组织面对的特定风险方面有所改进。除此之外，SAMM能够创建记分卡，记录在典型的管理、开发和部署业务功能过程中组织在安全开发方面的有效性。记分卡也能够在组织内部实现管理，通过迭代建立安全保证程序来说明量化的改进。

2.3 IS0/IEC 27034：信息技术、安全技术、应用安全

• 2011年，国际标准化组织（International Standards Organization，ISO）/国际电工委员会（International Electrotechnical Commission，IEC）发布ISO/IEC27034-l：2011中6个应用安全标准的第1部分。该标准提供了一个简洁并且国际公认的方式来获得厂商/供应商软件安全管理流程的透明性。
• 在撰写本书时，第2~6部分仍处于工作草案阶段，由以下5部分组成：第2部分，组织规范性框架：第3部分，应用安全管理流程：第4部分，应用安全验证：第5部分，协议和应用安全控制数据结构；第6部分，具体应用的安全指导。
• ISO/IEC制定了ISO/IEC 27001标准（纳入ISO/IEC 17799，这一直是信息安全事实上的ISO标准）。它是一个信息安全管理体系（Information Security Management System，ISMS）标准，通过制定一个管理体系获得正式管理控制下的信息安全。它规定了一个组织采用该标准时需要满足的具体要求。该标准从整体上解决了信息安全问题，囊括了从物理安全到规范的所有内容。行业踊跃采用该实践，IS0/IEC 27001是当今面向信息安全管理体系（ISMS）的领先标准。

2.4 其他SDL最佳实践的资源

2.4.1 SAFECode

• 卓越代码软件保膝论坛（Software Assurance Forum for Excellence in Code，SAFECode）是一个非营利性组织，致力于通过先进有效的软件保证方法，增加信息、通信技术产品和服务的可信性。SAFECod是一项全球性的、行业主导的工作，确定和推广开发提供更安全可靠的软件、硬件和服务的最佳实践。它意味着提供一系列基础的安全开发实践，在不同的开发环境下由SAFECode成员实际实现的软件安全已得到有效改善。

2.4.2 美国国土安全软件保障计划

• 自2004年以来，美国国土安全部（Department of Homeland Security，DHS）软件保障计划已资助了网站内置安全（Build Security In，BSI）的开发。BSI的内容基于以下原则：软件安全本质上是一个软件工程问题，必须在整个SDLC中以一种系统的方式进行管理。美国国土安全部国家网络安全办公室（National Cyber Security Division，.NCSD）的软件保障（Software Assurance，SwA）计划旨在减少软件漏洞，最大限度地减少开发，以及改善可信软件产品的日常开发和部署。与开放政府指令一致，该计划促使公共和私营部门合作，包括开发、发布和推广实用指南与工具的使用；促进更安全、更可靠软件产品的投资。

2.4.3 美国国家标准与枝术研究院

• 美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）主要向政府和企业信息安全社区提供研究、信息和工具。以下是NST贡献给软件安全社区的一些关键领域。
  • NIST的软件保障度量和工具测量（Software Assurance Metrics And Tool Evaluation，SAMATE）项目致力于开发软件工具测量方法（测量工具和技术的有效性，确定工具和方法之间的差异）以提高软件保障。该项目支持美国国土安全部的软件保障工具和研发需求识别计划一一特别是第3部分：技术（工具和要求）、识别、增强和软件保障工具的开发。
  • NIST特别出版物（Special Publication，SP）800-64，《系统开发生命周期中的安全考虑》，已在完善中，以协助联邦政府机构把重要的信息技术安全步骤整合到他们现有的T系统开发生命周期中。这个安全考虑指导原则适用于除了国家安全系统之外所有的联邦T系统。
  • 美国国家漏洞数据库（National Vulnerability Database，NVD）是基于标准的漏洞管理数据使用安全内容自动化协议（Security Content Automation Protocol，SCAP）表示的美国政府资料库。这些数据实现了漏洞管理、安全测量和合规的自动化。

2.4.4 MITRE公司公共计算机漏洞和暴露

• MITRE公司公共计算机漏洞和暴露（Computer Vulnerability and Exposure，CVE）是一个被广泛认同的信息安全漏洞和暴露的清单。CVE的目标是使用这个“共同枚举”能够更容易地在独立的漏洞功能（工具库、存储库和服务）间共享。

2.4.5 SANS研究所高级网络安全风险

• SANS研究所高级网络安全风险，之前的SANS 20个最关键的互联网安全漏洞，是互联网安全中最关键问题领域的一个共识列表，如果系统上存在这些漏洞就需要立即修复。纠正这些安全缺陷的步骤说明和更多信息的链接也作为该列表的一部分。SANS列表包括CVE标识符来唯一标识它描述的漏洞。这有助于系统管理员使用CVE兼容的产品和服务，使他们的网络更安全。

2.4.6 美国国防部网络安全与信息系统信息分析中心

• 2012年9月，软件数据与分析中心（Data&Analysis Center for Software，DACS）、信息保障技术分析中心（Information Assurance Technology Analysis Center，IATAC）和建模与仿真信息分析中心（Modeling and Simulation Information Analysis Center，MSIAC）合并，成立了网络安全与信息系统信息分析中心（Cyber Security and Information Systems Information AnalysisCenter，CSIAC）。CSIAC是美国国防技术信息中心（Defense Technical Information Center，DTIC）资助的8个信息分析中心之一，执行必要的基本操作中心（Basic Center of Operations，BCO）功能，实现网络安全、信息保障、知识管理和信息共享、软件密集型系统工程以及建模和仿真的使命和目标，其适用于美国国防部研究开发测试和评估（Research DevelopmentTest and Evaluation，EDT&E）以及收购社区的需求。过去，DACS已经为社区提供了一些关于软件安全和SDL的优秀文档，尤其是，“提高开发生命周期以生产安全软件：软件保障参考指南”（2008）B0和联合IATAC/DACS的报告“软件安全保障：技术现状报告”（SOAR）（2008），我们期望他们能够在CSIAC的保护伞下继续这样做。

2.4.7 CERT、Bugtraq和SecurityFocus

• 除了上面讨论的资源以外，卡内基梅隆计算机应急响应小组（Computer EmergencyReadiness Team，CERT）、Bugtraq）和SecurityFocus是读者应该知道的其他3个资源。
• CERT提供安全漏洞的及时警报和漏洞的每周总结公告（CERT网络安全公告）。公告中的信息包括CVSS分数和CVE ID，后者用来唯一标识漏洞。汇编结果建立在过去的一周中NIST NVD）所记录的基础之上。本书后面的章节将详细讨论CVSS打分过程。
• Bugtraq是一种电子安全邮件列表，提供安全漏洞信息和来自供应商的安全公告及通知。该列表通常包含额外的信息，例如漏洞利用示例和已发现问题的修复。Bugtraq是SecurityFocus安全门户网站的一部分，其目前由赛门铁克（Symantec）所有。Bugtraq是许多通过SecurityFocus的安全邮件列表之一。还有其他一些有用的邮件列表，如专用于微软、Linux、DS和意外事件的邮件列表。

2.5 关键工具和人才

2.5.1 工具

2.5.1.1 模糊测试

• 模糊测试（Fuzz testing/Fuzzing）是一种自动或半自动化的黑盒软件测试技术，它为某一计算机软件程序输入提供了无效、意外或者随机数据。换句话说，它通过使用一种自动化的畸形/半畸形数据注入方式发现bug或者安全缺陷。软件程序的输入用于监控异常返回，如崩溃、出错的内置代码断言和潜在的内存泄漏。模糊测试已成为测试软件或计算机系统安全问题的一个关键要素。相对于其他工具，模糊测试一个明显的优势是，其测试设计非常简单并且与系统行为无关。
• 模糊测试是软件安全的关键要素，必须嵌入到SDL中。有很多供应商在这个领域可供选择，有的开发商甚至开发他们自己的工具。两个流行的模糊测试工具是Codenomicon和Peach Fuzzing Tool，Codenomicon是市场上可用的最成熟的模糊测试工具之一，PeachFuzzing Tool是更受欢迎的开源工具之一。正如在本书后面章节所看到的，模糊测试工具在SDL中使用的时机是至关重要的。还应当注意的是，模糊测试适用于安全和质量保障测试。
• 在很多软件开发计划中，已认为模糊测试既是一个关键要素，也是一个主要的不足之处，因此它现在是美国国防部的信息保障认证和认定程序（Defense Information AssuranceCertification and Accreditation Process，DIACAP）的要求。

2.5.1.2 静态分析

• 静态程序分析是指在不实际运行程序的条件下，进行计算机软件分析的方法。它主要针对特定版本的源代码，也有些静态程序分析的对象是目标代码。与此相反，动态分析需要在程序运行时才能进行。静态分析是通过一个自动化的软件工具进行的，不应与人工分析或者软件安全架构评审相混淆，其中涉及人工代码评审、程序认识和理解。如果使用得当，静态分析工具相对于人工静态分析具有明显的优势，即分析能够更加频繁地进行，安全知识普遍优于标准的软件开发人员。它还给予经验丰富的软件安全架构师或者工程师充足的时间，只需在绝对必要的时候他们出现即可。
• 静态分析，也称为静态应用安全测试（Static Application Security Testing，SAST），在一个项目的开发或质量保障阶段识别漏洞。它提供了行代码级检测，使得开发团队能够快速地修补漏洞。
• 静态分析工具的使用和适合环境的供应商的选择是成功的另一个关键技术要素。任何有利于自动化软件开发过程中任何部分的技术都是值得欢迎的，但因为并没有在选择工具或工具集的过程中使用合适的人和过程，这个软件已经成为许多组织的搁置软件（shelf-ware）。在这个空间中不是所有的工具都是一样的，在某些语言上有些工具表现得更好，尽管其他工具有很大的治理/风险/合规性（Governance/.Risk/Compliance，.GRC）和度量分析。在某些情况下，需要使用多达三个不同的工具才能有效实施。最后，需要选择合适的工具，需要支持语言、可伸缩、可以嵌入到开发过程中以及拥有最低的误报率。
• 软件开发是一项复杂的业务，对于大多数组织来说，任何能够使这一过程更加可重复、可预测并减少“摩擦”的举措都是一个巨大的胜利。使用静态分析工具有很多好处。最重要的原因有以下几个。
  • 静态分析工具可以缩短时间。它们可以非常快速地评审大量的代码，这是人类无法做到的。
  • 静态分析工具不会感到疲惫。静态分析工具在凌晨2:00连续运行4个小时和在上班时间运行效果不变。但对于人类评审者来说，效果是不可能一样的。
  • 静态分析工具帮助开发人员了解安全漏洞。在许多情况下，可以使用这些工具和来自供应商的教育资源，对开发团队开展软件安全方面的教育。

2.5.1.3 动态分析

• 动态程序分析是指在真实或者虚拟处理器中运行程序的条件下，进行计算机软件分析的方法。目的是在程序运行时找到程序的安全错误，而不是反复地离线审查代码。通过在设计程序的所有场景下调试它，动态分析避免了人为创造可能产生错误的情景。它有一个显著的优势，即有能力识别可能已经漏报的漏洞，以及验证静态代码分析的结果。
• 动态分析，也称为动态应用安全测试（Dynamic Application Security Testing，DAST），能够确定应用程序中的漏洞。这些工具用于快速地评估系统的整体安全，并使用在SDL和SDLC中。有关使用静态分析工具的优点和注意事项同样适用于动态分析工具。一些流行的SAST供应商的产品包括：Coverity、HP Fortify Static Code Analyzer、IBM SecurityAppScan Source、Klocwork、Parasoft网和Veracode），而比较流行的DAST供应商的产品包括：HP eblnspect、QAinspect、IBM Security AppScan Enterprise、Veracode和WhiteHat Sentinel Source。

2.5.2 人才

2.5.2.1 软件安全架构师

• 软件安全架构师负责提供整个X公司产品安全的架构和技术指导。产品安全架构师将设计、计划和实现安全编码实践和安全测试方法：确保该实践符合软件认证过程：推动产品的安全测试；测试和评估安全相关的工具；管理第三方供应商以满足上述这些责任。具体的角色和职责包括以下方面。
  • 推动整体软件安全架构。
  • 提供技术指导，如在全面计划、开发和X公司软件安全努力的执行中提供技术指导。
  • 与产品和工程开发团队紧密合作，确保产品符合或超过用户的安全和认证需求。其中包括确保安全架构具有良好的文档记录并经过沟通。
  • 提供给软件工程和产品开发过程的计划与输入。这里涉及安全，并对企业的约束和需求很敏感。
  • 监控安全技术的发展趋势和需求，如新技术下出现的标准。
  • 制定并执行安全计划。这可能包括管理与第三方供应商的合作开发，并为工程和测试实践提供指导（与其他部门一起）。
  • 保证和创建（如果需要）安全策略、过程、实践和操作，确保可重复开发和高质量，同时控制成本。
  • 从事实际深入的软件分析、评审和设计，包括从安全角度来看源代码的技术评审和分析。这将会包括内部开发代码和第三方供应商提供的技术评审
  • 。在安全认证过程中提供主要技术角色，包括准备大量的文档和与第三方评估合作。
  • 为员工、合约商、开发人员、质量保障团队和与产品安全相关的产品/软件安全拥护者提供培训。
  • 指导X公司软件开发团队通过面向SDLC的安全开发生命周期（SDL）设计，参与设计评审、威胁建模、代码和系统的深入安全渗透测试。把这些职责延伸到提供应用设计的输人、安全编码实践、日志取证、日志设计和应用代码。

2.5.2.2 软件安全从业者

• 一个软件安全拥护者典型的工作描述如下所示。
  • SSC必须有至少3~5年的软件开发经验：愿意从事软件安全或者有相关的背景；有时间接受软件安全和中央业务单元特定的软件安全团队工具、计划和过程的培训；最重要的是，不仅要知道如何开发软件，还要了解如何“像黑客一样思考”并拆解软件，即考虑到攻击者利用软件采用的所有可能的途径或攻击。
  • 每一个产品开发组织应该至少有一个人拥有技术能力并能被训练成软件安全从业者，并最终作为初级软件安全架构师协助中央软件安全团队进行架构安全分析/威胁建模。理想情况下，除了面向技术的产品安全从业者，如果认为有必要，每一个团队应该有一个额外的产品安全从业者协助作为一个变更代理（更多面向项目/计划的个人）。
  • 具体的角色和职责包括以下几个。
    • 强制实施SDL：协助中央软件安全团队保证安全租户的机密性、完整性和可用性都持续包含在SDL中，作为X SDLC公司的一部分。
    • 评审：协助中央软件安全团队软件安全架构师构建架构安全分析、评审和威胁建模。
    • 工具专家：代表每一个开发团队、产品团队和/或业务单元中的中央软件安全团队软件安全工具专家（例如，静态、动态分析和模糊测试）。
    • 搭配：作为每一个开发团队、产品团队和业务单元的中央软件安全团队的眼睛、耳朵和支持者。
    • 参加会议：作为一个全球X公司软件安全领军团队的成员，参加每月的电话会议和一年两次的面对面会议（在预算允许的前提下）。

2.6 最小特权原则

• 在信息安全、计算机科学以及其他领域，最小特权原则（the principle of least privilege）规定，在计算环境特定的抽象层中，每一个模块（如过程、用户或程序，取决于主题）仅仅能访问合法目的所必需的信息和资源。
• 限制特权提升是威胁建模的重要部分，其也是SDL架构（A2）阶段的一个核心组成部分。特权提升的概念是非常重要的，它是微软安全开发生命周期卡片游戏的主题，旨在培养开发人员和安全专业人员快速、轻松地找到软件或计算机系统的威胁。未经授权的权限提升攻击利用程序错误或设计缺陷，赋予攻击者访问网铬及其相关的数据和应用程序的提升权限。这些攻击可以是垂直的（攻击者赋予自己特权），或水平的（攻击者使用已经赋予的相同水平的特权），但假设他拥有具有相似权限的另一个用户的身份。
• 确保最小特权防止敏感数据泄露，并防止未经授权的用户访问程序或者他们未曾想要访问的区域。软件设计应遵循最小特权原则，这是软件发展的一个关键因素。限制特权等级是非常重要的，因为特权提升可以导致攻击者获得超过授予一个普通用户的授权。例如，若拥有普通用户特权的攻击者有“只读”权限，则他或许能够破解软件进而提升权限以获得“读写”权限。推动最小权限要求用户获得执行一个特定任务所必需的最小权限。在SDL/SDLC的设计阶段，你需要确定执行工作所需的特权最小集合，限制用户登录到只有这些特权的域中。确保最小特权不仅包括用户权限的限制，还包括资源权限的限制，比如CPU限制、内存、网络和文件系统权限。这就要求将权限授予一个对象之前满足多个条件，因为仅仅检查一种状况下的访问可能无法满足强安全性。例如，如果攻击者能够获得一个特权，但没有获得第二个特权，将会限制其实施成功的攻击。将软件隔离到需要多次检查访问的单独组件中，可以抑制攻击或者可能阻止攻击者接管整个系统。访问权限的慎重授权可以限制攻击者成功地攻击软件或系统。资源的最小权利和访问应限于完成该任务需要的最短时间内。

2.7 隐私

• 保护用户的隐私是SDL过程的另一个重要组成部分，应被视为SDLC所有阶段重要的系统设计原则。用户隐私安全出了问题将导致信任危机。由于在未经授权访问的用户越来越多的情况下，个人信息在媒体中公开，在软件和系统中使得客户的数据得到可靠保护的状况日益恶化。此外，许多新的隐私法律法规强调了在软件和系统的设计和开的包含隐私的重要性。至于安全性，已经通过的软件开发生命周期的进度的变更是成本很高的，就是把高成本的隐私保护方法和技术融入SDLC的适当阶段，以维护个人的隐私，并保护个人身份信息（PII）的数据。包含在微软SDL中的一些关键的隐私设计原则，包括提供有关数据收集、存储或者共享的适当通知，使用户可以对自己的个人信息做出明智的决策；使用户策略和控制可用；最小化数据收集和敏感性；以及存储保护和数据传送。
• 至关重要的是，隐私保护措施通过SDL实现的最佳实践构建到了SDLC中。忽略用户的隐私问题可能会导致诉讼、媒体负面报道和不信任。

2.8 度量标准的重要性

• 安全度量标准是可用于评估一个组织软件安全计划有效性的宝贵资源。有意义的度量标准，可用于不断改进产品安全程序的性能，证明合规性，提高管理和利益相关者的安全意识水平，并协助决策者提供资金的请求。如果没有度量标准，每个企业都恐惧、不确定和怀疑下管理其产品。
• 有意义的安全度量标准允许一个组织确定其安全控制的有效性。为了有效地衡量一个组织的安全状况，产品的安全性首先要保证适当的框架到位，以得出有意义的度量数据。这包括适合于产品的安全治理模式、企业的战略和运营要求。这样的模式应该实现实用的产品安全政策和程序，统一部署最佳做法和措施，并要求在整个组织强有力地执行管理支持。最佳实践要求下的安全性是作为一个企业的水平、垂直和跨职能管理整个组织的模型。这种模式更适合于实现一致的监测、计量和报告企业的产品安全状况。
• 对有效测量的安全性，它必须得到有效的管理。当公司努力保护宝贵的信息资产和论证基于风险的决策时，集中度量报告机制对于产生有意义的指标，并提供软件开发组织中的产品安全状况的持续评估至关重要。

2.9 把SDL映射到软件开发生命周期

• 无论你使用何种SDL模式，不论它是否已经存在，一个你自己开发的或者是两者的结合，都必须将其映射到当前的SDLC才能有效。安全可以内置到每一个SDLC阶段中——安全到SDLC的映射。如果安全内置到每一个SDLC阶段，那么该软件默认有较高的概率是安全的，后续软件的变化是不太可能危及到整体安全的。这种映射的另一个好处是，你将有可能与SDL的拥有者和的利益相关者一起工作，这将有助于在SDLC的操作和业务过程中构建买进、高效和可实现的安全，将可能包括开发人员、产品和项目经理、业务经理以及主管。

2.10 软件开发方法

2.10.1 瀑布开发

• 瀑布开发是较传统的软件开发方法的别称。这种方法通常高风险、高成本，而且比敏捷方法低效。瀑布方法使用那些已知的要求，下一个阶段开始之前每个阶段结束，并需要大量的文档，因为这是在整个过程中的主要通信机制。虽然大多数开发组织正在转向敏捷开发方法，当需求得到充分理解或不是很复杂时，依然使用瀑布方法。使用瀑布方法，一旦某一阶段完成将不会重复访问，因此第一次必须正确：通常没有第二次机会。

• 虽然瀑布开发方法有所不同，但它们往往是类似的，即参与者尽量保持最初的计划、直到周期的晚期才有可行软件，假设他们知道前期的所有事情，通过一个变更控制委员会最小化变化（即，假设变化是坏的和可以控制的），给予项目经理（Project Manager，PM）大部分责任，优化与进度和预算的一致性，通常采用弱控制，并且允许仅在完成时实现价值。它们由一个以PM为中心的方法驱动，即如果遵守计划中的过程，那么一切工作将会按照计划进行。在今天的开发环境中，在前面的句子中列出的大部分项目被认为是瀑布方法的负面属性，这是行业转向敏捷开发方法的原因。瀑布方法可以看作一个流水线方法，当恰当地应用于硬件时它是出色的，但就软件开发而论，它与敏捷方法相比有缺点。
  

• 迭代瀑布开发

  • 迭代瀑布开发模型是标准瀑布模型的改进。这种方法比传统的瀑布方法风险较小，但比敏捷方法风险大且效率较低。在迭代瀑布方法中，整体项目分为不同的阶段，每一阶段采用传统的瀑布方法各自执行。分解较大的项目为较小的可识别的阶段，将会导致每一个阶段对应一个较小的范围，在转向下一个阶段之前，根据需要，每一个阶段的最终交付成果能够被评审和改进。因此，整体风险降低。虽然迭代法是传统瀑布方法的改进，但是在今天的环境中，你更可能要面对的是敏捷软件开发方法，而不是标准或者迭代瀑布方法。
    

2.10.2 敏捷开发

• 敏捷方法是基于迭代和增量的开发方法。需求和解决方案通过自组织、跨职能的团队之间的协同推进，并且从每一次迭代中产生的解决方案在整个过程中定期回顾和提炼。敏捷方法是一个时间可控的迭代方法，有利于快速灵活地响应变化，从而鼓励演进式开发并交付，同时促进整个项目生命周期中的适应性计划、开发、团队合作、协作和过程适应性。任务被分解成需要最小计划的增量。这些迭代称为“时间盒”，它可以持续1~4周。发布一个产品或多个新功能可能需要多次迭代。跨职能团队负责每次迭代中所有的软件开发功能，包括计划、需求分析、设计、编码、单元测试和验收测试。一个敏捷项目通常是跨职能的，自组织团队与任何层次的企业或个人团队成员（自己决定如何满足每一个迭代的需求）独立工作。这使得项目能够快速适应变化并最小化整体风险。目标是在每一次迭代的结束，有一个可用的发布和一个展示给利益相关者的可行产品。

2.10.2.1 Scrum

• Scum是一种迭代和增量敏捷软件开发方法，用于管理软件项目、产品或者应用程序开发。Scum采用一种经验方法，接受该问题不能被完全理解或定义，而将重点放在最大限度地提高团队的交付，并迅速响应新出现的需求。这是通过使用协同定位和所有学科可以表示的自组织团队完成的。相较于传统计划或预测的方法，这个概念有利于促进客户（在项目开发过程中改变需求）处理生产的能力。Scum开发的基本单元称为一个“冲刺”（spit），能够持续一周到一个月。每个冲刺是时间可控的，使产品的成品部分按时完成。这些需求的优先级列表是从产品积存中衍生的，如果它们在冲刺过程中没有完成，它们将被忽略并返回产品积存中。该团队演示了每一个冲刺完成后的软件。Scum普遍接受的增值属性包括自适应计划的使用；它需要第一个冲刺（通常为两周）早期可行软件的反馈；它强调好的改变的最大化，如专注于最大限度地提高整个项目的学习；它把大部分责任放在小的、专注于思维的适应性团队，计划和重新计划自己的工作；它具有较强的和频繁的控制；优化业务价值、上市时间和质量；支持较早实现价值（可能在每次冲刺后）。
  

2.10.2.2 精益开发

• 根据我们的经验，对于那些已经或者正在从瀑布方法中转变的软件开发者来说，Scum是敏捷开发各种方法中最有可能遇到的。精益是另一种日益普及的方法，值得一说。遗憾的是，精益有许多定义，它是一种在很多方向发展的方法。虽然和Scum类似，精益也关注功能而不是群功能，但精益将这个想法更进一步，即在选择、计划、开发、测试和部署下一个功能之前，以最简单的形式选择、计划、开发、测试和部署当前功能。其目的是进一步隔离个体功能等级的风险。这种隔离的优点是专注于尽可能避免“浪费”，除非绝对必要或者相关，否则将什么都不做。
• 基于精益生产原则的概念，精益开发方法可以概括为7个基本“精益”原则：（1）避免浪费，（2）增强学习，（3）尽量推迟决策，（4）尽快交付，（5）授权团队，（6）嵌入完整性，（7）着眼整体。精益开发方法的关键要素之一是提供种着眼整体的模型，即使开发人员分散在多个位置和合约商中。虽然社区中许多人依然认为其和敏捷相关，但精益软件开发方法已经演变成一门相关学科，而不是一个特定的敏捷开发方法。
  

安全评估(A1)

• 安全评估是安全开发生命周期的第一个阶段，在这个阶段中，要解决四项原则问题：
  • 软件满足客户任务和关键程度如何？
  • 软件所必需的安全目标是什么？
  • 那些法规和政策是适用于确定什么需要保护的？
  • 在给软件运行的环境中又可能存在什么威胁？
• 在这一阶段，软件安全团队提早参与项目并主持发现会议，创建SDL项目计划。启动隐私影响评估（PIA），PIA主要包含以下要点：
  • 立法摘要
  • 所需的工艺步骤
  • 技术和技巧
  • 其他资源
• 安全评估成功的关键因素和度量标准
  
  
• 度量标准
  • 软件安全团队循环的时间
  • 参加SDL的利益相关者的百分比
  • SDL活动映射到开发活动的百分比
  • 安全目标满足的百分比

架构(A2)

• 在安全开发生命周期的第二阶段，安全方面的考虑被带入软件开发生命周期，以确保所有的威胁、要求、功能和集成方面的潜在制约因素均被考虑到。

• 威胁建模五个步骤：

  • 确定安全目标
  • 调查应用程序
  • 分解它
  • 识别威胁
  • 确定漏洞
    

• DREAD模型：潜在损害、可重复性、可利用性、受影响的用户和可发现性，1-10用于建立风险评级，数字越高，风险越严重。DREAD算法用来计算风险值，是DREAD类别的平均值

• 成功的关键因素
  
  

• 度量标准

  • 业务微威胁、技术威胁和威胁参与者的列表
  • 这个阶段之后不满足的安全目标个数
  • 遵守公司政策的百分比
  • 软件入口点的数量
  • 风险接受、减轻和容忍的百分比
  • 重新定义的初始软件需求百分比
  • 产品中计划的软件体系结构的变化数量
  • 根据安全要求所需的软件体系结构更改数量

设计和开发（A3）

• 设计和开发是软件最终用户最为关心的部分。在这个阶段你会做策略一致性分析，创建测试计划文档，更新威胁模型(根据需要)，进行安全性设计分析和总结，以及做隐私实施评估等，帮助你安全地部署软件、建立开发最佳实践，从而在开发阶段的早期消除安全问题和隐私问题。你将会在SDL的设计和开发(A3)以及发布(A4)阶段进行静态分析。
• 安全测试的通用步骤：定义测试脚本、定义用户社区、识别项目障碍物、识别内部资源、识别外部资源。测试技术主要分为白盒、灰盒或黑盒。
  • 白盒：从内部的角度测试软件，包括：源代码分析、基于属性、源代码错误注入
  • 灰盒：设计测试用例的目的是分析源代码，同时也使用黑盒技术，包括：源代码错误注入、动态代码分析、二进制错误注入
  • 黑盒：从外部的角度测试软件，没有关于软件的任何知识，包括：二进制错误注入、模糊测试、二进制代码分析、字节码分析、黑盒调试、漏洞扫描、渗透测试。
• 成功的关键因素和度量标准
  
  
  

设计和开发（A4）

• A4策略一致性分析是A3策略依赖检查的延续，在这个阶段，任何存在于SDL域之外的策略都要被检查或者重新检查。安全测试是一个耗时的过程，需要适当的准备，确保前后一致，并协调所有利益相关方，以及对什么是真正测试内容的深刻理解。安全测试贯穿整个SDLC过程，在典型的SDLC周期中，软件需要通过QA（质量保证）测试，包括单元测试、性能测试、系统测试和回归测试。安全测试用例执行主要从两个方面开展：安全机制和安全测试。对软件产品和相关系统采取的三种特定的测试类型：基准测试、预定测试和探索测试。

• 代码审查对于发现软件开发过程中的安全缺陷非常有效，代码审查可以让我们在代码测试或安装之前就找到和修复大量安全问题。有四种分析软件应用安全性的基本技术：自动扫描、人工渗透测试、静态分析、人工代码审查
  

• 安全分析工具包括静态分析、动态分析、模糊测试和人工代码检查。每种方法各有优缺点。静态分析是在计算机软件实际上不执行的情况下进行的测试，也称为静态应用程序安全分析（SATA）。动态分析是通过再真实或虚拟处理器上运行程序进行计算机软件分析的方法，也称为动态应用软件安全检测（DAST），用来确认应用软件产品中的漏洞。模糊测试是一种自动化或半自动化的黑盒软件测试技术，他为计算机软件输入提供非法的、非预期的数据或随机数据。必须嵌入在SDL中。人工代码审查是通常对软件产品进行逐行检查以发现安全漏洞的方法，有更高的精确性和质量，但是最耗费资源

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

发布（A5）

• 这是软件开发生命周期的最后阶段，需要确保软件是安全的，隐私问题已经被解决到软件发布时可以接受的程度。该阶段需要进行漏洞扫描，利用应用程序和数据库签名尝试确认应用程序缺陷的存在。渗透测试是模拟黑客行为对软件系统进行的白盒安全分析。开源软件必须按照资产进行管理，遵循许可证，必须像内部开发软件标准一样满足安全需求，所以要进行开源审查。最后要进行最终安全性审查，对所有安全活动进行重新评估以确认软件产品是否为发布做好准备。还要进行最终隐私性审查。
• 成功的关键因素
  
  
• 度量标准
  • 遵守公司策略的百分比
  • 安全漏洞扫描和渗透测试发现的安全问题的数量、类型和严重性
  • 发现的安全问题的修复数量
  • 发现的严重问题的数量、类型、严重性
  • 遵守安全和隐私需求的百分比

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

对SDL的需求

• 隐私与安全：隐私可以看作是遵守策略的一种方式，安全则看做是一种执行策略的方式。隐私问题的核心是符合监管部门的要求、公司策略和客户期望。关于安全还需要考虑的一个因素是与客户签订的服务水平协议（SLA）和维护时间。安全与可靠性存在显著差别，但有时候可能会产生冲突。微软可信计算最初关注四个方面，其中三个是技术方面：安全、隐私和可靠性。下图为质量、安全、隐私和可靠性之间的关系
  

• 当前的软件开发方法不足以生成安全的软件，主要有以下四种：

  • “只要给予足够的关注，所有的缺陷都将无处遁形”
  • 专利软件开发模式
  • 敏捷软件开发模式
  • 通用评估准则

• “只要给予足够的关注，所有的缺陷都将无处遁形”不行的原因：大多数人并不喜欢审核代码中的bug和漏洞，因为过程缺乏创新性且缓慢枯燥令人厌烦。有一个简单的原则：代码审核的质量，完全取决于待审核的代码的多少；必须有足够多的具备相关知识的人员才能够对代码进行充分的审核；“关注越多”越容易失去要点。

• 专利软件开发模式不行的原因：现在有许多开发模式，没有任何证据表明，这些模式中的任何一种能比其中的另外一种缔造出更安全的软件。多数软件开发模式在文档中很少提及“安全”和“质量”。

• 敏捷开发模式不行的原因：安全最佳实践不够深入。

• 通用评估准则不行的原因：CC所提供的知识表明安全相关的特性已经按照预期执行的证据，他的目标并不是确保监控程序不出现任何实现上的安全bug。

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

第0阶段：教育和意识

• 微软的bug bush本身是为了找出安全bug，但他的娱乐性远远高于其本身涉及的技术。奠定了微软整个安全教育的根基。还有安全意识演讲，应包含可信计算概述、SDL简介、安全设计基础、威胁建模、模糊测试介绍、安全编码最佳实践。微软所有工程人员每年必须至少参加一次安全培训，也可将在线培训拍下来放到公司内网中。成功的安全教育与意识培训需要三点:
  • 管理层明确支持
  • 富有经验演讲者
  • 持续进行的教育

第1阶段：项目启动

• 首先判断软件安全开发生命周期是否覆盖应用。原则上来说，所有的软件都能从SDL过程中受益。接着指定一个在SDL过程中指引开发团队安全活动的安全人员，其主要职责是确保最终安全审核能够完成。这个员工叫做安全顾问。安全顾问是开发团队与安全团队之间沟通的桥梁，安全顾问需要召集开发团队举行SDL启动会议，对开发团队的设计与威胁模型进行评审，分析并对bug进行分类。接着是组建安全领导团队，确保在bug跟踪管理过程中包含有安全与隐私类bug。最后建立“bug标准”。

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

• 常见安全设计原则：
  • 经济机制：保证代码与设计尽可能简单、紧凑。
  • 默认失效保护：对任何请求默认应加以拒绝。
  • 完全中介：每一个访问受保护对象的行为都应当被检查
  • 公开设计：与“不公开即安全”的原则相对而言，认为设计本身不应具有神秘感。
  • 权限分离：切勿允许基于单一条件的操作过程
  • 最小特权：只授予执行操作所必需的最小特权
  • 最少公共机制：使诸如文件以及变量等类似的共享资源尽可能少。
  • 心理可接受程度
• 进行受攻击面分析与降低，不仅要理解应用的受攻击面组成，而且还要理解如何才能有效地降低受攻击面，从而阻止利用潜在的缺陷代码进行攻击的攻击者。ASR主要有一下几步：确定该特性是否真的很重要、谁需要从哪里访问这些功能、降低特权。

第3阶段：产品风险评估

• 安全风险评估被用于判断系统中易受攻击的漏洞级别。需要考虑以下几个问题：安装问题、受攻击面问题、移动代码问题、安全特性相关问题、常规问题、分析问卷。
• 隐私影响分级是产品风险评估的第二部分，这个分级包括三个策略值：隐私分级1，隐私分级2和隐私分级3。如果应用满足以下任何一项，就具有最高可能性隐私分级，因而要求具有最高隐私保护职责。
  
• 应用传输匿名数据给软件开发人员或者第三方，则被划分为隐私分级2.如果应用不包含1和2中任何一种行为，则被划分为隐私分级3.
• 统一各种因素：一旦确定应用程序的安全与隐私风险，就必须在日程表排出响应时间，以确保应用相应的技能以及努力来减少客户所面临的全面风险。

第4阶段：风险分析

• 威胁建模产物是描述应用背景信息并定义高层应用模型的文件，通常包括：应用场景、外部依赖性、安全假设、外部安全备注。威胁建模过程如下：
  • 定义应用场景
  • 收集外部依赖列表
  • 定义安全假设
  • 创建外部安全备注
  • 绘制数据流图
  • 确定威胁类型
  • 识别系统威胁
  • 判断风险
  • 规划消减措施
• 威胁模型可以用来辅助代码评审和测试。

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

• 创建指导性安全最佳实践文档，主要包括以下几类：安装文档、主线产品使用文档、帮助文档、开发人员文档

第6阶段：安全编码策略

• 使用编译器内置防御特性，这些保护性的代码是由编译器自动添加，无需开发人员进行干预，主要的防护选项：
  • 缓冲区安全检查：/GS
  • 安全异常处理：/SAFESEH
  • 数据执行防护兼容性：/NXCOMPAT
• 使用源代码分析工具本身并不能使软件变得更安全，很容易落到陷阱中。但源代码分析工具也有益处。切勿使用违禁函数，减少潜在可被利用的编码结构或设计，使用安全编码检查清单。

第7阶段：安全测试策略

• 模糊测试最初用于发现可靠性bug，后来证明其也可以发现某类安全bug。模糊操作旨在通过反复解释代码分析数据结构，也可称之为解析器，有三种：文件格式解析器、网络协议解析器、API和其他零散解析器。渗透测试是一个用于在信息系统在中发现脆弱性的测试过程。还有一种测试方式就是运行时验证。

第8阶段：安全推进活动

• 一次成功的推进活动需要周密的计划以及从一开始就被列入日程计划中的时间投入。软件开发团队最低程度也需要接受专门的培训，以使其对安全推进活动的期望值以及推进流程等有所了解。计算机上运行的所有代码或成为你软件的一部分的代码都必须被评审，而且该评审与代码年限没有关系。架构师和程序经理们需要对威胁模型进行不止一次的评审。在安全推进活动期间的程序化管理方式推动重估受攻击面的任务完成，会获得两个主要的收益：好的安全习惯和有助于推动代码评审任务的优先程度评级。最终，编写终端用户文档的作者和编辑们都应当对他们所有的草稿文档进行评审，以验证安全最佳实践是正确无误的，且文档中没有述及潜在有危害的实践。

第9阶段：最终安全评审

• 完整的最终安全评审过程有四个步骤，一是产品团队协调，这一部分不是纯技术性的活动，团队必须填写一个调查问卷。二是再次评审威胁模型，三是未修复的安全bug评审，验证那些标记为“暂不修复”的安全bug是否可真正对其不予理睬。四是工具有效性验证。

第10阶段：安全响应规划

• 为什么准备响应？因为开发团队一定会出错，新漏洞一定会出现，规则一定会发生变化。准备安全响应包含两个过程，第一是建立一个安全响应过程，第二就是每一个产品开发团队的责任，组建一个安全响应中心
  
• 产品团队有效的执行响应过程是十分必要的，有两个指导原则，一是准备安全响应的时间应位于漏洞被上报之前；二是每一个软件团队都必须做好安全响应准备。主要步骤：组建相应团队、支持全线产品、支持所有客户、使产品具备更新能力、在研究人员之前找到漏洞。

第11阶段：产品发布

• 如需软件被签字通过，安全与隐私团队就必须认可以下事实：SDL过程被正确无误地贯彻落实了。

第12阶段：安全响应执行

• 遵从你的计划，如果有新上报的漏洞，保持冷静，记住欲速则不达，留意可能改变计划的事件，遵从你的计划；尽你所能补救，深谙取舍之道