When people are asked why they think computer security is important, their responses usually show concern for confidentiality. Most of us do not want our medical records made easily available to anyone curious enough to ask for them. Credit histories and other financial data hopefully are treated with confidence, too. Academic records, performance evaluations, and personnel files are other sources of information that we generally assume must be handled confidentially. Likewise, numerous manual procedures for the confidential care of banking transactions have been developed over hundreds of years. Therefore, a clear history of how to accomplish confidentiality has been established even if a computer is not in the loop.

Integrity of information is also of concern in everyday life. Unauthorized changes to your credit history represent a weakness in the capability of a system to maintain integrity of the data under its control. In network communications, if an adversary manages to alter the data packets before the destination is reached, the integrity of the information has been compromised. If you are browsing a Web site and a malicious person can gather information from your personal computer and then use this information to steal funds from your bank account, you have become a victim of both integrity and confidentiality violations.

Lack of data availability caused by security problems is a major concern. If the primary trading database for a securities brokerage firm is inaccessible, millions of dollars could be lost with every passing minute. If the database suddenly became unreachable because of a software bug, few people would be shocked. Neither would it be a surprise if the disk drives failed and crashed the database. However, if the database becomes unavailable as a result of industrial espionage, watch for front-page coverage in the newspapers! Despite this potential reaction, money more likely will be budgeted for redundant power supplies, redundant network adapters, redundant servers, and redundant disks but not allocated for the purchase of a security monitoring product.

How can we show that a security product provides confidentiality, integrity, and availability? Using techniques from theoretical computer science, we can formally define confidentiality and integrity within the context of a particular computer system. As a consequence, one can say that confidentiality and integrity are computable. This notion is very profound because it enables security researchers to know without doubt that a particular system enforces confidentiality and integrity (Brinkley and Schell, 1995). In commercial products, these formal methods are rarely used. However, it is comforting to know that, in principle, we can rigorously defend a product’s claims about integrity and confidentiality.

Proving availability is more complicated. Statements regarding availability cannot be made with as much confidence as those for integrity and confidentiality. The main reason for this is that identifying all of the factors influencing availability in a particular computer system is almost impossible. That is, these influences cannot be exhaustively listed in mathematical expressions, and thus, a formal proof for availability is more elusive. Formal proofs and notations are not used in this book, but if you would like to learn more about formal models of computer security, many good references are available (Bell, 1990; LaPadula, 1990; Williams and Abrams, 1995), so check the references at the back of the book for these resources.

To summarize in computer security jargon, we can make statements about confidentiality and integrity with a high level of assurance, but we cannot make statements about the availability of a particular system with the same level of assurance. At least you can feel confident that products built to protect the confidentiality and integrity of your system can be provably secure assuming that the vendor has followed some sound design and development processes.

In computer security literature, you sometimes will find other goals of computer security including authentication and nonrepudiation. Authentication is the process of verifying the identity of someone or something, such as a when a user enters a password. Nonrepudiation is the process of proving that a message came from a particular sender and that the message could not have come from anyone else. As you see in this chapter, authentication is defined as a required supporting function of the basic security model, rather than as an explicit goal. Nonrepudiation might be needed at your site, but because it is not always required, nonrepudiation is omitted from the three primary goals listed previously.

Now that you know the security goals for your network, it’s time to take a look at how the goals can be met—by implementing a security model.

Learn to Ask Tough Questions

A security model is an abstraction used to define entities and how these entities are allowed to interact. A security model begins as a set of definitions on paper, but eventually the model is implemented in software, hardware, or both. Hopefully, the implementation is accurate and adheres to the model specification. If the implementation is flawed, the system will lack the capability to provide confidentiality, integrity, and availability.

A security model is found in every operating system. As part of the security model in most operating systems, access to each file can be limited in specific ways. In traditional UNIX systems, one rule controlling access might state that only Joe is allowed to read the file named JoeMail. The entities in this case are Joe and JoeMail, and both must be uniquely identifiable within the context of the operating system. Any ambiguity weakens the capability of the model to meet its three goals. The access control rule, or authorization, which is used to specify this particular part of the security policy consists of the triple {Joe,JoeMail,read}. Naturally, these few entities and this one rule represent only a fraction of the complete operating system security policy and underlying security model. Other operating system entities are files, processes, threads, queues, messages, processors, and the kernel itself.