Taking a risk-based approach to access management
Taking a Risk-based Approach to Access Governance
This five-part blog discusses why IDM is not enough to protect your ERP. This series explores the following topics:
The four threats to your ERP posed by user access request management
A risk-based approach to application access governance
Fine-grained identity governance and administration
Access control capabilities & access governance options
We have discussed Identity Access Management (IAM) and its limitations throughout this blog series. In this part, we will explore the benefits of a risk-based approach to access governance and why it is the most effective strategy for identity and access management in the modern enterprise.
A risk-based approach is relatively straightforward. You identify the highest risks to your organization and make them a priority for controls, policies, and procedures. Your most significant risks are the ones that cost your organization time spent on investigations, money spent on regulatory settlements, unwanted headlines, business partnerships jeopardized, etc. Once you reduce those risks to acceptable levels, you move to the subsequent highest risks.
Organizations are beginning to recognize the importance of using a risk-based approach to access governance solutions. Specialized IGA solutions help organizations better understand what their systems are used for, who has access to them, and what they are doing while they are in the system.
Each organization is unique. But generally, the identity access governance process flows through three steps.
In the first swim lane in this diagram, you can see how companies use SafePaaS or an IDM solution such as Okta, SailPoint, or Ping Identity. The basic idea is to create a governance “hub” of all your access. However, this is easier said than done as some organizations have hundreds of applications. Creating a central access hub is not easy; it takes many interfaces. SafePaaS, for example, has built a platform for all your organization's API services and incorporated multiple tier-one ERP systems, IAM systems, IDM systems, and ITSM systems. SafePaaS provides that hub to make this process of integration easier.
You can see how SafePaaS obtains the employee-manager hierarchy from a system like ServiceNow, SailPoint, or Okta, and the data from Workday, Oracle, or PeopleSoft. This data retrieval enables your organization to create the hierarchy you need to ensure approvals are matched with fine-grained visibility. With this data, you have visibility over the roles and processes that control access approvals.
Using SafePaaS DataProbeETL™ technology, SafePaaS can sync up with that employee-manager hierarchy data periodically. DataProbe™ has ETL capabilities to bring in data from your organization's provisioning systems - your IAM or IDM systems. This gives you a complete view that helps you ensure compliance with your business policies and that the policies are loaded appropriately. An example of such a policy may be that people who create suppliers shouldn't be paying the supplier. This policy needs to be tested against a fine-grained engine set.
The second swim lane does that. As requests come in, whether it's coming in from SailPoint, ServiceNow, Okta, Microsoft Azure, or Oracle, SafePaaS can pick up the request through an API service. Through the API service or directly through SafePaaS, you have a tool that allows you to request access directly. Once a request comes in, SafePaaS can analyze the requested role, which may be a role in the catalog. For example, suppose a controller role is requested. The controller role may consist of AP inquiry, GL manager, AR inquiry, etc, because that's what the controller needs. So, it makes it easy with these ITSM systems like ServiceNow, where the controller's office doesn't have to think about all that jargon. They request the controller role in the catalog, and they are given it. But SafePaaS can map that catalog down to the details and components that make up that role down to the lowest level. Seeing these components is essential because a role may say AP inquiry, but that doesn't mean that's what the role entails. The role could say AP inquiry but have the ability to create and pay suppliers.
These situations are unfortunately widespread for organizations and their auditors. The idea behind a risk-based approach is that preventive controls are better and more cost-effective, costing you less than remediation. With SafePaaS, you can see what privileges the requested role involves. Having a platform that allows you this visibility allows you to avoid roles being given conflicting privileges such as creating suppliers, paying suppliers, and changing customer credit limits. These are the kind of problems that, if undiscovered, can result in financial misstatement risk, operational losses, and fraud.
The third swim lane demonstrates how SafePaaS can process that request and either send it back to the ETL, ServiceNow, or your provisioning system for various levels of approval. SafePaaS has a five-level hierarchy. Most IAM and IDM solutions only have a single level. The problem with single-level approvals is that audit doesn't work that way. For example, if the Global Controller is responsible for all financial risks in the company and someone is requesting access to accounts payable from their Manager. If the manager says, "Hey, give this person GL superuser" and the AP manager doesn't know that the person needs to look at journal entries; they get given access. They're not responsible for the access. So, the problem with having an employee-manager approval is that your Global Control Owners get caught by surprise because they're responsible for these controls, but they're not even in the approval loop. Organizations need more than just one level of approval regarding risk, especially with high risk.
The last swim shows processing approval requests. SafePaaS provides five levels of approval, but most organizations only need three. Usually, the approval chain will consist of the Manager, a Global Control Owner, and somebody in the CISO’s office because risks impact cybersecurity too. In some cases, an organization may have a fourth approval level if they're very diversified. In all cases, the Control Owner should be accountable for certifying the control and approving the control access they're responsible for.
SafePaaS can then provision the role. SafePaaS has APIs, allowing you to configure the platform yourself. For example, suppose you want to provision it into Cloud ERP, E-Business Suite, or other ERP systems. In that case, SafePaaS will make the native API call and create that link. SafePaaS also can put it back in ServiceNow and let the ServiceNow ticket continue. The person that requested the role can pick it up in ServiceNow. ServiceNow can talk to SailPoint, SailPoint can provision it, and so on. There are a lot of “lego” blocks that SafePaaS can put together to meet your needs.
The final piece is audit. That's the purpose of the whole process. That is to say, with this fine-grained access, your IS security team and your auditors can perform the self-service process that is the holy grail of identity governance. That's what all organizations are ideally looking for.
SafePaaS gives organizations a dashboard and the ability to know what's happening at the fine-grained level whenever you need that information. This could be IS security, your external auditors, your partner, or system integrators. You can create role-based access for those people to come in and see what's happening in the business unit, division, and group. That's how SafePaaS can help streamline your current process into a process with embedded preventive controls.