top of page
Sök

Nyhetsbrev OT-Säkerhet #73

  • 29 dec. 2025
  • 21 min läsning

Uppdaterat: för 20 timmar sedan

Dags för en riktigt fullproppad utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången lovar jag sluta prata så mycket om NIS2, vi får tips om AI inom OT, lär oss att svenska myndigheter skannar våra system, lurar angripare med deception-verktyg, fördelar ansvar där det hör hemma, djupdyker i våra kära Security Levels, funderar på vad vi vet om vad som faktiskt fungerar, inser att det är fysiskt omöjligt att ha god säkerhet längst ut i processen, deppar ihop över att år2000-problemet är tillbaka i ny skepnad, lär oss nätverketsövervakning av NERC CIP, tittar på indiska SOCar, får en ny version av PROFINET, korkade ryska hackers, funderar över svarta svanar, surar över årsrapporter, lär oss ledarskap, virtualiserar PLCer och avslutar väldigt starkt med kännetecken på bra riskanalyser!


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!

Nej! Ingenting om NIS2 eller CRA!

Den 29:e december 2020 skrev jag för första gången om NIS2 i nyhetsbrevet. Det var Nyhetsbrev nummer 21 och Kommissionen hade just släppt ett förslag till ett nytt NIS-direktiv. Då var jag väldigt positiv till det nya direktivet och det är jag egentligen fortfarande. Dess fokus på proportionerligt säkerhetsarbete baserat på begreppet "Allrisk-ansats" är precis vad som behövs för att få lite mer tryck i samhällets robusthet.


Redan på första sidan av direktivs-texten förklarade man varför ett nytt direktiv behövdes. En av de viktigaste var att länderna inom EU implementerat kraven i det första NIS-direktivet helt olika vilket skapade orättvisa och handelshinder. Tyvärr kan jag nu konstatera att man inte lyckats speciellt bra med just det målet. För de verksamhetstyper som faller under EUs gemensamma krav, exempelvis IT-tjänster ser det riktigt bra ut. Men för övriga sektorer är lagstiftningarna och kraven i de olika länderna är fortfarande helt olika. Många länder, inklusive Sverige, verkar skjuta det där med Allrisk-ansats och Proportionalitet i sank genom att ställa onödigt detaljerade krav som ska implementeras allt för brett.

Nu har Riksdagen fattat beslut om den svenska implementationen av NIS2 och MSB har kört ett antal föreskrifter på remiss. Samtidigt har även arbetet med CRA fått väldig fart och det kommer nyheter nästan varje dag. Vi är nästan i mål men samtidigt har många stora organisationer fortfarande inte ens påbörjat arbetet...


NIS2 och CRA kommer över tid få en enorm inverkan på hur robust vårt digitala samhälle är. CRA är komplext och utmanande, men det är nödvändigt för att höja nivån brett i alla digitala komponenter. NIS2 kommer få stor effekt på hur vi arbetar med cybersäkerhet i samhället, men vi måste nog tyvärr vänta på NIS3 innan vi får den där Proportionaliteten på riktigt. Det kommer nog dröja 8-10 år innan vi är där. Men då räknar jag kallt med att man orkar trycka igenom en gemensam lagstiftning i form av en EU-förordning som blir gemensam för alla länderna på riktigt.


Med början i denna utgåva av nyhetsbrevet kommer jag framöver skriva betydligt mindre om NIS2 och CRA. Nu har intresset för dessa frågor blivit tillräckligt stort för att vettig information ska komma ut på mer direkta sätt. Om ett ämne har en tydlig koppling till OT-säkerhet så kommer det förstås att platsa även framöver.


Men misströsta inte! Det kan nog bli en hel del NIS2 även i fortsättningen. Majoriteten av de organisationer som berörs av NIS2 gör det på grund av de har en verksamhet som är OT-baserad. Det kommer finnas gott om spännande OT-säkerhetsutmaningar framöver för alla som ska leva sitt liv under den svenska Cybersäkerhetslagen!

