Security Policy is Critical Infrastructure

The policy environment – ie the accumulated rules across firewalls, cloud controls and microsegmentation – determines which of those systems can reach each other, which connections are blocked and which exceptions still apply. Collectively, these rules form the security policy control plane: the governance layer that translates business intent into access decisions across distributed enforcement points.

Any misconfigured segmentation rule during a cloud migration can sever a payment service from its settlement platform. Any temporary rule granting broad access from a development subnet into production can stay in place months after ‘go live’ because no-one owns the removal.

Every firewall rule, segmentation policy and access decision directly affects operational risk and, when the policy environment fails, the critical services it governs fail with it. That makes the policy environment critical infrastructure in its own right.

Still governed like housekeeping

Despite this, many regulated organisations still manage their policy environments as operational tasks. Rules are added through change requests and the accumulated result is rarely examined against what was intended.

Ownership disperses as leaders change roles and the reason why a specific rule came into being in the first place can only be found in a change ticket (if anywhere at all).

Any Chief Information Security Officer (CISO) who would never accept a payment platform running without continuous monitoring or documented dependencies may accept both being absent from the policy environment that determines whether the platform is reachable. We can think of this as infrastructure-grade consequence with housekeeping-grade governance.

In banking, a policy failure that severs connectivity between settlement systems would constitute the disruption of an important business service. The Financial Conduct Authority (FCA) would take an interest in such a failure since the loss of such a service could lead to intolerable harm.

In healthcare or energy, the consequences are somewhat different, but the mechanism is the same: a misconfiguration that permits access from a corporate network into clinical systems in a National Health Service Trust, or into operational technology in a power distributor, creates exposure at the level of essential service delivery.

These are not hypothetical risks, but rather the operational consequences of treating critical infrastructure governance as a simple housekeeping task.

Regulatory expectations

UK regulatory expectations increasingly support the same conclusion: the security policies governing access to important services must be managed with infrastructure-grade discipline.

The FCA’s operational resilience regime requires regulated firms to identify important business services and demonstrate, on an ongoing basis, that the supporting infrastructure remains within defined impact tolerances.

Ofgem assesses operators of essential services against the National Cyber Security Centre’s (NCSC) Cyber Assessment Framework, asking whether defined security outcomes are being achieved on a sustained basis.

The Cyber Security and Resilience Bill, which is expected to become law later this year, will extend similar obligations to Data Centres, managed service providers and critical suppliers alike.

These frameworks are not prescriptive. None of them specifies which firewall rules an organisation should have or how its segmentation policies should be configured. What they require is proof: that what the policy environment permits is what was intended and that the organisation can demonstrate this on an ongoing basis rather than reconstruct the evidence for each assessment.

Meeting that standard

Most policy environments were never built to meet that standard. In fact, most policy environments were never consciously or deliberately built at all. Instead, policy tends to accumulate as a by-product of delivery. Every project and migration adds rules and almost none take any away. Over time, the policy surface – ie the full body of rules and access decisions across enforcement layers – grows larger than the group of people who understand it and the estate reaches a point where it can be operated, but not explained.

Across regulated industries like banking, energy and healthcare, that was sustainable under earlier regulatory regimes: periodic assessment, control-based audit and compliance frameworks that asked whether controls existed rather than whether they were effective. However, this is no longer enough. The new standard requires continuous evidence that access is intentional.

The FCA’s findings after a year of operational resilience self-assessments illustrate what this looks like in practice. Where regulated firms reported few or no outstanding vulnerabilities in the infrastructure supporting their important business services, the FCA often deemed the evidence too thin to determine whether there really were no vulnerabilities or whether the vulnerabilities just hadn’t been identified.

The lesson applies directly to security policy governance: an organisation cannot credibly claim access-related vulnerabilities are controlled without evidence of what its policies permit, how they were tested and whether weaknesses were remediated.

Infrastructure-grade governance

Too often, the response is to reach for more visibility and more documentation. However, documentation will only ever capture a point in time: it cannot provide the continuous assurance regulators are coming to expect.

The CISO in a regulated firm needs more than a record of what the policy environment was configured to permit. Configuration and effective access are not the same thing. Security teams need to understand how rules, routes, objects and enforcement layers interact to determine what can actually communicate.

Meeting the standard means reconciling the two: showing that what the environment permits in practice is still what it was intended to permit and being able to show it without notice.

We separate where policy intent is defined from where it’s enforced. Intent is held and maintained centrally, while enforcement remains distributed across firewalls, cloud controls and microsegmentation in hybrid, multi-cloud and multi-vendor environments. Validation runs continuously against that intent rather than at review points: proposed changes are tested against policy before they reach production and effective access is assessed on an ongoing basis for unnecessary exposure, inconsistency between enforcement layers and divergence from business intent. What was permitted and what changed is retained as evidence.

Policy environment 

The same CISO who would never accept a payment platform running without continuous monitoring, validated change control and documented dependencies has to apply this standard to the policy environment that determines whether the platform is reachable.

The FCA, the NCSC’s Cyber Assessment Framework and the Cyber Security and Resilience Bill all point towards the same underlying question: can this organisation demonstrate, continuously, that the infrastructure supporting its critical services is governed to the standard those services demand?

Answering that key question means knowing (and actually knowing, not assuming and not reconstructing at audit) what the policy environment permits at any given moment and whether what it permits is what was intended.

David Brown is Senior Vice-President for International Business at FireMon (www.firemon.com)