Network Segmentation and Enhancing Security in Hybrid On-Premises and Cloud Infrastructure

1. Executive Summary

Network segmentation remains one of the most effective controls for reducing cyber risk in enterprise environments. Yet many organisations struggle to implement it effectively — particularly those operating hybrid infrastructure that spans on-premises data centres, multiple cloud platforms, and operational technology (OT) networks.

This whitepaper draws on practical experience implementing segmentation programmes across pharmaceutical, manufacturing, automotive, and financial environments. It presents a structured approach to segmentation that addresses the real-world challenges: legacy systems that can't be easily moved, OT networks that demand availability over confidentiality, cloud environments with different security models, and organisations with limited change windows and competing priorities.

The core argument is straightforward: effective segmentation in hybrid environments requires a zone-based architecture that treats trust boundaries — not network topology — as the primary design constraint. The Purdue model provides the conceptual framework for OT environments, while Zero Trust principles extend this thinking to IT and cloud. The implementation methodology must be phased, production-safe, and aligned with both business operations and regulatory requirements.

2. The Challenge

Modern enterprise networks are not single, homogeneous environments. They are composites: a corporate LAN running Active Directory and Microsoft 365, a production OT network with PLCs and SCADA systems, one or more cloud platforms (AWS, Azure, GCP) hosting workloads, and an increasing number of SaaS applications accessible from anywhere. Each layer operates under different security assumptions, different change management processes, and different regulatory requirements.

The flat network problem

Many organisations evolved their networks incrementally. What started as a simple office LAN grew into a multi-site, multi-function network where a compromise on a single endpoint can reach manufacturing control systems, financial databases, and cloud management planes. The network is "flat" — meaning there are few or no internal boundaries restricting lateral movement.

In incident after incident, from NotPetya through to recent ransomware campaigns targeting manufacturing, the primary amplification vector has been lateral movement across flat networks. The attacker gains initial access through a phishing email or exposed service, and within minutes has traversed from the corporate IT network into OT systems, backup infrastructure, or cloud management accounts.

The hybrid complication

Segmentation in a purely on-premises environment is well-understood: deploy firewalls, create VLANs, implement access control lists. But hybrid environments introduce additional complexity. Cloud networks use software-defined perimeters that don't map neatly onto traditional firewall-based segmentation. OT networks contain devices that can't run agents, don't support modern authentication, and may use proprietary protocols that firewalls can't inspect. And the connections between these environments — VPN tunnels, ExpressRoute circuits, API gateways — create trust relationships that are often poorly documented and inconsistently monitored.

The human challenge

Beyond the technical complexity, segmentation projects face organisational friction. OT teams are concerned about availability. Application owners are concerned about breaking connectivity. Change advisory boards demand evidence that changes are safe. And security teams often lack the operational context to design policies that work in practice. Segmentation programmes that fail almost always fail for organisational reasons, not technical ones.

3. Segmentation Principles

Effective segmentation is not primarily a technology project. It is an architectural discipline that requires clear principles. These principles guide every design decision and policy rule.

Principle 1: Segment by trust, not by location

The traditional approach of segmenting by physical location (building, floor, site) is insufficient in hybrid environments. Instead, segment by trust level: what sensitivity does the data have? What criticality does the system have? What are the consequences of compromise? Systems with similar trust requirements belong in the same zone, regardless of physical or virtual location.

Principle 2: Define conduits, not just zones

IEC 62443-3-2 introduces the concept of "conduits" — the controlled pathways between zones. This is where most segmentation designs fall short. It's not enough to place systems in separate VLANs; you must explicitly define what communication is permitted between zones, over what protocols, in what direction, and under what conditions. Every conduit should have a documented business justification.

Principle 3: Default deny, explicit allow

Every firewall and access control should default to denying traffic. Permitted flows are explicitly configured based on documented requirements. This sounds obvious, but in practice many organisations operate with default-allow policies and rely on blacklists to block known threats — a fundamentally weaker posture.

