A sanitized portfolio case study describing an OT/ICS cybersecurity appliance designed to enforce protocol-aware policy on Modbus/TCP traffic while preserving normal industrial communications.
Public portfolio notice
This repository intentionally contains no employer source code, production configuration, customer information, real network addressing, device credentials, deployment scripts, or operational security details. It documents engineering concepts and lessons learned using generic terminology and synthetic examples only.
Industrial firewalls often need to permit Modbus/TCP for legitimate operations while applying more precise controls than a simple TCP port allow/deny rule.
The goal of this project was to design and validate an inline security appliance that could:
- remain transparent to the protected industrial communications path;
- inspect Modbus/TCP at the application-protocol layer;
- distinguish permitted operations from restricted operations;
- preserve normal read-oriented traffic;
- prevent unauthorized state-changing operations from reaching a controller;
- keep device management isolated from the protected field-facing path; and
- recover predictably after reboot or service restart.
Authorized Industrial Client
|
v
[ Inline Security ]
[ Appliance ]
|
v
Industrial Gateway
|
v
PLC / Controller
The appliance operates inline so endpoint addressing does not need to be redesigned solely to insert the security control.
Management access is logically separated from the field-facing industrial path.
See docs/ARCHITECTURE.md for additional sanitized design notes.
The design uses protocol-aware inspection rather than treating all Modbus/TCP traffic as equivalent.
Conceptually, the policy is:
IF traffic is valid Modbus/TCP
AND the operation is read-only
THEN permit according to policy
IF traffic attempts a restricted state-changing operation
THEN block and record the event
The exact production rule set, addresses, interfaces, management paths, and appliance configuration are intentionally not published.
The security control had to be inserted into an existing industrial path without requiring application changes at either endpoint. The solution therefore emphasized inline inspection and predictable forwarding behavior.
Blocking the entire Modbus/TCP service was not acceptable because legitimate industrial communication still had to function. Inspection needed to understand Modbus operations rather than make decisions only from IP addresses and TCP ports.
The protected field-facing side was not intended to become a general management network. Administrative access was kept logically separate from the industrial data path.
The implementation was converted from a qualified appliance configuration into a repeatable deployment approach with validation checks, while avoiding cloning machine identity or credentials between systems.
The delivery appliance also received a separate hardening pass covering unused interfaces, local-console exposure, boot controls, and service minimization. Exact firmware settings and operational hardening values are omitted because they were environment-specific.
Testing focused on observable behavior rather than configuration alone.
Validation included:
- confirming permitted industrial requests continued to traverse the appliance;
- confirming restricted operations were blocked;
- correlating blocked events with security-engine telemetry;
- checking behavior after reboot;
- verifying service persistence;
- confirming management exposure remained limited to the intended administrative path; and
- re-testing the industrial communications path after hardening changes.
No production packet captures, logs, addressing, rule identifiers, or device backups are included in this repository.
OT / Industrial Security
- Modbus/TCP
- PLC communications
- OT/ICS network segmentation
- application-protocol inspection
- inline intrusion prevention concepts
Linux / Platform Engineering
- Debian Linux
- Suricata
- AF_PACKET inline processing
- systemd
- OpenSSH
- Bash automation
- boot and console hardening concepts
Networking
- TCP/IP
- transparent inline enforcement
- routing and address-selection troubleshooting
- NAT concepts
- management-plane separation
- packet and service validation
Engineering Practices
- requirements-driven design
- iterative troubleshooting
- repeatable deployment
- qualification testing
- reboot/persistence testing
- configuration validation
- technical documentation
- human-in-the-loop AI-assisted engineering
AI was used as an engineering aid for troubleshooting, configuration review, deployment-script scaffolding, test planning, command generation, and documentation.
AI-generated suggestions were reviewed before execution and validated against actual system behavior. Final technical decisions, implementation, physical configuration, and qualification remained under human control.
This portfolio repository does not include:
- employer or customer names;
- company branding;
- production source code or scripts;
- exact protocol-filtering rules;
- public or private production IP addresses;
- actual management ports or forwarding rules;
- device serial numbers or hardware identifiers;
- usernames, passwords, keys, certificates, or hashes;
- production packet captures or logs;
- internal router or firewall configuration;
- exact firmware menu selections;
- deployment archives or backups;
- customer/site topology; or
- original Git history from the private project.
This repository exists only to demonstrate the engineering problem, architecture, validation approach, and technologies used. It is not intended to reproduce the employer's deployed firewall or serve as a field-deployment package.
This public case study contains only original portfolio documentation written for this repository. Employer-owned implementation artifacts are not included.