什么是漏洞管理？

CVE 的一个重要局限是，它们通常只列出影响公开软件（如开源应用程序）的威胁。主要原因是，任何人都可以检查公共软件并发现其中的潜在漏洞。组织保留给内部使用的软件更难让第三方研究人员进行研究。因此，软件中的漏洞不一定会在 CVE 数据库中被发现或披露。

这意味着，千万不要因为 CVE 数据库中没有已知漏洞的记录，就认为应用程序不存在漏洞。漏洞总是有可能存在的--威胁参与者也知道--只是尚未报告而已。

但如上所述，安全漏洞有多种形式。

验证失败

软件内无效的 访问控制 流程或配置可能会允许恶意行为者访问软件或将权限升级到用户权限之外。

SQL 注入

SQL 注入漏洞允许攻击者向数据库注入恶意查询，从而操纵数据或从中外泄信息。SQL 注入漏洞通常是由于与数据库连接的应用程序缺乏适当的输入验证而造成的。

跨站点脚本

跨站点脚本漏洞允许攻击者运行恶意脚本。这种类型的漏洞最常影响那些包含拙劣 Javascript 代码的网站。如果攻击者发现了有漏洞的代码，他们就可以诱使网站运行他们选择的脚本，从而有可能让他们访问连接到网站的端点上的资源。

跨站请求伪造

攻击者可利用跨站请求伪造漏洞，向用户当前已通过身份验证的网站或应用程序注入恶意代码。它们与跨站点脚本漏洞类似，主要区别在于跨站点请求伪造漏洞的核心是冒充认证用户执行恶意操作，而不是通过不安全的 Javascript 执行恶意代码。

安全配置错误

任何类型的安全配置错误或疏忽都可能引发漏洞。例如，由于防火墙配置错误，管理员可能无意中通过互联网访问了敏感数据，或者在配置新的应用程序部署时忘记要求进行多因素身份验证。

漏洞管理与漏洞评估

漏洞管理是 IT 组织用来识别和应对漏洞的策略。但是，当发现个别漏洞时，他们会使用一种称为漏洞评估的程序来了解漏洞所带来的风险程度，并帮助确定如何补救。

漏洞评估之所以重要，是因为并非所有漏洞都会带来相同程度的风险。例如，一般来说，只能由可直接实际访问易受攻击系统的攻击者利用的漏洞，比可通过网络利用的漏洞带来的风险要小，因为通过网络进行操作的威胁参与者的数量通常比可实际访问 IT 资产的威胁参与者的数量要多得多。

此外，在某些情况下，只有在特定配置或环境下才能利用漏洞。例如，如果应用程序托管在 Windows 服务器上，但不托管在 Linux 服务器上，那么应用程序中的漏洞就可能被利用，反之亦然。

基于诸如此类的因素，漏洞评估可以让组织确定每个漏洞对其造成的具体风险程度。然后，他们就可以优先应对最严重性的漏洞，将整体风险水平降到最低。

建立漏洞管理框架

尽管漏洞管理计划需要根据所服务组织的独特要求量身定制，但 Gartner 提供了一个漏洞管理指导框架，为开始进行漏洞管理提供了一个有用的起点。

Gartner 框架 的主要组成部分包括

确定计划的范围：企业在开始实施漏洞管理策略时，首先要确定需要处理多少 IT 资产和漏洞类型。

确定角色和责任：确定谁在什么时候做什么是漏洞管理的一个重要组成部分。从 IT 工程师等一线员工到 CISO 和首席技术官，每个人都要在发现、报告和管理漏洞方面发挥作用。

选择脆弱性评估工具：企业必须决定使用哪些工具来查找和评估漏洞，以及如何将漏洞修复纳入工作流程和工具。

创建并完善政策 SLA：服务水平协议决定了组织对漏洞做出反应的速度，也决定了他们可以容忍哪种程度的活动漏洞。服务水平协议是一种特别重要的资源，可根据业务情况进行调整，因为不同的组织可以承受不同程度的风险。

确定资产背景来源：资产上下文源可提供补充信息，如有关系统或应用程序在业务中的作用的数据，这对于评估漏洞及其严重性至关重要。

通过满足上述每一项要求，组织可以建立漏洞管理计划，使其有能力在所有相关系统中发现漏洞并作出反应。

漏洞管理的四个关键步骤

在全面实施时，有效的漏洞管理计划应能让企业在漏洞管理流程中执行以下每个步骤。

识别薄弱环节

