DevOps 安全实用指南（一）

最新推荐文章于 2025-09-01 21:10:42 发布

原创最新推荐文章于 2025-09-01 21:10:42 发布 · 1.4k 阅读

27 ·

CC 4.0 BY-SA版权

License CC BY-NC-SA 4.0 / 自豪地采用谷歌翻译

文章标签：

#默认分类

默认分类专栏收录该内容

10507 篇文章

订阅专栏

原文：annas-archive.org/md5/e4714e8364fa44aa64a294c6d969ee99

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

DevOps 提供了通过持续开发和部署方法带来的速度和质量优势，但它并不能保证整个组织的安全。《DevOps 中的安全实践》将向您展示如何采用 DevOps 技术，持续提高组织各层级的安全性，而不仅仅是集中保护基础设施。

本指南结合了 DevOps 和安全，帮助您保护云服务，并教您如何将安全技术直接融入产品中。您将学习如何在每个层级实施安全，例如 Web 应用、云基础设施、通信和交付管道层级。通过实践示例，您将探索核心安全方面，如阻止攻击、欺诈检测、云取证和事件响应。在最后几章，您将学习扩展 DevOps 安全的相关主题，如风险评估、威胁建模和持续安全。

本书结束时，您将能够熟练地在组织的各个层面实施安全，并有信心在整个云服务中监控和阻止攻击。

本书的读者对象

本书面向希望确保整个组织安全的系统管理员、安全顾问和 DevOps 工程师。需要具备基础的云计算、自动化框架和编程知识。

本书内容涵盖

第一章，DevSecOps 驱动因素与挑战，我们将探讨推动安全需求的外部因素，如安全合规、法规和市场需求。

第二章，安全目标与度量，我们将基于 OWASP SAMM 框架从不同角度探讨安全实践。我们还将涵盖不同角色的安全活动，例如安全管理、开发、质量保证和运营团队。

第三章，安全保障计划与组织，将讲解不同的组织结构如何与安全保障计划的执行相关联。组织结构中安全团队的角色、责任和关系也会影响安全保障计划的成功执行。我们将通过案例研究来讨论这些因素。

第四章，安全需求与合规性，将涵盖四个方面的安全需求：每个发布质量关卡的安全要求、一般 Web 应用的安全要求、大数据的安全要求以及符合通用数据保护条例（GDPR）的安全要求。

第五章，案例研究 - 安全保障计划，我们将介绍两个案例研究，探讨 DevOps 过程中的安全保障计划和安全实践。微软 SDL 和 SAMM 被引入应用于安全保障计划。除了流程，非技术部分（如安全培训和文化）对于安全计划的成功至关重要。我们还将举例说明安全工具和 Web 安全框架如何在整个 DevOps 过程中提供帮助。

第六章，安全架构与设计原则，将介绍安全架构与设计原则。对于安全架构师和开发人员来说，基于成熟的安全框架构建软件不仅可以大大降低安全风险（通过行业最佳实践），还可以减少实施工作。因此，本章介绍了云服务架构的关键安全元素以及一些成熟的安全框架，这些框架可以根据不同场景应用。

第七章，威胁建模实践与安全设计，我们将讨论整个团队参与威胁建模实践的重要性，并介绍 STRIDE 模型（欺骗、篡改、否认、信息泄露、服务拒绝和特权提升）。

第八章，安全编码最佳实践，我们将介绍行业安全编码最佳实践，如 CERT、CWE、Android 安全编码、OWASP 代码审查和苹果安全编码指南。基于这些安全编码规则，我们将建立安全编码基线，作为安全政策和发布标准的一部分。

第九章，案例研究 - 设计中的安全性和隐私性，我们将通过一个案例研究来讨论如何实现设计中的安全性和隐私性。该案例研究将展示 DevOps 团队在应用安全实践时可能面临的常见挑战，以及安全团队如何提供最佳实践、工具、安全框架和培训套件。

第十章，安全测试计划与实践，将概述安全测试计划、安全测试领域和最小安全测试范围。我们将讨论安全测试计划、测试方法、风险分析、安全领域和行业实践，以构建您的安全测试知识库。此外，我们还将介绍一些行业最佳实践、测试方法和安全工具，用于安全测试。

第十一章，白盒测试技巧，将重点介绍白盒测试的技巧。白盒代码审查可以最有效地识别某些特定的安全问题，如 XXE、反序列化和 SQL 注入。然而，如果没有合适的工具或策略，白盒审查可能会非常耗时。为了进行有效的白盒测试，我们需要关注特定的编码模式和高风险模块。本章将提供技巧、工具以及识别高风险安全问题的关键编码模式。

第十二章，安全测试工具包，我们将介绍常见的（但不是全面的）安全测试工具集。涉及安全测试的网络主要元素包括 Web 和移动连接、配置、通信、第三方组件以及敏感信息。我们将探讨每个元素的测试技巧和工具。此外，我们还将学习如何将这些工具既能自动执行，又能作为内置于持续集成中的工具来使用。

第十三章，CI 管道中的安全自动化，将重点讨论开发阶段的安全实践，以及如何将诸如 Jenkins 之类的工具集成到持续集成中。在开发阶段，我们探讨了使用 IDE 插件进行代码扫描的技术，并建议了一些静态代码分析工具。对于构建和包交付，还将介绍安全的编译器配置和依赖项漏洞检查。最后，本章还将讨论 Web 安全自动化测试方法和技巧。

第十四章，事件响应，将介绍安全运营团队的事件响应。我们将主要讨论事件响应过程中的关键阶段：准备、遏制、检测和事件后分析的关键活动。事件响应领域包括如何处理公共 CVE 漏洞，如何应对白帽子或安全攻击，如何评估每个安全问题，反馈环路到开发团队，以及我们在事件响应中可能应用的工具或实践。

第十五章，安全监控，将介绍一些安全监控技术。本章的目标是为我们的安全监控机制做好准备，以保护并防止我们的云服务受到攻击。为了做好准备，我们的安全监控程序应包括日志记录、框架监控、威胁情报和恶意程序的安全扫描。

第十六章，新版本的安全评估，本章将介绍新版本的安全评估。云服务可能会有频繁的发布和更新。对于开发、运维和安全团队来说，在短时间内发布工作并在发布前完成最低限度的安全测试是一个挑战。在本章中，我们将查看安全评审政策、每个发布的建议清单和测试工具。对于集成测试，本章还将介绍 BDD 安全框架和其他集成安全测试框架。

第十七章，威胁检测与情报，将介绍威胁检测与情报。本章重点讨论如何使用各种日志关联识别和防止已知和未知的安全威胁，例如后门和注入攻击。我们将介绍所需的日志、如何将这些日志关联起来以及攻击的潜在症状。还将介绍一些开源的威胁检测工具。最后，我们将介绍如何构建自己的内部威胁情报系统。

第十八章，商业欺诈与服务滥用，将介绍商业欺诈和服务滥用。云服务引入了新类型的安全风险，例如交易欺诈、账户滥用和优惠码滥用。这些在线欺诈和滥用可能导致财务损失或收益，具体取决于你站在哪一方。这一章还将提供如何检测这些行为的指南和规则。我们将讨论构建服务滥用防护或在线欺诈检测系统所需的典型技术框架和技术方法。

第十九章，GDPR 合规案例研究，将以 GDPR 合规为案例研究，应用到软件开发中。它讨论了应该在即将发布的版本中包含的 GDPR 软件安全要求。我们还将探索一些实际案例研究，如个人数据发现、数据匿名化、cookie 同意、数据掩码实施和网站隐私状态。

第二十章，DevSecOps - 挑战、技巧与常见问题解答，将从功能角色的角度，介绍一些实践技巧、挑战和常见问题解答。

为了最大限度地利用本书

参考 OWASP 安全项目、NIST、CSA、GDPR 以获取最新的安全最佳实践。尝试安装并应用书中提到的开源工具。

每次将一个安全工具或实践应用到 DevOps 过程当中。

下载彩色图片

我们还提供了一份 PDF 文件，其中包含了本书中使用的截图/图表的彩色图像。你可以在这里下载：www.packtpub.com/sites/default/files/downloads/HandsOnSecurityinDevOps_ColorImages。

使用的约定

本书中使用了多种文本约定。

CodeInText：表示文本中的代码字、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入以及 Twitter 账号。例如：“能够在安全关系中建立应用程序资源（TimeSheet.xls）是 OACC 中的一种独特授权模型。”

粗体：表示新术语、重要词汇或屏幕上显示的词语。

警告或重要说明如下所示。

提示和技巧如下所示。

联系我们

我们始终欢迎读者的反馈。

一般反馈：通过电子邮件feedback@packtpub.com与我们联系，并在邮件主题中注明书名。如果你对本书的任何方面有问题，请通过questions@packtpub.com与我们联系。

勘误：尽管我们已尽一切努力确保内容的准确性，但错误仍然会发生。如果你在本书中发现错误，我们将非常感激你向我们报告。请访问www.packtpub.com/submit-errata，选择你的书籍，点击“勘误提交表单”链接，并输入详细信息。

盗版：如果你在互联网上发现我们作品的任何非法复制品，我们将非常感激你提供相关地址或网站名称。请通过copyright@packtpub.com与我们联系，并附上相关链接。

如果你有兴趣成为作者：如果你在某个领域具有专业知识，并且有兴趣撰写或为书籍做贡献，请访问authors.packtpub.com。

读者反馈

请留下评论。在阅读并使用本书后，为什么不在购买该书的网站上留下评论呢？潜在读者可以看到并根据你的公正意见做出购买决定，Packt 也能了解你对我们产品的看法，而我们的作者可以看到你对其书籍的反馈。谢谢！

欲了解更多有关 Packt 的信息，请访问packtpub.com。

第一章：DevSecOps 驱动因素与挑战

由于云服务的快速发布、执法、安全事件和租户数据保护，安全对于云/互联网服务来说不可或缺。在开发生命周期中将安全活动从右向左转移，并在持续集成管道中内置安全实践，是 DevSecOps 的目标。

商业环境、文化、法律合规性和外部市场驱动因素与 DevSecOps 安全保证程序在组织中的推广方式相关。DevSecOps 或安全保证程序的管理涉及整个组织的所有业务单元，DevSecOps 的成功关键在于所有利益相关者达成共识，并同意目标和方法。

本章将涵盖以下主题：

安全合规性（ISO 2700x，FIPS，CSA-CCM）
法律/法律合规——通用数据保护条例（GDPR）
新技术（第三方、云、容器和虚拟化）
云服务攻击/滥用
快速发布

如下图所示，这就是外部驱动因素和挑战如何影响团队在提供安全云服务时的表现：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

安全合规性

对于云服务来说，具备安全合规性是非常重要的。安全合规性不仅展示了云服务的安全控制如何符合安全标准，还表明了客户和合作伙伴对安全的信任。安全合规性提供了安全保证程序的概览，但不会具体说明应该应用哪种安全技术方法。对于频繁发布的云服务，持续监控和审计以满足安全合规性可能是一个巨大挑战。

尽管大多数云服务提供商已准备好符合安全合规性（ISO，PCI，FedRAMP，SOC 等），但确保数据安全和管理自身应用合规性评估仍然是云服务客户的责任。云服务客户和提供商都需要维护系统或应用的审计日志、配置清单和变更历史记录以进行合规性评估。合规性评估应被视为持续的活动——而不是一次性的审计检查。

本章将介绍关键的云服务安全合规性，作为构建安全保证程序的参考，并探讨这些安全合规性标准与 DevSecOps 的关系。

ISO 27001

ISO 27001 是一个信息安全管理体系（ISMS）。它提供了组织级安全保障程序的概述。ISO 27001 不会规定技术安全方法，但提供了一整套安全管理程序。如图所示，上部分的段落可能与 DevOps 安全实践更直接相关，如合规性、业务连续性、操作安全、访问控制、软件开发、加密、事件管理和通信。这将作为进一步发展我们自己的 DevOps 安全程序的指导方针：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

我们不会介绍 ISO 27001 的详细内容，但以下表格总结了 ISO 27001 与每个角色及 DevOps 团队的关系：

角色	公司/组织安全策略	运营或 DevOps 团队	开发团队
ISO 27001 章节	5 信息安全政策 6 信息安全组织 7 人力资源安全 8 评估管理 15 供应商关系 11 物理和环境安全	9 访问控制 10 加密 12 操作安全 13 通信安全 17 业务连续管理的信息安全方面 16 信息安全事件管理 18 合规性；内部要求，如政策，以及外部要求，如法律 19 云服务控制	14 系统开发 10 加密 9 访问控制

ISO 27017 和 ISO 27018

ISO 27018 主要用于云中的个人可识别信息（PII）保护。它是基于 ISO 27001 和 ISO 27002 的扩展安全合规。在 ISO 27001/27002 的基础上，ISO 27018 还额外定义了 PII 保护的安全要求。

ISO 27017 为服务提供商和云服务消费者提供了实施云服务安全控制的能力。ISO 27017 是 ISO 27002 的扩展，用于解决云特定的安全问题。

云安全联盟（CSA）

由于存在许多云安全合规方法，我们可能会因试图遵循每一个而感到沮丧。云安全联盟（CSA） 云控制矩阵（CCM）将大多数安全合规方法整合到一个名为 CCM 的矩阵中。以应用和接口应用安全为例——CCM 包括所有与该领域相关的安全合规控制，如 ISO、FedRAMP 和 NIST 800-53，并定义了控制 ID。参考 CCM 的主要好处是，我们可以简单地专注于 CCM，并知道所有其他安全合规法规也将得到满足。

此外，CSA 提供了 共识评估倡议问卷（CAIQ）。这是一份用于云消费者或云服务提供商的“是/否”问卷，用于进行安全自我评估并了解安全控制的要求。谷歌供应商安全评估问卷（VSAQ）也提供了关于 Web 应用安全、安全与隐私程序、基础设施安全和物理及数据中心安全的安全评估问卷。

此外，如果您正在寻找主要的云安全威胁及其控制措施，云安全联盟（CSA）提供的云顶级威胁指南是一个很好的参考。在撰写本文时，CSA 已定义了 12 个主要云威胁，并提供了与威胁分析、CCM/控制 ID 和 CSA 安全指南参考领域的映射。以下表格展示了相关的 CSA 安全指南以及如何在您的组织中应用安全实践：

