Consider Expanding VulnerabilityType in Exploit Target

[ikiril01]

We should consider expanding the VulnerabilityType's ability to characterize software vulnerabilities beyond simply the identity of the vulnerability. Some of the notional new properties could include the following:

Impact (String; the effect and extent of the vulnerability.) Source (String; the source of the CVE description, as a textual description, or URL?) @is_known (Boolean; a simple flag for whether the vulnerability is known (i.e. not a 0-day) at the time of characterization) Description (String; a description of the vulnerability, especially useful if no CVE ID is available). Discovered (DateTime; the date/time the vulnerability was discovered) Last_Modified (DateTime; the date/time the entry describing the vulnerability was last modified) Name (String; the name/identifier of the vulnerability, especially useful if no CVE ID is available) Published (DateTime; the date/time the entry describing the vulnerability was published) References (list of CybOX URI Objects; a list of external references describing the vulnerability) Severity (String; the severity of the vulnerability, as described by NVD) Type (String or enum? The type or class of vulnerability, e.g. race condition. Could also be a CWE reference?) Affected_Software (list of CybOX Product Objects; a list of software products that are vulnerable)

[johnwunder]

In talking this through, @sbarnum thought that the following items might not be appropriate to add:

• Impact
• Last_Modified
• Type

[johnwunder]

Should also check to see whether this can be supported in CVRF.

[johnwunder]

The STIX 1.1 proposal was accepted with some modifications. Specifically, the @is_publicly_acknowledged will be added and the annotations will state that the field is used to denote whether the vulnerability is publicly acknowledged by the vendor. We will also ensure that either in this version or a future one, CPE names may be used for the Affected_Software field.