Clark–Wilson model

The Clark–Wilson integrity model provides a foundation for specifying and analyzing an integrity policy for a computing system.

The model is primarily concerned with formalizing the notion of information integrity. Information integrity is maintained by preventing corruption of data items in a system due to either error or malicious intent. An integrity policy describes how the data items in the system should be kept valid from one state of the system to the next and specifies the capabilities of various principals in the system. The model defines enforcement rules and certification rules.

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

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.

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.

See also

References

External links