Network Security Policy Template: Perimeter Access and Network Device Rules

Most network compromises still come down to an inbound rule nobody owns, an exposed management interface or a router configuration holding a weak shared secret. This template gives you a network security policy covering the two areas the SANS policy library treats separately: perimeter network access management and network device management. It sets requirements for boundary filtering, segmentation, remote and wireless access, management plane protection, device credentials and configuration, logging and rule review. It is written for network, security and infrastructure teams, and for policy owners who need a document an auditor can test. Adapt the placeholders and have it reviewed by your legal, HR and compliance functions before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [Network Security Manager] and [90 days], with your own roles and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Requirements are numbered so that standards, procedures and audit tests can reference them (for example, NSP-4.3).
• Place this policy beneath your information security policy, alongside the Remote Access Policy Template, the Secure Configuration Policy Template and the Logging and Monitoring Policy Template. Do not repeat their detail here; cross-reference it.
• The values shown (review periods, retention times) are starting points drawn from public guidance. Set them from your own risk assessment and regulatory obligations.

1. Purpose

This policy sets the minimum requirements for protecting [Organisation] networks: how traffic is allowed to cross network boundaries, how networks are segmented, and how network devices are configured, administered and monitored. Its aim is that every permitted network flow has a documented business need and an owner, and that every network device is administered only by authenticated, authorised and logged identities over secure channels.

2. Scope

This policy applies to:

• All [Organisation] networks, including office, data centre, branch, industrial, laboratory, guest and wireless networks, and virtual networks in public cloud environments operated by or for [Organisation].
• All network devices, including routers, switches, firewalls, VPN concentrators, wireless controllers and access points, load balancers, proxies, web application firewalls, network access control systems and software-defined networking controllers, whether physical, virtual or cloud-native.
• All people and systems that design, administer or change network infrastructure, including employees, contractors, managed service providers and automation accounts.

Endpoint host firewalls are covered by the [Endpoint Security Policy]. User remote access methods are covered by the [Remote Access Policy]; this policy covers the network infrastructure those methods terminate on.

3. Roles and responsibilities

4. Policy statements: perimeter and boundary access

1. NSP-4.1 Default deny. All network boundaries, including internet edges, cloud security groups and internal zone boundaries, must deny traffic by default and permit only flows that are explicitly approved.
2. NSP-4.2 Documented business need. Every inbound rule from the internet, and every rule between security zones, must be approved by an authorised person and recorded with its business need, owner, source, destination, ports, protocol and review date.
3. NSP-4.3 Rule removal. Rules that are no longer needed must be removed or disabled. Temporary rules must carry an expiry date of no more than [30 days].
4. NSP-4.4 No unauthenticated inbound services. Unauthenticated inbound connections must be blocked unless the service is intentionally public (for example a public website) and is placed in a demilitarised zone (DMZ) or equivalent isolated segment.
5. NSP-4.5 Egress filtering. Outbound traffic from server and management networks should be restricted to required destinations, ports and protocols, including DNS through [approved resolvers].
6. NSP-4.6 Segmentation. Networks must be segmented into zones by function and sensitivity, at minimum separating user, server, management, guest, development and operational technology networks. Cross-zone flows are subject to NSP-4.2.
7. NSP-4.7 Remote access termination. Remote access services (VPN, ZTNA, virtual desktop gateways) must terminate in a controlled segment, must require multi-factor authentication and must be patched under the [Vulnerability Management Policy] with priority for known exploited vulnerabilities.
8. NSP-4.8 Third-party connections. Connections from third parties and MSPs must use a dedicated, logged access path limited to the systems the third party supports.
9. NSP-4.9 Wireless networks. Corporate wireless networks must use enterprise authentication (WPA2-Enterprise or WPA3-Enterprise with 802.1X, certificate-based where possible). Guest wireless must be isolated from corporate networks.
10. NSP-4.10 Intrusion detection and boundary inspection. Internet-facing boundaries and high-risk internal boundaries should be monitored by intrusion detection or prevention, and internet-facing web applications should be protected by a web application firewall where risk assessment requires.

5. Policy statements: network device management

