top of page
Sök
2 juni 2021

Nyhetsbrev OT-Säkerhet #28 - NIST, Nozomi Guardian och LOGIIC

Den här gången funderar jag på vad folk menar när de "jobbar enligt NIST", imponeras av Guardian från Nozomi Networks, tittar på olje&gas-branschens syn på sårbarheter i safetysystem, funderar över vad en OT-incident egentligen är och rotar vidare i NOA från NAMUR. Åsså en massa annat spännande förstås!

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. Jag skrev nyligen ett inlägg på Atea-bloggen som förklarar mer.


Jag vill ge er ett stort tack för alla trevliga mejl jag får med frågor, förslag och uppmuntrande ord. 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.karlsson-landre@atea.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. Framöver kommer också vissa artiklar från nyhetsbreven publiceras på Ateas officiella blogg tillsammans med en del annat som jag skriver där.

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!

 

Långa men tomma rör...

Jag har fått flera frågor om varför jag inte gett mig in i diskussionerna kring attacken mot Colonials pipeline i östra USA. Det är ju definitivt en intressant händelse, det är väl förmodligen den IT-attack som fått störst påverkan på civilbefolkningen i något land, någonsin. Möjligen undantaget händelserna kring Ukrainas elnät.


Mitt svar är helt enkelt att jag inte ser någon mening med att tidigt klämma ur mig en massa listiga åsikter baserat på rykten och halvdan media-rapportering. Inte minst ur ett OT-perspektiv återstår det ju verkligen att se vad som egentligen hände och vad som gjorde att produktionen stoppades. Jag vet av erfarenhet att det oftast finns väldigt många bottnar i den här typen av händelser och väntar gärna med att dra mina slutsatser till röken har lagt sig ordentligt...

En sak som diskuterats flitigt är om det var en OT-incident eller inte med tanke på att den fysiska driften stoppades av företaget själva. Personligen tror jag att de flesta som diskuterar den frågan inte har förstått hur en sådan här pipeline fungerar. Det är lätt att tro att det är ett långt rör där man dag efter dag stoppar in samma typ av olja i ena änden och får ut den igen på en annan plats. I praktiken pumpar pipeline-företaget alla möjliga petroleumprodukter åt en lång rad olika kunder och man byter fram och tillbaka relativt ofta. Det är inte heller alltid att det är samma företag som stoppar in produkten som också plockar ut den, utan försäljning sker via pipelinen. I Colonials fall så förlorade de sina system för all hantering av köp- och sälj-beställningar, vilket förstås gör det helt meningslöst att köra en pipeline!

Ett begrepp som används slarvigt i lite olika sammanhang är "IT - OT Convergence" i betydelsen att IT och OT växer ihop. Personligen brukar jag undvika att använda det eftersom det är så luddigt men i Colonial-incidenten kan man ju faktiskt säga att attacken riktade sig just mot deras "IT - OT Convergence". Och då menar jag det affärsmässiga beroendet mellan IT och OT, inte något slags integration nödvändigtvis. Attacken slog ut deras möjlighet att bedriva fysisk verksamhet men utan att attackera de fysiska systemen.

Här tror jag IT-säkerhetsarbetet kan ta lite inspiration från OT-världen och fokusera lite mer på Tålighet. Alltså att se till att verksamheten går att köra i något slags "nödläge" även om man förlorat sin normala effektivitet. Självklart ska vi göra allt för att stoppa attacker men någonstans går gränsen för när mer skydd mot attacker blir för dyrt eller störande och man får skydda sin verksamhet på andra sätt. Jag kan inte bedöma hur lätt det hade varit för Colonial att ha nödrutiner för att hålla igång produktionen men det hade varit ett fantastiskt sätt att köpa sig lugn och ro för att hantera den egentliga attacken.


Det här är en händelse som kommer få många och intressanta konsekvenser framöver! Just pipelines är dessutom ett extra klurigt område säkerhetsmässigt så oavsett vad som hände kommer det finnas mycket att lära.

 

Det går bra nu!

Intresset kring OT-säkerhet och industriella system växer jättesnabbt. Vi behöver fler kompisar som vill arbeta med det här fantastiskt spännande området och våra roliga kunder! Du måste inte vara specialiserad på just OT-säkerhet men något slags kombination av de här kompetenserna är bra:

  • Säkerhet - Du kanske har en bakgrund inom informationssäkerhet, OT-Säkerhet, IT-säkerhet, fysiskt skydd eller riskhantering?

  • Industri - Du kan prata med "industrifolk", både med automationsteknikern och med produktionschefen. Du ser inte ut som ett frågetecken när de pratar om MES-system, PLCer eller SCADA. Du har upplevt hur en sådan verksamhet fungerar i verkligheten.

  • IT-Arkitektur - Du har en bred förståelse av IT-teknik och hur IT-drift fungerar i praktiken! Du kan prata om Windows, Linux, nätverk, certifikat, brandväggar och virusskydd även om du inte är specialist på något av det.

