5 juni

Nyhetsbrev OT-Säkerhet #62

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du två spännande produkter som varit i labbet, jag bevisar att jag är en nörd, lite gnäll över hur Purdue används, vi hittar förändringar i NIS2, jag läser en gammal bok med nya ögon och så vill tydligen Rockwell att vi kopplar bort deras grejor från Internet!

Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Läs mer om det här i det här nyhetsbrevet!

Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Det här nyhetsbrevet är ju något som jag fortfarande tycker är väldigt roligt att skapa, vilket förstås är viktigt eftersom det till största delen skrivs hemma i TV-soffan. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att anmäla dig på www.ot-säkerhet.se eller dra ett mejl till mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta!

Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i dess egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Mastodon, 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!

Statistik och röster från verkligheten...

Jag blir sällan imponerad av alla de statistik-rapporter som alla de stora produkttillverkarna tar fram för att visa hur farlig världen är och hur viktigt det är att vi köper just deras produkter. Ibland kommer det undantag...

Jag hittade faktiskt en del intressant i "2024 Threat Report - OT Cyberattacks with physical consequences" från Waterfall och i "Security Navigator 2024" från Orange. Jag ska inte ge mig på att tolka deras analyser här, men kan exempelvis tipsa om när Dale Peterson intervjuar Andrew Ginter från Waterfall:

Det verkar förresten som att lyckade attacker som inleds via "elaka länkar" i mejl tydligen nästan helt har upphört? Jag hör från folk som sysslar med incidentstöd till organisationer som drabbats att så gott som 100% av ransomware-fallen de senaste månaderna inleds genom attacker mot vanliga VPN-tjänster. Det har ju onekligen varit en strid ström av allvarliga sårbarheter i just sådana senaste året.

Det här är förstås ett superstarkt argument för att skaffa något annat än "en vanlig VPN". I OT-världen vill man ju ofta dessutom ha lite funktionalitet som inte finns i IT-världens lösningar. För ett bra exempel se min text om Cyolo i Nyhetsbrev #59.

Och på sjön...

Ett av mina specialintressen är OT-säkerhet inom sjöfarten. Jag har skrivit tidigare om de kommande regelverken som klassningssällskapen tar fram och som börjar gälla fullt ut i sommar. Nu börjar även certifierade produkter dyka upp, exempelvis gav DNV nyligen tumme upp till "Vessel Insight" från Kongsberg Digital baserat på DNV Cybersecurity Profile Level 1 (SP1) och IACS UR E27.

Det här är en spännande utveckling inom ett väldigt roligt område av OT-säkerhet där säkerhetsarbetet har ytterligare lite fler utmaningar jämfört med "vanlig" OT-säkerhet på landbacken...

NIS2 har ändrats!

NIS2-direktivet finns, precis som de flesta viktiga EU-dokument, översatta till 24 olika språk. Det betyder förstås att det alltid dyker upp språkliga missar efterhand. För vårt kära NIS2-direktiv är vi just nu uppe i 4 uppdateringar som ändrar på små, och ibland större saker, i texten. Den svenska versionen fick en intressant ändring i uppdatering nummer 4 och berör outsourcade verksamheter. Notera att det alltså är olika ändringar på de olika språken även i samma uppdatering.

Uppdatering 1 (Italienska och Nederländska)
Uppdatering 2 (Nederländska)
Uppdatering 3 (Slovenska)
Uppdatering 4 (Tyska, Estniska, Engelska, Italienska, Ungerska och Svenska)

Apropå uppdateringen kring outsourcing... Det här med att alla former av MSP- och MSSP-tjänster i sig omfattas av NIS2, är ett bra exempel på en av de branscher där det inte känns som polletten har trillat ner hos alla. Om du sysslar med drift eller säkerhetsövervakning av någon form av IT- och OT-prylar åt andra organisationer så omfattas du av NIS2.

Det finns fler polletter som inte ramlat ner överallt, exempelvis att man inte löser utmaningar kring NIS2 med produkter. Inte heller att det kommer en checklista med saker du måste göra. Det hindrar inte att många påstår detta, vilket fick mig att nyligen skriva det här inlägget på LinkedIn:

