Micro Focus is now part of OpenText. Learn more >

You are here

You are here

4 best practices for application security testing tools

public://pictures/Robert-Lemos-Technology-Journalist-Lemos-Associates.jpg
Rob Lemos Writer and analyst
 

Code analysis and application security testing — core parts of secure software development — have come a long way over the past five years. Security testing is increasingly offered as a service, testing results come with more context, and training is often more refined.

Yet one problem remains: Developing secure software is not an easy task. The proliferation of tools, the struggle to trim down alerts to only what matters, and the lack of support for some software frameworks and programming languages all conspire to make adding security testing to software development a challenge. "When you go outside of security teams and try to give developers security tools, there is an investment that has to be made," said Dan Cornell, principal of software-security firm Denim Group.

"Just handing off tools to the developers is not likely to bring success."

Companies that are able to navigate the path to better software see dividends. While security is itself a laudable goal, the ultimate payoff is reducing the cost of creating and maintaining software. Catching bugs before they are shipped in production code can save anywhere from 20 percent to 50 percent, according to one large insurance firm's estimate, and reduce the cost of fixing a bug by as much as 100-fold.

The faster a tool can notify a user — whether software developer, quality assurance manager, or security practitioner — of a vulnerability, the less fixing the issue costs, said Jeff Williams, chief technology officer of Contrast Security, a startup focused on interactive application security testing (IAST). "If you can tell a developer of a problem right away, then it is like a compiler warning, and the cost of the vulnerability goes to zero," he said.

The three main types of application security testing (AST) tools focus on three different parts of the problem:

  • Static analysis tools, which have been around for more than two decades, search for known patterns of vulnerabilities and defects in the source code and warn the developer.
  • Dynamic analysis tools use known types of attacks against a running instance of the software — most often, a web-based application — to determine if the software is vulnerable.
  • Interactive analysis uses an agent running on an application server or a library built into the code at compile time to create an instrumented version of the software, which can then detect behavior indicating a vulnerability or an attack.

Here are four best practices for putting app sec testing tools to work for your organization, regardless of the debate:

1. Dynamic analysis is a good starting point

For companies that have no real secure development life cycle, dynamic application security testing, or DAST, is a good place to start, according to Jason Schmitt, vice president of the Fortify brand of Hewlett Packard Enterprise Security Products. DAST tools scan running applications for vulnerabilities, with a strong focus on vetting web applications. 

Kicking off an initiative to better secure software with a dynamic analysis can help convince developers that the technology can be useful, HPE Fortify's Schmitt said. Because almost all issues found using dynamic scanning can be exploited to some extent, the technology requires less security knowledge and can be more rapidly deployed, either as a service or on premises.

"Without tons of training or expertise required, you get a team some quick wins with real vulnerabilities of higher criticality, and that will impact the developers' perspective on how secure their software is. That quick life cycle shows a victory to the team and shows that the process is not all that complex, when you break it down to test before you deploy and fix before you release the software." 

2. Integration is extremely important

A key consideration in adopting any technology is how well it fits into your development environment, said Denim Group's Cornell. Developers are not going change their coding language to match a preferred application security testing tool, so security managers need to take stock of the environments used by their developers, he said. Finding security testing products that integrate well into developers' processes is important. 

"Companies need to decide what the outcome is that you want, and then figure out what combination of vendors can give you that coverage" -Cornel

Successfully covering a company's application portfolio will almost certainly require multiple products, he said. In addition, each technology has its strengths, which companies should be aware of. "No one technology and no one vendor is going to allow an enterprise to get complete coverage across their portfolio," he said.

3. Pilot the latest technologies

Application security testing continues to be a dynamic field. The technologies are improving and changing every year, so security teams should experiment with new tools to see if they work better for their particular development environments. 

For security teams that already have dynamic AST in place, for example, piloting static or interactive application security testing is a good next step. The right tool not only depends on the languages and platforms used in development, but also the company's overall development philosophy and what tools have already been put in place. 

"One thing that we have definitely learned is that there is no one-size-fits-all approach, everyone is different" -HPE Fortify's Schmitt

Static analysis tools are a good way to give immediate feedback to developers on common classes of vulnerabilities. Dynamic analysis tools typically have low false positives and are well suited to testing online applications and services. A fairly new technology, interactive analysis, instruments the application to allow the collection of runtime data for later analysis. "IAST is an excellent arrow for security teams to have in the quiver, so they should be looking at it and see were it fits in their process," Denim Group's Cornell said. "It will take time for that type of adoption to occur."

4. Turning vulnerability data into actionable information takes time

Companies should realize that implementing AST requires time, both for deployment and for processing the analysis. AST, especially static analysis, can produce a lot of data on likely defects in the code. To get the best results, the systems have to be customized, or tuned, over time to meet the appropriate balance for the company.

Multiple tools can add better fidelity, but at the expense of making the triaging of vulnerabilities possibly more complex, Cornell said. "If every tool has something to contribute, then the drawbacks of running multiple tools is that you have more data to sift through, and that data is not necessarily of high quality," he said.

"For certain applications, there may be value in doing that, and for other applications, you may say that the incremental value is not worth the time that I'm going to have to spend to get the results I need."

Contrast's Williams, a vocal proponent of interactive analysis and a critic of other types of analysis, agrees that testing adds work. "Every tool that you buy, especially static or dynamic analysis, takes work to run," he said. "Every organization I know of does not have 100 percent coverage in their application security program, and the reason is the bottleneck of app-sec experts."

It's time for culture change

Williams and HPE Fortify's Schmitt have had an impassioned debate on the digital pages of Dark Reading about the efficacy of static and dynamic analysis versus interactive. Yet, figuring out the best technology is important. For most companies, the important step is to decide to pursue better software security, Schmitt said. 

"The real way to secure software is to affect cultural change."

Keep learning

Read more articles about: SecurityApplication Security