Skip to main content

Documentation Index

Fetch the complete documentation index at: https://threatbasis.io/llms.txt

Use this file to discover all available pages before exploring further.

Operational Technology (OT) and Industrial Control Systems (ICS) security prioritizes safety and availability over confidentiality, requiring security controls adapted to real-time constraints, legacy protocols, and operational continuity requirements. Security engineers implement defense-in-depth for OT environments through network segmentation, protocol-aware monitoring, and safety-first incident response. Effective OT security balances protection with operational requirements including uptime, deterministic response times, and safety system integrity. OT environments differ fundamentally from IT environments in priorities, constraints, and risk profiles. Security controls must be adapted to OT operational realities rather than directly applying IT security practices. Understanding these differences is essential for security engineers who protect critical infrastructure including manufacturing plants, power grids, water treatment facilities, and transportation systems.

​
OT Architecture and Segmentation

The foundation of OT security lies in proper network architecture and segmentation. Unlike flat IT networks, OT environments require strict hierarchical separation to protect safety-critical systems from cyber threats while maintaining operational efficiency.

​
Purdue Model

The Purdue Enterprise Reference Architecture defines a hierarchical network architecture for industrial control systems organized into distinct levels. Level 0 contains the physical process itself, including sensors and actuators that directly interact with industrial equipment. Level 1 encompasses basic control devices such as Programmable Logic Controllers (PLCs) and Remote Terminal Units (RTUs) that execute control logic. Level 2 provides supervisory control through Human-Machine Interfaces (HMIs) and engineering workstations. Moving up the hierarchy, Level 3 handles site manufacturing operations and includes data historians that store process data. Level 4 manages site business planning and logistics, while Level 5 represents the enterprise network connecting to external business systems. This hierarchical model provides a framework for implementing segmentation controls that protect lower levels from threats originating in higher levels.

​
Network Isolation

Levels 0 and 1 require strict isolation from IT networks because they contain real-time control systems that cannot tolerate disruption. Any compromise at these levels poses direct safety and operational risks to the physical process. Organizations achieve this isolation through multiple technical controls working together. Demilitarized Zones (DMZs) between enterprise and control networks enable controlled data exchange while preventing direct connectivity. These DMZs host data diodes, jump servers, and protocol converters that mediate all traffic between IT and OT domains. Unidirectional security gateways provide even stronger isolation by physically preventing any data flow from IT to OT while allowing process data to flow outbound for business intelligence purposes.

​
Access Control

Strict allow-listing of network communications permits only known-good traffic patterns between OT devices. This approach differs from IT environments where deny-listing of known bad traffic is more common. OT networks have predictable communication patterns that make allow-listing feasible and highly effective at preventing unauthorized connections. Remote access represents a significant attack surface and requires careful controls. Jump hosts with multi-factor authentication and session recording provide controlled access points that enable monitoring and audit of all remote sessions. Organizations should maintain separate VPN infrastructure for OT access, ensuring that compromise of IT VPN systems does not automatically grant access to control systems. VPN and remote access security practices require additional rigor in OT contexts.

​
Asset Inventory and Management

Comprehensive asset inventory forms the foundation of OT security programs. Organizations cannot protect assets they do not know exist, making visibility a prerequisite for all other security controls.

​
Passive Discovery

Passive network monitoring discovers OT assets without the risks associated with active scanning. Active scanning techniques common in IT environments can disrupt OT operations, causing controllers to fault or processes to stop. Passive discovery tools capture network traffic to identify devices, protocols, and communication patterns without injecting any traffic onto the network. Asset inventories should capture device type, vendor, model, firmware version, network location, and communication relationships. This comprehensive data enables risk assessment by identifying vulnerable devices and their connectivity to critical systems. Organizations should update inventories continuously through passive monitoring rather than relying on periodic manual audits.

​
Vendor Documentation

Vendor Bills of Materials (BOMs) document installed components and versions, providing an authoritative source of inventory data. These documents are particularly valuable for understanding software components and nested dependencies within complex control systems. However, BOMs require active maintenance and must be updated whenever changes occur—stale documentation creates dangerous blind spots. Configuration baselines document known-good device configurations and enable detection of unauthorized changes. Security teams should track all configuration changes through formal change management processes and investigate any unauthorized modifications as potential indicators of compromise. Periodic baseline validation through configuration audits detects drift that might otherwise go unnoticed.

​
Patch Management

