Migrate to new Gitea instance (gitea.wbd-rd.nl)
- Update all submodule URLs from gitea.centraal.wbd-rd.nl to gitea.wbd-rd.nl - Add settler as proper submodule in .gitmodules - Add agent skills, function anchors, decisions, and improvements - Add Docker configuration and scripts - Add manuals and third_party docs - Update .gitignore with secrets and build artifacts - Remove stale .tgz build artifact Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
znetsixe
149
third_party/docs/ot-security-iec62443.md
vendored
Normal file
149
third_party/docs/ot-security-iec62443.md
vendored
Normal file
@@ -0,0 +1,149 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user