Hybrid mesh policy across plants, cloud and 400 small sites
A German industrial manufacturer runs 22 plants, 8,000 managed endpoints and roughly 1,400 unmanaged OT devices spread across three segmented production zones. Two data centres host Quantum Force clusters in high-availability pairs; SAP and analytics workloads sit in AWS and Azure; 400 small sales and service sites connect over SD-WAN with local internet breakout. Network operations owns the data-centre and plant firewalls. A separate cloud platform team owns the AWS and Azure landing zones and has deployed its own native security controls, arguing that cloud traffic never touches the network team's estate. Incidents in the last year include a misconfigured security group exposing an analytics bucket for eleven days, and a plant-level bypass created during an outage that was never removed. The board has approved a Hybrid Mesh Network Security programme and wants one policy and one evidence trail within twelve months.
1. Explain what a hybrid mesh firewall architecture means in this estate, and be explicit about which elements here would and would not be part of it.
Read the worked answer
A hybrid mesh is not a single product; it is a management and policy construct. The mesh is the set of enforcement points that share one policy intent and one log/evidence plane, regardless of whether each point is an appliance, a virtual gateway, a cloud-native control or a cloud-delivered service.
Inside the mesh here: the Quantum Force clusters at the two data centres; plant-level enforcement covering the IT and DMZ zones adjacent to OT, with OT segmentation treated as a separate policy layer; virtual gateways inside the AWS and Azure landing zones, managed from the same console; and, if you adopt it, Harmony SASE for the 400 sites doing local breakout, since those sites' internet traffic never transits a data-centre appliance.
Outside the mesh, or only partly in it: the OT devices themselves, which need segmentation and anomaly detection rather than an agent; the cloud team's native controls, which should be reconciled with the mesh policy rather than duplicated blindly; and endpoint protection, which is a different control plane entirely.
The two incidents are the argument for the mesh. The exposed bucket was a policy-visibility failure across ownership boundaries; the forgotten plant bypass was a policy-drift failure. Neither is fixed by buying another appliance.
2. The network and cloud teams dispute ownership. Propose a governance and policy model that both can accept, and describe the technical controls that make it enforceable.
Read the worked answer
Split the question into policy authorship and policy execution. The cloud team keeps authorship of cloud-specific rules because they understand the workloads and hold the change process; the security function owns the guardrails and the evidence.
Practically: define a small set of non-negotiable global rules (no workload with a public address outside a protected front end, mandatory inspection of egress, logging to a central store, tagging standards for ownership). Publish them as infrastructure-as-code templates the cloud team consumes in their own pipeline, so compliance is a build step rather than a ticket. Then give the cloud team delegated administration in the management plane scoped to their gateways, with read-only visibility elsewhere, and route all logs to one collector so the evidence trail is unified even where authorship is not.
For the plant bypass problem, require that any temporary rule carries an owner, a ticket reference and an expiry date, and audit rules with no expiry monthly. That single control would probably have caught the outage workaround.
Expect resistance to be about accountability, not technology. Write down who is answerable when a global rule blocks a production release, before the first conflict happens.
3. The board wants proof the programme worked within twelve months. Propose measures, and explain why each is a better indicator than a simple alert count.
Read the worked answer
Choose measures that describe the estate's behaviour rather than the tooling's output. Alert volume measures the sensors, not the risk.
Proposed measures. (1) Percentage of enforcement points with a current, reviewed policy and a working log feed, reported weekly; a gap here is a blind spot, not a backlog item. (2) Policy drift: number of rules that are undocumented, unowned or past their expiry, trending down; this directly addresses the plant bypass. (3) Time from cloud resource creation to first policy evaluation, which tests whether the mesh actually covers new workloads rather than only the ones that existed at design time. (4) Exposure of internet-facing assets, expressed as the count and age of externally reachable services with known critical weaknesses, which is the board-legible version of the bucket incident. (5) Mean time to contain an incident that spans at least two enforcement points, which is the only measure that tests the mesh rather than the parts.
Deliberately exclude raw alert counts and number of blocked attacks: both rise with coverage and tell the board nothing about whether the estate is better controlled.