The NSA calls for software developers to fix memory safety issues: Why should credit unions care?

Cybersecurity leaders and solution vendors have made progress developing and implementing solutions across enterprises to combat malware and the bad guys who deliver it. But blind spots remain, and they leave gaping holes in the security infrastructure everywhere, including at credit unions. The National Security Agency’s (NSA) recognition of one significant blind spot, software memory, focuses attention on the need for software developers to fix the “in-memory vulnerabilities” in almost all deployed software.

For the NSA, that guidance calls for a strategic shift: “Memory issues in software comprise a large portion of the exploitable vulnerabilities in existence. NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, to a memory safe language when possible. By using memory safe languages and available code hardening defenses, many memory vulnerabilities can be prevented, mitigated, or made very difficult for cyber actors to exploit,” the NSA concludes.

To see NSA’s detailed recommendations, go here NSA SOFTWARE MEMORY SAFETY.

Will software developers take heed and act? Can they? Given the billions of lines of code written and deployed, can we expect to see the NSA’s call to action prompt wholesale change? Probably not. Certainly not any time soon. And this means we all remain vulnerable to the significant risks in-memory software weaknesses expose us to.

So, if the NSA’s call to action is a “heavy lift”, why is it still impactful? And why should credit unions care? Because it “calls out” a collective failure.

A September 2021 CUInsight article focused on the need to combat credit unions’ overconfidence regarding cybersecurity (How to combat cyber confidence that undermines security). It referenced credit union security leaders’ confidence in their security posture, compared it to other security professionals’ confidence, as reported by others, raised concerns about the relative gap and the rosy picture painted by credit unions.

“One particularly interesting finding to come out of this research project has been the confidence of credit union leaders in their cybersecurity programs. Overwhelmingly, 71% feel confident they are fully protected and 92% feel they were never breached. However, among non-credit union business leaders, just 16% feel prepared.” – Chris Sache, Think|Stack.

It went on from there to discuss the security risk posed by overconfidence and suggested that we needed to focus more on “achievement” or resolution to the problems and less on “activity” focused on security audit completion.

While one might choose to argue with the article’s premise, it’s important to recognize that there are segments of our cybersecurity efforts that are questioned too little, including the acceptance of significant risk from not addressing in-memory application security flaws, as well as other risks posed by blind spots found in application software. And software memory safety issues, and those other application software blind spots, are both a BIG DEAL, and a big reason for the continued growth in malware, ransomware and other cyberattacks that drain resources and compromise organizations. Our collective failure to understand and act upon these security blind spots has allowed bad actors to continue their successful attacks. And we remain at risk.

As Brad LaPorte, a long-time EPP veteran and recent Gartner Senior Analyst, writes “Cybercriminals are now able to secretly bypass modernized security solutions like Next-Generation Antivirus, Application Control, Endpoint Protection Platforms (EPP), and Endpoint Detection and Response (EDR). Worse yet, cybersecurity vendors are aware of this devastating tactic but are keeping quiet about it. They are not able to stop it and that is a serious threat to their viability (and yours). Attackers are able to sneak into corporate networks by hiding INSIDE APPLICATIONS, where ALL endpoint security products are blind to what is executing behind the scenes. It’s time we all focus on fixing this.”

It’s this critical need to focus on fixing this problem that makes the NSA’s declaration so important. In its publication the NSA focused on both the size of the problem and on how to mitigate common software memory safety issues that expose organizations to the kinds of remote code execution that enable the largest and most damaging types of malware attacks. The NSA’s recognition of this problem with software memory, and of the failure of in-market cybersecurity vendors and practitioners to solve for it, publicizes how critical it is for us to collectively implement a solution.

We must take note. And we must find a path forward. We can’t wait for software developers. And we can’t count on current in-market cybersecurity vendors to solve for it. Look again at what Brad LaPorte says about cybersecurity vendors.

Why is it important to recognize the problem? Successful cyberattacks damage organizations and their clients and customers. Global research shows that organizations are losing the cybersecurity fight. Organizations across the globe are spending well over $120 billion a year on cybersecurity products and services, yet Ponemon Institute’s IBM sponsored study showed that organizations’ ability to contain cyberattacks have declined by 13% over just the past five years. Failing to prevent malware intrusion, and then failing to contain the damage done, has led to a rapid rise in both the number of data breaches and the costs to repair the damage – much of which is never repaired fully.

Unfortunately, the NSA’s recommendations are only directed toward software developers, and don’t pretend to offer actionable advice for the rest of us, including credit unions. To learn how NSA’s recommendations fall short, and what we must do to address “in-memory security weakness”, and to address other application security blind spots, I reached out to a security expert I know to be working to solve the problem.

NSA is right to focus on software memory insecurity. Consultants and cybersecurity solution developers I spoke with said the NSA is right to recognize that most software in use today suffers from memory operation vulnerabilities that open the door to remote code execution that drives cyber-attacks, attacks that few if any security solutions identify before damage is done. And they believe the NSA’s published guidance on how organizations can implement protections against these common software memory safety issues is an important contribution because Microsoft and other software developers blame them for 70% of their bugs.

But in talking with software security experts, I learned there are problems with the guidance. According to TJ Tajalli, CEO of OnSystem Logic and a long-tenured software development security expert, “it’s not possible to rewrite billions of lines of code, that are the foundation of software in use today, using memory safe languages. Technologies like Control Flow Guard (CFG) and Address Space Layout Randomization (ASLR) have been around for years but have limitations and published methods for being defeated. In fact, Microsoft and Google have been using these technologies for many years in their own software, but still issue immediate security patches for most of their memory safety bugs.”

For Mr. Tajalli and others, the NSA’s guidance, while useful for some, isn’t actionable for most organizations. “The NSA focuses on fixing or replacing the software used across organizations, along with application security testing; but how many of us”, asks Mr. Tajalli, “are capable of repairing, rewriting or swapping out software throughout the organization — especially when there are few good options available?”

So where do we go? What can we do? The NSA’s recognition of the problem provides a great service because the problem remains unresolved, and its impact is growing. We all should promote the move toward the use of programming languages that don’t inherently open the door to these vulnerabilities; but few of us are positioned to make wholesale changes to the software we run, at least in the near term, and we are under attack NOW. So, if rewriting software and implementing wholesale changes to the software environments we have today is not the answer we need NOW, what are other options?

For Mr. Tajalli, the quest for a solution consumes his time. “The most important thing to do to mitigate a memory safety bug is to make sure that the bug cannot be used by an adversary to run code that is under its control AND can perform useful operations on the system. What I mean by useful operations is any type of operation that gives the adversary the ability to access important resources in the affected software. For example, the ability of the adversary to create dynamic code in the software under attack. There are operations like this that apply to all software and others that apply to specific software.

So, if we learn the internal deterministic access patterns to these resources within EVERY piece of software running on a system, we can protect EVERY piece of software from adverse effects of memory software bugs without having access to source code, rewriting the software, caring about what language it is written in, or how it was compiled. These protections can work side by side with CFG, ASLR, etc. but do not require them or any other processor specific security features, that may or may not be present, to implement CFG, ASLR, etc. The learning can be done in the QA environment of the software maker and/or from customer machines that have deployed this capability to protect their servers and workstations.”

Looking for solutions that address this problem? The cybersecurity world may finally be realizing how important memory and endpoint application software protection is when defending against malware. For credit unions, the first step is to understand fully what’s at risk, and then to determine where to find in-market solutions that address the problem.