Part 1: Why managing SoD is such a BIG deal

Part 1: Why managing SoD is such a BIG deal

Over the coming weeks, we will be publishing a new series of 10 articles covering a number of security and access control related topics for Oracle E-Business Suite. If you to get access to these articles before anyone else, please subscribe to our newsletter.


You’ve probably read about or heard the term Segregation of Duties (SoD) or perhaps Separation of Duties. Given you are reading this then you probably know what it means, but do you know why managing SoD is such a big deal? In this article we will briefly talk about why SoD can be so tricky to manage.

First a quick refresher on what SoD is…

Simply put, SoD is the concept of having more than one person perform tasks within a given business process with the ultimate goal of SoD being to help reduce risk related to fraud or inaccurate data.

Example SoD risk

We will begin with a simple example of where SoD would likely be needed…

Within your Oracle EBS system, you have the ability to create a new supplier, you also have the ability to create a new invoice related to this supplier. Consider for a moment if one person has the ability to perform both tasks, they could potentially create a fictitious supplier and then create an invoice for this supplier who would eventually receive payment.

Ideally then, you would not want one person to be able to both create suppliers and invoices. A key component of managing SoD is the ability to identify risks of this type within the system.

No big deal, right?

In your company you have 10 staff with access to Oracle EBS; you are looking for a single “risk” where one person can create both suppliers and invoices; easy, right?

Yes, it is easy at this point for sure.

You’d take a quick look at what each of the 10 staff can do within Oracle EBS and check to see if any one of them can perform both tasks; where you find a match, either remediate the risk or else mitigate it in some other way.

No problem, what’s the big deal?

It really is a BIG deal

In the example above we were only considering a single SoD risk; now imagine you have lots of potential risks that need to be checked; based on the current risk matrix (rulesets courtesy of our implementation partner, ERP Risk Advisors) that we have available in our SoD solution CS*Comply, you now have 38,250 potential risks (rules) to consider; now imagine checking each of the 10 users with all 38,250 rules; still possible to do manually I guess but extremely labor-intensive and error prone for sure.

One of the biggest issues you face when trying to manage SoD is volume; by volume I mean data volume. Of course, in the example above SoD is easy because the numbers are so small (1 risk/rule and 10 users) but what about when the numbers begin to grow; even in a relatively modest sized organization, the numbers grow very rapidly to the point where managing SoD becomes impossible without the help of some sort of software automation.

Real-World Example

Let us now work through a more real-world example for a medium sized organization.

Our example organization is a national manufacturing organization; the makeup of their Oracle EBS environment is as follows…

850 users (excluding self-service)
250 roles and responsibilities
• Average of 7 responsibilities per user
• Average of 50 menu entries/functions/concurrent programs per responsibility

If we multiply the number of users by the average number of responsibilities by the average number of functions per responsibility, then this means there are potentially 297,500 individual access points in the system.

If we have a single SoD rule then we need to look at all 297,500 access points to check if any of them violate the SoD rule; this is bad enough but now consider that we actually have 38,250 rules to evaluate.

An Impossible Problem (to deal with manually)

So, if we multiply 297,500 by 38,250, this means the theoretical number of tests that must be performed to seek out the SoD (and single function) risks is…

11,379,375,000

Yes, you read it right, that’s over 11 billion!!

In fact, for some of our customers, the number of theoretical tests that would need to be performed runs into the 100’s of billions and even trillions in some cases.

So how would you approach that if you were told to manually figure out where the SoD risks are in your system; the answer is you wouldn’t because it is impossible without the help of some sort of software automation.

This is one of the reasons why managing SoD really is such a BIG deal.

Want to find out how we can help you manage SoD and perform those 11 billion tests for you in seconds? Get in touch today and ask us about CS*Comply.

Early Access – Newsletter

The next article in this series is “Why do we need a tool to help manage access related risk?“.

If you want to get access to these articles before anyone else, please subscribe to our newsletter.

Did you like this article? Follow us to receive all our blog updates

Subscribe to our newsletter
CaoSys
info@caosys.com
No Comments

Post A Comment

Call
Email

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.