top of page
Sök

Nyhetsbrev OT-Säkerhet #77

  • för 41 minuter sedan
  • 27 min läsning

Dags för ett nytt nyhetsbrev kring OT-säkerhet! Den här gången stoppar vi ett kärnkraftverk, manipulerar grekiska elmätare, funderar kring begreppet försvarbarhet, tittar på säkerhetsfunktioner som läcker information via DNS, övar i dricksvattenbranschen, ser fram emot 11:e september, tittar på kopplingar mellan CER-lagen och CSL, springer på OT-löpbandet, tittar på virtualiserade PLC:er, funderar på hur nyckeln fungerar på en PLC, läser HMS årliga analys av OT-protokoll, läser nya böcker och väldigt mycket annat.


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!


Mats Karlsson Landré klädd i varseljacka med "ot-säkerhet.se" skrivet på bröstet.

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å X/Twitter, på W Social 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!

Hur man stoppar ett kärnkraftverk

Med tanke på min bakgrund i kärnkraftsvärlden blev jag lite extra nyfiken när jag såg Ruben Santamartas analys av en OT-händelse på kärnkraftverket Plant Hatch, en kokarvattenanläggning i sydöstra USA.


En av de två reaktorerna snabbstoppades på grund av störningar i systemen kring turbinen. I grundorsaksanalysen visade det sig vara orsakat av en utbytt nätverksswitch som konfigurerats fel vilket ledde till nätverksstormar.

Stora pengar i Grekland!

Ruben Santamarta har också skrivit en artikel om bedrägerier där man manipulerade elmätare i Grekland under flera års tid. En av DSO:erna som drabbades uppskattar skadorna för dem själva till nio miljoner Euro. Man har helt enkelt ändrat i inställningarna hos mätarna och på så sätt skalat om mängden energi som uppmäts. Man har både kunnat minska den uppmätta förbrukningen och ökat energin som levereras från solenergianläggningar. Tre personer har arresterats.

Ännu större pengar i OT-världen!

Accenture har spenderbyxorna på sig och köpte nyligen största delen av OT-säkerhetsföretaget Dragos och samtidigt hela ägandet i företagen runZero och NetRise. RunZero gör en finfin produkt för att inventera nätverk och NetRise sysslar bland annat med analys av firmware. Några veckor innan detta hade dessutom Dragos köpt företaget Phosphorous som sysslar med asset-upptäckt och härdning. För ett par år sedan köpte Dragos också bolaget Network Perception som gör visualiseringsprodukter för OT-nätverk.


Totalt värde på affären uppges vara drygt fyra miljarder dollar! Det betyder att Dragos nu är värt fyra gånger mer än Nozomi Networks eller Claroty!


Dale Peterson har gjort en bra analys av vad detta betyder för företagen, produkterna, Accenture och OT-marknaden i tre artiklar:


Den alltid skarpsinnige Mattias Pilroth gjorde en radda intressanta reflektioner kring vad detta betyder och kanske framför allt vad det inte betyder. Han avslutar sin text med dessa insiktsfulla ord:

The transaction lowers the price of detection, which was already the part of the work that scaled. It does not lower the price of the consequence model that turns a detection into a decision, because that model is local to the plant and cannot be bought as a transferable asset. And it does nothing for the property that model depends on: that the protections it counts are still independent in the live system. Detection became cheaper this quarter. Consequence, and the independence it rests on, did not. The most thorough analysis of the deal ends where the unsolved work begins.

Apropos Dragos kan jag rekommendera en fantastiskt bra Nasdaq-intervju med Dragos grundare och VD, Rob Lee. Som vanligt säger Rob en massa kloka saker men lyssna speciellt när har pratar om glappet mellan ledningens tabletop-övningar och verkligheten. Hans poänger om att kunna göra en riktig grundorsaksanalys är också riktigt bra. Han bryter sedan även ner utmaningarna kring AI i tre klockrena delar. Hans avslutande ord om vilka tre frågor som alla styrelser och ledningsgrupper borde ställa är identiska med mina egna käpphästar:

  1. Handlar vår cybersäkerhetsstatus om "Enterprise" eller "Enterprise-IT"?

  2. Vad gör vi specifikt för att skydda OT? Det räcker inte med en anpassad version av IT-säkerhetsarbetet!

  3. Har vi informationen vi behöver vid en incident om vad som händer i OT-systemen?

Försvarbar eller Defensible?

När jag såg titeln på FOIs intervjustudie "Försvarbarhet i cyberdomänen" gick mina tankar direkt till ett av mina favoritbegrepp, "Defensible architecture". Begreppet kommer från SANS metodik "The Five ICS Cybersecurity Critical Controls" som tar den lite oortodoxa vägen att först fokusera på incidenthanteringsbehov för att utforma en arkitektur som går att försvara och få bra uppsyn över.


Studien är skriven av Martin Karresand, William de Brun Mangs, Ralf Alvarsson och Frankie Johansson med ett annat fokus än det SANS har. Trots det kan man se en hel del likheter i tänk och slutsatser. SANS-dokumentet listar fem initiala steg för att skapa en verklighetsanpassade förmågor i OT-miljöer:


  1. OT-specifik incidenthantering – Ganska tydlig koppling till FOIs resonemang

  2. Defensible control system network architecture – Samma principiella tänk

  3. OT-nätverkssynlighet och övervakning – Väldigt likt

  4. Säker fjärråtkomst – Ingen tydlig koppling

  5. Riskbaserad sårbarhetshantering – Ingen tydlig koppling


