漏洞管理_漏洞管理，广阔视野

最新推荐文章于 2025-04-29 11:25:52 发布

weixin_26722031

最新推荐文章于 2025-04-29 11:25:52 发布

阅读量1.1k

点赞数

文章标签： python 安全 git

原文链接：https://medium.com/ochrona/vulnerability-management-taking-a-wide-view-7516f0e71a1e

版权

漏洞管理

什么是漏洞管理？ (What is Vulnerability Management?)

We’ll start at the beginning. According to ISO 27002, a vulnerability is

我们将从头开始。根据ISO 27002，漏洞为

A weakness of an asset or group of assets that can be exploited by one or more threats.

一种资产或一组资产的弱点，可以被一个或多个威胁利用。

The SANS Institute goes on to summarize Vulnerability Management as

SANS研究所继续将漏洞管理总结为

… the process in which vulnerabilities in IT are identified and the risks of these vulnerabilities are evaluated. This evaluation leads to correcting the vulnerabilities and removing the risk or a formal risk acceptance by the management of an organization.

…识别IT漏洞并评估这些漏洞的风险的过程。这种评估可以纠正漏洞，并消除组织管理层的风险或对风险的正式接受。

In security our primary measure is “risk”, and our mandate is to understand, lessen, and control that risk. If you remember back to your ISC2 studies, risk is the outcome when you combine threats and vulnerabilities, with threats being anything that can exploit a vulnerability to cause damage to an asset.

在安全方面，我们的主要措施是“风险”，而我们的任务是理解，减轻和控制该风险。如果您还记得ISC2的研究，则将威胁与漏洞结合在一起就可以得出风险，威胁就是可以利用漏洞造成资产损坏的任何事物。

Risk = Threat * Vulnerability

风险=威胁*脆弱性

So with some of the tomes of the industry weighing in with such broad strokes, why does it often feel like the modern implementation of vulnerability management tools are so narrowly focused on vulnerability scanners, IP addresses, and CVEs as the archetypal entities? I believe that all of the terms above are defined in such vague language is on purpose, and that’s because the nature of defining what is a vulnerabilities is fluid itself.

因此，随着行业中的某些主题广为流传，为什么感觉到漏洞管理工具的现代实现常常像原型实体那样狭focused地专注于漏洞扫描程序，IP地址和CVE？我相信以上所有术语都是用这种模糊的语言定义的，这是有意为之的，这是因为定义什么是漏洞的本质本身就是不确定的。

什么是现状？ (What is the Status Quo?)

In the vendor landscape today there are a few primary object types that the solutions are modeled around.

在当今的供应商环境中，有几种主要的对象类型可以用来对解决方案进行建模。

First are assets, which most often can just be considered as computers of one sort or another. These can be employee workstations, servers, virtual machines, IoT devices and much, much more. They are often identified by an IP Address or a hostname/fqdn. These asset objects often also contain other identifying and/or actionable attributes that are collected during a vulnerability scan. For example attributes such as the MAC Address, operating system, BIOS uuid, and many, many more are frequently added to provide additional context around the assets themselves.

首先是资产，通常可以将其视为一种或另一种类型的计算机。这些可以是员工工作站，服务器，虚拟机，物联网设备等等。它们通常由IP地址或主机名/ fqdn标识。这些资产对象通常还包含在漏洞扫描期间收集的其他标识和/或可操作的属性。例如，经常添加诸如MAC地址，操作系统，BIOS uuid之类的属性，以及许多其他属性，以在资产本身周围提供其他上下文。

Next are vulnerabilities. These are most often mapped directly to a CVE, which conveniently come with a CVSS score attached to communicate its severity. Frequently though, within the different vulnerability management tools, there can be other vulnerabilities reported that don’t have an associated CVE, but are clearly vulnerabilities in many circumstances. An example of this might be an open port on a host that should not be exposed.

接下来是漏洞。这些最经常直接映射到CVE ，其中方便地配备了CVSS附着传达其严重程度评分。但是，在不同的漏洞管理工具中，经常会报告其他漏洞，这些漏洞没有关联的CVE，但在许多情况下显然都是漏洞。例如，主机上的开放端口不应该公开。

为什么这是个问题？ (Why is this a problem?)

While this system can work very well in isolation, where it begins to fall apart is once products from different vendors are used together. Things can still work well for vulnerabilities that directly tie to a CVE, but when vulnerability findings from disparate products are aggregated together and there is a disconnect between the perceived severity level of different vulnerabilities it can limit a team’s ability to categorize and prioritize remediations.

尽管该系统可以很好地隔离运行，但一旦将来自不同供应商的产品一起使用，它就会开始崩溃。对于直接与CVE相关的漏洞，事情仍然可以很好地进行，但是，如果将来自不同产品的漏洞发现汇总在一起，并且不同漏洞的严重程度之间存在脱节，则会限制团队对补救进行分类和确定优先级的能力。

As security organizations grow, the larger the likelihood is that there will be a growing number of tools and vendors used internally. Consolidating all of the generated data in a way that is accurate and actionable is the crux of the problem.

随着安全组织的发展，内部使用的工具和供应商的可能性将越来越大。问题的关键在于以一种准确且可操作的方式整合所有生成的数据。

As security teams today see more and more requirements from emerging domains like DevSecOps and cloud governance the types of data that need to be handled has expanded far beyond network/host based CVEs.

随着当今安全团队看到新兴领域(例如DevSecOps和云治理)越来越多的需求，需要处理的数据类型已经远远超出了基于网络/主机的CVE。

but a risk ain’t one

但风险不是一个

