Sources and publication scope.
I reviewed OT_Security_Network_Report_Final.docx and OT_Security_Network_Report_BenjaminRutt.docx. Both are network-design reports for a simulated water-level control environment. They inventory OpenPLC, Factory I/O, HMI/SCADA, pfSense, Suricata, Kali, Wireshark and Hyper-V components, and recommend stronger segmentation, monitoring and recovery. Their similar embedded topology diagram has overlapping labels and a clipped edge, so the article uses a clearly labelled conceptual reconstruction instead of publishing it as a verified deployment diagram.
The five screenshots of application and terminal views were already present in the portfolio's assets/coursework/ collection. They are not embedded in either DOCX and do not have a documented capture-to-report chain or a shared test timeline. I use them only for what is visible. The complete reports, which include a student identifier, remain private; the published captures show lab-only private addresses and no credentials.
What each capture supports.
pfSense rules: the LANLEVEL1 screen shows a broad inter-zone pass entry, narrower TCP 502, 22 and 8080 entries, and a bogon block entry. It shows configuration, not a confirmed allow or deny outcome. Connectivity: Ubuntu pings to two field-side private addresses return “Destination Host Unreachable” and no replies; the cause is undetermined. Suricata configuration: the YAML view shows af-packet configured for eth0. Ruleset test: terminal output records rule loading and completion of suricata -T. Service: systemctl status reports an active service after restart. None of these images shows an IDS alert or confirmed inspection of both proposed zones.
Design is not implementation proof.
The reports place a pfSense VM between operations and field virtual switches and propose Suricata monitoring across the environment. The Suricata captures show an Ubuntu vboxuser terminal rather than a demonstrated Hyper-V monitoring attachment; no image maps that interface to the proposed switches. The reports also describe the Factory I/O, PLC, HMI and Ignition components, but the selected evidence does not show a complete control-loop test, a successful Modbus/TCP session or a measured process-safety outcome. The port 502 rule label is not a substitute for a packet trace.
The broad pass entry and the unreachable pings cannot be combined into a firewall-block claim. Routing, target availability, interface state and ICMP policy are unresolved. Rule order, effective state, packet counters and logs would need review. The reports themselves acknowledge that internal filtering was insufficient and frame stricter allowlisting, VLAN or physical separation, additional monitoring and backup/recovery as recommended improvements, not completed controls.
What would close the gaps.
A repeatable validation would map each VM and interface, document required process flows and source/destination pairs, capture one permitted and one denied cross-zone transaction with corresponding pfSense logs, and confirm Suricata receives representative traffic and emits a test alert. It would also check that normal operator visibility and control remain available after policy changes. These are future tests, not results claimed for this coursework.