Identity Is a Co-owned Problem Between Security and IT

Who owns identity at your organization?

Identity is currently seen as an IT problem in most organizations. IT owns most of the identity stack (e.g., Okta, Sailpoint, etc.), and security usually has a subteam that interfaces with IT, which can lead to a disjointed identity management process. For example, security can get hit with compliance needs about identity (user access reviews, access/privacy controls, separation of duties, etc.). However, because IT usually owns the tooling, security often gets insufficient access — and sometimes only gets the logs that are shipped to their SIEM tools (e.g., Okta system logs are shipped to Splunk and then security has to make sense of them) — making it difficult to approach identity compliance in a cohesive and effective matter.

Security’s main way of addressing identity today is essentially asking IT for help: “can you grant me this access for compliance,” “can you implement this type of policy (e.g. only SWEs get GitHub),” “can you help rollout this tech (e.g. SSO, 2FA)?”

So who should own ‘the identity problem?’

Identity is (and should be treated as) a co-owned problem between security and IT because both departments have a vested interest in ensuring that user identities are effectively managed and secured. They are both crucial members of the identity team, and any identity management solutions must involve both as equal members lest they be incomplete and shortsighted.

This is easier said than done because, oftentimes, security and IT have other interests that are at odds. While IT typically owns the tools and processes for managing user identities, security is responsible for ensuring that those identities are properly secured and that, ideally, access is only granted on a need-to-know basis.

For example, IT typically wants to give as many people access as possible to reduce ticket load. In contrast, security wants to limit access in order to keep their organization as secure as possible. While, theoretically, your organization is at its safest when users only have as much access as they need and nothing more (a concept we expand on here), that can be a logistical nightmare for IT, who has to keep granting that access.

In order for both departments to work effectively together, they need to collaborate closely and communicate their priorities. This might involve setting up regular meetings or working groups to help IT better understand security’s concerns or vice versa.

For instance, many IT folks want to be more security-aware and knowledgeable. Still, they may find it unapproachable, so security could set up meetings, workshops, or coaching to help IT develop a security lens. Conversely, a lot of security folks want to empower the business while doing their jobs, so it could be helpful for them to gain empathy and understanding of what the IT workload at their company looks like — through something like rotational programs, a fresh perspective could help them collaborate with IT to build a system that meets both of their needs.

Ultimately, the goal should be to create a shared understanding of what “identity” means within their organization’s context and to work together to create a system that meets both departments’ needs. One place to start is with an agreement between IT and security on what they care about and what certain terms mean (e.g., Are someone’s SSH keys part of Problem A? Is HR the complete source of truth, or is some information in HR and some in your IdP?).

The trickiest term here is “identity” itself. You can use it to mean machine or human identity; identity can mean the way that you authenticate and sign on to SaaS, or it can mean the email and profile data (job title, manager, location, etc) that constitutes a person or the credentials you use for getting access to infra.

Identity information is often fragmented: across different SaaS apps (like Notion vs. Slack), across infra (e.g., SSH keys), across IdP (which you may have multiple of), and across HR (e.g., your BambooHR profile). As a result, it’s hard to say what’s “true” if any of those sources of identity conflict, and it can get weirder if certain pieces of information are true in one place, and others are true in another. For instance, your legal first name in HR might differ from your preferred first name in Slack, and your job title might be different in Okta (e.g., Software Engineer II) than in Google (e.g., Software Engineer).

Because there’s likely no single place this information lives, one way to mend this fragmentation is through products that not only manage access but also combine IT and security interests in regard to identity. Identity and access management (IAM) solutions do exactly what they sound like they do: they help you manage user identities and who has access to what resources in your organization (AKA security authorization as opposed to authentication). Where many IAM products are more IT-focused or more security-focused, modern identity solutions like Crosswire recognize that identity is a co-owned problem and approach it as such.

For example, Crosswire gathers permissions across different enterprise applications to implement rule-based access without human intervention. It automatically provisions access and identifies anomalies, providing the IT infrastructure to manage authorization at scale. On the other hand, Crosswire also uses GPT-4 to analyze access to high-risk apps in Okta, matching app assignments to employee job responsibilities and then applying auto-remediation from step-up 2FA to manager approval at SAML sign-in time, neutralizing pass-the-cookie attacks for security.

To stay up to date with Crosswire on all things identity and infosec — trainings, webinars, blog posts, and more — come see us at Booth 21 at RSAC 2023 and sign up to receive our updates below!