Government Computer News recently published an article about the security of government Web applications based on Veracode’s semiannual State of Software Security Report. What the report found was that, overall, government Web-based applications were more susceptible to attack than their counterparts in the private sector.

Why are these Web-based applications more hacker-friendly? The article claims that the platform they’re built on and the experience of the developers was to blame. However, there could be other reasons why these sites are less secure, and some simple ways to correct the issue.

The simple excuse could be that the government has a large bull’s eye on it for various reasons. Hackers and terrorists look to deface and embarrass the government for political and financial motives. This means that the government needs to be even more vigilant when it comes to compliance and security issues.

However, there are deeper and more significant problems than the increased attention of hackers. One of these issues is the government acquisition process. Many of the individuals responsible for the creation of RFPs containing software development and security requirements do not possess the requisite knowledge to write those sections. Many of these individuals don’t think to make strict security requirements part of the scope of the project.

Many times, these individuals will rely on Federal Information Security Management Act (FISMA) standards for establishing minimum security requirements for applications. Unfortunately, FISMA standards were created years ago. In the ever-evolving, constantly-shifting security environment, a few years can make a huge difference. Security threats have evolved and FISMA standards are no longer capable of securing against today’s advanced cyber threats.

The contractors that respond to these RFPs with obvious security gaps aren’t required to address the issues. In many cases, the extra time and effort needed to do so would ultimately cut into their bottom line, so they avoid it. And it’s easy to understand why.

Developers aren’t security people by nature. In fact, security is often an afterthought when developing an application. It requires going back through applications post development and testing to identify vulnerabilities. That’s an extra step, potentially extra personnel, and a huge extra cost to the contractor.

The end result? A Web application is developed for the federal government that meets outdated FISMA standards for security, but ultimately is not protected from today’s advanced threats.

This application is rolled out across the agency where it becomes a goldmine of valuable information for hackers. As the application is breached or compromised, the government goes back and improves security. This reactive nature can patch the holes, but not before information has been compromised.

But what could have been done differently?

Once again, it goes back to the acquisition process. By working with an independent subject matter expert in security, RFPs can be written to require the most recent security advancements.

On the contractor side, developers need to be trained on how to develop secure code. In addition, they need to ensure that development teams are doing testing as they create the applications. They also need to start embracing code reviews and having independent quality assurance people conduct testing for vulnerabilities.  It’s also, not uncommon for companies to hire consultants to conduct security coding classes for development and testing staff.

Cyber security threats are real and they’re constantly evolving, becoming more sophisticated and increasing in number. Government agencies, which hold a wealth of information, digital records and files about citizens, are an incredibly attractive target for data thieves. It’s no longer enough to reactively plug holes in applications.

In this challenging cyber security landscape, government agencies need to ensure that applications handling sensitive data are protected against the most advanced threats. Moreover, contractors need to take the next step to educate their developers and test their work to ultimately ensure that a secure product is delivered. If both sides, the government and the contractor, take security more seriously, they can proactively stop attacks, instead of triage the damage.