EVOLV/third_party/docs/ot-security-iec62443.md

OT Security Standards — IEC 62443 & NIST SP 800-82

Used by: ot-security-integration agent Validation: Verified against IEC 62443 series, NIST SP 800-82, Dragos, and Rockwell Automation publications

IEC 62443 Framework Overview

IEC 62443 "Industrial communication networks — IT security for networks and systems" is the primary international standard series for Industrial Automation and Control System (IACS) cybersecurity.

Standard Structure

Part	Title	Scope
62443-1-x	General	Concepts, vocabulary, use cases
62443-2-x	Policies & Procedures	Security management system, patch management
62443-3-x	System	System security requirements, zones & conduits
62443-4-x	Component	Secure development lifecycle, component requirements

Key Parts for EVOLV

• 62443-3-2: Security risk assessment and system design
• 62443-3-3: System security requirements and security levels
• 62443-4-2: Technical security requirements for IACS components

Zones and Conduits

Security Zone

A zone is a logical or physical grouping of assets that share common security requirements. Assets within a zone have the same security level (SL) target.

Conduit

A conduit is a logical or physical grouping of communication channels connecting two or more zones. Conduits require security controls appropriate for the traffic they carry.

EVOLV Zone Architecture (typical WWTP deployment)

Zone 0: Enterprise IT Network (SL 1-2)
  ↕ [Conduit: Firewall/DMZ]
Zone 1: SCADA/Historian Network (SL 2-3)
  ↕ [Conduit: Data diode or filtered bridge]
Zone 2: Process Control Network (SL 3)
  ↕ [Conduit: Managed switch with ACLs]
Zone 3: Field Device Network (SL 2-3)
  - PLCs, RTUs, I/O modules
  - Node-RED edge runtime (EVOLV)
  - Sensors and actuators

Zone Design Rules

• A zone can contain sub-zones
• A conduit cannot contain sub-conduits
• A zone can have more than one conduit
• Every device must belong to exactly one zone
• Communication between zones must pass through a conduit

Security Levels (SL)

Level	Protection Against	Typical Measures
SL 0	No specific requirements	—
SL 1	Casual or coincidental violation	Basic authentication, logging
SL 2	Intentional attack with low motivation, generic skills	Role-based access, encrypted communications
SL 3	Intentional attack with moderate motivation, IACS-specific skills	Strong authentication, intrusion detection, hardened systems
SL 4	Intentional attack with high motivation, IACS-specific skills, extended resources	Dedicated security team, continuous monitoring, zero-trust

SL Types

• SL-T (Target): Required security level for the zone
• SL-A (Achieved): Actual security level implemented
• SL-C (Capability): Maximum security level a component can support

NIST SP 800-82 — Guide to ICS Security

Source: NIST Special Publication 800-82 Revision 3 (2023). "Guide to Operational Technology (OT) Security"

Key Recommendations

1. Develop and maintain an OT-specific security program
2. Segment OT networks from IT networks (defense in depth)
3. Apply least privilege access control
4. Monitor OT network traffic for anomalies
5. Maintain an accurate OT asset inventory
6. Implement secure remote access with MFA
7. Develop OT-specific incident response plans
8. Regularly assess and manage OT security risks

OPC UA Security Model

Authentication

• X.509 certificates for server and client authentication
• Username/password as fallback (less secure)
• Anonymous access (should be disabled in production)

Encryption

• Security policies define algorithm suites:
  • None — No security (testing only)
  • Basic128Rsa15 — Deprecated, avoid
  • Basic256 — Deprecated, avoid
  • Basic256Sha256 — Minimum recommended
  • Aes128_Sha256_RsaOaep — Preferred
  • Aes256_Sha256_RsaPss — Strongest

Message Security Modes

• None — No signing or encryption
• Sign — Messages signed but not encrypted
• SignAndEncrypt — Full protection (recommended)

Modbus Security Considerations

Vulnerabilities (standard Modbus TCP)

• No authentication — any network client can read/write registers
• No encryption — all traffic is plaintext
• No integrity protection — commands can be modified in transit
• Predictable function codes — easy to craft malicious packets

Mitigations

1. Network segmentation — isolate Modbus devices in dedicated VLANs
2. Firewall rules — whitelist only authorized master IP addresses
3. Application-layer filtering — deep packet inspection for Modbus function codes
4. Monitoring — detect unusual register access patterns
5. Modbus/TCP Security (TLS) — available in newer implementations (RFC 7878-based)

EVOLV-Specific Security Considerations

Node-RED Admin Endpoints

• GET /<nodeName>/menu.js — Serves configuration data to editor
• GET /<nodeName>/configData.js — Serves runtime config to editor
• Risk: Information disclosure if exposed beyond editor network
• Mitigation: Bind Node-RED to localhost or trusted network only

msg.topic Input Validation

• All msg.topic handlers must validate topic format before processing
• Prevent topic injection: reject topics containing path separators, special characters
• Validate payload types and ranges before applying to control logic

Dynamic Configuration

• Configuration loaded from files or received via MQTT
• Must validate schema, types, and value ranges before applying
• Reject configurations that would violate safety envelopes

Control Message Safety

• Validate actuator commands against physical limits before sending
• Rate-limit control output changes (prevent rapid cycling)
• Log all control actions with timestamp, source, and reason

Authoritative References

1. IEC 62443 series (2018-2024). "Industrial communication networks — IT security for networks and systems"
2. NIST SP 800-82 Rev 3 (2023). "Guide to Operational Technology (OT) Security"
3. Dragos Inc. — "Understanding ISA/IEC 62443: A Guide for OT Security Teams" (https://www.dragos.com/blog/isa-iec-62443-concepts)
4. ISA/IEC 62443-3-3 — "System Security Requirements and Security Levels"
5. OPC Foundation — "OPC UA Security Model" specification
6. Modbus Organization — "MODBUS/TCP Security" specification