AI och OT?

Principles for the Secure Integration of Artificial Intelligence in Operational Technology

Samarbetet mellan cybersäkerhetsmyndigheterna i Kanada, USA, Tyskland, Australien, Nya Zeeland och Storbritannien fortsätter med nästa gemensamma dokument - nu handlar det om användning av AI i OT-världen.


Vi får fyra grundläggande principer som var och en underbyggs av ett antal åtgärder:

  1. Understand AI. Understand the unique risks and potential impacts of AI integration into OT environments, the importance of educating personnel on these risks, and the secure AI development lifecycle.

  2. Consider AI Use in the OT Domain. Assess the specific business case for AI use in OT environments and manage OT data security risks, the role of vendors, and the immediate and long-term challenges of AI integration.

  3. Establish AI Governance and Assurance Frameworks. Implement robust governance mechanisms, integrate AI into existing security frameworks, continuously test and evaluate AI models, and consider regulatory compliance.

  4. Embed Safety and Security Practices Into AI and AI-Enabled OT Systems. Implement oversight mechanisms to ensure the safe operation and cybersecurity of AI-enabled OT systems, maintain transparency, and integrate AI into incident response plans.

Jag slår på min egen trumma!

Jag brukar undvika att skriva för mycket om mitt eget arbete och min arbetsgivare Sectra i nyhetsbrevet. Nu gör jag ett undantag för ett whitepaper där vi tittat på alla krav på säkerhet som numera träffar verksamheter från alla möjliga håll. Om man tittar på MSBs föreskrifter till Cybersäkerhetslagen/NIS2, SÄPOs vägledning till Säkerhetsskyddslagen, alla branschspecifika regelverk och förstås standarderna IEC 62443 och ISO 27000 så märker man att vissa grundläggande saker kommer igen från dem allihop. I vårt exempel tittar vi på VA-branschen, men samma tendenser finns kring de flesta verksamhetstyper. Vi är förstås lite extra intresserade av säkerhetsövervakning, SOC-tjänster, så fokus ligger där. Vad förväntas egentligen av dig? På köpet får du med vettiga kravställningar att använda när du ska skaffa den här typen av tjänster.

Myndigheterna skannar dina system!

...fast bara om du ber om det! CERT-SE erbjuder möjligheten att få sina externa system skannade efter sårbarheter, GRATIS. Det är i första hand inte tänkt att användas för OT, men i vissa situationer kan det vara relevant. Man fyller i en intresseanmälan och anger vilka domäner, IP-adresser och eventuellt AS-nummer som ska skannas.


MEN! Kom ihåg att detta är just det - en skanning av det du känner till och bara det som är åtkomligt "utifrån". Du kommer inte hitta okända system på okända platser på nätet. Du kommer inte få skanning av de delar av system som kräver inloggning. Du kommer inte hitta saker som är exponerade på andra sätt - exempelvis via trådlös teknik eller gentemot partnerföretag. Är du orolig för okända 5G-modem, Wireless HART eller länken till din integratör så behöver du andra lösningar. Därmed inte sagt att erbjudandet från CERT-SE är dåligt, tvärt om! Men som alltid behöver du veta vad som faktiskt ingår.


Notera också att du automatiskt blir anmäld till deras existerande tjänst, ANTS, först. Efter en vecka dras den utökade skanningen igång - under förutsättning att ni fixat eventuella svagheter som ANTS hittade. Notera också att denna tjänst vänder sig till organisationer som omfattas av NIS2.

Deception - orsaka kostnader för angriparen!

Brittiska NCSC håller på med försök kring hur väl Deception fungerar i praktiken som en säkerhetsåtgärder. Det annonserades i början av hösten och nu kom det ett blogginlägg med lite lärdomar de dragit så här långt. Lärdomarna kommer ur ett "experiment" de gjort med 121 olika organisationer, 14 leverantörer av "Cyber deception solutions" och 10 produkt-tester. Snabbt summerat är deras slutsatser just nu:

  • Deception funkar men det går inte av sig själv

  • Ett problem är oklara definitioner och ord

  • Organisationer vill inte prata om att de använder deception

  • Det finns dåligt med vägledning

  • Det finns risker - exempelvis att man skapar nya sårbarheter eller risker


