Separation of Duties Security: Ensuring Security Supports SoD

What is Separation of Duties Security?

Separation of duties (SoD) is a principle that restricts users from getting more privileges than needed, with the aim of preventing abuse of privileges. For example, employees preparing paychecks should not also have permission to authorize them, because that would create a short circuit where they could overpay themselves and commit fraud.

SoD helps organizations split critical functions between different employees, in order to ensure that no one individual has enough access or information to perform damaging fraud activities.

SoD security is a set of procedures and controls that can enforce separation of duties. Organizations can enforce SoD statically, by identifying conflicting roles and adjusting them. SoD can also be enforced dynamically, by applying controls at the time of access.

Using IT Security Controls to Implement Separation of Duties

SoD is a core tenet of least privilege, which means that individuals should only have access to the information they need to perform their job.

Typically, IT teams use controls to restrict access according to user roles. Each user role can perform certain actions, and typically, roles are devoid of SoD conflicts themselves. One caveat being, certain privileged roles can create or modify other user privileges. Because users typically have multiple roles, SOD conflicts get introduced through interrole conflicts (between roles, rather than within a role). Implementing SoD for all accounts can help avoid conflicts of interests and prevent fraud.

In addition to controlling access within the organizational structure, enforcing SoD within the broader lens of least privilege can also help contain the spread of a cyber attack. If an administrator suspects an account is compromised, they can shut it down to prevent the attack from spreading. If attackers gain access to an account that has unnecessary admin permissions, they can do much more damage.

To prevent attackers from exploiting highly privileged accounts, organizations should limit the amount of admin account, ensure a proper account request and approval process is in place, and consistently monitor 100% of activity in privileged accounts. Implementing SoD for these accounts can help prevent security breaches, data theft, and fraud.

SoD in the Security Organization

SoD assists in assuring that organizations are compliant with financial regulation. Typically, financial leaders are involved in role design for financial applications. Once roles are designed, security and application teams are responsible for ensuring that members of the organization are granted the proper roles, and any SoD conflicts are properly managed.

The role of the security team in SoD is two cater to two main goals:

• Prevent real or apparent conflicts of interest—such as wrongful acts, errors, fraud, and abuse of privileges.
• Detect control failures—including security breaches, data theft, or any circumvention of security controls that might risk compliance with regulations like SOX.

A SoD implementation should prevent individuals from having conflicting responsibilities. Additionally, individuals should not be responsible for reporting on their superiors or themselves, due to inherent conflicts of interest.

Here are several questions that can help you evaluate the maturity of your SoD program. If you answer in the affirmative to any of these questions, your SOD program may need to be enhanced or updated:

• Can an individual modify or destroy financial data without being detected?
• Can an individual steal or exfiltrate sensitive data without approval?
• Can an individual create payments to themselves or others without approval?
• Can an individual influence the design, implementation, or reporting of controls?

Here are a few ways you can ensure SoD for security responsibilities:

• Ask a third party entity to monitor security and conduct surprise security tests and audits. The third party should report to an audit committee or the board of directors.
• The CISO might report to internal auditors, but if the auditors report to the CFO or other executive in charge of finance, this creates a conflict of interest. In these cases the CISO should report directly to the board of directors.
• Information security leadership should report to the audit committee.

6 SoD Security Best Practices

Use the following best practices to ensure that security controls support SoD in your organization:

1. Create an SoD Risk Matrix—make a list of duties, and identify who performs each duty to identify any SoD conflicts. To create an SoD Risk Matrix, you need to understand what each duty means and what are the inherent risks. Consider which task can be easily performed by the same role and which tasks must be separated to ensure security.
2. Use a framework to devise new roles as necessary—sometimes you might need to re-distribute existing duties between members, or hire a new team member to fill a new role. This might require changing your organizational structure, to ensure there are no new SoD conflicts as a result of the changes.
3. Modify your framework as needed—if you cannot accomplish separation of duties due to insufficient manpower, you can add compensating controls. For example, adding a new layer of management review. If you need to test new controls more frequently, or establish monitoring by multiple managers, you should build these changes into the framework.
4. Test all controls to assure they work—controls are a critical component of all information security systems. Control failure may lead to financial and legal repercussions, especially related to SOX compliance, which can harm the company’s reputation. Testing controls frequently and thoroughly can help you ensure they remain effective. If a control fails your test, reexamine the SoD framework and modify it as soon as possible.
5. Document all roles, responsibilities, and controls—SoD definitions can be forgotten over time or lost when new employees replace previous ones. To ensure you retain all important information, you should create detailed documentation of roles within the organization and the risk of ownership each represents.
6. Repeat your risk assessment and remediation as necessary—you should repeat assessment and remediation either periodically, or after significant changes such as mergers or downsizing. Risk management should not be treated as a static process. The initial framework can change as the organization grows. New applications and roles are always being created. To make sure SoD practices grow with the organization, you should regularly reassess risks and controls and change them when needed.

Separation of Duties Security with Pathlock

Pathlock provides a robust, cross-application solution to managing SoD conflicts and violations. Finance, internal controls, audit, and application teams can rest assured that Pathlock is providing complete protection across their enterprise application landscape.

With Pathlock, customers can enjoy a complete solution to SoD management, that can monitor conflicts as well as violations to prevent risk before it happens:

• Integration with the leading business applications, with a “rosetta stone” that can map SoD conflicts and violations across systems
• Intelligent access-based SoD conflict reporting, showing users’ overlapping conflicts across all of their business systems
• Transactional control monitoring, to focus time and attention on SoD violations specifically, applying effort towards the largest concentrations of risk
• Automated, compliant provisioning into business applications, to monitor for SoD conflicts when adding or changing user access
• Streamlined, intelligent User Access Reviews that highlight unnecessary or unused privileges for removal or inspection
• Compliant workflows to drive risk mitigation and contain suspicious users before they inflict harm

Interested to find out more about how Pathlock is changing the future of SoD? Request a demo to explore the leading solution for enforcing compliance and reducing risk.