Sökresultat

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: Indusol#PROmesh P10+_Part01_Start up your network equipment! Indusol#PROmesh P10+_Part02_Let's Connect to Profinet! Indusol#PROmesh P10+_Part03_Let's access the SNMP Server! 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: Del 1: "Attacking MODBUS" Del 2: "Attacking Modbus, Act 2 - Using Scapy" 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 .

Dags för en maxad utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du reda på nyhetsbrevets framtid, att NIS2 blir ännu mer försenat, varför en OT-SOC är en bra idé, hur det egentligen stod till ombord på skeppet som raserade bron i Baltimore, vi lär oss hur man tänker själv, möter en ny spännande bekantskap i labbet, australiensiska principer för OT, hur man får gratis pengar till säkerhet, vad vi har glömt i NIS2, hur man hackar safety-system i kärnkraftverk, du får en inbjudan till Cybernoden och så kommer ett skepp lastat med mängder av larm. 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å 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! Nyhetsbrevet läggs inte ner! Jag fick en del oroliga frågor om nyhetsbrevets framtid efter att jag berättade på LinkedIn att jag skulle byta arbetsgivare. Men jag kan lugna alla som eventuellt är oroliga, min tanke är att nyhetsbrevet ska fortsätta precis som vanligt. Kanske till och med att det blir lite nytändning tack vare nya intryck och perspektiv i vardagen? Jag arbetar numera på svenska företaget Sectra , ett fascinerande företag som bland annat är känt runt om i världen för supercoola bildhanteringssystem inom sjukvården och för megasäkra kryptosystem . Jag finns i en grupp som jobbar med kritisk samhällsinfrastruktur och då i synnerhet kring en väletablerad tjänst för "Managed Detection and Response" (MDR eller "SOC-tjänst") som är byggd från grunden med OT-säkerhet i fokus. En annan orolig fråga som dykt upp är om jag inte kommer vara tillgänglig som rådgivare längre. Även där kan jag lugna dig om du är fundersam, konsultandet är en fantastiskt rolig del av mitt arbete som jag inte ger upp i första taget. Behöver du stöd, ett bollplank, lite utbildning eller kanske att någon agerar djävulens advokat i en workshop så är det bara att höra av dig! OT-säkerhet är hett just nu, inte minst kopplat till NIS2. Det är klokt att ha etablerat kontakten i förväg, redan innan man akut behöver det där stödet, så att vi kan bli snabba på bollen! En tredje vanlig fråga är "Varför just Sectra"? Det är en fråga som det finns många svar på, men det viktigaste svaret för mig personligen är att jag redan tidigare jobbat nära Sectras vassa medarbetare, så jag vet precis hur stimulerande det här kommer bli. Ett annat, och kanske lite mer grandiost svar handlar om att leva som jag lär. Det handlar om att jag söker mig mot lösningen på just det feltänk som jag tycker har varit allra vanligast hos mina kunder. Jag brukar ta hjälp av det välkända hjulet från NIST Cyber Security Framework för att illustrera vad jag menar. Det handlar helt enkelt om att många organisationer (medvetet eller omedvetet) lägger för mycket av sitt krut på tårtbiten "Protect", vilket ger en rejäl slagsida på säkerhetsarbetet. (Jag har skrivit om detta flera gånger förut, senast i nyhetsbrev 61 .) Sectra har förstås ett uppenbart fokus på att stötta både "Detect" och "Respond" med vår väletablerade MDR/SOC-tjänst. Det finns dessutom väldigt naturliga kopplingar från en bra SOC-verksamhet till att hålla hög kvalitet i asset-information ("Identify") och att ge "Recover" bästa möjliga förutsättningar att återställa en havererad produktion. För att allt detta ska bli effektivt och anpassat till varje verksamhets unika förutsättningar är förmågan att mäta och leda ("Govern") centralt och något som vi gärna stöttar som rådgivare! Nu får det räcka, det här var inte tänkt som en reklam för Sectra utan mer som en förklaring till varför min nya arbetsplats känns som ett väldigt naturligt steg framåt för mig. Det ska bli enormt roligt att utforska OT-branschen med Sectra-glasögon på och jag vet att jag kommer att lära mig massor! Om du är sugen på en riktig OT-SOC så berättar jag förstås gärna mer, oavsett om det är som potentiell kund eller kollega! Nej, det var inte en cyberattack! Du minns säkert den tragiska olyckan i Baltimore när containerfartyget Dali körde ner en bro vilket orsakade sex dödsfall. Genast efter händelsen cirkulerade en massa teorier om att avancerade OT-attacker mot fartygets system var orsaken till att man förlorade kontrollen över fartyget. Nu har U.S. Department of Justice lämnat in en stämning där man pekar på ganska avancerade felgrepp och slarv som ligger bakom att fartygets elsystem slogs ut upprepade gånger. Som synes har man gjort en del "intressanta" modifieringar av fartygets system... Nix! NIS2 kommer inte vid nyår! Det blir mer och mer uppenbart att den nya cybersäkerhetslagen, som skulle implementera NIS2 vid årsskiftet, inte kommer att bli klar i tid. Från källor "väldigt nära händelsernas centrum" har jag fått beskedet att riksdagen kommer få en proposition tidigast under våren 2025 och då lär det inte bli någon lag förrän om ett år. Samma besked ges nu också på MSB:s hemsida . Vi hör liknande signaler även från andra länder, exempelvis Danmark , Tyskland, Spanien och Nederländerna. Det här är förstås synd men betyder förmodligen väldigt lite i praktiken. Med tanke på hur långsamt implementationen går i de flesta organisationer som jag har kontakt med så är det kanske tur? En sak är klar för de flesta, det betyder inte att man kan ta det lugnt med NIS2-arbetet. Vill man ha lite stöd så har MSB precis uppdaterat sin text " Skydd av samhällsviktig verksamhet ". Den innehåller en vettig checklista med vad som kan vara bra att göra men ingenting om hur . En juridisk finess i sammanhanget är begreppet " EU-rättens direkta effekt " som jag ska vara väldigt försiktig med att tolka här med tanke på att jag inte pluggat juridik en enda sekund av mitt liv... Men som jag förstår det så har det slagits fast i rättsfall inom andra områden att ett EU-direktiv gäller som lag i ett land om landet inte har implementerat direktivet i tid. Det har dock en massa begränsningar och verkar framför allt handla om att privatpersoner kan hävda rättigheter som de får via exempelvis ett direktiv. Däremot får inte staten använda ett direktiv som krav på en privatperson. Här får gärna jurister i läsekretsen höra av sig med sina insikter! mats@ot-sakerhet.se Principer från down-under! ASD, Australian Signals Directorate , har publicerat ett kort dokument med 6 principer för OT-säkerhetsarbete. ASD är en myndighet som producerar väldigt bra material och det stämmer även i det här fallet! Man har dessutom förankrat materialet med motsvarande myndigheter i USA, Kanada, Storbritannien, Nya Zealand, Tyskland, Nederländerna, Japan och Sydkorea. I nyhetsbrev #51 skrev jag om ett liknande samarbete kring "Secure by design/default" och nu är det alltså OT-säkerhetens tur! Man kan tycka att det blir lite väl flummigt att komprimera det viktigaste till bara 6 principer men de har faktiskt gjort det riktigt bra och kommentarerna till respektive princip innehåller en del guldägg. Väl värt att titta på! Gratis pengar till säkerhet! Sveriges nationella samordningscenter för forskning och innovation inom cybersäkerhet (NCC-SE) är en del av MSB. De har just nu en utlysning där mindre företag kan få bidrag för cybersäkerhets-åtgärder. De har totalt 23 miljoner att dela ut och man kan få upp till 600 000 per sökande. Det kan handla om att öka kompetensen, att åtgärda risker eller att bättre möta nya krav från EU, exempelvis NIS2, CRA eller någon av alla de andra nya lagarna. Det bortglömda kravet i NIS2! Hysterin kring NIS2 och den kommande svenska cybersäkerhetslagen ökar för var dag som går. Det är förvisso bra med ordentlig uppmärksamhet, men tyvärr hamnar diskussionerna ofta på fel saker. Det tenderar att bli fokus på att uppfylla kraven på säkerhetsåtgärder, vilket i sin tur oftast beror på att diskussionerna startas av leverantörer som vädrar morgonluft. I direktivets artikel 21 finns 10 punkter med säkerhetsåtgärder som anses vara en nedre skamgräns för vad man ska ha på plats. Det nämns till exempel saker som kryptering, multifaktorinloggning och cyberhygien, men också mjuka frågor som incidenthantering, personalsäkerhet, riskanalys, leverantörskrav och katastrofhantering. Allihop är bra krav men de beskrivs extremt kort, i vissa fall bara ett ord (!), så exakt vad som krävs är verkligen inte speciellt tydligt. Det passar förvisso bra ihop med det allmänna kravtänket i NIS2 som kan sammanfattas under parollen "Tänk själv!". Bland dessa 10 punkter finns en som jag nästan aldrig hör diskuteras, men som jag tycker är fantastiskt viktig. Och svår... Det "Strategier och förfaranden för att bedöma effektiviteten i riskhanteringsåtgärderna för cybersäkerhet". Det vill säga, du ska mäta hur effektivt ditt säkerhetsarbete tar hand om dina risker. En bra effektivitet i det här sammanhanget bör ju rimligen betyda att risker sänks mycket i förhållande till vad säkerhetsåtgärderna kostar. Det betyder att vi behöver ha koll på riskerna och säkerhetsåtgärderna samt hur de relaterar till varandra. Det låter ju spontant som ett klokt och viktigt krav. Men vad betyder det i praktiken? Och vad behöver man för att klara det? Och det är här som det geniala med det här kravet blir tydligt! Det tvingar nämligen oss att ha riktigt bra ordning på alla de andra åtgärderna. Men det blir också tydligt att det kan bli väldigt omständligt och tungt... Vi behöver vi förstå vilka risker vi utsätter oss själva och samhället för Vi behöver förstå vilka åtgärder vi har på plats, deras verkliga nytta och vad de kostar Vi behöver förstå vilka åtgärder som i verkligheten påverkar vilka risker Vi behöver förstå vilka risker som orsakas av våra leverantörer och hur våra krav påverkar de riskerna I praktiken kan mätandet uppenbart bli en enorm börda i sig, och det är ju förstås inte meningen. Det finns säkert en massa genvägar man kan ta och förenklade uppskattningar som kan göras. Men vi kommer aldrig undan från att ha ordentlig koll på risker och åtgärder! Men det finns en väldigt stor nytta för den egna organisationen med det här. Om man lyckas väl med detta kan man plötsligt prioritera bland nya och existerande åtgärder baserat på vilken nytta de faktiskt gör. Det är precis det här som behövs när man ber om pengar till ett nytt säkerhetsinitiativ eller ska försvara sin budget! LARM! LARM! LARM! Ett område som på flera sätt angränsar till OT-säkerhet är genomtänkt larmhantering i kontrollsystem, alltså hur man hanterar situationer där ett system inte vet hur det ska bete sig och därför behöver larma en människa. Det här är något som sedan länge är känt som ett viktigt område, men som vanligt går inte teori och praktik alltid hand i hand. Inom sjöfarten har detta seglat upp (!) som ett allvarligt problem på senare år. I takt med att man drar ner bemanningen ombord på fartyg blir larmhantering, på gott och ont, allt viktigare. Lloyds Register har under ledning av Asger C. Schliemann-Haug undersökt situationen för att förstå om den är ohållbar och vad som kan göras för att förbättra den. De har analyserat erfarenheter från 65 vakthavande personer på 15 fartyg från 10 av världens största företag inom sjöfart. Summerat kan man säga att den 182-sidiga rapporten säger att det finns utrymme för förbättring... Om du föredrar det så finns det även en summering på 24 sidor. Jag har tidigare hört en presentation av innehållet på en träff med Maritime Cyber Guild och jag blev helt häpen över hur illa det står till i många fall och vilka skrämmande exempel man tar upp på hur det kan gå! Här finns mycket att lära även för andra branscher. Inte minst kring hur larmhantering inom själva OT-säkerhetsarbetet ska ske för att få snabba reaktionstider och detta utan att bränna ut personalen - något som tyvärr är ett vanligt problem. Det där med att tänka själv... En av höjdpunkterna i den kommande svenska cybersäkerhetslagen är hur man håller koll på säkerheten kring de leverantörer som man är beroende av. Det här är ju ett område där vi minns ett antal spektakulära attacker kopplade till exempelvis Solarwinds och Kaseya. Det är ett område där jag fortfarande hör missförstånd kring vad kraven i NIS2-direktivet egentligen säger. Det vanligaste är nog "Om du är leverantör till någon som omfattas av NIS2 så kommer du automatiskt också omfattas av direktivet". (Så är det ju alltså inte!) Om man vill djupdyka i det här området och de juridiska klurigheterna som hör till, så kan jag rekommendera Vendela Schörlings uppsats  på området. Om du läser noga så kommer du upptäcka att jag haft ett finger med i spelet under arbetet. Du hittar många kloka resonemang kring juridik, riskanalys och ansvarsfördelning. Mycket nöje med läsningen! En trio brandväggar i labbet! Det är knappast en nyhet för någon att bra nätverkssegmentering är grundstommen i de flesta OT-säkerhetsprogram. Om man ska segmentera "långt ut" i produktions-näten behöver man ha utrustning som överlever i sådana fysiska miljöer. Ofta vill man dessutom bygga brandväggsregler på detaljer i OT-protokollen och då behöver man förstås grejor som förstår dem... Det är här de ruggade OT-brandväggarna firar triumfer på egen hemmaplan. Monterade på DIN-skena, drivna med 24 Volt likspänning och fyllda med OT-specifika lyxfinesser är de perfekta att hantera de utmaningar som är vanliga i robotceller, maskiner och andra ställen med grupper av känsliga komponenter. Med rejäla kylflänsar och vibrationståliga komponenter tål de att bokstavligen sitta i händelsernas centrum. I labbet finns nu en spännande trio av dessa brandväggar. Den till höger på bilden känner ni kanske igen sedan tidigare, det är TxOne EdgeFire  som jag skrev om senast i nyhetsbrev #31 . En av mina favoriter, vars kanske starkaste sida är deras virtuella patchning baserad på sårbarhetsinformation från  ZDI, Zero Day Initiativ . I mitten ser du en riktigt spännande nykomling som egentligen "inte finns ännu", det är väletablerade svenska brandväggstillverkarna Clavister  som nu ger sig djupare in i OT-världen med brandväggen "NetWall 200R". Jag har ett förserie-exemplar med serienummer noll (!) som jag kommer att återkomma till i ett framtida nyhetsbrev. Till vänster på bilden sitter dagens huvudperson, en Anybus Defender 6004 DPI FW , en alldeles ny produkt på marknaden - på sätt och vis... Anybus  är ett av varumärkena inom svenska bolaget HMS Networks . HMS är ju något av ett doldis-bolag om man inte är i branschen själv, men du kanske vet att deras produkter går att hitta i fantastiskt många olika sammanhang, inklusive i produkter från andra produkttillverkare. En typ av produkt som HMS inte haft tidigare är OT-brandväggar, men det har de alltså åtgärdat nu. De har faktiskt gjort det på två sätt, dels köpte nyligen HMS Networks det amerikanska företaget Red Lion Controls  och fick då en väldig massa nya och spännande produkter under sina vingar. Men HMS nöjde sig inte där, de har också etablerat ett samarbete med amerikanska företaget Dynics och säljer deras trevliga brandväggar under Anybus-flagg. Det är en av dessa som nu dykt upp i mitt lilla labb, närmare bestämt en " Anybus Defender 6004 DPI FW "... Jag kan direkt avslöja att det här är en riktigt trevlig bekantskap, faktiskt en av mina absoluta favoriter i den här kategorin! I grunden liknar den de flesta produkter av den här typen; ett vettigt webb-gränssnitt där man konfigurerar alla aspekter av funktionaliteten. Har man lite fler enheter finns även programvaran "Anybus Cybersecurity Console" för enklare "mass-drift". Känslan i gränssnittet kan kanske beskrivas som "en avancerad hemmarouter", vilket jag menar som en komplimang och som jag verkligen tycker är bra i det här sammanhanget. Du kommer känna dig hemma oavsett om du är nätverksproffs eller automationsingenjör. Det är lätt att hitta i menyerna och hjälptexterna är extremt bra. De grundläggande funktionerna kring nätverket och de "normala" brandväggsfunktioner är kraftfulla och enkla att få till. Det finns gott om avancerade funktioner under "Advanced"-flikarna om man behöver göra något som är lite utöver det vanliga. I tillverkande industri är vettiga NAT-funktioner viktigt och det finns på plats. Så långt är det två tummar upp från min sida. Hur är det då med funktioner som både tilltalar OT-folket och säkerhetsnördarna? Brandväggsinställningarna har en sektion som heter "Industrial protocols" där man kan bygga regler, regelgrupper och profiler på ett smart sätt. Det finns en "Analysis"-funktion suger i sig inspelad nätverkstrafik och presenterar förslag på regler för att göra det enklare att genomskåda vad som faktiskt behöver ha regler. Riktigt elegant är att man hanterar de här reglerna separat från underliggande IP-regler. Se nedanstående exempel på en regel för MODBUS TCP som struntar i IP-adresser, portnummer etc och enbart filtrerar på ren MODBUS-information. Snyggt! Just nu finns det bara stöd för MODBUS TCP och EtherNet/IP (CIP) på den här detaljeringsnivån men ytterligare ett antal protokoll är redan på väg. Om du har en åsikt om vilka protokoll som vore intressantast att faktiskt kunna filtrera på så får du gärna höra av dig! mats@ot-sakerhet.se Den här produkten är baserad på opensource-brandväggen pfSense som i sin tur bygger på FreeBSD. Att den bygger på pfSense är förstås en stor del av förklaringen till den stora flexibiliteten i produkten. Men det ger också en annan riktigt spännande möjlighet! Genom "Packages" kan man enkelt lägga till väldigt avancerad funktionalitet. I den långa listan hittar du bland annat super-intressanta mjukvaror som: ArpWatch (Reagerar på exempelvis ARP-spoofing) Snort (IDS/IPS) Softflowd (Exporterar nätverksinformation via NetFlow) Squid (Webb-proxy) Suricata (IDS/IPS mm) Wireguard och Tinc (VPN) Zeek (Nätverksanalys) Möjligheterna som ges via Packages är nästan obegränsade och det ska bli spännande att se hur den här delen tas emot av marknaden. Hårdvaran är relativt kraftfull så den pallar att köra avsevärt mer än ren brandväggsfunktion! Om du redan använder det här i någon form av OT-sammanhang så vill jag gärna höra mer! mats@ot-sakerhet.se På det hela taget är det här en fantastiskt intressant produkt! De erbjuder extremt flexibla möjligheter att lösa dina utmaningar utan att gränssnittet känns förvirrande eller komplext. Förhoppningsvis kommer vi se stöd för fler OT-protokoll inom kort och ännu fler möjligheter med "Packages". En detalj som verkligen tilltalar mig är att licenserna är "eviga", alltså ingen oro att någon licens löper ut och stoppar någon viktig funktion! Säkerhetsuppdateringar ingår också på livstid. Vill du höra HMS själva prata om det här så finns exempelvis den här videon med Thomas Vasen på YouTube: En OT-avhandling! Sarah Fluchs är ett välkänt namn i branschen som har varit drivande på många spännande områden, exempelvis i projektet " Top 20 Secure PLC Coding Practices " som jag skrivit om tidigare. Nu har hon levererat sin avhandling som handlar om en visuell modell för att fatta, dokumentera och kommunicera beslut kring hur cyberfysiska system utformas. Vad är annorlunda med utbilda i OT-säkerhet? Ett spännande samarbete mellan ISAGCA, INL, Idaho State University och DOE har resulterat i ett dokument som innehåller en mycket stor mängd kunskaper som de bedömer behöver vara annorlunda i en cybersäkerhetsutbildning riktad mot OT-miljöer jämfört med "vanliga" cybersäkerhetsutbildningar. Och det är verkligen en diger lista de fått ihop, så man måste nog verkligen ta fasta på ordet "guidance" i titeln: "CURRICULAR GUIDANCE: Industrial Cybersecurity Knowledge". Med tanke på att ser ut att börja lossna även i Sverige kring denna typen av utbildningar, så finns det nog en hel del inspiration att hämta här! NIS2 handlar mest om OT-säkerhet! NIS2 trycker på två saker; dels starka nationella strukturer för cybersäkerhet, och dels ”cyber-robust” produktion i organisationer som är viktiga för samhället. Om vi funderar över den där robusta produktionen, så inser vi direkt att de flesta organisationer som ingår i NIS2 producerar något ”fysiskt”. Det är tillverkande industrier, energiproduktion, transporter, dricksvatten, avlopp, avfall, livsmedel och kemikalier. Det är dessutom sektorer som innehåller väldigt många organisationer och där den samhällsviktiga verksamheten är helt beroende av god OT-säkerhet. IT-säkerhet är förstås också viktigt, men samhället kommer inte bry sig så mycket om ert fakturasystem står still eller om din budgetrapport för oktober är otillgänglig. Men om produktionen stannar blir det snabbt problem! Inget ont om banker, kommuner, IT-driftleverantörer, DNS-tjänster och rymdtjänster – de är väldigt viktiga! Men de är betydligt färre och har i de flesta fall relativt moget säkerhetsarbete redan idag. Den stora utmaningen framöver finns därför i organisationer som behöver OT-säkerhet, både för att de tenderar av vara mer omogna och för att de är många fler! Just nu är det många som nyvaket ställer ganska grundläggande frågor kring NIS2 i diverse forum på nätet, exempelvis: ”Vad är det jag behöver göra egentligen?”. Det är förstås en väldigt bra fråga, egentligen precis den fråga som alla behöver ställa sig. Problemet är att man ofta får ett och samma svar tillbaka; ”Det är bara att implementera ISO 27001!”. Svaret är i sig inte fel. Men som nörd inom OT-säkerhet drar det direkt i gång några stora varningsflaggor i mitt huvud. Jag ska vara väldigt tydlig med att jag verkligen gillar ISO 27001 och att jag tror att det är rätt väg för nästan alla organisationer! De där varningsflaggorna hänger mer ihop med de typiska dikeskörningar som jag sett lite för många gånger i organisationer som gett sig på att bygga ett ledningssystem med hjälp av ISO 27001. Flera av dikeskörningarna blir dessutom lite extra allvarliga när det handlar om NIS2 i kombination med OT-säkerhet. En väldigt vanlig dikeskörning är att man fokuserar alldeles för mycket på Annex A i ISO 27001, alltså listan över säkerhetsåtgärder som kan vara relevanta enligt standarden. Jag hävdar att det är den minst viktiga delen av standarden och att den egentligen borde tas bort helt. Det viktiga finns tidigare i dokumentet, kapitel 4 till 10; att förstå organisationens förutsättningar, planering, styrning av säkerhetsarbetet, att löpande utvärdera hur det går och att jobba med ständiga förbättringar. De här dikeskörningarna är ett problem även utan NIS2 och OT-säkerhet, men det tenderar att göra problemet mycket större om man rusar i väg för att implementera klassiska IT-säkerhetsåtgärder. Riktigt bra kan det bli om man kombinerar kapitel 4 till 10 i ISO 27001 med del 2 av IEC 62443. Det kräver förstås lite extra jobb men resultatet kan bli riktigt välanpassat till både IT och OT. Samtidigt! Hur man skyddar ett kärnkraftverk Ruben Santamarta har just publicerat en riktig djupdykning i ett vanligt förekommande skyddssystem för kärnkraftverk. Eftersom jag är "uppvuxen" i kärnkraftsbranschen är jag förstås lite extra nördigt intresserad men det finns godis här för alla! Årets SCADA-Säkerhet har gått av stapeln! I mitten av september spenderade jag två dagar på konferensen "SCADA-Säkerhet" i Stockholm. Som man förstår av det lite ålderdomliga namnet är det en konferens som funnits i ett antal år nu och som samlar en trogen publik. Det var två dagar av föredrag, men kanske framför allt två dagar av riktigt roliga diskussioner med både nya och gamla bekantingar. Ett stort tack till alla jag träffade där för många inspirerande samtal! Favoriterna bland föredragen var nog: Björn Eriksson som är gruppchef komplexa cyberbrott (KCB) på Polismyndigheten som pratade om hur polisen arbetar vid cyberattacker. Hörde många kommentarer efteråt om att det var viktigt att få höra. Jimmy Persson som är utvecklings- och säkerhetschef på Svenska Stadsnätsföreningen pratade om robusthet och fysiskt skydd på ett sätt som jag tror många organisationer kan ha nytta av även i helt andra branscher. Du kan läsa deras anvisningar för fiber och för anläggningar . Anders Jonson som är medlem i ENISA AHWG – EUCS/AI pratade om hur framför allt NIS2 kommer påverka branschen. Ted Strandberg som är projektledare på RISE tog avstamp kring det uppdaterade Radiodirektivet från EU och vad som händer runt om det. Cybernoden! Har du koll på Cybernoden ? Om inte så tycker jag du ska titta närmare och om din arbetsgivare inte redan är medlem så är det faktiskt gratis! Den officiella förklaringen av vad Cybernoden är: " Cybernoden är Sveriges nationella kompetensgemenskap inom cybersäkerhetsforskning och innovation och drivs av RISE på uppdrag av NCC-SE inom ramen för ECCC, och är finansierat av Vinnova. " Det finns en lång radda temagrupper, så det finns garanterat någon som passar oavsett vilken typ av säkerhetsarbete du är intresserad av! Men den roligaste gruppen är förstås " Säkerhet i ICS/OT " som jag och Thomas Vasen leder! Hör av dig om du vill vara med och bidra till diskussionerna! ( mats@ot-sakerhet.se ) ENISA har inte så mycket fokus på OT? EUs cybersäkerhetsmyndighet ENISA har just publicerat " ENISA Threat Landscape 2024 ", deras analys av hotläget mot EU och världen. Rapporten är intressant i sig, men ännu mer intressant kan det tyckas att OT-säkerhet nämns exakt en enda gång i ett dokument på 131 sidor... Men? Vem är det som kör egentligen? Välkände profilen Joe Weiss har publicerat ett 24-sidigt dokument under rubriken "Who’s in charge of OT security?" där han skriver kloka saker kring den "eviga frågan" om hur vi ska få IT och OT att fungera bra tillsammans. NSSS24 och CRA I slutet av september gick konferensen Nordic Software Security Summit av stapeln i Stockholm, organiserad till största delen av Olle E. Johansson. Jag var inte där själv men har förstått att den var mycket uppskattad av deltagarna. Något som kan intressera läsarna av det här nyhetsbrevet var Filipe Jones Mourao från Europeiska Kommissionen som i sin keynote-dragning berättade om läget kring Cyber Resilience Act, CRA: Vem är Mats? Jag är till vardags 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 .

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du bland annat läsa om vad OT-branschen kan lära sig efter Crowdstrike-händelsen, vad ordet proportionalitet betyder, den svenska energibranschens nya CERT, nya detaljer kring krav i NIS2, attacker mot MODBUS TCP, fysiskt skydd av dricksvatten och hur aerodynamik spelar roll för OT-säkerhet. 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å 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! Svensk EnergiCERT bildas! Fem svenska energiföretag har tillsammans bildat "EnergiCert". (CERT är en förkortning av " Computer Emergency Response Team") Det är Jämtkraft, Vattenfall, Fortum, E.ON Sverige och Uniper som tar det här steget för att gemensamt förebygga och hantera cybersäkerhetsincidenter. Det är inte så mycket som är officiellt ännu mer än identiska pressreleaser från Jämtkraft och Vattenfall . Detta är ett samarbete mellan fem pionjärföretag men siktet är inställt på att skapa möjligheter för hela energibranschen. Vi har nyligen etablerat grunderna för partnerskapet och planerar att rekrytera en vd till hösten, säger Håkan Hagberg, säkerhetsansvarig för Jämtkraft AB.  Det här är ett riktigt bra steg som kan leda till många bra saker. Vi har sedan länge sett liknande initiativ i andra länder, inte minst InfraCERT/KraftCERT i Norge, som verkligen gjort nytta. Där hände det igen... Jag kan väl inte låta bli att kommentera Crowdstrike-incidenten även om det kanske redan är lite tjatigt? Jag ska i alla fall inte dyka i detaljerna kring vad som hände, det har andra redan gjort mycket bättre. Men det verkar klarlagt att det var en uppdatering av detektionsreglerna ledde till att säkerhetsprogramvaran Falcon från Crowdstrike kraschade de Windows-system som använde den, vilket fick enorma konsekvenser runt om i världen - både inom IT och OT. Vi som varit i branschen ett tag minns att det hänt förut, mest känd är väl McAfee som fick liknande problem 2010 . Lite extra tråkigt för Crowdstrikes VD George Kurtz som var CTO på McAfee förra gången... Det är en liten bransch... Helt klart är att QA-rutinerna på Crowdstrike kommer få en upprustning efter det här... En diskussion som genast uppstod var kring patchrutiner och hur viktigt det är med solida testrutiner innan man släpper in uppdateringar i sin systemmiljö. Nu var det ju inte en uppdatering av mjukvara i det här fallet, utan "bara" definitionsfiler vilket ju gör det hela lite klurigare... (Det var för övrigt precis samma sak som hände McAfee 2010, då var det av deras DAT-filer som ställde till det och nu var det en Channel-fil från Crowdstrike.) Det är nog många som kommer inkludera möjligheten till att provköra den här typen av uppdateringar i sina kravspecifikationer framöver! Och med rätta, det här är helt avgörande inom både IT och OT! Det behöver inte finnas ondskefulla hackers för att det ska bli riktigt jobbiga konsekvenser! De flesta "OT-incidenter" jag hört om i det här sammanhanget har orsakats av för starka beroenden till IT-världen, även om Falcon definitivt förekommer på OT-system också. Det som störts har varit kopplingar till affärssystem, utskrifter som går via system på "IT-sidan", delade administrationsmiljöer eller gemensamt Active Directory. För mig bekräftar det här en av mina gamla käpphästar som jag envisas med att tjata om så fort jag får en chans; satsa inte för mycket av dina resurser på att förebygga problem och attacker. Du behöver en rejäl förmåga kring att hantera jobbiga incidenter oavsett vad som orsakade dem. Det är de tre "bortglömda" delarna i cirkeln från NIST CSF: Detect, Respond och Recover: Detect - Här finns mycket att lära av "IT-folket"! Detect är inte bara att upptäcka attacker, utan även generell övervakning av system och nätverk. Gärna med bra loggning och inspelning så att det går att analysera vad som hänt i efterhand. Respond - Gammal hederlig krisledning och förmågan att få ihop rätt kompetens och tillräckligt med resurser när det "smäller". Mycket fokus på att öva! Recover - Här får man bygga från grunden så att man kan ta hand om alla typer av problem: brand, kraschade system eller infektioner. Lite enklare att hantera i enstaka system men mycket mer utmanande om det drabbar ALLA system... I OT-världen är mycket av det här väldigt svårt eftersom system ofta levereras och installeras av leverantörer. Den egna personalen har väldigt liten chans att hantera jobbiga situationer själv, samtidigt som leverantörernas personal snabbt blir otillgängliga om många kunder drabbas samtidigt... Här finns några att de största utmaningarna för den som behöver jobba med säkerheten i sina leverantörskedjor, oavsett om det är på grund av NIS2 eller för att det är en bra idé ändå... Och apropå NIS2, det finns ingenting i NIS2 som fokuserar specifikt på säkerhetsincidenter som orsakats av elaka hackers. Man pratar om "Incidenter" och "Allriskansats", med andra ord är allt som kan hota produktionen i fokus, vilket gör förmågan att effektivt hantera alla former av störningar avgörande. En del av detta är förstås också att bygga sina system på ett sätt som tål störningar och där det går att "provköra" uppdateringar av alla slag. Hör gärna av dig till mig ( mats@ot-sakerhet.se ) med dina tankar, insikter eller funderingar. Om du i förtroende vill berätta om er incident så är jag förstås väldigt intresserad. Ett bortglömt ord i NIS2... I diskussioner kring NIS2 fokuseras det oftast (ganska naturligt) på att höja säkerheten och hur dyrt eller jobbigt det kommer bli. Det blev dessutom "ännu värre" när den svenska utredningen föreslog att hela organisationen ska omfattas av cybersäkerhetslagen även om bara en del av verksamheten egentligen berörs av direktivet. Det jag tycker många missar är att ordet "proportionerlig" hela tiden används kring säkerhetsåtgärder. Det betyder förstås att man ska ha rejäla säkerhetsåtgärder för att komma åt allvarliga risker. Men det betyder också att man absolut kan ha mindre omfattande åtgärder för de verksamhetsdelar som inte orsakar stora risker för den egentliga NIS2-verksamheten. Mer säkerhet är inte alltid bättre, se till att hushålla med resurserna så att de får göra maximal nytta där det behövs mest! Men det förutsätter förstås att man faktiskt gör jobbet som krävs för att förstå riskerna! Utan att veta om de största riskerna kan vi inte heller veta om de minsta... Det kräver både kunskap och mod att göra det här ordentligt. Det är precis som med ordet "Prioritera". Det tenderar bara användas när man tycker något är extra viktigt, men den riktiga utmaningen är att kunna våga peka på vad som är mindre viktigt ! Om allting är viktigt så är ingenting viktigt! Varför patchning är svårt? En kort och enkel artikel av Anrei Mungiu som snyggt sammanfattar varför patchning är utmanande. Jag gillar speciellt ansvarsfrågan kring vems fel det är om det strular men också att man tenderar att enbart fokusera på operativsystem! En guldgruva för Safety! Jag råkade snubbla över en stor mängd gratis publikationer från Springer , där bland annat spännande forskningsartiklar går att läsa alldeles gratis. De har även sammanställt besläktade artiklar i böcker, exempelvis hittade jag en samling böcker kring " SpringerBriefs in Safety Management ", där exempelvis boken " The Coupling of Safety and Security " ingår. Du kan ladda ner dem gratis som pdf eller epub. Om du sysslar med Safety-frågor finns exempelvis också böcker med titlar som: Exploring Resilience Risk Communication for the Future Compliance and Initiative in the Production of Safety The Regulator–Regulatee Relationship in High-Hazard Industry Sectors Human and Organisational Factors Och mycket annat... Syra i ditt nätverk? Om du använder Zeek (ett ramverk för nätverksövervakning och IDS) i dina OT-nätverk, så kan CISAs nya projekt "ACID" , "ATT&CK-based Control-system Indicator Detection for Zeek" kanske vara intressant att titta lite närmare på. Det ger möjlighet att upptäcka och reagera på viktiga händelser kopplade till PLC:er, som synes i tabellen. Än så länge har det bara stöd för tre protokoll: S7COMM, ENIP/CIP och BACnet, men det är baserat på ett annat projekt från CISA, ICSNPP , som har stöd för många fler. Vi kan nog lugnt räkna med att fler protokoll kommer läggas till efter hand. Conny reder ut begreppen kring ISA-95 och Purdue! Trogna läsare har förmodligen redan sett mina tidigare texter om de allt för vanliga missförstånden kring Purdue-modellen och tillhörande standarder. Jag snubblade över en kort artikel av Conny Jakobsson där han reder ut begreppen, missförstånden och historiken på ett riktigt bra sätt! Förhoppningsvis kan den hjälpa en eller annan att använda rätt modell till rätt behov framöver. Vad är nästa stora grej? Dale Peterson resonerar kring vilket produktområde inom OT-säkerhet som kommer bli nästa stora grej nu när Detection-marknaden börjat sätta sig. Han tar upp remote access för OT, SBOM för OT och OT Cyber risk management. Som vanligt håller jag med honom i både resonemanget och slutsatserna! Ett facit för NIS2! Nä... Så är det inte riktigt, men det är en så kallad " Genomförandeakt ", alltså ett dokument kopplat till NIS2 där Europeiska Kommissionen beskriver sina förväntningar på hur man möter kraven i NIS2 på ett rimligt sätt. Det som har kommit nu är en remiss , alltså att vi får skicka in åsikter om akten som består av ett huvuddokument och en bilaga. Fokuset är inte på typiska OT-verksamheter utan exempelvis DNS-tjänster, cloud-tjänster mm men även managerade drifttjänster och managerade säkerhetstjänster som definitivt kan vara relevanta för en OT-verksamhet. Dessutom kan man se lite hur tänket ser ut vilket man förstås kan dra slutsatser av även för mer OT-nära organisationer. I samma veva får vi också detaljerade definitioner av vad en incident är och i synnerhet vad en "betydande incident" betyder. (Det är just "betydande incidenter" som ska anmälas.) Slarvigt sammanfattat så är det när en incident matchar minst en av: Kan orsaka finansiell skada på minst 100 000 Euro eller 5% av årlig omsättning. Kan orsaka skada på verksamhetens rykte. (Exakt vad detta innebär definieras också.) Kan orsaka att verksamhetens företagshemligheter stjäls. Kan orsaka dödsfall eller allvarliga skada på en människa. Ej behörig tillgång till nätverk eller system har inträffat som misstänks vara i ont uppsåt. Upprepade säkerhetsincidenter som inträffar inom 6 månader eller som har samma grundorsak. Specifika problem beroende på vilka tjänster som påverkats: DNS-tjänster, Toppdomäner, Molntjänster, Datorhallstjänster, Innehållstjänster, Managerade tjänster, Managerade säkerhetstjänster, Marknadsplatser, Sökmotorer, Sociala nätverk eller identitetstjänster. I en bilaga får vi lite mer detaljer kring hur säkerhetskraven ska utformas, helt fokuserat på de minimikrav som finns i NIS2-direktivets paragraf 21. Det som i mina ögon är fantastiskt bra är att man nöjer sig med att definiera vad man ska göra men inte hur . Å andra sidan är det relativt detaljerat, exempelvis räknas hela 13 områden upp som ska definieras i organisationens säkerhetspolicies. Här vet jag att det finns olika åsikter om hur det borde vara, men jag är personligen helt på linjen att det absolut bästa med NIS2 är att den inte definierar krav som är "Check-In-The-Box" utan att man faktiskt måste tänka själv och göra säkerhetsarbetet på riktigt! Det blir naturligtvis mer utmanande men resultatet är definitivt värt det. Jag hoppas verkligen att de svenska tillsynsmyndigheterna inte kommer "förstöra" det här genom att göra för detaljerade föreskrifter i sina sektorer! Högst personligen ger jag två tummar upp för kravnivån, exempelvis kring det snåriga området riskhantering. Tittar man speciellt på områden som är kluriga för OT-folket så är några favoriter att: Konfigurationer ska dokumenteras, styras och övervakas. Säkerhetstestning ska genomföras regelbundet men också vara en del av utvecklingsprocesserna. Styrd hantering av ändringar och underhåll. Patchning kan man välja att låta bli om nackdelarna är större än nyttan. Fjärrarbete ska vara uppstyrt. Nätverk ska vara segmenterade. Kraven rimmar faktiskt ganska bra med tänket i IEC 62443 och inkluderar även hänsyn till Safety-utmaningar. Extra guldstjärna till kravet att separera systemadministration till egna nät! Sårbarhetsannonseringar från systemleverantörer ska löpande utvärderas. Kraven på utbildning i säkerhetsförståelse inkluderar leverantörer av produkter och tjänster. Samma sak gäller för krav på bakgrundskontroll. En personlig favorit från NIS2-direktivet är att man ska mäta hur väl säkerhetsarbetet fungerar. Även detta kläs i lite mer detaljer nu och på ett bra sätt dessutom. Det kommer fortfarande vara en svår puck för de flesta men otroligt nyttig! Frostigt i Ukraina! Vännerna på Dragos har annonserat att de utrett incidenter i Ukraina där en ny skadlig kod, döpt till FrostyGoop, använts för att manipulera fjärrvärme i Lviv. Det "nya" i sammanhanget är, förutom att själva koden är ny, att man manipulerat en fysisk process genom att prata MODBUS TCP med aktiv utrustning och på så sätt manipulerat mätvärden och annat. Det här är i sig kanske inte så anmärkningsvärt men när man betänker att väldigt många system baserade på MODBUS TCP är dåligt skyddade (eller till och med anslutna direkt till Internet) så sätter det tonen för vad man kan ana är på väg... De noterar också att verktyget är väldigt enkelt uppbyggt, vilket kanske inte är så förvånande med tanke på att det är enkla funktioner som ska manipuleras... Tyvärr blir ofta reaktionen "Men hur kan man använda oskyddade nätverksprotokoll?", vilket förvisso är en riktig observation men jag kan ändå tycka att det är fel slutsats. Det här är en välkänd begränsning så om man vill använda sådana protokoll (vilket det ibland finns goda skäl till) så får man bygga sin säkerhet på andra sätt. Med det sagt så kan jag väl tycka att det är dags att faktiskt börja använda de säkra varianter som faktiskt finns tillgängliga sedan länge ! Som alltid finns det en mänsklig sida på det här, i synnerhet bland de som drabbades av attacken. Om jag förstod det rätt utfördes attackerna mot den ukrainska fjärrvärmen i Januari, vilket förstås är mitt i smällkalla vintern. Jag kan tycka att Rob Lee på Dragos uttryckte sig mycket lämpligt i ett inlägg på Linkedin ... Ett nytt sätt att orsaka fysisk skada... Det finns många spännande publikationer! En ny för mig var " Journal of Wind Engineering and Industrial Aerodynamics " där jag nyligen hittade ett forskningspapper med den något otippade titeln " On the cybersecurity of smart structures under wind ". Miguel Cid Montoya, Carlos E. Rubio-Medrano och Ahsan Kareemhar har tittat på den intressanta attack-vektorn som uppstår när fysiska konstruktioner som är utsatta för vind har aktiva skyddsmekanismer. Exempel är tydligen långa broar, höga byggnader, vindkraftsnurror och stora solpaneler. Det här var ett för mig okänt område inom OT-säkerhet, vilket är en av anledningarna att jag är aktiv i det här området - det finns så många spännande sätt att använda cool teknik! Cybersäkerhet för fartyg inom EU? EMSA, European Maritime Safety Agency, vilket alltså är EUs myndighet för säkerhet inom sjöfarten har gjort en bra och tydlig sammanställning av de regler och ställningstaganden som EU gjort kring cybersäkerhetskrav för fartyg och inte minst hur detta område ska inspekteras. Det där är inte speciellt snällt! Jag snubblade över en rapport som FOI gav ut förra året på uppdrag av Myndigheten för psykologiskt försvar: "Diaspora och påverkan från främmande makt" . Obehagligt och väldigt aktuellt ämne som alla "säkerhetsmänniskor" behöver ta till sig. MEN! Vi ska verkligen se upp så vi inte blir fullständigt paranoida, samtidigt som det här är verkliga och vardagliga hot som dessutom är ruskigt svåra att skydda sig mot. I rapporten har man fokuserat på beteendet från Iran, Kina, Eritrea, Syrien och Ryssland. Arbetar du inom verksamheter som är viktiga för samhället är det här viktig läsning! Chatham House om kärnkraftens cybersäkerhet För de flesta är nog Chatham House annars mest känd för " Chatham House Rule ", men nu har de släppt en forskningsrapport som tittar på den civila kärnkraftsvärlden ur ett cybersäkerhetsperspektiv; " Cybersecurity of the civil nuclear sector Threat landscape and international legal protections in peacetime and conflict ". Inte minst kopplat till intresset för att bygga små reaktorer, "SMR" och hur detta påverkas av krigshändelser i omvärlden. Intressant! Återstående eller inneboende? Som alltid, en intressant artikel av Sinclair Koelemij kring skillnaderna i att bestämma "Återstående risk" kontra "Inneboende risk". Väldigt relevant for OT-världen och med en tydlig koppling till metoderna i 62443-standarden. Inte nytt, men bra! ISA uppdaterade förra året deras kompakta guide-dokument " Industrial Cybersecurity for Small- and Medium-Sized Businesses " som är en riktigt bra start för den som är osäker på hur man lägger upp sitt säkerhetsarbete för att komma igång. Det är bara 14 sidor att läsa men de lyckas ändå sätta bakgrund och prioriterade åtgärder på ett tydligt sätt. Rekommenderas! Glöm inte S4! Missa inte att det löpande släpps videos från årets S4-konferens. När detta skrivs är vi uppe i över 30 stycken . Jag ska inte ge mig till att peka på någon favorit, de håller sanslöst hög kvalitet allihop! (Biljetterna till nästa år släpps 16:e september...) Man glömmer så lätt... Phil Venables skriver ofta kloka texter. Senast läste jag en text med titeln " Why Good Security Fails: The Asymmetry of InfoSec Investment " som är otroligt relevant för OT-säkerhet! I grunden handlar det om utmaningen som uppstår om man bedriver ett bra säkerhetsarbete, nämligen att man får färre problem som motiverar att man arbetar med säkerhet! Det påverkar både hur mycket resurser som görs tillgängligt men förstås även vad folk är motiverade att arbeta med! En speciellt viktig poäng som han också tar upp är det som kallas " Chesterton's Fence ", som enkelt uttryckt innebär att man (som person eller organisation) glömmer bort varför man införde en åtgärd. När åtgärden senare mest ses som ett hinder blir det lätt att den rationaliseras bort. En helt annan typ av lag! Det är mycket snack om lagar nu, inte minst från EU... Men en helt annan typ av lagar är de som förklarar hur någonting i vår omvärld fungerar och som vi kan lära oss någon av. Nu tänker jag inte på tyngdlagen eller något annat fysikaliskt utan lite mer "filosofiskt"... En lag som jag inte hade koll på men som jag kände igen mig i direkt är "Goodharts lag". Förenklat säger den "När du använder ett mätetal som ett mål så slutar det vara ett bra mätetal". Du har säkert varit med om varianter på detta när man vill utveckla något slags verksamhet genom att sätta utmanande mål. Man hittar någonting som går att mäta och som verkar indikera vår förmåga på ett bra sätt. Men ganska snabbt märker man att det spårar ur, exempelvis för att folk börjar fokusera enbart på vissa saker eller att mätetalet helt enkelt inte fungerar i andra situationer. I en text från 2019, skriven av David Manheim och Scott Garrabrant , beskriver de fyra varianter på varför det går snett. Perfekt läsning och bra inspiration för den som vill mäta och sätta bättre mål för sitt säkerhetsarbete framöver! Om inte annat så är det ju faktiskt ett lagkrav i NIS2 att man ska mäta sitt säkerhetsarbete... Vill du gå ännu längre finns en blogg-text av den alltid intressante Phil Venables som tar upp tio lagar kring teknikutveckling. Allt från de välkända Moore's lag och Murphy's lag till lite mer okända (men bra) som Hyrums lag och Conways lag. Där finns även några som är direkt applicerbara på säkerhetsfrågor, speciellt Wirths lag, Hyppönens lag och Venables lag. Många synpunkter på Cybersäkerhetslagen! I förra nyhetsbrevet berättade jag att jag skrev ett personligt svar på remissen av nya Cybersäkerhetslagen, den som ska möta kraven i NIS2. Förutom de 163 andra svar som är listade på försvarsdepartementets sida kan man förstås alltid begära ut de 41 övriga svaren som skickats in på remissen... Tittar man i den listan ser man att jag inte är helt ensam om att vara nördig nog att skriva ett personligt remissvar, vi är tre stycken individer... Det finns många kloka tankar även bland dessa 41 svar men som inte får samma synlighet som de 163. Lite synd kan jag kanske exempelvis tycka om Kungliga Musikskolan som bland annat pekar på det lite orimliga att en liten högskola som forskar kring musik omfattas av lagens krav. Jag hade kanske förväntat mig lite fler nödrop från andra verksamheter som kommer omfattas, men som man spontant kan tycka är lite i överkant att kräva den här nivån av skydd för. Roliga exempel som jag tänker på är tillverkare av barnvagnar, kanoter, shoppingvagnar och spelkonsoler. Det kan ju vara så att de inte finns i Sverige eller att de helt enkelt inte insett att de omfattas ännu... Cybersäkerhet eller fysiskt skydd? En rad uppmärksammade inbrott i dricksvattenanläggningar i Finland påminner oss om hur viktigt det är att det fysiska skyddet av många anläggningar matchar OT-säkerheten och hur viktigt det är att exempelvis inbrott utreds ur perspektivet "Var det manipulation av system även om det maskerats som stöld?". Kloka tankar kring nätverksswitchar En artikel av James Mulford med titeln " 10 Basic Switch Features to Improve Your Industrial Security " listar 11 (!) kloka råd för den som sätter upp nätverksswitchar för OT-miljöer. Vissa av råden vet jag att det finns lite olika åsikter om, men personligen håller jag med om allihop. Vissa råd är dessutom väldigt viktiga av andra skäl än klassisk säkerhet, framför allt tänker jag då på råden kring VLAN och kring IGMP Snooping. Nu tar vi nästa steg? I många sammanhang är det en utmaning att kunna installera säkerhetslösningar tillräckligt "nära" styrsystemen. Det kan vara på grund av svårigheter att få tillgång till nätverkstrafiken, platsbrist i skåpen eller helt enkelt kostnaden för mer utrustning. Det påverkar ofta vilka typer av information vi kan samla in och vilka typer av incidenter vi kan upptäcka. En tanke som jag själv har utforskat i en del kunduppdrag är hur man skulle kunna utnyttja den nya funktionalitet som börjar dyka upp i PLC:er från allt fler tillverkare, nämligen att köra andra typer av applikationer utöver än de klassiska "styr och mät"-delarna. Rimligen finns här en möjlighet att integrera säkerhetslösningar väldigt nära processen? Nu verkar Nozomi vara på väg med en variant på precis detta! De har annonserat att deras ARC-lösning kommer i en variant, "ARC Embedded", som går att köra i en PLC. Till en början i Mitsubishis produkter i serien MELSEC iQ-R, men en personlig gissning är att vi kommer se detta i PLC:er från fler tillverkare framöver. Det borde rimligen vara enkelt i andra produkter med liknande stöd - exempelvis PLCnext från Phoenix Contact eller Beckhoffs controllers. När detta skrivs finns inga offentliga detaljer att prata om, så jag ber att få återkomma... Tankar kring robusthet i tillverkande industri En artikel från World Economic Forum med några tankar på hög nivå kring hur tillverkande industri kan bygga en kultur där cyber-robusthet är högt på agendan. Det här är ett område som man inte ska underskatta, inte minst om man tänker sig möta kraven från exempelvis NIS2. Det är inte ekonomiskt rimligt att förebygga alla former av cyberhot, så då får man fokusera på en lagom kombination av förebyggande skydd och förmågan att hantera incidenter på ett sätt som inte raserar verksamheten. Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT. 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 .

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du två spännande produkter som varit i labbet, jag bevisar att jag är en nörd, lite gnäll över hur Purdue används, vi hittar förändringar i NIS2, jag läser en gammal bok med nya ögon och så vill tydligen Rockwell att vi kopplar bort deras grejor från Internet! 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å 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! Statistik och röster från verkligheten... Jag blir sällan imponerad av alla de statistik-rapporter som alla de stora produkttillverkarna tar fram för att visa hur farlig världen är och hur viktigt det är att vi köper just deras produkter. Ibland kommer det undantag... Jag hittade faktiskt en del intressant i "2024 Threat Report - OT Cyberattacks with physical consequences" från Waterfall och i "Security Navigator 2024" från Orange. Jag ska inte ge mig på att tolka deras analyser här, men kan exempelvis tipsa om när Dale Peterson intervjuar Andrew Ginter från Waterfall: Det verkar förresten som att lyckade attacker som inleds via "elaka länkar" i mejl tydligen nästan helt har upphört? Jag hör från folk som sysslar med incidentstöd till organisationer som drabbats att så gott som 100% av ransomware-fallen de senaste månaderna inleds genom attacker mot vanliga VPN-tjänster. Det har ju onekligen varit en strid ström av allvarliga sårbarheter i just sådana senaste året. Det här är förstås ett superstarkt argument för att skaffa något annat än "en vanlig VPN". I OT-världen vill man ju ofta dessutom ha lite funktionalitet som inte finns i IT-världens lösningar. För ett bra exempel se min text om Cyolo i Nyhetsbrev #59. Och på sjön... Ett av mina specialintressen är OT-säkerhet inom sjöfarten. Jag har skrivit tidigare om de kommande regelverken som klassningssällskapen tar fram och som börjar gälla fullt ut i sommar. Nu börjar även certifierade produkter dyka upp, exempelvis gav DNV nyligen tumme upp till "Vessel Insight" från Kongsberg Digital baserat på DNV Cybersecurity Profile Level 1 (SP1) och IACS UR E27. Det här är en spännande utveckling inom ett väldigt roligt område av OT-säkerhet där säkerhetsarbetet har ytterligare lite fler utmaningar jämfört med "vanlig" OT-säkerhet på landbacken... NIS2 har ändrats! NIS2-direktivet finns, precis som de flesta viktiga EU-dokument, översatta till 24 olika språk. Det betyder förstås att det alltid dyker upp språkliga missar efterhand. För vårt kära NIS2-direktiv är vi just nu uppe i 4 uppdateringar som ändrar på små, och ibland större saker, i texten. Den svenska versionen fick en intressant ändring i uppdatering nummer 4 och berör outsourcade verksamheter. Notera att det alltså är olika ändringar på de olika språken även i samma uppdatering. Uppdatering 1 (Italienska och Nederländska) Uppdatering 2 (Nederländska) Uppdatering 3 (Slovenska) Uppdatering 4 (Tyska, Estniska, Engelska, Italienska, Ungerska och Svenska) Apropå uppdateringen kring outsourcing... Det här med att alla former av MSP- och MSSP-tjänster i sig omfattas av NIS2, är ett bra exempel på en av de branscher där det inte känns som polletten har trillat ner hos alla. Om du sysslar med drift eller säkerhetsövervakning av någon form av IT- och OT-prylar åt andra organisationer så omfattas du av NIS2. Det finns fler polletter som inte ramlat ner överallt, exempelvis att man inte löser utmaningar kring NIS2 med produkter. Inte heller att det kommer en checklista med saker du måste göra. Det hindrar inte att många påstår detta, vilket fick mig att nyligen skriva det här inlägget på LinkedIn: Det kommer bli intressant att se hur tillsynsmyndigheterna väljer att utforma sina föreskrifter. Personligen hoppas jag att man inte "förstör" chansen som direktivet och Cybersäkerhetslagen ger oss där man kan fokusera åtgärderna där de gör mest nytta för den egna organisationen men förstås då också tvingas tänka lite själv och att bygga upp kompetens kring risk- och säkerhetsarbete... En gammal goding... Jag får regelbundet frågor i stil med "Varför gillar du inte Purdue-modellen?" och mitt svar brukar lika regelbundet bli något i stil med "Jag har inget emot Purdue, men väldigt många har missförstått den." Jag har varit inne på detta många gånger förut i nyhetsbrevet. Den bästa förklaringen kring det här som jag hört är fortfarande från Ralph Langner: Jag rekommenderar verkligen att du ser videon, det tar under 10 minuter. Om du sedan inte håller med vill jag verkligen höra varför! mats@ot-sakerhet.se Några personliga kommentarer: Segmentering är inte bara en nätverksfråga. Se upp med hur applikationer sträcker sig över segmenteringsgränser. Ett vanligt exempel är Active Directory som lätt blir en kortslutning mellan separata zoner som delar samma AD-tjänster. "Utvecklade" versioner av Purdue-modellen har en DMZ-nivå mellan IT och OT. Det är absolut en bra idé att undvika direkt kommunikation mellan dessa världar. Men, på samma sätt som att "Nivå 2" inte ska uppfattas som ett stort nätverk är inte DMZ-nivån heller ett enda nätverk! System i ett DMZ är extra utsatta och ska definitivt inte kunna prata med varandra i onödan! Min rekommendation är att använda något slags variant på "Zones & Conduits" enligt IEC 62443. Man måste inte nödvändigtvis använda den komplexa metoden för riskanalys som beskrivs i del -3-3 av standarden! Notera förresten också att Purdue-modellen inte existerar i 62443-standarden, mer än som ett exempel på möjliga arkitekturer. Något som sällan diskuteras i det här sammanhanget är nätverk och system som "måste" ha kontakt med många andra komponenter. Varifrån administreras dina switchar? Hur tas backuper? Administration av hostar och lagring för virtualisering? Kan säkerhetssystemen bli en risk i sig själva? Sist men inte minst... Den ultimata kortslutningen i många segmenterade nätverk, remote access! Här vill det verkligen till att tänka hela vägen! Vilka risker kan vi stå ut med? Hur ska vi göra nu när vi insett att en vanlig VPN är direkt olämplig? Hur bevisa att man är en nörd? Med tanke på hur mycket i mitt arbete som kretsar kring NIS2 just nu, så kunde jag inte låta bli att skicka in ett personligt remissvar till försvarsdepartementet kring förslaget till den nya "Cybersäkerhetslagen"! Remisstiden gick ut den 28:e maj! Jag misstänker att inte alla håller med om mina åsikter, så ta chansen att säg emot! Eftersom jag inte formellt är ombedd att svara på remissen så går det inte att se mitt svar på Regeringskansliets hemsida, men du hittar min text i ett inlägg på LinkedIn. Det finns mycket bra att säga kring både NIS2-direktivet och den föreslagna Cybersäkerhetslagen. I mitt svar fokuserade jag på 6 saker som jag tycker kan förbättras men som inte fått den rätta uppmärksamheten: Lagen sägs syfta till hög cybersäkerhet vilket jag tycker är ett lite inavlat sätt att se problemet. Det borde handla om att hantera samhällets risker som orsakas av brister i cybersäkerheten. Säkerhet har sällan något egenvärde! Den svenska utredningen tog bort den viktiga poängen att säkerhetsåtgärder måste vara lämpliga för sitt användningsområde. Otroligt viktigt inom OT att vi inte använder åtgärder som är farliga för verksamheten! En av mina stora käpphästar är att kemikaliesektorn definierats som att den inkluderar alla verksamheter som använder kemikalier för att producera andra varor. Det blir väldigt många industrier det! Stora organisationer som till 99.99% inte omfattas av Cybersäkerhetslagen men som har 0.01% av sin verksamhet som gör det måste uppfylla lagens krav i hela verksamheten. (Skaffa inte solceller!) Känns inte riktigt rimligt... En annan av mina käpphästar är att orden "tak" och "trösklar" anses betyda samma sak när man definierar övre och undre gränser för storlekar. Så var det inte på mina svenska-lektioner... Vissa sektorer får tillsyn och föreskrifter från fyra olika länsstyrelser. Vore ju snyggt om det blev lite samordning där... Några av dem (3 och 5) är problem redan i direktivet men skulle möjligen kunna tydliggöras i den svenska lagen. Spanskt besök i labbet! Jag har märkt att många läsare är lite extra intresserade när jag får chansen att berätta om mina äventyr med roliga saker i OT-labbet. Det tar ju förstås en hel del tid, så det blir lite långt mellan gångerna jag har något att skriva om. Den här gången är det lite extra roligt... Det är inte varje dag jag får chansen att testa en spansk OT-säkerhetsprodukt, men idag är en sådan dag! Det är företaget Opscura som med produkten Lunaria löser utmaningarna kring att segmentera och övervaka OT-nätverk på ett nytt och spännande sätt! Deras mjukvara tar utgångspunkt helt och hållet i begreppen "Zones" och "Conduits" som vi känner igen från vår favoritstandard IEC 62443. Deras grepp bygger på att man kan låta sina nätverksprylar vara kvar mer eller mindre utan förändring. Istället stoppar man in en liten ruggad dator på de platser i nätet där det ska finnas en eller flera Zoner. Dessa datorer som kallas för "VIA" och administreras i ett samlat gränssnitt. Till en början kan man låta trafik fortsätta flöda helt utan påverkan genom Viorna och i administrationsgränssnittet analyserar den verkliga trafiken i nätet. Sedan definierar man sina zoner och hur dessa får kommunicera med varandra genom Conduits. Opscura har på det här sättet lyckats skapa något som i praktiken är ett slags Software Defined Network, men utan att nätverksutrustningen behöver ha stöd för det. Switcharna kan till och med vara omanagerade om man nu tycker det är trevligt med sådana. Deras lösning ger en massa fina finesser som annars kan bli tråkiga överraskningar när man driftsätter en sådan här lösning i OT-sammanhang: Om man vill kan man släppa fram broadcast-trafik, "Layer 2", vilket gör det möjligt för programmeringsverktyg och annat som ofta använder just broadcast för att exempelvis hitta nya PLC:er på nätverket redan innan de konfigurerats. I och med att man definierar en Conduit mellan två Zoner så definierar man också brandväggsreglerna som ska gälla för den kommunikationen. Det betyder att filtreringen sker ute på varje Via och inte behöver involvera vanliga brandväggar. Om man vill samla in trafik i nätet för att skicka till exempelvis en IDS, såsom Nozomi Guardian, blir det oftast svårt att få tag på trafik "långt ut i nätet". Opscura kan aggregera trafik som samlas in ute på de olika Viorna och presentera det som en samlad kopia på ett lämpligt ställe där IDS:en kan suga i sig trafiken. Med samma funktion som samlar nätverkstrafik till en IDS kan man också spela in nätverkstrafik någonstans i nätet och sedan ladda ner den som en pcap-fil som går att titta på i Wireshark eller något annat verktyg. Helt ovärderligt för både felsökning och när man planerar segmentering. För att testa om det här fungerar i verkligheten drog jag igång en test-process som jag skrivit om förut i bland annat Nyhetsbrev #54, en PLCnext från Phoenix Contact som styr en hiss och några transportband som simuleras i Factory IO via ett remote IO över MODBUS TCP. Via-funktionerna körs på två fysiska datorer, som i det här fallet kommer från Schneider Electric och management-servern körs på en annan liten PC. I labbet står de intill varandra men i praktiken finns de kanske på helt olika platser med någon form av nätverksförbindelse mellan dem. Inkopplingen av de två Viorna mellan PLC:n och IO:t i labbuppställningen var helt odramatisk. Det blir förstås ett avbrott när man drar ut en sladd men sedan flödade funktionen som vanligt trots att nätverkstrafiken passerade fram och tillbaka genom de två Viorna. I det här läget kan man välja att manuellt skapa Zones och Conduits i administratörsverktyget, under förutsättning att man vet vilken typ av kommunikation som behövs. Annars drar man igång Opscuras inbyggda analys av all nätverkstrafik som direkt listar vilka enheter som pratar på nätet, vem som pratar med vem och sedan ritar upp detta tydligt. De blå rutorna i bilden är Viorna och visar vilken Via som hanterar vilka enheter på nätet. Zoomar man in närmare så ser man vad som är vad: När man har sina Zones och Conduits så ber man Viorna att sluta bete sig som en "Wire" och istället börja skydda trafiken. Jag slog på skyddet medan "tillverkningsprocessen" var igång och det fungerade utan störningar! När man tittar på trafiken på nätet ser man tydligt att det istället för MODBUS-paket enbart skickas krypterad trafik mellan Viorna. Före: Och efter: Ja, trafiken som går genom en Conduit är alltså automatiskt krypterad. Då kanske någon tänker: "Men kryptering kan ju vara lite klurigt i OT-världen?". Ja, så är det men i det här fallet ser jag faktiskt ingen nedsida: Systemet sköter om all nyckelhantering själv Det gör inget att trafiken blir "osynlig" eftersom Lunaria kan erbjuda en kopia av all trafik till IDS:er och liknande säkerhetslösningar. Krypteringen gör att man kan skicka trafik genom nätverk som man inte litar fullt ut på även om man förstås inte löser risker med avbrott orsakade av angrepp mot nätverket. Även om kryptering alltid introducerar en liten extra fördröjning så verkar lösningen verkligen vara trimmad på ett sätt som gör påverkan minimal. Jag kanske inte skulle använda den på väldigt tidskritiska lösningar men annars så... Om du läst tidigare nyhetsbrev så vet du kanske att jag har stort hopp om att SDN, Software Defined Networking, ska bli en vanlig lösning för OT-nätverk. Opscura infriar väldigt mycket av den nytta som SDN ger, men på ett sätt som inte påverkar den underliggande nätverksinfrastrukturen. Det blir förstås extra intressant i sammanhang där utrustningen finns på olika fysiska platser och kommunicerar mellan nätverk som kanske hanteras av olika grupper. Är man på jakt efter en lösning som gör det enkelt att bygga nät baserat på Zones och Conduits tycker jag absolut man ska överväga Opscuras lösning! Vem vill ha ett trasigt nätverk? I det här nyhetsbrevet får du faktiskt två tester i labbet! Jag har lyckats få fingrarna på en väldigt "udda" men rolig produkt från Keysight som simulerar "dåliga" nätverk, NE2 - "Network Emulator 2". Det är ju inte helt ovanligt att ett system fungerar bra när man testar det under perfekta förhållanden, men sedan fungerar mycket sämre efter driftsättning när nätverket tappar enstaka paket eller det blir fördröjningar på grund av långa avstånd. Med NE2 kan man bli väldigt kreativ med elakheterna som man vill introducera under tester! Som vanligt när det är en Keysight-produkt så är det väldigt välgjort och kompetent! Jag kom snabbt igång och kunde simulera en dålig förbindelse mellan de två Viorna i Lunaria-lösningen i föregående text. Trots ett något blygsamt utseende är det en riktigt kraftfull manick! Du har möjlighet att manipulera upp till fyra separata nätverksförbindelser samtidigt som valfritt kan vara koppar eller fiber, var och en upp till 16 Gb/s. Det finns en rejäl arsenal med påverkan som man kan kombinera för att simulera utmanande nätverk. Vad sägs exempelvis om att: Rena bit-fel, där en eller flera slumpmässiga bitar i huvudet eller innehållet för vissa paket blir fel. Slumpmässigheten styr du själv och kan baseras på olika statistiska fördelningar: Periodic, Uniform, Gaussian och Poisson. Trasig laser för fiberförbindelser där lasern helt enkelt stängs av slumpmässigt. Påverka hur paket fördelar sig över tid, exempelvis skapa "Bursts". Låtsas vara en asymmetrisk förbindelse, typ DSL eller satellit, som har olika hastigheter i de båda riktningarna. Maximera bandbredden som kan användas. Påverka olika typer av trafik på olika sätt. Skapa IPv4-fragmentering genom att automatiskt hugga sönder paket och dela upp dem i flera mindre paket. "Tappa bort" paket på valfritt slumpmässigt vis. Manipulera innehållet i paket men återställa checksummor så de stämmer. Fördröjningar som kan vara konstanta eller slumpmässiga. Byta ordning på nätverkspaket så de kommer fram till mottagaren i "fel" ordning. Slumpmässigt skapa kopior av paket så att det kommer flera av samma till mottagaren. En del av dessa elakheter kan dessutom utföras på Fibre Channel om man har sådana förbindelser. Det här är en riktigt cool pryl som definitivt platsar om man är riktigt seriös i sina tester av systemlösningar. Mina tester med Lunaria visade tydligt att Opscura klarar "dåliga" nätverksförbindelser, men man kan tyvärr inte säga samma sak om min PLC-programmering som spårade ur rejält när jag var elak mot den... Det vanligaste problemet för OT-lösningar som man kan komma åt med NE2 är nog system som kommunicerar över långa avstånd eller via media som drabbas av en del störningar. Att kunna hitta lösningar på sådan påverkan redan under testerna blir mycket enklare än felsökning när man väl är ute i fält! Som vanligt gillar jag Keysights sätt att leverera solida lösningar på ovanliga utmaningar! Snyggt jobbat! Ett boktips från förr! Man kan tycka att det är en bok som jag borde ha läst för länge sedan, men jag har alltid tänkt att jag redan hört alla historier kring NotPetya, Sandworm, Projekt Aurora, Industroyer och 74455 - hur mycket mer kan Andy Greenbergs klassiska bok "Sandworm" tillföra? Det visar sig - en hel del! Det var en del pusselbitar som föll på plats och att läsa om händelserna i Ukraina 2017 fick förstås lite extra tyngd. En bok som alla som sysslar med OT-säkerhet bör läsa men också alla som någonsin uttalat orden "Varför skulle någon vilja hacka oss?". Stark läsrekommendation helt enkelt! Passar utmärkt som semesterläsning... Jag har inga sårbarheter kvar - kan jag ta ledigt då? I IT-världen innebär aktivt säkerhetsarbete ofta att man spenderar mycket tid på att jaga nyannonserade sårbarheter i mjukvara, CVE:er. Ni vet hur det är... "Oj! Titta på den här nya sårbarheten i vår webbserver, nu måste vi genast patcha!". Det innebär en ständig jakt mot något slags perfekt tillstånd där man inte har några sårbarheter. Om det är svårt för IT-folket så blir det genast ännu värre i de flesta OT-miljöer på grund av alla möjliga viktiga begränsningar i hur vi vill ändra i våra system. Det innebär att målet "Noll sårbarheter" blir så gott som omöjligt att uppnå. Dessutom blir det som jag skrev i Nyhetsbrev #59 så krävs trots det väldigt mycket arbete för att analysera vilka sårbarheter som verkligen är viktiga för oss ur den fullkomliga floden av sårbarhetsannonseringar som flödar över oss! Nästa insikt kommer när man börjar fundera över så kallade "Zero Days", alltså sårbarheter som de elaka hackarna känner till, men som ännu inte upptäckts av oss andra. Vi kommer alltså sannolikt aldrig ha "Noll sårbarheter", utan bara "Noll av oss kända sårbarheter". Det är en väldigt jobbig tanke i IT-världen, där man ofta är väldigt exponerad för omvärlden. Men för OT-folket blir det också en jobbig tanke men av delvis andra skäl, vi är ju vana att vi ska bygga robusta system som tål att något går snett i den fysiska processen. Varför kan vi inte göra samma sak när händelsen orsakas av en cyberbrist? Ett koncept som vi borde diskutera mer är "Cyberrobusthet". Alltså tanken att våra system exempelvis ska tåla en oväntad sårbarhet som utnyttjas utan att något allvarligt inträffar och att vi dessutom alltid ska upptäcka att det hänt. Det finns förstås många olika sätt att närma sig den här frågan. Jag har tidigare skrivit om metoder som CCE, "Consequence-driven, Cyber-informed Engineering" där man just fokuserar på att bygga bort allvarliga konsekvenser med fysiska åtgärder. Lite på samma tema kan man tänka kring potentiella sårbarheter som man inte känner till ännu. I Nyhetsbrev #49 skrev jag om MITREs nya version av CWE-ramverket som nu mappar mot några av delarna i IEC 62443. Om man tar den kopplingen och använder den för att göra analysarbetet jag skrev om i Nyhetsbrev #59 så kan man bygga ett försvar som gör ännu så länge teoretiska sårbarheter harmlösa genom att förekomma dem med andra åtgärder än patchning. Man resonerar alltså kring typer av sårbarheter snarare än en viss specifik sårbarhet, vilket är svårare men också mer meningsfullt! Det här gör att vi också får ett annat bra resultat på köpet, vi slutar resonera om sårbarheter i betydelsen "Buggar i mjukvara" och byter till att prata om det som ordet "Sårbarheter" egentligen betyder - nämligen svagheter i våra systems robusthet. Blir systemen så robusta att de tar hand om mjukvarubrister så har vi ju ingen sårbarhet! Jag tror det här är ett mycket vettigare sätt att spendera säkerhetsresurserna än att syssla med brandsläckning. Det är lätt av avfärda resurser som MITRE CWE med "Det där är för utvecklarna", men då missar man riktigt viktiga poänger. Det är lite likt hur man kan använda MITRE ATT&CK för att analysera sina försvarsförmågor. Vi kanske inte får ta extra semester men vi får i alla fall vara ifred för sårbarhetslarm på semestern. Samtidigt är det här förstås inte svaret på alla våra problem. Vi kan inte alltid utforma våra system på det optimala sättet för god cybersäkerhet, eftersom det skapar andra typer av risker som vi tycker är värre! Begreppet "insecure by design" används ibland lite skämtsamt för detta. Allt detta är dessutom beroende av ett aktivt säkerhetsarbete så att systemens förmågor inte förfaller över tid. På samma sätt måste vi också se upp så att vi över lite längre tid inte börjar kompromissa bort alltför mycket av vårt säkerhetstänk. Marco Ayala pratade om precis detta på årets S4-konferens, tänkvärt... Den bäst bevarade hemligheten inom svensk industri! Jag spenderade nyligen några dagar på Elmia Produktionsmässor i Jönköping. En verklig högtid för alla med koppling till tillverkande industri, massor med automationlösningar, verktygsmaskiner och annat kul att titta på. Mindre kul var att jag hade samma upplevelse som tidigare år, nämligen att det inte finns något som helst fokus på säkerhetsfrågor. Kunderna frågar inte efter det och leverantörerna skryter inte om att de har det. Bland alla föredrag och presentationer under mässdagarna så var det (nästan) bara jag som pratade säkerhet. Dessutom var det väldigt tydligt att industrin inte har förstått att NIS2 och den nya Cybersäkerhetslagen även berör många tillverkande industrier. Det kommer bli ett hårt uppvaknande för många framåt hösten... MSB svarar på frågor! Ett steg i rätt riktning är att MSB och vissa av tillsynsmyndigheterna börjat ha informationsevent kring NIS2. MSB har annonserat att man kommer svara på de vanligaste frågorna den 18:e juni. Öppen antagonistisk hotbild för svensk elförsörjning Svenska Kraftnät släppte nyligen dokumentet "Öppen antagonistisk hotbild för svensk elförsörjning" som kan vara väldigt intressant även om man inte är i elbranschen. Säkerhetskrav för elnät? Jag har ärligt talat inte hängt med på det sätt som jag kanske borde när det gäller EUs nya förordning för "gränsöverskridande elflöden". Det låter ju inte vansinnigt relevant för så speciellt många verksamheter, eller hur? Nu i mars släpptes så den slutgiltiga versionen och när jag nu läser så noterar jag en del intressant ändå: Lite på samma sätt som exempelvis CER-direktivet ska man inte själv avgöra om den egna organisationen omfattas, man blir utpekad av en myndighet. Inte bara elföretag kan omfattas utan även exempelvis MSSP - Managerade säkerhetstjänster, IT-outsourcingleverantörer, elbilsladdare mm Det är väldigt många kopplingar till NIS2-direktivet För den som ligger nära sådan verksamhet eller har kunder som gör det bör nog följa med vad som kommer framöver kring den här kravmassan! Kanske en kurs hos Svenska Kraftnät? Jobbar du i en verksamhet som påverkar elnätets stabilitet som producent eller förbrukare? Då har Svenska Kraftnät en kurs för dig! På deras utbildningssida står: Svenska kraftnät arrangerar sedan en tid tillbaka en kurs för personal inom elsektorn där deltagarna får bekanta sig med ett brett spektrum av risker och hotscenarier kopplade till cybersäkerhet och industriell styrning (ICS). Under 2023 har runt 200 personer antagits och genomgått kursen. Kursen är en elberedskapssatsning och målgruppen är personer som direkt eller indirekt arbetar med elnätsdrift, it-stöd eller säkerhet på svenska elnätsföretag, hos vissa större förbrukare eller i andra organisationer vars verksamhet kan påverka nätstabiliteten. Kursen genomförs i internatform under tre dagar (lunch-lunch) och är anpassad för att underlätta deltagande från hela Sverige. Anmälan sker efter inbjudan från Svenska kraftnät. Intresseanmälan kan skickas till icskurs@svk.se. Här behövs också en kurs! Jag kan tyvärr inte säga att jag är förvånad... Runt om i världen fortsätter det inträffa hacker-incidenter där OT-utrustning som placerats direkt på Internet blir saboterade. Å andra sidan ska man definitivt inte tro på siffrorna i Shodan och andra scanningsverktyg, det är sannolikt minst 80% honeypots bland de OT-prylar som dyker upp där. Men ändå... Jag fick nyligen ett mejl från Rockwell Automation som skickade ut en advisory med den fantastiska rubriken: IMPORTANT NOTICE: SD1672 – Rockwell Automation Reiterates Customer Guidance to Disconnect Devices from the Internet to Protect from Cyber Threats Att det kan hända av misstag ska man naturligtvis tänka på och försöka upptäcka som del i sitt säkerhetsarbete. Jag är nyfiken att höra om dina erfarenheter, har du hittat tokigt installerade prylar? Ska vi höras? I ett tidigare nyhetsbrev öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt så jag kommer repetera den här texten framöver. Jag har redan haft ett antal kul samtal med roliga människor från spännande verksamheter av alla de slag. Du behöver förstås verkligen inte vara proffs på just OT-säkerhet för att det ska bli ett intressant utbyte av erfarenheter och tankar! En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite. Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt. Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra. Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats. Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du (nästan) en ursäkt från mig, MSBs åsikter om NIS2-lagen, nytt kring sjöfartens säkerhet, positiva tankar från Dale Peterson, lärdomar kring hantlar och dödsfall, ENISA kopplar CRA till IEC 62433 och så funderar jag på att strunta i Radiodirektivet. 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å 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! Jag ber om ursäkt! Eller? Nä... Egentligen inte... Om du av någon anledning inte är intresserad av NIS2, CER, CRA, RED eller någon av alla de andra regleringarna som EU pytsar ur sig just nu så börjar det nog bli lite tjatigt med all uppmärksamhet som detta äntligen börjar få. Det här nyhetsbrevet är definitivt inget undantag, proppen har verkligen gått ur för de här frågorna sedan nyår! Men jag tycker mig ha bra anledningar till att lyfta detta så mycket just nu. Om du läst tidigare nyhetsbrev vet du att jag är väldigt positiv till den effekt som jag tror att framför allt NIS2 och CRA kommer få på OT-säkerheten i Sverige. Jag tillhör inte alls dem som tycker det är synd att det behövs lagstiftning för att organisationer ska ta ansvar för samhällets cybersäkerhetsrisker. Tvärtom, det är ganska naturligt att det behöver finnas tydliga ekonomiska drivkrafter för det här! En effekt som jag tror vi kommer se tydligt är hur det här också kommer "smitta av sig" på företag som inte är direkt berörda av av NIS2. Producerar man digitala produkter så blir det självklart något av en revolution för många organisationer när CRA ska implementeras, det är ju uppenbart. Men effekten av fokuset på supplychain-säkerhet i NIS2 tror jag kommer ha en enorm effekt på vad som betraktas som en "normal" förväntansnivå på cybersäkerheten hos alla former av leverantörer. I och med att NIS2 har produktion som fokus kommer bra och tydlig OT-säkerhet bli helt avgörande för väldigt många organisationers affärsmässiga framgångar eller haverier. Så du får nog räkna med att jag, och många med mig, fortsätter att tjata om det här ett tag framöver! Och oavsett vad du tycker om det så tror jag att du kommer kunna dra nytta av effekterna, vare sig du vill eller inte... Är faran över? Nej, så långt gick han inte, Dale Peterson, i hans keynote-tal på årets S4-konferens, men han gav en mycket mer positiv och hoppfull bild jämfört med den vi normalt föds med från branschens alla olyckskorpar. Under parollen "Believe", som i att vi ska tro på att vi faktiskt löser våra utmaningar rätt bra, gav han oss sin ljusare framtidsversion där halva lösningen är att inte ge upp innan vi ens försökt... Det här fick en lätt chockad Ralph Langner att publicera en egen video där han kommenterar Dales något oväntade och väldigt positiva presentation: Ingen (inte ens Ralph Langner) förnekar att det förekommer OT-säkerhetsincidenter. Vi kan förstås alltid diskutera hur vi definierar en sådan incident, vilket kan vara roligt, men egentligen inte så viktigt. Om vi tillfälligt struntar i eventuella farliga situationer som kan uppstå i vissa branscher, så är ju det viktiga faktiskt att vår produktion inte drabbas av störningar, oavsett om det är dricksvatten, legobitar eller diesel vi skapar. Vår verksamhet finns där för att producera, i det flesta fall är den primära produkten ekonomisk vinst, som vi skapar genom att först producera något annat med ekonomiskt värde som vi säljer. Kan vi inte producera så tjänar vi inga pengar, och då spelar det mindre roll varför vi inte kunde producera! Vi har alla hört diskussionerna om OT-säkerhetsincidenter som "egentligen" är IT-incidenter. Attacker som drabbar fakturasystem, logistik eller orderhantering men som gör det omöjligt att bedriva produktionen på ett meningsfull och säkert sätt. Lite för ofta hör jag åsikten att den här typen av incidenter mindre viktiga eller intressanta jämfört med en riktig "Stuxnet-liknande attack". Jag håller med om att de är mindre coola, men för att skydda produktionen är de väl egentligen viktigare? De inträffar ju faktiskt relativt ofta och dessutom med allvarliga konsekvenser! Eftersom jag sällan sysslar med stöd kring redan inträffade incidenter blir jag ibland rädd att jag drabbas av en slags "survivor-bias", där jag inte fullt ut hör om de OT-incidenter som faktiskt inträffar. Man hör ibland historier om mindre händelser, ransomware på HMI:er och sånt, men sällan något större. Om du kan tänka sig att dela med dig att dina war-stories så är jag förstås väldigt intresserad av att prata mer om det under strikt tystnadslöfte. Även händelser som var "nära ögat" är superintressanta. Hör av dig på mats@ot-säkerhet.se eller skapa ett möte här. Jag tror precis som Dale att vi kan hantera OT-säkerhetshotet enklare än vi ibland tror. De stora utmaningarna är, som vanligt, att verkligen förstå vad verksamheten är beroende av och att använda våra begränsade resurser där de gör mest nytta. Vi kommer aldrig få alla de resurser som skulle krävas för att ta bort alla risker - men det är inte meningen heller. De flesta verksamheter existerar inte för att du och jag ska vinna VM i OT-säkerhet utan för att skapa produktion till rätt kostnad! Glöm inte Radiodirektivet! Eller borde vi göra just det? Kan det vara så att i allt ståhej kring NIS2 och CRA så har EUs Radiodirektiv "RED" blivit lite bortglömt! Det här är inte ett nytt direktiv, det kom i en första version 2014. Fokus är, precis som namnet indikerar, på alla former av radioutrustning, både sändare och mottagare - oavsett om det är en telefon, en walkie-talkie eller en GPS. Genom ändringar och genom tillägg till direktivet omfattar det numera en rad saker som inte var påtänkta från början. Den kanske mest kända är beslutet att tvinga fram USB-C som standard för laddare av mobil utrustning, I oktober 2021 kom ytterligare en så kallad "Commission Delegated Act" som lägger till en massa cybersäkerhetskrav till Radiodirektivet. Implementation i augusti i år, 2024, var det tänkt. Men det visade sig lite för jobbigt så förra sommaren kom ett nytt beslut som sköt fram införandet till augusti 2025. Det man lägger till är i huvudsak tre saker som har med cybersäkerhet att göra: Radioutrustning som kan "kommunicera på Internet" ska omfattas av ett redan existerande krav som lite slarvigt sammanfattat säger att utrustningen inte ska skada eller störa nätverket. Radioutrustning som kan hantera personlig information eller platsinformation ska skydda den informationen om utrustningen är Internetansluten, avsedd för barn eller kan bäras på kroppen(!). Radioutrustning som kan hantera något slags pengar ska uppfylla krav för skydd mot bedrägerier. Jag är verkligen ingenting annat än en total amatörjurist, även om jag erkänner att jag har en smått perverst nöje av att läsa lagtext. Det här tillägget till RED tycker jag faktiskt är lite märkligt. Det blir nog framför allt konstigt för att man bakar in detta i ett direktiv som jag tycker egentligen handlar om något annat. Det är inte helt tydligt för mig vad de nya kraven siktar på och framför allt har man inte definierat vad ordet "Network" betyder. Ordet användes tidigare i betydelse radionät men ingen ny definition finns nu när det rimligen borde inkludera även Internet? Min tolkning som amatörjurist är att det fortfarande krävs att radiovågor skickas eller tas emot eftersom ordet radioutrustning är definierat så. Det här gäller i så fall inte prylar som bara kommunicerar via en ethernet-kontakt! Ur ett OT-perspektiv tillkommer lite mer förvirring kring formuleringen som säger att saker omfattas om de kan kommunicera på Internet. Vad betyder det för protokoll som inte är baserade på IP? Det hela blir ju faktiskt lite extra fånigt när vi vet att CRA är på gång och liksom kommer ta över de här kraven och det med råge! Det finns dock ingenting som säger att kraven i RED kommer försvinna. Det vore intressant att höra från någon klok person som dykt djupare i det här och kan reda ut begreppen lite mer... mats@ot-sakerhet.se Inspelningar från S4! De första inspelningarna från årets S4-konferens har nu börjat släppas i en separat spellista på YouTube. Efterhand kommer det mesta att släppas utspritt under året. Ta chansen och lyssna på ett stort antal att de stora hjärnorna i OT-säkerhetsvärlden! Det finns massor av godbitar, en av dem är den alltid lika intressanta paneldiskussionen som avslutar hela konferensen. Den är faktiskt inte släppt som video än men du kan tjuvlyssna på en ljudversion så länge. Ni har gjort fel! En av medlemmarna i ovanstående S4-panel är den ständigt underhållande och utmanande Ralph Langner. I en text sammanfattade han nyligen sin kloka syn på hur man bygger en robust OT-plattform. Mycket nöje! Baksidan av NIS2? En av de saker som jag verkligen gillar och tror på kring NIS2 (och den kommande Cybersäkerhetslagen) är att man tvingar alla som omfattas av lagen att ställa motsvarande krav på sina leverantörer. Det skapar ju verkligen ett affärstryck för alla som vill kunna vara en leverantör till NIS2-organisationer - och de blir ju väldigt många! Men vad är baksidan då? Jo... Det är ju jobbigt att ställa krav på sina leverantörer, åtminstone om man ska göra det ordentligt - för då ingår ju förstås att följa upp att de faktiskt brytt sig om dina krav... Relationen mellan leverantörer och kunder är ju alltid "Många-Till-Många", det vill säga kunder måste följa upp många leverantörer och leverantörer måste hantera krav från många kunder. Dessutom kommer förstås alla kunder göra detta "på sitt sätt"... Här finns förstås en fin affärsmöjlighet för den som vill göra det här åt andra företag. Man tar betalt av en leverantör för att göra något slags assessment av säkerhetsarbetet, vilket är trevligt för leverantören som bara behöver göra det här en gång. Sedan tar man betalt av alla kunder till den leverantören för att sammanställa hur leverantörens förmågor kring säkerhet ser ut. Perfekt även för kunden eftersom man kan gå till ett ställe och ta reda på allt om alla sina leverantörer.... Så långt - inget problem! Eller? Jag har sett ett gäng Internet-baserade tjänster som försöker lösa detta, men det är inte alla som inger förtroende... Mina invändningar är framför allt: Vilken leverantör kommer någonsin avslöja något negativt till en sådan mellanhand utan att det finns mycket starka avtal upprättade mellan dem som reglerar sekretessen? Mellanhanden hamnar i en spännande position där man skulle kunna få tillgång till otroliga mängder ytterst känslig information. Börjar man tänka i begrepp som "ackumulerad och aggregerad information" så gissar jag att man snabbt hamnar i nivåer där säkerhetsskydd är aktuellt ur ett svenskt perspektiv? Ovanstående två punkter kommer i bästa fall leda till att ingen kommer berätta sanningen vilket i sin tur gör resultatet från arbetet helt meningslöst. Jag säger inte att det här är omöjligt att göra på ett bra sätt, jag har bara inte sett någon göra det ännu... De varianter som passerat framför mina ögon än så länge har verkligen inte gjort ett solitt intryck! Jag vill gärna bli överbevisad och då vill jag förmodligen dessutom investera i det företaget direkt! Däremot kanske våra branschorganisationer har en fin möjlighet här? Då kan man tänka sig att kravställningen blir relevant, uppföljningen fokuserar på rätt saker och hanteringen sköts av en organisation som man kanske redan litar på. Jag tror just branschorganisationer kommer ha en viktig roll att fylla generellt, både på kund- och leverantörssidan. Vad kan vi lära av en hantel? I en artikel av Dale Peterson refererar han till den ekonomiska strategin "Barbell strategy". Det är tanken att man har en enkel med trygg basplattform som man kompletterar med något som tar hand om oönskade händelser. Översatt till OT så tänker han sig att man kommer relativt långt med enkla och billiga säkerhetsåtgärder som kompletteras med åtgärder som säkerställer något slags drift trots att vissa incidenter inte kan förhindras. Själv brukar jag använda hjulet från NIST Cyber Security Framework för en liknande poäng. Där är min tanke att det lätt blir slagsida till fördel för preventiva åtgärder inom området "Protect", men att man missar Recover som är nödvändigt för att kunna hantera när incidenten är ett faktum. På samma sätt springer många och handlar IDS-system, som är tänkta att användas inom Detect men organisationen har inte resurser att agera på larm från IDS-systemet, dvs Respond. Istället blir resultatet i bästa fall att man får förbättrad information om sin anläggning, dvs lite åt Identify-hållet, med bättre asset-information. Att lära av ett dödsfall? Som vanligt när Sinclair Koelemij skriver blir det intressant och utmanande. I en text med rubriken "Strategic Decision-Making in Cyber-Physical Risk Assessments and Cyber Ethics" beskriver han flera klurigheter som är specifika för vår vardag som OT-säkerhetsmänniskor. Intressant nog är det delvis ett svar på Dales artikel om hanteln som jag skriver om här ovanför. Han utmanar bland annat användningen av modeller där man lägger mycket krut på att uppnå tålighet genom att vara snabb i återställningen av redan havererade system. En svårighet med det (som jag hintar om i rubriken ovan) är om konsekvenserna kan bli riktigt allvarliga, till den grad att inte allting är möjligt att återställa på ett rimligt sätt, som människoliv, miljöskador eller kritisk utrustning som har mycket långa leveranstider. Läs och begrunda! En bra påminnelse om att våra riskanalyser inte får fokusera för mycket OT-systemen om de stora konsekvenserna uppstår utanför systemen! MITRE kopplar CWE till IEC 62443 CWE skrev jag senast om i nyhetsbrev #49. CWE, Common Weakness Enumeration, är ett systematiskt sätt att beskriva svagheter i mjuk- och hårdvaror. Nu har MITRE lagt till en vy som heter "Weaknesses Addressed by ISA/IEC 62443 Requirements" där namnet ganska väl beskriver vad tanken är. Snyggt upplägg som gör CWE ännu mer användbart för OT-folket! Om du är road av detta så finns även en uppdaterad dashboard hos "ICS Advisory Project" där du kan filtrera registrerade Sårbarheter/CVE:er mot vilka CWE-koder de orsakas av med koppling till respektive krav i de olika standarderna inom IEC 62443. Nu kan man verkligen gå helt bananas i att analysera dessa sårbarheter! Mycket nöje! Ännu mer på gång från MITRE! Om man läster MITREs plan för ATT&CK: "ATT&CK 2024 Roadmap" ser man att de har mycket på gång för OT-folket. Det blir mer detaljer kring attacker, man gör om asset-informationen och mycket annat. Den som väntar på något gott... ENISA kopplar CRA till IEC 62443 Lite på samma tema som det MITRE gjort för att koppla CWE till standarden har nu EUs cybersäkerhetsmyndighet ENISA publicerat en mappning mellan CRA-förordningen och en rad olika standarder. Det hela är på en väldigt hög nivå men kan ändå vara en väldigt praktisk startpunkt om man ska ta tag i sitt CRA-arbete! Det man dessutom får på köpet är att de sammanställt de krav som de anser att CRA formulerar kring säkerhet och hantering av sårbarheter. Det är 13 + 8 krav som annars inte är helt enkla att hitta i den massiva förordningen. Dessa krav mappas sedan mot en rad olika standarder med ett resonemang om hur respektive standard tar hand om kravet och eventuella gap som man behöver ta hänsyn till. Allt är på ett ruskigt hög nivå, resonemangen är enbart för en hel standard, exempelvis: De standarder man har med är en rejäl lista, så oavsett vad du är i för bransch så finns nog flera relevanta med: ISA/IEC: 62443-3-2, 62443-4-1, 62443-4-2 ISO/IEC 9796 2-3, 9797 1-3, 9798 ISO/IEC 13888, 14888 ISO/IEC 15408-2, 15408-3 ISO/IEC 18031, 18033, 18045 ISO/IEC 19249 ISO/IEC 22237 ISO/IEC 24760 ISO/IEC 27002, 27005 ISO/IEC 27034, 27036 ISO/IEC 27701 ISO/IEC 29100, 29147 ISO/IEC 29146, 29147 ISO/IEC 30111 ETSI 103 485, 303 645 ITU-T X.805, X.812, X.814, X.815, X.1214, X.1253, Y.4810 Jag hittade också en bra översikt gjord av Steffen Zimmermann: Från teori till praktik Som du kanske minns från nyhetsbrev #46 så använder jag ibland programvaran Factory IO i mitt kära hemmalabb för att illustrera fysiska processer. Det visar sig att det finns fler som gillar den här produkten, i en två-delad artikelserie beskriver nämligen Team82 från Claroty deras användning. I del 1 kan vi läsa om hur de satt upp sitt labb och i del 2 beskriver de ett antal praktiska attacker som leder till ett härligt kaos i processen. Följetongen om EUs språkhantering... I förra nyhetsbrevet skrev jag att ryktet om att CRA skulle bli framskjutet tydligen var fel eftersom texten klubbades i Europaparlamentet. Nu visar det sig att jag kanske inte var så fel ute i alla fall, senaste budet är att en slutgiltig version sannolikt inte blir klubbad förrän framåt oktober. Nå ja, vi får se... Om du producerar digitala produkter fick du några extra månader på dig, det kommer bli tajt ändå för det flesta... Lustigt det där... Som jag nämnde i nyhetsbrev #59 så har VMware annonserat att gratisversionen av ESXi ska försvinna, ett tungt slag för många hemmalabbare som använt det som bas för virtualisering. Det här ökar förstås intresset ännu mer för andra alternativ och då kanske i synnerhet min egen favorit Proxmox VE. Som av en händelse annonserade nu Proxmox nytt stöd just för att automatiskt migrera virtuella maskiner från ESXi direkt in i Proxmox VE... Lustigt det där... Det har förstås tekniskt varit möjligt även tidigare men krävt lite mer handpåläggning. Nu ansluter Proxmox VE direkt till ESXi-server och "suger i sig" systemen. Smidigt! Välkommen över till den ljusa sidan! Var är klockan? I nyhetsbreven #59 och #60 skrev jag om utmaningarna kring GPS/GNSS-störningar. För den som vill lära sig mer finns ett bra dokument från kanadensiska företaget NovAtel som ingår i välkända svenska Hexagon-koncernen. Där beskriver man både störning och spoofing tillsammans med deras egna lösningar för att minska problemen. De refererar även till en artikel i "Inside GNSS" som tittar på samma ämne. Äntligen någon som tycker som jag! Om du lyssnat på någon av mina föredrag kopplat till NIS2 så har du sannolikt hört mig fundera högt kring den märkliga definitionen av kemikalie-sektorn. Jag skrev också om det i ett nyhetsbrev nyligen. Nu har jag hittat tecken på att fler ifrågasätter om den extremt breda definitionen (alla verksamheter som använder "kemikalier" för att framställa något slags vara) verkligen är rimlig! Den tyska juristfirman reusch law har publicerat dokumentet "Working Paper on ANNEX II No. 3 NIS2 Directive, NIS2 and REACH" skrivet av Steffen Zimmermann från VDMA and Stefan Hessel där de verkligen går till botten med den här frågan. Förslaget från den svenska utredningen kring NIS2 och CER har inte tagit alls i den här frågan utan för vidare samma definition som i direktivet. Något annat var i och för sig inte att vänta sig eftersom man som land inte kan göra så stora ändringar i omfattningen hos ett direktiv. Det ska bli väldigt intressant att se hur Länsstyrelserna i Norrbottens, Skåne, Stockholms och Västra Götalands län kommer hantera den här nöten, de är nämligen föreslagna som ansvariga för föreskrifter och tillsyn i den här sektorn... Jag har en känsla av att man inte räknat på det här sättet när man uppskattade hur mycket resurser Länsstyrelserna kommer behöva... Ett skepp kommer lastat... Attacker mot GNSS-system är en av alla populära diskussionsämnen i området säkerhet inom sjöfarten. Det här med potentiella attacker mot fartyg fick lätt bisarra proportioner nyligen, när fartyget Dali kraschade in i Francis Scott Key Bridge i Baltimore vilket resulterade i att stora delar av bron rasade. Genast dök en lång rad olyckskorpar upp som kraxade om att det minsann kunde vara en cyberattack. Personligen tycker jag det är direkt pinsamt och korkat att försöka skaffa sig poänger genom att presentera vilda teorier som helt saknar faktisk grund. Det här beteendet är verkligen ett av skälen till att vi säkerhets-människor inte tas på allvar när vi varnar för risker. I det här fallet så kan det förstås visa sig att det faktiskt var en cyberattack, men den diskussionen tar vi när det är klarlagt! Däremot är det definitivt så att cybersäkerhet i sjöfarten är spännande och viktigt, speciellt kanske OT-säkerhet ombord på fartyg! Jag har haft förmånen att vara insyltad i några fartygsprojekt och det är en fascinerande men utmanande värld! I nyhetsbrevet har det tidigare funnits nyheter om att det kommer skarpare krav på området och nu är det flera intressanta sådana på gång igen. Framför allt är det klassningssällskapens organisation IACS som från och med 1:a juli sätter kravdokumenten UR E26 och UR E27 i skarp verkan. De skulle ju ha gällt redan från 1:a januari, men i sista minuten drogs de tillbaka och reviderades. Samtidigt släpper man en uppdaterad version 3 av UR E22 som handlar om utformning, konstruktion, driftsättning och underhåll av alla datorbaserade system ombord som krävs för att få fartyget klassat. Dessutom är FN:s sjöfartsorganisation IMO på gång att godkänna en uppdatering av deras riktlinjer för cyberriskhantering inom maritima verksamheter. (Länken kräver ett gratis konto.) Som skäl uppger IMO att man bland annat vill adressera förändringarna i hotlandskapet, sätta en tydligare basnivå för säkerheten samt tydligare referera till standarder och ramverk. Det man refererar till är förutom ISO 27000 och nya NIST CSF även tre specialiserade kravmassor: "The Guidelines on Cyber Security Onboard Ships" som underhålls av en rad organisationer ICS, IUMI, BIMCO, OCIMF, INTERTANKO, INTERCARGO, InterManager, WSC och SYBAss Samlingsrekommendationerna från IACS Riktlinjerna kring hamnar och hamnsystem från IAPH På samma tema kan man också notera att kustbevakningen i USA nyligen släppte ett förtydligande för en "Executive order: Executive Order on Amending Regulations Relating to the Safeguarding of Vessels, Harbors, Ports, and Waterfront Facilities of the United States" som president Biden skrev under i februari. Det här är definitivt ett område som väcker mycket intresse och dessutom välförtjänt! En riktigt intressant rapport kommer från norska organisationen NORMA Cyber. De tittar på den aktuella hotbilden och tar upp GNSS/AIS-spoofing, OT-säkerhet, ransomware med mera. Vad tycker MSB om NIS2? När detta skrivs är förslaget till ny Cybersäkerhetslag (som ska implementera NIS2-direktivet) ute på remiss. En nyckelspelare kring dagens NIS-direktiv är MSB, vilket för övrigt utredningen föreslår ska fortsätta. MSB har publicerat sitt eget svar på remissen vilket var intressant att läsa. Jag ställer upp på i princip allt som de tycker till om, inklusive behovet av att samordna baskraven enligt lagen med de åtgärder som krävs när Säkerhetsskydd är aktuellt. Ska vi höras? I ett tidigare nyhetsbrev öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt så jag kommer repetera den här texten framöver. Jag har redan haft ett antal kul samtal med roliga människor från spännande verksamheter av alla de slag. Du behöver förstås verkligen inte vara proffs på just OT-säkerhet för att det ska bli ett intressant utbyte av erfarenheter och tankar! En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite. Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt. Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra. Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats. Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången får du spontanfunderingar direkt från S4-konferensen i Miami, GPS-störningar, SBOM-utmaningar, elaka typer som leker kurragömma i våra OT-system, en bokrecension, järnspindlar i våra HMI:er, en ny 62443-certifiering, framsteg för CRA & NIS2 och så en rolig trippeltest i hemmalabbet. (Japp, tre spännande men helt olika produkter möts lite otippat i ett gemensamt test...) 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å 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! Många roliga tankar kring förra nyhetsbrevet Det är alltid extra roligt när det kommer spontana inspel från er läsare på innehållet i nyhetsbrevet. Kring förra utgåvan var det lite extra mycket och dessutom på lite oväntade delar av innehållet, vilket är ännu roligare! Även om du får nyhetsbrevet skickat till dig så är du förstås väldigt välkommen att bidra till samtalet som ibland uppstår på LinkedIn. Följ mig gärna där så hittar du enklare till kommentarerna. Alternativt ett mejl direkt till mig: mats@ot-sakerhet.se. Några av de kommentarer och diskussioner som uppstod förra gången resulterade i några av de texter längre ned i det här nyhetsbrevet. Tack för ert engagemang! Varning för rant! Ingen som följer mitt nyhetsbrev kan ha missat att jag till största delen är positiv till de lagkrav som är på gång från EU i form av NIS2, CRA, Maskinförordningen osv. Emellanåt hör jag argument i något föredrag eller läser någon artikel som sänder signalen att organisationer "drabbas" av dessa krav. Det är där jag vill markera att jag tänker lite annorlunda. Se det som en chans att ta ditt samhällsansvar utan att din organisation hamnar i ett sämre läge konkurrensmässigt. Det som samhället, i form av EU, säger är: Kära verksamheter, vi tycker inte ni tar hänsyn till de risker ni utsätter samhället för när ni slarvar med er säkerhet. Vi förstår att samhällets risker är svåra att väga in när ni tar ekonomiska beslut. Varsågod, nu får ni tillbaka de risker ni skapat för oss i en form som ni faktiskt kan använda; sanktionsavgifter, "framtvingade" kundkrav och personligt ansvar för er ledning. Lycka till! Jag håller med dem som tycker att det är synd att lagkrav behövs, men med lite klarsynthet ser man att det knappast finns några realistiska alternativ. Från mig skickar jag två tummar upp till EU för att man tar stora kliv framåt på området! Bra, fortsätt så! Man kan ha många åsikter om EU men i det här sammanhanget fungerar det verkligen. Hade enbart Sverige lanserat något i stil med NIS2 hade man förmodligen som land tyvärr skjutit sig själv i foten genom att "tvinga på" svenska kommersiella verksamheter en massa kostnader försämrar konkurrensförmågan och ger nyttoeffekter även för andra länder. I och med att EU är tillräckligt stort så sätter man konkurrensproblemet ur spel när hela den europeiska marknaden blir otillgänglig för den som inte bryr sig om CRA. Ursäkta denna lilla rant (vad heter det ordet på svenska?) men jag behövde få ur mig det... Var har de gömt sig? En varning från amerikanska CISA nyligen tycker jag var en bra påminnelse om en av mina egna käpphästar! I IT-världen är det stort fokus på ransomware, och det med rätta förstås! Det hörs emellanåt diskussioner kring när vi ska förvänta oss att se fler ransomware-attacker i OT-miljöer, vilket är en relevant fråga och som kan ha spännande filosofiska diskussioner om. Men... En fråga som jag tycker man glömmer bort i det sammanhanget är att vi kanske har helt fel bild av attackerna i vårt samhälle. Ett lyckat angrepp med ransomware är per definition väldigt svårt att missa, det är ju faktiskt hela idén! Tänk dig istället tanken att ALLA lyckade attacker som du hör om varje dag istället "bara" resulterade i att angriparen i tysthet skaffade sig en eller många bakdörrar för att snabbt och enkelt kunna återvända när det behövs för att skapa maximal oreda vid sämsta möjliga tillfälle. Det scenariot tycker jag alldeles för få oroar sig över i OT-världen! Med tanke på omvärldsläget borde det vara väldigt aktuellt för alla verksamheter vars produktion är viktiga för ett stabilt samhälle! Det kanske till och med borde till en lagstiftning för att få alla sådana verksamheter att fokusera mer på säkerhet med ett brett tänk kring risker? Men vänta... Det är ju precis det som vårt kära NIS2 är! Där använder man begreppet "allriskansats" för att trycka just på att vi ska tänka på alla risker som är relevanta - inte bara de som är populära i media! Hur ska du hitta en angripare som planterade en inloggning i ditt system för två år sedan? Här vill det nog till att sluta förlita sig på förebyggande skydd och börja tillämpa aktivt sökande i våra system efter tecken på vilande angripare... Direkt från S4! Så var det då äntligen dags för årets OT-höjdpunkt om du frågar mig, S4-konferensen i Miami Beach. Drygt 1000 förväntansfulla deltagare som njuter av framåtlutande och kloka presentationer på tre scener. Och det är ju det framåtlutande som gör S4 så rolig konferens, det är en uttalad strategi från arrangörens sida att man väljer innehåll som hjälper oss genomskåda hur framtiden kan tänkas se ut i branschen. Av de 1000 var vi hela 15 deltagare från Sverige vilket förstås var väldigt roligt i sig! Som vanligt är skallen full med mängder med intryck från presentationer, diskussioner och roliga möten med nya och gamla bekantskaper. De flesta presentationer kommer publiceras på YouTube senare under året så du kommer kunna ta del av en hel del i efterhand också. Om jag ska rekommendera några favoriter som jag tycker du ska hålla utkik efter så är det bland annat de här: Dale Peterson inledde själv under parollen "Believe" där han poängterade att vi faktiskt klarar ganska mycket i branschen om vi bara vill och tror på oss själva. Mest klarspråk fick vi (som vanligt) av Rob Lee från Dragos. Mycket uppfriskande! Ska du bara se en video från S4, så se den här! Som alltid är slutpanelen där Dale tillsammans med Ralph Langner, Megan Sanford och Zach Tudor reder ut kluriga frågor, både underhållande och fylld med klokskap. Om du bara ska se två videos från S4 så se den här också! Maggie Morganti på Rockwell berättade vad som hände bakom kulisserna i samband med att en riktigt allvarlig sårbarhet upptäcktes i händerna på en fientlig aktör. Imponerande samarbete mellan organisationer som annars är konkurrenter! Mest imponerande och rörande var nog Joe Marshall från Cisco Talos som berättade om de akuta insatser han gjort för att stötta Ukrainas elnät med synkroniserad tid trots pågående elektronisk krigföring som slår ut GPS-klockorna de använder. Se den om du börjat tappa hoppet om mänskligheten, Joe är en sann OT-hjälte! Dave Aitel från Cordyceps Systems slaktade begreppen "Secure by default" och "Software liability" på ett klokt och underhållande sätt. Vid sidan av alla presentationer pågår en massa andra aktiviteter. En som jag speciellt ser fram emot att höra resultatet från är "Vulnerability Management Pavilion" där 8 leverantörer visar hur de hittar, bedömer, presenterar och rekommenderar åtgärder för sårbarheter i en speciellt uppbyggd testmiljö. De 8 är aDolus, Finite State, Forescout, Framatome, Industrial Defender, Otorio, Runzero och Tenable. Jag har förstås pratat med många leverantörer och upptäckt en del nya spännande produkter som mycket väl kan tänkas dyka upp i hemmalabbet och i nyhetsbrevet framöver... Nästa år flyttar man hela konferensen till Tampa men förhoppningsvis kommer kvaliteten inte påverkas av att man kan ta in fler besökare! Storleken har betydelse! Ett litet förtydligande kring texten från förra nyhetsbrevet om att det finns en oro i en del organisationer som inte egentligen berörs av NIS2 för att de är i "fel" bransch men som skulle kunna hamna under NIS2 i alla fall för att de exempelvis satt upp solceller på taket. Det som behöver påpekas att det här bara är värt att oroa sig över om man är en tillräckligt stor organisation, över 50 anställda eller med mer än 10 miljoner Euro i omsättning. Är ni mindre så faller ni ut av det skälet. Floskeltoppen? Något som produkttillverkare i vår bransch är riktigt duktiga på är att ta meningsfulla ord och sedan använda/missbruka dem så mycket att de till slut förlorar sin egentliga mening och mest blir störande floskler. Ett sådant är tyvärr Zero Trust. Jag skriver "tyvärr" för jag tycker Zero Trust är värd ett mycket bättre öde än att ses som en säljfloskel! En fråga som dök upp från en läsare efter förra nyhetsbrevet var om det inte är dags att reda ut vad som är vad kring just Zero Trust inom OT-säkerhetsvärlden? Jag höll med, men insåg senare att jag faktiskt redan rotat runt i detta en del, främst i nyhetsbrev #45 och nyhetsbrev #43. Jag ska inte upprepa mig i onödan utan refererar till tidigare texter. Glöm förresten inte, apropå det, att det finns en sökfunktion på nyhetsbrevets sida. Jag använder den själv en hel del för att hitta bland mina egna gamla skatter... Det här är ett område där jag gärna skulle diskutera i mycket mer detalj med någon som kan Zero Trust bättre än jag! Men jag ska ändå konstatera jag fortfarande är positiv till tanken på Zero Trust inom OT-världen, även om man förstås får resonera lite annorlunda jämfört med IT. Mycket beror förstås på vilken typ av system vi talar om och vilka risker man är mest oroad över. I många situationer är det förmodligen dessutom helt enkelt orimligt att tänka sig något annat är blint förtroende, som att ett remote I/O inte skulle lita fullständigt på sin controller... I gränslandet mellan IT och OT finns det däremot gott om mycket rimliga platser att fullt ut tänka Zero Trust. Inte minst funktioner som är både viktiga och säkerhetsmässigt utsatta, som exempelvis remote access - som jag ju skrev om i förra utskicket. Här kan man ju dessutom dra nytta av "mänskliga" säkerhetsfunktioner som exempelvis eskorterade besök. Den svenska NIS2-utredningen skjuts fram! Ursäkta min tendens till click-bait i rubriken, men det är faktiskt i alla fall delvis sant. Den svenska utredningen som tittar på bland annat hur NIS2 och CER ska implementeras i svensk lag har fått utökad tid på sig för vissa delar av arbetet. Tyvärr då för några av de mest spännande delarna, nämligen hur man ska få direktiven att samsas med två andra kritiska svenska lagar, Säkerhetskyddslagen och Offentlighets och Sekretesslagen. Den första (och stora) delen av arbetet är ju faktiskt avrapporterad i ett massivt dokument på 522 sidor och det finns en del matnyttigt kring även Säkerhetsskydd i den delen. Efter en första genomläsning har jag konstaterat att det mesta följer direktivet väldigt väl (vilket ju faktiskt var syftet med det nya direktivet...) men jag har några reflektioner och saker som jag tycker är intressanta: Man rekommenderar att NIS2 implementeras i en lag kallad "Cybersäkerhetslagen". De flesta kommuner, regioner och myndigheter kommer omfattas av lagen. Alla universitet och högskolor omfattas. Personer i styrelser (!) får tillsammans med VD ett personligt ansvar för cybersäkerheten och kan i grova fall via domstol förbjudas agera i organisationen om säkerhetsarbetet inte fungerar. Inga krav på att använda certifierade produkter förrän sådana krav kommer från EU. Man struntar i att direktivet sätter 17:e/18:e oktober 2024 som startdatum och föreslår istället 1:a januari 2025. Det är man själv som organisation som ska avgöra om man omfattas av Cybersäkerhetslagen och i så fall anmäla sig till rätt tillsynsmyndighet. (Lite som säkerhetsskyddslagen alltså.) Det finns ingenting specifikt skrivet om OT-system, industriella system eller något i den stilen. Man talar om Cybersäkerhet men jag tycker nog inte det finns något tvivel om att alla former av Cybersäkerhet avses oavsett om det är IT eller OT. Man trycker speciellt på att organisationen i sin helhet omfattas av kraven även om det bara är en del av verksamheten som egentligen berörs. Det här är förmodligen klokt, det hade blivit en del kluriga gränsdragningar annars men det gör det där jag kommenterade i förra nyhetsbrevet om gränsdragning för exempelvis stora organisationer som producerar lite el verkar man inte ha identifierat som ett problem. Inte heller den enorma otydligheten kring hur kemikaliebranschen ska avgränsas. Som förväntat trumfar säkerhetsskydd kraven i Cybersäkerhetslagen. Det betyder även att vissa uppgifter eventuellt inte kan lämnas ut kring exempelvis en NIS2-incident. MSB pekas ut som sammanhållande i de flesta avseenden men ett antal nya tillsynsmyndigheter läggs till utöver dagens. På det hela är jag väldigt positiv till resultatet, inte minst för att det är nära till direktivets tänk! Vi ska komma ihåg att allt ovanstående är rekommendationer från utredningen men jag har svårt att se varför det i slutändan inte skulle bli som de föreslår? Det var synd att man inte redde ut fler av frågetecknen i direktivet men det kommer lösa sig över tid! Eftersom missad anmälan om att man omfattas av lagen finns bland anledningarna till att utdela sanktionsavgifter så blir det viktigt att verkligen göra en riktig analys även om man inte tror att man omfattas. Det kan bli helt avgörande att man kan visa på en riktig argumentation och ett formellt beslut av styrelsen. Det finns gott om klurigheter som gör detta till en bedömningssport och då behöver man vara övertydlig... Nu är CRA på gång! I förra nyhetsbrevet skrev jag om utmaningarna med att hålla EUs lagtexter enhetliga med tanke på att de översätts till 24 olika språk. Det har cirkulerat ett rykte om att CRA kommer skjutas fram till hösten just på grund av att den inte hinner bli översatt. Sedan tidigare är det känt att just översättandet generellt är en trång sektor för EU. Men det verkar vara ett falskt rykte eller åtminstone överdrivet! Den 12:e Mars var CRA nämligen uppe i Europaparlamentet, och helt enligt planerna så röstades det JA till förslaget. Om du är riktigt nördig kan du se omröstningen här. (Det är snabba ryck, ca 30 sekunder för omröstningen även om det efteråt blev lite stök kring någon som uppträtt illa under omröstningen.) Det här betyder inte att CRA är färdigt, det är ett antal ringar till som det ska hoppas igenom, somi princip bara är formaliteter även om det kommer ta ett antal veckor. En ny bekantskap! (Del 1) Beckhoff är ett välkänt tyskt märke i automationsbranschen med en lång historik. Jag har förstås stött på dem hos mina kunder, men jag hittills inte haft så mycket egen erfarenhet "hands-on". Det har ändrat sig nu, när en C6017-0020 - "Ultra-compact Industrial PC" dök upp i posten och förstås monterades upp i hemmalabbet direkt. Hade det handlat om utrustning från en annan leverantör hade jag kallat den en "PLC", men som du kommer se är det här lite annorlunda... Det första intrycket var imponerande - den har den där härliga massiva tyngden av solida material och rejäla kylflänsar. På pappret borde prestandan vara hel okej också; 4-kärnors Intel CPU, 8 GB RAM, 40 GB SSD och 4 stycken portar med Gb Ethernet. Lite senare visade det sig att den dessutom var extrautrustad med Beckhoffs inbyggda mini-UPS. En snabb test visade att den "på tomgång" klarar ungefär 5 sekunders störning i strömmatningen vilket gör att man kan undvika onödiga stopp vid korta störningar. Bra där! Om man är van vid PLC:er från andra tillverkare kan Beckhoffs tänk kännas ovant. Deras automationsprogramvara, "TwinCAT", går att köra på vilken dator som helst. Men vill man ha en robust hårdvara som tål tuffa miljöer så installerar man mjukvaran på en av deras datorer, liknande den som jag fick fingrarna på. Beckhoff är för övrigt också kända för att de skapade fältbuss-protokollet "EtherCAT" som numera är en fristående IEC-standard som stöds av mängder av tillverkare. Beckhoffs utrustningar är rent principiellt "vanliga" datorer som i de flesta fall kör Windows eller Beckhoffs variant på FreeBSD, TwinCAT/BSD. I och med det så går det enkelt att kombinera PLC-applikationer med helt andra programvaror. Konfigurationen sker via ett lokal webbgränssnitt vilket gör det enkelt att göra rätt. Jaha, Windows tänker du kanske? Men Beckhoff har inte bara slängt in Windows lite hur som helst utan har sett till att det beter sig på ett sätt som anstår en "PLC". Ett exempel på det är deras "Write filter" som gör att förändringar i systemet inte blir bestående utan att man lätt kan "backa" till en känd konfiguration. BSD-varianten har Jails och kan hantera både Docker-containers och virtuella system samtidigt som man kör TwinCAT-runtime. Riktigt coolt! Framöver kommer det ske en gradvis övergång från Windows till Linux, vilket är en intressant trend... Hårdvaran finns i en massa spännande varianter som jag verkligen kan se tilltala det kreativa automationsfolket. Det finns allt från de ultrakompakta, där den variant jag testar ingår, hela vägen till brutala serverlösningen "Control cabinet industrial server" med 40 CPU-cores. Vill man exempelvis ha direktanslutning till många nätverk kanske mini-varianten på bilden passar, med 9 ethernet-portar!? (Det är alltså inte en inbyggd switch, utan 9 stycken separata interface!) Jag hade hoppats skapa ett testprojekt i TwinCAT med någon lämplig testmiljö i FactoryIO, men jag har helt enkelt inte haft möjlighet att lägga den tiden. Men jag kan direkt konstatera att både hårdvara och mjukvara imponerar, allt tuffade igång utan problem så jag får be att återkomma om programmerandet i framtiden! Det ser i alla fall mycket lovande ut. En cool möjlighet är att man kan installera hela utvecklingsplattformen direkt på "PLC:n", tack vare att den ju faktiskt har ett "normalt" operativsystem. Om du har erfarenhet av att bygga system med TwinCAT vill jag väldigt gärna höra om dina erfarenheter! Jag har närmast lite mer "exotiska" planer för att testa vad hårdvaran i sig går för. Testerna kommer dessutom ske tillsammans med ett par helt andra spännande produkter, en som varit med tidigare i nyhetsbrevet och en nykomling i labbet. Fler nya bekantskaper... (Del 2) När jag ändå hade tillgång till den imponerande lilla Beckhoff-datorn smidde jag lite annorlunda planer för att se vad hårdvaran i sig går för. Om du läste min text om Cyolo i förra nyhetsbrevet så vet du att jag gillar deras lösning för säker fjärråtkomst i OT-system. Min tanke nu var att se om man skulle kunna installera hela deras funktionalitet i en hårdvara som går att placera ute i ett minimalt apparatskåp? Planen blev alltså att komplettera min existerande Cyolo-installation i hemmalabbet med ytterligare en Cyolo IDAC-server som körs på Beckhoffs lilla kraftpaket - skulle den räcka till? Det blir dessutom ett test av klustringsfunktionen i Cyolo - är den så enkel att få till som de påstår? Spännande redan där men det är nu som jag kan presentera ytterligare en nykomling i hemmalabbet... Det danska företaget Bifrost Connect har också skapat en lösning för säker fjärranslutning, men de har valt en väldigt annorlunda målgrupp och metod jämfört med Cyolo. Det de siktar in sig på är nämligen att komma åt konsol-anslutningar på system via HDMI, tangentbord, mus eller via serieport. De gör det genom att kombinera en molnbaserat tjänst och en batteridriven (!) enhet som fixar den fysiska anslutningen. I det enklaste fallet ansluter du Bifrost-enheten via HDMI och USB för att skapa en simulerad skärm, tangentbord och mus. Batteriet räcker länge men laddas när enheten är ansluten till en USB-port. Kommunikationen mellan enheten och molntjänsten går via en inbyggd 4G-anslutning eller WiFi. De använder krypterad WebRTC som skyddar kommunikationen hela vägen från molntjänsten till enheten, och kan använda TURN-servrar som proxy om det behövs. Det här lät ju väldigt intressant så jag fick låna ett par enheter av Bifrost Connect. För att göra testet lite mer intressant så anslöt jag en Bifrost-enhet till Beckhoff-datorn dagen innan jag åkte till S4-konferensen... Kommer det funka bra även från andra sidan Atlanten? Det känns som ett bra test, eller hur? Som förväntat vaknade jag jetlaggad, alldeles för tidigt första morgonen, så varför inte använda tiden till att börja installera Cyolo? Jag tog och installerade om Beckhoff-enheten helt, med Ubuntu-linux som jag sedan installerade mjukvaran Cyolo på. Det låter ju enkelt tills man tänker på att jag behöver hantera datorn i UEFI/BIOS-läge för att välja ny boot-disk mm vilket kräver åtkomst till skärm och tangentbord.... Perfekt för Bifrost Connect med andra ord! Redan innan det var dags för frukost hade jag redan installerat Ubuntu och startat Cyolo. Smidigt och enkelt utan några större klurigheter! Jag ska passa påpeka att den nya Cyolo-servern uppförde sig perfekt. Den bildade helt automatiskt ett kluster med den tidigare IDAC-servern och dök upp i administrationsverktyget precis som utlovat. Otroligt imponerande i sin enkelhet! IDAC-servern vill egentligen ha en större disk än vad som finns installerad i min lilla Beckhoff-dator, men för enklare användning fungerar det hur bra som helst! Snyggt jobbat Cyolo! Beckhoff-datorn å sin sida gör också precis allt den ska och med imponerande prestanda och enkelhet! Nu har jag inte testat att dra nytta av att den har 4 nätverksinterface, men jag ser ingen anledning till att det skulle strula. Snyggt jobbat Beckhoff! Och när det gäller Bifrost Connect så märktes inte avståndet på något vis, webbgränssnittet kändes i princip som att sitta framför bildskärmen hemma! Förutom alla grundläggande funktioner, som behörighetsstyrning av vem som får ansluta till vilken enhet och loggning av alla aktiviteter, kan de även göra en del andra trick som jag inte haft möjlighet att utforska ännu, men som låter intressanta: Du kan koppla två enheter till varandra, "rygg mot rygg", över Internet vilket skapar ett slags VPN-lösning mellan dem. Enheterna har 6GB lagring som man kan presentera som en USB-disk till det anslutna systemet Man kan ansluta till en ren konsolport, RS232 eller USB. Användbart för nätverksutrustning, OT-prylar och annat med sådan anslutning. Med två enheter kan man tunnla en serie-ansluten konsolport (RS232 eller USB) på distans. Det finns en reläport så att man kan styra strömmen till den styrda enheten och därmed göra "hårda" omstarter. Det finns en ethernet-port vilket gör det möjligt att göra en "lokal" SSH-anslutning från Bifrost-enheten. Om man vill ha handgriplig kontroll över hur uppkopplingar sker så finns enheten i en version som kallas "Attended Access". Det är en listig lösning där den lilla displayen på enheten visar en sifferkod som man ger till den som ska koppla upp sig. En smart kombination av tvåfaktor-inloggning och operatörs-godkännande! De har en ovanligt vettig beskrivning av säkerhetsaspekterna i deras lösning som är värd att ladda ner och titta på. Det känns lite fel att jämföra Cyolo och Bifrost Connect. De har förstås likheter, men de problem som de försöker lösa är ganska olika. Bägge gör det dock väldigt bra, och det ska bli intressant att utforska kombinationen av dem båda lite mer! Jag ser dem nämligen inte som konkurrenter, men som intressanta komplement till varandra. Blir sårbarhetshantering ännu enklare med dioder? En fråga som dök upp efter min text i förra nyhetsbrevet om att förenkla sårbarhetshantering med en genomtänkt segmentering var om inte nätverksdioder kunde spela en viktig roll i detta? Jag tyckte det var en spännande fråga som förtjänar lite extra uppmärksamhet... Jag ska direkt säga att jag inte har använt nätverksdioder eller CDS-lösningar med just sårbarhetshantering som mål, men det är ganska uppenbart att det kan ge stora fördelar - även om det i många fall kanske inte ens är huvudsyftet med att införa den typen av teknik. Mest uppenbart blir det förstås om man överväger en ren nätverksdiod, där ett system som är på "uppströms-sidan" av dioden är fysikaliskt omöjligt att nå från andra sidan. Det är ju faktiskt hela vitsen med dioden och ungefär så bra skydd man någonsin kan få mot nätverksburna angrepp... Men även system "nedströms" kommer i de flesta fall bli svårare att angripa men det beror förstås till en viss del på vilken typ av filtrering som sker i dioden, vilket nätverksprotokoll som är aktuellt och naturligtvis vilken typ av angrepp man vill undvika. När det gäller CDS-lösningar blir det alltid lite mer av en bedömningssport, men eftersom hela tanken med en sådan lösning är att "plocka isär" kommunikation i sina beståndsdelar kommer de flesta angrepp i praktiken bli väldigt svåra att få igenom en CDS-gateway. Förutom att skydda mot angreppet blir det i de flesta fall även ett visst skydd mot skadeverkningar även om angreppet faktiskt skulle lyckas. Stöld av information eller manipulation av en process är ju definitionsmässigt omöjligt i "fel riktning" genom en diod. När det gäller förenkling av sårbarhetshantering bör rimligen diod-liknande teknik vara en hit! I de flesta fall borde analysen av en ny sårbarhet bli enklare och det borde i slutändan även resultera i färre panik-uppdateringar! Nu har jag faktiskt läst den... Jag slog ett slag för Andrew Ginters senaste bok redan i nyhetsbrev #57, men då hade jag inte läst den. Nu har jag ändrat på det och kan komplettera med lite egna tankar kring innehållet... Andrew är kanske mest känd från den podcast han gör hos sin arbetsgivare Waterfall Security. Det går inte att missa att det finns en väldigt tydlig koppling till Waterfalls produkter i boken men det gör ingenting, eftersom resonemangen håller och det är dessutom bra produkter! Boken "Engineering-Grade OT Security - A managers guide" verkar fortfarande gå att få skickad gratis från USA eller köpa direkt från Amazon. Jag rekommenderar att du läser boken själv, men jag ska i alla fall återberätta några av alla de tankar som jag tycker han fångar på ett bra sätt i boken: Man hör ofta om skillnaderna mellan säkerhet inom IT och OT men som Andrew mycket riktigt påpekar är det nästan lika stora skillnader inom OT-säkerhet mellan olika branscher! Visst är Safety viktigt överallt, men i vissa verksamheter är det helt avgörande medan andra, med rätta, fokuserar bredare. I vissa branscher finns massor av känslig information i OT-systemen och i andra inte alls. Viktigt att ha med sig när man diskuterar filosofier inom OT-säkerhet! Boken knyter an till de tankar som blivit moderna på senare år, en återgång till att hantera vissa av de risker som orsakas av moderna OT-teknik med hjälp av säkerhetsåtgärder från helt andra områden, exempelvis mekaniska hinder för allvarliga konsekvenser. Här finns mycket att hämta för att få digital teknik och fysiska processer att gå mer hand i hand... På samma tema har Andrew en bra diskussion kring den ibland heta debatten om vad en "OT-säkerhetsincident" egentligen är. Man hör ofta att det är ovanligt med "riktiga OT-incidenter" vilket avser att de flesta produktionsstörningar beror på ett för stort beroende av IT-system snarare än att en hacker manipulerat en PLC. Det är en åsikt som jag håller med om men det är egentligen inte så intressant om man trots allt är intresserad av att hålla sin produktion igång! Det sätter också fingret på att det kan finnas IT-system som behöver skyddas som om de var OT-system, ett jobbigt sätt att tänka för en del organisationer... Ett begrepp som jag arbetat med inom exempelvis kärnkraftsvärlden är det som tidigare kallades "Dimensionerande Hotbeskrivning", DHB och som numera oftast får heta DAF istället "Dimensionerande Antagonistisk Förmåga". I boken talas det om cDBT, "Cyber Design Basis Threat" vilket är samma sak men med fokus just på cyberhot. Det här är ibland något som man får av Säkerhetspolisen om man är en säkerhetsskyddad verksamhet, men det är också något man kan definiera för sin egen verksamhet. Det handlar helt enkelt om att definiera vilka typer av attackförmågor som man ska kunna hantera. Detta är något som jag ofta rekommenderar mina kunder att ta fram eftersom det skapar en enhetlig bild av vad man ska klara av. Det många inte tänker på är att det faktiskt också är en definition av "Risktolerans", det där kluriga begreppet som jag sett få faktiskt göra något bra med. Om man i en cDBT/DAF definierar vilka förmågor och hot man ska klara av så har man ju faktiskt också sagt att "allt annat är det okej att vi inte kan stå emot". Det här kan vara en jobbig diskussion, men oj så viktig! Ordet "Sårbarhet" orsakar ibland missförstånd. De flesta tänker nog på en brist i en mjukvara som går att fixa med en patch. Men i många sammanhang betyder ordet mycket mer, det är vilken svaghet som helst, i vad som helst, som möjliggör något slags angrepp. Viktig skillnad att ha med sig! Jag träffade Andrew under S4-konferensen så jag kunde både tacka för en bra bok och bekräfta för honom att jag håller med om hans syn på att OT-säkerhet måste utformas på ett sätt som drar nytta av skydd i både den fysiska processen och "cyberdelarna". Det är tyvärr alldeles för vanligt att man försöker lösa utmaningarna "på samma sätt som IT gör" och helt missar möjligheterna med åtgärder i hur processen är utformad! Det gäller i synnerhet de allra värsta konsekvenserna som man helt enkelt vill bygga bort! Järnspindeln är här - se upp med dina HMI:er! Ett nytt spännande forskningspapper beskriver hur man skapat en ny klass skadlig kod riktad mot PLC:er via webb-baserade HMI:er. Det är Ryan Pickren, Tohid Shekari, Saman Zonouz och Raheem Beyah på Georgia Institute of Technology som ligger bakom arbetet. De drar nytta av att moderna PLC:er ofta har en inbyggd webb-server för att bygga HMI-bilder med. Det tillsammans med den dåliga idén att låta "kontors-datorer" komma åt HMI-bilderna direkt från PLC:n skapar en intressant möjlighet att manipulera PLC:ns beteende. (Alternativt att "OT-datorer" får surfa på Internet, vilket är en ännu sämre idé...) Jag ska inte försöka mig på att sammanfatta metoden mer än så, utan rekommenderar en genomläsning. Om du är någorlunda hemma i webb-teknik så går det enkelt att förstå denna unika metod. Spännande! Kul trend! Det börjar röra på sig så smått bland tillverkarna av OT-produkter när det gäller säkra utvecklingsrutiner. Ett tecken på det är ett ökande intresse för certifiering på det här området och då ofta IEC 62443-4-1. Ett lite extra kul exempel är varumärket Anybus som ingår i den svenska HMS Networks. (Du kanske minns min test av en Ewon-enhet i nyhetsbrev #57?) De har precis annonserat att de certifierat sig på mognadsnivå 3 av IEC 63443-4-1! Nivå 3 är alltså den näst högsta nivån, det finns från 1 till 4. (Detta trots att -4-1 bygger på CMMI-DEV som ju har fem nivåer. I -4-1 slår man ihop nivå 4 och 5 till en nivå...) Med tanke på att produkter från Anybus ofta byggs in produkter från andra tillverkare så blir det förstås avgörande att de håller minst lika hög nivå av säkerhet som sina direkta kunder! Ett viktigt steg förstås också inför de kommande CRA-kraven. Grattis HMS Networks och bra jobbat! Konsten att säga nej Jake Brodsky har skrivit en kort text om det viktiga med att kunna säga nej. En konst som kan tyckas vara enkel, men där det ofta handlar om att kunna ta en diskussion kring vad som är viktigt i den svåra avvägningen mellan att skydda verksamheten och att utveckla den. Det här är något jag stött på i alla branscher jag arbetat med, allt från kryssningsfartyg till verktygstillverkning. Det handlar i slutändan om att säkerställa att rätt beslut tas av rätt person baserat på rätt information. För att vi säkerhetsmänniskor ska bli respekterade som relevanta personer att ha med i en diskussion finns det några saker där jag tycker vissa kollegor i branschen ibland går lite för långt: Ta inte säkerhet personligt! Vi tycker det är viktigt med säkerhet, men om du blir upprörd av en diskussion så kommer du förlora den! Säkerhet har inget egenvärde! På samma sätt som att ingenting är 100% säkert måste vi vara bekväma med att navigera kompromisser där både säkerhet och nytta "får sitt". Säkerhet är inte motsatsen till nytta! Säkerhetsåtgärder blir mycket enklare att sälja in om de presenteras som möjliggörare av nya sätt att arbeta som man inte "vågat" tidigare. Tack för den, SÄPO! En av mina käpphästar är att det gått lite väl mycket inflation i användning av säkerhetsskydd i vissa branscher. Samtidigt ska jag direkt erkänna att det är ett svårt område att bedöma och applicera, i synnerhet när det handlar om OT-säkerhet. SÄPO har nu skapat ett stöddokument för att hjälpa organisationer att förstå vilka delar av verksamheten som kan vara att betrakta som säkerhetskänsliga. Jag hade kanske hoppats på lite mer klarspråk, men vi fick i alla fall svart på vitt att dagis och begravningsbyråer inte är säkerhetskänsliga. Men visst, det är faktiskt varje organisations eget ansvar att bedöma detta och då ska inte SÄPO skriva ett facit. Läs speciellt avsnitt 3, "Skadekonsekvenser på nationell nivå", det är det viktigaste i mina ögon. Det här kommer ju dessutom bli ett extra intressant område att följa framöver i och med inträdet i NATO. Har du tid? Om du gillade min lilla test av tidsprogramvaran Timekeeper i förra nyhetsbrevet så kanske du gillar Jörgen Städjes text "För Sverige i tiden". I hans artikel nämner han även sajten gpsjam.org som ger en intressant bild av hur mycket störningar det är kring GPS-systemet och var i världen det sker. Väl värt att ha med sig i bakhuvudet när man pratar om tjänster som hanterar tid eller plats! Team82 fortsätter i samma stil! Clarotys forskargrupp Team82 kör vidare i sin kampanj att vända ut och in på OPC UA. Nu är artikelserien uppe i del 9, där de visar hur de hittade problem i Softings integrationsserver "SIS". En intressant djupdykning med videos och allt: Om du missat någon av de tidigare delarna så finns de förstås tillgängliga: OPC UA Deep Dive (Part 1): History of the OPC UA Protocol OPC UA Deep Dive (Part 2): What is OPC UA? OPC UA Deep Dive (Part 3): Exploring the OPC UA Protocol OPC UA Deep Dive Series (Part 4): Targeting Core OPC UA Components OPC UA Deep Dive Series (Part 5): Inside Team82’s Research Methodology OPC UA Deep Dive Series (Part 6): A One-of-a-Kind Exploit Framework OPC UA Deep Dive Series (Part 7): Practical Denial of Service Attacks OPC UA Deep Dive Series (Part 8): Gaining Client-Side Remote Code Execution Vad finns i dina mjukvaror? Det är mycket snack i branschen kring SBOM (Software Bill Of Materials), alltså innehållsförteckningar för mjukvara som bland annat EU via CRA kommer kräva av alla mjukvaruleverantörer. Det här är fortfarande en väldigt omogen värld där det finns en massa kluriga utmaningar, men där det också sker en massa spännande framsteg. Om du är fundersam över alla utmaningar och vad märkliga akronymer som PURL, spdx, SASBOM, CBOM och CycloneDX betyder så kan jag rekommendera ett avsnitt av Dataföreningens "Prata EU Cyber Resilience Act med oss". Olle E Johansson och Per-Erik Eriksson berättar om det senaste i den här världen. Ska vi höras? I ett tidigare nyhetsbrev öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt så jag kommer repetera den här texten framöver. Jag har redan haft ett antal kul samtal med roliga människor från spännande verksamheter av alla de slag. Du behöver förstås verkligen inte vara proffs på just OT-säkerhet för att det ska bli ett intressant utbyte av erfarenheter och tankar! En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite. Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt. Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra. Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats. Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! En massa cool teknik blir det den här gången - inte mindre än två tester av riktigt trevlig teknik, direkt från hemmalabbet! Jag filosoferar kring hur man kan spara en massa administrativ tid genom klok segmentering. Det blir mycket snack om EU-lagar också, det är verkligen ett hett område just nu! 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å 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! Nya tider! Min högst personliga åsikt är att någonting hände vid nyår. Helt plötsligt pratar alla organisationer om NIS2. Är det så enkelt att det är ny budget och nya mätetal eller har poletten trillat ner ute i landet? I vilket fall som helst har tillströmningen av nya spännande kunder som vill ha stöd i gränslandet där NIS2 möter OT-säkerhet verkligen exploderat. Jag stöter på alla tänkbara varianter på hur man ser på lagstiftningen och på hur den egna organisationen "drabbas". Allt från den väldigt sunda inställningen "Vi omfattas inte av NIS2 men våra kunder gör det - låt oss kapa åt oss konkurrensfördelar genom att bli duktiga på säkerhet" till struts-taktiken "Nä, det verkar lite konstigt att vi skulle vara samhällsviktiga så det måste vara fel!". Om man inte är så intresserad av EU, lagstiftning eller kravstandarder kan tyckas vara väldigt mycket snack om lagstiftning nu, inte minst i det här nyhetsbrevet! Men jag tror faktiskt kombinationen av NIS2, CRA och Maskinförordningen kommer ha en enorm effekt på hur vi arbetar med risk och säkerhet kring våra OT-system. Och ALLA kommer påverkas även om man inte själv faller direkt under någon av lagstiftningarna. Som vanligt kommer vi förmodligen överskatta effekten på kort sikt, men samtidigt underskatta den på lite längre sikt. Apropå längre sikt så meddelade justitieministern i Nederländerna nyligen att man inte kommer hinna klart med NIS2 och CER till deadline den 17:e oktober. Några dagar senare annonserade det danska försvarsministeriet liknande problem. Andra länder, med Finland i spetsen, ligger väldigt bra till. Vi får se hur det går i Sverige, utredningen har sin deadline i slutet av februari och då kanske planen framåt klarnar lite? Det är många steg kvar tills allt är klart... Samtidigt förändras sättet man bygger system på ett ganska radikalt sätt. Även här kommer det ta lite längre tid än vad vi tror (eller hoppas) men det kommer! Se exempelvis texten längre ner om den möjliga trenden att lämna OPC UA till fördel för MQTT, en detalj kan tyckas - men ändå. Ett annat exempel är det där läskiga begreppet "IT/OT-convergence" som många tror bara handlar om teknik, när det stora skiftet snarare (om du frågar mig) kommer handla om människor och arbetssätt. Sakta men säkert ser vi människor som är vana vid arbetssätten inom IT börja närma sig OT-världen och i takt med det kommer nya produkter - exempelvis är det äntligen dags för virtuella PLC:er, helt nya utvecklingsverktyg (läs exempelvis den här texten av Peter Kurhajec om Siemens SIMATIC AX) och nya sätt att bygga mjukvarudefinierade nätverk (exempelvis Veracitys nya nätverksappliance). Det här gör att vi i OT-säkerhetsbranschen verkligen behöver hänga med i utvecklingen för att inte uppfattas som de gamla vanliga stoppklossarna som säkerhetsfolk lätt blir. Jag skrev om detta för några utgåvor sedan, när jag jämförde säkerhetsarbete med teatersport. Det gäller verkligen att arbeta in de nya lagkraven och de nya arbetssätten i detta. Om säkra system ska möjliggöra nya verksamheter och affärer behöver vi sluta svara "Nej, det är för osäkert" eller "Nej, det får man inte enligt NIS2" och istället säga "Ja, om vi löser X och Y för att möta CRAs krav" eller "Ja, men då behöver vi byta till en modern arkitektur". Det är spännande tider som väntar oss framöver! ...och apropå tid... Ur led är tiden! Den klassiska frasen fick vi av Shakespeare i Hamlet, men det var nog inte våra datorers klocksynkronisering han tänkte på. I takt med att tiden spelar en allt viktigare roll för många delar i våra OT-system blir det också viktigare att hålla koll på klockorna i alla system. De behöver gå rätt och de behöver gå lika. Det är inte helt ovanligt att man använder någon form av GPS-baserad mottagare för att få en bra referensklocka att utgå ifrån och sedan sprider tiden i nätverket med exempelvis NTP-protokollet. På senare tid har det blivit väldigt uppenbart att GPS-systemet är sårbart för attacker, både för navigerande flygplan och för dem som vill ha rätt tid! På samma sätt kan man tänka sig att välkända tidskällor på Internet skulle utsättas för attacker. Keysight är ett företag vars produkter jag testat och skrivit om förut, det har exempelvis varit nätverkstappar eller aggregationsswitchar för att samla in kopior av all nätverkstrafik. I nyhetsbrev 29 skrev jag om deras brutala nätverkstestare BreakingPoint. Det totala produktsortimentet innehåller en närmast bisarr mängd coola lösningar. Den här gången har jag tittat på en produkt som heter Timekeeper. Timekeeper gör precis vad namnet hintar om, den håller koll på tiden från ett antal valfria källor. Kvaliteten på tids-informationen analyseras hela tiden (!) och kan presenteras i grafer och statistik. Om någon tidskälla avviker på ett orimligt sätt eller om någon signal visar tecken på att vara spoofad så kommer den att ignoreras när "rätt tid" bestäms. "Den rätta tiden" kan sedan spridas på nätverket via NTP. I exemplet nedan ser du en graf över hur det såg ut i mitt hemmalabb. Timekeeper är vid pilen, och ovanför finns de NTP-källor som är konfigurerade och nedanför är några av de klienter som hunnit ansluta. NTP i tillsammans med Timekeeper är en imponerande kombination. Timekeeper är löjligt enkel att få igång och avvikelserna i tiden ligger på några tusendelar av en sekund bara genom att använda öppna NTP-källor på Internet. Om man vill ansluta egna GPS-mottagare eller PTP-källor så finns stöd för det också. Underskatta inte behovet av bra tid, det uppstår väldigt märkliga fel när tiden är dåligt synkad... Jag avslutar med en tråkigare nyhet, nämligen att Dave Mills som uppfann NTP nyligen gick ur tiden (!) vid 85 års ålder. Jag skickar en tacksam tanke till honom och alla andra pionjärer som lade grunden till mycket av det vi tycker är självklart, men fortfarande spännande, idag. Mindre slit genom att göra mer? OT-Säkerhet är ett område som ger oss många spännande utmaningar. Men ibland känns det frustrerande att de säkerhetsåtgärder vi tar inte ”räcker hela vägen”. En anledning till det tror jag kan vara att man försöker implementera en åtgärd åt gången istället för att se hur olika åtgärder kan förstärka varandra. Ett intressant exempel på två områden som verkligen kan förstärka varandra är sårbarhetshantering och segmentering. Med sårbarhetshantering menar jag i det här sammanhanget det håra arbete som man står inför om man ska försöka hänga med i alla nya sårbarheter som annonseras för att kunna analysera hur de slår mot alla komponenter man har och i vilka sammanhang som det faktiskt är värt att störa produktionen för att lägga på en säkerhetsrättning. Det är ju här som skillnaderna mot IT-världen kanske blir som allra tydligast för många. När jag pratar om segmentering tänker jag främst på arbetet att dela upp nätverk, dataflöden och system inom OT-miljön. Att separera ”IT” och ”OT” förutsätter jag är hanterat även om mitt resonemang här skulle kunna fungera lika bra på den uppdelningen. För båda dessa utmaningar blir en absolut förutsättning för att kunna göra någonting alls att man har tillgång till pålitlig information om vilka komponenter man har, hur de sitter ihop och hur dataflöden mellan dem ser ut. Det betyder (som vanligt) att vi är beroende av att vi har verktyg och processer som hjälper oss med detta. Att löpande bedöma vilken risk som nya sårbarheter orsakar för organisationen är ett tufft jobb av många skäl. Ett sådant skäl är att även en enkel systemmiljö har många komponenter som var för sig kan påverka helheten på kluriga sätt. Det är här som kopplingen till segmenteringsarbetet blir en möjlighet att göra arbetet mycket enklare. Arbetsordningen för att bedöma en ny sårbarhet kan se ut så här: Bevaka alla relevanta källor för att fånga upp alla nya sårbarheter som eventuellt kan vara aktuella någonstans För varje sårbarhet: Förstå sårbarheten (Vad påverkas, hur och under vilka förutsättningar?) Identifiera alla komponenter i vår miljö som möjligen berörs av sårbarheten För sårbarheten - bedöm varje komponent: Går sårbarheten att utnyttja i just denna komponenten på det sätt den används hos oss? (Med tanke på andra skydd och arkitekturen) Hur påverkas komponentens pålitlighet om sårbarheten utnyttjas? Hur påverkar verksamhetens risk av att komponenten inte går att lita på? Vilka skydd finns som kan minska verksamhetens risk? (Härdning, segmentering etc?) Ett av problemen med det här resonemanget är att alla komponenter både blir en potentiell sårbarhet OCH samtidigt en del av skyddet mot angrepp. Det gör att analysen blir väldigt komplex! Jag föreslår att vi istället vänder resonemanget på huvudet och utgår ifrån att alla komponenter alltid kommer vara sårbara och istället fokuserar på att omgärda dem med tydliga säkerhetsåtgärder. Då behöver vi bara bedöma hur säkerhetsåtgärderna eventuellt påverkas av den nya sårbarheten medan vi vi med flit struntar i allt som inte är exponerat. Det låter ju onekligen lite enklare… Om du tycker det här låter som en jobbig kompromiss så har du förmodligen rätt. Att jag tycker den i många fall är okej är att man i slutänden ändå väljer att skjuta upp patchningen på grund av något annat skydd, exempelvis just segmenteringen. Med det tänket blir bra säkerhetsåtgärder extremt avgörande och det är här kopplingen till segmenteringsarbetet dyker upp. Jag tänker mig att vi gör en ”riktig” segmentering i still med vad IEC 62443 del 3 pekar på, och använder säkerhetszoner (”Zones” i standarden) som sammanbinds av det standarden kallar ”Conduits”. När folk pratar om segmentering brukar det lätt bli en ren nätverksfråga och det är här nästa nyckel till mitt resonemang finns. Tricket ligger i att vara så pass systematisk i designen att man faktiskt har koll på vad som exponeras i respektive system. Att göra det ur ett nätverksperspektiv är inte så svårt, det handlar ofta om att öppna portar i något slags brandvägg. Utmaningen ligger i att hantera det som exponeras! Ett exempel på varför det här är viktigt: Det vanligt att jag stöter på organisationer där man noggrant segmenterat sitt nätverk men att man samtidigt tillåter Windowsdatorer att prata ganska fritt över segmenteringsgränserna för att komma åt filer, använda Active Directory, skriva ut osv… Det innebär att man segmenterat nätverket på ett sätt, men ur ett Windowsperspektiv så ser segmenteringen väldigt annorlunda ut! Det betyder att en Windows-tjänst som exponeras i en säkerhetszon potentiellt ”drar med sig andra säkerhetszoner i fallet”. Det går ofta inte att undvika men då ska vi ha koll på det och bygga vårt riskresonemang utifrån det! Exempelvis undvika att hamn i situationer där en Windows-dator med flera nätverksanslutningar används för att knyta ihop olika nätverk eller säkerhetszoner, då har en redan onödigt stor säkerhetszon blivit ännu större och väldigt mycket mer komplex. Om vi gjort en klok segmentering och därmed har koll på vilka säkerhetsåtgärder vi har och vilka tjänster i andra komponenter som är exponerade behöver ovanstående metod för att analysera en sårbarhet bara titta på säkerhetsåtgärderna och de exponerade tjänsterna. Det är en enorm minskning av mängden arbete, både för att volymen är mindre men också för att den ordning och reda man skapat gör det väldigt enkelt att identifiera vad som är relevant att bedöma! Om man kan dra nytta av moderna sätt att annonsera sårbarheter går det dessutom att automatisera en del av arbetet! Eftersom uppdelningen i ”Zones” och ”Conduits” är tänkt att vara riskstyrd blir nästa nytta man kan ta del av att bedömningen av en sårbarhet blir enklare eftersom det är möjligt att definiera en enhetlig riskprofil per Zone och Conduit. Observera att grunden för att kunna dra nytta av detta inte i första hand är tekniska lösningar, utan en klok metod för att göra och dokumentera hur man designat segmenteringen, tillsammans med vettiga procedurer för hur man följer med i floden av annonserade sårbarheter. Däremot är tekniken förstås helt avgörande för att kunna implementera detta i praktiken. Nätverkssegmentering kan exempelvis vara en valfri kombination av klassiska centrala brandväggar med tillhörande switchar (exempelvis Fortinets prylar), lokalt skydd ute i anläggningen (exempelvis TxOnes Edge-serie) eller mjukvarudefinierade nätverk (exempelvis Veracity). När det gäller komponentinventering, trafikflödesanalys och riskanalys kan det vara bra med en valfri kombination av specialiserade verktyg för inventering (exempelvis OTbase), en modern detekteringsplattform (exempelvis Nozomi) eller en plattform för förebyggande riskanalys (exempelvis Otorio RAM2). Som vanligt blir bra verktyg helt fantastiska i händerna på något som använder dem rätt! Vad är kemikalier egentligen? Arbetet med att få NIS2 att landa i alla EUs länder pågår, vissa länder gör som Sverige och implementerar en nationell lag, medan andra länder har andra metoder. När den delen är klar återstår ett väldigt intressant arbete, nämligen att reda ut vad kraven i direktivet egentligen betyder i vardagen. Det finns nämligen en del klurigheter i direktivs-texten som går att tolka lite olika. Jag har själv hängt upp mig lite på en av dem, frågan om vad som egentligen ingår i kemikalie-sektorn? (Extremt nördigt - jag vet! Sorry...) Vilka organisationer som omfattas av direktivet är ju onekligen en viktig fråga och här är det faktiskt inte speciellt tydligt i mina ögon. Eller egentligen... Det är jättetydligt men på ett sätt som inte känns rimligt! Bland alla nya sektorer som ingår i NIS2 finns punkten "Tillverkning, produktion och distribution av kemikalier" med i listan. Det låter ju ganska uppenbart vad det handlar om ifall man använder den vardagliga definitionen av vad en kemikalie är. Utmaningen är den sista delen av definitionen som du ser i bilden här ovan: "...företag som producerar varor ... genom att använda ämnen och blandningar". Klurigheten uppstår när man tar reda på vad EUs definition av orden "varor", "ämnen" och "blandningar" är. Enkelt uttryckt är en vara något vars funktion framför allt bestäms av vilken fysisk form den har, medan ett ämne och en blandning helt enkelt är ett eller flera grundämnen utan någon speciell funktion. Vill du dyka i de exakta definitionerna så hittar du dem i EUs kemikalieregelverk "REACH" under "Artikel 3": Då är frågan, vad har vi för vardagliga exempel på verksamheter som tar ett eller flera ämnen och producerar en vara av dem? Det måste ju vara viktigt eftersom det innebär att man då automatiskt definieras som samhällsviktig verksamhet! Det finns nämligen inga andra generella begränsningar eller undantag i direktivet; är du verksam i en sektor som omfattas av direktivet och har en tillräckligt stor verksamhet så träffas du av NIS2! Vad tror du om exemplen nedan? Visst är de alla rimliga exempel på att man tar ämnen och gör varor av dem? Känns någon av dem som rimliga exempel på verksamheter som automatiskt bör vara samhällsviktiga? Tillverka synålar av stål Valsa ut ugnsfolie av aluminium Göra elektriska ledare av koppar Göra örhängen av silver Naturligtvis kan de här typerna av verksamheter att vara väldigt viktiga för vårt samhälle! Men är alla det? Den mest extrema slutsatsen blir ju faktiskt att alla producerande verksamheter som använder kemikalier i produktionen kommer omfattas av direktivet eftersom det knappast går att skapa något annat av kemikalier förutom varor eller andra kemikalier! Allt det här känns intuitivt inte rätt! Jag har svårt att tro att det här var tanken med den här definitionen. Men var drar man gränsen då? Och baserat på vilken regel? Jag har skickat den här frågan till lämpliga instanser inom EU, kontaktpersoner på myndigheter i både Sverige och andra länder, till jurister jag känner samt en rad andra kloka kontakter men hittills inte fått något tydligt svar på var jag resonerar fel. Det finns fler gränsdragningar som behöver bli tydligare kring hur NIS2 ska begränsas. Är dessa rimliga exempel? Ett stort företag med en verksamhet som inte alls träffas av NIS2 skaffar en massa solceller på taket till fabriken och blir därmed elproducent - Omfattas! En större industri utan koppling till NIS2 säljer spillvärme till det lokala fjärrvämenätet - Omfattas! En stor bilverkstad som sätter upp laddstolpar för allmänhetens elbilar - Omfattas! De enda områden som jag känner till där det krävs en viss omfattning av verksamheten är dricksvattenproduktion, avloppsrening, avfallshantering och möjligen livsmedelsproduktion. I övrigt kan det vara en väldigt liten del av din totala verksamhet men ändå göra dig till en NIS2-verksamhet. Här vore jag väldigt tacksam om du som läsare kan hjälpa till att bringa klarhet! Hör av dig med inspel eller tankar till mats@ot-sakerhet.se ! Speciellt om du faktiskt jobbar i någon av alla de verksamheter som skulle träffas av den här tolkningen - hur har ni tänkt i er NIS2-analys? Säker fjärranslutning är enkelt! Ett område som ALLA verkar ha utmaningar med är fjärranslutning till OT-system. Det är en väldigt viktig funktion för att hålla igång produktionen, men också en av de mest utsatta delarna ur ett säkerhetsperspektiv! När jag träffar nya kunder brukar det alltid dyka upp alla möjliga spännande lösningar, med mer eller mindre genomtänkt säkerhet. Det här är ett kul område eftersom det är ganska vanligt att man kan skapa verklig nytta genom förbättrad säkerhet! Underhållspersonal, utvecklare, integratörer eller leverantörer kan skapa mycket mer värde om de snabbt kan få åtkomst, oavsett om det är från andra sidan jordklotet eller från kontoret i andra änden av industriområdet! Oavsett i vilken bransch man är brukar ungefär samma saker dyka upp när verksamheter sammanställer sina krav på säker fjärråtkomst till OT, det kan vara: Användbar för både egna anställda och för leverantörer. Ingen installation av programvaror hos den som ska koppla upp sig. (Speciellt viktigt för leverantörer som inte rimligen kan ha mängder med olika klienter och agenter på sina datorer.) Smidig att använda både externt över Internet och mer internt från IT-nätet. Smidig hantering av användare, gärna kopplad till någon separat identitetstjänst. Flerfaktorinloggning för säkrare identifiering och minska risken för delade inloggningar. Behörighetshantering och roller för att styra vem som får komma åt vad. Så här långt finns det ganska många produkter som möter kraven, det är egentligen ganska likt kraven för en typisk IT-miljö. Men när man börjar ställa lite "vassare" krav ur ett OT-perspektiv börjar det bli klurigare: Vid oväntade behov av fjärrstöd ska man väldigt snabbt kunna skapa åtkomst till en ny person utan att blanda in "IT-avdelningen". Inspelning av sessioner för att i efterhand kunna avgöra vad som hände. "Eskorterad inloggning", alltså att man släpper in någon på distans, men "tittar över axeln på dem" medan de är uppkopplade och kan avbryta arbetet om något är på väg att gå snett. Att kunna släppa in en besökare i ett system utan att man behöver dela inloggningsinformation till systemet. (Något slags lösenordsvalv och stöd för semi-automatisk inloggning.) Undvika att skapa en direkt tunnel mellan klientdatorn och systemet man kopplar sig mot. (Om man kan bryta den direkta nätverkskopplingen som man får via en vanlig VPN så är många risker eliminerade. En vanlig källa till problem är att leverantörernas datorer över tid är anslutna till väldigt många olika system, och därför tenderar att "samla på sig" diverse skadlig kod och annat tråkigt.) Stöd för hierarkiskt uppbyggda organisationer där olika bolag i samma koncern ska kunna samarbeta men samtidigt ha egen kontroll över sin egen miljö. Kunna skapa åtkomst till finmaskigt segmenterade och komplexa nätverk utan att man "kortsluter" segmenteringen. Stöd för end-to-end-kryptering och samtidigt något som liknar zero-trust på riktigt. Smidiga metoder för godkännande av inloggningar. Stöd att bygga en robust arkitektur helt utan "Single-points-of-failure". Kunna fungera även i miljöer som kräver fullständig isolering från Internet eller som vill ha egen kontroll över alla komponenter. Baserad på modern teknik, lättanvänd utan utbildning, snabb att implementer och inte resurskrävande för vare sig människor, nätverk eller system. Full loggning av händelser och spårbarhet för ändringar i systemet för fjärruppkoppling. Undvika jumphosts och liknande lösningar som ofta blir en svag punkt underhållsmässigt och dessutom en potentiell kortslutning i ett segmenterat nätverk. På plats i mitt kära hemmalabb finns numera en lösning som imponerat stort på mig och som jag personligen tycker bockar av alla krav som vanligen ställs på fjärråtkomst till OT! Jag tänkte ge dig en översikt här, men får nog anledning att återkomma kring några speciellt intressanta detaljer i framtida nyhetsbrev. Både produkten och företaget heter Cyolo. Lösningen bygger på två mjukvaru-komponenter, "Edge" och "IDAC" (ID Access Control), som man kombinerar ett valfritt antal av för att bygga upp en robust och snabb lösning. Det är i IDAC som allt intressant händer, medan Edge enbart har som funktion att knyta samman kommunikationen. En väldigt intressant styrka är att ingen känslig kommunikation någonsin dekrypteras i en Edge. All kommunikation sker krypterat hela vägen mellan klientsystemet och en IDAC, även om den passerar en eller flera Edge på vägen! Det betyder också att all känslig information bara lagras i system som är under organisationens egen kontroll, ingenting finns hos leverantören. Cyolo erbjuder som du ser på bilden nedan en molnbaserad, generell Edge-tjänst som fungerar ihop med alla installationer som vill använda den, eller så sätter du upp en eller flera egna Edge-tjänster som du exponerar på Internet. En finess med att "studsa via" molntjänsten är att dina egna Edge-tjänster inte behöver vara åtkomliga ute på Internet. Oberoende av hur du har segmenterat dina OT-nätverk finns det många olika sätt att flexibelt skapa styrd åtkomst dit det behövs. Edge-funktionen löser att kommunikationen kommer fram och IDAC ser till att du kan skapa anslutningar på rätt ställen. Och vill du inte ha Cyolo exponerad alls mot Internet så funkar det lika bra med 100% on-prem. Under huven finns ett modernt tänk där de valt att använda Docker-containers för att skapa stabil drift samtidigt som uppdateringar kan ske så gott som utan påverkan på driften. För att maxa tillgängligheten är det också väldigt enkelt att skapa klustrade lösningar över flera sajter. Det gör att störningar i samband med driftproblem eller uppdateringar hanteras automatiskt och snabbt. Det innebär också att det är superenkelt att börja litet för att sedan lägga till efter hand som man behöver mer åtkomst och stabilare drift. Installationen i testlabbet gick oerhört smidigt: Jag skapade en Ubuntu-server, körde ett installationsskript och kopierade in en licensnyckel. Sedan är det igång - inklusive full, och säker, administration från Internet om så önskas! Första gången du loggar in som administratör tvingas du sätta din flerfaktor-identifiering, exempelvis Google Authenticator eller något liknande. Vi kan börja med att titta på några sätt som det här kan fungera ur användarens perspektiv. Den första är nästan lite magisk; du sätter nämligen i princip vilken intern applikation som helst ute på Internet, men bakom flerfaktorinloggning, över krypterad länk och med möjlighet till en rad andra säkerhetsåtgärder! En leverantör som bara ska arbeta på distans i ett webb-baserat internt system får en extern länk direkt till det systemet! I mitt fall sköter jag exempelvis min Proxmox-administration genom att surfa till en länk i stil med https://proxmox.otsäkerhet.cyolo.io! Jag får en Cyoloinloggning med flerfaktorautentisering och sedan landar jag direkt i administrations-webbsidan hemma hos mig! Där får jag logga in som vanligt och kan arbeta precis som om jag satt hemma! På samma sätt som ovanstående exempel kan användaren komma in via protokoll såsom SSH, VNC, Telnet, RDP osv. Användaren jobbar direkt i webbläsaren men den sista delen av kommunikationen, den mellan IDAC och systemet, sker förstås med "rätt" protokoll. Alternativt sätter man upp exempelvis RDP-åtkomst i "bägge ändar" av förbindelsen, vilket förstås kräver tillgång till lämplig klientprogramvara men förbindelsen skapas och skyddas automatiskt av Cyolo. En variant på ovanstående är om jag släppa in någon som jag inte vill ska veta om inloggningen i själva systemet. Då kan jag lagra inloggningen (exempelvis för Proxmox i mitt fall) i lösenordsvalvet som finns inbyggt i IDAC:en och låta inloggningen ske automatiskt när personen ansluter med sitt eget lösenord. Perfekt funktion även internt, för system där många tvingas dela på samma lösenord - ingen behöver kunna det verkliga lösenordet och bara de som ska ha personlig åtkomst får det och med full spårbarhet... Ett vanligt case är att någon ska köra TIA Portal, PLCnext Engineer eller något annat specifikt verktyg på distans. En elegant lösning på det är att Cyolo efter inloggning fixar en lokal port på remote datorn, som magiskt transporteras till exakt den port som behövs för applikationens funktion. Bara en port och bara mellan dessa två system! Och detta utan att installera några agenter på systemet... Du kan erbjuda åtkomst till en Windows-fildelning (SMB) som man kommer åt i ett webb-gränssnitt istället för att oroa sig över att exponera sårbarheter i Windows. Om man absolut vill använda Cyolo som en "en gammaldags VPN" med full åtkomst till ett nätverk så går det också. Det är inte säkerhetsmässigt optimalt, men är ibland nödvändigt. Ur en säkerhetspersons synvinkel är möjligheterna att erbjuda applikationer ett fantastiskt sätt att skapa verksamhetsnytta. Ur ett rent säkerhetsperspektiv kompletterar man det med att styra åtkomst och sätta policies kring användningen. Några intressanta exempel på vad man kan styra åtkomst till en viss applikation baserat på: Användarens identitet eller de grupper man tillhör Om inloggning skett med flerfaktorinloggning Vissa tider och dagar Anslutning från nätverk i utvalda länder Anslutning från vissa IP-adresser eller nät Anslutning från vissa klientsystem som får identifiera sig med certifikat Egenskaper hos enheten man kopplar upp sig från, exempelvis viss version av operativsystemet, ett installerat virusskydd, lokal brandvägg, krypterad hårddisk eller domäntillhörighet Krav på "eskorterat besök" baserat på användarens identitet eller applikationen man ska använda. I korthet handlar det om att en person eller en grupp personer aktivt ska godkänna att uppkopplingen sker. Man kan sedan även övervaka vad som händer under uppkopplingen. Krav på att sessionen ska spelas in Integrationer med andra applikationer kan användas för att kontrollera lämpligheten i att koppla upp sig, genom ett API eller WebHooks. Exempelvis skulle en EDR-lösning (Endpoint Detection & Response) kunna bekräfta att ingen skadlig kod finns på systemet eller ett SCADA-system kan bekräfta att processen är i säkert läge. Dessutom kan man välja vilken funktionalitet som ska vara tillgänglig för användaren under en uppkoppling. Lite beroende på vilken typ av anslutning som är aktuell så kan det handla om att tillåta Cut&Paste, inspelning av sessionen, port forwarding, interaktivt samarbete med den som eskorterar, uppladdning av filer, nedladdning av filer och en massa annat. Hanteringen av identiteter är förstås väldigt central för alla sådana här lösningar. Plattformen kommer med egna IdP:er (Identity Providers) men beroende på dina krav så kanske du vill integrera med existerade identitetskällor (exempelvis Okta, Azure AD, JumpCloud, AD eller Duo) via något av de typiska protokollen som används för detta (SAML, OpenID, RADIUS eller LDAP). Det finns enkla beskrivningar för alla kombinationer av lösningar och stöd för exempelvis SCIM ("System for Cross-domain Identity Management") så att man automatiskt kan bygga upp användarlistan. Men det finns goda anledningar att använda Cyolos egen användardatabas också, exempelvis: Du vill ha en lösning som är fullständigt oberoende av yttre tjänster Du vill separera identitetshantering från flerfaktorsinloggning så de blir oberoende (exempelvis inte köra Azure AD tillsammans Microsofts MFA) Du vill spara på licenskostnader Du vill hantera användare från dina leverantörer separat från den interna hanteringen Det finns ett "lösenordsvalv" inbyggt i lösningen. Det möjliggör att den som ansluter till ett system inte behöver kunna lösenordet som används för att ansluta. Det är en fantastisk finess för att få spårbar och personlig anslutning till utrustning som bara har ett enda lösenord! Det är inte bara lösenord som kan lagras i valvet utan även andra typer av hemligheter, som privata kryptonycklar, certifikat och API-nycklar. Förutom ett systemvalv finns även ett personligt valv för varje användare som möjliggör att man kan spara lösenord som kan möjliggöra automatisk inloggning. Cyolo är väldigt väl anpassad för OT-användning men det passar minst lika bra för olika typer av IT-scenarier. Det finns stöd för SaaS-applikationer och en massa möjligheter att integrera med olika identitetstjänster och SSO-lösningar. När det blir lite mer komplext kan man koppla upp applikationsspecifika tunnlar mot flera olika system samtidigt. Allt som händer i systemet loggas noggrant, både användares aktiviteter och ändringar som administratörer gör. Loggningen, tillsammans med möjligheten till inspelning av sessioner, gör att man kan skapa extremt snygg spårbarhet. En viktig del för att analysera problem och incidenter! Man bör förstås också se till att anslutningar som kommer in på distans passerar förbi andra säkerhetssystem man redan har på plats. Det vore ju fånigt om IDS:er och annat inte fick "hjälpa till" att kontrollera även dessa anslutningar! Vilket förstås kräver klok placering av IDAC. Sammantaget är Cyolo en vansinnigt imponerande lösning. Den har mycket starka funktioner och kan enkelt skapa robust tillgänglighet, men ändå relativt enkel konfiguration och administration! Det blir verkligen en stor vinst säkerhetsmässigt att inte slentrianmässigt släppa in folk i känsliga nätverk via "vanlig VPN" utan istället använda en OT-anpassad lösning för att bryta upp de direkta nätverksförbindelser som annars blir möjliga. Om man inte vill göra sig beroende av externa tjänster går det utmärkt att skapa en helt lokal lösning som fortsätter att fungera även om tvingas isolera en anläggning under en incident. Stark rekommendation! Underhåll och ändringar... Apropå remote access och segmentering så hittade jag nedanstående siffror i en årsrapport från TxOne. Nu tar jag alltid sådana här siffror med en rejäl nya salt men oavsett källan och vad man menar med "OT-säkerhetsincident" så väcker det tankar... Det är onekligen något som jag känner igen mig i, det är inte (än så längre) hackers som är orsaken till de flesta säkerhetsincidenter i produktionsmiljöer. Det är istället våra egna arbeten i miljön, antingen direkt via underhållsarbete eller indirekt när IT-system råkar störa något i produktionen. Förutom vettiga arbetsrutiner och "ordning och reda" så blir förstås styrd åtkomst till system och separation från andra system en viktig del i att undvika problem. Språket spelar roll! Jag har i diverse sammanhang påpekat att man får se upp med vilket språk man läser standarder och lagkrav på. Man kan ju exempelvis tycka att det är fantastiskt att EUs alla viktiga dokument översätts till 24 olika språk, men det finns ju samtidigt en risk att det uppstår otydligheter när dessa översättningar skapas. Mina juristvänner berättar för mig att det är den engelska och franska versionen som väger tyngst om det blir tolkningsfrågor inom EU. Jag har hittat en del ställen där exempelvis NIS2-direktivet inte riktigt sänder samma signaler på olika språk. Häromdagen läste jag i en artikel att NIS2 kräver att man använder "state-of-the-art" i sina åtgärder vilket fick mig att börja jämföra olika språk. Här är den engelska versionen som mycket riktigt säger att man ska väga in moderna möjligheter när man utformar sitt skydd: Om man läser motsvarande text på svenska, så får i alla fall inte jag samma budskap. "State-of-the-art" och "de senaste" sänder inte riktigt samma signaler... Det finns fler klurigheter i översättningarna, en personlig favorit är kring gränsdragningen mellan Väsentlig och Viktig när det kommer till organisationens storlek. På engelska talar man om att Väsentliga ("Essential") måste överstiga taket ("Ceiling") för vad som är en medelstor organisation. Motsvarande text på svenska talar om "trösklar", vilket i alla fall jag tolkar som en nedre gräns för någonting, i motsats till "tak" som känns som en övre gräns: Man kan alltså lätt tro att ett "Medelstort företag" automatiskt blir Väsentligt om man läser den svenska texten, men den korrekta tolkningen är att det krävs nästa storleksordning. I det här fallet skulle konsekvenserna bli att man drar på sig radikalt högre krav om man av misstag ser sin organisation som "Väsentlig"! Nu är det ju inte meningen att alla ska sitta och läsa lagtext, men eftersom tiden är kort tills implementationen av alla NIS2-åtgärder ska vara klar så blir man ju så illa tvungen när ingen svensk vägledning finns klar. Min rekommendation är verkligen att inte läsa avgörande texter enbart på svenska, i synnerhet gäller det för oss amatörjurister! När du analyserar om er organisation omfattas av NIS2 och när du utformar era åtgärder är det viktigt att vara lite noggrann med dokumentation av vad era avgörande beslut baseras på. En annan sida av EU-reglering En intressant artikel av Mazaher Kianpour (från RISE och NTNU) och Shahid Raza (från RISE, MDU och Cybercampus) tittar på hur organisationer reagerar på cybersäkerhetslagar. Det är ju en klassisk insikt att förändrade spelregler inte automatiskt skapar det beteende man egentligen var ute efter... Hotet om sanktionsavgifter och annat kommer naturligtvis alltid vägas mot andra risker och resursbehov. Följetongen CRA... Du missade väl inte extrautgåvan av nyhetsbrevet som kom alldeles efter nyår och tittade närmare på den slutgiltiga texten för CRA-förordningen? Ännu så länge är den inte formellt spikad och det finns heller inget datum bestämt när det kan bli aktuellt. Prognosen säger just nu en vecka in i april men det kan mycket väl ändras. Nu börjar det gå upp för allt fler hur tuffa de närmaste åren kommer bli för många organisationer. Väldigt många är mitt uppe i NIS2-resan (plus DORA och CER för dem som berörs) samtidigt som nu CRA dyker upp på horisonten. CRA ska dessutom sannolikt vara fullt implementerad ungefär samtidigt som den nya Maskinförordningen har sin deadline. Även om det senare inte är förrän 2027 kommer det bli nödvändigt för många organisationer att ta ett samlat helhetsgrepp redan nu på alla dessa kravmassor för att inte behöva göra om jobbet flera gånger. Jag har försökt förstå vad opensource-världen tänker kring det slutgiltiga förslaget. De tidigare versionerna sågades ju brutalt därifrån men det har blivit nästan märkligt tyst efter det slutgiltiga förslaget. Några tankar har jag hittat, exempelvis från Eclipse Foundantion, OpenForum Europe, Python Software Foundation där tongångarna var mestadels positiva medan Debian var lite mer negativa. Jag hittade också en bra genomgång skriven av Bert Hubert. För NIS2 gick det att skaffa sig fördelar som leverantör om man var snabbt uppe ur startblocken och visade upp att man kan leverera enligt direktivets krav långt innan de börjar gälla. För NIS2 har det tåget snart lämnat stationen, men för CRA finns fortfarande bra möjligheter att styra upp utvecklingsprocesserna och villkoren för säkerhetssupport på sålda produkter. Säljer du produkter med digitalt innehåll är det viktigt att hugga tag i CRA snabbt! På OT-sidan som ofta har komponenter i drift under lång tid blir det speciellt viktigt att tänka igenom hur lång supportperiod man tänker garantera vid köp! Jag kan förresten rekommendera en episod av Dataföreningens "Prata CRA lagen med oss", där Olle E Johansson och Per-Erik Eriksson diskuterar den senaste versionen av förordningen: EUCC är klar! EUs cybersäkerhetsmyndighet ENISA har annonserat att "EU cybersecurity certification scheme on Common Criteria", (EUCC), är klar. Det är den första av en radda sådana och kommer bland annat följas av en kring molntjänster (EUCS) och en för 5G (EU5G). Det tittas också på möjligheterna på motsvarande upplägg för AI, elektroniska identitetstjänster och för MSSP:er (Leverantörer av managerade tjänster för säkerhet) Det här är ett spännande och komplext område som kommer få många beröringspunkter med exempelvis CRA-förordningen. Jag får säkert anledning att återkomma till detta! Jag satsade på rätt häst i labbet! Om du följt mina äventyr i hemmalabbet vet du att jag snöat in på Proxmox som virtualiseringsmotor. Ett annat vanligt val för virtualisering i hemmalabb är att köra gratisvarianten av VMware ESXi. Nu är jag ännu gladare att jag fastnade för Proxmox när VMware nu annonserat att gratisvarianten av ESXi försvinner. Det har hörts många "vad var det jag sa" från folk som såg detta komma sedan VMware köptes av Broadcom. Det återstår att se om/hur detta slår tillbaka mot VMware men tills dess är min personliga rekommendation att titta på Proxmox. Har du kollat tändstiften? Här är en intressant text som egentligen är en presentation som Christofer Dutz höll på "2023 IoTDB Summit" som inte nämner säkerhet en enda gång men som illustrerar en intressant förflyttning i branschen. Nämligen den som går bort från OPC UA och istället rör sig mot MQTT och Sparkplug B. Några av anledningarna till denna trend beskrivs i texten. Det är inte helt klart för mig hur siffrorna ser ut för OPC UA och MQTT men oavsett är det här något som vi OT-säkerhetsmänniskor måste vara uppmärksamma på! Läsvärt från MSB! MSB släppte nyligen dokumentet "Cyberangrepp mot samhällsviktiga informationssystem - 25 rekommendationer för stärkt skydd mot cyberangrepp". Det är inte skrivet specifikt för OT-säkerhet men innehåller många relevanta referenser och exempel som borde göra det till ett intressant dokument för de flesta säkerhetsintresserade. Ska vi höras? I förra nyhetsbrevet öppnade jag min kalender för alla som vill diskutera något kring OT-säkerhet. Gensvaret blev fantastiskt och jag har haft en radda riktigt roliga samtal, så jag kommer repetera den här texten framöver. En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen korta alternativ långa och "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite. Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt. Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra. Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats. Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Det glamorösa livet på AFRY? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en extrautgåva av nyhetsbrevet kring OT-säkerhet! Huvudnyhet den här gången är att CRA-förordningen verkar vara klar! Just därför är nyhetsbrevet lite kortare än vanligt, jag ville få ut en första analys lite snabbt. Men du får också en ny 62443-standard, mina tankar kring leverantörskedjor, nya vägledningar från SÄPO och ytterligare en rapport från hemmalabbet! 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å 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! Nu vet vi mer om CRA! Nu är texten för CRA, Cyber Resilience Act, tillgänglig i den version som man enades om i trevägsförhandlingarna mellan Parlamentet, Kommissionen och Rådet. Rent principiellt är den inte godkänd, den ska nu formellt klubbas av Parlamentet och av Rådet innan den kan börja gälla. Men det ska mycket till innan det blir några större ändringar nu! Samtidigt kom också ett utkast till en gemensam text om att EUs cybersäkerhetsorganisation ENISA behöver utökas med mer kompetens för att kunna ta hand om de nya kraven. Det här är en riktigt viktig lagstiftning! I korthet är det helt enkelt de säkerhetskrav som ställs på (nästan) alla typer av digitala produkter och dess tillverkare för att de ska få säljas eller göras tillgängliga inom EU. På samma sätt ställs motsvarande krav på importörer, distributörer eller någon som modifierar produkten. Formellt sett heter texten inte CRA utan "Horizontal cybersecurity requirements for products with digital elements" vilket ju faktiskt säger mer om både innehållet och syftet med kraven. Det är 186 sidor av juridisk text som inte alltid är helt enkel att ta till sig, särskilt inte för en amatörjurist som jag... Till att börja med konstaterar vi att det är en "Regulation" och inte ett "Directive" som exempelvis NIS2 är ett exempel på. "Regulation" blir på svenska "Förordning", vilket för övrigt är ett lite olyckligt ordval eftersom "Förordning" i svensk lagstiftning är någonting helt annat. En tydlig skillnad mellan CRA och NIS2 blir därför att CRA inte behöver "landa" i nationell lag, utan gäller direkt som lag i alla EUs länder. Som vanligt i de här texterna inleder man med en beskrivning av bakgrund och tänket i lagstiftningen, i det här fallet på 69 sidor. Det här är en viktig text även om den inte innehåller några krav, eftersom den definierar vad avsikten är - och det är viktigt i EU-rätt, vilket vi inte är så vara vid i Sverige där man lägger mer vikt på den exakta formuleringen i lagtexten. I den inledande beskrivningen kan man tydligt se resultatet av förhandlingarna kring texten, inte minst när det gäller open-source. Det är många tillägg och förändringar, men också faktiskt riktigt många strykningar. Vi får krav på fyra områden: Regler för hur man får göra digitala produkter tillgängliga på marknaden inom EU Krav på design, utveckling och produktion av digitala produkter och vilket ansvar inblandade organisationer har Krav på hantering av sårbarheter Regler för marknadsövervakning och hur alla krav genomdrivs Reglerna gäller för alla produkter med digitalt innehåll, mjukvara eller hårdvara, som görs tillgängliga på EUs marknad om det är rimligt att tro att den kan ha en logisk eller fysisk "dataförbindelse" med en enhet eller ett nätverk. Det slås direkt fast att CRA inte gäller om produkten lyder under EUs regler för medicinsk utrustning eller någon av regelverken för motorfordon, flygplan eller fartyg. De gäller inte heller för försvarsutrustning eller utrustning för nationell säkerhet. Kraven innebär att man får CE-märka produkten och därmed sälja den inom EU. (Observera att den inte bara får vara CE-märkt, utan den ska vara det!) Det är inte bara tillverkarens ansvar som definieras utan även importörer, distributörer och andra som på något vis representerar en del i att produkten görs tillgänglig för andra. Några av de viktigaste detaljerna som finns i förordningen tycker jag personligen är: Säkerhetsuppdateringar ska göras tillgängliga i hela produktens livslängd och ska vara gratis. De ska göras tillgängliga separat från funktionsuppdateringar. En säkerhetsuppdatering ska fortsätta hållas tillgänglig i minst 10 år. Sårbarheter ska annonseras publikt när de åtgärdats. Det här är en stor grej i OT-världen där väldigt många bolag fortfarande mörkar sina rättningar. Varm applåd från min sida! Supporttiden ska vara minst fem år om det inte är uppenbart att produkten kommer användas kortare tid än fem år. Supporttiden ska vara tydligt definierad redan vid köp och ska motsvara tiden som produkten kan förväntas användas kombinerat med rimliga förväntningar från kunderna. (I OT-världen vet vi att många produkter används väldigt länge, det blir intressant att se hur detta kommer tolkas för dem och hur det kommer påverka priset på produkterna?) Det är frivilligt att meddela myndigheterna (ENISA eller den nationella cybersäkerhetsmyndigheten) om sårbarheter som tillverkaren (eller någon annan) upptäcker. Om sårbarheter aktivt utnyttjas ska tillverkaren meddela myndigheterna (ENISA och den nationella cybersäkerhetsmyndigheten) inom 24 timmar. Även drabbade användare av produkten ska meddelas. På samma sätt ska tillverkaren meddela myndigheterna om allvarliga säkerhetsincidenter som tillverkaren själv drabbas av, om de kan påverka produkternas säkerhet! Produkter ska levereras "Secure by default" vilket bland annat kan betyda att de inte får ha kända sårbarheter eller samma lösenord. Tillverkare ska skapa en SBOM, Software Bill Of Materials men som lustigt nog inte behöver ta upp beroenden på mer än på en direkt nivå. Teknisk dokumentation ska vara tillgänglig i minst 10 år. I den tekniska dokumentationen ska tillverkarens riskanalys för produkten finnas med. Dokumentationen och riskanalysen ska uppdateras löpande under hela produktens livslängd. Vid användning av tredjepartskomponenter (både open-source och annat) ska tillverkaren ta ansvar för att det inte försämrar säkerheten. I produkter inkluderas även "remote data processing". Det vill säga att om delar av funktionaliteten i en produkt kommer från en molntjänst eller någon annan tjänst som finns i andra system så inkluderas även de i produkten och därmed motsvarande krav. Det finns tre kategorier av digitala produkter där "Important" och "Critical" definieras som viktigare än andra. Inom "Important" finns dessutom "Class I" och "Class II". Exempel på de olika kategorierna är: Important, Class I: System för identitetshantering och accesskontroll, Webbläsare, Lösenordshanterare, Skydd mot skadlig kod, VPN, SIEM-system, PKI-lösningar Important, Class II: Hypervisors och containersystem, Brandväggar, "Mikroprocessorer som ska vara skyddade mot fysisk manipulation" Critical: "Hardware devices with security boxes" Vad tusan är det? :-) Oavsett vilken kategori så gäller att tillverkaren ska via att produkten uppfyller ett antal grundläggande säkerhetskrav. Det kan göras på lite olika sätt men för "Important" är metoderna lite mer formaliserade och för "Critical" kommer det framöver komma separata krav på en formell certifiering för vissa typer av system. Det är viktigt att komma ihåg att kategoriseringen inte "smittar", ett system som innehåller komponenter som är "Important" eller "Critical" får alltså inte automatiskt samma kategori. Om man inte sköter sig blir det spö! Dels får man inte leverera sina produkter men till det kan man få upp till 15 miljoner Euro i sanktionsavgift, alternativt 2.5% av den globala omsättningen om det är högre. Att tillhandahålla felaktig eller inkomplett information kan "belönas" med 5 MEUR eller 1% i sanktion. Ganska hårda bud alltså... Ett av de områden som kritiserades hårdast när det första utkastet till CRA kom var hur det slog mot open-source världen. Det har man verkligen tagit till sig i den här versionen, några tydliga tecken är: Rollen "open-source software steward" definieras som en legal organisation som tillhandahåller support för digitala produkter som är avsedda för kommersiell verksamhet. En steward ska se till att det finns en cybersäkerhetspolicy som styr utvecklingen av produkten och hanteringen av sårbarheter. Stewarden ska verka för frivillig rapportering av sårbarheter bland utvecklarna. Stewarden ska rapportera aktivt utnyttjade sårbarheter och egna incidenter till myndigheter och användare på samma sätt som tillverkare ska. En steward kan inte drabbas av sanktionsavgifter. Notera att open-source inte är kopplat till priset på en produkt, Definitionen av en "Tillverkare" kräver inte att man tar betalt för produkten, man har ändå samma ansvar så länge produkten är en del av en kommersiell verksamhet. Det bör rimligen innebära att mjukvara som Internetbrowsers, sociala medier och liknande omfattas. Det finns en hel del referenser till NIS2 i CRA. Dels använder man ett antal gemensamma definitioner ("incident", "near miss") vilket förstås är bra. I kommande utökningar av vad som definieras som "Critical products" ska speciell hänsyn tas till om "Väsentliga entiteter" enligt NIS2 är beroende av dem. Det finns en del överlapp kring annonsering av sårbarheter och samarbete mellan nationernas cybersäkerhetsmyndigheter. Däremot har man tagit bort referenserna till NIS2 i definitionerna av "Kritiska produkter" som fanns i tidigare utkast. Denna slutgiltiga version av CRA är betydligt förenklad jämfört med det ursprungliga utkastet, men det är inte enkla krav som ställs, de kräver en hel del arbete och kompetens för att kunna möta. I förordningen finns texter om att Kommissionen ska ge ut vägledning för att underlätta införandet och med ett speciellt fokus på mindre verksamheter. Det står också att respektive land ska tillhandahålla utbildning och stöd till mindre organisationer. Kring OT-säkerhet finns nästan ingenting skrivet. I tidigare utkast fanns OT definierat som begrepp och en rad OT-prylar uppräknade som exempel på "Kritiska produkter" men det har tagits bort. När det gäller kraven på att inga kända sårbarheter får finnas i produkten kan man fundera på hur helt oskyddade OT-protokoll kommer ses? Att Modbus helt saknar autentisering måste ju ändå ses som en sårbarhet men det lär ju inte vara aktuellt att förbjuda Modbus-servrar? Det finns faktiskt öppningar för att kontraktsmässigt kunna ta bort kraven på "Secure by default" och gratis säkerhetsuppdateringar, men de är begränsade till skräddarsydda system och lär inte kunna användas i andra sammanhang. För de flesta organisationer kommer det krävas mycket arbete för att få allt på plats. När förordningen börjar gälla så har man 36 månader på sig förutom i följande fall: Kraven på rapportering av utnyttjade sårbarheter och egna säkerhetsincidenter börjar gälla redan efter 21 månader. Länderna ska inom 18 månader ha fått igång myndigheter som sätter upp "myndighetssidan" av kraven. Det finns en målsättning om att det inom 24 månader ska finnas tillräckligt med "Notified bodies", alltså organisationer som bedömer att certifieringskraven uppfylls. Eventuella andra cybersäkerhetscertifieringar som gjorts tidigare ska kunna vara giltiga i upp till 42 månader. Produkter som satts på marknaden före införandet undantas tills de "modifieras betydligt" men kraven på rapportering av utnyttjade sårbarheter och egna säkerhetsincidenter börjar gälla oavsett efter 21 månader. Personligen tycker jag man verkar ha fått ihop en riktigt bra kompromiss! Det finns mycket kvar som fortfarande är lite oklart, i synnerhet de delar som ska "fyllas på efterhand". Det kommer förstås få en påverkan på priset för vissa produkter, men säkerhet måste få kosta så det är bra att "det blir lika för alla". Extra spännande blir det förstås för de företag som även omfattas av andra krav, kanske framför allt NIS2 och Maskin-förordningen. Det är definitivt inte läge att försöka implementera dem var för sig! Mest uppenbart blir det väl kanske för tillverkare av datorer, elektronik och många typer av maskiner, men kanske i vissa fall även andra? Hur blir det med apparna som firmor tillhandahåller som del av sina tjänster, som exempelvis budfirmor, flygbolag, fjärrvärmeleverantörer, banker, livsmedelskedjor och sjukvårdsappar? Hur blir det med routern som Internetleverantören ställer ut? De moderna mätarna för el och vatten? Min personliga tolkning är att de alla ingår i scopet för CRA samtidigt som organisationen faller under NIS2... Vad händer i andra änden av kedjan? Jag har på sistone varit insyltad i en del diskussioner kring de delar av NIS2 som handlar om säkerheten i leverantörskedjor. Det här är ju en väldigt central del i direktivet och det är tydligt att EU tagit intryck av att så många av de stora incidenter som varit de senare åren har varit orsakade av brister i säkerheten hos leverantörer. Det här är verkligen något som det trycks speciellt på i direktivstexten: Det här betyder i praktiken att alla organisationer som själva omfattas av NIS2 i princip i sin tur behöver ställa motsvarande krav som NIS2 ställer på sina egna leverantörer. Det intressanta är att det här inte är krav som är speciellt enkla att hålla koll på. Hur håller man koll på sina leverantörers "säkerhetspraxis"? Eller på deras metoder för säker utveckling? Eller på "...de sårbarheter som är specifika för varje direktleverantör..."? Ska man göra det här ordentligt kommer det krävas en hel del jobb av både leverantörer och kunder! Vad händer då när man börjar "dra" i ena änden av leverantörskedjan? Någonting behöver ju hända i den andra änden? Jag har en känsla av att detta i förlängningen kan leda till att många organisationer kommer dra ner på antalet leverantörer som de använder, av det enkla skälet att det blir en tung hantering att löpande hålla koll på deras säkerhetsrutiner. Med tanke på hur hårt man trycker på det i direktivet så kan vi nog räkna med att tillsynsmyndigheterna kommer ha mycket fokus på detta! Både NIS2 och CRA innehåller regler som leder till försäljningsförbud om man inte klarar reglerna. Som vi sett på helt andra områden (exempelvis laddare för elbilar och högteknologiska cykelhjämar) kan det bli tufft (eller till och med dödsstöten) för en leverantör som får säljstopp! Å andra sidan är det här förstås en fantastisk möjlighet för de leverantörer som är duktiga på säkerhet att skaffa sig stora konkurrensfördelar. Och förstås även för de som nu satsar på att bli duktiga på NIS2-krav innan kunderna hinner börja ställa dem. Tidigare har ju inte god säkerhet varit ett jättestarkt argument vid inköp och upphandlingar. Det kan nog komma att ändras nu, åtminstone för de delar av säkerhetsarbetet som är enkla att kravställa och mäta. Hur ska man bäst hantera detta som leverantör då? Den enklaste lösningen i mina ögon är för leverantörer att se till att de uppfyller kraven i NIS2 även om de inte formellt själva faller under direktivet. Skaffar man sig sedan en lämplig certifiering på detta så kan man slippa ha upprepade diskussioner med varje enskild kund! Glöm inte Maskindirektivet! När vi ändå är inne på NIS2 och CRA vill jag påminna om den nya Maskinförordningen som också tar upp cybersäkerhet. Om du tillverkar maskiner med digitalt innehåll kommer du sannolikt beröras av både CRA och Maskindirektivet. Beroende på vad det är för maskiner så kan även NIS2 vara aktuellt. Försök för allt i världen inte implementera de här tre kravmassorna var för sig! Det blir otroligt mycket onödigt jobb och resultatet blir förmodligen inte så bra. Sammanställ era egna krav, se till att de räcker till och implementera dem sedan i ett svep! Nix! Det har inte blivit fritt fram i 62443... Det pågår ett antal olika aktiviteter för att uppdatera de olika delarna i 62443-standarden. Det är verkligen något som behövs, tiden har sprungit ifrån standarden och de olika delarna säger ibland emot varandra på lite ologiska sätt. Arbetet blir lite extra komplicerat av det enkla faktum att vissa delar drivs av ISA och andra av IEC. Nu senast fick vi en ny version av 62443-2-4 från IEC. Den förra versionen var från 2015 med en mindre uppdatering 2017, så det var dags för en ny version! Del 2-4 handlar om krav på de säkerhetsprocesser som tjänsteleverantörer ska följa när de erbjuder systemägare integration och/eller underhåll av automationslösningar. Den kan användas direkt av leverantören eller för bra kravställning från kundorganisationen. Det påverkar inte hur andra viktiga delar i standarden, exempelvis 3-3 och 4-2 ska användas. 2-4 är en av de få delarna i standarden som faktiskt bygger ett par resonemang på Purdue-modellen. Jag har sett en del ståhej kring detta i sociala medier, med rubriker som insinuerar att något helt nytt är på gång och att de gamla principerna som förbjöd direkt kommunikation mellan olika nivåer nu är borta. Det är min åsikt att detta är överdrivet av flera skäl, men framför allt har Purduemodellen aldrig legat till grund för hur 62443 styr nätverkssegmentering. Det är "Zones" och "Conduits" som gäller och där är det ingenting nytt. Den gamla versionen av 2-4 nämnde Purdue i två sammanhang: Att dokumentationen över hur trådlösa nätverksfunktioner används mellan olika Purdue-nivåer är aktuell. Att ingenjörsstationer för safety-system inte kan påverkas från nivå 3 eller högre upp. I den nya versionen har man helt strukit referenserna till Purdue kring trådlöst och nämner istället "Zones" and "Conduits". När det gäller Safety-system finns referensen märkligt nog kvar men det spelar mindre roll, att skydda safety-system tenderar att få stort fokus oavsett! Jag får ibland frågan om varför jag tycker så illa om Purdue-modellen och jag inser att det kan verka så. I praktiken har jag inget emot den alls, så länge den inte används för att "fuska"... Purduemodellen är jättebra att använda i diskussioner kring hur olika typer av system kommunicerar, och det är inte så konstigt med tanke på att det var det som var ursprungstanken med modellen! Modellen är också användbar som inspiration när man gör sin segmentering av nätverk och system. IEC 62443-3-2 nämner precis detta - att den kan användas som grund för segmenteringstänket. Tyvärr är det många som stannar där och inte gör det viktiga jobbet. De bygger nät utefter nivåerna i modellen och tycker sig ha gjort det som behövs enligt standarden. I vissa, enklare fall kan det förstås vara så att detta räcker. Men för att kunna veta om det räcker så behöver man fortfarande göra något slags riskanalys och bygga sina "Zones" och "Conduits" efter den. Visar det sig att "Zones" blir samma sak som Purduenivåer så var det ju bra! Men! Vi ska naturligtvis inte bara luta oss mot vad vår kära standard säger! Vissa saker är (nästan) alltid väldigt bra att göra! Det är alltid en bra idé att ha DMZ-nät mellan "IT" och "OT"! (Även om inte standarden tvingar oss!) Det är dessutom nästan alltid bra att ha flera DMZ-nät så att vi inte blandar utsatta system med varandra! (Även om inte standarden tvingar oss!) Det är alltid bra att inte tillåta obruten kommunikation direkt mellan "IT" och "OT", utan att "mellanlanda" den i något slags proxy-system. (Även om inte standarden tvingar oss!) Jag ser den nya versionen av 2-4 som ett välkommet steg i moderniseringen av standarden. Vi får hoppas att arbetet med övriga delar rör sig någorlunda snabbt framåt! Vi behöver en lokal! I förra nyhetsbrevet erbjöd jag mig att skapa något slags diskussionsforum kring OT-säkerhet. Av återkopplingen att döma så var det en populär tanke, det var många som ville kunna diskutera OT-säkerhet med andra! Baserat på intresset tänker jag mig att vi börjar med något slags digitalt forum. Om det sedan finns intresse där för någon form av träffar eller digitala event så tar vi det i steg två. Ett digitalt forumet behöver vara enkelt att komma åt på många olika typer av enheter och enkelt att använda. Det är inte tänkt att hantera några direkta hemligheter men det behöver vara tillräckligt säkert för att hålla borta de flesta spammare och bottar. Det behöver klara att ha någon form av enkel ämnesstruktur så att det inte bara blir en enda röra av meddelanden. Det ska kännas okej för dem som tar privacy på extra stort allvar och som kanske undviker sociala medier. Spontant ser jag några rimliga alternativ: Ett klassiskt Internetforum som en "bakficka" till nyhetsbrevet. Dvs man loggar in på något i stil med ot-säkerhet.se/otdiskussion. (Men... Extra underhållsjobb för mig och kanske inte lockar till mycket interaktion om man måste använda en webbläsare?) En privat server på Discord. (Funkar på alla plattformar men lite klurig att använda om man inte är van vid Discord. Discord har väl hyfsat rykte men det är trots allt ett slags socialt medium.) Vi använder Slack eller någon liknande freemiumtjänst. (Kan vara lite skakigt kring privacy och klurigt för folk som inte använder produkten annars.) Self-hosta någon lämplig FOSS-programvara hemma i garaget. (Förmodligen mycket mer jobb än jag hade tänkt mig...) Invadera något existerande forum som har ett annat syfte. (Enkelt men kan vara impopulärt?) Vad tycker du? Ser du något annat alternativ? Skicka tyckanden och förslag till mig på mats@ot-sakerhet.se eller kommentera det här nyhetsbrevet på LinkedIn. Ska vi höras? En av de saker jag uppskattar allra mest med mitt jobb är att jag får kontakt med så många intressanta organisationer. Mina uppdrag är typiskt antingen ganska korta eller "lågintensiva", vilket öppnar för fler kontakter. Det kan vara som tillfälligt expertstöd i ett projekt, som rådgivare till en IT-chef eller som coach till en säkerhetschef under lång tid, som granskare av kravunderlag eller kanske som "djävulens advokat" när det behövs någon som utmanar lite. Det är verkligen en förmån att få lite insyn i så vitt skilda verksamheter och att få träffa människor med intressanta utmaningar! Det är märkligt att det kan vara så många likheter mellan OT-säkerhetsutmaningarna i robotceller hos en tillverkande industri, fastighetsautomationen i en extremt känslig byggnad, dricksvattenproduktionen i en liten kommun, en gruvas komplexa värld, de medicintekniska system på det lilla sjukhuset, maskinrummet på riktigt stora fartyg eller någon av alla andra spännande verksamheter som jag kommer kontakt med. I princip 100% av gångerna kan jag dela med mig av något jag lärt mig från en tidigare erfarenhet till nästa kontakt. Normalt sett sker dessa kontakter som en del av ett uppdrag vilket förstås begränsar vilka människor jag kommer i kontakt med. Jag tänkte att det skulle vara kul att komma i kontakt med fler verksamheter, spännande eller vardagliga, även utan ett aktivt uppdrag, för att se vad vi kan lära av varandra. Som ett experiment provar jag att öppna kalendern för alla som vill höras för att bolla någon intressant fråga. Vad som helst som har med OT-säkerhet att göra! Du får naturligtvis själv avgöra vad du kan dela med dig av eftersom det formellt sett inte finns några sekretessavtal på plats. Plocka åt dig en timme här! Vad vill du prata om? Segmentering? NIS2? Samarbete IT & OT? Cool teknik? Ladder Logic kontra Structured Text? Active Directory? Hemmalabbet? Incidentövningar? Du väljer! SÄPO är klara! Nu har Säkerhetspolisen släppt uppdaterade versioner av samtliga vägledningar kring säkerhetsskydd. så att de ska matcha uppdateringarna i lagen som kom för två(!) år sedan. Det finns fortfarande inte mycket hjälp att vänta för den som hanterar OT-säkerhet i säkerhetskänslig verksamhet. Fokus är fortfarande på skydd av information och OT får finna sig i att bli hanterad under "...skadlig inverkan i övrigt på...informationssystem". Att kombinera de två väldigt olika områdena säkerhetsskydd och OT-säkerhet kräver verkligen att man håller tungan rätt i mun för att inte tappa fokus på vad som är viktigt. Just därför är det förstås extra roliga projekt för en säkerhetsnörd som jag själv. Säkerhetsnörd? Ja, apropå säkerhetsnördar så kan jag rekommendera den nyutgivna boken "Förutsättningar för krisberedskap och totalförsvar i Sverige" från Försvarshögskolan. Den finns att köpa som bok eller ladda ner gratis. Inte så mycket fokus på OT-säkerhet, eller ens cybersäkerhet. Men en intressant historik över totalförsvaret i Sverige sedan 1901 och diskussioner kring en lång rad händelser och insatser i mer modern tid. Du får också en genomgång av alla myndigheter som är inblandade i krisberedskap och totalförsvar. Hackers utan verktyg? I en artikel sammanställer Danielle Jablanski ett gäng goda idéer kring hur man skyddar sina system mot "Living of the land techniques", "LotL". Det här är ett begrepp som blivit allt mer i ropet i IT-världen och som nu också börjar hitta in i OT-världen. Det handlar helt enkelt om angrepp som sker utan hjälp av specialskrivna "hackerverktyg" utan istället att man använder de verktyg som redan finns på de system där man bryter sig in. Det här är ju något som egentligen passar "väldigt bra" i OT-världen med tanke på hur begränsat inre skydd de flesta system och komponenter har. Rapport från lekstugan Jag fick väldigt mycket roliga frågor om mitt lilla hemmalabb när jag pratade min nya virtualisering i förra nyhetsbrevet. Om det är fler som är nyfikna kring hur jag tänkt när jag satte upp Proxmox så kommer lite tankar och erfarenheter här... I övrigt finns lite mer information kring labbet i allmänhet i nyhetsbrev #55. Helt kort för den som inte känner till Proxmox så pratar jag om en opensource-programvara som heter "Proxmox VE", Proxmox Virtual Environment. Det är en Debian-baserad Linux-plattform som skapar en helhetslösning för virtualisering med applikationer skrivna i Perl och Rust. Man erbjuder fullständig virtualisering via KVM och samtidigt möjlighet att köra containers via LXC. Det finns stöd för klustring, fail-over, live-migrering och en massa andra fina funktioner. På nätverkssidan är det också rejält utrustat med fullt stöd för virtuella eller "Software defined" nätverk, VLAN och alla andra nätfunktioner som kan vara intressanta. Allting är baserat på existerande Linuxfunktioner som knyts ihop på ett elegant sätt. Vill man köra detta i produktion så finns fullt kommersiellt stöd från den tyska firman "Proxmox Server Solutions GmbH" som ligger bakom alltihop. Direkt ska jag säga att det finns en baksida med att det verkligen går att göra precis vilka lösningar som helst, och det är att det definitivt finns gränser för vad som går att göra i administratörsgränssnittet. Resten är kommandon och konfigurationsfiler precis som det alltid är i Linux. Det kan vara en rejäl tröskel om man är ovan, men å andra sidan finns det en gigantisk mängd hjälp att hitta via valfri sökmotor på Internet! För mig som är gammal Unix/Linux-nörd sedan i början av 90-talet, så är det underbart att återvända till den här världen! Det är som att cykla, handgreppen sitter kvar i händerna... Mitt tänk är att hemmalabbet ska vara en ultra-flexibel lekstuga där det snabbt går att testa nästan vad som helst. Jag har valt att inte bygga någon simulerad industri med alla de vanliga lösningarna som är vanliga då. Istället ska jag snabbt och enkelt kunna slänga upp små och stora nät med lämpligt innehåll, allt efter behov. Det betyder också att jag unnar mig att använda lösningar som kanske inte alltid passar i "riktiga" miljöer, exempelvis att "IT" och "OT" rör sig i separata VLAN i samma switchar. Eller att virtualisering sker i delad hårdvara. Eller att simulerade safety-system, som skulle varit väldigt skyddade i "riktiga" system, är åtkomliga från andra nät. Om det blir aktuellt att pentesta en kopia av ett riktigt system så får man förstås hantera det lite annorlunda. Min huvudsakliga proxmox-host är en mini-PC. Den är inte alls avsedd för industriellt bruk, men den är liten och tillräckligt kraftfull: 32 GB RAM, i5-8500T-processor med 6 cores, ett antal TB disk fördelat på SSD/M.2NVMe/USB3.0 och två nätverksanslutningar. En av nätverksanslutningarna har ett trunkat nät med 8 VLAN som möter en liten switch med motsvarande uppsättning, vilket gör att jag har 8 "OT-nät" som finns både i den virtuella miljön och i (taggade eller otaggade) nätverksportar i switchen. Smidigt! Det finns förresten också två andra proxmox-hostar i samma "Datacenter". En som snurrar på en enklare laptop med en 4-cores i5-4300U CPU och bara 8 GB RAM. Laptopen är främst där för att kunna testa servermigration i Proxmox och för att ta backuper. Den andra är servern för hemautomation och annat kul (en HPE MicroServer Gen 10 med en 4-cores AMD Opteron X3421 och 32 GB minne) där bland annat Home Assistant snurrar. Övrig infrastruktur byggs med de prylar som råkar sitta i labbracket för tillfället. Åtkomst till Internet ordnas via ett eget VLAN i hemmets Ubuiquiti Unifi nätverk (en DreamMachine Pro, två 8-portars PoE-switchar, ett par AC Long Range som fixar husets WiFi assisterade av två AC Mesh). Okej då, lite prylnörd är jag väl då... Om jag ska försöka dela med mig av lite insikter och erfarenheter kring just Proxmox så är det väl: Du behöver förstås vara lite hemma på att hantera datorer men det är relativt enkelt att komma igång. Det finns otroliga mängder hjälp på Internet, det är i princip omöjligt att få ett problem som ingen annan redan haft! Det mesta som behövs för "normalt bruk" går väldigt enkelt att få till i det grafiska webb-gränssnittet. Ska du gå utanför det grundläggande får du räkna med att bli bekväm med att administrera system i Linux, dvs kommandon, skript och konfigurationsfiler. I och med att man har direkt tillgång till alla konsoler och shell i proxmox administrationsgränssnitt blir man väldigt snabb och effektiv när man har fått lite koll på läget. Proxmox är gjort för extrem tillförlitlighet som passar i "skarp användning". Om man inte tycker det är en katastrof om man tappar några sekunders data vid ett strömavbrott så går det att optimera på ett annat sätt för att få upp prestandan rejält, exempelvis om man använder zfs för lagring. Precis som för alla andra virtualiseringslösningar så tjänar man på att ha mycket RAM och snabba diskar. Om du har möjlighet så maxa RAM och skaffa NVMe-diskar. Proxmox har stöd för containers. Men det är inte Docker-containers som många tror utan "rena" linuxcontainers via LXC. Men det är enkelt att lägga till en virtuell maskin där man kör sina Dockers men det kan vara förvirrande i början. I närtid finns det ett gäng roliga områden som jag behöver utforska mer förutom alla roliga OT-prylar som jag får i händerna, exempelvis: Automatiserad uppsättning av testmiljöer med Ansible och någon variant av Terraform. (För att bli ännu snabbare i att komma igång när något ska testas.) Den spännande världen kring "Software Defined Networking" i OT-världen. Här kommer sannolikt en controller från Veracity kombineras med "Open vSwitch" som är innbyggt i Proxmox. Min hemautomation, som är baserad på Home Assistant, ska få flytta över till Proxmox tillfälligt medan dess egentliga server ska ominstalleras från scratch. (Med Proxmox förstås!) Tillgång till speglad nätverkstrafik är enkelt i traditionella switchar, men kan vara ett klurigt område i virtualiserade miljöer. Tyvärr verkar det sant även i Proxmox, men det behöver lösas för att få till bra tester av OT-IDS:er framöver. När det gäller roliga OT-prylar så hoppas jag snart kunna skriva om en lösning för riktig fjärråtkomst för OT-miljöer, dvs någonting som är mycket mer flexibelt än klassisk VPN eller lösningar baserade på centrala serverfunktioner och som löser de problem som en typisk underhållsavdelning står inför. Och varför inte lite riktigt fina nätverksprylar? Det är alltid kul och är också på gång... Finns det något annat som du vill att jag utforskar och skriver om? Hör av dig till mats@ot-sakerhet.se ! Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Några höjdpunkter den här gången är vi letar läckor i nätverket, lär oss teatersport, stjäl inloggningar i ABB-system, konstaterar att EU är överens om CRA, överraskas av en smart mojäng, fyller på i hemmalabbet och så läser vi två böcker, ett examensarbete, en doktorsavhandling och ett jättegammalt dokument! 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å 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! Vad har teatersport med säkerhet att göra? Jag hörde nyligen en intervju om improvisationsteater och teatersport. En av tipsen för att bli en duktig teatersportare var att alltid säga "Ja!" oavsett vad dina motspelare hittar på. Jag kunde inte låta bli att tänka att samma sak gäller inom säkerhetsarbete! Jag menar inte att man som "säkerhetsperson" ska vara okej med vad som helst, men att inleda med "Ja" är ändå en möjlighet att skicka en signal att man faktiskt har samma mål som den man pratar med. Att man inte ser sig själv som en stoppskylt, en polis eller som "Mordac" från Dilbert. Säger man "Ja" och kvalificerar det med frågor om vad som ska uppnås eller kanske "Ja, men då behöver vi först..." så skickar man lite respekt för vad kollegan vill uppnå, som förmodligen faktiskt är något viktigt och klokt. Inom improvisationsteater tappar man tempo och flyt i handlingen om man säger "Nej". Inom säkerhet tappar verksamheten tempo och dessutom skapar man beteenden där man försöker kringgå säkerhetsrutinerna. När jag är ute och konsultar träffar jag emellanåt på säkerhetsfolk som verkar ha missförstått sin roll totalt och som tror att man framstår som kunnig genom att vara så motvalls om möjligt. Att bara säga "Nej" är enkelt, det behöver man ingen speciell kompetens för. Att förklara varför ett förslag är dåligt kräver inte så mycket mer. Men, om man är skicklig så klarar man att hitta vägar framåt tillsammans med organisationen så de når sina mål på ett sätt som inte stökar till säkerheten. Tillhör man den riktiga säkerhets-eliten så klarar man att skapa helt nya möjligheter för verksamheten genom att möjliggöra saker som tidigare var omöjliga. Då blir det lätt att få resurser för säkerhetsarbetet! Nu kommer CRA! Snart... Den sista november annonserade EU att man nått politisk enighet kring CRA, Cyber Resilience Act. (Jag har skrivit om CRA tidigare, exempelvis: Nyhetsbrev #48 och #51.) Det här är ett rejält omdiskuterat förslag, inte minst för dess hårdhänta påverkan på opensource-världen, men också på grund av kraven på att rapportera sårbarheter till EUs cybersäkerhetsmyndighet. I grunden handlar det om att produkter med digitala funktioner ska vara CE-märkta för att få säljas inom EU. CE-märkningen känner vi igen från andra områden men nu lägger man alltså även till krav på cybersäkerhet. Det ursprungliga förslaget presenterades i september 2022 och nu har man kommit överens om en rad kompromisser som ska göra det möjligt att klubba igenom kraven. De kompromisser som lyfts fram är enligt uppgift: Tillverkare måste tillhandahålla säkerhetsuppdateringar i minst fem år om man inte kan visa att livstiden för produkten är avsevärt kortare. Sårbarhetsrapporter och incidenter skall skickas till nationella myndigheter men ENISA har en stark roll. Kravmassan för hur certifiering av produkter går till har förenklats jämfört med det ursprungliga förslaget och antalet "kritiska produkter" har minskats. Hur man har skruvat på reglerna som påverkar opensource-projekt är inte helt tydligt ännu men förändringar har tydligen gjorts. Små företag ska få stöd i hur man praktiskt kan hantera kraven. När besluten är tagna kommer tillverkare, importörer och distributörer av hård- och mjukvara ha 36 månader på sig att ta till sig kraven. När det gäller kraven för tillverkare att rapportera sårbarheter och incidenter börjar de gälla redan efter 21 månader. Något datum finns inte ännu men man säger "...early 2024", så det är inte långt borta! I motsats till NIS2 är detta inte ett direktiv utan en förordning, vilket innebär att det gäller som lag direkt i alla EUs länder utan att man behöver stifta nationella lagar. När detta skrivs har jag fortfarande inte fått fingrarna på den uppdaterade texten så jag får återkomma med mina egna tankar om innehållet. Enligt "vanligtvis välunderrättade källor" så har alla OT-relaterade produkter strukits ur listan över viktiga och kritiska produkter. Däremot ska kopplingen mot NIS2 finnas kvar så att prylar som är viktiga för säkerheten i en "Väsentlig entitet" enligt NIS2 blir en "Kritisk produkt" i CRA vilket ställer höga krav på certifiering av produkten. Eric Byres på Adolus skrev en intressant kommentar kring kraven på SBOM och vilka dolda utmaningar som finns bland kraven i CRA. Värt att läsa! Personligen är jag generellt väldigt positiv till CRA, om inte annat för att vi till slut kanske slipper alla dessa mörkande tillverkare som inte låtsas om att deras produkter har haft sårbarheter. Förhoppningsvis har man nu lyckats minska påverkan på opensource-världen som jag uppskattar mycket! Hitta läckan i ditt nätverk? Oavsett om du har ett OT-nätverk som ska vara helt isolerat eller om det har kommunikation med omvärlden är det en utmaning att kontrollera att det inte finns några okända "läckor". Det är inte det minsta ovanligt att man hittar 4G-modem gömda i apparatskåp, att tillfälliga brandväggsregler råkar bli permanenta eller att utrustning har flera nätverksinterfaces som oväntat gör dem till en router. Vissa typer av kommunikation kräver dessutom mer än bara brandväggar för att kunna styras upp. Ett klassiskt knep för att kommunicera med omvärlden i smyg är att tunnla genom DNS-uppslag. (DNS, Domain Name System - det sätt som nästan alla nätverksanslutna prylar tar reda på adressen till andra prylar) Man tvingas ofta att tillåta DNS genom brandväggar men då måste din DNS-uppsättning begränsa hur namnuppslag skickas vidare ut på Internet... För att göra det ännu mer utmanande vill man ju upptäcka framtida förändringar i nätet som gör att det börjar "läcka". Även om skyddet är perfekt så förändras saker över tid och plötsligt så får någon ändring en oväntad sidoeffekt... Allt det här bygger förstås på att man faktiskt styrt upp både vad som får komma in i nätverket men också vad som får gå ut från det. Tidigare vad det vanligt, både mot Internet och mot industrinät, att man bara stoppade oönskad trafik som försöker ta sig in. Det är inte lika vanligt längre, mycket "tack vare" ransomware, men jag stöter fortfarande på det. Jag har genom åren provat produkter som löser det här problemet men ingen av dem har varit anpassade för OT-nätverk. Men det finns ett undantag, det finska företaget SensorFu har med produkten "Beacon" löst precis det här problemet. Och de har gjort det med just OT-nätverk i fokus! Det är egentligen en väldigt enkel lösning. Du placerar ut en eller flera Beacons i ditt nätverk och en hemmabas kallad "Home". Dessa Beacons försöker hela tiden kommunicera med sitt Home som du placerat på Internet eller på något annat nät som inte borde gå att nå. Beacons använder diverse olika trix att nå till Home och lyckas de så får du ett larm med information om hur de "tog sig ut". Det är just de här försöken som gör SensorFus lösning unik, det är här anpassningen till OT syns tydligt. Det är förstås viktigt att de här försöken inte stör nätverket eller automationsutrustning! En Beacon gör sina tester i ett väldigt lågt tempo och använder inte tester är "stökiga" på nätet. En Beacon finns i olika former. Du kan köra det som en applikation i Windows eller Linux, skapa en container eller en virtuell maskin. Vill du köra Raspberry PIs så finns officiellt stöd för det också. Hemmabasen Home kan du antingen köpa i molnform eller köra själv i en Linuxmaskin. Själv provade jag både att automatiskt skapa en virtuell maskin, en Linux-applikation och en LXC-container i hemmalabbet. Testerna inkluderar direktanslutning via TCP och UDP, broadcast via Ethernet, DNS-uppslag, Ping, Spoofade avsändaradresser och oväntade IP-protokoll som IGP, IGMP eller TLSP. Dessutom använder den både IPv4 och IPv6. Har du koll på hur ditt OT-nät hanterar IPv6? (De flesta har inte det...) I exemplet nedan var nätet helt blockerat av en brandvägg förutom för DNS över UDP vilket förstås räcker för en läcka. Det finns många situationer där läcksökning är viktigt. Naturligtvis är det inte bara inom OT som det här är viktigt, känsliga IT-nätverk inklusive privata cloud-nät är precis lika klurigt att hålla koll på. Några vanliga exempel kring OT är: OT-nät som enbart ska kunna kommunicera med prylar på ett DMZ Jumphosts som bara ska vara åtkomliga via en säker lösning för fjärråtkomst Nät för fysiskt skydd, kameranät eller passagesystem Datorer som aldrig någonsin ska nätanslutas, exempelvis programmeringsverktyg för safety-system eller kanske en root-server för PKI Managementnätverk där systemadministratörer utför de allra mest känsliga arbetsuppgifterna Det här är en produkt som jag verkligen rekommenderar alla att prova. Även om du ska ha öppningar i nätverket är det förstås viktigt att det inte finns andra "läckor" som du inte har koll på. Det man vet om kan man hålla koll på... Produkten är superenkel att använda och resultaten kommer direkt! Hör gärna av dig så hjälper jag till att ordna en test. Vissa saker måste man göra själv! En artikel från Otorio tittar på sätt att stjäla administratörsrättigheter från ABBs 800xA-system. Jag ska påpeka att artikeln inte kritiserar säkerheten i systemet, snarare tvärtom - men det är en påminnelse om att vissa saker behöver man se till själv när man implementerar ett system. I 800xA-fallet är det skydd av kommunikationen, exempelvis genom att använda IPSec på det sätt som ABB föreslår i anvisningarna. Här är det lätt att man missar viktiga krav i samband med upphandlingar eller systemdesign! Exemplet som Otorio visar i artikeln och videon nedan är en kapning av kommunikationen med en Aspect-server. Vi behöver en lokal! Ni som är tillräckligt gamla kommer kanske ihåg att Johan Ulvesons karaktär Nisse Näslund från TV-programmet Lorry myntade uttrycket "Vi har ju ingen lokal ju!". Jag har en fundering på att skapa en "lokal" för oss OT-människor där man kan diskutera OT-säkerhet, bolla klurigheter, be om hjälp eller sprida bra information. Kanske ett diskussionsforum eller något liknande, helt separat från alla sociala medier, där vi kan diskutera OT-säkerhet. Är det något som du tror du faktiskt skulle använda? Har du åsikter om vad som är viktigt i så fall? Hjälp mig genom att skicka dina spontana tankar till mig på mats@ot-sakerhet.se eller kommentera det här nyhetsbrevet på LinkedIn. Alla andra åsikter och önskemål om nyhetsbrevet tas förstås också emot med väldigt stor tacksamhet! Andrew Ginter har gjort det igen! Han är ett känt namn i branschen och från den podd han skapat hos Waterfall Security. Nu har han skrivit sin tredje bok och den är som vanligt gratis om du ber om den från Waterfall direkt. Skynda dig att beställa! Den har precis landat i min brevlåda så jag har ingen åsikt ännu men jag har hört positiva omdömen från andra. Han diskuterade den nyligen med Dale Peterson på Dales podd. Andrew skrev också ett förtydligande på LinkedIn efter intervjun. De två tidigare böckerna är något av klassiker i branschen och jag vet flera kloka kollegor som startat sina karriärer genom att läsa dem! Stark rekommendation! En annan bok som jag verkligen rekommenderar, åtminstone om du är intresserad av säkerhetsskydd är Kim Hakkarainens bok "Säkerhetsskydd - En introduktion". Den har precis kommit i en uppdaterad andra utgåva. Jag tycker mig själv ha bra koll på säkerhetsskydd men redan på första sidan i boken var jag tvungen att säga "Jasså? Det hade jag inte koll på!". Det här är ett klurigt ämne men Kim kombinerar ett sinne för detaljer med en förmåga att skapa överskådlighet och tydlighet, vilket gör boken lätt att både läsa och att hitta i. Den funkar definitivt både som lärobok och som uppslagsverk oavsett om du är ny eller senior inom säkerhetsskyddet! Nu får det vara slutlekt! Ja, det är faktiskt den underbara titeln på ett examensarbete om NIS2 som Ellinor Dison skrivit vid Stockholms Universitet. Undertiteln är "Cybersäkerhetskraven för privata aktörer i ljuset av NIS2-direktivet". Hon skriver ingenting specifikt kring just OT-säkerhet, men jag måste säga att det är en rejäl sammanställning av området med många kloka resonemang och intressanta jämförelser med NIS-direktivet. Rekommenderas för alla NIS2-intresserade! Bra texter måste inte ha en rolig titel! Jämfört med Ellinors examensarbete har inte Björn Leanders doktorsavhandling vid MDU, Mälardalens Universitet: "Dynamic Access Control for Industrial Systems" den roligaste titeln i världshistorien. Men den innehåller å andra sidan desto mer OT-säkerhet, vilket ju är väldigt roligt i mina ögon! Roligt är också att den faktiskt tittar på praktiska lösningar för intressanta problem vi kommer stå inför när våra automationssystem framöver börjar se annorlunda ut än idag. Det där med "Industri 4.0" och "Industrial Internet" har vi knappt sett början på ännu! Avhandlingen tittar på dynamisk accesskontroll med målet att stötta ett införande av Zero-trust i OT-system inom tillverkande industri. Det kanske låter lite tungt att läsa en doktorsavhandling? Och så kan det ofta vara, akademi och industri har verkligen olika sätt att göra saker. Men jag tycker Björn har lyckats göra sin text riktigt läsbar och intressant. Är man det minsta intresserad av ämnet så ska man absolut läsa den! Det finns faktiskt en massa andra bra anledningar att läsa avhandlingen också. Bara i kapitel 2, "Bakgrund" beskriver Björn en massa bra baskunskaper som är värda att läsa på deras egna meriter. Exempelvis trender i avsnitt 2.2 där vi, kortfattat men väldigt tydligt, får förklarat skillnaderna mellan den "gamla skolan" där det gäller att hierarkiskt strukturera dataflöden i automationssystem enligt Purdue-modellen kontra den "nya" nätverksbaserade modell som bland annat förespråkas i OPAS-standarden. (Sök i nyhetsbrevet, jag har skrivit om OPAS förut!) Nyttigt att ha koll på när vi snart börjar röra oss mot den fjärde industriella revolutionen på riktigt! OT-system kommer byggas väldigt annorlunda om några år! Björns arbete ställer flera intressanta frågor och försöker förstås också svara på dem. Ett grundläggande exempel för accesskontroll är "Hur beskriver man regler för accesskontroll på ett sätt som passar i en extremt flexibel tillverkningsmiljö?" Det låter som en enkel fråga men i en tänkt framtid där alla system har tillgång till all data och där tillverkningsprocessen i sig själv dynamiskt (och automatiskt) förändras efter behoven blir det en riktigt klurig nöt att knäcka! Arbetet ger förstås inte alla svar som behövs men i Björns sammanfattning får vi en radda intressanta frågor för framtida arbete: Arbetet fokuserar på kommunikation mellan enheter. Motsvarande arbete behövs för mänsklig interaktion och kommunikation med helt andra system. Hur man praktiskt integrerar resultaten i industriella produkter? Dagens PKI-lösningar är anpassade för IT-användning, hur ser en vettig PKI-lösning ut för industriellt bruk? I traditionella automationssystem är det väldigt tydligt vilken enhet som äger en viss utsignal. I framtida nätverksbaserade lösningar är det inte självklart och behöver styras upp. Jag rekommenderar varmt egen läsning i avhandlingen. För den som inte får nog har Björn och hans medarbetare skrivit en radda intressanta papper. Vissa av dem ingår i avhandlingen och andra inte. Några exempel är: Access Control Models to secure Industry 4.0 Industrial Automation and Control Systems som även innehåller de här artiklarna: Cybersecurity Challenges in Large IIoT Systems Applicability of the IEC 62443 standard in Industry 4.0 / IIoT Access Control for Smart Manufacturing Systems A Recipe-based Algorithm for Access Control in Modular Automation Systems Towards an ideal Access Control Strategy for Industry 4.0 Manufacturing Systems Access Control Enforcement Architectures for Dynamic Manufacturing Systems Simulation Environment for Modular Automation Systems Classification of PROFINET I/O Configurations utilizing Neural Networks Anomaly Attack Detection in Wireless Networks Using DCNN Developing and Evaluating MQTT Connectivity for an Industrial Controller Dependability and Security Aspects of Network-Centric Control Enhanced Simulation Environment to Support Research in Modular Manufacturing Systems Jag var på plats på MDU när Björn presenterade sin avhandling. Som opponent hade man tagit i rejält och plockat in Marina Krotofil (som jag skrev om senast i Nyhetsbrev #54). Marina, tillsammans med en betygskommité, ställde en lång radda utmanande frågor som Björn hanterade galant. I slutändan blev omdömet "Godkänt" så ett stort grattis är på sin plats! Det här är ett spännande område där vi kommer se att mycket förändras framöver, och tyvärr inte alltid åt ett håll som vi säkerhetsmänniskor gillar. Grundtänket kring identitetsstyrd åtkomst, som numera oftast går under slagordet "Zero trust", har alltid varit rätt - därom har jag inga tvivel, även i OT-världen. I slutänden tror jag att en kombination av traditionella segmenteringsåtgärder och "zero trust"-inspirerad åtkomststyrning i linje med Björns tänk kommer bli framgångsrikt i många branscher. Jag skulle dessutom vilja lägga till motsvarande "zero trust"-tänk i infrastrukturen baserat på Software Defined Networking som anpassar sig efter aktuella behov på samma sätt som den dynamisk åtkomststyrningen. Det är en spännande framtid som väntar för oss som är nördar inom både säkerhet, teknik och industriella processer! Det smällde i Danmark och Pennsylvania! Om du är intresserad av OT-säkerhet har du förmodligen redan koll på händelserna i Danmark och . Om inte, så hittar du den danska rapporten från SektorCERT här tillsammans med ett par artiklar från media: Govinfosecurity och Industrialcyber. Händelserna i Aliquippa, Pennsylvania kan du läsa om i en rad artiklar. Exempelvis SecurityWeek, CSO och en text från WaterISAC. En oväntat kompetent mojäng! I mitt kära hemmalabb är det förstås fokus på säkerhetsprylar. Den här gången blev det något av en överraskning hur mycket annat än "bara säkerhet" som man ibland får på köpet. Fast förmodligen skulle tillverkaren säga att det är säkerheten man får på köpet... En viktig del i säkerheten de senaste åren är att kunna jobba med integrationer och dataflöden på ett säkert sätt. Det är precis i den nischen som den här produkten är tänkt att excellera - och utan att avslöja för mycket redan tycker jag att den verkar göra ett bra jobb! Jag fick nyligen fingrarna på en "Ewon Flexy 205". Ewon är från början ett belgiskt företag som numera ingår i den svenska "HMS Networks"-koncernen. HMS annonserade för övrigt tidigare i veckan att man köper amerikanska företaget Red Lion Controls, vilket känns som en jättebra matchning! Red Lion köpte i sin tur tyska firman MB Connect Line för ett år sedan, intressant utveckling... Tanken från min sida var att komma över en enkel och rimligt säker VPN-produkt så att jag kan nå hemmalabbet på distans. Till det yttre ser den kanske inte så imponerande ut. En ganska enkel plastkapsling med DIN-fäste och fyra RJ45 nätverksportar. Inget märkligt så långt... Sedan inser man att den har två kortplatser där man kan kombinera olika typer av instickskort för att utöka funktionaliteten. Det visar sig att det finns en radda kort som man kan stoppa i, exempelvis med MPI-port för att prata med PLC:er från Siemens, ytterligare nätverksportar, 4G, WIFI, Serieportar eller kanske USB? Dessutom finns det en lucka där man kan stoppa in ett SD-minne! Hmm? Vad är det här för en manick jag fått fingrarna på egentligen? I mitt fall sitter ett kort instucket med ett gäng digitala och analoga in- och utgångar. Hmm? Ett IO-kort? På en VPN-server? Intressant... När man vänder på den och tittar på anslutningen för strömförsörjning så finns det även där ett par digitala in- och utgångar som är inbyggda i grundenheten. Det visar sig att det här är en M2M-router, alltså en lösning för att få maskiner att kunna prata med andra maskiner. Ett mer poppigt namn på samma sak kanske är IIoT-gateway? Att jag kan använda den som VPN-router är bara en liten fotnot i listan över vad det här underverket kan leverera. Att få igång enheten på nätverket är enkelt med hjälp av wizards. Att få igång fjärranslutning kräver bara att man registerar ett konto på Ewons webbtjänst och kör en konfigurations-wizard. Sedan börjar det roliga. Vill man ha direktkontakt med en PLC så finns beskrivningar för hur man konfigurerar sin PLC från Siemens, Yaskawa, Omron, Rockwell, Schneider osv. Kom ihåg att det här inte i första hand är en klassisk VPN-server utan en integrationsplattform. Den kan själv suga i sig data via OPC UA, MODBUS TCP, BACnet, http, ftp eller en rad leverantörsunika protokoll för olika fabrikat av PLCer. Som "vanligt" skapar du taggar i Flexyn för den information som ska hanteras. Taggarna kan vara enbart för läsning eller tvåvägs så att man kan skriva värden via Flexyn. Taggarna kan du sedan sätta loggning för, övervakning på och definiera larm för. För att exportera data kan enheten skicka loggfiler eller definiera egna taggar som kan läsas av andra enheter via MODBUS TCP, SNMP (!) eller den inbyggda servern för OPC UA. Om man vill kan data löpande exporteras externt via Ewons molntjänst, Talk2M. Den kan också extraknäcka som konverterare till seriella protokoll! För att styra upp nätverkstrafiken finns grundläggande brandväggsfunktioner och NAT-funktionalitet på plats. Vill man koppla den mot andra VPN-tjänster har den även en OpenVPN-klient inbyggd! Om man tittar på de olika instickskorten så finns en radda intressanta möjligheter. Seriekortet har två portar, en RS232 och en konfigurerbar RS232/RS422/RS485 med eller utan terminering. Kortet med nätverksuttag är precis bara det, om man behöver fler än de fyra inbyggda nätverken kan man få fler. Korten med WIFI eller 4G är precis vad det låter som och USB-kortet kan exempelvis användas för att komma åt USB-enheter på distans som om de vore lokala! Sedan visar det sig till slut att man kan bygga HMI-sidor i enheten som publiceras av den inbyggda webbservern och till på köpet går det att programmera egna funktioner i Java. Jisses vilken mackapär! Snacka om att jag missförstod den här lilla lådan när jag fick den i handen! Den kanske inte var den VPN-tjänst som jag trodde, men det är ju inte heller meningen med den! För den som vill bygga dataflöden på distans eller samla in (och presentera) data från andra enhet så imponerar mängden funktionalitet rejält! Det verkar dessutom finnas allt man kan önska sig för att skapa en säker lösning. Man ska tydligen inte döma M2M-routern efter utseendet! Principer för industriell cybertålighet WEF, World Economic Forum, har gett oss ett whitepaper med titeln "Unlocking Cyber Resilience in Industrial Environments: Five Principles". Innehållet är precis vad titeln hintar om, fem principer som är grundläggande för god OT-säkerhet: Riskhantering Ansvar för OT-säkerhet Samordning med ledning och strategi Skapa säkerhetsstandarder och rutiner Öva, öva, öva! Det är inte på något vis ett revolutionerande dokument men det är kraftfullt att kunna referera till vad WEF säger när man diskuterar prioritering och resurssättning! Nyhetsbrevet växer! Jag vill tacka dig som läser och sprider nyhetsbrevet vidare. För varje upplaga så blir det fler som läser det, vilket säger mig att det fortfarande finns ett behov och ett intresse för den här typen av innehåll! Strax efter att förra nyhetsbrevet släpptes slog vi ett nytt rekord med 450 läsare på en enda dag. Kul! Att jag driver nyhetsbrevet vidare bygger mycket på det gensvar som jag får. I grunden kommer nyhetsbrevet även i fortsättningen baseras på att jag dammsuger OT-världen efter de mest intressanta nyheterna och skriver om dem. Jag roade mig med att ta fram lite statistik kring vilka nyhetsbrev som har väckt mest uppmärksamhet. Det är ganska tydligt att det är tre saker som just nu ligger i topp när det gäller att skapa lite extra intresse från dig som läser: NIS2 Hemmalabbet Mina egna reflektioner kring branschens utmaningar Att det är de tre är extra kul med tanke på att det är tre ämnen som jag gillar att skriva om! NIS2 kommer ju bara bli mer och mer aktuellt i takt med att vår deadline närmar sig. Hemmalabbet kommer jag försöka prioritera mer framöver även om det tar mycket tid och det är svårt att komma över spännande utrustning. Donationer och lån av prylar mottages tacksam! Mina egna reflektioner kring trender och gemensamma egenheter jag stöter på hos mina kunder kommer ganska naturligt, så det blir det mer av framöver också! Tack för ert intresse! Många svenskar på plats! Tittar just på deltagarlistan för nästa S4-konferens och ser 12 personer som är registrerade från Sverige! Kul! Biljettförsäljningen slår tydligen (som vanligt) rekord och de sista 250 biljetterna säljs nu. Agendan börjar bli klar och ser (också som vanligt) superintressant ut! Ska bli kul! Lite fundersam blir jag över att det (än så länge) bara är en enda deltagare från det privata näringslivet! (Förutom alla vi konsulter och produktleverantörer förstås!) Konferensarrangörerna ser ju också detta som ett problem och testar i år begränsningar i hur många deltagare en konsultfirma får ha. Dessutom är de sista hundra biljetterna reserverade för "Asset owners". Vi ses där! Attacker mot olja och gas TxOne har givit ut en välfylld rapport kring olje- och gasindustrin som ju är en verksamhet med väldigt speciella förutsättningar och som är extra utsatt av många olika skäl. Vi får en genomgång av branschen, en analys av hotlandskapet och förstås en analys av de olika delarna i typiska attacker, inledande access, lateral förflyttning, påverkan och konsekvenser samt (förstås) tankar kring hur man kan motverka de olika delarna i attackerna. På vägen får vi en analys av typiska problem i vanliga systemkomponenter inklusive OPC UA, som har bred spridning i den här branschen. Totalt 28 sidor som man tar sig igenom ganska enkelt. Inte OT men intressant ändå... En intressant artikel om tåg som saboterades av tillverkaren för att ingen annan leverantör skulle kunna göra underhåll på dem. Om det inte hade varit för att jag själv faktiskt varit med om något liknande i ett IT-system skulle jag knappt tro på historien! Man kan väl mycket väl tänka sig något liknande sabotage i klassiska OT-system? Ett fantastiskt sätt att bli rejält svartlistad som leverantör är det oavsett! Senaste nytt från hemmalabbet För den som är tekniknörd och intresserad av vad som händer i mitt labb för OT-prylar hemma så har jag gjort ett om-tag kring virtualisering. En bättre begagnad mini-PC (6 CPU cores, 32 GB RAM) kör nu Proxmox vilket erbjuder otroligt smidig virtualisering och hantering av Linux-containers (LXC). Nätverket har fått en ny VLAN-indelning vilket gör att jag kan hantera ett gäng separata nätverk med en blandning av virtuella system, containers och förstås fysiska OT-prylar. Som gammal Unix/Linux-hacker är det helt underbart att återvända till den världen via Proxmox som verkligen är makalöst kraftfullt! Ett antal system har redan "flyttat in", först ut var virtuella administrationskonsoler för säkerhetslösningar som exempelvis TxOnes EdgeOne, en installation av Kali-Linux och agenter för SensorFu Beacon som du kan läsa om på annan plats i det här nyhetsbrevet. Till nästa nyhetsbrev pågår redan experiment med en riktigt imponerande lösning för att hantera fjärråtkomst för leverantörer och annat "löst folk". Återkommer om det! Gammal är äldst! Såg ett inlägg på LinkedIn häromdagen som påminde mig om ett av de äldsta OT-säkerhetsdokument som jag kan minnas att jag läste "på den gamla goda tiden"; "21 Steps to Improve Cyber Security of SCADA Networks". Det gavs ut 2002, alltså fyra år innan Stuxnet ens hade börjat planeras! Att det kom till just 2002 är ingen slump, det bedrevs en hel del nyskapande riskanalysarbete efter attackerna den 11:e september 2001! Det är värt att notera att allt som skrevs då fortfarande är lika relevant. Man uttrycker sig lite annorlunda och har kanske en lite annan ordning i prioriteringarna, men i grunden ändå väldigt likt. Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Några höjdpunkter den här gången är att jag blev lurad av Fortinet, vi får nytänk kring Security Levels i IEC 62443, en ny version av CVSS, jag frågar mig hur det går med NIS2 egentligen, ny awarenessutbildning för OT, nytag (igen) i sjöfarten, CSAF, jag besöker en podd, analys av DOS-attacker mot OPC UA, EU rör sig framåt kring CRA/EUCC och så lär vi oss om ”Conways Lag”.. 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å 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! CVSS i ny version! CVSS är en standard för att bedöma hur allvarlig en sårbarhet är. Jag har skrivit om utkasten till version 4 av CVSS tidigare, i Nyhetsbrev #50 och Nyhetsbrev #53. Nu har den skarpa versionen släppts av FIRST tillsammans med all dokumentation och en kalkylator. Vid en första anblick ser det ännu mer komplicerat ut än tidigare versioner och det visar sig att det intrycket är rätt! Det är definitivt fler "rattar" att skruva på när man ska bestämma allvarligheten hos en sårbarhet samtidigt som det faktiskt får den här versionen att kännas mer rättvisande och sund. Precis som i version 3 blir resultatet från en bedömning en siffra mellan 0 och 10 som ska vara en sammanfattning av sårbarhetens allvarlighet samt en kryptisk sträng som beskriver alla aspekter som vägts in i siffran. I version 4 kan den bli ganska lång om alla aspekter bedöms, exempelvis: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:H/SC:H/SI:L/SA:H/E:A/CR:H/IR:M/AR:L/MAV:P/MAC:L/MAT:P/MPR:N/MVC:L/MVI:L/MVA:N/MSC:L/S:P/AU:Y/R:I/V:C/RE:H/U:Red Siffran och strängen skickas normalt med när en sårbarhet annonseras. Som bilden illustrerar är det fyra huvudgrupper av bedömningar som ska göras. De är: Base Metrics - Sårbarhetens egna egenskaper som inte kommer förändras över tid. Här finns två undergrupper: Exploitability Metrics och Impact Metrics. Den förstnämnda kan man säga beskriver hur enkelt det är att utnyttja sårbarheten medan den andra (Impact Metrics) beskriver konsekvenserna för systemet själv men också för andra system vars säkerhet är beroende av det beskrivna systemet. Threat Metrics - Beskriver hur sårbarheten kan förändras över tid vilket i praktiken är om det finns kända sätt att utnyttja sårbarheten. Bedömningen bör därför inte skilja mellan olika organisationer. Environmental Metrics - Beskriver hur sårbarheten är applicerbar i en viss organisation eller en viss del av en organisation. Sårbarheten kanske har en annan påverkan än den generella eller kan utnyttjas på ett annat sätt. Man kanske har något slags skydd som gör sårbarheten svår att utnyttja eller så är det sårbara systemet väldigt viktigt. Supplemental Metrics - Här kan man beskriva påverkan på yttre faktorer och från yttre faktorer. Mest relevanta faktorer för OT-säkerheten är förmodligen om sårbarheten kan leda till farliga situationer ur ett Safety-perspektiv och hur svår återställningen efter en attack blir. Ingen av dessa påverkar det numeriska "betyget" på sårbarheten men kommer med i den beskrivande strängen som kan påverka hur den egna organisationen prioriterar sårbarheten. Det är viktigt att notera att Base Metrics och Supplemental Metrics normalt sett definieras av den som rapporterar sårbarheten medan Environmental Metrics och Threat Metrics definieras baserat på mottagarens ögonblicksuppfattning. Det betyder alltså att en klok idé är att ta leverantörens definition och sedan modifiera den utifrån de egna förutsättningarna innan man tar beslut om hur sårbarheten ska hanteras. Nu är jag inte någon stark förespråkare för att man maniskt ska jaga sårbarheter i sin OT-miljö, det är typiskt ett svårt och dyrt sätt att få hög säkerhet. Men det betyder inte att det är en dålig idé, i synnerhet om man kommit en bit på väg i att bygga en arkitektur som går att försvara. Den nya versionen av CVSS känns vettig just för att det är enkelt att göra egna bedömningar utifrån den egna organisationens förutsättningar och därför fokusera på det som verkligen har effekt på riskerna. På väg ner i diket? När jag frågar organisationer om deras syn på hur NIS2 kommer beröra dem är det roligt att höra att många numera faktiskt vet om att NIS2 kommer. Samtidigt blir jag förvånad över den stora andelen som fortfarande inte förstått hur stort scope NIS2 har. Onödigt många har därför inte heller gjort den allra enklaste formen av analys för att reda ut hur de berörs. I synnerhet gäller detta tillverkande industrier, som väldigt ofta inte kan ta till sig tanken att deras produktion skulle kunna betraktas som samhällsviktig. Det är tyvärr dessutom vanligt att få reaktionen "det finns ju inte ens en svensk lag ännu", speciellt från jurister. Det är förvisso sant men det indikerar på en ganska dålig insikt om vad ett EU-direktiv i praktiken är. Att man som verksamhet inte förstår att man är viktig för samhället är ju för övrigt precis det problem som NIS2 är tänkt att lösa. Allt säkerhets- och riskarbete handlar om att balansera riskkostnader mot kostnaderna för att göra någonting åt riskerna. Problemet är att en typisk industri som gör riskanalyser kring deras system sällan tar med konsekvenser av typen "Om vi inte kan producera våra varor så påverkas samhället negativt". Man fokuserar normalt enbart på konsekvenser för den egna organisationen och indirekt även kunderna. Det EU nu gör med hjälp av NIS2 är att man säger: Eftersom ni inte anstränger er nog för att minska riskerna för samhället så kommer samhället skapa nya risker för er. De kommer i form av sanktionsavgifter, personligt ansvar för ledningen och hårdare krav från era kunder. De riskerna kan ni minska genom att göra er produktion mer robust. Då är det ju lite ironiskt att så många verksamheter fortfarande inte förstått att det är på väg att läggas en massa nya risker i deras vågskålar. Riskerna som vi oavsiktligt skapat för EU:s gemensamma marknad kommer tillbaka och biter oss i rumpan som sanktionsavgifter... Nu är vi inne på "upploppet", det är mindre än ett år kvar innan alla krav ska vara uppfyllda. Visst, tillsynsmyndigheterna kommer vare sig vilja eller kunna jaga misskötta organisationer redan dag ett. Men om din organisation råkar ut för en större incident den 18:e oktober och ni inte tagit NIS2 på allvar så kommer det ändå ganska snabbt kunna bli jobbigt för ledningen! Tack vare direktivets stora fokus på att man måste ställa säkerhetskrav på sina leverantörer, kommer väldigt många organisationer beröras indirekt genom sina kunder. Möjligheten att skapa konkurrensfördelar genom att vara snabb på bollen finns fortfarande kvar ett tag till, men det tåget lämnar också stationen nu. En typisk ledningsgrupp som får förklarat för sig vad direktivet är och det ganska brutala ansvar som det lägger på både företagsledning och styrelse brukar snabbt förstå allvaret... Att sedan reda ut hur organisationen berörs är faktiskt ett relativt litet jobb om man är van vid sådana analyser och ger i de flesta fall ett ganska entydigt resultat. Jag hoppas att "ryktet" om NIS2 kommer börja sprida sig mellan styrelserummen, för det är fortfarande märkligt tyst i media om denna stora omställning. Tyvärr är det också väldigt tyst från myndighetshåll, speciellt om man jämför med andra länder, där exempelvis Finland sticker ut som ett föregångsland, där allmänna informationsmöten hålls regelbundet. Myndigheter, politiker och verksamheter träffas för att lyssna på varandra. Många ledningar, styrelser och säkerhets-ansvariga kommer få ett jobbigt uppvaknande under 2024 och då blir det tufft att hinna komma på banan. Något som är viktigt att ta med sig är att EUs definition av samhällsviktig verksamhet inte alltid matchar den som de flesta människor spontant har själva. Se till att göra en analys för din egen organisation och för era viktigaste kunder! Dags för oss att tänka om? När Sinclair Koelemij skriver en artikel är det alltid intressant och klokt. Det gäller för övrigt även när han presenterar på konferenser, vilket ni som var på plats i Solna på AFRYs OT-säkerhetskonferens i slutet av september märkte. Nu har han skrivit en artikel som utmanar det etablerade och lite stelbenta tänket från IEC 62443-3-3 kring Security Levels. Och det är just det stelbenta som är en av källorna till problemet vilket gör det svårt att använda ett mer modernt och riskbaserat angreppssätt när man designar sina system. Jag kan bara konstatera att jag håller med om vad han säger. En utmaning med ett "klassiskt" riskbaserat angreppssätt är att vi saknar information om sannolikheter. Det är helt enkelt för ovanligt med angrepp mot OT-system! Sinclair slår därför ett slag för ROPA (Rings of Protection Analysis) som ett starkt alternativ. Hans tidigare text om ROPA har jag skrivit om i Nyhetsbrev #50 och varför inte titta på hans dragning från S4 i våras kring semikvantitativa riskanalyser av cyberfysiska risker: När du ändå är igång så tycker jag gott du även kan läsa Sinclair artikel "Process Safety and OT Security – A Symbiotic Relationship" där han slår ett slag för triaden "COO" istället för "CIA" som vi känner igen från IT-säkerhetsvärlden. Tänkvärt om du inte funderat över den här typen av frågor tidigare! Du skulle också bli lurad! Det landade en riktigt rolig grej i mitt hemmalabb, en FortiDeceptor från Fortinet. Det här är en produkt som utvecklats mycket de senaste åren och det var roligt att upptäcka alla nya funktioner. Den finns som virtuell maskin eller hårdvaror i två olika format. Den variant jag tittat på är en ruggad version som är mycket väl anpassad för tuffa fysiska miljöer. Det är en stadig kloss som kanske inte är så stor, men som tack vare de rejäla kylflänsarna ändå väger in på 6 kilo och ger ett massivt intryck. I grunden är syftet med produkten att på olika sätt lura en angripare genom att skapa fejkade men samtidigt väldigt "naturtrogna" system och applikationer på nätverken. Angriparen ska luras att ge sig på dessa låtsas-resurser vilket då genast avslöjar angreppet och möjliggör en analys av vad angriparen gör. För att göra det lätt för en angripare att hitta till de fejkade systemen kryddar man sina "riktiga" system med "Tokens". Det kan exempelvis vara cachade inloggningar, databas-anslutningar, fildelningar och konfigurationsfiler. Det här är saker som angripare letar efter som ett verktyg för att röra sig mellan system, vilket passar oss utmärkt i fall vi kan få angriparen att röra sig mot ett av våra lockbeten. Det här är kraftfull teknik även i IT-världen men i hos oss i OT-sammanhang blir det ännu mer avgörande eftersom vi kan placera dessa enheter i nätverk och system som normalt sett är väldigt statiska. Tack vare det sticker ovanliga beteenden ut extra mycket vilket gör det mycket utmanande för en angripare att röra sig i systemen utan att väcka uppmärksamhet. Enkelt förklarat kör en FortiDeceptor ett antal virtuella system som presenteras på nätverket. Det är en lång rad olika systemtyper som kan skapas: Windows 7/10/11/2016/2019/2022, Ubuntu Desktop, CentOS, ESXi och ELK. Dessutom kan du installera dina egna standard-images för organisationen inklusive AD-integration! Så långt är det redan imponerande men sedan börjar det bli riktigt intressant när vi kommer till "IoT"... I kategorin "IoT OS" kan du skapa fejkade skrivare av olika fabrikat, Cisco-routrar, IP-kameror och en massa annat. I andra kategorier kan du skapa medicintekniska system som exempelvis infusionspumpar men också kassasystem, ERP-system (som SAP) och stödsystem för MQTT, CoAP och XMPP. Sedan blir det förstås ännu intressantare när vi kommer till OT-prylar. Här hittar vi fejkade versioner av utrustning från exempelvis Kamstrup, Liebert Spruce, Niagara, Rockwell, GE, Schneider, Moxa, Siemens och Phoenix Contact. Dessa kan nås via "rätt" protokoll och tjänster, som kan vara DNP3, HTTP, Modbus TCP, ENIP, BACNET, TRICONEX, S7COMM, IEC104, Profinet och en massa andra! Här hade det verkligen hänt saker sedan jag tittade på den här produkten för ett antal år sedan! Ett intressant sätt att använda en FortiDeceptor är att sätta den i "DMZ Mode". Tanken med det är att den finns i ett DMZ, antingen nära Internet eller mellan två interna nätverk - i vårt fall typiskt mellan "IT" och "OT". Det här är förstås ett riktigt kraftfullt sätt att fiska efter de fula fiskar som gärna söker sig till den utsatta miljö som ett typiskt DMZ är. Riktigt användbart! Eftersom ett DMZ är ett tufft ställe att befinna sig även för en FortiDeceptor så låser systemet ner sig när man går till det här läget, vilket begränsar vad man kan göra med lösningen i övrigt. Bra tänkt! Det här är i grunden en passiv lösning men det finns bra möjligheter att få saker att hända automatiskt när ett angrepp upptäcks. Man kan integrera med en rad olika fabrikat av Sandboxar så att angreppskod som fångas under en attack automatiskt skickas på analys direkt. Om man använder nätverksutrustning från Fortinet kan man välja att få automatisk blockering/karantän av angripare och det finns också integrationer till motsvarande funktioner hos en massa andra leverantörer. Det här är något som förstås är extremt kraftfullt men också något man får vara lite försiktig med i OT-miljöer så man inte råkar "skjuta sig själv i foten"... Apropå speciella saker inom OT så finns förstås ett riktigt snyggt stöd för "MITRE ATT&CK for ICS". Ett bra hjälpmedel för både incidentanalys och förebyggande arbete. Dessutom kan du slå på "Asset discovery", vilket - precis som det låter - hjälper till att (passivt) identifiera vad som finns på de nätverk som den är ansluten till. Ett bra stöd i den ständiga utmaningen att underhålla bra inventarieinformation! Det här är ett riktigt smidigt system att jobba med. Det är enkelt att komma igång men samtidigt har man alla möjligheter att göra riktigt avancerade konfigurationer av de fejkade systemen. Om man har stora installationer med många FortiDeceptors kan en av dem ta rollen som manager och styra hur de övriga konfigureras. Om man vill automatisera användningen av FortiDeceptor så finns det ett JSON API där de viktigaste funktionerna kan styras och mätas. Hör gärna av dig om du har funderingar eller kanske idéer kring hur den här tekniken kan användas på kreativa sätt! Är du medveten om medvetenheten? Om du jobbar inom industrin har du sannolikt stött på SSG, Standard Solutions Group. SSG startades på 50-talet som en underavdelning till SCA, och skulle hantera och ta fram interna standarder. Numera ägs SSG gemensamt av SCA, Billerud, Korsnäs, Södra Skogsägarna, Holmen, StoraEnso och Metsä Board. SSG är nog mest kända för "SSG Entre", en tillträdesutbildning för alla som ska som ska komma in och arbeta på en industrianläggning och därför behöver generell kunskap om bland annat arbetsmiljö, tillstånd, krav och miljö. SSG driver olika nätverk och arbetsgrupper som tar fram branschgemensamma standarder för industrin och nyligen har en arbetsgrupp inom nätverket IT och automation tagit fram "SSG Cyber Security", en awareness-utbildning med fokus på verksamheter som använder OT. Vi är alla vana vid (och trötta på?) vanliga awareness-utbildningar, där vi gång på gång får lära oss att inte klicka på länkar och använda USB-minnen. "SSG Cyber Security är motsvarande utbildning men med fokus på tillverkande industri där tanken är att alla medarbetare ska få ökad medvetenhet om hur modern teknik påverkar säkerheten i en anläggning och vilken roll deras eget beteende har för att det ska fungera på ett säkert sätt…. Jag har inte stött på något liknande tidigare och det är dessutom något som jag efterlyst i olika sammanhang. För full transparens ska jag vara tydlig med att jag varit med att ta fram utbildningen, men jag måste ärligt säga att jag tycker slutresultatet blev bra! Det ska bli intressant att höra hur den tas emot ute i verksamheterna! Det här med awareness-utbildning är ett område som det finns många åsikter om. Jag tänkte genast på den här videon där den ständigt intressante och kloke Ralph Langner berättar varför den här typen av utbildning är skräp! Den är några år gammal men i princip fortfarande lika relevant... Jag håller med Ralph i mycket av det han säger, men personligen tycker jag att den här typen av medvetandegörande är viktig. Samtidigt får man inte se det som en komplett lösning. Att utbilda är bara början, men utan att göra det kommer vi inte få bra effekt på allt annat säkerhetsarbete! Om inte medarbetare, konsulter och entreprenörer är medvetna om varför säkerhet är viktigt och vad deras egen roll är så kommer de aldrig att acceptera de säkerhetslösningar som sätts på plats. Om man inte är medveten kommer man inte ha en chans att ifrågasätta konstigheter eller vilja prioritera säkerhet över andra resultat! En viktig poäng som Ralph gör är att det finns alldeles för många "OT-säkerhetsexperter" som inte har en aning om hur vardagslivet "på golvet" ser ut. En tråkig sidoeffekt av att det är svårt att få tag på erfaret OT-säkerhetsfolk är att självutnämnda experter på andra typer av säkerhet gärna uttalar sig om vad som är rätt och fel inom OT-säkerhet. Ofta får de dessutom inget mothugg... Ralph pekar själv på lösningen, se till att bjuda in folket från IT-avdelningen eller säkerhetsavdelningen till en dag i verksamheten. Det gäller även oss konsulter, i ett nytt uppdrag propsar jag alltid på att få en rejäl genomgång ute i verkligheten. Alla verksamheter är olika och det vill till att förstå vad som är unikt hos varje kund! Ibland har jag förmånen att bli inbjuden på studiebesök hos spännande verksamheter, vilket jag alltid tackar ja till eftersom det är jätteroligt och i 100% av fallen resulterar i att både jag och verksamheten får nya insikter. Magplask eller inte? Som jag har skrivit i tidigare nyhetsbrev tar sjöfartsindustrin ett rejält tag i OT-säkerhetsfrågor på ett sätt som känns ganska framsynt. Nästa steg i det är klassningssällskapens samarbetsorganisation IACS som publicerat ett par dokument (UR E26 och UR E27) som skall börja gälla skarpt från årsskiftet. Eller rättare sagt... Skulle börja gälla då! I en pressrelease nyligen drog man tillbaka dokumenten och lovar nya versioner av dokumenten och "sjösättning" 6 månader senare. Den nya revisionen av E27 finns redan på IACS site medan E26 ska komma innan årsskiftet. CISA börjar med CSAF! Varning! Om du ogillar förkortningar kan denna artikel orsaka svåra besvär! För dig som jagar sårbarheter är den amerikanska myndigheten CISA en användbar källa till annonseringar av nya sårbarheter. CISA har just annonserat att de nu utökar denna annonsering genom att även sprida samma information i CSAF-format. Samma resonemang har börjat komma från produkttillverkare också, exempelvis annonserade Siemens detta i våras tillsammans med deras avsikt att på sikt avveckla andra format, exempelvis PDF, Text och CVRF. Ett stort problem med de ständigt ökande mängderna sårbarheter som upptäcks är att annonseringen har olika format och innehåll beroende på vem källan är. CSAF är ett försök att råda bot på detta genom att annonseringen sker i ett standardiserat och maskinläsbart format som bygger på JSON. Formatet utvecklas av standardiseringsorganisationen OASIS, som för övrigt driver en väldig massa standardiseringsarbeten inom oväntat många dataformat - några av de mest kända är MQTT, SAML och OpenDocument. Det finns dessutom definierade metoder för hur detta knyts samman med SBOM, (Software Bill Of Materials), och andra viktiga delar kring att bedöma sårbarheter, exempelvis VEX. Här kommer det ske väldigt mycket utveckling de närmaste åren! Att vi sedan behöver fundera på om det är vettigt att jaga sårbarheter inom OT-säkerhet, det återstår fortfarande... Om du är en av de som börjat använda VEX kring OT så är jag nyfiken att höra mer om dina erfarenheter! Hör gärna av dig! mats@ot-sakerhet.se Jonas Berge och Conways lag! Melvin E. Conway är något av en legend inom datavetenskapen, inte minst för att han myntade Conways lag: Organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations En annan person som, i min högst personliga åsikt, också borde betraktas som en legend av klokskap är Jonas Berge. Inte nog med att han nyligen kryddade en (som vanligt) läsvärd artikel med citat från Conway, han gör också en radda kloka observationer kring kopplingen mellan Conways lag och varför den ständigt missförstådda Purdue-modellen ser ut som den gör. Vi får dessutom en moderniserad uppfattning av hur dataflöden kan se ut! Byt media! Om du börjar bli trött på att läsa mina texter kan du variera dig genom att lyssna på ett avsnitt i Advenicas podd "Cyberlandet" där jag är med för att diskutera OT-säkerhet med fokus på VA-branschen. (Vatten och Avlopp!) Det är en vansinnigt viktig verksamhet som innehåller mycket OT men som samtidigt väldigt ofta saknar resurser för att bedriva ett rimligt säkerhetsarbete. DOS-attacker mot OPC UA! Team82 från Claroty fortsätter publicera intressanta tekniska artiklar med fynd från deras säkerhetsforskning kring OPC UA. Den här gången (del 7) tittar de på möjligheter att slå ut system genom olika former av utmattningsattacker. Väl värt att läsa för att få nya vinklar på hur vi och våra system kan råka illa ut! Med rätta märker jag ett ständigt ökande intresse för säkerheten i OPC UA. Även TxOne har dragit igång en serie intressanta artiklar på området: Del 1, Del 2, Del 3. Nästa uppköp! OT-säkerhet är en het bransch men med väldigt osäkra värderingar av hur mycket pengar det egentligen är möjligt att tjäna. De senaste åren har det varit en lång rad med uppköp och nu köpte Rockwell Automation nyligen OT-säkerhetsföretaget Verve. Jag ska inte ge mig på en analys för jag tycker Dale Peterson redan gjort det bra i två artiklar: 1 och 2. S4x24 börjar ta form! Min favoritkonferens, S4, går nästa gång av stapeln i början av Mars. Nu har man börjat annonsera delar av agendan och det ser lyckligtvis precis lika intressant ut som vanligt! Man har redan sålt närmare 700 av de 1100 biljetterna så nu börjar det bli dags att slå till om du inte ska bli utan! Av någon anledning körs det varken Pwn2Own eller Capture-The-Flag i år, men det bör inte påverka huvudkonferensen det minsta. Däremot blir det "the Vulnerability Management Pavilion", där ett antal utvalda företag ska få försöka skapa en så bra bild som möjligt av ett "riktigt" OT-system som byggs upp på plats, med fokus på förstå systemets uformning och att hitta sårbarheter. Det blir inte en tävling med poäng i år utan mer jämförelser och insikter om skillnader. Det är dessutom tillåtet för företagen att samarbeta om det finns nytta med att exempelvis förse en SBOM-produkt med en bättre inventerielista från en scanner som sedan får tillbaka information om detaljer om prylarna. Ska bli intressant att se! De företag som fick plats är: Företag med scannerprodukter: Framatome RunZero Tenable Företag med fokus på SBOM: aDolus Finite State Företag inom detektion och risk: Forescout Industrial Defender Otorio I våras var vi hyfsat många svenskar på plats, det vore kul om det blir minst lika många nästa gång! Arrangörerna har verkligen lyckats skapa ett unikt event med minimalt av säljpitchar på scen och extremt framåtlutande presentationer. Det är här det händer! En annan konferens på gång! Värme & kraftföreningen har sin höstkonferens den 14:e till 15:e november. Jag kommer göra ett gästspel där för att prata om NIS2 i förhållande till OT-säkerhet. CRA och EUCC närmar sig!? Ett av de mest omdiskuterade lagförslagen inom EU på senare tid, "CRA" - Cyber Resilience Act rör sig sakta framåt, åtminstone tycks det så på pappret. Senaste livstecknet är ett dokument fyllt med förslag till ändringar som publicerades sista augusti. Jag har inte dykt i vad som föreslås ändras eftersom den största frågan, den kring hur Open Source ska hanteras fortfarande inte verkar ha landat. Jag har en känsla av att ingen kommer vara helt nöjd när vi en gång får ett slutgiltigt beslut - vilket i och för sig brukar tyda på en rimlig kompromiss för alla partner. Den som lever får se... Det rör sig också EUCC, det tänkta regelverket kring EUs cybersäkerhets-certifiering. Den som vill dyka i EUs senaste tankar kring detta kan titta här tillsammans med ENISAs schema här. Det är nu man på riktigt börjar se hur alla dessa regleringar kommer passa ihop, då det finns många kopplingar mellan CRA, NIS2, ENISA och EUCC via deras respektive dokument och via EUs Cybersäkerhetsakt. Stöd för Top 20 Secure PLC Coding Practices Jag har skrivit förut om projektet Top 20 Secure PLC Coding Practices som tog fram 20 av de viktigaste sätten man som PLC-programmerare kan hjälpa systemet att bli säkert och robust. Den som tycker att detta är viktigt kan eventuellt få lite stöd från en resurs som företaget Fortiphyd lagt ut på GutHub och som beskriver hur utrustning från en radda olika tillverkare stöder de olika metoderna. Just nu verkar Siemens, Honeywell, Mitsubishi, Omron, Rockwell, Schneider och Yokogawa finnas med och dessutom finns en plugin för CISAs verktyg CSET. Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Några höjdpunkter den här gången är nytt material från SÄPO och NIST, tankar kring fyra konferenser, begreppet Deep Defense, säkerhetsverktyg med egna säkerhetsbrister, vad man förlorar vid en incident, AFRYs juniorer glänser och ett "Hemma hos"-reportage. 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å 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! En inspirerande bok, del 2 Som jag skrev om i nyhetsbrev #51 har jag läst boken "Industrial Cybersecurity - Case studies and Best Practices" av Steve Mustard. Nu har jag läst ut den, och det goda intrycket jag hade redan då består. Redan från början märker man att Steve, i motsats till många andra som skriver om OT, verkligen förstår både IT och OT. Han kan jämföra dem utan att fastna i de vanliga fällorna där kreativ OT-säkerhet bara brukar handla om att rita om Purdue-modellen på ett nytt sätt eller räkna upp skillnader mellan IT och OT. Han tar oss igenom många viktiga ämnen och gör det på ett sätt som ändå håller boken nere på en rimlig tjocklek, 250 sidor. Innehållsmässigt är den väldigt bred vilket gör den användbar för den som lära sig områdets speciella förutsättningar eller använda den som ett slags uppslagsverk efter behov. Ämnena som avhandlas varierar från det tekniknära som certifieringar och design till mjukare frågor som projektgenomförande, riskanalyser och ledarskap. På det hela en stark köprekommendation om du vill ha en välskriven bok fylld med ovärderliga kunskaper inom ett brett område! NIST har levererat en ny 82:a! Då har vi till slut fått en skarp version av den tredje revisionen av NIST SP 800-82! Jag skrev om draftversionen i nyhetsbrev #42. men nu har NIST alltså samlat in all feedback de fick på draften och levererat en slutgiltig version! Jag har inte hunnit läsa tillräckligt noga för att kunna bedöma vad som skiljer mellan draftversionen och den skarpa version, men det är sannolikt inga stora skillnader. I vilket fall som helst så ger den ett mycket bättre intryck än revision 2 som jag aldrig riktigt blev kompis med... Tankar från en konferens Den 19:e och 20:e september gick årets SCADA-säkerhet av stapeln. Det här är en konferens som funnits i ganska många år nu, vilket man ju också kan ana på namnet. I år var jag där och pratade om hur NIS2 påverkar arbetet med OT-säkerhet. Om du är nyfiken på jag pratade om kan du läsa Advenicas intervju. Riktigt trevlig konferens med många bra diskussioner med både nya och gamla bekanta! Tankar från en annan konferens Den 27:e september arrangerade vi på AFRY konferensen "Nordic OT Security Conference" för första gången. Om jag får säga det själv blev det en riktigt lyckad tillställning, närmast succé med en fulltecknad anmälningslista. Fantastiskt roligt att vara med att organisera detta och verkligen en symbol för den roll AFRY vill ta som medelpunkt för nordisk OT-säkerhetskompetens! På agendan stod en radda intressanta presentationer och paneldiskussioner som till och med överträffade mina egna förväntningar! Dagarna före och efter passade många på att sitta ner med oss och med våra partnerföretag för att djupdyka i aktuella utmaningar och kommande produktförbättringar. Dagens efter konferensen bjöd AFRY och Sandvik tillsammans in till ett rundabordssamtal där vi tillsammans med representanter från ett antal utvalda företag och skolor diskuterade den stora bristen på OT-säkerhetskompetens i samhället. Jag återkommer till resultatet av det. I väntan på Sinclairs bok... En av våra gäster på "Nordic OT Security Conference" var Sinclair Koelemij, en välkänd tänkare inom OT-säkerhet. Han pratade om konceptet "Deep Defense", som inte ska förväxlas med konceptet "Defense in depth". Lite slarvigt kan man kanske säga att "Deep Defense" handlar om att ta ett bredare grepp på säkerhetsarbetet medan "Defense in depth" typiskt handlar om att skapa ett slags redundans genom att ha "överlappande" säkerhetsåtgärder så att man inte är beroende av att en viss säkerhetsåtgärd är perfekt. Han är på väg att publicera en bok i ämnet som jag verkligen ser fram emot att läsa, men i väntan på den finns en artikel om konceptet och en artikel med fokus på supply chain samt en diskussion med Prabh Nair. En tredje konferens på gång! Värme & kraftföreningen har sin höstkonferens den 14:e till 15:e november. Jag kommer göra ett gästspel där för att prata om NIS2 i förhållande till OT-säkerhet. Biljetter till en fjärde konferens! Nu är biljetterna till nästa års S4-konferens släppta! Den går av stapeln 4:e till 7:e mars. Det finns (minst) fyra skäl att vara snabb att handla sin biljett: Priset stiger ganska rejält efter hand, biljetterna brukar ta slut, rabatterade hotellrum tar slut, och, framför allt och dessutom nytt för i år, finns det begränsningar i hur många deltagare som får köpa biljett. Det senare är ett försök att få färre deltagare från leverantörer och konsulter. De sålde hälften av biljetterna under de första 36 timmarna! I övrigt verkar det vara samma starka upplägg som tidigare med fokus på framåtlutade och spännande föredrag. Jag har säkrat min biljett, ses vi där? Kan du lita på dina säkerhetsverktyg? Något som jag tycker många "säkerhetsmänniskor", både inom OT-säkerhet och andra områden, slarvar med är att de automatiskt litar på säkerhetsverktyg. Ett underbart exempel på detta är Flipper Zero, en liten Schweizisk Fällkniv som gör en lång rad attacker mot diverse trådlösa media väldigt enkla att utföra. Jag har en själv och den gör verkligen sitt jobb. Den har blivit väldigt populär och säljer i stora mängder, även om det varit lite incidenter i vissa länder där tullen och andra myndigheter stoppat leveranser. Att det kan finnas anledning att vara försiktig även med den här typen av utrustningar och dess tillhörande programvaror berättade Mikael Simovits på årets SEC-T konferens i mitten av september. En lång radda besvärande fakta gör att det finns skäl att vara väldigt försiktig med vad du använder din Flipper till... Vad förlorar man när det smäller? Ett resonemang som dykt upp ett par gånger på sistone i lite olika sammanhang är begreppet RPO, Recovery Point Objective. Ett begrepp man använder när man dimensionerar backupsystem och gör katastrofplanering. Enkelt uttryckt så handlar det om att definiera vilken punkt i tiden man vill komma tillbaka till när man återläser en backup. Det ska inte förväxlas med det som brukar kallas RTO, Recovery Time Objective, som är hur lång tid själva återställningen får ta. Det här är inget konstigt, det är begrepp som är vanliga i IT-världen och som är minst lika relevanta för OT-folk. Det jag nyligen reagerat över i några olika sammanhang är att man gör det väldigt enkelt för sig genom att nöja sig där och missar att det kan finnas fler saker att tänka på i OT-världen. Inom OT är vi förstås lika beroende av att få tillbaka informationen som behövs för verksamheten och att våra system är kompletta, där är ingen skillnad mot IT. Men information är inte allt, vi har i många fall något slags fysisk produkt eller process som kan behöva återställas. Här blir det betydligt svårare att ha ett enkelt resonemang och dessutom blir det förstås extremt beroende av vad man producerar. I vilket fall som helst så är det ju här som de riktigt stora kostnaderna uppstår i vissa branscher. I bästa fall blir det bara omarbete, men det kan ju också handla om att stora mängder produkter eller råvara behöver kasseras. Jag har även varit med om sammanhang där den fysiska processen är väldigt komplicerad att återställa om den avbryts vid fel tillfälle. Det kan vara ugnar som behöver rivas för att komma åt innehållet eller stelnad produkt som sätter igen rör och pumpar. Det här behöver man förstås ha koll på och dimensionera säkerhetsåtgärder på rätt sätt. Ibland är det inte bara viktigt att ha en bra RPO, man måste dessutom se till att ha samma RPO i flera system. Det kan handla om att system som utbyter information med varandra ska hamna i synk igen. ERP, MES, LIMS, PLC osv ska ha samma uppfattning om världen för att kunna arbeta tillsammans på det sätt som är tänkt. Manuell justering kan minst sagt vara mer eller mindre svårt... I IT-världen är det oftast svart eller vitt, antingen är systemet återställt och kan användas, eller så är det otillgängligt. Lite beroende på vilken typ av OT-verksamhet vi pratar om så kan det vara mer gråskala under återställningen. Man kanske kan köra vissa delar manuellt? Man kanske har flera linjer och kan köra med begränsad kapacitet? Det här påverkar våra resonemang och ger också möjligheter att bli kreativ med reservrutinerna. Samtidigt kan det finnas fällor, exempelvis behövs förstås mer resurser om flera linjer ska återställas samtidigt. När vi pratar om återställning i IT-världen är det ju oftast backupåterläsning det handlar om. När vi rör oss till OT-världen finns ju fler uppenbara risker som kan får mer fysiska konsekvenser och därmed kräver en helt annan typ av återställning. Orsaken kan ju vara både en "Cyberattack" men oftast är det helt andra källor som orsakar de flesta skador, inte minst bränder. Att återställa förstörd utrustning eller till och med byggnader kan förstås handla om helt andra tidsskalor är en backupåterläsning. Men inte desto mindre behöver man ju fortfarande bra rutiner för att, inte bara ta backup på prylarna, utan även lagra de där minneskorten eller vad man nu använder på en brandsäker plats... Backup kan betyda väldigt olika saker. Backup av databaser och filer är väldigt likt IT-världen och även återställningen blir lite liknande. I takt med att de flesta numera jobbar strukturerat med sina automationsprojekt har det blivit enklare att återställa PLC-programmering mm. Men att ta backup på konfiguration av annan utrustning och kanske kalibrering av sensorer verkar fortfarande "slira" i många verksamheter. Då får man en väldigt konstig variant av RPO, man får tillbaka ett äldre beteende på en nyare komponent! Tillgång till installationsmedia kan vara en variant på en udda RPO också, om man tvingas återställa till en annan version av mjukvaran i en komponent. Det här är något som många slarvar med och tvingas använda "fel" version av en mjukvara. Helt plötsligt backar man i tiden alternativt tvingas gå till en mycket nyare version vilket också kan påverka beteendet. Har man riktig otur har leverantören försvunnit från marknaden och då blir det väldigt klurigt att få tag på media. Åsså klassikern, gamla mediatyper... Kan du fortfarande installera från disketter, DAT-band eller något annat semi-antikt medium? En liten extra knorr kan vara att man ofta delar backupsystem mellan IT och OT. Det här är ett område där det är enkelt att göra bort sig... Du riskerar att kortsluta din fina nätverkssegmentering vilket är illa nog. Men du riskerar också att göra information tillgänglig på fel ställen, det kanske finns information i OT-världen som inte ska gå att komma åt hur som helst i IT-världen, eller vice versa. En duktig ransomware-aktör ser oftast till att slå ut backupsystemet innan man krypterar filer, så även om OT-systemen är välskyddade riskerar du att bli av med dina backuper i en IT-attack. På samma sätt kan en dåligt skyddad OT-miljö bli ett sätt att angripa IT-världen. Man kan även tänka sig lite mer avancerade attack-scenarier där man manipulerar data på delade system på IT-sidan för att den manipulerade datan ska återläsas på OT-sidan. Samma resonemang kan definitivt gälla om man delar virtualiseringsplattform eller serverlagring mellan IT och OT. När IT-driften är beroende av OT... Joe Weiss skriver en intressant artikel om incidenter i stora datacenters där diverse OT-utrustning påverkat driften av IT-utrustningarna. Ett viktigt område som inte får mycket uppmärksamhet! Som vanligt när Joe skriver är det intressant, relevant och utmanande! Hotmodellering i OT-världen Jag snubblade över ett litet papper från ett sydkoreanskt universitet där de tittar på hotmodellering med STRIDE och DREAD mot ett typiskt DCS-system i ett oljeraffinaderi. Intressant läsning! Hur ska man välja? Dale Peterson skrev nyligen en kort artikel om nyttan med att tvingas välja vilka säkerhetsåtgärder som faktiskt är viktigast. Jag såg en koppling, om än ganska långsökt, till mina egna tankar om nyttan med konvergerande riskarbete som kommer tvingas fram av NIS2. Öh? Va? Tänker du kanske? Det jag far efter är att NIS2 pekar så extremt tydligt på att ledningen i en organisation både ska godkänna alla säkerhetsåtgärder och sedan säkerställa att de får effekt. För att det ska vara möjligt kommer ledningen behöva ha ett samlat underlag med riskanalyser som belyser alla säkerhetsområden som konkurrerar om resurser, oavsett om det handlar om IT-säkerhet, OT-säkerhet eller något annat säkerhetsområde. Som en extra effekt tvingas man ju faktiskt göra om en riskanalys när åtgärder är vidtagna så att man kan visa att risken minskat! Det är ju något som de flesta organisationer inte kommer i närheten av att göra. Märks det att jag är positiv till NIS2? :-) Cybersäker IoT-utveckling - nu på engelska! På Elektronikmässan i Göteborg i våras deltog jag i en "expertpanel" som arrangerades i samband med att en handbok för cybersäker utveckling inom IoT lanserades. (Som jag gjort ett pyttelitet bidrag till.) Boken finns numera även på engelska och den är fortfarande gratis och du kan hämta den här! Det finns mycket tänkvärt i boken även om du inte tycker att du sysslar med "IoT" eller att du inte sysslar med produktutveckling. Det finns många referenser till OT-säkerhet och många resonemang kring IEC 62443 som är viktiga för alla! En speciellt bra sak som boken trycker på är att utmaningarna kopplat till livscykelhantering av utrustning som driftsatts och hur viktigt det är att se till att lösningar som man väljer/utformar har stöd för det. Det är definitivt relevant för både OT och generellt kring IoT! Ett "Hemma hos"-reportage! Nu tycker jag att tekniken ofta får alldeles för mycket fokus när man pratar OT-säkerhet, men teknik är ju samtidigt så himla kul, så nu får ni stå ut med lite teknikfrosseri. Min text om de senaste aktiviteterna i mitt hemma-labb väckte nämligen oväntat mycket intresse. För den som är nyfiken på detaljer eller vill bygga något eget i samma stil kommer här lite mer information kring prylar och mjukvaror... Strömförsörjning är viktigt! Den här typen av prylar går typiskt på 12, 24 eller 48 Volt likspänning så jag har nätaggregat för var och en av alla tre spänningarna. Här får man se upp så man inte skapar farliga situationer, eftersom den här typen av nätaggregat inte är avsedda för "hemmabruk" och därmed inte är kapslade och petskyddade på ett sätt som vi är vana vid för prylar i hemmamiljö! Ett extra petskydd och en snabb jordfelsbrytare hjälper till att ändå hålla säkerheten på en rimlig nivå. Bra skyddsjord (och funktionsjord) är också viktigt. Låt inte barn och husdjur komma i närheten oavsett! Ställningen har jag byggt av 20x20 aluminiumprofiler, den typen som exempelvis används för att bygga 3D-skrivare. Superstabilt, starkt och lätt! På ställningen sitter det sedan 4 stycken DIN-skenor som OT-utrustningen sedan i sin tur monteras på. Nästan alla prylar som passerar labbet har DIN-fästen vilket gör dem väldigt lätta att jobba med. Tänk på att ruggade utrustningar ofta är tunga på grund av kylflänsar och stabila kapslingar. Den utrustning som sitter monterad hos mig just nu väger totalt drygt 20 kg! Bygg stabilt! Mycket av utrustningen i labbet är min egen men en del är inlånat från leverantörer. Just när detta skrivs är det ovanligt mycket prylar monterade på en gång, vilket förstås är kul! Det du ser på bilderna är bland annat: Ett par PLCer (Phoenix Contact PLCnext 2152 respektive Siemens S7-1200) Båda två är riktigt lättjobbade och smarta lösningar med riktigt bra programmerings-verktyg! IPS och brandvägg för OT-protokoll (2 stycken TxOne EdgeIPS 102 och en TxOne EdgeFire med administrations-programvaran EdgeOne i en virtuell maskin) Riktiga favoriter! Smarta nätverksprylar (2 stycken Fortinet 112D Switchar och en Fortinet 60F brandvägg) Det är verkligen inte utan anledning att Fortinet säljer riktigt bra av sina OT-produkter, det här är vassa grejor! Några omanagerade switchar (2 stycken Moxa EDS 2500 ELP och en Phoenix Contact FL 1000) Enkelt, billigt och hållbart för snabba nätbyggen! Utrustning för fjärranslutningar (Ewon Flexy 205) En schweizisk armekniv för fjärranslutningar, datakonvertering och insamling av data. Kommer från belgiska företaget Ewon som är en del av svenska HMS Networks... En nätverksdiod (Data Diode Zero från svenska Link22) Förmodligen den absolut enklaste dioden som finns, men samtidigt allt som behövs för grundläggande enkelriktad trafik. En nätverks-tapp (Keysight Copper Tough Tap) Perfekt för att kunna analysera nätverkstrafik utan att störa den... En HMI-skärm (Phoenix Contact BWP 2070W) En enkel men ändå kraftfull HMI-terminal. Mjukvara för process-simulering (Factory I/O) Simulerar snygga fysiska processer i 3D med tillhörande virtuella remote IO att koppla en PLC till. Tänk på att det krävs ett hyfsat grafikkort för att få bästa kvaliteten på simuleringen. Nätaggregat för 12, 24 och 48 Volt. (Moxa, Siemens och Mean Well) Man behöver alltid ström! VMware Workstation på en dator för att köra virtuella system och virtuella nätverk. Bra att ha för både administrationsverktyg och hackerprogram. Kombinera med ett antal USB-anslutna ethernetadaptrar så att dina virtuella och fysiska nätverk kan kopplas ihop! Jag ska som noga påpeka att jag aldrig tar betalt av leverantörerna för att skriva om deras prylar, men jag har å andra sidan inget emot att göra lite gratisreklam för saker som jag själv gillar! Ett mycket stort tack till respektive leverantör för bra samarbete och för de saker som är donerade respektive utlånade. Möjligen är detta lite extremt för ett hemma-labb kan man tycka? Så här mycket grejor behöver man förstås inte för att komma igång med egna labbar. Exakt vad som passar beror på vad man vill göra. Men "mycket vill ha mer"... :-) På min jaktlista står just nu: Fler fabrikat av PLCer, både nyare och äldre. En ruggad server som orkar med ett antal virtuella maskiner och containers. På lite sikt tänker jag mig bli lite modern och kunna automatisera uppsättningen av labbmiljöer med hjälp av Ansible. Mycket handlar om att bygga smarta nätverk så tillgång till nätverks- och säkerhetsutrustning från fler fabrikat är viktigt! Ett gäng remote IO för att kunna köra fler OT-protokoll i näten. Utrustning för SDN, Software Defined Networking, som jag tror kan bli nästa stora grej inom OT. Även om Factory I/O är ett makalöst verktyg för att bygga en virtuell fabriksmiljö så kan det ibland vara bra med "riktiga prylar". Det är roligare att trycka på en "riktig" knapp och att se en "riktig" signallampa lysa. Någon gång ska jag också försöka få tag på en av modellerna som FischerTechnik tillverkar. Hör gärna av dig om du har funderingar, vill ha tips eller har idéer kring labbet! Som alltid tar jag tacksamt emot nya och gamla prylar/mjukvaror. AFRYs juniorer visar framfötterna! Här är tre resultat från några av de examensarbetare som jag jobbat med på AFRY under året. Riktigt bra rapporter som jag inte ska ge mig på att försöka sammanfatta utan låter er läsa själva! Är du själv på väg att göra någon form av examensarbete så kommer vi ganska snart börja annonsera nästa års upplägg. Du får förstås gärna höra av dig om du har funderingar redan nu! Niklas Andersson har tittat på hur skillnaderna mellan IT och OT påverkar införandet av NIS2. Zainab Anifowose tittade på hur användningen av MITRE ATT&CK skulle kunna stödja bilindustrin att implementera FN-kraven i R155. Mathilda Berg och Olivia Svensson gjorde en studie av cybersäkerhetstjänster i elkraftbranschen. Living on the edge... För den som tänker att en 4G-router inte är någon källa till oro kan behöva läsa senaste rapporten från Clarotys Team82. De har tittat på routrar, deras management-mjukvara och kommunikationen mellan dem. De presenterade också den här forskningen på årets S4-konferens: Snyggt jobbat! Leverantörerna av OT-utrustning blir allt duktigare på att bli tydliga kring hur man faktiskt använder deras produkter på ett säkert sätt. Annars har det varit lite för vanligt att det skryts om alla fina säkerhetsfunktioner i marknadsföringen, men att dessa funktioner sedan är obegripliga eller måste stängas av för att göra produkten användbar i verkligheten. Ett lysande exempel på hur man ska göra kommer från Phoenix Contact som tydligt beskriver vilka funktioner som krävs för att nå Security Level 1 eller 2 enligt IEC 62443-4-2. Snyggt jobbat och tack för att ni gör vårt jobb enklare! Mer säkerhetsfolk i styrelserna! Fokuset på cybersäkerhet och riskerna med olika typer av angrepp mot digitaliserade system går inte att ta miste på i alla sorters organisationer. Inte minst har frågan tydligt hamnat på ledningens bord och i styrelserummet! Men det riktiga genomslaget tror jag vi fortfarande inte har sett, det förväntar jag mig när NIS2 drar genom näringslivet och insikten om det brutala ansvar som läggs direkt på ledningen går upp för VD och ordförande. En intressant artikel från SecurityWeek beskriver varför en CISO är ett perfekt tillskott i styrelsen. Jag håller med även om jag tror att det är helt avgörande för producerande verksamheter att ta hjälp av säkerhetsledare med produktionskunskap. Alltså en OT-säkerhetschef eller en CISO med riktigt produktionserfarenhet. Design eller lärobok? Cisco publicerade tidigare i år ett ovanligt vettigt designdokument. Då menar jag inte att just Cisco brukar ha dåliga dokument (tvärt om skulle jag säga!), men att många leverantörers arkitekturbeskrivningar är så hårt skruvade mot de egna produkterna att de mest blir något slags tekniskt reklamdokument. Cisco har i det här fallet förvisso väldigt mycket information om sina produkter (Jag har definitivt inget ont att säga om dem!) men de bjuder på dessutom väldigt mycket mer. I vissa avsnitt blir det nästan läroboksnivå på texten. Exempelvis är diskussionen kring referensarkitekturer i kapitel 1 ovanligt vettig med många väl beskrivna usecases och man talar ur skägget kring skillnaderna mellan en nivå i Purdue-modellen och ett nätverk. I kapitel 2 finns en hel kloka tankar kring utmaningar att få pålitlig synlighet i passiva säkerhetsfunktioner. Kapitel 3 om segmentering är extremt Cisco-fokuserat men kan vara av intresse även om man inte är Cisco-kund. Fast i fastigheter? Om du sysslar med fastighetsautomation i någon form kan den nya rapporten "Trygg och säker informationshantering" från samarbetsorganisationen "Offentliga fastigheter" vara intressant. De tittar på Säkerhetsskydd, NIS och CER för att belysa vanliga utmaningar när dessa världar möts eller krockar med varandra. SÄPO uppdaterar! För dig som arbetar i verksamheter som berörs av säkerhetsskydd kan den uppdaterade vägledningen för Informationssäkerhet vara intressant. Nu återstår bara två av SÄPOs vägledningar att uppdatera. Precis som tidigare indikerar språket ett fokus på IT-system men det finns en del som är användbart även inom OT-världen, exempelvis kring bedömning av Riktighet/tillgänglighet, kontinuitet, särskilda säkerhetsskyddsbedömingar och förstås logisk kontra fysisk separation. Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.

