http://itmanagement.earthweb.com/columns/article.php/3578216/Segregate-Duties-to-Lessen-Security-Risks.htm

Back to article

Segregate Duties to Lessen Security Risks

By George Spafford
January 18, 2006

The basic intent of segregation of duties (SOD) controls are that no one person should have excessive control over one or more critical processes.

When dealing with access controls for example, a person should not be able to grant himself/herself rights and then perform the action. Similarly, they should not be able to perform a transaction and then delete all the logs that tracked the activity. Instead, processes should be properly reviewed and separated in order to reduce the risks associated with a process being compromised either maliciously or through human error.

Understanding and applying SOD controls are vital to information security.

SOD controls exist both to limit malicious behavior, and to limit accidents caused by human error. This is done through the pragmatic implementation of checks and balances designed to reduce risks to an acceptable level.

For non-critical tasks, you may not need to worry about SOD issues. However, there are some worry about who can take the trash out of the data center and they split the collection role from the disposal role to make sure classified information isn't being leaked.

In many organizations, a great deal of thought has gone into having appropriate SOD for accounting because of the understood risks. Accounting has been identifying risks, and designing and implementing mitigating controls for hundreds of years. In contrast, IT doesn't have remotely the same depth of experience in this area. This is readily evidenced by the number of corporations that found an unexpectedly high proportion of their Sarbanes-Oxley internal control issues coming from IT.

Typical IT shops have evolved over time without formalized controls. As a result, some personnel have excessive access levels. The permissions accumulated as a worker shifted roles or the need-of-the-day was addressed. There always was a push to add access but little prompting to remove access. As a result, the current business needs verses the actual current system profiles are out of synch and critical processes are exposed to risk.

Implementation

One way to verify that SOD controls are properly implemented is to initiate a project solely to rationalize permissions by reviewing job descriptions, actual requirements and then correct the disparities. The following steps highlight what is needed:

Understand the goal, objectives and risks -- First, understand what the goal of the organization is, the objectives of functional areas and what worries management. To properly re-architect roles, you must understand resource needs, risks and where the company is headed;

Collect all existing job descriptions -- What does management think people are doing? See if everyone identified in the organization chart have job descriptions. If not, note the omissions and cases where there are job descriptions but nobody using them;

Compare job descriptions to roles -- What are people doing in reality relative to their formalized job descriptions? What job descriptions do they most closely align with, if any? What are the gaps between the formal definitions and what people actually do?

Review SOD conflict areas -- Develop a grid of functions on one axis and roles on the other. For each intersecting point, review the risks and figure out if that role will grant excessive permission over a given process. If it does, then the SOD conflict should be clearly flagged so people understand where the conflicts are. Alternatively, identify what roles would be in conflict if a person were to have more than one. For example, a developer should not have administrator-level access to a production system;

Revise accordingly -- Based on the SOD assessment findings and talks with management, revise the job descriptions accordingly and/or create new ones. There often will be a lot of give-and-take here as formal and informal roles are identified and either accommodated or changed. With risks in mind, look for areas of unacceptable risks and look for ways to directly and indirectly address SOD issues. If there are SOD issues, look for compensating controls that exist, or can be implemented, to mitigate risks;

Develop system roles that mirror requirements -- Take the job descriptions and define system roles that will enable workers to accomplish their functions;

Review the resulting roles with the team(s) in question -- Make any revisions necessary and review again with the necessary stakeholders;

Review the results with management -- Management must understand and accept any residual risk associated with SOD conflicts. Depending on the level of residual risk they are willing to accept, roles may need to change;

Document and train -- Formal documentation outlining job descriptions needs to be generated and any training required performed;

Pilot -- Depending on the scope of the rationalization, the implementation may need to be done in phases with an initial pilot to make sure the changes will work as planned;

Roll-out -- When ready, the organizational change should be deployed with proper monitoring to make corrections and/or provide support as issues surface. Be prepared for problems to arise and have a process to review and remediate issues as they arise;

Post implementation review (PIR) -- When finished, the project should be formally reviewed for lessons learned.

Segregation of duties issues come up frequently in security reviews and audits. Rather than being viewed as arcane control concepts, SOD controls should be recognized as additional means to help manage risks. Like all controls, there will be limits to what organizations can do. To help address concerns, a review can be undertaken to properly align roles with business needs while properly addressing the risks associated with improper segregation of duties.

Please note that sample SOD assessment templates are available at this site and will be listed next to the entry for this article.