Det ska bli spännande att se var detta tar vägen. Personligen tror jag mycket starkt på deception som ett starkt verktyg i säkerhetsarsenalen, speciellt i OT-sammanhang. Det ska absolut inte vara det första man satsar på, men som förstärkning av en redan etablerad säkerhetsfunktion finns det nog inte mycket som slår det i effektivitet! Om man å andra sidan inte har grundläggande säkerhetsövervakning på plats, en OT-SOC med vettig övervakning av nätverk och system, kommer inte deception att tillföra något annat än mer kostnader.


Om du vill lära dig mer finns ett nytt spännande initiativ från Marcel Rick-Cen. Det är en utbildning, DCEPT, som fokuserar på just Honeypots och Honeynets med inriktning mot OT. Jag har inte provat den själv, men kursprogrammet ser välfyllt och relevant ut! Om du provar så får du gärna höra av dig med dina intryck. mats@ot-sakerhet.se

Ansvar ska fördelas på konsekvenser - inte teknik!

I en riktigt välskriven artikel sätter Sinclair Koelemij fingret på några grundläggande sanningar kring den ständiga frågan om hur vi ska få IT och OT att närma sig varandra i säkerhetsfrågor. Hans tes är att frågan är fel ställd, att definiera organisation och ansvar utifrån teknikområden är det grundläggande felet. Det här är en ganska lång text av den alltid lika kloke och tydlige Sinclair. Om det är en enda text från det här nyhetsbrevet som du faktiskt ska läsa ordentligt, så är det den här.

What the industry must recognize is that responsibility must follow the consequence, not the cause. Whether a deviation begins with corrosion, fatigue, misconfiguration or malicious manipulation is secondary. What matters is that the hazard develops in the production installation, and that is where ownership and analysis must begin.

Det är ju väldigt självklart för oss som sysslar med detta dagarna i ända, men ändå är det väldigt sällan jag ser att man faktiskt tänker konsekvensdrivet när man bygger sin organisation. Om det är så att du vill ta tag i detta i din organisation finns massor av bra citat och kloka tankar i Sinclairs text:

That means the owner of the hazard, not the owner of any individual technology domain, must lead detection, diagnosis, mitigation, and response. The potential hazards determine the priority, not the location of the initiating manipulation. This is not only operational logic; it reflects legal reality. The plant’s accountability and regulatory responsibilities are determined by the consequences, irrespective of whether the initiating deviation originated in IT, OT or an external intrusion.

Det här är förstås sant oavsett om din definition av en riktigt dålig dag är att produktionen står still eller om dina värsta konsekvenser är katastrofala fysiska händelser med dödsfall och förstörelse. Utebliven produktion blir inte roligare bara för att orsaken var att inköpsfunktionen fått sitt IT-system hackat och därför inte kan köpa råvaror. När din kollega dör i en explosion spelar det ingen roll att angriparen som utlöste explosionen kom in via HR-avdelningens rekryteringssystem.


Sinclair spär mot slutet på med en annan gammal sanning som är värd att upprepas - att klassiska resonemang kring Safety inte fungerar när orsaken inte är slumpen utan en medveten och skicklig angripare.

Våra kära gamla Security Levels!

Avslutningen i Sinclairs artikel här ovanför anknyter som sagt till hur saker och ting blir annorlunda när risker skapas med flit av en kunnig (och elak) angripare. Om man fortsätter det resonemanget blir nästa naturliga fråga om det finns grader av kunnighet (och elakhet) hos angripare? Då landar vi i Sinclairs nästa artikel som han levererade på själva julafton.


