Infrastructure Security: What’s an Infrastructure?

By now, you’ve heard it a hundred times: the perimeter is breaking down, no more “crunchy outside” to protect a “chewy inside”, no more castle-and-moat model of network infrastructure security. If there is no inside and outside, then where do defenses belong? What security architectures make sense for such amorphous network?

If a network is fluid, then defenses must be similarly flexible: flexible in configuration, granular but efficient to manage, capable of minimizing the spread of an intrusion, and “sticky”, meaning that defenses should remain with assets, even if the asset moves or changes.

This sounds like a job for software-defined networking (SDN), also called micro-segmentation, which is central to the zero-trust model of security. (Hey, if the perimeter is fuzzy, the terminology should be, too). Let’s clarify these terms by looking at their origins.

In traditional networking, network administrators would divide a network into segments, or subnetworks – groups of systems with something in common, such as a common physical location, or a shared work mission. The “Atlanta” subnet might be one segment, while the “Accounting” subnet would be another.

The combination of segments formed a “network” around which system administrators would deploy various types of defense mechanisms: an intermediary “DMZ” network, firewalls, e-mail gateways, proxies, and so on. These defenses would closely inspect “north-south” traffic (the term security geeks use to refer to the torrent of bits and bytes network traffic flowing into a network from the outside).

In addition, administrators would typically surround the DMZ network on both sides with defenses, to double down on guarding against north-south intrusions, but would install minimal, if any security between other segments. North-south traffic was “dirty”, east-west traffic, “clean”.

This design has some major flaws. First, it is not flexible. Changing configurations requires extensive manual intervention, up to and including moving or re-installing physical devices. Further, assuming that east-west traffic was clean constitutes a huge vulnerability in the defense architecture, a weakness that hackers were quick to notice, and have been happy to exploit. This approach also does not translate well to cloud computing and cloud networking, where agility rules.

SDN addresses these problems. Instead of deploying or reconfiguring physical devices, administrators can implement or reconfigure defenses by pointing and clicking, dragging and dropping. More importantly, it enables deployment of defense mechanisms that inspect east-west traffic, blocking it or re-routing it to a “black hole” or deception network when necessary. The approach is agile and lends itself well to automation. Defenses can be extremely granular, even down to the workload level, and they can be a “sticky” defense: when you drag-and-drop an asset to a new location or segment, its defense mechanisms stay with it. Finally, with SDN, it is possible to limit the spread of an intrusion very quickly. Stopping traffic from single systems is quick and easy, and is more likely to happen when east-west traffic is suspicious rather than safe.

Cloud computing provides flexibility, and the use of mobile, unmanaged devices on a network spells the demise of the “perimeter”. It is impossible for a human to keep up with such fluidity, but software, or software-defined networking, can do what humans cannot.