CSA 安全指南	它是什么？	何时应用？
CSA 安全指南参考	云安全白皮书	如果您的组织需要云服务安全指南或白皮书，这可以作为一个好的参考。
云顶级威胁	12 个主要云威胁及其与威胁分析、CCM/控制 ID 和 CSA 安全指南参考领域的映射	它可以作为云威胁建模的基础。
CAIQ	是/否问卷	一个自我评估的“是/否”问题列表，用于了解现有的安全控制要求。
CSA CCM	一项全球统一的安全标准映射	这是一个极好的统一参考，包含了大多数安全合规标准（如 ISO 27001、PCI、NIST 等）。它是您审查安全标准合规性时唯一需要参考的矩阵。

联邦信息处理标准（FIPS）

FIPS 主要定义了使用加密模块的最低安全要求。任何不打算获得 FIPS 证书的组织都应参考它。强烈建议您参考 加密模块安全要求 以了解哪些加密模块可能被认为是安全的、过时的或薄弱的。

对于希望学习如何正确实现加密模块的开发人员，以下资源是推荐的：

OWASP 加密存储备忘单。
OWASP 加密指南
OWASP 密钥管理备忘单

以下是每种加密算法及其使用的最低安全要求总结：

使用场景	不安全的加密算法（密钥长度）	仅限旧系统使用	推荐的加密算法
对称加密	Blowfish, DES, Skipjack, RC4	仅在（三个密钥不相等时）使用 3DES	AES > 128 位
非对称加密	RSA（< 1024 位）	RSA（1024 位）	RSA（> 1024 位）
哈希	MD5	SHA1（1024 位）	SHA256
数字签名	RSA（< 1024 位）DSA（< 1024 位）ECDSA（<= 160 位）	DSA（1024 位）RSA（1024 位）	RSA（>=2048 位）DSA（>=2048 位）ECDSA（>=256 位）
赫尔曼密钥交换（DH）	DH（< 1024 位）	DH（1024-2047 位）	DH（>=2048 位）ECDH（> 256 位）

互联网安全中心（CIS）与 OpenSCAP——保障您的基础设施安全

CIS 定义了安全基准，国家检查单计划（NCP），由 NIST SP 800-70 定义，提供了操作系统、数据库、虚拟化、框架和应用程序的安全配置指导。

IT 和运维团队主要负责确保基础设施的安全。然而，开发团队也可能在保障基础设施安全方面分担一些责任。例如，开发团队可能决定以容器的形式交付应用包，或应用基础设施即代码框架，如Puppet或Chef。这些技术允许开发团队在开发阶段就定义安全配置，而运维团队只需要在应用部署时应用该安全配置定义。

此外，开发团队的工作也是为每次发布的部署提供一份配置更改清单。这将使运维团队能够审查配置更改是否安全且适当。由于需要审查的配置复杂且数量庞大，因此采用扫描工具来检查所有配置是否安全，并符合行业最佳实践是必要的。云服务提供商可能会提供此类扫描服务或工具。在这里，我们推荐像 CIS 提供的开源工具 CIS-CAT Lite 和 OpenSCAP 等。

保障基础设施和平台安全的过程可以分为三个阶段。第一阶段是通过参考行业实践（如 CIS 或 NIST NCP）来定义安全配置基准。然后，我们可以使用 Chef 或 Puppet 等工具，确保每次部署都包含安全配置。最后阶段是对频繁的配置更改和安全合规性进行持续监控。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

以下表格列出了典型的基础设施组件。CIS 为每个系统组件提供了安全配置建议，并提供了扫描工具，以验证安全最佳实践基准的符合情况。

CIS 提供了 CIS 基准，定义了操作系统、服务器软件、云服务、网络设备等的安全配置。它帮助运维团队理解如何保障和配置基础设施和平台的安全。

基础设施层	系统
网络服务	Apache, Nginx, IIS
数据库	MS SQL, MySQL, Oracle, MongoDB
虚拟化/容器	VMware, Docker, Kubernetes
网络	Cisco 设备
操作系统	Windows、Linux、Ubuntu、CentOS、SUSE

除了 CIS 基准文件，CIS 还为基础设施或操作团队提供安全配置扫描工具。CIS 安全网站提供相关的安全配置扫描工具供下载。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

来源：https://www.cisecurity.org/cybersecurity-tools/

国家检查清单计划（NCP）库

NCP 库为特定软件组件提供安全配置。例如，如果你在寻找 Apache 的安全配置或 CIS Apache，你可以使用 NCP 进行搜索。截图来自 NIST NCP（国家检查清单计划）。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

来源：https://nvd.nist.gov/ncp/repository

OpenSCAP 工具

OpenSCAP 类似于 CIS 安全基准，它也提供了一个安全配置基准。此外，OpenSCAP 还为操作或基础设施团队提供不同种类的工具，用于进行安全配置评估和扫描。根据需求，提供了四种工具，具体见下图：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

来源：https://www.open-scap.org/tools/

法律和安全合规

欧盟的 GDPR（通用数据保护条例）于 2018 年 5 月生效，旨在保护所有欧盟公民免受隐私和数据泄露的威胁。根据 GDPR 常见问题解答：

“GDPR 不仅适用于位于欧盟境内的组织，还适用于所有处理和存储欧盟境内数据主体个人数据的公司，无论公司所在地。”

换句话说，如果一家公司在欧盟向客户提供服务，其数据处理必须完全符合 GDPR。从 DevSecOps 的角度来看，这与数据的收集、处理、存储、备份、修改、传输和删除等都相关，且必须以安全的方式进行。根据 GDPR 第 5 条，存在六项隐私原则：

合法性、公平性与透明度
目的限制
数据最小化
准确性
存储限制
完整性与保密性

与其他安全合规政策一样，GDPR 并未定义实现这一目标的技术方法。GDPR 可能对于工程团队来说仍然过于宏观，需要将其转化为软件安全需求、设计、威胁建模、工具等。下表总结了工程团队的典型安全实践：

阶段	隐私或敏感信息处理的常见安全实践
设计	隐私影响评估（PIA）
编码

数据掩码库
匿名工具箱
RAPPOR—隐私保护报告算法
加密存储（RSA，ASE）
安全擦除
安全通信协议（如 TLS v1.2、SSH v2、SFTP、SNMP v3）
Cookie 同意
数据保险库
密钥管理

测试	OWASP 对弱加密的测试、错误处理测试、配置测试等
部署

OWASP 配置和部署管理测试
CIS 安全环境配置
Git 中的敏感信息

监控

用于日志分析的 ELK
完整性监控（IDS/IPS）以监控任何未经授权的更改
CIS 安全配置监控
Git 中的敏感信息泄露

新技术（第三方、云、容器和虚拟化）

新技术如虚拟化、Docker 和微服务引入了新的软件交付方法，加速了应用程序的部署，但也带来了新的安全威胁和风险。我们将简要讨论这些新技术如何改变安全和 DevOps 的实践。

虚拟化

在虚拟化操作系统上安装应用服务是非常常见的。虚拟化技术有助于最大限度地利用物理机的资源，如 CPU、内存和硬盘。然而，虚拟化是一种共享操作系统技术，它还引入了如 VM 逃逸、信息泄露和拒绝服务等安全风险，影响在虚拟化上运行的应用程序。

客户操作系统虚拟化中的安全实践通常涉及操作系统和虚拟化的强化。以下是与虚拟化相关的一些关键安全配置。有关详细信息，请参考 CIS 基准：

限制虚拟机到 VMX 文件的消息传递
限制控制台连接共享
断开未经授权的设备（USB、DVD、串行设备等）
禁用BIOS 启动规范（BBS）
禁用客体与主机的交互协议处理程序
禁用主机和客体文件系统服务器
禁用 VM 控制台粘贴操作
禁用虚拟磁盘缩减
不向客户发送主机信息

以下图示展示了虚拟化的采用情况。虚拟化在物理服务器上增加了一个虚拟机监控器层，从而使虚拟化的客户操作系统可以在其上运行：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

除了虚拟化的安全配置外，为虚拟化应用安全补丁也是运维或 IT 团队必须进行的操作。

此外，以下资源可能有助于您在漏洞数据库中查找公共漏洞与暴露（CVE）：

漏洞利用数据库 www.exploit-db.com/
SecLists seclists.org/fulldisclosure/
漏洞备注数据库 www.kb.cert.org/vuls/

要查找特定产品或供应商的漏洞，请参考以下 URL 搜索 VMware 的相关信息：

Docker

Docker 的引入为软件包的交付和安装提供了新的选择，可以成为在不使用完整独立操作系统虚拟机的情况下隔离不同应用程序的最佳方式之一。软件可以通过 Docker 打包成容器。容器像虚拟机镜像一样，包含了运行应用服务所需的一切，例如运行时、系统库和设置。虚拟机镜像和容器之间的关键区别在于，容器并不包含整个操作系统。容器只包含必要的系统库，每个容器在运行时共享同一个操作系统内核。因此，Docker 容器可以在几秒钟内启动，并且使用的内存和磁盘比虚拟化镜像少得多。

使用 Docker 还可以极大地帮助运维团队进行部署和安全配置，因为 Docker 容器包含了运行所需的所有配置和设置。要了解 Docker 安全实践，可以查看 CIS Docker 基准 和 Docker 安全，并参考 进一步阅读 部分。

以下是 Docker 的一些关键安全实践和配置：

为容器分配独立分区
更新的 Linux 内核
仅允许可信用户控制 Docker 守护进程
审计 Docker 守护进程、文件和目录
限制容器之间的网络流量
Docker 守护进程的 TLS 认证
不要将 Docker 绑定到另一个 IP/端口或 Unix 套接字
Docker 守护进程配置文件的权限
容器运行时（Linux 内核能力、SSH、端口、内存、CPU、IPC）

以下图表展示了虚拟化和 Docker 之间的关键区别。虚拟化是在客体操作系统层级，而 Docker 实际上是在应用程序层级进行隔离，并且共享相同的客体操作系统：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

这是对 Docker 中已识别的已知安全漏洞的总结。

CVE ID	相关 CWE ID	描述
CVE-2014-5282	20	Docker 在 1.3 之前没有正确验证镜像 ID，允许远程攻击者通过 Docker load 加载不可信的镜像来重定向到另一个镜像。
CVE-2017-14992	20	Docker-CE（也称为 Moby）及更早版本缺乏内容验证，允许远程攻击者通过构造的镜像层有效载荷发起拒绝服务攻击；即 Gzip 攻击。
CVE-2017-7297	264	Rancher Labs rancher server 1.2.0+ 存在漏洞，认证用户可以通过 API 调用禁用访问控制。此问题已在版本 rancher/server:v1.2.4、rancher/server:v1.3.5、rancher/server:v1.4.3 和 rancher/server:v1.5.3 中修复。
CVE-2016-9962	362	RunC 允许通过 runc exec 让附加的容器进程被容器的 pid 1 进行 ptrace 跟踪。这使得容器的主进程（如果以 root 身份运行）可以在初始化期间访问这些新进程的文件描述符，并可能导致容器逃逸或在进程完全放入容器之前修改 runC 状态。
CVE-2014-0047	n/a	Docker 1.5 之前允许本地用户通过涉及不安全的/tmp 使用的向量产生未指定的影响。

这里有一个查询特定漏洞的技巧。以’CVE-2014-0047’为例，只需在以下 URL 末尾替换 CVE ID 号即可。

基础设施即代码（IaC）

Puppet、Chef、Ansible 和 SaltStack 是应用 IaC 的工具。使用这些工具的关键优势是，任何系统配置都可以在设计阶段以文本文件的形式定义，且变化可以通过版本进行管理。这将帮助运维或开发团队构建安全配置基准，如文件权限、防火墙规则、Web 配置或 MySQL 连接。一旦安全配置基准定义完成，运维团队可以监控任何未经授权的更改，或将配置回滚到之前的特定版本。

例如，我们可能有一个为 Web 服务环境定义的安全防火墙基准规则，只允许端口80和443。操作团队只需使用其中一个工具（Puppet、Chef、Ansible、SaltStack）定义防火墙规则，框架就会应用这些规则，审核，并且如果其他端口因错误或其他服务部署而被意外打开，甚至会自动修正。

可在github.com/dev-sec访问的 DevSec 加固框架项目提供了 Ansible、Chef 和 Puppet 的安全配置基准模板脚本。

以下图表展示了 IaC（例如 Puppet）是如何工作的：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

云服务的黑客攻击/滥用

CSA 关于云安全关注问题的调查已经确定了以下 12 个问题：

数据泄露
弱身份、凭证和访问管理
不安全的 API
系统和应用程序漏洞
账户劫持
恶意内部人员
高级持续性威胁（APTs）
数据丢失
不足的尽职调查
云服务的滥用和恶意使用
拒绝服务
共享技术问题

此外，服务滥用也成为大多数电子商务或购物网站的难题。我们以一个例子来了解黑客或不当用户如何从中获益。

案例研究 – 正在销售的产品

假设某在线购物商店将在 2 月 1 日 12:00 为前 100 名顾客提供某款新型号手机的 50%折扣。

黑客通常做什么？

对于这种利润达到 50%的销售活动，它对恶意用户有很大的吸引力。地下用户通常会采取一些行动，如大量注册用户账户。在短时间内，仅在促销前夕，可能会注册超过 10,000 个用户账户。销售开始时，他们会使用自动化脚本触发购买行为，并在几秒钟内完成订单。一旦他们下单或占用了所有手机，他们可能会以更高的价格转售，甚至可能不支付订单。

这合法吗？ 这些行为遵循注册和购买的业务规则。尽管这些行为可能不违反法律，但可能被视为不当行为或滥用服务。因此，这种销售活动可能需要额外的业务规则和规范。毕竟，这并不是纯粹的黑客行为。我们将在后续章节中讨论这一点。这里，我们提供一些缓解措施的概述，这些措施可以通过业务规则或技术方法实现：

