OT/ICS Industrial Security: Protection concepts for industrial plants and KRITIS

Operational Technology (OT) refers to hardware and software that directly controls and monitors physical devices, processes, and infrastructure. OT systems were designed for reliability and longevity, not for cybersecurity: PLCs with a 20-year lifespan, proprietary protocols without authentication, Windows XP HMIs that can no longer be patched. At the same time, the integration of OT and IT (Industry 4.0) is growing, and with it, the attack surface is expanding rapidly. Stuxnet, Triton, and the attacks on Ukraine prove it: critical infrastructures are real targets with physical consequences.

OT vs. IT: Fundamental Differences

The Different World of Operational Technology:

IT Security (Traditional):        OT Security:
  Priority: CIA Triad              Priority: AIC Triad (Availability first!)
  Patches: can be applied quickly           Patches: Maintenance windows, vendor approval
  Lifecycle: 3–5 years               Lifecycle: 15–30+ years
  Downtime: tolerable              Downtime: can cost lives / environmental disaster
  Protocols: TCP/IP standard        Protocols: Modbus, DNP3, OPC-UA, Profinet, EtherNet/IP
  Updates: automatic               Updates: manual, tested, often never
  Isolation: sometimes                Isolation: historically air-gapped (but increasingly IT-networked!)

OT Component Classes:

OT (Operational Technology):
  → Umbrella term for technology that controls physical processes
  → Includes: ICS, SCADA, DCS, PLC, RTU, HMI, Safety Systems

ICS (Industrial Control Systems):
  → Category of control systems for industrial processes
  → Subtypes: SCADA, DCS, PLC-based systems

SCADA (Supervisory Control and Data Acquisition):
  → Monitoring and control system for distributed facilities
  → Examples: power grids, water treatment plants, pipelines
  → Communicates with Remote Terminal Units (RTUs) via WAN

DCS (Distributed Control System):
  → For continuous processes in a facility
  → Examples: chemical plants, refineries, power plants

PLC (Programmable Logic Controller):
  → Industrial computer for discrete/sequential control
  → Programmed in Ladder Logic, Structured Text, FBD (IEC 61131-3)
  → Examples: Siemens S7-300/400/1200/1500, Allen-Bradley, Schneider Modicon

RTU (Remote Terminal Unit):
  → Field devices for remote SCADA communication
  → Often located in remote sites (pumping stations, substations)
  → Communicates via DNP3, IEC 60870-5-101/104

HMI (Human Machine Interface):
  → User interface for process visualization and control
  → Often runs on long-lived Windows systems

SIS (Safety Instrumented System):
  → Physical safety systems (emergency shutdown, overpressure protection)
  → Separate from PLC/SCADA (IEC 61511)
  → TRITON attack targeted SIS (the biggest known OT security risk!)

EWS (Engineering Workstation):
  → Programming laptop for PLCs
  → Historian: Time-series data storage (OSIsoft PI)

Most Notable OT Attacks (Case Studies)

Historical OT Attacks:

Stuxnet (2010) - First known OT cyberweapon:
  Target: Iranian uranium enrichment facility (Natanz)
  Method:
  → USB flash drive as entry point (Siemens Engineering Workstation)
  → Siemens Step 7 PLC programming software infected
  → PLCs (Siemens S7-315) for centrifuges manipulated
  → Centrifuges ran at incorrect speeds → physical damage
  → SCADA displayed NORMAL values (manipulation of the display!)
  Lesson: An air gap alone does not provide protection; software integrity is critical

TRITON/TRISIS (2017) - Safety system attack:
  Target: Petrochemical plant (Saudi Arabia)
  Method:
  → Triconex Safety Instrumented System (SIS) attacked
  → SIS prevents plant disasters (explosion, fire)
  → Attackers: Cause SIS to fail → enable physical explosion
  → Discovered by chance: SIS triggered fail-safe mode
  Lesson: Safety systems are targets; explicit protection is necessary

