On Mon, Jul 11, 2022 at 2:32 PM Alec J Summers <[email protected]> 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 <[email protected]> > *Date: *Tuesday, May 31, 2022 at 1:33 PM > *To: *Hoole, Alexander <[email protected]>, [email protected] > <[email protected]>, Seifried, Kurt <[email protected]> > *Cc: *Alec J Summers <[email protected]>, CWE CAPEC Board < > [email protected]> > *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 <[email protected]> > *Sent:* Friday, May 27, 2022 6:39 PM > *To:* Jeremy West <[email protected]>; Kurt Seifried <[email protected]> > *Cc:* Alec J Summers <[email protected]>; CWE CAPEC Board < > [email protected]> > *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 > 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*. > > 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 <[email protected]> > *Sent:* Tuesday, May 24, 2022 2:03 PM > *To:* Kurt Seifried <[email protected]> > *Cc:* Alec J Summers <[email protected]>; CWE CAPEC Board < > [email protected]> > *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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > wrote: > > Dear CWE/CAPEC Board Members, > > > > Good afternoon! I hope the week is going well for you all. > > > > During a recent CWE/CAPEC User Experience Working Group session, the topic > of definitions came up – more specifically, the difficulty in agreeing on > good ones and making sure they are understood by downstream users. It also > reminded me of Pietro’s comment during our February meeting, I believe, on > the importance of harmonious definitions for similar terms across the CVE > and CWE/CAPEC sites. To that end, the team went ahead and did a quick > document authorities search of our key terminology to start (i.e., > vulnerability, weakness, attack pattern), and suggested the following: > > > > *Term* > > *Definition* > > *Authority* > > *Authorities Doc* > > *Vulnerability* > > *A flaw in a software, firmware, hardware, or service component resulting > from a weakness that can be exploited, causing a negative impact to the > confidentiality, integrity, or availability of an impacted component or > components. (not changed)* > > *CVE* > > *website* > > *Weakness* > > *A type of mistake made during the implementation, design, or other phases > of a product lifecycle that, under the right conditions, could contribute > to the introduction of vulnerabilities in a range of products made by > different vendors.* > > *n/a* > > *edited from def on CWE wesbite* > > *Attack Pattern* > > *The common approach and attributes related to the exploitation of a known > weakness type, usually in cyber-enabled capabilities * > > *n/a* > > *edited from def on CAPEC website* > > > > > > The full spreadsheet of definitions to compare is attached. The plan would > be to unify the definitions according to the above across all our sites. > Would love to hear your thoughts. > > > > Cheers, > > Alec > > > > -- > > *Alec J. Summers* > > Center for Securing the Homeland (CSH) > > Cyber Security Engineer, Principal > > Group Lead, Cybersecurity Operations and Integration > > *––––––––––––––––––––––––––––––––––––* > > *MITRE - Solving Problems for a Safer World™* > > > > > > > > > -- > > *Jeremy West* > > Red Hat Product Security > > Red Hat Massachusetts <https://www.redhat.com> > > 314 Littleton Rd > > [email protected] > M: 9192686967 IM: hobbit > > > <https://red.ht/sig> > > > <https://red.ht/sig> > > -- <https://red.ht/sig> > > Kurt Seifried (He/Him) > [email protected] <https://red.ht/sig> > > > <https://red.ht/sig> > > -- <https://red.ht/sig> > > *Jeremy West <https://red.ht/sig>* > > Red Hat Product Security <https://red.ht/sig> > > Red Hat Massachusetts <https://red.ht/sig> > > 314 Littleton Rd <https://red.ht/sig> > > [email protected] > M: 9192686967 IM: hobbit <https://red.ht/sig> > > [image: Image removed by sender.] <https://red.ht/sig> > > > <https://red.ht/sig> > > > -- Jeremy West Red Hat Product Security Red Hat Massachusetts <https://www.redhat.com> 314 Littleton Rd [email protected] M: 9192686967 IM: hobbit <https://red.ht/sig>
