深化风险洞察，保障安全合规

如若无法发现风险或漏洞，您就无法采取措施来降低风险或补救漏洞，也无法向监管机构证明自己能够妥善处理具体问题。但是，监测能力是网络安全团队面临的共同挑战。

Forrester 2024 年进行的一项研究发现，超过一半 (52%) 的金融公司认同或非常认同他们缺乏对 IT 资产的全面监测能力。对任何行业来说，不合规带来的风险都很高。从 2023 年到 2024 年，支付超过 10 万美元监管罚款的企业数量飙升了将近 20%。

在我们合规系列的第一篇博文中，我们阐述了将监管合规工作与分层安全策略相对应的观点。采取主动方法来弥补监测能力差距可以帮助您满足针对以下方面的安全合规要求：

• 展示您的控制措施
• 执行风险管理评估
• 提交审计报告

在本博文中，我们将探讨企业在网络安全和 API 保护方面遇到的监测能力问题，并讨论企业可以添加哪些层来增强其合规性。最后，我们还提供了一些出色的安全措施来帮助您遵守监管要求。如果您看到了风险，就能更好地抵御风险。

我们从很多网络安全负责人那里了解到，他们的团队缺乏有效监控网络流量的能力，因此无法看到哪些资产正在相互通信等风险因素。对于支付卡行业数据安全标准 (PCI DSS v4.0) 和通用数据保护条例 (GDPR) 等标准和法规来说，能够有效监控网络流量至关重要。

上述标准和法规都要求在 IT 环境中将范围内的数据与其他系统相分离，并报告您的相关工作。网络监测能力对于国际标准化组织 (ISO) IEC 27001 等信息安全管理系统 (ISMS) 标准来说也非常重要，该标准要求隔离数据和数据处理设施，以阻止在攻击者入侵网络后进行横向移动。

企业通常会部署一些基准层以实现监测能力；例如，传统网络防火墙可以提供一些见解。但是，这些层未跟上企业向由云环境和微服务组成的复杂 IT 资产转变的步伐。因此，安全团队缺乏以下能力：

• 确保企业在运营、销售和/或使用第三方产品的众多地区遵守各种法规的要求

• 清楚地了解应用程序和最终用户在整个网络中如何与数据库进行通信和交互

这些监测能力差距使得您的企业难以向监管机构证明自己如何检测网络威胁并防范可能会导致数据失窃、运营中断和感染恶意软件的攻击。监测能力不佳也使得企业难以满足技术要求，例如 PCI DSS v4.0 的第一条要求，其中规定必须对防火墙进行配置，以限制受信任网络与不受信任网络之间的连接。

弥补网络流量方面的监测能力差距的一种方法是，增加一个软件定义的微分段层，以便对网络中资产之间的通信进行可视化、监控和识别。此方法：

• 提供对网络交互的精细控制，并帮助企业了解、隔离和阻止在跨越本地和云端的复杂网络环境下，特定数据中心内各种设备之间的非法网络流量（即，东西向流量）

• 让企业能够将网络划分为多个分段，并针对每个分段的风险属性定义相应的安全控制措施，从而抵御和遏制勒索软件攻击

• 可以增强东西向监测能力，使安全团队能够更好地了解“谁可以访问什么”敏感资源，例如客户的信用卡数据

在您考虑贵企业能够使用哪些微分段层来增强网络监测能力的同时，可以寻找提供实时和历史见解的功能。这样就能在合规审计过程中提供证据，证明范围内的数据和资产未遭到破坏。

我们也知道，一些安全团队难以获得对其快速增长的 API 资产的监测能力。每次客户、合作伙伴或供应商以电子方式与企业进行互动时，API 都会在后台传输数据，并且这些数据通常都是敏感数据。现在的攻击者知道，由于存在错误配置、糟糕的身份验证控制及编码错误等因素，API 都非常容易受到攻击，并且相对容易进行入侵。

很多企业只能看到他们全部 IT 资产的一部分，因为他们的很多 API 都处于隐蔽状态，并且无法通过传统 API 保护工具进行检测。我们的 2024 年 API 安全影响研究表明，拥有完整 API 清单的安全专业人员中只有 27% 的人真正知道哪些 API 会返回敏感数据，这一比例低于 2023 年本就令人担忧的 40%。

按行业进行筛选后，我们发现在哪些 API 会在响应请求（无论这些请求来自合法用户还是攻击者）时提供敏感数据方面的监测能力更低。

• 医疗保健：相关的 API 占比只有 24.0%
• 保险：相关的 API 占比只有 20.7%
• 政府/公共部门：相关的 API 占比只有 18.5%

我们以医疗保健行业为例，说明其中的利害关系：如果攻击者可以轻松操纵提供商错误配置的 API 来检索患者记录，那么这种操纵行为可能会导致 HIPAA 审查和罚款。

一些法规中明确提到了 API。例如，PCI DSS v4.0 包含如何确认某个企业的软件是否安全地使用了外部组件功能的相关指导。这包括用于将支付信息（如信用卡数据）从移动应用程序传输到银行系统的 API。

在其他法规实例中，虽然并未直接提到 API，但其中的要求也明确侧重于保护依赖 API 才能实现的技术。例如，欧盟的《数字运营弹性法案》(DORA)，该法案旨在帮助欧盟成员国的金融服务企业抵御网络攻击并从中恢复。

DORA 的第 3 条要求企业使用符合以下条件的信息和通信技术 (ICT) 解决方案及流程：

• 尽可能地减少与数据相关的安全风险、未经授权的访问和技术缺陷

• 防止数据不可用、数据丢失以及数据完整性和机密性违规

• 确保数据传输安全

API 的主要功能是帮助实现快速、可靠且安全的数据传输。因此，要遵守 DORA 的要求，必须对对每个会接触到企业数据的 API 进行发现、风险评估和保护。

这些控制措施也有助于更好地遵守 PCI DSS、GDPR 及一系列旨在确保网络恢复能力和数据安全性的法规。如果您正在考虑添加多个层来增强对 API 及其风险的监测能力，那么您需要能够：

• 发现 IT 环境中的每个 API（受管和不受管），包括僵尸和影子 API

• 评估每个 API 的风险因素，例如它一直在交换的数据的类型以及可以访问这些数据的用户或对象

• 对情境洞察信息进行可视化，以识别数据泄露、可疑行为、恶意爬虫程序和 API 攻击等风险。

• 记录数据流

• 生成将企业的 API 安全态势与监管标准相对应的合规性报告

总而言之，我们认为遵守信息安全合规框架和法规需要采取核心在于保护攻击面内各个区域的分层方法。

请关注本博文系列的后续文章，其中将介绍与当今监管机构对安全合规管理的要求直接相关的最佳安全实践。这包括阻止网络、应用程序和 API 之间的横向移动。