Sök

Nyhetsbrev OT-Säkerhet #26 - Tungviktare och dödliga kedjor

Här kommer ett nytt nyhetsbrev fyllt till bredden med personligt utvalda godbitar från OT-säkerhetsvärlden. Du får ett nytt boktips, en premiärvisning (i Norden) av en riktig OT-tungviktare, spretiga tankar kring standarden 62443, ett ramverk kring insiderbrott och en massa annat spännande!

Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Med IT använder man teknik för att hantera information. Inom OT använder man liknande teknik men för "Operations", alltså att få fysiska saker under kontroll. Det kan exempelvis vara att styra maskiner i en fabrik, elproduktionen i ett kraftverk eller kemiska processer i ett raffinaderi. Inom IT är fokus ofta på att skydda hemligheter men inom OT blir det oftast viktigast att hålla en funktion tillgänglig och korrekt. Det innebär att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är anledningen till mina texter. Jag skrev nyligen ett inlägg på Atea-bloggen som förklarar mer.


Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att dra ett mejl till mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!


Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i en egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se. Framöver kommer också en kopia publiceras på Ateas officiella blogg tillsammans med en del annat som jag skriver där.

Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på artikeln och genom att dela den vidare. Tack för hjälpen!

Konsekvensdrivet säkerhetsarbete - Ett boktips (till...)

Om du läste om boken "Security PHA Review for Consequence-Based Cybersecurity" i förra nyhetsbrevet så kanske du undrar om det här är en repris? Men det är det faktiskt inte! Det märks om inte annat på att den här boken är nästan tre gånger så tjock.


Men det är verkligen inte bara barlast som fyller boken, det är väldigt mycket matnyttigt! Det som presenteras är en metod som kallas CCE, "Consequence-driven, Cyber-informed Engineering", slarvigt översatt så handlar det om hur man arbetar ingenjörsmässigt med att hantera konsekvenserna av olika typer av händelser med blicken stadigt fäst på de utmaningar som modern teknik tillfört. Historiskt så är det ju precis där vi kört vilse när vi skulle ta oss från tiden när det framför allt handlade om att hantera att OT-komponenter slumpmässigt gick sönder till att kunna hantera medvetna och avancerade sabotage utförda av kunniga människor med insyn i utformningen av de system som angrips. Redan i titeln förstår vi också att den handlar om "Engineering" och inte "Security", det är viktigt att komma ihåg skillnaden!

Författarna, Andrew A. Bochman och Sarah Freeman, arbetar på INL. "Idaho National Lab" är en intressant amerikansk institution som inte riktigt är vad vi är vana vid när vi pratar om "Lab". Vi brukar tänka på vetenskaplig forskning när vi pratar om "Lab" men INL sysslar inte med den typen forskning utan försöker lösa lite mer ingenjörsmässiga problem i samtiden eller den närmaste framtiden. De sysslar med allt från att pressa kärnreaktorer till alla tänkbara gränser, via att kalibrera enorma kanoner för flottans slagskepp, till att testa EMP-attacker. De gör väldigt mycket kopplat till OT-säkerhet, i synnerhet när det gäller elnätet. De är kanske mest kända för "Aurora", en demonstration där de visade där de kunde förstöra en elektrisk generator fysiskt med hjälp en liten snutt programkod.

De går ut stenhårt och målar upp en becksvart bild av våra möjligheter att försvara våra verksamheter mot den ständigt ökande strömmen av attacker högt och lågt. En av mina egna favoritliknelser dyker upp, den av känslan av att stå på ett löpband och springa allt man kan men utan att man kommer framåt en enda millimeter. Drar man av på tempot det minsta så åker man obönhörligt bakåt... Det här sättet att tänka leder naturligt fram till en del andra populära tankesätt, exempelvis att ingen absolut säkerhet någonsin kommer existera (vilket vi bara kan försöka lösa genom att bygga våra skydd i många lager och med ganska stort fokus på att kunna upptäcka och hantera de angrepp som oundvikligen kommer) eller "Assume breach" dvs att vi alltid ska förutsätta att vi är hackade, faktiskt redan innan vi gått i drift.


