Security Requirements and Goals

Security is a key issue with many implications, and it is critical throughout software systems. Thus, when we speak of security in software, it can refer to many areas of the systemapplications, data, networks, communications, users, host systems, and so forth. Within each of these areas are common security requirements and goals that involve the protection of data. Data that is passed over communication paths that may be open to unauthorized viewers needs to be protected; this is the concept of confidentiality. This same data must be protected from unauthorized changes during transit; this is the concept of data integrity. Users, whether human or programmatic, must be able to prove their identities before being allowed access to the data; this is the concept of authentication. Once authenticated, the system needs to ascertain what type of access the user has to the data; this is the concept of authorization. When a user does perform an action on data, such as approving a document, that action must be bound with the user in such a way that the user cannot deny performing the action; this is the concept of non-repudiation. Each of these concepts is explained further in the sections that follow.

Confidentiality

Confidentiality is the concept of protecting sensitive data from being viewable by an unauthorized entity. A wide variety of information falls under the category of sensitive data. Some sensitive data may be illegal to compromise, such as a patient's medical history or a customer's credit card number. Other sensitive data may divulge too much information about the application. For example, a Web application that keeps a user's state via a cookie value may be more susceptible to compromise if a malicious adversary can derive certain information from the cookie value. With the increased use of legacy systems exposed via Web services over the Internet, ensuring the confidentiality of sensitive data becomes an especially high priority.

However, communication links are not the only area that needs solutions to ensure confidentiality. An internal database holding thousands of medical histories and credit card numbers is an enticing target to a malicious adversary. Securing the confidentiality of this data reduces the probability of exposure in the event the application itself is compromised.

To protect the confidentiality of sensitive data during its transit or in storage, one needs to render the data unreadable except by authorized users. This is accomplished by using encryption algorithms, or ciphers. Ciphers are secret ways of representing messages. There are a wide variety of ciphers at the software developer's disposal; these are discussed later in this chapter.

Integrity

Integrity is the concept of ensuring that data has not been altered by an unknown entity during it transit or storage. For example, it is possible for an e-mail containing sensitive data such as a contractual agreement to be modified before it reaches the recipient. Similarly, a purchase request sent to a Web service could be altered en route to the server, or a software package available for downloading could be altered to introduce code with malicious intent (a "trojan horse"). Checking data integrity ensures that data has not been compromised.

Many communications protocols, including TCP/IP, employ checksum or CRC (cyclic-redundancy check) algorithms to verify data integrity, but an intelligent adversary easily overcomes these. For example, suppose a downloadable software package has a published CRC associated with it, and this package is available at many mirror sites. An adversary with control over one of the mirrors installs a Trojan horse in the program; now the CRC has changed. The attacker can alter other insignificant parts of the code so that the CRC calculates to what it was before the alteration.

To counter this threat, cryptographically strong one-way hash functions have been developed that make it computationally infeasible to create the same hash value from two different inputs. There are quite a few such hash functions available in the public domain; details are discussed later in this chapter.

Authentication

Authentication is the concept of ensuring that a user's identity is truly what the user claims it to be. This is generally accomplished by having the user first state his identity and then present a piece of information that could only be produced from that user.

The oldest and most common form of user authentication is password authentication. However, passwords may be intercepted if sent on an unsecured line, where their confidentiality is not ensured. Passwords can be exposed by a variety of other means as well. Passwords are often written down and left in places too easily discovered by others. Also, people often use the same password for different services, so exposure of one password opens up multiple targets for potential abuse. Passwords are an example of authentication based on "what you know."

In response to the issues with password-type authentication, alternatives have been developed that are based on other factors. One approach requires the user to enter a different password for each login. This can be accomplished by giving the user a device that is used during the authentication process. When the user logs in, the server sends a "challenge" string that the user keys into her security device. The device displays a response to the challenge string, which the user sends back to the server. If the response is correct, the user has been successfully authenticated. Unlike passwords, this authentication is based on "what you have," rather than "what you know." Alternatively, instead of sending a challenge string, the server and the security device may be time-synchronized so that the user only needs to type in the display on the security device. Generally, such security devices use cryptographic techniques; for example, the device will have a unique internal key value that is known by the server, and the user's response will be derived from an encrypt function of the challenge string or current time. One of the more popular security device-based authentication solutions is SecureID, which uses a time-synchronized device to display a one-time password. Additionally, SecureID requires the user to prepend the one-time password with a regular password of the user's choosing, combining "what you have" with "what you know" to create a strong authentication solution.

Along with "what you know" and "what you have," there are authentication methods based on "what you are"biometrics. Biometric authentication products check fingerprints, retina patterns, voice patterns, and facial infrared patterns, among others, to verify the identity of the user. However, even these methods can be fooled [Schneier02], so a best practice is to combine biometrics with additional authentication (such as a password). The role of biometrics in personal identification and authentication is discussed in Chapter 15, "Secure Personal Identification Strategies Using Smart Cards and Biometrics."

Authorization

Authorization is the concept of determining what actions a user is allowed to perform after being allowed access to the system.

Authorization methods and techniques vary greatly from system to system. One common method employs access control lists (ACLs), which list all users and their access privileges, such as read-only, read and modify, and so forth. Another technique is to assign each user a role or group identification, and the rest of the application checks this to determine what actions the user may perform. On UNIX operating systems, the owner of each file determines access to that file by others. Each system presents unique requirements that affect the design of authorization methods for that system.

Non-Repudiation

Non-repudiation is the concept that when a user performs an action on data, such as approving a document, that action must be bound with the user in such a way that the user cannot deny performing the action. Non-repudiation is generally associated with digital signatures; more details are presented later in this chapter.