Industroyer/Crashoverride (2016) - Ukrainian power grid:
  Target: Ukrainian power distribution SCADA
  Method:
  → Native support for IEC 61850, IEC 60870-5-104, IEC 60870-5-101 protocols
  → Circuit breakers remotely controlled → Power outage in Kyiv
  → Wiper component: Substation workstations destroyed
  Lesson: Industrial protocols lack inherent authentication

Colonial Pipeline (2021):
  → Ransomware in the IT network, but OT shutdown as a precaution
  → Compromised VPN credentials as the entry point

Common attack vectors today:
  1. Compromised IT/OT interface:
     → Remote maintenance VPN for machine manufacturers
     → Shared credentials for SCADA remote access
     → IT Active Directory with domain trust to the OT environment

  2. Supply chain (suppliers):
     → Software updates from manufacturers (similar to SolarWinds for OT)
     → Technicians’ USB service laptops
     → Remote service connections without MFA

  3. Legacy protocol vulnerabilities:
     → Modbus: no authentication, no encryption, no integrity checks
     → DNP3: no authentication (without Secure Authentication v5)
     → BACnet (building automation): often directly exposed to the internet

  4. Poorly secured HMI/SCADA web interfaces:
     → SCADA web interfaces exposed to the internet (Shodan!)
     → Default credentials (admin/admin, root/root)
     → Unpatched web vulnerabilities (SQL injection in SCADA web interface!)

Industrial Protocols and Their Security Characteristics

OT protocols were designed for reliability, not security:

Modbus (1979):
  Transport: TCP (Port 502) or Serial (RS-485)
  Security: NO authentication, NO encryption
  Problem: Anyone on the network can send commands to Modbus devices
  Critical function codes:
    FC 05: Writes Single Coil (Actuator ON/OFF!)
    FC 06: Writes Single Register
    FC 15: Writes Multiple Coils
    FC 16: Writes Multiple Registers
  Protection: Whitelist allowed function codes via firewall

DNP3 (1993):
  Application: Power grids, water treatment plants (SCADA↔RTU)
  Security: Basic DNP3 = no authentication; DNP3 Secure Authentication v5 = HMAC
  Problem: Many implementations still lack SAv5
  Attack: Industroyer exploited a DNP3 module against the Ukrainian power grid

IEC 60870-5-104:
  Application: European power grid (similar to DNP3, TCP/IP)
  Security: No authentication in base specification
  Extension: IEC 62351 (Security for IEC 60870-5/61850)

Profinet (Siemens):
  Transport: Ethernet Layer 2 or UDP
  Security: optional (Profinet Security Level 2 starting in 2022)
  Strength: Industrial real-time requirements

EtherNet/IP (Rockwell/Allen-Bradley):
  Transport: TCP/UDP
  Security: Optional since CIP Security (2017)
  Strength: IT network compatible

OPC UA (Unified Architecture):
  Transport: TCP (Port 4840) or HTTPS
  Security: Integrated! TLS, authentication, signing
  Role: "Secure" IT/OT bridge, SCADA↔ERP communication
  Recommendation: OPC UA as the standard for new OT implementations

Conclusion:
  → Legacy protocols (Modbus, DNP3 without SAv5) = no inherent security
  → Security must be enforced at the network level (firewall, IDS, segmentation)
  → New implementations: Prefer OPC UA or CIP Security

Purdue Reference Model and IEC 62443

ISA/IEC 62443 Purdue Reference Architecture:

Level 5 - Enterprise Network (IT):
  → ERP (SAP), office systems, email, internet
  → User workstations, Active Directory
  ─────────────────────── DMZ / Firewall ──────────────────────
Level 4 - Site Business Planning & Logistics:
  → Production planning, MES (Manufacturing Execution System)
  → Data historians (OSIsoft PI, AspenTech), Data Diode
  ─────────────────────── Firewall ────────────────────────────
Level 3.5 - Industrial DMZ:
  → Data diodes, unidirectional gateways
  → Patch Management Server, Antivirus Updates
  → Remote Access Jump Hosts
  ─────────────────────── Firewall ────────────────────────────