FOI-dokumentet är skrivet med ett mycket bredare fokus, en annan inriktning och med ett mer generellt tänk. Men trots det – eller kanske precis därför, blir det en utmärkt inspiration även för OT-folket som arbetar enligt SANS metodik.

Vad händer när säkerhetsfunktionen läcker?

Vännerna på SensorFu producerar den utmärkta och ofta underskattade produkten "Beacon". som är ett effektivt sätt att leta efter "läckor" från nätverk eller system som ska vara hårt begränsade i vad de kan kommunicera med – exempelvis OT-system. I en intressant artikel hintar de om ett lite oväntat problem med en IDS-funktion.


Bra nätverkssegmentering är utmanande att få till. Dels ska rätt trafik identifieras och släppas fram, samtidigt som allt annat ska blockeras. En tjänst som nästan alltid skapar utmaningar är namnuppslagningsprotokollet DNS. I exemplet beskriver SensorFu ett väl avskiljt nätverk där säkerhetsfunktionerna i form av en IDS blev den stora läckan när den slog upp ett DNS-namn som den fångat upp som en del av en TLS-uppkoppling. Intressant och värt att tänka på!

Vad fungerar utan vatten?

Vi är vana vid att Andy Greenberg producerar intressanta texter och böcker. Nu har han skrivit en spännande Wired-artikel om en tabletop-övning som han var gäst i, en övning med höga chefer från försäkringsbranschen som deltagare. I övningen slås 5000 dricksvattenanläggningar ut samtidigt över hela USA. Det får "intressanta" konsekvenser i samhället...


Det finns mycket att fundera över och ta till sig i texten. Att övningar verkligen är nyttiga och inte behöver innehålla någon teknik alls. Att vi inte ska underskatta risken för att många separata anläggningar slås ut samtidigt – även i Sverige är det väldigt vanligt att olika sektorer har sina "favoritleverantörer" och "favoritsystem". Att det inte handlar om att förhindra att jobbiga saker händer utan att ha förberett kloka prioriteringar som minimerar de värsta konsekvenserna.

Jobba smartare med CIE

Gillar du också CIE, Cyber-Informed Engineering? Jag snubblade över ett intressant dokument från Idaho National Laboratory (INL). Det är inte ett helt nytt dokument, det gavs ut hösten 2025, men jag har missat det.


De tittar på ett antal etablerade metoder för riskanalys genom CIE-glasögon, exempelvis HAZOP, PRA, FMEA, STPA, HAZCADS och LOPA. För var och en av metoderna finns ett resonemang och förslag till hur man kan tillföra tankar från CIE i dessa metoder. Intressant!

Nytt kring lagar och föreskrifter

Om du berörs av CRA och Maskinförordningen kan en artikel av Sarah Fluchs vara värdefull: "Meeting Machinery Regulation and CRA in parallel – A step-by-step guide to product security for manufacturers" Som vanligt när Sarah skriver finns texten även på tyska om du föredrar det.


Sarah har även andra intressanta texter kring just CRA, exempelvis: "CRA reporting obligation from September 11: How reporting will work" och "From CRA Compliance Anxiety to Confident Decisions".


Sagar Singam sätter fingret på något som många missar kring CRA, nämligen att det är en väldigt viktig deadline redan nu i höst. Den 11 september blir det obligatoriskt att rapportera sårbarheter för ALLA digitala produkter som används inom EU – även de som såldes för 20 eller 30 år sedan! Dessutom ska det gå snabbt, en första varning inom 24 timmar, full information inom 72 timmar och slutrapport inom 14 dagar! Hur många leverantörer har ens koll på vad de sålde för 20 år sedan?


Timo Lagerbjelke skrev en tankeväckande text om den enorma databas över kända sårbarheter som EU bygger upp genom rapporteringsverktyget "Single Reporting Platform. Det här en väldigt viktig funktion som samtidigt blir otroligt farlig och sanslöst intressant att utsätta för angrepp.


ENISA publicerade nyligen en undersökning om hur små och medelstora företag som borde beröras av CRA hanterar utmaningarna. Bara 66% hade hört talas om CRA. 20% säger att de är osäkra på om de berörs. 54% hade ingen eller begränsad kunskap om hur man bedömer compliance. Det finns att göra...


Sedan första juli det mesta av cybersäkerhetsverksamheten från MCF samlad med övriga delar hos NCSC, Nationellt Cybersäkerhetscenter. MCFs föreskrifter kring cybersäkerhetslagen har landat på NCSCs sebbsidor. Samtidigt lanserades också det nya verktyget "Cyberportalen" för incidentrapportering som ersätter det gamla IRON.


Än så länge är det lite rörigt. Vissa saker ligger kvar under mcf.se och vägledningar och webbsidor pekar till fel ställen för exempelvis anmälan som NIS2-organisation, men det kommer väl lösa sig över tid.


Vägledningarna för föreskrifterna kan vara lite kluriga att hitta, de syns inte överallt – men här kan du hitta alla dokument på samma ställe. Där hittar du föreskrifterna för:

  • Anmälan och identifiering

  • Incidentrapportering

  • Säkerhetsåtgärder och ledningens utbildning (mer om den längre ner.)

  • Säkerhetsrevisioner


