Sökresultat

Den här gången tittar jag på riktigt cool teknik för virtuell patchning av zero-days i OT-system så att du kan slippa störa din verksamhet med omstarter! Jag återvänder också till NIS2 och tittar närmare på vad som är på väg! Sedan blir jag lite filosofisk och funderar kring alla ord som vi slänger oss med och vad som händer när vi missförstår varandra. Plus en massa annat spännande förstås! 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 igång den fysiska processen och att se till att inget farligt händer som kan skada medarbetare eller miljö. Det innebär i sin tur att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är en av anledningarna till att jag skriver om det. 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@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här artikeln delas eller i Säkerhetsbubblan på Facebook. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på den här artikeln och genom att dela den vidare. Tack för hjälpen! Mats filosoferar... Den här artikeln får du läsa på egen risk! :-) Om du inte ser upp kan du bli mer förvirrad än du var innan av mitt filosoferande kring några ord och begrepp som varit populära på sistone... Det är förstås viktigt att alla är överens om vad ett visst ord betyder! Det är ju grunden till att kunna ha ett språk överhuvudtaget. De flesta håller nog med om att samhället generellt har mer stingsligt över vad vi lägger olika ord, det är inte nödvändigtvis fel men ändå ett potentiellt problem. Inom OT-världen är det förstås likadant och jag tycker att det har blivit värre på senare år. En anledning är förstås att både tekniken blivit allt mer komplex och att hoten mot vår säkerhet samtidigt blivit större och svårare att överblicka. Vissa ord verkar folk gå igång på mer än andra. Senaste året har "IT/OT-convergence" varit ett sådant begrepp som häftigt debatterades, både offentligt och i mer inofficiellt diskussionsgrupper på Internet. Som en naturlig följd av den diskussionen kommer frågan om segmenteringsprinciper och Purdue-modellens eventuella förestående död alltid upp. Ett annat ord som passar in i samma resonemang är "Edge-computing". Vad är det egentligen? Och vad betyder det för de andra diskussionerna? Drar vi in begreppet "IoT" blir det ännu fler frågetecken. För att inte tala om begreppen vi ska använda för att beskriva våra risker och skyddsbehov. Är det det gamla vanliga "CIA" - Confidentiality, Integrity & Availability som vi ärvt från klassisk informationssäkerhet? Eller passar kanske "COO" - Controlability, Operability & Observability från teoretisk processanalys bättre för OT? På senare tid har "SRP" - Safety, Resilience & Performance seglat upp som en favorit för många klassiska OT-verksamheter för att trycka på skyddet av människor och miljö. Även själva begreppet OT, som ju delvis uppstod som ett försök att komma bort från en massa teknik- och branschspecifika ord, går förstås att ge en massa olika innebörder. Som vanligt finns det förstås inte en sanning här! Och en orsak till det är väl som vanligt att de som diskuterar har väldigt olika världsbilder. Jobbar du med olje-raffinaderier ser du självklart helt annorlunda på alla dessa begrepp jämfört med om du tillverkar tandpetare. Är du dessutom tillverkare av utrustning eller mjukvara har du alltid en egen agenda i bakhuvudet som påverkar den bild som du försöker övertyga resten av världen är rätt. Jag ska inte på något vis försöka göra sken av att jag genomskådat alla dessa diskussioner men kanske har vi som dagligen rör oss mellan olika branscher och mellan produkter från olika tillverkare lite lättare att konstatera att det inte finns en världsbild som passar alla. Lika lite som att det sällan finns enkla svar på svåra frågor, det gäller ju faktiskt i alla områden i livet! Det första att inse är att det inte går att diskutera alla dessa begrepp var för sig. De hänger alla ihop med varandra och det är bara genom att vara övertydlig med vad som menas som vi kan bli duktiga på att kommunicera våra tankar. Allt säkerhetsarbete går i slutändan ut på att adressera risk. Jag tror det är där man måste börja även när det gäller våra begrepp. Beroende på hur hoten mot din verksamhet ser ut måste du förstås välja en begreppsvärld som passar. Har du en OT-verksamhet som hanterar känslig information, tillverkningsrecept är kanske det vanligaste exemplet, ja då kanske hela ditt säkerhetsarbete bygger på klassisk informationssäkerhetsanalys och "CIA-begreppen". Om du producerar LPG-gas är du förmodligen mer fokuserad på att inget farligt händer i din anläggning, då kanske ditt Seveso-arbete gör det mer rimligt att resonera utifrån "Safety/Resilience/Performance"? Men för att vara tydlig kanske du ändå måste kombinera begrepp från flera modeller så att bilden blir klar för alla? När vi kommer till segmentering och Purdue-modellen känner jag att det vanligaste misstaget är att man sätter likhetstecken mellan zoner i segmenteringsmodellen och den fysiska nätverksmodellen. Det är exempelvis jättevanligt att man ser ordet "Cloud" eller "Internet" överst i modellen. Jag tillhör dem som hävdar att det är feltänkt! Bara för att Internet är bärare av information eller att en applikation snurrar i molnet betyder ju inte det automatiskt att skyddet är sämre än i någon av de "interna" zonerna. En källa till förvirring är att Purdue-modellen, när den skapades i början av 90-talet, inte handlade om säkerhet alls utan beskrev hur man skulle bygga en bra arkitektur enligt standarden ISA-95. När säkerhetsresonemangen i ISA-99 övertog begreppen från ISA-95 var det ingen tvekan om att den då tillgängliga tekniken gjorde att varje lager i modellen blev egna nät på egen hårdvara. Så är inte verkligheten idag! Visst finns det många situationer där man tvingas ha egna fysiska nät för de olika säkerhetszonerna men i allmänhet handlar det egentligen om ordning och reda kombinerat med vad som går att bygga och administrera. Å andra sidan finns det andra, mer praktiska, skäl till att inte vad som helst går att köra i molnet. Det här med typiska cykeltider för de olika lagren i modellen tycker jag också är ett bra sätt att hänga upp tänkandet. Nära den fysiska processen (0 - 2) arbetar våra system med händelser som mäts i bråkdelar av en sekund, på MES-nivån (3) är det uppe i timmar, skiftlag eller dagar och på ERP-nivån (4) betydligt längre än så. Det är ju också här som "Fog-computing" och "Edge-computing" helt naturligt uppstod i ett behov av att flytta molnet "närmare marken" eftersom fysikens lagar började sätta gränser för hur vår system-arkitektur kan se ut. När kraven på svarstider närmar sig noll och mängden data som ska hanteras sväller enormt blir vissa lösningar helt enkelt inte möjliga! I kölvattnet till resonemang om Internet och segmentering dyker IoT upp som en källa till missförstånd. Om det är IoT - "Internet Of Things" så måste det ju kommunicera på Internet, det hörs ju på namnet! Och om IoT-prylarna pratar med system på Internet så betyder det ju att Purdue-modellen kollapsar om enheter nere i processen ska tillåtas prata direkt ut på Internet! Eller? Det väldiga insamlandet av information som vi ser i den snabba digitaliseringen av alla branscher skapar ofta förvirring just kring det här. Svaret är som vanligt: "Det beror på!". Sätter du en vibrationssensor på ett kullager som skickar data direkt till något analyssystem är det förmodligen "IoT". Samlar du in data från PLCer och annan processnära utrustning handlar det nog snarare om klassisk system-integration. Vad ska inkluderas i själva begreppet OT då? Frågar du mig handlar det inte om skillnader i teknik eller bransch utan vilka problem vi försöker lösa. Är ditt fokus på information sysslar du med IT och är det på att styra någon fysisk process så är det OT. I praktiken är det förstås inte så svart eller vitt utan det finns en hel skala av grått där emellan. Det är också därför det där "IT/OT convergence" är så viktigt att få rätt, dessa två världar behöver hanteras på ett samordnat sätt men det betyder inte att de nödvändigtvis kommer växa samman helt! Som alltid när det gäller språk utvecklas nya betydelser av ord i takt med att behoven av dem förändras. Ett exempel är att man sällan hör någon tala om "Fog-computing" numera sedan "Edge-computing" övertog i princip samma betydelse. Den här ständiga utvecklingen av språket kommer förstås också alltid kunna leda till missförstånd, det är ju inte unikt för vår bransch. Om jag ska sammanfatta mina egna insikter så är de sedan länge att vi måste vara försiktiga med att anta att andra lägger samma betydelse i orden vi använder som vi själva gör. Det handlar ofta bara om att orka förklara vad man menar! På samma måste IT-folk och OT-folk vara väldigt ödmjuka inför att de har helt olika världsbilder när de allt mer "tvingas" samarbeta. Kom ihåg att exakt samma teknik oftast måste användas på helt olika sätt för att lösa IT-behov och OT-behov! OT-säkerhet utan patchar! Jag genomför just nu ett uppdrag åt en industriell OT-kund där vi använder IPS-skydd och brandväggar från TxOne för att knyta ihop nätverk som tidigare varit avskilda. Om du har följt mitt nyhetsbrev länge kanske du minns att jag skrev om en tidig version av deras produkter i nyhetsbrev 14 och med en uppdatering i nyhetsbrev 17. TxOne är ju ett riktigt spännande möte mellan IT och OT där Trend Micro har krokat arm med Moxa för att skapa något som kombinerar deras respektive traditionella styrkor. Sedan jag skrev om dem senast har det hänt en del, så jag tänkte det kunde vara dags för en uppdatering. Trend Micro ligger ju som kanske bekant bakom ZDI, Zero Day Initiative, som är den största köparen av sårbarheter bland alla bug-bounty organisationer. Det ger dem tidig tillgång till stora mängder nya sårbarheter som de bland annat använder för att snabbt kunna erbjuda skydd via sina säkerhetsprodukter. För TxOne betyder detta att man kan erbjuda virtuell patchning av sårbarheter redan innan tillverkarens egna patchar släppts, dvs man kan adressera zero-days med signaturer, vilket ju är både coolt och unikt. ZDI har på senare år fokuserat allt mer på OT-sårbarheter, vilket exempelvis märktes på förra årets S4-konferens då tävlingen Pwn2Own hölls med enbart OT-produkter och där 250 000 dollar delades ut till vinnarna. De annonserade nyligen också att ZDI var störst på OT-sårbarheter under 2020. TxOne har också lösningar för skydd av klienter i form av produkter för vitlistning, inventering och virusskanning men idag tittar vi på deras nätverksprodukter. (Du kan läsa om deras helt unika sticka för virusskanning i nyhetsbrev 16.) Produktserien består av en management-konsol, en brandvägg och två varianter på IPS. Namngivningen av produkterna andas modern OT-teknik, de kallas "EdgeFire" och "EdgeIPS". Om du inte är bekant med begreppet IPS, "Intrusion Prevention System", kan man kort och slarvigt beskriva det som ett slags virusskydd som tittar på nätverkstrafik. Istället för att titta efter virus tittar man efter tecken på en attack och när en sådan hittas stoppas helt enkelt den aktuella anslutningen utan att påverka all annan trafik som passerar på samma anslutning. Det här är en teknik som man traditionellt sällan vågat använda inom OT-världen eftersom alla tillgängliga lösningar varit fokuserade på IT-världens förutsättningar. Som OT-person skall det till ganska mycket innan man vågar stoppa in säkerhetsåtgärder som skulle kunna påverka viktig kommunikation. Nu kan man våga det! Du kan direkt se att brandväggen och den lilla IPS:en fysiskt är helt inriktade på OT-marknaden. Det är två smidiga men ordentligt ruggade produkter med rejäla kylflänsar som gör att de kan monteras ute i anläggningen på DIN-skena eller vägg, körs på 12-48 Volt med möjlighet till redundant matning, de fungerar mellan -40 ˚C och 75 ˚C och har MTBF på över 700 000 timmar! IPS:en har hårdvaru-bypass för att inte störa verksamheten även om den skulle gå sönder. (Läs mer om detta i nyhetsbrev 20.) Jag gillar verkligen den massiva känslan som dessa små enheter ger i handen! IPS:en är bara 4x7x8 cm vilket gör det lätt att få plats i trånga apparatskåp! Trots det minimala formatet är den specad för att kunna hantera minst 200 Mb/s med full IPS-funktionalitet. Numera finns även ett par storasyskon till IPS:en. Som du kanske minns från nyhetsbrev 17 finns det en monsterversion där man stoppat in 24 respektive 48 enheter i ett rackmonterat chassi och kryddat med ännu mera funktionalitet. Nu snackar vi totalt 20 Gb/s med IPS påslaget! Den här manicken är ju som synes inte tänkt att sitta ute i ett apparatskåp någonstans utan ska placeras i ett nätverksrum eller en datorhall, men i övrigt är den helt fokuserad på OT-världens förutsättningar! Man ska inte underskatta den lilla IPS-enheten på grund av dess format, exempelvis har den riktigt imponerande brandväggsfunktionalitet för OT-protokoll! Vill man exempelvis begränsa vissa Modbus-klienter till att bara kunna göra läs-operation så gör man enkelt det. Vill du gå riktigt bananas kan du styra åtkomst ner på Coil-nivå i Modbus eller på individuella Service Codes i CIP! Idag har man protokoll-medveten filtrering för Modbus, CIP, S7Comm, Profinet, SLMP, MELSOFT, SECS/GEM och TOYOPUC men det verkar komma nya protokoll hela tiden. De stora IPS:erna har jag inte haft möjlighet att titta på ännu så där tänkte jag återkomma i ett framtida nyhetsbrev. Brandväggen har samma funktioner som den lilla IPS:en förutom att den saknar hårdvaru-bypass, men den tillför istället en rad andra funktioner. Intressant är att man kan välja att köra den som en layer 3 enhet, dvs som en traditionell gateway, eller som en brygga på layer 2 vilket gör att den likt IPS:en blir en "bump-in-the-wire" fast då med en inbyggd switch och fler anslutningar. Den har SFP-anslutning och kan därför också anslutas direkt med fiber. Om man använder den som gateway har den alla grundläggande funktioner man kan förvänta sig av en sådan, exempelvis NAT, port mapping samt porthantering för FTP/SIP/H.323. Man får stor frihet i hanteringen av NAT om man behöver mer än den automatiska funktionen, det finns stöd för både översättningsregler och klassisk port forwarding. Hur ser IPS-skyddet och den virtuella patchningen ut då? Det är ju ändå de viktigaste funktionerna för den här typen av utrustning! Svaret är helt enkelt att jag tycker det ser riktigt bra ut. Här märker man släktskapet med de stora TippingPoint-IPSerna från Trend Micro. På bilden ser du exempelvis profiler för skyddet mot Ripple20 som var en av många läskiga fel som upptäcktes i TCP/IP-stackar under 2020. Positivt är också att riktigt gamla sårbarheter adresseras eftersom det inte är helt ovanligt med äldre utrustning i OT-miljöer... Alla attack-profiler kommer med en föreslagen åtgärd men du kan alltid välja en annan om du vill. Några stickprov bekräftar att man hittar skydd mot en massa viktiga sårbarheter i Windows och Linux, jag såg exempelvis Zerologon, EternalBlue och ShellShock men även sårbarheter i underliggande applikationer som man kanske inte alltid är medveten om att man kör: Apache Struts och PHP. Det finns också skydd mot generella attacker såsom brute-force mot RDP, POP3 eller Webtjänster. I mitt exempel här intill har jag testat IPS-funktionen med hjälp av EternalBlue-attacken känd från WannaCry, NotPetya, Shadow Brokers och Equation Group. Det är en radda riktigt otrevliga sårbarheter i SMB-protokollet från Windows-världen. Som synes är det inga problem att identifiera attacken och om IPS:en körs i blockeringsläge så stoppas attacken direkt. Men även om man väljer att enbart köra detektering är det mycket värt att få reda på när sånt här dyker upp kring dina OT-system! Något som jag tycker är väldigt viktigt om jag ska lita på den här typen av säkerhets-system i viktiga produktionsmiljöer är att jag kan hantera uppdateringar på ett kvalitetssäkrat och styrt sätt. Typiskt vill man kanske automatiskt uppdatera signaturer på vissa enheter men bestämma själv på andra? Här kan du exempelvis skapa en grupp för testenheter och en annan för produktionsenheter. På produktions-gruppen väljer du själv vilken version som ska användas på alla system i den gruppen medan testgruppen alltid uppdateras efter hand som nya version dyker upp. System kan flyttas enkelt mellan de två grupperna. För varje grupp kan du dessutom välja om skydden ska vara aktiva eller bara logga angrepp - perfekt när man vill bekräfta att normal trafik inte blockeras av misstag. Riktigt smidigt och elegant! Man får bra statistik om de trafiktyper som rör sig på nätet och vilka system som "pratar", vilket ger en bra förståelse för vad som faktiskt finns där. Normalt sett kan de här enheterna bara agera på den nätverkstrafik som passerar dem. Om man vill ha mer information om vilka system som finns på nätverket kan man slå det som TxOne kallar "Active Query". Då kommer aktiva, men försiktiga, frågor ställas på nätet för att fråga alla system om deras status, i nuvarande version stöds Modbus, CIP, FINS och SMB. Ett snyggt och praktiskt sätt att även kunna hitta system som inte är så "pratiga". All administration kan ske lokalt på varje enhet men om du har många så blir det snabbt enklare att använda administrationskonsolen "OT Defense Console". Jag tycker den är väldigt lättjobbad med ungefär samma upplägg som de flesta konsolverktyg för brandväggar och IPS:er. Lite speciellt är att man fokuserat på att göra det enkelt att administrera många IPS:er med samma konfiguration genom möjligheten att skapa konfigurationsgrupper. Elegant och snyggt! All hantering av uppdateringar och uppgraderingar sker i konsolen, både för konsolen själv, firmware till alla enheter, IPS-signaturer och DPI-signaturer. Har du inte Internetaccess från konsolen så laddar du upp uppdateringsfiler i konsolen och skickar ut dem därifrån. Om man absolut vill finns alltid möjligheten till lokal administration kvar direkt på varje system. Konsolen är en virtuell appliance som du kör i VMware eller KVM. Den är enkel att installera och få igång. Jag fick nyligen tillfälle att göra en uppgradering av administrationskonsolen vilket ju kan vara lite klurigt i vissa säkerhets-system. Uppgraderingen i mitt OT-labb var väldigt enkel och till min glädje dök ett antal nya funktioner upp som löste de svagheter som jag såg i den tidigare versionen, exempelvis stöd för inloggning via TACACS+, multipla syslogservrar, SNMP traps och bättre filtrering av SMB. Använder man Pro-versionen av IPS:en får man en snygg möjlighet till automatisk inspelning av nätverkstrafiken vid händelser. Om TxOne fortsätter att lägga till vass funktionalitet i den här takten kommer de vara ostoppbara! Även om konsolen har stöd för inloggning baserat på TACACS+ så finns även en smidig inbyggd användarhantering. Konsolen har ovanligt bra inbyggt skydd av administratörernas inloggningar genom att både kunna sätta krav på lösenordskvalitet och inbyggt skydd mot bruteforce-attacker. Stöd för att skapa roller och grupper saknas men det gör inte så mycket eftersom man har fyra nivåer av användartyper att välja mellan (admin, operator, auditor och viewer) kombinerat med att man istället skapar grupper av de enheter som administreras och som tilldelas till olika användare. Ett smidigt upplägg som fungerar bra i praktiken. Edge-serien från TxOne ger oss en möjlighet att börja adressera problematiken som brukar kallas "insecure by design", alltså faktumet att det inte räcker att vara duktig på att uppdatera våra system eftersom nästan alla OT-system bygger på i grunden osäkra nätverksprotokoll. Så länge inte tekniken förändras helt måste vi kombinera god underhållshygien med klassisk nätverkssegmentering och zon-indelning. Edge-produkterna från TxOne hjälper oss med både segmentering och virtuella uppdateringar, till och med där det inte finns några uppdateringar att få från leverantören! Min högst personliga syn på Edge-serien från TxOne är att man faktiskt lyckats ta det bästa från en IT-leverantör och kombinera det med det bästa från en OT-leverantör i en gemensam produktserie! Man får en lösning som IT-folket känner igen sig i men som samtidigt kan ge OT-folket den känsla av trygghet som behövs för att våga stoppa in säkerhetslösningar i OT-miljön. NIS2 igen... Jag skrev i nyhetsbrev 21 om förslaget till om ett rejält utökat NIS-direktiv som lades fram strax innan jul. Jag noterar att det fortfarande är ganska tyst om detta i media vilket förvånar mig lite. Visst är det bara ett förslag än så länge men det är å andra sidan ganska brutala tillägg som föreslås kring både vilka verksamheter som omfattas, tillsynsmyndigheternas möjlighet till sanktioner och inte minst i höjda kravnivåer. Hittills har jag mest sett analyser från olika jurist-byråer som inte tillför så mycket utöver en ren sammanfattning av det massiva materialet. Jag har pratat med personer som arbetar med NIS-tillsyn på några av de myndigheter som har detta uppdrag idag. Där är det fortfarande för nytt för att de ska dra några stora slutsatser men några gemensamma drag ser man i det man reagerar över: En rejäl utökning av de branscher som omfattas där det som kanske sticker ut mest är ganska många tillverkande industrier. Det talas om myndighetstillsyn och rejält utökad möjlighet att utdöma böter i samma storleksordning som i GDPR. (10 MEUR eller 2% av total omsättning) En anmärkningsvärd punkt är att tillsynsmyndigheter ska ha mandat att tillfälligt förhindra ansvariga personer att verka i verksamhetens ledning om de misslyckats åtgärda förlägganden på ett effektivt sätt. Det är egentligen två direktiv som lagts fram, NIS2 och CER - "Directive on the resilience of critical entities". Båda ingår i den strategi för EUs Cybersäkerhet som lades fram samtidigt. Det är alltså en mycket komplex bild att tolka för att se helheten. NIS2 fokuserar främst på Cybersäkerhet medan CER går ett par steg till och ställer krav på verksamheten i sig. Det talas om krav på riskanalyser och samverkan. Krav på utbildning av ledningen för att kunna förstå risker och utmaningar kopplat till Cybersäkerhet. Krav på riskanalyser och säkerhetspolicies Krav på incidenthantering, både förebyggande och hanterande Krav på kontinuitetsplanering och krishantering, inte bara för IT/OT - utan för verksamheten Krav på säkerhet kopplat till leverantörer, upphandling, utveckling, underhåll och sårbarhetshantering Krav på mätning och kontroll av säkerhetsåtgärdernas effektivitet Krav på användning av kryptografi. Krav på rapportering av hot och sårbarheter även om de inte ledde till skada Krav på samordnad rapportering och hantering av sårbarheter inom både länder och EU-gemensamt. Jag är väldigt nyfiken på att höra vad mina läsare har för tankar kring förslaget! Hör av dig eller kommentera nyhetsbrevets inlägg på LinkedIn! Om du själv vill dyka ner i EUs texter så får du några pekare av mig här: Allmän information: https://ec.europa.eu/digital-single-market/en/news/proposal-directive-measures-high-common-level-cybersecurity-across-union Det här är den juridiska texten: https://ec.europa.eu/newsroom/dae/document.cfm?doc_id=72166 Några spännande exempel från innehållet: Sanktioner i samma storleksordning som GDPR: 10 MEUR eller 2% av total omsättning (Article 31, sid 56) Tillsynsmyndigheter ska ha mandat att tillfälligt förhindra ansvariga personer att verka i verksamhetens ledning om de misslyckats åtgärda förlägganden på ett effektivt sätt (Article 29, punkt 5b, sid 54) Krav på utbildning av ledningen för att kunna förstå risker och utmaningar kopplat till Cybersäkerhet (Article 17, punkt 2, sid 45) Krav på en massa annat: riskanalyser, säkerhetspolicies, incidenthantering, kontinuitetsplanering, krishantering, leverantörssäkerhet, mätning av säkerhetsarbetets effektivitet, sårbarhetsrapportering även om inte incidenter uppstår osv Small- och micro-verksamheter kan vara undantagna. (Article 2, punkt 1, sid 30) Definitionerna hittar du här: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2003:124:0036:0041:EN:PDF Micro: <10 anställda och omsättning < 2 MEUR (Se Annex, Article 2, sidan 39) Small: <50 anställda och omsättning < 10 MEUR Annex I, II & III: https://ec.europa.eu/newsroom/dae/document.cfm?doc_id=72172 Innehåller lista över de berörda verksamhetsområdena. Annex I listar ”Essential entities”, exempelvis: Fjärrvärme: punkt 1b (Sidan 2) Refererar till definitioner som finns här: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2018.328.01.0082.01.ENG Gasproduktion punkt 1d (Sidan 2) Refererar till definitioner som finns här: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32009L0073 (Här finns också texter som jämställer biogas med naturgas för dessa regler.) Annex II listar ”Important entities”, exempelvis: Avfallshantering: punkt 2 (Sidan 9) Refererar till definitioner som finns här: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A32008L0098 Att gå över gränsen utan att göra sig illa... Brittiska NCSC (National Cyber Security Center) producerar ständigt material med riktig hög kvalitet. Häromdagen släppte de "Security principles for cross domain solutions" där de delar med sig av klokskap hur man för över information mellan två nätverk som har olika säkerhetsförutsättningar. Jag var inne på den här typen av lösningar i slutet av min artikel om Advenicas nätverksdiod i förra nyhetsbrevet. Som vanligt levererar NCSC insikter på ett sätt som går att använda direkt. Vad är detta? Vem behöver det? Vad är viktigt? Vilka risker tas omhand och vilka nya risker kan uppstå? Hur implementerar man sådana här funktioner? Som jag var inne på sist är det här riktigt kraftfulla lösningar som passar väldigt bra för OT-världen där man ofta vill ha riktigt bra koll på gränsytor och kommunikation med omvärlden. Tiden när vi kunde hävda att vi hade luftgap mellan IT och OT är sedan länge över för de flesta. På samma sätt är tiden förbi när man kunde peka på sin brandvägg och hävda att den tar hand om hoten. Nu krävs en kombination av innehållsstyrning och övervakning av trafiken i känsliga övergångar mellan olika miljöer! Klokskap från FOI David Lindahl på FOI (Totalförsvarets forskningsinstitut) är en annan pålitlig producent av kvalitetsmaterial. Strax före jul släpptes "Omvärldsbevakning statsattribuerade cyberoperationer 2020" som är väl värt att läsa för den som arbetar med riskanalyser eller säkerhetsåtgärder i känsliga miljöer. David ger oss sina reflektioner kring vad som fungerar angreppsmässigt och varför vissa grupper beter sig som de gör. För oss som intresserar oss för OT-Säkerhet finns några exempel på angrepp mot "Styrsystem" som David kallar det. Använder du OPC? Se upp! Claroty släppte nyligen mer information om ett antal riktigt allvarliga sårbarheter i flera leverantörers OPC-produkter. Vi har tidigare sett annonseringen från respektive leverantör om viktiga uppdateringar och nu ger Claroty hela bilden. Det gäller produkter från Softing, Kepware PTC och Matrikon som berör både OPC DA och OPC UA. Alla tre är välkända leverantörer för de som använder OPC och problemen gäller en hel rad produkter från dessa leverantörer. Mer detaljer hittar du i Clarotys annonsering och hos respektive leverantör. Det finns också en hel del analyser i media, exempelvis hos DarkReading och SecurityWeek. Med tanke på hur viktigt OPC oftast är för de verksamheter som använder det kombinerat med hur lätt de flesta av sårbarheterna är att utnyttja är situationen onekligen allvarlig. Kanske speciellt för OPC UA som ju annars betraktas som säkrare än OPC DA och därmed kan vara mer exponerad i nätverken. Den här typen av produkter tenderar ibland också att bli lite bortglömd när det gäller patchbevakning. Nu är det dags att uppdatera! De där leverantörerna alltså... Joe Weiss levererade i mitten av Januari en bra reflektion över de två största (i alla fall ur ett amerikanskt perspektiv) OT-säkerhetshändelserna under 2020: Solarwinds-hacket och upptäckta bakdörrar i transformatorer för det amerikanska stamnätet. Han ondgör sig över att säkerhets-branschen sprungit åt fel håll och att vi som grupp ignorerar behovet av att arbeta med säkerhet närmare den fysiska processen. Diskussionen om attacker via leverantörskedjan blir förstås ännu mer tillspetsad när man kommer till angrepp som levereras med hjälp av leverantören! Tänkvärda ord om ett riktigt svårt problem! Rekommenderad läsning... Dale Peterson resonerar kring en rapport som förutsäger hur många kända sårbarheter som kommer att dyka upp under 2021 och vad resursbehovet som följer av det betyder för vår förmåga att hänga med i det eviga patchandet? En av mina nyupptäckta idoler, Jonas Berge, skrev i höstas en artikel om standarder i OT-världen. Han gör många intressanta poänger men kretsar hela tiden kring OPC-UA som ju verkligen håller på att bli en standard på riktigt! Men han väver också in jämförelser med standarder i IT-världen, buss-protokoll, filformat och framför allt NAMUR Open Archtecture (NOA). Inget av detta har något specifikt med säkerhet att göra samtidigt som den standardisering vi kan uppnå med OPC-UA i kombination med kloka design-principer i stil med NOA gör det möjligt att bygga säkra miljöer. Det är ju trots allt faktiskt så att det är kring integrationer som de flesta sårbarheter uppstår! En riktigt intressant artikel från "Air & Space Magazine" om hackning av kritiska system i flygplan. En rapport om ett antal riktigt otrevliga sårbarheter i en WiFi-modul från RealTek som bland annat sägs vara vanlig inom industriella tillämpningar. Sårbarheterna är möjliga att utnyttja på distans över WiFi utan att ha tillgång till kryptonycklar eller annan autentisering! Jag har inte sett någon sammanställning från systemleverantörer ännu men det låter riktigt allvarligt! Ett bra White Paper från IIC, Industrial Internet Consortium, som reder ut begrepp och utmaningar kring Edge computing. En nygammal attack mot ett osupportat operativsystem, Windows 7, som de flesta av oss fortfarande använder... Energimyndigheten gav nyligen ut föreskrifter och allmänna råd, STEMFS 2021:3, kopplat till NIS-direktivet där man ställer krav och ger råd för bland annat OT-system. Det här nyhetsbrevet skickas till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se .

