Industrial Network Protocols and Their Security Implications
Security implications of common industrial protocols and the assumptions behind their use.
Learning objectives
- Recognise common industrial protocols and their typical use.
- Separate protocol capability from secure implementation.
- Identify dangerous trust assumptions in legacy communications.
- Plan safe, passive traffic inspection.
Introduction
This module considers protocols as part of a wider engineered security architecture.
Planned video lesson
Video lesson coming soon. The written module can be completed without the video.
Planned recording: 9-11 minutes reading a passive packet capture in an isolated lab and explaining why a permitted industrial protocol can still carry a dangerous command.
Transcript will be added with the video.
Main lesson
A protocol carries process meaning
Industrial protocols do more than transport data. They may read measurements, change setpoints, start equipment, download logic or acknowledge alarms. A firewall rule that permits a protocol may therefore permit actions with very different consequences.
Record:
- Protocol and version.
- Client / server or publisher / subscriber roles.
- Permitted function.
- Engineering and administrative functions.
- Authentication, integrity and encryption capability.
- Certificate or key ownership.
- Required latency and availability.
- Boundary and monitoring method.
Common examples
| Protocol | Typical use | Security issue | Design response |
|---|---|---|---|
| Modbus TCP | Simple register and coil access | Traditional deployments lack authentication and encryption | Restrict peers and functions; monitor writes; use supported secure options where practical |
| OPC Classic | Windows-based data exchange using DCOM | Complex permissions and dynamic communication can drive broad rules | Use tightly managed hosts, gateways or DMZ services; minimise identity and port scope |
| OPC UA | Structured data exchange | Security features depend on selected profile, certificate trust and configuration | Require signing / encryption as justified; manage certificates and reject insecure endpoints |
| DNP3 | Telemetry and utility control | Legacy deployments may trust the communicating endpoint | Use supported secure authentication, controlled peers and command monitoring |
| PROFINET | Real-time industrial automation | Discovery, engineering and control functions may share the environment | Segment cells, protect engineering access and validate product-specific security capability |
| EtherNet/IP | CIP-based control and information exchange | Security support varies by device and implementation | Restrict connections and services; assess CIP Security support and operational compatibility |
Never assume a protocol is secure because a modern secure variant exists. Confirm which feature, profile, firmware and configuration are actually deployed.
Encryption is not the only requirement
A secure channel may provide confidentiality and integrity while still allowing an authorised account to issue a dangerous command. Protocol security must work with:
- Named identity.
- Role and least privilege.
- Safe application logic.
- Approved command paths.
- Boundary filtering.
- Logging and monitoring.
- Change control.
In some time-critical or constrained systems, strong encryption may not be feasible. Record the limitation and use compensating controls rather than making an unsupported claim.
Inspect traffic safely
Passive inspection through a network TAP or correctly configured mirror port can help identify:
- Unexpected assets.
- Undocumented protocols.
- Broadcast and discovery traffic.
- Repeated errors or reconnects.
- Unauthorised write functions.
- New engineering connections.
- Plaintext credentials or sensitive values.
Capture only with authorisation. Traffic can contain sensitive process, configuration or personal data. Protect the capture file and retention period.
Do not inject protocol commands, scan devices or replay traffic on a live system without a reviewed method, operational approval and a safe test environment.
Protocol-aware boundary controls
Where supported and justified, application-aware controls can:
- Limit permitted function codes.
- Detect unauthorised writes.
- Restrict engineering services.
- Validate expected protocol behaviour.
- Alert on malformed or unusual messages.
These controls must be tested against the real application. A protocol parser that blocks legitimate failover or recovery traffic can reduce availability.
Planned original figure — M11-F01
Create a protocol comparison graphic showing legacy trust, optional secure profiles, boundary restriction and protocol-aware monitoring.
Planned asset: /static/training/ot-cyber-security/module-11/figure-01.svg
Engineering example
Riverside application
Riverside uses industrial protocols for monitoring, control and engineering; permitting a protocol alone does not define which functions are acceptable.
Practical activity
Apply what you learned
Create a protocol inventory for HMI-to-PLC, RTU telemetry, historian exchange and vendor engineering. For every protocol, identify:
- Read, write and engineering functions.
- Security features enabled.
- Trust material owner.
- Boundary rule.
- Monitoring opportunity.
- Behaviour if certificates, keys or time services fail.
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
Industrial protocols carry process and engineering actions with different consequences.
Secure protocol features protect nothing unless they are enabled, configured and maintained correctly.
Protocol-aware controls complement, rather than replace, broader segmentation and system hardening.
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
- MITRE ATT&CK for ICS
Further reading
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
- MITRE ATT&CK for ICS
- OPC Foundation — OPC UA Security Model
- Modbus Organization — Modbus Security Protocol
- ODVA — CIP Security
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.