Zero Entropy Networks All articles
Zero-Trust Strategy

The Disorder Ledger: Why Network Entropy Belongs on the Board Agenda Before Zero-Trust Spend

Zero Entropy Networks
The Disorder Ledger: Why Network Entropy Belongs on the Board Agenda Before Zero-Trust Spend

Photo: Stephen Craven, CC BY-SA 2.0, via Wikimedia Commons

Zero-trust programmes rarely fail because the chosen platform was wrong. They fail because the organisation cannot see, name or evidence what it is trying to protect. Before a UK CIO signs a multi-year zero-trust contract, the more useful question is not which vendor has the strongest identity graph. It is how much disorder already exists in the network, and whether that disorder has been measured.

Network entropy is a useful term for that disorder. It is the accumulation of unmanaged change: firewall rules that no one owns, cloud security groups that drift from baseline, shadow SaaS bought on a corporate card, endpoints missing from the configuration management database, stale accounts with standing privileges, and flat network segments that still allow lateral movement. Entropy is not a security incident. It is the condition that makes incidents more likely and recovery harder.

Why entropy precedes architecture

Zero trust depends on known assets, known identities and enforceable policy. If a fifth of the estate is invisible, policy coverage is a fiction. If access rules have accumulated for a decade, least privilege is a diagram rather than an operating model. If segmentation exists only on a Visio slide, microsegmentation will expose the gap rather than close it.

For UK leaders, this is also an assurance issue. The NCSC Cyber Assessment Framework is not a product checklist. It asks organisations to demonstrate governance, risk management, asset management, identity control, resilient networks, monitoring and recovery. An entropy audit produces evidence for those outcomes before a platform procurement begins. It also gives the board a trend line rather than a one-off assurance statement.

A practical scoring model

The aim is not perfect precision. It is a defensible baseline that operations teams recognise and executives can act on. A five-domain model is usually sufficient for a first pass. Each domain is scored from 0 to 4, where 0 means controlled and evidenced, 1 means mostly controlled, 2 means partial, 3 means weak, and 4 means chaotic or unknown. Weights reflect the degree to which the domain undermines zero-trust outcomes.

Domain Weight What to examine
Configuration drift 20% Firewall, switch, cloud security group and proxy changes against approved baselines; age of rules; percentage with named owners
Asset visibility 25% Managed versus unmanaged endpoints, servers, OT and IoT; CMDB coverage; discovery-tool reconciliation
Identity and access hygiene 25% Stale accounts, orphaned service identities, standing admin rights, MFA coverage, joiner-mover-leaver evidence
Shadow IT and unsanctioned SaaS 15% Expense data, DNS and proxy logs, SaaS discovery, departmental purchases outside IT
Segmentation integrity 15% Flat VLANs, any-any rules, lateral paths between user, server, OT and guest estates; east-west test results

The weighted score is converted to a 0–100 index where higher is worse: sum the weighted domain scores, divide by four, and multiply by 100. A score below 25 indicates a controlled baseline. 26–50 is moderate and suitable for phased zero-trust work. 51–75 is high: fix visibility and identity before large platform commitments. Above 75 is severe: the organisation is buying policy enforcement for an estate it cannot yet describe.

Mapping the score to the NCSC CAF

The value of the model is that it turns technical housekeeping into assurance language. Asset visibility maps to CAF principle A3 on asset management and B4 on system security. Identity hygiene maps to B2 on identity and access control. Configuration drift maps to B4 and B5 on resilient networks. Shadow IT touches A4 on supply chain and B1 on service protection policies. Segmentation integrity supports B5 and D1 on response planning, because bounded incidents are easier to contain.

The audit should not be run as a security-team scoring exercise alone. Network operations, identity teams, procurement and service owners should each validate the evidence. A score that operations does not recognise will be dismissed. A score that finance can compare quarter on quarter becomes a management metric.

Running the audit without buying a platform

Start with existing telemetry. A configuration management database, endpoint detection and response console, identity provider, cloud security posture tool and firewall management system will usually provide enough evidence for a first pass. Where data is missing, record the gap as a finding rather than guessing. Sample manually: inspect twenty high-risk firewall rules, twenty leavers, twenty service accounts and a representative set of operational technology segments. The sample is not statistically perfect, but it is operationally credible.

Produce a one-page heat map and a ninety-day remediation plan. Prioritise identity hygiene, asset discovery and removal of unnecessary lateral paths. These actions reduce entropy and improve zero-trust readiness at the same time. They also tend to be cheaper than platform licences.

From baseline to buying decision

An entropy score changes the procurement conversation. Instead of asking a vendor to deliver zero trust, the CIO can ask how the platform will integrate with the existing identity provider, how it will discover unmanaged assets, how it will support migration from legacy rules, and how success will be measured against the baseline. Contract terms should include exit provisions and evidence of interoperability, not just deployment milestones.

The board should see the score as a resilience indicator, not a compliance badge. Re-score quarterly. A falling index is evidence that the organisation is becoming more governable. A rising index is an early warning that change is outrunning control.

Zero trust remains the right destination for most UK enterprises. But the first deliverable is not a platform. It is a ledger of disorder: measured, owned and shrinking. CIOs who start there will buy less, deploy faster and explain the programme more convincingly when the next audit, incident or board challenge arrives.

All Articles

Related Articles

What Held When the Ransomware Hit: Three UK Zero-Trust Drills, Three Hard Lessons

What Held When the Ransomware Hit: Three UK Zero-Trust Drills, Three Hard Lessons