Networking Basics for Industrial Control Systems
Essential networking concepts for understanding communications within industrial control systems.
Learning objectives
- Explain the roles of switches, routers and firewalls.
- Read basic IP, subnet, protocol and port information.
- Use the OSI model as a troubleshooting aid.
- Produce a useful OT data-flow register.
Introduction
This module establishes the networking foundation needed for later security decisions.
Planned video lesson
Video lesson coming soon. The written module can be completed without the video.
Planned recording: 10-12 minutes following one PLC data request through the OSI layers and showing where switching, routing and filtering occur.
Transcript will be added with the video.
Main lesson
Network types and boundaries
An industrial system may contain:
- Field networks between instruments, drives and controllers.
- Cell or area LANs connecting controllers and HMIs.
- Control-centre networks for SCADA, historians and engineering.
- WAN or telemetry links between sites.
- Enterprise connections for reporting and support.
- Wireless links for process, maintenance or mobile working.
The security question is not whether Ethernet is present. It is which assets can communicate, who can initiate the communication, what the protocol can do and what happens when the link fails.
Use the OSI model to ask better questions
| Layer | Practical OT question | Examples |
|---|---|---|
| 1 - Physical | What medium and physical route exist? | Copper, fibre, radio, serial cable |
| 2 - Data link | Which local devices share a broadcast domain? | Ethernet, MAC address, VLAN |
| 3 - Network | Which subnets can route to one another? | IPv4, IPv6, router |
| 4 - Transport | Which connection type and port are used? | TCP, UDP |
| 5-7 - Session to application | What service and industrial action are performed? | Modbus, OPC UA, HTTPS, vendor engineering protocol |
The model does not perfectly describe every industrial protocol. Its value is disciplined troubleshooting: physical connectivity, local delivery, routed reachability, transport session and application behaviour are different problems.
Switch, router and firewall are not synonyms
- A switch forwards frames inside a local network, usually by MAC address.
- A router moves packets between IP networks.
- A firewall applies a security policy to permitted communication, often using addresses, ports, state and sometimes application awareness.
A Layer 3 switch can route. A router can include firewall functions. The name on the box is less important than the configured and tested behaviour.
Addressing essentials
- A MAC address identifies an interface on the local data-link network.
- An IP address identifies an interface for network-layer communication.
- A subnet mask or prefix defines which addresses are local.
- A default gateway is used to reach other networks.
- A TCP or UDP port identifies a service endpoint, not a physical socket.
- DNS maps names to addresses.
- ARP helps IPv4 devices resolve local IP addresses to MAC addresses.
Use documentation ranges such as 192.0.2.0/24 in public examples rather than exposing a real site addressing scheme.
VLANs help organise traffic but need enforcement
A VLAN creates a logical Layer 2 separation. Traffic between VLANs still depends on routing and access policy. If every VLAN can route freely through a core switch, the security benefit may be small.
Document:
- VLAN purpose.
- Subnet.
- Assets and owner.
- Routing point.
- Boundary policy.
- Management access.
- Failure and recovery behaviour.
The data-flow register
A useful flow record contains:
| Field | Example question |
|---|---|
| Source and destination | Which exact hosts or zones communicate? |
| Initiator | Which side starts the session? |
| Service | What application function is required? |
| Protocol and port | Is the observed port fixed or dynamic? |
| Direction | One-way request, response traffic or bidirectional session? |
| Frequency | Continuous, periodic, event-driven or temporary? |
| Security | How are identity, integrity and confidentiality protected? |
| Criticality | What happens if the flow is delayed, blocked or altered? |
| Owner | Who approves and reviews it? |
Do not populate a firewall from a diagram alone. Validate flows against configuration, supplier documentation and passive observation where it is safe to do so.
Planned original figure β M09-F01
Create a packet journey from Riverside HMI through switch, router / firewall and PLC, labelling MAC address, IP subnet, TCP or UDP and application protocol.
Planned asset: /static/training/ot-cyber-security/module-09/figure-01.svg
Engineering example
Riverside application
Riverside has a limited set of important data flows, making it suitable for practising how to document initiators, destinations, protocols and operational purpose.
Practical activity
Apply what you learned
Write flow records for:
- HMI to PLC.
- Engineering workstation to PLC.
- RTU to central SCADA.
- Historian transfer to enterprise reporting.
- Vendor support to the engineering environment.
Mark any unknown initiator, port or failure behaviour as an engineering action. Do not replace missing evidence with βbidirectional - anyβ.
Record your reasoning and project notes here. Your response stays in this browser and is not submitted to the website.
Loading saved responseβ¦
0 / 10,000Do not enter real credentials, confidential network details, sensitive asset information or security-sensitive project data.
Knowledge check
Answer every question correctly to complete this module. If an answer is incorrect, review the explanation and try again. This is not a formal examination.
Key takeaways
Remember these points
Network security starts with understanding purpose, initiator, destination and expected traffic.
- Switches, routers and firewalls perform different functions.
Passive observation is normally the safest first method for learning traffic on sensitive legacy networks.
Relevant standards and guidance
This module uses original explanatory language. Consult the applicable editions and project requirements rather than treating this lesson as normative text.
- NIST SP 800-82 Rev. 3
Further reading
- NIST SP 800-82 Rev. 3 β Guide to Operational Technology Security
- NCSC β Creating and maintaining a definitive view of your OT architecture
- NCSC β Identify and document connectivity within your OT system
- IETF RFC 5737 β IPv4 address blocks reserved for documentation
Last reviewed
15 July 2026.
Complete the knowledge check above and answer every question correctly to unlock module completion.
Progress is stored only in this browser and is not a certificate or formal training record.