Compliant Access Solution Overview

All businesses can be broken down into a series of business processes performed in the course of the production and delivery of their goods or services. Each business process is itself, a series of tasks that can be performed by either internal or external participants in order to complete that process. Drilling deeper, each individual task in each process can also be broken down into the functions that are executed in the process of completing that task.

An example of a function would be the act of creating a purchase order within a much larger purchasing business process. Naturally, because such terminology is commonplace, business users can readily recognize the function of creating a purchase order. Furthermore, managers and auditors could easily and quickly identify who within an organization should be entitled to create purchase orders and are, therefore, permitted to perform this function. Similarly, those who are not entitled to create purchase orders, cannot.

Later, when managers need to review employee access rights periodically, it would be simple to see whether the ability to create purchase orders has been assigned to someone for whom it was no longer job appropriate. Again, this is still at a business level and using common terminology, and contrasts starkly with the often unintelligible names and descriptions of technical entitlements that grant access to systems and applications within the software itself. One can see that functions are the missing link that connects traditional technical access management with the world of business-friendly terms and recognizable job appropriate access.

Figure 1 illustrates the clean separation between the business and the technology that supports it.

Here you can see three levels within our organization: The Business Specialists, Application Specialists, and the Application Itself.

At the top, we have the Business Specialists. These are the process specialists within your organization and who have worked with the business to determine, develop, implement, and test the processes that you currently use. Though it’s not essential to have a high level of process maturity, the more mature an organization’s processes are, the easier it is to map to the supporting applications. The processes are separate, unique (you only ever want 1 single way of performing processes), and are comprised of multiple functions. Though each function will, itself, be made up of multiple tasks or work instructions/procedures, you should only have one tested, proven, and efficient way of performing a function–such as ‘create a purchase order’—within your business.

The Business Specialist would then work with the Application Specialist to map these defined business processes and functions to the application itself. At the application level, you can see how a single function can be made up of single or multiple modules from the app.

As outlined, Compliant Access must be “appropriate” and adhere to an organization’s “business policies”. These business policies are specific to an organization and tailored to match how the organization operates, their industry, the processes executed to deliver goods or services, and the regulatory requirements to which it must adhere. Business processes are non-technical in nature and are independent of the IT systems an organization uses.

For example, an organization’s Customer Acquisition Process and related risks do not vary based on whether they use SalesForce.com , Hubspot, or an Excel spreadsheet as their CRM. It makes no difference to the process itself. Moreover, the functions that a user performs in their job role as part of these higher- level processes are already known. As such, they can be mapped out in advance and linked to the required business policy or policies before the IT system itself has been chosen: again, your processes define how you do business and, unless you’re a start-up in the very earliest of days, you will already be doing this.

Also, as part of this process, an organization can and will define what high risk functions merit special attention. This could be an isolated function, or it could be when combined with other functions and involve other factors, such as certain job roles. Furthermore, it’s possible that these latter functions could be low risk on their own but, when combined with others, then require special considerations to prevent fraud or other misdeeds. One classic example is Separation of Duties (SoD), where having the ability to create a purchase order and to approve a purchase order is fine when done by separate users. However, when policy permits a single user to perform both tasks, it’s now an unnecessary risk.

It crucial that risk policies are defined at the function level because these are the actual business activities an organization must monitor and control. Technical entitlements do not directly relate to business concepts or entitlements, and neither do risk policies. Consequently, trying to implement policies in this manner will only lead to confusion for business users, create a lack of visibility into what the user can actually do, and ultimately prove ineffective.

Once your organization has defined and identified what is business-appropriate access and what constitutes risky access, we can now implement the technical controls to deliver, monitor, and enforce access and compliance with business policies. Unfortunately, organizational security is no longer a simple internal/external = trust/no trust equation and requires a new framework for Compliant Access Delivery. This framework is a new way of thinking about security and is called Zero Trust. (And technology vendors are rushing to embrace its principles.)

Zero Trust is based on the idea that identity is the new control plane, and is driven by 3 elements: never trust–access to systems must always be strongly authenticated; always verify–authorization is based on both the identity of the user and the context of the request; and always enforce least privilege–only absolute minimum access is ever given.

This last principle of least privilege is a key concept of both Compliant Access and Zero Trust. Least privilege directs an organization to grant only the minimal appropriate access. This permits us to use Compliant Access’ business process modelling approach to add business appropriate and business risk to the determination of least privilege. Furthermore, when functions are mapped to technical entitlements, this allows an organization to define job appropriate access as it applies to a specific business in their specific industry. Finally, the last component for Compliant Access is adherence to an organization’s policies concerning risk and, specifically, what is defined as being acceptable/allowed or unacceptable/prohibited. In conjunction with Compliant Access, least privilege adds business risk policies into the equation to determine if this least privilege ‘level’ would still produce unacceptable risks. Identifying such cases allows the organization to then make an informed decision whether to accept, and make an exception, or reject it.

An additional approach for modern web-based applications is the Federated Identity or claims-based model. In this model, federated applications trust a central identity and authorization source, such as EmpowerID, to deliver the identity information and Compliant Access as claims during login. The application trusts this information and uses it to both verify the user’s identity and to enforce Compliant Access within the application itself.

A sophisticated example of this can be seen in the AWS authorization model. First, AWS supports receiving AWS IAM “Roles” as claims and, second, these roles are then mapped within AWS to Access policies. An organization can define the functions granted by these AWS roles and ensure that user access is job appropriate and adheres to risk policies.