In a modern organization, segregation of duty (SoD) conflicts fall in the gray area between business accounting and IT security. To illustrate this concept and its impact on both functions, consider the following fictional scenario.

Alice is in a hurry to leave the office. She dips into her company’s sales system and changes the price of Widgets to the new, lower price that management wants. As usual, she gets irritated by the need to switch screens to hit the approval button.

The next day, factory orders for Super Widgets are way up. But sometime late in the afternoon, someone realizes that indicated profit margin is way down. How can that be with the volume they’re seeing?

The company soon realizes they’re selling Super Widgets for the new lower price of Widgets, below the cost of production. Soon, nicer customers are in arbitration and negotiation.

The more heavy-handed ones have sent lawyers to point out the contract language and automated pricing arrangements for EDI and XML orders. The firm has lost millions. What went wrong?

SoD for the executive team is precisely what the meat of Sarbanes-Oxley is all about – the control of data and its proper reporting to management and stockholders.

For IT, SoD means ensuring that a combination of roles and rights within a system do not allow someone more access than was originally intended.

In Alice’s case, someone in IT gave her the right to change prices in the system and gave her the right to approve the change.

The maker of the software meant for these two items to be separate tasks, but in the rush to make things work, she was just given the rights she needed to “get the job done.”

In other scenarios, aggregate rights due to access to two separate systems combine to create the same problem. In some of the more modern systems, there are hundreds or even thousands of roles, jobs, values, transactions and view rights.

Management often does not fully understand the way that systems work together and the resulting lack of a potential audit trail. IT and the business units need to be involved in controlling access, and need a thorough understanding of how systems interact in terms of business functions.

The first step in fixing SoD problems is identifying them.

This requires cooperation between the IT department and each business unit. Application assessment and security definitions help to translate what the system settings are into a form business owners clearly understand.

The next step is to sit down with business owners and determine which combinations pose a risk (input from audit and finance is essential at this point).

There can be dozens of transactions that map to each business activity. The resulting conflicts matrix is often huge.

It is possible to analyze the information in a spreadsheet or custom database, but tools like Approva or Virsa are of enormous help. A word of warning – I have seen a poorly engineered tool actually cause and hide SoD issues.

Once initial assessments have been completed, it is time to start mitigating issues. By now, companies will have found out that even with a few hundred employees, you can have tens of thousands of conflicts. Smart design will help here – in many cases, one slight change to view rights will fix hundreds of problems.

Identifying and mitigating cross-system SoD issues is more complicated. Clear documentation of the business processes as they relate to your application environment is the most important tool at your disposal.

The next step is to bring this information into a single location, so you can compare the rights in one system to the rights and capabilities in the others.

Maintaining logs off-system in areas that are separate from the application servers themselves is very helpful when maintaining audit trails for multi-system architectures.

For the IT side, syslog and SNMP trap solutions can reduce the costs and complexity when doing this.

For the business side, data warehousing and report and data archiving can serve the same functions.

Regardless of the reason you pursue the goal, SoD is something that every information security officer needs to be informed of, and involved in.

Jim Cupps is information security officer at Sappi Fine Paper