Risk management involves the systematic approach to addressing potential threats to a company's IT assets. This process entails identifying, assessing, and mitigating risks in a manner consistent with the organization's risk tolerance. The goal is to empower businesses to effectively deliver "compliant access."
The term compliant access denotes minimizing the risks related to granting access to business resources by adhering to established guidelines and policies. This kind of access applies not only to individuals but also to systems, applications, software, and other business-related assets. Compliant Access Delivery incorporates a business modeling method and integrates multiple Identity and Access Management (IAM) technologies to automate and maintain appropriate access to IT systems for each user while consistently reducing risk.
In a corporate setting, compliant access implies "role-appropriate" access and reflects an organization's risk-related "business policies." Within the organization, existing operational procedures, industry standards, and regulatory requirements dictate what is suitable for a position, what constitutes risk, and what is considered non-compliant.
Obstacles in Conventional Risk Management Strategies
Modern organizations face the daunting task of managing enterprise risks spread across various cloud and on-premise systems, often resulting from a dangerous mix of cross-system access. With the extensive number of enterprise-level applications being utilized, it is essential for companies to comprehend the permissions model for each application they employ. Failure to do so may result in users receiving excessive access, generating unwarranted risks. EmpowerID addresses this concern by providing one of the most extensive Identity Governance and Administration (IGA) connector libraries available, capable of connecting and integrating even the most unique permissions models and inheritance structures within applications. This method consolidates diverse permissions from each system into a unified, comprehensive, and business-friendly model.
Many IAM solutions primarily focus on the technical aspects of access control, lacking a model that links entitlements in technical systems to easily understandable business processes. For example, take the creation of a purchase order in SAP. In this system, entitlements are represented by TCodes, with the TCode for creating a purchase order being ME21N. While application specialists may be familiar with the TCode's significance, numerous business users likely are not. This issue becomes more complex when considering the multiple technical systems used in a business's daily operations, each with its own set of entitlements available to users. As a result, those responsible for managing access may spend an excessive amount of time determining exactly "who can do what, where, and when with their IT systems."
EmpowerID Risk Management Approach
EmpowerID acknowledges that each organization has its distinct language for processes and policies and has developed its solution to incorporate this language into risk management. This approach understands that delivering efficient, compliant access involves more than simply replicating the potentially obscure rights and entitlements found within technical systems.
Integrating your Business Model
The EmpowerID Compliant Access Solution is built on the concept that all businesses can be broken down into a series of processes executed during the continuous production and delivery of their products or services. Each business process consists of a sequence of tasks carried out by internal or external participants to complete the process. Moreover, each task in every process can be divided into the functions performed while accomplishing the task. In simpler terms, EmpowerID defines functions as "business-defined activities that a person can perform." Using this method, the technical term "ME21N" mentioned earlier could be translated simply as "Create Purchase Order," making it immediately more understandable for business users.
To address this requirement, EmpowerID leverages an organization's business model and language to enforce and provision Compliant Access across both cloud and on-premise systems.
The EmpowerID Risk Management Solution simplifies risk management using an organization's business model and language. This allows for the abstraction of technical access rights terminology, replacing it with language that is more easily comprehended by users, their managers, and those responsible for risk management.
EmpowerID begins with the assumption that all businesses consist of a series of processes conducted during the production and delivery of their goods or services. Each business process is made up of a sequence of tasks executed by internal or external participants to achieve that process. Furthermore, each individual task in every process can be further examined into the functions performed during the completion of that task.
Functions for Entitlements
In EmpowerID, functions represent business-defined activities that an individual can perform, such as creating a purchase order within a broader purchasing business process. As mentioned earlier, the purpose of a function is to translate a technical system's entitlement into business language. A function does not grant any capabilities in an external application but instead represents those capabilities in a user-friendly manner for business users.
Functions must be defined and mapped to entitlements in a specific system. Once defined and mapped, EmpowerID periodically compiles a function to identify all individuals in the system who possess that function. EmpowerID has two types of functions: global functions and local functions.
Global Functions
Global functions depict an action that users can perform in an application, such as "Create Purchase Order" or "Create Group." They act as a bridge between the global rights and roles that EmpowerID inventories from a connected application and the business users responsible for delivering compliant access. When EmpowerID connects to an external identity-aware application like 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 then be mapped to the appropriate global functions. For instance, "Create Group" is an action that users can perform in multiple applications like ServiceNow, AWS, SAP, Salesforce, and EmpowerID. This action can be represented in EmpowerID with a single "Create Group" global function.
Figure 4: Global Function that represents an action that a user could perform in multiple systems
Local Functions
Local functions describe actions that users can perform within a specific location, such as "Create Purchase Orders in Austria" or "Create Groups in Azure Tenant X." In EmpowerID, local functions are added to global functions to establish a logical connection between general actions that users can perform in applications and the actual entities, systems, and locations where they can execute them. For instance, "Create Groups in Austria" would be a local function associated with the "Create Groups" global function. As depicted below, you can add as many local functions to a global function as required.
Function Mapping
Functions, on their own, are merely empty containers representing actions that users could perform within your IT environment. To make them useful, they must be mapped to specific rights and roles. In EmpowerID, this process is called adding "function mapping rules" to functions. Function mapping takes place initially at the global function level and subsequently at the local function level.
Global Function Mapping
At the global function level, function mapping entails adding global rights, global roles, and local functions to the function that logically represent what users with the function could do. For instance, if you create a global function called "Create Azure Groups" to identify who can create groups in Azure, you should only add to the function those function mapping rules related to creating groups in Azure. Figure 6 below illustrates this, displaying some of the function mapping rules for the "Create Azure Groups" global function in the EmpowerID Web interface.
From Figure 6, we observe that there are three types of function mapping rules:
Global Rights Granting Function (Mapped) – Specifies the global rights, if any, related to the function. In this example, global rights would be those rights that enable someone 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 allow someone to create groups in Azure.
Local Functions – Specifies the local functions 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. Revisiting 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 depend 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 depend 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
Organizations create risk policies to define critical or sensitive functions within their IT infrastructure and to identify toxic combinations or Segregation of Duties (SOD) violations. Risks can vary from users having access to high-risk functions unrelated to 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. A risk can have multiple functions as required, but it must have at least one for the risk engine to calculate the risk rules. (SOD risks require a minimum of two – a risk function and a risk-segregated function.) Risks can be both global and local.
Global Risks
Global risks represent actions that users can perform in one or more applications considered potentially risky by an organization. Consequently, global risks map to global functions that define the specific rights and roles granting users the ability to perform those actions. For example, a global risk named "Create Purchase Order" could be mapped to a global function – known as a risk function – also named "Create Purchase Order." When the risk engine compiles a global risk, it returns all users with the risk functions.
Local Risks
Local risks represent actions that users can perform within a specific location or application instance considered potentially risky by an organization. In EmpowerID, local risks are added to global risks to logically connect the generic actions specified by global risk policies to the actual entities, systems, and locations where users can perform them. An example of a local risk would be "Create Purchase Order in SAP Prod" mapped to a global risk named "Create Purchase Order." When the risk engine compiles a local risk, it returns all users with those risk functions as violations.
Risk Rules
Risk rules are the functions added to a risk. A risk can have multiple functions as required, but it must have at least one for the risk engine to calculate the risk rules. (SOD risks require a minimum of two – a risk function and a risk-segregated function.)
The image below 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 calculates the risk rules based on the defined risk functions and risk-segregated functions. 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 classified as either Preventative or Detective. Preventative controls involve real-time checks that take place when access is being requested or assigned to determine if the assignments breach any risk policies. EmpowerID uses preventative controls to enable users requesting access to a resource in the IAM Shop to see any risk policy violations their access request might cause before submitting it. In such cases, users must acknowledge the violations to continue with the access request.
When violations like those mentioned above are identified and submitted for approval, the requests undergo an additional layer of approval by risk owners. The risk owners can either accept the risk and implement mitigating controls or reject the risk and deny the access assignment. Preventative controls are easier to implement, as the risk engine focuses on a smaller data set derived from newly assigned items and the recipient's current access.
Detective controls are more data and processing-intensive for the risk management system. Every day, thousands of access and attribute changes can occur across hundreds of an organization's on-premise or Cloud systems outside the control of the risk management system. These changes often produce ripple effects, leading to larger changes driven by inherited policies and users' lifecycle events, resulting in the readjustment of their access. Therefore, new risk violations must be "detected" by the engine, which is only possible by continuously reanalyzing all the access, attribute, and entitlement data collected from external systems. EmpowerID adopts a big data approach to this complex challenge, boiling down the net results of all these access assignments to detect violations obtained even through multiple disconnected inheritance hierarchies and dynamic policies. The EmpowerID engine also captures a complete picture of how the user triggers 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, who must decide whether to allow the user to obtain or keep the offending access.
If EmpowerID discovers users violating the risk rules for a local risk (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, alerting risk owners of pending violations awaiting their decision. Risk owners can analyze all aspects of how the risky access was obtained and decide whether to allow the risk and add optional mitigating controls or opt for the violation to be corrected and the risky access removed.
Figure 10: Risk violations
Risk violations are logged, tracked, and risk owners are alerted of pending violations awaiting their decision. Risk owners can analyze various aspects of how the risky access was obtained to decide whether to allow the risk and add optional mitigating controls or opt for the violation to be corrected and the risky access removed. The available violation data includes the following information:
When the violation was discovered
Mitigation status
The violator – EmpowerID distills 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 with the function, EmpowerID will flag each person in the role as a violator to provide a comprehensive view of the risk magnitude.
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 of acknowledging a risk but allowing it while actively implementing checks and balances procedures through mitigating controls. In EmpowerID, mitigating controls are objects defined at a global level and associated with global risks. Once connected with global risks, they become available for mitigating local risks and can be used for addressing specific violations to those risks. Risks can have multiple mitigating controls, offering risk owners the flexibility to select the most appropriate control.
Premitigation occurs when one or more mitigating controls are assigned to risk rules, enabling the system to automatically mitigate any violations to those rules. For instance, if it is known that users with a specific role will cause one or more violations of risk rules, a mitigating control can be assigned to the rules, preventing the need for routing the violations to risk owners for mitigation. Instead, 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.
Figure 11: Relationship Between Risks and Mitigating Controls