Clark-Wilson model
From Wikipedia, the free encyclopedia
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.
Contents |
[edit] 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 Bell-LaPadula (read-down/write-up) and Biba (read-up, write-down) were better suited to enforcing data confidentiality rather than information integrity. The Bell-LaPadula and Biba models are more clearly useful in, for example, military classification systems to prevent the theft 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).
[edit] Model Basics
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.
[edit] 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.
