We’ve already seen this recently with the re-evaluation of CWEs related to password complexity and other password-related policies. Last year, some of our cryptography entries were modified to better allow for the fact that something that’s safe today might not be tomorrow.
- Steve From: Kurt Seifried <k...@seifried.org> Sent: Thursday, July 14, 2022 2:45 PM To: Hatfield, Arthur <arthur_hatfi...@homedepot.com> Cc: Jarzombek, Joe <sjoeja...@gmail.com>; Wissmann, Rob <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://www.google.com/url?q=https://urldefense.com/v3/__https:/www.cve.org/About/Process*CVERecordLifecycle__;Iw!!M-nmYVHPHQ!NfnLPvDdkiRWH3L2xvMa9KYle-CdclOb75YztG_5ExXRad3d_EIacRd2LMB8bBeLbczXRpgZviQ46Vn0fy3hmNg21w$&source=gmail-imap&ust=1658424336000000&usg=AOvVaw2SeZfZHtLqix20ioUiz44s>: “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
