Datacenter segmentation - Starting the Segmentation Journey

This is the first post in a series about datacenter network segmentation using Cisco ACI. In this series I’ll cover the complete journey from preparation to advanced segmentation techniques. This first post focuses on the preparations you need to make before you start implementing segmentation in your datacenter.

Segmentation projects are often driven by security requirements, compliance mandates, or simply the desire to reduce the blast radius of potential security incidents. Whatever your reason, the journey towards a properly segmented network requires careful planning and preparation.

Why Segment Your Network?

Before diving into the technical aspects, let’s discuss why you would want to segment your datacenter network in the first place. There are several reasons:

Reducing the Blast Radius

In a flat network, an attacker who compromises a single system potentially has access to every other system on the network. When a breach occurs, the attacker can move laterally through the network, compromising additional systems as they go. I often call this horizontal escalation. By implementing segmentation, you limit the scope of what an attacker can reach from a compromised system.

One of my customers thought of it this way: if your datacenter is a building, a flat network is like having all rooms connected without any doors. Once someone gets in, they can walk everywhere. Segmentation adds doors, walls, and access controls between rooms.

Compliance Requirements

Many regulatory frameworks now require network segmentation. I’ll discuss these in more detail later in this post, but frameworks like NIS2, PCI-DSS, and ISO27001 all have requirements or recommendations around network segmentation.

Operational Benefits

Depending on the way segmentation is implemented it could also ease troubleshooting. It could reduce the scope of potential issues. When problems occur, they’re contained within a segment rather than affecting the entire network.

Application Protection

Modern applications often consist of multiple tiers (web, application, database or many more). Segmentation allows you to protect each tier appropriately, ensuring that only the necessary traffic flows between tiers.

Regulatory Drivers

Let’s look at some of the regulatory frameworks that either require or strongly recommend network segmentation.

NIS2 Directive

The Network and Information Security Directive 2 (NIS2) is the successor to the original NIS Directive in the European Union. NIS2 significantly expands the scope of organizations that must comply with cybersecurity requirements. If your organization operates in the EU or provides services to EU-based entities, NIS2 likely applies to you.

NIS2 came into force on January 16, 2023, and EU member states had until October 17, 2024 to transpose it into national law. The directive applies to two categories of entities:

  • Essential entities: Organizations in critical sectors like energy, transport, banking, healthcare, and digital infrastructure.
  • Important entities: Organizations in sectors like postal services, waste management, manufacturing, and digital providers.

While NIS2 doesn’t explicitly mandate “network segmentation” by name, it requires organizations to implement appropriate technical measures to manage cybersecurity risks. Article 21 specifically mentions:

  • Network security
  • Access control
  • Incident handling
  • Business continuity

Network segmentation is considered a fundamental technical measure for implementing these requirements. The directive emphasizes a risk-based approach, meaning you need to assess your risks and implement appropriate controls. For most organizations, segmentation is one of the most effective controls available.

PCI-DSS

The Payment Card Industry Data Security Standard has always been explicit about segmentation. If you process, store, or transmit cardholder data, PCI-DSS requires you to isolate the cardholder data environment (CDE) from the rest of your network. While segmentation is technically not a requirement (you can choose to have your entire network in scope), it’s practically impossible to achieve compliance without it.

PCI-DSS 4.0, which became mandatory in March 2024, continues to emphasize network segmentation as a critical control.

ISO 27001

ISO 27001 is the international standard for information security management systems. While it doesn’t prescribe specific technical controls, Annex A includes controls around network segmentation and network security. Organizations seeking ISO 27001 certification typically implement segmentation as part of their control framework.

DORA

The Digital Operational Resilience Act (DORA) is an EU regulation that applies to financial entities. It requires organizations to implement appropriate ICT security measures, including network security controls. Like NIS2, DORA doesn’t explicitly mandate segmentation, but it’s considered a fundamental control for achieving compliance.

Getting Management Support

Before you start implementing segmentation, you need management support. This might seem obvious, but I’ve seen too many segmentation projects fail because they lacked proper backing from leadership.

Building the Business Case

To get management support, you need to build a compelling business case. Here are some arguments that typically resonate:

Compliance: If your organization falls under NIS2, PCI-DSS, or other regulatory frameworks, segmentation isn’t optional. Frame it as a compliance requirement rather than a nice-to-have.

Risk reduction: Quantify the risk of a security breach. What would it cost your organization if an attacker compromised your network? Segmentation significantly reduces this risk.

Insurance: Many cyber insurance providers now require or offer reduced premiums for organizations that have implemented proper network segmentation.

Operational efficiency: A well-segmented network is often easier to manage and troubleshoot. This can translate to reduced operational costs over time.

Setting Realistic Expectations

Be honest with management about what segmentation entails. It’s not a quick project. Depending on the size and complexity of your environment, a full segmentation project can take months or even years to complete. Set realistic timelines and milestones.

Also be clear about the potential impact on operations. Implementing segmentation in an existing environment will require application owners to understand their communication requirements. Some disruption is almost inevitable, even with careful planning. Application teams need to be on-board. It is impossible to introduce proper segmentation without cooperation of the application teams. Segmentation might mean technical changes to their applications, or at least information gathering. Ensure management is aware of this, and ready to support.

