It’s not enough for a network just to get packets from here to there. Networks, in some sense, bear some responsibility for the epidemic of cybercrime: networks have enabled instant global connectivity, but they have also allowed instant global threats to come into your home or workplace. Networks need to be designed so that they enhance overall security, rather than contribute to the problem.
It is simply a fact of life that operating systems and applications will always have flaws that can be exploited by malicious actors. Software is getting more complex, straining the abilities of us humans to comprehend it. The rate of new software vulnerabilities discovered each month is not going down, it is increasing. If you’re hoping for the day when operating systems and applications are bug-free, forget it. We live in a world of vulnerable software and increasing connectivity, and your systems will always be exposed to potential attackers. The fact is, your networks will get attacked, and your users will be compromised.
So we, as network engineers, need to do more. I don’t mean add more firewalls or IDSs or other “security” devices, although they’re certainly helpful. We need to design networks that actively defend against network attacks. It’s been said many times before, but this design principle bears repeating: networks need to be designed with security in mind, and not as just an afterthought. Most networks are designed for performance, redundancy and administrative ease. Security is one of the last qualities to be considered, and it is almost always applied piecemeal – without a consistent plan.
You have all heard of and probably have even used the phrase “hard and crunchy on the outside, soft and chewy on the inside,” to describe the security posture of many networks. The candy metaphor may be a bit overused, but it is still accurate because it describes how network security is often applied: to the edges of the network only, leaving the internal network components subject to attack (soft and chewy). Remember, if an attacker is able to compromise one workstation on the internal network, he essentially becomes an “internal” hacker, and all your edge defenses are for naught. To build an effective secure network, security has to be included in all points of the network, by enforcing security policy throughout the network, not just at the edges.
How does a secure network defend against attacks? Richard Beijtlich has some useful blogs on this subject. Principally, in two ways:
- By limiting what can be attacked, improving the odds of detecting attacks, and it facilitating the containment and eradication of compromises.
- By providing information that can indicate that an attack took place (or is taking place). By providing evidence of network activities and events (or, just as importantly, their absence). In other words, by providing useful forensic information so that attacks can be detected.
I should emphasize that a secure network will not stop all attacks from succeeding. Given enough time and motivation, an attacker will eventually compromise your systems. However, a secure network design assumes that attacks will take place — even that some will (initially) succeed — and plans accordingly.
The first step in building a secure network is what I call “compartmentalization.” It refers to the idea of logically separating the network into sections, or “compartments,” where access policy can be enforced and attempted violations of that policy can be detected.
A good analogy for this is a fire door. You probably have fire doors spread throughout your place of work. Consider what a fire door does. A fire door does not prevent fires. But when a fire occurs, a fire door slows the fire’s spread. It gives you time to detect the fire, and it gives you time to respond. Similarly, a compartmentalized network does not prevent attacks, but it slows down attackers, making it harder to compromise more systems, and also makes it easier to detect the attacks taking place.
The first step in compartmentalizing a network is understanding the components and the subsystems, how they interact with other devices on the network and what kinds of traffic they use (and should not use). Here are some examples of components:
- General user workstations.
- General purpose servers (file/print, database, web, etc.).
- Servers with restricted access, such as financial systems, HR systems, etc.
- IP telephony servers.
- IP-based security systems (cameras, badge readers, recording equipment, motion sensors, etc.).
- Wireless guest networks.
This is not an exhaustive list – you may have additional categories. The point is to understand the different types of devices and their differing security needs – each of the categories above will have different access policies.
The next step is to separate the devices in each of these categories from devices in other categories. By “separate,” I mean create layer 3 boundaries between, say, printers and workstations. The easiest way to do this is to create VLANs for each category. Place your workstations in one VLAN, printers in another, IP phones in a third, and so on. In a large network you will have many VLANs for each category. As an example, each floor of a building may have a VLAN for user workstations, a VLAN for IP telephones, a VLAN for printers, etc.
This strategy greatly increases the number on VLANs and therefore, the number of IP subnets in your network. So, we should talk briefly about your IP addressing plan because it also plays an important part of your network security. A well thought out addressing plan can contribute to security by facilitating the creation of ACLs to enforce security policies. It does this by grouping categories of devices into summarizable address blocks. For example, if you allocate the following subnets to workstations:
172.24.0.0/24
172.24.1.0/24
172.24.2.0/24
172.24.3.0/24
:
:
172.24.15.0/24
You can summarize all these subnets as 172.24.0.0/20, and use that summary to make creating and applying ACLs much easier. Without summarization, it becomes difficult to create ACLs to control policy. They become long and difficult to manage. They may even affect network performance. Long ACLs may not be able to be processed in switching hardware and instead may require use of the CPU (often called process switching), which drastically reduces network performance.
So, for each of your device categories, allocate a block of addresses that you can summarize. In the example above, we’ve allocated 172.24.0.0/20 to workstations. You might allocate 172.24.16.0/20 to IP Phones, 172.24.32.0/20 to printers, etc. Each subnet within the /20 block can be used in a different closet or floor, yet you can refer to them all in an ACL by using the summary address.
In my next post, I will show how to develop an effective access policy for different groups of devices and how that contributes to a more secure network.