Interactive application security testing: Ready for prime time?
With software development and methodologies such as DevOps becoming more popular, companies are increasingly looking for ways to make application security testing part of their development process.
Static software analysis is increasingly integrated into the code check-in process, often in a slimmed-down form, to improve the quality of code and to catch known vulnerability patterns. Dynamic testing is often used as an automated check of web applications. And, increasingly, companies are looking at interactive application security testing (IAST)—using a software agent to add instrumentation to applications and then using test cases to attempt to force failures—to help catch certain types of flaws.
Nir Valtman, the head of application security for business-technology maker NCR, said that IAST makes it possible to bake more security into the software development process. One important aspect of the technology: It only flags vulnerabilities that have an impact on the system, he noted.
One of the biggest pains with security scanning in general is the amount of false positives that you have to deal with, Valtman told TechBeacon.
“If you try to integrate security scanning that is part of the continuous integration process, and there are too many false positives, then you are blocking the engineering team.”—Nir Valtman, NCR
Looking ahead, interactive application security testing has two strong advantages that will help agile development teams, experts say. Here is a rundown.
Fewer false positives
By putting an agent on systems to instrument applications and access process memory, IAST deployments only see code defects that lead to actual problems. For that reason, interactive testing tools act as canaries to give a definitive answer on whether a flaw is exploitable.
“IAST is close to zero false positives. None of the vendors is comfortable saying that they have zero false positives, but it's pretty close.”—Nir Valtman, NCR
Fewer false positives is important because developers dislike dealing with bugs in their code. Previous testing technology that scans an application and produces a report of the issues can have a high rate of false positives—software issues that are flagged as defects but that are not exploitable—and that slows down development and can make developers resist security efforts.
"If you get handed a phone book of vulnerabilities and you have to say, 'Thanks, you just made it so I can't release my product,' you are not going to be happy," said Scott Johnson, a director in Hewlett Packard Enterprise's Fortify group.
Better, and more defined, coverage
Companies can convince developers to use a tool that benefits security by selling them on the tool's non-security benefits. The best way to convince a team of engineers to use static analysis, for example, is to tell them it is a tool to find quality issues, said NCR's Valtman.
IAST can help companies determine how much of their code base they are covering in their testing—an important quality-control function that also has security implications, he said. "You can tell whether you are testing 60 percent or 80 percent of the code on your server," Valtman said.
Yet companies should not try to maximize the amount of code they vet with IAST. Rather, they should use the technology as a surgical tool, and—in a DevOps environment—the technology should be focused on enabling development teams to move quicker, said Zane Lackey, founder and chief security officer for Signal Sciences, an agile security-services company.
“[IAST] is inherently self-limited in the coverage it can give you, because it runs in your development or QA department. So you need to understand that it is a piece of your software security story, not the be-all and end-all of your story.”—Zane Lackey, Signal Sciences
IAST currently not easy to deploy
Companies also need to understand that IAST requires technical know-how to parse the result and determine the cause of an issue. If static analysis tools have a complexity of 4 out of 10, IAST is about an 8, according to NCR's Valtman.
"When you deploy IAST, the people that you work with to integrate it need to be extremely technical," Valtman said. "So the people who you put in charge cannot be a junior person."
Staging any rollout is critical, he said. By adding the technology to a small project first and then expanding its reach, the security project can pay dividends while the security team is learning the best ways to integrate it.
"If I introduce a new service, and only run certain tests on the new service—you can do that," Valtman said. "The IAST results will be very quick but will not find everything, because you are limiting it. But that aligns with the way that the engineers work."
Starting with the most pervasive issues—and those that IAST is well suited to find—is also a good approach, said HPE's Johnson. "Pick the most important areas and tackle those," he said. "Cross-site scripting and SQL injection are likely the most significant—that's probably 70 to 80 percent of the issues out there."
Is IAST ready for prime time?
IAST makes a lot of sense on paper but has been slow to take off. That will change over the next two years, says analyst firm Gartner, which predicts that more than 30 percent of companies will adopt IAST by 2019. A similar technology, runtime application self-protection (RASP), which is designed to protect production environments, will not break the 10 percent mark, the firm stated in a recent report.
Valtman said he expects IAST to eventually replace dynamic application security testing (DAST), which sends test input to an application and observes for external responses.
For now, however, companies are just dipping their toe into the water. Most are just evaluating IAST technology because it has not yet delivered the kind of results that are must-haves, said HPE's Johnson.
“The need is more visibility sooner, especially with DevOps gaining a foothold with organizations. There has been some level of not wanting to put an agent on your machine, but I think that is changing.”—Scott Johnson, HPE