信息安全策略最佳实践-二-信息安全策略最佳实践（二）第三部分：信息安全的运营化在这一最后部分，我们将实施措施以确保系

信息安全策略最佳实践（二）

原文：annas-archive.org/md5/5b3e514c57bef38b0fe4f8e2a395c7ee

译者：飞龙

协议：CC BY-NC-SA 4.0

第三部分：信息安全的运营化

在这一最后部分，我们将实施措施以确保系统和软件的安全，保持对安全事件的可见性，确保对安全事件的反应是充分的，并且不断改进流程。

本节包含以下章节：

第六章，设计和管理安全测试流程
第七章，拥有安全运营
第八章，提高软件安全性

第六章：设计和管理安全测试过程

现在，你已经很好地理解了可以实施的控制措施，以便你在组织中有一个有效的安全策略，我猜你已经实现了其中的一些控制措施，现在，你可以放心地放松，浏览 LinkedIn，在工作电脑上看 Netflix，直到你退休。恭喜你！你已经赢得了金表。

哦，你刚刚被pwned了。哎呀，怎么会这样？好吧，这是因为在你的设计中有一个巨大的漏洞，而你没有让其他人* sanity check你的架构，也没有让任何内部或外部团队对你的环境进行渗透测试*。你需要第二双眼睛，通常，你希望那第二双眼睛是一个技术高手——一个与组织没有任何关系的人，不会因为负面的意见而担心得罪同事或上司。

你想要答案。你想要真相！你的安全控制有效吗？有没有绕过控制的方法？你的员工觉得实施这些控制麻烦还是难以使用？

当我谈论信息安全时，它通常会回到采用持续改进的思维方式，这当然包括测试你现有的实施，并改进任何发现的问题，以便运行更顺畅、优化的信息安全程序。哦，当然，不言而喻，你会根据…你知道我要说什么吧？我希望是的：风险。

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

准备安全评估
了解不同类型的安全评估
执行安全评估的最佳实践
解读安全评估结果

到本章结束时，你将能够理解安全控制测试，包括安排外部和内部安全审计、如何分析报告并审查测试结果，以及如何管理每个评估中产生的行动。

让我们开始吧！首先，让我们看看我们需要测试什么，以及我们打算如何进行测试。

准备安全评估

我们怎么知道我们的系统可以防御攻击者？我们怎么知道我们的系统是有韧性的？我们怎么知道我们的系统是适当冗余的？

不幸的是，答案不能仅仅是“因为是我自己设计的”（戴着墨镜，站在电梯里的 Segway 上）。至少，第二双眼睛是很重要的。为什么我说“至少”？有时，你的第二双眼睛可能是一个同事，他要么没有足够的知识，要么与组织的隔离程度不够，无法提出他们如果没有上司会因为提出意见而冒犯对方的观察。

首先，你需要获得高层管理的支持。这是本书中的另一个经典主题，也是信息安全中的经典主题，你将在各种标准中看到这一点。例如，在ISO 27001的要求中（www.iso.org/standard/54534.html），第 5 条谈到领导力，而第 9.3 条则涉及管理评审。第 5 条指出，高层管理层必须参与制定信息安全政策。第 9.3 条则要求高层管理层持续参与评估信息安全管理系统，以确保其有效性。

就像我们之前说过的那样，管理层中的某些老古董怎么能做到这一点呢，尤其是他们还没有学会如何在 Excel 中使用公式？其实很简单：他们批准支出，并正式回应调查结果，要么批准所需的修复费用，要么接受风险。当然，作为你组织中的信息安全专业人员，你需要将调查结果转化为管理层能理解的内容，并且要以一种易于理解并突出任何风险的方式进行。

让我们来看一下如何根据组织需求选择合适的评估解决方案。

定义你的需求

你有大量的信息、系统、建筑和其他敏感或机密的资产，你已经实施了控制措施来保护它们。为了说它们是安全的（并且确保CIA 三原则完整），你需要确保这些控制措施有效地防止未经授权的访问、未经授权的修改，并确保可用性。对吧？对。

这是一件简单的事情，写起来简单，执行起来却不那么简单，尤其是当你的组织做着成千上万种不同的事情时。如果你联系到信息安全咨询公司，你可能会运气不错，遇到一个真正关心你组织的销售人员，然后他会拒绝销售那些不合适或不必要的评估。这对你来说是一个很好的情况，但同时，重要的是在购买之前确保你知道自己需要什么，并且，如何确保你接触到的是那种类型的销售人员呢？

此外，你是否愿意在还没有机会充分内部评估系统之前，就支付咨询公司来评估你的系统？这不仅听起来像是在浪费钱，而且也显得有些不负责任，直接交给别人而没有任何了解。我的意思是，我们是什么？高层管理层吗？！

首先，我们需要参考任何我们需要遵守的标准或法规，并记录是否因此需要进行安全评估。之所以建议这样做，有两个原因：

首先，我们可以接受标准和法规是有其存在的理由的，并且它们包含了适用于所有组织（包括我们自己）的最佳实践。
其次，如果您没有遵守要求，您可能会在未来的审计中被罚款，或者失去对标准的认证。有时，您的组织有与维持各种标准相关的业务运营和关系，例如支付卡行业数据安全标准（PCD-DSS），并能够处理卡支付。

有时，例如在 PCI-DSS 的情况下，标准的评估要求会根据您组织的活动不同而有所不同。对于低量处理，您可能只需要填写自我评估问卷（SAQ），而不是让合格安全评估员（QSA）评估您的系统。

让我们更仔细地看看 PCI-DSS 的 12 个高层次要求作为例子：

实施并维护有效的防火墙
更改所有默认密码
对持卡人数据进行静态加密
对持卡人数据进行传输中的加密
实施并维护恶意软件防护
更新和修补系统以防止漏洞
对持卡人数据的访问控制
对系统组件的访问控制
对持卡人数据的物理访问控制
监控所有对持卡人数据和网络资源的访问
定期测试系统
为所有员工维护信息安全政策

现在，让我们假设由于您的组织处理的支付交易数量较大，因此需要一个 QSA。这些 QSA 将评估您的组织是否符合这 12 个高层次要求（以及总计 220 多个子要求）。如果您无法证明这些要求，您的组织面临罚款的风险，或者可能无法接受某些类型的支付。

当我们考虑为PCI-DSS 评估做的准备工作，并确保您的组织在 QSA 到达之前符合标准时，重要的是要安排测试，记录每个要点的发现。我们这样做是为了确保我们的组织能够接受支付并避免被罚款。我们有一份要求清单，其中包括要求 11，即测试所有系统、流程和软件，以便了解任何可能被恶意行为者利用的漏洞，然后应用适当的控制措施。

组织可能会出于其他原因对其内部系统进行安全评估，即使没有具体的监管要求。可能的原因包括不确定组织的知识产权是否得到了适当保护，或者检查已实施的控制措施是否有效地防范了威胁。也许你认为组织的安全性较差，但没有人听你的。在这种情况下，你可能未能获得高层管理的支持，但通过让专业人士展示如何利用漏洞进行攻击，或许能引起更多关注和/或争取到预算。做出这个决定并不是我所能倡导的，但它可能会有效，也有可能让你陷入困境，因此尽量争取上级的支持。

在我们选择进行哪种评估时，这取决于你的需求和战略。你在做出决策之前可以定义的一些内容包括以下几个方面：

为什么要进行评估？

— 合规性：有时，组织仅仅需要勾选一个合规性框。对于一些顾问来说，合规性评估可能是他们工作的大部分内容。如果这对你的组织来说是主要驱动力，那么花钱做更高价值的评估可能不太值得。

— 追求改进：在这种情况下，组织可能已经符合要求，但希望得到比当前更好的保护。此时，你可能需要更高价值的评估，因此需要一些稍微贵一些的服务，或者选择一家更有名的公司。

此外，安全评估有助于通过快速发现错误来降低成本，提供一个私密的环境，让团队可以修正任何发现的问题，同时避免因泄露带来的声誉损害。
测试的内容是什么？评估的范围是什么？

— 软件：你是否想查看你的组织所创建的软件是否能够防止入侵或滥用？你是否想检查你的文件共享软件或操作系统的配置是否得当？针对软件有各种评估方法，比如网络应用渗透测试、安全扫描、内部渗透测试、外部渗透测试等。

— 硬件：你的组织是否创建或购买了某些物理设备，如自动取款机、锁系统或加密货币钱包？你将需要一个硬件安全测试人员来评估它是否足够安全，以保护它需要保护的内容。

— 网络：前面已经提到过，您可能想要了解，组织内部的低权限用户能够利用自己的凭证做到什么程度。您可能希望查看某人是否能从外部入侵您的网络并提升他们的权限。您是否想在其中加入社交工程的测试？您是否想同时测试您的物理安全性？

— 员工意识与物理安全：社交工程评估，例如钓鱼活动，向用户发送伪造的跟踪链接，测试他们识别社交工程攻击的能力。

— 物理安全：您是否对“黑队”评估感兴趣，即安全评估人员会实际（并且数字化）渗透到您的场所？员工是否允许陌生人进入限制区域？在这种情况下，某人可以访问多少信息？
您会给评估人员多长时间？

— 有时，一个精心策划的活动可能需要几个月的时间来妥善规划和执行。您试图模拟什么类型的威胁？
您需要评估在何时完成？

— 信息安全行业正在蓬勃发展，但目前人才短缺，这可能导致评估完成的延迟。确保提前规划，并与不同的公司沟通，了解他们的交付周期。
您对这个特定评估的预算是多少？

— 如果您需要一个“红队”评估，其中评估团队需要长期规划并模拟长期的真实威胁，但您只有 5000 美元预算，并且没有监控或“蓝队”，您可能需要重新考虑您期望的目标。

与提供安全评估的第三方交流时，值得询问他们的评估方法，并了解他们是否有适用于您希望进行的具体任务的参考资料。此外，在正式合作之前，可能值得与评估人员交流，并/或查看他们的简历。

另一个重要的要求是您的条款。首先，您不希望评估导致您的生产系统停机，并让您的组织因为收入损失而付出代价。这对任何人都不利，您希望与有经验的第三方合作，以防止这种情况发生。此外，您不希望在您有机会修复漏洞之前泄露您的弱点。一种防止未经授权共享的方式是设立各种条款，包括保密协议（NDA）。

现在我们已经涵盖了关于在进行安全评估之前，您和您组织成员可能需要问的一些高层次问题，我认为接下来讨论我们可能遇到的安全评估类型是个好主意。

了解不同类型的安全评估

有多种安全评估可帮助您了解以下内容：

您整个组织的安全态势
你的硬件产品的安全控制有效性
你的软件产品的安全控制有效性
你建筑物的安全性
你员工的安全意识
你安全团队应对主动威胁的能力

除了这个列表外，执行这些类型评估的方法有很多，包括让你自己的员工进行内部审查，或让其他组织进行第三方审查。此外，还可以进行自动化测试。

内部审查有助于降低成本，在某些情况下，如果内部团队熟悉其审查的流程，还能节省时间。然而，内部审查缺乏客观性，且可能没有“新鲜眼光”来看待目标。

第三方审查由行业专家进行，这些专家每天都在破解软件、硬件、建筑物和组织的信息系统。他们的发现通常会以标准化报告的形式提供，报告可能还会提供补救措施和战略建议，指导你的组织接下来的行动。此外，第三方能够诚实并公开地向客户说明其缺陷，前提是这不是简单的合规性勾选式评估。

另一方面，第三方审查可能会很昂贵、耗时，如果没有经过良好的规划和与组织的合作，它们可能缺乏相关性。

总体而言，安全评估既有积极的一面，也有消极的一面。它们有可能会让组织付出时间、金钱，并减少创造新价值的能力，但它们也提供了揭示安全问题的机会，这些问题如果不处理，可能会通过声誉损害、法规问题或盗窃等带来更大的财务损失。

让我定义一下每项评估可能涉及的内容。

自动化评估和扫描

在自动化评估和安全扫描中，你依赖软件根据收集的各种信息，检测已知的安全漏洞，并将这些信息与漏洞数据集进行对比。让我简要说明几个可以进行自动扫描的场景。

Web 应用程序漏洞扫描器

通常，Web 应用程序漏洞扫描器可以指向你的组织的 Web 应用程序的 IP 或 URL，并让它“扫描”漏洞，方法是解析HTTP 响应来获取有关软件的信息。然后，它可以将这些信息与已知漏洞的数据集进行对比。

除此之外，他们还可能检查暴露的文件，这些文件可能被用来访问机密信息或提升权限，例如在 WordPress 站点中找到/readme.html，从而揭示 WordPress 版本信息。

许多扫描工具会包括模糊测试器，用于检查SQL 注入和跨站脚本攻击（XSS），以便检测以前未发现的漏洞。模糊测试器自动化了渗透测试者（或恶意攻击者）为确定用户输入是否存在漏洞而进行的初步过程，一旦发现漏洞，测试者会花时间修改并利用该漏洞来获取信息或访问权限。

此外，如果你的网页应用允许登录功能，大多数网页应用漏洞扫描工具都会允许你提供凭证进行身份验证，这将模拟来自已经“突破”登录屏障的恶意攻击者的攻击。

许多付费的专有网页应用漏洞扫描工具会内置不同类型应用的“配置文件”，以减少扫描时间或模拟不同程度的攻击。

一旦扫描工具配置正确，你就可以对组织的网页应用进行扫描，完成后，软件通常会将发现结果整理成报告或网页仪表盘，报告中会解释每个发现、基于风险的漏洞评分，以及潜在的修复步骤。

如果你的网页应用面向外部世界，很可能恶意攻击者已经对你的服务器和应用进行过自动扫描，以检查是否存在漏洞，通常使用下面列出的开源工具之一。很难通过IP 黑名单来阻止这些攻击，因为它们通常来自被攻陷的机器的 IP 地址，或者根本不遵循特定的模式。这类活动时时刻刻在互联网各处发生。这些扫描往往来自那些寻求“低挂果实”的团体，因此，对自己的应用进行扫描并分析结果是否会引发潜在机会是很重要的。网页应用防火墙能够检测这些活动，并防止泄露过多信息，但在这方面，最好的防御方式是确保及时实施服务器操作系统和网页应用软件包的安全更新。

以下是一些网页应用漏洞扫描工具的示例，分为专有和开源选项：

专有：

a) Tenable.io/Nessus

b) Rapid7 InsightAppSec

c) Acunetix

d) Detectify

e) WP Scan
开源：

a) Nikto

b) OWASP Zed Attack Proxy（ZAP）

c) w3af

d) OpenVAS

如果你计划设置自己的网页应用漏洞扫描工具，无论是开源的还是供应商提供的，你应该考虑一些常见问题，涉及漏洞扫描活动的实施。

你有资源维护一个内部系统吗？

如果你没有专门的员工负责维护内部漏洞扫描器的工作职责，那么将此需求外包给提供托管服务的第三方可能是有用的，第三方将维护和更新扫描器，确保你获得最新和相关的结果。

另一个值得问的问题如下：

你打算扫描你的生产 Web 应用程序吗？

如果你的组织依赖于 Web 应用程序赚钱，并且与客户有 SLA 来确保正常运行，那么是否有意义对其进行扫描，这可能会导致它变慢或停机？

另一种解决方案是建立一个渗透测试或扫描环境，它是你生产环境的1:1 克隆，在软件方面与生产环境相同，但使用虚拟数据集，通常运行在完全独立（且便宜得多）的硬件上。这个解决方案有许多优点：

你可以将 IP 列入白名单，指定扫描器的IP 范围，该范围通常由供应商在文档中提供。如果你自己设置了 Web 应用漏洞扫描器，你应该知道这些 IP。这使你能够限制服务器需要做的工作量，从而确保该环境的需求比生产环境低，成本显著低于真正的复制环境。
你避免了因扫描而导致生产系统停机的风险，因为测试环境与产生收入的系统不共享任何资源。
你可能在生产环境中有一个Web 应用防火墙（WAF），但在渗透测试环境中，你可以专门测试你的应用程序，而不是测试 WAF 本身。在这种情况下，你可以通过 WAF 将扫描器 IP 列入白名单，从而使请求可以不经过检查地通过。

