Cybersecurity in the government sector has dominated the headlines the past couple years. From nation-state actors breaching voter databases in 2016, to the recent findings that 74 percent of federal agencies have cybersecurity programs that are either at risk or high risk, there are a lot of worrisome stories regarding the state of government cybersecurity. Should we be concerned? What’s the reality, how did we get here, and what should government entities focus on moving forward?
The government software security reality
At CA Veracode, we’ve been scanning our customers’ applications to identify security flaws for more than a decade. All those scans produce a lot of valuable data around software security – for instance, what types of flaws are most prevalent, what fixes are working, and which industries have the most and least secure code. And year in and year out, our data finds that the government performs the worst in terms of software security. Truthfully, no industry is getting high marks in terms of software security – from healthcare to financial services to retail – we’ve got a long way to go in terms of creating secure code. Yet it could be argued that government is the industry with the most to lose if their data is exposed. The unprecedented cyberattacks on elections in the US and other democracies over the past year demonstrate that our most critical systems and the very foundation of our society are in the cross-hairs.
According to CA Veracode scan data collected just this past year, government applications had the highest flaw prevalence of any industry group for cross-site scripting, SQL injection, credentials management, and cryptographic issues. Government is also the industry that performs security testing the least frequently and passes the OWASP Top 10 application security policy the least frequently.
Why are government agencies in this state?
Several factors converge to leave government agencies in this less-than-ideal software security state. First, these institutions, far more than other industries, are targeted by some of the most malicious actors — nation states with extensive funding. At the same time, they are subject to some of the most stringent regulations, including DISA-STIGS, FIPS, FISMA, NIST, PCI, OWASP, and SANS. Making matters worse, most government entities are developing applications with older programming languages known to produce more vulnerabilities, and they’re not always fixing the flaws that they find.
Older tech combined with strict regulations and well-funded attackers leaves them in a tough spot.
In addition, because software is an integral part our daily activities — from shopping to driving — we expect that same level of speed and convenience in all our interactions, including with our government agencies. In response, agencies of all sizes are building, buying, and downloading more applications than ever before, and faster than ever before.
What should the government sector do?
We have seen signs that the government sector is trying to take better advantage of technology, streamline processes and make security a priority. The Cloud First Policy requires agencies to evaluate safe, secure cloud computing options before making any new investment. And the Modernizing Government Technology Act, which was signed into law last year, has made a point of prioritizing both security and agile management practices as government looks to refresh its IT infrastructure.
These are positive steps in the right direction, and we would add the need to focus on prevention. The prevalent idea that you will be able to detect and respond to a cyberattack is simply misguided. As we saw with the recent WannaCry ransomware, attacks can now move with lightning speed – meaning a strategy of “detect it and contain it as quickly as possible” will not be effective. Our data clearly reveals that government agencies are not conducting security testing and are releasing insecure code. Waiting for this code to be exploited is not the right tactic. Developing an application security program that incorporates security testing early in the development cycle – stopping the insecurity at its source — is the right tactic.
Developer security education
This prevention focus also has an education component. Asking developers to test their code for security flaws earlier in the development process does not mean they will understand the results of that testing or how to avoid the same making the same mistakes again. Most developers have not had security training, in school or on the job, and don’t know the basics of secure coding. Prevention starts with getting developers that training. And we know this works. Again, pulling from our scan data, we found this year that eLearning improved developer fix rates by 19 percent; remediation coaching improved fix rates by 88 percent.
Dev-friendly security tools
In addition, prevention entails ensuring developers have both the secure coding knowledge they need, and the right security tools. The government is not going to decrease its reliance on software; it’s not going to be creating less applications. It’s going to be creating more, and faster. Any security controls that slow a developer down will be ignored or overlooked. Look for solutions that work the way developers work and that don’t bog them down with endless results or, worse, false-positive results. Help them make security testing a part of their processes and make sure they understand how to code securely and can get guidance on fixing flaws when and if they need it.
I recently reunited with my fellow L0pht members to again present to Congress, 20 years after we first presented on cybersecurity. It was frankly astonishing that despite the vast changes in technology in the past 20 years, we were talking about many of the same underlying vulnerabilities. The government has a role to play here – both in securing its own software and setting flexible, outcomes-focused cybersecurity standards and policy for other organizations. We’re seeing signs of an awareness shift; let’s keep the conversation going and start the move from awareness to action.
This article is published as part of the IDG Contributor Network. Want to Join?
Copyright © 2018 IDG Communications, Inc.