Episode 01 / Factory reality · 6 minutes
Understand your factory network before you touch it
Start with one production cell. Understand its dependencies, choose an observation method and separate evidence from assumptions.
Start with one cell.
Identify the process, its owner and the dependencies that matter to production.
Choose the collection point.
Compare an existing capture, SPAN and TAP arrangements, including coverage and operational constraints.
Separate fact from assumption.
Record what was observed, what was inferred and what still needs an owner’s review.
Read the full transcript
Understand your factory network before you touch it
My name is Sam Armstrong, a senior developer for OTCogniShield.
We'll use an illustrative packaging cell. This isn't a live customer installation.
Your starting point: a cell boundary, a dependency map and an observation plan.
Give the exercise a clear boundary.
Choose one cell, with an owner who understands its operation and recovery.
Mark the controller, operator interface and connected equipment. Show links crossing the boundary.
Ask: which communications matter to production, and what remains uncertain?
Start with the process, not an IP address.
Ask the operator what happens when a display, connection or shared service fails.
Separate loss of visibility from loss of control. They aren't always the same.
Agree who owns the process, supports the equipment and authorises changes.
Build a useful starting inventory.
List the controller, operator display, drive, switch and engineering workstation.
Record each asset's role, location and owner. Include your information source.
Keep unconfirmed models and firmware versions unconfirmed. Don't replace unknowns with guesses.
Look beyond the cell boundary.
Look outside the cell: historians, production systems, time servers and authentication services.
Ask about maintenance laptops and vendor access. Occasional connections are easily missed.
Map these dependencies, then have their purpose and importance reviewed.
A protocol is a clue. It is not a device identity.
Modbus traffic tells you something about communication between two addresses.
It doesn't prove manufacturer, firmware, safety function or authorisation.
Separate observed traffic from inferred roles. Confirm identity through another evidence source.
Use the records you already have.
Compare drawings, asset lists and maintenance records with operators' knowledge.
Treat disagreements as questions. A drawing may be old; an address may be unfamiliar.
Record document revisions and reviewers. Don't interrogate controllers to fill spreadsheet gaps.
Choose the method before connecting anything.
Consider an existing capture, a switch mirror or a suitable network TAP.
Choose for your operational question. Record the traffic the method could miss.
Passive analysis doesn't make installation risk-free. Agree the connection and change process.
An existing capture is a controlled first step.
For an authorised existing capture, establish where, when and how it was collected.
Keep the original and its hash. Work from an approved copy.
Preserve capture times. Importing yesterday's traffic today doesn't make it current activity.
A mirror port needs a reviewed configuration.
Ask the switch owner which ports, VLANs and directions the mirror includes.
Review capacity and documented limits. An overloaded mirror can lose packets.
Use an authorised engineer. Record the approved settings and coverage checks.
A TAP is hardware in a real production path.
Match the TAP to the link, media and speed. Check its documentation.
Installation may interrupt the link. Review power behaviour and failure modes.
Agree a maintenance window and recovery procedure. Verify receive-only behaviour.
Separate observation from management.
Identify the monitoring and management interfaces. Draw their intended network paths.
Check for unapproved bridging. Review addresses, routes and enabled services.
Verify passive behaviour. A monitoring label doesn't prove an appliance cannot transmit.
Observe representative production activity.
Choose a representative observation window. Normal running can hide dependencies.
Where authorised, include changeovers, startup, shutdown and maintenance. Record anything not observed.
Check capture health and packet loss before interpreting a quiet result.
Use three clear labels.
Observed means the source shows it. Keep the evidence and observation time.
Inferred means an interpretation. Record your reasoning and the uncertainty.
Reviewed means an owner confirmed it. Record who, when and supporting evidence.
Not observed does not mean offline.
Quiet devices, unobserved segments and encryption can limit passive visibility.
Say not recently observed. Check coverage before calling an asset offline.
A newly observed address isn't automatically rogue. Verify ownership and context.
Investigate uncertainty without inventing certainty.
Turn uncertainty into actions: identity questions, coverage checks and owner reviews.
Ask whether maintenance or an approved change explains an unexpected connection.
Assign owners and review points. Don't disconnect production equipment just because it's unfamiliar.
Leave with a small, reviewed evidence pack.
Bring together the cell boundary, inventory, dependency map and observation limitations.
Add evidence references, capture health, open assumptions and assigned actions. Store them securely.
Have operations and engineering review the pack. It isn't a compliance certificate.
One cell. Clear evidence. An agreed next step.
Start with one cell. Understand its dependencies. Make uncertainty visible.
Next time: choosing and checking a passive observation path. Bring your map and questions.
See the accompanying reading list for further guidance. Thank you.