Nu har vi alltså alla de viktigaste föreskrifterna på plats för att Cybersäkerhetslagen ska bli så tydlig som möjligt. PTS, Post och telestyrelsen, arbetar på föreskrifter för sina områden men inom deras områden finns redan det viktigaste på plats direkt från EU. De övriga tillsynsmyndigheterna, som under första NIS-direktivet skrev sina egna föreskrifter, får inte längre göra det.


Apropå föreskrifter så har Sarah Fluchs en fantastisk text som jag verkligen ställer upp på. (Den bygger till stor del på en text av Lim Thian Chin.) Sarah hävdar att vi borde ta bort alla säkerhetskrav i våra lagstiftningar. Det är inte så fånigt som det kanske kan låta! En av de stora problemen som hon vill åt är "security by checklist" som tyvärr är sorgligt vanligt och som ofelbart leder till ett enormt slöseri med resurser. Ska man vara lite elak så har jag gott om egna exempel där välmenande människor med säkerhetsansvar har efterlyst listor med obligatoriska säkerhetsåtgärder eftersom de helt enkelt inte är tillräckligt kompetenta i sitt jobb! En myndighet kommer aldrig vara bättre på att bedöma vilka riskåtgärder din organisation verkligen behöver jämfört med en expert inom organisationen. Sarah föreslår tre principer:

  1. Ta bort säkerhetskrav i lagstiftningar – Kravet ska vara att hantera risk! Då blir riskanalyserna på riktigt och ger verklig effekt.

  2. Var extremt tydlig med ansvar i lagstiftningar – Tydligt ansvar för risker och för kommunikation om hur verksamheten ligger till.

  3. Be om bevis som bra säkerhetsprojekt ändå behöver – För att kunna ha tillsyn behöver det finnas bevis. Rimligen är det samma bevis som alla projekt med säkerhetspåverkan behöver för att styra sitt eget arbete.


Regeringen har lämnat sin proposition för implementation av CER-direktivet i svensk lag. Det här är ju "Syster-lagen" till NIS2 som behandlar alla andra former av motståndskrav och robusthet utöver det som kommer ur cybersäkerhet. Väldigt lite förändringar jämfört med tidigare utkast. Ungefär samtidigt kom ett "Meddelande från Kommissionen" med titeln "Riktlinjer för tillämpning av artikel 13.5 i direktiv (EU) 2022/2557 om kritiska entiteters motståndskraft (C/2026/3712)". Det här är vägledande tillrop från Kommissionen om vad man ska tänka på om man omfattas av CER. Här blir det väldigt tydligt att det finns många beröringspunkter mellan CER och OT-säkerhet, även om CER inte ställer krav på OT. Men i och med att mycket i CER berör fysiskt skydd och fysiska konsekvenser så blir det automatiskt släktskap med OT. Det finns en del uttryckliga kopplingar också, exempelvis:

  • Punkt 23 som tycker man bör "införa manuella åsidosättningar och human-in-the-loop-bestämmelser" vid användning av OT. Om du är som jag blir sånt här väldigt otydligt när det översätts till svenska. Det engelska originalet säger mycket mer: "...should incorporate manual overrides and human-in-the-loop provisions defining the specific conditions and requirements for human intervention and manual control in response to hazards."

  • Det pratas mycket om koordination med motsvarande arbete utifrån NIS2.

  • Punkt 37 påminner om att ett bra fysiskt skydd inte ersätter kraven på cybersäkerhet i NIS2.

  • Punkt 54 pekar på åtgärder för höjd integritet hos system och mjukvara som används i utrustning.

  • Punkt 68 tycker på åtgärder för att kunna återställa vid incidenter är viktigt.

Vi har fått NIS2-föreskrifter för säkerhetsåtgärder!

Så har vi då fått den slutgiltiga versionen av föreskriften för säkerhetsåtgärder och ledningens utbildning kopplat till Cybersäkerhetlagen! Som väntat är det en betydligt "snällare" version jämfört med de tidiga utkasten och remissversionerna. Många detaljkrav har förvandlats från "SKA" till "BÖR". Vi väntar fortfarande på vägledningen till föreskriften och jag har inte sett någon planering som indikerar när vi kan vänta oss den. Formellt sett börjar kraven gälla den 1 oktober.


Jag tycker nog att den slutgiltiga versionen är klart bättre jämfört med tidigare remiss-versioner. Det finns definitivt saker jag skulle ändra på om jag var kung för en dag men det får duga som det är... Kraven på dokumentation och administration har tonats ner sedan tidigare versioner, vilket definitivt är ett steg framåt!


Något som är riktigt bra i föreskriften är att man trycker hårt på att säkerhetsåtgärder ska vara "lämpliga och proportionella". Men tyvärr finns det ingenting tydligt i föreskriften som tydliggör vad man ska vara proportionell mot. Jag tänker då speciellt på att NIS2-direktivet säger att man ska ta hänsyn till sin samhällspåverkan när man gör riskanalyser. Det kravet försvann i Cybersäkerhetslagen och har inte dykt upp i föreskriften. Det är olyckligt eftersom det står väldigt tydligt med i förarbetena till lagen och därför i praktiken är ett krav. Här finns stor risk för missförstånd och att man sedan får smisk för att man inte sköter sig!