The image below (sourced from Cisco Live presentation BRKDCN-2959 2025 by Fabien Gandola &Steve Sharman) shows the dependency on Application Knowledge. Each step on the security ladder requires more application knowledge.

Security vs Application Knowledge

Setting Up Architecture Guidelines

Before you start implementing segmentation, you need to establish clear architecture guidelines. These guidelines will ensure consistency across your environment and make the project more manageable.

Defining Security Zones

The first step is to define your security zones. A security zone is a logical grouping of systems with similar security requirements. Common security zones include:

  • Internet-facing: Systems that are directly accessible from the internet
  • Internal production: Production systems not directly internet-facing
  • Development and test: Non-production environments
  • Management: Administrative systems and networks
  • Restricted: Highly sensitive systems requiring additional protection

For each zone, define:

  • The types of systems that belong in the zone
  • The default security posture (what traffic is allowed by default)
  • The requirements for communication between zones

Mapping Applications to Zones

Once you’ve defined your zones, you need to map your applications to them. This is often the most time-consuming part of the planning phase. For each application, determine:

  • Which zone(s) does it belong to?
  • What are its communication requirements?
  • Who is responsible for the application?

In the next post in this series, I’ll discuss tools that can help you discover application communication patterns. This information is crucial for successful segmentation.

Deciding on Segmentation Levels

In ACI, you have multiple levels at which you can implement segmentation:

VRF-level segmentation: This is the coarsest level of segmentation. VRFs are completely isolated from each other by default. Traffic between VRFs must pass through an external device (such as a firewall) unless you explicitly enable route leaking.

EPG-level segmentation: Within a VRF, you can use End Point Groups (EPGs) to segment traffic. By default, traffic between EPGs is blocked unless a contract allows it.

ESG-level segmentation: Endpoint Security Groups (ESGs) provide a more dynamic way to group endpoints based on their attributes rather than their network location.

I’ll cover each of these in detail in later posts. For now, decide which level(s) of segmentation are appropriate for your environment. Most organizations will use a combination of all three. Keep in mind the dependency between security and application knowledge as shown in the image above.

Documentation Standards

Establish documentation standards early. You’ll need to document:

  • Zone definitions and policies
  • Application mappings
  • Communication requirements (flows)
  • Exception processes

Good documentation is essential for maintaining the segmented network over time and for demonstrating compliance to auditors.

Building Your Team

A segmentation project requires a cross-functional team. At minimum, you’ll need:

Network engineers: These are the people who will implement the segmentation in ACI.

Security architects: They’ll help define the zone model and security policies.

Application owners: Each application needs an owner who can identify communication requirements.

Project management: Someone needs to coordinate the effort and track progress.

Consider establishing a governance board that can make decisions about exceptions and resolve conflicts. When application owner A says they need to talk to application owner B’s system, someone needs to validate and approve that requirement.

Planning the Approach

There are different approaches to implementing segmentation:

Big Bang

In a big bang approach, you implement segmentation across the entire environment at once. This approach is rarely recommended because:

  • The risk of disruption is high
  • It’s difficult to troubleshoot issues
  • It requires complete knowledge of all communication patterns upfront

Phased Approach

A phased approach implements segmentation gradually:

  1. Phase 1: Implement VRF-level segmentation for coarse separation
  2. Phase 2: Implement EPG-level segmentation within each VRF
  3. Phase 3: Implement ESG-level segmentation for fine-grained control

This allows you to learn as you go and reduces the risk of major disruptions.

Application-by-Application

Another approach is to segment application by application. Start with your most critical or most sensitive applications and gradually expand. This approach:

  • Allows you to build expertise gradually
  • Reduces risk by limiting the scope
  • Provides quick wins to demonstrate value

In my experience, a combination of the phased and application-by-application approaches works best. Start with VRF-level segmentation to establish your zone boundaries, then progressively implement finer-grained segmentation for individual applications.

Common Pitfalls

I’ve been involved with several segmentation projects over the years and I’ve encountered several pitfalls in these projects.

Underestimating Application Discovery

Don’t underestimate how long it takes to discover all application communication patterns. Applications often have undocumented dependencies. A server might have a scheduled job that runs once a month, connecting to a system that nobody remembers.

Lack of Application Owner Engagement

Application owners are essential to the success of a segmentation project. If they don’t engage, you won’t have accurate information about communication requirements.

Analysis Paralysis

Some organizations spend so much time analyzing that they never start implementing. At some point, you need to accept that you won’t have perfect information and start implementing. You can always adjust as you learn.

No Exception Process

Every segmentation project will have exceptions. If you don’t have a clear process for handling exceptions, you’ll end up with either:

  • A completely blocked network because nobody can get exceptions approved
  • An ineffective segmentation because exceptions are approved without proper review

Next Steps

In the next post, I’ll discuss the tools you can use to gain insight into your application communication patterns. This information is crucial for successful segmentation implementation.

The posts in this series will be:

  1. Starting the Segmentation Journey (this post)
  2. Tools for Getting Insight
  3. Basic Network Level Segmentation
  4. Implementing L4-L7 Services for Segmentation
  5. Advanced Network Segmentation with ESGs
  6. Extending Segmentation Beyond ACI

Stay tuned!