Nyhetsbrev OT-Säkerhet #76
- för 14 minuter sedan
- 22 min läsning
Den här gången smugglar vi MODBUS-meddelanden förbi en OT-brandvägg, kraftCERT lär dig vad ”Trusselvardering” betyder, jag skrämmer dig med AI, Mattias Pilroth lär oss att fokusera på rätt saker, vi inser att nätverken ska vara nere i tre månader, herr Biba lär oss om integritet, ENISA ger oss en uppdaterad lägesbild för alla Väsentliga NIS-verksamheter, vi försöker hänga med Sinclair i hans enorma produktion av kloka texter, får 62 473 förslag till åtgärder i Cyber Informed Engineering, hittar andra sätt att resonera om sannolikhet, får en massa uppdateringar kring NIS2-föreskrifter, läser en ny take på Zero Trust inom OT, jag uppmanar alla att vara mer osäkra, lär oss hantera incidenter i industrin, träffar Stuxnets brorsa, hackar europeisk solenergi och träffar på något som heter RITICS.
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 eller med ett mejl till mats@ot-sakerhet.se. 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!
Smuggla MODBUS-meddelanden!
Itai Shmueli på SaiFlow publicerade nyligen en intressant text om möjligheten att "smuggla" kommandon via MODBUS. Det gäller ett av de absolut populäraste biblioteken för MODBUS, libmodbus, som används i tusentals olika produkter i OT-världen.
Enkelt uttryckt kan du klämma in två MODBUS-meddelanden där det egentligen bara ska finnas ett. Det som gör detta allvarligt är att eventuella filter eller skydd kring vilka MODBUS-kommandon som får utföras bara tittar på det första meddelandet. Det andra kommer att utföras helt utan begränsningar.
Det här är en del av en större diskussion under det senaste året kring OT-brandväggar som sägs kunna filtrera på detaljer i olika OT-protokoll. I MODBUS-fallet kan det vara att endast tillåta att man läser information eller att man bara får skriva till vissa Coils. Generellt är många brandväggar ganska dåliga på det här, oftast på grund av att dessa protokoll kan utnyttjas på så många olika sätt. Det blir inte bättre av att olika OT-leverantörer implementerar protokollen lite olika...
Jag säger inte att man ska undvika filtrering av OT-protokoll i brandväggar men det gäller att se upp och att inte bara ha en nivå av skydd. Djupförsvar är viktigt om det man skyddar är viktigt!
Hoten från Norge!
Norska kraftCERT har publicerat sin hotanalys för 2026, "Trusselvurdering". Den finns på både norska och engelska. Mycket föredömligt att de publicerar detta material öppet!
De trycker på att cyberkriminalitet fortfarande är det mest aktiva och sannolika hotet. De pekar samtidigt på att statliga hot från främst Ryssland och Kina resulterar i ständiga angrepp med fokus på spionage. Samtidigt pekas fysiska sabotage ut som möjliga.
OT får förstås mycket uppmärksamhet och man bedömer det som sannolikt att attacker kommer störa produktionen i verksamheter. Samtidigt bedömer man risken för förstörande attacker som låg, men fortfarande 15-20%!
Ett intressant grepp är att de har satt sannolikheter i procent på de flesta bedömningar som görs. Användbart för de som tycker sannolikheter är relevanta!
Hotet från AI!
Jag får ibland frågan hur jag ser på hoten från AI mot OT. På senare tid handlar det förstås mycket om samma paranoia som drabbat IT-världen genom Mythos och andra språkmodeller som lyckats förflytta nuläget kring tekniska sårbarheter i produkter.
Personligen ser jag nog inte nya sårbarheter i våra utrustningar som det mest oroande med utvecklingen på AI-sidan. Visst kommer många OT-miljöer påverkas av att ännu fler sårbarheter i VPN-produkter upptäcks och av att angreppen mot IT ökar. Men för de allra flesta OT-verksamheter lever man redan i en vardag där det finns mängder av tekniska sårbarheter i OT-prylarna, där blir inte skillnaden speciellt stor när vi får AI-hjälp att hitta fler sårbarheter.
Med det sagt är det ändå både imponerande och oroande att de senaste modellerna räcker långnäsa åt våra mänskliga bedömningar av sårbarheter. I en text från Anthropic testar man hur bra de ledande modellerna är på att utnyttja redan kända sårbarheter, alltså att skapa "exploits". I ett av testerna skapade man exploits för sårbarheter i Windows kernel som publicerats under 2026. 14 av sårbarheterna hade Microsoft klassat som "Exploitation Less Likely" eller "Exploitation Unlikely" men Mythos Preview skapade ändå PoC:ar för 13 av dem... Den viktigaste lärdomen för mig är alltså att kända sårbarheter som är exponerade behöver patchas oavsett hur de bedömts, de kommer så gott som alltid att kunna utnyttjas. För OT betyder det INTE att vi ska patcha mer och oftare - det kan vi sällan. Det betyder att vi måste arbeta ännu mer med härdning, både av system och hela anläggningar. Mitt gamla favoritbegrepp "Defensible architecture" kommer bli ännu mer avgörande för att klara det.
En relaterad poäng kring patchade sårbarheter kommer från NSAs tidigare hackingchef Rob Joyce. Han påpekar att en patchad sårbarhet väldigt ofta indikerar att det finns sårbarheter i samma kod. (De stora VPN-tillverkarna har verkligen visat att det här är sant de senaste åren.) Han uttryckte detta nyligen i ett inlägg på LinkedIn:
The existence of a vuln should never be assumed to be “unlikely to be exploited.” Its existence means there are mistakes in the code. Where there is one bug, there are more. When I’ve seen a dangerous exploit patched out of a system, you’re almost always able to pivot to another error in the same code and recover… Look at the recurring patches from several major internet device vendors.
Det som gör mig ännu mer orolig är däremot att vi nu ser exempel på hur AI-teknik sänker tröskeln för att ge sig på OT-system genom att förstå redan existerande svagheter i designen och genom att analysera anläggningens dokumentation automatiskt. Då är inte steget heller så långt från att identifiera "bästa" sättet att skapa riktigt otrevliga konsekvenser genom OT-angrepp. Det är ju ofta detta som målas upp som ett hinder för katastrofala konsekvenser – att "vanliga hackers" inte förstår den fysiska process som de ger sig på och därför inte kan manipulera den för att skapa de absolut värsta skadorna.
I ett exempel har man sett framsteg i direkt attackförmåga i flera komplexa steg. En intressant artikel från AISI, AI Security Institute, visar på detta. Bilden nedan är från en tidigare analys som finns att läsa på arXiv: Measuring AI Agents' Progress on Multi-Step Cyber Attack Scenarios. Det var en utmaning i en cyber-range där kylsystemet i ett kraftverk skulle saboteras. Ingen av modellerna som de testat tidigare har klarat alla steg men nu gör de det. Det som är extra intressant är att de hittar egna sätt att ta sig fram som konstruktörerna av utmaningarna inte hade tänkt på själva. Men! Det är fortfarande testmiljöer som saknar aktivt försvar så det finns många steg kvar att ta innan man tar sig runt en professionell SOC och andra skydd!
Det här forskas det förstås en hel del kring. Här är några andra texter och artiklar om du vill dyka mer i området som handlar både om attacker och skydd mot attacker:
Mer från Mattias!
Mattias Pilroth har uppdaterat sin sajt med ytterligare två otroligt tänkvärda texter som beskriver ett ramverk för att styra investeringar och säkerhetsarbete baserat på konsekvenser. Du får:
Sequenced OT Resilience: A Framework for Consequence-Derived Investment - En text som beskriver metodiken
SOR Framework: Practitioner Reference and Illustrative Assessment - Som beskriver resultatet av metodiken i praktiken
Det här är två massiva dokument som kräver fullt fokus när man läser dem. Inte för att de är svåra att läsa, utan för att de är så överfyllda med insikter och klokskap att varenda ord räknas. Ramverket tycker jag personligen är en närmast självklar fortsättning av Zon-tänket i IEC 62443 och borde kunna bli en så kallad Technical Report i standardserien!
Just av det skälet ska jag inte ge mig på något slags populärbeskrivning av innehållet. Det här är rätt dokument att läsa om du är intresserad av att bedriva ett OT-säkerhetsarbete som bygger vidare på Zones&Conduits-tänket och där du kan dra nytta av att OT är annorlunda mot IT genom att våga lita på dina skyddslager. Du får stöd i att kunna arbeta seriöst i den stökiga men verkliga världen där vi är begränsade i vilka resurser vi har och vad vi kan göra.
Är du dessutom intresserad av NIS2 tycker jag du ska läsa Mattias artikel på LinkedIn om hur hans kloka tankar från "The coverage trap" påverkar hur många kommer försöka uppfylla kraven i NIS2.
Apropå mina reflektioner kring AI ovan så kom Mattias precis med ett inlägg på samma tema. Underbart citat: "The patch race in OT was lost before AI entered it. AI just turns the scoreboard on."
Ni ska klara er själva!
I samordnade utspel från cybersäkerhetsmyndigheterna i Kanada, U.K., Australien och USA trycker man nu hårt på att kritisk infrastruktur måste:
Klara av att isolera sina nätverk i 3 månader
Testa responsplaner för att säkerställa att verksamheten fungerar även under långvariga kriser i samhället
Säkerställa att man kan bygga om sina system från grunden vid allvarliga angrepp
Det här är något som svenska verksamheter verkligen behöver ta till sig! Exakt vad det betyder beror förstås mycket på vilken typ av verksamhet man bedriver. Men det är en extremt relevant tanke för alla verksamheter som träffas av NIS2 och Cybersäkerhetslagen. Rent tekniskt är förstås den ständigt ökande användningen av "Cloud" i både produktion och säkerhetsarbete en utmaning i sig. Men viktigare är förstås att inte falla för frestelsen att blanda IT och OT när man bygger infrastruktur eller säkerhetslösningar.
De uppenbara utmaningarna är just uppenbara, men den kanske svåraste balansen är att kombinera detta med att fortfarande bedriva en hållbar verksamhet när det inte är kris. Man kommer exempelvis alltid vara beroende av kritiska leverantörer, det kan man inte isolera sig från. På samma sätt kan man inte välja att göra allting själv. Att exempelvis ha råd med egna resurser för att klara att samtidigt sköta underhåll, bedriva säkerhetsövervakning, utföra incidenthantering och återbygga förstörda system kan inte ens de största organisationerna klara.
För en snabb överblick tycker jag materialet från Kanada var tydligast och enklast att ta till sig.
Skydda din integritet!
En text av den alltid lika kloke Andrew Ginter kopplade ihop två saker som jag var medveten om, men som jag inte tänkt på tillsammans tidigare. När man kombinerade dem uppstod en del nya intressanta tankar!
Den ena saken är att systemintegritet oftast är en prioritet i OT-världen. Alltså att ett system inte kan störas eller påverkas utifrån. Från världen kring informationssäkerhet är vi vana vid CIA-triaden, där man balanserar Konfidentialitet, Integritet och Tillgänglighet. Man får ibland höra att Tillgänglighet är den viktigaste aspekten i OT men det håller jag verkligen inte med om. Integritet är viktigast, utan Integritet är det omöjligt att ha Tillgänglighet.
Den andra är Bibas klassiska säkerhetsmodell från mitten av 70-talet, för hur man skyddar integritet i generella datorsystem. Man brukar lära sig den tillsammans med motsvarigheten från Bell-LaPadula, vars modell skyddar Konfidentialitet. Om du har tagit en CISSP-certifiering så har du garanterat stött på dessa modeller...
Att resonera utifrån Bibas modell sätter nytt ljus på en del gamla sanningar inom OT. De två mest kända delarna i modellen säger dels att system med hög integritet ska vara försiktiga med att läsa information från system med lägre integritet och dels att system med låg integritet inte ska få skriva till system med högre integritet. Det är nästan alltid en dålig idé att en PLC okritiskt läser indata direkt från en publik tjänst på Internet. På samma sätt är det inte en bra idé att en kontors-PC får ladda upp projektfiler till ingenjörsstationen.
När man diskuterar zoner enligt "Zones and Conduits" från IEC 62443, är det ett klokt sätt att tänka att se zongränser som integritetsgränser. Det handlar inte bara om nätverksåtkomst utan om påverkansrätt!
Fjärråtkomst är alltid utmanande i OT-världen. Med Biba-ögon beror det på att vi kortsluter en massa gränser för integritetsskydd genom att möjliggöra direkt åtkomst. Om vi ändå vill göra det får vi arbeta med kompenserande åtgärder, exempelvis fjärråtkomst endast via kontrollerad jump host, sessionsinspelning, tidsbegränsad åtkomst, MFA, godkännande av lokal personal, separata konton, ingen direktåtkomst till PLC-nät, filsluss med malwarekontroll och möjlighet att snabbt stänga fjärråtkomst.
Det finns många resonemang där Biba kan vara till hjälp. I en värld där man blandar OT och IoT kan Biba vara ett stöd för att avgöra vilka sensorer vi vågar lita på. I en OT-SOC kan man modellera hot utifrån Bibas tankar och prioritera övervakning mot hotande information som rör sig från lägre integritet mot högre.
Det här och ett antal andra "missuppfattningar" inom OT-säkerhet pratar Andrew också om i ett webbinar nyligen:
Läget i Europa?
EUs myndighet för cybersäkerhet, ENISA, släppte nyligen sin återkommande rapport "ENISA NIS360". Det här är den tredje i ordningen. Det är en statusrapport kring hur EUs arbete kring NIS2 ligger till med fokus på "Väsentliga" verksamheter, alltså den högre viktighetsgraden i direktivet.
Deras egen sammanfattning pekar på en generell positiv utveckling även om takten är ojämn mellan olika sektorer och mellan olika storlekar på organisationer. Man har också justerat hur kritiska man bedömer några av sektorerna.
Resultatet är ungefär vad jag skulle ha gissat på och är dessutom förstås ganska likt föregående rapport. 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 lite för stort gap 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...
Mycket glädjande så talar man ur skägget 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 i bland 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 oss 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.
Nya klokskaper från Sinclair
Som alltid finns en ny skörd makalösa artiklar av Sinclair Koelemij. Mina favoriter den här gången är:
Operational Integrity Under Compromise - Ett fiktivt exempel beskrivs, där förtroendet för automationssystemet har rubbats, tar oss till det verkliga exemplet från Buncefield i UK där 43 människor skadades i en explosion i en oljedepå. Sinclair tar oss sedan med till avsnittet "Three Layers of Operational Resilience". De tre lagren är "System-centric protection", "Control authority and operational integrity" och "Physical consequence resilience".
The Hidden Layer Between Cybersecurity and Physical Consequence - Här tar Sinclair oss djupare in i lager 2 från ovanstående text.
When does a security problem become a process safety problem? - Ganska självförklarande titel!
After the Firewall Fails: Designing Process Automation for Cyber-Physical Resilience - Ett ännu djupare dyk kring lager 2 enligt ovan.
Incident Response in Process Automation: Do Not Become Part of the Incident - Talande citat från texten: "a cyber attack may start the incident, but a poorly executed response may finish it". Väldigt tydlig beskrivning av varför en typisk IT-SOC inte ska få fria händer att hantera incidenter på det sätt som de är vana. Incidenthantering i OT-världen kräver förståelse för de annorlunda förutsättningar som gäller inom OT generellt och i synnerhet för den enskilda anläggningen!
Cyber incident strategy in the process industry - Mer på temat incidenthantering!
Behöver du inspiration?
Du kanske redan vet att jag gillar CIE, Cyber Informed Engineering. Slarvigt förklarat är det ett strukturerat sätt att bygga bort de värsta konsekvenserna i OT-världen genom att INTE använda "cyberåtgärder". Istället gör man smarta ingenjörsmässiga designval i produktionsutrustningen så att de värsta konsekvenserna inte KAN uppstå. CIE kan tyvärr vara stort och utmanande att genomföra fullt ut men jag gillar tanken på att risker som vi orsakar genom att använda digital teknik inte alltid behöver åtgärdas med digitala åtgärder.
När jag läste om "CIE Engineered Controls" från Idaho National Labs tänkte jag först att det var ett våldsamt överdrivet initiativ. Det är Benjamin Lampe som ligger bakom en databas med (just nu) 62 473 förslag till CIE-åtgärder. Extremt fånigt att sammanställa en stor lista med förslag - även om alla förslagen är bra så blir det oanvändbart i praktiken.
Men jag hade fel. När jag provade verktyget insåg jag att det var mycket mer klokskap inbyggt. Framför allt är det uppdelat per verksamhetstyper och vilken typ av aktivitet som man vill skydda. Helt plötsligt blev det väldigt smidigt! I exemplet nedan bad jag om fel-säkra sätt att förebygga skador i vattenbehandlingen i en dricksvattenanläggning. Svaret blev 11 starka sätt att få robusthet genom att utforma utrustningen på ett smart sätt fysiskt! Väldigt användbart!
Även om man inte använder CIE fullt ut så tror jag det här verktyget kan användas som inspiration och för att väcka nya tankesätt oavsett vilken typ av verksamhet man verkar i. Prova! Det är gratis! Det är superenkelt att använda! Det väcker nya tankar direkt!
Om din verksamhet berörs av NIS2 och Cybersäkerhetslagen tycker jag det här sättet att arbeta är extremt mycket i linje med de krav på riskdriven proportionalitet i säkerhetsåtgärder. Ta bort alla farliga konsekvenser först så återstår bara de som stör verksamheten. Blir betydligt billigare och ger bättre nattsömn...
Så osannolikt att det egentligen inte hänt...
Det där med sannolikhet i riskbedömningar är alltid en het potatis som det finns många åsikter om. I en artikel beskriver Naveen Menon ett av de alternativ som finns, nämligen att ersätta sannolikhet med hur utmanande en händelse är att få till. Svårigheten beskrivs som en kombination av hur exponerad den aktuella sårbarheten är för en angripare och hur svår den är att utnyttja.
Ingen modell är perfekt, men den här är enkel och resonemanget passar bra i en OT-miljö som ofta bygger mycket av sitt skydd på segmentering.
På samma tema kan den här texten av Tony Martin-Vegue om ordet "Probably" vara intressant. Det här med att bedöma och beskriva sannolikheter är verkligen ingen ny utmaning...
Nytt kring lagar och föreskrifter
Från första juli gäller en ny version av föreskriften för rapportering av cyberincidenter och cyberhot kopplad till Cybersäkerhetslagen och NIS2: MCFFS 2026:8, Föreskrifter om incidentrapportering och informationsskyldighet för väsentliga och viktiga verksamhetsutövare. (Man ersätter alltså en föreskrift som inte ens börjat gälla ännu.) Ändringen som gjorts är liten och egentligen mest av språklig karaktär, ingenting avgörande har ändrats. Jag vill passa på att lyfta den här föreskriften av ett annat skäl och ge en väldigt stark rekommendation om att tolka den i förväg istället för att vänta tills det "smäller". För vissa typer av organisationer kan det bli ganska många olika frågor att ta ställning till för att avgöra om en händelse ska rapporteras eller inte. Det är inte något som man vill syssla med när man står mitt i en incident – 24 timmar är inte lång tid i dessa sammanhang! En organisation som jag förberedde en sådan tolkning åt, i form av en checklista med 11 beslutspunkter (!), hade väldigt stor nytta av den när de nyligen drabbades av en driftstörning som behövde rapporteras.
Apropå incidentrapportering så har samarbetsgruppen kring NIS2 enats om en mall för vilken information som ska samlas in vid incidenter. Att det här likriktas mellan länderna i EU är bra i sig och kan det dessutom göra rutinerna för själva anmälan tydligare och enklare så har vi mycket att vinna i Sverige. Ni som också varit med och gjort incidentanmälan i det gamla svenska systemet håller nog med...
Samma samarbetsgrupp kom precis med dokumentet "Reference document on security measures for entities under NIS2" som är precis vad det låter som. Till dokumentet finns också en mappningstabell för den som vill hoppa från direktivets artiklar 20 och 21 till ISO 27001, IEC 62443-2-1, IEC 62443-2-4, IEC 62443-3-3, NIST CSF 2.0, CyFun och en rad nationella kravmassor
I september i år börjar rapporteringskravet i CRA gälla för allvarliga incidenter och aktivt utnyttjade sårbarheter för tillverkare av digitala produkter. I slutet av nästa år gäller kraven på CE-märkning fullt ut. Om du och din organisation fortfarande inte riktigt fått grepp på hur ni ska tackla CRA så är en ny text av Sarah Fluchs förmodligen till hjälp.
ENISA har publicerat resultatet av en undersökning kring läget för SBOM, Software Bill of Materials, i samband med CRA.
Den svenska implementationen av CER-direktivet har nu skickats på lagrådsremiss: "Lag om motståndskraft hos kritiska verksamhetsutövare". Det här är inget som direkt påverkar OT-världen på samma sätt som NIS2 men kan bli ett oväntat stöd till NIS2-arbetet i och med att man blir mer tvingad att fokusera på verksamheten och dess risker snarare än att slentrianmässigt försvara verksamhetens system. Det är lite synd att vi inte fick CER först!
Belgiens officiella ramverk för cybersäkerhet, CyFun, "CyberFundamentals Framework" kom relativt nyss i en uppdaterad version. Nu finns även mappningstabeller som hjälper dig koppla ramverket mot andra kravmassor, inklusive NIS2, ISO 27001, ISO 27002, IEC 62443-2-1 och IEC 62443-3-3. CyFun är ett starkt och lite annorlunda grepp som är nära besläktat med NIST CSF. Jag gillar CyFun, inte minst för att det anpassar sig efter den egna riskprofilen och organisationens storlek. Trots det blir det snabbt ett väldigt stort att ta sig an, även för små organisationer.
Lita inte på någon i OT-världen!
Amerikanska CISA har släppt ett dokument med titeln "Adapting Zero Trust Principles to Operational Technology". På 28 sidor beskriver de hur man kan ta detta väletablerade grepp från IT-världen och använda det inom OT. Det här är en klurig utmaning eftersom det vänder upp och ner på ett antal grundläggande antaganden för OT-folket. Inte minst är det ibland viktigare att system fortsätter fungera även om cybersäkerheten har störts. Ett klassiskt exempel är att IPS:er och brandväggar anpassade för OT inte blockerar trafiken om de själva går sönder.
Dokumentet ger rekommendationer i var och en av kategorierna från NIST CSF: Govern, Identify, Protect, Detect, Respond och Recover. Ett bra val som gör dokumentet väldigt enkelt att läsa även om de gott kunde ha tryckt mer på hur de olika delarna är beroende av varandra för att ge bästa resultat.
Govern: Samverkan och personal med kompetens inom flera områden är tycker jag är det viktigaste rådet i den här kategorin. Utmaningarna med att implementera cybersäkerhet i OT-miljöer handlar om avvägningar mellan olika typer av risker där en säkerhetsåtgärd på ett område kan skapa andra typer av risker som faller under någon annans ansvar. Ett annat område som kräver mer fokus är inköp och leverantörshantering.
Identify: Asset-hantering dyker förstås upp här. Ett viktigt område även om det numera ifrågasätts allt mer. Ändringshantering pekas ut som viktigt, vilket jag verkligen håller med om. Dålig hantering av ändringar skapar en stor del av det problem som asset-hantering försöker lösa... Riskhantering, inklusive hotmodellering och fysiska konsekvenser, är också ett viktigt område.
Protect: Segmentering pekas ut som en väletablerad åtgärd i OT-världen som behöver bli mer "aktiv" för att dra maximal nytta av den. De använder inte det begreppet, men jag läser det som väldigt likt tankarna kring "Defensible architecture" från SANS, alltså att man inte bara ser segmentering som en uppdelning av nätverk utan även som en möjlighet att förbättra andra säkerhetsåtgärder, exempelvis nätverksövervakning. De speciella behoven kring identitetshantering pekas sedan ut på ett riktigt bra sätt. Remote access får förstås mycket uppmärksamhet eftersom det tenderar att "störa" många andra säkerhetsåtgärder. Säker kommunikation och patch-hantering har också egna rubriker med bra innehåll.
Detect: Ständig övervakning är egentligen det enda ämnet här. Inga nyheter egentligen. Övervakning är hur vi får maximal nytta av det vi gjort inom "Protect" och hur vi gör "Respond" meningsfullt. Det är också vad som gör att vi kan fokusera på rätt saker i "Recover".
Respond: Fokuserar förstås på incidentplanering och hur man planerar att begränsa skadorna vid ett intrång. Ett underskattat område som kan lära mycket från IT-världen men som kräver att man verkligen förstår OT-världens speciella förutsättningar.
Recover: Backup och återställning pekar på skillnaderna i varför man gör backup jämfört med inom IT. Mindre fokus på information i systemen och mycket mer på att kunna återskapa konfiguration, licenser, inställningar och kalibreringar. En del som man kunde tryckt på mer är att från början utforma system för att de ska fortsätta fungera på ett rimligt sätt även om vissa delar slutat fungera.
Våga vara osäker!
Jag skrev nyligen ett inlägg på LinkedIn om att vi sällan har all information som vi egentligen behöver. Det dök upp en del intressanta diskussioner efteråt som jag tycker är värda att lyfta.
Bejaka osäkerheten!
I säkerhetsbranschen gör vi ofta en poäng av att ordet ”Säkerhet” har två helt olika betydelser. När man använder motsvarande ord på engelska, ”Security” och ”Safety”, blir skillnaderna uppenbara, men också de starka beroenden som finns mellan dem.
På senare tid har jag slagits av att det finns två betydelser av ”Osäkerhet” som också är värda att tänka på. De betydelser som jag tänker på motsvarar ”Insecurity” och ”Uncertainty”.
”Insecurity” är de där riskerna som vi försöker hantera i säkerhetsarbetet. När något inte är tillräckligt säkert för vår smak och riskaptit.
”Uncertainty” är någonting helt annat, det är den jobbiga insikten om att vi aldrig har hela sanningen, att vi inte ser hela bilden och att vi alltid tar våra beslut baserat på bedömningar snarare än fakta. Det gäller hoten. Det gäller vårt skydd. Det gäller vår verksamhet.
Det gäller speciellt i våra riskanalyser. Det är här de svarta svanarna gömmer sig. De där riskerna som vi inte ens vet om att vi inte vet om. Händelser och svagheter som vi inte kunnat föreställa oss. Alla de där otroligt osannolika händelserna som blir sannolika som grupp eftersom de är så sanslöst många.
Det är viktigt att vi kommer ihåg det här! Vi måste arbeta med säkerhet på ett sätt som gör oss mindre sårbara även för risker som vi inte kan föreställa oss. Det här gäller speciellt risker som är väldigt osannolika men som orsakar extrema konsekvenser. I mitt arbete med OT-säkerhet är det här speciellt vanligt eftersom vi talar om risker i fysiska processer. De mest extrema konsekvenserna i fysiska processer blir, av naturliga skäl, händelser som skadar människor, miljö och samhälle.
Men även utanför OT-världen är det viktigt att vi säkerhetsmänniskor är öppna med vår osäkerhet. I en bransch där man ofta hör om utmaningarna med att få resurser lockas man förstås att vara tvärsäker i sin argumentation. Det är inte en svaghet att ”erkänna” att vi inte vet allt. Det är snarare ett argument för att arbeta med säkerhet på ett sätt som bygger bort extrema konsekvenser oavsett vad som orsakar dem.
Vi behöver ett säkerhetsarbete med fokus på robusthet och resiliens snarare än att jaga enstaka sårbarheter. Ett sådant säkerhetsarbete kan inte ske utan verksamheten. Det går inte att bedriva på IT-avdelningen. En CISO kan inte göra det här själv. OT-säkerhetsingenjören måste jobba tillsammans med produktionen.
För att skapa säkerhet behöver vi våga vara osäkra!
Efter att texten publicerades påminde någon om att mitt resonemang gäller på fler ställen än i exemplet riskanalys, som jag använde. Det är verkligen sant. FMEA är en sådan metod som är helt beroende av att vi kan föreställa oss vad som kan gå snett. HAZOP kan vara en metod som faktiskt försöker hjälpa oss hitta problem som är svåra att hitta genom att ställa ledande frågor kring vad som händer om "För lite", "Fel riktning", "Inget flöde" och så vidare inträffar.
En annan tanke är att vi måste skilja på kunskapsbrist och handlingsbrist. Speciellt gäller det kring organisationer som kanske har rätt kunskaper och insikter men som av andra skäl inte lyckas agera på det man redan vet.
Ett klokt inspel är att inte fokusera på svarta svanar innan man gjort det mest grundläggande i säkerhetsarbetet. Vissa saker är alltid viktiga, exempelvis: ändringshantering, säker fjärrsupport, testade backuper och att någon faktiskt tittar på larm och loggar. Citat: "Fokuset på det okända får inte göra oss blinda för det pinsamt kända."
En annan kommentar gällde det underskattade verktyget "Pre-mortem". Alltså att man låtsas att något har gått riktigt illa och funderar över: Vad kan ha hänt? I samband med det dök en av mina favorit-gurus, Roger L. Martin, upp i skallen med sin favoritfråga: "What would have to be true?". Det borde även funka med "What would have to be false?"...
Ytterligare en bra kommentar var att "Defense in depth", Djupförsvar, kan vara ett av sätten att hantera att okända saker dyker upp. Jag blev påmind om uttrycket "Defense in depth är ödmjukhet översatt till arkitektur."
Tack för alla kloka inspel! Det här är ett område som jag tycker är viktigt och intressant. Det är dessutom en av de roligare delarna i mina uppdrag som rådgivare, att ställa utmanande frågor som kan sätta fingret på uppdragsgivarens blinda fläckar. Den där klassiska insikten om att man ska lära av sina misstag blir ännu starkare när man via en konsult också kan lära sig av andras misstag. Jag har sett en del intressanta dikeskörningar genom åren...
Ett skepp kommer lastat! Men obemannat...
OT-säkerhet ombord på fartyg är en rolig värld med mycket spännande utmaningar. Det är också ett område där cybersäkerhetsarbetet är aktivt och åtminstone ligger långt framme i tydlighet. (Även om den miniminivå som man måste uppfylla är märkligt låg. Här är vi på gott och ont i händerna på klassningssällskapen.)
Nu blir det ännu mer spännande... FNs sjöfartsmyndighet IMO, International Maritime Organization, har just antagit Safety-krav för autonoma fartyg i internationell handelstrafik.
Incidenthantering i industrin?
NIST har släppt en draft av ett spännande dokument: "Responding to and Recovering from a Cyber Attack: Cybersecurity for the Manufacturing Sector". NIST har tillsammans med MITRE och ett gäng produktleverantörer (Dragos, Garland, Inductive Automation, Siemens, Rockwell etc) genomfört ett projekt där man tittat på ett antal scenarier kring incidenthantering inom tillverkande industri. De har inte bara gjort scenarierna utan även byggt lämpliga lösningar med de inblandade leverantörernas produkter.
Här kan du hitta ny inspiration för att lösa dina egna utmaningar!
Brorsan till Stuxnet!
Stuxnet får väl anses vara startskottet för den bransch som vi idag kallar OT-säkerhet. Du har förmodligen redan läst en massa artiklar och kanske böcker om detta. Om inte så är "Countdown to Zero Day", skriven av Kim Zetter, faktiskt obligatorisk läsning!
Det är en fascinerande historia som femton år senare fortfarande är en av de mest imponerande angreppen som någonsin genomförts mot någon form av OT-system. (I alla fall som har blivit offentligt...)
Samma Kim Zetter har nu skrivit en artikel om en samtida skadlig kod, "Fast16", som precis som Stuxnet visade sig vara riktad mot Irans kärnvapenprogram. Fast16 är inte alls relaterad till OT-säkerhet men ändå tänkvärd för oss i OT-världen. Vad händer om våra utrustningar och system manipuleras att räkna fel på jobbiga sätt men i övrigt fungerar precis som vanligt?
Även Wired har skrivit om detta och publicerat en video med Andy Greenberg. En annan vällfylld text att läsa kommer från Vitaly Kamluk och Juan Andrés Guerrero-Saade på SentinelLABS.
Attacker mot solenergi i Europa
Den alltid produktive Ruben Santamarta har publicerat 55 sidor intressanta tankar kring attacker mot europeisk solenergi i praktiken: "A Practical Analysis of Cyber-Physical Attacks Against Solar Photovoltaic Generation in Europe".
Är du det minsta intresserad av attacker mot elnätet är detta spännande läsning.
Det hade jag helt missat...
Jag snubblade nyligen över den brittiska organisationen RITICS, "Research Institute in Trustworthy Inter-Connected Cyber-Physical Systems" och framför allt deras "Industrial Control Systems Community of Interest".
När man rotar runt bland deras "Downloads & Guidance" hittar man en massa nedskriven kunskap som är väl värd att ta till sig!
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.