Om jag ska vara lite bitsk så är det ändå kul att se att OT är utgångspunkten när föreskriften definierar olika typer av system. IT definieras som "Det som inte är OT". I alla fall är det så när man läser definitionerna av "it-segment" och "ot-segment" – it-segment är allting som inte är ot-segment... Tyvärr är det precis tvärt om i resten av texten:

  • Information ska ha utpekade ägare men motsvarande roll för fysisk produktion saknas.

  • Information ska klassas så man vet vad som är viktigast att skydda. Den fysiska produktionen behöver inte ha något motsvarande.

  • Riskhanteringen behöver inte bry sig om den fysiska produktionen när man identifierar risker.

  • Ordet "Informationsbehandling" används flitigt vilket är utmanande i många OT-sammanhang där cyberverksamheten i produktionen knappast ses som behandling av information. Man kan till och med läsa föreskriften som att det inte krävs några åtgärder om man outsourcar system inom fysisk produktion! (Det är förstås inte så de menar, men ändå...)


Jag tror verkligen inte att tillsynsmyndigheterna kommer hålla med om mitt elaka sätt att läsa föreskriften, så jag rekommenderar starkt att man inte försöker arbeta efter föreskriften utan istället etablerar ett riktigt systematiskt säkerhetsarbete med stöd av ISO 27001 och IEC 62443-2-1! Föreskriften är ett facit, inte något man bygger ett säkerhetsarbete på!


Det finns en tydlig rekommendation i föreskriften om att använda ISO 27001 och 27002, men det finns ingenting om lämpliga standarder för OT-säkerhetsarbete. De meningsfulla delarna i ISO 27001 (alltså kapitel 4 till 10) fungerar förstås alldeles utmärkt även i OT-världen, men många använder ju tyvärr Annex A i ISO 27001 (eller motsvarande i ISO 27002) som ett facit för säkerhetsåtgärder och då funkar det direkt dåligt i de flesta OT-sammanhang. Idealet är oftast att använda ISO 27001 för att etablera systematiskt säkerhetsarbete, kompletterat med IEC 62443-2-1 för att få med ett tydligare OT-fokus. Men för säkerhetsåtgärder på OT-sidan är det ett absolut måste i nästan alla OT-verksamheter att jobba med något som liknar IEC 62443-3-2 och IEC 62443-3-3. Där duger inte ISO 27002! I vissa sektorer är man tvungen att följa IEC 62443 av andra skäl än NIS2. Tillhör du exempelvis delsektorn Sjöfart inom Transport så lever du kanske efter klassningssällskapet DNVs regelverk som bygger på IEC 62443. Då får du mycket gratis i ditt NIS2-arbete!


I ärlighetens namn finns det faktiskt ett antal viktiga områden där det inte är någon diskriminering alls mot fysisk produktion. Det ställs exempelvis precis samma krav på kontinuitetshantering, incidenthantering, krishantering, tester, härdning, säkerhetsövervakning osv oavsett om det är IT eller OT, vilket är mycket bra!


Du vet nog att det här med säkerhetsövervakning ligger mig varmt om hjärtat. Det är dessutom speciellt viktigt i OT-världen eftersom övervakning ofta pekas ut som en kompenserande åtgärd när andra säkerhetsåtgärder inte går att få till. Här är föreskriften glasklar på behovet av att kunna utreda incidenters grundorsak – vilket förstås kräver en genomtänkt säkerhetsövervakning som inte bara fokuserar på larm. Vi behöver ha rejäla backspeglar att titta i för att kunna nå upp till de kraven! Med OT-glasögon på är det dessutom ganska tuffa krav på vad som ska övervakas. Det är dessutom ett krav att man SKA ha intrångsdetektering, vilket i de flesta OT-miljöer betyder nätverksanalys med NIDS-lösningar.


Ett område där kraven verkligen har tonats ner på ett bra sätt i den slutgiltiga versionen är kring segmentering. Men det kunde varit tydligare att segmentering inte bara är en nätverksfråga. Att bara försöka hacka upp ett nätverk på ett sätt som inte matchar uppdelningen av systemen blir ofta ett meningslöst arbete. På OT-sidan är det förstås extra viktigt, dels för att mycket av IEC 62443-3-3 bygger på segmentering och dels för att säkerhetsövervakning är helt beroende av att man utformat segmenteringen på ett sätt som passar att övervaka!


Begreppet "Sektorskritiska system" används för att peka ut de system som verksamheten är beroende av för att bedriva den där verksamheten som gör att man omfattas av NIS2. Det är ett riktigt bra sätt att undvika onödigt detaljerade regler och fungerar bra även för OT.


På det hela taget tycker jag slutresultatet blev ganska bra även om det märks att extrema kompromisser måste till för att ta hand om (nästan) alla tillsynsmyndigheters behov. Lite larvigt är det väl att man håller fast vid att skriva IT och OT med små bokstäver när till och med vår nationella cybersäkerhetsstrategi skriver OT med versaler. Ska jag förslå något till nästa revision så är det väl att ot-säkerhet.se borde listas under 3 kap 10 § "Omvärldsbevakning"? :-)

Mer från årets S4-konferens

Som väntat fortsätter inspelningarna från årets upplaga av S4-konferensen att dyka upp i spellistan på YouTube. Samtidigt har årets anmälningar börjat tas emot för de som vill stå på scen, men det gäller att vara snabb - det är populärt och platserna går snabbt!


