Clark–Wilson model

Origin

The model was described in a 1987 paper (A Comparison of Commercial and Military Computer Security Policies) by David D. Clark and David R. Wilson. The paper develops the model as a way to formalize the notion of information integrity, especially as compared to the requirements for multi-level security (MLS) systems described in the Orange Book. Clark and Wilson argue that the existing integrity models such as Biba (read-up/write-down) were better suited to enforcing data integrity rather than information confidentiality. The Biba models are more clearly useful in, for example, banking classification systems to prevent the untrusted modification of information and the tainting of information at higher classification levels, respectively. In contrast, Clark–Wilson is more clearly applicable to business and industry processes in which the integrity of the information content is paramount at any level of classification (although the authors stress that all three models are obviously of use to both government and industry organizations).

Basic principles

According to Stewart and Chapple's CISSP Study Guide Sixth Edition, the Clark-Wilson model uses a multi-faceted approach in order to enforce data integrity. Instead of defining a formal state machine, the model defines each data item and allows modifications through only a small set of programs. The model uses a three-part relationship of subject/program/object (where program is interchangeable with transaction) known as a triple or an access control triple. Within this relationship, subjects do not have direct access to objects. Objects can only be accessed through programs. Look here to see how this differs from other access control models.

The model’s enforcement and certification rules define data items and processes that provide the basis for an integrity policy. The core of the model is based on the notion of a transaction.

A well-formed transaction is a series of operations that transition a system from one consistent state to another consistent state.

In this model the integrity policy addresses the integrity of the transactions.

The principle of separation of duty requires that the certifier of a transaction and the implementer be different entities.

The model contains a number of basic constructs that represent both data items and processes that operate on those data items. The key data type in the Clark–Wilson model is a Constrained Data Item (CDI). An Integrity Verification Procedure (IVP) ensures that all CDIs in the system are valid at a certain state. Transactions that enforce the integrity policy are represented by Transformation Procedures (TPs). A TP takes as input a CDI or Unconstrained Data Item (UDI) and produces a CDI. A TP must transition the system from one valid state to another valid state. UDIs represent system input (such as that provided by a user or adversary). A TP must guarantee (via certification) that it transforms all possible values of a UDI to a “safe” CDI.

Clark–Wilson model rules

At the heart of the model is the notion of a relationship between an authenticated principal (i.e., user) and a set of programs (i.e., TPs) that operate on a set of data items (e.g., UDIs and CDIs). The components of such a relation, taken together, are referred to as a Clark–Wilson triple. The model must also ensure that different entities are responsible for manipulating the relationships between principals, transactions, and data items. As a short example, a user capable of certifying or creating a relation should not be able to execute the programs specified in that relation.

The model consists of two sets of rules: Certification Rules (C) and Enforcement Rules (E). The nine rules ensure the external and internal integrity of the data items. To paraphrase these:

C1—When an IVP is executed, it must ensure the CDIs are valid. C2—For some associated set of CDIs, a TP must transform those CDIs from one valid state to another.

Since we must make sure that these TPs are certified to operate on a particular CDI, we must have E1 and E2.

E1—System must maintain a list of certified relations and ensure only TPs certified to run on a CDI change that CDI. E2—System must associate a user with each TP and set of CDIs. The TP may access the CDI on behalf of the user if it is “legal.”

This requires keeping track of triples (user, TP, {CDIs}) called “allowed relations.”

C3—Allowed relations must meet the requirements of “separation of duty.”

We need authentication to keep track of this.

E3—System must authenticate every user attempting a TP. Note that this is per TP request, not per login.

For security purposes, a log should be kept.

C4—All TPs must append to a log enough information to reconstruct the operation.

When information enters the system it need not be trusted or constrained (i.e. can be a UDI). We must deal with this appropriately.

C5—Any TP that takes a UDI as input may only perform valid transactions for all possible values of the UDI. The TP will either accept (convert to CDI) or reject the UDI.

Finally, to prevent people from gaining access by changing qualifications of a TP:

E4—Only the certifier of a TP may change the list of entities associated with that TP.

CW-lite

A variant of Clark-Wilson is the CW-lite model, which relaxes the original requirement of formal verification of TP semantics. The semantic verification is deferred to a separate model and general formal proof tools.