Sök

Nyhetsbrev OT-Säkerhet #21 - NIS 2


Du får mina tankar om det nya NIS-direktivet "NIS 2", 44 (!) stycken extremt underskattade sårbarheter i OT-prylar, utbildning i säkerhetsskyddslagen och så funderar jag över SolarWinds betydelse för OT-säkerheten... Jag tittar också närmare på en "Packet Broker" från Keysight, något av en doldis-pryl bland nätverks-utrustning men som visar sig kunna lösa en massa kluriga utmaningar! Ett riktigt välfyllt nyhetsbrev alltså!


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!


Tänk på att du kan hjälpa mig, mer än du kanske tror, genom att trycka "like" på den här artikeln och genom att dela den vidare. Tack för hjälpen!

Nu kommer NIS 2!

Lagom till jul, den 16:e december, fick vi en julklapp från EU! "Kommissionen och unionens höga representant för utrikes frågor och säkerhetspolitik" levererade ett förslag till ny EU-strategi för cybersäkerhet. Som en del av detta finns en uppdaterad version av NIS-direktivet, som man fantasifullt nog valt att kalla "NIS 2".

Strategin pekar på tre områden som man vill fokusera arbetet på:

  1. Resiliens, teknisk suveränitet och ledarskap

  2. Operativ kapacitet för att förebygga, avskräcka och reagera

  3. En global och öppen cyberrymd genom ökat samarbete

Lite floskelartat kan jag väl tycka, men i grunden är det jättebra områden. I den perfekta världen tar alla organisationer ett eget ansvar för att skydda sin egen verksamhet och de som är beroende av den men i praktiken vet vi att det sällan händer! Här kliver EU fram rejält och pekar ut en riktning baserad på ökade krav, tydligare "straff" om man inte sköter sig och ett rejält samarbete både inom och utom unionen. Jag är positiv så här långt!


Jag ser tydligt att det nuvarande direktivet har börjat få effekt. Det är många nya organisationer som hör av sig för att få hjälp och som berättar att vissa svenska tillsynsmyndigheter börjat agera mycket tydligt. Även här måste jag säga att jag är väldigt positiv till utvecklingen, inte bara för att det ger jobb till mig, utan även för att det faktiskt får viktiga verksamheter att prioritera upp sitt säkerhetsarbete!

Det som tillkommer i NIS 2 är bland annat att väldigt många fler branscher omfattas, exempelvis inom elektronisk kommunikation, sociala nätverk, avloppshantering, avfallshantering, rymdverksamhet, läkemedelstillverkning, post, livsmedel och offentlig förvaltning.


Ett område som jag, och många med mig, saknade i det första NIS-direktivet var fjärrvärmeproduktion. Det finns nu med! Ett annat intressant verksamhetsområde är produktion av biogas från exempelvis kompost eller lantbruksavfall. Det finns även med en rad tillverkningsindustrier inom exempelvis fordon, datorer, maskiner, verktyg mm. Ännu lite oklart för mig hur det kommer implementeras, men det är helt klart risk för att ganska många organisationer förvånat kan se sig själva plötsligt omfattas av NIS...

Man har också lagt till sanktioner och böter för brister i riskarbete eller incidentrapportering, mer fokus på samarbete kring sårbarheter och incidenter samt ett fokus på risker kring supply-chain.


Vi ska komma ihåg att det är ett förslag som lagts fram. Det ska diskuteras och förhandlas nu och när man (förhoppningsvis) enats om ett skarpt förslag kommer staterna ha 18 månader på sig att hantera ett införande.


Utan att vara jurist och utan att ha läst förslaget speciellt noggrant tycker jag nog att det verkar extremt lovande på många sätt. Inte minst att omfattningen utökas till några uppenbart viktiga områden. Vi får se hur det tas emot när detaljer och förhandlingar klarnar!

Hör gärna av dig om du har bättre koll på förslaget och hur diskussionerna går! Jag är nyfiken!

När solvindar blir solstormar...

Ingen som varit i närheten av nyhetsmedia den senaste veckan kan ha undgått händelserna kring SolarWinds! Det enda vi kan vara säkra på är att vi fortfarande är väldigt långt från att ha förstått vidden av denna vansinnigt elaka och framgångsrika attack. Som säkerhetsnörd drabbas man både av svindel över de enorma konsekvenserna samtidigt som man inte kan låta bli att bli imponerad!


För bara tanken att rikta in en attack mot en leverantör av den här typen av verktyg är ju ärligt talat smått genialiskt. Om SolarWinds Orion ska fungera som det är tänkt behöver det kommunicera med alla andra system i organisationen och därmed har en insmugglad programvara fantastiska möjligheter att sprida i offrens nätverk. Man kan undra vilka andra leverantörer som drabbats av liknande attacker som ännu inte upptäckts? Om man fantiserar lite blir man snabbt mörkrädd vid tanken på vad som kan hända om något liknande skulle drabba leverantörer av sårbarhetsscanners, virtualiseringsprogram, operativsystem eller PKI-mjukvara. För att inte tala om leverantörer av molntjänster som Azure, AWS, Google, Alibaba osv...