我们缺少什么？ (What are we missing?)

There is certainly some danger here in defining what Vulnerability Management is too broadly — however since we’ve seen that the status quo is already missing notable categories, I think it is valuable to include the following domains:

在定义什么范围的漏洞管理时肯定存在一定的危险-但是，由于我们已经看到现状已经缺少值得注意的类别，因此我认为包括以下领域很有价值：

软件漏洞(AppSec) (Software Vulnerabilities (AppSec))

This is a huge category, encompassing everything from Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Software Composition Analysis (SCA) to Container Security to Pen Testing tools.

这是一个巨大的类别，涵盖了从静态应用程序安全测试(SAST)，动态应用程序安全测试(DAST)和软件组成分析(SCA)到容器安全到笔测试工具的所有内容。

There are some blurred lines between several of the categories of AppSec tools, and they can output a CVE and/or a CWE, or neither. Their subjects also differ greatly from what we traditionally consider as assets since they’re not a host, but rather just a piece of software under development or actively deployed.

AppSec工具的几种类别之间存在一些模糊的界线，它们可以输出CVE和/或CWE，或两者都不输出。它们的主题也不同于我们传统上认为的资产，因为它们不是主机，而只是正在开发或积极部署的软件。

Remediating AppSec findings can also be difficult because applications are tested using different tools at different steps in the SDLC, making quick developer feedback of paramount importance. Remediation itself is also best left to the developers since the steps to remediate are often as simple as applying the latest patch.

补救AppSec的发现也可能很困难，因为在SDLC中的不同步骤使用不同的工具对应用程序进行了测试，从而使开发人员Swift获得至关重要的反馈。补救措施本身也最好留给开发人员，因为补救步骤通常与应用最新补丁一样简单。

Shadow IT(攻击面发现) (Shadow IT (Attack Surface Discovery))

At a certain scale, just knowing what assets belong to an organization becomes challenging. Whether you have multiple development organizations or you engage in a merger/acquisition it becomes very difficult to maintain an accurate, up-to-date list of all of the assets and services that a VM team needs to oversee.

在某种程度上，仅知道组织属于什么资产变得具有挑战性。无论您有多个开发组织还是参与合并/收购，维护VM团队需要监督的所有资产和服务的准确，最新列表都是非常困难的。

Even the best Vulnerability Management teams can’t protect what they don’t know about, making this category vitally important for having complete visibility into an organization’s attack surface.

即使是最优秀的漏洞管理团队也无法保护他们所不知道的东西，因此使该类别对于完全了解组织的攻击面至关重要。

云 (Cloud)

The Cloud is pervasive in IT today, touching nearly every organization to some degree. Managing risks in the cloud is a massive undertaking all its own, requiring everything from managing permissions to tracking down rouge resources.

云在当今的IT中无处不在，几乎在一定程度上影响了每个组织。管理云中的风险是一项艰巨的任务，需要从管理权限到跟踪恶意资源的一切工作。

One major difficultly for cloud security as it relates to VM is the ephemerality of many assets in the cloud. Additionally, depending on how your organization is leveraging the cloud you may only have varying levels of access to remediate issues on your own.

云安全与VM相关的一个主要困难是云中许多资产的短暂性。此外，根据您的组织利用云的方式，您可能只能拥有不同级别的访问权限来自行解决问题。

我们从这里去哪里？ (Where do we go from here?)

Think of Vulnerability Management as a process rather than a tool. There are a lot of awesome tools out there that solve some subset of the problems described here — but it may be more useful to start thinking of some of these as Vulnerability Assessment rather than Vulnerability Management.
将漏洞管理视为过程而非工具 。有很多很棒的工具可以解决这里描述的问题的一部分，但是开始将其中一些视为漏洞评估而不是漏洞管理可能更有用。
Redefine what an asset is. We need to redefine assets to be more flexible than just some kind of a computer — an asset could be a workstation, a server, a piece of code, a running container, or more. We need to be able to think of assets generally, but address them specifically.
重新定义什么是资产 。我们需要重新定义资产，以使其不仅具有某种计算机的灵活性，而且资产可以是工作站，服务器，一段代码，正在运行的容器或更多。我们需要能够一般性地考虑资产，但是要具体解决它们。
Vulnerabilities also need some redefining. While CVEs with CVSS scores work well as a means of ranking severity, they fall short when in instances where vulnerabilities are not a specific instance of a known weakness.
漏洞也需要重新定义 。尽管具有CVSS分数的CVE可以很好地作为对严重性进行排名的一种手段，但是当漏洞不是已知弱点的特定实例时，它们就不足。
Improve how we aggregate and prioritize risks. Teams today are understaffed and overwhelmed — they need to be able to take in findings from a number of tools across categories and prioritize remediations objectively. There are some vendors on the market today trying to address this issue, but they are not yet widely deployed or understood.
改善我们汇总和确定风险优先级的方式 。如今，团队人手不足且不知所措-他们需要能够从各种类别的许多工具中获得发现，并客观地对修复进行优先排序。当今市场上有一些供应商试图解决此问题，但它们尚未得到广泛部署或理解。

I’d love to hear your thoughts on the topic, did I go too wide? Are there existing tools and frameworks that are helping you grapple with a more expansive perspective on vulnerability management? Leave a comment below.

我很想听听您对这个话题的想法，我做得太宽泛了吗？是否有现有工具和框架可帮助您应对漏洞管理的更广阔视野？在下面发表评论。

翻译自: https://medium.com/ochrona/vulnerability-management-taking-a-wide-view-7516f0e71a1e

漏洞管理