Re: CWE/CAPEC definitions update

[Kurt Seifried]

Should we also acknowledge regulated industries/law, e.g.

causing a negative impact to the confidentiality, integrity, or
availability of an impacted component or components, and/or violating a
given security policy/law/regulation that applies to the affected entity.

On Mon, Sep 12, 2022 at 1:55 PM Alec J Summers  wrote:

> Dear CWE/CAPEC Community,
>
>
>
> Earlier this summer I emailed you regarding the CWE/CAPEC User Experience
> Working Group’s efforts to harmonize the definitions of some key
> terminology across our sites. As CWE and CAPEC were developed separately
> and on a different timeline, some of the terms are not similarly defined,
> and we want to address that.
>
>
>
> Thank you for your thoughtful and considered feedback to my first request
> for comment on this topic. We received the most feedback on the definition
> of “weakness”. The UEWG and the CWE/CAPEC team has used that in our
> development of a new definition:
>
>
>
> *Weakness*: *A condition in a software, firmware, hardware, or service
> component that, under the right circumstances, could contribute to the
> introduction of vulnerabilities*
>
>
>
> If adopted, this would be accompanied by the following two definitions for
> ‘attack pattern’ and ‘vulnerability’, respectively.
>
>
>
> *Attack Pattern: **The common approach and attributes related to the
> exploitation of a weakness, usually in cyber-enabled capabilities*
>
>
>
> *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. *(from CVE® and not in consideration
> for modification)
>
>
>
> We are eager to hear your thoughts, and we look forward to formalizing
> this change on our sites soon.
>
>
>
> 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™*
>
>
>
>
>


-- 
Kurt Seifried (He/Him)
k...@seifried.org

Re: CWE/CAPEC Definitions

[Kurt Seifried]

There's another aspect: legislated vulnerabilities/weaknesses.

E.g. https://www.enforcementtracker.com/ there are lots of examples, e.g.:

https://www.enforcementtracker.com/ETid-1091

Emailing data in an unencrypted format, now ignoring the fact it may well
have been encrypted in transit, I assume they want end to end encryption,
now we have CWE-311: Missing Encryption of Sensitive Data but for example,
there is no distinction between encryption of data end to end, in transit
between email systems/over the Internet, etc.

So while you specifically may not care, GDPR cares, and it's clear (if you
search the fines database) that this is a pretty common failure scenario,
for for example, I would suggest we start breaking up protection mechanisms
between end to end and all the other possibilities where applicable.




On Fri, Jul 15, 2022 at 8:22 AM Rob Wissmann 
wrote:

> Kurt Seifried’s point is very interesting because it makes clear that the
> shift in classification from “perfectly acceptable feature” to “flaw and
> weakness” to “vulnerability” is a based on the perspective of the observer.
>
>
>
> Said another way, “flaw”, “weakness” and “vulnerability” are subjective
> classifications not objective classifications. An objectivist point of view
> would say, “an exploit for a flaw either can exist or cannot, therefore it
> is objectively knowable whether a flaw is a vulnerability.” This point of
> view precludes saying a flaw *might* be exploitable but we don’t know
> yet, obviating the need for the term weakness.
>
>
>
> Consider the question “Is this buffer overflow a vulnerability?” The
> objectivist perspective requires abstaining from an answer until the issue
> can be proved one way or another. To answer “maybe” is to classify that
> buffer overflow as a weakness, which it cannot be since an exploit either
> can exist or cannot. The objectivist take on vulnerability is not very
> useful definition to most of us because it’s usually impossible or at least
> impractical for any observer to have the perfect knowledge it requires.
> Considering Kurt’s point, that perfect knowledge might even have to extend
> into the future! Further, when the cost of a full investigation into a flaw
> is high and mitigation costs are low or risk aversion is high, there is
> value in answering “maybe.” That’s why the term “weakness” exists.
>
>
>
> The definitions of weakness and vulnerability should explicitly consider
> the observer’s frame of reference to clear up that these terms are to be
> used subjectively.
>
>
>
> Vulnerability: A flaw … accepted by the observer, their community, or the
> public to be exploitable …
>
> Weakness: A flaw … not accepted by the observer, their community, or the
> public to be exploitable but accepted to be potentially exploitable …
>
>
>
> Circling back, the term flaw is subjective as well – today’s features may
> come to be regarded as tomorrows flaws – which is a little bit of an issue
> with the vulnerability and weakness definitions. But these versions of the
> definitions do a good job implying what is meant by flaw: features that are
> accepted to be exploitable or potentially exploitable. It also helps
> protect from the “changes with time” issue since what is accepted to be
> exploitable or potentially so necessarily changes with time.
>
>
>
> Thanks
>
>
>
> *From:* Kurt Seifried 
> *Sent:* Thursday, July 14, 2022 2:45 PM
> *To:* Hatfield, Arthur 
> *Cc:* SJ Jazz ; Rob Wissmann <
> rob.wissm...@nteligen.com>; Alec J Summers ; CWE
> Research Discussion 
> *Subject:* Re: CWE/CAPEC Definitions
>
>
>
> There’s also changes in standards, expectations and so on. 20 years ago
> 2FA was exotic, now it’s common place and in 20 more years I bet lack of
> 2FA is classed as a vulnerability.
>
>
>
> -Kurt
>
>
>
>
>
>
>
>
>
>
>
> On Jul 14, 2022, at 11:25 AM, Hatfield, Arthur <
> arthur_hatfi...@homedepot.com> wrote:
>
> 
>
> I think it may be best to split the difference by describing weaknesses as
> flaws that are *potentially* exploitable to cause undesired operation of
> the system and describing vulnerabilities as the subset of weaknesses that
> are *provably* exploitable; that allows the possibility that some
> exploits are either extant but not generally known to exist, or would exist
> if someone applied themselves to finding an exploit technique.
>
>
>
>
>
> *RT Hatfield**, BS CS, CCITP, CISSP*
>
> Staff Cybersecurity Analyst
>
> Lead, Notifications and Operations Service Line
>
> Cyber Threat Intelligence
>
> *The Home Depot*
>
>
>
>
>
>
>
> *From: *SJ Jazz 
> *Date: *Thursday, July 14, 2022 at 1:13 

RE: CWE/CAPEC Definitions

[Rob Wissmann]

Kurt Seifried’s point is very interesting because it makes clear that the shift 
in classification from “perfectly acceptable feature” to “flaw and weakness” to 
“vulnerability” is a based on the perspective of the observer.

Said another way, “flaw”, “weakness” and “vulnerability” are subjective 
classifications not objective classifications. An objectivist point of view 
would say, “an exploit for a flaw either can exist or cannot, therefore it is 
objectively knowable whether a flaw is a vulnerability.” This point of view 
precludes saying a flaw might be exploitable but we don’t know yet, obviating 
the need for the term weakness.

Consider the question “Is this buffer overflow a vulnerability?” The 
objectivist perspective requires abstaining from an answer until the issue can 
be proved one way or another. To answer “maybe” is to classify that buffer 
overflow as a weakness, which it cannot be since an exploit either can exist or 
cannot. The objectivist take on vulnerability is not very useful definition to 
most of us because it’s usually impossible or at least impractical for any 
observer to have the perfect knowledge it requires. Considering Kurt’s point, 
that perfect knowledge might even have to extend into the future! Further, when 
the cost of a full investigation into a flaw is high and mitigation costs are 
low or risk aversion is high, there is value in answering “maybe.” That’s why 
the term “weakness” exists.

The definitions of weakness and vulnerability should explicitly consider the 
observer’s frame of reference to clear up that these terms are to be used 
subjectively.

Vulnerability: A flaw … accepted by the observer, their community, or the 
public to be exploitable …
Weakness: A flaw … not accepted by the observer, their community, or the public 
to be exploitable but accepted to be potentially exploitable …

