Network Segmentation

What Is Network Segmentation?

It is the architecture of dividing and subdividing a network into distinct segments or subnets for better operational and cybersecurity control. The goal of segmenting a network is to limit the blast radius of the attack surface by separating core functions and using access control to limit a user’s ability to cause harm — intentionally or unintentionally.

The National Institute of Standards and Technology (NIST) defines network segmentation as “splitting a network into subsections where firewalls reject unnecessary traffic for that section.”

Commenting on this NIST definition in a joint report, the Cybersecurity and Infrastructure Agency (CISA) and the National Security Agency (NSA) states: “This is a foundational cybersecurity principle, which, when properly implemented, can isolate malicious activities and vulnerabilities to a limited part of the network and minimize the effect of a breach.”¹

In a similar overview of network segmentation, CISA defines it as “a physical or virtual architectural approach dividing a network into multiple segments, each acting as its own subnetwork providing additional security and control.”² CISA further explains that segmentation limits access to devices, data, and applications and restricts communications between networks.

 

Why Is Network Segmentation Necessary?

Organizations traditionally focused their network security measures on protecting the network perimeter, relying on firewalls to keep bad actors off the network and limit the attack surface. However, that approach fails to prevent authenticated users from doing damage. CISA and the NSA highlighted the danger of not restricting users once they gain initial authentication: “When using this perimeter-focused approach to network security, MCAs [malicious cyber actors] who breach that first line of defense will have access to target user traffic and organization resources, exploiting any vulnerable or unauthenticated network protocols and delivering malicious payloads.”³

The threat also extends beyond malicious actors. Well-intended employees, remote workers, partners, automated applications, and other ‘friendly’ sources may unintentionally cause harm after gaining authenticated access to the network. For example, remote workers with virus-infected devices may pass through the firewall and spread malware across the enterprise. By segmenting the network, IT can establish policies and use access control measures to limit each user’s access to only the resources on a subnet or within specific subnetworks, such as a local area network, they need to perform their individual job role, preventing lateral movement across the entire network and unnecessary access to additional resources. In this way, the organization minimizes the attack surface and damage from a bad actor (or a good actor with a compromised device with malware).

 

The Benefits of Network Segmentation

While network segmentation offers benefits to any organization, it proves most valuable in three common use cases:

1. Keeping OT separate from IT
2. Supporting Zero-Trust Architecture (ZTA)
3. Ensuring regulatory compliance

By applying network segmentation, IT can separate and protect the OT and IT/business networks from one another. Figure 1 (below) shows how a firewall does little to protect OT and IT from each other once a bad actor has entered the network, while Figure 2 (below) demonstrates how the use of network segmentation keeps the different resource types separated.

“Properly implemented Demilitarized Zones1 (DMZs) and firewalls can prevent a malicious actor’s attempts to access high-value assets by shielding the different networks from unauthorized access,” says CISA. Such a strategy dramatically reduces the effectiveness of many of today’s attack types, such as phishing.

[Source: CISA]

Of course, IT must make use of firewalls and DMZs in conjunction with higher-level measures, such as designing, implementing and enforcing policies and controls to monitor and regulate system access as well as the movement of network traffic and workloads between zones — which may require managing network congestion.

 

Supporting Zero Trust Architecture

Organizations must understand what is on their network before they can develop a plan to secure it. This means knowing each and every user and device seeking network access. “Current interest in network segmentation is being driven by Zero Trust,” according to Gartner.[iv]

Segmenting the network for each user and asset (or device) helps to improve security and
is a key capability under a Zero Trust architecture (ZTA) where the concept of least privileged access is derived. In Network Segmentation, IT policies grant proper network access to users/devices according to their role, such as moving printers to their own VLANs or granting developers access to certain systems while blocking others from them.

Consider a healthcare industry example: IT can set up a security policy that states, “medical devices can connect only to the medical records server” or “a security camera (which can be an IoT device) can connect only to the video server.” This approach prevents devices in a guest network from having access to these endpoints and limits access to their functions without connecting to the outside Internet. As a result, any unauthorized user cannot gain access to devices located in the network’s other zones. If, for example, a medical device moves within the network, the policy follows that endpoint device, eliminating the need to reprogram the network.

 

A Primer on Microsegmentation

What’s the difference between segmentation and microsegmentation?

Think of traditional segmentation as dividing your network into broad zones—maybe by function or geography. You’ve got your production zone, your guest network, your data center, that kind of thing.

Microsegmentation takes this way further by creating much smaller, more granular segments. We’re talking about isolating individual machines or even specific applications. This gives you stricter access control and really cuts down on lateral movement if an attacker gets in.

What is microsegmentation and why should I care?

It embraces the idea of least privileged access by only allowing verified clients access to resources they’re authorized to use. It’s powerful because not only do you limit attack vectors to devices, but if something gets compromised, you can greatly reduce the blast radius. Here’s how to do it in the real world.

 

What are the five steps to implementing microsegmentation?

I recommend breaking it down into these five steps:

1. Discover and Identify – Account for all devices, users, and applications
2. Map Data Flows – Understand current communication patterns
3. Policy Design – Define requirements and enforcement points
4. Test and Simulate – Validate policies before deployment
5. Deploy and Monitor – Gradually roll out and continuously review