在测试环境中使用不同的凭据和帐户，并使用虚拟数据集而非生产数据集，以确保隐私和保密性，通常也是个好主意。此外，拥有一个“渗透测试”数据集，它占用的存储空间比生产数据集少，也可以节省资金。

网络漏洞扫描器

网络漏洞扫描器在功能和操作上与Web 应用漏洞扫描器非常相似，但它们专注于你组织的网络环境，包括员工使用的设备和服务。

许多漏洞扫描器供应商将 Web 应用程序和网络扫描合并到他们的解决方案中，提供一种“一体化”或“单一视窗”的统一自动漏洞评估方法。

通常，你希望网络漏洞扫描器执行以下任务：

发现网络中的设备和软件资产。
确定设备的软件版本和操作系统版本。
检查从收集的信息中获取的已知漏洞。
根据风险/漏洞分数报告并优先排序修复步骤。

许多解决方案提供额外的功能，包括以下内容：

深网监控，检查你的组织的凭证是否已在市场上被检测到
记录网络事件，如用户活动，并与警报进行关联
一个用于网络（NIDS）、主机（HIDS）和云的入侵检测系统（IDS）
端点检测，可能来自网络事件启发式分析

本质上，这意味着网络漏洞扫描器软件能够收集有关你内部网络环境的信息，然后判断是否存在恶意行为者可能利用的漏洞，从而进入你的网络并在网络内部“转移”以提升其特权，最终导致网络被攻陷。

如果你的组织使用过时的操作系统，如Windows 2008 或 2012 服务器或Windows 7 桌面，那么你的网络漏洞扫描器将像圣诞树一样亮起，你将不得不完成大量的工作来修复这些问题。也就是说，运行这个扫描要比支付数千美元给安全公司，然后让渗透测试员在几个小时内攻陷你的网络要便宜得多。通过修复网络漏洞扫描器中发现的问题，你在去除低悬果实，并增加了入侵你组织网络所需的技术水平。

一些网络漏洞扫描器的例子，分为专有和开源选项，可能包括以下内容：

专有：

a) Microsoft Security Suite

b) Tenable.io/Nessus

c) Rapid7 InsightVM

d) AT&T Cybersecurity USM Anywhere

e) Acunetix

f) Detectify

g) WP Scan
开源：

a) Nikto

b) OWASP Zed Attack Proxy（ZAP）

c) w3af

d) OpenVAS

除了在环境中进行漏洞扫描之外，还需要考虑你组织开发的任何软件中的漏洞，因此让我们更详细地看一下这个场景。

软件开发生命周期（SDLC）或 DevSecOps 扫描

如果你的组织开发软件，无论是供内部使用、客户使用，还是供公众使用（包括网站），那么在软件开发生命周期（SDLC）中实施安全实践是至关重要的。

在整个过程中有许多机会和阶段可能会引入漏洞，在 第八章 提高软件的安全性中，我们将深入探讨如何提高软件的安全性并加强安全的软件开发生命周期。直到那时，还是值得关注可以在过程中实施的扫描器，用来检查漏洞代码或软件包，包括以下内容：

静态应用程序安全测试（SAST）工具会扫描你的软件源代码。它们通常会集成在开发人员的**集成开发环境（IDE）**中，或者被设置为自动扫描你代码库中的新条目或提交，例如 GitHub、BitBucket 或 GitLab。通过扫描源代码，软件可以找到常见的陷阱和错误，这些错误可能导致应用程序漏洞，例如 XSS 和 SQL 注入，即使在应用程序上线后。常见的 SAST 工具示例包括 GitLab 集成的 SAST 工具和 SonarQube / SonarCloud。
动态应用程序安全测试（DAST）工具本质上与之前讨论的 Web 应用程序漏洞扫描器相同。它们允许你在软件编译并运行后，通过信息收集和模糊测试对软件进行扫描。通常，DAST 与软件开发生命周期相关，理念是你可以自动触发对每个由开发人员修改的应用程序源代码的临时测试环境的扫描，并根据扫描结果，如果该更改不符合安全基线要求，则拒绝该更改合并到生产代码库中。基本上，我的意思是，Web 应用程序漏洞扫描器通常能够配置为软件的CI/CD 管道中的 DAST 工具，或者定期进行扫描。

DAST 工具的示例包括 Acunetix、Rapid7 InsightAppSec/AppSpider、Tenable.io/Nessus 以及 OWASP 的 Zed 攻击代理（ZAP）。
依赖扫描工具允许你扫描软件导入的依赖项。开发人员通常会利用其他方已创建的软件，这避免了耗时的开发过程并减少了实现的复杂性，但也增加了将已知漏洞引入软件的可能性。依赖扫描器会将导入的模块及其版本与已知漏洞的数据库进行比对，以确保你的软件不会使用到存在漏洞的第三方代码版本。

依赖扫描器的示例包括以下内容：

a) Snyk.io 评估多个语言的导入，包括 JavaScript、Java、.NET、Python、GoLang、PHP 等。

b) Node 包管理器（NPM）为 JavaScript 提供了一些内置的依赖扫描器。

c) OWASP 依赖项检查项目。

现在我们已经讨论了如何对你组织的数字资产进行自动化扫描，我认为有必要进一步探讨可以由你组织内部员工执行的其他内部评估。

内部评估

内部评估是指那些无需外部（第三方）专家帮助就能执行的评估。我们来看一下你可以进行的几种不同类型的内部评估。

员工安全意识评估

我们已经讨论过，在我们的组织中给予员工安全意识测试，以确保他们已经吸收了提供的信息，并作为对您的合规性审计的尽职和持续改进的证据。一种方法是让员工需要以问答形式回答标准化测试题，以展示他们的知识水平。

另一种方法是利用工具，例如对员工进行钓鱼训练，例如发送他们已经接受培训以识别的电子邮件，并记录他们的响应指标。如果维护内部软件和创建新的电子邮件模板的开销在内部无法承受，则第三方也可以作为托管服务来执行此项工作。

合规性审计

如果您的组织受到诸如通用数据保护条例（GDPR）或加州消费者隐私法（CCPA）之类的法规，或者诸如ISO27001或 PCI-DSS 之类的标准约束以执行其核心业务目标并为客户提供服务，那么理解您的控制措施的有效性，并找出合规要求与实际情况之间的差距就非常关键。

为此，可以进行内部合规审计，作为对将来由监管机构或代表其进行检查的第三方审计的准备。模拟第三方，并调查证据是否存在，以评估控制实施对要求的有效性，是在您真正支付昂贵的审计员前来对您的组织进行评估时，减少时间和精力消耗的绝佳方式。

您必须确保做好记录，并确保所有要求被适当的员工了解，以便实施适当的控制并保持合规性。像Microsoft Compliance Manager这样的软件解决方案可以跟踪、分配、安排和记录对超过 300 个全球法规的合规性观察，并提供关于实施方法的解释和指导，这些方法在您的组织中可能非常有效。

红队和蓝队

如果您拥有一个合格的内部安全团队，您可以将团队分为红队（攻击团队）和蓝队（防御团队），以模拟恶意行为者的攻击方法来攻击您的组织，测试防御团队应对这些攻击的能力，并减少可能造成的损害。

较小的组织在这项工作中将比拥有非常庞大安全团队和大预算的大型企业更加困难，但即使是大型组织也可能发现他们的团队更适合执行防御措施，而不是渗透测试人员已经掌握的攻击性措施，所有这些措施都可以通过第三方参与利用。

有了这些，我们来看一下可以由你的组织进行的第三方评估。

第三方评估

当你想评估你的控制措施在风险评估或内部评估中所估算的有效性时，你会想引入第三方评估员。当你想测试你的蓝队的有效性时，你会想引入第三方评估员。如果你想向潜在和现有客户展示你的安全效果时，你会想引入第三方评估员。当你想遵守标准和法规时，你需要引入第三方评估员。

你可能有很多原因想要或需要引入第三方。归根结底，这涉及到两种特定的理念：客观性和技能。

在安全公司工作的渗透测试员每天都获得报酬，去“攻占”客户系统，这些系统可能非常先进，也可能是“普通”的。它们使用恶意行为者可能使用的工具，并且在攻防安全方面高效且熟练。此外，由于没有受到办公室政治或既得利益的影响，他们无需讨好你们公司的人；他们是客观的，他们的报告通常清晰、标准化，并且具有可操作性。

第三方可以进行多种评估，且新的“类型”不断涌现。我将提供几个例子。

考虑到我们可能（潜在地）将以下任何安全评估作为内部审查进行，而不是让第三方组织执行测试。

技术评估和渗透测试

技术评估和渗透测试有多种形式，但通常，评估的重点是查看是否可以利用漏洞来获取访问权限，并在此基础上提升权限，直到能够访问机密或敏感数据为止：

Web 应用渗透测试是由渗透测试员或多个渗透测试人员针对Web 应用程序进行的测试。它模拟了一个恶意行为者试图通过 Web 应用中的功能和/或漏洞来获取访问权限并提升权限。
网络渗透测试是由渗透测试员或多个渗透测试人员对组织的网络环境进行的测试。它模拟了一个恶意行为者试图通过安全漏洞远程获取访问权限并提升权限，或者模拟一个内部威胁，假设其初始访问权限有限，然后通过安全漏洞提升权限并访问机密或敏感信息。
红队和黑队 是模拟威胁的活动，复制恶意行为者尝试通过任何必要手段渗透进入您的组织的情景。红队通常专注于信息安全，而黑队则通常专注于物理安全。

红队和黑队都比传统的渗透测试需要更多的计划和侦察工作，但它们总体上代表了更高质量的测试。这对于那些已经建立良好信息安全实践和程序，并在其员工中具有被证明的控制有效性和高级别安全意识的组织非常有价值。通常，蓝队将意识到这一参与，并准备好保护其资产，这需要您的组织进行计划和准备。

继续从渗透测试出发，接下来我们将关注风险管理和治理评估。

风险管理和治理评估

远离技术评估，我们转向“无聊”的合规审计和认证审查世界。在这里，业务流程和政策将被审查和测试其有效性，需要证据来满足审计员的要求。我之前提到过这些审计; 例如，它们可以包括PCI-DSS 合规评估或ISO27001 认证评估。

只要审计员技术娴熟，您与评估人员诚实开放，这些评估可能具有巨大的价值。这些评估人员可以发现您流程和程序中的漏洞，并识别您可能没有考虑到的风险，以便轻松地由您组织内的业务利益相关者理解。

不幸的是，如果评估人员没有足够的时间参与，或者没有足够的权限从头到尾对公司进行全面评估，他们可能会错过漏洞和间隙。这就是为什么与评估人员保持诚实和开放，确保您的组织从评估中得到物有所值的重要性所在。

考虑到第三方安全评估可以分为这两种“风格”，我们可以理解以下内容：

涵盖整个组织安全姿态的评估通常会是技术和风险管理评估的混合。
对您的硬件产品安全控制效果的评估通常会归入技术评估。
对您的软件产品安全控制效果的评估也是如此。
评估建筑物安全可以通过技术或风险管理评估来完成，但通常我们会考虑“黑队”。
你的员工安全意识的第三方评估可以包括钓鱼演习或红队/黑队参与。
您的安全团队应通过红队评估来应对主动威胁，在此过程中，您的团队充当蓝队，保护组织的资产。

让我们继续讨论执行安全评估时的最佳实践。

执行安全评估的最佳实践

无论您的组织是在进行内部评估，还是聘请第三方评估其信息安全状况，都有一些最佳实践可以有效确保评估的价值最大化。

关键要点如下：

确保评估有足够的时间进行彻底完成。匆忙进行评估没有意义，但同样重要的是确保测试不会拖延，确保您宝贵的 IT 和安全人员能够专注于评估，而不是日常工作需求。
确保测试范围已定义，以避免进行不相关的评估。
确保测试人员和协助测试人员的内部员工都经过良好的培训，准备充分，并且具备相关知识，以提高评估的价值。

还有一些过程可以在不依赖于纯粹出于合规性要求的测试和审计的情况下，用于有效选择合适的评估。

这些过程可以包括以下内容：

定义业务需求。
定义信息安全目标和策略。
从内部角度审查感知的优势和劣势。
对资产进行风险评估，包括已知的威胁和漏洞。
执行并记录来自网络和 Web 应用程序漏洞扫描的结果。
审查并记录系统的安全控制有效性，包括防火墙、VPN、客户端、访问控制机制和其他信息系统。
审查并记录来自访问控制列表和访问日志的发现。
审查并记录员工的安全意识。

一旦您收集了尽可能多的关于组织的信息（其中许多内容在我们之前多次讨论的风险管理阶段已经完成），您将能够基于风险做出决定，选择需要评估的资产，这样可以比仅仅对所有事物进行完全测试更有效地利用您的预算。

关于最佳实践的另一个简短说明是我之前提到过的：我认为为自动化扫描和（一些）渗透测试设置一个虚拟环境是值得的。这减少了使生产系统停机的风险，并且通过使用虚拟数据，避免暴露真实的客户数据或机密商业信息。这是一种成本效益高的解决方案，用来降低由于安全评估而导致的停机风险。权衡之下，一些认证机构、监管机构和客户可能不会像测试生产环境一样看待对克隆环境的测试，但这些情况可以在出现时进行处理。

在第三方测试结束时，评估人员会花时间撰写报告并提供结果。这些结果是为你的组织带来价值的，而不是支付费用仅仅为了勾选一个框并继续在不必要的风险下工作。这就是为什么诚实能够带来更好的、可操作的改进。你支付专业人士的费用是为了告诉你你的弱点，所以要诚实，获取真实的结果，而不是支付第三方费用后误导他们远离你流程和实践的实际情况，这样你的组织就能继续重复犯同样的错误。

让我们来看一下这些结果是如何呈现的。

解释安全评估结果

当我们查看安全评估的结果时，有两种类型，类似于我们在上一节中对第三方评估的划分。这两种类型分别是技术评估和风险管理与治理评估。

这两种类型的报告通常会尝试通过给每个发现的漏洞分配一个分数（可能是 1-5、1-10，或其他量表）来量化漏洞带来的风险水平。重要的是，你需要在风险评估过程中考虑资产的价值，因为有时一个漏洞可能被认为具有较高的可利用性，但可能不值得去缓解，因为它不会保护任何有价值的东西。换句话说，所呈现的风险水平低于风险接受水平。

通常，技术报告会包括渗透测试如何逐步进行的叙述，并附有截图、命令和其他信息，以帮助客户复制发现的结果并测试他们的修复措施。这些对于信息安全专业人士来说是无价的贡献，因为它们不仅作为你组织 IT 员工的教程，还帮助你将威胁呈现给非技术人员和高层管理人员。它为恶意行为者的思维提供了一个很好的第一人称视角，并有助于让威胁变得更真实。

在涉及第三方审查时，无论报告是技术性的还是非技术性的，通常都会包含由第三方交付的图表、图形和展示材料，并以“发现展示”的形式呈现。将公司相关利益方纳入会议非常重要，因为许多人不会阅读 PDF 报告。说实话：大多数人邮箱里有成千上万封未读邮件，那为什么他们会关注你那份枯燥的 PDF，里面写的是他们的业务是如何被轻松攻破的呢？

除了这些发现外，还会有修复步骤的建议。这些页面的价值不可估量。你基本上是在“坏人”告诉你如何防止他们（或具备相同技能的其他人）下次进入！因此，我的建议是按照他们的指导进行操作。你将需要计划如何更新和重构系统、修改密码以及招聘员工，所以第一步是确保你有必要的资源和批准。记住：发现展示将会唤醒高层管理人员，并成为一个很好的机会，让你在问题尚在他们脑海中的时候请求批准这些资源。

同样适用于内部审查，包括自动化评估和扫描的结果。你有度量标准以及可以采取的措施来控制风险，这些内容已经被量化，并以引人注目的方式展示，以帮助你向高层管理人员展示你的发现。不要错过向老板展示你信息安全计划价值的机会——这就是他们支付你薪水的原因。

