This is Flux Capacitor, the company weblog of Fluxicon.
You can find more articles here.

You should follow us on Twitter here.

How To Check Segregation of Duties with ProM 3

The segregation of duties, also called the 4-Eyes-Principle, is one way for organizations to reduce the risk of fraud. For example, it may not be allowed for the same person to initiate a purchase order and pay the invoice for the same item.

Segregation of duties is often controlled via role-based access management in the IT systems. However, there are situations in which after-the-fact verification (based on audit files) is needed.

Here are three examples:

  1. No preventive mechanisms are in place.

    Not every organization employes preventive mechanisms to ensure segregation of duties via IT controls. Sometimes there are simply not enough people to realize segregation of duties via separate roles.

    But auditors still have to prove that the 4-Eyes-Principle was obeyed in the operations.

  2. Changing roles create loopholes.

    Changing roles may create loop holes for bypassing segregation of duty IT controls and create a risk for fraud. For example, a person who initiated a purchase order in role A may over time obtain role B and thus be able to pay the open invoice after the role change.

    Even complex role management tools usually verify the risk of violation at a static point in time (not over time).

  3. Access management may have been circumvented.

    Processes often run across different systems. Increased certainty is needed in today’s climate in addition to preventive controls and beyond sampling.

    By automatically checking 100% of the process log files for violations of segregation of duty constraints, auditors can provide a higher assurance.

In this post, I give you a step-by-step instruction for how to actually check segregation of duty constraints using Nitro and ProM.

1. Determine Segregation of Duty rules

Before you start, you need to know what the segregation of duty rules for your process are. For example, in a Purchase-to-Pay process it is most likely not allowed that the same person issues a purchase order and also approves it.

Here is an example from this ERP vendor blog. The matrix illustrates with an ‘X’ all those two tasks that should be separated. The red marking highlights one of the task combinations that are not allowed:

In the rest of this post, I continue with the call center demo example used earlier. This way, even if you don’t have a log file that you want to check yourself, you can follow the steps using the demo file that comes with Nitro. (Download the free demo version of Nitro here.)

2. Import Audit File

Using Nitro the process log can be imported from a CSV or Excel file. The meaning of the columns is configured in the GUI.

You need to at least configure the following columns:

The other columns are optional. For example, you can configure the columns as shown in the screenshot shown above.

Now, the audit file can be exported in MXML format, which is needed for importing the data in ProM 5.2. (Download ProM here.)

3. Choose 2 Activities

After the import of the converted log file in ProM, start the LTL Checker by choosing ‘Analysis → Raw ExampleLog.mxml.gz (unfiltered) → LTL Checker‘ from the menu.

In the LTL Checker settings screen:

  1. Choose ‘exists_person_doing_task_A_and_B‘ from the list of pre-defined formulas. This is the formula that checks segregation of duties.
  2. Write down the names of the two activities that should not be performed by the same person for the same case.
  3. Click on ‘Check formula

4. View and Export Violations

Now, potential violations are displayed and the details can be exported.

In the screenshot above you see the result for our segregation of duty check with respect to the activities ‘Email Outbound‘ and ‘Call Outbound‘.1

In total, there were 75 cases for which the segregation of duty rule was violated (‘Correct process instances‘ means that the formula could be matched) and 3810 cases were without problem (‘Incorrect process instances‘ means that the formula was not matched — so this is a bit counter-intuitive).

You can also switch between the “Correct” and “Incorrect” set of cases and inspect individual process instances. For example, in the screenshot above the case 3278 is visualized and the found Segregation of duty violation is highlighted.

For further analysis in Excel, you can export the found violations by choosing ‘Exports → Correct instances → CSV for log Exporter‘ from the menu.

Discussion

Do you think checking segregation of duties after-the-fact makes sense? Have you needed it at some point in time? Which tools did you use, and what did you like or dislike about that solution?

Let us know in the comments.


  1. Granted, the example does not make any sense here. This call center process simply does not have any segregation of duty constraints. But I am sure you will have plenty of examples from your own processes.  

Comments (3)

I am a big fan of this kind of testings, over a period, which is transaction-based (logfiles) instead of process-based (like ITIL procedures).

The only thing that is difficult to say is whether there is a correct segregation of duties if nothing was ‘found’ by the log-files. Though using it as a monitoring tool, it might be useful to react quickly upon ‘strange’ actions.

p.s. The 4-eyes principle is a principle which can be used because of a lack of segregation of duties implemented in a system, or as ‘a’ segregation of duties for approval.

I agree. If “nothing has been found” then that does not mean that it cannot happen in the future.

You are right about the difference between the system level and the concept in itself. Thanks for the comment!

[…] years ago, we had shown you already how to check segregation of duties with ProM. With Disco, it has actually been possible to check segregation of duties from the beginning. In […]


Leave a reply