Level 3 - Site Manufacturing Operations:
  → SCADA Server, Historian Collector, OT-DMZ
  → Engineering Workstations
  ─────────────────────── Firewall ────────────────────────────
Level 2 - Area Supervisory Control:
  → DCS Controllers, HMIs, Local Historian
  → Alarm Management Systems
  ─────────────────────── Level 2 Network ───────────────────────
Level 1 - Basic Control:
  → PLCs, RTUs, Flow Controllers, Drives
  ─────────────────────── Fieldbus ─────────────────────────────
Level 0 - Physical Process:
  → Sensors, Actuators, Valves, Motors

Security Principle: Traffic controlled from top to bottom
  Level 5 must NOT directly reach Level 1!
  NO direct connection between Level 5 and Levels 0–2!
  DMZ as a buffer: only defined, controlled communication
  Data diodes where possible: physically only one direction allowed

IEC 62443 - Standard for Industrial Security

IEC 62443 family of standards:

IEC 62443-1: General (Terminology, Models)
  → Roles: Asset Owner, System Integrator, Component Supplier

IEC 62443-2-1: Security Management System
  → ISMS for industrial automation (comparable to ISO 27001 for OT)
  → Risk Assessment and Treatment

IEC 62443-2-4: Service Provider Requirements
  → Requirements for System Integrators and Service Providers

IEC 62443-3-2: Security Risk Assessment
  → Methodology for OT Risk Assessment

IEC 62443-3-3: System Security Requirements and Security Levels (SL):
  SL 0: No specific protection
  SL 1: Protection against unintentional errors / incorrect operation
  SL 2: Protection against intentional simple attacks (normal means)
  SL 3: Protection against sophisticated attacks (IIoT expertise)
  SL 4: Protection against state-level attacks (Stuxnet level)

  Target SL → determined by risk analysis
  Achieved SL → current actual state
  Capability SL → maximum SL of the component/solution

  SL classification based on risk analysis:
  → Critical KRITIS facilities: SL 3-4
  → Standard production: SL 2
  → Non-critical automation cells: SL 1

IEC 62443-4-1: Secure Development Lifecycle (for manufacturers)
  → Security-by-design for ICS components
  → Patch and vulnerability management processes

BSI ICS Security Compendium:
  → Free: bsi.bund.de/ICS
  → German, for operators of critical infrastructure
  → Top 10 threats + measures for ICS

Zone and Conduit Model

IEC 62443-3-3: Zones and Conduits:

Zone:
  → Logical grouping of assets with the same protection requirements
  → Example zone "Reactor Control": PLCs, HMIs, RTUs of the reactor

Conduit:
  → Communication path between zones
  → EVERY conduit is a potential attack surface → must be protected!
  → Conduit controls: Firewall, data diode, VPN, DMZ

Zone definition process:
  1. Asset inventory (record all OT components)
  2. Map communication relationships (who communicates with whom?)
  3. Group similar assets (same function/same operator)
  4. Define zone boundaries (firewall, VLAN, physical separation)
  5. Identify and document conduits
  6. Determine security level per zone (risk analysis!)

Example: Water treatment plant zone model:
  Zone 1: IT office network (SL 1)
           ↕ Conduit A (firewall + DMZ)
  Zone 2: SCADA network (SL 2)
    ├─ Zone 2a: Control room (SCADA server, HMI)
    │           ↕ Conduit B (Layer 3 firewall, whitelist rules)
    └─ Zone 2b: OT network (SL 2)
         ├─ Zone 3: North Pump Control (PLCs, RTUs) [Layer 3]
         │           ↕ Conduit C (Data Diode → read-only)
         └─ Zone 4: Chlorination (Safety-Critical) [Layer 4]

