Thanks to the ISACA Now blog for posting my article, Eliminating Passwords in the Enterprise!
Periodically I have a disconnect with a client or a consulting partner. You know, one of those moments when you realize you are on different pages than you thought you were when the conversation started.
I’ve realized that there are typically two types of people working in Identity and Access Management. The first group comes from a security background, while the second has access administration or maybe more general IT on their resume. I’m a graduate from the second school.
This really dawned on me about five years ago. I was talking to a consultant, who was relatively new to IT, about identity management and how my job was to give the right people access to the right resource, yadda, yadda, my normal spiel. He was listening but had a furrowed brow and I realized he was struggling with the ‘allow access’ part of the conversation.
I quickly learned that he was an ex-military police officer with experience in electronic security systems. He was much, much more interested in blocking access and ensuring maximum security. The idea that we could (and should) make access easier was hard for him to understand.
I have learned that there are some in this business that come from a position of wanting to over-secure everything. If that’s who you are working with, it is best to consider that viewpoint because they won’t be able to move forward with an IAM solution until their primary security needs are met.
But there are also those of us that want a really good user experience even if it means managing some additional security risk. We’ll always look for a design that allows access — while still being compliant with security and privacy — but is more aligned with client business needs.
Where you from?
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.
An important issue is being raised by our federal Privacy Commissioner around changes to legislation to combat online fraud and other crimes. These changes look to be more than cursory — they would potentially create a legal environment where law enforcement can implement excessive surveillance on Canadians.
To quote Jennifer Stoddart’s letter to Vic Toews, the Minister of Public Safety:
By expanding the legal tools of the state to conduct surveillance and access private information, and by reducing the depth of judicial scrutiny, the previous bills would have allowed government to subject more individuals to surveillance and scrutiny. In brief, these bills went far beyond simply maintaining investigative capacity or modernizing search powers. Rather, they added significant new capabilities for investigators to track, and search and seize digital information about individuals.
This is an important issue, one worth paying attention to over the coming months.
Implementing Identity & Access Management solutions can be complicated. There are a wide range of features, technical inter-dependencies and business issues to be managed. Cost, schedule and scope issues can all result in project problems.
My first experience actually managing a large IAM project came in 2003. At that time the solutions were clumsy and the technical resources simply weren’t that strong. Today the product suites for IAM are much more capable, but there remain a number of risks to manage:
- Resourcing — Good people can be hard to find and you’ll want some good quality business analysts and at least one ‘go-to’ technical architect. Avoid resourcing risk by looking for these people early and once you get them in place, be sure to keep your core team happy. As you move along, try to cross-train the team members and document the solution — doing this will significantly reduce the risk to the project should a key person leave unexpectedly.
- Management Support — Don’t just give your boss a status report every week and think you’ve earned her support. Keep the communications flowing and be sure to celebrate successes and continually emphasize key benefits. Hit your dates, deliver as expected and people will notice.
- Technical — IAM’s complexity comes from integration, and while standards like SAML are well established, there is going to be customization required to get the solution working within an enterprise environment. With customization comes complexity and inevitable technical hurdles. Reduce project risk by tackling these head-on: identify the problem early and if the technical team is stumped, bring in the vendor experts.
- Scope Creep — Where possible, I try to keep the scope small to reduce complexity and to ensure the team delivers something every six months. If your scope does creep, it is on a smaller base of work and is much more obvious — and manageable. For bigger scope issues, communicate early and stop reporting ‘green’ status. If you don’t have clear scope you need to stop and resolve — don’t just assume you’ll fit it into the workplan. Another sure fire way to manage risk related to scope is simply to drop less critical functions. For example, if the scope creep is related to the administration component, perhaps drop the lower priority reports — they can always be built later, either as part of some follow-on project or by the operational support team.