I texten plockar han upp den diskussion som varit i diverse sammanhang på sistone kring begreppet "SL - Security Levels" i vår favorit bland standarder: ISA/IEC 62443. Traditionellt har standarden definierat de 4 nivåerna av SL baserat på vilket typ av angripare de ska motverka. Från SL1 som i princip bara skyddar mot misstag till SL4 som ska skydda mot "Nation states" - dvs angripare med stora kunskaper och i princip oändliga resurser.


I den värld vi lever i nu har det här sättet att tänka slutat vara relevant. I arbetet som pågår med att modernisera standarden är en av sakerna man tittat på att istället basera Security Levels på bedömd risk. Och det är detta resonemang som Sinclair driver med den kloka insikten att det gör SL riskdriven när den kravställs, men att det inte betyder att resultatet efter säkerhetsåtgärder ändras.


Jag ska inte återberätta hela Sinclairs text, som, som vanligt, är väl värd att läsa. Extremt sammanfattat handlar det om att Security Levels är bra som indata i risk- och säkerhetsarbete men det ska absolut inte ses som ett sätt att bedöma vad acceptabel risk är.

Men det är inte slut där! - Mer Security levels!

Sinclair slutade inte tänka på Security Levels med den ovanstående artikeln. Några dagar senare följer han upp med tankar om vad man faktiskt kan göra om man tänker lite annorlunda kring begreppet Security Level. Nu landar han i något som matchar perfekt med min egen syn på det här. SL passar bra att definiera den grundläggande motståndskraften i ett system - oavsett om det bedöms som tillräckligt eller inte. (Eller för mycket...)


Det här är en ganska lång text, men vartenda stycke innehåller en guldklimp. Läs den här texten om du är det minsta intresserad av 62443, Security Levels, Zones & Conduits, Safety, SIL eller något av alla andra ämnen som Sinclair på ett magiskt sätt lyckas stoppa in i en och samma text.


Är texten för lång, så läs i alla fall sista delen, under "Conclusion". Sista stycket sammanfattar varför detta är otroligt viktigt:

Used in this way, Security Levels remain a powerful and scalable engineering tool. They structure protection, guide architectural decisions, and focus effort. What they do not do is replace risk justification where consequences matter. Recognizing that boundary does not weaken cyber security practice. It makes it defensible.

Kommer du till S4 nästa år?

Världens i särklass mest intressanta OT-säkerhetskonferensen är i mina ögon S4. Biljetterna till detta event i februari är nu på god väg att ta slut.


Just nu ser vi ut att vara (minst) 10 svenskar som kommer dyka upp. Det vore kul om vi blev ännu fler! Läs mer här.


Om du inte får nog med "bara" S4 så arrangeras en Bsides-konferens dagen innan och agendan ser riktigt spännande ut. Ses vi där?

Vet vi vad som faktiskt fungerar bäst?

Dale Peterson (som för övrigt är den som organiserar S4-konferensen ovan) skriver i en tänkvärd artikel att vi fortfarande har väldigt lite bevis om vilka säkerhetsåtgärder som faktiskt är mest effektiva i OT-världen. I texten använder han exemplet "asset inventory" som det har blivit något slags allmän sanning att man måste ha först av allt om man ska arbeta med OT-säkerhet. (Märks det att jag håller med?) Hans text trycker på problemet att AI dessutom förstärker det här problemet. Har man för lite riktigt mätbara indata men mycket tyckanden och säljpropaganda så kommer förstås AI att förstärka de starkaste budskapen.


En viktig påminnelse om att vi måste tänka själva och alltid utgå från vår egen organisations förutsättningar! Det är förstås speciellt viktigt om vi samtidigt ska visa att vi uppfyller lag- och myndighetskrav.

Är cybersäkerhet möjligt nära en fysisk process?

En närmast religiös debatt som ständigt dyker upp är om man kan skydda de komponenter som sitter allra närmast den fysiska processen, och i så fall, hur det skulle går till? Vi talar om det som ofta kallas "Level 0" - alltså gränssnittet mellan den fysiska processen och automationssystemet.