Mina kunder finns i hela landet så det spelar egentligen mindre roll var du bor, även om det förstås vore extra kul med en kollega på Västerås-kontoret


Är det här du? Eller känner du den perfekta personen? Tipsa! Hör av dig!

 

En väktare från Nozomi!

Något som nästan alla verksamheter med OT-system har gemensamt är att de inte kan jobba löpande med uppdateringar, patchning och aktiva skydd i sina system. Oavsett om det är leverantörerna som håller emot på grund av garantier eller verksamheten själv för att man inte vågar göra förändringar i viktiga processer så hamnar man i ett läge där man behöver fokusera på andra säkerhetsåtgärder än de som man kanske är van vid från IT-världen.


Om man ska välja ett ställe att börja på så skulle jag absolut rekommendera att skaffa riktigt bra insyn i vad man har för komponenter i sina system och vad de pysslar med. Oavsett vilken standard för säkerhetsarbete du tittar på, CIS Controls, ISO 27000, ISA 62443 eller NIST så pekar man på att bra koll sina prylar är en förutsättning för allt annat säkerhetsarbete. När man sedan har den insynen är steget inte långt att löpande använda den kollen man fått i nätverket för att aktivt leta efter händelser som är värda att stoppa eller kolla upp.

In på scenen kommer då Guardian från Nozomi Networks! Det här är en av de mycket få lösningar på marknaden som första stund byggts för att passa OT-världens behov. Att den sedan råkar bli riktigt intressant även för IT-miljöer är en välkommen bonus! Guardian matas med nätverkstrafik som man kopierat från sina OT-nätverk. Trafiken analyseras och presenteras förstås men framför allt letar den löpande efter oväntade förändringar i hur enheterna på nätverket pratar och efter uppenbart skadlig trafik.


I mitt OT-labb har jag just nu den minsta modellen av Guardian, "NSG-R 50". Det är en ruggad variant utan fläktar som ändå tål jobbiga temperaturer tack vare feta kylflänsar, den monteras på DIN-skena och matas med 12 - 36 V DC. En reläutgång för matningsfel hintar om ett seriöst OT-ursprung.


Som synes har den fyra ingångar för att ta emot trafik. Den trafiken kan komma från SPAN/Mirror-portar i nätverksswitchar eller från tappar/aggregatorer likt dem från Keysight som jag tittade på i förra nyhetsbrevet. Management-porten ansluter man till sitt nätverk och det är den vägen man arbetar i detta imponerande verktyg.

Hur är det att arbeta i då? Och vad kan man göra? Ja, det första man slås av är att det verkligen är ett OT-verktyg på riktigt! Det är inte bara att det förstår vad MODBUS eller en PLC är utan man får tillgång till massor av information som är annars är väldigt klurigt att få sammanställt i en blandad miljö. Ett bra exempel är att man till och med får insyn i vad som hänt ner på enskilda register, taggar och variabler. (Se bilden här nedan)

Något man alltid hör från de som implementerat den här typen av verktyg är att "automationsfolket" blir helt exalterade över den kontroll de får på sina prylar. De kan helt plötsligt se kluriga händelseförlopp och felsöka på helt nya sätt. Jag har själv hört exempel på en test-implementation av ett annat verktyg där säkerhetsfolket som testade verktyget inte fick ta bort det efteråt för automationsingenjörerna som absolut ville ha kvar det! Det här är definitivt inte bara ett säkerhetsverktyg utan det bidrar också med riktigt starka funktioner för de som sysslar med drift, underhåll och utveckling.

Det är ytterst sällan (i min egen erfarenhet) som man har en renodlad OT-miljö med bara utrustning från en enda tillverkare och där prylarna dessutom är av samma tekniska generation. Personligen tycker jag att det är fantastiskt att få en sådan överblick av en "rörig" miljö samtidigt som man kan dyka ner i vilka detaljer som helst! Det gör ingenting att du använder OSIsoft PI-server som historian ihop med PLCer från både Siemens, ABB och Phoenix Connect med ett kamerasystem från Hikvision som ligger slängt ovanpå. Du kan se alla systemen, alla protokollen och alla variabler i samma verktyg. Det är inte ett problem att titta på PI-CONNECT blandat med BACNET och RTSP, allt är tydligt och snyggt tillsammans!

