03/31/2020 | Press release | Distributed by Public on 03/31/2020 15:33
If there's one thing that drives me crazy about the tech industry, it's the sheer volume of acronyms and jargon it generates. From SOC, NOC and DLP, to XSS, CRUD, FUD and spearfishing. I could write a whole article in nothing by acronyms and domain language. The crazy thing is, despite it looking like alphabet soup, tech people could probably follow it quite easily.
With that said, there is one industry term I don't hear nearly enough of, and that's dwell time. Dwell time is one of the least talked about, yet most important metric for managed service providers (MSPs), their partners and end-users.
What is dwell time?
Dwell time is defined as the time a bad actor has access to your system before being identified. It's calculated by adding the Mean Time to Detect with the Mean Time to Response/Remediate. The longer someone is able to explore your system, map the network and have access to the data, the more harm they can potentially cause.
You risk losing all data by malicious deletion, or being asked to pay a fee - which could reach the million dollar range - in the event of a ransomware attack. If data is lost, you may also incur expensive fines from regulatory agencies like the European Union's (EU) General Data Protection Regulation (GDPR). The potential losses to your company are infinite considering everything from downtime and loss of resources, to expensive ransom payments, penalties and damage to your reputation.
Overall, average dwell times have declined since 2015, when they peaked at 146 days, according to Fireye's 2020 M-Trends Report. But it's also still quite surprising to see the 2019 average of 56 days. Just imagine hackers having access to your systems for 56 days! What kind of damage could someone do in nearly three months without being detected?
Factoring dwell time into your security program
One common problem is presuming you can prevent a bad actor from gaining access to your systems and network. Instead, a good security program should start with the assumption that a hacker will, of course, gain access. Unfortunately, it's not a question of if, but when, and the numbers prove it.
According to The New York Times, 205,280 organizations reported being infected with ransomware in 2019. That's a 41% increase compared to 2018. Additionally, a ransomware attack successfully corrupts an organization filesystem every 12 seconds. And unfortunately, the average downtime for a ransomware attacks is 16 days. Certainly not a manageable amount of time for many small to medium-sized businesses (SMBs) to be offline.
Now faced with the cold hard fact that an attack is probable, you can secure your network or create your security program to do more. By factoring in dwell time you ask appropriate questions that can optimize security. Things like, 'how will we identify abnormal events on the network?' and 'how will these events be remediated and logged?' Understanding dwell time leads to a more comprehensive discussion of appropriate security processes.
For example, full packet mirroring for deep inspection is great, but it might not help you identify threats any faster than just monitoring outbound traffic for off-pattern traffic. Similarly, identifying, blocking and removing a bad actor is essential, but an area often overlooked is how to enable full logging across the network, to be used later for forensic analysis.
So how does dwell time relate to backup and disaster recovery (BDR)? As a piece of the puzzle in our partners' security blanket, we may not be able to detect when a bad actor gains access to a network or system. We can however do things to limit the damage they are able to do once they've broken in.
By enforcing a minimum number of backup points, regardless of what the configuration is set to, we can ensure recovery points with meaningful duration. This allows us to restore in the event of a crypto lock or corruption of a system. Further, by placing honeypots in the system, we can help identify suspicious events and give attackers a false sense of accomplishment.
Reducing your dwell time
Here are a few tips for setting a baseline as you continue to address dwell time as part of your overall security program:
About the Author:
Ben Nowacky // Senior Vice President of Products, Axcient
As Senior Vice President of Products for Axcient, Ben Nowacky leads the Engineering and Security teams to provide business continuity and cloud enablement services. He's also a semi-amateur boxer and modern-day renaissance dog trainer. When he's not banging the keyboard and helping MSPs, he loves long walks on the beach and romantic dinners with his wife.