Några intressanta exempel från årets konferens är Tony Turner från Frenos som pratade om bristerna i hur industriella brandväggar hanterar OT-protokoll. Innehållet kan upplevas som jobbigt, speciielt kanske om man är van vid IT-brandväggar och "enkla" IT-protokoll. Jag rekommenderar verkligen fortfarande brandväggskydd (på rätt ställen) i OT-nätverk men man ska absolut inte tro att de löser alla problem!


Europa är just nu världsmästare i lagstiftning kring cybersäkerhet, exempelvis CRA. Hur påverkar det stora företag som har verksamheter i hela världen. Det diskuterar Dale med Trevor Rudolph från Schneider Electric och Ryan Rathbun from Dupont:

Kloka tankar från Sinclair

Som vanligt har Sinclair Koelemij producerat en lång rad intressanta och kloka texter. Jag bad min AI-kompis illustrera Sinclairs sanslösa tempo och enorma kunskap. Det blev... Intressant...


Här är några av alla texter Sinclair har levererat sedan förra nyhetsbrevet, ALLA är läsvärda:

OT-säkerhet är som ett löpband!

En intressant artikel från Industrial Cyber påminde mig om en otydlighet i det gamla uttrycket "Säkerhet är inte något man har – det är något man gör!". Uttrycket är fortfarande sant, man kan inte köpa cybersäkerhet genom att skaffa bättre brandväggar och intrångsskydd. Det krävs att man ständigt arbetar med sin säkerhet.


Det är lite tröstlöst ibland, jag har en gammal presentation som jag plockar fram ibland där jag jämför säkerhetsarbete med att springa på ett löpband; man springer allt man kan men kommer inte framåt – men slår man av på tempot så åker man bakåt och till slut ramlar man av. Det viktigaste av allt är ständiga förbättringar! Att vi hela tiden anpassar säkerhetsarbetet till förändringar i anläggningen, nya hot och nya behov från verksamheten.


Men det finns en viktig poäng att göra i jämförelsen med ett löpband som artikeln belyser på ett bra sätt. Löpbandet snurrar redan när man börjar planera sin nya anläggning eller sitt nya system! Säkerhetsarbetet behöver starta i samma ögonblick som man börjar utforma sina system!


I OT-världen är detta extra viktigt eftersom ändringar i efterhand tenderar att vara omöjliga eller väldigt dyra. Jag är väldigt förtjust i begreppet "Defensible architecture" från SANS 5 critical controls och det är ofta det som det handlar om. Bygg en anläggning som går att försvara med rimliga resurser!

Nätverket är inte allt!

Ett white paper från Indurex sätter fingret på något som lätt kommer bort i OT-säkerhetsarbetet, att det inte bara handlar om att skydda nätverk och system. Att vi behöver hålla blicken lite högre så att den fysiska processen skyddas och behöver vi minnas att kalibreringen hos sensorer, skyddet av ingenjörsstationer och safetyfunktionernas integritet är helt avgörande.

Till havs!

En av mina favoritbranscher inom OT-säkerhet är sjöfarten. Utmaningarna liknar de som man stöter på i andra typer av verksamheter men det tenderar att vara ännu mer utmanande att förbättra säkerheten. Här är en fantastisk presentation av Ken Munro som verkligen illustrerar hur viktigt OT-säkerhet är ombord på fartyg och hur utmanande säkerhetsarbetet är. Ni får se massor av riktigt imponerande "misstag", min favorit är att missbruka 802.1x för att skapa ett eget nätverk ombord.

Allt förändras men ingenting är nytt...

OT-branschen är inte känd för att förändras snabbt. Tvärtom är det de långsamma förändringarna som ger många av de intressanta utmaningarna kring OT-säkerhet. Något som det pratats om länge är PLC:er som mjukvara och virtualiserade PLC:er.


Det har pratats om det här i många år men det är först nu som det verkligen börjat ta fart. Mitt intryck är att man kan se tre huvudspår, som drar åt lite olika håll:

  1. Virtualiserad PLC som körs på en server. Tenderar att vara på en annan plats än fysiskt nära produktionen, ofta i något slags datacenter eller till och med i ett publikt moln.

  2. Mjukvaru-PLC som körs på hårdvara nära produktionen. Hårdvaran kommer från en annan leverantör än mjukvaran och kan likna en traditionell PLC eller en PC.

  3. Mjukvaru-PLC som körs mycket nära produktionen men på en hårdvara som man normalt sett inte alls associerar alls med en PLC, exempelvis en nätverksswitch.


Jag tror att de flesta traditionella tillverkarna har rena mjukvaruversioner av sina produkter på plats vid det här laget. Det har också skapat uppmärksamhet kring andra möjligheter, speciellt kanske norska uppstickarna OTee och den öppna plattformen OpenPLC från Autonomy Logic. På hårdvarusidan ser jag oftast Revolution PI som har en rad spännande hårdvaror.


Egentligen finns det ett fjärde spår också, men som inte är så nytt. Jag tänker på det omvända, PLC:er som har stöd för att också köra container-applikationer tillsammans med den klassiska IEC 61131-3 programmeringen. Ett välkänt exempel är PLCnext från Phoenix Contact. Riktigt användbart i många lägen!


Den tredje varianten har jag inte stött på hos kunder i verkligheten ännu, men jag påmindes om den när jag läste Emily Zainalis masteruppsats "Reliable containerized soft PLCs for industrial applications" från Mälardalens Universitet. Tydligen har svenska stoltheterna Westermo infört stöd för OCI-containers i senaste versionen av operativsystemet för deras switchar och Emily har tittat på hur väl det fungerar för industriella applikationer i CODESYS om man stressar systemet lite.