Circling back, the term flaw is subjective as well – today’s features may come 
to be regarded as tomorrows flaws – which is a little bit of an issue with the 
vulnerability and weakness definitions. But these versions of the definitions 
do a good job implying what is meant by flaw: features that are accepted to be 
exploitable or potentially exploitable. It also helps protect from the “changes 
with time” issue since what is accepted to be exploitable or potentially so 
necessarily changes with time.

Thanks

From: Kurt Seifried 
Sent: Thursday, July 14, 2022 2:45 PM
To: Hatfield, Arthur 
Cc: SJ Jazz ; Rob Wissmann ; 
Alec J Summers ; CWE Research Discussion 

Subject: Re: CWE/CAPEC Definitions

There’s also changes in standards, expectations and so on. 20 years ago 2FA was 
exotic, now it’s common place and in 20 more years I bet lack of 2FA is classed 
as a vulnerability.

-Kurt






On Jul 14, 2022, at 11:25 AM, Hatfield, Arthur 
mailto:arthur_hatfi...@homedepot.com>> wrote:

I think it may be best to split the difference by describing weaknesses as 
flaws that are potentially exploitable to cause undesired operation of the 
system and describing vulnerabilities as the subset of weaknesses that are 
provably exploitable; that allows the possibility that some exploits are either 
extant but not generally known to exist, or would exist if someone applied 
themselves to finding an exploit technique.


RT Hatfield, BS CS, CCITP, CISSP
Staff Cybersecurity Analyst
Lead, Notifications and Operations Service Line
Cyber Threat Intelligence
The Home Depot



From: SJ Jazz mailto:sjoeja...@gmail.com>>
Date: Thursday, July 14, 2022 at 1:13 PM
To: Rob Wissmann mailto:rob.wissm...@nteligen.com>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>, CWE 
Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: [EXTERNAL] Re: CWE/CAPEC Definitions
Actually, being listed as a CVE is not the criteria for being a vulnerability.  
Only vulnerabilities catalogued as CVEs are 'known vulnerabilities'. There are 
actual instances of uncatalogued (unpublished) vulnerabilities; some are in 
proprietary or intelligence organization's libraries, and some are held by 
malicious actors for future exploitation (at which point they will be known as 
zero-day vulnerabilities).

It is the existence of an exploit designed to take advantage of a weakness (or 
multiple weaknesses) and achieve a negative technical impact that makes a 
weakness a vulnerability.

It is not the state of being publicly known or catalogued that makes it a 
vulnerability.

...Joe



On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
mailto:rob.wissm...@nteligen.com>> wrote:
Regarding the circular definitions, it has always struck me that weaknesses are 
flaws that may or may not be exploitable to cause negative impact whereas 
vulnerabilities are flaws known to be exploitable to cause negative impact.

A rewrite of the definitions to match this concept:

Vulnerability
A flaw in a software, firmware, hardware, or service component known to be 
exploitable to cause a negative impa

RE: CWE/CAPEC Definitions

[Steven M Christey]

We’ve already seen this recently with the re-evaluation of CWEs related to 
password complexity and other password-related policies. Last year, some of our 
cryptography entries were modified to better allow for the fact that something 
that’s safe today might not be tomorrow.

- Steve


From: Kurt Seifried 
Sent: Thursday, July 14, 2022 2:45 PM
To: Hatfield, Arthur 
Cc: Jarzombek, Joe ; Wissmann, Rob 
; Alec J Summers ; CWE Research 
Discussion 
Subject: Re: CWE/CAPEC Definitions

There’s also changes in standards, expectations and so on. 20 years ago 2FA was 
exotic, now it’s common place and in 20 more years I bet lack of 2FA is classed 
as a vulnerability.

-Kurt






On Jul 14, 2022, at 11:25 AM, Hatfield, Arthur 
mailto:arthur_hatfi...@homedepot.com>> wrote:

I think it may be best to split the difference by describing weaknesses as 
flaws that are potentially exploitable to cause undesired operation of the 
system and describing vulnerabilities as the subset of weaknesses that are 
provably exploitable; that allows the possibility that some exploits are either 
extant but not generally known to exist, or would exist if someone applied 
themselves to finding an exploit technique.


RT Hatfield, BS CS, CCITP, CISSP
Staff Cybersecurity Analyst
Lead, Notifications and Operations Service Line
Cyber Threat Intelligence
The Home Depot



From: SJ Jazz mailto:sjoeja...@gmail.com>>
Date: Thursday, July 14, 2022 at 1:13 PM
To: Rob Wissmann mailto:rob.wissm...@nteligen.com>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>, CWE 
Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: [EXTERNAL] Re: CWE/CAPEC Definitions
Actually, being listed as a CVE is not the criteria for being a vulnerability.  
Only vulnerabilities catalogued as CVEs are 'known vulnerabilities'. There are 
actual instances of uncatalogued (unpublished) vulnerabilities; some are in 
proprietary or intelligence organization's libraries, and some are held by 
malicious actors for future exploitation (at which point they will be known as 
zero-day vulnerabilities).

It is the existence of an exploit designed to take advantage of a weakness (or 
multiple weaknesses) and achieve a negative technical impact that makes a 
weakness a vulnerability.

It is not the state of being publicly known or catalogued that makes it a 
vulnerability.

...Joe



On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
mailto:rob.wissm...@nteligen.com>> wrote:
Regarding the circular definitions, it has always struck me that weaknesses are 
flaws that may or may not be exploitable to cause negative impact whereas 
vulnerabilities are flaws known to be exploitable to cause negative impact.

A rewrite of the definitions to match this concept:

Vulnerability
A flaw in a software, firmware, hardware, or service component known to be 
exploitable to cause a negative impact to the confidentiality, integrity, or 
availability of an impacted component or components (from CVE®)
Weakness
A flaw in a software, firmware, hardware, or service component that may or may 
not be exploitable to cause a negative impact to the confidentiality, 
integrity, or availability of an impacted component or components.

Vulnerabilities must be known to be exploitable because of the CVE criteria 
[cve.org]<https://www.google.com/url?q=https://urldefense.com/v3/__https:/www.cve.org/About/Process*CVERecordLifecycle__;Iw!!M-nmYVHPHQ!NfnLPvDdkiRWH3L2xvMa9KYle-CdclOb75YztG_5ExXRad3d_EIacRd2LMB8bBeLbczXRpgZviQ46Vn0fy3hmNg21w$=gmail-imap=165842433600=AOvVaw2SeZfZHtLqix20ioUiz44s>:
 “Details include but are not limited to affected product(s); affected or fixed 
product versions; vulnerability type, root cause, or impact; and at least one 
public reference.”

An example of a flaw that may or may not be a vulnerability is an integer 
overflow. It might result in a vulnerability, or it might not. That’s a 
weakness.

Thanks

From: Alec J Summers mailto:asumm...@mitre.org>>
Sent: Wednesday, July 13, 2022 1:09 PM
To: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)
Weakness
A type of flaw or 

Re: CWE/CAPEC Definitions

[David A. Wheeler]

> On Jul 14, 2022, at 1:47 PM, SJ Jazz  wrote:
> 
> Vulnerability = weakeness + exploit
> Or more specifically,
> Vulnerability = weakeness(es) + known exploit

I believe the first one is the right one. that is, vulnerabilities = weakness + 
exploit exists.

If vulnerabilities are only known vulnerabilities, then you can't discover 
vulnerabilities. It would mean the mere act of looking creates vulnerabilities.

--- David A. Wheeler

Re: CWE/CAPEC Definitions

[SJ Jazz]

Vulnerability = weakeness + exploit
Or more specifically,
Vulnerability = weakeness(es) + known exploit

...Joe

On Thu, Jul 14, 2022, 12:17 Hatfield, Arthur 
wrote:

> I think it may be best to split the difference by describing weaknesses as
> flaws that are *potentially* exploitable to cause undesired operation of
> the system and describing vulnerabilities as the subset of weaknesses that
> are *provably* exploitable; that allows the possibility that some
> exploits are either extant but not generally known to exist, or would exist
> if someone applied themselves to finding an exploit technique.
>
>
>
>
>
> *RT Hatfield**, BS CS, CCITP, CISSP*
>
> Staff Cybersecurity Analyst
>
> Lead, Notifications and Operations Service Line
>
> Cyber Threat Intelligence
>
> *The Home Depot*
>
>
>
>
>
>
>
> *From: *SJ Jazz 
> *Date: *Thursday, July 14, 2022 at 1:13 PM
> *To: *Rob Wissmann 
> *Cc: *Alec J Summers , CWE Research Discussion <
> cwe-research-list@mitre.org>
> *Subject: *[EXTERNAL] Re: CWE/CAPEC Definitions
>
> Actually, being listed as a CVE is not the criteria for being a
> vulnerability.  Only vulnerabilities catalogued as CVEs are 'known
> vulnerabilities'. There are actual instances of uncatalogued (unpublished)
> vulnerabilities; some are in proprietary or intelligence organization's
> libraries, and some are held by malicious actors for future exploitation
> (at which point they will be known as zero-day vulnerabilities).
>
>
>
> It is the existence of an exploit designed to take advantage of a weakness
> (or multiple weaknesses) and achieve a negative technical impact that makes
> a weakness a vulnerability.
>
>
>
> It is not the state of being publicly known or catalogued that makes it a
> vulnerability.
>
>
>
> ...Joe
>
>
>
>
>
>
>
> On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
> wrote:
>
> Regarding the circular definitions, it has always struck me that
> weaknesses are flaws that *may or may not* be exploitable to cause
> negative impact whereas vulnerabilities are flaws *known* to be
> exploitable to cause negative impact.
>
>
>
> A rewrite of the definitions to match this concept:
>
>
>
> *Vulnerability*
>
> *A flaw in a software, firmware, hardware, or service component known to
> be exploitable to cause a negative impact to the confidentiality,
> integrity, or availability of an impacted component or components (from
> CVE®)*
>
> *Weakness*
>
> *A flaw in a software, firmware, hardware, or service component that may
> or may not be exploitable to cause a negative impact to the
> confidentiality, integrity, or availability of an impacted component or
> components.*
>
>
>
> Vulnerabilities must be known to be exploitable because of the CVE
> criteria [cve.org]
> <https://urldefense.com/v3/__https:/www.cve.org/About/Process*CVERecordLifecycle__;Iw!!M-nmYVHPHQ!NfnLPvDdkiRWH3L2xvMa9KYle-CdclOb75YztG_5ExXRad3d_EIacRd2LMB8bBeLbczXRpgZviQ46Vn0fy3hmNg21w$>:
> “Details include but are not limited to affected product(s); affected or
> fixed product versions; vulnerability type, root cause, or impact; and at
> least one public reference.”
>
>
>
> An example of a flaw that may or may not be a vulnerability is an integer
> overflow. It might result in a vulnerability, or it might not. That’s a
> weakness.
>
>
>
> Thanks
>
>
>
> *From:* Alec J Summers 
> *Sent:* Wednesday, July 13, 2022 1:09 PM
> *To:* CWE Research Discussion 
> *Subject:* CWE/CAPEC Definitions
>
>
>
> Dear CWE Research Community,
>
>
>
> I hope this email finds you well.
>
>
>
> Over the past few months, the CWE/CAPEC User Experience Working Group has
> been working to modernize our programs through a variety of activities. One
> such activity is harmonizing the definitions on our sites for some of our
> key terminology including weakness, vulnerability, and attack pattern. As
> CWE and CAPEC were developed separately and on a different timeline, some
> of the terms are not defined similarly, and we want to address that.
>
>
>
> We are seeking feedback on our working definitions:
>
>
>
> *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 (from CVE®)*
>
> *Weakness*
>
> *A type of flaw or defect inserted during a product lifecycle that, under
> the right conditions, could contribute to the introduction of
> vulnerabilities in a range of products made by different vendors*
>

Re: CWE/CAPEC Definitions

[Hatfield, Arthur]

I think it may be best to split the difference by describing weaknesses as 
flaws that are potentially exploitable to cause undesired operation of the 
system and describing vulnerabilities as the subset of weaknesses that are 
provably exploitable; that allows the possibility that some exploits are either 
extant but not generally known to exist, or would exist if someone applied 
themselves to finding an exploit technique.


RT Hatfield, BS CS, CCITP, CISSP
Staff Cybersecurity Analyst
Lead, Notifications and Operations Service Line
Cyber Threat Intelligence
The Home Depot



From: SJ Jazz 
Date: Thursday, July 14, 2022 at 1:13 PM
To: Rob Wissmann 
Cc: Alec J Summers , CWE Research Discussion 

Subject: [EXTERNAL] Re: CWE/CAPEC Definitions
Actually, being listed as a CVE is not the criteria for being a vulnerability.  
Only vulnerabilities catalogued as CVEs are 'known vulnerabilities'. There are 
actual instances of uncatalogued (unpublished) vulnerabilities; some are in 
proprietary or intelligence organization's libraries, and some are held by 
malicious actors for future exploitation (at which point they will be known as 
zero-day vulnerabilities).

It is the existence of an exploit designed to take advantage of a weakness (or 
multiple weaknesses) and achieve a negative technical impact that makes a 
weakness a vulnerability.

It is not the state of being publicly known or catalogued that makes it a 
vulnerability.

...Joe



On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
mailto:rob.wissm...@nteligen.com>> wrote:
Regarding the circular definitions, it has always struck me that weaknesses are 
flaws that may or may not be exploitable to cause negative impact whereas 
vulnerabilities are flaws known to be exploitable to cause negative impact.

A rewrite of the definitions to match this concept:

Vulnerability
A flaw in a software, firmware, hardware, or service component known to be 
exploitable to cause a negative impact to the confidentiality, integrity, or 
availability of an impacted component or components (from CVE®)
Weakness
A flaw in a software, firmware, hardware, or service component that may or may 
not be exploitable to cause a negative impact to the confidentiality, 
integrity, or availability of an impacted component or components.

Vulnerabilities must be known to be exploitable because of the CVE criteria 
[cve.org]<https://urldefense.com/v3/__https:/www.cve.org/About/Process*CVERecordLifecycle__;Iw!!M-nmYVHPHQ!NfnLPvDdkiRWH3L2xvMa9KYle-CdclOb75YztG_5ExXRad3d_EIacRd2LMB8bBeLbczXRpgZviQ46Vn0fy3hmNg21w$>:
 “Details include but are not limited to affected product(s); affected or fixed 
product versions; vulnerability type, root cause, or impact; and at least one 
public reference.”

An example of a flaw that may or may not be a vulnerability is an integer 
overflow. It might result in a vulnerability, or it might not. That’s a 
weakness.

Thanks

From: Alec J Summers mailto:asumm...@mitre.org>>
Sent: Wednesday, July 13, 2022 1:09 PM
To: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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™




--
Regards,

Joe

Joe Jarzombek
C 703 627-4644


INTERNAL USE

Re: CWE/CAPEC Definitions

[Hatfield, Arthur]

It’s still a vulnerability, in my opinion, even if it’s not actually known yet. 
I think it makes most sense to assume identified weaknesses in a particular 
system are vulnerabilities until proved otherwise – either by referring to a 
specific control designed (and proven) to prevent that weakness from being 
exploitable, or by demonstrating via a logical proof that a would-be exploiter 
cannot actually “get to” the weakness to exploit it, or the like.


RT Hatfield, BS CS, CCITP, CISSP
Staff Cybersecurity Analyst
Lead, Notifications and Operations Service Line
Cyber Threat Intelligence
The Home Depot



