JOHN OF GAUNT: This fortress built by Nature for herselfAgainst infection and the hand of war,This happy breed of men, this little world,This precious stone set in the silver sea,Which serves it in the office of a wall,Or as a moat defensive to a house,Against the envy of less happier lands; | ||
| --The Tragedy of King Richard the Second, II, i, 43–49. | ||
The goals of an installation, and its security policy, dictate the functionality required of the site. The distribution of functionality throughout the site's network is critical to improving the security of the site. The functionality of each part of the network controls the nature and configuration of each host on the network. This chapter applies some of the principles and concepts of computer security to a particular situation.
The Dribble Corporation builds and sells dribbles, an electronic item popularly seen as the successor to the Pet Rock. The Drib (the popular name for the corporation) has decided to develop a network infrastructure that would enable it to connect to the Internet, to provide a Web and electronic mail presence that consumers, suppliers, and other partners could access, and to protect its proprietary information. Because of its need to add meaningless but entertaining information gleaned from various Internet Web sites, the Drib developers must have access to the Internet, but external users cannot be allowed to access the development sites. Finally, because dribbles look like their main competitor, gibbles (from the Gibble Gabble Gobble Git Company), the Drib has many lawyers working to defend its patents on dribbles, and its corporate officers are preparing to fight a hostile takeover from GGGGC. Hence, the corporate officers and lawyers also need access to developer data, but the developers are not to have access to the corporation's private or legal information.
The goals of the Drib's security policy are to be as follows.
Data related to company plans is to be kept secret. In particular, sensitive corporate data, such as data involved in developing potential products, is to be available only to those who need to know.
When a customer provides data (such as a credit card number) to the Drib as part of a purchase, the data, and all information about the customer, are to be available only to those who fill the order. Company analysts may obtain statistics about a number of orders for plannning purposes.
Releasing sensitive data requires the consent of the company's officials and lawyers.
Our goal is to design a network infrastructure that will meet these requirements. We begin by analyzing the goals of the policy so that we can make them precise.
The Drib requires a policy that minimizes the threat of data being leaked to unauthorized entities. However, it is unclear what “unauthorized” should mean. The Drib's internal structure suggests one answer.
The Drib has three main internal organizations. The first is the Customer Service Group (CSG), which handles all dealings with customers. This group maintains all customer data and serves as the interface between the other groups and the clients of the Drib. The second group is the Development Group (DG), which develops, modifies, and maintains products. Members of the DG rely on the CSG for descriptions of customer complaints, suggestions, and ideas; at no time do they talk directly with customers. This prevents them from accidentally revealing confidential information or from learning confidential information such as credit card numbers. The Corporate Group (CG) handles the Drib's debentures, lawsuits, patents, and other corporate-level work.
The policy describes the way information is to flow among these groups.
When one looks at the actual functions of the three groups, how they restrict information, and how they share information, a pattern emerges. Specifications of current products, as well as marketing and sales literature, are publicly available. However, other information about current products, such as problems (especially those that are the subjects of lawsuits), patent applications, and budgets, is not public. The CG and DG groups share this information for planning, budgeting, and development purposes, but beyond this sharing, each group keeps its own private information. The CG keeps corporate information private so that it can be protected by attorney privilege and so that it can comply with government stock regulations. The DG plans and prototypes future products. The DG waits until it is convinced that production is feasible before it proposes a new product to the CG. The CSG keeps track of customer credit card information and specific clients' ordering information for its own purposes, and it does not share this information (except in the aggregate) with either the CG or the DG. This forms the basis for the policy.
We classify information into five classes that reflect the divisions outlined above. The classification reflects the principle of least privilege[1] by separating the data in such a way that the ability to view one class of data does not imply the ability to view another class of data. Also, the policy and all its rules are not secret, reflecting the principle of open design.[2] Note that “open design” does not mean that this information is available to the public. It simply means that anyone within the Drib who is affected by the policy, or who wants to know what the policy is and why it was designed that way, can find out.
Public data (PD) is available to anyone. It includes product specifications, price information, marketing literature, and any other data that will help the Drib sell dribbles without compromising its secrets.
Development data for existing products (DDEP) is available only internally. Because of pending lawsuits, it must be available to the company lawyers and officers as well as to the developers. It is kept secret from all others.
Development data for future products (DDFP) is available to the developers only. The specifications may change, as may various aspects of development, but the Drib never announces information about products under development, and does not intend to change this style of operation.
Corporate data (CpD) includes legal information that is privileged and information about corporate actions that is not to become known publicly (such as actions that may affect stock values). The corporate officials and lawyers need access to this information; no one else does.
Customer data (CuD) is data that customers supply, such as credit card information. The Drib protects this data as strongly as it protects its own data.
Data may change from the DDFP class to the DDEP class as products become implemented; from the DDEP class to the PD class when deemed advantageous to publicize some development details; and from the CpD class to the PD class as privileged information becomes publicly known through mergers, lawsuit filings, or the ordinary course of business. There is no provision for revealing CuD directly; this protects the privacy of the Drib's customers.
Four classes of people may access data. The user classes are based on the same principles as the classes of data: separation of privilege[3] and least privilege.[4] Some users may be placed in multiple classes. If so, an underlying assumption of the model is that they will not bypass the restrictions by copying data from one class to another without using the mechanisms provided for that purpose.
Outsiders (members of the public) get access to some of the Drib's data such as prices, product descriptions, and public corporate information. The public can also order merchandise, download new drivers for their dribbles, and send electronic mail to the company.
Developers get access to both classes of development data. They cannot alter development data for existing products because that data describes how to manufacture the product. It also provides a historical record for use in developing new products. Developers can modify development data for future products, however.
Corporation executives (corporation counsel, members of the board of directors, and other executives) get access to corporate data. They can see development data for both existing and future products but may not alter it. They may read customer data (for legal purposes or analysis). Under specific conditions (described below), they may make sensitive data public.
Employees get access to customer data only.
The following table summarizes the access that each class of users has to each class of data. This table is an access control matrix[5] and defines the access control policy. It reflects a mandatory access control policy[6]; the discretionary component is fixed at “allow always.” This matrix combines elements of confidentiality[7] and integrity.[8] Left as an implementation detail is the security officer who puts people and data into the appropriate classes (see Lipner's integrity matrix model,[9] and Exercise 1).
Outsiders | Developers | Corporation executives | Employees | |
|---|---|---|---|---|
Public data | read | read | read | read |
Development data for existing products | read | read | ||
Development data for future products | read, write | read | ||
Corporate data | read, write | |||
Customer data | write | read | read, write |
Specific classes of people can move data from one class to another, as indicated above. The specific transformation rules are as follows.
The developers must propose that a proposed future product be realized. Corporation executives must determine if the proposed action is wise, from both legal and economic standpoints. Hence, both developers and corporation executives must agree to reclassify data from the DDFP class to the DDEP class.
The employees may identify certain development data as important for answering technical questions from outsiders, or for market literature. In these cases, the employees notify the corporation executives, who then decide whether or not to make the information public. Both employees and corporation executives must agree to reclassify data from the DDEP class to the PD class.
Corporation executives may reveal corporate data in filings or when revealing that the data will not harm the company. Thus, they can reclassify data from CpD to PD. However, at least two members must agree to do the reclassification.
The principle of separation of privilege[10] dictates that moving data from one class to another requires approval of more than one user. In the first two cases, the users must come from separate classes because the data involved may reveal internal information that would be of use to a competitor. (Two users in different classes may be the same user in two different roles.[11] Hence, the requirement for two different users.) The third case involves corporate business, usually in legal matters (such as lawsuits or stock filings). In this case, the Drib lawyers (all of whom are in the “corporate executive” user class) have the expertise to determine what must be revealed, and because the consequences may involve criminal charges, the lawyers and corporate executives must make the decisions. Because the Drib is a well-run company, they will obtain the appropriate information and recommendations from people in the other user classes as required. However, the requirement that the two members be in the corporate executive class is an acknowledgment of the responsibility of the corporate executives.
The Drib is a world-wide, multinational corporation and does business on all seven continents (although its Antarctic operation is quite small). Orders come from all over the world. Thus, the corporate officers want employees and the public to be able to contact the Drib at any time. In practice, this means that the Drib's systems must be available 99% of the time, the remaining 1% being used for planned maintenance and unexpected downtimes.
The policy described above should meet the goals of the Drib. Otherwise, it is not an appropriate policy. We will now review the goals of the policy and discuss consistency.
The first goal is to keep sensitive information confidential, on a “need to know” basis. Public data is, by definition, not confidential, and is available to all. Developers clearly need access to both current and future development data, but not to customer data or corporate information (because they do not decide which products to market). They can alter development data as they investigate possibilities and test ideas. Corporate executives need access to corporate data to plan business actions. Some of these actions may be based on development data for existing products; for example, should the Drib invest in a company developing faster CPUs for the Drib's products? Hence, corporate executives also need access to development data for existing products. They can alter corporate data, but not development data. So, the first goal of the policy is met.
The second goal requires that only employees who handle purchases can access customer data, and only they and the customers themselves can alter the customer data. The policy above provides this restriction.
The third goal is met by the rules for changing security classes. Moving data from the DDFP class to the DDEP class requires consent of both a developer and a corporate executive. Moving data from the DDEP class to the PD class requires the consent of an employee and a corporate executive. Finally, moving data from the corporate class to the public class requires consent of a corporate executive. In all cases, a corporate executive can prevent the release of company information. Furthermore, because no other class of users can write public class data, only the corporate executives can release the information.
Thus, the policy is valid, because it meets the security requirements of the Drib.[12]
We next verify the consistency of the policy, to show that it is not self-contradictory. We construct the transitive closure of all paths along which information can flow among the classes. From this closure, it is clear that the only way information can flow into the public class is when a corporate executive moves it there. Hence, the key point of trust is in the corporate executive class. Without an executive acting, information simply cannot become public. Furthermore, by the rules for moving data out of the DDEP and DDFP classes, some other entity beyond the corporate executives must consent to the release of the information. This satisfies the principle of separation of privilege as well as the corporate goals. Because there is no contradiction among the rules in the policy, the policy is self-consistent.
We have now (informally) both validated and verified the policy. Validation and verification are basic aspects of information assurance[13] and provide a basis for asserting that the policy is correct.
We have now defined the confidentiality, integrity, and availability aspects of the Drib's basic security policy. We will now expand this into a simple network architecture.
The policy discussed above suggests that the network be partitioned into several parts, with guards between parts to prevent information from leaking. Each type of data resides in one of the parts (we combine both types of development data into one type, DD). The resulting partition is shown in Figure 26-1. This is a fairly standard corporate network, with one part available to the public and a second part available only internally.
Definition 26–1. The DMZ[14] is a portion of a network that separates a purely internal network from an external network.
Figure 26-1. The network designed for the Dribble Corporation. The “outer firewall” sits between the Internet and the company network. The subnet labeled “DMZ” provides limited public access to various servers. The “inner firewall” sits between the DMZ and the subnets that are not to be accessed by the public. These subnets share common mail and DNS servers that, like the other hosts, are not publicly accessible.
When information moves from the Internet to the internal network, confidentiality is not at issue. However, integrity is. The guards[15] between the Internet and the DMZ, and between the DMZ and the internal network, must not accept messages that will cause servers to work incorrectly or to crash. When information moves from the internal network to the Internet, confidentiality and integrity are both at issue. The firewalls must ensure that no confidential information goes to the Internet and that the information that reaches the Internet is correct.[16] The latter issue requires simply that information not be altered in transit from the internal network to the Internet. For simplicity, we make the assumption that the systems as deployed will not change any information in transit (except delivery information, such as packet headers). If such changes are made, then the system has been compromised by an attacker. This would require the attacker to gain access to the system. This is equivalent to the problem of disallowing certain types of information (namely, attack mechanisms) from entering the internal or DMZ subnets from the Internet—in other words, ensuring the integrity of this information.[17]
The arrangement and configuration of the firewalls provide the supporting access control mechanisms used to implement the policy.[18]
The “guards” mentioned above perform access control in both directions,[19] to and from the Drib's network.
Definition 26–2. A firewall is a host that mediates access to a network, allowing and disallowing certain types of access on the basis of a configured security policy.
This firewall accepts or rejects messages on the basis of external information, such as destination addresses or ports, rather than on the basis of the contents of the message.
Definition 26–3. A filtering firewall performs access control on the basis of attributes of the packet headers, such as destination addresses, source addresses, and options.
Routers and other infrastructure systems are typical examples of filtering firewalls. They allow connections through the firewall, usually on the basis of source and destination addresses and ports. Access control lists provide a natural mechanism for representing these policies.[20]
This contrasts with the second type of firewall, which never allows such a direct connection. Instead, special agents called proxies control the flow of information through the firewall.
Definition 26–4. A proxy is an intermediate agent or server that acts on behalf of an endpoint without allowing a direct connection between the two endpoints.
Definition 26–5. A proxy (or applications level) firewall uses proxies to perform access control. A proxy firewall can base access control on the contents of packets and messages, as well as on attributes of the packet headers.
A proxy firewall adds to a filtering firewall the ability to base access on content, either at the packet level or at a higher level of abstraction.
A different point of view is to see the firewall as an audit mechanism.[21] It analyzes the packets that enter. Firewalls can then base actions on this analysis, leading to traffic shaping (in which percentages of bandwidth are reserved for specific types of traffic), intrusion response,[22] and other controls.
With these definitions in mind, the reason for this structure of the network falls into place.
The benefits of this design flow from the security policy and the principle of least privilege. The security policy distinguishes “public” entities from those internal to the corporation, but recognizes that some corporate resources must be available to the public. The network layout described above provides this functionality. The public entities may enter the corporate perimeter (bounded by the “outer firewall”) but are confined to the DMZ area (bounded inside by the “inner firewall”). The next few paragraphs give an overview of the technical details of this arrangement. We then expand on the configurations of the infrastructure systems.
The key decision is to limit the flow of information from the internal network to the DMZ. The public cannot communicate directly with any system in the internal network, nor can any system in the internal network communicate directly with other systems on the Internet (beyond the “outer firewall”). The systems in the DMZ serve as mediators, with the firewalls providing the guards. This setup is derived from the notion of the “pump” (see page 469 in Section 17.3.3). The firewalls and the DMZ systems make up the pump, because they control all access to and from the Internet and filter all traffic in both directions.
The first step is to conceal the addresses of the internal network. In general, the internal network addresses can be any IP addresses (the families of addresses specifically allocated to private networks are 10.x.y.z, 172.a.x.y (where16 < a < 31), and 192.168.x.y[23] [837]), and the inner firewall can use a protocol such as the Network Address Translation protocol [959] to map these internal host addresses to the firewall's Internet address. A more common method is to assign each host an address but not allow those addresses to leave the corporate network. This is particularly simple, because all services are implemented as proxies in the outer firewall. However, electronic mail presents a special problem.
The DMZ mail server must know an address in order for the internal mail server to pass mail back and forth. This need not be the actual address of the internal mail server. It could be a distinguished address that the inner firewall will recognize as representing the internal mail server. Similarly, the internal mail server must know an address for the DMZ mail server. These addresses can be fixed (in which case the DMZ DNS server is unnecessary). For flexibility, we will assume that the Drib has decided to use a DNS server on both the internal and DMZ subnets. As a backup, each system in the DMZ has the network addresses of both firewalls stored locally, so if the DNS system is unavailable, the other servers can function.
The Web server lies in the DMZ for the same reasons that a mail server lies in the DMZ. External connections to the Web server go into the DMZ and no farther. If any information is to be transmitted from the Web server to the internal network (for example, the customer data subnet), the transmission is made separately, and not as part of a Web transaction.
This network organization reflects several of Saltzer and Schroeder's design principles [865]. The containment of internal addresses reflects the principle of least privilege[24] as well as the Drib's solution to the confinement problem.[25] The inner firewall mediates every access involving the DMZ and the internal networks, meeting the principle of complete mediation.[26] Going out of the inner network to the Internet requires that several criteria be met, to implement the principle of separation of privilege.[27] The firewalls are distinct computers, as are the DMZ servers, leading to a duplication rather than a sharing of network services. If the mail server stops working, for example, the WWW server is not affected. The principle of least common mechanism[28] suggests this design. The shared DNS server in the DMZ violates this principle, because multiple systems are affected if it is corrupted or unavailable. The reason for the local, fixed addresses of the two firewalls is to handle the case of unavailability, mitigating this threat. Finally, the applications of confinement, access control,[29] and information flow control[30] have been discussed earlier.
We now examine each component in more detail.
The goals of the outer firewall are to restrict public access to the Drib's corporate network and to restrict the Drib's access to the Internet. This arises from the duality of information flow.[31] In the Bell-LaPadula Model,[32] for example, one cannot read information from a higher level (here, by restricting public access to the Drib's network), but one cannot write information to a lower level, either (here, by restricting the Drib's employees' access to the Internet). Certain sanitized exchanges, however, are allowed. To implement the required access control, the firewall uses an access control list,[33] which binds source addresses and ports and destination addresses and ports to access rights.
The public needs to be able to access the Web server and mail server, and no other services. The firewall therefore presents an interface that allows connections to the WWW services (HTTP and HTTPS) and to electronic mail (SMTP). Sites on the Internet see the addresses of the Web and mail servers as the same—that of the firewall. No other services are provided to sites on the Internet.
The firewall is a proxy-based firewall. When an electronic mail connection is initiated, the SMTP proxy on the firewall collects the mail. It then analyzes it for computer viruses and other forms of malicious logic. If none is found, it forwards the mail to the DMZ mail server. When a Web connection (or datagram) arrives, the firewall scans the message for any suspicious components (such as extraordinarily long lines or other evidence of attacks) and, if none is found, forwards it to the DMZ Web server. These two DMZ servers have different addresses, neither of which is the address of the firewall.
Attackers trying to penetrate the firewall have three methods of entry. The first is to enter through the Web server ports. The unsecured (HTTP) port proxy checks for invalid or illegal HTTP requests and rejects them. The second is to enter through the SMTP port. The mail proxy will detect and reject such attempts. The third is to attempt to bypass the low-level firewall checks by exploiting vulnerabilities in the firewall itself.
The discussion of vulnerabilities in Chapter 23, “Vulnerability Analysis,” implies that there is no way to ensure that the firewall software and hardware cannot be breached. Designing the firewall mechanisms to be as simple as possible, in accordance with the principle of economy of mechanism,[34] using assurance techniques such as those described in Part 6 minimizes, but does not eliminate, this possibility. So we apply the principle of separation of privilege[35] in the form of a technique called “defense in depth.” In order to attack a system in the DMZ by bypassing the firewall checks, the attacker must know something about the internal addresses of the DMZ. If, for example, the attacker knows that the internal address of the DMZ mail server is 10.34.231.19, the attacker may be able to use that information to piggyback packets to that host.[36] But if the attacker has no idea of the internal DMZ mail server's address, even if the attacker is able to bypass the firewall checks, he or she will not know where to have the packets sent.
The internal network is where the Drib's most sensitive data resides. It may contain data, such as proprietary information, that the Drib does not want outsiders to see. For this reason, the inner firewall will block all traffic except for that specifically authorized to enter (the principle of fail-safe defaults[37] ). All such information will come from the DMZ, and never directly from the Internet.
Like the outer firewall, the inner firewall allows a limited set of traffic through (using the same type of access control mechanism as does the outer firewall). It allows SMTP connections using proxies, but all electronic mail is sent to the DMZ mail server for disposition. It allows limited transfer of information to the DNS server in the DMZ. It also allows system administrators to access the systems in the DMZ from a trusted administrative server. All other traffic, including Web access, is blocked.
The administrator's connection uses the Secure Shell (SSH) protocol and differs from the other protocols in that a direct connection through the SSH port is allowed (that is, no SSH proxies). This allows the address of the administrative server to leave the internal network. However, the firewall filter ensures that the SSH connection can go only to one of the DMZ servers. This use of cryptography provides message secrecy and integrity as well as strong (cryptographic) authentication of the endpoints.[38] Because the requisite public keys are embedded into the system when SSH is configured, the issue of an infrastructure for public key distribution[39] is finessed.
The access allowed to system administrators violates the principle of least privilege,[40] because the connection allows the administrators full control over the DMZ systems. Several precautions ameliorate this violation. First, if the connection to the systems in the DMZ does not originate from a special system in the internal network (dubbed the “administrative server”), the firewall will disallow the connection. Second, the Drib trusts its system administrators, so only trusted users will be allowed unrestricted access to the DMZ servers. Third, the administrators can use the SSH protocol only to connect to the DMZ servers, and all administrative traffic is protected using SSH. This means that an attacker would not only have to spoof the internal network host addresses, but also find the correct set of cryptographic keys. Although not perfect, these precautions reduce the risk of compromise.
Four servers reside in the DMZ. They are the mail, WWW, DNS, and log servers. We will discuss these servers separately.
The mail server in the DMZ performs address and content checking on all electronic mail messages. The goal is to hide internal information from the outside while being transparent to the inside. When the mail server receives a letter from the Internet, it performs the following steps.
The mail proxy reassembles the message into a set of headers, a letter, and any attachments. The attachments are assembled into their native form (not the form used to transmit them through electronic mail). This allows the mail server to work on the original mail, as opposed to a packetized form of the letter. It simplifies the checking.
The mail proxy scans the letter and attachments, looking for any “bad” content. “Bad” content here is defined as a computer virus or known malicious logic. The attachments are then restored to the form used to transmit them through electronic mail. The headers, the letter, and the attachments are rescanned for any violation of the SMTP specification. This is the basic content checking. Any binary data (which might indicate a buffer overflow or other attack) is weeded out, as are excessively long lines.[41] Although address lines are limited in length to 1,000 characters, the mail proxy will split them as needed to keep lines less than 80 characters long. The scanning also detects and eliminates known malicious logic (computer viruses and worms, logic bombs, and so forth). The analysis of content for malicious logic uses standard techniques.[42]
The mail proxy scans the recipient address lines. The addresses that directed the mail to the Drib are rewritten to direct the mail to the internal mail server. The DMZ mail server then forwards the mail to the internal mail server. This step forwards the mail to the Drib's internal network, on which it will be delivered. Identification is by host name and not user name,[43] because the mail server determines the identity of the correct host to forward the mail to on the basis of host name, not user name.
The procedure for sending mail out of the Drib is similar. All outgoing mail comes from the internal mail server. Steps 1 and 2 are the same (although the content checking in step 2 may be enhanced to detect keywords such as “proprietary”). But the sanitization for step 3 is different.
3′. The mail proxy scans the header lines. All lines that mention internal hosts are rewritten to identify the host as “drib.org,” the name of the outside firewall. All header lines must be checked. In addition to the source address lines, any “Received” lines are to be removed, and any destinations that name the Drib must also be changed. Following this sanitization, the letter is forwarded to the firewall for delivery. This step forwards the mail to the Internet after hiding all details of the Drib's networks. This idea comes from the principle of least privilege,[44] because those who do not need to know about the internals of the Drib's network do not get that information.
The primary goals of the mail server are to handle mail and to perform all needed checks and sanitization. This way, the firewalls only need to perform rudimentary checks (such as checks on line length and character type) and leave the detailed checking to the mail servers.
The DMZ mail server also runs an SSH server. This server is configured to accept connections only from the trusted administrative host in the internal network. This allows the system administrators to configure and maintain the DMZ mail host remotely (a great convenience) without unnecessarily exposing that host to compromise.
The Web server accepts and services requests from the Internet. It does not contact any servers or information sources within the internal network. This means that if the Web server is compromised, the compromise cannot affect internal hosts. Although the Web server runs CGI scripts, the scripts have been checked for potential attacks and hardened to prevent their success.[45] The server itself contains no confidential data.
The Web server also identifies itself as “www.drib.org” and uses the IP address of the outside firewall. This hides part of the DMZ configuration in accordance with the principle of least privilege[46] (because people outside the network need not know the address), and forces external entities to send Web traffic to the firewall.
A system in the internal network known as the “WWW-clone” is used to update the DMZ Web server. People authorized to update the Drib's Web page can access this system. Periodically (or on request), an administrator will copy the contents of the WWW-clone to the DMZ Web server (see Section 27.7.1). This follows from the principle of separation of privilege,[47] because any unauthorized changes in the Web server are mitigated by the updates. Like the mail server, the WWW server also runs an SSH server for maintenance and updating. The server provides the cryptographic support necessary to ensure confidentiality and data and origin integrity.[48]
The Drib accepts orders for its merchandise through the Web. The data entered by the consumer is saved to a file. After the user confirms an order, the Web server invokes a simple program that checks the format and contents of the file and creates an enciphered version of the file using the public key of a system on the internal customer subnet. This file resides in a spooling area that is not accessible to the Web server (see Exercise 3). The program deletes the original file. This way, even if the attacker can obtain the file, the attacker cannot determine the order information or credit card numbers associated with customers. Indeed, because the customer names are in the enciphered files, the attacker cannot even determine the names. Formally, not keeping valuable information online and in the clear follows from the principle of least privilege,[49] because the users of that machine are not authorized to read the data, and from the principle of separation of privilege,[50] because the cryptographic key is needed to read the data. Using public key cryptography means that only a public key need be on the DMZ Web server. This prevents an attacker from deciphering the data on that system should it be compromised, which is an application of the principle of fail-safe defaults.[51]
The internal trusted administrative server periodically connects to the Web server using the SSH protocol, uploads the enciphered order files, and transmits them to the appropriate system on the internal customer subnet. The SSH server on the Web server is configured to reject connections from any host other than the trusted internal administrative server, so an attacker cannot connect from outside (assuming the attacker is able to penetrate the outer firewall). The principle of denying unknown connections, rather than allowing them and then authenticating them, follows the principle of fail-safe defaults.[52]
The DMZ DNS host contains directory name service information about those hosts that the DMZ servers must know. It contains entries for the following.
DMZ mail, Web, and log hosts
Internal trusted administrative host
Outer firewall
Inner firewall
Note that the DNS server does not know the addresses of the internal mail server. The inner firewall will forward mail to that server. The DMZ mail server need only know the addresses of the two firewalls (for mail transfers), and the trusted administrative server. If the mail server knows the address of the DNS server, it can obtain these three addresses. This gives the internal network the flexibility to rearrange its host addressing. The DMZ DNS server must be updated only if the address of the internal trusted administrative host is changed.
The limited information in the DNS server reflects the principle of least privilege,[53] because those entries are sufficient for the systems in the DMZ.
The log server performs an administrative function. All DMZ machines have logging turned on. In the event of a compromise (or an attempted compromise), these logs will be invaluable in assessing the method of attack, the damage (or potential damage), and the best response. However, attackers can delete logs, so if the logs were on the attacked machines, they might be tampered with or erased.
The Drib has located a fourth server in the DMZ. All other servers log messages by writing them to a local file and then to the log server. The log server also writes them to a file and then to write-once media, which is a precaution in case some attacker is able to overwrite log files on both the target server and the log server. It is also an application of the principle of separation of privilege.[54]
The log system is placed in the DMZ to confine its activity.[55] It never initiates transfer to the inner network. Only the trusted administrative host does that, and then only if the administrators choose not to read logs by reading the media on which the logs reside.
Like the other servers, the log server accepts connections from the internal trusted administrative host. Administrators can view the logs directly, or they can replace the write-once media with another instance of the media and read the extracted media directly. The use of write-once media is an example of applying the principle of least privilege[56] and fail-safe defaults,[57] because the media cannot be altered; they can only be destroyed, and then only if the attacker has physical access to the system.
Each server has the minimum knowledge of the network necessary to perform its task. This follows the principle of least privilege. Compromise of the servers on these systems will restrict the transfer of information, but will not lead to compromise of the systems on the internal network.
Ideally, the operating systems of the server computers should be very small kernels that provide only the system support services necessary to run the appropriate servers. In practice, the operating systems are trusted operating systems (developed using assurance techniques,[58] or—more commonly—commercial operating systems in which all unnecessary features and services have been disabled. This minimizes the operations that a server can perform on behalf of a remote process. Hence, even if the server is compromised, the attacker cannot use it to compromise other hosts such as the inner firewall.
The use of proxies on the firewalls prevents direct connections across the firewalls. Moreover, the data passing through the firewalls can be checked and, based on the content, filtered or blocked. The only exception is the SSH connection from the internal network to the DMZ. The inner firewall checks the origination of the connection, to ensure that it comes from the internal administrative host, and the destination, to ensure that it goes to one of the servers.
The internal network may be organized in several ways. Each of the subnets may have its own firewall and its own server, and may filter traffic just as the inner firewall does. The subnets may share servers. If the primary goal is to guard the Drib's internal data from being stolen by an outside attacker, what goes on behind the inner firewall is irrelevant.
The Drib's policy imposes the opposite requirement. The subnets must guard against unauthorized access to information as dictated by the policy. For these purposes, “read” corresponds to fetching or retrieving a file, and “write” corresponds to putting or depositing a file. For the moment, we ignore electronic mail, updating of Web pages on the DMZ, and the internal administrative host.
The constraints on information flow[59] dictate the arrangement of the network. The firewalls impose the confinement [60] required at the interfaces.
The data and users are distributed among the three subnets of the internal network in the obvious way. The firewall on the developer network allows read access from the corporate network but blocks write access to all other subnets. The firewall on the corporate network does not allow read or write access from the other networks. The firewall for the customer subnet allows read access from the corporate network. It also allows write access for information placed by the public onto the DMZ Web server. However, the write access is constrained to be mediated only by the DMZ Web server and the inner firewall, so the public does not have unrestricted access. These firewalls may be proxy firewalls or filtering firewalls.
The internal mail server must be free to communicate with hosts behind each of the subnet firewalls. Either the subnet may have its own mail server, or the internal mail server can deliver mail directly to each host on the subnets. The former has the advantage of flexibility, because the internal DNS server need only know the addresses of the subnet firewalls and (possibly) the mail servers. Thus, other host addresses can be changed freely within each subnet. The latter requires the internal DNS to have the addresses of all hosts on the internal network, but is simpler to configure and maintain. Either arrangement will satisfy the Drib's policy.
In addition to the mail server, an internal Web server provides a staging area for the Drib's Web pages. All internal firewalls allow both read and write access to this server. (The server itself controls the specific access that individuals have to each Web page.) The DMZ Web server's pages are synchronized with the Web pages on this server by using the trusted internal administrative host. This provides a test bed for changes in the pages, so corporate and other internal personnel can review and approve changes before they are made visible to the public. Furthermore, if the DMZ Web server is ever compromised, the Web pages can be restored very quickly.
Finally, the trusted internal administrative server has strict access rules: only system administrators authorized to administer the DMZ systems have access to it. All connections to the DMZ through the inner firewall must use this server, except for the mail server and (possibly) the DNS server. The server itself uses SSH to access systems in the DMZ, and the DMZ servers recognize it as the only host authorized to access their SSH daemons. This prevents a user on the internal network from sending SSH commands from a local workstation to DMZ servers.
With respect to the internal network, the DMZ servers know only about the inner firewall's address and the trusted administrative host's address, by the principle of least privilege.[61] The DMZ servers never communicate directly with the internal servers. They instead send information to the firewall, which routes the messages appropriately. DMZ servers accept only incoming SSH connections from the trusted administrative host. These connections use public key authentication to establish identity,[62] so an attacker cannot forge addresses.
This arrangement is layered with checks. A single action affecting a host on the DMZ requires that several tests be passed (implementing the principle of separation of mechanism). Only a few administrators can alter or update systems on the DMZ. In general, the only data in the DMZ that nonadministrators can alter is the data in the Web pages. However, the alterations occur on a copy on the internal network. An administrator must invoke special functions to move the updated pages to the Web server on the DMZ.
The only data that is written from the DMZ to the internal network comes from customer orders, but the data so received has been checked for potential errors (or deliberately corrupt data), is enciphered, and is transferred to an internal machine in such a way that it cannot be executed. This applies the analysis techniques for analyzing existing systems[63] and developing systems with some level of assurance.[64] This again limits the ability of an attacker to use this data to attack systems on the internal network.
All of the defenses discussed above depend on software that has been written defensively. This is particularly true of software on the firewalls. Although the amount of software running on the firewalls is minimized, and the software is written to perform only necessary functions and has been extensively audited and tested, the Drib defensive mechanisms all trust that the software is correct and cannot be compromised. If this trust is misplaced, the defensive mechanisms can be breached. This is another reason why the configuration of servers and firewalls is based extensively on the principle of separation of mechanism. If one mechanism fails, another may prevent the attacker from exploiting that failure.
A similar remark applies to hardware. Suppose the network interface card connected to the Internet never cleared its buffer. An attacker could craft a packet that contained data of the form of a legal packet addressed to an interior system. The containing packet would be validated as allowed to go to the interior network and then would be passed to the interior network. The next packet would be short enough to overwrite the contents of the buffer from the beginning up to the data in the form of the valid packet. If the card then flushed the contents of its buffer to the inside network, the legal but unvalidated packet would be sent on, too. (See Exercise 2.) The separation of mechanism inherent in a proxy firewall hinders attacks based on failures in single network cards, but other types of malfunctions may allow other attacks.
Assurance at all levels is important. Here, the informal policy model of the Drib (see Section 26.2) guides the design of the network architecture as well as the analysis of the software and hardware configurations. Infrastructure, software, and hardware all provide the basis for claims that the network actually enforces the policy model correctly.
The availability component of the Drib's policy requires that the systems must be available to the public and to Drib personnel. This means that access over the Internet must be unimpeded. We consider this in the context of flooding attacks, in which attackers attempt to overwhelm system resources.
The SYN flood is the most common type of flooding attack. It occurs when incoming connections repeatedly refuse to execute the third part of the TCP three-way handshake (see page 762). This is a denial of service attack. If the packets come from multiple sources but have the same destination, this is an example of a distributed denial of service attack. The source address of these SYN packets is typically set to some unreachable host. This prevents the third part of the handshake from being executed, and prevents the attacked systems from determining the attacker by reading the source address from the SYN packet.
In what follows, the term “legitimate handshake” refers to a connection attempt that is not part of a SYN flood. If the client in a legitimate handshake receives the SYN/ACK packet from the server, it will respond with the appropriate ACK to complete the handshake and begin the connection. The term “attack handshake,” on the other hand, refers to a connection attempt that is part of a SYN flood. The client in an attack handshake will never send an ACK packet to complete the handshake. A critical observation is that the server cannot distinguish between a legitimate handshake and an attack handshake. Both follow the same steps. The only difference lies in whether the third part of the handshake is sent (and received).
There are two aspects of SYN flooding. The first is the consumption of bandwidth. If the flooding is more than the capacity of the physical network medium, or of intermediate nodes, legitimate handshakes may be unable to reach the target. The second is the use of resources—specifically, memory space—on the target. If the flooding absorbs all the memory allocated for half-open connections, then the target will discard the SYN packets from legitimate handshake attempts.
We focus on the second aspect, because the first involves infrastructure elements not under the control of the Drib. First, we consider defenses that do not involve the target system. Then we examine the target system.
This approach tries to reduce the consumption of resources on the target by using routers to divert or eliminate illegitimate traffic. The key observation here is that the SYN flood is handled before it reaches the firewall, at the infrastructure level. The goal is to have only legitimate handshakes reach the firewall.
An alternative is to have a system monitor the network traffic and track the state of the three-way handshake.
The problem with these techniques is that they simply push the focus of the attack back from the firewall onto infrastructure systems on the outside of the Drib's network. They do not solve the problem, but they may ameliorate it sufficiently to allow some legitimate connections to reach their destinations.
This approach springs from the way in which most TCP servers are implemented. When a SYN packet is received, the server creates an entry in a data structure of pending connections and then sends the SYN/ACK packet. The entry remains until either a corresponding ACK is received or a time-out occurs. In the former case, the connection is completed; in the latter case, a new entry for the next SYN packet is created. Under a SYN flood, the data structure is kept full of entries that never move to the connected state. All will be timed out, and new SYNs create new entries to continue the cycle.
The data structure contains the state of the pending connection. This information typically includes the source IP address, a sequence number, and other (internal) information. When the client replies with an ACK packet to complete the handshake, the server uses this information to verify that the ACK packet corresponds to the initial SYN packet. The SYN flood succeeds because the space allocated to hold this state information is filled before any three-way handshakes are completed. Legitimate handshakes cannot obtain space in the data structure. However, if legitimate handshakes can be assured space, to some level of probability, then legitimate handshakes have a probability of successfully completing even in the face of a denial of service attack.
Two techniques are used to make availability of space more likely. The first is to push the tracking of state to the client. For example, if the state can be encoded in the initial sequence number of the ACK, the server can rederive the information from information in the client's ACK packet. Then no state needs to be kept on the server system. This approach is called the SYN cookie approach.
The second technique assumes that there is a fixed amount of space for the state of pending connections. A SYN flood causes attack handshakes to fill this space. After some constant amount of time (usually 75 seconds), the server deletes the state information associated with the attack handshake. This is called the “time-out” of the pending connection. This approach simply varies the times before the time-outs depending on the amount of space available for new pending connections. As the amount of available space decreases, so does the amount of time before the system begins to time out connections. This approach is called adaptive time-out.
Both of these techniques improve the resilience of systems in the face of flooding attacks. The first technique changes the allocation of space for pending connections by trading the space used to store the state information of pending connections for extra computations to validate the states of incoming ACKs. The second method times out pending connections quickly to make more space available for the incoming handshakes.
In spite of the measures outlined above, the Drib security officers realize that their network and systems might be compromised through unanticipated means. They have taken steps to prepare for, and handle, such attacks.
The extensive logging described above is one step. The DMZ log server contains an intrusion detection mechanism that scans through the logs looking for evidence of known attacks and of anomalous behavior. The reasons, and settings, are bound in the Drib's philosophy of defense.
The Drib security officers are aware of the multitude of attacks that can be launched against networks and systems. They expect these attacks to come from the Internet against the outer firewall. If the attacks are stopped by the firewall, they are logged and ignored. For example, should someone attempt a known buffer overflow attack against the SMTP mail proxy, the proxy will reject the attack, log the attempt, and continue to function. The security officers will not pursue the attacker, and are interested in the attack only as a statistic they can use when higher management asks them to justify their budget, or when they are training new system administrators in security procedures and techniques.
However, should the SMTP proxy be attacked successfully, the Drib's security officers will be very interested. At that point, the SMTP mail proxy will cease to function as a mail proxy. Instead, it will start nonstandard programs (such as a command interpreter or some other program that gives the attacker access to, or information about, the system). At this point, the anomaly detection component of the intrusion detection mechanism will detect the unusual behavior and report a potential problem. The Drib's security staff monitors the intrusion detection system around the clock, so they can act quickly on such reports.
The Drib's security officers are very interested in attempted attacks within the DMZ. Unlike the Internet, where attack tools are commonplace, use of the DMZ is restricted only to those who have access to the internal administrative trusted host or who are using a small set of services. If a known attack occurs on this network, someone who has obtained access to the network has launched it. This means that some trusted administrator should not have been trusted (entry through the administrative trusted host), that one of the servers on the firewall has been compromised (entry through the outer firewall), or that the software on the DMZ systems either is corrupted (already in the DMZ) or does not restrict actions sufficiently tightly (entry through the DMZ Web or mail server). Hence, network traffic is monitored using both anomaly and misuse detection methods, and all attempted compromises are reported.
The philosophy of ignoring attacks that fail seems dangerous, because when an attacker succeeds in compromising the system, the attacker probably has tried—and failed—numerous times before. Although this is true, the Drib's answer is, “So what? We do not have the personnel to handle the false alarms and the failed attacks. Instead, we focus on what we are most concerned about: successful attacks, and failed attacks in areas where attacks ought not to be launched. A failed attack within the DMZ tells us that someone or something is acting in a forbidden way and that some compromise has occurred. But a failed attack from the Internet tells us that someone may have found a new attack script and used us as the target. We put our efforts where we can obtain useful results.”
Finally, the Drib security officers analyzed many commercial intrusion detection systems to find one that met their needs. All reported many false positives. Some even failed to detect attacks launched by the security officers. The Drib therefore purchased an intrusion detection system that allowed them to add signatures of known attacks and to tune parameters to control reporting of events. After considerable experimentation, they found a group of settings that seemed to work well. To verify this, every month the Drib security officers select two 1-hour periods at random and analyze the logs for attacks, probes, and other nefarious events. The results of the analysis are compared with the reported events. If they match, the current set of settings is accepted; if not, the settings are retuned.
This chapter demonstrated how to develop a network infrastructure from security requirements. The security goals led directly to the development of a security policy, which in turn suggested the form of the network. One firewall limits the types of traffic to public servers; the other firewall blocks all external traffic from reaching the innermost portions of the corporate network. The servers available to the public are dedicated systems that provide only one service. The firewalls are application level firewalls, so they can check the contents of any connection. Finally, meeting the availability policy requirements led to a discussion of defenses against attackers using SYN floods to prevent legitimate connections accessing the publicly available servers.
Distributed denial of service (DDoS) attacks are insidious and difficult to handle. Research into handling them, as well as tracing them, focuses on both the end system and the infrastructure. One difficult problem is to distinguish between an attack and a large number of attempted connections over a short period of time; the effect is the same, but the response may need to be different.
The dissonance between policy and implementation means that systems often do not enforce the stated policy. Policies include procedural issues, some of which cannot be enforced by technical means. However, the host and infrastructure systems should be configured to implement those parts of the policy that can be enforced by technical means. An automated method of deriving settings for a system from a given policy would reduce the inconsistencies and provide a higher degree of assurance that the site enforces those aspects of the policy correctly. Conversely, many sites do not have a clear policy for controlling access to their networks. Application of reverse engineering techniques to deduce the actual policy that the configurations of the systems support, and expression of that policy in a clearly understood manner, also constitute a deep research problem that involves not just technical analysis but also human factors. The elements of policy languages are critical to both of these problems.
The structure of the network architecture resembles that of a medieval fortress: a single gateway to the outside world, an outer keep (the DMZ) in which people from outside the fortress may enter for limited purposes, and an inner keep, in which the inhabitants of the fortress dwell. This structure ignores the historical problem of the frailty of medieval fortresses, and can be attacked in the same way—through an insider. The problem of defending systems from unauthorized access is simpler than defending them from unauthorized acts by authorized users. This “insider problem” suggests a different approach. The skin of the human body is designed to protect people from certain bacteria, but if the skin is breached (through a cut, or through breathing in bacteria or viruses), the body responds with antibodies. Perhaps this could be extended to a network architecture other than the one shown here. How to do this is a research question, and how to do it effectively involves not only technical considerations but also human factors.
Many books and papers describe firewalls and the design of network infrastructures that use them. Lodin and Schuba [643] describe the basic use of firewalls. Frantzen, Kerschbaum, Schultz, and Fahmy [370] discuss the structure of a firewall in order to shed light on possible vulnerabilities. Bellovin and Cheswick [75], and Zwicky, Cooper, and Chapman [1075], discuss the principles of firewalls. Ranum and Avolio [829] have created an early applications layer firewall. Chapman [181] describes an early packet filtering firewall. Schuba and Spafford [894] have created a reference model for firewalls. Epstein, Thomas, and Monteith suggest using wrappers to prevent attackers from exploiting security holes in proxies on firewalls [332]. Mayer, Wool, and Ziskind [667] have developed a tool for examining the policy enforced by a firewall.
Virtual Private Networks (VPNs) build virtual infrastructures on existing infrastructures. They are ideal for corporations with geographically distributed offices, or when telecommuting is used. Several books discuss their creation and management [592, 801, 896]. Caronni, Kumar, Schuba, and Scott present a layering approach to VPNs that hides the existing infrastructure [175].
Web commerce and security uses principles and practices that are common to other systems in which security is desired. Several authors [383, 855, 966] have described the issues and approaches specifically in terms of the Web and electronic commerce.
1: | Suppose a new class of users, the system security officers (SSOs), were to be added to the access control matrix discussed in Section 26.2.2. Augment the matrix with the change right. This right allows the user to alter the classes of other users in that category. For example, if user Amy had change rights over the class “developers,” she could change the class of user Tom, who is currently in the “developers” class, to any of the other four classes.
|
2: | Assume that an attacker has found a technique for sending packets through the outer firewall to the DMZ without the packets being checked. (The attacker does not know the internal addresses of hosts in the DMZ.) Using this technique, how can the attacker arrange for a packet to be sent to the WWW server in the DMZ without the firewall checking the packet? |
3: | Consider the scheme used to allow customers to submit their credit card and order information. Section 26.3.3.2 states that the enciphered version of the data is stored in a spooling area that the Web server cannot access.
|
4: | The organization of the network provides a DMZ to which the public has controlled access. This follows the principle of least privilege, as noted in Section 26.3.3.5. For each of Saltzer and Schroeder's other design principles [865] (see Chapter 13), explain how the principle is relevant to the creation of the DMZ. Justify your answer. |
5: | A security analyst wishes to deploy intrusion detection monitors to determine if any attackers penetrate the Drib's network.
|
6: | The Drib has hired the computer security firm of Dewey, Cheatham, and Howe to audit their networks. The analyst from DC&H arrives and produces a floppy disk. She states that the disk is to be loaded onto a system on the internal network. She will then run the program. It will scan the Drib's networks and send the information to DC&H's headquarters in Upper Bottom. There, DC&H analysts will determine whether the Drib's security is acceptable, and will recommend changes.
|
7: | This exercise asks you to compare an SMTP server such as sendmail with an SMTP proxy for an application level firewall. Your answers should assume that the questions refer to the Drib's network.
|
8: | Suppose the Drib wished to allow employes to telecommute. In order to protect the network, they require all remote connections (other than those for the Web and mail servers) to use SSH.
|
9: | Consider the first example in Section 26.4.1.
|
10: | The Linux system uses the SYN cookie approach discussed in the first example in Section 26.4.2, with one modification. The maximum segment size (MSS) is sent as part of the initial SYN. This value must be encoded in the sequence number so that the state can be properly reconstructed when the ACK arrives. The MSS used is three bits. The Linux system simply adds it to the SYN cookie shown in the example. How does the system recover the MSS from the ACK's sequence number? |
[1] See Section 13.2.1, “Principle of Least Privilege.”
[2] See Section 13.2.5, “Principle of Open Design.”
[3] See Section 13.2.6, “Principle of Separation of Privilege.”
[4] See Section 13.2.1, “Principle of Least Privilege.”
[6] See Section 4.4, “Types of Access Control.”
[9] See Section 6.3, “Lipner's Integrity Matrix Model.”
[10] See Section 13.2.6, “Principle of Separation of Privilege.”
[11] See Section 14.4, “Groups and Roles.”
[12] See Section 18.1.2, “The Role of Requirements in Assurance.”
[13] See Chapter 18, “Introduction to Assurance.”
[14] “DMZ” stands for “demilitarized zone.”
[15] For example, see the Secure Mail Guard (Section 16.5.2). The guards discussed here are called “firewalls” (see Section 26.3.1).
[16] See Chapter 16, “Information Flow.”
[17] See Chapter 23, “Vulnerability Analysis.”
[18] See Chapter 16, “Information Flow.”
[19] See Chapter 15, “Access Control Mechanisms.”
[20] See Section 15.1, “Access Control Lists.”
[21] See Chapter 24, “Auditing.”
[22] See Section 25.6, “Intrusion Response.”
[23] In classless IP terminology, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
[24] See Section 13.2.1, “Principle of Least Privilege.”
[25] See Definition 17–1.
[26] See Section 13.2.4, “Principle of Complete Mediation.”
[27] See Section 13.2.6, “Principle of Separation of Privilege.”
[28] See Section 13.2.7, “Principle of Least Common Mechanism.”
[29] See Chapter 15, “Access Control Mechanisms.”
[30] See Chapter 16, “Information Flow.”
[31] See Chapter 16, “Information Flow.”
[32] See Section 5.2, “The Bell-LaPadula Model.”
[33] See Section 15.1, “Access Control Lists.”
[34] See Section 13.2.3, “Principle of Economy of Mechanism.”
[35] See Section 13.2.6, “Principle of Separation of Privilege.”
[36] The description here is vague out of necessity. Whether or not such a method exists, and how to exploit it, are properties of individual hosts, software, and vendors. The curious reader is invited to use the Flaw Hypothesis Methodology (see Section 23.2.4) to analyze his or her organization's firewall after obtaining written permission from the responsible officials.
[37] See Section 13.2.2, “Principle of Fail-Safe Defaults.”
[38] See Chapter 9, “ Basic Cryptography,” and Chapter 11, “Cipher Techniques.”
[39] See Section 10.4, “Cryptographic Key Infrastructures.”
[40] See Section 13.2.1, “Principle of Least Privilege.”
[41] See Chapter 23, “Vulnerability Analysis.”
[42] See Section 22.7.4, “Malicious Logic Altering Files.”
[43] See Section 14.6.1, “Host Identity.”
[44] See Section 13.2.1, “Principle of Least Privilege.”
[45] See Chapter 23, “Vulnerability Analysis,” and Chapter 29, “Program Security.”
[46] See Section 13.2.1, “Principle of Least Privilege.”
[47] See Section 13.2.6, “Principle of Separation of Privilege.”
[48] See Chapter 9, “Basic Cryptography,” and Chapter 11, “Cipher Techniques.”
[49] See Section 13.2.1, “Principle of Least Privilege.”
[50] See Section 13.2.6, “Principle of Separation of Privilege.”
[51] See Section 13.2.2, “Principle of Fail-Safe Defaults.”
[52] See Section 13.2.2, “Principle of Fail-Safe Defaults.”
[53] See Section 13.2.1, “Principle of Least Privilege.”
[54] See Section 13.2.6, “Principle of Separation of Privilege.”
[55] See Chapter 17, “Confinement Problem.”
[56] See Section 13.2.1, “Principle of Least Privilege.”
[57] See Section 13.2.2, “Principle of Fail-Safe Defaults.”
[59] See Chapter 16, “Information Flow.”
[60] See Chapter 17, “Confinement Problem.”
[61] See Section 13.2.1, “Principle of Least Privilege.”
[62] See Section 9.3, “Public Key Cryptography,” and Section 14.6.1, “Host Identity.”
[63] See Chapter 23, “Vulnerability Analysis.”
[65] Specifically, the number of connections that have completed the TCP three-way handshake but are awaiting an accept system call from the process.