CISA's Product Security Bad Practices: Implications for OT/ICS

On October 16, 2024, the Cybersecurity and Infrastructure Security Agency (CISA), in collaboration with the Federal Bureau of Investigation (FBI), released its Product Security Bad Practices guidance as part of its Secure by Design initiative. The set of guidelines highlights practices deemed exceptionally risky for software manufacturers, particularly those serving critical infrastructure. By addressing key security weaknesses and prioritizing secure development practices, CISA intends to encourage the broader software industry to enhance product safety and customer trust.

While CISA’s guidance targets product security practices used in Operational Technology (OT) and Industrial Control Systems (ICS), the IoT domain is uniquely complex, and security challenges in this ecosystem must be addressed on multiple fronts.

This is the first blog in a three-part mini-series that will explore bad practices in OT/ICS and across the broader IoT ecosystem, including cloud-based management portals, mobile applications, and backend systems. As an industry, we must consider device-level vulnerabilities and ecosystem-wide security practices.

Bad Practices According to CISA

CISA groups its guidance into three primary categories: Product properties, Security features, and Organizational processes and policies. Below, we’ll overview what each covers and provide our take on the effectiveness of the guidance. 

Product Properties

Development in Memory Unsafe Languages

• CISA’s guideline → Using memory-unsafe languages like C or C++ for new products when safer alternatives exist represents a significant security risk. Memory safety vulnerabilities are a major source of exploitable security flaws that can compromise entire systems. For existing products, CISA requires the publication of a memory safety roadmap by January 2026, demonstrating how manufacturers will address these vulnerabilities in priority code components.
• Finite State’s Verdict: Developing firmware for IoT devices using memory-unsafe languages like C/C++ exposes them to vulnerabilities, particularly because these devices are often directly exposed to the physical environment and rely on constrained resources. Exploiting a memory vulnerability in an embedded system can provide attackers access to the device’s functionality or data. Developing memory-safe languages seems quite reasonable, especially considering the adoption of compiled, memory-safe languages such as Rust.

Inclusion of User-Provided Input in SQL Query Strings

• CISA’s Guidance: Including user input directly in SQL query strings creates dangerous opportunities for SQL injection attacks. These vulnerabilities can allow attackers to manipulate database queries, potentially compromising entire databases. To mitigate this risk, manufacturers must implement parameterized queries to systematically prevent SQL injection vulnerabilities.

• Finite State’s Verdict: Embedded systems with a built-in web server or management interface must avoid directly using user inputs in SQL queries, as SQL injection can compromise configuration data. At first glance, this seems reasonable to accomplish. Still, within the scope of IoT hardware devices, it is very unlikely that any sort of SQL database is used due to the paucity of processing cycles and limited system memory.

Inclusion of User-Provided Input in Operating System Command Strings

• CISA’s Guidance: The practice of including user input directly in operating system command strings poses severe security risks. This vulnerability enables command injection attacks that could compromise system security at the operating system level. Manufacturers must implement clear delineation between command inputs and command content to prevent these vulnerabilities.
• Finite State’s Verdict: For IoT devices that provide a local command-line interface or an embedded API, including unsanitized user inputs in command strings can lead to command injection, allowing complete control over the device. This one is an absolute must!  In similar fashion to SQL injection attacks, I can’t believe that in 2024, this still has to be part of the conversation. This has been the bread and butter for adversaries on hardware devices. This was the exact method used to start the whole OpenWRT hacking scene.

Presence of Default Passwords

• CISA’s Guidance: Releasing products with universal default passwords creates significant security risks by making systems easily compromisable through widely known credentials. Manufacturers must implement more secure approaches, such as requiring unique initial passwords, mandating user-set passwords during setup, implementing time-limited setup passwords, or requiring physical access for initial setup.

• Finite State’s Verdict: Default passwords on IoT devices represent a critical risk, as such devices are often deployed in various locations with limited security oversight. Default credentials are an easy entry point for attackers. This one is nearly a must-do, and it is one of the few things that can have such an impact, with a simple switch to a force of password change on first use/install. Enforcing unique, strong passwords upon initial setup is critical.

Presence of Known Exploited Vulnerabilities

• CISA’s Guidance: Releasing products with known exploitable vulnerabilities or failing to patch them quickly exposes systems to active exploitation. Manufacturers must patch vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog within 30 days and clearly document any vulnerabilities that aren't exploitable in their implementation.

• Finite State’s Verdict: Using components with known vulnerabilities puts the entire device at risk, which is particularly problematic if the device is critical infrastructure. This risk is amplified by the difficulty of performing timely updates on embedded systems. Here is where vulnerability scanning is really helpful, but is really only addressing the problem with the final firmware to be delivered to the customer. Operationalizing SBOMs enriched with CVEs and threat intelligence as part of the CI/CD pipeline (i.e., from start to finish) makes this one very doable. Add some reasonably rapid patching policies here, and this is a win.

Presence of Open Source Software with Known Exploitable Vulnerabilities

