Columnist George Spafford says no one should have excessive control over any critical process. Here's what to do to make sure your company isn't at risk.
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
Understanding and applying SOD controls are vital to information
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
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
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.
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
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
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
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.