Cybersecurity Hardening for OT Security Networks

Physical security systems represent one of the largest and least-secured attack surfaces in enterprise networks. A typical corporate campus deploys 500-3,000 IP cameras, 100-500 access control readers and panels, dozens of building automation controllers, and hundreds of IoT sensors—all network-connected devices that run embedded operating systems with known vulnerabilities, communicate over unencrypted protocols, and are rarely patched. The 2021 Verkada breach demonstrated the consequences: attackers gained access to 150,000 cameras across hospitals, prisons, and Tesla factories through a single exposed support server.

The root cause is an institutional gap between the teams responsible for these devices. Physical security integrators install cameras and access control on flat Layer 2 networks using DHCP-assigned addresses, default administrative credentials, and RTSP video streaming without TLS encryption. IT security teams manage the enterprise network but treat the security system VLAN as the integrator's responsibility. Neither team owns the cybersecurity posture of the physical security infrastructure, and neither has the cross-domain expertise to address it—integrators lack network security skills, and IT teams lack knowledge of ONVIF, OSDP, BACnet, and the operational requirements of real-time video and access control systems.

Compliance frameworks are catching up to this reality. NIST SP 800-82 Rev. 3 explicitly addresses security for building automation and physical security systems. IEC 62443 provides a comprehensive framework for industrial automation and control system security that applies directly to building OT networks. PCI DSS 4.0 requires segmentation of any network carrying cardholder data from IP camera and access control networks. Yet most facilities have no formal cybersecurity architecture for their OT security systems, no asset inventory of connected devices, and no monitoring for anomalous behavior on these networks.

We begin with a comprehensive OT asset discovery and vulnerability assessment. Using passive network monitoring (Nozomi Guardian, Claroty, or Armis) and active scanning (Nmap with OT-safe scan profiles), we produce a complete inventory of every device on the physical security network: manufacturer, model, firmware version, MAC address, IP assignment method, open ports, running services, and known CVEs. This asset inventory—typically the first one the client has ever seen for their OT network—forms the baseline for all subsequent hardening activities.

Network segmentation follows IEC 62443 zone-and-conduit principles. We define security zones by function and trust level: cameras in one zone, access control panels in another, building automation controllers in a third, management workstations in a fourth. Inter-zone communication is restricted to defined conduits with explicit firewall rules permitting only the protocols and ports required for operational functionality. For example, cameras communicate with the VMS on TCP 554 (RTSP) and TCP 80/443 (ONVIF) only; the VMS communicates with the management zone on TCP 443 only; and no device in the camera zone can initiate outbound connections to the internet. Micro-segmentation at the switch port level uses 802.1X with EAP-TLS certificate-based authentication, ensuring that only enrolled devices with valid certificates can access the network.

Ongoing monitoring integrates OT network telemetry into the enterprise SIEM (Splunk, Microsoft Sentinel, or equivalent). OT-specific detection rules identify anomalous behaviors unique to physical security systems: a camera firmware downgrade, an access control panel communicating with an unexpected IP address, a BACnet controller receiving write commands from a non-authorized source, or ONVIF discovery broadcasts from a device not in the asset inventory. We establish a monthly vulnerability management cadence with the integrator and device manufacturers to track firmware updates, assess CVE applicability, and schedule maintenance windows for patching that do not disrupt 24/7 security operations.

802.1X deployment for IP cameras uses EAP-TLS with device certificates issued by an internal PKI (Microsoft AD CS or EJBCA). Each camera is enrolled using SCEP (Simple Certificate Enrollment Protocol) or EST (Enrollment over Secure Transport, RFC 7030) with a bootstrap credential provided during initial provisioning. The RADIUS server (Cisco ISE, Aruba ClearPass, or FreeRADIUS) validates the device certificate against the CA chain and assigns the camera to the appropriate VLAN based on the certificate's organizational unit (OU) field. MAB (MAC Authentication Bypass) is configured as a fallback for legacy devices that do not support 802.1X, with the MAC address whitelisted in the RADIUS server and the port placed in a restricted VLAN with additional firewall filtering. Monitor mode is deployed first to identify authentication failures without disrupting operations, followed by a phased enforcement rollout by zone.

Protocol hardening addresses the specific vulnerabilities of physical security protocols. RTSP streams from cameras are encrypted using SRTP (Secure RTP, RFC 3711) where the camera firmware supports it, or tunneled through TLS 1.3 on cameras that support ONVIF Profile T Streaming over HTTPS. ONVIF device management shifts from HTTP to HTTPS with mutual TLS authentication. Default credentials on every device are replaced with unique, randomly generated passwords stored in a privileged access management (PAM) system (CyberArk, BeyondTrust, or HashiCorp Vault). SNMP is reconfigured from v1/v2c (community string, plaintext) to SNMPv3 with AES-256 encryption and SHA-256 authentication, or disabled entirely on devices where it is not operationally required.

Network monitoring uses a combination of SPAN/mirror ports on distribution switches feeding a passive OT monitoring appliance (Nozomi Guardian or Claroty CTD) that performs deep packet inspection of BACnet, ONVIF, RTSP, OSDP, and Modbus traffic. The appliance builds a behavioral baseline for every device—normal communication partners, protocols, data volumes, time-of-day patterns—and generates alerts when deviations occur. These alerts are forwarded to the enterprise SIEM via syslog (CEF format) or API integration, where they are correlated with IT security events. A quarterly vulnerability scan using Tenable.io with OT-specific plugins identifies new CVEs applicable to the discovered firmware versions, and results are prioritized using CVSS v3.1 scoring adjusted for the device's network exposure (a camera on a segmented VLAN with no internet access receives a lower environmental score than a BACnet controller on a flat network).