I was talking to a long time competitor/colleague/client/friend this week about identity governance and a variety of other identity topics. We were commenting that in some regards access certification and access policies have been stuck in bubble of amber: not a lot of innovation save the addition of some cluster analysis (marketed as AI.) In the course of the conversation I remember that a long time ago I had written a piece on the use of negative policy spaces for access governance. My buddy thought it would be fun to dig it up a repost it. So of I went to find this…
What’s funny (at least to me) is that what follows is a writing sample I used as part of the interview process to get my first analyst job at Burton Group. And that brought back a lot of memories…
So without further adieu, straight out of 2008, I bring you:
Controls Intelligence in the Greater Whole – Using Negative Authorizations to satisfy Audit Requirements and strengthen Positive Authorization Policies
Whether conscious of it or not, no enterprise embarks on a controls exercise, be it controls definition, management, monitoring, or rationalization, unless that exercise addresses audit requirements. Auditors and regulators have defined the backdrop against which a variety of corporate stakeholders must perform an ever-changing array of maneuvers to prove compliance. Within this context, controls intelligence platforms and processes have developed to directly satisfy audit requirements. In contrast, identity management technologies and other “compliance” tools are not truly aware of the constraints and requirements that auditors inflict upon organizations and are fundamentally not designed to meet those needs. This piece will contrast the difference between controls intelligence platforms and their associated negative authorization policies against identity management technologies and their positive authorization policies, illustrating the appropriate use of both in the eyes of the auditors as well as the enterprise.
To grow your skills, you must know your skills. Problem is, that’s harder than it sounds, if only because we rarely carve time out of our hectic lives to do so. Might as well use these next few minutes to do so, and this post will give give a technique to help you along.
We cannot think about our skills in a vacuum. It’s a well researched fact that humans are horrible at assessing their own skills. We often inflate skills we do not have. We downplay skills we do have. Simply put, we lie to ourselves about the strength of our skills.
We need inner honesty. We need outside voices. We need feedback… in order to examine these skills we have and those we don’t.
If you want feedback, it helps to have a bit of structure to shape the conversation. If you want to evaluate your own skills, it helps you to focus if you have a bit of structure as well. So what then should that structure be?
In Part 1 of this series, I discussed the types of attackers who can weaponize your identity systems, use them to cause harm. In Part 2, I introduced the design goals of the Maturity Model as well as the disciplines needed to implement the Maturity Model. In this post, I’ll discuss each of the 5 levels of the Maturity Model and controls you should put in place to achieve those levels.
Level 1 – Managed
This level is table stakes. It optimizes your organization’s existing security controls for identity systems. I believe it helps make compliance with things like GDPR easier but it is in no way a “cure all” for regulatory burdens. To achieve Level 1, you’ll need a combination of access control, data protection, and audit:
2FA for admins
No developer access to production data
No program-lead access to production
No insecure data transfers
No insecure data staging
Data encrypted in transit
Audit all admin system configuration changes
Audit user access to systems
Some of things to note… 2FA for admins is just good practice in every setting, especially if you do not have a privileged account management procedure in place. We often hear about “no developer access to production” but in an era of DevOps, you want your developers in production… but that doesn’t mean they need to access to production data, just the production systems themselves. Similarly, while developers get a lot of attention, one constituency that doesn’t are program leads. People like me should not have access to production. If you oversee an IAM program, you should not have any sort of administrative access to your production systems. Sure, you are an end-user of those systems, like everyone else, but you should not have any other privileges.
Probably not a lot of surprises in the Data Protection section, but we still see people getting tripped up by staging data insecurely.
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. Continue reading A Maturity Model for De-Weaponizing Identity Systems – Part 2