.png)
Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du en rolig tävling, försäkringsbolagens nya fokus på OT-säkerhet, världsläget inom OT enligt SANS, dödsstöten för risk-management, Pentagon driver Zero Trust inom OT, beröringspunkter mellan olika standarder, vad ordet sårbarhet egentligen betyder, realtids-Linux, det senaste kring CRA/NIS2/Maskinförordningen och en lång radda andra spännande ämnen.
Om det är första gången du läser ett av mina nyhetsbrev kanske du undrar vad det där "OT" är som jag pratar om? OT står för Operational Technology vilket är ett syskon till IT, Information Technology. Läs mer om det här i det här nyhetsbrevet!
Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. Det här nyhetsbrevet är ju något som jag fortfarande tycker är väldigt roligt att skapa, vilket förstås är viktigt eftersom det till största delen skrivs hemma i TV-soffan. Som vanligt vill jag gärna att du delar med dig av nyhetsbrevet till kollegor som kan vara intresserade! Ju fler som läser, desto bättre möjligheter får jag att producera bra innehåll framöver! Om du vill ha nyhetsbrevet i inkorgen i fortsättningen är det bara att anmäla dig på www.ot-säkerhet.se eller dra ett mejl till mig på mats@ot-sakerhet.se. Jag lovar att din mejladress inte används till något annat än detta!
Du hittar alla tidigare utgåvor av nyhetsbrevet på www.ot-säkerhet.se. När det kommer nytt material så annonserar jag det på en massa ställen: min Linkedin-profil, i dess egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, på Mastodon, på Bluesky, på Twitter och på en egen Facebook-sida. Du kan också prenumerera via RSS på www.ot-säkerhet.se.
Ge mig gärna mothugg, frågor eller förslag på LinkedIn där den här utgåvan delades. Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på artikeln och genom att dela den vidare. Tack för hjälpen!
Försäkringsbolagen är på G!
I dessa dagar, när alla pratar om nya lagar som ställer krav på säkerhetsåtgärder i våra produktionsmiljöer får vi inte glömma en annan maktfaktor som redan arbetat med det här i många år. Jag tänker på försäkringsbolagen.
Och jag ska säga direkt att jag inte tänker på cybersäkerhetsförsäkringar utan att försäkringsbolagen allt mer hanterar digital säkerhet i produktionsmiljöer på samma sätt som brandskydd och andra "klassiska" riskområden.
Jag har deltagit som stöd till några av mina rådgivningskunder när deras försäkringsbolag kommer på "inspektion" med fokus på cybersäkerhet i produktionen. Mina intryck av hur försäkringsbolagen hanterar det här är väldigt positiva! Det har varit kunniga människor som ställer meningsfulla frågor och som drar mycket relevanta slutsatser om riskerna.
Ett exempel på ett försäkringsbolag som jag har ett gott intryck av är FM Global. De är extra intressanta för att de dessutom publicerar en mängd texter kring vad som är bra att tänka på för att minimera risker i produktionen. Ett exempel, som nyligen uppdaterades, handlar om "Industrial Control Systems".
Som du kanske märkt är jag väldigt positiv till de ökade kraven från exempelvis EU, men jag måste säga att försäkringsbolagen kan komma att ha lika mycket effekt - även om de verkar lite mer "bakom kulisserna". Jämförelsen med att ha bra brandskydd haltar förstås lite men det tydliga ekonomiska tryck som försäkringsbolagen börjar sätta mot organisationer med dålig säkerhet i produktionen kommer ha effekt!
Läget i OT-världen enligt SANS
Jag är inte så förtjust i alla de där årsrapporterna som vänder och vrider på enkätsvar för att skapa något som liknar spännande insikter. Men välkända utbildningsföretaget SANS, som jag har mycket respekt för, släppte nyss sin "2024 State of ICS/OT Cybersecurity".
Du får själv ta till dig vad du tycker är rimligt, relevant och intressant men jag noterade för min del att:
Användningen av molnbaserade tjänster ökar snabbt nu. Det matchar för övrigt vad jag själv ser bland mina kunder.
Förmågan att upptäcka säkerhetsincidenter och att hantera dem är fortfarande svag hos de flesta. Här hoppas jag att många påverkas av det fokus som NIS2 har på just detta - insikten att du oavsett hur mycket skydd du har, så behöver du fortfarande kunna upptäcka, hantera och analysera en produktionspåverkande händelse.
Färre rapporterar ransomware-angrepp vilket matchar utvecklingen generellt.
Förmågan att försvara sin OT-infrastruktur tycks fortfarande främst bygga på accesskontroll, backuper, EDR, IT/OT-separation och säker fjärråtkomst. En förvånansvärt stor andel har fortfarande ingen säkerhetsövervakning eller OT-SOC. Jag får ofta frågan om man ska ha en separat SOC för OT (särskilt nu när jag jobbar på Sectra). Svaret är som vanligt: "Det beror på!". I de fall OT-systemen verkligen liknar "vanliga IT-system" och produktionen faktiskt inte har annorlunda behov än resten av organisationen så är en kombinerad SOC definitivt rimlig. Annars finns det anledning att vara försiktig.
Riktigt glädjande att se att så många tagit rejält tag i sin fjärraccess! 33% spelar in sessionerna och 55% kan övervaka och avbryta uppkopplingar om märkligheter upptäcks. Kul att fler inser de grava begränsningarna med vanlig VPN!
Har du koll på 2024/2847?
2024/2847 blev det officiella dokumentnumret på CRA, Cyber Resilience Act, när lagen nyligen publicerades och därmed börjar gälla den 11:e december. Det betyder att nedräkningen mot full implementation den 11:e december 2027 har börjat. På vägen finns det ett antal "etappmål"; bland annat ska aktivt utnyttjade sårbarheter börja rapporteras redan 11:e september 2026 och från den 11:e juni 2026 gäller reglerna kring organisationer som granskar överensstämmelse. Senare samma år, från och med den 11:e december 2026, ska länderna ha sett till att det finns tillräckligt många sådana granskande organisationer inom EU.
Det har verkligen gått inflation i lagar med ordet "Cyber" i titeln på senare tid. Det är faktiskt något av ett problem, i synnerhet om NIS2 verkligen kommer implementeras i Sverige under namnet "Cybersäkerhetslagen". NIS2 handlar i mina ögon främst om resiliens och CRA mest om säkerhet - vilket gör namnen väldigt förvirrande!
Nu blir det tre bråda år för väldigt många produkt- och mjukvaruproducenter, även de mest mogna utvecklingsprocesser behöver i de flesta fall kompletteras. Det kommer kanske också bli en del intressanta kommersiella effekter, bland annat eftersom alla säkerhetsuppdateringar enligt lag måste vara gratis från och med 2027...
Men? Vem är det som kör egentligen?
Joe Weiss har publicerat ett dokument med den spännande titeln "Who's in charge of OT Security", som är tänkt att försöka reda ut många av de klassiska frågorna kring OT-säkerhet, exempelvis:
Skillnader mellan IT och OT samt mellan IT-säkerhet och OT-säkerhet?
Vad är Purdue-modellen egentligen tänkt att användas till?
Inträffar det några OT-säkerhetsincidenter?
Skillnaderna mellan nätverkssäkerhet och "Safety" i kontrollsystem?
Hur ska man organisera och leda säkerhetsarbetet?
Hur kommer vi framåt?
Kluriga frågor som förtjänar kluriga svar!
Den eviga frågan om risk!
Ett område som jag personligen alltid har haft svårt för är "Risk management". Jag har aldrig känt mig riktigt bekväm i någon av alla modeller för riskidentifiering, riskanalys, riskprioritering, riskhantering osv som jag stött på genom åren. Det känns nästan alltid väldigt konstlat med noll eller inget fokus på att faktiskt skapa något slags verkligt värde.
Ett intressant perspektiv hittade jag i ett LinkedIn-inlägg av Marinus de Pooter som egentligen är en utskrift av en presentation han genomförde under "Risk & Resilience Festival" på Nederländska Universiteit Twente. Den utmanande titeln är "Stop managing risks!". Han ifrågasätter precis som jag nyttan med sedvanliga metoder kring risk och vill istället sätta ett starkt nytto-fokus och ta ledningens perspektiv. Vi får på köpet en historisk beskrivning kring vårt sätt att se på risker.
Jag kan inte säga att jag ser det som en komplett lösning, men han sätter definitivt fingret på intressanta poänger, exempelvis:
Poängen med att använda begreppet "uncertainty" istället, det passar betydligt bättre med de förutsättningar som alla andra beslut i en organisation styrs kring.
Med stöd i COSO kan man faktiskt söka upp mer risk för att uppnå mer prestanda och/eller andra vinster.
Att regelbundet uppdatera listor med saker som kan gå snett hjälper oss inte nå våra mål under oklara förutsättningar.
Fokus borde ligga på "future-proofing" och robusthet som ett sätt att uppnå de vinster som risk management var tänkta att skapa.
Apropå detta, i synnerhet "future-proofing" och robusthet, så hade jag en intressant diskussion nyligen kring det som jag uppfattar som en tydlig trend i samhällets syn på säkerhetsarbete. Jag tycker det är intressant att fokuset på sannolikheter äntligen har börjat minska till fördel för ett konsekvens-drivet fokus som siktar på att bygga resiliens. Det som jag stöter på oftast väl:
Det är allt mer populärt att använda metoder som Cyber-Informed Engineering (CIE) och Consequence-driven Cyber-informed Engineering (CCE) som båda på sitt sätt fokuserar åtgärder mot extrema konsekvenser oavsett sannolikhet. (Jag har skrivit om dessa tidigare, exempelvis här.)
Det svenska säkerhetsskyddet är inget nytt och har alltid haft just det här fokuset. Däremot appliceras säkerhetsskydd på allt fler verksamheter (på gott och ont) och i synnerhet på verksamheter där skyddet av information inte står i centrum, dvs OT. Regelverket och våra myndigheter har verkligen inte kommit ikapp kring den här typen av resonemang, men det tar sig...
I de kundkontakter jag har på min nya arbetsplats, Sectra, är det väldigt tydligt att intresset för riktig säkerhetsövervakning i OT-sammanhang ökar rejält. Det kommer ofta ur en insikt om att man vare sig kan förutse alla attacker eller kan ta bort alla sårbarheter. Samtidigt måste övervakningen då vara byggd från grunden för att förstå förutsättningarna i OT-verksamheter, vilket är lätt att missa eftersom OT-tekniken allt mer liknar IT-världens teknik.
Initiativen från EU, i synnerhet NIS2, bygger också på den här typen av resonemang - att skapa tålighet i samhället genom att viktiga leverantörer tål att få en "cybersmocka" utan att gå ner för räkning.
Hör gärna av dig med tankar kring detta kluriga ämne! mats@ot-sakerhet.se
Pentagon satsar på Zero Trust för OT-säkerhet
I en intressant liten artikel i "Breaking Defense" berättas att USAs Department of Defense nu kommer styra om fokuset på sitt arbete med Zero Trust mot OT-verksamheten.
Python och honung i OT-nätet?
Yuancheng Liu från Singapore har skapat "Python PLC Honeypot Project", en riktigt intressant honeypot med fokus på OT-världen. Fokus tycks vara att simulera ett antal olika PLC-typer och deras kommunikationsvägar för att på så sätt kunna identifiera och analysera angripares beteenden.
Det finns även två artiklar av honom på LinkedIn. En om projektet i sig och en om uppsättning/detektion.
Förvirrad av alla standarder?
Det blir hela tiden fler standarder, lagar, ramverk osv som vi ska förhålla oss till! Det är lätt gjort att man känner sig lite vilse i den här djungeln. Andrew Ginter på Waterfall höll nyligen ett riktigt bra webinar där han sorterar upp ett tiotal av de mest kända, men den stora behållningen är att han också för ett resonemang kring viktiga kravområden som genomsyrar dem alla. Lyssna exempelvis på avsnitten om "Consequence boundaries" och "Risk-based approach", det här är viktiga resonemang för alla som jobbar med OT-säkerhet.
Om du inte redan gjort det så missa inte att beställa Andrews senaste bok som är gratis! Massor av klokskap på ett och samma ställe!
Vad menar du med ordet "Sårbarhet"?
Att hålla koll på sårbarheter är viktigt inom både IT-säkerhet och OT-säkerhet. Det är också en av de saker som ofta lyfts fram som en viktig skillnad mellan just IT och OT. Tanken brukar vara att IT typiskt har mycket enklare att snabbt kunna patcha sårbarheter i system medan OT-folket behöver göra fler och svårare avvägningar mellan nytta och risk.
Det här med att patcha är med rätta också något som har stort fokus i både standarder och myndighetskrav. För oss i OT-världen finns det en fälla som jag tycker många missar när de definierar sin sårbarhetshantering. Fällan bygger på att själva ordet "sårbarhet" har ganska olika definitioner beroende på om du lever i en verksamhet som lever efter ISO 27001 eller efter IEC 62443.
ISO 27001 pratar just om svagheter i ett system eller en säkerhetsåtgärd. IEC 62443 har en betydligt bredare definition som även tar med brister i hur ett system utformades, hur implementationen gjordes och hur systemet sköts om. Det kan tyckas som en liten och oviktig skillnad men den kan få ganska stora konsekvenser...
"Vulnerability" enligt IEC 62443-3-2: Flaw or weakness in a system's design, implementation or operation and management that could be exploited to violate the system's integrity or security policy
"Vulnerability" enligt ISO 27000: Weakness of an asset or control that can be exploited by one or more threats
Den vardagliga betydelsen har ofta en ännu smalare definition som bara handlar om mjukvaror. Med glimten i ögat skulle den bli något i den här stilen:
"Vulnerability" i vardagligt språk: A mistake in software that stubborn vendors keep creating. It can be fixed by simply applying an patch before hackers can use it in some magical way.
Det där med att 62443 tar med svagheter i hur ett system är designat är ju ganska naturligt i OT-världen med tanke på att vi använder en hel del "svaga" protokoll och system som inte är utformade för att vara robusta. Tyvärr finns det en tendens att det glöms bort, vilket skapar onödigt arbete. Ett påhittat exempel på vad jag menar är att vi har en applikation där en motor styrs via en "frekvensare", en VFD, från en PLC via MODBUS TCP. En eventuell angripare med tillgång till nätverket skulle enkelt kunna styra motorn direkt utan att PLCn har något att "sätta emot". Då blir det ganska konstigt om man bekymrar sig över en ny DoS-sårbarhet i PLCn och lägger ner mycket arbete på att patcha den när det finns mycket enklare sätt att störa produktionen...
Det här är inget stort problem om man är medveten om det och verkligen ser till att alla i den egna organisationen använder samma tolkning. Däremot är det förstås viktigt att vara extra noggrann om man siktar på att certifiera sig mot en standard! Om man är en så pass mogen organisation att man har ett integrerat ledningssystem med inslag av både ISO 27001 och IEC 62443 blir det en lite klurigare balansgång att hantera detta. Men det går!
Sinclair levererar igen!
Vi är sedan länge bortskämda med att Sinclair Koelemij skriver superintressanta texter. Nu är det dags igen, den här gången en ganska detaljerad artikel om integritet som del i riskanalys inom petrokemisk industri.
Vad är det jag missar?
CIA-triaden, alltså den gamla välkända trion av ord: Confidentiality, Integrity och Availability, känner du säkert igen från Informationssäkerhet!
Ett vanligt argument när "folk" försöker förklara skillnaden mellan säkerhetsarbete i IT och i OT är något i den här stilen: "Inom IT är Confidentiality och delvis Integrity viktigast. Man kan tänka sig att offra Availability för att skydda de andra två. Inom OT är Availability viktigast." Det brukar dyka upp som förklaring till att man inte vill patcha i OT-världen, eftersom det oftast kräver att system görs otillgängliga.
Det här har jag alltid haft svårt för, och av minst två skäl. Dels så är det helt enkelt inte sant för alla typer av OT-verksamheter, ett vanligt exempel är tillverkande industri som, i många fall, relativt enkelt kan hantera planerad nertid.
Men det som "stör" mest är att jag tror de flesta skulle säga att Integrity är viktigast i de flesta OT-sammanhang! Att vi tappar tillgänglighet är förstås aldrig bra men för de flesta verksamheter skulle det vara ännu värre om integriteten i styrningen av processen manipulerades! I synnerhet när vi talar om farliga verksamhet där Safety-system ska hålla koll på att inget farligt händer. I ett välbyggt system går det inte att missa att ett Safety-system blir otillgängligt, men om systemet i stället manipulerades så att det agerar utifrån fel förutsättningar - då kan det bli riktigt farligt!
Jag tror att det här missförståndet kan ha sin grund i att man pratar om olika saker? Tillgänglighet av funktion kontra riktighet i funktionalitet kanske? Har du åsikter om detta vill jag väldigt gärna höra dem! mats@ot-sakerhet.se
Guide för CIS Critical Security Controls
Jag verkar ha missat att CIS i somras släppte en guide för hur man använder "CIS Critical Security Controls v8.1" i OT-världen. Dessa controls är ju väldigt populära i IT-världen, dels för att man begränsat sig till bara 18 huvudsakliga säkerhetsåtgärder och för att man vågar ranka dem genom att säga att control 1 är viktigast att göra först.
Upplägget är tydligt! För var och en av de 18 får vi en översikt, en beskrivning av hur den passar inom OT-världen, speciella utmaningar för OT och lite referenser till andra dokument. Varje säkerhetsåtgärd har som vanligt ett antal "underrubriker", kallade "Safeguards" som beskrivs var för sig med OT-ögon.
Ett mycket användbart dokument, i synnerhet om organisationen använder CIS Controls för fler saker.
Kräv inte att dina leverantörer följer NIS2!
Ett vanligt slarvfel som jag hör från "förståsigpåare" är "Om du levererar till ett NIS2-företag så omfattas du också av NIS2!". I synnerhet är det vanligt från säljsugna produktleverantörer som utlovar "NIS2-compliance som produkt". Men det finns ingen sådan regel, vare sig i NIS2 eller förslaget till cybersäkerhetslag! Däremot ska en NIS2-organisation se till att leverantörernas säkerhetsnivå inte ställer till det för dem själva som kund!
En liknande tankevurpa hör jag från organisationer som omfattas av NIS2 när de ska ställa krav på sina leverantörer: "Om ni ska sälja till oss så måste ni uppfylla NIS2!". Det är förvisso helt möjligt att ställa ett sådant krav men du riskerar att skjuta dig själv i foten som kund.
Varför då undrar du kanske och då svarar jag att:
Med ett "flummigt uttryckt" krav riskerar du att orsaka mycket onödigt arbete och därmed onödiga kostnader för din leverantör, vilket i slutänden kommer att hamnar på fakturorna som de skickar till dig...
NIS2 pratar mycket om proportionalitet i de säkerhetsåtgärder du väljer. Du ska ha vare sig mer eller mindre säkerhet än vad som faktiskt är meningsfullt för dig. Varför ska du då missa chansen att sätta din egen nivå på kraven mot leverantörerna? Vilka delar av deras leverans är viktigast och vad är dina krav?
När cybersäkerhetslagen har satt sig om några år och vi fått föreskrifter från en rad olika tillsynsmyndigheter så blir det omöjligt för en underleverantör att veta vilka kravmassor de ska bry sig om för respektive kund. Det måste vara ditt jobb som kund att definiera! Glöm inte att riktigt kritiska leveranser kanske måste ha mycket högre krav på sig än de allmänna kraven i NIS2!
Om du själv inte omfattas men är leverantör till NIS2-organisationer så kan du göra det mycket enklare för dig själv genom att redan nu sammanställa de krav du uppfyller åt dina leverantörer. Mindre jobb för dig och gladare kunder!
Jag håller förvisso med de som säger att NIS2 egentligen inte kräver något speciellt säkerhetsarbete som inte alla organisationer redan borde ha på plats. Men i praktiken är det inte så enkelt och det behöver vi förhålla oss till! Leverantörer är helt avgörande för många verksamheter och då borde de få motsvarande uppmärksamhet i säkerhetsarbetet!
(Den här texten publicerade jag på LinkedIn för ett tag sedan. Det märks att det är ett ämne som engagerar, det blev det i särklass mest lästa inlägg som jag någonsin gjort. Det finns en del godis att läsa bland kommentarerna.)
Riktigt realtids-stöd i standard-Linux!
I takt med att det blir allt populärare med olika typer av edge-produkter i OT-världen samtidigt som PLC:er baserade på "normala" operativsystem också får allt mer uppmärksamhet är det passande att nu den ordinarie Linux-kärnan fått stöd för realtids-hantering från version 6.12. Jag gissar att det firas hos företag som Beckhoff och WAGO nu?
Nu blir det NIS2-smisk?
EU har beslutat att agera formellt kring att majoriteten av länderna i unionen grovt har missat deadline för NIS2 och CER. Sverige är i "gott sällskap", det är totalt 23 länder som får ett brev på posten (!) som uppmanar dem att återkomma inom två månader med implementation eller en plan.
CRA utreds i Sverige....
En utredning har tillsats för att titta på vad som behöver göras i Sverige kring EUs Cyberresiliensförordning, CRA. Arbetet leds av Anette Norman, som också drev NIS2/CER-utredningen. Arbetet ska vara klart 15:e december nästa år. Notera att det alltså inte är samma typ av uppdrag som NIS2/CER, där handlade det om att implementera två EU-direktiv i svensk lag, nu är det en EU-förordning vilket gäller som lag direkt - men däremot kan det behövas justeras i andra lagar för att det ska fungera bra.
En tävling med ett pris som du bestämmer själv!
Bland folk som sysslar med cybersäkerhet har det alltid varit många som tycker det är kul att klistra laptopens skärm full med märkliga klistermärken med anknytning till det man sysslar med. Av det skälet tänkte jag att det kunde vara kul att framöver trycka upp lite roliga klistermärken med koppling till OT och nyhetsbrevet, men jag behöver din hjälp att hitta riktigt bra idéer!
Det kan vara något om OT-säkerhet som område och varför det är viktigt. Det kan vara för sajten ot-säkerhet.se. Eller det kan vara något annat som har med området att göra, kanske safety, robusthet eller produktion? Det vore riktigt kul med förslag till en smart logga för nyhetsbrevet!
Skicka mig dina bästa och sämsta idéer, det behöver inte vara en bild utan kanske en bra text eller ett budskap att förmedla! mats@ot-sakerhet.se Jag är enväldig domare och vinnaren kommer förstås få sitt förslag upptryckt som klistermärke! Det finstilta: "Om du skickar in ett förslag så säger du att det är okej att jag använder det oavsett om du vinner eller inte."
Här är några utkast jag lekte med själv, men låt inte mina försök begränsa din egen kreativitet:
När jag ändå var igång så provade jag även text på reflexmaterial som monterades på varseljackan. Nu kan man visa upp sig på ett riktigt moderiktigt sätt igen! :-) Och så blev det förstås några broderade patchar för ryggsäckar som också blev riktigt bra.
Kom gärna med alla möjliga kreativa förslag! Allt uppskattas! Vad skulle du själv vilja ha?
Lås dörren inifrån!
En insikt som IT-säkerhetsvärlden tog till sig för många år sedan verkar fortfarande inte ha "landat" fullt ut inom OT-säkerhet. Det handlar om hur man bygger brandväggsfunktioner som inte bara styr upp vad som får "komma in", utan även vad som får "komma ut". Eftersom många attacker så att säga uppstår inifrån så behöver man också ha koll på vad som kommunicerar ut.
Ett typiskt hemmanätverk har någon form av brandvägg som ser till att allt elakt på Internet inte kan komma åt prylarna som är anslutna till hemmets nätverk; laptops, skrivare, tv-apparater och kylskåp. Inget konstigt så långt. De flesta har nog aldrig tänkt tanken att man skulle kunna begränsa vad man får komma åt på Internet. (Utom möjligen föräldrar som vill styra upp barnens åtkomst.)
Många enklare IT-nätverk liknar ett sådant hemmanätverk, möjligen kompletterat med funktioner som försöker titta på trafiken för att hitta misstänkt skadlig kod eller liknande. Har man servrar som ska vara åtkomliga på Internet så släpper man fram bara rätt trafik till just dem. Men i stort är det fortfarande framförallt fokus på att begränsa vad som släpps in.
IT-nätverk med högre krav på säkerhet har genom åren ägnat sig att även styra upp vad som släpps ut på Internet. Vanlig surfning släppte man typiskt ut men man höll ändå koll på att det faktiskt var rimlig trafik och kanske att krypteringen var korrekt. Men sedan började det ta stopp, typiska exempel var:
De allra flesta servrar har inga eller väldigt begränsade behov av att fritt nå Internet. Uppdateringar och annat ska hanteras via de verktyg som hämtar hem sånt.
DNS-trafik är väldigt lämpligt att både övervaka och filtrera. Då behöver man också begränsa vilka system som skickar ut externa förfrågningar.
Trafik på ovanliga portar eller via ovanliga protokoll bör styras upp så att allsköns bakdörrar inte skapas.
I takt med att allt fler IT-system blev "molnifierade" behövde man hantera det här annorlunda men behoven finns ofta kvar. I grunden handlar det om att bara det som behöver kunna prata på nätverket ska ha möjlighet att göra det. Lite besläktat på sätt och vis med "least privilege" och "Zero trust".
För de allra flesta OT-nätverk är det här fortfarande extremt relevanta åtgärder i kommunikationen med IT-system. OT-nätverk som behöver fri åtkomst till vad som helst på "IT-sidan" är ovanliga och bred åtkomst direkt till Internet är rimligen extremt ovanligt. OT-nätverk (bör) kännetecknas av att förändringar sker sällan och bara i samband med planerat arbete. Det betyder att vi enklare kan styra upp vad som får prata ut från OT-nätverket och vi kan betrakta oväntad ny trafik med misstänksamhet.
Glöm förresten inte det som Beacon från SensorFu kan hjälpa dig med! Jag skrev om den här fiffiga lösningen i nyhetsbrev #57. Den upptäcker den alla möjliga spännande varianter på kommunikation som man kan använda att få kontakt med något utanför en brandvägg...
Man behöver komma ihåg att OT är många olika saker, där alla OT-verksamheter är olika, så man behöver välja säkerhetsåtgärder efter sina egna förutsättningar. Några kloka åtgärder att överväga är:
All trafik, både in och ut, från OT-nätet ska vara känd, dokumenterad och tillåten individuellt per system eller liknande.
En del oväntade protokoll kan användas för att styra skadlig kod eller stjäla information. DNS är en sådan vilket gör det viktigt att se till att begränsa både vem som får skicka förfrågningar en också vilka frågor som får ställas.
Ett specialfall är fjärruppkopplingar som förstås behöver lite extra uppmärksamhet. Välj något som faktiskt stöttar verksamheten på ett vettigt sätt och undvik att använda "en vanlig VPN". Alla andra former av tunnlar bör begränsas.
Beroende på hur man arbetas med segmentering inom OT-nätet och hur man använder DMZ-liknande funktioner får man förstås anpassa regelverket för vad som får prata med vad.
Ägna speciell uppmärksamhet åt system och nät som används för systemadministration. I många fall är det vettigt att inte blanda med IT-världen och det är definitivt vettigt att ha superkoll på system där exempelvis Domänadministratörer kan logga in.
Glappet mellan Säkerhetsskydd och NIS2!
Ska din organisation följa både Säkerhetsskyddslagen och den föreslagna NIS2-Cybersäkerhetslagen? Då vet du nog redan att det är tydligt att enbart Säkerhetsskyddslagens krav gäller för de delar av verksamheten där de båda lagarna överlappar. (I alla fall för de flesta verksamheter.)
Det finns dock en klurighet som kan vara värd att fundera över, nämligen att de två lagarna adresserar olika hot! I NIS2, och därmed Cybersäkerhetslagen, säger man väldigt tydligt att riskanalyser ska göras ur ett "allriskperspektiv", dvs alla risker som kan påverka produktionen via någon form av cyberhot ska tas med.
Säkerhetsskyddslagen däremot, är enbart inriktad på det som brukar kallas "antagonistiska hot". Där ska riskanalysen, som är en del av Säkerhetsskydds-analysen, enbart titta på medvetna mänskliga angrepp. Det är förvisso inte helt sant, lagen säger också att säkerhetskänslig information även ska skyddas på vissa andra sätt, exempelvis mot brister i dokumenthanteringen. I det här sammanhanget brukar man prata om Verksamhetsskydd när man tar hand om alla andra typer av risker, men det är inget som kravställs i lagen.
Den utmaning jag ser är alltså att det, på sätt och vis, blir lägre krav på robust produktion via säkerhetsskyddslagen än via cybersäkerhetslagen! De risker som faller mellan stolarna är skador som orsakas av olyckshändelser, haverier, otur, naturkatastrofer, misstag, tekniska brister och liknande som ingen "elak" person orsakade med flit.
Men jag har samtidigt inget förslag på hur lagstiftarna kunde gjort det annorlunda. Hanteringen av tillsyn och incidentrapportering skulle bli väldigt komplicerad om man försökte kombinera de två lagarna i samma verksamhet.
Det här är inte tänkt som kritik mot säkerhetsskydd, även om mycket kan utvecklas i stödet kring de delar av säkerhetsskyddet som inte fokuserar på hemlig information. Vi får helt enkelt hantera det som saknas i kraven i ren självbevarelsedrift. Om det stora syftet med vårt säkerhetsskydd är att säkerställa att vi kan hålla igång vår verksamhet så är det precis det vi hela tiden måste ha i bakhuvudet! Målet med vårt arbete måste alltid vara en robust produktion oavsett om det handlar om el, vatten, fjärrvärme eller något annat område där rätt OT-säkerhet är avgörande för vår förmåga att producera.
(Den här texten finns även på LinkedIn och har ett antal intressanta kommentarer som är värda att läsa.)
Inget förtroende för Zero trust?
ISA Global Cybersecurity Alliance (ISAGCA) är en sammanslutning av företag som hålls samman av organisationen ISA, som ju är en av organisationerna bakom 62443-standarden. De har publicerat ett white paper som tittar på Zero Trust ur ett OT-perspektiv.
Zero Trust och OT-säkerhet är en lite klurig kombination som många leverantörer satt sin egen spinn på för att visa att de kan leverera "Zero Trust på burk". Det här dokumentet är ett samarbete mellan bland annat Nozomi Networks, Schneider Electric och Rockwell Automation vilket gör det lite mindre produktfokuserat. Det tar upp en del intressanta vinklar som kan vara värda att ta till sig om man siktar åt det här hållet i sitt säkerhetsarbete.
Ett annat dokument på samma tema imponerade faktiskt lite mer på mig. Det är CSA, Cloud Security Alliance (!) som producerat "Zero Trust Guidance for Critical Infrastructure". Här har man utvecklat resonemangen mycket mer och kombinerar många intressanta vinklar från både NIST, CISA, ISA, IEC 62443 och SANS Five ICS Cybersecurity Critical Controls. De kryddar alltsammans med citat från självaste John Kindervag och knyter ihop säcken snyggt.
Nu ökar takten från EU!
Det duggar allt tätare mellan viktiga utskick från EU. När det gäller Cyberresiliensförordningen CRA så har den kommit i en slutgiltig version. Här ställs alltså krav på säkerhet i utveckling och underhåll av alla former av digitala produkter. Apropå CRA så har Sarah Fluchs släppt en (som vanligt) bra och tydlig artikel om dokumentationskravet i CRA och dessutom en artikel om hur CE-märkningen i CRA fungerar. Hon har dessutom skrivit en artikel där CRA och Maskinförordningen jämförs. Spännande eftersom de har en del intressanta överlapp...
När det gäller NIS2 så har vi fått en skarp version av den genomförandeförordning som jag nämnde i ett tidigare nyhetsbrev. Från EUs cybersäkerhetsmyndighet ENISA finns också ett utkast till stöd kring förordningen ute för feedback. Här finns en del detaljer kring vilka typer av bevis som kan vara lämpliga vid en tillsyn kring dessa regler. Det finns också en del referenser till standarder som man kan ta hjälp av i de olika olika kraven, men eftersom kraven inte är inriktade på OT-säkerhet finns tyvärr inga referenser till 62443-standarden.
Vi har också fått ett uttalande från Post och Telestyrelsen PTS som berättar att verksamheter som omfattas av "NIS1" och som träffas av genomförandeförordningen förväntas ta hänsyn till kraven där sedan den 7:e november.
Den 27:e november höll Post och Telestyrelsen, PTS, ett webbinar kring NIS2 som dessutom finns inspelat. En rimlig fråga är då om OT-verksamheter verkligen är intresserade av de branscher som PTS har tillsyn över? Svaret är faktiskt ja, även om kopplingen mest är indirekt. Bland de branscher som PTS är tänkt att ha tillsyn för finns förutom kommunikationstjänster även IT/OT-drifttjänster och outsourcade säkerhetstjänster, exempelvis en OT-SOC eller patchningsuppdrag som man lägger ut på underleverantörer.
Nytt (och gammalt) i labbet
För den som är road av kul teknik så inför jag nu den här stående rubriken i nyhetsbrevet. Här kommer jag helt kort nämna saker som nyligen dykt upp i OT-labbet där hemma eller prylar som funnits där ett tag men inte har synts tidigare. Vissa av dem återkommer kanske lite senare med mer djuplodande analyser.
Jag får erkänna att jag inte hade full koll på Indu-Sol och deras svenska representation Lindh Automation innan jag träffade dem på Scanautomatic-mässan i oktober.
I vilket fall så imponerade deras prylar på mig direkt och de skickade med mig en "PROmesh B8" hem. Det är en managerad 8-portars switch med utvecklat stöd för Profinet och EtherNet/IP. Så här långt verkar den mycket kompetent, men jag ska nyfiket prova lite mer utmanande saker. Det första blir nog att testa integration med PLCnexts engineeringverktyg via definitioner i en GSDML-fil.
Snyggt och tydligt i alla fall! Indu-Sols övriga sortiment ser riktigt intressant ut för den som vill ha hjälp att bygga nät som går att diagnosticera och analysera. Jag rekommenderar en titt på deras övriga produkter också!
Av en slump snubblade jag lite senare över Chris Chungs spännande blogg och YouTube-kanal. Här finns det mycket godis som du kan botanisera i, inte minst tre blogginlägg om Indu-Sols kraftfullare switch-serie PROmesh P10. Mycket nöje:
Tyskt vatten är säkrare!
I Tyskland öppnades nyligen ett gemensamt säkerhetscentrum; "Lagezentrum
CyberSec@Wasser", för landets vattenindustri. Där finns en SOC, Security Operations Center tillsammans med centraliserad sårbarhetshantering och någon form av utbildningsverksamhet.
I Sverige annonserades ju nyligen EnergiCERT som har likheter med det tyska initiativet. Jag tror vattenbranschen i Sverige skulle må väldigt bra av ett sådant här initiativ, det är typiskt verksamheter med mycket begränsade resurser som förvaltar en otroligt viktig resurs! Vad säger ni, ska vi starta en svensk motsvarighet?
Läs förresten gärna den utmärkta sammanställningen som William och Joel på Svensk OSINT gjort kring de svenska dricksvattenincidenterna som vi sett nyligen.
Det där med riskaptit?
En person som jag regelbundet återkommer till i nyhetsbrevet är Phil Venables. Han levererar ideligen kloka texter där det finns mycket att lära. Nu senast hittade jag en text om floskelbegreppet "Riskaptit" som hjälper oss att se igenom det slarviga bruket av det här begreppet och istället hittar lite handfasta råd kring hur man kan skapa verklig nytta. Om inte annat så tydliggörs skillnaden mellan Riskaptit och Risktolerans...
Sjöfart är alltid spännande!
En förmån i mitt arbete är att jag får vara med i intressanta samverkansgrupper. En av dessa är "Maritime Cyber Guild" som träffas ett par gånger om året för att diskutera erfarenheter inom sjöfarten med fokus på OT-säkerhet. Nyligen träffades vi hos BIMCO i Danmark och det blev som vanligt en dag fylld med spännande diskussioner.
Några av punkterna på agendan som jag själv tog med mig lite extra mycket från var:
Resultat från övningar där erfarna besättningsmedlemmar "utsätts" för ovanliga situationer, orsakade av en hacker, i ett simulerat fartyg. De var utrustade med glasögon som registrerade hur de arbetade med felsökningen i fartygets system. Resultatet bekräftade tidigare insikter om att avancerad OT-hacking inte behövs om man på något sätt skaffat sig tillgång till samma system som personalen arbetar i. I exemplet ledde en liten börvärdes-ändring i kylsystemet för fartygets generatorer till att alla fyra generatorer slogs ut samtidigt. En felorsak som i praktiken är väldigt svår att hitta tillräckligt snabbt, även för mycket erfaren personal. Ett fartyg i skärgårdstrafik sitter då redan på klipporna.
DNK, "Den Norske Krigsforsikring for Skib", berättade om cyberförsäkringar kring sjöfart. Försäkringar är ett spännande område som blir ännu klurigare när det handlar om fartyg.
marcybersec.com är en intressant sajt där man bland annat samlar rapportering av sjöfartsrelaterade cybersäkerhetsincidenter.
Diskussioner kring hur meningsfullt det är med penetrationstester tidigt under ett fartygsbygge med tanke på att det lätt blir något som man gör för att "få en bock i rutan" samtidigt som det tenderas att tas mängder med dåliga "genvägar" under tiden system installeras ombord.
Om du är aktiv inom OT-säkerhet med koppling till sjöfart och vill vara med i gruppen så hör av dig. Det är gratis och alltid intressant! mats@ot-sakerhet.se
Sugen på att hacka lite MODBUS?
Pascal Ackerman är en välkänd profil i OT-säkerhetsbranschen, han har bland annat förekommit tidigare i nyhetsbrevet med några av sina välskrivna böcker. I två artiklar som publicerades nyligen gör han en djupdykning i hur man man sätta upp en eget MODBUS-labb för att experimentera i:
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.