Four Reasons Why Traditional SIEMs Fall Short For Identity Security Programs
Security teams are struggling to combat increasing identity threats effectively. Why? Because they’re using yesterday’s technology stack to solve today’s problems.
Security Information and Event Management (SIEM) solutions have been used by security teams for many years to detect and respond to security threats. SIEMs “gather event and log data” and “bring that data together on a centralized platform.”
Want to extend this to identity threats? Easy! Simply ingest identity data, and voila.
Not so fast.
Unfortunately, many security teams have tried and failed to do this. First, only some have access to the myriad of identity providers and IAM tools that IT teams own. Second, even if organizations consume identity data in their SIEM, only one-quarter use them in their detection rules. SIEMs were built for firewalls and endpoint detection tools, not for people.
In this blog, we’ll explore three main reasons why SIEMs do not work for adequate identity security, why that is the case, and how security teams can overcome this challenge.
TLDR: This isn’t only a cost thing; SIEMs are simply not built in a way that can effectively monitor for identity security issues.
1. Writing and maintaining detection rules
Writing effective detection rules is hard, especially if you want to minimize false positives. From mismatched event types to regex problems, a wide range of technical mistakes can break SIEM detection rules. Specifically, there are two main problems when it comes to identity security:
Event formats and sequences change all the time
For building a good detection rule, you need a team that can identify an IoC, match its pattern, and understand its variations if the attacker changes it (even marginally)
While rules are sometimes provided out-of-the-box, research has found that 75% of these rules are disabled “due to noisiness and customization challenges experienced by detection engineering teams.”
External support is needed if teams don’t want to spend most of their time managing their SIEM. You will need a hefty professional services budget to write and maintain these detection rules.
Even if you have bottomless pockets to write flawless detection rules, you still need to know what to look for in the first place. Be prepared to revisit these rules as new identity attacks emerge continually.
2. Not all issues are event-based
By their nature, SIEMs help you to analyze event data. A SIEM may detect an unauthorized login attempt or a user attempting to access a resource they are not authorized to access. However, they cannot prevent these events from happening in the first place.
For example, how would you detect the following with a SIEM?
24% of your accounts are dormant and could come back to life at any point;
40% of accounts have no strong MFA;
Deprovisioned users have not been deprovisioned;
80% of assigned applications go unused by users.
Discover what admin accessed a service account
All of the statistics are not hypothetical; they are what we discover for the average organization.
Done well, a SIEM might detect identity attacks, but it won’t prevent them.
3. Missing context
Identities have a lot of context that you miss by only looking at a stream of events. Unlike machines, the activity of users comes low and slow, which makes it tricky for SIEMs to make sense of this.
However, context about the user is critical for informing a response. For example, what is ok for a person to do is not ok for a service account. While it is normal for a user to log in, service accounts are usually used for backend-to-backend communication and are not supposed to.
Another example is the role. The risk presented by a summer intern is not the same as the CFO. Similarly, an Account Manager should not be treated the same as a domain administrator.
4. Hidden storage and licensing costs
Finally, security teams have to grapple with some profound financial implications.
First, most SIEMs charge based on the amount of data ingested and collected. Doing so creates a disincentive to increasing your visibility.
Second, SIEM license costs can be extremely high, resulting in data silos. For a successful identity security program, security and IAM professionals must work together to detect threats and reduce the identity attack surface. Unfortunately, existing licensing models thwart effective collaboration.
Oort, for example, is built on Snowflake to overcome these cost challenges. This enables security teams to gain comprehensive visibility into identities and detect anomalies across enormous datasets–all while controlling their own data.
Oort’s Unique Approach
You only need to connect Oort to your identity providers, and we’ll do the rest. We collect users, groups, applications, devices, authenticators, and events. This enables us to detect identity threats AND your identity attack surface issues.
These insights come with vital context, such as whether or not it's a user or a service account and whether it is a break glass account used for daily operations. In the case of an incident, the ability to answer these questions in real-time allows the responder to be much more effective. And as we know, time is money.
Do you still want to have this information in your SIEM? No problem. We can integrate and feed these high-fidelity insights into your existing SIEM tool.
With Oort, you get all the insight without any financial and detection limitations described above.
Get in touch to learn more about our approach!
