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