Understanding Risk Management
?Risk management is the process of managing risks associated with an organization’s IT resources. It involves involves the systematic approach to addressing potential threats to a company's IT assets. This process entails identifying, assessing, and treating mitigating risks to those resources in a manner that best reflects the organization’s consistent with the organization's risk tolerance. The goal is to help empower businesses more to effectively deliver “compliant "compliant access.” Compliant access relates to minimizing the risk associated with "
The term compliant access denotes minimizing the risks related to granting access to business assets via standards resources by adhering to established guidelines and policies. Such This kind of access applies not only applies to people individuals but also to systems, applications, programssoftware, or and other business-related resourcesassets. Compliant Access Delivery uses incorporates a business modeling approach method and synthesizes integrates multiple Identity and Access Management (IAM) technologies to automate and maintain each user with the appropriate access to IT systems while continuously minimizing for each user while consistently reducing risk.
In a business sensecorporate setting, compliant access is access that is “position appropriate” and reflective of an organization‘s implies "role-appropriate" access and reflects an organization's risk-related “business "business policies.” " Within the businessorganization, existing operating processesoperational procedures, industry normsstandards, and regulatory restrictions define requirements dictate what is job appropriatesuitable for a position, what is a constitutes risk, and what is considered non-compliant.
The Problem with Traditional Approaches toObstacles in Conventional Risk Management Strategies
The reality for organizations today is that enterprise risks are scattered across many Cloud Modern organizations face the daunting task of managing enterprise risks spread across various cloud and on-premise systems and are often acquired by a risky combination , often resulting from a dangerous mix of cross-system access. Given With the sheer extensive number of enterprise-level applications availablebeing utilized, it is imperative essential for organizations companies to know comprehend the permissions model for each of those applications application 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 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 and, as such, fail to provide , lacking a model that maps the links entitlements in technical systems to clearly understood easily understandable business processes. For example, consider take the act creation of creating 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 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 can may spend an undue excessive amount of time uncovering determining exactly “who "who can do what, where, and when with their IT systems.”"
EmpowerID Risk Management Approach
EmpowerID understands acknowledges that each organization has its own particular distinct language for processes and policies and designed the solution with the flexibility to bring that process has developed its solution to incorporate this language into risk management. This model approach 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 delivering efficient, compliant access involves more than simply replicating the potentially obscure rights and entitlements found within technical systems.
LeveragesIntegrating your Business Model
The EmpowerID Compliant Access Solution starts with the premise is built on the concept that all businesses can be broken down into a series of business processes performed executed during the ongoing continuous production and delivery of their goods products or services. Each business process is itself, a series of tasks that can be performed consists of a sequence of tasks carried out by internal or external participants to complete that the process. And Moreover, each individual task in each every process can be broken down divided into the functions that are executed in the process of completing that task. Simply putperformed while accomplishing the task. In simpler terms, EmpowerID defines functions as “business "business-defined activities that a person can perform.” " Using this approachmethod, the technical term “ME21N” "ME21N" mentioned above earlier could be translated simply as “Create "Create Purchase Order.” The activities are the same, but the terminology for the latter is immediately clearer ," making it immediately more understandable for business users.
Figure 2: Native System Entitlements VS Functions
To meet address this needrequirement, EmpowerID leverages an organization’s organization's business model and language to both enforce and to provision Compliant Access across Cloud both cloud and on-premise systems.
The EmpowerID Risk Management Solution simplifies risk management by leveraging an organization’s using an organization's business model and language to allow them to abstract . This allows for the abstraction of technical access rights terminology away from business users in favor of , replacing it with language that is more readily accessible to easily comprehended by users, their managers, and those responsible for risk management.
EmpowerID starts begins with the premise assumption that all businesses can be broken down into consist of a series of business processes performed conducted during the production and delivery of their goods or services. Each business process is itself, a series made up of a sequence of tasks that can be performed executed by internal or external participants to complete achieve that process. Each Furthermore, each individual task in each every process can be further broken down examined into the functions that are executed in the process of completing performed during the completion of that task.
Figure 3: Business Process
Functions for Entitlements
In EmpowerID, functions are represent business-defined activities that a person can perform. An example of a function would be the act of an individual can perform, such as creating a purchase order within a much larger broader purchasing business process. As mentioned aboveearlier, the purpose of a function is to translate an entitlement in a technical system to language of business's entitlement into business language. A function does not grant any capabilities in an external application . It simply but instead represents those capabilities in a user-friendly way manner for business users.
Figure 4: Native System Entitlements VS Functions
Functions need to be first Functions must be defined and then mapped to entitlements in a given specific system. Once defined and mapped, EmpowerID periodically compiles a function on a scheduled basis to return identify all people individuals in the system who have the possess that function. You have EmpowerID has two types of functions in EmpowerID, : global functions and local functions.
Global Functions
Global functions represent depict an action that users can do perform in an application, such as “Create "Create Purchase Order” Order" or “Create "Create Group.” " They serve act as the 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 such as 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 example, “Create Group” instance, "Create Group" is an act action that users can do perform in numerous multiple applications like ServiceNow, AWS, SAP, Salesforce, and EmpowerID. This action can be represented in EmpowerID with a single “Create Group” "Create Group" global function.
Figure 54: Global Function that represents an action that a user could perform in multiple systems
Local Functions
Local functions represent an action describe actions that users can do perform within a specific location, such as “Create "Create Purchase Orders in Austria” Austria" or “Create "Create Groups in Azure Tenant X.” " In EmpowerID, you add local functions are added to global functions to logically link the generic establish a logical connection between general actions that users can do perform in applications to and the actual entities, systems, and locations where they can do execute them. In this model, “Create For instance, "Create Groups in Austria” Austria" would be a local function belonging to the “Create Groups” associated with the "Create Groups" global function. As shown depicted below, you can add as many local functions to a global function as makes senserequired.
Figure 6: Relationship between local and global functions
Function Mapping
In and of themselves, functions are nothing more than empty containers that represent Functions, on their own, are merely empty containers representing actions that users could do perform within your IT environment. To have usemake them useful, they must be mapped to specific rights and roles. In EmpowerID, this process is known as called adding “function "function mapping rules” rules" to functions. Function mapping occurs first takes place initially at the global function level and then subsequently at the local function level.
Global Function Mapping
At the global function level, function mapping involves entails adding to the function the global rights, global roles, and local functions to the function that logically represent what users with the function could do. For exampleinstance, if you create a global function named “Create Azure Groups” that you want to use to see called "Create Azure Groups" to identify who can create groups in Azure, you should only add to the function those function mapping rules that relate related to creating groups in Azure. We can see this in figure Figure 6 below illustrates this, which shows displaying some of the function mapping rules for the “Create "Create Azure Groups” Groups" global function in the EmpowerID Web interface.
Figure 7: Function Mapping Rules at the global function level
From figure 7, we can see From Figure 6, we observe that there are three types of function mapping rule typesrules:
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. Returning to 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.
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 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 are dependent 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
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 Organizations create risk policies to define critical or sensitive functions within their IT infrastructure and to identify toxic combinations or Segregation of Duties (SOD) violationviolations. Risks can encompass everything vary from users have having access to high-risk functions not needed in 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. 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.) 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 such. Consequently, 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 an organization considers to be considered potentially risky by an organization. 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 image 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 calculates the risk rules based on the defined 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 management controls are typically described classified as being either Preventative or Detective. Preventative controls are the involve 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 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 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 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 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.
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 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, tracked, and tracked with risk owners are alerted of pending violations pending awaiting their decision. The risk Risk owners can analyze all various aspects of how the risky access was obtained and 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. Violation The available violation data available includes the following information:
When the violation was discovered
Mitigation status
The violator — – EmpowerID distils 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 that has with the function, EmpowerID will flag each person in the role as a violator to give you a full picture of the magnitude provide a comprehensive view of the risk . Risk owners can view the exact assignment point that caused the person to be in violationmagnitude.
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 of acknowledging a risk but allow it, choosing instead to actively mitigate it with allowing it while actively implementing checks and balances procedures through mitigating controls. In EmpowerID you achieve this through the use of mitigating controls. Mitigating , mitigating controls are objects that you define defined at a global level and associate associated with global risks. Once associated connected with global risks, they become available for mitigating local risks and can be used for mitigating addressing specific violations to those risks. Risks can have multiple mitigating controls, giving offering risk owners the ability flexibility to select the mitigating control that is most appropriate control.
Premitigation occurs when you assign one or more mitigating controls are assigned to risk rules in order to have , enabling the system to automatically mitigate any violations to those rules. So for exampleFor instance, if you know it is known that a users with a specific role will cause one or more violations to of risk rules, you can assign a mitigating control can be assigned to the rules and the system will not route , preventing the need for routing the violations to risk owners for mitigation. The 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
Next Steps
| Div | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
IN THIS ARTICLE
|
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|