Addressing Product Security Bad Practices: CISA's Call to Action for Software Manufacturers

Ensuring the security of software products is not just a best practice—it’s a necessity!

CISA PUBLICATION: Product Security Bad Practices, October, 2024

In the ever-evolving world of technology, software plays a crucial role in powering critical infrastructure and essential services. However, the consequences can be far-reaching if security is overlooked during development. Recognizing this, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) have outlined key areas where software manufacturers often falter. These "product security bad practices" significantly increase risks to national security, public safety, and economic stability.

Why Security from the Start is Non-Negotiable

CISA’s Secure by Design initiative emphasizes that security must be prioritized from the very inception of software development. The idea is simple yet powerful: proactive security measures can prevent vulnerabilities and protect customers from malicious exploitation.

Software products are often used in critical contexts, from managing national utilities to securing financial systems. A single security flaw can cascade into devastating outcomes. Hence, software manufacturers are urged to avoid practices that compromise security and adopt recommendations to enhance product safety.

Categories of Product Security Bad Practices

The outlined bad practices are categorized into three main areas:

Product Properties: These relate to the observable security aspects of a software product, such as the programming languages used and input handling mechanisms.

• Development in Memory Unsafe Languages
• Inclusion of User-Provided Input in SQL Query Strings
• Inclusion of User-Provided Input in Operating System Command Strings
• Presence of Default Passwords
• Presence of Known Exploited Vulnerabilities
• Presence of Open Source Software with Known Exploitable Vulnerabilities

Security Features: These cover functionalities like multifactor authentication (MFA) and logging capabilities that support intrusion detection.

• Lack of Multifactor Authentication
• Lack of Capability to Gather Evidence of Intrusions

Organizational Processes and Policies: These include practices such as timely vulnerability reporting and maintaining transparency with customers.

• Failing to Publish Timely Common Vulnerabilities and Exposures (CVEs) with Common Weakness Enumerations (CWEs)
• Failing to Publish a Vulnerability Disclosure Policy

By understanding these categories, manufacturers can systematically address weaknesses and build more secure systems.

Common Product Security Bad Practices and Solutions

1. Development in Memory Unsafe Languages

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer:

https://cwe.mitre.org/data/definitions/119.html

Using memory-unsafe languages (e.g., C or C++) for new critical infrastructure or NCF products, when memory-safe alternatives exist, poses significant risks to national security, economic stability, and public safety.

Manufacturers are advised to: (1) Use memory-safe languages or technologies that prevent vulnerabilities in new products. (2) Publish a memory safety roadmap by January 1, 2026, unless the product's end-of-support is before January 1, 2030.

Memory unsafety refers to a scenario wherein a program can access or manipulate memory incorrectly. This can lead to various vulnerabilities, such as buffer overflows, use-after-free errors, and null pointer dereferences. Malicious actors can exploit these vulnerabilities to compromise software products, leading to severe consequences in critical sectors, including national security and public safety.

CWE-119, which outlines improper restriction of operations within the bounds of a memory buffer, is one of the critical weaknesses associated with memory-unsafe languages. According to OWASP, vulnerabilities related to buffer overflows are prevalent in C and C++ due to their manual memory management and lack of inherent safety features.

Exploit Scenarios

• Buffer Overflow in Network-Facing Code: An attacker could exploit a buffer overflow vulnerability in software that handles network communications, leading to unauthorized access or denial of service (DoS). This scenario underscores the critical importance of addressing vulnerabilities in network-facing code as outlined in memory safety roadmaps.
• Use-After-Free Vulnerabilities in Cryptographic Libraries: Flaws in memory management can lead to use-after-free vulnerabilities, particularly in code handling sensitive operations like cryptography. Attackers can leverage such weaknesses to intercept data or impersonate legitimate users, threatening both national security and individual privacy.
• Malicious Code Injection: Memory-unsafe languages are particularly vulnerable to code injection attacks. For instance, a vulnerability in a web application could allow an attacker to execute arbitrary code, potentially compromising user data and system integrity.

