backup: 2026-10-14 09:41

This commit is contained in:
2026-10-14 09:41:44 +03:00
parent 828f59d961
commit 5c6ccbe3f2
13 changed files with 709 additions and 43 deletions
+65
View File
@@ -74,7 +74,16 @@ Running, quiz-ready glossary built up during Aner's cybersecurity terminology ra
- 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.
@@ -146,3 +155,59 @@ Covered 2026-10-05 in response to "how do I build a fake OT network to play with
- 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).