软件安全 从源头开始

第一章 引论

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

软件在现实世界中扮演着关键的角色，几乎无所不在，尤其是在最关键的系统中。正因为如此，设计安全的软件就显得至关重要。尽管大多数信息技术领域的安全解决方案已经有效降低了不安全软件带来的风险，但我们必须认识到构建安全软件所带来的经济成本和其他风险的重要性和相关性。因此，软件安全不仅仅是技术问题，更是商业决策的一部分，因为它关乎着安全风险的最小化。

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

在软件开发过程中，我们需要区分两个重要概念：软件安全（software security）和应用程序安全（application security）。尽管这两个术语经常被互换使用，但它们在管理和实施过程中有明显的不同。软件安全指的是在软件开发生命周期（SDLC）中通过应用SDL构建安全的软件，而应用程序安全关注于发布后运行时软件和系统的保护。

高质量和安全代码

虽然安全代码未必就是高质量代码，反之亦然，但软件开发过程应当遵循高质量和安全代码的原则。没有安全的高质量代码，也没有低质量的安全代码，它们是相辅相成的。至少，质量和软件安全应该在开发过程中密切结合；最理想情况下，它们应该是同一组织的一部分，成为软件开发工程部门的一部分。这种整合将在后续章节中从组织和操作的角度进一步讨论。

三个最重要的SDL安全目标

所有软件安全分析和构建的核心是三个最重要的安全特性：保密性、完整性和可用性，也被称为C.I.A.模型。为了确保软件开发的安全性，这三个特性必须贯穿整个SDL过程的始终。

威胁建模和攻击界面验证

威胁建模和攻击界面验证被认为是SDL中最耗时和难以理解的部分。在当前敏捷软件开发的环境中，正确处理这一问题至关重要，否则无法确保软件的安全性。通过威胁建模和攻击界面验证，可以最大程度地减少软件产品发布后发现的安全漏洞。鉴于这一功能的重要性，本书将专门用一节和一章来关注这一主题。

第二章 安全开发生命周期

2.1 克服软件安全中的挑战

在软件开发生命周期（SDL）中，克服安全挑战是至关重要的。SDL涵盖了开发行业、政府标准以及最佳实践，这些都是确保软件安全所需的基本组件。为了有效地防止、识别和减轻系统中的漏洞，需要经验丰富的人员、安全软件的策略以及严格的管控要求。

不符合SDL中的最低活动要求将给内部和外部威胁提供利用系统资产的机会。安全不再仅仅是网络要求，而是信息技术（IT）的要求，涵盖了所有软件开发的意图，包括信息的分发、存储和处理。为了保护客户的隐私和重要信息，组织必须实施最高标准的开发，以确保发布最高质量的产品。

实施SDL程序可以确保企业软件在设计和开发阶段就具备了良好的安全性，而不是在产品发布后才开始考虑安全性问题。采用SDL方法可以带来实实在在的好处，比如确保所有软件版本都符合最低安全标准，以及确保所有利益相关者都支持和强制执行安全准则。在开发周期的早期发现漏洞并进行修复不仅更容易，而且成本更低，这也为信息安全团队提供了一个系统化的方法，可以在开发过程中共同消除软件风险。

2.2 软件安全成熟度模型

软件安全成熟度模型（SSMM）涵盖了一系列关键领域，包括：

    1. 策略和度量标准
    2. 符合性和政策
    3. 培训
    4. 攻击模型
    5. 安全特征和设计
    6. 标准和要求
    7. 架构分析
    8. 代码审查
    9. 安全测试
    10. 渗透测试
    11. 软件环境
    12. 配置和漏洞管理

BSSIM的第4个版本发布于2012年9月18日，新增了两个活动：模拟软件危机和自动化恶意代码检测。BSIMM4涵盖了来自12个垂直行业的51家公司，相较于BSIMM3增长了20%，是一个在软件安全领域持续成长的标志。该模型的数据集包含了95个不同的测量，表明领先的公司在每100个开发人员中平均雇佣了两名全职的软件安全专家。

OWASP的软件保证成熟度模型（SAMM）是一个灵活的框架，用于将安全性融入软件开发组织。SAMM通过覆盖更多于典型SDLC基础模型的安全性，使得组织能够自行评估其安全保障程序，并在特定风险面临挑战时进行改进。此外，SAMM还能够创建记分卡，记录组织在管理、开发和部署业务功能过程中在安全开发方面的有效性，从而量化改进。

2.3 ISO/IEC 27034：应用安全的国际标准

ISO/IEC 27034标准是信息技术、安全技术和应用安全领域的国际标准。它提供了一套管理应用程序安全的指南，涵盖了基于风险的方法，通过流程整合和改进来管理应用程序的安全性。ISO/IEC 27034标准的出现标志着软件安全标准和框架开始整合，类似于ISO/IEC 27001标准对信息安全的影响。

ISO/IEC 27034标准的实施有助于组织内嵌过程安全方面的指导，帮助环境中运行安全的应用程序。它不仅仅是一种框架，更是一种基于风险的方法，通过设计流程来持续提高应用程序的安全性。

2.4 软件安全相关资源

在软件安全开发过程中，以下资源可为您提供有效的安全开发生命周期（SDL）最佳实践：

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

2.5 关键工具和人才

1. 工具

1.1 模糊测试

模糊测试（Fuzz testing/Fuzzing）是一种自动或半自动化的黑盒软件测试技术，通过提供无效、意外或随机数据对计算机软件程序输入进行测试。

1.2 静态分析

静态程序分析是指在不实际运行程序的情况下，对计算机软件进行分析的方法。

