EmpowerID Risk Management

What is Risk Management?

Risk management is the process of managing risks associated with an organization’s IT resources. It involves identifying, assessing, and treating risks to those resources in a manner that best reflects the organization’s risk tolerance. The goal is to help businesses more effectively deliver “compliant access.” Compliant access relates to minimizing the risk associated with granting access to business assets via standards and policies. Such access not only applies to people but also to systems, applications, programs, or other business-related resources. Compliant Access Delivery uses a business modeling approach and synthesizes multiple Identity and Access Management (IAM) technologies to automate and maintain each user with the appropriate access to IT systems while continuously minimizing risk. In a business sense, compliant access is access that is “position appropriate” and reflective of an organization‘s risk-related “business policies.” Within the business, existing operating processes, industry norms, and regulatory restrictions define what is job appropriate, what is a risk, and what is non-compliant.

The Problem with Traditional Approaches to Risk Management

The reality for organizations today is that enterprise risks are scattered across many Cloud and on-premise systems and are often acquired by a risky combination of cross-system access. Given the sheer number of enterprise-level applications available, it is imperative for organizations to know the permissions model for each of those applications they use. Otherwise, users may be given more access than needed, resulting in unnecessary risks. To gain visibility and control over these risks, EmpowerID provides one of the largest IGA connector libraries available with the ability to connect and consume even the most idiosyncratic permissions models and inheritance used within your applications. In this way, the disparate permissions in each system can be brought together into one comprehensive and business-friendly permissions model. Most IAM systems manage only the technical aspects of access control and, as such, fail to provide a model that maps the entitlements in technical systems to clearly understood business processes. For example, consider the act of creating a purchase order in SAP. In that system, entitlements are designated by TCodes, and the TCode for creating a purchase order is ME21N. While application experts might readily know what the TCode means, many business users probably will not. And that is one entitlement in one system. When one considers the many technical systems that could be used within the daily operations of a business — and the amount of entitlements available to users within each — it becomes easy to see how those responsible for managing access can spend an undue amount of time uncovering exactly “who can do what, where and when with their IT systems.”

Open

EmpowerID Risk Management

EmpowerID understands that each organization has its own particular language for processes and policies and designed the solution with the flexibility to bring that process language into risk management. This model understands that to help organizations deliver effective compliant access requires more than just echoing what many could consider to be the “black box” speak of the rights and entitlements available within technical systems.

Leverages your Business Model

The EmpowerID Compliant Access Solution starts with the premise that all businesses can be broken down into a series of business processes performed during the ongoing production and delivery of their goods or services. Each business process is itself, a series of tasks that can be performed by internal or external participants to complete that process. And each individual task in each process can be broken down into the functions that are executed in the process of completing that task. Simply put, EmpowerID defines functions as “business defined activities that a person can perform.” Using this approach, the technical term “ME21N” mentioned above could be translated simply as “Create Purchase Order.” The activities are the same, but the terminology for the latter is immediately clearer for business users.

Open

To meet this need, EmpowerID leverages an organization’s business model and language to both enforce and to provision Compliant Access across Cloud and on-premise systems.

The EmpowerID Risk Management Solution simplifies risk management by leveraging an organization’s business model and language to allow them to abstract technical access rights terminology away from business users in favor of language that is more readily accessible to users, their managers and those responsible for risk management.

EmpowerID starts with the premise that all businesses can be broken down into a series of business processes performed during the production and delivery of their goods or services. Each business process is itself, a series of tasks that can be performed by internal or external participants to complete that process. Each individual task in each process can be further broken down into the functions that are executed in the process of completing that task. This model looks like that shown in Figure 2.

Functions for Entitlements

In EmpowerID, functions are business defined activities that a person can perform. An example of a function would be the act of creating a purchase order within a much larger purchasing business process. As mentioned above, the purpose of a function is translate an entitlement in a technical system to language of business. A function does not grant any capabilities in an external application. It simply represents those capabilities in a user-friendly way for business users.

Functions need to be first defined and then mapped to entitlements in a given system. Once defined and mapped, EmpowerID compiles a function on a scheduled basis to return all people in the system who have the function. You have two types of functions in EmpowerID, global functions and local functions.

Global Functions

