Re: [EXT] RE: Glossary

[Alec J Summers]

Board members,

Thanks so much to JasonO, JasonF, and Joe for your considered feedback. I 
encourage ongoing deliberation on this thread to the points raised by these 
individuals.

I will be sending out the research list email on this topic this afternoon and 
will collect/share feedback with you all.

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: SJ Jazz 
Date: Tuesday, July 12, 2022 at 4:59 PM
To: Jason Oberg 
Cc: Fung, Jason , Alec J Summers , 
Hoole, Alexander , jw...@redhat.com 
, Seifried, Kurt , CWE CAPEC Board 

Subject: Re: [EXT] RE: Glossary

I'm OK with not further tweaking the definition of 'vulnerability'; yet while 
providing updated definitions for 'weakness' and 'attack pattern', we should 
also address associated definitions/descriptions of:

- Cyber-Enabled Capability
- Weakness Type
- Negative Technical Impact
- Exploit

When defining 'attack pattern', we should also address associated 
definitions/descriptions of:

- Exploit
- Attack
- Meta Attack Pattern
- Standard Attack Pattern
- Detailed Attack Pattern

Yes, 'Exploit' is important to both Weakness and Attack Pattern.

With 'Weakness', using the currently available definition, I suggest:

1. We should avoid using 'mistake' in the definition and instead use 'flaw' or 
'defect' since a mistake might imply there was no intent to create the flaw; 
yet a flaw or defect could have been inserted deliberately (as a feature) 
without understanding the consequences of potential exploitability or 
deliberately with malicious intent.  The existence of a 'flaw' or 'defect' and 
its exploitability potential is often independent of intent; yet insertion of a 
flaw or defect might not be a mistake.

2. We might shorten "...made during the implementation, design, or other phases 
of a product lifecycle..." to "...inserted during a product lifecycle..." since 
a weakness could be inserted anytime, even after the product is operational.

3. We might consider changing "...under the right conditions, could contribute 
to the introduction of vulnerabilities in a range of products made by different 
vendors" to "...if left unaddressed, could under the proper conditions 
contribute to a cyber-enabled capability being vulnerable to exploitation" 
since this better fulfills the reason we introduced the concept of weakness vs 
vulnerability -- weaknesses can be source vectors of future vulnerabilities, 
and they are not limited to 'products made by different vendors'.

4. In providing a description of weakness, it would be useful to remind all 
that a weakness represents a potential source vector for zero-day exploits and 
zero-day vulnerabilities, and that it is the existence of an exploit designed 
to take advantage of a weakness (or multiple weaknesses) and achieve a negative 
technical impact is what makes a weakness a vulnerability.


With 'Attack Pattern', using the currently available definition, I suggest:

1. We avoid using 'known weakness type' and just simply use 'weakness' since it 
does not have to be publicly known to be subject to exploitation; indeed, it is 
often the lesser known weaknesses that represent source vectors for zero-day 
exploits.

2. We consider explicitly including 'exploit designed to take advantage of a 
weakness' in the definition of an attack pattern


When I have available time, I will address the other terms.  In the interim, 
I'd welcome comments and recommendations about the above comments.

Regards,

Joe Jarzombek
703 627-4644


On Tue, Jul 12, 2022 at 12:51 PM Jason Oberg 
mailto:ja...@cycuity.com>> wrote:
The proposed course of action sounds good to me.

FWIW for the weakness definition, I'm still thrown off by the word "mistake" 
because a weakness could be introduced intentionally or by mistake.

Of course we could debate definitions forever so your proposed approach to 
reach resolution sounds efficient and productive to me.

On Tue, Jul 12, 2022 at 6:26 AM Fung, Jason M 
mailto:jason.m.f...@intel.com>> wrote:
I agree with the proposed approach.  People just need to keep in mind that even 
definitions from Webster Dictionary (or substitute your favorite) are not liked 
by everyone. 

From: Alec J Summers mailto:asumm...@mitre.org>>
Sent: Monday, July 11, 2022 11:32 AM
To: Fung, Jason M mailto:jason.m.f...@intel.com>>; 
Hoole, Alexander 
mailto:alexander.ho...@microfocus.com>>; 
jw...@redhat.com<mailto:jw...@redhat.com>; Seifried, Kurt 
mailto:k...@seifried.org>>
Cc: CWE CAPEC Board 
mailto:cwe-capec-board-list@mitre.org>>
Subject: Re: [EXT] RE: Glossary

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 U

Re: [EXT] RE: Glossary

[SJ Jazz]

I'm OK with not further tweaking the definition of 'vulnerability'; yet
while providing updated definitions for 'weakness' and 'attack pattern', we
should also address associated definitions/descriptions of:

- Cyber-Enabled Capability
- Weakness Type
- Negative Technical Impact
- Exploit