När du ska undersöka en misstänkt incident blir det förstås helt ovärderligt med den här helhetsbilden! Vill du ha listor så får du det men vill du jobba i interaktiva som på bilden så gör du det. Och här hittar vi nästa ovärderliga finess med ett sånt här verktyg, att du inte bara vet vad som händer just nu utan du kan även rota i vad som hänt bakåt i tiden. Att kunna svara på frågan "Vad hände i Pressningens nätverk den 14 April runt 15:30?" är i princip omöjligt utan rätt verktyg men samtidigt helt nödvändigt om du ska kunna fatta rätt beslut!

Du får stöd i att snabbt och enkelt skaffa dig en uppfattning om läget. Insikter som är värda titta närmare på lyfts fram tydligt. Det kan vara klassiska misstag som att en PC har flera nätverksinterface som "kortsluter" din brandvägg eller att nya enheter dyker upp på nätverket.


Undrar du över någon speciell detalj så är det snabbt gjort att kolla "vilka IP-adresser har våra streckkodsläsare från Cognex?" eller "Finns det sårbarheter i vår utrustning från Allen-Bradley?". Svaret är lätt att hitta och innehåller förvånansvärt mycket detaljer!

All denna rikedom av information om våra system och hur de kommunicerar används sedan för Guardians kanske största och viktigaste trolleritrick av dem alla, att löpande analysera trafiken i jakt på konstiga eller farliga händelser. Här nedan ser du ett exempel på en analys av en gammal nätverksinspelning som visar på bredden i analysen genom ett antal bra exempel:

  • En ny enhet dyker upp på nätet och genomför ett angrepp mot en sårbarhet i SMBv1. (Havex/Dragonfly/EternalBlue)

  • En variabel sätts till ett värde som ligger utanför vad som betraktas som normalt.

  • Två redan kända noder börjar kommunicera på ett nytt sätt.

  • En ny enhet dyker upp på nätverket och gör en MITM-attack (Man In The Middle) mot två existerande system.

  • Ett känt system försöker plötsligt ansluta till Internet

Alla dessa attacker är svåra eller näst intill omöjliga att upptäcka utan en löpande analys av nätverkstrafiken med hjälp av AI/ML. I kombination med signaturbaserat skydd blir det verkligen heltäckande!


När Guardian upptäcker något sånt här kan den larma dig på en rad olika sätt beroende på hur din systemmiljö ser ut i övrigt. Integrationer finns av alla sorter och med alla typer av system, allt från enkla meddelanden via epost, SNMP-traps eller syslog till riktiga integrationer med ett SIEM-system eller ServiceNow.

En viktig del i allt detta är förstås att du kan berätta för Guardian hur din nätverksstruktur ser ut. Du kan använda den klassiska Purdue-modellen för att placera in dina adressområden eller VLAN på de olika nivåerna. Det gör rapporter och larm både tydligare och enklare att basera beslut om åtgärder på.

På samma sätt finns alla möjligheter till integrationer för att automatisera åtgärder baserat på regler som triggas. Vill du att vissa typer av angrepp automatiskt ska få en brandvägg att blockera anslutningsförsök så finns det stöd för det.


Nozomi fyller förstås hela tiden på med regler och signaturer för att upptäcka olika typer av angrepp, sårbarheter och risker. Vill du fylla på med egna regler finns möjlighet att använda YARA-regler eller STIX-indikatorer.

Det är imponerande hur mycket insikter Guardian kan ge enbart genom att passivt lyssna på nätverkstrafik men om man vill ha ännu mer finns möjligheter att låta Guardian aktivt fråga systemen. Man kan fråga respektive system via något lämpligt protokoll som EthernetIP, WMI, MODBUS eller SNMP. Tanken här är att man ska våga prata även med "känsliga" system eftersom man gör det på systemets egna vilket och med ett protokoll som systemet använder "till vardags". Man kan också integrera med olika administrationssystem för att hämta information ur någon CMDB (Configuration Management Database) som exempelvis ServiceNow, Cisco ISE eller Aruba ClearPass.


Har man ett mindre nätverk med upp till 500 noder räcker en liten "NSG-R 50" långt men det finns förstås en lång rad andra möjligheter också. Dels finns ett antal större syskon i olika storlekar som klarar upp till 500 000 noder. Det finns också en portabel modell som passar bra när vi konsulter åker ut för att göra en genomlysning av nuläget hos en kund. Har man ett utspritt nätverk finns en mindre enhet, "Remote Collector", som ansluts ute i verksamheten och som sedan förmedlar information till en Guardian för analys. Det finns också virtuella versioner av både Guardian och "Remote Collector" om man föredrar det. Det finns även en container-variant som går att köra direkt i nätverksprylar, exempelvis i Siemens RUGGEDCOM.

Har man flera Guardians så kan man ändå arbeta samlat i deras "Central Management Console". Nozomi har också vad man kallar "Vantage", vilket är deras SAAS-tjänst. Insamlingen av trafik görs förstås i nätverket som vanligt men analys och presentation sker i en molntjänst. Det här är förstås en otroligt smidig lösning, inte minst om man har många separata sajter som man vill samla under en och samma hatt.