OT patching operates under constraints that differ significantly from IT environments. Maintenance windows may occur annually or even less frequently due to operational requirements for continuous availability. Vendor support cycles often extend longer than IT software, but legacy systems may lack patches entirely. Vulnerability management processes must account for these realities. When patching is not feasible, compensating controls reduce risk. Network segmentation limits the exposure of vulnerable systems, while protocol-aware monitoring detects exploitation attempts. Organizations should test patches comprehensively in non-production environments that replicate the production configuration, as untested patches have caused significant operational incidents in critical infrastructure.

​
Protocol-Aware Monitoring

Effective OT security monitoring requires deep understanding of industrial protocols that differ significantly from standard IT network traffic. Generic security tools cannot provide adequate visibility into OT environments.

​
Industrial Protocol Support

Protocol-aware intrusion detection systems must support industrial protocols including Modbus, DNP3, Profinet, EtherNet/IP, and OPC-UA. This protocol awareness enables deep packet inspection that can identify malicious commands rather than just network anomalies. When these systems detect protocol violations, security teams should investigate them as potential indicators of attack or misconfiguration. Protocol-specific attacks require specialized detection capabilities. Command injection attacks that attempt to manipulate process values, unauthorized write operations to controller memory, and denial-of-service attacks targeting protocol weaknesses all require knowledge of how legitimate protocol traffic should appear. Advanced threat detection techniques adapted for OT protocols provide this specialized capability.

​
Anomaly Detection

Establishing baseline behavior for normal operations enables detection of anomalies that signature-based detection would miss. OT networks exhibit predictable traffic patterns during normal operations, making anomaly detection particularly effective. Deviations including unexpected communication pairs, unusual command sequences, and abnormal process values may indicate compromise. Time-series analytics applied to process data can detect attacks that manipulate physical processes. These attacks might not generate obvious network anomalies but produce subtle changes in process behavior that analytics can identify. Threat hunting teams should include process engineers who understand expected operational patterns.

​
Monitoring Architecture

Monitoring infrastructure must avoid introducing risk to OT operations. Network TAPs and SPAN ports provide traffic visibility without inline risk—security tools that require inline deployment can cause operational disruptions if they fail. All monitoring components must demonstrate that they do not impact OT network performance, as any latency or packet loss is unacceptable in real-time control environments. Security monitoring data should flow to a separate security network isolated from both IT and OT production environments. This separation ensures that compromise of monitoring infrastructure does not provide attackers access to control systems. The SIEM and log management architecture should accommodate OT-specific data sources and retention requirements.

​
Logging and Time Synchronization

​
Log Retention

Log retention policies for OT environments must account for extended dwell times and delayed incident discovery. Unlike IT environments where compromises are often discovered within weeks, OT intrusions may go undetected for months or years. Long retention periods of one year or more enable historical investigation when incidents are eventually discovered. Log storage infrastructure must be sized appropriately for these extended retention requirements. Insufficient storage that causes log rotation or loss can eliminate critical evidence needed for incident investigation. Organizations should monitor storage utilization and plan capacity proactively.

​
Secure Time Synchronization

Accurate time synchronization is critical for log correlation, incident investigation, and regulatory compliance. OT environments must use secure time synchronization protocols to prevent time manipulation attacks that could complicate forensic analysis or enable replay attacks. NTP authentication prevents attackers from manipulating time sources to hide their activities. Time sources should be redundant and monitored for availability and accuracy. Time source failures affect logging, event correlation, and any time-dependent control logic. Organizations should maintain multiple synchronized time sources and alert on synchronization failures.

​
Tamper-Evident Storage

Logs should be stored in tamper-evident storage that prevents or detects post-compromise manipulation. Sophisticated attackers who compromise OT environments often attempt to modify or delete logs to cover their tracks. Write-once storage media or cryptographic signing of log entries provides tamper evidence that supports incident investigation and regulatory compliance.

​
Incident Response in OT

Incident response in OT environments requires procedures adapted for operational constraints and safety requirements. Standard IT incident response playbooks can create additional hazards when applied to industrial environments.

​
Safety-First Containment

Safety considerations take precedence over all other factors in OT incident response. Containment actions that security teams might routinely execute in IT environments—such as isolating systems or shutting down services—could create safety hazards in industrial settings. Predefined manual overrides must enable safe shutdown of processes when required, and operations teams should regularly test these override procedures. Incident response procedures must be developed collaboratively with operations and safety teams who understand process hazards. Security teams should never take containment actions without coordinating with personnel who can assess the safety implications of those actions.

​
Vendor Coordination

OT vendors possess specialized knowledge of their equipment that security teams typically lack. Engaging vendors early in incident response provides access to diagnostic capabilities, known vulnerabilities, and recommended remediation procedures. Organizations should maintain current vendor contact information in accessible locations that remain available even if primary communication systems are compromised. Contracts should define vendor response SLAs for security incidents, including provisions for emergency support outside normal business hours. Third-party vendors for integration and maintenance may also require engagement during incidents, so third-party risk management programs should include incident response coordination requirements.

