CS 513 System Security -- Commercial Security Policies

Commercial Security Policies

Lecturer: Professor Fred B. Schneider

Lecture notes by Lynette I. Millett

This lecture is based on:

Clark, David D. and Wilson, David R., A Comparison of Commercial and Military Computer Security Policies. Proceedings IEEE Symposium on Security and Privacy, IEEE Computer Society Press. 1987. pp. 184-194.

The policies we have examined so far have been primarily concerned with maintaining secrecy of data. We are also interested in policies that ensure integrity of data. For instance, a bank is probably much more interested in ensuring that customers not be able to change account balances than it is in ensuring that account balances be kept secret. Although the latter is desirable, unauthorized data modification can usually cause much more harm to a business than inadvertent disclosure of information.

In 1987 Clark and Wilson examined how businesses manage the integrity of their data in the "real world" and how such management might be incorporated into a computer system. In the commercial world, we need security policies that maintain the integrity of data. In this environment, illegal data modification occurs due to fraud and error. And there are two classical techniques to prevent fraud and error.

The first technique is the use of well-formed transactions. More specifically, we stipulate that data can be changed only by performing well-formed transactions. Users may not manipulate data arbitrarily, but only in constrained ways that preserve or establish its integrity. An example of this is double-entry bookkeeping. This involves making two sets of entries for everything that happens. Another example is the use of logs. Everything that occurs is recorded on a log. For example, rather than erasing mistakes, the sequence of actions that reverses the mistake is performed and recorded on the log. A record of everything that has occurred is maintained. Using well-formed transactions makes it more difficult for someone to maliciously or inadvertently change data.

Another technique to prevent fraud is referred to as separation of duty. Here, operations on data are separated into subparts that must be done by independent parties. This works to maintain integrity as long as there is no collusion between agents working on different subparts. A typical transaction might look as follows:

A purchasing agent creates an order. The agent sends the order to both the supplier and the receiving agent.
The supplier ships the goods to the receiving department. The receiving clerk checks the goods that were received against the original order and updates the inventory records.
The supplier also sends an invoice to the accounting department. The accountant checks the invoice against both the original order and what the shipping clerk said was received. If they match, the accountant pays the bill.

In this scenario, no one person can cause a problem that will go unnoticed. The separation of duty rule being employed here is: A person who can create or certify a well-formed transaction may not execute it.

Commercial Security Policies in Cyberspace

The question now becomes: How can we employ these commercial policies in computer systems? First, we require that data objects be manipulated only by well-formed transactions. That means we need a mechanism to ensure that a data item can be manipulated only by a specific set of programs (the well-formed transactions). Second, we need a way to ensure separation of duties. This can be done by a mechanism that restricts which programs each user can execute. We can compare this with the Bell LaPadula (BLP) approach discussed previously. In BLP, a data item is associated with a security level; here, a data item is associated with program(s) that can access it. In BLP, users can read and write data; in our new scheme, users can execute certain programs (data access is implicit in the programs).

How can these mechanisms be implemented? In order to restrict what programs a user can execute, the system must authenticate every user (e.g. with passwords.). We also need a way to associate data with the programs that can manipulate it. To meet the "separation of duty" requirement, users need to be associated with programs. Finally, the system needs to maintain an audit log.

A formal description is as follows. We partition the data items into two sets: constrained data items (CDIs) and unconstrained data items (UDIs). In order to satisfy the create vs. certify rule we define integrity verification procedures (IVPs). These are used to confirm that all CDIs conform to the integrity specifications. We insist that well-formed transactions manipulate only CDIs. Such transactions can also turn UDIs into CDIs. We postulate transformation procedures (TPs) as a way to manipulate CDIs. If a CDI starts in an "integrity" state, then running a TP on that CDI leaves it in that state. The rules can be formalized as follows:

The system maintains a list (uid, TP_i, CDI₁, ..., CDI_n) and insists that uid can execute TP_i and that TP_i only accesses CDI₁, ..., CDI_n. This ensures that the only manipulation of a CDI is by a TP that has been certified to preserve an integrity constraint.
All TPs are certified to write to an append-only CDI (the log) the information necessary to permit the nature of the operation to be reconstructed.
Any TP that takes a UDI as input must output a valid CDI or be a no-op.