top of page

Sökresultat

57 resultat hittades med en tom sökning

  • Nyhetsbrev OT-Säkerhet #69

    Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången förbereder vi oss på Ransomware i OT-miljöer, tittar på MSBs nya ”OT-Säkerhetskollen”, imponeras av NSA som kompletterar IEC 62443, räknar om CVSS för OT-system, funderar på begreppet ”hygien”, läser om AI i kritisk infrastruktur, får massor av klokskap från Nederländerna, läser gratis-standarder, funderar över leverantörskedjor och letar spöken i fastighetsautomation. 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! Har du koll? MSB släppte nyligen årets version av Cybersäkerhetskollen som numera även innehåller OT-Säkerhetskollen! Min spontana reaktion var att det var väldigt snabbt marscherat eftersom det här var en av sakerna som vår nya nationella cybersäkerhetsstrategi sa skulle produceras fram till 2027. Snyggt jobbat! Jag är försiktigt positiv till hur OT-Säkerhetskollen är utformad, även om jag alltid har lite svårt för listor som indirekt insinuerar att mer säkerhetsåtgärder självklart är bättre - oavsett riskexponering, oavsett kostnad och oavsett om åtgärderna har meningsfull effekt. Men vi ska komma ihåg att syftet med materialet är att skapa en bild i stort av hur det står till i landet och det tror jag det kan passa väldigt bra för. Det ska bli väldigt intressant att se resultatet och jag kommer nyfiket fråga runt bland de som fyller i den hur de uppfattar OT-delen. Du får väldigt gärna höra av dig med dina tankar till mig: mats@ot-sakerhet.se ! För dig som är utvecklare av OT-komponenter! Två organisationer som är nära kopplade till ISA, ISAGCA (ISA Global Cybersecurity Alliance) och ISASecure har tagit fram ett dokument där man mappar ISAs kravstandard för mjukvaru-utvecklingsprocesser ISA/IEC 62443-4-1 mot USAs Secure Software Development Framework från NIST SP 800-218. ISA-standarden är ju helt OT-fokuserad medan SSDF är helt generell så det kan vara en användbar jämförelse. Personligen tycker jag mig se att trenden mot att tillverkare av komponenter och mjukvaror för OT-kunder allt mer satsar på att certifiera sina processer mot ISA/IEC 62443-4-1 och ofta gör motsvarande arbete för själva produkterna - fast då mot ISA/IEC 62443-4-2. I takt med att intresset för leverantörernas del i den totala säkerhetsbilden, exempelvis kopplat till NIS2, så är detta en klok och viktig väg framåt. Det där med hygien? Ett begrepp som jag alltid haft lite svårt för är "Cyberhygien". Jag har inte riktigt kunnat förklara varför jag inte gillade det, men jag tyckte definitivt att det användes väldigt slentrianmässigt och det hintade om en lista med säkerhetsåtgärder som magiskt passar för alla. Dessutom ofta använt med en underton av att det egentligen är ganska enkelt; "om alla bara skötte sin cyberhygien så skulle vi inte ha några cyberproblem". I IT-världen kopplas det gärna ihop med att allt ont som händer beror på användare som är så korkade att de klickar på länkar. Att dålig hygien kan leda till virusinfektioner är förvisso en lite rolig lek med orden! Jag vägrar hålla med om att användares sunda förnuft ska vara vårt viktigaste försvar mot allvarliga tråkigheter eller att samma nivå på hygien ska vara rimliga för alla. Säg åt en HR-person att man inte får öppna bilagor som skickats till dem med mejl... Eller att Bengts Mekaniska AB ska ha samma krav på cyberhygien som kontrollsrumspersonalen på kärnkraftverket i Ringhals... Nu har jag till slut förstått vad jag störde mig mest på med cyberhygien-begreppet! Det som skaver är att man alltid verkar betrakta hygien som förmågan att helt undvika att drabbas av angrepp, men sedan helt glömmer bort förmågan att reagera när något udda ändå är på väg att hända. Det är när man bedriver säkerhetsarbete på det sättet som säkerhetsåtgärderna blir onödigt störande för verksamheten. Det leder ofelbart till att medarbetarna betraktar säkerhetsfolket som besvärliga och gör sitt bästa för att kringgå säkerhetsåtgärderna för att "kunna jobba". Jag menar inte alls att kloka medarbetare eller cyberhygien är dåligt. Hygien i vardagen är viktigt - men det ska vara rätt hygien på rätt plats. Det ställs olika krav på hur jag tvättar händerna och hur en sjuksköterska gör det! Åtgärder som är anpassade efter riskerna kommer respekteras! En patient som löper större risk att drabbas av infektioner kan vi övervaka noggrannare och ta prover oftare! Dessutom vet vi också att även sjuksköterskor blir förkylda, så det finns inga garantier trots hygienen - trots handtvätten gäller det att vara vaksam på symptom och reagera snabbt när de kommer! På samma sätt måste riskhanteringen skilja mellan olika delar av en verksamhet och oftast mellan IT och OT. Den som håller på med förberedelser inför NIS2 just nu har förhoppningsvis gjort begreppet "proportionalitet" till sin bästa vän - just för att kunna fokusera "hygienen" där den är som viktigast! Med den här tolkningen av hygienbegreppet så tycker jag personligen det blir mycket mer användbart och rimligt! AI + Kritisk infrastruktur = ? ISA och Automation.com har tagit fram ett tydligt material som tittar på hur AI (främst generativ AI men även Machine Learning) kan användas inom kritisk samhällsinfrastruktur. Det är skrivet med ett USA-perspektiv och med extra fokus på energi-branschen, men resonemanget går att överföra till andra länder och till andra branscher. Sammanfattningen säger ganska väntat att AI-lösningar inte kan användas i sammanhang där deterministiska lösningar är nödvändiga: Andrew Bochman har publicerat en artikel med hans tankar kring innehållet och lite hintar om vad INL pysslar med i sammanhanget. Kan CVSS användas inom OT? Du är förmodligen bekant med CVSS, The Common Vulnerability Scoring System , som används för att definiera hur allvarlig en sårbarhet är på en skala mellan 0 och 10. Det är förstås en extrem förenkling att beskriva en sårbarhet enbart med en siffra, men samtidigt vill man ju i alla fall att siffran är så meningsfull som möjligt. Roger Hill beskriver i en artikel ett sätt att få CVSS-poäng att passa bättre i OT-världen genom att räkna om dem och ta hjälp av de delar som redan finns tillgängliga i CVSS-definitionen. Väl värt att tänka på för den som jobbar med att prioritera sårbarheter. NSA tänker till om PLC:er på ett riktigt intressant sätt! NSA i USA har publicerat en teknisk rapport med titeln: " Smart Controller Security within National Security Systems " som var oväntat intressant! De har gjort en analys som utgår från kraven i NIST SP 800-53 Rev. 5 och mappade dem mot kraven i IEC 62443-4-2. Man utgick från de lagkrav som gäller för system med nationell säkerhetspåverkan i USA och mappade dem mot nivå SL-3. De komponenter man har haft i åtanke är "Smart Controllers", vilket man definierat som PLC:er och andra controllers som har "avancerade" förmågor. Det kan vara mer beräkningskraft för realtidsanalys, utökade kommunikationsmöjligheter och dataanalysförmågor, "Edge computing", direkt i den enskilda controllern. Det man kom fram till var att 74 krav från 800-53 var relevanta i det här sammanhanget, men det intressanta var att man hittade 13 som inte togs omhand i 62442-4-2! Som lösning har man helt enkelt föreslagit nya krav. (1 st CR och 5 st RE) Resultatet kommer användas för deras test-processer men har också skickats till ISA för att tas omhand i kommande uppdateringar av standarden. Som du kan se i tabellen var det en rad säkerhetsåtgärder, från helt olika områden, som man identifierade. Kul och seriöst sätt att utveckla standarden! Tack NSA! Om jag förstått det rätt är förresten det här definitionen av ett National Security Systems (NSS): Där får man ändå ge USA lite cred för att man tagit ett bra grepp kring OT-säkerheten i lite mer "utmanande" systemlösningar, inte minst de som är inbyggda i vapensystem. Jag vet av egen erfarenhet att regelverk inom militär verksamhet annars tenderar att fastna lite vid att skyddet av känslig information är det enda viktiga i världen... Alltid redo? Lesley Carhart har skrivit ett utmärkt whitepaper kring hur man förbereder sig inför Ransomware i sin OT-miljö som är publicerat via SANS. Man kan definitivt häva att det finns andra typer av attacker som enklare kan få riktigt allvarliga konsekvenser, men ska man fokusera på vad som är mest troligt i de flesta verksamheter så är det utan tvivel ransomware. Det kanske inte är avsett att drabba OT-verksamheten i sig men det brukar lätt bli produktionspåverkan även om det "är IT som egentligen drabbats". Är man förberedd för just ransomware så kommer man på köpet att ligga mycket bättre till även när andra typer av incidenter inträffar, även om de inte orsakats av någon illvillig hacker! Sista ordet kring CIA-triaden i OT-världen! Den person som jag refererar allra oftast till i nyhetsbrevet är Sinclair Koelemij, som trots sin pensionering (eller kanske tack vare?) fortsätter producera artiklar som jag ofta önskar att jag skrivit själv. Den här gången sätter han punkt för diskussionen kring varför Confidentiality/Integrity/Availability passar dåligt i OT-världen och varför Controllability/Observability/Operability är en mycket listigare trojka av ord. Det hade räckt där, men sedan följer han upp med ytterligare en artikel med ett riktigt klokt ifrågasättande av hur vi definierar begreppet "OT"! Själv brukar jag ibland roa mig med att försöka provocera folk lite genom att säga att "IT är systemen som stöttar verksamheten, men OT är verksamheten". Sinclair tar den tanken och vrider den ett varv till genom att flytta fokuset för vad OT är, från system och komponenter till den fysiska processen - där den förstås hör hemma. Han argumenterar för sin syn med en radda positiva effekter som detta synsätt ger oss i vårt sätt att arbeta med risk. Och när han redan var igång så fick vi dessutom en artikel med kloka insikter kring hur CRA-förordningen påverkar automationsbranschen . Exempelvis pekar han på de kluriga gränsdragningar som systemintegratörer kommer behöva hantera. Spännande! Jag kan bara säga "Läs!". Och tack till Sinclair! Läs EUs standarder gratis! En viktig del när EU skapar så kallade "Harmoniserade standarder" är att de ska vara tillgängliga gratis. Hur man gör det beror lite på vilket land man befinner sig i, men man kan alltid hitta rätt via https://harmonized.standards.eu/ . Är du i Sverige så kommer du till slut hamna hos SIS där du kan registrera dig och komma åt CEN- och CENELEC-standarder. De här standarderna kommer bli allt viktigare framöver. Närmast framöver kommer du höra om dem allt oftare i samband med det uppdaterade Radiodirektivet och sedan även CRA-förordningen. Dags att se över EUs sätt att arbeta med cybersäkerhet? EU-kommissionen efterlyser nu dina åsikter kring hur man kan utveckla arbetet med cybersäkerhet inom EU. Det handlar om CSA, "Cyber Security Act" som ligger till grund för bland annat ENISA, EUs cybersäkerhetsmyndighet, men också allt arbete som pågår med bland annat certifieringskrav. Man verkar tänka stort och öppet vilket syns i att man formellt överväger fyra radikalt olika vägval: Har du en åsikt om detta så är det dags att säga ifrån nu ! 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 ! Uppdatering till sjöss! IMO, som är FNs organisation för sjöfart är på väg att släppa en uppdaterad version av sina rekommendationer kring cybersäkerhet . Den enes kund är den andres leverantörskedja En gammal fråga, inte minst inom OT-världen, är hur vi ska se på säkerheten hos våra leverantörer. Den har blivit extra mycket i fokus på senare tid tack vare NIS2-direktivet och CRA-förordningen. När det gäller NIS2 så handlar ju den i grunden om att samhället nu ställer krav på "cyber-resiliens" i samhällets egna leverantörskedjor; den som levererar något som samhället är beroende av behöver se till att både egen cybersäkerhet och underleverantörernas cybersäkerhet möjliggör stabila leveranser även under säkerhetsincidenter. Det har dykt upp ett antal tjänster på marknaden som hjälper organisationer att följa upp cybersäkerheten hos deras leverantörer. I alla de exempel som jag har tittat på handlar det om att leverantören får självskatta sina förmågor utifrån ett antal frågor; "Har ni en säkerhetspolicy?", "Använder ni MFA för remote access?" och så vidare. Jag tycker det i grunden är positivt att dessa tjänster dyker upp eftersom det kommer sätta ljus på den oerhört svåra fråga som leverantörsuppföljning faktiskt är, i synnerhet när det handlar om säkerhetsfrågor! Däremot är jag skeptisk till att dessa tjänster verkligen ger en sann bild av den samlade riskprofilen för ett företag - men det är en diskussion för en annan dag... En insikt jag fått i dessa diskussioner är att nästan alla missar sin egen roll i samhällets leverantörskedjor - det blir väldigt mycket fokus på att jaga underleverantörerna, men mycket mindre på att bedöma vilka risker den egna organisationen orsakar för kunderna och samhället! Detta blir dessutom rörigt när NIS2 kommer på tal eftersom många verkar missförstå hur kraven därifrån "drabbar" organisationer och underleverantörer... När man börjar fundera över detta blir det snabbt tydligt hur snabbt det blir väldigt komplext när man tittar på leverantörskedjor. Jag ritade den här bilden för att försöka göra det lite begripligt. Det blev det nog inte... (Om du lätt får ont i huvudet så kanske du ska sluta läsa här...) Orange pilar symboliserar leverans av någonting från en leverantör till en kund och en leverans är alltid kontraktsmässigt kravställd, vilket visas som gröna pilar. Lila pilar är samhällets NIS2-krav på leverantörer. Samhället är ju en lite speciell kund som kan ta många skepnader men jag ritar den som en stor kund för enkelhetens skull. Det man snabbt inser är att om leveransen flödar i de orangea pilarnas riktning så flödar kundens krav på leveranserna åt andra hållet, enligt de gröna pilarna. Man inser också att NIS2-krav och leveranskrav kan vara (och ska vara) helt olika saker. I min modell har jag fyra olika exempel på leverantörer. I verkligheten är det förstås oerhört mycket mer komplicerat, men det här får räcka för mitt resonemang. Det blir nog stökigt ändå! A och B omfattas av NIS2, medan C och D inte gör det. En viktig insikt som man ser direkt är att en organisation kommer få krav från flera olika håll samtidigt beroende på vilka kunder den har. Det är rimligt att anta att dessa krav ställs på olika sätt och med olika nivå så arbetet att se till att man kan leva upp till allihop kan bli utmanande... Det är just den här rörigheten och utmaningen kring varifrån kraven kommer som jag vill försöka reda ut här. Jag hör tyvärr fortfarande ofta resonemang i stil med: "Vi omfattas av NIS2 och som leverantör till oss så måste ni också uppfylla NIS2" Om du frågar mig är det ett riktigt dåligt sätt att ställa krav på sin leverantör. Det leder inte  till att kunden uppfyller sina egna åtaganden kring leveranstörskedjan enligt NIS2! Hur träffas då de fyra typ-organisationerna av kraven? Organisation "A" A omfattas själv av NIS2 och kommer därför träffas av krav "direkt från samhället", de lila pilarna i bilden. Här gäller det att ta till sig tänkesättet i NIS2 - att förstå vilka risker man utsätter både sig själv för, men också samhället, så att man kan ta hand om riskerna på ett "proportionerligt" sätt. Fokus ska vara på att kunna producera även om man utsätts för attacker eller drabbas av andra typer av incidenter! A kommer också få krav på sig som en del av respektive leveranskontrakt, de gröna pilarna. En utmaning blir då att kombinera dem med NIS2-kraven. En komplikation för vissa organisationer är om de är verksamma i flera NIS2-sektorer och kommer då träffas av föreskrifter från flera olika tillsynsmyndigheter. Det är ännu oklart hur mycket möda myndigheterna kommer lägga på att synka sina krav med varandra. Om A dessutom själv är kund till B eller C så behöver man ställa rätt krav på dem utifrån sin egen verksamhet och sin egen samhällspåverkan. Se mer nedan. Organisation "B" B är väldigt lik A med skillnaden att B även drabbas av krav från A. De kraven utgår ingår i As arbete med att själv uppfylla NIS2-kraven. Här är det viktigt att inse det är inget som säger att kraven som A ställer på B ska vara samma som ställs på A från NIS2! De kan vara hårdare eller snällare. Man kan mycket väl tänka sig att B är extremt viktig för att A ska kunna producera och då kan det vara rimligt att ställa högre krav i sina kontrakt med dem än vad NIS2 kräver! Organisation "C" C har förvisso leveranser till samhället, men tillhör inte en sektor som omfattas av NIS2. Det innebär att eventuella säkerhetskrav i leveranserna direkt till samhället kan bli lite vad som helst, men man kan ju misstänka att kraven efter hand börjar likna dem som "drivs fram " av NIS2. C levererar också till NIS2-organisationen A enligt pilen 6. Även här måste A ställa rätt krav utifrån sin faktiska verksamhet, istället för att blint peka på NIS2. Organisation "D" D liknar mycket C. De kan dessutom beröras av att A, på grund av NIS2, ställer krav på att C i sin tur måste ställa relevanta krav på sina egna leverantörer. Beroende på hur duktig C är på riskanalys och kravställning kan det bli mer eller mindre bra för alla inblandade... Ja, som synes blir det snabbt komplicerat och det kan vara mycket att hålla rätt på. Några grundläggande tips kan man sammanfatta till: Oavsett om du eller din leverantör omfattas av NIS2 så bör ni alltid ta fram era egna krav utifrån era egna risker. En viktig del är sedan att säkerställa att de kraven dessutom hjälper er uppfylla alla krav ni själva får på er utifrån. Omfattas ni av NIS2 så handlar kraven därifrån främst om att förstå risker som uppstår runt er produktionsförmåga och att ni ska fokusera på att hantera de viktigaste riskerna. Har ni fysisk produktion så lär OT-säkerhet hamna väldigt högt upp på prio-listan! Ta gärna hjälp av kommersiella verktyg för att följa upp hur era leverantörer uppfyller säkerhetskraven, men glöm inte att nivån på kraven måste komma från er . Det är stor skillnad på kravet "Ni ska ha ett snöre!" och "Ni ska ha ett snöre som är 60cm långt!" Om ni omfattas av NIS2 så kan det vara klokt att se er själva som en del av "Samhälls-rutan". Är man viktig för samhället så är man på ett tydligare sätt en del av samhället och inte något som står lite vid sidan av! Något som inte tas upp här är det omvända behoven, alltså ert beroende av samhället. Det är viktigt att ha med i sina riskanalyser - vad händer om andra funktioner i samhället börjar knaka i fogarna? Här kan det skapas nya gröna pilar till era leverantörer! Koll på väderstrecken? En kort artikel från DarkReading illustrerar det viktiga med att inte bara övervaka trafiken in och ut från våra känsliga nätverk, utan även det som rör sig inom nätet, ofta kallat "Öst-Västlig trafik". Det är något som dessutom ofta är utmanande att få till på ett bra sätt i typiska OT-nät. De är ofta utspridda fysiskt och tekniken sätter begränsningar kring vilken trafik som går att få insyn i utan stora extrakostnader. Det är därför det är så viktigt att bygga sin infrastruktur med försvar i åtanke redan från start. Det som SANS kallar "defensible architecture" i sin "SANS Five ICS Cybersecurity Critical Controls" . På samma sätt är det sällan möjligt att komma åt all trafik men om man vet vilka blinda fläckar man har så går det mycket bättre att hantera det i praktiken. Vill du inte åka till Orlando? I mitten av juni går årets SANS ICS Security Summit av stapeln i Orlando. Om du vill slippa Musse Pigg så kan man ta del av många delar av programmet på distans. Mycket nöje! Det kan ju förstås vara en slump... För ett par år sedan fick jag ett konsultuppdrag som gick ut på att titta på hur produktleverantörer i den svenska OT-världen hanterade annonseringen av sårbarheter i deras produkter och hur rättningar lyftes upp offentligt. Jag slogs då av att vissa väldigt välkända svenska produktleverantörer i aldrig någonsin hade haft några sårbarheter i sina produkter! De hade fina webbsidor där man skröt om processerna för hanteringen, men där sårbarheterna skulle listas var det tomt... Nu noterade jag i förra veckan att samma leverantörer plötsligt börjat "drabbas" av en massa sårbarheter under det senaste året! Märkligt... Kan det vara så att de tagit de kommande kraven i CRA på allvar redan nu och faktiskt inte mörkar sina sårbarheter längre? Oavsett vad som ligger bakom så är det en positiv utveckling! Bra där! Vill du också göra rätt? Kanske vill du också hantera sårbarheter rätt? Vill du också ha koll på allt annat som CRA-förordningen kräver av dig som är leverantör av digitala produkter? Då är den gratisutbildning i CRA som The Linux Foundation och OpenSSF (Open Source Security Foundation) tagit fram ett förnämligt första steg! En bra introduktion på ungefär en timme och en med liten certifiering på slutet om man vill! Spöken i husets automation? Fastighetsautomation är en spännande del av OT-världen, men vad händer om man blandar in polisens forensiska utredningar i mixen? I en artikel publicerad i " Forensic Science International: Digital Investigation " har Johnny Bengtsson från Polismyndighetens Nationellt Forensiskt Centrum tillsammans med Linköpings Universitet tittat närmare på den frågan. Rubriken är " The ghost in the building: Non-invasive spoofing and covert attacks on automated buildings ". NIS2 i Finland! Den 8:e april implementerades NIS2 i Finland vilket är lite extra intressant även för oss i Sverige. Alla texter, inklusive lagen, är ju tillgänglig på svenska. Jag måste säga att jag gillar deras sätt att annonsera lagstiftningen och även sättet de skriver lagtexter. Det ska bli intressant att titta närmare på och så småningom jämföra med det svenska lagförslaget. Vi får se hur det går... Om du sysslar med cybersäkerhet i någon form så har du knappast missat allt ståhej på senare tid kring den USA-finansierade CVE-databasen vars framtid är oklar. Oavsett hur det går med detta och egentligen också oavsett vad man tycker om sårbarhetshantering i den här formen, och kanske i synnerhet CVSS-poäng, så blir det intressant att se hur detta landar. EUs eget initiativ framstår som mycket rimligare idag än vad jag personligen kanske tyckte för något år sedan. Otmar Lendl på Österrikes nationella CERT, cert.at , skrev en tankeväckande artikel där han jämför utmaningarna med CVE med DNS-systemet som vi alla använder dagligen för att hitta IP-adresser. Artikeln är på tyska men det fixar din browser! En smygtitt i brevlådan... Fedex kom förbi med en låda roliga grejor till låns från Profitap . Att kunna lyssna på nätverkstrafik är populärt i OT-världen. Det är ett vanligt grepp för att kunna leta efter angrepp eller andra händelser som man vill ha koll på. En par vanliga myter är att passivt lyssnande på trafik inte kan ställa till några driftproblem och att nätverksswitchar lätt kan hantera mirror/SPAN-portar utan problem. Så enkel är ju tyvärr inte verkligheten och ett sätt att minska vissa av dessa risker är att använda specialiserad hårdvara för att "kopiera" nätverkstrafik, vanligen kallade "Tappar". De är dessutom helt ovärderliga för lite mer avancerad felsökning i nät som drabbas av "magiska" fel! Att Profitap är proffs just på tappar framgår ju faktiskt av namnet... Från vänster till höger på bilden är det en C1D-1G , en Profishark 1G och en C8P-X2 . Jag återkommer med en närmare titt på dessa när jag hunnit utsätta dem för en del intressanta utmaningar... Fler videos från S4 - missa inte! Glöm inte att S4-konferensen fortsätter att lägga ut inspelningar från årets tillställning i spellistan "S4x25 Tampa" på YouTube . En rad intressanta presentationer finns att gotta sig åt, exempelvis när Andrew Ohrt berättar om CIE, Cyber Informed Engineering och kommer in på fantastiska begrepp i stil med "Cyber-enabled failure mode": MITRE EMB3D i ny version! MITRE har släppt version 2.0 av hot-ramverket MITRE EMB3D . Oerhört användbart om du pysslar med modellering av hot mot alla former av inbyggda system. Vad kan vi vänta oss för vägledning kring CRA? Sarah Fluchs delar med sig av sina insikter kring vad vi kan vänta oss när det kommer till ytterligare vägledning kring CRA. Vi är många som är angelägna att veta mer om vad som gäller i praktiken. Sarah ställer helt rätt frågor och nu väntar vi på att Kommissionen levererar svaren. Waterfalls årsrapport är här! Jag är inte så förtjust i alla årsrapporter från snart sagt varenda produktleverantör i säkerhetsbranschen. Det tenderar att blir en jakt på motivation att köpa just deras produkter... Jag ska inte säga att Waterfall helt låter bli det men deras rapporter tenderar att vara mer balanserade än de flesta. Jag låter dig läsa deras slutsatser direkt i deras senaste årsrapport 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 .

  • Nyhetsbrev OT-Säkerhet #68

    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 .

  • Nyhetsbrev OT-Säkerhet #67

    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 .

  • Nyhetsbrev OT-Säkerhet #70

    Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången inser vi att OT-säkerhet är ett riktigt svårt problem, vi testar en haj i labbet, vi förbjuder lösenordsbyten, läser statistik över vilka OT-protokoll som är populärast, lyssnar på en ny podd om fastighetsautomation, svarar på en fråga om FMEA-analys, räknar OT-honeypots på Internet, filosoferar över proportionalitet i NIS2, funderar över hur lång tid ett havererat system tar att få igång och så tittar vi på den nya nationella sårbarhetsbedömningen. 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! Regelbundna lösenordsbyten? Det har ingenting specifikt med OT-säkerhet att göra, men jag tyckte det var intressant att NIST nu äntligen kommer "förbjuda" att man tvingar fram regelbundna byten av lösenord och krav på att blanda olika typer av tecken. (Rad 5 och 6 nedan) Texten kommer från ett utkast till den nya versionen av NIST SP 800-63B så det är inte en officiell version riktigt ännu. De har sedan knappt 10 år tillbaka avrått från detta, men nu är det alltså uppgraderat till ett "SKA INTE" istället för ett "BÖR INTE"! Håll tummarna! Vi har ett resultat! Svenska HMS Networks har publicerat årets analys av hur användningen av olika "OT-protokoll" ser ut . På det hela är det inga stora överraskningar - användningen av av PROFINET, EtherNet/IP och EtherCAT ökar. Det är precis som tidigare en hel del skillnader mellan olika världsdelar. Generellt verkar intresset för de spännande teknikerna APL (Advanced Physical Layer) och SPE (Single Pair Ethernet) vara stort framöver. Jag fick en bra fråga... Efter en presentation jag körde nyligen kring hur det går för Sverige i arbetet med NIS2 fick jag en fråga om det inte vore en bra idé att använda FMEA-analys (Failure Mode and Effects Analysis) när man gör riskanalyser i sitt NIS2-arbete. Mitt svar gick ut på tre saker och gäller egentligen oavsett om NIS2 är aktuellt eller inte: Det känns som en bra idé i största allmänhet. Jag har inte använt metoden i just det sammanhanget, men spontant känns det vettigt. Jag har en farhåga att metoden kan tendera att lura bort uppmärksamheten från det som verkligen måste styra NIS2-arbetet, nämligen hur verksamheten påverkas av en incident. Man ska förstås förstå hur incidenten uppstår i systemen men man måste komma ihåg att värdera konsekvenserna på riktigt. En riktigt bra effekt av att använda metoden är att man kan väva in organisationens förmåga att upptäcka incidenter när man bedömer sina risker. Den tredje poängen är extra viktig! Det handlar om att man utökar det gamla vanliga tänket med sannolikhet och konsekvens med en tredje parameter: "upptäckbarhet". Incidenter som vi har dåliga möjligheter att upptäcka är rimligen otäckare jämfört med andra incidenter som vi har förmåga att upptäcka och hantera tidigt, innan konsekvenserna blir allvarliga! Det knyter an till en poäng som jag skrivit om flera gånger förut, nämligen att man lätt lägger för mycket av sina resurser på att förhindra att incidenter kan inträffa. Jag vet att det kan låta lite bakvänt, men min poäng är att erfarenheten visar att allt för många blir helt överrumplade när incidenten trots allt inträffar! De har inte tillräcklig förmåga till detektion, de har inte rutiner för att hantera situationen snabbt, de har inte övat på rutinerna och de samlar inte in tillräckligt med information för att kunna analysera vad som egentligen inträffade. ...och vad som inte hände! Det där, att veta vad som faktiskt hänt och inte hänt, i systemen är otroligt viktigt av två skäl. Dels för att kunna ägna sig åt rätt saker när man hanterar incidenten och kunna vara säker på att man är helt färdig med uppstädningen. Men om man exempelvis omfattas av NIS2 så förväntas man dessutom i efterhand kunna förklara för sin tillsynsmyndighet vad som inträffade, vad som inte hände, varför det gick som det gick och vad som kommer förhindra att det återkommer igen. Oavsett om man behöver skicka en rapport till en myndighet eller inte, så är det förstås extremt viktigt att man lär sig av incidenter och då vill det ju också till att verkligen veta vad som hände i systemen! Det finns förstås inget som hindrar att man väger in "upptäckbarhet" i sina riskanalyser oavsett vilken metod man använder. Jag skulle nog rekommendera det för de flesta. För att kunna dra nytta av att NIS2 säger åt oss att använda proportionerliga åtgärder behöver vi verkligen förstå var åtgärderna gör störst nytta! Om du vill läsa mer om FMEA har jag förresten skrivit om det tidigare i Nyhetsbrev #48 men då i ett annat sammanhang. Behovet av att kunna vara efterklok skrev jag om i Nyhetsbrev #67 . Det finns en variant av FMEA som kallas FMECA där man även väger in hur kritisk en viss komponent är, jag har inte själv använt den varianten men det låter som den skulle kunna adressera en del av problemet att man riskerar att missa verksamhetspåverkan? Om du som läser har erfarenhet av detta vill jag gärna lära mer: mats@ot-sakerhet.se. (Sorry att jag gick lite bananas med AI-bilderna i den här texten...) OT-säkerhet är ett riktigt svårt problem! Amerikanska "National Academies" har släppt ett helt fascinerande dokument: " Cyber Hard Problems ". Syftet med dokumentet är att definiera de absolut viktigaste och svåraste problemen att lösa kring cybersäkerhet. Tanken är att det ska skapa ett fokus på att faktiskt lösa dem! Det är ett rejält dokument på 137 sidor som känns riktigt väl genomarbetat! En sammanställning  på 3 sidor finns också tillgänglig. Det är tydligen en stolt tradition sedan många år tillbaka att ta fram dessa dokument "emellanåt", det finns två tidigare versioner, en från 1995 och en från 2005! I ett av kapitlen tittar man på hur det har gått, och glädjande nog finns det tydliga framsteg på flera av dåtidens topplista! Jaha? Vad har det med OT-säkerhet att göra då kan man undra? Jo, det är faktiskt så att OT-säkerhet är en av de 10 problemen: nr 8! Dessutom är flera av de andra problemen extremt relevanta problem för oss i OT-branschen, personligen tänker jag framför allt på nr 4: Supply chain, och nr 10: Operational Security. Risk assessment and trust Secure development. Secure composition Supply chain Policy establishing appropriate economic incentives Human–system interactions Information provenance, social media, and disinformation Cyber-physical systems and operational technology AI as an emerging capability Operational Security De problem som målas upp kring OT-säkerhet är ingenting nytt för någon i branschen men det ska bli väldigt spännande att se om det ändå kan påverka hur branschen utvecklas på något litet sätt? Slutsatserna om vad som är viktigt framåt känns främst som: Multidisciplinär ansats där vi fåt ihop teknik, människa och policy på ett vettigt sätt. Fokus på resiliens snarare än endast skydd. Att sårbarheter i dagens OT-system måste hanteras strukturellt, inte bara reaktivt. En proffsig haj är på besök i labbet! Som jag förvarnade om i förra nyhetsbrevet har mitt OT-säkerhetslabb fått besök av en spännande trio från Profitap . Först ut att bli synad lite närmare är en ProfiShark 1G som jag hade stora förväntningar på redan i förväg och som det snabbt visade sig vara en riktigt trevlig bekantskap... Den presenteras som en "Portable traffic capture and troubleshooting tool", vilket säger ganska mycket om nyttan den ger. Men samtidigt måste jag säga att dess blygsamma yttre döljer en del riktigt imponerande muskler! Den variant jag har fått i händerna, "1G", är en mellanmodell bland fem olika. Syftet med alla modellerna är att göra det enkelt att samla in en kopia på nätverkstrafik. Det kan vara för att felsöka märkligt beteende i anläggningens nätverk, eller om vi pratar säkerhet, att samla in trafik för senare analys. Nätverkstrafiken kan man antingen få genom att ProfiShark ansluts till en (eller två) SPAN-portar på exempelvis en nätverksswitch. Alternativt kan den användas som en nätverks-tap, alltså att den kopplas in så att trafiken passerar igenom enheten. Det senare är det mer rättvisande alternativet eftersom man ser det som verkligen rör sig på nätverket och inte begränsas till det som switchen väljer att kopiera ut. Exempelvis kan man få tillgång till korrupta paket och full insikt i länkförhandlingar! En baksida som alla tapar har är att man måste bryta kommunikationen för att koppla in den och att den kan störa kommunikationen om tapen inte fungerar som den ska. Några av de fem varianterna har därför inbyggda funktioner som "kortsluter" kommunikationen om de exempelvis förlorar strömmen. Något som blir allt vanligare är att industriella komponenter strömförsörjs via nätverksanslutningen via PoE - Power Over Ethernet. Profishark 1G hanterar det här på rätt sätt så att man kan koppla in sig utan att behöva ordna med separat strömmatning. De två modellerna som har ett "+" i namnet har dessutom ingångar för GPS och PPS, alltså extremt exakt tid. Det används för att ge de infångade nätverkspaketen extra exakt tidsstämplig, vilket kan vara väldigt viktigt i exempelvis nätverk som använder TSN-teknik. Alla modellerna klarar tidsstämpling med en upplösning på 8 nanosekunder! Två modeller har stöd för 10 Gb/s via SFP-moduler, vilket även medger insamling från fiberanslutningar. En klurighet om man lyssnar på full-duplex trafik är att resultatet kan bli dubbla bandbredden. Det vill säga att om man lyssnar på en vanlig länk med 1 Gb/s så kan resultatet bli 2 Gb/s. Det blir klurigt om systemet som ska ta emot trafiken bara klarar 1 Gb/s! Det finns olika varianter på lösningar av detta. En är att ha två utgångar med 1Gb/s var. Inte speciellt smidigt! En annan är så kallade aggregerande tapar, vilket innebär att trafiken slås ihop till en gemensam dataström. Men det kräver ju då mer bandbredd... En viktig sak som skiljer dessa tapar från de flesta andra tapar jag kommit i kontakt med är att man ansluter till dem via USB! Det innebär förvisso att man behöver en speciell drivrutin, men i gengäld får man en massa fördelar. Den största fördelen är att du klarar att hantera full-duplex, dvs 2 Gb/s, på ett vettigt sätt. Profitap har även byggt in möjligheten att låta ProfiShark spela in direkt till en NAS via USB om det är så att man ska spara enorma mängder data, eller över lång tid för att hitta problem som uppstår mycket sällan. För att komma igång installerar man en drivrutin och det finns stöd för Windows, macOS, en rad varianter av Linux, Synology NAS och VMware ESXi. I mitt fall provade jag på Windows där enheten dyker upp som ett vanligt nätverksinterface och därmed är åtkomligt direkt i alla analysverktyg, exempelvis WireShark. Tillsammans med drivrutinen finns även "ProfiShark Manager", en mjukvara där man kan diagnostisera portproblem, följa trafiken, starta inspelningar mm för en eller flera ProfiShark-enheter. Om man använder någon av modellerna med stöd för 10 Gb/s så finns även möjligheten att filtrera i trafiken så att bara de delar som man är intresserad av skickas vidare. Gör man inspelningar direkt i mjukvaran så kan man be den dela upp inspelningen i flera filer baserat på tid eller storlek. Det här är smidigt för att hantera stora mängder data. Om du använder CloudShark som samarbetsplattform så kan dina inspelningar laddas upp automatiskt - smidigt! När man ska analysera en driftstörning eller en potentiell säkerhetspåverkan är möjligheten att snabbt kunna ta en kopia på nätverkstrafik ofta jätteviktig. Det sista man behöver i det läget är teknikstrul eller att en super-certifierad nätverkstekniker måste vara tillgänglig. ProfiShark är så enkel att använda att jag nästan undrade vad jag missförstått. Jag försöker generellt vara försiktig med rekommendationer, men ProfiShark passar verkligen utmärkt i händerna på en automationsingenjör eller en OT-säkerhetsperson. Den är smidig att använda, stör inte kommunikationen och kräver ingen extra strömförsörjning. Man behöver inte vara specialist på nätverk för att få till det. Resultatet blir de inspelningar man faktiskt behöver och det mesta sköter sig självt helt automatiskt. Oavsett om du har 10, 100 eller 1000 Mb/s i nätet så funkar den rätt av! Den har alla förutsättningar att bli årets julklapp i din verksamhet! Om du vill se alternativ på marknaden och få en jämförelse med andra portabla tapar så gjorde Sake Blok en spännande presentation på Sharkfest 24 där han jämförde ett antal olika märken. Om du är medlem kan du se presentationen på YouTube : (Annars finns hans slides att titta på gratis.) Till nästa nyhetsbrev hoppas jag återkomma till en av de andra godbitarna som jag lånat av Profitap: en C1D-1G eller en C8P-X2 . Vi får se vilken det blir, eller kanske båda två? Vem lurar vem egentligen? Jag har alltid tyckt att att det känns lite överdrivet med alla larmrapporter som regelbundet dyker upp och säger att det sitter mängder av OT-prylar direkt på Internet. Att problemet existerar säger jag ingenting om, men att det skulle vara jätte-vanligt känns lite överdrivet... Kan det vara så att det finns väldigt många fejkade system för att mäta hur mycket angrepp OT utsätts för på Internet? Jag ser framför mig forskare som letar efter "angripare" och andra forskare som letar efter "exponerade system" - men de båda upptäcker mest varandra... Nu har en grupp forskare, Martin Mladenov, László Erdődi och Georgios Smaragdakis, tittat närmare på hur stor del av alla "OT-system" på Internet som egentligen är klassiska honeypots. Deras slutsats i " All that Glitters is not Gold: Uncovering Exposed Industrial Control Systems and Honeypots in the Wild " är att det är uppemot 25%! Dessutom verkar andelen öka ganska snabbt! Då återstår ju frågan om hur stor del av de övriga 75%:en som inte är "riktiga" system? Jag tänker mig prylar som inte är "honeypots" utan istället är "riktiga" komponenter men som inte ingår i "riktiga system"? Duktiga angripare kommer relativt snabbt upptäcka att de kommit i en honeypot - men det tar längre tid om man hamnat i ett "riktigt" system, med "riktiga" komponenter, som fungerar "på riktigt" - men som inte styr någonting viktigt? Hur vanligt är det? Men ta nu inte detta som att problemet med direkt-exponerade OT-system egentligen inte är ett problem! Det är ett problem, men det är inte så stort som det ibland presenteras som! Proportioner i samhället? Det är mycket snack om NIS2 nu! Även om vi inte fått någon svensk lagstiftning ännu så finns ju väldigt tydliga förväntningar att läsa direkt i direktivet från EU . En sådan är att man förväntas hantera risker på ett proportionerligt sätt. När man tänker efter så är det ju ett väldigt enkelt, tydligt och vettigt krav, att man ska lägga mer resurser på allvarliga risker och mindre på alla andra risker. Men... Det finns en liten detalj i direktivet som jag tycker ofta tappas bort när man pratar om just proportionalitet. Detaljen handlar om vilken risk man ska utgå från när man väljer sina åtgärder. Det är lätt att tänka att det är de risker som slår hårdast mot den egna verksamheten, men då missar man att man också förväntas bedöma hur man påverkar samhället! (Se de sista orden i slutet av utdraget.) Det här är det lätt att säga smarta saker om, men ganska svårt att genomföra i praktiken. I grunden handlar det om att inte bara stirra sig blind på säkerheten i sina egna leveranskedjor, utan även förstå sin egen roll i kundernas leveranskedjor. Och deras kunders... Och deras kunders... Det betyder också att vad som är en rimlig mängd resurser att lägga på riskåtgärder kan bli mycket högre om man inte bara ska "tänka på sig själv". Det kanske dessutom är lite extra svårt att se samhälls-perspektivet när man fokuserar på OT-säkerhet i en fysisk produktion? Risken att roboten i vår automation "petar bort" den där avgörande komponenten som en massa oväntade saker i samhället balanserar på... Det kan tänkas att jag är lite indoktrinerad kring det här med proportionalitet. Det där är nämligen ett extremt centralt begrepp i kärnkraftsbranschen, där ju jag har min "uppväxt". Där använder man istället begreppet "graded approach" som på hög nivå handlar om exakt samma sak. Nämligen att det är direkt dåligt att försöka skydda allt på samma nivå; det blir onödigt dyrt, saker som egentligen inte behöver så mycket skydd blir onödigt "krångliga" och det blir i slutändan för lite resurser kvar till det som verkligen behöver mycket skydd... Här har tyvärr en del kollegor i säkerhetsbranschen gått vilse och driver linjen "mer säkerhet är alltid bättre". Det är förvisso fullt förståeligt om de kanske har fått slåss för "sin sak" hela livet. Min erfarenhet är att det är enklare att få både gehör och resurser om man är mer nyanserad och vågar prioritera ner vissa saker lika ofta som andra prioriteras upp. Det ska bli spännande att se hur föreskrifterna från tillsynsmyndigheterna hjälper verksamheterna att se sin roll i samhället! Här ska vi också komma ihåg en annan bortglömd rad i direktivet, den om att man inte alls måste uppfylla kravet på 50 anställda mm för att omfattas av NIS2-kraven. Tycker en myndighet att alldeles för mycket i samhället balanserar på er lilla verksamhet så kommer ni att "manuellt" stoppas in som NIS2-verksamhet oavsett er storlek! 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 ! Sarah ger kloka råd om CRA! Sarah Fluchs är en ständig källa till kloka texter. Nu har vi fått en summering av läget kring CRA från henne som ger en radda riktigt bra och handfasta råd för den som känner sig vilsen. Det bästa med råden är att Sarah utgår ifrån det faktum att det faktiskt inte går att undvika att vara förvirrad just nu, det är alldeles för mycket som är oklart fortfarande. Men med en klok inställning och vettigt fokus i arbetet så kan man ändå göra meningsfulla insatser i riktning mot målet att uppfylla kraven. Hon följde upp detta med ett inlägg kring en oro runt att CRA är risk-drivet och att det på något sätt skulle kunna underminera den ideala säkerheten. Sarah reder förstås ut de missförstånden like elegant som vanligt! Lycka till med CRA-arbetet! Podd-dags igen - "Energi & Magi" För ett tag sedan var jag och hälsade på hos PiiGAB i Göteborg för att spela in ett poddavsnitt i deras podd-serie "Energi & Magi". Om du pysslar med energi-effektivisering eller automation av fastigheter så har du förmodligen stött på deras produkter i något sammanhang. Det blev ett kul samtal om OT-säkerhet , NIS2, mätvärden och fastigheter med Gunnar Oesterreich, Kaj Winther och Karl Lindell. Väl värt att lyssna på även om du är i en annan bransch! ( Spotify , Poddtoppen , Apple ) Att komma igång igen... Dale Peterson publicerade nyligen två kloka texter, en handlar om RTO , Recovery Time Objective, och vad som gör det begreppet speciellt i OT-världen. Den andra texten fortsätter på den första och tittar på hur man faktiskt kan uppnå det RTO-mål man har satt upp. Dales texter är riktigt bra och förtjänar verkligen att man tänker igenom budskapet ordentligt. Att det är bra texter märktes också genom att det väckte tre helt olika associationer i min stackars hjärna: De påminde mig om en text jag skrev i Nyhetsbrev #55 om RPO, Recovery Point Objective, ett närbesläktat begrepp som också är viktigt att ha koll på. Den andra associationen var till ett samtal jag hade nyligen där jag just jämförde förmågan att återställa havererade system tillräckligt snabbt (och tillräckligt bra) med förmågan att kunna avsluta en incident när man blivit hackad. Det är en sak att ha övervakning så att man kan reagera snabbt vid angrepp. Men det är en annan sak att löpande samla på sig tillräckligt mycket av rätt information om vad som händer i nätverket och system för att kunna avgöra vad som faktiskt hänt och om man verkligen tagit hand om det. Efter det kommer dessutom en analys för att förstå vilka brister som bidrog till incidenten - och då behöver man ännu mer sparad information. Ska man skicka in en NIS2-rapport till sin tillsynsmyndighet kan det krävas ännu mer... Den tredje associationen var lite mer långsökt och knöt också an till en diskussion nyligen. Inom elförsörjningen talar man om "dödnätsstart", alltså att kunna få igång ett stort elnät (tänk en hel stad eller en hel region) med tillhörande kraftverk när elnätet helt saknar ström. Det är utmanande och kräver speciella förberedelser. På samma sätt måste återställningplanering för OT (och för IT) i många fall fundera på hur man får igång viktiga system och processer när kringliggande system eller nätverk är "döda". Ofta finns betydligt fler beroenden än man tror, inklusive diverse fysiska behov som el, kyla, tryckluft, tillträde genom låsta dörrar osv... Det här är viktiga analyser att ta sig tid med. De brukar dessutom föra med sig en massa insikter om vilka system som faktiskt är viktiga för produktionen... Fler videos från S4 Det fortsätter att ramla in videos från årets S4-konferens med många godbitar! Här är några exempel, men det finns fler i den kompletta spellistan . Andy Bochman drar intressanta jämförelser mellan "naturliga" katastrofer i vår omvärld och katastrofer vi kan drabbas av via våra OT-system. Vad lär det oss om hur vi förbättrar vår tålighet och robusthet? Dale intervjuar Tom Burke som grundade och ledde OPC Foundation i tre decennier. De skapade exempelvis OPC DA och OPC UA. Eric Forner slår ett slag för att IT-säkerhet och OT-säkerhet är mer lika än vi tror och att säkerhetslösningar i molnet är alldeles utmärkt för majoriteten av OT-system. Snacka om att svära i kyrkan enligt många men hans poänger håller alldeles utmärkt för många verksamheter. Favoriter från Sinclair Om du läst mina tidigare nyhetsbrev vet du att Sinclair Koelemij är en av mina största hjältar. Den här gången plockar jag ett citat från ett inlägg på LinkedIn : Det här är viktiga insikter på flera nivåer. En av dem är att vi både måste ägna oss åt att bygga så säkra system som möjligt (exempelvis genom att luta oss mot compliance-krav) och samtidigt arbeta med att förstå och utveckla tåligheten och robustheten i våra fysiska produktionsprocesser så att de står pall även när vi har en riktigt dålig dag. Gamla nyheter från Kanada! Ett nyhetsbrev ska rimligen mest innehålla nyheter... Men ibland kommer jag tillbaka till gamla godingar, bara för att de är riktigt bra! En sådan är en vägledning från myndigheterna i Kanada kring hur man bygger upp sin förmåga kring incidenthantering inom OT. Den gavs ut 2020 men känns fortfarande bland det bästa jag läst på området - tydligt, enkelt och med äkta fokus på OT. Anledningen till att jag lyften denna, förutom att den helt enkelt är bra, är att det behövs mycket mer fokus på incidenthanteringsförmåga i nästan alla verksamheter som jag stöter på. Nu i NIS2-tider så blir det ännu tydligare att allt för många enbart fokuserar på att förbygga tråkiga saker och lägger alldeles för lite intresse vid att upptäcka och hantera incidenter. Det är riktigt jobbigt att ta till sig tanken att man nästan oundvikligen kommer drabbas av incidenter - trots allt jobb med att förebygga dem. Men när man kommit dit så blir arbetet desto enklare att fokusera på rätt saker. Det jag alltid tjatar om i det här sammanhanget är att börja öva tidigt och i liten skala! Det finns inget bättre sätt att hitta sina viktigaste svaga punkter så att man snabbt jag höja nivån än att göra enkla små-övningar! Dale bedömer hur det gick... Den alltid insiktsfulle Dale Peterson tittar i en artikel hur det gått för de uppköpta OT-säkerhetsbolagen sedan 2018: Forescout köpte SecurityMatters 2018 Tenable köpte Indegy 2019 Cisco köpte Sentryo 2019 Microsoft köpte CyberX 2020 Honeywell köpte SCADAfence 2023 Rockwell Automation köpte Verve 2023 Hans dom är hård och jag håller med om den till 100%. Det är egentligen bara Microsoft som lyckades med det som var avsikten med deras köp. Även om alla existerande kunder till CyberX genast hoppade av så fick Microsoft grundstommen till Defender for IoT. I alla andra fall, inklusive kopplingen till Ciscos köp av Splunk för ett par år sedan, har resultatet verkligen inte varit imponerande. Dale har inte med Armis köp av Otorio som genomfördes alldeles nyligen, där har jag personligen lite mer hopp - men det återstår att se hur det går... Först ett stabilt nätverk - sedan säkerhetsarbete! Jag läste nyligen en bra artikel från svenska firman Lindh Automation om viktiga mätpunkter för att hålla koll på att ett PROFINET-nätverk mår bra. En intressant artikel i sig, men den påminde mig också om hur viktigt det är att man har ett välmående nätverk (oavsett om man kör PROFINET eller något annat) innan man börjar lägga till säkerhetslösningar. Jag träffar lite för ofta verksamheter som råkat illa ut i samband med att de fått dåliga råd i samband med en PoC-test av någon ny säkerhetsprodukt. En klassiker är att man skulle prova en IDS-lösning och fick höra det klassiska; "Nej, den är helt passiv så den kan inte störa produktionen!". Men efter hand uppstår det en massa konstiga störningar som är väldigt svåra att felsöka. Senare visar det sig att nätverksswitchen som man fick en mirror-port i hade så hög last att den inte pallade med att kopiera all trafik till den speglade porten och istället började tappa paket. En annan variant är att mirrorporten visar sig inte vara begränsad till att enbart skicka trafik åt ett håll utan "ny trafik läcker in" på produktionsnätet från säkerhetsservern... Din SBOM är trasig! I ett intressant papper från University of California, Riverside har Sheng Yu, Wei Song, Xunchao Hu and Heng Yin studerat ett antal program för att generera SBOM:ar och framför allt, hur "rätt" de har i sina analyser. I korthet konstaterar de att det fortfarande finns stora brister i hur väl dessa system fungerar. Å andra sidan kan man med viss rätt hävda att en SBOM bara kan vara rätt och fullt meningsfull om den producerats i samband med att den mjukvara som beskrivs togs fram. Fler certifieringar att ta! CompTIA har annonserat att de kommer med en OT-certifiering. Det ska bli roligt att se hur de tagit sig an detta när fler detaljer blir tillgängliga. En ny nationell risk- och sårbarhetsbedömning! MSB har genomfört en analys av nationella risker och sårbarheter som publiceras i ett rejält dokument på dryga 180 sidor . Som sig bör dyker OT-säkerhet upp i ett antal viktiga sammanhang, både specifikt men också (som är det nya sättet att tala om detta) under paraplybegreppet "Cybersäkerhet" som i det här sammanhanget inkluderar Informationssäkerhet, IT-säkerhet och OT-säkerhet i ett och samma ord. Det här är ett gediget dokument som verkar väl genomarbetat. Vi kommer säkert se en hel del referenser till det, både i kommande myndighetskommunikation men, som slagträ i diskussioner kring prioritering av resurser och från produktleverantörer som motivation till att köpa fler fantastiska säkerhetsprylar! Andrew är i molnet! Den alltid kloke Andrew Ginter reflekterar över "Molnet" och dess allt viktigare roll i OT-verksamheter och spekulerar kring vad som skulle kunna vara bra lösningar för att inte tumma på "Safety" i dessa sammanhang. Stressad av NIS2? Vänta du bara... Ett läsvärt dokument publicerades nyligen av EUs cybersäkerhetsmyndighet ENISA, en handbok i hur myndigheter ska stressa verksamheter - exempelvis kopplat till NIS2. Nä, det är inte så bisarrt som det låter. Det handlar om att genomföra en slags myndighetsorganiserade övningar baserat på utmanande scenarier. Scopet kan vara en eller flera sektorer och för ett/flera/alla länder i EU samtidigt. Tanken är att övningarna ska vara "table top", alltså helt utan tekniska eller praktiska inslag. Man tänker sig specifikt att detta kan vara ett verktyg för tillsynsmyndigheterna under NIS2 för att bedöma starka och svaga sidor i organisationernas tålighet mot allvarliga störningar. MITRE genomförde nyligen något liknande i USA med 200 personer från 70 organisationer. Själva övningen och de exakta resultaten är hemligstämplade, men det finns ett par dokument som i korthet tittar på övningen. Ett med den dramatiska titeln " 5 STEPS TO PREPARE CRITICAL INFRASTRUCTURE FOR A CYBER WAR " och det andra " Past is Prologue: Creating a Civil Defense Mindset to Address Modern Cyber Threats ". Virtuella PLC:er någon? Branschens intresse kring virtualisering av PLC:er har verkligen hettat till. Senaste tillskottet är norska startupen OTee som börjar synas mer och mer . Det finns många spännande för- och nackdelar ur ett säkerhets- och riskperspektiv så vi kan se fram emot fler spännande diskussioner framöver. Personligen är jag definitivt positiv även om startsträckan i vissa branscher är extremt lång. På samma tema annonserade Siemens nyligen hur deras virtuella S7-1500V används i Safety-applikationer. Intressant.... Se upp med GPS:en! Det är inga nyheter att det förekommer en hel del medveten störning av GPS-tjänster runt om i världen, inklusive i vår närhet där södra Östersjön lustigt nog är extra utsatt. Nyligen annonserades det att fartyget MSC Antonia gick rejält på grund i Röda havet i början av maj på grund av manipulerad eller störd GPS-information. Fartyg innehåller mängder med OT-teknik men även för OT på land kan GPS-störningar ställa till det, inte minst om man använder GPS-källor för att ha synkroniserad tid - något som Ukraina haft stora problem med i sitt elnät. Värt att tänka på! Vem är Mats? Jag är till vardags konsult och säkerhetsrådgivare kring OT på Sectra Critical Infrastructure AB. 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 .

  • Nyhetsbrev OT-Säkerhet #66

    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 .

  • Nyhetsbrev OT-Säkerhet #63

    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 .

  • Nyhetsbrev OT-Säkerhet #64

    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 .

  • Nyhetsbrev OT-Säkerhet #65

    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 .

  • Nyhetsbrev OT-Säkerhet #62

    Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du två spännande produkter som varit i labbet, jag bevisar att jag är en nörd, lite gnäll över hur Purdue används, vi hittar förändringar i NIS2, jag läser en gammal bok med nya ögon och så vill tydligen Rockwell att vi kopplar bort deras grejor från Internet! Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Läs mer om det här i det här nyhetsbrevet! Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Det här nyhetsbrevet är ju något som jag fortfarande tycker är väldigt roligt att skapa, vilket förstås är viktigt eftersom det till största delen skrivs hemma i TV-soffan. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att anmäla dig på www.ot-säkerhet.se eller dra ett mejl till mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i dess egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Mastodon, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se. Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på artikeln och genom att dela den vidare. Tack för hjälpen! Statistik och röster från verkligheten... Jag blir sällan imponerad av alla de statistik-rapporter som alla de stora produkttillverkarna tar fram för att visa hur farlig världen är och hur viktigt det är att vi köper just deras produkter. Ibland kommer det undantag... Jag hittade faktiskt en del intressant i "2024 Threat Report - OT Cyberattacks with physical consequences" från Waterfall och i "Security Navigator 2024" från Orange. Jag ska inte ge mig på att tolka deras analyser här, men kan exempelvis tipsa om när Dale Peterson intervjuar Andrew Ginter från Waterfall: Det verkar förresten som att lyckade attacker som inleds via "elaka länkar" i mejl tydligen nästan helt har upphört? Jag hör från folk som sysslar med incidentstöd till organisationer som drabbats att så gott som 100% av ransomware-fallen de senaste månaderna inleds genom attacker mot vanliga VPN-tjänster. Det har ju onekligen varit en strid ström av allvarliga sårbarheter i just sådana senaste året. Det här är förstås ett superstarkt argument för att skaffa något annat än "en vanlig VPN". I OT-världen vill man ju ofta dessutom ha lite funktionalitet som inte finns i IT-världens lösningar. För ett bra exempel se min text om Cyolo i Nyhetsbrev #59. Och på sjön... Ett av mina specialintressen är OT-säkerhet inom sjöfarten. Jag har skrivit tidigare om de kommande regelverken som klassningssällskapen tar fram och som börjar gälla fullt ut i sommar. Nu börjar även certifierade produkter dyka upp, exempelvis gav DNV nyligen tumme upp till "Vessel Insight" från Kongsberg Digital baserat på DNV Cybersecurity Profile Level 1 (SP1) och IACS UR E27. Det här är en spännande utveckling inom ett väldigt roligt område av OT-säkerhet där säkerhetsarbetet har ytterligare lite fler utmaningar jämfört med "vanlig" OT-säkerhet på landbacken... NIS2 har ändrats! NIS2-direktivet finns, precis som de flesta viktiga EU-dokument, översatta till 24 olika språk. Det betyder förstås att det alltid dyker upp språkliga missar efterhand. För vårt kära NIS2-direktiv är vi just nu uppe i 4 uppdateringar som ändrar på små, och ibland större saker, i texten. Den svenska versionen fick en intressant ändring i uppdatering nummer 4 och berör outsourcade verksamheter. Notera att det alltså är olika ändringar på de olika språken även i samma uppdatering. Uppdatering 1 (Italienska och Nederländska) Uppdatering 2 (Nederländska) Uppdatering 3 (Slovenska) Uppdatering 4 (Tyska, Estniska, Engelska, Italienska, Ungerska och Svenska) Apropå uppdateringen kring outsourcing... Det här med att alla former av MSP- och MSSP-tjänster i sig omfattas av NIS2, är ett bra exempel på en av de branscher där det inte känns som polletten har trillat ner hos alla. Om du sysslar med drift eller säkerhetsövervakning av någon form av IT- och OT-prylar åt andra organisationer så omfattas du av NIS2. Det finns fler polletter som inte ramlat ner överallt, exempelvis att man inte löser utmaningar kring NIS2 med produkter. Inte heller att det kommer en checklista med saker du måste göra. Det hindrar inte att många påstår detta, vilket fick mig att nyligen skriva det här inlägget på LinkedIn: Det kommer bli intressant att se hur tillsynsmyndigheterna väljer att utforma sina föreskrifter. Personligen hoppas jag att man inte "förstör" chansen som direktivet och Cybersäkerhetslagen ger oss där man kan fokusera åtgärderna där de gör mest nytta för den egna organisationen men förstås då också tvingas tänka lite själv och att bygga upp kompetens kring risk- och säkerhetsarbete... En gammal goding... Jag får regelbundet frågor i stil med "Varför gillar du inte Purdue-modellen?" och mitt svar brukar lika regelbundet bli något i stil med "Jag har inget emot Purdue, men väldigt många har missförstått den." Jag har varit inne på detta många gånger förut i nyhetsbrevet. Den bästa förklaringen kring det här som jag hört är fortfarande från Ralph Langner: Jag rekommenderar verkligen att du ser videon, det tar under 10 minuter. Om du sedan inte håller med vill jag verkligen höra varför! mats@ot-sakerhet.se Några personliga kommentarer: Segmentering är inte bara en nätverksfråga. Se upp med hur applikationer sträcker sig över segmenteringsgränser. Ett vanligt exempel är Active Directory som lätt blir en kortslutning mellan separata zoner som delar samma AD-tjänster. "Utvecklade" versioner av Purdue-modellen har en DMZ-nivå mellan IT och OT. Det är absolut en bra idé att undvika direkt kommunikation mellan dessa världar. Men, på samma sätt som att "Nivå 2" inte ska uppfattas som ett stort nätverk är inte DMZ-nivån heller ett enda nätverk! System i ett DMZ är extra utsatta och ska definitivt inte kunna prata med varandra i onödan! Min rekommendation är att använda något slags variant på "Zones & Conduits" enligt IEC 62443. Man måste inte nödvändigtvis använda den komplexa metoden för riskanalys som beskrivs i del -3-3 av standarden! Notera förresten också att Purdue-modellen inte existerar i 62443-standarden, mer än som ett exempel på möjliga arkitekturer. Något som sällan diskuteras i det här sammanhanget är nätverk och system som "måste" ha kontakt med många andra komponenter. Varifrån administreras dina switchar? Hur tas backuper? Administration av hostar och lagring för virtualisering? Kan säkerhetssystemen bli en risk i sig själva? Sist men inte minst... Den ultimata kortslutningen i många segmenterade nätverk, remote access! Här vill det verkligen till att tänka hela vägen! Vilka risker kan vi stå ut med? Hur ska vi göra nu när vi insett att en vanlig VPN är direkt olämplig? Hur bevisa att man är en nörd? Med tanke på hur mycket i mitt arbete som kretsar kring NIS2 just nu, så kunde jag inte låta bli att skicka in ett personligt remissvar till försvarsdepartementet kring förslaget till den nya "Cybersäkerhetslagen"! Remisstiden gick ut den 28:e maj! Jag misstänker att inte alla håller med om mina åsikter, så ta chansen att säg emot! Eftersom jag inte formellt är ombedd att svara på remissen så går det inte att se mitt svar på Regeringskansliets hemsida, men du hittar min text i ett inlägg på LinkedIn. Det finns mycket bra att säga kring både NIS2-direktivet och den föreslagna Cybersäkerhetslagen. I mitt svar fokuserade jag på 6 saker som jag tycker kan förbättras men som inte fått den rätta uppmärksamheten: Lagen sägs syfta till hög cybersäkerhet vilket jag tycker är ett lite inavlat sätt att se problemet. Det borde handla om att hantera samhällets risker som orsakas av brister i cybersäkerheten. Säkerhet har sällan något egenvärde! Den svenska utredningen tog bort den viktiga poängen att säkerhetsåtgärder måste vara lämpliga för sitt användningsområde. Otroligt viktigt inom OT att vi inte använder åtgärder som är farliga för verksamheten! En av mina stora käpphästar är att kemikaliesektorn definierats som att den inkluderar alla verksamheter som använder kemikalier för att producera andra varor. Det blir väldigt många industrier det! Stora organisationer som till 99.99% inte omfattas av Cybersäkerhetslagen men som har 0.01% av sin verksamhet som gör det måste uppfylla lagens krav i hela verksamheten. (Skaffa inte solceller!) Känns inte riktigt rimligt... En annan av mina käpphästar är att orden "tak" och "trösklar" anses betyda samma sak när man definierar övre och undre gränser för storlekar. Så var det inte på mina svenska-lektioner... Vissa sektorer får tillsyn och föreskrifter från fyra olika länsstyrelser. Vore ju snyggt om det blev lite samordning där... Några av dem (3 och 5) är problem redan i direktivet men skulle möjligen kunna tydliggöras i den svenska lagen. Spanskt besök i labbet! Jag har märkt att många läsare är lite extra intresserade när jag får chansen att berätta om mina äventyr med roliga saker i OT-labbet. Det tar ju förstås en hel del tid, så det blir lite långt mellan gångerna jag har något att skriva om. Den här gången är det lite extra roligt... Det är inte varje dag jag får chansen att testa en spansk OT-säkerhetsprodukt, men idag är en sådan dag! Det är företaget Opscura som med produkten Lunaria löser utmaningarna kring att segmentera och övervaka OT-nätverk på ett nytt och spännande sätt! Deras mjukvara tar utgångspunkt helt och hållet i begreppen "Zones" och "Conduits" som vi känner igen från vår favoritstandard IEC 62443. Deras grepp bygger på att man kan låta sina nätverksprylar vara kvar mer eller mindre utan förändring. Istället stoppar man in en liten ruggad dator på de platser i nätet där det ska finnas en eller flera Zoner. Dessa datorer som kallas för "VIA" och administreras i ett samlat gränssnitt. Till en början kan man låta trafik fortsätta flöda helt utan påverkan genom Viorna och i administrationsgränssnittet analyserar den verkliga trafiken i nätet. Sedan definierar man sina zoner och hur dessa får kommunicera med varandra genom Conduits. Opscura har på det här sättet lyckats skapa något som i praktiken är ett slags Software Defined Network, men utan att nätverksutrustningen behöver ha stöd för det. Switcharna kan till och med vara omanagerade om man nu tycker det är trevligt med sådana. Deras lösning ger en massa fina finesser som annars kan bli tråkiga överraskningar när man driftsätter en sådan här lösning i OT-sammanhang: Om man vill kan man släppa fram broadcast-trafik, "Layer 2", vilket gör det möjligt för programmeringsverktyg och annat som ofta använder just broadcast för att exempelvis hitta nya PLC:er på nätverket redan innan de konfigurerats. I och med att man definierar en Conduit mellan två Zoner så definierar man också brandväggsreglerna som ska gälla för den kommunikationen. Det betyder att filtreringen sker ute på varje Via och inte behöver involvera vanliga brandväggar. Om man vill samla in trafik i nätet för att skicka till exempelvis en IDS, såsom Nozomi Guardian, blir det oftast svårt att få tag på trafik "långt ut i nätet". Opscura kan aggregera trafik som samlas in ute på de olika Viorna och presentera det som en samlad kopia på ett lämpligt ställe där IDS:en kan suga i sig trafiken. Med samma funktion som samlar nätverkstrafik till en IDS kan man också spela in nätverkstrafik någonstans i nätet och sedan ladda ner den som en pcap-fil som går att titta på i Wireshark eller något annat verktyg. Helt ovärderligt för både felsökning och när man planerar segmentering. För att testa om det här fungerar i verkligheten drog jag igång en test-process som jag skrivit om förut i bland annat Nyhetsbrev #54, en PLCnext från Phoenix Contact som styr en hiss och några transportband som simuleras i Factory IO via ett remote IO över MODBUS TCP. Via-funktionerna körs på två fysiska datorer, som i det här fallet kommer från Schneider Electric och management-servern körs på en annan liten PC. I labbet står de intill varandra men i praktiken finns de kanske på helt olika platser med någon form av nätverksförbindelse mellan dem. Inkopplingen av de två Viorna mellan PLC:n och IO:t i labbuppställningen var helt odramatisk. Det blir förstås ett avbrott när man drar ut en sladd men sedan flödade funktionen som vanligt trots att nätverkstrafiken passerade fram och tillbaka genom de två Viorna. I det här läget kan man välja att manuellt skapa Zones och Conduits i administratörsverktyget, under förutsättning att man vet vilken typ av kommunikation som behövs. Annars drar man igång Opscuras inbyggda analys av all nätverkstrafik som direkt listar vilka enheter som pratar på nätet, vem som pratar med vem och sedan ritar upp detta tydligt. De blå rutorna i bilden är Viorna och visar vilken Via som hanterar vilka enheter på nätet. Zoomar man in närmare så ser man vad som är vad: När man har sina Zones och Conduits så ber man Viorna att sluta bete sig som en "Wire" och istället börja skydda trafiken. Jag slog på skyddet medan "tillverkningsprocessen" var igång och det fungerade utan störningar! När man tittar på trafiken på nätet ser man tydligt att det istället för MODBUS-paket enbart skickas krypterad trafik mellan Viorna. Före: Och efter: Ja, trafiken som går genom en Conduit är alltså automatiskt krypterad. Då kanske någon tänker: "Men kryptering kan ju vara lite klurigt i OT-världen?". Ja, så är det men i det här fallet ser jag faktiskt ingen nedsida: Systemet sköter om all nyckelhantering själv Det gör inget att trafiken blir "osynlig" eftersom Lunaria kan erbjuda en kopia av all trafik till IDS:er och liknande säkerhetslösningar. Krypteringen gör att man kan skicka trafik genom nätverk som man inte litar fullt ut på även om man förstås inte löser risker med avbrott orsakade av angrepp mot nätverket. Även om kryptering alltid introducerar en liten extra fördröjning så verkar lösningen verkligen vara trimmad på ett sätt som gör påverkan minimal. Jag kanske inte skulle använda den på väldigt tidskritiska lösningar men annars så... Om du läst tidigare nyhetsbrev så vet du kanske att jag har stort hopp om att SDN, Software Defined Networking, ska bli en vanlig lösning för OT-nätverk. Opscura infriar väldigt mycket av den nytta som SDN ger, men på ett sätt som inte påverkar den underliggande nätverksinfrastrukturen. Det blir förstås extra intressant i sammanhang där utrustningen finns på olika fysiska platser och kommunicerar mellan nätverk som kanske hanteras av olika grupper. Är man på jakt efter en lösning som gör det enkelt att bygga nät baserat på Zones och Conduits tycker jag absolut man ska överväga Opscuras lösning! Vem vill ha ett trasigt nätverk? I det här nyhetsbrevet får du faktiskt två tester i labbet! Jag har lyckats få fingrarna på en väldigt "udda" men rolig produkt från Keysight som simulerar "dåliga" nätverk, NE2 - "Network Emulator 2". Det är ju inte helt ovanligt att ett system fungerar bra när man testar det under perfekta förhållanden, men sedan fungerar mycket sämre efter driftsättning när nätverket tappar enstaka paket eller det blir fördröjningar på grund av långa avstånd. Med NE2 kan man bli väldigt kreativ med elakheterna som man vill introducera under tester! Som vanligt när det är en Keysight-produkt så är det väldigt välgjort och kompetent! Jag kom snabbt igång och kunde simulera en dålig förbindelse mellan de två Viorna i Lunaria-lösningen i föregående text. Trots ett något blygsamt utseende är det en riktigt kraftfull manick! Du har möjlighet att manipulera upp till fyra separata nätverksförbindelser samtidigt som valfritt kan vara koppar eller fiber, var och en upp till 16 Gb/s. Det finns en rejäl arsenal med påverkan som man kan kombinera för att simulera utmanande nätverk. Vad sägs exempelvis om att: Rena bit-fel, där en eller flera slumpmässiga bitar i huvudet eller innehållet för vissa paket blir fel. Slumpmässigheten styr du själv och kan baseras på olika statistiska fördelningar: Periodic, Uniform, Gaussian och Poisson. Trasig laser för fiberförbindelser där lasern helt enkelt stängs av slumpmässigt. Påverka hur paket fördelar sig över tid, exempelvis skapa "Bursts". Låtsas vara en asymmetrisk förbindelse, typ DSL eller satellit, som har olika hastigheter i de båda riktningarna. Maximera bandbredden som kan användas. Påverka olika typer av trafik på olika sätt. Skapa IPv4-fragmentering genom att automatiskt hugga sönder paket och dela upp dem i flera mindre paket. "Tappa bort" paket på valfritt slumpmässigt vis. Manipulera innehållet i paket men återställa checksummor så de stämmer. Fördröjningar som kan vara konstanta eller slumpmässiga. Byta ordning på nätverkspaket så de kommer fram till mottagaren i "fel" ordning. Slumpmässigt skapa kopior av paket så att det kommer flera av samma till mottagaren. En del av dessa elakheter kan dessutom utföras på Fibre Channel om man har sådana förbindelser. Det här är en riktigt cool pryl som definitivt platsar om man är riktigt seriös i sina tester av systemlösningar. Mina tester med Lunaria visade tydligt att Opscura klarar "dåliga" nätverksförbindelser, men man kan tyvärr inte säga samma sak om min PLC-programmering som spårade ur rejält när jag var elak mot den... Det vanligaste problemet för OT-lösningar som man kan komma åt med NE2 är nog system som kommunicerar över långa avstånd eller via media som drabbas av en del störningar. Att kunna hitta lösningar på sådan påverkan redan under testerna blir mycket enklare än felsökning när man väl är ute i fält! Som vanligt gillar jag Keysights sätt att leverera solida lösningar på ovanliga utmaningar! Snyggt jobbat! Ett boktips från förr! Man kan tycka att det är en bok som jag borde ha läst för länge sedan, men jag har alltid tänkt att jag redan hört alla historier kring NotPetya, Sandworm, Projekt Aurora, Industroyer och 74455 - hur mycket mer kan Andy Greenbergs klassiska bok "Sandworm" tillföra? Det visar sig - en hel del! Det var en del pusselbitar som föll på plats och att läsa om händelserna i Ukraina 2017 fick förstås lite extra tyngd. En bok som alla som sysslar med OT-säkerhet bör läsa men också alla som någonsin uttalat orden "Varför skulle någon vilja hacka oss?". Stark läsrekommendation helt enkelt! Passar utmärkt som semesterläsning... Jag har inga sårbarheter kvar - kan jag ta ledigt då? I IT-världen innebär aktivt säkerhetsarbete ofta att man spenderar mycket tid på att jaga nyannonserade sårbarheter i mjukvara, CVE:er. Ni vet hur det är... "Oj! Titta på den här nya sårbarheten i vår webbserver, nu måste vi genast patcha!". Det innebär en ständig jakt mot något slags perfekt tillstånd där man inte har några sårbarheter. Om det är svårt för IT-folket så blir det genast ännu värre i de flesta OT-miljöer på grund av alla möjliga viktiga begränsningar i hur vi vill ändra i våra system. Det innebär att målet "Noll sårbarheter" blir så gott som omöjligt att uppnå. Dessutom blir det som jag skrev i Nyhetsbrev #59 så krävs trots det väldigt mycket arbete för att analysera vilka sårbarheter som verkligen är viktiga för oss ur den fullkomliga floden av sårbarhetsannonseringar som flödar över oss! Nästa insikt kommer när man börjar fundera över så kallade "Zero Days", alltså sårbarheter som de elaka hackarna känner till, men som ännu inte upptäckts av oss andra. Vi kommer alltså sannolikt aldrig ha "Noll sårbarheter", utan bara "Noll av oss kända sårbarheter". Det är en väldigt jobbig tanke i IT-världen, där man ofta är väldigt exponerad för omvärlden. Men för OT-folket blir det också en jobbig tanke men av delvis andra skäl, vi är ju vana att vi ska bygga robusta system som tål att något går snett i den fysiska processen. Varför kan vi inte göra samma sak när händelsen orsakas av en cyberbrist? Ett koncept som vi borde diskutera mer är "Cyberrobusthet". Alltså tanken att våra system exempelvis ska tåla en oväntad sårbarhet som utnyttjas utan att något allvarligt inträffar och att vi dessutom alltid ska upptäcka att det hänt. Det finns förstås många olika sätt att närma sig den här frågan. Jag har tidigare skrivit om metoder som CCE, "Consequence-driven, Cyber-informed Engineering" där man just fokuserar på att bygga bort allvarliga konsekvenser med fysiska åtgärder. Lite på samma tema kan man tänka kring potentiella sårbarheter som man inte känner till ännu. I Nyhetsbrev #49 skrev jag om MITREs nya version av CWE-ramverket som nu mappar mot några av delarna i IEC 62443. Om man tar den kopplingen och använder den för att göra analysarbetet jag skrev om i Nyhetsbrev #59 så kan man bygga ett försvar som gör ännu så länge teoretiska sårbarheter harmlösa genom att förekomma dem med andra åtgärder än patchning. Man resonerar alltså kring typer av sårbarheter snarare än en viss specifik sårbarhet, vilket är svårare men också mer meningsfullt! Det här gör att vi också får ett annat bra resultat på köpet, vi slutar resonera om sårbarheter i betydelsen "Buggar i mjukvara" och byter till att prata om det som ordet "Sårbarheter" egentligen betyder - nämligen svagheter i våra systems robusthet. Blir systemen så robusta att de tar hand om mjukvarubrister så har vi ju ingen sårbarhet! Jag tror det här är ett mycket vettigare sätt att spendera säkerhetsresurserna än att syssla med brandsläckning. Det är lätt av avfärda resurser som MITRE CWE med "Det där är för utvecklarna", men då missar man riktigt viktiga poänger. Det är lite likt hur man kan använda MITRE ATT&CK för att analysera sina försvarsförmågor. Vi kanske inte får ta extra semester men vi får i alla fall vara ifred för sårbarhetslarm på semestern. Samtidigt är det här förstås inte svaret på alla våra problem. Vi kan inte alltid utforma våra system på det optimala sättet för god cybersäkerhet, eftersom det skapar andra typer av risker som vi tycker är värre! Begreppet "insecure by design" används ibland lite skämtsamt för detta. Allt detta är dessutom beroende av ett aktivt säkerhetsarbete så att systemens förmågor inte förfaller över tid. På samma sätt måste vi också se upp så att vi över lite längre tid inte börjar kompromissa bort alltför mycket av vårt säkerhetstänk. Marco Ayala pratade om precis detta på årets S4-konferens, tänkvärt... Den bäst bevarade hemligheten inom svensk industri! Jag spenderade nyligen några dagar på Elmia Produktionsmässor i Jönköping. En verklig högtid för alla med koppling till tillverkande industri, massor med automationlösningar, verktygsmaskiner och annat kul att titta på. Mindre kul var att jag hade samma upplevelse som tidigare år, nämligen att det inte finns något som helst fokus på säkerhetsfrågor. Kunderna frågar inte efter det och leverantörerna skryter inte om att de har det. Bland alla föredrag och presentationer under mässdagarna så var det (nästan) bara jag som pratade säkerhet. Dessutom var det väldigt tydligt att industrin inte har förstått att NIS2 och den nya Cybersäkerhetslagen även berör många tillverkande industrier. Det kommer bli ett hårt uppvaknande för många framåt hösten... MSB svarar på frågor! Ett steg i rätt riktning är att MSB och vissa av tillsynsmyndigheterna börjat ha informationsevent kring NIS2. MSB har annonserat att man kommer svara på de vanligaste frågorna den 18:e juni. Öppen antagonistisk hotbild för svensk elförsörjning Svenska Kraftnät släppte nyligen dokumentet "Öppen antagonistisk hotbild för svensk elförsörjning" som kan vara väldigt intressant även om man inte är i elbranschen. Säkerhetskrav för elnät? Jag har ärligt talat inte hängt med på det sätt som jag kanske borde när det gäller EUs nya förordning för "gränsöverskridande elflöden". Det låter ju inte vansinnigt relevant för så speciellt många verksamheter, eller hur? Nu i mars släpptes så den slutgiltiga versionen och när jag nu läser så noterar jag en del intressant ändå: Lite på samma sätt som exempelvis CER-direktivet ska man inte själv avgöra om den egna organisationen omfattas, man blir utpekad av en myndighet. Inte bara elföretag kan omfattas utan även exempelvis MSSP - Managerade säkerhetstjänster, IT-outsourcingleverantörer, elbilsladdare mm Det är väldigt många kopplingar till NIS2-direktivet För den som ligger nära sådan verksamhet eller har kunder som gör det bör nog följa med vad som kommer framöver kring den här kravmassan! Kanske en kurs hos Svenska Kraftnät? Jobbar du i en verksamhet som påverkar elnätets stabilitet som producent eller förbrukare? Då har Svenska Kraftnät en kurs för dig! På deras utbildningssida står: Svenska kraftnät arrangerar sedan en tid tillbaka en kurs för personal inom elsektorn där deltagarna får bekanta sig med ett brett spektrum av risker och hotscenarier kopplade till cybersäkerhet och industriell styrning (ICS). Under 2023 har runt 200 personer antagits och genomgått kursen. Kursen är en elberedskapssatsning och målgruppen är personer som direkt eller indirekt arbetar med elnätsdrift, it-stöd eller säkerhet på svenska elnätsföretag, hos vissa större förbrukare eller i andra organisationer vars verksamhet kan påverka nätstabiliteten. Kursen genomförs i internatform under tre dagar (lunch-lunch) och är anpassad för att underlätta deltagande från hela Sverige. Anmälan sker efter inbjudan från Svenska kraftnät. Intresseanmälan kan skickas till icskurs@svk.se. Här behövs också en kurs! Jag kan tyvärr inte säga att jag är förvånad... Runt om i världen fortsätter det inträffa hacker-incidenter där OT-utrustning som placerats direkt på Internet blir saboterade. Å andra sidan ska man definitivt inte tro på siffrorna i Shodan och andra scanningsverktyg, det är sannolikt minst 80% honeypots bland de OT-prylar som dyker upp där. Men ändå... Jag fick nyligen ett mejl från Rockwell Automation som skickade ut en advisory med den fantastiska rubriken: IMPORTANT NOTICE: SD1672 – Rockwell Automation Reiterates Customer Guidance to Disconnect Devices from the Internet to Protect from Cyber Threats Att det kan hända av misstag ska man naturligtvis tänka på och försöka upptäcka som del i sitt säkerhetsarbete. Jag är nyfiken att höra om dina erfarenheter, har du hittat tokigt installerade prylar? Ska vi höras? I ett tidigare nyhetsbrev öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt så jag kommer repetera den här texten framöver. Jag har redan haft ett antal kul samtal med roliga människor från spännande verksamheter av alla de slag. Du behöver förstås verkligen inte vara proffs på just OT-säkerhet för att det ska bli ett intressant utbyte av erfarenheter och tankar! En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite. Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt. Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra. Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats. Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY. Det här nyhetsbrevet ger jag ut helt privat baserat på mitt intresse för området och utifrån att det verkar matcha ett behov av information kring OT-säkerhet på svenska. Innan jag blev konsult för några år sedan spenderade jag det mesta av mitt arbetsliv inom kärnkraftsbranschen. Det är härifrån som jag har fått mitt intresse för OT-säkerhet, fysiskt skydd, human performance och säkerhetsskydd. Jag har ett grundmurat intresse för alla former av säkerhetsfrågor och kanske i synnerhet när det knyter samman kul teknik med utmanande frågor runt hur vi människor hanterar tekniken. På senare år är det nästan uteslutande OT-säkerhet och till viss del säkerhetsskydd som jag arbetat med. Båda två år områden där det är väldigt viktigt att hantera tekniska och mänskliga utmaningar tillsammans. Jag är alltid väldigt tacksam för alla former av kontakt eller återkoppling från dig som läser detta. Det är intresset från mina läsare som gör det roligt och meningsfullt att hålla liv i nyhetsbrevet. Hör gärna av dig till mats@ot-sakerhet.se ! Det här nyhetsbrevet vänder sig till personer som är intresserade av säkerhet inom OT. Det produceras av Mats Karlsson Landré och får spridas vidare fritt. Tanken är att det ska innehålla tips om intressanta resurser kombinerat med mina egna tankar om aktuella händelser. Återkoppla gärna med egna idéer eller funderingar till mats@ot-sakerhet.se! Förslag till ämnen eller innehåll tas förstås emot med tacksamhet! Om du önskar få nyhetsbrevet direkt till din inkorg i fortsättningen kan du gärna kontakta mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta! Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

  • Nyhetsbrev OT-Säkerhet #61

    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.

  • Nyhetsbrev OT-Säkerhet #60

    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.

  • Nyhetsbrev OT-Säkerhet #59

    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.

bottom of page