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:
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.
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:
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.
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
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.
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:
2. Storage: Have a storage solution that can support:
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:
6. Understand the threats and needs in the space:
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!
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.