Mike Wills - The Official (ISC)2 SSCP CBK Reference

Safety, like security, is an end-to-end responsibility. It's no wonder that some cultures and languages combine both in a single word. For example, in Spanish seguridad unifies both safety and security as one integrated concept, need, and mind-set.

Several control principles must be taken into account when developing, implementing, and monitoring people-focused information security risk mitigation controls. Of these, the three most important are need to know, separation of duties, and least privilege. These basic principles are applied in different ways and with different control mechanisms. However, a solid understanding of the principles is essential to evaluating a control's effectiveness and applicability to a particular circumstance.

Security classification and categorization should be the linch pin that ties together the organization's information security and risk mitigation efforts. It's what separates the highest-leverage proprietary information from the routine, nearly-public-knowledge facts and figures. Information classification schemes drive three major characteristics of your information security operations and administration.

Internal boundaries for information control: Many business processes have “insider knowledge” needed to inform decisions or exert control over risky, hazardous, or sensitive sequences of actions. These can and should be encapsulated with a layer that hides that inside knowledge by allowing controlled “write-up” of inputs and “write-down” of outputs to the points where they interface with other business processes. These boundaries surround data at higher levels, and the trusted processes that can manipulate or see it, from outer, surrounding layers of processes that perforce operate at lower levels of trust. (It's not a coincidence that that sounds like a threat surface.)

Standards for trust and confidence: It's only logical to require higher levels of trustworthiness for the people, processes, and systems that deal with our most vital information than we would need for those that handle low-risk information. In most cases, greater costs are incurred to validate hardware, software, vendors, our supply chain, and our people to higher levels of trust and confidence; as with all risk mitigation decisions, cost-effectiveness should be a decision factor. The information classification standards and guide should directly lead to answering the question of how much trustworthiness is enough.

Measures of merit for information security processes: The level of information classification should dictate how we measure or assess the effectiveness of the security measures put in place to protect it.

Taken together these form a powerful set of functional requirements for the design not just of our information security processes but of our business processes as well! But first, we need to translate these into two control or cybernetic principles.

Least privilege as a design and operational principle requires that any given system element (people or software-based) has the minimum level of authority and decision-making capability that the specifically assigned task requires, and no more. This means that designers must strictly limit the access to and control over information, by any subject involved in a process or task, to that minimum set of information that is required for that task and no more. Simply put, least privilege implements and enforces need to know.

A few examples illustrate this principle in action.

A financial disbursements clerk, when generating payments against invoices from suppliers, has to access and use information about each supplier account as well as access his company's bank-related systems to make the payment take place. However, this clerk would not be expected to modify the information about where the payment should be sent, edit the invoice, or alter the amount of the payment. Nor would this clerk be expected to need any information about other employees, such as their payroll information, while generating payments to suppliers.

A process control system that actively manages a chemical processing system for a paint manufacturer would not normally be expected to access the Internet or have a need to run web searches of any kind.

Each time you encounter a situation in which a person or systems element is doing something in unexpected ways—or where you would not expect that person or element to be present at all—is a red flag. It suggests that a different role, with the right set of privileges, may be a necessary part of a more secure solution.

Least privilege should drive the design of business logic and business processes, shaping and guiding the assignment (and separation) of duties to individual systems and people who accomplish their allocated portions of those overall processes. Driven by the Business Impact Analysis (BIA), the organization should start with those processes that are of highest potential impact to the organization. These processes are usually the ones associated with achieving the highest-priority goals and objectives, plus any others that are fundamental to the basic survival of the organization and its ability to carry on day-to-day business activities.

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.