Security System Concepts

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.

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.

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.

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.

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.

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.

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.