From: Rob Wissmann 
Date: Thursday, July 14, 2022 at 1:16 PM
To: SJ Jazz 
Cc: Alec J Summers , CWE Research Discussion 

Subject: [EXTERNAL] RE: CWE/CAPEC Definitions
Putting “known” in there still works. It doesn’t say publicly known, and known 
ability to be exploited for negative impact is still the distinction between 
weakness and vulnerability.

From: SJ Jazz 
Sent: Thursday, July 14, 2022 1:13 PM
To: Rob Wissmann 
Cc: Alec J Summers ; CWE Research Discussion 

Subject: Re: CWE/CAPEC Definitions

Actually, being listed as a CVE is not the criteria for being a vulnerability.  
Only vulnerabilities catalogued as CVEs are 'known vulnerabilities'. There are 
actual instances of uncatalogued (unpublished) vulnerabilities; some are in 
proprietary or intelligence organization's libraries, and some are held by 
malicious actors for future exploitation (at which point they will be known as 
zero-day vulnerabilities).

It is the existence of an exploit designed to take advantage of a weakness (or 
multiple weaknesses) and achieve a negative technical impact that makes a 
weakness a vulnerability.

It is not the state of being publicly known or catalogued that makes it a 
vulnerability.

...Joe



On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
mailto:rob.wissm...@nteligen.com>> wrote:
Regarding the circular definitions, it has always struck me that weaknesses are 
flaws that may or may not be exploitable to cause negative impact whereas 
vulnerabilities are flaws known to be exploitable to cause negative impact.

A rewrite of the definitions to match this concept:

Vulnerability
A flaw in a software, firmware, hardware, or service component known to be 
exploitable to cause a negative impact to the confidentiality, integrity, or 
availability of an impacted component or components (from CVE®)
Weakness
A flaw in a software, firmware, hardware, or service component that may or may 
not be exploitable to cause a negative impact to the confidentiality, 
integrity, or availability of an impacted component or components.

Vulnerabilities must be known to be exploitable because of the CVE criteria 
[usg02.safelinks.protection.office365.us]<https://urldefense.com/v3/__https:/usg02.safelinks.protection.office365.us/?url=https*3A*2F*2Fwww.cve.org*2FAbout*2FProcess*23CVERecordLifecycle=05*7C01*7Crob.wissmann*40nteligen.com*7Cbfe6bb046efb4259739408da65bc21af*7C379c214c5c944e86a6062d047675f02a*7C0*7C0*7C637934155958576066*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C=dPvbIHKos0b6KigosyMLP*2FltfYU0IV577aPlhHhtXFI*3D=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!M-nmYVHPHQ!L3NWgNeTRatlJP851k7GSvKVNwpKSbTlrri3L8E6knvWblXRHtAn33UxrNkA2PIzCvhOuhBRTPJ6sIFY12SWPQ-S_UyhCVUa$>:
 “Details include but are not limited to affected product(s); affected or fixed 
product versions; vulnerability type, root cause, or impact; and at least one 
public reference.”

An example of a flaw that may or may not be a vulnerability is an integer 
overflow. It might result in a vulnerability, or it might not. That’s a 
weakness.

Thanks

From: Alec J Summers mailto:asumm...@mitre.org>>
Sent: Wednesday, July 13, 2022 1:09 PM
To: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)
Weakness
A type of flaw or defect inserted during 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 approac

RE: CWE/CAPEC Definitions

[Rob Wissmann]

Putting "known" in there still works. It doesn't say publicly known, and known 
ability to be exploited for negative impact is still the distinction between 
weakness and vulnerability.

From: SJ Jazz 
Sent: Thursday, July 14, 2022 1:13 PM
To: Rob Wissmann 
Cc: Alec J Summers ; CWE Research Discussion 

Subject: Re: CWE/CAPEC Definitions

Actually, being listed as a CVE is not the criteria for being a vulnerability.  
Only vulnerabilities catalogued as CVEs are 'known vulnerabilities'. There are 
actual instances of uncatalogued (unpublished) vulnerabilities; some are in 
proprietary or intelligence organization's libraries, and some are held by 
malicious actors for future exploitation (at which point they will be known as 
zero-day vulnerabilities).

It is the existence of an exploit designed to take advantage of a weakness (or 
multiple weaknesses) and achieve a negative technical impact that makes a 
weakness a vulnerability.

It is not the state of being publicly known or catalogued that makes it a 
vulnerability.

...Joe



On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
mailto:rob.wissm...@nteligen.com>> wrote:
Regarding the circular definitions, it has always struck me that weaknesses are 
flaws that may or may not be exploitable to cause negative impact whereas 
vulnerabilities are flaws known to be exploitable to cause negative impact.

A rewrite of the definitions to match this concept:

Vulnerability
A flaw in a software, firmware, hardware, or service component known to be 
exploitable to cause a negative impact to the confidentiality, integrity, or 
availability of an impacted component or components (from CVE(r))
Weakness
A flaw in a software, firmware, hardware, or service component that may or may 
not be exploitable to cause a negative impact to the confidentiality, 
integrity, or availability of an impacted component or components.

Vulnerabilities must be known to be exploitable because of the CVE 
criteria<https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.cve.org%2FAbout%2FProcess%23CVERecordLifecycle=05%7C01%7Crob.wissmann%40nteligen.com%7Cbfe6bb046efb4259739408da65bc21af%7C379c214c5c944e86a6062d047675f02a%7C0%7C0%7C637934155958576066%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=dPvbIHKos0b6KigosyMLP%2FltfYU0IV577aPlhHhtXFI%3D=0>:
 "Details include but are not limited to affected product(s); affected or fixed 
product versions; vulnerability type, root cause, or impact; and at least one 
public reference."

An example of a flaw that may or may not be a vulnerability is an integer 
overflow. It might result in a vulnerability, or it might not. That's a 
weakness.

Thanks

From: Alec J Summers mailto:asumm...@mitre.org>>
Sent: Wednesday, July 13, 2022 1:09 PM
To: CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE(r))
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE's definition for 'vulnerability' was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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(tm)




--
Regards,

Joe

Joe Jarzombek
C 703 627-4644

Re: CWE/CAPEC Definitions

[SJ Jazz]

Actually, being listed as a CVE is not the criteria for being a
vulnerability.  Only vulnerabilities catalogued as CVEs are 'known
vulnerabilities'. There are actual instances of uncatalogued (unpublished)
vulnerabilities; some are in proprietary or intelligence organization's
libraries, and some are held by malicious actors for future exploitation
(at which point they will be known as zero-day vulnerabilities).

It is the existence of an exploit designed to take advantage of a weakness
(or multiple weaknesses) and achieve a negative technical impact that makes
a weakness a vulnerability.

It is not the state of being publicly known or catalogued that makes it a
vulnerability.

...Joe



On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann 
wrote:

