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

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

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>>, 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 types define logical groupings of bugs which share 
similar properties