DevOps-安全实用指南-全-

DevOps 安全实用指南（全）

原文：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）：

要查找特定产品或供应商的漏洞，请参考以下 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 实践。在接下来的章节中，我们将进一步讨论安全目标、度量标准和安全保障计划如何适用于不同类型的组织和实践。

问题

  1. FIPS 是否定义了加密的安全要求？

  2. 以下哪个选项定义了主要关注个人数据隐私的安全合规性？

    1. ISO 27018

    2. FIPS

    3. GDPR

    4. CIS

  3. 什么可以被视为云服务滥用？

    1. 账户共享

    2. 暴力破解登录

    3. API 滥用

    4. 以上所有

  4. CIS 安全基准的用途是什么？

    1. 防病毒

    2. 定义操作系统、平台、数据库等的安全配置

    3. 防火墙

    4. 完整性

  5. 在 DevOps 周期中，哪个角色涉及安全实践？

    1. QA

    2. RD

    3. 运维

    4. 以上所有

  6. 基础设施即代码（IaC）如何帮助安全运维团队？

    1. 病毒检测

    2. 安全配置

    3. 入侵检测

    4. 加密

  7. 以下哪个不是隐私原则？

    1. 欺骗

    2. 目的限制

    3. 存储限制

    4. 准确性

进一步阅读

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

第二章：安全目标和度量

在前一章中，我们讨论了 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 和 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 最危险的软件错误。同时，项目团队也可以基于历史记录或客户反馈，制定自己的顶级安全问题：

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

实施审查

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

  • 安全编码

  • 选择可靠且安全的第三方组件

  • 安全配置

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

第三方组件

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

  • 第三方软件评估检查表：

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

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

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

  • 第三方组件的 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 编码标准是很好的参考。如果需要其他代码审查过程的技巧，请参阅第八章，安全编码最佳实践。

安全测试

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

  • 安全发布标准：

发布标准定义了质量发布门的最低要求。它们可以帮助业务利益相关者就何时发布软件达成共识。拥有这样的基准将有助于减少开发、质量保证和 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 团队。我们举了应用程序通信端口矩阵和配置清单等例子，并分析了安全事件的根本原因。

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

问题

  1. OWASP SAMM 是否代表软件保障成熟度模型？

  2. 以下哪些是在 OWASP 安全治理中定义的？

    1. 策略与指标

    2. 政策与合规性

    3. 教育与指导

    4. 以上所有

  3. 根据 OWASP SAMM，在构建阶段应考虑哪些事项？

    1. 安全架构

    2. 威胁评估

    3. 安全需求

    4. 以上所有

  4. 以下哪项不是威胁建模的工具或技术？

    1. CAPEC

    2. ATT&CK

    3. OWASP Cornucopia

    4. GDPR

  5. 在 GDPR 中，我们可以应用哪些安全实践进行隐私评估？

    1. PIA 隐私影响分析

    2. 渗透测试

    3. 问题管理

    4. ISO 27001

进一步阅读

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

本章将讨论安全保障程序，如安全开发生命周期（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 或入侵检测，而不是购买安全服务，以更好地适应业务需求。在第五阶段，团队使用大数据分析来防范未知威胁。

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

问题

  1. Microsoft SDL 是否代表安全开发生命周期？

  2. 根据 SDL，设计阶段应进行哪些活动？

    1. 确定设计要求

    2. 执行攻击面分析减少

    3. 用户威胁建模

    4. 以上所有

  3. 在 OWASP SAMM 中，哪个安全实践不属于安全治理的一部分？

    1. 安全与指标

    2. 教育和指导

    3. 安全架构

    4. 政策与合规

  4. 在 OWASP SAMM 中，哪个安全实践不属于安全操作的一部分？

    1. 问题管理

    2. 安全需求

    3. 环境强化

    4. 操作启用

  5. 以下哪项不是 CTO 领导下的安全办公室的特点？

    1. 大型安全团队——超过 100 名成员

    2. 没有专职 CSO

    3. 安全团队服务所有项目

    4. 安全团队可能无法完全参与项目团队

深入阅读

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

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

