Segmentation Done Right – Part 2 of 3
Segmentation is a good thing, and there are many use cases for segmentation done the right way. What tools then do we implement to get started with segmentation, and are there some pitfalls to avoid? The idea is simple, but one doesn’t want to design cost and complexity into the equation from the start. A flexible yet granular segmentation system with ample room to grow is what you need.
The traditional way of doing segmentation was to use the perimeter firewall—one side was trusted and safe, and on the outside was the big bad world. With many intrusions, however, a small breach means the damage is difficult to contain. Take it a step further, and one can deploy multiple virtual networks, or VLANs, to further segment and create various “safety zones” inside the network, then leverage routers and Layer 3 switches to control access between the virtual segments.
Using VLANs is pretty intuitive—place all things of a particular type into the same virtual segment. But VLANs are manually intensive—each new device must be manually categorized and assigned the correct VLAN. Each new group needs its own VLAN and a painful call to the IT desk to allocate a new VLAN across the enterprise, each with its own unique IP address space. And don’t forget the VLAN boundaries. ACL policies need to be consistently deployed at each of the routers and L3 switches to control the flow between VLANs, or else what was the reason for creating new VLANs in the first place?
Furthermore, the world of applications is dynamic, so boundaries can’t be so rigid. When one creates and deploys a new application using an Auto Scaling group, which contains a collection of Amazon EC2 instances, an IP address is dynamically assigned. Frequently this application will need to move around various network segments. If one applies a rigid approach to segmentation, there will be too many strict routing rules to navigate since traffic is only allowed when information is on a pre-defined list. Moving around is hampered, and a permissible list has to be updated continuously manually. In today’s environment, network ports are dynamic, DHCP is dynamic, applications are active, and we think segmentation should be flexible and smart.
Let us go back to the middle school example from last week. Students in their classrooms can further represent segmentation. Grades and different classrooms separate children, and each class has a teacher. Typically, (or in some cases hopefully) the children are expected not to interact with each other during lessons and only interact with the teacher. Likewise, when you have a class of IoT devices, rarely do these devices need to communicate or talk to each other. If anything, one MRI machine talking to another or sharing a snack should not happen.
So if this orderly communication between a teacher and student makes sense in a classroom or “segment,” then why do we lump similar devices such as cameras, X-Ray machines, or workstations together into their respective segment, VLAN or subnet with the notion that they are protected? These devices should talk to a central master and externally to get a patch once in a while, but not each other. If one device is compromised, there goes the notion of protection via segmentation. If junior in class catches the flu, other students in the same class are likely to get sick, too. Likewise, if a workstation is compromised and it’s in the same VLAN with other workstations, how does one contain the damage?
Traditional segmentation often places all sorts of devices of a general category into the same group/segment, and any infection of one will quickly spread to the rest. At Ordr, we segment smartly and take it further with micro-segmentation. We can group and segment things logically, and we can control the flow between the logical segments. Micro-segmentation divides networks down to the workload level and then defines specific security controls and policies for these specific segments and workloads. It’s a more granular and logical approach than physical segmentation via physical firewalls, making it easier for network and security administrators.
If a device becomes infected, we can contain the damage and not let it spill over, thus help you regulate and protect precious assets and information. Next week we will discuss segmentation automation and how one can generate clear policies using observed behavior. Be smart and control the flow between segments and do segmentation in an Ordr’ly way.
Pandian has more than 20 years of product and engineering leadership experience and is also a serial entrepreneur. Before founding Ordr, he was the Chief Development Officer at Aruba, responsible for all of engineering and product management functions. Aruba, an enterprise mobile wireless company, was acquired by HPE for $3 Billion in March 2015. Before Aruba, Pandian served as the head of engineering for Cisco’s multi-billion-dollar Wi-Fi business unit and before that as VP of engineering for low-end switching product lines. He graduated with a master’s degree in Electrical Engineering from IIT, Chennai, India and holds several patents to his credit in various networking technologies.
Follow by Author