在修复阶段，进行内部验证是非常重要的。这可以成为一个有益的机会，帮助 IT 和开发人员了解安全漏洞的危险，同时也提高了你组织的整体安全意识。此外，内部验证修复措施可以避免尴尬，因为你最不希望发生的情况是安排第三方进行后续测试，结果他们又做了完全相同的事情，浪费了时间、金钱和资源。

这让我进入最后一个要点：持续改进。你需要安排后续检查，以验证你的修复措施是否有效，然后你还需要为未来安排另一个测试，看看评估人员能否发现其他弱点。

总结

现在我们已经到了这一章的结尾，我知道你已经能够理解安全控制测试，包括如何安排外部和内部的安全审计，如何分析报告和审查测试结果，以及如何管理每次评估中产生的行动。

现在你已经了解了，可以进行各种不同的安全评估，以帮助你了解如何保护和改善整个组织的安全态势，以及你的网络和数字资产，从组织所创建的硬件和软件到物理安全和员工意识。

此外，你现在也知道了进行这些类型评估的不同方式，例如让你自己的员工进行内部审查，或是让其他组织进行第三方审查。此外，还可以进行自动化评估，你也了解了几种不同的自动化安全测试方法。

在我们讨论了安全评估如何帮助你的组织改善安全性并简化操作之后，我认为接下来讨论第七章，拥有安全运营，是有意义的。

第七章：掌控安全操作

你已经实施了自己心中对卓越且持续改进的信息安全战略的愿景，并且采取了适当的控制措施，以确保你的组织安全且合规。做得很好！接下来，你打算如何保持对事情的掌控？在发生安全事件或事故时，你将如何调查？我们需要做什么才能确保在线运作，保持组织资产的可用性，并使员工能够不受干扰地进行日常工作？本章专注于安全操作这一永无止境的任务，以及它如何与组织的商业愿景对齐。

本章将讨论以下主题：

配置资源和维护资产的有效策略
聚焦于可用性、灾难恢复和业务连续性活动
管理升级、打补丁及应用安全控制
事件调查与事故响应
实施和利用侦测控制
使用安全监控提高可见性
安全监控最佳实践

让我们开始吧！首先，我们来看看配置资源和维护资产的一些有效策略。

配置资源和维护资产的有效策略

Automox 在 500 至 25,000 名员工的公司中进行了一项调查，超过 500 名 IT 和信息安全专业人士回答了相关问题（www.darkreading.com/vulnerabilities---threats/missing-patches-misconfiguration-top-technical-breach-causes/d/d-id/1337410）。Automox 发现，过去两年内，超过 80%的公司曾遭遇过安全 breaches，以下数字显示了在这些攻击中被利用的漏洞类型：

操作系统补丁缺失（30%）
应用程序补丁缺失（28%）
操作系统配置错误（27%）

在成功的网络钓鱼攻击或凭证收集后，通常会发生一连串事件，这些事件往往会利用前面提到的某个漏洞。关键是，我们可以通过提供经过批准的配置并确保资产得到维护（包括操作系统和应用程序补丁与更新）来防止这种情况发生。

本节将讲解我们如何确保在整个生命周期内，资产始终得到维护并保持最新。这个过程是持续的，但它能节省时间和精力，并确保组织能够创新其产品，而不是单纯地应对信息安全威胁并急于更新遗留软件。

资源配置

在数字资产中，信息系统不断地被添加、移除和修改。不幸的是，这通常是没有任何监督或缺乏最佳实践指导的情况下进行的。

当我们将新资产添加到我们的资产池时，涉及什么样的流程？我们是否“只是做了”，没有定义更广泛的策略？我们对资产版本或操作系统有何种可视化？

此外，在云计算时代，部署只需要在浏览器中点击几下按钮，我们如何避免影子 IT（在没有 IT 部门批准的情况下使用系统、设备、软件或其他 IT 解决方案），并确保当组织中的员工“启动一个新服务器”时，遵循我们的流程，并考虑到我们的信息安全策略？

政策

随着你在本书中的阅读进展，你已经习惯了我对政策的看法：在信息安全政策文档中定义你的方法的力量是至关重要的。信息系统的配置和维护也同样如此。我们需要具体指导用户找到正确的答案。你不一定需要在政策文档中直接定义“批准”的操作系统版本或应该禁用哪些功能；事实上，我建议不要这样做，因为这将需要不断更新以保持相关性。

你可以指向一个不断更新的资源，类似于“批准的操作系统版本和配置可以在这里找到：。” 然后，在链接的文档中，可以更新并根据你的策略调整信息，无需维护文档，同时确保每个人都能获取到正确的信息安全政策版本。

配置管理

当我们查看上述包含“批准”配置的链接时，应该如何处理？我们从哪里获取“良好”的配置？如何定义我们组织需要什么，以确保操作的持续性？

幸运的是，市场上有软件配置管理（SCM）工具。常见的选择包括以下几种：

Microsoft 系统中心配置管理器 (SCCM)，或配置管理器
SolarWinds 服务器配置监控器
Ansible/Ansible Tower
Puppet
Chef

这些工具提供各种功能，包括以下内容：

远程管理
补丁管理
软件分发
操作系统部署
配置管理
维护每个资产的软件和硬件清单

作为信息安全专业人员，这可以从多个方面帮助你。考虑到你现在拥有一份资产清单，以及每个资产使用的软件。这可以帮助你完善资产和风险登记表，并提供每个资产的实时准确信息，同时简化如审计等特定时间点的评估。通过配置管理，我们还确保记录所有更改，以便于轻松排查配置错误、停机、性能下降和不符合标准的来源，并提高系统的可审计性。

此外，我们有可用的治理结构，以便设置基准配置并实施变更控制流程，确保对生产系统的任何更改都是以系统化、计划好的方式进行的。通过实施这些治理控制措施，例如要求管理员在进行系统或网络配置更改之前验证所做的更改（职务分离），你可以降低配置错误导致停机或安全漏洞的风险。

运营员工可能会对建立治理结构提出反对意见，抱怨例如“这与我们以前的工作方式相悖”或“这会让我们变慢”。请记住，从组织的角度来看，节省的时间（无需恢复系统）、节省的费用（避免违反服务水平协议）、防止声誉损害以及在确保系统得到适当维护并设置了检查和制衡的情况下放心前行的心态，将弥补在变更时可能出现的轻微速度损失（如果真有速度损失的话）。流程的自动化可以帮助消除障碍，防止许多员工预测的那种麻烦。

当我们考虑有效使用配置管理工具时，应考虑以下实践：

确保将系统分类并分组到对组织有意义的分类法中。这些类别和子类别可以批量更改，因此请确保你和你的同行架构师在设计时考虑到这一点。
我们需要定义“已批准”的基础配置，并记录每个配置的理由和标签。像互联网安全中心（CIS）这样的组织提供“加固镜像”。这些操作系统和应用镜像很可能已经符合安全配置指南，比如 CIS 基准，能够快速、轻松地在云环境和本地环境中部署安全系统，而无需自行定义要求。更多信息可以参考www.cisecurity.org/cis-hardened-images/。
在更改系统时，所有关于更改的信息（用户、时间、所做更改、受影响的系统）应当被记录和追踪，并且过程应当遵循有效的职责分离原则，以确保没有个人能够做出破坏性更改。
确保测试环境和生产环境之间的一致性，包括操作系统、软件版本、网络配置等。环境越对齐，当变更推向生产时，出现停机或未发现漏洞的可能性就越小。
在出现故障的情况下，还可以自动化回滚或修复的过程。

话虽如此，许多组织正在向一种名为基础设施即代码（IaC）的理念转变，这与DevOps和持续集成/持续部署（CI/CD）的 IT 管理和软件开发方法密切相关。让我们来看一下 IaC 的优势。

基础设施即代码

有一个叫做 IaC 的概念，从安全角度和 IT 运维角度来看，它都是一种非常有益的方法。IaC 的基本思想是，您的基础设施不再仅仅是特定位置的物理服务器，而是越来越趋向于完全虚拟化、分布式的云环境。因此，您不再需要配置、管理、扩展和停用物理硬件，或者使用传统的、专为这些硬件设计的交互式配置管理工具，而是可以在机器可读文件中定义您的基础设施和所有信息处理设施，这些文件像软件代码一样版本化并更新，供自动化软件在无需人工干预的配置/扩展/停用过程中引用。

这个想法与DevOps和CI/CD实践紧密相关，而不是传统的 IT 运维与软件开发人员之间的分离。IaC的目标，以及大多数DevOps和CI/CD实践的目标，都是通过减少错误频发的手动流程，提升改进的速度，加快部署并提高效率，从而部署更高质量的软件。

在我们讨论 IaC 工具和格式之前，我想提到的是，IaC 范式通常涉及利用容器和编排软件，如Docker和Kubernetes。

Docker 根据Dockerfile 中定义的指令构建容器镜像，Dockerfile 是一个文本文件，包含构建系统镜像所需的所有命令（例如应用程序及其依赖项），这些镜像被称为容器。容器是虚拟机的轻量级替代品，它们已经与运行它的服务器底层基础设施解耦。因此，一个服务器可以运行基于数千种不同配置的容器，每个容器可能包含不同的操作系统和软件包。关于 Docker 工作原理的进一步阅读可以在这里找到：docs.docker.com/get-started/overview/。

关于如何定义和编写Dockerfiles的进一步阅读可以在这里找到：docs.docker.com/develop/develop-images/dockerfile_best-practices/

编排软件，如Kubernetes，有助于自动化在分布式环境中部署这些容器，并帮助管理、部署和扩展容器的操作方面。编排软件行为的基础配置通常定义在YAML文本文件中，并且可以通过前端 Web 应用界面或命令行工具进一步修改。有关 Kubernetes 的进一步阅读可以在这里找到：kubernetes.io/docs/concepts/overview/what-is-kubernetes/。

你可能会问：“我为什么要简要探讨这些内容？”我想从信息安全的角度突出一个要求，那就是紧跟你组织运作方式的变化。IT 变化极快，理解新技术背后的概念非常重要，以确保流程和解决方案的安全性。在这个例子中，应考虑如何确保这些工具和文本文件进行安全性检查并进行版本控制。这些新的软件打包和部署方式正在逐渐成为你组织基础设施建设的方式，如果没有你组织定义的适当治理和流程，它们可能为恶意行为者提供了利用漏洞的机会。

在基础设施即代码（IaC）方面，在创建了用于包装和部署你组织中的应用程序所需的 Dockerfiles/YAML 后，你需要确保部署软件的基础设施被正确配置。接下来就是持续配置自动化（CCA）工具的作用。CCA 利用 IaC 的原则，并参考 IaC 定义文件，以自动化我们之前提到的 IT 配置管理方面。

你可能会问：“好吧，如果你只是想告诉我们那是旧的方法，且现在有了更好、更新的方法，那你为什么还要提到配置管理工具呢？！”

最棒的是，你通常还是在使用之前相同的工具组！一些流行的 CCA 工具包括以下几个：

Ansible/Ansible Tower
Chef
Puppet
SaltStack

与之前的列表相比，我们可以看到传统的配置管理工具与 CCA 工具之间存在重叠，例如 Ansible、Chef 和 Puppet 等。这些工具提供了传统的“前端”配置仪表盘，可以通过浏览器访问，并提供我们期望并要求的图形化库存管理和报告功能，这些是我们从传统配置管理工具中所期待的。

这些DevOps 导向的理念、工具和解决方案为开发人员和系统管理员提供了一个机会，可以简单地在他们的代码中“声明”要部署的基础设施，自动化工具接收该声明，然后参考预定义的“批准”蓝图，这些蓝图可以配置以确保符合安全性和合规性要求，（通常称为政策即代码）。

因此，就像我们能够为人类阅读创建政策一样，我们也能够将这些政策定义为机器可读格式，确保每次都以自动化、无错误的方式部署适当的配置。我们现在拥有一个可审计的、可测量的、预定义的“批准”基础设施和部署场景，并且这些场景会不断监控是否有未经授权的更改，任何绕过或不合规的行为都会被拆除，同时用符合规范的版本替换掉。考虑到你的风险，这是绝对完美的。此外，我们在过程中解决了许多完整性和可用性的问题，前提是工具可靠，解决方案为你的组织精心设计。

从保密性的角度来看，我们能够通过利用密钥管理自动化工具（如HashiCorp Vault）来自动创建和声明超级强大的密钥、令牌、密码和密钥，这些内容永远不会由个人处理。

通过密钥管理，你可以以编程方式动态地创建、撤销和轮换组织的密钥，响应根据政策定义或检测到的活动所设定的变化或需求。这样，你可以实现对静态或传输数据的高效加密，且对密钥没有任何知识，并能记录所有交互的审计日志。此外，密钥管理过程的自动化可以为授权提供高效的即时解决方案。

当然，IaC CCA 方法也存在一些缺点。像Docker Hub这样的社区仓库，包含了数十万已经被“弃置”或“腐烂”的容器配置文件。这些文件包含过时的定义、不良的安全实践，或者有意写入的后门和恶意软件，等待那些匆忙（或无法正确阅读和理解文件）的人将漏洞部署到他们的系统中。

记住，这并不是一个极端案例。Palo Alto Networks 的威胁情报团队曾发现，2019 年 65%的公开披露的云安全事件是由于组织员工的错误配置所致。当他们调查为何这个数字如此之高时，他们发现那些采用 DevOps 方法的公司内部有一种文化，强调创建新功能的速度，而非治理和安全。再加上对速度的推动，数十万个高风险模板在受信任供应商（如 Docker Hub）开放源代码、可搜索的仓库库中免费提供。有关此主题的进一步阅读可以在这里找到：www.paloaltonetworks.com/company/press/2020/palo-alto-networks-report-finds-poor-security-hygiene-leads-to-escalating-cloud-vulnerabilities。

考虑到这一点，我们可以达成共识：即使在事物的核心是高度自动化和加速的情况下，IaC 也无法消除实施和遵循变更控制和审批流程的必要性。我们必须记住，省略这些治理步骤会增加实施变更时引入未知风险的可能性。

一些适用于 IaC 部署管道的过程和程序的合适理念可能包括以下内容：

确保你为用户实施了最小权限原则。你不希望给他们“城堡的钥匙”或让他们有机会关闭流水线中的某些功能，从而绕过某些保护和检查。此外，应该没有任何方法让用户能够访问他们已部署代码的生产服务器。
在开发和部署过程的多个阶段，可以对定义基础设施的机器可读文本文件进行安全检查和扫描：

– DevOps 工程师或开发人员可以在他们编写代码的 IDE 中扫描文本文件，检查是否存在已知的错误配置和镜像。

– Git 仓库，如 GitHub、GitLab 或 Bitbucket，可以与安全扫描器集成，以检查文件中是否存在已知的配置错误或恶意项。像Snyk.io这样的解决方案可以参与 CI/CD 流程，确保正在使用的 IaC 定义是安全的。

– 像 Snyk 这样的工具能够扫描 IaC 配置文件，报告容器是否以特权模式/特权用户身份运行，或者是否未设置内存和 CPU 限制等漏洞。

– 这些扫描还可以检查基础设施是否运行在最新且安全的操作系统和应用版本上。
IaC 工具本身应该得到维护，我们需要确保我们正在运行最新、最安全的版本。

总结来说，使用 IaC，我们能够实施自动化方法，以减少配置错误和过时基础设施的风险，包括通过变更控制阶段发生的管道安全扫描。

通过自动化和适当的测试，你可以通过去除部署、更新和变更过程中的人为因素来减少错误的风险。一份好的脚本在每次执行时都能有效运行，并且需要员工的参与时间和精力更少。

这些自动化解决方案应该防止在检测到不可接受的风险水平时部署基础设施，你的工作是确定适合你组织的风险水平，并将其传达给相关人员。

此外，通过适当的监控和变更检测，我们可以确保系统在停机或类似事件后可预测地恢复。例如，如果只有一台服务器出现故障，我们可以创建规则自动部署该服务器的镜像来替代它，而不是等待员工注意到故障、诊断故障原因并修复问题。