销售仅限于具有一定购买历史的客户
应用验证码以区分人类和机器
双因素认证和通过短信注册
检测和关联 IP、电话号码、电子邮件、账户 ID、物理地址和 GeoIP 位置
异常的页面浏览行为，如跳过产品直接进入购买页面
从同一 IP 或设备登录或注册异常大量行为

快速发布

对于云服务，快速、频繁和迭代发布非常常见。这通常推动了 DevOps 实践的需求。这既是一个机会，也可能是一个安全挑战。挑战在于，频繁的短周期发布可能没有足够的时间进行完整的安全测试。DevOps 实践有三个成熟度级别：

成熟度级别	已实现	技术采用
持续集成

源代码仓库和版本控制
带有每日构建和单元测试的 CI 工作流

Jenkins
Git
单元测试

持续交付

自动化部署到预生产环境
在预生产环境中的集成测试
部署到生产环境是手动完成的

IaC（Puppet）
Docker

持续部署

在生产环境中的自动化部署和验收测试
生产环境的变更或配置管理

IaC（Puppet）
Docker
自动化验收测试
配置监控

DevOps 实践的采用意味着开发、QA、IT 和运维团队之间更多的协作，以及持续集成或持续交付工具的逐步采用。这为转向 DevSecOps 提供了良好的基础。根据现有 CI/CD 的成熟度，可以在现有的 CI/CD 框架上添加安全实践或工具。最有效且学习曲线最小的方式是不要改变现有的开发、QA、IT、运维团队的工作方式。围绕现有的 CI/CD 构建安全工具仍然是最佳方法。我们将在接下来的章节中进一步探讨这一点。

下图展示了开发、QA 和运维在整个 CI/CD 生命周期中涉及的安全性。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

摘要

在本章中，我们讨论了驱动安全需求的外部因素，如安全合规性、法规和市场。此外，新技术的采用也带来了新的挑战，如 Docker、虚拟化、云服务和 IaC。

在安全合规性方面，我们简要讨论了 ISO 27001 以及 CSA 介绍的一些安全最佳实践/工具，如 CCM、云安全指南、CAIQ 和云顶级威胁。同时还讨论了 FIPS 在正确使用加密方面的重要性。在基础设施安全方面，介绍了 CIS 和 OpenSCAP。最后，欧盟 GDPR 法规规范并推动数据和隐私保护的安全要求。

基于所有这些安全挑战和合规规则，我们介绍了一个云服务的小案例研究，云服务可能被黑客攻击和滥用。此外，还探讨了哪些安全技术可能适用于 DevOps 实践。在接下来的章节中，我们将进一步讨论安全目标、度量标准和安全保障计划如何适用于不同类型的组织和实践。

问题

FIPS 是否定义了加密的安全要求？
以下哪个选项定义了主要关注个人数据隐私的安全合规性？
1. ISO 27018
2. FIPS
3. GDPR
4. CIS
什么可以被视为云服务滥用？
1. 账户共享
2. 暴力破解登录
3. API 滥用
4. 以上所有
CIS 安全基准的用途是什么？
1. 防病毒
2. 定义操作系统、平台、数据库等的安全配置
3. 防火墙
4. 完整性
在 DevOps 周期中，哪个角色涉及安全实践？
1. QA
2. RD
3. 运维
4. 以上所有
基础设施即代码（IaC）如何帮助安全运维团队？
1. 病毒检测
2. 安全配置
3. 入侵检测
4. 加密
以下哪个不是隐私原则？
1. 欺骗
2. 目的限制
3. 存储限制
4. 准确性

进一步阅读

阅读以下链接以获取更多阅读资料：

CSA（云安全联盟）安全白皮书： cloudsecurityalliance.org/download/
NIST 在系统开发生命周期中的安全考虑：nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-64r2.pdf
ISO 29100 信息技术安全技术隐私框架：www.iso.org/standard/45123.html
NIST 国家检查表计划 nvd.nist.gov/ncp/repository
OWASP 加密指南 www.owasp.org/index.php/Guide_to_Cryptography
NVD（国家漏洞数据库） nvd.nist.gov/
CVE 详情 cvedetails.com/
CIS 网络安全工具 www.cisecurity.org/cybersecurity-tools/
ENISA 虚拟化安全性：www.enisa.europa.eu/publications/security-aspects-of-virtualization/at_download/fullReport
CIS 基准还提供了 VMware、Docker 和 Kubernetes 的安全指南：www.cisecurity.org/cis-benchmarks/
OpenStack 对虚拟化层的加固提供了构建虚拟化层的安全指南：docs.openstack.org/security-guide/compute/hardening-the-virtualization-layers.html
Docker 安全性 在 docs.docker.com/engine/security/security/

第二章：安全目标和度量

在前一章中，我们讨论了 DevSecOps 的挑战和业务驱动因素。在本章中，我们将讨论安全目标和度量。DevSecOps 的采用是一个持续的学习旅程，需要大量的利益相关者参与、流程优化、业务优先级冲突、安全工具定制以及安全知识学习。本章将基于功能角色的视角，为您提供一些实用的技巧、挑战和常见实践，并且还将以 GDPR 为例，解释如何进行隐私影响评估。

本章将涵盖以下主题：

组织目标
开发目标/度量
QA 目标/度量
运营目标/度量

组织目标

任何组织的安全最终目标是保护客户数字资产。我们将在这里讨论如何为安全保证程序和 DevSecOps 定义组织级分阶段目标的目标。

开放式 Web 应用安全项目 (OWASP) 和 软件保证成熟度模型 (SAMM) 治理在考虑组织安全目标时定义了三个关键领域：

战略和度量：建立软件安全保证程序的框架
策略和合规性：专注于确保满足外部法律或法规要求（如 GDPR 或 ISO 27001）
教育和指导：这是为了进行安全意识培训和特定角色的安全能力，以执行 DevOps

以下是与业务目标对齐的一些典型 DevSecOps 安全实践。DevSecOps 的目标可能不仅受业务目标的需求影响，还受安全环境成熟度的影响：

欧盟 GDPR 的安全合规性
OWASP SAMM 自评安全成熟度达到 2 级
每个项目准备的安全需求指南和基线
采用安全编码自动化工具供开发团队使用
威胁情报安全监控
准备好的安全设计知识库供所有开发人员参考
安全测试工具或平台已准备好用于 QA 使用

除了 OWASP SAMM 外，NIST 800-160《系统安全工程》也是软件工程过程全生命周期安全工程方法和实践的良好参考。

以通用数据保护条例 (GDPR) 安全合规要求为例，审查如何在软件工程生命周期中实施数据隐私。每当企业决定在欧盟市场销售服务时，组织都必须遵守 GDPR。从组织级安全管理的角度来看，建议在策略和度量、安全政策以及安全意识培训方面规划 GDPR 合规性。

战略和度量

为了识别当前组织的业务风险概况，特别是 GDPR 合规性，建议定义隐私影响评估（PIA）模板和流程，审查当前数据处理风险。PIA 是一个工具，通过以下评估，帮助识别在开发和运营周期中的隐私风险。

是否应收集该信息
收集的信息类型，以及与个人可识别信息（PII）相关的信息
保护和处理信息的流程，以减轻任何隐私风险。
用户收集、处理、编辑或删除信息的选项和明确同意。

请参阅www.bitkom.org/noindex/Publikationen/2017/Leitfaden/170919-LF-Risk-Assessment-ENG-online-final.pdf以获取 PIA 资源和模板。

政策和合规性

定义所有项目需遵循的一般 GDPR 安全要求和发布门控。此外，组织可以定义以下安全政策：

发布日期的最低安全要求
身份和访问管理、隐私、密钥管理、加密和会话管理
安全设计最佳实践和模板

提供常见安全要求作为模板或政策供项目团队遵循可能是一个不错的做法。此外，提供或建议相关的实施框架，帮助将其构建到产品中，将更加有效，后续章节中我们将进行讨论。

教育和指导

教育和安全意识培训可能会根据企业的需求、文化、角色和内容而有所不同。如果 GDPR 合规性是企业目标之一，教育应当支持该目标。以下是一些示例：

隐私和数据处理安全意识培训
为开发人员、QA、DevOps 或 IT 团队提供角色特定的隐私信息培训
为员工建立一个案例研究知识库、常见问题解答和数据处理模板。

开发目标/度量标准

开发团队的安全目标是交付安全的设计和实现。根据 OWASP SAMM 实践，在构建阶段需要考虑三个关键方面：

威胁评估
安全要求
安全架构

尽管设计和实施审查通常也是开发团队活动的一部分，我们将在进一步讨论中考虑这些内容。

威胁评估

为了进行有效的威胁评估，建议项目团队使用以下指导方针或模板：

威胁建模工具/模板	理由和目的
威胁和缓解知识库	威胁和缓解知识可以帮助团队从知识列表中选择对项目最相关的内容，而不是从零开始。例如，CAPEC 或 ATT&CCK 也是很好的参考。
工具或威胁建模模板	一个模板或工具可以帮助团队交付一致质量的威胁建模报告。

此外，威胁建模分析不仅限于开发团队的角色，它还涉及整个团队，包括研发、QA 和 DevOps。

如果团队正在寻找模板或工具，以下资源是建议的起点。我们将在第七章中更详细地讨论威胁建模分析，威胁建模实践与安全设计。

常见攻击模式列举与分类（CAPEC）：capec.mitre.org/data/definitions/1000.html
对抗性战术、技术与常识（ATT&CK）：attack.mitre.org/wiki/Main_Page
Microsoft SDL 威胁建模工具：www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx
OWASP 威胁建模备忘单：www.owasp.org/index.php/Threat_Modeling_Cheat_Sheet
特权提升（EoP）卡牌游戏：www.microsoft.com/en-us/sdl/adopt/eop.aspx
OWASP Cornucopia：www.owasp.org/index.php/OWASP_Cornucopia

如果你正在寻找威胁与缓解的知识库，CAPEC 和 ATT&CK 都提供了非常好的参考。如果你需要绘制图表来进行威胁分析，Microsoft 的 SDL 威胁建模工具可能会有所帮助。如果你希望给团队快速介绍威胁建模，可以参考 OWASP 威胁建模备忘单。最后，EoP 和 OWASP Cornucopia 提供了卡牌游戏，使得威胁建模过程更加互动，并促进团队成员之间的参与。

GDPR 威胁评估

典型的威胁评估包括欺骗、篡改、否认、信息泄露、破坏、升级（STRIDE）。当涉及到 GDPR 合规评估时，隐私影响评估（PIA）将重点关注每个模块如何收集、处理和删除个人可识别信息及隐私数据。除了 STRIDE，PIA 还关注个人数据保护的原则。

请参考下图的 PIA，以探索数据流：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

交付物和开发团队自我评估

开发的交付物包括威胁建模、设计和编码。下表总结了开发团队自我评估的示例指标：

交付物	自我评估检查表
威胁建模分析报告	威胁建模分析是否涵盖了 STRIDE 六大威胁分析？图表中是否包括了所有组件、数据流和信任边界？所有的威胁缓解措施是否有效并已纳入发布计划？威胁建模分析是否覆盖了所有新特性和之前发布的风险？将有效的威胁缓解措施作为案例分享。
安全编码分析报告	是否有任何静态安全代码扫描工具适用于整个项目，包括遗留部分？所有扫描结果和误报警告是否已被审查和检查？安全编译选项是否已正确配置？所有危险或不安全的 API 是否已识别并移除？有效的代码扫描工具、定制扫描规则、缓解方法或常见编码问题案例的知识分享。
安全架构	案例研究。交付通用安全框架。应用行业最佳实践安全框架。

安全需求

安全需求取决于业务环境、法规和安全合规性。组织应定义一个最低的预期安全需求基准，作为发布门槛的一部分。根据严重性和影响，发布计划可能会有不同条件，如依赖热修复准备、直到问题修复后才发布、带有缓解保护的发布等。

拥有一个安全需求发布基准将有助于在利益相关者之间建立共识，比如 IT、开发团队、安全团队等。否则，业务团队可能希望发布，即使存在安全缺陷，而安全团队可能不同意发布。

这是市场时间与安全成熟度水平之间的权衡。目标是建立适当（而非完美）的安全控制，以保护数字资产，在安全质量和市场发布时间之间找到平衡。

OWASP 应用安全验证标准 (ASVS) 定义了三个安全需求级别：

	应用场景	威胁保护
ASVS 级别 1	这是所有应用程序的最低安全要求。	简单且易于利用的漏洞。
ASVS 级别 2	处理敏感数据的应用程序。	利用特定工具和目标攻击来攻击应用程序中的弱点。
ASVS 级别 3	需要最高安全级别的应用程序，如电子商务、健康系统、股票交易所或关键服务。	攻击级别 3 应用程序需要更深入的架构或代码分析。

此外，OWASP 安全软件合同附件定义了一个软件合同模板，涵盖外包项目的安全需求：Https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex/。

请参见以下图表，展示 OWASP ASVS 要求与 Web 架构的映射：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

在组织层面，保持推荐的安全框架或模块清单可以帮助项目团队不仅在成熟框架之上构建服务，还能减少已知的安全风险。不要重复发明轮子。一个组织应该将这些常见的安全模块作为其安全知识库的一部分。以下是与 OWASP ASVS 对应的常见关键安全模块映射。这并不是一个全面的清单；如果你需要寻找其他开源模块，BlackDuck Open Hub 可能是一个很好的数据库：www.openhub.net。

安全需求	开源安全框架
V2: 身份认证	OpenSAML2 for JavaCentral Authentication ServiceHostapd
V3: 会话管理	Shiro, Spring Security
V4: 访问控制	Shiro, Spring Security, OpenSAMLOpenLDAP, Apache Directory Studio
V5: 恶意输入处理	Apache Jakarta commons validatorBean ValidationOWASP Java HTML Sanitizer
V6: 输出编码/转义	Apache Santuario, Apache XML Security for JavaOWASP Java Encoder Project
V7: 加密技术	OpenSSL, BouncyCastle, scrypt, KeycZar
V8: 错误处理与日志记录	Apache Log4j, Apache Jakarta 通用日志记录
V9: 数据保护	Hashicorp Vault, Google Rappor, 私密数据共享接口, UTD Anonymization 工具集, letsEncrypt, BetterCrypto, mbed TLS
V10: 通信安全	OpenSSL, OpenSSH, JSCH
V11: HTTP 安全配置	OpenSCAP
V12: 安全配置	OpenSCAP
V13: 恶意控制	VisualCaptcha
V14: 内部安全	本节已合并到 V13。
V15: 业务逻辑	不适用
V16: 文件与资源	ProjectSend, LinShare
V17: 移动安全	VisualCaptcha
V18: 网络服务	Shiro

QA 目标/指标

在验证的这个阶段，QA 的角色是评估与软件安全相关的问题、代码级漏洞、配置错误或导致重大安全风险的逻辑错误等。OWASP SAMM 定义的验证阶段关键安全活动包括设计审查、实施审查和安全测试。由于我们将在后续章节中讨论软件安全验证的详细信息，这里重点介绍本阶段的一些关键实践。

设计审查

在实践中，安全设计审查可以视为低级威胁建模。设计审查时建议关注以下内容：

安全合规检查清单
安全需求检查清单（OWASP ASVS）
Top 10 安全设计问题
先前版本中的安全问题
客户或市场反馈的安全问题

当我们进行针对顶级安全问题的设计审查时，我们也可以参考一些行业实践，如 OWASP Top 10 和 CWE/SANS Top 25 最危险的软件错误。同时，项目团队也可以基于历史记录或客户反馈，制定自己的顶级安全问题：

OWASP Top 10: www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
CWE/SANS Top 25 最危险的软件错误: cwe.mitre.org/top25/

此外，我们还可以审查设计是否能够有效缓解我们在威胁评估阶段分析的安全风险。ATT&CK 也是设计审查的一个很好的参考来源，因为它列出了威胁的技术以及缓解建议：

ATT&CK 对抗战术、技术与常识: attack.mitre.org/wiki/Main_Page

实施审查

实施审查涉及开发团队中的以下关键活动：

安全编码
选择可靠且安全的第三方组件
安全配置

由于我们将在后续部分讨论安全配置，本节将重点讨论第三方组件和安全编码。自动化的安全代码扫描被认为是审查的最有效方式。对于安全代码审查，有一些不同的技术方法。

第三方组件

对于第三方组件的管理与审查，建议遵循以下安全指南：

第三方软件评估检查表：

这将使每个项目能够遵循一致的标准来引入外部第三方软件组件。

项目推荐使用的第三方软件：

拥有一个内部的第三方组件数据库可以让项目团队交叉参考哪些项目可能使用了第三方组件以及其集成方式。

第三方组件的 CVE 状态：

任何第三方组件都可能引入安全风险。将安全补丁更新的跟踪和规划作为运维团队的常规任务。

IDE 插件代码审查

为代码审查配置 IDE 插件可以帮助开发者在提交代码之前，就能现场学习并纠正安全代码问题。这是最有效、对开发者来说挑战最小的安全编码方式。然而，由于它是逐行静态代码扫描，并且无法分析整个源代码的上下文，扫描结果可能会出现一些误报。

静态代码审查

静态代码扫描工具在日常构建中使用，或在代码提交进行扫描时使用。这是识别软件开发初期安全问题的最有效方法。有多种静态代码扫描技术。如果你希望进一步评估这些工具，可以参考 OWASP 基准项目（www.owasp.org/index.php/Benchmark）：

技术	它是什么？	示例
静态应用程序安全测试（SAST）	静态代码扫描。开发人员可以将此工具作为 IDE 插件的一部分使用，或者与日常构建一起触发扫描。由于易于使用，因此被视为基础的代码扫描工具。	FindSecbugs，Fortify，Coverity，klocwork
动态应用程序安全测试（DAST）	DAST 通过向运行时 Web 应用程序发送攻击负载来识别安全问题，代替代码审查。	OWASP ZAP，BurpSuite
互动应用程序安全测试（IAST）	IAST 不仅进行 DAST 安全测试，还可以通过 RASP 代理在源代码级别识别根本原因/原因。简单来说，IAST = RASP 代理 + DAST。	CheckMarks，Varacode
运行时应用程序安全保护（RASP）	RASP 通常用于 Web 应用防火墙，因为它可以实时检测攻击并采取缓解措施。	OpenRASP，参考`github.com/baidu/openrasp`

目标代码审查

此外，我们还可以通过识别相关代码模式，针对特定的安全问题进行定位和聚焦。这也是一种静态应用程序安全测试（SAST），但更侧重于具体问题。这是审查特定类型安全漏洞的最有效方法。例如，当涉及到加密时，以下 Java API 被认为是不安全的，应该避免使用：

MD5; RC4; SH1; DES; skipjack, SEAL, blowfish, random

OWASP 代码审查项目和 SEI CERT 编码标准是很好的参考。如果需要其他代码审查过程的技巧，请参阅第八章，安全编码最佳实践。

OWASP 代码审查项目 www.owasp.org/index.php/Category:OWASP_Code_Review_Project
SEI CERT 编码标准 wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards

安全测试

安全测试的目标是确保整体应用程序符合安全要求、行业标准、客户期望和监管控制。从组织层面来看，建议在发布标准、测试计划/用例和自动化测试工具包方面准备好以下工具和知识：

安全发布标准：

发布标准定义了质量发布门的最低要求。它们可以帮助业务利益相关者就何时发布软件达成共识。拥有这样的基准将有助于减少开发、质量保证和 DevOps 团队之间的大量沟通问题或争论。

安全测试计划/案例：

OWASP 测试指南和 OWASP ASVS 为安全测试计划/案例提供了非常好的参考基础。对于移动安全测试，请参考 OWASP 移动安全测试指南。www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide

自动化测试工具包：

安全自动化的最佳方法是将安全工具与现有的 CI/CD 框架（如 Jenkins）集成。这可能需要安全工具具备 CLI 或 RESTful API 接口，并能够输出 XML/HTML/JSON 格式的报告。

为开发和质量保证团队构建内部工具包进行安全测试非常重要。如果您的组织刚刚开始构建内部安全测试工具集，Kali Linux 中的工具集列表是一个不错的起点。Kali Linux 工具列表提供了多个领域的完整安全测试工具集。工具列表请访问：tools.kali.org/tools-listing。对于移动测试，请参考移动安全测试指南（MSTG）：github.com/OWASP/owasp-mstg/。

您可以考虑构建一个内部的安全测试平台，配备所有准备好的安全工具。一旦软件包被部署，安全测试平台将触发进行各种类型的安全测试。例如，软件保障市场（SWAMP）提供基于云的源代码安全分析，支持多种编程语言和工具：www.mir-swamp.org/。

操作目标/指标

基于 SAMM，操作目标可以分为三个功能：问题管理、环境加固和操作启用。我们来讨论一下每个功能中的一些最佳实践。

问题管理

这里的问题管理指的是如何处理安全事件、漏洞问题或安全漏洞。应该建立一个漏洞管理流程，涉及 DevOps 和开发团队的合作。

在组织级别的安全保障计划中，必须定义安全事件和漏洞响应流程，以及根本原因分析模板。NIST SP800-61 是组织建立安全事件响应流程的良好参考。它将事件处理行动清单分为三个阶段：检测与分析；遏制、根除与恢复，以及事件后活动。

该表列出了安全事件处理周期中的典型安全活动：

阶段	开发团队	DevOps/IT 团队
漏洞接收	初步评估接收到的漏洞。给安全问题初步的 CVSS 评分，以了解其严重性和影响级别。事件响应团队（包括 DevOps、开发和 IT）讨论行动计划和初步响应。
内部/外部通信
根本原因分析	技术和开发团队将调查安全问题，如哪些 API 引发了问题、数据流可能产生的影响、使用了哪些工具或载荷，并提出修复计划。	IT 或 DevOps 可能会检查它是否是已知的 CVE 或漏洞，并查看是否有可用的补丁。如果可以应用防火墙或虚拟补丁安全控制来缓解问题，还需要分析其他云服务或接口是否也存在类似问题。
缓解措施	代码更改及相关影响服务，安全配置更改。	防火墙安全策略虚拟补丁安全规则安全补丁部署安全配置更改
部署与验证	部署与验证。

除了有行动清单外，最好还要有漏洞根本原因分析模板。根本原因模板将帮助事件响应团队了解应遵循的步骤、如何收集发现结果以及应进行哪些根本原因分析。

环境加固

环境加固中的组织级安全策略应至少涵盖：

安全配置基准
持续监控机制

安全配置基准定义了什么是安全的，监控机制确保所有配置始终保持安全。

安全配置基准

安全配置指南包括操作系统、服务器、通信协议、软件、Web 服务、数据库、虚拟化等。强烈建议参考 CIS 基准（www.cisecurity.org）作为基准：

	常见软件组件
数据库	MySQL, SQL Server, Oracle
Web 服务	Apache Tomcat, NginX
虚拟化	VMWare, Docker
操作系统	Linux（CentOS、REdHat、Suse、Ubuntu），Windows Server

持续监控机制

除了有安全配置基准外，还应有一个通用策略来定义应扫描哪些内容以及可以使用哪些工具：

	目的	开源工具
常见漏洞与暴露 (CVE)	了解云服务是否存在任何已知的公共漏洞。参考`cve.mitre.org/`。	OpenVAS, NMAP
完整性监控	确定主要系统配置文件是否已被篡改。	OSSEC
安全配置合规性	安全配置以符合行业最佳实践。	OpenSCAP(`www.open-scap.org/`)
敏感信息暴露	审查配置文件中是否存在任何个人身份信息、密钥或秘密泄露。	该领域没有特定的开源工具，但我们可以定义特定的正则表达式模式来扫描敏感信息。

操作支持

操作支持主要关注开发团队与 DevOps/IT 团队之间的互动。运营团队的典型活动包括将软件包部署到生产环境，确保每次软件发布的完整性，确保通信协议的安全性，确保配置的安全性，以及修复软件漏洞的更新。以下三项被认为是开发团队将软件发布交付给运营团队进行生产部署审查时必须具备的事项。

应用程序部署的代码签名
应用程序通信端口矩阵
安全的应用程序配置

应用程序部署的代码签名

代码签名的目标是确保软件包的完整性和真实性。它确保应用程序没有被修改，并确定该应用程序的来源是由特定的供应商签名的。代码签名不仅仅是一个指南或流程，它是持续集成构建过程的一部分。

应用程序通信端口矩阵

服务通信端口矩阵的目的是让 IT/DevOps 团队了解使用了哪些通信端口/协议。通信端口列表将帮助安全团队进行必要的防火墙配置调整或监控。这还将帮助 IT/DevOps 团队建立网络通信基线，并能够识别不寻常的端口或通信流量。下面是一个示例通信端口矩阵：

源服务	源 IP	源端口	目标服务	目标端口	协议	用途	如何配置
`Service A`	`10.1.1.1`	`80`	`Service B`	`8080`	`10.1.1.2`	`REST API`	`/ect/nginx.conf`

应用程序配置

应用程序配置列表定义了服务或应用程序配置的列表，并包含变更历史信息。其目的是允许 DevOps/IT 团队管理安全配置，并监控任何未经授权的更改。配置列表可能涵盖操作系统、虚拟化、Web 服务、数据库以及特定于目标服务的框架。这些配置通常通过基础设施即代码（如 Puppet 或 Chef）来完成。基础设施即代码使得在实施阶段也能实现安全配置，并允许开发与运维团队之间更轻松的协作。

总结

本章我们从不同角度基于 OWASP SAMM 框架讨论了安全实践。我们讨论了不同角色的安全活动，如安全管理、开发、质量保证和运营团队。

首先，从安全管理的角度来看，包括组织目标、政策和教育。我们以 GDPR 合规为例，展示了安全管理中可以进行的规划。

对于开发团队，关键的安全活动包括威胁评估、安全需求和安全架构与编码。尽管安全编码在开发阶段也被认为是关键，但我们将讨论转移到了安全代码验证阶段。在威胁评估方面，我们介绍了一些行业工具、最佳实践，甚至是卡牌游戏。我们以 GDPR 隐私评估为例，解释了如何执行 PIA（隐私影响评估）。对于自我评估，我们列出了开发团队的关键交付成果。我们还讨论了 OWASP ASVS 安全需求，以及 ASVS 如何与网页框架实施相结合，并提供了建议的开源组件。

在验证方面，包括设计审查、实施审查和安全测试。我们讨论了设计审查的关键考量以及 OWASP 十大安全风险。还讨论了不同类型的安全编码审查工具。安全测试包括发布标准、测试计划和自动化测试工具包。毕竟，自动化安全测试是 DevOps 中的终极目标。

运营活动主要包括安全问题管理、环境加固和运营支持。向 DevSecOps 发展，这些活动不仅高度涉及运营团队本身，还包括开发和 QA 团队。我们举了应用程序通信端口矩阵和配置清单等例子，并分析了安全事件的根本原因。

在下一章节中，我们将讨论安全保障项目和组织，以及组织或文化如何在组织中执行安全程序。

问题

OWASP SAMM 是否代表软件保障成熟度模型？
以下哪些是在 OWASP 安全治理中定义的？
1. 策略与指标
2. 政策与合规性
3. 教育与指导
4. 以上所有
根据 OWASP SAMM，在构建阶段应考虑哪些事项？
1. 安全架构
2. 威胁评估
3. 安全需求
4. 以上所有
以下哪项不是威胁建模的工具或技术？
1. CAPEC
2. ATT&CK
3. OWASP Cornucopia
4. GDPR
在 GDPR 中，我们可以应用哪些安全实践进行隐私评估？
1. PIA 隐私影响分析
2. 渗透测试
3. 问题管理
4. ISO 27001

进一步阅读

