Secure Network Design Starts with Segmentation

Over the last year or so, I’ve noticed that there is at least one major security breach— hundreds of thousands of records— every week. Each breach represents tens of thousands of lives disrupted, millions (or tens of millions) of dollars lost, and an immeasurable loss of trust. Beyond hurting companies and people, data breaches also hurt the reputation of information technology systems.

What can network engineers do about this problem? There’s a myth that says something like: “Data breaches are an application problem; network engineers cannot do much about them.” This is wrong on a lot of different levels. The network can help build a secure system by adding depth to defense-in-depth.

What’s the first thing an attacker does when they breach a system? Install a command-and-control system. What’s the second? Find a way to move laterally through the network to attack and breach other systems.

While network design may not often play a role in preventing the initial breach, it can help reduce the effectiveness of command and control, and it can help reduce the scope of lateral movement. Of course, anyone reading this will think of one of two catchphrases used throughout information technology: Shift left! Zero trust!

Shifting zero trust principles left means moving security awareness into design (day 0), instead of reacting to events during operations (days 1 and 2). What does it mean to create a security-aware network design? I’ll draw out some helpful principles and ideas in this series.

Segmentation

Let’s consider a small data center fabric and some attached hosts, as shown below.

 

Assume this fabric runs an iBGP underlay and an eBGP EVPN overlay, with eBGP connections configured from the ToR switches to the hypervisors. What happens if an attacker can take control of server 1—not a single process on the server, but the hypervisor or the entire server?

The attacker accesses the entire overlay routing table, including all the configured Ethernet Segments (ESs). The attacker can exploit this rich vein of information to discover the network’s segmentation and where services or hosts are connected. Given this is EVPN, the routing table includes Ethernet addresses matched to IP addresses.

Because the underlay and overlay are the same protocol, the attacker also gains access to the entire underlay routing table. An attacker with access to the underlay can inject routes, disrupting the infrastructure and bringing the entire data center down.

An attacker with access to the underlay control plane might not be good.

How could we plug this threat vector through configuration? We could, in theory, set a community on all iBGP infrastructure routes so they’re never sent outside the fabric, and then set a filter on received routes so we don’t accept anything “we know” is in the infrastructure range of addresses. Manually configured filters would work, but it could also be messy to maintain.

How could we plug this threat vector through design? We could use different underlay and overlay protocols— perhaps my favorite pairing is IS-IS for the underlay and BGP for the EVPN overlay. Isn’t using two protocols more complex and, hence, less secure? Maybe— or maybe not. For the moment, let’s call this one a wash and continue thinking about security.

Using separate protocols for underlay and overlay is a form of segmentation—just not the kind we normally think about. In fact, all kinds of segmentation can help increase security. Segmentation always involves functional separation. You can generally separate:

• One part of a network topology from another horizontally by removing control plane information through aggregation and summarization
• One group of hosts or applications from another group of hosts or applications vertically by creating virtual topologies or by functionally dividing functions into layers

Just about every form of segmentation will fall into one of these two forms. For instance, multiple control planes are a form of functional separation, carrying infrastructure and “customer” routes in different systems, so failures or security breaches in one cannot impact the other.

I’ll look at obfuscation and virtualization in future posts.