Good afternoon!
With the release of the Top25 and CWE v4.8, I wanted to pick this thread up
from where we got it a month or so ago. As a refresher, the User Experience
Working Group (UEWG) agreed on these definitions as updates to what are
currently in the CWE and CAPEC glossaries for these terms:
Vulnerability
A flaw in a software, firmware, hardware, or service component resulting from a
weakness that can be exploited, causing a negative impact to the
confidentiality, integrity, or availability of an impacted component or
components
Weakness
A type of mistake made during the implementation, design, or other phases of a
product lifecycle that, under the right conditions, could contribute to the
introduction of vulnerabilities in a range of products made by different
vendors.
Attack Pattern
The common approach and attributes related to the exploitation of a known
weakness type, usually in cyber-enabled capabilities
One thing is that this “definitions harmonization” effort started as an effort
to align definitions across the CWE and CAPEC sites which don’t agree on
“weakness” and “attack pattern” definitions… surprising, no?
CVE’s definition for ‘vulnerability’ was agreed upon after significant
community deliberation, and I am hesitant to open that up for further edit at
this time.
For that reason, I propose CWE and CAPEC adopt the current CVE definition for
‘vulnerability’, and work to harmonize the ‘weakness’ and ‘attack pattern’
definitions on the sites.
1. I believe that Jeremy’s definition for weakness focuses too much on the
absence of a safeguard/control versus a mistake/error. This has come up in
previous scoping conversations for CWE, where its not always the case that the
‘absence of a mitigation’ warrants a new weakness type
2. I appreciate Alex’s set-theory type definition scheme and I think the
definitions mostly. For weakness, however, while the UEWG agrees on the ‘XXX
that could become a vulnerability’, I think the added detail in the table above
is helpful. The connection between attack patterns and weakness types is
present in both our definitions as well.
I think we could certainly debate these definitions till the proverbial cows
come home. I propose using the CWE- and CAPEC-research email listservs for
further community comment. I’d like to establish a timeline (say Friday, July
29?) for accepting feedback, after which we can formally the terms in the CWE
and CAPEC glossaries.
Are there any objections to this course of action? If not, I will send out
notes to the listservs by midweek.
Cheers,
Alec
--
Alec J. Summers
Center for Securing the Homeland (CSH)
Cyber Security Engineer, Principal
Group Lead, Cybersecurity Operations and Integration
––––––––––––––––––––––––––––––––––––
MITRE - Solving Problems for a Safer World™
From: Fung, Jason M <jason.m.f...@intel.com>
Date: Tuesday, May 31, 2022 at 1:33 PM
To: Hoole, Alexander <alexander.ho...@microfocus.com>, jw...@redhat.com
<jw...@redhat.com>, Seifried, Kurt <k...@seifried.org>
Cc: Alec J Summers <asumm...@mitre.org>, CWE CAPEC Board
<cwe-capec-board-list@mitre.org>
Subject: RE: [EXT] RE: Glossary
Love the definitions!
The only part to nitpick is this phrase “vulnerability is a property of …” I
am not sure if vulnerability is commonly perceived as a “property”. E.g., the
following sentence does not read as smoothly if vulnerability is replaced with
property
“In December of 2021, a new vulnerability (property) has been identified within
…”
I associate vulnerability as an exploitable bug that takes advantage of 1 or
more weaknesses.
- Jason
From: Alexander Hoole <alexander.ho...@microfocus.com>
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West <jw...@redhat.com>; Kurt Seifried <k...@seifried.org>
Cc: Alec J Summers <asumm...@mitre.org>; CWE CAPEC Board
<cwe-capec-board-list@mitre.org>
Subject: [EXT] RE: Glossary
Good afternoon/evening Everyone,
Please consider the following points:
1. I agree with Jason O. that the terms are a stepping stone to
understanding how these concepts play out in the real world. However, a
slightly different perspective is the following (without defining all of the
base terms):
* A bug is an instance of a flaw/fault/error/defect in the design,
development/implementation, or operation of a system.
* A weaknesses is a bug that could (i.e., may, or may not) lead to a
vulnerability. Weakness types define logical groupings of bugs which share
similar properties (e.g., Buffer Overflow).
* A vulnerability is a property of system requirements, design,
implementation, or operation that can be accidentally or intentionally
exploited (resulting in a security failure). A vulnerability is made possible
due to the presence of one or more underlying weaknesses.
* An exploit successfully results in a security failure through one or
more vulnerabilities which does exploit underlying weaknesses.
* An attack is an attempt to exploit one or more vulnerabilities that
could lead to an exploit. Attack patterns define logical groupings of attacks
which share similar properties and approaches related to underlying weakness
types.
Note: the distinction between can and could is a comparison of probability.
Can is likely to occur. Could is less likely to occur.
1. Regarding the Red Hat definition, if we want to be consistent with other
standards and best practices, we should probably use the term “control” rather
than “safeguard” (e.g., NIST SP 800-53 Rev. 5).
To test the observations, we should be able to apply the terms to descript
actual occurrences in the context we are trying to represent. For example,
consider the following:
“In December of 2021, a new vulnerability has been identified within Log4J
under the common name Log4Shell
(CVE-2021-44228<https://nvd.nist.gov/vuln/detail/CVE-2021-44228>). This
vulnerability affects version 2.0-beta9 through 2.15.0 (excluding security
releases 2.12.2, 2.12.3, and 2.3.1). Specifically, CVE-2021-44228 is caused by
an underlying JNDI Injection and LDAP Entry Poisoning weaknesses which exists
in the affected versions. To date, multiple exploits have been recorded across
the industry where attacks targeting CVE-2021-44228 have been observed (e.g.,
VMWare<https://www.bleepingcomputer.com/news/security/lazarus-hackers-target-vmware-servers-with-log4shell-exploits/>,
…).
Thoughts?
Best,
-A
From: Jeremy West <jw...@redhat.com>
Sent: Tuesday, May 24, 2022 2:03 PM
To: Kurt Seifried <k...@seifried.org>
Cc: Alec J Summers <asumm...@mitre.org>; CWE CAPEC Board
<cwe-capec-board-list@mitre.org>
Subject: Re: Glossary
Correct Kurt. Process is defined here as an executing process on the stack.
On Tue, May 24, 2022 at 5:01 PM Kurt Seifried
<k...@seifried.org<mailto:k...@seifried.org>> wrote:
"process" means executing process, or like a business process, e.g. password
reset policy?
On Tue, May 24, 2022 at 2:15 PM Jeremy West
<jw...@redhat.com<mailto:jw...@redhat.com>> wrote:
Red Hat adopted the following definition of a weakness a year or so ago. "A
weakness is specifically the absence of a safeguard in an asset or process that
provides a higher potential or frequency of a threat occurring, but does not
meet the exploitability criteria for a vulnerability." We've also defined
vulnerability much more broadly to include weaknesses as a subset "A weakness
or absence of a safeguard in an asset that provides a higher potential or
frequency of a threat occurring." We were running into differing opinions when
we looked at each as separate and unique. The other factor we've called out
internally is hardening. The key difference between a weakness and hardening
for us is that a weakness is a direct factor in the potential and frequency vs
hardening which are safeguards which prevent.
On Tue, May 24, 2022 at 12:49 PM Alec J Summers
<asumm...@mitre.org<mailto:asumm...@mitre.org>> wrote:
Dear CWE/CAPEC Board Members,
Good afternoon! I hope the week is going well for you all.
During a recent CWE/CAPEC User Experience Working Group session, the topic of
definitions came up – more specifically, the difficulty in agreeing on good
ones and making sure they are understood by downstream users. It also reminded
me of Pietro’s comment during our February meeting, I believe, on the
importance of harmonious definitions for similar terms across the CVE and
CWE/CAPEC sites. To that end, the team went ahead and did a quick document
authorities search of our key terminology to start (i.e., vulnerability,
weakness, attack pattern), and suggested the following:
Term
Definition
Authority
Authorities Doc
Vulnerability
A flaw in a software, firmware, hardware, or service component resulting from a
weakness that can be exploited, causing a negative impact to the
confidentiality, integrity, or availability of an impacted component or
components. (not changed)
CVE
website
Weakness
A type of mistake made during the implementation, design, or other phases of a
product lifecycle that, under the right conditions, could contribute to the
introduction of vulnerabilities in a range of products made by different
vendors.
n/a
edited from def on CWE wesbite
Attack Pattern
The common approach and attributes related to the exploitation of a known
weakness type, usually in cyber-enabled capabilities
n/a
edited from def on CAPEC website
The full spreadsheet of definitions to compare is attached. The plan would be
to unify the definitions according to the above across all our sites. Would
love to hear your thoughts.
Cheers,
Alec
--
Alec J. Summers
Center for Securing the Homeland (CSH)
Cyber Security Engineer, Principal
Group Lead, Cybersecurity Operations and Integration
––––––––––––––––––––––––––––––––––––
MITRE - Solving Problems for a Safer World™
--
Jeremy West
Red Hat Product Security
Red Hat Massachusetts<https://www.redhat.com>
314 Littleton Rd
jw...@redhat.com<mailto:jw...@redhat.com>
M: 9192686967<tel:9192686967> IM: hobbit
<https://red.ht/sig>
<https://red.ht/sig>
-- <https://red.ht/sig>
Kurt Seifried (He/Him)
k...@seifried.org<https://red.ht/sig>
<https://red.ht/sig>
-- <https://red.ht/sig>
Jeremy West<https://red.ht/sig>
Red Hat Product Security<https://red.ht/sig>
Red Hat Massachusetts <https://red.ht/sig>
314 Littleton Rd<https://red.ht/sig>
jw...@redhat.com
M: 9192686967 IM: hobbit <https://red.ht/sig>
[Image removed by sender.]<https://red.ht/sig>
<https://red.ht/sig>
