In the first part of this series, I discussed different kinds of attackers and why they attack our identity systems. I also discussed how they can weaponize our identity systems, turning what is meant to deliver services and do good into something that can be used to cause harm. In this part I’ll talk about the goals of the model, the disciplines needed to do this work, and the levels of maturity.
Goals of the Maturity Model
When coming up with this maturity model, I had 4 goals in mind:
- Defend against all attackers
- Balance protection and productivity
- Achieve greater transparency
- Promote data provenance
Defend against all attackers
Since all 3 kinds of attackers can weaponize identity systems, we have to defend against every time of attacker: Bulk, Single Data Subject, and Successor. However in order to do this requires that we have specialized defenses against each type. Said differently, a generic defense is in effective. In fact, one can think of this maturity model as a specialization of existing security controls for identity systems, but more on that later.
Balance protection and productivity
You want to keep your identity systems from causing harm, but you’ve got to keep the lights on as well. Our identity systems are valuable because they enable business processes of all sorts. Whatever controls we put in place to protect those systems must have as little impact on the usefulness of those systems as possible.
Achieve greater transparency
I am lucky enough to work for an incredible transparent company. Salesforce’s Ohana culture instills a sense family throughout our interactions and our work. From this comes our deep seated value of transparency. Interesting things happen when you are in such an organization. Transparency leads to cultural norms which I believe benefit identity professionals and the way people interact with identity systems.
Promote data provenance
This is a bit of a pet project for me… and people like Bob Blakley and Robin Wilton. Knowing where data comes from is incredibly important. The reality is that in our personal and professional lives we make decisions without always knowing where the data on which we made those decisions comes from. Fake news is an example of this in our personal lives.
I wrote about this years ago back in my Gartner days, saying:
Data handlers rely on contextual information about the data they are handling to make decisions. Today, that information is implicit and tribal in nature. When data moves from one system, department, organization, or country to another, it moves from one context to another. And in moving from one context to another, data leaves behind its handling rules, expectations, norms, and agreements unless something makes all of these things explicit and bundles them with the data before it moves. Better data-handling decisions can be made by labeling data with this contextual information…
Back then I was thinking about data labels as a means of communicating the context of data transfers. The hope was that a labeling system, which i called Relationship Context Metadata, could help in situations where you find a data set “in the wild.” You could understand who it was meant for, understand circumstances could it be used, and what to do if you found the data and it wasn’t meant for you. And I believe to prevent weaponization of our identity systems, data provenance has a hand to play.
The Disciplines Required
It is crucially important to acknowledge that in order to de-weaponize our identity systems requires more than just identity management technologies, techniques, and professionals. This mirrors the reality that in order to do anything “interesting” in a modern enterprise, regardless of geography, industry, or size, requires multiple kinds stakeholders and multiple kinds of contributors. Naturally this maturity model requires identity management capabilities, especially identity governance and access management. But it order to de-weaponize our identity management systems we identity professionals will need the help of our peers. We will need to enlist our security peers to bring their audit and data protection capabilities to bear. We also need to work with our data management peers because we will have to ask more of our data services tier.
Levels of Maturity
Like all good maturity models this one has 5 levels and like all good arrays its starts at 0. The 0th level is an enterprise’s baseline set of controls it uses to protect systems commensurate with the data classification of those systems. That is a long winded way of saying, “Keep doing what you’re doing.” When it comes to protecting identity systems, we must start in the same place as all of the other services in the enterprise. The maturity model adds 5 levels of controls to that baseline. In essence, the maturity model is a way for organizations to optimize their controls to protect identity data.
The 5 + 1 levels of the maturity model are:
- Baseline
- Managed
- Defend Against Successors Attackers
- Defend Against Bulk Attackers
- Defend Against Single Data Subject Attackers
- Transparency
In the final part of this series, I’ll discuss what kinds of controls are needed at each level. In the meantime, here’s a sneak peak.