• CISA’s Guidance: Using open-source components with known exploitable vulnerabilities introduces significant security risks into products. Manufacturers must maintain a software bill of materials (SBOM), carefully evaluate dependencies, monitor for CVEs, and cache dependencies internally. They should also contribute to the maintenance of the open source projects they depend on.
• Finite State’s Verdict: Many embedded systems use open-source libraries for efficiency, but including libraries with known vulnerabilities can compromise device integrity. It's crucial to maintain updated versions of these libraries. Again, here is where vulnerability scanning is really helpful, but is really only addressing the problem with final firmware to be delivered to the customer. Operationalizing SBOMs enriched with CVEs and threat intelligence as part of the CI/CD pipeline (i.e., from start to finish) makes this one very doable. Add some reasonably rapid patching policies here, and this is a win.

Security Features

Lack of Multifactor Authentication

• CISA’s Guidance: Not supporting multi-factor authentication in the baseline product version significantly weakens security, as single-factor authentication is more easily compromised. By January 2026, products must enable MFA by default for administrator accounts. This requirement reflects the growing recognition that password-only authentication is insufficient for protecting critical systems.
• Finite State’s Verdict: Many IoT devices have web-based management interfaces where MFA could provide an added security layer, particularly for critical device settings. Unfortunately, regardless of industry, MFA on local interfaces for IoT is unheard of.  This is likely due to the difficult nature of MFA implementation by the average user. On the OT/ICS front with more sophisticated implementers, many devices don’t even feature the ability to implement MFA outside of connected management platforms. This is something that the industry needs to change.

Lack of Capability to Gather Evidence of Intrusions

• CISA’s Guidance: Products that don't provide adequate capability to gather evidence of common intrusions hamper incident detection and response. Manufacturers must implement logging for configuration changes, identity and network flows, and data access in standard formats. For cloud and SaaS products, these logs must be retained for at least six months at no additional charge.
• Finite State’s Verdict: Intrusions into IoT devices often leave minimal trace due to a lack of logging capabilities. Enhancing logging in devices provides data points for understanding breaches. This one is quite hard to implement, largely due to the lack of strenuous logging facilities. OT/ICS arguably does a better job here due to the critical nature of the devices and the need to support off-system logging.

Organizational Processes and Policies

Failing to Publish Timely CVEs with CWEs

• CISA’s Guidance: Failing to publish timely CVEs with CWEs for critical or high-impact vulnerabilities prevents organizations from properly assessing and addressing risks. Manufacturers must promptly publish complete CVEs that include CWE fields, ensuring transparency about security vulnerabilities and enabling organizations to make informed decisions about risk management.
• Finite State’s Verdict: Embedded device manufacturers must disclose vulnerabilities to allow customers to take mitigating actions promptly. This one should be easy to accomplish with the development of programs or the adoption of bug bounty programs.  Unfortunately, many manufacturers are reluctant to adopt bug bounty programs or make it easy to report (and therefore few disclosures) for fear that they become a target for hacking with little ability to respond in a timely fashion.

Failing to Publish a Vulnerability Disclosure Policy

• CISA’s Guidance: The absence of a published vulnerability disclosure policy inhibits the discovery and reporting of security issues. Manufacturers must publish policies that authorize public testing, provide clear reporting channels, and commit to not pursuing legal action against good faith security research efforts. This policy should align with coordinated vulnerability disclosure best practices and international standards.
• Finite State’s Verdict: The lack of a clear VDP for embedded systems makes it difficult for researchers to report vulnerabilities, leading to longer exposure times for critical flaws. This is arguably an issue with the IoT/OT/ICS and many other industries and is something simple and fundamental that can be fixed. This will require commitment from organizations to provide timely responses to submissions. This should be easy to both publish and support a VDP.

Putting it All Together

CISA's Product Security Bad Practices guidance represents a significant milestone in addressing security challenges within Operational Technology (OT) and Industrial Control Systems (ICS) environments. The guidance provides a clear roadmap for manufacturers and operators to enhance their security posture.

Key takeaways:

1. Technical Evolution is Essential: The push toward memory-safe languages like Rust signals a fundamental shift in how industrial systems should be developed, prioritizing security from the ground up.
2. Basic Security Practices Cannot Be Overlooked: Despite the complexity of OT/ICS environments, fundamental security measures such as eliminating default passwords and implementing proper input validation remain critical.
3. Vulnerability Management Must Be Systematic: The emphasis on timely patching (30-day window), comprehensive SBOMs, and proper vulnerability disclosure policies demonstrates the need for systematic approaches to security maintenance.
4. Balance Between Security and Operational Constraints: The guidance acknowledges the unique challenges of OT/ICS environments while pushing for necessary security improvements, particularly in areas like MFA implementation and logging capabilities.

Looking ahead, this guidance sets new standards for the industry while recognizing that securing OT/ICS environments requires a multi-faceted approach that considers both technical capabilities and operational realities. As organizations work to implement these recommendations, the focus should be on creating sustainable, long-term security improvements that protect critical infrastructure while maintaining operational efficiency.