云原生安全 | 利用Verified Exploit Paths™ 更好地确定优先级、更快地做出响应

2024年6月，SentinelOne 推出了 Singularity™ Cloud Native Security (CNS)，这是我们的无代理云原生应用保护平台 (CNAPP)，专门设计用于通过威胁行为者的视角评估云环境。随着攻击者越来越多地瞄准云环境，SentinelOne 的最新解决方案可帮助组织更好地防御这些攻击。
CNS 模拟攻击方法来验证漏洞利用路径，即所谓的 Verified Exploit Paths™。通过这种方式，CNS 可以减少理论上可能出现的干扰，以便云安全从业者可以专注于修复最重要的问题。
在这篇文章中，云安全、AI/ML 和核心平台产品管理副总裁 Ely Kahn 和 SentinelOne 云原生安全产品负责人 Anand Prakash 探讨了云原生安全的价值和成果。了解我们的无代理 CNAPP 和独特的 Offensive Security Engine™ 如何帮助安全、开发人员和云团队协作和沟通，从而大幅减少他们的云和容器攻击面。

Ely： Anand，您能概述一下我们对云原生安全（CNS）的总体愿景吗？
Anand：对我来说，云原生安全（CNS）就是像攻击者一样思考的云安全。
当组织构建和运行其多云和容器环境时，会出现许多安全问题：操作系统和应用程序级漏洞、配置错误的云服务、过于宽松的云身份、配置错误的容器部署、泄露的凭据……等等。除了满足合规性需求和与其他团队构建跨职能协作工作流程外，云防御者还必须确保整个资产的可见性，以构建和执行安全策略。他们有太多事情要做，而时间或资源却不够。另一方面，攻击者只有一个明确的职责：找到一种入侵方式。
云原生安全提供了上述所有风险的统一视图，更重要的是，它将攻击者的思维模式应用到云攻击面，以突出显示哪些云有着不安全区域代表着真正可利用的风险。CNS会传达云环境中存在直接利用潜力的关键区域，并通过屏幕截图和代码片段提供证据。我们称之为已验证的漏洞路径™。
有时，CVSS 评分不足以传达风险的影响。了解数百条潜在的理论攻击路径会浪费每个人调查不可利用威胁的时间。CNS 专注于提供证据，这不仅意味着没有误报，还有助于云安全团队有效地与同行合作，快速修复云问题。
Ely：这种自主攻击者的心态对客户来说非常有价值。我认为值得一提的是，这种心态如何为安全团队实现以下几点：
确定哪些风险可利用以及哪些风险需要优先警报
验证风险的性质并提供攻击载体的证据，从而自动执行冲突解决的过程
如何通过向所有团队提供推动行动所需的“那又怎样”的证据，来加速补救漏洞
现在我们已经有了更多的了解，让我们来谈谈云原生安全如何实现这一点。
即时可见性和覆盖范围
Anand：让我们先来了解一下我们如何与客户合作，即新用户引导流程。
作为无代理 CNAPP，CNS 新用户引导仅需几分钟，且结果立竿见影。CNS是一个非常高效的新用户向导，可引导客户熟悉其多云环境。它提供要部署的模板，并在几分钟内允许客户在 AWS、Microsoft Azure、Google GCP、Oracle Cloud、阿里云和 Digital Ocean 之间设置读取访问权限。

这就是 CNS 所需的全部功能，它可在几分钟内实现跨云基础架构的即时可观察性和全面安全性。此外，CNS 还会在启动新帐户、项目和订阅时自动检测它们。这对于确保我们的客户能够完全了解其不断变化的资产非常重要。

根据我们客户的反馈，他们描述了云资产蔓延或“影子云”带来的困扰。对我来说，这种可见性是所有安全性的开始，因为您无法保护您看不到或不知道是否存在的东西！
CNS 提供完整的云资产清单和易于导航的云环境图形浏览器。下图显示了 SentinelOne 图形浏览器，它可以直观地分析云资源。所有安全问题都有一个预先构建的链接视图，显示受已识别漏洞或错误配置影响的云资源的潜在威胁范围。这也是编写查询或创建自定义策略的便捷且直观的方法。只需点击几下，任何搜索和视图都可以转换为可重复使用的安全策略。

云安全态势管理 (CSPM)
Ely：我们来谈谈错误配置。云错误配置通常会给安全和云团队带来麻烦。我们来谈谈我们的云安全态势管理 (CSPM)。
Anand：为了帮助云和安全分析师查找云配置错误，CNS 有超过 2,000 个内置检查，包括轻松添加自定义检查的能力。这些检查涵盖了广泛的云服务，可以按严重程度、云提供商或服务类型快速搜索。
对于每个错误配置警报，CNS 都会提供有关资源性质的详细信息，并在本机云服务提供商控制台中链接到受影响的资源。警报包括对错误配置的简要描述，并提供有关该特定错误配置为何危险的影响声明。然后，CNS 列出了建议工程师采取的补救措施。除了建议之外，还可以根据错误配置的性质提供一键式和自动补救措施。