Den här gången längtar jag efter NIS2, tittar på MITRE Engenuity, kombinerar ISO 27001 med ISA 62443, läser på om Pålitlighet, granskar känsliga dataöverföringar med Python, tittar på NISTs CSF-profil för tillverkande industri, kommunicerar fältnära med OPC UA och tycker till om Purdue-modellens betydelse för hur vi bygger våra nätverk. 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. 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 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! Hur går det för NIS2? Vi är många som är nyfikna på hur det kommer att gå med det förslag till helt nytt NIS-direktiv som lades fram i julas. (Jag har skrivit om detta tidigare i Nyhetsbrev #21 och #23.) "Snacket på stan" sade att någonting skulle komma ut under Juli men än så länge har i alla fall jag inte sett eller hört något konkret. Det är inte helt trivialt att navigera EUs enorma informationsmängder och när man väl hittar ett intressant dokument är de sällan enkla att läsa heller... Ett intressant brev från Europakommissionen till Europaparlamentet och Europeiska rådet berättar att man fick in 121 åsikter kring förslaget. Det senaste och viktigaste livstecknet som jag hittar är ett utkast till en sammanställning från Europaparlamentet på 59 sidor utgiven den femte maj med förslag till ändringar och tillägg. En snabb genomläsning gav inga revolutionerande intryck men ändå några intressanta, och i mitt tycke riktigt vettiga, förslag till ändringar: Rapportering av säkerhetshändelser och hot som inte leder till en incident ska inte omfattas av rapporteringskravet. (Det hade blivit tufft att hantera den volymen...) Man får 72 timmar (istället för 24) på sig att rapportera säkerhetshändelser. (Väldigt klokt!) Man trycker på att det är lite för mycket fokus på krav och straff. Myndigheterna bör också ta en stöttande och uppmuntrande roll. (Wow!) Man trycker på att det är viktigt att undvika överlappande tillsyn från flera myndigheter. (Av praktisk erfarenhet håller jag definitivt med!) Root-servrarna i DNS undantas eftersom de sällan drivs av monetära syften. (Inte säker på att jag tycker detta är så smart...) Man vill se lagligt stöd för mer samarbete mellan polis och förebyggande myndigheter. (Jaaaa!!!) Det ursprungliga förslaget sa att ENISA skulle sätta upp en egen EU-motsvarighet till CVE-databasen för sårbarheter. Det tonas ner nu! (Otroligt vettigt!) Den som väntar på något gott... Det kan komma mer nyheter vilken dag som helst nu och det kan förstås visa sig att det vi trott så här långt är helt fel. Än så länge har i alla fall inte jag sett något som tyder på att NIS2 är på väg att köra i diket eller drabbas av några större ändringar på rakan fram mot målet... Vi håller tummarna! Vet du mer får du väldigt gärna höra av dig! MITRE Engenuity levererar! Vi har fått den första leveransen från MITRE Engenuity! MITRE är ju annars känt för ATT&CK-ramverken och har via Engenuity börjat samarbeta med leverantörer av säkerhetsprodukter för att utvärdera dem gentemot ramverken baserat på verkliga incidenter. Tanken är att ge potentiella kunder möjlighet att jämföra var de olika leverantörernas styrkor och svagheter ligger. Det är definitivt ett intressant grepp. Ett antal leverantörer deltar i ett simulerat angrepp och hur väl deras produkter hanterar angreppet redovisas med hjälp av MITRE ATT&CK. Den här gången var testerna en kopia av TRITON-angreppen mot en Saudiskt petrokemisk anläggning 2017. (Det som var skrämmande med TRITON var att det siktade in sig på skydds-systemen, SIS, på anläggningen, vilket bara kan ha ett mål, nämligen att skada anläggningen och människorna där fysiskt.) Det är första gången man gör det här för OT-produkter med hjälp av MITRE ATT&CK for Industrial Control Systems. Fem deltagare fanns med; Claroty, Armis, Microsoft, Dragos och "the Institute for Information Industry". Den sistnämnda är en Taiwanesisk organisation som åtminstone jag aldrig hört talas om förut. Om du är på väg att välja ett verktyg i den här vansinnigt viktiga kategorin är testresultaten definitivt en pusselbit i utvärderingen. Det är ju definitivt inte någon heltäckande test men det ger ändå hintar om hur respektive lösning beter sig. På köpet kan man få lite mer insyn i nyttan med MITRE ATT&CK även om jag personligen kan tycka att man inte nådde ända fram när det gäller att underlätta jämförelser. Men där tycker man kanske olika? I vilket fall ska det bli spännande att se vad kommande tester resulterar i och om fler leverantörer hoppar på tåget! Det kan inte hända - det har ju aldrig hänt förut! Ett klassiskt mothugg som ofta dyker upp när man behöver resurser för säkerhetsarbete är argumentet "Är det verkligen vettigt? Det har ju aldrig hänt!". Samma sak när man är kreativ i en riskworkshop och kommer med händelser som lite utöver det vanliga... Jag undrar om argumentet att det inte hänt förut börjar kännas lite tunnare nu? Vi har kommit halvvägs genom 2021 och har redan sett ett antal riktigt smaskiga händelser som aldrig hänt förut. En av de största svenska livsmedelskedjorna stod still. Amerikanska östkusten hade inte tillräckligt med olje-produkter. Viktiga system i Irländska sjukvården stod still i över en månad. Minst ett stort försäkringsbolag har slutat ersätta ransomware-utbetalningar. Inget av detta har hänt förut! Som vanligt är problemet att man inte kan bedöma sannolikheten för saker som inte hänt förut. Budskapet att man för riktigt allvarliga händelser bara behöver bedöma om det KAN hända kan du ta del av i Richard Clarkes keynote från S4x17 där har sätter fingret på problemet med ett antal fantastiska poänger! Tre godbitar från Industrial Internet Consortium Vännerna på IIC verkade vilja jobba klart innan det blev semester. De producerade nämligen tre intressanta texter på kort tid... Godbit nummer ett! Det mest intressanta i mina ögon är ett white-paper med titeln "The Industrial Internet of Things Trustworthiness Framework Foundations". Det handlar alltså om "Trustworthiness", vilket i det här sammanhanget jag föredrar att översätta med "Pålitlighet". Det är en rejäl genomgång av begreppet som de definierar så här: Riktigt intressant för oss OT-människor! De hänger upp resonemanget på just Safety, Security, Privacy, Reliability och Resilience. (Jag låter bli att översätta dessa begrepp eftersom det oundvikligen förändrar betydelsen av orden.) De tar oss genom ett långt men tydligt resonemang där de definierar värdefulla principer kring synsätt, värderingar, ledarskap, metoder och arbetssätt på vägen. Ibland blir det kanske lite väl akademiskt men det finns gott om guldklimpar att ta till vara för den egna organisationen! Godbit nummer två! Nästa godbit heter "Global Industry Standards for Industrial IoT" som dels gör en rejäl genomgång av hur standarder skapas och hur de bäst används för IIoT och OT. Men de ger oss också en lång lista över relevanta organisationer som sysslar med standarder på det här området där vi bland annat hittar välkända namn som DIN, IEC, IEEE, IETF, ISA, ISO och OPC Foundation. Vi får också en lista över intressanta samarbetsorganisationer där kända namn som NAMUR, IIC, PI4.0 och ZVEI blandas med för mig okända grupper. ...och nummer tre! IIC annonserade också "IIC Patterns Initiative" som är en öppen databas med arkitektur-principer för IIoT och OT. Den innehåller bara ett fåtal än så länge men tanken är att vem som helst får dela med sig av sin bästa idé. Om det tar skruv kan det här bli riktigt intressant, inte minst på grund av att det är en öppen resurs! Plus en bonus! Dessutom kom en utgåva av "The Industrial Internet Consortium's Journal of Innovation" som fokuserade på Edge. De finns många åsikter om vart relationen mellan OT och "molnet" är på väg men oavsett vad man tycker så är det intressant! 27001 + 62443 = 89444? En av mina ständiga käpphästar när jag är ute och föreläser om OT-säkerhet är att man inte ska välja fel standard till sitt ledningssystem. ISO 27001 är defacto-standarden för informationssäkerhet och ISA 62443 är motsvarigheten för OT-säkerhet. Försök INTE använda dem för något annat! Jag har sett tråkiga exempel på när välmenande människor, i synnerhet de som älskar 27001, försöker vränga till tolkningen av 27001 på ett sätt som ska passa OT-världen. Det blir inte bra! Men! Det finns ingenting som hindrar att man kombinerar de båda. Tvärt om är det bra. Integrerade ledningssystem är ju ingenting nytt, många organisationer kombinerar utan problem standarder som ISO 9001, ISO 14001, ISO 45001 och ISO 20000. Att lägga till ISO 27001 och ISA 62443 bör inte vara något jätteproblem för de flesta. Och man behöver ju inte certifiera sin organisation bara för att man lutar sig mot standarder. Men vad ska man tänka på då? Den frågan försöker ISA svara på nu med ett sprillans nytt översiktsdokument. Riktigt bra kan jag tycka även om det är lite tunt och inte går in på detaljer. Men de pekar på en radda intressanta saker och det är en bra början! En utmaning som ISA inte tar upp är att vi inte är så många ännu som kan båda standarderna. Även om man inte behöver vara expert så vill det ju till att man har tillräcklig koll för att knyta ihop dem. I takt med att intresset för 62443 nu ökar kommer det nog lösa sig automatiskt... Att röra sig mellan domäner... Jag har nyligen haft möjlighet att sätta fingrarna på en ZoneGuard från svenska Advenica och tänkte passa på att skriva några rader om den för att dela med mig av mina intryck. Jag skrev om en kusin till ZoneGuard i Nyhetsbrev #22, nätverksdioden DD1000i, som är en nätverksbrygga där man använder fysikens lagar för att säkerställa att information bara kan skickas åt ett håll. Dioder används exempelvis för att föra ut loggar från säkra nät utan att riskera att nätverkskopplingen används "åt andra hållet". En ZoneGuard är också tänkt att koppla samman nätverk som har skilda säkerhetskrav utan att de påverkar varandra. Till skillnad från dioden kan man med en ZoneGuard skicka information åt båda håll, istället tittar man på informationen som överförs och ser till att de protokoll som används inte kan missbrukas. Lite som en brandvägg men med väldigt mycket mer kontroll över vad som är okej. Man brukar prata om CDS, "Cross Domain Solution", alltså att man kommunicerar mellan säkerhetsdomäner. En "vanlig" brandvägg inspekterar trafiken och skickar den vidare utan ändring. I en ZoneGuard bryter man sönder protokollet helt, plockar ut informationen som ska överföras och kastar sedan nätverkspaketen. Sedan applicerar man regler och filter på själva innehållet och bygger sedan ihop helt nya nätverkspaket. Angrepp som utnyttjar felformatterade nätverkspaket har alltså inte en chans! ZoneGuard har stöd för en rad protokoll och format. Det finns också väldigt bra stöd för organisationens egna utvecklare att anpassa stödet till de egna kraven. Det här är en väldigt spännande produkt för OT-verksamheter eftersom integrationen mellan IT och OT är helt avgörande för både organisationens effektivitet och dess säkerhet! Nätverksmässigt är det enkelt men smart utformat. En nätverksanslutning till respektive nätverk (Röd och Blå i bilden), en separat anslutning för administration (Grön) och en för loggning (Svart). Du behöver alltså inte blanda data, administration och loggning på samma nätverk vilket kan vara avgörande för vissa verksamheter. Om man tittar på vad som händer under huven tycker jag den här bilden förklarar hur det hänger ihop. Jag använder RDP, "Remote Desktop Protocol", som exempel i resonemanget. Ett klientsystem ansluter från vänster i bilden till "Data 1". Kommunikationen transformeras i en service där innehållet plockas ut och läggs i en datastruktur, i vårt fall är det händelser i RDP, dvs tangentbordstryckningar, musförflyttningar och liknande. Datastrukturen skickas vidare till validering via en jämförelse mot ett schema där det säkerställs att alla strukturer och datatyper är korrekta. Ska det exempelvis vara en siffra så kollas det. Ska det vara en bitmap så kollas det. Det är i validerings-steget i mitten av bilden som den verkliga magin händer! Där definierar vi vår policy för vad som är ok att göra via RDP. Om informationen godkänns (eventuellt efter att ha modifierats) så kollas resultatet igen mot ett schema och lämnas över till en service som bygger ihop RDP-trafik och skickar den vidare till RDP-servern. All trafik som går åt andra hållet kollas på motsvarande sätt. Och så håller det på! I och med att bara innehållet i trafiken hanteras blir det väldigt osannolikt att någon av de riktigt allvarliga säkerhetshål som funnits i RDP går att utnyttja och man får dessutom möjlighet att styra exakt vad som går att göra på skärmen! Nät det gäller policy-filtren har Advenica gjort ett verkligt genidrag! De filter som implementerar policyn är nämligen Python-script! All information som ska granskas är tillgänglig i ett enkelt API. Du kan bygga precis vilken logik du vill! Det är här som den stora skillnaden mot klassiska brandväggar blir tydlig! Lite mer komplext att sätta upp förstås men oerhört kraftfullt! I vårt RDP-exempel vill vi kanske inte tillåta att man rör muspekaren var som helst på skärmen, inte tillåta vilka tangenttryckningar som helst eller maskera delar av bilden? Kanske bara titta utan att påverka? Skriv bara regler för de händelser du vill ändra, godkänna eller ta bort! Förutom RDP finns stöd för Syslog, NTP, FTP, SFTP, NFS, SMB, SMTP, POP3, HTTP, HTTPS, SOAP och MySQL. Dessutom finns ett generellt stöd för TCP och UDP som gör att du kan skapa egna tjänster. ZoneGuard finns också som mjukvaruprodukt också om du hellre kör en virtuell lösning. Det här är ett riktigt snyggt sätt att styra upp känslig kommunikation som jag personligen tycker fler verksamheter skulle överväga. Som vanligt när det gäller Advenica är dokumentationen riktigt bra och ger riktigt bra stöd kring både uppsättning, drift, säkerhetsrutiner och utveckling av policies och services. Om man inte ska göra någonting allt för komplext är man relativt snabbt igång även om policy-delen förstås kräver lite mer arbete jämfört med en brandvägg eller en nätverksdiod. Hur ska vi skära OT-kakan? Ett område som debatteras flitigt är relationen mellan Purdue-modellen (ISA 95) och hur man bygger nätverk. Och hur rimmar det med tankarna i ISA 62443? Jag inbillar mig inte att jag har något facit men här är mina spontana tankar kring detta: (och säg gärna emot mig!) Den ursprungliga Purdue-modellen (och ISA 95) skapades inte för att underlätta för vare sig nätverksbyggare eller säkerhetsfolk. Det är ett sätt att organisera system i en komplex verksamhet så att det går att förstå strukturen och hålla liv i verksamheten. I och med att vi nu i många år byggt våra system baserat på Purdue och ISA 95 så har det trots allt varit ganska naturligt att nätverk och annan kommunikation följer nivåerna i modellen. I och med att krav på skydd och tillgänglighet dessutom också ofta följer nivåerna blir det snyggt. ISA 62443 bryr sig inte om nivåerna från ISA 95 och Purdue men den säger å andra sidan inte direkt att det är fel heller. I 62443 bygger man sin kommunikation baserat på "Zones" och "Conduits" som i sin tur bygger på systemens faktiska kommunikationsbehov, utsatthet och säkerhetskrav. Dessa Zones och Conduits kan både återspeglas fysiskt i nätverksstrukturen eller genom andra, logiska, strukturer. I och med digitaliseringen, och i synnerhet mer extrema tankar som "Industri 4.0", har det blivit tydligt att en rent lagerbaserad kommunikation som inspirerats av Purdue-modellen inte fungerar längre. Det gamla traditionella tänket att hoppa mellan intillliggande nivåer dödar effektivt alla möjligheter till molnbaserade lösningar men skapar också en tröghet som motverkar många potentiella framsteg. För att nå idealen i Industri 4.0 utan att bryta mot tankarna i ISA 62443 har det uppstått riktigt eleganta arkitektur-ramverk. Där använder man enbart "Zones" och "Conduits" men man gör det på det sätt som var tänkt i 62443 utan att färgas av traditioner från Purdue. Min personliga favorit på området är NOA, "Namur Open Architecture" som du kan läsa mer om i Nyhetsbrev #27 och #30. I slutändan handlar det precis som vanligt om riskanalyser och bedömningar. Bedömningarna ska förstås inte bara handla om säkerhet utan också hur den nätverksstruktur vi skapar går att underhålla och byta ut över tid. Att skära kakan med OPC UA... Peter Lutz och ISA ger oss en riktigt intressant artikel kring planerna framåt för fältnära kommunikation med OPC UA. Det här är ganska långt från att vara min personliga specialitet men det är väldigt intressant att se hur våra möjligheter att framöver kunna "styra upp" kommunikation kommer att påverkas. Det finns ju en tydlig koppling till den föregående artikeln om Purdue och Zones&Conduit när man ser att den inre strukturen i pyramiden suddas ut. Tankarna far dessutom mot "Zero Trust" eftersom varje enhet kommer få ta ett större ansvar i att försvara sig själv när man börjar prata med fler enheter istället för med enstaka centrala punkter. Som Peter också tar upp blir en väldigt intressant koppling till nyare underliggande tekniker som 5G, TSN och APL. Som en naturlig konsekvens av att de enhetliga kommunikationsvägarna suddas ut förstärks ytterligare behovet av att ha riktigt bra insyn i vad som händer på nätverket. Egentligen är väl redan analyslösningar i stil med Guardian från Nozomi nödvändiga men i den här framtida världen kommer man inte ha en chans utan dem. Det här kommer nog också ytterligare öka intresset för processnära skydd i stil med TxOnes EdgeIPS för att skapa fältnära utrustning som kan försvara sig själv. Lite mer från NIST Det här är sjätte delen i min serie om standarder och ramverk. Första avsnittet i nyhetsbrev #26 handlade om ISA/IEC 62443 och i nyhetsbrev #27 tittar jag på NAMUR NOA. I nyhetsbrev #28 var NIST CSF, NIST 800-53 och NIST 800-82 huvudattraktionen men du fick också lite mer om NOA som en bonus. I nyhetsbrev #29 tittade jag på den nya versionen av CIS Controls och i nyhetsbrev #30 . Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig! När jag skrev om NIST-dokumenten missade jag ju att nämna ett dokument som är intressant för oss OT-människor! Jag tänker på "Cybersecurity Framework Manufacturing Profile" som är ett exempel på det NIST CSF kallar "profiler", dvs en anpassning av CSF till en viss bransch eller verksamhet. I det här fallet är det tillverkande industri även om det går att återanvända för andra besläktade branscher. Det man gjort är helt enkelt att man valt ut de viktigaste åtgärderna i CSF för tillverkande industrier och kombinerat dem med en riskmodell i tre steg (Low/Medium/High) för att sedan beskriva vad som behöver göras i respektive kombination av dessa. Som exempel kan vi ta denna ganska korthuggna punkt om loggning i CSF-dokumentet: ...som i Manufacturing Profile istället ser ut så här: Som synes får vi mer hjälp direkt i tabellen. Man har också städat upp referenserna till att bara peka på de två relevanta delarna i 62443 och dessutom mer detaljer kring var i NIST SP 800-53 man ska titta vidare. Det här är förstås inte svaret på alla frågor och det är inte säkert att du kan använda allting rakt av i din egen verksamhet men det är en riktigt bra startpunkt om du vill arbeta med NIST. Dokumentet uppdaterades senast 2019 så det är fortfarande någorlunda relevant. Tips om event och mer läsning! Den 26:e Augusti går årets Xday av stapeln. Jag är en av talarna under rubriken "Stå stadigt med säker OT". Exakt vad jag kommer prata om får ni höra om ni är med! Skynda att anmäla dig! https://resources.trendmicro.com/Xday2021.html Den 28 September är jag med på årets upplaga av CyberNorth under rubriken "Den mänskliga sidan av OT-säkerhet". CyberNorth organiseras av Luleå Tekniska Universitet och beskrivs så här: "Cyber North — ett i särklass informativt event för säker hantering av risk. Fokuset på CyberNorth adresserar de utmaningar som finns kopplat till digitalisering inom processindustrin och särskilt kopplat till Cyber/informationssäkerhet." Glöm inte anmäla dig! Du missade väl inte de två nyhetsbrev jag släppt tidigare under sommaren? Nummer #30 och #31. En detaljerad genomgång av de potentiella säkerhetsriskerna med privata 4G/5G-nät för industriella miljöer gjord av Trend Micro och Institute of Information Industry. De tittar inte bara på själva näten utan hur den typen av angrepp skulle kunna användas i typiska OT-sammanhang med en lång radda attackscenarier. En utmärkt påminnelse från Brian Krebs kring nyttan av att kolla att man har tid att läsa tillbaka sina backuper. Hans vinkel är att många organisationer betalar för ransomware-nycklar just för att de plötsligt inser att det kommer ta flera år att läsa tillbaka en fullständig backup. Den vinkeln har inte så mycket att göra med OT direkt men tanken att faktiskt kolla att man har backuper och att de verkligen går att läsa tillbaka är VÄLDIGT relevant för de flesta OT-miljöer! https://krebsonsecurity.com/2021/07/dont-wanna-pay-ransom-gangs-test-your-backups/ Intressant analys av sårbarheter i både PLCer och molntjänster baserade på CODESYS från Clarotys nyligen omdöpta forskningsgrupp Team82. De visar hur de kan ta över en PLC från WAGO via den tillhörande molntjänsten men också omvänt kan ta över molntjänsten via en sårbarhet i PLCn. Det här är viktiga frågor som många med ambitioner åt "Industri 4.0"-hållet kommer ställas inför. Men det är ett problem även annars eftersom väldigt många OT-produkter baseras på CODESYS. https://www.claroty.com/2021/07/21/blog-research-exploiting-vulnerabilities-in-the-ot-cloud-era/ Det här nyhetsbrevet vänder sig till personer som är intresserade av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Den här gången kommer vi halvvägs till NIS2, vi lyssnar på Gartner som säger att några av oss kommer att dö senast 2025, jag tittar närmare på ISO 27019, vi har drömmar om säker PLC-programmering på svenska och vi bedömer en vanlig slagsida i säkerhetsarbetet. 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. 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 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! Gartner säger att vi kommer att dö! Gartner släppte nyligen en rapport som förutspår att senast 2025 kommer angripare framgångsrikt ha dödat eller skadat människor genom att angripa OT-system. De bedömer att redan 2023 kommer den ekonomiska konsekvensen av dödliga angrepp vara över 50 MUSD. Det mest kända fallet än så länge är angreppet mot en petrokemisk anläggning i Saudiarabien 2017 (TRITON/TRISIS) som dock misslyckades på grund av vad som verkar vara buggar i den skadliga koden. Det var ett angrepp mot skyddssystemen vid anläggningen som ju är där för att förhindra att riktigt allvarliga situationer uppstår. Hur dessa så kallade SIS-system ska separeras från ordinarie processtyrning är en populär diskussionspunkt inom OT-säkerhetsvärlden. Gartners förslag till åtgärder är i princip hederligt gammalt säkerhetsarbete där förutom tydliga ansvarsområden, utbildning, incidentberedskap mm tas upp de även pekar på saker som är speciellt viktiga och svåra inom OT-säkerhet: logganalys, hantering av bärbara lagringsmedia, asset-hantering, nätverkssegmentering och fokus på säkerhet vid konfiguration. OT-säkerhet i ISO 27000? Något som man kan ha många åsikter om är hur man bäst använder standarderna inom ISO 27000 för OT-säkerhet. Vad som är rätt beror på vilka delar av 27000 man tänker på men också vad man menar med OT-säkerhet... Det här är sjätte delen i min serie om standarder och ramverk. Första avsnittet handlade om ISA/IEC 62443 och finns i nyhetsbrev #26. I nyhetsbrev #27 och #30 tittar jag på NAMUR NOA. I nyhetsbrev #28 tittade jag på NIST CSF, NIST 800-53 och NIST 800-82 men du fick också lite mer om NOA som en bonus. I nyhetsbrev #29 tittade jag på den nya versionen av CIS Controls och funderade på hur den passar för OT. Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig! Det är vanligt att man bygger sitt informationssäkerhetsarbete kring ISO 27001, det har verkligen blivit den absolut populäraste standarden. När man sedan tänker sig att "styra upp" sin OT-säkerhet så ligger det förstås nära till hands att bara bygga på det man redan har. Och det är där som det kan bli lite utmanande vilket jag var inne på i förra nyhetsbrevet men som jag också konstaterade där så finns det inga hinder att kombinera ISO 27001 med ISA 62443. Det är ju för övrigt här som mina andra fråga blir så tydlig: "Vad menar vi med OT-säkerhet?". Bilden visar en vanlig modell för att beskriva informationssäkerhet, IT-säkerhet och relationen mellan dem. När vi sedan ska försöka göra motsvarande bild för OT-säkerhet blir gärna den första reaktionen att ersätta rutan "IT-Säkerhet" med "OT-Säkerhet". Det finns två viktiga problem med det sättet att tänka. Dels att det rimmar illa med att det överordnade syftet för informationssäkerhet är att skydda information. Men också att viktiga delar av OT-säkerhetsarbetet går ut på att analysera verksamhetsrisker och adressera dem, vilket är något som typiskt brukar landa inom "Informationssäkerhet". I praktiken betyder det att OT-Säkerhet måste finnas på två platser i bilden och dessutom blir en delmängd av sig själv. Som gjort för missförstånd alltså! Jag ser ingen enkel lösning på detta utom att vara väldigt tydlig med vad man menar. Men om vi återvänder till 27000-serien så finns det ju andra delar av standarden som man kan titta på också. Idag tänkte jag att vi tittar på ISO 27019 som har titeln "Informations-säkerhetsåtgärder för energiförsörjningssektorn" för att se om den kan hjälpa oss. Jag har inte själv använt 27019 i något verkligt fall så jag är väldigt nyfiken på att höra från er som praktisk erfarenhet! 27019 bygger vidare på 27000, 27001 och 27002 men ger dem ytterligare substans för att fungera inom elsektorn med ett stort fokus på OT-system och safety-utmaningar. I praktiken gör man det genom att ge ytterligare vägledning för krav från 27002 i ljuset av elsektorns utmaningar och genom att lägga till ytterligare krav utöver de som finns i 27002. Personligen tycker jag att 27019 fyller på med en del bra saker. Min uppfattning om den är att den är bra men väldigt allmänt hållen. (Precis som 27002...) Men den är nog en riktigt bra ögonöppnare för den som inte är van vid området och som kanske behöver förstå att allt inte är riktigt som man är van vid från IT/Info-säk. Riktigt centrala delar som nätverkssegmentering och är alldeles för kortfattade för att man ska få någon handgriplig hjälp framåt. Och det är förstås där som det passar väldigt bra att kombinera med ISA 62443. Lite tråkigt att 62443 är gömd sist i 27019, i en lista över internationella standarder och helt utan specifik hänvisning. Att utgå från 27001, 27002 och 27019 kommer nog funka alldeles utmärkt i lite enklare miljöer om man får med sig tillräcklig kompetens från start som förstår de specifika utmaningarna kring OT. Annars tror jag man ska utgå från 27000-serien men tidigt fylla på med det viktigaste från 62443, vilket för de flesta förmodligen är tänket kring zone&conduit samt hur man gör en riskanalys att basera segmenteringen på. 27019 ger definitivt ett bra "klister" mellan 27000-världen och 62443-världen! Säker PLC-programmering på svenska? Initiativet "The Top 20 Secure PLC Coding Practices Project" som jag skrev om i Nyhetsbrev #29 har fått mycket uppmärksamhet vilket är välförtjänt! Men bara för att man nu givit ut sin första version kommer de inte att ligga på latsidan, nu kommer bland annat en rad översättningar skapas. Jag har själv räckt upp handen för att se till att det blir en version på svenska. Om du vill hjälpa till är det bara att höra av dig! mats@ot-sakerhet.se Det ska bli spännande att se vart det här projektet tar vägen! NIS 1.5? MSB har en remiss ute just nu för en uppdatering av deras föreskrifter kring NIS-direktivet. Det är alltså inte NIS2 utan bara det enkla faktum att MSBs vägledning kring ämnet ska uppdateras vartannat år. Det är inga större överraskningar i mina ögon. Man kan ana lite gemensam inspiration från NIS2-förslaget här och där. Exempelvis tydliggör man nu att biogas räknas på samma sätt som naturgas när man ska bedöma om man berörs av kraven. Vill du svara på remissen har du till den 17:e september på dig. Fördomar mot försvaret! Dragos har på ett föredömligt sätt givit mig vatten på min kvarn när det gäller slagsidan i att de flesta organisationer prioriterar sina förebyggande säkerhetsåtgärder mycket högre än de analyserande åtgärderna. Det här är något som jag brukar predika för mina kunder och i mina föredrag. Vi satsar mycket hellre på brandväggar, patchning och segmentering istället loggning, analys och åtgärder. Naturligtvis måste båda varianterna finnas i något slags balans men jag tror vi någonstans drar oss för att sätta in åtgärder som kräver något av oss löpande. (Vilket förstås är en rimlig tanke, inte minst ekonomiskt.) Vännerna på Dragos har gett ut en rapport där de pekar på det här systematiska problemet finns redan i våra standarder och best-practices. Jag påstår inte att det måste vara exakt lika många åtgärder av varje sort men som bilden är nu är det ju en våldsam slagsida! Jag inser förstås att Dragos slår på sin egen trumma när de skriver så här, det är ju just aktiv analys som de är så duktiga på men det hindrar ju inte att de har rätt i sina insikter! Det paradoxala är ju dessutom att OT-miljöer tenderar att vara svåra att använda förbyggande åtgärder i när man kommer bortom grundläggande nätverkssegmentering. Däremot är det här nästan alltid relativt statiska miljöer där övervakande och analyserande åtgärder passar väldigt bra och blir extremt effektiva. Tro nu inte att jag tycker att förebyggande och förhindrande åtgärder är dåligt! Nej, vi måste ha dem också. Men eftersom de aldrig kommer kunna bli 100%-iga så behöver vi ju förstås balansera dem med något som kan upptäcka när den där attacken som är en på tusen slinker förbi! Det här resonemanget passar ju dessutom bra ihop med den insikt som många börjar få nu kring behovet av krishantering, återställningsplanering och kontinuitetsplaner. Återställning blir ju faktiskt mycket enklare om man fångar incidenten tidigt! De tre rekommendationer som Dragos ger ställer jag upp på helt och hållet: Se säkerhetsarbete som något du hela tiden förbättrar. Det kommer aldrig bli klart eller perfekt så om man arbetar utifrån det tänket blir man inte besviken och man blir dessutom förstås mycket mer drivande! Om det gamla slitna talesättet "Resan är målet" någon gång passar bra så är det väl för oss säkerhetsmänniskor... Jag brukar ha en bild av ett löpband i mina presentationer för att illustrera att vi hela tiden måste arbeta framåt även om det känns som att vi står stilla, för att om vi slår av på takten så börjar vi åka bakåt... Öka synligheten in i dina OT-miljöer. Det gäller förstås dels för att kunna veta vad som händer där men kanske framför allt för att överhuvudtaget veta VAD som finns där! Vet du vad du har och hur det fungerar när allt är normalt blir det väldigt mycket enklare att förstå när det inte är det. Min personliga reflektion kring detta är att det vill till att man har en förmåga att reagera och ta hand om de saker som man upptäcker med hjälp av sin insyn. Annars får man enbart stresspåslag och ingen verklig nytta. Lite som att ta backuper men inte kunna återläsa dem... Jag brukar också peka på ett annat skäl att jobba med insyn innan man jobbar med segmentering nämligen att segmentering helt enkelt blir mycket smidigare om man redan har koll på sin nätverkstrafik! Det sägs ofta att vi behöver öva på incidenthantering vilket nästan lika ofta får mothugg i stil med "vi kan ju inte öva i produktionen". Jag håller verkligen med Dragos om att det räcker extremt långt med enkla diskussionsövningar runt ett bord. Att öva på att ta beslut och samtidigt fundera över vad vi behöver veta under en skarp incident är väldigt lärorikt! Tips om event och mer läsning! Dags att damma av ett dokument från 2012! I dessa dagar när vi allt oftare hör diskussioner om attribuering av attacker och de svårigheter som kan finnas i sådana resonemang kan vi vända oss till Jason Healey och Atlantic Council för klokskap! Det kanske helt enkelt spelar mindre roll vem som tryckte på knappen som fick Coop att stanna och istället är det viktigare vems fel det är! Läs dokumentet, det finns klockrena liknelser med stenkastning efter bombade ambassader eller med somaliska pirater! Johan Bengtsson och Lovisa Mickelsson på FOI har gett ut en studie kring smarta städer där de bland annat tittar på möjligheter och risker på området. Inte riktigt OT utan snarare syskonområdet IoT, men ändå en del intressanta resonemang! Biljetterna till S4x22 är släppta! För den som inte vet det är S4 generellt sedd som den främsta och definitivt mest framåtriktade konferensen inom OT-säkerhet i världen. Den går av stapeln i Miami i Januari. Om du inte vill eller kan åka till Miami är Köpenhamn ett riktigt bra alternativ. "Industrial Security Conference Copenhagen" är tre dagar i November där den första dagen hålls på danska och de andra två på engelska. Många intressanta ämnen på agendan! En riktigt bra genomgång av hur man kan tänka kring riskkriterier av Sinclair Koelemij. Jag kan speciellt rekommendera hans snygga genomgång av skillnaden mellan riskaptit och risktolerans. Han bjuder också på en genomgång av begreppet SL - "Security Level" från ISA 62443. Dragos har gett ut ett whitepaper som snyggt sammanfattar allt som är klurigt med sårbarhetshantering inom OT och hur man bäst ger sig på utmaningarna som man stöter på. https://www.dragos.com/resource/ot-vulnerability-management-whitepaper/ Om du var väldigt ledig på semestern kanske du missade några av de nyhetsbrev jag gav ut under sommaren? I #32 tittade jag på de senaste nyheterna kring NIS2, MITRE Engenuity och Industrial Internet Consortium. Vi fick också godbitar kring hur man ska tänka kring risker som aldrig varit ett problem förut. I #31 letar jag efter motsvarigheten till informationssäkerhet för OT-säkerhet, hur virtuell patchning fungerade för PrintNightmare. I #30 funderar jag på hur vi ska stava till "Industrie 4.0", ovanliga sätt att beskriva risk och mina favoritpoddar. I #29 tittade vi på "The top 20 Secure PLC coding practices project", hur den nya versionen av "CIS controls" passar i OT-världen och tittar närmare på utrustningen som jag använt för att testa och överlasta brandväggar. Jag kommer att prata på CyberNorth den 28:e September och alla är förstås välkomna att lyssna! Ämnet blir en variant på min nuvarande käpphäst om hur man undviker att missförstånd och otydligheter leder till dålig framdrift i säkerhetsarbetet och till misslyckanden med tekniska initiativ. Det här nyhetsbrevet vänder sig till personer som är intresserade av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Nu fick du vänta lite längre än vanligt sedan senaste nyhetsbrevet, jag ber om ursäkt för det. Jag har helt enkelt varit ute och njutit av att få träffa mina kunder i den fysiska verkligheten igen och av att prata på fysiska event! Fantastiskt roligt! Men den som väntar på något gott... Den här gången får du Zero Trust i OT-världen, gränsdragningar mot IT, nya NIS-föreskrifter, dåliga bilförare i hemkokta psykologiteorier 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. 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 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! Är vi mogna nog att förstå hur omogna vi är? Du kanske känner till "Dunning Kruger Effekten"? Det är en psykologisk effekt som (lite förvanskat) säger att en person som har mindre kunskap i något ämne gärna överskattar sin egen kunskap medan någon som kan mycket mer ofta underskattar sin egen kompetens. Det här är väldigt förrädiskt eftersom det är lätt att se hos andra personer men nästan omöjligt att genomskåda för sig själv! En klassiskt variant är att 95% av alla bilförare anser sig tillhöra den bättre halvan av alla i trafiken... Det här är förstås extremt sant även inom säkerhetsarbete i alla former. På sistone har jag funderat kring en variant av effekten som jag med sedvanlig ödmjukhet kallar "Karlsson Landré Effekten". Den går ut på att precis samma resonemang också fungerar på organisationer och på säkerhetsmognad. Jag menar att man i omogna organisationer inte inser sin egen omognad, inte ser hoten mot organisationen och inte ens förstår behovet av ett strukturerat säkerhetsarbete. Det skapar förstås också en massa frustration för de personer i organisationen som faktiskt har en bra personlig kompetens och hög personlig säkerhetsmognad, eftersom de helt enkelt har svårt att få gehör för sina insikter. Den omvända effekten kan i någon mån också vara ett problem, fast på ett annat sätt. En organisation med väldigt hög säkerhetsmognad kanske tenderar att bli lite väl paranoid och börjar sikta lite FÖR högt i sin risk-eliminering? Det krävs nog också människor med en lite annan syn på vad som är roligt när organisationen är väldigt mogen, det finns helt enkelt ingen plats för vilda säkerhets-comboys! Jag inser att jag inte kan vänta mig något nobelpris i säkerhetspsykologi och det var förstås inte meningen att det här skulle vara någon revolutionerande tanke heller. Istället hoppas jag att detta kan vara en hjälp i att bli lite mer självkritisk och kanske hjälpa oss alla att våga leta efter våra egna "blindspots" och svaga punkter. Hur bra bilförare är ni i din organisation? Egentligen... Hur ska vi tänka kring Zero Trust i OT-världen? "Zero trust" är ett koncept som jag personligen har stora förhoppningar för i IT-världen även om begreppet lider av att det har blivit ett riktigt floskel-ord som används väldigt slarvigt i många sammanhang. Om du inte har koll på vad det går ut på så kan man väldigt enkelt förklara det som ett sätt att bygga sin systemarkitektur baserat på att allting är behörighetsstyrt snarare än begränsat av nätverksbegränsningar. Det här är en gammal tanke som har fått nytt liv i och med att tekniken ger oss nya möjligheter. Jag minns att jag var på konferens i London i början av 2000-talet med något som hette Jericho Forum där liknande tankar drevs. NIST släppte förra hösten dokumentet NIST SP 800-207 "Zero Trust Architecture" som har blivit tongivande i diskussionen kring Zero trust. Det ger ingen vägledning alls kring OT-världens utmaningar och hur Zero trust skulle passa där. Det försöker nu "Operational Technology Cyber Security Alliance" (OTCSA) råda bot på med ett whitepaper kallat "Review of Zero Trust - Inspiration for OT environments". Det är bara 6 sidor att läsa och ger dessutom en riktigt bra inflygning till både Zero trust och NIST-dokumentet. Det är lätt att man fastnar i utmaningen att många OT-utrustningar idag har väldigt dåligt stöd för identiteter och behörigheter. OTCSA höjer blicken lite grann och resonerar istället kring beröringspunkterna mellan NIST-dokumentet och ISA/IEC 62443. De kommer kanske inte fram till något världsomvälvande men det är en väldigt bra sammanfattning av ett antal kluriga utmaningar och möjligheter. Jag ska inte ge mig på att försöka sammanfatta en så bra dokument utan rekommenderar varmt att du läser det! Det är som sagt föredömligt kort och koncist! Var slutar OT och var börjar IT? I ett kunduppdrag insåg vi nyligen att synen på vad som var "OT" varierade oväntat mycket mellan olika delar av organisationen. Kunden hade sedan tidigare låtit alla delar av organisation göra en självskattning av sina förmågor inom OT-säkerhet. Det blir naturligtvis lite klurigt att skapa en samlad bild av hur det står till med OT-säkerheten när de olika bedömningarna handlar om olika saker... Det är lätt gjort att man omedvetet sätter något slags likhetstecken mellan OT och PLCer. Det kanske stämmer i vissa verksamheter men för de flesta går "gränsen" mellan IT och OT någon annanstans. För någon är MES-systemet en del av OT och för en annan kan det till och med inkludera produktionsplanering. Jag ska inte försöka mig på att ge dig ett facit på vad "OT" är. Jag tycker det kan få vara ok att det varierar mellan olika organisationer utifrån deras egna förutsättningar och behov. MEN! Det är viktigt att man i varje organisation är överens eller i alla fall tydlig med vad man menar med "OT"! Några av de varianter som jag stött på och som alla gått att få fungera hyfsat för de organisationer som valt dem är: Layer 1, 2 och 3 enligt ISA 99 är OT - det här borde teoretiskt sett vara den bästa definitionen men det visar sig ofta att man inte alltid är överens om var saker hör hemma eller att vissa system spänner över flera olika lager. Man lurar sig lätt genom att sätta likhetstecken mellan lagermodellen och segmenteringens nätverkszoner. Det som ägs av IT-avdelningen är IT - resten är OT - kan tyckas lite som en bakvänd eller till och med fånig definition men om man är strukturerad i sina processer för IT Services Management kan det fungera. De här nätverken är OT - allt annat är IT - inte en av mina egna favoriter men kan funka om man är tydlig med ansvarsfördelningen man samtidigt duktig på att samarbeta för att utnyttja den kompetens som finns. Domänen prod är OT och acme är IT - om man har valt att ha två domäner kan det vara ett sätt att tänka. Vi gör ingen skillnad - alla system hanteras på sina egna villkor - låter bra på pappret men kräver en extrem mognad för att fungera i praktiken... Det handlar om var i verksamheten systemet används - låter också bra tills ett system används på flera ställen. I slutänden spelar det mindre roll vilken metod man väljer så länge den är tydligt, har få undantag och att alla är överens om vad som gäller i praktiken! Som vanligt är det klokt att vara väldigt tydlig med vad man menar och inte bara anta att den man pratar med har samma syn på begreppen... Exploits - Hur mår OT? Vännerna på Dragos har givit ut en intressant analys av sårbarheter och exploits i OT-prylar baserat på över tio års information. Det är en snygg och lättillgänglig analys som jag rekommenderar att du tittar närmare på! Det finns mycket godis i deras tabeller och grafer som hjälper oss förstå hur vår bransch utvecklats. Samtidigt finns ett antal oklarheter och än så länge oförklarade trender. De noterar i förbigående att av alla organisationer som köper sårbarheter så verkar det bara vara Zero Day Initiative (ZDI) som verkligen satsar på att ta hand om sårbarheter i OT-världen. (ZDI har jag skrivit om tidigare (Nyhetsbrev #31 och #23 eftersom deras koppling till TxOne är så spännande.) De står ensamma för hälften av alla CVE-registreringar med OT-koppling! Hur översätter man förresten "Exploit" till svenska på ett bra sätt? "Attackmetod" är ju kanske närmast men tappar lite i tydlighet... Vill du hjälpa till med svenskan? Initiativet "The Top 20 Secure PLC Coding Practices Project" som jag skrev om i Nyhetsbrev #29 har fått mycket uppmärksamhet vilket är välförtjänt! Men bara för att man nu givit ut sin första version kommer de inte att ligga på latsidan, nu kommer bland annat en rad översättningar skapas. Jag har själv räckt upp handen för att se till att det blir en version på svenska. Om du vill hjälpa till är det bara att höra av dig! mats@ot-sakerhet.se Jag är verkligen ingen PLC-programmerare så det skulle vara bra att få hjälp av någon som är duktig på det! Tar gärna ytterligare en eller två översättare och framför allt ett gäng som vill tycka till om innehållet och språket i vårt utkast när det är klart! NIS-föreskrifter från Transportstyrelsen Den 6:e september släppte Transportstyrelsen sina nya NIS-föreskrifter på remiss. Du har till den 4:e oktober på dig att tycka till. Det är föreskrifter kopplade till det nuvarande NIS-direktivet och inte det kommande NIS2. (Men det matchar å andra sidan förslaget till NIS2 ganska bra redan nu.) Man har fokuserat på att sätta ett slags hygiennivå som uttryckligen ska ses som en grund att bygga vidare på. De flesta kraven går ut på att ta fram styrande dokument och att tillämpa dem. Innehållet innehåller inga överraskningar alls. Det liknar de flesta krav-standarder med områden som "Inventera vad du har", "omvärldsbevaka hot och sårbarheter", "gör åtgärdsplaner från dina riskanalyser", "följ upp alla säkerhetsåtgärder", "driftsätt inte osäkra system", "ändringshantering är viktigt", "testa din säkerhet", "utbilda kring säkerhet", "härda dina system", "segmentera", "kryptera", "ge alla en unik identitet som autentiseras", "administratörer ska jobba säkert", "skydda utrustning fysiskt", "upptäck intrång" och "hantera kriser och återställning". Alla områden beskrivs i några enstaka meningar på väldigt hög nivå, så det är upp till varje organisation att bedöma vad som är "lagom". Enligt konsekvensutredningen bygger föreskrifterna på NIS Cooperation Groups referensdokument CG Publikation 01/2018 istället för att ta fram helt egna. Förmodligen ett klokt val även om innehållet i princip ser ut att vara en extremt förkortad version av ISO 27002. De föreslår att reglerna ska gälla från 1:a Januari 2022. Något nytt om NIS2? Jag och många med mig väntar otåligt på att NIS2 ska spikas men det verkar tyvärr vara längre bort än vad det verkat tidigare. Jag skrev senast en uppdatering i Nyhetsbrev #32, men sedan dess har det varit väldigt lite nyheter som läckt ut. Slovenien tog över presidentskapet för EU-rådet i somras och pekade bland annat på att NIS2 var prioriterat. Den som väntar på något gott... Tips om event och mer läsning! Du kommer väl till årets upplaga av IT-arenan i Örebro? Jag kör dragningen "Stå stadigt med säker OT" men du kan också komma förbi i säkerhetsmontern och snacka OT hela dagen! Spännande rapport från Trend Micro som bygger på en hotmodellering av kraven från FNs arbetsgrupp WP.29 för cybersäkerhet i fordonsbranschen. Kanske inte den vanligaste typen av OT men väldigt intressant! Hög kvalitet from vanligt från Phoenix Contact när de går igenom nyheterna som är på väg i det nya maskindirektivet. Inspelningen från huvudpresentationen finns på Youtube tillsammans med den uppföljande frågestunden som Nisse och Co körde därefter. Det här är ett spännande område som jag skrev om i Nyhetsbrev #27. Ett bra whitepaper från Garland som beskriver viktiga principer (och förstås deras egna produkter) för att få synlighet i vad som händer i OT-nätverk. Titeln pratar om Industri 4.0 men innehållet är generellt OT. De tar upp viktiga saker men grundläggande saker som att välja rätt mellan en nätverks-tap eller en span-port men även en del andra klurigheter som det är lätt att missa i detta väldigt viktiga område! Halvårsrapporten från Clarotys Team82 är som vanligt späckad med information kring vad de sett "där ute"... Alltid retar det någon? Intressant artikel från Velta Technology om vad OT kan lära sig av IT. Jag håller med om mycket men inte allt. En del intressanta insikter kring exempelvis skillnader i synen på investeringar mellan de båda världarna. Berätta gärna om dina tankar där du läser den! Intressant dragning DEF CON ICS Village av Aaron Boyd från Dragos. Ämnet är penetrationstester i OT-system där man av olika skäl inte har tillgång till verktyg utöver det som finns att tillgå i systemen man angriper. Ofta handlar det om att ta sig runt vitlistning eller något liknande skydd genom att bara använda redan kända mjukvaror. Nyttigt för både angripare och försvarare. Spännande insikter från Dale Peterson kring hur försäkringsbranschen förändras snabbt just nu i det förändrade risklandskapet. Det är verkligen en bransch som kämpar för att hitta sitt nya sätt att hantera samtiden! Du kan se min dragning från Xday 2021 på YouTube nu tillsammans med ett antal andra snack som är riktigt intressanta även om de inte handlar om OT. Det här nyhetsbrevet vänder sig till personer som är intresserade av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Den här gången skriver jag om två nya delar i standarden ISA 62443, acceptabla dödssiffror, personliga tankar kring säkerhetskultur, nyheter från NIST, cybersäkerhet i kärnkraftsbranschen, farliga backuper och smartare segmentering! 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 också är anledningen till mina texter. 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 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! En ny del i ISA 62443! En sprillans ny del i 62443-standarden är på väg att spikas. Det är "ISA-62443-2‑2: IACS Security Protection" som är ute på sin andra remissrunda. Det är fritt fram för alla med tillgång till arbetsmaterial från ISA99 att komma med kommentarer fram till slutet av November. Den här delen ger ledning kring hur man skapar, mäter och validerar något som man valt att kalla "SPS, Security Protection Scheme". En SPS är helt enkelt en bild av det totala skyddet, alltså kombinationen av de stödprocesser som kommer från del 2-1 av standarden och de tekniska skydden (inklusive segmenteringen i "Zones and Conduits") från del 3-2. Det viktigaste som vi får i del 2-2 är ett (någorlunda) entydigt sätt att mäta hur väl vi i verkligheten implementerat de skyddsåtgärder som tagits fram. Det är användbart både som en del av SAT inför driftsättningen men också regelbundet för att följa upp att utvecklingen går åt rätt håll. Personligen kan jag väl tycka att 2-2 (precis som de flesta andra delar i standarden) är något i överkant vad gäller komplexitet och detaljeringsgrad kring hur man ska göra. Att inte kunna se skogen för alla träd är ett talessätt som känns lämpligt i sammanhanget... Men syftet är både viktigt och bra; det är lätt att man bestämmer och utformar en massa bra skydd som man sedan inte riktigt lyckas implementera fullt ut. Här får man stöd att hålla ögonen på bollen även över tid... På det hela taget känns det här som en viktig pusselbit som saknats tidigare. Det ska bli spännande att se de första organisationerna börja implementera den! ...och en till! Det är faktiskt en draft till som är kopplad till 62443 ute på remiss just nu. Det är "62443-1-5, Scheme for IEC 62443 cyber security profiles" som är ute på sin första runda. Förutom att det är ett nytt dokument så är det också det första tecknet på en kommande ny serie av dokument, serie 5. Tidigare har standarden haft fyra serier och sett ut ungefär som på bilden. Serie 1 är allmänna delar, serie 2 fokuserar på administrativa processer, serie 3 är teknik och serie 4 gäller de som tillverkar OT-komponenter. Nu kommer vi så småningom få en femte serie där något som kallas profiler ska finnas. Profiler är enkelt uttryckt anpassningar av en eller flera delar av standarden till specifika behov för en viss bransch eller ett visst syfte. Det nya dokumentet "62443-1-5" beskriver hur man tar fram dessa profiler. En profil är inte tänkt att tillföra några nya krav utan ska enbart peka ut vilka krav som är relevanta och vilka miniminivåer som ska uppnås. Det här tror jag kan underlätta införandet av standarden i många typer av organisationer. Hur väl det kommer fungera är svårt att bedöma baserat på dokumentet så vi får vänta tills de första profilerna börjar dyka upp. Vad kan säkerhet lära av säkerhet? En vanlig fråga jag brukar få är om det är bättre att försöka lära IT-säkerhetsfolk att förstå OT-världen eller att uppfostra OT-folk i IT-säkerhet. Mitt första svar brukar vara att det beror mer på individen är dess utbildning. Men jag har på senare tid insett att det finns ett annat svar också... Som jag tror jag egentligen gillar bättre... Det viktigaste är nog att man arbetat nära någon form av produktion - helt oavsett vad man haft för jobb. Och då menar jag fysiskt nära, så att man har fått lära sig det lite speciella grundtänket och känslan som finns i verksamheter där saker kan hända som kan vara farliga för dig själv, för utrustningen eller för dina kollegor. Där det är viktigt att jobba med säkerhetskultur av andra skäl än att folk inte ska klicka på spam-länkar. Där säkerhet handlar om att maskiner inte ska gå sönder, folk inte ska bli skadade och miljön inte ska ta stryk. Kanske man lärt sig förstå eller praktiskt använda mystiska begrepp som "HuP-verktyg", "TAK-mätning", "kompiskoll", "FAT/SAT", "ställtider", "Poka-Yoke" eller "takt". Man förstår instinktivt de väldigt annorlunda förutsättningarna som (nästan) alltid råder jämfört med IT-säkerhet och informationssäkerhet. Där nästan allt man gör på ett eller annat (indirekt) sätt har med säkerhet i någon form att göra. Fast då är det ju traditionellt inte OT-säkerhet som stått i fokus utan det mer traditionella arbetet med skydd mot personskador och miljöpåverkan. Viktiga frågor utan tvekan men jag ser tyvärr fortfarande att man missar OT-aspekter i dessa riskanalyser. Jag tror det här är vägen in för OT-säkerhet på de platser där den fortfarande inte är en naturlig del i det övergripande säkerhetsarbetet. Jag provocerar säkert en och annan med detta men jag tror att de flesta kan lära sig segmentera nätverk eller programmera PLCer efter några väl valda kurser och lite övning. Att ta till sig en säkerhetskultur som passar i typiska OT-miljöer tar tid och praktisk erfarenhet... Här vet jag att det kommer finnas många åsikter och förmodligen många som inte håller med mig. Hör gärna av dig eller kommentera den här utgåvan på LinkedIn. Jag vill uppriktigt förstå fler synvinklar och erfarenheter! NIST ger oss ett facit! Jag har tidigare skrivit om dokument från NIST, framför allt i Nyhetsbrev #28 där jag gick igenom "NIST Cybersecurity Framework", "NIST Special Publication 800-53" och "NIST SP 800-82". Nu har NIST släppt en draft av ett nytt dokument i 1800-serien som har det smidiga namnet "NIST 1800-10 Protecting Information and System Integrity in Industrial Control System Environments: Cybersecurity for the Manufacturing Sector". Om du inte känner till 1800-serien så är det en samling dokument som är tänkta att vara "how-tos", alltså handfasta och praktiska rekommendationer kring hur man hanterar olika kniviga ämnen - i det här fallet OT-säkerhet för tillverkande industri. Det som är lite speciellt är att man gör det i samarbete med ett antal tillverkare och använder deras produkter rätt av som exempel på hur man kan göra. För min egen del hade jag inte koll på Dispel och GreenTec sedan tidigare men i övrigt är det idel välkända namn som medverkar. Vissa har förekommit i nyhetsbrevet tidigare, exempelvis ConsoleWorks från TDI Technologies som var med redan i nyhetsbrev #18! Det här är ett massivt dokument på drygt 300 sidor, uppdelat i tre delar. Det huvudsakliga innehållet beskriver hur man implementerar funktioner från "NIST CSF" med hjälp av dessa produkter. Som synes är det väldigt olika produkter: Säkerhetsfokuserade produkter som applikationskontroll i Carbon Black, sårbarhetshantering i Tenable.ot eller styrsystem-nära säkerhet i Dragos och Azure Defender Fjärråtkomst på ett säkert sätt via ConsoleWorks Generella historian-funktioner mm via OsiSoft PI Server. Tillsammans kokar de en ganska heltäckande soppa som bör gå alldeles utmärkt att utnyttja även om man inte använder just de här produkterna. I grunden är det ett ganska bra sätt att tänka brett genom att utgå från CSF. Jag kallade skämtsamt dokumentet för ett facit i rubriken, men man ska nog hellre se det som en receptsamling. Man kan byta ut de ingredienser som man saknar mot andra som man redan har hemma i skafferiet. Men det hjälper förstås också till att sätta ljuset på eventuella hål i det egna säkerhetsarbetet. Personligen ser jag väldigt ofta en stark slagsida mot preventiva skyddsåtgärder. En av mina favoritdelar i CSF är de fem grundläggande delarna, "Identify", "Protect", "Detect", "Respond" och "Recover". När man diskuterar utifrån dessa blir det ofta väldigt tydligt att alltför mycket tid och pengar ägnas åt "Protect" medan de övriga får betydligt mindre att dela på. Slarvar man med "Identify" blir alla de andra delarna (inklusive "Protect") betydligt mindre effektiva. Missar man någon av delarna i trojkan "Detect", "Respond" och "Recover" blir man väldigt sårbar om det hårda skalet man försöker skapa via "Protect" skulle brista. Hur många ska dö det här årtusendet? Sinclair Koelemij ger oss första delen i en serie blogginlägg om komplexa riskanalyser i sammanhang där det ställs detaljerade krav från samhället. Det kan vara saker som hur ofta ett visst antal människor "får" dödas i olyckor. En speciellt intressant del av den här typen av riskbedömningar är att kraven från samhället innehåller sannolikheter (eller egentligen frekvenser, hur ofta får det hända en dödlig händelse) eftersom kraven traditionellt är utformade för slumpmässiga händelser som jordbävningar, utrustningsfel eller översvämningar. Men när vi pratar om angrepp från människor försöker vi oftast undvika att prata om just sannolikheter eftersom det blir näst intill omöjligt att definiera hur ofta en målinriktad angripare lyckas. Hur hanterar man den här skillnaden på ett bra sätt i sitt riskarbete? Om verksamheten sedan ska hanteras enligt det svenska säkerhetsskyddet där man från myndigheterna uttryckligen säger att man inte ska ta hänsyn till sannolikheter utan enbart gå på konsekvenser, då gäller det att hålla tungan rätt i munnen! Om du har funderat över begrep som SIS, SIL och SIF får du här en genomgång med ett tydligt exempel. Vi får lite diskussioner kring skillnaden mellan attacker mot "vanliga" styrsystem gentemot attacker mot skyddssystemen, de så kallade SIS-systemen (där TRISIS/TRITON är det, än så länge, mest kända exemplet). Kort sagt - läs den! IAEA levererar igen! Internationella Atomenergiorganisationen IAEA har levererat ett nytt dokument! "IAEA Nuclear Security Series No. 42-G - Computer Security for Nuclear Security". IAEA är en organisation med nära band till FN, den rapporterar till FNs säkerhetsråd och till dess general-församling. Uppdraget är att verka för fredlig användning av kärnteknik och samtidigt motverka farlig eller aggressiv användning. Jag är ju själv "uppvuxen" i kärnkraftsbranschen och måste säga att jag gillar de flesta av IAEAs dokument inom många områden. Det här dokumentet är bara 86 sidor och är inte speciellt inriktat på OT utan har också ett stort fokus på att skydda känslig information och på fysiskt skydd av känsliga anläggningar. Det är faktiskt inte skrivet för enskilda organisationer utan har stater som sin publik! Trots detta kan det vara en bra inspiration för hur man kan driva sitt säkerhetsarbete som enskild organisation, kanske i synnerhet om man har en verksamhet som är av det mer känsliga slaget. Ett viktigt koncept i den kärntekniska världen är "Graded Approach", dvs att man ska har rätt skydd på rätt plats - vare sig mer eller mindre! Det är verkligen något jag tagit med mig från min tid i kärnkraftsvärlden. Här kan verkligen andra typer av verksamheter lära sig av IAEA och andra organisationer i den här branschen. Inte minst verksamheter som lyder under säkerhetsskyddslagen, där jag allt för ofta ser att man överreagerar, nästan i blindo, och applicerar närmast förlamande skyddsåtgärder med bred pensel över alldeles för många verksamhetsdelar. Det är svårt att få medarbetarna att respektera säkerhetsåtgärder som uppenbart är överdrivna och därmed bara stör verksamheten! Läs gärna detta och andra IAEA-dokument även om du är i helt andra branscher! Farliga backupsystem! Team82 från Claroty har på senare tid hittat vansinnigt spännande sårbarheter i OT-produkter. Den här gången har de tittat på applikationer som (bland annat) hanterar backup av komponenter och system inom OT med närmast skräckinjagande resultat. Det blir ju inte bättre av att varje produkt hade en hel radda sårbarheter... Rockwell Automation FactoryTalk AssetCentre, 9 sårbarheter (CVSS 10.0) MDT AutoSave, 7 sårbarheter (CVSS 10.0) AUVESY Versiondog, 17 sårbarheter (CVSS 9.8) Precis som i IT-världen är backupsystem extremt viktiga att skydda ordentligt och sårbarheter i dem blir därmed oftast katastrofala. Dessutom har dessa system en tendens att sätta nätverkssegmenteringen ur spel eftersom de kan ha bakvägar till system som annars är separerade från varandra. Kloka ord kan hittas även i reklam... Ett bra white-paper från Cisco kring "Edge"-baserade arkitekturer för OT-nät i en modern värld där det klassiska DMZ-tänket inte duger längre. Det här är egentligen inget nytt men det blir allt fler som inser att det inte fungerar speciellt bra när man bara sätter likhetstecken mellan Purdue-modellen och nätverkssegmentering. Om man implementerar någonting som liknar Industri 4.0 ovanpå en befintlig "klassisk" OT-miljö så blir det extremt tydligt att tänket inte håller! Jag har skrivit om en del liknande resonemang tidigare, exempelvis "NAMUR Open Architecture" i nyhetsbrev #27 och #30. De pekar elegant på de två besläktade områdena synlighet och segmentering. Ett av standardråden jag ger till mina kunder är att inte ha för bråttom med segmentering. För att kunna segmentera behöver man först ha örnkoll på vad som finns i nätverket och hur det som finns där kommunicerar. Med ett bra verktyg som förstår OT-protokoll och som kartlägger miljön blir det sedan vansinnigt mycket enklare och bättre att segmentera. När det gäller synlighets-delen jämför de lösningar såsom TAP, SPAN mm. De slår förstås ett slag för sina egna switchar som gör det möjligt att få synlighet överallt utan att bygga en extra infrastruktur för synligheten. Kombinerat med Cisco Cyber Vision är det faktiskt en riktigt snygg lösning som ser en massa fördelar i praktiken. (Som faktiskt funkar hyfsat även om man inte har switchar från Cisco.) Tips om event och mer läsning! CSA (Cyber Security Agency of Singapore) verkar vara en intressant organisation som producerar en del spännande läsning. Härom veckan kom "Operational Technology Cybersecurity Competency Framework (OTCCF)" som är ett dokument som försöker beskriva kompetenser och roller kring OT-säkerhetsområdet tillsammans med en stiliserad beskrivning av karriärvägar. Jag har inte själv landat i vad jag tycker om innehållet men det kan definitivt vara bra som inspiration för den som är sugen på att arbeta inom det här fantastiska området. Det kan nog också vara ett bra stöd för den som har den otacksamma uppgiften att författa rollbeskrivningar eller platsannonser... En bra artikel av Jason Christopher som ger rekommendationer för vad man ska spendera sin säkerhetsbudget på. Jag håller verkligen med om grundteserna som är det gamla citatet "Prevention is ideal, but detection is a must!" kombinerat med "But detection without response is of little value!". Jag ser ofta att allt för mycket tid och pengar spenderas på att försöka förhindra angrepp och andra händelser men att man samtidigt missar att bygga förmågor kring att upptäcka incidenter och att hantera dem. Två, lite olika, perspektiv kring kopplingen mellan "Zero Trust" och "OT". Pricksäkra ord från Dale Peterson och andra tankar, även de är kloka, från KPMG. Kloka råd från Accenture kring hur man kan bli bättre på riskhantering inom OT. En presentation av Daniel Ehrenreich på GTACS 2021 kring hur man genomför vettiga hotanalyser i OT-världen. Ett kort dokument som belyser tre viktiga aktiviteter för att få säkerhetsarbetet inom IT och OT att fungera tillsammans. De tre matchar vad jag brukar mässa om när jag är ute och föreläser om det här: Se till att ledningen förstår konsekvenserna om OT skulle haverera eller saboteras. Välj ett gemensamt sätt att värdera risker över hela organisationen. Utbilda IT i OT-säkerhet och OT i IT-säkerhet! Om man förstår varför den andra gruppen människor beter sig som de gör blir samarbetet mycket bättre! En bra artikel som sammanfattar allt det viktiga med hantering av certifikat i OPC UA. Det här nyhetsbrevet vänder sig till personer som är intresserade av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Dags för en sommarlätt utgåva av nyhetsbrevet! Jag jämför OT-säkerhet med informationssäkerhet, kollar hur fort virtuell patchning löste PrintNightmare och tar en närsynt titt på en massa fina prylar från Moxa. 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. 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 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å vissa artiklar från nyhetsbreven 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! Precis som informationssäkerhet! När man försöker lära sig om OT-säkerhet får man lätt intrycket att "det är IT-säkerhet men för OT-prylar". Jag förstår att man tänker så, jag tänkte nämligen själv så tidigare... Men när man dyker lite djupare i resonemangen inser man att det inte är fullt så enkelt. I mitt eget resonemang finns en massa, kanske lite oväntade, paralleller till informationssäkerhet. Va? Infosäk? Ja faktiskt! Ett populärt sätt att tänka är att IT-säkerhet är en del av det större begreppet informationssäkerhet och att det därför är behoven av skydd för informationen som ställer krav på IT-säkerhet. Det ligger förstås mycket i det, eftersom det är via skyddet av information som IT-säkerhet får sina övergripande prioriteringar. MEN! Det är ju väldigt uppenbart nu för tiden att det krävs en ganska rejäl dos IT-säkerhet för att hålla liv i vilket IT-system som helst, oavsett om det är ett kassasystem på COOP eller någons nyligen raderade NAS hemma. Bara det att du har ett system som du vill hålla liv i kräver ganska mycket säkerhetsansträngningar oavsett vad det ska användas till! När folk pratar om OT-säkerhet tenderar de ofta att fastna på att skydda systemen i sig själva. Det är inte så konstigt, eftersom prylarna tenderar att vara väldigt ömtåliga och nästan alltid byggda med teknik som inte kan vara säker. "Insecure by design". Precis som för IT-säkerhet krävs det därför ansträngningar för att systemen överhuvudtaget ska kunna överleva i en omvärld som är allt mer hotfull och aggressiv. MEN! Om du istället fokuserar ditt säkerhetsarbete på att hålla igång din fysiska process så måste du helt plötsligt fokusera på den betydelse dina system har för verksamheten och kanske för samhället runt omkring. Det är här jag drar min parallell till informationssäkerhet! Plötsligt är det verksamheten som bestämmer var som är viktigast! Har du en potentiellt farlig verksamhet kanske samhället ställer krav på dig också för att skydda omgivningarna... Men den viktigaste likheten med skydd av information är att säkerhetsåtgärder inte alltid behöver sitta i systemen! Är din fysisk process byggd så att det faktiskt är omöjligt för den att bli farlig för omgivningen oavsett vad en elak hacker gör med systemen så är väl det en mycket åtgärd än att försöka stoppa hackern. Det finns förstås fler skäl att vilja stoppa en hacker men åtgärderna, och framför allt kostnaderna för dem, blir annorlunda om man redan löst en del av utmaningarna. Precis som inom IT är kontinuitetsplanering tyvärr ofta en underskattad del av säkerhetsarbetet. Naturligtvis kan man välja att inte ha alternativa rutiner om systemen rasar, det är en riskavvägning man förstås får göra. MEN! Allt fler verksamheter hamnar där vare sig de vill eller inte, det är helt enkelt inte möjligt att bedriva vissa verksamheter på ett meningsfullt (eller lagligt) sätt utan IT-stöd. Jag gissar (en ren killgissning!) att COOP (eller ICA...) inte får sälja något utan fungerande kassasystem eftersom skatteverket har höga krav på spårbarhet. På samma sätt skulle jag själv föredra att Seveso-klassade verksamheter lät bli att köra sin verksamhet utan fungerande säkerhetssystem... Jag tycker alltså faktiskt att OT-säkerhet i stort mest liknar informationssäkerhet, om man nu ska jämföra... Inom OT-säkerhet finns ju då också något som på ytan liknar IT-säkerhet där man skyddar sina system, men som på grund av att våra förutsättningar och prioriteringar faktiskt skiljer sig väldigt mycket. I slutändan håller jag därför fast vid att OT-säkerhet måste handla om både säkerhet i den fysiska processen och skyddet av de tekniska systemen! En stor poäng med likheten mellan OT-säkerhet och informations&IT-säkerhet är att man kan bedriva ett vettigt gemensamt risk- och säkerhetsarbete. Som du kanske läste i förra nyhetsbrevet tycker jag att det finns stor anledning hålla att säkerheten inom IT och OT på jämförbara nivåer. I takt med att verksamhetsutveckling ofta är beroende av både IT- och OT-stöd ser jag allt oftare att säkerhetsåtgärder i de båda områdena möjliggör nya sätt att driva verksamheten och nya sätt att skapa värde. Det är ju när säkerhetsarbete skapar möjligheter som det är som allra roligast att vara i den här branschen! Fungerar det i verkligheten? Jag har tidigare skrivit om TxOnes produkter för nätverkssäkerhet i OT-system, se exempelvis nyhetsbrev #23 och #26. I samband med ett införande av dessa produkter hos en industrikund passade jag på att titta på hur snabbt hanteringen av nya sårbarheter fungerar i praktiken, speciellt i de fall när TxOne och deras kompisar på "Zero Day Initiative" inte har förhandsinformation om sårbarheten. (Dvs när de har sämst förutsättningar för att agera snabbt.) Ingen som läser det här nyhetsbrevet har väl missat "PrintNightmare", den smaskiga bristen i printspoolern i Windows? Annonseringen av sårbarheten råkade ju dessutom bli lite snurrig vilket gjorde den lite extra intressant att titta på som exempel. 1:a Juli – Sårbarheten annonserades av Microsoft efter att exploit-kod av misstag (?) publicerats på Github. 2:a Juli – TxOne är klar med en IPS-regel baserat på hur sårbarheten kan utnyttjas. Regeln släpps på validering i 72 timmar för att säkerställa kvaliteten. 6:e Juli – IPS-regeln släpps för nedladdning och min kunds system laddar automatiskt ner filen. EdgeIPS och EdgeFire skyddar omgående mot sårbarheten även på helt opatchade system. Hur ska man tänka om det här då? Man kan tycka att det är lite långsamt att det tar flera dagar från annonsering till aktivt skydd? Personligen tycker jag inte det eftersom: Om man har möjlighet att lägga på kritiska patchar snabbt så hade det förstås kunna göras snabbare. MEN! Det förutsätter att man kan installera patchar i sin produktionsmiljö. Och att man vill installera sprillans nya (och därmed relativt oprövade) patchar där. Det här är den långsamma varianten av händelseförloppet. I det här fallet var TxOne och Zero Day Initiative inte alls inblandade i upptäckten av sårbarheten. Ofta är de det och då har IPS-regeln förberetts redan innan sårbarheten är publik och kan släppas i samma ögonblick som Microsoft annonserar sårbarheten. Den 6:e Juli har kanske några enstaka, riktigt snabba, verksamheter börjat installera den här patchen på sina mest kritiska och mest utsatta system. Extremt få organisationer kommer att ens vara nära att göra det på servrar och PC i någon form av OT-miljö. Det här är snabbt! I efterhand har det visat sig att Microsoft ”klantade till” sin patch så den inte skyddar mot alla varianter av attacker mot dessa sårbarheter. Eftersom TxOne skapar sitt skydd på ett oberoende sätt är det osannolikt att de två har samma problem vilket gör TxOne till ett vettigt skydd även för patchade system i det här fallet! Totalt sett tycker jag personligen att man håller vad man lovat med råge! Att kunna gå från noll till implementerat skydd i OT-system på några få dagar slår det mesta jag sett. Självklart måste man som alltid själv besluta om det finns risker med att släppa på den här typen av skydd men jag skulle själv föredra en produkt som testas utifrån OT-världens förutsättningar än något annat som forceras ut på andra premisser. Det är riktigt roligt att se lösningar som ger relevanta lösningar på praktiska problem och som fungerar i verkligheten! Massor med MOXA! MOXA är ett företag som det nästan inte går att undvika om man rör sig i OT-världen. De tillverkar en väldig massa intressanta prylar, allt från serieportar och mediakonverterare via nätverksswitchar och accesspunkter till datorer och säkerhetsutrustning. Här i nyhetsbrevet har de dykt upp flera gånger som en av delägarna (tillsammans med Trend Micro) av TxOne. Jag fick nyligen möjlighet att utforska en del andra delar av deras sortiment och tänkte fokusera på de delar som har mest med säkerhet att göra här. Det blir TxOne-grejor och VPN-tjänster. Funderar du över deras switchar, I/O-enheter eller powersupplies så är det bara att höra av dig! Om vi börjar med grejorna från TxOne så säljer ju MOXA och Trend Micro dem var för sig även om produkterna förstås är väldigt lika. Men de är inte identiska, och jag tänkte fokusera på skillnaderna här. För att läsa mer om det gemensamma hänvisar jag gärna till nyhetsbrev #23. En skillnad mellan bolagens erbjudanden är också att den stora rackmonterade varianten "EdgeIPS Pro" som jag skrev om i nyhetsbrev #26 bara finns i Trend Micros erbjudande. Redan på utsidan finns det skillnader. Samtliga är små men massiva pjäser med enorma kylflänsar som möjliggör drift utan fläktar från -40˚C upp till +75˚C. De små IPS-enheterna är identiska på utsidan förutom loggorna. MOXA kallar dem EtherCatch och Trend Micro kallar dem EdgeIPS. De större brandväggarna har några intressanta skillnader redan på utsidan. Båda tillverkarna kallar dem EtherFire men där slutar också likheterna. MOXAs variant är lite mer kompakt till formatet vilket kan vara en fördel, jag har själv varit med om att den mer avlånga varianten från Trend Micro inte fick plats mellan två kabelrännor i en maskin. Å andra sidan saknar MOXAs variant RJ45-portar för WAN-anslutningen och har istället enbart SFP-portar, från Trend Micro får du båda varianterna. MOXAs variant är intressant nog förberedd med kabelplintar för en digital insignal och en reläutgång för felindikering men de verkar inte vara aktiva i den nuvarande versionen. Administrationsgränsnitten är väldigt lika. Dock ska man komma ihåg att om man använder de smidiga management-servrarna så verkar man inte kunna blanda produkter från MOXA och Trend Micro. De är enkla att sätta upp och man kan snabbt vara igång. Att MOXA och Trend Micro som företag har lite olika bakgrund skiner igenom i administrationen av virtuell patchning och IPS-funktioner. MOXA som väl kan sägas traditionellt har vänt sig till automationsfolket i första hand har skalat ner möjligheterna detaljkonfigurera IPS-reglerna till förmån för att göra det enkelt att konfigurera, det är av eller på... Trend Micro som kommer mer från IT-världen ger fler möjligheter att själv styra över vilka IPS-regler som ska användas men det ger förstås en ökning av komplexiteten. Personligen har jag ingen stark preferens åt något håll, båda uppläggen har sina fördelar. Ni som läst mina artiklar om TxOne tidigare vet att jag gillar deras produkter. Det var intressant att se de skillnader man valt att skapa mellan de två produktlinjerna. Vilken man föredrar kanske handlar mest om personlig preferens och vilken leverantör man vill jobba med. Funktionaliteten är lika imponerande i båda två och om man tänker sig att bygga segmentering med stöd för IDS/IPS och Virtuell patchning fysiskt nära sin automationsutrustning så känner inte jag till något starkare erbjudande än det som TxOne kommer med! Den andra produkten från MOXA som jag tittat närmare på är MRC, "Moxa Remote Connect". MRC är en VPN-lösning som kombinerar central styrning med lokal anslutningar. Det här med fjärranslutningar är ju något som jag skrivit om många gånger förut, det är ett svårt problem som leder till kluriga utmaningar säkerhetsmässigt. När jag tittat på den här typen av lösningar tidigare så har det ofta handlat om verksamheter som har riktigt höga krav på skydd. Där man, förutom en skyddad uppkoppling, behöver ha koll på exakt vem som kopplar upp sig, vem som har rätt att släppa in dem och vad de faktiskt gjorde. Men om verksamheten inte har så extrema krav, vad gör man då? Hur gör man någonting åtkomligt på Internet men med så få av de risker som det innebär att sätta en klassisk VPN på nätet? Vi hör dagligen om dåligt patchade VPN-tjänster som missbrukas av elakt folk... Lösningen som jag tittat på från MOXA kombinerar små, smidiga VPN-enheter med en molntjänst där den faktiska ihopkopplingen sker. Det innebär att den fysiska VPN-enheten inte "syns" på Internet eftersom den också kopplar upp sig mot molntjänsten. Självklart är vi därmed beroende av att MOXA sköter säkerheten i sin molntjänst men tanken med den här typen av lösningar är att det sannolikt går bättre än att hålla lokala VPN-tjänster uppdaterade. Vill man hellre köra "molntjänsten" i egen regi så går det också att göra. Den fysiska enheten finns i ett par varianter, med eller utan 4G-stöd. De går att koppla in på ett antal sätt, antingen "osynligt" i ett befintligt nätverk eller som en mer klassisk router. På undersidan finns en digital ingång och en reläutgång som ger möjlighet att styra om det ska gå att koppla upp sig med hjälp av en nyckelbrytare eller styrt av en PLC. Reläutgången ger dig en indikering på när uppkopplingen används. I molntjänsten konfigurerar du dina VPN-enheter och dina användare. Du styr vem som ska ha tillgång till vad om 2-faktorinloggning ska användas. För att få till den första konfigurationen kan du (om du vill) skicka den som en fil till personen som ska koppla in VPN-enheten. Man lägger filen på ett USB-minne som ansluts till enheten och vips så är den konfigurerad! Smidigt och enkelt sätt att undvika att man behöver ha folk på plats som kan produkten. För att koppla upp sig installerar man MOXAs VPN-programvara som även den kan konfigureras genom att skicka en fil till användaren. De enheter man har tillgång till dyker upp i programmet och du väljer med ett klick vilka som ska kopplas upp just nu. I och med att du kan arbeta mot flera olika gateways samtidigt blir det här ett otroligt smidigt verktyg. Med samma lösning kan du också skapa site-till-site anslutningar så att utrustningar kan "prata" med varandra. Naturligtvis ska man komma ihåg att det är en VPN-tjänst och ingenting annat. Behöver man mer skydd än vad krypterad fjärrkoppling med bra behörighetsstyrning kan ge så finns det andra (betydligt dyrare) lösningar. Behöver man inte mer så är det dumt att köpa något man inte vill ha! I det här fallet ingår molntjänsten när du köper burken även om det förstås finns vissa begränsningar i mängden data och antalet enheter du kan ansluta. Det här känns som en enkel lösning att komma igång med som man inte kommer växa ur i första taget. Du kan hantera flera olika typr av behov med samma lösning vilket är bra supportmässigt. Möjligheten att styra när det går att koppla upp sig via en digital ingång känns som ett bra sätt att låta anläggningens operatörer kan styra över när det är säkert att hantera den på distans. Tips om event och mer läsning! Den 26:e Augusti går årets Xday av stapeln. Jag är en av talarna under rubriken "Stå stadigt med säker OT". Exakt vad jag kommer prata om får ni höra om ni är med! Skynda att anmäla dig! https://resources.trendmicro.com/Xday2021.html Riktigt bra snabbguide till alla delar av ISA 62443 från Verve. https://verveindustrial.com/resources/blog/the-ultimate-guide-to-protecting-ot-systems-with-iec-62443/ Verica delar ut boken "Chaos Engineering - System Resilience in Practice" alldeles gratis. Jag skrev om Chaos Engineering i Nyhetsbrev #20, denna intressanta metod som kanske är mest känd från Netflix som löpande testar sin infrastruktur genom att med flit introducera slumpmässiga fel. Boken är inte specifik för OT men har ett kapitel kring Cyberfysiska system som bland annat tittar på relationen mellan kaos-engineering och FMEA. Det finns också intressanta kopplingar till säkerhetskultur. https://www.verica.io/book/ Jake Brodsky delar med sig av sina tankar kring kryptering i styrsystem, ett område som blivit hett de senaste veckorna. https://scadamag.infracritical.com/index.php/2021/07/09/applying-cryptography-to-control-systems/ En liten rant från Dale Peterson om orden vi använder och deras betydelser. https://www.linkedin.com/pulse/terminology-tipping-points-dale-peterson/?trackingId=NJQY0x3BI3%2B2m1fW8K9ZfQ%3D%3D För den som vill läsa mer av mina alster så finns några av mina artiklar med koppling till OT-säkerhet på Ateas officiella blogg. Var läcker din båt? https://www.atea.se/it-specialisten/sakerhet/var-lacker-din-bat/?pid=19773 Jag hade fel! https://www.atea.se/it-specialisten/sakerhet/jag-hade-fel/ Säker programmering av PLC! https://www.atea.se/it-specialisten/sakerhet/saker-plc/ Vad är NIST? https://www.atea.se/it-specialisten/sakerhet/vad-menas-med-nist/ Sluta segmentera! https://www.atea.se/it-specialisten/sakerhet/sluta-segmentera/ Det nya NIS-direktivet, "NIS2": https://www.atea.se/it-specialisten/sakerhet/ett-helt-nytt-nis-direktiv-ar-pa-vag/ Vad är OT-säkerhet?: https://www.atea.se/it-specialisten/sakerhet/ot-sakerhet-vad-ar-det/ En jämförelse mellan ISO 27000 och ISA 62443: https://www.atea.se/it-specialisten/sakerhet/isa-62443-battre-an-iso-27000/ Industri 4.0 blir lättare och säkrare med NAMUR NOA: https://www.atea.se/it-specialisten/sakerhet/klurigt-med-industri-4-0-svaret-ar-noa/ Det nya maskindirektivet: https://www.atea.se/it-specialisten/sakerhet/ce-markt-sakerhet/ Det här nyhetsbrevet vänder sig till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Jag firar att det trettionde nyhetsbrevet är utgivet med en snabb kopp kaffe innan det är dags att fortsätta skriva på nummer 31 och 32. Nej, allvarligt talat så känns det riktigt stort att "ha fyllt 30"! Jag hade aldrig trott att gensvaret skulle bli så här stort när jag drog igång nyhetsbrevet för snart två år sedan och skickade det första utskicket till mina dåvarande fyra (!) läsare... Nyhetsbrevet kommer förstås alltid att vara extremt nischat, men med tanke på just detta så är de 500-700 läsare ett inlägg har idag helt fantastiskt! Det har börjat dyka upp läsare utanför Sverige med önskemål om engelska men jag kommer hålla kvar i att skriva på svenska som förstaspråk. Den här gången känner vi måltavlan på våra ryggar, funderar vilket sätt vi ska stava till "Industrie 4.0", läser en ny del i NAMURS NOA-serie och hittar nya sätt att mäta risker. Du får också mina bästa pod-tips och en massa annat. Ett riktigt varmt tack till er alla som läser mina spretiga tankar om detta udda, men ack så viktiga, ämne. 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 i allra högsta grad är ett hobby-projekt, då det till största delen skrivs hemma i TV-soffan. Framöver kommer jag försöka öka tempot lite i utgivningarna men istället låta innehållet bli motsvarande kortare. Jag siktar på att ge er nyhetsbrev ungefär var 14:e dag framöver även om det kan variera lite, inte minst över sommaren. 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å vissa artiklar från nyhetsbreven 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! Känner du måltavlan på ryggen? Häromdagen läste jag en artikel av Vytautas Butrimas som, precis som vanligt, gör en radda kloka observationer. Huvudpoängen är att organisationer som sysslar med kritisk infrastruktur aldrig får glömma att de är väldigt utsatta. Att allting som de gör (eller låter bli att göra) kommer aktörer i omvärlden att försöka utnyttja. Det här är förstås egentligen inga nyheter för någon. Samtidigt tycks det vara lätt att glömma att slutmålet för angriparna inte är att slå mot den kritiska infrastrukturen i sig utan att använda den som ett slagträ mot samhället i stort. Dels som en störning och dels som en kraftfull psykologisk effekt. Det här är viktigt att komma ihåg när man sitter där i sin risk-workshop och undrar "varför skulle någon vilja angripa oss?". Att alltid känna måltavlan på ryggen och att alltid peka på jobbiga begränsningar är tufft. Här är det viktigt att man har vettiga rutiner för belysa risker i alla typer av ändringar som kan påverka säkerheten. Något som jag personligen tycker är en underskattad komponent i det sammanhanget är att ge organisationen en gemensam syn på de hot som man står inför. Om alla i organisationen har samma bild av vad man behöver skydda sig mot blir säkerhetsarbetet oerhört mycket enklare. Organisationer som har verksamheter som faller under säkerhetsskyddslagen och som tillhör någon av de två högsta konsekvensnivåerna (och därför kallas "Särskilt säkerhetskänslig verksamhet"), får ju en så kallad DHB, "Dimensionerande Hotbeskrivning", av SÄPO och tillsynsmyndigheterna. Även om man inte bedriver säkerhetskänslig verksamhet, eller inte ens kritisk infrastruktur, tycker jag något i stil med en DHB är ett fantastiskt kraftfullt sätt att definiera sin egen kravnivå. Det är något som passar alla typer av organisationer! Men se samtidigt upp så att ni inte stoppar in en massa onödigt känslig information i i beskrivningen, den får inte bli "hemligstämplad" - innehållet behöver ju vara känt inom den egna organisationen för att kunna göra någon nytta! Om man sedan lyckas kombinera känslan av en ständig måltavla på ryggen med tänket "assume breach", dvs att man antar att angreppen redan lyckats och därför behöver kunna upptäckas och hanteras så har man sannolikt den perfekta inställningen till sitt säkerhetsarbete! Inget av det här är specifikt för OT-säkerhet men jag tror att det är extra viktigt för oss. Eftersom vi ofta har lite mer extrema konsekvenser med i vår riskekvation och eftersom vi gärna blir lite begränsade i vilka säkerhetsåtgärder som är möjliga att använda blir det helt avgörande att klyschan "Säkerhet är en del i allt vi gör" faktiskt inte är en klyscha. Jag skulle vilja utöka den till att "Säkerhet är en del i allt som ALLA gör" så att vi får med alla på tåget. Lite på samma tema har det börjat gå upp för allt fler att IT och OT inte bara är ett hot mot varandra utan att de båda två tillsammans ofta är helt avgörande för att kunna bedriva en verksamhet. Tiden när vi kunde "köra vidare utan IT" är förbi för de flesta verksamheter. Det är lite märkligt att så många blev förvånade över att man "stoppade driften" av pipelinen i östra USA nyligen på grund av ett IT-angrepp. Det beror kanske delvis på att man inte förstår hur den typen av verksamhet funkar och delvis på att händelsen fördummats i diverse media som att "de inte ville köra produktionen om de inte kunde fakturera". Det talas om "konvergensen mellan IT och OT", vilket många väljer att tolka som att systemen växer ihop. Jag ser det inte på det sättet, även om förstås integrationen mellan de två världarna ökar. Istället är det viktiga att verksamhetens risker blir allt mer gemensamma mellan IT och OT. Stannar produktionen så har den stannat, om det var IT eller OT som "ställde till" det spelar mindre roll. Vi har i alla fall passerat punkten där man inte längre kan skylla bristande säkerhetsarbete på "att man inte visste". Om verksamhetens ledning inte arbetar aktivt med risker och säkerhet idag så är man antingen inkompetent eller förd bakom ljuset. Att medvetet välja att göra ingenting är självklart fortfarande möjligt men det är inte längre ett automatiskt utgångsläge. Vi som arbetar med säkerhet har ett stort ansvar att förmedla en korrekt bild till vår ledning och våra medarbetare! Mer NOA från NAMUR! Det duggar tätt mellan storstilade leveranser. Bara dagen efter att "Top 20 Secure PLC Coding Practices" lanserades (som du såg i förra nyhetsbrevet) dök nästa del av NAMUR Open Architecture (NOA) upp. Nu är det dokumentet NE 176 “NAMUR Open Architecture – NOA Information Model“ som är tillgängligt, den tredje delen av totalt fem planerade. Det här är femte delen i min serie om standarder och ramverk. Första avsnittet handlade om ISA/IEC 62443 och finns i nyhetsbrev #26. I nyhetsbrev #27 tittar jag på NAMUR NOA. I nyhetsbrev #28 tittade jag på NIST CSF, NIST 800-53 och NIST 800-82 men du fick också lite mer om NOA som en bonus. I förra nyhetsbrevet tittade jag på den nya versionen av CIS Controls och funderade på hur den passar för OT. Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig! Jaha? Kanske du undrar... "Informationsmodeller! Vad har det med OT-säkerhet att göra?" Inte så mycket på ytan kanske men i praktiken tycker jag att det är helt avgörande för säkerheten i en OT-verksamhet som börjat ta sig mot "Industri 4.0". Om det är någonting som förstör de bästa säkerhetsmässiga intentioner så är det integrationer mellan system där man tagit genvägar. Usla API:er, dåliga nätverksprotokoll och allmänt kass koll på vad som kommunicerar med vad, leder ofelbart till att den där fina segmenteringen förstörs och din dyra brandvägg blir bara en schweizer-ost med blinkande lampor... Det som är kul med att just den här delen blev tillgänglig är att vi nu har tillgång till de tre viktigaste delarna. Det som vi inte fått ännu är "NE 178 – NOA Verification of Request" och "NE 179 – NOA Aggregating Server" som förvisso är viktiga och intressanta men inte helt nödvändiga för att börja använda det här smarta tänket. Och precis det är ju viktigt att komma ihåg - man måste ju inte använda alla detaljer i NOA utan kan också nöja sig med att luta sig mot tänket. Det gör vi hos några av mina kunder just nu, där det viktiga är att se datainsamlingen som en separat funktionalitet värdig egna system och egna nätverk så att man inte påverkar befintliga produktionsutrustningar. Hur långt man vill gå med exempelvis diodbaserade envägslösningar kan man ju låta styras av sina riskanalyser. I mitten av juni gick konferensen "Dialog Days - Edition Process Automation", anordnad av den spännande tillverkaren Phoenix Contact, av stapeln. En av diskussionspassen var just kring NAMUR NOA. Kan vara intressant om du vill förstå NOA bättre. Hur passar då det här med NOA in i "Industri 4.0"? Varför ges NOA-dokumenten ut på engelska och tyska? ...och är det uppenbart vad vi egentligen menar med "Industri 4.0"? Ett ämne som jag tyckte var värd en egen liten text... Industri 4.0? Industry 4.0? Industrie 4.0? Är det bara olika stavningar av samma koncept eller finns det mer i den underliggande betydelsen? Jag har hittills inte sett någon officiellt uttalad skillnad men jag börjar personligen se viktiga skillnader som kommer kunna leda till riktigt dyra missförstånd som dessutom får säkerhetskonsekvenser! När man kommer ner under ytan på begreppen "Industri 4.0", "Industry 4.0" eller "Industrie 4.0" märker man att det finns två ganska olika betydelser av dem. Orginalet är förstås det formella "Industrie 4.0" som definieras av "Plattform Industrie 4.0" som i sin tur drivs av tyska staten. Den andra är något slags luddigare och mer vardaglig betydelse i stil med att "stoppa in IoT-sensorer, dataflöden och analytics i industrin för att göra smarta saker!". Och det kanske är precis så att vi ska skilja på begreppen? Personligen kommer jag i fortsättningen försöka använda "Industrie 4.0" när jag tänker på den tyska formaliserade betydelsen och "Industry 4.0" för den enklare varianten. Apropå enklare så har "tyskarna" nu börjat förkorta "Industrie 4.0" till "I4.0", så nu har vi ett begrepp till! För den som inte trängt in i det enorma arbetet som "Plattform Industrie 4.0" bedriver kan det vara svårt att inse omfattningen av resultatet och de löften som det ger. Det blir speciellt tydligt när man kommer in på det som kallas AAS eller "Asset Administration Shell". Extremt förenklat kan man säga att det är en datamodell för hur man beskriver vilket fysiskt objekt som helst i en industri, oavsett om det är en produkt, en maskin, ett dokument eller en motor. Datamodellen är standardiserad och finns beskriven ner på fältnivå för både kommunikation mellan organisationer och för dataflöden i en produktionsprocess. Det finns samarbeten som ska säkerställa att exempelvis ID-nummer för alla dessa typer av prylar blir standardiserade på ett sätt som fungerar både i de tekniska standarder som förordas (framför allt OPC UA) men också i en massa andra standarder för kommunikation och fältbussar. Men det är inte bara teknik utan även metoder för att köpa och sälja tjänster online som passar in direkt i organisationer som följer standarderna. Det står naturligtvis var och en fritt att ta till sig alla dessa tankar och standarder i den omfattning man vill. Extremerna är väl att antingen gå all-in eller att sno själva tänket i exempelvis "NAMUR Open Architecture" men applicera det på ett eget sätt. Högst personligen är jag osäker på hur den extremt formaliserade "tyska modellen" kommer lyckas i framtiden. Min osäkerhet beror just på den enorma komplexiteten i helheten även om jag förstås tilltalas av den enorma elegans som genomsyrar mycket av tänket. Att det till stor del drivs av tyska organisationer hindrar inte att vi andra använder resultatet eftersom allting dokumenteras på både tyska och engelska. Däremot sker en del spännande diskussioner på tyska och där blir i alla fall jag snabbt utelåst även om jag försöker putsa upp min skol-tyska. Säkerhetsmässigt har det ju definitivt fördelar med hög standardisering men jag ser också risker om man tillämpar standarder och lösningar som man inte riktigt förstår själv och därmed inte kan hantera riskerna med. För risker finns det ju. I allting. Alltid... Däremot gillar jag personligen att plocka riktigt snygga koncept, som exempelvis NOA, för att applicera en arkitektur hos mina kunder som bygger på tänket även om vissa tekniska lösningar är annorlunda. Är allt redan sagt om risker? Om du har följt mitt nyhetsbrev ett tag så har du läst mina kritiska tankar kring riskanalys. (Exempelvis konsekvensdrivet riskarbete i Nyhetsbrev #25 och #26 eller kvantitativa metoder i Nyhetsbrev #16.) Då vet du att jag har lite svårt för de där klassiska workshoparna där man i grupp gissar sannolikhet och konsekvens för ett antal hopfantiserade risker. Fastän det är kvalitativa enheter man "mäter" med så försöker man sedan gärna sig på att multiplicera dessa "värden" på risk och konsekvens. Allt för att det ska kännas som man varit noggrann och matematiskt exakt. Men... Det var faktiskt inte det jag tänkte gnälla om den här gången... Nej, jag snubblade nyligen över en 11 år gammal artikel på den medicinska sajten "Medical Device and Diagnostic Industry". Nog för att det finns en massa spännande OT-teknik inom sjukvården men den här gången var det riskanalys det handlade om med en lite ny vinkel som jag gillade. De lyfter fram ett antal andra dimensioner, utöver sannolikhet och konsekvens, som är värda att fundera över och använda för att gradera risker. Flera av resonemangen känner jag igen från min tid inom kärnkraftsbranschen. Jag ska inte försöka återberätta hela artikeln utan rekommenderar att du läser den. De "nya" vinklarna som man föreslår att man utökar sin analys med är: Detectability, vilket på svenska väl blir "upptäckbarhet". Alltså hur lätt är det att upptäcka händelsen innan den får sin konsekvens. En väldigt sannolik risk med hög konsekvens förvandlas ju från läskig till bara störig om den är enkel att upptäcka innan skadan uppstår. Man får förstås vara noga med att bedömma rätt sannolikhet så att resonemanget går ihop. Correctability som då kanske blir "åtgärdbarhet" eller "hanterbarhet"? Det handlar om att man vill prioritera de risker som är enkla att åtgärda för att få maximal total riskreduktion i säkerhetsarbetet. Här får man förstås se upp så det inte går över styr men eftersom vi sällan har obegränsat med resurser blir det gärna viktigt att satsa på rätt häst. Product Utility är det klurigaste av dessa medicintekniska resonemang att dra en vettig parallell till för OT-säkerhet. Översatt till svenska och OT blir det "verksamhetsnytta" eller kanske "riskaptit"? Det handlar om att det kan vara lättare att "stå ut med" risker för system som ger stor nytta eller tvärtom att man inte tolererar att risker orsakas av system som ändå inte ger stor nytta. Värt att resonera om speciellt i sammanhang där risker uppstår i ett system men "drabbar" ett annat. Som vanligt får man se upp med att skapa för komplexa modeller. Det är lätt gjort att man lurar sig själv med känslan av att vara väldigt noggrann och vetenskaplig. Även om man inte använder dessa dimensioner som formella mätvärden så är det perfekt att ta en diskussion kring. Jobba med mig i Västerås - utan att vara där! Innan jag blev konsult var jag helt säker på att det inte kunde vara roligt! Och inte kunde väl jag något som en kund skulle vara intresserad av att betala för? Det visade sig att jag verkligen hade helt fel! Just den där erfarenheten från "riktiga verksamheter" är helt avgörande för att bli en extra trovärdig konsult. Har man redan gått i kundens skor så kommer man inte rekommendera något som inte fungerar i praktiken! Och att få lära sig om en massa olika och jättespännande verksamheter är vansinnigt roligt! Säkerhetsbranschen växer så det knakar! Jag behöver fler kollegor inom alla former av säkerhet! Helst vill jag förstås ha kollegor i Västerås men det betyder inte att du måste befinna dig fysiskt här. Du kan få samma knasiga chef som jag har men sitta någon annanstans! Eller så kan du förstås tillhöra något av alla våra andra roliga kontor! Så här står det i vår annons just nu. Eftersom jag skrev texten i den själv, så håller jag förstås verkligen med om att: "Säkerhet på Atea är lika spännande och omväxlande som våra kunder! Oavsett om kunden redan är avancerad i sitt säkerhetsarbete eller en omogen nybörjare behöver vi dig med en rejäl dos kompetens och erfarenhet. Ditt kunnande kan vara brett och spänna över flera områden eller mer specialiserat på ett område som du brinner speciellt för. Exempel på kompetenser som vi har stora behov av är informationssäkerhet, it-säkerhet, GDPR, OT-säkerhet, riskanalyser, säkerhetsskydd, identitetshantering och NIS-direktivet. " Hör av dig! Oavsett var du vill jobba och med vad! Poddar? Just poddar är något som jag använder väldigt mycket för att hänga med i vad som händer i branschen! Jag föredrar de poddar som tenderar att vara "snabba på bollen" och plocka upp nyheter före alla andra. Här är en uppdaterad lista med mina egna favoriter, både kring säkerhet och annat. OT-Säkerhet: “@BEERISAC: ICS Security Podcast Playlist” – Som namnet indikerar är det inte en egen podcast utan en spellista med utvalda avsnitt från andra poddar. Det som är väldigt bra är att här hittar man avsnitt som handlar om OT även om podcasten inte är OT-specifik. ”Unsolicited Response Podcast” – Pod som drivs av Dale Peterson som är mest känd som organisatör för OT-konferensen ”S4”. ”The industrial Security Podcast” – Pod som ges ut av utrustningstillverkaren Waterfall (mest kända för att tillverka nätverksdioder). Andra säkerhets-poddar: ”SANS Internet Stormcenter Daily StormCast” – En daglig pod (5-10 minuter) om aktuella händelser. ”Risky Business” – En australiensisk pod som är min favorit av alla säkerhetpoddar. ”The Cyberlaw Podcast” - Ett gäng jurister i USA diskuterar de olika lagstiftningarna runt om i världen som påverkar säkerhet och privacy. Mer underhållande än man kanske tror… "Dataministeriet" - Jag är inte enormt intresserad av privacy-frågor men den här podden har haft många intressanta gäster och diskussioner kring dataskydd och privacy. "Hacking Humans" - En pod om social engineering i olika former. Några andra favoritpoddar som inte har ett dugg med säkerhet att göra: "Lex Fridman Podcast" - Makalöst intressanta diskussioner där ryskfödde AI-forskaren Lex Fridman pratar med "världskändisar" inom lite udda områden som fysik, kryptovalutor, kampsport, filosofi, matematik, "Exponential view with Azeem Azhar" - Fascinerande diskussioner kring exponentiell teknik och deras konsekvenser på samhället "I huvudet på en innovationsledare" - Spännande diskussioner på svenska kring innovation som leds av min gode vän och kollega Stefan Fasth. "Snedtänkt med Kalle Lind" - Riktigt nördigt kring historiskt svenskt nöjesliv "Into the Impossible with Brian Keating" - Hur intressanta gäster kan en professor i astrofysik hitta? Var beredd på att hjärnan värker efteråt... "99% Invisible" - Design och arkitektur i dess allra vidaste betydelser med vansinnigt intressanta historier. "Orbiter Dictum" - Rejäl nördighet om "popkultur" på svenska. "Home Assistant Podcast" - Podcasten för oss som använder Home Assistant för vår hem-automation. Lite skryt I förra nyhetsbrevet skrev jag om leveransen från projektet "The Top 20 Secure PLC Coding Practices Project". Det var tydligen något som projektet uppskattade så nu finns Nyhetsbrevet listat på deras webbsida under rubriken "Resources in Swedish". Kul! Tips om event och mer läsning! Den 26:e Augusti går årets Xday av stapeln. Jag är en av talarna under rubriken "Stå stadigt med säker OT". Exakt vad jag kommer prata om får ni höra om ni är med! Skynda att anmäla dig! https://resources.trendmicro.com/Xday2021.html Det pratas en del kring alternativ till CVSS som standard för att gradera sårberheter. En artikel från spanska Incibe CERT diskuteras IVSS och en del andra tänkbara möjligheter. https://www.incibe-cert.es/en/blog/industrial-cvss-alternative-calculations-different-needs Eric Cosman reder ut en del vanliga missförstånd kring vad Purdue-modellen egentligen är till för och hur dess betudelse tonats ner i ISA 62443 numera. https://www.arcweb.com/blog/whats-fuss-about-purdue-model Steffan Sørenes gör en riktigt bra genomgång av NAMUR NOA och Industri 4.0 som ställer en rad intressanta följdfrågor. https://www.linkedin.com/pulse/implementation-namur-open-architecture-noa-era-iot-cloud-sørenes/ Intressanta insikter eller balla fönster som imponerar på chefen? Hos TxOne och deras nya OT Threat Atlas får du båda i ett! https://www.tr.txone-networks.com/ Intressant artikel om TAP och SPAN för att få insyn i OT-nätverk. Jag har skrivit om detta ämne tidigare när jag tittade på produkterna från Keysight i nyhetsbrev #27 och nyhetsbrev #17. https://industrialcyber.co/article/evaluating-network-taps-vs-span-in-ot-critical-infrastructure-environments/ För den som vill läsa mer av mina alster så finns några av mina artiklar med koppling till OT-säkerhet på Ateas officiella blogg. Jag hade fel! https://www.atea.se/it-specialisten/sakerhet/jag-hade-fel/ Säker programmering av PLC! https://www.atea.se/it-specialisten/sakerhet/saker-plc/ Vad är NIST? https://www.atea.se/it-specialisten/sakerhet/vad-menas-med-nist/ Sluta segmentera! https://www.atea.se/it-specialisten/sakerhet/sluta-segmentera/ Det nya NIS-direktivet, "NIS2": https://www.atea.se/it-specialisten/sakerhet/ett-helt-nytt-nis-direktiv-ar-pa-vag/ Vad är OT-säkerhet?: https://www.atea.se/it-specialisten/sakerhet/ot-sakerhet-vad-ar-det/ En jämförelse mellan ISO 27000 och ISA 62443: https://www.atea.se/it-specialisten/sakerhet/isa-62443-battre-an-iso-27000/ Industri 4.0 blir lättare och säkrare med NAMUR NOA: https://www.atea.se/it-specialisten/sakerhet/klurigt-med-industri-4-0-svaret-ar-noa/ Det nya maskindirektivet: https://www.atea.se/it-specialisten/sakerhet/ce-markt-sakerhet/ Det här nyhetsbrevet vänder sig till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Vad levererade egentligen projektet "Top 20 Secure PLC Coding Practices"? Går det att använda den nya versionen av CIS Controls för OT? Hur får man vilken brandvägg som helst att bryta ihop? Hur förstår man säkerheten i OPC UA? Dessa spännande frågor svarar jag på i ett sprillans nytt nyhetsbrev! 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å vissa artiklar från nyhetsbreven 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! Säker PLC-programmering? Jag har teasat om det här ögonblicket i ett antal tidigare nyhetsbrev och nu är det här! Den 15:e juni släpptes det första skarpa resultatet från projektet "The Top 20 Secure PLC Coding Practices Project". Det här får väl sägas vara ett unikt, viktigt och roligt projekt som tydligen uppstod i samband med S4-konferensen förra året. Det har varit en rejäl gruppinsats som Sarah Fluchs var en av ledarna för. Jag rekommenderar att du läser hennes egna ord för att verkligen förstå bakgrunden och storheten i detta projekt! Det här är verkligen ett OT-säkerhetsprojekt ända ut i fingerspetsarna. De har skapat en samling goda idéer för hur man programmerar sina PLCer med målet att höja säkerhet och tillförlitlighet ur en massa olika perspektiv. Det allmänna tänket är faktiskt lite likt CIS Controls även om innehåll och fokus är helt annorlunda. Syftet ligger väl egentligen närmare OWASPs rekommendationer för säker programmering. Missförstå nu inte det här som att PLCn plötsligt ska kunna försvara sig mot en hacker! Nej, det handlar i första hand om att låta PLCn gör lite mer av det den redan är bra på, att hålla koll på att saker beter sig rätt och att vara väldigt stabil. Man kan väl grovt summera de tjugo punkterna i tre kategorier: Validera att det som händer i den fysiska processen faktiskt borde kunna hända och att information som hanteras är korrekt. Tar rörelser rätt tid? I vilket tillstånd ska vi sätta processen efter en omstart? Är de indata vi får fysiskt möjliga? Är de inställningar som operatören gör rimliga? Här är det väldigt likt vad OWASP gör för säker IT-programmering. Hur man skriver PLC-kod: modularisering, hantering av registerblock men också att faktiskt använda PLCn för all hantering istället för att som man ser ibland, låta MES-system eller liknande ta över delar av den fysiska hanteringen. Härdning och robusthet: Kontroll av checksummor, blockering av oanvända ingångar och protokoll eller att begränsa åtkomst till funktioner från andra system. Men sedan finns det faktiskt en del möjligheter till självförsvar också. En del moderna PLCer kan exempelvis hålla koll på sin egen minnesanvändning eller på cykeltiderna för programmen. Eftersom de tenderar att vara väldigt stabila över tid så kan det vara värt att larma om de plötsligt förändras, eftersom det skulle vara ett tydligt tecken på att någon förändrat någonting. Dokumentet är föredömligt lättläst och kortfattat. Det är i egentligen en lista rätt och upp ner där var och en av de tjugo rekommendationerna på en till fyra sidor var. För var och en beskrivs: Själva rekommendationen Vad syftet med den är Vem den vänder sig till Väldigt jordnära vägledning Exempel på hur den kan implementeras i PLCer från olika tillverkare Argument för varför detta är en god idé för säkerhet, pålitlighet och underhåll Referenser till MITRE ATT&CK for ICS och ISA 62443. Tydligen diskuterar man med gruppen som driver "MITRE CWE" om att samarbeta mer framåt vilket ju skulle kunna vara både smart och spännande. Det finns ju en del uppenbara beröringspunkter. I dokumentet hittar du apropå det även en bra korsreferenslista till ISA 62443, MITRE ATT&CK och till CWE som kan vara värdefull. Det här är ett projekt som kommer påverka hur PLC-tillverkarna beter sig framöver. Vi kan nog räkna med att de kommer göra allt för att underlätta användningen av de tjugo åtgärderna. Peka dina kollegor som hanterar PLCer i vardagen till det här nyhetsbrevet och till projektet. De kanske inte ser sig som programmerare men det är de faktiskt. Vivek Ponnada skrev en bra artikel om just detta: https://www.linkedin.com/pulse/what-has-ladder-logic-got-do-cwe-vivek-ponnada/. Du hittar projektet på deras sprillans nya sida: https://www.plc-security.com/ . Vill du läsa vad andra skriver om projektet finns en bra artikel av Kelly Jackson Higgins på DarkReading. Jag kommer med stor sannolikhet återkomma till det här ämnet i framtida nyhetsbrev om ni läsare är intresserade? Hör av dig! Har du åsikter om innehållet så vill jag väldigt gärna höra dem! CIS Controls Det här är fjärde delen i min serie om standarder och ramverk. Första avsnittet handlade om ISA/IEC 62443 och finns i nyhetsbrev #26. I nyhetsbrev #27 kan du läsa del två där jag tittar på NAMUR NOA. I förra nyhetsbrevet tittade jag på NIST CSF, NIST 800-53 och NIST 800-82 men du fick också lite mer om NOA. Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig! För några veckor sedan fick vi version 8 av "CIS Controls". Kärt barn har många namn, genom åren har vi även kallat den "CIS CSC, Critical Security Controls, CIS 20, CCS CSC, SANS Top 20 och CAG 20". Det här är helt enkelt en sammanställning av de absolut viktigaste IT-säkerhetsförmågorna och är tänkt att passa alla typer av organisationer. Fram tills nu har det varit 20 förmågor men från version 8 har man byggt om strukturen lite och gått ner till 18 stycken: Inventory and Control of Enterprise Assets Inventory and Control of Software Assets Data Protection Secure Configuration of Enterprise Assets and Software Account Management Access Control Management Continuous Vulnerability Management Audit Log Management Email Web Browser and Protections Malware Defenses Data Recovery Network Infrastructure Management Network Monitoring and Defense Security Awareness and Skills Training Service Provider Management Application Software Security Incident Response Management Penetration Testing För var och en av de 18 förmågorna får vi en genomgång av varför den är så viktig att den kvalar in bland de 18, ett antal rutiner och verktyg som behövs för att förmågan ska bli effektiv och ett antal handgripliga åtgärder som skapar själva förmågan. Totalt är det 153 åtgärder. "Hur ska man välja i en så lång lista?" är en berättigad fråga som har ett utmärkt svar... En viktig skillnad från tidigare versioner är att man sedan version 7.1 inte längre säger att förmågorna står i prioritetsordning. De har istället numera prioriterat åtgärderna i tre kategorier, IG1, IG2 och IG3. IG1 betraktas som "hygiennivån" som alla organisationer borde uppfylla. IG2 och IG3 bygger sedan vidare på det för större och mer riskutsatta organisationer. Personligen tycker jag steget från prioriterade förmågor till prioriterade åtgärder är helt rätt. MEN! För oss med OT-fokus är min bedömning av indelningen i de tre grupperna inte riktigt matchar vad jag normalt skulle sätta som prioritering. Jag ska inte dyka ner i en generell genomgång av CIS Controls 8 utan rekommenderar att du tar en titt på det arbete som Christoffer Strömblad gör. Han är inte helt färdig när detta skrivs men det är på väg att bli en ambitiös genomgång av det nya upplägget inklusive översättningar till svenska vilket kan vara väldigt användbart! Tack för ditt hårda arbete Christoffer! Har det här något med OT-säkerhet att göra då? Nix - inte på pappret! Begrepp som "OT", "ICS" eller "SCADA" nämns knappt alls. Det närmaste vi kommer är några få rader om man ska tänka på "IoT" vilket inkluderar "Industriella styrsystem". Men varför tar jag upp det här i så fall? Jo, därför att jag tycker att CIS Controls är fantastiskt användbar även om man har sina OT-glasögon på sig. Den ersätter på inget vis ISA 62443 och NIST 800-82 men den pekar fortfarande på viktiga prioriteringar, förmågor och åtgärder som är helt rätt för de flesta organisationer med OT-verksamhet! Personligen tycker jag steget från prioriterade förmågor till prioriterade åtgärder är helt rätt. MEN! För oss med OT-fokus är min bedömning av indelningen i de tre grupperna inte riktigt matchar vad jag normalt skulle sätta som prioritering för OT-organisationer. Framför allt är det vissa åtgärder i IG2 som jag tycker är rena hygienåtgärder om man sysslar med OT. Det gäller framför allt inom förmågorna "Network Monitoring and Defense" och "Application Software Security" som helt saknar åtgärder i IG1. Men i slutändan skulle jag nog ändå gå igenom alla åtgärderna för att hitta de som är viktigast för min organisation, det är ändå bara 153 stycken. Dels är det ju förstås så att det blir allt mer "IT" även inom "OT", vilket gör ett strukturerat IT-säkerhetsarbete jätteviktigt för OT-säkerheten. Men det är ju också så att ALLA de 18 förmågorna är helt relevanta även om man enbart stirrar på sina OT-system! Jag tycker personligen att det faktiskt är ett plus att tvingas tänka "Vad betyder det här för OT?" eftersom man hjälps hitta nya vinklar på både hot, sårbarheter och åtgärder. Vi kan ta några exempel även om jag lätt hittar OT-vinklar på alla arton: 1. Inventory and Control of Enterprise Assets och 2. Inventory and Control of Software Assets De här två är ju egentligen helt avgörande för allt säkerhetsarbete, oavsett vad man sysslar med. Det ställer krav på ordning och reda i konstruktions- och ändringsprocesser. Det är också det här behovet som är en av drivkrafterna bakom det stora intresset för verktyg från företag som Nozomi Networks, Dragos och Radiflow. För att försvara något måste man veta att man har det. Definitivt en helt avgörande förmåga inom OT som man tycker de flesta OT-verksamheter borde vara duktiga på men i praktiken är det (i min personliga erfarenhet) snarare tvärt om... 3. Data Protection Men den här är väl ändå inte så användbar för OT? Nej, det kan man tycka men börjar man titta på de åtgärder som ingår i här kan man hitta en del viktiga saker för OT. En vansinnigt viktig åtgärd är hanteringen av bärbara lagringsmedia. Väl värt att fundera på både rutiner och kanske verktyg för skanning av USB-minnen i stil med Impex från svenska Sysctl. 4. Secure Configuration of Enterprise Assets and Software Definitivt en stor punkt på OT-sidan! När vi köper ny OT-utrustning har de ofta stöd för en massa bra säkerhetsfunktionalitet men det är tyvärr (i min erfarenhet) väldigt vanligt att man inte använder dem. Här är det skärpning som gäller! 7. Continuous Vulnerability Management Med den takt som sårbarheter offentliggörs nu för tiden är det helt avgörande att man blir aktiv i hanteringen av viktiga rättningar. Här blir man ju dessutom helt beroende av att förmågorna 1 och 2 fungerar som de ska! 13. Network Monitoring and Defense Här återkommer vi ju mycket till de verktyg som hjälper oss med punkt 1 och 2. Om vi av olika skäl inte kan använda alla de verktyg vi är vana vid från IT-världen för att STOPPA anggrepp får vi lägga desto mer krut på att att UPPTÄCKA märkligheter! Vi kanske dessutom kan använda OT-anpassade skydd i stil med StellarProtect och EdgeIPS från TxOne. 14. Security Awareness and Skills Training Det är förstås otroligt viktigt att alla som är insyltade i arbetet med OT-systemen vet vad de sysslar med och att de har ett lämpligt fokus på säkerhet! Det är lätt att man hamnar i att "Det tar IT-avdelningen hand om" eller "Vårt system är inte nätanslutet"... 16. Application Software Security Här handlar det om mer än bara att ha koll på köpta programvaror. Jag vill också peka på det fantastiska initiativet "The Top 20 Secure PLC Coding Practices Project" som jag diskuterat tidigare. Nu har projektet levererat sin första version som jag diskuterar lite längre ner i det här nyhetsbrevet. 18. Penetration Testing Det här är något som betraktas som svårt inom OT-säkerhet. Och visst finns det en STOR poäng i att man inte kan panga på med en massa automatiska verktyg i produktionsmiljöer. Frågar du mig så tycker jag för övrigt att många är alldeles för oförsiktiga även inom IT-världen, kanske speciellt när det gäller tester av produktionsatta webapplikationer och APIer! Men visst kan man göra pentestning även inom OT, man får bara vara mer noggrann och ibland skapa nya sätt att åstadkomma de resultat man är ute efter! För den tidigare versionen av CIS Controls finns det guider att hämta som stöttar i användningen av CIS Controls för både IoT och OT. Jag har inte sett till några sådana för version 8 ännu, men det kommer garanterat. Tills dess kan man naturligtvis dra nytta av de gamla även om man får mappa om numrering och innehåll själv. Vad blir då min dom över nya CIS Controls? Personligen tillhör jag sedan länge fanklubben för CIS Controls och har använt den sedan den hette "SANS Top 20". Version 8 är definitivt ett fall framåt i och med de nya strukturen men kanske framför allt för det nya sättet att prioritera åtgärder som kom i version 7.1. Den innehåller inget onödigt fluff utan är tydlig och koncis med fullt fokus på förmågorna och åtgärderna. Att den inte alls fokuserar på OT stör mig som sagt inte alls om man bara använder den som ett välkänt och tydligt stöd för att fokusera på vad som är viktigast. Sysslar man med både IT- och OT-säkerhet är det ju förstås väldigt snyggt att använda samma modell och begrepp i bägge världarna även om det resulterar i olika praktiska åtgärder. Den perfekta stormen! Det här är en riktigt udda fågel i mitt nyhetsbrev! Det är en typ av utrustning som de flesta aldrig kommer i kontakt med eller ens har hört talas om. Jag har nämnt den tidigare i nyhetsbrev #27 och nyhetsbrev #25 där jag berättar vad jag använt den till och vilka några av de andra utrustningarna är som den fått spänna sina muskler ihop med. För muskler har den... Egentligen är det två produkter vi pratar om, det är dels hårdvaran "PerfectStorm ONE" och dels mjukvaran "BreakingPoint". Båda levereras av Keysight som har en vansinnig massa och otroligt spännande lösningar som jag rekommenderar att man botaniserar i om man gillar extrem teknik. Just den här hårdvaran finns i några olika varianter med olika prestanda. Den som står i mitt labb är värstingen, en tio kilos bamse med brutala fläktar som "inte passar i ett kontorslandskap"... Den har 8 stycken portar som var och en kan leverera 10 Gbit/s trafik. Det finns dock ännu grövre muskedunder i andra produktserier från Keysight som pressar ut flera Terabit i sekunden. Imponerande men kanske lite mindre relevant i OT-sammanhang... Vad är det då för magisk trafik som den ska leverera? Mjukvaran som jag använt, "BreakingPoint", har ett mycket passande namn. Syftet är helt enkelt att simulera otroliga mängder nätverkstrafik av någon önskvärd blandning och sedan smyga in attacker i detta massiva trafikflöde. Den här trafiken utsätter man sedan en säkerhetsutrustning för med två enkla frågor: "Vilka attacker upptäcks" och "När pallar inte utrustningen under trycket från all trafik". Det här är alltså en pryl som de flesta IT-organisationer inte har i sin verktygslåda. Den typiska kunden är tillverkare av säkerhetsprodukter och organisationer som testar/granskar säkerhetsprodukter. Det finns också möjlighet att köpa utvärderingstjänster baserat på det här verktyget som kan passa exempelvis för en större organisation som ska sjösätta en ny lösning. I praktiken kan det exempelvis vara en brandvägg som ska testas. Två eller flera anslutningar görs helt enkelt från "PerfectStorm ONE" till brandväggen. I "BreakingPoint" definierar man sedan ett virtuellt nätverk som kan vara mer eller mindre komplext i sig själv och som "fylls med" tusentals klienter och servrar. Man bestämmer vilka typer av applikationer som ska simuleras på nätverket, i vilken takt som trafikvolymen ska trappas upp och förstås vilka typer av attacker som trafiken ska kryddas med. Det finns stöd för närmare 500 applikationer kombinerat med 60 000 attacker och malware. För oss som intresserar oss för OT-säkerhet finns det en rejäl uppsättning med attacker mot OT-protokoll och OT-utrustningar. När man sedan kickar igång simuleringen får man löpande statistik över vad som händer, vilka attacker som eventuellt lyckades och hur väl den testade utrustningen pallar med trycket. Det är oftast en väldigt tydlig gräns när trafik tappas bort eller när utrustningen helt enkelt inte mår bra längre. Det är svårt att förmedla hur imponerande den här lösningen är i text och vilket absolut monster det är. Det måste nog upplevas. Namnet "BreakingPoint" är som sagt väl valt, jag har inte hittat någon produkt ännu som inte har en tydlig "BreakingPoint" när den utsätts för den här behandlingen. Kanske inte så förvånande men ändå... Att det fungerar i praktiken kan jag intyga eftersom jag faktiskt kunnat hitta spännande brister i kommersiella produkter som leverantörerna sedan kunnat fixa baserat på information som jag plockat ut från "BreakingPoint". Även om det här är en produkt som normalt har en relativt smal kundkrets kan det definitivt vara en intressant del i alla organisationers utvärderingar av säkerhetslösningar om man står inför ett val av brandväggar, IPSer eller någon annan nätverksbaserad säkerhetsfunktion. Man behöver inte köpa utrustningen själv utan kan köpa tester som tjänst. Bygger din organisation någon form av säkerhetslösning baserad på nätverk tycker jag att det här närmast är ett måste. Om du blir sugen på att ta hjälp eller köpa en egen utrustning kan du höra av dig direkt till mig så löser vi det! OPC UA Det är nästan omöjligt att syssla med OT utan att stöta på OPC UA. Denna de-facto-standard för kommunikation i OT-världen har fått extra uppmärksamhet, bland annat kopplat till dess snygga stöd för kommunikation med molntjänster men också eftersom tunga organisationer hyllar den, exempelvis lyfter ju NAMUR fram OPC UA som den naturliga kommunikationsmetoden för NAMUR Open Architecture. Säkerhet var ju definitivt inte ett kännetecken för dess föregångare, "OPC Classic", men OPC UA har ju utformats från grunden med säkerhet med i fokus. MEN! Det betyder ju inte att det är omöjligt att göra osäkra lösningar om man gör korkade saker... Jag har länge letat efter riktigt bra resurser kring OPC UA och dess säkerhet. Av någon anledning har det varit svårt att hitta något som jag gillar, men ibland ska man ju inte göra det krångligare än det behöver vara... Det fanns ju förstås en massa bra resurser från OPC Foundation själva om man bara tittade lite noggrant... Har du några andra förslag att tipsa om? En riktigt höjdare är den här: en "Deep dive" kring just säkerheten i OPC UA. Den är på 45 minuter och ger en riktigt bra sammanfattning. Extra skönt är att den helt struntar i jämförelser med "gamla OPC" som ju inte är speciellt rolig om man är intresserad av säkerhet. PKI, Trust Lists, https://youtu.be/pa82WydVtPY En vansinnigt detaljerad och intressant analys av säkerheten i OPC UA från tyska BSI, "Bundesamt für Sicherheit in der Informationstechnik", som dessutom visar upp en snygg användning av STRIDE-metodiken: https://opcfoundation.org/wp-content/uploads/2017/04/OPC_UA_security_analysis-OPC-F-Responses-2017_04_21.pdf OPC Foundation har en riktigt snygg Wiki med all information om OPC UA och dess totala struktur: http://wiki.opcfoundation.org/index.php/Main_Page Nyligen gick "OPC Day International" av stapeln. En vansinnig massa superspännande presentationer om allt som händer kring OPC UA. Om du inte var med live så finns allt nu på YouTube: Dag 1 https://youtu.be/Wf9O2wfpLgU Dag 2 https://youtu.be/P-FQOhvBOBU Dag 3 https://youtu.be/KPr2k-vDf2c Tips om event och mer läsning! Den 26:e Augusti går årets Xday av stapeln. Jag är en av talarna under rubriken "Stå stadigt med säker OT". Exakt vad jag kommer prata om får ni höra om ni är med! Skynda att anmäla dig! https://resources.trendmicro.com/Xday2021.html Alltid pålitliga Kelly Jackson Higgins på DarkReading tolkar Mandiants senaste analysrapport: https://www.darkreading.com/attacks-breaches/rise-in-opportunistic-hacks-and-info-sharing-imperil-industrial-networks/d/d-id/1341134 (Rapporten finns här: https://www.fireeye.com/blog/threat-research/2021/05/increasing-low-sophistication-operational-technology-compromises.html) Open Group har släppt version 2.1 av den våldsamt ambitiösa men än så länge preliminära standarden O-PAS, "Open Process Automation™" som finns tillgänglig gratis än så länge under utvärderingslicens. De knyter samman så vitt skilda saker som exempelvis Redfish, ISA 62443 och OPC UA utifrån en massa olika perspektiv som säkerhet, management, arkitektur, informationsmodeller, alarm- och eventhantering osv... Jag är själv inte så bekant med deras arbete sedan tidigare så om någon av mina läsare vet mer får du gärna höra av dig! https://publications.opengroup.org/p210 Claroty har hittat den heliga gralen! De publicerade en rapport i slutet av Maj som beskriver hur de uppnår komplett kodexekvering på PLCer från Siemens genom enbart nätverksåtkomst. De beskriver också historiken, där tidigare attacker uppnått delar av detta mål men tidigare inte nått hela vägen. Imponerande och skrämmande! https://www.claroty.com/2021/05/28/blog-research-race-to-native-code-execution-in-plcs/ En tjusig poster från SANS som beskriver hur du bedömmer säkerheten i en OT-miljö och kopplar resonemanget till NIST CSF. En snygg och enkel metodik som adresserar både teknik och mjuka utmaningar. https://www.sans.org/security-resources/posters/industrial-control-systems/ics-assessment-quick-start-guide-425 För den som vill läsa mer av mina alster så finns några av mina artiklar med koppling till OT-säkerhet på Ateas officiella blogg. Vad är NIST? https://www.atea.se/it-specialisten/sakerhet/vad-menas-med-nist/ Sluta segmentera! https://www.atea.se/it-specialisten/sakerhet/sluta-segmentera/ Det nya NIS-direktivet, "NIS2": https://www.atea.se/it-specialisten/sakerhet/ett-helt-nytt-nis-direktiv-ar-pa-vag/ Vad är OT-säkerhet?: https://www.atea.se/it-specialisten/sakerhet/ot-sakerhet-vad-ar-det/ En jämförelse mellan ISO 27000 och ISA 62443: https://www.atea.se/it-specialisten/sakerhet/isa-62443-battre-an-iso-27000/ Industri 4.0 blir lättare och säkrare med NAMUR NOA: https://www.atea.se/it-specialisten/sakerhet/klurigt-med-industri-4-0-svaret-ar-noa/ Det nya maskindirektivet: https://www.atea.se/it-specialisten/sakerhet/ce-markt-sakerhet/ Det här nyhetsbrevet vänder sig till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Den här gången funderar jag på vad folk menar när de "jobbar enligt NIST", imponeras av Guardian från Nozomi Networks, tittar på olje&gas-branschens syn på sårbarheter i safetysystem, funderar över vad en OT-incident egentligen är och rotar vidare i NOA från NAMUR. Åsså en massa annat spännande förstås! 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å vissa artiklar från nyhetsbreven 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! Långa men tomma rör... Jag har fått flera frågor om varför jag inte gett mig in i diskussionerna kring attacken mot Colonials pipeline i östra USA. Det är ju definitivt en intressant händelse, det är väl förmodligen den IT-attack som fått störst påverkan på civilbefolkningen i något land, någonsin. Möjligen undantaget händelserna kring Ukrainas elnät. Mitt svar är helt enkelt att jag inte ser någon mening med att tidigt klämma ur mig en massa listiga åsikter baserat på rykten och halvdan media-rapportering. Inte minst ur ett OT-perspektiv återstår det ju verkligen att se vad som egentligen hände och vad som gjorde att produktionen stoppades. Jag vet av erfarenhet att det oftast finns väldigt många bottnar i den här typen av händelser och väntar gärna med att dra mina slutsatser till röken har lagt sig ordentligt... En sak som diskuterats flitigt är om det var en OT-incident eller inte med tanke på att den fysiska driften stoppades av företaget själva. Personligen tror jag att de flesta som diskuterar den frågan inte har förstått hur en sådan här pipeline fungerar. Det är lätt att tro att det är ett långt rör där man dag efter dag stoppar in samma typ av olja i ena änden och får ut den igen på en annan plats. I praktiken pumpar pipeline-företaget alla möjliga petroleumprodukter åt en lång rad olika kunder och man byter fram och tillbaka relativt ofta. Det är inte heller alltid att det är samma företag som stoppar in produkten som också plockar ut den, utan försäljning sker via pipelinen. I Colonials fall så förlorade de sina system för all hantering av köp- och sälj-beställningar, vilket förstås gör det helt meningslöst att köra en pipeline! Ett begrepp som används slarvigt i lite olika sammanhang är "IT - OT Convergence" i betydelsen att IT och OT växer ihop. Personligen brukar jag undvika att använda det eftersom det är så luddigt men i Colonial-incidenten kan man ju faktiskt säga att attacken riktade sig just mot deras "IT - OT Convergence". Och då menar jag det affärsmässiga beroendet mellan IT och OT, inte något slags integration nödvändigtvis. Attacken slog ut deras möjlighet att bedriva fysisk verksamhet men utan att attackera de fysiska systemen. Här tror jag IT-säkerhetsarbetet kan ta lite inspiration från OT-världen och fokusera lite mer på Tålighet. Alltså att se till att verksamheten går att köra i något slags "nödläge" även om man förlorat sin normala effektivitet. Självklart ska vi göra allt för att stoppa attacker men någonstans går gränsen för när mer skydd mot attacker blir för dyrt eller störande och man får skydda sin verksamhet på andra sätt. Jag kan inte bedöma hur lätt det hade varit för Colonial att ha nödrutiner för att hålla igång produktionen men det hade varit ett fantastiskt sätt att köpa sig lugn och ro för att hantera den egentliga attacken. Det här är en händelse som kommer få många och intressanta konsekvenser framöver! Just pipelines är dessutom ett extra klurigt område säkerhetsmässigt så oavsett vad som hände kommer det finnas mycket att lära. Det går bra nu! Intresset kring OT-säkerhet och industriella system växer jättesnabbt. Vi behöver fler kompisar som vill arbeta med det här fantastiskt spännande området och våra roliga kunder! Du måste inte vara specialiserad på just OT-säkerhet men något slags kombination av de här kompetenserna är bra: Säkerhet - Du kanske har en bakgrund inom informationssäkerhet, OT-Säkerhet, IT-säkerhet, fysiskt skydd eller riskhantering? Industri - Du kan prata med "industrifolk", både med automationsteknikern och med produktionschefen. Du ser inte ut som ett frågetecken när de pratar om MES-system, PLCer eller SCADA. Du har upplevt hur en sådan verksamhet fungerar i verkligheten. IT-Arkitektur - Du har en bred förståelse av IT-teknik och hur IT-drift fungerar i praktiken! Du kan prata om Windows, Linux, nätverk, certifikat, brandväggar och virusskydd även om du inte är specialist på något av det. Mina kunder finns i hela landet så det spelar egentligen mindre roll var du bor, även om det förstås vore extra kul med en kollega på Västerås-kontoret Är det här du? Eller känner du den perfekta personen? Tipsa! Hör av dig! En väktare från Nozomi! Något som nästan alla verksamheter med OT-system har gemensamt är att de inte kan jobba löpande med uppdateringar, patchning och aktiva skydd i sina system. Oavsett om det är leverantörerna som håller emot på grund av garantier eller verksamheten själv för att man inte vågar göra förändringar i viktiga processer så hamnar man i ett läge där man behöver fokusera på andra säkerhetsåtgärder än de som man kanske är van vid från IT-världen. Om man ska välja ett ställe att börja på så skulle jag absolut rekommendera att skaffa riktigt bra insyn i vad man har för komponenter i sina system och vad de pysslar med. Oavsett vilken standard för säkerhetsarbete du tittar på, CIS Controls, ISO 27000, ISA 62443 eller NIST så pekar man på att bra koll sina prylar är en förutsättning för allt annat säkerhetsarbete. När man sedan har den insynen är steget inte långt att löpande använda den kollen man fått i nätverket för att aktivt leta efter händelser som är värda att stoppa eller kolla upp. In på scenen kommer då Guardian från Nozomi Networks! Det här är en av de mycket få lösningar på marknaden som första stund byggts för att passa OT-världens behov. Att den sedan råkar bli riktigt intressant även för IT-miljöer är en välkommen bonus! Guardian matas med nätverkstrafik som man kopierat från sina OT-nätverk. Trafiken analyseras och presenteras förstås men framför allt letar den löpande efter oväntade förändringar i hur enheterna på nätverket pratar och efter uppenbart skadlig trafik. I mitt OT-labb har jag just nu den minsta modellen av Guardian, "NSG-R 50". Det är en ruggad variant utan fläktar som ändå tål jobbiga temperaturer tack vare feta kylflänsar, den monteras på DIN-skena och matas med 12 - 36 V DC. En reläutgång för matningsfel hintar om ett seriöst OT-ursprung. Som synes har den fyra ingångar för att ta emot trafik. Den trafiken kan komma från SPAN/Mirror-portar i nätverksswitchar eller från tappar/aggregatorer likt dem från Keysight som jag tittade på i förra nyhetsbrevet. Management-porten ansluter man till sitt nätverk och det är den vägen man arbetar i detta imponerande verktyg. Hur är det att arbeta i då? Och vad kan man göra? Ja, det första man slås av är att det verkligen är ett OT-verktyg på riktigt! Det är inte bara att det förstår vad MODBUS eller en PLC är utan man får tillgång till massor av information som är annars är väldigt klurigt att få sammanställt i en blandad miljö. Ett bra exempel är att man till och med får insyn i vad som hänt ner på enskilda register, taggar och variabler. (Se bilden här nedan) Något man alltid hör från de som implementerat den här typen av verktyg är att "automationsfolket" blir helt exalterade över den kontroll de får på sina prylar. De kan helt plötsligt se kluriga händelseförlopp och felsöka på helt nya sätt. Jag har själv hört exempel på en test-implementation av ett annat verktyg där säkerhetsfolket som testade verktyget inte fick ta bort det efteråt för automationsingenjörerna som absolut ville ha kvar det! Det här är definitivt inte bara ett säkerhetsverktyg utan det bidrar också med riktigt starka funktioner för de som sysslar med drift, underhåll och utveckling. Det är ytterst sällan (i min egen erfarenhet) som man har en renodlad OT-miljö med bara utrustning från en enda tillverkare och där prylarna dessutom är av samma tekniska generation. Personligen tycker jag att det är fantastiskt att få en sådan överblick av en "rörig" miljö samtidigt som man kan dyka ner i vilka detaljer som helst! Det gör ingenting att du använder OSIsoft PI-server som historian ihop med PLCer från både Siemens, ABB och Phoenix Connect med ett kamerasystem från Hikvision som ligger slängt ovanpå. Du kan se alla systemen, alla protokollen och alla variabler i samma verktyg. Det är inte ett problem att titta på PI-CONNECT blandat med BACNET och RTSP, allt är tydligt och snyggt tillsammans! När du ska undersöka en misstänkt incident blir det förstås helt ovärderligt med den här helhetsbilden! Vill du ha listor så får du det men vill du jobba i interaktiva som på bilden så gör du det. Och här hittar vi nästa ovärderliga finess med ett sånt här verktyg, att du inte bara vet vad som händer just nu utan du kan även rota i vad som hänt bakåt i tiden. Att kunna svara på frågan "Vad hände i Pressningens nätverk den 14 April runt 15:30?" är i princip omöjligt utan rätt verktyg men samtidigt helt nödvändigt om du ska kunna fatta rätt beslut! Du får stöd i att snabbt och enkelt skaffa dig en uppfattning om läget. Insikter som är värda titta närmare på lyfts fram tydligt. Det kan vara klassiska misstag som att en PC har flera nätverksinterface som "kortsluter" din brandvägg eller att nya enheter dyker upp på nätverket. Undrar du över någon speciell detalj så är det snabbt gjort att kolla "vilka IP-adresser har våra streckkodsläsare från Cognex?" eller "Finns det sårbarheter i vår utrustning från Allen-Bradley?". Svaret är lätt att hitta och innehåller förvånansvärt mycket detaljer! All denna rikedom av information om våra system och hur de kommunicerar används sedan för Guardians kanske största och viktigaste trolleritrick av dem alla, att löpande analysera trafiken i jakt på konstiga eller farliga händelser. Här nedan ser du ett exempel på en analys av en gammal nätverksinspelning som visar på bredden i analysen genom ett antal bra exempel: En ny enhet dyker upp på nätet och genomför ett angrepp mot en sårbarhet i SMBv1. (Havex/Dragonfly/EternalBlue) En variabel sätts till ett värde som ligger utanför vad som betraktas som normalt. Två redan kända noder börjar kommunicera på ett nytt sätt. En ny enhet dyker upp på nätverket och gör en MITM-attack (Man In The Middle) mot två existerande system. Ett känt system försöker plötsligt ansluta till Internet Alla dessa attacker är svåra eller näst intill omöjliga att upptäcka utan en löpande analys av nätverkstrafiken med hjälp av AI/ML. I kombination med signaturbaserat skydd blir det verkligen heltäckande! När Guardian upptäcker något sånt här kan den larma dig på en rad olika sätt beroende på hur din systemmiljö ser ut i övrigt. Integrationer finns av alla sorter och med alla typer av system, allt från enkla meddelanden via epost, SNMP-traps eller syslog till riktiga integrationer med ett SIEM-system eller ServiceNow. En viktig del i allt detta är förstås att du kan berätta för Guardian hur din nätverksstruktur ser ut. Du kan använda den klassiska Purdue-modellen för att placera in dina adressområden eller VLAN på de olika nivåerna. Det gör rapporter och larm både tydligare och enklare att basera beslut om åtgärder på. På samma sätt finns alla möjligheter till integrationer för att automatisera åtgärder baserat på regler som triggas. Vill du att vissa typer av angrepp automatiskt ska få en brandvägg att blockera anslutningsförsök så finns det stöd för det. Nozomi fyller förstås hela tiden på med regler och signaturer för att upptäcka olika typer av angrepp, sårbarheter och risker. Vill du fylla på med egna regler finns möjlighet att använda YARA-regler eller STIX-indikatorer. Det är imponerande hur mycket insikter Guardian kan ge enbart genom att passivt lyssna på nätverkstrafik men om man vill ha ännu mer finns möjligheter att låta Guardian aktivt fråga systemen. Man kan fråga respektive system via något lämpligt protokoll som EthernetIP, WMI, MODBUS eller SNMP. Tanken här är att man ska våga prata även med "känsliga" system eftersom man gör det på systemets egna vilket och med ett protokoll som systemet använder "till vardags". Man kan också integrera med olika administrationssystem för att hämta information ur någon CMDB (Configuration Management Database) som exempelvis ServiceNow, Cisco ISE eller Aruba ClearPass. Har man ett mindre nätverk med upp till 500 noder räcker en liten "NSG-R 50" långt men det finns förstås en lång rad andra möjligheter också. Dels finns ett antal större syskon i olika storlekar som klarar upp till 500 000 noder. Det finns också en portabel modell som passar bra när vi konsulter åker ut för att göra en genomlysning av nuläget hos en kund. Har man ett utspritt nätverk finns en mindre enhet, "Remote Collector", som ansluts ute i verksamheten och som sedan förmedlar information till en Guardian för analys. Det finns också virtuella versioner av både Guardian och "Remote Collector" om man föredrar det. Det finns även en container-variant som går att köra direkt i nätverksprylar, exempelvis i Siemens RUGGEDCOM. Har man flera Guardians så kan man ändå arbeta samlat i deras "Central Management Console". Nozomi har också vad man kallar "Vantage", vilket är deras SAAS-tjänst. Insamlingen av trafik görs förstås i nätverket som vanligt men analys och presentation sker i en molntjänst. Det här är förstås en otroligt smidig lösning, inte minst om man har många separata sajter som man vill samla under en och samma hatt. Nozomi riktar in sin produkt mot både OT och IoT vilket jag tror passar den här typen av produkt perfekt. Inte minst i samband med Industri 4.0 där man ju förstås är extra intresserad av gränslandet mellan OT, IoT och IT. Det som kan vara en utmaning med den här typen av lösningar är att man är helt beroende av att se tillräckligt mycket trafik för att kunna göra sin analys. Här får man (som vanligt) välja sin ambitionsnivå efter sin riskanalys, sin existerande nätverksplattform och sina behov. Det fungerar ju också alldeles utmärkt att börja lite begränsat för att sedan bygga ut efter hand som man har möjlighet. Kvaliteten på den nätverkstrafik man samlar in är förstås viktig och att man inte riskerar att störa de nätverk man "avlyssnar". Där kan jag verkligen rekommendera att man löser det seriöst redan från första början, varför inte med tappar och aggregatorer som dem från Keysight som jag tittade på i förra nyhetsbrevet. Min högst personliga åsikt är att Guardian är en makalös produkt. Det är bara att gratulera Nozomi Networks till en riktig fullträff! Man kommer i ett enda slag åt ett stort antal av de riktigt kluriga utmaningar som det innebär att arbeta med säkerhet i OT-miljöer. Det är väldigt tydligt att Guardian är utformad för OT-behov från första stund vilket gör det extremt enkelt att snabbt skapa riktigt starka lösningar! Det är precis den här typen av lösning som behövs för att lösa många olika typer av säkerhetsutmaningar och på köpet får du en massa andra unika fördelar för både säkerhetsfolk och automationsfolk. Vaddå NIST? Man hör ofta att folk "jobbar enligt NIST" eller "granskar enligt NIST" när de pratar säkerhet. Men vad menar de egentligen? Och vad är det där NIST som de pekar på? Det här är tredje delen i min serie om standarder och ramverk. Första avsnittet handlade om ISA/IEC 62443 och finns i nyhetsbrev #26. I förra nyhetsbrevet kan du läsa del två där jag tittar på NAMUR NOA. Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig! Det första att tänka på är att folk kan mena lite olika saker när de pratar om NIST! NIST är en enorm organisation med 3000 anställda som driver standardisering och forskning som en del av USAs Department of Commerce. De har en väldig massa standarder inom en stor mängd områden. Lite slarvigt skulle man kunna jämföra deras standardiseringsarbete med svenska SIS även om jämförelsen haltar ganska mycket eftersom de sysslar med så mycket annat också. Inom just säkerhetsområdet är det fyra delar som de själva lyfter fram: "Cybersecurity framework", OT-säkerhet, kryptolösningar och medicinska system som trådlöst styrda medicinska pumpar. De dokument som vi OT-, Info- och IT-säkerhetsmänniskor brukar intressera oss för finns i det som NIST kallar "Special Publications" och närmare bestämt i underserien 800. Tittar man på mängden dokument ser man att Cybersecurity faktiskt är ett av deras minsta områden... Så vad menar folk med att de jobbar enligt NIST? Förmodligen är det något av dessa eller en kombination av dem: Man organiserar sitt säkerhetsarbete enligt "NIST Cybersecurity Framework" Man mäter sin säkerhetsförmåga enligt "NIST Cybersecurity Framework" Man implementerar säkerhetsåtgärder enligt "NIST SP 800-53" Man arbetar med OT-säkerhet enligt "NIST SP 800-82" Av dessa fyra är det egentligen bara 800-82 som är specifikt för OT-säkerhet. De övriga är generella även de är mycket lämpliga även för OT-verksamheter. NIST Cybersecurity Framework De flesta som pratar om "NIST" menar Cybersecurity Framework eller CSF som det brukar förkortas. Det är ett ramverk för hur man mäter risk, strukturerar riskarbete, väljer säkerhetsåtgärder och utför säkerhetsarbete i en organisation. En snygg sak är att man istället för att skapa en ny standard försöker knyta ihop en massa redan existerande standarder och rekommendationer. Man har gjort en elegant struktur i fem delar som är lätt att förstå. Det i grunden ett dokument och en lista som är tillgänglig i två versioner, antingen en lista i Excel eller ett dokument som beskriver hela modellen. På sätt och vis är det ganska likt upplägget i ISO 27000 där dokumentet motsvarar ISO 27001 och listan motsvarar ISO 27002. De fem delarna är nedbrutna i 23 kategorier som sedan bryts ner till totalt 108 underkategorier. Varje kategori och underkategori är beskriven med en enda mening och till var och en av dem finns en radda referenser till olika standarder: "Center for Internet Security: Critical Security Controls", "COBIT", "ISA 62443-2-1", "ISA 62443-3-3", "ISO 27001" och "NIST 800-53". Här ett exempel från kategorin "Protect" i listan med ett par underkategorier samt en förteckning över referenser till diverse standarder som kan användas för att implementera respektive kategori. Som du ser beskrivs varje kategori med bara en enda mening: En viktig sak som man också trycker på i själva dokumentet är att man måste vara försiktig med att prata om "compliance" gentemot ramverket i och med att det kan användas på så väldigt många olika sätt. Varje organisation uppmanas själv definiera hur man bäst drar nytta av det. På samma sätt ser man ibland att man utför granskningar av en organisation och kommer fram till en betygspoäng, "Företag X har 1.7 NIST-poäng". Det här är inte fel men man får se upp med att jämföra den siffran med andra eftersom det finns många olika sätt att värdera vad som är rätt och fel. NIST uppmanar dessutom organisationer att lägga till egna kategorier eller referenser om det behövs för verksamheten. Men oavsett allt detta är det ett väldigt starkt verktyg för att mäta sin egen utveckling! Listan med de 108 kategorierna är det som kallas kärnan i NIST CSF. Till det kommer två andra delar, "Implementation Tiers" och "Framework Profile". "Implementation Tiers" beskriver organisationens generella förmåga att arbeta strukturerat med risk men är inte tänkt att ses som en mognadsmodell utan mer som ett handfast sätt att beskriva den nuvarande förmågan och besluta vilken ambitionsnivå man vill ha. "Framework Profile" beskriver hur man sätter mål och sedan mäter uppfyllandet av de 108 kategorierna. Resultatet kan beskrivas på lite olika sätt, vanligast är en kurva eller NIST-poängen jag nämnde här ovanför. Man trycker från NISTs sida på att man inte blint ska sikta på att höja sin "poäng" utan att först värdera det man vill göra utifrån sin riskprofil och utifrån vad åtgärderna kommer att kosta. För att mäta sin egen organisation med hjälp av CSF kan man antingen göra egna självskattningar alternativt kan man låta en intern eller extern granskare göra en genomlysning. Som stöd för ett sådant arbete finns en massa olika stödverktyg som gör det enklare att ställa rätt frågor eller kontrollera rätt saker. Personligen är jag certifierad CISA-revisor och har då tillgång till ISACAs frågebatteri "Cybersecurity: Based on the NIST Cybersecurity Framework Audit Program" som jag gillar. De flesta stora revisionsföretag har sina egna modeller som de "utsätter" sina kunder för. För oss OT-människor trycker NIST i CSF lite extra på att vi måste tänka på att vi hanterar andra typer av risker så att vi inte fastnar i enbart "IT-tänk" utan även tänker på miljö, hälsa och annat som är typiskt för vår värld. Högst personligen gillar jag CSF eftersom man valt att inte skapa ytterligare en ledningssystemsstandard och för att det är väldigt lite dödkött i dokumenten. Baksidan av samma mynt är att det lämnar en hel del öppet för eget tyckande vilket förstås kan vara störande för paragrafryttare. Delen om "Implementation Tiers" är kanske värst på det viset, där har man väldigt lite att luta sig mot. Delarna kring "Framework Profiles" bör de flesta verksamheter kunna kombinera på ett bra sätt med "Security Levels" om man arbetar efter ISA 62443 för att få en snygg helhetsbild. Ramverket har en stor fördel i att det är gratis även om det förstås lutar sig mot andra standarder som inte är det... NIST SP 800-53 Det här dokumentets riktiga namn är "Security and Privacy Controls for Information Systems and Organizations" vilket förklarar precis vad det är för ett dokument, en enorm samling säkerhetsåtgärder. Den första versionen dök upp 2005 och sedan dess har det kommit fem uppdateringar som förändrat innehållet ganska mycket. Den senaste versionen dök upp i höstas där man bland annat ändrat språkbruket så att dokumentet passar mycket bättre för oss som intresserar oss för OT och IoT. Ett gäng åtgärder kring supply chain är också intressant men å andra sidan har också ett gäng privacy-krav dykt upp som ofta är mindre relevant för oss. Där NIST CSF är ett nätt dokument är SP 800-53 betydligt tyngre. Ett introduktionskapitel på 3 sidor, ett kapitel på 7 sidor med förklaringar till strukturen i dokumentet och sedan 350+ sidor med säkerhetsåtgärder! Dessutom har ett dotter-dokument SP 800-53B med 50+ sidor brutits ut som innehåller baselining för säkerhetsåtgärderna i huvuddokumentet. Sedan tidigare finns också SP 800-53A på nästan 500(!) sidor som beskriver man mäter effektiviteten hos säkerhetskontrollerna. Nu är det ju två helt olika dokument men jag kan ändå inte låta bli att jämföra med hur NAMUR skriver sina NOA-dokument från förra nyhetsbrevet, verkligen två helt olika sätt att bygga dokument! Alla dessa säkerhetsåtgärder delas in i en struktur med 20 familjer där varje familj innehåller ett antal säkerhetsåtgärder där varje åtgärd kan ha en eller flera utökningar. Dokumentet gör en poäng i att inte berätta hur man ska välja rätt säkerhetsåtgärder baserat på sin riskanalys utan pekar istället på ett antal alternativa sätt, bland andra NIST CSF. Det här är ett brutalt dokument! Vi talar alltså om över 1000 säkerhetsåtgärder som beskrivs på ett utförligt sätt. De är alla skriva på ett sätt som är helt neutralt från tekniken som används och sättet de implementeras vilket gör att det är ett rejält jobb att välja, definiera och implementera dem var och en! Å andra sidan är det en mycket komplett uppsättning i motsats till exempelvis åtgärderna i ISO 27002 som ju av det skälet egentligen kräver ännu mer arbete för att bli heltäckande. Oavsett hur man bygger sitt ledningssystem och kravkatalog för säkerhet är NIST SP 800-53 ett formidabelt uppslagsverk! I och med att det är så generellt skrivet finns mycket som är väldigt användbart även för OT-säkerhet. NIST SP 800-82 Det här dokumentet släpptes i sin första version 2011 och revision 2, som är den senaste, släpptes 2015. För några veckor sedan begärde NIST in förslag och kommentarer inför ett kommande arbete med att ta fram revision 3. Man säger sig sikta på att ha ett första utkast klart vid årsskiftet. Den nuvarande versionen av SP 800-82 är anpassad till den förra revisionen av SP 800-53 vilket gör att vi hamnar i ett litet mellanläge nu när vi väntar på en uppdatering av SP 800-82... Några intressanta områden som man verkar sikta speciellt på är bland annat: Att göra dokumentet mer inriktat mot styrsystem och automation i allmänhet snarare än det industriella fokus det har i den nuvarande versionen. Användning av moderna säkerhetsåtgärder. Anpassningar som ska passa mindre verksamheter. Generellt är SP 800-82 tänkt att "läggas ovanpå" SP 800-53 för att bättre anpassa den till OT-världens behov. Dokumentet inleds med en ganska omfattande genomgång av historiken kring OT och ger jämförelser med IT kring skillnaderna i risker och utmaningar. Om man är ny inom OT-världen är det en helt okej introduktion även om det märks att den har några år på nacken, exempelvis saknar jag alla de nya utmaningarna kring "Industri 4.0" som de flesta OT-verksamheter står mitt i idag. Inriktningen är också väldigt hårt skruvad mot processindustri och tillverkande industri medan andra sorters OT bara omnämns i förbigående, inom exempelvis fastighetsautomation, autonoma system, fysiskt skydd och energistyrning. Allt detta verkar man ju sikta på att fixa i den kommande uppdateringen! Generellt kan jag tycka att SP 800-82, precis som väldigt många amerikanska myndighetstexter, går vilse i sitt syfte och försöker vara allting på en gång. Ena sekunden luktar det skolbok när man går igenom massor av olika nätverksprotokoll för att förklara vad de används till för att sedan plötsligt i detalj gå igenom de 20 familjerna av säkerhetsåtgärder som finns i SP 800-53 för att förklara hur de funkar i OT-världen. Ena sekunden riktar man sig till ledningen och nästa stund till tekniker. Inget av det är förstås fel men det blir tungt att ta till sig den här typen av dokument! Om man använder SP 800-53 i en OT-verksamhet så finns det absolut mycket godis i SP 800-82, inte minst Appendix G som graderar alla säkerhetsåtgärder efter applicerbarhet beroende på verksamhetens riskprofil. Personligen ser jag nog oftast dokumentet som en bra inspiration och kanske ett uppslagsverk när man tittar på något speciellt säkerhetsområde. Mer NOA! I förra nyhetsbrevet gick jag igenom grunderna för NOA, Namur Open Architecture, och som utlovat kommer här fortsättningen kring deras senaste dokument, NE 177, som belyser säkerhetstänket mer. Vi saknar fortfarande tre dokument i den här serien av totalt fem, men nu kan vi på riktigt börja se vart det tar vägen, åtminstonde säkerhetsmässigt. Jag rekommenderar att du läser min förra text först som du hittar i förra nyhetsbrevet. Redan från början av den första genomläsningen får man en trygg känsla i magen eftersom de trycker hårt på att det som de beskriver är ett rekommenderat sätt att använda ISA 62443 snarare än att de försöker skapa en konkurrent. Man går så långt att man anger två delar av ISA 62443 som normativa referenser! Fantastiskt klokt sätt att resonera som verkligen hjälper oss som ska använda resultatet framåt! Dokumentet NE 177 beskriver egentligen det byggblock i arkitekturen som de kallar NOA Secure Gateway, eller ibland "NOA Dioden". En elegant finess i dokumentet är att de försökt vara tydliga med vilka kapitel som vänder sig till användare av arkitekturen och vilka som vänder sig till tillverkare av "NOA Dioder". Ett extra plus där för fokuset på läsaren och vår upplevelse! Som jag nämnde i min tidigare artikel om NOA har den en väldigt stark sida i att den från början är att passa lika bra oavsett om du bygger en helt ny miljö eller om du kompletterar en gammal automationsplattform med "Industri 4.0". Starkt! NOAs zonmodell bygger helt på tänket i ISA 62443 och ger oss tre zoner: En kallas CPC, "Core Process Control" - alltså det egentliga styr- och automationssystemet. En andra kallas "M+O onprem", "Monitoring and Optimization On-premises" - vilket är "tillägget" för Industri 4.0 som hör till den fysiska sajten. Den tredje zonen är "M+O offprem", "Monitoring and Optimization Off-premises" - en valfrit zon där information bearbetas på en högre nivå, potentiellt för flera sajter och potentiellt i något slags molntjänst. I bilden nedan är det de två röda funktionerna som ser till att information förs ut respektive in på ett säkert sätt. I dokumentet vi tittar på nu behandlas den röda boxen till vänster medan den högra kommer behandlas i det kommande dokumentet NE 178. En riktigt snygg rekommendation som de gör handlar om hur olika aspekter av säkerhet ska prioriteras i de olika zonerna. Även om detta förstås alltid är upp till varje enskild organisation gör de en intressant iakttagelse utifrån den klassiska triaden, "Hemlighet", "riktighet" och "Tillgänglighet". Var och en av zonerna har en egen rekommenderad prioritetsordning: CPC: 1 - Tillgänglighet, 2 - Riktighet och 3 - Hemlighet M+O onprem: 1 - Riktighet, 2 - Hemlighet och 3 - Tillgänglighet M+O offprem: 1 - Hemlighet, 2 - Riktighet och 3 - Tillgänglighet Du som läst mina tidigare texter vet att jag har vissa invändningar mot att enbart använda dessa tre begrepp (Hemlighet, Riktighet och Tillgänglighet) från informationssäkerhets-världen (se exempelvis nyhetsbrev #24 och #23) men här lyfter det verkligen fram en intressant vinkel och möjlighet! Den som känner till ISA 62443-3-3 vet att begreppet "Security Levels" är centralt. I NOA förenklar man upplägget i standarden genom att banta ner standardens fyra SL-nivåer till två, "NOA BASIC" och "NOA EXTENDED". De motsvarar ungefär "SL 2" respektive "SL 4" men det finns en lista med de exakta kraven som gäller om man vill använda NOAs två klasser. Vi får se när det börjar dyka upp tekniska lösningar som implementerar en NOA Secure Gateway? I grunden är det en nätverksdiod som är klädd med lämpliga applikationsproxys på bägge sidor. Det finns redan lösningar som kommer nära även om de inte formellt sägs vara utformade enligt NOA, ett exempel är Waterfall som har stöd för Historians som OSIsoft PI server och för OPC UA i sina dioder. I vilket fall som helst är NOA och tänket kring NOA Secure Gateway klockrent för att på ett enkelt och tydligt sätt haka på "Industri 4.0" på ett nytt eller gammalt OT-system. Tummen upp från min sida! Intryck från MSBs NIS-konferens Jag deltog på MSBs konferens kring NIS-direktivet i mitten av Maj. Min förhoppning var framför allt att få höra lite mer tankar kring det kommande nya NIS-direktivet men det blev tyvärr inte så mycket av den varan. De flesta dragningar från olika grupper (politiker, MSB, ENISA, EU-kommisionen mfl) kring det ämnet gick mest ut på att berätta vad de själva gör för bra saker i vardagen. Inget fel i det men det blev inte så framåtriktat som jag hade hoppats. Det som sades kring just NIS2 var egentligen mest en sammanfattning av skillnaderna mellan det nuvarande direktivet och det liggande förslaget. Av någon anledning sparades bara inspelningarna från konferensen under Maj så det finns tyvärr ingenting att hänvisa till om du vill ta del av vad som sades. Är du nyfiken på just NIS2 så har jag skrivit om det tidigare, i nyhetsbrev #21 och #23 men även i ett blogginlägg. Security for Safety En av mina favoritsaker att tjata om när jag håller presentationer är klurigheten i att svenskan har samma ord för "Safety" och "Security". Det kan tyckas vara en petitess men jag har varit med om flera händelser där projekt och verksamheter fått problem för att folk missförstått vad man menade när man sa "Säkerhet". Oavsett vad vi kallar saker så är "Security" väldigt viktigt om man ska få bra "Safety" i våra OT-system. Det finns en massa bra standarder och regelverk som man kan luta sig mot när man designar och kör system med höga krav på "Safety". Intresset för säkerhet i Safety-system ökade rejält för tre år sedan med TRISIS-attacken mot ett Saudiskt raffinaderi. Och nyligen har det varit en hel del ståhej kring något som kallas "Project 12" från LOGIIC. Och det är är verkligen det 12:e projektet från den här gruppen som egentligen heter "Linking the Oil and Gas Industry to Improve Cybersecurity". Det är den amerikanska olje- och gasindustrin som samarbetar med Department of Homeland Security kring säkerhetsfrågor. Projekt nummer 12 tittade på säkerheten i säkerhetssystem, alltså "Security of Safety systems, eller mer exakt, egentligen så letade man efter sårbarheter som skulle vara speciellt intressanta i den här typen av system. Rapporten från projektet blev precis klar och rekommenderas för en genomlösning om du är det minsta intresserad av Safety-frågor. Dale Peterson gjorde en intervju nyligen med ett par av deltagarna i arbetet, väl värd att lyssna på! LOGIIC har ett antal tidigare rapporter, närmare bestämt 11 stycken, som också är intressanta. De täcker spännande ämnen som SIS-system, virtualisering, trådlös teknik och fjärrövervakning. Tips om event och mer läsning! Den 26:e Augusti går årets Xday av stapeln. Jag är en av talarna under rubriken "Stå stadigt med säker OT". Exakt vad jag kommer prata om får ni höra om ni är med! Skynda att anmäla dig! https://resources.trendmicro.com/Xday2021.html Sinclair Koelemij ger oss en rejäl utläggning kring risk och riskbedömning, han är lika intressant som alltid: https://otcybersecurity.blog/2021/05/09/cyber-risk-assessment-is-an-exact-business/ Om mina artiklar om NOA intresserade dig kanske du vill läsa vad en av mina idoler, Jonas Berge, skriver om ämnet: https://www.linkedin.com/pulse/implementing-namur-open-architecture-noa-jonas-berge/ Diskussioner kring säkerhet i 5G brukar lätt bli en massa fantasier eller skrämsel-propaganda. Vännerna på Trend Micro överraskar lite med ett rejält djup i dessa frågor vilket syns i ett forskningspapper de släppte nyligen: https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/the-transition-to-5g-security-implications-of-campus-networks Keysight som du mötte senast i förra nyhetsbrevet där jag tittade på deras fina tappar och aggregatorer har levererat något RIKTIGT intressant, något de kallar en Electro Turbo Encabulator. Det här är en närmast magisk manick som jag hoppas kunna få fingrarna på snart och återkomma med en rejäl test. Tills dess får vi hålla till godo med deras reveal-video: https://youtu.be/fltOyddlnOE Berätta gärna vad du tycker! Matthew Loong berättar för oss hur en pipeline fungerar. Väldigt aktuellt i dessa dagar... https://www.linkedin.com/pulse/operational-technology-musings-former-pipeliner-matthew-loong-%25E9%25BE%2599%25E5%2587%25AF%25E4%25BF%258A/ Projektet "The Top 20 Secure PLC Coding Practices Project" har skaffat sig en snygg logga och nu börjar det närma sig leverans av den första versionen. Om du är med i gruppen kan du följa arbetet från insidan: https://top20.isa.org/ Apropå Colonial-incidenten så har många förståsigpåare tyckt till om behovet av luftgap, något som sällan är en meningsfull tanke och som är helt befängt i samband med en modern pipeline. Här är i alla fall två proffstyckare som dessutom har olika åsikter: Joe Slowik: https://pylos.co/2021/05/13/mind-the-air-gap/ och Jake Brodsky: https://scadamag.infracritical.com/index.php/2021/05/15/air-gapping-it-and-ot/ För den som vill läsa mer av mina alster så finns några av mina artiklar med koppling till OT-säkerhet på Ateas officiella blogg. Det nya NIS-direktivet, "NIS2": https://www.atea.se/it-specialisten/sakerhet/ett-helt-nytt-nis-direktiv-ar-pa-vag/ Vad är OT-säkerhet?: https://www.atea.se/it-specialisten/sakerhet/ot-sakerhet-vad-ar-det/ En jämförelse mellan ISO 27000 och ISA 62443: https://www.atea.se/it-specialisten/sakerhet/isa-62443-battre-an-iso-27000/ Industri 4.0 blir lättare och säkrare med NAMUR NOA: https://www.atea.se/it-specialisten/sakerhet/klurigt-med-industri-4-0-svaret-ar-noa/ Det nya maskindirektivet adresserar spännande utmaningar kring säkerhet (både safety och security) i potentiellt farliga maskinutrustningar med ett speciellt intresse för användningen av AI i skyddsfunktioner: https://www.atea.se/it-specialisten/sakerhet/ce-markt-sakerhet/ Det här nyhetsbrevet vänder sig till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré på Atea Sverige och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

Jag ger dig en snygg lösning på utmaningarna kring Industri 4.0 när vi tittar på NAMUR NOA, jag prövar sprillans nya ruggade nätverksgrejor från Keysight som jag kopplar upp tillsammans med andra spännande prylar i mitt labb, bland annat en Nozomi Networks Guardian och en OT-diod från Advenica. En titt på EUs nya krav på CE-märkning av OT-säkerhet från det nya maskindirektivet blir det också och så gnäller jag över alldeles för mycket segmentering. Åsså en massa annat förstås! 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å vissa artiklar från nyhetsbreven 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! Segmentering är kass! Alla som arbetar inom någon form av OT-säkerhet är van vid att segmentering är en av de viktigaste säkerhetsåtgärderna. Oavsett om det är klassiska Purdue-tankar från ISA 95, "zones and conduits" enligt 62443, ACL:er, SDN-nät eller mikrosegmentering så använder vi segmentering för att skära upp helheten. Vi skapar de där lagren som i en lök så enbart de prylar som behöver kommunicera med varandra kan göra det. Efter att ha sett ett antal segmenterings-projekt så inser jag också att segmentering är den enkla delen. Det svåra är att få till bra integration, det vill säga en säker kommunikation mellan de olika segmenten. Beroende på var i vår segmenteringsmodell vi tittar så är det dessutom olika protokoll och kommunikationsmetoder så vi använder olika former av gateways och tjänster för att översätta så att olika språk kan användas i olika situationer. I de flesta av mina uppdrag agerar jag rådgivare åt olika grupper av personer i olika typer av organisationer. Jag har regelbundna träffar med IT-säkerhetschefer, automationsfolk, IT-chefer, lösningsarkitekter, R&D-folk, produktionschefer och informationssäkerhetschefer från alla möjliga typer av organisationer, allt från kärnkraftverk, via sjukvård och fastighetsförvaltning till skogsindustri och högteknologisk tillverkande industri. Jag reflekterar ofta över att alla dessa människor och deras organisationer har så många gemensamma utmaningar trots att förutsättningarna på ytan är så olika. Det finns mycket att lära av varandra mellan helt olika branscher! Den absolut vanligast problematiken i alla dessa organisationer har med segmenterad kommunikation att göra. Fast då inte den sorten som går på nätverk, utan den som är mellan människor. Lite som i våra nätverk har man oavsiktligt skapat segmentering genom uppdelade organisationsstrukturer, åtskilda produktionsenheter och genom att man har olika mål och utmaningar i vardagen. Och även här har man olika "protokoll", eller sätt att uttrycka sig, som gör att det är svårt att få till en vettig kommunikation mellan olika enheter. Det här är definitivt ett problem som jag ser i precis alla branscher och oavsett storlek på organisation. Hur ska vi då få till en bra kommunikation? Vilken motsvarighet har vi till bra integrationer och gateways? Eftersom vi knappast kan få alla att ha samma prioriteter, få att alla att använda samma språk eller ge alla samma utmaningar så får vi hitta ett sätt att kommunicera som överbryggar dessa olikheter. Mycket handlar förstås om grundläggande verksamhetsstyrning som strategiarbete, målnedbrytning och internkommunikation. Men om vi fokuserar på säkerhetsarbete här så finns det speciella utmaningar i att få till bra kommunikation. Sysslar du med informationssäkerhet har du ett sätt att utrycka dig kring risker, hot och sårbarheter. Om du arbetar med miljöfrågor har du en annan uppsättning begrepp, likaså har du ytterligare andra ord om du sysslar med fysiskt skydd, GDPR, brandskydd, maskinsäkerhet, Seveso-frågor eller SIS-system. De flesta har stött på CIA-triaden från informationssäkerhet, "Confidentiality - Integrity - Availability" ("Hemlighet - Riktighet - Tillgänglighet"). Det här är begrepp som passar väldigt bra när man resonerar kring skyddet av information. Om man sysslar med risker kopplade till automationssystem passar inte "CIA" så bra och därför har en annan triad blivit populär "Control - Observe - Operate" som utifrån styrsystemets perspektiv beskriver dess förmåga att styra processen, att låta oss observera processen och att låta oss påverka processen. Är man mer fokuserad på processen och dess riskers påverkan på oss har ytterligare en triad "Safety - Resilience - Performance" blivit populär eftersom vi kan beskriva hur farlig processen är för omgivningen, hur tålig processen är mot påverkan och hur effektiv processen är på att leverera det resultat som den är till för. (Du kan läsa mer i mitt nyhetsbrev #24.) Dessa olika kombinationer av tre är väldigt användbara. Det diskuteras flitigt vilken kombination som är bäst, vilket jag tycker är helt fel sätt att närma sig det här. För att få till den där integrationen mellan olika delar av organisationen och mellan personer med olika vardag behöver vi krydda vårt språk med alla dessa ord för att vara säker på att vi beskriver verkligheten på ett sätt som alla förstår oavsett av deras bakgrund. Det är så vi skapar vår integrationsplattform för mänsklig kommunikation som överbryggar skillnader i vår världsbild. En annan viktig bit är förstås organisationen i sig själv. Större organisationer med verksamhet på flera platser låter ofta varje enskild "fabrik" bli en separat produktionsenhet med en egen produktionschef som är ansvarig för resultat och risker i den egna verksamheten. Varje enhet har egna resurser som bygger och underhåller automationssystemen som driver verksamheten. Det är väldigt mänskligt att man som automationsingenjör prioriterar den egna enhetens behov och möjligheter över hela organisationens möjligheter. Det är lätt att detta, rätt eller fel, skapar situationer som ser ut som suboptimering för en utomstående. Något som jag personligen tycker är viktigt är att det företagsgemensamma säkerhetsarbetet fokuserar på att skapa möjligheter för varje enskild produktionsenhet som de själva inte har resurser att få till var för sig. Vi måste bli bättre på att kommunicera! Så precis som inom nätverkssegmentering är det integrationen mellan de olika segmenten som är både svårt och viktigt. Lyckas vi med integrationen kan vi dra nytta av alla fördelar som segmenteringen ger men utan den stör helhetens förmågor och utan att vi tar genvägar som förstör effekten av segmenteringen. CE-märkt OT-säkerhet! Ett förslag till nytt maskindirektiv lades fram av EU-kommissionen i slutet av April. Om du inte inte känner till vad maskindirektivet är för något så kan man enkelt förklara det som att det är gemensamma krav på hur man konstruerar, tillverkar, underhåller och använder maskiner och utrustningar för att undvika olyckor. Det är det kravunderlag som används för maskiner som CE-märks. I Sverige är det arbetsmiljöverket som ansvarar för regelverket. Att det behövdes ett nytt direktiv slogs fast i en rapport från förra året, "Report on the safety and liability implications of Artificial Intelligence, the Internet of Things and robotics", som pekade på hur modern teknik påverkar maskinsäkerheten. Observera att när jag använder ordet "säkerhet" här så menar jag "safety", alltså att maskinen inte skadar människor. För att klara det krävs också att tekniken har god "security" så att den inte kan bli farlig genom exempelvis manipulation eller ändring. Jag ska direkt erkänna att maskindirektivet inte är något som jag är jättehemma i, men eftersom det nu verkar bli ett intressant överlapp mellan OT-säkerhet och direktivet så blev jag förstås nyfiken. Precis som med nya NIS-direktivet (läs mer här och här!) så blev det en övning i att läsa komplexa EU-dokument. Man ger sex huvudskäl till att ett nytt direktiv behövs. Det första skälet, och kanske mest intressanta, är att det gamla direktivet inte täcker risker som kommer ur ny teknik. Man vill förstärka förtroendet för nya tekniska lösningar och därmed behövs legal tydlighet. Man listar sedan fem intressanta riskområden kopplat till just ny teknik: Direkt samarbete mellan människor och robotar. Det här är ju ett område som verkligen börjat växa på sistone med så kallade co-bots. Uppkopplade maskiner. Förändringar i maskiners "beteende" på grund av uppdateringar till mjukvaran efter godkännandet. Svårigheterna att göra riktiga riskbedömningar på lösningar som bygger på Machine Learning. Autonoma eller fjärrstyrda maskiner som inte har en förare eller operatör på plats. Det är inga detaljerade krav vi får så det blir ju intressant att se hur detta kommer tolkas i praktiken när man ska kravställa eller granska maskiner framöver. Man gör en poäng av att trycka på att direktivet är i linje med en kommande EU-reglering kring Artificiell Intelligens och med EUs policy för cybersäkerhet. För just kopplingen mellan safety och cybersäkerhet finns det egentligen två kravtexter, en kring skydd mot allmän påverkan och en kring utformningen av styrsystem: Maskinen ska vara konstruerad och byggd på ett sätt som gör att farliga situationer inte kan orsakas av anslutningar till andra prylar oavsett om det handlar om oavsiktlig påverkan eller ett medvetet angrepp. Det finns ett krav på att alla former av förändringar ska loggas och lagras för både hårdvara, mjukvara, konfiguration och data. Styrsystem ska kunna stå emot angrepp så att inte farliga situationer uppstår. På samma sätt ska inte fel i hårdvaran eller i styrsystemet kunna skapa risker. Speciellt ska Safety-system inte kunna ändras utanför gränserna för vad som anses vara säkert. Loggar för förändringar ska vara tillgängliga i fem år och loggar för safety-händelser ska vara tillgängliga i ett år. Speciellt intressant är att man trycker på funktioner som utvecklas under tiden maskinen används, det vill säga AI och Machine Learning. En annan intressant fråga som alltid brukar dyka upp är synen på trådlös styrning och vad som ska hända om den fallerar på något vis. Man trycker speciellt på att safety-funktioner ska vara lokala i maskinen så att den kan avvisa fjärrstyrning i farliga situationer. En intressant del är Bilaga 1 som definierar högriskmaskiner som nu även innehåller AI-baserade skyddssystem förutom cirkelsågar, industriella pressar, sopkompressorer, fordonslyftar och en massa andra farliga saker. Eftersom man också pratar om att det inte ska vara möjligt att påverka skyddssystem så att de slutar fungera enligt riskanalysens antaganden blir det här väldigt viktigt att skydda på ett bra sätt. Just samarbetet mellan människa och autonom maskin lyfter de i ergonomiavsnittet, där det speciellt trycks på en bra två-vägskommunikation. Maskinen ska kommunicera sina avsikter och reagera på ett bra sätt när den får order. Det är som sagt långt ifrån några detaljerade krav som vi får. Det är inte helt klart för mig hur det här kommer omsättas i praktiska åtgärder och vad som kommer bli något slags hygien-nivå för att uppnå CE-märkning. Om någon av mina läsare vet mer om det här så får ni väldigt gärna kommentera eller höra av er! Fullt ös i labbet! I mitt OT-testrack finns just nu en hel radda roliga och imponerande prylar. Jag har gjort en lite större installation nu där ett antal av burkarna får leka tillsammans och tänkte gå igenom helheten i den här artikeln. Framöver kommer jag titta närmare på prylarna var för sig i kommande nyhetsbrev. Hör av dig om det är något speciellt du är nyfiken på och vill att jag tittar extra noga på! Det den här testmiljön gör är att generera stora mängder trafik mellan hundratals fejkade system där trafiken också innehåller attacker och skadlig kod. Denna trafik kopieras sedan av ett antal olika nätverkstappar och aggregeras så att summan av all trafik kan kopieras till ett antal mottagare. Dessa mottagare analyserar trafiken och presenterar sina insikter. Tanken med hela upplägget är att simulera en nätverksmiljö för en verksamhet som vill förbättra synligheten i sina nätverk. På köpet får vi möjlighet att låta var och en av komponenterna visa upp vad den kan! Om vi tar det från vänster till höger så har vi: Mjukvaran "BreakingPoint" som körs i en "PerfectStorm One" från Keysight som du fick en glimt av i nyhetsbrev #25. Trafiken skickas i mitt fall mellan tre par nätverksinterface där var och en av dessa par simulerar ett nätverk med hundratals klienter och servrar. I mitt fall har jag valt en riktigt jobbig blandning av IT- och OT-trafik där jag även skjuter in skadlig trafik av lite olika typer. Tre stycken nätverkstappar från Keysight skapar en kopia av den trafik som skickas genom dem. I ett verkligt fall skulle de kunna vara anslutna mellan viktiga switchar i nätverket. I mitt fall är det en mer IT-anpassad IxTap och två ruggade varianter där "Copper Tough Tap" har RJ45-anslutningar och "Flex Tough Taps" har fiberanslutningar. Jag skrev om IxTap i nyhetsbrev #18. Trafiken från de tre tapparna samlas in av en paketaggregator, "Vision T1000" från Keysight. Det här är en ruggad aggregator som är tänkt att kunna sitta ute i en anläggning eller ett ställverk. Den tar nätverkstrafik från flera håll, sammanställer den och skickar sedan vidare till en eller flera analysburkar. Jag skrev om en besläktad produkt, "Vision Edge 1S", i nyhetsbrev #21. "Guardian NSG-R 50" från Nozomi Networks" analyserar trafik den får till sig och sammanställer en otrolig mängd information utifrån den passivt insamlade trafiken. Den är utformad i grunden för att passa de speciella förutsättningar som råder inom OT. Resultatet blir en makalös insyn i vad som finns på nätet, hur de kommunicerar, vad som är normalt eller onormalt och vilka hot som behöver hanteras. TxOne EdgeIPS Pro träffade du i förra nyhetsbrevet, där du fick en glimt av detta muskedunder till nätverks-IPS för OT-miljöer som identifierar olika typer av angrepp på nätet. I det här exemplet kommer jag köra den som en IDS, dvs den kommer enbart larma när den ser något otrevligt. En nätverksdiod DD1G från Advenica som kan vara lösningen på ett klurigt problem när man segmenterat sitt nätverk. Ofta vill man exempelvis använda gemensamma säkerhetslösningar för IT- och OT-världen, men hur vet man att den utrustning som skickar nätverkstrafik för analys är säker och inte är en bakväg från IT till OT? En möjlighet är att skicka den kopierade nätverkstrafiken via en diod för att vara säker på att nätverkspaketen verkligen bara kan ta sig åt ena hållet. Superenkelt att få till dessutom, saknar helt konfiguration. Gigabit-sladd in och gigabit-sladd ut, det är allt! Du kan läsa mer om dioder i nyhetsbrev #22. Ett första intryck är att alla delarna imponerar stort! Att kunna skapa testtrafik på ett så brutalt sätt som BreakingPoint gör är fantastiskt för alla former av nätverkstester. De olika tapparna sköter sig exemplariskt och levererar de kopior av trafiken som vi är ute efter. Aggregatorn är precis så lättjobbad som man vill att en så viktig funktion är. TxOne EdgeIPS Pro vet vi sedan tidigare är ett monster i sin nisch. Nozomi Guardian vet jag själv sedan tidigare är en imponerande lösning men jag blir ändå fascinerad av hur mycket information den kan plocka ut bara genom att passivt "tjuvlyssna" på nätverkstrafik! Dioden är i sin enkelhet en fantastisk lösning på ett riktigt svårt problem! Framöver kommer jag titta vidare på de här olika delarna var för sig. Lyssna på OT-trafiken! Vi kastar oss direkt över de helt nya prylarna från Keysight! Det är tre typer av utrustningar, två är nätverkstappar och en är en aggregator. Jag har tidigare tittat på en liten smidig tapp från Keysight som inte var speciellt anpassad för OT-världens behov, läs mer i nyhetsbrev #17. I nyhetsbrev #21 tittade jag på ett syskon till aggregatorn som inte heller var OT-stukad. I och med de här nya produkterna har Keysight verkligen tagit ett tydligt kliv framåt i OT-världen och det här är riktigt coola prylar! Copper Tough Tap är en nätverkstapp med vanliga RJ45-anslutningar. Den kopplas in i linje på en nätverksförbindelse som du vill ha insyn i där den blir helt osynlig men skickar en exakt kopia av all trafik till en tredje och fjärde utgång. Så långt är det inget konstigt, som tappar är mest. Men... Det här är en ruggad enhet i extruderad aluminium som monteras på DIN-skena. Den är fläktlös men som trots det fungerar från -40 grader till +85 grader! Den har dubbel strömmatning men skulle den tappa ström kommer den ändå inte störa kommunikationen. Den genomsnittliga tiden för den att går sönder (MTBF) är över 142 år! Behöver man många på samma ställe har Keysight en lösning för att effektivt montera och fördela ut ström till dem alla. Eftersom den själv inte har någon IP-adress går den heller inte att angripa. Den har vad Keysight kallar "airgapped monitor ports", dvs att det inte finns någon fysisk möjlighet att störa genom att mata in trafik "bakvägen". Kör du PoE, Power over Ethernet, så skickas spänningen vidare utan problem. Riktigt cool och imponerande pryl! Bra jobbat Keysight! Flex Tough Taps är på motsvarande sätt en nätverkstapp för fiberanslutning. Det första man kanske blir förvånad över är att det inte finns någonstans att koppla in strömmen! Det här är en helt passiv enhet som helt enkelt "stjäl" lite av ljuset i fibern (30% för att vara exakt) för att skicka vidare som en kopia av trafiken. Här får du fyra stycken tappar per burk men i övrigt har den samma imponerande spec som koppar-tappen! Den finns i två varianter beroende på fibertyp, för OM1 och för OM5. Har man fiberanslutningar i sitt nätverk är det här ett klockrent sätt att få insyn i trafiken! Vision T1000 presenteras som en "Industrial Network Packet Aggregator". Men vaddå "Industrial", tänker du, den ser ju ut som vilken 19-tums nätverkspryl som helst? Men skenet bedrar! Den är fläktlös, fungerar från -40 grader till +85, kan matas med 48V DC eller 240V AC, har reläutgång för att markera spänningsfel och tål vibrationer, stötar och fall enligt IEC 60068-2. Det gör inte andra nätverksprylar! Att det här är en industriell pryl märks om inte annat i att det går att prata MODBUS med den. Det ger möjlighet att läsa av en väldig massa intressant information. Nyttan med den här prylen är att den samlar ihop trafik på ett gäng (20st SFP och 6st RJ45) ingångar som kommer från tappar och SPAN-portar. All den här trafiken kan man sedan filtrera för att slippa onödig belastning och sedan skicka ut till en eller flera mottagare som får analysera trafiken. Det man vill uppnå är att skapa insyn i många olika nätverk och segment för att sedan enklare kunna låta flera verktyg titta på den trafiken. Du kan läsa mer om tänket i nyhetsbrev #21. Tillsammans blir de här tre komponenterna en fantastisk kombo! Med hjälp av tapparna kan du enkelt få kopior av trafik utan att störa nätverket även om du inte har nätverksswitchar som erbjuder SPAN-portar. Aggregatorn gör att alla dessa kopior enkelt kan slås samman till en samlad bild och skickas på analys. Är det enkelt att få till då? Ja, det måste man faktiskt säga! Tapparna har ju i princip ingen konfiguration alls och aggregatorns webbinterface är riktigt lättjobbat. I grunden handlar det om att definiera vilka av de 26 portarna som ska ta emot trafik och till vilka portar denna trafik ska skickas. Mappningen kan kompletteras med olika filterregler och regler för lastbalansering. Förvisso skulle man kunna önska sig vissa mer avancerade finesser som saknas, kanske framför allt deduplicering av nätverkspaket som fångats upp flera gånger, men enkelheten är å andra sidan också en stor vinst. Just deduplicering skapar man ju ändå oftast i en mer central funktion och då vill man inte betala för den i onödan här. Sammantaget är det här en makalös kombination av prylar som löser ett svårt problem i många OT-nätverk. Den trafik man inte ser kan fortfarande ställa till elände! Med en unik kombination av fysisk robusthet, genomtänkt konstruktion och smidig funktionalitet är lätt att få den insyn i nätverket som är helt nödvändig för både säkerhetsverktyg och andra analysbehov. Ett stort beröm till Keysight för den här raddan nya produkter som verkligen är en fullträff! Klurigt med Industri 4.0? Svaret är NOA! I förra nyhetsbrevet startade jag en serie texter om olika standarder och ramverk. Först ut var ISA 62443 som ju får betraktas som en riktig kändis jämfört med den här omgångens huvudperson, "NOA" eller "NAMUR Open Architecture". NAMUR är en gammal organisation som grundades 1949, som en samarbetsorganisation för tyska kemikaliefabrikanter. Sedan dess har den utvecklats på många sätt, både genom att numera adressera automation i största allmänhet och genom att bli helt internationell. (Även om ursprunget fortfarande är väldigt tydligt...) NAMUR har en väldig massa arbetsgrupper som publicerar rekommendationer inom så skilda områden som projektledning, ingenjörskonst, MES-system, sensorteknik, asset management, säkerhet och en massa annat. Men det som jag tittar på nu, NOA, "NAMUR Open Architecture", är faktiskt inte i första hand tänkt att vara något för säkerhetsfolket. NOA handlar i grunden om "Industri 4.0" (som ju också var en tysk uppfinning från 2011) och hur man på ett bra (och indirekt därmed säkert) sätt ansluter stora mängder med informationsinsamling i nya och befintliga automationsmiljöer. Det är nu vi försöker få OT och IoT att bli kompisar på riktigt! Jag skulle spontant säga att jag inte kan komma på en enda av mina OT-kunder, oavsett bransch, som inte brottas med precis den här frågan! Hur man ansluter en massa nya sensorer och hur man tankar ut en massa information ur styrsystem utan att riskera pålitligheten, säkerheten och utan att skapa en enormt rörig systemmiljö. Dessutom drar man ju ofta på sig omaket att man får en massa känslig information som man inte är riktigt van vid att hantera i dessa delar av organisationen. Klurigt! NOA är helt anpassad till ISA 62443 och är tänkt att fungera lika bra när man utökar en existerande installation som när man bygger helt nytt från scratch. Hela idén illustreras riktigt bra av pyramidbilden här ovanför. Istället för att försöka lirka in en massa nytt i den existerande pyramiden, lägger man istället på ett lager på sidan. När man tränger in i detaljerna är det förstås inte riktigt fullt så enkelt men grundtänket är helt i linje med en av mina egna gamla käpphästar: "Blanda inte ihop grejor på samma nätverk bara för att de råkar sitta i samma maskiner eller i samma fysiska process". Arbetet med NOA har sex styrande principer som ju onekligen låter alldeles utmärkta: Man ska enbart lägga till lösningar - inte ersätta eller ändra. Perfekt för att kunna bygga vidare i existerande anläggningar. Vara öppen för nytt tänk från Industri 4.0. NOA fokuserar på mätning och optimering snarare än processkontroll vilket ger en enkel väg mot Industri 4.0. Bygga på enbart öppna standarder - enkel integration stöttar ju dessutom effektiv segmentering. Ska tillåta att snabbt föränderlig IT-teknik integreras ända nerifrån vår fysiska process och hela vägen upp till affärssystemet. Ja tack! Rejält minska kostnaden för information genom öppna, skalbara och integrerade lösningar. Då får vi pengar över till säkerhetsarbetet! Inte på något vis påverka tillförlitlighet eller säkerhet i den fysiska processen! Naturligtvis helt avgörande för att vi ens ska vara intresserade! Som så mycket annat i OT-säkerhetsvärlden är NOA fortfarande under arbete. Av fem dokument som är tänkta att tas fram är två klara. "NE 175 – NOA Concept" släpptes i höstas och "NE 177 – NOA Security Zones and NOA Security Gateway" dök upp för ett par veckor sedan. Vi har att se fram emot "NE 176 – NOA Information Model", "NE 178 – NOA Verification of Request", "NE 179 – NOA Aggregating Server". Som sagt, det här är inte en säkerhetsstandard utan ett arkitektuellt tänk med högt fokus på säkerhet. Precis som det ska vara! Väldigt få saker här i livet är gratis, inte heller NOA! Man kan köpa de separata dokumenten för 53 Euro styck eller prenumerera på hela NAMURs dokumentbibliotek för 200 Euro per år. Jag kan direkt säga att det är väl värt pengarna att skaffa sig tillgång till dem! Det är oerhört välskrivna dokument, tydligt och exakt utan att bli långt i onödan. Kan det vara det noggranna tyska arvet? Dokumentet NE 175 som beskriver hela det grundläggande konceptet är inte mer än på 22 sidor! En viktig del kan också vara att dessa dokument inte är tänkta att vara standarder utan enbart rekommendationer. I vilket fall som helst är de väldigt tydligt skrivna! Jag måste trycka på att man verkligen lyckats med att hålla sig till de 6 principerna! Inte minst att man skiljer extremt tydligt på kärnprocessen som inte ska påverkas och det nya som NOA tillför. Eftersom de olika delarna har helt olika uppgifter och därmed kravbilder ska de hanteras på helt olika sätt! Man är också väldigt verklighetsförankrad, till exempel har man redan från början med faktumet att de flesta organisationer har många produktionssajter och därmed separata OT-system, vilket ju så klart måste hanteras på ett bra sätt! På samma tema är man tydlig med att kärnan i de flesta OT-system bygger på proprietära lösningar och att vi ska akta oss för att försöka "jacka in oss" i dem! Även omvänt är det väldigt viktigt att inte de nya delarna som vi tillför "av misstag" blir nödvändiga för att kunna köra processen på ett säkert och effektivt sätt. Därmed kan vi sätta helt olika krav, både för säkerhet och annat, vilket förstås skapar nya möjligheter! "Jaha? Molnet nästa då?" hör jag att du undrar! Ja! Precis! I och med att NOA-tilläggen inte på något vis påverkar säkerheten i den fysiska processen öppnar vi säkerhetsmässigt dörren till att enklare besluta om att inte nödvändigtvis implementera allting i lokal teknik utan flytta det till något slags molnfunktion. Men det kan förstås finnas andra skäl till att en lokal edge-lösning passar bättre! Rent tekniskt pekar NOA med hela handen på OPC UA för kommunikation med existerande OT-system, vilket ska kombineras med en rekommenderad datamodell som kommer inom kort. Men tro inte att NOA-tillägg i en process enbart kan syssla med datainsamling och analys! NOA-modellen öppnar för att feedback och ordrar skickas till OT-systemet, som i så fall måste ha lämpliga skydd (manuella eller automatiska) för att granska den input som tas emot så att den är relevant. Där påverkan ska vara helt omöjlig pekar NOA på en "diod-lösning" som man inte beskriver tekniskt men där kraven på den är specade i "NE 177". Man kan tänka sig flera olika sätt att lösa det praktiskt beroende på vilka krav på man har i den aktuella situationen. Den som sysslar med Industri 4.0 eller arkitektur i allmänhet kan ha kommit kontakt med "RAMI 4.0" (The Reference Architectural Model Industrie 4.0), med den karakteristiska 3-dimensionella modellen. Den kommer från en annan tysk organisation "Zvei", där främst tillverkande industrier inom el- och elektronik är med. Glädjande är att Zvei och NAMUR nu samarbetar kring NOA vilket förstås ger resultatet ännu bättre möjligheter att "slå igenom"! Vi får bara hoppas att det inte sinkar arbetet med de sista delarna... Så här långt har jag egentligen bara berört de allmänna delarna som beskrivs i "NE 175 – NOA Concept" här i den här texten. Jag tänker återkomma med en djupdykning i lite mer detaljer från "NE 177 – NOA Security Zones and NOA Security Gateway" i ett kommande nyhetsbrev. Och när de tre återstående delarna dyker upp så tar vi förstås oss en titt på dem. Jag måste säga att jag är väldigt positiv till NOA, både för det nonsensfria sätt som den är skriven på och för den rättframma lösningen på ett klurigt problem! Det blir intressant att se hur snabbt det här tänket kommer anammas. Det har den där härliga känslan av att vara självklart, så där att det nästan känns onödigt att ha dokument som beskriver det. Klassiskt tecken på en riktigt bra idé! Om någon av mina läsare har egna erfarenheter så utbyter jag gärna lite sådana! Lästips! Ett litet provocerande blogginlägg som jag själv skrev för att jämföra ISA 62443 och ISO 27000. Handlar framför allt om vikten av att välja ett verktyg som passar bra till det som du tänker göra. https://www.atea.se/it-specialisten/sakerhet/isa-62443-battre-an-iso-27000/ För den som vill läsa fler av mina alster så finns några artiklar med koppling till OT-säkerhet på Ateas officiella blogg: Det nya NIS-direktivet, "NIS2": https://www.atea.se/it-specialisten/sakerhet/ett-helt-nytt-nis-direktiv-ar-pa-vag/ Vad är OT-säkerhet?: https://www.atea.se/it-specialisten/sakerhet/ot-sakerhet-vad-ar-det/ I veckan fick vi det tråkiga beskedet att årets CS3STHLM ställs in. Jag vet att de försökte in i det sista att få till en fysisk träff i år men pandemin har tyvärr skördat ytterligare ett offer i och med att vår favoritkonferens ställs in. Det låter lyckligtvis som att de kommer satsa på en revansch 2022. Om du inte redan gjort det kan du stötta dem genom att köpa tillgång till alla spännande presentationer från förra året: https://vod.cs3sthlm.com/product/cs3sthlm-2020-video-on-demand/ En avhandling från tyska Saarbrucken Graduate School of Computer Science, Saarland University som tittat på praktiska utmaningar och säkerhetsmässiga snubbeltrådar i OPC UA. https://arxiv.org/pdf/2104.06051.pdf Goda råd från Center of Internet Security (CIS, mest kända för CIS Controls) kring hur man gör RDP lite säkrare. RDP är ju (tyvärr) ett vanligt sätt att ta sig mellan olika system och nätverkszoner. I de fall man inte vill eller kan göra något lite bättre kan man ju i alla fall försöka få till säkerheten så bra det går. https://www.cisecurity.org/blog/commonly-exploited-protocols-remote-desktop-protocol-rdp/ Sarah Fluchs skriver om säkerhet i två perspektiv, "Security" och "Safety" för att ge oss lite nya perspektiv på hur de hänger ihop. Möjligheter och utmaningar för dem som dra nytta av de gemensamma aspekter som dessa områden har. https://fluchsfriction.medium.com/coupling-security-and-safety-engineering-2e08ef2148ba CISA har släppt tolkar för OT-protokoll att använda i Zeek (tidigare "Bro"), en välkänd open-source IDS. De har lagt till stöd för BACnet, BSAP, Ethercat, Ethernet/IP och CIP. Dessutom har de utökat logg-funktionaliteten för DNP3 och Modbus. https://github.com/cisagov/icsnpp Det här nyhetsbrevet skickas till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré på Atea Sverige och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se .

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: Om din verksamhet är det minsta intressant för andra nationer så kommer du angripas av statsfinansierade angripare. Garanterat! Om du attackeras av dem så kommer de att lyckas. Garanterat! Det betyder att de förmodligen redan rör sig i dina system. Garanterat! Nästan... 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. Apropå drama och de fysiska anslutningarna så är det här vi hittar den första skillnaden mot den lilla EdgeIPS. De har båda två relä-baserade bypass-kopplingar för att inte nätverksanslutningarna ska brytas vid ett haveri eller strömförlust. Men i Pro-versionen kan vi välja hur relät ska agera. "Fail Open" eller "Fail Close" avgörs förstås av om du föredrar att köra processen utan skydd eller om du hellre bryter nätverkskopplingen vid ett fel. Eftersom det här förstås varierar mellan olika utrustningar går detta att ställa in per port! Dessutom finns en tredje inställning, "Force Open", som fysiskt kopplar förbi trafiken helt vilket kan vara praktiskt vid felsökning. Snyggt! En efterlängtad finess som bara finns i Pro-versionerna är "Packet Capture". Det handlar helt enkelt om att du kan få en inspelning av nätverkstrafiken som triggat en IPS-regel. Det här är förstås helt ovärderligt vid incidentanalys om man saknar generell inspelning av sin nätverkstrafik. Den inspelade nätverkstrafiken laddar man sedan ner i administrationsgränssnittet och öppnar med WireShark eller något annat analysverktyg. Konfigurationen av brandväggsregler och IPS-skydd är intuitiv och snygg precis som tidigare. Men även här tillför Pro-versionen lite extra. Här finns möjligheter att kombinera klassiska brandväggsregler med filtrering baserat på OT-protokoll, IPS-regler och överföring av filer via olika protokoll. Många OT-verksamheter kan exempelvis ha enorm nytta av att kunna styra och reglera trafik som skickas över SMB version 1. Annars känner man igen det smidiga administrationsgränssnittet från de tidigare modellerna. Administrationskonsolen levereras som en färdig virtuell appliance som kräver ett minimum av inställningar för att komma igång. Gränssnittet är enkelt och tydligt. Man skapar konfigurationsgrupper vilket gör det enkelt att snabbt få till en väl standardiserad uppsättning även om man har många enheter. Genom att flytta enheter mellan konfigurationsgrupper kan man på ett väldigt smidigt sätt byta en hel konfiguration, självklart utan att trafiken eller skyddet påverkas under bytet! Summa summarum är det här en fantastisk maskin som, trots sitt datorhallsanpassade yttre, levererar OT-säkerhetsfunktioner som är extremt väl anpassade till operativa verksamheter. Jag lovade i förra nyhetsbrevet att utsätta det lilla underverket för en del extrema prestandatester vilket jag tänker be att få återkomma till! Funktionellt är det här unika produkter för den som vill skydda sin OT-miljö och tack vare kopplingen till Zero Day Initiative blir skyddet dessutom riktigt vasst även när det gäller zero-days! Standarder och sånt... Jag tänkte dra igång en liten serie korta texter om olika standarder och ramverk med något slags anknytning till OT framöver. Först ut blir förstås min ständiga favorit ISA/IEC 62443 men sedan tänkte jag låta dig läsare tycka till om vad som ska tas upp. Kanske blir det NIST CSF, NERC CIP, ICS Cyber Kill Chain, ISA 95, NAMUR eller någon annan spännande variant. Hör av dig om du har önskemål! Mats.Karlsson-Landre@atea.se Men jag börjar förstås med ISA/IEC 62443. Men varför då? - blir ju den uppenbara motfrågan. Vad är det som gör den standarden så speciell förutom att det är min egen favorit? Det kanske viktigaste skälet är att den skapades uteslutande för att hantera de speciella förutsättningar som ofta gäller inom OT. Förutsättningar som gör att man inte oftast kan resonera kring risker och kring säkerhetsåtgärder på samma sätt som man gör inom informationssäkerhet. De här skillnaderna har jag skrivit om flera gånger förut, exempelvis kan du läsa mer i nyhetsbreven #25, #24 och #23. Arbetet började 2002 när en grupp kallad ISA99 inom International Society of Automation började ta fram standarden som först publicerades via ANSI och senare via IEC. Det är ett pågående arbete med flera olika delar, så det finns både hål i listan över dokument och en del motsägelser mellan dokument som är olika gamla. Standarden har fyra delar, även om de flesta bara kommer i kontakt med del 1, 2 och 3. Del 1 beskriver definitioner och en del allmänna koncept på dryga 90 sidor. Den viktigaste biten i del 2 är 170 sidor som handlar om hur man sätter upp ett säkerhetsprogram i en OT-verksamhet för att säkerställa att man har koll på sina säkerhetsåtgärder. Del 2 lånar CMMIs mognadsmodell för att ge lite mätbarhet på säkerhetsarbetet. I del 2 finns också två tekniska rapporter, en om patchningsrutiner och en som beskriver krav på tjänsteleverantörer inom OT. Del 3 är förmodligen den mest välkända. Där spenderas drygt 120 sidor för att definieras konceptet "SL" - "Security Level" där säkerhetsåtgärder graderas från 0 till 4 baserat på ett 50-tal åtgärder med undervarianter. På sätt och vis kan man jämföra det med ISO-27002 inom 27000-serien. Utöver åtgärderna beskrivs också en metod för att bedöma risker och i vilken säkerhetsåtgärder behövs för att uppnå önskad säkerhet. Del 4 riktar sig till dem som tillverkar OT-utrustning. Den beskriver hur en säker utvecklingsprocess ska se ut och vilka krav som ställs på produkterna. Som så ofta är inte standard-texterna gratis men genom att bli medlem i ISA för en överkomlig penning får man tillgång till alla deras standarder. De ger också ut intressanta böcker och har också en mängd utbildningar, bland annat de fyra utbildningar med tillhörande certifieringar som jag själv tagit för att stolt få kalla mig "ISA/IEC 62443 Cybersecurity Expert". Den inledande Fundamentals-kursen är ett perfekt sätt att komma underfund med standarden. En stark sida med både böcker och kurser från ISA är att de anstränger sig för att de ska fungera oavsett om din bakgrund är från automationsvärlden eller från IT-världen. En klurig balans att hantera... Som medlem i ISA blir man också insläppt i deras diskussionsforum där det emellanåt går hett till... Vill man, som jag, engagera sig i arbetet med att utveckla standarden eller ta del av nya texter innan de publiceras kan man gå med i arbetsgrupperna utan extra kostnad. Personligen tycker jag verkligen att 62443 är värd att ta till sig för alla organisationer som på något vis lutar sig mot OT-system. Det är en standard som kräver lite arbete innan man blir kompisar men grundtänket i texterna är ett perfekt stöd för allt OT-säkerhetsarbete. Den går utmärkt att kombinera med ISO 27001 och 27002 om man har information som behöver skyddas i OT-systemen. Jag kan tycka att tänket kring riskbedömningar kan utvecklas och då kan ju exempelvis SPR-metoden som jag berättade om i förra nyhetsbrevet vara en alldeles utmärkt metod. Killchain för insiders! Ett gissel i alla former av säkerhetsarbete är att du måste lita på dina medarbetare. En extern angripare kan man förstå, förutse och hantera men att försvara sig mot att en betrodd kollega plötsligt vänder sig mot sin egen organisation är väldigt svårt att hantera för de flesta verksamheter. Det gäller i allra högsta grad även inom OT eftersom en insider ofta har unika möjligheter i och med att man både känner till och kan manipulera de skydd som finns. Det här är av naturliga skäl en stor fråga i min egen gamla bransch, kärnkraften. Där har man sedan länge arbetat strukturerat med denna riktigt svåra fråga. Jag råkade nyligen snubbla över en artikel från G-Research, en organisation som inte har ett smack med OT och OT-säkerhet att göra. Det är en brittisk forskningsgrupp i finansbranschen. Vad de har gjort är att, med inspiration från de välkända ramverken "Lockheed Martin Cyber Kill Chain" och "MITRE ATT&CK" utvecklat resonemangen från en bok som heter "CERT Guide to Insider Threats" till något de kallar "Insider Attack Matrix" och "Insider Kill Chain". De säger själva att det krävs mer arbete för att vidareutveckla deras resultat men jag tycker redan det finns riktigt starka delar i detta. Om du är intresserad av ämnet kan jag definitivt rekommendera att du läser deras text. Om du använder killchains eller MITRE ATT&CK i andra sammanhang vill jag gärna höra om du tycker det här är ett vettigt komplement. En gränsdragning jag gärna skulle vilja se diskuterad framöver är om, och i så fall hur, man skiljer på en insider med ont uppsåt och en insider som blir lurad/manipulerad att göra något elakt. Det är en diskussion som dyker upp ibland och som jag ännu inte sett något tydligt grepp kring. Lästips! Dale Peterson funderar kring hur vi ska få fram fler människor med kompetens inom OT-säkerhet. Han resonerar ur ett amerikanskt perspektiv men hans tankar känns relevanta även här. Vi får tre förslag: 1.) Få in fler kvinnor i branschen 2.) Tro inte att det finns massor med folk som redan kan allt utan leta upp dem med bra förutsättningar och lär dem det som de saknar 3.) Belasta inte automationsfolket med säkerhetsåtgärder utan hyr in OT-säkerhetsproffs! https://www.linkedin.com/pulse/how-do-we-solve-ot-cybersecurity-staffing-challenges-dale-peterson En artikel i ISAs tidning som väckt diskussioner kring hur man ska åstadkomma separation mellan processkontroll och processsäkerhet. Författarna har tittat på hur kravtexter från standarder och leverantörernas egna texter använder olika ord som därmed kan tolkas på olika sätt. Exempelvis "Separation" kontra "Isolation". https://intechdigital.isa.org/publication/?m=60495&i=684843&p=28 Den som är road av ämnet kan också läsa i ISA-rapporten ISA-TR84 Part 9 där man i Appendix A tittar på för- och nackdelar med olika arkitekturer. Vi i Sverige har ju dessutom det besläktade problemet med att "Security" och "Safety" båda översätts till "Säkerhet" vilket jag själv har varit med om att det lett till allvarliga missförstånd. Jim Gavigan resonerar kring användningen av Historian-tjänster framöver på vägen in i Industrie 4.0. https://www.industrialinsightinc.com/post/2019/08/01/are-industrial-data-historians-an-iiot-platform Remote Desktop Protocol (RDP) är en vanlig svag punkt när vi bygger den enklaste formen av jumphosts mellan segmenterade nätverk. Center for Internet Security, CIS, har ett bra White Paper kring hur man kan göra så gott det går för att skydda tjänsten. https://www.cisecurity.org/white-papers/exploited-protocols-remote-desktop-protocol-rdp/ Jag har nämnt projektet "Top 20 Secure PLC Coding Practices" förut. Deras arbete för att ta fram riktlinjer för säker programmering av PLCer går framåt och en första publicering planeras till sommaren. Förutom rena programmeringsråd samlar de också in en massa andra klokskaper. Redan nu finns det väldigt mycket att ta till sig om man sysslar med programmering eller kodgranskning. Personligen tror jag att det här arbetet kommer leda till riktigt viktiga framsteg i att göra PLC-program mer tåliga mot påverkan. https://top20.isa.org/ Anmäl dig till MSBs NIS-konferens den 19:e Maj! Perfekt tillfälle att lära sig mer om detta viktiga område oh vad som är på gång framöver! https://www.msb.se/sv/aktuellt/kalender/2021/maj/kunskapshojande-nis-konferens/ Joe Weiss slår ett slag för de underskattade säkerhetsriskerna kopplat till OT-system i våra datorhallar. System för avbrottsfri kraft, eldistribution, kyla, inpassering mm innehåller ofta kompontenter eller använder protokoll som vi känner igen från OT-världen. Om inte de skyddas på rätt sätt är det en riktigt effektiv pungspark mot driften av en datorhall. https://scadamag.infracritical.com/index.php/2021/03/23/data-center-cybersecurity-dont-overlook-the-cyber-vulnerable-building-control-systems/ Jag skrev en inlägg nyligen på Atea-bloggen om vad OT-säkerhet är där jag beskriver vad OT-säkerhet är och varför det är speciellt tillsammans med några vanliga utmaningar och missförstånd som lätt uppstår. https://www.atea.se/it-specialisten/sakerhet/ot-sakerhet-vad-ar-det/ OTCSA (OT Cyber Security Alliance) har gett ut en serie om tre dokument kring hur man bygger upp en OT-säkerhetsorganisation: https://otcsalliance.org/wp-content/uploads/2021/01/OTCSA-DTX_Whitepaper-1-August062020.pdf https://otcsalliance.org/wp-content/uploads/2021/01/OTCSA-DTX_Whitepaper-2-August062020.pdf https://otcsalliance.org/wp-content/uploads/2021/01/OTCSA-DTX_Whitepaper-3-August2020.pdf Matthew Loong tittar närmare på säkerheten i de system som ligger allra närmast de fysiska processerna och avslutar med tankar kring hur detta kan förändras i takt med att vi gå in i Industrie 4.0 https://www.linkedin.com/pulse/taking-closer-look-level-0-1-security-matthew-loong/ Ytterligare en standard att hålla ordning på: ISO/SAE 21434 Cybersäkerhet för bilar och andra vägburna fordon. Någon som har mer koll på detta och som vill berätta? https://www.cyres-consulting.com/hello-iso-sae-21434-the-new-point-of-reference-for-cybersecurity-in-the-automotive-industry-is-coming/ Det här nyhetsbrevet skickas till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré på Atea Sverige och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats.karlsson-landre@atea.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se .

Ett sprängfyllt nyhetsbrev som den här gången förbereder en kamp mellan två giganter, ger ett boktips om konsekvensdrivet säkerhetsarbete, tycker lite synd om Rockwell Automation, diskuterar konceptet "Insecure by design", ger en lång rad spännande lästips och en massa annat! Nyhetsbrev nummer 25! Något av ett jubileum alltså... Det första nyhetsbrevet skickade jag till fyra läsare. Tydligen fanns det ett och annat intressant bland mina tankar för nu är det flera hundra gånger fler som läser varje utgåva. Det är fantastiskt roligt med ett så positivt gensvar och jag vill verkligen skicka ett stort tack till dig som läser mina spretiga funderingar kring det här spännande ämnet! 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 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. 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å den här artikeln och genom att dela den vidare. Tack för hjälpen! Så olika men ändå så lika! Något jag slås av varje gång jag träffar nya verksamheter för att prata säkerhet är hur olika de ser ut på ytan, men hur mycket som går igen när man tittar innanför skalet! Ett sågverk kan väl inte ha mycket gemensamt med tillverkning av biogas? Hur kan en industrihamn vara besläktad med eldistribution? Man kan tycka att skyddet av medicintekniska system i sjukvården inte borde ha jättemycket att göra med en högteknologisk tillverkande industri men de har de! De har olika namn på saker och de har lite olika prioriteringsmetoder men de är alla ute efter att skydda fysiska funktioner från störningar och ganska ofta också att människor skyddas från att skadas fysiskt på grund av manipulerade eller störda OT-system. Miljöpåverkan är också ofta en risk som har stort fokus. En annan likhet mellan just sjukvård och hitech-tillverkning är att de både måste skydda väldigt känslig information i sina OT-system och se till att systemen i sig fungerar exakt som det är tänkt. I riskanalyserna hamnar man ofta på väldigt låga sannolikheter och extrema konsekvenser vilket ju kan kräva ett lite speciellt synsätt. Just detta är temat för mitt boktips lite längre ner där en väldigt intressant metod beskrivs. I förra nyhetsbrevet frågade jag om intresset för någon form av nätverkande eller onlineforum kring OT-säkerhet. Av svaren att döma verkar det glädjande nog som att intresset är stort. Jag tror just att mötet mellan människor från olika branscher som alla har ett intresse av OT-säkerhet kan bli riktigt spännande och roligt tack vare de oväntade likheterna mellan deras utmaningar! Det visade sig att mina tankar på någon form av diskussionsforum kring OT-säkerhet sammanföll med Karl Emil Nikkas tankar om något motsvarande fokuserat på IT- och informationssäkerhet. Du är kanske med i gruppen Säkerhetsbubblan på Facebook som han ligger bakom tillsammans med Jonas Lejon? Vi insåg direkt att det är bäst för alla om vi skapar ett gemensamt ställe att diskutera alla former av säkerhetsfrågor. Herr Nikka hade redan kommit en bra bit på väg i sina planer så då väljer jag att skrota mina egna planer och lägger min energi på att stötta honom i arbetet för en gemensam plats. Vi återkommer framöver med mer information... Intresset för att träffas och diskutera OT-säkerhet var också stort. Fysiska träffar avvaktar jag förstås lite för att se hur det går med pandemin. Någon form av digital träff skulle det däremot kunna bli framöver. Clubhouse hade ju kanske varit ett kul upplägg. Jag tar gärna emot förslag och tankar på former, teman och metoder! Om någon har en Clubhouse-inbjudan att skicka till mig så tar jag den gärna, måste bara skaffa en äpple-telefon också... För någon vecka sedan skapade jag en omröstning på LinkedIn om vilka delar av nyhetsbrevet som mina läsare vill se mer av. (Det är inte försent, tyck gärna till fortfarande!) Det verkar så här långt vara många som gillar dagens upplägg men med önskemål om att "Mats Filosoferar" ska ta lite större utrymme och även mina tankar kring aktuella händelser. Jag kommer förstås ta till mig önskemålen framöver! Giganternas kamp! Det är verkligen ingen hemlighet att jag tycker det är roligt att jag stöter på så mycket spännande teknik i mitt arbete. Nu måste jag säga att det är två ovanligt coola prylar som står i labbet och väntar på sin tur. Jag kan riktigt höra hur de frustar och stampar i marken som de båda fullblod de är. I den ena ringhörnan står en maskin som jag har nämnt i tidigare nyhetsbrev. Det är Pro-versionen av IPSen från TxOne, kallad "EdgeIPS Pro". De har tagit deras lilla ruggade OT-IPS som du kan läsa mer om i nyhetsbrev #23 och gjort en datacenter-version som innehåller 24 stycken separata IPS-segment! Dessutom har de kryddat anrättningen med en del extra funktionalitet. Det här är 16 kg brutal OT-IPS som i princip ska klara att maxa alla 24 Gigabit segmenten samtidigt! Det finns faktiskt en dubbelt så stor maskin också, men den har jag inte lyckats få fingrarna på ännu... Ett typiskt use-case för Pro-versionen är när man inte vill bygga in de små EdgeIPS-enhetern från TxOne i respektive maskin som ska skyddas utan hellre samlar skyddet i ett nätverksrum eller datacenter. Ett extra tack till TxOne som skickade den första Pro-burken i Norden direkt till mig! Det här ska bli riktigt roligt! I den andra ringhörnan står en riktig doldis för de flesta. Det är en "ixia PerfectStorm One" från Keysight. Keysight har jag nämnt tidigare, exempelvis deras fina lilla tap "IxTap" i nyhetsbrev 17. Den ser ärligt talat inte så mycket ut för världen, men specen säger någonting helt annat! Tanken med den här besten är att skapa verklighetstrogen testtrafik för att provskjuta mot olika typer av nätverkssäkerhetsutrustning. I den här kör man en programvara kallad "BreakingPoint" vilket är ett mycket passande namn... Genom de 8 portarna med SFP+ kan du skapa och pressa igenom 80 Gb/s av testtrafik. Det är dessutom inte vilken testtrafik som helst utan du kan krydda med mängder av attacker och skadlig kod. I det enorma biblioteket med elakheter finns en rejäl dos OT-specifika attacker att välja från. Det typiska use-caset är att simulera trafik för exempelvis en brandvägg genom att helt enkelt stadigt öka på med trafik tills brandväggen inte klarar mer och kastar in handduken! De här två tänkte jag matcha mot varandra framöver. Det kommer bli en intressant match mellan två riktiga tungviktare! Vi får hoppas att propparna och luftkonditioneringen håller för det kommer bokstavligen gå hett till! Vadslagning på vinnaren, någon? "Ooops!" eller "Insecure by design" Nyligen fick amerikanska automations-giganten Rockwell Automation (mest kända för varumärket Allen-Bradley) ett delikat problem kring en sårbarhet i en låååång radda av deras Logix-controllers. Sårbarheten fick dessutom CVSS-poäng 10, dvs den absolut värsta graderingen en sårbarhet kan få. Med tanke på att det var en bugg som gjorde det enkelt att helt ignorera alla former av inloggningskrav i produkterna var betyget kanske inte så förvånande. Det blev inte bättre när Rockwell några dagar senare tvingades annonsera att problemet inte skulle gå att lösa med en patch! Det är inte klart för mig ännu varför sårbarheten inte går att adressera med en patch, spontant är den enda förklaringen att sårbarheten på något vis är kopplad till hårdvaran - vilket låter osannolikt. Vi får se hur den här historien utvecklar sig... Jag hade egentligen tänkt att skriva en liten text om begreppet "Insecure by design" vilket INTE ALLS avser det som Rockwell råkade ut för, alltså produkter som designats lite tokigt och därmed är osäkra. Det här är ett begrepp som blivit populärt under senaste halvåret i diskussioner kring hur vi bygger våra automationssystem. Jag har hört lite olika varianter men min egen tolkning är att "insecure by design" avser faktumet att många komponenter och protokoll inte behöver "hackas" för att manipuleras - de är helt enkelt utformade för att göra som de blir åtsagda, oavsett vem det är som skickar ordern. Det låter som ett lite löjligt resonemang men det är förvånansvärt ofta man springer på situationer när någon är upprörd över att de hittat ett opatchat system och hävdar att det är ett hot mot verksamheten. Om det råkar vara ett system som är "Insecure by design" pekar man då på faktumet att, även om systemet var helt uppdaterat, så kör det en mjukvara som inte behöver hackas för att en angripare ska manipulera den fysiska processen. Allt man behöver finns till och med beskrivet i manualen! Nu var det som sagt inte det här som Rockwell drabbades av även om effekten i slutändan blev den samma. Sista ordet är inte sagt kring vare sig deras sårbarhet eller hur man ska värdera sårbarheter i OT-system... Konsekvensdrivet säkerhetsarbete - Ett boktips! Som jag teasade om i förra nyhetsbrevet så kommer här en berättelse om vad jag lärt mig av boken "Security PHA Review for Consequence-Based Cybersecurity" och något slags recension av boken. Boken gör en grundlig genomgång av SPR-metoden på cirka 140 sidor och gör det på ett sätt som känns lättillgängligt för de flesta läsare. SPR, som ska uttalas som det engelska ordet "Spur", syftar till att flytta fokus inom OT-säkerhetsarbetet bort från att skydda varje komponent och istället fokusera på att göra den fysiska processen "ohackbar" och därmed säker. (SPR är en förkortning av "Security PHA Review".) Det är viktigt att ha med sig att det man vill uppnå med SPR är framför allt att säkerställa att vi inte har ihjäl folk, skadar miljön eller orsakar stora fysiska skador som är svåra och dyra att åtgärda. Därför är det en metod som framför allt passar i processindustrier och då speciellt i verksamheter som har farliga moment i sin produktion. Eftersom man utgår från processen i den inledande riskanalysen, istället för att göra det som ISA/IEC 62443 kallar "en riskanalys på hög nivå", så identifierar man mycket lättare de ställen där skydd av OT-systemen kan göra verklig nytta för skyddet av processen. På samma sätt påpekar de att det som 62443 kallar "detaljerad riskanalys" inte alls är en riskanalys utan snarare en granskning av den design som tagits fram. Det här angreppssättet tar hand om ett av de områden som alltid stört mig i 62443-standarden och gör det på ett riktigt elegant sätt. Jag hoppas att få omsätta det här arbetssättet i ett verkligt projekt snart, det ska bli intressant! Man inser att man är en riktig nörd när man går igång på sådana här insikter... Författarna sågar ett antal andra metoder, som till namnet verkar vara ungefär samma sak, vid fotknölarna. Metoder som "Cyber PHA", "Cyber HAZOP" och "CHAZOP" siktar i praktiken på något helt annat och liknar egentligen mer feleffektsanalys (FMEA, "Failure Mode and Effects Analysis"). De har alla sin plats men med andra syften. Det som jag kanske gillar allra mest med SPR är att man tar ett rejält kliv bort från skogen och då plötsligt kan se träden. Andra verktyg tenderar ofta att bli väldigt detaljfokuserade, tekniska och omständliga men missar ironiskt nog det egentliga målet att skapa en översiktlighet av risker och hot. Man försöker göra något åt vartenda träd i hela skogen i förhoppningen att skogen borde bli bättre. I SPR börjar vi med att titta på skogen för att sedan välja vilka träd som är viktigast att göra någonting åt. Tidigt i boken gör de upp med några av de (som jag tycker) mest störande bristerna som man stöter på i "klassisk" analys av sårbarheter och risker. De hävdar (och jag håller med) att: Att en säkerhetsbrist i sig inte har någon konsekvens förrän någonting händer som gör att bristen påverkar processen. Ett trasigt bilbälte får ingen konsekvens förrän man krockar. Eftersom det finns så många konsekvenser av varje sårbarhet blir det omöjligt att veta vilka konsekvenser som inte kan uppstå eftersom de förhindras av någon helt annan säkerhetsfunktion eller någon begränsning i den fysiska processen. I en bil som bara går att köra i 5 km/h kanske ett trasigt bilbälte inte är ett problem men hur vet du bilens maxfart om du bara tittar på skyddet av föraren? Eftersom det nästan alltid finns massor med tänkbara konsekvenser av en sårbarhet blir sårbarheten också omöjlig att bedöma. Ett stulet lösenord kan användas på extremt många olika sätt, men vilka är värst och vad betyder det för risken av händelsen "Stulet lösenord"? Man tvingas ofta använda något slags påhittat värsta scenario. I många metoder är sannolikhet eller frekvens en viktig faktor för riskbedömningen vilket sällan är en meningsfull bedömningsgrund. Hur bedömer du sannolikheten för att en hacker lyckas hacka just ditt system? Hur ofta det har skett historiskt? Kommer de verkligen ge upp om de misslyckas i de första 20 försöken? Sannolikheter fungerar bra för slumpmässiga händelser men är väldigt mycket sämre för beslutsamma och medvetna mänskliga angripare. Just alla de där godtyckliga sannolikhetsbedömningarna som görs är nog den största anledningen till att jag genomlidit så många meningslösa workshops för riskanalyser. Ett annat alternativ som fungerar i många viktiga situationer är att använda kvantitativa metoder. Men det är en annan historia som har sitt eget existensberättigande. Vill du läsa mer så har jag skrivit om det i Nyhetsbrev #16. SPR-metoden bygger på att det redan finns någon form av PHA- eller HAZOP-liknande analys som man återanvänder genom att ta alla felscenarier och skydd från den och utökar dem med bedömningar av deras "hackbarheten" . Om man inte har sådana analyser får man helt enkelt göra det som en del av SPR-arbetet. Enkelt uttryckt kan man säga att en HAZOP-analys är ett systematiskt sätt för en grupp experter att identifiera alla sätt saker kan gå snett oavsett orsak och vilka skydd som finns för att motverka att farliga situationer uppstår. Om man ska summera vad SPR-metoden lägger till på ett extremt komprimerat sätt så blir det: För varje källa till avvikelser i processen analyserar man om den går att provocera fram genom att hacka en utrustning. Är den inte hackbar så är inte scenariet hackbart. (Här har jag en viktig invändning mot författarnas resonemang, se nedan.) Om källan är hackbar tittar man på de skydd som finns i processen. Om något av dem inte är hackbart så antas de skyddet motverka avvikelsen och därmed är scenariet inte heller hackbart. (Även här har jag invändningar, se nedan.) Om både källan och alla skydd är hackbara blir hela scenariet hackbart och då måste man hitta åtgärder. Åtgärderna kan bestå i att införa icke hackbara skydd eller att man höjer säkerhetsnivån i systemet. (Man använder då begreppet SL-T från ISA/IEC 62443, "Security Level Target".) Repetera för alla system och zoner. Sammanställ resultatet för helheten. Inför åtgärderna som identifierats. Vad är det då för invändningar jag har? Ja, det är faktiskt flera stycken... Enligt boken måste en hackbar komponent gå att nå med ett routbart nätverksprotokoll. I min värld så kan man mycket väl manipulera ett system även om det inte går att komma åt det, om det är möjligt att manipulera dess programmering utan att det upptäcks. I min erfarenhet är ofta utvecklingsmiljöer mindre skyddade än de system dit programvaran sedan flyttas. Man kan också vända sig mot att de kräver routbarhet eftersom det i så fall missar situationer där man hoppar mellan system med någon form av direktanslutning emellan dem. Författarna kräver att källan till en avvikelse ska vara hackbar för att scenariet ska vara relevant. För en angripare som har mycket tid kan det mycket väl räcka med att sabotera ett eller flera skydd och sedan bara vänta på att processen får en avvikelse "av sig själv". SPR-metoden säger att händelser och skydd som hanteras av människor inte är hackbara vilket i så fall ignorerar möjligheterna till "Social Engineering". Boken tar inte upp situationer där det av någon anledning finns krav på redundanta skydd. I sådana fall måste man ju förstås ta hänsyn till att det finns redundans bland de icke-hackbara skydden. Nu låter det som att jag sågar både boken och SPR-metoden rejält men så är det faktiskt inte. De lämnar öppningar för att skapa sin egen version av metoden som passar den egna verksamheten och dess industrityp. Vad som är acceptabelt och relevant får man avgöra själv med någon form av risk- och konsekvensanalys. Självklart måste arbetsmetoder och kravnivåer rimligen skilja mellan ett kärnkraftverk och en fabrik som tillverkar tandpetare... Som du (förhoppningsvis) ser i min beskrivning av SPR-metoden så letar man efter sårbarheter i den fysiska processen istället för i enskilda komponenter och man tittar enbart på konsekvenserna av olika scenarier. Sannolikheter dyker aldrig upp i resonemanget och mikroprocessorbaserade system betraktas som hackbara oavsett om de faktiskt har några sårbarheter eller inte. Och häri ligger metodens finess, fokus ligger på att helt bygga bort möjligheten för allvarliga konsekvenser att inträffa även om varenda system blir hackat... Om man ska knyta tillbaka till mitt filosoferande i förra nyhetsbrevet så får vi en chans att låta skyddet av processen verkligen kravställa skyddet av systemen, precis på det sätt som skyddet av informationen ska ställa krav på skydd av IT-system! Sammantaget kan jag verkligen rekommendera både boken och SPR-metoden. Metoden passar inte för alla typer av verksamheter men rätt använd och anpassad så tar den hand om en hel del störande moment i ISA/IEC 62443 standarden och flyttar fokus från att minska sannolikheter till att minska konsekvenser. Har din organisation redan bra koll på processäkerheten generellt sett (oavsett om det just är en klassisk HAZOP-metodik eller något annat) blir införandet av SPR inte någon omfattande sak att få till! Var annonseras sårbarheteter? Jag fick frågan om var man ska söka eller prenumerera på sårbarhetsannonseringar för OT. Personligen använder jag oftast amerikanska CISAs ICS-CERT: https://us-cert.cisa.gov/ics/advisories. För generella sökningar i kända sårbarheter är https://www.cvedetails.com/ alltid en bra källa. Gäller det en speciell tillverkare så är förstås deras egen annonsering viktig men där kan det vara lite olika spelregler beroende på om du har aktiva serviceavtal med dem. Jag söker mer OT-utrustning! Jag har ett litet OT-labb där jag konfigurerar och testar OT-säkerhetsutrustning för Nyhetsbrevet. Nu vill jag utvidga och bredda labbet och därför söker jag samarbeten med tillverkare och distributörer av intressant OT-utrustning för samarbete, lån eller köp av utrustning under "Not For Resale"-vilkor. Jag tänker mig allt från PLCer och IO-enheter till strömförsörjning, sensorer och HMI-paneler men även ren nätverksutrustning. Färdiga utbildnings- eller demonstrationsuppsättningar är också intressanta! Även begagnad utrustning som någon läsare har över är intressant. Hör av er! mats.karlsson-landre@atea.se. Lästips! https://www.sakerhetspolisen.se/publikationer/om-sakerhetspolisen/sakerhetspolisen-2020.html SÄPOs årsbok för 2020 släpptes i mitten av Mars och innehåller väldigt mycket intressant. Jag håller verkligen med om att de stora bristerna inom säkerhetsskyddsområdet är oroande, inte minst inom många kritiska OT-verksamheter! https://www.regeringen.se/rattsliga-dokument/lagradsremiss/2021/03/ett-starkare-skydd-for-sveriges-sakerhet/ Det var självklart ingen slump att Justitidepartementet släppte ett förslag till stärkt säkerhetsskydd dagen efter att SÄPO släppte sin årsbok. En mer framträdande roll för säkerhetsskyddschefer, säkerhetsskyddsavtal i fler situationer, bättre analyser av utkontraktering och större befogenheter för tillsynsmyndigheterna, låter alla som bra förslag! Kim Hakkarainen sammanfattar det bra här: https://blogg.mrpoyz.net/paradigmskifte/ https://www.fra.se/download/18.15d6ea201729ce403d2358/1615817255659/FRA-arsrapporten-for-2020.pdf När du ändå är igång så kom FRAs årsrapport samma vecka... https://download.schneider-electric.com/files?p_enDocType=White+Paper&p_File_Name=998-21085205_CybersecurityBusinessContinuity_GMA_whitepaper.pdf&p_Doc_Ref=998-21085205_GMA Ett intressant papper från SchneiderElectric som tittar på konsekvenserna av att inte ha med cybersäkerhetsåtgärder i sin krisplanering. Man använder pandemin som exempel för att illustrera hur OT-hoten påverkas av kriser i samhället eller någon annan övergripande händelse. https://hub.dragos.com/hubfs/Whitepaper-Downloads/Industrial-Cyber-Risk-Management-2021March.pdf Dragos tankar kring hur man ska bedriva risk management inom industrin. En del nya synsätt som jag gillar. https://www.pull-the-plug.net/thesis/ Avhandling av Jan Hoff från universitetet i tyska Hagen som föreslår en metod för att automatiskt skapa attackgrafer för OT baserat på "MITRE ATT&CK for ICS". https://www.splunk.com/en_us/blog/security/splunk-for-ot-security-v2-soar-and-more.html Splunk gör intressanta saker för att OT ska fungera bättre i klassiska SIEM-lösningar, något som många upplever som ett problem idag. https://www.willistowerswatson.com/en-US/Insights/2021/03/cyber-risk-and-critical-infrastructure Ett papper kring hur dagens IT-försäkringar bör närma sig OT-världen. Man kan ha många åsikter om försäkringars värde så lär dig mer! https://www.linkedin.com/pulse/legacy-system-problem-keeps-growing-dale-peterson De senaste veckorna har det nästan blivit bråk kring frågan om "insecure by design" i komponenter närmast våra processer. Här är ett av Dale Petersons inlägg om saken och här är ett par inlägg av Joe Weiss som har en annan åsikt: https://www.controlglobal.com/blogs/unfettered/observations-from-the-2021-sans-ics-cyber-security-conference/ och https://www.controlglobal.com/blogs/unfettered/lack-of-authentication-of-process-sensors-does-not-appear-to-bother-people/ https://www.txone-networks.com/upload/website/white_papers/normal/Network%20Segmentation%20-%20The%20OT%20Standard%20for%20Industry%204.0_20120818233.pdf Klokskaper kring segmentering och närbesläktade ämnen från TxOne som förstås är lite skruvade mot deras egna produkter men ändå har en del grundläggande guldkorn! https://www.ncsc.gov.uk/blog-post/what-is-ot-malware Genomgång av skadlig kod i OT-världen från brittiska NCSC som alltid levererar stabilt material. https://webbutik.skr.se/bilder/artiklar/pdf/7585-871-5.pdf Sveriges Kommuner och Regioner har tillsammans med Offentliga Fastigheter gett ut ett gediget material kring digital fastighetsautomation som pratar flitigt om säkerhetsaspekterna i detta spännande OT-område. https://www.missionsecure.com/blog/industrial-cybersecurity-applying-zero-trust-and-carta-to-operational-technology-ot Några intressanta reflektioner kring kopplingen mellan "Zero Trust" och OT-Säkerhet samt hur man knyter ihop det med CARTA.