Firewall Rules for OT Conduits:
  # Whitelist Only! (no "Deny Rest" as a fallback)
  # Allowed: Historian-Collector → PLC (TCP/102 - Siemens S7)
  # Allowed: HMI → PLC (OPC-UA, Port 4840)
  # EVERYTHING else: DENY + LOG

Segmentation Architecture

Defense-in-Depth for OT:

Level 1: Physical Separation
  → Air Gap for ultra-high security requirements (SIS, military)
  → Data Diode: Hardware-enforced one-way communication
    Vendors: Owl Cyber Defense, Waterfall Security, Advenica
    Use Case: OT Historian → IT Analytics without a return channel

Level 2: Industrial DMZ
  → Intermediate zone between IT network (Level 4) and OT network (Level 3)
  → Contains: Historian replica, patch server, jump host, antivirus update server
  → IT systems only access the IDMZ (never OT directly)

  What is allowed in the DMZ:
  ✓ Antivirus update server (pull from IT, push to OT)
  ✓ Patch management server
  ✓ Remote access jump host (for remote maintenance)
  ✓ Active Directory read-only domain controller
  ✓ Historian replication
  ✗ Internet access (NO!)
  ✗ Email clients in the OT network
  ✗ Domain trust between IT AD and OT AD

  Firewall rules IT→IDMZ:
    ALLOW: ERP server → Historian replica IDMZ TCP:1433 (Read-only!)
    ALLOW: Patch Server-IT → Patch Repository-IDMZ TCP:445
    DENY: ANY → OT Core

  Firewall Rules IDMZ→OT:
    ALLOW: Historian Replica → OT Historian TCP:5450 (PI Protocol)
    ALLOW: Jump Host → PLC IPs TCP:102 (S7comm) - ONLY during maintenance!
    DENY: ANY → OT-Core (Default)

Level 3: Microsegmentation within OT
  → Process lines as separate zones
  → PLC Zone, HMI Zone, Engineering Zone, Safety Zone SEPARATED
  → Safety Zone: physically isolated, NO IP connection to other zones!

Level 4: OT-IDS/IPS
  → Passive anomaly detection on OT traffic
  → Alarm on: unknown PLC command, unknown communication relationship

Practical example – Chemical plant:
  Zone A: Enterprise (IT network)
  Zone B: IDMZ (Historian replica, patch server, MES proxy)
  Zone C: Production Control (SCADA, Historian, Engineering WS)
  Zone D: Reactor PLC (PLC for reactors – internal traffic only!)
  Zone E: Packaging PLC (PLC for filling)
  Zone F: Safety (SIS – physically isolated, no IP!)
  Conduit C→D: Whitelist Modbus FC03/04 only
  Conduit C→F: Physical: Serial only (no Ethernet!)

Asset Management for OT Systems

OT Asset Inventory - Special Features:

Why it’s more difficult than IT:
  → No standard management interfaces (no WMI, no SNMP standard)
  → Active scans can disrupt/crash OT systems!
  → Age: 15–30 years, undocumented configurations
  → Shifting responsibilities: IT doesn’t know OT, OT doesn’t know IT

Asset Discovery Methods (security-oriented):

1. Passive network analysis (preferred):
   Nozomi Networks Guardian:
     → Passive sensor on SPAN port/mirror port
     → Automatically detects: Device type, manufacturer, firmware, protocol
     → Communication matrix: which device communicates with which?
     → Baseline creation: define normal behavior
     → Supports 300+ OT protocols

   Claroty Continuous Threat Detection:
     → Passive asset discovery (no scanning! Only network tap)
     → IT/OT asset convergence in a single platform
     → ICS protocol deep inspection: Modbus, EtherNet/IP, OPC UA, DNP3

   Dragos Platform:
     → OT-specific threat detection system
     → Asset discovery as a byproduct of monitoring
     → Threat group mapping (Dragos recognizes OT threat groups)

   Microsoft Defender for IoT (formerly CyberX/Azure Defender for IoT):
     → Agentless, Microsoft integration: Sentinel, Defender for Endpoint
     → Good asset discovery for mixed IT/OT environments