En av de envisaste förkämparna inom det här området är Joe Weiss som nyligen skrev en artikel på området, där han beskriver konsekvenserna och uppmanar till att försöka lösa dessa utmaningar: "The unaddressed cyber frontier: Level 0 sensor measurement integrity".


Som ett slags svar skrev sedan Sinclair Koelemij en enastående artikel som beskriver VARFÖR det är ett så svårt problem att lösa. Om du verkar inom processindustri eller någon annan verksamhet där säkerhet i sensorer är avgörande för anläggningens säkerhet är detta i princip nödvändig läsning.

To illustrate: a typical Zone 0 intrinsically safe 4–20 mA pressure transmitter is limited to roughly 1.5 mW at the sensor head under worst-case fault conditions (IEC 60079-11). Even lightweight cryptographic functions such as Ed25519 or SPECK require several milliwatts during key exchange or signing, and introduce tens of milliseconds of processing delay. Both the energy requirement and the added latency exceed what is permissible for microsecond-scale control loops and for devices that must remain non-igniting in explosive atmospheres.

Det här är ett klurigt och eftersatt område. Sinclair har fler artiklar som anknyter till ämnet som kan vara värda att titta på också:

Har du koll på Y2k38?

Det är nog dags att påminna igen om att vi har "ett nytt Y2k" framför oss. Den 19:e januari 2038 vid 03:14:07 UTC kommer system som använder en 32-bitars "Unix epoch" klocka för att beskriva tid att slå om till noll. Det innebär att klockan plötsligt går från att vara en tidig januaridag 2038 till att bli en sen kväll den 13:e december 1901!


Den som någon gång skrivit något slags programvara som hanterar tid inser direkt att detta är ett dödligt problem för mjukvara. Men 2038 är ju långt borta tänker man kanske? Men är man van vid hur ofta saker byts ut i OT-världen så inser man att många komponenter som är nya idag fortfarande kommer vara i drift 2038...


Det var nyligen rubriker i fransk media när tågtillverkaren Alstom efter sex år i domstol tvingades åtgärda detta problem för åtta tunnelbanelinjer och sex spårvagnslinjer. Dessa hade annars stannat 2038...


Förutom rena applikationer som är använder time_t med 32-bitar oavsett vilket operativsystem som används är extremt många operativsystem drabbade om de har ett par år på nacken. Vi vet ju att det fortfarande säljs produkter som är baserade på väldigt gamla operativsystem. Det är förstås inte självklart att precis allting plötsligt kommer sluta fungera men precis som inför år 2000 kommer väldigt många verksamheter inte våga chansa. Det innebär också att vi redan nu måste kräva att allt vi köper garanterat inte innehåller någon 32-bitars tid. SBOM någon?


Exempel på system som sannolikt ligger illa till (även nyare versioner kan drabbas):

  • Klassiska Linux-distributioner med en kärna tidigare än 5.6

  • Android fram till och med version 4 på ARMv7

  • NetBSD före 6.0

  • OpenBSD före 5.5

  • FreeBSD i386-userland

  • Solaris om man använder 32-bitars applikationer

  • Alla gamla unix-varianter: AIX, HP-UX, IRIX, OSF/1 osv

  • iPhone 5 och tidigare

  • OS X på PowerPC


OT-världens leverantörer har väldigt mycket gammal proprietär kod i bagaget när vi pratar inbyggda Linux-system och RTOS-system.


Vi ska också komma ihåg att samma problem finns på andra platser där tid lagras i 32 bitar, exempelvis databaser och filsystem.

  • Filsystem: ext2, ext3, reiserFS och andra som lagrar fil-tider i 32-bitars fält i inoder på 32-bitars plattformar.

  • Databaser: Kolumner som sparar Unix-tid i signerat 32-bitars int och funktioner som UNIX_TIMESTAMP() i SQL-dialekter när resultatet castas till 32 bitar.

  • Applikationsspråk och bibliotek: Äldre C/C++-kod som lagrar time_t i int32_t och äldre versioner av t.ex. Ruby, Java-bibliotek, skript som antar 32-bitars Unix-tid


Lycka till!

