OT Risk Management: Risikovurdering i den Fysiske Verden 🏭

Når vi træder ind i Operational Technology (OT) - som dækker over ICS (Industrial Control Systems) og SCADA - ændrer spillereglerne sig markant fra det, vi kender i klassisk IT. I denne artikel dykker vi ned i, hvordan man griber en risikovurdering an i et OT-miljø, forskellene mellem eksisterende og nye netværk, samt hvorfor rammeværktøjer som NIST 800-82r3 er afgørende.

🏗️ Analyse af Eksisterende vs. Nyt OT Netværk

Når vi skal analysere arkitekturen på en fabrik, afhænger vores tilgang utrolig meget af, om fabrikken allerede producerer (brownfield), eller om den er på tegnebrættet (greenfield).

1. Eksisterende OT Netværk (Kørende Fabrik)

At analysere et anlæg i fuld drift kræver ekstrem forsigtighed. OT-udstyr er ofte bygget med meget lidt regnekraft og netværkskapacitet, så blot at køre en klassisk netværksscanner som Nmap (som i IT) kan få en PLC (Programmable Logic Controller) til at crashe fuldstændigt og sænke produktionen!

Fremgangsmåden er derfor:

  • Passiv Reconnaissance (Sniffing): Vi lytter på netværket uden at udsende pakker. Vi opsætter SPAN-porte / Mirror-ports på core switche og bruger værktøjer til at analysere netværkstrafik (f.eks. Zeek eller forespørgsler via pcap filer) for at identificere aktive enheder (Asset Inventory) og hvilke protokoller der benyttes.
  • Walkdowns (Fysisk gennemgang): Man går rent fysisk en tur i fabrikken. Vi følger kablerne, ser på maskinerne, og finder det stykker udstyr, som en leverandør i gamle dage har gemt inde bag et panel, men som overhovedet ikke fremgår af the “As-Built” netværkstegningen.
  • Konfigurations-gennemgang: Undersøgelse af eksisterende firewall-regler, port blockings og adgangskontroller (især ind mod proces-netværket).

2. Nyskabt OT Netværk (Gårdsdagens Design)

Når vi designer et nyt netværk, er fokusområdet Secure-by-Design. Det er drastisk billigere og lettere at bygge sikkerhed ind fra starten end at skulle lappe og segmentere løbende senere hen.

Fremgangsmåden her centrerer sig om papirarbejdet:

  • Threat Modeling & Design Review: Vi vurderer de foreslåede tegninger og tjekker benhårdt, om de overholder Purdue Modellen (se min tidligere note om Purdue segmentering).
  • Zone & Conduit Analyse: I henhold til IEC 62443 inddeler vi udstyr i “Zones” baseret på funktion og kritikalitet. Vi definerer derefter de tilladte og afgrænsede kommunikationsveje (“Conduits”) imellem dem, og planlægger minutiøst, hvor de forskellige jump hosts og data-dioder/firewalls skal stilles op.
  • Vendor Risk Scrutiny: Før udstyr rulles ud, evaluerer vi de leverandører, som er valgt. Hvad er deres patch management, og hvordan faciliteres fjernsupport sikkert (Remote Access)?

📋 Informationsindsamling & Analysetyper

Hvilken information skaffer vi først, og hvorfra?

Før selve analysen kan starte, mangler vi basal struktur. Vi sætter hurtigst muligt jagten ind på:

  1. Netværkstegninger (As-Built & As-Designed): Skaffes via Plant Manageren (ofte forældede), eller netværksingeniørerne.
  2. Asset Inventory List: Alle IP’er, MAC adresser, og hardware. Kan typisk trækkes ud vha. fabrikkens passive overvågningssystem, men oftest må vi bygge den manuelt via pcap-filer.
  3. Firmware & Software versioner: Afgørende oplysninger om udstyrets aktuelle stand til sårbarhedsassessment.
  4. Operationelle konsekvenser: Hvis “Machine X” fejler, eller HMI’en sættes ud af spil, hvad sker der så med produktionen og sikkerheden for medarbejderne? Fås igennem afgørende interviews med selve process-ingeniørerne, som styrer værket.