Den största delen av INLs finansiering kommer från den nukleära delen av amerikanska Department of Energy. Startskottet för CCE kom 2017 i och med ett forskningsuppdrag för att genomlysa OT-säkerhetsutmaningarna för organisationer som kör kärnkraftverk. Kärnkraftsbranschen, där jag själv fick min praktiska säkerhetsskolning, är förmodligen den bransch som förflyttat sig längst när det gäller OT-säkerhet. Man har ju gått mer eller mindre helt elektromekaniska styrsystem till mycket sofistikerade kontrollsystem baserat på modern teknik och längs vägen skapat ett sätt att arbeta målinriktat med alla möjliga former av säkerhet för att möta de vitt skilda utmaningarna som uppstår kring alla de verksamheter och system som krävs för att köra ett kärnkraftverk på ett effektivt och hypersäkert sätt.

Något som intresserade mig är att de refererar till ett väldigt centralt dokument i all världens kärnkraftsverksamheter, IAEA NSS 13: "Nuclear Security Recommendations on Physical Protection of Nuclear Material and Nuclear Facilities". Den definierar bland annat kravet på att arbeta med en DBT, "Design Basis Threat" - på svenska "Dimensionerande Hotbeskrivning". (Alltså vilka hot organisationens system ska dimensioneras för att "tåla".) Tidigare saknades OT-faktorer helt i det här dokumentet men det är nu så klart väldigt centralt i skyddet av dessa anläggningar. Den som är road kan mycket väl läsa detta dokument även om man inte är i kärnkraftsbranschen, exempelvis är IAEAs resonemang kring begreppet "Graded approach" intressant för alla, alltså att man alltid ska anpassa skyddet, både uppåt och nedåt, baserat på hotnivån och konsekvenserna kopplade till det man skyddar. Om du läst mina nyhetsbrev ett tag så vet du att en DBT är något jag tycker är viktigt för alla organisationer, oavsett bransch, om inte annat så för att säkerställa att organisationen är överens med sig själv om hur hoten ser ut. Det gör att man slipper många onödiga diskussioner!

Nå... Nog med sidospår... Tillbaka till CCE! Om man frågar sig själv är "vad kan hända om någon riktigt elak med full kunskap om vår anläggning, om våra system och om våra rutiner får full tillgång och kontroll över alla våra system? De har dessutom alla resurser och all tid de behöver..." När rysningarna längs ryggraden lagt sig lite börjar man leta efter svar och det är då som CCE blir som mest användbar. ...och kom ihåg: svaren vi ska hitta är alltså inte hur vi ska undvika att det händer utan hur vi ser till att konsekvenserna inte blir en katastrof!


Deras budskap till alla som ansvarar för samhällskritisk infrastruktur är benhårt:

  1. Om din verksamhet är det minsta intressant för andra nationer så kommer du angripas av statsfinansierade angripare. Garanterat!

  2. Om du attackeras av dem så kommer de att lyckas. Garanterat!

  3. Det betyder att de förmodligen redan rör sig i dina system. Garanterat! Nästan...

  4. Din egen stat har inga möjligheter att skydda dig åt dig. Garanterat!

Det är under de här bistra förutsättningarna som de målar upp CCE. Och då var vi tillbaka vid "Assume breach", som är den svåraste delen att ta till sig för de som medverkar i en sådan här övning. Alltså att helt ge upp tanken på att hålla angripare ute (eftersom de redan är inne med full access) och istället helt fokusera på att ta ifrån angriparen möjligheten att göra allvarlig skada. Det är ju också därför denna typ av åtgärder inte går att göra med enbart "omskolat IT-säkerhetsfolk". Det måste vara många andra kategorier med, inte minst processingenjörer, eftersom de flesta åtgärder sannolikt kommer göras med hjälp av förändringar i processen och i sättet vi använder våra leverantörer!

