:PROPERTIES: :ID: 3e1fc0f3-6bc2-43ab-95bf-b32118f37e9e :END: #+title: ot-ics-security-ramp/glossary #+filetags: :project: :knowledge: :cybersecurity: :glossary: Running, quiz-ready glossary built up during Aner's cybersecurity terminology ramp-up (see [[ot-ics-security-ramp/curriculum]] for the study plan/methodology this supports). Term → one-line definition. Updated automatically as new terms are covered in session, no need to ask first. ** General Attack/Defense Vocabulary - RAT (Remote Access Trojan) — malware giving an attacker remote hands-on-keyboard control of a victim machine. - C2 (Command & Control) — the infrastructure/server an attacker uses to control compromised machines and receive stolen data. Distinguish from **C2 payload/C2 traffic**: the actual encoded command or data moving across that channel at a given moment — "C2" names the infrastructure, "C2 payload" names a specific piece of data on it. - Web shell — malicious code (often a small script like PHP) dropped directly onto a compromised web server, giving the attacker remote command execution through the web server's own HTTP interface. Distinct from a RAT: no separate persistent connection needed, the "channel" is just HTTP requests to the already-compromised server. Header-based C2 smuggling (e.g. WHIPSHOT, a 2026-observed PHP web shell) hides Base64-encoded command/response data inside HTTP header values instead of the body/URL, since headers get less scrutiny from most traffic-inspection tools. - IOC (Indicator of Compromise) — forensic evidence something already happened (bad hash, known-bad IP, dropped file). Reactive. - IOA (Indicator of Attack) — behavioral signal an attack is happening right now, regardless of the specific malware (e.g. PowerShell spawned with an encoded command). Proactive/technique-based. - Kill chain — the staged sequence of an attack (recon → exploit → install/persist → escalate privileges → move laterally → achieve objective). - MITRE ATT&CK — a public catalogue/matrix of real-world adversary tactics and techniques, organized by attack-lifecycle stage; the industry's shared reference vocabulary for describing attacker behavior. - Lateral movement — moving from an initially compromised host to other hosts within the network. - Pivoting / SSH tunneling — using an already-compromised, dual-homed host as a relay to reach a network it can see but the attacker otherwise couldn't. Practically done via SSH port forwarding: `-L` forwards one local port to one specific internal target through the existing SSH session; `-D` opens a local SOCKS proxy so any tool's traffic gets relayed through that session. Chaining several compromised hosts this way (device A tunnels into network B, from which device C tunnels into network D...) is how a single credential compromise on the edge can reach deep into an otherwise-segmented internal network — the actual mechanism behind lateral movement, not just the goal. - Living-off-the-land (LOTL) — using legitimate built-in OS tools (PowerShell, WMI, psexec) to carry out an attack instead of custom malware, to blend in and evade detection. - Exfiltration — the act of stealing data out of a compromised network. - Ransomware-as-a-Service (RaaS) — a ransomware operator provides the toolkit/infrastructure; affiliates carry out the actual intrusion and split the ransom revenue. - Supply chain attack — compromising a trusted vendor/software update mechanism to reach that vendor's downstream customers. - Zero-day — a vulnerability with no available patch (attacker often first to know). N-day — a known, patched vulnerability that's still exploitable wherever the patch hasn't been applied yet. - APT (Advanced Persistent Threat) — a well-resourced, often nation-state-linked attacker group focused on long-term, stealthy access rather than smash-and-grab. - TTP (Tactics, Techniques, and Procedures) — the standard way of describing *how* a specific threat actor operates, at three levels of specificity (tactic = goal, technique = general method, procedure = exact implementation). This is the language MITRE ATT&CK is built around. - WAF (Web Application Firewall) — inspects/filters HTTP(S) requests against rules to block web-layer attacks. - Sandboxing — running untrusted code in an isolated environment so it can't affect the surrounding system. - Zero trust — never implicitly trust a device/user, even inside the "internal" network; always authenticate and authorize. - SSO (Single Sign-On) — one login session grants access across multiple systems. - MFA (Multi-Factor Authentication) — requiring more than one proof of identity to authenticate. - SAML/OAuth — protocols for delegated authentication: a trusted identity source issues a token after authenticating the user, and that token is what other systems check instead of re-authenticating. - Kerberoasting — requesting a Kerberos service ticket for a service account (any authenticated user can do this, no alert triggered), then cracking it offline to recover that account's password hash. - CVE (Common Vulnerabilities and Exposures) — the standard ID assigned to a specific known vulnerability. - CVSS (Common Vulnerability Scoring System) — the standard severity score (0-10) for a CVE. - Red team / Blue team / Purple team — red = offense, simulates real attackers; blue = defense, detection & response; purple = collaboration between the two to improve detection. - Pentest vs. vulnerability scan — a vuln scan is automated, passive, matches known signatures/CVEs; a pentest is human-driven, actively attempts real exploitation/chaining to validate actual risk. - Port scanning — probing a range of IPs on a set of TCP/UDP ports to see which are open, as a quick way to fingerprint what services/devices are present without yet having to speak each protocol correctly (e.g. nmap). A scan that starts at a specific, already-known-valuable IP suggests prior reconnaissance; a scan hitting every address in a range sequentially suggests an untargeted automated sweep. - Shodan — a search engine that continuously scans the entire public internet and indexes what it finds on open ports (banners, service metadata, sometimes screenshots), searchable by service type, port, geography, or organization. Unlike Google (indexes web page content), Shodan indexes *devices/services themselves* — webcams, routers, databases, and notoriously, internet-exposed ICS/SCADA devices (PLCs, HMIs) that were never meant to be reachable from the public internet. The standard first move in OT recon/research for finding exposed ICS protocols (Modbus/502, S7/102, DNP3/20000) in the wild — and the reason "don't scan real internet-facing ICS, keep it in your own lab" is a real ethical/legal line, not just caution for its own sake. - CNA (CVE Numbering Authority) — an organization authorized to mint CVE IDs for a defined scope (its own products, a coordinator role, etc.). Most CVEs today are assigned by vendor CNAs or bug-bounty-platform CNAs (HackerOne, Bugcrowd), not by MITRE directly. - CNA-LR (CNA of Last Resort) — MITRE's role: assigns CVE IDs via a request form when no vendor/coordinator CNA covers the affected product. Slower than going through a dedicated CNA. - CERT/CC (CERT Coordination Center, Carnegie Mellon) — a third-party coordinator CNA, useful when a vendor is unresponsive, has no security contact, or an issue spans multiple vendors. - CSIRT (Computer Security Incident Response Team) — generic term for an organizational incident-response team; CERT Polska carries out this function at Poland's national level (as "CSIRT NASK"). - PSIRT (Product Security Incident Response Team) — a vendor's internal team handling vulnerability reports and incident support for its own products; e.g. Siemens calls theirs "ProductCERT". - Coordinated disclosure — reporting a vulnerability privately to the affected vendor first (rather than publishing immediately), giving them time to patch before any public CVE/details are released; the norm the whole CVE submission process assumes. - CWE (Common Weakness Enumeration) — the taxonomy of vulnerability *types* (e.g. "CWE-79: Cross-Site Scripting"). A CVE identifies one specific instance of a flaw in a specific product; CWE classifies what *kind* of flaw it is. - NVD (National Vulnerability Database) — NIST's database that enriches published CVEs with a CVSS score and structured metadata after a CNA assigns the ID. ** OT/ICS Fundamentals - IT vs OT priority — IT security follows Confidentiality→Integrity→Availability (CIA); OT security flips it to Availability→Integrity→Confidentiality (AIC), because OT systems control physical processes where downtime/instability can cause physical harm. - ICS (Industrial Control Systems) — umbrella term for equipment/software controlling physical industrial processes (PLCs, RTUs, HMIs, SCADA, DCS). - SCADA (Supervisory Control and Data Acquisition) — a type of ICS focused on supervising geographically distributed systems (e.g. a utility grid or pipeline). - DCS (Distributed Control System) — a type of ICS typically used within a single plant/site rather than spread over distance. - PLC (Programmable Logic Controller) / RTU (Remote Terminal Unit) — the field-level controllers that read sensors and drive actuators in tight, fast loops (Purdue Level 1). - HMI (Human-Machine Interface) — the operator-facing dashboard/screen showing live process data (Purdue Level 2). - Historian — a database logging sensor/process data over time, typically at Purdue Level 3. - Purdue Model — reference architecture mapping OT/IT network layers, Level 0 (physical sensors/actuators) up to Level 5 (corporate/enterprise); the IT/OT security boundary is conventionally drawn around Level 3/3.5. - Level 3.5 / DMZ — the firewalled buffer zone mediating any traffic between OT (Levels 0-3) and IT (Levels 4-5); the main real-world security boundary in practice. - Air-gapped — historically meant zero physical connectivity between OT and IT; in practice today almost nothing is truly air-gapped, so security work focuses on controlling the Level 3.5 boundary instead. - Passive monitoring — watching a copy of network traffic (via a tap/span port) rather than actively scanning/injecting packets, because active scans can crash fragile field devices never built to handle unexpected input. - SNMP (Simple Network Management Protocol) — general network-device management protocol (not ICS-native, but ubiquitous on the network infrastructure — switches, routers, firewalls, UPSs — surrounding OT, and sometimes on OT devices themselves). Manager/agent model: manager polls or configures an agent via GET/SET; agents can also proactively push a TRAP (e.g. "interface down") without being polled. UDP 161 (agent)/162 (trap). v1/v2c auth is a single plaintext "community string" sent in every request and directly comparable to a password check — no real security, and a successful GET/SET with the default `public`/`private` string can both enumerate a full device inventory and alter live configuration. SNMPv3 adds real user-based authentication and optional encryption, but — same brownfield pattern as DNP3-SA/Modbus Security — is often left disabled. See [[ot-ics-security-ramp/reading-list]] for the NSA/CISA SNMP abuse advisory, including the Russian FSB Center 16 campaign that exfiltrated critical-infrastructure router configs via SNMP. - MIB (Management Information Base) / OID (Object Identifier) — SNMP's data model: a standardized hierarchical tree (defined in ASN.1/SMI) of every manageable variable a device exposes, addressed by an OID (a dotted numeric path from root to leaf, e.g. `1.3.6.1.2.1.1.1.0` = sysDescr). MIB-II is the standard baseline branch nearly every SNMP device implements (interfaces, uptime, routing table); vendors extend into a reserved private-enterprise branch (`1.3.6.1.4.1....`) for proprietary variables. A "MIB walk" (enumerating every OID under a branch) is why read-only SNMP alone is a reconnaissance goldmine — one walk against MIB-II returns a device's full interface/routing/system inventory with no vendor-specific knowledge required. Mechanically, a walk isn't "ask the root for its children" — SNMP has no such operation. It's iterative: `GetNextRequest` returns the next OID in strict lexicographic order after the one you supply, so a walk loops GetNext → take the returned OID → GetNext again, until the result falls outside the starting branch (`GetBulkRequest` in v2c/v3 batches several "next" steps per round trip instead of one at a time). Every call still requires valid auth (community string in v1/v2c) — a walk succeeding against weak/default credentials isn't an auth bypass, it's auth trivially satisfied. A device's MIB only describes *itself* (its own interfaces/CPU/routing table), not devices it merely forwards traffic for — except via neighbor-discovery branches like Cisco's CDP-MIB or the vendor-neutral LLDP-MIB, which let a device report what's directly connected to each of its own ports, the closest SNMP gets to mapping adjacent devices one hop at a time. - ACL (Access Control List) — a rule set on a device/network boundary (router, switch, firewall) specifying which source addresses/ports/protocols may reach a given service. Not a per-protocol auth mechanism itself — it operates at the network layer, restricting *who can even attempt* a request (e.g. restricting which hosts may query a device's SNMP agent at all) independent of whatever credential/auth check the service itself performs. A common compensating control for protocols with weak native auth (SNMP, Modbus, DNP3): even if the protocol-level security is trivial to satisfy, an ACL can still block the request from ever arriving if the source isn't on the allowed list. - Modbus — the oldest/most universal ICS protocol (1979, Modicon); originally serial (RTU/ASCII), later Modbus TCP (port 502). Master/slave (client/server) request-response only, addressing four flat tables (coils, discrete inputs, holding registers, input registers) via function codes (FC01 read coils, FC03 read holding registers, FC05/FC06/FC16 writes). No authentication, no encryption, no sender-identity check — any client reaching port 502 can issue any function code; the canonical example of "ICS protocols have no security by design." Modbus Security (TLS retrofit, ~2018) exists but is rarely enabled in the field, same adoption story as DNP3-SA. - Modbus Plus (Modbus+) — a separate, proprietary Schneider Electric/Modicon network protocol, not the same wire format as standard Modbus RTU/ASCII/TCP. Token-passing (not master-slave) so multiple PLCs can initiate as peers; 1 Mbps over shielded twisted-pair with deterministic timing, proprietary HDLC-derived data link layer incompatible with standard Modbus framing (needs a bridge/gateway to talk to it). Mostly legacy now, superseded by Modbus TCP/IP. Same no-auth/no-encryption weakness as standard Modbus, just rarer in the wild so less commonly targeted/tooled-for. - Compensating controls / defense-in-depth — when a weakness can't be fixed at its source (e.g. an inherently insecure field protocol), layer protections around it instead (network segmentation, monitoring, access control). The practical justification for the Purdue Level 3.5 DMZ: Modbus/DNP3/GOOSE can't be secured on their own, so security gets pushed to the perimeter/network layer instead. - Brownfield vs. greenfield — brownfield = existing legacy installed equipment (the overwhelming majority of OT/ICS, often running protocols/hardware decades old); greenfield = new builds designed from scratch. OT field devices commonly have 20-30 year lifecycles, so replacing a protocol in the field usually means replacing working hardware, not just patching software — a major reason insecure legacy protocols persist. - DNP3 (Distributed Network Protocol) — dominant protocol for North American electric/water utility master-station-to-RTU communication. Richer than Modbus: object-based data types with built-in semantics (Binary/Analog Input/Output, Counters) rather than anonymous flat registers, plus unsolicited reporting (an outstation can push event-driven updates without being polled — useful over slow serial/radio links, but an extra unauthenticated inbound-trigger surface). Originally serial (Data Link Layer framing + per-block CRC → Transport Function reassembly → Application Layer data); DNP3 over TCP (port 20000) tunnels that same serial-era framing inside TCP rather than replacing it the way Modbus-TCP's MBAP header does. - DNP3-SA (Secure Authentication, IEEE 1815) — optional auth extension, rarely enabled in practice. Only protects *critical* function codes (control/operate/config-change), not routine polls/reads, as a deliberate latency tradeoff. Uses HMAC-based challenge-response rather than a static shared secret (like SNMP's community string, sent in cleartext and directly replayable): outstation sends a random nonce Challenge, master replies with an HMAC of that nonce under a pre-shared session key (the key itself never crosses the wire), outstation verifies by recomputing the same HMAC — a sniffed Challenge/Reply pair is useless for a different operation. Session keys rotate via a separate key-update exchange from longer-lived per-user-role "update keys," giving per-operator accountability a static secret can't. Full challenge-response costs a round trip per critical command, which is real overhead over slow serial/radio links — "Aggressive Mode" exists to cut that round trip by having the master proactively attach its HMAC without waiting for a fresh challenge, but formal analysis (Cremers et al. 2019; Coloured Petri Net modeling) found this reintroduces a replay flaw: a captured Aggressive Mode message can be replayed to execute reads/writes/application launches on the outstation without ever possessing the session key. Net effect: real deployment of DNP3-SA remains limited by both legacy device constraints and genuine real-time-latency requirements, so most operational DNP3 traffic today is still plaintext. - IEC 61850 — modern substation automation standard for electric utilities; includes GOOSE messages. - GOOSE (Generic Object Oriented Substation Event) — publish-subscribe (not request-response) protection-relay messaging requiring single-digit-millisecond delivery, with essentially no authentication due to the speed requirement; a known attack surface (used in the 2016 Ukraine grid attack, Industroyer malware). Runs directly on raw Ethernet Layer 2 (EtherType 0x88B8) to a reserved multicast MAC range (01-0C-CD-01-xx-xx) — no IP, no TCP/UDP, so ordinary L3 routers can't route it (nothing to route on) though ordinary L2 switches handle it fine, just flooding to every port on the VLAN (no IGMP-style group pruning, since that's IP-layer). Reliability comes from repetition, not acknowledgment: publisher retransmits the same state at a fast-then-slowing interval; a State Number (stNum, increments only on real state changes) plus Sequence Number (sqNum, increments per retransmission) is what Industroyer forged — crafting a higher stNum than the legitimate relay to make a spoofed "breaker open" look like the newest valid state. All publish/subscribe wiring (which multicast address/dataset maps to which relay) is statically pre-engineered in a Substation Configuration Description (SCD) file loaded onto each IED at commissioning time, not negotiated at runtime — so once an attacker has that config (via traffic capture or a leaked SCD file), forged frames work indefinitely, no handshake to invalidate them. - IEC 62351-6 — the security extension for GOOSE/Sampled Values/MMS, adding a digital signature for authentication/integrity (not encryption — confidentiality isn't the goal on an assumed-physically-secured substation LAN). Low real-world adoption, and not just from brownfield inertia like Modbus/DNP3-SA: the original RSA-signature scheme is often too slow for the sub-4ms timing budget on older relay hardware, a genuine unresolved engineering tension rather than pure organizational inertia; later proposals shift to faster symmetric-key MAC schemes to try to fit the budget. - PRP / HSR (Parallel Redundancy Protocol / High-availability Seamless Redundancy, IEC 62439) — substation network resilience standards that send duplicate frames over two independent physical paths simultaneously, giving zero-recovery-time failover if one link/switch dies. Distinct from GOOSE's own retransmission-based reliability, which only covers random packet loss, not a dead physical path. - Process bus / station bus — the dedicated, VLAN-segmented (sometimes physically separate) Ethernet network a substation runs GOOSE/Sampled Values on, kept apart from general SCADA/IT traffic for two reasons: (1) latency contention — ordinary traffic queuing ahead of a time-critical trip message, (2) security — Ethernet doesn't distinguish IP packets from GOOSE frames on the wire, so any compromised host sharing that L2 segment can craft and inject raw GOOSE frames directly (exactly what Industroyer did), with no "GOOSE-specific access" required. Segmentation here is the control meant to keep an IP-side compromise from ever reaching that segment — in budget-constrained or poorly-designed substations this isolation is sometimes incomplete, a real rather than theoretical risk. - IEC 60870-5-104 ("IEC 104") — DNP3's rough equivalent dominant in Europe/Middle East/Asia/Africa (DNP3 dominates North America); if you see TCP port 2404 in a capture, it's almost certainly non-US utility telemetry. The IP-networked version of the older serial IEC 60870-5-101 (104-to-101 is roughly what Modbus-TCP is to Modbus-serial). Master-slave (controlling/controlled station), not pub-sub. Data carried as ASDUs (Application Service Data Units) containing typed Information Objects (Type Identification field marks e.g. single-point info, measured value, command) — gives semantic typing Modbus's flat registers lack, similar in spirit to DNP3's object model. No authentication/encryption/integrity in the base spec, same as Modbus/DNP3-without-SA; IEC 62351-3/5 defines a TLS security retrofit, same low-adoption brownfield story as everything else. - OPC-UA — platform-independent successor to the original OPC (built on Windows-only COM/DCOM, a firewall nightmare); own binary protocol on TCP port 4840 or an HTTPS binding. Unlike field protocols' flat/typed-but-static registers, exposes a genuine object-oriented, self-describing address space (Nodes: variables, methods, types, relationships) a client can browse/discover at runtime. Real built-in security, not retrofitted: X.509 certs for mutual client/server auth, configurable Security Policies (None/Sign/SignAndEncrypt) with a defined cipher-suite-like profile stack (Basic256Sha256 etc.) — though "Security Policy: None" is a valid, sometimes-used setting that defeats all of it. Primary/original use case is horizontal: cross-vendor interoperability between different Level 2/3 systems (SCADA-to-historian, historian-to-MES, HMI-to-SCADA) — solving the "every vendor has a proprietary driver" problem OPC was founded to fix. Increasingly also vertical: Level 2/3 (historian/SCADA) up to Level 4/5 IT/cloud/analytics, crossing the DMZ. At the leading edge, pushed down to the field level too — modern PLCs (Siemens S7-1500, Beckhoff, Rockwell) often ship a native OPC-UA server directly on the controller, and OPC-UA over TSN (Time-Sensitive Networking) is an emerging effort toward real-time field-level use, a long-horizon candidate to someday displace protocols like Modbus or GOOSE. Doesn't retroactively secure the field-level protocols underneath it — it secures the bridge/interop layer it operates at, nothing lower. - OPC UA message types (HEL/ACK/OPN/MSG/CLO) — the four transport-level frames every OPC UA conversation is built from: client sends HEL (Hello, endpoint URL + buffer limits), server replies ACK; OPN (OpenSecureChannel) bootstraps the encrypted channel via asymmetric cert-based crypto (client/server certs + nonces → derived symmetric keys), periodically renewed with a fresh OPN before expiry; all actual application traffic then rides inside MSG chunks under the symmetric keys; CLO tears the channel down. Large MSG payloads split into multiple chunks (Intermediate/Final/Abort) — never sending the Final chunk is the basis of chunk-flooding DoS (CVE-2023-32787, unbounded server-side buffering). - SecureChannel vs. Session (OPC UA) — two deliberately decoupled layers: the SecureChannel (established via OPN) is a transport artifact providing encryption/integrity between two certificate-validated endpoints, with no concept of user identity; the Session (CreateSession + ActivateSession, carrying a UserIdentityToken — Anonymous/UserName-Password/X.509 cert) is the application-level, identity-bound conversation, including its Subscriptions/MonitoredItems state. A Session can outlive a SecureChannel renewal (new keys, same logical conversation) — same relationship as a TLS session ticket outliving an individual TCP connection. - GetEndpoints — unauthenticated-by-design OPC UA discovery call (has to be, since a client can't know what SecurityPolicy to speak until it asks) returning the server's available endpoint URLs, each with its own SecurityPolicy/SecurityMode combination, plus the server's certificate and ApplicationName/ProductURI metadata. Not a secrecy boundary — the real exposure is a server offering/accepting SecurityPolicy "None" or Anonymous auth among the discoverable options, the same pattern behind "over half of internet-exposed OPC UA servers allow unauthenticated access." - Reverse Connect (OPC UA) — role-inversion at the TCP-dial step only: a server behind NAT/no inbound firewall hole initiates the TCP connection outward and sends a ReverseHello, then hands control back so the client still drives the rest of the HEL/OPN/session handshake. Added in UA spec 1.04 for field devices that can't be reached directly. - Subscription / MonitoredItem (OPC UA) — client-server efficiency mechanism layered on Sessions: client registers interest in specific Nodes at a publishing interval; server proactively pushes change Notifications inside Publish responses instead of the client polling Read repeatedly. Distinct from the separate "OPC UA PubSub" transport profile (connectionless UDP/MQTT/AMQP multicast, no Session concept at all). - Zip-slip — a path-traversal vulnerability class in archive-extraction code: a crafted archive entry name containing `../` sequences writes outside the intended extraction directory when naively joined to a base path. Used by Team82 chained with client-side XSS against Softing edgeAggregator to drop a malicious shared-object file into a system library path for root RCE. - WerFault abuse — using Windows' built-in crash-reporting handler (WerFault.exe) as an unwitting code-execution trigger: after planting a malicious DLL (e.g. in System32), deliberately crashing the target process causes WerFault to run in a context that loads the planted DLL. Seen in Team82's Softing Secure Integration Server exploit chain. - Pwn2Own ICS — the ICS-specific track of the Pwn2Own exploit competition (vendor products, cash prizes for working exploit chains); Team82 used their OPC UA exploit framework across three Pwn2Own ICS competitions. - MES (Manufacturing Execution System) — Purdue Level 3 software managing/tracking production on the plant floor in real time (work orders, batch tracking, quality, OEE) — sits between the Historian/SCADA (Level 2/3, process data) and ERP (Level 4, business/planning data). A common OPC-UA peer: SCADA/historian-to-MES and MES-to-ERP are typical OPC-UA interoperability links. - ERP (Enterprise Resource Planning) — Purdue Level 4/5 corporate business software (SAP, Oracle, etc.) covering finance, procurement, supply chain, and production planning; consumes aggregated/summarized production data from MES rather than real-time process data, and does not connect directly down to field-level devices — that hop-by-hop chain (PLC→SCADA→MES→ERP) is what keeps the Level 3.5 DMZ boundary from being bypassed in a single connection. - S7 — Siemens' proprietary ICS protocol for communicating with SIMATIC PLCs (S7-300/1200/1500 etc.), port 102/TCP; like Modbus/DNP3, a frequent target for ICS network scanning. - CODESYS — the IEC 61131-3 engineering/runtime environment (port 11740/TCP) underlying many different vendors' PLCs, including WAGO's — a shared software base means a CODESYS vulnerability can cross vendor lines. - VFD (Variable Frequency Drive) — a device that controls motor speed by varying the frequency/voltage of its power supply; common ICS target (pumps, fans, compressors) alongside PLCs. - CHP (Combined Heat and Power) — a plant that generates electricity and useful heat from the same fuel source (cogeneration); a common critical-infrastructure target since it serves both the grid and district heating. - DER (Distributed Energy Resources) — small-scale generation/storage assets connected to the distribution grid rather than centralized transmission-level generation (e.g. wind, solar, battery storage). - DSO (Distribution System Operator) — the utility entity operating the local distribution grid (as distinct from a Transmission System Operator); DSOs typically run their own private telemetry networks reaching down to substations and RTUs. - GCP (Grid Connection Point) — the point where a generation asset (e.g. a wind farm) connects into the distribution network and its operator. (Not to be confused with the identically-abbreviated Google Cloud Platform.) - Private APN (Access Point Name) — a cellular-carrier-provisioned network, isolated from the public internet, used for machine-to-machine telemetry (e.g. DSO-to-RTU SCADA traffic). Often assumed "safe by isolation," but without client isolation between devices on the APN, one compromised device can reach every other device on it — treat it as untrusted as the public internet toward OT. ** OT/ICS Hands-On Lab Tools Covered 2026-10-05 in response to "how do I build a fake OT network to play with" — see [[ot-ics-security-ramp/curriculum]] for progress tracking. - pymodbus — Python library implementing a full Modbus TCP/RTU client and server; fastest way to stand up a fake "PLC" (a Modbus server with custom registers) in a few lines and point nmap/Wireshark at it. - opendnp3 — open-source C++ DNP3 protocol stack (with Python bindings) for simulating a DNP3 master or outstation (DNP3's term for the field-device side); the DNP3 equivalent of pymodbus. - OpenPLC — open-source IEC 61131-3 soft-PLC runtime: a real PLC, not just a protocol stub. Runs real ladder logic/structured text and serves it over genuine Modbus and DNP3 slave interfaces. Dockerized/Raspberry-Pi friendly; the accepted standard open-source PLC for ICS security training and CTFs. - GRFICS (Graphical Realism Framework for Industrial Control Simulations) — Georgia Tech project providing a full prebuilt virtual plant (simulated chemical process + HMI + PLC logic + documented attack scenarios) as VMs, built explicitly for cybersecurity teaching/research. Closest thing to an "accepted standard" fake OT environment to attack. - Conpot — low-interaction ICS honeypot, defaults to impersonating a Siemens S7-300 PLC; speaks Modbus, S7comm, BACnet, SNMP, HTTP simultaneously. Good for observing what scanning/exploitation traffic looks like against a fake device; not meant for realistic control logic. - T-Pot — docker-compose bundle of Conpot plus a dozen other honeypots (IT + OT), with a Kibana dashboard of all captured attack traffic. Useful for the "SOC watching attacks land" view rather than the device-builder view. - MiniCPS — Mininet-based (network namespaces + virtual Ethernet, not Docker containers) framework for simulating ICS networks at scale; topology and PLC devices defined in real Python (Mininet Topo subclass; PLC subclass with pre_loop()/main_loop()), not a config file. Ships the actual SWaT (Secure Water Treatment) testbed scenario alongside a minimal toy example — most academically credentialed of the open-source ICS simulators. No bundled attacker/traffic-observer tooling; MIT licensed, actively maintained. Chosen (2026-10-06) as the foundation for the planned network-simulator project specifically for its lightweight namespace-based scaling over Docker-per-device isolation — see [[ot-ics-security-ramp/network-simulator-blueprint]] for the full comparison against ICSSIM/ICS-SimLab. - ScadaBR — open-source HMI/SCADA software, commonly paired with OpenPLC to get a realistic-looking operator dashboard on top of real PLC logic. ** OT Attack Case Studies - Stuxnet (2010) — malware delivered via USB to Iran's Natanz facility, targeted Siemens PLCs to physically destroy uranium centrifuges by subtly altering their speed, while feeding operators falsified "everything normal" readings. Canonical example of an OT *integrity* attack — not data theft, not an obvious outage, just making the physical process do the wrong thing while lying to the humans monitoring it. Widely attributed to a US/Israel joint operation, never officially confirmed. - Ukraine grid attacks (2015, 2016) — first confirmed cyberattacks to cause a power outage. 2015: Sandworm (Russian GRU-linked) phished into utility IT, pivoted to OT, manually opened substation breakers via SCADA HMI (~230,000 people lost power). 2016: follow-up used Industroyer malware, the first malware built to natively speak ICS protocols (including IEC 61850 GOOSE) to automate breaker control at scale instead of manual HMI clicks. - TRITON / TRISIS (2017) — targeted a Saudi petrochemical plant's Safety Instrumented System (SIS) — the independent emergency-shutdown layer that exists to prevent physical catastrophe (explosion, toxic release). Reprogrammed Schneider Electric SIS controllers; a bug in the attacker's own code accidentally triggered a shutdown, likely preventing serious harm. The case study proving OT attacks carry real physical/safety risk, not just theoretical danger. - SIS (Safety Instrumented System) — an independent hardware/software layer that triggers automatic emergency shutdown if a process becomes physically dangerous, separate from the normal control system. - FrostyGoop (2024) — malware that injected Modbus TCP commands directly against district-heating ICS controllers in Ukraine, disabling heating to apartment buildings during winter; notable as a protocol-native attack requiring no exploit, just valid-looking Modbus writes to the right registers (same "no authentication to distinguish attacker from legitimate master" pattern as the 2015 Ukraine grid breaker attack). Predecessor VPNFilter (2018) only sniffed/exfiltrated Modbus TCP traffic rather than injecting commands. - Metcalf sniper attack (2013) — attackers shot up a PG&E transmission substation in California, knocking out 17 transformers. Physical, not cyber, but the case study behind NERC CIP-014 (mandating physical security planning for critical substations) — cited to make the point that critical-infrastructure risk isn't purely digital. - Private-APN CHP plant incident (Poland, 29 Dec 2025; CERT Polska follow-up report) — attacker pivoted from a compromised wind-farm FortiGate VPN/firewall, through a Teltonika cellular router's SSH tunnel, across a DSO private APN lacking client isolation, into a WAGO PFC200 gateway PLC reachable via default web-admin credentials, then via a further SSH tunnel into an unrelated CHP plant's OT network — stopping Siemens S7-300/1200/1500 PLCs and shutting down a steam turbine and water treatment system. First known real-world attack to use a private APN as a lateral-movement path between otherwise-unconnected facilities; the attacker also destroyed the WAGO device's partition table as anti-forensics. ** OT Vendor Landscape - Dragos — pure-play OT threat detection & intel vendor; known for naming/tracking specific ICS-targeting threat groups (e.g. XENOTIME, linked to TRITON), similar to how CrowdStrike names IT-side APT groups. - Claroty — pure-play OT asset visibility + exposure/vulnerability management; also strong in healthcare device security under the term "xIoT" (extended IoT — medical devices, building systems, etc. alongside classic ICS). - Nozomi Networks — pure-play OT asset visibility + passive network threat detection; notable distribution partnership with Palo Alto Networks. - Dragos/Claroty/Nozomi are referred to as the OT security "big three" — all compete on roughly the same product shape: passive network monitoring → asset inventory → anomaly/threat detection → vulnerability/exposure management. - Tenable.ot — Tenable's OT product (from acquiring Indegy), bundled with their IT vulnerability-management business. - Microsoft Defender for IoT — Microsoft's OT offering (from acquiring CyberX). - Forescout / Armis — broader IT/OT/IoT device-visibility vendors with Network Access Control (NAC) roots, less ICS-protocol-specialized than the big three. - Vendor-native OT security — control-system manufacturers (Siemens, Schneider Electric, Honeywell) selling their own security add-ons for their own equipment. ** 2026 OT Threat Landscape & Supply-Chain Targets (from the Dragos 2026 OT Cybersecurity Year in Review — see [[ot-ics-security-ramp/reading-list]]) - KAMACITE, SYLVANITE, BAUXITE — named OT-targeting threat groups tracked by Dragos as active in 2026; BAUXITE notably deployed wiper malware alongside hacktivist messaging campaigns. - MSP (Managed Service Provider) — a third party remotely managing IT/OT infrastructure (patching, monitoring, help desk) for multiple clients. A high-value supply-chain target because compromising one MSP can grant privileged access into all of its downstream clients at once (cf. the Kaseya ransomware incident). - GIS (Geographic Information System) — software mapping/managing geospatial data. For utilities, GIS holds the physical topology (which pole feeds which transformer, pipeline routing, substation locations) — a reconnaissance goldmine for an attacker trying to map control loops and physical dependencies, which the 2026 Dragos report flagged as a rising adversary behavior. - Engineering firms, system integrators, vendors, MSPs, and GIS providers are collectively the "trusted access periphery" around a utility — 2026 attacker focus has shifted toward this periphery rather than the utility's own network directly, since these firms hold privileged access or critical mapping data across multiple client environments. ** Compliance / Frameworks - NERC (North American Electric Reliability Corporation) — the organization overseeing bulk power system reliability across North America. - NERC CIP (Critical Infrastructure Protection) — NERC's mandatory, legally-enforced cybersecurity standards for the electric grid; not a voluntary best-practice framework like NIST CSF. Overseen/enforced by FERC, with fines up to $1M+/day per violation. - FERC (Federal Energy Regulatory Commission) — the US federal regulator that oversees and enforces NERC standards. - BES (Bulk Electric System) — the scope of NERC CIP: roughly the high-voltage transmission-level grid (generally 100kV+), not every piece of electric infrastructure. Small distribution-only utilities may fall outside CIP scope. - NERC CIP is electric-sector only — water utilities fall under EPA/AWIA requirements instead, and gas pipelines under TSA security directives, not NERC CIP. - CIP-002 — categorize BES Cyber Systems by impact (High/Medium/Low); the mandatory starting point for all other CIP standards. - CIP-005 — Electronic Security Perimeter (ESP): the legal/compliance formalization of the Purdue Level-3.5 segmentation boundary. - CIP-007 — system security management (patching, ports/services hardening), with the OT-specific tension that you can't patch live field devices the way you'd patch a laptop. - CIP-008 — incident reporting and response planning requirements. - CIP-010 — configuration change management and vulnerability assessments. - CIP-013 — supply chain risk management (added ~2020): the standard legally requiring utilities to vet third-party/vendor/MSP access — directly related to the MSP/GIS supply-chain targeting trend above. - CIP-014 — physical security requirements for critical substations, added in response to the 2013 Metcalf sniper attack. ** Networking / Crypto Primitives - TLS (Transport Layer Security) — the standard encryption/authentication protocol behind HTTPS; assumes a reliable, ordered, connection-based transport (TCP). - DTLS (Datagram Transport Layer Security) — TLS adapted to run over UDP instead of TCP, adding handshake retransmission and tolerance for packet loss/reordering/duplication since UDP gives none of that natively. Used wherever "HTTPS-grade" security is needed over a latency-sensitive, connectionless channel — VPN tunnel modes (e.g. Cisco AnyConnect), WebRTC, CoAP for constrained/IoT devices. Most classic field-level ICS protocols (Modbus, DNP3, GOOSE) predate DTLS and don't use it natively. - VLAN (Virtual Local Area Network) — a logical, software-defined subdivision of a physical network, used to segment traffic without separate physical cabling; segmentation by VLAN alone doesn't stop an attacker who already has administrative access to a device that bridges multiple VLANs. - SSH (Secure Shell) — encrypted remote shell/administration protocol; also commonly abused for tunneling (forwarding arbitrary traffic through an encrypted SSH session) to pivot across network boundaries. - RDP (Remote Desktop Protocol) — Microsoft's protocol for remote GUI access to Windows machines; a frequent lateral-movement and credential-brute-force target. - VNC (Virtual Network Computing) — a platform-independent remote-desktop protocol; like RDP, a common target for credential-guessing during network reconnaissance. - RTSP (Real Time Streaming Protocol) — protocol for controlling streaming media sessions, commonly used by IP video-surveillance/CCTV systems. - Client isolation — a network configuration that prevents devices on the same subnet/segment (e.g. the same private APN or Wi-Fi AP) from communicating directly with each other, typically restricting them to talk only to a gateway. Its absence was the root misconfiguration that let an attacker pivot across devices sharing a DSO private APN in the CERT Polska December 2025 incident. - VPN concentrator — a dedicated device (often combined with a firewall) built to terminate and manage many simultaneous VPN tunnels at once, from many remote clients/sites, as opposed to being a single tunnel's endpoint like client VPN software. A single compromised concentrator can expose every site/segment it serves — as with the FortiGate device in the CERT Polska December 2025 incident. - ICT (Information and Communication Technology) — a broader-scope synonym for "IT," more common in European/telecom/utility usage, covering computing and communications infrastructure together. In utility contexts, "the DSO's ICT network" means the DSO's own IT/corporate-side systems, as distinct from the OT side (RTUs, field devices) — functionally the same split the Purdue Level 3.5 DMZ formalizes. ** IR / Forensics Covered 2026-10-12 — see [[ot-ics-security-ramp/curriculum]] for session notes. - NIST SP 800-61 IR lifecycle — 4 phases: Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity. - SANS PICERL — 6-phase equivalent of the same lifecycle, finer-grained: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned. Same substance as NIST 800-61, just splits phases differently for reporting granularity. - Triage — first-pass judgment on a security alert: real or noise, and how severe. Precedes scoping. - Scoping — determining how far an incident has actually spread (which hosts/accounts/segments are touched) by reconstructing a timeline against the kill chain. - SIEM (Security Information and Event Management) — centralized platform correlating log events from many sources against rules to generate alerts; the main source of IT detection output feeding into triage. - EDR (Endpoint Detection and Response) — agent-based endpoint monitoring that flags suspicious process behavior on a host; the backbone of IT detection, but generally can't be installed on OT field devices (PLC/RTU) since they have no general-purpose OS or spare resources for a third-party agent — a core reason OT detection leans on passive network monitoring instead (see Dragos/Claroty/Nozomi in OT Vendor Landscape). - IDS / IPS (Intrusion Detection / Prevention System) — network-traffic monitoring matching against known-bad signatures; IDS alerts only, IPS can actively block. - Containment: short-term vs. long-term — short-term is an immediate stopgap (firewall block, disable an account, VLAN move) to stop spread right now; long-term is the more thorough fix done once stable (rebuild, patch, rotate every touched credential). - Containment: isolate vs. monitor-in-place — isolating a compromised host immediately stops further damage but tips off the attacker (who may escalate or destroy evidence); monitoring quietly gathers more intel on the attacker's full objective at the cost of letting them keep acting. - DNS sinkholing — redirecting a known-malicious domain (e.g. a C2 domain) to a controlled server instead of its real destination, as a containment action that can be done covertly without alerting the attacker. - OT containment constraint — abruptly isolating/shutting down a live industrial process can itself cause physical harm (overpressure, overheating, mechanical damage), so touching the actual process requires joint sign-off from plant operations/safety engineers, not unilateral cyber-IR action; network-layer containment (segmenting at the Level 3.5 DMZ) is preferred over touching the field device directly. TRITON/TRISIS is the cautionary case: it targeted the SIS itself, meaning you can't always assume your own safety-shutdown layer is trustworthy during an incident. - Chain of custody — the documented, unbroken record of who handled a piece of evidence, when, and how; required for legal admissibility. A gap lets anyone challenge the evidence as tampered. - Forensic imaging — a bit-for-bit copy of storage media (captures deleted/unallocated space, not just visible files), taken via a write blocker so the original is never touched; a cryptographic hash (MD5/SHA) before and after proves the original wasn't altered. - Order of volatility (RFC 3227) — the sequence for what to collect first because it disappears fastest: CPU registers/cache → RAM/process state → network connections/routing tables → running processes → disk → remote logs → physical config/topology → archival backups. - Live vs. dead-box forensics — live forensics captures volatile state (memory, connections, processes) before touching power, at the risk of your own tooling altering system state; dead-box forensics images an already-powered-off disk cleanly, but everything volatile is already gone unless captured first. - Memory forensics / acquisition — dumping RAM to capture a snapshot of everything active (processes, connections, loaded modules, injected code, sometimes credentials/keys); the main way to catch fileless malware or living-off-the-land activity that leaves little/no disk trace, since it still has to execute somewhere. Acquisition needs either a privileged kernel driver on the box (WinPmem/Magnet RAM Capture/FTK Imager on Windows; LiME or avml as a loadable kernel module on Linux) or access from outside the OS entirely (hypervisor-level snapshot of a VM, which sidesteps guest-OS hardening completely). Modern hardening (Windows HVCI/VBS + driver-signature enforcement, Linux Lockdown LSM + CONFIG_STRICT_DEVMEM) specifically blocks this same primitive since it's also what a kernel-level rootkit wants — real IR practice relies on pre-positioned, already-signed/trusted acquisition tooling deployed before an incident (Preparation phase), not improvising mid-incident on a hardened box. - /proc/kcore — a Linux virtual file exposing the kernel's view of physical memory as a (sparse) ELF core file, root-only (mode 0400) by default, readable without loading a new kernel module (lower footprint than LiME). Reported file size (~128 TiB) is the full kernel virtual address space, not real RAM — the ELF header's e_phoff/e_phnum fields point to a Program Header Table listing the actual PT_LOAD segments (contiguous ranges backed by real RAM); real tools read only those ranges rather than the sparse whole. Separate from kptr_restrict (hides raw kernel pointer values from /proc/kallsyms for non-root — a narrower, different protection) and the Lockdown LSM (/sys/kernel/security/lockdown; a stronger, kernel-wide restriction that can block kcore access even for root when active). - Volatility — the standard open-source framework for analyzing a raw memory dump offline (process lists, network connections, injected/unbacked code) without needing the original OS running. - Timeline analysis — correlating MACB timestamps (Modified/Accessed/Changed/Born) across many files and logs to reconstruct a single chronological narrative of what happened when. - File carving — recovering files from unallocated/raw disk space by recognizing file-type signatures (magic bytes) directly in the byte stream, with no file-system metadata to rely on. - Slack space — leftover data in the unused tail of a disk block allocated to a smaller file; can retain fragments of older, otherwise-deleted content. - Persistence artifacts — disk-side evidence of how an attacker maintains access across reboots: registry run keys, scheduled tasks, services, startup folders. The concrete artifacts behind the IOC/IOA concepts. - PCAP (full packet capture) — complete, byte-for-byte network traffic capture; highest fidelity (can reconstruct exact payloads/streams) but too expensive to retain everywhere, always, at scale. - NetFlow / IPFIX — metadata-only flow records (five-tuple + byte/packet counts + timestamps), orders of magnitude cheaper than PCAP; the usual continuous baseline, with full PCAP triggered selectively once something looks suspicious. - Zeek (formerly Bro) — network security monitor sitting between NetFlow and full PCAP: real protocol parsing emitting structured, searchable per-protocol logs (conn.log, dns.log, http.log, ssl.log, files.log, weird.log) without retaining raw payloads. Where most practical SOC/IR network forensics actually happens. - Beaconing — a C2-hunting signal: malware checking in with its C2 infrastructure at suspiciously regular intervals, unlike the bursty/irregular pattern of normal human/application traffic. Detected via inter-arrival-time analysis; modern C2 deliberately jitters timing to evade this. - DGA (Domain Generation Algorithm) — malware algorithmically computing new C2 domains on a schedule so no single domain can be blocklisted; shows up in DNS logs as high-entropy/random-looking subdomains. - DNS tunneling — smuggling arbitrary data through DNS queries/responses (e.g. oversized TXT records) as a covert C2/exfiltration channel, abusing DNS's dual legitimate/exploitable nature. - JA3 / JA3S fingerprinting — hashing specific fields/ordering in a TLS ClientHello (JA3) / ServerHello (JA3S) to fingerprint a specific client or server TLS stack (often a malware family's) even though the encrypted payload itself stays opaque. - SNI (Server Name Indication) — the destination hostname sent in cleartext during the TLS handshake itself, before encryption kicks in; lets network forensics identify which domain was contacted even with zero decryption. - OT network forensics advantage — since ICS protocols (Modbus/DNP3/GOOSE/IEC 104) are largely unencrypted by design, full PCAP against OT traffic gives complete semantic visibility (exact function codes, register values, commands) in plaintext — the literal product core of Dragos/Claroty/Nozomi's deep protocol parsing, and a genuine advantage over IT network forensics where TLS increasingly limits visibility to metadata tricks (JA3/SNI/beaconing) alone. - PLC forensic dead end — most PLCs keep no audit log at all (no record of who wrote what register when, often unreliable local timestamps), a consequence of limited storage/compute and decades-old firmware never designed for forensic retention, not vendor oversight. Real forensic value in an OT incident usually lives on the engineering workstation (normal Windows box programming the PLCs) instead — project files, USB history, SCADA/HMI logs — which is why Stuxnet's forensic trail was reconstructed from engineering workstations and recovered malware samples, not from the Siemens PLCs themselves. - Control logic verification — the OT equivalent of file-integrity monitoring: extracting/uploading a PLC's current program and comparing it against an engineering golden image (last known-legitimate configuration) to spot unauthorized modifications, since there's no log entry saying "logic changed." Realistically done via the vendor engineering software's Upload function (inverse of Download) over the native programming protocol (S7comm/S7+ for Siemens, CIP/EtherNet-IP for Rockwell, not the real-time I/O protocol) — a read-only operation safe to run against a live PLC, one of few OT forensic actions that doesn't collide with the "can't take it offline" containment constraint. Caveat, not hypothetical: Stuxnet defeated this exact technique with a rootkit-like component that intercepted the PLC's own block-read responses, showing clean logic to a normal Upload/monitor query while different logic actually ran (injected into OB1) — the first known PLC rootkit, and proof that upload-and-compare only works if the PLC's self-reporting can be trusted. Rigorous verification against a sophisticated implant needs independent corroboration below that layer (JTAG/firmware extraction, or comparing actual I/O behavior against claimed program logic) — far more invasive, reserved for dedicated malware-research labs rather than routine IR. - Historian as forensic evidence — since PLCs keep no audit trail, the process Historian (continuous timestamped sensor/setpoint/alarm log, Purdue Level 3) is often the only record of actual physical process behavior during an incident; correlating historian trends against whatever host/network timeline is available (engineering workstation, PCAP) is frequently how "what physically happened, and when" gets reconstructed. - SCD file integrity as a forensic target — GOOSE's Substation Configuration Description file (static multicast/dataset-to-relay mapping) carries no built-in runtime integrity check, so a tampered SCD file is a distinct attack vector from a live network injection; detecting tampering has to happen out-of-band (version control, hashing the file itself) since the protocol gives nothing to lean on. - Anti-forensics in OT — can be purely remote/digital (e.g. the Dec-2025 Poland CHP incident: the attacker wiped the WAGO PFC200's partition table as an anti-forensics step, executed remotely through the SSH-tunnel/private-APN access chain already established — not a physical act). Physical anti-forensics (an insider or facility intruder pulling a drive, degaussing storage, cutting a cable) is a separate, real consideration distinct to OT's physically-reachable hardware, but not what happened in the Poland case — worth keeping "destructive" and "physical" as separate axes rather than conflating them. - OT forensics scheduling constraint — the same physical-safety logic from OT containment applies to forensics itself: a live PLC often can't be pulled for imaging, so analysis frequently happens against a still-running system or gets deferred to a planned maintenance window, a real constraint largely absent from IT incident response. ** VPN / Remote-Access & Tunneling Covered 2026-10-13 — triggered by an interview-process note that the startup is considering a custom VPN product for OT infrastructure at a client's request. Quick vocabulary pass, not a deep dive; see [[ot-ics-security-ramp/curriculum]]. - IPsec — network-layer (L3) VPN suite: IKE for key exchange, ESP/AH for packet protection. Transport mode (host-to-host, payload only) vs. tunnel mode (gateway-to-gateway, whole packet wrapped — the one used for site-to-site VPNs). - OpenVPN — SSL/TLS-based VPN, userspace, TUN (IP-layer) or TAP (Ethernet-layer) virtual interfaces. Flexible and widely supported, slower than kernel-space alternatives like WireGuard. - WireGuard — modern, minimal-codebase VPN built on the Noise protocol framework; UDP-only, kernel-integrated on Linux, no IKE-style negotiation overhead. The current default choice for new deployments. - SSL/TLS VPN ("clientless") — browser-portal-based remote access (an HTTPS gateway proxying into specific internal apps) rather than a full network tunnel; common for vendor/contractor access since it doesn't hand out full network reachability like a traditional VPN does. - GRE (Generic Routing Encapsulation) — encapsulation only, not encryption; often paired as "GRE over IPsec" to carry routing protocols/multicast through an encrypted tunnel. - MPLS VPN — carrier-provided L2/L3 VPN service, not something you run yourself; common for utility WAN backhaul (substation ↔ control center). - DMVPN (Dynamic Multipoint VPN) — Cisco spoke-to-spoke tunneling negotiated on demand over a hub, avoiding full-mesh static IPsec between many distributed sites (e.g. substations). - Jump host / bastion — a hardened, logged single chokepoint remote users must pass through to reach OT assets, layered on top of a VPN rather than allowing direct VPN-to-asset reachability. - ZTNA (Zero Trust Network Access) — identity- and session-based access brokering one specific asset/app per session, instead of a VPN's network-level trust (once on a VPN, you can typically reach anything on that segment). - OT Secure Remote Access (SRA) platforms — vendor category purpose-built to replace flat VPN access to OT with session-scoped, often agentless, fully-recorded access: Claroty SRA, Cyolo, Dispel, Xona Systems, Cisco Secure Equipment Access. Likely the competitive category behind the "custom OT VPN" interview note. - Data diode — hardware-enforced unidirectional (OT→IT only) data flow; solves one-way monitoring/log export, not interactive remote access — a different problem than "OT VPN" despite surface-level association. - IEC 62443 zone/conduit model — architectural frame remote access is supposed to respect: assets grouped into trust zones, cross-zone traffic forced through a defined conduit (firewall/jump host) rather than bypassed by a VPN tunnel. - Engineering workstation (EWS) vendor access — the classic high-risk OT remote-access case: an OEM/integrator needing occasional PLC-programming access, historically given via always-on VPN + shared credentials — the main case SRA/ZTNA tooling targets (scope access to one device, one maintenance window).