Many companies are challenged with provisioning access to their information systems and data. Usually, the “hiring” manager is tasked with determining what access a new employee or consultant should have. Logical access is really not their focus; their focus is on operating and growing the business. Since the manager is not sure exactly what is needed, they request to model access after another employee. Does this sound familiar?
A key security principle is “Least Privilege,” which is instrumental in reducing risks associated with unauthorized access and use and minimizing accidental sharing or malicious intent. Least Privilege is the practice of restricting access rights for user accounts to only those resources and data that is absolutely required to perform legitimate activities.
The risks associated with a modeling after approach is twofold:
· The manager does not know exactly what access the model after employee has, and therefore can increase the permissions and data access that the new employee will get
· Continued use of this approach can easily exaggerate permissions and data access over time
The risks are not just contained to the new hire process. Employee transfers are just as risky. Consider the following real-life scenario to illustrate how permissions and data access can easily get out of control.
A finance employee, Employee 1, pursues a new position within human resources. Employee 1 is quickly advanced into the new position. Since the human resources’ department needs Employee 1 to be immediately productive, they promptly provision access to the human resource systems and data.
During the transfer, the finance manager does not adjust Employee 1’s access. Either they forget or figure the human resources will adjust the access once Employee 1 moves over to the new department. Human resources do not request any changes to financial access as they don’t know what access that Employee 1 has.
A few weeks later, the finance manager finds a replacement, Employee 2. The finance manager not knowing exactly what permissions and data access is needed, requests Employee 2 have the same access, modeled after, as Employee 1.
No big deal, right? But when you analyze what happened, Employee 2 received exactly the same access as Employee 1’s, based on the date of the finance manager’s request. This means Employee 2 got access to the sensitive human resource data in addition to the financial data.
Are you comfortable with the scenario and the resulting escalated permissions? There is a solution, Role-Based Access Control (RBAC).
Quite simply, RBAC is assigning information system resources and data access based on the roles of users within an organization. But the actual process of implementing RBAC is a little more challenging. However, completing this project will reduce your risk associated with unauthorized access and use.
To achieve the desired outcome, you will need to map access to roles, or titles. For example, if our two sample employees had job titles of Assistant Treasurer and Compensation Analyst, we would work with the business subject matter experts (SME) to decompose the permissions and data access each position requires to perform their job. Then these get mapped to their title. So, when a new hire is brought into the company, instead of modeling access after an individual employee, permissions and data access is granted based on the defined template for that a role for that individual.
The decomposition needs to take into account all access. For example:
- Active Directory
- Remote Access
- Distribution Lists
- Unstructured Data
And what happens with transfers within the organization? The transfer request will include the from position to the new position which will all system administrators to remove the Assistant Treasury role and provision the Compensation Analyst role.
The role templates are only a base as there will be exceptions for specific individuals. If done right, these will be minimal.
RBAC is not once and done. RBAC is a process that will require maintenance. Permissions and data access with roles will change and new roles will be created. As part of your ongoing certification process, certification of roles is important. The resulting role templates can speed entitlement reviews by identifying access outliers and the managers will only need to certify these permissions.
From a business perspective, RBAC allows managers to focus on the business. Once RBAC is implemented it will drive better productivity. Access can be provisioned correctly the first time and it builds the foundation for implementing automated solutions.