Introduction
As people join, move and leave our organizations, their entitlements do not always follow or leave with them like a shadow does. The more likely scenario is that in which some of these entitlements are left unaccounted for, leaving an imprint. The depth of that imprint is a function of the amount of change our organization incurs over time and our Security programs understanding of, and accounting for, that change. Left unchecked, this imprint gets deeper, becoming yet another attack vector on our organizational assets. It should be the goal of any Security program to understand this imprint and minimize its impact. In this article, we will introduce you to the Imprint, some common causes, and some of the ways organizations can begin to understand and tame it.
The Access Imprint
To begin, every Security program should have an Access Ideal. That is, “here are the accesses you need to perform your duties, no more, no less”. That Ideal can be defined in a number of ways, both technically (Roles, Rules) and procedurally (Policy, Guidelines) and will necessarily change over time.1 Our Identity and Access Governance (IAG) program has to understand organizational change and be able to articulate that back into the overall Security program. It is that understanding that will allow us to define an Ideal and adhere to it while, at the same time, allowing our organization to grow and move forward safely.
Throughout this article I will refer to the quantification of stale entitlements, rogue accesses (outside of policy and procedural guidelines) and the scale of the threat it presents as an “Imprint”. It makes it easier to visualize the threat level without diving deeply into the technology behind actually quantifying and scoring this threat (there are a number of tools on the market that help with this). Fig. 1.0 shows an Access Ideal, the guideline about which entitlements should be provisioned/de-provisioned. Below that line, you have too little access to perform your job and above it, you have too much. In a perfect scenario, entitlements will lay directly over the top of (or very close to) that Ideal over time. In reality, however, the number of unchecked/unaccounted for entitlements begins to grow, creating Access Creep. It is the gap between these that we call the Imprint. The deeper this Imprint, the more risk our organization is exposed to.
Figure 1.0
Identity Related Threats
Now that we have an idea of what the Imprint is, lets look at some of the causes. This is certainly not an all-inclusive list, but some common, and often overlooked examples.
Shared Access: Perhaps you have one account with a vendor/service provider and more than one person in a given department utilizing that account to perform work. While this might seem like a simple and necessary solution, it should be avoided whenever possible. This not only causes a loss of fidelity when we want to start to correlate entitlements back to individual identities, but it effectively eliminates accountability, a key tenet in a robust Security program.
System Account Access: Sometimes these are necessary. However, these accesses carry with them the opportunity for the person with such an access to grant access to others (to hit that looming deadline or delegate the weekend work while they are out of town). These accesses are very likely outside of any automated provisioning system or request/approval flow, thus falling off of the radar when it comes time to revoke.
Un-checked / Stale Entitlements: This normally occurs when a user is provisioned an entitlement on some resource, perfectly legitimately, for the purposes of performing their daily duties or for short term/temporary assignments. Once there is no longer a business need for that entitlement (the project completes, the person moves out of the area and on to another, or leaves the organization altogether) the revocation of some or all entitlements may not occur.
Active Accounts for users no longer with the organization: Unfortunately, this is more common that one might hope. While there are several factors that may prevent this threat from actually manifesting itself into a breach (perhaps the account is active, but they no longer have physical access company computers/systems), those factors must not be relied upon solely. Thus, these types of accounts are at the top of any Regulatory Compliance priority list.
These are just a few scenarios, but it isn’t difficult to see how just the above examples could deepen the Access Imprint very quickly in an organization even as small as a few hundred. Larger organizations are at greater risk.
Reducing The Imprint
There are a number of ways to address the Imprint and, as you will find, they all need to work in concert to form a solid and sustainable IAG program. One of the most important, we feel, is to ensure that the ownership of entitlements is in the right place.
Historically, the solution to a technical problem has been to address it with more technology. On the surface, Access Imprinting certainly seems like a technology problem. In actuality, however, it is a business problem, enabled by technology. Many organizations have left their Security program, which is usually tied very closely to (and funded by) their IT department, in charge of dealing with provisioning/de-provisioning entitlements, and solving any problems that arise as a result. But is this the best place for this ownership? We believe that it is equally as important for your business partners to play a role in your Security program. They are the ones closest to the problem domain (the people doing the work, and what entitlements they need to do it), and will be able to provide the most valuable feedback. Our IAG Program will then be responsible for leveraging that feedback into reusable and consistent requirements for any technology solutions deployed to address the Imprint.
The foundation of a good IAG program, long before choosing what (technology) solution to use to address any issues, has to be the establishment of a good working relationship with your business partners. This might seem like a no-brainer, but it is easily (and often) overlooked. Having a Business Analyst allocated to your Security projects is not always enough, though it is certainly a great start. Business areas must understand that they are an integral part of your Security program and the goal of gaining a better understand of your organization. That relationship cannot come and go. It has to be understood by IT and the Business that this is a lifelong partnership. Transparency, that deep understanding of your organization and identity data, will come much easier with constant input and keeping the Imprint at bay is going to rely on that input.
By assigning ownership of the part of the Access Ideal (a Role, a set of Rules, Policy) that aligns to the respective Business areas to someone within that business area, we can abstract the nuances of understanding who needs what accesses (the Business problem) from the area of the organization responsible for building, deploying and maintaining any technology solutions. Remember, these Ideals have to evolve over time to remain relevant and that evolution is best understood at the Business level. By understanding and accounting for this change, we gain transparency and a better understanding of our organization. This understanding is what our IAG program is going to leverage to achieve the overall goals of Risk Mitigation, Operational Efficiency and Compliance.
1. The graph in Fig. 1.0 shows the Access Ideal as a constant, but that is only in relation to the magnitude of the change between Access Creep and the Ideal.