2. Active Scanning (Caution!):
   → Only with manufacturer approval and during maintenance windows
   → Siemens: proprietary TIA Portal Discovery
   → Rockwell: FactoryTalk AssetCentre
   → Generic NMAP: NEVER in an OT network!

   # Nmap OT Fingerprinting (only during maintenance windows!):
   nmap --script s7-info -p 102 192.168.1.0/24
   nmap --script modbus-discover -p 502 192.168.1.0/24
   # S7 CPUs may crash!

Asset database minimum fields:
  □ Manufacturer + Model (e.g., Siemens S7-315)
  □ Firmware Version (e.g., V2.6.1)
  □ Hardware Revision
  □ IP Address + MAC Address
  □ VLAN / Network Segment / Zone
  □ Physical Location (Control Cabinet, Hall)
  □ Function (what does this device control?)
  □ Process criticality (failure = production stoppage?)
  □ Communication partners (communication matrix)
  □ Last firmware update / next maintenance window
  □ Person responsible (OT engineer + backup)
  □ Maintenance contract (manufacturer support active?)

OT Vulnerability Management and Patch Management

The OT Patch Dilemma:

Why OT patches are so difficult:
  → Windows XP, CE: no more patches (EOL)
  → PLC firmware: updates require production shutdown + testing + manufacturer certification
  → Some systems: can only be patched once a year during the maintenance window
  → Manufacturer certification: certain Windows patches can break PLC software!
  → Refinery: 1 hour of production downtime = 100,000+ EUR

Patch process for OT:
  1. Vulnerability information (subscribe to RSS feeds!):
     → CISA ICS-CERT Advisories: us-cert.gov/ics
     → Siemens ProductCERT: siemens.com/cert
     → Schneider Electric EVITA / PSIRT
     → ABB PSIRT: abb.com/support/cybersecurity
     → NIST NVD: nvd.nist.gov

  2. Risk analysis:
     → CVSS ≥ 9.0: immediate assessment (but: check availability!)
     → Exploitability: are public exploits available?
     → Network accessibility: Internet-exposed? Air-gapped?

  3. Testing in staging:
     → Identical system (if possible)
     → Manufacturer approval required (safety systems!)
     → Regression testing: Are all control functions OK?

  4. Deployment:
     → Coordinate maintenance window (stop production)
     → Rollback plan: Image backup before patch
     → Emergency contact: Is manufacturer support available?

Patch prioritization for OT:
  CRITICAL (immediately in the next maintenance window):
    → CVSS ≥ 9.0 AND exploit available AND device has network access
    → Known exploitation by APT groups (ICS-CERT alert!)
  HIGH (within 3 months):
    → CVSS 7.0–9.0 AND device is accessible from the outside
  MEDIUM (next scheduled maintenance window):
    → CVSS 4.0–7.0 AND internal systems
  LOW:
    → CVSS < 4.0 OR internal systems without network access

Compensatory security measures (if patching is not possible):
  1. Network segmentation: Isolate vulnerable components
  2. Virtual patching: IPS signature blocks known exploits at the network level
  3. Application whitelisting: Only allow permitted programs
     McAfee Solidcore (ePolicy) for HMI systems
     Carbon Black (App Control) for OT Windows
  4. Monitoring: Double-monitor unpatched systems
  5. Write protection: PLCs in read-only mode
  6. Deactivation: Unnecessary services and ports

Security architecture: Air gap and secure remote access

Air Gap, Data Diodes, and Secure Remote Access:

True Air Gap:
  → Physically isolated: no network cables, no Wi-Fi
  → Data transfer: USB drives (Stuxnet vector!), laptops
  → Problem: maintenance-intensive, USB = risk
  → Protection: USB blockers, USB disinfection (Qubes-based)

Data Diode (physically enforced one-way communication):
  → Hardware component: Data can only flow in one direction
  → Physics: optical transmission without a return channel
  → Vendors: Owl Cyber Defense, Waterfall Security, Advenica

