Support common formats STIX & CVRF

[chrisdlangton]

Support for common formats STIX & CVRF will provide compatibility to so many tools that export to these formats.

Additionally, building your own scripts and tools have a standard format to target will have value (in terms of interoperability) if aggregator tools actually adhere to standard formats and not just proprietary ones.

[chrisdlangton]

p.s. (from the README)

The Vulnerability Standard will initially be a new simple one level JSON with all the information that matches from the different scanners having standardized variable names, while maintaining the rest of the variables as they are. In the future, once everything is implemented, we will evaluate moving to an existing standard like ECS or AWS Vulnerability Schema; we prioritize functionality over perfection.

Using the word standard has connotations, if VulnWhisperer is the only place the format is used it is not a standard it is just a common format VulnWhisperer uses to map other formats/ schemas.

STIX and CVRF are standards, by supporting these you might even avoid needing your own common format at all as mapping to STIX and CVRF is unlikely required to be effort for VulnWhisperer because most 3rd parties already output STIX or CVRF

[chrisdlangton]

p.s.s. If VulnWhisperer goes ahead and creates a common format to map 3rd party formats, then VulnWhisperer is creating yet another disparate format, it might as well be proprietary.

[qmontal]

Hi @chrisdlangton,

The reason of implementing a vulnerability standard is that currently, every scanner module is implemented separately and each scanner has its variables names and specific outputs (eg. severity values differ between scanners), and the intention is to do a conversion of all of them to a single format to have interoperability with the other modules.

Once the implementation of a conversion is done, the values of the end format can be changed; the problem is not the standard itself, but all the work (each scanner value mapping, implementation and refactoring) behind the decision. We are giving priority to doing and moving forward instead of perfect planning but having nothing done, which was the problem with the current amount of resources.

Also, the whole standardization process not only affects the output of the scanners, but the creation of guidelines regarding module implementation and code abstraction, so that its easier for users to add support to new specific scanners without much work behind it.

We are open to ideas and PRs, feel free to join the Slack channel and share them.

Cheers

[chrisdlangton]

@qmontal instead of creating adapters to ingest 3rd parties disparate formats, you could write code to accept STIX or CVRF and the same 3rd parties don't actually need you to write code or support disparate adapters. Allow me to demonstrate;

• Nessus has CVRF and STIX is coming
• Qualys, you should follow and contribute to this thread for CVRF, though since the product launch there has been no more on STIX publically, more info may be hidden behind a login
• OpenVAS as usual has not much to learn online, will need to dig through source to figure out if they have support
• Tenable.io have STIX in the roadmap (3 years ago) according to the forums, and it is quite clear based on how often CVRF is quoted by them that they use CVRF in some capacity though i am not a Tenable.io customer i cannot confirm

I could go through all of them but here are some STIX usages I am aware you will get compatibility with once it is supported; MISP (obviously), mitre, Cosive, CERT NetSA Security Suite, RiskIQ, Autopsy (The Sleuth Kit), and MineMeld (paloaltonetworks). That is just page 1 of a quick search and there are some big names here already. Additionally, STIX and OpenIOC are pretty easily interchangeable in my experience.

I could do a search for the wider accepted CVRF standard but you get the picture by now i hope...

Honorary mention MISP are doing it right.