Global functions represent an action that users can do in an application, such as “Create Purchase Order” or “Create Group.” They serve as the bridge between the global rights and roles that EmpowerID inventories from a connected application and business users responsible for delivering compliant access. When EmpowerID connects to an external identity-aware application such as SAP or AWS, it inventories the global rights and roles defined in those applications and stores them in the EmpowerID Identity Warehouse. These inventoried rights and roles can be mapped to the appropriate global functions. For example, “Create Group” is an act that users can do in numerous applications like ServiceNow, AWS, SAP, Salesforce and EmpowerID. This action can be represented in EmpowerID with a single “Create Group” global function.

Local Functions

Local functions represent an action that users can do within a specific location, such as “Create Purchase Orders in Austria” or “Create Groups in Azure Tenant X.” In EmpowerID, you add local functions to global functions to logically link the generic actions that users can do in applications to the actual entities, systems, and locations where they can do them.  In this model, “Create Groups in Austria” would be a local function belonging to the “Create Groups” global function. As shown below, you can add as many local functions to a global function as makes sense.

Function Mapping

In and of themselves, functions are nothing more than empty containers that represent actions that users could do within your IT environment. To have use, they must be mapped to specific rights and roles. In EmpowerID, this is known as adding “function mapping rules” to functions. Function mapping occurs first at the global function level and then at the local function level.

Global Function Mapping

At the global function level, function mapping involves adding to the function the global rights, global roles and local functions that logically represent what users with the function could do. For example, if you create a global function named “Create Azure Groups” that you want to use to see who can create groups in Azure, you should only add to the function those function mapping rules that relate to creating groups in Azure. We can see this in figure 6 below, which shows some of the function mapping rules for the “Create Azure Groups” global function in the EmpowerID Web interface.

From figure 6, we can see that there are three function mapping rule types:

• Global Rights Granting Function (Mapped) — Specifies the global rights, if any, related to the function. In this example, the global rights would be those rights that give someone the ability to create groups in Azure.

• Global Roles Granting Function (Mapped) — Specifies the global roles, if any, related to the function. In this example, the global roles would be those Azure roles that give someone the ability to create groups in Azure.

• Local Functions — Specifies the local functions to be derived from the global function. All local functions should be related to the parent global function. In this example, a local function could be “Create Azure Groups in Austria.”

Local Function Mapping

Local functions are created by adding them to global functions as function mapping rules. Returning to the “Create Azure Groups” global function as an example, if you want to know who could potentially create groups in an Azure tenant in Austria, you could add “Create Azure Groups in Austria” to the function as a function mapping rule.

Once the local function is added to a global function as a function mapping rule, you can then map the function to the local rights or roles specific to it. Local function mappings include the following possibilities:

• Local Rights Granting Function (Mapped) — Specifies the local rights, if any, related to the function. Local rights that can be mapped to local functions are dependent on the global rights mapped to the parent global definition. A right that is not mapped first in the parent global function cannot be selected for the local function.

• Local Roles Granting Function (Mapped) — Specifies the local roles, if any, related to the function. Local roles that can be mapped to local functions are dependent on the global roles mapped to the parent global definition. A role that is not mapped first in the parent global function cannot be selected for the local function.

• Assignees Granting Local Function (Mapped) — Allows you to specify one or more EmpowerID actor types with the function. Actor types can include:

  • Business Role and Location — All people belonging to the Business Role and Location will be flagged as having the function

  • Group — All people belonging to the group will be flagged as having the function

  • Management Role — All people belonging to the Management Role will be flagged as having the function

  • Management Role Definition — All people belonging to the Management Roles derived from the definition will be flagged as having the function

  • Person — The specified person will be flagged as having the function

  • Query-Based Collection — All people belonging to the Query-Based Collection will be flagged as having the function

Risks

Risks are policies an organization creates to define the functions people could do within their IT infrastructure that the organization considers to be critical, or sensitive, or where users having a particular combination of functions would produce a toxic combination or Segregation of Duties (SOD) violation. Risks can encompass everything from users have access to high-risk functions not needed in their daily work routine to users having the ability to perform end-to-end functions within an application. Risks are comprised of risk rules, which are the functions added to the risk. Risks can have as many functions as is logically needed but need to have at least one for the risk engine to calculate the risk rules. (SOD risks need at least two—a risk function and a risk segregated function.) Like functions, risks can be both global and local.

Global Risks

Global risks represent actions that users can do in one or more applications that an organization considers to be potentially risky.  As such, global risks map to the global functions defining the specific rights and roles that grant users the ability to perform those actions. A simple example of a global risk would a risk named “Create Purchase Order” that is mapped to a global function—known as a risk function—named “Create Purchase Order.” When the risk engine compiles a global risk, it returns all users having the risk functions.

