Blog Van gepland patchbeheer naar realtime patchbeheer

Exploits verplaatsen zich nu in uren, niet in dagen. De vraag is niet óf uw bedrijfsvoering wordt verstoord, maar of dat gebeurt op uw voorwaarden of op die van hen.

Een paar weken geleden zat ik midden in een vergadering toen mijn laptop besloot dat het wachten voorbij was. Ik had dezelfde patch-update iets te vaak uitgesteld. Precies daar, midden in een zin, sloot het systeem af. Geen meldingen meer met "herinner mij later". Geen optie tot uitstel.

Het punt is dat ik niet eens boos kon worden. Ik pakte mijn telefoon, belde opnieuw in bij de vergadering en ging verder. Want dat beleid, dat zojuist mijn gesprek onderbrak, is exact hetzelfde beleid waarvan ik securityleiders vertel dat ze het moeten invoeren: verstoring afdwingen op uw eigen voorwaarden, niet op die van een ander.

Direct patchen betekent dat u kritieke kwetsbaarheden behandelt als actieve incidenten. Dit meet u in uren die nodig zijn om te reageren, niet in vaste dagen op een kalender.

Als ik onze klanten vraag om hun aanpak van patching te heroverwegen, dan moet ik daar zelf ook naar leven.

Dit is hoe ik dit tegenwoordig bespreek met securityleiders.

De schuifregelaar in mijn hoofd

Ik bedacht deze metafoor tijdens een lunchgesprek met een securityleider bij Cisco Live, en het laat me sindsdien niet meer los. Stel u een schuifregelaar voor. Aan de ene kant staat de operationele impact: het risico dat uw bedrijfsvoering wordt verstoord. Aan de andere kant staat een security-incident: het risico dat u wordt gehackt. Elke organisatie bevindt zich ergens op die lijn, of ze het nu doorhebben of niet. De positie op die lijn laat precies zien hoe zij over risico's denken.

Dit is wat de meeste organisaties al jaren laten zien. Wanneer u een patchcyclus van 90 dagen hanteert (en ik zal eerlijk zijn, dat was tot voor kort ook ons tempo bij Insight), neemt u een gok. U zegt eigenlijk: "Ik gok liever op een cybersecurity-incident dan dat ik het risico neem om de productie stil te leggen voor een patch." U heeft de schuifregelaar stevig aan de kant van de operationele bescherming gezet. U heeft het gevoel dat een datalek de minst waarschijnlijke uitkomst is, dus optimaliseert u tegen de verstoring die u ziet aankomen.

Ik begrijp dat instinct volkomen. We houden van onze processen. We houden van onze wijzigingsvensters, onze CAB-beoordelingen en onze controles. Ze zijn er om ons veilig te houden en IT-operations voorspelbaar te maken. Maar Mythos en andere geavanceerde AI-modellen hebben de kansen bij die gok stilletjes veranderd. Veel leiders hebben hier nog niet op gereageerd en hebben hun risicoschuifregelaar nog niet verplaatst.

Het deel dat iedereen mist

Dit is wat mijn eigen manier van denken heeft veranderd. Wanneer de tijd tussen het bekendmaken van een kwetsbaarheid en de daadwerkelijke cyberaanval krimpt van dagen naar uren (en in de nabije toekomst naar minuten), is een datalek niet langer de onwaarschijnlijke uitkomst. Het wordt de onvermijdelijke uitkomst.

En dit is het punt waar u echt even bij stil moet staan: een datalek is ook een productie-uitval. U voorkomt de verstoring niet door niet te patchen. U ruilt de ene soort verstoring alleen in voor de andere.

Wanneer u patcht op uw eigen voorwaarden, is de verstoring gepland en beheersbaar. U heeft het ingepland. Uw mensen staan stand-by. U heeft rollback-tools klaarstaan. Als er iets misgaat, lost u het op en gaat u verder.

Wanneer u wordt gehackt, heeft u nog steeds uitval, maar nu is deze ongepland. Het is onverwacht, het gebeurt om twee uur 's nachts wanneer u niet de juiste bezetting heeft en het is kwaadaardig. De persoon die de uitval veroorzaakt, heeft er alle belang bij dat dit zo lang mogelijk duurt en niet om u te helpen weer overeind te krabbelen. Dat is de hele omslag: gepland en beheersbaar versus onverwacht en kwaadaardig.

