Skip to main content

Who Has Access -v- Who Has Accessed

The certification and attestation part of identity management is clearly focused on the 'who has access to what?' question.   But access review compliance is really identifying failings further up stream in the identity management architecture.  Reviewing previously created users, or previously created authorization policies and finding excessive permissions or misaligned policies, shows failings with the access decommissioning process or business to authorization mapping process.

The Basic Pillars of Identity & Access Management

  • Compliance By Design
The creation and removal of account data from target systems falls under a provisioning component.  This layer is generally focused on connectivity infrastructure to directories and databases, either using agents or native protocol connectors.  The tasks, for want of a better word, are driven either by static rules or business logic, generally encompassing approval workflows.  The actual details and structure of what needs to be created or removed  is often generated elsewhere - perhaps via roles, or end user requests, or authoritative data feeds.  The provisioning layer helps fulfill what system level accounts and permissions need creating.  This could be described as compliance by design and would be seen as a panacea deployment, with quite a pro-active approach to security, based on approval before creation.
  • Compliance By Control
The second area could be the authorization component.  Once an account exists within a target system, there is a consumption phase, where an application or system uses that account and associated permissions to manage authorization.  The 'what that user can do' part.  This may occur internally, or more commonly, leverage an external authorization engine, with a policy decision point and policy enforcement point style architecture.  Here there is a reliance on the definition of authorization policies that can control what the user can do.  These policies may include some context data such as what the use is trying to access, the time of day, IP address and perhaps some business data around who the user is - department, location and so on.  These authorization 'policies' could be as simply as the read, write, execute permission bits set within a Unix system (the policy here is really quite implicit and static), or something more complex that has been crafted manually or automatically and specific to a particular system, area and organisation.  I'd describe this phase as compliance by control, where the approval emphasis is on the authorization policy.
  • Compliance By Review
At both the account level and authorization level, there is generally some sort of periodic review.  This review could be for internal or external compliance, or to simply help align business requirements with the underlying access control fulfillment layer.  This historically would be the 'who has access to what?' part.  This would be quite an important - not to mention costly from a time and money perspective - component for disconnected identity management infrastructures.  This normally requires a centralization of identity data, that has been created and hopefully approved at some point in the past.  The review is to help identify access misalignment, data irregularities or controls that no longer fulfill the business requirements.  This review process is often marred by data analysis problems, complexity, a lack of understanding with regards to who should perform reviews, or perhaps a lack of clarity surrounding what should be certified or what should be revoked.

SIEM, Activities and Who Has Accessed What?

One of the recent expansions of the access review process has been to marry together security information and event monitoring (SIEM) data with the identity and access management extracts.  Being able to see what an individual has actually done with their access, can help to determine whether they actually still need certain permissions.  For example, if a line manager is presented with a team member's directory access which contains 20 groups, it could be very difficult to decide which of those 20 groups are actually required for that individual to fulfill their job.  If, on the other hand, you can quickly see that out of the 20 groups, twelve were not used within the last 12 months, that is a good indicator that they are no longer required on a day to day basis and should be removed.

There is clearly a big difference between what the user can access and what they actually have accessed.  Getting this view, requires quite low level activity logging within a system, as well as the ability to collect, correlate, store and ultimately analyse that data.  SIEM systems do this well, with many now linking to profiling and identity warehouse technologies to help create this meta-warehouse.  This is another movement to the generally accepted view of 'big data'.  Whilst this central warehouse is now very possible, the end result, is still only really trying to speed up the process of finding failures further up the identity food chain.

Movement to Identity 'Intelligence'

I've talked about the concept of 'identity intelligence' a few times in the past.  There is a lot of talk about moving from big data to big intelligence and security analytics is jumping on this band wagon too.  But in reality, intelligence in this sense is really just helping to identify the failings faster.  This isn't a bad thing, but ultimately it's not particularly sustainable or actual going to push the architecture forward to help 'cure' the identified failures.  It's still quite reactive.  A more proactive approach is to apply 'intelligence' at every component of the identity food chain to help make identity management more agile, responsive and aligned to business requirements.  I'm not advocating what those steps should be, but it will encompass an approach and mindset more than just a set of tools and rest heavily on a graph based view of identity.

By analyzing the 'who has accessed' part of the identity food chain, we can gain yet more insight in to who and what should be created and approved, within the directories and databases that under pin internal and web based user stores.  Ultimately this may make the access review component redundant once and for all.

By Simon Moffatt


Popular posts from this blog

2020: Machine Learning, Post Quantum Crypto & Zero Trust

Welcome to a digital identity project in 2020! You'll be expected to have a plan for post-quantum cryptography.  Your network will be littered with "zero trust" buzz words, that will make you suspect everyone, everything and every transaction.  Add to that, “machines” will be learning everything, from how you like your coffee, through to every network, authentication and authorisation decision. OK, are you ready?

Machine Learning I'm not going to do an entire blog on machine learning (ML) and artificial intelligence (AI).  Firstly I'm not qualified enough on the topic and secondly I want to focus on the security implications.  Needless to say, within 3 years, most organisations will have relatively experienced teams who are handling big data capture from an and identity, access management and network perspective.

That data will be being fed into ML platforms, either on-premise, or via cloud services.  Leveraging either structured or unstructured learning, data fr…

Customer Data: Convenience versus Security

Organisations in both the public and private sector are initiating programmes of work to convert previously physical or offline services, into more digital, on line and automated offerings.  This could include things like automated car tax purchase, through to insurance policy management and electricity meter reading submission and reporting.

Digitization versus Security

This move towards a more on line user experience, brings together several differing forces.  Firstly the driver for end user convenience and service improvement, against the requirements of data security and privacy.  Which should win?  There clearly needs to be a balance of security against service improvement.  Excessive and prohibitive security controls would result in a complex and often poor user experience, ultimately resulting in fewer users.  On the other hand, poorly defined security architectures, lead to data loss, with the impact for personal exposure and brand damage.

Top 5 Security Predictions for 2016

It's that time of year again, when the retrospective and predictive blogs come out of the closet, just before the Christmas festivities begin.  This time last year, the 2015 predictions were an interesting selection of both consumer and enterprise challenges, with a focus on:

Customer Identity ManagementThe start of IoT security awarenessReduced Passwords on MobileConsumer PrivacyCloud Single Sign On
In retrospect, a pretty accurate and ongoing list.  Consumer related identity (cIAM) is hot on most organisation's lips, and whilst the password hasn't died (and probably never will) there are more people using things like swipe login and finger print authentication than ever before.

But what will 2016 bring?

Mobile Payments to be Default for Consumers

2015 has seen the rise in things like Apple Pay and Samsung Pay hitting the consumer high street with venom.  Many retail outlets now provide the ability to "tap and pay" using a mobile device, with many banks also offer…