[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Vulnerability as an object
Greetings--I would like to object to two aspects of the 2.1 Draft STIX Standard. 1) The elimination of 'Weakness' as a property_type in STIX 2.0 (dropped from 1.1). The removal of this category removes the relationship tree that we currently use to communicate vulnerabilities to our stakeholders via STIX. As a result we have to strap on an 'external resource = CAPEC or CWE' which does not allow us to communicate the various components and relationships we need to serve our DoD stakeholders. 2) The underlying definition of 'Vulnerability' is not consistent with current NIST guidance. It is also too narrow (software or CVE-based) and does not reflect how we view the fundamental nature of a vulnerability. The current STIX definition looks at 'vulnerability' as a verb, something that is acted upon by something else. Example, "A Vulnerability is "a mistake in software that can be directly used by a hacker to gain access to a system or network" . For example, if a piece of malware exploits CVE-2015-12345, a Malware object could be linked to a Vulnerability object that references CVE-2015-12345. CVE is a list of information security vulnerabilities and exposures that provides common names for publicly known problems [CVE]. The Vulnerability SDO is primarily used to link to external definitions of vulnerabilities or to describe 0-day vulnerabilities that do not yet have an external definition. Typically, other SDOs assert relationships to Vulnerability objects when a specific vulnerability is targeted and exploited as part of malicious cyber activity. As such, Vulnerability objects can be used as a linkage to the asset management and compliance process." (Section 4.18 STIX 2.1 Draft, p. 121). This definition does not account for 80-85% of the vulnerability reports that we receive and pass on to our DoD stakeholders. These vulnerabilities range from improper information disclosures to a plethora of web-based attacks as well as the all to often reported system or process misconfigurations which leave our customers vulnerable (our reporters provide proof-of-concept attacks which we verify). Roughly 15-20 percent of our reporting involves CVE-based software vulnerabilities. Additionally, the lengthy timeframe for software vulnerability discovery, responsible coordination and disclosure, and the time for a vendor to release a patch the vulnerability ensures that CVEs will arrive at the end of the vulnerability management process. Most of our reports are able to be mitigated within 7-45 days, depending on criticality. The STIX definition differs considerably from the DoD VDP Program's definition, which states: Vulnerability: "a weakness in an information system, including in its system security procedures, internal controls, requirements, design, or implementation, that could be exploited or triggered by a threat source." This definition is considerably broader than the 'software only' (CVE-based) definitions currently in the STIX 2.0/2.1 Draft descriptions. My team back at the Software Engineering Institute (CERT/CC) developed the DoD VDP definition based on NIST guidance from the following sources: Most of those words come from: NIST SP 800-37 Rev. 1 under Vulnerability (CNSSI 4009) FIPS 200 under VULNERABILITY (CNSSI 4009 - Adapted) NIST SP 800-128 under Vulnerability (CNSSI 4009 - Adapted) NIST SP 800-137 under Vulnerability (CNSSI 4009) NIST SP 800-161 under Vulnerability (NIST SP 800-53 Rev. 4, FIPS 200, NIST SP 800-53A Rev. 4) NIST SP 800-18 Rev. 1 under Vulnerability (CNSSI 4009 - Adapted) NIST SP 800-53 Rev. 4 under Vulnerability (CNSSI 4009) NIST SP 800-53A Rev. 4 under Vulnerability (CNSSI 4009) NIST SP 800-60 Vol. 1 Rev. 1 under Vulnerability (CNSSI 4009 - Adapted) NIST SP 800-60 Vol. 2 Rev. 1 under Vulnerability (CNSSI 4009 - Adapted) NIST SP 800-82 Rev. 2 under Vulnerability (NIST SP 800-53) NISTIR 7621 Rev. 1 under Vulnerability (NIST SP 800-53 Rev. 4) NISTIR 7622 under Vulnerability (FIPS 200, NIST SP 800-115, NIST SP 800-37, NIST SP 800-53A, NIST SP 800-60, NIST SP 800-53) "design" from NIST SP 800-47 under Vulnerability NIST SP 800-33 NIST SP 800-28 Version 2 under Vulnerability NIST SP 800-27 Rev. A [Withdrawn] NISTIR 4734 under Vulnerability NISTIR 7316 under Vulnerability "requirements" from NIST SP 800-27 Rev. A [Withdrawn] We in the DoD VDP Program also use NIST SP800-30, which aligns well with the other NIST publications on this list as well. As you can see, our definition defines a vulnerability as 'a weakness'--which names vulnerability as a discrete type of entity and not an activity that occurs to some other entity. The definition we use allows us to identify and codify not just incident response (post-exploit) data like the CVE-based definitions do, but to use our VDP reporting which identifies pre-exploit data. We have demonstrated that using vulnerability data from our reporting can allow us to alert vulnerable asset owners and assist them to mitigate the vulnerability BEFORE the asset is exploited. Our goal is to be able to use our reporting to inoculate other stakeholders before they become a victim. However, unless the STIX definition is 're-visioned' our ability to communicate the vulnerability is severely limited. Yes, we can strap it onto the existing 'external report' socket in STIX 2.x, but the underlying misalignment in definitions means that it will be much harder to efficiently communicate the actual threat. I would be glad to discuss this further. Thanks. Chuck Chuck Yarbrough DoD Vulnerability Disclosure Program (DVDP) Department of Defense Cyber Crime Center (DC3) Linthicum, MD 21090 (410) 694-2803 Charles.yarbrough.ctr@dc3.mil (Unclass) Charles.yarbrough.ctr@dc3.smil.mil (Secret)
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]