Secure Remote Access (Maintenance/Vendor Access):
  # PROBLEM: Attackers exploit third-party VPN access
  # Colonial Pipeline: Compromised VPN credentials

  Requirements:
  → Jump server / bastion host in OT-DMZ
  → MFA for ALL remote access (no passwords alone!)
  → Session recording: record all actions
  → Time-limited access: automatically expires after X minutes
  → Least privilege: access only to necessary systems
  → Vendors: dedicated accounts, no shared credentials

  Technology stack:
  → CyberArk Privileged Remote Access
  → Claroty Secure Remote Access
  → In-house solution: Jumpserver (SSH Bastion) + PAM

  Privileged Access Workstation (PAW) for OT:
  → Dedicated laptop, only for OT admin access
  → No email, no browser, no USB drives
  → BitLocker encrypted, EDR active

OT Security Monitoring and SIEM Integration

Anomaly Detection in OT Environments:

Baseline Creation:
  → OT environments exhibit very stable, predictable behavior
  → PLCs always communicate with SCADA servers, never directly with the Internet
  → Communication matrix: who communicates with whom? (Whitelist approach)
  → Deviations = highly suspicious
  → Baseline period: Record 2–4 weeks of normal operation

OT Monitoring Best Practices:
  □ Passive monitoring ONLY (active scanning can cause PLCs to crash!)
  □ Alerts for: new devices, new connections, unknown protocol commands
  □ No direct connections from the OT-SIEM to the Internet
  □ 24/7 OT SOC or MDR service for critical systems

Critical OT events for SIEM alerting:
  □ New device on the OT network (unknown MAC address)
  □ First-time communication between two devices
  □ PLC configuration change (Ladder Logic upload!) outside of maintenance windows
  □ Modbus write command (FC05/06/15/16) from unknown source
  □ Engineering workstation with active PLC programming software outside of maintenance
  □ Direct connection OT → Internet (exfiltration!)
  □ Password change on OT system
  □ USB device connected to HMI (if USB monitoring is available)

Log sources for OT-SIEM:
  → Firewall logs (IT/OT boundary): most critical log source
  → Windows Event Logs from HMIs and engineering workstations
  → SCADA audit logs (if available)
  → Historian change logs
  → Network traffic (passive via SPAN port)
  → VPN logs (remote access logging!)

OT-SIEM integration:
  → Nozomi Guardian → Sentinel/Splunk/QRadar integration
  → Claroty → proprietary platform + SIEM forwarding
  → Dragos → proprietary platform
  → Microsoft Sentinel: Defender for IoT (native integration)

Incident Response for OT

OT-IR differs fundamentally from IT-IR:

IT vs. OT: Fundamental conflict:
  IT-IR paradigm: Immediately isolate/shut down the system
  OT reality: Shutdown = production stoppage, security risk!
    Example: Pump running at 2,000 RPM → immediate shutdown → water hammer → pipe rupture!
    Example: Power plant → load shedding → grid instability!
  OT-IR principle: Safety first – then Availability – then Security

OT-IR Team Composition:
  □ OT Security Analyst (technical analysis)
  □ Process Engineer (understands the physical consequences of actions!)
  □ Safety Engineer (SIS expertise)
  □ OT Network Specialist
  □ IT IR Expert (for the IT side of the pivot)
  □ Government Liaison (KRITIS: BSI, Federal Network Agency)

OT IR Process:

Phase 1 - Detection:
  → Anomaly alert from Nozomi/Claroty/Dragos
  → OR: Physical anomaly (control error, unplanned actions)
  → FIRST QUESTION: Is the plant physically secure? Is the SIS functioning correctly?
  □ Does the incident involve physical security risks? → Notify the Safety Team!
  □ Spread to safety systems? → Check for emergency shutdown with Operations!
  □ Is production downtime acceptable? → Decide only after consulting with the Plant Manager!

