Implementing role-based access controls for third-party access

Role-Based Access Control, or RBAC as it’s commonly referred to, is one of the types of access control that has been considered a core best practice for organizations to protect their IT assets for a long time. According to NIST, where it originated in a research paper several decades ago, there are three key aspects to a proper RBAC implementation: least privilege, separation of duties, and data abstraction. These are separate and complicated processes in their own right, but most companies try a one size fits all approach. People will often implement RBAC solely by using a directory service such as Windows Active Directory (AD). And while AD has its issues such as non-Windows platform functionality and limited data abstraction features, it does do an okay job for internal employees for Identity and Access Management (IAM) piece. But, IAM is just part of the role-based access control principles, therefore many companies have felt the need to implement further RBAC controls via additional software or technology.  Special cases, such as vendor access, require even more care since the company has less information on these non-company workers and less control over their behavior. This is the reason many breaches come through third parties now. So, better security via role-based access control is a very good idea for access for these entities to implement. It may also be required by new regulations, such as NYDFS and others, that specify extra steps for third parties accessing their systems. Here are things to consider when implementing RBAC for third-party access.

The principle of least privilege

The principle of least privilege is tried and true for employee users and is known as a classic best practice. Giving only the rights and privileges that a user needs to do their job, nothing more and nothing less helps to prevent users from going where they shouldn’t be going, both intentionally and unintentionally. When it comes to vendors, using just Active Directory groups may give too much privilege by handing out default access to HR and email servers, for example, that all employees get. It also may give them access to other services tied to AD if it is used to implement single sign-on (SSO). Additionally, system administrators often don’t know exactly how much privilege to hand out to achieve least privilege for vendors working on specific applications they aren’t deeply familiar with. The issue is that vendors might only need access to a single system they are hired to support, or they might need access to potentially all desktops if they are doing desktop support. This kind of granular and variable access is hard to build and administrate in an RBAC environment using only a directory service. So with vendors, role-based access control least privilege can be a “least” version of it, if implemented solely via Active Directory. Ideally use a vendor management system, which is tailored for the use cases and security and compliance requirements around vendors. These systems will let you delegate specific use cases and permissions down to the application owners who understand their systems better and what minimum access is required.

Separation of duties

This is another area that is difficult to fully implement in AD. The idea is that rights should be segregated so that groups act as checks and balances over each other and no one user or group has all the controls over critical resources. For instance, developers should not be administrators of the underlying infrastructure, and administrators should generally not have sole administrator accounts and be monitored in use of those rights. How these are implemented vary widely depending on the company and use case. Using a Privileged Access Management (PAM) system can help you take control of your administrative accounts and keep a closer eye on their use. This concept also rolls up further to dictate the separation of IT and security management functions, but that is a topic for a different article.

Data abstraction

This is a difficult concept to achieve via any directory service. It basically instructs that data is not stored inside code or infrastructure objects and access to it is applied by role. For application programmers, this is usually achieved by having the application never store its own data, but rather calling out to a separate database where the actual data is stored. You can then implement roles within the application to limit access to specific data and protect the database behind additional firewalls or network segmenting. In terms of access to the applications, it can also be achieved by giving access only to an application port, rather than the underlying database or operating system. Some vendor management systems allow abstracting the connection to only a specific application port rather than a desktop or command line. This prevents database developers from doing anything to the underlying operating system or gaining access to a desktop where other applications could be launched.

Key takeaways

Properly and fully implementing Role-Based Access Control, as it was originally envisioned, is complicated and requires multiple layers of technology, policies, and procedures. Doing it for non-employees, like vendors, is even more difficult. However, layering your existing RBAC technology with privileged access management, for both internal and external access, will keep you both secure and compliant. This blog originally ran on Cybersecurity Insiders.