Nozomi riktar in sin produkt mot både OT och IoT vilket jag tror passar den här typen av produkt perfekt. Inte minst i samband med Industri 4.0 där man ju förstås är extra intresserad av gränslandet mellan OT, IoT och IT.


Det som kan vara en utmaning med den här typen av lösningar är att man är helt beroende av att se tillräckligt mycket trafik för att kunna göra sin analys. Här får man (som vanligt) välja sin ambitionsnivå efter sin riskanalys, sin existerande nätverksplattform och sina behov. Det fungerar ju också alldeles utmärkt att börja lite begränsat för att sedan bygga ut efter hand som man har möjlighet. Kvaliteten på den nätverkstrafik man samlar in är förstås viktig och att man inte riskerar att störa de nätverk man "avlyssnar". Där kan jag verkligen rekommendera att man löser det seriöst redan från första början, varför inte med tappar och aggregatorer som dem från Keysight som jag tittade på i förra nyhetsbrevet.

Min högst personliga åsikt är att Guardian är en makalös produkt. Det är bara att gratulera Nozomi Networks till en riktig fullträff! Man kommer i ett enda slag åt ett stort antal av de riktigt kluriga utmaningar som det innebär att arbeta med säkerhet i OT-miljöer.


Det är väldigt tydligt att Guardian är utformad för OT-behov från första stund vilket gör det extremt enkelt att snabbt skapa riktigt starka lösningar!


Det är precis den här typen av lösning som behövs för att lösa många olika typer av säkerhetsutmaningar och på köpet får du en massa andra unika fördelar för både säkerhetsfolk och automationsfolk.

 

Vaddå NIST?

Man hör ofta att folk "jobbar enligt NIST" eller "granskar enligt NIST" när de pratar säkerhet. Men vad menar de egentligen? Och vad är det där NIST som de pekar på?


Det här är tredje delen i min serie om standarder och ramverk. Första avsnittet handlade om ISA/IEC 62443 och finns i nyhetsbrev #26. I förra nyhetsbrevet kan du läsa del två där jag tittar på NAMUR NOA. Har du önskemål om vad jag ska ta upp framöver så får du väldigt gärna höra av dig!

Det första att tänka på är att folk kan mena lite olika saker när de pratar om NIST! NIST är en enorm organisation med 3000 anställda som driver standardisering och forskning som en del av USAs Department of Commerce. De har en väldig massa standarder inom en stor mängd områden. Lite slarvigt skulle man kunna jämföra deras standardiseringsarbete med svenska SIS även om jämförelsen haltar ganska mycket eftersom de sysslar med så mycket annat också. Inom just säkerhetsområdet är det fyra delar som de själva lyfter fram: "Cybersecurity framework", OT-säkerhet, kryptolösningar och medicinska system som trådlöst styrda medicinska pumpar.

De dokument som vi OT-, Info- och IT-säkerhetsmänniskor brukar intressera oss för finns i det som NIST kallar "Special Publications" och närmare bestämt i underserien 800. Tittar man på mängden dokument ser man att Cybersecurity faktiskt är ett av deras minsta områden...


Så vad menar folk med att de jobbar enligt NIST? Förmodligen är det något av dessa eller en kombination av dem:

  • Man organiserar sitt säkerhetsarbete enligt "NIST Cybersecurity Framework"

  • Man mäter sin säkerhetsförmåga enligt "NIST Cybersecurity Framework"

  • Man implementerar säkerhetsåtgärder enligt "NIST SP 800-53"

  • Man arbetar med OT-säkerhet enligt "NIST SP 800-82"

Av dessa fyra är det egentligen bara 800-82 som är specifikt för OT-säkerhet. De övriga är generella även de är mycket lämpliga även för OT-verksamheter.


NIST Cybersecurity Framework

De flesta som pratar om "NIST" menar Cybersecurity Framework eller CSF som det brukar förkortas. Det är ett ramverk för hur man mäter risk, strukturerar riskarbete, väljer säkerhetsåtgärder och utför säkerhetsarbete i en organisation. En snygg sak är att man istället för att skapa en ny standard försöker knyta ihop en massa redan existerande standarder och rekommendationer.


Man har gjort en elegant struktur i fem delar som är lätt att förstå. Det i grunden ett dokument och en lista som är tillgänglig i två versioner, antingen en lista i Excel eller ett dokument som beskriver hela modellen. På sätt och vis är det ganska likt upplägget i ISO 27000 där dokumentet motsvarar ISO 27001 och listan motsvarar ISO 27002.

