Zones and conduits for a smaller factory
Episode 03 — Practical architecture

[00:00:00.000] Welcome back. I am Sam Armstrong. This episode looks at zones and conduits for a smaller factory.

[00:00:07.564] We will use an illustrative packaging line, shared production services and an office network to build a practical example.

[00:00:15.833] Our aim is a reviewed boundary map and communication register, with clear owners and questions for the plant team.

[00:00:24.778] Invite the operator, maintenance lead, controls engineer and IT colleague. Include the safety specialist wherever safety functions could be affected.

[00:00:35.290] Ask each person what the line needs to run, what can interrupt it, and who authorises changes.

[00:00:42.264] Choose a named owner for the map. Capture disagreements as open questions, rather than forcing a quick answer.

[00:00:51.140] Start with packaging line A. Include its controllers, operator panels, drives, engineering access and the connections leaving that line.

[00:01:00.859] Show shared services that sit outside the immediate boundary. An excluded server can still be an important dependency.

[00:01:09.201] Record the scope, assumptions, drawing date and reviewers. Keep the system boundary distinct from the security zones inside it.

[00:01:19.488] Describe functions before choosing network boundaries: filling, labelling, conveying, operator supervision, engineering support and production reporting.

[00:01:30.408] Mark which equipment supports each function. One computer may support several functions, so note overlapping roles explicitly.

[00:01:39.498] Ask what happens if each function stops or behaves incorrectly. Use those consequences to guide the boundary discussion.

[00:01:49.126] Our example has two packaging lines, a shared reporting server and an engineering workstation used during approved maintenance.

[00:01:58.388] The office receives production totals. A supplier occasionally supports a machine through an agreed access route.

[00:02:06.450] These are teaching assumptions. Replace them with your own verified functions, connections, owners and operational constraints.

[00:02:16.358] A security zone groups assets that share security requirements. Consider their function, ownership, trust and the consequences of a problem.

[00:02:26.491] A production line may be a useful starting candidate, but shared services or different requirements can change the grouping.

[00:02:34.827] Write down why each asset belongs. A convenient rectangle on a drawing is only the beginning of that reasoning.

[00:02:43.867] A conduit groups communication channels connecting zones where those channels share security requirements. It describes more than a cable.

[00:02:53.455] Identify the connected zones and the required services. Record the purpose, responsible owner and applicable protection requirements.

[00:03:02.993] A conduit can contain several channels. Keep enough detail to review each channel without losing the overall relationship.

[00:03:12.537] Purdue levels provide useful functional context. Our simplified view runs from field devices through control, supervision, operations and business planning.

[00:03:23.587] Use that context to help colleagues understand where a function sits and which dependencies cross operational boundaries.

[00:03:32.051] Do not force every modern device into one neat box. Record mixed roles and discuss them with the relevant owners.

[00:03:41.462] Two separate production lines can contain similar controllers and panels at similar levels, while needing separate security zones.

[00:03:50.646] A zone may also contain functions across more than one level when their security requirements justify that arrangement.

[00:03:59.102] Avoid assigning a zone simply because equipment shares a level. Record the reason for the proposed grouping and review it.

[00:04:08.693] Compare current drawings, equipment records and interviews with authorised passive traffic evidence. Note the source and observation time.

[00:04:18.198] A packet capture shows what was visible at its collection point. It may miss other segments, quiet devices or encrypted detail.

[00:04:26.917] Label connections as observed, inferred or owner reviewed. Retain uncertainty until the evidence and plant knowledge support a conclusion.

[00:04:37.869] For every connection crossing a proposed boundary, ask who initiates it, which destination is needed and what task it supports.

[00:04:46.808] Capture protocol, service and ports where known, together with frequency, access conditions and the responsible owner.

[00:04:55.039] Observed traffic is evidence of activity. The plant team still needs to decide whether that activity is required and authorised.

[00:05:05.425] For example, the operator panel exchanges status and commands with the line controller. Record that purpose in plain language.

[00:05:14.691] Check the actual protocol, communication direction and timing requirements with the controls engineer and equipment documentation.

[00:05:23.856] If both assets remain in the same zone, retain their relationship on the detailed map even though it crosses no zone boundary.

[00:05:33.402] Suppose the reporting server collects production totals from line A. That is a candidate communication across the proposed line boundary.