Key Elements of a Memory Safety Roadmap

1. Prioritized Code Assessment: Manufacturers should systematically assess code components, especially those related to network communication and sensitive functions, for memory safety vulnerabilities.
2. Adoption of Memory-Safe Languages: Where possible, transitioning to memory-safe languages or employing rigorous static analysis tools can significantly reduce the risk of memory safety vulnerabilities. Leverage hardware capabilities to prevent memory safety vulnerabilities actively.
3. Demonstrated Efforts:?Manufacturers must demonstrate their commitment to implementing the roadmap by providing a transparent account of their progress. This ensures accountability and fosters trust among stakeholders. The roadmap should prioritize eliminating vulnerabilities in critical code, such as network-facing or cryptographic operations, and aim to significantly reduce these vulnerabilities. Additionally, manufacturers must collaborate with industry standards organizations, government agencies, and the cybersecurity community to stay updated on best practices for ensuring software safety and security.

2. Inclusion of User-Provided Input in SQL Query Strings

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'):

https://cwe.mitre.org/data/definitions/89.html

The inclusion of user-provided input directly in the raw contents of a SQL database query string in products used in service of critical infrastructure or NCFs is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

Products should be built in a manner that systematically prevents the introduction of SQL injection vulnerabilities, such as by consistently enforcing the use of parametrized queries.

The Common Weakness Enumeration (CWE) identifies vulnerabilities that can lead to serious security issues. CWE-89, specifically, deals with SQL Injection, where user-provided input is included directly in SQL query strings. This vulnerability poses a significant threat, particularly when it involves critical infrastructure or national-critical functions (NCFs). The risks associated with SQL injection extend beyond unauthorized data access and can jeopardize national security, economic stability, and public health and safety.

Understanding SQL Injection

SQL Injection occurs when an attacker injects malicious SQL code into a query via user input fields, allowing them to manipulate the database unexpectedly. For instance, if a developer constructs a query like this:

SELECT * FROM users WHERE username = 'user_input';        