GDPR 隐私影响评估: gdpr-info.eu/issues/privacy-impact-assessment/
对抗性战术、技术与常识: attack.mitre.org/wiki/Main_Page
SDL 威胁建模工具: www.microsoft.com/en-us/sdl/adopt/threatmodeling.aspx
权限提升（EoP）卡牌游戏: www.microsoft.com/en-us/sdl/adopt/eop.aspx
SP 800-100 信息安全手册：管理者指南 csrc.nist.gov/publications/detail/sp/800-100/final
软件保障市场: www.mir-swamp.org/
NIST 软件保障参考数据集中的资源: samate.nist.gov/SARD/around.php
NIST 测试套件: samate.nist.gov/SARD/testsuite.php
NIST 关于服务器虚拟化管理程序部署的安全建议: nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-125A.pdf
NIST 保护非联邦信息系统和组织中的受控非机密信息: www.nist.gov/publications/protecting-controlled-unclassified-information-nonfederal-information-systems-and-3
NIST 系统安全工程: www.nist.gov/publications/systems-security-engineering-considerations-multidisciplinary-approach-engineering-1
OWASP 移动安全测试指南: www.owasp.org/index.php/OWASP_Mobile_Security_Testing_Guide

第三章：安全保障程序和组织

本章将讨论安全保障程序，如安全开发生命周期（SDL）、OWASP 软件保障成熟度模型（SAMM）和 ISO 27001。然后，我们将讨论安全如何随着业务的增长而发展。此外，还有一些非技术性的内容对于任何安全程序的成功至关重要，比如流程、指导方针、培训和角色。将通过一个小案例研究来说明不同的组织结构如何影响安全保障程序的执行。

本章将涵盖以下主题：

安全保障程序
随着业务的增长，安全的发展
安全团队在组织中的角色
案例研究——矩阵、功能或工作组结构

本章结束时，你将学习以下内容：

安全保障程序的关键部分，用于推出 DevSecOps
安全如何与业务共同发展
安全程序中的过程、角色和培训部分
如何规划跨业务部门的安全团队

安全保障程序

我们将通过介绍一些行业实践，如 SDL、OWASP SAMM 和 ISO 27001，讨论安全保障程序。SDL 列出了整个开发生命周期中的安全活动。OWASP SAMM 解释了如何在四个不同的功能角色中应用三种成熟度级别的安全实践。ISO 27001 被认为是安全认证标准的基础，并概述了安全管理程序应该是什么样的。

SDL（安全开发生命周期）

微软定义了SDL（安全开发生命周期），帮助开发人员构建安全的软件。每个开发阶段的安全活动如下表所示：

MS SDL 阶段	安全活动
培训

核心安全培训

需求

建立安全需求
创建质量关卡/缺陷标准
执行安全和隐私风险评估

设计

建立设计需求
执行攻击面分析减少
使用威胁建模

实施

使用批准的工具
弃用不安全功能
执行静态分析

验证

执行动态分析
执行模糊测试
进行攻击面审查

发布

创建事件响应计划
进行最终安全审查
认证、发布和归档

响应	执行事件响应计划

尽管组织可以遵循或参考成熟的 SDL 过程，但这些安全实践及其执行的关键在于如何将这些安全实践融入开发人员、QA 或开发团队的日常任务中。此外，任何安全程序要成功，必须根据业务需求量身定制，并支持业务的成功。

以开发者的日常例行任务为例——他需要理解业务和功能需求来进行设计，应用适当的第三方模块，编码、调试、排错，并进行本地编译/构建以进行验证。仅仅为了完成项目的功能以满足截止日期，就需要做很多工作。安全编码活动涉及超过 100 条安全编码规则。对于任何开发者来说，成为所有编码规则的专家，甚至只是意识到这些规则，都是一个巨大的挑战。

因此，在大多数情况下，采用合适的工具将大大有帮助。如果开发者使用 Eclipse 作为主要的源代码编辑器，那么建议你将安全编码工具作为 Eclipse 插件的一部分。根据编程语言和集成开发环境（IDE），安全和开发团队可能会制定一个计划，涉及如何将安全工具融入到日常任务的开发中。虽然安全编码指南依然是必不可少的，但实施安全编码最有效、最高效的方式是为每个开发者提供一个易于使用的工具，将其作为日常任务的一部分。

同样的情况也适用于 QA 或 IT DevOps 团队。要求每个 QA 或 IT 团队都熟悉所有的安全测试或加固实践是一项挑战。最好的方法也是提供相关的自动化安全工具来完成这些工作。

OWASP SAMM

OWASP SAMM 将安全实践分为四个关键的业务功能——治理、构建、验证和运维。对于任何组织来说，这是一个非常实用的自评安全成熟度水平的指南。微软 SDL 在开发过程中定义了安全实践，而 OWASP SAMM 则基于业务功能和四个安全成熟度级别定义了安全实践：

业务功能	安全实践
治理

策略与度量
政策与合规
教育与指导

构建

威胁评估
安全需求
安全架构

验证

设计审查
实施审查
安全测试

运维

问题管理
环境加固
运维启用

根据组织的不同，业务功能或构建、验证和运维之间的边界可能有所不同；在 DevOps 环境下，OWASP SAMM 12 安全实践被视为最低要求。如果我们将业务组织功能映射到 OWASP SAMM，它可能看起来像下图所示。这里有一个 CSO，负责管理整个安全程序：开发团队负责软件应用构建，安全测试团队负责验证，IT 或运维团队负责应用运维：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

安全指南和流程

在审视了行业实践、SDL、OWASP SAMM 和 ISO 27001 后，通常是 CSO 或 CTO 安全办公室的责任来定义安全治理程序和安全指南。下表展示了安全指南的概述。在实践中，这些安全指南是模板，由中央提供建议并更新到安全知识库中，供每个项目团队参考。再次强调，如果这些指南无法融入开发人员、QA、IT 或 DevOps 的日常工作中，它们将无法发挥作用。为 DevOps 团队提供内置安全实践的工具仍然是 DevSecOps 成功的关键。下表建议了一些可能适用的行业实践和工具：

阶段	指南、模板、检查表、工具包	行业实践参考
安全培训

安全意识
安全认证程序
案例研究知识库
常见问题
渗透学习环境

OWASP 前 10 名
CWE 前 25 名
OWASP VWAD

安全成熟度评估

微软 SDL，OWASP SAMM 自评估成熟度水平

微软 SDL
OWASP SAMM

安全设计

威胁建模模板（风险/缓解知识库）
发布门控的安全要求
安全设计案例研究
隐私保护

OWASP ASVS
NIST
隐私风险评估

安全编码

编码指南（C++、Java、Python、PHP、Shell、移动端）
安全编码扫描工具
常见的安全编码案例研究

CWE
安全编码 CERT
OWASP

安全测试

安全编译选项，如栈保护（Stack Canary）、NX、Fortify Source、PIE 和 RELRO
安全测试计划
安全测试用例
已知 CVE 测试
已知安全编码问题
API 级别安全测试工具
自动化测试工具
模糊测试
移动测试
利用与渗透
安全合规性

Kali Linux 工具
CIS

安全部署

配置检查表
加固指南
通信端口/协议
代码签名

CIS 基准
CVE

事件与漏洞处理

根本原因分析模板
事件处理流程和组织

NIST SP800-61

安全培训

通过电子邮件进行安全意识培训
案例研究通讯
工具包使用实践培训
安全证书和考试

NIST 800-50
NIST 800-16
SAFECode 安全工程培训

安全与业务成长同步

根据企业的发展状态，安全需求和实施可能会受到企业目标和环境的影响。初创公司可能会利用外部云服务和现成的安全服务来保护其服务和数据。而一家价值数百万美元的云服务公司可能会根据自己的业务需求自建并定制安全服务，甚至分享其安全技术，使其成为开源。我们来讨论一下不同发展阶段的企业如何与安全实践的范围相关联。

阶段 1 – 基本安全控制

在这个阶段，我们可能在处理一家初创公司。IT 团队没有专门的安全团队。大多数安全控制来自云服务，例如 AWS。

尽管云服务可能提供安全服务，但仍然是用户的责任来保护应用和数据。因此，以下内容对这个阶段的安全保证计划至关重要。以 AWS 服务实践为例：

利用第三方云服务提供商的安全机制（例如，AWS 提供 IAM、KMS、安全组、WAF、Inspector、CloudWatch 和 Config）
安全配置依赖外部工具，如 AWS Config 和 Inspector
服务或操作监控可能会应用 AWS Config、Inspector、CloudWatch、WAF 和 AWS Shield

组织中可能仍然没有熟练的安全编码开发人员或渗透测试人员。团队大多仍依赖外部工具和服务进行安全实践。

第二阶段 – 构建安全测试团队

在这个阶段，业务已经稳定和成熟。组织可能会建立一个安全测试团队，负责在发布前进行应用安全验证，并持续监控环境漏洞。开发团队可能会在安全缺陷和问题上高度依赖安全测试团队，开发团队专注于业务的功能开发，尚未参与安全设计或安全编码。

专门的安全测试可能开始使用一些安全自动化测试或开源监控工具。开发人员通过逐步识别的安全缺陷案例来学习安全编码，仍然没有采用正式的威胁建模、设计或架构安全审查过程。团队正处于将安全转向左侧的初期阶段。

在这个阶段，内部安全团队可能会尝试调查或使用部分开源安全工具。以下表格展示了你可以考虑应用的典型安全工具包：

类别	开源工具名称
漏洞评估

NMAP
OpenVAS

静态安全分析

Java 的 FindBugs
Ruby on Rails 的 Brakeman
适用于 Java、C++、Objective C 和 C 的推理工具
Cppcheck 或 Flawfinder for C/C++

网络安全

OWASP 依赖性检查
OWASP ZAP
Archni-Scanner
Burp Suite
SQLMap
w3af

沟通

Nmap
NCAT
Wireshark
SSLScan
sslyze

基础设施安全

OpenSCAP
InSpec

虚拟机工具集

Windows 用的 Pentest Box
Kali Linux
移动安全测试框架

安全监控

ELK
MISP——开源威胁情报平台
OSSCE——开源 HIDS 安全
Facebook/osquery——高效的端点可见性
AlienVault OSSIM——开源 SIEM

第三阶段 – SDL 活动

随着软件服务交付变得越来越大规模且频繁，安全开发生命周期的需求变得至关重要。在这个阶段，关键目标是将安全实践融入到开发和运营团队中。

这一阶段的主要差异和新引入的安全实践如下：

安全性向左转，并涉及每个利益相关者
必须进行架构和设计评审，以进行威胁建模
开发人员接受安全设计和安全编码培训
运维和开发团队作为一个闭环协作
采用行业最佳实践，如 OWASP SAMM 和 Microsoft SDL，用于安全成熟度评估

在应用 SDL 时，可能会遇到一些学习曲线，甚至会有阻力。毕竟，这些安全实践将为团队带来额外的工作量。在初始的 SDL 实施阶段，充分的培训和沟通是必要的。为团队提供一些时间，以便他们熟悉安全实践和工具。让它成为一段有趣的学习之旅。

采用工具将安全性融入 DevOps 是至关重要的。使安全工具（威胁建模、安全编码、安全框架）对开发人员易于使用是将安全性提前到开发周期左侧的关键。

阶段 4 – 自建安全服务

在这一阶段，公司不仅拥有自己的安全测试和监控团队，还开发和定制自己的安全服务，例如Web 应用防火墙（WAF）和入侵检测。此外，公司甚至可能将一些安全工具或服务贡献给开源社区。安全保障计划不仅覆盖公司自身，还包括合作伙伴或生态系统。

以 Salesforce 为例—Salesforce 开发者中心门户提供安全培训模块、编码、实施指南、评估工具、代码扫描、测试或 CAPTCHA 模块，还提供开发者论坛。无论你是否在 Salesforce 上构建应用，Salesforce 开发者中心仍然是一个很好的参考，不仅适用于安全知识，也适用于你可能考虑应用的一些开源工具。

阶段 5 – 大数据安全分析和自动化

这个阶段的安全不仅仅是检测已知威胁，还包括利用云、大数据分析和机器学习来防范未知威胁，并使系统能够采取主动的保护措施。此阶段的关键特点是：

在整个开发周期中进行完全或主要自动化的安全测试
运用大数据分析和机器学习来识别异常行为或未知威胁
针对安全事件自动采取主动安全措施，例如部署 WAF 规则或虚拟补丁部署

大数据分析框架中的典型开源技术组件包括以下内容：

Flume、Log Logstash 和 Rsyslog 用于日志收集
Kafka、Storm 或 Spark 用于日志分析
Redis、MySQL、HBase 和 HDFS 用于数据存储
Kibana、ElasticSearch 和 Graylog 用于数据索引、搜索和展示

大数据安全分析的关键阶段在表格中进行了说明：

阶段	描述
数据收集	从各种来源和系统收集日志，如防火墙、Web 服务、Linux、网络网关、终端等。
数据规范化	将数据格式清理或转换为 JSON，特别是对于关键信息，如 IP 地址、主机名、电子邮件、端口和 MAC 地址。
数据增强/标记	就 IP 地址数据而言，它将进一步与 GeoIP 和 WhoIS 信息关联。此外，如果是已知的黑名单 IP 地址，还可能会被标记。
关联	关联分析关键特征之间的关系，如 IP 地址、主机名、DNS 域名、文件哈希、电子邮件地址和威胁知识库。
存储	将存储不同类型的数据——来自源的数据、丰富信息的数据、关联结果、GeoIP 映射和威胁知识库。
警报	当识别到威胁或基于指定的警报规则时触发警报。
展示/查询	用于监控和查询的安全仪表盘。ElasticSearch，RESTful API 或第三方 SIEM。

下图展示了典型的大数据安全分析框架，或者你可以参考开源的 Apache Metron 框架：cwiki.apache.org/confluence/display/METRON/Metron+Architecture。

大数据安全分析的概念架构如下所示：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

安全团队在组织中的角色

安全团队的角色和职责范围还取决于业务的阶段。最初可能是 IT 团队的一部分；之后是一个专门负责基础设施安全监控的安全团队，进而发展成专门的安全功能团队，负责安全工具开发和安全策略管理；或者是一个安全测试团队，等等。

我们来看看两种典型的场景，讨论一个组织可能涉及的角色和范围。一个是首席技术官（CTO）下的安全工程团队，另一个是一个拥有完整、安全职能的专职首席安全官（CSO）。

CTO 下的安全办公室

这是一个典型的组织结构，安全工程团队隶属于 CTO 办公室。此类组织结构有一些特点：

没有专职的首席安全官（CSO）
安全团队可能规模不大——例如，少于 10 名成员
安全工程团队根据需求为所有项目提供服务
安全工程团队的主要职责是为所有项目团队提供安全指南、政策、检查表、模板或培训
安全工程团队的成员可能会被分配到不同的项目中，成为该项目的主题专家，具体取决于项目的需求
安全工程提供指南、工具包和培训，但是项目团队负责日常安全活动的执行。

这种团队结构的缺点在于，由于安全成员有限，安全工程团队可能无法完全专注于项目。毕竟，安全将通过更紧密地与业务结合，并更深入地了解工程团队的挑战，发挥最佳作用。

下图显示了 CTP 如何基于项目管理团队，并直接向首席技术官汇报安全工程团队，以支持他们并确保所有项目和架构的安全实践：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

专职安全团队

随着业务的增长，组织可能会设立一个正式的 CSO 角色，拥有更专注的安全功能团队，例如安全管理团队、安全测试、安全工程、安全监控和安全服务：

安全管理：团队定义安全指南、流程、政策、模板、检查表和要求。安全管理团队的角色与之前在首席技术官下的安全办公室部分讨论的角色相同。
安全测试：团队在应用发布之前进行内部安全测试。
安全工程：团队为开发团队提供通用安全框架、架构、SDK 和 API。
安全监控：这是安全运营团队，负责监控所有在线服务的安全状态。
安全服务：这是开发安全服务（如 WAF 和入侵防御服务）的团队。

有时，可能是混合结构。例如，尚未有专职 CSO，但安全测试团队和安全管理团队向首席信息官报告。这一切取决于业务目标和业务需求的阶段。

这种安全团队结构包括大多数安全功能。然而，与之前的问题类似。我们希望安全内建于项目和实践之中。这将需要与项目团队的深度参与和对每个项目业务流程的清晰理解。这就是为什么我们希望在下一节讨论另一种矩阵式的组织结构：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

案例研究 - 矩阵、功能或任务组结构

约翰，作为一家云软件应用提供商的 CSO，正在规划组织中的安全团队结构。现有的安全团队包括一个安全设计团队、一个安全编码团队和一个测试团队。安全设计团队负责威胁建模、安全框架和安全设计指南。安全编码团队为开发团队提供安全编码工具和检查清单。安全测试团队负责每次服务发布的安全验证。另一方面，CSO 彼得管理着软件开发团队（包括开发人员、质量保证和运营成员）。

彼得和约翰都知道安全是一项专家知识，最好有一个专门的安全团队来确保安全知识能够跨项目应用，同时也能帮助团队成员提升安全技能。另一方面，他们也知道安全必须与业务和现有的软件开发团队紧密结合。因此，他们正在经历两个主要阶段——安全资源池阶段，随后是安全技术委员会阶段。

安全资源池

保持安全成员在一个专门的安全团队中的主要优势是能够在项目之间共享安全知识，并能够为整个组织提供工具或最佳实践。然而，要将安全实践融入到 DevOps 实践中，DevOps 和安全团队需要在一定程度上参与其中。因此，CTO 列出了全年项目计划作为参考，以规划安全团队在项目中的参与。CSO 分配安全成员参与不同的项目。在项目分配期间，安全成员向项目经理汇报工作。虽然这种方式在一段时间内有效，但在这种组织结构下也存在一些问题：

项目团队可能在很大程度上依赖于安全团队的参与。例如，开发人员可能仍然对安全编码了解较少，因为大多数工作是由安全团队完成的。
随着业务和项目的增长，安全团队成员可能会同时负责多个项目，无法处理每个项目的所有安全细节。

因此，约翰和彼得意识到这一情况，并希望现有的 DevOps 团队能更多地参与安全任务，而安全团队的角色可能更像是安全顾问。

安全技术委员会（工作组）

随着项目团队逐渐壮大，项目数量也在迅速增长。John 和 Peter 决定成立一个安全技术委员会，这是一个虚拟的专责小组，旨在促进团队参与安全工作，并推动安全知识在项目之间的共享。他们成立了三个专责小组——安全设计、安全编码和安全测试小组。以安全设计小组为例，该小组由来自安全团队的一个或多个安全设计专家，以及每个项目团队的开发者代表组成。开发者代表相当于项目团队的安全冠军。他将参与小组的安全讨论，并将安全实践或指导方针带回项目团队。安全设计小组将与来自所有项目团队的安全代表以及来自安全团队的安全专家每周举行一次会议，讨论以下主题（不是详尽无遗的清单）：

常见的安全设计问题及其缓解措施（由安全团队发起）
项目应遵循的安全设计模式（由安全团队发起）
项目的安全设计框架建议（由安全团队发起）
一些项目提出的具体安全设计问题，并寻求其他项目的建议（由项目团队发起）
某项目的安全设计评审（由项目团队发起）

开发团队与安全团队之间的安全专责小组结构如下图所示：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

没有完美的安全组织结构。关键在于与现有的业务需求和实践更好地契合。对于任何安全团队结构，最重要的是理解业务目标的目的。建立虚拟专责小组可能会补充现有的官方团队结构，因为该小组允许安全知识在各项目之间共享。

总结

本章讨论了三种典型的安全保障程序。SDL 聚焦于每个开发阶段中的安全活动。OWASP SAMM 定义了四个不同职能中的安全活动。ISO 27001 提供了安全管理程序的概述。这些都是我们构建自身安全指导方针、流程、检查表或工具包的基础。

随着业务的增长，安全的需求和范围变得更加复杂。我们将安全增长分为五个阶段。在第一阶段，我们从基本的安全控制需求开始。在第二阶段，组织可能会建立自己的内部安全测试团队。在第三阶段，安全活动将 SDL 应用到更大范围，并向左迁移——即向开发团队迁移——在早期设计阶段。在这一阶段，大多数安全工具或自动化不仅应用于测试，还应用于开发和运营团队。在第四阶段，安全团队开始建立安全服务，如 WAF 或入侵检测，而不是购买安全服务，以更好地适应业务需求。在第五阶段，团队使用大数据分析来防范未知威胁。

由于安全与每个业务利益相关者都息息相关，因此组织结构中的角色和安全团队也进行了讨论。没有完美的组织结构，只有根据业务需求和文化最适合的结构。毕竟，在任何安全计划的采纳中，都有一些重要的非技术因素需要考虑。

问题

Microsoft SDL 是否代表安全开发生命周期？
根据 SDL，设计阶段应进行哪些活动？
1. 确定设计要求
2. 执行攻击面分析减少
3. 用户威胁建模
4. 以上所有
在 OWASP SAMM 中，哪个安全实践不属于安全治理的一部分？
1. 安全与指标
2. 教育和指导
3. 安全架构
4. 政策与合规
在 OWASP SAMM 中，哪个安全实践不属于安全操作的一部分？
1. 问题管理
2. 安全需求
3. 环境强化
4. 操作启用
以下哪项不是 CTO 领导下的安全办公室的特点？
1. 大型安全团队——超过 100 名成员
2. 没有专职 CSO
3. 安全团队服务所有项目
4. 安全团队可能无法完全参与项目团队

深入阅读

Microsoft 安全开发生命周期: www.microsoft.com/en-us/SDL/
OWASP SAMM 项目: www.owasp.org/index.php/OWASP_SAMM_Project
CWE/SANS 最危险的 25 种软件错误: cwe.mitre.org/top25/
OWASP 易受攻击的 Web 应用程序目录项目: www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project
CERT 安全编码标准: wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards
NIST 特别出版物 800-53: nvd.nist.gov/800-53
SAFECode 安全白皮书: safecode.org/publications/
Microsoft Threat Modeling tool 2016: aka.ms/tmt2016/
Salesforce 开发者中心: developer.salesforce.com/devcenter/security
用于实时大数据安全的 Apache Metron: metron.apache.org/documentation/
介绍 OCTAVE Allegro：改进信息安全风险评估流程: resources.sei.cmu.edu/asset_files/TechnicalReport/2007_005_001_14885.pdf
NIST 800-18 联邦信息系统安全计划开发指南: nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-18r1.pdf
ITU-T X.805 (10/2003) 提供端到端通信的系统安全架构: www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.805-200310-I!!PDF-E&type=items
ETSI TS 102 165-1 V4.2.1 (2006-12) : 威胁、风险、漏洞分析的方法和表单: www.etsi.org/deliver/etsi_ts/102100_102199/10216501/04.02.01_60/ts_10216501v040201p.pdf
SAFECode 安全软件开发基本实践: safecode.org/wp-content/uploads/2018/03/SAFECode_Fundamental_Practices_for_Secure_Software_Development_March_2018.pdf
NIST 800-64 系统开发生命周期中的安全考虑: nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-64r2.pdfhttps://csrc.nist.gov/publications/detail/sp/800-64/rev-2/final
NIST 800-50 建立信息技术安全意识和培训程序: nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-50.pdf
CIS 安全基准: www.cisecurity.org/cis-benchmarks/
NIST 800-16 信息技术安全培训要求: csrc.nist.gov/publications/detail/sp/800-16/final
SAFECode 安全工程培训: safecode.org/publication/SAFECode_Training0409.pdf
一种混合威胁建模方法: resources.sei.cmu.edu/library/asset-view.cfm?assetid=516617
微软 SDL 工具 www.microsoft.com/en-us/SDL/adopt/tools.aspx

第四章：安全要求和合规性

我们先前在一个组织中讨论了安全保证计划，并将在本章中探讨安全要求和合规性。我们都同意安全和隐私对软件发布至关重要。然而，对产品经理来说，计划安全或隐私特性进入产品发布可能是一项挑战。

本章将讨论涵盖四个方面的安全需求：每个发布质量门的安全要求，通用 Web 应用程序的安全要求，大数据的安全要求，以及符合通用数据保护条例（GDPR）的安全要求。一些安全需求是工程驱动的，比如发布门，而一些是市场驱动的，比如 GDPR。本章通过从不同角度探讨安全需求规划指南，提供了安全需求的规划准则。

我们将在本章中涵盖以下主题：

发布门的安全要求
Web 应用程序的安全要求
大数据的安全要求
GDPR 的隐私要求

发布门的安全要求

对每个发布阶段设置安全质量标准非常重要，例如威胁建模、设计、编码、测试和部署。发布门的目标是在每个阶段提高安全发布的质量。在开始定义发布门时，建议从一些主要或高优先级的安全问题开始，因为长长的检查表不仅会增加开销，还会引起开发或质量保证团队的抵触。

在引入安全发布门时，允许团队学习，熟悉安全实践，并有可能犯错。试图成为支持团队达到更高安全质量标准的教练，而不是像警察一样检查可交付成果。

发布门的示例

当所有团队熟悉安全实践并进行了一些安全自动化后，可以为更高的安全标准添加额外的安全检查表。每个阶段的典型安全发布门示例如下表所示：

阶段	发布门示例
设计

针对高风险模块进行了威胁建模活动。
已审查了第三方组件版本的使用，没有主要漏洞。
已经审查了最常见的安全设计问题，没有主要问题。

编码

使用静态代码分析工具识别了主要的安全风险。
代码扫描结果中的高严重性问题都已经进行了检查。
在源代码中没有发现敏感信息（如密码、IP、电子邮件、加密密钥）。

构建

工具链（编译器和链接器）加固配置，如位置独立可执行文件（PIE），或地址空间布局随机化（ASLR），或数据执行防护（DEP）都已正确配置。

测试

没有高严重性的安全问题。严重性是通过常见漏洞评分系统（CVSS）版本 3.0 来衡量的。
遵循并执行了 OWASP 测试用例。
所有协议均使用模糊测试工具进行测试。

生产交付

已交付安全配置定义。
通信端口、接口和协议已文档化。

监控

服务的准备情况以及安全扫描的配置列表。
服务日志的安全分析准备情况。

常见漏洞评分系统 (CVSS)

在发布评审阶段，不同的利益相关者之间常常会就是否进入下一阶段的问题发生争论。例如，开发团队可能认为这是一个小问题，可以继续进入下一阶段，而运维团队则可能认为这是一个高风险问题。

因此，为了更客观地评估安全问题的严重性和影响，建议使用 CVSS 3.0。CVSS 3.0，www.first.org/cvss/calculator/3.0，通过回答以下八个问题来评估安全问题：

攻击向量 (AV)：攻击是否需要物理访问，还是可以通过网络进行？
攻击复杂度 (AC)：攻击是否可以在任何时间进行，还是只能在特定条件下进行？
所需权限 (PP)：攻击是否需要管理员权限？
用户交互 (UI)：攻击是否需要用户交互（例如点击）才能成功？
范围 (S)：攻击仅影响脆弱组件，还是会影响所有其他组件及整个系统？
完整性 (I)：是否会对完整性产生影响，例如篡改或更改系统信息？
可用性 (A)：是否会影响可用性，例如性能影响或服务不可用？

除了前述的基础分数外，我们还可以通过审查时间分数和环境分数来进一步评估。时间分数审查利用代码的成熟度、修复级别（热修复、临时解决方法或无修复）以及报告的信心度。环境分数主要评估成功利用所需的网络或主机修改，例如权限、用户交互、完整性、可用性和机密性。这两个附加向量有助于让我们深入了解安全问题的完整严重性和影响。

Web 应用程序的安全要求

OWASP 应用程序安全验证标准（ASVS）不仅提供了开发团队应遵循的安全要求清单，还可以作为 QA 团队进行验证和评估应用程序安全级别的检查表。请参考项目源：www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project。

OWASP 应用程序安全验证标准（ASVS）

OWASP ASVS 在撰写时（2018 年）定义了以下安全要求。由于某些章节被并入其他章节，部分章节号被跳过：

ASVS V1 架构
ASVS V2 身份验证
ASVS V3 会话管理
ASVS V4 访问控制
ASVS V5 输入验证和输出编码
ASVS V7 加密
ASVS V8 错误处理
ASVS V9 数据保护
ASVS V10 通信
ASVS V13 恶意代码
ASVS V15 业务逻辑漏洞
ASVS V16 文件和资源
ASVS V17 移动安全
ASVS V18 API
ASVS V19 配置
ASVS V20 物联网

