When responding to an emergency, speed matters. It's true in traffic incidents and structure fires, and it's true in the realm of computers and networks. There's no real surprise here, but a new report by the Aberdeen Group has quantified just how much speed matters -- and it turns out to matter quite a lot.
One of the things that the study (sponsored by McAfee) looked at was dwell time, or the time between breach and detection. Put another way, the dwell time is just how long the attacker was able to run free inside a system before being detected. The median time to detect in the attacks studied by Aberdeen (which were taken, in turn, from the Verizon Data Breach Investigations Report) was 38 days. That means half were detected in less that five weeks, while the other half took up to four years to be detected.
The report broke the attacks into two broad categories: those intended to steal information and those intended to disrupt service. Aberdeen found that the impact of response time differed greatly between the two types of attacks. In attacks designed to steal confidential data, detection and response twice as fast meant a reduction in business impact of 30%. In those attacks intended to disrupt service, detection and response twice as fast meant that business impact was reduced by 70%.
In a Security Now telephone interview with Barbara Kay, McAfee's senior director of product and solutions marketing, she pointed out that information like this can be important for an IT staff, especially when it comes to budget discussions. "You have people in IT trying to justify expenditures and this data set says that reducing time to detect and time to respond both make a tangible difference in impact. Investing in detection and response does have a tangible impact," Kay said. "This is a sound business decision."
Kay pointed out that knowing the importance of response time could have an impact on a less-easily measured IT factor, as well. "It makes staff know that their time matters," she said. "Showing the staff that their time matters and that they have an impact makes a difference in an overworked staff."
Longer response times were generally (though not always) attached to zero-day attacks -- attacks in which the first public knowledge of a vulnerability comes when it is used in a successful attack. In cases where the vulnerability is known and corrected before an attack is launched -- as with the recent WannaCry attack -- attention turns to whether the patch has been applied and the legitimacy of reasons for not patching the issue.
Aberdeen estimates that an enterprise will deal with between 220 and 660 vendor patches a year. That translates to a median of 910 hours a year in disruption to enterprise applications. Given that "five nines" reliability is seen as standard reliability in many organizations (a metric that, by the way, means 26 seconds per year in downtime), 910 hours is completely unacceptable. So what options are available to organizations that want to stay on top of the situation?
A solid patch-management regimen is at the top of the list. Next up is virtual patching -- sometimes known as external patching or vulnerability shielding -- to deal with the vulnerabilities before the system can be patched. In virtual patching, an attack based on a vulnerability is understood and a blocking rule is applied by a firewall, filter or UTM to prevent the exploit from ever reaching the vulnerable system. This can be an effective protective mechanism while waiting for patches to be applied.
So get faster. Much faster. It's the responsible thing to do in security.