Hvilke type analyse gennemfører vi?

  • Konsekvensdrevet Risikovurdering (CCE): I stedet for at starte med sårbarheder inderst, spørger vi udefra: “Hvad er vores ‘Crown Jewels’ og hvilken process er mest kritisk, og hvordan kan den bringes til standsning?” – og så identificeres risiko-scenarierne ud fra the worst case.
  • Segmenteringsanalyse: Hvor kan en hacker pivotere igennem? Verifikation af, om der eksisterer uautoriserede “bagdøre” via dual-homed styrecomputere, eller et 4G USB-modem i en maskine, der lynhurtigt omgår core-firewallen (Air-gap brud).
  • Vulnerability Assessment: Vi mapper vores lister i Asset Inventory op imod kendte databaser med sårbarheder, altid med respekt for det industrielle udstyr.

Hvad er Outputtet? (Handlinger og Artefakter)

Et succesfuldt risk management sweep skaber to primære linjer af output:

  • Artefakter: Reviderede og sandfærdige netværkstegninger, et stærkt detaljeret Asset Inventory, et formaliseret Risk Register, samt en rapport med en præcis Zone/Conduit logik.
  • Handlinger: Opbygningen af en prioriteret udbedringsplan (Remediation Plan). Typisk vil det afføde tiltag som opsætning af decideret strammere ACL’er (firewall regler), fuldstands fjernelse af direkte internetadgang eller introduktion af kompensationskontroller (fordi vi ikke kan patche).

🛡️ NIST 800-82r3: Hvorfor OT Risk Management adskiller sig fra IT

NIST 800-82 version 3 adresserer specifikt rammeværket af koncepter til styring af ICS-sikkerhed. Læsningen af Section 4: Managing OT Security Risk drager flere streger i sandet og afslører fundamentale skift i tankegangen bag sikkerhed, når det vedrører operationel teknik.

Den fundamentale forskel (CIA vs. SRP / AIC)

I Enterprise IT handler fundamentet om CIA-triaden (Confidentiality, Integrity, Availability). Og rækkefølgen byder at vi for alt i verden vil forhindre et ransomware datalæk, som bryder fortrolighed og lovgivning. Hvis der er tegn på brud, så ‘kill-switches’ og nedlukkes systemet for netop at bevare dataen trygt.

I OT ombygges dette koncept totalt, da vi prioriterer fremdriften bag maskinerne: Ofte vendes CIA om til AIC (Availability, Integrity, Confidentiality), eller erstattes med et bedre parameter: SRP (Safety, Reliability, Productivity).

  1. Safety & Availability: Er ubestridt vigtigst. Vi kan ikke bare genstarte en PLC, hvis der opstår et problem i et kernesystem bygget i et smeltende atomkraftværk eller der laves mad til millioner af mennesker. Nedetid koster liv - eller ufattelige dagbøder.
  2. Integrity: Vi SKAL vide at maskinen får korrekte målinger. Modificerede netværkspakker på dette stadie giver ikke korruption af en PDF fil, men i stedet en motor til at spinde ude af kontrol over for mange grader.
  3. Confidentiality: Placeres på sidstepladsen. Som udgangspunkt er vi fuldstændig ligeglade med om en hacker overvåger, hvor mange grader stålet smelter ved, bare at vi kan slå fast med en 100 procent garanti at vedkommende ikke kan ændre grænseværdien.

De 5 Vigtigste / Interessante Konklusioner fra Lektionen

1. “Worst-case scenario” er ikke længere tab af data, men tab af liv

I en bank er worst-case scenario ofte et brud på GDPR og et enormt stjålet pengebeløb. I et OT-miljø er worst-case scenariet en direkte kinetisk effekt (fysisk skade): Kæmpemæssige varmerør der ikke lader tryk ud og i stedet eksploderer, vandforsyninger der bliver forgiftet, gasudslip, eller tab af menneskeliv / naturen (HSE - Health, Safety, Environment). Dette ændrer hele vores tankegang markant. Vi beskytter ikke længere the virtuel data, men vi bygger et hegn omkring den fysiske verden. Skræksmålet hæves, når vi designer sikkerhed til det.

2. Manglen på “Standarder” og utallige separate Leverandører

En moderne IT-infrastruktur roterer typisk trygt om få standardiserede enterprise-spillere (Windows Active Directory, Cisco netværk, Amazon Cloud).
OT-miljøet er derimod den vildeste diverse hardware-legeplads. Det er stærkt fragmenteret og består af utallige proprietære systemer fra dominerende leverandører som (Siemens, Rockwell, Schneider, ABB).
Det resulterer i specifikke protokoller med lang anciennitet på bagen. En helt normal produktion kan desuden indeholde blandet OT-udstyr fra mere end 20 forskellige maskinbyggere og have ICS systemer bygget på forældet Windows XP computere fra 00’erne, som skal køre uden stop i ud over 30 år. Denne logik harmonerer ekstremt ringe i den homogene IT-verden - “Standard OT løsninger” eksistere reelt ikke.

