When it comes to building and securing a network, the most impactful thing that can be done is planning your network design in an efficient and protective manner. Understanding and implementing a segmented and layered architecture will establish a clear precedent for efficiency and security from the jump. If you don’t do this, once an environment starts to go down the unwieldy path of a flat environment or a device free for all, it is awfully hard to put the cat back in the bag. This is why any time I’m starting to work on a new network design, segmentation is step number one.
Network Segmentation 101
Network segmentation really relies on a few different technologies and configurations that are intertwined: network subnetting, VLANs, and physical and virtual security zones. The first step when planning a network is to determine the scope of services and devices that will be residing on it. Once these are defined, it makes sense to start breaking these up into logical groups. At a minimum, you should break them up into the following:
- External/Untrusted/Premise devices: these are devices that have a direct connection to the Internet that doesn’t sit behind a firewall or some type of access control screening. Such devices might be things like your external router/switch or VPN termination points.
- DMZ devices: these are any devices that provide services that can be accessed from external devices/clients on the Internet. Best practice is anything that has inbound access from the Internet should not reside in your internal network. By placing devices in the DMZ, you can add additional layers of technical controls and safeguards.
- Internal Servers: pretty self explanatory- any server that resides on your internal network, should be in its own group.
- Workstations: for protection purposes it makes complete sense to segment workstations from everything else, as these will often be the main vector that malware is introduced into the environment. I’d also highly encourage ensuring that the workstations can’t talk to each other (as well as limiting the ability to communicate with other servers.) However, that topic will be thoroughly discussed in the subsequent blog posts on Access Control Lists and Private VLANs.
So, you noticed that when describing the above section, I said “at a minimum”. The real purpose of listing things out above was to get you thinking logically about how to break these groups of services/devices up. In all honesty, the above segmentation, while a step in the right direction, would still have way too much freedom to allow lateral movement and also really miss out on a lot of the efficiency benefits of further segmentation. So, how would I improve on the above? I would break it down into even smaller logical groups within each of the main groups. Below are some examples of how I might do that:
- External Devices Grouping
- External devices public subnet
- External devices management subnet
- VPN termination encrypted subnet
- VPN termination clear-text subnet
- DMZ Devices Grouping
- DMZ web services public subnet
- DMZ web services management subnet
- DMZ email services public subnet
- DMZ email services management subnet
- DMZ reverse proxy public subnet
- DMZ network device management subnet
- Internal Servers Grouping
- Domain controllers subnet
- Database servers subnet
- Monitoring tools subnet
- Email servers subnet
- Office tools subnet
- Network device management subnet
- Web proxy subnet
- Security tools subnet
- End Devices Grouping
- Workstation subnet
- Printers subnet
- VoIP phones subnet
- Video teleconference subnet
- Smart device subnet
- Wireless Devices Grouping (if applicable)
- Untrusted guest devices subnet
- Trust company devices subnet
- Wireless infrastructure management subnet
Having now identified these logical groupings of devices and servers in order to architect a segmented network, we would take each of these and assign the proper subnet and VLAN. From a subnet perspective the main decision is public or private IP space (or IPv6, which is a little out of scope for this discussion at the moment.)
The main deciding factor is whether or not it will have inbound communications from the Internet. I’d say based on the network described above, anything that is in the External or DMZ groupings and is not management subnet would require public IP space. The rest of the devices could use private internal IP addresses. Those devices that need to communicate from within the environment to the Internet would probably suffice with just having their private IP addresses being translated to a public IP address via network address translation (NAT) on the network’s firewall or premise router.
Now with the subnets in place and the proper VLANs assigned to each subnet, we can take this segmentation a bit further by layering on security zones within the devices providing firewall services for the environment. I understand that not all environments may be architected this way, but it should be a goal to ensure that all internal subnets and VLANs must pass through a firewall when communicating to other subnets/VLANs. By having these VLANs associated with an unique security zone, it allows for the implementation of granular access control policies between each VLAN.
Network segmentation allows us to implement a handful of techniques and technologies allowing for greater protection and granularity of asset monitoring. By breaking up all of your services into separate subnets, it forces us to do a few things which are extremely beneficial. If implemented properly with a deny-by-default posture, it forces us to become aware of the specific data flows/protocols that are traversing our environment. In flat environments hosts are generally allowed unfettered access to all other devices. If this is not the case, you must know the proper ports and protocols in order to get services functioning properly. It is a great learning and documentation exercise.
Likewise, segmentation allows you the ability to focus attention on key assets. You can increase your monitoring or controls on specific VLANs/subnets that you have deemed as high priority. This can be accomplished through targeted auditing and alerting, or by routing only critical traffic from these particular subnets through additional protections. You can also ensure that communications within a subnet are further controlled by implementing intra-VLAN ACL’s.
Lastly, segmentation is the key component of minimizing lateral movement within the environment. You should look at your overall architecture from the perspective of an attacker already having a foothold within it. Implementing segmentation will allow you to make it a lot more frustrating for an attacker to pivot to additional devices. In essence, this is the original and a practical first step of implementing “Zero Trust” security principles.
While I would primarily focus on network segmentation and isolation as a security improvement, there are many benefits from an operational efficiency perspective. By having less devices in individual VLANs/subnets, you minimize the amount of broadcast traffic within the VLANs. It also minimizes potential operational issues that are directly tied to the configurations applicable to the VLAN/subnet in question. Lastly, as mentioned above, if you are able to scope your auditing and alerting for your key assets, you can possibly lower the total amount of logging and alert data you have in your environment.
Real World Examples
Some very simplified examples of what segmentation would look like in a real environment can be seen in our previous Network Security Basics post on documentation. In that post, I showed some examples of various network diagrams and data flow documentation. Additionally, I depicted a network that had segmentation already put in place via different VLANS per service type.
Likewise, the data flows between each of the hosts in the various VLANs were explicitly documented. Anything not matching these rules would not be allowed by the firewall/network/host access control lists.
The Segmentation and Isolation Wrap-Up
So the take away from this post should be two things. First, segmentation should be at the foundation of any network architecture. It will enhance both the security and efficiency of traffic in the environment. It will severely hinder an attacker’s ability to laterally move. Second, segmentation takes a considerable amount of planning compared to the normal “spray and pray” implementation of a flat network. Be sure to take the time and count with the proper resources to do it correctly from the beginning. If it is not done properly, you will either have a lot of misconfigurations that can be exploited, or it will negatively impact the operational functionality for users and services in your organization.
Next in the six-part series on the basic network security principles (The Fab Five), we’ll be discussing Access Control Lists.
Find out more about J.B.C.’s Cyber&Sight™ blog here.