Security System Concepts

When designing a security system, it is helpful to segment your major domains of trust with choke points to control access. This section defines domains of trust and choke points and goes on to describe the security roles of the three different layers described in the preceding section.

Domains of Trust

Within all networks, there are devices with differing levels of value and differing levels of attack susceptibility. This concept is discussed in Chapter 2, "Security Policy and Operations Life Cycle." By combining these factors, you can start to define the relative attention needed for a given information asset. In a flat network, as shown in Figure 12-7, the security of these assets is left completely up to the applications.

Figure 12-7. Flat, Untrusted Network

As you can see, there is no segmentation except where necessary (WAN connections). All users and servers share the same network, and any required access control is expected to be done by each host. Some network security functions are possible, such as NIDS or VLAN ACLs, but this is not commonly done in a design with this topology. Although some networks are still designed this way, the vast majority opt for some basic segmentation.

Segmentation can be done for several reasons. When one of those reasons is security, you are creating domains of trust. If you are segmenting the network for performance or scalability reasons only, you are just creating more segments but still have one domain of trust. Figure 12-8 shows the topology from Figure 12-7 mapped into a possible set of trust domains.

Figure 12-8. Domains of Trust

Depending on the size of the network, your security policy, and the decisions you make regarding your security system, you might have dozens of security domains or only a few. A domain of trust in network security is created to segment information assets with certain trust, value, and attack risk from one another. This allows the topology of the network (physical or logical) to help enforce your security policy. Typically, a domain of trust contains more than one system but not always. Often a domain of trust contains both clients and servers at a particular trust level, but there are exceptions. For example, in Figure 12-8, the external server is considered at a different trust level than its users (the Internet at large). The following are several common domains of trust, all from the perspective of the primary location for an organization:

• Internet
• Public servers
• Business partners (connected by WAN or VPN)
• WAN
• Remote sites (WAN or VPN)
• Remote users (dial-up or VPN)
• Basic internal network (users and servers)
• Department-specific network (users and servers)
• Management network
• E-commerce network (with subdomains based on application trust)

Each of these domains can overlap with one another. For example, although members of the finance group clearly need special access to the finance servers, they also need the same level of rights afforded to other users for basic system access (e-mail, Internet access, and so on).

Domains of Trust and Network Design

Although it is easy to define domains on paper, in your own network you will find that trade-offs must be made. Your network, and its users, very rarely falls into obvious and nonoverlapping categories. In addition, if your network was designed purely from a security standpoint, it might not function very well in terms of performance, application support, and general usability. As an example, consider an access-control-centric design for a campus network, as shown in Figure 12-9.

Figure 12-9. Security-Centric Campus Design

Here you can see seven different domains of trust defining the network topology. Security devices aren't put in place, but it is assumed that they exist at the points between trust domains (more on this in the following "Choke Points" section). Although it is possible to design your network as shown in the figure, there are several caveats:

• User mobility The design in the figure assumes that each user will always be in one location. What if users are spread across several buildings (or cities)? What if users must work from other locations temporarily? Standard 802.1x (Chapter 9, "Identity Design Considerations") can mitigate this issue somewhat, but for many networks it isn't yet viable.
• Network backups With server resources spread across several segments, how are you going to back up these systems on a regular basis? Without separate backup systems or a lot of VLAN trunking, chances are you're not.
• Intradomain access control If you decide to limit the access to a server resource within a domain, how do you do it without deploying more hardware? If you must do this in several different domains, how does this scale in terms of cost and management expense? The network shown in Figure 12-9 looks a lot like several small networks, each with its own management and equipment.

Depending on the applications and network size, there are a dozen or more additional considerations for such a design. As has been touched on throughout this book, there is a trade-off between security and usability. In domains of trust, the same idea holds. The more rigid you are on domain definitions and topology, the less usable and manageable your network will be. To make sound design decisions, you must consider the impact of your security decisions on the surrounding network. Figure 12-10 shows a similar design, balanced to consider the three factors previously listed as concerns.

Figure 12-10. Balanced Domain of Trust Campus Design

The following list details how the concerns of the previous design are addressed in Figure 12-10:

• User mobility All users are in a central location and are not distinguished from one another at the network level. This puts more responsibility on the applications to securely authenticate users but allows for user mobility. User segmentation, if needed for network scalability reasons, can be based on physical location only, with all hosts residing in the same domain of trust.
• Network backups All the internal server systems are connected to the same switch. By using a technology such as private VLANs, you can segment the access on that switch to the different departments. A network backup system could still be used in this location to gain access to all the servers in the same way that the router can gain access to all the servers. When using private VLANs, for example, set the network backup system as an additional promiscuous port.
• Intradomain access control Because only server resources are contained in the individual department domains, any amount of access control can be put on the connection between the domains.

The extent to which you can make compromises in security to benefit usability or management has a lot to do with the disparity in trust of the domains involved. In Figures 12-8 through 12-10, the domains that were adjusted to increase usability and manageability were already fairly close to one another in terms of trust. Although moving the external server onto the same switch that the other servers are on in Figure 12-10 might make backups easier, the impact from a security perspective is too great. This concept comes up again in the following section.