1.3 动态分析

动态程序分析是指在真实或虚拟处理器中运行程序的情况下，对计算机软件进行分析的方法。

2. 人才

2.1 软件安全架构师

2.2 软件安全从业者

2.6 最小特权原则

最小特权原则是软件安全中的关键概念，它包括限制特权提升和确保最小权限以防止攻击者获得不应具有的访问权限。在SDL架构中，限制特权提升是一个核心组成部分，它需要在软件设计阶段加以考虑。

确保最小特权的措施包括：

    • 限制用户权限和资源权限
    • 推动最小权限原则
    • 将软件隔离到需要多次检查访问的单独组件中
    • 访问权限的慎重授权

2.7 隐私保护

隐私保护是软件开发生命周期中的重要组成部分，应视为系统设计的基本原则。随着个人信息泄露的风险增加，用户隐私安全的保护显得尤为重要。一些关键的隐私设计原则包括：

    • 提供关于数据收集、存储或共享的适当通知
    • 使用户能够控制和管理自己的个人信息
    • 最小化数据收集和敏感性
    • 提供存储和传输数据的安全保护

在软件开发生命周期中，将隐私保护方法和技术融入适当阶段，有助于维护个人隐私并保护个人身份信息（PII）的安全。

2.8 安全度量标准的重要性

在软件开发生命周期（SDL）中，实现有效的缺陷多级过滤过程是关键目标之一，以最小化导致安全漏洞的剩余缺陷。每个缺陷去除活动都可以视为一个从软件产品中消除一定百分比缺陷的过滤器，从而降低安全漏洞的风险。早期的度量和评估能够帮助组织及早采取纠正措施，确保安全问题在软件发布前得到解决。每个缺陷去除的点都成为一个检测的点，缺陷度量的重要性超越了仅仅移除和预防缺陷的层面：它为团队提供了他们当前位置和目标的视角，指导他们是否应该进入下一个阶段，采取纠正措施，以及如何调整以满足目标要求。

有意义的安全度量标准允许组织评估其安全控制的有效性。为了有效衡量组织的安全状况，首先需要确保适当的框架得到落实，以获取有意义的度量数据。这包括确定适合产品的安全治理模式、企业的战略和运营需求。该模式应该促使实施切实可行的产品安全政策和程序，并统一部署最佳实践和措施，并要求在整个组织中严格执行管理支持。在最佳实践的指导下，安全性被视为管理整个组织的企业级、水平和跨职能模型。这种模型涵盖了监测、计量和报告企业产品安全状况的活动。

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

无论使用何种SDL模式，是否已经存在，是自行开发的还是结合了现有模式，都必须将其有效地映射到当前的软件开发生命周期（SDLC）中。图2-4展示了一个SDL活动和最佳实践模型，将其映射到典型的SDLC阶段。每个SDL活动和最佳实践都基于实际经验，作者提供的例子向读者说明了安全如何嵌入到每个SDLC阶段中。如果安全嵌入到每个SDLC阶段，那么该软件默认有较高的概率是安全的，后续的软件变更也不太可能会影响整体安全性。将安全映射到SDLC的另一个好处是，您将有机会与SDL的所有者和利益相关者共同合作，这有助于在SDLC的运营和业务过程中构建支持、高效和可实施的安全性。这些利益相关者可能包括开发人员、产品和项目经理、业务经理以及管理层。

2.10 软件开发方法

在软件开发过程中，有多种方法可供选择，其中一些常见的包括：

    1. 瀑布开发：瀑布开发是一种线性顺序的软件开发模型，各个阶段依次执行，每个阶段的完成都是基于前一个阶段的结果。

    2. 敏捷开发：敏捷开发是一种迭代和增量的软件开发方法，强调快速响应变化、持续交付和合作。

      • Scrum：Scrum是一种敏捷开发方法，强调团队协作、自组织和迭代开发。在Scrum中，工作被切分成短期迭代的“冲刺”，通常为2到4周。

      • 精益开发：精益开发是一种以减少浪费为核心的软件开发方法，强调持续改进、价值流和快速交付。

选择合适的软件开发方法取决于项目的需求、团队的特点以及项目的约束条件。在实践中，许多组织会结合不同的方法来满足特定项目的需求。

三、安全评估（Al）: SDL活动与最佳实践

 

3.1 提前引入软件安全团队

 

在软件开发生命周期（SDLC）的启动阶段，将软件安全团队纳入是至关重要的。这确保了安全性在整个过程中都是一个重要的组成部分，并且被内置到了项目中。早期参与可以帮助识别并减轻潜在的安全风险，从而降低后期安全控制实施和漏洞修复的成本。此外，早期介入还有助于将安全要求和约束集成到项目计划中，并提醒项目团队在决策时权衡安全风险。通过与业务人员进行讨论，可以确保安全性需求得到适当的关注，并且项目团队对安全问题有清晰的理解，从而为风险管理提供基础。

 

3.2 发现会议的主持

 

发现会议是SDLC的关键启动阶段，在这个阶段，关键的利益相关者汇聚在一起，确保安全性在整个过程中得到了内置。在发现会议中，应制定安全规划，包括整个系统生命周期的安全里程碑和可交付成果，以及可能需要采购的安全工具和技术的鉴定。此外，应该考虑到可能需要的其他资源，如第三方安全架构师或工程师的使用，以及相关的培训和认证需求。发现会议的成果通常包括对未来安全活动的决定，这些决定将指导后续的安全实践和项目进度。通过确保所有参与者和利益相关者对安全问题达成共识，可以确保安全需求得到充分考虑，并且项目团队对安全目标有清晰的认识。

 