本章将讨论涵盖四个方面的安全需求：每个发布质量门的安全要求，通用 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)：攻击仅影响脆弱组件，还是会影响所有其他组件及整个系统？

  • 机密性 (C)：是否会有机密信息被窃取？

  • 完整性 (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 自我评估及与软件应用相关的安全要求的关键步骤。共有四个主要步骤，如下所示：

关键步骤 检查清单

|

  1. GDPR 合规性

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

  • 位于欧盟的公司

  • 向欧盟居民提供免费或付费商品或服务的公司（不在欧盟的公司）

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

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

|

  1. 隐私影响分析

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

  1. 识别 PIA 的需求

  2. 描述信息流

  3. 识别隐私及相关风险

  4. 识别和评估隐私解决方案

  5. 签署并记录 PIA 结果

  6. 与利益相关者制定行动计划

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

|

  1. 数据控制者或数据处理者

|

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

|

|

  1. 验证

|

  • 建议为开发团队提供一份自我评估和评估清单

  • 或者，一个组织也可以考虑获得与隐私相关的安全认证，例如欧盟的 EuroPrise 认证或美国的 TRUSTe 认证

|

隐私影响评估（PIA）

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

  1. 介绍

  2. PIA 的范围

  3. 数据属性识别

  4. 数据流评估

  5. 计划的行动和现有的差距

  6. 数据保护影响评估结果

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

隐私数据属性

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

属性 描述相关的业务流程或应用
隐私数据类型 描述收集或处理的隐私数据，如姓名、地址、电话
收集目的 描述数据收集的目标及其业务背景
是否必须？ 数据收集对保持业务应用的正常运行是否至关重要？
收集方式 个人数据如何收集，例如通过 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. 以下哪项可以作为设计阶段发布门的安全要求？

    1. 应执行威胁建模活动

    2. 审查第三方组件的使用

    3. 审查常见的安全设计问题

    4. 以上所有

  2. 以下哪项不是编码阶段的安全门？

    1. 源代码已由静态代码分析工具扫描

    2. 源代码中未发现敏感信息

    3. 服务日志已准备好进行安全分析

    4. 代码扫描结果中的高严重性问题已全部检查

  3. CVSS 是否代表常见漏洞评分系统？

  4. 以下哪种技术通常用于为大数据框架进行授权？

    1. Apache Ranger

    2. Apache Ambari

    3. TLS

    4. NTP

  5. GDPR 是否适用于那些不位于欧盟的组织，正确还是错误？

  6. 数据控制者和数据处理者之间的主要区别是否是决定数据处理目的的能力？

进一步阅读

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

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

由于我们在前几章已经涵盖了安全要求和安全保障计划，本章将讨论两个案例，重点查看 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. 云服务提供商提供哪些安全服务？

    1. 数据加密

    2. 安全监控

    3. 防止 DDoS

    4. 以上全部

  3. 提高安全意识的最具成本效益的方式是什么？

    1. 时事通讯

    2. 研讨会

    3. 电话会议

    4. 教程

  4. CI 是否代表持续集成？

  5. CD 是否代表持续交付和持续开发？

  6. 哪些活动被认为是在 CI 循环内？

    1. 代码

    2. 提交

    3. 构建

    4. 测试

  7. FindSecBugs 工具用于哪些类型的安全实践？

    1. 安全代码扫描

    2. 安全监控

    3. 入侵防御

    4. 认证

  8. 以下哪项不是 Java Web 安全框架？

    1. 护照

    2. Spring 安全

    3. Apache Shiro

    4. PicketLink

进一步阅读

第六章：安全架构与设计原则

安全管理，包括其目标、安全保障计划和安全要求，在前面的章节中已有解释。本章将讨论安全架构和设计原则。对于安全架构师和开发人员来说，基于成熟的安全框架构建软件将大大降低安全风险，同时遵循行业最佳实践，也能减少实现过程中的工作量。因此，本章介绍了云服务架构的关键安全元素和一些成熟的安全框架，依据具体场景进行应用。我们还将在本章讨论 GDPR 和数据保护技术。

本章将涵盖以下主题：

  • 安全架构设计原则

  • 云服务安全架构参考（ESAPI）

  • 安全框架（Shiro、加密、验证、数据屏蔽）

  • GDPR 和数据治理

安全架构设计原则

在本节中，我们将讨论两个关键概念，即安全设计和隐私设计。当我们讨论安全时，更侧重于整个系统的安全控制，如身份验证、授权、可用性、问责性、完整性和保密性。隐私则特别关注隐私数据或个人身份信息（PII）。隐私保护专注于授权的数据处理生命周期和治理。

如果我们以一般术语对一些安全控制进行分类，你可能会发现一些差异，尽管在安全和隐私方面有一些重叠区域：

安全设计 隐私设计
主要关注点 未经授权的系统访问。 授权的隐私数据处理过程。

| 原则 | 根据 OWASP，安全设计原则如下：

  • 最小化攻击面

  • 建立安全默认值

  • 最小权限原则

  • 深度防御原则

  • 安全失败

  • 不信任服务

  • 职责分离

  • 避免通过模糊性来保障安全

  • 保持安全简单

  • 正确修复安全问题

| 参考 OECD 隐私原则，隐私设计一词由八项原则定义：

  • 收集限制原则

  • 数据质量原则

  • 目的规定原则

  • 使用限制原则

  • 安全保障原则

  • 开放性原则

  • 个人参与原则

  • 问责原则

|

控制示例

  • 访问控制

  • 登录失败尝试

  • 会话控制

  • 时间戳

  • 不可否认性

  • 配置变更控制

  • 审计安全事件

  • 加密模块

  • 事件监控

  • 错误处理

|

  • Cookie

  • 匿名性

  • 同意

  • 混淆

  • 限制

  • 通知与告知

  • 身份验证

  • 最小化

  • 分离

  • 加密

  • 数据屏蔽

|

以下行业参考资料可以帮助你构建一个安全的架构：

我们已经理解了安全与隐私的概念和原则。然而，大多数组织面临的挑战是如何将这些原则融入到应用程序或服务中。因此，我们将在接下来的章节中讨论一些设计模式以及开源框架的实现。

云服务安全架构参考

开放安全架构（OSA）模式 SP-011：云计算模式 和 SP-008：公共 Web 服务器模式 提供了整个系统的概览图。此外，SP-001：客户端模块 和 SP-002：服务器模块 也是很好的参考。请查看以下链接中的云计算模式组件：www.opensecurityarchitecture.org/cms/library/patternlandscape/251-pattern-cloud-computing

此外，如果你在寻找用于自我评估或合作伙伴安全评估的问卷或检查表，以下是一些推荐的参考资料。CSA CAIQ 汇总了大多数安全标准（包括 ISO 27001、FedRAMP、NIST 800-53 R3 和 PCI DSS）形成一个自我评估问卷。VSAQ 主要用于外部供应商评估，涵盖了网络应用安全、安全与隐私程序、基础设施安全以及物理和数据中心安全方面。

安全框架

架构原则可能对大多数开发人员来说仍然过于抽象。因此，在本节中，我们将讨论一些关键的开源安全框架。根据安全目标和编程语言的不同，存在各种类型的开源安全框架。我们将在这里讨论一些主要或广泛使用的安全框架。

采用安全框架是实现 安全设计 的最佳方法。一个成熟的安全框架提供如身份认证、访问控制、会话管理、HTTP 安全、加密和日志记录等安全控制功能。它还使得一个对安全知识了解较少的初级开发人员也能够构建安全的软件。

只需记住，我们将介绍的安全框架是与我们的应用程序集成的第三方安全组件。像杀毒软件、Web 应用防火墙和入侵检测等安全应用程序将不在本节讨论范围内，稍后章节中会详细讨论。

Java Web 安全框架

如前所述，采用 Web 安全框架将帮助我们处理大量的安全控制。以 Spring Security 为例，编辑 XML 配置不仅能提供登录/登出表单认证，还能提供 CSRF 攻击防护、会话管理以及 HTTP 安全头（HSTS、X-content-type、XSS、X-Frame-Options）保护：

Java 安全框架 关键特性
Spring Security
  • Spring Security 框架仅适用于基于 Java 和 Spring 的应用程序。它提供了许多开箱即用的安全控制功能，如用户身份认证、CSRF 攻击防护、会话固定保护、HTTP 安全头和 URL 访问控制。此外，它还支持多种身份认证方式，如 Oauth2.0、CAS 和 OpenID。

|

Shiro
  • 与 Spring Security 相比，Shiro 是一个更轻量级、更简单的框架。Shiro 和 Spring Security 之间的主要区别在于，Shiro 不需要基于 Spring 的应用程序，它可以独立运行，无需与任何 Web 框架或非 Web 环境相结合。

|

对象访问控制 (OACC)

  • OACC 主要提供身份认证和授权。OACC 的关键特点是，它提供了与应用程序资源的安全关系，而 Spring Security 则通过 URL、方法和角色来定义授权。

  • 在 OACC 中，安全关系的示例定义可能是：（Sara）对（TimeSheet.xls）拥有（读取、编辑）权限。能够在安全关系中建立应用程序资源（TimeSheet.xls）是 OACC 中独特的授权模型。

|

对于 Java 开发团队，推荐使用哪种框架？如果网站完全基于 Java Spring 构建，Spring Security 仍然是最佳选择，因为它具有强大的安全特性和完整的技术文档。然而，如果你的 Web 应用程序运行在非 Web 或非 Spring 的应用环境中，推荐使用 Shiro。如果你的应用可能需要资源访问控制模型，尝试使用 OACC。

非 Java 网络安全框架

对于非 Java 编程，以下是一些建议：

编程语言 身份验证框架
Node.JS
  • Passport 框架是一个用于 Node.JS 的身份验证模块。

|

Ruby on Rails
  • Devise Security：这是一个用于 Ruby 的安全模块。它提供了密码复杂性、验证码、用户账户不活跃检查、验证码和会话控制等安全功能。

|

ASP.NET
  • ASP.NET Core 提供了身份验证、授权、防 XSS、SSL 强制、反请求伪造、加密等安全功能，并支持 GDPR 的 API。

|

Python

  • Yosai 是一个 Python 应用程序的安全框架

  • Flask Security：它为 Flask 应用程序提供了常见的安全控制，如身份验证、密码哈希和角色管理。

|

网络隐私保护准备情况

要评估网站的隐私保护准备情况，不仅需要考虑一般的网络安全控制，还需关注以下几个主要领域：

  • TLS 安全数据传输：TLS 配置错误可能导致数据传输不安全或遭遇中间人攻击。

  • Referrer Policy：Referrer Policy 定义了浏览器应如何处理 Referrer 信息，该信息揭示了用户原始访问的网站。网站访问历史也被认为是个人隐私信息。

  • Cookie 同意声明：为遵守 GDPR，收集 cookie 信息和使用任何第三方 cookie 都需要明确的 cookie 同意。

  • HTTP 安全头：HTTP 协议本身提供了网络安全控制。请参考以下表格，了解建议的 HTTP 安全头配置。

以下表格总结了隐私安全要求的技术部分以及评估和构建网站的建议工具：

隐私技术要求 工具
安全通信：默认使用 HTTPS 并安全配置 TLS。
  • Pentest Box 或 Kali Linux 中包含 SSLyze、SSLScan 和 TestSSLServer

|

访问网站的来源不应通过 referer 头信息泄露给其他网站。

  • Referrer Policy 定义了如何使用 referer 信息。Referrer Policy 的配置取决于具体要求。

  • no-referrer 将确保浏览器从不发送 referer 头信息。

  • 如果需要发送此信息，建议使用‘strict-origin’配置通过 HTTPS 发送信息。

|

如果使用 Google Analytics，请启用隐私扩展来匿名化 IP。
  • 为 Google Analytics 启用 IP 屏蔽

|

第三方 Cookies 或嵌入式服务（如 Google Analytics），需用户同意。

|

| HTTP 安全头 | 以下是推荐的强制性安全 HTTP 头示例。

  • 内容安全策略（CSP）   "default-src 'self' "

  • Referrer-Policy    "no-referrer"

  • Strict-Transport-Security   "max-age=31536000"

  • X-content-Type-options    "nosniff"

  • X-Frame-Options    "SAMEORGIN"

  • X-Xss-Protection    "1;mode=block"

  • Cookie                                  "Secure"

参阅 OWASP 安全头项目，了解每个安全头的定义。 |

还建议为您的网站构建内部隐私扫描工具。以下资源提供了符合隐私要求的在线扫描服务：

隐私评分评估：privacyscore.org.

登录保护

登录保护可以视为应用程序的第一道防线。黑客可能使用工具或 API 进行暴力破解登录攻击。CAPTCHA 是区分人类与机器输入的方式之一。CAPTCHA 要求客户端完成视觉感知任务。然而，CAPTCHA 可能会被 OCR 或无意的人力所破解。除了 CAPTCHA 之外，我们还可以增加另一层安全防护来监控登录失败次数。如果登录失败次数达到某一阈值，系统应采取措施，如禁止 IP 来源：

登录保护的工具/模块总结在下表中：

登录保护技术 工具/模块
检测日志中登录失败的次数并采取措施
  • Fail2Ban

|

CAPTCHA 解决方案，防止机器暴力破解登录攻击

  • 使用 VisualCaptcha 构建自己的 CAPTCHA 服务

  • Google reCAPTCHA

|

加密模块

加密模块的典型使用案例不仅仅是数据加密/解密，还包括 SSL/TLS 安全通信、密钥交换、X509 证书处理、消息完整性的一-way 哈希以及随机数生成。开发团队可能需要的推荐加密模块如下：

加密模块 应用场景
OpenSSL
  • 功能全面且最广泛使用的加密和 SSL/TLS 工具包

|

Bouncy Castle Crypto APIs
  • 轻量级加密 Java API

|

mbed TLS

  • OpenSSL 替代品

  • 嵌入式产品中的加密与 SSL/TLS

  • 加密 C API

|

SSLyze
  • 验证 Web 服务器的安全 TLS 配置

|

此外，运营团队可能更关心的是服务器上的加密配置，例如 Web 服务器、SSH、邮件、VPN、数据库、代理和 Kerberos 等。

参见《应用加密强化》：betterCrypto.org/static/applied-crypto-hardening.pdf。

输入验证和数据清洗

输入验证就像是整个应用程序的外围安全控制。输入不仅包括用户的数据输入，还包括函数调用、方法、API 或系统之间传递的参数。验证的概念涵盖了各种技术方法：

技术 目的 示例
规范化 将输入数据处理为已知或预期的格式。

  • URL 解码/编码

  • 文件路径或名称处理

|

清洗 清洗是去除非法字符或使潜在风险数据变得安全。始终对输出进行清洗以避免 XSS。
  • 转义：将 < > ' " & 替换为 HTML 实体。

|

验证 检查输入是否有效或是否符合约束的数据类型、长度等。
  • IsAlpha, isCreditCard, isDecimal, isIP

|

实施的正确顺序也很重要，可以减少恶意数据绕过验证的可能性。安全编码需要以下内容：

  • 在验证之前对字符串进行规范化处理

  • 在验证之前对路径名进行规范化处理

  • 在验证之前进行任何字符串修改

  • 在使用之前对 URL 进行规范化处理

当接收到数据时，应首先对数据进行规范化处理，将其转化为预期的格式，然后对数据进行清洗，移除非法字符，验证可能根据业务规则检查数据是否可接受。最后，如果数据需要输出，总是需要进行输出清洗，以防止 XSS 攻击：

对于一般的规范化、清洗和验证，我们可以应用成熟的安全框架提供的 API，而开发团队可以更多地专注于业务逻辑验证：

编程语言 验证和清洗框架
Java
  • OWASP Java HTML 清洗器

|

Ruby on Rails
  • Active Record 验证

|

Node.js/JavaScript
  • 验证器

|

JavaScript
  • DOMPurity 用于清洗 HTML 并防止 XSS 攻击

|

Python
  • Cerberus

|

数据屏蔽

数据屏蔽是通过混淆原始/敏感数据来保护数据的过程。根据不同的角色或使用场景，需要使用不同的工具。典型的五种数据屏蔽场景包括：

场景 涉及角色 所需工具/模块

|

  1. 应用程序接收数据并根据定义的策略进行数据屏蔽
开发者

  • 数据屏蔽模块

  • 数据屏蔽策略

|

|

  1. 定义 PII 数据标签和访问策略
数据库管理员 (DBA)

  • PII 元数据定义

  • PII 访问策略

|

|

  1. 基于定义的 PII 标签和访问策略查询数据结果并进行数据屏蔽
数据查询用户
  • 动态数据屏蔽

|

|

  1. 运维团队可能会监控并检查数据、文件、配置或任何非结构化数据中是否存在 PII。
运维团队
  • PII 数据发现

|

|

  1. 日志或文件中的任何 PII 在进一步处理前必须进行掩码处理。
支持团队
  • 数据匿名化工具

|

对于数据掩码技术，匿名化和假名化是两大常见类别。

匿名化 假名化
关键区别 匿名数据无法重新识别。 假名化数据是数据替代，可以进行某种形式的重新识别。加密或哈希是这一类别中最常用的技术。

| 数据 | 匿名化主要用于敏感的个人信息，例如：

  • 姓名

  • 身份证号（信用卡号、社会安全号码等）

  • 邮政地址

  • 电话号码

  • 邮政编码 + 城市

|

  • 任何数据

|

表格列出了常用的数据掩码、匿名化和假名化技术：

让我们以电话号码为例，说明匿名化与假名化之间的关键区别。如果电话号码的原始值是 12345678，那么该号码的匿名化将是 123，而该电话号码的假名化则是哈希或加密后的值 ADF231DADEF。这也意味着，如果号码的匿名化结果类似于 123，用户就无法知道原始值。然而，如果已知算法或收集到足够的数据样本，哈希或加密后的值仍然可能被逆向还原为原始值。

数据治理 – Apache Ranger 和 Atlas

在数据隐私治理方面，我们不仅仅需要基于角色的访问控制 (RBAC) 或 基于属性的访问控制 (ABAC)，这些是常见的安全访问控制方式。数据治理还需要额外的元数据或标签来定义数据分类，并且需要行级别的基于属性的访问控制来进行数据掩码或行过滤。以欧盟和美国的数据中心为例——我们希望能拥有细粒度的访问控制策略，具体如下：

  • 美国支持团队只能查询美国数据，无法查看欧盟数据

  • 欧盟支持团队只能查询欧盟数据，无法查看美国数据

  • 年龄被视为个人身份信息（PII），只能作为范围显示给美国支持团队

  • 欧盟支持团队不能查看年龄信息

  • 身份证号是 PII 数据，将进行数据掩码处理

这个示例展示了数据隐私更多的是关于授权访问控制隐私数据的权限。随着大数据与云服务的使用、GDPR 合规性以及个人隐私意识的提升，对数据治理、数据掩码、加密、数据分类和细粒度 ABAC 等技术的需求不断增加：

你可以考虑基于 Apache Ranger 和 Atlas 框架构建数据隐私治理。Apache Ranger 主要用于 ABAC，而 Atlas 用于数据分类。

第三方开源管理

组织应建立内部开源和第三方软件的数据库及选择标准。该数据库记录项目中采用的开源或自家开发的组件，为类似项目（例如我们之前讨论的网络安全框架）提供良好的框架选择参考。如果你正在寻找一个开源组件搜索数据库，可以尝试 Open Hub。你可以在这里搜索开源项目并找到项目所需的资源：www.openhub.net/。此外，开源选择标准有助于减少法律和质量风险。

以下表列出了典型的标准检查清单：

选择标准 示例和说明
开源社区是否及时修复安全问题？
  • 高安全风险在 1 个月内修复。

|

采用最新且稳定的版本
  • 社区发布的官方且稳定版本。

|

是否提供技术支持？
  • 开源社区提供官方技术支持并反馈问题。

|

含有 GPL 和 LGPL 许可证的软件组件不太推荐。

  • 不推荐使用 GPL 和 LGPL 许可证的组件。如果使用了 GPL 软件组件，可能还需要将自定义开发的源代码作为开源代码公开。

  • 二进制分析工具（BAT）建议用于基于二进制文件的许可证扫描：www.binaryanalysis.org/。

|

漏洞状态与修复

|

软件发布或更新频率
  • 最新版本是在 6 个月内发布，还是几年之前发布的？

|

软件架构
  • 是不是使用了最新的软件技术，还是依赖于遗留框架？

|

对于开源组件的安全性，推荐的安全实践和工具在 DevOps 阶段的应用总结如下表所示：

阶段 活动 推荐工具/实践
设计与选择 选择开源软件。

|

软件包交付 识别项目中的所有依赖关系并检查已知的漏洞。

  • OWASP 依赖检查

  • OWASP 依赖追踪

|

软件包部署 在线服务监控和 CVE 扫描。

|

此外，参考 SAFECode Managing Security Risks Inherent in the Use of Third-party Components: www.safecode.org/wp-content/uploads/2017/05/SAFECode_TPC_Whitepaper.pdf。

总结

我们讨论了安全架构设计原则，包括安全设计和隐私设计的澄清。安全设计侧重于机密性、完整性和可用性（CIA），而隐私设计更关注隐私数据的保护。行业标准 CSA、Google、PCI 或 NIST 提供了良好的参考。我们还可以参考 OSA 云计算模式来理解云服务的整体安全架构。

要构建一个安全框架，我们列出了一些开源安全框架，以实现一些安全控制，而不是重新发明轮子。例如，在 Java 中有 Spring Security 和 Shiro 用于 Web 安全框架，NodeJS 中有 Passport 框架。

谈到网站隐私保护时，我们讨论了法律要求，例如版权声明、Cookie、免责声明和数据保护通知。我们列出了网页隐私的关键安全技术控制。

我们还讨论了登录保护模块，如 Fail2Ban 和 reCAPTCHA，以及加密模块（OpenSSL、SSLyze）。我们解释了输入验证的概念，包括归一化、清理和验证。为了保护敏感数据，解释了数据脱敏和技术（匿名化、假名化）的场景。解释了使用 Apache Ranger 和 Atlas 框架进行数据分类和脱敏的数据治理。介绍了大量第三方组件和安全框架组件后，我们还建议组织如何管理第三方开源软件。

在下一章中，我们将更详细地讨论威胁建模和安全设计安全实践。

问题

  1. 以下哪项是安全设计原则之一？

    1. 建立安全默认值

    2. 最小权限原则

    3. 安全地失败

    4. 以上全部

  2. 以下哪个参考汇总了大多数安全标准，如 ISO、FedRAMP 和 NIST？

    1. CSA CAIQ

    2. Google VSAQ

    3. PCI DSS

    4. （OSA）开放安全架构模式

  3. Spring Security 框架提供了什么安全保护？

    1. 认证

    2. CSRF 攻击防护

    3. HTTP 安全头部

    4. 以上全部

  4. Shiro 和 Spring Security 之间的主要区别是什么？

    1. Shiro 不需要 Java Spring 框架

    2. 记录日志

    3. 加密

    4. 入侵防御

  5. 以下哪个可能适用于 Passport 框架？

    1. ASP .NET

    2. Node.JS

    3. Ruby on Rails

    4. Python

  6. 以下哪个加密模块特别用于嵌入式应用？

    1. OpenSSL

    2. Mbed TLS

    3. SSLyze

    4. Fail2Ban

  7. 以下哪个是清理的示例？

    1. 将输入数据处理为已知或预期的形式

    2. 检查输入是否有效

    3. 删除非法字符

    4. 检查数据类型

进一步阅读

第七章：威胁建模实践与安全设计

在讨论安全架构和设计原则后，我们将介绍威胁建模的安全实践和工具。采用威胁建模实践有助于在设计阶段减少主要的安全风险。此外，一旦识别出风险，我们将介绍如何应用 OWASP 安全设计最佳实践来缓解这些安全风险。

本章将覆盖以下主题：

  • 威胁建模实践

  • 使用 STRIDE 进行威胁建模

  • 图表设计工具

  • 卡牌游戏

  • 威胁库参考

  • 案例研究：是否需要正式文档？

  • 安全设计

威胁建模实践

威胁建模是一项安全实践，旨在帮助团队根据现有的架构设计识别威胁、攻击和风险，并减少这些潜在的安全风险。在进一步讨论之前，有几点关于威胁建模需要澄清：

  • 这是一个团队活动，不仅仅是开发人员的工作。与 QA、运维、架构师和安全团队的参与将更为有效。

  • 威胁建模可能是唯一不建议通过自动化完成的安全实践。这是一个团队协作的活动。

  • 威胁建模的目的是识别高风险威胁，而不是提供一个全面的威胁列表，关键模块如身份验证、授权、购买或客户信息处理等是重点。

  • 建议在架构设计完成后，或者在详细设计和编码阶段之前进行威胁建模，尽管将威胁建模应用于现有应用程序也是常见做法。

一个典型的威胁建模过程包括 DFD 图或架构审查、威胁分析、风险影响评估、缓解措施以及产品实施行动审查。威胁建模通常从对架构的分析开始。DFD 图在威胁建模活动中是常用的。然而，只要团队能够理解整个架构设计和信息流，UML 或其他现有架构设计也可以完成任务。威胁建模的目标是与缓解措施一起讨论最相关和优先级最高的安全风险。不要让过程或工具限制团队的学习和创新。

根据应用程序的复杂性，我们可以在架构或高级设计阶段进行威胁建模。如果是一个非常大的项目，并且大多数模块提供类似功能，建议对高风险部分或最能代表业务功能的模块进行威胁建模。以下是推荐进行威胁建模的模块。这些也适用于代码审查：

  • 包含安全控制的模块，如身份验证、授权、会话管理、加密、数据验证、错误处理、日志记录、管理和数据库处理器。

  • 存在漏洞的旧模块（CVE）。

  • 可能与未知用户或第三方 API 进行外部交互的模块

  • 处理敏感信息的模块。

STRIDE 威胁建模

STRIDE 威胁模型定义了六类威胁，包括欺骗、篡改、否认、信息披露、服务拒绝和权限提升。通常用于评估架构设计。

STRIDE 威胁模型和通用安全缓解措施在下表中进行了总结。除了 STRIDE，还建议在分析中包括隐私：

STRIDE 威胁 缓解措施
欺骗 认证，如凭证、证书和 SSH
篡改 完整性（HASH256，数字签名）
否认 认证、日志记录
信息披露 保密性（加密，ACL）
服务拒绝 可用性（负载均衡、缓冲区、消息队列）
权限提升 授权（ACL）
隐私（附加内容） 数据屏蔽、访问控制、用户同意、删除

STRIDE 分析通常涉及实体（用户、管理员、外部应用）、过程（Web 服务器、FTP、服务）、数据存储（数据库或文件）、数据流（模块、过程、系统或用户之间的参数或信息）和信任边界。以下是 STRIDE 分析映射的一些示例：

STRIDE 和隐私威胁 示例
欺骗 实体（用户或客户端）可能伪装其身份。过程可能伪装其来源。
篡改 该过程可能会被篡改，例如 DLL 注入攻击。数据存储可能会被篡改。信息流可能会被篡改，例如 MITM 攻击。
否认 实体（客户端）可能否认已做的事情。过程可能篡改日志以否认已做的事情。审计日志的数据存储可能会被篡改。
信息披露 该过程本身可能包含一个加密密钥，并且可以被反向操作。数据存储会保留密码的明文副本。数据流在没有加密通道的情况下传输密码。
服务拒绝 过程可能连接到过多的客户端并导致超载。数据存储损坏或已满。数据流断开，无法到达目标。
权限提升 该过程应在用户模式下运行，但可以执行内核模式命令。该过程以附加权限运行。
隐私 外部实体（客户端应用）可能会收集 PII，但未告知用户。数据存储在日志中保留 PII，且未进行匿名化处理。

请参考 OWASP 应用威胁建模，以获取基于 DFD 图的更多示例：www.owasp.org/index.php/Application_Threat_Modeling。

实际操作中，STRIDE 可能仍然过于概括，无法让团队深入讨论威胁。因此，强烈建议使用清单或威胁库列表，如 CWE 列表（cwe.mitre.org/data/index.html）、常见攻击模式枚举与分类 (CAPEC) 或 对抗性战术、技术与常识 (ATT&CK)，我们将在下一部分讨论这些内容。

工具和模板的目的是帮助团队更高效地进行威胁建模。另一方面，使用工具可能会给团队带来学习曲线或额外负担。我们将介绍一些可以应用于威胁建模实践的工具。

图表设计工具

这些工具帮助你绘制应用程序的图表（DFD），标出信任边界，并标注威胁属性。工具还包括一个威胁库，供用户从中选择威胁。它是一个理想的工具，用于记录威胁建模分析报告。通常，应用程序架构和系统图（DFD）展示之后，紧接着就是威胁识别。

如果你的团队分布在多个地区，或者威胁建模需要跨不同时区的多个角色提供离线反馈，强烈建议使用这些工具来生成威胁建模分析报告。

微软威胁建模工具、OWASP Threat Dragon 和 Mozilla SeaSponge 是这一类别中的工具，它们可以帮助你绘制带有威胁分析的 DFD 图表：

纸牌游戏

纸牌游戏使威胁建模成为团队建设的一部分。所有团队成员聚集在一起，手中持有一副卡片和应用程序的数据流图。每张卡片代表一种常见的威胁。以 OWASP Cornucopia 为例，这些威胁也映射到业界实践中，如 OWASP SCP、OWASP ASVS、CAPEC 和 SAFECode。

OWASP Cornucopia 定义了六个与关键安全领域相关的套件：

  • 数据验证和编码 (VE)

  • 身份验证 (AT)

  • 会话管理 (SM)

  • 授权 (AZ)

  • 加密 (CR)

  • Cornucopia (C)

请参考此链接以获取卡片的 DOC 或 PDF 版本：www.owasp.org/index.php/OWASP_Cornucopia#tab=Get_the_Cards。

例如，数据验证与编码 套件的第 2 张卡片展示了攻击场景，并将安全最佳实践映射到 OWASP SCP、ASVS、AppSensor、CAPEC 和 SAFECode：

2
Brian 可以通过错误信息、配置不当、默认安装文件的存在或旧的、测试的、备份的或资源的副本，或者源代码暴露来收集关于底层配置、模式、逻辑、代码、软件、服务和基础设施的信息

|

| OWASP SCP69, 107-109, 136, 137, 153, 156, 158, 162 |

| OWASP ASVS1.10, 4.5, 8.1, 11.5, 19.1, 19.5 |

| OWASP AppSensorHT1-3 |

| CAPEC54, 541 |

| SAFECode4, 23 |

| OWASP Cornucopia 电商网站版 v1.20-EN |

|

这个卡牌游戏即使只有一个开发人员也能作为一个有效的工具。开发人员或测试人员可以随机抽取一张卡牌，反映现有应用程序中的安全问题。利用这些卡牌思考现有设计是否容易受到威胁，或者是否缺少安全考虑。这款卡牌游戏能使威胁建模变得更加有趣。毫无疑问，面对面的讨论总是最有效的沟通方式。

有两个问题我们需要注意。首先，要使一个团队能够一起玩卡牌游戏，F2F 团队必须坐在一起。其次，一个分布在多个地区的项目团队可能无法一起玩卡牌游戏。为了解决这两个问题，仍然需要官方文档记录讨论结果。该文档包含已识别的风险和缓解措施，不仅供无法参与卡牌游戏的团队进行审核，还用于追踪目的。

卡牌游戏的参考资料如下：

威胁库参考资料

有时，在威胁建模分析过程中，很难头脑风暴出威胁。通过从威胁库中挑选符合现有应用设计的威胁会更容易。卡牌游戏确实有帮助，但它们可能只呈现最常见的威胁。如果你发现这些威胁不适合你的项目，或者需要更多的威胁库供参考，这里有一些建议的行业威胁库：

威胁库 特征
CAPEC 以树状视图列出了 508 种攻击模式。攻击模式也可以通过 CSV 和 XML 格式获取。每种攻击模式都标有 CAPEC-ID 编号。
ATT&CK 按平台（Linux、Windows、Mac、移动设备）分类的威胁，包含具体的攻击技术。每个威胁还讨论了技术性缓解和检测方法，涉及大量实用的黑客和恶意软件攻击技术。
CWE CWE 是一个软件弱点列表，每个 CWE 都被归类为威胁树视图，并展示不安全和安全的源代码实现。它也是安全编码的一个非常好的参考。

案例研究——是否需要正式文档？

让我们通过一个案例研究来讨论威胁建模实践的不同方法。Peter 和 Linda 是安全负责人，他们计划与项目团队一起进行威胁建模。Peter 所在的是一家非常大的组织，项目团队成员分布在全球各地。安全流程要求提供正式的威胁建模分析报告，作为进入下一步的标准之一。另一方面，Linda 在一家小型软件公司工作，团队成员都在同一地点。Linda 认为使用白板和卡片游戏进行讨论将比详细文档更加互动和高效。因此，Peter 和 Linda 决定采取不同的方法来进行威胁建模，具体总结如下表所示：

正式过程（Peter） 小组讨论（Linda）
特点 需要正式文档交付使用模板和工具生成所需输出文档可能积累知识 无需正式文档交付采用专注于团队互动和讨论过程的卡片游戏
工具 检查表和模板威胁建模与图表设计器 卡片游戏白板
缺点 文档可能会增加团队的负担 讨论过程中缺乏文档可能仅适用于成员地理位置相近的团队

没有完美的过程，关键在于哪种方法最适合团队。没有规定 Peter 不能使用卡片游戏，或者 Linda 不能采用正式流程。任何过程采用的最重要部分是理解该过程的目标和合理性。例如，Linda 可能会考虑将最终的卡片游戏讨论结果记录下来，以供利益相关者参考。Peter 可能会考虑在小型模块/团队中使用卡片游戏，以减少文档负担。考虑混合方法可能是一个不错的主意。只要不让流程限制团队的创造力和创新。

安全设计

安全设计可以是一个非常广泛的讨论话题。在本节中，我们将重点讨论七个关键安全控制：身份验证、授权、会话管理、数据验证、错误处理、日志记录和加密。请参考以下图示：

安全设计可能与多个因素相关，包括安全需求、安全框架的采用、逻辑流程和正确的实现。以身份验证为例——市场安全需求可能要求添加双因素认证或一次性密码（OTP）。安全框架，如 Spring Security 或 Shiro 本身，提供身份验证、授权和会话管理的安全控制。然而，错误的逻辑流程和不正确的实现可能导致其身份验证绕过安全问题。尽管组织可以定义安全设计政策和指南，但通过展示安全框架、CWE 案例研究和实施示例仍然是最有效的。

安全设计培训或通讯可以包括行业常见的 CWE 以及公司内部项目的常见问题，随后给出安全设计建议。建议还可以介绍一个安全框架，并列出常见的错误实现，这些错误实现会导致安全风险。在这里，我们仅列出 Java 实现的示例。此外，以下链接建议供进一步阅读：

只需记住，采用安全框架并不意味着应用程序就会得到保障。它仍然需要正确的框架实现：

常见 CWE 开源框架

| 身份验证 | CWE-294: 捕获重放导致的身份验证绕过 CWE-306: 关键功能缺少身份验证

CWE-307: 不当限制过多的身份验证尝试

CWE-640 忘记密码的弱密码恢复机制 | Spring SecurityShiroKeyCloakVisualCaptchaprivacyIDEA |

授权 CWE-639: 通过用户控制的密钥绕过授权 CWE-647: 使用非标准 URL 路径进行授权决策 CWE-425: 直接请求（“强制浏览”） Spring SecurityShiro
会话管理 CWE-384: 会话固定 CWE-613: 会话过期不足 CWE-6: J2EE 配置错误: 会话 ID 长度不足 CWE-488: 数据元素暴露给错误的会话 Spring SecurityShiroJetty
数据验证 CWE-89 SQL 命令中未正确中和特殊元素 CWE-77 命令中未正确中和特殊元素 CWE-120: 缓冲区复制时未检查输入大小（“经典缓冲区溢出”） Java Commons Validator
错误处理 CWE-200: 信息泄露 CWE-460: 异常抛出时未正确清理 不适用。通常需要安全编码实践和正确的配置。
日志记录 CWE-532: 通过日志文件暴露信息 CWE-117: 日志输出未正确中和 CWE-779: 记录过多数据 SLF4F（Java 简单日志外观）OWASP 安全日志
加密 CWE-759: 使用无盐的单向哈希 CWE-523: 未保护的凭证传输 CWE-330: 使用不充分随机的值 OpenSSL BouncyCastle

以下是 OWASP 主动控制建议的其他实用安全软件实施框架：

OWASP 十大主动控制 开源工具和框架
C1: 定义安全需求

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

  • OWASP 移动应用安全验证标准（MASVS）

|

C2: 利用安全框架和库

  • OWASP 依赖检查

  • OWASP 依赖追踪

  • Retire.JS

|

C3: 安全数据库访问
  • CIS 数据库加固标准

|

C4: 编码和转义数据

  • OWASP Java 编码器项目示例

  • OWASP Java 编码器项目

  • AntiXSSEncoder

  • Zend/Escaper

|

C5: 验证所有输入

  • OWASP Java HTML 清理项目

  • Java JSR-303/JSR-349 Bean 验证

  • Java Hibernate 验证器

  • JEP-290 过滤传入的序列化数据

  • Apache Commons Validator

  • PHP 的过滤器函数

|

C6: 实施数字身份

|

C7: 强制访问控制
  • OWASP ZAP 与可选的访问控制测试插件

|

C8: 保护数据无处不在

  • SSLyze: SSL 配置扫描库和 CLI 工具

  • SSLLabs: 免费的 TLS/SSL 配置扫描与检查服务

  • OWASP O-Saft TLS 工具: TLS 连接测试工具

  • TLS 观察台

  • SSL 配置生成器

  • GitRob: 查找 GitHub 公开文件中敏感信息的命令行工具

  • TruffleHog: 搜索意外提交的秘密信息

  • KeyWhiz: 密钥管理工具

  • Hashicorp Vault: 密钥管理工具

|

C9: 实施安全日志记录与监控

  • OWASP 安全日志记录项目

  • Apache 日志服务

|

C10: 处理所有错误和异常

  • 错误易发（Error Prone）

  • 混沌猴（Chaos Monkey）

|

在分析安全问题的根本原因时，有时很难确定问题是由于不安全的设计还是不安全的编码所导致。每当可能时，建议将安全设计文档化为详细的具体实现。例如，安全设计文档可能会定义使用安全的随机数进行加密。然而，如果没有对安全随机数的具体定义，开发团队仍然无法实现安全的实施。有关强随机数的建议，请参考 OWASP 加密存储备忘单。

组织可以考虑建立一个内部的安全设计知识门户，其中包括以下资源：

  • 安全设计案例研究：每个案例研究都包括场景、安全问题和减轻风险的设计。

  • 建议的实施框架：采用成熟的安全框架来解决常见的安全问题。

  • 作为 IDE 插件的一部分的安全助手：所有的安全编码规则对开发人员来说仍然可能是一种负担。建议为开发人员提供一个 IDE 插件，进行安全编码检查，并补充其他安全编码扫描工具。

实施审查工具包，如代码审查和依赖性审查工具。我们将在下一章中讨论这些工具。

如果你仍然发现构建安全设计知识门户有困难，以下是一些好的参考来源。知识门户的目标是为开发人员提供所有实现安全设计所需的知识、工具、教程和最佳实践：

在实践中，采用安全框架可以帮助你实现安全架构、设计和实施，因为这些安全框架是默认以安全为基础构建的。此外，采用安全框架仍然需要进行安全编码和实施。在下一章中，我们将更详细地探讨安全编码和实施。

总结

我们讨论了整个团队参与威胁建模实践和 STRIDE 示例（欺骗、篡改、否认、信息泄露、拒绝服务和权限提升）的重要性。

有多种工具和方法可以进行威胁建模。如果你需要一个 DFD/威胁图设计工具，可以使用微软的威胁建模工具、OWASP Threat Dragon 或 Mozilla SeaSponge。如果你有一个小团队，并且希望通过卡牌游戏的团队活动进行威胁建模，建议使用微软 EOP 卡牌游戏和 OWASP Cornucopia。

我们还介绍了一些威胁库，如 CAPEC、ATT&CK 和 CWE，这些库也能支持在威胁建模过程中进行威胁识别。我们还讨论了一个威胁建模案例研究，了解了使用威胁建模设计工具和卡牌游戏的优缺点。

在安全设计话题中，我们讨论了主要的关键安全控制措施，包括认证、授权、会话管理、数据验证、错误处理、日志记录和加密。我们建议在每个安全控制类别中参考 CWE 和开源安全框架。此外，推荐建立一个安全设计知识门户。OWASP SKF 和安全隐私的开放参考架构是很好的参考来源。

在接下来的章节中，我们将详细讨论安全实施和编码。

问题

  1. 威胁建模只与开发人员相关。QA、架构师或运维团队不需要参与。对还是错？

  2. 以下哪些模块应该应用威胁建模？

    1. 传统模块

    2. 与第三方供应商有外部交互的模块

    3. 处理个人信息的模块

    4. 以上所有

  3. 以下哪一项是防止否认的安全缓解措施？

    1. 哈希

    2. 认证日志

    3. 负载均衡

    4. 加密

  4. 以下哪一项主要不是用于威胁库参考？

    1. CAPE

    2. ATTCK

    3. SeaSponge

    4. CWE

  5. 以下哪一项与认证安全框架无关？

    1. Shiro

    2. Spring Security

    3. VisualCaptcha

    4. Java Commons Validator

进一步阅读

第八章：安全编码最佳实践

安全架构设计和威胁建模后是安全编码阶段。在编码阶段，我们希望避免使用不安全的 API、缓冲区溢出、敏感信息泄露等问题。每个开发人员都很难熟悉所有的安全编码规则。因此，如何运用安全编码工具和技巧来发现主要的安全问题，将在本章中讨论。

本章将涵盖以下主题：

  • 安全编码行业最佳实践

  • 建立安全编码基准

  • 安全编码意识培训

  • 工具评估

  • 工具优化

  • 高风险模块审查

  • 手动代码审查工具

  • 安全代码扫描工具

  • 安全编译

  • 实践中的常见问题

安全编码行业最佳实践

安全编码是安全软件的基础。我们已经进行了威胁建模和安全架构设计。这些都需要通过安全编码来实现。安全编码对于开发团队来说可能是一个挑战，因为开发人员通常忙于开发新特性，且可能需要学习数百条安全编码规则。在我们更详细地讨论安全编码实践之前，我们将回顾一下可以参考的现有安全编码标准。

根据编程语言的不同，安全编码标准总结如下表所示：

参考标准 描述与参考
CERT 安全编码
  • 该标准为 C、C++、Java、Perl 和 Android 提供了安全编码标准。

|

查找安全漏洞
  • 它提供了 Java 的漏洞代码样本和解决方案的错误模式。

|

CWE
  • 它提供了从常见软件弱点的角度出发的漏洞源代码示例。编码示例涵盖 C、C++、Java 和 PHP。

|

Android
  • Android 应用程序安全设计与安全编码指南

|

OWASP SKF

  • OWASP 安全知识框架。

  • 它可以作为一个内部安全知识库，包括 OWASP ASVS 和安全编码知识。

|

PHP 安全
  • OWASP PHP 安全备忘单

|

OWASP 代码审查
  • OWASP 代码审查项目

|

Apple 安全编码指南
  • Apple 安全编码指南

|

Go
  • GO 语言的安全编码实践

|

JavaScript
  • JavaScript 安全编码实践

|

Python
  • OWASP Python 安全项目

|

我们理解了安全编码基准和标准。此外，关键挑战在于如何将这些安全编码规则应用到开发人员的日常编码活动中。以下是进行安全编码实践的推荐方法。

建立安全编码基准

安全编码基准是最基本的安全编码要求，也是项目团队向下一个阶段推进的检查清单。安全编码基准还是发布标准的一部分。建议始终使用基于行业最佳实践或标准的安全编码指南，例如前表中描述的 CERT 安全编码。

根据每种编程语言（如 PHP、Python、JavaScript、Android 和 iOS）定义安全编码基准。安全编码基准最好不仅包括安全编码规则，还包括安全风险、易受攻击的代码示例和建议的解决方案。以下是一个示例。

安全代码问题 – 可预测的随机数：

使用可预测的随机数可能会导致会话 ID、令牌或加密初始化向量的漏洞。建议使用java.security.SecureRandom代替java.util.Random：

// 易受攻击的代码

Random rnd = New Random ();

// 建议的代码

SecureRandom rnd = SecureRandom();

所有项目在发布前必须使用指定的代码扫描工具进行扫描。某些组织还可能会定义安全编码实践的发布标准。以下是一些示例：

  • 扫描工具生成的扫描结果中的所有警告都必须检查

  • 所有编译器警告（不仅仅是错误）都应检查并清除

  • 扫描结果中每行代码的开放缺陷数不能超过某个百分比

此外，安全编码基准还需要相关的开发工具和实践中的培训；否则，这些安全编码规则将仅仅是文档。

安全编码意识培训

安全编码培训的目的是让开发团队了解我们即将执行的安全编码实践。在安全编码意识培训的初期阶段，重点将主要集中在以下内容：

  • 什么是安全编码标准或基准？

  • 常见的行业安全编码问题有哪些？

  • 它们会如何影响开发者的日常任务？

  • 安全代码扫描的发布标准

一个基于案例研究或场景的易受攻击的源代码示例，比单纯的安全编码规则具有更好的培训效果。以下是该领域的良好参考，提供了大量易受攻击的代码和安全最佳实践代码示例：

工具评估

一旦团队意识到安全编码的重要性和挑战，它将寻找一些工具来简化安全编码。扫描工具的评估可能包括以下考虑因素：

考虑因素 描述
可用性
  • 代码扫描工具的目标用户是开发者。可用性包括扫描源代码部分的能力、差异扫描、扫描报告、追溯到原始源代码等。

|

预算
  • 如果它是一个 IDE 插件商业工具，我们需要考虑它将需要多少并发用户许可证。

|

编程语言支持

  • 大多数工具支持 C/C++和 Java，但不支持脚本语言，如 Python、JavaScript 或 PHP。

  • 对公司内部项目使用的编程语言进行调查，并优先支持即将使用的编程语言。

|

检测率和误报率

  • 任何扫描工具都有误报率，这取决于扫描引擎和规则。高误报率并不一定是坏事，它也可能意味着扫描器采取了更保守的策略。选择最适合项目的工具，而不是选择最知名的工具。

  • 为了评估检测率，我们可以使用已知的漏洞项目。

|

扫描规则更新
  • 工具持续更新规则和扫描器非常重要。商业工具的一个关键优势是它们会有最新的扫描规则。

|

通常有两种代码扫描方式。第一种是使用 IDE 插件进行静态代码扫描，像拼写检查一样工作，对开发者来说更直观，方便学习和修正安全问题。第二种是使用每日构建进行代码扫描，生成每日扫描报告。开发者需要查看每日扫描报告，批量修复或评论安全问题。这种方式对于开发者来说可能不那么直观，但编译后的安全扫描可能提供更高的准确性。为了促进这两种扫描工具的采用，建议从小规模的试点团队开始。市场上有一些商业和开源工具，支持这两种扫描方式。

优点 缺点
IDE 插件静态代码扫描 对开发者直观（像拼写检查一样工作）。

  • 它可能会产生较高的误报。

  • 它要求每个开发者都安装插件。

  • 检测能力有限。

  • 每个开发者的许可证费用。

  • 需要强制要求每个开发者使用工具。

|

每日编译扫描

  • 基于项目集成和编译扫描的安全扫描准确性。

  • 集中管理扫描规则和结果。

  • 它容易建立安全指标并监控每个项目的结果。

|

  • 需要完整可构建的源代码。

  • 扫描结果需要进一步分配给开发者检查。当开发者被指派去检查报告时，他可能不熟悉其他模块。

|

代码扫描工具的评估包括检测率、假阳性率、潜在开销以及开发团队的可用性。用于静态代码扫描工具评估的脆弱代码项目列在下表中：

脆弱项目 描述 编程语言
NIST 软件保障参考数据集项目 该项目提供了故意设计的不安全代码示例，可用于测试安全代码扫描工具的检测率。 Java, C/C++, C#, PHP
OWASP Node JS Goat 这是一个脆弱的网站，用于练习 OWASP 前 10 大安全测试，使用 NodeJS 构建。 Node JS
OWASP WebGoat .Net 这是一个脆弱的网站，用于练习 OWASP 前 10 大安全测试，使用 .NET 构建。 .NET
OWASP WebGoat PHP 这是一个脆弱的网站，用于练习 OWASP 前 10 大安全测试，使用 PHP 构建。 PHP
OWASP Rail****sGoat 这是一个脆弱的网站，用于练习 OWASP 前 10 大安全测试，使用 Ruby 构建。 Ruby on Rails

一旦安全团队在测试结果后选择了扫描工具，安全团队可能会与更多的开发团队进行沟通，讨论工具的采用。在工具采用之前，建议通过演示使用结果、处理扫描结果以及使用扫描工具来进行实践培训。

这个阶段的培训更多侧重于如何做而不是做什么。实践教程的示例包括如何使用扫描工具，如何审查安全问题，如何根据扫描结果进行修复，如何禁用某些扫描规则等。

工具优化

一旦团队使用了代码扫描工具一段时间，安全团队可能会根据用户反馈帮助优化工具、流程或规则。以下是大规模代码扫描采用中需要优化的一些关键因素：

关键因素 建议
扫描规则定制 规则定制的目的是帮助项目团队减少假阳性。安全团队可能会帮助禁用一些不适用于项目的规则，或者修改那些总是导致假阳性的规则。
推荐修复 理想情况下，IDE 插件不仅会显示安全警告，还会提供修复建议。然而，如果所使用的工具不支持团队，使用 OWASP 安全知识框架可以作为替代方案。
集成 将代码扫描工具集成到 Jenkins 和开发者的 IDE 插件中。自动化框架。与 Jenkins 的集成是 CI/CD 的基本组成部分。
报告 团队可能会请求进一步的质量指标报告，例如基于之前检查结果的增量扫描报告或跨项目的常见问题报告。

| 自动化平台 | 将安全编码自动化提升到下一个水平涉及将多个工具集成到自动化平台中。尝试以下开源工具来构建自己的安全编码自动化平台：

  • SWAMP-in-a-Box：

  • JackHammer：

|

高风险模块审查

自动化代码扫描工具可以帮助检测大多数源代码的安全问题。然而，对于高风险模块，仍然需要额外的关注。除了源代码扫描工具，我们还将应用黑盒测试或动态应用安全测试（DAST），这些将在后续章节中讨论。像黑客一样思考。黑客会对哪些模块感兴趣？哪些信息对黑客来说最有价值？整个应用程序中最薄弱的环节可能是什么？下表列出了需要进一步审查的高风险模块：

高风险模块 安全审查重点
认证

  • 账户注册

  • 登录和验证码

  • 密码恢复或重置

  • 密码更改

  • 身份和密码存储及访问控制

  • 多次失败后的账户锁定控制

|

授权

  • 敏感资源访问

  • 管理员管理

|

配置

  • 配置中有两种审查类型：

    • 应用程序的安全配置，例如关闭调试模式和启用 TLS 通信。

    • 每个软件版本的配置影响。

|

财务

  • 支付功能

  • 订单和购物车

|

文件处理

  • 文件上传

  • 文件下载

|

数据库

  • 数据库查询

  • 数据库的添加、更新和删除

|

API 接口

  • Restful API 接口

  • 第三方集成接口

|

遗留

  • 不支持安全通信的模块

  • 可能仍使用弱加密算法的模块

  • 使用禁止或危险的 API

|

加密

  • 使用禁止的加密算法

  • 在开发过程中源代码中硬编码的敏感信息或注释，例如 IP、电子邮件、密码或隐藏的快捷键

|

会话

  • 并发会话控制和检测

  • 会话 ID 和过期时间的随机性

|

手动代码审查工具

手动代码审查可能需要一些时间。没有适当的工具和策略的手动代码审查就像是在大海捞针。如前所述，我们只对特定的高风险模块进行手动代码审查，而不是整个项目。除了选择目标范围，工具还可以帮助我们更高效地进行手动代码审查。以下是一些推荐的开源工具，虽然这些工具并不是专门为此目的设计的，但它们有助于提高源代码审查的效率：

工具 使用场景
AndroGuard

  • 这包括许多 Python 分析模块，用于对 Android 应用进行逆向工程分析。

  • 生成的图表可以通过 Gephi 查看。

|

Doxygen

  • 该工具支持多种编程语言，能够生成在线 HTML 或 PDF 文档。它还可以生成可由 Graphviz 查看的函数调用图。

  • 它有助于我们概览程序并识别出我们应重点关注的高风险模块。

|

Kscope
  • 该工具可以分析 C 源代码，生成调用函数的树和调用图。

|

OpenGrok
  • 它提供类似 Google 的语法和正则表达式全文源代码搜索。它还可以基于搜索结果进行交叉引用。

|

WinMerge

  • 它可以比较两个文件和文件夹之间的差异。比较结果以视觉颜色呈现。在我们查找不同版本间的代码变更时非常有用。

  • 对于非 Windows 平台，KDiff3 或 Meld 是替代的开源选项：

|

NCC Code Navi
  • NCC Code Navi 工具的主要优势是能够在源代码文件中进行关键词搜索。右键点击启动 CERT 搜索代码搜索也是非常有用的。

|

安全代码扫描工具

在源代码扫描方面，没有一种适合所有的解决方案。也没有任何扫描工具可以做到零假阳性并具有 100%准确的检测率。因此，对于相同的编程语言，我们通常会应用至少两个扫描工具进行交叉验证。

这里列出的是一些 2018 年常用的开源安全编码分析工具。请注意，我们这里只列出了开源工具：

Tools 扫描工具的背景和关键特性
Retire.JS

  • 检测易受攻击的 JavaScript 库，如 jQuery、AngularJS、Node 等。

  • 它提供命令行、grunt 插件，并且还提供 OWASP ZAP 插件用于集成扫描。

|

Clang Static Analyzer 该工具提供 C、C++和 Objective C 的独立命令行分析。
Flawfinder 一个简单的 C/C++代码扫描工具。它是一个 Python 命令行扫描工具，可以根据需求轻松定制。
DREK

  • 它像 GREP 一样通过正则表达式搜索特定的安全问题，但它可以生成 PDF 或 HTML 格式的扫描结果。

  • 它可以通过正则表达式轻松扩展任何扫描规则，且可用于扫描任何编程语言。

|

Pylint Pylint 是 Python 编程语言的源代码检查工具。
PHPMD
  • PHP Mess Detector 是一个 PHP 源代码扫描工具。

|

DawnScanner Ruby Web 应用程序的安全扫描工具。
SpotBugs

  • 这提供了一个独立的 GUI 和命令行界面。

  • SpotBugs 还可以作为 Eclipse 插件使用。它是 FindBugs 的继任者。

|

CPP Check 这是一个用于 C/C++的静态代码分析工具。
移动安全框架（MobSF） 移动安全框架是一个完全自动化的 Android 应用程序扫描工具。开发者只需上传 APK 到 MSF，MSF 将自动完成所有分析。
Clang 静态分析器 这是一个 C/C++和 Objective C 的代码分析工具。
ESLint

  • 这是一个用于 JavaScript 的命令行代码扫描工具。

  • 请参见此链接查看安全代码扫描规则：eslint.org/docs/rules/。

|

JSHint 这是一个用于 JavaScript 代码扫描的工具，并且提供了 NodeJS 的命令行工具。
Infer 这是一个由 Facebook 提供的 Java、C/C++和 Objective C 的静态代码分析器。
Phan Phan 是一个 PHP 静态分析工具。
PHP 安全检查器 这个工具检查 PHP 项目依赖项中的已知安全问题。
OWASP Dependency check 该工具支持多种编程框架，并检查已公开的漏洞，使用更新的 NVD 数据源。该工具可以通过命令行运行或与 Jenkins 集成运行。
VisualCodeGrepper (VCG) VCG 是一个语言无关的扫描工具。扫描规则也可以通过正则表达式轻松定制。它还提供了针对常见禁止 API 的默认规则，并提供 GUI 和命令行工具来扫描任何源代码。
PMD 这是一个用于 Java 和 JavaScript 的源代码分析工具，主要用于检查常见编程缺陷。
Graudit 这是一个简单的脚本，利用 GREP 搜索特定的代码模式来查找潜在的安全问题。签名数据库模板提供了查找线索。
SonarQube 这个工具支持超过 20 种语言，并且可以与 CI 框架集成。它也提供 UI，便于查看质量代码扫描结果。
Brakeman Ruby on Rails 的静态分析安全扫描器。
bandit Python 源代码的安全分析工具。
Error Prone Error Prone 在编译时检测潜在的 Java 错误。
Dawn Dawn 是一个用于 Ruby Web 应用的静态分析安全扫描器。

下面是按语言的另一种分类：

编程语言 扫描工具
C/C++

  • Infer

  • CPP Check

  • Flawfinder

  • Clang 静态分析器

|

Java

  • Infer

  • SpotBugs

  • PMD

|

Android
  • MobSF

|

PHP

  • Phan

  • PHPMD

|

Ruby
  • DawnScanner

|

Python
  • Pylint

|

JavaScript

  • ESLint

  • JSHint

  • Retire.JS

  • PMD

|

依赖漏洞

  • OWASP Dependency check

  • PHP 安全检查器

  • Retire.JS

|

语言无关

  • SonarQube

  • DREK

  • Graudit

  • VisualCodeGrepper

|

由于规则和检测引擎的能力，相同编程语言的扫描结果可能会有所不同。建议使用两个扫描工具对同一语言进行扫描。例如，使用一个商业工具进行日常编译扫描，另一个开源工具用于开发者的 IDE 插件。使用商业扫描工具有助于向客户说明服务是如何进行测试的，而开源扫描工具则为进一步定制和大规模部署提供了灵活性，无需预算限制。

安全编译

内存损坏和缓冲区溢出可能导致利用代码注入攻击。对于 C/C++编程语言，这些可以通过编译器选项进行保护。通过适当配置 C/C++编译器（GCC，MS Visual Studio），应用程序可以增加额外的运行时防御层，以防止利用代码注入攻击。这些通常被开发团队忽视。常见的安全选项总结如下表：

保护技术 安全选项 操作系统/编译器
地址空间布局随机化（ASLR） echo 1 >/proc/sys/kernel/randomize_va_space Android, Linux 操作系统
基于栈的缓冲区溢出保护 -fstack-protector –fstack-protector-all gcc
GOT 表保护 -Wl, -z, relro gcc
动态链接路径 -Wl,--disable-new-dtags,--rpath [path] gcc
不可执行栈 -Wl,-z,noexecstack gcc
镜像随机化 –fpie –pie gcc
不安全的 C 运行时函数检测 –D_FORTIFY_SOURCE=2 –Wformat-security gcc
基于栈的缓冲区溢出防护（Canary） /GS MS（微软）Visual C++
地址空间布局随机化（ASLR） /DYNAMICBASE MS Visual C++
CPU 级别的不可执行（NX）支持。数据执行防护（DEP） /NXCOMPAT MS Visual C++
安全结构化异常处理 /SAFESEH MS Visual C++
启用附加安全检查 /SDL MS Visual C++

进一步参考和每种保护技术的描述，请查看以下参考资料：

为了验证应用程序或环境是否已配置安全选项，以下工具非常有用：

实践中的常见问题

市面上有许多商业和开源的安全编码工具。有哪种工具能够提供低假阳性率和高检测率吗？

回答：没有完美或卓越的工具能够提供高检测率并保持低假阳性率。每个工具提供的扫描结果不同。较高的阳性率也可能意味着更保守的扫描，识别更多潜在或可疑的代码问题。你会发现不同工具的检测率和扫描结果也有所不同。工具 A 可能能够检测到工具 B 无法识别的问题，反之亦然。在实际操作中，也建议使用至少两种工具进行代码扫描作为交叉参考审查。

扫描结果可能列出超过 1000 个问题。对于如何处理这些问题，有什么建议吗？

回答：对于大规模项目，出现此类问题是非常常见的。开发团队检查扫描工具识别出的所有问题可能会感到不知所措。这里有一些可以考虑的方法：

  • 首先筛选并评估那些评分为高风险的问题。

  • 根据项目自定义扫描规则，过滤掉与项目无关的规则。

  • 对新添加或最近更改的源代码范围进行增量扫描。这可能取决于扫描工具是否提供增量扫描功能。

  • 对相同根本原因/问题进行分类。也许 50%的问题是由相同的根本原因引起的，例如使用相同的模块。

总结

我们已经讨论了安全编码行业的最佳实践，例如 CERT、CWE、Android 安全编码、OWASP 代码审查和 Apple 安全编码指南。基于这些安全编码规则，我们建立了安全编码基准，作为安全政策和发布标准的一部分。为了让团队熟悉安全编码，我们准备了一个培训门户。建议安全编码知识门户不仅应提供编码规则，还应提供案例研究。

为了将安全编码应用到开发者的日常工作中，必须采用安全编码工具。我们评估了安全编码工具，考虑了可用性、预算、编程语言支持、检测率和扫描规则维护等因素。为了评估扫描工具的检测率，我们还引入了一些可作为测试项目的漏洞项目。

安全编码规则和最佳实践是指导方针。它们需要正确的安全编码工具来实现，同时还需要正确的方法以使其更加高效和有效。因此，我们讨论了代码审查方法以及高风险模块的示例。为了更高效地进行高风险模块的手动代码审查，我们还列出了一些有助于审查的工具。最后，我们列出了适用于不同编程语言的常见开源安全代码扫描工具。

在下一章中，我们将通过一个案例研究，介绍开发阶段的安全需求、威胁建模、安全架构、设计和实现。

问题

  1. 以下哪个不包含在 CERT 安全编码标准中？

    1. C/C++

    2. Java

    3. Android

    4. PHP

  2. Find Security Bugs 主要用于以下哪种编程语言？

    1. C/C++

    2. Python

    3. Java

    4. Go

  3. 以下哪个可以作为安全编码的发布标准？

    1. 所有源代码必须使用指定的代码扫描工具进行审查。

    2. 所有编译器警告应检查并清除。

    3. 扫描工具生成的所有警告必须进行检查

    4. 以上所有

  4. 使用易受攻击的项目来评估代码扫描工具的主要目的是什么？

    1. 检测率和误报率

    2. 预算

    3. 许可证

    4. 性能

  5. 以下哪个不防止缓冲区溢出漏洞代码注入？

    1. 地址空间布局随机化（ASLR）

    2. CSRF 令牌

    3. 基于栈的缓冲区溢出保护

    4. 非执行栈

  6. 以下哪个不用于扫描依赖性漏洞？

    1. OWASP 依赖性检查

    2. PHP 安全检查工具

    3. Retire.JS

    4. VisualCodeGrepper

  7. 哪个是自动化的移动安全测试框架？

    1. MobSF

    2. OpenGrok

    3. Retire.JS

    4. SonarQube

  8. 以下哪个工具不用于 Android 安全评估？

    1. AndroGuard

    2. MobSF（移动安全框架）

    3. Flawfinder

    4. SpotBugs

深入阅读

第九章：案例研究 - 安全与隐私设计

我们已经讨论了安全架构和设计原则、威胁建模以及安全编码实践。在本章中，我们将通过一个案例研究来讨论安全设计和隐私设计的实施。该案例研究将展示 DevOps 团队在应用安全实践时可能遇到的常见挑战，以及安全团队如何提供最佳实践、工具、安全框架和培训工具包来帮助解决这些挑战。

案例研究将从 OWASP ASVS 的安全评估开始，进一步识别所需的安全改进，例如身份验证、授权、会话管理、数据输入/输出控制和隐私设计。我们将查看一些建议的工具和开源安全框架的实现。此外，第三方组件还可能引入漏洞和安全风险。我们还将讨论用于审查和管理开源框架及依赖项的流程和工具。

本章将涵盖以下主题：

  • 安全架构审查

  • 隐私设计

  • 安全与隐私框架总结

  • 第三方组件管理

案例研究背景

理查德是一个在线书店的 CTO，管理着约 500 名开发人员。理查德希望与安全团队合作，在架构审查、设计审查和第三方框架审查过程中应用标准的安全实践，并且还应用安全编码。理查德和安全团队达成共识，他们应该具备以下条件，以为下一阶段的业务发展做准备：

  • 安全设计检查清单

  • 推荐的安全设计模式

  • 可重用的第三方组件列表

让我们看看安全团队如何帮助理查德通过开发阶段。

安全架构审查

为了评估电子商务网站的现有安全架构，安全团队决定与架构师合作，基于 OWASP ASVS 实践进行初步架构审查。为了进行评估，项目团队可以使用在线门户或 EXCEL。在这个案例中，项目安全架构审查是使用 EXCEL 检查清单完成的，之后才使用了内部安全评估门户。以下表格包含了一些关于这两种工具的资源和文档，您可能会觉得有用：

OWASP 评估工具 资源参考
在线演示

|

离线 EXCEL

|

OWASP ASVS 评估的结果可以通过图表呈现，展示哪些安全领域需要进一步改进：

经过一些试点项目后，安全团队对 OWASP ASVS 评估越来越熟悉，且有更多项目需要进行安全评估。为了便于项目数据管理和交叉参考审查，安全团队决定基于以下开源框架之一，建立并定制一个内部评估门户，而不是使用 EXCEL：

为了建立安全设计检查表，安全团队引入了 OWASP ASVS 实践，建立了内部知识库，并与项目团队进行了自我评估。为了建立安全设计模式和一系列可复用的安全框架，安全团队决定基于 OWASP ASVS 的评估结果，提出一个开源安全框架。这是因为一些安全框架也包含了安全最佳实践，如 Web 安全框架、Spring 安全和 Shiro。

认证

基于对项目的 OWASP ASVS 评估，安全团队发现他们未能满足某些认证安全要求。

OWASP ASVS 认证：

OWASP ASVS 认证验证源代码中或在线源代码库中不包含秘密、API 密钥和密码。

安全团队进一步调查了现有的秘密管理实践。首席技术官理查德澄清了这个问题正成为开发和运维团队的头疼问题。在开发和测试环境中，开发人员可能会将密码或密钥保存在一个单独的配置文件中。然而，为了过滤这些文件，并将它们分开存放在不同的版本控制仓库中，确实需要大量的沟通，并且增加了协作负担。

为了减轻风险，安全团队提出了一些安全实践。他们建议在源代码提交到代码库时，应加密敏感信息。测试和运维团队将定期扫描源代码库，查找任何敏感信息。下图展示了修订后的开发工作流模型：

安全团队还建议了一些工具，以便整合到开发、测试和运维团队的日常工作中。以下是一些可能用于秘密管理的开源工具：

工具 场景和工具

| Git Secret | 开发人员可能需要一种工具，可以在提交时加密敏感文件，并在检出时透明地解密。如果您的开发团队使用 Git 作为主要的源代码仓库，以下工具可以用于减少 API 密钥、密码或加密密钥等秘密泄露。

  • Git-Secret

  • 黑盒

  • Git-Crypt

  • Git-Remote-gcrypt

|

TruffleDumpsterDiver 开发人员、QA 或运维团队倾向于定期搜索源代码或配置文件，以识别文件中是否存在潜在的秘密泄露。TruffleHog 可以对 GIT 仓库进行秘密搜索，而 DumpsterDiver 则在本地文件中搜索秘密。

一旦安全团队评估了这些工具，下一阶段是与一些开发和运维团队进行试点测试，然后再进行大规模部署。试点测试的目的是使过程更加顺畅，并为更好的可用性定制工具。

授权

授权安全要求可以参考《OWASP ASVS V4：访问控制验证要求》。例如，OWASP ASVS 自我评估结果显示需要集中机制保护。

集中机制保护：您应验证是否存在集中机制（包括调用外部授权服务的库）来保护对每种受保护资源的访问。

为了实现集中机制保护，安全团队决定引入 API 网关架构，设计使所有 API 接口都由 API 网关/管理器控制，例如身份验证、API 密钥、监控、ACL、日志记录和速率限制。安全团队与 CTO Richard 讨论后，意识到现有的安全控制是由每个服务实施的，且每个服务的实施也会发生变化。Richard 希望有一个通用的安全框架，不仅为了确保一致的访问控制行为，还为了实现安全策略的集中管理。

对于需要与外部合作伙伴互动的服务，中央安全策略管理至关重要：

市场上有多种 API 管理器选项。以下表格列出了一些开源的 API 管理器解决方案。采用开源框架或工具的一个关键优势是，您可以根据业务需求进行进一步的定制：

API 管理器 开源参考
Kong

|

API umbrella

|

WSO2 API 管理器

|

会话管理

CTO 还指出了会话管理实现中存在的一些挑战。现有的会话管理需要与特定的容器技术绑定，并不支持各种类型的客户端应用访问，如独立或非 Web 应用。CTO 希望会话管理能够支持异构客户端访问，并且希望它能够与容器无关。此外，团队还希望以不同的方式实现 CSRF 令牌，这可能会带来潜在的风险和额外的工作。CTO 希望团队提供一个公共库，以实现一致的 CSRF 保护。

在评估会话管理的挑战和需求后，安全团队着手评估可行的安全框架，并准备一个安全工具包，工具包可能包含下表中的信息。安全工具包的目的是帮助开发团队在开发过程中应用相关的安全实践和工具：

阶段 安全参考和工具
威胁分析

  • CWE-6 会话 ID 长度不足

  • CWE-352 跨站请求伪造（CSRF）

  • CWE-384 会话固定

  • CWE-488 数据元素暴露给错误的会话

  • CWE-613 会话过期不足：

查询特定 CWE 的提示。只需在下面的 URL 末尾指定 CWE ID 号。例如，CWE-613 为cwe.mitre.org/data/definitions/613.html。|

安全设计

  • OWASP ASVS V3 会话管理

  • OWASP Top 10 A2 弱认证

  • OWASP 会话管理备忘单

|

安全架构

|

数据输入/输出

每个项目团队实现数据输入验证的方式不同。有些项目团队可能忽略了过滤某些非法字符，有些可能不知道如何正确地编码输出，有些可能忽视在验证前进行路径或 URL 的规范化。这些数据输入/输出处理问题可能导致一些安全问题。因此，CTO 希望安全团队提供合适的安全框架，并为其员工创建实操教程。

安全团队提出了一个安全培训工具包，其中包括编码规则、编码框架、扫描工具和一些案例研究。

数据输入/输出培训工具包：

培训工具包的目的是提供数据输入验证和数据输出编码的安全最佳实践、工具和实施指南，以防止 XSS 攻击。

一般安全编码规则：

必须在验证之前进行规范化和标准化。

应使用输出编码以避免 XSS 攻击。

下表展示了安全培训工具包的初步议程：

安全框架/工具 安全控制
OWASP HTML Sanitizer Project (www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project) 这是一个用于 Java 的 HTML 清理工具，旨在防止 XSS 攻击。
Commons Validator (commons.apache.org/proper/commons-validator/) 这是一个通用数据验证器，提供数据格式验证，如电子邮件、信用卡、日期、URL 等。
ValidateJS (validatejs.org/) 这是一个前端 JavaScript 数据验证器。
OWASP Java Encoder (www.owasp.org/index.php/OWASP_Java_Encoder_Project) 它的工作原理与 HTML 清理器类似。用于执行输出编码以避免 XSS 攻击。

安全编码扫描工具

安全风险示例：

  • FIO16-J：在验证路径之前进行路径名规范化

  • IDS07-J：清理传递给Runtime.exec()方法的不可信数据

  • IDS00-J：防止 SQL 注入

  • IDS16-J：防止 XML 注入

  • IDS08-J：清理包含在正则表达式中的不可信数据

  • IDS06-J：从格式字符串中排除未清理的用户输入

更多内容请参见wiki.sei.cmu.edu/confluence/display/java/2+Rules。

隐私设计

团队意识到隐私的重要性，并接受了与隐私法相关的意识培训。然而，将法律语言转化为技术安全要求之间仍然存在差距。CTO 希望安全团队帮助提供常见的隐私设计解决方案，并使隐私设计在软件工程团队的技术指南中得以体现。此外，CTO 还计划让各项目团队完成现有的数据任务实现，计划制定通用库来实现一致的数据屏蔽行为，以减少跨团队的实施工作量。运营部门还提出了其他问题，如敏感信息分类和隐私评估扫描。安全团队的职责不仅是引入行业最佳实践，还包括评估支持在 DevOps 过程中进行隐私设计的可行工具或框架。在此阶段，以下资源可以为您提供帮助：

隐私设计的挑战 安全团队的建议
如何将“隐私设计”转化为技术安全要求？

|

开发人员需要一个数据掩码实现 API 来处理敏感信息。 ARX De-Identifier 数据匿名化工具。
运维团队需要根据现有数据库分类 PII 属性，并配置访问安全策略。 评估 Apache Atlas 框架以进行数据治理和访问控制。
DevOps 团队需要一个自动隐私扫描工具，以评估所有 Web 服务的隐私状态。 尝试使用 'PrivacyScore' 进行 Web 隐私评估。
开发团队需要一个通用库来实现所有 Web 服务的一致 Cookie 同意行为。 开源的 CookieConsent 库可能是一个值得评估的候选项。

安全性和隐私框架总结

采用任何安全框架不仅需要考虑业务需求，还要考虑其与现有架构的契合度。以下是我们在本案例研究中讨论的行业实践、工具和框架的总结：

安全性改进领域 开源安全和隐私框架
身份认证

  • Gluu：它用于多因素认证和社交登录。

  • CAPTCHA 通常用于防止机器登录。可以考虑使用 HCaptcha、ReCaptcha、Patcha 这些开源解决方案。

  • Git-Secret：用于保护源代码库中的敏感信息，建议开发团队使用该工具。

|

授权

  • Gluu：它还提供用户同意管理功能

  • Apache Shiro 会话管理

  • OWASP CSRF Guard 可以生成安全令牌来防止 CSRF 攻击。

|

| API 管理器 | 可以考虑应用以下开源框架来保护外部 RESTful API 接口的安全。

  • Kong

  • API umbrella

  • WSO2 API 管理器

|

| 数据输入/输出 | 根据编程语言的不同，可能有各种数据验证框架。

  • OWASP Java HTML Sanitizer 项目：它是一个用 Java 编写的 HTML Sanitizer，用于防止 XSS。

  • Commons 验证器：它是一个 Java 验证库

  • ValidateJS：它是一个 JavaScript 验证库。

  • OWASP Java Encoder：它是一个 Java 编码库，主要用于防止 XSS。

|

隐私

|

第三方组件管理

为了降低第三方组件的安全风险，团队定义了一个评估第三方组件的流程。然而，CTO 发现手动检查开源许可证以收集相关信息确实耗费了大量精力，而且在这个过程中，团队也犯了一些错误，比如信息丢失或错误输入数据。CTO 与安全团队进行了会面，讨论了自动化扫描整个项目、为每个组件创建身份许可证等相关信息的可行性。该审查的各个阶段和关键活动如下表所示：

阶段 第三方组件审查的关键活动
需求
  • 从法律、许可证、安全性和支持等角度评估开源框架组件

|

设计

  • 将开源信息保存在中央数据库中，包括开源名称、版本、来源和许可证等详细信息

  • 对组件进行威胁和安全分析，确保没有后门、硬编码的加密密钥以及隐藏的恶意软件

  • 确保提供软件更新和补丁的渠道

|

实施

  • 必须使用安全代码扫描工具验证第三方组件

  • 所有的安全更新和更改应作为变更管理的一部分进行文档记录

|

验证

  • 安全测试的范围包括所有第三方组件

  • 项目中应实施许可证声明

  • 必须与法律部门确认许可证的合规性

|

发布

  • 必须揭示已知的 CVE 或漏洞

  • 确保所有二进制文件的完整性

|

维护
  • 必须制定并实施安全更新计划

|

没有适当的工具或自动化工具，安全实践可能会对开发团队造成很大的负担。在了解执行过程中面临的挑战后，安全团队确定了三个关键领域：

  • 许可证信息的代码扫描

  • 对已知漏洞进行二进制扫描

  • 对二进制文件进行扫描和运行时行为监控，以发现潜在的后门和恶意行为

以下是一些推荐的第三方组件扫描工具：

目的 推荐的开源工具

| 开源许可证检查 | 以下项目有助于识别和提取开源组件中的关键信息，例如漏洞、许可证和版权状态。 |

  • AboutCode

  • FOSSology

  • Ninka

  • Linux 基金会开源扫描

|

已知漏洞检查 OWASP Dependency Check、OWASP Dependency Track 和 OpenVAS 是推荐的开源工具，用于扫描软件漏洞。
恶意软件和可疑行为分析 Cuckoo：这是一种沙箱工具，用于分析未知文件的静态和动态行为。

概要

在本案例研究中，我们回顾了一个典型电子商务网站在需求、架构、安全框架、设计评审和威胁建模阶段采用安全实践的情况。我们讨论了安全团队的角色以及 DevOps 团队在采用安全实践时面临的挑战。

团队通过应用 OWASP ASVS 进行了架构评估。团队发现有一些安全领域可以改进，包括身份验证、授权、会话管理和数据输入验证。此外，团队还在寻求关于隐私设计的实施建议。

对于身份验证过程，他们发现一些敏感信息，如加密密钥、密码或密钥，可能会不小心提交到源代码仓库中。安全团队建议应用监控或加密工具（Git-Secret），以防止开发人员将凭证以明文形式提交到 Git 仓库中。

对于授权过程，由于 REST API 与第三方合作伙伴的开放接口，架构需要中央安全访问控制。引入了 API 管理器来管理所有 API 的 ACL、日志、授权和速率限制。开源解决方案，如 Kong 和 WSO2 API Manager，被引入团队以供进一步评估。除了 API 访问控制，团队还在寻找一个安全的会话管理框架，以处理各种客户端技术，并保护系统免受 CSRF 攻击。为了解决安全会话管理问题，安全团队提出了一个安全工具包，其中包括带有 CWE 示例的威胁分析、OWASP 安全设计备忘单以及用于实现的开源框架，如 Shiro 和 CSRF Guard。

关于数据输入验证和输出编码，安全团队准备了一个培训工具包，其中包括安全编码规则、安全框架和代码扫描工具。在实施过程中，根据安全需求，建议使用一些开源框架，例如 HTTP Sanitizer、common validator、ValidateJS 和 Java Encoder。

隐私设计不仅对法律合规至关重要，而且对个人数据保护也至关重要。项目团队对如何将这些法律要求转化为软件工程技术要求感到困惑。安全团队根据可能的场景提出了一些行业最佳实践和工具。例如，开发人员需要确保他们的 API 正确地实现数据掩码。运营团队需要与现有数据库一起对个人身份信息（PII）属性进行数据分类，并配置访问安全策略。DevOps 团队需要一款自动化隐私扫描工具，以评估所有 Web 服务的隐私状态。开发团队需要一个通用库，以便为所有 Web 服务实现一致的 Cookie 同意行为。如果我们使用正确的工具和框架，隐私设计将使我们的要求更容易实现。

最后但同样重要的是，我们讨论了第三方组件管理。有许多开源框架和工具应用于安全实践。第三方组件也引入了法律和安全风险。我们介绍了一些实践和工具来减轻这些风险。

我们在开发阶段已经详细研究了威胁建模、安全需求、安全架构、框架、设计安全和隐私安全。接下来的章节，我们将更加深入地探讨安全测试。

问题

  1. 以下哪些是我们不希望包含在源代码中的机密？

    1. API 密钥

    2. 密码

    3. 加密密钥

    4. 以上所有

  2. API 网关不能做什么？

    1. 访问控制列表

    2. 限流

    3. 杀毒软件

    4. API 密钥认证

  3. 以下哪个与会话管理的安全性相关？

    1. 会话 ID 长度不足

    2. 跨站请求伪造（CSRF）

    3. 会话固定

    4. 以上所有

  4. 对与数据验证相关的问题，标准化和规范化是否发生在验证之后？请判断正误。

  5. 数据匿名化的用途是什么？

    1. 它用于执行敏感信息的数据掩码

    2. 它用于数据治理

    3. 网络隐私评估

    4. Cookie 同意

  6. AboutCode、FOSSology 和 Ninka 工具能做什么？

    1. 开源许可证检查

    2. 已知漏洞检查

    3. 可疑行为分析

    4. 入侵防御

深入阅读

第十章：安全测试计划和实践

我们已经讨论了涉及开发过程中的安全实践，包括架构安全、设计安全、威胁建模和编码安全等阶段。现在我们将讨论测试阶段的安全测试计划和实践。

本章的目标是概述安全测试计划、安全测试领域以及最低安全测试范围的设置。我们将讨论安全测试计划、测试方法、风险分析、安全领域和行业实践，以构建你的安全测试知识库。此外，我们还将介绍一些行业最佳实践、测试方法和安全工具，以供安全测试使用。

本章将涵盖以下主题：

  • 安全测试知识包

  • 安全测试计划模板

  • Web 安全测试

  • 隐私

  • 安全测试领域

  • 像黑客一样思考

  • 安全培训环境

安全测试知识包

安全测试，也称为渗透测试，是一项非常专业的工作。没有适当的指导、培训和工具，测试结果和安全测试的质量可能会有所不同。建议拥有一个内部的安全测试知识门户，其中可以包含安全测试指南、最佳实践、说明、工具和培训环境。可以使用开放 Web 应用程序安全项目（OWASP）安全测试知识包来构建这样的知识门户。以下表格概述了整个安全测试知识包应涵盖的内容：

安全测试工具包 目的
安全测试计划模板 测试计划定义了实现业务目标的安全基准、测试方法、工具和风险分析。根据应用的业务需求，建议根据技术领域进行调整。
隐私或安全检查清单 检查清单可以是基本的测试用例集。安全更多关注应用程序的 CIA（机密性、完整性、可用性），而隐私则更侧重于保护个人信息。
安全测试工具包 工具包为项目团队提供常见的安全测试工具建议。
培训环境 培训环境使用易受攻击的应用程序，让安全团队进行实际的安全测试练习。

为了建立自己的内部安全测试知识门户，建议采纳 OWASP 安全知识框架，其中包括 OWASP ASVS、安全知识和代码示例，如下图所示：

来源: skf.readme.io/docs/knowledge-base

安全测试计划模板

黑客攻击与安全测试的主要区别在于，安全测试需要对整个应用程序进行全面的安全质量保证，而黑客攻击则是寻找特定的安全问题或漏洞。创建一个安全测试模板将有助于项目团队规划安全测试并维持安全测试的质量。以下是构建安全测试计划的业内公认最佳实践：

  • OWASP 测试指南：OWASP 测试指南提供了 Web 应用程序安全测试的什么、为什么、何时、何地和如何。

  • PCI 渗透测试指南：PCI 渗透测试指南并不是列出详细的测试案例和工具，而是包括了四个关键议程，如渗透测试组件、渗透测试人员的资格、渗透测试方法和渗透测试报告指南。

  • NIST 800-115 信息安全测试与评估技术指南：提供了有关规划和执行渗透测试活动的实用建议。

  • 移动安全测试指南（MSTG）：专注于移动安全测试，包括测试方法、技术和工具。

以下是包含主要部分的安全测试模板示例。

安全测试目标

本节应明确安全测试的业务目标。例如，业务目标中最重要的部分可以是 GDPR 合规性、PCI DSS 合规性、客户期望，或定期或重大版本的安全检查。将安全测试与业务目标相结合有助于管理安全测试的重点和范围。

安全测试基线

安全测试基线定义了测试范围和标准的最低期望。OWASP ASVS 和 OWASP MSTG 是刚开始建立安全测试基线的组织的良好参考。除了软件应用程序的安全性外，还包括以下常常被忽视的领域：

  • 平台安全配置，如操作系统、数据库、虚拟化技术、Web 服务（nginX、Apache）

  • 安全通信协议，如 SFTP、SSH v2 或 TLS v1.2

  • 第三方软件组件的已知漏洞

  • 敏感信息或个人身份信息（PII）数据的处理、存储和删除

  • 与访问管理、密码更改、认证以及外部通信接口使用相关的文档或在线帮助说明

  • 软件补丁更新和完整性检查的安全通道

  • 密码策略的复杂性

  • 日志文件访问控制及所有非查询操作的日志记录

安全测试环境

测试环境列出了所有软件组件，包括应用程序、所有依赖项和平台。在准备安全测试环境时，建议有一个与生产环境完全相同的预备环境。在大多数情况下，安全问题可能不是由软件应用程序本身引起的，而是由依赖项或平台的安全配置问题引起的。

测试策略

测试策略强调了某些高风险功能的测试方法。测试策略可以是手动审查、自动化测试，或白盒测试与黑盒测试。白盒测试主要关注源代码级的检查，黑盒测试则从终端用户和黑客的角度审视整个应用程序。这些测试策略通常采用混合方式执行。以下表格展示了平台和身份验证功能的测试策略示例：

测试策略 平台 身份验证
手动审查 不适用 设计审查
自动化 完全自动化扫描 暴力破解攻击
白盒测试 审查配置文件 加密代码审查
黑盒测试 端口或服务扫描 暴力破解攻击

高风险模块

本节的目的是列出黑客最感兴趣的攻击功能或可能具有更大安全影响的功能，标题为高风险模块。以下表格列出了一些高风险模块的风险及其测试方法：

模块或功能 安全风险 测试方法
身份验证 账户被盗，暴力破解攻击。 暴力破解账户攻击，密码攻击
管理管理 权限提升。 通过不同角色测试相同的功能。列出管理员 URL 以供运营商或访客账户测试。文件访问控制列表（ACL）检查。
文件上传 上传恶意许可证文件或文件注入攻击。 非法的文件类型、大小、名称和内容。
软件更新 软件可能会被更新或注入恶意代码。 软件包完整性检查、签名检查和文件大小检查。
密码重置 账户可能被盗或遭遇账户枚举暴力破解攻击。 密码不能以明文形式发送。密码重置流程需要原始电子邮件、安全问题或手机验证。

推荐的安全测试工具

这可以是一个非常广泛的领域。这里是一个典型的安全测试工具集，我们将在后续章节中进一步讨论。最小的安全测试范围包括漏洞扫描、端口扫描、网络安全、模糊测试、安全配置等。建议每个安全测试领域至少使用两种安全工具，以涵盖更多的测试场景。请看一下这个表格：

安全测试领域 建议的安全测试工具
漏洞扫描 Nessus, OpenVAS, Retina：这些是常见的开源工具，用于扫描应用程序、Web 服务以及所有软件依赖项的漏洞。
端口扫描 Nmap：Nmap 广泛用于网络安全扫描。常见的网络安全扫描场景包括端口扫描、主机扫描和服务发现。
Web 安全 OWASP ZAP, Arachni, Burp：这些是最受欢迎的开源且免费的 Web 安全测试工具，可以执行 OWASP Top 10 安全测试。
代码扫描 FindBugs, SonarQube：这些工具用于静态安全编码扫描。FindBugs 主要用于 Java。SonarQube 支持超过 20 种编程语言的代码质量问题扫描。
Fuzz 测试 Peach, FuzzDB, API-fuzzer：Fuzz 测试的目标是给定大量动态和随机数据输入，以验证目标应用在意外输入下的行为。
安全配置 OpenSCAP：该工具执行操作系统、软件和服务配置的安全评估和强制执行安全配置基准。
秘密或敏感信息 TruffleHog 或 GittyLeaks：这些工具扫描 GIT 源代码库中可能存在的秘密、API 密钥或密码。
移动 移动安全测试框架（MSTF）：MSTF 提供 APK 文件的全自动静态和动态分析。
SSL SSLScan, SSLyze：这些工具扫描并检测网站的 SSL/TLS 配置是否不安全。
拒绝服务（DoS）攻击 Hping：Hping 可以进行 TCP 数据包操作。HTTPSlow：HTTPSlow 用于生成 HTTP 慢速 DoS 攻击。
注入 SQLMap：SQLMap 是用于 SQL 注入攻击的常用工具。Commix：Commix 用于命令注入攻击。
登录暴力破解 THC Hydra：该工具以暴力破解登录攻击而著名。它支持多种协议，如 SNMP、SMTP、Cisco AAA、HTTP、MySQL 等。
Android 测试 APKtool, dex2Jar, JD-Gui, Appie：这些是常见的开源工具，用于进行 Android 安全测试。Appie 是一个便携的 Android 安全测试工具包，包含所有工具，且可以在 Windows 上执行，无需虚拟机。
SQL 注入测试 SQLMap, Sqlninja：SQL 注入是常见的攻击方式，允许黑客窃取或篡改网站后端数据库。SQLMap 和 Sqlninja 可以帮助进行各种类型的 SQL 注入测试。

网络安全测试

如我们所讨论的通用安全测试计划，还建议根据具体领域准备安全测试指令。每个领域需要不同种类的安全测试工具和方法。通常有 Web、虚拟化、固件、大数据、隐私和物联网安全领域。

Web 服务是应用程序和云服务最常见的呈现方式。几乎所有云服务都通过 Web UI 呈现，可以通过任何浏览器轻松管理，无需安装客户端应用程序。此外，用于服务间通信的 RESTful API 通信也是建立在 HTTPS 之上的。Web 安全可以被视为云服务的基础。谈到 Web 安全时，我们必须熟悉开放 Web 应用安全项目（OWASP）Top 10，它通过行业排名调查列出了最常见的 Web 安全问题。请查看以下内容：

  • A1:2017-注入漏洞：任何数据输入源都可能导致注入攻击，常见的攻击包括 SQL 注入、命令注入、XML 注入等。

  • A2:2017-认证漏洞：弱密码策略、认证控制或会话管理可能使攻击者获得未授权的账户访问权限。

  • A3:2017-敏感数据泄露：不安全的数据传输、弱加密或数据存储访问控制可能导致个人数据泄露。

  • A4:2017-XML 外部实体（XXE）：利用 XML 处理器漏洞进行 XXE 注入，进而实现远程控制、窃取数据或发动拒绝服务攻击。

  • A5:2017-访问控制漏洞：指在特权功能、URL 或关键资源上，访问控制机制薄弱或缺失。

  • A6:2017-安全配置错误：攻击者可能利用默认账户、启用的服务、错误消息、目录列表、默认权限或已知漏洞攻击系统。安全配置包括应用服务、网络服务、Web 服务器、应用服务器、数据库、框架等。

  • A7:2017-跨站脚本攻击（XSS）：利用跨站脚本（XSS）攻击，攻击者可以在受害者的浏览器中执行任意 HTML 和 JavaScript 代码，或将攻击者可控制的数据存储在 Web 服务器上。

  • A8:2017-不安全的反序列化：反序列化是将对象转换为字节流的常见过程，以便传输到内存、数据库或文件。攻击者可能会篡改对象或数据，从而实现远程代码注入攻击。

  • A9:2017-使用存在已知漏洞的组件：包括操作系统、Web/应用服务器、数据库管理系统（DBMS）、应用程序、API 及所有组件、运行时环境和库中存在的任何易受攻击的依赖项或未使用的库。

  • A10:2017-日志记录和监控不足：缺乏日志记录或监控可能会让攻击者或未经授权的用户在未被检测或审计的情况下窃取敏感信息。

OWASP 还建议安全测试人员考虑使用开放 Web 应用安全项目（OWASP）、应用安全验证标准（ASVS）、OWASP 测试指南和 OWASP 安全知识框架作为输入，而不仅仅依赖于特定的安全工具进行全面的安全保障。没有一刀切的解决方案。不要仅仅复制和应用这些 OWASP 项目。审视现有项目的需求，识别共同的安全基线。你可以进行一定的定制，以适应项目的需要。请查看此表：

OWASP 项目 项目目标与参考
OWASP 前 10 大 OWASP 前 10 大列出了 10 个最关键的 Web 安全问题。它还提供了如何识别应用是否脆弱、如何防止攻击、攻击场景示例及与每个关键安全问题相关的参考资料。
OWASP ASVS OWASP 应用安全验证标准提供了一系列应用安全要求，也可以作为安全测试清单使用。
OWASP 测试指南 OWASP 测试指南提供了如何测试的案例和建议的工具。
OWASP 安全知识框架（SKF） OWASP SKF 可以帮助建立安全知识门户，包含 OWASP ASVS 清单、安全知识库和代码示例。
OWASP 安全移动测试指南项目（MSTG） 这是一个移动应用（Apple iOS 和 Android）测试指南的好参考，提供了移动测试方法论，并建议了测试工具。

隐私

有两类隐私信息需要保护。一类是与应用安全相关的敏感信息，如密码、API 密钥、加密密钥、CA 证书，另一类是个人身份信息（PII），它也受到 GDPR 的监管。对于敏感信息的审查，涉及 IAM、加密、会话管理、日志记录、CA 管理和管理的功能是直接处理敏感信息的模块。以下是隐私数据处理生命周期的通用测试指南：

数据生命周期 测试关键点 建议测试工具
数据传输

  • 确保敏感信息不通过 GET 传输

  • 安全通信协议，如 TLS v1.2、SSH V2、SFTP、SNMP V3。

SSLyze, NMAP, Wireshark
数据存储

  • 检查敏感信息是否被加密

  • 检查文件的权限是否正确配置

TruffleHog
数据加密
数据访问与审计

  • 记录所有敏感数据查询

  • ACL 权限

AuthMatrix
数据删除

  • 不要在临时文件、异常文件和 Cookie 中存储敏感信息

  • 检查内存和缓存中的任何明文敏感信息

GCOREWinHex LaZagne

此外，还有一些与敏感信息高度相关的文件类型。以下是一些常见的文件，这些文件可能暴露敏感信息，需要在应用程序中进行加密或适当的访问权限控制：

文件可能包含敏感信息 文件类型
SSH 密钥 *rsa, *dsa, edcsa
加密密钥 Pckcs12, pfx, p12, asc,
Shell 历史文件 Bash_history, zsh_history
Shell 配置文件 bashrc, zshrc, bash_profile, zsh_profile
PHP 配置文件 .INC
Docker 配置文件 Dockercfg
MySQL 命令历史 Mysql_history
应用程序或网络日志 .log

对于 PII 处理审查，请参考以下行业最佳实践：

安全测试领域

我们已经讨论了网络安全测试和隐私问题。安全测试必须与业务和应用程序的目标紧密结合，这不仅与测试场景相关，还与测试工具有关。了解应用程序的领域知识始终是规划安全测试的第一步。以下是每个安全测试领域的行业参考总结。组织可以基于这些参考进一步制定自己的领域特定测试计划。请查看此表：

安全领域 行业安全最佳实践与测试指南
网络安全测试
  • OWASP 测试指南

|

虚拟化安全测试

  • NIST 800-125 完整虚拟化技术安全指南

  • PCI DSS 虚拟化指南

  • Red Hat 虚拟化安全指南

  • SANS 顶级虚拟化安全错误

  • ISCACA 虚拟化安全清单

|

固件安全测试

  • GitHub Awesome 固件安全

  • GitHub BIOS/UEFI 系统固件的安全性，从攻击者和防御者的角度

|

大数据安全测试

  • NIST 1500-4 大数据互操作性框架

  • CSA 大数据安全与隐私手册

|

隐私

|

IoT 安全

  • ENISA IoT 基线安全建议

  • GSMA IOT 安全评估

|

容器安全
  • NIST 800-190 应用程序容器安全指南

|

移动安全
  • OWASP MSTG（移动安全测试指南）

|

像黑客一样思考

安全测试需要系统化的方法来审查应用程序，并涵盖全面的安全测试用例。我们参考一些行业最佳实践和工具来规划安全测试。另一方面，我们还应该向白帽黑客或真正的黑客学习。研究真实的威胁和漏洞的目的是审查并改进现有的安全测试方法和工具。以下部分包含一些关于真实漏洞的推荐参考资料。

漏洞利用与 CVE

这些资源提供了 CVE 的概念验证（PoC）测试脚本和工具。它们非常有价值，因为我们可以将这些测试脚本应用或定制为我们安全测试工具集的一部分。Security Focus、Packet Storm Security 和漏洞数据库不仅提供 CVE 信息，还提供安全测试工具和 PoC 脚本。请查看以下内容：

  • Security Focus：Security Focus 列出了每个 CVE 漏洞的技术细节。

  • Packet Storm Security：除了漏洞利用，它还提供大量更新的安全工具和安全白皮书。

  • 漏洞数据库：它提供漏洞利用、Shellcode、安全白皮书，还包括谷歌黑客数据库。

例如，对于 Java 反序列化安全问题，您可以搜索关键字反序列化以查找特定的易受攻击产品、测试脚本（大多是 Python 脚本）以及描述反序列化概念和测试技术的论文。您可以在漏洞数据库中找到它们：www.exploit-db.com/

此外，漏洞利用工具包也值得研究。这些漏洞利用工具包可以生成恶意负载和攻击工具，以针对特定的软件漏洞或创建后门连接。ExploitPack 和 Metasploit 是该类别中最常用的测试框架。

黑客技术

对抗性战术、技术与常识（ATT&CK）提供了大多数平台（包括 Windows、Linux、macOS 和移动设备）恶意威胁战术和技术的详细列表。例如，在 Windows 技术矩阵中的AppInit DLLs，ATT&CK 解释了 AppInit DLLs 的原理、示例、缓解措施、检测方法和参考资料（attack.mitre.org/wiki/Technique/T1103）。

以下是可以用于模拟 APT 攻击或 ATT&CK 的测试脚本。这些脚本可以用来测试现有的安全解决方案是否能够检测到这些可疑行为。参考以下内容：

恶意软件信息

了解现实世界中的恶意软件攻击是审查我们安全防御的另一种方式。US-CERT 是一个有价值的参考，因为它提供了对主要恶意软件攻击的详细技术分析、检测建议、妥协指标、恶意软件特征、应用程序的影响以及防御技术解决方案。有关“警报和提示”部分，请查看以下内容：

安全培训环境

未经许可进行安全或渗透测试是违法的。开发安全测试技能需要一个适当的测试环境或培训平台。这些安全测试环境是专门构建的漏洞 Web 或移动应用程序。一些安全测试环境甚至提供在线教程，指导你进行安全测试技巧。请参考下面列出的 OWASP 项目，获取安全测试环境的在线或离线虚拟化镜像的完整列表。如果可能，最好设置一个内部的安全测试环境，而不是使用外部的在线测试站点。以下是一些可帮助建立安全测试环境的漏洞应用程序项目。请注意，这些是漏洞应用程序，因此应在安全控制的环境中设置这些应用程序。以下开源项目是用于安全测试的漏洞 Web 应用程序示例：

  • OWASP 异常 Web 应用程序项目

  • OWASP 漏洞 Web 应用程序目录项目

  • OWASP Security Shepherd

  • MITRE 漏洞移动应用程序

为了鼓励安全测试的参与，可以举行内部安全测试比赛。奖励可以基于报告的安全问题的严重性。对于外部的白帽安全研究人员，可以考虑设立安全漏洞赏金计划，以奖励提交的漏洞。例如，Google Bug Hunter University 定义了不合格发现的规则和奖励计划，如“Google 应用安全奖励计划”和“Google Bug Hunter University”。

总结

在本章中，我们建议设置一个安全测试知识包，包括测试指南和相关的安全工具。OWASP 安全知识框架 (SKF) 提供了一个内部安全测试知识门户，默认包含 OWASP ASVS 检查表、安全知识和代码示例。安全团队可以使用 OWASP SKF 进一步定制安全测试知识门户。

为了制定安全测试计划，我们建议参考行业参考资料，如 OWASP 测试指南、PCI 渗透测试指南、NIST 800-115 和 移动安全测试指南（MSTG）。一个典型的安全测试计划应包括测试目标、基准、测试环境、测试策略、已识别的高风险模块，以及推荐的安全测试工具。

我们还讨论了一些可以帮助进行 web 和移动应用安全测试的 OWASP 项目。除此之外，我们讨论了应用程序如何处理隐私信息和敏感数据，这对安全测试同样至关重要。我们讨论了数据生命周期的安全测试重点和工具，并列出了可能包含高度敏感信息的常见系统文件。

除了 web 和移动安全，我们还列出了其他安全测试领域及相关行业参考，包括虚拟化、固件、大数据、隐私、物联网安全和容器。最后，为了提高您的安全测试知识，我们分享了一些参考资料，可以帮助了解黑客使用的技术，如漏洞利用和 CVE、黑客技术、漏洞利用工具包以及恶意软件案例研究。安全培训环境可以为内部团队提供一个内部安全测试平台，以进行实践性安全测试。

在下一章中，我们将讨论白盒安全测试技巧。

问题

  1. 建议的安全测试工具包应该包括以下哪些内容？

    1. 隐私检查清单

    2. 测试工具包

    3. 安全测试计划模板

    4. 以上所有

  2. 以下哪项行业参考涉及到移动安全？

    1. OWASP 测试指南

    2. NIST 800-115 渗透测试

    3. 移动安全测试指南（MSTG）

    4. PCI 渗透测试指南

  3. 什么是测试策略？

    1. 它是一个安全检查清单

    2. 它定义了高风险功能的测试方法

    3. 这是白盒测试

    4. 这是黑盒测试

  4. 以下哪项不是典型的高风险模块？

    1. 管理管理

    2. 身份验证

    3. 安装

    4. 密码重置

  5. 以下哪种安全工具不用于 web 安全？

    1. Nmap

    2. OWASP ZAP

    3. Arachni

    4. Burp

  6. 以下哪种通信协议是不安全的？

    1. TLS v1.2

    2. SSH v1

    3. SFTP

    4. SNMP v3

  7. ATT&CK 资源不能提供什么？

    1. 安全测试工具

    2. 对抗性战术

    3. 对抗性技术

    4. 对抗性知识

  8. OWASP Broken Web Application 项目用于什么？

    1. 它是一个 web 安全扫描工具

    2. 这是一个安全检查清单

    3. 这是一个为安全测试实践而构建的专用漏洞 web 应用

    4. 它是一个自动化测试框架

进一步阅读

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

第十一章：白盒测试技巧

测试计划概述了测试方法、风险评估和建议的测试工具。在本章中，我们将重点介绍白盒测试技巧。

白盒代码审查最有效的方式是识别特定的安全问题，如 XXE、反序列化和 SQL 注入。然而，如果没有合适的工具或策略，白盒审查可能会耗时。如果要进行有效的白盒测试，我们需要关注特定的编码模式和高风险模块。本章将提供识别高风险安全问题的技巧、工具和关键编码模式。

本章将涵盖以下主题：

  • 白盒审查准备

  • 整个项目的鸟瞰图

  • 高风险模块

  • 白盒审查检查清单

  • 常见的主要问题

  • 安全编码模式和关键字

  • 案例研究——Java Struts 安全审查

白盒审查准备

白盒测试或源代码审查最有效的方式是识别源代码中的隐藏安全问题。在开始白盒源代码审查之前，一些准备工作和输入将帮助我们判断该如何（方法、工具）以及做什么（哪些模块）来进行安全源代码审查。

以下是我们在进行源代码审查之前可能会检查的列表；请查看此表：

白盒测试输入 注意事项
源代码

  • 我们需要完整的可构建源代码吗？

  • 源代码是否包含相关的导入模块或头文件？

  • 这些依赖源代码在我们希望追溯某些 API 定义时非常有用。然而，如果没有完整的源代码，可能需要进行逆向工程。

|

威胁建模文档 威胁建模为我们提供了一个很好的参考，帮助识别我们应重点关注的高风险模块和接口。
架构和设计文档 架构和设计文档为我们提供了设计流程和模块关系的良好视图。
自动化静态代码分析结果 在进行白盒审查之前，最好先进行一次自动化安全代码扫描。扫描结果不仅使工作更容易，而且还会告诉我们应该关注哪些部分。
应用程序相关配置 一些安全框架可能在配置中定义安全策略，这些配置也应进行审查。例如，Spring MVC 或 Spring Security 框架中的 web.xml 文件对于访问控制非常关键。
通信接口或端口 列出外部 API 接口和通信端口的目的是了解它们如何与来自不可信源的外部输入、不安全的通信协议或错误暴露的 API 进行交互。

对于一些外部依赖或第三方组件，在没有源代码的情况下，我们可能需要对这些组件进行某些分析，以确定是否存在后门、弱加密、硬编码或密码。这将需要逆向工程和动态运行时分析。下表提供了一些工具供进一步参考：

描述 工具
Cuckoo Cuckoo Sandbox 是一个开源虚拟化环境，用于对任何二进制文件进行静态和动态分析。欲了解更多信息，请参阅 cuckoosandbox.org。
REMnux REMnux 包含了许多用于逆向工程的 Linux 工具包。欲了解更多信息，请参阅 remnux.org/。

查看整个项目

自上而下的方法意味着我们使用源代码分析工具来查看编程流程图，如类图、调用图或依赖图。下表列出了一些推荐的工具，帮助你更容易地分析源代码：

工具 描述

| Doxygen | 它可以从源代码生成文档，并且还可以通过使用 Graphviz 的 dot 工具，自动可视化模块之间的关系、依赖图和继承图。请参阅网站 www.doxygen.org。要能够从源代码生成文档，需要在源代码中添加适当的注释和标签。以下是一些可能值得阅读的提示。请记住，通过 doxygen 生成文档可能需要较长时间。不要将 doxygen 与编译器的部分任务绑定。有关更多信息，请查看以下链接：

|

Graphviz 它不是一个代码分析工具，但它帮助 doxygen 生成图表。欲了解更多信息，请参阅 www.graphviz.org/Download.php。
HTML Help Workshop 用于将 doxygen 生成的 HTML 文件转换为 CHM 文档。请查看 msdn.microsoft.com/en-us/library/windows/desktop/ms669985(v=vs.85).aspx。
phpDocumentor 如果项目的编程语言是 PHP，phpDocumentor 能够很好地直接从 PHP 源代码生成 API 文档和类继承图。请查看 www.phpdoc.org/。

| Natural docs | 它支持超过 20 种编程语言，并允许开发者以非常直接的方式记录源代码。请记住，源文档仍然需要开发团队正确地注释源代码。请查看 www.naturaldocs.org/。以下是源代码中注释的示例：

// Function: Sum
// Sum up two integers and returns the result.
int Sum (int a, int b)
{ return a + b; }

|

| Pandoc | 它是一个通用的文档格式转换器。请查看以下链接以获取更多信息：

|

Sphinx 它主要用于 Python 文档。请查看 www.sphinx-doc.org/。

总结来说，为了直接从源代码生成文档，我们将使用以下工具——Natural docs 和 doxygen 用于一般编程语言，phpDocumentor 用于 PHP，Sphinx 用于 Python。这些文档生成工具并非魔法。如果开发团队没有遵循某些编码注释规范，生成的信息也会受到限制。对于白盒审查，我们使用源代码文档生成工具来更高效地识别安全问题。然而，如果生成的文档在这方面帮助不大，可以转向以下审查方法。请仔细考虑以下各节内容。

高风险模块

一旦我们对整个项目有了清晰的了解，我们将需要识别那些需要进一步手动代码审查的模块或功能。我们不仅仅对高风险模块进行手动代码审查；我们会对所有模块进行自动化代码扫描，并对那些可能隐藏安全问题的高风险模块进行进一步的手动代码审查，这些问题可能无法通过自动化扫描工具轻易识别。

当我们识别高风险模块，以优先考虑白盒源代码审查模块时，尽量像黑客一样思考。哪些模块会吸引黑客？ 哪些信息对黑客最有价值？ 所有应用中最薄弱的环节是什么？ 以下表格列出了应考虑进行进一步白盒审查的典型高风险模块：

高风险模块 业务功能
身份验证

  • 账户注册。

  • 登录与验证码。

  • 密码恢复或重置。

  • 密码更改。

  • 身份和密码存储与访问控制。

  • 多次失败后的账户锁定控制。

|

授权

  • 敏感资源访问。

  • 管理管理。

|

配置管理 配置审查有两种类型。一种是配置值，另一种是应用程序如何安装或更新配置。一般来说，网页、数据库和服务配置需要特别注意。
财务

  • 支付功能。

  • 订单和购物车。

|

文件处理

  • 文件上传。

  • 文件下载。

  • 文件处理。

|

数据库

  • 数据库查询操作。

  • 数据库创建、添加、更新和删除选项。

|

API 接口

  • Restful API 接口或其他通信接口。

  • 第三方集成接口。

|

遗留

  • 不支持安全通信的模块。

  • 可能仍在使用弱加密算法的模块。

  • 使用禁用或危险的 API。

|

加密

  • 使用禁用的加密算法。

  • 在开发过程中，源代码中硬编码的敏感信息或注释，例如 IP、电子邮件、密码或隐藏的快捷键。

|

白盒审查检查表

建议制定检查表进行白盒审查。在白盒源代码审查中使用安全检查表可以帮助团队决定应该关注的重点内容。典型的代码审查安全检查表可能包括关键安全控制项，如身份验证、数据验证、授权、会话管理、错误处理、加密、日志记录、安全配置、管理功能、支付、与金钱相关的功能以及私人数据处理。

安全检查表的参考来源可以来自行业最佳实践或历史项目经验。检查表的内容可以根据审查的目标不同而有所不同。

请查看下表：

安全检查表类别 目标和参考

| 一般安全代码审查检查表 | 目标是为项目团队提供一个安全代码审查检查表模板。项目团队可以根据项目概况进一步添加或自定义列表。以下是行业参考链接：

|

| 常见问题 | 理想的常见问题检查表是根据历史项目记录、编程语言或项目类型总结的。如果没有足够的项目数据来生成该列表，可以参考 CWE 或 OWASP。以下是行业参考链接：

|

| 特定安全问题（Struts，反序列化） | 目标是专注于某一特定安全问题的安全审查。在某些情况下，我们可能会发现这些类型的安全审查很有帮助。例如，Java Struts 框架正在遭受攻击，团队可能希望检查与 Struts 相关的实现是否存在漏洞。项目 A 中已经发现了一个重大安全问题，组织希望了解其他项目是否也有类似的安全问题。检查特定安全问题的驱动因素可能来自最近发布的 CVE、重大安全事件新闻，或是客户报告的安全问题，我们希望检查所有其他项目是否存在同样的问题。以下是这一类别的示例列表：

  • Struts 安全问题。

  • Java 反序列化安全问题。

  • REST API 安全。

|

常见安全问题

一个常见问题的清单对项目团队在进行安全代码审查时非常有效。为了构建一个常见的安全问题清单，建议参考 CWE Top 25。安全团队和项目团队可以基于历史项目数据，以 CWE Top 25 为基础，结合公司内部的安全问题，共同达成关于前五大安全问题的共识。

总结公司内部的主要安全问题至关重要，因为 CWE Top 25 可能不完全适用于公司内部项目，这与业务背景、技术栈和实现方式密切相关。一旦识别出公司内部的安全问题列表，应该同时列出相应的缓解方法。请参阅下表，了解它可能的样式。表格的目的是给出一个示例，您也可以根据自己的组织定义适合的列表，而不是直接复制 CWE Top 25 中的全部内容。请注意，以下仅为示例，而非全面列表。让我们看看这个表格：

主要问题示例 主要安全问题的缓解方法
CWE-89 SQL 注入 通过工具可以有效检测特定源代码模式中的 SQL 注入问题。重点检查那些没有使用预编译语句的 SQL 语句，或者在 iBATIS 框架中使用`
--- ---
作为 SQL 参数的情况。
CWE-78 操作系统命令注入 由于代码扫描工具可以检测操作系统命令注入问题，团队决定列出可能导致命令注入的高风险 API，并开发一个工具进行源代码搜索。

| CWE-120 缓冲区溢出 | 根据历史记录，缓冲区溢出问题曾是常见问题之一。团队进一步识别了可能导致缓冲区溢出的常见 API。例如，列出了 C/C++相关的 API：

  • strcpy, strncpy_s, strncpy

  • strncat, strcat

  • sprint, snprintf

  • memcpy

  • memmove_s, memset, memset_s

  • scanf_s, gets, vscanf

|

| CWE-79 跨站脚本攻击 (XSS) | 团队还发现 XSS 是最主要的问题之一。为了审查 XSS 问题，团队决定列出所有可能导致 XSS 的 API。以下是一些例子——在 JS/JSP/HTML 中，查找以下相关函数：

  • document.location

  • document.URL

  • document.write

  • document.open

  • eval

在 Java 中，查看以下 API 的参数：

  • Request.getParameter

  • innerHTML.innerText

  • getAttribute

  • getHeader

  • getServerName

|

| CWE-306 关键功能缺少认证 | 特定 URL 或资源缺少认证是一个常见的安全问题，且难以通过任何工具检测。哪些 URL 可以在没有认证的情况下被访问，哪些 URL 需要认证，通常与业务逻辑紧密相关。此类安全问题也很难通过白盒源代码审查识别。基于历史项目记录，以下是 Java 源代码模式的一些提示：

  • 使用部分 URL 匹配 API 来确定是否需要认证，如 StartsWith 和 EndsWith

  • 验证之前没有进行路径规范化

  • 验证之前没有进行数据标准化

|

安全编码模式和关键字

基于源代码关键字或特定模式的搜索技术的目标不是替代任何其他自动化代码扫描工具。它是通过搜索潜在的高风险字符串来支持白盒审查和自动化代码扫描工具。安全团队可以准备或定义一组可能导致安全问题的关键字或正则表达式字符串。一旦项目团队拥有一组搜索字符串，可以使用任何搜索工具（如 GREP）进行搜索，并分析搜索结果。这种搜索可以在部分源代码中进行，并且与编程语言无关。只要我们有明确定义的搜索字符串，搜索特定问题就变得非常简单。

下图展示了这种类型的白盒审查技术的一般过程：

下面是如何根据特定模式或关键字搜索代码潜在安全风险的示例。你也可以参考 OWASP 代码审查指南 2.0，附录——爬虫 代码 获取更多信息以及其他编程语言。

请查看以下表格：

安全问题类别 Java 代码模式/关键字示例
命令注入 Runtime.exec, ProcessBuilder
缓冲区溢出风险 strcpy, strcat, sprint, sscanf, vscanf, gets
XML 注入 SAXParser, DocumentBuilderFactory, BeanReader, XmlReader, DOMParser, SAXReader, XMLInputFactory
敏感信息

  • 后门、密码、管理员、root

  • 加密、getInstance

  • MessageDigest.getInstance

  • 编码、加密、共享密钥、令牌

  • URL、电子邮件、IP 地址

|

HTTPS 中间人攻击 (MITM)

  • ALLOW_ALL_HOSTNAME_VERIFIER

  • X509Certificate, X509TrustManager

  • getAcceptedIssuers

|

不安全的加密技术

  • RC4, SSL, AES, DEC, ECB, MD5, SHA1

  • Java.util.Random

  • Cipher.newInstance("DES

  • Cipher.getInstance("ECB

|

XSS

  • document.location, document.URL

  • document.referrer, document.write, document.print

  • document.body.innerHTML

  • window.location, window.execScript

  • window.setTimeout, window.open

  • request.getParameter

|

反序列化问题

  • XMLDecoder

  • XStream

  • readObject, readResolve, readExternal

|

用户数据输入

  • getParameter, getQueryString, getRequest

  • getCookies, getInputStream, getReader

  • getInputSteam, getMethod, getReader

  • getRemoteUser, getServerName

|

以下是此类别中可以进行源代码扫描的安全代码扫描工具，基于正则表达式模式。通常，这些工具还会具有预定义的易受攻击的源代码模式和安全签名。建议审查这些安全签名，并根据您的项目环境定制这些正则表达式或字符串。请查看下表：

工具 参考资料
drek

|

Graudit

|

VisualCodeGrepper (VCG)

|

| CRASS Grep IT | 推荐使用此工具，因为它无需任何依赖，仅需要一个 shell 脚本即可执行。

|

这些都是静态代码分析工具，使用类似 GREP 的搜索方法来识别易受攻击的源代码。这种源代码审查方法对于禁止的 API、不安全的 API、弱加密算法或硬编码的秘密最为有效。它灵活性高，因此可以扫描部分源代码，无需完整构建项目，并且可以用于扫描多种编程语言，只要安全代码模式签名已正确定义。

案例研究 – Java Struts 安全审查

苏珊，作为一家软件公司的 CTO，寻求安全团队关于 Struts 的建议。苏珊理解，Struts 的安全审查不仅需要 Struts 的领域知识，还需要特定于 Struts 的威胁知识。为了识别 Struts 的安全性，需要自动化代码扫描、白盒审查、安全配置审查，以及带有恶意负载的黑盒测试，安全团队提出了以下结合行业实践资源的安全审查方法。此案例研究的目的是展示如何进行针对 Struts 安全性的白盒审查，而非提供全面的 Struts 安全审查指南。

苏珊和安全团队讨论了可能的审查方法，并为项目团队提供了一个 Struts 安全检查清单，作为代码审查的基准。

Struts 安全审查方法

下表给出了 Java Struts 框架关键审查方法的示例：

Struts 安全审查方法 目标和参考资料
Struts 安全检查 安全检查清单供开发人员用于执行 Struts 的安全实施和审查。Struts 官方网站提供了一个很好的参考。可以查看链接：struts.apache.org/security/。
Struts 潜在风险字符串 除了代码扫描外，我们还可以搜索可能导致 Struts 安全问题的特定字符串。对于 Struts 的安全性，我们更关注安全配置，struts.xml，而不是源代码。
Struts 漏洞利用脚本 为了测试 Struts 的每个漏洞，建议参考已发布的漏洞利用脚本。参考：www.exploit-db.com/search/?action=search&q=struts。
OWASP 依赖项 大多数已知的 Struts 漏洞在最新版本中已修复。OWASP 依赖项扫描工具可以帮助检测旧版本 Struts 的使用。查看链接：www.owasp.org/index.php/OWASP_Dependency_Check。

Struts 安全检查清单

安全检查清单将提醒团队在代码审查过程中应关注的重点。具体来说，对于 Struts 框架的安全性，Struts 安全实施检查清单总结了以下几点。Struts 安全参考资料的链接：struts.apache.org/security/：

  • 配置浏览器插件应仅在开发环境中使用

  • 按安全级别将动作分组到一个命名空间中

  • 将所有 JSP 文件放置在WEB-INF中，以避免 JSP 文件的直接访问

  • 禁用开发模式`devMode`

  • 在生产环境中减少日志记录级别

  • UTF-8 编码

  • 验证getText()的输入数据参数

  • 不要直接使用原始的${} EL表达式来处理输入参数

  • 禁用静态方法访问

  • 禁用动态方法调用

在struts.xml和 API 中搜索 Struts 安全字符串

这份直接与 Struts 安全问题相关的关键字列表将帮助我们使用搜索工具（如 drek 或 Graudit）定位并识别问题；请看以下表格：

Struts 安全性 粗体关键字搜索
开发模式 struts.devMode。审查提示：建议值应在struts.xml中设置为 false。
动态方法调用 struts.enable.DynamicMethodInvocation。审查提示：建议值应在struts.xml中设置为 false。
OGNL 静态方法访问 struts.ognl.allowStaticMethodAccess。审查提示：建议值应在struts.xml中设置为 false。
文件上传 Allowedtypes.maximumSize.allowedExtensions.审查提示：这些参数应在struts.xml中定义，以限制文件上传的类型、大小和扩展名。请查看链接 struts.apache.org/core-developers/file-upload.html。
数据输入注入 findValue，getValue，setValue。审查提示：审查这些 API 的外部输入参数，以避免struts.xml中的 OGNL 注入攻击。
验证 validate。审查提示：验证的安全值应在struts.xml中设置为 true。
数据输入注入 request.getParameter。审查提示：审查这些 API 的外部输入参数，以避免潜在的注入攻击。
类加载器操作 getClass。审查提示：审查这些 API 的外部输入参数，以避免潜在的注入攻击。

总结

我们讨论了白盒审查的实践。为了进行有效的白盒审查，需要一些准备和输入，如源代码、威胁建模分析、架构和设计文档、自动化静态代码分析报告、配置文件和通信接口列表。

进行白盒源代码审查有几种方法。我们可以使用 doxygen 和 naturaldocs 从源代码生成文档和流程图。这将帮助我们全面了解源代码。然后，我们识别高风险模块进行手动代码检查。高风险模块是那些处理敏感信息、安全控制或管理功能的模块。

在白盒审查过程中，必须建立一个检查清单。这包括一些推荐的行业实践，如 OWASP 安全编码实践、OWASP 代码审查指南、CWE Top 25 和 OWASP Top 10。基于这些实践，建议组织可以构建自己最常见的安全问题及其缓解方法。

然后，最后但同样重要的是，我们讨论了安全编码模式和关键字。我们列出了针对安全问题的一些常见 Java 代码模式，并介绍了一些工具，如 drek、Graudit、VCG 和 CRASS Grep IT。

案例研究给出了一个特定于 Struts 框架的安全代码审查示例。在该案例中，团队应用了一些审查方法，并且定义了一个与 Struts 相关的安全检查清单。

在下一章节中，我们将探讨每个安全测试领域中的更多安全测试工具包。

问题

  1. 以下哪项不是白盒审查的输入？

    1. 源代码

    2. 威胁建模文档

    3. 自动化静态代码分析结果

    4. 杀毒扫描结果

  2. doxygen 和 naturaldocs 工具的用途是什么？

    1. 直接从源代码生成文档

    2. 静态代码扫描

    3. 动态代码扫描

    4. 逆向工程

  3. 以下哪项是高风险模块？

    1. 认证

    2. 授权

    3. API 接口

    4. 以上所有

  4. 以下哪个 API 与缓冲区溢出无关？

    1. strcpy

    2. strncat

    3. memcpy

    4. fwrite

  5. 什么原因可能导致认证缺失？

    1. 使用部分 URL 匹配 API 来确定是否需要认证，如 StartsWith 和 EndsWith

    2. 在验证之前没有进行路径标准化

    3. 在验证之前没有进行数据规范化

    4. 以上所有

深入阅读

参考以下链接了解更多信息：

第十二章：安全测试工具包

在上一章中，我们讨论了白盒测试的技巧。本章将介绍一套常见的（但不是全面的）安全测试工具。涉及安全测试的网络主要包括网页和移动连接、配置、通信、第三方组件以及敏感信息。我们将逐一探讨每个元素的测试技巧和工具。此外，我们还将学习如何自动执行这些工具，以及如何将它们作为集成到持续集成中的工具。

本章将涵盖以下内容：

  • 通用安全测试工具包

  • 自动化测试标准

  • 基于行为的安全测试框架

  • Android 安全测试

  • 安全基础设施配置

  • Docker 安全扫描

  • 集成安全工具

通用安全测试工具包

提供安全测试工具包的目的是让项目团队了解可用的工具，并根据业务应用场景判断并应用他们认为合适的工具。安全测试工具有很多种。一些组织可能会为所有项目定义一个通用的测试工具包，并根据特定领域（如自动化、基础设施、Docker、BDD 等）推荐其他安全测试工具：

有许多种 Linux 安全发行版，它们已经预装并配置了安全工具。Kali、BlackArch 和 PentestBox 是常见的 Linux 安全发行版。推荐使用 PenetestBox，因为它不需要 Linux 虚拟机环境来执行 Linux 实用工具，并且可以原生在 Windows 上执行。PenetestBox 也包含许多安全工具，就像 Kali Linux 一样。关于每个工具的更多信息，请访问以下链接：

由于 Kali 或 BlackArch Linux 中可能有数百个安全工具，要求安全测试团队使用所有工具进行安全测试可能不可行。建议你熟悉一些关键的常见安全工具。

以下表格显示了推荐的最小安全测试工具集（这里只列出了开源或免费工具）：

正在进行安全检查的区域 常见的开源安全工具

| 白盒审查 | GraudIT 或 GREP-IT 这些工具推荐使用，因为它们不需要完整的可构建源代码来识别不同编程语言的安全问题：

|

Web BurpSuite, OWASP ZAP, Vega, SQLmap, Arachni
漏洞 Nessus, OpenVAS, OpenSCAP, NMAP
网络 NMAP, WireShark, TCPDump, Hping, SSLScan, SSLyze, masscan

自动化测试标准

我们希望大多数基本和显而易见的网页安全测试案例能够自动执行，而人工测试则集中在更深入的安全问题审查上。自动化网页安全测试的目标是将安全测试工具与持续集成框架（如 Jenkins）集成。每当构建提交时，可以自动触发网页安全测试。为了能够将网页安全测试工具与 Jenkins 集成，我们需要考虑几个关键标准：

  • 命令行控制台：大多数安全测试工具提供命令行控制台或 GUI 接口来操作安全测试程序。理想情况下，工具应提供这两种接口。命令行控制台可用于 Jenkins 触发安全测试的执行，而 GUI 则可以辅助人工测试。从自动化测试的角度看，命令行接口（CLI）是与 Jenkins 集成的最低要求。CLI 接口还帮助我们与单元测试框架或 BDD 框架进行集成。

  • API 接口：网页安全测试可以在独立攻击者模式或代理模式下执行。API 接口将允许我们在运行时通过编程方式与测试工具进行交互。例如，OWASP ZAP 提供了一个 REST API，可以使用 Python 自动化所有操作，也提供了 ZAP CLI 以从命令行与 ZAP 进行交互。

  • 输出格式：大多数网页安全测试工具提供不同种类的报告格式，如 HTML、PDF、XML、CSV、JSON 或控制台输出。如果我们希望将测试结果汇总在一起，CSV、JSON 和 XML 是基本的格式。由于不同的安全工具和每日报告中大量的结果，建议使用集成安全测试工具，如 OWASP DefectDojo，将所有测试结果汇总在一个仪表盘中（这个选项稍后会讨论）。此外，一些工具可能提供 Jenkins 插件，帮助您将结果输出到 Jenkins 管理控制台。

基于这些标准，建议用于自动化的网页安全测试工具总结在下表中。OWASP ZAP、Arachni 和 W3af 是三款开源网页安全测试工具，提供 CLI、API 和 Web GUI 接口。如果您需要轻量级的命令行工具，Nikto 和 Wapiti 也是不错的选择。由于每种工具的误报率，我们建议额外使用一种工具进行扫描。

请注意，Web 安全自动化测试无法完成所有 Web 安全任务。某些测试场景仍然需要人工安全测试人员来引导工具并进行进一步验证，如身份验证、网页授权、与业务逻辑相关的测试和多次订单提交。下表显示了这些工具及其特点：

Web GUI CLI REST API
OWASP ZAP Yes ZAP CLI ZAP API
Arachni Yes Yes Yes（它还提供 Ruby 库。）
W3af Yes Yes Yes
Nikto n/a Yes n/a
Wapiti n/a Yes n/a

行为驱动安全测试框架

BDD 安全测试非常适合在您的安全测试报告需要与外部供应商共享，或者甚至在内部跨团队沟通时使用，以了解正在执行哪些安全测试用例。此外，BDD 安全测试还可以帮助您将各种安全测试工具整合起来，并根据框架汇总测试报告。

让我们通过一个简单的例子来了解什么是行为驱动的安全测试。在行为驱动的安全测试框架下，安全测试脚本是用人类可读的语言编写的测试用例。它使得安全测试用例和测试结果能够被非安全专业人员轻松理解。以下是这个人类可读脚本的一个例子：

场景：攻击者可能会执行系统命令来获取有价值的信息。 前提条件：假设操作系统中有 "ping" 命令行二进制文件。 当我发起一个 "ping" 攻击时： "Ping 127.0.0.1" 那么它应该通过正则表达式： "<1ms TTL=128"

上述示例是基于 GauntIT 测试脚本重新编辑的版本。您还可以参考github.com/gauntIT/gauntIt/tree/master/examples/获取更多定义安全测试用例的示例。

在 BDD 安全测试框架中有三个开源工具。如果您熟悉 Java BDD cucumber，那么 BDD 安全将是您的最佳选择。如果您想使用 Python 与 BDD 框架，可以参考 MITTN。GauntIT 是独立于编程语言的，可以通过定义正则表达式轻松扩展以执行任何工具并验证结果。GauntIT 使安全测试人员可以专注于测试脚本的定义，适合那些对 Java 或 Python 知之甚少的测试人员。BDD 安全框架及其特色工具列在以下表格中：

BDD 安全框架 默认包含的安全工具

| BDD 安全 | OWASP ZAP、SSLyze、NessusBDD 安全基于 Java 和 Cucumber。

|

| MITTN | BurpSuite、SSlyze 和 Radamsa API fuzzingMITTN 基于 Python 和 Behave。 |

|

| GauntIT | CURL, NMAP, SSLyze, SQLmap, Garmr, heartbleed, dirb, Arachni

|

Android 安全测试

Android 安全测试需要使用 APK 文件进行逆向工程分析，使用 Manifest 进行权限分析，以及使用意图、服务、广播和内容提供者进行内部组件分析。通常，在进行 Android 安全测试时，以下工具被认为是常用的测试工具：

工具 描述
ApkTool ApkTool 用于对 Android APK 文件进行逆向工程。
ByteCode View ByteCode View 是一个 Java 字节码查看器和 GUI Java 反编译器。
Dex2JAR Dex2JAR 将 DEX 文件转换为 CLASS 文件。
JADX JADX 将 DEX 文件转换为 Java 反编译器。
JD-GUI JD-GUI 是一个 GUI 查看器，用于读取 CLASS 文件的源代码。
Drozer Drozer 是一个交互式安全和攻击框架，用于 Android 应用程序。
Baksmali Baksmali 是一个 DEX 格式的汇编器/反汇编器。
AndroBugs AndroBugs 接受 APK 文件作为输入，并执行 APK 安全漏洞扫描。
AndroGuard AndroGuard 是一个 Python 框架，能够执行 APK 的逆向工程和恶意软件分析。
QARK Quick Android Review Kit（QARK）的工作原理类似于 AndroBugs，能够检测 APK 文件中的安全漏洞。
AppMon AppMon 可以监控 iOS 和 Android 应用的 API 调用。

单独安装和配置这些工具可能非常耗时，因此建议使用以下工具包，这些工具包已预安装了大多数 Android 安全测试工具：

工具包 描述

| AndroL4b | AndroL4b 是一个基于 Ubuntu 的虚拟机，不仅包括安全测试工具，还包括供实践使用的易受攻击 APK 实验室。 |

|

| Appie | Appie 是一个 Android 测试工具包门户，可以在 Windows 上运行，无需任何安装和虚拟机。 |

|

| PentestBox | PentestBox 类似于 Appie，但还包括许多与 Android 无关的其他安全测试工具。 |

|

最后，如果你希望进行完全自动化的 APK 和 iOS 安全分析，并且可以通过拖放 APK 文件到 Android 安全分析平台上使用，那么 MobSF（移动安全框架）就是你需要的工具，具体见以下截图： 来源: github.com/MobSF/Mobile-Security-Framework-MobSF/

MobSF/Mobile-Security-Framework-MobSF 采用 GNU 通用公共许可证 v3.0 授权。

以下截图展示了 MobSF 的基本使用方法。

以下截图显示了 Manifest 分析和代码分析的 MobSF 安全评估结果。

源代码：https://github.com/MobSF/Mobile-Security-Framework-MobSF

确保基础设施配置安全

确保基础架构配置的安全对于确保基础架构配置和系统硬化符合行业安全最佳实践（如 CIS 基准、PCI-DSS 以及国家检查清单计划（NCP））至关重要。如果 DevOps 团队已应用基础设施工具，如 Chef 或 Puppet，强烈建议您在这些工具之上定义安全配置，以实现基础设施安全即代码的目标。这有助于将基础设施安全从运维阶段转移到开发阶段。Inspec、Hardening Framework 和 ServerSpec 工具用于检查基础设施安全配置。您可以在以下链接了解更多信息：

对于未使用配置管理工具（Puppet、Chef、Ansible 或 SaltStack）部署的基础设施环境，建议使用以下扫描工具：

这些基础设施安全配置审查工具将减少运维团队和安全团队的工作量。运维团队可以在服务部署之前应用这些工具，并且可能会定期检查生产环境。开发和测试团队可以使用这些工具了解是否缺少任何安全配置或配置不正确。

OpenSCAP 的扫描结果示例，请访问 www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html。

Docker 安全扫描

Docker 技术广泛用于软件部署和云基础设施。针对 Docker 的安全测试，Docker Bench 定义了几项 Docker 容器部署的安全最佳实践和配置。《CIS Docker 社区版基准》定义了有关 Docker 主机、守护程序、容器镜像和容器运行时的安全建议。总的来说，有三种 Docker 安全工具执行三种不同的功能：

  • 基于 CIS 的 Docker 安全最佳实践扫描（Docker Bench、Actuary）

  • 扫描已知的常见漏洞和曝光（CVEs）（Claire、Anchor Engine）

  • 运行时威胁分析（Falco、Dagda）

以下是用于 Docker 安全性的开源安全测试工具：

Docker 安全工具 目的与参考

| Docker Bench | Docker Bench 是一个自动化脚本，用于检查 Docker 安全最佳实践的合规性。扫描规则基于 CIS Docker 安全基准。

|

| Actuary | Actuary 的工作原理类似于 Docker Bench。此外，Actuary 可以根据 Docker 安全社区定义的安全配置文件进行扫描。

|

Clair Clair 是一个容器镜像安全静态分析器，用于 CVE（公共漏洞与暴露）。 Clair: github.com/coreos/clair

| Anchor EngineAnchor Cloud | Anchor Cloud 和 Anchor Engine 扫描 Docker 镜像中的 CVE（公共漏洞与暴露）。Anchor Engine 是一个托管工具，Anchor Cloud 是一个基于云的工具。

|

| Falco | Falco 是一个 Docker 容器运行时安全工具，能够检测异常活动。

|

| Dagda | Dagda 是一个集成的 Docker 安全工具，提供运行时异常活动检测（Sysdig Falco）、漏洞（CVE）分析（OWASP 依赖检查、Retire.JS）以及恶意软件扫描（CalmAV）。

|

集成安全工具

由于有许多安全测试工具，我们可能希望将测试结果集成到一个仪表板中，或通过统一的界面执行这些工具。如果你在寻找这样的集成安全测试管理工具，以下是一些开源且免费的工具可供参考：

工具 默认包含的工具

| JackHammer | JackHammer 由 Ola 提供，是一个集成的安全测试工具。它为您提供一个仪表板，整合所有的测试结果。其主要区别在于 JackHammer 包含移动应用安全扫描和源代码静态分析工具。支持的开源安全扫描工具包括 Brakeman、Bundler-Audit、Dawnscanner、FindSecurityBugs、PMD、RetireJS、Arachni、Trufflehog、Androbugs、Androguard 和 NMAP。以下截图展示了其集成界面的典型示例。

|

| Faraday | Faraday 是一个集成的渗透测试环境，提供了一个管理所有测试结果的仪表板。它集成了超过 50 个安全工具。

|

| Mozilla Minion | Mozilla Minion 也是一款集成的安全测试工具，默认包含以下插件：

  • ZAP

  • Nmap

  • Skipfish

  • SSLScan

你可以在 github.com/mozilla/minion/ 找到 Mozilla Minion。 |

| 渗透测试工具包 | 渗透测试工具包为许多 Linux 扫描工具提供了统一的 Web 界面，例如 nmap、nikto、WhatWeb、SSLyze、fping、URLCrazy、lynx、mtr、nbtscan、automater 和 shellinabox。

|

| Seccubus | 使用 Seccubus 的主要优势在于它能够与各种漏洞扫描器的测试结果集成，并且还可以比较每次扫描之间的差异。它包括以下扫描器：

  • Nessus

  • OpenVAS

  • NMAP

  • Nikto

  • Medusa

  • SSLyze

  • SSL Labs

  • TestSSL.sh

  • SkipFish

  • ZAP

你可以在 github.com/schubergphilis/Seccubus 找到 Seccubus。  |

| OWTF | 进攻性 Web 测试框架 (OWTF) 是一个集成的安全测试标准，符合 OWASP 测试指南，并包含 PTES 和 NIST 工具。

|

RapidScan RapidScan 是一款多功能工具，包含 Web 漏洞扫描器。它包含的安全扫描工具包括 nmap、dnsrecon、uniscan、sslyze、fierce、theharvester、golismero。
DefectDojo OWASP DefectDojo 是一款安全工具，可以将各种安全测试工具的输出导入并汇总到一个管理仪表板中。DefectDojo: github.com/DefectDojo/django-DefectDojo

总结

在本章中，我们学习了安全测试工具包。根据需要测试的元素，有 Kali Linux、BlackArch 和 PentestBox，它们是提供通用安全测试工具包的 Linux 安全发行版。由于工具种类繁多，我们建议了一套最小化的安全工具集，以覆盖白盒审查、网络连接、漏洞和网络安全。

我们还展示了安全自动化工具的关键因素，并比较了一些 Web 安全工具在支持 CLI 和 REST API 接口方面的能力。我们还介绍了 BDD 安全框架，它支持自动化框架。我们考察了 BDD Security、MITTN 和 GauntIT。

还讨论了其他一些安全测试工具。对于 Android 安全测试，推荐使用 MobSF（移动安全框架）作为一个快速获胜、完全自动化的分析平台。对于基础设施安全，我们介绍了 Lynis 安全审计、OpenSCAP 或 CIS 基准安全扫描工具，用于检测不安全的配置。对于 Docker 安全，有三类安全工具——即 CIS 安全配置最佳实践、已知漏洞扫描和运行时威胁分析。最后，我们介绍了集成安全工具，它们可以帮助您整合和合并所有的测试结果。

在下一章中，我们将讨论与持续集成结合的安全自动化。

问题

  1. 以下哪个不是用于安全测试的 Linux 发行版？ 答案：d

    1. Kali Linux

    2. BlackArch

    3. PentestBox

    4. OSSEC

  2. OWASP ZAP、Vega 和 Arachni 工具用于以下哪种安全测试？

    1. Web 安全

    2. 网络安全

    3. 入侵检测

    4. 完整性监控

  3. 以下哪个工具用于漏洞扫描？

    1. WireShark

    2. OpenVAS

    3. TCPDump

    4. Hping

  4. 以下哪个不是自动化测试的最低标准？

    1. GUI 界面

    2. CLI 接口

    3. API 接口

    4. 输出格式

  5. 使用 BDD 安全的好处是什么？

    1. 与所有工具的集成

    2. 整合测试结果

    3. 团队之间沟通容易

    4. 以上所有

  6. 以下哪个不是用于 Docker 安全的？

    1. 基于 CIS 的 Docker 安全最佳实践扫描（Docker Bench，Actuary）

    2. Appie

    3. 扫描已知的 CVE。（Claire，Anchor Engine）

    4. 运行时威胁分析。（Falco，Dagda）

  7. 以下哪个主要不是专注于基础设施安全？

    1. Inspec

    2. 加固框架

    3. Serverspec

    4. PentestBox

深入阅读

欲了解更多信息，请访问以下网址：

第十三章：CI 管道中的安全自动化

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

本章将涵盖以下内容：

  • 持续集成中的安全性

  • 开发阶段的安全实践

  • 主动/代理模式下的 Web 测试

  • Web 自动化测试技巧

  • Jenkins 中的安全自动化

持续集成中的安全性

开发团队的日常活动包括编码、编译/构建、测试和部署。我们的目标是将安全自动化实践融入到这些活动中。在编码阶段，开发团队可以使用 IDE 插件进行安全源代码分析。在构建阶段，我们扫描安全强化的编译选项、依赖组件的已知漏洞，以及整个项目的安全源代码。

一旦构建完成并安装到预发布环境中，将进行更全面的安全扫描，例如使用 OWASP ZAP 进行动态 Web 安全测试、基础设施配置安全性和安全通信协议。在生产部署阶段，也会定期进行安全扫描，并且更多关注于安全监控，而非源代码或动态 Web 安全测试。

以下图表展示了每个阶段的安全实践，即编码、构建、测试和生产部署：

开发阶段的安全实践

开发团队的安全实践包括安全编码和安全构建交付。对于安全编码，我们可以让 IDE 插件进行代码扫描，或者要求进行安全单元测试并运行整个项目的静态代码扫描。对于安全构建交付，我们需要确保编译器选项正确配置，并审查所有依赖组件的已知漏洞。以下图表展示了我们可以在开发阶段规划的整体安全实践。接下来的章节中，我们将介绍一些用于这些安全活动的开源安全工具和实践：

自动化代码审查的 IDE 插件

使用 IDE 插件进行自动化安全代码审查的主要优势是，这些工具可以在编码阶段提供修复的有用建议，类似于拼写检查器的工作方式。这将大大减少代码审查的工作量，并能发现黑盒测试无法检测的安全缺陷。缺点是，这种静态代码扫描可能会引入一些恼人的误报，开发团队可能忽视或忘记使用 IDE 插件进行静态安全代码分析。

以下表格展示了一些可以帮助开发人员检测安全和编码错误的开源 IDE 插件。这里只列出了开源工具，尽管也有许多优秀的商业工具可供选择。

推荐使用 DevSkim，不仅因为它支持多种语言，还因为它支持多种 IDE，如 VS、VS Code、Sublime Text 等。此外，编写 DevSkim 扫描规则也很简单，采用 JSON 格式。更多信息请参见 github.com/Microsoft/DevSkim/wiki/Sample-Rule：

工具 支持的编程语言 参考
FindSecBugs Java

|

PMD Java

|

DevSkim 支持所有语言

|

虽然我们希望代码审查能够通过工具自动完成，但有时我们可能需要执行团队同侪代码审查，并且需要一个团队协作平台来评论或讨论代码质量。对于团队代码审查平台，推荐以下开源工具：

  • Gerrit: 它提供了一个基于 Web 的 UI 代码审查工具，适用于 GIT 源代码。www.gerritcodereview.com

  • Phabricator: Phabricator 是一个开源工具，集成了代码审查工具和缺陷跟踪功能。www.phacility.com

对于同侪代码审查实践，建议创建一个代码审查检查表，或者参考 OWASP 随机书或 OWASP SCP（安全编码实践）：

静态代码分析

静态代码扫描分析是在 CI 框架中（如 Jenkins 或 Travis）进行源代码级别安全检查的一种有效方式。开发团队可能不会完全应用 IDE 代码扫描插件来进行安全代码分析。在这种情况下，将静态代码分析集成到 CI 框架中有助于确保所有项目都进行安全代码扫描。换句话说，静态安全代码分析工具与 Jenkins 的集成是开发阶段的必要步骤。

以下表格列出了部分静态代码分析工具。你还可以参考第八章，安全编码最佳实践，以获取其他推荐工具：

工具 支持的编程语言 特点
Grep Rough Audit 所有 这是一种简单的脚本，通过使用 GREP 和正则表达式来检测源代码中的安全漏洞，适用于常见的安全模式。
Flawfinder C/C+ 这是一种简单的工具，用于扫描 C/C++ 源代码中的安全问题。
Brakeman Ruby on Rails Brakeman 主要关注 Ruby 代码中的安全问题。
SonarQube 所有 SonarQube 是一款源代码质量分析工具。
GREP IT 所有 这是一种 Linux shell 脚本，可以进行代码扫描。无需其他依赖项。
NodeJsScan NodeJS 它主要用于扫描 NodeJS 中的安全问题。
ScanJS JavaScript ScanJS 可以识别使用高风险的 JavaScript API，如 eval、execScript、document.write 等。
Bandit Python 它扫描 Python 源代码中的安全问题。

安全编译器配置

安全编译器配置意味着你可以启用针对内存损坏问题的编译时防御，防止执行意外的攻击代码。这些缓解措施可能包括 RELRO、地址空间布局随机化（ASLR）、不可执行（NX）、栈金丝雀和位置无关可执行文件（PIE）。这些安全编译器配置应该在开发阶段完成。

以下表格显示了一些可用的缓解措施：

缓解措施 Visual Studio 编译器选项
栈随机化 /DyNAMICBASE
缓冲区溢出防护 /GS
不可执行（NX） /NXCOMPAT
异常处理器保护 /SAFESEH

以下表格显示了 GCC 和 G++ 编译器驱动程序的常见构建标志：

缓解措施 GCC 编译器和链接器标志
地址 -fPIC
不可执行栈 -Wl, -z, noexecstack
GOT 保护 -Wl, -z, relro
栈保护 -fstack-protector
ASLR Echo 1 > /proc/sys/kernel/randomize_va_space

以下工具可用于验证正确的安全编译器配置：

安全编译器配置是缓冲区溢出安全缓解的低挂果实。这种安全实践常常被开发团队忽视。确保在编译时进行安全配置，并在测试阶段验证二进制包。

依赖项检查

第三方组件或依赖项中的已知漏洞被认为是 OWASP 十大使用已知漏洞组件名单的一部分。这些已知的漏洞组件应在开发早期阶段就进行识别。建议你不仅在开发阶段进行依赖组件的漏洞扫描，还应定期在生产阶段进行漏洞扫描。

以下工具可以帮助你扫描脆弱的组件：

工具 支持的语言
OWASP 依赖性检查 OWASP 依赖性检查扫描 Java、Ruby、PHP、JavaScript、Python 和 .NET 中的依赖性漏洞。
Retire.JS Retire.JS 扫描脆弱的 JavaScript 库。
Snyk Snyk 扫描 JS、Ruby、Python 和 Java 的漏洞。

网站测试的主动/代理模式

动态网站测试工具，如 OWASP ZAP、Arachni、Wapiti 和 W3af，通常提供两种安全测试模式：主动模式和代理模式。主动模式意味着你启动测试工具，直接对 web 服务进行安全测试。测试者可以决定对目标 web 服务进行何种类型的安全测试（如 XSS 或 SQLi）。然而，这种测试的一个主要缺点是你可能会错过某些需要权限的网页，或者错过需要特定访问顺序的网页。以下图示展示了主动模式的工作方式：

主动模式

代理模式，也可以理解为 MITM（中间人攻击），意味着安全测试工具以代理的形式运行，拦截浏览器客户端和目标 web 服务之间的流量。在代理模式下，安全测试工具 OWASP ZAP 将基于拦截到的流量检测潜在的安全漏洞问题。

以 OWASP ZAP 为例。假设我们希望将 OWASP ZAP 以代理模式执行。这将需要以下配置：

  1. 启动 OWASP ZAP 代理模式。

  2. 将客户端代理配置为 OWASP ZAP 代理。

  3. 在 OWASP ZAP 代理中安装 CA 证书。

代理模式对于项目团队而言效果最佳，尤其是在他们已设置了功能自动化（如 Selenium 或 Robot Framework）的情况下。Selenium 或 Robot Framework 将帮助引导 OWASP ZAP 穿越网页，特别是那些需要权限的页面：

代理模式

在实际操作中，建议你使用多种工具以两种模式执行网站安全测试。这是因为每个安全工具可能在安全攻击和检测引擎方面都有自己的优缺点。例如，OWASP ZAP 和 Arachni 可能在主动扫描和蜘蛛模式下运行。此外，你还可以使用 Selenium 自动化客户端引导 Vega 或 OWASP ZAP 访问需要身份验证的页面，并对指定的 web 服务进行更深入的模糊测试。请参阅以下图示了解测试场景：

Web 自动化测试提示

只需安装并启动 OWASP ZAP。主动和被动扫描只能为我们提供公用 Web 服务的初步测试结果。以下表格包含一些建议的提示，以提高 Web 自动化测试工具（如 ZAP 或 Arachni）的测试效率和效果：

测试提示 描述

| 集成 | 要进行自动化集成，尝试了解 Web 安全工具提供以下内容：

  • 无头执行模式

  • 命令行界面

  • REST API

  • Jenkins 插件（只要提供了前述工具之一，这可能是可选的）

例如，OWASP ZAP（github.com/Grunny/zap-cli/）提供了 ZAP CLI 接口，这也有助于简化集成。 |

| 授权测试 | 测试每个 Web 服务的访客、用户和管理员权限，需要适当的预定义导航工作流。测试场景可能包括以下内容：

  • 会话固定、重用、过期

  • 用户、角色、访客、管理员权限

  • 登录、登出和重新认证行为

安全测试有两种主要方法：

  • 使用 Selenium 或 Robot Framework 进行身份验证，然后使用 OWASP ZAP 检测安全问题

  • 在 OWASP ZAP 或 Arachni 中预配置需要身份验证的页面或 URL

|

扫描范围 动态 Web 测试可能需要很长时间。正确配置扫描范围，以包括或排除正在测试的 URL。仅在应用程序通过冒烟测试后，才进行完整扫描。可以安排完整扫描在夜间进行。

| API 模糊测试 | 网络服务可能提供多个 REST JSON 或 SOAP XML API。建议您获取完整的 API 列表和规范。对每个 API 的参数进行模糊测试。一旦完成，使用 OWASP ZAP 或 Arachni 的代理模式来拦截所有 API 调用。然后，调查这些 API 调用，以进一步使用有效载荷中的参数进行模糊测试。对于模糊安全有效载荷测试，请考虑将参数的值替换为 fuzzDB 中的以下数据：

Radamsa 可以用来自动生成模糊测试数据：

|

| 业务逻辑 | 某些 Web UI 工作流需要按顺序操作，例如购买商品、下单和支付。以下是一些帮助您处理这种安全测试的方法：

|

Jenkins 中的安全自动化

在本节中，我们将讨论如何配置 Jenkins 以触发自动化测试，并介绍一些安全插件。

下表展示了如何配置命令行 ZAP 的示例，可以通过预定义的 URL 周期性地和远程触发：

步骤 配置步骤
新建项目 新建项目 | 输入项目名称 | "安全测试" | 自由风格项目 | 确定
一般 项目名称："安全测试"
构建触发器 自动化测试可以通过以下方式触发。构建触发器定义了任务如何触发。支持两种模式：一种是定时模式，另一种是通过 REST API 远程触发：                 定时构建：45 9-17/2 * * 1-5自动化测试也可以通过发送 HTTP 请求远程触发：                 远程触发构建： ZAP定义后，将成为可以远程触发自动化执行的 URL：https://<JenkinsHost:8080>/job/Security Testing/build?token=ZAP
Build 构建 | 添加构建步骤执行 Windows 批处理命令：echo ---- 执行 OWASP ZAP 的主动扫描----``           zap cli   active-scan    http://targetWeb/``     echo ---- OWASP ZAP 主动扫描结束 ----

有一些开源安全扫描工具也提供 Jenkins 插件。在实际应用中，这些 Jenkins 插件是可选的。如果你有少量项目并希望在 Jenkins 仪表板中管理安全扫描状态，这些 Jenkins 插件将是不错的选择。然而，如果你有大量项目并进行各种类型的安全测试扫描，建议你建立自己的集成安全测试框架。详情请参考第十二章，安全测试工具包。下表列出了与软件安全评估相关的常见 Jenkins 插件：

Jenkins 安全插件 描述
ZAP ZAP 是一个动态 Web 扫描工具。
Arachni Scanner Arachni Scanner 是一个动态 Web 扫描工具。
依赖检查插件 依赖检查插件用于检测易受攻击的依赖组件。
FindBugs FindBugs 是一个用于 Java 的静态代码分析工具。
SonarQube SonarQube 是一个代码质量分析工具。
360 FireLine 360 FireLine 是一个用于 Java 的静态代码扫描工具。
HTML 发布插件 HTML 发布插件生成 HTML 格式的测试结果。
日志解析插件 日志解析插件解析安全测试工具的测试结果，如检测到的 XSS 数量或错误数量。
静态分析收集器 静态分析收集器插件可以整合来自其他静态代码分析插件的结果，如 Checkstyle、Dry、FindBugs、PMD 和 Android Lin。

总结

本章中，我们学习了在编码、构建、测试和生产部署阶段持续集成周期中发生的安全实践。在开发阶段，我们进行安全代码扫描、安全编译检查，并且还对易受攻击的第三方组件进行审查。对于静态代码分析，我们还介绍了一些适用于不同编程语言的开源扫描工具。我们还学习了如何启用编译时防御机制来防止缓冲区溢出，如 ASLR 和 NX。

在网站安全测试中，我们介绍了主动和代理模式下的测试方法，并讨论了提高测试有效性的 Web 自动化测试技巧，涉及业务逻辑、API 模糊测试、扫描范围、授权和集成等方面。我们还介绍了 Jenkins 配置和 Jenkins 中的安全自动化插件，如 ZAP、Arachni、Dependency Check、FindBugs 和 SonarQube。在下一章，我们将学习关于事件响应的内容。

问题

  1. 与安全编码相关的安全实践有哪些？

    1. 使用 IDE 插件进行安全扫描

    2. 安全单元测试

    3. 静态代码扫描

    4. 以上所有

  2. DevSkim 工具是做什么的？

    1. 逆向工程

    2. 它是一个用于静态代码扫描的 IDE 插件

    3. 网站安全扫描

    4. 网络安全

  3. 防御内存溢出攻击使用了哪些技术？

    1. 堆栈随机化

    2. 不执行

    3. 异常处理程序保护

    4. 以上所有

  4. 使用依赖检查工具的主要目的是什麽？

    1. 软件完整性

    2. 实施访问控制

    3. 扫描已知的漏洞

    4. 数据加密

  5. Radamsa 可以用于哪些安全测试？

    1. API 模糊测试

    2. 完整性监控

    3. 动态分析

    4. 移动应用

进一步阅读

第十四章：事件响应

在前几章中，我们已经介绍了安全测试计划、白盒测试技巧、安全工具集和自动化。 从这一章开始，我们将讨论安全运营团队的事件响应。我们将主要讨论事件响应流程中各关键阶段的核心活动：准备、遏制、检测和事后分析。事件响应领域包括如何处理公开的 CVE 漏洞、如何应对白帽子或安全攻击、如何评估每个安全问题、反馈机制与开发团队的互动以及我们可能在事件响应中应用的工具或实践。本章将涵盖的主题如下：

  • 安全事件响应流程

  • 安全运营团队结构

  • 事件取证技术

安全事件响应流程

建立安全事件响应流程不仅是大型企业的必需，小型企业也同样需要。网络安全法律或 GDPR 要求不仅要有安全事件处理流程，还要求向监管机构和关键利益相关者发送安全事件通知。完整的安全事件流程包括安全事件处理团队、人力资源、法务部门，以及外部监管机构。尽管有许多安全技术和工具可以帮助识别、保护、检测、响应和从威胁中恢复，但公关和公共沟通在非技术部分中扮演着至关重要的角色。我们将重点关注基于 NIST SP 800-62 在准备、检测、遏制和事后处理阶段的安全活动。

以下是与安全事件响应相关的一些行业推荐参考：

NIST SP 800-62 将事件响应生命周期定义为四个阶段：准备、检测与分析、遏制清除与恢复，以及事件后活动。我们将在接下来的章节中介绍每个阶段的一些实用工具：

准备阶段

准备阶段是事件处理过程中最关键的部分。我们无法完全预测或避免任何安全事件，但可以做好充分的准备。准备阶段涵盖了所有所需的流程、分析工具、安全技术和团队资源，以预防和处理安全事件。准备不仅有助于预防安全事件，还能最大程度地减少发生安全事件时造成的损害。

以下是建议在事件响应准备阶段执行的一些安全实践：

  • 事件处理沟通计划

  • 事件分析硬件和软件工具（参考事件取证部分）

  • 现有的网络图和基准线

  • 预防控制措施，如风险评估、主机安全、网络安全、恶意软件保护、用户意识和培训（参考 CIS 安全控制）

  • 蓝队与红队安全演习（参考下表）

  • 白帽黑客或安全研究人员提交安全问题的赏金计划

建议定期进行内部攻击模拟，以测试现有终端和网络检测安全解决方案的有效性和弱点，例如杀毒软件、IPS、IDS 和防火墙。安全团队还可以分析现有的日志记录和警报功能以及响应时间。这类模拟攻击给安全团队提供了审查和优化现有安全框架的机会。

以下开源工具可以帮助生成内部攻击模拟而不影响业务操作。这些工具不会生成真实的攻击样本，而是模拟黑客行为或高级持续性威胁（APT）行为：

工具 APT 模拟
DumpsterFire DumpsterFire 工具包括多种模拟攻击场景，如账户攻击、文件下载、丢弃文件、命令执行和 Python 中的网页访问。它提供了一个用户友好的菜单，便于定制安全事件，即使是那些不懂 Python 的人也能使用。
METTA METTA 工具允许安全团队基于 MITRE ATT&CK 定制 APT 攻击的模拟。由 YAML 定义的模拟 APT 行为包括凭证访问、规避、发现、执行、数据外泄、横向移动、持久性和权限提升。
红队自动化（RTA） 红队自动化工具是一组基于 ATT&CK 的 Python 和 PowerShell 脚本，能够模拟超过 50 种恶意行为。
原子红队（ART） 原子红队工具提供 Windows、macOS 和 Linux shell 脚本，用于模拟 MITRE ATT&CK。
APT 模拟器 APT 模拟器工具是一组 Windows BAT 脚本，模拟 APT 行为。
网络飞行模拟器 网络飞行模拟器工具可以用于生成恶意网络流量，如 DNS 隧道、C2 通信、DGA 流量和端口扫描。

在处理安全事件时，团队可能会因专注于案件而忘记记录相关信息。一个事件跟踪工具可以帮助记录相关信息。开源工具 FIR（快速事件响应）是一个安全事件案件管理工具，可以帮助记录、跟踪和归档每个安全事件案件的所有发现。这些信息将有助于构建内部的安全事件处理知识库，并生成事后分析的事件报告（你可以在github.com/certsocietegenerale/FIR/找到此工具）。

检测与分析

识别安全事件的迹象需要部署各种安全解决方案和日志传感器。感染源包括 IDS/IPS、SIEM、防病毒、文件完整性监控、操作系统/网络日志以及已知的公共漏洞。整个企业安全控制的部署可参考 CIS 网络防御有效安全控制（你可以在www.cisecurity.org/controls/找到相关信息）。

这些包括 20 项安全控制，以下表格总结了这些控制。每个安全控制中有许多商业解决方案，但表格中仅列出了开源解决方案：

网络安全控制 安全技术和开源工具示例
CSC 1: 授权和未授权设备的清单 端点安全，资产管理
CSC 2: 授权和未授权软件的清单 端点安全，资产管理
CSC 3: 移动设备、笔记本电脑、工作站和服务器上的硬件和软件的安全配置 CIS 安全基准，OpenSCAP。
CSC 4: 持续漏洞评估与修复 OpenVAS、Nmap、OWASP 依赖检查、OWASP 依赖追踪、vulscan
CSC 5: 管理权限的受控使用 强密码复杂度，审计根用户和管理员活动的日志
CSC 6: 审计日志的维护、监控与分析 Syslog、事件日志、SIEM、ELK、GrayLog、Security Onion、恶意流量检测
CSC 7: 电子邮件与网页浏览器保护 邮件保护、反垃圾邮件、Web 应用防火墙 ModSecurity、电子邮件加密 Scramble、Linux 恶意软件检测
CSC 8: 恶意软件防护 终端保护、杀毒软件、HIDS/HIPS、OSSEC、ClamAV
CSC 9: 网络端口、协议和服务的限制与控制 Nmap、OpenSCAP
CSC 10: 数据恢复能力 Bacula
CSC 11: 网络设备（如防火墙、路由器和交换机）的安全配置 CIS 安全基准
CSC 12: 边界防御 防火墙、IPS、蜜罐 Security Onion
CSC 13: 数据保护 OSQuery、Data Vault
CSC 14: 基于需要知道的控制访问 数据分类、防火墙、VLAN、日志记录
CSC 15: 无线访问控制 VPN、SSL 证书、WAP2
CSC 16: 账户监控与控制 日志分析工具 Fail2ban
CSC 17: 安全技能评估与适当的培训填补漏洞 安全培训与实验室资源 CybraryIT
CSC 18: 应用软件安全 OWASP
CSC 19: 事件响应与管理 NIST SP800-61 计算机安全事件处理指南、FIR（快速事件响应）
CSC 20: 渗透测试与红队演习 请参考我们在准备部分建议的一些开源工具

当收到安全事件案例时，安全团队应根据事件的影响进行优先级排序。NIST SP800-61《计算机安全事件处理指南》建议通过功能性影响、PII 信息影响和恢复能力工作量来量化影响级别：

  • 功能性影响是指对业务功能的影响

  • PII 信息的影响是敏感信息的机密性、完整性和可用性（CIA）

  • 恢复能力工作量是指从事件中恢复所需的时间和资源量

下表展示了每个安全事件警报级别的一些示例定义：

优先级 影响 响应
高 功能性影响、信息泄漏或恢复能力工作量被归类为高。 需要立即人工响应。
中 功能性影响、信息泄漏或恢复能力工作量被归类为中等。 需要在 24 小时内响应。
低 功能性影响、信息泄漏和恢复能力工作量都被定义为低。 需要在常规任务中响应。
通知 没有直接与功能性影响或信息泄漏相关的重大迹象，但这可能是一个潜在的安全问题。 仅为通知。此内容可以作为季度威胁趋势分析的一部分。

隔离与恢复

隔离的短期目标是在完整解决方案准备好之前隔离感染的主机。另一方面，恢复的长期目标是寻找一种可以避免未来类似安全事件的安全控制，或者能够在检测到安全事件时执行自动恢复。

对于隔离，网络策略执行中已建立典型的网络或主机隔离标准。只要满足其中的任何标准，隔离措施可以包括阻止特定主机、重定向流量以应用最新的安全补丁，以及拒绝特定的通信流量或端口。

以下是常见的安全策略执行标准，这些标准会触发网络或主机隔离：

在恢复方面，目标是将感染的应用程序或主机恢复到正常操作状态。恢复活动不仅包括恢复系统，还包括删除被破坏的文件、应用最新的补丁、保护通信端口、增加密码复杂度以及改进安全控制，如权限配置、HIDS、SELinux 和防火墙。

事件后活动

举行经验教训会议或事后分析报告可以帮助团队从事件中学习。经验教训会议的主要目标是寻找在安全事件响应过程中每个阶段的改进。此类会议往往在安全问题解决后被忽视。建议至少记录安全事件的过程，并将其纳入知识库。

对于一次经验总结会议，会议应集中讨论团队如何共同改进，避免类似问题在未来再次发生，而不是责怪某个人。事后会议的输入通常包括提议的安全控制变更、案件处理信息以及根本原因分析报告。期望团队能思考具体可以采取哪些行动来防止类似问题的发生。例如，可以加强特定的电子邮件钓鱼意识培训。可以优化 IDS 中的安全扫描规则，减少误报。可以通过自动化进行安全事件取证。已知漏洞的安装周期可以缩短。这些是会议的潜在输出，通常会在利益相关者之间达成共识，如安全、IT、开发、业务和法律团队。

期望的事后报告通常包括若干关键部分，回答关键问题，如发生了什么、影响、根本原因分析、短期和长期的缓解措施、事件时间线中的活动、应改进的地方以及应保留的内容。以下是一次事后总结会议的输出报告示例：

问题概述

其中一项服务被确认存在异常不可用情况。WebLogic 进程占用 100%的 CPU，日志显示有异常且可疑的出站 IP 连接。

发生了什么以及影响

业务功能影响：部分服务响应变慢，无法响应请求。运行的进程占用了 100%的 CPU 资源。未发现数据泄露风险。

根本原因分析

  • IT 识别到是 WebLogic 进程经常导致 CPU 使用率超过 80%。

  • 安全团队检查 Linux 连接日志后，确认 WebLogic 进程与外部主机有出站连接，而这些主机与加密劫持相关（加密劫持是指通过攻击主机来挖掘加密货币）。

  • 在安全团队查询 CVE 数据库后，问题可能与 CVE 2017-3248 有关。

缓解措施和解决方案

  • 安全补丁准备之前的短期措施：应用防火墙规则，阻止与加密劫持服务器的出站通信流量，并阻止对受害主机的入站连接。

  • 长期：

    • 应用 WebLogic 安全补丁。

    • 更新防病毒安全模式。

    • 优化基于主机的入侵检测规则，以应对高 CPU 占用进程和异常的出站连接行为。

时间线中的活动

第一天 1000: IT 服务监控识别到服务不可用。

第一天 1020: IT 识别到 WebLogic 进程占用 100%的 CPU，并收集了相关日志以供进一步分析。由于问题频繁发生并影响到服务可用性，案件也被上报给安全团队，检查是否为安全事件。

第一天 1040：安全团队完成了日志分析并识别出异常连接。

第一天 1145：IT 团队接到通知，决定断开与恶意 IP 的出站连接。

应改进或保留的内容

  • 保留：IT 团队与安全团队之间的良好协作。

  • 改进：自动化日志收集和分析工具。

  • 改进：在安全补丁准备好之前，通过防火墙进行虚拟补丁处理。

  • 改进：与威胁知识的网络日志关联，来自iplists.firehol.org/。

安全事件响应平台（SIRP）

在处理安全事件时，会有大量信息需要处理和分析。理想的安全事件响应平台应能够做到以下几点：

  • 接收来自不同来源的警报和安全事件（SIEM、IDS、电子邮件）

  • 安全事件案例管理应允许安全分析师在事件处理生命周期中添加相关日志、IOC 或发现。

  • 将其分析与外部威胁信息进行对比，例如 VirusTotal，以识别文件、哈希、域名或 IP 地址的恶意行为。

开源工具 TheHive 可以帮助你提供一个安全事件响应管理平台。TheHive 还可以与 MISP 配合使用，MISP 是一个威胁情报平台，用于共享和关联攻击指示符（表示目标攻击已经发生）和漏洞信息。更多信息请参考以下文档：

欲了解更多关于 TheHive、CorTex 和 MISP 如何集成以进行威胁事件响应的信息，请访问blog.thehive-project.org/2017/06/19/thehive-cortex-and-misp-how-they-all-fit-together/。

SOC 团队

安全运营中心（SOC），也称为计算机事件响应团队（CIRT），是处理和监控日常安全事件的安全团队。SOC 的组织结构可以包括现有 IT 团队的部分成员、外包团队或专门的安全团队。无论其结构如何，团队都有几个关键功能：

关键功能 描述
安全事件分析和取证（呼叫中心） 该职能团队可能包括在 24/7 安全监控中心进行的一级案件处理。一级团队通常根据预定义的检查表或 SOP 来进行初步根本原因分析或缓解处理。

| 安全操作和管理 | 该职能团队涉及以下常规安全活动。这些是针对生产环境的定期安全检查活动： |

  • 网络扫描（每周）

  • 漏洞扫描（每周）

  • 渗透测试（月度）

  • 安全意识培训（每两个月一次）

  • 安全日志趋势分析（月度）

  • 安全管理和监控（每日）

  • 补丁或安全签名更新（每日/每周）

|

安全工具工程 安全工程团队为安全呼叫中心或安全运营团队实施安全工具。安全工具可以是安全自动化、可疑行为检测器、取证分析工具、安全配置检查器、威胁情报集成、威胁签名创建等。

SOC 团队可以由 IT 呼叫中心的一部分或专门的安全团队组成，具体取决于整个组织的规模。典型的专门 SOC 团队结构如下图所示：

事件取证技术

组织进行事件取证的主要目标是回答以下问题：

  • 主机是否被恶意程序感染？

  • 主机是如何感染的？

  • 如何改进以避免感染？

《NIST SP 800-86 数字取证与事件响应集成指南》定义了在受损计算机上执行数字取证的四个主要阶段：

  • 收集：收集受损计算机的所有相关日志或网络活动日志

  • 检查：提取并关联可能与可疑行为高度相关的信息

  • 分析：分析所有信息以查明恶意感染的根本原因

  • 报告：总结结果

取证技术要求事件响应团队具备进行分析的能力。在下表中，我们列出了一些能够执行半自动化取证的快速解决方案，包括收集、检查和分析：

类别 工具 目的和使用场景
日志收集 OSX Collector Mac OS X 日志收集器是一个用于 macOS 的自动化取证证据收集工具。Python 脚本 osxcollector.py 执行所有收集任务。该工具会生成一个 JSON 文件，作为收集信息的总结。
日志收集 IR Rescue IR Rescue 是一个用于收集主机取证数据的 Windows 和 Linux 脚本。Windows 版本集成了 Sysinternals 和 NirSoft 的几个工具。
日志收集 FastIR Collector FastIR Collector（仅适用于 Linux）只需一个 Python 脚本即可收集 Linux 中的所有相关日志。对于 Windows 系统，需额外的模块和工具。更多信息请参见github.com/SekoiaLab/Fastir_Collector。
恶意软件检测器 Linux 恶意软件扫描器 以下链接提供免费的 Linux 恶意软件扫描器：CalmAV：它是一个适用于 Windows 的开源杀毒软件。Linux 恶意软件检测（LMD）：它是一个适用于 Linux 的开源杀毒软件。
可疑文件分析 Cuckoo Cuckoo 是一个自动化恶意软件分析系统。它可以分析 Windows、Linux、macOS 和 Android 平台下未知和可疑文件的动态运行时行为和静态行为。
客户端/服务器日志收集与分析 GRR Rapid Response 你可以使用 Google Remote Live forensics 进行事件响应。这需要在目标主机上安装 Python 代理以收集日志，并在 Python 服务器上进行分析。
客户端/服务器日志收集与分析 OSQuery OSQuery 工具的工作方式与 GRR 类似。关键区别在于 OSQuery 提供了一个 SQL 查询来进行端点分析。有关更多信息，你可以阅读以下链接的文档：osquery.io/osquery.readthedocs.io/en/stable/deployment/anomaly-detection/

总结

在本章中，我们讨论了安全事件响应过程，并分享了一些行业实践，如 NIST SP800-62、SANS Incident Handler Handbook 和 MITRE 的世界级网络安全运营中心十大策略。我们根据 NIST SP800-62 定义的阶段探讨了事件响应活动，这些阶段包括准备、检测与分析、控制与根除以及事后活动。

在准备阶段，我们介绍了一些用于红蓝队演练的模拟攻击工具。在检测阶段，我们建议应用 CIS Critical Security Controls for Effective Cyber Defense 来评估检测与分析能力。在控制阶段，我们介绍了一些控制安全策略。在事后阶段，我们学习了如何进行事后复盘，并查看了一个事件的事后复盘报告。为了将不同阶段和团队的信息连接起来，建议你使用一个 安全事件响应平台 (SIRP)。

最后但同样重要的是，我们讨论了 SOC 组织及其应具备的关键职能。我们还查看了一些事件取证技术和工具。

在下一章中，我们将讨论安全监控。安全事件响应可能是一次性的安全案例处理活动，但安全监控将是一个持续的安全监控活动。

问题

  1. 安全事件响应阶段的正确顺序是什么？

    1. 检测 -> 准备 -> 控制 -> 事后分析

    2. 控制 -> 检测 -> 准备 -> 事后分析

    3. 准备 -> 检测 -> 控制 -> 事后分析

    4. 准备 -> 控制 -> 检测 -> 事后分析

  2. 什么最能描述一个奖励计划？

    1. 这是一个激励计划，鼓励安全研究人员提交安全问题

    2. 这是一个安全意识培训计划

    3. 这是一次内部的安全渗透演练

    4. 这是一个安全设计营

  3. 攻击模拟的目的是什么？

    1. 测试终端检测的弱点

    2. 测试网络安全检测能力

    3. 测试安全系统的日志记录和警报能力

    4. 以上所有

  4. CIS 关键安全控制在有效的网络防御中定义了什么？

    1. 它定义了整个企业安全的 20 项安全控制

    2. 它定义了事件响应流程

    3. 它定义了安全编码实践

    4. 它定义了安全自动化实践

  5. ELK、Graylog 和 Syslogs 主要用于以下哪些安全控制？

    1. 审计日志的监控与分析

    2. 电子邮件和网页浏览器保护

    3. 恶意软件防御

    4. 数据恢复能力

  6. 以下哪项不应用于量化影响级别？

    1. 功能影响

    2. 恶意软件检测能力

    3. 个人身份信息（PII）影响

    4. 可恢复性工作

  7. 以下哪个是 SOC 团队不正确的角色/职责？

    1. 一级呼叫中心的主要目标是执行恶意软件分析

    2. 安全运营团队应定期执行网络扫描

    3. 安全工具工程团队负责安全工具的实施

    4. 安全日志分析应定期总结并分析

  8. "加密劫持"的正确描述是什么？

    1. 未经授权使用受损主机进行加密货币挖掘

    2. 未经授权加密受损主机

    3. 未经授权访问加密的信息

    4. 未经授权加密受损主机

进一步阅读

第十五章：安全监控

事件响应的话题在上一章中已有讨论。在本章中，我们将介绍一些安全监控技术。本章的目标是准备我们的安全监控机制，以保护和防止我们的云服务受到攻击。为了做好准备，我们的安全监控程序应包括日志记录、监控框架、威胁情报和恶意程序的安全扫描。本章将涵盖以下内容：

  • 日志策略

  • 安全监控框架

  • 信息来源

  • 威胁情报工具集

  • 安全扫描工具集

  • 恶意软件行为匹配—YARA

日志策略

安全监控的一般目标是了解数据、网络、终端主机、网关、云服务、Web 服务、数据库、应用程序和安全配置的现有安全态势。此监控可以通过各种安全工具来实现，例如主机 IDS、网络 IDS/IPS、防病毒软件、防火墙，以及安全信息和事件管理（SIEM）。安全监控场景将决定应收集哪些日志，应该监控什么内容，以及威胁可视化的重点。

如果日志收集过于频繁，信息可能会变得过于庞大，占用过多的资源，如存储和网络流量。另一方面，如果收集的日志不够详细，安全专家可能无法识别潜在风险或进行安全事件的事后分析。

NIST SP 800-92《计算机安全日志管理指南》建议，日志收集配置应基于对系统的安全影响。建议日志收集和保留策略应基于数据的价值和业务影响。组织可以定义此类安全策略来管理整个日志基础设施。以下表格是一些日志策略的示例：

NIST SP 800-92 的日志配置设置示例：

类别 低影响 中等影响 高影响
日志数据保留时间（请注意，网络安全法可能会明确要求日志保留期限。此处的数字仅为示例。） 一到两周 一到三个月 三到 12 个月
日志轮换频率 可选（如果执行，至少每周一次，或每 25 MB） 每六到 24 小时一次，或每 2 到 5 MB 每 15 到 60 分钟一次，或每 0.5 到 1.0 MB
组织要求系统多频繁将日志数据传输到日志管理基础设施（如果有此政策） 每 3 到 24 小时一次 每 15 到 60 分钟一次 至少每五分钟一次
日志数据需要多频繁地在本地分析（通过自动化或手动方式） 每 1 到 7 天 每 12 到 24 小时 至少每天六次
是否需要对轮换日志进行完整性检查 可选 是 是
是否需要加密轮换日志 可选 可选 是
是否需要加密日志数据传输，或是否需要在单独的日志网络上执行传输 可选 是（如果可行） 是

安全监控框架

一旦安全检测解决方案到位，就可以规划安全监控管理，执行安全事件的关联分析。安全监控框架的目的是不是取代现有的端点或网络安全解决方案，而是提供整个环境的安全态势、安全趋势和安全事件关联。一些先进的安全监控框架甚至可以应用机器学习进行安全事件关联，以识别异常。不要单纯地认为建立一个安全监控管理框架就能解决所有与安全监控相关的工作。构建一个完整的安全监控框架需要包括以下关键组件：

  • 日志收集器：负责收集并转发所有日志给安全监控团队进行进一步分析。在生产环境中，日志收集的关注点是主机的性能影响和需要转发的日志数量。Syslog 是最常见的将日志发送到安全监控管理的方式。

  • 安全监控 (SIEM)：这为安全管理员提供整个环境的可视化安全概览。一个理想的 SIEM 甚至可以基于预定义规则进行自动化安全关联分析，识别异常和潜在风险。

  • 威胁情报：威胁情报用于将收集到的内部安全日志与外部威胁信息进行关联，例如黑名单中的 IP、Tor 出口节点、已知恶意域名、用户代理、文件哈希和妥协指标（IOC）。

  • 威胁情报馈送：这些构成了威胁数据库，包含由网络安全社区、安全供应商或客户提交的已知当前威胁信息。组织可以使用外部威胁情报馈送来修正内部安全事件，以识别是否存在任何可疑活动，例如内部主机连接到已知的网络犯罪 IP。

实际操作中，建议在部署和优化安全扫描解决方案（如主机 IDS/IPS 和网络安全）后，再构建威胁情报和安全监控。安全监控和威胁情报有助于您可视化并关联主机和网络段的安全事件，但这些安全监控技术仍依赖于主机和网络 IDS/IPS 检测及操作。

以下图示展示了安全监控的典型范围：

信息来源

各种日志源将帮助您在不同方面提供安全事件。以下是一些安全监控重点的常见建议：

信息来源 安全监控重点

| 应用日志 | 这些是应用程序生成的操作日志和错误日志。如果应用程序是 Web 服务，日志可能包含在 Apache 或 nginx 日志中：

  • 监控用户活动，特别是涉及敏感数据访问的活动

  • 监控用户配置文件的重大变化，例如登录 IP、异常终端设备、非浏览器连接客户端以及来自不同 IP 源的并发连接

  • 监控管理员和服务账户的活动

  • 监控登录失败和 Web 错误，如 401、404 和 501

|

| 主机安全、数据库日志 | 这些主要依赖于基于主机的 IDS/IPS 检测日志、操作系统和数据库日志：

  • 用户的成功和失败认证

  • 管理员访问和更改

  • 未授权的登录失败

  • 主要配置文件的更改，例如 mysql.cnf

  • 添加了数据库账户

  • 向特定主机传输大量数据

|

漏洞 OpenVAS 或 NMAP 扫描的 CVE 漏洞、不安全的通信端口或协议，如 Telnet、SSH v1、SSL 和 FTP
OpenSCAP 采用 OpenSCAP 扫描工具可以帮助您识别应用程序、操作系统、数据库和 Web 服务的不安全配置
网络安全、防火墙 依赖于网络 IDS/IPS 检测日志，以及负载均衡器、交换机和路由器的日志。有关 IPtables、Snort 和 Suricata 的更新防火墙规则，请参阅 EmergingThreats 网站。

| Web 安全 | 依赖于 Web 应用防火墙检测日志：

  • 客户端 IP 来自黑名单中的 IP

  • 与可疑客户端相关的用户代理

  • Web 日志中错误过多，例如 401、404 和 500

  • 请参考 OWASP ModSecurity CRS，它包括了 Web 应用防火墙规则集。

|

| 邮件安全 | 回复邮件安全扫描和检测日志：

  • 不寻常的邮件接收者或发送者

  • 恶意附件文件

  • 消息体中的恶意 URL

|

威胁情报工具集

威胁情报的目的是帮助组织为已知和未知的威胁做好准备。为了应对未知威胁，可以使用外部威胁源来识别现有环境中是否存在类似的威胁，同时也可以用于优化安全检测规则。例如，已知的网络犯罪 IP 或 Tor 出口 IP 可以用来在防火墙中阻止出站连接 IP 列表。

集成内部威胁日志信息和外部威胁源有助于结合已知和未知的威胁，并采取主动措施。整个威胁情报过程通常包括以下关键组件：

  • 日志收集器：用于收集内部系统、应用程序和安全日志

  • SIEM/可视化：用于在一个仪表盘中可视化安全态势

  • 威胁情报平台：用于关联内部和外部的威胁信息

  • 威胁情报源：这是外部威胁数据库，如黑名单 IP、恶意哈希、可疑域名等

以下是一些开源工具，可以帮助你构建完整的威胁情报解决方案：

类别 开源安全工具
日志收集器/传感器 Syslog-NG：Syslog-ng 是一个增强版日志守护进程，不仅能处理标准的 syslog 消息，还能处理非结构化数据。Rsyslog：Rsyslog 是一个rocket-fast（极速）system（系统）用于log（日志）处理的工具。FileBeat：Filebeat 提供了一种背压敏感协议，用于控制将数据发送到 Logstash 或 Elasticsearch 的流量。LogStash：Logstash 是一个数据处理管道，收集数据、转换数据并将其发送到 Elasticsearch。
SIEM/可视化 Kibana：Kibana 提供 Elasticsearch 数据的可视化展示。ElasticSearch：实时搜索、索引和分析数据。AlienValut OSSIM：这是 AlienValut 提供的开源 SIEM（安全信息和事件管理）解决方案。Grafana：提供一个快速的日志查询和可视化解决方案，无论数据存储在哪里。GrayLog：这是一个开源企业日志管理解决方案。
威胁情报平台 MISP - 开源威胁情报平台：MISP 是一个威胁共享平台，可以搜索和关联 IoC（入侵指示器）、威胁情报源和漏洞信息。

| 威胁情报源 | 外部威胁情报源，提供黑名单 IP 列表和防火墙规则建议：

|

安全扫描工具集

这里有一些可以执行安全监控、扫描和检测的开源工具。虽然您的组织可能已经部署了一些商业安全解决方案，但这些开源安全检测规则在优化现有的安全检测时，比如 IDS/IPS、防火墙和 Web 安全，可能是一个很好的参考。

您可能会发现以下规则有助于更新或改进现有的防火墙规则：

  • Wazuh 主机 IDS 规则：主机入侵防御规则。

  • OSSEC 主机 IDS 规则：主机入侵防御规则。

  • ModSecurity WAF 规则：Web 应用防火墙规则。

  • Suricata 网络 IDS/IPS 规则：基于网络的入侵防御防火墙规则。

  • Snort 网络 IDS/IPS 规则：基于网络的入侵防御防火墙规则。

该表列出了每个类别中的安全监控工具。

类别 开源安全监控工具
一体化安全扫描（主机、网络、可视化） Security Onion: github.com/Security-Onion-Solutions 包含多个开源安全工具，如 Elasticsearch、Logstash、Kibana、Snort、Suricata、Bro、OSSEC、Sguil、Squert 和 NetworkMiner。
一体化主机 IDS、安全配置与可视化 Wazuh 集成了 OSSEC（一个主机 IDS）、OpenSCAP（安全配置扫描器）和 Elastic Stack（威胁可视化）。
安全配置 OpenSCAP 定义了操作系统、Web、数据库和应用程序的安全配置。
漏洞 OpenVAS 和 OWASP 依赖是两款流行的开源漏洞扫描器。
杀毒软件 CalmAV 是 Windows 的开源杀毒软件。LMD（Linux Malware Detect）是 Linux 版本的开源杀毒软件。
主机 IDS/IPS OSSEC 和 Samhain 是两种需要考虑的开源主机 IDS/IPS 解决方案。
Web 应用防火墙（WAF） ModSecurity 是 OWASP 开源项目之一，是一个轻量级的 Web 应用防火墙。
网络 IDS/IPS Snort 和 Suricata 是两款流行的开源网络 IDS/IPS 解决方案。这两种解决方案还提供经常更新的规则。

恶意软件行为匹配 – YARA

YARA (virustotal.github.io/yara/) 是一个用于恶意软件检测的模式匹配瑞士军刀。YARA 规则由基于文本或二进制模式的恶意软件特征描述组成。YARA 可用于进行恶意软件检测，检测签名也可以轻松定义。YARA 扫描器/规则可以视为一种杀毒扫描器和签名。

例如，假设一台主机识别到可疑的 Webshell 活动，但杀毒软件没有检测到任何可疑活动。安全管理员可以使用 YARA 检测器和预定义的 YARA 规则扫描主机上的所有文件或扫描收集的日志。以下是一个 YARA 规则的示例，用于检测 Web shell：

rule  php_webshell : webshell
{
    meta:
        description = “This is a sample of a PHP webshell detection rule.”
    strings:
         $x1 = “eval(\\\x65\\x76\\x6C”
         $x2 = “Dim wshell, intReturn, strPresult”  fullword   ascii
    condition:
         filesize < 15KB and all of them
}

YARA 规则定义了 Web shell 的两个特征。当使用 YARA 规则扫描任何二进制文件时，如果文件大小小于 15 KB 且满足 x1 和 x2 中规定的标准，则 YARA 扫描器会识别出匹配项。

YARA 扫描器可以作为独立的命令行工具或作为 Python 插件执行。请参考 YARA 入门指南 编译与安装 YARA，了解如何在 Windows、Linux 和 macOS 上安装 YARA 扫描器。你可以在 yara.readthedocs.io/ 上找到该指南。

最新的 YARA 规则——以及恶意软件、恶意邮件、Webshell、打包工具、文档、漏洞利用包、CVE 和加密学的签名和检测——可以在以下链接找到：

概要

在本章中，我们讨论了使用 NIST 800-92《计算机安全日志管理指南》来定义日志策略。我们还探讨了安全监控框架的关键组件，如日志收集器、SIEM 和威胁情报。安全监控框架需要信息日志来源。我们还讨论了信息来源，并阐明了我们在日志中寻找的内容。应用日志、主机安全日志、数据库日志、漏洞扫描结果、网络安全日志以及 Web 和电子邮件安全日志通常是安全监控的日志来源。

我们还介绍了构建自己内部威胁情报框架所需的工具集。我们将威胁情报框架应用于识别已知和未知的威胁。我们还分享了一些用于构建威胁情报框架的开源工具，如 MISP——一个开源威胁情报平台。工具大致分为三个关键类别——日志收集器、SIEM/可视化和威胁情报订阅。另一方面，也有一些开源安全扫描工具集可用，如 Security Onion、主机 IDS、漏洞扫描器、杀毒软件、WAF、网络安全，以及 YARA 的使用。

总结来说，安全监控依赖于安全扫描工具、通过 SIEM 从各个来源关联的日志，以及用于识别已知和未知威胁的威胁情报订阅。

问题

  1. 以下哪项不是安全监控框架的一部分？

    1. 日志收集器

    2. 安全监控

    3. 威胁情报

    4. 加密

  2. 哪些类型的日志有助于安全监控？

    1. 应用程序日志

    2. 主机安全日志

    3. 漏洞扫描结果

    4. 以上所有

  3. 以下哪个事实与网络安全无直接关系？

    1. 客户端 IP 来自黑名单 IP

    2. 用户代理与可疑客户端相关

    3. 异常的邮件接收者或发件人

    4. Web 日志中的错误过多，如 401、404、500

  4. 以下哪种工具不是日志收集器/传感器？

    1. Syslog

    2. Kibana

    3. FileBeat

    4. LogStash

  5. Security Onion 用于什么？

    1. 它是一个一体化的安全扫描和监控工具（主机、网络、可视化）

    2. 它是一个漏洞扫描器

    3. 它是一个杀毒扫描器

    4. 它是一个 WAF（Web 应用程序防火墙）

  6. YARA 是什么？

    1. 它是一个加密模块

    2. YARA 是一个用于恶意软件检测的模式匹配瑞士军刀

    3. 它是一个漏洞扫描器

    4. 它是一个自动化框架

进一步阅读

第十六章：新发布的安全评估

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

本章节将涵盖以下主要内容：

  • 安全审查政策

  • 安全检查清单和工具

  • BDD 安全框架

  • 汇总的测试结果

发布的安全审查政策

组织应为每次发布定义其自己的安全评估政策。对于重要或新发布的应用程序，毫无疑问需要进行全面的安全评估。然而，我们是否也需要对补丁发布进行同样的处理，特别是当它是一个时间敏感且对业务至关重要的发布时？清晰理解应用程序发布的范围和目标将有助于安全团队规划必要的安全评估范围。

下表展示了应用发布与安全评估范围之间关系的示例：

应用程序发布目标 安全评估范围
新版或重大应用发布 全面评估
第三方组件更新 基于第三方及其集成接口的评估
补丁发布 基于补丁范围的针对性评估
紧急发布 安全测试范围有限，以确保没有重大安全问题

当一个团队接收更多项目并且发布频率更高时，单一的安全团队可能无法处理所有项目的安全评估。因此，建议定义哪些安全评估应由产品开发团队完成，哪些应由安全团队完成。通常，安全团队将帮助准备安全检查清单、工具包和指南，供产品团队进行自我评估。有关安全检查清单和工具的更完整列表，请参考下一节。本表格展示了开发、安保和 DevOps 团队执行安全评估活动的示例：

安全审查阶段 示例关键安全实践 执行者
自我评估

  • 审查 OWASP ASVS 检查清单

  • 审查 OWASP Top 10 检查清单

  • 执行定义好的自动化安全工具，例如 ZAP、NMAP 和 SQLmap

  • 修复重大安全问题

产品开发团队
发布前

  • 将自我评估测试结果和预发布包提交给安全团队

  • 安全团队重点评估风险最高的模块

  • 安全团队执行验收安全测试，不仅包括软件包，还包括整个系统的安全配置，如 Linux、MySQL 和 NginX

  • 安全审查团队将执行手动和自动应用程序和网络安全测试，并将收到的审查结果发送给您（详见后续结果部分）

安全团队

| 生产 | 定期执行以下安全扫描：

  • 软件组件已知 CVE

  • 安全配置

  • 网络通信，例如端口和不安全协议

  • OWASP 十大安全问题

运维和安全团队

安全检查清单和工具

我们讨论的安全检查清单范围主要是针对预生产部署版本。在部署到生产之前，DevOps 和安全团队会进行最终测试。在最佳情况下，这些定义的安全检查清单可以自动完成。这将帮助 DevOps 团队即使在部署到生产后也能定期进行安全检查。参考进一步阅读部分以获取每个工具的参考来源。以下表格显示正在检查的功能、安全测试方法和建议的安全测试工具：

安全类别 安全测试方法 建议的安全测试工具
隐藏的通信端口或通道

  • 确保没有隐藏的通信端口或后门

  • 确保没有隐藏的硬编码秘密、密码或硬密钥

  • 检查不必要的系统维护工具

  • 对网络通信进行源代码审查，如与 Java 相关的 API connect(), getPort(), getLocalPort(), Socket(), bind(), accept(), ServerSocket()

  • 禁止监听 0.0.0.0

NMAPGrauditTruffleHogSnallygasterHpingmasscan
隐私信息

  • 搜索源代码中的明文密码和密钥

  • 搜索符合 GDPR 合规性的个人信息

  • 个人信息可以由最终用户修改和删除

  • 个人信息可以在规定期限内删除

TruffleHogBlueflowerYARAPrivacyScoreSnallygaster
安全通信

  • SSH v2 取代 Telnet

  • SFTP 取代 FTP

  • TLS 1.2 取代 SSL TLS 1.1

NMAPWireSharkSSLyzeSSL/TLS tester
第三方组件

  • CVE 检查

  • 已知漏洞检查

  • 隐藏的恶意代码或秘密

OWASP 依赖检查 LMD（Linux 恶意软件检测）OpenVASNMAPCVEChecker
密码学

  • 确保没有弱加密算法

  • 确保公共 Web 界面上没有秘密文件

GrauditSSLyzeSnallygaster

| 审计日志 | 确保运维和安全团队能够记录以下情景：

  • 非查询操作，包括成功和失败的行为

  • 非查询调度任务

  • 执行管理任务的 API 访问或工具连接

GREP

| DoS 攻击 | DoS 测试旨在确保应用程序失败是否如预期。DoS 场景可能涵盖以下内容：

  • TCP 同步洪水攻击

  • HTTP 慢速攻击

  • HTTP POST 洪水攻击

  • NTP DoS

  • SSL DoS

PwnlorisSlowlorisSynfloodThc-sll-DoSWreckuestsntpDoS

| Web 安全 | 为了制定 Web 安全政策，你可以参考 OWASP 测试指南和 OWASP 十大漏洞：

  • 注入攻击

  • 身份验证

  • 数据暴露

  • XXE

  • 访问控制破坏

  • 安全配置错误

  • XSS

  • 不安全的反序列化

  • 已知漏洞

  • 日志记录和监控不足

参考 OWASP 测试指南 v4OWASP ZAPBurpSuiteArachni 扫描器 SQLMap
安全配置
模糊测试
移动应用安全
常见问题
安全合规

BDD 安全框架

由于存在各种安全测试工具，分析每个测试工具生成的测试结果可能需要耗费时间。在简单查看安全测试结果时，可能难以判断执行了哪些安全测试用例。例如，NMAP 生成的安全测试报告可以被安全测试团队理解，但可能对 DevOps 团队不易理解。这些都是 BDD 安全框架能够解决的问题。采用 BDD 安全框架的目的是整合所有安全测试工具，并通过可读的用户故事语句来定义所有安全测试用例。

为了构建完整的自动化框架，建议先准备好安全测试工具，如 NMAP、SSLyze、SQLmap、ZAP 和 Arachni。当这些安全工具和实践尚未就绪时，不要尝试构建 BDD 安全自动化框架。

毕竟，BDD 安全框架用于整合所有安全工具和结果，并以定义的用户故事形式呈现，要求每个安全测试工具执行相关操作：

以下表格对比了开源 BDD 安全工具与其他选项。这些框架足够灵活，可以执行安全工具集成并提供汇总的测试结果。如果你正在寻找一个可以在 Windows 和 Linux 上执行的 BDD 框架，并且能够与其他工具集成，那么可以考虑使用 GAUNTLT。GAUNTLT 提供了通用命令行适配器，允许你执行任何命令行工具：

MITTN GAUNTLT BDD 安全
编程语言 Python Ruby Java
BDD 框架 Behave Cucumber CucumberSelenium
Windows/Unix Unix 两者 两者
默认插件 BurpSuiteSSLyzeRadamsa NMapSSLyzeSQLMapGarmr 通用命令行 ZAPSSLyzeNessus

汇总的测试结果

如果你的安全团队使用各种安全工具进行安全测试，其中一个挑战就是如何汇总所有的输出结果。我们之前提到的 BDD 框架就是其中的一个解决方案。然而，如果你不打算构建另一个 BDD 框架，而只想汇总所有的测试输出，那么 OWASP DefectDojo 可能是你的解决方案（更多信息请见 github.com/DefectDojo/django-DefectDojo）。

使用 DefectDojo 来汇总所有安全测试工具输出的主要优势是能够将结果展示在一个仪表盘上，并附带相关的度量，如下图所示：

来源: github.com/DefectDojo/django-DefectDojo

以下表格展示了 DefectDojo 可以导入的开源安全工具输出格式：

开源安全工具 输出格式
Arachni Scanner: www.arachni-scanner.com/ JSON
Bandit: github.com/PyCQA/bandit JSON
Burp: portswigger.net/burp XML
Dependency Check: www.owasp.org/index.php/OWASP_Dependency_Check XML
Nikto: github.com/sullo/nikto XML
NMAP: nmap.org/ XML
OpenVAS: www.openvas.org/ CSV
Retire.JS: retirejs.github.io/retire.js/ JSON
ssllabs-scan: github.com/ssllabs/ssllabs-scan JSON
Trufflehog: github.com/dxa4481/truffleHog JSON
Visual Code Grepper (VCG): github.com/nccgroup/VCG CSV 或 XML
ZAP: www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project XML
通用发现导入 CSV

总结

在本章中，我们讨论了如何为每次发布建立安全审查政策。我们了解到，推荐将安全评估的范围基于应用发布目标。例如，新的重大应用发布应该进行全面的安全评估；而第三方组件更新发布可能只关注集成接口，而不是全范围评估。此外，安全审查可以在不同阶段进行，例如产品开发团队的自我评估、安全团队的发布前评估以及运维团队的产品安全评估。

还讨论了预生产部署发布的安全检查清单和相关的测试工具。安全检查清单的关键领域包括隐藏的通信接口、隐私信息、安全通信、第三方组件、加密、审计日志、DoS 攻击、Web 安全、配置、模糊测试以及最近的主要问题列表。

为了将所有的测试案例与不同的工具集成，推荐使用 BDD 安全框架。目前有三个开源 BDD 安全框架——MITTN、GAUNTLT 和 BDD-Security。如果没有使用 BDD 安全框架，建议使用 OWASP DefectDojo，它可以帮助整合各种安全测试工具的输出，并将结果呈现于一个仪表盘中。

总结来说，过程（安全发布政策、检查清单和测试策略）、技术（安全测试工具和框架）以及团队（开发、运维和安全团队）的参与是确保每次发布安全的关键。

问题

  1. 哪项安全评估适用于新的或重大应用发布？

    1. 完全评估

    2. 基于补丁范围的评估

    3. 基于第三方和集成接口的评估

    4. 安全测试范围限制为确保没有重大安全问题

  2. 以下哪项不是产品开发团队应进行的自我评估活动？

    1. 查看 OWASP ASVS 检查清单

    2. 安全意识培训计划

    3. 执行已定义的自动化安全工具，例如 ZAP、NMAP 和 SQLmap

    4. 修复重大安全问题

  3. 以下哪项不是用于检查隐藏通信接口的安全测试方法？

    1. 禁止监听 0.0.0.0

    2. 寻找隐藏的硬编码机密、密码或硬密钥

    3. 寻找个人信息

    4. 不必要的系统维护工具

  4. 以下哪种通信协议是不安全的？

    1. SSH v2

    2. SFTP

    3. TLS 1.2

    4. Telnet

  5. 以下哪项测试不是 DoS 测试？

    1. TCP 同步泛洪攻击

    2. HTTP 慢速攻击

    3. HTTP POST 泛洪攻击

    4. CVE 检查

进一步阅读

第十七章：威胁检查与情报

在上一章中，我们讨论了每次发布的安全评估。在本章中，我们将介绍威胁检查与情报。本章的重点是如何通过各种日志关联来识别和防范已知和未知的安全威胁，如后门和注入攻击。我们将介绍所需的日志、如何连接这些日志以及攻击的潜在症状。还将介绍一些开源的威胁检测技术。最后，我们将介绍如何构建自己的内部威胁情报系统。

本章将涵盖以下主题：

  • 未知威胁检测

  • 受损指标

  • 使用大数据框架进行安全分析

未知威胁检测

威胁态势处于不断变化的状态，随着新兴的、复杂的技术不断出现。与应对动态威胁态势相关的安全防护投资也在不断增加。安全防护正在从已知威胁检测转向早期防范未知威胁。大数据框架、机器学习和威胁情报是帮助实现未知威胁检测的技术。异常事件的关联分析是检测潜在未知威胁的关键。

以下图表展示了不同数据源之间关联或机器学习的概念：

网络流量分析的目标是识别异常的内部主机流量通信。网络流量分析面临的挑战是数据量可能非常庞大。此外，为了能够识别异常，网络管理员需要进行网络流量分析，例如定义网络通信白名单或网络流量基准线。尽管大数据和机器学习在分析方面可能有所帮助，但仍然需要 IT 网络管理员定义正常和异常网络流量的分类规则。

以下是一些典型的异常网络流量示例：

异常网络流量 潜在威胁
端口/主机扫描 端口或主机扫描行为意味着某个主机可能已被恶意软件感染，且恶意软件正在寻找网络上的漏洞、其他服务或主机。
从同一主机发出的大量 DNS 请求 这是 命令与控制（C&C）恶意软件的一个症状，通过 DNS 协议建立受感染主机与 C&C 服务器之间的通信。
从同一主机发出的大量 HTTP 请求 这是 C&C 的一个症状，通过 HTTP 协议建立受感染主机与 C&C 服务器之间的通信。
每天在相同时间段内，周期性地发出相同大小的请求 这是 C&C 恶意软件的症状，表明受感染主机与 C&C 服务器之间建立了通信。
向外部网站或 DNS 发送流量，这些网站或 DNS 被威胁情报源列为已知威胁 用户可能通过社交工程被欺骗连接到外部已知威胁网站，或者 C&C 连接成功建立。

为了可视化网络威胁状态，推荐两种开源工具：Malcom 和 Maltrail（恶意流量检测系统）。Malcom 可以展示主机通信关系图，帮助我们了解是否有任何内部主机连接到外部可疑的 C&C 服务器或已知的恶意网站。

来源: github.com/tomchop/malcom#what-is-malcom

另一种是恶意流量检测系统（Maltrail），它将外部威胁情报源进行关联，以识别已知恶意域名、可疑 URL、IP 或用户代理头：

来源: github.com/stamparm/maltrail

妥协指标

对主机进行可疑行为分析也是一项重大挑战，因为日志的可用性问题。例如，动态运行时信息可能未记录在文件中，用于放置可疑文件的原始进程也可能未被记录。因此，建议始终安装主机 IDS/IPS，如 OSSEC（开源 HIDS 安全）或主机杀毒软件，作为抵御恶意软件的第一道防线。一旦安装了主机 IDS/IPS 或杀毒软件，威胁情报和大数据分析可以作为补充，帮助我们了解整体主机的安全态势，以及现有主机环境中的已知妥协指标（IoCs）。

根据严重程度，以下是可能表明主机已被攻破的关键行为：

异常主机行为 潜在威胁
多个受损主机向外部主机的数据通信 受损主机正向外部 C&C 服务器发送数据。
主机连接到外部已知 APT IP 地址或 URL，并/或下载已知恶意文件 主机显示出来自 APT 或恶意软件攻击的妥协迹象。
多次失败的登录尝试 内部受损的主机正试图登录以访问关键信息。
包含危险 URL 或恶意文件的电子邮件 攻击者可能使用社交工程技术通过电子邮件进行针对性攻击。将发送邮件的发件人加入观察列表。
进程/服务/程序启动时出现罕见和异常文件名 恶意软件会安装自己以确保即使重启后仍能继续运行。恶意软件实现持久性的一种常见方式如下：对于 Windows 系统，建议使用AutoRuns检查主机是否被可疑恶意软件感染。docs.microsoft.com/en-us/sysinternals/downloads/autoruns

| 异常事件和审计日志警报 | 以下系统事件或审计日志可能需要进一步分析：

  • 账户锁定

  • 用户被添加到特权组

  • 用户账户登录失败

  • 应用程序错误

  • Windows 错误报告

  • 蓝屏死机（BSOD）

  • 事件日志已被清除

  • 审计日志已被清除

  • 防火墙规则更改

|

网页访问分析同样至关重要，因为大多数互联网连接都是基于 HTTP 协议的。网页访问主要有两种情况。一种是内部主机连接外部网站，另一种是内部或外部主机连接托管的 Web 服务。下表列出了网页访问分析的一些常见技术和工具：

网页访问分析 检测技术

| 外部来源客户端 IP | IP 地址来源分析有助于识别以下内容：

  • 已知的恶意 IP 或 TOR 出口节点

  • 异常地理位置变动

  • 来自不同地理位置的并发连接

MaxMind GeoIP2 数据库可以用于将 IP 地址转换为地理位置：dev.maxmind.com/geoip/geoip2/geolite2/#Downloads |

客户端指纹（操作系统、浏览器、用户代理、设备等） 客户端指纹可以用来识别是否存在异常客户端或非浏览器连接。开源的 ClientJS 是一个纯 JavaScript 工具，可以用来收集客户端指纹信息。Salesforce 提供的 JA3 通过 SSL/TLS 连接分析来识别恶意客户端。ClientJS: clientjs.org/ JA3: github.com/salesforce/ja3
网站声誉 当存在外部网站的出站连接时，我们可能会检查该目标网站的威胁声誉。这可以通过 Web 应用防火墙或 Web 网关安全解决方案来完成。www.virustotal.com/
域名生成算法（DGAs）生成的随机域名 C&C 服务器的域名可以通过 DGAs 生成。DGA 域名的主要特征包括高熵、高辅音数量和域名长度较长。根据这些指标，我们可以分析该域名是否由 DGAs 生成，并可能是一个潜在的 C&C 服务器。DGA 检测器：github.com/exp0se/dga_detector/此外，为了减少误报，我们还可以使用 Alexa 的前百万个网站作为网站白名单。参见s3.amazonaws.com/alexa-static/top-1m.csv.zip
可疑文件下载 Cuckoo 沙箱可疑文件分析：cuckoosandbox.org/

| DNS 查询 | 在 DNS 查询分析中，以下是一些妥协的关键指标：

  • 向未经授权的 DNS 服务器发送 DNS 查询。

  • 不匹配的 DNS 响应可能是 DNS 欺骗的一个指标。

  • 客户端连接到多个 DNS 服务器。

  • 超过 150 字符的长 DNS 查询，是 DNS 隧道的一个指标。

  • 高熵的域名。这是 DNS 隧道或 C&C 服务器的一个指标。

|

使用大数据框架进行安全分析

在讨论了一些常见的未知潜在威胁检测技术之后，我们将介绍一些开源框架，用于结合威胁情报和大数据技术进行安全分析。如果你打算建立一个能够执行以下操作的安全日志分析框架，可以考虑将这些开源解决方案作为基础：

  • 机器学习和与 IoCs 的关联

  • 涉及外部威胁情报数据源的分析

  • 数据增强，如 GeoIP 信息

  • 可视化和查询 IoCs 之间的关系

项目 主要特征
TheHive 项目 TheHive 提供威胁事件响应案例管理，允许安全分析员标记 IOCs。Cortex 可以使用诸如 VirtusTotal、MaxMind 和 DomainTools 等威胁情报服务进行分析。支持超过 80 个威胁情报服务。Hippocampe 通过 REST API 或 Web UI 提供查询接口：thehive-project.org/
MISP 这主要是一个用于共享 IoCs 和恶意软件指标的威胁情报平台。其关联引擎帮助识别恶意软件属性和指标之间的关系：www.misp-project.org/MISP 提供超过 40 个威胁情报数据源。参见www.misp-project.org/feeds/.

| Apache Metron | Apache Metron 是一个 SIEM（威胁情报、安全数据解析器、警报和仪表板），同时也是基于 Hadoop 大数据框架的安全分析（异常检测和机器学习）框架：metron.apache.org/。构建大数据框架时常用的技术组件包括以下内容：

  • Apache Flume

  • Apache Kafka

  • Apache Storm 或 Spark

  • Apache Hadoop

  • Apache Hive

  • Apache Hbase

  • Elasticsearch

  • MySQL

|

这些开源解决方案可以彼此协同工作。例如，TheHive 可以作为安全运营中心，管理包含 IoC 信息的安全事件案例，并将 TheHive 与 MISP 集成，以查询外部威胁情报源。此外，Metron 可以利用机器学习对日志数据进行丰富和分析，以识别异常情况。

此外，还有一些基于Elasticsearch、Logstash、Kibana（ELK）的开源分析框架。请参考以下列表：

TheHive

TheHive 是一个安全事件响应平台，集成了恶意软件信息共享平台（MISP）。Cortex 可以通过外部威胁分析服务，如 VirusTotal、DomainTools 和 MaxMind，帮助分析可观察数据。Hippocampe 提供 REST API 或 Web UI，帮助用户执行分析报告并进行查询。

以下图表展示了 TheHive、Cortex、SIEM 以及 MISP 之间的协作：

MISP – 开源威胁情报平台

MISP 是一个威胁情报平台，可以与威胁属性、IOC 和指标进行关联。MISP 还可以基于观察到的 IOCs 生成 Snort/Suricata IDS 规则、STIX 和 OpenIOC 检测规则。

以下图表引用了 MISP（恶意软件信息共享平台）：

以下图表展示了在 MISP 中识别的威胁及其威胁关系图。

来源：http://www.misp-project.org/features.html

除了 MISP，你还可以参考开源的你的日常威胁情报（YETI）平台解决方案，它也提供了类似的威胁情报平台。请参考yeti-platform.github.io/.

Apache Metron

Apache Metron 是一个网络安全应用框架，可以执行大数据分析以识别异常。该框架提供以下关键特性：

  • 对数据源进行处理、丰富和标注，以用于安全分析、搜索和查询。

  • 使用机器学习算法进行异常检测

  • 类似 SIEM 的功能（警报、威胁情报框架、数据源采集代理）

  • 一个可插拔的框架，支持各种数据源，并可以为新数据源添加解析器

请参阅以下 Apache Metron 图示：

总结

在这一章中，我们讨论了涉及识别网络流量和主机行为异常的未知威胁检测技术。为了识别和可视化网络流量中的潜在威胁，我们介绍了两个开源工具——Malcom 和 Maltrail。Malcom 帮助绘制连接关系图，并能识别潜在的 C&C 服务器连接。

关于主机行为，我们解释了 IOCs，并讨论了一些潜在威胁的异常主机行为。我们还讨论了网页访问日志分析的不同方面，包括外部来源的客户端 IP、客户端指纹、网站信誉、DGA 和 DNS 查询。

我们还为希望建立内部安全分析大数据框架的组织建议了一些开源框架。TheHive 和 MISP 可以协作进行威胁分析。Apache Metron 提供基于 Hadoop 大数据框架的安全分析。

在下一章中，我们将讨论商业欺诈和服务滥用。

问题

  1. 检测同一主机发送大量外向 DNS 请求的目的是什么？

    1. 这是勒索软件的一个指示器

    2. 这是一种端口扫描行为

    3. 这是 C&C 连接的一个指示器

    4. 这是一种正常行为

  2. IOC 代表什么？

    1. 妥协指示器

    2. 妥协信息

    3. 计算机检查

    4. 计算机注入

  3. 以下哪些可以是事件日志中潜在攻击的指示器？

    1. 蓝屏死机（BSOD）

    2. 事件日志已被清除

    3. 一个失败的用户账户登录

    4. 上述所有

  4. 为了进行网页日志分析，为什么我们要分析外部源客户端 IP？

    1. 用于识别是否为已知恶意 IP 或 TOR 退出节点

    2. 用于识别是否在短时间内存在异常的地理位置变化

    3. 用于识别来自不同地理位置的并发连接

    4. 上述所有

  5. DGA 代表什么？

    1. 域名生成算法

    2. 数据生成算法

    3. 非正规化生成算法

    4. 重复生成算法

  6. 为什么我们能够检测到由 DGA 生成的域名？

    1. 这是一种下载恶意软件

    2. 这是 C&C 服务器的一个指示器

    3. 这是勒索软件的一个指示器

    4. 这是暴力破解攻击的一个指示器

深入阅读

第十八章：商业欺诈和服务滥用

上一章讨论了威胁检查和情报。在本章中，我们将探讨商业欺诈和服务滥用。云服务带来了新的安全风险，例如交易欺诈、账户滥用和促销代码滥用。这些在线欺诈和滥用可能导致财务损失或收益，这取决于你站在哪一方。

因此，本章的目标是提供如何检测这些行为的指南和规则。我们还将讨论构建服务滥用预防或在线欺诈检测系统所需的典型技术框架和技术方法。

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

  • 商业欺诈和滥用场景

  • 商业风险检测框架

  • PCI DSS 合规性

商业欺诈和滥用

我们已经讨论了许多与防御或检测恶意活动相关的安全技术。另一方面，在线黑市也在寻找不同的机会，从而利用毫无防备的用户和电子商务网站服务牟取利益。这些网络犯罪活动正在利用商业交易的漏洞，借此获取经济利益。

以下是一些与在线黑市相关的常见活动：

商业场景 网络犯罪活动

| 为了促进新用户注册，电子商务网站可能会提供$10 的优惠券或某些折扣 | 账户作弊：

  • 网络犯罪分子可能注册大量账户以获得优惠券和折扣，然后将这些优惠券转售。

|

| 购物网站可能会出售数量有限的特版商品 | 黄牛：

  • 网络犯罪分子可能注册大量账户购买商品，并以更高价格转售

|

| 购物搜索查询结果按照在线卖家的评分和销量排序 | 非真实订单：

  • 在线卖家可能与网络犯罪分子达成协议，操控大量非真实订单和评分，以便在查询结果的排名中位列前茅

|

| 购物网站账户通常通过电子邮件、电话号码和身份证注册 | 账户接管：

  • 网络犯罪分子冒充真实用户，获取账户控制权并进行未经授权的交易

  • 此外，网络犯罪分子可能会对账户进行暴力破解攻击，并使用不同的电子邮件地址或电话号码重新注册，从而获得经济利益

|

以下图表概述了在账户、内容、支付和促销方面的商业欺诈风险：

你可能会想，限时出售限量版商品是否一件好事。毕竟，它吸引了公众的注意，而且并不违法。然而，黄牛党行为同样适用于在线商务交易。在线黄牛党行为可能在法律眼中占据灰色地带，但它确实破坏了商业的初衷。最终，随着这种行为的大规模蔓延，所有在线业务都会受到影响。

商业风险检测框架

构建商业风险框架的关键目标是识别交易是否真实，这意味着正常的用户或卖家遵循正常的商业规则，以便在电子商务平台上进行交易。另一方面，商业风险框架能够检测交易、账户或卖家是否可疑，是否受到网络犯罪分子的控制。网络犯罪分子与购物网站之间的关键关系如下图所示：

商业欺诈和滥用检测框架需要与在线业务紧密集成；特别是，安全政策必须理解商业物流规则。此外，框架必须能够检索关键的商业活动日志，包括登录、注册、用户行为、密码重置、支付和购买操作。

并非所有在线业务功能都需要实时欺诈检测。用户账户注册、促销、订单、支付和商业交易是需要风险管理的关键功能。当这些在线服务接收到来自客户的请求时，商业服务将查询实时欺诈检测服务，以决定是否继续交易。实时欺诈检测服务根据预定义的安全规则、离线分析以及其他支持信息来决定商业风险。

离线分析的关键目标是构建用户行为分析档案，帮助识别客户是否为正常用户，还是由网络犯罪分子控制的用户。为了识别客户是否为网络犯罪分子，必须获取多项信息。

假设我们有一个场景：一个用户通过Jimmy账户登录。我们如何识别这个人是否真的就是 Jimmy，还是有人盗用了 Jimmy 的账户？

为了回答这个问题，我们将研究 IP、账户、设备和使用情况的分析。分析的查询结果如下表所示。

案例 1 代表了正常用户行为，因为它说明了 Jimmy 在同一城市使用一台设备进行了 20 次登录。

然而，案例 2 绝对需要进一步调查，因为高度怀疑背后是网络犯罪分子。此案例表明，Jimmy 在 10 个不同的城市使用 10 台不同的设备进行了 20 次登录：

案例 账户 登录操作次数 设备概况 GeoIP
1 吉米 20 1 同一城市
2 吉米 10 10 10 个不同的城市

典型的商业欺诈检测框架如下图所示：

概况 描述

| IP 概况 | IP 概况旨在识别账户和设备的 IP 行为。IP 概况包括以下属性：

  • 地理位置

  • VPN、代理、网关或 TOR（这些 IP 地址将要求用户进行进一步验证）

  • 已知的黑名单 IP 地址

|

| 设备指纹 | 设备指纹是与远程客户端设备或浏览器相关的信息，目的是进行身份识别。我们使用设备指纹来判断远程连接的设备是否是用户/账户通常使用的设备。例如，同一个账户每天用不同的手机登录电子商务服务，显然是异常的表现。以下是一些常见的设备指纹：

  • 机器类型、CPU、虚拟化

  • 操作系统版本、软件插件、字体

  • 同一设备指纹的并发连接

  • 同一天同一设备的地理位置

  • 同一设备指纹被多个不同账户使用

  • 同一用户账户使用的多个不同设备指纹

|

| 机器与人类行为 | 行为分析的目标是识别请求源是否被恶意程序操控或是真实的人类：

  • 键盘使用情况

  • 鼠标移动

  • 用户代理；HTTPS 指纹

|

| 账户概况 | 以下属性与账户相关。如果其中一个属性（如电子邮件地址）被识别为可疑，那么与该电子邮件相关的所有其他账户也很可能是可疑的。因此，我们将基于以下信息构建一个可疑监控列表：

  • 电子邮件地址

  • 收货地址

  • 银行账户号码

  • 电话号码

  • 社交网络好友

  • 支付

|

| 使用概况 | 基于历史使用情况，我们还可以识别是否为正常用户，或者只是一个试图滥用服务或商业推广代码的临时用户：

  • 页面访问历史

  • 与卖家的历史通讯

  • 购买历史和习惯

|

构建概况的目的是根据历史使用或统计数据建立正常和常见行为的基础。概况的离线分析可以包括 IP 概况、设备指纹、机器行为、账户和使用情况。利用这些用户概况数据，我们将能够判断一个用户是否被黑客攻击或可能被网络犯罪分子操控。

此外，我们还可以分析页面访问行为，以识别是否为机器买家或真实人类买家。只需注意，网络犯罪分子也在尝试让机器行为更接近人类行为，以避开这些检测规则。这些行为可能是一个指标参考，但不能作为判断是否为机器买家的唯一证据。以下是正常用户和机器用户之间的一些关键差异：

正常人类买家 机器买家
通过关键词搜索查找产品 无搜索行为，直接定位到特定产品页面，跳过首页
查找相似产品进行某种比较 只关注促销中的特定产品
每个产品的浏览时间可能超过 20 秒 少于三秒
真实用户可能与卖家有过沟通历史 机器买家账户没有沟通历史
真实用户可能有购买过的产品的评分反馈历史 无评分反馈历史

截至写作时（2018 年），仍然没有一个完整的开源框架来整体检测欺诈风险，尽管已有用于执行设备指纹和威胁情报服务来识别黑名单 IP 的模块。建立一个完整的欺诈风险管理框架对于小型或中型企业来说可能是一个挑战。

以下是一些可考虑的缓解和安全措施：

欺诈缓解 描述
PCI 合规性 在线零售商的最低要求是符合 PCI 标准。确保相关第三方供应商和支付网关符合 PCI 标准。

| 定义阈值 | 这是减少欺诈风险中最容易实施的措施。常见的限制使用的阈值包括以下几种：

  • 登录失败次数超过一定次数后账户锁定一段时间

  • 限制每个设备/账户的优惠券使用次数

  • 限制每个设备/账户/日的交易次数

正确定义阈值将需要从历史数据中获取一些统计信息。 |

双因素重新认证 要求用户对关键操作如支付进行重新认证。
CAPTCHA 使用 CAPTCHA 来区分人类和机器人软件程序。
电话认证 向手机号码发送认证代码以完成购买操作。这也是双因素认证的第一步，因为它证明用户拥有该手机。

| GeoIP 或 IP 声誉 | 查找客户源 IP 地址的地理位置，因为 IP 地址可能很难伪造。检查以下内容：

  • IP 地址是否在黑名单中

  • GeoIP 是否出现在全球异常位置

|

PCI DSS 合规性

PCI 数据安全标准（DSS）被视为必须遵守的标准，是处理信用卡信息或在线支付操作的组织的最低安全要求。共有 12 项安全要求，此外还包括针对共享托管提供商和 TLS 的两个额外要求：

  • 要求 1：安装并维护防火墙配置，以保护持卡人数据

  • 要求 2：不要使用供应商提供的默认系统密码和其他安全参数

  • 要求 3：保护存储的持卡人数据

  • 要求 4：加密跨开放公共网络传输的持卡人数据

  • 要求 5：使用并定期更新防病毒软件或程序

  • 要求 6：开发并维护安全的系统和应用程序

  • 要求 7：根据需要了解的原则，限制企业对持卡人数据的访问

  • 要求 8：为每个有计算机访问权限的人分配唯一的 ID

  • 要求 9：限制对持卡人数据的物理访问

  • 要求 10：跟踪并监控所有对网络资源和持卡人数据的访问

  • 要求 11：定期测试安全系统和流程

  • 要求 12：制定一项针对所有人员的信息安全政策

  • 附录 A1：针对共享托管提供商的附加 PCI DSS 要求

  • 附录 A2：针对使用 SSL/早期 TLS 的实体的附加 PCI DSS 要求

在实施 PCI DSS 合规性时，PCI DSS 建议采用优先级方法，并为 12 个安全要求及其子要求设定了六个里程碑。以下是六个里程碑的关键概念：

  1. 如果不需要，避免存储敏感信息

  2. 保护系统和网络，并准备好响应系统漏洞

  3. 安全支付卡应用程序

  4. 监控并控制对系统的访问

  5. 保护存储的持卡人数据

  6. 完成剩余的合规性工作，确保所有控制措施到位

以下是关键类别的映射；请参阅参考资料以了解每个里程碑中的详细子要求：

PCI DSS 安全要求
如果不需要，避免存储敏感信息

  • 要求 1：安装并维护防火墙配置，以保护持卡人数据

  • 要求 3：保护存储的持卡人数据

  • 要求 9：限制对持卡人数据的物理访问

  • 要求 12：制定一项针对所有人员的信息安全政策

|

保护系统和网络，并准备好响应系统漏洞

  • 要求 1：安装并维护防火墙配置，以保护持卡人数据

  • 要求 2：不要使用供应商提供的默认系统密码和其他安全参数

  • 要求 4：加密跨开放公共网络传输的持卡人数据

  • 要求 5：使用并定期更新防病毒软件或程序

  • 要求 8：为每个有计算机访问权限的人分配唯一的 ID

  • 要求 9：限制对持卡人数据的物理访问

  • 要求 11：定期测试安全系统和流程

  • 要求 12：维护一个涉及所有人员信息安全的政策

|

安全支付卡应用

  • 要求 2：不要使用供应商提供的默认系统密码和其他安全参数

  • 要求 6：开发和维护安全的系统和应用程序

|

监控并控制对您系统的访问

  • 要求 7：根据需要访问原则限制企业对持卡人数据的访问

  • 要求 8：为每个有计算机访问权限的人分配唯一的 ID

  • 要求 10：跟踪和监控所有对网络资源和持卡人数据的访问

  • 要求 11：定期测试安全系统和流程

|

保护存储的持卡人数据

  • 要求 3：保护存储的持卡人数据

  • 要求 9：限制对持卡人数据的物理访问

|

完成剩余的合规工作，并确保所有控制措施到位

  • 要求 1：安装并维护防火墙配置，以保护持卡人数据

  • 要求 6：开发和维护安全的系统和应用程序

  • 要求 12：维护一个涉及所有人员信息安全的政策

|

PCI DSS 优先级方法参考源：

总结

在本章中，我们讨论了一些典型的商业欺诈和滥用案例，包括账户作弊、在线倒卖、非真实订单和账户接管。商业欺诈风险的主要类别包括账户、内容、支付和推广。

我们建议了一些检测规则和典型框架，用于构建自己的业务风险检测服务。为了识别正常和异常的用户行为，我们需要构建一个用户档案。档案构建的方面包括 IP 档案、设备指纹、机器行为、账户和使用情况。

除了检测，我们还探讨了一些缓解措施，例如 PCI 合规性、阈值、二次验证（2FA）、验证码（CAPTCHA）、GeoIP 和 IP 声誉。最后，但绝不是最不重要的，列出了 PCI DSS 合规性的优先方法。PCI DSS 合规性被视为任何信用卡数据处理或电子商务服务的最低安全要求。

在下一章中，我们将重点讨论隐私和 GDPR 合规案例的安全要求。

问题

  1. 什么是账户接管？

    1. 在线卖家可能与网络犯罪分子达成协议，操控大量非真实订单

    2. 计算机犯罪者冒充真实用户，获取账户控制权，进行未经授权的交易

    3. 网络犯罪分子可能注册大量账户以购买商品

    4. 网络犯罪分子可能注册大量账户以获取优惠券和折扣

  2. 账户可能与哪些商业风险和欺诈相关？

    1. 账户接管

    2. 暴力破解攻击

    3. 大规模注册

    4. 以上所有

  3. 以下哪个与促销滥用无关？

    1. 大量新用户

    2. 机器用户

    3. 爬虫

    4. 黄牛党

  4. 在进行潜在商业滥用风险检测时，分析的关键特征是什么？

    1. IP

    2. 账户使用情况

    3. 设备指纹

    4. 以上所有

  5. 以下哪个不包含在 IP 分析中？

    1. 地理位置

    2. CPU 类型

    3. 已知的黑名单 IP 地址

    4. TOR 出口节点

  6. 以下哪个可以用于设备指纹识别？

    1. CPU 类型

    2. 操作系统版本

    3. 软件插件

    4. 以上所有

  7. 识别机器行为的关键特征是什么？

    1. 跳过登录页面

    2. 每个产品的浏览时间非常短

    3. 没有通信历史

    4. 以上所有

进一步阅读

第十九章：GDPR 合规性案例研究

在前一章中，我们探讨了商业欺诈和服务滥用问题。在本章中，我们将深入讨论 GDPR 的案例研究。通用数据保护条例（GDPR）已设定了实施日期：2018 年 5 月 25 日。任何在此日期之前未遵守数据保护规则的组织，可能会面临重罚。本章将以 GDPR 合规性为案例，应用于软件开发。我们将讨论 GDPR 软件安全要求，并提出即将发布的版本中应包含的内容。我们还将探讨一些实际的案例研究，例如个人数据发现、数据匿名化、Cookie 同意、数据遮蔽实施以及网站隐私状态。

本章将涵盖以下主题：

  • GDPR 安全要求

  • 案例研究

GDPR 安全要求

GDPR 共有 11 章。为了将 GDPR 纳入产品开发考虑，第一至第四章与产品需求规划最为相关。下图展示了所有 GDPR 章节，其中括号中的数字表示该章节中的条款数量。

我们来看一下：

隐私权 详细描述

| 隐私通知（数据控制者）| 产品应提供隐私通知。隐私通知的内容应包括以下内容：

  • 如何收集和使用个人数据

  • 如何使用 Cookies

  • 如何保护个人数据。

  • 如何管理个人数据

  • 如何保护儿童的个人数据

  • 第三方服务

  • 个人数据的国际传输

|

处理的合法性（全部） 任何在用户未同意的情况下，后台收集个人数据的接口都是禁止的。例如，未获得用户同意上传故障排除日志，或在后台发送手机 IMEI。
数据最小化（全部）

  • 产品必须确保不收集与产品功能无关的数据。

  • 数据遮蔽（匿名化或伪匿名化）必须应用于个人数据。伪匿名化允许重新识别，但匿名化则不能重新识别。

以下个人数据应考虑进行匿名化处理：

  • 姓名（姓氏和名字）

  • 邮政地址、电话号码

  • 身份证件（信用卡号、社会安全号）

|

同意（数据控制者）

  • 在数据收集之前，产品必须向数据主体提供同意或不同意的选项。

  • 对于数据收集同意选项，禁止默认值为同意。

  • 同意授权的操作必须被记录。

  • 任何个人数据处理的进一步变化应获得另一个用户的同意。

|

反对数据处理的权利（数据控制者）

  • 产品必须提供选项，让用户可以停止用于任何直接营销目的的数据处理。

  • 产品必须提供选项，让用户可以随时删除自己的个人数据。

  • 一旦用户决定从数据处理流程中移除，若相关个人数据仍然按法律要求保留，则个人数据的保留期限应可配置。

|

数据主体权利（更正、访问、知情）

  • 产品应提供接口，允许用户添加、更新和删除自己的个人数据。

  • 如果产品需要连接互联网，必须告知并获得用户同意。

  • 任何软件更新或应用程序的安装也必须获得用户的同意。

  • 用于改善用户体验的反馈信息也必须征得用户的同意。

  • 在发送故障排除日志之前，必须征得用户的同意。

  • 个人数据应采取适当的安全控制措施，如访问控制和加密。

|

数据可携带权
  • 产品必须提供数据导出功能。数据导出格式可以是机器可读的格式，如 XML、CSV 或 JSON。

|

数据传输

  • 数据通信应通过安全的通道进行。

  • 如果个人数据需要传输给第三方，必须征得用户的同意。

  • 未经用户同意，不得将数据传输到欧洲经济区（EEA）以外。

|

被遗忘权

  • 一旦数据处理的目标完成，相关数据应被删除或匿名化，尤其是临时数据。

  • 一旦用户决定撤销用户账户，相关的个人数据也应该能够自动删除。

  • 产品应提供数据删除机制。

|

根据这些隐私权，GDPR 对产品和服务的安全要求可以总结在以下表格中。我们一起来看看。

实际上，以下是产品设计中常见的一些问题。我们来看看这个表格：

常见的产品设计问题 GDPR 合规性预期行为
该产品在用户撤销账户后不会删除相关的个人数据。 提供数据删除机制
该产品没有提供用户导出个人数据的接口。 提供将数据导出为 CSV 或 XML 格式的机制
用户同意的默认值始终为同意。 用户同意页面不应默认选择“同意”
用户无法选择停止进一步的用于营销目的的数据处理。 提供用户选择不参与营销分析的选项
上传包含个人信息的故障排除日志未进行匿名化处理，且没有获得用户同意。 征得用户同意，并对所有故障排除日志进行匿名化处理
该产品没有提供用户更新或编辑个人信息的接口。 提供用户编辑或更新个人信息的接口

此外，以下是推荐的 GDPR 自评估检查清单。在线评估报告还提供了改善数据保护和 GDPR 合规性的实际建议措施。请查看以下表格：

自评估检查清单类别 描述

| 控制者的数据保护自评估 | 这是一份在线自评估检查清单。评估结束时，将提供一份带有总体评分、指导意见和建议措施的报告。评估主要涵盖以下四个方面：

  • 合法性、公平性和透明度

  • 个人的权利

  • 责任和治理

  • 数据安全、国际转移和泄露

根据 GDPR 第 4 条，“控制者”是指单独或与他人共同确定处理个人数据的目的和方式的自然人或法人、公共机关、机构或其他组织；|

| 处理者的数据保护自评估 | 根据 GDPR 第 4 条，“处理者”是指代表控制者处理个人数据的自然人或法人、公共机关、机构或其他组织。该评估涵盖以下方面：

  • 文档

  • 责任和治理

  • 个人权利

  • 数据安全

对于 GDPR 合规性，数据处理者的安全要求可能低于数据控制者。

| 信息安全 | 信息安全评估包括以下内容：

  • 管理和组织信息安全

  • 员工和信息安全意识

  • 物理安全

  • 计算机和网络安全

  • 个人数据泄露管理

|

直销 评估是检查用于直销活动（如电话、电子邮件、邮寄、传真）中的个人数据处理。

| 记录管理 | 记录管理检查清单包括以下四个主要领域：

  • 管理和组织记录管理

  • 记录创建和维护

  • 跟踪和异地存储

  • 记录访问

|

| 数据共享和主体访问 | 它评估以下领域的数据共享政策：

  • 数据共享治理

  • 数据共享记录

  • 隐私信息

  • 安全措施

  • 个人数据处理请求

|

| GDPR 合规性检查清单 | GDPR 检查清单评估以下方面的一般安全要求：

  • 你的数据

  • 责任与管理

  • 新的权利

  • 同意

  • 跟进

  • 特殊情况

|

案例研究

在本节中，我们将讨论 GDPR 实施中的实际案例，并提供建议的解决方案或开源工具。这些案例涵盖数据发现、数据库匿名化、Cookie 同意、数据掩码和网站隐私等内容。这些都是与 GDPR 合规性直接相关的典型实际场景。

案例 1 – 个人数据发现

公司 A 已经运营了多个服务和数据库，并且有许多遗留的应用程序。数据库和 IT 管理员希望进行个人身份信息（PII）扫描，以全面了解所有个人数据的分布情况。在这种情况下，公司 A 需要一个PII 发现工具，该工具能够定义 PII 数据类型，并能够搜索各种类型的文件和数据库。请看这个图：

对于开源工具，推荐使用 RedataSense 数据发现工具，因为它支持多个数据库，并且可以通过字典和正则表达式识别个人数据。以下是敏感数据发现工具的参考来源：github.com/redglue/redsense。

此外，还建议定期搜索高度敏感和机密信息，如 API 密钥、加密密码、哈希值等。这些值的共同特征是高熵，尽管一些密码可能仍以明文配置，或使用没有加密的默认值。以下工具推荐定期使用，以扫描和识别秘密信息的存储。DumpsterDiver 是一个 Python 脚本，可以在本地文件中搜索秘密，而 TruffleHog 主要用于扫描 Git 仓库中的秘密。

要了解更多关于这些工具的信息，请访问以下网址：

案例 2 - 数据库匿名化

在开发和测试过程中，禁止开发团队访问生产数据库进行任何测试或评估，因为这样可能会导致意外泄露和侵犯隐私的风险。然而，另一方面，生产数据对于开发团队的性能、安全性和开发评估可能是有帮助的。因此，开发一个能够生成充满匿名数据的数据库的数据库匿名化工具变得非常重要。

数据库匿名化工具的数据流如下面的图所示。虽然该工具在技术上可以将生产数据库转换为匿名数据库，但强烈建议仅基于数据库架构（空数据库）来生成匿名数据。这是因为将生产数据库的数据转换过来可能会遗漏一些需要匿名化的与个人数据相关的列。生成数据的工具应该保持与生产数据相似的格式。请看这个图：

下表总结了数据匿名化工具及其适用场景。

数据匿名化工具 关键应用场景
数据匿名化(github.com/dataanon/data-anon) 这是一个 Java 库，能够帮助生成匿名化数据。可以定义多种匿名化策略，如随机邮箱、随机名字、随机整数、随机字符串等。
数据防御、数据发现和匿名化工具包(github.com/armenak/DataDefender) 它支持多个主流数据库，如 MS SQL Server、MySQL 和 Oracle。数据匿名化工具可以根据预定义的规则生成匿名化数据。
ARX 数据匿名化工具(arx.deidentifier.org/) ARX 可以灵活地定义转换规则并将数据导出为匿名化数据集。
数据库匿名化工具 github.com/Divanteltd/anonymizer 它可以与现有数据库一起工作，以进行匿名化、截断和清空表格。它也可以与 JSON 编码数据一起进行匿名化处理。
数据匿名化 sunitparehk.github.io/data-anonymization/ 这是一个 Ruby 数据匿名化库，用于构建 MySQL 匿名化数据转储。

案例 3 – Cookie 同意

为了符合 GDPR，任何用于唯一识别个人或设备的 Cookie 应被视为个人数据。（根据《通用数据保护条例第 30 条》）。请考虑以下原始引用：

“自然人可能会与其设备、应用程序、工具和协议提供的在线标识符相关联，如互联网协议地址、Cookie 标识符**或其他标识符，如射频识别标签。这可能留下痕迹，特别是在与唯一标识符和服务器接收的其他 信息 结合时，可能被用来创建自然人的个人资料并识别他们。”

因此，根据 GDPR，网站开发需要一个通用的 Cookie 同意政策和框架。传统的做法是通过访问此网站，您必须接受 Cookie，或者在用户首次进入页面时立即加载 Cookie，或使用第三方 Cookie（例如 Google Analytics），如果没有用户的同意，这可能不符合 GDPR。为了确保符合 GDPR，必须考虑一些 Cookie 同意方法。请务必咨询法律建议，以确定哪些方法最适合您的在线服务。

通常，有两种主要的 cookie 同意通知方式。软性选择加入的 cookie 同意方式是在访问者首次访问网站时默认显示带有“OK”按钮和隐私政策链接的通知。30 天后该通知会再次显示。直到用户点击其他链接或接受 cookie，首次登陆页面不会加载任何 cookie 行为。请看这个截图：

另一种方法是显示带有“OK”按钮和“Cookie 设置”的 cookie 同意横幅，其中包括隐私政策以及基于特定服务的 cookie 退出选项，以过滤 cookie。以下快照展示了 cookie 同意行为的概念。请查看此截图：

该截图显示了 cookie 设置：

请参阅后续章节了解一些开源的 GDPR cookie 同意实现。

案例 4 – 数据掩码库的实现

对于开发团队，涉及个人信息处理的服务实现将需要数据掩码 API，用于对个人数据进行匿名化。常见的数据掩码应用场景包括数据导出、基于访问角色的报告或查询结果、故障排除日志、第三方组件之间的通信以及生产数据库的导出。请查看此图：

以下是一些常见的基于编程语言的数据掩码 API：

案例 5 – 评估网站隐私状态

网站隐私扫描工具用于运营或安全团队，他们希望了解网站服务中所有第三方 cookie 的行为。很可能，某个嵌入的第三方服务可能具有网站管理员未意识到的 cookie 行为。因此，拥有一个在线隐私扫描器定期扫描所有 cookie 来源，以确保符合 GDPR 也是至关重要的。请查看此图：

以下是推荐的隐私扫描工具，它们不仅能扫描 cookie 跟踪行为，还能扫描 TLS 和 HTTP 安全头部的采用情况：

总结

本章讨论了产品和服务在 GDPR 合规性方面的安全要求。通常，这些安全要求涵盖了隐私通知、数据处理的合法性、数据最小化、同意、反对数据处理的权利、数据主体的权利、数据可携带权、数据传输和被遗忘权。

我们还阐述了一些常见的产品设计问题。例如，产品未提供用户编辑或导出自己个人数据的界面。用户同意的默认值总是“同意”。此外，我们还分享了 GDPR 数据保护的自我评估清单。

还讨论了五个实际的 GDPR 案例研究，描述了问题、建议的行动以及可使用的开源工具。这些案例涵盖了数据发现、数据库匿名化、Cookie 同意、数据掩码和网站隐私。

在接下来的最后几章中，我们将总结 DevOps 安全方面的挑战和常见问题，讨论如安全管理、开发、测试和安全监控团队等角色。

问题

  1. 以下哪一项应包含在隐私通知中？

    1. 如何保护个人数据

    2. 如何管理您的个人数据

    3. 如何保护儿童的个人数据

    4. 上述所有内容

  2. 什么是“数据最小化”？

    1. 保持数据尽可能小

    2. 产品必须确保不收集与产品功能无关的数据

    3. 压缩个人数据

    4. 加密个人数据

  3. 以下哪一项关于数据同意的规则是不正确的？

    1. 产品必须在数据收集后提供“同意”或“不同意”选项给数据主体

    2. 对于数据收集同意选项，不允许默认值为“同意”

    3. 同意授权的行为必须被记录

    4. 任何个人数据处理的进一步变更应获得用户的再次同意

  4. 以下哪一项是 GDPR 合规的预期行为？

    1. 如果用户撤销账户，产品不会删除相关的个人数据

    2. 用户同意的默认值总是“同意”

    3. 提供数据导出机制至 CSV 或 XML 格式

    4. 产品没有提供用户更新或编辑自己个人信息的界面

  5. 以下哪一项可能需要数据匿名化？

    1. 电子邮件

    2. 名字

    3. 年龄

    4. 上述所有内容

深入阅读

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

第二十章：DevSecOps - 挑战、提示与常见问题

DevSecOps 的采用是一个持续学习的过程，需要大量利益相关者的参与、流程优化、业务优先级冲突、安全工具的定制，以及安全知识的学习曲线。本章的目的是从功能角色的角度为您提供一些实用的提示、挑战和常见问题解答。

本章将涵盖以下主题：

  • DevSecOps 常见问题（适用于安全管理）

  • DevSecOps 常见问题（适用于开发团队）

  • DevSecOps 常见问题（适用于测试团队）

  • DevSecOps 常见问题（适用于运营团队）

DevSecOps 适用于安全管理

问：是否有针对 DevOps 的安全开发和部署的行业最佳实践？

OWASP SAMM（软件保障成熟度模型）、微软安全开发生命周期（SDL）和 SafeCode 为 DevOps 或敏捷开发提供了实际的安全实践。

问：云服务的安全风险有哪些？

CSA（云安全联盟）在其网站上定义了云计算的主要威胁（cloudsecurityalliance.org/group/top-threats/），如下所示：

  • 数据泄露

  • 身份、凭证和访问管理不足

  • 不安全的接口和 API

  • 系统漏洞

  • 账户劫持

  • 恶意内部人员

  • 高级持续性威胁

  • 数据丢失

  • 不足的尽职调查

  • 云服务的滥用与恶意使用

  • 服务拒绝

  • 共享技术漏洞

问：在 GDPR 合规性方面，安全要求是什么？

下表列出了数据处理者和数据控制者的软件/服务的 GDPR 安全要求：

GDPR 要求 数据处理者 数据控制者
提供数据隐私声明 必须 必须
数据收集需要用户的明确同意，允许数据收集并允许用户禁用数据收集 必须 必须
为了故障排除，用户必须被告知日志收集是否包括个人信息 必须 必须
收集用户的 cookie 需要用户的同意。有关详细信息，请参见 www.cookielaw.org/the-cookie-law/ 必须 必须
如果数据用于市场分析目的，应用程序必须允许用户禁用分析 推荐 必须
提供在数据过期后安全删除数据的能力 必须 必须
如果数据将提供给第三方合作伙伴，则必须获得用户的明确同意 推荐 必须
提供用户查询和更新数据的能力 推荐 必须
删除任何不再使用的临时数据 推荐 必须
提供导出数据的能力 推荐 必须
安全数据传输 必须 必须
使用加密、访问控制和日志安全控制的安全本地数据存储 必须 必须

DevSecOps 适用于开发团队

问：推荐的安全架构模式有哪些？

问：构建安全软件时，常用的安全框架有哪些？

安全改进领域 开源安全与隐私框架
认证

  • Gluu 用于多因素认证和社交登录

  • ReCAPTCHA

  • Git-Secret 用于保护源代码中的敏感信息

|

授权

  • Gluu 用于用户同意管理

  • Apache Shiro 会话管理

  • OWASP CSRF 防护

|

API 管理器

  • Kong

  • API 伞形架构

  • WSO2 API 管理器

|

数据输入/输出

  • OWASP HTML 消毒项目

  • Commons 验证器

  • ValidateJS

  • OWASP Java 编码器

|

隐私

  • ARX De-Identifier 数据匿名化工具

  • Apache Atlas 用于数据治理

  • PrivacyScore 用于网页隐私评估

  • CookieConsent

|

问：有很多第三方组件和依赖项与软件包一起发布和部署。是否有推荐的工具来评估这些安全风险？

问：在设计和编码阶段，推荐的安全交付物有哪些？

阶段 交付物
需求

  • 客户安全需求分析

  • 安全标准合规性分析

  • 安全行业最佳实践（如 OWASP ASVS、CSA CCM）

|

设计

  • 威胁建模分析报告

  • 安全设计检查表自评报告

|

编码

  • 静态安全编码扫描报告

  • 高风险模块安全评估报告

  • 安全编译器和链接器标志状态

  • 禁止或不安全的 API 使用扫描报告

|

问：推荐的安全编码最佳实践资源有哪些？

问：用于缓解缓冲区溢出攻击的安全编译器和链接标志是什么？

参考第八章，安全编码最佳实践中的安全编译表。

测试团队的 DevSecOps

问：建议用于数据隐私评估的测试工具有哪些？

数据生命周期 测试关键点 建议的测试工具
数据传输

  • 确保敏感信息不会通过 GET 方法传输

  • 安全通信协议，如 TLS v1.2、SSH V2、SFTP、SNMP V3

SSLyze、NMAP、Wireshark
数据存储

  • 检查敏感信息是否加密

  • 检查文件权限是否正确配置

TruffleHog: github.com/dxa4481/truffleHog
数据加密
数据访问和审计

  • 记录任何敏感数据查询

  • CL 权限

AuthMatrix: github.com/SecurityInnovation/AuthMatrix
数据移除

  • 检查临时文件、异常文件和 Cookies 中是否存在敏感信息

  • 检查内存和缓存中的任何纯文本敏感信息

GCOREWinHex: www.x-ways.net/winhex/ LaZagne: github.com/AlessandroZ/LaZagne

参考第十章，安全测试计划和实践，获取更多详情。

问：每个安全领域的行业安全测试指南是什么？

安全领域 安全测试指南
Web 安全测试

|

虚拟化安全测试

|

固件安全测试

|

大数据安全测试

|

隐私

|

物联网安全

|

容器安全

|

移动安全

|

请参阅第十章，安全测试计划和实践，了解更多细节。

Q: 推荐哪些使用正则表达式或字符串模式搜索高风险源代码的白盒审查工具？

工具 参考资料
DREK 工具：github.com/chrisallenlane/drek签名：github.com/chrisallenlane/drek-signatures/tree/master/signatures（参阅*.yml文件）
GrAudit 工具：github.com/wireghoul/graudit签名：github.com/wireghoul/graudit/tree/master/signatures（参阅*.db文件）
Visual Code Grepper（VCG） 工具：github.com/nccgroup/VCG签名：github.com/nccgroup/VCG/tree/master/VisualCodeGrepper/bin/Release（参阅*.conf文件）
CRASS Grep IT 推荐使用 CRASS Grep IT 工具，因为它不需要任何依赖项，只需要一个 shell 脚本来执行。工具：github.com/floyd-fuh/crass/blob/master/grep-it.sh签名：github.com/floyd-fuh/crass/blob/master/grep-it.sh

请参阅第十一章中展示的白盒测试技巧，了解更多细节。

Q: 推荐的开源工具有哪些，用于 BDD 安全框架？

BDD 安全框架 默认安全工具
BDD-Security OWASP ZAP, SSLyze, NessusBDD-Security 基于 Java 和 Cucumber。BDD-Security：www.continuumsecurity.net/bdd-security/
MITTN BurpSuite, SSlyze 和 Radamsa API 模糊测试 MITTN 基于 Python 和 Behave。MITTN：github.com/F-Secure/mittn
Gauntlt CURL, NMAP, SSLyze, SQLmap, Garmr, Heartbleed, dirb, Arachni Gauntlt：gauntlt.org/

请参阅第十二章，安全测试工具包，了解更多细节。

Q: 推荐哪些开源 Docker 安全扫描工具？

Docker 安全工具 目的和参考
Docker Bench Docker Bench 是一个自动化脚本，用于检查系统是否符合 Docker 安全最佳实践。扫描规则基于 CIS Docker 安全基准。Docker Bench: github.com/docker/docker-bench-security/ CIS Docker 安全基准: benchmarks.cisecurity.org/
Actuary Actuary 与 Docker Bench 的工作原理类似。此外，Actuary 还可以根据 Docker 安全社区提供的用户定义的安全配置文件进行扫描。Actuary: github.com/diogomonica/actuary/
Clair Clair 是一个容器镜像安全静态分析工具，用于检测 CVE 漏洞。Clair: github.com/coreos/clair
Anchor Engine Anchor Engine 扫描 Docker 镜像中的已知漏洞 CVE。Anchor Engine: Https://github.com/anchore/anchore-engine 此外，Anchor 还提供云版本，参考 'Anchor Cloud'
Falco Falco 是一个 Docker 容器运行时安全工具，可以检测异常活动。Falco: sysdig.com/opensource/falco/
Dagda Dagda 是一个集成的 Docker 安全工具，提供运行时异常活动检测（Sysdig Falco）、漏洞（CVE）分析（OWASP 依赖检查，Retire.JS）和恶意软件扫描（CalmAV）。Dagda: github.com/eliasgranderubio/dagda/

参考 第十二章，安全测试工具包，以获取更多细节。

问：有哪些集成的安全测试工具可以汇总各个测试工具的结果？

Faraday

Faraday 是一个集成渗透测试环境，并提供一个仪表盘来汇总所有测试结果。它整合了超过 50 种安全工具。

Faraday: www.faradaysec.com/#why-faraday 参考 github.com/infobyte/faraday/wiki/Plugin-List 以获取可用插件列表。

工具 默认包含的工具
JackHammer JackHammer，由 Ola 提供，是一个集成的安全测试工具。它提供一个仪表盘来汇总所有测试结果。其主要区别在于，JackHammer 包含了移动应用安全扫描和源代码静态分析工具。支持的开源安全扫描器包括 Brakeman、Bundler-Audit、Dawnscanner、FindSecurityBugs、PMD、RetireJS、Arachni、Trufflehog、Androbugs、Androguard 和 NMAP。JackHammer: github.com/olacabs/jackhammer Ola: jch.olacabs.com/userguide/

| Mozilla Minion | Mozilla Minion 也是一个集成的安全测试工具，默认包含以下插件：

  • ZAP

  • Nmap

  • Skipfish

  • SSLScan

Mozilla Minion: github.com/mozilla/minion/ |

渗透测试工具包 渗透测试工具包提供一个统一的 Web 界面，供多种 Linux 扫描工具使用，如 Nmap、nikto、WhatWeb、SSLyze、fping、URLCrazy、lynx、mtr、nbtscan、automater 和 shellinabox。渗透测试工具包: github.com/veerupandey/Penetration-Testing-Toolkit

| Seccubus | 使用 Seccubus 的主要优点是它能够整合各种漏洞扫描工具的测试结果，并比较每次扫描之间的差异。它包括以下扫描工具：

  • Nessus

  • OpenVAS

  • NMAP

  • Nikto

  • Medusa

  • SSLyze

  • SSL Labs

  • TestSSL.sh

  • SkipFish

  • ZAP

Seccubus: github.com/schubergphilis/Seccubus |

OWTF 攻击性网络测试框架（OWTF）是一个集成的安全测试案例，包含 OWASP 测试指南、PTES 和 NIST 测试标准。OWTF: owtf.github.io/ OWTF 指南: owtf.github.io/online-passive-scanner/
RapidScan RapidScan 是一个包含网页漏洞扫描工具的多功能工具。它包含的安全扫描工具包括 Nmap、dnsrecon、uniscan、sslyze、fierce、theharvester、golismero 等。
DefectDojo OWASP DefectDojo 是一个安全工具，可以导入并整合各种安全测试工具的输出，集中在一个管理仪表盘中。DefectDojo: github.com/DefectDojo/django-DefectDojo

请参考第十二章，安全测试工具包，了解更多详情

Q: 常见的安全 Jenkins 插件有哪些？

Jenkins 插件 描述
ZAP ZAP 是一个动态网页扫描工具。ZAP: plugins.jenkins.io/zap
Arachni Scanner Arachni Scanner 是一个动态网页扫描工具。Arachni Scanner: plugins.jenkins.io/arachni-scanner
依赖检查插件 依赖检查插件检测有漏洞的依赖组件。依赖检查插件: plugins.jenkins.io/dependency-check-jenkins-plugin
FindBugs FindBugs 是一个针对 Java 的静态代码分析工具。FindBugs: plugins.jenkins.io/findbugs
SonarQube SonarQube 是一个代码质量分析工具。SonarQube: plugins.jenkins.io/sonar
360 FireLine 360 FireLine 是一个 Java 的静态代码扫描工具。360 FireLine：plugins.jenkins.io/fireline
HTML 发布插件 HTML 发布插件生成 HTML 格式的测试结果。HTML 发布插件：plugins.jenkins.io/htmlpublisher
日志解析插件 日志解析插件解析安全测试工具的测试结果，如检测到的 XSS 数量或错误数量。日志解析插件：plugins.jenkins.io/log-parser
静态分析收集器 静态分析收集器插件可以汇总所有其他静态代码分析插件的结果，如 Checkstyle、Dry、FindBugs、PMD 和 Android Lin。静态分析收集器：plugins.jenkins.io/analysis-collector

参见第十三章，CI 管道中的安全自动化，了解更多详细信息。

DevSecOps 针对运营团队

Q. 针对 20 个 CIS 关键安全控制，有哪些建议的开源安全监控工具可以有效防御网络攻击？

网络安全控制 安全技术示例
CSC1：授权与未授权设备清单 端点安全，资产管理
CSC2：授权与未授权软件清单 端点安全，资产管理
CS3：移动设备、笔记本电脑、工作站和服务器的硬件与软件安全配置 CIS 安全基准，OpenSCAP
CSC4：持续漏洞评估与修复 OpenVAS：www.openvas.org/Nmap：nmap.org/OWASP 依赖检查：www.owasp.org/index.php/OWASP_Dependency_Check
CSC 5：控制使用管理员权限 强密码复杂性审计日志以监控 root 和管理员活动
CSC 6：审计日志的维护、监控和分析 Syslog、事件日志、SIEMELK：bitnami.com/stack/elkGrayLog：www.graylog.org/securitySecurity Onion：github.com/Security-Onion-Solutions恶意流量检测：github.com/stamparm/
CSC 7：电子邮件与网页浏览器保护 电子邮件保护、反垃圾邮件、Web 应用防火墙 ModSecurity：www.modsecurity.org/电子邮件加密 Scramble：dcposh.github.io/scramble/Linux 恶意软件检测：github.com/rfxn/linux-malware-detect
CSC 8: 恶意软件防御 终端保护，杀毒软件，HIDS/HIPSOSSEC: github.com/ossec/ClamAV: www.clamav.net/
CSC 9: 网络端口、协议和服务的限制与控制 NMAP, OpenSCAP
CSC 10: 数据恢复能力 Bacula: blog.bacula.org/
CSC 11: 网络设备如防火墙、路由器和交换机的安全配置 CIS 安全基准： www.cisecurity.org/cis-benchmarks/
CSC 12: 边界防御 防火墙，IPS，蜜罐安全洋葱： github.com/Security-Onion-Solutions
CSC 13: 数据保护 OSQuery: github.com/facebook/osquery/ 数据保险库:  github.com/hashicorp/vault
CSC 14: 基于知情需要的受控访问 数据分类、防火墙、VLAN、日志记录
CSC 15: 无线接入控制 VPN，SSL 证书，WAP2
CSC 16: 账户监控与控制 日志分析工具 Fail2ban: github.com/fail2ban/fail2ban/
CSC 17: 安全技能评估和适当培训以弥补差距 安全培训和实验室资源 Cybrary: www.cybrary.it/Git 良好的信息安全资源集合：github.com/onlurking/awesome-infosec
CSC 18: 应用软件安全 OWASP: www.owasp.org/index.php/Category:OWASP_Project
CSC 19: 事件响应与管理 NIST SP800-61 计算机安全事件处理指南快速事件响应（FIR）： github.com/certsocietegenerale/FIR
CSC 20: 渗透测试与红队演练 参考我们在第十二章中建议的一些开源工具，安全测试工具包。

问：有哪些推荐的开源工具可以模拟黑客攻击，以测试安全监控的有效性？

工具 APT 模拟
垃圾桶火灾 垃圾桶火灾包括各种模拟攻击场景，如账户攻击、文件下载、文件丢弃、命令执行和 Python 中的 Web 访问。它提供了一个用户友好的菜单，允许用户自定义安全事件，即使是那些不懂 Python 的人也能使用。垃圾桶火灾： github.com/TryCatchHCF/DumpsterFire
METTA METTA 允许安全团队根据 MITRE ATT&CK 自定义 APT 攻击的模拟。YAML 定义的模拟 APT 行为包括凭证访问、规避、发现、执行、外泄、横向移动、持久性和特权提升。METTA：github.com/uber-common/mettaMITRE ATT&CK：attack.mitre.org/wiki/Main_Page
红队自动化（RTA） RTA 是一组 Python 和 PowerShell 脚本，可基于 ATT&CK 模拟超过 50 种恶意行为。RTA：github.com/endgameinc/RAT
原子红队（ART） ART 提供 Windows、macOS 和 Linux 的 Shell 脚本，用于模拟 MITRE ATT&CK。ART：github.com/redcanaryco/atomic-red-team
APT 模拟器 APT 模拟器是一组 Windows BAT 脚本，用于模拟 APT 行为。APT 模拟器：github.com/NextronSystems/APTSimulator
网络飞行模拟器 网络飞行模拟器可用于生成恶意网络流量，例如 DNS 隧道、C2 通信、DGA 流量和端口扫描。网络飞行模拟器：github.com/alphasoc/flightsim

问：针对安全事件响应，推荐的行业参考有哪些？

问：安全运营团队结构中的典型职能有哪些？

关键职能 描述
安全事件分析与取证分析（呼叫中心） 安全事件分析和取证分析团队可能包括 24x7 安全监控中心中的 Tier 1 事件处理。Tier 1 事件通常通过遵循预定义的检查单或标准操作程序（SOP）来进行初步根本原因分析或缓解处理。

| 安全操作和管理 | 安全操作和管理团队涉及以下常规安全活动。这些是检查生产环境的常规安全活动： |

  • 网络扫描（每周一次）

  • 漏洞扫描（每周一次）

  • 渗透测试（每月一次）

  • 安全意识培训（每两个月一次）

  • 安全日志趋势分析（每月一次）

  • 安全管理和监控（每天一次）

  • 补丁或安全签名更新（每天/每周）

|

安全工具工程 安全工具工程团队为安全呼叫中心或安全操作团队实施安全工具。这些工具可以是安全自动化、可疑行为检测器、取证分析工具、安全配置检查工具、威胁情报集成、威胁签名创建工具等。

问：推荐哪些开源工具用于安全取证？

类别 工具 用途和使用场景
日志收集 OSX Collector macOS X 日志收集器是一个用于 macOS X 的自动化取证证据收集器。Python 脚本 osxcollector.py 是执行所有收集工作的代码。该工具将生成一个 JSON 文件，用于汇总收集到的信息。OSX Collector: github.com/Yelp/osxcollector
日志收集 IR Rescue IR Rescue 是一个用于收集主机取证数据的 Windows 和 Linux 脚本。IR Rescue: github.com/diogo-fernan/ir-rescue/
日志收集 FastIR Collector FastIR Collector for Linux 仅需要一个 Python 脚本即可收集 Linux 中所有相关日志。FastIR Collector: github.com/SekoiaLab/Fastir_Collector_Linux 对于 Windows 版本，它需要额外的模块和工具。有关更多信息，请参考 github.com/SekoiaLab/Fastir_Collector。
恶意软件检测器 Linux 恶意软件扫描器 Linux 恶意软件扫描器是一个免费的 Linux 恶意软件扫描工具。CalmAV: www.calmav.net/downloads Linux Malware Detect (LMD): github.com/rfxn/linux-maware-detect
可疑文件分析 Cuckoo Cuckoo 是一个自动化恶意软件分析系统。 Cuckoo: cuckoosandbox.org/
客户端/服务器日志收集与分析 GRR Rapid Response Google 的远程实况取证工具用于事件响应，需要在目标主机上安装 Python 代理来收集日志，并通过 Python 服务器进行分析。GRR Rapid Response: github.com/google/grr
客户端/服务器日志收集与分析 OSQuery OSQuery 的工作方式与 GRR 类似。主要区别在于，OSQuery 提供 SQL 查询来进行端点分析。OSQuery: osquery.io/附加信息: osquery.readthedocs.io/en/stable/deployment/anomaly-detection/

问：有哪些工具集可以帮助构建威胁情报解决方案？

类别 开源安全工具
日志收集器/传感器 Syslog-NG: github.com/balabit/syslog-ngRsyslog: github.com/rsyslog/rsyslogFileBeat: www.elastic.co/products/beats/filebeatLogStash: www.elastic.co/products/logstash
SIEM/可视化 Kibana: www.elastic.co/products/kibanaElasticSearch: www.elastic.co/AlienValut OSSIM: www.alienvault.com/products/ossimGrafana: grafana.com/GrayLog: www.graylog.org/
威胁情报平台 MISP - 开源威胁情报平台 MISP: www.misp-project.org附加信息: csirtgadgets.org/collective-intelligence-framework/
威胁情报源 外部威胁源提供了黑名单 IP 和防火墙规则建议：rules.emergingthreats.net/fwrules/www.spamhaus.org/drop/rules.emergingthreats.net/fwrules/emerging-Block-IPs.txtcheck.torproject.org/exit-addressesiplists.firehol.org/

问：有哪些开源工具可以帮助我们进行安全扫描？

类别 开源安全工具
一体化安全扫描（主机、网络、可视化） Security Onion 包括了多个开源安全工具，如 Elasticsearch、Logstash、Kibana、Snort、Suricata、Bro、OSSEC、Sguil、Squert 和 NetworkMiner。Security Onion: github.com/Security-Onion-Solutions
一体化主机 IDS、安全配置和可视化 Wazuh 集成了 OSSEC（主机 IDS）、OpenSCAP（安全配置扫描）和 Elastic Stack（威胁可视化）。Wazuh: github.com/wazuh/wazuh规则: github.com/wazuh/wazuh-ruleset/tree/master/rules
安全配置 OpenSCAP: www.open-scap.org/
漏洞 OpenVAS: www.openvas.org/
防病毒软件 CalmAV: www.clamav.net/LMD: github.com/rfxn/linux-malware-detect
主机 IDS/IPS OSSEC: github.com/ossec/ossec-hidsOSSEC 主机 IDS 规则: github.com/ossec/ossec-hids/tree/master/etc/rulesSamhain: www.la-samhna.de/samhain/
Web 应用防火墙（WAF） ModSecurity: github.com/SpiderLabs/ModSecurity规则: github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0/master/rules
网络 IDS/IPS Snort: www.snort.org/Snort 规则: snort.org/advisories/talos-rules-2018-06-05Suricata: suricata-ids.org/Suricata 规则: github.com/OISF/suricata/tree/master/rules
MySQL 审计 MySQL 审计插件: github.com/mcafee/mysql-auditMySQL 安全插件: dev.mysql.com/doc/mysql-security-excerpt/5.7/en/security-plugins.html

问：每个新版本需要哪些安全检查清单和工具？

安全类别 安全测试方法 建议的安全测试工具
隐藏的通信端口或通道

  • 确保没有隐藏的通信端口或后门。

  • 确保没有隐藏的硬编码密钥、密码或硬件密钥。

  • 确保没有不必要的系统维护工具。

  • 启动源代码审查，检查网络通信，如 Java 相关的 API connect()、getPort()、getLocalPort()、Socket()、bind()、accept() 和 ServerSocket()。

  • 禁止监听 0.0.0.0。

NMAPGrauditTruffleHogSnallygasterHpingmasscan
隐私信息

  • 在源代码中搜索明文密码和密钥。

  • 搜索个人信息以确保符合 GDPR 合规性。

  • 检查用户是否可以修改或删除个人信息。

  • 检查个人信息是否能在定义的时间内删除。

TruffleHogBlueflowerYARAPrivacyScoreSnallygaster
安全通信

  • 使用 SSH v2 代替 Telnet

  • 使用 SFTP 代替 FTP

  • 使用 TLS 1.2 代替 SSL，TLS 1.1

NMAPWireSharkSSLyzeSSL/TLS 测试工具
第三方组件。

  • CVE 检查

  • 已知漏洞检查

  • 隐藏恶意代码或机密检查

OWASP 依赖检查 LMD（Linux 恶意软件检测）OpenVASNMAPCVE 检查器
加密技术

  • 确保没有弱加密算法

  • 确保公共 Web 接口上没有机密文件

GrauditSSLyzeSnallygaster

| 审计日志 | 确保操作和安全团队能够记录以下场景：

  • 非查询操作，包括成功和失败操作

  • 非查询计划任务

  • 执行管理任务的 API 访问或工具连接

GREP

| DoS 攻击 | DoS 测试旨在确保应用程序故障是否按预期发生。DoS 场景可能包括以下内容：

  • TCP 同步洪水攻击

  • HTTP 慢请求

  • HTTP Post 洪水攻击

  • NTP DOS

  • SSL DoS 攻击

PwnlorisSlowlorisSynfloodThc-sll-dosWreckuestsntpDOS

| Web 安全 | 这可以参考 OWASP 测试指南和 OWASP 前十名：

  • 注入

  • 破坏的身份验证

  • 敏感数据泄露

  • XXE

  • 访问控制漏洞

  • 安全配置错误

  • XSS

  • 不安全的反序列化

  • 已知漏洞

  • 日志记录和监控不足

请参考 OWASP 测试指南 v4.OWASP ZAPBurpSuiteArachni 扫描器 SQLMap
安全配置
模糊测试
移动应用安全
常见问题
安全合规

Q. 用于构建大数据框架安全分析的开源工具有哪些？

项目 关键特性
TheHive 项目 TheHive 提供威胁事件响应案例管理，允许安全分析员标记 IOCs。Cortex 可以通过 VirtusTotal、MaxMind 和 DomainTools 等威胁情报服务分析问题。它支持超过 80 种威胁情报服务。Hippocampe 提供通过 REST API 或 Web UI 的查询接口。TheHive：thehive-project.org/
MISP MISP 主要是一个威胁情报平台，用于共享恶意软件的 IoC 和指示器。关联引擎有助于识别恶意软件属性和指示器之间的关系。MISP：www.misp-project.org/ MISP 提供超过 40 个威胁情报数据源。有关更多信息，请参考 www.misp-project.org/feeds/

| Apache Metron | Apache Metron 是一个 SIEM（包含威胁情报、安全数据解析器、警报、仪表盘）以及一个基于 Hadoop 大数据框架的安全分析（异常检测和机器学习）框架。Apache Metron：metron.apache.org/ 构建大数据框架所需的典型技术组件包括以下内容：

  • Apache Flume

  • Apache Kafka

  • Apache Storm 或 Spark

  • Apache Hadoop

  • Apache Hive

  • Apache Hbase

  • Elastic Search

  • MySQL

|

参考第十八章，《商业欺诈与服务滥用》，了解更多详细信息。

问：常见的入侵指标和用于识别它们的检测技术是什么？

异常主机行为 潜在威胁
多个被攻陷主机与外部主机的数据通信。 被攻陷的主机正在将数据发送到外部 C&C 服务器。
主机连接到外部已知 APT IP 地址或 URL。主机下载了已知的恶意文件。 主机显示出来自 APT 或恶意软件攻击的被攻陷迹象。
多次登录失败尝试 内部被攻陷的主机正在尝试登录以访问关键信息。
包含危险 URL 或恶意文件的电子邮件消息 攻击者可能利用社会工程学发送电子邮件进行定向攻击。将电子邮件发送者添加到观察列表中。

| 稀有且不寻常的文件名 | 恶意软件在启动时安装自己，即使重启后也能继续运行。以下是恶意软件实现持久性的常见方式。

  • 程序启动

  • 服务

  • 进程注入

  • 登录脚本

对于 Windows，建议使用 AutoRuns 检查主机是否被可疑恶意软件感染。AutoRuns：docs.microsoft.com/en-us/sysinternals/downloads/autoruns |

| 异常事件和审计日志警报 | 以下系统事件或审计日志可能需要进一步分析：

  • 帐户锁定

  • 用户已添加到特权组

  • 用户帐户登录失败

  • 应用程序错误

  • Windows 错误报告

  • 蓝屏死机日志（BSOD）

  • 事件日志已被清除

  • 审计日志已被清除

  • 防火墙规则更改

|

以下表格列出了 Web 访问日志中的检测异常：

Web 访问分析 检测技术

| 外部来源客户端 IP | IP 地址的来源有助于识别以下内容：

  • 已知的坏 IP 或 Tor 出口节点。

  • 异常的地理位置变化。

  • 来自不同地理位置的并发连接。

MaxMind GeoIP2 数据库可用于将 IP 地址转换为地理位置。 MaxMind GeoIP2: dev.maxmind.com/geoip/geoip2/geolite2/#Downloads |

客户端指纹（操作系统、浏览器、用户代理、设备等） 客户端指纹可以用来识别是否存在任何异常的客户端或非浏览器连接。开源的 clientJS 是一个纯 JavaScript 库，可以用于收集客户端指纹信息。Salesforce 提供的 JA3 工具使用 SSL/TLS 连接分析来识别恶意客户端。ClientJS: clientjs.org/JA3: github.com/salesforce/ja3
网站信誉 当存在到外部网站的出站连接时，我们可以检查该特定网站的威胁信誉。这可以通过 Web 应用防火墙或 Web 网关安全解决方案完成。 VirusTotal: www.virustotal.com/
通过 DGA（域名生成算法）生成的随机域名 C&C 服务器的域名可以通过 DGA 生成。DGA 域名的关键特征可能是高熵、高辅音数和长域名长度。根据这些指标，我们可以分析域名是否由 DGA 生成，从而成为潜在的 C&C 服务器。DGA 检测器: github.com/exp0se/dga_detector/此外，为了减少误报，我们还可以使用 Alexa 前 1,000,000 个网站作为网站白名单。有关更多信息，请参阅 s3.amazonaws.com/alexa-static/top-1m.csv.zip
可疑文件下载 Cuckoo Sandbox 对于可疑文件分析非常有用。 Cuckoo Sandbox: cuckoosandbox.org/

| DNS 查询 | 对于 DNS 查询的分析，以下是妥协的关键指标：

  • DNS 查询到未经授权的 DNS 服务器。

  • 不匹配的 DNS 回复可能是 DNS 欺骗的指示。

  • 客户端连接到多个 DNS 服务器。

  • 长 DNS 查询（例如，超过 150 个字符），这是 DNS 隧道的指示。

  • 高熵的域名。这是 DNS 隧道或 C&C 服务器的指示。

|

请参阅 第十八章，商业欺诈与服务滥用，以获取更多详细信息。

问：在商业场景中，常见的网络犯罪活动有哪些？

业务场景 网络犯罪活动
在新用户注册的推广中，电商网站可能会赠送 10 美元优惠券或某些折扣。 账户作弊： 网络犯罪分子可能会注册大量账户以获得优惠券和折扣，然后转售这些优惠券。
购物网站可能会出售数量有限的特别版商品。 黄牛党：网络犯罪分子可能会注册大量账户购买商品，然后以更高的价格转售。
购物搜索查询结果按在线卖家的评分和销量排序。 虚假订单：在线卖家可能与网络犯罪分子合作，操纵大量虚假订单和评分，以便在查询结果的排名中位列前茅。
购物网站账户通常需要使用电子邮件地址、电话号码和身份证号注册。 账户接管：网络犯罪分子冒充真实用户，控制账户进行未经授权的交易。此外，网络犯罪分子可能会对账户进行暴力破解，并重新注册其他电子邮件或电话号码，以获取经济利益。

参考第十九章，GDPR 合规案例分析，获取更多详细信息。

问：“分析”如何帮助检测商业欺诈和滥用行为？

分析 描述

| IP 分析 | IP 分析用于识别账户和设备的 IP 行为。IP 分析包括以下属性：

  • 地理位置

  • VPN、代理、网关或 Tor（这些 IP 地址需要用户进一步验证）

  • 已知的黑名单 IP 地址

|

| 设备指纹 | 设备指纹是关于远程客户端设备或浏览器的收集信息，用于身份识别。我们使用设备指纹来判断远程连接的设备是否为用户/账户常用设备。例如，对于同一账户，如果每天用不同的手机登录电子商务服务，这肯定是异常的标志。以下是一些常见的设备指纹：

  • 机器类型、CPU、虚拟化

  • 操作系统版本、软件插件、字体

  • 同一设备指纹的并发连接

  • 同一设备在同一天的地理定位

  • 多个不同账户使用相同的设备指纹

  • 同一用户账户使用多个不同的设备指纹

|

| 机器与人工行为 | 行为分析的目的是识别请求的来源是否被恶意程序操控，或者是真实用户的行为。以下是分析用户行为的几个线索，用于判断其是人类还是机器：

  • 键盘使用

  • 鼠标移动

  • 用户代理 HTTPS 指纹

|

| 账户分析 | 以下属性与账户相关。如果某一属性被识别为可疑，例如电子邮件地址，那么与该电子邮件地址相关的其他账户也很可能是可疑的。因此，我们将建立一个关注名单，包含以下隐私信息：

  • 电子邮件地址

  • 收货地址

  • 银行账户号码

  • 电话号码

  • 社交网络朋友

  • 支付

|

| 使用情况分析 | 基于历史使用情况，我们还可以识别是正常用户，还是仅仅是滥用服务或业务推广代码的单次用户：

  • 页面访问历史记录

  • 历史与卖家的沟通记录

  • 购买历史与习惯

|

请参见 第十九章，GDPR 合规性案例研究，以获取更多详细信息。

总结

在本章最后，我们总结了不同角色（如安全管理、开发、测试、IT 和运维团队）在 DevSecOps 实践中的关键常见问题解答（FAQ）。

安全管理识别安全需求，并确定支持业务成功的安全合规性需求。为了实现这一目标，安全经理可能会定义安全意识计划、安全保障计划、安全指南，以及供开发、测试和安全监控团队使用的流程或工具。

开发团队的目标是以快速交付构建安全的软件和服务。安全和隐私设计原则将贯穿整个开发周期，从安全需求、设计安全架构框架、加固编译选项、安全编码，到安全的第三方依赖关系。我们列出了许多行业最佳实践、建议框架和安全代码扫描工具供开发团队参考。开发团队可以应用这些安全实践。

安全测试团队通过多种方法确保安全质量，如白盒代码审查、渗透测试、安全配置、安全通信、敏感信息审查等。我们介绍了几种开源工具和测试方法来进行安全测试。这些安全测试工具也可以被其他团队使用。例如，开发团队也可以使用代码扫描工具确保在构建阶段的安全编码，运维团队也可以在部署阶段使用安全配置扫描工具。安全不仅仅是测试团队的责任，还需要开发与运维团队之间的合作。

安全运维团队需要确保云服务的安全性 24/7。安全运维团队的安全活动包括安全监控、安全事件响应、安全环境管理、漏洞管理和服务滥用监控。此外，我们还介绍了威胁情报，它提供威胁信息流，以检测已知的恶意 IP、文件哈希值或 DNS。安全运维团队是对抗威胁的前沿防线，可以为开发和测试团队提供最有价值的反馈，以提高安全性。同样，一个有效的反馈环路也需要每个职能团队之间的高度协作。

向 DevSecOps 过渡需要开发、测试、IT、运维和安全监控团队之间的高度协作。例如，基础设施运维团队可能会使用 Docker 容器技术进行部署。安全测试团队将提供安全配置评估工具，开发团队可能会定义 Dockerfile 的安全配置。安全管理团队会定义 Docker 采用全生命周期的安全要求。将安全“左移”——即将安全融入过程的早期阶段——需要每个角色的协作文化和安全意识。一个明确定义的角色、责任矩阵以及标准操作程序（SOP）可以帮助提高任务执行的效率。然而，职能团队之间的壁垒以及各个角色的关键绩效指标（KPI）可能对推动 DevSecOps 进展产生负面影响。每个职能团队对安全和隐私重要性的理解以及团队之间的协作是 DevSecOps 成功的关键。

进一步阅读

请访问以下网址了解更多信息：

第二十一章：评估

第一章

  1. 是

  2. GDPR

  3. 上述所有

  4. 定义操作系统、平台、数据库等的安全配置

  5. 上述所有

  6. 安全配置

  7. 欺骗

第二章

  1. 是

  2. 上述所有

  3. 上述所有

  4. GDPR

  5. PIA 隐私影响分析

第三章

  1. 是

  2. 上述所有

  3. 安全架构

  4. 安全需求

  5. 大型安全团队——超过 100 名成员

第四章

  1. 上述所有

  2. 服务日志已准备好进行安全分析

  3. 是

  4. Apache Ranger

  5. 错误

  6. 是

第五章

  1. 不是

  2. 上述所有

  3. 新闻通讯

  4. 是

  5. 是

  6. 测试

  7. 安全代码扫描

  8. 护照

第六章

  1. 上述所有

  2. CSA CAIQ

  3. 上述所有

  4. Shiro 不需要 Java Spring 框架

  5. Node.JS

  6. Mbed TLS

  7. 移除非法字符

第七章

  1. 错误

  2. 上述所有

  3. 身份验证日志

  4. SeaSponge

  5. Java Commons Validator

第八章

  1. PHP

  2. Java

  3. 上述所有

  4. 检测率和误报率

  5. CSRF Token

  6. VisualCodeGrepper

  7. MobSF

  8. Flawfinder

第九章

  1. 上述所有

  2. 杀毒软件

  3. 上述所有

  4. 错误

  5. 它用于执行敏感信息的数据掩码处理

  6. 开源许可证检查

第十章

  1. 上述所有

  2. 移动安全测试指南（MSTG）

  3. 它定义了高风险功能的测试方法

  4. 安装

  5. Nmap

  6. SSH v1

  7. 安全测试工具

  8. 它是一个专门为安全测试实践而设计的脆弱 Web 应用程序

第十一章

  1. 杀毒扫描结果

  2. 直接从源代码生成文档

  3. 上述所有

  4. fwrite

  5. 上述所有

第十二章

  1. OSSEC

  2. Web 安全

  3. OpenVAS

  4. 图形用户界面（GUI）

  5. 上述所有

  6. Appie

  7. PentestBox

第十三章

  1. 上述所有

  2. 它是一个用于静态代码扫描的 IDE 插件

  3. 上述所有

  4. 扫描已知漏洞

  5. API 模糊测试

第十四章

  1. 准备 -> 检测 -> 隔离 -> 事后分析

  2. 它是一个鼓励安全研究人员提交安全问题的激励计划

  3. 上述所有

  4. 它定义了整个企业安全的 20 项安全控制

  5. 审计日志的监控与分析

  6. 恶意软件检测能力

  7. 一级呼叫中心的主要目标是进行恶意软件分析

  8. 未经授权使用被攻陷主机挖掘加密货币

第十五章

  1. 加密

  2. 上述所有

  3. 不寻常的邮件接收者或发件人

  4. Kibana

  5. 它是一个全能的安全扫描和监控工具（主机、网络、可视化）

  6. YARA 是一款用于恶意软件检测的模式匹配瑞士军刀

第十六章

  1. 完整评估

  2. 安全意识培训计划

  3. 搜索个人信息

  4. Telnet

  5. CVE 检查

第十七章

  1. 它是 C&C 连接的一个指示器

  2. 受影响指示器（IOC）

  3. 上述所有

  4. 上述所有

  5. 域名生成算法

  6. 它是 C&C 服务器的一个指示器

第十八章

  1. 一名计算机犯罪分子冒充真实用户，获得账户控制权进行未授权交易

  2. 上述所有

  3. 爬虫

  4. 上述所有

  5. CPU 类型

  6. 上述所有

  7. 上述所有

第十九章

  1. 上述所有

  2. 产品必须确保不收集与产品功能无关的数据

  3. 产品必须在数据收集后提供同意或不同意选项给数据主体

  4. 提供数据导出机制，支持 CSV 或 XML 格式

  5. 以上所有

posted @ 2025-06-29 10:38  绝不原创的飞龙  阅读(21)  评论(0)    收藏  举报