Cybersecurity controls and countermeasures often depend on preventing one person from having expansive privileges that allow for the misuse of that system. For example, the person who grants access to sensitive data should not be the same person who requests that access. Or a designer on the marketing team who is given blanket privileges to internal systems that include access to customer data.
The key: to ensure that user access to information is appropriate for a users job role and as limited as possible.
Realizing this goal requires a principle known as separation of duties (SOD) in cybersecurity. Also known as “segregation of duties,” SOD is foundational to establishing a strong security posture. It is also critical for many areas of compliance and sound business practices.
According to the National Institute of Standards (NIST), which publishes the predominant cybersecurity frameworks, SOD refers to "the principle that no user should be given enough privileges to misuse the system on their own.”
Implicit in the principle of SOD is the concept of a cybersecurity control. A control is a mechanism or policy that prevents a cyber threat from succeeding. (There’s more to it than that, but for our purposes, this will suffice). SOD is part of many controls. Each control has a control objective, such as preventing someone from deleting data without permission.
In this case, SOD makes it harder for an unauthorized user to access, alter, or delete data. SOD prevents both internal as well as external abuses. Also implicit in SOD is the practice of breaking down IT management and cybersecurity operations tasks into steps that can be assigned to multiple individuals.
But, internal misuse is not the only risk associated with weak SOD policies. A malicious external actor could also exploit deficient SOD in the IT estate, break into a network, and then elevate his privileges to the point where he could wreak havoc on the environment.
You can find SOD across a variety of sectors, not just in IT and cybersecurity. In the financial industry, for instance, the same person cannot request approval to execute a risky financial transaction and then approve it. Or in healthcare, a doctor writes a prescription, but a pharmacist fills it.
Done right, SOD confers a number of benefits on organizations, including:
Mitigating Insider Threats: Insiders can be attackers. This is an unfortunate reality of life in the corporate world, as well as in government. To mitigate insider threats, SOD often dictates how admins handle approvals to data changes and system access.
Error and Accident Prevention: SOD can prevent errors and accidents that affect security. For example, SOD might allow or compel a system admin to review actions taken by a colleague. This can be useful for major system upgrades or migrations where a mistake can cause an outage or expose a system to cyber risk. Reducing the access footprint can also achieve similar control objectives, limiting user access to systems and reducing the opportunity for error.
Regulatory Compliance: SOD is built into a lot of regulatory frameworks, especially in finance and accounting. For example the Sarbanes Oxley Act (SOX), the US law governing how publicly traded corporations document and audit their accounting controls, requires verifiable SOD for tasks like approval of purchases, valuation of assets, revenue recognition, and preparation of financial statements. All of these limits must also be reflected in controls around user access and audits. An example of the kind of control dedicated by SOX might be that, a procurement system will not allow a user to approve their own requisition for a purchase over a certain budget amount, per SOD rules.
Enhancing Data Integrity and Availability: SOD should enhance data integrity and availability by applying the “Four Eyes Principle,” which requires at least two people to review certain mission-critical or sensitive actions.
Challenges can arise in the implementation of SOD, some of which have to do with the disconnect between the principle of SOD and the ability of certain solutions to realize it. An accounting system, for example, may allow admins to set up workflows that lack SOD controls, even if such controls are required for compliance.
A bigger problem is simply the manual nature of mapping SOD rules to users and roles, and then implementing them. As people come and go, and workflows evolve, it is easy for SOD to become deficient. And there is the simple issue of laziness. If a manager shares his password with employees because he doesn’t want to be bothered every time someone needs a system override, SOD falls apart.
These difficulties can become more severe when it comes to cloud-based data management. In an enterprise cloud or multi-cloud data management scenario, the work of mapping SOD controls to roles and permissions can be more complex and challenging than it is with traditional on-premises systems.
A collection of best practices makes it possible to succeed with SOD. Regular audits and role updates are essential in this regard. It’s imperative to stay on top of what’s happening with controls and workflows that require SOD—and be aware of situations where SOD has stopped working. Specialized auditing tools make this feasible. It would be difficult to monitor controls that span multiple systems and user roles. Data monitoring can be part of this practice. Knowing where sensitive data resides goes together with figuring out who can access it and whether SOD controls need to be in place to protect it.
It is also a best practice to establish clear role definitions. This is partly an organizational issue, one that touches on policy not technology. The better the thinking and planning that go into the process, the better the SOD outcomes will be. Rubrik, for example, supports this process with user access control and reporting.
Education and training matter too. SOD is about people and organizations, so it pays to make people aware of how the principle works. Indeed, most employees are probably not familiar with the concept. If they understand that a single person cannot approve all permissions, for example, that will help make SOD a success.
The principle of separation of duties is foundational to many critical cybersecurity controls and countermeasures. Access controls, network security, and data security, to name three major workloads, will be deficient if one person can self-assign multiple privileges to himself. Four eyes are almost always better than two.
Getting to SOD requires best practices and the right tools. Solutions for SOD include purpose-built software that tracks roles and duties, but solutions for data management, access control, and other aspects of security also need to be part of the process. Monitoring and auditing are also essential. As these elements come together, it becomes possible to realize the principle of SOD throughout the IT ecosystem.
SOD is a system of controls that prevents users from getting privileges that would enable them to misuse the system on their own, e.g., by allowing a user to escalate his or her access privileges.
Correctly implemented, SOD reduces the risk of data breaches and other risks caused by unauthorized access and unauthorized privileges to execute system tasks, e.g., setting up user accounts
Implementing SOD starts with clear policy definitions that establish each duty, and who is authorized to perform it. From there, SOD implementation involves the enforcement of policies through supporting systems, including solutions for identity and access management (IAM) and privileged access management (PAM), along with the applications they protect.