When defining 'attack pattern', we should also address associated
definitions/descriptions of:

- Exploit
- Attack
- Meta Attack Pattern
- Standard Attack Pattern
- Detailed Attack Pattern

Yes, 'Exploit' is important to both Weakness and Attack Pattern.

With 'Weakness', using the currently available definition, I suggest:

1. We should avoid using 'mistake' in the definition and instead use 'flaw'
or 'defect' since a mistake might imply there was no intent to create the
flaw; yet a flaw or defect could have been inserted deliberately (as a
feature) without understanding the consequences of potential exploitability
or deliberately with malicious intent.  The existence of a 'flaw' or
'defect' and its exploitability potential is often independent of intent;
yet insertion of a flaw or defect might not be a mistake.

2. We might shorten "...made during the implementation, design, or other
phases of a product lifecycle..." to "...inserted during a product
lifecycle..." since a weakness could be inserted anytime, even after the
product is operational.

3. We might consider changing "...under the right conditions, could
contribute to the introduction of vulnerabilities in a range of products
made by different vendors" to "...if left unaddressed, could under the
proper conditions contribute to a cyber-enabled capability being vulnerable
to exploitation" since this better fulfills the reason we introduced the
concept of weakness vs vulnerability -- weaknesses can be source vectors of
future vulnerabilities, and they are not limited to 'products made by
different vendors'.

4. In providing a description of weakness, it would be useful to remind all
that a weakness represents a potential source vector for zero-day exploits
and zero-day vulnerabilities, and that it is the existence of an exploit
designed to take advantage of a weakness (or multiple weaknesses) and
achieve a negative technical impact is what makes a weakness a
vulnerability.


With 'Attack Pattern', using the currently available definition, I suggest:

1. We avoid using 'known weakness type' and just simply use 'weakness'
since it does not have to be publicly known to be subject to exploitation;
indeed, it is often the lesser known weaknesses that represent source
vectors for zero-day exploits.

2. We consider explicitly including 'exploit designed to take advantage of
a weakness' in the definition of an attack pattern


When I have available time, I will address the other terms.  In the
interim, I'd welcome comments and recommendations about the above comments.

Regards,

Joe Jarzombek
703 627-4644


On Tue, Jul 12, 2022 at 12:51 PM Jason Oberg  wrote:

> The proposed course of action sounds good to me.
>
> FWIW for the weakness definition, I'm still thrown off by the word
> "mistake" because a weakness could be introduced intentionally or by
> mistake.
>
> Of course we could debate definitions forever so your proposed approach to
> reach resolution sounds efficient and productive to me.
>
> On Tue, Jul 12, 2022 at 6:26 AM Fung, Jason M 
> wrote:
>
>> I agree with the proposed approach.  People just need to keep in mind
>> that even definitions from Webster Dictionary (or substitute your favorite)
>> are not liked by everyone. 
>>
>>
>>
>> *From:* Alec J Summers 
>> *Sent:* Monday, July 11, 2022 11:32 AM
>> *To:* Fung, Jason M ; Hoole, Alexander <
>> alexander.ho...@microfocus.com>; jw...@redhat.com; Seifried, Kurt <
>> k...@seifried.org>
>> *Cc:* CWE CAPEC Board 
>> *Subject:* Re: [EXT] RE: Glossary
>>
>>
>>
>> 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
>&g

Re: [EXT] RE: Glossary

[Jason Oberg]

The proposed course of action sounds good to me.

FWIW for the weakness definition, I'm still thrown off by the word
"mistake" because a weakness could be introduced intentionally or by
mistake.

Of course we could debate definitions forever so your proposed approach to
reach resolution sounds efficient and productive to me.

On Tue, Jul 12, 2022 at 6:26 AM Fung, Jason M 
wrote:

> I agree with the proposed approach.  People just need to keep in mind that
> even definitions from Webster Dictionary (or substitute your favorite) are
> not liked by everyone. 
>
>
>
> *From:* Alec J Summers 
> *Sent:* Monday, July 11, 2022 11:32 AM
> *To:* Fung, Jason M ; Hoole, Alexander <
> alexander.ho...@microfocus.com>; jw...@redhat.com; Seifried, Kurt <
> k...@seifried.org>
> *Cc:* CWE CAPEC Board 
> *Subject:* Re: [EXT] RE: Glossary
>
>
>
> 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 
> *Date: *Tuesday, May 31, 2022 at 1:33 PM
> *To: *Hoole, Alexander , jw...@redhat.com
> , Seifried, Kurt 
> *Cc: *Alec J Summers , 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 

RE: [EXT] RE: Glossary

[Fung, Jason M]

I agree with the proposed approach.  People just need to keep in mind that even 
definitions from Webster Dictionary (or substitute your favorite) are not liked 
by everyone. 