关于停机的问题，我认为现在是时候转向讨论专注于可用性、灾难恢复和业务连续性了。

专注于可用性、灾难恢复和业务连续性

我们在谈论信息安全时需要诚实；它并不总是为了防御那些试图窃取我们组织珍贵知识产权的恶意黑客。实际上，在你的职业生涯中，你会面临的许多场合都涉及由于停电或软件更新失败等原因导致生产系统宕机的情况。

仅仅因为这些威胁不是敌对性质的，并不意味着它们不真实。事实上，情况可能恰恰相反：我们可能会比面对恶意攻击者更频繁地遭遇非敌对事件导致的停机。因此，我们需要确保拥有有效的变更控制政策，并严格遵循这些政策，我们还需要定义和演练灾难恢复和业务连续性流程，以确保最大限度地减少停机时间。

定义、实施和测试灾难恢复流程

灾难恢复是建立适当文档、规划和实践的过程，确保我们能够从自然灾害或人为灾难中恢复，并恢复关键的业务功能。它与业务连续性不同，业务连续性专注于确保所有关键的业务功能在任何破坏性事件或灾难发生时仍然保持在线并正常运作，而灾难恢复则是关于恢复。

例如，正如我在前面的章节中所讨论的，您的组织可能面临自然灾害，如洪水、地震和龙卷风。在我写这本书时，全球范围内正在发生大流行和战争活动。您可能会面临危险废物事件、爆炸，甚至是导致您的业务下线或人员不得不离开常规工作空间的网络攻击。

对于所有这些灾难，我们面临着潜在的损失。2015 年，IT 灾难恢复准备（DRP）委员会报告称，小型企业在每小时停机的情况下可能面临最高 8,000 美元的损失。同一报告中，中型企业每小时可能面临最高 74,000 美元的损失，而大型企业在灾难发生时每小时的损失可能高达 70 万美元。更多阅读内容可以在这里找到：www.researchgate.net/publication/343063858_PLANNING_FOR_DISASTER_RECOVERY_CAN_LEAD_TO_AVOIDING_DISASTER。

为了准备适当的灾难恢复计划，我们需要一些文档，这些文档看起来非常熟悉，因为我们在本书中反复提到了相同的内容：

清晰、直白的操作手册，任何人都可以在没有干扰的情况下跟随。这意味着清晰的标签和确保可用性（即使在停机或外部场景下）。
政策文件，清楚地说明您组织的角色和职责，以及从业务角度的需求，这些可能包括来自监管机构的合规要求或服务级别协议（SLA）。

一旦这些文档创建完成，优先级第一的任务是审查这些计划——不仅要进行桌面演练，还要进行实际的场景演练，进行实际的疏散以及基础设施和系统恢复操作，以发现从理论到现实的任何逻辑或技术上的漏洞。如果发现任何漏洞，必须进行补救计划并实施，然后重新创建测试场景，以验证更改的有效性。

当然，这一切都围绕风险展开。你专注于最关键的资产和系统，并根据哪些对业务运营至关重要来优先恢复活动。

与灾难恢复密切相关，以至于我不知道应该先谈哪个，我想简要谈谈业务连续性，尽管我在前面的章节中已经提到过它。

管理业务连续性设计、规划和测试

与灾难恢复紧密相关的功能是业务连续性。业务连续性专注于确保所有关键的业务功能在受到干扰事件或灾难的情况下仍能保持在线并正常运行。从某种意义上说，灾难恢复可以看作是业务连续性的一个子部分。通过建立所有必要的文档、规划、培训和测试，我们能够确保在面对困境或发生干扰事件时，我们的组织具备韧性。

对于灾难恢复和业务连续性来说，值得考虑的是关于热备站、温备站和冷备站的相关理念。

热备站指的是作为公司生产系统的可用且完全冗余的镜像的活跃基础设施，与原始基础设施解耦，以减少两者同时被摧毁的可能性。如果你有一个热备站准备好，那么只需要将操作转移过去。这是最昂贵的选项，但也是在发生干扰时最能够迅速投入使用的选项。

温备站是与生产系统同步的版本，能够随时部署，尽管在提供过程中会有一些延迟。温备站的优点在于其准备成本远低于热备站。

冷备站可用于非关键的业务操作，或当组织面临的风险水平不足以要求热备站或温备站，或没有预算来维持这两者时。冷备站需要从头开始进行配置，但仍然能够在故障或灾难发生后提供迅速恢复的机会。

实施和管理物理安全

一如既往，我想简要提到，作为信息安全专业人员，您应该将物理安全纳入自己的责任范围。从本书开始以来，我们已经讨论了组织在物理领域面临的风险，从因恶劣天气或电力中断导致的可用性损失，到恶意攻击者突破外围防线并获得机密信息。

对于各种物理安全事件，必须定义、研讨和实践相关的计划和程序，以确保您的团队能够做出适当的反应。文档必须存放在任何可能承担责任的人可以轻松访问的位置，且指令必须简明清晰，因为高度紧张的情况下可能导致误解和混淆。

由于我们在本书中已讨论过物理安全的各个方面，我将简要总结本节内容并进入本节的总结部分。

在本节中，我们讨论了通过定义、实施和测试灾难恢复流程，以及管理业务连续性设计、规划和测试，来提高系统可用性的方法。现在我们已经讨论了可用性问题，我将继续讲解如何管理升级、打补丁和应用安全控制。

管理升级、打补丁和应用安全控制

您的系统需要不断更新和打补丁。在前面的一节中，我们讨论了 IaC 如何帮助我们自动化这些过程，这非常有益，但并不总是可行的。

有时，我们需要采取实践操作的方式来配置、审计、更新和撤销系统，例如，当我们过渡到更新的技术或在第三方进行渗透测试时得到了相关发现。

此外，在第六章《设计和管理安全测试流程》中，我们讨论了网页应用程序漏洞扫描器、网络漏洞扫描器、SAST/DAST、依赖性扫描以及类似的自动化扫描，这些可以提供需要采取的行动和必须执行的升级内容。

问题是，如何确保 IT 团队理解组织面临的风险，并执行需要实施的变更列表，以确保更加安全的环境？

教育

作为组织的信息安全专家，我们有责任确保相关人员了解并掌握他们可以采取行动应对的风险。这可能包括安排安全培训，但也可能意味着定期安排与 IT 团队的会议，可以是每周、每两周或每月一次，会议中你将展示特定风险或陷阱的信息，或者讨论组织面临的整体风险态势。花时间解释并帮助他们理解这些问题为何重要。这是你知识体系中的一个关键部分，否则你只会成为办公室里那个让人浪费时间、没有实质性贡献且不让同事们在公司笔记本电脑上插入 USB 驱动器的脾气暴躁的人。

此外，这些会议有助于你更好地理解资产管理。你可以参与对话，从中获得关于为什么某个变更可能在另一个变更之前实施的有用信息。你可以从管理日常运营的团队那里获得丰富的信息，而这种对话在持续改进的过程中极具价值。这不仅是积极主动管理你数字资产健康的有效方法，也是大多数标准和义务要求的内容，你的组织将受到这些要求的约束。

这种知识共享和开放性可能是决定变更是否成功的关键，或者它可能导致失败，从而引发安全漏洞或停机。基于此，让我们来看看实施变更的最佳实践。

变更控制

正如我们之前提到的，遵循已定义的治理结构和变更控制流程至关重要，这有助于减少停机时间，并提升你组织的员工诊断故障或错误的能力。

我们可以在这个话题上深入讨论成千上万的页面，但我认为更相关的是聚焦于 IT 领域的安全特定内容，并让你进一步研究作为更广泛 IT 或组织控制的变更控制流程。当我们从信息安全的角度看待变更控制时，我们的目标是避免错误配置，最大化正常运行时间和可用性，并记录所有变更及相关信息。

在进行补丁、升级或应用安全控制时，变更控制流程中有价值的步骤包括以下内容：

在文档中识别并描述所需的变更
从商业角度证明变更的必要性以及为何需要进行变更
评估变更可能对组织造成的影响，并记录减轻负面影响的方式
描述在失败时的回退计划
记录任何需要批准的内容并保存相关批准记录
与员工、合作伙伴、客户或类似方进行沟通的规划
有效沟通计划中的变更，包括时间窗口和任何预期的停机时间
变更的实施和评估

一个出色的变更控制过程不需要慢或限制性强。关键在于确保我们有一个计划，以减少停机、配置错误或类似的信息安全事故的可能性。通过确保我们有适当的文档和规划，我们也在确保拥有所有必要的资源。

大型项目将从定义明确的变更控制过程中受益，例如安全改进计划，我将在此简要介绍。

安全改进计划

除了在差距分析或第三方/内部渗透测试后的持续改进努力外，可能会揭示出你们的信息安全计划中某些方面缺乏在风险管理方面所需的成熟度或有效性。安全改进计划是一个定义明确的信息安全改进项目，在一段时间内进行排定、实施并测试其有效性，朝着成为一个更加安全、运营更加有韧性的组织迈进。

安全改进计划可以涵盖本书中所讨论的所有主题以及更多内容，它是一个全组织范围的努力，旨在实施和加强控制措施并降低风险。

安全改进计划的理念在于，我们不仅仅是把一些基于安全的任务“撒入”我们每天、每周和每月关注的任务中。这是一个主动的决定，降低新特性的优先级，而是专注于提高保护水平和风险缓解。当然，像这样的决定需要高层管理的支持，这将需要一个明确的计划，其中包括时间、成本、风险和回报的估算。

在规划和估算这一点时请花些时间，因为这往往是一个领导层难以做出的决定。然而，一旦你获得了支持，你将能够向团队呈现计划，这将帮助你在每个步骤中推进安全改进计划，且让团队知道这一指令是“来自高层”是一种非常有效的方法，可以优先处理这些任务并获得一线员工的支持。

既然我们简要讨论了资源配置、专注于可用性和业务连续性、以及管理升级、补丁和应用安全控制的内容，我认为我们应该进入下一部分，讨论如何调查信息安全事件并响应信息安全事故。

调查事件与响应事故

我相信大家都会同意，当我说“没有准备就是在准备失败”时，尤其是在事件响应和调查方面。如果没有足够的响应计划、操作手册和文档，当我们面临数据泄露、停机或其他信息安全事件时，我们注定会无所适从，缺乏有效的方向。

我们可以有出色的软件解决方案来帮助识别我们环境中的恶意和高风险活动，但如果没有足够的应对计划来决定响应什么以及如何响应，那这一切都是徒劳的。

我们应该通过定义什么构成响应的启动来开始制定我们的事件响应计划。哪些类型的信息安全事件会导致贵组织的成员进行调查或响应？

并非所有信息安全事故都是信息安全漏洞，但所有信息安全漏洞都是信息安全事故和信息安全事件。让我引用一些来自 ISO 27001 的定义：

信息安全事件是指在一个环境或系统内，任何表明安全政策被违反、控制措施失效或出现未预测到的可能影响安全的情况。
信息安全事故是指一项或多项信息安全事件，其中信息安全或业务操作受到损害。
信息安全不合规是指未能履行政策、标准或法规中的要求。

所以，信息安全事件即使是短暂的，也有可能影响风险。信息安全事件是指我们已知对运营或安全产生负面影响的情况，如停机或确认的安全漏洞，信息安全不合规则是发现控制措施未正确实施或政策在实践中被忽视。

让我举个例子，说明信息安全事件是如何引发信息安全事故的：

事件：贵组织的一名用户联系说他们无法打开任何文件，且屏幕上显示有警告信息。
事故：经过调查后，你的团队发现该用户的笔记本电脑感染了勒索病毒。因此，启动了勒索病毒的事件响应手册，并启用了相关团队进行响应。
不合规：经过调查和修复后，事件响应团队发现员工打开了来自未知方的电子邮件附件，并且由于 IT 团队的疏忽，某些计算机上未禁用过时的 SMB 服务。
行动：已优先为员工提供钓鱼攻击和信息安全培训，IT 部门已将实施工作站安全配置（包括禁用过时的 SMB 版本）列入路线图项目。

如你所见，如果我们使用这些事件和事故的定义，并考虑到我们的风险，我们就能够为调查特定类型的事件和响应事故制定统一且有效的程序。做到这一点就是定义你的事件响应计划，接下来我将进一步探讨。

定义你的事件响应计划

为了理解工作流程和需求，制定适合你组织的事件响应计划是至关重要的。例如，如果你没有为你的组织的安全信息与事件管理（SIEM）解决方案生成的警报制定可行的响应，那么你实际上就是在浪费这项工具的投资，无法从中获得价值。

我想借此机会讨论一些在开始安全监控活动之前需要回答的关键问题。

我们希望回答的一些问题可能包括以下内容：

与信息安全事件相关的角色有哪些？

一些角色示例可能包括首席执行官（CEO）、首席信息安全官（CISO）、首席技术官（CTO）、董事总经理（MD）、系统管理员（SysAdmin）、人力资源经理等。
每个角色在每种类型的事件中的职责是什么？

一些成员可能需要与客户沟通，其他成员可能需要与执法机构、客户或业务利益相关者沟通。可能会有负责调查事件的角色；也可能会有负责恢复流程的角色。将角色与特定的技能相匹配是一个有益的解决方案，将这些角色与特定的职位名称和职位描述挂钩，则能够使个人在进入新角色时意识到自己的职责。
如何对安全事件进行优先级排序？

优先级应该基于风险，但你需要以一种便于任何可能成为“首位响应者”的人遵循的方式正式定义这些优先级。教育员工如何应对安全事件，以及文档可能存放的位置，是事件响应的一部分，我们在其他章节中曾提到过。
记录安全事件的方法是什么？

我们如何从发现到关闭记录安全事件，这是事件响应的另一个方面，我们需要有效地定义并培训员工。
如何通知事件响应团队的适当成员有关事件的信息？

一些示例可能包括电子邮件、电话、短信或 WhatsApp。

当我们定义一个流程时，我们需要考虑以下步骤的指导：

调查一个事件，包括需要观察和记录哪些信息
确认事件，包括沟通和后续适当响应的步骤
响应事件，包括隔离或遏制威胁并减少对组织的损害
恢复操作，确保事件的影响降到最低。
调查和报告，可能使用取证能力，并采取措施保护免受罪犯侵害或采取法律行动（如适用）

如果我们想要一套简明的指南来应对信息安全事件，我们可能会看到由各政府机构提供的以下几条指南：

英国国家网络安全中心（NCSC）的中小型企业指南：响应与恢复（www.ncsc.gov.uk/collection/small-business-guidance--response-and-recovery）
欧洲网络与信息安全局的事件管理良好实践指南（www.enisa.europa.eu/publications/good-practice-guide-for-incident-management）
美国国家标准与技术研究院的800-61 Rev. 2（csrc.nist.gov/publications/detail/sp/800-61/rev-2/final）

您还可以寻求提供事件响应服务的信息安全咨询公司帮助。通常情况下，您需要提前支付费用，以便这些组织在发生事件时能够随时响应，并且每次事件所消耗的时间将从您的“余额”中扣除。

此外，值得注意的是，根据您所在国家/地区的不同，政府的各个部门提供的支持是不同的。

其他组织可能更倾向于自己进行调查和应对，而无需外部帮助。接下来让我们看看关于执行安全调查的几个要点。

执行安全调查

我将在本节中讨论如何管理和进行事件的安全调查，以及如何报告事件。通过使用一致的、结构化的方法，我们可以确保在大多数情况下采取系统且有效的方式。

首先，让我们提醒自己，并非所有安全事件都足够重大，值得进行调查。记录单个事件或多次事件的组合是很重要的，但我们不一定需要将每个记录的事件上报并让更广泛的组织介入或联系执法部门。有关应该报告哪些内容的指导可以在当地法规或来自警方、国防部、网络安全部门（如英国的 NCSC）以及其他类似机构提供的资源中找到。

作为一名信息安全专业人员，您的责任包括以下内容：

确定什么构成轻微事件和重大事件。
确定对轻微事件和重大事件的响应。
确保遵守所有国家或地区的法律法规，包括确保事件报告给相关执法部门。