CCE påminner mycket om SPR som jag skrev om i förra nyhetsbrevet i det att man flyttar fokus för sin analys till att förstå konsekvenser. I SPR överger man den gamla trötta riskanalysformeln "Risk = Sannolikhet * Konsekvens" som ju fungerar väldigt dåligt för att bedöma mänskliga motståndare eftersom det inte är slumpmässiga händelser. I CCE är det istället det klassiska ingenjörstänket "Risk = Hot * Sårbarhet * Konsekvens" som dissas. I traditionellt säkerhetsarbete, oavsett vilket område det handlar om, har vi nästan alltid tittat på faktorn "Sårbarhet" eftersom den upplevs enklast att påverka. Vi lever i en tid där vi nästan blivit lite avtrubbade av alla enorma sårbarheter som identifieras i system efter system, ena dagen Solarwinds Orion och nästa Microsoft Exchange. Det är här CCE pekar på att vi oundvikligen kommer drabbas av problem och därför måste lägga vårt krut på att se till att konsekvenserna blir hanterbara!


För oss som sysslar med OT-säkerhet finns det en annan vinkel på samma resonemang som passar oss bra. Vi vet att vi under lång tid framöver kommer fortsätta ha svårt att hänga med IT-världen i deras patchningstempo. Det är förstås också ett skäl till att vi inte kan jobba med faktorn "Sårbarhet" som en väg att minska våra risker. Faktorn "Hot" kommer vi aldrig åt, så då återstår "Konsekvens" som möjlig att jobba med!


Men om man ska peka på skillnaderna mellan SPR och CCE så blir det ganska snart tydligt att det finns en anledning till att CCE-boken är betydligt tjockare, det var inte bara författarnas utsvävningar. Där SPR är mer av ett allmänt tänk så är CCE verkligen en tydligt beskriven metod. Författarna säger själva att man "lånat" bitar från en massa väletablerade metoder och listar bland annat Process Hazard Analysis (PHA), ICS Cyber Kill Chain, Design Basis Threat (DBT) och Crown Jewels Analysis (CJA).

Det första man gör i metoden är att identifiera vilka saker som skulle vara det absolut värsta som skulle kunna hända. Frågor i stil med "Vad får oss att gå i konkurs?", "Vad skulle sätta vår anläggning helt ur spel?" och "Vad skulle döda våra medarbetare?" ställs och besvaras på fullt allvar. Tanken är att till en början helt strunta i om det finns teknikbaserade (oavsett om det är IT eller OT) angreppssätt. Vi vill hitta de funktioner i verksamheten som vi står och faller med. Deras grundpoäng är att de flesta verksamheter inte bottnat i den typen av resonemang och att motstånd i stil med "Det kan ju inte hända!" nästan alltid faller platt till marken när man rotar lite djupare. Det här gäller även verksamheter som är duktiga på att förbereda sig på naturkatastrofer och andra slumpmässiga händelser eftersom de oftast tenderar att vara sämre på att genomskåda mänskliga angrepp, och i synnerhet då IT- och OT-baserade sådana.

I steg två, när man har hittat sina värsta katastrofer, börjar man arbetet med att förstå alla sätt som de kan uppstå. Alltså lite bakvänt mot många andra metoder som tittar på konsekvenser kopplat till ett visst system. Det här är ett brutalt arbete där man analyserar "system av system" ner på skruv- och mutter-nivå och verifierar dokumentation mot verkligheten för att säkerställa att man har full förståelse för de utmaningar vi verkligen står inför. Det var här jag insåg vilken sanslöst dyr metod det här är för stora verksamheter, men å andra sidan är det rimligt att en analys av komplexa system blir ett komplext arbete!

I det tredje steget använder vi en variant på "ICS Cyber Kill Chain" för att definiera en väg till de värsting-resultat som vi identifierade i steg 1 med hjälp av de insikter vi skapat i steg 2. Det görs genom att analysera var i verksamhetens processer vi sätter tillit till saker som vi inte har bekräftat att vi kan lita på. Alltså samma tänk som ligger bakom "Zero trust" fast istället använt av en tänkt angripare. Här används alla tänkbara attackvägar - klassisk hacking, angrepp mot supply chain och att utnyttja mänskliga mål.