Step 1: What do I need to discover and identify?

You want to account for all the players on the field. Without understanding what devices, users, and applications are out there, you can’t possibly have the confidence to design the correct policies.

What device information matters?

Devices are the direct touchpoint to the network, so their identity is crucial. Key factors include:

• Role/Function – Is it a mobile phone, workstation, IP camera, or something else?
• Operating System – This helps understand requirements. For example, Windows clients access different patch management servers than macOS clients.
• Vendor – Especially for IoT and OT devices, which have unique requirements.

What about device posture?

Posture is the dynamic information that decides if access should even be granted at all. There are three key factors:

• Authorization method – Is it using 802.1X, device enrollment, fingerprinting, or just a MAC address bypass?
• Compliance – Are security agents installed? Are patches applied?
• Risk level – Any exposed vulnerabilities, malicious behavior, or threat detections?

Think of it this way: identity is the mostly static information that helps decide what resources a device should access, while posture is the dynamic information that decides if that access should be granted.

How do I gather device information?

Discovery tools or network access control solutions help with identity. Posture typically comes from a range of security tools. Whatever the case, all this information needs to flow up to your policy decision point.

What user information do I need?

We want to apply the same least privileged access concepts to users. You’ll need:

User Entitlements:

• Business units – High-level grouping for common services (like corporate employees accessing HR systems)
• Job function – Role-based access (like physical security teams accessing surveillance systems)
• Clearance level – For sensitive resources

Dynamic Context:

• Authentication method – Tells you how trustworthy the session is
• Risk score – Reflects user behavior or detected threats

How do I get user information?

Identity access brokers or authenticated session details can provide the user account name. To associate a user to a device, you might need manageability of that device to query who’s logged in. Once you have the account name, you’ll usually query a database like Active Directory or your personnel system for entitlement information.

What about applications?

Since we’re focused on microsegmentation in the campus, let’s keep it simple and treat applications as resources that clients access. You just need three things:

1. Which host the apps are running on
2. Which ports they’re being accessed over
3. The protocols in use

You can make reliable guesses if you have visibility of the traffic, especially at the application layer. If you know the host’s identity, you might be able to find out which services are running on it.

Step 2: How do I map data flows?

You want to evaluate what’s currently in use so you can better understand potential access requirements. This data often comes from monitoring network traffic—whether that’s raw packets seen through a switch or analyzing flow data.

What should I capture?

It’s important to capture not only north/south traffic but also lateral east/west movement. Your capture period should be long enough to account for monthly or quarterly scheduled workloads.

How do I make sense of the data?

Once you have communication flows, enrich them by mapping the data from your discovery phase. Here’s what this looks like:

You start with a basic record: source, destination, and port. That doesn’t really tell you much. But once you overlay the data, you might see that the source is actually a Windows PC, logged in by a ‘Bob Hodges’ from accounting, and the destination is a database server over SSH.

Which leads to the question: does ‘Bob’ from accounting really need SSH access to the database server?

Being able to consolidate this information into a single record is immensely helpful. Having insight into which devices and users are accessing which services will help you build correct policies and audit their effectiveness down the road.

Step 3: How do I design my policies?

Time to put it all together and figure out what requirements each device and user needs to do their job—and only that. We’ll assume these rules go against the backdrop of an implicit deny all.

How do I figure out requirements?

Consult all the information you’ve gathered, along with some investigative work:

• Enriched data flows – Give you a current baseline. That doesn’t mean the traffic is absolutely required, but it should be considered.
• Documentation – Can specifically state network service requirements for IoT and OT devices.
• Team surveys – Time-intensive, but surveying your teams for resources they use helps cover your grounds.
• Existing ACLs and firewall rules – They might need amendments, but they’ll help ensure important production workflows don’t fall through the cracks.

Where should I enforce policies?

This depends greatly on which technologies are in play and how traffic traverses your network. Common enforcement points include:

• Client firewalls
• Edge, distribution, or core layers
• Firewalls dispersed throughout your network

What should I consider about enforcement points?

Every environment is unique, but here are common considerations:

• Software-based controls work well on managed IT clients, but how will you apply policies to IoT and OT devices?
• Edge enforcement is ideal, but can your switches handle the TCAM loads or do they have modern blocking capabilities?
• Context awareness – Are your enforcement points device context aware so they know which policies to apply? If not, is there another system to inform them?
• Layering strategy – You might need different policy enforcement points for lateral, cross-zone, or outbound traffic.

Step 4: How do I test my policies?

Do the responsible thing and test them—not only to validate effectiveness but also to make sure they don’t block important production workflows.

What’s the best testing approach?

Set your policy enforcement points to log-only mode, whether at the switch level, client-side firewall, or core distribution layers. Aggregate all those logs and make sure nothing is being blocked that shouldn’t be.

If you have the resources, consider a test environment. You might mirror production traffic from your firewalls or core switches to a clone device with your policy proposals enabled.

What’s the key to effective testing?

Having a holistic view of the entire network is much more effective than only looking at specific enforcement points.

