Understanding SoD in Modern Enterprises: Same App, Cross-App & Service Account

 

Segregation of Duties (SoD) in IAM and Saviynt EIC

Segregation of Duties (SoD) — also known as Separation of Duties — is a key security principle used to reduce the risk of fraud, errors, or misuse by making sure no single person has control over all parts of a sensitive task or transaction.

SoD Within the Same Application

This is the most common SoD scenario. It ensures that within a single application, users don’t get access to perform conflicting actions that could lead to fraud.

Real-Time Example in SAP:

A user named Vikram works in the Finance department.

Current Roles:

• Role A: Create Vendor Master Data
• Role B: Process Vendor Payments

SoD Violation:

This is a classic intra-application SoD violation:

Vikram can create a fake vendor and then initiate payment to that vendor, all within SAP.

There is no oversight or second pair of eyes — a clear fraud risk.

How Saviynt Handles It:

Create SoD Rule in Saviynt:

Rule Name: Create Vendor and Process Payments

Application: SAP ECC

Entitlement A: Role with XK01

Entitlement B: Role with F110

Risk Level: Critical

SoD Analysis in Identity Repository:

Saviynt scans current access:

• Finds Vikram with both entitlements.
• Displays violation under Access Risk Details.

During Access Request Workflow:

• If Vikram requests Role B while already having Role A, Saviynt:

Violation Remediation:

• Remove one of the conflicting roles
• Grant temporary access using Firefighter ID (Privileged Access Management)
• Add a monitoring alert or require supervisor review

Key Concepts:

• Role-Based Access Control (RBAC): Roles are used to group permissions, and SoD rules define what role combinations are risky.
• Granular Permissions: SoD works best when permissions are clearly defined and separated.

SoD Across Different Applications (Cross-Application)

SoD across applications refers to identifying and preventing conflicting access when a user has roles or entitlements in more than one system that, when combined, pose a security or compliance risk.

Most organizations use multiple systems like SAP, Oracle EBS, Salesforce, ServiceNow, etc. Users often get roles in these apps that seem fine in isolation, but together they create a toxic combination.

Why is This Important?

Without cross-application SoD:

• Users might exploit access in one app to commit fraud in another
• Internal audits and compliance (SOX, GDPR) may fail
• Risk visibility is fragmented across siloed systems

Saviynt shines here because it supports cross-application SoD policies, pulling entitlement data across systems to detect toxic combinations.

Real-Time Example: SoD Violation Across SAP and ServiceNow

Scenario:

Let’s say you have a user named Anita who works in Finance.

Access Anita has:

In SAP, she has: Role A: Create Vendor Master Data (Tcode XK01: Add new vendor details)

In ServiceNow, she has: Role B: Approve Vendor Onboarding Tickets(Entitlement: sn_vndr.approver)

SoD Risk:

This is a toxic combination. Anita can: Create fake vendors in SAP & Approve her own vendor requests in ServiceNow

Even though the systems are different, the business function is the same, and it breaks the SoD principle of "no self-approval."

How Saviynt Handles This

Cross-Application SoD Rule Setup:

In Saviynt, you define a rule.

Rule Name: Create and Approve Vendor

App A: SAP → Entitlement: Create Vendor

App B: ServiceNow → Entitlement: Approve Vendor Ticket

Violation Type: High

SoD Risk Analysis:

Saviynt scans identities, finds Anita with both entitlements, and flags her in Access Risk Dashboard.

During Access Request:

If Anita requests either access:

• Saviynt checks SoD policies across both apps.
• Raises an SoD violation warning.
• Routes to approvers with risk justification options.

Remediation Options:

• Remove one of the roles
• Add a compensating control (e.g., monthly audit)
• Assign access via firefighter ID with logging

Why is this matter:

• Business processes often span across multiple apps.
• SoD must look at the full picture across systems, not just one app at a time.

SoD in Service Accounts

Service accounts are non-human accounts used by applications or systems to run automated tasks. These accounts often have high privileges and are easy to overlook, making them a serious security risk if not managed properly.

Real-Time Example in Saviynt:

Scenario:

You are managing an SAP system using Saviynt, and there is a service account svc_batch used for running background jobs.

Risky Access Detected:

Saviynt detects that svc_batch has both:

1. SAP Role A – Can create purchase orders (Tcode: ME21N)
2. SAP Role B – Can approve purchase orders (Tcode: ME28)

SoD Violation:

These two roles combined violate a critical SoD rule:

Create and Approve Purchase Orders should not be performed by the same identity — whether human or service account.

If an attacker compromises svc_batch, they can create fake purchase orders and approve them — a classic fraud scenario.

What Saviynt Does:

Risk Detection: Saviynt uses its SoD rules engine to flag this combination as a violation.

Policy Enforcement: The service account may be blocked from receiving Role B.

Approval Workflow: A SoD exception request may be raised, requiring compensating controls or justification from an approver (like the risk manager).

Risk Remediation: Admin can reassign the roles, use break-glass access, or implement firefighter ID controls.