> Regarding the circular definitions, it has always struck me that
> weaknesses are flaws that *may or may not* be exploitable to cause
> negative impact whereas vulnerabilities are flaws *known* to be
> exploitable to cause negative impact.
>
>
>
> A rewrite of the definitions to match this concept:
>
>
>
> *Vulnerability*
>
> *A flaw in a software, firmware, hardware, or service component known to
> be exploitable to cause a negative impact to the confidentiality,
> integrity, or availability of an impacted component or components (from
> CVE®)*
>
> *Weakness*
>
> *A flaw in a software, firmware, hardware, or service component that may
> or may not be exploitable to cause a negative impact to the
> confidentiality, integrity, or availability of an impacted component or
> components.*
>
>
>
> Vulnerabilities must be known to be exploitable because of the CVE
> criteria : “Details
> include but are not limited to affected product(s); affected or fixed
> product versions; vulnerability type, root cause, or impact; and at least
> one public reference.”
>
>
>
> An example of a flaw that may or may not be a vulnerability is an integer
> overflow. It might result in a vulnerability, or it might not. That’s a
> weakness.
>
>
>
> Thanks
>
>
>
> *From:* Alec J Summers 
> *Sent:* Wednesday, July 13, 2022 1:09 PM
> *To:* CWE Research Discussion 
> *Subject:* CWE/CAPEC Definitions
>
>
>
> Dear CWE Research Community,
>
>
>
> I hope this email finds you well.
>
>
>
> Over the past few months, the CWE/CAPEC User Experience Working Group has
> been working to modernize our programs through a variety of activities. One
> such activity is harmonizing the definitions on our sites for some of our
> key terminology including weakness, vulnerability, and attack pattern. As
> CWE and CAPEC were developed separately and on a different timeline, some
> of the terms are not defined similarly, and we want to address that.
>
>
>
> We are seeking feedback on our working definitions:
>
>
>
> *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 (from CVE®)*
>
> *Weakness*
>
> *A type of flaw or defect inserted during 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
> weakness, usually in cyber-enabled capabilities*
>
>
>
> *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after
> significant community deliberation, and we are not looking to change it at
> this time.
>
>
>
> We are hoping to publish new, improved definitions on our websites at the
> end of the month. Please provide thoughts and comments by Tuesday, July 26.
>
>
>
> 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™*
>
>
>
>
>


-- 
Regards,

Joe

Joe Jarzombek
C 703 627-4644

RE: [External] - RE: CWE/CAPEC Definitions

[Paul Anderson]

I also agree with dropping that part of the definition. The rest is good.

-Paul

---
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850
Tel: +1 607 273-7340 x118; 
https://www.grammatech.com<https://www.grammatech.com/>

From: Schweiger, Andreas Dr. 
Sent: Thursday, July 14, 2022 7:58 AM
To: CWE Research Discussion 
Subject: [External] - RE: CWE/CAPEC Definitions

CAUTION: External Email


Dear all,

dropping the mentioned part of the sentence is a very good idea.

Apart from that I am fine with all three definitions.

Best wishes
Andreas

Dr. rer. nat. Andreas Schweiger, Dipl.-Inf. (Univ.)
System Architect
TOR Embedded RTS Development - TEYXI
Airbus Defence and Space

T   +49 8459 81-67087
M  +49 172 7159582
F   +49 8459 81-78112
E   andreas.schwei...@airbus.com<mailto:andreas.schwei...@airbus.com>

Airbus Defence and Space GmbH
Rechliner Straße
85077 Manching
Germany

www.airbusdefenceandspace.com<https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.airbusdefenceandspace.com%2F=05%7C01%7C%7Cdaaf2cc7c873487ff2be08da65975f14%7C22cbf1b8306c42309e2a81f94e129fa8%7C1%7C0%7C637933998060165434%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=VDFKbLeRfw68eWoRZiIw%2Fh0AFPgbbGo4X9X2u6Hys7E%3D=0>

Airbus Defence and Space GmbH

Chairman of the Supervisory Board: Dominik Asam
Managing Directors: Dr. Michael Schoellhorn (Chairman), Dr. Lars Immisch
Registered Office: Ottobrunn
District Court of Munich HRB 107 648
UST. Ident. Nr./VAT reg. no. DE167015661




THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

From: James Pangburn [mailto:jpangb...@cadence.com]
Sent: Wednesday, July 13, 2022 10:49 PM
To: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>; Kurt 
Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: RE: CWE/CAPEC Definitions

I also vote to drop "in a range of ..."

Best regards,
Jim Pangburn
Director, IPG Operations

From: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>
Sent: Wednesday, July 13, 2022 1:21 PM
To: Kurt Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: CWE/CAPEC Definitions

EXTERNAL MAIL
Or for that matter non-vendors. Software composition, as an example, Open 
Source, etc.



Best Regards,
Joe Baum
Director, Threat Management Group





On Wed, Jul 13, 2022 at 3:18 PM Kurt Seifried 
mailto:k...@seifried.org>> wrote:
Also, it excludes services. So yeah, I vote drop the " in a range of products 
made by different vendors"

On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz 
mailto:sjoeja...@gmail.com>> wrote:
I still recommend deleting at the end of the definition of weakness "... in a 
range of products made by different vendors.

It adds no value, and actually unintentionally limits applicability by implying 
weaknesses only apply to products made by vendors.

Regards,

Joe

On Wed, Jul 13, 2022, 12:08 Alec J Summers 
mailto:asumm...@mitre.org>> wrote:
Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE's definition for 'vulnerability' was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

Cheers,
Alec

--
Alec J. Summers
Center for Securing the Homeland (CSH)
Cyber Security Engineer, Principal
Group Lead, Cybersecurity Operations and Integration
---

RE: CWE/CAPEC Definitions

[Rob Wissmann]

Regarding the circular definitions, it has always struck me that weaknesses are 
flaws that may or may not be exploitable to cause negative impact whereas 
vulnerabilities are flaws known to be exploitable to cause negative impact.

A rewrite of the definitions to match this concept:

Vulnerability
A flaw in a software, firmware, hardware, or service component known to be 
exploitable to cause a negative impact to the confidentiality, integrity, or 
availability of an impacted component or components (from CVE(r))
Weakness
A flaw in a software, firmware, hardware, or service component that may or may 
not be exploitable to cause a negative impact to the confidentiality, 
integrity, or availability of an impacted component or components.

Vulnerabilities must be known to be exploitable because of the CVE 
criteria: "Details 
include but are not limited to affected product(s); affected or fixed product 
versions; vulnerability type, root cause, or impact; and at least one public 
reference."

An example of a flaw that may or may not be a vulnerability is an integer 
overflow. It might result in a vulnerability, or it might not. That's a 
weakness.

Thanks

From: Alec J Summers 
Sent: Wednesday, July 13, 2022 1:09 PM
To: CWE Research Discussion 
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE(r))
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE's definition for 'vulnerability' was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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(tm)

Re: CWE/CAPEC Definitions

[nazar.abdul]

Hello,



I think the below red part should be removed because:



1. It removes dependency of definition of Vulnerability on the next definition 
"Weakness", do we really want one definition to be dependent on another 
definition? this creates confusion because now in order to understand

    what a vulnerability, now I have to read the definition of Weakness.



2. Makes it clear that it can be any type of flaw.




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 (from CVE®)













Sincerely

Nazar Abdul

SysIntellects LLC | Lead Success Manager/Principal Architect
CMx Contract Experience Success Team 

M: 727-249-4238 | O: 1-844-433-3269 Extn:803
101 East Park Blvd, #600, Plano TX 75074
mailto:nazar.ab...@sysintellects.com | http://www.sysintellects.com


Next Generation CLM Platform?  
Visit:https://www.contractexperience.comhttps://www.contractexperience.com



CONFIDENTIALITY  NOTICE: This e-mail and any files attached contain 
confidential  information of SysIntellects LLC. If you are not the intended 
recipient,  or a person responsible for delivering it, you are hereby notified 
that  any disclosure, copying, distribution or use of any of the information  
contained in or attached to this transmission is STRICTLY PROHIBITED. If  you 
have received this transmission in error, please destroy the  original 
transmission and its attachments without reading or saving in  any manner and 
notify the sender.If you do not want to receive any further emails from us , 
please reply with text UNSUBSCRIBE in subject line.













 On Wed, 13 Jul 2022 12:08:33 -0500 Alec J Summers  
wrote ---




Dear CWE Research Community,

 

I hope this email finds you well.

 

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions
 on our sites for some of our key terminology including weakness, 
vulnerability, and attack pattern. As CWE and CAPEC were developed separately 
and on a different timeline, some of the terms are not defined similarly, and 
we want to address that.

 

We are seeking feedback on our working definitions:

 

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 (from CVE®)



