Network Security Procedure

1. Purpose

This procedure defines how networks that carry Organisation information are built, protected and operated. It protects information in transit, keeps unauthorised people and devices off the network, limits the spread of an attack, and keeps network services available. It supports the Communications and Operations Security Policy and the Access Control Policy.

2. Scope

• In scope: all local, wide-area, data centre, cloud, remote access and wireless networks and the equipment that forms them: switches, routers, firewalls, gateways, load balancers, wireless controllers and access points, VPN concentrators, DNS, DHCP and network management systems.
• In scope: networks supplied by third parties (carriers, hosting and cloud providers) to the extent of the Organisation's configuration and contract, and every user, device and service that connects.
• Out of scope: the internal design of public cloud provider backbones and the networks of customers; those are governed by contracts and by the Supplier Relationship Management Procedure.

3. Terms and Definitions

4. Roles and Responsibilities

5. Network Security Management

5.1 Network controls

The network is built as layers of control so that no single failure exposes the Organisation's information. These controls are mandatory for production and corporate networks.

• Default deny: traffic is blocked unless an approved rule allows it, in both directions at every boundary.
• Boundary protection: firewalls separate the internet, DMZ, corporate, server, management, guest and customer-facing zones, with intrusion detection or prevention on the internet edge.
• Management of devices uses a separate management network or encrypted out-of-band access, with multi-factor authentication and named accounts.
• Traffic that carries Confidential or Restricted data uses encryption between zones and over external links, following the Cryptography Procedure.
• Egress filtering and DNS filtering block known malicious destinations and categories that the Acceptable Usage Policy prohibits.
• Denial-of-service protection is arranged with the carrier or a scrubbing service for internet-facing services of Class 1.
• Redundancy: critical links and devices have a failover with a recovery time target of [15 minutes] and the failover is tested [annually].
• Network time, DNS and certificate services are protected and monitored as security-critical services.

5.2 Security of network services

Network services provided by internal teams or outside parties must have their security features, service levels and management needs defined before use. For each service the network team records them in the network service register (Annexure A).

Managed network and carrier suppliers are assessed before contract and reviewed [annually] under the Supplier Relationship Management Procedure. Unapproved network services, such as personal hotspots bridged to the corporate network, are not allowed.

5.3 Network documentation

Accurate documentation is a control in itself: it lets the Organisation find, protect and recover what it has. The network team maintains the following and reviews each [semi-annually] and after every significant change.

Diagrams that show security architecture are classified [Confidential] under the Information Classification and Handling Procedure.

5.4 System hardening

Every network device is hardened to the baseline configuration before it is placed in production. The baseline is reviewed [annually] and when vendor guidance changes.

1. ObtainTake the device from a trusted source and verify the software image against the supplier's checksum.
2. Reset defaultsChange all default accounts, passwords, community strings and keys. Remove unnecessary accounts.
3. DisableTurn off unused services, ports, protocols and legacy features such as Telnet, plain HTTP management and insecure SNMP versions.
4. ConfigureEnable encrypted management, secure time, logging to the central platform, banner text, session timeouts, and role-based administration.
5. PatchApply current software before use and thereafter according to the Patch Management Procedure.
6. VerifyA second engineer checks the configuration against the baseline checklist; scanning confirms no unintended exposure. Evidence: checklist signed in the change record.

6. Network Access Control

6.1 Policy on use of network services

• Access to the network is granted on a need-to-use basis according to role, and follows the Access Control Policy.
• Only services that the user's role requires are reachable. Access to production zones requires an approved request and is limited to named people and addresses.
• Authentication is required to join any network other than the guest network; Organisation-owned and managed devices are authenticated by certificate, user credentials, or both.
• Use of the networks is monitored and logged. Users must not attempt to bypass controls, connect unauthorised devices, run network scanners or share their access.

6.2 Remote access registration

Remote access to internal resources is available only through the approved VPN or zero-trust gateway, with multi-factor authentication and device compliance checks.

