Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How one healthcare giant stays focused on application security

Rob Lemos Writer and analyst

With 3,000 applications under his management, Aetna's chief information security officer Jim Routh has a lot to deal with. The healthcare company uses considerable diversity in how it builds applications. Developers build two-thirds of the company's applications in Java, and much of the remainder is written in .NET and Ruby. And like many large companies, Aetna maintains a small number of critical applications written in COBOL, a language more than five decades old.

Keeping the developers of those diverse applications focused on security is tough, but it can result in significant cost savings, says Routh.

Ensuring ROI and compliance

"Our whole software security program is predicated on the objective of reducing the total cost of ownership of the application portfolio," Routh says. "We try to prevent as many defects as we can, and we try to fix as many bugs as well as we can, and that ends up creating a productivity gain of 20 to 50 percent."

As a covered entity, Aetna must secure any application that handles protected health information (PHI) to be compliant with the Health Insurance Portability and Accountability Act (HIPAA). In fact, all health insurance companies must do a risk analysis of their applications and infrastructure to make sure that PHI is handled in a secure way. Most security professionals consider technical vulnerability assessment—whether vulnerability scanning or penetration testing—a required part of risk analysis.

Letting developers lead the app sec charge

To cope, Routh delegates much of the responsibility for choosing a testing tool and the actual testing to the developers themselves. Through a mature secure development lifecycle (SDLC) process, the company’s coders test for security at multiple steps in the process of creating and updating applications.

Static tools (SAST, or static application security testing tools) are chosen by the developers to fit with their programming process, while dynamic tools (DAST, or dynamic application security testing tools) are used to assess infrastructure and running applications.

“We are not a big fan of running industrial-strength software security testing tools after the code is written, taking a day or two to compile the results, and then sending it back to the development teams,” he said. “If the development teams are doing a DevOps model, they are continuously doing builds.”

Routh’s team at Aetna sets requirements for types of testing. The use of static and dynamic analysis tools has led the team to start a pilot to evaluate interactive application security testing (IAST) tools.

Determining security risk levels

The company does not mandate what development environment programmers use, but it does require each application to be classified within a risk category: low, medium, or high. An electronic medical records system would have a high-risk classification, while an information site for patients may have a low-risk classification.

Then it requires teams responsible for these applications to abide by a set of controls for the risk level. To support developers, the security team has an approved set of tools that they use to secure their software. Open-source software is acceptable, as long as the development team is active and releases patches quickly.

“We have different affiliates that have different development teams, and some of them, for example, are exclusive Ruby development,” Routh says. “In those cases, we will pick a tool that is based on those environments and require that they use it.”

Final note: Take precautions with open source

Routh recommends that companies take stock of their portfolios of open source code as an important first step. Open-source libraries are frequently used by application developers without much thought, and they may not track notifications of vulnerabilities in those libraries. The result is that applications, which are otherwise secure, will have security weaknesses in the included code libraries and frameworks.

After getting a grip on common code dependencies, developers should adopt static analysis tools, then use dynamic scanning, and finally focus on locking down their mobile applications, says Routh.

Keep learning

Read more articles about: SecurityApplication Security