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<mailto: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<mailto:sjoeja...@gmail.com>> Date: Thursday, July 14, 2022 at 1:13 PM To: Rob Wissmann <rob.wissm...@nteligen.com<mailto:rob.wissm...@nteligen.com>> Cc: Alec J Summers <asumm...@mitre.org<mailto:asumm...@mitre.org>>, CWE Research Discussion <cwe-research-list@mitre.org<mailto: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<mailto: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<mailto:asumm...@mitre.org>> Sent: Wednesday, July 13, 2022 1:09 PM To: CWE Research Discussion <cwe-research-list@mitre.org<mailto: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