Valet att gå från traditionella PLCer till någon form av mjukvarubaserad lösning kräver mycket eftertanke så att man kan dra nytta av fördelarna utan att drabbas av nackdelarna. Emilys slutsatser är en viktig del av sådana resonemang.


För oss som intresserar oss för OT-säkerhet så ställs en del invanda begrepp på huvudet när PLC:n flyttar fysiskt eller dyker upp på en oväntad plats i nätverket. Det är samtidigt just det här som är roligt med OT-säkerhet, att man alltid måste tänka själv och grunda sina vägval i ingenjörsmässiga beslut. Det vill till att hålla tungan rätt i munnen när man gör sitt arbete med Zone&Conduits om en PLC i en viss zon delar hårdvara med funktionen som skapar en conduit. Spännande tider framåt!

När loopen inte är en loop...

Marty Rickard har tittat under skalet våra PLC:er och jämför den klassiska modellen från 80-talet med hur en modern PLC fungerar.


Sättet att programmera är kvar men den gamla modellen kring cykeltider är borta. Om du någonsin drabbats av märkliga fel som inte "borde kunna hända" så kan förklaringen finnas här...


Blir du nyfiken på hur de två processorerna samarbetar så finns en fortsättningsartikel också.

Men nyckeln då?

När du ändå är igång och läser Marty Rickards texter kan kanske den om nyckelbrytare på PLC:er vara intressant? Alltså en strömbrytare, ibland med en riktig nyckel, för att välja om PLCn ska köra eller gå att programmera. De klassiska tre lägena "Run", "Remote" och "Program".

Jag hittade en nyckelbrytare på en gammal SLC 5/03 från Allen Bradley hemma i labbet.
Jag hittade en nyckelbrytare på en gammal SLC 5/03 från Allen Bradley hemma i labbet.

Ett känt case är TRISIS/Triton-attacken där Triconex-enheter hackades på ett visst Saudiskt raffinaderi 2017. Där hade nyckelbrytarna lämnats i "Program" vilket gav angriparna möjlighet att programmera om enheterna så att de i fortsättningen ignorerade nyckel...


Jag stötte på en "hemsnickrad" variant på detta i en kunduppdrag för inte så länge sedan. Där hade man en fysisk brytare som skulle koppla bort all autonomi i systemet som styrdes så att det enbart gick på operatörernas kommando. En bra idé, så länge man inte använder det för att skydda sig mot någon som programmerar om PLC:n – då är det enkelt att stänga av funktionen som reagerar på brytaren...

Apropå långsamma förändringar...

Halmstads stoltheter HMS Networks har publicerat sin årliga analys av OT-protokoll! Om du betalar med din mejl-adress kan du dessutom ladda ner en utökad rapport som pratar mer om säkerhet, mycket mer – 107 gånger på 24 sidor...


Ingen är nog förvånad över att Ethernet fortsätter att ta andelar och inom det området är triaden PROFINET, EtherNet/IP och EtherCAT både störst och mest växande. PROFIBUS och andra fältbussar fortsätter som väntat att minska.

Top 20 Secure PLC Coding Practices

Det här projektet tog 2021 fram rekommendationer om sätt att låta programmeringen av PLCer stötta anläggningens säkerhet. Riktigt bra innehåll! Nu tar man ett nytt kliv framåt, vilket Sarah Fluchs skrev om nyligen.

Vad är en OT-incident?

Ja, det är en fråga som det finns många svar på... Arthur Lin tog en egen titt på 37 välkända OT-incidenter och landade i en del intressanta siffror:

  • 65% av attackerna var egentligen bara en inloggning. Bara i 22% av fallen användes något slags mjukvarusårbarhet.

  • I 57% av fallen upptäcktes attacked förrän den redan gjort sin skada. Bara 8% upptäcktes tillräckligt tidigt för att betraktas som att vara i förväg.

  • Runt 90% av fallen orsakade någon form av fysiska konsekvenser utan att en enda OT-pryl angreps, det räckte med att slå mot IT för att stoppa produktionen.


Nu kan man invända att han inkluderade Oldsmar som de flesta är överens om att det inte var en cyberattack utan ett misstag. Oavsett det så hintar siffrorna om det vi redan vet är vanliga problem:

  • Brister i separation mellan IT och OT

  • Fjärruppkoppling som inte är anpassad till behoven inom OT

  • Nästan ingen har meningsfull OT-övervakning trots att väldigt många har övervakning...

  • Robust produktion är mer än bara tekniska åtgärder i ett nätverk

OT-säkerhet eller ingenjörskonst?

Lee Carter trycker i en lätt sarkastisk och humoristisk text på likheter och skillnader mellan OT-säkerhetsarbete och ingenjörskonst. Jag ska inte försöka återberätta innehållet utan rekommenderar att du läser texten.


På köpet får vi ett gäng coola citat att slänga oss med på möten:

  • “The best OT security control is still good engineering discipline.”

  • “Flat networks were never secure. They were merely lucky.”

  • “Cyber security did not invent defence in depth. Engineers did.”

  • “Every unmanaged switch is future archaeology.”

  • “If your recovery plan is hope, you do not have a strategy.”

  • “Good engineering prevents accidents. Good security assumes someone causes them deliberately.”

  • “Industry 4.0 did not break OT. It exposed what was already fragile.”

  • “A firewall without operational understanding is just an expensive blinking box.”

  • “The air gap was not a strategy. It was geography.”