OWASP ASVS 定义了三种安全要求等级。以V7: 静态加密为例，在一级应用程序中，可能仅要求加密模块安全地失败。对于二级/三级应用程序，其安全要求超过一级，此外还要求在应用程序中使用经批准的随机数生成器。

实际中，产品经理可能使用 ASVS 规划未来版本所需的安全特性，开发团队参考 ASVS 来正确实现安全的应用程序，而 QA 团队则将其作为检查表来评估应用程序，或作为发布门禁。定制 ASVS 检查表，并将其纳入您的安全实践，使其更加有效。例如，将安全要求基准作为产品功能规划模板的一部分，或在流程中将安全检查列为发布门禁。毕竟，我们不希望 ASVS 仅仅是一个检查表文档。它需要意识、流程和共识才能落实到实践中。

安全知识门户

您还可以考虑构建一个内部安全知识门户，包含安全要求、案例研究、指导方针或模板等。内部安全门户不仅有助于传达组织级的安全政策，还能建立内部知识库。项目团队还可以在门户上分享他们的最佳实践或工具，以增强跨业务部门的经验共享。理想的安全知识门户可能涵盖以下领域，如下图所示：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

如果您的组织是新成立的，或者正在计划建立一个内部的安全知识门户，强烈推荐使用 OWASP 安全知识框架（SKF）。OWASP SKF 提供了 OWASP ASVS 检查清单、安全知识库，以及安全代码示例。以下是下载 OWASP SKF 的 URL：github.com/blabla1337/skf-flask。

大数据安全需求

大数据的安全需求不仅包括整个大数据框架的安全，还包括数据本身的保护。保护数据不仅仅是加密。根据 CSA 大数据安全与隐私的十大挑战，大数据的安全与隐私分为四个领域：

基础设施安全
数据隐私
数据管理
完整性和响应性安全

我们将基于这四个安全类别进一步讨论安全需求。

大数据安全需求

下表列出了每个类别的安全需求示例。这不是一个详尽的清单，但这是您应该考虑的大数据安全的关键需求：

大数据安全分类	安全需求示例
基础设施安全

数据库和服务可用性
防范 DDOS 攻击和大规模数据流量
安全的数据传输，如 TLS 1.2

数据隐私

数据分类和保护
未授权访问审计与日志记录
敏感或个人信息的数据掩码
遵守隐私法或法规

数据管理

安全的数据库存储，如安全配置、加密和硬化
数据生命周期过程中的数据治理
告知用户数据如何被收集和使用
明确的用户同意收集任何个人数据
允许用户编辑、更新或删除收集的数据

完整性和响应性安全

日志安全分析以识别异常的数据访问
防止数据被篡改
当发生安全事件时通知用户

大数据技术安全框架

另一方面，如果我们深入了解大数据基础设施，我们会发现它通常包括 HDFS、Hive、HBase、Storm、Knox、Solr、Kafka、ZooKeeper 和 YARN。这些带来了新的安全挑战，比如如何保护分布式数据环境、细粒度的数据访问控制、安全存储、隐私数据保护和数据治理。从大数据安全框架的角度来看，下表列出了大数据安全需求与建议的技术控制组件的映射：

安全需求	技术实施组件

集中式安全管理和管理
授权和权限控制
集中式审计与报告

Apache Ranger
Apache Sentry

操作监控与审计

Apache Ambari

强制执行 REST API 安全
边界安全

Apache Knox

安全传输

使用 TLS v1.2 代替 HTTP
使用 SSH v2 代替 Telnet
使用 SFTP 代替 FTP

身份认证

Kerberos

安全配置和部署

Kerberos 和 Knox 安全配置，如文件权限、守护进程用户、NTP、证书和 TLS

数据治理
数据生命周期管理
数据分类，例如 PII、机密数据
基于分类的授权/数据掩码

Apache Atlas

以下是关于大数据隐私与安全的进一步推荐参考资料：

SP.1500-4 大数据互操作性框架：第 4 卷，安全与隐私
ENISA：大数据中的隐私设计
CSA 扩展的十大大数据安全与隐私挑战
信息专员办公室的数据保护指南
ENISA：大数据安全

GDPR 的隐私要求

GDPR 是欧盟关于隐私数据保护的法规，于 2018 年 5 月生效。我们需要了解并为之做好规划，因为 GDPR 定义了数据隐私的相关法规。它不仅仅是一个指南或最佳实践，GDPR 是一个必须在整个欧盟范围内遵守的正式法规。

在这里，我们将介绍一些关于 GDPR 自我评估及与软件应用相关的安全要求的关键步骤。共有四个主要步骤，如下所示：

关键步骤	检查清单

GDPR 合规性

| 如果满足以下任一条件，必须遵守 GDPR 合规性：

位于欧盟的公司
向欧盟居民提供免费或付费商品或服务的公司（不在欧盟的公司）
监控欧盟居民行为的公司（不在欧盟的公司，或不向欧盟提供商品或服务的公司）

GDPR 官网提供了许多值得阅读的资源，如“谁必须遵守”和“常见问题解答” |

隐私影响分析

| 这一步主要指的是进行隐私影响评估（PIA）。PIA 包括以下步骤：

识别 PIA 的需求
描述信息流
识别隐私及相关风险
识别和评估隐私解决方案
签署并记录 PIA 结果
与利益相关者制定行动计划

请参考这里的 PIA 评估模板。gdpr-info.eu/issues/privacy-impact-assessment/ |

数据控制者或数据处理者

根据数据控制者或数据处理者的角色执行 GDPR 合规性

验证

建议为开发团队提供一份自我评估和评估清单
或者，一个组织也可以考虑获得与隐私相关的安全认证，例如欧盟的 EuroPrise 认证或美国的 TRUSTe 认证

隐私影响评估（PIA）

PIA 的目标是对可能涉及隐私数据处理的业务模块进行初步自我评估，并准备好遵守 GDPR。数据隐私影响分析是 GDPR 第 35 条要求的内容。强烈建议为所有项目团队应用 PIA 评估模板，或者根据组织的需求定制模板。PIA 的关键成果包括隐私数据属性和数据流列表。典型的 PIA 评估报告可能包含以下议程。

介绍
PIA 的范围
数据属性识别
数据流评估
计划的行动和现有的差距
数据保护影响评估结果

以下部分展示了如何识别隐私数据以及数据流风险评估。

隐私数据属性

对于隐私数据，我们还必须进一步识别其属性。属性列表（目的、收集方式、存储、格式、保留期限等）有助于确定和审查如何处理隐私数据。例如，某些隐私数据可能被识别为不是必须收集的，或者没有合法的收集依据，这些隐私数据不应当被收集。

属性	描述相关的业务流程或应用
隐私数据类型	描述收集或处理的隐私数据，如姓名、地址、电话
收集目的	描述数据收集的目标及其业务背景
是否必须？	数据收集对保持业务应用的正常运行是否至关重要？
收集方式	个人数据如何收集，例如通过 API、电子邮件或网页表单注册
合法依据	数据收集是否基于用户协议、合同或法律合规？
数据主体的权利	数据主体是否可以编辑或删除数据？
传输方式	数据是如何传输的，如 FTP、电子邮件或 API
存储国家	数据存储在哪个国家？
存储格式	数据以何种格式存储，例如大数据、关系型数据库或纸质形式？
过期期限	数据使用是否有指定的过期期限？
跨境传输	数据是否会从欧盟传输到其他国家或地区？
第三方参与	是否有任何第三方参与数据处理？
所有者	谁/哪个团队是数据的所有者？

数据流评估示例

下图展示了客户、服务和研发团队之间典型的数据流问题排查。对于数据流，必须识别是否包含任何隐私数据、数据处理操作以及数据处理的目标：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

该表描述了在相关业务场景中处理数据隐私的操作，表格中标明了场景：

#	业务场景	数据隐私	操作	目标
1	客户将其 PC 发送到客服中心进行修复	客户的联系信息和个人数据存储在 PC 上	客服中心接收 PC	初步测试 PC 的功能
2	PC 送交工程团队进行进一步检查	客户联系信息和个人数据存储在 PC 上	工程团队进行更深入的分析	提供 PC 的工程修复

GDPR 对于数据处理者和控制者的安全要求

根据 GDPR 常见问题解答，控制者是确定个人数据处理目的、条件和方式的实体，而处理者是代表控制者处理个人数据的实体。

例如，一个向欧盟客户（数据主体）销售服务的电子商务网站。该电子商务网站是数据控制者，应遵守 GDPR 要求。作为数据处理者的软件供应商为该电子商务网站提供软件服务。

与数据处理者相比，数据控制者需要满足更多的 GDPR 要求。这就是为什么在隐私数据处理生命周期中，明确其角色至关重要。下表列出了软件/服务在数据处理者和数据控制者方面的 GDPR 安全要求。

GDPR 要求	数据处理者	数据控制者
提供数据隐私声明	必须	必须
数据收集必须获得用户明确同意，并允许用户禁用数据收集	必须	必须
为了故障排除，必须通知用户日志收集是否包含个人信息	必须	必须
收集用户的 Cookies 需要用户的同意	必须	必须
如果数据是为了营销分析目的而收集，应用程序必须允许用户禁用分析	推荐	必须
在数据过期后提供安全的数据删除功能	必须	必须
如果数据将提供给第三方合作伙伴，必须获得用户的明确同意	推荐	必须
提供用户查询和更新数据的功能	推荐	必须
删除任何不再使用的临时数据	推荐	必须
提供导出数据的功能	推荐	必须
安全数据传输	必须	必须
使用加密、访问控制和日志记录安全控制的安全本地数据存储	必须	必须

总结

我们讨论了四个领域的安全要求，并提供了如何为每个开发阶段定义安全发布门的示例，如设计、编码、构建、测试、交付和监控。每当遇到是否进行下一次发布的难题时，建议进行 CVSS 评估。

为了让产品经理规划安全功能，我们推荐使用 OWASP ASVS。根据业务场景，安全有三个等级。基于 OWASP ASVS，我们引入了一个开源的 OWASP 安全知识框架，帮助组织建立内部安全知识门户。

关于数据安全与隐私，我们讨论了大数据的安全要求。

对于大数据需求，CSA 定义了四个安全类别：如基础设施安全、数据隐私、数据管理与完整性，以及响应性安全。此外，我们还提供了建议的大数据安全框架列表，如 Apache Ranger 和 Atlas。还建议进一步阅读 NIST SP 1500-4 和 ENISA 大数据安全相关内容。

最后，我们讨论了 GDPR 的安全要求。根据数据控制者或数据处理者的角色，安全要求可能会有所不同。我们还回顾了一个示例，看看如何使用 PIA 模板作为 GDPR 的自我评估。

我们讨论了与行业实践（OWASP ASVS，CSA 大数据）、工具（OWASP SKF，Apache Ranger）和模板（CVSS，PIA）相关的安全要求。在下一章中，我们将通过案例研究来探讨在 DevOps 过程中如何执行安全实践。

问题

以下哪项可以作为设计阶段发布门的安全要求？
1. 应执行威胁建模活动
2. 审查第三方组件的使用
3. 审查常见的安全设计问题
4. 以上所有
以下哪项不是编码阶段的安全门？
1. 源代码已由静态代码分析工具扫描
2. 源代码中未发现敏感信息
3. 服务日志已准备好进行安全分析
4. 代码扫描结果中的高严重性问题已全部检查
CVSS 是否代表常见漏洞评分系统？
以下哪种技术通常用于为大数据框架进行授权？
1. Apache Ranger
2. Apache Ambari
3. TLS
4. NTP
GDPR 是否适用于那些不位于欧盟的组织，正确还是错误？
数据控制者和数据处理者之间的主要区别是否是决定数据处理目的的能力？

进一步阅读

访问以下网址以获取更多信息：

NIST 1500-4 大数据互操作性框架：安全与隐私：bigdatawg.nist.gov/_uploadfiles/NIST.SP.1500-4.pdf
ENISA 大数据隐私设计：www.enisa.europa.eu/publications/big-data-protection
SAFE 实践安全故事与敏捷开发环境中的安全任务：safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf
大数据、人工智能、机器学习与数据保护： ico.org.uk/media/for-organisations/documents/2013559/big-data-ai-ml-and-data-protection.pdf
PCI DSS 3.2 的优先级方法： www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI_DSS-v3_2.pdf
安全与隐私的开放参考架构：security-and-privacy-reference-architecture.readthedocs.io/en/latest/
IT 产品国家清单计划 – 清单用户与开发者指南： nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-70r3.pdf
CSA 扩展十大大数据安全与隐私挑战： cloudsecurityalliance.org/download/expanded-top-ten-big-data-security-and-privacy-challenges/
信息专员办公室《数据保护指南》： ico.org.uk/for-organisations/guide-to-data-protection/
SANS 网络应用设计安全清单： www.sans.org/reading-room/whitepapers/securecode/security-checklist-web-application-design-1389
GDPR 谁需要遵守： www.gdpreu.org/the-regulation/who-must-comply/
GDPR 常见问题解答： www.eugdpr.org/gdpr-faqs.html
GDPR 隐私影响评估： gdpr-info.eu/issues/privacy-impact-assessment/
Cookie 法律： www.cookielaw.org/the-cookie-law/
ISO/IEC 29151:2017 个人身份信息保护实践规范： www.iso.org/standard/62726.html

第五章：案例研究 - 安全保障计划

由于我们在前几章已经涵盖了安全要求和安全保障计划，本章将讨论两个案例，重点查看 DevOps 过程中的安全保障计划和安全实践。微软 SDL 和 SAMM 被引入用于应用安全保障计划。除了过程之外，非技术性部分，如安全培训和文化，对于安全计划的成功也至关重要。我们还将举例说明安全工具和 Web 安全框架如何在整个 DevOps 过程中提供帮助。

在本章中，我们将学习以下主题：

微软 SDL 和 SAMM
安全培训和意识
安全文化
将安全工具融入 DevOps
Web 安全框架

安全保障计划案例研究