一些重大事件的例子可能包括以下内容：

诸如入室盗窃或损坏组织财产等犯罪行为
洪水、风暴以及其他天气灾害导致的安全或运营受损
未经授权访问被分类为机密或受保护的信息

通常，一个重大事件需要联系保险提供商、执法机构、政府机构、客户和其他团体。为这些情况定义并保持一套程序并确保其易于访问是非常重要的，通常这些内容会被记录在你的应急响应和灾难响应的操作手册和政策中。

随着流程的推进，定义与安全调查相关的角色也非常重要。以下是一些角色及其职责的示例：

CEO 和 C-suite 高层管理人员，最终负责响应安全事件。通常这包括确保为员工和承包商提供足够的流程来报告和响应此类事件，并确保有关于过去表现和要求的记录。这通常通过任命适当的员工来专注于这些工作。
CISO，由 C-suite 任命负责处理前述工作的人员，负责以下事项：

– 处理与信息安全事件相关的流程

– 管理与安全事件相关的信息，包括来自内部调查和执法机构调查的结果

– 向 C-suite 和高级管理团队报告该信息
高级管理 团队成员将在事件响应过程中发挥作用，并会利用其团队在发生安全事件时执行相关职责。这可能包括法务负责人准备与诉讼相关的信息、人力资源负责人回应内部风险、传播负责人准备公众声明等。他们通常也会负责与其部门相关的报告领域，并定期向 CISO 汇报这些信息。
经理更接近业务活动的运营层面，确保安全事件得到适当报告，并确保员工在发生需要响应的安全事件时，做好应对其职责的准备。
员工是最有可能注意到信息安全事件或事故的群体。他们应该理解自己的职责以及在发现安全事件时可用的流程。这可以通过教育和培训来实现。

我建议你阅读国际非营利组织 CREST 发布的一份文档。这是一个关于事件响应流程的指导，名为 网络安全事件响应指南 (www.crest-approved.org/wp-content/uploads/2014/11/CSIR-Procurement-Guide.pdf)。

在链接的 PDF 指南中，你将找到以下内容的指导：

理解信息安全事件，包括以下内容：

– 如何定义一个事件

– 各种事件之间的对比

– 我们从攻击中预期的各个阶段
为信息安全事件做准备，包括在应急响应过程中可能遇到的各种挑战、应对方式、如何利用专家进行响应以及如何建立内部响应能力。此外，文档讨论了为你的组织做好准备的五个步骤：

– 对你的组织进行关键性评估

– 进行威胁分析

– 考虑对组织的影响，包括所需的人力、流程和技术

– 创建一个安全的环境，包括实施基本的控制措施，以防止最常见的事件发生

– 审查你的防护姿态并测试应急响应准备情况
对信息安全事件的响应，包括以下内容：

– 识别事件

– 确定目标

– 采取行动来遏制事件

– 恢复系统
下面是信息安全事件相关内容，包括以下方面：

– 进一步调查事件

– 向利益相关者报告事件

– 进行事件后的调查复盘

– 传达发现并基于发现进一步扩展

– 根据调查结果更新信息和控制措施

– 执行分析以发现趋势
最后，选择供应商来帮助处理信息安全事件。

这份文档将在未来成为你和你组织的宝贵资源，我希望你能采纳我的建议并阅读它。

现在我们已经讨论了事件调查和应对事件，我想深入讲解如何在你的组织中实施和利用侦测控制。

实施和利用侦测控制

如 IT 的性质所示，我们面临着不断变化的技术、威胁和应对技巧，包括勒索软件、分布式拒绝服务（DDoS）攻击和渗透攻击。我们需要了解我们网络中的情况，并实施自动化的控制措施，在攻击发生时进行通知，并积极防止这些威胁被利用。

为了实现这种可见性，我们需要一套围绕安全监控和安全调查的流程和结构，并且我们需要与负责保护我们网络的员工和第三方一起测试这些流程。

最终，高级管理层负责向内部安全运营中心（SOC）或第三方提供的SOC 即服务分配适当资源，并准备好事件响应团队。一旦高级管理层认识到信息安全的这些方面的重要性，实施和维护这些控制的责任可能会被委托给您，您的组织的信息安全专业人员。

在承担这一责任的同时，我们需要确保采取基于风险的策略，包括以下内容：

资产优先级排序
威胁建模
一个检测预算
一个响应预算

除此之外，我们需要为未来制定策略，并确定应采取哪些教育和改进措施，以确保组织即使在不断变化的情况下也能保持受保护状态。

就目前而言，信息安全专业人员在实现这些更高水平的可见性方面最有效的措施之一是通过安全监控。让我们讨论接下来可能涉及的内容。

使用安全监控来提高可见性

增加对数字资产运行情况的可见性的一种特别受欢迎的控制是实施日志记录并将这些日志聚合到 SIEM 系统中。

SIEM 不仅为专家提供了调查组织内资产日志的能力，而且最近还能利用 IPS/IDS 功能以及机器学习算法来丰富日志数据并积极防范威胁。这将 SIEM 从仅仅是侦查控制转变为既是预防性又是侦查性控制，为网络以前黑暗的角落提供上下文和可见性，以及减轻威胁行为者的有效性。

这可能包括识别以下模式和行为：

通过认证日志进行账户被篡改检测。
通过系统活动、防火墙、IDS/IPS 和CASB（云应用安全代理）日志进行恶意软件检测。
通过上下文参考，如比较 IDS/IPS 和漏洞数据库，进行入侵检测。
通过防火墙和 CASB 的出站连接日志进行恶意软件主机检测。
通过管理活动、用户活动和变更日志进行策略违规检测。
通过 Web 应用防火墙日志、Web 或云服务器日志，或应用程序和数据库服务器日志，检测对外部应用程序的攻击。

为了了解这些检测是否有效且可信的威胁，准备一些信息以使您的事件响应团队和SOC进行比较和参考将是重要的。

这些信息可能包括以下内容：

预期在您环境中出现的主机列表。这有助于团队成员或自动化系统检测您环境中不需要的主机或端点。
在特定时间段内的网络活动的基线日志，可能被视为“正常”。收集这些信息的问题在于回答“如果我们已经遭受入侵怎么办？”的问题。假设“已遭受入侵”的原则在零信任网络理念中变得流行，但许多组织并没有准备好像我们希望的那样迅速采取这些步骤。
每台主机上运行服务的列表作为基线。它可以建立在先前提到的主机列表上，并应包括预期在特定主机上进行通信的端口号和协议。
与 OSI 参考模型对齐的网络功能的交互式图表或可视化表示。如前所述，在这个过程中提供有污染的数据的风险，实际上证明了您网络中存在的威胁是“正常”的，因为它们被认为是“正常”的。

为了避免提供掩盖已存在于您资产中的威胁的垃圾信息的陷阱，您应该考虑一个项目，解决以下问题：

确定所有服务器上存在的所有过程和服务，并指定它们的功能
确定这些过程和服务产生和/或接收的通信类型
确定这些服务的关键性，以及它们的脆弱性和相关风险水平
确定是否有冗余服务（即，它们是不必要的）
确定是否有关键服务缺乏冗余（即，它们是关键的，但没有任何备用措施）

“啊，我们又来了！”，你现在可能在想。“又让我们做不可能的事情！”

对于一些人来说，尝试准确表示资产中的所有网络活动似乎是不可能的... 这就是为什么自动化系统开始提供解决方案，而不是要求团队放下日常任务，投入时间和精力去处理像之前看到的那样困难的任务。

相反，这些自动化系统能够“扫描”和“检测”在您资产中发现的活动类型，并丰富该数据与全球其他资产中发生的恶意活动周围的情报，然后利用该信息通知您的 SOC 并应对任何活动威胁。

这些解决方案可能是您组织的更可行的解决方案，并可以帮助您导航您的资产的复杂性，过滤掉所有噪音，突出只有最有价值的见解和基于风险的检测。这些见解甚至可以转化为基于关键点摘要的报告或“管理风格”的报告。

这些软件的一些示例可以包括以下内容：

Microsoft Azure Sentinel
Splunk Enterprise Security
IBM QRadar Security
LogRhythm NextGen SIEM 平台
AT&T 网络安全 AlienVault USM
Graylog

无论你为组织选择哪种 SIEM 和情报解决方案，都有一些最佳实践值得注意，并可以在将解决方案引入组织并创建最佳流程的早期阶段应用。

安全监控最佳实践

安全监控和 SIEM 工具在检测和预防试图利用你组织资源的重大威胁方面非常有用，帮助确保你的组织遵守相关法规和要求，同时提供可衡量的洞察，指出安全态势可以改进的地方。

对于这类系统，我们希望从技术、法律或监管的角度收集尽可能多的信息，以确保最高水平的可见性和数据聚合，并从我们组织的活动中获取有意义的洞察。这可能包括网络设备和服务器日志、Active Directory/IAM 日志、漏洞扫描仪和配置管理工具指标等等。

此外，在聚合数据时，实施冗余非常重要，并且要像对待任何关键数据一样处理这些数据，其中的风险通过备份和恢复策略得到缓解，以确保符合你的信息安全政策。

在SIEM 和安全监控中也存在一些局限性。有时候，收集某些信息是不可行的，或者网络和计算吞吐量无法处理你组织中的数据量。做出决定之前，了解你期望系统处理的数据量非常重要，这对于选择合适的解决方案和供应商至关重要。

我想介绍一些在深入进行安全监控之前需要采取的特别重要的步骤，这些步骤可以帮助你和你的组织避免常见的错误和失误。

建立需求并定义工作流

让我问你一个问题：如果你不知道从 SIEM 中需要什么，怎么能评估可用解决方案的功能呢？

首先，像做任何决定一样，在选择解决方案之前，以下几个步骤非常重要：

确定你的需求。
确定你的时间线目标。
定义理想的工作流，并根据你和你组织的需求进行规划。

有时候，供应商会尝试突出一些对你没有价值的功能，这些功能的存在只是为了让那些没有准备好的人眼花缭乱。另一方面，有时候，供应商会为你提供一个更好的解决方案，它能够解决更多你未曾预料到的问题，或者以巧妙的方式解决你的问题，这是一个很好的情况。

在我们制定需求时，不妨再次考虑KISS 原理（保持简单）。定义一个合理的范围来试点你的解决方案。在实施 SIEM 的第一天，你不需要一次性覆盖所有需求，系统可以逐步推出，允许进行故障排除和已定义流程的测试。通过这样做，你不仅提供了概念验证，减少了边缘案例的可能性，还能向关键决策者展示 SIEM 系统的好处。

鉴于此，确保始终牢记你的最终目标，确保解决方案能够扩展到你希望覆盖的数据量级。这可能以每秒事件数（EPS）来衡量，或者可能是每日千兆字节（GB/day）。

在考虑需求、目标和工作流程时，你还需要考虑合规性和法规要求。SIEM能够帮助向监管机构和审计员展示其他安全控制的有效性。在之前的章节中，我们讨论了制定法规和标准清单，以及你的组织必须遵守的每项法规和标准的具体要求，所以你应该已经准备好这些了，对吧？没错吧？！

有了这份清单，你已经准备好在演示和展示过程中向供应商提及你的合规性要求，确保你能收集、保留和删除为了保持合规所需的信息。它还可以帮助估算为存储保留所需的存储量，帮助简化定价讨论。

定义具体规则并确保其有效性

在确定你的需求和定义SIEM与事件响应流程之后，你可以定义对组织有用的数据类型及其可能的指示意义。许多解决方案有各种“内建”的指标，例如以下内容：

授权失败的尝试
授权成功
用户权限变更
应用服务器错误
应用服务器性能问题
管理员活动

此外，定义你不想存储或执行 SIEM 活动的信息，或者可能希望限制某些活动类型也是非常重要的，例如以下内容：

个人身份信息（PII）
违法收集的信息
信用卡和银行信息
密码
加密密钥

从这些定义以及从这些定义中制定的规则来看，定期测试解决方案的有效性非常重要，以确保预期的结果确实发生。这包括精确数据匹配或近似匹配，或需要通过的阈值（例如，某事件需要在 1 分钟内发生超过三次，才会触发警报），等等。这还包括解决方案生成的通信和通知，以及是否如预期一样通知了相关人员。

我相当确定，在为事件响应和安全监控制定需求和计划的过程中，你会发现一些你曾认为可行的理论并不奏效。这是你开始采取下一个最佳实践的机会，那就是…你猜对了，持续改进你的政策和配置。

持续改进你的 SIEM 配置和事件响应策略

信息技术领域正在以前所未有的速度变化，且这一速度正在不断加快。这意味着解决方案会变得过时，曾经被认为是高质量的解决方案或资产的信息要么变得难以使用，要么变得毫无用处，同时，新的威胁会出现，利用或规避曾经被视为“防弹”的配置。

因此，我们需要在日历中设定一个定期的日期，专注于完善 SIEM 配置和事件响应策略（当然也包括其他方面，但我们现在只讨论 SIEM 和事件响应）。我们不能让它停滞不前，即使我们正在使用一个*软件即服务（SaaS）*解决方案，且该解决方案会自动从供应商处更新，我们仍然需要确保系统中反映的是当前我们环境的实际状况。

现在我们已经结束了关于安全监控的这一部分内容，我想以本章的总结来作结。

总结

那么，现在就结束了第七章，安全运营管理。我相信我们已经涵盖了信息安全专业人员处理安全运营所需的高层次要求。正如本书的每一章节一样，我们涵盖了许多话题，但每个话题都只是非常简略地提及。任何本章的内容，甚至是其中某一段，都是可以专门写成整本书的。我希望这能激发大家未来深入了解每个领域的兴趣！

在本章中，我们涵盖了信息安全运营团队日常需求的各个重要方面。

首先，我们探讨了资产配置和维护的有效策略，包括所需的政策和配置管理步骤，并且简单介绍了基础设施即代码（IaC）这一概念，以简化和自动化这些过程。

接着，我们关注了可用性、灾难恢复和业务连续性活动，包括定义、实施和测试灾难恢复与业务连续性计划的流程。

从这里，我们进一步探讨了在组织中管理升级、打补丁和应用安全控制的相关话题，其中包括关于教育要求、变更控制流程以及安全改进项目的信息。

然后，我们深入探讨了事件调查和应急响应，包括定义事件响应计划和进行安全调查。

然后，为了结束本章，我们探讨了实施和利用侦探控制措施，包括如何利用监控来提高对你系统内部的可见性，利用增加的日志记录级别，将这些日志聚合到 SIEM 中，应用自动化逻辑和机器学习洞察分析数据，并让 SOC 成员审核这些数据。

最后，我们讨论了安全监控的最佳实践，包括建立需求并定义工作流程，定义具体的规则并确保其有效性，以及持续改进你的 SIEM 配置。

现在，接下来我们要进入最后一章，第八章，提高软件安全性，这是我个人最喜欢的话题。

第八章：提高软件安全性

软件帮助全球各地的组织将生产力提升到前所未有的效率水平，帮助自动化以前需要人工完成的琐事。通过查看组织的软件资产（并在此过程中更新风险登记册），你会越来越意识到，几乎每一个商业流程都依赖于至少一个软件解决方案，而软件的韧性、安全性和可用性越高，组织获得的收益就越大。

你的一些软件可能是内部开发的，其他软件则是从第三方购买或许可的。这些系统通常存在巨大的攻击面，拥有许多易被利用的活动组件，且由于它们处理机密和敏感信息并存储业务关键数据，未经授权访问（或摧毁）这些系统可能导致关键数据的永久丢失，或者导致知识产权、公司机密和客户数据的机密性或完整性丧失。此外，这些安全漏洞可能导致监管机构的巨额罚款，雪上加霜。

可怕的事情是，即使我刚刚列出了所有关心的理由，各种软件系统的采购、开发和使用通常都没有任何以安全为重点的监督。这正是为什么理解并执行改进的软件安全至关重要，以确保你的组织能够减轻使用软件带来的风险。