Men mot slutet blir han också allvarlig och tydlig:

  • Engineering without security thinking is now incomplete.

  • Cyber security without engineering understanding is dangerous.

OT och OSINT

Jeremy McDonald beskriver i en artikel hur OT-säkerhet påverkas av angripare som använder OSINT, alltså öppna källor, för att lära sig hur din verksamhet och era system ser ut. Högst relevant utmaning och lite extra spännande i OT-världen!

Apropå OSINT!

Jag har tidigare rekommenderat alla att följa Svensk OSINT och deras nyhetsbrev. Om du är det minsta intresserad av att hänga med i säkerhetspåverkande i samhället och världen – följ dem!


Nu har de släppt "Svensk OSINT Kommunal Säkerhetsbrief" som är precis vad det låter som – en säkerhetsbrief helt inriktad för svenska kommuner.


Jag vill rikta ett väldigt stort tack till Joel och William för det jättejobb de lägger ner på detta! Mycket användbart!

Finns det några gap i remote access?

Jag var själv insyltad i ett hörn av Henrik Falks arbete på MDU, Mälardalens Universitet, där han jämför remote access i praktiken jämfört med tankarna i NIST SP 800-82r3. För den som vill dyka i hotmodellering kring det här viktiga ämnet är detta ett utmärkt tillfälle!

Undantagshantering i OT

En vanlig utmaning för de flesta OT-verksamheter är bra undantagshantering kopplat till OT-säkerhet. Roger Hill sätter fingret på dessa problem på ett utmärkt sätt i en text som tyvärr är skriven på "broetry". Men om man orkar läsa sådan text är innehållet riktigt bra.

Vad är nästa steg?

Det finns en tydlig förflyttning just nu i OT-säkerhetsvärlden. Allt fler inser att fokuset på visibilitet och asset management som varit i ropet ett antal år nu inte är vad som faktiskt skapar bättre OT-säkerhet. Antoine d'Haussy utvecklar detta på ett tydligt sätt i en text. Väl värt att läsa, särskilt om du är en av alla de som investerat i någon av IDS-leverantörernas produkter och undrar när säkerheten ska börja förbättras.

Vilken PLC-tillverkare har flest sårbarheter?

Arthur Lin har tittat på vilka av PLC-tillverkarna som har flest sårbarheter. Det kunde lätt ha blivit en riktigt meningslös artikel med tanke på att det sällan är tekniska sårbarheter av den här typen som är det stora problemet. Men Arthur gick inte i den fällan, så texten är väl värd att läsa. Han noterar exempelvis att Siemens långt fler sårbarheter jämfört med alla andra tillverkare, men att det beror på att just Siemens sedan deras roll i Stuxnet varit säkerhetsforskarnas favorit att angripa.


En annan poäng, som är väldigt viktig, är att många hundra olika plattformar idag använder samma mjukvara: CODESYS. Det betyder förstås att en bugg där påverkar en enorm mängd tillverkare. Framöver ska det bli intressant att se hur det går för OpenPLC när öppen källkod väcker allt mer intresse.

Konferenser i höst

Dags att planera för höstens konferenser?


Traditionella "SCADA-säkerhet" har till slut uppdaterat sitt namn. Nästan... "SCADA & OT-säkerhet" går av stapeln i Stockholm 29–30 september.


Danska ISC-CPH genomförs i Köpenhamn 9–11 november. Det här har börjat bli Nordens ledande OT-säkerhetskonferens med många internationella talare av hög klass. Numera behöver man inte ens förstå danska, det finns hela tiden något på programmet på engelska.


NCSC, Nationellt Cybersäkerhetscentrum, har annonserat att de genomför en endags-konferens den 23 november, "SVENSK CYBER". De har lovat att det ska finnas fler deltagarplatser än de tidigare konferenserna där det var väldigt svårt att komma in.

Vad är viktigast?

Arun Chauhan påminner oss i en kort artikel om att vårt asset-register inte är värt något om vi inte definierat vilka prylar som är viktigast. Viktig poäng om ett arbete som våra kära inventeringsverktyg inte ska göra åt oss!

Ansvar eller mandat?

I en text från Hillstrong Group påminner de oss om den subtila men praktiska skillnaden mellan att utdela ansvar och att tilldela mandat. Vem får besluta och godkänna? Texten är skriven ur ett rent OT-perspektiv.

Nytt i bokhyllan

Ett par nya böcker har landat i bokhyllan. Båda är på temat risk men den ena fokuserar på riskanalys medan den andra handlar om hur man arbetar med riskhantering i OT specifikt.


Den första är "Risk Management for Operational Technology Systems", skriven av Robert Radvanovsky och Steven Mustard. Risk-drivet säkerhetsarbete är vad alla moderna standarder och lagstiftningar säger åt oss att syssla med. Tyvärr visar det sig ofta att man underskattar hur svårt det är att göra riktigt meningsfulla riskanalyser – inte bara inom OT, utan generellt.


Det här är en massiv bok. Förvisso bara 300 sidor tjock men verkligen fullspäckad med information! I den här boken slipper man de plattityder som tyvärr är vanliga i böcker kring OT-säkerhet, istället dyker de huvudstupa in i utmanande ämnen och backar inte för att vara väldigt tydliga med hur OT-säkerhet utvecklas just nu. Oavsett om man är nybörjare eller rutinerad i branschen ger den här boken mycket till läsaren!