Dags för en riktigt välfylld upplaga av nyhetsbrevet kring OT-säkerhet! Några höjdpunkter den här gången är en gratis bok som är riktigt bra, en modell för hur ransomware kan drabba PLC:er, vettig prioritering av sårbarheter, EU ger oss stöd kring supply chain, lite mer detaljer kring såväl CER-direktivet som CRA-förordningen, en ny version av NIST CSF, en djupdykning (!) i sjöfartens regelverk, en NATO-utbildning från MSB och så berättar jag vad jag hållit på med för roligheter i mitt labb! 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å 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! Alla pratar om Supply Chain! Om du inte levt under en sten de senaste åren har du märkt att fokuset på säkerhet i relationen med leverantörer har fått massor med fokus. Inte minst på grund av stora incidenter som NotPetya, Solarwinds och Coop/Visma/Kaseya. NIS2-direktivet trycker väldigt hårt på det här, likaså den nya versionen av NIST CSF. (Som du kan läsa mer om längre ner i nyhetsbrevet...) Ett bra stöd för att sortera sina tankar på området är en ny rapport från EUs cybersäkerhets-myndighet ENISA, "Good practices for supply chain cybersecurity". Förutom en introduktion till området och en analys av nuläget får vi en radda ganska handfasta förslag till åtgärder med tydliga mål för var och en av dem. Uppdaterat från IIC Industry IoT Consortium, IIC, har kommit med en uppdaterad version 2 av sitt dokument "Industry Internet of Things Security Framework", (IISF) som kom ut första gången 2016. Det här är ett dokument som det har refererats till i lite olika sammanhang, inte minst kring begreppet "Trustworthiness". Och just detta begrepp, Trustworthiness, är lite extra intressant när man ska försöka förstå vad det populära buzzordet (!?) "Convergence" egentligen betyder. IIC reder ut skillnader mellan IT och OT när det just gäller Trustworthiness och hur de två världarna kan mötas i den punkt som de kallar IIoT. De bygger begreppet Trustworthiness på de fem grundpelarna Security, Safety, Resilience, Privacy och Reliability. Tillsammans ska de motverka Attacks, Disturbances, Errors och Faults. Personligen är jag lite allergisk mot alla former av buzzord, inte minst "Convergence". Men jag måste säga att IIC åtminstone reder ut begreppets alla sidor på ett tydligt och bra sätt. De arrangerar begrepp som förtroende, assurans, krav och förmågor i kombination med berörda roller på ett sätt som känns väldigt användbart även om det i sig inte ger några magiska svar på svåra frågor. Det här är i alla delar ett ramverk och inget annat, dvs det är riktigt bra att hänga upp resonemang och planer på, och även om man inte får några svar på de svåra frågor man måste ställa sig själv så är det ändå stor hjälp. Rekommenderas! Klokskap från de sju haven Som jag skrev om i förra nyhetsbrevet så har jag på senare tid haft förmånen att vara insyltad i ett par projekt kring OT-säkerhet ombord på nybyggda fartyg. Det här är fantastiskt intressanta verksamheter med väldigt speciella utmaningar, inte minst när fartygen ska användas i mycket känsliga verksamheter. I den här världen har de så kallade klassningssällskapen mycket att säga till om, det är organisationer med välkända namn som Lloyd's Register, DNV och Bureau Veritas. Det här är verksamheter som i vissa fall funnits sedan tidigt 1800-tal och som sätter regler för hur man konstruerar, bygger och underhåller fartyg för att de ska vara säkra i alla betydelser av ordet "Säkerhet". På senare år har förstås cybersäkerhet och inte minst OT-säkerhet fått stort fokus. Ett godkännande från ett klassningssällskap innebär att fartyget får en så kallad Klassnotation inom ett visst område, exempelvis cybersäkerhet. För att få behålla fartygets notation sker regelbundna återkontroller av både tekniken och organisationens förmågor. Precis som vilken certifiering som helst! Som vanligt när OT-säkerhet är relevant baseras numera de flesta krav på en kombination av ISO 27001/27002 och IEC 62443. De klassningssällskap jag tittat på kombinerar på ett snyggt sätt krav på den tekniska utformningen med krav på organisationens arbetssätt och förmågor. Jag har personligen ett gott öga till DNV och deras kravmassa kopplat till OT-säkerhet på fartyg. Det är dokument som dessutom kan vara väldigt användbara även om man inte är i fartygsbranschen! Kravdokumenten från DNV är gratis att komma åt men en personlig inloggning krävs. Om man är intresserad av OT-säkerhet så är dokumenten DNV-CG-0325, DNV-RU-SHIP Pt.6 Ch.5 (Section 21) och DNV-RU-SHIP Pt.7 Ch.1 (Section 36) speciellt intressanta. Det finns också en recommended practice DNV-RP-0496 som är värd att titta på. Ett dokument som jag verkligen tycker alla borde ta en titt på har egentligen inte OT-säkerhet i fokus, utan dyker ner i utmaningarna kring hur man bygger bra styr- och övervakningssystem: DNV-RU-SHIP Pt.4 Ch.9. Läs exempelvis Section 2 om principer för utformning av dessa system! Väldigt många kloka principer för att bygga robusta lösningar i känsliga miljöer! Man får förstås ersätta begrepp och system som är unika för fartyg med motsvarande utmaningar i den egna miljön. Larm, safety och felhantering är otroligt viktigt att tänka på och det är ofta insikter i dessa områden som man saknar om man kommit över till OT-säkerhetsvärlden från IT-sidan. En annan sida av säkerhet till havs har sammanställts av ett Nederländskt universitet, NHL Stenden University of Applied Sciences. Det är en interaktiv karta med information om kända attacker mot fartyg, hamnar och annat sjöfartsrelaterat. Jag kan inte avgöra hur tillförlitlig eller komplett deras sammanställning är men det är en väldigt intressant illustration av ganska annorlunda utmaningar jämfört med "på land". Död mans PLC! Ransomware och andra liknande typer av utpressning är inget nytt inom IT-världen. Däremot har jag, och många med mig, undrat när vi ska börja se motsvarande angrepp mot OT-system. Idag drabbar de flesta OT-incidenter egentligen främst IT-system som "råkat" bli lite för viktiga för produktionen. Med undantag för Stuxnet, Triton och några få till, så är det extremt ovanligt med skadlig kod riktad direkt mot PLC:er och deras fysiska processer. Alla faktiska exempel jag känner till har handlat om sabotage i olika former snarare än utpressning. Det kan vara på väg att ändra sig snart... Richard Derbyshire, Benjamin Green, Charl van der Walt och David Hutchison har publicerat ett intressant papper med den lovande titeln "Dead Man’s PLC: Towards Viable Cyber Extortion for Operational Technology". Extremt sammanfattat så beskriver de en metod att hålla en verksamhet gisslan genom att utöka det klassiska ransomware-tänket med modifierad PLC-kod som upptäcker försök att kringgå attacken och då slår ut den fysiska processen på ett sätt som "förhoppningsvis" orsakar fysisk skada. Det har gjorts ett par liknande försök tidigare som de diskuterar och bygger vidare på. Namnet "Dead Man's PLC" associerar förstås till begreppet "Dödmansgrepp", men i det här fallet är det inte ett skydd utan en avtryckare! De tänker sig att angreppet börjar med en ingenjörsstation där man samlar information om nätverkets uppbyggnad, vilken programmerbar utrustning som finns där, deras programmering och hur de kan kommunicera med varandra. De beskriver en stegvis metod för att, baserat på den informationen, modifiera de aktiva programmen på ett sätt som kommer bevaka att ingen komponent återställs eller stoppas. Offret får en viss tid på sig att betala lösensumma innan samtliga komponenter slås ut och den fysiska processen aktiveras på ett så felaktigt sätt som möjligt. På det här sättet tar man inte en enstaka PLC gisslan utan samtliga i samma system. (Vilket är den stora skillnaden mot tidigare beskrivna metoder.) Ingenjörsstationen drabbas av något som liknar klassisk ransomware medan övrig utrustning enbart programmeras om utan att man behöver någon speciell access till systemen. Det är fortfarande en metod som kräver att man kan hantera och förstå de aktuella ingenjörs-verktygen men med lite vidareutveckling kan det säkert göras enklare. Jag rekommenderar att du läser hela pappret, det är bara 12 sidor text. Än så länge är det bara en teoretisk metod som beskrivs även om de genomfört "skarpa" attacker i testmiljöer. Det här känns som ett första steg mot en riktigt jobbig utveckling. Några spontana tankar kring kloka säkerhetsåtgärder för att möta det här är att satsa på en bra balans mellan förebyggande, upptäckande och återställande förmågor, exempelvis: Använd skyddet du redan betalt för! Moderna PLC-system har massor av enkla men bra skydd. Bra lösenord och kryptering hjälper mycket mot sånt här! Se till att du förstår dina system bättre än angriparen! Aktiv insamling av inventarie-information tillsammans med automatisk löpande riskanalys av nätverkets och komponenternas konfiguration ger dig möjlighet att ligga steget före. Angriparen behöver nätverksaccess till ingenjörsstationen eller den plats där den lagrar sina projekt. Skydda och härda ingenjörsstationen. Skaffa en riktig lösning för fjärråtkomst, dvs inte en vanlig VPN. Blanda inte lagring mellan IT och OT! Se till att du upptäcker förändringar i systemen, styr upp din ändringshantering och kombinera det med ett verktyg som övervakar nätverk och komponenter efter förändringar. Slarva inte med separationen av Safety-PLCer från övrig utrustning så behöver i alla fall inga farliga situationer uppstå. (Du är väl inte en av dem som bygger sådana funktioner i samma system som styr processen?) Backup, backup, backup! Precis som i IT-världen är bra (dvs testade och separerade) backuper helt avgörande för att få igång verksamheten när det värsta händer. På samma tema är det förmodligen en bra (men dyr) idé att också ha extra exemplar av all utrustning på hyllan i det fall angriparen lyckas helt "bricka" prylarna. NATO och civil beredskap MSB har släppt en webbutbildning kring NATO med fokus på civil beredskap. Jag tycker det var en riktigt bra sammanfattning av allmän information kring NATO och en väldigt nyttig insyn i den icke-militära sidan av NATO. Intressant att se hur mycket av tankarna kring allriskperspektiv för resiliens i samhället går hand-i-hand med EUs satsningar via exempelvis NIS2 och CER. Utbildningsmaterialet släpptes i mars så det saknar de senaste händelserna kring Sveriges medlemskap men det gör ingenting. Rapport från labbet! Jag är tekniker i själen! Men i min roll som rådgivare är det mer sällan som jag numera får nörda ner mig ordentligt i tekniken och få rejält med "skit under naglarna". Trots det är tekniken är något som jag är noga med att fortsätta mig hålla nära för att inte tappa kontakten med "verkligheten". Och dessutom för att det är roligt, inte minst programmering som jag tycker är en väldigt kul del! Det är väldigt lärorikt och dessutom roligt att prova nya kluriga säkerhetsupplägg som jag inte vågar/får/kan/vill göra i kunduppdrag - och i synnerhet att angripa dem förstås! En utmaning när man vill labba med sånt här är att OT handlar om fysiska processer, vilket förstås är både jobbigt och dyrt att bygga testmiljöer för. Då är verkligen det portugisiska företaget Real Games lösning Factory I/O en superelegant möjlighet! De har tagit en vanlig spelmotor för 3D, men istället för att fylla den med monster och vapen har man skapat en virtuell värld med komponenter och maskiner som man kan använda för att bygga ihop en tillverkande anläggning med enkel drag'n'drop. Alla sensorer och ställdon dyker sedan upp som ett remote I/O på nätverket som du kan ansluta till din PLC med MODBUS, OPC UA eller något annat protokoll som du vill ha. Riktigt smidigt och snyggt är att du sedan kan gå runt i anläggningen medan den kör. Du kan trycka på knappar på "riktigt" för att styra processen. Nyligen satte jag upp en ny labb-uppställning och drog igång några småprojekt för att kombinera teknik som jag inte blandat förut. Först ut blev en uppställning med en PLC (PLCnext 2152 från Phoenix Contact), ett par omanagerade switchar, ett par EdgeIPS 102 från TxOne och en virtuell tillverkningsprocess baserad på Factory I/O. Mitt super-simpla "experiment" gick helt enkelt ut på att utforska kombinationen PLCnext, OPC UA, EdgeIPS och FactoryIO: Koppla PLCn till ett virtuellt remote I/O i Factory I/O via OPC UA (Och det blev även motsvarande övning med Modbus TCP av bara farten) Programmera PLCn att köra processen Attackera kommunikationen för att störa processen, gärna med underhållande konsekvenser Skydda kommunikationen mellan PLCn och Factory I/O med en EdgeIPS Det är alltid roligt och lärorikt att "labba" lite. Ett återkommande intryck är hur kapabel och enkel modern teknik är! Som den där PLCn från Phoenix Contact. Den kan inte bara agera klassisk PLC och då programmeras enligt IEC 61131-3, utan även har stöd för alla möjliga moderna programmeringsspråk, nätverksprotokoll, Docker-containers och som har en egen "app-store". Vill du köra Node-RED, MQTT, Python eller något annat "modernt" så är det antingen installerat vid leverans eller enkelt (och gratis) att installera. Extra elegant är att deras programmerings-mjukvara, "PLCnext Engineer", är gratis. Om du inte har en fysisk PLC kan du istället skapa en virtuell PLC! (Om du är nyfiken så har Nisse Eriksson på Phoenix Contact skapat en radda bra lektioner kring PLCnext på YouTube.) Factory I/O har jag inte så mycket erfarenhet av ännu men det är en imponerade mjukvara med riktigt snygg simulering av både remote I/O och fysiska processer! Den fysiska processen blev i det här fallet en hisslösning, delvis baserad på ett av de scenarier som man får med i programvaran. Komponenter ska matas fram på tre rullband på tre våningar som sedan ska samlas upp fem åt gången i en plastback med hjälp av en hiss. När backen är full ska den skickas iväg på en lastpall och en ny back plockas in. På ytan kan man tycka att det är en ganska enkel process, men att få till programmeringen tog en stund! Men i slutänden blev det riktigt bra och jag passade på att lära mig att programmera med Structured Text i funktionsblock vilket jag inte gjort förut. Jag har däremot jobbat ganska länge med grejorna från TxOne, men slås fortfarande varje gång av hur smidiga de är. Smidiga både i betydelsen att de är enkla att arbeta med men också att de tar upp väldigt lite plats på skenan. En EdgeIPS styr enkelt upp nätverkstrafiken utan att man riskerar att påverka den i onödan. Medan processen sedan snurrar är det en barnlek att låta en EdgeIPS automatiskt lära sig trafiken på nätverket och föreslå brandväggsregler som kommer stoppa eller larma på annan trafik! Ja, och jag får väl säga att min lilla övning var framgångsrik... Det blev som vanligt tydligt att det kan behövas lite skydd för verksamheten! Mina angrepp mot den oskyddade hissen via OPC UA fick väldigt "fysiska" konsekvenser och resulterande i ett lätt kaos på "fabriksgolvet"... Vi får se vad nästa projekt blir i Factory IO? En av komponenterna i Factory IO är en vattentank som ska nivåregleras, så kanske att det blir att testa en PID-funktion? Men jag är nog mest sugen på ett lite mer komplext scenario där man kopplar ihop flera olika komponenter till ett långt produktionsflöde och kanske även styr med flera olika PLC:er. Jag ska också se om jag kan komplettera min labbuppställning med mer roliga prylar. En riktig HMI-webbpanel skulle vara kul för att bygga användargränssnitt på "riktigt" med Phoenix Contacts eleganta HTML5-baserade lösning. En mer sofistikerad nätverkslösning står också högt på önskelistan och förstås fler PLCer med tillhörande remote IO. En nätverkstapp eller två skulle vara praktiskt också. Det är kul med leksaker - men dyrt! Jag tar tacksamt emot stöd till nyhetsbrevets laboratorium om du tycker att nyhetsbrevet tillför någonting. Om du har avvecklad begagnad utrustning så är det väldigt intressant att få ta över, hör gärna av dig, mats@ot-sakerhet.se ! Säkerhetsmässigt finns det förstås mycket annat att utforska vidare. Nära till hands ligger angrepp mot HMI-kommunikation, labba med krypteringen i OPC UA, använda lite mer "udda" nätverksprotokoll än Profinet, OPC UA och Modbus TCP, men förstås också alla möjligheterna att låta TxOne styra vad som är tillåtet på nätet ner till en löjligt detaljerad nivå - typ: "PLC A får manövrera coil 1 men inte coil 2". Än så länge har jag bara använt enkla omanagerade switchar så där finns mycket kvar att utmana kring segmentering och fjärranslutningar. Man kan lära (och lära ut) så länge man lever! Apropå OPC UA Jag har tidigare berättat om Clarotys utmärkta artikelserie kring OPC UA. Nu är del 5 ute där de förklarar hur de forskar kring sårbarheter, generellt och hur de gjort kring just OPC UA. De avslutar med att gå igenom resultaten så här långt, ganska imponerande! I del 6 släpper de dessutom ett attackverktyg som är fritt fram att använda om man vill jaga nya sårbarbarheter eller granska sin egen installation. Det ser riktigt användbart ut! Kopplat till artiklarna finns också en text, "OPC UA Deep Dive: A Complete Guide to the OPC UA Attack Surface", som också är värd att titta på. De länkar också till en presentation på samma tema som Eran Jacob på OTORIO gjorde 2021, väl värd att läsa om man är nyfiken! En riktigt bra bok! ...och gratis! Vi är inte bortskämda med jättemånga bra böcker kring OT-säkerhet. Det finns några lysande stjärnor på den här bokhimlen som jag skrivit om i tidigare nyhetsbrev, men dagens boktips är lite annorlunda... Det kan vara en av de bästa - och den är gratis! Marina Krotofil är ett känt namn i våra kretsar. Hon är en av de där få men ack så viktiga personerna som verkligen förstår processautomation på riktigt och samtidigt förstår säkerhet. Om jag skulle manipulera en tillverkningsprocess så att ordentligt farliga situationer uppstår så skulle jag ta hjälp av henne... Här hittar ni inga dåligt förklädda IT-attacker utan ett resonemang som utgår från den fysiska processen. Hon kallar det ett Technical White Paper, men jag skulle personligen gärna betalat bra pengar för det här innehållet om det hade dykt i bokform! Du hittar det på hennes sajt och på GitHub. Vi får 133 sidor som är både välfyllda och välskrivna. Hon börjar med en genomgång av hur en ingenjör ser på kontrollsystem. En kort beskrivning av den exempelprocess hon använder är intressant på många sätt, framställning av vinylacetat av etylen och ättiksyra. Det här är en vanlig, välkänd och framför allt väldokumenterad kemisk process med en massa "spännande" möjligheter att skapa farliga situationer om kontrollen över processen blir angripen. Nästa kapitel är "Cyber-Physical Attack Lifecycle", den centrala delen i texten, där hon går igenom de steg som en angripare behöver ta i en systematisk attack. Igen med ett primärt fokus på tillverknings-processen snarare än system och infrastruktur. Naturligtvis finns även de delarna också med, men de är bara redskapen som angriparen kan använda för att uppnå de fysiska syften som man råkar vara ute efter. Därefter kommer ett kort avsnitt med hennes slutsatser. Om du inte orkar läsa hela dokumentet så tycker jag ändå att dessa två sidor är värda din uppmärksamhet! Som en bonus får vi några appendix. Jag rekommenderar speciellt appendix A där hon går igenom Donn Parkers Hexadmodell. (En utökning av den klassiska CIA-modellen. Ni som tagit en CISSP-certifiering har garanterat redan läst om den.) Här möts klassisk informationssäkerhet och information som används i kontrollsystem på ett sätt som är viktigt att förstå! Som du förstår rekommenderar jag varmt att du läser Marinas papper! Det är inte trivialt att ta till sig i alla delar men det ger en lång rad fantastiskt viktiga insikter! Styrelsen pratar om fel saker! En artikel i Harvard Business Review tar upp ett ämne som jag verkligen känner igen mig i och som jag håller med om; att styrelser tenderar att fokusera alldeles för mycket på förebyggande säkerhetsåtgärder istället för att bygga upp en robust och tålig organisation. Visst är det bra att säkerhet numera diskuteras på styrelsenivå, men det sänder fel signaler ut i organisationen! Samma tendens finns ju för övrigt på alla nivåer i många organisationer som jag stöter på, alltså att man lägger lite för stor andel resurser på förebyggande arbete och mindre på de förmågor som krävs för att upptäcka och hantera incidenter som trots allt inträffar. När styrelsen dessutom spär på detta genom att ha samma slagsida i sitt intresse blir saken än värre. Jag brukar använda den klassiska cirkeln från NIST CSF för att visa att vissa segment tenderar att få alldeles för lite intresse och resurser. "Protect" är populärast. I takt med att många OT-verksamheter skaffat IDS:er (Nozomi, Dragos etc) så skulle man kunna tro att "Detect" börjar växa till sig men tyvärr är det många verksamheter som i slutändan mest använder sin IDS för att försöka samla inventarieinformation (dvs Identify). Tyvärr är passiv inventering i praktiken inte så effektiv som tillverkarna hävdar. Vill du få bättre resultat krävs aktiv insamling. (Vilket inte är samma sak som IT-världens nätverksscanning!) Respond och Recover får oftast minst fokus trots att det är helt avgörande för organisationens robusthet. Ett nytt sätt att skära kakan! Framöver kommer jag få visa en annan bild från NIST CSF än den jag nämnde ovan. Som jag skrev om i nyhetsbrev #52 och nyhetsbrev #49 har NIST version 2.0 på gång av deras Cyber Security Framework, NIST CSF. Nu har de tuggat i sig all feedback de har fått och annonserat en formell draft av det nya ramverket. Vi har också fått en ny version av det välkända "hjulet" som förutom lite ändrade färgtoner, också har fått det nya sjätte området, "Govern". Vi har alla till den 4:e november på oss att komma med återkoppling - så börja läsa bums! Ett annat sätt att utforska det nya ramverket är via det nya verktyget "NIST Cybersecurity Framework (CSF) 2.0 Reference Tool" som också lanserats, om än i en ännu så länge begränsad version. Här kan du vända och vrida på ramverket samt ladda ner valda delar i ett antal olika format. De kommer lägga till mer funktionalitet efter hand. Mycket nöje! Vi kommer att ses... ...om du deltar på konferensen "SCADA-säkerhet" i Stockholm, den 19:e och 20:e september. Jag är där för att prata om vad som händer i skärningspunkten mellan OT-säkerhet och NIS2. Hugg mig gärna under dessa dagar och diskutera vad du vill! Det vore roligt att träffa dig och att få ansikten på några av mina läsare! Exklusivt och gratis! Vi på AFRY organiserar en nordisk konferens kring OT-säkerhet och kritisk infrastruktur den 27:e september. Tillsammans med några av våra partners erbjuder vi en exklusiv heldagskonferens i Solna, som trots att den är gratis kommer att vara väldigt "osäljig"! Skynda att anmäla dig, det kommer bli fulltecknat! Förutom att lyssna på klokskaper kring OT-säkerhet direkt från ledande personer inom olika industrigrenar kommer det bland annat bli: En trio före detta högt uppsatta militärer (Fredrik Robertsson, Yair Attar och Inge Kampenes), från tre olika länder, som alla tre numera arbetar i näringslivet. De kommer diskutera hur man håller sin verksamhet robust i en orolig omvärld. Välkände OT-säkerhetsprofilen Sinclair Koelemij besöker oss för att presentera kloka tankar om försvar i djupled. En panel där riktigt erfarna OT-säkerhetsmänniskor, Robert Valkama från Fortum, Björn Löfgren från Hitachi Energy och Gjert Tronstad från Elkem diskuterar utmaningar och möjligheter inom OT-säkerhet Johanna Parikka Altenstedt kommer hjälpa oss få rätsida på alla EU-krav som är på väg och hur de påverkar arbetet med OT-säkerheten. Adam O'Gorman och Oscar Gumaelius presenterar ett helhetstänk kallat "Secure Site" som tar ett helhetsgrepp kring säkerheten i alla sorters producerande verksamheter! Och en massa annat som är inte är officiellt ännu. Bland annat kommer våra partnerföretag skicka sina vassa tänkare för att dela med sig av sina insikter snarare än att visa trötta produktslides! Redan klar är Kevin Kumpf från Cyolo men det blir fler tunga namn! Jag kommer förstås vara där och ser fram emot många spännande möten och diskussioner. Du har förstås även chansen att träffa en massa av mina oerhört kloka och erfarna kollegor, inte bara inom OT-säkerhet utan även säkerhetsskydd, NIS2, penetrationstestning, produktsäkerhet, safety, säker utveckling och en massa andra områden! Välkommen till en riktigt rolig dag! Det är sannolikt ganska osannolikt! Det där med att risk skulle vara lika med sannolikhet gånger konsekvens, det är klurigt på många sätt... Dels är ju inte verkligheten så enkel att varje risk är en punkt i ett diagram. En annan stor utmaning som risk- och säkerhetsarbete kring all modern teknik måste stångas med, är att man ska skydda mot mänskliga angrepp. Mänskligt beteende är svårt att sätta en sannolikhet på och hur ska man då bedöma risker? Saker som går sönder av sig själva är det enklare att räkna på men hur sannolikt är ett visst mänskligt beteende? Ett område där detta är extra jobbigt är om man vill jobba med att åtgärda kända sårbarheter. Vilka sårbarheter är viktigast att fixa först? Rimligen de som får störst konsekvenser och som är mest sannolika att bli använda. Konsekvenserna är förhållandevis enkla att ta räkna på men hur bedömer vi sannolikheten att en sårbarhet får en exploit? Vi vet att kända sårbarheter bedöms enligt CVSS-systemet från FIRST. (Jag skrev om version 4 i Nyhetsbrev #50.) Vi vet också att CVSS är omdiskuterat och att modellen inte ger hela bilden av en sårbarhet. Ett annat, och nyare, initiativ från FIRST är EPSS, Exploit Prediction Scoring System. Det är viktigt att förstå att det här inte är ett alternativ till CVSS, utan är ett försök att bedöma sannolikheten för att en viss sårbarhet omvandlas till en exploit inom 30 dagar! Du får läsa FIRSTs utmärkta egna förklaring till detta för mer detaljer. EPSS är definitivt ingen exakt vetenskap men kan nog bli en väldigt viktig pusselbit i många verksamheter. Hur viktigt det kommer bli inom just OT-säkerhet är en diskussion i sig, som nog mer handlar om hur man ser på jakten på sårbarheter i OT-produkter. Jag har i alla fall sett att EPSS har börjat användas i allt fler IT-säkerhetsprodukter och vi kommer helt säkert se och höra mer kring detta framöver. Om det här är ett ämne som intresserar dig kan jag även verkligen rekommendera en serie dokument från Cyentia Institute och Cisco (före detta Kenna Security), där del 9 precis släpptes. Del 9 tittar på initiativet KEV, "Known Exploited Vulnerabilities" från amerikanska CISA. De tidigare dokumenten i serien verkar gå att hitta här numera. En del av de resultat som presenteras i del 1 var det som triggade aktiviteter som till slut ledde till att EPSS togs fram! Du kan också läsa Fortinets rapport "1H 2023 Global Threat Landscape Report" som tar upp en del intressant statistik kring EPSS, citat: Our analysis shows that the top most exploitable vulnerabilities, as identified by EPSS, are 327 times more likely to be attacked within a week than others on your radar. Det är inte självklart att motsvarande siffror för OT-området är lika imponerande, men på klassiskt Pareto-manér tycker jag personligen att man ska hitta enkla lösningar för 80% av sina utmaningar - så man kan lägga 80% av sina resurser på den svåra återstoden. Det här känns som en sådan lösning... Inspiration kring risker? Britterna kommer till din räddning om du har svårt att komma på "bra" risker i dina riskanalyser eller som händelser i dina krisövningar. Deras sprillans färska "National Risk Register" är den publika versionen av en nationell riskanalys. Du får en lång radda intressanta händelser, allt från cyberattacker, elaka drönare och djurpandemier till krig och vulkanutbrott. Om du vill ha en svensk version finns exempelvis MSBs riskkatalog som har ett lite annorlunda stuk och en del andra risker. Mycket nöje! USB-minnen är fortfarande en utmaning! Kaspersky annonserade nyligen en rapport kring en metod för angrepp mot system utan nätverksanslutning via USB-minnen. Intressant i sig men framför allt en påminnelse om att alla former av bärbara medier fortfarande är ett mycket relevant hot, speciellt om man använder luftgap som en säkerhetsåtgärd. För, som vi vet, det finns inga helt isolerade system! Se till att ha bra rutiner och någon form av saneringsverktyg för bärbara media. Lite nya detaljer kring CER-direktivet Europeiska Kommissionen har släppt en delegerad förordning med en något utförligare lista över vilka typer av verksamheter som ska inkluderas när EUs stater bedömer vad som är samhällsviktigt enligt CER-direktivet. Jag ser inga direkta överraskningar i den, men det är å andra sidan inte tänkt att vara en uttömmande lista, staterna kan själva lägga till vad de vill. Jag skrev senast om CER-direktivet i nyhetsbrev #52 om du vill läsa på lite. Är du mer orolig över NIS2 så kom ihåg att alla verksamheter som bedöms omfattas av CER-direktivet automatiskt också blir "Väsentliga verksamheter" enligt NIS2... För vissa branscher är det väldigt viktigt, kanske framför allt livsmedelsbranschen. ...och CRA-förordningen rullar vidare... Under sommaren publicerade Europeiska Rådet sitt förslag till kompromisser för den väldigt omdiskuterade CRA-förordningen tillsammans med en önskan om att dra igång förhandlingar baserat på förslaget. Sista ordet är långt ifrån sagt kring CRA och det ska bli spännande att se vad som händer härnäst. Alltid retar eller glädjer det någon? Microsoft är inte kända för att vara speciellt aktiva kring PLC-nära säkerhet, förutom när det är kopplat till deras Defender for IoT. På senare tid har de dykt upp i lite annorlunda sammanhang, nu senast när de tillsammans med CODESYS annonserade ett antal ganska allvarliga sårbarheter i CODESYS SDK. Extra allvarligt i och med att CODESYS finns till väldigt många tillverkares plattformar. Inom OT-säkerhet (precis som många andra säkerhetsområden) finns en massa "sanningar" och "självklarheter" som man fått lära sig att hålla med om. Som vanligt finns det sällan en enda sanning som alltid gäller och som man religiöst kan följa, även om det förstås oftast är väldigt bra tumregler att utgå ifrån! En lite extra känslig sanning att utmana är om/hur man kan/bör använda moln-teknik i OT-sammanhang. Jag snubblade över en artikel från förra året där Microsoft beskriver en högnivå-design, där den del av infrastrukturen som ibland beskrivs som "Nivå 3" enligt Purduemodellen byggs som en hybridlösning mellan on-site och Azure. Jag tycker att jag ser fler och fler organisationer som börjar utmana etablerade sanningar, men även stora samarbetsorganisationer (som OPAF, Open Process Automation Forum) som driver fram nya sätt att bygga automationssystem. Microsoft utvecklar också ett intressant opensource-verktyg för forensik i PLC:er. Än så länge med stöd för Siemens S7 och CODESYS version 3. Du får hjälp att analysera anropsgrafer mm. Riktigt användbart för den som vill kunna göra handgripliga analyser av PLC:er som misstänks vara manipulerade. Känner du dig mogen? IIC, Industry IoT Consortium och ISA, International Society of Automation har uppdaterat sitt gemensamma dokument "IoT Security Maturity Model: ISA/IEC 62443 Mappings for Asset Owners, Product Suppliers and System Integrators". Här möts IICs mognadsmodell SMM och de olika delarna av 62443-standarden genom att olika krav i standarden mappas mot de fyra mognadsnivåerna i SMM. Ett riktigt användbart dokument även om mappningstabellerna tyvärr blir onödigt svåra att läsa på grund av formatet de valt. (Som inte riktigt passar med de långa referenstexterna.) Vem är Mats? Jag är till vardags säkerhetsrådgivare kring OT på AFRY i Västerås. 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.