Phase 2 - Assessment (within 1 hour):
  □ Identify affected assets (without isolating them!)
  □ Start network captures (without altering traffic)
  □ Increase manual monitoring (inform process operators)
  □ Contact OT manufacturers (Siemens, Rockwell PSIRT)
  → Is this an IT incident with OT implications? (Ransomware in the IT network)
  → Is OT directly compromised? (PLC configuration altered?)
  → Can the plant continue to run in emergency mode?

Phase 3 - Containment (with Operations approval, without production stoppage if possible):
  □ Block compromised communication paths (firewall configuration change)
  □ Isolate affected workstations (NOT PLCs!)
  □ Deploy backup HMIs / engineering workstations
  □ Switch to manual control if possible
  NEVER: Simply unplug the power cord while the process is running!
  Option: Switch the suspect OT system to manual control
  Option: Isolate the compromised HMI (use another HMI as a backup)

Phase 4 - Forensics (OT-friendly):
  → Prefer passive forensics: network capture
  → PLC memory dump: manufacturer-specific tools (not standard IT tools!)
  → PLC backup and status assessment: Ladder Logic, Inputs/Outputs
  → PCAP from the time of the incident (if a recorder is available)
  → Volatile PLC data: Memory is very limited and overwritten quickly
  → Timestamps: OT systems often have incorrect system time (no NTP!)
  → Chain of Custody: ISO/IEC 27037 processes

Phase 5 - Recovery:
  □ Check PLC programs for integrity (hash comparison!)
  □ Restore PLC firmware from verified backups
  □ HMI image from golden backup image
  □ Renew safety system certification (if SIS affected!)
  □ Forensics: Back up process history data as evidence
  □ Validate communication matrix: Is everything back to normal?
  □ Intensify monitoring: 30 days of heightened vigilance

Phase 6 - Reporting:
  → KRITIS notification: BSI (24-hour early warning in case of a significant incident)
  → Insurance documentation
  → Lessons Learned: Close security gap

Regulatory Requirements

NIS2 obligations for OT operators:

Who is affected (NIS2 / BSIG §2):
  → Energy supply (electricity, gas, oil, district heating)
  → Water/sewage
  → Digital infrastructure (data centers, cloud, CDN)
  → Healthcare (hospitals, laboratories)
  → Transportation (Rail, Air, Sea, Road)
  → Finance (Credit Institutions, Market Infrastructure)
  → Public Administration
  → OT Systems explicitly within the NIS2 scope!

Key requirements of NIS2 Art. 21:
  □ Risk analysis and security policies (Section 6 BSIG)
  □ Incident handling and business continuity
  □ Supply chain security (suppliers!)
  □ Assessment of the effectiveness of security measures
  □ Access control, asset management, MFA
  □ Cryptography and encryption

Reporting obligations (BSIG §30, according to BSI reporting office):
  → Early warning: 24 hours after becoming aware (significant incident)
  → Initial report: 72 hours (nature, extent, impact)
  → Final report: 1 month (complete analysis, measures)

BSI IT-Grundschutz modules for ICS:
  IND.1:  General ICS
  IND.2.1: Programmable Logic Controller (PLC)
  IND.2.2: Siemens S7 Programmable Logic Controller
  IND.2.3: Sensors and Actuators
  NET.3:  Routers and Switches (including OT segments)

NIST SP 800-82 Rev. 3 (2023):
  → U.S. guidelines for ICS security (free)
  → Very practical: specific recommendations for each OT technology

Checklist of critical OT measures:
  □ Network segmentation: IT and OT strictly separated
  □ Purdue model implemented: communication directions enforced
  □ Asset inventory: all OT components recorded
  □ Remote access: MFA + session recording + JIT access
  □ Backup PLC programs: backed up by version, tested regularly
  □ Patch management: process defined, risk analysis per patch
  □ Anomaly detection: Nozomi or Claroty or Defender for IoT
  □ IR plan: OT-specific playbooks, vendor contacts
  □ Vendor management: Access reviews, contractual security requirements
  □ Training: OT operators made aware of social engineering and phishing