It is no secret that enterprises run on information: records tucked away in databases, procedures retrieved from content management systems and transactions posted by business applications. These information systems are as varied as the people who access them, ranging from highly-structured data stores to loose collections of images, files and assorted bits. And cloud computing is flinging corporate information in ever-more places, onto remote servers, accessed by employees and customers whenever and from wherever they like.
Information Security professionals have to deal with questions that probe into information access. On the surface, management — and their earnest auditors — have a simple question: who has access to what? After all, access controls have been around for half a century and it is common practice to apply those controls to all types of information. So what is the problem with these Who Has Access To What (WHAW) questions?
Put simply, security managers fear these questions because they are very difficult to answer. And these, inevitably, then lead to ‘who gave access to whom’ (WGAW), ‘when was access granted’ (WWAG) and ‘why wasn’t access revoked when Bob left five months ago’ (WWARWBL5MA… okay, enough with the acronyms…)
Auditors know of these challenges but they are obligated to ask the questions. It is their thing. And they don’t forget they asked — predictably they will return a year later to ask again.
Traditionally security managers would simply work with existing tools and cobble together reports based on information contained within business applications. Once notice of an audit arrived, the security manager would direct access cleanup, export data from various systems, clean up the data, import data into a reporting tool, create reports, correct reports, format reports and submit them to management. With anything less than 30 days lead time, this manual, inefficient process puts strain on the team and leads to errors in the reporting.
The main issues here are related to identity and entitlement management. Let’s look at identity management first.
- The true ‘source of truth’ for enterprise identity is the company’s human resources system. No employee gets hired, paid or retired without HR knowing about it. But what about temporary staff? Or contractors? Or those new employees from the company we just acquired that are in a separate HR system? The source of truth for these individuals — all of whom will have access to information — likely isn’t a single HR system.
- Digital identities in enterprises are represented as accounts in a directory (typically Microsoft Active Directory or another type of LDAP store). These accounts are created when employees are hired and removed when they leave. An account is used to access network resources such as shared folders, content management systems and email. Provisioning of a user’s information directly from HR into Active Directory should be a straight-forward and high-value integration — and, sure enough, many enterprises have solved this problem already. But those relatively high-churn temps and contractors are often left outside this loop, requiring manual processes to create, modify and revoke those accounts.
- Enterprise applications also require accounts, and these are often unique to each application or application suite. Increasingly these accounts can be linked to the directory account, but that capability isn’t a given. Legacy systems may have no support for this type of account linkage let alone any kind of dynamic provisioning. And even if they are linked once, there’s no guarantee that they’ll be updated as the user progresses through the organization, experiences key life events (e.g. a name change), goes on extended leave, or, ultimately, retires or quits. As a result, gaps result that can be exploited by others who have access to the enterprise network.
Access issues are similarly challenging, and even more complex:
- Before we get to describing the problem (even amongst ourselves), can we even agree on terms? Quick: what is the difference between an ‘access right’ and a ‘permission’? How about ‘entitlement’, what exactly does that mean? Do you group users into ‘roles’, or perhaps you prefer ‘groups’? Each system has its own, often arcane, language for describing what a user can access. I have no real bias towards any one term but I’ll use ‘entitlement’ for the remainder of this article. Entitlement is simply any form of application access right granted to a user.
- ‘What’ is being accessed is similarly a challenge to define. Some applications give access to all information. Others have entitlements based on application functions or menu groups. It is common to only have entitlements created for access to a group of records, or even a single record. Other systems have field level access controls. And of course we have files and folders… as you can see, ‘what’ is being accessed is difficult to describe. For now, let’s call all of these ‘information objects’.
- These objects exist and need to be protected if we are going to keep the auditor happy (or less unhappy). Going back to our access terms, we might control access to one object using group membership entitlement – a common technique with Active Directory and network folders.
- A business application might also use group-like entitlements that are related to job functions, but instead calls them ‘roles’. And the roles don’t map to the same AD groups because, well, this application’s information objects aren’t used in the same way as network information objects are used.
- Another system works from job title entitlements — only users with payroll titles can access the payroll system. Of course, job titles may have little to do with the application’s groups or roles…and job titles change…
The result is that linking a user’s digital identity to an entitlement, then making sure the entitlement is controlling the right information object is a difficult problem to solve. In practice, security managers delegate this responsibility to the owners of each business application. They are given processes to follow for requesting access. Sometimes the processes for access changes involve an email or two. Or a call to the help desk. Or a full-fledged Access Governance tool. But in many cases it starts with a hallway conversation…
See where all this is going? That’s right – access anarchy. It seems hopelessly complicated to manage WHAW and we accept the next invite to the audit review with dread.
Over the next while, I’ll outline solutions to Access Anarchy: creating an Access Governance Strategy, having a better understanding of risk, developing standards, implementing software tools, and enhancing training. The key is to embracing the importance of Access Governance to quell Access Anarchy in your organization.
Mike
