I can’t recall having seen an overview of a systematized privilege management program. There are lots of great articles on specific authorization management techniques and guidance for identity/access management configuration on-premise and in the cloud. There is also a lot of technical guidance for the implementation of specific policy enforcement mechanisms, but not much on overall enterprise-wide access governance. So, here’s a short post that might be useful.
First of all we need to consider the goals. In any reasonably sized, long-lived and heterogeneous environment there will be millions, billions, perhaps trillions or more, of objects that have access controlled from identified and authenticated subjects. The objects could be applications, application privileges, data, infrastructure elements, analytics or other data warehouse objects, external resource accesses, physical access privileges, groups of privileges designated as roles and so on. It is the simple (to state) but immensely challenging (to achieve) goals of privilege management to make sure that:
All subjects are known, identified and authenticated.
All objects are known.
Policies are defined for what subjects (or groups of subjects) with what attributes (or conditions) can access what objects with what privileges (or roles).
That reality corresponds to policy i.e. known subjects and objects correspond to discovered subjects and objects and the reality of the distributed policy bindings correspond in real-time to the policy intent.
There is a process to manage the meta-information of groups, roles, and rules such that the policy intent corresponds to enterprise risk mitigation goals.
There is a management process to close any deltas detected and to apply adjustments to resolve those, both tactically (quick fix) and strategically (root cause of root cause).
That’s it. Somewhat simple to assert but as anyone who has even tried a slice of this at enterprise scale knows, it is tremendously hard to do. In an idealized state, all privileges would be grouped into roles, users (and other subjects) into groups, sprinkle in some attribute based access control or RBAC condition layers and it would all be integrated. In reality things are more complex and harder to govern. But there’s no reason why you shouldn’t keep moving on the path of achieving the goals.
Looking at the elements:
Automated or human approved workflows to approve access being granted should conform to the enterprise policy intent. In other words, don’t let provisioning systems provision privileges which would cause a rule to be violated. In step 6, a by-product of detecting rule exceptions is to feed that back into why the provisioning process did not prevent such privilege being granted in the first place. In any medium to large organization this is going to be in a constant state of flux as these processes may well be a group of systems that are differently integrated in the provisioning step vs. the rule surveillance step. Clearly, that shouldn’t be the case, but in reality it often is. The feedback loop is important to provide the impetus to correct this.
Automate the provisioning of access on the target systems to remove the potential for human error. This is, of course, quite an obvious thing to do but in many organizations with 1000’s of business applications built over decades there won’t always be a shared policy management system or set of enforcement points that are API accessible. Even if some automation can be established there may still be a need for human administrators to finely tune the specific privileges or attributes / conditions directly in the application. This is where you need to drive a program to implement more cohesive automation. In some cases, though, you might simply need to do as best as you can and focus on replacing the application and having new applications designed with a more integrated privilege management approach.
Continuously extract the configured access control state from the distributed set of applications and other object collections. Continuously compare that with the expected configuration derived from your rules, roles and attribute set. From this, deal with any detected exceptions. But, remember, such exceptions may not always be a violation - they could be locally approved overrides because of incorrectly modeled access policies. In other words, detected violations are a feedback loop for which the feedback is either an actual violation or a misconfigured policy/rule. In either case, corrective action is needed. A build-up of temporary exception approvals should be avoided, a good metric is the velocity of the find exception / fix exception flow rather than simply exception counts. In the beginning you will get lots of exceptions and what matters, of course, is how quickly they are resolved not the amount of them (remember the uncanny valley).
Continuously extract the actual use of specific privileges and, over suitable time periods, flag for removal any which are unused. This is harder than it sounds. It is complicated as you have to consider over what time frame you are looking and with what scope - there are plenty of critical enterprise privileges that are used maybe at most annually or in some cases only in break-glass situations. When applying this feedback you will also need to consider if the subsequent new precision in policies and rules causes too much brittleness in policy to be worth the risk reduction (here is also where you are balancing security risk vs. resilience risk).
Align with your asset discovery program to continuously monitor whether or not you have all the actual assets in your organization in scope. This is likely broader than your regular asset discovery program used to verify your inventories as it will need to further correlate with application, data and other catalogs.
Continuously run your enterprise rules against the observed state of privilege assigned to look for any “toxic combinations” of access. Adopt various levels of analytics, basic or more advanced ML approaches, to recommend access adjustments.
Establish and manage the enterprise policies of rules and roles to be used by all the other elements. Here there will be significant, and often underestimated, effort to manage this meta-data of your privilege program. It is here you should also consolidate and drive automated actions from specific enterprise event triggers, like leavers, movers, joiners and other types of events.
Bottom line: it’s relatively straightforward, but never easy, to establish a privilege management program at small scale, for new environments, or those that have homogenous identity and access management technology. But if these conditions aren’t true (and they usually aren’t for 90%+ of most organizations) then you’ll need some overall program structure executed over many years to bring things under sustained control. This is often one of the least talked about but most challenging aspects of an enterprise information security program.
Comments