De fem delarna är nedbrutna i 23 kategorier som sedan bryts ner till totalt 108 underkategorier. Varje kategori och underkategori är beskriven med en enda mening och till var och en av dem finns en radda referenser till olika standarder: "Center for Internet Security: Critical Security Controls", "COBIT", "ISA 62443-2-1", "ISA 62443-3-3", "ISO 27001" och "NIST 800-53".


Här ett exempel från kategorin "Protect" i listan med ett par underkategorier samt en förteckning över referenser till diverse standarder som kan användas för att implementera respektive kategori. Som du ser beskrivs varje kategori med bara en enda mening:

En viktig sak som man också trycker på i själva dokumentet är att man måste vara försiktig med att prata om "compliance" gentemot ramverket i och med att det kan användas på så väldigt många olika sätt. Varje organisation uppmanas själv definiera hur man bäst drar nytta av det. På samma sätt ser man ibland att man utför granskningar av en organisation och kommer fram till en betygspoäng, "Företag X har 1.7 NIST-poäng". Det här är inte fel men man får se upp med att jämföra den siffran med andra eftersom det finns många olika sätt att värdera vad som är rätt och fel. NIST uppmanar dessutom organisationer att lägga till egna kategorier eller referenser om det behövs för verksamheten. Men oavsett allt detta är det ett väldigt starkt verktyg för att mäta sin egen utveckling!

Listan med de 108 kategorierna är det som kallas kärnan i NIST CSF. Till det kommer två andra delar, "Implementation Tiers" och "Framework Profile". "Implementation Tiers" beskriver organisationens generella förmåga att arbeta strukturerat med risk men är inte tänkt att ses som en mognadsmodell utan mer som ett handfast sätt att beskriva den nuvarande förmågan och besluta vilken ambitionsnivå man vill ha. "Framework Profile" beskriver hur man sätter mål och sedan mäter uppfyllandet av de 108 kategorierna. Resultatet kan beskrivas på lite olika sätt, vanligast är en kurva eller NIST-poängen jag nämnde här ovanför. Man trycker från NISTs sida på att man inte blint ska sikta på att höja sin "poäng" utan att först värdera det man vill göra utifrån sin riskprofil och utifrån vad åtgärderna kommer att kosta.

För att mäta sin egen organisation med hjälp av CSF kan man antingen göra egna självskattningar alternativt kan man låta en intern eller extern granskare göra en genomlysning. Som stöd för ett sådant arbete finns en massa olika stödverktyg som gör det enklare att ställa rätt frågor eller kontrollera rätt saker. Personligen är jag certifierad CISA-revisor och har då tillgång till ISACAs frågebatteri "Cybersecurity: Based on the NIST Cybersecurity Framework Audit Program" som jag gillar. De flesta stora revisionsföretag har sina egna modeller som de "utsätter" sina kunder för. För oss OT-människor trycker NIST i CSF lite extra på att vi måste tänka på att vi hanterar andra typer av risker så att vi inte fastnar i enbart "IT-tänk" utan även tänker på miljö, hälsa och annat som är typiskt för vår värld.

Högst personligen gillar jag CSF eftersom man valt att inte skapa ytterligare en ledningssystemsstandard och för att det är väldigt lite dödkött i dokumenten. Baksidan av samma mynt är att det lämnar en hel del öppet för eget tyckande vilket förstås kan vara störande för paragrafryttare.


Delen om "Implementation Tiers" är kanske värst på det viset, där har man väldigt lite att luta sig mot.


Delarna kring "Framework Profiles" bör de flesta verksamheter kunna kombinera på ett bra sätt med "Security Levels" om man arbetar efter ISA 62443 för att få en snygg helhetsbild. Ramverket har en stor fördel i att det är gratis även om det förstås lutar sig mot andra standarder som inte är det...


NIST SP 800-53

Det här dokumentets riktiga namn är "Security and Privacy Controls for Information Systems and Organizations" vilket förklarar precis vad det är för ett dokument, en enorm samling säkerhetsåtgärder. Den första versionen dök upp 2005 och sedan dess har det kommit fem uppdateringar som förändrat innehållet ganska mycket. Den senaste versionen dök upp i höstas där man bland annat ändrat språkbruket så att dokumentet passar mycket bättre för oss som intresserar oss för OT och IoT. Ett gäng åtgärder kring supply chain är också intressant men å andra sidan har också ett gäng privacy-krav dykt upp som ofta är mindre relevant för oss.


