top of page
Sök
    • 29 dec. 2020

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@ot-sakerhet.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.

Då blir ju nästa fråga vad man ska använda för själva analysen? Här finns en uppsjö av möjligheter, allt från kommersiella lösningar som Nozomis Guardian och Microsofts Azure Defender for IoT (som ju bygger på gamla CyberX som Microsoft köpte nyligen) till lösningar som är open source där framstående exempel är Arkime (före detta Moloch), Malcolm och Security Onion.


Jag planerar att titta närmare på kommersiella lösningar som är specialiserade på OT i ett framtida nyhetsbrev. Om man tittar på gratisverktygen Arkime och Security Onion så är båda två generella verktyg som inte är inriktade mot OT även om det finns en del tillägg och annat med det fokuset. Malcolm har jag inte använt själv men man säger att det finns ett OT-fokus på utvecklingen.


Man kommer väldigt långt med gratis verktyg även om det som vanligt tenderar att krävas betydligt mer arbetsinsatser jämfört med kommersiella lösningar, både för att komma igång och löpande. Det är ganska vanligt att man använder "open source"-system för att "komma igång" och för att visa på värdet och behovet av denna typ av lösningar.

En av våra svenska världsstjärnor på området, Eric Hjelmvik, publicerade nyligen ett intressant blogg-inlägg som beskriver hur man kan använda PolarProxy som är ett riktigt smidigt verktyg som Eric tillhandahåller för att dekryptera krypterad kommunikation för att kunna analysera innehållet. I bloggen beskriver Eric hur man använder PolarProxy just med Arkime! Kryptering blir ju sakta men säkert allt mer vanligt inom OT-världen, inte minst när vi pratar OPC-UA. Kryptering är som bekant en bra idé men det ställer till det i de här sammanhangen eftersom det tenderar att dölja en del intressant information i våra analyser. Jag kan förresten verkligen rekommendera Erics andra verktyg, framför allt NetworkMiner och CapLoader som är sanslöst smidiga att arbeta med.

Arkime tycker jag personligen är ett fantastiskt verktyg för analys av nätverkstrafik, både inom IT och OT. Det går verkligen smidigt att samla in trafik och sedan att analysera på alla tänkbara ledder.

Malcolm (som verkar finnas i två forks: cisagov och idaholab) har jag som sagt inte prövat själv men det ser lovande ut med ett tydligt OT-fokus. Malcolm är baserad på Arkime, ElasticSearch, Zeek och andra framstående projekt.


Är det någon av mina läsare som arbetat med Malcolm? Hör av dig och berätta mer!



 

I skuggan av en solstorm...

Händelserna kring Solarwinds har snott åt sig de flesta rubrikerna på sistone, men det finns fler spännande sårbarheter att fundera över. Två som har speciellt mycket koppling till OT-säkerhet är URGENT/11 och AMNESIA:33. (Visst är det viktigt med bra namn på sårbarheterna! :-) ) Båda två är ett gäng riktigt allvarliga sårbarheter i olika implementationer av TCP/IP, vilket dessutom tenderar att vara den värsta sortens sårbarheter eftersom de finns direkt i implementationen av nätverksprotokollen. Nästan alla former av skydd är overksamma på den nivån!

URGENT/11 är en samling sårbarheter i TCP/IP för VxWorks från Wind River som upptäcktes av säkerhetsföretaget Armis och som publicerades förra sommaren. Ingenting nytt alltså, men sårbarheterna kom i fokus igen nyligen när en undersökning publicerades som sade att 97% av sårbara OT-enheter ännu inte uppdateras och därför fortfarande är sårbara. VxWorks är förmodligen världens populäraste realtids-operativsystem. Det används bland annat i OT-utrustning, som PLCer, från en rad stora tillverkare. Armis uppskattade antalet berörda enheter till över 2 miljarder!

AMNESIA:33 är som namnet indikerar 33 sårbarheter i fyra olika implementationer av TCP/IP (uIP, FNET, picoTCP and Nut/Net) som upptäcktes av Forescout. Sårbarheterna berör hundratals leverantörer av utrustning inom OT men också IoT, skrivare, nätverksutrustning, servrar och inbyggda system.


Av de 11 sårbarheterna i URGENT/11 är 6 riktigt allvarliga i och med att de kan leda till exekvering av kod på distans genom att bara ha någon form av nätverksförbindelse med "offret". 4 av de 6 allvarligaste sårbarheterna berör TCP, 1 ligger i IP (source routing) och 1 i DHCP. Det finns en del åtgärder man kan göra utan att uppdatera, främst att blockera lite udda användning av TCP/ip: tcp-paket med Urgent-flaggan satt och source routing. Du hittar rekommendationer hos respektive tillverkare. Här är ett snyggt exempel: Phoenix Contact.