Local Risks

Local risks represent actions that users can do within a specific location or application instance that an organization considers to be potentially risky. In EmpowerID, you add local risks to global risks to logically link the generic actions specified by that users can do in applications specified in a global risk policy to the actual entities, systems, and locations where they can do them.  A simple example of a local risk would be a risk named “Create Purchase Order in SAP Prod” that has been mapped to a global risk named “Create Purchase Order.” When the risk engine compiles a local risk, it returns all users having the risk functions as violations.

Risk Rules

Risks are comprised of risk rules, which are the functions added to the risk. Risks can have as many functions as is logically needed but need to have at least one for the risk engine to calculate the risk rules. (SOD risks need at least two—a risk function and a risk segregated function.)

The below image shows a risk that was authored in EmpowerID. The risk is a SOD risk with one risk function, the SAP Create Purchase Order function and one risk segregated function, the SAP Approve Purchase Order function. When the risk engine compiles this risk, it compiles the risk functions and risk segregated functions defined by the risk and calculates the rules of the risk. Risk rules only apply to local risks, which are risks scoped to a specific instance of an application rather than global risks, which run against all instances of an application.

Risk Violations

Risk Management controls are typically described as being either Preventative or Detective. Preventative controls are the real-time checks that occur when access is being requested or assigned to determine whether the assignments violate any risk policies. When detected, the assignments go through another level of approval by the risk owners either to accept the risk and add some mitigating controls or reject the risk and prevent the access assignment. Preventative controls are easier to implement as the risk engine focuses on a smaller set of data based on the new items being assigned and the recipient's existing access.

Detective controls are much more data and processing-intensive for the risk management system. On any given day, thousands of access and attribute changes can occur across hundreds of an organization’s on-premise or Cloud systems outside of the control of the risk management system. These changes often produce ripple effects leading to more massive changes driven by inherited policies and lifecycle events for users and the readjustment of their access. Therefore, new risk violations must be “detected” by the engine, which is only possible by continuously reanalyzing all of the access, attribute, and entitlement data pooled from these external systems. EmpowerID takes a big data approach to this complex challenge, boiling down all these access assignments' net results to detect violations obtained even through multiple disconnected inheritance hierarchies and dynamic policies. The EmpowerID engine also captures a complete picture of exactly how the user is triggering the violation and the roles or entitlements from which they receive the Segregated Business Functions.

Whether detected by preventative or detective risk controls, violations of risk policies must be routed to risk owners to decide whether to allow the user to obtain or keep the offending access.

If when calculating the risk rules for a local risk, EmpowerID discovers users violating the rules (they have one or more risk functions defined by the local risk), it flags the violations and sends them to risk owners for approval, mitigation or remediation.  Risk violations are logged and tracked with risk owners alerted of violations pending their decision. Risk owners can analyze all aspects of how the risky access was obtained and decide to allow the risk and add optional mitigating controls or opt for the violation to be corrected and the risky access removed.

Risk violations are logged and tracked with risk owners alerted of violations pending their decision. The risk owners can analyze all aspects of how the risky access was obtained and decide to allow the risk and add optional mitigating controls or opt for the violation to be corrected and the risky access removed. Violation data available includes the following information:

• When the violation was discovered

• Mitigation status

• The violator — EmpowerID distils all violations down to the person violating the rule, regardless of how they received the violating functions. For example, if numerous people belong to a role that has the function, EmpowerID will flag each person in the role as a violator to give you a full picture of the magnitude of the risk. Risk owners can view the exact assignment point that caused the person to be in violation.

• The violation

• The risk

• Risk type

• Whether the violation is still active

• When the risk was modified

• The risk migitator, if any

Risk Mitigation and Premitigation

Mitigation is the process by which you recognize a risk but allow it, choosing instead to actively mitigate it with checks and balances procedures. In EmpowerID you achieve this through the use of mitigating controls. Mitigating controls are objects that you define at a global level and associate with global risks. Once associated with global risks they become available for mitigating local risks and can be used for mitigating specific violations to those risks. Risks can have multiple mitigating controls, giving risk owners the ability to select the mitigating control that is most appropriate.

Premitigation occurs when you assign one or more mitigating controls to risk rules in order to have the system automatically mitigate any violations to those rules. So for example, if you know that a users with a role will cause one or more violations to risk rules, you can assign a mitigating control to the rules and the system will not route the violations to risk owners for mitigation. The system approves the violations based on the premitigation controls. In all cases, EmpowerID maintains a record of mitigations and premitigations in the Identity Warehouse.

