Separation of duties and responsibilities is a type of security control intended to counter insider threats, whether malicious or accidental. It reduces the potential for deliberate misuse of authorized privileges, as well as the risk of accidental misuse or harm to the organization’s assets. Separation of duties and responsibilities targets sensitive tasks, which require special access and capabilities and which could cause serious damage to the organization.
Separation of duties, like all security measures, inhibits productivity and efficiency; applying the concept creates situations that purposefully degrade operational efficiency in return for security.
The classic example is the acquisition process: in the most efficient situation, a manager who wanted to acquire a new asset could find the asset, make payment, and collect the asset. However, to secure the process, most organizations add a step (or multiple steps): the manager who wants the asset creates a purchase order, the purchase order is delivered to the finance office, and the finance officer makes payment to the vendor (in many cases, there are even more offices/personnel involved, depending on the organization, the price of the purchase, and the nature of the asset). While this is inefficient and slows the acquisition process, it allows for additional benefits, such as reduction of asset duplication (the IT department might check the asset inventory before the purchase, determine the organization already owns a similar asset, and can inform the manager that the capability the manager requires already exists so the purchase does not have to be made), operational security (the security office, when reviewing the new asset request as part of the change management process, might notice that the requested asset has critical vulnerabilities and can recommend another vendor with a similar, more secure product), and, most pointedly, fraud prevention (if the manager is allowed to choose the vendor and make the payment without any oversight, the manager is susceptible to inimical motivations, such as bribery/kickbacks, favoritism/nepotism, and personal benefit).
When separation of duties is applied properly, fraud cannot take place without collusion of two or more parties; the manager and the finance officer would have to act in concert to defraud the organization. In forcing collusion, the organization gets the benefit of higher security: there is more likelihood the crime will be detected or reported if there are more people involved.
This means that even in cases where the entire task is actually performed by one person, there is still an additional person/people involved to review, approve, or audit what the first person is doing. This serves as a deterrent to a malicious user and as a second set of eyes to potentially catch accidents that could cause harm.
Here are some examples of how separation of duties can look in practice:
- Employees in the finance department can access a financial application and create and change transaction records, which in turn generate audit logs, but those end users cannot access the audit logs. Inversely, a security administrator who can access the audit logs cannot create or change transactions in the financial application itself.
- A developer who writes code for a software release can’t also be a tester for that same release or be the one who approves or moves that release into the production environment. If a developer put a flaw into that code maliciously, it will be intentionally allowed to pass. If the flaw was introduced accidentally or through ignorance or poor training, there is a chance the developer will miss it again in testing. Involving a second person in the testing process allows the organization the opportunity to catch the mistake or malicious flaw.
- An emergency has arisen, and an administrator needs to access a superuser account to perform a sensitive task that is far above their normal level of permissions. Authentication to that account requires a specific hardware token, which must be obtained from the shift lead at the SOC. The SOC lead verifies with the administrator’s supervisor and/or verifies that there is an outage, incident ticket, or some other valid reason why the superuser token must be used before issuing it, and the token must be returned when the incident is resolved.
While implementing separation of duties, keep a few additional considerations in mind. First, separation of duties must be well documented in policies and procedures.To complement this, mechanisms for enforcing the separation must be implemented to match the policies and procedures, including access-level authorizations for each task and role. Smaller organizations may have difficulty implementing segregation of duties, but the concept should be applied to the extent possible and logistically practical. Finally, remember that in cases where it is difficult to split the performance of a task, consider compensating controls such as audit trails, monitoring, and management supervision.
Another, similar form of process security is dual control. In dual control, two people are required to coordinate the same action to accomplish a specific task. One example familiar from film and television is the military’s procedure for launching a nuclear weapon: two officers must each use their own physical key in a launch mechanism simultaneously. This prevents any one person from launching a missile in an unauthorized manner.
A related concept is two-person integrity, where no single person is allowed access or control over a location or asset at any time. For instance, a data center might have two-person integrity if it cannot be entered unless two employees present their credentials simultaneously.
