NCSC urges network device makers to improve forensic capabilities 

The UK’s National Cyber Security Centre (NCSC) is urging network device manufacturers to embed stronger “forensic observability” into their products to help organizations detect, investigate and respond to cyberattacks. 

New guidance, developed with international partners, calls on vendors to improve the collection and preservation of forensic data to support incident response and recovery. 

The guidance outlines 31 recommendations across areas including logging, time synchronization, event recording, forensic data collection and secure storage. NCSC said network devices are increasingly targeted by sophisticated threat actors, making it critical for organizations to have sufficient forensic evidence to determine how a compromise occurred and what systems were affected. 

Donald McFarlane, Advisory Board Member, Xcape, Inc Had this comment: 

“Government guidance is increasingly acknowledging that cybersecurity is about more than prevention, and that it requires enabling rapid investigation, containment, and recovery for when prevention fails. Forensic observability should be viewed as a core design requirement for network infrastructure, not an optional feature. 
 
“Network devices have historically prioritized forwarding packets over recording evidence. Today, defenders need trustworthy, tamper-resistant forensic data to determinewhat happened, what was affected, and how to recover. You can’t investigate what you didn’t record. 
 
“It’s also worth viewing this alongside the recent Five Eyes guidance on preparing critical infrastructure to operate while intentionally isolated from external dependencies during a major cyber incident. Those recommendations aren’t in tension: organizations must be prepared to operate independently during a crisis, but collective defense still depends on sharing high-quality telemetry, forensic evidence, and threat intelligence before and after an incident. Resilience requires both the ability to stand alone and the ability to learn together.” 

Denis Calderone, CTO, Suzu Labs follows with this: 

“We generally love the direction this guidance is heading. What the NCSC is really asking for is EDR-level telemetry on network devices, and I’d argue that it’s long overdue. This incorporates devices that sit on the perimeter.  These devices are the way into the target, the way attackers exfiltrate data out of the targets and are often the internal boundary that must be traversed while moving from zone to zone and internal network to network.  In short, they see an awful lot, and that’s the data you need when working a real incident. The telemetry they could be providing about attacker movement, tooling, and data flows between environments is invaluable for an investigation. During incident response it’s not uncommon for the handlers to request log data, only to find that it falls short of their needs. 

“If I had a nickel for every time I’d heard “oh, we weren’t collecting that log data”, or “it only goes back 2 days”, well, I’d have a lot of nickels. This could allow us to maybefinally see the early promises of SIEM come true, where all events were going to be perfectly correlated across all layers of the stack. If vendors actually deliver on this guidance, we may end up with meaningful telemetry from the network infrastructure flowing into the same correlation engines that are already processing endpoint and cloud data. You could trace lateral movement across zone boundaries, identify what tools the attacker used, and quantify how much data moved between segments. That changes the quality of an investigation completely.  

“There’s a lot in this, but one thing I really do like is the emphasis on log shipping and the recommendation that devices should alert administrators when remote logging is disabled or misconfigured. That’s a simple thing that would catch a lot of problems early, including attackers who disable logging as one of their first moves after compromise. It would be great to correlate all the data in an intelligent way, but just having the data there at all is a huge plus over what we often find during actual incidents. 

“It’s also worth noting that this isn’t just a UK initiative. CISA, the FBI, and the Australian, Canadian, and New Zealand equivalents all co-authored the underlying guidance back in February 2025, and NIST currently has nothing this specific for network devices. This is currently the most detailed framework out there for what manufacturers should be building, and it has Five Eyes backing.  

“The one concern I’d flag is telemetry overload, particularly around capturing all DNS queries on a busy network device. That’s a lot of data, and organizations that are already managing high SIEM costs and alert fatigue need to think carefully about how they consume and operationalize this without drowning in it. That said, the volatile data collection recommendations are excellent. Capturing the running state of a device during an incident, process trees, memory maps, network connections, and particularly the CAM tables and DHCP lease tables, that’s the kind of data that can completely change an investigation. Knowing which MAC addresses were on which switch ports and which IPs were leased at the time of compromise could be a real game changer during an actual incident.” 

Josh Marpet, Senior Product Security ConsultantFinite State: 

“The NCSC has put out a security posture recommendation. Network devices should be able to log, secure, and be forensically available for examination, for both volatile and static data. 

“Why? Because for so long, network device manufacturers built the cheapest hardware they could, to be competitive in price. But that means that firmware is squeezed into flash too small to back itself up, hardware doesn’t have the space to store logs, or have the capability to be attached to a forensic duplicator. 

“The NCSC is asking manufacturers to make sure that network devices, long the target of cybercriminals and rogue nation-states, can perform basic security hygiene and has the basic security and compliance capabilities to make it simpler and faster for enterprises to perform incident response, disaster recovery, and be a modern mature workplace. 

“None of it is extraordinary, most of it is fundamental steps. Rich log data, solid logs of all major events, protection of keys, physical protection of protected hardware modules (TPM, HSM, etc), and the ability to do remote logging and maybe even local logging. 

“Again, nothing crazy. Fundamental security, especially for a device that traffics all of the data from the enterprise. Good ideas. Solid guidance. Manufacturers! Follow it!!!” 

Basic logging and a basic security posture… Sounds like a very good idea to me. This should be copied elsewhere as the UK seems to have a few good ideas.

Leave a Reply

Discover more from The IT Nerd

Subscribe now to keep reading and get access to the full archive.

Continue reading