在这一章中，我将深入探讨一些能够帮助你确保组织中软件安全标准更高的话题。包括以下几个主题：

探索软件安全范式
理解安全开发生命周期
利用 OWASP 十大主动控制
评估软件安全性

总的来说，我们希望从这一章中学到的是，如何为软件建立需求，无论它是由第三方开发还是由内部开发团队开发。我将讨论我们如何理解由供应商开发的软件系统的风险特征，如何减少在组织内部开发活动中出现漏洞和错误的可能性，以及如何针对安全风险采取措施，重点关注 CIA 三元组。

话不多说，让我们继续进入这一章。

探索软件安全范式

我想让你回想一下 2014 年 4 月，这在信息安全的历史中是一个重要时刻；全世界都被CVE-2014-0160漏洞的披露所震惊，这个漏洞被冠以Heartbleed的名字。现在，当我说“全世界”时，我是认真的。Heartbleed 就像是软件安全大片中的大白鲨，它甚至有了自己的网站（heartbleed.com），甚至还有自己的 logo：

图 8.1 – Heartbleed 漏洞的标志

披露的信息中提到，OpenSSL 加密库存在一个与缓冲区过度读取相关的漏洞，这使得恶意行为者能够访问加密密钥和登录凭证，以及其他各种机密信息。听起来很糟糕，但情况更糟：OpenSSL 版本的 TLS 协议中也使用了 OpenSSL 加密库，这种协议广泛用于全球范围内保护数据传输的安全，几乎无处不在。简单来说：全球排名前 100 万的TLS/HTTPS 保护网站中超过一半受到了影响，并且容易受到攻击。

尽管在披露的同一天发布了 Heartbleed 漏洞的修复程序，但这并没有阻止设备（如防火墙、安卓手机和其他受信硬件）、软件以及网站在补丁被应用并且更新与最新版本对齐之前，继续处于脆弱状态。

此外，让我们明确一点：这个漏洞自 2011 年起就在代码中存在；我们知道这一点，因为任何愿意查看和阅读源代码的人都能看到它。这是因为 OpenSSL 是一个开源开发的程序。开源意味着软件的源代码可以自由阅读、修改和重新发布。开源软件运动的一个被认为的优势是透明的软件能够防止通过模糊化安全问题以及源代码中的其他漏洞，因为任何愿意查看的人都会发现这些问题。不幸的是，在 OpenSSL 的加密库的案例中，似乎要么没有人注意到，要么没有人愿意大声呼喊这个漏洞，直到 3 年后。

这听起来有些奇怪，对吧？错了。直到最近，这一直是默认情况。安全性一直是任何寻求开发新功能和推出新产品的组织事后的考虑，但随着时间的推移，随着 Heartbleed 等重磅披露事件进入了普通商业主和 IT 专业人士的词汇中，我们看到了一个向更加重视安全的范式转变。

那么，我们如何确保在组织中避免实施存在漏洞的软件呢？无论是供应商创建的生产力套件，还是开源的加密库，或是为员工开发的内部工具，你不可能发现所有问题，因此重要的是要管理好自己的预期。就像信息安全中的任何问题一样，这关乎风险管理，并且需要制定适当的政策和程序，确保采取了必要的步骤，并与相关资产的价值相一致。

首先，让我们来看一个可以应用于不仅仅是信息安全的概念，而是任何我们购买东西时都能用到的原则。

买者自慎

你是否听过让买家警惕这个术语？我敢打赌你听过拉丁文版本，caveat emptor，对吧？怎样，我们不妨借此机会做个快速的拉丁术语学习，来探讨一下合同法中常见的拉丁术语：

买者自慎，因为他不应对所购买的财产的性质一无所知

它的大致英文翻译如下：

让买家警惕，因为他不应对他从其他方购买的财产的性质一无所知。

说实话，我很惊讶它能够传播得这么广。通常情况下，如果你在背诵格言时需要停顿一下，它就不会长久存在。尽管它相当冗长，这个想法经得起时间的考验，在采购新软件时必须考虑到这一点。

由买方负责对将要在其组织中使用的软件系统进行尽职调查。你有责任确保你的组织已经适当地进行了尽职调查，并将相关信息保存下来，以备将来需要向监管机构或审计员证明已采取适当的预防措施并在过程中履行了必要的谨慎时使用。

"但是怎么做？"你问。"我怎么能确保呢？"

法律文档

"哦，太好了，"你在阅读到这一节标题后说，"他接下来会谈论文件工作。"嗯，是的，遗憾的是，我确实会。

事实是，你不能百分百确定你购买的软件是否在安全性上得到了开发。然而，你可以尝试在与供应商的合同协议中加入条款，确保他们理解你的要求，并负责确保他们开发的解决方案是在安全的前提下构建的。

定义责任的合同是风险缓解的一种形式。我的意思是，在发生泄露事件，导致你组织的机密信息或与个人相关的敏感信息被泄露时，你是否能够根据你组织面临的罚款和声誉损害的损失程度，要求供应商进行赔偿？

是否接受这些条款取决于多种因素，包括条款的性质、供应商的规模、你组织的规模、你对他们的客户价值等。

有时候，你只需要实施其他类型的缓解措施，并接受供应商在发生泄露事件时不承担责任，无论是否是由于他们一方引入了后门或恶意软件。你有责任将这些协议文件化，并在进行风险评估时，尤其是软件实施前后，引用它们。

此外，本书中我们讨论的关于信息安全理念仍然适用。我们必须允许软件的最小权限访问，我们应该监控软件的活动以及它如何与其他资产互动，并且在软件的整个生命周期内持续审查和评估它的适用性和风险。

说到生命周期，我觉得我们应该讨论一下安全开发生命周期（SDLC）的概念，因为关于这个话题的知识既涉及第三方开发的软件，也涉及你们组织自行开发软件的工作。

理解安全开发生命周期

SDLC 的核心是通过一系列流程将安全性融入软件开发。当你向供应商询问他们的 SDC 时，你需要理解他们在确保他们出售的软件对你的组织足够安全时所采用的方法。

提供CISSP认证的同一公司，名为*(ISC)²*，还提供CSSLP，即认证安全软件生命周期专家，涵盖了八个领域，你需要了解这些领域才能通过考试：

安全软件概念
安全软件需求
安全软件架构与设计
安全软件实施
安全软件测试
安全软件生命周期管理
安全软件部署、运营与维护
安全软件供应链

显然，深入讨论这些主题会超出我在本章中 30 页的限制，如果我这么做，很多内容会重复我在本书之前提到的概念，包括数据类型的标记或实施最小权限原则、职务分离或深度防御等，但还是值得强调一些与 SDLC 独特相关的关键要点，激发你进一步探究的兴趣。

我们可以将软件开发生命周期（SDLC）大致分为五个阶段，每个阶段都有其子组：

确定业务和安全需求
设计安全软件
安全软件的测试计划
安全软件开发
测试软件

我们是否可以简要探讨一下这些要点，稍微详细地讨论一下这一过程？我们来讨论，但首先我想处理一个显而易见的问题：现在已经没有人以这种方式开发代码了。让我们来谈谈各种软件开发方法论，以及它们如何与 SDLC 协同工作。

与各种软件开发方法论的兼容性

随着时间的推移，开发软件的最常用方法已经从传统的阶段性、项目管理的“每年发布两次重大更新”的瀑布式方法转向了更快速的迭代方法，通常称为敏捷方法，在这种方法中，解决方案被拆分为小的周期，试图早期交付一个可工作的产品，并且不断改进和频繁更新。

此外，组织中的开发团队和 IT 运维团队可能存在分隔，或者可能采用更加集成的软件开发和部署方法，比如DevOps方法，例如：

图 8.2 – DevOps 生命周期图

无论你的组织使用哪种方法来开发软件（这些方法中有许多不同的风格），SDLC 过程仍然可以作为一种内建的方法来使用。在前面展示的 DevOps 生命周期图中，你会发现它与我之前提到的 SDLC 的五个步骤是对齐的，只要你确保在规划阶段定义了软件的业务和安全需求！

好的，让我们更仔细地看看 SDLC 的五个步骤，从定义业务和安全需求开始。

定义业务和安全要求

你看，为了创造出好的软件，需求必须在每次迭代的开始时就被明确界定。虽然这种情况很少发生，但话说回来，软件也很少是我们所认为的“好”软件。在这些需求定义中，除了使用场景和解决方案外，我们还需要确保定义软件的安全性和隐私要求，并且在开发过程中，软件必须针对这些安全性和隐私要求进行测试。

除此之外，我们还需要考虑滥用案例或恶意行为者可能滥用软件的方式，本质上是进行威胁建模，并考虑攻击面。根据滥用案例的发现，我们需要确保已采取适当的缓解措施（支出与风险水平相符），以防止或减少这些攻击成功的可能性，并找到方法减少如果攻击成功后的影响。

我将在*《利用 OWASP 十大积极控制》*部分中更详细地讨论我们如何做到这一点。

设计安全软件

有了滥用案例和需求后，我们希望设计软件架构，确保具备适当的控制措施（预防性、侦测性和响应性），并确保应用程序的整体结构及其与其他系统和人员的交互是从设计上就确保安全的。

安全软件的测试计划

与单元测试、集成测试、系统测试和验收测试一起，安全测试必须纳入软件开发生命周期（SDLC），通过各种方法，包括自动化和手动流程，发现安全漏洞。

在软件开发之前，我们希望规划并定义必须执行的测试，以确保软件开发过程考虑到这些测试。

ISO/IEC/IEEE 29119 标准适用于软件与系统工程 - 软件测试，这是一个包含五个不同部分的标准：

第一部分：概念和定义
第二部分：测试概念
第三部分：测试文档
第四部分：测试技术
第五部分：基于关键字的测试

对29119标准有很多反对意见，多个小组认为标准化测试没有必要。我认为在本章中，这不应该是你的关注点；是否采纳这些理念，取决于你的组织。最重要的是，标准的第三部分提供了你的测试计划文档模板示例，如果我们遵循 SDLC，那么依赖这些模板可能比花时间重新发明轮子更为合理。

来自 ISO/IEC/IEEE 29119:-3:2013（是的，我知道，这个名字很长）的模板涵盖了你可能希望使用的组织级、项目级和动态测试文档，包括以下内容：

组织测试过程文档模板：
- 测试政策
- 组织测试策略
测试管理过程文档模板：
- 测试计划（包括测试策略）
- 测试状态
- 测试完成
动态测试过程文档模板：
- 测试设计规范
- 测试用例规范
- 测试过程规范
- 测试数据要求
- 测试数据准备报告
- 测试环境要求
- 测试环境准备报告
- 实际结果
- 测试结果
- 测试执行日志
- 测试事件报告

这意味着你将拥有适当的模板集合，帮助你的产品团队和工程团队迅速且系统化地记录和满足软件所需的要求。如果这些过程和文档看起来会妨碍你进行实际的工程工作，那你可能是个软件工程师。

话虽如此，我非常清楚在这种情况下开发人员所提出的抱怨和顾虑，尤其是在我们开发进度加快，且更迅速地将变更集成到生产环境中的时候。如果你的组织正在使用这些原则，我不会建议你让团队被一堆文书工作拖慢进度。

作为信息安全专业人员，我们的工作是了解风险并将其降低到可接受的水平。这个过程的一部分是确保开发团队创建的软件适合其用途，并符合定义的要求，展示没有这些过程是多么困难的任务。

根据我提到的来自 ISO/IEC/IEEE 29119 的文档，我们的目标是做到以下几点：

分析软件，在此过程中我们指定用户、使用案例、使用场景以及解决方案所使用的资源。
设计测试策略，在此过程中我们定义测试的目标，并估算所需的资源和与测试阶段相关的成本。我们还定义了测试范围和不在范围内的内容。
定义测试标准，在此过程中我们创建一个流程，定义在失败的情况下何时停止测试，以及什么样的结果构成成功的测试完成。
定义测试环境，在此过程中我们指定将要进行测试的用户环境和业务环境。
定义进度表，包括截止日期、每项资源的估算，以及可能妨碍测试完成的任何阻碍或依赖项。
确定测试交付物，包括测试结果和报告、测试过程文档以及在软件满足测试要求时的发布说明。

所以，这并不是让我让你写战争与和平，如果我们遵循敏捷过程，每个小的改进都可以为之前列出的六个概念提供一个非常简短的定义，可能紧随用户故事之后。用户故事是一种结构化的方式，用来定义软件需求并传达给开发人员：

As a <insert role>, I want <insert requirement>, so I can <insert use-case>.

这涵盖了第一步的大部分内容，即分析软件，之后我们可以加入我们的测试目标、所需的测试资源、验收标准、测试环境和测试进度表。

如果发现错误，它们可以在同一个迭代或冲刺中迅速而轻松地解决。

那么，你可能如何测试软件，以确保考虑并避免安全漏洞呢？

我将详细讲解这个内容，但首先我想谈谈确保软件开发安全，这是软件开发生命周期（SDLC）的下一个阶段。

确保软件开发安全

在开发代码的过程中，我们希望确保开发人员遵循与安全代码相关的某些理念。我们可以创建培训和意识提升计划，并提供文档，指导他们如何确保遵循安全软件开发理念，包括但不限于以下内容：

输入和输出的安全处理，以防止注入漏洞和服务拒绝攻击，这些漏洞源于恶意或疏忽的用户输入
适当的错误处理，并确保在发生错误时用户不会被提供过多信息
资源管理和并发性，确保流程是可扩展的
隔离，确保通过沙箱、虚拟化、容器化及相关技术概念对进程进行隔离。
加密控制的选择与实施，确保正确实施适当的协议，同时考虑成本效益分析。
访问控制结构，包括确保信任区、最小权限和基于角色的访问控制（RBACs）得到考虑并适当应用。

为了避免重复，我们认为通过深入探讨可能实施的测试类型来检查软件中已知的安全漏洞，并解释如何避免或缓解这些漏洞，可能会更加有用。

测试软件

考虑到我们已经定义了适当的测试流程、相关的利益相关者、环境和验收标准，现在是时候执行这些计划了，既要进行自动化过程，也要进行手动过程，以确保对源代码、环境或软件使用所做的任何更改都能有效、效率高且安全。

这并不是说我们在软件开发完成后才进行所有这些测试。如果我们使用的是更快速的开发方法论，我们必须利用更多自动化系统，并为任何需要的手动测试过程创建快速通知，以确保在 SDLC 的测试阶段不会出现瓶颈。通过这种接近实时的软件测试方法，能够快速发现问题，并确保开发人员能够快速适应，快速失败，及时发现错误并在投入过多时间于错误的方法之前进行修复。通过这样做，我们帮助开发人员快速构建更安全的软件。

回顾我们如何定义测试计划和设计测试流程，一些我们希望在流程中实现的例子，以增加安全性并加速测试过程，包括以下内容：

架构分析，包括端到端流程和设计检查。
依赖检查，自动化检查导入的第三方软件依赖项中的漏洞。
自动化SAST，即静态应用程序安全测试，我们在前面章节中提到过。
自动化DAST，即动态应用程序安全测试，我们在前面章节中也提到过。
代码审查，一个开发人员阅读并批评另一个开发人员的代码。这有助于知识共享，同时也实施了双人原则，即两方需要共谋才能实现后门或恶意软件。这不是绝对安全的，但它是深度防御方法的一部分。
渗透测试，我们已经多次提到过，可以在重大变更时进行，也可以定期进行。

在这些过程中，至少我们需要检查确保已实施 OWASP Top 10 积极控制（owasp.org/www-project-proactive-controls/v3/en/0x04-introduction.html）。这意味着为自动扫描和手动代码审查建立文档化的程序，并且对开发人员进行相关步骤和控制的培训。这对 SDLC 的成功至关重要，因此不要忽视培训、意识、政策和程序！

我接下来将讨论 OWASP 的 Top 10 积极控制。

利用 OWASP Top 10 积极控制

让我简要介绍一下 OWASP Top 10 积极控制，用于提高软件安全性。每个控制项都有自己的章节。

定义安全要求

