Which of the following would be an example of separation of duties?

The basic principle of separation of duties is that no individual person, role, or group, should be able to execute all parts of a transaction or process. A simple example serves to clarify this principle: a single person should not be judge, jury, and executioner.

In practice, separation of duties is a loss-control measure designed to reduce the risk of accidental or intentional damage to the integrity, confidentiality, and availability of a transaction or process. It serves three primary purposes:

• Reduce the risk of conflict of interest or the appearance of conflict of interest
• Reduce the risk of errors, fraud, abuse, theft, or other wrongful actions.
• Comply with regulatory mandates (e.g., SOX, HIPAA, PCI DSS, GDPR) and industry-specific regulations (e.g., ISO 17799)

A risk-based approach to separation of duties

There is “no one size fits all” plan that organizations can use to ensure separation of duties. Each organization must consider the risks it faces, as well as the compliance mandates it must meet.

Creating a separation of duties plan applicable for your organization requires conducting a risk-assessment, which involves four steps:

1. Conduct data discovery and classification to determine where your sensitive data resides and assess the level of risk to its integrity, confidentiality, and availability.
2. Identify any individual person, role, or group that can:
   • Alter, encrypt, or destroy sensitive data, either accidentally or intentionally.
   • Exfiltrate sensitive data.
   • Influence the design, testing, implementation, and reporting of sensitive data controls.
3. Create a risk map or matrix, based on the results of steps 1 and 2.
4. Implement separation of duties controls, based on the results of step 3. Implementation should use the principle of least privilege necessary to complete a transaction.

What to consider

Although the results of your risk assessment will be unique to your organization, in general, separation of duties controls should ensure that:

• Software developers, contractors, and third-party vendors cannot access production systems, database management systems, or system-level technologies.
• Functional users and system programmers cannot access or modify source or application code.
• End users cannot access or modify production data, except through an appropriate administrative application.
• DBAs do not have root or administrator permissions.
• Only security system analyst can access system logs and system audits, which is monitored on a regular basis.
• Only network security analysts can access firewalls and network security systems, which is monitored on a regular basis.
• Only approved operators can make data backup tapes, with regular monitoring to ensure that appropriate compliance procedures were followed.
• Only a system security administrator can create, update, or delete user accounts, which are independently monitored on a regular basis for excessive, unauthorized, or unused privileges.
• Generic administrator accounts are disabled.

These separation of duties controls create a robust ‘checks and balances’ system that prevents any individual person, role, or group from:

• Giving any user account excessive or unauthorized privileges (e.g., permission to view or change sensitive data).
• Modifying sensitive data residing within production systems.
• Modifying security systems (e.g., disabling audit functions).
• Modifying system logs or audit reports.

Practices to facilitate or enforce separation of duties

The following practices are recommended for facilitating or enforcing separation of duties.

• Install only approved code on production systems.
• Monitor source code repositories for excessive use.
• Create unique VLANS for software developers, contractors, and third-party vendors working on any data-related projects.
• Create two user accounts for Administrators and DBAs—one for routine activities such as email and one for activities requiring privileged user access and permissions.
• Use two-factor authentication for privileged users, to ensure the person is who he or she claims to be.
• Use network access controls to prevent VLANs from accessing production systems.
• Use a write-only logging system administered by a group separate from system and network administrators.
• Use role-based access to logging and audit records, to ensure that administrators can only see records for their networks or systems.
• Use automated tools to manage and audit database access and activities, user rights, and privileged users.

Learn how Imperva solutions can support separation of duties.

Separation of duties (SoD), also known as segregation of duties is the concept of having more than one person required to complete a task. It is an administrative control used by organisations to prevent fraud, sabotage, theft, misuse of information, and other security compromises. In the political realm, it is known as the separation of powers, as can be seen in democracies where the government is separated into three independent branches: a legislature, an executive, and a judiciary.

General description[edit]

Separation of duties is a key concept of internal controls. Increased protection from fraud and errors must be balanced with the increased cost/effort required.

In essence, SoD implements an appropriate level of checks and balances upon the activities of individuals. R. A. Botha and J. H. P. Eloff in the IBM Systems Journal describe SoD as follows.

Separation of duty, as a security principle, has as its primary objective the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users. This principle is demonstrated in the traditional example of separation of duty found in the requirement of two signatures on a cheque.[1]

Actual job titles and organizational structure may vary greatly from one organization to another, depending on the size and nature of the business. Accordingly, rank or hierarchy are less important than the skillset and capabilities of the individuals involved. With the concept of SoD, business critical duties can be categorized into four types of functions: authorization, custody, record keeping, and reconciliation. In a perfect system, no one person should handle more than one type of function.

Principles[edit]

Principally several approaches are optionally viable as partially or entirely different paradigms:

• sequential separation (two signatures principle)
• individual separation (four eyes principle)
• spatial separation (separate action in separate locations)
• factorial separation (several factors contribute to completion)

Auxiliary Patterns[edit]