På sätt och vis kan man dra paralleller till utmaningarna kring insiders. På samma sätt som organisationer tvingas lita på vissa av sina egna anställda så finns det system som man bara måste lita på för att de ska kunna utföra sin uppgift. Och på samma sätt får man istället försöka arbeta med möjligheterna att upptäcka när de beter sig konstigt och på så sätt förbygga skador och angrepp.

Det här med attacker via leverantörskedjan var jag inne på i nyhetsbrev #19 och framför allt då tankarna kring innehållsförteckningar, SBOM, för mjukvara. Några entusiaster var lite snabba i sin analys och pekade på SolarWinds som ett lysande exempel där detta hade varit en lösning. Tyvärr har det visat sig att det inte var fallet eftersom utvecklarna på SolarWinds verkar ha haft extremt dåliga säkerhetsrutiner, vilket förmodligen hade lett till att de som litar på en SBOM hade blivit ännu mer lurade...


Även om Solarwinds kanske oftast används i klassiska IT-sammanhang finns det garanterat gott om kopplingar till OT-system, både direkt och indirekt. Även om OT-systemen inte hanterades direkt av Solarwinds finns det helt säkert många organisationer där OT-systemen är beroende av andra system som kunde påverkas direkt av attacken, exempelvis avbrottsfri kraft, datorhallskyla och system för fysiskt skydd.

För oss OT-människor är det en viktig påminnelse om att ingen mjukvara är ofelbar. För system som under inga omständigheter får kunna manipuleras behöver vi kombinera olika metoder för att skydda och härda våra system.

En viktig metod återkommer jag till i nästa nyhetsbrev, då jag tittar närmare på en nätverksdiod från Advenica, nämligen att använda fysikens lagar för att styra upp hur man kan kommunicera mellan olika säkerhetsnivåer.


En annan viktig insikt är att man inte alltid kan förhindra angrepp med 100% säkerhet utan istället får lägga mer krut på att upptäcka och hantera felaktiga beteenden innan de får konsekvenser. Även där har jag några spännande produkter på gång framöver!

Som vanligt när vi pratar om riktade händelser, som medvetet orsakas av människor, blir det svårt eller helt meningslöst att prata om sannolikheter. När man gör sina riskanalyser får man istället fokusera på konsekvenser och göra vad man kan för att ta bort oacceptabla händelser. Om du vill läsa mer om ämnet kan du hoppa till nyhetsbrev #15 men det är också viktigt att bli duktig på att hantera incidenter, vilket jag skrev om i nyhetsbrev #20. Jag kan också rekommendera Andy Bochmans presentation från S4:


En klassisk metod är att arbeta med diversifiering och redundans så att de känsligaste processerna inte står och faller med ett enstaka system eller en enstaka teknologi. Det här är gammal skåpmat för folk i branscher som flyg, tåg, kärnkraft osv men det går att återanvända samma principer i många branscher. Analyser av "common cause" i felsituationer är inte så enkelt som man kan tro men kan vara effektivt för att skapa riktigt robusta miljöer.

För de flesta OT-miljöer är fortfarande en genomtänkt och välskött segmentering en viktig del i skyddet mot alla typer av angrepp. Men det är lätt att man slarvar bort skyddet när man ser alla möjligheter med integration mellan olika system. Det behöver inte vara något motsats-förhållande mellan integration och segmentering men man måste tänka rätt från början. Har man börjat luckra upp segmenteringen, kanske med verktyg från SolarWinds, kanske direkt kommunikation med affärssystemet eller kanske ett gemensamt Active Directory som inte givits motsvarande segmentering så faller snart hela vitsen med segmenteringen! En dålig segmentering orsakar mycket irritation, ger väldigt lite nytta och skapar en falsk känsla av säkerhet...

Vem behöver egentligen en packet broker?

Om du läste nyhetsbrev 17 minns du att jag tittade närmare på en liten och smidig IXIA-nätverkstapp från Keysight. En tapp är ett stabilt och pålitligt sätt att få ut en kopia av all trafik från en nätverkslänk utan att påverka vare sig trafiken eller de system som kommunicerar.


När man sedan har den där kopian på nätverkstrafik så blir nästa fråga vad man göra med den? I det enklaste fallet skickar man in alltihop i en IDS eller något annat analysverktyg. I praktiken är det inte alltid så enkelt... Man kanske vill skicka trafikkopian till flera olika analysverktyg? Man kanske inte vill skicka all trafik till alla analyser? Man kanske vill skicka kopian till en central sajt för analys där? Eller man kanske vill ha metadata om trafiken, exempelvis NetFlow? Den här gången tittar jag på nästa länk i kedjan efter tappen, som ger en snygg lösning på alla de utmaningarna!

