Datamation Logo

Segregate Duties to Lessen Security Risks

Home Trends
thumbnail George Spafford
By George Spafford
January 18, 2006
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:

  • 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.

      SEE ALL
    ARTICLES      
    • Previous Article
    FCC Chair Vows ‘Unfettered’ Internet Access
    Next Article
    The State of CDP

    Subscribe to Data Insider

    Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

    Similar articles

    thumbnail What Is Sentiment Analysis? Essential Guide

    What Is Sentiment Analysis? Essential Guide

    Trends

    11 Top Data Collection Trends Emerging In 2024

    Big Data
    thumbnail 6 Top Data Classification Trends

    6 Top Data Classification Trends

    Big Data
    Datamation Logo

    Datamation is the leading industry resource for B2B data professionals and technology buyers. Datamation's focus is on providing insight into the latest trends and innovation in AI, data security, big data, and more, along with in-depth product recommendations and comparisons. More than 1.7M users gain insight and guidance from Datamation every year.

    Advertisers

    Advertise with TechnologyAdvice on Datamation and our other data and technology-focused platforms.

    Advertise with Us

    Our Brands

    Technologyadvice
    ServerWatch
    TechRepublic
    Enterprise Networking Planet
    eWeek
    Project Management
    eSecurity Planet
    IT Business Edge
    Privacy Policy Terms & Conditions About Contact Advertise California - Do Not Sell My Information

    Property of TechnologyAdvice.
    © 2025 TechnologyAdvice. All Rights Reserved

    Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.