Domains of Trust Recommendations

When creating domains of trust, you should put resources with similar trust, asset value, and attack profile into similar locations on the network. Attack profile includes not only the likelihood of a system being attacked (as discussed in Chapter 2) but also the likelihood of a system attacking someone else. This outbound attack profile can adjust the trust level you have for a domain. For example, a public web server might have a high asset value, a high chance of successfully being attacked, and (because of the high chance of attack) a high chance of attacking others. This is the primary reason it is separated from the other servers in Figure 12-10. Other servers internally have a high asset value as well but are not as likely to be attacked or to attack others. This attack profile is also modified by the application and host security controls in place. Again, your security policy should drive most of these decisions.

Choke Points

In the previous section, all the L3 interconnections in each design were made by using basic routers. In today's designs, you have L3 switches and firewalls as other potential interconnection points. In addition, technologies such as IPsec, NIDS, and content filtering can help define the boundaries between these domains of trust. The combination of hardware and software that makes up a network transit point between two domains of trust is called a choke point.

Deciding which choke point is appropriate for a given trust boundary is a critical element in secure network design. Choosing too weak a security control devalues the creation of the trust domains to begin with. Choosing too strong a control adds capital, management, and usability costs that might not be justified.

One of the easiest ways to start down this decision process is to consider the trust delta (or difference) between the two domains. Figure 12-11 shows a simplified version of the domains of trust shown in Figure 12-8. Here only three domains are represented.

Figure 12-11. Three Domains of Trust

All three domains must be connected to one another. The data center should reach the Internet by way of the campus LAN. Looking at the trust levels of the domains, you see that the Internet is completely untrusted, the campus LAN is fairly trusted, and the data center is highly trusted. When deciding which choke point technology to use, start by considering this delta and then evaluate the direction of the traffic flows.

The campus LAN connection to the Internet requires the most security. The trust delta is high, but the Internet as a resource is valuable to the campus LAN. Therefore, campus LAN traffic must be able to use resources in the Internet domain. To limit the return traffic from the Internet and lessen the risk of attack, a stateful firewall should be deployed. In addition, NIDS should strongly be considered to check traffic coming from the Internet into the campus.

The connection between the campus LAN and the data center has a much smaller trust delta. In this case, the existing routers could be configured with stateless ACLs to filter the types of traffic coming in to specific servers. The addition of NIDS might not be necessary. Figure 12-12 shows the resulting topology.

Figure 12-12. Three-Domain Security Design

WARNING

The examples in this section of the chapter are making assumptions that might not apply to your own network. For example, you might run a network in which the campus LAN is almost as untrusted as the Internet. (Some university networks fall into this category.) In this case, the security you might need for your internal servers could be quite a bit more than that discussed here. Your security policy should be driving a lot of these decisions combined with the proper categorization of your various domains of trust.

As a general rule, the restrictive elements of a choke point should apply to traffic flowing from the lower trust level to the higher. Resources at a higher trust level should usually be allowed to communicate with lower trust levels. This doesn't always apply, however; it sometimes makes good sense to limit access from higher to lower trust levels, particularly when such communication isn't necessary. This is the case for recommendations made earlier in this book to limit the outbound access of your Internet-facing servers. Additionally, as is the case with NIDS at an Internet perimeter, it is sometimes useful to limit traffic from a higher trust level to a lower trust level to limit outbound attacks. The NIDS can help spot infected hosts within your campus LAN that are attempting to attack resources on the Internet.

I wish there were some hard science here to tell you exactly what to do, but there isn't. The best you can do is evaluate your own network and policies against the information you learn in this book and make some decisions. Besides, if it were hard science, would it be very much fun? This lack of a clear right answer is part of the reason testing, validation, and compliance auditing are so important in secure networking. No one spends time testing to ensure that 2 + 2 really is 4.

Security Roles: Access/Edge, Distribution, Core

On a note related to domains of trust and choke points, each of the three layers of network design discussed earlier has different potential security roles to play. A stateful firewall has a role to play in the access or distribution layer but usually not the core. Table 12-1 shows where the technologies discussed so far in this book are most commonly applied. Technologies can fall into core, distribution, or access layers, and some technologies are common in more than one area. In addition, some entries in the table are not technologies but rather best practices (BPs) as discussed throughout the book.

As you can see, the core has a very small role to play in overall secure networking. This is primarily because, by the time the traffic gets to the core, all the security controls should have already been applied. Depending on the network topology, some of the technologies listed in these categories might not apply where they are listed. Don't think of this as a rigid list but rather as a guideline to consider when deciding on the placement of a given security control. This list also changes depending on the type of access or distribution layer you are securing. For example, the access layer column in Table 12-1 contains nearly every security area because the access layer can contain a diverse set of resources. If you were securing the L2 access layer of your user PCs, the list of technologies at the access layer might look like this:

• Identity technologies
• Host and application security
• Crypto
• Network device hardening
• OS hardening
• Application hardening
• Rogue device detection
• Physical security
• L2 security BPs

All of the L3 controls are removed, as are technologies for attacks which probably do not apply in this location of the network.