Weakness


A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities





 

Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

 

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

 

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™

 



 

Re: CWE/CAPEC Definitions

[Landfield, Kent]

Agreed.

Change the highlighted ‘vulnerabilities’ and ‘a weakness’ to ‘conditions’…

Just a quick thought.

Thank you, Gracias, Grazie, Mahalo, Merci, Σας ευχαριστώ, Bedankt, Danke, 
ありがとう, धन्यवाद!
--
Kent Landfield
Trellix
+1.817.637.8026
kent.landfi...@trellix.com

From: Paul Wooderson 
Date: Thursday, July 14, 2022 at 11:19 AM
To: Alec J Summers , CWE Research Discussion 

Subject: RE: CWE/CAPEC Definitions


CAUTION: External email. Do not click links or open attachments unless you 
recognize the sender and know the content is safe.


All,

One issue I see with these definitions of vulnerability and weakness is that 
they are circular, i.e. each term uses the other in its definition. So when 
each term is replaced with its definition in the other term’s definition, it is 
impossible to resolve what is intended. I have tried this below (including 
striking the “range of products” as suggested by others) – the substituted 
definitions are in red text and the circularities are highlighted in yellow.

Vulnerability
A flaw in a software, firmware, hardware, or service component resulting from a 
type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could contribute to the introduction of vulnerabilities in a 
range of products made by different vendors that can be exploited, causing a 
negative impact to the confidentiality, integrity, or availability of an 
impacted component or components (from CVE®)
Weakness
A type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could contribute to the introduction of flaws 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 in a range of products made 
by different vendors

We have recently addressed the same issue with these same terms in the recently 
published automotive cybersecurity standard ISO/SAE 21434. There we settled on 
the following definitions:

vulnerability
weakness that can be exploited as part of an attack path
weakness
defect or characteristic that can lead to undesirable behaviour

In this way we can define vulnerabilities as a specific subset of weaknesses.

Definitions in ISO standards tend to be short and less descriptive than these 
from CVE/CWE, so it may not be appropriate to directly suggest them here. 
However, if it is preferred to not make further changes to “vulnerability”, 
then perhaps “weakness” could be modified as follows in order to avoid the 
circularity:

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 (from CVE®)
Weakness
A type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could lead to undesirable behaviour


Best regards,
Paul

Paul Wooderson
Chief Engineer – Cybersecurity
Email:
paul.wooder...@horiba-mira.com<mailto:paul.wooder...@horiba-mira.com>
Direct:
+44 24 7635 5244
Mobile:
+44 7731 010066
HORIBA MIRA Ltd.
Watling Street, Nuneaton
Warwickshire, CV10 0TU, UK
www.horiba-mira.com<https://www.horiba-mira.com/>

From: Alec J Summers 
Sent: 13 July 2022 18:09
To: CWE Research Discussion 
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

Cheers,
Alec

--
Alec J. Su

Re: CWE/CAPEC Definitions

[SJ Jazz]

A short alternative definition for weakness:  defect or characteristic that
could enable undesirable behaviour

...Joe

On Thu, Jul 14, 2022, 11:18 Paul Wooderson 
wrote:

> All,
>
>
>
> One issue I see with these definitions of vulnerability and weakness is
> that they are circular, i.e. each term uses the other in its definition. So
> when each term is replaced with its definition in the other term’s
> definition, it is impossible to resolve what is intended. I have tried this
> below (including striking the “range of products” as suggested by others) –
> the substituted definitions are in red text and the circularities are
> highlighted in yellow.
>
>
>
> *Vulnerability*
>
> *A flaw in a software, firmware, hardware, or service component resulting
> from a **type of flaw or defect inserted during a product lifecycle that,
> under the right conditions, could contribute to the introduction of
> vulnerabilities in a range of products made by different vendors** that
> can be exploited, causing a negative impact to the confidentiality,
> integrity, or availability of an impacted component or components (from
> CVE®)*
>
> *Weakness*
>
> *A type of flaw or defect inserted during a product lifecycle that, under
> the right conditions, could contribute to the introduction of flaws 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 in a range of products made by different vendors*
>
>
>
> We have recently addressed the same issue with these same terms in the
> recently published automotive cybersecurity standard ISO/SAE 21434. There
> we settled on the following definitions:
>
>
>
> vulnerability
>
> weakness that can be exploited as part of an attack path
>
> weakness
>
> defect or characteristic that can lead to undesirable behaviour
>
>
>
> In this way we can define vulnerabilities as a specific subset of
> weaknesses.
>
>
>
> Definitions in ISO standards tend to be short and less descriptive than
> these from CVE/CWE, so it may not be appropriate to directly suggest them
> here. However, if it is preferred to not make further changes to
> “vulnerability”, then perhaps “weakness” could be modified as follows in
> order to avoid the circularity:
>
>
>
> *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 (from CVE®)*
>
> *Weakness*
>
> *A type of flaw or defect inserted during a product lifecycle that, under
> the right conditions, could **lead to undesirable behaviour*
>
>
>
>
>
> Best regards,
>
> Paul
>
>
>
> *Paul Wooderson*
> *Chief Engineer – Cybersecurity*
>
> Email:
>
> *paul.wooder...@horiba-mira.com *
>
> Direct:
>
> +44 24 7635 5244
>
> Mobile:
>
> +44 7731 010066
>
> HORIBA MIRA Ltd.
> Watling Street, Nuneaton
> Warwickshire, CV10 0TU, UK
>
> *www.horiba-mira.com *
>
>
>
> *From:* Alec J Summers 
> *Sent:* 13 July 2022 18:09
> *To:* CWE Research Discussion 
> *Subject:* CWE/CAPEC Definitions
>
>
>
> Dear CWE Research Community,
>
>
>
> I hope this email finds you well.
>
>
>
> Over the past few months, the CWE/CAPEC User Experience Working Group has
> been working to modernize our programs through a variety of activities. One
> such activity is harmonizing the definitions on our sites for some of our
> key terminology including weakness, vulnerability, and attack pattern. As
> CWE and CAPEC were developed separately and on a different timeline, some
> of the terms are not defined similarly, and we want to address that.
>
>
>
> We are seeking feedback on our working definitions:
>
>
>
> *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 (from CVE®)*
>
> *Weakness*
>
> *A type of flaw or defect inserted during 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
> weakness, usually in cyber-enabled capabilities*
>
>
>
> *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after
> significant community deliberation, and we are not looking to change it at
> this time.
>
>
>
> We are hoping to publish new, improved definitions on our websites at the
> end of the month. Please provide thoughts and comments by Tuesday, July 26.
>
>
>
> Cheers,
>
> Alec
>
>
>
> --
>
> *Alec J. Summers*
>
> Center for Securing the Homeland (CSH)
>
> Cyber Security Engineer, Principal
>
> Group Lead, 

RE: CWE/CAPEC Definitions

[Paul Wooderson]

All,

One issue I see with these definitions of vulnerability and weakness is that 
they are circular, i.e. each term uses the other in its definition. So when 
each term is replaced with its definition in the other term's definition, it is 
impossible to resolve what is intended. I have tried this below (including 
striking the "range of products" as suggested by others) - the substituted 
definitions are in red text and the circularities are highlighted in yellow.

Vulnerability
A flaw in a software, firmware, hardware, or service component resulting from a 
type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could contribute to the introduction of vulnerabilities in a 
range of products made by different vendors that can be exploited, causing a 
negative impact to the confidentiality, integrity, or availability of an 
impacted component or components (from CVE(r))
Weakness
A type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could contribute to the introduction of flaws 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 in a range of products made 
by different vendors

We have recently addressed the same issue with these same terms in the recently 
published automotive cybersecurity standard ISO/SAE 21434. There we settled on 
the following definitions:

vulnerability
weakness that can be exploited as part of an attack path
weakness
defect or characteristic that can lead to undesirable behaviour

In this way we can define vulnerabilities as a specific subset of weaknesses.

Definitions in ISO standards tend to be short and less descriptive than these 
from CVE/CWE, so it may not be appropriate to directly suggest them here. 
However, if it is preferred to not make further changes to "vulnerability", 
then perhaps "weakness" could be modified as follows in order to avoid the 
circularity:

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 (from CVE(r))
Weakness
A type of flaw or defect inserted during a product lifecycle that, under the 
right conditions, could lead to undesirable behaviour


Best regards,
Paul

Paul Wooderson
Chief Engineer - Cybersecurity
Email:
paul.wooder...@horiba-mira.com
Direct:
+44 24 7635 5244
Mobile:
+44 7731 010066
HORIBA MIRA Ltd.
Watling Street, Nuneaton
Warwickshire, CV10 0TU, UK
www.horiba-mira.com


From: Alec J Summers 
Sent: 13 July 2022 18:09
To: CWE Research Discussion 
Subject: CWE/CAPEC Definitions

Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE(r))
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE's definition for 'vulnerability' was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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(tm)



HORIBA MIRA Ltd

Watling Street, Nuneaton, Warwickshire, CV10 0TU, England
Registered in England and Wales No. 9626352
VAT Registration  GB 100 1464 84

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you should not disseminate, 

RE: CWE/CAPEC Definitions

[Paul.Wortman]

I also agree with dropping the “in a range of….” piece.  It just further 
muddies the water and adds no value.

   - Paul

From: Schweiger, Andreas Dr. 
Sent: Thursday, July 14, 2022 7:58 AM
To: CWE Research Discussion 
Subject: RE: CWE/CAPEC Definitions


Dear all,

dropping the mentioned part of the sentence is a very good idea.

Apart from that I am fine with all three definitions.

Best wishes
Andreas

Dr. rer. nat. Andreas Schweiger, Dipl.-Inf. (Univ.)
System Architect
TOR Embedded RTS Development - TEYXI
Airbus Defence and Space

T   +49 8459 81-67087
M  +49 172 7159582
F   +49 8459 81-78112
E   andreas.schwei...@airbus.com<mailto:andreas.schwei...@airbus.com>

Airbus Defence and Space GmbH
Rechliner Straße
85077 Manching
Germany

www.airbusdefenceandspace.com<https://urldefense.com/v3/__http:/www.airbusdefenceandspace.com/__;!!F9svGWnIaVPGSwU!qTdaFI-OGThsZAjQ-7qpuGoSD7cRo1r090e1fapJ9H4bxFOwQ75ag9ZkagEZRHCGzz7PwQQAQeRoHsJg8BwXCoQ1peMTABRnWA$>

Airbus Defence and Space GmbH

Chairman of the Supervisory Board: Dominik Asam
Managing Directors: Dr. Michael Schoellhorn (Chairman), Dr. Lars Immisch
Registered Office: Ottobrunn
District Court of Munich HRB 107 648
UST. Ident. Nr./VAT reg. no. DE167015661




THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

From: James Pangburn [mailto:jpangb...@cadence.com]
Sent: Wednesday, July 13, 2022 10:49 PM
To: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>; Kurt 
Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: RE: CWE/CAPEC Definitions

I also vote to drop “in a range of …”

Best regards,
Jim Pangburn
Director, IPG Operations

From: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>
Sent: Wednesday, July 13, 2022 1:21 PM
To: Kurt Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: CWE/CAPEC Definitions

EXTERNAL MAIL
Or for that matter non-vendors. Software composition, as an example, Open 
Source, etc.



Best Regards,
Joe Baum
Director, Threat Management Group





On Wed, Jul 13, 2022 at 3:18 PM Kurt Seifried 
mailto:k...@seifried.org>> wrote:
Also, it excludes services. So yeah, I vote drop the " in a range of products 
made by different vendors"

On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz 
mailto:sjoeja...@gmail.com>> wrote:
I still recommend deleting at the end of the definition of weakness "... in a 
range of products made by different vendors.

It adds no value, and actually unintentionally limits applicability by implying 
weaknesses only apply to products made by vendors.

Regards,

Joe

On Wed, Jul 13, 2022, 12:08 Alec J Summers 
mailto:asumm...@mitre.org>> wrote:
Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)

Weakness

A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities


Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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™




--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


For more information on how and why we collect your personal information, 
please visit our Privacy 
Policy<https://urldefense.com/v3/__https:/www.motorolasolutions.com/en_us/about/privac

RE: CWE/CAPEC Definitions

[Schweiger, Andreas Dr.]

Dear all,

dropping the mentioned part of the sentence is a very good idea.

Apart from that I am fine with all three definitions.

Best wishes
Andreas

Dr. rer. nat. Andreas Schweiger, Dipl.-Inf. (Univ.)
System Architect
TOR Embedded RTS Development - TEYXI
Airbus Defence and Space

T   +49 8459 81-67087
M  +49 172 7159582
F   +49 8459 81-78112
E   andreas.schwei...@airbus.com<mailto:andreas.schwei...@airbus.com>

Airbus Defence and Space GmbH
Rechliner Straße
85077 Manching
Germany

www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>

Airbus Defence and Space GmbH

Chairman of the Supervisory Board: Dominik Asam
Managing Directors: Dr. Michael Schoellhorn (Chairman), Dr. Lars Immisch
Registered Office: Ottobrunn
District Court of Munich HRB 107 648
UST. Ident. Nr./VAT reg. no. DE167015661



THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

From: James Pangburn [mailto:jpangb...@cadence.com]
Sent: Wednesday, July 13, 2022 10:49 PM
To: Joe Baum ; Kurt Seifried 
Cc: SJ Jazz ; Alec J Summers ; CWE 
Research Discussion 
Subject: RE: CWE/CAPEC Definitions

I also vote to drop “in a range of …”

Best regards,
Jim Pangburn
Director, IPG Operations

From: Joe Baum 
mailto:joe.b...@motorolasolutions.com>>
Sent: Wednesday, July 13, 2022 1:21 PM
To: Kurt Seifried mailto:k...@seifried.org>>
Cc: SJ Jazz mailto:sjoeja...@gmail.com>>; Alec J Summers 
mailto:asumm...@mitre.org>>; CWE Research Discussion 
mailto:cwe-research-list@mitre.org>>
Subject: Re: CWE/CAPEC Definitions

EXTERNAL MAIL
Or for that matter non-vendors. Software composition, as an example, Open 
Source, etc.



Best Regards,
Joe Baum
Director, Threat Management Group





On Wed, Jul 13, 2022 at 3:18 PM Kurt Seifried 
mailto:k...@seifried.org>> wrote:
Also, it excludes services. So yeah, I vote drop the " in a range of products 
made by different vendors"

On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz 
mailto:sjoeja...@gmail.com>> wrote:
I still recommend deleting at the end of the definition of weakness "... in a 
range of products made by different vendors.

It adds no value, and actually unintentionally limits applicability by implying 
weaknesses only apply to products made by vendors.

Regards,

Joe

On Wed, Jul 13, 2022, 12:08 Alec J Summers 
mailto:asumm...@mitre.org>> wrote:
Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)

Weakness

A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities


Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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™




--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


For more information on how and why we collect your personal information, 
please visit our Privacy 
Policy<https://urldefense.com/v3/__https:/www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7=2786=2*privacystatement__;Iw!!EHscmS1ygiU1lA!HoAHMf_wuSq-0SkyyBWnWkRrlC1iilECJYPmmvLny6ZvzB7Ffrj5HuBJ3ORBz0l5JEIPajfx6HC5WZtdO0TO93z2Ww$>.
The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail by 
anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any concerns 
over the c

RE: CWE/CAPEC Definitions

[James Pangburn]

