Security teams spend as much time on false positives as they do on actual attacks

Now more than ever, security practitioners need precision and actionable intelligence from the monitoring systems that instrument their environment or that manage traffic at the network perimeter.

Actionable intelligence in this context may be defined as relevant alerts which warrant further examination or investigation and provide enough precise detail for the investigator without unnecessarily overloading security analysts, network engineers and developers.

Practitioners still get far too many mislabelled alerts – false positives – that mischaracterise legitimate traffic as a security threat.

The problem is that you don’t know it’s a false positive until after you’ve done the work to investigate it which consumes time, human resources and money.

The number of false positives multiplies with the number of security tools layered into the environment; recent research by ESG Research and Fastly showed practitioners are dealing with alerts from 11 tools on average.

Web application and API security tools alone send an average of 53 alerts per day, of which 45 per cent are ultimately determined to be false positives. That matches up with a prior piece of research that showed almost half of practitioners deal with a 50 per cent or higher false positive rate.

Perhaps the most jarring finding from the ESG study, though, is that false positives cause just as much downtime as actual attacks, and that three out of every four organisations spend equal or more time on false positives as actual attacks.

That’s a waste of finite – not to mention expensive – time and resources.

VIEW ALL

But at a time when many practitioners are working from home due to lockdowns, false positives are also increasingly a source of unwanted stress; in a separate survey, 70 per cent of practitioners said that dealing with the flood of alerts is impacting their home life, and over half say they are “overwhelmed”.

This is not good for your people, and has flow-on impacts for the organisation, where alert volume and false leads mean between 28 per cent and 39 per cent of alerts are ignored or otherwise go unaddressed.

Scanning for intent

We need modern security tools that look at intent, not just action.

Security teams have long been focused on fighting specific threats. They traditionally use tools that look for signatures or “indicators of compromise” (IoCs) of a particular threat, such as IP addresses of known attackers. If recognised, these indicators can then be acted upon.

What these tools don’t do well is differentiate between legitimate and malicious traffic. Current security tools frequently block harmless business traffic, impacting the organisation’s bottom line. Requests originating from university or corporate proxies often have the same client IP address, and just one malicious client can block the whole organisation from accessing your web application when the security tools assume one user to one IP address.

As a result, 72 per cent of Australian organisations run tools in log or monitoring mode only. Practitioners are effectively the “filter” here for false positives, and that’s where the model breaks down (potentially, along with the practitioners themselves).

A further 12 per cent of Australian organisations choose to shut the tools off entirely. All this despite 53 per cent preferring to run tools in an active blocking mode, since it would reduce manual intervention and effort – if only it worked effectively.

The new rules of web application and API security demand a shift toward a more intelligent model, one that infuses enough confidence into the security toolchain that a practitioner can assuredly run the system in front of valuable traffic without fear that it will block legitimate attempts or allow malicious ones through.

Getting there requires making new demands from security technology. First, practitioners must demand tools that examine not just the signature of the traffic but its intent or behaviour. This means taking into account factors like the speed of the request, time of day, and user log-in status.

Second, builders must demand that tools can be run not just in monitoring mode but in blocking mode. Tools that can only run in monitoring mode for fear of false positives reinforce a broken system: the damage is done by the time the team can respond. Teams need a foundation of tooling that can confidently block threats as they happen, not diagnose the problem after the breach.

The tools also need to be able to keep up with modern threats without placing additional burden on the security and operations teams to obsess (even more than they already do) about emerging threats.

Building up to a change

The ESG study shows that teams and organisations are ready for a change.

We need integrated, consolidated tooling that works across teams – and it looks like we already know that: 93 per cent of respondents to the ESG study (over three-quarters in Australia) said they are interested in or planning to deploy a consolidated web application and API security solution to improve security efficacy, provide consistent protection across disparate application architectures and environments and reduce costs.

There’s no time like the present to start updating and consolidating your processes and security stacks.

Stephen Gillies is the APAC technology evangelist at Fastly.