U kiest er niet meer voor of uw bedrijfsvoering wordt verstoord. U kiest alleen nog maar op wiens voorwaarden het gebeurt.

Twee benaderingen, dezelfde kwetsbaarheidy

Dit is de reden waarom ik patching ben gaan beschrijven als een incident en niet meer als een onderhoudstaak. Zelfde CVE, compleet andere houding.

In het onderhoudsmodel is de centrale vraag: "Zal deze patch de productie verstoren?" U meet succes aan het percentage bijgewerkte bedrijfsmiddelen en de doorlooptijd bedraagt weken of maanden. In het incidentmodel draait de vraag om: "Wat is de impactradius als we dit niet patchen?" WU meet succes aan de gemiddelde hersteltijd en de doorlooptijd bedraagt uren. Wanneer kwaadwillenden binnen enkele uren toeslaan, is een maandelijks onderhoudsvenster geen proces meer; het is een directe bedreiging die uw operationele risico vergroot..

We praten nu over het implementeren van patches via dezelfde workflow die u verwacht bij een traditioneel cybersecurity-incident: detecteren, triageren, indammen, herstellen en valideren. We registreren de dreiging via continu beheer van blootstelling aan risico's, lokaliseren de kwetsbaarheid binnen de gehele IT-omgeving, gebruiken machine learning om de kans op daadwerkelijk misbruik in uw specifieke infrastructuur te berekenen en valideren dit met continu penetratietesten. Bij een hoge tot kritieke kwetsbaarheid start een SLA-tijdlijn en komen de responsteams direct in actie.

Dit gaat niet over het patchen van alles op het moment van publicatie. Het gaat over het identificeren van de kleine selectie van kwetsbaarheden die een reëel, exploiteerbaar risico vormen voor uw omgeving. Deze specifieke risico's vereisen directe actie met de urgentie van een live incident.

Wat betekent dit concreet op een dinsdagochtend?

In plaats van te wachten op de volgende patchronde, triggert een kritieke, extern blootgestelde kwetsbaarheid direct een geautomatiseerde workflow. Het securityteam signaleert het risico, valideert de blootstelling en start de patching binnen uren. Dit is exact dezelfde procedure als bij een actieve cyberaanval.

De contra-intuïtieve winst

Als operationsmanager gaan uw alarmbellen nu af: vaker patchen betekent meer verstoring, toch?

Het tegendeel is waar. Dit is het argument dat Cisco’s moeten delen met operations en businesspartners. Patchvensters lopen meestal uit omdat we patches opsparen om vervolgens tientallen updates tegelijk in verschillende subsystemen te pushen. Wanneer u overstapt naar realtime updates, patcht u één getroffen module afzonderlijk. De kans op onvoorziene fouten in gekoppelde systemen daalt drastisch. U neemt kleinere, gecontroleerde, gerichte stappen en vermindert daarmee het algehele operationele risico.

Dit is een verandering in uw bedrijfsvoering

Ik zal niet beweren dat de technologie de grootste uitdaging is; dat is het niet. De uitdaging is organisatorisch. U moet bereid zijn om de traditionele benadering van patchbeheer los te laten. U moet architectuur met hoge beschikbaarheid in uw systemen bouwen. Grote, monolithische applicaties functioneren niet binnen dit model zonder dagelijkse risico's voor die kritieke bedrijfsprocessen. Dit vereist een nieuwe visie op architectuur en dit gesprek moet verder gaan dan alleen het securityteam.

Ik laat u achter met dezelfde vraag waar ik zelf steeds op uitkom. U krijgt te maken met enige downtime; dat deel is niet meer optioneel. De enige keuze die u heeft, is of deze verstoring gepland is en plaatsvindt op uw voorwaarden, of ongepland op de voorwaarden van de

Bij Insight zijn we zelf de eerste klant voor deze ingrijpende verandering in patchbeheer van IT-systemen. We stonden voor dezelfde existentiële verschuiving als iedereen, hebben onze security en IT-operations hierop heringericht en brengen deze expertise nu naar onze klanten. Het maakt niet uit wie toegang heeft tot Mythos; het model bestaat. Er komen vergelijkbare, krachtige modellen aan en sommige daarvan worden niet door de goeden ontwikkeld.

Het gaat erom of u erkent dat de verdediging van uw organisatie fundamenteel is veranderd en dat u uw schuifregelaar verplaatst voordat een externe partij dat voor u doet.