OT-säkerhet är ett område som ger oss många spännande utmaningar. Men ibland känns det frustrerande att de säkerhetsåtgärder vi tar inte ”räcker hela vägen”. En anledning till det tror jag kan vara att man försöker implementera en åtgärd åt gången i stället för att se hur olika åtgärder kan förstärka varandra. Ett intressant exempel på två områden som verkligen kan förstärka varandra är sårbarhetshantering och segmentering.
Med sårbarhetshantering menar jag i det här sammanhanget det hårda arbete som man står inför om man ska försöka hänga med i alla nya sårbarheter som annonseras för att kunna analysera hur de slår mot alla de komponenter man har och i vilka sammanhang som det faktiskt är värt att störa produktionen för att lägga på en säkerhetsrättning. Det är ju här som skillnaderna mot IT-världen kanske blir som allra tydligast för många.
När jag pratar om segmentering tänker jag främst på arbetet att dela upp nätverk, dataflöden och system inom OT-miljön. Att separera ”IT” och ”OT” förutsätter jag är hanterat även om mitt resonemang här skulle kunna fungera lika bra på den uppdelningen.
För båda dessa utmaningar blir en absolut förutsättning för att kunna göra någonting alls att man har tillgång till pålitlig information om vilka komponenter man har, hur de sitter ihop och hur dataflöden mellan dem ser ut. Det betyder (som vanligt) att vi är beroende av att vi har verktyg och processer som hjälper oss med detta.
Att löpande bedöma vilken risk som nya sårbarheter orsakar för organisationen är ett tufft jobb av många skäl. Ett sådant skäl är att även en enkel systemmiljö har många komponenter som var för sig kan påverka helheten på kluriga sätt. Det är här som kopplingen till segmenteringsarbetet blir en möjlighet att göra arbetet mycket enklare.
Arbetsordningen för att bedöma en ny sårbarhet kan se ut så här i normala fall:
- Bevaka alla relevanta källor för att fånga upp alla nya sårbarheter som eventuellt kan vara aktuella
- För varje sårbarhet:
a. Förstå sårbarheten (vad påverkas, hur och under vilka förutsättningar?)
b. Identifiera alla komponenter i vår miljö som möjligen berörs av sårbarheten
c. För sårbarheten – bedöm varje komponent som berörs:
i. Går sårbarheten att utnyttja i just denna komponent på det sätt den används hos oss? (med tanke på andra skydd och arkitekturen)
ii. Hur påverkas komponentens pålitlighet om sårbarheten utnyttjas?
iii. Hur påverkar verksamhetens risk av att komponenten inte går att lita på?
iv. Vilka skydd finns som kan minska verksamhetens risk? (härdning, segmentering etc.?)
Ett av problemen med det här resonemanget är att alla komponenter både blir en potentiell sårbarhet OCH samtidigt en del av skyddet mot angrepp. Det gör att analysen blir väldigt komplex! Jag föreslår att vi i stället vänder resonemanget på huvudet och utgår ifrån att alla komponenter alltid kommer vara sårbara och i stället fokuserar på att omgärda dem med tydliga säkerhetsåtgärder. Då behöver vi bara bedöma hur säkerhetsåtgärderna eventuellt påverkas av den nya sårbarheten medan vi med flit struntar i allt som inte är exponerat. Det låter ju onekligen lite enklare… Om du tycker det här låter som en jobbig kompromiss så har du förmodligen rätt. Att jag tycker den i många fall ändå är okej är att man i slutänden ofta ändå väljer att skjuta upp patchningen på grund av något annat skydd, exempelvis just segmenteringen.
Med det tänket blir bra säkerhetsåtgärder extremt avgörande och det är här kopplingen till segmenteringsarbetet dyker upp. Jag tänker mig att vi gör en ”riktig” segmentering i stil med vad IEC 62443 del 3 pekar på, och använder säkerhetszoner (”zones” i standarden) som sammanbinds av det standarden kallar ”conduits”. När folk pratar om segmentering brukar det lätt bli en ren nätverksfråga och det är här nästa nyckel till mitt resonemang finns. Tricket ligger i att vara så pass systematisk i designen att man faktiskt har koll på vad som exponeras i respektive system. Att göra det ur ett nätverksperspektiv är inte så svårt, det handlar ofta om att öppna portar i någon slags brandvägg. Utmaningen ligger i att hantera det som exponeras!
Ett exempel på varför det här är viktigt: Det är vanligt att jag stöter på organisationer där man noggrant segmenterat sitt nätverk men att man samtidigt tillåter Windows-datorer att prata ganska fritt över segmenteringsgränserna för att komma åt filer, använda Active Directory, skriva ut osv… Det innebär att man segmenterat nätverket på ett sätt, men ur ett Windows-perspektiv så ser segmenteringen väldigt annorlunda ut! Det betyder att en Windows-tjänst som exponeras i en säkerhetszon potentiellt ”drar med sig andra säkerhetszoner i fallet”. Det går inte alltid att undvika, men då ska vi ha koll på det och bygga vårt riskresonemang utifrån det! Exempelvis undvika att hamna i situationer där en Windows-dator med flera nätverkskort används för att knyta ihop olika nätverk eller säkerhetszoner, då har en redan onödigt stor säkerhetszon blivit ännu större och väldigt mycket mer komplex.
Om vi gjort en klok segmentering och därmed har koll på vilka säkerhetsåtgärder vi har och vilka tjänster i andra komponenter som är exponerade behöver ovanstående metod för att analysera en sårbarhet bara titta på säkerhetsåtgärderna och de exponerade tjänsterna. Det är en enorm minskning av mängden arbete, både för att volymen är mindre men också för att den ordning och reda man skapat gör det väldigt enkelt att identifiera vad som är relevant att bedöma! Om man kan dra nytta av moderna sätt att annonsera sårbarheter går det dessutom att automatisera en del av arbetet!
Eftersom uppdelningen i ”zones” och ”conduits” är tänkt att vara riskstyrd blir nästa nytta man kan ta del av att bedömningen av en sårbarhet blir enklare eftersom det är möjligt att definiera en enhetlig riskprofil per zone och conduit.
Observera att grunden för att kunna dra nytta av detta inte i första hand är tekniska lösningar, utan en klok metod för att göra och dokumentera hur man designat segmenteringen, tillsammans med vettiga procedurer för hur man följer med i floden av annonserade sårbarheter.
Däremot är tekniken förstås helt avgörande för att kunna implementera detta i praktiken. Nätverkssegmentering kan exempelvis vara en valfri kombination av klassiska centrala brandväggar med tillhörande switchar, lokalt skydd ute i anläggningen eller mjukvarudefinierade nätverk. När det gäller komponentinventering, trafikflödesanalys och riskanalys kan det vara bra med en valfri kombination av specialiserade verktyg för inventering, en modern detekteringsplattform eller en plattform för förebyggande riskanalys. Som vanligt blir bra verktyg helt fantastiska i händerna på något som använder dem rätt!
En riktig ”killer-applikation” i det här sammanhanget är förstås nätverksdioder, det som Advenica kallar ”data diodes”. Det är ganska uppenbart att det kan ge stora fördelar – även om det i många fall kanske inte ens är huvudsyftet med att införa den typen av teknik.
Mest uppenbart blir det förstås om man överväger en ren nätverksdiod, där ett system som är på ”uppströms-sidan” av dioden är fysikaliskt omöjligt att nå från andra sidan. Det är ju faktiskt hela vitsen med dioden och ungefär så bra skydd man någonsin kan få mot nätverksburna angrepp… Men även system ”nedströms” kommer i de flesta fall bli svårare att angripa, men det beror förstås till en viss del på vilken typ av filtrering som sker i dioden, vilket nätverksprotokoll som är aktuellt och naturligtvis vilken typ av angrepp man vill undvika.
När det gäller andra CDS-lösningar, exempelvis ZoneGuard från Advenica, finns inte samma skydd från fysikens lagar. Men eftersom hela tanken med en sådan lösning är att ”plocka isär” kommunikation i sina minsta beståndsdelar kommer angrepp i praktiken bli väldigt svåra att få igenom en CDS-gateway.
Förutom att skydda mot angreppet blir det i de flesta fall även ett visst skydd mot skadeverkningar även om angreppet faktiskt skulle lyckas. Stöld av information eller manipulation av en process är ju definitionsmässigt omöjligt i ”fel riktning” genom en diod.
När det gäller förenkling av sårbarhetshantering bör rimligen diod-liknande teknik vara en hit! I de flesta fall borde analysen av en ny sårbarhet bli enklare och det borde i slutändan även resultera i färre panik-uppdateringar!
Mats Karlsson Landré
OT-säkerhetsexpert
AFRY
