Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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:
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;
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;
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?
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;
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;
descriptions and define system roles that will enable workers to
accomplish their functions;
revisions necessary and review again with the necessary stakeholders;
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;
descriptions needs to be generated and any training required performed;
implementation may need to be done in phases with an initial pilot to
make sure the changes will work as planned;
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;
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.
