Thank you for the thoughtful suggestion – and happy new year! CWE may be able to do something to help better formalize and label issues related to “insecure default”.
There are a few ways CWE could address the suggestion and I encourage more feedback from the community on how best to proceed. There may be an opportunity to restructure some related weaknesses under a new class-level weakness, although it may be difficult to do so without overlapping existing entries. CWE aims to minimize overlap." Cheers, Alec -- Alec J. Summers Cyber Security Engineer, Principal Group Lead, Cybersecurity Operations and Integration Center for Securing the Homeland (CSH) –––––––––––––––––––––––––––––––––––– MITRE - Solving Problems for a Safer World™ From: Andy Murren <amur...@ieee.org> Date: Wednesday, January 3, 2024 at 2:17 PM To: dwhee...@linuxfoundation.org <dwhee...@linuxfoundation.org>, CWE Research Discussion <cwe-research-list@mitre.org> Cc: Michael Scovetta <michael.scove...@microsoft.com>, Michael Winser <micha...@xwind.io> Subject: Re: [EXT] Proposal: Add "Insecure default" as a general CWE category (per "Secure-by-design" paper) I concur with David's proposal and rational. Software needs to be secure by design and by default. I have done security assessments on hundreds of systems and almost none have been securely configured unless the default settings were secure I concur with David's proposal and rational. Software needs to be secure by design and by default. I have done security assessments on hundreds of systems and almost none have been securely configured unless the default settings were secure and the user didn't intentionally change the setting to disable security to make it "more usable". Andy Murren Cyber Security Engineer, Sila Solutions Group On 1/3/24 13:51, David A. Wheeler wrote: > I propose that CWE add "Insecure default" as a *general* category of > vulnerabilities, instead of only covering a few special cases as it > does now. Here's my rationale. The paper "Secure-by-Design: Shifting > the Balance of Cybersecurity Risk: > > I propose that CWE add "Insecure default" as a *general* category of > vulnerabilities, > instead of only covering a few special cases as it does now. Here's my > rationale. > > The paper "Secure-by-Design: Shifting the Balance of Cybersecurity Risk: > Principles and Approaches for Secure by Design Software" (revised > October 25, 2023) was > published by US CISA and 17 U.S. and international partners > (including those in the UK, Norway, Korea, Japan, & many others). > This "joint guidance urges software manufacturers to take urgent steps > necessary to ship products that > are secure by design and revamp their design and development programs > to permit only > secure by design products to be shipped to customers." > > Their rationale is simple: Most developers and users do *NOT* > specially configure software > to make software secure; most accept the defaults. Some manufacturers release > "hardening guides", but they're completely ineffective. As noted in the paper, > "Relying on hardening guides simply does not scale". > You can see their October 2023 version here: > * <https://www.cisa.gov/resources-tools/resources/secure-by-design> > * > <https://www.cisa.gov/sites/default/files/2023-10/SecureByDesign_1025_508c.pdf> > > I believe this paper represents a broad consensus among governments that > software that is insecure by default is *NOT* secure, even if it is > theoretically > possible to "configure it into being secure". > > Today, many programs & libraries have vulnerabilities by default that > are *not* fundamentally > necessary for their proper operation. Unfortunately, CVE assignments > are usually rejected for those cases because it's theoretically > possible to use them securely. > E.g., many XML parsers are vulnerable by default to external entity > injection (XXE), but CVEs > aren't assigned in these situations because they're safe to use as > long as every developer > worldwide performs heroic extra efforts to secure the thousands of > components they reuse. > That rarely happens, so security rarely happens. The current situation > means that there is *no* incentive for developers of programs & libraries to > make their software secure by default, *and* there's no mechanism for > developers & users to separately learn that the default use is insecure. > > CWE does have a large number of specialized cases of "insecure default". > However, as far as I can tell, nothing covers the general case. > Examples of specific cases are: > > * CWE-1188: Initialization of a Resource with an Insecure Default > * CWE-1394: Use of Default Cryptographic Key > * CWE-1393: Use of Default Password > * CWE-276: Incorrect Default Permissions > * CWE-453: Insecure Default Variable Initialization > * CWE-798: Use of Hard-coded Credentials > * CWE-665: Improper Initialization (this is a little bit of a stretch) > * CWE-1221: Incorrect Register Defaults or Module Parameters (this is > hardware not software) > > What's needed is a *general* CWE covering "not secure by default" cases. > > This is somewhat related to OWASP Top 10 A05, Security Misconfiguration > <https://owasp.org/Top10/A05_2021-Security_Misconfiguration/>. > Misconfiguration is less likely if the default is secure. > It's also related to OpenSSF's Alpha-Omega, which is working to > improve the security of open source software (OSS) projects (which is where > this discussion came up). > > As always, the devil is in the details. For example, > I'd be willing to accept the definition as one that only covered cases > where it's > theoretically *possible* for it to be configured to be > secure-by-default (e.g., it's not possible for strcpy() > to be secure by default from memory corruption, so it cannot ever be > secure by default). > An interface that "cannot be made safe to use" does seem different > than "insecure by default > but theoretically possible to configure into being secure". I'm sure > there will be many discussions. > > That said, the first step is to acknowledge that "insecure by default" *IS* a > security vulnerability & specifically label it as a category of vulnerability. > People can then work to carefully define it & come to a general consensus. > > Anyway, I hope you find this idea helpful. Thank you! > > --- David A. Wheeler > Director of Open Source Supply Chain Security, The Linux Foundation