NERC CIP och intern nätverksövervakning

Den som sysslat med nätverksövervakning vet att det inte är så enkelt att få bra resultat. I synnerhet är det svårt att kunna "se" all trafik överallt i nätverket utan att det blir väldigt dyrt och komplicerat. I OT-världen är det här extra viktigt eftersom nätverksövervakning tenderar att passa ganska bra i OT-sammanhang och kan delvis ersätta andra säkerhetsåtgärder som är svåra eller olämpliga inom OT. Å andra sidan har nätverksövervakning sina egna utmaningar, speciellt kring risken för störningar och försämrad robusthet i nätverket.


Det cirkulerar en hel del artiklar kring den amerikanska organisationen NERCs nya krav ( CIP-015-1 ) på övervakning av intern nätverkstrafik, här är exempelvis en artikel. Det har varit en hel del diskussioner och tyckanden kring det här, men sedan myndigheten Federal Energy Regulatory Commission fattade ett formellt, och mycket detaljerat, beslut i somras är det inte så mycket att diskutera kring kraven. Däremot kan man fundera mycket på hur man bäst får till intern nätverksövervakning på den nivå som krävs.


Det som krävs nu är alltså övervakning av trafik mellan system inne i det skyddade nätverket, det som ibland kallas "öst-västlig trafik". Tidigare fanns ett motsvarande krav på övervakning av trafik som gick in och ut ur det skyddade nätverket, "nord-sydlig trafik".


Oavsett om man är i elbranschen eller inte är det här en väldigt intressant utmaning. En anledning till det är att de här är ett område där det blir väldigt uppenbart att säkerhet som "läggs på i efterhand" blir dyr och inte lika bra. Det är inte helt ovanligt att jag stöter på verksamheter som stolt berättar om den nya nätverks-infrastruktur de precis investerat i och byggt. Tyvärr är det lite för vanligt att man bara fokuserat på att bygga ett superrobust nätverk, men inte fått med ett tänk som ger bra insyn överallt i nätet. Har man redan ett existerande nätverk som utvecklats under många år är det ofta ännu svårare att kunna se in i alla "hörn" i nätverket.


Det handlar helt enkelt om att "Säkerhetsfolket", "Nätverksfolket" och "Automationsfolket" måste klura på detta tillsammans för att det ska bli bra. Min absoluta favorit-referens är det listiga dokumentet "The Five ICS Cybersecurity Critical Controls" från SANS, där man pratar om "defensible architecture". Det man menar är en arkitektur som dels går att hålla uppsikt över (dvs säkerhetsövervakning fungerar bra) och dels gör det möjligt att agera effektivt på incidenter.


Du kanske är en av alla de som insett att NIS2 gör det nödvändigt med bra nätverks-övervakning? Lycka till med det - du har ett väldigt viktigt arbete framför dig!

Kloka tankar kring SOC från Indien

Det har inte varit så ofta jag har delat med mig av något från Indien, men här är ett bra dokument kring OT-SOCar. Det är skrivet av DSCI (Data Security Council of India) och Honeywell. Innehåller en hel del klokskap, jag gillar till exempel att de trycker på att bra arkitektur och segmentering är viktigt för att ge en SOC bra förutsättningar att göra nytta.

PROFINET i version 2.5

PROFIBUS and PROFINET International (PI) har släppt specifikationerna för version 2.5 av PROFINET. De fem stora nyheterna är bra stöd för IEC/IEEE 60802, framsteg på säkerhetssidan, en ny transportkanal för underhållsaktiviteter, stöd för Ethernet-APL & Single Pair Ethernet (SPE) och uppdaterade specar för GSD/GSDX.