​
Exercises and Testing

Tabletop exercises for OT environments must include operations, safety, and security teams working together. These cross-functional exercises improve coordination and help each team understand the constraints and priorities of others. Scenarios should include OT-specific attack patterns including controller compromise, historian manipulation, and safety system interference. Exercises provide opportunities to validate manual override procedures before they are needed in actual incidents. Teams should physically execute safety procedures during exercises to verify they work as documented and that personnel maintain proficiency. The red, blue, and purple teaming approach can be adapted for OT environments with appropriate safety constraints.

​
Recovery

Recovery procedures must prioritize safety systems and critical processes in the correct sequence. Attempting to restart processes before safety systems are validated could create hazardous conditions. All recovery should include validation of system integrity before restart, ensuring that compromised systems do not return to operation with malicious code or configurations still present. Business continuity and disaster recovery plans for OT environments require specialized considerations including manual operation procedures, equipment lead times for replacement, and coordination with regulatory authorities for safety-critical systems.

​
Governance and Compliance

Effective OT security requires governance structures and compliance programs adapted for operational environments. Standard IT security governance often fails to account for OT constraints and priorities.

​
IEC 62443

The IEC 62443 series provides the most comprehensive international standards for industrial automation and control systems security. This standard family addresses security across the entire OT lifecycle from product development through system integration and ongoing operations. IEC 62443-3-3 defines system-level security requirements organized into foundational requirements including identification and authentication, use control, system integrity, data confidentiality, and resource availability. IEC 62443-4-2 defines component-level security requirements that guide procurement decisions and vendor assessments. The standard defines four Security Levels (SL 1-4) that specify protection requirements against progressively more capable threat actors, enabling risk-based implementation appropriate to each organization’s threat environment.

​
NERC CIP

NERC CIP (Critical Infrastructure Protection) standards apply specifically to the bulk electric system in North America. These mandatory standards carry significant penalties for violations and require documented compliance programs audited by regional entities. NERC CIP requirements span asset identification and categorization, security management controls, personnel training and awareness, electronic security perimeter implementation, physical security, system security management, incident response, and configuration change management. The standards continue to evolve with emerging threats and incorporate lessons learned from significant incidents.

​
Change Management

Change management processes for OT environments must include security review to prevent introduction of vulnerabilities through configuration changes or software updates. Separation of duties ensures that individuals who request changes cannot also approve and implement them without oversight. Emergency change procedures should balance the need for rapid response with documentation and approval requirements. Even urgent changes should be documented contemporaneously and reviewed retrospectively. All changes require comprehensive testing, as untested modifications have caused significant operational incidents in critical infrastructure.

​
Access Reviews

Access to OT systems requires regular review to ensure that permissions remain appropriate as roles and responsibilities change. Privileged access to safety-critical systems warrants more frequent review than standard user access. Organizations should revoke access immediately when employees terminate or transfer to roles that no longer require OT access—delayed revocation creates risk that is unacceptable for critical infrastructure.

​
Supply Chain Risk

The OT supply chain encompasses hardware components, embedded software, configuration services, and ongoing maintenance relationships. Each element introduces potential security risks that require management through software supply chain security practices adapted for industrial contexts. Vendor security assessments must include OT-specific requirements beyond standard IT vendor questionnaires. Questions should address secure development practices for embedded systems, firmware signing capabilities, vulnerability disclosure processes, and long-term support commitments. Component authenticity verification is critical because counterfeit PLCs, sensors, and other industrial components create both safety hazards and security vulnerabilities. All firmware and software should be verified before installation through cryptographic hash verification or digital signature validation. This verification prevents installation of malicious code that could have been introduced during distribution or storage. Organizations should obtain software only from verified vendor sources and maintain chain of custody documentation.

​
Conclusion

OT and ICS security requires adapting security controls to operational realities including safety priorities, real-time constraints, and legacy protocols. Security engineers implement defense-in-depth through network segmentation based on the Purdue Model, protocol-aware monitoring that understands industrial communications, and safety-first incident response procedures developed collaboratively with operations teams. Success requires continuous collaboration between security, operations, and safety teams, with each group understanding the priorities and constraints of the others. Implementation of standards including IEC 62443 provides a structured framework for OT security programs that scales appropriately with organizational risk. Organizations that invest in OT security fundamentals protect critical infrastructure while maintaining the safe, reliable operations that society depends upon.

​
References