There's another aspect: legislated vulnerabilities/weaknesses. E.g. https://www.enforcementtracker.com/ there are lots of examples, e.g.:
https://www.enforcementtracker.com/ETid-1091 Emailing data in an unencrypted format, now ignoring the fact it may well have been encrypted in transit, I assume they want end to end encryption, now we have CWE-311: Missing Encryption of Sensitive Data but for example, there is no distinction between encryption of data end to end, in transit between email systems/over the Internet, etc. So while you specifically may not care, GDPR cares, and it's clear (if you search the fines database) that this is a pretty common failure scenario, for for example, I would suggest we start breaking up protection mechanisms between end to end and all the other possibilities where applicable. On Fri, Jul 15, 2022 at 8:22 AM Rob Wissmann <rob.wissm...@nteligen.com> wrote: > Kurt Seifried’s point is very interesting because it makes clear that the > shift in classification from “perfectly acceptable feature” to “flaw and > weakness” to “vulnerability” is a based on the perspective of the observer. > > > > Said another way, “flaw”, “weakness” and “vulnerability” are subjective > classifications not objective classifications. An objectivist point of view > would say, “an exploit for a flaw either can exist or cannot, therefore it > is objectively knowable whether a flaw is a vulnerability.” This point of > view precludes saying a flaw *might* be exploitable but we don’t know > yet, obviating the need for the term weakness. > > > > Consider the question “Is this buffer overflow a vulnerability?” The > objectivist perspective requires abstaining from an answer until the issue > can be proved one way or another. To answer “maybe” is to classify that > buffer overflow as a weakness, which it cannot be since an exploit either > can exist or cannot. The objectivist take on vulnerability is not very > useful definition to most of us because it’s usually impossible or at least > impractical for any observer to have the perfect knowledge it requires. > Considering Kurt’s point, that perfect knowledge might even have to extend > into the future! Further, when the cost of a full investigation into a flaw > is high and mitigation costs are low or risk aversion is high, there is > value in answering “maybe.” That’s why the term “weakness” exists. > > > > The definitions of weakness and vulnerability should explicitly consider > the observer’s frame of reference to clear up that these terms are to be > used subjectively. > > > > Vulnerability: A flaw … accepted by the observer, their community, or the > public to be exploitable … > > Weakness: A flaw … not accepted by the observer, their community, or the > public to be exploitable but accepted to be potentially exploitable … > > > > Circling back, the term flaw is subjective as well – today’s features may > come to be regarded as tomorrows flaws – which is a little bit of an issue > with the vulnerability and weakness definitions. But these versions of the > definitions do a good job implying what is meant by flaw: features that are > accepted to be exploitable or potentially exploitable. It also helps > protect from the “changes with time” issue since what is accepted to be > exploitable or potentially so necessarily changes with time. > > > > Thanks > > > > *From:* Kurt Seifried <k...@seifried.org> > *Sent:* Thursday, July 14, 2022 2:45 PM > *To:* Hatfield, Arthur <arthur_hatfi...@homedepot.com> > *Cc:* SJ Jazz <sjoeja...@gmail.com>; Rob Wissmann < > rob.wissm...@nteligen.com>; Alec J Summers <asumm...@mitre.org>; CWE > Research Discussion <cwe-research-list@mitre.org> > *Subject:* Re: CWE/CAPEC Definitions > > > > There’s also changes in standards, expectations and so on. 20 years ago > 2FA was exotic, now it’s common place and in 20 more years I bet lack of > 2FA is classed as a vulnerability. > > > > -Kurt > > > > > > > > > > > > On Jul 14, 2022, at 11:25 AM, Hatfield, Arthur < > arthur_hatfi...@homedepot.com> wrote: > > > > I think it may be best to split the difference by describing weaknesses as > flaws that are *potentially* exploitable to cause undesired operation of > the system and describing vulnerabilities as the subset of weaknesses that > are *provably* exploitable; that allows the possibility that some > exploits are either extant but not generally known to exist, or would exist > if someone applied themselves to finding an exploit technique. > > > > > > *RT Hatfield**, BS CS, CCITP, CISSP* > > Staff Cybersecurity Analyst > > Lead, Notifications and Operations Service Line > > Cyber Threat Intelligence > > *The Home Depot* > > > > > > > > *From: *SJ Jazz <sjoeja...@gmail.com> > *Date: *Thursday, July 14, 2022 at 1:13 PM > *To: *Rob Wissmann <rob.wissm...@nteligen.com> > *Cc: *Alec J Summers <asumm...@mitre.org>, CWE Research Discussion < > cwe-research-list@mitre.org> > *Subject: *[EXTERNAL] Re: CWE/CAPEC Definitions > > Actually, being listed as a CVE is not the criteria for being a > vulnerability. Only vulnerabilities catalogued as CVEs are 'known > vulnerabilities'. There are actual instances of uncatalogued (unpublished) > vulnerabilities; some are in proprietary or intelligence organization's > libraries, and some are held by malicious actors for future exploitation > (at which point they will be known as zero-day vulnerabilities). > > > > It is the existence of an exploit designed to take advantage of a weakness > (or multiple weaknesses) and achieve a negative technical impact that makes > a weakness a vulnerability. > > > > It is not the state of being publicly known or catalogued that makes it a > vulnerability. > > > > ...Joe > > > > > > > > On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann <rob.wissm...@nteligen.com> > wrote: > > Regarding the circular definitions, it has always struck me that > weaknesses are flaws that *may or may not* be exploitable to cause > negative impact whereas vulnerabilities are flaws *known* to be > exploitable to cause negative impact. > > > > A rewrite of the definitions to match this concept: > > > > *Vulnerability* > > *A flaw in a software, firmware, hardware, or service component known to > be exploitable to cause a negative impact to the confidentiality, > integrity, or availability of an impacted component or components (from > CVE®)* > > *Weakness* > > *A flaw in a software, firmware, hardware, or service component that may > or may not be exploitable to cause a negative impact to the > confidentiality, integrity, or availability of an impacted component or > components.* > > > > Vulnerabilities must be known to be exploitable because of the CVE > criteria [cve.org] > <https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fwww.google.com%2Furl%3Fq%3Dhttps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.cve.org%2FAbout%2FProcess*CVERecordLifecycle__%3BIw!!M-nmYVHPHQ!NfnLPvDdkiRWH3L2xvMa9KYle-CdclOb75YztG_5ExXRad3d_EIacRd2LMB8bBeLbczXRpgZviQ46Vn0fy3hmNg21w%24%26source%3Dgmail-imap%26ust%3D1658424336000000%26usg%3DAOvVaw2SeZfZHtLqix20ioUiz44s&data=05%7C01%7Crob.wissmann%40nteligen.com%7C3994a9af3a144525f62e08da65c8ec46%7C379c214c5c944e86a6062d047675f02a%7C0%7C0%7C637934210899094804%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KniqieE7Gy1Bw1AFYrec%2FAbsYdM%2FMS6K2LC09T3Ekls%3D&reserved=0>: > “Details include but are not limited to affected product(s); affected or > fixed product versions; vulnerability type, root cause, or impact; and at > least one public reference.” > > > > An example of a flaw that may or may not be a vulnerability is an integer > overflow. It might result in a vulnerability, or it might not. That’s a > weakness. > > > > Thanks > > > > *From:* Alec J Summers <asumm...@mitre.org> > *Sent:* Wednesday, July 13, 2022 1:09 PM > *To:* CWE Research Discussion <cwe-research-list@mitre.org> > *Subject:* CWE/CAPEC Definitions > > > > Dear CWE Research Community, > > > > I hope this email finds you well. > > > > Over the past few months, the CWE/CAPEC User Experience Working Group has > been working to modernize our programs through a variety of activities. One > such activity is harmonizing the definitions on our sites for some of our > key terminology including weakness, vulnerability, and attack pattern. As > CWE and CAPEC were developed separately and on a different timeline, some > of the terms are not defined similarly, and we want to address that. > > > > We are seeking feedback on our working definitions: > > > > *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 (from CVE®)* > > *Weakness* > > *A type of flaw or defect inserted during 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 > weakness, usually in cyber-enabled capabilities* > > > > *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after > significant community deliberation, and we are not looking to change it at > this time. > > > > We are hoping to publish new, improved definitions on our websites at the > end of the month. Please provide thoughts and comments by Tuesday, July 26. > > > > 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™* > > > > > > > > > -- > > Regards, > > > > Joe > > > > Joe Jarzombek > > C 703 627-4644 > > > > INTERNAL USE > > -- Kurt Seifried (He/Him) k...@seifried.org
