Information Security: Network Protection Standard

Original Issuance Date: November 9, 2022
Last Revision Date: January 19, 2023
Effective Date: December 1, 2023

1. Purpose of Procedures

To provide structure and guidance for the deployment and management of Information Technology (IT) network controls used to mitigate Information Security (IS) threats throughout the University of Wisconsin (UW) System.

2. Responsible UW System Officer

Associate Vice President for Information Security

3. Definitions

Please see SYS 1000, Information Security: General Terms and Definitions, for a list of general terms and definitions. Terms and definitions found within this procedure include:

External Network
High Risk
Managed Interface
Moderate Risk
Network Backbone Connection
Network Security Zone
Remote Access
Research Network
Split Tunneling
System Boundary
Transit Peer Link
Trusted Network Security Zone
Untrusted Network Security Zone
Zero Trust Architecture

4. Procedures

A. Standards

Network Security Architecture Documentation Requirements
Institutions are required to maintain documentation of their network security architecture as an artifact of their network design, deploy, and maintain processes. The documentation must provide a high-level view of the network and security controls that transport data for the institution’s information systems, including the following:
1. Identify the Trusted and Untrusted Network Security Zones in the System Boundary and the connections to External Networks. For each Trusted Network Zone, identify the institution-defined trust level and, if applicable, whether it is a Network Backbone Connection, Transit Peer Link, or Research Network.
2. Identify the security services and mechanisms that provide the required network security an controls to support the data security requirements for the institution.
  1. Identify the key Managed Interfaces between Network Security Zones and the connections to External Networks.
  2. Identify Virtual Private Networks (VPNs) and where Split Tunneling is implemented.
  3. For secure remote management of Managed Interfaces, identify where mechanisms that supplement the operational network controls are used, including out-of-band access or a jump box on a secure network.
  4. For Trusted Network Security Zones that support systems with Moderate Risk and High Risk data and connect with External or lower level Network Security Zones, identify where security controls for data transit protection are provided by non-network or external security services, e.g., application-level encryption, IPsec Tunnel, and/or Zero Trust Architecture controls.
  5. For Network Backbone Connections, Transit Peer Links, or Research Networks, document the technologies and processes to secure these specialized Trusted Network Security Zones.
3. At the external interfaces, identify the demarcations of responsibilities between the institution and the external network provider(s) so it is clear who is responsible for the components and services.
4. High-level diagram(s) of the institution’s network security architecture must be included in the documentation, and diagram(s) must be reviewed at least semiannually to verify they remain current. The diagram(s) must provide a high-level visual representation of how the networks in the System Boundary fit together and provide a framework and vocabulary for the network controls and data transit. The diagram must illustrate the key types of controls at the external boundaries and between Trusted and Untrusted Network Security Zones. Institutions determine the format and structure of the diagram(s) that best support their operations. Note that diagrams created for compliance requirements (e.g., PCI DSS) while they may be more detailed for those data flows, can be used for the applicable Network Security Zones.
Network Access Controls
The following network access controls must be used to control and monitor network communications:
1. Physically and/or logically separate Network Security Zones. Untrusted Network Security Zones must be separated from Trusted Network Security Zones, and Trusted Network Security Zones with different levels of security must be separated. Examples of logical separation include, but not limited to: encryption, device partitioning, and network traffic filtering. Example technologies available to meet logical separation objectives include, but not limited to: firewalls, logical VLANs, L3/L2 VPNs, and IPsec tunnels.
2. Restrict the flow of data at the connections between the Network Security Zones, as defined in the institution’s network security architecture. For Trusted Network Security Zones, control inbound (ingress) data flow to prevent unauthorized access to the network, and control outbound (egress) data flow to prevent unauthorized outbound connectivity from servers. Note, egress controls are not intended for workstations and end user devices.
  Example controls include, but are not limited to: denying all inbound traffic except as part of a connection initiated from within the Network Security Zone, or denying all inbound traffic except as part of a connection initiated from within the Network Security Zone and when explicitly permitted for defined services. Example technologies available include, but are not limited to: firewalls, network Access Control Lists (ACLs), and security groups.
