[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). 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,
 …).

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 of mistake made during the implementation, design, or other