Et sted i IT-miljøet ditt står en maskin som ikke vil ta imot denne ukens patch, og den kommer til å stå der neste måned også. Kompenserende tiltak for upatchede sårbarheter er de tiltakene et IT-team setter inn så lenge det er slik. De lukker ikke svakheten. De gjør den vanskeligere å nå eller mindre nyttig for en angriper, og de holder eksponeringen på et nivå virksomheten aksepterer, til en permanent løsning er på plass.
Ordet som bærer vekten, er midlertidig. Et kompenserende tiltak står i stedet for utbedringen du ikke kan gjennomføre ennå. Det erstatter den aldri.
Det meste av rådene om sårbarhetshåndtering på endepunkter forutsetter at patchen finnes, og at det eneste spørsmålet er hvor raskt den kommer ut. Slik oppfører IT-miljøer seg sjelden, og teamet eier fortsatt risikoen på hver maskin som faller utenfor den forutsetningen.
Hvorfor noen sårbarheter forblir åpne
Tre situasjoner står for de fleste endepunktene som fortsatt er eksponert etter en skanning.
Leverandøren har ikke levert en løsning. Sikkerhetsvarselet er offentlig, kode for konseptbevis (proof of concept) sirkulerer, og versjonsnotatene sier ingenting. Ingenting IT-teamet installerer, hjelper.
Patchen finnes, men den ødelegger noe. Et saksbehandlingssystem er avhengig av akkurat den runtime-versjonen oppdateringen erstatter. Programeieren tester, en eksportfunksjon feiler, og utrullingen stopper. Den sårbare versjonen blir værende i produksjon, fordi alternativet er en avdeling som ikke kan jobbe.
Enheten kan ikke ta imot oppdateringen. En maskin som styrer produksjonsutstyr og kjører et operativsystem som er utenfor supportperioden. Et endepunkt som er omfattet av en endringsfrys. En bærbar PC som kobler seg til i tjue minutter i uken, aldri lenge nok til å fullføre en installasjon.
Å begrense risikoen er ikke å utbedre den
En skanner rapporterer tilstand, ikke vurderinger. Etter at et kompenserende tiltak er på plass, står CVE-en fortsatt i rapporten, fordi den sårbare versjonen fortsatt ligger på disken. Ingenting ved tiltaket endrer den linjen.
Det som endres, er svaret på et annet spørsmål: kan noen nå dette, og hva skjer hvis de gjør det. Det gir tre tilstander, og en rapport som ikke skiller dem, villeder den som leser den.
Sårbar og eksponert. Svakheten er der, og ingenting står mellom den og en angriper.
Sårbar, men begrenset. Svakheten er der, et navngitt tiltak bryter angrepsveien, og noen eier det som gjenstår.
Utbedret. Svakheten er borte – gjennom en patch, en oppgradering, en konfigurasjonsendring, en utskifting eller at maskinen fases ut.
De fleste team følger med på den første og den tredje tilstanden. Det er den midterste som rommer det faktiske arbeidet de neste seks ukene.
Den formelle terminologien er strengere enn dagligtalen. NIST beskriver et kompenserende tiltak som et tiltak en virksomhet innfører i stedet for et tiltak et grunnlagskrav stiller, og som gir tilsvarende eller sammenlignbar beskyttelse. Endepunktteam bruker uttrykket løsere, om ethvert midlertidig tiltak som kjøper tid. Begge betydningene krever den samme disiplinen: skriv ned hva tiltaket erstatter, og hva det etterlater.
En praktisk arbeidsflyt for kompenserende tiltak ved upatchede sårbarheter
Fire steg, og rekkefølgen gjør det meste av jobben.
Finn nøyaktig hvilke maskiner det gjelder
Et tiltak som dekker hele IT-miljøet, koster mer enn det burde og skjuler hva det beskytter. Et tiltak som bare dekker maskinene som kjører den sårbare versjonen, forblir proporsjonalt, og teamet fjerner det i det øyeblikket gruppen ikke lenger trenger det.
Det første spørsmålet er derfor ikke hvilket tiltak du skal bruke. Det er hvor mange endepunkter som har den berørte versjonen, og hvilke. En CVE på et dashbord forteller at IT-miljøet har et problem. Førti maskinnavn forteller hva det koster å holde problemet i sjakk.
Finn ut hva angrepet trenger
Mange sårbarheter er avhengige av forutsetninger du kan sette navn på: en tjeneste som kan nås fra nettverket, en funksjon ingen har slått av, en filtype som når fram til en sårbar parser, en konto med rettigheter den aldri trengte. Der sikkerhetsvarselet dokumenterer disse forutsetningene, kan du fjerne én av dem og redusere eksponeringen uten å røre programvaren. Leseruten i Outlook som angrepsvektor viser filtype-tilfellet: Den sårbare gjengivelseskoden i Word kjørte så snart Outlook forhåndsviste et ondsinnet dokument.
Der det ikke gjør det, bør du anta mindre. Noen svakheter trenger svært lite, og et sikkerhetsvarsel skrevet for et dusin produktversjoner sier sjelden hvilke av forutsetningene som gjelder for den versjonen du kjører.
Velg et tiltak som bryter angrepsveien
Det nyttige tiltaket bryter den konkrete kjeden. Det er ikke automatisk det som er raskest å rulle ut. De vanligste alternativene, omtrent i den rekkefølgen de brukes på endepunkter:
- Begrens hvem som kan nå tjenesten – en brannmurregel, segmentering eller å fjerne nettverksveien helt.
- Slå av den sårbare funksjonen, eller konfigurer den bort fra den tilstanden som kan utnyttes.
- Fjern faste lokale administratorrettigheter der angrepet, eller det som følger etter, krever forhøyede rettigheter – slik som med den videresendte passordhashen i CVE-2026-32202.
- Kontroller hva som kjøres – tillatelseslister (allowlisting) eller avvisningsregler for skriptverter og installasjonsprogrammer som angrep kjeder seg gjennom.
- Skjerp overvåkingen av de berørte maskinene, slik at et mislykket forsøk skiller seg ut fra støyen.
- Isoler eller fas ut enheten når ingenting annet senker risikoen nok.
Flere av disse ligger utenfor verktøyene for endepunktadministrasjon, og noen hører til nettverksteamet. Det er en del av poenget: tiltaket følger angrepsveien, ikke organisasjonskartet.
Navngi restrisikoen og veien ut
Det tiltaket etterlater, er restrisiko, og den trenger en eier og en beslutning – aksepter den for en angitt periode, forsterk tiltaket eller ta maskinen ut av drift.
Skriv deretter avslutningsbetingelsen ved siden av tiltaket, og gjør den til en utløser i stedet for en dato. Dette fjernes når leverandøren leverer versjon 4.2, eller når disse førti endepunktene rapporterer den rettede versjonen. Et tiltak som bare har en dato for gjennomgang, blir til permanent konfigurasjon som ingen kan forklare, og seks måneder senere fjerner noen det under en opprydding som handler om noe helt annet, fordi begrunnelsen ikke står noe sted lenger.
Slik støtter CapaOne kompenserende tiltak for upatchede sårbarheter
CapaOne dekker endepunktsiden av dette arbeidet: hvilke maskiner det gjelder, rettighetslaget og det å lukke sløyfen. Segmentering og nettverksfiltrering blir værende der de allerede hører hjemme.
CapaOne Security Monitor, en del av CapaOne-plattformen for endepunktadministrasjon, kobler CVE-er til endepunktene som har dem og gjør omfang, alvorlighetsgrad og konsekvens om til en risikoscore. Det svarer på steg én. Den rapporterer også sikkerhetskonfigurasjonen hvert endepunkt kjører med – antivirusbeskyttelse, diskkryptering, brannmurstatus, oppdateringsstatus for operativsystemet, eksponering av lokale administratorrettigheter og ventende omstarter. To av disse feltene har betydning for akkurat denne beslutningen: brannmurstatus og eksponering av lokale administratorrettigheter. Resten beskriver sikkerhetsstatus snarere enn angrepsveien, og det er viktig å holde forskjellen klar i det øyeblikket noen spør hvorfor et tiltak ble satt inn på én gruppe maskiner og ikke på en annen.
Privilege Manager tar seg av rettighetssteget. Den fjerner faste lokale administratorrettigheter og gir i stedet policybasert, tidsbegrenset heving av rettigheter, og policybaserte avvisningsregler dekker skall og usignerte installasjonsprogrammer.
Application Manager lukker sløyfen. Når leverandøren leverer en versjon som installeres uten problemer, går de berørte endepunktene gjennom den konfigurerte oppdateringsflyten etter policy, versjonsstatusen viser hvilke maskiner som har fått den rettede versjonen, og tiltaket fjernes på utløseren teamet skrev ned.
Gevinsten er ikke en kortere CVE-liste. Skanneren rapporterer det den rapporterer. Det som endres, er den midterste tilstanden: en oversikt du kan stå inne for, over hvilke endepunkter som er eksponert, hvilke som er begrenset og med hva, og hvilke som er utbedret. Det er den oversikten en revisor, et forsikringsselskap eller et styre faktisk spør etter.
Kompenserende tiltak hører hjemme i den samme arbeidsflyten som patching, ikke i et regneark ved siden av. Book en demo av CapaOne-plattformen for endepunktadministrasjon for å se koblingen mellom CVE-er og endepunkter og statusfeltene i et ekte IT-miljø.