Skip to Main Content

The Identity Core

What’s the definition of a core? Years ago, there was this cheesy movie about the possible destruction of the planet. Side note: it was a weird time then. We were obsessed with making movies about the billion ways we would all die… anyway, I digress. But in this cheesy movie, the center of the Earth had stopped spinning, and because of that all kinds of strange and deadly side effects were occurring throughout the world– and they were only going to get worse (cue dramatic music… dun-dun-dunnnnn).  In typical movie fashion, they come up with a plan that costs billions of dollars, requires inventions that haven’t been created yet, and try to pull off a project in a matter of months that would typically take 20 years. But hey, it’s a movie, right? Now let’s talk about why this was so dramatically important.

What exactly does the Earth’s core do?

Scientists have theorized that it’s responsible for the Earth’s Magnetic Field, which is essential because it protects the Earth from harmful radiation and solar winds. Without delving into the exact science of it, let’s suffice to say that the contents of the Earth’s core, along with the rotation of it, generate the field that surrounds the Earth. If something were to happen to the core– it stops spinning or the composition of it changes– it would alter the magnetic field. The example shown in the movie was this: imagine the Earth is an apple, and the sun is a can of aerosol spray and a lighter. The core stops spinning, the magnetic field goes away, and the heat and radiation from the sun torch the planet. Ouch.

So, what does any of this have to do with identity?

Everything, really. Hear me out. If you don’t implement identity at the core of your security architecture, the sun will scorch the Earth. OK, not really, but there is a parallel to the cause and effect relationship between identity and your security architecture.

Every single security construct we’ve created and implemented revolves around our need to answer a fundamental question. Who are you? Based on the answer to this question, we launch a plethora of activities, authorizations, and interactions with you to determine if you are who you say you are and decide if you should have access. Nothing works if we can’t identify in some way which the user is in our infrastructure. We start with the basics. We assign every user a login and a password. We did this so we could uniquely identify that user whenever they wanted to interact with our applications. We needed to identify them so we could decide what applications this user can access, and furthermore what actions they can take with said application. We create a very delicate chain of identity that we depend on to protect our apps and our data. As we build more and more applications and need access to more and more things that identity chain becomes a common thing that we just assumed would be there and we could trust, but as we quickly found out with the year of the data breaches that infrastructure wasn’t nearly as robust as we thought it was.

The reason for this is that we ignored the foundation of our architecture. We forgot about the core, and at some point, it stopped spinning. We spent our efforts building up the outer edges of the architecture, firewalls, VPN’s, authorization engines, SSO, etc. However, we failed to build around the central piece itself, which is identity. Remember our fundamental question: who are you?

To establish a record of identity that we can trust and use to answer that fundamental question, we have to create our baseline for who a user is.

When does someone’s digital identity begin in our infrastructure? When they apply for a job? When they accept the job? When they onboard? At some point, we establish a precedent for collecting information that we will use to determine who that user is. Since knowing who someone is creating the foundation for our security posture, we want to make sure that the information we are collecting is accurate and is stored in a manner which can be shared and utilized by other systems. The process in which we collect and move that data should be well understood and transparent to the systems that need it.

Next, we need to determine what information from that identity is most important to us from a security standpoint. How does a person’s identity affect the access they have in my organization? Does position matter? How about location, department, region, etc.? Does Mario, our VP of HR, get access to more applications than Linda, our tier 1 support agent? We need to understand the attributes of an identity that matter most for granting access.

Once we know what those attributes are, we then need to ensure we have a process in place to protect the integrity of those attributes. In our previous example if Linda does have more access than Mario, and Linda’s attributes were placed in Mario’s profile does that raise a concern? When those attributes change for good reasons, like when Linda is promoted to support manager and now has a need for more applications, how do we handle that?

Establishing a baseline of identity is critical to our success in having a robust security architecture. To accomplish that, we have to develop standards and processes to ensure that the core of that architecture is trusted and sound, that way the systems that rely on knowing who a user is, and what attributes they have can process those decisions from a trusted source because a mistake at the identity level ripples through the entire security architecture: corrupt identity practices, bad security posture — no scorched Earth with a sad core. Let’s avoid that at all costs by clearly defining identity from the very beginning of time.


Discussion