Keeping a network protected against cyber attack can appear daunting. This guidance suggests some simple steps around the acqusisition, management and dispsoal of devices that can reduce the chances of a successful attack.
Acquiring and deploying network devices
Acquisition and initial deployment of network devices into new and existing networks can inadvertently compromise the future security of the system. If the integrity of devices (or their initial configuration load) is not appropriately protected, then an attacker with access to the device will be able to allow themselves future access to information and protected systems.
Equipment acquisition and initial staging
All equipment should be procured through reputable channels to ensure it is genuine. Equipment should be staged in an appropriate environment prior to deployment into the final network.
Equipment reuse is only recommended between similar customer environments – such as converting an existing (non-encrypting) customer router into an encryption gateway, or redeployment of an encryption endpoint from one part of an organisation to another. Specific requirements for particular endpoints may be described in Security Procedures for those products.
In-field deployment
Equipment should be transported to the end location via a means that ensures tracking and traceability. If possible, delivery to an identified individual is preferred. Equipment should be transported in tamper-evident packaging, which should be verified intact before deployment.
It may be necessary to store endpoint equipment outside the staging environment, such as forward deploying it to a particular site in anticipation of future network service delivery. In such circumstances, the equipment should be stored in a broadly similar environment to that in which it would be used (for example, in the same data centre, communications room, or logistics facility). If this principle is maintained, and a full record kept of where the equipment has been stored, it is acceptable to redeploy unused equipment to other environments.
Initial enrolment and configuration
Depending on the nature of the VPN and the associated PKI, it may be possible to centrally load an enrolment profile onto endpoint devices. Alternatively, an engineer may need to load a specific initial configuration onto a device in-field for a particular environment and network. In either situation, the integrity of this initial configuration should be protected.
Configuration files and associated material should be produced and stored in a controlled manner, such that changes to them are audited and only made by authorised individuals. The mechanism by which these files are deployed and loaded onto endpoint devices needs to ensure that no unauthorised individuals would have the opportunity to modify them; this might be achieved through use of existing management infrastructure or through the application and inspection of digital signatures.
At the point of device deployment, it is likely that an endpoint certificate will need to be generated and enrolled into the relevant PKI. This technical process should be mirrored by business processes and activities within the management infrastructure of the PKI to ensure that only those devices which are expected to enrol are actually allowed to do so. For example, a prior entry might be required in a work tracking system for the field engineer to start the enrolment process, and for the PKI to authorise the enrolment of the device’s certificate.
Without such processes, it becomes more difficult to ensure that only those devices which require certificates have access to legitimate credentials, increasing the probability that unauthorised endpoints may be able to establish trusted communications with a network.
Managing network devices
Keeping a network protected against cyber attack can appear daunting. However, some simple steps to make attackers’ lives harder can reduce the chances of a successful attack.
Security of device information
Endpoint configuration information is generally not sensitive, with the exception of private keys, passwords and similar information derived from these values. The integrity of such information needs to be protected to ensure that endpoints are connected to the correct networks, and mis-configuration does not occur.
Management network
We strongly recommend that a management network should be created to perform administrative tasks on all network devices.
- Management of network elements should only be possible from the management network or from local management interfaces.
- Management terminals should only be used to access system management tools and the management interfaces of equipment. They should not be able to access other networks directly (such as the Internet) or open unfiltered rich content (such as emails and attachments, or content from file shares external to the management system). For example, internet browsing, or access to corporate resources, via a remote-desktop or similar ‘browse-down’ mechanisms would be acceptable.
- Access to the management network should be strictly controlled. Vendor and third-party access (for example to aid debugging) should not be enabled by default, but only permitted on a case-by-case basis for a time limited session, and with controls to ensure that only those activities expected can be performed.
- System management activity should be tied to business processes in a manner that allows effective auditing. It should be possible to trace a management change on a system to the individual(s) who performed it, and the reason for that change.
- Involving a qualified security architect in the design of the management network will help to ensure that the architecture defends against common attacks, has appropriate security controls, and allows effective secure operation of the service. Those with suitable skills should include CCP ‘IA Architects’ at the Senior or Lead levels.
Management staff clearances
Any individual who has unsupervised access to private keys for a substantial number of devices or across multiple customer organisations (or who has the ability to change the configuration of multiple devices at the same time) is in a privileged role, and should have had appropriate background checks. This is particularly important for engineers who would have the ability to alter the configuration of multiple devices, or affect the service of multiple customers.
Staff with management privileges should be cleared to at least the BPSS level BS7858:2012, or suitable equivalent. Organisations might consider enhanced measures of security screening for particularly privileged roles.
Device management
Management traffic must always be protected. Acceptable management approaches for assured devices are contained in their Security Procedures but, as a general principle, management traffic must be encrypted, its integrity protected, and authenticated at least as well as the user data it protects. IPsec, SSH and TLS are acceptable ways to achieve this.
| Traffic | Protection Recommended |
| Device management | SSH/IPsec/TLS, with cryptographic authentication of endpoints |
| CRL / OCSP | N/A as integrity-protected by design |
| Certificate enrolment protocols | Should be performed over a management link |
Wherever possible, management traffic must be separated from data traffic by physical or cryptographic mechanisms. If possible, management of devices should be via a separate physical or logical LAN, WAN, or loopback interface to data traffic. This helps minimise the attack surface of managed devices, and prevents would-be attackers from interfering with traffic and interfaces they don’t need to access.
Credentials which allow administrative access to devices must be controlled to ensure that only those who have a legitimate requirement are able to perform management functions. Engineers should only be given access to credentials for the devices they are responsible for maintaining. When an engineer changes roles, their accesses should be adjusted / revoked accordingly, and any device management passwords or private keys which they may have had access to must be changed.
It is also acceptable to use systems which broker access to devices, and do not require engineers to have direct access to privileged credentials.
Engineers with privileged access may also need to be monitored to ensure that their activities are compliant with policies governing their actions.
Device maintenance
In some circumstances you may need to return endpoint devices, or diagnostic information from devices (such as crash dumps or logs) to the device manufacturer to help solve issues. The main risk is that the device (or diagnostic information) may inadvertently contain user information or current credentials / keys, which may allow future access to the network.
We strongly recommend that vendors should not be given any kind of direct remote access to endpoint devices, but that such access – if required – be brokered and strictly controlled via the management network.
Prior to providing a vendor with a returned device or diagnostic information, any credentials associated with the device should be revoked or changed as appropriate. You probably won’t be able to completely remove sensitive information from returned diagnostic files or devices, and it may not be desirable to overwrite them as this may hinder any investigation. It is vital that the information owner(s) from any affected customer networks understand what action is planned, and what mechanisms are in place to protect any of their data that may remain within the device or diagnostic files. They must also agree that these mechanisms are appropriate, and that they are happy for their information to be potentially released in this way.
Establishing management connections
When it is necessary to establish management connections to endpoint devices from the management network, there should be technical and procedural measures in place to ensure that the connection is being made to an authentic device, and that the connection is not subject to interference. Ideally this would be through the use of previously established cryptographic trust (such as via the exchange of certificates, or via out-of-band validation of SSH fingerprints). Non-cryptographic mechanisms may introduce the possibility of such connections being subject to a man-in-the-middle attack, and should therefore be avoided.
Decommissioning and disposing of network devices
It is important that equipment decommissioning and disposal procedures do not inadvertently compromise information or networks. Devices which have been involved in providing security functionality for a network are likely to retain sensitive information within them, even when powered down. The goal is to ensure that devices are unlikely to contain any recoverable user information, and will not be able to reconnect to the encrypted network.
The following recommendations should be applied to all equipment involved in providing the encrypted network service:
- All certificates associated with a device (including operational, management and maintenance) should be revoked prior to device disposal.
- Any other credentials associated with a device should be changed or revoked as appropriate.
- The advice in our Secure sanitisation of storage media guide should be followed for any devices that have handled decrypted information.
- Factory resets or device wiping should be employed as a general precaution.
Specific circumstances
Any equipment, such as a VPN gateway, for which the NCSC has published Security Procedures, should be decommissioned and disposed of following the guidance in that document. Generally this will involve performing a low-level wipe of any configuration data stored in the device, followed by a reset to factory defaults. Any certificates or other credentials related to the device must be revoked and/or changed as appropriate.
Source: NCSC
