We’ve talked a lot about Insider Threats. They are a Big Deal™ and deserve the attention. In fact, I did a webinar recently that went into a bit of depth on the subject, ”Insider Threats Deep Dive: Case Studies for Advanced Analytics.” Unlike the usual presentation, where it goes into the tools, techniques, and use cases, we took the opportunity to dig into a couple of specific insider threat case studies that highlighted where behavior analytics could have shown its strength.
Case Study vs Use Case
One of the things I’ve encountered is that a lot of people conflate use cases with case studies. And by a lot of people, I include writers in the security industry who do the same thing. So, to get that out of the way, I’ll define use cases as specific problems that you need to solve. An example in our Insider Threat context, beyond Insider Threat being a security use case, is privileged access abuse. That’s a use case where the specific problem is admin level users doing things they shouldn’t.
In contrast, a case study is a specific case looking at how one organization handled a particular use case. For example, Acme Corporation installing an access management system and behavior analytics to address the risk of admin abuse.
With that out of the way, I can talk about the two insider threat case studies we used in the presentation.
Studying Cases
The first one was a summary of a fairly famous retail sales breach, where the attackers gained access through a 3rd party HVAC vendor. The attackers gained access to the vendor portal, then pivoted to the internal network where they compromised a domain controller, and from there the PoS terminals. Once they had the terminals, it was just a matter of skimming payment data, dumping it to an external FTP server, and picking up the ill-gotten gains.
I considered this one an Insider Threat because by breaching a 3rd party vendor that had access to their victim the attackers effectively became an insider, albeit one of the more limited members of the Insider family. This is also a case Gurucul wasn’t involved with. But it was a good example to show where having behavior analytics in the stack could have mitigated the threat.
We’d See That
For example, if the HVAC vendor had been running security analytics, they would almost certainly have detected the account compromise that led to the next stage of the attack. Though, one of the challenges is that a lot of smaller vendors don’t have the budget needed to field a full security stack of their own, or they rely on an MSSP who may not have it in their offerings.
This “3rd party gap”, where it’s hard to hold 3rd party vendors to the same security standard your own organization follows, deserves a talk of its own.
The victim here also wasn’t one of our customers, but they could have benefited from having our security analytics in their stack as well. Since everything the attackers did was outside the normal behaviors they’d expect, there were multiple opportunities to identify the attack and break it up before it reached its goal.
Access abuse on the Vendor Portal, with logins from strange locations at unusual times? That’s unusual behavior we’d see.
Pivoting into the network and accessing a domain controller? Also, unusual behavior we’d see and raise the risk score of that user and asset(s).
PoS terminals dropping data on some non-standard share, and that share reaching out to an external FTP server? Yup. Same thing.
You get the idea.
And Then There’s This One
The second case study I went over in the talk was one where an attacker had taken a contract job with a healthcare provider and used his position to compromise internal systems. The attacker here was less successful in meeting his goals, but it was still an interesting case and had some points where behavior analytics could have caught him.
In this one, the attacker took a job as a security guard at a healthcare provider and was posted to an unsupervised night shift. What the employer didn’t know was that the attacker was the leader of a local APT group and him taking the job was part of a plan to gain access to the target’s resources to launch DDoS and other attacks.
The attacker was able to leverage his position to gain access to an HVAC controller in a locked closet (there’s that HVAC thing again) using a range of common attack tools, including password crackers and their kin. He also compromised some nurse’s workstations, which gave him access to patient records and other information which, fortunately, he didn’t pursue. His downfall was that the attacks on the HVAC system caused some instability which the facility noticed, which led to an expert coming in and identifying the breach before the attacker could leverage what he’d gained.
With this one, behavior analytics could have highlighted the problem at several points. Given the ability to take in threat intelligence feeds and data from the HR system, it’s possible the system could have identified this person as a risk before he was ever put in a position where he could abuse his access. Admittedly, that’s a best-case scenario, where all the information was available and using it didn’t run afoul of privacy laws, but it was certainly possible.
The more likely case was that he was identified by the card access system as he was entering areas of the site outside his usual rounds – after all, even when security checks the supply cabinet, it’s a little suspect when he’s in there for a couple hours at a time. Or he would have been identified trying to brute force the HVAC system’s password, or by the unusual access to a nurse’s workstation. Or any of a number of behaviors he exhibited during the intrusion.
If Only
We weren’t involved in either of these incidents, but these insider threat case studies highlight where Gurucul’s Unified Security and Risk Analytics platform could have disrupted the attacks before they turned into major incidents.
Want to hear it in more detail? Then check out the presentation on BrightTALK. I go into much more detail on these insider threat case studies – enjoy!