.png)
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.