You know what they say happens when you assume…
I’ll leave it to you to fill in the answer to this old joke.
How does this apply to identity security in business applications?
The past few years have shown that security and compliance leaders can’t simply assume that predefined user permissions and entitlements in critical business applications, like ERP and HCM systems, are set up correctly and move on to other projects. Identity and risk governance must be ongoing and involve more granular understanding of business application security models than a simple check-the-box exercise.
Below are three common areas where organizations often rely on false assumptions and therefore miss critical compliance gaps and security vulnerabilities. For each, I’ve included emerging strategies you can use to adapt your Segregation of Duties (SoD) and user access strategies to gain more detailed visibility and catch the “gotchas” that can easily fly under the radar.
1. Cross-application risk increases as your application environment grows more fragmented
Most companies nowadays have 10 or more business applications, as ‘best of breed’ applications that do one or two things have replaced monolithic ERP applications with functionality for every business need. As a result, you can’t simply assess user entitlements for a single system or review each system in a silo.
What to do instead:
Account for whether users are over-permissioned or have conflicting access rights across applications. For example, a finance manager may use one system to set up a vendor and another, potentially disconnected system, to pay them.
For detailed recommendations on implementing cross-application checks, read Managing Identity and Access Controls Across Multiple Applications.
2. Out-of-the-box security roles from software vendors don’t always mean what you think
Software vendors set up security roles in applications for the broadest use cases. The labels they use for these roles may not match your needs. For example, someone set up with the role “AP clerk,” may be able to do multiple things in a system, including executing transactions, even though that may not be part of their job responsibilities in your specific organization.
Additionally, IT teams may be responsible for setting up security in a business application, but they don’t know what access a user should have, or the inner workings of the security model. The best implementation results when your business process owner and IT team work together.
What to do instead:
Start by fostering open communication between IT and business process owners (BPOs). First, IT gathers tasks that a user will perform, which can be done through a workshop with BPOs. Then, IT can isolate securable objects from tasks, and determine what access is needed to execute the tasks. Use least privilege security design to look at the actions in a system.
When using least privilege security design, it is critical to identify the combination of tasks in the system that would cause a financial risk, to make sure that no user can perform that action without a process control in place or a separate user to approve that workflow.
Make sure you are analyzing risk at the lowest securable object or permission level; below you can see an example of the security model for Microsoft Dynamics 365 Finance & Supply Chain. When reviewing SoD risk, account for the transactions each role can execute, the data they can access, and any other permissions they have. This allows you to be very precise in detecting SoD violations and avoid false positives.
An example of a false positive that could occur: let’s say I have a role and assign every privilege in the system to it, therefore bypassing any direct duty assignment. This would give a user extremely high rights to the system and should trigger every SoD, but when I perform this setup no SOD violations are reported. This is because the solution does not look at the access being assigned but only looks for a combination of duties being assigned.
For more detailed guidance on the role of an SoD matrix or ruleset, check out:
How using a segregation of duties matrix and ruleset strengthens internal controls to reduce risk.
3. Your business applications likely have over provisioned access and license creep
Business application users are often over provisioned with access. In a common scenario, when an employee goes on sick leave another employee is granted temporary access to cover for them until they return. This elevated access comes in the form of a license with additional entitlements, and often the elevated access never gets removed.
From a risk perspective, having more privileges than necessary runs counter to the Principle of Least Privilege, which says people should be granted only the access necessary to do their jobs, nothing more. The more high-level access entitlements that have been granted, the greater your risk exposure.
It’s likely you’ve granted licenses with entitlements to people who don’t use them. They may have used their licenses briefly for a specific project and no longer need them. In this case, you’re paying for software licenses you don’t need.
Consider Microsoft Dynamics 365 Finance and Supply Chain (D365 F&SC), a cloud-based Enterprise Resource Planning (ERP) software associated with a high level of risk. Within D365 F&SC, user security and licenses are tied together. The type of license purchased depends on the user's role and the features required. Microsoft D365 F&SC has 3 types of licenses:
- Operations
- Activity
- Team Member
Over time, if you are not reviewing and governing access the result is license creep. License usage and optimization is not the primary focus of the ERP software vendor, so license usage data is not readily available in native reports.
What to do instead:
By using a third-party GRC tool that includes telemetry and license usage data and reports, you might find out
- User A has not logged in for 30 days.
- User B has access to advanced analytics in the Finance module but hasn’t used it in six months.
- User C has admin rights but has never performed admin-specific tasks, such as role assignments or workflow customization.
- User D hasn’t viewed or edited records in three months.
If you can identify underutilized or dormant software licenses, then you can reclaim them and reassign them as needed. You may also be able to downgrade or consolidate licenses to reduce costs and risk exposure.
We’re here to help
Delinea Fastpath Access Control analyzes access risks in your business applications, using built-in Segregation of Duties rulesets to identify potential conflicts within and across applications, down to the lowest securable object or fine-grained permission level.
Utilizing telemetry and monitoring features within Fastpath Access Control gives you visibility into access and license usage data so you can shift from reporting on what users could do to what they actually did do. This additional insight empowers you to identify over provisioned access that can be removed, helping reduce both risk and licensing costs.
Don’t let assumptions drive your business application security strategy. Effective SoD and user access management means checking your assumptions at the door.