Mind the Gap

An Open Letter to Security from Identity

Identity teams and Security teams struggle to work together. The problem isn’t that there are good people in one and bad people in another; it’s not that there are some core, foundational reasons why it can’t happen. These two domains have simply developed best practices, tools, and habits independently of each other over decades, and threat actors have adopted new habits in recent years taking advantage of that fact. So, we’re in a hard spot, but there are lots of ways for us to get out of it.

Why is this a problem?

The fact that identity and security teams aren’t in lockstep matters because it affects both of their missions, which has material effects on their organizations. Identity teams can’t manage tool costs, help desk workload, and improve end user experience without considering security needs. And, likewise, security can’t optimize their ticket count, improve their visibility, or work on new threats if they’re constantly responding to identity alerts.

Can you imagine if there was a city where the fire marshall and fire chief never spoke? Where the person in charge of responding to fires never worked with the person who tries to prevent them in the first place? It’s a ludicrous idea, but at so many companies I have worked with and teams that I’ve interviewed, this is exactly the kind of situation they’re struggling through. It’s nobody’s fault, it’s just that arsonists have started behaving differently, and now it’s more important than it used to be that the two work in tandem.

As we’ve seen in so many publicly available incident reports, attacks jump between domains. We all know this to some extent - after all, any random walk moving through the MITRE ATT&CK matrix is likely to have some mix of network, application, identity, cloud, and on-prem touchpoints - but it’s worth re-emphasizing. Conway’s law says that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” This is often referred to in product organizations: if you’ve got one team working on function A, and another team on function B, end users are liable to be frustrated at how, even though A and B are both great by themselves, they don’t work together all that well. Identity and security teams are shipping their org chart.

Threat actors take advantage of this fact on a regular basis. Take a look at CISA’s FY22 Risk and Vulnerability Assessments (RVA) Results: MITRE ATT&CK Tactics and Techniques. Map any route from reconnaissance to impact and you’re almost sure to jump between Identity and something else. “Things that can be mitigated by the identity team, or detected based on data they give to the security team” will dominate the observed use of techniques in initial access, persistence, privilege escalation, credential access; and will be almost totally absent in all other tactics.

IBM’s most recent Cost of a Data Breach report lays this impact bare: there’s a frequent correlation between the most expensive attacks and initial access vectors through the identity layer (figure 10). A resilient plan consisting of the most effective preventive measures will require work from both the identity and the security teams (figure 16).

Recognizing any one of these individual MITRE techniques is not easy to do at scale. Most security teams track some version of true-positive rates among their detections; this is important, since it contributes directly to analyst workload, and therefore burnout, total staffing costs, and coverage capabilities. However, the kind of true-positive rates that security teams need can be extremely difficult to achieve in the wildly noisy, odd-because-humans-are-odd world of identity. It takes expertise in both domains to arrive at an effective, sustainable strategy, and that usually means expertise from both teams working together. It is rare for organizations to have a dedicated identity security team, with its own people, process, and technology.

Where does this problem come from?

A lot of academic research has gone into the idea of coordination costs: if I’m doing one thing, and you’re doing another, how much time, energy, and effort do we have to dedicate to making sure we’re effectively moving towards our shared goals?

“if the actions of specialized units impose binding constraints on each other, or if the underlying nature of interactions between the units is unknown or ambiguous (Ethiraj & Levinthal, 2004a, b; Siggelkow, 2002) there can be significant gains from collaboration (Rivkin & Siggelkow, 2003)” - Integration Through Incentives Within Differentiated Organizations, Kretschmer & Puranam, 2008

If the identity team decides that they want to get rid of MFA, that places a binding constraint on the security team. Likewise, if the security team decides that they cannot afford account takeover incidents at a given rate, that places a binding constraint on the identity team. And anyone who says that they understand every single thing in their SIEM or identity stack has a bridge to sell you. However, in many organizations, teams, budgets, and manager’s incentives are set up as if these were totally independent operations! A given identity team might get a budget to work on a specific IAM outcome; or, an SOC manager might earn an annual bonus based in part on their ability to reduce MTTR. However, you have to get pretty high up the org chart - and far away from the hands-on-keyboard work that reinforces how much identity and security intersect - to find someone whose incentive structure accounts for both sides of the coin.