正如我们之前讨论过的，能够清晰表达和文档化软件解决方案所需满足的要求，对组织非常有益，原因包括节省成本和提高可用性，但另一个必须通过软件开发工作或购买/开源软件来满足的业务需求是有关信息安全的要求。

基于最佳实践和行业知识创建标准的安全要求，帮助开发人员和采购人员重用他们从先前迭代中获得的知识，因此强烈建议以统一且经得起时间考验的方式定义这些要求。

在OWASP Top 10 积极控制部分关于定义安全要求时，他们提到了OWASP ASVS，即应用程序安全验证标准，这是一个安全要求的集合，包含了验证这些要求是否已满足的各种标准。作为示例，它包括了用于各种信息安全职能的最佳实践类别，如访问控制、错误处理、身份验证等。这是一个不容忽视的优秀资源。

正如我们之前所讨论的，利用用户故事（如在敏捷软件开发过程中看到的）以及误用用户故事，可以帮助团队在这些职能中验证安全要求是否已满足。

作为示例，我们可以参考ASVS要求，您可以利用这些要求进行身份验证，例如验证是否没有使用默认密码，如此处所示：

验证应用程序框架或应用程序所使用的任何组件（如“admin/password”）中没有使用默认密码。

– ASVS 3.0.1，要求 2.19

将其转化为用户故事，使用我之前提到的公式：

As a <insert role>, I can <insert requirement>, so I can <insert use-case>.

我们来处理一下 ASVS 3.0.1，要求 2.19：

“作为用户，我可以输入我的用户名和密码，从而获得对应用程序的访问权限。”

或：

"作为一个用户，我可以输入最多 1023 个字符的长密码，这样我就可以使用强大且独特的密码。"

滥用用户故事是从恶意行为者的角度来描述的：

"作为一个恶意行为者，我希望能够输入发布的默认用户名和密码，这样我就能在未经授权的情况下访问系统。"

是否在用户故事中使用这些内容，由你决定，但要小心，确保开发人员理解这些内容，并且不要将滥用用户故事误读为需求！

利用安全框架和库

软件开发有大量在线资源可供利用，从学习各种编程语言的免费在线课程到用于 Web 应用框架的文档，资源繁多，数不胜数。这种文化已经扩展到软件开发中的安全领域，标准、框架、库以及其他高度文档化的资源对任何有兴趣学习的人开放。有时，只需将几个软件包导入到开发项目中，就能轻松应用这些资源。

尽管如此，仍然重要的是要记住一些关键理念，以确保利用第三方资源的风险是安全的：

使用有维护记录的可信来源。如果一个框架或资源没有得到积极更新和维护，那么它将面临挑战，并且容易出现漏洞。
确保我们在风险管理资产目录中记录所有第三方库和软件。这可能会很困难，但有像 Snyk (snyk.io/) 这样的服务，可以自动化收集列表并为该列表应用风险评分。
确保在软件面临由于缺乏维护而导致的重大变更之前，及时应用更新。除了之前提到的 Snyk，OWASP 还提供了一个名为 OWASP Dependency-Check 的工具，可以检查第三方库列表中公开披露的漏洞。NPM 也有类似的服务，其他选项也在不断涌现。
确保开发人员始终遵循 最小权限原则。允许过多的访问会增加攻击面，从而可能增加风险。

你知道的，整个书中我们一直在强调的基础知识！

确保数据库访问安全

当软件与数据存储（如 SQL 数据库）进行交互时，可以遵循一些关键理念，以提高软件的安全性并将风险控制在可接受的水平。例如，我们不希望用户能够向查询中输入任何内容，而这些内容在没有经过解析、检查和清理之前就会被当作命令执行：

图 8.3 – XKCD #327 – 输入清理

理想情况下，我们甚至不允许用户自己输入查询，但这取决于使用场景。通过使用如查询参数化等保护措施，你可以创建安全查询，减少发生注入攻击的可能性，如 SQL 注入。

阅读更多关于查询参数化的内容，参考OWASP 查询参数化备忘单 (cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html)。

此外，你还需要确保数据库和用于运行数据库的计算平台配置正确，具有安全配置，最好利用我们在前面章节中提到的基线配置。

安全认证意味着通过多种方式保护认证过程。例如，确保认证通过安全通道进行，防止凭证泄露。存储在静态时的凭证必须通过深度防御来保护，以应对各种威胁，包括访问控制和静态加密，以防止机密性攻击，和冗余，以防止可用性攻击。

最后，尽管软件和数据库之间进行着双向通信，但确保通信通过安全通道进行是很重要的，利用传输加密，并防止用户从错误消息和日志中获取过多信息。

你可以通过阅读 OWASP 数据库安全备忘单 (cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html)进一步了解数据库安全。

编码和转义数据

另一种防止注入攻击的方法是使用 \"，防止解释器关闭字符串，以降低因不良输入导致解释器或浏览器输出危险内容的风险。

编码输出数据有助于防御跨站脚本攻击（XSS），以及其他缺陷，如操作系统命令注入或某次有人使用表情符号时导致整个银行系统崩溃的事件（www.vice.com/en/article/gv5jgy/iphone-emoji-break-apps）。

编码和转义可以在接收和输出数据的各个阶段进行，任何时候用户输入或其他不受信任的数据被解释或动态输出到界面时，都应该考虑这些措施。

您可以阅读更多关于如何防止 XSS 攻击的信息，参考OWASP 跨站脚本预防备忘单 (cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)，以及如何防止注入攻击的信息，参考OWASP 注入预防备忘单 (cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html)。

验证所有输入

与上一点紧密相关的是验证所有输入的概念。我们希望确保所有输入在存储或与软件或系统的任何部分交互之前，都经过适当的验证并正确格式化。

这包括经典的语法检查，例如如果用户输入的是信用卡号码，我们需要确保它符合信用卡号码的格式。

这包括防止接受任何黑名单字符或术语，以及在输入仅能为某些特定项时设置白名单。例如，如果输入要求提供美国州的两个字母缩写，我们可以设置一个包含 50 个“批准”输入的白名单，并防止任何其他输入被接受。

这些检查应遵循深度防御的理念，并且不应依赖于用户遵循的理想路径，因为恶意行为者喜欢寻找绕过前端控制的方法。

利用各种安全库和框架中的验证功能可以简化此过程，但它们应始终经过测试，以确保在您的项目中适用。

将所有输入视为恶意输入是前进的方向，因此让我们达成一致，今后将这一点纳入我们所有的软件开发生命周期（SDLC）政策，好吗？有关输入验证的进一步阅读可以参考OWASP 输入验证备忘单 (cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)。

实施数字身份

我们需要确保我们的每个用户在与软件交互时都被赋予一个 ID，以便在他们的会话期间提供流畅的体验，同时也能为我们提供理解错误和跟踪滥用的能力。

NIST 发布了特别出版物，800-63B，数字身份指南——认证与生命周期管理 (pages.nist.gov/800-63-3/sp800-63b.html)，在实施和利用数字身份的过程中值得参考。

在NIST 特别出版物 800-63B中，详细说明了各种控制措施及其正确实施方式。这包括针对不同“级别”应用程序的要求，具体取决于所包含的信息和执行的处理。

例如，一级应用程序被认为是低风险的，不包含任何私密数据或个人身份信息（PII）。因此，仅需要密码认证，建议检查常用密码，并建议未使用多因素认证（MFA）的用户设置至少 10 个字符的密码长度要求。强烈建议阅读该出版物以获取进一步的指导。

用户重置忘记的密码的过程应包括多因素认证（MFA）方法来证明他们的身份。实现这一点的典型方式是利用侧信道，如电子邮件，向与账户关联的电子邮件地址发送包含唯一链接的密码重置邮件。有关建议流程的更多信息可以参考OWASP 忘记密码备忘单（cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html）。

当我们谈论会话管理和 cookie 时，可以采取一些步骤来提高用户的安全性。例如，应设置 cookie 的过期时间。为 cookie 设置HttpOnly属性可防止该 cookie 在 JavaScript 代码中被引用和使用。任何传输都应通过 TLS 加密来保护，以防止中间人攻击窃取会话 ID，通过设置Secure属性来实现。

有关会话管理、网页认证和访问控制的进一步阅读可以参考OWASP 会话管理备忘单（cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html）。

强制实施访问控制

与前面提到的数字身份类似，访问控制和授权是关于向用户授予和撤销各种权限或特权。通过利用已知的模型，例如我们在本书中介绍过的 RBAC，通过提前建立强大的访问控制来防止权限膨胀等漏洞和缺陷，确保用户只访问他们所需要的内容，既不多也不少。

为了强制执行已实施的访问控制，所有请求必须通过访问控制检查，默认设置应为拒绝。因此，规则不应硬编码，而应基于当前与软件交互的用户的访问级别动态调整。同样，这是深度防御的一部分。

最后，确保通过日志记录跟踪与访问相关的所有事件，并将这些日志传输到安全监控资源中。我们稍后会详细讨论。

进一步阅读可参考OWASP 访问控制备忘单（cheatsheetseries.owasp.org/cheatsheets/Access_Control_Cheat_Sheet.html）。

随时保护数据

信息安全行业的基础是确保信息的安全。当我们在应用程序中传输或存储数据时，我们需要确保它得到充分的保护，免受威胁，并基于风险采取控制措施，同时考虑到我们在本书中讨论的最小特权、防御深度等方法。

在数据安全方面，它包括数据分类，我们对每一条数据应用敏感性级别标签，并根据规定、声誉风险承受度以及机密性、完整性和可用性风险承受度，将这些标签映射到您和您的组织所定义的适当控制要求。

在保护数据方面，一个简单有效的办法是对传输中的数据进行加密，通常使用 TLS。这可以防止中间人攻击和侧信道攻击，这些攻击可能发生在用户与前端应用服务器之间，或者前端应用服务器与后端之间的通信中。

对静态数据进行加密可以降低与机密性丧失相关的风险，但所需的复杂性和技术技能可能稍微增加潜在的误配置风险，从而导致可用性丧失。加密静态数据是一个重要步骤，但必须小心规划和实施才能有效。

利用加密库可能是一个不错的起点，无论我在本章开头提到的恐怖故事是否完全基于由于使用第三方加密库而导致的组织信息安全事件。

像凭证、证书、SQL 密码等秘密信息应该像保护应用程序的“皇冠珠宝”一样进行管理和保护。不要将它们以明文存储在数据库中，不要硬编码这些信息，并在用户离开组织时旋转或撤销与其相关的密钥。像HashiCorp Vault这样的秘密金库提供了这一过程的自动化简化，但需要具备一定的技术技能。

更多阅读资料请参见以下链接：

OWASP 传输层保护备忘单 (cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html)
OWASP 加密存储备忘单 (cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html)
OWASP 密码存储备忘单 (cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)

实施安全日志记录和监控

正如我们在前几章中谈到的安全监控一样，我不认为我需要深入探讨它如何帮助你的组织。最重要的一点是：更多的信息可以帮助你和你的同事更准确地检测到安全事件，并提高响应速度。

你可以增加你的组织开发的应用程序提供给监控解决方案的信息量，但请记住，PII（个人身份信息）或机密信息有时会包含在诊断和调试信息中，可能需要在传递到监控解决方案之前删除。此外，确保你的时间戳在各节点之间对齐，否则数据将不准确且难以使用。

为了防止日志伪造或注入攻击，你应该考虑我们在列表中的*#4和#5*中提到的编码原则和验证练习。另一种防止篡改的保护措施是为你的日志解决方案设置访问控制和授权原则。为了避免可用性的丧失，你的解决方案应该在数据集上采取某种形式的冗余，例如存储在多个位置和备份。

进一步了解如何使用安全日志记录和监控，可以参考OWASP 日志记录备忘单（cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html）。

处理所有错误和异常

确保你的应用程序具有弹性，能够处理错误和异常，这是确保 CIA 三原则（保密性、完整性和可用性）的一项重要属性。错误处理不当可能导致机密或敏感信息的泄露，应用程序稳定性的中断，甚至是你依赖的用于各种监控目的的重要数据的修改。

错误的错误信息可能会给恶意攻击者提供比可接受范围更多的信息。看看这个我认为应该是玩笑的注册页面，否则我已经失去所有希望：

图 8.4 – 有史以来最愚蠢的注册页面错误信息

我只能猜测，在看到那个错误信息后，用户决定使用hunter2作为密码。

在我们创建错误时，确保用户无法获得超出其需求的信息，但要提供足够的信息，让他们自己找到答案或联系支持人员求助。从内部来看，我们希望记录足够的信息，帮助支持团队、测试人员、法医调查人员和事件响应团队。请记住，如果软件开发团队成员与安全、测试和业务团队成员积极合作，将会提高软件的整体质量。

最后，必须创建好的测试，以便在用户发现之前捕捉这些异常。优秀的测试人员，加上一些自动化工具，用于静态和动态地发现错误，将有助于减少支持所需的开销，并减少应用程序丧失一个或多个 CIA 三原则的风险。

更多的阅读内容可以在OWASP 错误处理备忘单中找到(cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html)。

如果你像我一样喜欢这个话题，我认为你可能会对进一步阅读感兴趣，因此我整理了一些框架和流程的链接供你调查。这些对于在 SDLC 中实现安全非常有用：

MS-SDL，微软安全开发生命周期：www.microsoft.com/en-us/securityengineering/sdl
NIST 800-160，工程可靠安全系统的多学科方法考虑因素：csrc.nist.gov/publications/detail/sp/800-160/vol-1/final
网络安全和基础设施安全局的CLASP，或综合轻量级应用安全流程：us-cert.cisa.gov/bsi/articles/best-practices/requirements-engineering/introduction-to-the-clasp-process

好的，我们已经讨论过 SDLC 了，现在可以详细探讨它如何帮助我们评估软件。

评估软件安全

接下来，我想讨论我们可能采用的方法，以评估软件的安全性。在之前的章节中，我们探讨了定期测试软件和系统的重要性，包括渗透测试和漏洞扫描，以及对任何发现进行修复。我提倡实施配置管理系统，以帮助保持组织的资产最新，并使用监控解决方案来发现性能问题、滥用、错误或恶意活动。我还谈到了弹性和冗余，以及每小时组织失去系统访问权限可能造成的高昂费用。

既然我们已经讨论了这些，如果我们要更深入地探讨，我认为将这个话题分为两个部分是相关的，因为方法和方法论会有所不同，这取决于谁拥有软件，并考虑到云操作模型以及与使用软件即服务（SaaS）产品相关的共享责任。

一方面，我们有第三方供应商，他们开发并向公司销售软件。他们的重点是创建对您的组织有价值的工具，如客户关系管理（CRM）系统、HR 软件、生产力工具、网站分析软件、云存储解决方案等。

另一方面，我们也可以利用内部开发团队为我们的组织创建软件，解决供应商目前未提供的问题，或者根据当前第三方提供的成本节省开支。此外，我们还可以利用外包开发团队来创建我们的内部软件，或利用开源软件的力量和便利。

让我们深入探讨如何提高第三方供应商软件的安全性。

降低由第三方供应商开发的软件带来的风险

由于我们已经讨论了可以采取的各种控制措施和流程，以减少软件中代码漏洞的可能性，必须指出，许多您组织的软件解决方案将会是从第三方购买的，或者是从开源软件库（如 GitHub 的公共代码库）中提取的。

需要制定政策和程序，确保无论发生何种情况，都能让你对采购过程有可见性，并对在你公司使用的软件资产进行监督。

问题在于：你能做些什么呢？当我们审视几乎每个组织都在使用的主要软件时，比如微软、Salesforce、Atlassian 等公司开发并销售的软件，如何确保它们为其解决方案采取了适当的控制措施，并且遵循了软件开发生命周期（SDLC）的方法？

基于云的软件

在过去十年中，我们见证了向 SaaS 模型的巨大范式转变，这加快了将新软件实施到组织中的步伐，用户很可能通过其网页浏览器访问该解决方案。使用这种软件的模式导致了服务器和数据库的管理责任从客户转移到供应商。