1. RequestThe user's line manager submits a remote access request in the ticketing tool, naming the systems, justification and duration. Input: remote access request form (Annexure B).
2. ApproveThe system owner approves access to each system; the Head of IT Security approves any privileged or third-party access. Target: [2 working days].
3. PrepareThe service desk confirms the device is enrolled and compliant, creates the account in the right group, issues a hardware or app-based second factor, and records the grant in the remote access register.
4. BriefThe user accepts the remote access terms: use only for work, no sharing of tokens, no split tunnelling unless permitted, no use from unsecured public computers.
5. ActivateAccess starts on the approved date and carries an expiry date no later than [12 months]; third-party access is limited to the contract period or [90 days], whichever is shorter.
6. ReviewOwners recertify remote access every [6 months]. Unused accounts are disabled after [60 days] of inactivity.

6.3 Remote access termination

1. TriggerHR, the line manager, the contract manager or the system owner informs the service desk that access should end: leaver, role change, contract end, device loss, security concern or expiry reached.
2. DisableThe service desk disables VPN and gateway accounts and revokes certificates and tokens. Target: same day as the trigger, and within [1 hour] for dismissals or suspected compromise.
3. RemoveRemove the user from groups and the remote access register, collect hardware tokens, and wipe or remove the work profile from devices.
4. VerifyCheck logs for activity after the termination time. Any activity is an incident.
5. RecordClose the ticket with times and evidence. The Head of IT Security sample-checks [10 percent] of terminations [quarterly].

6.4 Equipment identification in networks

• Every device that connects to a wired or wireless network is identified by a unique asset identifier, hardware address and owner in the asset register.
• Network access control authenticates corporate devices through certificates. Unknown devices are placed in a quarantine or guest segment, or blocked.
• Network discovery scans run [weekly] to compare what is connected with the inventory. Unrecognised devices are investigated within [1 working day] and removed if not approved.
• Hardware addresses alone are not treated as proof of identity because they can be copied.
• Printers, cameras, door controllers and operational technology are placed in dedicated segments and are inventoried like any other device.

6.5 Remote diagnostic and configuration ports

Diagnostic, console and maintenance ports on network and server equipment are disabled or protected by physical lock and authentication. Remote vendor maintenance is allowed only through a session that the Organisation enables for the duration of the task, with a ticket reference, a named engineer, session recording and disabling afterwards. Cables to console ports are kept secure and unused ports are shut down.

6.6 Segregation in networks

The network is divided into zones so that an attack in one cannot spread freely. Zone boundaries enforce rules according to trust and data classification.

Segmentation is verified by testing [annually] and after major changes, using the Vulnerability Assessment and Penetration Testing Procedure.

6.7 Network connection control

• Firewall rules follow the pattern: source, destination, port, protocol, reason, owner, expiry. Rules with any in source, destination or service require Head of IT Security approval.
• Each rule is requested by the system owner, reviewed by security, and implemented through a change record. Emergency rules follow the emergency change path and are reviewed within [2 working days].
• The rule base is reviewed [every 6 months]. Rules unused for [90 days], expired rules, shadowed rules and rules with no owner are removed.
• Connections between the Organisation and third parties go through the boundary firewall with named endpoints, encryption and a contract that covers security.
• Routing controls prevent unwanted traffic paths; spoofed addresses are dropped at the edge.

7. Wireless Network Security

Wireless networks extend the boundary beyond walls, so they have stricter controls. Only wireless networks run by the Organisation's network team are allowed.

7.1 Authorised equipment and use

• Only the network team installs access points and controllers. Staff must not attach personal routers, hotspots or access points to the network.
• Rogue access point detection runs continuously; detection triggers an alert within [15 minutes].
• Wireless use is for work, and follows the Acceptable Usage Policy.

7.2 Wireless network configuration

• Hide management interfaces from users, disable WPS and legacy protocols, and change default settings.
• Set transmit power and coverage so signals reach as little as possible beyond the premises.
• Shared pre-shared keys are not used on the corporate network; guest keys change at least [quarterly] where used.
• Wireless is tested for coverage, rogue access points and configuration drift [semi-annually].

7.3 Authentication and authorisation

Corporate wireless access requires the user's directory identity and a compliant device. Access is removed when the account or device is disabled. Guests receive limited, time-bound access, usually [8 hours], with a record of the sponsor and the device in the visitor log.

8. Cloud Network Security