Det kommer bli intressant att se hur tillsynsmyndigheterna väljer att utforma sina föreskrifter. Personligen hoppas jag att man inte "förstör" chansen som direktivet och Cybersäkerhetslagen ger oss där man kan fokusera åtgärderna där de gör mest nytta för den egna organisationen men förstås då också tvingas tänka lite själv och att bygga upp kompetens kring risk- och säkerhetsarbete...

En gammal goding...

Jag får regelbundet frågor i stil med "Varför gillar du inte Purdue-modellen?" och mitt svar brukar lika regelbundet bli något i stil med "Jag har inget emot Purdue, men väldigt många har missförstått den." Jag har varit inne på detta många gånger förut i nyhetsbrevet. Den bästa förklaringen kring det här som jag hört är fortfarande från Ralph Langner:

Jag rekommenderar verkligen att du ser videon, det tar under 10 minuter. Om du sedan inte håller med vill jag verkligen höra varför! mats@ot-sakerhet.se

Några personliga kommentarer:

Segmentering är inte bara en nätverksfråga. Se upp med hur applikationer sträcker sig över segmenteringsgränser. Ett vanligt exempel är Active Directory som lätt blir en kortslutning mellan separata zoner som delar samma AD-tjänster.
"Utvecklade" versioner av Purdue-modellen har en DMZ-nivå mellan IT och OT. Det är absolut en bra idé att undvika direkt kommunikation mellan dessa världar. Men, på samma sätt som att "Nivå 2" inte ska uppfattas som ett stort nätverk är inte DMZ-nivån heller ett enda nätverk! System i ett DMZ är extra utsatta och ska definitivt inte kunna prata med varandra i onödan!
Min rekommendation är att använda något slags variant på "Zones & Conduits" enligt IEC 62443. Man måste inte nödvändigtvis använda den komplexa metoden för riskanalys som beskrivs i del -3-3 av standarden! Notera förresten också att Purdue-modellen inte existerar i 62443-standarden, mer än som ett exempel på möjliga arkitekturer.
Något som sällan diskuteras i det här sammanhanget är nätverk och system som "måste" ha kontakt med många andra komponenter. Varifrån administreras dina switchar? Hur tas backuper? Administration av hostar och lagring för virtualisering? Kan säkerhetssystemen bli en risk i sig själva?
Sist men inte minst... Den ultimata kortslutningen i många segmenterade nätverk, remote access! Här vill det verkligen till att tänka hela vägen! Vilka risker kan vi stå ut med? Hur ska vi göra nu när vi insett att en vanlig VPN är direkt olämplig?

Hur bevisa att man är en nörd?

Med tanke på hur mycket i mitt arbete som kretsar kring NIS2 just nu, så kunde jag inte låta bli att skicka in ett personligt remissvar till försvarsdepartementet kring förslaget till den nya "Cybersäkerhetslagen"! Remisstiden gick ut den 28:e maj! Jag misstänker att inte alla håller med om mina åsikter, så ta chansen att säg emot!

Eftersom jag inte formellt är ombedd att svara på remissen så går det inte att se mitt svar på Regeringskansliets hemsida, men du hittar min text i ett inlägg på LinkedIn. Det finns mycket bra att säga kring både NIS2-direktivet och den föreslagna Cybersäkerhetslagen. I mitt svar fokuserade jag på 6 saker som jag tycker kan förbättras men som inte fått den rätta uppmärksamheten:

Lagen sägs syfta till hög cybersäkerhet vilket jag tycker är ett lite inavlat sätt att se problemet. Det borde handla om att hantera samhällets risker som orsakas av brister i cybersäkerheten. Säkerhet har sällan något egenvärde!
Den svenska utredningen tog bort den viktiga poängen att säkerhetsåtgärder måste vara lämpliga för sitt användningsområde. Otroligt viktigt inom OT att vi inte använder åtgärder som är farliga för verksamheten!
En av mina stora käpphästar är att kemikaliesektorn definierats som att den inkluderar alla verksamheter som använder kemikalier för att producera andra varor. Det blir väldigt många industrier det!
Stora organisationer som till 99.99% inte omfattas av Cybersäkerhetslagen men som har 0.01% av sin verksamhet som gör det måste uppfylla lagens krav i hela verksamheten. (Skaffa inte solceller!) Känns inte riktigt rimligt...
En annan av mina käpphästar är att orden "tak" och "trösklar" anses betyda samma sak när man definierar övre och undre gränser för storlekar. Så var det inte på mina svenska-lektioner...
Vissa sektorer får tillsyn och föreskrifter från fyra olika länsstyrelser. Vore ju snyggt om det blev lite samordning där...

