Skip to content
Networking
ASD ISMISM-2161

ASD ISM 2161 Verify network device firmware and configuration against known-good baseline

What it says

The integrity of network device firmware and running configurations is verified against an approved known-good baseline following patching, on detection of anomalous behaviour and at least monthly.

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

What it means

In plain English

Compare each network device's firmware and running configuration to an approved baseline after patching, when something looks wrong, and at least every month.

Network devices such as routers, switches, firewalls and wireless controllers run two things an attacker would love to quietly alter: the firmware (the device's operating software) and the running configuration (the rules and settings it applies right now). This control asks you to keep an approved, known-good copy of both for every device and then check the live device against that copy at three points: straight after any patch or firmware update, whenever the device or the network starts behaving strangely, and on a routine cycle no longer than a month. It matters because network devices sit in the path of all traffic and are a favoured foothold. Implanted firmware or a single added configuration line (a new admin account, a changed ACL, a mirrored port, a diverted route) can persist for months without anyone noticing, because the device keeps forwarding packets normally. A post-patch check confirms the update landed cleanly and nothing rode in with it. An anomaly-triggered check turns a vague "the firewall is acting odd" into a concrete answer about whether the device has been tampered with. The monthly floor catches slow drift and changes that slipped past change management.

Why it matters

Without baseline verification, unauthorised firmware implants or configuration changes on network devices can go undetected indefinitely. An attacker who has modified a device can intercept, redirect or copy traffic, open persistent remote access, weaken firewall rules or disable logging, and the organisation has no reliable way to tell a trusted device from a compromised one. A failed or tampered patch may also leave a device in an unknown state that undermines every other control depending on the network. Detection is delayed until the damage is visible, and incident response is slower because there is no trusted reference to compare against.

How to implement

  1. Network team lead: build and approve a known-good baseline for every in-scope network device by capturing the sanctioned firmware version and image hash together with the approved running configuration, storing it in a version-controlled repository that only the change process can update.

  2. Network engineers: add a post-patch verification step to the patching procedure, so that after every firmware or software update the engineer confirms the installed image and hash match the approved version and diffs the running configuration against the baseline before closing the change ticket.

  3. Network operations team: deploy a configuration-management or monitoring tool that pulls running configurations and firmware details from all devices on a schedule of at least monthly, diffs them against the stored baseline and raises an alert to a named owner for any difference.

  4. SOC and network on-call staff: write an integrity check into the triage playbook for anomalous device or network behaviour, so that whenever an alert or ticket indicates something unusual the responder compares the affected device's firmware and running configuration to the baseline and records the result in the incident.

  5. Change manager: require that every approved change to a network device also updates the baseline record, and review the monthly verification results to confirm that every reported difference is either matched to an approved change or escalated as a security incident.

Keep it running

Day to day, the network team maintains an approved baseline per device (or per device class where configurations are templated) that records the sanctioned firmware version and hash plus the approved running configuration. The baseline is updated only through the change process, so that every legitimate change moves the baseline and every unexplained difference stands out.

Verification runs at three triggers. After patching, the engineer who applied the update (or the automation that did) confirms the installed firmware matches the approved version and image hash and that the running configuration still matches the baseline, then records the result in the change ticket. When monitoring, help-desk tickets or the SOC flag anomalous behaviour on or around a device, an integrity check is added to the triage steps and its result feeds the incident record. Independently of both, a scheduled job compares every in-scope device at least monthly and reports differences to a named owner.

Differences are treated as findings: either the change is traced to an approved ticket and the baseline is corrected, or it is unexplained and handled as a potential security incident. The team keeps the schedule, the exception list and the results so the cycle can be shown to have run.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the approved known-good baseline records for a sample of network devices, including firmware version, image hash and running configuration.

    Look at

    Check that a baseline exists for each sampled device, that it is marked as approved, and that its history shows updates tied to change records.

    Good evidence

    Every in-scope device has a current, approved baseline held under change control, with no devices missing and no unapproved edits.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the scheduled integrity verification results for the last three months.

    Look at

    Confirm the comparison ran against all in-scope devices at least once in each month and that each run covered both firmware and running configuration.

    Good evidence

    There is an unbroken monthly record, coverage matches the device inventory, and any gaps are explained and approved.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for recent network device patching change tickets.

    Look at

    Look for a recorded post-patch verification step showing the installed firmware and running configuration were compared to the baseline before the change was closed.

    Good evidence

    Each patching ticket contains the verification result and the engineer who performed it, with no tickets closed without the check.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for incident or alert records where a network device showed anomalous behaviour.

    Look at

    Check whether an integrity check against the baseline was performed as part of the response and what it found.

    Good evidence

    Anomaly responses consistently include a firmware and configuration comparison, and the outcome is documented in the incident record.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the list of differences the verification process reported and how each was handled.

    Look at

    Trace a sample of differences to either an approved change that updated the baseline or a security incident that was investigated.

    Good evidence

    No difference is left unexplained; each is closed as an approved change or escalated and resolved as a potential compromise.

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: 3 mappings

  • A.8.9Configuration management for secure IT systemsPartially meets
  • A.8.20Network and network devices securityPartially meets
  • A.8.32Change management procedures for information systemsSupports

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