Separation of Duties

Separation of duties means that a process within an organization is segregated into smaller pieces that are then given to individuals or small groups of individuals. The goal is to protect the information and the process by ensuring that no single group or individual has control of the entire process from start to finish. Information within these processes is then protected from complete loss because no single person knows everything within the process.

This separation allows the workers within each part of the process to become subject matter experts (SMEs) at their jobs. For example, developers are specifically responsible for the creation and maintenance of software applications within an organization. They do not administer the computer systems that the applications run on nor do they control the security on those boxes. Conflicts of interest often arise within organizations trying to fill multiple job positions with a single person.

However, there are also system administrators that are responsible for the security of the computer systems they manage. But when considered from an objective point of view, the primary responsibility of any system administrator is to ensure the system works and is available, without hindrance, to every user. This is in direct contrast to security work, which may sometimes require a degree of degradation in service to ensure proper protection of information assets.

This section considers the separation of duties as it pertains directly to the development process. Some of the key points to remember here are:

• Developers should not conduct official testing on their own products.

• Security administrators should not perform official audits of their own systems.

• Individuals need an objective third party to check their work.

Exam Warning 

The concepts of "separation of duties" and "least privilege" are different, although they are sometimes confused because of their similarities. During the test, keep in mind that least privilege is specifically dealing with limiting user access to the system to ONLY that access required to accomplish their job. Separation of duties, on the other hand, deals with segmenting operations into smaller jobs and letting no single individual gain too much control or access to the processes or the information within the processes.

Control Mechanisms and Policies

Certain policies and mechanisms are put into place to protect the vital assets of an organization. Protection of the operational systems and the critical information transmitted, processed, and stored there is the goal.

When a development project is near completion, a full code review should take place to identify problem errors within the code. The reviewer should look for things like logic problems such as algorithms that perform unforeseen functions along with their intended functions. Poor memory management within the program can cause functional issues or possibly allow the buffer to be altered. The code review process is intended to identify these problems prior to the product being put into an operational environment where it could endanger the entire system.

The reviewing team should be an objective third party that has no vested interest in the code, other than to ensure it functions correctly and operates securely. The development staff that created the code should not perform the code review. Programming has a tendency to create tunnel vision within a developer's mind. They see the code as they intended it to work, not as a body of code that could be doing other things they never intended.

The development staff should also not be the same team supporting the production system and its associated data. Test environments are normally used to create new products and test their performance. Changes, when necessary, are also done in the test environment to ensure that no unnecessary impact to the production system occurs. Remember, the goal here is to keep the production systems as stable as possible while changes are created and tested in a safe environment. A separate operations team controls the production systems and while a developer may have recommendations or advice for that team, they should have no direct control or administrative privilege on the production systems.

Along with the safe testing and changing of software comes the need to test on realistic databases of information. These test databases should not be comprised of real world customer data. Production database systems should not be used for the development and testing of new products or new versions of products. Realistic databases can be created that emulate the true production database but do not put the sensitivity and security of real customer data in danger.

Developers also should not manipulate or manage the data in a production database. Production data is the lifeblood of the organization. Errors can be introduced by individuals, even inadvertently. Only the users directed by the organization to utilize that information in the performance of their job duties should be allowed to manipulate or use the information. And because customer data is so sensitive, only those users needing access to the data to provide a service to the customer or to accomplish the mission will be allowed to access the data. But even those authorized to access the data should be monitored. Auditing creates an audit trail showing user sign-in, user sign-out, and actions on the system that could impact the production data. Administrators should use the audit trails to ensure all actions on the system are authorized and that the integrity, availability, and confidentiality of data on the system is maintained.

Development Staff Should Not Conduct Evaluation or Testing

During any security testing of systems and applications, it is important to understand that the team running the system or responsible for the development of the application in question should not conduct the official testing themselves. An objective third party should be brought in to evaluate the security of the system in question. Since the team that runs the system or developed the application is responsible for potential flaws, a direct conflict of interest arises if they are the individuals evaluating the system. During the development process some testing will take place by the developers as a result of the normal development process. But when it is time for the final acceptance testing, a non-partial party should be brought in.

Security Administrators Should Not Perform Audit Tasks

It is important to note that in-house security administrators should not be responsible for conducting security evaluations on their company's systems or resources. Since in-house security administrators are often responsible for the security at the organization, a conflict of interest occurs when they evaluate their own work. Third party evaluations ensure that an objective review is given. Even security administrators with the organizations best interest in mind would tend towards a bias when it comes to their own work at the organization. Assessments conducted by third parties will hold more credibility.

Individuals Should Not Be Responsible for Approving Their Own Work

The idea here is to avoid a situation where employees are approving their own work. Developers do not approve the security of their own applications. Security administrators do not approve the security of the organization's resources when they are responsible for implementing protective measures. Third-party evaluations of all systems and applications within an organization can provide a more detailed and objective look at the actual security that exists.