3. Where Trusted Network Security Zones include Remote Access, employ the following, or as defined by the institution’s network security architecture. These controls do not apply to public web servers or systems designed for public access.
  1. Where data transit security for Remote Access is provided by the service at the application layer, provide network access controls to ensure routing to the service application layer. Examples include remote desktops and application enforced SSL protection.
  2. Require client VPN for Remote Access when services require the remote endpoint device to appear to be on the local network.
  3. For VPN implementations, prevent Split Tunneling for remote devices connecting through organizational Trusted Network Security Zones unless the split tunnel is securely provisioned to only route specific named managed environments and/or specific addresses/ports to the VPN tunnel or to the default gateway. The provisioning process must use institution-defined and documented approval procedures, and the approval procedures must include documented purpose and approval.
4. For Moderate Risk and High Risk data that traverse External Networks, Untrusted or lower level Network Security Zones (see examples below), the institution must ensure security services meet the data transit control requirements as defined by the institution’s network security architecture. These controls may include application-level encryption, IPsec Tunnel, physical controls (hardware and discrete fiber channels), IPsec VPN tunnel, monitoring, and Zero Trust Architecture controls.
  Examples of Trusted Network Zones where data transit protection services may be provided by non-network or external security services include, but are not limited to: Network Backbone Connections, Transit Links, between data centers, between data center and cloud service, and Research Networks. They may also include institution-defined architectures for performance and network throughput requirements, technical limitations, and to avoid redundancy when non-network controls provide sufficient network security.
  For Network Zones with Zero Trust Architecture implementations, the institution must implement a set of controls that are designed to work in combination to meet the control requirements for the data. These are institution-defined and are typically a coordinated combination of user authentication and device authentication, and access rights that are continuously evaluated.
Network Communication Protection Activities
The following is required when network controls use cryptographic mechanisms to provide confidentiality and integrity services for information transmitted over secure Network Zones.
1. National Institute of Standards and Technology (NIST)-approved cryptography standards must be used.
2. Cryptographic keys must be established and managed according to institution- defined requirements for key generation, distribution, storage, access, destruction, and recovery when applicable. The institution’s key management requirements may be informed by NIST SP 800-57-3, Recommendation for Key Management, Part3: Application-Specific Key Management Guidance.
3. Public key certificates must be issued by an appropriate Certificate Authority in accordance with the institution’s network security architecture.
Network Configuration Management
1. Using institution-defined configuration management processes, ensure manual configuration changes to security controls for institution-defined key Managed Interfaces are documented. Documentation must include who made the change and when. Institutions may require additional configuration management documentation, including the reason for change, business need, contact, and the expected time the change will stay in effect.
2. Administrator access on network devices must be implemented in accordance with the principle of least privilege, with access only provided to administrators that need access to perform their job functions.
Network Device Security
1. Physical security – limit authorized access to the physical location of network IT assets commensurate with the risk of the assets.
2. Logical security – remote management access to network IT assets must include the following:
  1. Employ access control restrictions on open management ports.
  2. Disable unencrypted remote administration protocols, such as telnet and ftp, or document in institution’s network architecture why the protocols are required.
  3. Use SNMPv3 with at least encrypted authentication when using SNMP community write strings.
  4. For key management interfaces, as identified in the institution network architecture, ensure secure transmission for remote management. For lower trust Network Security Zones, this may require controls that are supplemental to the operational network, examples include a special purpose management network or a jump box on a higher Trusted Network Security Zone.
3. Disable or remove network services, ports, and protocols that are not necessary for the intended purpose or operation of a device, as defined by the network architecture (e.g., discovery protocols, source routing, HTTP and Bootstrap Protocol).
4. Network devices with compute resources, e.g., application hosting, containers, and Guest Shell access, must be in accordance with the institution’s network security architecture.