As the pace of digital transformation increases, so does the complexity of an organization’s IT infrastructure. Gartner predicts that by 2025, almost two-thirds (65.9%) of global spending on application software will be directed toward cloud technologies, up from 57.7% in 2022. Moving from on-premises to hybrid and cloud architectures means companies must manage access controls across a diverse ecosystem.
The challenge? Each Software-as-a-Service (SaaS) application incorporates its own security models, while the Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) service providers use different terminologies. As users request access to additional resources, using the built-in dashboards to monitor compliance with internal controls can be overwhelming. To maintain Separation of Duties (SoD) compliance, organizations need a holistic Identity Governance and Administration (IGA) program to manage these access requests and provide an authoritative source of identity definitions.
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 by requiring more than one person to complete a transaction-based task. In the traditional sense, Segregation of Duties refers to separating duties — such as accounts payable from accounts receivable — 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, Segregation of Duties ensures that no one user or role can transact every activity within any business process from start to finish without proper checks and balances. A primary SoD control is managing users’ access rights to digital resources across the organization’s ecosystem.
In the early 2000s, a series of corporate scandals led to the United States Congress passing the Sarbanes-Oxley Act of 2002 (SOX), which required SoD compliance across a variety of information security standards and regulations. The compliance risk associated with SoD violations can lead to monetary penalties and 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 SoD policies that prevent 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 ensures that the person who implements firewall controls cannot approve those changes.
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.
Different applications use different terms for roles, groups, and entitlements. So managing user access often relies on cross-referencing multiple dashboards — manual processes that open the organization to human error risks and SoD violations.
Many vendor-supplied access management tools only allow you to limit access to the resource. However, Enterprise Resource Planning (ERP) applications often embed multiple modules.
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. Or, someone on the APAC sales team shouldn’t have access to customer information of the EMEA sales team. Organizations often struggle to maintain access policies within these larger cloud resources, leading to potential SoD violations.
The cloud adds to the complexity by changing the types of identities you deal with. New non-person identities, such as service accounts, robotic process automations (RPAs), and Internet of Things (IoT) devices can access networks, systems, and software.
For example, RPAs often streamline a business process by automating multiple manual tasks like making payments or approving invoices. Although RPAs may appear to minimize SoD risks, it only mitigates them when Segregation of Duties controls are applied to the account executing the RPA. Additionally, human actors can write the RPA scripts — but if they shouldn’t be accessing the resources the RPA is acting upon, then you need to monitor the RPA’s access to ensure humans aren’t using the RPA to circumvent controls.
As organizations move to the cloud, non-person identities require more privileged access to perform their expected tasks. However, non-person accounts are rarely monitored with the same stringency applied to administrators. This lack of visibility is yet another potential compliance risk.
As your organization seeks to streamline business operations by incorporating new technologies, your users require additional access to resources. This inundation of access requests often becomes burdensome for IT administrators, particularly as they navigate SoD compliance.
As users engage with your digital resources, they often need more access than the “least privilege” controls provide.
For example, both marketing and sales departments may need access to the same databases. Once one employee requests access, others will also want to use the resource. IT admins or managers will often “rubber stamp” these requests to streamline the compliance review process and enable smooth business operations. Unfortunately, this practice increases compliance risk since it lacks the purposeful review that prevents SoD violations.
Even when IT administrators engage in purposeful review, they may need to cross-reference multiple dashboards. They may run into different definitions for users’ roles — or a lack of business-friendly explanations of what kind of access a role delivers. Manually comparing these definitions and entitlements increases the likelihood of human error and subsequent SoD violations.
Often, your IT department or end users will request temporary “emergency” or “firefighter” authorization so they can process a transaction. Since your administrator needs to respond to these requests rapidly, your staff may not have the time to engage in compliance due diligence.
Predictive access analytics with peer- and usage-based data can help streamline the access request/review/certification process. Automation with intelligent analytics can prevent SoD violations by applying context-aware, risk-based controls to the request.
Intelligent analytics also enables organizations to standardize identity and access definitions across the ecosystem, tying all user access to a single, holistic identity. This access visibility surfaces cross-application SoD violations which might be overlooked amidst different dashboards and definitions.
As your organization expands its digital footprint, the principle of “least privilege” must be applied to and within your IaaS, PaaS, and SaaS services. Choosing an automated tool with fine-grained rulesets for individual applications and cross-application checks enables your organization to enforce field-level read/write privileges within these ecosystems, limiting actions that lead to fraud.
Digital transformation changes the way organizations view identity. In the past, using Role-Based Access Controls (RBAC) in static, on-premises infrastructures provided appropriate Segregation of Duties 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.
Automation streamlines the access request/review/certification process by enabling you to create risk-based rules and approval paths.
For example, when a user manually requests access to a server — and an admin manually fulfills it — human errors or SoD violations can occur. With automation, you can create designated approver notifications, delegation rules, SoD rules, and escalations.
Automated tools can also enforce your authoritative identity source with risk-based, context-aware rules. Intelligent analytics can automatically compare access requests to policies and peer access, send potential violation alerts, and suggest remediation to reduce your compliance risk.
As identity analytics continuously monitor for anomalous access requests, automation removes the “rubber-stamping” that can lead to SoD violations. Your IAM policies can be applied automatically across the identity lifecycle, triggering escalations when a request needs to be purposefully examined by a person in the organization.
The ultimate goal of any GRC program is to determine who has access to what — and whether that access is secure and appropriate. But in today’s complex threat landscape, managing access requests and reducing SoD violations can be an overwhelming task.
Wherever your organization is on its digital transformation journey, Saviynt’s cloud-native Enterprise Identity Cloud (EIC) platform provides flexible security solutions for both on-prem and cloud-based deployments. Our GRC solution, Application Access Governance (AAG), can help you establish an authoritative identity source across your ecosystem and deliver a unified, cross-application view into identities, access, and SoD controls.
AAG includes rulesets for a wide range of applications and can build new ones for custom applications. AAG also provides intelligent peer- and usage-based analytics that compares users’ requests to their peers’ access and establishes “least privilege” entitlements to control access to and within your IaaS, PaaS, and SaaS environments.
When new users onboard or move around the business, AAG also helps you streamline provisioning and address risks preventatively. You can easily monitor a library of actionable controls to ensure compliance with SOX, GDPR, HIPAA, and ITGC — all with one-click reporting.