A useful cyber bowtie starts with scope. The reference architecture provides that scope: main components, important interfaces, user roles and the boundary of the assessment.
It is deliberately simpler than an engineering network diagram. Its job is to reveal supporting assets and risk relationships, not to replace an authoritative asset inventory or configuration-management system.
Zones group similar risk conditions
A zone groups assets that share security requirements, threats, consequences and users. It is not automatically a subnet.
Several physically separate substations may belong to one analytical zone when they have the same function, interfaces, users and consequences. Conversely, systems on one network segment may require separate zones when their criticality or access conditions differ.
Start with a small number of zones. Split when the analysis identifies a real difference:
- Threats: different physical location, exposure or interfaces.
- Consequences: different operational criticality or safety effect.
- Users: different roles, privileges or administration paths.
- Security requirements: a materially different target or control set.
Too many zones make the assessment unmanageable; too few hide important differences.
Interfaces reveal threats
An interface is a point where a human or software actor crosses into the assessed zone. Examples include:
- routed network connectivity;
- wireless access;
- remote maintenance;
- a local screen and keyboard;
- serial or USB access; and
- application or service-to-service calls.
Every interface should trigger a threat question. Who or what can use it? How is access established? What can be observed, changed or interrupted? A new interface often means a new threat path even when the underlying component is unchanged.
Conduits carry risk between zones
A conduit is a communication path connecting zones, particularly across a less-trusted environment. Remote telemetry over cellular infrastructure, an operational WAN or a vendor support path are common examples.
Conduit threats include interception, manipulation, replay, flooding and unauthorized use. The barriers may be implemented at either end or within the communication service, but the model should make their ownership and trust assumptions explicit.
Where the Purdue model helps
The Purdue model provides a familiar vocabulary for logical location in industrial environments: field process, basic control, supervisory control, site operations, industrial DMZ and enterprise services.
Use it as a yardstick, not a prescriptive diagram. Cloud services, mobile workforces, distributed energy and modern platform architectures do not always fit a strict hierarchy. The important result is an understandable trust and dependency model.
A Purdue-level tag can still help reviewers notice suspicious relationships—for example, direct enterprise access into lower-level control assets—but the tag does not itself prove segmentation or security.
Turning architecture into bowties
A practical sequence is:
- Define the business process and operational outcome in scope.
- Draw the smallest architecture that shows supporting assets and interfaces.
- Group sufficiently similar assets into zones.
- Mark conduits and external dependencies.
- Create or reuse bowties for the supporting assets that drive material risk.
- Use architecture nodes without assessments as a visible to-do list.
The architecture helps answer “what needs assessment?” The bowtie answers “how can control be lost and what stops the resulting harm?”
Keep sensitive detail elsewhere
A risk workshop rarely needs IP addresses, precise versions, credentials, detailed firewall rules or exploitable configurations. Keep those in controlled engineering and security systems.
The reference architecture should contain enough information to reason about trust, access and consequence—without becoming an unnecessary map for an attacker or a stale duplicate inventory.
Go to the source
Sources and further reading
Apply the method
Want to discuss this in your own risk model?
Keep the details high-level. We can start with scope, terminology and evaluation approach.