Snabbt summerat betyder det, tur och ordning:

  1. Man ska kunna köra PROFINET över TSN-nät (Time Sensitive Networking) enligt TSN-profilen i IEC/IEEE 60802. Det gör det enklare att bygga konvergerade IT/OT-nät där PROFINET kan samexistera mer förutsägbart med annan trafik, tack vare en gemensam TSN-profil.

  2. Framstegen på säkerhetssidan verkar vara att man gått "från idé till handling". Det finns nu specade mekanismer för "Security Classes" och att man löst alla öppna frågor inklusive distribution av certifikat. Det här innebär stora förändringar så vi får se hur man hantererar kompabilitet och migrering?

  3. Transportkanalen för underhåll ska ge mer standardiserade sätt att göra parameterisering, firmvareuppdateringar mm.

  4. Stöd för APL/SPE innebär att man enklare kan "flytta PROFINET längre ut" i anläggningen. Hur detta hanteras bäst säkerhetsmässigt ska bli intressant att se.

  5. GSD/GSDX innebär att engineeringverktyg får stöd för fler nya funktioner.

Dum och Dummare: Ryska hacktivister

Srsly Risky Biz skrev i mitten av december en underbar text om "misslyckade" hacktivister som är backade av Ryssland. Department of Justice i USA släppte nyligen nyheter om två aktivistgrupper som sysslat med att genomföra "disruptive attacks against critical infrastructure worldwide".


Även om detta låter skrämmande och imponerande så är det i alla fall delvis snarare skrattretande:

  1. I en rad attacker mot vattenanläggningar har man totalt lyckas få mindre vatten än i en normal simbassäng att gå till spillo

  2. I en stor attack mot en amerikansk köttfabrik uppstod skador på hela $5000...

  3. Man har stökat med utrustningen i en biltvätt i Florida

  4. Man har påverkat klorhalten i vattnet i en nederländsk fontän


Grupperna ska ha grundats av GRU men till och med de är så besvikna att de dragit in stödet till grupperna!


Nog för att det här är töntigt så ska vi inte skratta bort problematiken. Även en blind höna - ni vet... Det här är de första stapplande stegen mot betydligt tråkigare incidenter...


Jag kan för övrigt verkligen rekommendera nyhetsbrevet som Tom Uren skriver. Och om ni inte redan lyssnar på podden "Risky Business" så gör det! Patrick Gray med stöd av Adam Boileau levererar nyheter med riktigt insiktsfulla kommentarer. Denna australiensiska skapelse är förmodligen världens bästa cybersäkerhetspodd! (Även om det inte är så mycket OT...)

Svarta svanar påminner oss om robusthet!

Ett kort inlägg på LinkedIn av Tony Martin-Vegue var en klockren påminnelse om begreppet "svarta svanar" som ibland dyker upp när man pratar risk och riskanalys. Det är ett gammalt begrepp som Nassim Nicholas Taleb gjorde populärt i sin bok "The Black Swan". Begreppet är tänkt att sätta ett namn på faktumet att det finns brutalt elaka risker som vi aldrig kommer lyckas identifiera i förväg eftersom vi inte stött på dem tidigare. När de väl inträffat är de däremot helt uppenbara.


Det som Tony pekar på i sin artikel är att det förekommer att man missförstår begreppet och istället tolkar det som de risker som är väldigt allvarliga och väldigt ovanligt - MEN KÄNDA! Däri ligger felet, de svarta svanarna handlar om att "skit händer" som vi aldrig kunnat föreställa oss i förväg.


I ett OT-sammanhang blir det här en påminnelse om att vi inte bara kan sikta på att hantera kända risker. Vi måste också bygga en tålighet tillsammans med en förmåga att hantera det oförutsedda. Mycket av det vi redan gör i vårt säkerhetsarbete gör oss starkare även mot okända hot. Det vi måste se upp med är att gå för alldeles för långt i vårt "riskdrivna proportionella säkerhetsarbete" så att vi riskerar att glömma att det finns risker som ligger utanför våra riskanalysmallar.

En recension av en årsrapport!

Om du läst mina nyhetsbrev ett tag vet du att jag inte bryr mig så mycket om alla årsrapporter som produkt-leverantörerna dränker oss i varje år. De har förstås alltid enstaka intressanta poänger, men de är ofta väl gömda bland märklig statistik, oklara frågeställningar till de som intervjuats och övertydliga produktplaceringar. Därför uppskattade jag en artikel av Jason Rivera lite extra, han har grundligt tittat på SANS årsrapport: "SANS State of ICS/OT Security 2025 Survey". Han är väldigt kritisk men lyfter också fram en del kloka tankar.