We see this kind of incentive structure play out explicitly in the way that employees are often rewarded:

• You get your base salary no matter what

• You get your bonus based on your performance - this is your manager’s way of asking you to fill in all of the gaps that lead up to the outcomes they want from you, specifically

• You get a stock grant based on how the company does - this is your company’s way of asking you to fill in all of the gaps between your job and your coworker’s to make sure that the company does well

What we’re seeing here is that identity and security teams are both doing a great job in earning their individual bonuses, but don’t have the tools and processes to improve the company stock price. In fact, according to IBM, “Poor collaboration with teams outside of SOC team” is cited as the top contributing factor to alert response time.

Finally, there are a million cognitive biases at work against us here. Unlike back in the day, where there had been less explosion in complexity and vendors, expertise in just a sub-section of security or identity is a full-time job, since everything has become so complicated and the domains have gotten so large. So, people focus on one slice of the pie and work on what they know. In other words, you’re an expert, so you try to solve problems within your field, you understand your field better than you do others, and you see a lot more stuff about your field than others.

• Anchoring bias

• Egocentric bias

• Availability bias

• Ingroup bias

What can you do about it?

Formalize the lines of communication. Who, specifically, is responsible for deciding on a new authentication policy? Who is pulled in as an advisor to that decision? What about remediation for incidents - who executes that? What about a retro for the incident - who’s invited to that? If you can’t answer these questions, it could be a sign that there is friction between your teams.

First off, start the conversation. If you don’t know each other, that’s a great starting place. The teams I’ve seen who work best together, who have the most effective identity security programs, are on a first-name, joking basis, and they understand each other’s pains, daily work, and strategic goals. The teams who struggle the most are vaguely aware that the security team does this or the identity team handles that…but for the most part, those other teams are just an email address they occasionally use.

Second, formalize the work you have to do. Who, specifically, is responsible for deciding on a new authentication policy? Who is pulled in as an advisor to that decision? What about remediation for incidents - who executes that? What about a retro for the incident - who’s invited to that? Who has read-only access to which tools, who has break-glass access, and who should be managing policy day-by-day? If you don’t have a clear line of understanding for these types of questions, it’s a good sign that you aren’t effectively addressing identity risks in a holistic sense. There are likely gaps in your compensating controls, or excessive costs showing up as help desk tickets, SOC alerts, or IAM budget items.

Third, purposefully reach out of your area of expertise and ask the other team what matters to them. Are they tracking MTTR for new alerts? What about authentication events per day per user? Number of help desk tickets? Something else? If you can learn what it is that they care about - what keeps them up at night, what they put work into daily, what they get evaluated on annually - you’ll be much better prepared to evaluate your problems and decisions from their perspective, which is an indicator that you’ve improved your identity security program. It’s also good to walk through this exercise at both the peer level as well as up and down your org chart. Does your boss care about this quarter’s budget? Does their boss care about next year’s business strategy? Being able to measure your impacts in terms that they care about can only help you.

Fourth, get into their tools! This might not be literal - not everyone can get a seat for every tool, after all. But the point is that you should dive into the nitty gritty. Do you, the IAM manager, really grok why alert fatigue is a problem? Can you, a security analyst, explain why it’s so hard to present one unified authentication policy across all access points? Can you tell each other the challenges of deploying webauthn, and what threat vectors it mitigates?

Fifth, look into tooling that can help you work on improving these efforts. There are some really cool products out there that are jam-packed with features resulting from folks studying these problems. You’re not alone in struggling with this!

Finally, as a wise Jedi once said: Be Good to each other, Be Kind to each other, Love each other.

Joe Duggan is a product manager at Duo Security, where he works at the intersection of identity and security teams. He focuses on ITDR and seamless authentication. You can find him in the IDPro slack, or on LinkedIn. Read more about what Joe and his colleagues are up to here.