[00:05:42.936] Record the real connection initiator, destination service and data exchanged. Do not guess direction from the word reporting.

[00:05:51.754] Ask whether the account can write process values as well as read them. Have the owner confirm the permissions required.

[00:06:00.818] Include engineering workstations, maintenance laptops and supplier support paths. Occasional access is easy to miss during normal production.

[00:06:11.302] Record the authorised task, intended targets and access conditions. Connect this register to the approval and session records from episode two.

[00:06:21.436] Separate the current route from the proposed route. A planned jump host is not an implemented control.

[00:06:30.199] Ask about time services, naming, authentication, backups, licensing and label printing. Small shared dependencies can affect several production cells.

[00:06:41.549] Identify what happens when each service becomes unavailable, including during startup, changeover, recovery and maintenance.

[00:06:50.541] Record the owner and recovery expectations. Check these connections before proposing a boundary that could interrupt them.

[00:07:00.052] Our draft uses one candidate zone for each packaging line and another for shared production services. The office remains separate.

[00:07:09.434] For each candidate, list the included assets, common security requirements, operational consequences, responsible owner and unresolved assumptions.

[00:07:19.826] This is a workshop proposal. Detailed risk assessment can lead to a different partition and more specific security requirements.

[00:07:29.533] Identify safety-related systems and their interfaces explicitly. Involve the people responsible for functional safety and the equipment design.

[00:07:39.999] Do not assume that a separate drawing box proves independence or that moving a device improves safety.

[00:07:47.543] Record the required specialist review and applicable separation requirements. Agree how proposed cyber controls could affect diagnostics, response and recovery.

[00:08:00.220] A zone drawing does not enforce communication. The implementation needs suitable controls, configuration and a clear administration process.

[00:08:10.457] For a proposed boundary, identify where approved channels would be permitted, how other traffic would be restricted, and where records would be collected.

[00:08:20.177] A virtual LAN label alone does not demonstrate controlled access. Ask the engineer to explain and verify the actual enforcement.

[00:08:30.994] Where business and production systems exchange information, discuss whether an industrial demilitarised zone or other intermediary fits the design.

[00:08:41.114] Define the service it provides and the connections on each side. Avoid adding an intermediary without an operational purpose.

[00:08:49.930] Review the solution against the actual site risk, support arrangements and recovery needs. A smaller factory still needs a maintainable design.

[00:09:01.209] Walk through one normal shift using the draft map. Ask the operator which screens, services and support paths must remain available.

[00:09:10.893] Then consider startup, a product change, a maintenance visit and recovery from an outage. Look for missing connections or unclear ownership.

[00:09:20.682] Record accepted boundaries, unresolved questions and assigned actions. Keep the version and the names of the people who reviewed it.

[00:09:30.996] Before implementing a change, agree the maintenance window, baseline evidence, backups, validation steps and rollback conditions with the plant team.

[00:09:41.002] Use a suitable test environment where available. Review the impact on communication timing, operator visibility and recovery procedures.

[00:09:50.846] Have an authorised engineer make the approved change. Stop and follow the agreed rollback process if the validation criteria fail.

[00:10:01.184] Keep the versioned map, zone rationale and communication register together. Link each reviewed connection to its evidence and owner.

[00:10:10.555] Distinguish proposed controls from deployed controls and record validation results when changes are made. Make exceptions visible and time bound.

[00:10:20.643] Review the pack when equipment, software, supplier access or production arrangements change. Give someone responsibility for keeping it current.

[00:10:31.179] A passive visibility platform can help organise observed assets and communication relationships, with evidence and observation times for the workshop.

[00:10:41.585] Use only capabilities and evidence available in your deployment. People still need to confirm function, ownership, required access and boundary decisions.

[00:10:52.268] An automatically drawn map cannot establish that the zoning is appropriate, the controls are effective or the site meets a standard.

[00:11:02.582] Start with one production line. Map its functions and dependencies, then propose zones with a clear security rationale.

[00:11:11.389] Use Purdue levels as context, review the required communications and agree the boundaries with operations, engineering, IT and safety colleagues.

[00:11:21.730] Leave with a reviewed map, a communication register and named next actions. Thank you for watching.

[00:11:30.000] End card: Thank you.
