When our perfect abstract model of how we'd like the world to be, meets messy reality - an archaeological dig of past attempts, ad-hoc pragmatism and non-compliance!
In an ideal world, identity and access management (IAM) would work just like in the movies (well, the pre-recorded demos – not the live ones!). Nice clean identity data, cartoonishly simple org-charts and role-based access models enabling automated and low-touch management. Users experience a perfect 'first day' with everything ready for them, and movers and leavers events automatically result in the correct access and no audit findings.
When you set out to start or reboot an IAM project, this has to be the goal - a clean access model that ‘just works’, reduces maintenance and manual approvals, gets you close enough to ‘least privilege’ to reduce risk without impacting user experience.
Once your carefully designed access model meets messy reality, it can seem like an impossible task to map and bring all the existing access into your model. Even if all new access is provisioned within the new access model (stemming the bleeding), carrying an enormous legacy of non-compliant access can undermine the effort as all the benefits of automation, lower maintenance and governance costs take too long to be realised.
Most organisations have been through multiple projects trying to clean up access, design roles and reach the nirvana of role-based access control (RBAC) or one of its cousins (e.g. Attribute-Based Access Controls ABAC). But it’s hard to get the data to define the roles, get consensus between engineering and the business on what the roles should be, and then maintain roles over time to ensure they still fit the business as it changes. There are many reasons why RBAC projects fail, but the outcome is usually the same – instead of one new access model to rule them all, yet another access model to add to the existing confusion.
Credit: xkcd.com & license info
It’s important that the value of a good access model is well understood and supported by your business and leadership. You also need a shared level of pragmatism that there will be a (potentially long) period where reality doesn’t match the model. Remediating that delta – between the reality and the model – takes time and needs robust processes and resourcing to succeed. Being able to track and demonstrate progress and value hopefully avoids yet another abandoned standard!
What about AI?
Matching patterns in large data sets sounds like the kind of problem that the explosion in AI/ML tools and techniques should be able to help us with – finding groups with clusters of similar access; finding outliers that have unusual access; comparing access used and access granted to remove excess access. IAM vendors are adding these features to their tools, which makes sense as they already hold the central database of all the identities and access we want to make sense of.
But there are two challenges or issues to using automated tools to clean up your access and roles:
1. the old rule of ‘GIGO’ or garbage-in-garbage-out. If you have a lot of excess access – a history of bulk cloning access for new starters, or poor remediation of access for leavers and movers – the algorithms will find patterns of access and identities that are present in the data but do not represent genuine business requirements.
2. for many systems, it’s hard to know what access is really being used. Even with good recertification processes, your line manager might know that you still need a role, but struggle to know that you only use 5% of the access that role contains. Without usage data from the end systems being visible in the central IAM database, it is hard to systematically prune out unused access which is approved, but not really needed - unnecessarily exposing your organisation to additional risk.
In cyber security we say “you can't protect what you don’t know you’ve got”. It’s equally hard to right-size access if you don’t know whether it’s being used or not.
This usage visibility issue is becoming easier to solve in the cloud era. A consistent cloud management layer for identity, resource and access management, and event logging, means that we do have the data, showing not only who can do what, but who has done what. A new acronym and set of tools offering Cloud Infrastructure Entitlement Management (CIEM) continually assess and suggest adjustments to roles to trim out access that is not being used. CIEM functionality is increasingly being built into IAM platforms offering additional value and coverage of your cloud infrastructure.
What about the legacy systems, the SaaS tools and all the other systems which don’t use the cloud management layer for IAM access policies and activity logging? Well, we still have to cope with the patchwork of multiple data sources and the varying quality and granularity of logging data. A lot more work is needed to prioritise which systems get ‘fully’ connected to your IAM systems (e.g. with a native connector), and which remain more indirectly connected. The right strategy for your organisation depends a lot on your threat landscape, legacy environment and cloud transformation roadmap.
Savanti are identity strategy and implementation experts and help clients at all stages of their security maturity to tackle the complex challenges that come with identity-centric security.
If you want to find out more, visit the chat function on our website, email us at info@savanti.co.uk or fill in the below details:
