Sökresultat

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången funderar jag på vad man kan skydda, jag tittar på OT-innehållet i Sveriges nya cybersäkerhetsstrategi, MSB har tittat på OT-utmaningar, det har dykt upp nya prylar hemma i labbet, noterar att gruvor inte har säkerhetsutmaningar, funderar på var som är proportionerligt och så har jag två AI som diskuterar nyhetsbrevet. 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å Bluesky , 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! Nyhetsbrevet diskuteras i en ny "podd" Jag provar nu att erbjuda ett nytt grepp för att ta till sig det här nyhetsbrevet. Nu kan du höra mina goda AI-vänner Aileen och Aiden diskutera det jag skrivit i deras podd . Jag är väldigt nyfiken på att höra dina åsikter om detta är något som är värt att producera även i fortsättningen? Är det ett bra komplement till nyhetsbrevet eller till och med bättre? Eller borde jag skapa något slags podd själv, en "riktig"? Kommentera gärna det LinkedIn-inlägg där nyhetsbrevet annonserades eller hör av dig till mig på mats@ot-sakerhet.se . Du kan inte skydda det som... Den som pysslar med OT-säkerhet vet att det varit mycket fokus på asset management på senare år, alltså att man gärna skaffar verktyg som hjälper till att hitta de prylar som finns i våra anläggningar. Detta för att vi ska kunna hålla koll på vad det är, var de är, hur de sitter ihop, vilka sårbarheter de har och kanske hur de påverkar varandra. Ett slagord som man brukar höra i det sammanhanget är någonting i stil med " You cannot protect what you don't know you have! ". Det är förstås helt sant och definitivt något att tänka på. Baksidan av det resonemanget är att jag sett en lång rad organisationer skaffa fina (och dyra) verktyg som de sedan inte lyckas skapa något värde med. Man har kanske fått lite bättre kvalitet i sitt CMDB/inventarieregister, men nyttan för organisationen dyker liksom inte upp. Det finns nämligen ett ännu viktigare slagord som de ofta missat: " You cannot protect what you do not understand! ". Det finns dessutom två bra tolkningar av detta: Vi behöver ha kompetensen att förstå utrustningen som vi hittat. Det är tyvärr lite för vanligt att någon stackars IT-person får detta i knät och har väldigt svårt att göra något meningsfullt med informationen på egen hand. Man måste förstå produktionsprocessen där prylarna ingår. Det viktiga är inte att skydda prylarna i sig utan att se till att processen inte störs! Som en variant på den andra punkten brukar jag slänga mig med ett annat slagord: " IT är ett stöd till verksamheten, men OT är verksamheten! " Jag menar inte alls att OT är viktigare än IT, utan istället att OT-säkerhet inte går att bedriva utan att ha förstått produktionsprocessen. Det här är extra viktigt att ha med sig för alla som tar sig an NIS2. Det är lätt att man börjar skydda utrustning "blint", men det gäller att hålla kvar fokuset på att åtgärderna ska hantera de risker som organisationen och samhället utsätts för om produktionen inte fungerar som den ska! Annars blir det lätt att vi spenderar tid och pengar men får väldigt lite effekt... En ny nationell strategi som pekar på OT-säkerhet! Medias intresse för att vara på plats var lågt när Carl-Oskar Bohlin presenterade Sveriges nya cybersäkerhetsstrategi, men jag tror definitivt inte det ska ses som lågt intresse för frågan. Själv satt jag som klistrad framför direktsändningen med en påse chips i handen... Efter en första snabb titt på strategin  så verkar den riktigt lovande. Om inte annat så har nu det viktiga begreppet OT-säkerhet börjat dyka upp på allvar i dessa sammanhang! Man beskriver dessutom på ett mer handfast sätt än tidigare de faktiska mål som ska uppfyllas senast 2030. Om du vill läsa strategin så finns den faktiskt i två versioner, en som är regeringens formella skrivelse och en som är "glättigare" för att bli mer tilltalande. Innehållet ska vara samma i övrigt. En sida av strategin som har orsakat en del irritation och diskussion är att man lämnat begreppet "Informationssäkerhet" och istället följer i EUs fotspår genom att prata om "Cybersäkerhet". Den klassiska modellen har ju länge varit att allting handlar om att skydda information vilket gör IT-säkerhet, OT-säkerhet och Cybersäkerhet till underordnade delar av Informationssäkerhet. Det är en vettig modell när fokuset är just på information oberoende av hur den lagras och överförs. Men det är också en riktigt dålig modell i många sammanhang, och i synnerhet när man kommer till OT-säkerhet! Personligen är jag väldigt positiv till att Cybersäkerhet används som paraplybegrepp, även om jag inser att det också har baksidor, kanske framförallt när vi pratar om säkerhetsskydd och annat där informationen ofta står i centrum. Om man däremot fokuserar på NIS2 så blir arbetet med NIS2 mycket tydligare i och med att orden har samma betydelse! OT-säkerhet pekas det speciellt på i flera sammanhang: Kompetens- och kunskapsbrist -- Något som jag definitivt kan skriva under på, det behövs mycket fler som verkligen förstår utmaningarna kring OT-säkerhet och inte bara ser det som IT-säkerhet i en fysisk pryl. Digitaliseringen av kritisk samhällsinfrastruktur -- Man pekar på att förutsättningarna inom OT-säkerhet är väldigt speciella. Bra där! Säkerhetsövervakning -- Detta är något som ska stimuleras med stort fokus på OT-system inom kritisk infrastruktur. Proportionalitet -- Man trycker på att även OT-säkerhet behöver dimensioneras utifrån betydelsen för samhället och hotbilden mot den. MSB ska vidareutveckla Cybersäkerhetskollen. MSB ska ge stöd för arbete med OT-säkerhet inom samhällsviktiga verksamheter. Vi får nog vänta ett par månader till innan vi ser ett färdigt lagförslag utifrån NIS2 men om det ligger i linje med den nationella cybersäkerhetsstrategin (vilket är väldigt rimligt) så tror jag det kan bli riktigt bra. Vad är det som hindrar oss? Att säkerhetsarbete har sina utmaningar är inte någon nyhet för någon; inte heller att OT-säkerhet har sina egna klurigheter. För att reda ut hur det ligger till i OT-säkerhetsarbetet inom "samhällsviktiga verksamheter" så har vännerna på MSB gjort ett intervjuarbete och skrivit en rapport över resultatet . Jag tror inte resultatet kommer förvåna någon som är i branschen men det är ändå bra att det sätts på pränt, det gör det enklare att börja ta tag i utmaningarna på riktigt! Första steget mot en EU-standard för CRA! Sarah Fluchs förklarar i en artikel hur den nya harmoniserade EU-standarden EN18031 hänger ihop med det utökade Radiodirektivet "RED", där cybersäkerhetskrav numera finns för alla produkter som innehåller någon form av radiosändare. Det är förstås intressant i sig självt, men kanske i synnerhet som en försmak för vad som kan komma för CRA, Cyber Resilience Act och cybersäkerhetsdelarna i Maskinförordningen. Jag rekommenderar en genomläsning av Sarahs korta text . Tyvärr verkar det som en del ganska grundläggande saker i CRA fortfarande inte är klarlagda. Jag tänker speciellt då på det viktiga begreppet "Produkt" som beroende på vem man frågar antingen betyder "en typ av produkt" eller "en enstaka individ". Det låter kanske lite akademiskt men det får stor effekt på när vissa krav börjar gälla för existerande produkt-typer! Nytt (och gammalt) i labbet I mitt kära OT-labb där hemma har många spännande prylar passerat förbi genom åren. Jag har ofta känt att det blivit lite för mycket fokus på infrastruktur och nätverk, det har varit massor av brandväggar, switchar och IPS:er, men alldeles för lite klassisk processutrustning. Nu är det nya tider! Men inte helt nya grejor... En av de intressanta och utmanande delarna med arbetet som säkerhetsrådgivare inom OT-säkerhet är att man oftast behöver förhålla sig till gammal, men "väl beprövad", utrustning. Alltså borde hemmalabbet se ut på samma sätt! Några av de allra senaste fynden ser du på bilden. En bättre begagnad Mitsubishi Melsec-PLC, remote I/O från Wago, en frekvensare från Allen Bradley, ett säkerhetsrelä från Pilz, lite Profibus-prylar och en flödes/tryck-mätare från ABB. Verkligen högt och lågt - stort som smått... Tillsammans med Melsec-PLC:en fyndade jag dessutom en "tillverkningsprocess" i form av en äkta Fischertechnik "mini-fabrik" som normalt sett är löjligt dyr att köpa. Processen är inte så speciellt avancerad kanske, men fullt tillräcklig för att skapa realistiska scenarier. Se "hemmavideon" nedan.... Vissa av sakerna har jag fyndat begagnade, medan annat är presenter från läsare av nyhetsbrevet som haft prylar över. I det här fallet ville givarna vara anonyma, men ett stort tack får de här i alla fall! Det är förstås helt ovärderligt för mig att få fingrarna på mer utrustning! Rena julafton faktiskt! Det som jag har svårast att få tag på är mjukvaror och licenser, så där är jag extra tacksam - även för äldre versioner som någon har liggande i skrivbordslådan. Det händer också att produktleverantörer lånar ut eller ger bort spännande prylar, vilket jag förstås uppskattar väldigt mycket eftersom det är modernare utrustning. De senaste veckorna har det dykt upp lite nya prylar som produkt-tillverkare lånat ut. Men jag har inte har bestämt mig om jag ska skriva om dem eller inte, så deras identitet får förbli en hemlighet tillsvidare... Det är för övrigt en av de tre principer som jag satte tidigt i nyhetsbrevets historia: att jag bara skriver om produkter som jag verkligen gillar själv. (Ni får fundera själva över vad som inte dykt upp i nyhetsbrevet...) att jag aldrig tar betalt av de företag som syns i nyhetsbrevet. Det är belöning nog att få klämma på rolig teknik. att jag verkligen ska ha utvärderat produkterna själv, att skriva om något som jag bara sett en demonstration av blir för tunt! Det fortsätter vara min starka ambition att behålla en fot i den praktiska teknik-världen, vilket också ska synas i nyhetsbrevet. Dels för att det är otroligt roligt, men jag märker att det ger mig mycket bättre trovärdighet - både på "golvet" och i "styrelserummet". Dale inledde årets S4 på ett välbalanserat sätt! Jag deltog inte själv på årets S4-konferens, men det verkar som vanligt ha varit en utmärkt tillställning. De första inspelningarna har börjat dyka upp på YouTube och bland dem Dales egen keynote-dragning . Jag nöjer mig med att notera att han pekar på ett antal av mina egna käpphästar, resten får du höra direkt från honom själv: Kom ihåg att vi alltid har begränsade resurser för säkerhetsåtgärder. Se till att prioritera på ett klokt sätt! Att hitta viktiga saker att prioritera upp är enkelt. Det utmanande är att prioritera ner viktiga saker till förmån för de mest effektiva åtgärderna. Att avgöra vad som är mest effektivt är i det närmaste en konstart man kan komma i mitt skrå. Att utifrån erfarenhet, kunskap och mod välja bort bra åtgärder är inte enkelt och det kommer aldrig finnas ett facit! Att bocka av åtgärder i IEC 62443 eller ISO 27002 är definitivt inte svaret! Jag hoppas fler tar till sig at Dales kloka ord! Han sätter verkligen fingret på det som jag oftast känner är mitt viktigaste bidrag som inhyrd rådgivare, att hitta de starkaste korten att spela bland andra starka kort! I övrigt börjar årets presentationer nu dyka upp i S4:s YouTube-kanal . En riktigt intressant är NVIDIAs satsning på säkerhet genom Bluefield och Morpheus , något som kan bli extra stort inom OT. Skulle jag sätta en peng på något som kommer förändra säkerhetslösningar i grunden så är det detta. Jag tror dessutom det kommer ”synka” bra med vårt tänk eftersom säkerhetsdelarna är separerade från de producerande applikationerna. Förvisso en löjligt ”säljig” presentation men ändå värd att se för att förstå hur brutalt nya möjligheter vi står inför. Bli min kollega! Jag behöver en rådgivarkollega! ...eller två! ...eller tre! Nu bygger vi på Sectra vidare på Sveriges starkaste OT-SOC med bred kompetens och fler tjänster kring OT-säkerhet! Vi söker i hela Sverige ! Ett Sverige utan bakdörrar! Jag uppmärksammade nyligen i ett inlägg på LinkedIn att Clavister har en fantastisk deklaration som man exempelvis kan läsa i deras manualer: Det här ligger ju verkligen i tiden på flera sätt. Dels för att säkerhetsläget i världen förändras snabbt nu och dels för att exempelvis NIS2 kommer tvinga oss att ta våra leverantörers säkerhetsarbete på mycket större allvar. Ett enkelt sätt att hantera delar av det problemet är förstås att undvika uppenbara risker med utländska komponenter och tjänster som lyder under andra länders underrättelselagar... Inlägget fick massor av reaktioner och ganska snabbt så räckte även Xertified upp handen . Nu går vi och väntar på ytterligare produktleverantörer som vill ställa sig bakom det här löftet, oavsett om de är svenska eller inte! Lite på samma tema har flera läsare hört av sig och berättar att deras verksamheter ser över hur de kan minska riskerna som beroendet av utländska leverantörer skapar oavsett om de har backdörrar eller inte. Det där är en spännande och svår utmaning att reda ut. Jag har gått och funderat i flera år på att göra "en grej" kring helsvenska produkter med anknytning till OT-världen. Om du representerar en tydligt svensk producent så får du gärna höra av dig och bolla lite tankar kring det här... Reaktioner på förra nyhetsbrevet Efter förra nyhetsbrevet så handlade de flesta kommentarer och frågor om min text kring utdelade "böter" kopplat till det nuvarande NIS-direktivet. Jag är fortfarande förvånad över varför de tillsynsmyndigheter som utdelar sanktionsavgifter gör det så diskret och då också missar en chans att "motivera" andra organisationer i samma bransch? Mina två låtar väckte också en del uppmärksamhet, så för att underlätta för dig som vill spela dem i olika sammanhang så finns de nu på Spotify ! Det känns som den poppiga NIS2 har bäst chanser att bli en hit även om jag personligen gillar den något hårdare " OT-säkerhet dot se " bättre... Nu finns jag i en podd-spelare nära dig! Jag och Johan Guste gästade ett avsnitt av podden "Cyber Chats & Chill" som den fantastiska duon Margarita Sallinen och Linda Nieminen driver. Det blev ett kul samtal om högt och lågt inom OT-säkerhet - allt från Stuxnet till relationsrådgivning. Jag tycker verkligen Margarita och Linda lyckas väldigt väl med det som de satsat på - att föra ut insikter om vad cybersäkerhets-arbete innebär brett till en publik som annars inte har chansen att förstå vad vi egentligen sysslar med i den här branschen. Du hittar vårt avsnitt tillsammans med alla deras andra fantastiska episoder. Sprid det väldigt gärna till kollegor, familj och vänner som behöver höra varför OT-säkerhet är roligt och viktigt att arbeta med. Återkoppla gärna dina tankar om vad vi pratade om! Missade vi något viktigt? Hade vi fel? EU talar ur skägget! EUs cybersäkerhetsmyndighet ENISA har publicerat sin första NIS360-rapport där man bedömer hur mogna och hur kritiska olika sektorer i samhället är. Alltsammans synas förstås ur ett NIS2-perspektiv. De har fokuserat på ”Väsentliga” verksamheter, den högre graden i direktivet. Det är lite synd att man inte tog med ”Viktiga” verksamheter också, men det kanske kommer i framtida versioner. Ingen blir nog förvånad över att El, Telekom och Bank pekas ut som de mognaste även om jag av personlig erfarenhet nog måste säga att just El är "spretig" - det är långt mellan de mest amatörmässiga och de duktigaste! Generellt måste man ju tyvärr konstatera att de flesta OT-dominerade sektorerna ligger på den undre halvan av mognadsskalan och att jag dessutom har precis samma syn på det som ENISA... Den som sticker ut mest i mina ögon (även om jag håller med om bedömningen) är "ICT Service Management", alltså MSP och MSSP - dvs tjänsteföretag inom drift och säkerhetstjänster inom IT och OT. De ligger extremt högt i kriticitet och bara halvvägs upp på mognadsskalan. Problemet med det är ju förstås att de "drar med sig sina kunder i fallet", vilket kan slå hårt och brett mot samhället. Mycket glädjande så talar man numera ur skägget mer kring hur viktigt OT-säkerhet är i det här sammanhanget. NIS2 fokuserar helt på robust produktion av tjänster och produkter som samhället är beroende av, så god OT-säkerhet är helt centralt för de allra flesta områden. Man lyfter dessutom specifikt OT lite extra ibland annat sjöfarten, dricksvatten, fjärrvärme, el, järnväg som är bra exempel på att den fysiska delen av produktionen helt står och faller med god OT-säkerhet. Generellt måste jag säga att deras resultat motsvarar min egen magkänsla för var vi har de stora utmaningarna i samhället. Det är lite lugnande att det syns en tydlig koppling mellan hur kritisk en verksamhet är och hur mogen den är. Nu tittar rapporten på EU som helhet, vissa saker hade jag definitivt ändrat ur ett strikt svenskt perspektiv; exempelvis är fjärrvärme väldigt viktigt för stora delar av landet och jag tycker nog dricksvatten förtjänar att ligga lite högre på viktighets-skalan. Vi vet också erfarenhetsmässigt att det är en väldigt stor spridning i mognaden inom vissa sektorer, personligen skulle jag peka på dricksvatten, fjärrvärme och fartyg som viktiga exempel på det. Skit händer! Den alltid kloke Sinclair Koelemij skrev ett inlägg på LinkedIn nyligen som satte ord på en diskussion som jag haft ganska ofta på sistone. Den där insikten om att vi inte kan satsa alla våra resurser på att förebygga dåliga saker. Skiten kommer träffa fläkten i alla fall och om vi då blir det jobbigt och vi inte förberett oss på att upptäcka händelsen snabbt, kunna hantera situationen och återgå till rimlig produktion inom rimlig tid. För den som gillar NIST CSF så handlar det ju förstås om att inte lägga alla sina ägg i korgen "Protect" utan att ha några kvar för "Detect", "Respond" och "Recover". Men Sinclair nöjer sig inte där... Nyligen kom han med en riktigt bra artikel på LinkedIn som tittar på begränsningarna med det populära (och viktiga) begreppet "Secure by design", och hur det kan vara en klurig tankefälla om man har en produktions-process med någon form av Safety-utmaningar. En riktigt viktig text att läsa för många som har sin bakgrund i IT-världen, där den här dimensionen inte existerar. Gruvor har inga cyberrisker! Eller? I en uppmärksammad års-rapport från EY har cybersäkerhet halkat ut från topp-10-listan över risker i gruvindustrin. Det här kan man tycka vad man vill om men det är en bra illustration över att företagsledningar har många typer av risker att hantera och att det inte är säkert (!) att cybersäkerhet (och därmed OT-säkerhet) ska vara högsta prioritet för dem! Samtidigt finns det en poäng i att cybersäkerhet inte hanteras separat eftersom den ofta ingår som en delkomponent i andra, större riskmassor. Skippa projekten! I en artikel beskriver Allan Kelly hur Madrid lyckades bygga ut sin tunnelbana utan att det blev jättedyrt. Poängen verkar, enkelt uttryckt, att man bedrev arbetet i den ordinarie organisationen och på så sätt optimerade för fokus på resultat och undvek baksidorna med projekt. Min tanke gick direkt till ett antal välkända IT-projekt som valsat runt i media på sistone efter att ha kört i diket. Tankarna gick också åt att vi kanske kan tänka likadant kring en del implementationsprojekt för OT-säkerhet så att inte projektet hamnar vid sidan av verksamheten? Kommer du ihåg Y2k? Ja, det var många som var nervösa inför årsskiftet mellan 1999 och 2000 trots att otroligt många system uppdaterats för att klara datum-omställningen. Efteråt har jag förstått att många uppfattade det hela som något av ett antiklimax eftersom så lite gick snett. Det är förstås en rimlig reaktion om man inte haft insyn i den enorma mängd system som åtgärdades och som annars hade fått problem om man inte hanterat situationen i tid. Nu är det snart dags igen... Den 19:e januari 2038 närmare bestämt! Då kommer alla system som använder 32-bitars tid på Unix-manér. Det kan tyckas vara lång tid kvar men i synnerhet i OT-världen så är ju lång livslängd på utrustningen ett viktigt krav. Utrustning som vi installerar idag kan mycket väl vara i drift 2038... Och det är väldigt mycket utrustning som berörs. Wikipedia-sidan om detta förklarar bakgrunden bra. Mer batterier! I förra nyhetsbrevet skrev jag en del om säkerhet i batterisystem. Jag följer upp med ett riktigt intressant papper kring modellering och simulering av cyberattacker mot just batterisystem. Det är skrivet av Frans Öhrström, Joakim Oscarsson, Zeeshan Afzal, János Dani och Mikael Asplund. Det är extra roligt med tanke på att Frans, Joakim och János alla är kollegor till mig på Sectra. De har tittat på hur olika typer av kreativ manipulation av dessa system kan ställa till oreda för elnätet. Aktuellt och intressant ämne! Vad är proportionerligt? Jag hade nyligen en intressant diskussion om kopplingen mellan CCE ("Consequence-driven, Cyber-informed Engineering") och NIS2-direktivet, speciellt ur perspektivet om det finns några fällor med att se CCE som en del av åtgärderna för att möta NIS2? En av mina favoritdelar i NIS2 är att man trycker så hårt på att man ska basera säkerhetsåtgärder på riskbedömningar utifrån både hur den egna verksamheten kan drabbas av någon form av störning, men också hur samhället kan drabbas indirekt om den egna verksamheten drabbas av störningar. Eftersom bedömningarna ska vara utifrån de egna unika förutsättningarna så är det svårt att säga något generellt som gäller alla. Men något som jag tycker många stirrar sig blinda på i sina riskanalyser är störningar i produktionen, alltså situationer där "produktionen kommer igång igen när cyberincidenten är löst". Det man lätt missar är de riktigt allvarliga händelserna som kan skapas i vissa verksamheter om man som angripare verkligen "går in för det". Jag tänker exempelvis på: Sönderkörd utrustning. Stora generatorer, motorer eller transformatorer kan ha leveranstider på flera år om de behöver ersättas. Explosioner, brand, utsläpp och annat som tar människoliv ögonblickligen. Miljöpåverkan genom giftiga utsläpp som får stor miljöpåverkan. Det som dessa exempel har gemensamt är att konsekvenserna i sig inte är "cyber. I inget av exemplen har man tagit en backup som man kan läsa tillbaka transformatorn, kollegan Bengt eller abborrarna ifrån... Det är ju precis här som CCE har sitt fokus. Att säkerställa att den fysiska processen är utformad på ett sätt som gör att den skyddar sig själv, i bästa fall utan att skyddet innehåller något "Cyber" som går att påverka av en illasinnad angripare. För mig är det ett uppenbart sätt att bygga bort de där konsekvenserna som får de allra mest långdragna konsekvenserna, vilket rimligen är viktigt för samhället om man omfattas av NIS2. Det som ska blir intressant att se är hur den här typen av resonemang hanteras av tillsynsmyndigheterna när de skriver sina sektorspecifika föreskrifter och hur de följer upp åtgärderna under tillsyn. Jag hoppas att det här landar väl, så att vi kan använda det här kraftfulla verktyget på bästa sätt. Det dröjer nog ett tag till... Om du inte riktigt hänger med i svängarna så kan du ha missat det senaste kring när vi kan förvänta oss svensk lagstiftning kopplat till NIS2-direktivet? Som jag skrev i nyhetsbrev #65 så har EU besviket konstaterat att Sverige och en massa andra länder helt missat den deadline för NIS2 som gick ut i oktober. Ett brev skickades ut till alla eftersläntrare för att förstå vad som händer och varför. Nu har vi sett Sveriges officiella svar och där säger man helt enkelt att arbetet med lagstiftningen och den nationella cybersäkerhetsstrategin pågår. Strategin har vi precis fått, men lagstiftningen är tänkt att beslutas under våren med skitet på en implementation framåt årsskiftet 2025/2026. ECSO har för övrigt en tracker som enligt uppgift uppdateras månadsvis där man kan se hur implementeringen av NIS2 kryper framåt: Ny strategi för ENISA EUs cybersäkerhetsmyndighet ENISA har firat 20-årsjubileum och har då tagit fram en ny strategi och plan för arbetet fram till 2027 . Väl värda att läsa. Om du inte orkar ta dig igenom den ganska mastiga planen så bad jag Googles mäktiga AI-hjärna ta fram en avslappnad summering, det kanske blev lite väl relaxat? Hallå där! Tjohej från ENISA:s värld! 🎉 Nu rullar vi in i 2025-2027 med ett sprillans nytt treårigt programdokument! Det är fullproppat med spännande saker för att göra EU ännu säkrare online. Vi snackar inte bara om att hänga med i svängen, utan om att ta ledningen när det gäller cybersäkerhet! En stor grej är att vi nu verkligen dyker ner i nya EU-direktiv som NIS2, Cyber Resilience Act (CRA), och Cyber Solidarity Act (CSoA) – det kommer att bli mycket att göra! Vi satsar stenhårt på att boosta allas cybersäkerhetskunskaper genom initiativ som Cybersecurity Skills Academy – heja kompetens! Ett annat hett ämne är att stärka vårt samarbete och vår gemensamma lägesbild så att vi kan agera snabbt om något händer. Och hör på detta – vi jobbar på en EU-gemensam cybersäkerhetsreserv för att kunna rycka in vid kriser. Dessutom bygger vi coola verktyg som en CRA-rapportplattform och en EU-databas för sårbarheter. Vi på ENISA tittar också inåt och vill bli en ännu bättre arbetsplats med fokus på hållbarhet och grym service. Kort sagt, det är full fart framåt för ett ännu tryggare digitalt Europa! Vem är Mats? Jag är till vardags konsult och säkerhetsrådgivare kring OT på Sectra. 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 .

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du musikaliska versioner av OT-säkerhet och NIS2! Jag berättar också hur mycket böter som delats ut kopplat till nuvarande NIS-direktivet, avslöjar hur man blir riktigt efterklok, serverar några riktigt jobbiga sanningar, tittar närmare på batteri-system, söker en kollega, funderar på hur vi reagerar på hybridhot, tittar på ett par årsrapporter och säger tack till både Livsmedelsverket och MSB. 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å Bluesky , 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 OT-säkerhet.se som musik i dina öron? För den som är musikaliskt intresserad finns nu nyhetsbrevets första egna låt med den uppkäftiga titeln "Purdue is not security!" . Valet av genre föll på industri-metall förstås, som sig bör... Tankar på den? Sjung med! ot-säkerhet.se come follow me, don't even have to pay a fee. Purdue was never a security plan, do your zoning properly man! The time for point to point is gone, now Unified Namespace has won. Now let's make OT secure again, or all our work has been in vain... Är det så att du kanske föredrar ett lite mer poppigt sound? Kanske tänker du mycket på NIS2? Då har jag ett alternativ bara för dig: Okej... Jag inser att jag inte ska satsa på en musik-karriär... Men det är inte omöjligt att det kommer något mer i framtiden om det uppskattas? Hur många röda kort har delats ut? Jag insåg nyligen att jag inte hade koll på hur mycket "böter" som drabbat svenska organisationer för att de inte skött sig enligt NIS-direktivet. Att vissa av tillsynsmyndigheterna varit aktiva med tillsyning och delat ut en hel del anmärkningar är välkänt. Men hur mycket smisk har egentligen delats ut för sådana förseelser? Och varför är det så tyst om att detta faktiskt sker? För att förstå detta bättre har jag på sista tiden lekt undersökande journalist och begärt ut den här informationen från de aktuella myndigheterna (Post- och Telestyrelsen, Energimyndigheten, Transportstyrelsen, Livsmedelsverket, Inspektionen för vård och omsorg och Finansinspektionen). Det jag ville veta var vilka sanktionsavgifter de beslutat om, vilka organisationer som berörts och vilka regelbrott de straffats för. Resultatet visade sig mycket intressantare än jag hade trott och dessutom på fler sätt än väntat... Generellt sett ser svaren från de olika myndigheterna väldigt olika ut, vissa har delat ut förvånansvärt många böteslappar, medan andra inte har gjort det alls. I vissa fall är det rejäla belopp vi pratar om och i andra ett större antal småbelopp. Vissa skillnader kan ju förstås bero på skillnader mellan branscher och i vilken takt de olika myndigheterna tagit fram sina föreskrifter, men ändå... En väldigt tydlig skillnad mellan de olika myndigheterna är hur de hanterar information om vilka organisationer som "berörs". I ett par fall vägrar man lämna ut namnen på organisationerna eftersom man har belagt den informationen med sekretess enligt Offentlighets- och Sekretesslagen. Samtidigt berättade andra myndigheter gladeligen exakt vilka verksamheter som hade anmält sig som berörda av NIS. (För den som är nyfiken på detaljer kring sekretessen så refererar man till OSL 18 kap 8 § vilket också prövats i rättsfall, exempelvis Kammarrätten i Jönköping mål nr 3039-20 .) Det jag egentligen var ute efter i första hand var ju att förstå hur det stod till med just sanktionsavgifterna. Även här visade det sig vara stor skillnad mellan sektorer och mellan myndigheter. Det absolut vanligaste är att organisationen missat eller varit sen med att anmäla sig, det "kostar" alltid 5 000 kronor hos en av myndigheterna, medan de andra myndigheterna drar till med mellan 15 000 och 90 000 kronor. En annan vanlig förseelse är brister i hur man hanterat en inträffad säkerhets-incident och där ligger beloppen i spannet mellan 70 000 och 200 000 kronor. Riktigt dyrt blir det om man får allvarliga anmärkningar under en tillsyn av verksamhetens säkerhetsarbete, där startar fakturan på en dryg miljon och det högsta beloppet jag hittat är nästan 4 miljoner. I ett fall, som jag känner till sedan tidigare, var förhållandet mellan storleken på beloppet (1,5 miljon) och storleken på organisationen riktigt tuff! Tro alltså inte att myndigheterna håller igen med piskan bara för att du är liten eller har svagare ekonomi! Brister i anmälan Incidenthantering Tillsyn Totalt antal 78 4 17 Maxbelopp 90 000 200 000 3 750 000 Snittbelopp 24 000 115 000 1 155 000 Allt detta handlar alltså om regler som direkt eller indirekt kopplar till det första NIS-direktivet. Jag ser ingen anledning att tro att våra tillsynsmyndigheter kommer hålla igen mer när NIS2 implementerats. Tvärtom! Då finns fler och tyngre straff att ta till! Nu är ju inte viljan att undgå straff den bästa drivkraften för säkerhetsarbete, men nog skulle det kännas bättre att lägga de där 4 miljonerna på säkerhetsåtgärder istället för att betala dem till en myndighet? Det som förvånar mig mest med allt detta är att man från myndigheternas sida inte tar chansen att berätta för alla andra berörda verksamheter hur det kan gå om man inte sköter sig. Även om man hemlighåller namnet på organisationen så är det ju en missad chans att "motivera" andra att skärpa till sig ännu mer! Men där kanske det blir skillnad med NIS2 eftersom man kan tvingas att själv berätta för hela världen varför man fått en "sanktionsavgift". En riktig skampåle-paragraf alltså! Helt uppenbart är det viktigt att hantera NIS2-kraven ordentligt framöver. Några generella insikter kan man dra kring hur man minimerar risken för att få spö: Se till att ta analysen av om ni omfattas på allvar. Även om ni inte tror ni omfattas så tycker jag det är en väldigt bra idé att ändå göra en enkel men formell analys. Glöm inte att låta högsta ledningen fatta beslut om vägvalet, oavsett om det blir att ni omfattas eller inte! Om ni omfattas av reglerna så glöm inte att göra en formell anmälan! Lätt gjort att man glömmer den lilla detaljen... Siktar ni på att uppfylla NIS2 så är min bedömning att man inte ska försöka hitta något facit, för det kommer det ändå inte att finnas. Säkerställ att ni jobbar systematiskt med att identifiera och hantera risker med fokus på er egen produktion. Glöm inte att NIS2 handlar om att bygga en "cyber-robust" produktion, vilket kan innebära att andra delar av verksamheten inte behöver lika mycket säkerhetsfokus! Var inställda på att ni aldrig kan förebygga risken för incidenter helt. Ni måste vara beredda på att hantera att tråkiga saker faktiskt händer. Läs även artikeln nedan om att bli efterklok, det är otroligt viktigt att kunna förklara vad som hände efteråt! Konsten att bli riktigt efterklok! Om du följer något slags nyhetsflöde inom cybersäkerhet har du garanterat inte missat den enorma läckan av konfigurationsdata som drabbat en stor grupp användare av Fortinet-prylar. Som vanligt har den fått ett putslustigt namn: FortiGate-skandalen... En artikel på samma tema påpekade klokt att, även om man varit snabb på att installera säkerhetsrättningar, så behöver man dessutom dubbelkolla att inte det elaka typerna ändå hann utnyttja sårbarheterna innan du hann rätta dem. (För då hjälper det inte att patcha!) Just det här tycker jag är en poäng som lätt tappas bort! För det är en viktig poäng! Och en riktigt svår poäng att göra något åt i verkligheten! Eftersom jag arbetar på ett företag som erbjuder en framstående OT-SOC , alltså säkerhetsövervakning fokuserad på OT-drivna verksamheter, så hamnar jag ofta i samtal om nyttan med övervakning. Den primära nyttan med en SOC är förstås att någon snabbt upptäcker en angripare och att man därför tidigt kan få stopp på angreppet, innan det lett till jobbiga konsekvenser. Jag märker dock att många organisationer missar att diskutera en annan nytta, som är nästan lika viktig. Förmågan att efter en attack kunna titta i backspegeln och avgöra vad som egentligen hände! Och detta oavsett om man lyckades stoppa angreppet tidigt eller om det dessutom hann börja leda till tråkiga konsekvenser. Det värsta som finns när man städat upp efter ett angrepp är att inte veta vad som egentligen hände! Hur kom de in? Vad ställde de till med egentligen? Har vi lyckats åtgärda allting? Kan de ställa till samma oreda igen imorgon? Kan vi lära oss något till nästa gång? Det här får ytterligare en dimension för de organisationer som omfattas av någon av alla nya och gamla lagstiftningar kring cybersäkerhet. Ta NIS2 som exempel, där en av de viktigaste kraven är att man i efterhand ska kunna redogöra i detalj för vad som hände. NIS2 förbjuder inte säkerhetsincidenter, men man kan råka riktigt illa ut om man har så dålig koll på läget att man inte kan analysera vad som gick snett! Är det dessutom så att din verksamhet omfattas av svenskt säkerhetsskydd så behöver du eventuellt kunna spara all den informationen länge (10 eller 25 år), så att motsvarande analys kan ske om man inser långt senare att man drabbats av en säkerhetsincident. Så fundera noga över vilken information du behöver samla in för att kunna göra en bra analys och vilka förmågor som behövs för att kunna tolka informationen. Du behöver se till att insamlingen startats i god tid innan incidenten, för när incidenten inträffat är det redan för sent... För att kunna bli efterklok i framtiden så behöver du vara klok idag... Vill du bli ytterligare lite klokare så kommer MSB anordna ett webbinarium den 28:e mars kring ämnet säkerhetsövervakning. Gratis och förmodligen fyllt av klokheter: Varför en stark Security Operations Center (SOC)-förmåga är avgörande för att stärka samhällets motståndskraft Hur monitorerings- och realtidsövervakning bidrar till att skydda kritiska system och tjänster Praktiska steg för att bygga eller förbättra SOC-förmåga för offentlig sektor Brittiska risker! Storbritannien publicerade nyligen den officiella/publika versionen av deras riskbedömning "National Security Risk Assessment", (NSRA) i form av en riskförteckning, " National Risk Register " (NRR). Som vanligt i den här typen av dokument från britterna så är det genomarbetat och bra. En hel del användbart för oss OT-människor i olika sammanhang men fungerar även som en utmärkt sammanfattning av hotläget i "Cybervärlden". Jobbiga sanningar... Chris Hughes skriver under rubriken " Cybersecurity's Delusion Problem " om en utmaning som jag verkligen håller med om. Det här att vi "säkerhetsmänniskor" gärna blir fanatiska och en-frågefokuserade i vår iver att göra allting säkert. Jag har ofta stött på motstånd när jag påpekar att vi behöver stötta ledningen i organisationerna att kunna jämföra risker mellan olika områden - för det finns faktiskt värre saker i livet än cyberrisker! Jag tycker det blir väldigt tydligt när man ställer frågan "Hur mycket risk är lagom?" till olika personer. En typisk cybersäkerhetsmänniska kommer nästan garanterat svara något i still med att "Mindre risk är alltid bättre!". Ställer du samma fråga till en styrelsemedlem kan du räkna med ett svar i linje med "Så mycket som möjligt. Men inte för mycket!". Tricket med risk är inte att undvika dem. Det viktiga är att ha koll på dem så man kan göra kloka och informerade val. Att ta risker är att skapa fördelar och möjligheter men gör man det blint och på magkänsla så kommer man snabbt hamna i diket. Det här är för övrigt en av sakerna jag brukar lyfta som en fördel med att styrelsen pekas ut så hårt i NIS2. Kloka styrelser kommer kräva att organisationen kan visa en samlad bild av riskbelastningen och därmed måste vi kunna jämföra risker från helt olika områden. "Ska vi byta ut de gamla PLC:erna i produktionen eller är det faktiskt viktigare att renovera fabrikstaket?" Dragos ger oss sin syn på världen! Dragos har släppt sin "8th annual year in review, 2025 OT/ICS Cybersecurity Report" som är väl värd att läsa. Jag ska dessutom ge dem extra beröm för att de, i motsats till alla andra i OT-säkerhetsbranschen, inte tvingar oss att ge bort vår mejladress till dem för att få läsa rapporten! Bra! Det är en ganska omfattande (56 sidor) genomgång av hur Dragos uppfattar hotlandskapet och hur det går för "försvararna" i deras utveckling mot mer mognad och effektivare säkerhetsarbete. Hacktivisterna har varit ganska aktiva under senare tid vilket får mycket uppmärksamhet i rapporten. Naturligtvis också en hel del kring trenderna runt ransomware men också den spännande rubriken "Legacy malware" där man diskuterar att gammal skadlig kod, som exempelvis WannaCry, fortfarande "gömmer sig" i existerande system. I kapitlet "Vulnerabilities" pekar de på den intressanta utmaningen att förstå fältbusstrafik när protokoll körs "ovanpå varandra" i flera lager. De nämner exempelvis EtherCAT som Omron kör över NXBus-protokollet och bakar in alltihop i http-förfrågningar! Jag har varit på CCE-kurs! Jag hade nyligen förmånen att få gå en utbildning i CCE-metoden , "Consequence-driven, Cyber-informed Engineering". Det är Idaho National Labs, INL , organisationen som utvecklade metoden som också kör dessa påkostade intensiv-utbildningar kallade " ACCELERATE ". Jag kan verkligen rekommendera dessa kurser, som dessutom är gratis. Å andra sidan genomförs de bara i USA, så resan tillkommer förstås... Om du läst mina nyhetsbrev tidigare så vet du att jag propagerat för den här metoden tidigare. Det finns en bok utgiven som jag recenserade i nyhetsbrev #26 men du kommer långt även med ett av INLs whitepapers . I grunden handlar det om att identifiera de allra värsta händelser som kan drabba en producerande verksamhet, alltså inte bara de som är väldigt jobbiga, utan händelser som kan: få organisationen att gå under orsaka enorma skador eller förlust av människoliv få allvarlig påverkan på samhället Det som gör metoden så intressant är att man identifierar katastrofala händelser som kan utlösas via digitala angrepp, men man försöker inte lösa problemet med "cyber-åtgärder". Istället siktar man på att hindra en angripare genom att fysiskt ändra i processen så att konsekvensen blir fysiskt omöjlig. Mitt favoritexempel för att illustrera tänket är lite fånigt: "Om det är farligt att köra en pump baklänges så kan en backventil vara ett effektivare skydd än att sätta motorstyrningen bakom en brandvägg". En annan aspekt som gör metoden så intressant är att den verkligen gör precis de svåra antaganden som vi säkerhetsmänniskor alltid säger att man ska göra, exempelvis "assume breach" - alltså att angriparen redan är i våra system och därmed spelar det mindre roll hur de tog sig dit! Man förutsätter också att angriparen vet mer om systemen och tekniken i dem än vad vi själva vet. Tuffa antaganden, men viktiga på den här nivån! Jag ska inte upprepa allt fantastiskt med metoden, där hänvisar jag till min tidigare text i nyhetsbrev #26 , men några nya reflektioner vill jag ändå göra: Det här är en makalös metod för att identifiera och åtgärda de absolut värsta händelser som kan drabba organisationer. En av styrkorna är att man tvingas tänka långt utanför boxen och där kanske hittar risker som ingen tidigare "vågat" tänka på. Metoden passar väldigt väl för verksamheter som lyder under säkerhetsskyddslagen. Både CCE och säkerhetsskydd tar ingen hänsyn till sannolikheter, det handlar bara om att se till att allvarliga händelser inte KAN hända. Klockren kombination! Även kopplat till NIS2 passar CCE bra om man tar fasta på att direktivet trycker hårt på att allt säkerhetsarbete ska vara risk-drivet och att åtgärderna ska vara proportionella. CCE kan möjligen vara lite förvirrande om man jobbar strikt enligt IEC 62443-3-3, men även den är ju i grunden risk-driven så om man bara gör riskanalyser med tungan rätt i munnen så fungerar det utmärkt! En potentiell utmaning med att använda CCE för att uppfylla NIS2, Säkerhetsskydd eller något annat regulatoriskt krav skulle kunna vara att tillsynsmyndigheterna ibland blir alldeles för detaljerade i sina krav. Om det i mitt exempel ovan finns ett uttryckligt krav på att skydda alla farliga pumpar med en brandvägg så kanske inte en backventil accepteras som ett bättre alternativ. Låt oss hoppas att myndigheterna respekterar den risk-drivna approachen i exempelvis NIS2! Metoden kan uppfattas som tung, vilket den också är om man tar sig an en komplex produktionsprocess. Som motvikt till det kan den med fördel genomföras "iterativt" så att man bara fokuserar på den absolut värsta konsekvensen först och sedan repeterar i den takt man orkar med. Det pågår ett intressant arbete på Luleå Tekniska Högskola där Ebba Linnea Nilsson och Hampus Ettehag tittar på hur man bäst kan anpassa metoden till de förmågor som en mindre organisation har. Det ska bli spännande att se vad de landar i. Det finns gott om delar i metoden som kan vara inspiration för att förbättra konventionella metoder för riskbedömningar. Många organisationer jag jobbar med har inte tidigare tänkt igenom hur de genomför riskanalyser eller vilket värde de egentligen kan ge. Om inte annat så tvingar CCE-tänket organisationer att få "IT-folk" och "process-folk" att prata med varandra! Hör gärna av dig om du är nyfiken på att prova det här i din verksamhet! mats@ot-sakerhet.se Batterier? Användningen av batteri-teknik i vårt elnät ökar. I takt med att de blir allt viktigare blir säkerheten i dem allt mer kritisk. En radda intressanta rapporter INL (Idaho National Labs) är väldigt intressanta i sammanhanget och innehåller dessutom en del referenser till arbete utfört enligt CCE-metoden . INLs sida för batterier och energilagring Rapporten " Battery Energy Storage Systems Report " från US DoE White paper " Application of Cyber-informed Engineering för protecting BESS " Guide: " Securing Digital Energy Infrastructure: Procurement, Contracting, and Supply Chain Risk Management Guidance " Till det ska vi verkligen inte glömma den (som vanligt) välskrivna artikeln "BESS Cyber physical risk" av Sinclair Koelemij. Bli min kollega! Jag behöver en rådgivarkollega! ...eller två! ...eller tre! Nu bygger vi på Sectra vidare på Sveriges starkaste OT-SOC med bred kompetens och fler tjänster kring OT-säkerhet! Vi söker i hela Sverige ! Hybrida hot och knattefotboll Jag vill slå ett slag för Anton Lifs texter , han kommer ständigt med kloka insikter om den kluriga värld som vi verkar i. I senaste utgåvan reagerade jag lite extra på en mening i ett stycke som egentligen handlar om att hybrida hot inte ska ses som snällare. Meningen han skrev är: Men när det väl är sensationella angrepp (ex. Nordstream) så fastnar vi alla i fällan, och allt fokus riktas mot ett och samma håll. Det där är något jag tänkt på också, både kring världshändelser som kabelsabotage i Östersjön, men även i mindre skala, exempelvis inom OT-säkerhetsbranschen. Det är väldigt lätt att fastna i de frågor som fått rubriker på sista tiden! Ibland känns det som att vi är spelare i ett knattefotbollslag - ni vet där alla spelare springer efter bollen istället för att fundera på var på planen man själv kan göra bäst nytta utifrån sina egna förutsättningar... För en säkerhetsperson handlar det nog mest om att våga tänka fritt när man gör sina riskanalyser och funderar över vilka åtgärder som får bäst effekt. Ska vi satsa stenhårt på försvar genom att bara förebygga att motståndaren gör mål eller ska vi även höja blicken, förstå spelet och leta efter nya möjligheter framåt? Reaktioner på förra nyhetsbrevet Det stora intresset kring Clavisters OT-satsning och deras nya NetWall 200R gick inte att missa! Kul att de får erkännande för det de gör. Jag kommer följa deras fortsatta utveckling på OT-sidan med stort intresse, men måste ärligt säga att de redan nu är ett riktigt starkt kort i kampen mellan OT-brandväggar! Den svenska flaggan på prylarna gör definitivt inte saken sämre... Den senaste versionen av mjukvaran sägs komma att lanseras inom ett par veckor, men jag har förstått att det redan nu är fritt fram att diskutera offerter eller ordna en provkörning! Det kommer alltid ett gäng kloka kommentarer på det LinkedIn-inlägg där nya nyhetsbrev annonseras, så även den här gången. Mest genialisk var nog Lina Bengtsson som utökade min liknelse mellan bilbälten och cybersäkerhet med att regelbunden besiktning har ett stort värde. Så är det ju verkligen! Realtid! Begreppet realtid är inte alltid så lätt att förstå för nybörjare i branschen. I en uppföljare till artikeln om skillnaderna mellan SCADA och DCS som jag nämnde i förra nyhetsbrevet så skriver nu Sinclair Koelemij om "riktig" process-styrning och hur en angripare skulle kunna störa dessa systems cykeltider för att på så sätt påverka den fysiska processen. Som alltid, välskrivet och läsvärt när det kommer från Sinclair! Samtidigt kommer skrytvideos från Siemens och Audi om hur de virtualiserat PLC:er och placerat dem i en datorhall 8 kilometer bort. Naturligtvis en helt annan typ av verksamhet och helt andra krav, men ändå en tydlig påminnelse att utvecklingen av tekniken och metoderna ständigt utvecklas! Obligatorisk läsning! Sarah gör det igen! Namnet Sarah Fluchs har dykt upp ett antal gånger tidigare i nyhetsbrevet, senast i nyhetsbrev #64 där jag pekade på hennes avhandling. Nu har hon släppt ett gratisverktyg för att göra "Cyber Decision Diagrams". Verktyget bygger på det kommersiella verktyget “Security Engineering Tool” (SET) som Sarah också ligger bakom. Du hittar e n av hennes texter här som förklarar mycket av tänket. Utforska gärna det här arbetssättet och hör av dig med dina reflektioner! mats@ot-sakerhet.se Det här är ett intressant utvecklingsområde! Tack Livsmedelsverket! Livsmedelsverket har släppt en uppdaterad version av " Handbok i krisberedskap och civilt försvar för dricksvatten ". Viktigt material i största allmänhet om man är i vattenbranschen. Extra kul tycker jag personligen bilaga 2 är som innehåller en stor samling scenarier för övningar - viktigt att göra ofta! När det gäller säkerhetsfrågor så pratas det tyvärr nästan bara om skydd av information och nästan ingenting om skydd av process-systemen, vilket ju känns lite märkligt? Men i övrigt ett riktigt bra dokument! Tack MSB! Ett annat bra dokument som tyvärr pratar ännu mindre om OT-säkerhet är MSBs " Resultatredovisning av Cybersäkerhetskollen 2024 ". Det är trots detta ett bra dokument, men som pekar på väldigt dåliga saker inom samhällsviktig verksamhet - den generella säkerhetsnivån är helt enkelt bedrövlig... Det skulle vara väldigt intressant att komplettera "Cybersäkerhetskollen" som ju bygger på "Infosäkkollen" och "IT-säkkollen" med "OT-säkkollen". Den skulle i så fall rimligen behöva omfatta ungefär samma områden som både "Infosäkkollen" och "IT-säkkollen", men då med fokus på fysisk produktion. Ett vanligt missförstånd är att IT-säkerhet och OT-säkerhet är varandras motsvarigheter eftersom de har så lika namn. Men det är min erfarenhet att OT sällan finns med på radarn när organisationer pratar om "Analys av informationssäkerhetsrisker", "Kontinuitetshantering" eller "Ledningens styrning"... Så i praktiken behöver OT-säkerhet driva samma frågor som både informationssäkerhet och IT-säkerhet gör. Minimera mera! I en artikel av Marco Felsberger sätter han fingret på två av mina allra käraste käpphästar för hur vi skapar robusta verksamheter och system: Minimera systemen, "Minimum viable systems" Begränsa skadeverkningarna, "Bounded impact" Det är en gammal sanning att komplexitet och säkerhet är varandras fiender. Det betyder både att vi behöver skala av det som är överflödigt ("Härdning") men också att vi ska kunna falla tillbaka till minimalt systemstöd och ändå leverera. Den andra delen av resonemanget är att vi kan begränsa skadorna vid haverier/attacker och på så sätt öka tåligheten i verksamheten. Begreppet "Limiting the blast radius" är ganska talande sammanhanget. Marco avslutar med en radda citat-värda tankar, där " resilience is about survival, not perfection " är min favorit. Det är lite samma grundtanke som i CCE (se ovan ), att vårt fokus behöver vara på de händelser som helt kan utplåna vår organisation och verksamhet. När vi har koll där så kan vi börja med finliret... Får jag svära lite i kyrkan? Det är fortfarande en del "OT-folk" som inte vill ta ordet "Molnet" i sin mun. Var eventuella kopplingar till något slags moln passar eller inte passar är extremt situationsberoende, men jag tror de flesta av oss sedan länge insett att världen inte är så svart-vit att man bara kan avfärda ett teknikområde helt. Håkon Olsen har skrivit en väldigt bra artikel som säkert kan hjälpa till att desarmera frågan om det fortfarande behövs. Om inte annat så är den också fylld med en rad goda idéer! Din egen eller någon annans kryptering? Det har varit en hel del rubriker på sistone kring infiltration av teleoperatörer av en hackergrupp som precis som vanligt fått en massa fåniga namn: "Salt Typhoon", "RedMike", "Ghost Emperor" och "Famous Sparrow". Innan dess var det gruppen " Volt Typhoon " som angrep kritisk infrastruktur med hjälp av routrar och brandväggar som de tagit över. Det här med att nätverksutrustning tas över är ju ett riktigt jobbigt hot att hantera. Som angripare går det att ställa till riktigt tråkiga saker, i synnerhet när det handlar om nätverkstrafik som var tänkt att bara åka runt i "interna nätverk"... Det påminner mig om en diskussion som jag hamnar i emellanåt. Det handlar om hur mycket vi egentligen kan lita på teleoperatörer och andra leverantörer av nätverk? Inte för att de är onda - tvärtom, utan för att de har alldeles för komplexa lösningar för att kunna hålla elaka angripare ute från sina nät. Konsekvensen för mig är att man ska akta sig för att se leverantörernas nät som en säkerhetslösning. Att de är duktiga på att få fram vår trafik är det inget tvivel om, men mitt förtroende för att trafiken är väl skyddad mot insyn eller ändring är ganska låg. Mitt råd brukar helt enkelt vara att alltid själv ha rådighet över skyddet av känslig trafik, oftast genom att använda något slags krypterade tunnlar i näten. Och, Ja, jag menar även mobiltrafik med privata APN eller leverantörer som erbjuder olika former av krypterade tunnlar inne i sina nät. Och, Ja, jag inser att det inte är självklart att vi klarar att skydda våra egna nätverksprylar så fantastiskt mycket bättre. Och, Ja, jag inser att många tycker jag har fel eftersom det inte finns några bevis... Men det är i alla fall något som man borde ta ett medvetet beslut om! Jag skulle förresten gärna se att vi börjar ge dessa kriminella grupper lite mindre glamorösa namn, som det är nu låter de onödigt coola! Jag förslår att vi byter ut namnet på den här gruppen från "Salt Typhoon" till något mer förolämpande. Vad tror du om "Fluffy Poop", "Farty Pants" eller kanske "Smelly Armpit"? Snart i en podd-spelare nära dig! Jag och Johan Guste gästade ett avsnitt av podden " Cyber Chats & Chill " som fantastiska Margarita Sallinen och Linda Nieminen driver. Det blev ett kul samtal om högt och lågt inom OT-säkerhet - allt från Stuxnet till relationsrådgivning. Avsnittet är inte släppt ännu när detta skrivs, men det finns många andra bra avsnitt så om du inte har lyssnat på dem tidigare så har du tid på dig nu som uppvärmning till vårt! Gartner tycker till om OT-säkerhetsplattformar Gartner släppte nyligen en uppdaterad analys av alla de stora "OT-säkerhetsplattformarna". Även om den här typen av analyser har sina begränsningar så är det i alla fall åtminstone en bra startpunkt för den som vill välja eller byta system. Vem är Mats? Jag är till vardags konsult och säkerhetsrådgivare kring OT på Sectra. 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 .

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången jämför jag boxning med NIS2, du får en närgången titt på en helsvensk OT-brandvägg och en ovanligt listig nätverksswitch men dessutom kan din chef få gå en kurs, vi mäter nyttan med Cyber Informed Engineering, lär oss begreppet Secure by Demand, får lite utmaningar med VLAN, tittar på Irans senaste cybervapen, jämför SCADA med DCS och funderar på om två brandväggar alltid är bättre än en? 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å Bluesky , 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! Varför har du bromsar på bilen? Ibland får jag frågor i stil med: ”Hur långt vågar vi ta vår digitalisering? Det verkar så farligt med alla angrepp man läser om, och säkerhetsprylar är så dyra!” Mitt svar brukar bli en motfråga: ”Varför har du bromsar på bilen?”. Svaret blir gärna något i stil med: ”För att kunna köra sakta?”. Min poäng är förstås att man har bromsar på bilen för att kunna köra riktigt fort! Vi vill komma fram snabbt och effektivt genom att hålla en tillräckligt hög hastighet, men det kräver att vi också kan bromsa och hantera farliga situationer som plötsligt dyker upp. Trots att man har riktigt bra bromsar så kan det förstås gå snett ändå och då behöver vi ett bra katastrofskydd, i form av bälten och krockkuddar. Skulle bilen sakna både bromsar, bälten och krockkuddar så lär vår bilkörning inte bli speciellt effektiv… Det är här EU i sin vishet har givit oss NIS2-direktivet. Det övergripande syftet är att verksamheter som samhället är beroende av ska fortsätta leverera trots att farliga situationer uppstår. Här brukar jag plocka fram nästa liknelse, nämligen boxning! Det finns nämligen en del viktiga likheter mellan NIS2 och boxning… Ett vanligt missförstånd är att NIS2 förbjuder säkerhetsincidenter, att det på något vis är straffbart att drabbas av ett cyberangrepp. Naturligtvis är det att föredra att man duckar ”cybersmockan” när den kommer, men det är hur man hanterar en smäll som räknas. Riktigt dåligt är att ramla ihop och inte snabbt komma upp igen efter en rejäl snyting. Minst lika illa är att efteråt inte kunna förklara vad det var som hände – ”det blev bara svart!”. En tredje ”no-no” är att skylla på någon annan, i boxning kanske dina skor och i NIS2 dina viktiga leverantörer – det är alltid du själv som är ansvarig för det som dina leverantörer ställer till med för dig! Ytterligare en likhet med boxningen är att man måste ha koll på sina egna svagheter, sina sårbarheter. Om man under träning har upptäckt att man åker dit på högerkrokar så får man förstås se till att det inte blir ett problem i skarpt läge! En myt som jag ofta hör kring cybersäkerhet är att det skulle vara mycket enklare att vara angripare än försvarare; ”En angripare behöver bara hitta en sårbarhet men som försvarare behöver du ha koll på alla sårbarheter!”. Som alltid när det handlar om myter finns det ett korn av sanning – de två vanligaste misstagen som jag ser är att man lägger allt krut på förebyggande åtgärder och att man som försvarare inte utnyttjar att man har ”hemmaplan”. Det första misstaget kan jag förklara med hjälp av NIST Cybersecurity Framework, där den här cirkelmodellen finns. Den illustrerar sex typer av säkerhetsåtgärder som jag tycker behöver balanseras för att få ett robust säkerhetsarbete. Enkelt uttryckt så hanterar ”Identify” att vi har koll på vår verksamhet och våra system, ”Protect” att vi förebygger incidenter och ”Detect” att vi kan upptäcka incidenter som inträffar trots vårt förebyggande arbete. I ”Respond” finns vår förmåga att hantera incidenter som vi upptäckt och om vi ändå hamnar i diket använder vi ”Recover” för att få igång verksamheten igen. Alltihop hålls samman av ”Govern” för att styra säkerhetsarbetet. Det misstag som jag ser alldeles för ofta är att man lägger allt sitt krut på ”Protect” och ”Govern”. Det är ett misstag som är förståeligt – man vill undvika problem och man vill visa att man har koll på sitt arbete. Problemet med det är att man inte kan upptäcka incidenter som trots allt inträffar, man kan inte reagera på ett sätt som förhindrar att incidenter orsakar skador och man får väldigt svårt att komma igen vid en större händelse. Här behöver man helt enkelt ha is i magen och flytta lite av sitt fokus bort från Protect för att istället kunna hantera de tråkigheter som för eller senare är oundvikliga. Det andra misstaget är att man inte drar fördel av att man som försvarare är på ”hemmaplan”. En stor del av detta handlar just om att förstärka förmågorna ”Detect” och ”Respond” genom att utforma sin infrastruktur på ett smart sätt. Det talas ibland om ”Defensible architecture”, vilket sätter fingret på vad som är viktigt. Om man gör det här rätt är vinsten enorm! En annan sida av samma mynt är att man ofta väntar alldeles för länge med att öva incidenthantering. Min åsikt är att övningar inte ska ses som en ”examen” där man bevisar att säkerhetsarbetet varit framgångsrikt. Tvärt om faktiskt! Öva är något man gör tidigt och ofta för att snabbt hitta sina största svagheter. Samtidigt hittar man lättare vad som är viktigt för att ”Detect” och ”Respond” ska få bra förutsättningar. En aspekt av NIS2 som ofta får kritik är att direktivet inte ställer några specifika krav på säkerhetsåtgärder. Här har jag en annorlunda åsikt, jag tycker det är precis detta som är det geniala med NIS2! Vi förväntas förstå alla relevanta risker i vår verksamhet och göra något åt dem på ett proportionerligt sätt. Det är just det där proportionerliga som är tricket, det betyder inte bara att stora risker ska få mycket fokus, det betyder också att mindre viktiga delar av verksamheten ska  ha mindre skydd! Vi har alla begränsade resurser och de ska användas där de gör mest nytta! OT-brandvägg på svenskt vis! Som jag hintade om i nyhetsbrev #64 breddar nu svenska brandväggstillverkaren Clavister sitt utbud för OT-nätverk. De gör det genom att lansera ny ruggad hårdvara och samtidigt släppa helt ny funktionalitet med fokus på OT. OT-funktionaliteten är för övrigt tillgänglig även i andra hårdvaror om man inte behöver ruggad utrustning. Den släpps även i mjukvaran för "virtuell brandvägg". När det här nyhetsbrevet skrivs har OT-satsningen formellt sett inte lanserats än, så se det här som en välfylld aptitretare... Efter lanseringen kommer jag uppdatera den här texten med länkar till Clavisters officiella produktbeskrivningar. Clavister är ett spännande företag med ett intressant sortiment, även utanför OT-världen... Jag har märkt att inte alla har full koll på Clavister som företag, så det är kanske bra om jag slår ett slag för denna svenska teknikledare! Bara det faktum att allt ägande och all utveckling finns i Sverige (det mesta i Örnsköldsvik närmare bestämt) är ju något som allt fler organisationer kommer värdera högt framöver, när exempelvis NIS2 ställer krav på att ha koll på sina leverantörer. Om du inte känner till Clavister sedan tidigare så är det alltså inte något nystartat företag, de grundades för över 25 år sedan. De bygger brandväggar, allt från små "bordsbrandväggar" i NetWall 100-serien som klarar 1 Gb/s till extrema brandväggar för teleoperatörer som " Netshield 9000T " som hanterar 800 Gb/s! Det finns även "virtuella" mjukvaru-varianter som mest begränsas av den hårdvara du kör dem på. Förutom traditionella brandväggsfunktioner finns förstås även VPN-tjänster och SD-WAN som dessutom kan kompletteras med smarta Cloud-tjänster. Via varumärket " PhenixID " erbjuder de även lösningar kring identitetshantering, autentisering, signering mm. Möjligen är Clavister mest kända för sina militära brandväggar som går under det coola namnet "Cyber Armour", där bland annat de erbjuder den hårdkokta NetWall RSG-400 . Nu börjar vi prata utrustning som är ruggad på riktigt... Clavisters prylar finns exempelvis i CV90 från BAE Systems, men du hittar dem numera även i militära fartygssystem. Den helt nya OT-brandväggen NetWall 200R är kanske inte så uppseendeväckande till utseendet. I en DIN-monterad ruggad låda med rejäla kylflänsar hittar vi dels 4 st RJ45-portar med stöd för 2.5 Gb/s och dels 2 st SFP-portar för koppar eller fiber. Dubbla anslutningar för 24 VDC håller den med ström. Men det är när vi "tittar under huven" som det blir riktigt intressant... De flesta andra leverantörer av OT-specifika brandväggar verkar fokusera på att bygga minimalistiska produkter som enbart har funktioner som en genomsnittlig OT-miljö behöver. Clavister har valt en helt annan väg... Här hittar vi precis samma funktionalitet som finns i deras stora modeller, men i ett mindre format rent fysiskt. En skillnad mot deras andra produkter är grundkonfigurationen baserad på "transparent" läge. Det innebär att brandväggen direkt kan kopplas in i ett existerande nätverk utan att "störa" för att direkt börja logga vilken trafik den ser och möjliggöra att begränsande regler läggs till efter hand. Jag har ingen chans att gå igenom all nätverksfunktionalitet här, utan kommer fokusera på de som kanske är intressantast för den typiska OT-läsaren. Du kan lugnt utgå från att alla andra "normala" brandväggsfunktioner finns på plats, som exempelvis: Brandväggsregler baserat på adresser, interface, nätverkstjänster, geografisk plats, användargrupper, applikationer, tidsbegränsningar osv VLAN med virtuella interface på brandväggen Transparent filtrering ger möjlighet att införa brandväggsskydd utan att bygga om nätverket helt Möjlighet att bygga virtuella brandväggar med egna routingtabeller Klustring av flera brandväggar för redundans och maximal tillförlitlighet En lång rad olika tekniker för att bygga tunnlar och VPN-tjänster IDS/IPS (Intrångsdetektion), Virusscanning av filer, phishingskydd, DoS-skydd ... och så vidare... För användning i olika typer av OT-sammanhang kanske exempelvis följande är lite extra intressanta finesser: Filtrering och loggning av applikationer, med stöd för en enorm mängd OT-protokoll och systemtyper, här finns alla välkända namn såsom OPC UA, CIP, MODBUS, ifix, S7Comm_plus, IEC61850, IEC104, mbConnect24, Codesys, DeltaV, Fanuc, Melsec, Osisoft PI, Profinet, SAP osv... Clavister lägger hela tiden till mer stöd för att bygga regler baserat på detaljer i de olika protokollen. Du kanske vill begränsa vad som går att slå upp via DNS eller begränsa var version 1 av SMB får användas? Inga problem! Alla tänkbara kombinationer av adressöversättning, "NAT", är tillgängliga för att hantera komplexa situationer med exempelvis överlappande adressområden. Alla säger att de erbjuder AI i dessa dagar, så även Clavister med NetWall 200R. Clavister köpte för ett par år sedan Göteborgsbaserade AI-företaget Omen Technologies , vilket nu börjar synas på ett väldigt intressant sätt i deras brandväggsprodukter. Det som Clavister gjort här är lite utöver det vanliga vi brukar se när någon pratar om AI. Här finns nämligen en inbyggd anomali-detektering som fungerar på allt, inklusive protokoll som brandväggen inte förstår! Och det inkluderar krypterade protokoll som brandväggen inte kan tyda. Samma funktionalitet kommer samtidigt även på andra modeller: NetWall 300/500/6000 samt "virtuella" modeller. Peka ut bara trafik som ska AI-analyseras så görs en automatisk träning på vad som är normalt beteende. Det här är en viktig funktion, inte bara för cybersäkerhet, utan minst lika mycket för att hitta avvikelser i produktionen. De mest uppenbara möjligheterna finns kanske kring förebyggande underhåll men man kan tänka sig många kreativa varianter... En fantastisk variant är att man kan låta sin SOC via säkerhetsövervakning korrelera förändringar i den fysiska processer med händelser i systemen... Nu kan det bli fokus på produktionsprocesserna på riktigt i säkerhetsarbetet! I en kommande version har Clavister kombinerat AI-funktionen med deras enorma stöd för OT-protokoll på ett riktigt starkt sätt. Man kommer exempelvis kunna göra saker såsom " skicka bara Topic-fältet från all MQTT trafik till Ignition-servern på AI-analys ". Då blir förstås analysen ännu mer fokuserad och vass! AI-funktionen kan nog bli en oväntat viktig pusselbit för många teknikorganisationer att kunna erbjuda mer än "bara" cybersäkerhet till den producerande verksamheten. Nu kan cybersäkerhetslösningen även hitta andra oönskade beteenden än hackers och virus! En annan unik egenskap hos NetWall 200R passar för de OT-tillämpningar där det uppstå farliga konsekvenser om man förlorar kommunikationen i nätet. Det leder ofta till att man helt undviker att stoppa in cybersäkerhetsutrustning för att inte skapa andra risker genom ökad komplexitet. Man vill kanske exempelvis inte riskera att en brandvägg går sönder och då helt förhindrar kontakten mellan kritiska komponenter. I NetWall 200R kan man lösa det genom att två av portarna automatiskt förbinds med varandra mekaniskt om brandväggen av någon anledning slutar fungera. Man kan alltså få extra nätverkssäkerhet under normal drift om man accepterar mindre skydd om det uppstår störningar. Snyggt! I många organisationer är det fortfarande en utmaning att få till samarbetet mellan "IT-folket" och "OT-folket". Runt nätverk, och i synnerhet brandväggar, brukar det bli extra tydligt. I de flesta fall finns de vassaste nätverksproffsen på "IT-sidan", men samtidigt vill "OT-folket" ha egen kontroll över de miljöer de ansvarar för. Ofta leder det till att man från OT-hållet skaffar prylar som är enklare att hantera om man inte är en certifierad nätverksexpert. Det som jag tycker Clavister faktiskt har lyckats med att kombinera riktigt vass fullblods-funktionalitet för den som behärskar den, med överskådlighet för den som inte har behov av alla spets-finesser. Slappna inte av för att du slutar med ESXi! I ett dokument från FBI kring LockBit noterar man i förbigående att versioner för Proxmox och Nutanix är på gång. Om din organisation precis som jag själv (och många andra just nu) slutat med VMware så betyder det att vi definitivt inte kan slappna av för ransomware-hotet. De host-system där vi kör våra virtuella system är bland de viktigaste vi har att skydda! Se till att er säkerhetsövervakning inkluderar de här systemen! Kör du fortfarande ESXi gäller det precis som tidigare att verkligen tänka igenom skyddet av dina hostar! Just nu är det en del ståhej kring sårbara implementationer av OpenSSH i ESXi vilket är ett utmärkt exempelvis på att även kommunikation som i sig fortfarande är säker kan exponera allvarliga sårbarheter i våra system. Nä, slappna verkligen inte av... Som jag noterat tidigare verkar det vara något av en trend (och en positiv sådan) att myndigheter i olika länder samarbetar allt mer för att ge ut gemensamma rekommendationer och riktlinjer. Det senaste exemplet är nog ett nytt rekord med 15 loggor på framsida, även om flera är från samma länder. Å andra sidan är en av loggorna från EU-Kommissionen... Den här gången är titeln " Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products ". I korthet ger man sig på det välkända faktumet att OT-produkter sällan byggs under parollen "Security by design", vilket i sin tur förstås beror på att kunderna ytterst sällan kräver det... Nu slår man ett slag för begreppet "Secure by Demand" i ett försök att öka intresset och medvetenheten från kundsidan. Spontant tycker jag det är väldigt bra! Det är relativt kortfattat och tydligt. För oss i EU matchar det ganska väl tankarna i kommande CRA-förordningen. Å andra sidan ändrar det inte faktumet att vissa saker som de vill att vi prioriterar för att minska riskerna för cyberattacker samtidigt ökar komplexitet och andra risker för driftstörningar... Hur som helst är det positivt att det piskar på utvecklingen av mer lättanvända säkerhetsfunktioner i OT-produkter! Det hela har sammanställts av CISA i USA som även har en kort guide kring begreppet "Secure by Demand" för alla typer av digitala produkter. Nytt (och gammalt) i labbet I förra nyhetsbrevet dök den trevliga switchen " PROmesh B8 " från Indu-Sol  (och deras svenska representation Lindh Automation ) upp. Nu får du träffa storasyskonet " PROmesh P10+ " som är en riktigt imponerande bekantskap! I grunden är det en rejäl och ruggad nätverksswitch med 8 stycken gigabit-portar och 2 stycken 2,5-gigabit SFP-portar. Den har stöd för Ethernet/IP och PROFINET, du kan ladda ner GSDML-filen direkt från switchens konfigurations-webbsida. Till det kommer en radda vettiga grundfunktioner: Stöd för VLAN inklusive trunkning En IP- och/eller MAC-baserad brandvägg NAT, alltså adressöversättning, vilket är en viktig funktion i sammanhang där man tvingas hantera IP-adresskonflikter QoS (Quality of Service) och bandbreddskontroll, ger möjlighet att prioritera trafik och att begränsa hur mycket bandbredd varje port kan lägga beslag på Portaggregering ger möjlighet att skapa "virtuella portar" med hög bandbredd genom att slå ihop flera fysiska portar Portspegling för att skicka kopior av nätverkstrafik till övervakningssensorer LLDP, Link Layer Discovery Protocol, för att upptäcka "grannskapet" på nätverket För att bygga robusthet genom redundans i nätverket finns stöd för MRP, RSTP och MSTP: MRP, Media Redundancy Protocol, ger möjlighet att bygga ringnät så att nätet överlever att man tappar en länk RSTP, Rapid Spanning Tree Protocol, kan hantera multipla redundanta länkar i mer komplexa nätverk MSTP, Multiple Spanning Tree Protocol, utökar RSTP med stöd för olika redundans beroende på vilket VLAN det handlar om Så här långt är det en ganska "normal" DIN-monterad switch som är riktigt välförsedd med smarta nätverksfunktioner, men nu börjar det bli riktigt intressant... Till detta kommer nämligen ytterligare några funktioner som ger dig möjlighet att hålla koll på din fysiska infrastruktur och upptäcka försämringar innan de orsakar problem: Den fysiska kvaliteten på kablaget utvärderas löpande på alla portar. Du får larm om någon av dem försämras för mycket, förhoppningsvis innan trafiken påverkas. Läckströmmar till jordning kan vara en jobbig källa till fel i kommunikationen, den mäts löpande. Ovanligt detaljerad statistik över hur trafiken ser ut på varje port ger möjlighet att identifiera oväntad trafik. Du kan sätta larmnivåer för allting som analyseras och definiera larm som skickas via SNMP, mejl eller till en syslog-server. Du kan också annonsera larm via PROFINET eller elektriskt via en inbyggd relä-utgång. I sin helhet är detta en riktigt imponerande skapelse! Till det finns andra produkter från Indu-Sol för att bygga vidare på analysförmågan. Dels finns " PROmanage NT " som samlar all administration och analys på ett ställe. Till det kan man koppla andra sensorer för att hålla koll på exempelvis PROFIBUS . Det här är nätverksprylar för dig som bygger automationsnätverk på riktigt och vill ha koll på ditt kablage! Utmaningarna kring just kablage är något som ofta glöms bort. I en intressant artikel  påpekar exempelvis Rob Hulsebos att temperaturen kan ha stor inverkan på hur långa kablar vi kan använda. Det är ju inte helt ovanligt att vi behöver använda långa kablar som dessutom förläggs i varma miljöer. Om vi dessutom kör strömförsörjning via PoE så spär vi på problemen ytterligare... Indu-Sol har förresten en annan intressant liten produkt, PROFINET-INspektor® NT , som är besläktad med PROmesh P10+. Även om den ju faktiskt inte primärt är tänkt som en säkerhetsprodukt, utan mer för diagnos, felsökning och som en garant för nätverkets välmående, så löser den ändå en del grundläggande säkerhetsrelaterade utmaningar. Tanken med den här prylen är att den placeras permanent mellan nätverkets PROFINET-master och resten av nätet. Där analyserar den PROFINET-trafiken på en riktigt avancerad nivå. För extra information kan den integrera med PROmesh P10+ om man använder sådana switchar. Förutom en imponerande lista analysfunktioner för nätverkets status och kvalitet så kan säkerheten hjälpas av att den kan säga till om säkerhetspåverkande händelser inträffar, exempelvis att controllern programmeras om, att det dyker upp nya enheter i nätverket eller om nätverket i sig förändras i sin topologi. Alltsammans kan integreras och läsas av även via PROFINET eller OPC UA. En cool liten pryl! Jag har tidigare nämnt Chris Chungs spännande blogg  och YouTube-kanal . Här finns det mycket godis som du kan botanisera i. Numera finns sex blogginlägg om PROmesh P10+. Mycket nöje: Indusol#PROmesh P10+_Part01_Start up your network equipment! Indusol#PROmesh P10+_Part02_Let's Connect to Profinet! Indusol#PROmesh P10+_Part03_Let's access the SNMP Server! Indusol#PROmesh P10+_Part04_Let’s use the Syslog Server sending function! Indusol#PROmesh P10+_Part05_Let’s use the MRP function! Indusol#PROmesh P10+_Part06_Let’s use the RSTP function! En kurs för dig? Om du arbetar inom elsektorn så kan jag verkligen rekommendera kursen som Svenska Kraftnät erbjuder: " ICS och cybersäkerhet för elsektorns aktörer ". Jag hör mycket goda saker om utbildningen från de som redan gått den, vilket inte är så förvånande när man vet att det är Robert Malmgren och Erik Johansson som leder den. Det blir inte sämre av att den är gratis... Skynda och anmäl dig! En kurs för din chef och en ny kurs för Sverige? Nja... Det kanske är en kurs för dig själv också? I vilket fall som helst så lanserar MSB nu en utbildning i hur man leder informations- och cybersäkerhetsarbete för "personer i ledande befattningar i verksamheter som är viktiga för samhällets funktionalitet". Kursstart någon gång kring månadsskiftet februari/mars. Den typen av utbildning kan verkligen vara en av pusselbitarna som behövs för att möta det behov av ökad digital suveränitet som efterlystes nyligen i en debattartikel i Dagens Industri . (Skriven av Annika Rydström, John Vestberg, Jim Johansson, Johan Christenson, Fredric Wallsten, Joakim Öhman och Johan Edlund) Det knyter i sin tur an till en tanke jag gått och funderat på ganska länge nu... Hur långt skulle jag komma om jag försökte bygga någon form av OT-verksamhet med enbart komponenter som utvecklats i Sverige? Jag tror det skulle bli svårt men samtidigt väldigt intressant! Den första frågan är förstås att reda ut vad man menar när man säger "svensk utrustning"... Jag vill gärna höra dina tankar om detta! mats@ot-sakerhet.se Hur ger man sig på ett sådant projekt? Dystra tongångar från regeringen! Några dagar innan julafton beslutade regeringen " Gemensamma förutsättningar för utvecklingen av totalförsvaret 2025–2030 ". Om du på något sätt arbetar med säkerhetsfrågor så berörs du, direkt eller indirekt av det som slås fast i dokumentet. Och egentligen berörs vi ju förstås alla som bor i Sverige. Det kan vara värt att läsa för att ta till sig hur landets ledning ser på situationen. Jobbiga citat som vi behöver ta till oss är exempelvis: "Det väpnade angreppet är dimensionerande." "Hoten omfattar bland annat otillbörlig informationspåverkan, cyberangrepp, illegal underrättelseinhämtning, terrorism och sabotage samt utnyttjande av ekonomiska beroenden. Aktiviteterna kan vara en del i krigsförberedelser, men utförs i väsentligt högre utsträckning lågintensivt i fredstid och är därmed något som samhället måste kunna hantera även utan särskilda beslut om höjd beredskap och med både civila och militära medel." "Nyckelpersonal kan komma att likvideras i hela samhället. " "Påverkansoperationer för att störa vår förmåga att fatta beslut och försvaga vår försvarsvilja kommer att vara en del i krigföringen." "Överraskning och vilseledning kan förväntas vara en viktig del i operationen." Jag skulle säga att alla verksamheter, oavsett vad man sysslar med, skulle må bra av att se över sin planering inför alla former av kriser. Höjd beredskap eller till och med krig skulle ju förstås vara extremformen av kris, men även i något mer begränsade situationer kan det bli riktigt jobbigt. En underskattad del tycker jag ofta är tillgången till sin egen personal och de konsulter man är beroende av. Levererar man något som är viktigt för samhället har man alla möjligheter att exempelvis krigsplacera nyckelpersoner på arbetet. Hur mäter man nyttan med CIE? Det blir allt mer populärt att använda metoder som Cyber-Informed Engineering (CIE) och Consequence-driven Cyber-informed Engineering (CCE) för att bygga bort cyberrisker med metoder som inte använder "cyber-lösningar". (Jag har skrivit om dessa tidigare, exempelvis här .) En fråga som förstås dyker upp är hur man mäter och bevisar nyttan med dessa metoder. Idaho National Labs (INL) gav nyligen MITRE i uppdrag att titta på det vilket resulterade i en intressant rapport . Man tittar på utmaningarna och listar ett antal alternativa sätt att närma sig problemet, samt rekommenderar en av dem. Intressant läsning även om man inte siktar på att använda dessa metoder eftersom de tittar på generella problem! VLAN är kluriga! VLAN är ett populärt diskussionsämne kring OT-säkerhet, om inte annat så bara den eviga tvistefrågan om virtuella LAN verkligen är en säkerhetsåtgärd? (Min åsikt är förresten oftast "Ja"!) Men oavsett varför man använder VLAN och till vad så är de ibland kluriga att få till. I ett inlägg på LinkedIn nyligen skriver Josh Vargese om skillnaderna mellan hur olika produktleverantörer hanterar konfiguration av dem. En del av egenheterna som han beskrive är ganska uppseendeväckande... Om du är intresserad av OT-nätverk och inte redan följer Josh så rekommenderar jag att du åtgärdar det bums. Många intressanta inlägg och dessutom en radda bra texter på hans företag Traceroutes blogg . Om du vill förstå teorin bakom VLAN och hur det relaterar till bland annat prioritering av realtidskommunikation finns en kort men bra artikel från svenska specialisterna inom OT-protokoll RT-Labs . Ännu ett "cybervapen"! Team82 från Claroty har dissekerat IOCONTROL , ett verktyg som enligt uppgift används av hotaktörer kopplade till Iran som kopplats till attacker mot företag och produkter med koppling till USA och Israel. Analysen bygger på kod man hittade i ett "bränslehanteringssystem" och man nämner kopplingar till attacker mot produkter från Unitronics, Orpak och Gasboy. Skaffa dig ett bollplank! 2025 kommer bli ett intensivt år för säkerhetsarbetet i producerande verksamheter. Utifrån stressas vi av både ransomwaregängens attacker och EUs nya lagkrav på robust cybersäkerhet. Samtidigt vill vi ju se positivt på nyttan med säkerhetsförbättringar – att vi vågar använda den nya tekniken och att vi kan dra nytta av all information som finns i vår produktion! Bland de organisationer jag träffar märks tydligt att intresset för säkerhetsfrågor nu verkligen har vaknat. I synnerhet gäller det kombinationen av OT-säkerhet och NIS2, där insikten om hur brett de nya lagarna slår har landat på VD:s bord. Vissa väljer att bygga upp egen kompetens medan andra tar stöd av oss konsulter. Oavsett vilken väg man väljer verkar ett behov vara gemensamt; att kunna lära av andras erfarenheter, att undvika andras misstag och att ha någon att bolla vägvalen med. Här är det roligt att se att allt fler hör av sig och etablerar en relation i förebyggande syfte. Tanken är att alltid ha någon att ringa när man behöver ett bollplank eller någon som ger feedback på det man tagit fram. Kanske behövs en NIS2-utbildning för ledningsgruppen eller en coach för den nyblivna säkerhetsstrategen? Om det avtalsmässiga redan är satt på plats kan man ju få hjälp samma dag och hjälpen kostar bara när den används. Det här är definitivt mina personliga favorituppdrag. Här känner jag verkligen att jag direkt bidrar med erfarenheter och insikter från alla de verksamheter som jag haft förmånen av att jobba med tidigare. Varje gång är det samma känsla, oavsett om det är med en styrelsemedlem, automationsingenjör, systemarkitekt, underhållsingenjör, IT-chef, pentestare, utvecklare eller säkerhetschef så är utbytet av erfarenheter väldigt berikande för oss båda! Jag kommer ha tid för fler spännande uppdrag framöver. Hör av dig! mats@ot-sakerhet.se Först till kvarn… En eller två brandväggar? Emellanåt hör man argument för att använda brandväggar från olika leverantörer som ett sätt att komma till rätta med alla de risker kring framför allt VPN-tjänster som formligen exploderat på sistone. I en kort artikel utforskar Dragos för- och nackdelar med detta tänk. SCADA och DCS möter olika risker! Sinclair Koelemij beskriver i en artikel skillnaderna i vilka risker man ser kring SCADA- respektive DCS-system utifrån hur de normalt används och den funktion de har i sina respektive produktionsverksamheter. Relevanta poänger men också läsvärt för att bättre tydliggöra skillnaderna mellan SCADA och CDS, två begrepp som jag ofta hör blandas ihop. Safety och IEC 61508, IEC 61511 och IEC 62443 Sinclair Koelemij leverar som vanligt kloka tankar , den här gången kring Safety och kopplingen mellan standarderna IEC 61508, IEC 61511 och IEC 62443. Han slår ett slag för bättre integration mellan standarder för cybersäkerhet och standarder för safety. En viktig poäng! Reaktioner på förra nyhetsbrevet Det är alltid roligt att se vad som väcker mest uppmärksamhet när jag släpper ett nytt nyhetsbrev. Förra gången var det definitivt texten om riskhantering och texten om missförstånden kring Integritet . Stort tack till er som hörde av er via mejl och er som kommenterade inlägget på LinkedIn . Björn Klug skrev ett eget inlägg som utvecklar tankarna kring riskhantering ännu mer. Kul! Minst reaktioner kom det på min tanke kring att skapa roliga dekaler så den lade jag ner direkt! Fortsätt gärna höra av er ( mats@ot-sakerhet.se ), det uppskattas mycket! Nästa utspel från EU: Produktansvar Det blir intressant att se hur PLD, det nya produktansvarsdirektivet från EU kommer användas i praktiken. Jag har själv inte riktigt landat i min syn på det här ännu, men det är väldigt uppenbart att PLD tillsammans med andra EU-krav, framför allt cybersäkerhetskraven i CRA-förordningen, väldigt tydligt lägger ansvaret för alla former av säkerhet hos tillverkaren. Det är förstås viktigt för mig som privatperson att förstå vad jag kan ställa för krav på produkter och tjänster jag använder. Att produkter inte ska kunna skada mig fysiskt är tydligt, men formuleringar som ”När det gäller en produkt vars hela syfte är att förhindra skada, att produkten inte uppfyller detta syfte” hintar även om indirekta klurigheter. Om ett villalarm visar sig enkelt att störa ut och en inbrottstjuv därmed tar sig in och misshandlar mig – är det larmtillverkarens fel då? Om mitt uppkopplade brandlarm störs ut av min uppkopplade brödrost och de tillsammans bränner ner mitt hus – är det brandvarnarens fel eller brödrostens? För mig som OT-säkerhetsperson blir samma citat extremt intressant. Om det finns cybersäkerhetsbrister i systemen som ska se till att en kemisk tillverkningsprocess inte exploderar och dödar alla i närheten – vems fel är det? Tillverkaren av produkten? Eller den som konfigurerat produkten genom att aktivera osäkra funktioner? Citatet ” Varje fysisk eller juridisk person som väsentligt ändrar en produkt utanför tillverkarens kontroll och därefter tillhandahåller den på marknaden eller tar den i bruk ska betraktas som tillverkare av den produkten” tyder på det. Eller kanske till och med arbetsgivaren som kravställt och installerat produkten? Det är positivt att man, precis som i exempelvis CRA, tvingar tillverkaren att ta hänsyn till hur produkten faktiskt kan tänkas användas i praktiken. Exempelvis säger citatet ”Rimligen förutsebar inverkan på produkten av andra produkter som kan förväntas bli använda tillsammans med produkten, även genom sammankoppling” att saker som kan kopplas ihop ska tåla det. Däremot hittar jag inte motsvarigheten till de formuleringar i CRA där brukaren förutsätts installera, använda och underhålla produkten som det är föreskrivet. Det är mycket som händer på det här området just nu! Som konsult och rådgivare kring OT-säkerhet märker jag tydligt att det finns ett stort intresse bland alla som berörs! (Det här skrevs först som ett inlägg på LinkedIn .) Skydda dina ingenjörsstationer! Det kan vara värt att påminna om att skyddet av ingenjörsstationer behöver ligga högt upp på prioriteringslistan för dig som jobbar med OT-säkerhet. Nog för att rena processkomponenter är känsliga i sig, men ingenjörsstationerna är i de flesta fall ännu värre. Tillgång till känslig information i projektfiler och dokumentation, sparade behörigheter och lösenord samt färre begränsningar i nätverket gör att de är en intressant måltavla. Det är dessutom här som säkerhetskrav krockar med bekvämlighet vilket kan leda till sämre skydd än tänkt. För att göra det ännu värre tenderar de också vara åtkomliga på distans på mer eller mindre säkra sätt... En artikel från Forescout berättar om en analys de gjorde kring smittade OT-mjukvaror som laddats upp till VirusTotal. Deras slutsatser kanske inte är så skräckinjagande men det belyser ändå intresset för ingenjörsmjukvaror bland de som skriver skadlig kod. En intressant detalj är att man hittat texter på nederländska och spanska i koden vilket kan vara en indikation på att utvecklarna inte finns i de länder som vanligen pekas ut i dessa sammanhang... NIS2 och Seveso? Är det någon mer än jag som saknar kopplingen mellan NIS2- och Seveso-lagstiftningarna? Som rådgivare och granskare av OT-säkerhet har jag genom åren arbetat med ett antal Seveso-klassade organisationer där hanteringen av digitala risker i kemikaliehanteringen verkligen inte känts bra. Med tanke på att Seveso är EUs lagstiftning för att förebygga storskaliga kemikalieolyckor så borde robust cybersäkerhet i stil med NIS2 rimligen vara en viktig ingrediens. En direkt koppling mellan NIS2 och Seveso är förvisso inte helt självklar. Kanske är det snarare dags att ”modernisera” Seveso-lagstiftningen, speciellt med tanke på det stora inslaget av digitala säkerhetslösningar i de flesta verksamheter numera? Läser man MSBs stöd för de säkerhetsrapporter som Seveso kräver så nämns ”ont uppsåt” bland de risker som ska hanteras, men ingenting sägs specifikt om cybersäkerhet eller OT-säkerhet. Det finns förvisso en indirekt koppling mellan NIS2 och Seveso via CER-direktivet, som möjligen skulle kunna ”smitta” NIS2 över tid, men jag tycker faktiskt området är lite för viktigt för att hanteras så. Har du mer erfarenhet av Seveso och dessa frågor? Har jag missat något avgörande? Hör gärna av dig! mats@ot-sakerhet.se (Det här skrevs ursprungligen som ett inlägg på LinkedIn .) Vem är Mats? Jag är till vardags konsult och säkerhetsrådgivare kring OT på Sectra. 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 .

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du bland annat läsa om vad OT-branschen kan lära sig efter Crowdstrike-händelsen, vad ordet proportionalitet betyder, den svenska energibranschens nya CERT, nya detaljer kring krav i NIS2, attacker mot MODBUS TCP, fysiskt skydd av dricksvatten och hur aerodynamik spelar roll för OT-säkerhet. 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! Svensk EnergiCERT bildas! Fem svenska energiföretag har tillsammans bildat "EnergiCert". (CERT är en förkortning av " Computer Emergency Response Team") Det är Jämtkraft, Vattenfall, Fortum, E.ON Sverige och Uniper som tar det här steget för att gemensamt förebygga och hantera cybersäkerhetsincidenter. Det är inte så mycket som är officiellt ännu mer än identiska pressreleaser från Jämtkraft och Vattenfall . Detta är ett samarbete mellan fem pionjärföretag men siktet är inställt på att skapa möjligheter för hela energibranschen. Vi har nyligen etablerat grunderna för partnerskapet och planerar att rekrytera en vd till hösten, säger Håkan Hagberg, säkerhetsansvarig för Jämtkraft AB.  Det här är ett riktigt bra steg som kan leda till många bra saker. Vi har sedan länge sett liknande initiativ i andra länder, inte minst InfraCERT/KraftCERT i Norge, som verkligen gjort nytta. Där hände det igen... Jag kan väl inte låta bli att kommentera Crowdstrike-incidenten även om det kanske redan är lite tjatigt? Jag ska i alla fall inte dyka i detaljerna kring vad som hände, det har andra redan gjort mycket bättre. Men det verkar klarlagt att det var en uppdatering av detektionsreglerna ledde till att säkerhetsprogramvaran Falcon från Crowdstrike kraschade de Windows-system som använde den, vilket fick enorma konsekvenser runt om i världen - både inom IT och OT. Vi som varit i branschen ett tag minns att det hänt förut, mest känd är väl McAfee som fick liknande problem 2010 . Lite extra tråkigt för Crowdstrikes VD George Kurtz som var CTO på McAfee förra gången... Det är en liten bransch... Helt klart är att QA-rutinerna på Crowdstrike kommer få en upprustning efter det här... En diskussion som genast uppstod var kring patchrutiner och hur viktigt det är med solida testrutiner innan man släpper in uppdateringar i sin systemmiljö. Nu var det ju inte en uppdatering av mjukvara i det här fallet, utan "bara" definitionsfiler vilket ju gör det hela lite klurigare... (Det var för övrigt precis samma sak som hände McAfee 2010, då var det av deras DAT-filer som ställde till det och nu var det en Channel-fil från Crowdstrike.) Det är nog många som kommer inkludera möjligheten till att provköra den här typen av uppdateringar i sina kravspecifikationer framöver! Och med rätta, det här är helt avgörande inom både IT och OT! Det behöver inte finnas ondskefulla hackers för att det ska bli riktigt jobbiga konsekvenser! De flesta "OT-incidenter" jag hört om i det här sammanhanget har orsakats av för starka beroenden till IT-världen, även om Falcon definitivt förekommer på OT-system också. Det som störts har varit kopplingar till affärssystem, utskrifter som går via system på "IT-sidan", delade administrationsmiljöer eller gemensamt Active Directory. För mig bekräftar det här en av mina gamla käpphästar som jag envisas med att tjata om så fort jag får en chans; satsa inte för mycket av dina resurser på att förebygga problem och attacker. Du behöver en rejäl förmåga kring att hantera jobbiga incidenter oavsett vad som orsakade dem. Det är de tre "bortglömda" delarna i cirkeln från NIST CSF: Detect, Respond och Recover: Detect - Här finns mycket att lära av "IT-folket"! Detect är inte bara att upptäcka attacker, utan även generell övervakning av system och nätverk. Gärna med bra loggning och inspelning så att det går att analysera vad som hänt i efterhand. Respond - Gammal hederlig krisledning och förmågan att få ihop rätt kompetens och tillräckligt med resurser när det "smäller". Mycket fokus på att öva! Recover - Här får man bygga från grunden så att man kan ta hand om alla typer av problem: brand, kraschade system eller infektioner. Lite enklare att hantera i enstaka system men mycket mer utmanande om det drabbar ALLA system... I OT-världen är mycket av det här väldigt svårt eftersom system ofta levereras och installeras av leverantörer. Den egna personalen har väldigt liten chans att hantera jobbiga situationer själv, samtidigt som leverantörernas personal snabbt blir otillgängliga om många kunder drabbas samtidigt... Här finns några att de största utmaningarna för den som behöver jobba med säkerheten i sina leverantörskedjor, oavsett om det är på grund av NIS2 eller för att det är en bra idé ändå... Och apropå NIS2, det finns ingenting i NIS2 som fokuserar specifikt på säkerhetsincidenter som orsakats av elaka hackers. Man pratar om "Incidenter" och "Allriskansats", med andra ord är allt som kan hota produktionen i fokus, vilket gör förmågan att effektivt hantera alla former av störningar avgörande. En del av detta är förstås också att bygga sina system på ett sätt som tål störningar och där det går att "provköra" uppdateringar av alla slag. Hör gärna av dig till mig ( mats@ot-sakerhet.se ) med dina tankar, insikter eller funderingar. Om du i förtroende vill berätta om er incident så är jag förstås väldigt intresserad. Ett bortglömt ord i NIS2... I diskussioner kring NIS2 fokuseras det oftast (ganska naturligt) på att höja säkerheten och hur dyrt eller jobbigt det kommer bli. Det blev dessutom "ännu värre" när den svenska utredningen föreslog att hela organisationen ska omfattas av cybersäkerhetslagen även om bara en del av verksamheten egentligen berörs av direktivet. Det jag tycker många missar är att ordet "proportionerlig" hela tiden används kring säkerhetsåtgärder. Det betyder förstås att man ska ha rejäla säkerhetsåtgärder för att komma åt allvarliga risker. Men det betyder också att man absolut kan ha mindre omfattande åtgärder för de verksamhetsdelar som inte orsakar stora risker för den egentliga NIS2-verksamheten. Mer säkerhet är inte alltid bättre, se till att hushålla med resurserna så att de får göra maximal nytta där det behövs mest! Men det förutsätter förstås att man faktiskt gör jobbet som krävs för att förstå riskerna! Utan att veta om de största riskerna kan vi inte heller veta om de minsta... Det kräver både kunskap och mod att göra det här ordentligt. Det är precis som med ordet "Prioritera". Det tenderar bara användas när man tycker något är extra viktigt, men den riktiga utmaningen är att kunna våga peka på vad som är mindre viktigt ! Om allting är viktigt så är ingenting viktigt! Varför patchning är svårt? En kort och enkel artikel av Anrei Mungiu som snyggt sammanfattar varför patchning är utmanande. Jag gillar speciellt ansvarsfrågan kring vems fel det är om det strular men också att man tenderar att enbart fokusera på operativsystem! En guldgruva för Safety! Jag råkade snubbla över en stor mängd gratis publikationer från Springer , där bland annat spännande forskningsartiklar går att läsa alldeles gratis. De har även sammanställt besläktade artiklar i böcker, exempelvis hittade jag en samling böcker kring " SpringerBriefs in Safety Management ", där exempelvis boken " The Coupling of Safety and Security " ingår. Du kan ladda ner dem gratis som pdf eller epub. Om du sysslar med Safety-frågor finns exempelvis också böcker med titlar som: Exploring Resilience Risk Communication for the Future Compliance and Initiative in the Production of Safety The Regulator–Regulatee Relationship in High-Hazard Industry Sectors Human and Organisational Factors Och mycket annat... Syra i ditt nätverk? Om du använder Zeek (ett ramverk för nätverksövervakning och IDS) i dina OT-nätverk, så kan CISAs nya projekt "ACID" , "ATT&CK-based Control-system Indicator Detection for Zeek" kanske vara intressant att titta lite närmare på. Det ger möjlighet att upptäcka och reagera på viktiga händelser kopplade till PLC:er, som synes i tabellen. Än så länge har det bara stöd för tre protokoll: S7COMM, ENIP/CIP och BACnet, men det är baserat på ett annat projekt från CISA, ICSNPP , som har stöd för många fler. Vi kan nog lugnt räkna med att fler protokoll kommer läggas till efter hand. Conny reder ut begreppen kring ISA-95 och Purdue! Trogna läsare har förmodligen redan sett mina tidigare texter om de allt för vanliga missförstånden kring Purdue-modellen och tillhörande standarder. Jag snubblade över en kort artikel av Conny Jakobsson där han reder ut begreppen, missförstånden och historiken på ett riktigt bra sätt! Förhoppningsvis kan den hjälpa en eller annan att använda rätt modell till rätt behov framöver. Vad är nästa stora grej? Dale Peterson resonerar kring vilket produktområde inom OT-säkerhet som kommer bli nästa stora grej nu när Detection-marknaden börjat sätta sig. Han tar upp remote access för OT, SBOM för OT och OT Cyber risk management. Som vanligt håller jag med honom i både resonemanget och slutsatserna! Ett facit för NIS2! Nä... Så är det inte riktigt, men det är en så kallad " Genomförandeakt ", alltså ett dokument kopplat till NIS2 där Europeiska Kommissionen beskriver sina förväntningar på hur man möter kraven i NIS2 på ett rimligt sätt. Det som har kommit nu är en remiss , alltså att vi får skicka in åsikter om akten som består av ett huvuddokument och en bilaga. Fokuset är inte på typiska OT-verksamheter utan exempelvis DNS-tjänster, cloud-tjänster mm men även managerade drifttjänster och managerade säkerhetstjänster som definitivt kan vara relevanta för en OT-verksamhet. Dessutom kan man se lite hur tänket ser ut vilket man förstås kan dra slutsatser av även för mer OT-nära organisationer. I samma veva får vi också detaljerade definitioner av vad en incident är och i synnerhet vad en "betydande incident" betyder. (Det är just "betydande incidenter" som ska anmälas.) Slarvigt sammanfattat så är det när en incident matchar minst en av: Kan orsaka finansiell skada på minst 100 000 Euro eller 5% av årlig omsättning. Kan orsaka skada på verksamhetens rykte. (Exakt vad detta innebär definieras också.) Kan orsaka att verksamhetens företagshemligheter stjäls. Kan orsaka dödsfall eller allvarliga skada på en människa. Ej behörig tillgång till nätverk eller system har inträffat som misstänks vara i ont uppsåt. Upprepade säkerhetsincidenter som inträffar inom 6 månader eller som har samma grundorsak. Specifika problem beroende på vilka tjänster som påverkats: DNS-tjänster, Toppdomäner, Molntjänster, Datorhallstjänster, Innehållstjänster, Managerade tjänster, Managerade säkerhetstjänster, Marknadsplatser, Sökmotorer, Sociala nätverk eller identitetstjänster. I en bilaga får vi lite mer detaljer kring hur säkerhetskraven ska utformas, helt fokuserat på de minimikrav som finns i NIS2-direktivets paragraf 21. Det som i mina ögon är fantastiskt bra är att man nöjer sig med att definiera vad man ska göra men inte hur . Å andra sidan är det relativt detaljerat, exempelvis räknas hela 13 områden upp som ska definieras i organisationens säkerhetspolicies. Här vet jag att det finns olika åsikter om hur det borde vara, men jag är personligen helt på linjen att det absolut bästa med NIS2 är att den inte definierar krav som är "Check-In-The-Box" utan att man faktiskt måste tänka själv och göra säkerhetsarbetet på riktigt! Det blir naturligtvis mer utmanande men resultatet är definitivt värt det. Jag hoppas verkligen att de svenska tillsynsmyndigheterna inte kommer "förstöra" det här genom att göra för detaljerade föreskrifter i sina sektorer! Högst personligen ger jag två tummar upp för kravnivån, exempelvis kring det snåriga området riskhantering. Tittar man speciellt på områden som är kluriga för OT-folket så är några favoriter att: Konfigurationer ska dokumenteras, styras och övervakas. Säkerhetstestning ska genomföras regelbundet men också vara en del av utvecklingsprocesserna. Styrd hantering av ändringar och underhåll. Patchning kan man välja att låta bli om nackdelarna är större än nyttan. Fjärrarbete ska vara uppstyrt. Nätverk ska vara segmenterade. Kraven rimmar faktiskt ganska bra med tänket i IEC 62443 och inkluderar även hänsyn till Safety-utmaningar. Extra guldstjärna till kravet att separera systemadministration till egna nät! Sårbarhetsannonseringar från systemleverantörer ska löpande utvärderas. Kraven på utbildning i säkerhetsförståelse inkluderar leverantörer av produkter och tjänster. Samma sak gäller för krav på bakgrundskontroll. En personlig favorit från NIS2-direktivet är att man ska mäta hur väl säkerhetsarbetet fungerar. Även detta kläs i lite mer detaljer nu och på ett bra sätt dessutom. Det kommer fortfarande vara en svår puck för de flesta men otroligt nyttig! Frostigt i Ukraina! Vännerna på Dragos har annonserat att de utrett incidenter i Ukraina där en ny skadlig kod, döpt till FrostyGoop, använts för att manipulera fjärrvärme i Lviv. Det "nya" i sammanhanget är, förutom att själva koden är ny, att man manipulerat en fysisk process genom att prata MODBUS TCP med aktiv utrustning och på så sätt manipulerat mätvärden och annat. Det här är i sig kanske inte så anmärkningsvärt men när man betänker att väldigt många system baserade på MODBUS TCP är dåligt skyddade (eller till och med anslutna direkt till Internet) så sätter det tonen för vad man kan ana är på väg... De noterar också att verktyget är väldigt enkelt uppbyggt, vilket kanske inte är så förvånande med tanke på att det är enkla funktioner som ska manipuleras... Tyvärr blir ofta reaktionen "Men hur kan man använda oskyddade nätverksprotokoll?", vilket förvisso är en riktig observation men jag kan ändå tycka att det är fel slutsats. Det här är en välkänd begränsning så om man vill använda sådana protokoll (vilket det ibland finns goda skäl till) så får man bygga sin säkerhet på andra sätt. Med det sagt så kan jag väl tycka att det är dags att faktiskt börja använda de säkra varianter som faktiskt finns tillgängliga sedan länge ! Som alltid finns det en mänsklig sida på det här, i synnerhet bland de som drabbades av attacken. Om jag förstod det rätt utfördes attackerna mot den ukrainska fjärrvärmen i Januari, vilket förstås är mitt i smällkalla vintern. Jag kan tycka att Rob Lee på Dragos uttryckte sig mycket lämpligt i ett inlägg på Linkedin ... Ett nytt sätt att orsaka fysisk skada... Det finns många spännande publikationer! En ny för mig var " Journal of Wind Engineering and Industrial Aerodynamics " där jag nyligen hittade ett forskningspapper med den något otippade titeln " On the cybersecurity of smart structures under wind ". Miguel Cid Montoya, Carlos E. Rubio-Medrano och Ahsan Kareemhar har tittat på den intressanta attack-vektorn som uppstår när fysiska konstruktioner som är utsatta för vind har aktiva skyddsmekanismer. Exempel är tydligen långa broar, höga byggnader, vindkraftsnurror och stora solpaneler. Det här var ett för mig okänt område inom OT-säkerhet, vilket är en av anledningarna att jag är aktiv i det här området - det finns så många spännande sätt att använda cool teknik! Cybersäkerhet för fartyg inom EU? EMSA, European Maritime Safety Agency, vilket alltså är EUs myndighet för säkerhet inom sjöfarten har gjort en bra och tydlig sammanställning av de regler och ställningstaganden som EU gjort kring cybersäkerhetskrav för fartyg och inte minst hur detta område ska inspekteras. Det där är inte speciellt snällt! Jag snubblade över en rapport som FOI gav ut förra året på uppdrag av Myndigheten för psykologiskt försvar: "Diaspora och påverkan från främmande makt" . Obehagligt och väldigt aktuellt ämne som alla "säkerhetsmänniskor" behöver ta till sig. MEN! Vi ska verkligen se upp så vi inte blir fullständigt paranoida, samtidigt som det här är verkliga och vardagliga hot som dessutom är ruskigt svåra att skydda sig mot. I rapporten har man fokuserat på beteendet från Iran, Kina, Eritrea, Syrien och Ryssland. Arbetar du inom verksamheter som är viktiga för samhället är det här viktig läsning! Chatham House om kärnkraftens cybersäkerhet För de flesta är nog Chatham House annars mest känd för " Chatham House Rule ", men nu har de släppt en forskningsrapport som tittar på den civila kärnkraftsvärlden ur ett cybersäkerhetsperspektiv; " Cybersecurity of the civil nuclear sector Threat landscape and international legal protections in peacetime and conflict ". Inte minst kopplat till intresset för att bygga små reaktorer, "SMR" och hur detta påverkas av krigshändelser i omvärlden. Intressant! Återstående eller inneboende? Som alltid, en intressant artikel av Sinclair Koelemij kring skillnaderna i att bestämma "Återstående risk" kontra "Inneboende risk". Väldigt relevant for OT-världen och med en tydlig koppling till metoderna i 62443-standarden. Inte nytt, men bra! ISA uppdaterade förra året deras kompakta guide-dokument " Industrial Cybersecurity for Small- and Medium-Sized Businesses " som är en riktigt bra start för den som är osäker på hur man lägger upp sitt säkerhetsarbete för att komma igång. Det är bara 14 sidor att läsa men de lyckas ändå sätta bakgrund och prioriterade åtgärder på ett tydligt sätt. Rekommenderas! Glöm inte S4! Missa inte att det löpande släpps videos från årets S4-konferens. När detta skrivs är vi uppe i över 30 stycken . Jag ska inte ge mig till att peka på någon favorit, de håller sanslöst hög kvalitet allihop! (Biljetterna till nästa år släpps 16:e september...) Man glömmer så lätt... Phil Venables skriver ofta kloka texter. Senast läste jag en text med titeln " Why Good Security Fails: The Asymmetry of InfoSec Investment " som är otroligt relevant för OT-säkerhet! I grunden handlar det om utmaningen som uppstår om man bedriver ett bra säkerhetsarbete, nämligen att man får färre problem som motiverar att man arbetar med säkerhet! Det påverkar både hur mycket resurser som görs tillgängligt men förstås även vad folk är motiverade att arbeta med! En speciellt viktig poäng som han också tar upp är det som kallas " Chesterton's Fence ", som enkelt uttryckt innebär att man (som person eller organisation) glömmer bort varför man införde en åtgärd. När åtgärden senare mest ses som ett hinder blir det lätt att den rationaliseras bort. En helt annan typ av lag! Det är mycket snack om lagar nu, inte minst från EU... Men en helt annan typ av lagar är de som förklarar hur någonting i vår omvärld fungerar och som vi kan lära oss någon av. Nu tänker jag inte på tyngdlagen eller något annat fysikaliskt utan lite mer "filosofiskt"... En lag som jag inte hade koll på men som jag kände igen mig i direkt är "Goodharts lag". Förenklat säger den "När du använder ett mätetal som ett mål så slutar det vara ett bra mätetal". Du har säkert varit med om varianter på detta när man vill utveckla något slags verksamhet genom att sätta utmanande mål. Man hittar någonting som går att mäta och som verkar indikera vår förmåga på ett bra sätt. Men ganska snabbt märker man att det spårar ur, exempelvis för att folk börjar fokusera enbart på vissa saker eller att mätetalet helt enkelt inte fungerar i andra situationer. I en text från 2019, skriven av David Manheim och Scott Garrabrant , beskriver de fyra varianter på varför det går snett. Perfekt läsning och bra inspiration för den som vill mäta och sätta bättre mål för sitt säkerhetsarbete framöver! Om inte annat så är det ju faktiskt ett lagkrav i NIS2 att man ska mäta sitt säkerhetsarbete... Vill du gå ännu längre finns en blogg-text av den alltid intressante Phil Venables som tar upp tio lagar kring teknikutveckling. Allt från de välkända Moore's lag och Murphy's lag till lite mer okända (men bra) som Hyrums lag och Conways lag. Där finns även några som är direkt applicerbara på säkerhetsfrågor, speciellt Wirths lag, Hyppönens lag och Venables lag. Många synpunkter på Cybersäkerhetslagen! I förra nyhetsbrevet berättade jag att jag skrev ett personligt svar på remissen av nya Cybersäkerhetslagen, den som ska möta kraven i NIS2. Förutom de 163 andra svar som är listade på försvarsdepartementets sida kan man förstås alltid begära ut de 41 övriga svaren som skickats in på remissen... Tittar man i den listan ser man att jag inte är helt ensam om att vara nördig nog att skriva ett personligt remissvar, vi är tre stycken individer... Det finns många kloka tankar även bland dessa 41 svar men som inte får samma synlighet som de 163. Lite synd kan jag kanske exempelvis tycka om Kungliga Musikskolan som bland annat pekar på det lite orimliga att en liten högskola som forskar kring musik omfattas av lagens krav. Jag hade kanske förväntat mig lite fler nödrop från andra verksamheter som kommer omfattas, men som man spontant kan tycka är lite i överkant att kräva den här nivån av skydd för. Roliga exempel som jag tänker på är tillverkare av barnvagnar, kanoter, shoppingvagnar och spelkonsoler. Det kan ju vara så att de inte finns i Sverige eller att de helt enkelt inte insett att de omfattas ännu... Cybersäkerhet eller fysiskt skydd? En rad uppmärksammade inbrott i dricksvattenanläggningar i Finland påminner oss om hur viktigt det är att det fysiska skyddet av många anläggningar matchar OT-säkerheten och hur viktigt det är att exempelvis inbrott utreds ur perspektivet "Var det manipulation av system även om det maskerats som stöld?". Kloka tankar kring nätverksswitchar En artikel av James Mulford med titeln " 10 Basic Switch Features to Improve Your Industrial Security " listar 11 (!) kloka råd för den som sätter upp nätverksswitchar för OT-miljöer. Vissa av råden vet jag att det finns lite olika åsikter om, men personligen håller jag med om allihop. Vissa råd är dessutom väldigt viktiga av andra skäl än klassisk säkerhet, framför allt tänker jag då på råden kring VLAN och kring IGMP Snooping. Nu tar vi nästa steg? I många sammanhang är det en utmaning att kunna installera säkerhetslösningar tillräckligt "nära" styrsystemen. Det kan vara på grund av svårigheter att få tillgång till nätverkstrafiken, platsbrist i skåpen eller helt enkelt kostnaden för mer utrustning. Det påverkar ofta vilka typer av information vi kan samla in och vilka typer av incidenter vi kan upptäcka. En tanke som jag själv har utforskat i en del kunduppdrag är hur man skulle kunna utnyttja den nya funktionalitet som börjar dyka upp i PLC:er från allt fler tillverkare, nämligen att köra andra typer av applikationer utöver än de klassiska "styr och mät"-delarna. Rimligen finns här en möjlighet att integrera säkerhetslösningar väldigt nära processen? Nu verkar Nozomi vara på väg med en variant på precis detta! De har annonserat att deras ARC-lösning kommer i en variant, "ARC Embedded", som går att köra i en PLC. Till en början i Mitsubishis produkter i serien MELSEC iQ-R, men en personlig gissning är att vi kommer se detta i PLC:er från fler tillverkare framöver. Det borde rimligen vara enkelt i andra produkter med liknande stöd - exempelvis PLCnext från Phoenix Contact eller Beckhoffs controllers. När detta skrivs finns inga offentliga detaljer att prata om, så jag ber att få återkomma... Tankar kring robusthet i tillverkande industri En artikel från World Economic Forum med några tankar på hög nivå kring hur tillverkande industri kan bygga en kultur där cyber-robusthet är högt på agendan. Det här är ett område som man inte ska underskatta, inte minst om man tänker sig möta kraven från exempelvis NIS2. Det är inte ekonomiskt rimligt att förebygga alla former av cyberhot, så då får man fokusera på en lagom kombination av förebyggande skydd och förmågan att hantera incidenter på ett sätt som inte raserar verksamheten. Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT. 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 .

Dags för en maxad utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du reda på nyhetsbrevets framtid, att NIS2 blir ännu mer försenat, varför en OT-SOC är en bra idé, hur det egentligen stod till ombord på skeppet som raserade bron i Baltimore, vi lär oss hur man tänker själv, möter en ny spännande bekantskap i labbet, australiensiska principer för OT, hur man får gratis pengar till säkerhet, vad vi har glömt i NIS2, hur man hackar safety-system i kärnkraftverk, du får en inbjudan till Cybernoden och så kommer ett skepp lastat med mängder av larm. 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! Nyhetsbrevet läggs inte ner! Jag fick en del oroliga frågor om nyhetsbrevets framtid efter att jag berättade på LinkedIn att jag skulle byta arbetsgivare. Men jag kan lugna alla som eventuellt är oroliga, min tanke är att nyhetsbrevet ska fortsätta precis som vanligt. Kanske till och med att det blir lite nytändning tack vare nya intryck och perspektiv i vardagen? Jag arbetar numera på svenska företaget Sectra , ett fascinerande företag som bland annat är känt runt om i världen för supercoola bildhanteringssystem inom sjukvården och för megasäkra kryptosystem . Jag finns i en grupp som jobbar med kritisk samhällsinfrastruktur och då i synnerhet kring en väletablerad tjänst för "Managed Detection and Response" (MDR eller "SOC-tjänst") som är byggd från grunden med OT-säkerhet i fokus. En annan orolig fråga som dykt upp är om jag inte kommer vara tillgänglig som rådgivare längre. Även där kan jag lugna dig om du är fundersam, konsultandet är en fantastiskt rolig del av mitt arbete som jag inte ger upp i första taget. Behöver du stöd, ett bollplank, lite utbildning eller kanske att någon agerar djävulens advokat i en workshop så är det bara att höra av dig! OT-säkerhet är hett just nu, inte minst kopplat till NIS2. Det är klokt att ha etablerat kontakten i förväg, redan innan man akut behöver det där stödet, så att vi kan bli snabba på bollen! En tredje vanlig fråga är "Varför just Sectra"? Det är en fråga som det finns många svar på, men det viktigaste svaret för mig personligen är att jag redan tidigare jobbat nära Sectras vassa medarbetare, så jag vet precis hur stimulerande det här kommer bli. Ett annat, och kanske lite mer grandiost svar handlar om att leva som jag lär. Det handlar om att jag söker mig mot lösningen på just det feltänk som jag tycker har varit allra vanligast hos mina kunder. Jag brukar ta hjälp av det välkända hjulet från NIST Cyber Security Framework för att illustrera vad jag menar. Det handlar helt enkelt om att många organisationer (medvetet eller omedvetet) lägger för mycket av sitt krut på tårtbiten "Protect", vilket ger en rejäl slagsida på säkerhetsarbetet. (Jag har skrivit om detta flera gånger förut, senast i nyhetsbrev 61 .) Sectra har förstås ett uppenbart fokus på att stötta både "Detect" och "Respond" med vår väletablerade MDR/SOC-tjänst. Det finns dessutom väldigt naturliga kopplingar från en bra SOC-verksamhet till att hålla hög kvalitet i asset-information ("Identify") och att ge "Recover" bästa möjliga förutsättningar att återställa en havererad produktion. För att allt detta ska bli effektivt och anpassat till varje verksamhets unika förutsättningar är förmågan att mäta och leda ("Govern") centralt och något som vi gärna stöttar som rådgivare! Nu får det räcka, det här var inte tänkt som en reklam för Sectra utan mer som en förklaring till varför min nya arbetsplats känns som ett väldigt naturligt steg framåt för mig. Det ska bli enormt roligt att utforska OT-branschen med Sectra-glasögon på och jag vet att jag kommer att lära mig massor! Om du är sugen på en riktig OT-SOC så berättar jag förstås gärna mer, oavsett om det är som potentiell kund eller kollega! Nej, det var inte en cyberattack! Du minns säkert den tragiska olyckan i Baltimore när containerfartyget Dali körde ner en bro vilket orsakade sex dödsfall. Genast efter händelsen cirkulerade en massa teorier om att avancerade OT-attacker mot fartygets system var orsaken till att man förlorade kontrollen över fartyget. Nu har U.S. Department of Justice lämnat in en stämning där man pekar på ganska avancerade felgrepp och slarv som ligger bakom att fartygets elsystem slogs ut upprepade gånger. Som synes har man gjort en del "intressanta" modifieringar av fartygets system... Nix! NIS2 kommer inte vid nyår! Det blir mer och mer uppenbart att den nya cybersäkerhetslagen, som skulle implementera NIS2 vid årsskiftet, inte kommer att bli klar i tid. Från källor "väldigt nära händelsernas centrum" har jag fått beskedet att riksdagen kommer få en proposition tidigast under våren 2025 och då lär det inte bli någon lag förrän om ett år. Samma besked ges nu också på MSB:s hemsida . Vi hör liknande signaler även från andra länder, exempelvis Danmark , Tyskland, Spanien och Nederländerna. Det här är förstås synd men betyder förmodligen väldigt lite i praktiken. Med tanke på hur långsamt implementationen går i de flesta organisationer som jag har kontakt med så är det kanske tur? En sak är klar för de flesta, det betyder inte att man kan ta det lugnt med NIS2-arbetet. Vill man ha lite stöd så har MSB precis uppdaterat sin text " Skydd av samhällsviktig verksamhet ". Den innehåller en vettig checklista med vad som kan vara bra att göra men ingenting om hur . En juridisk finess i sammanhanget är begreppet " EU-rättens direkta effekt " som jag ska vara väldigt försiktig med att tolka här med tanke på att jag inte pluggat juridik en enda sekund av mitt liv... Men som jag förstår det så har det slagits fast i rättsfall inom andra områden att ett EU-direktiv gäller som lag i ett land om landet inte har implementerat direktivet i tid. Det har dock en massa begränsningar och verkar framför allt handla om att privatpersoner kan hävda rättigheter som de får via exempelvis ett direktiv. Däremot får inte staten använda ett direktiv som krav på en privatperson. Här får gärna jurister i läsekretsen höra av sig med sina insikter! mats@ot-sakerhet.se Principer från down-under! ASD, Australian Signals Directorate , har publicerat ett kort dokument med 6 principer för OT-säkerhetsarbete. ASD är en myndighet som producerar väldigt bra material och det stämmer även i det här fallet! Man har dessutom förankrat materialet med motsvarande myndigheter i USA, Kanada, Storbritannien, Nya Zealand, Tyskland, Nederländerna, Japan och Sydkorea. I nyhetsbrev #51 skrev jag om ett liknande samarbete kring "Secure by design/default" och nu är det alltså OT-säkerhetens tur! Man kan tycka att det blir lite väl flummigt att komprimera det viktigaste till bara 6 principer men de har faktiskt gjort det riktigt bra och kommentarerna till respektive princip innehåller en del guldägg. Väl värt att titta på! Gratis pengar till säkerhet! Sveriges nationella samordningscenter för forskning och innovation inom cybersäkerhet (NCC-SE) är en del av MSB. De har just nu en utlysning där mindre företag kan få bidrag för cybersäkerhets-åtgärder. De har totalt 23 miljoner att dela ut och man kan få upp till 600 000 per sökande. Det kan handla om att öka kompetensen, att åtgärda risker eller att bättre möta nya krav från EU, exempelvis NIS2, CRA eller någon av alla de andra nya lagarna. Det bortglömda kravet i NIS2! Hysterin kring NIS2 och den kommande svenska cybersäkerhetslagen ökar för var dag som går. Det är förvisso bra med ordentlig uppmärksamhet, men tyvärr hamnar diskussionerna ofta på fel saker. Det tenderar att bli fokus på att uppfylla kraven på säkerhetsåtgärder, vilket i sin tur oftast beror på att diskussionerna startas av leverantörer som vädrar morgonluft. I direktivets artikel 21 finns 10 punkter med säkerhetsåtgärder som anses vara en nedre skamgräns för vad man ska ha på plats. Det nämns till exempel saker som kryptering, multifaktorinloggning och cyberhygien, men också mjuka frågor som incidenthantering, personalsäkerhet, riskanalys, leverantörskrav och katastrofhantering. Allihop är bra krav men de beskrivs extremt kort, i vissa fall bara ett ord (!), så exakt vad som krävs är verkligen inte speciellt tydligt. Det passar förvisso bra ihop med det allmänna kravtänket i NIS2 som kan sammanfattas under parollen "Tänk själv!". Bland dessa 10 punkter finns en som jag nästan aldrig hör diskuteras, men som jag tycker är fantastiskt viktig. Och svår... Det "Strategier och förfaranden för att bedöma effektiviteten i riskhanteringsåtgärderna för cybersäkerhet". Det vill säga, du ska mäta hur effektivt ditt säkerhetsarbete tar hand om dina risker. En bra effektivitet i det här sammanhanget bör ju rimligen betyda att risker sänks mycket i förhållande till vad säkerhetsåtgärderna kostar. Det betyder att vi behöver ha koll på riskerna och säkerhetsåtgärderna samt hur de relaterar till varandra. Det låter ju spontant som ett klokt och viktigt krav. Men vad betyder det i praktiken? Och vad behöver man för att klara det? Och det är här som det geniala med det här kravet blir tydligt! Det tvingar nämligen oss att ha riktigt bra ordning på alla de andra åtgärderna. Men det blir också tydligt att det kan bli väldigt omständligt och tungt... Vi behöver vi förstå vilka risker vi utsätter oss själva och samhället för Vi behöver förstå vilka åtgärder vi har på plats, deras verkliga nytta och vad de kostar Vi behöver förstå vilka åtgärder som i verkligheten påverkar vilka risker Vi behöver förstå vilka risker som orsakas av våra leverantörer och hur våra krav påverkar de riskerna I praktiken kan mätandet uppenbart bli en enorm börda i sig, och det är ju förstås inte meningen. Det finns säkert en massa genvägar man kan ta och förenklade uppskattningar som kan göras. Men vi kommer aldrig undan från att ha ordentlig koll på risker och åtgärder! Men det finns en väldigt stor nytta för den egna organisationen med det här. Om man lyckas väl med detta kan man plötsligt prioritera bland nya och existerande åtgärder baserat på vilken nytta de faktiskt gör. Det är precis det här som behövs när man ber om pengar till ett nytt säkerhetsinitiativ eller ska försvara sin budget! LARM! LARM! LARM! Ett område som på flera sätt angränsar till OT-säkerhet är genomtänkt larmhantering i kontrollsystem, alltså hur man hanterar situationer där ett system inte vet hur det ska bete sig och därför behöver larma en människa. Det här är något som sedan länge är känt som ett viktigt område, men som vanligt går inte teori och praktik alltid hand i hand. Inom sjöfarten har detta seglat upp (!) som ett allvarligt problem på senare år. I takt med att man drar ner bemanningen ombord på fartyg blir larmhantering, på gott och ont, allt viktigare. Lloyds Register har under ledning av Asger C. Schliemann-Haug undersökt situationen för att förstå om den är ohållbar och vad som kan göras för att förbättra den. De har analyserat erfarenheter från 65 vakthavande personer på 15 fartyg från 10 av världens största företag inom sjöfart. Summerat kan man säga att den 182-sidiga rapporten säger att det finns utrymme för förbättring... Om du föredrar det så finns det även en summering på 24 sidor. Jag har tidigare hört en presentation av innehållet på en träff med Maritime Cyber Guild och jag blev helt häpen över hur illa det står till i många fall och vilka skrämmande exempel man tar upp på hur det kan gå! Här finns mycket att lära även för andra branscher. Inte minst kring hur larmhantering inom själva OT-säkerhetsarbetet ska ske för att få snabba reaktionstider och detta utan att bränna ut personalen - något som tyvärr är ett vanligt problem. Det där med att tänka själv... En av höjdpunkterna i den kommande svenska cybersäkerhetslagen är hur man håller koll på säkerheten kring de leverantörer som man är beroende av. Det här är ju ett område där vi minns ett antal spektakulära attacker kopplade till exempelvis Solarwinds och Kaseya. Det är ett område där jag fortfarande hör missförstånd kring vad kraven i NIS2-direktivet egentligen säger. Det vanligaste är nog "Om du är leverantör till någon som omfattas av NIS2 så kommer du automatiskt också omfattas av direktivet". (Så är det ju alltså inte!) Om man vill djupdyka i det här området och de juridiska klurigheterna som hör till, så kan jag rekommendera Vendela Schörlings uppsats  på området. Om du läser noga så kommer du upptäcka att jag haft ett finger med i spelet under arbetet. Du hittar många kloka resonemang kring juridik, riskanalys och ansvarsfördelning. Mycket nöje med läsningen! En trio brandväggar i labbet! Det är knappast en nyhet för någon att bra nätverkssegmentering är grundstommen i de flesta OT-säkerhetsprogram. Om man ska segmentera "långt ut" i produktions-näten behöver man ha utrustning som överlever i sådana fysiska miljöer. Ofta vill man dessutom bygga brandväggsregler på detaljer i OT-protokollen och då behöver man förstås grejor som förstår dem... Det är här de ruggade OT-brandväggarna firar triumfer på egen hemmaplan. Monterade på DIN-skena, drivna med 24 Volt likspänning och fyllda med OT-specifika lyxfinesser är de perfekta att hantera de utmaningar som är vanliga i robotceller, maskiner och andra ställen med grupper av känsliga komponenter. Med rejäla kylflänsar och vibrationståliga komponenter tål de att bokstavligen sitta i händelsernas centrum. I labbet finns nu en spännande trio av dessa brandväggar. Den till höger på bilden känner ni kanske igen sedan tidigare, det är TxOne EdgeFire  som jag skrev om senast i nyhetsbrev #31 . En av mina favoriter, vars kanske starkaste sida är deras virtuella patchning baserad på sårbarhetsinformation från  ZDI, Zero Day Initiativ . I mitten ser du en riktigt spännande nykomling som egentligen "inte finns ännu", det är väletablerade svenska brandväggstillverkarna Clavister  som nu ger sig djupare in i OT-världen med brandväggen "NetWall 200R". Jag har ett förserie-exemplar med serienummer noll (!) som jag kommer att återkomma till i ett framtida nyhetsbrev. Till vänster på bilden sitter dagens huvudperson, en Anybus Defender 6004 DPI FW , en alldeles ny produkt på marknaden - på sätt och vis... Anybus  är ett av varumärkena inom svenska bolaget HMS Networks . HMS är ju något av ett doldis-bolag om man inte är i branschen själv, men du kanske vet att deras produkter går att hitta i fantastiskt många olika sammanhang, inklusive i produkter från andra produkttillverkare. En typ av produkt som HMS inte haft tidigare är OT-brandväggar, men det har de alltså åtgärdat nu. De har faktiskt gjort det på två sätt, dels köpte nyligen HMS Networks det amerikanska företaget Red Lion Controls  och fick då en väldig massa nya och spännande produkter under sina vingar. Men HMS nöjde sig inte där, de har också etablerat ett samarbete med amerikanska företaget Dynics och säljer deras trevliga brandväggar under Anybus-flagg. Det är en av dessa som nu dykt upp i mitt lilla labb, närmare bestämt en " Anybus Defender 6004 DPI FW "... Jag kan direkt avslöja att det här är en riktigt trevlig bekantskap, faktiskt en av mina absoluta favoriter i den här kategorin! I grunden liknar den de flesta produkter av den här typen; ett vettigt webb-gränssnitt där man konfigurerar alla aspekter av funktionaliteten. Har man lite fler enheter finns även programvaran "Anybus Cybersecurity Console" för enklare "mass-drift". Känslan i gränssnittet kan kanske beskrivas som "en avancerad hemmarouter", vilket jag menar som en komplimang och som jag verkligen tycker är bra i det här sammanhanget. Du kommer känna dig hemma oavsett om du är nätverksproffs eller automationsingenjör. Det är lätt att hitta i menyerna och hjälptexterna är extremt bra. De grundläggande funktionerna kring nätverket och de "normala" brandväggsfunktioner är kraftfulla och enkla att få till. Det finns gott om avancerade funktioner under "Advanced"-flikarna om man behöver göra något som är lite utöver det vanliga. I tillverkande industri är vettiga NAT-funktioner viktigt och det finns på plats. Så långt är det två tummar upp från min sida. Hur är det då med funktioner som både tilltalar OT-folket och säkerhetsnördarna? Brandväggsinställningarna har en sektion som heter "Industrial protocols" där man kan bygga regler, regelgrupper och profiler på ett smart sätt. Det finns en "Analysis"-funktion suger i sig inspelad nätverkstrafik och presenterar förslag på regler för att göra det enklare att genomskåda vad som faktiskt behöver ha regler. Riktigt elegant är att man hanterar de här reglerna separat från underliggande IP-regler. Se nedanstående exempel på en regel för MODBUS TCP som struntar i IP-adresser, portnummer etc och enbart filtrerar på ren MODBUS-information. Snyggt! Just nu finns det bara stöd för MODBUS TCP och EtherNet/IP (CIP) på den här detaljeringsnivån men ytterligare ett antal protokoll är redan på väg. Om du har en åsikt om vilka protokoll som vore intressantast att faktiskt kunna filtrera på så får du gärna höra av dig! mats@ot-sakerhet.se Den här produkten är baserad på opensource-brandväggen pfSense som i sin tur bygger på FreeBSD. Att den bygger på pfSense är förstås en stor del av förklaringen till den stora flexibiliteten i produkten. Men det ger också en annan riktigt spännande möjlighet! Genom "Packages" kan man enkelt lägga till väldigt avancerad funktionalitet. I den långa listan hittar du bland annat super-intressanta mjukvaror som: ArpWatch (Reagerar på exempelvis ARP-spoofing) Snort (IDS/IPS) Softflowd (Exporterar nätverksinformation via NetFlow) Squid (Webb-proxy) Suricata (IDS/IPS mm) Wireguard och Tinc (VPN) Zeek (Nätverksanalys) Möjligheterna som ges via Packages är nästan obegränsade och det ska bli spännande att se hur den här delen tas emot av marknaden. Hårdvaran är relativt kraftfull så den pallar att köra avsevärt mer än ren brandväggsfunktion! Om du redan använder det här i någon form av OT-sammanhang så vill jag gärna höra mer! mats@ot-sakerhet.se På det hela taget är det här en fantastiskt intressant produkt! De erbjuder extremt flexibla möjligheter att lösa dina utmaningar utan att gränssnittet känns förvirrande eller komplext. Förhoppningsvis kommer vi se stöd för fler OT-protokoll inom kort och ännu fler möjligheter med "Packages". En detalj som verkligen tilltalar mig är att licenserna är "eviga", alltså ingen oro att någon licens löper ut och stoppar någon viktig funktion! Säkerhetsuppdateringar ingår också på livstid. Vill du höra HMS själva prata om det här så finns exempelvis den här videon med Thomas Vasen på YouTube: En OT-avhandling! Sarah Fluchs är ett välkänt namn i branschen som har varit drivande på många spännande områden, exempelvis i projektet " Top 20 Secure PLC Coding Practices " som jag skrivit om tidigare. Nu har hon levererat sin avhandling som handlar om en visuell modell för att fatta, dokumentera och kommunicera beslut kring hur cyberfysiska system utformas. Vad är annorlunda med utbilda i OT-säkerhet? Ett spännande samarbete mellan ISAGCA, INL, Idaho State University och DOE har resulterat i ett dokument som innehåller en mycket stor mängd kunskaper som de bedömer behöver vara annorlunda i en cybersäkerhetsutbildning riktad mot OT-miljöer jämfört med "vanliga" cybersäkerhetsutbildningar. Och det är verkligen en diger lista de fått ihop, så man måste nog verkligen ta fasta på ordet "guidance" i titeln: "CURRICULAR GUIDANCE: Industrial Cybersecurity Knowledge". Med tanke på att ser ut att börja lossna även i Sverige kring denna typen av utbildningar, så finns det nog en hel del inspiration att hämta här! NIS2 handlar mest om OT-säkerhet! NIS2 trycker på två saker; dels starka nationella strukturer för cybersäkerhet, och dels ”cyber-robust” produktion i organisationer som är viktiga för samhället. Om vi funderar över den där robusta produktionen, så inser vi direkt att de flesta organisationer som ingår i NIS2 producerar något ”fysiskt”. Det är tillverkande industrier, energiproduktion, transporter, dricksvatten, avlopp, avfall, livsmedel och kemikalier. Det är dessutom sektorer som innehåller väldigt många organisationer och där den samhällsviktiga verksamheten är helt beroende av god OT-säkerhet. IT-säkerhet är förstås också viktigt, men samhället kommer inte bry sig så mycket om ert fakturasystem står still eller om din budgetrapport för oktober är otillgänglig. Men om produktionen stannar blir det snabbt problem! Inget ont om banker, kommuner, IT-driftleverantörer, DNS-tjänster och rymdtjänster – de är väldigt viktiga! Men de är betydligt färre och har i de flesta fall relativt moget säkerhetsarbete redan idag. Den stora utmaningen framöver finns därför i organisationer som behöver OT-säkerhet, både för att de tenderar av vara mer omogna och för att de är många fler! Just nu är det många som nyvaket ställer ganska grundläggande frågor kring NIS2 i diverse forum på nätet, exempelvis: ”Vad är det jag behöver göra egentligen?”. Det är förstås en väldigt bra fråga, egentligen precis den fråga som alla behöver ställa sig. Problemet är att man ofta får ett och samma svar tillbaka; ”Det är bara att implementera ISO 27001!”. Svaret är i sig inte fel. Men som nörd inom OT-säkerhet drar det direkt i gång några stora varningsflaggor i mitt huvud. Jag ska vara väldigt tydlig med att jag verkligen gillar ISO 27001 och att jag tror att det är rätt väg för nästan alla organisationer! De där varningsflaggorna hänger mer ihop med de typiska dikeskörningar som jag sett lite för många gånger i organisationer som gett sig på att bygga ett ledningssystem med hjälp av ISO 27001. Flera av dikeskörningarna blir dessutom lite extra allvarliga när det handlar om NIS2 i kombination med OT-säkerhet. En väldigt vanlig dikeskörning är att man fokuserar alldeles för mycket på Annex A i ISO 27001, alltså listan över säkerhetsåtgärder som kan vara relevanta enligt standarden. Jag hävdar att det är den minst viktiga delen av standarden och att den egentligen borde tas bort helt. Det viktiga finns tidigare i dokumentet, kapitel 4 till 10; att förstå organisationens förutsättningar, planering, styrning av säkerhetsarbetet, att löpande utvärdera hur det går och att jobba med ständiga förbättringar. De här dikeskörningarna är ett problem även utan NIS2 och OT-säkerhet, men det tenderar att göra problemet mycket större om man rusar i väg för att implementera klassiska IT-säkerhetsåtgärder. Riktigt bra kan det bli om man kombinerar kapitel 4 till 10 i ISO 27001 med del 2 av IEC 62443. Det kräver förstås lite extra jobb men resultatet kan bli riktigt välanpassat till både IT och OT. Samtidigt! Hur man skyddar ett kärnkraftverk Ruben Santamarta har just publicerat en riktig djupdykning i ett vanligt förekommande skyddssystem för kärnkraftverk. Eftersom jag är "uppvuxen" i kärnkraftsbranschen är jag förstås lite extra nördigt intresserad men det finns godis här för alla! Årets SCADA-Säkerhet har gått av stapeln! I mitten av september spenderade jag två dagar på konferensen "SCADA-Säkerhet" i Stockholm. Som man förstår av det lite ålderdomliga namnet är det en konferens som funnits i ett antal år nu och som samlar en trogen publik. Det var två dagar av föredrag, men kanske framför allt två dagar av riktigt roliga diskussioner med både nya och gamla bekantingar. Ett stort tack till alla jag träffade där för många inspirerande samtal! Favoriterna bland föredragen var nog: Björn Eriksson som är gruppchef komplexa cyberbrott (KCB) på Polismyndigheten som pratade om hur polisen arbetar vid cyberattacker. Hörde många kommentarer efteråt om att det var viktigt att få höra. Jimmy Persson som är utvecklings- och säkerhetschef på Svenska Stadsnätsföreningen pratade om robusthet och fysiskt skydd på ett sätt som jag tror många organisationer kan ha nytta av även i helt andra branscher. Du kan läsa deras anvisningar för fiber och för anläggningar . Anders Jonson som är medlem i ENISA AHWG – EUCS/AI pratade om hur framför allt NIS2 kommer påverka branschen. Ted Strandberg som är projektledare på RISE tog avstamp kring det uppdaterade Radiodirektivet från EU och vad som händer runt om det. Cybernoden! Har du koll på Cybernoden ? Om inte så tycker jag du ska titta närmare och om din arbetsgivare inte redan är medlem så är det faktiskt gratis! Den officiella förklaringen av vad Cybernoden är: " Cybernoden är Sveriges nationella kompetensgemenskap inom cybersäkerhetsforskning och innovation och drivs av RISE på uppdrag av NCC-SE inom ramen för ECCC, och är finansierat av Vinnova. " Det finns en lång radda temagrupper, så det finns garanterat någon som passar oavsett vilken typ av säkerhetsarbete du är intresserad av! Men den roligaste gruppen är förstås " Säkerhet i ICS/OT " som jag och Thomas Vasen leder! Hör av dig om du vill vara med och bidra till diskussionerna! ( mats@ot-sakerhet.se ) ENISA har inte så mycket fokus på OT? EUs cybersäkerhetsmyndighet ENISA har just publicerat " ENISA Threat Landscape 2024 ", deras analys av hotläget mot EU och världen. Rapporten är intressant i sig, men ännu mer intressant kan det tyckas att OT-säkerhet nämns exakt en enda gång i ett dokument på 131 sidor... Men? Vem är det som kör egentligen? Välkände profilen Joe Weiss har publicerat ett 24-sidigt dokument under rubriken "Who’s in charge of OT security?" där han skriver kloka saker kring den "eviga frågan" om hur vi ska få IT och OT att fungera bra tillsammans. NSSS24 och CRA I slutet av september gick konferensen Nordic Software Security Summit av stapeln i Stockholm, organiserad till största delen av Olle E. Johansson. Jag var inte där själv men har förstått att den var mycket uppskattad av deltagarna. Något som kan intressera läsarna av det här nyhetsbrevet var Filipe Jones Mourao från Europeiska Kommissionen som i sin keynote-dragning berättade om läget kring Cyber Resilience Act, CRA: Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på Sectra. 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 .

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du en rolig tävling, försäkringsbolagens nya fokus på OT-säkerhet, världsläget inom OT enligt SANS, dödsstöten för risk-management, Pentagon driver Zero Trust inom OT, beröringspunkter mellan olika standarder, vad ordet sårbarhet egentligen betyder, realtids-Linux, det senaste kring CRA/NIS2/Maskinförordningen och en lång radda andra spännande ämnen. 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å Bluesky , 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! Försäkringsbolagen är på G! I dessa dagar, när alla pratar om nya lagar som ställer krav på säkerhetsåtgärder i våra produktionsmiljöer får vi inte glömma en annan maktfaktor som redan arbetat med det här i många år. Jag tänker på försäkringsbolagen. Och jag ska säga direkt att jag inte tänker på cybersäkerhetsförsäkringar utan att försäkringsbolagen allt mer hanterar digital säkerhet i produktionsmiljöer på samma sätt som brandskydd och andra "klassiska" riskområden. Jag har deltagit som stöd till några av mina rådgivningskunder när deras försäkringsbolag kommer på "inspektion" med fokus på cybersäkerhet i produktionen. Mina intryck av hur försäkringsbolagen hanterar det här är väldigt positiva! Det har varit kunniga människor som ställer meningsfulla frågor och som drar mycket relevanta slutsatser om riskerna. Ett exempel på ett försäkringsbolag som jag har ett gott intryck av är FM Global. De är extra intressanta för att de dessutom publicerar en mängd texter kring vad som är bra att tänka på för att minimera risker i produktionen. Ett exempel, som nyligen uppdaterades, handlar om " Industrial Control Systems ". Som du kanske märkt är jag väldigt positiv till de ökade kraven från exempelvis EU, men jag måste säga att försäkringsbolagen kan komma att ha lika mycket effekt - även om de verkar lite mer "bakom kulisserna". Jämförelsen med att ha bra brandskydd haltar förstås lite men det tydliga ekonomiska tryck som försäkringsbolagen börjar sätta mot organisationer med dålig säkerhet i produktionen kommer ha effekt! Läget i OT-världen enligt SANS Jag är inte så förtjust i alla de där årsrapporterna som vänder och vrider på enkätsvar för att skapa något som liknar spännande insikter. Men välkända utbildningsföretaget SANS, som jag har mycket respekt för, släppte nyss sin " 2024 State of ICS/OT Cybersecurity ". Du får själv ta till dig vad du tycker är rimligt, relevant och intressant men jag noterade för min del att: Användningen av molnbaserade tjänster ökar snabbt nu. Det matchar för övrigt vad jag själv ser bland mina kunder. Förmågan att upptäcka säkerhetsincidenter och att hantera dem är fortfarande svag hos de flesta. Här hoppas jag att många påverkas av det fokus som NIS2 har på just detta - insikten att du oavsett hur mycket skydd du har, så behöver du fortfarande kunna upptäcka, hantera och analysera en produktionspåverkande händelse. Färre rapporterar ransomware-angrepp vilket matchar utvecklingen generellt. Förmågan att försvara sin OT-infrastruktur tycks fortfarande främst bygga på accesskontroll, backuper, EDR, IT/OT-separation och säker fjärråtkomst. En förvånansvärt stor andel har fortfarande ingen säkerhetsövervakning eller OT-SOC. Jag får ofta frågan om man ska ha en separat SOC för OT (särskilt nu när jag jobbar på Sectra). Svaret är som vanligt: "Det beror på!". I de fall OT-systemen verkligen liknar "vanliga IT-system" och produktionen faktiskt inte har annorlunda behov än resten av organisationen så är en kombinerad SOC definitivt rimlig. Annars finns det anledning att vara försiktig. Riktigt glädjande att se att så många tagit rejält tag i sin fjärraccess! 33% spelar in sessionerna och 55% kan övervaka och avbryta uppkopplingar om märkligheter upptäcks. Kul att fler inser de grava begränsningarna med vanlig VPN! Har du koll på 2024/2847? 2024/2847 blev det officiella dokumentnumret på CRA, Cyber Resilience Act , när lagen nyligen publicerades och därmed börjar gälla den 11:e december. Det betyder att nedräkningen mot full implementation den 11:e december 2027 har börjat. På vägen finns det ett antal "etappmål"; bland annat ska aktivt utnyttjade sårbarheter börja rapporteras redan 11:e september 2026 och från den 11:e juni 2026 gäller reglerna kring organisationer som granskar överensstämmelse. Senare samma år, från och med den 11:e december 2026, ska länderna ha sett till att det finns tillräckligt många sådana granskande organisationer inom EU. Det har verkligen gått inflation i lagar med ordet "Cyber" i titeln på senare tid. Det är faktiskt något av ett problem, i synnerhet om NIS2 verkligen kommer implementeras i Sverige under namnet "Cybersäkerhetslagen". NIS2 handlar i mina ögon främst om resiliens och CRA mest om säkerhet - vilket gör namnen väldigt förvirrande! Nu blir det tre bråda år för väldigt många produkt- och mjukvaruproducenter, även de mest mogna utvecklingsprocesser behöver i de flesta fall kompletteras. Det kommer kanske också bli en del intressanta kommersiella effekter, bland annat eftersom alla säkerhetsuppdateringar enligt lag måste vara gratis från och med 2027... Men? Vem är det som kör egentligen? Joe Weiss har publicerat ett dokument med den spännande titeln "Who's in charge of OT Security", som är tänkt att försöka reda ut många av de klassiska frågorna kring OT-säkerhet, exempelvis: Skillnader mellan IT och OT samt mellan IT-säkerhet och OT-säkerhet? Vad är Purdue-modellen egentligen tänkt att användas till? Inträffar det några OT-säkerhetsincidenter? Skillnaderna mellan nätverkssäkerhet och "Safety" i kontrollsystem? Hur ska man organisera och leda säkerhetsarbetet? Hur kommer vi framåt? Kluriga frågor som förtjänar kluriga svar! Den eviga frågan om risk! Ett område som jag personligen alltid har haft svårt för är "Risk management". Jag har aldrig känt mig riktigt bekväm i någon av alla modeller för riskidentifiering, riskanalys, riskprioritering, riskhantering osv som jag stött på genom åren. Det känns nästan alltid väldigt konstlat med noll eller inget fokus på att faktiskt skapa något slags verkligt värde. Ett intressant perspektiv hittade jag i ett LinkedIn-inlägg av Marinus de Pooter som egentligen är en utskrift av en presentation han genomförde under "Risk & Resilience Festival" på Nederländska Universiteit Twente. Den utmanande titeln är "Stop managing risks!". Han ifrågasätter precis som jag nyttan med sedvanliga metoder kring risk och vill istället sätta ett starkt nytto-fokus och ta ledningens perspektiv. Vi får på köpet en historisk beskrivning kring vårt sätt att se på risker. Jag kan inte säga att jag ser det som en komplett lösning, men han sätter definitivt fingret på intressanta poänger, exempelvis: Poängen med att använda begreppet "uncertainty" istället, det passar betydligt bättre med de förutsättningar som alla andra beslut i en organisation styrs kring. Med stöd i COSO kan man faktiskt söka upp mer risk för att uppnå mer prestanda och/eller andra vinster. Att regelbundet uppdatera listor med saker som kan gå snett hjälper oss inte nå våra mål under oklara förutsättningar. Fokus borde ligga på "future-proofing" och robusthet som ett sätt att uppnå de vinster som risk management var tänkta att skapa. Apropå detta, i synnerhet "future-proofing" och robusthet, så hade jag en intressant diskussion nyligen kring det som jag uppfattar som en tydlig trend i samhällets syn på säkerhetsarbete. Jag tycker det är intressant att fokuset på sannolikheter äntligen har börjat minska till fördel för ett konsekvens-drivet fokus som siktar på att bygga resiliens. Det som jag stöter på oftast väl: Det är allt mer populärt att använda metoder som Cyber-Informed Engineering (CIE) och Consequence-driven Cyber-informed Engineering (CCE) som båda på sitt sätt fokuserar åtgärder mot extrema konsekvenser oavsett sannolikhet. (Jag har skrivit om dessa tidigare, exempelvis här .) Det svenska säkerhetsskyddet är inget nytt och har alltid haft just det här fokuset. Däremot appliceras säkerhetsskydd på allt fler verksamheter (på gott och ont) och i synnerhet på verksamheter där skyddet av information inte står i centrum, dvs OT. Regelverket och våra myndigheter har verkligen inte kommit ikapp kring den här typen av resonemang, men det tar sig... I de kundkontakter jag har på min nya arbetsplats, Sectra, är det väldigt tydligt att intresset för riktig säkerhetsövervakning i OT-sammanhang ökar rejält. Det kommer ofta ur en insikt om att man vare sig kan förutse alla attacker eller kan ta bort alla sårbarheter. Samtidigt måste övervakningen då vara byggd från grunden för att förstå förutsättningarna i OT-verksamheter, vilket är lätt att missa eftersom OT-tekniken allt mer liknar IT-världens teknik. Initiativen från EU, i synnerhet NIS2, bygger också på den här typen av resonemang - att skapa tålighet i samhället genom att viktiga leverantörer tål att få en "cybersmocka" utan att gå ner för räkning. Hör gärna av dig med tankar kring detta kluriga ämne! mats@ot-sakerhet.se Pentagon satsar på Zero Trust för OT-säkerhet I en intressant liten artikel i "Breaking Defense" berättas att USAs Department of Defense nu kommer styra om fokuset på sitt arbete med Zero Trust mot OT-verksamheten. Python och honung i OT-nätet? Yuancheng Liu från Singapore har skapat "Python PLC Honeypot Project", en riktigt intressant honeypot med fokus på OT-världen. Fokus tycks vara att simulera ett antal olika PLC-typer och deras kommunikationsvägar för att på så sätt kunna identifiera och analysera angripares beteenden. Det finns även två artiklar av honom på LinkedIn. En om projektet i sig och en om uppsättning/detektion . Förvirrad av alla standarder? Det blir hela tiden fler standarder, lagar, ramverk osv som vi ska förhålla oss till! Det är lätt gjort att man känner sig lite vilse i den här djungeln. Andrew Ginter på Waterfall höll nyligen ett riktigt bra webinar där han sorterar upp ett tiotal av de mest kända, men den stora behållningen är att han också för ett resonemang kring viktiga kravområden som genomsyrar dem alla. Lyssna exempelvis på avsnitten om "Consequence boundaries" och "Risk-based approach", det här är viktiga resonemang för alla som jobbar med OT-säkerhet. Om du inte redan gjort det så missa inte att beställa Andrews senaste bok som är gratis! Massor av klokskap på ett och samma ställe! Vad menar du med ordet "Sårbarhet"? Att hålla koll på sårbarheter är viktigt inom både IT-säkerhet och OT-säkerhet. Det är också en av de saker som ofta lyfts fram som en viktig skillnad mellan just IT och OT. Tanken brukar vara att IT typiskt har mycket enklare att snabbt kunna patcha sårbarheter i system medan OT-folket behöver göra fler och svårare avvägningar mellan nytta och risk. Det här med att patcha är med rätta också något som har stort fokus i både standarder och myndighetskrav. För oss i OT-världen finns det en fälla som jag tycker många missar när de definierar sin sårbarhetshantering. Fällan bygger på att själva ordet "sårbarhet" har ganska olika definitioner beroende på om du lever i en verksamhet som lever efter ISO 27001 eller efter IEC 62443. ISO 27001 pratar just om svagheter i ett system eller en säkerhetsåtgärd. IEC 62443 har en betydligt bredare definition som även tar med brister i hur ett system utformades, hur implementationen gjordes och hur systemet sköts om. Det kan tyckas som en liten och oviktig skillnad men den kan få ganska stora konsekvenser... "Vulnerability" enligt IEC 62443-3-2: Flaw or weakness in a system's design, implementation or operation and management that could be exploited to violate the system's integrity or security policy "Vulnerability" enligt ISO 27000: Weakness of an asset or control that can be exploited by one or more threats Den vardagliga betydelsen har ofta en ännu smalare definition som bara handlar om mjukvaror. Med glimten i ögat skulle den bli något i den här stilen: "Vulnerability" i vardagligt språk: A mistake in software that stubborn vendors keep creating. It can be fixed by simply applying an patch before hackers can use it in some magical way. Det där med att 62443 tar med svagheter i hur ett system är designat är ju ganska naturligt i OT-världen med tanke på att vi använder en hel del "svaga" protokoll och system som inte är utformade för att vara robusta. Tyvärr finns det en tendens att det glöms bort, vilket skapar onödigt arbete. Ett påhittat exempel på vad jag menar är att vi har en applikation där en motor styrs via en "frekvensare", en VFD, från en PLC via MODBUS TCP. En eventuell angripare med tillgång till nätverket skulle enkelt kunna styra motorn direkt utan att PLCn har något att "sätta emot". Då blir det ganska konstigt om man bekymrar sig över en ny DoS-sårbarhet i PLCn och lägger ner mycket arbete på att patcha den när det finns mycket enklare sätt att störa produktionen... Det här är inget stort problem om man är medveten om det och verkligen ser till att alla i den egna organisationen använder samma tolkning. Däremot är det förstås viktigt att vara extra noggrann om man siktar på att certifiera sig mot en standard! Om man är en så pass mogen organisation att man har ett integrerat ledningssystem med inslag av både ISO 27001 och IEC 62443 blir det en lite klurigare balansgång att hantera detta. Men det går! Sinclair levererar igen! Vi är sedan länge bortskämda med att Sinclair Koelemij skriver superintressanta texter. Nu är det dags igen, den här gången en ganska detaljerad artikel om integritet som del i riskanalys inom petrokemisk industri. Vad är det jag missar? CIA-triaden, alltså den gamla välkända trion av ord: Confidentiality, Integrity och Availability, känner du säkert igen från Informationssäkerhet! Ett vanligt argument när "folk" försöker förklara skillnaden mellan säkerhetsarbete i IT och i OT är något i den här stilen: "Inom IT är Confidentiality och delvis Integrity viktigast. Man kan tänka sig att offra Availability för att skydda de andra två. Inom OT är Availability viktigast." Det brukar dyka upp som förklaring till att man inte vill patcha i OT-världen, eftersom det oftast kräver att system görs otillgängliga. Det här har jag alltid haft svårt för, och av minst två skäl. Dels så är det helt enkelt inte sant för alla typer av OT-verksamheter, ett vanligt exempel är tillverkande industri som, i många fall, relativt enkelt kan hantera planerad nertid. Men det som "stör" mest är att jag tror de flesta skulle säga att Integrity är viktigast i de flesta OT-sammanhang! Att vi tappar tillgänglighet är förstås aldrig bra men för de flesta verksamheter skulle det vara ännu värre om integriteten i styrningen av processen manipulerades! I synnerhet när vi talar om farliga verksamhet där Safety-system ska hålla koll på att inget farligt händer. I ett välbyggt system går det inte att missa att ett Safety-system blir otillgängligt, men om systemet i stället manipulerades så att det agerar utifrån fel förutsättningar - då kan det bli riktigt farligt! Jag tror att det här missförståndet kan ha sin grund i att man pratar om olika saker? Tillgänglighet av funktion kontra riktighet i funktionalitet kanske? Har du åsikter om detta vill jag väldigt gärna höra dem! mats@ot-sakerhet.se Guide för CIS Critical Security Controls Jag verkar ha missat att CIS i somras släppte en guide för hur man använder "CIS Critical Security Controls v8.1" i OT-världen. Dessa controls är ju väldigt populära i IT-världen, dels för att man begränsat sig till bara 18 huvudsakliga säkerhetsåtgärder och för att man vågar ranka dem genom att säga att control 1 är viktigast att göra först. Upplägget är tydligt! För var och en av de 18 får vi en översikt, en beskrivning av hur den passar inom OT-världen, speciella utmaningar för OT och lite referenser till andra dokument. Varje säkerhetsåtgärd har som vanligt ett antal "underrubriker", kallade "Safeguards" som beskrivs var för sig med OT-ögon. Ett mycket användbart dokument, i synnerhet om organisationen använder CIS Controls för fler saker. Kräv inte att dina leverantörer följer NIS2! Ett vanligt slarvfel som jag hör från "förståsigpåare" är "Om du levererar till ett NIS2-företag så omfattas du också av NIS2!". I synnerhet är det vanligt från säljsugna produktleverantörer som utlovar "NIS2-compliance som produkt". Men det finns ingen sådan regel, vare sig i NIS2 eller förslaget till cybersäkerhetslag! Däremot ska en NIS2-organisation se till att leverantörernas säkerhetsnivå inte ställer till det för dem själva som kund! En liknande tankevurpa hör jag från organisationer som omfattas av NIS2 när de ska ställa krav på sina leverantörer: "Om ni ska sälja till oss så måste ni uppfylla NIS2!". Det är förvisso helt möjligt att ställa ett sådant krav men du riskerar att skjuta dig själv i foten som kund. Varför då undrar du kanske och då svarar jag att: Med ett "flummigt uttryckt" krav riskerar du att orsaka mycket onödigt arbete och därmed onödiga kostnader för din leverantör, vilket i slutänden kommer att hamnar på fakturorna som de skickar till dig... NIS2 pratar mycket om proportionalitet i de säkerhetsåtgärder du väljer. Du ska ha vare sig mer eller mindre säkerhet än vad som faktiskt är meningsfullt för dig. Varför ska du då missa chansen att sätta din egen nivå på kraven mot leverantörerna? Vilka delar av deras leverans är viktigast och vad är dina krav? När cybersäkerhetslagen har satt sig om några år och vi fått föreskrifter från en rad olika tillsynsmyndigheter så blir det omöjligt för en underleverantör att veta vilka kravmassor de ska bry sig om för respektive kund. Det måste vara ditt jobb som kund att definiera! Glöm inte att riktigt kritiska leveranser kanske måste ha mycket högre krav på sig än de allmänna kraven i NIS2! Om du själv inte omfattas men är leverantör till NIS2-organisationer så kan du göra det mycket enklare för dig själv genom att redan nu sammanställa de krav du uppfyller åt dina leverantörer. Mindre jobb för dig och gladare kunder! Jag håller förvisso med de som säger att NIS2 egentligen inte kräver något speciellt säkerhetsarbete som inte alla organisationer redan borde ha på plats. Men i praktiken är det inte så enkelt och det behöver vi förhålla oss till! Leverantörer är helt avgörande för många verksamheter och då borde de få motsvarande uppmärksamhet i säkerhetsarbetet! (Den här texten publicerade jag på LinkedIn för ett tag sedan. Det märks att det är ett ämne som engagerar, det blev det i särklass mest lästa inlägg som jag någonsin gjort. Det finns en del godis att läsa bland kommentarerna .) Riktigt realtids-stöd i standard-Linux! I takt med att det blir allt populärare med olika typer av edge-produkter i OT-världen samtidigt som PLC:er baserade på "normala" operativsystem också får allt mer uppmärksamhet är det passande att nu den ordinarie Linux-kärnan fått stöd för realtids-hantering från version 6.12. Jag gissar att det firas hos företag som Beckhoff och WAGO nu? Nu blir det NIS2-smisk? EU har beslutat att agera formellt kring att majoriteten av länderna i unionen grovt har missat deadline för NIS2 och CER. Sverige är i "gott sällskap", det är totalt 23 länder som får ett brev på posten (!) som uppmanar dem att återkomma inom två månader med implementation eller en plan. CRA utreds i Sverige.... En utredning har tillsats för att titta på vad som behöver göras i Sverige kring EUs Cyberresiliensförordning, CRA. Arbetet leds av Anette Norman, som också drev NIS2/CER-utredningen. Arbetet ska vara klart 15:e december nästa år. Notera att det alltså inte är samma typ av uppdrag som NIS2/CER, där handlade det om att implementera två EU-direktiv i svensk lag, nu är det en EU-förordning vilket gäller som lag direkt - men däremot kan det behövas justeras i andra lagar för att det ska fungera bra. En tävling med ett pris som du bestämmer själv! Bland folk som sysslar med cybersäkerhet har det alltid varit många som tycker det är kul att klistra laptopens skärm full med märkliga klistermärken med anknytning till det man sysslar med. Av det skälet tänkte jag att det kunde vara kul att framöver trycka upp lite roliga klistermärken med koppling till OT och nyhetsbrevet, men jag behöver din hjälp att hitta riktigt bra idéer! Det kan vara något om OT-säkerhet som område och varför det är viktigt. Det kan vara för sajten ot-säkerhet.se . Eller det kan vara något annat som har med området att göra, kanske safety, robusthet eller produktion? Det vore riktigt kul med förslag till en smart logga för nyhetsbrevet! Skicka mig dina bästa och sämsta idéer, det behöver inte vara en bild utan kanske en bra text eller ett budskap att förmedla! mats@ot-sakerhet.se Jag är enväldig domare och vinnaren kommer förstås få sitt förslag upptryckt som klistermärke! Det finstilta: "Om du skickar in ett förslag så säger du att det är okej att jag använder det oavsett om du vinner eller inte." Här är några utkast jag lekte med själv, men låt inte mina försök begränsa din egen kreativitet: När jag ändå var igång så provade jag även text på reflexmaterial som monterades på varseljackan. Nu kan man visa upp sig på ett riktigt moderiktigt sätt igen! :-) Och så blev det förstås några broderade patchar för ryggsäckar som också blev riktigt bra. Kom gärna med alla möjliga kreativa förslag! Allt uppskattas! Vad skulle du själv vilja ha? Lås dörren inifrån! En insikt som IT-säkerhetsvärlden tog till sig för många år sedan verkar fortfarande inte ha "landat" fullt ut inom OT-säkerhet. Det handlar om hur man bygger brandväggsfunktioner som inte bara styr upp vad som får "komma in", utan även vad som får "komma ut". Eftersom många attacker så att säga uppstår inifrån så behöver man också ha koll på vad som kommunicerar ut. Ett typiskt hemmanätverk har någon form av brandvägg som ser till att allt elakt på Internet inte kan komma åt prylarna som är anslutna till hemmets nätverk; laptops, skrivare, tv-apparater och kylskåp. Inget konstigt så långt. De flesta har nog aldrig tänkt tanken att man skulle kunna begränsa vad man får komma åt på Internet. (Utom möjligen föräldrar som vill styra upp barnens åtkomst.) Många enklare IT-nätverk liknar ett sådant hemmanätverk, möjligen kompletterat med funktioner som försöker titta på trafiken för att hitta misstänkt skadlig kod eller liknande. Har man servrar som ska vara åtkomliga på Internet så släpper man fram bara rätt trafik till just dem. Men i stort är det fortfarande framförallt fokus på att begränsa vad som släpps in. IT-nätverk med högre krav på säkerhet har genom åren ägnat sig att även styra upp vad som släpps ut på Internet. Vanlig surfning släppte man typiskt ut men man höll ändå koll på att det faktiskt var rimlig trafik och kanske att krypteringen var korrekt. Men sedan började det ta stopp, typiska exempel var: De allra flesta servrar har inga eller väldigt begränsade behov av att fritt nå Internet. Uppdateringar och annat ska hanteras via de verktyg som hämtar hem sånt. DNS-trafik är väldigt lämpligt att både övervaka och filtrera. Då behöver man också begränsa vilka system som skickar ut externa förfrågningar. Trafik på ovanliga portar eller via ovanliga protokoll bör styras upp så att allsköns bakdörrar inte skapas. I takt med att allt fler IT-system blev "molnifierade" behövde man hantera det här annorlunda men behoven finns ofta kvar. I grunden handlar det om att bara det som behöver kunna prata på nätverket ska ha möjlighet att göra det. Lite besläktat på sätt och vis med "least privilege" och "Zero trust". För de allra flesta OT-nätverk är det här fortfarande extremt relevanta åtgärder i kommunikationen med IT-system. OT-nätverk som behöver fri åtkomst till vad som helst på "IT-sidan" är ovanliga och bred åtkomst direkt till Internet är rimligen extremt ovanligt. OT-nätverk (bör) kännetecknas av att förändringar sker sällan och bara i samband med planerat arbete. Det betyder att vi enklare kan styra upp vad som får prata ut från OT-nätverket och vi kan betrakta oväntad ny trafik med misstänksamhet. Glöm förresten inte det som Beacon från SensorFu kan hjälpa dig med! Jag skrev om den här fiffiga lösningen i nyhetsbrev #57 . Den upptäcker den alla möjliga spännande varianter på kommunikation som man kan använda att få kontakt med något utanför en brandvägg... Man behöver komma ihåg att OT är många olika saker, där alla OT-verksamheter är olika, så man behöver välja säkerhetsåtgärder efter sina egna förutsättningar. Några kloka åtgärder att överväga är: All trafik, både in och ut, från OT-nätet ska vara känd, dokumenterad och tillåten individuellt per system eller liknande. En del oväntade protokoll kan användas för att styra skadlig kod eller stjäla information. DNS är en sådan vilket gör det viktigt att se till att begränsa både vem som får skicka förfrågningar en också vilka frågor som får ställas. Ett specialfall är fjärruppkopplingar som förstås behöver lite extra uppmärksamhet. Välj något som faktiskt stöttar verksamheten på ett vettigt sätt och undvik att använda "en vanlig VPN". Alla andra former av tunnlar bör begränsas. Beroende på hur man arbetas med segmentering inom OT-nätet och hur man använder DMZ-liknande funktioner får man förstås anpassa regelverket för vad som får prata med vad. Ägna speciell uppmärksamhet åt system och nät som används för systemadministration. I många fall är det vettigt att inte blanda med IT-världen och det är definitivt vettigt att ha superkoll på system där exempelvis Domänadministratörer kan logga in. Glappet mellan Säkerhetsskydd och NIS2! Ska din organisation följa både Säkerhetsskyddslagen och den föreslagna NIS2-Cybersäkerhetslagen? Då vet du nog redan att det är tydligt att enbart Säkerhetsskyddslagens krav gäller för de delar av verksamheten där de båda lagarna överlappar. (I alla fall för de flesta verksamheter.) Det finns dock en klurighet som kan vara värd att fundera över, nämligen att de två lagarna adresserar olika hot! I NIS2, och därmed Cybersäkerhetslagen, säger man väldigt tydligt att riskanalyser ska göras ur ett "allriskperspektiv", dvs alla risker som kan påverka produktionen via någon form av cyberhot ska tas med. Säkerhetsskyddslagen däremot, är enbart inriktad på det som brukar kallas "antagonistiska hot". Där ska riskanalysen, som är en del av Säkerhetsskydds-analysen, enbart titta på medvetna mänskliga angrepp. Det är förvisso inte helt sant, lagen säger också att säkerhetskänslig information även ska skyddas på vissa andra sätt, exempelvis mot brister i dokumenthanteringen. I det här sammanhanget brukar man prata om Verksamhetsskydd när man tar hand om alla andra typer av risker, men det är inget som kravställs i lagen. Den utmaning jag ser är alltså att det, på sätt och vis, blir lägre krav på robust produktion via säkerhetsskyddslagen än via cybersäkerhetslagen! De risker som faller mellan stolarna är skador som orsakas av olyckshändelser, haverier, otur, naturkatastrofer, misstag, tekniska brister och liknande som ingen "elak" person orsakade med flit. Men jag har samtidigt inget förslag på hur lagstiftarna kunde gjort det annorlunda. Hanteringen av tillsyn och incidentrapportering skulle bli väldigt komplicerad om man försökte kombinera de två lagarna i samma verksamhet. Det här är inte tänkt som kritik mot säkerhetsskydd, även om mycket kan utvecklas i stödet kring de delar av säkerhetsskyddet som inte fokuserar på hemlig information. Vi får helt enkelt hantera det som saknas i kraven i ren självbevarelsedrift. Om det stora syftet med vårt säkerhetsskydd är att säkerställa att vi kan hålla igång vår verksamhet så är det precis det vi hela tiden måste ha i bakhuvudet! Målet med vårt arbete måste alltid vara en robust produktion oavsett om det handlar om el, vatten, fjärrvärme eller något annat område där rätt OT-säkerhet är avgörande för vår förmåga att producera. (Den här texten finns även på LinkedIn och har ett antal intressanta kommentarer som är värda att läsa.) Inget förtroende för Zero trust? ISA Global Cybersecurity Alliance (ISAGCA) är en sammanslutning av företag som hålls samman av organisationen ISA, som ju är en av organisationerna bakom 62443-standarden. De har publicerat ett white paper som tittar på Zero Trust ur ett OT-perspektiv. Zero Trust och OT-säkerhet är en lite klurig kombination som många leverantörer satt sin egen spinn på för att visa att de kan leverera "Zero Trust på burk". Det här dokumentet är ett samarbete mellan bland annat Nozomi Networks, Schneider Electric och Rockwell Automation vilket gör det lite mindre produktfokuserat. Det tar upp en del intressanta vinklar som kan vara värda att ta till sig om man siktar åt det här hållet i sitt säkerhetsarbete. Ett annat dokument på samma tema imponerade faktiskt lite mer på mig. Det är CSA, Cloud Security Alliance (!) som producerat " Zero Trust Guidance for Critical Infrastructure ". Här har man utvecklat resonemangen mycket mer och kombinerar många intressanta vinklar från både NIST, CISA, ISA, IEC 62443 och SANS Five ICS Cybersecurity Critical Controls . De kryddar alltsammans med citat från självaste John Kindervag och knyter ihop säcken snyggt. Nu ökar takten från EU! Det duggar allt tätare mellan viktiga utskick från EU. När det gäller Cyberresiliensförordningen CRA så har den kommit i en slutgiltig version . Här ställs alltså krav på säkerhet i utveckling och underhåll av alla former av digitala produkter. Apropå CRA så har Sarah Fluchs släppt en (som vanligt) bra och tydlig artikel om dokumentationskravet i CRA och dessutom en artikel om hur CE-märkningen i CRA fungerar . Hon har dessutom skrivit en artikel  där CRA och Maskinförordningen jämförs. Spännande eftersom de har en del intressanta överlapp... När det gäller NIS2 så har vi fått en skarp version av den genomförandeförordning som jag nämnde i ett tidigare nyhetsbrev . Från EUs cybersäkerhetsmyndighet ENISA finns också ett utkast till stöd kring förordningen ute för feedback. Här finns en del detaljer kring vilka typer av bevis som kan vara lämpliga vid en tillsyn kring dessa regler. Det finns också en del referenser till standarder som man kan ta hjälp av i de olika olika kraven, men eftersom kraven inte är inriktade på OT-säkerhet finns tyvärr inga referenser till 62443-standarden. Vi har också fått ett uttalande från Post och Telestyrelsen PTS som berättar att verksamheter som omfattas av "NIS1" och som träffas av genomförandeförordningen förväntas ta hänsyn till kraven där sedan den 7:e november. Den 27:e november höll Post och Telestyrelsen, PTS, ett webbinar kring NIS2 som dessutom finns inspelat . En rimlig fråga är då om OT-verksamheter verkligen är intresserade av de branscher som PTS har tillsyn över? Svaret är faktiskt ja, även om kopplingen mest är indirekt. Bland de branscher som PTS är tänkt att ha tillsyn för finns förutom kommunikationstjänster även IT/OT-drifttjänster och outsourcade säkerhetstjänster, exempelvis en OT-SOC eller patchningsuppdrag som man lägger ut på underleverantörer. Nytt (och gammalt) i labbet För den som är road av kul teknik så inför jag nu den här stående rubriken i nyhetsbrevet. Här kommer jag helt kort nämna saker som nyligen dykt upp i OT-labbet där hemma eller prylar som funnits där ett tag men inte har synts tidigare. Vissa av dem återkommer kanske lite senare med mer djuplodande analyser. Jag får erkänna att jag inte hade full koll på Indu-Sol och deras svenska representation Lindh Automation innan jag träffade dem på Scanautomatic-mässan i oktober. I vilket fall så imponerade deras prylar på mig direkt och de skickade med mig en " PROmesh B8 " hem. Det är en managerad 8-portars switch med utvecklat stöd för Profinet och EtherNet/IP. Så här långt verkar den mycket kompetent, men jag ska nyfiket prova lite mer utmanande saker. Det första blir nog att testa integration med PLCnexts engineeringverktyg via definitioner i en GSDML-fil. Snyggt och tydligt i alla fall! Indu-Sols övriga sortiment ser riktigt intressant ut för den som vill ha hjälp att bygga nät som går att diagnosticera och analysera. Jag rekommenderar en titt på deras övriga produkter också! Av en slump snubblade jag lite senare över Chris Chungs spännande blogg och YouTube-kanal . Här finns det mycket godis som du kan botanisera i, inte minst tre blogginlägg om Indu-Sols kraftfullare switch-serie PROmesh P10. Mycket nöje: Indusol#PROmesh P10+_Part01_Start up your network equipment! Indusol#PROmesh P10+_Part02_Let's Connect to Profinet! Indusol#PROmesh P10+_Part03_Let's access the SNMP Server! Tyskt vatten är säkrare! I Tyskland öppnades nyligen ett gemensamt säkerhetscentrum; "Lagezentrum CyberSec@Wasser" , för landets vattenindustri. Där finns en SOC, Security Operations Center tillsammans med centraliserad sårbarhetshantering och någon form av utbildningsverksamhet. I Sverige annonserades ju nyligen EnergiCERT som har likheter med det tyska initiativet. Jag tror vattenbranschen i Sverige skulle må väldigt bra av ett sådant här initiativ, det är typiskt verksamheter med mycket begränsade resurser som förvaltar en otroligt viktig resurs! Vad säger ni, ska vi starta en svensk motsvarighet? Läs förresten gärna den utmärkta sammanställningen som William och Joel på Svensk OSINT gjort kring de svenska dricksvattenincidenterna som vi sett nyligen. Det där med riskaptit? En person som jag regelbundet återkommer till i nyhetsbrevet är Phil Venables. Han levererar ideligen kloka texter där det finns mycket att lära. Nu senast hittade jag en text om floskelbegreppet "Riskaptit" som hjälper oss att se igenom det slarviga bruket av det här begreppet och istället hittar lite handfasta råd kring hur man kan skapa verklig nytta. Om inte annat så tydliggörs skillnaden mellan Riskaptit och Risktolerans... Sjöfart är alltid spännande! En förmån i mitt arbete är att jag får vara med i intressanta samverkansgrupper. En av dessa är " Maritime Cyber Guild " som träffas ett par gånger om året för att diskutera erfarenheter inom sjöfarten med fokus på OT-säkerhet. Nyligen träffades vi hos BIMCO i Danmark och det blev som vanligt en dag fylld med spännande diskussioner. Några av punkterna på agendan som jag själv tog med mig lite extra mycket från var: Resultat från övningar där erfarna besättningsmedlemmar "utsätts" för ovanliga situationer, orsakade av en hacker, i ett simulerat fartyg. De var utrustade med glasögon som registrerade hur de arbetade med felsökningen i fartygets system. Resultatet bekräftade tidigare insikter om att avancerad OT-hacking inte behövs om man på något sätt skaffat sig tillgång till samma system som personalen arbetar i. I exemplet ledde en liten börvärdes-ändring i kylsystemet för fartygets generatorer till att alla fyra generatorer slogs ut samtidigt. En felorsak som i praktiken är väldigt svår att hitta tillräckligt snabbt, även för mycket erfaren personal. Ett fartyg i skärgårdstrafik sitter då redan på klipporna. DNK, "Den Norske Krigsforsikring for Skib", berättade om cyberförsäkringar kring sjöfart. Försäkringar är ett spännande område som blir ännu klurigare när det handlar om fartyg. marcybersec.com är en intressant sajt där man bland annat samlar rapportering av sjöfartsrelaterade cybersäkerhetsincidenter. Diskussioner kring hur meningsfullt det är med penetrationstester tidigt under ett fartygsbygge med tanke på att det lätt blir något som man gör för att "få en bock i rutan" samtidigt som det tenderas att tas mängder med dåliga "genvägar" under tiden system installeras ombord. Om du är aktiv inom OT-säkerhet med koppling till sjöfart och vill vara med i gruppen så hör av dig. Det är gratis och alltid intressant! mats@ot-sakerhet.se Sugen på att hacka lite MODBUS? Pascal Ackerman är en välkänd profil i OT-säkerhetsbranschen, han har bland annat förekommit tidigare i nyhetsbrevet med några av sina välskrivna böcker. I två artiklar som publicerades nyligen gör han en djupdykning i hur man man sätta upp en eget MODBUS-labb för att experimentera i: Del 1: "Attacking MODBUS" Del 2: "Attacking Modbus, Act 2 - Using Scapy" Vem är Mats? Jag är till vardags konsult och säkerhetsrådgivare kring OT på Sectra. 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 .

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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du (nästan) en ursäkt från mig, MSBs åsikter om NIS2-lagen, nytt kring sjöfartens säkerhet, positiva tankar från Dale Peterson, lärdomar kring hantlar och dödsfall, ENISA kopplar CRA till IEC 62433 och så funderar jag på att strunta i Radiodirektivet. 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! Jag ber om ursäkt! Eller? Nä... Egentligen inte... Om du av någon anledning inte är intresserad av NIS2, CER, CRA, RED eller någon av alla de andra regleringarna som EU pytsar ur sig just nu så börjar det nog bli lite tjatigt med all uppmärksamhet som detta äntligen börjar få. Det här nyhetsbrevet är definitivt inget undantag, proppen har verkligen gått ur för de här frågorna sedan nyår! Men jag tycker mig ha bra anledningar till att lyfta detta så mycket just nu. Om du läst tidigare nyhetsbrev vet du att jag är väldigt positiv till den effekt som jag tror att framför allt NIS2 och CRA kommer få på OT-säkerheten i Sverige. Jag tillhör inte alls dem som tycker det är synd att det behövs lagstiftning för att organisationer ska ta ansvar för samhällets cybersäkerhetsrisker. Tvärtom, det är ganska naturligt att det behöver finnas tydliga ekonomiska drivkrafter för det här! En effekt som jag tror vi kommer se tydligt är hur det här också kommer "smitta av sig" på företag som inte är direkt berörda av av NIS2. Producerar man digitala produkter så blir det självklart något av en revolution för många organisationer när CRA ska implementeras, det är ju uppenbart. Men effekten av fokuset på supplychain-säkerhet i NIS2 tror jag kommer ha en enorm effekt på vad som betraktas som en "normal" förväntansnivå på cybersäkerheten hos alla former av leverantörer. I och med att NIS2 har produktion som fokus kommer bra och tydlig OT-säkerhet bli helt avgörande för väldigt många organisationers affärsmässiga framgångar eller haverier. Så du får nog räkna med att jag, och många med mig, fortsätter att tjata om det här ett tag framöver! Och oavsett vad du tycker om det så tror jag att du kommer kunna dra nytta av effekterna, vare sig du vill eller inte... Är faran över? Nej, så långt gick han inte, Dale Peterson, i hans keynote-tal på årets S4-konferens, men han gav en mycket mer positiv och hoppfull bild jämfört med den vi normalt föds med från branschens alla olyckskorpar. Under parollen "Believe", som i att vi ska tro på att vi faktiskt löser våra utmaningar rätt bra, gav han oss sin ljusare framtidsversion där halva lösningen är att inte ge upp innan vi ens försökt... Det här fick en lätt chockad Ralph Langner att publicera en egen video där han kommenterar Dales något oväntade och väldigt positiva presentation: Ingen (inte ens Ralph Langner) förnekar att det förekommer OT-säkerhetsincidenter. Vi kan förstås alltid diskutera hur vi definierar en sådan incident, vilket kan vara roligt, men egentligen inte så viktigt. Om vi tillfälligt struntar i eventuella farliga situationer som kan uppstå i vissa branscher, så är ju det viktiga faktiskt att vår produktion inte drabbas av störningar, oavsett om det är dricksvatten, legobitar eller diesel vi skapar. Vår verksamhet finns där för att producera, i det flesta fall är den primära produkten ekonomisk vinst, som vi skapar genom att först producera något annat med ekonomiskt värde som vi säljer. Kan vi inte producera så tjänar vi inga pengar, och då spelar det mindre roll varför vi inte kunde producera! Vi har alla hört diskussionerna om OT-säkerhetsincidenter som "egentligen" är IT-incidenter. Attacker som drabbar fakturasystem, logistik eller orderhantering men som gör det omöjligt att bedriva produktionen på ett meningsfull och säkert sätt. Lite för ofta hör jag åsikten att den här typen av incidenter mindre viktiga eller intressanta jämfört med en riktig "Stuxnet-liknande attack". Jag håller med om att de är mindre coola, men för att skydda produktionen är de väl egentligen viktigare? De inträffar ju faktiskt relativt ofta och dessutom med allvarliga konsekvenser! Eftersom jag sällan sysslar med stöd kring redan inträffade incidenter blir jag ibland rädd att jag drabbas av en slags "survivor-bias", där jag inte fullt ut hör om de OT-incidenter som faktiskt inträffar. Man hör ibland historier om mindre händelser, ransomware på HMI:er och sånt, men sällan något större. Om du kan tänka sig att dela med dig att dina war-stories så är jag förstås väldigt intresserad av att prata mer om det under strikt tystnadslöfte. Även händelser som var "nära ögat" är superintressanta. Hör av dig på mats@ot-säkerhet.se eller skapa ett möte här. Jag tror precis som Dale att vi kan hantera OT-säkerhetshotet enklare än vi ibland tror. De stora utmaningarna är, som vanligt, att verkligen förstå vad verksamheten är beroende av och att använda våra begränsade resurser där de gör mest nytta. Vi kommer aldrig få alla de resurser som skulle krävas för att ta bort alla risker - men det är inte meningen heller. De flesta verksamheter existerar inte för att du och jag ska vinna VM i OT-säkerhet utan för att skapa produktion till rätt kostnad! Glöm inte Radiodirektivet! Eller borde vi göra just det? Kan det vara så att i allt ståhej kring NIS2 och CRA så har EUs Radiodirektiv "RED" blivit lite bortglömt! Det här är inte ett nytt direktiv, det kom i en första version 2014. Fokus är, precis som namnet indikerar, på alla former av radioutrustning, både sändare och mottagare - oavsett om det är en telefon, en walkie-talkie eller en GPS. Genom ändringar och genom tillägg till direktivet omfattar det numera en rad saker som inte var påtänkta från början. Den kanske mest kända är beslutet att tvinga fram USB-C som standard för laddare av mobil utrustning, I oktober 2021 kom ytterligare en så kallad "Commission Delegated Act" som lägger till en massa cybersäkerhetskrav till Radiodirektivet. Implementation i augusti i år, 2024, var det tänkt. Men det visade sig lite för jobbigt så förra sommaren kom ett nytt beslut som sköt fram införandet till augusti 2025. Det man lägger till är i huvudsak tre saker som har med cybersäkerhet att göra: Radioutrustning som kan "kommunicera på Internet" ska omfattas av ett redan existerande krav som lite slarvigt sammanfattat säger att utrustningen inte ska skada eller störa nätverket. Radioutrustning som kan hantera personlig information eller platsinformation ska skydda den informationen om utrustningen är Internetansluten, avsedd för barn eller kan bäras på kroppen(!). Radioutrustning som kan hantera något slags pengar ska uppfylla krav för skydd mot bedrägerier. Jag är verkligen ingenting annat än en total amatörjurist, även om jag erkänner att jag har en smått perverst nöje av att läsa lagtext. Det här tillägget till RED tycker jag faktiskt är lite märkligt. Det blir nog framför allt konstigt för att man bakar in detta i ett direktiv som jag tycker egentligen handlar om något annat. Det är inte helt tydligt för mig vad de nya kraven siktar på och framför allt har man inte definierat vad ordet "Network" betyder. Ordet användes tidigare i betydelse radionät men ingen ny definition finns nu när det rimligen borde inkludera även Internet? Min tolkning som amatörjurist är att det fortfarande krävs att radiovågor skickas eller tas emot eftersom ordet radioutrustning är definierat så. Det här gäller i så fall inte prylar som bara kommunicerar via en ethernet-kontakt! Ur ett OT-perspektiv tillkommer lite mer förvirring kring formuleringen som säger att saker omfattas om de kan kommunicera på Internet. Vad betyder det för protokoll som inte är baserade på IP? Det hela blir ju faktiskt lite extra fånigt när vi vet att CRA är på gång och liksom kommer ta över de här kraven och det med råge! Det finns dock ingenting som säger att kraven i RED kommer försvinna. Det vore intressant att höra från någon klok person som dykt djupare i det här och kan reda ut begreppen lite mer... mats@ot-sakerhet.se Inspelningar från S4! De första inspelningarna från årets S4-konferens har nu börjat släppas i en separat spellista på YouTube. Efterhand kommer det mesta att släppas utspritt under året. Ta chansen och lyssna på ett stort antal att de stora hjärnorna i OT-säkerhetsvärlden! Det finns massor av godbitar, en av dem är den alltid lika intressanta paneldiskussionen som avslutar hela konferensen. Den är faktiskt inte släppt som video än men du kan tjuvlyssna på en ljudversion så länge. Ni har gjort fel! En av medlemmarna i ovanstående S4-panel är den ständigt underhållande och utmanande Ralph Langner. I en text sammanfattade han nyligen sin kloka syn på hur man bygger en robust OT-plattform. Mycket nöje! Baksidan av NIS2? En av de saker som jag verkligen gillar och tror på kring NIS2 (och den kommande Cybersäkerhetslagen) är att man tvingar alla som omfattas av lagen att ställa motsvarande krav på sina leverantörer. Det skapar ju verkligen ett affärstryck för alla som vill kunna vara en leverantör till NIS2-organisationer - och de blir ju väldigt många! Men vad är baksidan då? Jo... Det är ju jobbigt att ställa krav på sina leverantörer, åtminstone om man ska göra det ordentligt - för då ingår ju förstås att följa upp att de faktiskt brytt sig om dina krav... Relationen mellan leverantörer och kunder är ju alltid "Många-Till-Många", det vill säga kunder måste följa upp många leverantörer och leverantörer måste hantera krav från många kunder. Dessutom kommer förstås alla kunder göra detta "på sitt sätt"... Här finns förstås en fin affärsmöjlighet för den som vill göra det här åt andra företag. Man tar betalt av en leverantör för att göra något slags assessment av säkerhetsarbetet, vilket är trevligt för leverantören som bara behöver göra det här en gång. Sedan tar man betalt av alla kunder till den leverantören för att sammanställa hur leverantörens förmågor kring säkerhet ser ut. Perfekt även för kunden eftersom man kan gå till ett ställe och ta reda på allt om alla sina leverantörer.... Så långt - inget problem! Eller? Jag har sett ett gäng Internet-baserade tjänster som försöker lösa detta, men det är inte alla som inger förtroende... Mina invändningar är framför allt: Vilken leverantör kommer någonsin avslöja något negativt till en sådan mellanhand utan att det finns mycket starka avtal upprättade mellan dem som reglerar sekretessen? Mellanhanden hamnar i en spännande position där man skulle kunna få tillgång till otroliga mängder ytterst känslig information. Börjar man tänka i begrepp som "ackumulerad och aggregerad information" så gissar jag att man snabbt hamnar i nivåer där säkerhetsskydd är aktuellt ur ett svenskt perspektiv? Ovanstående två punkter kommer i bästa fall leda till att ingen kommer berätta sanningen vilket i sin tur gör resultatet från arbetet helt meningslöst. Jag säger inte att det här är omöjligt att göra på ett bra sätt, jag har bara inte sett någon göra det ännu... De varianter som passerat framför mina ögon än så länge har verkligen inte gjort ett solitt intryck! Jag vill gärna bli överbevisad och då vill jag förmodligen dessutom investera i det företaget direkt! Däremot kanske våra branschorganisationer har en fin möjlighet här? Då kan man tänka sig att kravställningen blir relevant, uppföljningen fokuserar på rätt saker och hanteringen sköts av en organisation som man kanske redan litar på. Jag tror just branschorganisationer kommer ha en viktig roll att fylla generellt, både på kund- och leverantörssidan. Vad kan vi lära av en hantel? I en artikel av Dale Peterson refererar han till den ekonomiska strategin "Barbell strategy". Det är tanken att man har en enkel med trygg basplattform som man kompletterar med något som tar hand om oönskade händelser. Översatt till OT så tänker han sig att man kommer relativt långt med enkla och billiga säkerhetsåtgärder som kompletteras med åtgärder som säkerställer något slags drift trots att vissa incidenter inte kan förhindras. Själv brukar jag använda hjulet från NIST Cyber Security Framework för en liknande poäng. Där är min tanke att det lätt blir slagsida till fördel för preventiva åtgärder inom området "Protect", men att man missar Recover som är nödvändigt för att kunna hantera när incidenten är ett faktum. På samma sätt springer många och handlar IDS-system, som är tänkta att användas inom Detect men organisationen har inte resurser att agera på larm från IDS-systemet, dvs Respond. Istället blir resultatet i bästa fall att man får förbättrad information om sin anläggning, dvs lite åt Identify-hållet, med bättre asset-information. Att lära av ett dödsfall? Som vanligt när Sinclair Koelemij skriver blir det intressant och utmanande. I en text med rubriken "Strategic Decision-Making in Cyber-Physical Risk Assessments and Cyber Ethics" beskriver han flera klurigheter som är specifika för vår vardag som OT-säkerhetsmänniskor. Intressant nog är det delvis ett svar på Dales artikel om hanteln som jag skriver om här ovanför. Han utmanar bland annat användningen av modeller där man lägger mycket krut på att uppnå tålighet genom att vara snabb i återställningen av redan havererade system. En svårighet med det (som jag hintar om i rubriken ovan) är om konsekvenserna kan bli riktigt allvarliga, till den grad att inte allting är möjligt att återställa på ett rimligt sätt, som människoliv, miljöskador eller kritisk utrustning som har mycket långa leveranstider. Läs och begrunda! En bra påminnelse om att våra riskanalyser inte får fokusera för mycket OT-systemen om de stora konsekvenserna uppstår utanför systemen! MITRE kopplar CWE till IEC 62443 CWE skrev jag senast om i nyhetsbrev #49. CWE, Common Weakness Enumeration, är ett systematiskt sätt att beskriva svagheter i mjuk- och hårdvaror. Nu har MITRE lagt till en vy som heter "Weaknesses Addressed by ISA/IEC 62443 Requirements" där namnet ganska väl beskriver vad tanken är. Snyggt upplägg som gör CWE ännu mer användbart för OT-folket! Om du är road av detta så finns även en uppdaterad dashboard hos "ICS Advisory Project" där du kan filtrera registrerade Sårbarheter/CVE:er mot vilka CWE-koder de orsakas av med koppling till respektive krav i de olika standarderna inom IEC 62443. Nu kan man verkligen gå helt bananas i att analysera dessa sårbarheter! Mycket nöje! Ännu mer på gång från MITRE! Om man läster MITREs plan för ATT&CK: "ATT&CK 2024 Roadmap" ser man att de har mycket på gång för OT-folket. Det blir mer detaljer kring attacker, man gör om asset-informationen och mycket annat. Den som väntar på något gott... ENISA kopplar CRA till IEC 62443 Lite på samma tema som det MITRE gjort för att koppla CWE till standarden har nu EUs cybersäkerhetsmyndighet ENISA publicerat en mappning mellan CRA-förordningen och en rad olika standarder. Det hela är på en väldigt hög nivå men kan ändå vara en väldigt praktisk startpunkt om man ska ta tag i sitt CRA-arbete! Det man dessutom får på köpet är att de sammanställt de krav som de anser att CRA formulerar kring säkerhet och hantering av sårbarheter. Det är 13 + 8 krav som annars inte är helt enkla att hitta i den massiva förordningen. Dessa krav mappas sedan mot en rad olika standarder med ett resonemang om hur respektive standard tar hand om kravet och eventuella gap som man behöver ta hänsyn till. Allt är på ett ruskigt hög nivå, resonemangen är enbart för en hel standard, exempelvis: De standarder man har med är en rejäl lista, så oavsett vad du är i för bransch så finns nog flera relevanta med: ISA/IEC: 62443-3-2, 62443-4-1, 62443-4-2 ISO/IEC 9796 2-3, 9797 1-3, 9798 ISO/IEC 13888, 14888 ISO/IEC 15408-2, 15408-3 ISO/IEC 18031, 18033, 18045 ISO/IEC 19249 ISO/IEC 22237 ISO/IEC 24760 ISO/IEC 27002, 27005 ISO/IEC 27034, 27036 ISO/IEC 27701 ISO/IEC 29100, 29147 ISO/IEC 29146, 29147 ISO/IEC 30111 ETSI 103 485, 303 645 ITU-T X.805, X.812, X.814, X.815, X.1214, X.1253, Y.4810 Jag hittade också en bra översikt gjord av Steffen Zimmermann: Från teori till praktik Som du kanske minns från nyhetsbrev #46 så använder jag ibland programvaran Factory IO i mitt kära hemmalabb för att illustrera fysiska processer. Det visar sig att det finns fler som gillar den här produkten, i en två-delad artikelserie beskriver nämligen Team82 från Claroty deras användning. I del 1 kan vi läsa om hur de satt upp sitt labb och i del 2 beskriver de ett antal praktiska attacker som leder till ett härligt kaos i processen. Följetongen om EUs språkhantering... I förra nyhetsbrevet skrev jag att ryktet om att CRA skulle bli framskjutet tydligen var fel eftersom texten klubbades i Europaparlamentet. Nu visar det sig att jag kanske inte var så fel ute i alla fall, senaste budet är att en slutgiltig version sannolikt inte blir klubbad förrän framåt oktober. Nå ja, vi får se... Om du producerar digitala produkter fick du några extra månader på dig, det kommer bli tajt ändå för det flesta... Lustigt det där... Som jag nämnde i nyhetsbrev #59 så har VMware annonserat att gratisversionen av ESXi ska försvinna, ett tungt slag för många hemmalabbare som använt det som bas för virtualisering. Det här ökar förstås intresset ännu mer för andra alternativ och då kanske i synnerhet min egen favorit Proxmox VE. Som av en händelse annonserade nu Proxmox nytt stöd just för att automatiskt migrera virtuella maskiner från ESXi direkt in i Proxmox VE... Lustigt det där... Det har förstås tekniskt varit möjligt även tidigare men krävt lite mer handpåläggning. Nu ansluter Proxmox VE direkt till ESXi-server och "suger i sig" systemen. Smidigt! Välkommen över till den ljusa sidan! Var är klockan? I nyhetsbreven #59 och #60 skrev jag om utmaningarna kring GPS/GNSS-störningar. För den som vill lära sig mer finns ett bra dokument från kanadensiska företaget NovAtel som ingår i välkända svenska Hexagon-koncernen. Där beskriver man både störning och spoofing tillsammans med deras egna lösningar för att minska problemen. De refererar även till en artikel i "Inside GNSS" som tittar på samma ämne. Äntligen någon som tycker som jag! Om du lyssnat på någon av mina föredrag kopplat till NIS2 så har du sannolikt hört mig fundera högt kring den märkliga definitionen av kemikalie-sektorn. Jag skrev också om det i ett nyhetsbrev nyligen. Nu har jag hittat tecken på att fler ifrågasätter om den extremt breda definitionen (alla verksamheter som använder "kemikalier" för att framställa något slags vara) verkligen är rimlig! Den tyska juristfirman reusch law har publicerat dokumentet "Working Paper on ANNEX II No. 3 NIS2 Directive, NIS2 and REACH" skrivet av Steffen Zimmermann från VDMA and Stefan Hessel där de verkligen går till botten med den här frågan. Förslaget från den svenska utredningen kring NIS2 och CER har inte tagit alls i den här frågan utan för vidare samma definition som i direktivet. Något annat var i och för sig inte att vänta sig eftersom man som land inte kan göra så stora ändringar i omfattningen hos ett direktiv. Det ska bli väldigt intressant att se hur Länsstyrelserna i Norrbottens, Skåne, Stockholms och Västra Götalands län kommer hantera den här nöten, de är nämligen föreslagna som ansvariga för föreskrifter och tillsyn i den här sektorn... Jag har en känsla av att man inte räknat på det här sättet när man uppskattade hur mycket resurser Länsstyrelserna kommer behöva... Ett skepp kommer lastat... Attacker mot GNSS-system är en av alla populära diskussionsämnen i området säkerhet inom sjöfarten. Det här med potentiella attacker mot fartyg fick lätt bisarra proportioner nyligen, när fartyget Dali kraschade in i Francis Scott Key Bridge i Baltimore vilket resulterade i att stora delar av bron rasade. Genast dök en lång rad olyckskorpar upp som kraxade om att det minsann kunde vara en cyberattack. Personligen tycker jag det är direkt pinsamt och korkat att försöka skaffa sig poänger genom att presentera vilda teorier som helt saknar faktisk grund. Det här beteendet är verkligen ett av skälen till att vi säkerhets-människor inte tas på allvar när vi varnar för risker. I det här fallet så kan det förstås visa sig att det faktiskt var en cyberattack, men den diskussionen tar vi när det är klarlagt! Däremot är det definitivt så att cybersäkerhet i sjöfarten är spännande och viktigt, speciellt kanske OT-säkerhet ombord på fartyg! Jag har haft förmånen att vara insyltad i några fartygsprojekt och det är en fascinerande men utmanande värld! I nyhetsbrevet har det tidigare funnits nyheter om att det kommer skarpare krav på området och nu är det flera intressanta sådana på gång igen. Framför allt är det klassningssällskapens organisation IACS som från och med 1:a juli sätter kravdokumenten UR E26 och UR E27 i skarp verkan. De skulle ju ha gällt redan från 1:a januari, men i sista minuten drogs de tillbaka och reviderades. Samtidigt släpper man en uppdaterad version 3 av UR E22 som handlar om utformning, konstruktion, driftsättning och underhåll av alla datorbaserade system ombord som krävs för att få fartyget klassat. Dessutom är FN:s sjöfartsorganisation IMO på gång att godkänna en uppdatering av deras riktlinjer för cyberriskhantering inom maritima verksamheter. (Länken kräver ett gratis konto.) Som skäl uppger IMO att man bland annat vill adressera förändringarna i hotlandskapet, sätta en tydligare basnivå för säkerheten samt tydligare referera till standarder och ramverk. Det man refererar till är förutom ISO 27000 och nya NIST CSF även tre specialiserade kravmassor: "The Guidelines on Cyber Security Onboard Ships" som underhålls av en rad organisationer ICS, IUMI, BIMCO, OCIMF, INTERTANKO, INTERCARGO, InterManager, WSC och SYBAss Samlingsrekommendationerna från IACS Riktlinjerna kring hamnar och hamnsystem från IAPH På samma tema kan man också notera att kustbevakningen i USA nyligen släppte ett förtydligande för en "Executive order: Executive Order on Amending Regulations Relating to the Safeguarding of Vessels, Harbors, Ports, and Waterfront Facilities of the United States" som president Biden skrev under i februari. Det här är definitivt ett område som väcker mycket intresse och dessutom välförtjänt! En riktigt intressant rapport kommer från norska organisationen NORMA Cyber. De tittar på den aktuella hotbilden och tar upp GNSS/AIS-spoofing, OT-säkerhet, ransomware med mera. Vad tycker MSB om NIS2? När detta skrivs är förslaget till ny Cybersäkerhetslag (som ska implementera NIS2-direktivet) ute på remiss. En nyckelspelare kring dagens NIS-direktiv är MSB, vilket för övrigt utredningen föreslår ska fortsätta. MSB har publicerat sitt eget svar på remissen vilket var intressant att läsa. Jag ställer upp på i princip allt som de tycker till om, inklusive behovet av att samordna baskraven enligt lagen med de åtgärder som krävs när Säkerhetsskydd är aktuellt. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du spontanfunderingar direkt från S4-konferensen i Miami, GPS-störningar, SBOM-utmaningar, elaka typer som leker kurragömma i våra OT-system, en bokrecension, järnspindlar i våra HMI:er, en ny 62443-certifiering, framsteg för CRA & NIS2 och så en rolig trippeltest i hemmalabbet. (Japp, tre spännande men helt olika produkter möts lite otippat i ett gemensamt test...) 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! Många roliga tankar kring förra nyhetsbrevet Det är alltid extra roligt när det kommer spontana inspel från er läsare på innehållet i nyhetsbrevet. Kring förra utgåvan var det lite extra mycket och dessutom på lite oväntade delar av innehållet, vilket är ännu roligare! Även om du får nyhetsbrevet skickat till dig så är du förstås väldigt välkommen att bidra till samtalet som ibland uppstår på LinkedIn. Följ mig gärna där så hittar du enklare till kommentarerna. Alternativt ett mejl direkt till mig: mats@ot-sakerhet.se. Några av de kommentarer och diskussioner som uppstod förra gången resulterade i några av de texter längre ned i det här nyhetsbrevet. Tack för ert engagemang! Varning för rant! Ingen som följer mitt nyhetsbrev kan ha missat att jag till största delen är positiv till de lagkrav som är på gång från EU i form av NIS2, CRA, Maskinförordningen osv. Emellanåt hör jag argument i något föredrag eller läser någon artikel som sänder signalen att organisationer "drabbas" av dessa krav. Det är där jag vill markera att jag tänker lite annorlunda. Se det som en chans att ta ditt samhällsansvar utan att din organisation hamnar i ett sämre läge konkurrensmässigt. Det som samhället, i form av EU, säger är: Kära verksamheter, vi tycker inte ni tar hänsyn till de risker ni utsätter samhället för när ni slarvar med er säkerhet. Vi förstår att samhällets risker är svåra att väga in när ni tar ekonomiska beslut. Varsågod, nu får ni tillbaka de risker ni skapat för oss i en form som ni faktiskt kan använda; sanktionsavgifter, "framtvingade" kundkrav och personligt ansvar för er ledning. Lycka till! Jag håller med dem som tycker att det är synd att lagkrav behövs, men med lite klarsynthet ser man att det knappast finns några realistiska alternativ. Från mig skickar jag två tummar upp till EU för att man tar stora kliv framåt på området! Bra, fortsätt så! Man kan ha många åsikter om EU men i det här sammanhanget fungerar det verkligen. Hade enbart Sverige lanserat något i stil med NIS2 hade man förmodligen som land tyvärr skjutit sig själv i foten genom att "tvinga på" svenska kommersiella verksamheter en massa kostnader försämrar konkurrensförmågan och ger nyttoeffekter även för andra länder. I och med att EU är tillräckligt stort så sätter man konkurrensproblemet ur spel när hela den europeiska marknaden blir otillgänglig för den som inte bryr sig om CRA. Ursäkta denna lilla rant (vad heter det ordet på svenska?) men jag behövde få ur mig det... Var har de gömt sig? En varning från amerikanska CISA nyligen tycker jag var en bra påminnelse om en av mina egna käpphästar! I IT-världen är det stort fokus på ransomware, och det med rätta förstås! Det hörs emellanåt diskussioner kring när vi ska förvänta oss att se fler ransomware-attacker i OT-miljöer, vilket är en relevant fråga och som kan ha spännande filosofiska diskussioner om. Men... En fråga som jag tycker man glömmer bort i det sammanhanget är att vi kanske har helt fel bild av attackerna i vårt samhälle. Ett lyckat angrepp med ransomware är per definition väldigt svårt att missa, det är ju faktiskt hela idén! Tänk dig istället tanken att ALLA lyckade attacker som du hör om varje dag istället "bara" resulterade i att angriparen i tysthet skaffade sig en eller många bakdörrar för att snabbt och enkelt kunna återvända när det behövs för att skapa maximal oreda vid sämsta möjliga tillfälle. Det scenariot tycker jag alldeles för få oroar sig över i OT-världen! Med tanke på omvärldsläget borde det vara väldigt aktuellt för alla verksamheter vars produktion är viktiga för ett stabilt samhälle! Det kanske till och med borde till en lagstiftning för att få alla sådana verksamheter att fokusera mer på säkerhet med ett brett tänk kring risker? Men vänta... Det är ju precis det som vårt kära NIS2 är! Där använder man begreppet "allriskansats" för att trycka just på att vi ska tänka på alla risker som är relevanta - inte bara de som är populära i media! Hur ska du hitta en angripare som planterade en inloggning i ditt system för två år sedan? Här vill det nog till att sluta förlita sig på förebyggande skydd och börja tillämpa aktivt sökande i våra system efter tecken på vilande angripare... Direkt från S4! Så var det då äntligen dags för årets OT-höjdpunkt om du frågar mig, S4-konferensen i Miami Beach. Drygt 1000 förväntansfulla deltagare som njuter av framåtlutande och kloka presentationer på tre scener. Och det är ju det framåtlutande som gör S4 så rolig konferens, det är en uttalad strategi från arrangörens sida att man väljer innehåll som hjälper oss genomskåda hur framtiden kan tänkas se ut i branschen. Av de 1000 var vi hela 15 deltagare från Sverige vilket förstås var väldigt roligt i sig! Som vanligt är skallen full med mängder med intryck från presentationer, diskussioner och roliga möten med nya och gamla bekantskaper. De flesta presentationer kommer publiceras på YouTube senare under året så du kommer kunna ta del av en hel del i efterhand också. Om jag ska rekommendera några favoriter som jag tycker du ska hålla utkik efter så är det bland annat de här: Dale Peterson inledde själv under parollen "Believe" där han poängterade att vi faktiskt klarar ganska mycket i branschen om vi bara vill och tror på oss själva. Mest klarspråk fick vi (som vanligt) av Rob Lee från Dragos. Mycket uppfriskande! Ska du bara se en video från S4, så se den här! Som alltid är slutpanelen där Dale tillsammans med Ralph Langner, Megan Sanford och Zach Tudor reder ut kluriga frågor, både underhållande och fylld med klokskap. Om du bara ska se två videos från S4 så se den här också! Maggie Morganti på Rockwell berättade vad som hände bakom kulisserna i samband med att en riktigt allvarlig sårbarhet upptäcktes i händerna på en fientlig aktör. Imponerande samarbete mellan organisationer som annars är konkurrenter! Mest imponerande och rörande var nog Joe Marshall från Cisco Talos som berättade om de akuta insatser han gjort för att stötta Ukrainas elnät med synkroniserad tid trots pågående elektronisk krigföring som slår ut GPS-klockorna de använder. Se den om du börjat tappa hoppet om mänskligheten, Joe är en sann OT-hjälte! Dave Aitel från Cordyceps Systems slaktade begreppen "Secure by default" och "Software liability" på ett klokt och underhållande sätt. Vid sidan av alla presentationer pågår en massa andra aktiviteter. En som jag speciellt ser fram emot att höra resultatet från är "Vulnerability Management Pavilion" där 8 leverantörer visar hur de hittar, bedömer, presenterar och rekommenderar åtgärder för sårbarheter i en speciellt uppbyggd testmiljö. De 8 är aDolus, Finite State, Forescout, Framatome, Industrial Defender, Otorio, Runzero och Tenable. Jag har förstås pratat med många leverantörer och upptäckt en del nya spännande produkter som mycket väl kan tänkas dyka upp i hemmalabbet och i nyhetsbrevet framöver... Nästa år flyttar man hela konferensen till Tampa men förhoppningsvis kommer kvaliteten inte påverkas av att man kan ta in fler besökare! Storleken har betydelse! Ett litet förtydligande kring texten från förra nyhetsbrevet om att det finns en oro i en del organisationer som inte egentligen berörs av NIS2 för att de är i "fel" bransch men som skulle kunna hamna under NIS2 i alla fall för att de exempelvis satt upp solceller på taket. Det som behöver påpekas att det här bara är värt att oroa sig över om man är en tillräckligt stor organisation, över 50 anställda eller med mer än 10 miljoner Euro i omsättning. Är ni mindre så faller ni ut av det skälet. Floskeltoppen? Något som produkttillverkare i vår bransch är riktigt duktiga på är att ta meningsfulla ord och sedan använda/missbruka dem så mycket att de till slut förlorar sin egentliga mening och mest blir störande floskler. Ett sådant är tyvärr Zero Trust. Jag skriver "tyvärr" för jag tycker Zero Trust är värd ett mycket bättre öde än att ses som en säljfloskel! En fråga som dök upp från en läsare efter förra nyhetsbrevet var om det inte är dags att reda ut vad som är vad kring just Zero Trust inom OT-säkerhetsvärlden? Jag höll med, men insåg senare att jag faktiskt redan rotat runt i detta en del, främst i nyhetsbrev #45 och nyhetsbrev #43. Jag ska inte upprepa mig i onödan utan refererar till tidigare texter. Glöm förresten inte, apropå det, att det finns en sökfunktion på nyhetsbrevets sida. Jag använder den själv en hel del för att hitta bland mina egna gamla skatter... Det här är ett område där jag gärna skulle diskutera i mycket mer detalj med någon som kan Zero Trust bättre än jag! Men jag ska ändå konstatera jag fortfarande är positiv till tanken på Zero Trust inom OT-världen, även om man förstås får resonera lite annorlunda jämfört med IT. Mycket beror förstås på vilken typ av system vi talar om och vilka risker man är mest oroad över. I många situationer är det förmodligen dessutom helt enkelt orimligt att tänka sig något annat är blint förtroende, som att ett remote I/O inte skulle lita fullständigt på sin controller... I gränslandet mellan IT och OT finns det däremot gott om mycket rimliga platser att fullt ut tänka Zero Trust. Inte minst funktioner som är både viktiga och säkerhetsmässigt utsatta, som exempelvis remote access - som jag ju skrev om i förra utskicket. Här kan man ju dessutom dra nytta av "mänskliga" säkerhetsfunktioner som exempelvis eskorterade besök. Den svenska NIS2-utredningen skjuts fram! Ursäkta min tendens till click-bait i rubriken, men det är faktiskt i alla fall delvis sant. Den svenska utredningen som tittar på bland annat hur NIS2 och CER ska implementeras i svensk lag har fått utökad tid på sig för vissa delar av arbetet. Tyvärr då för några av de mest spännande delarna, nämligen hur man ska få direktiven att samsas med två andra kritiska svenska lagar, Säkerhetskyddslagen och Offentlighets och Sekretesslagen. Den första (och stora) delen av arbetet är ju faktiskt avrapporterad i ett massivt dokument på 522 sidor och det finns en del matnyttigt kring även Säkerhetsskydd i den delen. Efter en första genomläsning har jag konstaterat att det mesta följer direktivet väldigt väl (vilket ju faktiskt var syftet med det nya direktivet...) men jag har några reflektioner och saker som jag tycker är intressanta: Man rekommenderar att NIS2 implementeras i en lag kallad "Cybersäkerhetslagen". De flesta kommuner, regioner och myndigheter kommer omfattas av lagen. Alla universitet och högskolor omfattas. Personer i styrelser (!) får tillsammans med VD ett personligt ansvar för cybersäkerheten och kan i grova fall via domstol förbjudas agera i organisationen om säkerhetsarbetet inte fungerar. Inga krav på att använda certifierade produkter förrän sådana krav kommer från EU. Man struntar i att direktivet sätter 17:e/18:e oktober 2024 som startdatum och föreslår istället 1:a januari 2025. Det är man själv som organisation som ska avgöra om man omfattas av Cybersäkerhetslagen och i så fall anmäla sig till rätt tillsynsmyndighet. (Lite som säkerhetsskyddslagen alltså.) Det finns ingenting specifikt skrivet om OT-system, industriella system eller något i den stilen. Man talar om Cybersäkerhet men jag tycker nog inte det finns något tvivel om att alla former av Cybersäkerhet avses oavsett om det är IT eller OT. Man trycker speciellt på att organisationen i sin helhet omfattas av kraven även om det bara är en del av verksamheten som egentligen berörs. Det här är förmodligen klokt, det hade blivit en del kluriga gränsdragningar annars men det gör det där jag kommenterade i förra nyhetsbrevet om gränsdragning för exempelvis stora organisationer som producerar lite el verkar man inte ha identifierat som ett problem. Inte heller den enorma otydligheten kring hur kemikaliebranschen ska avgränsas. Som förväntat trumfar säkerhetsskydd kraven i Cybersäkerhetslagen. Det betyder även att vissa uppgifter eventuellt inte kan lämnas ut kring exempelvis en NIS2-incident. MSB pekas ut som sammanhållande i de flesta avseenden men ett antal nya tillsynsmyndigheter läggs till utöver dagens. På det hela är jag väldigt positiv till resultatet, inte minst för att det är nära till direktivets tänk! Vi ska komma ihåg att allt ovanstående är rekommendationer från utredningen men jag har svårt att se varför det i slutändan inte skulle bli som de föreslår? Det var synd att man inte redde ut fler av frågetecknen i direktivet men det kommer lösa sig över tid! Eftersom missad anmälan om att man omfattas av lagen finns bland anledningarna till att utdela sanktionsavgifter så blir det viktigt att verkligen göra en riktig analys även om man inte tror att man omfattas. Det kan bli helt avgörande att man kan visa på en riktig argumentation och ett formellt beslut av styrelsen. Det finns gott om klurigheter som gör detta till en bedömningssport och då behöver man vara övertydlig... Nu är CRA på gång! I förra nyhetsbrevet skrev jag om utmaningarna med att hålla EUs lagtexter enhetliga med tanke på att de översätts till 24 olika språk. Det har cirkulerat ett rykte om att CRA kommer skjutas fram till hösten just på grund av att den inte hinner bli översatt. Sedan tidigare är det känt att just översättandet generellt är en trång sektor för EU. Men det verkar vara ett falskt rykte eller åtminstone överdrivet! Den 12:e Mars var CRA nämligen uppe i Europaparlamentet, och helt enligt planerna så röstades det JA till förslaget. Om du är riktigt nördig kan du se omröstningen här. (Det är snabba ryck, ca 30 sekunder för omröstningen även om det efteråt blev lite stök kring någon som uppträtt illa under omröstningen.) Det här betyder inte att CRA är färdigt, det är ett antal ringar till som det ska hoppas igenom, somi princip bara är formaliteter även om det kommer ta ett antal veckor. En ny bekantskap! (Del 1) Beckhoff är ett välkänt tyskt märke i automationsbranschen med en lång historik. Jag har förstås stött på dem hos mina kunder, men jag hittills inte haft så mycket egen erfarenhet "hands-on". Det har ändrat sig nu, när en C6017-0020 - "Ultra-compact Industrial PC" dök upp i posten och förstås monterades upp i hemmalabbet direkt. Hade det handlat om utrustning från en annan leverantör hade jag kallat den en "PLC", men som du kommer se är det här lite annorlunda... Det första intrycket var imponerande - den har den där härliga massiva tyngden av solida material och rejäla kylflänsar. På pappret borde prestandan vara hel okej också; 4-kärnors Intel CPU, 8 GB RAM, 40 GB SSD och 4 stycken portar med Gb Ethernet. Lite senare visade det sig att den dessutom var extrautrustad med Beckhoffs inbyggda mini-UPS. En snabb test visade att den "på tomgång" klarar ungefär 5 sekunders störning i strömmatningen vilket gör att man kan undvika onödiga stopp vid korta störningar. Bra där! Om man är van vid PLC:er från andra tillverkare kan Beckhoffs tänk kännas ovant. Deras automationsprogramvara, "TwinCAT", går att köra på vilken dator som helst. Men vill man ha en robust hårdvara som tål tuffa miljöer så installerar man mjukvaran på en av deras datorer, liknande den som jag fick fingrarna på. Beckhoff är för övrigt också kända för att de skapade fältbuss-protokollet "EtherCAT" som numera är en fristående IEC-standard som stöds av mängder av tillverkare. Beckhoffs utrustningar är rent principiellt "vanliga" datorer som i de flesta fall kör Windows eller Beckhoffs variant på FreeBSD, TwinCAT/BSD. I och med det så går det enkelt att kombinera PLC-applikationer med helt andra programvaror. Konfigurationen sker via ett lokal webbgränssnitt vilket gör det enkelt att göra rätt. Jaha, Windows tänker du kanske? Men Beckhoff har inte bara slängt in Windows lite hur som helst utan har sett till att det beter sig på ett sätt som anstår en "PLC". Ett exempel på det är deras "Write filter" som gör att förändringar i systemet inte blir bestående utan att man lätt kan "backa" till en känd konfiguration. BSD-varianten har Jails och kan hantera både Docker-containers och virtuella system samtidigt som man kör TwinCAT-runtime. Riktigt coolt! Framöver kommer det ske en gradvis övergång från Windows till Linux, vilket är en intressant trend... Hårdvaran finns i en massa spännande varianter som jag verkligen kan se tilltala det kreativa automationsfolket. Det finns allt från de ultrakompakta, där den variant jag testar ingår, hela vägen till brutala serverlösningen "Control cabinet industrial server" med 40 CPU-cores. Vill man exempelvis ha direktanslutning till många nätverk kanske mini-varianten på bilden passar, med 9 ethernet-portar!? (Det är alltså inte en inbyggd switch, utan 9 stycken separata interface!) Jag hade hoppats skapa ett testprojekt i TwinCAT med någon lämplig testmiljö i FactoryIO, men jag har helt enkelt inte haft möjlighet att lägga den tiden. Men jag kan direkt konstatera att både hårdvara och mjukvara imponerar, allt tuffade igång utan problem så jag får be att återkomma om programmerandet i framtiden! Det ser i alla fall mycket lovande ut. En cool möjlighet är att man kan installera hela utvecklingsplattformen direkt på "PLC:n", tack vare att den ju faktiskt har ett "normalt" operativsystem. Om du har erfarenhet av att bygga system med TwinCAT vill jag väldigt gärna höra om dina erfarenheter! Jag har närmast lite mer "exotiska" planer för att testa vad hårdvaran i sig går för. Testerna kommer dessutom ske tillsammans med ett par helt andra spännande produkter, en som varit med tidigare i nyhetsbrevet och en nykomling i labbet. Fler nya bekantskaper... (Del 2) När jag ändå hade tillgång till den imponerande lilla Beckhoff-datorn smidde jag lite annorlunda planer för att se vad hårdvaran i sig går för. Om du läste min text om Cyolo i förra nyhetsbrevet så vet du att jag gillar deras lösning för säker fjärråtkomst i OT-system. Min tanke nu var att se om man skulle kunna installera hela deras funktionalitet i en hårdvara som går att placera ute i ett minimalt apparatskåp? Planen blev alltså att komplettera min existerande Cyolo-installation i hemmalabbet med ytterligare en Cyolo IDAC-server som körs på Beckhoffs lilla kraftpaket - skulle den räcka till? Det blir dessutom ett test av klustringsfunktionen i Cyolo - är den så enkel att få till som de påstår? Spännande redan där men det är nu som jag kan presentera ytterligare en nykomling i hemmalabbet... Det danska företaget Bifrost Connect har också skapat en lösning för säker fjärranslutning, men de har valt en väldigt annorlunda målgrupp och metod jämfört med Cyolo. Det de siktar in sig på är nämligen att komma åt konsol-anslutningar på system via HDMI, tangentbord, mus eller via serieport. De gör det genom att kombinera en molnbaserat tjänst och en batteridriven (!) enhet som fixar den fysiska anslutningen. I det enklaste fallet ansluter du Bifrost-enheten via HDMI och USB för att skapa en simulerad skärm, tangentbord och mus. Batteriet räcker länge men laddas när enheten är ansluten till en USB-port. Kommunikationen mellan enheten och molntjänsten går via en inbyggd 4G-anslutning eller WiFi. De använder krypterad WebRTC som skyddar kommunikationen hela vägen från molntjänsten till enheten, och kan använda TURN-servrar som proxy om det behövs. Det här lät ju väldigt intressant så jag fick låna ett par enheter av Bifrost Connect. För att göra testet lite mer intressant så anslöt jag en Bifrost-enhet till Beckhoff-datorn dagen innan jag åkte till S4-konferensen... Kommer det funka bra även från andra sidan Atlanten? Det känns som ett bra test, eller hur? Som förväntat vaknade jag jetlaggad, alldeles för tidigt första morgonen, så varför inte använda tiden till att börja installera Cyolo? Jag tog och installerade om Beckhoff-enheten helt, med Ubuntu-linux som jag sedan installerade mjukvaran Cyolo på. Det låter ju enkelt tills man tänker på att jag behöver hantera datorn i UEFI/BIOS-läge för att välja ny boot-disk mm vilket kräver åtkomst till skärm och tangentbord.... Perfekt för Bifrost Connect med andra ord! Redan innan det var dags för frukost hade jag redan installerat Ubuntu och startat Cyolo. Smidigt och enkelt utan några större klurigheter! Jag ska passa påpeka att den nya Cyolo-servern uppförde sig perfekt. Den bildade helt automatiskt ett kluster med den tidigare IDAC-servern och dök upp i administrationsverktyget precis som utlovat. Otroligt imponerande i sin enkelhet! IDAC-servern vill egentligen ha en större disk än vad som finns installerad i min lilla Beckhoff-dator, men för enklare användning fungerar det hur bra som helst! Snyggt jobbat Cyolo! Beckhoff-datorn å sin sida gör också precis allt den ska och med imponerande prestanda och enkelhet! Nu har jag inte testat att dra nytta av att den har 4 nätverksinterface, men jag ser ingen anledning till att det skulle strula. Snyggt jobbat Beckhoff! Och när det gäller Bifrost Connect så märktes inte avståndet på något vis, webbgränssnittet kändes i princip som att sitta framför bildskärmen hemma! Förutom alla grundläggande funktioner, som behörighetsstyrning av vem som får ansluta till vilken enhet och loggning av alla aktiviteter, kan de även göra en del andra trick som jag inte haft möjlighet att utforska ännu, men som låter intressanta: Du kan koppla två enheter till varandra, "rygg mot rygg", över Internet vilket skapar ett slags VPN-lösning mellan dem. Enheterna har 6GB lagring som man kan presentera som en USB-disk till det anslutna systemet Man kan ansluta till en ren konsolport, RS232 eller USB. Användbart för nätverksutrustning, OT-prylar och annat med sådan anslutning. Med två enheter kan man tunnla en serie-ansluten konsolport (RS232 eller USB) på distans. Det finns en reläport så att man kan styra strömmen till den styrda enheten och därmed göra "hårda" omstarter. Det finns en ethernet-port vilket gör det möjligt att göra en "lokal" SSH-anslutning från Bifrost-enheten. Om man vill ha handgriplig kontroll över hur uppkopplingar sker så finns enheten i en version som kallas "Attended Access". Det är en listig lösning där den lilla displayen på enheten visar en sifferkod som man ger till den som ska koppla upp sig. En smart kombination av tvåfaktor-inloggning och operatörs-godkännande! De har en ovanligt vettig beskrivning av säkerhetsaspekterna i deras lösning som är värd att ladda ner och titta på. Det känns lite fel att jämföra Cyolo och Bifrost Connect. De har förstås likheter, men de problem som de försöker lösa är ganska olika. Bägge gör det dock väldigt bra, och det ska bli intressant att utforska kombinationen av dem båda lite mer! Jag ser dem nämligen inte som konkurrenter, men som intressanta komplement till varandra. Blir sårbarhetshantering ännu enklare med dioder? En fråga som dök upp efter min text i förra nyhetsbrevet om att förenkla sårbarhetshantering med en genomtänkt segmentering var om inte nätverksdioder kunde spela en viktig roll i detta? Jag tyckte det var en spännande fråga som förtjänar lite extra uppmärksamhet... Jag ska direkt säga att jag inte har använt nätverksdioder eller CDS-lösningar med just sårbarhetshantering som mål, men det är ganska uppenbart att det kan ge stora fördelar - även om det i många fall kanske inte ens är huvudsyftet med att införa den typen av teknik. Mest uppenbart blir det förstås om man överväger en ren nätverksdiod, där ett system som är på "uppströms-sidan" av dioden är fysikaliskt omöjligt att nå från andra sidan. Det är ju faktiskt hela vitsen med dioden och ungefär så bra skydd man någonsin kan få mot nätverksburna angrepp... Men även system "nedströms" kommer i de flesta fall bli svårare att angripa men det beror förstås till en viss del på vilken typ av filtrering som sker i dioden, vilket nätverksprotokoll som är aktuellt och naturligtvis vilken typ av angrepp man vill undvika. När det gäller CDS-lösningar blir det alltid lite mer av en bedömningssport, men eftersom hela tanken med en sådan lösning är att "plocka isär" kommunikation i sina beståndsdelar kommer de flesta angrepp i praktiken bli väldigt svåra att få igenom en CDS-gateway. Förutom att skydda mot angreppet blir det i de flesta fall även ett visst skydd mot skadeverkningar även om angreppet faktiskt skulle lyckas. Stöld av information eller manipulation av en process är ju definitionsmässigt omöjligt i "fel riktning" genom en diod. När det gäller förenkling av sårbarhetshantering bör rimligen diod-liknande teknik vara en hit! I de flesta fall borde analysen av en ny sårbarhet bli enklare och det borde i slutändan även resultera i färre panik-uppdateringar! Nu har jag faktiskt läst den... Jag slog ett slag för Andrew Ginters senaste bok redan i nyhetsbrev #57, men då hade jag inte läst den. Nu har jag ändrat på det och kan komplettera med lite egna tankar kring innehållet... Andrew är kanske mest känd från den podcast han gör hos sin arbetsgivare Waterfall Security. Det går inte att missa att det finns en väldigt tydlig koppling till Waterfalls produkter i boken men det gör ingenting, eftersom resonemangen håller och det är dessutom bra produkter! Boken "Engineering-Grade OT Security - A managers guide" verkar fortfarande gå att få skickad gratis från USA eller köpa direkt från Amazon. Jag rekommenderar att du läser boken själv, men jag ska i alla fall återberätta några av alla de tankar som jag tycker han fångar på ett bra sätt i boken: Man hör ofta om skillnaderna mellan säkerhet inom IT och OT men som Andrew mycket riktigt påpekar är det nästan lika stora skillnader inom OT-säkerhet mellan olika branscher! Visst är Safety viktigt överallt, men i vissa verksamheter är det helt avgörande medan andra, med rätta, fokuserar bredare. I vissa branscher finns massor av känslig information i OT-systemen och i andra inte alls. Viktigt att ha med sig när man diskuterar filosofier inom OT-säkerhet! Boken knyter an till de tankar som blivit moderna på senare år, en återgång till att hantera vissa av de risker som orsakas av moderna OT-teknik med hjälp av säkerhetsåtgärder från helt andra områden, exempelvis mekaniska hinder för allvarliga konsekvenser. Här finns mycket att hämta för att få digital teknik och fysiska processer att gå mer hand i hand... På samma tema har Andrew en bra diskussion kring den ibland heta debatten om vad en "OT-säkerhetsincident" egentligen är. Man hör ofta att det är ovanligt med "riktiga OT-incidenter" vilket avser att de flesta produktionsstörningar beror på ett för stort beroende av IT-system snarare än att en hacker manipulerat en PLC. Det är en åsikt som jag håller med om men det är egentligen inte så intressant om man trots allt är intresserad av att hålla sin produktion igång! Det sätter också fingret på att det kan finnas IT-system som behöver skyddas som om de var OT-system, ett jobbigt sätt att tänka för en del organisationer... Ett begrepp som jag arbetat med inom exempelvis kärnkraftsvärlden är det som tidigare kallades "Dimensionerande Hotbeskrivning", DHB och som numera oftast får heta DAF istället "Dimensionerande Antagonistisk Förmåga". I boken talas det om cDBT, "Cyber Design Basis Threat" vilket är samma sak men med fokus just på cyberhot. Det här är ibland något som man får av Säkerhetspolisen om man är en säkerhetsskyddad verksamhet, men det är också något man kan definiera för sin egen verksamhet. Det handlar helt enkelt om att definiera vilka typer av attackförmågor som man ska kunna hantera. Detta är något som jag ofta rekommenderar mina kunder att ta fram eftersom det skapar en enhetlig bild av vad man ska klara av. Det många inte tänker på är att det faktiskt också är en definition av "Risktolerans", det där kluriga begreppet som jag sett få faktiskt göra något bra med. Om man i en cDBT/DAF definierar vilka förmågor och hot man ska klara av så har man ju faktiskt också sagt att "allt annat är det okej att vi inte kan stå emot". Det här kan vara en jobbig diskussion, men oj så viktig! Ordet "Sårbarhet" orsakar ibland missförstånd. De flesta tänker nog på en brist i en mjukvara som går att fixa med en patch. Men i många sammanhang betyder ordet mycket mer, det är vilken svaghet som helst, i vad som helst, som möjliggör något slags angrepp. Viktig skillnad att ha med sig! Jag träffade Andrew under S4-konferensen så jag kunde både tacka för en bra bok och bekräfta för honom att jag håller med om hans syn på att OT-säkerhet måste utformas på ett sätt som drar nytta av skydd i både den fysiska processen och "cyberdelarna". Det är tyvärr alldeles för vanligt att man försöker lösa utmaningarna "på samma sätt som IT gör" och helt missar möjligheterna med åtgärder i hur processen är utformad! Det gäller i synnerhet de allra värsta konsekvenserna som man helt enkelt vill bygga bort! Järnspindeln är här - se upp med dina HMI:er! Ett nytt spännande forskningspapper beskriver hur man skapat en ny klass skadlig kod riktad mot PLC:er via webb-baserade HMI:er. Det är Ryan Pickren, Tohid Shekari, Saman Zonouz och Raheem Beyah på Georgia Institute of Technology som ligger bakom arbetet. De drar nytta av att moderna PLC:er ofta har en inbyggd webb-server för att bygga HMI-bilder med. Det tillsammans med den dåliga idén att låta "kontors-datorer" komma åt HMI-bilderna direkt från PLC:n skapar en intressant möjlighet att manipulera PLC:ns beteende. (Alternativt att "OT-datorer" får surfa på Internet, vilket är en ännu sämre idé...) Jag ska inte försöka mig på att sammanfatta metoden mer än så, utan rekommenderar en genomläsning. Om du är någorlunda hemma i webb-teknik så går det enkelt att förstå denna unika metod. Spännande! Kul trend! Det börjar röra på sig så smått bland tillverkarna av OT-produkter när det gäller säkra utvecklingsrutiner. Ett tecken på det är ett ökande intresse för certifiering på det här området och då ofta IEC 62443-4-1. Ett lite extra kul exempel är varumärket Anybus som ingår i den svenska HMS Networks. (Du kanske minns min test av en Ewon-enhet i nyhetsbrev #57?) De har precis annonserat att de certifierat sig på mognadsnivå 3 av IEC 63443-4-1! Nivå 3 är alltså den näst högsta nivån, det finns från 1 till 4. (Detta trots att -4-1 bygger på CMMI-DEV som ju har fem nivåer. I -4-1 slår man ihop nivå 4 och 5 till en nivå...) Med tanke på att produkter från Anybus ofta byggs in produkter från andra tillverkare så blir det förstås avgörande att de håller minst lika hög nivå av säkerhet som sina direkta kunder! Ett viktigt steg förstås också inför de kommande CRA-kraven. Grattis HMS Networks och bra jobbat! Konsten att säga nej Jake Brodsky har skrivit en kort text om det viktiga med att kunna säga nej. En konst som kan tyckas vara enkel, men där det ofta handlar om att kunna ta en diskussion kring vad som är viktigt i den svåra avvägningen mellan att skydda verksamheten och att utveckla den. Det här är något jag stött på i alla branscher jag arbetat med, allt från kryssningsfartyg till verktygstillverkning. Det handlar i slutändan om att säkerställa att rätt beslut tas av rätt person baserat på rätt information. För att vi säkerhetsmänniskor ska bli respekterade som relevanta personer att ha med i en diskussion finns det några saker där jag tycker vissa kollegor i branschen ibland går lite för långt: Ta inte säkerhet personligt! Vi tycker det är viktigt med säkerhet, men om du blir upprörd av en diskussion så kommer du förlora den! Säkerhet har inget egenvärde! På samma sätt som att ingenting är 100% säkert måste vi vara bekväma med att navigera kompromisser där både säkerhet och nytta "får sitt". Säkerhet är inte motsatsen till nytta! Säkerhetsåtgärder blir mycket enklare att sälja in om de presenteras som möjliggörare av nya sätt att arbeta som man inte "vågat" tidigare. Tack för den, SÄPO! En av mina käpphästar är att det gått lite väl mycket inflation i användning av säkerhetsskydd i vissa branscher. Samtidigt ska jag direkt erkänna att det är ett svårt område att bedöma och applicera, i synnerhet när det handlar om OT-säkerhet. SÄPO har nu skapat ett stöddokument för att hjälpa organisationer att förstå vilka delar av verksamheten som kan vara att betrakta som säkerhetskänsliga. Jag hade kanske hoppats på lite mer klarspråk, men vi fick i alla fall svart på vitt att dagis och begravningsbyråer inte är säkerhetskänsliga. Men visst, det är faktiskt varje organisations eget ansvar att bedöma detta och då ska inte SÄPO skriva ett facit. Läs speciellt avsnitt 3, "Skadekonsekvenser på nationell nivå", det är det viktigaste i mina ögon. Det här kommer ju dessutom bli ett extra intressant område att följa framöver i och med inträdet i NATO. Har du tid? Om du gillade min lilla test av tidsprogramvaran Timekeeper i förra nyhetsbrevet så kanske du gillar Jörgen Städjes text "För Sverige i tiden". I hans artikel nämner han även sajten gpsjam.org som ger en intressant bild av hur mycket störningar det är kring GPS-systemet och var i världen det sker. Väl värt att ha med sig i bakhuvudet när man pratar om tjänster som hanterar tid eller plats! Team82 fortsätter i samma stil! Clarotys forskargrupp Team82 kör vidare i sin kampanj att vända ut och in på OPC UA. Nu är artikelserien uppe i del 9, där de visar hur de hittade problem i Softings integrationsserver "SIS". En intressant djupdykning med videos och allt: Om du missat någon av de tidigare delarna så finns de förstås tillgängliga: OPC UA Deep Dive (Part 1): History of the OPC UA Protocol OPC UA Deep Dive (Part 2): What is OPC UA? OPC UA Deep Dive (Part 3): Exploring the OPC UA Protocol OPC UA Deep Dive Series (Part 4): Targeting Core OPC UA Components OPC UA Deep Dive Series (Part 5): Inside Team82’s Research Methodology OPC UA Deep Dive Series (Part 6): A One-of-a-Kind Exploit Framework OPC UA Deep Dive Series (Part 7): Practical Denial of Service Attacks OPC UA Deep Dive Series (Part 8): Gaining Client-Side Remote Code Execution Vad finns i dina mjukvaror? Det är mycket snack i branschen kring SBOM (Software Bill Of Materials), alltså innehållsförteckningar för mjukvara som bland annat EU via CRA kommer kräva av alla mjukvaruleverantörer. Det här är fortfarande en väldigt omogen värld där det finns en massa kluriga utmaningar, men där det också sker en massa spännande framsteg. Om du är fundersam över alla utmaningar och vad märkliga akronymer som PURL, spdx, SASBOM, CBOM och CycloneDX betyder så kan jag rekommendera ett avsnitt av Dataföreningens "Prata EU Cyber Resilience Act med oss". Olle E Johansson och Per-Erik Eriksson berättar om det senaste i den här världen. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! En massa cool teknik blir det den här gången - inte mindre än två tester av riktigt trevlig teknik, direkt från hemmalabbet! Jag filosoferar kring hur man kan spara en massa administrativ tid genom klok segmentering. Det blir mycket snack om EU-lagar också, det är verkligen ett hett område just nu! 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! Nya tider! Min högst personliga åsikt är att någonting hände vid nyår. Helt plötsligt pratar alla organisationer om NIS2. Är det så enkelt att det är ny budget och nya mätetal eller har poletten trillat ner ute i landet? I vilket fall som helst har tillströmningen av nya spännande kunder som vill ha stöd i gränslandet där NIS2 möter OT-säkerhet verkligen exploderat. Jag stöter på alla tänkbara varianter på hur man ser på lagstiftningen och på hur den egna organisationen "drabbas". Allt från den väldigt sunda inställningen "Vi omfattas inte av NIS2 men våra kunder gör det - låt oss kapa åt oss konkurrensfördelar genom att bli duktiga på säkerhet" till struts-taktiken "Nä, det verkar lite konstigt att vi skulle vara samhällsviktiga så det måste vara fel!". Om man inte är så intresserad av EU, lagstiftning eller kravstandarder kan tyckas vara väldigt mycket snack om lagstiftning nu, inte minst i det här nyhetsbrevet! Men jag tror faktiskt kombinationen av NIS2, CRA och Maskinförordningen kommer ha en enorm effekt på hur vi arbetar med risk och säkerhet kring våra OT-system. Och ALLA kommer påverkas även om man inte själv faller direkt under någon av lagstiftningarna. Som vanligt kommer vi förmodligen överskatta effekten på kort sikt, men samtidigt underskatta den på lite längre sikt. Apropå längre sikt så meddelade justitieministern i Nederländerna nyligen att man inte kommer hinna klart med NIS2 och CER till deadline den 17:e oktober. Några dagar senare annonserade det danska försvarsministeriet liknande problem. Andra länder, med Finland i spetsen, ligger väldigt bra till. Vi får se hur det går i Sverige, utredningen har sin deadline i slutet av februari och då kanske planen framåt klarnar lite? Det är många steg kvar tills allt är klart... Samtidigt förändras sättet man bygger system på ett ganska radikalt sätt. Även här kommer det ta lite längre tid än vad vi tror (eller hoppas) men det kommer! Se exempelvis texten längre ner om den möjliga trenden att lämna OPC UA till fördel för MQTT, en detalj kan tyckas - men ändå. Ett annat exempel är det där läskiga begreppet "IT/OT-convergence" som många tror bara handlar om teknik, när det stora skiftet snarare (om du frågar mig) kommer handla om människor och arbetssätt. Sakta men säkert ser vi människor som är vana vid arbetssätten inom IT börja närma sig OT-världen och i takt med det kommer nya produkter - exempelvis är det äntligen dags för virtuella PLC:er, helt nya utvecklingsverktyg (läs exempelvis den här texten av Peter Kurhajec om Siemens SIMATIC AX) och nya sätt att bygga mjukvarudefinierade nätverk (exempelvis Veracitys nya nätverksappliance). Det här gör att vi i OT-säkerhetsbranschen verkligen behöver hänga med i utvecklingen för att inte uppfattas som de gamla vanliga stoppklossarna som säkerhetsfolk lätt blir. Jag skrev om detta för några utgåvor sedan, när jag jämförde säkerhetsarbete med teatersport. Det gäller verkligen att arbeta in de nya lagkraven och de nya arbetssätten i detta. Om säkra system ska möjliggöra nya verksamheter och affärer behöver vi sluta svara "Nej, det är för osäkert" eller "Nej, det får man inte enligt NIS2" och istället säga "Ja, om vi löser X och Y för att möta CRAs krav" eller "Ja, men då behöver vi byta till en modern arkitektur". Det är spännande tider som väntar oss framöver! ...och apropå tid... Ur led är tiden! Den klassiska frasen fick vi av Shakespeare i Hamlet, men det var nog inte våra datorers klocksynkronisering han tänkte på. I takt med att tiden spelar en allt viktigare roll för många delar i våra OT-system blir det också viktigare att hålla koll på klockorna i alla system. De behöver gå rätt och de behöver gå lika. Det är inte helt ovanligt att man använder någon form av GPS-baserad mottagare för att få en bra referensklocka att utgå ifrån och sedan sprider tiden i nätverket med exempelvis NTP-protokollet. På senare tid har det blivit väldigt uppenbart att GPS-systemet är sårbart för attacker, både för navigerande flygplan och för dem som vill ha rätt tid! På samma sätt kan man tänka sig att välkända tidskällor på Internet skulle utsättas för attacker. Keysight är ett företag vars produkter jag testat och skrivit om förut, det har exempelvis varit nätverkstappar eller aggregationsswitchar för att samla in kopior av all nätverkstrafik. I nyhetsbrev 29 skrev jag om deras brutala nätverkstestare BreakingPoint. Det totala produktsortimentet innehåller en närmast bisarr mängd coola lösningar. Den här gången har jag tittat på en produkt som heter Timekeeper. Timekeeper gör precis vad namnet hintar om, den håller koll på tiden från ett antal valfria källor. Kvaliteten på tids-informationen analyseras hela tiden (!) och kan presenteras i grafer och statistik. Om någon tidskälla avviker på ett orimligt sätt eller om någon signal visar tecken på att vara spoofad så kommer den att ignoreras när "rätt tid" bestäms. "Den rätta tiden" kan sedan spridas på nätverket via NTP. I exemplet nedan ser du en graf över hur det såg ut i mitt hemmalabb. Timekeeper är vid pilen, och ovanför finns de NTP-källor som är konfigurerade och nedanför är några av de klienter som hunnit ansluta. NTP i tillsammans med Timekeeper är en imponerande kombination. Timekeeper är löjligt enkel att få igång och avvikelserna i tiden ligger på några tusendelar av en sekund bara genom att använda öppna NTP-källor på Internet. Om man vill ansluta egna GPS-mottagare eller PTP-källor så finns stöd för det också. Underskatta inte behovet av bra tid, det uppstår väldigt märkliga fel när tiden är dåligt synkad... Jag avslutar med en tråkigare nyhet, nämligen att Dave Mills som uppfann NTP nyligen gick ur tiden (!) vid 85 års ålder. Jag skickar en tacksam tanke till honom och alla andra pionjärer som lade grunden till mycket av det vi tycker är självklart, men fortfarande spännande, idag. Mindre slit genom att göra mer? OT-Säkerhet är ett område som ger oss många spännande utmaningar. Men ibland känns det frustrerande att de säkerhetsåtgärder vi tar inte ”räcker hela vägen”. En anledning till det tror jag kan vara att man försöker implementera en åtgärd åt gången istället för att se hur olika åtgärder kan förstärka varandra. Ett intressant exempel på två områden som verkligen kan förstärka varandra är sårbarhetshantering och segmentering. Med sårbarhetshantering menar jag i det här sammanhanget det håra arbete som man står inför om man ska försöka hänga med i alla nya sårbarheter som annonseras för att kunna analysera hur de slår mot alla komponenter man har och i vilka sammanhang som det faktiskt är värt att störa produktionen för att lägga på en säkerhetsrättning. Det är ju här som skillnaderna mot IT-världen kanske blir som allra tydligast för många. När jag pratar om segmentering tänker jag främst på arbetet att dela upp nätverk, dataflöden och system inom OT-miljön. Att separera ”IT” och ”OT” förutsätter jag är hanterat även om mitt resonemang här skulle kunna fungera lika bra på den uppdelningen. För båda dessa utmaningar blir en absolut förutsättning för att kunna göra någonting alls att man har tillgång till pålitlig information om vilka komponenter man har, hur de sitter ihop och hur dataflöden mellan dem ser ut. Det betyder (som vanligt) att vi är beroende av att vi har verktyg och processer som hjälper oss med detta. Att löpande bedöma vilken risk som nya sårbarheter orsakar för organisationen är ett tufft jobb av många skäl. Ett sådant skäl är att även en enkel systemmiljö har många komponenter som var för sig kan påverka helheten på kluriga sätt. Det är här som kopplingen till segmenteringsarbetet blir en möjlighet att göra arbetet mycket enklare. Arbetsordningen för att bedöma en ny sårbarhet kan se ut så här: Bevaka alla relevanta källor för att fånga upp alla nya sårbarheter som eventuellt kan vara aktuella någonstans För varje sårbarhet: Förstå sårbarheten (Vad påverkas, hur och under vilka förutsättningar?) Identifiera alla komponenter i vår miljö som möjligen berörs av sårbarheten För sårbarheten - bedöm varje komponent: Går sårbarheten att utnyttja i just denna komponenten på det sätt den används hos oss? (Med tanke på andra skydd och arkitekturen) Hur påverkas komponentens pålitlighet om sårbarheten utnyttjas? Hur påverkar verksamhetens risk av att komponenten inte går att lita på? Vilka skydd finns som kan minska verksamhetens risk? (Härdning, segmentering etc?) Ett av problemen med det här resonemanget är att alla komponenter både blir en potentiell sårbarhet OCH samtidigt en del av skyddet mot angrepp. Det gör att analysen blir väldigt komplex! Jag föreslår att vi istället vänder resonemanget på huvudet och utgår ifrån att alla komponenter alltid kommer vara sårbara och istället fokuserar på att omgärda dem med tydliga säkerhetsåtgärder. Då behöver vi bara bedöma hur säkerhetsåtgärderna eventuellt påverkas av den nya sårbarheten medan vi vi med flit struntar i allt som inte är exponerat. Det låter ju onekligen lite enklare… Om du tycker det här låter som en jobbig kompromiss så har du förmodligen rätt. Att jag tycker den i många fall är okej är att man i slutänden ändå väljer att skjuta upp patchningen på grund av något annat skydd, exempelvis just segmenteringen. Med det tänket blir bra säkerhetsåtgärder extremt avgörande och det är här kopplingen till segmenteringsarbetet dyker upp. Jag tänker mig att vi gör en ”riktig” segmentering i still med vad IEC 62443 del 3 pekar på, och använder säkerhetszoner (”Zones” i standarden) som sammanbinds av det standarden kallar ”Conduits”. När folk pratar om segmentering brukar det lätt bli en ren nätverksfråga och det är här nästa nyckel till mitt resonemang finns. Tricket ligger i att vara så pass systematisk i designen att man faktiskt har koll på vad som exponeras i respektive system. Att göra det ur ett nätverksperspektiv är inte så svårt, det handlar ofta om att öppna portar i något slags brandvägg. Utmaningen ligger i att hantera det som exponeras! Ett exempel på varför det här är viktigt: Det vanligt att jag stöter på organisationer där man noggrant segmenterat sitt nätverk men att man samtidigt tillåter Windowsdatorer att prata ganska fritt över segmenteringsgränserna för att komma åt filer, använda Active Directory, skriva ut osv… Det innebär att man segmenterat nätverket på ett sätt, men ur ett Windowsperspektiv så ser segmenteringen väldigt annorlunda ut! Det betyder att en Windows-tjänst som exponeras i en säkerhetszon potentiellt ”drar med sig andra säkerhetszoner i fallet”. Det går ofta inte att undvika men då ska vi ha koll på det och bygga vårt riskresonemang utifrån det! Exempelvis undvika att hamn i situationer där en Windows-dator med flera nätverksanslutningar används för att knyta ihop olika nätverk eller säkerhetszoner, då har en redan onödigt stor säkerhetszon blivit ännu större och väldigt mycket mer komplex. Om vi gjort en klok segmentering och därmed har koll på vilka säkerhetsåtgärder vi har och vilka tjänster i andra komponenter som är exponerade behöver ovanstående metod för att analysera en sårbarhet bara titta på säkerhetsåtgärderna och de exponerade tjänsterna. Det är en enorm minskning av mängden arbete, både för att volymen är mindre men också för att den ordning och reda man skapat gör det väldigt enkelt att identifiera vad som är relevant att bedöma! Om man kan dra nytta av moderna sätt att annonsera sårbarheter går det dessutom att automatisera en del av arbetet! Eftersom uppdelningen i ”Zones” och ”Conduits” är tänkt att vara riskstyrd blir nästa nytta man kan ta del av att bedömningen av en sårbarhet blir enklare eftersom det är möjligt att definiera en enhetlig riskprofil per Zone och Conduit. Observera att grunden för att kunna dra nytta av detta inte i första hand är tekniska lösningar, utan en klok metod för att göra och dokumentera hur man designat segmenteringen, tillsammans med vettiga procedurer för hur man följer med i floden av annonserade sårbarheter. Däremot är tekniken förstås helt avgörande för att kunna implementera detta i praktiken. Nätverkssegmentering kan exempelvis vara en valfri kombination av klassiska centrala brandväggar med tillhörande switchar (exempelvis Fortinets prylar), lokalt skydd ute i anläggningen (exempelvis TxOnes Edge-serie) eller mjukvarudefinierade nätverk (exempelvis Veracity). När det gäller komponentinventering, trafikflödesanalys och riskanalys kan det vara bra med en valfri kombination av specialiserade verktyg för inventering (exempelvis OTbase), en modern detekteringsplattform (exempelvis Nozomi) eller en plattform för förebyggande riskanalys (exempelvis Otorio RAM2). Som vanligt blir bra verktyg helt fantastiska i händerna på något som använder dem rätt! Vad är kemikalier egentligen? Arbetet med att få NIS2 att landa i alla EUs länder pågår, vissa länder gör som Sverige och implementerar en nationell lag, medan andra länder har andra metoder. När den delen är klar återstår ett väldigt intressant arbete, nämligen att reda ut vad kraven i direktivet egentligen betyder i vardagen. Det finns nämligen en del klurigheter i direktivs-texten som går att tolka lite olika. Jag har själv hängt upp mig lite på en av dem, frågan om vad som egentligen ingår i kemikalie-sektorn? (Extremt nördigt - jag vet! Sorry...) Vilka organisationer som omfattas av direktivet är ju onekligen en viktig fråga och här är det faktiskt inte speciellt tydligt i mina ögon. Eller egentligen... Det är jättetydligt men på ett sätt som inte känns rimligt! Bland alla nya sektorer som ingår i NIS2 finns punkten "Tillverkning, produktion och distribution av kemikalier" med i listan. Det låter ju ganska uppenbart vad det handlar om ifall man använder den vardagliga definitionen av vad en kemikalie är. Utmaningen är den sista delen av definitionen som du ser i bilden här ovan: "...företag som producerar varor ... genom att använda ämnen och blandningar". Klurigheten uppstår när man tar reda på vad EUs definition av orden "varor", "ämnen" och "blandningar" är. Enkelt uttryckt är en vara något vars funktion framför allt bestäms av vilken fysisk form den har, medan ett ämne och en blandning helt enkelt är ett eller flera grundämnen utan någon speciell funktion. Vill du dyka i de exakta definitionerna så hittar du dem i EUs kemikalieregelverk "REACH" under "Artikel 3": Då är frågan, vad har vi för vardagliga exempel på verksamheter som tar ett eller flera ämnen och producerar en vara av dem? Det måste ju vara viktigt eftersom det innebär att man då automatiskt definieras som samhällsviktig verksamhet! Det finns nämligen inga andra generella begränsningar eller undantag i direktivet; är du verksam i en sektor som omfattas av direktivet och har en tillräckligt stor verksamhet så träffas du av NIS2! Vad tror du om exemplen nedan? Visst är de alla rimliga exempel på att man tar ämnen och gör varor av dem? Känns någon av dem som rimliga exempel på verksamheter som automatiskt bör vara samhällsviktiga? Tillverka synålar av stål Valsa ut ugnsfolie av aluminium Göra elektriska ledare av koppar Göra örhängen av silver Naturligtvis kan de här typerna av verksamheter att vara väldigt viktiga för vårt samhälle! Men är alla det? Den mest extrema slutsatsen blir ju faktiskt att alla producerande verksamheter som använder kemikalier i produktionen kommer omfattas av direktivet eftersom det knappast går att skapa något annat av kemikalier förutom varor eller andra kemikalier! Allt det här känns intuitivt inte rätt! Jag har svårt att tro att det här var tanken med den här definitionen. Men var drar man gränsen då? Och baserat på vilken regel? Jag har skickat den här frågan till lämpliga instanser inom EU, kontaktpersoner på myndigheter i både Sverige och andra länder, till jurister jag känner samt en rad andra kloka kontakter men hittills inte fått något tydligt svar på var jag resonerar fel. Det finns fler gränsdragningar som behöver bli tydligare kring hur NIS2 ska begränsas. Är dessa rimliga exempel? Ett stort företag med en verksamhet som inte alls träffas av NIS2 skaffar en massa solceller på taket till fabriken och blir därmed elproducent - Omfattas! En större industri utan koppling till NIS2 säljer spillvärme till det lokala fjärrvämenätet - Omfattas! En stor bilverkstad som sätter upp laddstolpar för allmänhetens elbilar - Omfattas! De enda områden som jag känner till där det krävs en viss omfattning av verksamheten är dricksvattenproduktion, avloppsrening, avfallshantering och möjligen livsmedelsproduktion. I övrigt kan det vara en väldigt liten del av din totala verksamhet men ändå göra dig till en NIS2-verksamhet. Här vore jag väldigt tacksam om du som läsare kan hjälpa till att bringa klarhet! Hör av dig med inspel eller tankar till mats@ot-sakerhet.se ! Speciellt om du faktiskt jobbar i någon av alla de verksamheter som skulle träffas av den här tolkningen - hur har ni tänkt i er NIS2-analys? Säker fjärranslutning är enkelt! Ett område som ALLA verkar ha utmaningar med är fjärranslutning till OT-system. Det är en väldigt viktig funktion för att hålla igång produktionen, men också en av de mest utsatta delarna ur ett säkerhetsperspektiv! När jag träffar nya kunder brukar det alltid dyka upp alla möjliga spännande lösningar, med mer eller mindre genomtänkt säkerhet. Det här är ett kul område eftersom det är ganska vanligt att man kan skapa verklig nytta genom förbättrad säkerhet! Underhållspersonal, utvecklare, integratörer eller leverantörer kan skapa mycket mer värde om de snabbt kan få åtkomst, oavsett om det är från andra sidan jordklotet eller från kontoret i andra änden av industriområdet! Oavsett i vilken bransch man är brukar ungefär samma saker dyka upp när verksamheter sammanställer sina krav på säker fjärråtkomst till OT, det kan vara: Användbar för både egna anställda och för leverantörer. Ingen installation av programvaror hos den som ska koppla upp sig. (Speciellt viktigt för leverantörer som inte rimligen kan ha mängder med olika klienter och agenter på sina datorer.) Smidig att använda både externt över Internet och mer internt från IT-nätet. Smidig hantering av användare, gärna kopplad till någon separat identitetstjänst. Flerfaktorinloggning för säkrare identifiering och minska risken för delade inloggningar. Behörighetshantering och roller för att styra vem som får komma åt vad. Så här långt finns det ganska många produkter som möter kraven, det är egentligen ganska likt kraven för en typisk IT-miljö. Men när man börjar ställa lite "vassare" krav ur ett OT-perspektiv börjar det bli klurigare: Vid oväntade behov av fjärrstöd ska man väldigt snabbt kunna skapa åtkomst till en ny person utan att blanda in "IT-avdelningen". Inspelning av sessioner för att i efterhand kunna avgöra vad som hände. "Eskorterad inloggning", alltså att man släpper in någon på distans, men "tittar över axeln på dem" medan de är uppkopplade och kan avbryta arbetet om något är på väg att gå snett. Att kunna släppa in en besökare i ett system utan att man behöver dela inloggningsinformation till systemet. (Något slags lösenordsvalv och stöd för semi-automatisk inloggning.) Undvika att skapa en direkt tunnel mellan klientdatorn och systemet man kopplar sig mot. (Om man kan bryta den direkta nätverkskopplingen som man får via en vanlig VPN så är många risker eliminerade. En vanlig källa till problem är att leverantörernas datorer över tid är anslutna till väldigt många olika system, och därför tenderar att "samla på sig" diverse skadlig kod och annat tråkigt.) Stöd för hierarkiskt uppbyggda organisationer där olika bolag i samma koncern ska kunna samarbeta men samtidigt ha egen kontroll över sin egen miljö. Kunna skapa åtkomst till finmaskigt segmenterade och komplexa nätverk utan att man "kortsluter" segmenteringen. Stöd för end-to-end-kryptering och samtidigt något som liknar zero-trust på riktigt. Smidiga metoder för godkännande av inloggningar. Stöd att bygga en robust arkitektur helt utan "Single-points-of-failure". Kunna fungera även i miljöer som kräver fullständig isolering från Internet eller som vill ha egen kontroll över alla komponenter. Baserad på modern teknik, lättanvänd utan utbildning, snabb att implementer och inte resurskrävande för vare sig människor, nätverk eller system. Full loggning av händelser och spårbarhet för ändringar i systemet för fjärruppkoppling. Undvika jumphosts och liknande lösningar som ofta blir en svag punkt underhållsmässigt och dessutom en potentiell kortslutning i ett segmenterat nätverk. På plats i mitt kära hemmalabb finns numera en lösning som imponerat stort på mig och som jag personligen tycker bockar av alla krav som vanligen ställs på fjärråtkomst till OT! Jag tänkte ge dig en översikt här, men får nog anledning att återkomma kring några speciellt intressanta detaljer i framtida nyhetsbrev. Både produkten och företaget heter Cyolo. Lösningen bygger på två mjukvaru-komponenter, "Edge" och "IDAC" (ID Access Control), som man kombinerar ett valfritt antal av för att bygga upp en robust och snabb lösning. Det är i IDAC som allt intressant händer, medan Edge enbart har som funktion att knyta samman kommunikationen. En väldigt intressant styrka är att ingen känslig kommunikation någonsin dekrypteras i en Edge. All kommunikation sker krypterat hela vägen mellan klientsystemet och en IDAC, även om den passerar en eller flera Edge på vägen! Det betyder också att all känslig information bara lagras i system som är under organisationens egen kontroll, ingenting finns hos leverantören. Cyolo erbjuder som du ser på bilden nedan en molnbaserad, generell Edge-tjänst som fungerar ihop med alla installationer som vill använda den, eller så sätter du upp en eller flera egna Edge-tjänster som du exponerar på Internet. En finess med att "studsa via" molntjänsten är att dina egna Edge-tjänster inte behöver vara åtkomliga ute på Internet. Oberoende av hur du har segmenterat dina OT-nätverk finns det många olika sätt att flexibelt skapa styrd åtkomst dit det behövs. Edge-funktionen löser att kommunikationen kommer fram och IDAC ser till att du kan skapa anslutningar på rätt ställen. Och vill du inte ha Cyolo exponerad alls mot Internet så funkar det lika bra med 100% on-prem. Under huven finns ett modernt tänk där de valt att använda Docker-containers för att skapa stabil drift samtidigt som uppdateringar kan ske så gott som utan påverkan på driften. För att maxa tillgängligheten är det också väldigt enkelt att skapa klustrade lösningar över flera sajter. Det gör att störningar i samband med driftproblem eller uppdateringar hanteras automatiskt och snabbt. Det innebär också att det är superenkelt att börja litet för att sedan lägga till efter hand som man behöver mer åtkomst och stabilare drift. Installationen i testlabbet gick oerhört smidigt: Jag skapade en Ubuntu-server, körde ett installationsskript och kopierade in en licensnyckel. Sedan är det igång - inklusive full, och säker, administration från Internet om så önskas! Första gången du loggar in som administratör tvingas du sätta din flerfaktor-identifiering, exempelvis Google Authenticator eller något liknande. Vi kan börja med att titta på några sätt som det här kan fungera ur användarens perspektiv. Den första är nästan lite magisk; du sätter nämligen i princip vilken intern applikation som helst ute på Internet, men bakom flerfaktorinloggning, över krypterad länk och med möjlighet till en rad andra säkerhetsåtgärder! En leverantör som bara ska arbeta på distans i ett webb-baserat internt system får en extern länk direkt till det systemet! I mitt fall sköter jag exempelvis min Proxmox-administration genom att surfa till en länk i stil med https://proxmox.otsäkerhet.cyolo.io! Jag får en Cyoloinloggning med flerfaktorautentisering och sedan landar jag direkt i administrations-webbsidan hemma hos mig! Där får jag logga in som vanligt och kan arbeta precis som om jag satt hemma! På samma sätt som ovanstående exempel kan användaren komma in via protokoll såsom SSH, VNC, Telnet, RDP osv. Användaren jobbar direkt i webbläsaren men den sista delen av kommunikationen, den mellan IDAC och systemet, sker förstås med "rätt" protokoll. Alternativt sätter man upp exempelvis RDP-åtkomst i "bägge ändar" av förbindelsen, vilket förstås kräver tillgång till lämplig klientprogramvara men förbindelsen skapas och skyddas automatiskt av Cyolo. En variant på ovanstående är om jag släppa in någon som jag inte vill ska veta om inloggningen i själva systemet. Då kan jag lagra inloggningen (exempelvis för Proxmox i mitt fall) i lösenordsvalvet som finns inbyggt i IDAC:en och låta inloggningen ske automatiskt när personen ansluter med sitt eget lösenord. Perfekt funktion även internt, för system där många tvingas dela på samma lösenord - ingen behöver kunna det verkliga lösenordet och bara de som ska ha personlig åtkomst får det och med full spårbarhet... Ett vanligt case är att någon ska köra TIA Portal, PLCnext Engineer eller något annat specifikt verktyg på distans. En elegant lösning på det är att Cyolo efter inloggning fixar en lokal port på remote datorn, som magiskt transporteras till exakt den port som behövs för applikationens funktion. Bara en port och bara mellan dessa två system! Och detta utan att installera några agenter på systemet... Du kan erbjuda åtkomst till en Windows-fildelning (SMB) som man kommer åt i ett webb-gränssnitt istället för att oroa sig över att exponera sårbarheter i Windows. Om man absolut vill använda Cyolo som en "en gammaldags VPN" med full åtkomst till ett nätverk så går det också. Det är inte säkerhetsmässigt optimalt, men är ibland nödvändigt. Ur en säkerhetspersons synvinkel är möjligheterna att erbjuda applikationer ett fantastiskt sätt att skapa verksamhetsnytta. Ur ett rent säkerhetsperspektiv kompletterar man det med att styra åtkomst och sätta policies kring användningen. Några intressanta exempel på vad man kan styra åtkomst till en viss applikation baserat på: Användarens identitet eller de grupper man tillhör Om inloggning skett med flerfaktorinloggning Vissa tider och dagar Anslutning från nätverk i utvalda länder Anslutning från vissa IP-adresser eller nät Anslutning från vissa klientsystem som får identifiera sig med certifikat Egenskaper hos enheten man kopplar upp sig från, exempelvis viss version av operativsystemet, ett installerat virusskydd, lokal brandvägg, krypterad hårddisk eller domäntillhörighet Krav på "eskorterat besök" baserat på användarens identitet eller applikationen man ska använda. I korthet handlar det om att en person eller en grupp personer aktivt ska godkänna att uppkopplingen sker. Man kan sedan även övervaka vad som händer under uppkopplingen. Krav på att sessionen ska spelas in Integrationer med andra applikationer kan användas för att kontrollera lämpligheten i att koppla upp sig, genom ett API eller WebHooks. Exempelvis skulle en EDR-lösning (Endpoint Detection & Response) kunna bekräfta att ingen skadlig kod finns på systemet eller ett SCADA-system kan bekräfta att processen är i säkert läge. Dessutom kan man välja vilken funktionalitet som ska vara tillgänglig för användaren under en uppkoppling. Lite beroende på vilken typ av anslutning som är aktuell så kan det handla om att tillåta Cut&Paste, inspelning av sessionen, port forwarding, interaktivt samarbete med den som eskorterar, uppladdning av filer, nedladdning av filer och en massa annat. Hanteringen av identiteter är förstås väldigt central för alla sådana här lösningar. Plattformen kommer med egna IdP:er (Identity Providers) men beroende på dina krav så kanske du vill integrera med existerade identitetskällor (exempelvis Okta, Azure AD, JumpCloud, AD eller Duo) via något av de typiska protokollen som används för detta (SAML, OpenID, RADIUS eller LDAP). Det finns enkla beskrivningar för alla kombinationer av lösningar och stöd för exempelvis SCIM ("System for Cross-domain Identity Management") så att man automatiskt kan bygga upp användarlistan. Men det finns goda anledningar att använda Cyolos egen användardatabas också, exempelvis: Du vill ha en lösning som är fullständigt oberoende av yttre tjänster Du vill separera identitetshantering från flerfaktorsinloggning så de blir oberoende (exempelvis inte köra Azure AD tillsammans Microsofts MFA) Du vill spara på licenskostnader Du vill hantera användare från dina leverantörer separat från den interna hanteringen Det finns ett "lösenordsvalv" inbyggt i lösningen. Det möjliggör att den som ansluter till ett system inte behöver kunna lösenordet som används för att ansluta. Det är en fantastisk finess för att få spårbar och personlig anslutning till utrustning som bara har ett enda lösenord! Det är inte bara lösenord som kan lagras i valvet utan även andra typer av hemligheter, som privata kryptonycklar, certifikat och API-nycklar. Förutom ett systemvalv finns även ett personligt valv för varje användare som möjliggör att man kan spara lösenord som kan möjliggöra automatisk inloggning. Cyolo är väldigt väl anpassad för OT-användning men det passar minst lika bra för olika typer av IT-scenarier. Det finns stöd för SaaS-applikationer och en massa möjligheter att integrera med olika identitetstjänster och SSO-lösningar. När det blir lite mer komplext kan man koppla upp applikationsspecifika tunnlar mot flera olika system samtidigt. Allt som händer i systemet loggas noggrant, både användares aktiviteter och ändringar som administratörer gör. Loggningen, tillsammans med möjligheten till inspelning av sessioner, gör att man kan skapa extremt snygg spårbarhet. En viktig del för att analysera problem och incidenter! Man bör förstås också se till att anslutningar som kommer in på distans passerar förbi andra säkerhetssystem man redan har på plats. Det vore ju fånigt om IDS:er och annat inte fick "hjälpa till" att kontrollera även dessa anslutningar! Vilket förstås kräver klok placering av IDAC. Sammantaget är Cyolo en vansinnigt imponerande lösning. Den har mycket starka funktioner och kan enkelt skapa robust tillgänglighet, men ändå relativt enkel konfiguration och administration! Det blir verkligen en stor vinst säkerhetsmässigt att inte slentrianmässigt släppa in folk i känsliga nätverk via "vanlig VPN" utan istället använda en OT-anpassad lösning för att bryta upp de direkta nätverksförbindelser som annars blir möjliga. Om man inte vill göra sig beroende av externa tjänster går det utmärkt att skapa en helt lokal lösning som fortsätter att fungera även om tvingas isolera en anläggning under en incident. Stark rekommendation! Underhåll och ändringar... Apropå remote access och segmentering så hittade jag nedanstående siffror i en årsrapport från TxOne. Nu tar jag alltid sådana här siffror med en rejäl nya salt men oavsett källan och vad man menar med "OT-säkerhetsincident" så väcker det tankar... Det är onekligen något som jag känner igen mig i, det är inte (än så längre) hackers som är orsaken till de flesta säkerhetsincidenter i produktionsmiljöer. Det är istället våra egna arbeten i miljön, antingen direkt via underhållsarbete eller indirekt när IT-system råkar störa något i produktionen. Förutom vettiga arbetsrutiner och "ordning och reda" så blir förstås styrd åtkomst till system och separation från andra system en viktig del i att undvika problem. Språket spelar roll! Jag har i diverse sammanhang påpekat att man får se upp med vilket språk man läser standarder och lagkrav på. Man kan ju exempelvis tycka att det är fantastiskt att EUs alla viktiga dokument översätts till 24 olika språk, men det finns ju samtidigt en risk att det uppstår otydligheter när dessa översättningar skapas. Mina juristvänner berättar för mig att det är den engelska och franska versionen som väger tyngst om det blir tolkningsfrågor inom EU. Jag har hittat en del ställen där exempelvis NIS2-direktivet inte riktigt sänder samma signaler på olika språk. Häromdagen läste jag i en artikel att NIS2 kräver att man använder "state-of-the-art" i sina åtgärder vilket fick mig att börja jämföra olika språk. Här är den engelska versionen som mycket riktigt säger att man ska väga in moderna möjligheter när man utformar sitt skydd: Om man läser motsvarande text på svenska, så får i alla fall inte jag samma budskap. "State-of-the-art" och "de senaste" sänder inte riktigt samma signaler... Det finns fler klurigheter i översättningarna, en personlig favorit är kring gränsdragningen mellan Väsentlig och Viktig när det kommer till organisationens storlek. På engelska talar man om att Väsentliga ("Essential") måste överstiga taket ("Ceiling") för vad som är en medelstor organisation. Motsvarande text på svenska talar om "trösklar", vilket i alla fall jag tolkar som en nedre gräns för någonting, i motsats till "tak" som känns som en övre gräns: Man kan alltså lätt tro att ett "Medelstort företag" automatiskt blir Väsentligt om man läser den svenska texten, men den korrekta tolkningen är att det krävs nästa storleksordning. I det här fallet skulle konsekvenserna bli att man drar på sig radikalt högre krav om man av misstag ser sin organisation som "Väsentlig"! Nu är det ju inte meningen att alla ska sitta och läsa lagtext, men eftersom tiden är kort tills implementationen av alla NIS2-åtgärder ska vara klar så blir man ju så illa tvungen när ingen svensk vägledning finns klar. Min rekommendation är verkligen att inte läsa avgörande texter enbart på svenska, i synnerhet gäller det för oss amatörjurister! När du analyserar om er organisation omfattas av NIS2 och när du utformar era åtgärder är det viktigt att vara lite noggrann med dokumentation av vad era avgörande beslut baseras på. En annan sida av EU-reglering En intressant artikel av Mazaher Kianpour (från RISE och NTNU) och Shahid Raza (från RISE, MDU och Cybercampus) tittar på hur organisationer reagerar på cybersäkerhetslagar. Det är ju en klassisk insikt att förändrade spelregler inte automatiskt skapar det beteende man egentligen var ute efter... Hotet om sanktionsavgifter och annat kommer naturligtvis alltid vägas mot andra risker och resursbehov. Följetongen CRA... Du missade väl inte extrautgåvan av nyhetsbrevet som kom alldeles efter nyår och tittade närmare på den slutgiltiga texten för CRA-förordningen? Ännu så länge är den inte formellt spikad och det finns heller inget datum bestämt när det kan bli aktuellt. Prognosen säger just nu en vecka in i april men det kan mycket väl ändras. Nu börjar det gå upp för allt fler hur tuffa de närmaste åren kommer bli för många organisationer. Väldigt många är mitt uppe i NIS2-resan (plus DORA och CER för dem som berörs) samtidigt som nu CRA dyker upp på horisonten. CRA ska dessutom sannolikt vara fullt implementerad ungefär samtidigt som den nya Maskinförordningen har sin deadline. Även om det senare inte är förrän 2027 kommer det bli nödvändigt för många organisationer att ta ett samlat helhetsgrepp redan nu på alla dessa kravmassor för att inte behöva göra om jobbet flera gånger. Jag har försökt förstå vad opensource-världen tänker kring det slutgiltiga förslaget. De tidigare versionerna sågades ju brutalt därifrån men det har blivit nästan märkligt tyst efter det slutgiltiga förslaget. Några tankar har jag hittat, exempelvis från Eclipse Foundantion, OpenForum Europe, Python Software Foundation där tongångarna var mestadels positiva medan Debian var lite mer negativa. Jag hittade också en bra genomgång skriven av Bert Hubert. För NIS2 gick det att skaffa sig fördelar som leverantör om man var snabbt uppe ur startblocken och visade upp att man kan leverera enligt direktivets krav långt innan de börjar gälla. För NIS2 har det tåget snart lämnat stationen, men för CRA finns fortfarande bra möjligheter att styra upp utvecklingsprocesserna och villkoren för säkerhetssupport på sålda produkter. Säljer du produkter med digitalt innehåll är det viktigt att hugga tag i CRA snabbt! På OT-sidan som ofta har komponenter i drift under lång tid blir det speciellt viktigt att tänka igenom hur lång supportperiod man tänker garantera vid köp! Jag kan förresten rekommendera en episod av Dataföreningens "Prata CRA lagen med oss", där Olle E Johansson och Per-Erik Eriksson diskuterar den senaste versionen av förordningen: EUCC är klar! EUs cybersäkerhetsmyndighet ENISA har annonserat att "EU cybersecurity certification scheme on Common Criteria", (EUCC), är klar. Det är den första av en radda sådana och kommer bland annat följas av en kring molntjänster (EUCS) och en för 5G (EU5G). Det tittas också på möjligheterna på motsvarande upplägg för AI, elektroniska identitetstjänster och för MSSP:er (Leverantörer av managerade tjänster för säkerhet) Det här är ett spännande och komplext område som kommer få många beröringspunkter med exempelvis CRA-förordningen. Jag får säkert anledning att återkomma till detta! Jag satsade på rätt häst i labbet! Om du följt mina äventyr i hemmalabbet vet du att jag snöat in på Proxmox som virtualiseringsmotor. Ett annat vanligt val för virtualisering i hemmalabb är att köra gratisvarianten av VMware ESXi. Nu är jag ännu gladare att jag fastnade för Proxmox när VMware nu annonserat att gratisvarianten av ESXi försvinner. Det har hörts många "vad var det jag sa" från folk som såg detta komma sedan VMware köptes av Broadcom. Det återstår att se om/hur detta slår tillbaka mot VMware men tills dess är min personliga rekommendation att titta på Proxmox. Har du kollat tändstiften? Här är en intressant text som egentligen är en presentation som Christofer Dutz höll på "2023 IoTDB Summit" som inte nämner säkerhet en enda gång men som illustrerar en intressant förflyttning i branschen. Nämligen den som går bort från OPC UA och istället rör sig mot MQTT och Sparkplug B. Några av anledningarna till denna trend beskrivs i texten. Det är inte helt klart för mig hur siffrorna ser ut för OPC UA och MQTT men oavsett är det här något som vi OT-säkerhetsmänniskor måste vara uppmärksamma på! Läsvärt från MSB! MSB släppte nyligen dokumentet "Cyberangrepp mot samhällsviktiga informationssystem - 25 rekommendationer för stärkt skydd mot cyberangrepp". Det är inte skrivet specifikt för OT-säkerhet men innehåller många relevanta referenser och exempel som borde göra det till ett intressant dokument för de flesta säkerhetsintresserade. Ska vi höras? I förra nyhetsbrevet öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt och jag har haft en radda riktigt roliga samtal, så jag kommer repetera den här texten framöver. 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? Det glamorösa livet på AFRY? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en extrautgåva av nyhetsbrevet kring OT-säkerhet! Huvudnyhet den här gången är att CRA-förordningen verkar vara klar! Just därför är nyhetsbrevet lite kortare än vanligt, jag ville få ut en första analys lite snabbt. Men du får också en ny 62443-standard, mina tankar kring leverantörskedjor, nya vägledningar från SÄPO och ytterligare en rapport från hemmalabbet! 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! Nu vet vi mer om CRA! Nu är texten för CRA, Cyber Resilience Act, tillgänglig i den version som man enades om i trevägsförhandlingarna mellan Parlamentet, Kommissionen och Rådet. Rent principiellt är den inte godkänd, den ska nu formellt klubbas av Parlamentet och av Rådet innan den kan börja gälla. Men det ska mycket till innan det blir några större ändringar nu! Samtidigt kom också ett utkast till en gemensam text om att EUs cybersäkerhetsorganisation ENISA behöver utökas med mer kompetens för att kunna ta hand om de nya kraven. Det här är en riktigt viktig lagstiftning! I korthet är det helt enkelt de säkerhetskrav som ställs på (nästan) alla typer av digitala produkter och dess tillverkare för att de ska få säljas eller göras tillgängliga inom EU. På samma sätt ställs motsvarande krav på importörer, distributörer eller någon som modifierar produkten. Formellt sett heter texten inte CRA utan "Horizontal cybersecurity requirements for products with digital elements" vilket ju faktiskt säger mer om både innehållet och syftet med kraven. Det är 186 sidor av juridisk text som inte alltid är helt enkel att ta till sig, särskilt inte för en amatörjurist som jag... Till att börja med konstaterar vi att det är en "Regulation" och inte ett "Directive" som exempelvis NIS2 är ett exempel på. "Regulation" blir på svenska "Förordning", vilket för övrigt är ett lite olyckligt ordval eftersom "Förordning" i svensk lagstiftning är någonting helt annat. En tydlig skillnad mellan CRA och NIS2 blir därför att CRA inte behöver "landa" i nationell lag, utan gäller direkt som lag i alla EUs länder. Som vanligt i de här texterna inleder man med en beskrivning av bakgrund och tänket i lagstiftningen, i det här fallet på 69 sidor. Det här är en viktig text även om den inte innehåller några krav, eftersom den definierar vad avsikten är - och det är viktigt i EU-rätt, vilket vi inte är så vara vid i Sverige där man lägger mer vikt på den exakta formuleringen i lagtexten. I den inledande beskrivningen kan man tydligt se resultatet av förhandlingarna kring texten, inte minst när det gäller open-source. Det är många tillägg och förändringar, men också faktiskt riktigt många strykningar. Vi får krav på fyra områden: Regler för hur man får göra digitala produkter tillgängliga på marknaden inom EU Krav på design, utveckling och produktion av digitala produkter och vilket ansvar inblandade organisationer har Krav på hantering av sårbarheter Regler för marknadsövervakning och hur alla krav genomdrivs Reglerna gäller för alla produkter med digitalt innehåll, mjukvara eller hårdvara, som görs tillgängliga på EUs marknad om det är rimligt att tro att den kan ha en logisk eller fysisk "dataförbindelse" med en enhet eller ett nätverk. Det slås direkt fast att CRA inte gäller om produkten lyder under EUs regler för medicinsk utrustning eller någon av regelverken för motorfordon, flygplan eller fartyg. De gäller inte heller för försvarsutrustning eller utrustning för nationell säkerhet. Kraven innebär att man får CE-märka produkten och därmed sälja den inom EU. (Observera att den inte bara får vara CE-märkt, utan den ska vara det!) Det är inte bara tillverkarens ansvar som definieras utan även importörer, distributörer och andra som på något vis representerar en del i att produkten görs tillgänglig för andra. Några av de viktigaste detaljerna som finns i förordningen tycker jag personligen är: Säkerhetsuppdateringar ska göras tillgängliga i hela produktens livslängd och ska vara gratis. De ska göras tillgängliga separat från funktionsuppdateringar. En säkerhetsuppdatering ska fortsätta hållas tillgänglig i minst 10 år. Sårbarheter ska annonseras publikt när de åtgärdats. Det här är en stor grej i OT-världen där väldigt många bolag fortfarande mörkar sina rättningar. Varm applåd från min sida! Supporttiden ska vara minst fem år om det inte är uppenbart att produkten kommer användas kortare tid än fem år. Supporttiden ska vara tydligt definierad redan vid köp och ska motsvara tiden som produkten kan förväntas användas kombinerat med rimliga förväntningar från kunderna. (I OT-världen vet vi att många produkter används väldigt länge, det blir intressant att se hur detta kommer tolkas för dem och hur det kommer påverka priset på produkterna?) Det är frivilligt att meddela myndigheterna (ENISA eller den nationella cybersäkerhetsmyndigheten) om sårbarheter som tillverkaren (eller någon annan) upptäcker. Om sårbarheter aktivt utnyttjas ska tillverkaren meddela myndigheterna (ENISA och den nationella cybersäkerhetsmyndigheten) inom 24 timmar. Även drabbade användare av produkten ska meddelas. På samma sätt ska tillverkaren meddela myndigheterna om allvarliga säkerhetsincidenter som tillverkaren själv drabbas av, om de kan påverka produkternas säkerhet! Produkter ska levereras "Secure by default" vilket bland annat kan betyda att de inte får ha kända sårbarheter eller samma lösenord. Tillverkare ska skapa en SBOM, Software Bill Of Materials men som lustigt nog inte behöver ta upp beroenden på mer än på en direkt nivå. Teknisk dokumentation ska vara tillgänglig i minst 10 år. I den tekniska dokumentationen ska tillverkarens riskanalys för produkten finnas med. Dokumentationen och riskanalysen ska uppdateras löpande under hela produktens livslängd. Vid användning av tredjepartskomponenter (både open-source och annat) ska tillverkaren ta ansvar för att det inte försämrar säkerheten. I produkter inkluderas även "remote data processing". Det vill säga att om delar av funktionaliteten i en produkt kommer från en molntjänst eller någon annan tjänst som finns i andra system så inkluderas även de i produkten och därmed motsvarande krav. Det finns tre kategorier av digitala produkter där "Important" och "Critical" definieras som viktigare än andra. Inom "Important" finns dessutom "Class I" och "Class II". Exempel på de olika kategorierna är: Important, Class I: System för identitetshantering och accesskontroll, Webbläsare, Lösenordshanterare, Skydd mot skadlig kod, VPN, SIEM-system, PKI-lösningar Important, Class II: Hypervisors och containersystem, Brandväggar, "Mikroprocessorer som ska vara skyddade mot fysisk manipulation" Critical: "Hardware devices with security boxes" Vad tusan är det? :-) Oavsett vilken kategori så gäller att tillverkaren ska via att produkten uppfyller ett antal grundläggande säkerhetskrav. Det kan göras på lite olika sätt men för "Important" är metoderna lite mer formaliserade och för "Critical" kommer det framöver komma separata krav på en formell certifiering för vissa typer av system. Det är viktigt att komma ihåg att kategoriseringen inte "smittar", ett system som innehåller komponenter som är "Important" eller "Critical" får alltså inte automatiskt samma kategori. Om man inte sköter sig blir det spö! Dels får man inte leverera sina produkter men till det kan man få upp till 15 miljoner Euro i sanktionsavgift, alternativt 2.5% av den globala omsättningen om det är högre. Att tillhandahålla felaktig eller inkomplett information kan "belönas" med 5 MEUR eller 1% i sanktion. Ganska hårda bud alltså... Ett av de områden som kritiserades hårdast när det första utkastet till CRA kom var hur det slog mot open-source världen. Det har man verkligen tagit till sig i den här versionen, några tydliga tecken är: Rollen "open-source software steward" definieras som en legal organisation som tillhandahåller support för digitala produkter som är avsedda för kommersiell verksamhet. En steward ska se till att det finns en cybersäkerhetspolicy som styr utvecklingen av produkten och hanteringen av sårbarheter. Stewarden ska verka för frivillig rapportering av sårbarheter bland utvecklarna. Stewarden ska rapportera aktivt utnyttjade sårbarheter och egna incidenter till myndigheter och användare på samma sätt som tillverkare ska. En steward kan inte drabbas av sanktionsavgifter. Notera att open-source inte är kopplat till priset på en produkt, Definitionen av en "Tillverkare" kräver inte att man tar betalt för produkten, man har ändå samma ansvar så länge produkten är en del av en kommersiell verksamhet. Det bör rimligen innebära att mjukvara som Internetbrowsers, sociala medier och liknande omfattas. Det finns en hel del referenser till NIS2 i CRA. Dels använder man ett antal gemensamma definitioner ("incident", "near miss") vilket förstås är bra. I kommande utökningar av vad som definieras som "Critical products" ska speciell hänsyn tas till om "Väsentliga entiteter" enligt NIS2 är beroende av dem. Det finns en del överlapp kring annonsering av sårbarheter och samarbete mellan nationernas cybersäkerhetsmyndigheter. Däremot har man tagit bort referenserna till NIS2 i definitionerna av "Kritiska produkter" som fanns i tidigare utkast. Denna slutgiltiga version av CRA är betydligt förenklad jämfört med det ursprungliga utkastet, men det är inte enkla krav som ställs, de kräver en hel del arbete och kompetens för att kunna möta. I förordningen finns texter om att Kommissionen ska ge ut vägledning för att underlätta införandet och med ett speciellt fokus på mindre verksamheter. Det står också att respektive land ska tillhandahålla utbildning och stöd till mindre organisationer. Kring OT-säkerhet finns nästan ingenting skrivet. I tidigare utkast fanns OT definierat som begrepp och en rad OT-prylar uppräknade som exempel på "Kritiska produkter" men det har tagits bort. När det gäller kraven på att inga kända sårbarheter får finnas i produkten kan man fundera på hur helt oskyddade OT-protokoll kommer ses? Att Modbus helt saknar autentisering måste ju ändå ses som en sårbarhet men det lär ju inte vara aktuellt att förbjuda Modbus-servrar? Det finns faktiskt öppningar för att kontraktsmässigt kunna ta bort kraven på "Secure by default" och gratis säkerhetsuppdateringar, men de är begränsade till skräddarsydda system och lär inte kunna användas i andra sammanhang. För de flesta organisationer kommer det krävas mycket arbete för att få allt på plats. När förordningen börjar gälla så har man 36 månader på sig förutom i följande fall: Kraven på rapportering av utnyttjade sårbarheter och egna säkerhetsincidenter börjar gälla redan efter 21 månader. Länderna ska inom 18 månader ha fått igång myndigheter som sätter upp "myndighetssidan" av kraven. Det finns en målsättning om att det inom 24 månader ska finnas tillräckligt med "Notified bodies", alltså organisationer som bedömer att certifieringskraven uppfylls. Eventuella andra cybersäkerhetscertifieringar som gjorts tidigare ska kunna vara giltiga i upp till 42 månader. Produkter som satts på marknaden före införandet undantas tills de "modifieras betydligt" men kraven på rapportering av utnyttjade sårbarheter och egna säkerhetsincidenter börjar gälla oavsett efter 21 månader. Personligen tycker jag man verkar ha fått ihop en riktigt bra kompromiss! Det finns mycket kvar som fortfarande är lite oklart, i synnerhet de delar som ska "fyllas på efterhand". Det kommer förstås få en påverkan på priset för vissa produkter, men säkerhet måste få kosta så det är bra att "det blir lika för alla". Extra spännande blir det förstås för de företag som även omfattas av andra krav, kanske framför allt NIS2 och Maskin-förordningen. Det är definitivt inte läge att försöka implementera dem var för sig! Mest uppenbart blir det väl kanske för tillverkare av datorer, elektronik och många typer av maskiner, men kanske i vissa fall även andra? Hur blir det med apparna som firmor tillhandahåller som del av sina tjänster, som exempelvis budfirmor, flygbolag, fjärrvärmeleverantörer, banker, livsmedelskedjor och sjukvårdsappar? Hur blir det med routern som Internetleverantören ställer ut? De moderna mätarna för el och vatten? Min personliga tolkning är att de alla ingår i scopet för CRA samtidigt som organisationen faller under NIS2... Vad händer i andra änden av kedjan? Jag har på sistone varit insyltad i en del diskussioner kring de delar av NIS2 som handlar om säkerheten i leverantörskedjor. Det här är ju en väldigt central del i direktivet och det är tydligt att EU tagit intryck av att så många av de stora incidenter som varit de senare åren har varit orsakade av brister i säkerheten hos leverantörer. Det här är verkligen något som det trycks speciellt på i direktivstexten: Det här betyder i praktiken att alla organisationer som själva omfattas av NIS2 i princip i sin tur behöver ställa motsvarande krav som NIS2 ställer på sina egna leverantörer. Det intressanta är att det här inte är krav som är speciellt enkla att hålla koll på. Hur håller man koll på sina leverantörers "säkerhetspraxis"? Eller på deras metoder för säker utveckling? Eller på "...de sårbarheter som är specifika för varje direktleverantör..."? Ska man göra det här ordentligt kommer det krävas en hel del jobb av både leverantörer och kunder! Vad händer då när man börjar "dra" i ena änden av leverantörskedjan? Någonting behöver ju hända i den andra änden? Jag har en känsla av att detta i förlängningen kan leda till att många organisationer kommer dra ner på antalet leverantörer som de använder, av det enkla skälet att det blir en tung hantering att löpande hålla koll på deras säkerhetsrutiner. Med tanke på hur hårt man trycker på det i direktivet så kan vi nog räkna med att tillsynsmyndigheterna kommer ha mycket fokus på detta! Både NIS2 och CRA innehåller regler som leder till försäljningsförbud om man inte klarar reglerna. Som vi sett på helt andra områden (exempelvis laddare för elbilar och högteknologiska cykelhjämar) kan det bli tufft (eller till och med dödsstöten) för en leverantör som får säljstopp! Å andra sidan är det här förstås en fantastisk möjlighet för de leverantörer som är duktiga på säkerhet att skaffa sig stora konkurrensfördelar. Och förstås även för de som nu satsar på att bli duktiga på NIS2-krav innan kunderna hinner börja ställa dem. Tidigare har ju inte god säkerhet varit ett jättestarkt argument vid inköp och upphandlingar. Det kan nog komma att ändras nu, åtminstone för de delar av säkerhetsarbetet som är enkla att kravställa och mäta. Hur ska man bäst hantera detta som leverantör då? Den enklaste lösningen i mina ögon är för leverantörer att se till att de uppfyller kraven i NIS2 även om de inte formellt själva faller under direktivet. Skaffar man sig sedan en lämplig certifiering på detta så kan man slippa ha upprepade diskussioner med varje enskild kund! Glöm inte Maskindirektivet! När vi ändå är inne på NIS2 och CRA vill jag påminna om den nya Maskinförordningen som också tar upp cybersäkerhet. Om du tillverkar maskiner med digitalt innehåll kommer du sannolikt beröras av både CRA och Maskindirektivet. Beroende på vad det är för maskiner så kan även NIS2 vara aktuellt. Försök för allt i världen inte implementera de här tre kravmassorna var för sig! Det blir otroligt mycket onödigt jobb och resultatet blir förmodligen inte så bra. Sammanställ era egna krav, se till att de räcker till och implementera dem sedan i ett svep! Nix! Det har inte blivit fritt fram i 62443... Det pågår ett antal olika aktiviteter för att uppdatera de olika delarna i 62443-standarden. Det är verkligen något som behövs, tiden har sprungit ifrån standarden och de olika delarna säger ibland emot varandra på lite ologiska sätt. Arbetet blir lite extra komplicerat av det enkla faktum att vissa delar drivs av ISA och andra av IEC. Nu senast fick vi en ny version av 62443-2-4 från IEC. Den förra versionen var från 2015 med en mindre uppdatering 2017, så det var dags för en ny version! Del 2-4 handlar om krav på de säkerhetsprocesser som tjänsteleverantörer ska följa när de erbjuder systemägare integration och/eller underhåll av automationslösningar. Den kan användas direkt av leverantören eller för bra kravställning från kundorganisationen. Det påverkar inte hur andra viktiga delar i standarden, exempelvis 3-3 och 4-2 ska användas. 2-4 är en av de få delarna i standarden som faktiskt bygger ett par resonemang på Purdue-modellen. Jag har sett en del ståhej kring detta i sociala medier, med rubriker som insinuerar att något helt nytt är på gång och att de gamla principerna som förbjöd direkt kommunikation mellan olika nivåer nu är borta. Det är min åsikt att detta är överdrivet av flera skäl, men framför allt har Purduemodellen aldrig legat till grund för hur 62443 styr nätverkssegmentering. Det är "Zones" och "Conduits" som gäller och där är det ingenting nytt. Den gamla versionen av 2-4 nämnde Purdue i två sammanhang: Att dokumentationen över hur trådlösa nätverksfunktioner används mellan olika Purdue-nivåer är aktuell. Att ingenjörsstationer för safety-system inte kan påverkas från nivå 3 eller högre upp. I den nya versionen har man helt strukit referenserna till Purdue kring trådlöst och nämner istället "Zones" and "Conduits". När det gäller Safety-system finns referensen märkligt nog kvar men det spelar mindre roll, att skydda safety-system tenderar att få stort fokus oavsett! Jag får ibland frågan om varför jag tycker så illa om Purdue-modellen och jag inser att det kan verka så. I praktiken har jag inget emot den alls, så länge den inte används för att "fuska"... Purduemodellen är jättebra att använda i diskussioner kring hur olika typer av system kommunicerar, och det är inte så konstigt med tanke på att det var det som var ursprungstanken med modellen! Modellen är också användbar som inspiration när man gör sin segmentering av nätverk och system. IEC 62443-3-2 nämner precis detta - att den kan användas som grund för segmenteringstänket. Tyvärr är det många som stannar där och inte gör det viktiga jobbet. De bygger nät utefter nivåerna i modellen och tycker sig ha gjort det som behövs enligt standarden. I vissa, enklare fall kan det förstås vara så att detta räcker. Men för att kunna veta om det räcker så behöver man fortfarande göra något slags riskanalys och bygga sina "Zones" och "Conduits" efter den. Visar det sig att "Zones" blir samma sak som Purduenivåer så var det ju bra! Men! Vi ska naturligtvis inte bara luta oss mot vad vår kära standard säger! Vissa saker är (nästan) alltid väldigt bra att göra! Det är alltid en bra idé att ha DMZ-nät mellan "IT" och "OT"! (Även om inte standarden tvingar oss!) Det är dessutom nästan alltid bra att ha flera DMZ-nät så att vi inte blandar utsatta system med varandra! (Även om inte standarden tvingar oss!) Det är alltid bra att inte tillåta obruten kommunikation direkt mellan "IT" och "OT", utan att "mellanlanda" den i något slags proxy-system. (Även om inte standarden tvingar oss!) Jag ser den nya versionen av 2-4 som ett välkommet steg i moderniseringen av standarden. Vi får hoppas att arbetet med övriga delar rör sig någorlunda snabbt framåt! Vi behöver en lokal! I förra nyhetsbrevet erbjöd jag mig att skapa något slags diskussionsforum kring OT-säkerhet. Av återkopplingen att döma så var det en populär tanke, det var många som ville kunna diskutera OT-säkerhet med andra! Baserat på intresset tänker jag mig att vi börjar med något slags digitalt forum. Om det sedan finns intresse där för någon form av träffar eller digitala event så tar vi det i steg två. Ett digitalt forumet behöver vara enkelt att komma åt på många olika typer av enheter och enkelt att använda. Det är inte tänkt att hantera några direkta hemligheter men det behöver vara tillräckligt säkert för att hålla borta de flesta spammare och bottar. Det behöver klara att ha någon form av enkel ämnesstruktur så att det inte bara blir en enda röra av meddelanden. Det ska kännas okej för dem som tar privacy på extra stort allvar och som kanske undviker sociala medier. Spontant ser jag några rimliga alternativ: Ett klassiskt Internetforum som en "bakficka" till nyhetsbrevet. Dvs man loggar in på något i stil med ot-säkerhet.se/otdiskussion. (Men... Extra underhållsjobb för mig och kanske inte lockar till mycket interaktion om man måste använda en webbläsare?) En privat server på Discord. (Funkar på alla plattformar men lite klurig att använda om man inte är van vid Discord. Discord har väl hyfsat rykte men det är trots allt ett slags socialt medium.) Vi använder Slack eller någon liknande freemiumtjänst. (Kan vara lite skakigt kring privacy och klurigt för folk som inte använder produkten annars.) Self-hosta någon lämplig FOSS-programvara hemma i garaget. (Förmodligen mycket mer jobb än jag hade tänkt mig...) Invadera något existerande forum som har ett annat syfte. (Enkelt men kan vara impopulärt?) Vad tycker du? Ser du något annat alternativ? Skicka tyckanden och förslag till mig på mats@ot-sakerhet.se eller kommentera det här nyhetsbrevet på LinkedIn. Ska vi höras? 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 ganska korta eller "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! SÄPO är klara! Nu har Säkerhetspolisen släppt uppdaterade versioner av samtliga vägledningar kring säkerhetsskydd. så att de ska matcha uppdateringarna i lagen som kom för två(!) år sedan. Det finns fortfarande inte mycket hjälp att vänta för den som hanterar OT-säkerhet i säkerhetskänslig verksamhet. Fokus är fortfarande på skydd av information och OT får finna sig i att bli hanterad under "...skadlig inverkan i övrigt på...informationssystem". Att kombinera de två väldigt olika områdena säkerhetsskydd och OT-säkerhet kräver verkligen att man håller tungan rätt i mun för att inte tappa fokus på vad som är viktigt. Just därför är det förstås extra roliga projekt för en säkerhetsnörd som jag själv. Säkerhetsnörd? Ja, apropå säkerhetsnördar så kan jag rekommendera den nyutgivna boken "Förutsättningar för krisberedskap och totalförsvar i Sverige" från Försvarshögskolan. Den finns att köpa som bok eller ladda ner gratis. Inte så mycket fokus på OT-säkerhet, eller ens cybersäkerhet. Men en intressant historik över totalförsvaret i Sverige sedan 1901 och diskussioner kring en lång rad händelser och insatser i mer modern tid. Du får också en genomgång av alla myndigheter som är inblandade i krisberedskap och totalförsvar. Hackers utan verktyg? I en artikel sammanställer Danielle Jablanski ett gäng goda idéer kring hur man skyddar sina system mot "Living of the land techniques", "LotL". Det här är ett begrepp som blivit allt mer i ropet i IT-världen och som nu också börjar hitta in i OT-världen. Det handlar helt enkelt om angrepp som sker utan hjälp av specialskrivna "hackerverktyg" utan istället att man använder de verktyg som redan finns på de system där man bryter sig in. Det här är ju något som egentligen passar "väldigt bra" i OT-världen med tanke på hur begränsat inre skydd de flesta system och komponenter har. Rapport från lekstugan Jag fick väldigt mycket roliga frågor om mitt lilla hemmalabb när jag pratade min nya virtualisering i förra nyhetsbrevet. Om det är fler som är nyfikna kring hur jag tänkt när jag satte upp Proxmox så kommer lite tankar och erfarenheter här... I övrigt finns lite mer information kring labbet i allmänhet i nyhetsbrev #55. Helt kort för den som inte känner till Proxmox så pratar jag om en opensource-programvara som heter "Proxmox VE", Proxmox Virtual Environment. Det är en Debian-baserad Linux-plattform som skapar en helhetslösning för virtualisering med applikationer skrivna i Perl och Rust. Man erbjuder fullständig virtualisering via KVM och samtidigt möjlighet att köra containers via LXC. Det finns stöd för klustring, fail-over, live-migrering och en massa andra fina funktioner. På nätverkssidan är det också rejält utrustat med fullt stöd för virtuella eller "Software defined" nätverk, VLAN och alla andra nätfunktioner som kan vara intressanta. Allting är baserat på existerande Linuxfunktioner som knyts ihop på ett elegant sätt. Vill man köra detta i produktion så finns fullt kommersiellt stöd från den tyska firman "Proxmox Server Solutions GmbH" som ligger bakom alltihop. Direkt ska jag säga att det finns en baksida med att det verkligen går att göra precis vilka lösningar som helst, och det är att det definitivt finns gränser för vad som går att göra i administratörsgränssnittet. Resten är kommandon och konfigurationsfiler precis som det alltid är i Linux. Det kan vara en rejäl tröskel om man är ovan, men å andra sidan finns det en gigantisk mängd hjälp att hitta via valfri sökmotor på Internet! För mig som är gammal Unix/Linux-nörd sedan i början av 90-talet, så är det underbart att återvända till den här världen! Det är som att cykla, handgreppen sitter kvar i händerna... Mitt tänk är att hemmalabbet ska vara en ultra-flexibel lekstuga där det snabbt går att testa nästan vad som helst. Jag har valt att inte bygga någon simulerad industri med alla de vanliga lösningarna som är vanliga då. Istället ska jag snabbt och enkelt kunna slänga upp små och stora nät med lämpligt innehåll, allt efter behov. Det betyder också att jag unnar mig att använda lösningar som kanske inte alltid passar i "riktiga" miljöer, exempelvis att "IT" och "OT" rör sig i separata VLAN i samma switchar. Eller att virtualisering sker i delad hårdvara. Eller att simulerade safety-system, som skulle varit väldigt skyddade i "riktiga" system, är åtkomliga från andra nät. Om det blir aktuellt att pentesta en kopia av ett riktigt system så får man förstås hantera det lite annorlunda. Min huvudsakliga proxmox-host är en mini-PC. Den är inte alls avsedd för industriellt bruk, men den är liten och tillräckligt kraftfull: 32 GB RAM, i5-8500T-processor med 6 cores, ett antal TB disk fördelat på SSD/M.2NVMe/USB3.0 och två nätverksanslutningar. En av nätverksanslutningarna har ett trunkat nät med 8 VLAN som möter en liten switch med motsvarande uppsättning, vilket gör att jag har 8 "OT-nät" som finns både i den virtuella miljön och i (taggade eller otaggade) nätverksportar i switchen. Smidigt! Det finns förresten också två andra proxmox-hostar i samma "Datacenter". En som snurrar på en enklare laptop med en 4-cores i5-4300U CPU och bara 8 GB RAM. Laptopen är främst där för att kunna testa servermigration i Proxmox och för att ta backuper. Den andra är servern för hemautomation och annat kul (en HPE MicroServer Gen 10 med en 4-cores AMD Opteron X3421 och 32 GB minne) där bland annat Home Assistant snurrar. Övrig infrastruktur byggs med de prylar som råkar sitta i labbracket för tillfället. Åtkomst till Internet ordnas via ett eget VLAN i hemmets Ubuiquiti Unifi nätverk (en DreamMachine Pro, två 8-portars PoE-switchar, ett par AC Long Range som fixar husets WiFi assisterade av två AC Mesh). Okej då, lite prylnörd är jag väl då... Om jag ska försöka dela med mig av lite insikter och erfarenheter kring just Proxmox så är det väl: Du behöver förstås vara lite hemma på att hantera datorer men det är relativt enkelt att komma igång. Det finns otroliga mängder hjälp på Internet, det är i princip omöjligt att få ett problem som ingen annan redan haft! Det mesta som behövs för "normalt bruk" går väldigt enkelt att få till i det grafiska webb-gränssnittet. Ska du gå utanför det grundläggande får du räkna med att bli bekväm med att administrera system i Linux, dvs kommandon, skript och konfigurationsfiler. I och med att man har direkt tillgång till alla konsoler och shell i proxmox administrationsgränssnitt blir man väldigt snabb och effektiv när man har fått lite koll på läget. Proxmox är gjort för extrem tillförlitlighet som passar i "skarp användning". Om man inte tycker det är en katastrof om man tappar några sekunders data vid ett strömavbrott så går det att optimera på ett annat sätt för att få upp prestandan rejält, exempelvis om man använder zfs för lagring. Precis som för alla andra virtualiseringslösningar så tjänar man på att ha mycket RAM och snabba diskar. Om du har möjlighet så maxa RAM och skaffa NVMe-diskar. Proxmox har stöd för containers. Men det är inte Docker-containers som många tror utan "rena" linuxcontainers via LXC. Men det är enkelt att lägga till en virtuell maskin där man kör sina Dockers men det kan vara förvirrande i början. I närtid finns det ett gäng roliga områden som jag behöver utforska mer förutom alla roliga OT-prylar som jag får i händerna, exempelvis: Automatiserad uppsättning av testmiljöer med Ansible och någon variant av Terraform. (För att bli ännu snabbare i att komma igång när något ska testas.) Den spännande världen kring "Software Defined Networking" i OT-världen. Här kommer sannolikt en controller från Veracity kombineras med "Open vSwitch" som är innbyggt i Proxmox. Min hemautomation, som är baserad på Home Assistant, ska få flytta över till Proxmox tillfälligt medan dess egentliga server ska ominstalleras från scratch. (Med Proxmox förstås!) Tillgång till speglad nätverkstrafik är enkelt i traditionella switchar, men kan vara ett klurigt område i virtualiserade miljöer. Tyvärr verkar det sant även i Proxmox, men det behöver lösas för att få till bra tester av OT-IDS:er framöver. När det gäller roliga OT-prylar så hoppas jag snart kunna skriva om en lösning för riktig fjärråtkomst för OT-miljöer, dvs någonting som är mycket mer flexibelt än klassisk VPN eller lösningar baserade på centrala serverfunktioner och som löser de problem som en typisk underhållsavdelning står inför. Och varför inte lite riktigt fina nätverksprylar? Det är alltid kul och är också på gång... Finns det något annat som du vill att jag utforskar och skriver om? Hör av dig till mats@ot-sakerhet.se ! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Några höjdpunkter den här gången är vi letar läckor i nätverket, lär oss teatersport, stjäl inloggningar i ABB-system, konstaterar att EU är överens om CRA, överraskas av en smart mojäng, fyller på i hemmalabbet och så läser vi två böcker, ett examensarbete, en doktorsavhandling och ett jättegammalt dokument! 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! Vad har teatersport med säkerhet att göra? Jag hörde nyligen en intervju om improvisationsteater och teatersport. En av tipsen för att bli en duktig teatersportare var att alltid säga "Ja!" oavsett vad dina motspelare hittar på. Jag kunde inte låta bli att tänka att samma sak gäller inom säkerhetsarbete! Jag menar inte att man som "säkerhetsperson" ska vara okej med vad som helst, men att inleda med "Ja" är ändå en möjlighet att skicka en signal att man faktiskt har samma mål som den man pratar med. Att man inte ser sig själv som en stoppskylt, en polis eller som "Mordac" från Dilbert. Säger man "Ja" och kvalificerar det med frågor om vad som ska uppnås eller kanske "Ja, men då behöver vi först..." så skickar man lite respekt för vad kollegan vill uppnå, som förmodligen faktiskt är något viktigt och klokt. Inom improvisationsteater tappar man tempo och flyt i handlingen om man säger "Nej". Inom säkerhet tappar verksamheten tempo och dessutom skapar man beteenden där man försöker kringgå säkerhetsrutinerna. När jag är ute och konsultar träffar jag emellanåt på säkerhetsfolk som verkar ha missförstått sin roll totalt och som tror att man framstår som kunnig genom att vara så motvalls om möjligt. Att bara säga "Nej" är enkelt, det behöver man ingen speciell kompetens för. Att förklara varför ett förslag är dåligt kräver inte så mycket mer. Men, om man är skicklig så klarar man att hitta vägar framåt tillsammans med organisationen så de når sina mål på ett sätt som inte stökar till säkerheten. Tillhör man den riktiga säkerhets-eliten så klarar man att skapa helt nya möjligheter för verksamheten genom att möjliggöra saker som tidigare var omöjliga. Då blir det lätt att få resurser för säkerhetsarbetet! Nu kommer CRA! Snart... Den sista november annonserade EU att man nått politisk enighet kring CRA, Cyber Resilience Act. (Jag har skrivit om CRA tidigare, exempelvis: Nyhetsbrev #48 och #51.) Det här är ett rejält omdiskuterat förslag, inte minst för dess hårdhänta påverkan på opensource-världen, men också på grund av kraven på att rapportera sårbarheter till EUs cybersäkerhetsmyndighet. I grunden handlar det om att produkter med digitala funktioner ska vara CE-märkta för att få säljas inom EU. CE-märkningen känner vi igen från andra områden men nu lägger man alltså även till krav på cybersäkerhet. Det ursprungliga förslaget presenterades i september 2022 och nu har man kommit överens om en rad kompromisser som ska göra det möjligt att klubba igenom kraven. De kompromisser som lyfts fram är enligt uppgift: Tillverkare måste tillhandahålla säkerhetsuppdateringar i minst fem år om man inte kan visa att livstiden för produkten är avsevärt kortare. Sårbarhetsrapporter och incidenter skall skickas till nationella myndigheter men ENISA har en stark roll. Kravmassan för hur certifiering av produkter går till har förenklats jämfört med det ursprungliga förslaget och antalet "kritiska produkter" har minskats. Hur man har skruvat på reglerna som påverkar opensource-projekt är inte helt tydligt ännu men förändringar har tydligen gjorts. Små företag ska få stöd i hur man praktiskt kan hantera kraven. När besluten är tagna kommer tillverkare, importörer och distributörer av hård- och mjukvara ha 36 månader på sig att ta till sig kraven. När det gäller kraven för tillverkare att rapportera sårbarheter och incidenter börjar de gälla redan efter 21 månader. Något datum finns inte ännu men man säger "...early 2024", så det är inte långt borta! I motsats till NIS2 är detta inte ett direktiv utan en förordning, vilket innebär att det gäller som lag direkt i alla EUs länder utan att man behöver stifta nationella lagar. När detta skrivs har jag fortfarande inte fått fingrarna på den uppdaterade texten så jag får återkomma med mina egna tankar om innehållet. Enligt "vanligtvis välunderrättade källor" så har alla OT-relaterade produkter strukits ur listan över viktiga och kritiska produkter. Däremot ska kopplingen mot NIS2 finnas kvar så att prylar som är viktiga för säkerheten i en "Väsentlig entitet" enligt NIS2 blir en "Kritisk produkt" i CRA vilket ställer höga krav på certifiering av produkten. Eric Byres på Adolus skrev en intressant kommentar kring kraven på SBOM och vilka dolda utmaningar som finns bland kraven i CRA. Värt att läsa! Personligen är jag generellt väldigt positiv till CRA, om inte annat för att vi till slut kanske slipper alla dessa mörkande tillverkare som inte låtsas om att deras produkter har haft sårbarheter. Förhoppningsvis har man nu lyckats minska påverkan på opensource-världen som jag uppskattar mycket! Hitta läckan i ditt nätverk? Oavsett om du har ett OT-nätverk som ska vara helt isolerat eller om det har kommunikation med omvärlden är det en utmaning att kontrollera att det inte finns några okända "läckor". Det är inte det minsta ovanligt att man hittar 4G-modem gömda i apparatskåp, att tillfälliga brandväggsregler råkar bli permanenta eller att utrustning har flera nätverksinterfaces som oväntat gör dem till en router. Vissa typer av kommunikation kräver dessutom mer än bara brandväggar för att kunna styras upp. Ett klassiskt knep för att kommunicera med omvärlden i smyg är att tunnla genom DNS-uppslag. (DNS, Domain Name System - det sätt som nästan alla nätverksanslutna prylar tar reda på adressen till andra prylar) Man tvingas ofta att tillåta DNS genom brandväggar men då måste din DNS-uppsättning begränsa hur namnuppslag skickas vidare ut på Internet... För att göra det ännu mer utmanande vill man ju upptäcka framtida förändringar i nätet som gör att det börjar "läcka". Även om skyddet är perfekt så förändras saker över tid och plötsligt så får någon ändring en oväntad sidoeffekt... Allt det här bygger förstås på att man faktiskt styrt upp både vad som får komma in i nätverket men också vad som får gå ut från det. Tidigare vad det vanligt, både mot Internet och mot industrinät, att man bara stoppade oönskad trafik som försöker ta sig in. Det är inte lika vanligt längre, mycket "tack vare" ransomware, men jag stöter fortfarande på det. Jag har genom åren provat produkter som löser det här problemet men ingen av dem har varit anpassade för OT-nätverk. Men det finns ett undantag, det finska företaget SensorFu har med produkten "Beacon" löst precis det här problemet. Och de har gjort det med just OT-nätverk i fokus! Det är egentligen en väldigt enkel lösning. Du placerar ut en eller flera Beacons i ditt nätverk och en hemmabas kallad "Home". Dessa Beacons försöker hela tiden kommunicera med sitt Home som du placerat på Internet eller på något annat nät som inte borde gå att nå. Beacons använder diverse olika trix att nå till Home och lyckas de så får du ett larm med information om hur de "tog sig ut". Det är just de här försöken som gör SensorFus lösning unik, det är här anpassningen till OT syns tydligt. Det är förstås viktigt att de här försöken inte stör nätverket eller automationsutrustning! En Beacon gör sina tester i ett väldigt lågt tempo och använder inte tester är "stökiga" på nätet. En Beacon finns i olika former. Du kan köra det som en applikation i Windows eller Linux, skapa en container eller en virtuell maskin. Vill du köra Raspberry PIs så finns officiellt stöd för det också. Hemmabasen Home kan du antingen köpa i molnform eller köra själv i en Linuxmaskin. Själv provade jag både att automatiskt skapa en virtuell maskin, en Linux-applikation och en LXC-container i hemmalabbet. Testerna inkluderar direktanslutning via TCP och UDP, broadcast via Ethernet, DNS-uppslag, Ping, Spoofade avsändaradresser och oväntade IP-protokoll som IGP, IGMP eller TLSP. Dessutom använder den både IPv4 och IPv6. Har du koll på hur ditt OT-nät hanterar IPv6? (De flesta har inte det...) I exemplet nedan var nätet helt blockerat av en brandvägg förutom för DNS över UDP vilket förstås räcker för en läcka. Det finns många situationer där läcksökning är viktigt. Naturligtvis är det inte bara inom OT som det här är viktigt, känsliga IT-nätverk inklusive privata cloud-nät är precis lika klurigt att hålla koll på. Några vanliga exempel kring OT är: OT-nät som enbart ska kunna kommunicera med prylar på ett DMZ Jumphosts som bara ska vara åtkomliga via en säker lösning för fjärråtkomst Nät för fysiskt skydd, kameranät eller passagesystem Datorer som aldrig någonsin ska nätanslutas, exempelvis programmeringsverktyg för safety-system eller kanske en root-server för PKI Managementnätverk där systemadministratörer utför de allra mest känsliga arbetsuppgifterna Det här är en produkt som jag verkligen rekommenderar alla att prova. Även om du ska ha öppningar i nätverket är det förstås viktigt att det inte finns andra "läckor" som du inte har koll på. Det man vet om kan man hålla koll på... Produkten är superenkel att använda och resultaten kommer direkt! Hör gärna av dig så hjälper jag till att ordna en test. Vissa saker måste man göra själv! En artikel från Otorio tittar på sätt att stjäla administratörsrättigheter från ABBs 800xA-system. Jag ska påpeka att artikeln inte kritiserar säkerheten i systemet, snarare tvärtom - men det är en påminnelse om att vissa saker behöver man se till själv när man implementerar ett system. I 800xA-fallet är det skydd av kommunikationen, exempelvis genom att använda IPSec på det sätt som ABB föreslår i anvisningarna. Här är det lätt att man missar viktiga krav i samband med upphandlingar eller systemdesign! Exemplet som Otorio visar i artikeln och videon nedan är en kapning av kommunikationen med en Aspect-server. Vi behöver en lokal! Ni som är tillräckligt gamla kommer kanske ihåg att Johan Ulvesons karaktär Nisse Näslund från TV-programmet Lorry myntade uttrycket "Vi har ju ingen lokal ju!". Jag har en fundering på att skapa en "lokal" för oss OT-människor där man kan diskutera OT-säkerhet, bolla klurigheter, be om hjälp eller sprida bra information. Kanske ett diskussionsforum eller något liknande, helt separat från alla sociala medier, där vi kan diskutera OT-säkerhet. Är det något som du tror du faktiskt skulle använda? Har du åsikter om vad som är viktigt i så fall? Hjälp mig genom att skicka dina spontana tankar till mig på mats@ot-sakerhet.se eller kommentera det här nyhetsbrevet på LinkedIn. Alla andra åsikter och önskemål om nyhetsbrevet tas förstås också emot med väldigt stor tacksamhet! Andrew Ginter har gjort det igen! Han är ett känt namn i branschen och från den podd han skapat hos Waterfall Security. Nu har han skrivit sin tredje bok och den är som vanligt gratis om du ber om den från Waterfall direkt. Skynda dig att beställa! Den har precis landat i min brevlåda så jag har ingen åsikt ännu men jag har hört positiva omdömen från andra. Han diskuterade den nyligen med Dale Peterson på Dales podd. Andrew skrev också ett förtydligande på LinkedIn efter intervjun. De två tidigare böckerna är något av klassiker i branschen och jag vet flera kloka kollegor som startat sina karriärer genom att läsa dem! Stark rekommendation! En annan bok som jag verkligen rekommenderar, åtminstone om du är intresserad av säkerhetsskydd är Kim Hakkarainens bok "Säkerhetsskydd - En introduktion". Den har precis kommit i en uppdaterad andra utgåva. Jag tycker mig själv ha bra koll på säkerhetsskydd men redan på första sidan i boken var jag tvungen att säga "Jasså? Det hade jag inte koll på!". Det här är ett klurigt ämne men Kim kombinerar ett sinne för detaljer med en förmåga att skapa överskådlighet och tydlighet, vilket gör boken lätt att både läsa och att hitta i. Den funkar definitivt både som lärobok och som uppslagsverk oavsett om du är ny eller senior inom säkerhetsskyddet! Nu får det vara slutlekt! Ja, det är faktiskt den underbara titeln på ett examensarbete om NIS2 som Ellinor Dison skrivit vid Stockholms Universitet. Undertiteln är "Cybersäkerhetskraven för privata aktörer i ljuset av NIS2-direktivet". Hon skriver ingenting specifikt kring just OT-säkerhet, men jag måste säga att det är en rejäl sammanställning av området med många kloka resonemang och intressanta jämförelser med NIS-direktivet. Rekommenderas för alla NIS2-intresserade! Bra texter måste inte ha en rolig titel! Jämfört med Ellinors examensarbete har inte Björn Leanders doktorsavhandling vid MDU, Mälardalens Universitet: "Dynamic Access Control for Industrial Systems" den roligaste titeln i världshistorien. Men den innehåller å andra sidan desto mer OT-säkerhet, vilket ju är väldigt roligt i mina ögon! Roligt är också att den faktiskt tittar på praktiska lösningar för intressanta problem vi kommer stå inför när våra automationssystem framöver börjar se annorlunda ut än idag. Det där med "Industri 4.0" och "Industrial Internet" har vi knappt sett början på ännu! Avhandlingen tittar på dynamisk accesskontroll med målet att stötta ett införande av Zero-trust i OT-system inom tillverkande industri. Det kanske låter lite tungt att läsa en doktorsavhandling? Och så kan det ofta vara, akademi och industri har verkligen olika sätt att göra saker. Men jag tycker Björn har lyckats göra sin text riktigt läsbar och intressant. Är man det minsta intresserad av ämnet så ska man absolut läsa den! Det finns faktiskt en massa andra bra anledningar att läsa avhandlingen också. Bara i kapitel 2, "Bakgrund" beskriver Björn en massa bra baskunskaper som är värda att läsa på deras egna meriter. Exempelvis trender i avsnitt 2.2 där vi, kortfattat men väldigt tydligt, får förklarat skillnaderna mellan den "gamla skolan" där det gäller att hierarkiskt strukturera dataflöden i automationssystem enligt Purdue-modellen kontra den "nya" nätverksbaserade modell som bland annat förespråkas i OPAS-standarden. (Sök i nyhetsbrevet, jag har skrivit om OPAS förut!) Nyttigt att ha koll på när vi snart börjar röra oss mot den fjärde industriella revolutionen på riktigt! OT-system kommer byggas väldigt annorlunda om några år! Björns arbete ställer flera intressanta frågor och försöker förstås också svara på dem. Ett grundläggande exempel för accesskontroll är "Hur beskriver man regler för accesskontroll på ett sätt som passar i en extremt flexibel tillverkningsmiljö?" Det låter som en enkel fråga men i en tänkt framtid där alla system har tillgång till all data och där tillverkningsprocessen i sig själv dynamiskt (och automatiskt) förändras efter behoven blir det en riktigt klurig nöt att knäcka! Arbetet ger förstås inte alla svar som behövs men i Björns sammanfattning får vi en radda intressanta frågor för framtida arbete: Arbetet fokuserar på kommunikation mellan enheter. Motsvarande arbete behövs för mänsklig interaktion och kommunikation med helt andra system. Hur man praktiskt integrerar resultaten i industriella produkter? Dagens PKI-lösningar är anpassade för IT-användning, hur ser en vettig PKI-lösning ut för industriellt bruk? I traditionella automationssystem är det väldigt tydligt vilken enhet som äger en viss utsignal. I framtida nätverksbaserade lösningar är det inte självklart och behöver styras upp. Jag rekommenderar varmt egen läsning i avhandlingen. För den som inte får nog har Björn och hans medarbetare skrivit en radda intressanta papper. Vissa av dem ingår i avhandlingen och andra inte. Några exempel är: Access Control Models to secure Industry 4.0 Industrial Automation and Control Systems som även innehåller de här artiklarna: Cybersecurity Challenges in Large IIoT Systems Applicability of the IEC 62443 standard in Industry 4.0 / IIoT Access Control for Smart Manufacturing Systems A Recipe-based Algorithm for Access Control in Modular Automation Systems Towards an ideal Access Control Strategy for Industry 4.0 Manufacturing Systems Access Control Enforcement Architectures for Dynamic Manufacturing Systems Simulation Environment for Modular Automation Systems Classification of PROFINET I/O Configurations utilizing Neural Networks Anomaly Attack Detection in Wireless Networks Using DCNN Developing and Evaluating MQTT Connectivity for an Industrial Controller Dependability and Security Aspects of Network-Centric Control Enhanced Simulation Environment to Support Research in Modular Manufacturing Systems Jag var på plats på MDU när Björn presenterade sin avhandling. Som opponent hade man tagit i rejält och plockat in Marina Krotofil (som jag skrev om senast i Nyhetsbrev #54). Marina, tillsammans med en betygskommité, ställde en lång radda utmanande frågor som Björn hanterade galant. I slutändan blev omdömet "Godkänt" så ett stort grattis är på sin plats! Det här är ett spännande område där vi kommer se att mycket förändras framöver, och tyvärr inte alltid åt ett håll som vi säkerhetsmänniskor gillar. Grundtänket kring identitetsstyrd åtkomst, som numera oftast går under slagordet "Zero trust", har alltid varit rätt - därom har jag inga tvivel, även i OT-världen. I slutänden tror jag att en kombination av traditionella segmenteringsåtgärder och "zero trust"-inspirerad åtkomststyrning i linje med Björns tänk kommer bli framgångsrikt i många branscher. Jag skulle dessutom vilja lägga till motsvarande "zero trust"-tänk i infrastrukturen baserat på Software Defined Networking som anpassar sig efter aktuella behov på samma sätt som den dynamisk åtkomststyrningen. Det är en spännande framtid som väntar för oss som är nördar inom både säkerhet, teknik och industriella processer! Det smällde i Danmark och Pennsylvania! Om du är intresserad av OT-säkerhet har du förmodligen redan koll på händelserna i Danmark och . Om inte, så hittar du den danska rapporten från SektorCERT här tillsammans med ett par artiklar från media: Govinfosecurity och Industrialcyber. Händelserna i Aliquippa, Pennsylvania kan du läsa om i en rad artiklar. Exempelvis SecurityWeek, CSO och en text från WaterISAC. En oväntat kompetent mojäng! I mitt kära hemmalabb är det förstås fokus på säkerhetsprylar. Den här gången blev det något av en överraskning hur mycket annat än "bara säkerhet" som man ibland får på köpet. Fast förmodligen skulle tillverkaren säga att det är säkerheten man får på köpet... En viktig del i säkerheten de senaste åren är att kunna jobba med integrationer och dataflöden på ett säkert sätt. Det är precis i den nischen som den här produkten är tänkt att excellera - och utan att avslöja för mycket redan tycker jag att den verkar göra ett bra jobb! Jag fick nyligen fingrarna på en "Ewon Flexy 205". Ewon är från början ett belgiskt företag som numera ingår i den svenska "HMS Networks"-koncernen. HMS annonserade för övrigt tidigare i veckan att man köper amerikanska företaget Red Lion Controls, vilket känns som en jättebra matchning! Red Lion köpte i sin tur tyska firman MB Connect Line för ett år sedan, intressant utveckling... Tanken från min sida var att komma över en enkel och rimligt säker VPN-produkt så att jag kan nå hemmalabbet på distans. Till det yttre ser den kanske inte så imponerande ut. En ganska enkel plastkapsling med DIN-fäste och fyra RJ45 nätverksportar. Inget märkligt så långt... Sedan inser man att den har två kortplatser där man kan kombinera olika typer av instickskort för att utöka funktionaliteten. Det visar sig att det finns en radda kort som man kan stoppa i, exempelvis med MPI-port för att prata med PLC:er från Siemens, ytterligare nätverksportar, 4G, WIFI, Serieportar eller kanske USB? Dessutom finns det en lucka där man kan stoppa in ett SD-minne! Hmm? Vad är det här för en manick jag fått fingrarna på egentligen? I mitt fall sitter ett kort instucket med ett gäng digitala och analoga in- och utgångar. Hmm? Ett IO-kort? På en VPN-server? Intressant... När man vänder på den och tittar på anslutningen för strömförsörjning så finns det även där ett par digitala in- och utgångar som är inbyggda i grundenheten. Det visar sig att det här är en M2M-router, alltså en lösning för att få maskiner att kunna prata med andra maskiner. Ett mer poppigt namn på samma sak kanske är IIoT-gateway? Att jag kan använda den som VPN-router är bara en liten fotnot i listan över vad det här underverket kan leverera. Att få igång enheten på nätverket är enkelt med hjälp av wizards. Att få igång fjärranslutning kräver bara att man registerar ett konto på Ewons webbtjänst och kör en konfigurations-wizard. Sedan börjar det roliga. Vill man ha direktkontakt med en PLC så finns beskrivningar för hur man konfigurerar sin PLC från Siemens, Yaskawa, Omron, Rockwell, Schneider osv. Kom ihåg att det här inte i första hand är en klassisk VPN-server utan en integrationsplattform. Den kan själv suga i sig data via OPC UA, MODBUS TCP, BACnet, http, ftp eller en rad leverantörsunika protokoll för olika fabrikat av PLCer. Som "vanligt" skapar du taggar i Flexyn för den information som ska hanteras. Taggarna kan vara enbart för läsning eller tvåvägs så att man kan skriva värden via Flexyn. Taggarna kan du sedan sätta loggning för, övervakning på och definiera larm för. För att exportera data kan enheten skicka loggfiler eller definiera egna taggar som kan läsas av andra enheter via MODBUS TCP, SNMP (!) eller den inbyggda servern för OPC UA. Om man vill kan data löpande exporteras externt via Ewons molntjänst, Talk2M. Den kan också extraknäcka som konverterare till seriella protokoll! För att styra upp nätverkstrafiken finns grundläggande brandväggsfunktioner och NAT-funktionalitet på plats. Vill man koppla den mot andra VPN-tjänster har den även en OpenVPN-klient inbyggd! Om man tittar på de olika instickskorten så finns en radda intressanta möjligheter. Seriekortet har två portar, en RS232 och en konfigurerbar RS232/RS422/RS485 med eller utan terminering. Kortet med nätverksuttag är precis bara det, om man behöver fler än de fyra inbyggda nätverken kan man få fler. Korten med WIFI eller 4G är precis vad det låter som och USB-kortet kan exempelvis användas för att komma åt USB-enheter på distans som om de vore lokala! Sedan visar det sig till slut att man kan bygga HMI-sidor i enheten som publiceras av den inbyggda webbservern och till på köpet går det att programmera egna funktioner i Java. Jisses vilken mackapär! Snacka om att jag missförstod den här lilla lådan när jag fick den i handen! Den kanske inte var den VPN-tjänst som jag trodde, men det är ju inte heller meningen med den! För den som vill bygga dataflöden på distans eller samla in (och presentera) data från andra enhet så imponerar mängden funktionalitet rejält! Det verkar dessutom finnas allt man kan önska sig för att skapa en säker lösning. Man ska tydligen inte döma M2M-routern efter utseendet! Principer för industriell cybertålighet WEF, World Economic Forum, har gett oss ett whitepaper med titeln "Unlocking Cyber Resilience in Industrial Environments: Five Principles". Innehållet är precis vad titeln hintar om, fem principer som är grundläggande för god OT-säkerhet: Riskhantering Ansvar för OT-säkerhet Samordning med ledning och strategi Skapa säkerhetsstandarder och rutiner Öva, öva, öva! Det är inte på något vis ett revolutionerande dokument men det är kraftfullt att kunna referera till vad WEF säger när man diskuterar prioritering och resurssättning! Nyhetsbrevet växer! Jag vill tacka dig som läser och sprider nyhetsbrevet vidare. För varje upplaga så blir det fler som läser det, vilket säger mig att det fortfarande finns ett behov och ett intresse för den här typen av innehåll! Strax efter att förra nyhetsbrevet släpptes slog vi ett nytt rekord med 450 läsare på en enda dag. Kul! Att jag driver nyhetsbrevet vidare bygger mycket på det gensvar som jag får. I grunden kommer nyhetsbrevet även i fortsättningen baseras på att jag dammsuger OT-världen efter de mest intressanta nyheterna och skriver om dem. Jag roade mig med att ta fram lite statistik kring vilka nyhetsbrev som har väckt mest uppmärksamhet. Det är ganska tydligt att det är tre saker som just nu ligger i topp när det gäller att skapa lite extra intresse från dig som läser: NIS2 Hemmalabbet Mina egna reflektioner kring branschens utmaningar Att det är de tre är extra kul med tanke på att det är tre ämnen som jag gillar att skriva om! NIS2 kommer ju bara bli mer och mer aktuellt i takt med att vår deadline närmar sig. Hemmalabbet kommer jag försöka prioritera mer framöver även om det tar mycket tid och det är svårt att komma över spännande utrustning. Donationer och lån av prylar mottages tacksam! Mina egna reflektioner kring trender och gemensamma egenheter jag stöter på hos mina kunder kommer ganska naturligt, så det blir det mer av framöver också! Tack för ert intresse! Många svenskar på plats! Tittar just på deltagarlistan för nästa S4-konferens och ser 12 personer som är registrerade från Sverige! Kul! Biljettförsäljningen slår tydligen (som vanligt) rekord och de sista 250 biljetterna säljs nu. Agendan börjar bli klar och ser (också som vanligt) superintressant ut! Ska bli kul! Lite fundersam blir jag över att det (än så länge) bara är en enda deltagare från det privata näringslivet! (Förutom alla vi konsulter och produktleverantörer förstås!) Konferensarrangörerna ser ju också detta som ett problem och testar i år begränsningar i hur många deltagare en konsultfirma får ha. Dessutom är de sista hundra biljetterna reserverade för "Asset owners". Vi ses där! Attacker mot olja och gas TxOne har givit ut en välfylld rapport kring olje- och gasindustrin som ju är en verksamhet med väldigt speciella förutsättningar och som är extra utsatt av många olika skäl. Vi får en genomgång av branschen, en analys av hotlandskapet och förstås en analys av de olika delarna i typiska attacker, inledande access, lateral förflyttning, påverkan och konsekvenser samt (förstås) tankar kring hur man kan motverka de olika delarna i attackerna. På vägen får vi en analys av typiska problem i vanliga systemkomponenter inklusive OPC UA, som har bred spridning i den här branschen. Totalt 28 sidor som man tar sig igenom ganska enkelt. Inte OT men intressant ändå... En intressant artikel om tåg som saboterades av tillverkaren för att ingen annan leverantör skulle kunna göra underhåll på dem. Om det inte hade varit för att jag själv faktiskt varit med om något liknande i ett IT-system skulle jag knappt tro på historien! Man kan väl mycket väl tänka sig något liknande sabotage i klassiska OT-system? Ett fantastiskt sätt att bli rejält svartlistad som leverantör är det oavsett! Senaste nytt från hemmalabbet För den som är tekniknörd och intresserad av vad som händer i mitt labb för OT-prylar hemma så har jag gjort ett om-tag kring virtualisering. En bättre begagnad mini-PC (6 CPU cores, 32 GB RAM) kör nu Proxmox vilket erbjuder otroligt smidig virtualisering och hantering av Linux-containers (LXC). Nätverket har fått en ny VLAN-indelning vilket gör att jag kan hantera ett gäng separata nätverk med en blandning av virtuella system, containers och förstås fysiska OT-prylar. Som gammal Unix/Linux-hacker är det helt underbart att återvända till den världen via Proxmox som verkligen är makalöst kraftfullt! Ett antal system har redan "flyttat in", först ut var virtuella administrationskonsoler för säkerhetslösningar som exempelvis TxOnes EdgeOne, en installation av Kali-Linux och agenter för SensorFu Beacon som du kan läsa om på annan plats i det här nyhetsbrevet. Till nästa nyhetsbrev pågår redan experiment med en riktigt imponerande lösning för att hantera fjärråtkomst för leverantörer och annat "löst folk". Återkommer om det! Gammal är äldst! Såg ett inlägg på LinkedIn häromdagen som påminde mig om ett av de äldsta OT-säkerhetsdokument som jag kan minnas att jag läste "på den gamla goda tiden"; "21 Steps to Improve Cyber Security of SCADA Networks". Det gavs ut 2002, alltså fyra år innan Stuxnet ens hade börjat planeras! Att det kom till just 2002 är ingen slump, det bedrevs en hel del nyskapande riskanalysarbete efter attackerna den 11:e september 2001! Det är värt att notera att allt som skrevs då fortfarande är lika relevant. Man uttrycker sig lite annorlunda och har kanske en lite annan ordning i prioriteringarna, men i grunden ändå väldigt likt. Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.