Authorization is Broken

In the world of information security, two concepts define the access to information. The first is authentication; answering the question, “Does the information system know who you are?” Across the world there have been a lot of “fixes” to the authentication conundrum, from multi-factor authentication, to one-time passwords, to public key infrastructure. These efforts are bearing fruit, as systems are becoming more difficult to breach. The second concept is authorization which asks the question, “Now that I know who you are, what are you allowed to access?”

My belief is that Authorization, as currently implemented, is broken. This makes organizations vulnerable to insider threats, phishing attacks, and other efforts used to impersonate or trick users into providing access. In this post I will describe the problem of authorization. My next post will discuss how to fix it.

Why do I think that authorization is broken?

Authorization relies on the principle of least privilege. The principle of least privilege means giving a user account or process only those privileges which are essential to perform its intended function. When I was in the U. S. Navy a few decades ago, we used a similar matrix of authentication and authorization. Authentication was done with identification documents that were result of a vetting process. Authorization was granted based on “Need to Know,” which meant, although you may have been vetted to the Top-Secret level, you still only had access to information related to your specific job function.

To give a real-world example, when I was enrolled in the Navy’s Nuclear Power Program. I was vetted and given a Top-Secret clearance. While in training I lived on a military base complete with barbed wire fences and armed guards at the gates. I went to a schoolhouse where I had to show my identification to an armed guard before I entered. I was not allowed to take any paper out of the building, and my textbooks were locked in the building the entire time I went to school. One evening during training two of my buddies and I, during a break in our homework, postulated that we could design an atomic bomb. We did just that on the chalkboard in the training room. The last sentence is the point of the story. The information I had access to was incredibly dangerous (along with a lot of other information), and needed extreme measures for protection. Our “Need to Know” status gave us access to information that could be used for entirely different purposes than our training.

In a similar manner, authorization is broken. Because least privilege no longer works. I came to that realization after reviewing major lapses in security on platforms such as WikiLeaks, OPM, and other breaches. Many occurred because of a violation of the least privilege principle. The principle of least privilege is sound. The way it is implemented uses another concept called Role-Based Access Control (RBAC). Simply stated, RBAC is access control based on roles. Each user (or process) is assigned roles based on their function. Those roles, in turn, are used by applications to allow access to information and capabilities. Every role would logically have multiple users (and processes). But what also happens is that every user and most processes have multiple roles. The latter occurs because — since access control is implemented within applications — each user needs different roles for different applications. This many-to-many relationship and dependency on access control within applications leads to three inherent flaws.

1. Role Explosion. In an attempt to establish fine-grain access control, every application requires many roles. Since each user accesses many applications, the number of roles rises exponentially. Role explosion results in an environment where it becomes very difficult to manage roles — especially in assigning and revoking roles.
2. Role Accumulation. A side-effect of role explosion is role accumulation. In role accumulation a user accumulates roles over time. This occurs as users are promoted, transferred, or assigned to functions on a temporary basis. Often a user is granted roles, but those roles are never revoked. As a result, users have access to a broad set of data and capabilities that are no longer essential for their current function.
3. Application Architecture Brittleness. Brittleness occurs because each application has to manage access control. As applications are enhanced, patched or modified, the changes create access control issues that are unintended. When access to essential information is denied, the user raises a trouble ticket to get the issue resolved. However, if access is granted to non-essential information, the user may not know or communicate that access as they can still do their job.

The combination of these three flaws makes access control (and thus authorization), difficult to manage effectively in an age where every endpoint is a potential threat vector.

Hopefully, by this point you have a better understanding of the problem. The solution involves moving from RBAC to Attribute-Based Access Control, which I've covered in my next post.

Learn more about NTT DATA security solutions for federal government.