3.3 创建SDL项目计划

 

SDL项目计划应该基于发现阶段的信息，列出安全里程碑，并将它们整合到整个SDLC的时间表中。这样可以确保在项目变化时有适当的规划，同时也能够将安全活动与开发活动相结合。项目计划应该反映出在发现阶段达成的安全共识，并将安全活动与项目进度相结合，以确保安全需求得到满足，并且项目能够按计划进行。

 

3.4 隐私影响评估计划启动

 

隐私影响评估（PIA）是确保软件安全性和隐私性的关键步骤之一。评估应包括立法要求的摘要、所需的工艺步骤、技术和技巧以及其他资源的考虑。评估的内容应包括利益相关者的教育、与其他软件的交互、个人可识别信息（PII）的收集和存储、访问控制、数据完整性、网络和Web服务等方面。评估还应该考虑到安全性和隐私性之间的冲突，并应用最小特权原则来确保数据的安全性。评估结果应该根据隐私风险进行分类，以便采取适当的安全措施。

 

安全评估（A1）的成功因素和度量标准

 

成功的安全评估关键因素包括计划的准确性、产品风险轮廓的确定、威胁轮廓的准确性以及相关法规和认证框架的覆盖范围。可交付成果应包括产品风险轮廓、SDL项目概述、适用的法律法规、威胁轮廓、认证要求等。建议的度量标准包括软件安全团队循环的时间、参与SDL的利益相关者的比例以及安全目标的满足程度等。这些度量标准可以帮助评估安全评估的有效性，并指导未来的安全实践。

 

四、架构（A2）：SDL活动与最佳实践

 

4.1 A2策略一致性分析

 

软件的安全策略的目的是确定哪些需要加以保护以及它如何受到保护，包括审查和结合SDL外可能会影响开发进程的策略。这些措施可能包括治理软件或开发或应用在组织中的任何地方的策略。在这个阶段，SDL 的策略域外存在的任何策略都将被审阅。企业安全与隐私策略可能会指示设计和开发人员必须有什么样的安全和隐私功能及它们该如何实现。其他策略可能包括那些支配使用第三方和开源软件或组织内部和外部的保障与控制源代码以及其他知识产权。假设软件安全组独立于集中信息安全组，重要的是，这两个群体就涉及开发和发布后后的安全支持及从该组织的软件响应所有的策略和指导方针进行合作。同样重要的是与公司的保密功能进行协作，无论是集中组还是外部法律顾问。

 

对于软件安全和策略的一致性分析，需要考虑以下几个关键方面：

 

    1. 多层次的安全策略：软件安全策略应该由多个层次组成，包括组织级别、应用级别和开发团队级别的策略。这样可以确保在整个软件生命周期中的各个环节都得到适当的安全保护。

    2. 审查和更新策略：软件安全策略需要定期审查和更新，以适应不断变化的威胁和技术环境。随着新的漏洞和攻击技术的出现，策略应该及时进行调整和改进，以保持对潜在威胁的有效防范。

    3. 与法规和标准的一致性：软件安全策略应该与适用的法规和标准保持一致，如ISO 27001、GDPR等。确保软件开发过程中遵循相关法规和标准，不仅可以提供法律合规性，还可以提升软件的整体安全水平。

    4. 与业务需求的关联：软件安全策略应该与组织的业务需求相结合，以确保安全措施不会影响核心业务的正常运行。在制定策略时，需要综合考虑软件安全与业务效率之间的平衡，以实现安全和业务的双赢。

 

4.2 SDL策略评估和范围界定

 

SDL还提供了一个非常宝贵的指南为软件开发人员设置其组织的安全标准，应该提供一个实现路线图而无需中断生产高质量软件应用的核心业务。除非开发组织和管理团队的高层领导支持这种模式，否则SDL可能会失败。它必须由签订、出台的政策来驱动，并最好由CEO和软件开发管理团队提供支持。一个组织本应该有一个书面的和可重复的SDL的策略与方针，以支持SDLC，其中包括其业务需求，并作为它支持的工程和开发文化的补充。该组织的文化和成熟度在SDL策略的制定中是非常重要的，这样可以确保它会同时实现可行性和实用性。管理风格、人员、流程和技术需求(包括产品的整体架构)的复杂性，将有助于确定怎样的粒状或目标来作为重点指导方针。外包开发量，如果有的话，也需要作为这个过程的一部分被评估。一个内部的开发团队需要更详细的程序，而一个外包功能将需要更多的合同对象、服务水平，以及详细的可交付物。

 

