Nyhetsbrev OT-Säkerhet #69
- 30 apr.
- 17 min läsning
Dags för en ny utgåva av nyhetsbrevet kring OT-säkerhet! Den här gången förbereder vi oss på Ransomware i OT-miljöer, tittar på MSBs nya ”OT-Säkerhetskollen”, imponeras av NSA som kompletterar IEC 62443, räknar om CVSS för OT-system, funderar på begreppet ”hygien”, läser om AI i kritisk infrastruktur, får massor av klokskap från Nederländerna, läser gratis-standarder, funderar över leverantörskedjor och letar spöken i fastighetsautomation.
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!
Har du koll?
MSB släppte nyligen årets version av Cybersäkerhetskollen som numera även innehåller OT-Säkerhetskollen! Min spontana reaktion var att det var väldigt snabbt marscherat eftersom det här var en av sakerna som vår nya nationella cybersäkerhetsstrategi sa skulle produceras fram till 2027. Snyggt jobbat!
Jag är försiktigt positiv till hur OT-Säkerhetskollen är utformad, även om jag alltid har lite svårt för listor som indirekt insinuerar att mer säkerhetsåtgärder självklart är bättre - oavsett riskexponering, oavsett kostnad och oavsett om åtgärderna har meningsfull effekt. Men vi ska komma ihåg att syftet med materialet är att skapa en bild i stort av hur det står till i landet och det tror jag det kan passa väldigt bra för.
Det ska bli väldigt intressant att se resultatet och jag kommer nyfiket fråga runt bland de som fyller i den hur de uppfattar OT-delen.
Du får väldigt gärna höra av dig med dina tankar till mig: mats@ot-sakerhet.se !
För dig som är utvecklare av OT-komponenter!
Två organisationer som är nära kopplade till ISA, ISAGCA (ISA Global Cybersecurity Alliance) och ISASecure har tagit fram ett dokument där man mappar ISAs kravstandard för mjukvaru-utvecklingsprocesser ISA/IEC 62443-4-1 mot USAs Secure Software Development Framework från NIST SP 800-218.
ISA-standarden är ju helt OT-fokuserad medan SSDF är helt generell så det kan vara en användbar jämförelse.
Personligen tycker jag mig se att trenden mot att tillverkare av komponenter och mjukvaror för OT-kunder allt mer satsar på att certifiera sina processer mot ISA/IEC 62443-4-1 och ofta gör motsvarande arbete för själva produkterna - fast då mot ISA/IEC 62443-4-2. I takt med att intresset för leverantörernas del i den totala säkerhetsbilden, exempelvis kopplat till NIS2, så är detta en klok och viktig väg framåt.
Det där med hygien?
Ett begrepp som jag alltid haft lite svårt för är "Cyberhygien". Jag har inte riktigt kunnat förklara varför jag inte gillade det, men jag tyckte definitivt att det användes väldigt slentrianmässigt och det hintade om en lista med säkerhetsåtgärder som magiskt passar för alla. Dessutom ofta använt med en underton av att det egentligen är ganska enkelt; "om alla bara skötte sin cyberhygien så skulle vi inte ha några cyberproblem". I IT-världen kopplas det gärna ihop med att allt ont som händer beror på användare som är så korkade att de klickar på länkar. Att dålig hygien kan leda till virusinfektioner är förvisso en lite rolig lek med orden!
Jag vägrar hålla med om att användares sunda förnuft ska vara vårt viktigaste försvar mot allvarliga tråkigheter eller att samma nivå på hygien ska vara rimliga för alla. Säg åt en HR-person att man inte får öppna bilagor som skickats till dem med mejl... Eller att Bengts Mekaniska AB ska ha samma krav på cyberhygien som kontrollsrumspersonalen på kärnkraftverket i Ringhals...
Nu har jag till slut förstått vad jag störde mig mest på med cyberhygien-begreppet! Det som skaver är att man alltid verkar betrakta hygien som förmågan att helt undvika att drabbas av angrepp, men sedan helt glömmer bort förmågan att reagera när något udda ändå är på väg att hända. Det är när man bedriver säkerhetsarbete på det sättet som säkerhetsåtgärderna blir onödigt störande för verksamheten. Det leder ofelbart till att medarbetarna betraktar säkerhetsfolket som besvärliga och gör sitt bästa för att kringgå säkerhetsåtgärderna för att "kunna jobba".
Jag menar inte alls att kloka medarbetare eller cyberhygien är dåligt. Hygien i vardagen är viktigt - men det ska vara rätt hygien på rätt plats. Det ställs olika krav på hur jag tvättar händerna och hur en sjuksköterska gör det! Åtgärder som är anpassade efter riskerna kommer respekteras! En patient som löper större risk att drabbas av infektioner kan vi övervaka noggrannare och ta prover oftare! Dessutom vet vi också att även sjuksköterskor blir förkylda, så det finns inga garantier trots hygienen - trots handtvätten gäller det att vara vaksam på symptom och reagera snabbt när de kommer!
På samma sätt måste riskhanteringen skilja mellan olika delar av en verksamhet och oftast mellan IT och OT. Den som håller på med förberedelser inför NIS2 just nu har förhoppningsvis gjort begreppet "proportionalitet" till sin bästa vän - just för att kunna fokusera "hygienen" där den är som viktigast! Med den här tolkningen av hygienbegreppet så tycker jag personligen det blir mycket mer användbart och rimligt!
AI + Kritisk infrastruktur = ?
ISA och Automation.com har tagit fram ett tydligt material som tittar på hur AI (främst generativ AI men även Machine Learning) kan användas inom kritisk samhällsinfrastruktur. Det är skrivet med ett USA-perspektiv och med extra fokus på energi-branschen, men resonemanget går att överföra till andra länder och till andra branscher. Sammanfattningen säger ganska väntat att AI-lösningar inte kan användas i sammanhang där deterministiska lösningar är nödvändiga:
Andrew Bochman har publicerat en artikel med hans tankar kring innehållet och lite hintar om vad INL pysslar med i sammanhanget.
Kan CVSS användas inom OT?
Du är förmodligen bekant med CVSS, The Common Vulnerability Scoring System, som används för att definiera hur allvarlig en sårbarhet är på en skala mellan 0 och 10. Det är förstås en extrem förenkling att beskriva en sårbarhet enbart med en siffra, men samtidigt vill man ju i alla fall att siffran är så meningsfull som möjligt. Roger Hill beskriver i en artikel ett sätt att få CVSS-poäng att passa bättre i OT-världen genom att räkna om dem och ta hjälp av de delar som redan finns tillgängliga i CVSS-definitionen. Väl värt att tänka på för den som jobbar med att prioritera sårbarheter.
NSA tänker till om PLC:er på ett riktigt intressant sätt!
NSA i USA har publicerat en teknisk rapport med titeln: "Smart Controller Security within National Security Systems" som var oväntat intressant! De har gjort en analys som utgår från kraven i NIST SP 800-53 Rev. 5 och mappade dem mot kraven i IEC 62443-4-2. Man utgick från de lagkrav som gäller för system med nationell säkerhetspåverkan i USA och mappade dem mot nivå SL-3.
De komponenter man har haft i åtanke är "Smart Controllers", vilket man definierat som PLC:er och andra controllers som har "avancerade" förmågor. Det kan vara mer beräkningskraft för realtidsanalys, utökade kommunikationsmöjligheter och dataanalysförmågor, "Edge computing", direkt i den enskilda controllern.
Det man kom fram till var att 74 krav från 800-53 var relevanta i det här sammanhanget, men det intressanta var att man hittade 13 som inte togs omhand i 62442-4-2! Som lösning har man helt enkelt föreslagit nya krav. (1 st CR och 5 st RE) Resultatet kommer användas för deras test-processer men har också skickats till ISA för att tas omhand i kommande uppdateringar av standarden.
Som du kan se i tabellen var det en rad säkerhetsåtgärder, från helt olika områden, som man identifierade. Kul och seriöst sätt att utveckla standarden! Tack NSA!
Om jag förstått det rätt är förresten det här definitionen av ett National Security Systems (NSS):
Där får man ändå ge USA lite cred för att man tagit ett bra grepp kring OT-säkerheten i lite mer "utmanande" systemlösningar, inte minst de som är inbyggda i vapensystem. Jag vet av egen erfarenhet att regelverk inom militär verksamhet annars tenderar att fastna lite vid att skyddet av känslig information är det enda viktiga i världen...
Alltid redo?
Lesley Carhart har skrivit ett utmärkt whitepaper kring hur man förbereder sig inför Ransomware i sin OT-miljö som är publicerat via SANS. Man kan definitivt häva att det finns andra typer av attacker som enklare kan få riktigt allvarliga konsekvenser, men ska man fokusera på vad som är mest troligt i de flesta verksamheter så är det utan tvivel ransomware. Det kanske inte är avsett att drabba OT-verksamheten i sig men det brukar lätt bli produktionspåverkan även om det "är IT som egentligen drabbats".
Är man förberedd för just ransomware så kommer man på köpet att ligga mycket bättre till även när andra typer av incidenter inträffar, även om de inte orsakats av någon illvillig hacker!
Sista ordet kring CIA-triaden i OT-världen!
Den person som jag refererar allra oftast till i nyhetsbrevet är Sinclair Koelemij, som trots sin pensionering (eller kanske tack vare?) fortsätter producera artiklar som jag ofta önskar att jag skrivit själv. Den här gången sätter han punkt för diskussionen kring varför Confidentiality/Integrity/Availability passar dåligt i OT-världen och varför Controllability/Observability/Operability är en mycket listigare trojka av ord.
Det hade räckt där, men sedan följer han upp med ytterligare en artikel med ett riktigt klokt ifrågasättande av hur vi definierar begreppet "OT"!
Själv brukar jag ibland roa mig med att försöka provocera folk lite genom att säga att "IT är systemen som stöttar verksamheten, men OT är verksamheten". Sinclair tar den tanken och vrider den ett varv till genom att flytta fokuset för vad OT är, från system och komponenter till den fysiska processen - där den förstås hör hemma. Han argumenterar för sin syn med en radda positiva effekter som detta synsätt ger oss i vårt sätt att arbeta med risk.
Och när han redan var igång så fick vi dessutom en artikel med kloka insikter kring hur CRA-förordningen påverkar automationsbranschen. Exempelvis pekar han på de kluriga gränsdragningar som systemintegratörer kommer behöva hantera. Spännande!
Jag kan bara säga "Läs!". Och tack till Sinclair!
Läs EUs standarder gratis!
En viktig del när EU skapar så kallade "Harmoniserade standarder" är att de ska vara tillgängliga gratis. Hur man gör det beror lite på vilket land man befinner sig i, men man kan alltid hitta rätt via https://harmonized.standards.eu/ . Är du i Sverige så kommer du till slut hamna hos SIS där du kan registrera dig och komma åt CEN- och CENELEC-standarder.
De här standarderna kommer bli allt viktigare framöver. Närmast framöver kommer du höra om dem allt oftare i samband med det uppdaterade Radiodirektivet och sedan även CRA-förordningen.
Dags att se över EUs sätt att arbeta med cybersäkerhet?
EU-kommissionen efterlyser nu dina åsikter kring hur man kan utveckla arbetet med cybersäkerhet inom EU. Det handlar om CSA, "Cyber Security Act" som ligger till grund för bland annat ENISA, EUs cybersäkerhetsmyndighet, men också allt arbete som pågår med bland annat certifieringskrav.
Man verkar tänka stort och öppet vilket syns i att man formellt överväger fyra radikalt olika vägval:
Har du en åsikt om detta så är det dags att säga ifrån nu!
Bli min kollega!
Jag behöver en rådgivarkollega! ...eller två! ...eller tre! Nu bygger vi på Sectra vidare på Sveriges starkaste OT-SOC med bred kompetens och fler tjänster kring OT-säkerhet!
Uppdatering till sjöss!
IMO, som är FNs organisation för sjöfart är på väg att släppa en uppdaterad version av sina rekommendationer kring cybersäkerhet.
Den enes kund är den andres leverantörskedja
En gammal fråga, inte minst inom OT-världen, är hur vi ska se på säkerheten hos våra leverantörer. Den har blivit extra mycket i fokus på senare tid tack vare NIS2-direktivet och CRA-förordningen. När det gäller NIS2 så handlar ju den i grunden om att samhället nu ställer krav på "cyber-resiliens" i samhällets egna leverantörskedjor; den som levererar något som samhället är beroende av behöver se till att både egen cybersäkerhet och underleverantörernas cybersäkerhet möjliggör stabila leveranser även under säkerhetsincidenter.
Det har dykt upp ett antal tjänster på marknaden som hjälper organisationer att följa upp cybersäkerheten hos deras leverantörer. I alla de exempel som jag har tittat på handlar det om att leverantören får självskatta sina förmågor utifrån ett antal frågor; "Har ni en säkerhetspolicy?", "Använder ni MFA för remote access?" och så vidare. Jag tycker det i grunden är positivt att dessa tjänster dyker upp eftersom det kommer sätta ljus på den oerhört svåra fråga som leverantörsuppföljning faktiskt är, i synnerhet när det handlar om säkerhetsfrågor! Däremot är jag skeptisk till att dessa tjänster verkligen ger en sann bild av den samlade riskprofilen för ett företag - men det är en diskussion för en annan dag...
En insikt jag fått i dessa diskussioner är att nästan alla missar sin egen roll i samhällets leverantörskedjor - det blir väldigt mycket fokus på att jaga underleverantörerna, men mycket mindre på att bedöma vilka risker den egna organisationen orsakar för kunderna och samhället! Detta blir dessutom rörigt när NIS2 kommer på tal eftersom många verkar missförstå hur kraven därifrån "drabbar" organisationer och underleverantörer...
När man börjar fundera över detta blir det snabbt tydligt hur snabbt det blir väldigt komplext när man tittar på leverantörskedjor. Jag ritade den här bilden för att försöka göra det lite begripligt. Det blev det nog inte... (Om du lätt får ont i huvudet så kanske du ska sluta läsa här...)
Orange pilar symboliserar leverans av någonting från en leverantör till en kund och en leverans är alltid kontraktsmässigt kravställd, vilket visas som gröna pilar. Lila pilar är samhällets NIS2-krav på leverantörer. Samhället är ju en lite speciell kund som kan ta många skepnader men jag ritar den som en stor kund för enkelhetens skull.
Det man snabbt inser är att om leveransen flödar i de orangea pilarnas riktning så flödar kundens krav på leveranserna åt andra hållet, enligt de gröna pilarna. Man inser också att NIS2-krav och leveranskrav kan vara (och ska vara) helt olika saker.
I min modell har jag fyra olika exempel på leverantörer. I verkligheten är det förstås oerhört mycket mer komplicerat, men det här får räcka för mitt resonemang. Det blir nog stökigt ändå! A och B omfattas av NIS2, medan C och D inte gör det. En viktig insikt som man ser direkt är att en organisation kommer få krav från flera olika håll samtidigt beroende på vilka kunder den har. Det är rimligt att anta att dessa krav ställs på olika sätt och med olika nivå så arbetet att se till att man kan leva upp till allihop kan bli utmanande...
Det är just den här rörigheten och utmaningen kring varifrån kraven kommer som jag vill försöka reda ut här. Jag hör tyvärr fortfarande ofta resonemang i stil med:
"Vi omfattas av NIS2 och som leverantör till oss så måste ni också uppfylla NIS2"
Om du frågar mig är det ett riktigt dåligt sätt att ställa krav på sin leverantör. Det leder inte till att kunden uppfyller sina egna åtaganden kring leveranstörskedjan enligt NIS2!
Hur träffas då de fyra typ-organisationerna av kraven?
Organisation "A"
A omfattas själv av NIS2 och kommer därför träffas av krav "direkt från samhället", de lila pilarna i bilden. Här gäller det att ta till sig tänkesättet i NIS2 - att förstå vilka risker man utsätter både sig själv för, men också samhället, så att man kan ta hand om riskerna på ett "proportionerligt" sätt. Fokus ska vara på att kunna producera även om man utsätts för attacker eller drabbas av andra typer av incidenter!
A kommer också få krav på sig som en del av respektive leveranskontrakt, de gröna pilarna. En utmaning blir då att kombinera dem med NIS2-kraven. En komplikation för vissa organisationer är om de är verksamma i flera NIS2-sektorer och kommer då träffas av föreskrifter från flera olika tillsynsmyndigheter. Det är ännu oklart hur mycket möda myndigheterna kommer lägga på att synka sina krav med varandra.
Om A dessutom själv är kund till B eller C så behöver man ställa rätt krav på dem utifrån sin egen verksamhet och sin egen samhällspåverkan. Se mer nedan.
Organisation "B"
B är väldigt lik A med skillnaden att B även drabbas av krav från A. De kraven utgår ingår i As arbete med att själv uppfylla NIS2-kraven.
Här är det viktigt att inse det är inget som säger att kraven som A ställer på B ska vara samma som ställs på A från NIS2! De kan vara hårdare eller snällare. Man kan mycket väl tänka sig att B är extremt viktig för att A ska kunna producera och då kan det vara rimligt att ställa högre krav i sina kontrakt med dem än vad NIS2 kräver!
Organisation "C"
C har förvisso leveranser till samhället, men tillhör inte en sektor som omfattas av NIS2. Det innebär att eventuella säkerhetskrav i leveranserna direkt till samhället kan bli lite vad som helst, men man kan ju misstänka att kraven efter hand börjar likna dem som "drivs fram " av NIS2.
C levererar också till NIS2-organisationen A enligt pilen 6. Även här måste A ställa rätt krav utifrån sin faktiska verksamhet, istället för att blint peka på NIS2.
Organisation "D"
D liknar mycket C. De kan dessutom beröras av att A, på grund av NIS2, ställer krav på att C i sin tur måste ställa relevanta krav på sina egna leverantörer. Beroende på hur duktig C är på riskanalys och kravställning kan det bli mer eller mindre bra för alla inblandade...
Ja, som synes blir det snabbt komplicerat och det kan vara mycket att hålla rätt på. Några grundläggande tips kan man sammanfatta till:
Oavsett om du eller din leverantör omfattas av NIS2 så bör ni alltid ta fram era egna krav utifrån era egna risker. En viktig del är sedan att säkerställa att de kraven dessutom hjälper er uppfylla alla krav ni själva får på er utifrån.
Omfattas ni av NIS2 så handlar kraven därifrån främst om att förstå risker som uppstår runt er produktionsförmåga och att ni ska fokusera på att hantera de viktigaste riskerna. Har ni fysisk produktion så lär OT-säkerhet hamna väldigt högt upp på prio-listan!
Ta gärna hjälp av kommersiella verktyg för att följa upp hur era leverantörer uppfyller säkerhetskraven, men glöm inte att nivån på kraven måste komma från er. Det är stor skillnad på kravet "Ni ska ha ett snöre!" och "Ni ska ha ett snöre som är 60cm långt!"
Om ni omfattas av NIS2 så kan det vara klokt att se er själva som en del av "Samhälls-rutan". Är man viktig för samhället så är man på ett tydligare sätt en del av samhället och inte något som står lite vid sidan av!
Något som inte tas upp här är det omvända behoven, alltså ert beroende av samhället. Det är viktigt att ha med i sina riskanalyser - vad händer om andra funktioner i samhället börjar knaka i fogarna? Här kan det skapas nya gröna pilar till era leverantörer!
Koll på väderstrecken?
En kort artikel från DarkReading illustrerar det viktiga med att inte bara övervaka trafiken in och ut från våra känsliga nätverk, utan även det som rör sig inom nätet, ofta kallat "Öst-Västlig trafik". Det är något som dessutom ofta är utmanande att få till på ett bra sätt i typiska OT-nät. De är ofta utspridda fysiskt och tekniken sätter begränsningar kring vilken trafik som går att få insyn i utan stora extrakostnader.
Det är därför det är så viktigt att bygga sin infrastruktur med försvar i åtanke redan från start. Det som SANS kallar "defensible architecture" i sin "SANS Five ICS Cybersecurity Critical Controls". På samma sätt är det sällan möjligt att komma åt all trafik men om man vet vilka blinda fläckar man har så går det mycket bättre att hantera det i praktiken.
Vill du inte åka till Orlando?
I mitten av juni går årets SANS ICS Security Summit av stapeln i Orlando. Om du vill slippa Musse Pigg så kan man ta del av många delar av programmet på distans. Mycket nöje!
Det kan ju förstås vara en slump...
För ett par år sedan fick jag ett konsultuppdrag som gick ut på att titta på hur produktleverantörer i den svenska OT-världen hanterade annonseringen av sårbarheter i deras produkter och hur rättningar lyftes upp offentligt. Jag slogs då av att vissa väldigt välkända svenska produktleverantörer i aldrig någonsin hade haft några sårbarheter i sina produkter! De hade fina webbsidor där man skröt om processerna för hanteringen, men där sårbarheterna skulle listas var det tomt...
Nu noterade jag i förra veckan att samma leverantörer plötsligt börjat "drabbas" av en massa sårbarheter under det senaste året! Märkligt... Kan det vara så att de tagit de kommande kraven i CRA på allvar redan nu och faktiskt inte mörkar sina sårbarheter längre?
Oavsett vad som ligger bakom så är det en positiv utveckling! Bra där!
Vill du också göra rätt?
Kanske vill du också hantera sårbarheter rätt? Vill du också ha koll på allt annat som CRA-förordningen kräver av dig som är leverantör av digitala produkter? Då är den gratisutbildning i CRA som The Linux Foundation och OpenSSF (Open Source Security Foundation) tagit fram ett förnämligt första steg! En bra introduktion på ungefär en timme och en med liten certifiering på slutet om man vill!
Spöken i husets automation?
Fastighetsautomation är en spännande del av OT-världen, men vad händer om man blandar in polisens forensiska utredningar i mixen? I en artikel publicerad i "Forensic Science International: Digital Investigation" har Johnny Bengtsson från Polismyndighetens Nationellt Forensiskt Centrum tillsammans med Linköpings Universitet tittat närmare på den frågan. Rubriken är "The ghost in the building: Non-invasive spoofing and covert attacks on automated buildings".
NIS2 i Finland!
Den 8:e april implementerades NIS2 i Finland vilket är lite extra intressant även för oss i Sverige. Alla texter, inklusive lagen, är ju tillgänglig på svenska.
Jag måste säga att jag gillar deras sätt att annonsera lagstiftningen och även sättet de skriver lagtexter. Det ska bli intressant att titta närmare på och så småningom jämföra med det svenska lagförslaget.
Vi får se hur det går...
Om du sysslar med cybersäkerhet i någon form så har du knappast missat allt ståhej på senare tid kring den USA-finansierade CVE-databasen vars framtid är oklar. Oavsett hur det går med detta och egentligen också oavsett vad man tycker om sårbarhetshantering i den här formen, och kanske i synnerhet CVSS-poäng, så blir det intressant att se hur detta landar. EUs eget initiativ framstår som mycket rimligare idag än vad jag personligen kanske tyckte för något år sedan.
Otmar Lendl på Österrikes nationella CERT, cert.at, skrev en tankeväckande artikel där han jämför utmaningarna med CVE med DNS-systemet som vi alla använder dagligen för att hitta IP-adresser. Artikeln är på tyska men det fixar din browser!
En smygtitt i brevlådan...
Fedex kom förbi med en låda roliga grejor till låns från Profitap. Att kunna lyssna på nätverkstrafik är populärt i OT-världen. Det är ett vanligt grepp för att kunna leta efter angrepp eller andra händelser som man vill ha koll på.
En par vanliga myter är att passivt lyssnande på trafik inte kan ställa till några driftproblem och att nätverksswitchar lätt kan hantera mirror/SPAN-portar utan problem. Så enkel är ju tyvärr inte verkligheten och ett sätt att minska vissa av dessa risker är att använda specialiserad hårdvara för att "kopiera" nätverkstrafik, vanligen kallade "Tappar". De är dessutom helt ovärderliga för lite mer avancerad felsökning i nät som drabbas av "magiska" fel!
Att Profitap är proffs just på tappar framgår ju faktiskt av namnet... Från vänster till höger på bilden är det en C1D-1G, en Profishark 1G och en C8P-X2. Jag återkommer med en närmare titt på dessa när jag hunnit utsätta dem för en del intressanta utmaningar...
Fler videos från S4 - missa inte!
Glöm inte att S4-konferensen fortsätter att lägga ut inspelningar från årets tillställning i spellistan "S4x25 Tampa" på YouTube. En rad intressanta presentationer finns att gotta sig åt, exempelvis när Andrew Ohrt berättar om CIE, Cyber Informed Engineering och kommer in på fantastiska begrepp i stil med "Cyber-enabled failure mode":
MITRE EMB3D i ny version!
MITRE har släppt version 2.0 av hot-ramverket MITRE EMB3D. Oerhört användbart om du pysslar med modellering av hot mot alla former av inbyggda system.
Vad kan vi vänta oss för vägledning kring CRA?
Sarah Fluchs delar med sig av sina insikter kring vad vi kan vänta oss när det kommer till ytterligare vägledning kring CRA. Vi är många som är angelägna att veta mer om vad som gäller i praktiken. Sarah ställer helt rätt frågor och nu väntar vi på att Kommissionen levererar svaren.
Waterfalls årsrapport är här!
Jag är inte så förtjust i alla årsrapporter från snart sagt varenda produktleverantör i säkerhetsbranschen. Det tenderar att blir en jakt på motivation att köpa just deras produkter...
Jag ska inte säga att Waterfall helt låter bli det men deras rapporter tenderar att vara mer balanserade än de flesta. Jag låter dig läsa deras slutsatser direkt i deras senaste årsrapport
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.