这并不是说我们在涉及到这些 SaaS 应用程序中处理和存储的数据的隐私和安全时可以完全不负责任；事实上，作为客户，确保我们选择的解决方案对我们的组织来说是足够安全的，完全是我们的责任。

正如我之前提到的那样，安排对目前由 SaaS 供应商提供的基础设施和软件进行测试可能是困难的。原因很简单：这种测试活动可能会带来供应商认为不可接受的风险，因为你可能会不小心中断他们为数百万其他用户提供的服务。没有许可，你也不能对基础设施进行任何测试，否则你将使自己和组织面临法律责任的风险。

那么，我们该如何询问供应商他们的软件安全性呢？

了解第三方软件风险

在本书中，我们之前提到过，从作为信息安全专业人员在软件供应商处工作的角度出发，我们可能会创建一份信息安全白皮书，详细说明贵组织所采用的安全范式和控制措施。话虽如此，既然现在你是潜在的客户，你该如何提问，以确保你们组织正在采购的软件足够安全，并且其控制措施符合相应的风险水平？

好吧，我们执行尽职调查并制定法律文档，明确责任和你们组织与供应商之间的协议。我在前面那部分精彩的内容中已经讲过这些，其中涉及了合同法中的拉丁术语……你怎么可能忘记呢？

在这些协议中，你可能能够安排共享最新进行的渗透测试文档供你审查，或允许你的安全团队作为尽职调查的一部分进行测试。这一切取决于双方愿意达成的协议，以及能够为你提供所需的保障，帮助你满足风险容忍度。正如我们所说，我们必须意识到，渗透测试或甚至漏洞扫描软件解决方案并不总是可行的，但即使你在由第三方开发的软件解决方案中发现了漏洞，你该如何通知供应商，且是否期望他们及时修复这个漏洞？

在你的法律文档中，你可能还想尝试定义SLA和漏洞修复的程序，但我们仍然没有讨论如何更好地了解供应商的安全姿态。我们如何知道他们的安全管理方式是否符合我们所认为的可接受标准？

在这种情况下，我们通常会向软件供应商发送一套文件，通常称为供应商安全评估问卷（VSAQ），让他们在协议签署前填写。大多数组织会发送一些 Excel 表格，其中包含成百上千个问题的行，并配有下拉菜单或自由文本框来填写答案，和/或提供答案的证据和理由。如果你曾在为客户开发软件的组织中担任过安全专业人员，你就必须填写这些评估表格，而且不幸的是，它们从来都不是一样的。谷歌尽力将这些问题标准化，并通过其 GitHub 页面上的开源互动动态解决方案进行共享（github.com/google/vsaq），但从我所见，这个解决方案仍然未被广泛采用。如果我们能实现这一目标，它将真正为我们节省大量时间和精力，同时提供高质量的结果。我们能做到这一点吗？

在收到填写完成的 VSAQ 后，我们将记录供应商未能缓解的剩余风险，并评估这些剩余风险是否低于可接受的风险阈值。如果风险超出可接受水平，我们需要决定是缓解风险、接受风险，还是避免风险。我希望，考虑到我们已经接近书的结尾，这些内容现在应该非常熟悉。

一旦你完成了尽职调查并将结果传达给业务决策者，协议达成并最终确定后，软件的实施将开始。它可能是本地安装的软件，也可能是基于云的 SaaS。

软件供应商的 SDLC 尽职调查

由于我们已经涵盖了 SDC 的各种步骤和要求，现在你已经了解了基础知识，并掌握了进行适当尽职调查所需的大部分信息，确保你能对他们的开发生命周期进行适当的尽职调查。

首先，重要的是不仅要问供应商是否遵循 SDLC 相关的流程，还要让他们详细说明具体是如何执行的。你还可以要求提供证据作为验证方法。如果他们回答“否”，那么你需要将这款没有遵循 SDLC 开发的软件可能带来的风险，向组织内的相关决策者进行强调。

渗透测试和漏洞悬赏

我们或许能够安排对该软件进行渗透测试，但如果是 SaaS（软件即服务），如我们之前所说，不要抱太大希望，因为大多数供应商是不允许的。此外，对所有潜在供应商进行此类深入的技术活动，将很快给你的组织带来高昂的成本。最近，一个新兴的解决方案对供应商和客户都非常有吸引力，那就是实施漏洞奖励计划，供应商将他们的软件开放，接受漏洞赏金猎人进行渗透测试，猎人通过利用安全漏洞获得供应商提供的奖励。像 Bugcrowd（www.bugcrowd.com/）和 HackerOne（www.hackerone.com/）这样的公司，为像你这…

如果供应商声称自己是安全的，但不愿提供渗透测试报告，并且不参与漏洞赏金计划，你可能需要问他们如何处理和优先处理来自渗透测试的漏洞，或者他们使用哪些工具进行 DAST、SAST 或依赖扫描。利用你对安全形势的了解，判断他们是否知道自己在说什么，并尽可能获得证据。毕竟，最终是你们组织的安全性在承受风险。

本地第三方软件

当我们查看安装在公司服务器或终端上的软件时，我们可以采取一些简单的措施，以确保由于该软件中的漏洞不会导致环境安全受到威胁。我们希望通过遵循我们之前提到的最小权限的基本概念，来减少攻击面。

“抱歉，我们的软件需要以管理员身份运行，”供应商告诉你。

你回问他们的第一个问题应该是“为什么？”。你已经了解得足够多，不会仅仅被告知这一点而不继续追问。弄清楚软件是做什么的，为什么需要管理员权限，并找出是否有办法减轻这一风险。

此外，我们在之前的章节中已经讨论过你们组织的漏洞扫描，新的本地软件应该包括在范围内。如果通过这些方式发现了漏洞，值得与供应商开始对话，了解漏洞情况并讨论如何修复。尽管他们可能会因此反应不好，但我完全相信，在不久的将来，不仅仅是你会对他们软件中的安全问题提出质疑。我们可以共同努力，迫使供应商开发符合最佳实践的软件。

那么，关于开源的本地软件呢？

开源软件

当我们谈论开源软件时，我们通常指的是自由开源软件（FOSS）。借助 FOSS，你可以下载已在诸如 GitHub 或 SourceForge 等平台上创建并托管的软件，这些软件允许潜在用户实际查看底层代码。

开源的理念是，我们获得的软件是透明的，经过同行评审的，并且是免费的，开发者希望解决技术（或社会）问题，而没有其他动力，除了出于无私精神并可能展示专业知识。

话虽如此，我们在本章之前讨论过的 Heartbleed 事件，正是源自广泛使用的不安全开源软件。那么，我们如何确保在开发过程中，针对开源工具和代码片段（snippets）已实施了适当的缓解措施？这些工具和代码片段目前正在贵组织使用，或者正在考虑使用。

此外，我们需要记住，我们的许多供应商在开发他们的专有软件时，正在利用开源软件。在我们为尽职调查过程开发 VSAQ 时，请牢记这一点。

从积极的一面来看，我们有能力审查代码。我们的信息安全政策中应该有相关要求，确保我们为自己的软件开发所采取的相同安全措施，也适用于我们使用的开源软件。这意味着要进行依赖性检查、SAST、DAST、漏洞扫描等。通常，我们会创建一个安全管道，自动化定义的流程和安全扫描步骤，适用于任何被认为在范围内的代码或软件。

提升内部软件的安全性

假设内部软件可以包括由贵组织的内部开发团队或外包开发团队开发的软件，以及贵组织所利用的开源软件。尽管这些开源软件（很可能）是由第三方开发的，但你有能力将其视为内部开发的代码，并将其通过相同的保障流程。

我想讨论一下我们如何将安全控制措施纳入开发环境和部署管道，以确保在代码进入生产阶段之前，所有风险都已被识别并采取了相应的措施。

无论是内部开发团队还是外包开发团队，在提高贵组织软件安全性的政策上都应该能够遵循你的指示。有时，外包团队有自己的流程和解决方案来提供与你所要求的相同级别的保障，而其他时候，你可能需要达成协议，以弥补任何差距。

因此，让我们来看看我们如何改善内部软件的安全性。

软件开发生命周期

首先，我们希望实施本章之前讨论过的安全 SDLC 控制。这些政策、程序和工具能够确保贵团队高效且安全地开发高质量的软件。你可以根据贵组织的风险容忍度和现有流程的特点来设计 SDLC，但保持一致性理念将有助于你达成目标。

由于如此，我认为不有必要再详细讲解本章前面已经覆盖过的所有步骤，因此，我更希望讨论一下我们如何实施实际控制，以实现之前讨论过的高层目标。

代码库

贵组织很可能使用代码库解决方案来存储和版本控制任何开发的软件。代码库的例子可能包括 GitHub、Bitbucket 或 GitLab 等。

在这些工具中，我们提供了多种可用的功能和控制，确保我们的 SDLC 要求得到满足。例如，问题跟踪器允许开发人员、产品团队成员及其他相关方之间对软件缺陷、功能请求、漏洞发现等进行透明讨论。这些问题跟踪器可以帮助团队估算需求、分配优先级，并给每个问题打上复杂度评分，从而帮助组织如何处理它们。

存在所谓的分支，允许开发人员在开发环境中积极开发和修改软件，而不会影响主分支（该分支用于生产环境），甚至可能是当前迭代的开发分支。你需要保护这个分支不被随意更改，除非经过各种形式的批准，例如代码审查、测试，并确保合并遵循职责分离和两人原则。

每次对代码的更改都会被记录并归属于相关软件工程师，从而实现透明的审计过程和清晰的审批文档。所有提交都可以通过公钥加密技术进行签名，确保每个工程师对代码库的增量贡献具备不可否认性和完整性。

此外，如果我们考虑到之前讨论过的基础设施即代码的理念，就有可能将贵组织服务器和工具的配置文件存储在代码库中，并对其进行与软件开发同等严格的审查。

DevSecOps 流水线

持续集成和持续交付（CI/CD）管道为确保只有符合规定要求的软件才能部署到流程的下一阶段提供了自动化流程，并且通过依赖管道，您能够将开发人员和系统管理员的访问权限限制到最小特权，这意味着他们在没有遵循管道流程并获得适当批准的情况下，无法访问或更改生产系统。

这些管道通常与DevSecOps相关，其中我们通过自动化和管道将安全性融入 DevOps 生命周期。

让我们来设想一下这个管道流程，适用于贵组织的软件开发过程：

一名软件开发人员使用他们的 SSH 密钥访问项目的 Git 仓库，从开发代码中创建一个“功能分支”，并将代码克隆到他们的工作站进行本地开发。
它们的交互式开发环境（IDE）参考安全编码范式，并执行正则表达式检查，以查找明文密码和秘密，立即在发现缺陷时通知开发人员，让他们在将代码提交回代码库并触发管道流程之前进行修复。
开发人员进行更改，并尝试将代码提交回他们创建的 Git 分支。检查他们的访问权限以确保他们被允许这样做，记录他们的更改，并在 Git 解决方案中突出显示差异。
CI 管道运行并执行以下检查：
- 一个依赖扫描器评估任何导入软件的风险概况。
- 静态代码分析由SAST执行，用于检查代码质量和任何安全风险。
- 一个秘密检查器查找存储在代码中的秘密和密码。
- 一个容器审计员检查定义的基础设施即代码中是否存在漏洞。
- 更新后的软件的短暂版本被部署到测试环境中，DAST执行适当的检查，寻找错误、安全漏洞和性能问题。
- 如果所有自动化系统都通过，另一个开发人员将通过电子邮件或聊天收到通知，并进行代码审查。
- 如果代码审查通过，测试人员将收到通知，功能将由人工进行测试。
- 如果所有步骤都通过审批，代码将合并，并且CD 管道将运行以将更改实施到下一个环境中。

这一过程需要精心实施，并为参与的各个团队成员定义过程和期望，但它可能导致一个以自动化为核心的精简、安全的开发过程。

摘要

在本章中，我们讨论了提高软件安全性的非常有趣的话题，并重点介绍了我们可以用来确保组织内使用的软件从风险角度来看“足够安全”的各种方法。

在本章开始时，我们讨论了一些通用的软件安全框架，包括 SDLC（软件开发生命周期），以及确保这一过程有效执行所需的步骤。

随后，我们强调了我们在多大程度上依赖第三方开发的软件系统，尤其是当这些系统的开发过程不透明时，比如当我们从供应商处采购软件，而供应商没有披露其安全性策略时。我们深入探讨了如何更好地理解第三方软件所带来的风险，无论是专有解决方案，还是开源模型下的风险。

基于此，我们探讨了如何利用 SDLC 的知识来在公司内部开发更好的软件，将测试和自动化作为解决方案的核心，确保在发现漏洞时具有可扩展性和高效性，这些漏洞可能会导致机密性、完整性或可用性的丧失。

总体而言，本章的学习内容帮助我们理解在制定与软件开发及使用相关的要求、政策和程序时，应关注哪些方面。掌握这些知识后，你就能够准确评估风险，并应对任何超出可接受风险容忍度的残余风险。

至此，你已经完成了本书的阅读。非常感谢你抽出时间阅读！希望你在阅读过程中不仅享受了乐趣，还学到了一些有用的知识。如果我能帮助你提升组织的安全态势，我感到非常高兴。

我想借此机会感谢我的妻子 Helen，在这一路上的支持与关怀。此外，我还要感谢 Packt 团队的所有成员，他们在本书的创作过程中从头到尾给予了我支持。

Packt.com

订阅我们的在线数字图书馆，全面访问超过 7,000 本书籍和视频，以及帮助你规划个人发展和提升职业生涯的行业领先工具。欲了解更多信息，请访问我们的网站。

第十章：为什么订阅？

通过来自 4000 多位行业专业人士的实用电子书和视频，减少学习时间，增加编码时间
利用为你特别定制的技能规划提升学习效果
每月获取一本免费的电子书或视频
完全可搜索，方便访问重要信息
复制并粘贴、打印、收藏内容

你知道 Packt 提供每本出版书籍的电子书版本，并且有 PDF 和 ePub 文件可供下载吗？你可以在packt.com升级到电子书版本，作为纸质书籍的客户，你可以享受电子书版本的折扣。欲了解更多信息，请通过customercare@packtpub.com与我们联系。

在www.packt.com，你还可以阅读一系列免费的技术文章，注册多种免费的新闻简报，并获得 Packt 书籍和电子书的独家折扣和优惠。

你可能喜欢的其他书籍

如果你喜欢这本书，你可能会对 Packt 出版的以下书籍感兴趣：

CompTIA Security+实践测试 SY0-501

Ian Neil

ISBN：978-1-83882-888-2

了解你为 CompTIA Security+认证做好了多少准备
识别不同类型的安全威胁、攻击和漏洞
探索企业环境中的身份和访问管理
保护你的商业工具和平台免受网络攻击
创建并维护一个安全的网络

精通 Linux 安全与加固 - 第二版

Donald A Tevault

ISBN：978-1-83898-177-8

创建具有强密码的受限用户帐户
使用 iptables、UFW、nftables 和 firewalld 配置防火墙
使用不同的加密技术保护你的数据
强化安全外壳服务，防止安全漏洞
使用强制访问控制防止系统漏洞
强化内核参数并设置内核级审计系统
应用 OpenSCAP 安全配置文件并设置入侵检测

Packt 正在寻找像你这样的作者

如果你有兴趣成为 Packt 的作者，请访问authors.packtpub.com并立即申请。我们已经与成千上万的开发者和技术专业人士合作，帮助他们与全球技术社区分享他们的见解。你可以提交一般申请，申请我们正在招聘的特定热门话题的作者，或者提交你自己的创意。

留下评论 - 让其他读者知道你的想法

请通过在您购买该书的网站上留下评论，与他人分享您对这本书的看法。如果您是通过亚马逊购买此书，请在本书的亚马逊页面上给我们留下真实的评论。这一点至关重要，因为其他潜在读者可以看到并利用您的公正意见做出购买决策，我们也能了解客户对我们产品的反馈，而我们的作者则可以看到您对他们与 Packt 合作创作的作品的反馈。这只需要您几分钟的时间，但对其他潜在客户、我们的作者和 Packt 来说都非常宝贵。谢谢！