Attacks/Breaches

4/11/2018
04:58 PM
Connect Directly
Twitter
Twitter
RSS
E-Mail
0%
100%

Attacker Dwell Time Still Too Long, Research Shows

New DBIR and M-Trends reports show the window between compromise and discovery are still way too long.

In the past seven years, cybersecurity teams have cut down the time it takes to discover a security intrusion by fourfold. Unfortunately, that improvement in the window between initial attack and discovery of the incident isn't nearly enough to actually make a difference in blocking the typical intrusion from turning into a full-fledged data breach.

In fact, data from several new industry reports out in the last week show that most organizations would need to make that time to discover at least 100 times faster to actually prevent most successful breaches of data.

First among the latest spate of statistics are the numbers from FireEye/Mandiant's 2018 M-Trends report. According to the study, the most recently measured dwell time - that is, the time between initial attack and discovery of the incident - equals an average of about 101 days for organizations worldwide.

That's up by two days since last year, but the good news is that this number is down significantly from 416 days back in 2011. Another positive sign the report relates is that the percentage of incidents discovered internally versus those disclosed by a third party is way up. Approximately 62% of incidents are now discovered internally, which shows organizations are doing work to raise the bar on their detection capabilities, FireEye says.

Nevertheless, these are just silver linings on thunderclouds. Yesterday's Verizon Data Breach Investigation Report (DBIR) showed that once they've compromised their target, the time it takes attackers to breach data is orders of magnitude shorter than the time it takes for victims (or third parties) to discover an attack.

"When breaches are successful, the time to compromise continues to be very short. While we cannot determine how much time is spent in intelligence gathering or other adversary preparations, the time from first action in an event chain to initial compromise of an asset is most often measured in seconds or minutes," write the authors of this year's DBIR.

That's scary, considering discovery time is measured by weeks and months - sometimes even years. The DBIR numbers show that 87% of compromises took minutes or less. Only 3% of compromises were discovered as quickly. Meanwhile, 68% of them took months or years to be discovered. 

Many IT leaders are at least aware of this huge delta between compromise and discovery time. Another study out yesterday from LogRhythm showed a significant lack of confidence among IT decision makers in the ability of their systems and processes to discover all potential breaches -about four in 10 report they lack confidence in the thoroughness of their detection capabilities.

And, here's the thing: time to discovery is just the start of the journey in responding to a compromise. There's also the time it takes to respond to, contain, and investigate a threat. According to the LogRhythm study, fewer than one-third of organizations say that even if they detected a major incident they'd be unable to contain it within an hour. And that time to contain compromises is going up. A different study conducted by Ponemon Institute on behalf of IBM Resilient Systems earlier this year shows that 57% of organizations are experiencing longer times to resolve security incidents.

Related content:

 

Interop ITX 2018

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry’s most knowledgeable IT security experts. Check out the security track here. Register with Promo Code DR200 and save $200.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
'Hidden Tunnels' Help Hackers Launch Financial Services Attacks
Kelly Sheridan, Staff Editor, Dark Reading,  6/20/2018
Inside a SamSam Ransomware Attack
Ajit Sancheti, CEO and Co-Founder, Preempt,  6/20/2018
Tesla Employee Steals, Sabotages Company Data
Jai Vijayan, Freelance writer,  6/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-12716
PUBLISHED: 2018-06-25
The API service on Google Home and Chromecast devices before mid-July 2018 does not prevent DNS rebinding attacks from reading the scan_results JSON data, which allows remote attackers to determine the physical location of most web browsers by leveraging the presence of one of these devices on its l...
CVE-2018-12705
PUBLISHED: 2018-06-24
DIGISOL DG-BR4000NG devices have XSS via the SSID (it is validated only on the client side).
CVE-2018-12706
PUBLISHED: 2018-06-24
DIGISOL DG-BR4000NG devices have a Buffer Overflow via a long Authorization HTTP header.
CVE-2018-12714
PUBLISHED: 2018-06-24
An issue was discovered in the Linux kernel through 4.17.2. The filter parsing in kernel/trace/trace_events_filter.c could be called with no filter, which is an N=0 case when it expected at least one line to have been read, thus making the N-1 index invalid. This allows attackers to cause a denial o...
CVE-2018-12713
PUBLISHED: 2018-06-24
GIMP through 2.10.2 makes g_get_tmp_dir calls to establish temporary filenames, which may result in a filename that already exists, as demonstrated by the gimp_write_and_read_file function in app/tests/test-xcf.c. This might be leveraged by attackers to overwrite files or read file content that was ...