在SDL策略评估和范围界定方面，有几个关键点需要考虑：

 

    1. 高层支持和领导参与：SDL的成功需要得到组织高层领导的支持和参与。高层领导的重视将有助于确立SDL的重要性和优先级，并提供所需的资源和支持。

    2. 与业务需求的对齐：在制定SDL策略和范围时，需要充分考虑组织的业务需求和目标。SDL应该与业务流程和核心应用程序的开发过程紧密集成，以确保安全措施不会影响到业务的正常运行。

    3. 外包开发的考量：如果组织涉及到外包开发，特别是涉及核心业务的外包开发，SDL策略评估和范围界定需要更加详细和严格。合同对象、服务水平协议和可交付物的安全要求应该明确规定，并与外包方进行充分的沟通和合作。

    4. 风险评估和优先级确定：在SDL策略评估和范围界定过程中，需要进行全面的风险评估，识别潜在的安全威胁和漏洞。根据风险评估的结果，确定优先修复的漏洞和实施的安全措施，以最大程度地降低潜在风险。

 

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

 

    1. 威胁的风险建模：

      • 确定安全目标：明确定义软件的安全目标，例如保护用户数据、防止未经授权访问等。

      • 调查应用程序：对应用程序进行全面调查和分析，包括其功能、数据流、系统架构等。

      • 分解应用程序：将应用程序分解为不同的组件和模块，以便更好地理解其结构和安全需求。

      • 识别威胁：根据应用程序的分析结果，识别可能存在的安全威胁和攻击面。

      • 确定漏洞：针对每个威胁和攻击面，确定可能的漏洞和薄弱点。

    1. 设计原则：

      • 开放式设计：假设攻击者有来源和规格，设计防御措施以应对可能的攻击。

      • 故障保护默认值：系统应该具备故障保护机制，避免单点故障和不可关闭的漏洞。

      • 最小特权：除了需要的权限外，不给予额外的特权。

      • 机制的经济：设计安全机制时应保持简洁和高效。

      • 分离的特权：不要允许基于单一条件的操作，确保特权

 

五、设计和开发（A3 ）: SDL活动与最佳实践

 

5.1 策略一致性分析
在软件开发生命周期（SDL）中，确保外部开发机构遵循公司内部的安全和隐私策略至关重要。这涉及评估所有外部策略，以确保它们与公司的安全和隐私需求以及开发指南保持一致。公司的安全和隐私策略详细说明了所需的安全和隐私特性，并指导设计人员和开发人员如何实现这些特性。此外，其他策略可能涉及对公司内部或外部使用的第三方或开源软件的管理，以及对源代码和其他知识产权的控制。如果软件安全组与集中的信息安全组分开，那么两个组之间的协作基于所有原则和策略是至关重要的，包括开发、版本发布后的安全支持以及产品反馈。隐私功能上的合作也同样重要，无论是集中式组还是外部法律决策。

 

5.2 安全测试计划构成
安全测试活动旨在验证产品发布后的安全措施是否能有效降低客户或恶意用户发现安全问题的可能性。通过安全测试、工件、报告和工具对软件的安全性进行验证。目标不是证明产品不安全，而是在产品提供给客户前保证软件的健壮性和安全性。这些安全测试方法确实能发现安全漏洞，尤其是在那些没有经历关键的安全开发流程变更的产品中。安全测试和评估的结果也可能在安全控制中发现缺陷，安全控制用于保护正在开发的软件。因此，需要制定详细的行动计划和里程碑进度，以记录计划的整改措施，进而增强安全控制的有效性，并在软件发布之前提供必要的安全措施。

 

5.3 威胁模型更新
在构建威胁模型之后，重要的是确定何时完成构建过程。这需要回答几个问题，答案可能取决于商业竞争与安全风险之间的权衡。

 

1. 开发的软件是否符合所有相关政策、法规、条例的规定？并且对于每个需求获得各个层次的批准？
2. 所有的利益相关方是否对威胁建模过程中识别出的安全和风险进行了检查？相关的架构师、开发人员、测试人员、项目经理以及其他所有了解软件的人员都应为威胁模型构建做出贡献并进行核查。为了保证威胁模型覆盖全面，应广泛征求各方意见。所有相关人员在威胁和风险的认识上达成一致是很重要的。否则，针对威胁模型实现相关措施的落实会面临很多困难。
3. 你是否就建立威胁模型和针对威胁模型采取的应对措施、测试所需的时间和资源与相关方达成一致？
4. 你对风险和威胁的排名是否与相关人员达成了共识？如果你是一个软件购买者，是否会同意这个排名？

 

5.4 设计安全性分析和检查
1. 最小权限
2. 职责分离
3. 纵深防御
4. 故障安全
5. 经济机制
6. 完全仲裁
7. 开放式设计
8. 最小公共机制
9. 心理可接受性
10. 最弱环节
11. 利用现有的组件

 

5.5 隐私实现评估
- 高级隐私风险：特征、产品或服务对个人身份鉴别信息（PII）进行存储或传输，更改相关的配置或文件类型，或安装软件。
- 中级隐私风险：影响特征、产品或服务的隐私的独立行为是一次性的、用户发起的、匿名数据传输的（如，用户点击一个链接软件就跳转到一个外部网站）。
- 低级隐私风险：特征、产品或服务内部没有影响隐私的行为。不传输匿名或个人数据，不存储PII，没有配置改变用户的利益，不安装软件。

 

5.6 成功的关键因素和度量标准
- 成功的关键因素：
- 全面的安全测试计划
- 有效的威胁模型
- 设计安全性分析
- 隐私实现评估
- 策略一致性审查
- 可交付成果：
- 更新的威胁模型工作
- 设计安全审查
- 安全测试计划
- 更新的策略遵从分析
- 隐私实施评估结果

 

六、设计和开发（A4)：SDL活动与最佳实践

6.1 策略一致性分析

在这一阶段，需要确保所有相关的安全策略和隐私需求都被纳入考虑，并且与组织的安全和隐私指导方针保持一致。这包括检查和更新策略，以确保它们反映了最新的安全需求和行业标准。

6.2 全测试用例执行

    • 基准测试：通过比较系统的评估状态和实际状态，确保系统性能符合预期标准。
    • 预定测试：对软件进行强制性的安全性验证，以检测和调试安全问题或漏洞。
    • 探索测试：鼓励测试人员自由地探索和学习，以提高测试质量和效率。