If user_input contains a strategically crafted string (e.g., admin' --), the resulting query becomes:

SELECT * FROM users WHERE username = 'admin' --';        

The use of -- comments out the rest of the SQL statement, potentially granting the attacker unauthorized access.

Example Attack Scenario:

• Craft Malicious Input: The attacker inputs a string like OR '1'='1', resulting in queries that fetch all records instead of the intended one.
• Access Sensitive Data: The attacker retrieves sensitive patient data, potentially compromising privacy and leading to severe ramifications for the involved individuals.
• Modify Data: The attacker could also alter critical health information, thus endangering patient care.

Exploits and Consequences:

Numerous high-profile incidents have highlighted the repercussions of SQL injection vulnerabilities:

• Equifax (2017): A SQL injection vulnerability in the web app led to the exposure of the personal information of over 147 million individuals, affecting national economic security and consumer confidence.
• Yahoo (2013-2014): SQL injections contributed to a breach that affected all 3 billion Yahoo accounts. This leak posed significant risks to national security by compromising state-related data and user accounts.

Given the sensitivity of data related to critical infrastructure, the stakes are even higher. Both public safety and national security can be compromised through exploitable vulnerabilities.

Recommended Actions

Organizations that develop or manage systems reliant on SQL databases must prioritize security measures to mitigate the risks associated with SQL injection. Here are some key recommendations:

• Parameterized Queries: Always use parameterized queries or prepared statements, which separate SQL code from data. This technique ensures that user input is treated as data rather than executable code, effectively preventing injection.

PreparedStatement ps = connection.prepareStatement("SELECT * FROM users WHERE username = ?");
ps.setString(1, user_input);        

• Input Validation: Implement robust input validation to ensure that only expected data types and formats can be processed by the system.
• Least Privilege Principle: Configure database accounts with the least privileges necessary to minimize the impact of an injected payload.
• Regular Security Audits: Conduct routine security assessments and code reviews to identify and remediate vulnerabilities before they can be exploited.
• Use of Web Application Firewalls: Deploy web application firewalls (WAFs) to monitor for and block SQL injection attempts.
• Training and Awareness: Provide comprehensive security training for developers to ensure they understand best practices for secure coding.

3. Inclusion of User-Provided Input in Operating System Command Strings

CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'):

https://cwe.mitre.org/data/definitions/78.html3.

The inclusion of user-provided input directly in the raw contents of an operating system command string in products used in service of critical infrastructure or NCFs is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

Software manufacturers should build products in a manner that systematically prevents command injection vulnerabilities, such as by consistently ensuring that command inputs are clearly delineated from the contents of a command itself.

The inclusion of user-provided input directly into operating system command strings—identified by the Common Weakness Enumeration (CWE) as CWE-78: Improper Neutralization of Special Elements Used in an OS Command ('Command Injection') - poses significant threats to an organization’s security. This risk is particularly pertinent in the context of critical infrastructure and national control frameworks (NCFs), where the repercussions of security vulnerabilities can extend to national security, economic stability, and public health and safety.

Understanding Command Injection Vulnerabilities

Command injection vulnerabilities arise when applications process untrusted input—often from users—without rigorous validation or sanitization. Attackers exploit this flaw by injecting arbitrary commands, leading to unauthorized access, data breaches, or system compromise. The critical nature of many systems in service of essential infrastructure means that even minor exploits can lead to catastrophic consequences.

Risk Scenarios:

• Unauthorized Access Control: A scenario may involve an application that accepts a service identifier from the user without validating it. An attacker can submit a malicious input that incorporates additional commands, leading to unauthorized access to sensitive system functionalities.
• Malicious Data Exfiltration: In another scenario, command injection might facilitate data exfiltration. This occurs when an attacker injects commands that redirect system output to an external server, leading to the leakage of sensitive information.
• Service Disruption: Command injection can also be used to disrupt services. Attackers can craft inputs that lead to high-level resource consumption, effectively initiating denial-of-service scenarios that degrade the availability of critical systems.
• Privilege Escalation: Another risk involves attackers executing commands that escalate their privileges. If an application runs with high-level permissions, it may allow attackers to manipulate system-level actions, install malicious software, or change configurations.

Recommended Actions

To mitigate the risks associated with command injection vulnerabilities, particularly in critical infrastructure, software manufacturers must adopt systematic measures:

1. Input Validation and Sanitization: Applications should rigorously validate and sanitize all user inputs. Using a whitelist approach that defines acceptable input formats can significantly minimize risks.
2. Use of Parameterized Commands: Wherever feasible, developers should utilize parameterized commands or APIs that separate user input from command logic. This practice reduces the chances of malicious inputs being executed.
3. Contextual Escaping: Implementing contextual escaping mechanisms ensures that any user input that might interfere with command execution is correctly escaped, rendering the input harmless.
4. Comprehensive Logging and Monitoring: Implementing real-time logging and monitoring of command executions can help detect unauthorized attempts and provide insights necessary for response and recovery actions.
5. Security Testing and Code Reviews: Adopting rigorous security testing methods and peer code reviews focused on identifying security vulnerabilities are essential practices for ensuring robust security against command injection attacks.

4. Presence of Default Passwords

CWE-1392: Use of Default Credentials:

https://cwe.mitre.org/data/definitions/1392.html

CWE-1393: Use of Default Password:

https://cwe.mitre.org/data/definitions/1393.html

The use of default passwords in products for critical infrastructure or National Critical Functions (NCFs) poses significant risks to national security, economic stability, and public safety.

Provide random, unique initial passwords for each product instance. Require users to create strong passwords during installation. Use time-limited setup passwords that disable after setup and enforce secure authentication. Require physical access for initial setup with unique credential configuration. Transition existing deployments to secure authentication through updates or campaigns.

The presence of default passwords in software and hardware devices represents a significant security vulnerability, particularly in the context of critical infrastructure and national cyber systems. The Common Weakness Enumeration (CWE) identifiers CWE-1392 and CWE-1393 highlight two specific weaknesses associated with default credentials. CWE-1392 involves using the same default password across multiple instances of a product, while CWE-1393 refers to providing default passwords that are both commonly known and shared across products.

Default passwords are dangerous for several reasons:

1. Widespread Availability: Default passwords are often documented in user manuals and available online, making them easy targets for attackers.
2. Lack of Accountability: When multiple systems share the same default password, it becomes difficult to trace unauthorized access back to a specific instance.
3. Weak Security Practices: Organizations that do not modify default passwords demonstrate poor security hygiene, exposing themselves to potential breaches.

Several incidents highlight the threat posed by default passwords:

• Mirai Botnet (2016): One of the most notorious examples of default password exploits was the Mirai botnet. The malware primarily affected IoT devices, many of which had default passwords. The botnet exploited these vulnerabilities to launch massive distributed denial-of-service (DDoS) attacks, hijacking hundreds of thousands of devices, leading to widespread service outages.
• Ubiquiti Networks Breach (2015): A significant security breach occurred when attackers exploited default credentials in Ubiquiti network devices. This incident compromised sensitive user data and led to financial losses for the company.

These examples illustrate how default passwords can be exploited to compromise systems, leading to severe economic repercussions and potentially hazardous consequences for public safety.

To mitigate the risks associated with default passwords, software manufacturers and organizations should adopt robust security practices, such as:

1. Instance-Unique Initial Passwords: Manufacturers should implement random, instance-unique passwords that differ for each product instance.
2. Strong Password Creation at Installation: Require users to create a strong, unique password during the installation process.
3. Time-Limited Setup Passwords: Introduce temporary passwords that expire once the setup is complete, necessitating the creation of a secure password afterward.
4. Physical Access Requirements: Mandate that physical access is required for the initial setup, ensuring only authorized personnel can configure the system.
5. Transitioning Existing Deployments: Conduct campaigns to update existing systems, moving them from default passwords to more secure authentication methods, including multifactor authentication (MFA) that resists phishing attacks.

5. Presence of Known Exploited Vulnerabilities

Known Exploited Vulnerabilities (KEV) Catalog:

https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Software manufacturers should patch all known exploited vulnerabilities within software components prior to release. In the case of the publication of a new KEV on CISA’s catalog, the manufacturer should issue a patch at no cost to its users in a timely manner (under no circumstances longer than 30 days) and clearly warn users of the associated risks of not installing the patch.

The CISA’s Known Exploited Vulnerabilities Catalog comprises vulnerabilities that have been actively exploited by attackers in the wild. These vulnerabilities are indicators of weaknesses that, if left unaddressed, could be leveraged maliciously—compromising systems, exfiltrating data, and disrupting services. Given their critical nature, software developers must be vigilant in addressing such vulnerabilities both before and after product deployment.

Risk Scenarios:

Pre-release Vulnerability Inclusion

• Scenario: A software product designed for a municipal water system inadvertently integrates a third-party library containing a KEV. The product goes live, and attackers exploit the vulnerability to gain access to the system.

Post-release Vulnerability Discovery

• Scenario: After a product’s release, a KEV is reported affecting its components. The manufacturer delays providing a patch, leaving users vulnerable to potential exploitation.

Miscommunication on Exploitability

• Scenario: A manufacturer claims that a newly identified KEV is not exploitable within their product due to the function being dormant. However, an attacker discovers a way to invoke the function predictably, leading to a breach.

Recommended Actions for Software Manufacturers:

Preemptive Patching: Manufacturers should ensure that all known exploited vulnerabilities are patched before the product is released. Implementing rigorous security assessments during the development phase can help in identifying and addressing these vulnerabilities.

Timely Patch Issuance Post-Release: In the event a new KEV is listed in CISA’s catalog after the product’s release, manufacturers must issue patches at no cost to users. The timeline for patch delivery should not exceed 30 days. This proactive approach not only protects users but also reinforces the manufacturer's commitment to security.

Transparent Documentation: If a manufacturer believes that a KEV is not exploitable within their product, they must publicly document that assessment. This communication should clearly explain the reasoning behind the exploitability assessment to maintain user trust and provide assurance around their product's security posture.

Risk Awareness Communication: Regularly inform users about known vulnerabilities and the necessity of implementing patches. Clear communication channels help ensure that end-users remain aware of potential risks and security best practices.

6. Presence of Open Source Software with Known Exploitable Vulnerabilities

Software manufacturers should responsibly consume and sustainably contribute to the open source software that they depend on. This includes making a reasonable effort to evaluate and secure their open source software dependencies.

The integration of open source software (OSS) components into products servicing critical infrastructure or national security functions poses significant risks, particularly when those components contain known exploitable vulnerabilities at the time of release. The danger intensifies if new vulnerabilities are disclosed post-release and the product lacks timely patches or mitigations.

To mitigate these risks, software manufacturers are urged to practice responsible consumption and contribution to OSS. Key recommended actions include:

1. Software Bill of Materials (SBOM): Maintain a comprehensive SBOM that details all software dependencies, both open source and proprietary, and provide this transparency to customers.
2. Security Management Process: Establish a clear process for incorporating OSS, ensuring security scanning tools evaluate all chosen software and its dependencies.
3. Selecting Reputable Projects: Choose well-maintained OSS projects and contribute to their upkeep when feasible, ensuring sustained quality and security.
4. Evaluating Alternatives: Identify and select OSS options that are the most secure and well-maintained.
5. Adhering to Best Practices: Download OSS components only from trusted package repositories that comply with security best practices.
6. Continuous Monitoring: Regularly check for Common Vulnerabilities and Exposures (CVEs) and other security alerts related to all OSS dependencies, applying necessary updates promptly.
7. Caching Dependencies: Store copies of OSS within internal build systems instead of updating directly from unverified external sources.
8. Business Planning: Include the costs of updating major OSS dependencies in business planning to ensure they receive necessary security fixes during the product's lifecycle.

7. Lack of Multifactor Authentication

Software manufacturers should either support MFA natively in the product or support in the baseline version of the product the use of an external identity provider, such as via single sign on. Require MFA for administrators.

MFA is a security mechanism that requires users to provide two or more verification factors to gain access to a system. This typically includes combinations of something the user knows (password), something the user has (smartphone, security token), and something the user is (biometric verification). By adding layers of security, MFA significantly reduces the likelihood of unauthorized access.

The lack of MFA creates numerous attack vectors for cybercriminals:

• Brute Force Attacks: Without MFA, once an attacker acquires a username and password, they can repeatedly attempt to gain access until successful.
• Phishing Attacks: Cybercriminals often use deceptive emails to harvest credentials. MFA could potentially mitigate the impact of successful phishing attempts.
• Credential Stuffing: Attackers utilize stolen username and password databases to gain access to multiple accounts across different platforms, making MFA crucial in preventing unauthorized entry.

Given the dangers posed by products that do not support MFA, especially in critical infrastructures (NCFs), it is essential to adopt stringent security measures.

1. Native MFA Support: Software manufacturers should integrate MFA capabilities in their products. By enabling MFA as a default feature, companies can reduce the risks of account compromise significantly.
2. External Identity Provider Integration: For products that do not handle authentication internally, they should at least allow integration with external identity providers supporting MFA. This ensures that even without native MFA, users can secure their accounts through other means.
3. Mandatory MFA for Administrator Accounts: All administrative accounts, which have elevated privileges, should be required to use MFA by default. This will create a robust barrier against attacks aimed at gaining control of critical systems.

The deadline of January 1, 2026, signifies a crucial turning point for security practices in critical infrastructure. Software manufacturers that do not adopt MFA for administrator accounts or fail to offer other secure authentication methods will significantly elevate national risks. Exceptions for products with an announced end-of-support date before January 1, 2028, may permit some legacy systems to operate temporarily; however, pressing for modernization is vital to ensure security.

8. Lack of Capability to Gather Evidence of Intrusions

As part of the baseline version of a product, software manufacturers should make logs available in an industry-standard format. For cloud service providers and SaaS products, software manufacturers should retain logs for a set timeframe (at least 6 months) at no additional charge.

For products used in service of critical infrastructure or NCFs, it is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety to not provide customers with artifacts and capabilities in the baseline version of the product sufficient to gather evidence of common forms of intrusions affecting the product, which at a minimum includes:

• Configuration changes or reading configuration settings;
• Identity (e.g., sign-in and token creation) and network flows, if applicable; and
• Data access or creation of business-relevant data.

Recommended action:

• As part of the baseline version of a product, software manufacturers should make logs available in an industry-standard format related to, at minimum, the above listed areas.
• For cloud service providers and SaaS products, software manufacturers should retain logs for a set timeframe (at least 6 months) at no additional charge.

9. Failing to Publish Timely CVEs with CWEs

Software manufacturers should publish complete CVEs, including the appropriate CWE field, in a timely manner for all critical or high impact vulnerabilities.

For products used in service of critical infrastructure or NCFs, it is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety for the software manufacturer to not issue CVEs in a timely manner for, at minimum, all critical or high impact vulnerabilities (whether discovered internally or by a third party). Additionally, it is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety to not include the CWE field in every CVE record.

Recommended action:?Software manufacturers should publish complete CVEs, including the appropriate CWE field, in a timely manner for all critical or high impact vulnerabilities.

10. Failing to Publish a Vulnerability Disclosure Policy

Software manufacturers should remediate all valid reported vulnerabilities in a timely and risk-prioritized manner.

For products used in service of critical infrastructure or NCFs, not having a published vulnerability disclosure policy (VDP) that includes the product in its scope is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.

Recommended actions:

• Software manufacturers should publish a VDP that:
• Authorizes testing by members of the public on products offered by the manufacturer;
• Commits to not recommending or pursuing legal action against anyone engaging in good faith efforts to follow the VDP,
• Provides a clear channel to report vulnerabilities; and
• Allows for public disclosure of vulnerabilities in line with coordinated vulnerability disclosure (CVD) best practices and international standards.
• Software manufacturers should remediate all valid reported vulnerabilities in a timely and risk-prioritized manner.

Resources:

The Case for Memory Safe Roadmaps, CISA Secure by Design Pledge (Reducing Classes of Vulnerability)

Back to The Building Blocks,?NIST Secure Software Development Framework (SSDF) PW 6.1.

CISA Secure by Design Pledge (Reducing Classes of Vulnerability), SSDF PW.5.1,?CISA SQL Injection Secure by Design Alert.

CISA Secure by Design Pledge (Default Passwords), SSDF PW.9.1, CISA Default Passwords Secure by Design Alert.

CISA Secure by Design Pledge (Security Patches), SSDF PW.4.4, Binding Operational Directive 22-01

SSDF PW.4.4, ESF Recommended Practices for Managing Open Source Software and Software Bill of Materials, TODO Group Open Source Program Office (OSPO) Definition and Guide

CISA Secure by Design Pledge (Multi-Factor Authentication), SSDF PW.9.

CISA Secure by Design Pledge (Evidence of Intrusions)

CISA Secure by Design Pledge (CVEs), SSDF RV.1.3.

CISA Secure by Design Pledge (Vulnerability Disclosure Policy), SSDF RV.1.3, ISO 29147.

Product Security Bad Practices - 508c, https://www.cisa.gov/sites/default/files/2024-10/joint-guidance-product-security-bad-practices-508c.pdf

Neven Dujmovic, January 2025

#CISA #security #SecureByDesign #software #DataProtection #privacy #SecurityByDesign #CyberSecurity