Over the past decade, the role of software in the federal government has evolved from something that increased operational efficiency or made life easier, to completely mission-critical to agencies and military organizations. Software is key to federal digital transformation initiatives, it’s integral to many government processes and operations, and it’s even finding its way into our military’s next-generation weapons platforms and vehicles.
With software playing such a large role in today’s government, it goes without saying that securing those applications is increasingly imperative. Software vulnerabilities remain some of the most exploited vulnerabilities by malicious actors. And, with today’s outsized reliance on applications, an exploited software vulnerability could be catastrophic for a government agency.
To learn more about the increased role of software in the government, the importance of application security, and how the DevOps revolution could make software more secure, we recently sat down with Wias Issa, the CEO of Ubiq Security, whose solutions help developers integrate encryption directly into their applications with a “Security as Code” approach during the development process.
During our discussion, we talked about some real-life examples of application security gone wrong, the reasons why application security is essential, and why the way we embrace data encryption needs to change if we’re going to truly protect data from those that would seek to steal it. Here is what Wias had to say:
GovDevSecOpsHub (GDSOH): How has the role of software changed in the federal government over the past decade? How mission-critical are applications to civilian agencies? Military organizations?
Wias Issa: The short of it is, to call [software] mission-critical is probably an understatement. Government agencies – whether federal civilian, state and local, or even some branches of the military – every mission is now powered by software. It can be something that services the warfighter to something that maintains records for the DMV in small towns across the country.
Software is bringing a lot of efficiency, and enabling these organizations to deliver on their mission, but it also creates vulnerabilities and exposes them to a lot of risk. As the world is becoming increasingly connected, the government has been trailing quite a bit with application security – especially on the federal civilian, and the state and local government side.
GDSOH: In this new, more software and network-enabled age, how important is application security?
Wias Issa: It’s critical. According to Palo Alto, of all published vulnerabilities in the past five years, 76 percent were from applications. This has put massive pressure on companies to fix those application vulnerabilities and it’s driven a lot of new technology firms to emerge that are focused on embedding security within software application development processes.
Application development starts with the engineering teams. It flows from the idea, to initial requirements, and ultimately application development. The more you can build security into that process, the better off you are. As the process plays out – as you get further along in the application development process – every issue that you find has an exponentially higher impact. The earlier you find the problem in the process, the easier it is to fix and the smaller the impact, helping you avoid sometimes catastrophic findings later in the development process.
GDSOH: Do you have any examples of major government or private sector breaches that were a result of poor application security? How were they perpetrated?
Wias Issa: Honestly, the majority are typically tied to some kind of application vulnerability. Equifax is a great example to highlight. The initial attack vector was an internet-facing application and the attackers there exploited a widely known vulnerability that should have been patched, but due to a process failure on their end, remained present.
Another great example is Capital One, which actually considers itself more of a technology company than a financial services company. For them, specifically, there was a security tool – a Web application firewall (WAF) – that had more permissions than it should have. The malicious actor weaponized this authorized system – that was designed to defend the organization – to get into Capital One’s infrastructure, specifically a database hosted in AWS, and obtained the personal information of over 100 million people. The type of vulnerability that the actor exploited is a well-known method called a “Server-Side Request Forgery” attack, in which the WAF was essentially tricked into running commands that it should never have been permitted to run
If you’re looking for a government example – you tend not to hear about many of them due to national security concerns – but a great example is the OPM breach. That happened over half a decade ago and is arguably the largest publicly known breach of government systems in our country’s history.
In every one of these situations – all three examples – the underlying data was either not encrypted or the attack vector enabled the attacker to decrypt sensitive data. Since the inception of major encryption tooling nearly 3 decades ago, they have been predominantly focused on encryption data at the storage layer. The challenge with relying on storage layer encryption is that it doesn’t have an understanding of the core functionality of the application it’s serving. That’s why we firmly believe that building encryption directly into the application layer, significantly improves an organization’s threat model and enables a more consistent and robust encryption strategy that is entirely independent from the storage layer.
The application is the point of inception of data, it’s the one handling identity and access management, and yet we’re relying on the storage layer – which has no knowledge or in-depth intelligence into what the application is doing, the purpose, or the business value. If you up-level encryption from the storage layer into the application layer, now you’re empowering the application layer to determine when something should be encrypted or decrypted.
GDSOH: How can the evolution of DevOps and DevSecOps help make applications more secure? What impact can a different approach to application development have on security?
Wias Issa: DevOps and DevSecOps are some of the best things to have happened in our space in a while. Prior to DevOps, there was often friction between releasing new features and stability. Development teams were measured on the features and updates they’d, deliver while the operations team was measured on the health and availability of systems. About 15 years ago, you saw the emergence of dedicated security teams that joined the party and created even more friction.
Nowadays, DevOps has become the connective tissue or bridge between engineering and operations. Reducing tension, enabling faster deployment times, less failures, and closer collaboration. And DevSecOps is enabling the introduction of security even earlier in the software development process.
As I mentioned earlier, when you don’t address a security vulnerability or poor code as early as possible in the application development process, every day that goes by after its deployment makes trying to fix the problem exponentially harder. It has an increased business impact and engineering lift – the amount of resources that need to be mobilized and will be impacted by the change. DevSecOps involves introducing things like static and dynamic application security testing, security coding best practices, introducing really critical security controls directly into the application development process instead of doing it after the fact.
“Nowadays, DevOps has become the connective tissue or bridge between engineering and operations. Reducing tension, enabling faster deployment times, less failures, and closer collaboration. And DevSecOps is enabling the introduction of security even earlier in the software development process.” – Wias Issa, CEO, Ubiq Security
A very practical example is encryption. Most organizations develop applications, deploy them into production, and then at some point – days, months, or years later – someone realizes that sensitive application data is being written to a database or datastore completely unencrypted. Then finger-pointing between engineering, operations, and the security teams happens, followed by a scramble to identify an effective encryption tool, that also won’t create performance impacts. In some cases, identifying, testing, and acquiring the appropriate tool can take weeks or even months, especially if formal acquisition processes have to be followed. All this time, you’ve got data sitting out there unencrypted and vulnerable.
The whole concept of DevSecOps involves taking that security control – in that example encryption – and integrating directly into the application during the development process, saving you time, money, and freeing up resources to focus on higher priorities.
GDSOH: Application developers are clearly not cyberwarriors. How can they go about “baking security in” when developing applications? What tools exist for them in the marketplace to help them secure their solutions?
Wias Issa: I think that it starts with a mindset. There is a phrase that you’ll hear used, “Security as Code.” It’s very similar to concepts like, “Infrastructure as Code.” It starts off with adopting those concepts and principles within the engineering and operations teams. I don’t think it’s one individual – it needs to go across the entire organization. Once that mindset is accepted, and leaders align on designing things securely, that’s where it all starts.
Once you’ve embraced those concepts across the organization, then there enable effective DevSecOps. There are probably 20 or 30 emerging technology companies that are working to help developers not only code securely, but also integrate useful tools into their development processes, so that they can regularly perform security testing and also embed security controls as code. A great example is Secure Code Warrior, which has designed an innovative way to enable developers to code more securely, mitigating insecure code, and reducing risk much earlier in the application development process.
Coming back to encryption, according to Veracode, cryptographic issues are the 3rd most common vulnerability in software applications, occurring in 63.7 percent of the software applications they’ve performed security testing against. Now think of millions of applications out there in the wild. If 63.7 percent of them have cryptographic issues, that signals a massive problem. This is why integrating encryption directly into the application layer and a part of the application development process is increasingly essential.