6.3 SDLC/SDL过程中的代码审查

    • 确定代码审查对象：选择需要审查的代码部分。
    • 执行初步扫描：对代码进行初步检查，以识别潜在的安全问题。
    • 针对安全问题进行代码审查：深入检查代码中的安全漏洞。
    • 检查架构方面的安全问题：确保软件架构设计符合安全最佳实践。

6.4 安全分析工具

    • 代码静态分析：在不运行代码的情况下检查代码，可以快速识别潜在的安全问题，但可能存在误报和漏报。
    • 代码动态分析：在运行时检查代码，可以提供更准确的结果，但可能无法覆盖所有代码路径。
    • 模糊测试：通过提供异常或随机输入来测试系统的稳定性，有助于发现未知的漏洞。
    • 人工源代码审查：由专家进行深入的代码检查，可以发现复杂的逻辑错误，但成本较高且效率较低。

6.5 成功的关键因素

    • 安全测试用例执行：确保所有安全测试用例都被执行。
    • 安全测试：进行全面的安全测试，包括渗透测试和漏洞扫描。
    • 隐私验证和修复：确保软件符合隐私保护要求，并修复发现的隐私问题。
    • 策略合规性检查（更新）：定期检查并更新策略合规性。

6.6 可交付成果

    • 安全测试执行报告：记录安全测试的结果和发现。
    • 更新策略的合规性分析：分析策略更新的影响和合规性。
    • 隐私遵守报告：报告隐私保护措施的执行情况。
    • 安全测试报告：详细的安全测试结果。
    • 修复报告：记录修复的安全问题和采取的措施。

6.7 度量标准

    • 遵守公司策略的比例：衡量策略遵守的程度。
    • 通过静态测试工具实际测试的代码行数：评估测试的覆盖范围。
    • 通过静态分析工具找到的安全缺陷数量：衡量静态分析的有效性。
    • 缺陷密度：评估代码的安全性。
    • 使用不同类型的交叉测试找到的安全问题：衡量多种测试方法的效果。
    • 对比不同测试类型找到的安全问题的严重程度：评估测试的深度和准确性。
    • 对发现的安全问题进行修复的数量：衡量修复工作的效率。
    • 遵守测试安全计划的比例：确保测试计划得到执行。

 

 

 

七、发布(A5):SDL活动与最佳实践

 

7.1 策略一致性分析

策略一致性分析是确保软件开发生命周期（SDLC）中的项目遵循标准化安全开发生命周期（SDL）授权和活动的关键步骤。这一过程包括：

    • 项目分类：明确哪些类型的项目需要纳入SDL的范畴。
    • 策略定义：为每个SDL/SDLC阶段制定必须遵守的策略和流程。
    • 发布需求：设定软件版本发布前必须满足的安全需求。

7.2 漏洞扫描

漏洞扫描是使用自动化工具对应用程序和数据库进行评估，以识别已知的安全漏洞。与渗透测试不同，漏洞扫描侧重于发现潜在问题，并由技术人员执行，生成报告。开发人员通过执行漏洞扫描，可以更好地理解和实现软件安全的基本要求。

7.3 渗透测试

渗透测试是一种更深入的安全评估，旨在揭示系统架构中的弱点。执行渗透测试的测试人员需要：

    • 深入理解：能够分析设计文档、源代码和开发工件，并具备软件安全知识。
    • 攻击者思维：能够设计测试用例以验证软件漏洞。
    • 白盒测试经验：具备使用不同工具和技术进行白盒测试的知识与经验。

7.4 开源许可审查

开源许可审查涉及：

    • 遵守协议：确保遵守开源软件许可，避免法律诉讼和负面影响。
    • 安全意识：SDL、开发团队和投资者需要意识到开源软件中的安全漏洞，并采取措施进行确认、评估和修复。

7.5 最终安全性审查

最终安全性审查可能产生三种结果：

    1. 通过：所有已知的安全问题已解决，软件满足SDL需求，具备发布条件。
    2. 通过但有异常：部分问题未解决，但被视为可接受的异常，计划在后续版本中修复。
    3. 未通过，需要扩展：存在无法妥协的安全漏洞，软件不能发布，需要管理层介入决策。

最终安全性审查的流程包括：

    1. 资源评估：确定执行审查的资源，并建立可接受的最低安全水平。
    2. 特征确认：确认审查任务的合格标准，避免包含未完成的安全工作。
    3. 修复计划：利益相关者确认任务，并安排最终安全审查的日程。

 

八、发布后支持(PRSA1~5 )

 

8.1 优化软件安全团队配置

 

精准定位与高效运作

 

  • 组织架构：确保软件安全团队在组织中的位置合理，以便能够有效协调资源和决策。
  • 人才选拔：招募具备必要技能和经验的专业人员，他们能够理解并执行安全最佳实践。
  • 流程优化：建立和维护一套高效的安全流程，确保从开发到部署的每个环节都符合安全标准。

 

8.2 外部漏洞披露与响应策略（PRSA1）

 

发布后的安全与隐私应对

 

  • PSIRT行动：建立产品安全事件响应团队（PSIRT），以便在产品发布后迅速响应外部报告的漏洞。
  • 隐私保护：确保在发现潜在隐私问题时，能够及时采取措施保护用户数据。
  • 第三方协作：优化与第三方的沟通和协作流程，确保在安全事件发生时能够快速有效地响应。

 

8.3 第三方审查策略（PRSA2）

 

