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 <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> > > > <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> > > -- <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> > > <https://red.ht/sig> > > <https://red.ht/sig> > > > <https://red.ht/sig> > > <https://red.ht/sig> > -- 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>