Den fjärde, och sista, delen i arbetet fokuserar på att ta de attackvägar som skapades i steg 3 och identifiera motmedel mot dem. Grundtanken är att alltid använda "icke-hackbara" åtgärder där det är möjligt och olika former av övervakning eller fällor där de digitala systemen inte går att komplettera med fysiska åtgärder. För att använda begreppen från NIST CSF så föredrar man "Protect", följt av "Detect" & "Respond" med "Recover" som sista alternativ.


Om du inte redan insett det, så är det om CCE försöker hantera de problem som orsakas av OT-tekniken i våra processer men utan att stirra sig blind på att lösningen måste innehålla OT eller ens digital teknik! Det innebär också att CCE inte är svaret på alla våra risker. Det man ska komma ihåg är att det är inte är självklart att man löst alla mindre allvarliga hot bara för att man hanterat de värsta. CCE är inte svaret på alla frågor men det är svaret på ett antal frågor som många organisationer inte orkat ställa.

CCE må vara en tung metodik att ta från A till Ö men för verksamheter som hanterar extrema risker, för sig själva och för samhället, är det ett arbete som måste göras. SPR som jag skrev om i förra nyhetsbrevet är en enklare metod som siktar delvis på samma risker men som inte är lika deterministisk. Beroende på verksamhetens utmaningar får man välja sin egen väg framåt. Om någon av mina läsare har erfarenheter från den här typen av arbete skulle det vara väldigt intressant att utbyta erfarenheter.


Som bok kan jag bara rekommendera den starkt. Förutom att förklara metoden väldigt tydligt finns det en massa annat intressant som också diskuteras. Om du vill höra författarna själva diskutera CCE-metoden har Andrew Ginter har intervjuat dem, var för sig, i två avsnitt av podcasten "The Industrial Security Podcast". Sarah Freeman i ett avsnitt för några veckor sedan och Andy Bochman i ett annat avsnitt som sändes innan boken givits ut.

Tungt skydd för OT!

Jag har tidigare skrivit om de smidiga brandväggarna och IPSerna från TxOne, senast i min artikel om virtuell patchning i nyhetsbrev #23. De kombinerar ett litet fysiskt format med ett stort skydd på ett sätt som gör det väldigt smidigt och elegant att bygga in skydd i maskiner och ute i anläggningar. Och de är ruggade på ett sätt som inger förtroende i sådana miljöer! Den lilla "EdgeIPS" som är "osynlig" på nätverket gör det verkligen enkelt att lägga till ett starkt skydd utan att alls påverka den existerande uppsättningen. Den smidiga "EdgeFire" ger möjlighet att enkelt hantera de adresskonflikter som ofta uppstår när man börjar ansluta nätverk som tidigare varit isolerade. Båda två har en direkt koppling till systerorganisationen ZDI, Zero Day Initiative, som föder den virtuella patchningsfunktionen med zero-days.

Men! Om man inte vill, eller kan, bygga in skyddet ute i sin anläggning så blir det ju lite fånigt att sätta en massa ruggade burkar i sin datorhall eller i nätverksrummet! Det vore ju smidigt att få samma skydd men förpackat i ett lite mer rack-vänligt format? In på scenen kommer då "TxOne EdgeIPS Pro"! Det är 16kg tung fullblods-IPS, helt inriktad på OT men anpassad för att placeras datacentermiljöer. Det finns faktiskt en storebror också, en modell som är dubbelt så stor. Jag har fått möjligheten att klämma på den första enheten som kommit till Norden i mitt lilla OT-labb.


Det är verkligen en rejäl pjäs. Förutom den stadiga vikten är den 80cm djup vilket kräver ett stadigt rack för att kunna monteras. Man skulle kunna tro att det TxOne gjort är bara att kombinera 24 stycken EdgeIPS i en racklåda men det är faktiskt lite mer än så. Den har en del riktigt intressanta funktioner som man inte hittar i den betydligt mindre EdgeIPS.

Tanken är att man sätter den mellan en access-switch och utrustningarna i verksamheten. Nätverksportarna sitter i par där den ena porten ansluts till switchen och den andra till den fysiska utrustningen. Eftersom den nätverksmässigt är helt osynlig kan införandet göras helt odramatiskt när man har möjlighet att koppla om de fysiska anslutningarna.