源代码与安全评估

 

  • 代码审查：考虑将源代码提交给可信赖的第三方进行安全审查，尽管这可能涉及知识产权风险。
  • 渗透测试：与专业的渗透测试服务合作，进行深入的代码和架构评估，同时确保源代码的安全性。
  • 工具与培训：投资于内部安全工具和培训，提升团队的安全评估能力，并邀请外部专家验证流程。
  • 供应商要求：对第三方供应商提出同样的安全审查要求，确保所有集成到应用程序的代码都经过适当的安全评估。

 

8.4 发布后认证（PRSA3）

 

安全与隐私认证的重要性

 

  • 认证需求：认识到产品发布后可能出现的认证需求，这些需求可能源于新的市场、法规或用户群体。
  • 合规团队：建立专门的团队来处理认证和合规事宜，确保软件满足所有相关的安全和隐私标准。
  • 持续更新：随着全球安全和隐私标准的不断变化，持续更新和维护认证是必要的。

 

8.5 新产品组合或云部署的内部审查（PRSA4）

 

架构变更与安全复审

 

  • SDL再应用：认识到即使软件已经通过了安全开发生命周期（SDL），任何架构变更都可能引入新的安全风险。
  • 持续测试：确保任何新的代码或架构变更都经过全面的安全测试，包括但不限于渗透测试、代码审查和模糊测试。
  • 风险评估：对新部署的软件进行风险评估，确保其安全性能满足当前的安全标准和要求。

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

    关于遗留代码：

    遗留系统中的技术债务有可能隐藏着未被发现的安全威胁。在开发过程中，组织可能在保证软件安全性和质量方面做出妥协。这种情况经常出现，例如，为了在规定时间内完成过量的功能要求，或者在优先级较高的软件特性未考虑到质量和安全时。在这些情况下，遗留代码可能会存在安全漏洞，这是技术债务的一种表现。从软件产品安全的角度来看，对遗留代码的审查的主要目标就是权衡解决技术债务带来的投资回报和潜在风险。这需要考虑两个主要问题：

    1. 你替换了多少旧代码为新的安全生命周期(SDL)兼容的代码？旧代码以何种速度被替换？剩下的部分面临的安全风险是什么？

    2. 审查旧代码是一个耗时且困难的过程。你需要投入资源去降低现存的技术安全债务。这个工作的量将取决于在代码开发过程中是否使用了SDL。如果在遗留代码的开发中没有使用SDL，那么工作量将会很大。

    关于合并和收购：

    为了保持竞争优势，许多公司会寻求新的产品，进入新的市场，或者寻找替代方案，包括合并和收购，并且这往往是在他们无法利用现有的资源去完成这些目标时进行的。合并和收购可能出于多种原因，但通常是为了提高竞争力、盈利能力，或者公司及其产品的其他价值。在软件行业，这通常是因为你的解决方案集或产品需要某些功能。如果合并和收购的主要关注点是目标公司的软件，那么收购的人才将是一个额外的优势。当一次合并和收购开始，从初步讨论到公告开始，再到详尽的调查阶段，最后是将目标公司或者收购的技术整合到母公司中，这个过程中的工作量和范围将取决于项目的规模和复杂性。值得注意的是，合并和收购并不总是包含目标公司的所有资源。它们可能只包括代码的部分，或者对收购公司来说具有吸引力和价值的多个技术或产品。

    8.7 成功的关键因素：

    1. 外部漏洞信息的披露响应过程
    2. 发布后的认证
    3. 第三方的安全审查
    4. 任何架构变化或者代码复用的安全开发周期(SDL)
    5. 针对遗留代码、合并和收购以及产品生命周期结束(EOL)的产品的安全策略和过程

    8.8 可交付的成果：

    1. 外部漏洞信息的披露响应过程
    2. 发布后的认证
    3. 第三方的安全审查
    4. 任何架构变化或者代码复用的安全开发周期(SDL)
    5. 针对遗留代码、合并和收购以及产品生命周期结束(EOL)的产品的安全策略和过程

    8.9 度量标准：

    以下是一些应该在SDL阶段考虑的度量指标：

    1. 响应外部披露的安全漏洞的时间（以小时记）
    2. 每位全职员工每月花费在处理对外披露过程的时间（以小时记）
    3. 产品发布后发现的安全问题数量（按严重程度分类）
    4. 每月客户报告的安全问题数量
    5. 在任何SDL活动中，客户报告的未解决的安全问题数量

 

九、将SDL框架应用到现实世界中

 

9.1引言 软件安全是一个多方面、多层次的任务集合，它要求在软件开发生命周期的各个阶段都要考虑到安全问题。没有一个单一的任务能够保证软件的绝对安全，因此需要一系列互补的安全活动来共同构建安全的软件环境。这些活动包括但不限于安全设计、代码审查、静态分析、动态测试等。每个软件项目都有其特定的安全需求和风险，因此需要根据项目的具体情况来确定哪些安全任务最为关键。

9.2安全地构建软件 编写安全的代码是软件安全的基础。这要求开发人员不仅要关注程序的功能实现，还要关注程序可能产生的非预期行为。测试是发现现有bug的手段，但不能证明没有bug。因此，需要对所有输入进行严格的验证，以防止未知的输入导致的安全漏洞。结对编程可以提高代码质量和安全性，因为它允许两个开发人员共同审查代码和设计。

人工代码审查和静态分析是两种重要的代码质量保证手段。人工审查可以发现自动化工具可能遗漏的问题，而静态分析工具可以在不运行代码的情况下发现潜在的错误和安全漏洞。

9.3确定每个项目的正确行为 为了确保软件安全，需要对每个项目进行详细的安全需求分析。这包括确定项目的架构变化、第三方软件的集成、客户数据的处理、组织的操作历史、Web服务器的使用、非Web输入的处理以及版本的重要性等。