Några av dem (3 och 5) är problem redan i direktivet men skulle möjligen kunna tydliggöras i den svenska lagen.

Spanskt besök i labbet!

Jag har märkt att många läsare är lite extra intresserade när jag får chansen att berätta om mina äventyr med roliga saker i OT-labbet. Det tar ju förstås en hel del tid, så det blir lite långt mellan gångerna jag har något att skriva om. Den här gången är det lite extra roligt... Det är inte varje dag jag får chansen att testa en spansk OT-säkerhetsprodukt, men idag är en sådan dag!

Det är företaget Opscura som med produkten Lunaria löser utmaningarna kring att segmentera och övervaka OT-nätverk på ett nytt och spännande sätt! Deras mjukvara tar utgångspunkt helt och hållet i begreppen "Zones" och "Conduits" som vi känner igen från vår favoritstandard IEC 62443. Deras grepp bygger på att man kan låta sina nätverksprylar vara kvar mer eller mindre utan förändring. Istället stoppar man in en liten ruggad dator på de platser i nätet där det ska finnas en eller flera Zoner. Dessa datorer som kallas för "VIA" och administreras i ett samlat gränssnitt.

Till en början kan man låta trafik fortsätta flöda helt utan påverkan genom Viorna och i administrationsgränssnittet analyserar den verkliga trafiken i nätet. Sedan definierar man sina zoner och hur dessa får kommunicera med varandra genom Conduits.

Opscura har på det här sättet lyckats skapa något som i praktiken är ett slags Software Defined Network, men utan att nätverksutrustningen behöver ha stöd för det. Switcharna kan till och med vara omanagerade om man nu tycker det är trevligt med sådana. Deras lösning ger en massa fina finesser som annars kan bli tråkiga överraskningar när man driftsätter en sådan här lösning i OT-sammanhang:

Om man vill kan man släppa fram broadcast-trafik, "Layer 2", vilket gör det möjligt för programmeringsverktyg och annat som ofta använder just broadcast för att exempelvis hitta nya PLC:er på nätverket redan innan de konfigurerats.
I och med att man definierar en Conduit mellan två Zoner så definierar man också brandväggsreglerna som ska gälla för den kommunikationen. Det betyder att filtreringen sker ute på varje Via och inte behöver involvera vanliga brandväggar.
Om man vill samla in trafik i nätet för att skicka till exempelvis en IDS, såsom Nozomi Guardian, blir det oftast svårt att få tag på trafik "långt ut i nätet". Opscura kan aggregera trafik som samlas in ute på de olika Viorna och presentera det som en samlad kopia på ett lämpligt ställe där IDS:en kan suga i sig trafiken.
Med samma funktion som samlar nätverkstrafik till en IDS kan man också spela in nätverkstrafik någonstans i nätet och sedan ladda ner den som en pcap-fil som går att titta på i Wireshark eller något annat verktyg. Helt ovärderligt för både felsökning och när man planerar segmentering.

För att testa om det här fungerar i verkligheten drog jag igång en test-process som jag skrivit om förut i bland annat Nyhetsbrev #54, en PLCnext från Phoenix Contact som styr en hiss och några transportband som simuleras i Factory IO via ett remote IO över MODBUS TCP.

Via-funktionerna körs på två fysiska datorer, som i det här fallet kommer från Schneider Electric och management-servern körs på en annan liten PC. I labbet står de intill varandra men i praktiken finns de kanske på helt olika platser med någon form av nätverksförbindelse mellan dem.

Inkopplingen av de två Viorna mellan PLC:n och IO:t i labbuppställningen var helt odramatisk. Det blir förstås ett avbrott när man drar ut en sladd men sedan flödade funktionen som vanligt trots att nätverkstrafiken passerade fram och tillbaka genom de två Viorna.

