Memory safety vulnerabilities continue to plague ICS: Here’s what to do about it
Memory safety vulnerabilities have been around for decades, and yet they remain a persistent issue, particularly within industrial control systems (ICS). In the last few years, memory safety vulnerabilities within ICS have seen a steady upward trend, jumping from around 2,000 reported CVEs in 2020 to over 3,000 CVEs reported in 2022 alone.
The trend itself isn't surprising — more embedded systems means more software means more bugs. However, what is cause for concern is the severity of the threat to critical infrastructure. As many as 70% of memory safety vulnerabilities are scored high or critical and can lead to remote execution and data theft. ICS is particularly susceptible because of the widespread use of C /C++ coding languages, which are not inherently memory-safe.
The reality has caught the attention of government agencies and regulatory bodies worldwide. In 2022, the National Security Agency (NSA) issued an advisory urging the adoption of memory-safe languages and the Cybersecurity and Infrastructure Security Agency (CISA) in the U.S. has been advocating "Secure by Design" practices. In the EU, one of the key provisions of the Cyber Resilience Act is the requirement for accurate and complete Software Bills of Materials (SBOMs), which offer crucial visibility into potential vulnerabilities.
Challenges in Implementation: Why Memory Safety Remains a Problem
While the guidance from agencies like NSA and CISA, as well as regulations such as the EU Cyber Resilience Act, provide a roadmap for improving security, the implementation of these recommendations faces several hurdles:
1) Limited ecosystem support: Many embedded devices lack support for memory-safe languages on their operating systems or processors.
2) Developer shortage: There's a scarcity of developers proficient in memory-safe languages like Rust or Go-Lang.
3) Ecosystem limitations: While Rust and Go-Lang are gaining traction, they don't yet offer the same level of ubiquity and compatibility as C and C++ in embedded environments.
4) Time constraints: The process of migrating existing codebases to memory-safe languages is time-consuming. Some device manufacturers estimate it could take up to 15 years to fully transition their current products to memory-safe alternatives and deploy them in the field.
5) Infrequent updates: ICS environments are complex and typically receive updates infrequently, further prolonging the transition process.
Transitioning to memory safe language is the ideal end state, but it will take time to get there. Meanwhile, Volt Typhoon and other threat actors are actively exploiting memory safety vulnerabilities now. The question becomes: What can be done now to defend existing memory unsafe code bases?
Implementing RASP to Mitigate Memory Safety Vulnerabilities
Unlike traditional enterprise IT environments, where network intrusion detection systems can be readily deployed, ICS environments require a different approach. Runtime Application Self Protection (RASP) offers a promising solution for the embedded ICS space. RASP techniques harden software binaries so that attackers can't calculate in advance how to successfully execute their code. The result is a device that is capable of defending itself, even if there are known vulnerabilities within the code, and the ability to prevent an entire class of attacks related to memory safety.
Promisingly for ICS systems, RASP technology can be integrated directly into devices, protecting the system at runtime and actively monitoring and defending against potential attacks as they occur. This is achieved without having to rewrite any code and while introducing limited overhead.
Future Outlook
Memory safety vulnerabilities continue to pose a significant threat to industrial control systems, but there are ways to address the problem through transitioning to memory-safe languages, implementing secure-by-design principles, maintaining accurate SBOMs, and deploying RASP technology as a vital stopgap measure.
RASP, in particular, makes it possible to strengthen ICS today, future proofing against attacks long after a device has been fielded.