Principle 4: Production safety first

In OT environments, availability and safety are paramount. Segmentation must never compromise production operations or safety systems. This means extensive pre-implementation testing, graduated rollout (monitor mode before enforcement), and clear rollback procedures for every change.

Principle 5: Defence in depth across layers

Segmentation is one layer of a defence-in-depth strategy. It should be complemented by endpoint protection, identity and access management, monitoring and detection, and incident response capabilities. No single control is sufficient; the value of segmentation is that it constrains the blast radius when other controls fail.

4. Architecture Patterns

The Purdue Model for OT environments

The Purdue Enterprise Reference Architecture (PERA) provides the foundational model for OT network segmentation. It defines hierarchical levels from Level 0 (physical process) through Level 5 (enterprise network), with a critical Demilitarised Zone (DMZ) at Level 3.5 separating IT from OT.

The critical design decision is the IT/OT DMZ. This zone should contain only systems that need to bridge the IT/OT boundary: data historian mirrors (never the primary historian), patch management servers with controlled update windows, and jump servers for authenticated remote access. No direct traffic should flow from Level 5 to Level 2 or below.

Zero Trust for IT and cloud

On the IT side, Zero Trust architecture extends segmentation thinking beyond network boundaries. The principle "never trust, always verify" translates into micro-segmentation at the workload level, identity-based access controls, continuous verification of device posture, and encrypted communications between all services.

In cloud environments, this maps to VPC/VNET segmentation, security groups, network access control lists, and service mesh architectures. The cloud-native segmentation primitives are different from on-premises firewalls, but the principles are identical: define trust boundaries, control conduits, and default to deny.

The hybrid connection layer

The most architecturally challenging component is the connection between on-premises and cloud environments. VPN tunnels, ExpressRoute/Direct Connect circuits, and API gateways all create pathways that can bypass carefully designed on-premises segmentation. Each hybrid connection should be treated as a conduit: documented, monitored, and subject to access control policies that are at least as restrictive as the most sensitive zone it touches.

5. OT/ICS Special Considerations

Legacy protocol handling

OT environments commonly use protocols that predate modern security thinking: Modbus, DNP3, OPC Classic, PROFINET, EtherNet/IP. Many of these protocols lack authentication, encryption, or integrity checking. Segmentation compensates for protocol-level weaknesses by restricting which systems can communicate using these protocols and monitoring for anomalous traffic patterns.

Vendor access management

OT vendors frequently require remote access for maintenance, troubleshooting, and software updates. This access must be controlled through jump servers in the IT/OT DMZ, with session recording, time-limited access windows, and multi-factor authentication. Direct vendor VPN access into production OT networks is one of the most common — and most dangerous — architectural anti-patterns.

Safety system isolation

Safety Instrumented Systems (SIS) require additional isolation beyond standard segmentation. These systems protect human life and physical assets, and must be reachable only for authorised maintenance via physically controlled access or highly restricted network paths. SIS networks should never be accessible from corporate IT, cloud, or general OT networks.

6. Cloud Segmentation

VPC/VNET architecture

Cloud segmentation begins with VPC (AWS) or VNET (Azure) design. Each major workload or environment (production, staging, development) should have its own VPC/VNET with explicitly defined connectivity between them. Transit gateways or hub-spoke architectures provide centralised traffic inspection and policy enforcement.

Security groups and NACLs

Cloud-native security groups provide micro-segmentation at the instance level, while Network ACLs provide subnet-level controls. The two layers should work together: NACLs provide broad zone-level restrictions, while security groups enforce specific service-to-service policies.

Service mesh and API gateway controls

For containerised and microservices architectures, service mesh technologies (Istio, Linkerd) provide mutual TLS, traffic policies, and observability at the service level. API gateways control external access, rate limiting, and authentication. These represent the cloud-native evolution of traditional firewall-based segmentation.

7. Implementation Methodology