你无法修复你看不到的东西。查找漏洞涉及扫描组织内的所有 IT 资产，并确定它们（或其中的任何组件）是否存在漏洞。CVE 数据库是实现这一目的的重要资源，尽管公开的 CVE 列表并不是每个漏洞都有详细说明。

评估薄弱环节

发现漏洞后，必须对每个漏洞进行评估，以确定其对企业造成的风险程度。在某些情况下，可能需要人工进行漏洞评估，但漏洞管理工具可以自动确定每个漏洞的严重性，并评估该漏洞在企业环境中被利用的可能性，从而加快评估过程。

处理漏洞

处理脆弱性的方法主要有三种：

补救措施：补救涉及彻底消除漏洞，通常是通过更新或修补受影响的资产，使漏洞不再存在。

减轻影响：缓解措施使组织能够最大限度地降低漏洞被利用的风险，或减少漏洞可能造成的潜在危害。在补救不可能或不可行的情况下，缓解是一种很好的策略。例如，如果因为没有补丁程序而无法更新存在漏洞的传统应用程序，您仍然可以通过更改应用程序的配置来缓解漏洞。

接受：在某些情况下，IT 组织可能会认为漏洞不够严重，不值得进行修复或缓解。在这种情况下，他们只需接受漏洞。

报告漏洞

漏洞报告是向外部利益相关者披露漏洞的过程。这通常涉及向公共 CVE 数据库提交漏洞报告，但组织也可能根据合规性任务或合同协议的要求，直接向监管机构、客户或合作伙伴报告漏洞。无论哪种方式，报告的目的都是分享有关存在哪些漏洞、造成漏洞的原因以及如何修复漏洞的信息，以便其他人能够在漏洞被利用之前对其做出反应。

改进您的漏洞管理计划

制定了漏洞管理计划并不意味着您可以不再担心漏洞问题，转而关注其他问题。相反，漏洞管理应受益于持续改进的策略，即 IT 组织持续寻找改进漏洞管理策略的方法。

脆弱性管理计划改进的常见例子包括

更广泛地利用自动化技术，提高漏洞管理的效率和一致性。

将更多系统或应用程序纳入漏洞管理范围，以提高覆盖面的全面性。

在评估脆弱性时，利用更多的脆弱性数据库和/或资产背景来源来增加可用数据。

部署新的或增强的漏洞管理工具，以检测以前的系统无法支持的漏洞类型。

诸如此类的步骤使组织能够更有效、更高效地进行漏洞管理，使其更接近于确保实时检测和修复所有漏洞的目标，无论这些漏洞包含什么内容，也无论它们存在于何处。

管理云工作负载漏洞的最佳实践

要确保在云漏洞演变成严重威胁之前就能捕捉到并修复所有云漏洞，并没有什么简单的诀窍。不过，以下策略可以帮助您降低遭受与云有关的严重网络攻击的风险。

将漏洞扫描纳入 CI 流程

在开发生命周期中，越早发现漏洞，它们在生产环境中导致漏洞的风险就越低。

因此，应将漏洞扫描整合到您的 CI 流程中。与其等到工作负载进入生产环境后再进行扫描，不如在开发和暂存环境中扫描主机、容器、无服务器功能和其他资源。即使您的配置在开发/暂存和生产之间发生变化，在部署前监控漏洞仍能最大限度地防止漏洞潜入生产环境。

在生产中保持扫描

当然，在工作负载部署到生产环境后，您还应该执行持续的漏洞监控。再多的部署前扫描也无法替代对生产工作负载风险的检查。

扫描云环境的所有层面

典型的云工作负载包括多层配置。它们中的每一个都可能存在漏洞。

例如，如果您部署容器，容器映像中就可能存在漏洞。在容器编排器中配置的 RBAC 策略中也可能存在漏洞。除此之外，使用云提供商的 IAM 框架配置的策略可能会给容器化工作负载带来风险。

因此，扫描云工作负载的所有层面至关重要。只要存在数据，就可能存在漏洞。

使用 CVE 获取漏洞背景信息

如上所述，有些漏洞比其他漏洞更严重性。但哪些需要立即关注并不总是显而易见的。

尽管如此，要使漏洞警报尽可能具有可操作性，就需要了解每个漏洞的严重性级别。您可以使用 "常见漏洞和暴露"（CVE）数据库来完成这项工作，该数据库列出了已知的漏洞，并根据它们所造成的风险程度进行 "评分"。

通过将漏洞检测与 CVE 数据相结合，您可以获得有关云工作负载风险的上下文化、可操作的见解。

漏洞管理常见问题