Compliant Access Self-Service (Exceptions Management)

The overall goal of Compliant Access Delivery is to reduce the need for end-users to request additional access, also known as “exceptions.” Access not granted by a person’s roles is considered an exception and must go through a controlled yet easy-to-use process before being granted. Exceptions represent an additional risk and create manual work for their processing and approval and extra audit work during compliance recertifications. EmpowerID’s best practice approach to exceptions management ensures that exceptions are always based on proper justification, traceable and auditable, manageable, and temporary whenever possible.

Eligibility

EmpowerID provides a best-in-class access request microservice known as the “IT Shop.” As an additional access request interface option, the microservice enables end-users to initiate compliant access requests for themselves. The critical aspect of providing a simple end-user experience for access requests and to ensure that only compliant access can be requested is controlling which items different types of users see and may request. Suppose all end users are presented with the same catalog of requestable items. In that case, the user experience quickly becomes overwhelming and confusing as users must filter through large amounts of data to find the access they are looking for that would be relevant for them to request. Exposing unnecessary data also creates a severe security vulnerability as external users or potentially malicious actors may browse the entire catalog of the organization’s most sensitive roles and resources. Also crucial for regulatory compliance is to blacklist or explicitly deny the ability of certain groups of users ever to see or request specific roles and resources to enforce country-specific restrictions such as the International Traffic in Arms Regulations (ITAR).

EmpowerID offers a powerful policy engine to control which users may see and request which roles and resources in the IT Shop. These policies are known as “Eligibility.” Eligibility policies may apply to users by attribute query, role, group, or other criteria, making it easy to target who receives which policies and have the assignment automated and maintained throughout their lifecycle. To further ease the administrative burden, Eligibility policies can be applied to all requestable items of a type by location in addition to one by one. This allows policies to be broader, granting or excluding eligibility using the EmpowerID Location tree. For roles, eligibility policies can be applied to their members to control what the members may see and request in the IT Shop. Policies also apply to the role itself as a possible IT Shop item to control who may see and request it.

Eligibility policies can be defined as either inclusion rules or exclusion rules. Inclusion rules define the items a user is authorized to see and request in the IT Shop and ensure these are only the ones that would make sense for them to request. A multinational company example would be a Field Sales employee in Austria that should not see the same requestable items as a Developer in Brazil. Their catalog of requestable roles and resources should be different to provide a pleasant user experience and ensure that unwarranted access requests are not generated, creating unnecessary approval tasks.

Eligibility Exclusion rules would be created as a protective measure to enforce regulatory restrictions and ensure that specific classes of users are not accidentally given the ability to request items that they should not.

Eligibility policies also include the capability of affecting the approval flow for an item requested by a user. When assigning eligibility policies, the policy author may assign an Eligibility Type for the assignment.

There are three types of eligibility in EmpowerID.

• Eligible — Users can request items in the IT Shop, and the request will go for approval unless the requesting person has the RBAC delegations needed to grant the access being requested.

• Pre-Approved — Users assigned the policies are pre-approved for the items to which the policy is applicable. When the IT Shop user later requests access, it will not require an approval step before being fulfilled.

• Suggested — The IT Shop item will show a “Suggested” additional item they may request because of their existing roles or in the context of a role they are currently requesting. The item will still follow standard approval routing rules.

Approvals and Approval Routing

Being built on a workflow paradigm, EmpowerID includes a powerful approval routing engine and friendly end-user interfaces for task tracking and decisions. As discussed above, Eligibility policies are considered when calculating if a request requires approval and if so, how many approval steps and to whom should the tasks be assigned at each step. Determination of the approval process is dynamic and considers the roles of the requestor, the sensitivity of the items being requested, and an organization’s risk and SoD policies. Based on these factors an item may require many levels of approval and an additional SoD approval by the risk owner or skip the approval process entirely.

Approvers are notified via configurable and localized email notifications with reminder emails configured based on flexible policies. All decisions at each step in the process are logged and traceable up to and including the final fulfillment of access.

Next Steps

• Create Global Functions

• Map Global Functions

• Create Local Functions

• Map Local Functions

• Create Global Risks

• Add Risk Rules to Global Risks

• Create Local Risks

• Add Risk Rules to Local Risks

• Create Mitigating Controls

• Add Mitigating Controls to Risks

• View Risk Violations