What is Risk Management?
Risk management is the process of managing risks associated with an organization’s IT resources. It involves In a business environment, risk management means systematically 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 controlling threats that could negatively impact a company's IT resources. The ultimate goal is to keep your business running smoothly and ensure "compliant access."
Compliant access involves minimizing potential risks when granting access to company resources, such as computer systems, applications, and software, in line with set guidelines and policies. It means giving access that is appropriate to an employee's role based on company rules about risk. Regulatory rules, industry standards, and company procedures help define what is considered acceptable, risky, or non-compliant.
Challenges with Traditional Risk Management
Many businesses today struggle with managing enterprise risks spread across multiple cloud and on-premise systems. Overlapping system access often creates these risks. Therefore, companies need a deep understanding of the permissions model for every application they use to prevent users from having too much access and increasing risk. EmpowerID steps in to solve this problem with a comprehensive Identity Governance and Administration (IGA) connector library that integrates different permissions models, thereby lowering risk and enhancing understanding of system access.
However, many Identity and Access Management (IAM) solutions primarily focus on technical aspects of access control and lack a model that connects system entitlements to business processes in a user-friendly way. For example, take the creation of a purchase order in SAP. In that this system, entitlements are designated represented by TCodes, and with the TCode for creating a purchase order is being ME21N. While application experts might readily know what specialists may be familiar with the TCode means's significance, many numerous 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.”
likely are not. EmpowerID's risk management approach aims to bridge this gap.
EmpowerID Risk Management Approach
EmpowerID understands acknowledges 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.
Figure 2: Native System Entitlements VS Functions
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.
Figure 3: Business Process
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.
Figure 4: Native System Entitlements VS Functions
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.
Figure 5: Global Function that represents an action that a user could perform in multiple systems
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.
Figure 6: Relationship between local and global functions
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.
Figure 7: Function Mapping Rules at the global function level
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.
Figure 8: Local Functions as Function Mapping Rules
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 a unique way of defining its processes and policies. Therefore, it offers a risk management solution that caters to this uniqueness, making it easier to understand for non-technical audiences while maintaining necessary technical detail for IT professionals.
Integrating your Business Model
EmpowerID understands that every business consists of processes performed continuously to deliver products or services. It simplifies complex technical terms into plain language for business users by breaking down these processes into smaller, "business-defined activities" that a person can perform.
Function Mapping
These "functions" are then mapped to specific rights and roles in a process, which is known as "function mapping." EmpowerID distinguishes between global functions (actions users can perform in multiple applications, such as “create groups”) and local functions (actions users can perform within a specific location, such as “create groups in Azure Tenant X). Function mapping links business users to global rights, roles, and specific entities or systems.
Understanding Risks
Organizations establish risk policies to define critical or sensitive functions within their IT infrastructure and identify toxic combinations or Segregation of Duties (SOD) violations. Risks can vary from users having access to high-risk functions unrelated to their daily tasks to users having the ability to perform end-to-end functions within an application. Risks are comprised consist of risk rules, which are the functions added to the risk. Risks A risk can have as many multiple functions as is logically needed, but need to it must have at least one for the risk engine to calculate the risk rules. (SOD risks need at least require a minimum of two – a risk function and a risk-segregated function.) Like functions, risks Risks can be both global and local.
Global Risks
Global risks represent actions that users can do perform in one or more applications that considered potentially risky by an organization considers to be potentially risky. As sucha result, global risks map to the global functions defining that define the specific rights and roles that grant , granting users the ability to perform those actions. A simple For example of , a global risk would a risk named “Create Purchase Order” that is "Create Purchase Order" could be mapped to a global function – known as a risk function – also named “Create "Create Purchase Order.” " When the risk engine compiles a global risk, it returns all users having with the risk functions.
Local Risks
Local risks represent actions that users can do perform within a specific location or application instance that considered potentially risky by an organization considers to be potentially risky. In EmpowerID, you add local risks are added to global risks to logically link connect the generic actions specified by that users can do in applications specified in a global risk policy policies to the actual entities, systems, and locations where they users can do perform them. A simple An example of a local risk would be a risk named “Create "Create Purchase Order in SAP Prod” that has been Prod" mapped to a global risk named “Create "Create Purchase Order.” " When the risk engine compiles a local risk, it returns all users having the with those risk functions as violations.
Risk Rules
Risks are comprised of risk rules, which Risk rules are the functions added to the a risk. Risks A risk can have as many multiple functions as is logically needed but need to required, but it must have at least one for the risk engine to calculate the risk rules. (SOD risks need at least require a minimum of 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.
Figure 9: EmpowerID Risk Policy
Risk Violations
Risk Management controls are typically described as being
Risk Violations
Preventative Controls
Risk management controls are typically classified as either Preventative or Detective. Preventative controls are the involve real-time checks that occur take place when access is being requested or assigned to determine whether if the assignments violate 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 detected, the assignments go through another level of approval by the risk owners either to
When violations like those mentioned above are identified and submitted for approval, the requests undergo an additional layer of approval by risk owners. These risk owners can either accept the risk and add some implement mitigating controls or reject the risk and prevent deny 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 data set derived from newly assigned items and the recipient's existing current access.
Detective Controls
Detective controls are much more data and processing-intensive for the risk management system. On any given Every day, thousands of access and attribute changes can occur across hundreds of an organization’s organization's on-premise or Cloud cloud systems outside of the control of the risk management system. These changes often produce ripple effects, leading to more massive larger changes driven by inherited policies and users' lifecycle events for users and , resulting in the readjustment of their access. Therefore, new risk violations must be “detected” "detected" by the engine, which is only possible by continuously reanalyzing all of the access, attribute, and entitlement data pooled collected from these external systems. EmpowerID takes adopts a big data approach to this complex challenge, boiling down the net results of 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 triggers the violation and the roles or entitlements from which they receive the Segregated Business Functions.
Risk Owner Decisions
Whether detected by preventative or detective risk controls, violations of risk policies must be routed to risk owners to , who must decide whether to allow the user to obtain or keep the offending access. If when calculating If EmpowerID discovers users violating 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 , alerting risk owners alerted of pending violations pending 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 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.
Figure 11: Relationship Between Risks and Mitigating Controls
Next Steps
https://dotnetworkflow.jira.com/wiki/pages/resumedraft.action?draftId=1279852687| Macrosuite divider macro | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| Div | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
IN THIS ARTICLE
|
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|