2 jan.

Nyhetsbrev OT-Säkerhet #58

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.