Den ser ut som en vanlig nätverksswitch, men det är det inte. Det är en "Packet Broker", kallad "Vision Edge 1S" eller "E1S" som tillverkas av Keysight. Det är en mindre modell jämfört med deras större datacenter-utrustningar. Den är tänkt att användas i mindre organisationer eller för att placeras ute på någon mindre sajt. Precis som Tappen jag tittade på i nyhetsbrev 17 kan den också agera som testklient för Keysights nätverksanalys-verktyg Hawkeye men det är inte den delen jag intresserar mig för idag.


Vad har man en packet broker till då? Räcker det inte med en tapp eller en SPAN-port som skickar trafiken till analysverktyget? Ja, i vissa fall räcker det absolut men med en broker kan man enkelt ta sig an utmaningar som:

  • Filtrera det som skickas på analys för att minska belastningen på verktyget. Exempel kan vara att ta bort krypterad trafik eller bara skicka vidare trafik som berör vissa system. Ett analys-verktyg som bara kan titta på Modbus kan ju få slippa bördan att försöka förstå krypterad trafik från YouTube...

  • Kunna samla trafik från flera källor till samma analysverktyg. Du kan ha flera SPAN-portar och flera Tappar för sedan snyggt samla ihop all trafik.

  • Kunna skicka trafiken till många analysverktyg. Du kanske vill kombinera Zeek, Nozomi Guardian, Malcolm och samtidigt kunna utvärdera Microsoft Defender for IoT?

  • För att felsöka applikationer eller system som beter sig konstigt är det ibland extremt värdefullt att kunna se vad som händer på nätverket. Med en Packet Broker kan du alltid ha en port tillgänglig för att köra Wireshark mot.

  • Istället för att ställa ut analysverktyg på olika platser i nätet kan det ibland vara vettigare att skicka en kopia på den lokala nätverkstrafiken till ett centralt verktyg. Då är det förstås extra intressant att först filtrera bort ovidkommande trafik för att minska bandbreddsbehovet och sedan tunnla trafiken på ett smidigt sätt.

  • Jag har själv varit med om SPAN-portar på switchar som visar sig inte vara enkelriktade vilket lett till att analysverktyget "läckt" ut paket på nätet. Vill man vara supersäker på att det inte kan hända får man använda en nätverksdiod men i de flesta fall är det overkill då en Packet Broker ger samma effekt i praktiken.

  • NetFlow är en viktig informationskälla och med en broker kan du skapa NetFlow-information trots att nätverksswitcharna kanske inte stöder det.

För den som vill dyka lite djupare i hur tappar och SPAN-portar kan sjösättas i OT-miljöer finns ett SANS-papper av Daniel Behrens som visar på en del utmaningar. Daniels papper tar inte upp brokers specifikt men belyser en del andra, mer generella, vinklar på möjligheter och utmaningar i sammanhanget.


Hur kan det se ut i praktiken då? Här är ett par exempel som jag lånat från Keysights dokumentation och ett som jag satte ihop själv:

Här samlar man in trafik från flera "remote site" och skickar den vidare till en central sajt där analysverktygen finns. Här blir det intressant att filtrera bort så mycket som möjligt för att inte lasta ner WAN-länken. I ett OT-sammanhang kanske man bara skickar vidare de OT-protokoll som man är intresserad av. Som synes kan management ske centralt eller om man hellre vill, lokalt på varje burk.