From: Alec J Summers 
Sent: Monday, July 11, 2022 11:32 AM
To: Fung, Jason M ; Hoole, Alexander 
; jw...@redhat.com; Seifried, Kurt 

Cc: CWE CAPEC Board 
Subject: Re: [EXT] RE: Glossary

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 mailto:jason.m.f...@intel.com>>
Date: Tuesday, May 31, 2022 at 1:33 PM
To: Hoole, Alexander 
mailto:alexander.ho...@microfocus.com>>, 
jw...@redhat.com<mailto:jw...@redhat.com> 
mailto:jw...@redhat.com>>, Seifried, Kurt 
mailto:k...@seifried.org>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>, CWE CAPEC 
Board mailto: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 
mailto:alexander.ho...@microfocus.com>>
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West mailto:jw...@redhat.com>>; Kurt Seifried 
mailto:k...@seifried.org>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>; CWE CAPEC 
Board mailto: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 typ

Re: [EXT] RE: Glossary

[Jeremy West]

On Mon, Jul 11, 2022 at 2:32 PM Alec J Summers  wrote:

> 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.
>

No objections from me. I appreciate the discussion.

>
>
> 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 
> *Date: *Tuesday, May 31, 2022 at 1:33 PM
> *To: *Hoole, Alexander , jw...@redhat.com
> , Seifried, Kurt 
> *Cc: *Alec J Summers , 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 
> *Sent:* Friday, May 27, 2022 6:39 PM
> *To:* Jeremy West ; Kurt Seifried 
> *Cc:* Alec J Summers ; 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):
>   1. A *bug *is an instance of a *flaw/fault/error/defect* in the
&

Re: [EXT] RE: Glossary

[Alec J Summers]

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 
Date: Tuesday, May 31, 2022 at 1:33 PM
To: Hoole, Alexander , jw...@redhat.com 
, Seifried, Kurt 
Cc: Alec J Summers , CWE CAPEC Board 

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 
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West ; Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

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

RE: [EXT] RE: Glossary

[Fung, Jason M]

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 
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West ; Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

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 
Sent: Tuesday, May 24, 2022 2:03 PM
To: Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

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 
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 
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 
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

Re: Glossary

[Jeremy West]

On Fri, May 27, 2022 at 9:54 PM Alexander Hoole <
alexander.ho...@microfocus.com> wrote:

> 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):
>   1. A * bug *is an instance of a *flaw/fault/error/defect* in the
>   design, development/implementation, or operation of a system.
>   2. 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).
>   3. 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*.
>   4. An * exploit *successfully results in a security failure through
>   one or more *vulnerabilities* which *does* exploit underlying
>   *weaknesses*.
>   5. 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*.
>
> I favor this approach.  The order, specifically, has a spectrum feel to it
and reduces the chance of differing opinions on the vulnerability term
(imho).


>
> 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).
>
> Good catch ... and I agree!


>
> 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 
> *Sent:* Tuesday, May 24, 2022 2:03 PM
> *To:* Kurt Seifried 
> *Cc:* Alec J Summers ; 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  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  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 
> wrote:
>
> Dear CWE/CAPEC Board Members,
>
>
>
> Good afternoon! I hope the week is going well for you all.
>
>
>
> Duri

Re: [EXT] Re: Glossary

[Jeremy West]

On Tue, May 24, 2022 at 4:32 PM Jason Oberg  wrote:

> Jeremy, welcome!
>
> I like the idea of defining a weakness wrt to a protection for an asset.
> The protection could have weaknesses because of mistakes, forgetfulness, or
> any other reason (e.g. environment). An asset-based definition fits really
> well for hardware and I think for a lot of software, but I'm wondering if
> that generalizes completely to all software?
>

More and more I'm seeing the term "offering" used, which may work better
than "asset".  That said, I don't think there's a silver bullet for
phrasing this.

>
> On Tue, May 24, 2022 at 1:15 PM Jeremy West  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 
>> 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 
>>
>> 314 Littleton Rd
>>
>> jw...@redhat.com
>> M: 9192686967 IM: hobbit
>> 
>>
>>
>>
>>
>
>
> --
>
>
> Dr. Jason Oberg | Co-Founder and CTO | +1 (808) 635-7604
>
> Tortuga Logic   |  75 E Santa Clara Street,
> San Jose, CA 95113
>
>
> NOTICE TO RECIPIENT | This email and any attachments may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please immediately notify
> the sender of the error by return email and delete this email and any
> attachments.
>
>

-- 

Jeremy West

Red Hat Product Security

Red Hat Massachusetts 

314 Littleton Rd

jw...@redhat.com
M: 9192686967 IM: hobbit

[EXT] RE: Glossary

[Alexander Hoole]

