that requires the development of abstract security models and supporting mechanisms. Although careful analysis of the kind carried out in this chapter may seem tedious, it is a necessary prerequisite to ensuring the security of something as complicated as a computer system. Ensuring security, like protecting the environment, requires a holistic approach; it is not enough to focus on the problem that caused trouble last month, because as soon as that difficulty is resolved, another will arise.
The distinction between what a system does and how it does it, between specification and implementation, is basic to the design and analysis of computer systems. A specification for a system is the meeting point between the customer and the builder. It says what the system is supposed to do. This is important to the builder, who must ensure that what the system actually does matches what it is supposed to do. It is equally important to the customer, who must be confident that what the system is supposed to do matches what he wants. It is especially critical to know exactly and completely how a system is supposed to support requirements for security, because any mistake can be exploited by a malicious adversary.
Specifications can be written at many levels of detail and with many degrees of formality. Broad and informal specifications of security are called security policies1 (see Chapter 2), examples of which include the following: (1) "Confidentiality: Information shall be disclosed only to people authorized to receive it." (2) "Integrity: Data shall be modified only according to established procedures and at the direction of properly authorized people."
It is possible to separate from the whole the part of a specification that is relevant to security. Usually a whole specification encompasses much more than the security-relevant part. For example, a whole specification usually says a good deal about price and performance. In systems for which confidentiality and integrity are the primary goals of security policies, performance is not relevant to security because a system can provide confidentiality and integrity regardless of how well or badly it performs. But for systems for which availability and integrity are paramount, performance specifications may be relevant to security. Since security is the focus of this discussion, "specification" as used here should be understood to describe only what is relevant to security.
A secure system is one that meets the particular specifications meant to ensure security. Since many different specifications are possible,