I also vote to drop “in a range of …”

Best regards,
Jim Pangburn
Director, IPG Operations

From: Joe Baum 
Sent: Wednesday, July 13, 2022 1:21 PM
To: Kurt Seifried 
Cc: SJ Jazz ; Alec J Summers ; CWE 
Research Discussion 
Subject: Re: CWE/CAPEC Definitions

EXTERNAL MAIL
Or for that matter non-vendors. Software composition, as an example, Open 
Source, etc.



Best Regards,
Joe Baum
Director, Threat Management Group





On Wed, Jul 13, 2022 at 3:18 PM Kurt Seifried 
mailto:k...@seifried.org>> wrote:
Also, it excludes services. So yeah, I vote drop the " in a range of products 
made by different vendors"

On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz 
mailto:sjoeja...@gmail.com>> wrote:
I still recommend deleting at the end of the definition of weakness "... in a 
range of products made by different vendors.

It adds no value, and actually unintentionally limits applicability by implying 
weaknesses only apply to products made by vendors.

Regards,

Joe

On Wed, Jul 13, 2022, 12:08 Alec J Summers 
mailto:asumm...@mitre.org>> wrote:
Dear CWE Research Community,

I hope this email finds you well.

Over the past few months, the CWE/CAPEC User Experience Working Group has been 
working to modernize our programs through a variety of activities. One such 
activity is harmonizing the definitions on our sites for some of our key 
terminology including weakness, vulnerability, and attack pattern. As CWE and 
CAPEC were developed separately and on a different timeline, some of the terms 
are not defined similarly, and we want to address that.

We are seeking feedback on our working definitions:

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 (from CVE®)
Weakness
A type of flaw or defect inserted during 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 weakness, 
usually in cyber-enabled capabilities

Note: CVE’s definition for ‘vulnerability’ was agreed upon after significant 
community deliberation, and we are not looking to change it at this time.

We are hoping to publish new, improved definitions on our websites at the end 
of the month. Please provide thoughts and comments by Tuesday, July 26.

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™




--
Kurt Seifried (He/Him)
k...@seifried.org<mailto:k...@seifried.org>


For more information on how and why we collect your personal information, 
please visit our Privacy 
Policy<https://urldefense.com/v3/__https:/www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackId=8980d888905940e39a2613a7a3dcb0a7=2786=2*privacystatement__;Iw!!EHscmS1ygiU1lA!HoAHMf_wuSq-0SkyyBWnWkRrlC1iilECJYPmmvLny6ZvzB7Ffrj5HuBJ3ORBz0l5JEIPajfx6HC5WZtdO0TO93z2Ww$>.

Re: CWE/CAPEC Definitions

[Joe Baum]

Or for that matter non-vendors. Software composition, as an example, Open
Source, etc.


Best Regards,
Joe Baum
Director, Threat Management Group





On Wed, Jul 13, 2022 at 3:18 PM Kurt Seifried  wrote:

> Also, it excludes services. So yeah, I vote drop the " in a range of
> products made by different vendors"
>
> On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz  wrote:
>
>> I still recommend deleting at the end of the definition of weakness
>> "... in a range of products made by different vendors.
>>
>> It adds no value, and actually unintentionally limits applicability by
>> implying weaknesses only apply to products made by vendors.
>>
>> Regards,
>>
>> Joe
>>
>> On Wed, Jul 13, 2022, 12:08 Alec J Summers  wrote:
>>
>>> Dear CWE Research Community,
>>>
>>>
>>>
>>> I hope this email finds you well.
>>>
>>>
>>>
>>> Over the past few months, the CWE/CAPEC User Experience Working Group
>>> has been working to modernize our programs through a variety of activities.
>>> One such activity is harmonizing the definitions on our sites for some of
>>> our key terminology including weakness, vulnerability, and attack pattern.
>>> As CWE and CAPEC were developed separately and on a different timeline,
>>> some of the terms are not defined similarly, and we want to address that.
>>>
>>>
>>>
>>> We are seeking feedback on our working definitions:
>>>
>>>
>>>
>>> *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 (from CVE®)*
>>>
>>> *Weakness*
>>>
>>> *A type of flaw or defect inserted during 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
>>> weakness, usually in cyber-enabled capabilities*
>>>
>>>
>>>
>>> *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after
>>> significant community deliberation, and we are not looking to change it at
>>> this time.
>>>
>>>
>>>
>>> We are hoping to publish new, improved definitions on our websites at
>>> the end of the month. Please provide thoughts and comments by Tuesday, July
>>> 26.
>>>
>>>
>>>
>>> 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™*
>>>
>>>
>>>
>>>
>>>
>>
>
> --
> Kurt Seifried (He/Him)
> k...@seifried.org
>

-- 


*For more information on how and why we collect your personal 
information, please visit our Privacy Policy 
.*

Re: CWE/CAPEC Definitions

[Kurt Seifried]

Also, it excludes services. So yeah, I vote drop the " in a range of
products made by different vendors"

On Wed, Jul 13, 2022 at 2:12 PM SJ Jazz  wrote:

> I still recommend deleting at the end of the definition of weakness
> "... in a range of products made by different vendors.
>
> It adds no value, and actually unintentionally limits applicability by
> implying weaknesses only apply to products made by vendors.
>
> Regards,
>
> Joe
>
> On Wed, Jul 13, 2022, 12:08 Alec J Summers  wrote:
>
>> Dear CWE Research Community,
>>
>>
>>
>> I hope this email finds you well.
>>
>>
>>
>> Over the past few months, the CWE/CAPEC User Experience Working Group has
>> been working to modernize our programs through a variety of activities. One
>> such activity is harmonizing the definitions on our sites for some of our
>> key terminology including weakness, vulnerability, and attack pattern. As
>> CWE and CAPEC were developed separately and on a different timeline, some
>> of the terms are not defined similarly, and we want to address that.
>>
>>
>>
>> We are seeking feedback on our working definitions:
>>
>>
>>
>> *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 (from CVE®)*
>>
>> *Weakness*
>>
>> *A type of flaw or defect inserted during 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
>> weakness, usually in cyber-enabled capabilities*
>>
>>
>>
>> *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after
>> significant community deliberation, and we are not looking to change it at
>> this time.
>>
>>
>>
>> We are hoping to publish new, improved definitions on our websites at the
>> end of the month. Please provide thoughts and comments by Tuesday, July 26.
>>
>>
>>
>> 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™*
>>
>>
>>
>>
>>
>

-- 
Kurt Seifried (He/Him)
k...@seifried.org

Re: CWE/CAPEC Definitions

[SJ Jazz]

I still recommend deleting at the end of the definition of weakness "... in
a range of products made by different vendors.

It adds no value, and actually unintentionally limits applicability by
implying weaknesses only apply to products made by vendors.

Regards,

Joe

On Wed, Jul 13, 2022, 12:08 Alec J Summers  wrote:

> Dear CWE Research Community,
>
>
>
> I hope this email finds you well.
>
>
>
> Over the past few months, the CWE/CAPEC User Experience Working Group has
> been working to modernize our programs through a variety of activities. One
> such activity is harmonizing the definitions on our sites for some of our
> key terminology including weakness, vulnerability, and attack pattern. As
> CWE and CAPEC were developed separately and on a different timeline, some
> of the terms are not defined similarly, and we want to address that.
>
>
>
> We are seeking feedback on our working definitions:
>
>
>
> *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 (from CVE®)*
>
> *Weakness*
>
> *A type of flaw or defect inserted during 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
> weakness, usually in cyber-enabled capabilities*
>
>
>
> *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after
> significant community deliberation, and we are not looking to change it at
> this time.
>
>
>
> We are hoping to publish new, improved definitions on our websites at the
> end of the month. Please provide thoughts and comments by Tuesday, July 26.
>
>
>
> 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™*
>
>
>
>
>