Där NIST CSF är ett nätt dokument är SP 800-53 betydligt tyngre. Ett introduktionskapitel på 3 sidor, ett kapitel på 7 sidor med förklaringar till strukturen i dokumentet och sedan 350+ sidor med säkerhetsåtgärder! Dessutom har ett dotter-dokument SP 800-53B med 50+ sidor brutits ut som innehåller baselining för säkerhetsåtgärderna i huvuddokumentet. Sedan tidigare finns också SP 800-53A på nästan 500(!) sidor som beskriver man mäter effektiviteten hos säkerhetskontrollerna. Nu är det ju två helt olika dokument men jag kan ändå inte låta bli att jämföra med hur NAMUR skriver sina NOA-dokument från förra nyhetsbrevet, verkligen två helt olika sätt att bygga dokument!

Alla dessa säkerhetsåtgärder delas in i en struktur med 20 familjer där varje familj innehåller ett antal säkerhetsåtgärder där varje åtgärd kan ha en eller flera utökningar. Dokumentet gör en poäng i att inte berätta hur man ska välja rätt säkerhetsåtgärder baserat på sin riskanalys utan pekar istället på ett antal alternativa sätt, bland andra NIST CSF.


Det här är ett brutalt dokument! Vi talar alltså om över 1000 säkerhetsåtgärder som beskrivs på ett utförligt sätt. De är alla skriva på ett sätt som är helt neutralt från tekniken som används och sättet de implementeras vilket gör att det är ett rejält jobb att välja, definiera och implementera dem var och en! Å andra sidan är det en mycket komplett uppsättning i motsats till exempelvis åtgärderna i ISO 27002 som ju av det skälet egentligen kräver ännu mer arbete för att bli heltäckande. Oavsett hur man bygger sitt ledningssystem och kravkatalog för säkerhet är NIST SP 800-53 ett formidabelt uppslagsverk! I och med att det är så generellt skrivet finns mycket som är väldigt användbart även för OT-säkerhet.


NIST SP 800-82

Det här dokumentet släpptes i sin första version 2011 och revision 2, som är den senaste, släpptes 2015. För några veckor sedan begärde NIST in förslag och kommentarer inför ett kommande arbete med att ta fram revision 3. Man säger sig sikta på att ha ett första utkast klart vid årsskiftet. Den nuvarande versionen av SP 800-82 är anpassad till den förra revisionen av SP 800-53 vilket gör att vi hamnar i ett litet mellanläge nu när vi väntar på en uppdatering av SP 800-82... Några intressanta områden som man verkar sikta speciellt på är bland annat:

  • Att göra dokumentet mer inriktat mot styrsystem och automation i allmänhet snarare än det industriella fokus det har i den nuvarande versionen.

  • Användning av moderna säkerhetsåtgärder.

  • Anpassningar som ska passa mindre verksamheter.

Generellt är SP 800-82 tänkt att "läggas ovanpå" SP 800-53 för att bättre anpassa den till OT-världens behov. Dokumentet inleds med en ganska omfattande genomgång av historiken kring OT och ger jämförelser med IT kring skillnaderna i risker och utmaningar. Om man är ny inom OT-världen är det en helt okej introduktion även om det märks att den har några år på nacken, exempelvis saknar jag alla de nya utmaningarna kring "Industri 4.0" som de flesta OT-verksamheter står mitt i idag. Inriktningen är också väldigt hårt skruvad mot processindustri och tillverkande industri medan andra sorters OT bara omnämns i förbigående, inom exempelvis fastighetsautomation, autonoma system, fysiskt skydd och energistyrning. Allt detta verkar man ju sikta på att fixa i den kommande uppdateringen!

Generellt kan jag tycka att SP 800-82, precis som väldigt många amerikanska myndighetstexter, går vilse i sitt syfte och försöker vara allting på en gång. Ena sekunden luktar det skolbok när man går igenom massor av olika nätverksprotokoll för att förklara vad de används till för att sedan plötsligt i detalj gå igenom de 20 familjerna av säkerhetsåtgärder som finns i SP 800-53 för att förklara hur de funkar i OT-världen. Ena sekunden riktar man sig till ledningen och nästa stund till tekniker. Inget av det är förstås fel men det blir tungt att ta till sig den här typen av dokument! Om man använder SP 800-53 i en OT-verksamhet så finns det absolut mycket godis i SP 800-82, inte minst Appendix G som graderar alla säkerhetsåtgärder efter applicerbarhet beroende på verksamhetens riskprofil. Personligen ser jag nog oftast dokumentet som en bra inspiration och kanske ett uppslagsverk när man tittar på något speciellt säkerhetsområde.

 

Mer NOA!

I förra nyhetsbrevet gick jag igenom grunderna för NOA, Namur Open Architecture, och som utlovat kommer här fortsättningen kring deras senaste dokument, NE 177, som belyser säkerhetstänket mer. Vi saknar fortfarande tre dokument i den här serien av totalt fem, men nu kan vi på riktigt börja se vart det tar vägen, åtminstonde säkerhetsmässigt. Jag rekommenderar att du läser min förra text först som du hittar i förra nyhetsbrevet.