1. NSP-5.1 Inventory. All network devices must be recorded in the [asset inventory] with owner, location, model, software version, support status and management address.
2. NSP-5.2 Supported software. Network devices must run vendor-supported software. Devices beyond end of support must have a dated replacement plan approved as an exception.
3. NSP-5.3 Management plane isolation. Device management interfaces must be reachable only from a dedicated management network or jump hosts. Management interfaces must not be exposed to the internet unless there is a documented business need, and then must be protected by multi-factor authentication or an IP allow list combined with managed password authentication.
4. NSP-5.4 Secure management protocols. Administration must use encrypted protocols (SSH version 2, HTTPS, SNMPv3 with authentication and privacy). Telnet, HTTP management and SNMPv1 or v2c must be disabled. Where legacy SNMP cannot yet be removed, community strings must be unique, non-default and read-only, and a dated removal plan recorded.
5. NSP-5.5 Centralised authentication. Administrators must authenticate with named accounts through a central authentication, authorisation and accounting service (for example TACACS+ or RADIUS backed by the [identity provider]), with multi-factor authentication where the platform supports it. Shared administrator accounts must not be used for routine work.
6. NSP-5.6 Local and emergency accounts. Each device may have one local emergency account for use when central authentication is unavailable. Its password must be unique per device, stored in [the privileged access vault], hashed on the device with the strongest algorithm supported, and rotated after every use.
7. NSP-5.7 Default credentials. Default passwords and accounts must be changed or disabled before a device is connected to any production network.
8. NSP-5.8 Shared secrets and keys. RADIUS and TACACS+ shared secrets, SNMPv3 keys, routing protocol authentication keys and API tokens must be unique per device or device group, stored in [the secrets manager] and rotated at least every [12 months] and after any suspected exposure.
9. NSP-5.9 Least functionality. Unused services, ports and interfaces must be disabled. Unused switch ports should be shut down or placed in an isolated VLAN.
10. NSP-5.10 Configuration baseline and change control. Each device class must have an approved hardening baseline. All configuration changes must follow the [Change Management Policy], and running configurations must be backed up and compared with the approved baseline at least [weekly] to detect drift.
11. NSP-5.11 Automation accounts. Accounts and tokens used by network automation, configuration management or monitoring tools must be named, owned, scoped to the minimum privilege and devices needed, and stored in [the secrets manager]. They must not be personal credentials.
12. NSP-5.12 Firmware integrity. Device software must be obtained from the vendor, verified using the vendor's published hashes or signatures where available, and checked for integrity after any suspected compromise using vendor-provided tools.

6. Logging, monitoring and review

1. NSP-6.1 Device logging. Network devices must send logs of administrator authentication, privilege use, configuration changes and security events to [the central log platform], with time synchronised to [approved NTP sources].
2. NSP-6.2 Boundary logging. Firewalls and remote access gateways must log permitted and denied connections at internet boundaries and between high-risk zones.
3. NSP-6.3 Retention. Network security logs must be retained for at least [12 months], with at least [90 days] immediately searchable, or longer where law or contract requires.
4. NSP-6.4 Alerting. Security operations must alert on, at minimum: configuration changes outside approved change windows; administrator logins from outside the management network; use of emergency local accounts; new inbound rules on internet boundaries; and repeated authentication failures on management interfaces.
5. NSP-6.5 Rule review. Internet boundary rules must be reviewed at least every [6 months] and internal zone rules at least every [12 months]. Rule owners must reconfirm business need or the rule is removed.
6. NSP-6.6 Architecture documentation. Network architecture diagrams, zone definitions and data flow records must be kept current and reviewed at least annually and after significant change.

7. Exceptions

Exceptions must be requested through [the exception process], state the requirement affected, the business reason, compensating controls and an expiry date of no more than [12 months]. Exceptions are approved by the [Network Security Manager] for medium risk and by the [CISO] for high risk, and are reviewed before expiry.

8. Compliance and enforcement

Compliance is measured through configuration audits, rule reviews, log reviews and internal audit. Unauthorised network devices or connections may be disconnected without notice. Breaches of this policy by staff may lead to disciplinary action under [HR policy]; breaches by third parties are handled under their contract.

9. Review and approval

This policy is reviewed at least annually by the [Network Security Manager] and approved by the [CISO]. Version: [1.0]. Approved: [date]. Next review: [date].

Implementation guidance

Where to start. Implement in this order: inventory and supported software (NSP-5.1, 5.2); management plane isolation and removal of default credentials (NSP-5.3, 5.7); centralised authentication and secrets (NSP-5.5, 5.6, 5.8); logging and alerting (NSP-6.1, 6.4); then the first full rule review (NSP-4.2, 4.3, 6.5). These give the most risk reduction for effort.

Why device credentials matter. In the Salt Typhoon Telecom Intrusions 2025, Cisco Talos found the attackers mostly logged in to network devices with legitimate stolen credentials, and that configuration files with SNMP read/write community strings, weakly encrypted local passwords and captured TACACS and RADIUS traffic exposed further secrets. NSP-5.4, 5.6 and 5.8 address exactly these weaknesses. See the Salt Typhoon Threat Actor Profile.

Testing and rollback. Apply new boundary rules in log-only or monitor mode first where the platform supports it, and stage rule removals: disable, monitor for [14 days], then delete. Keep the previous configuration backup so a change can be reverted within the change window.

Small and large organisations. A small organisation with one firewall and a managed router can meet most requirements through Cyber Essentials-style controls: change default passwords, keep the admin interface off the internet, document inbound rules and remove unused ones. Larger organisations should automate NSP-5.10 drift detection and NSP-6.5 rule reviews with firewall policy management tooling. See the Firewall Management Guide and the Firewall Rule Review Checklist.

Metrics to report. Percentage of network devices on supported software; percentage with management interfaces reachable only from the management network; number of internet-facing rules without an owner or past their review date; percentage of devices using central authentication; configuration drift events per month; median age of temporary rules.

Sources. This template draws on the SANS and Cybersecurity Risk Foundation Perimeter Network Access Management and Network Device Management policy templates (SANS: Information Security Policy Templates), the NCSC Cyber Essentials: Requirements for IT infrastructure v3.2 firewall and secure configuration requirements, NIST SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy, NIST SP 800-53 Rev. 5 and CIS Control 12 Network Infrastructure Management. For hardening detail, see the Network Device Management Plane Hardening Guide and the SNMP Security Guide.

Related NHI Mgmt Group resources: Network Security Guide · Network Segmentation Guide · Firewall Management Guide · Remote Access Policy Template