As part of the National Cybersecurity Strategy, the White House issued a call to action for software developers to prioritize the use of memory-safe programming languages in their code to mitigate vulnerabilities. This initiative presents a significant challenge, particularly for organizations with legacy or critical infrastructure applications that cannot easily be rewritten. To address this security gap, the Virsec Security Platform (VSP) offers a proactive cybersecurity solution to safeguard workloads, even in instances where the application is not written in a memory-safe language or when patches are not readily available.
What Is A Memory-Safe Language?
Memory-safe languages are designed to prevent common programming mistakes related to memory management. They often use type safety capabilities that define and enforce safety considerations through the compiler and at runtime.
For example, the compiler can detect instances where a null pointer is dereferenced. The compiler also inserts artifacts in the code that allow runtime detection of memory unsafe operations, such as performing reads beyond the buffer boundary. Sometimes, the code can trigger an application crash rather than perform an insecure operation such as “leak” adjacent data. In other cases, the application may facilitate input data to be “converted” to code (aka Remote Code Execution, aka RCE). This weakness allows the Threat Actor to gain the ability to execute arbitrary malicious code.
Some examples of Memory-Safe Languages include Rust, Go, C#, Java, Python, etc.
Top 25 Most Dangerous Software Errors: Several software cyber security organizations in the US publish details on the TOP 25 Most Dangerous Software Errors. One such report coming from the Sans Institute enumerates the following top 25 errors:
As evidenced by this table, by deploying apps written in memory-safe languages, five of the Top 25 Most Dangerous Software Errors (highlighted in green) will no longer be an issue. Many of the remaining 20 most dangerous software errors are typically found in web applications.
Regarding legacy or critical infrastructure apps, most software has very little to no web components. As a result, a very significant percentage of dangerous software errors will be eliminated.
Reality Check #1: Unfortunately, many legacy or critical infrastructure apps are very old and cannot be changed quickly without a major upheaval. Replacing millions of lines of code with code written in memory-safe languages can be a major task that can take years.
Reality Check #2: A vast majority of the critical infrastructure code runs on highly constrained hardware (including CPUs and Memory). The consequence of this constraint is that modern memory-safe languages such as Java and Python cannot be implemented on such hardware. Unfortunately, code written in C/ C++ is here to stay for a long time until all enterprises decide to upgrade their control systems to modern hardware that can run memory-safe code.
Reality Check #3: Despite using Memory Safe languages, some bugs allow cleverly manipulated input data to turn to “code” at run time. How can one protect the underlying infrastructure despite such RCE vulnerabilities?
Reality Check #4: Even when patches are available for vulnerable code, many enterprises delay deploying because patching affects business continuity. Then, there is the issue of zero-day vulnerabilities. A recent analysis of CISA KEVs shows that for 40% of the KEVs, the date of mass exploitation precedes the date of the vulnerability announcement. The only explanation for this phenomenon is that the Threat Actors were aware of the vulnerability before its announcement and before an Enterprise could deploy a publicly available patch.
In the face of adversity, what can organizations do? Code written in memory unsafe languages and older hardware that runs such code are not going away anytime soon. The same goes for vulnerabilities - no matter how much software analysis is done, vulnerabilities will always find their way into the code. It is unrealistic to expect that vulnerabilities can be completely eliminated. Patching is a failed strategy, especially since 40% of vulnerabilities are exploited before the patch is even available. These are realities that cannot be avoided, no matter how much effort is put into it.
Enterprises must proactively safeguard themselves, even in scenarios where code is written in memory-unsafe languages or when patches are unavailable. It is imperative for organizations to have cybersecurity measures in place that can effectively thwart the Threat Actor's ability to exploit vulnerabilities, whether known or unknown, to execute "malicious" code in support of their nefarious intentions.
Fortunately, the Virsec Security Platform (VSP), which implements a Default-Deny-Allow-On-Trust strategy, can prevent a code of dubious trust (aka provenance) from executing even one instruction. When malicious code cannot execute, it cannot unleash a breach, and there is no recovery time or cost. This approach is the only reasonable way to deal with the realities the organization is faced with.
Summary: The Virsec Security Platform (VSP) compensates for known and unknown vulnerabilities that help Threat Actors execute malicious code, extract confidential data, and hold Enterprises to ransom. VSP protects unconditionally, even if the Threat Actor has access to stolen credentials and has “insider” access to the workload.
To learn more about the Virsec Security Platform (VSP), visit www.virsec.com
Don't miss our security insights, and subscribe to our blog now.
