The Official (ISC)2 SSCP CBK Reference. Mike Wills
Чтение книги онлайн.
Читать онлайн книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills страница 28
Separation of Duties
Separation of duties is intrinsically tied to accountability. By breaking important business processes into separate sequences of tasks and assigning these separate sequences to different people, applications, servers or devices, you effectively isolate these information workers with accountability boundaries. It also prevents any one person (or application) from having end-to-end responsibility and control over a sequence of high-risk or highly vulnerable tasks or processes. This is easiest to see in a small, cash-intensive business such as a catering truck or small restaurant.
The individual server takes orders, serves the food, and hands the bill to the patron, who pays either the server or the cashier; the cash collected goes into the cash drawer, which is also where any change due the patron is taken from.
The cash register or change drawer is set up and counted by a shift lead or manager and counted again at intervals throughout the shift and at shift change.
The daily accounting of cash at start, bills to patrons and receipts paid, and cash drawer tallies is reconciled by the accounting manager.
The accounting manager prepares the daily cash deposit, which is verified by the overall manager.
The deposit is counted by the bank and verified to match what is claimed on the deposit slip.
This system protects each worker from errors (deliberate or accidental) made by other workers in this cash flow system. It isolates the error-prone (and tempting!) cash stream from other business transactions, such as accounts payable for inventory, utilities, or payroll. With the bank's knowledge of its customer, it may also offer reasonable assurances that this business is not involved in money laundering activities (although this is never foolproof with cash businesses). Thus, separation of duties separates hazards or risks from each other; to the best degree possible it precludes any one person, application, system, or server (and thereby the designers, builders, and operators of those systems) from having both responsibility and control over too many hazardous steps in sequence, let alone end to end.
Other examples demonstrate 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 just 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 personnel are required to coordinate the same action from separate workstations (which may be a few feet or miles apart) to accomplish a specific task. This is not something reserved to the military's release of nuclear weapons; it is inherent in most cash-handling situations and is a vital part of decisions made by risk management boards, loan approval boards, and many other high-risk or safety-critical situations.
A related concept is two-person integrity, where no single person is allowed access or control over a location or asset at any time. Entry into restricted areas, such as data centers or network and communications facilities, might be best secured by dual control or two-person integrity processes, requiring an on-shift supervisor to confirm an entry request within a fraction of a minute.
Separation of duties is often seen as something that introduces inefficiencies, especially in small organizations or within what seem to be simple, well-bounded sequences of processes or tasks. As with any safeguard, senior leadership has to set the risk appetite or threshold level and then choose how to apply that to specific risks.
These types of risk mitigation controls are often put in place to administratively enforce a separation of duties design. By not having one person have such end-to-end responsibility or opportunity, you greatly reduce the exposure to fraud or abuse. In sensitive or hazardous material handling and manufacturing or in banking and casino operations, the work areas where such processes are conducted are often called no lone zones, because nobody is allowed to be working in them by themselves. In information systems, auditing, and accounting operations, this is sometimes referred to as a four-eyes approach for the same reason. Signing and countersigning steps are often part of these processes; these signatures can be pen and ink or electronic, depending upon the overall security needs. The needs for individual process security should dictate whether steps need both people (or all persons) to perform their tasks in the presence of the others (that is, in a no lone zone) or if they can be done in sequence (as in a four-eyes sign/countersign process).
Safety considerations also should dictate the use of no lone zones in work process design and layout. Commercial air transport regulations have long required two pilots to be on the flight deck during flight operations; hospital operating theaters and emergency rooms have teams of care providers working with patients, as much for quality of care as for reliability of care. Peer review, structured walkthroughs, and other processes are all a way to bring multiple eyes and minds to the process of producing high-quality, highly reliable software.
Note that separation of duties does not presume intent: It will protect the innocent from honest mistakes while increasing the likelihood that those with malicious intent will find it harder, if not impossible, to carry out their nefarious plans (whatever they may be). It limits the exposure to loss or damage that the organization would otherwise face if any component in a vital, sensitive process fails to function properly.
Separation of duties, for example, is an important control process to apply to the various event logs, alarm files, and telemetry information produced by all