Security

Retrofitting East-West Segmentation into a Live Enterprise Network

Cisco Secure FirewallFMCNetwork SegmentationVRFSnort 3Zero Downtime

The starting point: a hard shell and a soft inside

The company had solid north-south protection: edge firewalls inspecting everything entering and leaving the network. Internally, nothing. Every VRF could reach every other VRF through routing alone, so a single compromised workstation was one hop away from servers, management interfaces, and every other department. This is the classic hard shell, soft inside pattern, and it fails exactly when it matters: after the first foothold, when lateral movement decides how bad the incident gets.

Audits repeatedly turn up where that ends: over-permissive VRF designs where internal segments can reach far more than they should without ever crossing a firewall (the network audit write-up covers that failure mode). This project is the cure: put an inspection point in the middle of the network, between the VRFs, and earn the policy set from evidence instead of guesswork.

The design

The architecture is an internal segmentation firewall: a high-availability pair of Cisco Secure Firewall 4100 series appliances running Threat Defense (FTD), managed centrally through Firewall Management Center (FMC), inserted as the routing chokepoint for traffic between VRFs.

The key design decisions:

  • The firewall becomes the inter-VRF gateway. Instead of VRFs exchanging routes directly, inter-VRF traffic is steered through the firewall pair. Each VRF maps to a firewall interface and security zone, so policy is written in terms of zones, which stays readable as the network grows.
  • Symmetry is non-negotiable. Stateful inspection dies on asymmetric paths, so routing was designed to guarantee both directions of every inter-VRF flow traverse the same firewall pair. This drove the HA design (active/standby with stateful failover) and the routing metrics around it.
  • Intra-VRF traffic never touches the firewall. Segmentation applies where a security boundary exists. Keeping same-VRF traffic in the fabric avoided turning the firewall into an accidental bottleneck for east-west storage and backup flows that carry no cross-boundary risk.

Before and after: inserting an internal segmentation firewall between VRFs

Phase one: allow everything, log everything

Day one, the firewall pair went in with allow-all policies and full connection logging. Deliberately. Nobody, including the application owners, actually knows what talks to what inside a network that has never had internal enforcement. Turning on deny rules from a whiteboard model is how you take down payroll on a Tuesday.

For several weeks the firewalls did nothing but observe. Connection events streamed from FMC into our log analysis stack (FMC’s own analysis views for quick pivots, with events exported to the SIEM for longer-window queries), and out of that we built a flow matrix: for every VRF pair, which sources, destinations, ports, and applications actually communicate, how often, and how much.

This phase surfaced the usual archaeology: undocumented dependencies, servers calling services nobody owned anymore, backup jobs crossing boundaries nobody expected, and a handful of flows that were simply legacy misconfigurations rather than business needs.

Phase two: turning flows into policy

From the flow matrix we generated candidate rule sets per VRF pair: permit rules scoped to the observed sources, destinations, and services, grouped by application rather than dumped as one line per flow. Every candidate rule set then went through review with the security team, flow by flow: keep, restrict, or kill. That review is where segmentation actually happens. The firewall just enforces the outcome.

The rollout ran over a series of maintenance windows, one VRF boundary at a time, following the same guardrail pattern each night: deploy the scoped permits with a logging deny beneath them in monitor mode first, watch for hits that the flow matrix missed, then flip to enforcement with a tested rollback ready. Because every rule traced back to observed traffic, enforcement nights were quiet. The scary part had already happened in the data.

Next-generation inspection, tuned rather than maxed

With the traffic now flowing through an inspection point, we enabled the features that justify a firewall over an ACL:

  • Intrusion prevention with Snort 3 policies on inter-VRF flows, starting from the Balanced Security and Connectivity baseline and tuning rule sets per zone pair based on what actually lives behind each boundary.
  • Selective TLS decryption where inspection value justified it, with explicit do-not-decrypt handling for certificate-pinned applications and categories where decryption breaks the client or the trust model.
  • Prefilter fast paths for high-volume trusted flows like backups and storage replication, so elephant flows bypass deep inspection deliberately instead of degrading it for everyone else.

Each feature was benchmarked before and after enablement against latency and throughput budgets agreed with the application teams. A segmentation project that slows the business down gets rolled back politically even if it never gets rolled back technically, so performance tuning was treated as part of the security work, not an afterthought.

What changed

The network went from one security boundary (the edge) to enforced boundaries between every internal segment. Lateral movement now requires either an allowed flow, which is logged and inspected, or a firewall bypass, which is a much taller order than “be on the inside.” Just as valuable: the organization now has a living map of its own internal traffic, and a policy base where every rule exists because someone saw the flow and decided it should. Compliance conversations got shorter too. “Show us how you restrict internal access to the sensitive segment” is now a screenshot instead of a meeting.

The method is the reusable part: insert the chokepoint dark, observe until the data stops surprising you, review with the people who own the risk, then enforce in small reversible steps. It converts segmentation from a leap of faith into a sequence of boring, safe changes, and boring is exactly what you want standing between an attacker and everything else.

Key Results

  • Introduced inter-VRF traffic inspection into a network that previously had none, using an HA pair of Cisco Secure Firewall 4100 series appliances managed by FMC.
  • Mapped every real inter-VRF traffic flow from weeks of connection-event logging before writing a single deny rule.
  • Deployed least-privilege policies over phased maintenance windows with instant rollback available at each step, and no unplanned user impact.
  • Enabled next-generation inspection (Snort 3 IPS, selective TLS decryption) tuned to keep latency and throughput within agreed budgets.
  • Left the security team with an evidence-based policy set where every rule maps to a known, reviewed traffic flow.