Jag rekommenderar att du läser artikeln själv. Bland alla hans insikter tänkte jag bara lyfta en som är viktig och som jag verkligen känner igen mig i. Det är alldeles för många som glatt skaffar dyra IDS-system, bygger upp SOC-verksamheter och jagar snabb detektion av säkerhetshändelser. Bra och viktiga åtgärder allihop, men tyvärr går det nästan alltid ut över nästa steg - att kunna hantera säkerhetsincidenter snabbt och effektivt när de väl upptäckts.


Det är här krutet borde läggas, det är här den egna systemkompetensen kan göra riktig nytta - hantera + återställa + bygga upp igen! Eftersom jag själv arbetar på en OT-SOC-leverantör tycker jag förstås det är fullständigt självklart att man låter någon annan göra det tunga dygnet-runt arbetet i jakt på misstänkta händelser så att den egna, unika, kompetensen kan fokusera på att bli riktigt duktig på att agera resolut när något händer. (Japp! Där kom den! Smygreklamen! Men det här tyckte jag i och för sig redan innan jag började på Sectra...)

Goda idéer för dig som är ansvarig

Phil Venables var den förste CISOn på Google Cloud och är en välkänd tänkare kring ledarskap kring Cybersäkerhet. Han har, vad jag vet, ingen direkt koppling till OT-världen men hans kloka texter fungerar i de flesta världar. Phil har just levererat den sjunde och sista delen i en räcka artiklar kring CISO-rollen där det finns mängder med klokskap att inspireras av. Inte minst den sjunde delen där han blir extra vass och tittar kritiskt mot ledarskap inom säkerhet och hur det ofta spårar ur.


De andra sex texterna handlar om:


Om jag ska speciellt rekommendera någon del som är speciellt viktig för OT så är det avsnitt 6 om katastrofer följt av del 4 om att förbättra säkerhetsarbetet.

En PLC utan egen hårdvara?

Jag är personligen en av de som tror mycket på att framtidens PLC är virtualiserad på ett eller annat sätt. Det kommer hjälpa oss med en del av de säkerhetsutmaningar vi lider av i dagens lösningar. Jag ska säga direkt att jag inser att virtualisering av automation alltid kommer ha sina baksidor och att det därför kommer passa bättre i vissa sammanhang än i andra. Jag vill också påpeka att virtualisering i det här sammanhanget inte måste innebära att man kör sin PLC-kod i ett moln eller ett datacenter långt bort, det kan vara i en fysisk utrustning ute i produktionen.


Om du är nyfiken på området kan jag rekommendera en artikel av Ian Suhih som berättar om lärdomar de dragit av att ha utvärderat den här typen av teknik i praktiken. Det här är ett område som fortfarande är i "tidiga dagar" och vi kommer se en snabb och stor utveckling framöver!

Vad är riktigt bra riskanalys?


Om det är någonting inom säkerhetsvärlden som jag själv är riktigt frustrerad över så är det riskanalyser. Detta oerhört viktiga verktyg, som numera varenda standard och lagtext har som grund för säkerhetsarbetet, genomförs nästan alltid på ett sätt som inte leder till någonting meningsfullt. Jag har spenderat alldeles för många dagar av mitt liv, dagar som jag inte får tillbaka, i oändliga riskworkshops som inte ledde någonstans...


Jag har inget recept på den perfekta metoden för att undvika detta och vi får ingen sådan av Sarah Fluchs heller. Men i en artikel ger hon oss fem briljanta insikter om vad en bra metod ska innehålla och några trick för att få till dem! Sarah är, som du kanske redan vet, en av de stora tänkarna i OT-sammanhang så hennes tips är helt anpassade för OT-risker.

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.


 
 
bottom of page