As companies seek greater effectiveness in their operations, they add best-of-breed solutions, such as ERP, CRM, HCM, warehouse management, and supply chain management applications, to their environment. While these interconnected business applications increase productivity and reduce errors, they require more and more stakeholders, including employees, contractors, clients, suppliers, and partners, to access the data in these applications.
Many of these organizations struggle with tracking who has access to these applications, what their access allows them to do, and what they are doing with that access. Too often, companies rely on low-productivity manual processes to manage their application risks; multiple spreadsheets, email requests, and sticky notes are part of the error-prone and labor-intensive activities at many organizations. Not only do these legacy processes increase costs, but they are hard to audit, leading to questions about data reliability and control effectiveness.
The inability to track user access across a company's business systems, coupled with granting users more access to your systems than they need, can result in regulatory compliance violations, fines, loss of data, fraud, and loss of funds. As a result, Access Risk Management, which identifies and addresses the risks related to user access provisioning, has become top of mind for today's information security and audit professionals.
Separation of Duties is an essential element of application user lifecycle management in a company's overall risk management plan, which is fundamental to a company's overall Governance, Risk, and Compliance (GRC) initiatives.
In this document, we cover:
Segregation of Duties (also known as Separation of Duties or SOD) is a policy that aims to distribute the critical functions of a process to more than one person in the organization. By identifying and separating conflicting duties, an organization can ensure that a single person can't complete a process without oversight. Giving a single entity control over all aspects of a business process can expose the company to risk because that individual or entity can commit errors, omissions, or fraud and then hide the activity from others. A typical SOD conflict example is a user who can create and pay a vendor. The risk here is that the user can create a fraudulent vendor account that deposits into their personal bank account and then pay that fraudulent vendor via standard accounts payable functionality in the system, all without oversight or detection. By separating the ability to create a vendor from the ability to pay a vendor, the organization ensures that more than one person would have to be involved in completing the process.
Separation of Duties also extends beyond financial roles to IT and Development roles within an organization. For instance, software developers should not be able to develop and test their solutions and then move the solution directly into production without oversight. Instead, different individuals or departments should handle each of these tasks. Otherwise, there is the potential risk that a developer might provide a "backdoor access" to the code or data in production systems, even if that risk was introduced unintentionally.
For example, suppose a programmer has introduced debug functions into their code to monitor and change system variables during the code and unit test phase of development. As an innocent (even if careless) oversight, suppose those debug functions are never removed, and the developer moves the code into the production environment. Without even knowing it, the developer can now manipulate the code or data on the running production system.
A Segregation of Duties ruleset is a collection of SOD conflicts identified by the organization as presenting enough risk to require enforcement. This SOD ruleset considers the business environment, the control environment, and the systems environment.
In an ideal world, businesses would define and enforce SOD across all their in-scope applications (ERP, HCM, CRM, etc.). In reality, this is too expensive and too complex to achieve. In many small organizations, where resources must take on multiple roles, it is not even possible to separate duties (for example, if there is only one person in the accounting position). Within a risk-based audit and compliance approach, SOD rules should still be defined across all in-scope applications. Enforcement should consider both remediation (removal of conflicting access) as well as mitigation. Mitigation of conflicting access risk can use either manual controls or automated controls:
Effective separation of duties helps prevent individuals or groups from committing and then concealing errors and fraud. Adding mitigating controls helps minimize errors or fraud if they occur by exposing them early.
The analyst group, Gartner, has said, "Effective segregation of duties (SOD) controls can reduce the risk of internal fraud by up to 60% through early detection of internal process failures in key business systems." (Market Guide for SOD Controls Monitoring Tools, Gartner, 2017)
The Association of Certified Fraud Examiners also notes that the failure to maintain segregation of duties is a leading cause of fraud in many organizations. The more prolonged fraud goes undetected, the more significant the loss to the company (ACFE Report to Nations). The report predicts that the average company will lose $1.5M each year to fraud.
Financial errors and fraud could lead to erroneous financial statements. As a result, companies can easily under or overestimate their profit or balance sheet and, based on those figures, make unsound financial investments that jeopardize the company's solvency.
The Sarbanes-Oxley Act of 2002 (SOX) is primarily aimed at public companies and was passed following a series of corporate scandals involving falsified financial statements, including Enron, Tyco, and Worldcom. The legislation is intended to help restore investor confidence and protect shareholders, employees, and the public from future fraudulent financial practices in publicly traded companies.
Two sections of the Sarbanes-Oxley Act are of particular interest here.
While SOX does not offer a list of specific controls, it does expect organizations to show proof of security controls for areas such as change management, backup systems, and access to the company premises and business systems.
The SEC guidance on SOX compliance approaches it this way (Sarbanes-Oxley Section 404: A Guide for Small Business):
Think about "what could go wrong" by considering:
Effective management of segregation of duties conflicts and user access to business-critical applications can significantly improve a company's ability to meet SOX audit requirements.
Among other stipulations, SOX requires that publicly traded companies certify that they have instituted controls over their financial reporting. SOX compliance programs include Segregation of Duties controls in critical areas of financial responsibility.
SOX provides some latitude for small companies and companies that have recently gone public by offering them an exemption period before requiring their full compliance with Section 404b of SOX. In addition, the Jumpstart Our Business Startups Act (JOBS Act) further extended the Section 404b exemption period to up to five years for certain companies covered by the act.
Regardless of the length of the exemption, all public companies must eventually demonstrate full SOX compliance. It is in their best interest to put the necessary controls in place sooner than later. Automated SOD tools like Fastpath can help these companies develop rulesets and controls for the Separation of Duties and create streamlined workflows for access reviews.
Some questions that an auditor might ask include:
Sarbanes-Oxley is only one of many federal, state, and local laws, regulations, and ordinances that pertain to data security, user access risk management, and Segregation of Duties. Others include the Gramm-Leach-Bliley Act, the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), Health Insurance Portability and Accountability Act (HIPAA), and Food and Drug Administration (FDA) regulations, to name a few.
Auditors and regulators are looking closely at how companies of all sizes address internal security and access risk management. Management, internal auditors, IT, and business process owners must work together to develop a robust security architecture for their critical business applications and ensure they have complete visibility of the user access and Segregation of Duties risks in these applications.
The traditional role of IT has been to administer the company's network and software, and that has included setting up application security and provisioning users. However, when it comes to managing user access to business applications like ERP and CRM systems, it is the managers and business process owners in finance, accounting, sales, and human resources that are most capable of determining who in the organization should be granted access into the system—as well as the amount of access they should be authorized to have. Even if IT personnel are the ones who ultimately provision users, the responsibility of identifying who gets access and developing SOD rulesets is the responsibility of business management, not IT.
Some common examples where Segregation of Duties conflicts arise include the following combination of job functions:
Implementing the Segregation of Duties for various transactions follows the same general outline:
SOD can be applied to individuals, groups, or entire companies.
For most organizations, SOD involves granting or denying users access to key functions within their business applications by assigning roles.
Most SOD risk comes from the company's financial application, which, for most businesses, is an Enterprise Resource Planning (ERP) software application. While the term "role" may differ depending on the specific ERP being considered (for example, both SAP and Microsoft Dynamics 365 Finance and Operations will refer to a user's "role", while Oracle EBS uses the term "Responsibility", Workday uses the term "Security Group", and Oracle Cloud uses "Job Role"), they all refer to essentially the same concept: what tasks can this person do with his or her assigned permissions in the system?
The work environment is fluid: job requirements change, employees take on new responsibilities, new roles are defined, and new permissions are added to existing job roles. Sometimes, these responsibilities overlap, creating SOD conflicts for role definitions that did not exist before. In these situations, automated SOD tools can assist in finding the conflicts and suggesting mitigations that will resolve the SOD violations.
Rather than focusing on the names assigned to the various roles in these business applications, the actual SOD conflicts will only be found by analyzing permissions that are granted to the roles and the underlying security objects they can access. Here, the term "security objects", like roles, will vary from ERP to ERP: "menu item displays or actions" in Dynamics 365, "functions" in Oracle EBS, "privileges" in Oracle Cloud, "T-codes" in SAP, etc. The bottom line is that it is not simply the role title; it is the user’s access to the underlying security objects that will drive the SOD conflicts in each ERP application.
To truly manage SOD risk, the organization must be able to identify the permissions of each user at the most granular securable object level.
To illustrate the challenge of object-level analysis, consider the issues raised by using pre-configured roles.
Most ERP applications come with common job assignments pre-configured ("out-of-the-box"), including titles like "Purchasing Department Manager" or "Receivables Inquiry," and it can be tempting for system administrators to save time by simply applying these roles to the appropriate individuals as needed.
Unfortunately, many of these pre-configured role definitions include access permissions to underlying security objects that aren't obvious by simply looking at the role name. Using these out-of-the-box role definitions without first looking at the access privileges they provide often leads to many SOD conflicts. Administrators and business process owners must look at the specific access permissions granted by these role definitions to understand what this role assignment can do.
For example, role definitions with "Inquiry" in the name (such as "Receivables Inquiry" or "Payables Inquiry") seem harmless enough – they should simply permit the user to view, but not edit, add, or delete, the company's receivables or payables. However, in some ERP systems, such out-of-the-box roles will also allow the user to create a manual journal entry or modify vendor information, potentially circumventing any internal controls you have in place to catch this type of activity.
As another example, the role of "Bookkeeper" sounds innocuous enough. However, in some ERPs, this out-of-the-box role can enter an invoice, generate a payment for that invoice, and process the bank reconciliation for that payment.
A guiding rule in designing user roles is the Principle of Least Privilege, which states that users should only be granted the minimum permission to access a system or operation to complete their job functions or tasks. In addition, access should only be granted for the minimum length of time necessary for a person to complete their task. Granting a person more access than necessary could result in user access risk or an SOD violation, exposing the business to the possibility of having critical data accidentally or maliciously altered or deleted, intellectual property stolen, or finances fraudulently taken.
Regardless of the ERP system your company uses, it is best to avoid pre-configured role assignments because they might provide the user with access to change transactional or master data within the application. And simply editing the pre-configured roles might not be enough because software updates often add new responsibilities to these out-of-the-box role definitions, replacing your edits with a new version containing the original conflicts or adding new ones.
The better option is to use the pre-configured role definitions as a starting point, or template, for designing and building your own customized roles.
Out-of-the-box role definitions should only be used in special situations, such as granting a person temporary elevated account access to cover for a person who is out sick or on vacation. Even then, all such temporary assignments should be given an end date when the elevated access will be terminated.
Job roles change as a normal course of business: people are promoted or leave the company and business processes are updated. All too often, the access privileges of these users are not updated, which can lead to increased security risks.
Businesses should hold regular access reviews to ensure users have the appropriate access for their job responsibilities to avoid potential SOD conflicts and regulatory compliance issues.
Access reviews ensure that managers and business process owners review the access of the individuals in their department to the business applications used by the company. Access reviews reveal who has appropriate and inappropriate access and provides a means for organizations to correct any potential security issues early, helping the company avoid incidents of fraud, errors, and misstatements in the future.
Once the user access reviews are completed, the managers and business process owners should certify the access showing that the users are indeed authorized to have the access they have been granted. Automated risk management systems will include tools for conducting regular access reviews and certifications, routing the reviews to the appropriate business process owner, identifying the individuals who require sign-off, and tracking the responses in an auditable report.
Access reviews and certifications, showing the roles that are authorized access to critical areas of the company's applications, the individuals to whom those roles are assigned, and the person who authorized that access, are important for Access Risk Management audits.
Many companies manage their finances and business operations using an ERP application like Microsoft Dynamics 365, Oracle, SAP, or NetSuite, to name just a few. Today, companies are looking at best-of-breed solutions for all aspects of their business. In addition to an ERP, these companies might also use a Customer Relationship Management (CRM) application like Salesforce and a Human Capital Management (HCM) application like Workday. There are also instances where a parent company might run Oracle or SAP while a subsidiary or a new acquisition is running NetSuite or Dynamics GP.
The result is that, for many of these businesses, financial transactions are no longer limited to a single ERP software application. Instead, transactions are taking place in multiple business applications. For example, a company might maintain their supplier or vendor master data in their ERP and send payments to those suppliers in another application, such as Coupa.
Here are just a few of the potential cross-application SOD conflicts that are possible when companies have business processes interact with different business-critical applications:
In each of these examples, a user with permissions to perform each task in both systems creates a potential Separation of Duties risk for the company, even though their permissions in each application, when viewed in isolation, will not indicate an SOD conflict.
Most automated Identity Management and Access Control tools are designed to only check for SOD violations within a particular business application. They will not find SOD conflicts that might exist across interconnected business systems. So, while administrators are able to design user roles and privileges in these business applications individually, there is now a need to look at how these roles interact between the business applications themselves and identify potential SOD conflicts across business applications.
Fastpath Assure is a risk and compliance management platform that helps organizations of all sizes track, review, approve, and mitigate user access and Segregation of Duties (SOD) risks. Fastpath can analyze user access to critical data at a granular level across multiple business applications to help companies identify and mitigate their cross-platform SOD risks. Fastpath's SOD tools come with pre-defined and easily modified rulesets built by Fastpath's team of certified internal auditors.
Fastpath automates Access Reviews and Access Certifications, notifying the necessary parties of the tasks requiring sign-off, following up on incomplete assignments, and generating reports for audit compliance.
Other security tools available from Fastpath include:
Audit Trail – Track user activity, noting changes to critical data and configuration settings, including before and after values, when, and by whom.
Identity Manager – Streamline user setup and provisioning while adding approvals and audit trails into the process.
Security Designer – Create new roles or edit existing ones and identify where conflicts currently exist vs. where they would exist if the proposed changes went into effect. Decide which model best fits your needs with the lowest possible risk level before provisioning.
Risk Quantification – Quantify the financial exposure of Segregation of Duties conflicts in your ERP environment and assign a value to those risks. Delivering this critical information to auditors allows them to focus on the areas with the greatest monetary impact on the organization.
SAP Custom Code Checker – Interrogate the target SAP environment line by line to determine if indirect, unintended access is granted to users.
Transaction Control Monitor (TCM) for Oracle EBS – Identify transactions with potential risk or that exceed acceptable thresholds, allowing management to focus on the areas with the greatest monetary impact on the organization.
Universal Product Integration (UPI) – Fastpath has pre-built integrations to many ERP, CRM, and HCM applications. UPI allows users to extend Fastpath's cross-platform capacity and customize their own integrations to all in-scope applications, giving users the ability to see all their access risks from a single dashboard.
For a customized product demonstration based on your specific needs, please contact us here.
If you're looking for a step-by-step plan to help you get started on an overall risk assessment, and a plan for correction, this paper is for you. Inside you will learn how to begin, and then execute on, developing your own risk assessment plan.
Building A Strong Security Architecture for Oracle ERP Cloud - Protect your company with this Step-by-Step approach. For companies looking to move to Oracle ERP Cloud, it is critical to include a strong application security design aimed to deter fraud, and ensure that transactions performed in the cloud are appropriate and authorized. Whether you're implementing or redesigning your Oracle project, follow this guide to achieve a secure Oracle ERP Cloud system and avoid the common pitfalls in the process.
Building roles and implementing strong security in D365FO can be a daunting task, so we created a tool to assist in designing security roles for Dynamics 365 for Finance and Operations.
Whether you know the importance of access controls or not, implementing and maintaining them can still be a difficult part of your SAP security plan. This eBook reviews what access controls are, how SAP handles them, how you should implement and maintain them, and even suggests some tools to make the process easier on you.
Security. Audit. Compliance. 
© 2021 Fastpath Solutions, LLC. All rights reserved. Privacy Statement | Terms of Use | Personal Data Compliance