I detta snarlika exempel använder vi Netflow. Netflow är något som jag tycker får alldeles för lite uppmärksamhet, både av IT- och OT-folk. För den som inte känner till Netflow så handlar det om att samla in information om nätverkstrafik utan att samla in innehållet i det som skickats. (Läs mer här: https://en.wikipedia.org/wiki/NetFlow ) Den Netflow-informationen går det att göra väldigt spännande analyser även med små resurser. Det mest kända analysverktyget är nog Cisco Stealthwatch men Netflow är också en väldigt viktig input till ditt SIEM-verktyg, oavsett fabrikat. E1S kan förutom att skicka kopior av nätverkstrafik även skapa Netflow-information baserat på den trafik som samlas in. Det här skapar väldigt smidiga möjligheter att kombinera det bästa av de analysverktyg som man har tillgängligt!

I ett av de exempel jag satte upp i mitt OT-labb tog jag in trafik på tre 1 Gb/s-portar från två SPAN-portar och en nätverks-Tapp. All trafik slogs samman efter att ha filtrerat bort VLAN-taggar som jag inte är intresserad av. Resultatet skickades sedan till två fiberanslutna 10 Gb/s-portar. Dessutom skickades all BACnet-trafik till en port där den kunde analyseras för sig. På köpet skapades dessutom Netflow-information för all trafik som skickades till ett SIEM-system.

Att få till samma lösning utan att använda en broker hade blivit väldigt mycket krångligare. De tre källorna hade fått ha 3 utgångar vardera - en utgång för varje mottagare, vilket inte är möjligt i många switchar. Nätverkstappar med många utgångar finns, men är väldigt mycket dyrare! Alla mottagarna hade behövt tre nätverksinterface. Att få till Netflow är klurigt, inte minst på tappen. Vill du sedan lägga till ytterligare en källa eller en IDS till blir det hysteriskt komplext! Med en broker kan du enkelt lägga till fler sändare och mottagare så länge det finns portar kvar!

Konfigurationen av exemplet gick verkligen snabbt att få till, bara några minuter. Allt, inklusive filtreringen gick enkelt att konfigurera i det grafiska gränsnittet.


All management sker via Hawkeye-gränssnittet som kan köras centralt för flera enheter eller lokalt på varje burk. Gränssnittet är smidigt och snyggt, det är enkelt att lära sig. En funktion som är till stor hjälp vid felsökning på distans är att man kan logga in i E1S och dumpa utvald trafik till pcap-filer som sedan kan laddas ner och analyseras.

En utmaning när man aggregerar trafik från flera källor är att ett och samma paket kan komma att synas flera gånger om det passerar flera switchar med SPAN-portar. Konsekvensen blir förstås ökad trafik och eventuellt också rena felaktigheter i resultatet. En snygg funktion för att ta hand om detta är att man kan slå på "Deduplication" på utgångarna. I praktiken betyder det att paket som redan passerat ( under de senaste millisekunderna) kastas oavsett vilken MAC-adress som används. En smart och enkel lösning på detta problem!

Med sex stycken 1G-portar och fyra stycken 10G-portar som alla kan användas som ingång eller utgång klarar man en hel del olika scenarier! De fyra portarna med SFP+ kan hantera både fiber och koppar för extra flexibilitet.


Ett tänkbart scenario som jag gillar är att använda en broker för dra nytta av existerande IDS-tjänster på "IT-sidan". Man skulle då kunna samla ihop sin OT-trafik, filtrera och aggregera den för att sedan "skicka över" den på analys. Om man sedan tidigare har en kompetent IDS/IPS som känner igen sårbarheter i OT-produkter kan man för en billig penning skapa en riktigt vass analysförmåga på OT-sidan. Säg att man exempelvis redan sitter med en TippingPoint för sina IT-servrar kan man enkelt skapa en förmåga att upptäcka användningen av zeroday-sårbarheter i OT-näten. Att sedan framöver komplettera med analysverktyg för ren OT-trafik, kanske Nozomi Guardian, blir väldigt enkelt eftersom all trafik redan är tillgänglig i brokern.

Varför lyfter jag då den här i ett nyhetsbrev om OT? Utrustningen har ju ingenting specifikt med OT att göra! Det är en klassiskt datacenter-produkt som är anpassad för rackmontering och kontrollerat klimat. Det som gör just den här produkten intressant är att de skapat något som har en vettig balans mellan pris och prestanda vilket gör det möjligt att sätta ut ett gäng sådana här i anläggningarna. Alternativt ger den möjlighet att hantera en liten OT-miljö utan att tömma plånboken helt.


Så mitt svar på frågan i titeln är: "De flesta som bedriver ett seriöst säkerhetsarbete behöver en Packet Broker!"

Analysera mera!

Oavsett hur man samlar in nätverkstrafik, via tappar, brokers eller SPAN-port, så får man förstås ingen nytta förrän man analyserar det man ser. Det här med passiv analys av nätverkstrafik är ju något som är extra viktigt inom OT av flera skäl:

  • Eftersom man ofta tvingas undvika (eller skjuta fram) patchning blir bra analys av vad som händer i nätverket extra viktigt så att man kan upptäcka och agera på angrepp.

  • Man vill vara säker på att säkerhetskontrollerna inte riskerar att störa systemen. Exempelvis väljer de flesta att vara försiktiga med sårbarhetsscanningar och istället satsa mer på analys av trafiken.

  • Tyvärr har alldeles för många verksamheter dålig koll på vilka OT-system de har i sina nät. Moderna analysverktyg ger förvånansvärt bra information om både hårdvarutyp och mjukvaruversioner bara genom att lyssna på nätverkstrafiken. Det ger också automationsingenjörerna fantastiska möjligheter att se vad som verkligen händer i nätverk och system.

  • Många tillverkare och integratörer accepterar fortfarande inte att man installerar egen programvara. Då blir nätverksanalys det enda sätt man kan "titta in" under skalet på systemen.