Rethinking Software and Risk to Protect the Public Sector

Our current approach to cybersecurity, specifically within the public sector, is not working. We continue to spend more and more money on this issue across all industries, as evident in the fact that we have spent $173 billion on cybersecurity in 2020, twice the amount we spent just 10 years ago, while our losses continue to increase and currently surpass $1 trillion.

Rather than accept this trend as inevitable, we should rethink our approach to software and build security into the foundation of programs, instead of adding it in as an afterthought and subsequently risking the nation’s most sensitive data. The current approach of utilizing firewalls, antivirus and other mitigations, while important, does not substantially affect the economics of cybercrime. Therefore, we must focus on reducing the number of vulnerabilities in software if we are to defend federal agencies against potential attacks.

It’s best to think of malware as a business—whether it is implemented by criminals or state adversaries—with business-like incentives and disincentives. Budgets are always limited and there must be a return on the adversary’s investment. 

To raise attacker costs, one must consider the lifecycle of malware: delivery, exploitation and finally, the attack. If any of these phases can be disrupted, we can have a greater chance of defending federal software and data. Delivery and attack are, however, largely at the discretion of the attacker, making them difficult for defenders to affect. That leaves exploitation, which involves the finding and exploiting of software or system weaknesses. This step is dependent on vulnerabilities, or rather, bugs in the security controls, which are under the complete control of the software developers.

Much of today’s efforts have been focused on threat mitigations which, while they do not remove bugs, attempt to make them unexploitable. It’s like treating the symptoms of a disease rather than the cause. This does provide some measure of protection but is not enough, for once an attacker learns how to bypass a mitigation, that same bypass can be reused repeatedly, increasing the attacker’s profit. Instead, we should focus on the architecture of today’s computer software systems, the majority of which are still based on decades-old software-development practices that leave too much open to attack. 

One example of a critical systematic architectural flaw is known as ambient authority, a defect that greatly impacts user security and affects many, if not all software programs. Such a flaw can be explained in the case of running a program on a computer to view a PDF file. When a user runs a program to view a PDF, the program does not just receive permission to read the file. Rather, the program gains access to all of the user’s permissions, not just the few needed to view the document. If an attacker were to find a vulnerability within the PDF reader, the attacker could reprogram the software to perform any action the user could perform. This creates a tremendous security gap and exposes the user and agency to a plethora of potential risks.   

It seems like a daunting task, but if we are to overcome today’s hostile threat environment, software systems must be written to isolate authority to a small part of the program. In the case of a PDF viewer, this would involve isolating the parts of the program that interact with the operating system from the parts that interpret a PDF. The PDF-specific code can then be run in a way that only has permissions to interact with the remaining parts of the program but not the operating system. This PDF-specific code will be the majority of code in the program. With the majority of code now isolated away from authority, there are far fewer bugs for attackers to abuse, drastically reducing the number of bugs that can be considered vulnerabilities. 

As the world continues to increase in complexity, adversaries are taking advantage and extracting more value and becoming increasingly hostile against the public sector, putting the rest of the nation at tremendous risk and danger. Only when applications are written with security as the foundation of the platform, and not just as an accessory, will we stand a chance to reduce the attacker value and the endless threats.

Jonathan Moore is the chief technology officer at SpiderOak.