目前，对于每个错误配置，您可以指定特定的分析师，应用标签以便分析师记录他们的进度，并提供活动概览以允许用户审核操作。正如预期的那样，CNS 还与 Jira 等 ITSM 提供商集成，以提供您的团队可能喜欢的警报工作流程。
Ely：从合规性角度看，我们如何帮助客户？云状态和错误配置通常在合规性的背景下进行查看。
Anand：是的！虽然攻击者并不关心合规性，但这是一项至关重要的业务需求。为了帮助安全分析师轻松满足合规性要求，CNS 包含一个专用仪表板，用于您选择的合规性标准。它涵盖 NIST、SOC、ISO、CIS 和更多监管框架。CNS 还包括随时间推移的实时合规性分数跟踪，可帮助传达团队在组织内的进度。

无代理漏洞扫描
Anand：除了将云资产情境化并寻找云配置错误之外，CNS 还对正在运行的虚拟机和容器进行无代理漏洞扫描。漏洞管理会检查操作系统包、库和正在运行的应用程序中是否存在漏洞，以识别潜在的安全风险。此扫描是连续的，以提供最新的云健康状况视图。CNS 使用来自 25 多个数据库的丰富已知漏洞库，包括 CISA KEV、CVE、RedHat、NVD、MSRP、Kubernetes Security、OSVDB 等。这可确保组织免受新攻击媒介的侵害，为其整个云资产提供全面保护。
此外，我们的漏洞管理还包括一份软件物料清单 (SBOM)，其中详细说明了资源的组件、库和依赖项清单。与我们处理错误配置的方式一样，每个漏洞警报都有受影响资源的图形视图，并且可以分配和跟踪。每个漏洞都有详细信息来将警报情境化，包括 CVSS 分数、EPSS 分数以及攻击媒介、攻击复杂性、所需权限、用户交互、机密性影响、完整性影响、可用性影响和范围的概述。
Ely：真正的价值在于CNS 如何优先处理面向公共互联网的漏洞警报，以及哪些漏洞与同样配置错误的资源相关，从而增加了这些资产的风险状况。它将我们迄今为止讨论过的所有功能结合在一起。
现在，我们已经讨论了云可见性和资产清单、使用 CSPM 查找错误配置，并介绍了漏洞管理。这些都是评估正在运行的云环境的安全功能。我们如何在客户构建时为他们提供帮助？对于错误配置，我们如何将安全性向左移动？
基础设施即代码 (IaC) 扫描
Anand：我想谈谈基础设施即代码 (IaC) 扫描的机会。许多组织利用 IaC 构建可重复的架构，Golden IaC 模板是防止资源配置错误的好方法。CNS 可识别 Terraform 和 CloudFormation 等 IaC 模板文件中的预生产问题。
为了实现这一点，CNS 与流行的版本控制系统进行了多次集成，以扫描这些模板并在它们投入生产之前查明错误配置。在 DevOps 管道中，我们确保根据最佳实践对一致、可重复且适当的配置进行编码。这种左移安全方法使云和 DevOps 工程师能够解决问题并确保在构建阶段采用最佳实践。

