Blogg

Nätverket kan inte längre vänta på nästa servicefönster

När tiden från publicerad sårbarhet till möjlig exploatering krymper måste patchbarhet bli en del av nätverksarkitekturen.

Vi kan inte längre bygga nätverk där säkerhet förutsätter ett servicefönster. Framtidens infrastruktur måste kunna skyddas och uppgraderas medan verksamheten fortsätter.

Stabilitet har länge varit nätverkets främsta ledord. En switch, router eller brandvägg kunde stå orörd under lång tid. När det blev dags för en större uppgradering planerades ett servicefönster, förändringen testades, verksamheten informerades och infrastrukturen uppgraderades under kontrollerade former.

Det har varit en rimlig modell. Men hotbilden arbetar inte längre efter våra servicefönster.

Tiden mellan sårbarhet och angrepp krymper

Utvecklingen inom AI förändrar inte bara hur vi utvecklar programvara. Den förändrar också hur snabbt mycket stora och komplexa kodbaser kan analyseras, hur sårbarheter kan identifieras och hur snabbt potentiella angrepp kan tas fram.

Ett exempel på utvecklingen är Project Glasswing, ett initiativ från AI-företaget Anthropic där teknik- och säkerhetsföretag använder AI-modellen Claude Mythos Preview för att identifiera sårbarheter i kritisk mjukvara. Modellen har enligt Anthropic redan hittat tusentals allvarliga sårbarheter.

Det visar vilken kraft AI kan få inom cybersäkerhet. Samma utveckling som hjälper försvarare att hitta sårbarheter snabbare förändrar också förutsättningarna för hur snabbt organisationer behöver kunna reagera.

När en kritisk CVE publiceras börjar därför klockan ticka. CVE står för Common Vulnerabilities and Exposures och är ett standardiserat sätt att identifiera och referera till kända säkerhetssårbarheter i mjukvara och hårdvara. När en kritisk sårbarhet blir känd inleder nätverksteamet en kedja av aktiviteter som ofta tar tid:

Identifiera → Analysera → Testa → Planera → Uppgradera → Verifiera

Under tiden kan infrastrukturen vara exponerad. Detta brukar beskrivas som ett patching gap: tiden mellan att en sårbarhet blir känd och att en permanent programvarufix faktiskt har kunnat driftsättas.

När säkerhet ställs mot tillgänglighet

Organisationen vill minska risken genom att patcha snabbt. Men själva patchningen kan samtidigt innebära en verksamhetsrisk.

Nätverket är inte längre bara en del av IT-infrastrukturen. Nästan all annan digital infrastruktur är idag beroende av nätverket.. När en central switch, router eller brandvägg behöver startas om kan det påverka applikationer, användare, servrar, molntjänster, produktionsmiljöer och säkerhetssystem.

Därför hör man fortfarande: ”Vi tar den i nästa servicefönster.” Men om tiden från publicerad sårbarhet till möjlig exploatering fortsätter att krympa blir det allt svårare att acceptera veckor eller månader av exponering i väntan på nästa planerade förändringsfönster.

Från underhållsfönster till kontinuerlig motståndskraft

Framtidens nätverk behöver designas utifrån antagandet att säkerhetsproblem kommer att upptäckas medan infrastrukturen är i drift. Vi behöver därför kunna agera utan att först stänga ned det vi försöker skydda.

Redan i dag finns tekniska angreppssätt som förändrar förutsättningarna. Modern nätverksinfrastruktur kan byggas med redundans och uppgraderingsmekanismer som gör det möjligt att underhålla delar av miljön medan trafiken fortsätter via andra komponenter.

Vi ser också en ny generation skydd där risken med en specifik sårbarhet tillfälligt kan minskas innan den permanenta mjukvaruuppgraderingen genomförs. När plattformen stödjer det kan ett validerat runtime-skydd minska exponeringen utan omstart.. På brandväggssidan finns på motsvarande sätt programvarupatchar som kan applicera kritiska CVE-fixar utan en fullständig versionsuppgradering. Beroende på patchens typ kan åtgärden ske utan omstart, med omstart av enskilda processer eller med en fullständig reboot.

