Compare NetBox inventory with database of known vulnerabilities

[mmguero]

Feature-tracking issue dependent on #131

• possibilities
  • NIST API
  • CSAF

[mmguero]

@piercema suggests looking into Common Platform Enumeration (see also NIST and nmap.org) as a way to store the information about platforms of the devices in the inventory. I think that's a great idea.

As to where to store the information on a per-device basis, platform seems to make the most sense, if there is a place for it there. If not, creating a custom field type that either belongs to platform or belongs to devices/VMs seems like the way to go. If we can come up with the way to consistently store platform information with the devices we can reproducibly check it against a vulnerability database like CSAF.

[mmguero]

Although as indicated here (nmap.org), a CPE name is definable as a URL of sorts that looks like cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*. As such, it's possible we could just store them in the device or VMs comments field instead of creating a custom type. This might be a first step to play with during development.

[tschmidtb51]

@piercema suggests looking into Common Platform Enumeration (see also NIST and nmap.org) as a way to store the information about platforms of the devices in the inventory. I think that's a great idea.

Sorry, I don't. CPE has some severe issues (e.g. look at the entries in the CPE dict for Siemens). I don't want to say that it doesn't work - in fact it works quite well for e.g. RedHat.

So my question is: Is it just for storing data? Then, the format doesn't really matter. Is it for matching against an advisory? Well, then you should have the same identifier the vendor uses in its advisories... And this might not necessarily be CPE or the data used in CPE. Although the vendor/product_name/product_version can get you quite far.

Happy to have a chat.

[mmguero]

Thanks for the reply @tschmidtb51, copying this from my email to you for tracking purposes:

Here are our thoughts regarding this feature. I'm new to the world of vulnerability indicators and whatnot, although Melanie has got more experience with it. @piercema feel free to chime in if I've missed something here.

Here are the thoughts that led us to where we are:

• What we're looking at CPE for is for matching, not just for storing the data for human-readable consumption or reports. If it were, NetBox has already got the platform model for the string to be stored in.
• We're attempting to, in as much of a one-size-fits-all generic way, provide a way for software/firmware details about a device to be stored in a repeatable way for comparison against some feed or database of known vulnerabilities.
• We'd prefer not to reinvent the wheel and come up with our own string format for storing this information.
• The CSAF framework's design principles (see https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#21-construction-principles) states the following, which to us appeared to indicate that CPE is the preferred platform referencing schema for use with CSAF. Is this not the case?
  • Delegation to industry best practices technologies is used in referencing schemas for:
    • Platform Data:
      • Common Platform Enumeration (CPE) Version 2.3 [CPE23-N]
• Some of @piercema's initial research has led her to the conclusion that CSAF as a format allows for specifying CPE data for assets, but that it is not consistently utilized across the feeds she was looking at.
• As an alternative to CSAF, we've been talking about using the NIST API to pull CVEs from the NIST database, as it seems CPEs are used more consistently in that database. However we realize this is not quite an apples-to-apples comparison, as NIST is a specific database with an API to access it while CSAF is an open specification.

I think that's about it. I guess, in short, we'd love to hear your opinion on an alternative to CPE for representing platform information in a standardized way suitable for comparison against common vulnerability feed formats. I can see in some of your comments/commits on oasis-tcs/csaf (https://github.com/oasis-tcs/csaf/issues/91, https://github.com/oasis-tcs/csaf/pull/324, https://github.com/oasis-tcs/csaf/actions/workflows/cpe.yml, etc.) that this is something you've got experience with.

[danpetraru]

For OS vulnerabilities you can use the wazuh api - piggyback on existing deployment OR add Wazuh to Malcolm - this would be a nice integration Pros : wazuh agents are easy to deploy, wazuh app has the requested data Cons : for large env. you do need proper/multi-node wazuh deployment

[mmguero]

As part of our collaboration with BSI-Bund (www.bsi.bund.de, github org), they are going to be taking over this development of this feature. Marking as external, will update this issue as their work continues.

[mmguero]

Kamino closed and cloned this issue to cisagov/Malcolm