.png)
Den här gången längtar jag efter NIS2, tittar på MITRE Engenuity, kombinerar ISO 27001 med ISA 62443, läser på om Pålitlighet, granskar känsliga dataöverföringar med Python, tittar på NISTs CSF-profil för tillverkande industri, kommunicerar fältnära med OPC UA och tycker till om Purdue-modellens betydelse för hur vi bygger våra nätverk.
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. Med IT använder man teknik för att hantera information. Inom OT använder man liknande teknik men för "Operations", alltså att få fysiska saker under kontroll. Det kan exempelvis vara att styra maskiner i en fabrik, elproduktionen i ett kraftverk eller kemiska processer i ett raffinaderi. Inom IT är fokus ofta på att skydda hemligheter men inom OT blir det oftast viktigast att hålla en funktion tillgänglig och korrekt. Det innebär att säkerhetsarbetet kommer se väldigt annorlunda ut, vilket är anledningen till mina texter. 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 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 en egen LinkedIn grupp, i Facebook-gruppen Säkerhetsbubblan, 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!
Hur går det för NIS2?
Vi är många som är nyfikna på hur det kommer att gå med det förslag till helt nytt NIS-direktiv som lades fram i julas. (Jag har skrivit om detta tidigare i Nyhetsbrev #21 och #23.) "Snacket på stan" sade att någonting skulle komma ut under Juli men än så länge har i alla fall jag inte sett eller hört något konkret.
Det är inte helt trivialt att navigera EUs enorma informationsmängder och när man väl hittar ett intressant dokument är de sällan enkla att läsa heller... Ett intressant brev från Europakommissionen till Europaparlamentet och Europeiska rådet berättar att man fick in 121 åsikter kring förslaget.
Det senaste och viktigaste livstecknet som jag hittar är ett utkast till en sammanställning från Europaparlamentet på 59 sidor utgiven den femte maj med förslag till ändringar och tillägg. En snabb genomläsning gav inga revolutionerande intryck men ändå några intressanta, och i mitt tycke riktigt vettiga, förslag till ändringar:
Rapportering av säkerhetshändelser och hot som inte leder till en incident ska inte omfattas av rapporteringskravet. (Det hade blivit tufft att hantera den volymen...)
Man får 72 timmar (istället för 24) på sig att rapportera säkerhetshändelser. (Väldigt klokt!)
Man trycker på att det är lite för mycket fokus på krav och straff. Myndigheterna bör också ta en stöttande och uppmuntrande roll. (Wow!)
Man trycker på att det är viktigt att undvika överlappande tillsyn från flera myndigheter. (Av praktisk erfarenhet håller jag definitivt med!)
Root-servrarna i DNS undantas eftersom de sällan drivs av monetära syften. (Inte säker på att jag tycker detta är så smart...)
Man vill se lagligt stöd för mer samarbete mellan polis och förebyggande myndigheter. (Jaaaa!!!)
Det ursprungliga förslaget sa att ENISA skulle sätta upp en egen EU-motsvarighet till CVE-databasen för sårbarheter. Det tonas ner nu! (Otroligt vettigt!)
Den som väntar på något gott... Det kan komma mer nyheter vilken dag som helst nu och det kan förstås visa sig att det vi trott så här långt är helt fel. Än så länge har i alla fall inte jag sett något som tyder på att NIS2 är på väg att köra i diket eller drabbas av några större ändringar på rakan fram mot målet...
Vi håller tummarna! Vet du mer får du väldigt gärna höra av dig!
MITRE Engenuity levererar!
Vi har fått den första leveransen från MITRE Engenuity! MITRE är ju annars känt för ATT&CK-ramverken och har via Engenuity börjat samarbeta med leverantörer av säkerhetsprodukter för att utvärdera dem gentemot ramverken baserat på verkliga incidenter. Tanken är att ge potentiella kunder möjlighet att jämföra var de olika leverantörernas styrkor och svagheter ligger.
Det är definitivt ett intressant grepp. Ett antal leverantörer deltar i ett simulerat angrepp och hur väl deras produkter hanterar angreppet redovisas med hjälp av MITRE ATT&CK. Den här gången var testerna en kopia av TRITON-angreppen mot en Saudiskt petrokemisk anläggning 2017. (Det som var skrämmande med TRITON var att det siktade in sig på skydds-systemen, SIS, på anläggningen, vilket bara kan ha ett mål, nämligen att skada anläggningen och människorna där fysiskt.) Det är första gången man gör det här för OT-produkter med hjälp av MITRE ATT&CK for Industrial Control Systems. Fem deltagare fanns med; Claroty, Armis, Microsoft, Dragos och "the Institute for Information Industry". Den sistnämnda är en Taiwanesisk organisation som åtminstone jag aldrig hört talas om förut.
Om du är på väg att välja ett verktyg i den här vansinnigt viktiga kategorin är testresultaten definitivt en pusselbit i utvärderingen. Det är ju definitivt inte någon heltäckande test men det ger ändå hintar om hur respektive lösning beter sig.
På köpet kan man få lite mer insyn i nyttan med MITRE ATT&CK även om jag personligen kan tycka att man inte nådde ända fram när det gäller att underlätta jämförelser. Men där tycker man kanske olika? I vilket fall ska det bli spännande att se vad kommande tester resulterar i och om fler leverantörer hoppar på tåget!
Det kan inte hända - det har ju aldrig hänt förut!
Ett klassiskt mothugg som ofta dyker upp när man behöver resurser för säkerhetsarbete är argumentet "Är det verkligen vettigt? Det har ju aldrig hänt!". Samma sak när man är kreativ i en riskworkshop och kommer med händelser som lite utöver det vanliga...
Jag undrar om argumentet att det inte hänt förut börjar kännas lite tunnare nu? Vi har kommit halvvägs genom 2021 och har redan sett ett antal riktigt smaskiga händelser som aldrig hänt förut. En av de största svenska livsmedelskedjorna stod still. Amerikanska östkusten hade inte tillräckligt med olje-produkter. Viktiga system i Irländska sjukvården stod still i över en månad. Minst ett stort försäkringsbolag har slutat ersätta ransomware-utbetalningar. Inget av detta har hänt förut!
Som vanligt är problemet att man inte kan bedöma sannolikheten för saker som inte hänt förut. Budskapet att man för riktigt allvarliga händelser bara behöver bedöma om det KAN hända kan du ta del av i Richard Clarkes keynote från S4x17 där har sätter fingret på problemet med ett antal fantastiska poänger!
Tre godbitar från Industrial Internet Consortium
Vännerna på IIC verkade vilja jobba klart innan det blev semester. De producerade nämligen tre intressanta texter på kort tid...
Godbit nummer ett!
Det mest intressanta i mina ögon är ett white-paper med titeln "The Industrial Internet of Things Trustworthiness Framework Foundations". Det handlar alltså om "Trustworthiness", vilket i det här sammanhanget jag föredrar att översätta med "Pålitlighet". Det är en rejäl genomgång av begreppet som de definierar så här:
Riktigt intressant för oss OT-människor! De hänger upp resonemanget på just Safety, Security, Privacy, Reliability och Resilience. (Jag låter bli att översätta dessa begrepp eftersom det oundvikligen förändrar betydelsen av orden.) De tar oss genom ett långt men tydligt resonemang där de definierar värdefulla principer kring synsätt, värderingar, ledarskap, metoder och arbetssätt på vägen. Ibland blir det kanske lite väl akademiskt men det finns gott om guldklimpar att ta till vara för den egna organisationen!
Godbit nummer två!
Nästa godbit heter "Global Industry Standards for Industrial IoT" som dels gör en rejäl genomgång av hur standarder skapas och hur de bäst används för IIoT och OT. Men de ger oss också en lång lista över relevanta organisationer som sysslar med standarder på det här området där vi bland annat hittar välkända namn som DIN, IEC, IEEE, IETF, ISA, ISO och OPC Foundation. Vi får också en lista över intressanta samarbetsorganisationer där kända namn som NAMUR, IIC, PI4.0 och ZVEI blandas med för mig okända grupper.
...och nummer tre!
IIC annonserade också "IIC Patterns Initiative" som är en öppen databas med arkitektur-principer för IIoT och OT. Den innehåller bara ett fåtal än så länge men tanken är att vem som helst får dela med sig av sin bästa idé. Om det tar skruv kan det här bli riktigt intressant, inte minst på grund av att det är en öppen resurs!
Plus en bonus!
Dessutom kom en utgåva av "The Industrial Internet Consortium's Journal of Innovation" som fokuserade på Edge. De finns många åsikter om vart relationen mellan OT och "molnet" är på väg men oavsett vad man tycker så är det intressant!
27001 + 62443 = 89444?
En av mina ständiga käpphästar när jag är ute och föreläser om OT-säkerhet är att man inte ska välja fel standard till sitt ledningssystem. ISO 27001 är defacto-standarden för informationssäkerhet och ISA 62443 är motsvarigheten för OT-säkerhet. Försök INTE använda dem för något annat! Jag har sett tråkiga exempel på när välmenande människor, i synnerhet de som älskar 27001, försöker vränga till tolkningen av 27001 på ett sätt som ska passa OT-världen. Det blir inte bra!
Men! Det finns ingenting som hindrar att man kombinerar de båda. Tvärt om är det bra. Integrerade ledningssystem är ju ingenting nytt, många organisationer kombinerar utan problem standarder som ISO 9001, ISO 14001, ISO 45001 och ISO 20000. Att lägga till ISO 27001 och ISA 62443 bör inte vara något jätteproblem för de flesta. Och man behöver ju inte certifiera sin organisation bara för att man lutar sig mot standarder.
Men vad ska man tänka på då? Den frågan försöker ISA svara på nu med ett sprillans nytt översiktsdokument. Riktigt bra kan jag tycka även om det är lite tunt och inte går in på detaljer. Men de pekar på en radda intressanta saker och det är en bra början!
En utmaning som ISA inte tar upp är att vi inte är så många ännu som kan båda standarderna. Även om man inte behöver vara expert så vill det ju till att man har tillräcklig koll för att knyta ihop dem. I takt med att intresset för 62443 nu ökar kommer det nog lösa sig automatiskt...
Att röra sig mellan domäner...
Jag har nyligen haft möjlighet att sätta fingrarna på en ZoneGuard från svenska Advenica och tänkte passa på att skriva några rader om den för att dela med mig av mina intryck.
Jag skrev om en kusin till ZoneGuard i Nyhetsbrev #22, nätverksdioden DD1000i, som är en nätverksbrygga där man använder fysikens lagar för att säkerställa att information bara kan skickas åt ett håll. Dioder används exempelvis för att föra ut loggar från säkra nät utan att riskera att nätverkskopplingen används "åt andra hållet".
En ZoneGuard är också tänkt att koppla samman nätverk som har skilda säkerhetskrav utan att de påverkar varandra. Till skillnad från dioden kan man med en ZoneGuard skicka information åt båda håll, istället tittar man på informationen som överförs och ser till att de protokoll som används inte kan missbrukas. Lite som en brandvägg men med väldigt mycket mer kontroll över vad som är okej. Man brukar prata om CDS, "Cross Domain Solution", alltså att man kommunicerar mellan säkerhetsdomäner.
En "vanlig" brandvägg inspekterar trafiken och skickar den vidare utan ändring. I en ZoneGuard bryter man sönder protokollet helt, plockar ut informationen som ska överföras och kastar sedan nätverkspaketen. Sedan applicerar man regler och filter på själva innehållet och bygger sedan ihop helt nya nätverkspaket. Angrepp som utnyttjar felformatterade nätverkspaket har alltså inte en chans! ZoneGuard har stöd för en rad protokoll och format. Det finns också väldigt bra stöd för organisationens egna utvecklare att anpassa stödet till de egna kraven. Det här är en väldigt spännande produkt för OT-verksamheter eftersom integrationen mellan IT och OT är helt avgörande för både organisationens effektivitet och dess säkerhet!
Nätverksmässigt är det enkelt men smart utformat. En nätverksanslutning till respektive nätverk (Röd och Blå i bilden), en separat anslutning för administration (Grön) och en för loggning (Svart). Du behöver alltså inte blanda data, administration och loggning på samma nätverk vilket kan vara avgörande för vissa verksamheter.
Om man tittar på vad som händer under huven tycker jag den här bilden förklarar hur det hänger ihop. Jag använder RDP, "Remote Desktop Protocol", som exempel i resonemanget. Ett klientsystem ansluter från vänster i bilden till "Data 1". Kommunikationen transformeras i en service där innehållet plockas ut och läggs i en datastruktur, i vårt fall är det händelser i RDP, dvs tangentbordstryckningar, musförflyttningar och liknande. Datastrukturen skickas vidare till validering via en jämförelse mot ett schema där det säkerställs att alla strukturer och datatyper är korrekta. Ska det exempelvis vara en siffra så kollas det. Ska det vara en bitmap så kollas det.
Det är i validerings-steget i mitten av bilden som den verkliga magin händer! Där definierar vi vår policy för vad som är ok att göra via RDP. Om informationen godkänns (eventuellt efter att ha modifierats) så kollas resultatet igen mot ett schema och lämnas över till en service som bygger ihop RDP-trafik och skickar den vidare till RDP-servern. All trafik som går åt andra hållet kollas på motsvarande sätt. Och så håller det på! I och med att bara innehållet i trafiken hanteras blir det väldigt osannolikt att någon av de riktigt allvarliga säkerhetshål som funnits i RDP går att utnyttja och man får dessutom möjlighet att styra exakt vad som går att göra på skärmen!
Nät det gäller policy-filtren har Advenica gjort ett verkligt genidrag! De filter som implementerar policyn är nämligen Python-script! All information som ska granskas är tillgänglig i ett enkelt API. Du kan bygga precis vilken logik du vill! Det är här som den stora skillnaden mot klassiska brandväggar blir tydlig! Lite mer komplext att sätta upp förstås men oerhört kraftfullt!
I vårt RDP-exempel vill vi kanske inte tillåta att man rör muspekaren var som helst på skärmen, inte tillåta vilka tangenttryckningar som helst eller maskera delar av bilden? Kanske bara titta utan att påverka? Skriv bara regler för de händelser du vill ändra, godkänna eller ta bort!
Förutom RDP finns stöd för Syslog, NTP, FTP, SFTP, NFS, SMB, SMTP, POP3, HTTP, HTTPS, SOAP och MySQL. Dessutom finns ett generellt stöd för TCP och UDP som gör att du kan skapa egna tjänster. ZoneGuard finns också som mjukvaruprodukt också om du hellre kör en virtuell lösning.
Det här är ett riktigt snyggt sätt att styra upp känslig kommunikation som jag personligen tycker fler verksamheter skulle överväga. Som vanligt när det gäller Advenica är dokumentationen riktigt bra och ger riktigt bra stöd kring både uppsättning, drift, säkerhetsrutiner och utveckling av policies och services. Om man inte ska göra någonting allt för komplext är man relativt snabbt igång även om policy-delen förstås kräver lite mer arbete jämfört med en brandvägg eller en nätverksdiod.
Hur ska vi skära OT-kakan?
Ett område som debatteras flitigt är relationen mellan Purdue-modellen (ISA 95) och hur man bygger nätverk. Och hur rimmar det med tankarna i ISA 62443?
Jag inbillar mig inte att jag har något facit men här är mina spontana tankar kring detta: (och säg gärna emot mig!)
Den ursprungliga Purdue-modellen (och ISA 95) skapades inte för att underlätta för vare sig nätverksbyggare eller säkerhetsfolk. Det är ett sätt att organisera system i en komplex verksamhet så att det går att förstå strukturen och hålla liv i verksamheten.
I och med att vi nu i många år byggt våra system baserat på Purdue och ISA 95 så har det trots allt varit ganska naturligt att nätverk och annan kommunikation följer nivåerna i modellen. I och med att krav på skydd och tillgänglighet dessutom också ofta följer nivåerna blir det snyggt.
ISA 62443 bryr sig inte om nivåerna från ISA 95 och Purdue men den säger å andra sidan inte direkt att det är fel heller. I 62443 bygger man sin kommunikation baserat på "Zones" och "Conduits" som i sin tur bygger på systemens faktiska kommunikationsbehov, utsatthet och säkerhetskrav. Dessa Zones och Conduits kan både återspeglas fysiskt i nätverksstrukturen eller genom andra, logiska, strukturer.
I och med digitaliseringen, och i synnerhet mer extrema tankar som "Industri 4.0", har det blivit tydligt att en rent lagerbaserad kommunikation som inspirerats av Purdue-modellen inte fungerar längre. Det gamla traditionella tänket att hoppa mellan intillliggande nivåer dödar effektivt alla möjligheter till molnbaserade lösningar men skapar också en tröghet som motverkar många potentiella framsteg.
För att nå idealen i Industri 4.0 utan att bryta mot tankarna i ISA 62443 har det uppstått riktigt eleganta arkitektur-ramverk. Där använder man enbart "Zones" och "Conduits" men man gör det på det sätt som var tänkt i 62443 utan att färgas av traditioner från Purdue. Min personliga favorit på området är NOA, "Namur Open Architecture" som du kan läsa mer om i Nyhetsbrev #27 och #30.
I slutändan handlar det precis som vanligt om riskanalyser och bedömningar. Bedömningarna ska förstås inte bara handla om säkerhet utan också hur den nätverksstruktur vi skapar går att underhålla och byta ut över tid.
Att skära kakan med OPC UA...
Peter Lutz och ISA ger oss en riktigt intressant artikel kring planerna framåt för fältnära kommunikation med OPC UA. Det här är ganska långt från att vara min personliga specialitet men det är väldigt intressant att se hur våra möjligheter att framöver kunna "styra upp" kommunikation kommer att påverkas. Det finns ju en tydlig koppling till den föregående artikeln om Purdue och Zones&Conduit när man ser att den inre strukturen i pyramiden suddas ut. Tankarna far dessutom mot "Zero Trust" eftersom varje enhet kommer få ta ett större ansvar i att försvara sig själv när man börjar prata med fler enheter istället för med enstaka centrala punkter. Som Peter också tar upp blir en väldigt intressant koppling till nyare underliggande tekniker som 5G, TSN och APL.
Som en naturlig konsekvens av att de enhetliga kommunikationsvägarna suddas ut förstärks ytterligare behovet av att ha riktigt bra insyn i vad som händer på nätverket. Egentligen är väl redan analyslösningar i stil med Guardian från Nozomi nödvändiga men i den här framtida världen kommer man inte ha en chans utan dem. Det här kommer nog också ytterligare öka intresset för processnära skydd i stil med TxOnes EdgeIPS för att skapa fältnära utrustning som kan försvara sig själv.
Lite mer från NIST
Det här är sjätte delen i min serie om standarder och ramverk. Första avsnittet i nyhetsbrev #26 handlade om ISA/IEC 62443 och i nyhetsbrev #27 tittar jag på NAMUR NOA. I nyhetsbrev #28 var NIST CSF, NIST 800-53 och NIST 800-82 huvudattraktionen men du fick också lite mer om NOA som en bonus. I nyhetsbrev #29 tittade jag på den nya versionen av CIS Controls och i nyhetsbrev #30 . Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig!
När jag skrev om NIST-dokumenten missade jag ju att nämna ett dokument som är intressant för oss OT-människor! Jag tänker på "Cybersecurity Framework Manufacturing Profile" som är ett exempel på det NIST CSF kallar "profiler", dvs en anpassning av CSF till en viss bransch eller verksamhet. I det här fallet är det tillverkande industri även om det går att återanvända för andra besläktade branscher.
Det man gjort är helt enkelt att man valt ut de viktigaste åtgärderna i CSF för tillverkande industrier och kombinerat dem med en riskmodell i tre steg (Low/Medium/High) för att sedan beskriva vad som behöver göras i respektive kombination av dessa.
Som exempel kan vi ta denna ganska korthuggna punkt om loggning i CSF-dokumentet:
...som i Manufacturing Profile istället ser ut så här:
Som synes får vi mer hjälp direkt i tabellen. Man har också städat upp referenserna till att bara peka på de två relevanta delarna i 62443 och dessutom mer detaljer kring var i NIST SP 800-53 man ska titta vidare.
Det här är förstås inte svaret på alla frågor och det är inte säkert att du kan använda allting rakt av i din egen verksamhet men det är en riktigt bra startpunkt om du vill arbeta med NIST. Dokumentet uppdaterades senast 2019 så det är fortfarande någorlunda relevant.
Tips om event och mer läsning!
Den 26:e Augusti går årets Xday av stapeln. Jag är en av talarna under rubriken "Stå stadigt med säker OT". Exakt vad jag kommer prata om får ni höra om ni är med! Skynda att anmäla dig!
Den 28 September är jag med på årets upplaga av CyberNorth under rubriken "Den mänskliga sidan av OT-säkerhet". CyberNorth organiseras av Luleå Tekniska Universitet och beskrivs så här: "Cyber North — ett i särklass informativt event för säker hantering av risk. Fokuset på CyberNorth adresserar de utmaningar som finns kopplat till digitalisering inom processindustrin och särskilt kopplat till Cyber/informationssäkerhet." Glöm inte anmäla dig!
En detaljerad genomgång av de potentiella säkerhetsriskerna med privata 4G/5G-nät för industriella miljöer gjord av Trend Micro och Institute of Information Industry. De tittar inte bara på själva näten utan hur den typen av angrepp skulle kunna användas i typiska OT-sammanhang med en lång radda attackscenarier.
En utmärkt påminnelse från Brian Krebs kring nyttan av att kolla att man har tid att läsa tillbaka sina backuper. Hans vinkel är att många organisationer betalar för ransomware-nycklar just för att de plötsligt inser att det kommer ta flera år att läsa tillbaka en fullständig backup. Den vinkeln har inte så mycket att göra med OT direkt men tanken att faktiskt kolla att man har backuper och att de verkligen går att läsa tillbaka är VÄLDIGT relevant för de flesta OT-miljöer! https://krebsonsecurity.com/2021/07/dont-wanna-pay-ransom-gangs-test-your-backups/
Intressant analys av sårbarheter i både PLCer och molntjänster baserade på CODESYS från Clarotys nyligen omdöpta forskningsgrupp Team82. De visar hur de kan ta över en PLC från WAGO via den tillhörande molntjänsten men också omvänt kan ta över molntjänsten via en sårbarhet i PLCn. Det här är viktiga frågor som många med ambitioner åt "Industri 4.0"-hållet kommer ställas inför. Men det är ett problem även annars eftersom väldigt många OT-produkter baseras på CODESYS. https://www.claroty.com/2021/07/21/blog-research-exploiting-vulnerabilities-in-the-ot-cloud-era/
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.