Re: [cti-comment] Vulnerability as an object

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

You seem to be wanting
to bucket weakness and Vulnerabilities into one thing, and link them both
under the Vulnerability object. 

In my opinion,
vulnerabilities and Weaknesses are not the same thing, and should not be
confused - there are entire industry verticals in each of these. This is
even more important in today's world where there are whole enormous classes
of weaknesses that can be commonly observed in cloud architectures that
do not require any exploitation of actual vulnerabilities - which is why
cloud security posture management is now a vertical.

If there is a
desire to add Weakness as a top level SDO alongside Vulnerability, that
is what we should be looking at (and I would support that) - but please
lets not water down the meaning of Vulnerability to encompass every single
thing that can lead to a successful exploit. Being able to easily differentiate
between weaknesses and vulnerabilities is very important for intelligence
gathering, metrics and measurement.

-
Jason Keirstead
Chief Architect - IBM Security Threat Management
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple,
really. Double your rate of failure."

- Thomas J. Watson



From:
       "Yarbrough,
Charles CTR DC3/VDP" <Charles.Yarbrough.ctr@dc3.mil>
To:
       "cti-comment@lists.oasis-open.org"
<cti-comment@lists.oasis-open.org>
Cc:
       "'cgyarbrough@cert.org'"
<cgyarbrough@cert.org>, "Johnson, Kristopher CIV DC3/VDP"
<Kristopher.Johnson@dc3.mil>, "Mates, Jeffrey CIV DC3/TSD"
<Jeffrey.Mates@dc3.mil>
Date:
       09/12/2019
05:08 PM
Subject:
       [EXTERNAL]
[cti-comment] Vulnerability as an object
Sent
by:        <cti-comment@lists.oasis-open.org>

---

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)