Redan från början av den första genomläsningen får man en trygg känsla i magen eftersom de trycker hårt på att det som de beskriver är ett rekommenderat sätt att använda ISA 62443 snarare än att de försöker skapa en konkurrent. Man går så långt att man anger två delar av ISA 62443 som normativa referenser! Fantastiskt klokt sätt att resonera som verkligen hjälper oss som ska använda resultatet framåt!


Dokumentet NE 177 beskriver egentligen det byggblock i arkitekturen som de kallar NOA Secure Gateway, eller ibland "NOA Dioden". En elegant finess i dokumentet är att de försökt vara tydliga med vilka kapitel som vänder sig till användare av arkitekturen och vilka som vänder sig till tillverkare av "NOA Dioder". Ett extra plus där för fokuset på läsaren och vår upplevelse!


Som jag nämnde i min tidigare artikel om NOA har den en väldigt stark sida i att den från början är att passa lika bra oavsett om du bygger en helt ny miljö eller om du kompletterar en gammal automationsplattform med "Industri 4.0". Starkt!


NOAs zonmodell bygger helt på tänket i ISA 62443 och ger oss tre zoner:

  • En kallas CPC, "Core Process Control" - alltså det egentliga styr- och automationssystemet.

  • En andra kallas "M+O onprem", "Monitoring and Optimization On-premises" - vilket är "tillägget" för Industri 4.0 som hör till den fysiska sajten.

  • Den tredje zonen är "M+O offprem", "Monitoring and Optimization Off-premises" - en valfrit zon där information bearbetas på en högre nivå, potentiellt för flera sajter och potentiellt i något slags molntjänst.

I bilden nedan är det de två röda funktionerna som ser till att information förs ut respektive in på ett säkert sätt. I dokumentet vi tittar på nu behandlas den röda boxen till vänster medan den högra kommer behandlas i det kommande dokumentet NE 178.

En riktigt snygg rekommendation som de gör handlar om hur olika aspekter av säkerhet ska prioriteras i de olika zonerna. Även om detta förstås alltid är upp till varje enskild organisation gör de en intressant iakttagelse utifrån den klassiska triaden, "Hemlighet", "riktighet" och "Tillgänglighet". Var och en av zonerna har en egen rekommenderad prioritetsordning:

  • CPC: 1 - Tillgänglighet, 2 - Riktighet och 3 - Hemlighet

  • M+O onprem: 1 - Riktighet, 2 - Hemlighet och 3 - Tillgänglighet

  • M+O offprem: 1 - Hemlighet, 2 - Riktighet och 3 - Tillgänglighet

