Skip to content
Networking
ASD ISMISM-2162

ASD ISM 2162 Disabling or removing unneeded network device components and services

What it says

Unneeded components, services and functionality of network devices are disabled or removed.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Strip network devices back to what they actually need: switch off or take out any component, service or feature that has no business purpose, so it cannot be attacked.

Network devices such as routers, switches, firewalls and wireless access points ship with far more capability than most organisations ever use. Out of the box they often run legacy management protocols, discovery services, web interfaces, diagnostic tools, unused physical ports, optional modules and feature sets that nobody has asked for. This control says that if a component, service or piece of functionality on a network device is not needed, it should be disabled, or removed altogether where that is possible. It matters because every running service and enabled feature is something an attacker can probe, exploit or misuse. Unneeded services are the ones least likely to be patched, monitored or configured properly, precisely because nobody is thinking about them. A forgotten management protocol, an open diagnostic port or an unused module with a known vulnerability can give an attacker a foothold on the very devices that carry and segment all of the organisation's traffic. Compromising a network device is especially damaging because it can allow interception, redirection or disruption of traffic across many systems at once. The control covers three things on each network device: components (hardware and software modules, interfaces and ports), services (protocols and daemons the device runs) and functionality (features and capabilities that can be switched on or off). Anything in those categories that has no current business or operational need should be turned off or taken out, leaving only what the device requires to do its job.

Why it matters

If unneeded components, services and functionality are left active on network devices, the attack surface of the network's core infrastructure is larger than it needs to be. Attackers can exploit vulnerabilities in services nobody uses or monitors, use legacy or insecure protocols to gain management access, or abuse unused features to move laterally, intercept traffic or disrupt connectivity. Because network devices sit in the path of all traffic, a compromise through an unneeded service can affect every system behind that device, and the organisation carries ongoing patching and configuration burden for capability it gains nothing from.

How to implement

  1. Network administrators inventory every network device (routers, switches, firewalls, wireless controllers and access points, load balancers) and, for each one, enumerate the running services, enabled protocols, active interfaces and ports, installed modules and licensed feature sets using the device's show or status commands and management console.

  2. The network team, with input from system owners, classifies each enumerated item as needed or unneeded against a documented business or operational justification, and records the decision so that the reason for keeping any service is traceable.

  3. Network administrators disable every item classified as unneeded by shutting down unused interfaces and ports, turning off unnecessary protocols and management services (for example legacy or insecure discovery, remote access and file transfer services), and switching off unused features and functionality in the device configuration.

  4. Where the vendor supports it, network administrators remove unneeded components entirely, such as uninstalling optional software packages or feature bundles, removing unused physical modules or line cards, and deleting default or sample configurations that expose functionality the organisation does not use.

  5. The network team writes the resulting minimal configuration into a hardened build standard or configuration template per device model, applies it to all new and existing devices, and incorporates a check for re-enabled or newly introduced services into change management and firmware upgrade procedures so devices stay at the baseline.

Keep it running

In practice this control lives in the build standard and running configuration of each network device. Network teams maintain a documented baseline for each device type that lists which services, interfaces, modules and features are permitted to be enabled and why, and every device is built and hardened to that baseline before it goes into service.

Day to day, the main work is keeping devices at the baseline. Firmware upgrades, new feature licences, troubleshooting sessions and vendor defaults can quietly re-enable services or introduce new functionality, so configuration reviews and change management need to check that nothing unneeded has crept back in. When a service is enabled temporarily for diagnostics or a migration, it should be tracked and disabled again once the task is finished.

Where a component or feature can be physically or logically removed (an unused line card, an optional software package, a feature set that can be uninstalled), removal is preferable to simply disabling it, because it cannot be switched back on by accident. Where removal is not possible, the service or feature is disabled and the configuration is recorded so the decision is visible to anyone who later administers the device.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the hardened build standard or configuration template for each type of network device in use.

    Look at

    Look for an explicit list of the services, protocols, interfaces, modules and features that are permitted to be enabled, and confirmation that everything else is to be disabled or removed.

    Good evidence

    Each device type has a documented minimal baseline that names what is allowed and why, rather than relying on vendor defaults.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the running configurations of a sample of network devices selected across models, locations and roles.

    Look at

    Compare the running services, enabled protocols, active interfaces and feature sets against the documented baseline and look for anything enabled that has no recorded justification.

    Good evidence

    Sampled devices match the baseline, unused interfaces are shut down and unneeded protocols and features are disabled or absent from the configuration.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the inventory or register that records, per device, which components, services and functionality were assessed and the decision taken for each.

    Look at

    Check that the assessment covers all three categories (components, services and functionality), that unneeded items are marked as disabled or removed, and that any retained item has a stated business need.

    Good evidence

    There is a complete, current record showing the assessment was done for every device and that retained capability is justified rather than left on by default.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for change records and firmware upgrade records for network devices from a recent period.

    Look at

    Look for evidence that after upgrades or changes the device was checked for services or features that were re-enabled or newly introduced, and that any unneeded ones were disabled again.

    Good evidence

    Change and upgrade procedures include a post-change hardening check and the records show unneeded services being switched off after upgrades.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the results of the most recent internal review, configuration compliance scan or vulnerability scan of network devices.

    Look at

    Check whether the scan identified open ports, listening services or enabled features that should not be present, and whether findings were remediated.

    Good evidence

    Scans show only the expected services and ports, and any exceptions found were tracked to closure by disabling or removing the item.

Mappings

Closest match in ISO/IEC 27001: A.8.9, Configuration management for secure IT systems, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.