对于那些不会立即引起担忧和可利用的问题，我始终建议通过 IaC 方法修复它们，因为它总是比对实时云环境进行更改更安全、更少侵入。
容器和 Kubernetes 安全
Anand：对于需要容器和 Kubernetes 安全的客户，CNS 可以简单快速地与流行的 CI/CD 平台集成，以便在构建容器镜像时对其进行漏洞扫描。通过在开发阶段早期向开发人员提供反馈，可以在将安全问题投入生产之前对其进行补救。
我们可以帮助云防御者将安全措施左移的另一种方法是扫描 Kubernetes 的容器配置文件（包括 Helm 和清单），以查找 Kubernetes 的错误配置。Kubernetes 是一个被广泛采用的容器编排平台，因配置过于宽松而臭名昭著，这给容器化工作负载带来了独特的安全挑战。
Kubernetes 安全态势管理 (KSPM) 远远超出了 CSPM，后者不适合复杂的 Kubernetes 网络配置和 pod 间通信。我们的 KSPM 涵盖从左移扫描到集群及其活动的实时可见性。CNS中的 KSPM 功能可全面了解工作负载、节点、pod、容器和 Kubernetes API，从而实现对 Kubernetes 安全态势的持续监控和评估。
CNS 提供有关您的合规性状况的见解，包括 EKS、GKE 和 AKS 的 CIS 基准、来自三大领先云服务提供商的托管 K8s 服务以及 CIS Kubernetes 框架。例如，借助 CNS，客户可以精确定位过于宽松的角色，并检测缺少适当标签的命名空间，以执行特定于 Kubernetes 的 pod 安全标准。
构建生命周期中 CNS 安全检查的另一个示例是秘密扫描。
Ely：这一点非常重要——凭证泄露仍然是云安全失败的主要原因之一。在开发、测试和准备阶段，API 密钥泄露或意外硬编码凭证非常容易，鉴于其威力巨大，风险状况非常大。从攻击者的角度来看，我们经常看到自动存储库扫描凭证，因为它们可以以明文形式显示。这是威胁行为者登录云帐户、Web 应用程序或云基础设施的一部分的简单切入点，而不是入侵。
秘密扫描
Anand： Ely，你说得对，这是我以前作为漏洞赏金猎人和道德黑客构建的事物。我们很自豪地宣布，Cloud Native Security 领先业界，拥有超过 750 种不同类型的机密和凭据，我们会在代码存储库和配置文件中扫描这些机密和凭据。
CNS 定期扫描构建环境和配置文件中的代码库以及组织的公共和私有存储库以及相关开发人员的公共存储库，以检测和警告潜在的机密暴露并防止凭证泄露。
通过自动细致地扫描每个提交，我们确保在几秒钟内检测到泄漏，让您高枕无忧。此外，CNS 会标记任何新创建的公共存储库，确保任何新的代码库都会立即引起安全团队的注意，以便进行扫描和审查。
对于每个机密警报，除了典型影响、建议的操作和警报选项外，CNS 还提供了已暴露或处于危险中的敏感数据的详细概述。简洁的列表视图包含关键见解，包括机密的具体类型、位置、链接源和链接代码片段、文件名、发现时间和提交的用户。
至关重要的是，CNS 会验证每个机密警报，指示暴露的数据当前是否被视为“有效”。此验证具有自己的时间戳，只需单击按钮即可重新运行，从而使分析师能够实时验证风险并监控补救措施如何降低环境风险。通过单击“重新验证”，系统将重新扫描机密并相应地更新其状态。当团队认为他们已经补救了检测到的机密或怀疑初始检测可能是误报时，它特别有用。

然而，CNS 还更进了一步。CNS 能够实时阻止和防止凭证泄露，并采用强制机制来确保无秘密合并。
最后，CNS 拥有革命性的进攻性安全引擎，这是业界首个自主的红队云安全方法。这就是我们开始对话时的攻击者的心态。
进攻性安全引擎
Anand：在 CNS 的所有发现中，进攻性安全引擎都会区分理论和可利用的漏洞。首先，每个报告的问题都包含检测到不安全问题的路径跟踪。通过此路径，CNS 会使用无毒攻击模拟攻击者方法。然后，CNS 会捕获响应以验证攻击的影响并提供可利用性的证据。此带有证据的已验证漏洞路径™ 意味着每个进攻性安全引擎警报都是确凿的 – 这些发现中不存在任何误报的机会。这是最精细的优先级排序。

Ely：这又是云安全领域的革命性方法。进攻性安全引擎允许安全团队将云警报置于特定情境中，消除理论噪音，并首先集中精力修复真正关键的可利用风险，从而对企业的云态势产生最大积极影响。
这是面向云防御者的以结果为导向的自主安全。通过此次发布，无代理安全功能将成为Singularity 平台整体的一部分。
Singularity 平台中的云安全
CNS 已与Singularity 数据湖进行原生集成，可用于调查和自定义检测。结果采用通用开放网络安全架构框架 (OCSF) 格式。这意味着 CNS 警报和结果可以与 SentinelOne 基于代理的云安全、我们的云工作负载安全以及我们的端点安全遥测和其他合作伙伴反馈的遥测和结果进行关联和结合。
结论 | 了解云原生安全如何保障云安全
回到结果，云原生安全 (CNS) 解决了客户在采用云平台时面临的挑战：庞大的资产足迹、安全警报噪音过多、时间不足以及可预防的问题被发现得太晚。
CNS 为客户提供广泛的覆盖范围，支持所有主要云提供商、源代码存储库、Kubernetes 环境和 CI/CD 管道。安装简单快捷，几乎可以即时查看返回的云资产清单并评估问题。
最重要的是，Cloud Native Security 使用独特的进攻性安全引擎提供基于证据的问题报告。除了检测问题之外，CNS 还会通过漏洞利用证据来验证哪些问题真实存在。
CNS 旨在彻底改变现代企业的云安全，并为安全专业人员提供当前、明天及未来所需的安全工具。通过基于证据的 Verified Exploit Paths™ 节省时间并最大限度地利用资源，确保企业能够专注于关键业务运营并建立强大而持久的云网络态势。