Identity Management – Playing a Key Role in Organization Security
Participating in Oktane21, Okta’s annual conference, made it clear that this year, more than ever, that identity management takes a critical role in the reality of corporates. The remote workforce, the rapid shift to the cloud, and the increase in cyber attacks targeting employees via spear phishing campaigns and online scams have been some of the contributing factors for the exponential growth in the importance of identity and access management (IAM).
The 2020 Verizon Data Breach Investigation Report covered more than 32,000 security incidents, of which almost 4,000 were confirmed breaches—nearly double the number of breaches from the previous year. Over 67% of them were caused by credential theft and social engineering attacks such as phishing and business email compromises. This is a steady increase in these methodologies, proving the critical role identity management plays in prevention of security incidents.
Identity not only plays a key role in network penetration – it also plays a role throughout the entire attack kill chain: from privilege escalation to persistence.
Smoking Gun For Detecting Attacks
But the role of identity management doesn’t stop in the prevention of attacks. It also offers a unique opportunity for us as defenders to spot attacks and stop them.
A great example of the power of detection came in December from FireEye, when their team was the first to identify the SolarWinds attack. The hackers, who had already gained access to one of FireEye employee’s credentials, used them to register their own device to FireEye’s multi-factor authentication system so they could receive the employee’s unique access codes. This triggered an alert to the employee and to FireEye's security that a new device had just been registered to the company’s MFA system. The employee was vigilant enough to contact security which prompted FireEye to initiate a massive investigation.
It was when FireEye was trying to find the source of this incident and determine how the hackers obtained the employee’s credentials to register their device, that they uncovered the SolarWinds Orion backdoor.
This is a great example of how an MFA alert can serve as the smoking gun for an attack. But let’s be honest – not every organization is FireEye: not everyone will be as vigilant as their employees. And not all organizations will be able to effectively connect the dots the way one of the best Incident Response teams in the world did.
To be able to spot malicious behavior, organizations today need to have a powerful way to sort through endless amounts of data and sort out threat signals.
The Needle in the Haystack
Since identity represents human behavior, it is always unpredictable and chaotic. So when trying to use IAM data for the detection of threats, we are dealing with the hardship of finding a needle in a haystack.
For example, the list above is taken from an Okta blog suggesting the type of user and IAM events to monitor for suspicious behavior. The challenge of monitoring user data is the amount of data generated: each user, through the course of the day, can potentially produce hundreds of logged events. Multiply that by the number of users in the organization, and the amount of data to sift through becomes quite daunting.
In addition, examining user data for suspicious events requires some level of baselining to know what “normal” activity looks like. Normal activity may also vary by user group or regions. For example, access to Salesforce may be typical for users in a marketing group and atypical for users in engineering. A lot of what was defined as “normal” changed once organizations switched overnight to remote work due to the pandemic.
User activity alone is insufficient to determine whether an organization is under attack, but when taken with context and used with other indicators, user activity can be a piece of evidence pointing to an attack. Once an unusual user or system activity is discovered, this event can become a starting point for a broader investigation.
Connecting the Dots
Let’s review an example of a simple, relatively common attack and see how security teams can reveal it.
In this case, a targeted phishing attack was directed at the organization, and one employee clicked on a malicious link in the email. As a result, his credentials to the cloud were compromised by the attacker. The attacker used the stolen creds to access the cloud, took a disk snapshot, generated a download link and used it to exfiltrate data from the company’s cloud storage.
Now let’s see how this series of events was captured by the security tools of this company: the endpoint detection and response (EDR) tool identified a DNS query to a domain with low reputation, which is the malicious link. But by itself, this was not identified as malicious and therefore not alerted in the EDR system.
The anomalous sign in to the cloud, from a new location, was captured by the cloud service, but not escalated to an alert as it is not necessarily malicious. Only the creation of a disk snapshot link was suspicious enough to trigger an alert, even though by itself it is also not necessarily a malicious behavior.
A security analyst that will need to determine if this is a malicious or benign activity will have to spend time looking through EDR and cloud authentication logs, that are all disjointed.
Identity is the way to piece together these events, and Okta, as well as Microsoft AD, are powerful tools that could help put together that attack story: who is the user that took the disk snapshot, was his access to the cloud legitimate, was his endpoint compromised, etc.
Users and their data are often the glue that can put together the pieces of the puzzle.
But piecing identity data, if done manually, is hard, as identity-related data is highly variable across the different security tools.
Take for example in this case how many different entities are related to the activities spotted: from network identifiers to EDR and public cloud telemetry. The variety calls for automation algorithms to help piece them together.
And this is exactly what Hunters’ “Person-Matcher” algorithm does. Hunters XDR automates and streamlines incident investigation. And for that, being able to connect entities related to a specific user is key. Using Okta (or Microsoft Active Directory) Hunters XDR stitches together usernames, emails, devices employed by the user, cloud accounts, and others, to be able to link together activities that otherwise would look disjointed.
Here’s a demo that shows how Hunters XDR detects the phishing attack described above, in an automated way:
Hunters XDR applies deep security knowledge to drive effective detection and response across all organizational environments. Using Okta’s API, Hunters XDR seamlessly ingests Okta logs and telemetry as a key knowledge source for detecting suspicious behaviors, mapping sparse identities into actual users, and enriching and adding context to the automatic investigations performed by Hunters XDR.
Customers utilize existing Okta’s logs and native alerts such as the ones from Okta ThreatInsight to broaden their detection and response all across the enterprise with high-fidelity correlations, and achieve:
- Meaningful Attack Stories using Hunters’ Knowledge Graph to correlate Okta’s alerts and threat signals with telemetry from other security products from endpoint, cloud or network.
- Correlation of users’ SaaS activities by tying them to their Okta identity to understand the full story and whether there has been an illegitimate access or use of corporate resources.
- Leveraging user-based data like permissions sets, applications and employee’s profile with a specific user to investigate and enrich security telemetry from other data sources.
- Wider visibility and better understanding of the security posture all across the enterprise.
