NETWORK SECURITY AND SEGMENTATION STANDARD

Zero-Trust Principles · Segmentation · Boundary Control · IT/OT Separation · Remote Access

Table of Contents

1. Purpose and Scope
2. Principles
3. Zero-Trust Architecture
4. Network Segmentation
5. Boundary Control
6. The IT/OT Boundary
7. Remote Access
8. Cloud Network Security
9. Network Monitoring
10. Roles and Responsibilities
11. Regulatory and Framework Alignment Summary
12. Document Control

1. Purpose and Scope

The network is where an intruder moves. A foothold on one system becomes a breach of the estate only if the network lets the intruder travel. The IT, OT, and Access standards each impose network-adjacent requirements; none of them owns the network itself. This standard does.

This standard establishes the requirements for network security across CERG-managed environments: the zero-trust principles that govern how access to network resources is decided, how the estate is segmented, how boundaries between segments are controlled, how the IT and OT networks are separated, how remote access is granted, and how networks are monitored.

It applies to every network CERG-managed systems use: physical and virtual networks in owned data centers, cloud virtual networks, the network paths to SaaS, and operational technology networks.

Segmentation Is What Turns an Incident Into a Contained Incident

Every significant breach retrospective contains the same sentence in some form: the attacker moved laterally from the initial foothold. Lateral movement is a network event. A flat network means one compromised laptop can reach the domain controller, the financial system, and the control network. A segmented network means the compromised laptop reaches the things that laptop legitimately needs and nothing else. Segmentation does not prevent the incident. It decides how bad the incident gets.

2. Principles

1. The network is not a trust boundary. Being on the internal network grants nothing. Access to a resource is decided per request against identity, device posture, and context, not by network location.
2. Default deny. Network paths are denied unless explicitly allowed. A segment, a firewall, a security group starts closed. Connectivity is added deliberately and recorded.
3. Segment by function and criticality. Systems are grouped into segments by what they do and how critical they are, per the criticality tiers in CERG-STD-AM-001. A breach in one segment does not become a breach of another for free.
4. The boundary is enforced and watched. Every boundary between segments is enforced by a control and monitored. An unenforced boundary is not a boundary.
5. OT is separated, not just segmented. The boundary between the IT network and the OT network is the most consequential boundary in the estate and is held to a higher bar than any other.
6. Every allowed path has an owner and a reason. A firewall rule, a security group entry, a peering connection exists because someone needed it and someone owns it. Rules with no owner and no recorded reason are removed.

3. Zero-Trust Architecture

CERG networks are designed toward the zero-trust model in NIST 800-207. The estate does not have to reach a fully mature zero-trust architecture on day one; it does have to move deliberately in that direction and never away from it.

1. Access is per-session and per-resource. A user or service is granted access to a specific resource for a specific session, not to a network zone indefinitely.
2. Every access decision uses identity and device posture. Access decisions combine the authenticated identity per CERG-STD-AC-001 with the posture of the device making the request per CERG-STD-EP-001.
3. Encryption in transit is assumed everywhere. Traffic is encrypted in transit per CERG-STD-CR-001, including traffic between internal segments. The network is treated as hostile.
4. The policy decision point is logged. Every access decision a zero-trust enforcement point makes is logged per CERG-STD-LM-001.

Zero Trust Is a Direction, Not a Product

No purchase makes an organization zero-trust. Zero trust is an architecture an estate moves toward over years: removing implicit network trust, adding identity and posture to access decisions, encrypting internal traffic, shrinking segments. CERG asks one thing of every network change: does it move the estate toward the zero-trust model, or away from it? Changes that move away from it are exceptions and are filed as such.

4. Network Segmentation

1. The estate is segmented. The network is divided into segments. A single flat network for the whole estate is not permitted for any environment beyond a trivial one.
2. Segments are defined by function and criticality. At minimum the estate separates: user endpoints, servers and production workloads, management and administrative interfaces, infrastructure and security tooling, untrusted and guest networks, and OT (Section 6). Critical-tier systems are segmented from lower-tier systems.
3. Management interfaces are isolated. Administrative and management interfaces of infrastructure are placed in a dedicated management segment reachable only through controlled paths. A management plane reachable from the user network is a finding.
4. Inter-segment traffic is default-deny. Traffic between segments is denied unless an explicit, owned rule allows it (Section 5).
5. Segmentation is documented. The segment map, what each segment contains and which segments may talk to which, is documented and kept current as an architecture artifact. An undocumented network cannot be reasoned about.

5. Boundary Control

1. Every inter-segment boundary is enforced. A boundary between segments is enforced by a firewall, a cloud security group, an access control list, or an equivalent control. The enforcement point is itself a Critical or High asset per CERG-STD-AM-001.
2. Rules are least-privilege. A boundary rule allows the narrowest source, destination, port, and protocol that satisfies the need. Any-to-any rules are prohibited except at a deliberately open boundary, and that exception is recorded.
3. Every rule has an owner and a reason. Each rule records who owns it and why it exists. A rule traceable to neither is removed.
4. Rules are reviewed. The boundary rule set is reviewed at least annually. The review removes rules that are no longer needed, tightens rules that are broader than needed, and confirms each remaining rule still has an owner. Stale rules accumulate; the review is how they are removed.
5. Rule changes are change-controlled. A change to a boundary rule set follows change management. For SOX-relevant boundaries, the change record is audit evidence.
6. The internet boundary is hardened. The boundary between the estate and the internet enforces both ingress and egress control. Unrestricted outbound traffic is a data-exfiltration path; egress is filtered and monitored.