Jag gillar att man på slutet av boken har med intressanta kapitel om incidenthantering, återställning, incidentanalys och ständiga förbättringar. Riskhantering måste hantera och dra nytta av att risker faktiskt inträffar – oavsett om man förutsett dem eller inte...


Nästa bok är inte specifik för OT-säkerhet utan dyker djupt i området kring hur man kvantifierar, jämför och beskriver risker. "From Heatmaps to Histograms" av Tony Martin-Vegue. Vi talar alltså om att komma bort från de tröstlösa 3x3 och 5x5 matriserna för att istället bli tydliga med att vi kan bedöma saker tillräckligt bra även om vi inte har all information. Det här är ett område som alltid stör mig när jag sitter i något slags workshop för att "färglägga risker".


Ett av kapitlen inleds med ett av mina favoritcitat från citat-maskinen Yogi Berra: "It's tough to make predictions, especially about the future." Det är precis det som är utmaningen att försöka förutse vad som kan hända trots att man inte har perfekt information.


Mest känd på det här området är annars Douglas Hubbard med boken "How to measure anything" och tillsammans med Richard Seiersen "How to measure anything in cybersecurity risk" som är fantastiska. Den här boken ska nog ses just som en mycket praktiskt inriktad introduktion till kvantitativ riskanalys. Jag tycker att boken lyckas väldigt väl med detta mål. Jag var i och för sig redan övertygad och tillhör fanklubben för kvantitativa metoder. Nu ska jag ge mig i kast med FAIR-metoden och lära mig den bättre. Jag har fått nytt hopp om nyttan med riskanalyser!



Det är kul med välskrivna böcker! De flesta köper jag numera i digital form men det blir en del klassiska böcker också.

Bygg din egen gråskala!

Det vanligaste sättet som OT drabbas av en attack är att IT-sidan blir angripen och att man för att vara försiktig tar ner produktionen för att "inte riskera något". Jag stöter lyckligtvis allt oftare på verksamheter som inte nöjer sig där utan som vill ha starka men sansade metoder att ta till.


Donovan Tindill beskriver detta bra i en text där han utgår ifrån att "Shut it down!" inte är en strategi utan ett symptom på att man inte har koll på vad som hänt och man vet inte vad som krävs för att kunna köra produktionen vidare på ett säkert sätt.


För att göra något åt detta behöver man ta reda på vilka konsekvenser som kan uppstå, vilka beroenden som finns mellan olika system och sedan ta ett helhetsgrepp på sin infrastruktur. Insikten om att det finns en gråskala som man kan röra sig på är nyckeln till att ha mer avvägd respons till händelser. Donovan ger ett exempel med fyra nivåer:


  • Level 0 (Guarded): Enhanced monitoring, minimal change. Freeze non-essential engineering/maintenance changes and stabilize communications.

  • Level 1 (Elevated): Conduit isolation. Isolate external access paths first (vendor VPNs, remote tools, exposed management interfaces). Lock down portable media and laptops as conduits. This can have sub-tiers within the firewall access lists, with groups of applications and services being blocked.

  • Level 2 (High): Minimum viable operations (MVO). Reduce to the minimum networks/apps/integrations required to operate safely. Disable “nice-to-have” connectivity.

  • Level 3 (Severe): Safe shutdown as last resort. Shutdown happens out of knowledge, not uncertainty.


Läs hela artikeln, det finns många kloka tankar att ta med till ditt eget arbete! Det handlar inte bara om att hantera incidenter, det är även ett sätt att hantera tillfälliga förhöjda hotnivåer i samhället.

Från mitt eget LinkedIn

Om du inte följer mig på LinkedIn så är här några av mina inlägg från senare tid som väckte lite extra intresse och/eller diskussion. Det är alltid extra roligt när ett ämne får folk att reagera och tycka till!


Det inlägg som fick i särklass mest kommentarer och reaktioner var egentligen en udda detaljfråga jag ställde kring de där 24 timmarna som man maximalt har på sig att rapportera en incident enligt NIS2. I samband med att jag arbetade på ett kommande white paper med titeln "Erfarenheter av incidentrapportering enligt NIS2/CSL" så snubblade jag över en gammal svensk lag från 1930. Den här lagen, "Lag (1930:173) om beräkning av lagstadgad tid", verkade (för mig som 100% amatörjurist) innebära att det var okej att vänta till en vardag om de 24 timmarna innebär att rapporteringen behövde ske på helgen eller en helgdag. Jag tyckte själv att det vore väldigt olämpligt om det skulle vara så – det fick bli en fråga till alla jurister på LinkedIn. Svaren pekade åt lite olika håll men sedan kom en riktigt grundlig analys av David Eliasson som kom fram till att "söndagsregeln" inte gäller men att det samtidigt borde ha gjorts mycket tydligare i lagtexten eftersom det var ett känt problem. Jag rekommenderar verkligen alla att se till att ni klarar att respektera de 24 timmarna, även om det är på midsommarafton! Kravet är dessutom "så snart det går" med 24 timmar som absolut längsta tid, så arbeta snabbt!


Ett annat populärt inlägg var på det klassiska temat varför IT och OT tenderar att ha svårt att samarbeta.


Vem är Mats?

Porträtt av Mats Karlsson Landré

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 !

Logga för nyhetsbrevet på ot-säkerhet.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