A person with multiple functional roles has the opportunity to abuse those powers. The pattern to minimize risk is:

1. Start with a function that is indispensable, but potentially subject to abuse.
2. Divide the function into separate steps, each necessary for the function to work or for the power that enables that function to be abused.
3. Assign each step to a different person or organization.

General categories of functions to be separated:

• authorization function
• recording function, e.g. preparing source documents or code or performance reports
• custody of asset whether directly or indirectly, e.g. receiving checks in mail or implementing source code or database changes.
• reconciliation or audit
• splitting one security key in two (more) parts between responsible persons

Primarily the individual separation is addressed as the only selection.

Application in general business and in accounting[edit]

The term SoD is already well known in financial accounting systems. Companies in all sizes understand not to combine roles such as receiving cheques (payment on account) and approving write-offs, depositing cash and reconciling bank statements, approving time cards and have custody of pay cheques, etc. SoD is fairly new to most Information Technology (IT) departments, but a high percentage of Sarbanes-Oxley internal audit issues come from IT.[2]

In information systems, segregation of duties helps reduce the potential damage from the actions of one person. IS or end-user department should be organized in a way to achieve adequate separation of duties. According to ISACA's Segregation of Duties Control matrix,[3] some duties should not be combined into one position. This matrix is not an industry standard, just a general guideline suggesting which positions should be separated and which require compensating controls when combined.

Depending on a company's size, functions and designations may vary. When duties cannot be separated, compensating controls should be in place. Compensating controls are internal controls that are intended to reduce the risk of an existing or potential control weakness. If a single person can carry out and conceal errors and/or irregularities in the course of performing their day-to-day activities, they have been assigned SoD incompatible duties. There are several control mechanisms that can help to enforce the segregation of duties:

1. Audit trails enable IT managers or Auditors to recreate the actual transaction flow from the point of origination to its existence on an updated file. Good audit trails should be enabled to provide information on who initiated the transaction, the time of day and date of entry, the type of entry, what fields of information it contained, and what files it updated.
2. Reconciliation of applications and an independent verification process is ultimately the responsibility of users, which can be used to increase the level of confidence that an application ran successfully.
3. Exception reports are handled at supervisory level, backed up by evidence noting that exceptions are handled properly and in timely fashion. A signature of the person who prepares the report is normally required.
4. Manual or automated system or application transaction logs should be maintained, which record all processed system commands or application transactions.
5. Supervisory review should be performed through observation and inquiry.
6. To compensate mistakes or intentional failures by following a prescribed procedure, independent reviews are recommended. Such reviews can help detect errors and irregularities.

Application in information systems[edit]

The accounting profession has invested significantly in separation of duties because of the understood risks accumulated over hundreds of years of accounting practice.

By contrast, many corporations in the United States found that an unexpectedly high proportion of their Sarbanes-Oxley internal control issues came from IT. Separation of duties is commonly used in large IT organizations so that no single person is in a position to introduce fraudulent or malicious code or data without detection. Role-based access control is frequently used in IT systems where SoD is required. Strict control of software and data changes will require that the same person or organizations performs only one of the following roles:

• Identification of a requirement (or change request); e.g. a business person
• Authorization and approval; e.g. an IT governance board or manager
• Design and development; e.g. a developer
• Review, inspection and approval; e.g. another developer or architect.
• Implementation in production; typically a software change or system administrator.

This is not an exhaustive presentation of the software development life cycle, but a list of critical development functions applicable to separation of duties.

To successfully implement separation of duties in information systems a number of concerns need to be addressed:

• The process used to ensure a person's authorization rights in the system is in line with his role in the organization.
• The authentication method used such as knowledge of a password, possession of an object (key, token) or a biometrical characteristic.
• Circumvention of rights in the system can occur through database administration access, user administration access, tools which provide back-door access or supplier installed user accounts. Specific controls such as a review of an activity log may be required to address this specific concern.

References[edit]

1. ^ R. A. Botha; J. H. P. Eloff (2001). "Separation of Duties for Access Control Enforcement in Workflow Environments". IBM Systems Journal. 40 (3): 666–682. doi:10.1147/sj.403.0666. Archived from the original on December 18, 2001.
2. ^ Alyson Behr; Kevin Coleman (August 3, 2017). "Separation of Duties and IT Security". csoonline.com.
3. ^ "Segregation of Duties Control matrix". ISACA. Archived from the original on 2011-07-03. Retrieved 2022-07-17.

External links[edit]

• Nick Szabo's essay on Separation of Duties at the Wayback Machine (archived March 6, 2016)
• "Segregation/separation of duties definition", ISACA
• "Segregate Duties to Lessen Security Risks", Datamation
• "Transparency, Partitioning, Separation, Rotation and Supervision of Responsibilities", ISM3

What does separation of duties mean quizlet?

Which of the following is the segregation of duties an example of?

Which of the following are duties should be separated from the others?

What is the purpose of separation of duties?