Du som läst mina tidigare texter vet att jag har vissa invändningar mot att enbart använda dessa tre begrepp (Hemlighet, Riktighet och Tillgänglighet) från informationssäkerhets-världen (se exempelvis nyhetsbrev #24 och #23) men här lyfter det verkligen fram en intressant vinkel och möjlighet!


Den som känner till ISA 62443-3-3 vet att begreppet "Security Levels" är centralt. I NOA förenklar man upplägget i standarden genom att banta ner standardens fyra SL-nivåer till två, "NOA BASIC" och "NOA EXTENDED". De motsvarar ungefär "SL 2" respektive "SL 4" men det finns en lista med de exakta kraven som gäller om man vill använda NOAs två klasser.

Vi får se när det börjar dyka upp tekniska lösningar som implementerar en NOA Secure Gateway? I grunden är det en nätverksdiod som är klädd med lämpliga applikationsproxys på bägge sidor.


Det finns redan lösningar som kommer nära även om de inte formellt sägs vara utformade enligt NOA, ett exempel är Waterfall som har stöd för Historians som OSIsoft PI server och för OPC UA i sina dioder. I vilket fall som helst är NOA och tänket kring NOA Secure Gateway klockrent för att på ett enkelt och tydligt sätt haka på "Industri 4.0" på ett nytt eller gammalt OT-system. Tummen upp från min sida!

 

Intryck från MSBs NIS-konferens

Jag deltog på MSBs konferens kring NIS-direktivet i mitten av Maj. Min förhoppning var framför allt att få höra lite mer tankar kring det kommande nya NIS-direktivet men det blev tyvärr inte så mycket av den varan. De flesta dragningar från olika grupper (politiker, MSB, ENISA, EU-kommisionen mfl) kring det ämnet gick mest ut på att berätta vad de själva gör för bra saker i vardagen. Inget fel i det men det blev inte så framåtriktat som jag hade hoppats.


Det som sades kring just NIS2 var egentligen mest en sammanfattning av skillnaderna mellan det nuvarande direktivet och det liggande förslaget. Av någon anledning sparades bara inspelningarna från konferensen under Maj så det finns tyvärr ingenting att hänvisa till om du vill ta del av vad som sades. Är du nyfiken på just NIS2 så har jag skrivit om det tidigare, i nyhetsbrev #21 och #23 men även i ett blogginlägg.

 

Security for Safety

En av mina favoritsaker att tjata om när jag håller presentationer är klurigheten i att svenskan har samma ord för "Safety" och "Security". Det kan tyckas vara en petitess men jag har varit med om flera händelser där projekt och verksamheter fått problem för att folk missförstått vad man menade när man sa "Säkerhet".


Oavsett vad vi kallar saker så är "Security" väldigt viktigt om man ska få bra "Safety" i våra OT-system. Det finns en massa bra standarder och regelverk som man kan luta sig mot när man designar och kör system med höga krav på "Safety".

Intresset för säkerhet i Safety-system ökade rejält för tre år sedan med TRISIS-attacken mot ett Saudiskt raffinaderi. Och nyligen har det varit en hel del ståhej kring något som kallas "Project 12" från LOGIIC. Och det är är verkligen det 12:e projektet från den här gruppen som egentligen heter "Linking the Oil and Gas Industry to Improve Cybersecurity". Det är den amerikanska olje- och gasindustrin som samarbetar med Department of Homeland Security kring säkerhetsfrågor.

Projekt nummer 12 tittade på säkerheten i säkerhetssystem, alltså "Security of Safety systems, eller mer exakt, egentligen så letade man efter sårbarheter som skulle vara speciellt intressanta i den här typen av system. Rapporten från projektet blev precis klar och rekommenderas för en genomlösning om du är det minsta intresserad av Safety-frågor. Dale Peterson gjorde en intervju nyligen med ett par av deltagarna i arbetet, väl värd att lyssna på!


LOGIIC har ett antal tidigare rapporter, närmare bestämt 11 stycken, som också är intressanta. De täcker spännande ämnen som SIS-system, virtualisering, trådlös teknik och fjärrövervakning.

 

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!


Sinclair Koelemij ger oss en rejäl utläggning kring risk och riskbedömning, han är lika intressant som alltid: https://otcybersecurity.blog/2021/05/09/cyber-risk-assessment-is-an-exact-business/



Om mina artiklar om NOA intresserade dig kanske du vill läsa vad en av mina idoler, Jonas Berge, skriver om ämnet: https://www.linkedin.com/pulse/implementing-namur-open-architecture-noa-jonas-berge/


Diskussioner kring säkerhet i 5G brukar lätt bli en massa fantasier eller skrämsel-propaganda. Vännerna på Trend Micro överraskar lite med ett rejält djup i dessa frågor vilket syns i ett forskningspapper de släppte nyligen: https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/the-transition-to-5g-security-implications-of-campus-networks


Keysight som du mötte senast i förra nyhetsbrevet där jag tittade på deras fina tappar och aggregatorer har levererat något RIKTIGT intressant, något de kallar en Electro Turbo Encabulator. Det här är en närmast magisk manick som jag hoppas kunna få fingrarna på snart och återkomma med en rejäl test. Tills dess får vi hålla till godo med deras reveal-video: https://youtu.be/fltOyddlnOE Berätta gärna vad du tycker!


Matthew Loong berättar för oss hur en pipeline fungerar. Väldigt aktuellt i dessa dagar... https://www.linkedin.com/pulse/operational-technology-musings-former-pipeliner-matthew-loong-%25E9%25BE%2599%25E5%2587%25AF%25E4%25BF%258A/


Projektet "The Top 20 Secure PLC Coding Practices Project" har skaffat sig en snygg logga och nu börjar det närma sig leverans av den första versionen. Om du är med i gruppen kan du följa arbetet från insidan: https://top20.isa.org/


Apropå Colonial-incidenten så har många förståsigpåare tyckt till om behovet av luftgap, något som sällan är en meningsfull tanke och som är helt befängt i samband med en modern pipeline. Här är i alla fall två proffstyckare som dessutom har olika åsikter: Joe Slowik: https://pylos.co/2021/05/13/mind-the-air-gap/ och Jake Brodsky: https://scadamag.infracritical.com/index.php/2021/05/15/air-gapping-it-and-ot/


För den som vill läsa mer av mina alster så finns några av mina artiklar med koppling till OT-säkerhet på Ateas officiella blogg.

 

Det här nyhetsbrevet vänder sig till mottagare med intresse av säkerhet inom OT. Det produceras av Mats Karlsson Landré på Atea Sverige 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.karlsson-landre@atea.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.karlsson-landre@atea.se. Jag lovar att din mejladress inte används till något annat än detta!


Du hittar tidigare nyhetsbrev på ot-säkerhet.se.

bottom of page