Varför nätverket har blivit den sista försvarslinjen för OT, IoT och medicinsk utrustning
Någonstans i ditt nätverk finns en enhet som kör ett operativsystem vars support upphörde innan några av dina kollegor hade gått ut skolan. Det kan vara en ultraljudsskanner, en fastighetsstyrningsenhet, en kortläsare, en HMI-enhet i en produktionslinje eller en laboratorieanalysator som kostade mer än en tjänstebil. Du vet att det utgör en risk. Du har påpekat det. Och du har fått höra, artigt och upprepade gånger, att det inte går att uppdatera.
Det svaret är oftast korrekt. Tillverkaren har inte certifierat uppdateringen. Myndighetsgodkännandet gäller en specifik programvaruversion, och det kan ta månader att omvalidera den. Underhållsavtalet upphör att gälla om du modifierar systemavbildningen. Enheten är i drift dygnet runt i en klinisk miljö eller produktionsmiljö, där en omstart är en planeringsfråga snarare än ett enkelt klick. Eller så finns tillverkaren inte längre.
Den realistiska utgångspunkten för alla som idag driver ett företagsnätverk är alltså följande: en betydande andel av enheterna i nätverket kommer aldrig att uppdateras, kommer aldrig att köra en agent för slutpunkter och kommer inte att bytas ut inom den nuvarande planeringshorisonten. Varje säkerhetsåtgärd som utgår från motsatsen – EDR-täckning, agentbaserade säkerhetskontroller, automatiserad efterlevnad av uppdateringar – har en blindfläck just där den utrustning som är mest kritisk för verksamheten finns.
Om slutpunkten inte kan försvara sig själv måste nätverket ta över den uppgiften.
Varför det traditionella svaret inte längre fungerar
Den klassiska lösningen var att placera dessa enheter på en separat plats. Ett VLAN för medicinsk utrustning. Ett VLAN för fastighetsteknik. Ett VLAN för kameror. Stänga av dem från allt annat med en brandvägg och gå vidare.
Det fungerar tills det slutar skala upp. Tre saker kan orsaka att det slutar fungera:
Antalet enheter. Det gick att hantera en segmentering efter kategori när det bara fanns några hundra enheter. På dagens konvergerade campus finns nu tusentals enheter, och nya tillkommer hela tiden. De installeras ofta av en fastighetsentreprenör eller ett team inom klinisk teknik som – helt förståeligt – inte har lämnat in någon ändringsbegäran till nätverksteamet.
Problemet med statiska ACL:er. Varje undantag – servicepartnerns supporttunnel, övervakningsservern som måste nå alla subnät, den nya integrationen med patientjournalsystemet – blir ytterligare en regel. Efter några år vågar ingen ta bort något, så regelbasen växer bara. Segmenteringen finns på papperet, medan den faktiska policyn i tysthet har blivit ”tillåt i stort sett allt”.
Den fysiska placeringen stämmer inte längre överens med policyn. Ett VLAN är knutet till den plats där en enhet ansluts. Enheter flyttas mellan avdelningar, våningar och byggnader. Trådlösa enheter flyttas hela tiden. En policy som är knuten till en switchport eller ett SSID faller samman så fort den fysiska miljön förändras, och lösningen blir alltid att utvidga VLAN:et.
Resultatet är välbekant: ett nätverk som är segmenterat i design dokumentet men i praktiken är platt. Och just ett platt nätverk är precis vad ransomware behöver.
Det första infallsstället är sällan den enhet som inte går att uppdatera; oftast handlar det om ett användarkonto som utsatts för nätfiske. Det är just den enheten som inte går att uppdatera som avgör om en incident påverkar en enda avdelning eller hela sjukhuset.
Tre egenskaper som verkligen påverkar resultatet
Ha hela tiden koll på vad som finns där. Inte genom ett årligt inventeringsark. Använd passiv profilering för att identifiera enheter utifrån hur de beter sig i nätverket – DHCP-fingeravtryck, protokollanvändning, trafikmönster och MAC-ägarskap – och markera allt som dyker upp som du inte hade förväntat dig.
I nästan alla inventeringar visar det sig att antalet anslutna enheter överstiger det antal som finns registrerat i CMDB. Det är just i denna skillnad som risken ligger.
Omfattningen av denna brist underskattas genomgående. I en publicerad fallstudie från runZero fick York University, ett universitet med 54 000 studenter, överblick över 25 000 enheter – ungefär två och en halv gånger så många som man tidigare hade kunnat identifiera. CISO:ns förklaring är värd att beakta: deras nätverkshanteringsverktyg var bra på att hantera nätverket, men inte på att se vilka enheter som var anslutna till det.
Det är två olika funktioner, och de flesta organisationer har endast den första.
Bestäm vilka enheter som varje enhet får kommunicera med. En infusionspump måste kunna ansluta till tre servrar. En kamera måste kunna ansluta till nätverksvideobandspelaren. En dörrstyrning måste kunna ansluta till sin passerkontrollserver. Ingen av dem behöver internet, filservern eller någon av de andra enheterna.
Ställ först in en basnivå för den faktiska trafiken och utforma sedan policyn utifrån vad du observerar, snarare än vad som anges i leverantörens dokumentation. Referensarkitekturen är nästan alltid mer tillåtande än vad miljön faktiskt kräver.
Tillämpa policyn vid anslutningspunkten. Det är detta som gör att modellen fungerar. Policyn bör kopplas till enhetens identitet och tillämpas på åtkomstnivån – den port eller åtkomstpunkt där enheten ansluts – snarare än vid en brandvägg tre hopp bort.
När tillämpningen följer enheten påverkar det ingenting att flytta den mellan byggnader. Sidorörelser mellan två enheter på samma switch blockeras istället för att förbli osynliga.
Hur man gör det utan att stänga ner verksamheten
Anledningen till att dessa projekt går i stå är rädsla, och den rädslan är befogad: ingen vill vara den som på grund av sin segmenteringspolicy avbröt ett ingrepp. Sekvensering löser det mesta av detta.
- Utför en passiv kartläggning innan du vidtar några åtgärder. Det tar veckor, inte dagar. Ingenting förändras i nätverket under denna fas, så det finns ingen risk att ta hänsyn till.
- Simulera policyn i övervakningsläge. Kör de avsedda reglerna och logga vad som skulle ha blockerats. På så sätt förvandlas en diskussion om risker till en granskning av en rapport, och det brukar ofta framkomma två eller tre legitima flöden som ingen har dokumenterat.
- Börja med en enhetsgrupp som innebär hög risk men har begränsad inverkan på andra delar av verksamheten. Kameror och fastighetsteknik är perfekta första val: säkerhetsvinsten är påtaglig och de operativa riskerna är lägre än för utrustning inom sjukvård eller produktion.
- Involvera utrustningsägarna redan i ett tidigt skede. Klinisk teknik, fastighetsförvaltning, operationssalsteknik. De vet saker som nätverket inte kan berätta, att analysatorn överför data till tillverkaren under natten, att en leverantör ringer in varje kvartal för att kalibrera. De har också ett informellt vetorätt: första gången en policy får skulden för ett driftsproblem upphävs den, och när den väl har upphävts återinförs den sällan. Den policy du inför utan dem håller bara tills den första incidenten inträffar. Den policy du kommer överens om med dem överlever den.
- Expandera efter grupp, med en återställningsväg för varje grupp. Varje steg ska kunna återställas separat.
Det lönar sig att enas om åtgärder redan från början, eftersom argumentet ”vi är säkrare” inte håller i en budgetdiskussion. Nyttiga mått är: tiden det tar att identifiera en okänd enhet i nätverket, andelen åtkomstportar som omfattas av dynamiska policyer samt antalet destinationer som en komprometterad enhet i varje grupp kan nå – dess ”sprängradie” – och att se hur antalet minskar är det tydligaste beviset på att programmet fungerar.
Efterlevnadsaspekten, i korthet
Om ni bedriver verksamhet som en väsentlig eller viktig enhet enligt NIS2 är det svårt att på ett effektivt sätt uppfylla kraven gällande tillgångshantering, åtkomstkontroll och incidentdetektering utan denna funktion. Ni kan inte rapportera en incident inom den föreskrivna tidsramen om det tar flera dagar att fastställa vilken enhet det rör sig om, var den är ansluten och vilka system den har kommunicerat med.
ISO/IEC 27001 och ENISAs tekniska riktlinjer understryker vikten av dessa funktioner, medan de nationella ramverken för genomförandet av NIS2 i medlemsstaterna omsätter dem i lokala krav. För många organisationer innebär detta att det arbete med nätverkssegmentering som de har skjutit upp av säkerhetsskäl nu också blir en prioriterad fråga för att uppfylla kraven. Rent praktiskt är det ofta just detta som till slut frigör budgetmedlen.
Var Damovo passar in
Vi utformar och drifter campusnätverk där denna modell är standard snarare än en eftermontering – enhetsprofilering och policygenomförande är inbyggt i åtkomstlagret med hjälp av de plattformar som våra kunder redan använder, däribland Cisco Identity Services Engine, Extreme Networks Fabric och Universal ZTNA-policy, tillsammans med runZero för agentlös inventering av enheter inom IT, OT och IoT. Vi genomför upptäckts- och övervakningsfaserna som ett strukturerat uppdrag så att ni får en överblick över er faktiska enhetsinventering och er faktiska trafikbaslinje innan ni går vidare med tillämpningen, och vi kan hantera policycykeln som en hanterad tjänst där det interna teamet inte har kapacitet att ansvara för den.
Om du vill veta hur många enheter som faktiskt finns i ditt nätverk är det den här diskussionen du bör börja med.