Separation of Duties in Information Technology

John Gregg, Michael Nam, Stephen Northcutt and Mason Pokladnik

Separation of duties is a classic security method 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 be certain that you have
identified all separation of duties issues, you will first need to create an information flow diagram for every function
within each area of the organization. However common sense can help identify a large number of situations where
separation of duties is appropriate. For instance, positions that handle money, valuable items, and new and
attractive items (think iPad after it first came out), require a number of controls. 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 because it often increases head count, 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.[1]
To expand on 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.
Building contractors and their subs do the work, county impartial inspectors evaluate the work to ensure that it
meets the current building code. In fact, in industry there are numerous examples of "doers and inspectors".
Separation of duties in Information Technology
The technology group should understand the basic separation of duties issues within the technology area as well as
the principle of least privilege. 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 responsibility to identify these separation of duties issues. However, following the reasonable
person rule, technology does have the responsibility to bring a separation of duties issue to management attention
when they observe them. The audit function usually has more training and expertise to map business logic to
information flow and suggest where separation of duties makes sense. 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.
Intellectual property is the lifeblood of an Intellectual property is the lifeblood of an Intellectual property is the lifeblood of an Intellectual property is the lifeblood of an
organization and process should be designed to organization and process should be designed to organization and process should be designed to organization and process should be designed to
protect it. Some specic tips: protect it. Some specic tips: protect it. Some specic tips: protect it. Some specic tips:
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.
Source code, or other intellectual property repositories should always have a monitoring counter to detect
excessive use. For instance, SANS might have a courseware repository. Since courses are commonly six days,
but there might also be lab manuals, the counter might be set to ten. When an instructor is preparing to teach a
class, they download the latest version of the courseware for each day. However, if they download more than ten
files from the repository over a certain span of time, an alert might be sent to management or it could even trigger
an account logout.
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 or sometimes referred to as Xceedium. 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 administrators 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. It should be noted that Oracle has made significant progress in the past few years to allow
separation of duties.
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.
Even if IT is the custodian of the information, employee's may be able to access sensitive information. Two
classic examples are contact lists and contracts. If a salesperson is leaving an organization, it is a time honored
tradition to try to leave with the entire customer contact list. Receiving and providing contracts give a clear
picture of the revenue and cost structure of an organization. These should be protected not only with digital
means, but also with physical security protections.
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.
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?
- Is it possible to access the intellectual property off hours or from the Internet? If so, do we rely on single factor
authentication, or do we have multi-factor authentication?
- Do we only focus on the protection of digital information? Even in 2012, a tremendous amount of intellectual
property gets printed; how is it disposed of?
====
1 http://accounting.ucdavis.edu/refs/Departmental_Risk_Assessment.xls