New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add relationship from indicator to vulnerability #15
Comments
Can someone give a practical example of a vulnerability and an indicator for that vulnerability (actual STIX JSON)? It would be beneficial to have this in the spec (or an associated implementation guidance document), and would help me understand to make sure we aren't introducing multiple ways of doing something. I recognize that sometimes "shortcut" relationships are necessary, rather than the more pedantic but accurate ones, but want to make sure we take that into account (my standard example from STIX 1/CybOX 2 is that malware doesn't really connect to a Domain name, but you connect to whatever IP address that domain happens to resolve to). |
I am on mobile right now so hard to craft the JSON, but this is pretty trivial to come up with examples for. I can write an SCO pattern to indicate almost any vulnerability by looking for registry keys that enumerate software versions. This is just one example. Another would be to look for certain User-Agent headers in HTTP, banners on connections, etc etc. These are how most OVAL tests work. Now, it is interesting question on if we EVER want to be getting into this at all. Everyone already uses OVAL for this. Vulnerability scanner vendors are not going to switch to SCO pattern to look for vulnerabilities. So perhaps instead of this request we should be looking at how to use OVAL in STIX. |
Oh, thanks @JasonKeirstead. I didn't even think of vulnerability scanning, which I would argue is outside the scope of CTI; as you said, OVAL is already commonly used for this, and the vulnerability object exists only for linkages to Malware, Threat Actor, etc:
Furthermore, Indicators are described as containing:
and I would argue that indicating a vulnerability does not fall into that. If we want to add this relationship, I feel we need to revise the definition for the use of these two objects in STIX. I don't think such a revision is a good idea, as it represents unnecessary scope creep. |
After discussions on the working calls and email list, the TC decided not to make this change for 2.1. The decision can be revisited in the future. |
Per CSDPR01#20 (https://docs.google.com/spreadsheets/d/1TCNdwL9o4lbblsIlDfeV0mHsBVGMdbFgwp95dhLLfaI/edit#gid=5055878), the community should consider adding a relationship from an indicator to a vulnerability saying that the indicator "indicates" the vulnerability.
The text was updated successfully, but these errors were encountered: