Security Laboratory
Separation of Duties in Information Technology
February 18th, 2008
By John Gregg, Michael Nam, Stephen Northcutt and Mason Pokladnik
Separation of duties is a classic security principle to manage conflict of interest, the appearance of conflict of interest, and fraud. It restricts the amount of power held by any one individual. It puts a barrier in place to prevent fraud that may be perpetrated by one individual. Fraud will still occur if there is collusion. To properly identify separation of duties issues, you will first need to create an information flow diagram for every function within each area of the organization. Although there are a number of similar controls among organizations, specific controls are relatively different between industries. There is no complete matrix that may be applied to all organizations. separation of duties within each company is unique. Since separation of duties equates to additional cost, a risk assessment should first be performed to determine whether it is necessary, or whether compensating controls are adequate. As you are aware, management may decide to accept, reject, or divert the risk instead of controlling the risk through separation of duties. It is a balance between the cost and the amount of risk being considered and addressed. Once this is decided, management may determine where separation of duties will be applied.
Note: John Gregg from UC Davis, developed a self assessment for determining risk related to separation of duties, it is available here.
Positions concerning money: in general, one person should indicate the action related to money inflow or outflow, another verifies that action has happened or causes the action to happen. It is very common for accounting divisions to have this separation. Examples:
-
A salesperson may take orders, but someone else marks the order paid. The fulfillment department ships the product. The accounts receivable clerk matches the customer order to the shipment sent before charging the customer. A purchasing agent may have the authority to bind the company to purchase orders up to a specific amount. Their supervisor should be required to approve purchase order over that amount. After the product is received, the accounts payable clerk matches the purchase order, bill of lading, and invoice before payment is made.
-
Internal and External Auditors perform similar functions. To have External Audit review the internal controls and financial statements of a company is not a separation of duties issues. External Audit is an independent party that reviews the work of Internal Audit, internal controls, and financial records of the company. External Audit's assessment is for the general shareholders, while the Internal Audit's assessment is primarily for management and the board of directors.
The Technology group should understand the basic separation of duties issues within the Technology area. However, Technology does not normally have the expertise to determine the separation of duties issues within the business. Although conflicting access rights may be a cause for concern, it is not Technology's position to identify these separation of duties issues. Having stated such, Technology does have the responsibility to bring a separation of duties issue identified to management attention. Ultimately, it is business management's responsibility to adequately address separation of duties issues. For daily operational purposes, Compliance may be sought to review user access rights to address separation of duties concerns. Internal Audit would review user access during audits for separation of duties issues. Note that Internal Audit would not do it on a daily operational basis as it would become a separation of duties issues for Internal Audit. Where Internal Audit performs this function, Internal Audit will not have the appearance of being objective during their audit.
Positions involving data. Intellectual property is the lifeblood of an organization and process should be designed to protect it.
- Software developers should never have access to production systems. Production systems should not have compilers installed. A configuration management board or equivalent should be involved in the decision to place code that has been developed into a production environment. No code should ever be installed in a production environment that has not been approved. As a general principle development and production should always be separate with no crossover (at a minimum, the root/administrator password on development systems should not work on production systems. Better practice is not to allow developer accounts on production systems and to use network access control so that developer VLANS cannot access production systems other than office automation production systems so they can read their email.) Developers may be granted access to production for emergency changes using pre-established accounts for this purpose at the time of need. Controls need to be implemented to administer distribution. Emergency change procedures should only be initiated for operational problems occurring at night where a process must be completed and developer intervention is required. Additional controls will need to be implemented to ensure that changes are tested and approved properly. This problem is not unique to software development. Change control can be applied to many operational aspects of IT as well, such as having a manger approve firewall rule changes before they are applied.
-
Backups are important and we want to encourage backups, but not everyone that has administrator or super user privilege should be allowed to create backups since this gives them a copy of all of the intellectual property. Approved backup operators should be identified in writing with the appropriate procedures. In general, it is far safer to use disk replication to an alternate site. Backups made to small tapes that easily fit in a pocket or briefcase are the highest risk. Backup tapes may need to be produced for regulatory compliance and should be protected in a manner consistent with the sensitivity of the information.
-
Outsourced maintenance personnel should be restricted to the systems they are working on. This can be done by creating a unique VLAN, or DMZ, or using tools like Exceedium. All contractors should have contracts that meet the company's privacy requirements, including non-disclosure agreements. A vendor management policy and privacy policy should be implemented and enforced. Privacy Policy needs to address the data classification of intellectual property.
-
Network and Security administrators have the ability to see anything that is sent across the network. Only authorized sniffers may be used. Only authorized signature sets may be used. When possible, portable sniffers should not be used; use investigation enterprise level devices with a console. Only with written permission should the sniffer be a piece of software on the network administrator’s laptop; it is highly recommended to have a corporate device stored appropriately and checked out for use as needed.
-
Database administrators are the hardest position to control. If you want the database to work, all tables probably have to join. DBAs should only have DBA authority, not root or administrator. It may be possible to encrypt the content of some sensitive fields in the database. Consider tools that manage and audit database access, such as Imperva. All activity for accounts with elevated privileges should be logged and reviewed daily by an independent party.
-
To enforce accountability, generic administrative accounts should be disabled - and an alert issued if they are used - since generic accounts can be used to bypass role-based access controls. In addition, the principal of least privilege suggests that each Administrator and DBA should have two accounts, one with elevated rights and one with normal user rights. The normal account should be used to perform mundane functions such as checking email, while the account with elevated rights should only be used to perform tasks requiring administrator\\super user level access. If a process is particularly sensitive, two factor authentication may be used to further ensure that the person performing the task is the person authorized to do so.
-
Logging for systems, network equipment, databases, etc., should be directed to a write-only logging system. The logging system should be administered by a group separate from the people responsible for network and systems administration, and access to the logging system should be role-based so that administrators may only see the logs for their own systems.
The rich questions to ask are:
- Can one person destroy or encrypt all (or a significant amount) of the intellectual property
- Can one person steal or exfiltrate a significant amount of the intellectual property
Positions involving management duties can create conflict of interest or the appearance of same. The CIO or other officer responsible for roll out should not have signature authority over security or compliance workers or tasks.
====
1. http://accounting.ucdavis.edu/refs/Departmental_Risk_Assessment.xls