9.4架构和设计 安全架构是软件安全的骨架，它决定了软件如何处理安全相关的任务和数据流。安全架构需要有独特的设计方法和观点，以及专用的组件和规范流。这要求IT架构师具备专业的安全技能。

9.5测试 测试是验证软件安全性的关键步骤。功能测试、动态测试、网络扫描、模糊测试、攻击和渗透测试以及独立测试等都是确保软件安全的重要手段。这些测试可以帮助发现并修复潜在的安全漏洞，确保软件在实际使用中的安全性。

总之，软件安全是一个复杂的过程，需要从设计到测试的每个环节都加以重视。通过实施一系列的安全活动，可以最大限度地减少软件中的安全风险，保护用户的数据和系统的完整性。

 

十、集成:应用 SDL防止现实的威胁

 

10.1 战略、战术和特定于用户的软件攻击 在这一部分，我们讨论了不同类型的网络攻击，这些攻击针对的是业务功能、流程以及网络之间的联系。战略攻击通常是长期的、有计划的攻击，旨在对整个组织造成重大损害。战术攻击则更侧重于利用特定的漏洞或弱点，对特定的业务功能或流程进行攻击。特定于用户的攻击则是针对个别用户或用户群体的攻击，可能涉及钓鱼、恶意软件等手段。这些攻击所获取的信息可以用来指导和进行更高级别的战略攻击。

 

10.2 应用适当设计、管理和集中的SDL克服组织与业务挑战 软件安全开发生命周期（SDL）是一个框架，用于在整个软件开发过程中集成安全性。通过定义明确的组织架构和角色责任，SDL模型可以帮助组织有效地创建、实现和控制软件安全最佳实践。此外，SDL模型还可以通过提供一个仪表盘来帮助管理和跟踪软件安全方案的状态，识别资源缺口，并确保发布后的支持任务得到妥善处理。通过在SDL的每个阶段使用指标，组织可以更好地管理软件安全风险，并在发布后减少安全漏洞的发生。

 

10.3 软件安全组织的现状和影响力 软件安全组织（SSG）的角色是提供集中的管理和支持，以确保软件安全冠军能够在其业务组中有效地推动安全性。SSG负责指导安全性架构和审查，协调早期和及时的安全需求，帮助计算项目安全风险，并确保有合适的安全性测试工具可用。通过这些活动，SSG可以帮助确保软件产品在设计时就考虑到安全性，从而减少后期的安全问题。

 

10.4 通过合理的政府管理克服SDL审计和法规挑战 ISO/IEC 27034是一个软件安全标准，它提供了一个框架，用于将安全性整合到应用程序管理过程中。通过将ISO/IEC 27034的准则与SDL实践或其他成熟模型整合，组织可以更好地应对审计、监管或管理的挑战。这是因为遵循这些规范可以帮助组织确保其软件开发过程符合行业最佳实践，从而减少安全风险。

 

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

第0阶段：教育和意识提升

微软安全教育的发展历程

基础安全培训的核心内容：

  • 安全漏洞修复的常见借口：在《Writing Secure Code, Second Edition》一书中，Howard和LeBlanc（2003）列举了一系列关于忽视安全漏洞修复的借口，这些内容既幽默又深刻，旨在增强人们对安全问题的认识。

  • 威胁设计问题：设计中的缺陷，如默认端口开放、错误的注册键值存储、认证与授权机制的绕过、欺骗性登录方式等，都是需要特别关注的安全隐患。

  • 软件面临的威胁：基于五年的威胁建模研究经验，我们将在第9章“第4阶段：风险分析”中深入探讨软件可能遭遇的威胁。

  • 不安全的编程技术：对常见的编码错误，如缓冲区溢出、跨站脚本（XSS）、SQL注入、弱加密等进行分析，强调早期较少提及的整型数值错误。

持续教育的重要性：

  • 安全的软件设计、开发与测试基础
  • 模糊测试的核心要点
  • 威胁建模的核心要点
  • 实施威胁缓解措施
  • 安全设计与架构：经过验证的设计原则
  • SDL介绍与最终安全评审过程
  • 安全工具概览
  • 实战安全代码评审
  • 安全编程实践
  • 安全漏洞的核心要点
  • 受攻击面分析
  • 漏洞开发
  • 打包过程的安全需求
  • 安全响应
  • 加密实践
  • 客户隐私保护

培训交付类型：

  • 针对特定对象和目标听众开发新课程。
  • 安全专家创建课程内容，其他专家进行技术审核。
  • 培训专家进行一致性和排版错误的检查。
  • 发布beta课程以调整时间进度并收集初步反馈。
  • 根据反馈更新课程资料。
  • 定期交付课程，并在六个月后录制并发布到内网。

练习与实验：

  • 实践活动对于巩固新概念至关重要。

参与度和合规性的追踪：

  • 微软要求所有工程师在开发符合SDL的产品前完成相应的安全培训，并通过员工ID卡记录参与情况。

知识度量的复杂性：

  • 度量员工的知识水平是一个复杂的过程，涉及考试方式、防作弊措施等多方面考量。

自助培训的实现：

  • “安全基础”培训旨在提高员工的安全意识，并为工程师提供基本的安全知识，指导他们如何获取更多信息和寻求帮助。

