Zones and conduits for a smaller factory

Zones and conduits for a smaller factory

Welcome back. I am Sam Armstrong. This episode looks at zones and conduits for a smaller factory.

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

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

Bring the right people to the table.

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

Ask each person what the line needs to run, what can interrupt it, and who authorises changes.

Choose a named owner for the map. Capture disagreements as open questions, rather than forcing a quick answer.

Draw a boundary around the exercise.

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

Show shared services that sit outside the immediate boundary. An excluded server can still be an important dependency.

Record the scope, assumptions, drawing date and reviewers. Keep the system boundary distinct from the security zones inside it.

Map what the factory actually does.

Describe functions before choosing network boundaries: filling, labelling, conveying, operator supervision, engineering support and production reporting.

Mark which equipment supports each function. One computer may support several functions, so note overlapping roles explicitly.

Ask what happens if each function stops or behaves incorrectly. Use those consequences to guide the boundary discussion.

One line. Several shared dependencies.

Our example has two packaging lines, a shared reporting server and an engineering workstation used during approved maintenance.

The office receives production totals. A supplier occasionally supports a machine through an agreed access route.

These are teaching assumptions. Replace them with your own verified functions, connections, owners and operational constraints.

Group assets with shared requirements.

A security zone groups assets that share security requirements. Consider their function, ownership, trust and the consequences of a problem.

A production line may be a useful starting candidate, but shared services or different requirements can change the grouping.

Write down why each asset belongs. A convenient rectangle on a drawing is only the beginning of that reasoning.

Describe the channels between zones.

A conduit groups communication channels connecting zones where those channels share security requirements. It describes more than a cable.

Identify the connected zones and the required services. Record the purpose, responsible owner and applicable protection requirements.

A conduit can contain several channels. Keep enough detail to review each channel without losing the overall relationship.

Use levels to explain function.

Purdue levels provide useful functional context. Our simplified view runs from field devices through control, supervision, operations and business planning.

Use that context to help colleagues understand where a function sits and which dependencies cross operational boundaries.

Do not force every modern device into one neat box. Record mixed roles and discuss them with the relevant owners.

A level is context. A zone needs a rationale.

Two separate production lines can contain similar controllers and panels at similar levels, while needing separate security zones.

A zone may also contain functions across more than one level when their security requirements justify that arrangement.

Avoid assigning a zone simply because equipment shares a level. Record the reason for the proposed grouping and review it.

Use drawings, people and passive evidence.

Compare current drawings, equipment records and interviews with authorised passive traffic evidence. Note the source and observation time.

A packet capture shows what was visible at its collection point. It may miss other segments, quiet devices or encrypted detail.

Label connections as observed, inferred or owner reviewed. Retain uncertainty until the evidence and plant knowledge support a conclusion.

Ask why each connection exists.

For every connection crossing a proposed boundary, ask who initiates it, which destination is needed and what task it supports.

Capture protocol, service and ports where known, together with frequency, access conditions and the responsible owner.

Observed traffic is evidence of activity. The plant team still needs to decide whether that activity is required and authorised.

Keep local control relationships visible.

For example, the operator panel exchanges status and commands with the line controller. Record that purpose in plain language.

Check the actual protocol, communication direction and timing requirements with the controls engineer and equipment documentation.

If both assets remain in the same zone, retain their relationship on the detailed map even though it crosses no zone boundary.

Review a reporting connection separately.

Suppose the reporting server collects production totals from line A. That is a candidate communication across the proposed line boundary.

Record the real connection initiator, destination service and data exchanged. Do not guess direction from the word reporting.

Ask whether the account can write process values as well as read them. Have the owner confirm the permissions required.

Make occasional access explicit.

Include engineering workstations, maintenance laptops and supplier support paths. Occasional access is easy to miss during normal production.

Record the authorised task, intended targets and access conditions. Connect this register to the approval and session records from episode two.

Separate the current route from the proposed route. A planned jump host is not an implemented control.

Look beyond the obvious process traffic.

Ask about time services, naming, authentication, backups, licensing and label printing. Small shared dependencies can affect several production cells.

Identify what happens when each service becomes unavailable, including during startup, changeover, recovery and maintenance.

Record the owner and recovery expectations. Check these connections before proposing a boundary that could interrupt them.

Give every candidate a reason and an owner.

Our draft uses one candidate zone for each packaging line and another for shared production services. The office remains separate.

For each candidate, list the included assets, common security requirements, operational consequences, responsible owner and unresolved assumptions.

This is a workshop proposal. Detailed risk assessment can lead to a different partition and more specific security requirements.

Review safety-related assets explicitly.

Identify safety-related systems and their interfaces explicitly. Involve the people responsible for functional safety and the equipment design.

Do not assume that a separate drawing box proves independence or that moving a device improves safety.

Record the required specialist review and applicable separation requirements. Agree how proposed cyber controls could affect diagnostics, response and recovery.

Turn requirements into a reviewed design.

A zone drawing does not enforce communication. The implementation needs suitable controls, configuration and a clear administration process.

For a proposed boundary, identify where approved channels would be permitted, how other traffic would be restricted, and where records would be collected.

A virtual LAN label alone does not demonstrate controlled access. Ask the engineer to explain and verify the actual enforcement.

Discuss an intermediary where appropriate.

Where business and production systems exchange information, discuss whether an industrial demilitarised zone or other intermediary fits the design.

Define the service it provides and the connections on each side. Avoid adding an intermediary without an operational purpose.

Review the solution against the actual site risk, support arrangements and recovery needs. A smaller factory still needs a maintainable design.

Walk the map with the plant team.

Walk through one normal shift using the draft map. Ask the operator which screens, services and support paths must remain available.

Then consider startup, a product change, a maintenance visit and recovery from an outage. Look for missing connections or unclear ownership.

Record accepted boundaries, unresolved questions and assigned actions. Keep the version and the names of the people who reviewed it.

Agree validation and rollback first.

Before implementing a change, agree the maintenance window, baseline evidence, backups, validation steps and rollback conditions with the plant team.

Use a suitable test environment where available. Review the impact on communication timing, operator visibility and recovery procedures.

Have an authorised engineer make the approved change. Stop and follow the agreed rollback process if the validation criteria fail.

Leave a small, reviewable evidence pack.

Keep the versioned map, zone rationale and communication register together. Link each reviewed connection to its evidence and owner.

Distinguish proposed controls from deployed controls and record validation results when changes are made. Make exceptions visible and time bound.

Review the pack when equipment, software, supplier access or production arrangements change. Give someone responsibility for keeping it current.

Use visibility to support the review.

A passive visibility platform can help organise observed assets and communication relationships, with evidence and observation times for the workshop.

Use only capabilities and evidence available in your deployment. People still need to confirm function, ownership, required access and boundary decisions.

An automatically drawn map cannot establish that the zoning is appropriate, the controls are effective or the site meets a standard.

One line. Clear flows. Agreed boundaries.

Start with one production line. Map its functions and dependencies, then propose zones with a clear security rationale.

Use Purdue levels as context, review the required communications and agree the boundaries with operations, engineering, IT and safety colleagues.

Leave with a reviewed map, a communication register and named next actions. Thank you for watching.