5 Obamacare Website Failures That Could Have Been Avoided

The troubled HealthCare.gov website faced another setback when a software security expert found a series of security flaws, indicating that virtually no security testing went into the site's rollout, according to experts. Organizations that depend on software to run any part of their business need to be concerned about software security, according to software security luminary Gary McGraw, who serves as chief technology officer of Cigital.

McGraw recently unveiled the fifth version of the Building Security In Maturity Model (BSIMM-V). The free software security measurement tool helps organizations benchmark their activities against industry peers. The BSIMM-V study describes the initiatives of 67 organizations. It identifies more than 100 activities that were observed in the field. Here are five ways the Obamacare site could have benefited.

This was a big area of fail for the Healthcare.gov website. It turned out that a database hub failure at hosting provider Verizon Terremark caused a series of intermittent outages and even website downtime. The BSIMM-V study found that nearly all of the firms observed in the study ensured that host and network security basics were in place. This kind of thorough testing also covers the rest of the security operation teams' duties, including patching and firewall maintenance.

Can the website handle high traffic loads? Is denial-of-service protection in place and tested? Are all systems properly configured? "Doing software security before network security is like putting on your pants before putting on your underwear," according to the BSIMM study.

The vast majority of the firms observed in the BSIMM study use external penetration testers to find problems in the software. Penetration testers could be brought in to break a high-profile application in order to demonstrate that the organization’s code needs help, the study participants said. External tests validate the software quality before it is put into production.

An internal memo obtained by the Washington Post found some security tests were not conducted due to ongoing development. A thorough pen test would check to see if a Web application can identify an automated attack against contact forms. A test can verify that information stored in cookies is not stored in a readable form and help identify and prioritize vulnerabilities based on the risk they pose to the underlying data and the potential for exploitation by an attacker.

The contractors working on the HealthCare.gov project could have conducted an inventory of the kind of data that the Web applications associated with it would be handling. The inventory would help establish a priority, such as focusing on the Web apps that directly handle personally identifiable information. The BSIMM study found that organizations commonly undertake data classification. For example, organizations may classify according to protection of intellectual property, impact of disclosure or exposure to attack. Once a data classification system is put in place, it should be strictly maintained and reviewed periodically, say security experts.

Organizations that roll out applications with strong security generally have leadership at the top that drives the software security program, according to the BSIMM study. A leader helps promote privacy and over time establish a culture of security throughout the organization with a sustained user-awareness training program. A senior executive directly in charge of software security solves two common management issues, accountability and empowerment, according to the BSIMM study. Grassroots approaches have a poor track record, and leadership originating from the networking team often fails to work well with development teams.

Officials told lawmakers that the rush to launch Obamacare caused the federal contractors to fail to fully test the program's Healthcare.gov website. In fact, one official told a congressional committee that the site design was changed a month before the launch and a review of the software code detected language normally found in early versions of projects.

One of the 12 commonly observed activities in the BSIMM study is the process of having milestones or checkpoints in the software development lifecycle. To thoroughly monitor progress for projects, organizations should begin by identifying milestone locations. Enforcement is not immediately undertaken, instead the checkpoints are monitored and discussed, and security testing results are gathered with the understanding that they will be enforced later. "This gradual approach serves to motivate good behavior without requiring it," the study found.