What operational aspects should I consider?

During the simulation phase, start thinking about:

• Rollback processes in case something critical is blocked
• How this new design fits into your change control procedures

Step 5: How do I deploy to production?

Once you’re satisfied with how your policies perform in simulated mode, it’s time to gradually deploy them into production.

Where should I start?

IoT devices are great candidates to start with—their requirements are generally pretty straightforward. They can really help your teams build confidence and get into their groove.

What’s the deployment philosophy?

You’ve probably been down this road before. Take the gradual approach, and any problems that arise will be more manageable.

What about ongoing maintenance?

Once your policies are rolled out, review your denied traffic logs regularly. Just because a problem isn’t being brought to your attention doesn’t mean it isn’t lurking in the background.

Requirements will likely have been missed, and that can be okay. The key is to have a good process around reviewing and allowing for exceptions, and your policies will remain tidy and effective in the long term.

What’s the bottom line?

We covered five steps to guide you in designing Zero Trust microsegmentation policies for the campus:

1. Discover and identify all devices, users, and applications so you can dynamically apply policies later
2. Map data flows with enriched context to better understand access requirements
3. Design policies taking all information into consideration and planning enforcement points
4. Test and simulate deployment to gain confidence and avoid unforeseen impacts
5. Gradually deploy all rules and monitor them for effectiveness

 

Ensuring Regulatory Compliance

Network segmentation allows for the creation of different zones for varying types of servers and devices, while simplifying the audit process to ensure compliance with regulatory standards. Expanding on the healthcare industry example, IT can adhere to HIPAA regulations by storing patient records in their respective compartments to ensure separation between patient data, procedure records, and doctors’ notations and simultaneously restrict the access of medical devices within their zones – making them unreachable from any other network or device.

It’s not just highly regulated industries like healthcare and finance (SWIFT, NYDFS) that benefit greatly from network segmentation. Even eCommerce companies use network segmentation to follow the PCI-DSS standard to receive credit card payments. PCI-DSS provides guidance on creating clear separation of data within the network, such as separating the network for Payment Card authorizations from the network for Wi-Fi traffic. Considering the number of industries that operate by accepting credit card payments, network segmentation helps thousands or millions of organizations across a wide range of industries.

 

How Forescout Can Help

Forescout solutions, particularly Forescout eyeSegment for network segmentation, supports all three common use cases described above.

Forescout eyeSegment can translate IP addresses into context and, enabling IT and network administrators to:

• Classify and group non-managed devices automatically. These can include devices for building automation, OT systems, or business IoT.
• Add context to managed devices, grouping them in various ways, such as Finance users, payment apps, and compliance status. You can even group them based on the vulnerability intelligence which Forescout gathers about each device, as well as by location and ports/protocols.
• Visualize traffic flows by automatically mapping them to a logical taxonomy of users, applications, services, devices, and visibility.

 

How We Support Zero Trust Architecture

eyeSegment can continuously monitor any network type for new device events, traffic patterns, and anomalies that conflict with your defined segmentation policies. This understanding of your network traffic baseline will help you to design effective zero-trust policies and enforce least-privileged access.

By combining Forescout eyeSegment and eyeExtend, your IT team can implement a single set of policies across multi-vendor environments and multiple network domains, monitor happenings according to those policies, and respond appropriately. Forescout even provides closed–loop feedback so that your organization can improve segmentation controls over time – without impacting the business.

Forescout eyeSegment can provide an added aspect of compliance via network segmentation policies. Consider Figure 3 (below).

Figure 3. Segmenting for Compliance

Forescout can map all traffic to a connectivity matrix made up of ‘Sources’ and ‘Destinations’. You can display these by network segment, as well as device, user, or business groups. Wherever a blue dot is seen on the matrix, that indicates traffic detected between those two groups. Forescout’s strength in classifying devices and retrieving other information that yields contextual awareness beyond a simple IP underpins this unique way of viewing traffic flows.

The focus is placed on traffic from the service desk and the policies that allow service desk personnel to access only the resources needed to perform their jobs. You can create policies that allow access to printers and the internet, while granting only limited access to the internal servers these workers need. Once you put in place your policy for ‘Service Desk’, you will automatically restrict these workers from sensitive zones, such as database servers, surveillance systems, and manufacturing lines. Alerting and block will occur for any violating traffic.

As with Zero Trust, the path to successful network segmentation involves a process of continuous improvement. Forescout has helped organization of all levels of segmentation maturity to improve their compliance and security postures.

Contact Forescout today to experience a demo of Forescout eyeSegment and eyeExtend for yourself.

---

¹ CISA and the NSA, Implement Network Segmentation and Encryption in Cloud Environments, March 2024
² CISA, Layering Network Security Through Segmentation, January 2022. Accessed November 8, 2024 from the following source https://www.cisa.gov/resources-tools/resources/layering-network-security-through-segmentation-infographic
³ CISA and the NSA, Implement Network Segmentation and Encryption in Cloud Environments, March 2024
⁴ Gartner, Implementing Segmentation for Zero Trust Networking, January 25, 2024. Accessed November 8, 2024 from the following source https://www.gartner.com/en/documents/5141631