Om du letar efter argument att investera i IPS-skydd eller brandväggar ute i din anläggning så finns det inga bättre än dessa sårbarheter. Med lämplig utrustning, som exempelvis EdgeFire från TxOne eller mGuard från Phoenix Contact, kan du direkt blockera den här typen av kommunikation mellan enheterna i dina OT-nätverk. De flesta har garanterat sårbara utrustningar som de inte vill eller kan uppdatera och då är ett nätverksskydd det enda alternativet! Du kan dessutom implementera skydd väldigt mycket snabbare jämfört med att patcha alla utrustningar!


Men framför allt kan man se det här som en påminnelse om en viktig säkerhetsprincip kring OT. Man ska inte ha direkt nätverkskontakt mellan omvärlden och OT-enheter. Det gäller speciellt VPN-förbindelser som termineras lokalt i OT-enheten eftersom både VPN-tunneln i sig själv är en TCP/IP-förbindelse och förstås också anslutningen som går igenom VPN-länken! Det vanligaste misstaget kring det här är runt lösningar för fjärrsupport där man gärna börjar fuska genom att sätta upp VPN-tjänster utan att göra en ordentlig riskanalys. Se till att åtminstone "mellanlanda" i en härdad jumpserver eller satsa på en riktig lösning i stil med ConsoleWorks från TDI Technologies.

Det finns förstås hur mycket som helst att läsa om det här. Här är några förslag:

Armis har några intressanta video-demonstrationer av attacker mot PLCer från Rockwell och Schneider Electric.

 

Säkerhetsskydd?

I princip hela mitt yrkesverksamma liv har jag arbetat i verksamheter med höga krav på säkerhet och skydd. Numera, som konsult, har jag ett antal kunder som lyder under säkerhetsskyddslagen. Det här är ett område som många upplever som förvirrande och där det finns en massa missförstånd. Det blev inte bättre av att mycket ändrades i och med vår nya säkerhetsskyddslag som kom 2019. Många är också förvirrade över skillnaderna mot NIS-direktivet som vi fick 2018. Jag undrar hur det blir nu när "NIS 2" är på gång och höjer ribban rejält?

Dessutom har jag varit med om att man blandar samman Skyddslagen och Säkerhetsskyddslagen, de låter ju besläktade men handlar om helt olika saker. Skyddslagen styr bara över begreppet "Skyddsobjekt", vad som gäller kring dem och hur en "Skyddsvakt" utses, utbildas och får bete sig. Säkerhetsskydd och skyddsobjekt används helt oberoende av varandra även om de förstås är hyfsat vanliga tillsammans!

Under åren har jag väl samlat på mig en hel del kunskaper men jag har ibland känt att jag saknat en samlad utbildning. Så, när jag hittade Företagsuniversitetets utbildning "Diplomerad Säkerhetsskyddschef", var det dags att anmäla mig! Kursen är nio dagar totalt och nu har jag genomfört de första tre. Jag kan redan nu säga att det är en riktigt bra utbildning! För den som är intresserad av att vidareutveckla sig inom det här komplexa men intressanta området kan jag verkligen rekommendera den här kursen. Ett rejält kursmaterial, en otroligt erfaren lärare i Per Fjellman och en radda riktigt tunga gästföreläsare gör detta till en helt unik kurs!


Jag lovar att återkomma med eventuella spännande insikter när kursen är slut i Februari men hör gärna av er om ni har funderingar eller frågor! Min omgång av kursen blev fulltecknad men det kommer nya tillfällen kommer i Mars och September.

 

Önskas: Kandidater till testlabbet!

Det verkar som mina artiklar om olika produkter är uppskattade! Jag har en liten kö med spännande saker för kommande nyhetsbrev. I nästa nummer blir det en riktigt imponerande nätverksdiod från svenska Advenica som intar scenen.

Jag tar gärna emot tips och rekommendationer på produkter som jag borde titta närmare på. Det behöver inte bara vara rena säkerhetsprodukter utan kan även vara OT-produkter som är intressanta ur ett säkerhetsperspektiv. Jag kan även tänka mig att sladda över i IoT-hörnan emellanåt... Hör av dig!

 

Lästips

Lite mer att läsa:

Och en massa kloka tankar kopplat till Solarwinds-hacket och supply-chain:

 

Det här nyhetsbrevet skickas till mottagare med intresse 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 .

bottom of page