I det här läget kan man välja att manuellt skapa Zones och Conduits i administratörsverktyget, under förutsättning att man vet vilken typ av kommunikation som behövs. Annars drar man igång Opscuras inbyggda analys av all nätverkstrafik som direkt listar vilka enheter som pratar på nätet, vem som pratar med vem och sedan ritar upp detta tydligt.

De blå rutorna i bilden är Viorna och visar vilken Via som hanterar vilka enheter på nätet. Zoomar man in närmare så ser man vad som är vad:

När man har sina Zones och Conduits så ber man Viorna att sluta bete sig som en "Wire" och istället börja skydda trafiken. Jag slog på skyddet medan "tillverkningsprocessen" var igång och det fungerade utan störningar! När man tittar på trafiken på nätet ser man tydligt att det istället för MODBUS-paket enbart skickas krypterad trafik mellan Viorna.

Före:

Och efter:

Ja, trafiken som går genom en Conduit är alltså automatiskt krypterad. Då kanske någon tänker: "Men kryptering kan ju vara lite klurigt i OT-världen?". Ja, så är det men i det här fallet ser jag faktiskt ingen nedsida:

Systemet sköter om all nyckelhantering själv
Det gör inget att trafiken blir "osynlig" eftersom Lunaria kan erbjuda en kopia av all trafik till IDS:er och liknande säkerhetslösningar.
Krypteringen gör att man kan skicka trafik genom nätverk som man inte litar fullt ut på även om man förstås inte löser risker med avbrott orsakade av angrepp mot nätverket.
Även om kryptering alltid introducerar en liten extra fördröjning så verkar lösningen verkligen vara trimmad på ett sätt som gör påverkan minimal. Jag kanske inte skulle använda den på väldigt tidskritiska lösningar men annars så...

Om du läst tidigare nyhetsbrev så vet du kanske att jag har stort hopp om att SDN, Software Defined Networking, ska bli en vanlig lösning för OT-nätverk. Opscura infriar väldigt mycket av den nytta som SDN ger, men på ett sätt som inte påverkar den underliggande nätverksinfrastrukturen. Det blir förstås extra intressant i sammanhang där utrustningen finns på olika fysiska platser och kommunicerar mellan nätverk som kanske hanteras av olika grupper.

Är man på jakt efter en lösning som gör det enkelt att bygga nät baserat på Zones och Conduits tycker jag absolut man ska överväga Opscuras lösning!

Vem vill ha ett trasigt nätverk?

I det här nyhetsbrevet får du faktiskt två tester i labbet! Jag har lyckats få fingrarna på en väldigt "udda" men rolig produkt från Keysight som simulerar "dåliga" nätverk, NE2 - "Network Emulator 2".

Det är ju inte helt ovanligt att ett system fungerar bra när man testar det under perfekta förhållanden, men sedan fungerar mycket sämre efter driftsättning när nätverket tappar enstaka paket eller det blir fördröjningar på grund av långa avstånd. Med NE2 kan man bli väldigt kreativ med elakheterna som man vill introducera under tester!

Som vanligt när det är en Keysight-produkt så är det väldigt välgjort och kompetent! Jag kom snabbt igång och kunde simulera en dålig förbindelse mellan de två Viorna i Lunaria-lösningen i föregående text. Trots ett något blygsamt utseende är det en riktigt kraftfull manick! Du har möjlighet att manipulera upp till fyra separata nätverksförbindelser samtidigt som valfritt kan vara koppar eller fiber, var och en upp till 16 Gb/s.

Det finns en rejäl arsenal med påverkan som man kan kombinera för att simulera utmanande nätverk. Vad sägs exempelvis om att:

Rena bit-fel, där en eller flera slumpmässiga bitar i huvudet eller innehållet för vissa paket blir fel. Slumpmässigheten styr du själv och kan baseras på olika statistiska fördelningar: Periodic, Uniform, Gaussian och Poisson.
Trasig laser för fiberförbindelser där lasern helt enkelt stängs av slumpmässigt.
Påverka hur paket fördelar sig över tid, exempelvis skapa "Bursts".
Låtsas vara en asymmetrisk förbindelse, typ DSL eller satellit, som har olika hastigheter i de båda riktningarna.
Maximera bandbredden som kan användas.
Påverka olika typer av trafik på olika sätt.
Skapa IPv4-fragmentering genom att automatiskt hugga sönder paket och dela upp dem i flera mindre paket.
"Tappa bort" paket på valfritt slumpmässigt vis.
Manipulera innehållet i paket men återställa checksummor så de stämmer.
Fördröjningar som kan vara konstanta eller slumpmässiga.
Byta ordning på nätverkspaket så de kommer fram till mottagaren i "fel" ordning.
Slumpmässigt skapa kopior av paket så att det kommer flera av samma till mottagaren.
En del av dessa elakheter kan dessutom utföras på Fibre Channel om man har sådana förbindelser.

Det här är en riktigt cool pryl som definitivt platsar om man är riktigt seriös i sina tester av systemlösningar. Mina tester med Lunaria visade tydligt att Opscura klarar "dåliga" nätverksförbindelser, men man kan tyvärr inte säga samma sak om min PLC-programmering som spårade ur rejält när jag var elak mot den...

Det vanligaste problemet för OT-lösningar som man kan komma åt med NE2 är nog system som kommunicerar över långa avstånd eller via media som drabbas av en del störningar.

Att kunna hitta lösningar på sådan påverkan redan under testerna blir mycket enklare än felsökning när man väl är ute i fält! Som vanligt gillar jag Keysights sätt att leverera solida lösningar på ovanliga utmaningar! Snyggt jobbat!

Ett boktips från förr!

Man kan tycka att det är en bok som jag borde ha läst för länge sedan, men jag har alltid tänkt att jag redan hört alla historier kring NotPetya, Sandworm, Projekt Aurora, Industroyer och 74455 - hur mycket mer kan Andy Greenbergs klassiska bok "Sandworm" tillföra?

Det visar sig - en hel del! Det var en del pusselbitar som föll på plats och att läsa om händelserna i Ukraina 2017 fick förstås lite extra tyngd. En bok som alla som sysslar med OT-säkerhet bör läsa men också alla som någonsin uttalat orden "Varför skulle någon vilja hacka oss?".

Stark läsrekommendation helt enkelt! Passar utmärkt som semesterläsning...

Jag har inga sårbarheter kvar - kan jag ta ledigt då?

I IT-världen innebär aktivt säkerhetsarbete ofta att man spenderar mycket tid på att jaga nyannonserade sårbarheter i mjukvara, CVE:er. Ni vet hur det är... "Oj! Titta på den här nya sårbarheten i vår webbserver, nu måste vi genast patcha!". Det innebär en ständig jakt mot något slags perfekt tillstånd där man inte har några sårbarheter.

Om det är svårt för IT-folket så blir det genast ännu värre i de flesta OT-miljöer på grund av alla möjliga viktiga begränsningar i hur vi vill ändra i våra system. Det innebär att målet "Noll sårbarheter" blir så gott som omöjligt att uppnå. Dessutom blir det som jag skrev i Nyhetsbrev #59 så krävs trots det väldigt mycket arbete för att analysera vilka sårbarheter som verkligen är viktiga för oss ur den fullkomliga floden av sårbarhetsannonseringar som flödar över oss!

Nästa insikt kommer när man börjar fundera över så kallade "Zero Days", alltså sårbarheter som de elaka hackarna känner till, men som ännu inte upptäckts av oss andra. Vi kommer alltså sannolikt aldrig ha "Noll sårbarheter", utan bara "Noll av oss kända sårbarheter". Det är en väldigt jobbig tanke i IT-världen, där man ofta är väldigt exponerad för omvärlden. Men för OT-folket blir det också en jobbig tanke men av delvis andra skäl, vi är ju vana att vi ska bygga robusta system som tål att något går snett i den fysiska processen. Varför kan vi inte göra samma sak när händelsen orsakas av en cyberbrist?

Ett koncept som vi borde diskutera mer är "Cyberrobusthet". Alltså tanken att våra system exempelvis ska tåla en oväntad sårbarhet som utnyttjas utan att något allvarligt inträffar och att vi dessutom alltid ska upptäcka att det hänt.

