Learning from Incident Response — Get the latest insights from the cyber trenches
The Art of Detecting & Containing a Cybersecurity BreachLearn the top 3 ways threat actors gain access to an IT ecosystem, how to contain a breach, and ways to minimize your organization's exposure. By: Secureworks
Threat actors today are increasingly crafty, preying on any and every security gap they find. Unfortunately, a breach is seemingly more the norm than not. Our Counter Threat Unit™ researchers indicate that ransomware has increased by 8%, and 2021 saw an increased use of zero-day exploits by threat actors, compared to 2020. lf a breach is inevitable, how can organizations minimize the impact? Tony Kirtley, Director of Incident Command at Secureworks®, shared his insights with CyberCrime Magazine’s Hillarie McClure on some of the post-breach regulations organizations must adhere to, as well as the common vulnerabilities and gaps businesses should be aware of.
So Tony, I would love to hear more about your role at Secureworks.
Certainly. I manage a team of incident commanders that manage the most complex, largest incident response engagements that we see. A lot of them are ransomware because those who have experienced ransomware know that it's “all hands on deck” and a very, very challenging type of incident. So, that's what we do.
Definitely a challenging incident. And with regard to incident response, how much time does an organization have to identify and contain a breach, I guess. Is there an average? That's kind of what I'd want us to dive into next.
If I were to put a number on an average, I would say about two weeks, but that time has shortened. And I think it depends on what the threat actor sees in the environment as far as defensive tools.
In the last six months, we've seen, we call this “dwell time,” the time between when an attacker gets into an environment and when they take care of the actions on the objective, whether that's a data breach or ransomware. We've seen that dwell time between 1 day and 303 days on our incident response engagements in the last six months. Certainly, the shorter ones were the ones that have the detection tools, and so the threat actor sees them and probably thinks, “I need to do what I'm going to do very quickly.” However, there are other environments where they can take their time, especially if they're logging in via a VPN or some other remote access service and they go undetected, they fly under the radar, they can take their time and see how they can affect that organization the most.
As you know, Secureworks’ bread and butter is monitoring. And we have Taegis customers (that's our monitoring service), and we detect the early warning signs of these types of breaches, and we reach out to our customers urgently because we know what's going to happen. We see all kinds of indicators, and we have been able to prevent ransomware from happening because of them. We know—just by the tactics and tools that we see being used—that they're going to lead to ransomware, and data breaches are one of those things that leads to ransomware. So, the action needs to be taken quickly, just in case. I mean, we can't count on the threat actor taking 300 days to dwell in the environment before they detonate ransomware or steal the data.
Right? absolutely. That makes a lot of sense. And so, as far as timing goes, thanks for helping us contextualize that. My next question for you would be, “What's the first priority?” Or perhaps first course of action is a better way to put it if a breach has been detected.
Well, when you say “breach,” my mind goes to data breach. And regardless of whether it's a data breach or a data breach leading to ransomware. In the past, before ransomware was as prevalent as it is, the thought was you could take your time, observe what the threat actor’s doing, unless there's data actively leaving your environment. You could observe and take a more methodical approach. These days, because we see data breach as a precursor to ransomware so often, our advice is to immediately contain the environment, and that means cut off access of the threat actor. Usually, that means shutting down their connection with the internet. Of course, that's a hard pill to swallow for organizations that heavily rely on those services because it almost always disrupts the business. So that has conflicts with operations. When ransomware has detonated, it's an easy discussion.
But before it’s detonated, we have to convince the victim that they're about to get hit, and if they don't take action, they could face encryption of their systems. That’s why containment is the very first priority. Then after you contain, or after you cut off access, you need to make sure the ways the threat actor has accessed your network and dropped malware or has access via log-ins are fixed. Usually, that involves an investigation to find out how they got in and secure those means of access. We also typically go through an external penetration scan to find other ways the threat actor could easily get in and fix those as well. Because if you don't cut off that access, it could result in a very bad day.
I’m sure, and I guess if a breach is inevitable for organizations, how can they minimize the impact? Especially since there are so many different ways to be attacked.
So, before it happens? Minimizing the risk of getting breached, to begin with, or compromised? I would say that there are three things we recommend. The three most frequent means of access of threat actors are:
- Scan and exploit - which means finding a vulnerable web server or internet-facing server and exploiting it and dropping a web shell or some other way of compromising that web-facing server.
- Credential compromise - either password spraying or password guessing on a remote access service like VPN, Citrix, or RDP, and logging in and flying under the radar.
- Dropping malware in the environment via phishing, email, or something similar.
And so, to mitigate those risks in most of the breaches that we see, if the threat actor has gotten in, in one of those three ways, the number one recommendation we have coming out of an incident response engagement is, without exception, multi-factor authentication (MFA) on all remote access services.
We've seen cases where the victim thought that they had that covered, but then there was obscure VPN access for vendors that didn't have MFA. And so that's how the threat actor got in. And of course, to mitigate the scan and exploit risk, we recommend patching servers and keeping servers patched up to date.
There are a lot of (Microsoft) Exchange vulnerabilities in the news, and we're seeing those exploited in the wild today. So, keeping up on patching is inevitable. It's a must-have. And then thirdly, to detect the malware dropping in via a phishing email or something, we recommend endpoint detection with an EDR agent so you can see that malware executed in the environment.
I would suggest that's a front line of defense. Then, I would also suggest a “defense in depth.” That's a term we security folks use a lot. But in this case, to mitigate the things we actively see in incident response engagements, there are a couple of ways to secure the back end. And we do this during an incident response engagement. Microsoft will work with the customer or the victim to implement a secure tier model of their Active Directory and secure that Tier Zero, which basically means, if a threat actor is able to compromise credentials and log into the environment, they're not able to elevate their privileges to domain administrator, which is required for a lot of the attacks they carry out.
There’s also network segmentation. If your network is one big flat network, you’re allowing the threat actor to roam freely, and that makes it easy to compromise the entire environment. Network segmentation would put up some stumbling blocks for threat actors and keep them from being able to do that.
Fantastic. And so, Tony, my final question for you is what are some of the post-breach regulations that organizations must adhere to?
There are a lot of them, and it varies by jurisdiction, of course. Most I've found are privacy-related, like GDPR in Europe, and in the US, HIPAA has some requirements there. There are steep breach notification requirements for PII. And aside from regulatory requirements, I think companies need to also be mindful of contractual obligations to report breaches. There may be contracts with partners or with customers that require them to report. And I always recommend getting outside counsel involved, specifically someone experienced in these kinds of things to get their arms around what reporting requirements the victimized organization has, but I don’t pretend to have a full handle on those. And, you know, even if I did, it's not really my place to advise the customer on that. I always advise to get the lawyers involved when it comes to data breach reporting.