Security products you deploy in your network also rely on a security model. You must know the purposes and scope of each security model in use at your site. To understand why, think about what happens when you add a database management system to an operating system. The operating system and the database manager have different notions of user. No requirement states that the names used to identify users in the operating system and users in the database manager should be identical. In fact, the user names could be derived from completely different alphabets or characters. Different entities are defined in these two products. The operating system works with entities such as files and directories, but the database manager introduces the notions of record, field, and schema. The scope or span of control exercised by the operating system and the database manager differ, too. The operating system controls whether a user is even allowed to install the database manager, but the database manager makes all of the decisions about which parts of each database a user can access.

The database manager and the operating system also participate in a trust relationship. The operating system provides device drivers that the database manager uses to write data to disk. If the device drivers are compromised by a hacker, the integrity of the database might be affected. The database manager trusts that the operating system has adequate controls in place to prevent this type of attack. A trust boundary occurs at the operating system’s interface for calling the device driver. If a hacker can replace the device driver program on disk or if a hacker can intercept the database manager’s request to use the device driver and temporarily substitute a bogus device driver, then security is not guaranteed.

The dependencies that security products and the operating system have on each other are often overlooked or taken for granted. Someone might assume that the database software integrity can be maintained by monitoring the executables and configuration files for tampering. If someone tries to replace one of the binaries making up the database manager itself, a warning could be signaled. However, this warning alone is not sufficient for a secure environment. Each piece of the environment must be secure. As noted, if components of the operating system can be replaced, the database manager can lose its integrity. The only way to understand how products interact is by looking at the security models they introduce.

Understanding the security model upon which a product is based will help in the following ways:

You can precisely state the entities the product controls and describe how the entities interact. Thinking about a product in terms of its basic building blocks is the best way to find out whether the product meets its claims and for understanding how the product interacts with other products.

You can evaluate the implementation of the product itself, not just how the product solves your original problem. You should question the security of the implementation itself. You need to know how entities in the product can be created, deleted, or modified to decide whether the product is trustworthy.

You can recognize the product’s scope. A product that improves login security at your site may not be designed to limit what a user does after access is gained. If you expect more protection from a product than it can reasonably provide, you will be disappointed.

You should understand the product’s trust boundaries. Identifying the boundaries of a product you use improves your awareness because weaknesses often occur at the boundaries. This statement is a basic principle in mechanical and civil engineering. The joints, interfaces, and connection points in an object tend to be the sources of structural problems. The same is true of software systems in general. When those systems are responsible for enforcing a security policy, boundary weaknesses can lead to exploits.

You can recognize where trust relationships are established between products. When an improved login security program is installed at a site, a new trust relationship is created. Prior to the installation of this new security program, the operating system relied on its own software for login security. However, because this program was added, both the operating system and transitively any program running on this system must trust the new login program to do its job properly. Any weakness in the login security program or any weakness in the way it connects to the operating system will result in security problems that can ripple through many other software components.

Product boundaries are important because they present opportunities for attack. Interaction at a boundary involves passing information from one security model to another, where the information can be either data values or a task to perform. The login security product you might add interfaces with the operating system when it reports success or failure depending on the outcome of the login process. You might ask several questions about a product like this:

•  Can a user with a normal account replace all or part of the login software?

•  Is the handshake or protocol used between the operating system and the login program flawed?

•  Can you capture a successful login interaction if performed over the network and then replay the captured network traffic later to spoof the system?

•  How are user names and accounts accessed by the login program?

•  Does the login program check the lengths of values keyed in by users?

In order to answer these questions, you must start with the basic building blocks and construct a security model.

A Basic Computer Security Model

To show that a computer system can maintain confidentiality and integrity, an underlying security model is needed. At the lowest level of the model is an entity that is best thought of as a noun representing something of interest in your universe. Entities are further classified as either subjects or objects. Not surprisingly, this structure is similar to most spoken languages. Indeed, the next concept in the model is the verb access.

Subjects access objects. Upon this simple notion rests the foundation for all computer security products. When you purchase a security product, start by thinking of it in terms of these atomic definitions. What are the subjects? What are the objects? What kinds of access control can be specified between subjects and objects? You will have plenty of other questions to ask, but always start with these.