Cloud networks are configured in the same way as on-premises networks, with the Organisation holding responsibility for what it configures, and the provider for the underlying infrastructure. The Cloud Computing Security Policy and Procedure covers the wider cloud controls.

• Virtual networks have separate subnets and security groups for public, application, data and management tiers. Databases have no public addresses.
• Security groups and network access lists follow default deny, with rules reviewed [every 6 months] and changes made through infrastructure-as-code reviewed by a second person.
• Administrative access to cloud consoles and APIs requires multi-factor authentication, least privilege and logging to the central platform. Console access from untrusted networks is blocked.
• Private connectivity or encrypted tunnels link cloud and on-premises networks. Management endpoints are not exposed to the internet.
• Flow logs, firewall logs and cloud configuration changes are enabled and retained under the Logging and Monitoring Procedure.
• Public storage and public endpoints are created only through an approved pattern; an automatic scan alerts within [1 hour] on a public exposure of Confidential or Restricted data.
• Web application firewalls and rate limits protect internet-facing applications; denial-of-service protection is enabled for Class 1.
• Cloud environments for development and production are in separate accounts or subscriptions with distinct credentials.

9. Network Vulnerability Management

1. DiscoverThe network team and security operations scan all zones for assets and vulnerabilities on the schedule below. Output: scan reports.
2. AssessFindings are rated by severity, exposure and exploitability. Internet-exposed critical findings are escalated at once.
3. RemediateFix according to the timelines in the Patch Management Procedure: Critical [7 days], High [30 days], Medium [90 days]. Where a fix is not possible, apply compensating controls and record an exception.
4. VerifyRescan to confirm closure. The Head of IT Security reviews open items [monthly].
5. TestAn independent penetration test of the external perimeter and segmentation is carried out [annually] and after major change, under the Vulnerability Assessment and Penetration Testing Procedure.

10. Network Change and Lifecycle

10.1 Network changes

1. RequestThe requester raises a change describing the purpose, devices affected, back-out plan and testing, as described in the Change Management Policy and Procedure.
2. AssessThe network team and security assess risk to confidentiality, integrity and availability. Changes to a boundary, a Restricted data zone or the management network need Head of IT Security approval.
3. ScheduleNormal changes are made in an approved window with notice to users of at least [2 working days]. Emergency changes are approved by the on-call manager and reviewed afterwards within [2 working days].
4. Implement and testMake the change, check connectivity and security tests, and compare the new configuration with the baseline.
5. CloseUpdate diagrams, inventory and rule registers within [5 working days] and record the outcome.

10.2 Equipment lifecycle

• Devices are replaced before vendor support ends. A device that will lose support within [12 months] is placed on the replacement plan; devices past support need a recorded exception and compensating controls.
• Retired devices have their configurations and keys erased using the sanitisation methods in the Information Classification and Handling Procedure, and the asset register is updated.
• Spare equipment is stored securely and configured from the baseline only at deployment.

11. Network Monitoring and Incident Handling

Network telemetry is sent to the central logging platform and watched by the security operations team, using the alert rules in the Logging and Monitoring Procedure.

12. Internet Use and Web Filtering

• Web filtering blocks sites in categories the Acceptable Usage Policy prohibits, known malware and phishing sites, and uncategorised new domains for [24 hours] where practicable.
• Filtering applies to corporate devices on any network through the endpoint agent or secure web gateway, not only in offices.
• Exceptions for research or investigation are approved by the Head of IT Security for a named person and time, and are logged.
• Encrypted traffic inspection is used on the web gateway where the data protection officer has approved it, with staff informed and categories such as banking and health excluded.

13. Reporting

The network team reports to the Head of IT Operations [monthly], and the Head of IT Security includes network security metrics in the report to the ISMS steering group [quarterly]. Security events on the network go to the security operations team immediately and follow the Incident Management Procedure.

14. Measures

15. Records and Evidence

Annexure A: Network service register

Annexure B: Remote access request and register

Annexure C: Firewall rule change request

16. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

17. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

18. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Communications and Operations Security Policy
• Secure Configuration Policy
• Logging and Monitoring Procedure
• Patch Management Procedure
• Access Control Policy
• Cloud Computing Security Policy and Procedure
• Vulnerability Assessment and Penetration Testing Procedure
• User Access Management Procedure