Tool Sprawl & False Positives Hold Security Teams Back

Organizations report it’s becoming increasingly difficult to maintain the security of their Web applications and APIs with a patchwork of security tools and a rising wave of false positive alerts.

Nearly half (45%) of all daily security alerts are false positives, researchers report in “Reaching the Tipping Point of Web Application and API Security,” a study conducted by ESG Research and commissioned by Fastly. The global survey polled engineering, security, IT, and DevOps leaders across 500 organizations located in North America, Europe, and Asia-Pacific and Japan.

Most (75% of) respondents say their organization spends an equal amount, or more, time on false positives as on legitimate attacks. It’s a costly problem in more ways than one, explains Kelly Shortridge, senior principal at Fastly.

“Sometimes the actual attacks are just lost in the deluge,” she says. “It’s really difficult to stay on top of things when you’re having to triage sometimes more than a dozen events in an hour; sometimes much more than that.”

Compass CISO Jonathan Agha points to the issue of tools fighting for attention, a problem that worsens as they accumulate.

“With all the tooling and alerts that we have, we have a ton of information, but it might not be relevant information, or a context that we care about, and the alert also requires a human to act on it,” he adds.

False positive alerts can affect adjacent tooling as well, Shortridge continues. If an organization has a central data store polluted with a high number of false positives, it impedes the security team’s ability to use automation to help with workflows or playbooks based on that data. Any processes they create based on that data won’t work very well, she points out.

The opportunity cost extends to the rest of the business, as security practitioners investigating false positives lose time they could be spending on more strategic enterprise improvements. When more time is spent triaging false positives and trying to adjust tools to make them work better, the business misses out on opportunities to think more strategically about where it can improve elsewhere.

To respond to the increase in false positives, businesses have two primary options: run tools out of band in log or monitor mode, or turn them off entirely. Researchers found while 53% of respondents chose to shift to log or monitor mode, 12% report turning their tools off and 26% report doing both. Most respondents (82%) indicated their organization turned off Web application and API protection tools less than one month after deploying, researchers report.

Too Many Cooks in the Kitchen
Researchers found organizations use an average of 11 Web application and API security tools, and they spend $2.6 million on them each year. Much of this “tool sprawl” can be attributed to supporting new architectures and cloud environments, which indicates security grows more complex as businesses adopt new technologies.

“The majority of the market is struggling with transforming their applications to be cloud-native,” says Shortridge. “A lot of times they’re straddling the old world with monoliths and legacy on-prem systems, as well as the new world with microservices and cloud hosting.”

Tools that worked with those legacy systems generally can’t handle, or don’t support, cloud-based workloads with a microservices architecture, she continues. In Shortridge’s experience, tool sprawl isn’t as common a problem in organizations that fully operate in the cloud.

There’s a common mentality that a new tool will help solve a problem. When a data breach happens, or something falls through the cracks, or analysts are burned out, it’s easier to buy a new tool than it is to step back and consider in which ways the security program may be failing.

“You can’t technology your way out of a process or a people problem,” she says. It’s a human tendency to think buying the new and shiny tool, it will fix the problem — not make it worse — and people often think more about how they can add, rather than what they can subtract, when solving a problem.

How many tools is too many? While organizations often talk about the upfront cost and benefit of a new tool, they may not consider the long-term cost of their investment. The right number of tools is different for every business; however, there are a few red flags that might indicate it’s time to cut back, Shortridge says.

One of these is apparent when bringing in new employees: If it’s tough to onboard new team members who are supposed to work with application security tools, and they struggle to use them all, it’s not a good sign. Consider whether it’s difficult to discern the tool’s value on a daily or weekly basis. If you get a result from a tool and don’t immediately understand its value, that is a problem. And finally, she advises considering the opportunity cost: Where are tools slowing processes down? Would you recommend them to another organization?

Shopping for Web Application Security
As they consider which Web application security tools to invest in, she advises security teams to consider what the business values most, and the key indicators of success they’re measuring. For example, for engineering-led organizations that value velocity in delivering software, a security tool that doesn’t align with those principles of performance should give you pause.

“What’s the point in securing the business if you’re just hamstringing its operations?” Shortridge says. “The point is to help them operate safely.”

Read More HERE