We've also seen the steady move from "everything turned on by default", e.g. 2001 guidance: https://seifried.org/lasg/network/
It is advisable to disable as many services in inetd.conf as possible, typically the only ones in use will be ftp, pop and imap. Telnet and r services should be replaced with SSH and services like systat/netstat and finger give away far to much information. to "only SSH, if you want it". We've been consistently telling people to harden stuff/disable things for 20+ years.. maybe it's time to treat that as a problem and CWE/CVE it. On Wed, Jan 3, 2024 at 11:53 AM David A. Wheeler < [email protected]> 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: > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message originates outside of MITRE. If you feel this is suspicious, > please report it via "Report Suspicious Email" button in Outlook. > > ZjQcmQRYFpfptBannerEnd > > 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 > > -- Kurt Seifried (He/Him) [email protected]