Segmentation implementation must be phased, reversible, and aligned with operational reality. The following methodology has been refined through multiple large-scale deployments.

Phase 1: Discovery and baseline (2–4 weeks)

Map all assets, communication flows, and dependencies. This phase is investigative, not disruptive. Use passive monitoring, configuration review, and interviews with operations teams to build the current-state architecture. Document every communication flow with source, destination, protocol, port, direction, and business justification.

Phase 2: Zone design (2–3 weeks)

Based on the discovery data, define zones and conduits. Group assets by trust level and function. Design the target architecture with firewall placement, routing changes, and access control policies. Review with operations, IT, and business stakeholders before proceeding.

Phase 3: Monitor mode deployment (2–4 weeks)

Deploy firewall rules in monitor/log-only mode. This is the critical validation step: the rules are active but not enforcing. All traffic that would be blocked is logged and reviewed. This phase catches communication flows that were missed during discovery and prevents production impact.

Phase 4: Graduated enforcement (4–8 weeks)

Move from monitor to enforce mode, one zone at a time, starting with the least critical. Each enforcement step has a defined rollback procedure and a monitoring period. Changes are made during agreed maintenance windows with operations teams on standby.

Phase 5: Continuous improvement

Segmentation is not a one-time project. New systems, new applications, and new business requirements continuously introduce new communication flows. Establish a process for reviewing and approving firewall rule changes, conducting periodic rule-set audits, and validating that segmentation controls remain effective.

8. Compliance Alignment

Well-designed segmentation satisfies requirements across multiple regulatory frameworks simultaneously.

9. Case Study

The following is a generalised case study based on composite experience across multiple manufacturing clients. Specific details have been anonymised.

Situation

A European manufacturer operating across multiple sites had a largely flat network. Corporate IT, engineering workstations, production PLCs, and vendor VPN connections all shared the same network infrastructure. A penetration test demonstrated that an attacker with access to a corporate laptop could reach production SCADA systems within 8 minutes.

Approach

We implemented a Purdue-model segmentation over 16 weeks. Phase 1 discovered 1,200+ OT assets and 340 unique communication flows. Phase 2 designed a 6-zone architecture with 12 defined conduits. Phase 3 monitored in log-only mode for 3 weeks, catching 47 undocumented communication flows. Phase 4 enforced zone by zone over 6 weeks, with zero production impact.

Results

Post-implementation penetration testing showed that lateral movement from corporate IT to production OT was no longer possible without passing through two firewall inspection points and a jump server with multi-factor authentication. The time-to-contain metric for simulated incidents dropped from 8 minutes (unlimited lateral movement) to requiring attacker dwell time exceeding 4 hours — sufficient for detection and response.

The segmentation programme simultaneously satisfied the client's NIS2 network security requirements, their ISO 27001 certification audit findings, and their parent company's IEC 62443 mandate.

10. Recommendations

For organisations starting their segmentation journey

Begin with discovery. You cannot segment what you don't understand. Invest 2–4 weeks in mapping your current architecture, communication flows, and dependencies before designing any zones or writing any firewall rules. The quality of your discovery determines the quality of your segmentation.

For organisations with partial segmentation

Audit what you have. Many organisations have VLANs and firewalls in place but with overly permissive rules, undocumented exceptions, or bypass paths. A rule-set audit and communication flow analysis often reveals that existing segmentation is less effective than assumed. Focus on tightening existing controls before adding new ones.

For organisations operating OT environments

Prioritise the IT/OT boundary. The single highest-impact segmentation action is establishing a properly designed IT/OT DMZ with controlled conduits. Eliminate direct vendor VPN access to production networks, deploy jump servers, and ensure that no traffic flows directly from corporate IT to Level 2 or below.

For all organisations

Treat segmentation as a programme, not a project. Networks change continuously. Without ongoing governance — rule-set reviews, change management integration, periodic re-assessment — segmentation degrades over time. Build the governance process alongside the technical implementation.