Much of the attention in the industry is focussed on privileged account management and identity governance rather than the bigger architecture of privilege management. We have the opportunity to revolutionize this fragmented, inconsistent approach to the management of risk and privilege by taking a step back and looking at the bigger picture of risk and privilege management. Privilege management has the following components:
– Entitlement management – policy based request / approvals
~ Also applies to service management
– Access management – ABAC (risk engine) and PAM
– Security management – privilege / risk context for analytics
– Business process – policy based approvals
We have a unique ability to deliver a consistent approach to all of these different aspects through the use of an independent risk engine and independent workflow engine – underpinned by a common identity vault. This document will describe how.
Privilege, reputation and risk
A consistent IT risk approach is based on the foundational model of the “identity is the new perimeter”. This model requires a shift from “outside = bad and inside = good” to one of reputation and privilege. Privilege deals with the authority or power that has been delegated and reputation is socialized (relationship) risk. These are quantified via a very simple identity (people, place or thing) interaction model:
Risk = Identity1 <-> Interaction <-> Identity2
Privilege Management
Privilege management is typically covered under entitlement management – each entitlement has an impact (privilege/power) along with a likelihood of compromise or abuse. This information can be used in a number of ways to reduce risk:
– Total entitlement risk of an identity (service/person/thing) is used to specify controls.
– Relative entitlement risk between a user and a given application / service is used to specify controls. Special cases are:
~ Super user privileges – “judge, jury and executioner”.
~ Separation of Duties – Toxic combinations that have significant risk multipliers.
The typical controls for privilege management are:
– Authentication factors
– Audit – traceability through to “four eyes”
– Authorization factors – approvals (types, number), veto, etc..
Note: Personas need to be included to reflect the “masks” we operate with.
Reputation Management
Reputation uses the same simple identity interaction model except that the risk of both parties changes over time based on interactions: activity and behavioural analytics. Activity analytics looks at the type and frequency of interactions whereas behavioural analytics looks at the sequence of interactions. The simplest form of reputation management implemented today is “user history”, but a full implementation includes:
– Activity analysis:
~ Common interactions and interaction attributes are considered lower risk.
~ Typically seen as “social” network analysis when identities are restricted to people.
~ Uncommon interactions interaction attributes are considered higher risk.
~ Unused entitlements (interaction void) identify potential stale entitlements.
– Behavioural analysis:
~ Common sequences (paths) of interactions are lower risk.
~ Uncommon sequences (paths) of interactions are higher risk.
~ Incomplete (funnel) sequences of interactions are higher risk.
~ Identities with uncommon attributes (cohort) in a common sequence are a higher risk.
Activity analytics can be delivered relatively simply once you have a unified identity vault (people, place or thing) and event repository (Security information and event management – SIEM). Behavioural analytics requires a significant step up into big data and machine learning – we humans are too (Dunbar) limited to meet the scale of today’s digital landscapes.
A common model
Once we have a common model of identifying, adapting and responding to risk we can apply this consistently to a digital landscape – be that internal, hybrid or in the cloud. This Privilege Management Bus is founded on the following building blocks of:
Identity vault – store identities (people, places or things) and their attributes.
SIEM – record and store interactions and their attributes.
Analytics Engine – perform behavioural analytics and machine learning.
Risk Engine – determine the risk of an interaction based on attributes / analytics
Workflow engine – based on risk assessment, trigger (sequences) of events or controls, e.g. approvals.
This privilege management bus adds significant value to a number of key processes as follows.
SIEM
In addition to acting as the central repository for all interactions, the SIEM gains the ability to more effectively reduce risk by extending the identity context to cover places and things in addition to people, and to add the interaction context. We have already seen the power that the “people” context can add to a SIEM (Sentinel) and the ability to add the context of an application or service (composed of many infrastructure identities) will add further value. Shifting the context from events to an interaction frame allows relationships to be analysed like never before.
Identity Governance and Management
One of the key functions of identity management is the fulfilment of entitlements (privilege). Many organisations have approval and review functionality split across service management tools, identity management tools and identity governance tools. The separate tools are necessary because they each have different value propositions, but it can mean an inconsistent approach to risk management across them. The solution to this is for each to leverage the common risk and workflow engines to apply a consistent approach.
Access Management
Access management has traditionally had Attribute Based Access Control that typically focussed on the connection attributes. Today there is a requirement to extend that to leverage the attributes of the user and service to make a more complete risk assessment. This can be done by making the existing risk engine aware of a common identity vault that stores risk and privilege information.
Business Process
The exciting part about the privilege management bus is that it allows for business processes to leverage this at a transactional level – not just access (authentication & authorization).
Not sure how big a “thing” this would be, but seems logical to me.
Execution
The steps for phase one (dovetail with containerization strategy) would be:
– Split out the risk engine from NAM and available via REST/SOAP API’s
– Split out the identity vault and extend it to have risk attributes for identities.
~ Should be done via IG integration with IDM
~ Extend the vault to naturally understand places/things (apps, services, etc)
~ Leverage ITOM Asset management DB’s?
~ Extend entitlements, resources and roles to have risk attributes as well.
– Split out the IDM workflow / forms engine (callable via REST/SOAP API’s)
~ Must have a DAL to the IDV (identity and interaction are the differentiators here)
~ Kill OSP for the love of god. Use NAM
– Update Sentinel/Arc Sight to understand a full identity (not just people) – should use IDV
~ Add interaction model for analytics to leverage.
~ Add ability to dynamically update IDV with risk information.
Phase 2 would be:
– Integrating analytics
– Personas in NAM, NSL (PAM already does this)
– PAM to leverage risk engine and split out audit / reporting engine.
– Extended audit trails in NAM/NSL (align with PAM)
– Integrate identity governance (should already be doing much of this anyway)
Commercials
As a number of components in the privilege (management) bus are used by other solutions (NAM/NIM/etc.), I’d recommend an event (EPS) type model be used. This allows for a simple cost model that can extend seamlessly between on-premise/hybrid/cloud solutions.
Conclusion
The concept of a privilege (management) bus provides us an opportunity to differentiate ourselves in the market and allow us to add significant value to organizations that are risk sensitive (financials & defense). This also requires a commercial model that will scale and integrate appropriately with our existing portfolio.
Want to learn more?
What Is Privileged Access Management?
What is Data Access Governance?
If there’s anything you’d like to discuss please don’t hesitate to ‘contact us‘ and feel free to browse through a heap of Access Manager resources here. Or find me directly on LinkedIN if you like?