Just a quick correction… see below. Upon reflection, the example should not 
attribute an LDAP Entry Poisoning vuln (only JNDI Injection). An attack chain, 
which could include an LDAP Entry Poising vector (or more simply a maliciously 
controlled LDAP Server), could be part of a remote code execution exploit.
-A

From: Alexander Hoole
Sent: Friday, May 27, 2022 6:39 PM
To: Jeremy West ; Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

Subject: 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 mailto:jw...@redhat.com>>
Sent: Tuesday, May 24, 2022 2:03 PM
To: Kurt Seifried mailto:k...@seifried.org>>
Cc: Alec J Summers mailto:asumm...@mitre.org>>; CWE CAPEC 
Board mailto: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 
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 
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 
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 
import

[EXT] RE: Glossary

[Alexander Hoole]

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 
Sent: Tuesday, May 24, 2022 2:03 PM
To: Kurt Seifried 
Cc: Alec J Summers ; CWE CAPEC Board 

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 
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 
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 
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

Re: Glossary

[Jeremy West]

Correct Kurt.  Process is defined here as an executing process on the stack.

On Tue, May 24, 2022 at 5:01 PM Kurt Seifried  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  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 
>> 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 
>>
>> 314 Littleton Rd
>>
>> jw...@redhat.com
>> M: 9192686967 IM: hobbit
>> 
>>
>>
>>
>>
>
>
> --
> Kurt Seifried (He/Him)
> k...@seifried.org
>


-- 

Jeremy West

Red Hat Product Security

Red Hat Massachusetts 

314 Littleton Rd

jw...@redhat.com
M: 9192686967 IM: hobbit

Re: Glossary

[Kurt Seifried]

"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  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 
> 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 
>
> 314 Littleton Rd
>
> jw...@redhat.com
> M: 9192686967 IM: hobbit
> 
>
>
>
>


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

[EXT] Re: Glossary

[Jason Oberg]

Jeremy, welcome!

I like the idea of defining a weakness wrt to a protection for an asset.
The protection could have weaknesses because of mistakes, forgetfulness, or
any other reason (e.g. environment). An asset-based definition fits really
well for hardware and I think for a lot of software, but I'm wondering if
that generalizes completely to all software?

On Tue, May 24, 2022 at 1:15 PM Jeremy West  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 
> 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 
>
> 314 Littleton Rd
>
> jw...@redhat.com
> M: 9192686967 IM: hobbit
> 
>
>
>
>


-- 


Dr. Jason Oberg | Co-Founder and CTO | +1 (808) 635-7604

Tortuga Logic   |  75 E Santa Clara Street,
San Jose, CA 95113


NOTICE TO RECIPIENT | This email and any attachments may contain private,
confidential and privileged material for the sole use of the intended
recipient. If you are not the intended recipient, please immediately notify
the sender of the error by return email and delete this email and any
attachments.

[EXT] Re: Glossary

[Jason Oberg]

Hi Alec and all,

Happy to hear there is an initiative to help align these definitions. I
know it's a very common confusion point for many.

A couple of thoughts/comments from me:

   - In the weakness definition the word "mistake" throws me off a bit
   because that implies there was awareness of the issue and an intent to not
   make it. But many weaknesses appear just because individuals are completely
   unaware. I'm trying to think of another word, but what is on the CWE site I
   do like at first glance: "...flaws, faults, bugs, or other errors in
   software or hardware implementation, code, design, or architecture..."
   There's probably a compromise in there that's shorter...
   - I also think showing how Vulnerabilities, Weaknesses, and Attack
   Patterns relate to one another with a single picture would be really
   powerful and helpful for the community. I see the vulnerabilities as the
   focal point, with a set of weaknesses contributing to the vulnerability,
   and attack patterns forming how those weaknesses are exploited. So maybe a
   "funnel" with a vulnerability at the end, weaknesses spread across the
   input, and a cross section of attacks stringing those weaknesses together.
   We could surely debate the specific representation of this, but I do think
   a picture would be very helpful.

Regards,
Jason



On Tue, May 24, 2022 at 9:49 AM Alec J Summers  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™*
>
>
>
>
>


-- 


Dr. Jason Oberg | Co-Founder and CTO | +1 (808) 635-7604

Tortuga Logic   |  75 E Santa Clara Street,
San Jose, CA 95113


NOTICE TO RECIPIENT | This email and any attachments may contain private,
confidential and privileged material for the sole use of the intended
recipient. If you are not the intended recipient, please immediately notify
the sender of the error by return email and delete this email and any
attachments.

Re: Glossary

[Jeremy West]

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  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 

314 Littleton Rd

jw...@redhat.com
M: 9192686967 IM: hobbit

Glossary

[Alec J Summers]

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™




GAoB Glossary.xlsx
Description: GAoB Glossary.xlsx