3. Kilder til Factual Information for Sikkerhed i OT

Når the skal undersøges for håndtering af risici omkring industriel teknologi, støtter vi os markant oftere til referencerammer fremfor stack overflow:

  • NIST 800-82r3 (Guide til OT Sikkerhed, baseret udelukkende på the bedste erfaring og koncepter)
  • CISA (Cybersecurity and Infrastructure Security Agency, der specifikt publicere ICS Alerts).
  • IEC 62443 (Den gyldne referencestandard formuleret af industrien selv med den praktiske netværksmodel for Zone og Conduits.)
  • Leverandørernes (Vendors) egne guidelines (De fleste store aktører udstikker “hærdede”, best practice setup configs til de maskiner der købes).

4. En sårbarhed behøver ikke at være en CVE i koden

I datacentre er en “vulnerability” overvejende en fejl indpodet i koden, som en programmør har lavet – bedre kendt som et CVE nummer der udbedres med the nyeste patch version.
I OT kan systemet operere fuldstændig præcis som tiltænkt af skaberen, og alligevel indeholde gigantiske sikkerhedshuller!
Sandheden er, at mange industrielle legacy-protokoller oprindeligt blev designet lang tid før internetadgang, og er stærkt bygget uden konceptet “Autentificering”. De stoler med andre ord blindt på samtlige enheder, så længe at signalet befinder sig i det lokale netværk (Insecure-by-Design). Et eksempel er Modbus-protokollen. Sender man en stop-kommando til en given port, så adlyder protokollen ordren uanset hvem eller hvilken software som leverede signalet til dem. Dette kaldes “feature abuse” – Hackerne udnytter reelle features til deres fordel, uden nogensinde at overtræde og skrive ind i the forbudte Memory-huller, så det er teknisk set IKKE en bug og derfor ikke udlistet i CVE-databasen.

5. Patching er sidste udvej – Kompensationskontroller er OT Sikkerhedens Konge

Normal procedure for serveropsætninger er, at man glædeligt re-booter med de allernyeste Windows Updates om aftenen – bl.a. under the ikoniske “Patch Tuesday”.
Bruger man de samme opdateringsmetoder nede i kælderen på operationslaget, frembringer uanmeldte boot og patch opsætninger derimod massivt driftnedbrud. En maskine kan reelt afbryde processen i softwaren selv og kan ødelægge tonsvis af fysisk tilknyttede produkter på båndet. Desuden dækker udstyrets garanti for det meste kun den præcise software pakke maskinen har, og en maskine må ofte og kan the reelt set ikke patches, da firmware-skiftet bryder den vigtige sikkerheds-certificering, fabrikken har modtaget the fra leverandøren af enheden.
I stedet for IT’s patche-kultur the, bygger man ICS design udelukkende op på Kompenserende Kontroller (Compensating Controls). Hvis man har et PLC maskine der ikke vil kunne lappes, ja, så isolerer man i the stedet netværket. Vi pakker udstyret meget mere sikkert ind; segmenterer et virtuelt DMZ netværks bur udelukkende over netop systemet og foran tillades vi den en Firewall der kan overvåge og tillade alene adgang fra Human Machine Interface (HMI) skærmen igennem.

Endelig Opsamling

Integration af “OT Risk Management” forudsætter et opbrud fra mange klassiske IT-security reflekser. Vi kan ikke længere blot undersøge fejllogs. Vi er nødt til at tænke i indkapsling af afgørende fysiske processer og beskytte de massive industrielle værdier. Dette betyder, at fundamentet bibeholdes sikkert via pålidelig segmentering (Purdue), passiv snifning efter assets samt systemer bygget “Secure-by-design”. Som OT-specialister sikrer vi, at fabrikkerne ikke bryder sammen, og vi prioriterer oppetid og sikkerhed over blot at fokusere på datatab.

Kilder

> Quiz: Test din viden

1. Hvorfor er aktiv scanning farlig i eksisterende OT-netværk?

2. Hvad fokuserer Nyskabt OT-netværk på?

3. Hvad sikrer Threat Modeling i OT-netværk?

4. Hvad er passiv rekognoscering i OT-sammenhæng?