Managing Access Requests and Segregation of Duties Compliance
What does Segregation of Duties (SOD) mean?Segregation of duties (SOD), also called separation of duties, refers to a set of preventive internal controls in a company’s compliance policy that mitigates the risk of error and fraud in accounting and financial statements by requiring more than one person to complete a transaction-based task. In the traditional sense, SOD refers to separating duties such as accounts payable from accounts receivable tasks to limit embezzlement. For example, a user who can create a vendor account in a payment system should not be able to pay that vendor to eliminate the risk of fraudulent vendor accounts. In modern IT infrastructures, managing users’ access rights to digital resources across the organization’s ecosystem becomes a primary SOD control.
What is Segregation of Duties (SOD) compliance risk?In the early 2000s, a series of corporate scandals led to the United States Congress passing the Sarbanes-Oxley Act of 2002 (SOX). The legislation’s SOD compliance requirement has since been incorporated across a variety of information security standards and regulations. The compliance risk associated with SOD violations can lead to monetary penalties as well as audit findings. As information systems have become intertwined with financial reporting practices, business data security audits increasingly focus on access controls that limit users to “least privilege” and set SOD policies that prevent users from potential conflicts of interest. For example, the IT Administrator who can add and edit system access permissions should not be allowed to access financial systems. Another IT SOD control is ensuring that the person who implements firewall controls cannot approve those changes.
What are the difficulties with maintaining SOD in a cloud infrastructure?Cloud infrastructures create complex, interconnected digital ecosystems that often lack visibility. With disparate definitions of roles, groups, and identities from one application or cloud service provider to another, managing SOD compliance becomes difficult.
Disparate Identity DefinitionsWith different applications using different terms for roles, groups, and entitlements, managing user access often relies on cross-referencing multiple dashboards. The manual processes leave the organization open to human error risk that can lead to SOD compliance violations.
Lack of Fine-Grained EntitlementsMany vendor-supplied access management tools only allow you to limit access to the resource. However, Enterprise Resource Planning (ERP) applications often have multiple modules embedded within them. For example, SAP incorporates modules for both Marketing and Sales. While the sales team may need sensitive customer information such as bank accounts, the marketing team does not. Moreover, someone on the APAC sales team shouldn’t have access to customer information of the EMEA sales team. Organizations often struggle to maintain implemented access policies within these larger cloud resources, leading to potential SOD violations.
Lack of Managing Non-Person IdentitiesThe cloud changes the types of identities you deal with. New non-person identities, such as service accounts, robotic process automation (RPA), and Internet of Things (IoT) devices, access networks, systems, and software. For example, RPAs often streamline a business process by automating multiple manual tasks such as making payments or approving invoices. Although RPA may appear to minimize SOD compliance risks, it only mitigates them when SOD controls are applied to the account executing the RPA. Additionally, human actors create the RPA scripts, and this can create a SOD violation. If the human should not be accessing the resources the RPA is acting upon, then you need to monitor the RPA’s access to ensure the human writing the scripts isn’t using the RPA to circumvent controls.
Inability to Monitor Privileged AccessAs organizations move to the cloud, non-person identities increasingly require privileged access in order to perform their expected tasks. However, non-person accounts are rarely monitored with the same stringency applied to administrators. This lack of visibility into the activities of non-person accounts makes them a potential compliance risk.
Why does the access request process increase compliance risk?As your organization seeks to streamline business operations by incorporating new technologies, your users require additional access to resources. The inundation of access requests often becomes burdensome for IT administrators, particularly as they navigate SOD compliance.
Request/Review/Certify ProcessAs users engage with your digital resources, they often find that they need more access than the “least privilege” controls provide. For example, as your marketing and sales departments work together, both sets of users may need access to the same databases. Once one employee requests access, others will also want to use the resource. Your IT administrators need to review each request individually to ensure SOD compliance. Often, to streamline the review process, administrators or managers will “rubber stamp” the request and provide any access that enables business operations. Unfortunately, this increases compliance risk since it lacks the necessary purposeful review that prevents SOD violations.
Lack of Consistent Identity DefinitionsEven when IT administrators engage in purposeful review, the multiple dashboards that need to be cross-referenced may have different definitions for users’ roles, or a lack of business-friendly explanation of what access a role delivers. Comparing these definitions and entitlement manually increases the likelihood of SOD violations because the manual process leads to human error risk.
Provisioning Emergency Access RequestsOften, your IT department or end-users will request “emergency” temporary authorization so they can process a transaction. Since your administrator needs to respond to these requests rapidly, they increase your compliance risk since your staff may not have the time to engage in the appropriate due diligence.
How intelligent analytics can prevent SOD violations during the access request processPredictive access analytics using peer- and usage-based data can help streamline the access request/review/certification process by automating the SOD controls. Automation with intelligent analytics can prevent SOD violations by applying context-aware, risk-based controls to the request.
Identity ReconciliationIntelligent analytics enable organizations to standardize identity and access definitions across the ecosystem to tie all user access to a single, holistic identity. This access visibility surfaces cross-application SOD violations which could otherwise be missed due to different dashboards and definitions.
Fine-Grained Access ControlsAs your organization expands its digital footprint, you need to ensure that you follow the principle of “least privilege” both to and within your IaaS, PaaS, and SaaS services. Choosing an automated tool that enables you to enforce field-level read/write privileges within these environments and ecosystems allows you to mitigate access risk by limiting actions that lead to fraud.
Context-Aware ReviewsDigital transformation changes the way organizations view identity. In static, on-premises infrastructures, using Role-Based Access Controls (RBAC) provided appropriate SOD controls. However, the proliferation of identities and locations across on-premises, hybrid, and cloud-based architectures require context and risk-aware Attribute-Based Access Controls (ABAC). Peer- and usage-based analytics enable organizations to create more robust policies that better prevent SOD violations.
User Access RequestsAutomation streamlines the access request/review/certification process by enabling you to create risk-based rules and approval paths. For example, when the process to gain access to a server is a user manually requests access and a server administrator manually fulfills it, it can lead to human errors or SOD violations depending on the visibility and the resources stored on the server. With automation, you can create designated approver notifications, delegation rules, SOD rules, and escalations.
EnforcementUsing your authoritative identity source, you can establish risk-based, context-aware rules that the automated tools can enforce. Intelligent analytics can automatically compare access requests to policies and peer access, then send potential-violation alerts. The analytics also enable the tool to suggest remediation actions which then allow you to reduce compliance risk.
Documentation for AuditSince identity analytics continuously monitor for anomalous access requests, the automated tool removes the “rubber-stamping” that can lead to SOD violations. Automation applies your IAM policies across the identity lifecycle to create risk-aware escalations when a request mandates further review, requiring someone in the organization to purposefully examine the request.