让我们通过两个典型的业务场景来讨论安全保障计划的采用。一个是关于建立在第三方云服务提供商之上的服务，另一个是关于构建自己的完整云服务，包括软件即服务（SaaS）、平台即服务（PaaS）和基础设施即服务（IaaS）：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

**场景 1：Joyce，基于公共云服务的电子商务服务：**Joyce 是电子商务公司的一名安全领导。该公司拥有内部的软件开发、IT 和安全团队。他们部署了基于第三方云服务提供商的电子商务服务，并采用 IaaS/PaaS 云服务提供商提供的大部分安全服务。由于涉及支付和信用卡信息处理，电子商务服务必须遵守 PCI DSS 合规性。
**场景 2：John，基于自建云服务的电子商务服务：**John 是电子商务服务的首席安全官。John 案例中的关键区别在于，存在一个成熟的安全组织团队，并且有很多安全服务，如 WAF、IDS 或安全监控，都是自行构建并根据业务需求定制的。此外，电子商务是建立在他们自运营的云服务之上的。在这种情况下，PCI DSS 合规性也是最低要求。

对于这两个场景，让我们通过参考微软 SDL 和 OWASP SAMM 实践，讨论采用安全保障计划的差异。

微软 SDL 和 SAMM

在 Joyce 的案例中，采用微软 SDL 和 SAMM 可能在云服务提供商提供的框架基础上应用安全性。我们始终建议基于现有的业务流程构建安全实践，或者将安全工具集成到现有的 CI 或 CD 框架中。

大多数云服务提供商提供相关的云安全服务。在 Joyce 的案例中，熟悉云服务提供商提供的安全服务，以及这些服务如何应用到她的电子商务应用程序中，将有助于构建安全基础。此外，大多数云服务提供商已获得 IaaS 和 PaaS 的安全标准认证。这意味着 Joyce 只需关注构建在 IaaS 和 PaaS 上的数据和软件安全。而在 John 的案例中，他需要自行构建或购买这些安全服务来保护 IaaS、PaaS 和软件应用程序。下表展示了云服务提供商提供的典型安全服务：

安全领域	云安全服务
安全管理

威胁情报
云连接器
外包安全服务

内容安全

垃圾邮件防护
防止机器暴力攻击
账户滥用检测

基础设施

CA 证书管理器
密钥管理
HTTPS 服务
安全配置监控与检查

数据保护

加密
数据库审计
完整性监控
精细化访问控制

网络

HTTPS 服务
Web 应用防火墙
防 DDOS 服务

在第三方云服务之上构建软件应用程序可能会减少保护云基础设施和平台的工作量。由于 Joyce 的业务需要符合 PCI DSS，因此还建议根据业务需求推荐相应的安全实践。以下是 Joyce 可能计划的安全实践示例：

安全领域	Joyce 案例中的安全活动示例
策略与度量

根据 PCI 合规性等级定义发布门槛

策略与合规

符合 PCI DSS

教育

团队的安全培训和考试

安全要求

安全要求可能基于 PCI DSS 的六个类别
安全的网络和系统
保护持卡人数据
漏洞管理程序
强大的访问控制措施
监控和测试网络
维护信息安全政策

威胁评估

威胁评估专注于软件应用程序

安全架构

评估应用程序级组件中使用的外部依赖关系

设计审查

与外部供应商的安全 API 接口
安全的数据存储与传输

实施审查

采用安全编码扫描工具，如 flawfinder、FindSecbugs、OWASP 依赖检查。
Web 服务实现基于 Java 安全框架和 Apache Shiro，负责身份验证、授权、加密和会话管理。

安全测试

应用云服务提供商提供的安全扫描服务，如安全配置扫描、Web 服务安全或漏洞扫描

问题管理

云服务提供安全事件监控或警报，但乔伊斯仍然需要为公司建立一个安全事件处理流程。

环境加固

云服务可能提供机制来保障配置安全，并自动应用最新的补丁。

运维赋能

使用云服务提供商提供的服务监控工具；此外，将运维团队和开发团队聚集在一起处理客户反馈的问题，是这里最重要的事情。

在约翰的案例中，安全保障计划的覆盖范围扩展到云平台和基础设施。这意味着约翰还需要额外考虑这些安全控制：安全测试、问题管理、环境加固和运维赋能。其他方面，如策略、政策、教育、威胁评估、安全架构、设计审查和实施审查，将与乔伊斯的案例类似。

自建还是购买？这是每当我们规划安全实践工具时可能提出的问题。使用商业产品的一个主要优势是能够赢得客户的信任。这就像是服务通过第三方商业工具的测试和认证。另一方面，自建的安全工具能够与现有框架更紧密地集成，并可以根据需求进行定制。如果因为预算限制而陷入这种困境，使用开源工具可能是一个不错的替代方案。开源工具可能提供内置的安全规则和知识，同时也能让你灵活地根据需要进行定制。

安全培训与意识

在约翰和乔伊斯的案例中，安全意识的主题可能集中在 PCI DSS 合规性上。有很多方式可以提供安全培训，如海报、通讯、电子学习或远程会议、面对面的工作坊，或是动手实践教程。NIST SP 800-50 构建信息技术安全意识与培训计划 和 PCI DSS 实施安全意识计划的最佳实践 是构建安全意识计划的两个很好的参考资料。在这里，我们讨论在组织内实施安全意识与培训计划时需要考虑的一些关键点。

发送新闻简报被认为是针对所有业务单元员工的最具成本效益和常见的做法之一。更有效的方式是查看与该角色或业务相关的实际案例或案例研究。例如，人力资源部门可能更感兴趣的是关于与访问控制相关的就业故事或每个职位等级所需的安全知识证书的案例研究，而不是关于安全技术或威胁介绍的内容。尝试使用特定于每个角色的案例研究，如人力资源、开发人员、测试人员或运营团队，来解释安全如何与他们的工作相关并影响他们。此外，新闻简报与其他邮件并无不同，可能会很容易被忽视。建议进行简单的在线问卷调查跟进或要求回复带有评论的邮件。对于经理、领导者和特定角色，安全意识的目的是赢得他们的支持。内容不仅需要提高安全意识，还需要呼吁他们采取行动。有时，这不仅仅是单向的信息传递；它可以是一个论坛讨论或寻求共识以实现安全目标的过程。尽可能的话，推荐为这一群体进行面对面的沟通或论坛讨论。

对于开发或运营团队来说，应用安全实践的最有效方式仍然是进行动手教程和研讨会。工程师喜欢构建并参与动手练习。面对面的动手练习需要时间并且需要身体参与。然而，它们比海报、新闻简报、在线学习或电话会议要有效得多。

对于大型的、地理分布广泛的组织，通常会有在线自学的电子学习课程。这些电子学习课程有考试，并要求达到一定的及格分数。一些组织可能要求你每年通过安全知识认证。对于任何新的安全合规要求（如 GDPR）的采用，将安全实践融入现有流程或培训项目仍然是推荐的方法。

安全文化

组织文化可能会影响安全实践和执行。文化这个词可能相当模糊，但一般来说，有两种类型的安全文化。一种是严格流程类型，另一种是赋能团队类型。在严格流程中，几乎没有灵活性。一旦定义了预期的安全基线，它们就是强制性的。为每个项目定义了详细的安全检查清单，必须遵循。任何违规行为都是不允许的。另一方面，赋能团队类型意味着组织只定义一般的安全指南，而项目团队可以根据项目需求制定自己的安全检查清单。

严格的流程文化适用于需要高级控制的环境，例如军事或银行领域。每个安全控制都有明确的标准操作程序（SOPs）和检查清单。SOP 或检查清单将大大减少人为错误的可能性。此外，任何未能符合安全检查清单的例外情况，都需要团队提交正式的审查。从安全管理的角度来看，这可能减少了与每个项目团队进行检查的需求，因为项目团队需要为未满足的任何安全要求发起正式审查。项目团队几乎没有判断的空间，这些判断必须由安全管理团队做出。一个缺点是，项目团队成员可能仅仅遵循 SOP，而不知道检查清单背后的理由。

在一种赋能团队的文化中，安全管理仅定义指导方针，而每个项目团队可以根据项目需求制定检查清单。这里提到的检查清单是为开发团队设计的软件安全需求功能。这也意味着，组织层面的安全政策只定义了一些强制性的要求，没有详细的指导，并允许团队自行摸索如何实现这些要求。刚开始时，每个项目可能需要花费一些时间，并且新成立的团队可能会经历一些试错，但项目团队将从错误中吸取教训，这些错误可能仍会在测试阶段被发现，而不是设计阶段。毕竟，犯错和尝试不同的执行方法是创新和创造力的根源。

此外，团队可以根据自身的培训需求做出决定，而不是由安全管理团队定义强制性的课程列表。同样，团队决定的安全培训可能不够全面，但团队会通过经验学习。

这两种文化之间没有绝对的对错，关键取决于业务状况、合规需求、组织文化、现有流程等。一些组织可能有非常严格的安全程序，定义了具体的角色，但在其他角色上可能比较灵活。有些组织可能仍然为每个业务单元制定详细的安全检查清单，但允许每个项目团队判断是否严格遵循它。最终，融入组织文化并与业务目标对齐，是安全保障程序成功的关键。

Web 安全框架

应用成熟的 Web 安全框架将帮助开发人员减少大量为了满足安全要求所需的设计和编码工作，因为 Web 安全框架本身提供了必要的安全控制，如身份验证、授权、日志记录、验证、加密和会话管理。要构建 Web 服务，以下是一些流行的、采用 Apache 2.0 许可的开源 Java 安全框架：

Spring Security
Apache Shiro
PicketLink
对象访问控制 (OACC) 框架

一些大型组织可能倾向于为每个项目构建或定制一个网页安全框架。无论使用什么安全框架，通常都包括以下通用的安全模块。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

一个组织级别的安全保障计划可能会建议一份成熟的安全框架清单，甚至为项目团队提供一个通用框架。毕竟，一个有效的安全框架远比一堆安全需求文档更有效。

将安全性嵌入 DevOps

我们已经讨论了安全如何融入组织的文化方面。现在，让我们讨论技术方面。当涉及到将安全性融入 DevOps 时，我们大多是在谈论与现有的 持续集成 (CI) 或 持续交付 (CD) 框架的集成。CI/CD 框架有多种类型。我们可能会重点讨论如何与 Jenkins 集成安全性，因为 Jenkins 是整个 CI/CD 生态系统的中心，涉及代码与提交、构建、扫描与测试、发布和部署等环节。下图展示了带有安全工具集成的典型 CI/CD 过程。请注意，安全需求、威胁建模、安全设计和架构设计并不在图中，因为这些活动的安全实践通常与团队流程相关，而不是与像 Jenkins 这样的工具直接相关。

在 Joyce 的案例中，她可能会根据云服务提供商提供的框架来构建安全性。在 John 的案例中，他则根据现有的内部 CI/CD 框架来构建安全性。无论采用哪种方法，CI/CD 过程中的安全性都会类似于下图中的某个示例：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

带安全工具的 CI/CD 过程

避免重复造轮子，并将安全性融入现有的流程或框架，是任何阶段安全保障计划的关键成功因素。安全需求清单有助于我们了解所需的内容。此外，工具集和框架可以帮助实施产品的安全性。下表展示了工具和框架如何在 DevOps 中支持安全性的另一个示例：

安全工具类型	DevOps 中的关键活动	工具和框架示例
安全框架	架构设计

Shiro
Spring Security

安全编码	实施与编码

FindSecBugs 用于 Java 代码扫描
Java HTML 清理工具

安全测试	验证

Kali Linux 工具包

安全监控	操作监控

安全洋葱（IDS/IPS、安全监控和日志分析）
OpenSCAP

总结

本章中，我们讨论了两种典型的安全保障计划业务场景。一种是在第三方云服务提供商的基础上构建软件，另一种是在自己的云上构建完整的云服务。云服务提供商可能会提供安全服务来保护平台和基础设施，但仍然是云服务租户的责任来保护云中的 Web 应用程序和客户数据。接着，我们讨论了 Microsoft SDL 和 SAMM 在不同开发和运维阶段中安全活动的采纳。关于安全培训，我们建议根据角色和需求进行培训。我们还讨论了安全文化如何影响安全保障计划。

最后，我们以安全工具与 CI/CD 集成和 Web 安全框架的采用为例，解释了工具和框架如何对任何安全计划的成功至关重要。在接下来的章节中，我们将进一步探讨如何构建安全架构、常见模块和设计原则。

问题

云服务提供商是否承担所有安全责任，包括软件应用程序和客户数据？
云服务提供商提供哪些安全服务？
1. 数据加密
2. 安全监控
3. 防止 DDoS
4. 以上全部
提高安全意识的最具成本效益的方式是什么？
1. 时事通讯
2. 研讨会
3. 电话会议
4. 教程
CI 是否代表持续集成？
CD 是否代表持续交付和持续开发？
哪些活动被认为是在 CI 循环内？
1. 代码
2. 提交
3. 构建
4. 测试
FindSecBugs 工具用于哪些类型的安全实践？
1. 安全代码扫描
2. 安全监控
3. 入侵防御
4. 认证
以下哪项不是 Java Web 安全框架？
1. 护照
2. Spring 安全
3. Apache Shiro
4. PicketLink

进一步阅读

PCI DSS: www.pcisecuritystandards.org/pci_security/
Microsoft SDL: www.microsoft.com/en-us/sdl
SAMM: www.owasp.org/index.php/OWASP_SAMM_Project
flawfinder: www.dwheeler.com/flawfinder/
FindSecbugs: find-sec-bugs.github.io/
OWASP 依赖检查: www.owasp.org/index.php/OWASP_Dependency_Check
NIST SP 800-50 构建信息技术安全意识和培训计划: nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-50.pdf
实施安全意识计划的最佳实践: www.pcisecuritystandards.org/documents/PCI_DSS_V1.0_Best_Practices_for_Implementing_Security_Awareness_Program.pdf
Spring Security: projects.spring.io/spring-security/
Apache Shiro: shiro.apache.org/
PicketLink: picketlink.org/
OACC（对象访问控制）框架: oaccframework.org/
静态安全分析 github.com/mre/awesome-static-analysis/