Det finns förstås många olika sätt att närma sig den här frågan. Jag har tidigare skrivit om metoder som CCE, "Consequence-driven, Cyber-informed Engineering" där man just fokuserar på att bygga bort allvarliga konsekvenser med fysiska åtgärder. Lite på samma tema kan man tänka kring potentiella sårbarheter som man inte känner till ännu.

I Nyhetsbrev #49 skrev jag om MITREs nya version av CWE-ramverket som nu mappar mot några av delarna i IEC 62443. Om man tar den kopplingen och använder den för att göra analysarbetet jag skrev om i Nyhetsbrev #59 så kan man bygga ett försvar som gör ännu så länge teoretiska sårbarheter harmlösa genom att förekomma dem med andra åtgärder än patchning. Man resonerar alltså kring typer av sårbarheter snarare än en viss specifik sårbarhet, vilket är svårare men också mer meningsfullt!

Det här gör att vi också får ett annat bra resultat på köpet, vi slutar resonera om sårbarheter i betydelsen "Buggar i mjukvara" och byter till att prata om det som ordet "Sårbarheter" egentligen betyder - nämligen svagheter i våra systems robusthet. Blir systemen så robusta att de tar hand om mjukvarubrister så har vi ju ingen sårbarhet!

Jag tror det här är ett mycket vettigare sätt att spendera säkerhetsresurserna än att syssla med brandsläckning. Det är lätt av avfärda resurser som MITRE CWE med "Det där är för utvecklarna", men då missar man riktigt viktiga poänger. Det är lite likt hur man kan använda MITRE ATT&CK för att analysera sina försvarsförmågor. Vi kanske inte får ta extra semester men vi får i alla fall vara ifred för sårbarhetslarm på semestern.

Samtidigt är det här förstås inte svaret på alla våra problem. Vi kan inte alltid utforma våra system på det optimala sättet för god cybersäkerhet, eftersom det skapar andra typer av risker som vi tycker är värre! Begreppet "insecure by design" används ibland lite skämtsamt för detta. Allt detta är dessutom beroende av ett aktivt säkerhetsarbete så att systemens förmågor inte förfaller över tid.

På samma sätt måste vi också se upp så att vi över lite längre tid inte börjar kompromissa bort alltför mycket av vårt säkerhetstänk. Marco Ayala pratade om precis detta på årets S4-konferens, tänkvärt...

Den bäst bevarade hemligheten inom svensk industri!

Jag spenderade nyligen några dagar på Elmia Produktionsmässor i Jönköping. En verklig högtid för alla med koppling till tillverkande industri, massor med automationlösningar, verktygsmaskiner och annat kul att titta på.

Mindre kul var att jag hade samma upplevelse som tidigare år, nämligen att det inte finns något som helst fokus på säkerhetsfrågor. Kunderna frågar inte efter det och leverantörerna skryter inte om att de har det. Bland alla föredrag och presentationer under mässdagarna så var det (nästan) bara jag som pratade säkerhet.

Dessutom var det väldigt tydligt att industrin inte har förstått att NIS2 och den nya Cybersäkerhetslagen även berör många tillverkande industrier. Det kommer bli ett hårt uppvaknande för många framåt hösten...

MSB svarar på frågor!

Ett steg i rätt riktning är att MSB och vissa av tillsynsmyndigheterna börjat ha informationsevent kring NIS2. MSB har annonserat att man kommer svara på de vanligaste frågorna den 18:e juni.

Öppen antagonistisk hotbild för svensk elförsörjning

Svenska Kraftnät släppte nyligen dokumentet "Öppen antagonistisk hotbild för svensk elförsörjning" som kan vara väldigt intressant även om man inte är i elbranschen.

Säkerhetskrav för elnät?

Jag har ärligt talat inte hängt med på det sätt som jag kanske borde när det gäller EUs nya förordning för "gränsöverskridande elflöden". Det låter ju inte vansinnigt relevant för så speciellt många verksamheter, eller hur?

Nu i mars släpptes så den slutgiltiga versionen och när jag nu läser så noterar jag en del intressant ändå:

Lite på samma sätt som exempelvis CER-direktivet ska man inte själv avgöra om den egna organisationen omfattas, man blir utpekad av en myndighet.
Inte bara elföretag kan omfattas utan även exempelvis MSSP - Managerade säkerhetstjänster, IT-outsourcingleverantörer, elbilsladdare mm
Det är väldigt många kopplingar till NIS2-direktivet

För den som ligger nära sådan verksamhet eller har kunder som gör det bör nog följa med vad som kommer framöver kring den här kravmassan!

Kanske en kurs hos Svenska Kraftnät?

Jobbar du i en verksamhet som påverkar elnätets stabilitet som producent eller förbrukare? Då har Svenska Kraftnät en kurs för dig!

På deras utbildningssida står:

Svenska kraftnät arrangerar sedan en tid tillbaka en kurs för personal inom elsektorn där deltagarna får bekanta sig med ett brett spektrum av risker och hotscenarier kopplade till cybersäkerhet och industriell styrning (ICS).

Under 2023 har runt 200 personer antagits och genomgått kursen. Kursen är en elberedskapssatsning och målgruppen är personer som direkt eller indirekt arbetar med elnätsdrift, it-stöd eller säkerhet på svenska elnätsföretag, hos vissa större förbrukare eller i andra organisationer vars verksamhet kan påverka nätstabiliteten.

Kursen genomförs i internatform under tre dagar (lunch-lunch) och är anpassad för att underlätta deltagande från hela Sverige. Anmälan sker efter inbjudan från Svenska kraftnät. Intresseanmälan kan skickas till icskurs@svk.se.

Här behövs också en kurs!

Jag kan tyvärr inte säga att jag är förvånad... Runt om i världen fortsätter det inträffa hacker-incidenter där OT-utrustning som placerats direkt på Internet blir saboterade. Å andra sidan ska man definitivt inte tro på siffrorna i Shodan och andra scanningsverktyg, det är sannolikt minst 80% honeypots bland de OT-prylar som dyker upp där. Men ändå...

Jag fick nyligen ett mejl från Rockwell Automation som skickade ut en advisory med den fantastiska rubriken:

IMPORTANT NOTICE: SD1672 – Rockwell Automation Reiterates Customer Guidance to Disconnect Devices from the Internet to Protect from Cyber Threats

Att det kan hända av misstag ska man naturligtvis tänka på och försöka upptäcka som del i sitt säkerhetsarbete. Jag är nyfiken att höra om dina erfarenheter, har du hittat tokigt installerade prylar?

Ska vi höras?

I ett tidigare nyhetsbrev öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt så jag kommer repetera den här texten framöver. Jag har redan haft ett antal kul samtal med roliga människor från spännande verksamheter av alla de slag. Du behöver förstås verkligen inte vara proffs på just OT-säkerhet för att det ska bli ett intressant utbyte av erfarenheter och tankar!

En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite.

Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt.

Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra.

Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats.

Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Active Directory? Hemmalabbet? Incidentövningar? Du väljer!

Vem är Mats?

Jag är till vardags säkerhetsrådgivare kring OT på AFRY. Det här nyhetsbrevet ger jag ut helt privat baserat på mitt intresse för området och utifrån att det verkar matcha ett behov av information kring OT-säkerhet på svenska.

Innan jag blev konsult för några år sedan spenderade jag det mesta av mitt arbetsliv inom kärnkraftsbranschen. Det är härifrån som jag har fått mitt intresse för OT-säkerhet, fysiskt skydd, human performance och säkerhetsskydd.

Jag har ett grundmurat intresse för alla former av säkerhetsfrågor och kanske i synnerhet när det knyter samman kul teknik med utmanande frågor runt hur vi människor hanterar tekniken. På senare år är det nästan uteslutande OT-säkerhet och till viss del säkerhetsskydd som jag arbetat med. Båda två år områden där det är väldigt viktigt att hantera tekniska och mänskliga utmaningar tillsammans.

Jag är alltid väldigt tacksam för alla former av kontakt eller återkoppling från dig som läser detta. Det är intresset från mina läsare som gör det roligt och meningsfullt att hålla liv i nyhetsbrevet. Hör gärna av dig till mats@ot-sakerhet.se !

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.