8 Things to Look for in an ITDR Solution
What would you say you do here? (Office Space)
In 2018 I inherited the single sign-on project for Cisco security. Unlike my predecessor who tried to build an SSO solution on his own, I opted to leverage our Duo acquisition for MFA and Okta’s Universal directory. The team and I unstuck a 3 year project in less than 9 months and moved 6 products under management. While I love both these products (and Auth0 as well), when I was talking to my SE, I found a few gaps that made me start asking:
1. How do I know what factors a user is using?
2. Who are my admins and what are they doing?
3. How can I detect if any of my users get breached?
4. Are my users trending up or down?
Oh, and I wanted something I could easily pick off the shelf and deploy without a science project. Unfortunately, it ended up being a massive endeavor.
As I was rolling out the project to answer my four key questions I learned that while Identity Providers (IDPs) are critical parts of the security platform they are not geared or built to be part of the security ecosystem like traditional platforms. If you look at firewalls and Endpoint Detection and Response (EDR) platforms, they have robust analytics backends that can be secured stand-alone or connect to your SOC platform, SIEM or enterprise monitoring tools right out of the box. I was looking for something similar to Cisco’s SecureX or Cortex for identity, maybe a few built-in plugins and dashboards in Datadog, but I noticed that even the events for multi target outcomes (an application and a user for example) was not processed correctly by most platforms, not to mention analyzing which of my users are at risk.
Is it a security problem or is it an IT problem?
IDPs live in the zone between IT and Security and no one really wants to own them, therefore robust tooling has never been developed. The team I worked with at Okta offered Datadog or Splunk as the way to go. We used both but still didn’t get what I was looking for.
As we continued to deploy our IDP we discovered a few others lurking in the shadows. I needed to understand how Azure AD, Slack, Google Workspace, Salesforce and Ping worked with our main IDP.
Furthermore, the business needed to know:
How far are we into unifying our identity solutions? We always need to justify the cost of identity projects. Without knowing where we are, we might deploy bad policies or worse, launch massive marketing campaigns to solutions you can’t login into.
How fast do we block access in various scenarios? Knowing time to remediation is a critical security metric.
Where do we stand on various migration projects? Unifying IDPs comes as both a cost reduction exercise and security solution. If you are still paying for both, you might be missing the goal.
Which IDP the users actually use? Our customers could have used the pre-existing built in IDPs in the applications, might have brought their own IDP or used a social login. Understanding these trends were critical for feature development and policies we would like to enforce.
Who are our users? Are our customers logging in to our system? How do we know?
Does MFA registration or email confirmation cause users to drop subscriptions? The business might swing between “everything needs MFA” to “why do we need security?” based on weak metrics. The ability to show security posture impact on business helps navigate these mood swings without relaxing meaningful policies.
Along came COVID...
Initially the need for ITDR was clear for consumer or B2B IDPs. Workforce, on the other hand, was presumed to be well-defended behind firewalls, EDRs and other on-premise solutions. COVID accelerated a few trends.
First, there was a clear move towards cloud-based and SaaS solutions. In order to function, businesses needed to implement platforms like Workday, Salesforce, and Okta. When your workforce is at home, it makes more sense to have users go directly to the cloud.
Second, a similar shift was happening in infrastructure, with organizations looking for cost-savings by moving to on-premise servers to AWS, Azure, and GCP.
Third, the great resignation changed the workforce itself. Most organizations now rely on a large number of contractors. Due to remote hiring, many managers have never even met their full-time employees.
New opportunities for attackers
With these changes attackers adjusted tactics to take advantage. Phishing, credential sharing and stealing sessions came back with a vengeance. It’s cheaper and easier to execute than a complicated malware-based attack. All you need is a fake website and a few emails. Don’t believe me, just read up on the Lapsus$ and 0ktapus attacks, executed by 16 year olds.
Or listen to Dimitry from Avid's experience as employees outsourcing their jobs.
Now you have the need for a dedicated solution for identity that can cover both consumer and workforce identities.
Customer Interview with AVID technologies
Why can’t your SIEM be your ITDR solution
SIEMs are awesome for correlating events from very chatty systems like firewalls or EDR/XDRs. They are built to alert when a chain of events, like automated malware traverses your organization, because those are machine-based patterns. For example, you may well be able to write a rule that will detect if an admin logs on from a new IP. It will lack a lot of context about that user, how they historically login, with what devices, factors, and so on. But you could do it. You will also miss directory information such as the person's role, 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.
What you can’t do with SIEM rules is detect issues that are not event-based. You cannot detect inactive guest users. You cannot detect state changes. These are fundamental pieces of IAM hygiene that create opportunities for attackers. Some tools only focus on detecting the threats, but I think that misses a key element of reducing your identity attack surface. This is expanded when you see events that relate to a state such as inactivity, like a dormant user that starts being active after a long time of low and slow guessing attacks. Or the connection between a guest account to an internal user who is on an expiring contract or is about to be terminated.
Last, the staff that creates the detections for SIEM solutions has not been incentivized to build detections that are identity-related. Now, you can go off and build those detections via contractors and 3rd parties, but as we all know, detections and rules need to be constantly adjusted and updated. Ask yourself, are you staffed to play whack-a-mole with every new threat? The other option is to consider using the right ITDR solution. What does "right" mean? See my suggested list below, but in comparison to a SIEM solution, you need something that can deal with both high volume of login and audit events, while being able to correlate and enrich the data from directory and HR sources.
Evaluating Identity Threat Detection and Response solutions
Until now, getting the degree of visibility and control over identities for security purposes has required immense amounts of heavy lifting, taping and gluing capabilities together and, even at its best, still doesn’t deliver what I originally needed with my 4 main questions. ITDR can. But like all new shiny objects, every vendor is going to hop on the bandwagon and claim they can solve your woes. Be careful and make sure you get a solution that can do what it promises.
I’ve put together my view as a former practitioner of must-have criteria when evaluating solutions for ITDR.
1. Sources: Build an ingestion pipeline that includes:
IDP information (Okta, Azure, Google)
Productivity suites (Google, O365)
Messaging tools (Slack, Teams)
People information (HR)
Networking infrastructure information
2. Storage: Have a storage solution that can support:
Structured (like a database)
Semi-structured (e.g. log information) data.
3. Standards: Adhere to a standard as close as possible; SCIM is your friend
4. Operationalize effectively: Support lightweight automation based on Slack, ServiceNow and Jira.
5. Make the data accessible:
This can include digests in the tickets, enabling users to diagnose and react to issues easily.
Meeting the users where they are should not be a slogan, it should be done by design.
6. Understand the threats and needs in the space:
Session hijacking, available with a simple tool
Account takeover or sharing (they look the same)
Assess if unsuccessful attack research is worthwhile with your current budgetary constraints. Everyone gets attacked, all the time, continuously. You need to know are they looking at me, or is this a drive by where my MFA solution is holding up.
Understand if your MFA posture is the right one for your specific threat landscape. Some organizations can thrive with lightweight MFA, while others need strong cryptographical based solutions and tight refresh process.
7. Part of something bigger: Try being part of an ecosystem, such as Snowflake or Databricks that allow sharing of information with other parts of your security team.
8. Fulfill key questions and needs: Understand if you can answer the questions I asked in the beginning!
What now?
This long treatise is me trying to save you the lessons I learned the hard way. Leaving the identity part of your security solution and program in the dark seems to me an invitation for trouble. Consider getting an assessment for your program from a third party (We at Oort offer one for free, but feel free to ask your Azure or Okta reseller for one). Furthermore, start building KPIs for that program, don’t know what they should be, feel free to DM me on LinkedIn I can talk about these for hours.