关键成功因素与量化指标：

  • 成功的安全教育与意识培训需要管理层的明确支持、经验丰富的演讲者以及持续的教育

    • 安全文化的建立：除了技术培训，建立一种安全文化同样重要，这包括鼓励报告安全问题、奖励安全改进和持续的安全沟通。

    • 安全培训的个性化：根据不同岗位和职责，提供定制化的安全培训内容，确保培训的针对性和有效性。

    • 安全培训的评估与反馈：定期评估培训效果，收集参与者的反馈，以便不断优化培训内容和方法。

    • 安全意识的日常融入：将安全意识融入日常工作流程中，如代码审查、产品发布前的安全检查等，以确保安全成为日常工作的一部分。

    • 安全培训的多样性：利用在线课程、研讨会、工作坊等多种形式，提供多样化的学习体验，以适应不同学习风格和时间安排。

安全培训的持续更新：随着安全威胁的不断演变，安全培训内容也需要持续更新，以确保员工能够应对最新的安全挑战。

阶段一：项目启动与安全评估

项目启动阶段是整个软件开发生命周期（SDLC）中至关重要的部分，它涉及评估应用是否涵盖了安全开发的核心原则。在这个阶段，需要考虑以下关键要素：

  • 对于广泛使用的业务关键产品（例如电子邮件系统、数据库服务器等），这些系统因其重要性和潜在风险而必须遵循安全开发过程。
  • 任何定期处理或交换个人身份信息（PII）的应用，特别是根据像儿童在线隐私保护法案（COPPA）这样的法律，与儿童相关的产品或服务需要进行特别保护。
  • 经常连接到互联网或响应互联网请求的产品，包括始终在线的服务（如IM软件）、设计上需要在线的工具（如Web浏览器）以及依赖在线功能来增强体验的组件（如多人在线游戏）。
  • 具有自动更新机制的产品，由于更新可能引入新的安全问题，因此需要特别关注。

安全顾问的角色定义

作为安全顾问，您的角色是多方面的，包括但不限于：

  • 桥梁建设者：作为开发团队和安全团队之间的联络人，确保沟通流畅，无误解发生。您应牢记，与开发团队中指定的安全负责人协作，是保持通信有效的关键。
  • 教育者和启动者：通过举行SDL启动会议，向涉及的团队成员说明SDL的目的和关键流程，确保所有项目关键人员的参与，包括开发、测试和项目管理人员。
  • 审查者：在设计阶段结束时，与开发团队一起评审产品设计和威胁模型，以便尽早识别安全漏洞。确保应用程序的攻击面最小化，遵循安全设计最佳实践，威胁模型全面且真实反映系统防御能力，并保障足够的测试覆盖率。
  • 分类专家：分析并对bug进行分类，包括安全类和隐私类bug，确保每个bug都得到妥善评估和适当的处理。

传声筒：作为开发团队咨询安全问题的首选资源，并激励团队成员就安全和隐私问题提出问题和建议，同时提供必要的教育资源。

协助开发团队准备最终安全审核

在产品交付之前，必须通过最终安全审核来确保产品的安全性。安全顾问的职责是确保所有的安全开发生命周期（SDL）任务都得到完成，以便顺利进行最终安全审核。最终安全审核是产品提交给客户之前的最后一道关卡，因此对其要求非常严格。

与安全团队协同工作

当产品中发现已公开报道的安全漏洞时，安全顾问的经验和背景知识能够缩短问题分析时间，并选择最合适的修复方式。

组建安全领导团队

在开发过程中，应该有一个安全领导团队负责推动各团队之间的沟通和任务计划。该团队的任务包括定期与开发团队沟通安全和隐私方面的问题，及时更新安全和隐私策略。

确保在bug跟踪管理中包含安全和隐私类bug

在bug跟踪管理软件中增加安全和隐私类bug的跟踪域，包括安全/隐私bug的后果和原因。后果域应包含预定义的值，如非安全类bug、假冒、篡改、抵赖、信息泄露、拒绝服务、特权提升、受攻击面降低等。原因域应包含预定义的值，如非安全类bug、缓冲区溢出、算术错误、SQL/脚本注入、目录遍历、竞争状态、跨站脚本、密码弱点、弱身份认证、弱身份授权/不匹配ACL、无效秘密隐藏、资源消耗、错误/无出错信息、错误/无路径名等。

建立“bug标准”

确定在项目开发过程中哪些类型的bug，包括安全和隐私类bug，需要优先修复。建立bug标准有助于降低对修复哪些bug、消减哪些bug以及未修复bug的混淆。在产品发布之前，应该优先修复关键、重要和中等程度的安全和隐私类bug。

定义并遵守设计最佳实践

在设计过程中，应遵循一些常见的安全设计原则，如经济机制保证代码简洁、默认失效保护、完全中介、公开设计、权限分离、最小特权、最少公共机制和心理可接受程度。受攻击面分析与降低也是设计过程中需要考虑的重要因素。

产品风险评估

进行安全风险评估，包括安装问题、受攻击面问题、移动代码问题、安全特性相关问题和常规问题。通过问卷调查和隐私影响分级来评估产品的隐私风险。

创建威胁模型

使用威胁模型进行威胁建模，帮助规模化代码审核过程和执行安全编码策略。威胁模型可以帮助发现系统威胁、降低受攻击面、指导代码审核和测试，同时提供支持制定消减措施的指导。

创建安全文档、工具和最佳实践

为客户提供可操作的安全指南和工具，帮助他们在使用产品时处于受控状态。创建安装文档、主线产品使用文档、帮助文档和开发人员文档，同时提供相应的工具，如安全配置向导（SCW）等。

安全编码策略

使用最新版本的编译器和支持工具，利用编译器内置的防御特性，使用源代码分析工具来发现潜在的安全问题，避免使用违禁函数，减少潜在可被利用的编码结构或设计。