About 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.

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 7, 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.

Next Steps

• Create Global Functions

• Map Global Functions

• Create Local Functions

• Map Rights to 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