6. The IT/OT Boundary

This section applies to organizations that operate operational technology. For NERC-CIP entities, it operates alongside the electronic security perimeter requirements in CERG-STD-OT-001; where the two are read together, the stricter requirement governs.

1. IT and OT networks are separated. The OT network is not a segment of the IT network. It is a separate network joined to IT only through a controlled, monitored boundary.
2. The boundary is a single, defined set of crossing points. Traffic crosses the IT/OT boundary only through a defined, minimal set of crossing points. Every crossing point is documented, enforced, and monitored. Undocumented crossings are findings of the highest severity.
3. The boundary is default-deny and minimal. Only the specific flows an operational need requires cross the boundary. The direction of each flow is constrained; data flowing out of OT for monitoring is not a path for traffic to flow into OT.
4. No direct internet path to OT. OT systems do not have a direct path to or from the internet. Remote access to OT follows Section 7 and the additional constraints of CERG-STD-OT-001.
5. The boundary is designed with IEC 62443 zones and conduits. The IT/OT boundary and the segmentation within OT use the zones-and-conduits model of IEC 62443.

The IT/OT Boundary Is the Most Important Boundary in the Estate

A compromise that crosses from IT into OT moves from a data problem to a physical and safety problem. The IT/OT boundary is held to a higher standard than any other boundary in CERG: fewer crossing points, tighter rules, stricter direction control, and continuous monitoring. When the IT/OT boundary requirement here and the electronic security perimeter requirement in the OT standard appear to differ, the stricter one is followed. There is no acceptable reason to relax this boundary for convenience.

7. Remote Access

1. Remote access is identified, authenticated, and authorized. Every remote connection into the estate authenticates the identity per CERG-STD-AC-001, including multi-factor authentication, and is authorized to a specific set of resources.
2. Remote access is least-privilege. A remote session reaches the resources the session needs, not the whole internal network. Remote access that drops a user onto a flat internal network is prohibited.
3. Device posture is checked. A device connecting remotely is checked for posture before access is granted, per CERG-STD-EP-001.
4. Remote administrative access is brokered and recorded. Privileged remote access to infrastructure goes through a privileged access broker per CERG-STD-AC-001. Privileged remote sessions are recorded.
5. Vendor and third-party remote access is time-bound and supervised. A vendor granted remote access receives it for a defined window, scoped to defined systems, and the access is removed when the window closes. Standing vendor access is prohibited. This aligns with CERG-PRC-TPRM-001.
6. Remote access to OT is exceptional. Remote access into the OT network is granted only where operationally necessary, is brokered, is supervised in real time where it affects control systems, and follows CERG-STD-OT-001.

8. Cloud Network Security

1. Cloud virtual networks are segmented. The principles in Sections 4 and 5 apply to cloud virtual networks: function-based segmentation, default-deny between subnets, least-privilege security groups, and owned rules.
2. The cloud landing zone enforces network baseline. Network segmentation, boundary defaults, and egress control are part of the cloud landing zone governed by CERG-STD-IT-001 and are enforced through infrastructure-as-code per CERG-STD-SDL-001.
3. Cloud-to-on-premises connectivity is a controlled boundary. A private interconnect or VPN between cloud and owned environments is an inter-segment boundary and is governed by Section 5.
4. Public exposure is deliberate. A cloud resource is reachable from the internet only by an explicit, owned decision. Inadvertent public exposure of storage, databases, or management interfaces is a finding.

9. Network Monitoring

1. Boundary enforcement points log. Firewalls, security groups, and other enforcement points send logs to the platform governed by CERG-STD-LM-001.
2. East-west traffic is visible. Monitoring covers traffic between internal segments, not only traffic crossing the internet boundary. Lateral movement is an east-west event; monitoring that sees only the perimeter does not see it.
3. The IT/OT boundary is continuously monitored. Every crossing point of the IT/OT boundary is monitored continuously, using OT-safe methods per CERG-STD-OT-001.
4. Detection content covers the network. Detection use cases include network-based indicators: anomalous inter-segment traffic, boundary rule violations, and unexpected egress. Detection content is owned per CERG-STD-LM-001.

10. Roles and Responsibilities

Roles below are the canonical role names from CERG-GOV-OM-001 §6.1.

11. Regulatory and Framework Alignment Summary

12. Document Control

Revision History

Review Triggers

• Material change to network architecture or to the cloud landing zone
• Revision of NIST 800-207, NERC-CIP CIP-005, or IEC 62443
• A significant incident involving lateral movement or boundary failure
• Internal audit or regulatory finding affecting network security
• Direction from the CISO

Cyber Engineering owns this document. The Engineering Pillar Leader (Platforms) is responsible for initiating reviews, managing the revision cycle, and obtaining Governance Pillar Leader approval, with CISO endorsement, for all changes.

Related Documents

Source: standards/CERG-STD-NET-001_Network_Security_and_Segmentation_Standard.md · Download .md · View on GitHub