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 <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 <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 <asumm...@mitre.org> >> *Sent:* Monday, July 11, 2022 11:32 AM >> *To:* Fung, Jason M <jason.m.f...@intel.com>; Hoole, Alexander < >> alexander.ho...@microfocus.com>; jw...@redhat.com; Seifried, Kurt < >> k...@seifried.org> >> *Cc:* CWE CAPEC Board <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 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 <jason.m.f...@intel.com> >> *Date: *Tuesday, May 31, 2022 at 1:33 PM >> *To: *Hoole, Alexander <alexander.ho...@microfocus.com>, jw...@redhat.com >> <jw...@redhat.com>, Seifried, Kurt <k...@seifried.org> >> *Cc: *Alec J Summers <asumm...@mitre.org>, 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 <alexander.ho...@microfocus.com> >> *Sent:* Friday, May 27, 2022 6:39 PM >> *To:* Jeremy West <jw...@redhat.com>; Kurt Seifried <k...@seifried.org> >> *Cc:* Alec J Summers <asumm...@mitre.org>; 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 >> 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 <jw...@redhat.com> >> *Sent:* Tuesday, May 24, 2022 2:03 PM >> *To:* Kurt Seifried <k...@seifried.org> >> *Cc:* Alec J Summers <asumm...@mitre.org>; 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 <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 <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 <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 >> 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 >> >> jw...@redhat.com >> M: 9192686967 IM: hobbit >> >> >> <https://red.ht/sig> >> >> >> <https://red.ht/sig> >> >> -- <https://red.ht/sig> >> >> Kurt Seifried (He/Him) >> k...@seifried.org <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> >> >> jw...@redhat.com >> M: 9192686967 IM: hobbit <https://red.ht/sig> >> >> [image: Image removed by sender.] <https://red.ht/sig> >> >> >> <https://red.ht/sig> >> >> >> > -- Regards, Joe Joe Jarzombek C 703 627-4644
