.png)
Varning! Det här är möjligen ett av de minst seriösa nyhetsbreven du kommer läsa på flera timmar! Med tanke på att det är utgåva 42 av denna guide, förlåt, detta nyhetsbrev kommer det vara kryddat med små referenser till en av litteraturens största mästerverk. Om du inte förstår - få inte panik och börja leta efter svar i Encyclopedia Galactica! Om du förstår - hur många referenser hittar du? Mycket nöje!
Jag teasade lite kring temat på LinkedIn och Twitter. Den som var snabbast att gissa rätt var Cissi Thorell på Sysctl AB, bra jobbat Cissi!
Den här gången får du (mycket passande med tanke på temat) ett par reportage från mina egna resor till OT-konferenser. Jag tittar också närmare på nytt material från NIST, gratis kurser hos MSB, konsekvenser av den ökande graden av kryptering inom OT och inte mindre än två riktigt intressanta exempel på skadlig kod som är helt fokuserade mot OT.
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. Läs mer om det här i det här nyhetsbrevet!
Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Det här nyhetsbrevet är ju något som jag fortfarande tycker är väldigt roligt att skapa, vilket förstås är viktigt eftersom det till största delen skrivs hemma i TV-soffan. 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 anmäla dig på www.ot-säkerhet.se eller dra ett mejl till mig på mats@ot-sakerhet.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.
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!
PIPEDREAM eller INCONTROLLER
Den största OT-säkerhetsnyheten på länge var väl amerikanska CISAs annonsering av den skadliga koden "Pipedream" den 13:e April. Det finns mycket som är spännande i sammanhanget. Mest anmärkningsvärt är nog insikten som Rob Lee pekat på om att man annonserar det här innan den skadliga koden använts skarpt. På en direkt fråga ville man inte avslöja hur man kommit över koden mer än att det är via en tredje part, det är rimligt att tro att man inte vill bränna sina källor.
Det som är känt är att fokus verkar ligga på angrepp mot PLCer från Schneider Electric och OMRON samt OPC UA servrar. Men det som inte är så tydligt är att en stor del av funktionaliteten riktas mot CoDeSys som används av väldigt många tillverkare. Du kan alltså inte slappna av bara för att du använder andra fabrikat! Annonseringen från CISA innehåller en mappning mot MITRE ATT@CK for ICS som ger mer detaljer kring funktionaliteten som bland annat inkluderar att leta efter intressanta enhet på nätverket, ladda upp filer till PLCer, stjäla inloggningsinformation, krascha PLCer och skriva värden via OPC UA.
CISAs råd för att skydda sig innehåller egentligen inga nyheter. Segmentering, multifaktorinloggning, nätverksövervakning, bra backuper, incidentplanering osv. Mer detaljerad (och intressant!) information finns från bland annat Mandiant och Dragos. Det finns också information från Schneider Electric, CODESYS och WIRED som har skrivit en artikel som är värd att läsa.
Det här är sjunde gången en skadlig kod hittas som är utformad för avancerade angrepp mot OT-mål. Man ska noga akta sig för att känna sig lugn om man inte använder utrustning från de tillverkare som nämns. Motsvarande attacker fungerar mot alla typer av utrustning och med tanke på att den skadliga koden bevisligen är byggd för att vara lätt att utöka med moduler så är det här relevant för alla! Även om jag har underrubriken "Don't panic!" för det här nyhetsbrevet så är det här något som faktiskt borde ge en orolig känsla i magen!
Att synas eller inte synas - det är en av frågorna...
Joe Slowik skrev ett intressant blogginlägg som belyser ett allt vanligare problem med synligheten i OT-nätverk. (Det var också ett föredrag på årets S4-konferens som jag dock inte hann se själv.) Traditionellt kommunicerar system i de nedre nivåerna av Purdue-modellen med helt oskyddade protokoll, utan kryptering. Det har i alla tider möjliggjort säkerhetssystem som analyserar trafiken och larmar vid knasigheter.
I takt med att allt mer vettiga nätverksmodeller dyker upp som inte sätter likhetstecken mellan systemens Purdue-nivå och en nätverksstruktur tenderar också allt mer trafik bli krypterad. Precis som vi såg i IT-världen för ett antal år sedan betyder det att den krypterade trafiken inte längre går att analysera, i alla fall inte utan att ta till ganska komplexa lösningar för att bryta krypteringen. Det betyder också att de IDS-lösningar som är väldigt populära att köpa just nu går mot samma jobbiga öde, nämligen att bli blinda för vad som skickas på nätverket. Allt mer kommunikation använder protokoll som kan krypteras, exempelvis OPC UA och MQTT, men även moderna filosofier som Zero Trust sätter kryptering högt på önskelistan.
Exakt vart detta tar vägen får vi se men det kommer bli många spännande diskussioner framöver kring denna nya utmaning! I det här fallet beror inte osynligheten på NAP/SEP (Någon Annans Problem / Somebody Else's Problem) utan det är faktiskt bara vårt eget problem, både att se och att lösa...
Äntligen (nästan): NIST SP 800-82r3
NIST släppte för några dagar sedan en draft av en uppdaterad SP 800-82, "Guide to Operational Technology (OT) Security". Det är den första publika draften, så det dröjer nog ett tag tills vi ser den skarpa versionen men det är förstås ändå intressant att se vad man fokuserat på att uppdatera!
Det första att notera är att man övergett begreppet "ICS" för att istället gå all in på "OT". Tummen upp från mig på det!
Man trycker hårt på det viktiga med att ha många olika kompetenser med i OT-säkerhetsarbetet, det kan aldrig bara vara en fråga för IT-avdelningen, automationsingenjörerna eller Underhåll!
Något jag gillar skarpt är att man har väldigt många referenser till ISA/IEC 62443 vilket, om inte annat, gör dokumentet extra användbart även utanför USAs myndighetsvärld.
Ett svenskt hjärta bultar förstås lite extra stolt när man ser att vår svenska favorit-konferens CS3STHLM är en av fem konferenser som omnämns på området OT! (Jag håller tummarna att den återuppstår igen efter pandemiuppehållet!)
En detalj som jag gillar är att man har med "Physical Access Control Systems" ("passagekontrollsystem") som en av typerna av OT-system. Det här är en underskattad typ av OT-system som har en del unika/kluriga utmaningar och vars konsekvenser vid ett angrepp typiskt drabbar säkerheten i många andra system!
Jag blev kanske lite förvånad över att man inte trycker hårdare på "Zero Trust" med tanke på hur hårt USAs myndigheter satsar på detta. Det har förstås en radda kluriga utmaningar inom OT vilket man också diskuterar i dokumentet.
Om du använder NIST SP 800-53 så får du ett overlay i SP 800-82 för OT, vilket förstås är till stor hjälp när man implementerar och mäter sina åtgärder!
Det här är ett väldigt bra dokument. Stora delar av det funkar nog nästan som en lärobok för OT och OT-säkerhet. De 300 sidorna ska man inte bli skrämd av, det finns en hel del som går att skumläsa om man inte vill gå på detaljer i allt!
Exempelvis är de dryga 20 sidorna som ger överblick av OT-området en lysande introduktion till området. 10 sidor om hur man får till ett säkerhetsprogram är också bra och 22 sidor om risk management inom OT ger en massa riktigt bra insikter om vad man behöver tänka på i det här området med dess unika utmaningar!
Intryck från S4x22
Jag var på plats för årets upplaga av S4-konferensen i Miami South Beach. Det här är ju den mest kända (och största?) OT-säkerhetskonferensen, som nu är tillbaka efter pandemiavbrottet. Det var tre välfyllda dagar med presentationer från tre scener och runt 700 personer på plats.
S4 är kul eftersom man tar lite annorlunda grepp på den viktiga sociala delen av arrangemanget. Man har skippat de vanliga trista utställningarna där tillverkare står och drar sina pitchar likt Prostetnic Vogon Jeltz när han läser poesi. Istället har man en "Cabana-session" där man håller till utomhus under palmerna på ett pool-område. S4 är ju annars mycket seriöst och är nog den konferens som är mest avancerad och progressiv i sitt innehåll, det är här de stora tänkarna först berättar om sina nya rön! Extra kul är också att det börjar bli klart jämnare könsfördelning bland de medverkande, både i publiken och på scen.
Mina största takeaways personligen är nog:
Jag fick själv en mycket bättre känsla för vad "Zero Trust" kan vara när det kommer till OT. Egentligen är det samma gamla principer som vi alltid hyllat, inte minst om man bygger sina miljöer med "Zones & Conduits" så som ISA/IEC 62443 del 3 pekar på, men nu är det definierat som principer också vilket gör det mycket enklare att komma framåt med praktiska åtgärder! På det här området kommer det hända mycket framöver!
Arbetet med SBOM, "Software Bill of Material", kommer att få många märkliga konsekvenser. En av de första är hur snabbt utvecklingen gått framåt kring automatisk analys av firmware där forskarna nu hittar tusentals (!) redan kända sårbarheter varje dag, och detta på ställen där ingen trodde att de kunde finnas. Att ta hand om det här kommer bli ett enormt arbete för våra produkttillverkare! Det kommer också tvinga många verksamheter att bli bra på Asset Management, eftersom det är ganska meningslöst att jobba med SBOM om man inte vet vad man har för prylar...
Vi ska förvänta oss en revolution på nätverkssidan där SDN, "Software Defined Networking", gör sitt intåg nere på golvet. Sedan tidigare ser vi SDWAN ta över på de högre nivåerna i Purdue-modellen men nu är det tydligt att kombinationen "Zero Trust" och "SDN" kommer kunna skapa fantastiska nätverk ute i anläggningarna. Det finns redan produkter som gör det här på ett sätt som jag skulle känna mig trygg med i känsliga anläggningar! Men jag tror att de stora tillverkarna är på efterkälken här, så vill man komma vidare får man titta på andra spännande företag!
Orden "IT/OT convergence" uttalades i princip aldrig under hela konferensen. Jag tror aldrig det varit ett speciellt hett ämne för "folk i OT-branschen" utan snarare mest för dem som närmar sig det här från "IT-hållet". I praktiken växte IT och OT ihop för 10 år sedan men det kanske är så enkelt att det är nu som det blivit synligt genom uppmärksammade incidenter och frustrerade IT-chefer som "fått OT dumpat i knät"?
Ett roligt inslag (även om det inte är så mycket "action" som man kanske kan tro) är att Zero Day Initiative kör sin "tävling" Pwn2Own där det gäller att demonstrera nya sårbarheter mot OT-prylar. I år var det verkligen superintressanta produkter som deltog som "måltavlor", exempelvis "KEPServerEX" och "OPC UA .Net Standard". Enskilda sårbarheter kan belönas med upp till 40 000 dollar styck. Vad jag kunde se var det i princip bara framgångsrika attacker och i slutändan delades 400 000 dollar ut i belöningar för 26 sårbarheter...
En del av presentationerna kommer dyka upp på YouTube så småningom. Några som jag tyckte är extra värda att hålla utkik efter är:
"A tale of two (very different) secure ICS architectures" -
Alexandrine Torrents berättade om ett intressant praktikfall från energibranschen där man utmanat den gamla nätverksmodellen som försöker segmentera baserat på Purdue-nivå. Det är ju en modell som alltid varit problematisk och missförstådd men som fallerar helt när man ska ta sig an moderna, distribuerade lösningar i stora vind- och solkraftsanläggningar. De har byggt en spännande, distribuerad och skalbar lösning baserad på SDWAN-teknik för kommunikation mellan enheter på de lägre nivåerna i Purdue-modellen. Men hon varnar också för att modellen ger fler möjligheter till misstag med säkerhetspåverkan. Hon avslutar med att visa hur de mappat sina risker mot ISO 27005 och pekar på att det här sättet att tänka sätter fokus på att förstå processen och dess behov av skydd snarare än att skydda OT-systemen i sig!
"Recent cyber attacks and how to stop them 'dead in their tracks'!"
Joel Langil, som är ett tungt namn i branschen, diskuterade ett ämne som knöt an snyggt till det som Alexandrine pratade om. Hans poäng var att de flesta fortfarande tror att OT-skyddet ska fokusera på hot som kommer utifrån när det egentligen handlar om att hantera det som händer efter det att skalskyddet rämnat. När angriparen tagit kontroll över ett MES-system, ett AD eller ett HMI börjar utmaningen snarare likna den som man ställs inför när man försöker hantera insider-hot. Hans budskap handlade egentligen om att man ska göra som standarden ISA/IEC 62443 säger när det gäller segmentering. Att arbeta med det som kallas "Zones" och "Conduits" baserat på riskbedömningar. Enkelt förklarar kan man se det som mikrosegmentering där segmenten inte alltid är enstaka system utan också kan vara grupper av utrustningar. Den absolut viktigaste poängen som matchar en av mina gamla käpphästar perfekt är att det inte räcker med att segmentera. Nyttan uppstår framför allt i att kunna reagera när saker som är blockerade eller normalt inte ska hända ändå inträffar. Några av hans exempel är "Active Directory initierar kommunikation på eget bevåg" eller "Någon försöker ansluta till en ingenjörsstation". Sådant ska initiera larmklockor och rask incidenthantering!
Ni som läst mina nyhetsbrev tidigare vet att jag inte gillar hur Purdue-modellen brukar användas. Både Alexandrine och Joel gav mig verkligen vatten på min kvarn! Misstag som exempelvis handlar om att:
Internet är inte samma sak som "nivå 5" i Purdue-modellen! Det är bara en bärare av kommunikation!
Nivå i Purdue-modellen och nät är inte samma sak!
Segmentering blir att man bara filtrerar bort all trafik som ändå inte är ett hot och släpper fram trafik till tjänster som är viktiga och sårbara.
Det här är misstag som jag ser hos många och som vi behöver sluta göra om vi ska lyckas!
"Buyer beware: Managing OT Cyber risks in Mergers, Acqusitions and Divestments (MA&D)"
Nathan Fink diskuterade ett område som på ytan kan verka lite tråkigt men som verkligen är viktigt och utmanande, nämligen hur man hanterar OT-säkerhet i samband med att företag säljs och köps. Hur hanterar man risken för att man köper ett företag som redan är hackat men där attacken inte upptäcks ännu? Varför stiger antalet ransomware-angrepp mot företag som ska säljas? Jag ska inte försöka återberätta hans presentation men rekommenderar den varmt om du berörs av den typen av utmaningar!
"Slaying ICS mythical creatures: Top mindset changes to create the future"
Ron Fabela berättade om myterna som vi drar för varandra inom OT-branschen och för våra kunder. Han ser att vi hindrar utvecklingen genom att envist hålla fast vid sanningar som kanske bara är myter numera.
Bland hans exempel fanns myten om Enhörningen, alltså att vi VILL vara SÅ speciella, vilket leder till att vi inte släpper in nytt folk i branschen. Vi behöver ställa rimliga krav och inse att alla kan inte vara bäst!
En annan myt handlade om Basilisken som dödar med en enda blick. Vi hör ofta budskapet att "Allt är jättefarligt!", kanske speciellt som säljargument men också för att bekräfta att det behövs ett en hjälte - mig - för att lösa problemet! Sluta skrämmas, börja sprida myterna om hur lätt det är att stoppa hoten istället om man bara gör sitt jobb!
Han hade myten om Varulven, där du behöver en silverkula för att vinna - i vårt fall gärna en apparat med blinkande lampor som löser alla våra problem. Tyvärr jättesvår att hantera... Ta reda på vad som stör de ansvarigas nattsömn och vad som hindrar dem från att lösa problemet. Vi konsulter som lär oss från så många organisationer har ett ansvar att sprida våra kunskaper! Vi ska inte vara hjältar, vi ska skapa hjältar!
Jag vill tro att jag själv är en del av lösningen på några av de problem som Ron målar upp genom mina nyhetsbrev som jag roligt nog märker inspirerar folk att närma sig vår bransch!
Rob Lee om Chernovites pipedream
Rob Lee, grundaren av Dragos, är alltid fantastiskt intressant att lyssna på. Den här gången handlade det förstås om Pipedream som jag även skriver mer om i en separat text här ovanför. Rob tryckte bland annat hårt på att media presenterat allvarligheten fel och i synnerhet då att angreppen inte är begränsade till specifikt Omron och Schneider Electric! Han tryckte också på att det här inte är ett verktyg som ger access till offrets miljö, det måste man lösa på annat sätt. När man väl har tillgång används Pipedream för att "skapa effekt"... Verktyget är inte beroende av sårbarheter i systemen utan har förmågan att använda funktioner som finns naturligt där! Möjligheten att angripa via CoDeSys ger också möjlighet till proxy-funktioner, vilket gör det extremt viktigt att kunna hålla koll på vad som händer nere i PLC-näten! När det gäller Omronattacken kan man angripa utrustning "bakom" plcn via ethercat vilket också är väldigt svårt att förebygga utan det behöver istället upptäckas om det händer! Avslutade med att håna utvecklarna av Pipedream, han kallade dem pinsamma eftersom de upptäcktes redan innan de fick chansen att ens köra ett skarpt angrepp...
Samarbete i Norge!
Det var riktigt intressant att höra Trond Straume, CEO på norska Volue och Margrete Raaum på KraftCERT prata om deras samarbete när Volue drabbades av ett ransomware-angrepp förra året! Som alltid är det viktigt med rutiner för omvärldskommunikation vilket de löste på riktigt kreativa sätt som bland annat inkluderade partnerskapet med KraftCERT och att hålla öppna zoom-möten... Ett citat från vår favoritbok som dyker upp i min hjärna är:
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
SOAR för OT-säkerhet!
Joshua Magady och Jay Spann diskuterade det spännande området automation av säkerhetsarbete! Det här är ju inte ett nytt område på IT-sidan även om jag inte tror så många har kommit fullt så långt som de hoppades på där? När SOAR, "Security Orchestration Automation and Response", diskuteras inom OT hör jag oftast reaktionen att det inte går att använda eftersom man inte vågar ha automatiska åtgärder på incidenter. Nu handlar ju SOAR om så mycket mer, där automatiska åtgärder definitivt inte är det första man satsar på. Viktigt att komma ihåg är att SOAR är fel ända att börja i om man är en omogen säkerhetsorganisation. Personligen tror jag att det är relativt meningslöst om man inte redan har någon form av SOC (Security Operations Center, alltså en grupp specialister som fokuserar på att analysera incidenter och aktivt söka efter angrepp). Men har man kommit så långt ska man absolut satsa på att bli mer effektiv och reaktionssnabb genom automation även kring OT-säkerhet! Börja med att automatisera förebyggande arbete som ofta är tråkigt och därför lätt prioriteras bort! Det blir roligare att jobba i SOCen vilket leder till att medarbetarna stannar kvar längre och utvecklas snabbare.
Zero trust funkar ju inte för OT! Eller?
En riktigt intressant paneldebatt som inkluderade John Kindervag, mannen (eller kanske legenden?) som återuppväckte begreppet "Zero Trust" 2010 och definierade det tydligt. (Jag var senast inne på det här området i nyhetsbrev #34.) Personligen fick jag en radda insikter som jag inte haft förut, en av dem är hur långt efter Sverige är efter USA på det här området - på det här området är amerikanska myndigheter extremt tydliga: Zero trust är vägen framåt! Även inom OT!
Forensik på PLCer
Mandiant presenterade erfarenheter kopplade till det ramverk de har för forensiskt arbete i inbäddade system som exempelvis PLCer. Det här är ett område som har en del spännande utmaningar som man inte är van vid om man arbetar med forensik i IT-världen. Utmaningarna kan inkludera så grundläggande saker som att hitta rätt fysisk enhet när man står och tittar i skåpen, tillgång till rätt mjukvara för att kunna kommunicera med enheten är ibland klurigt, för att inte tala om att ha rätt licenser. Att veta vad som är förväntad konfiguration eller programmering är inte alltid möjligt. En till synes så "enkel" sak som att ha tillgång till rätt typ och version av kablage kan sätta rejäla käppar i hjulet. Är man på "extra spännande" ställen kan det krävas speciell utbildning eller skyddsutrustning för att arbeta på rätt plats. Att vara HUET-tränad, dvs i utrymning från en helikopter, under vatten, uppochner, är ett klassiskt exempel för att få lov att arbeta off-shore...
Att programmera PLC säkert är en konst!
Även om mycket av vår OT-utrustning i grunden ofta är relativt osäkra så finns det saker man trots det kan göra för att skapa säkrare system. De som programmerar PLCer är kanske lite ovana att sitta i förarsätet när vi pratar om cybersäkerhet men det är precis det som projektet "Top 20 Secure PLC Coding Practices" siktar in sig på. Jag har skrivit om detta tidigare, läs gärna mer i nyhetsbrev #29. Vivek Ponnada och Josh Ruff gick igenom en radda jättebra exempel för att illustrera varför detta faktiskt är riktigt viktigt! Det här är ett område där man ser en väldigt tydlig koppling mellan ett angrepp och riktigt jobbiga fysiska konsekvenser och dessutom, för ovanlighetens skull, kommer åt både sannolikheter och konsekvenser i riskanalysen! På köpet höjer vi både kvalitet och robusthet, vilket ju brukar vara bra! Josh och Vivek beskriver också en del intressanta testfall som ofta missas i FAT/SAT-testning, speciellt när man flyttar ut logik från PLC:n till exempelvis ett HMI.
Software Defined Networking inom OT!
Tim Watkins från Schweitzer Engineering Laboratories höll en presentation som verkligen gjorde avtryck för mig. Schweitzer är väl mest kända i eldistributionskretsar (!) men tillverkar bland annat nätverksutrustning som är intressanta på andra områden också. Fokuset för dagen var hur man kan använda SDN, Software Defined Networking, för att implementera Zero Trust. Nu pratar vi inte om SDWAN på det sätt som det brukar används inom IT. Nu är det kommunikation långt ner i Purdue-modellen där både behoven och möjligheterna ser väldigt annorlunda ut! Schweitzer har verkligen gjort detta på ett nytt sätt! Det här har klara drag av Zero Trust på så sätt att allt bygger på att uttryckligen ge tillstånd för det som är ok och att allt annat automatiskt är förbjudet. Den som sysslat med mikrosegmentering vet att det kan bli extremt mycket arbete för att manuellt analysera vilken trafik som är nödvändig. I deras lösning kan man, istället för att konfigurera alla regler själv, semi-automatiskt få till konfigurationen genom att använda projektfiler, nätverksdiagram och andra källor som man redan borde ha! En stor nytta med deras upplägg är att det blir väldigt mycket lättare att få till IDS-funktioner som "ser" rätt trafik. Jag ska inte försöka återberätta allt detta, vänta in videon istället, det här är imponerande!
Tack för i år!