Whenever the topic of compliance comes up in conversation, most people automatically think of regulations like PCI-DSS, HIPAA, SOC 2, and even GDPR. While compliance with these regulations is extremely important for your organization’s security profile (and reputation), your ability to comply with them hinges on your ability to control which users have access to specific systems and to monitor when they access them. 

‍

‍

From Access Control Lists to Role-Based Access Control

As soon as computers became multiuser, there was an obvious need to be able to control and track who could log in to what. Access control lists (ACLs) were used to do just that—if you weren’t on the list, then you couldn’t get in. But while ACLs are very good at handling authentication, they don’t limit what users can do once they are authenticated.  

About thirty years ago, we solved this problem by introducing role-based access control (RBAC), which enables subsystems to control access based upon assigned roles.

To illustrate why these kinds of controls matter, let’s imagine that we have three employees who work for a medical clinic: Vijay works in the billing department, Michelle is a nurse, and Noelle is a security auditor. All three of these users have access to the patient tracking system, but since they have access for different reasons, they have access to different information. For example, when Vijay logs in, he can see a list of every patient in the system, the date they were admitted, and a code for every procedure performed on them (such as X-rays), but he cannot see the results of these procedures or any notes that medical personnel put in the system. Michelle, on the other hand, has access to these notes and the results of the procedures, but she can only see this information for current patients, and she cannot access it after the patient is discharged. When Noelle logs in, she can see a list of every user in the system, when they were added, and when they accessed patient records, but she cannot see any details about the patients themselves.   

Now, let’s take a closer look at the role of our hypothetical security auditor, Noelle. While she can see information about who accessed what on demand (for example, she can see that Vijay accessed the code for a patient’s X-ray procedure while Michelle looked at the results of the X-ray), this is not scalable or very reactive. But what if this information was compiled into a log and loaded into a centralized logging system? Not only would this allow for better scalability (for example, adding more clinics without adding additional security auditors), it would also allow for automated reporting on potential security issues such as a nurse attempting to access patient records after hours or attempting to access the records of a patient from another clinic. Both of these events could be signs that staff accounts have been hacked, and the earlier it’s discovered, the better the chance of preventing a data leak that could ruin the reputation of the clinic and the wider organization. 

For this and a host of other reasons, both RBAC and centralized logging are key for successful service delivery.

‍

‍

Your Service Providers Use Identities, Too

Almost every business uses external services as part of its day-to-day operations, for everything from HR to CRM Salesforce. All of these third-party service providers have their own identity systems that rely on RBAC, too. The big, enterprise-class vendors have the ability to leverage Security Assertion Markup Language (SAML) as part of their authentication and authorization process. SAML allows them to leverage existing identities and roles within your organization to control access to your data that’s stored in their systems.

The basic process is quick and fairly seamless:

1. A client connects to the service provider.
2. The service provider redirects to the client organization’s identity provider with a basic SAML token (such as an Active Directory).
3. The identity provider recognizes the SAML token and asks the client for their login credentials.
4. After a successful login, the identity provider redirects the client back to the service provider with a fully populated SAML token, which can include client information and authorized roles.
5. The service provider receives the SAML token and processes its data; then, it grants the client access according to the roles that it has been assigned.
6. The client uses the service provider.

By leveraging SAML and taking advantage of its single sign-on and federation features, your organization’s identity provider can have full control over both the accounts and the roles that are used by any solution providers. This use allows existing processes to handle account management, and any centralized logging that you have in place will gain immediate visibility into logins and access requests on those external systems. Many third-party services also allow events and other activities to be exported as logs, either in real-time or as a scheduled activity. These logs can then be incorporated securely into your centralized logging to improve visibility into all ongoing activities across your organization.