Det handlar inte om att sluta patcha. Det handlar om att minska exponeringen medan den permanenta fixen går igenom rätt test- och changeprocess.

Sida

Nätverkssäkerhet

Läs

Patchbarhet blir en arkitekturegenskap

Historiskt har patch management framför allt betraktats som en operativ process. När reaktionstiden krymper blir förmågan att skydda och uppgradera utan avbrott i stället en arkitekturfråga.

Det räcker inte längre att fråga vilken switch eller brandvägg organisationen ska köpa. Vi behöver också fråga:

• Kan infrastrukturen uppgraderas utan trafikavbrott?
• Finns redundans hela vägen genom designen, eller bara på pappret?
• Hur snabbt kan vi identifiera vilka enheter och versioner som påverkas av en ny CVE?
• Kan ett temporärt skydd appliceras innan en fullständig uppgradering?
• Hur automatiserad är processen för analys, utrullning och verifiering?
• Hur länge är organisationen beredd att vara exponerad?

”Den har varit uppe i 800 dagar!”
För några år sedan hade det kanske resulterat i en high five. I dag borde nästa fråga snarare vara:
”Bra. Men när patchade vi den senast?”
Lång upptid är inte automatiskt samma sak som ett säkert och modernt nätverk.

Ett servicefönster är inte en säkerhetsstrategi

Det betyder inte att servicefönster försvinner. Större versionsuppgraderingar kommer fortsatt att behöva planeras, testas och genomföras kontrollerat. Temporära skydd får inte heller bli en ursäkt för att skjuta upp permanent patchning.

Men servicefönstret kan inte längre vara den enda tidpunkt då organisationen kan minska en kritisk infrastrukturrisk. Vi behöver i stället skapa en sammanhängande förmåga:

Upptäck  →  Skydda  →  Patcha  →  Verifiera

När en kritisk sårbarhet upptäcks ska organisationen snabbt kunna förstå sin exponering och, där tekniken stödjer det, lägga på ett temporärt skydd. Den permanenta uppgraderingen kan därefter testas och genomföras kontrollerat. Valet behöver då inte längre stå mellan att leva med sårbarheten och att riskera ett omedelbart produktionsavbrott.

Det kräver rätt arkitektur från början

Förmågan kommer inte automatiskt. Den påverkas av vilka plattformar och mjukvaruversioner som används, hur redundansen är byggd, hur infrastrukturen manageras och hur organisationens processer för vulnerability management och change management ser ut.

Nästa generations nätverksdesign behöver därför inte bara optimera prestanda, kapacitet och tillgänglighet. Den behöver också designas för security agility: förmågan att snabbt förändra, skydda och uppgradera infrastrukturen utan att verksamheten behöver stanna.

Så kan Conscia hjälpa

På Conscia hjälper vi organisationer att bedöma om nätverket är byggt för den nya verkligheten. Det handlar om rätt design, rätt plattformar, korrekt redundans, automatiserad livscykelhantering och processer som knyter samman sårbarhetsinformation med praktisk åtgärd.

Målet är inte bara att genomföra nästa uppgradering. Målet är att skapa en infrastruktur där säkerheten inte är beroende av att verksamheten kan hitta ett ledigt servicefönster.

Källor och faktaunderlag

• Cisco Live Protect – Reduce vulnerability exposure before the next patch window
• Cisco – Mitigate Data Center Networking Security without Disruption in Real Time
• Cisco Live – Live Protect on IOS-XE, BRKENS-2615
• Cisco Blogs – Shields Up: Cisco Live Protect Closes Vulnerability Gap
• Palo Alto Networks – Install a PAN-OS Software Patch

Om författaren