Segment Your Network

You have probably already heard the term network segmentation and understand the technical underpinnings of network segmentation. Network segmentation is the process by which we divide the network into logical groupings to protect pieces of the network from each other. Network segmentation is often a physical segmentation where we put one piece of the network on one physical infrastructure and another piece of the network on another physical infrastructure. Of course, that would mean the two pieces cannot talk to each other, so we have to put linkages in between (i.e., break our segmentation). Those linkages are sometimes created with routers, sometimes with VLANs. We are not enamored with the idea of using VLANs for network segmentation. It is fine in a test environment, but in a production environment, VLANs are too fragile. They depend on a solid build of the OS that runs the switches, one with no bugs in it. Switches and routers are running software, too, and they have vulnerabilities as well. Hardware has vulnerabilities, too, as the sidebar on the topic explains.

Hardware Vulnerabilities

When we originally wrote this chapter (late April 2004), the Common Vulnerabilities and Exposures (CVE) project listed 44 vulnerabilities containing the terms Cisco and IOS . Later in 2004, someone stole Cisco's source code and auctioned it off to the highest bidder. Although having source code does not help a whole lot in finding vulnerabilities, it lowers the bar for developing exploits. Also, in March 2004, a "security research" group (i.e., a group that publishes vulnerabilities, and often exploits for them, in the "public interest") released an exploit toolkit for Cisco IOS. The toolkit allows an attacker to choose between a number of exploits ranging from a denial-of-service exploit to remote escalation-of-privilege exploits. Of course, all the other hardware vendors have vulnerabilities, too, but Cisco's is most widely used, and therefore, most widely analyzed , giving us a more accurate understanding of the vulnerability profile. In a sense, Cisco is the "Microsoft" of hardware; they cannot afford to be as good as everyone elsethey must be better. This highlights that anything that runs software, including hardware, is under research and attack.

Clearly, relying on the network infrastructure as a protective measure should only be done if you understand the risks to that network infrastructure and treat it as a valuable asset to protect just like any other.

Chapter 8 explained that more-sensitive systems must never depend on less-sensitive systems for their security. The goal of network segmentation is to create virtual walls within your network, across which no dependencies may transit. At a high level, this may look like Figure 9-1. For a realistic network, it gets a bit more complicated. We start out by taking the model shown in Figure 9-4 and abstract it a bit. Then we add information on the types of traffic needed between systems in the network. This yields a picture such as shown in Figure 9-6.

Figure 9-6. Start segmentation by abstracting and annotating our DFD.

This picture highlights some clear groups of systems within the network. For example, it is clear that Web farm 1 and SQL cluster 1 need to communicate with each other, but there is no communication necessary between either of those systems and Web farm 2/SQL cluster 2. This is fairly obvious actually if you consider that those systems are essentially different properties. Each of those groupings form a "pod" of systems, which may be segmented to enforce the natural divisions within the network. If no communication needs to happen between systems, we can put them on different segments, particularly if they have differing security requirements. For instance, pod 1 may be the Human Resources system and pod 2 may be the Order Entry system.

Are Clusters One or Multiple Systems?

Clusters obviously consist of multiple systems, that is the whole point of clusters. However, a threat model is not directly concerned with individual systems. Often it makes sense to group systems together. Clusters is one such instance. To the outside, the members of the cluster appear to be a single system, hence we model them as a single system on the threat model. Should you want to dig deeper into your threat model, you may of course create a deeper-level diagram and model each system in the cluster as a separate process, and analyze their needs vis-  -vis each other as well as other systems.

The same actually holds for clients. From the point of view of servers, most clients are essentially identical (read " hostile "). In other words, if you are modeling a server network, you could probably consider all the clients as a single external entity. However, if you want to model the clients and reduce their dependencies on each other, you could consider making a simplified model of them and evaluate what types of relationships they really have with each other.

The initial segmentation is not complete, however. There are transitive dependencies to account for. For instance, both pods need to speak to the domain controller and the Terminal Server, as well as to clients on the Internet. Obviously, clients on the Internet are not part of any of our segmentsthey are part of the "horrible unknown," which receives no implicit trust at all. The DCs are similarly interesting. Segments are mutually exclusive, so a system cannot be part of more than one segment at the same time. In fact, the DCs are really their own segment. Think of it this way: The DCs hold the keys to the kingdom. Their compromise means the compromise of all systems in the network. Therefore, they clearly have the highest sensitivity. It may be useful here to assign a numeric sensitivity level to the segments. The DC segment, for example, may get 100, whereas pod 1 gets 95 and pod 2 gets 80. The numbers are really arbitrary, and we only use them to get relative measures. After we understand more about the segments, we can break the diagram apart and model each segment with trust boundaries, as shown in Figure 9-7.

Figure 9-7. During segmentation we annotate the diagram with trust boundaries.

A trust boundary is essentially the definition of a segment; it defines the segment border. Systems inside a trust boundary all have the same general security requirements and can be treated collectively. Systems outside the trust boundary are part of a different segment and need to be protected from all lower-level segments. In Figure 9-7, this is highlighted by the fact that the domain controller is not part of the segment that contains pod 1; it needs to be protected from that pod.

After you have created the logical segmentation, you must implement it. That happens in the restriction stage