Dreigingsactoren kunnen vrij snel handelen. Er zijn ontzettend veel kwaadwillenden die vanuit de schaduw op zoek zijn naar de volgende kwetsbaarheid die ze kunnen uitbuiten. Soms vinden ze een niet door white-hat onderzoekers of leveranciers geïdentificeerde kwetsbaarheid - wat resulteert in een zero-day exploit - maar meestal zoeken ze naar updates die openbaar zijn gemaaktdoor leveranciers om veranderingen te identificeren die zich hebben voorgedaan in de code. Op dit punt begint een race. De race om te zien of ze een functionerende exploit kunnen creëren voordat organisaties over de hele wereld de kwetsbaarheden kunnen dichten.

Er zijn verschillende recente voorbeelden die aantonen hoe snel dreigingsactoren kunnen handelen:

  • BlueKeep (CVE-2019-0708): De kwetsbaarheid die zoveel hype kreeg als de volgende potentiële WannaCry werd op 14 mei 2019 verholpen. Door de beruchtheid ervan kregen we de kans om de exploit-ontwikkeling in actie te zien, aangezien meerdere onafhankelijke onderzoeksteams in slechts 14 dagen werkende exploits realiseerden (op 28 mei 2019 toonden meerdere proof-of-concept (POC) video's volledige exploit van de kwetsbaarheid). Het duurde enige tijd voordat dreigingsactoren de exploits begonnen te gebruiken, maar er is veelvuldig actief gebruik van gemaakt in crypto-mining.
  • ZeroLogon (CVE-2020-1472): De kwetsbaarheid in NetLogon werd verholpen in een update op 11 augustus 2020. De oplossing vereiste enkele wijzigingen in de werking van NetLogon, dus rolde Microsoft de update uit door de kwetsbaarheid te verhelpen en de verandering in de auditmodus te laten beginnen. Microsoft adviseerde dat het afdwinging zou aanzetten als onderdeel van de februari 2021 Patch Tuesday-release, maar organisaties konden het ook eerder aanzetten zodra ze er klaar voor waren door een register-instelling te veranderen. Op 15 september 2020 kwam het nieuws over POC's naar buiten en op 18 september gaf het Department of Homeland Security de Noodrichtlijn 20-04 vrij, waarin overheidsinstellingen het advies kregen om met ingang van maandag 21 september 2020 de afdwinging van de update te implementeren en in te schakelen. Het blijkt dat deze urgentie op zijn plaats was, omdat de eerste exploits vóór eind september in de praktijk werden gedetecteerd.
  • .Net\SharePoint RCE Flaw (CVE-2020-1147): In eerste instantie verholpen in de juli Patch Tuesday-release van 14 juli. Op 21 juli circuleerde de POC exploit code. Deze update is opnieuw uitgebracht als onderdeel van de oktober Patch Tuesday-release.

In alle drie de gevallen - van release tot beschikbaarheid van exploit code - was het bereik ongeveer 14 tot 28 dagen. Dit komt toevallig overeen met de bevindingen in het 2016 Verizon Data Breach Investigations Report, waarin wordt aangegeven dat 50% van de exploits zal plaatsvinden in de twee tot vier weken voorafgaand aan de release door de leverancier. De bevindingen van “Zero Days, Thousands of Nights”, een door RAND Corporation uitgebracht rapport, geven een mediaan van 22 dagen aan als periode voor het exploiteren van een kwetsbaarheid. Op basis van dit bewijs wordt aanbevolen om een SLA te richten op het oplossen van kwetsbaarheden in 14 dagen of minder, wat ons naar de volgende reeks uitdagingen brengt.

Waarom is een SLA van 14 dagen moeilijk te realiseren?

Kwetsbaarheids- en patchbeheer oplossingen zijn al meer dan een decennium op de markt en dit zijn vrij volwassen oplossingen. Technologie om kwetsbaarheden te identificeren en er snel over te rapporteren vormt de minste uitdaging.

De grotere uitdaging zit onder meer in het feit dat het kwetsbaarheidsherstelproces zich uitstrekt over meerdere teams en technologie stacks. Het proces zit boordevol handmatige stappen, testen en operationele effecten, naast enkele basiscommunicatie-uitdagingen die voor vertraging zorgen. Ik kan uit mijn hoofd talloze bedrijven noemen die SLA's van 14 dagen of korter hebben behaald op het gebied van kwetsbaarheidsherstel. In een aantal gevallen betreft dat grote ondernemingen in productie, detailhandel en meer. Wat hebben ze gedaan om dit te bereiken, aangezien ze dezelfde technologie gebruiken als sommige bedrijven die nog steeds op 30-daagse cycli zitten?

De vier grootste uitdagingen op het gebied van kwetsbaarheidsherstel:

  • Het overbruggen van de kloof tussen beveiliging en operationeel: Laten we eerlijk zijn. Het komt niet vaak voor dat beveiliging en operationeel echt "goed met elkaar kunnen opschieten". Beveiliging spreekt de taal van Risk en CVE, terwijl operations het heeft over operationeel en patchen. Het verhelpen van een CVE heeft een operationele impact omdat de patch iets kapot heeft gemaakt. Het operationele team heeft daar veel last van. Wanneer de dagelijkse activiteiten de snelheid beperken waarmee beveiligingskwesties kunnen worden opgelost en er doet zich een incident voor, heeft het beveiligingsteam daar veel last van.
  • Risico gebaseerde prioritering is cruciaal om eerst de juiste kwetsbaarheden te verhelpen: Er zijn veel gevallen waarin de ernst van de leverancier en de CVSS-score niet de meest urgente zaken weerspiegelen. Er zijn veel voorbeelden van een zero-day die wordt opgelost, terwijl de urgentie van de leverancier slechts als "belangrijk" beoordeeld wordt en de CVSS-score 7.0 of zelfs minder is. Extra statistieken en metadata zijn nodig om ervoor te zorgen dat de meest risicovolle items worden gedicht. Wat wordt er bijvoorbeeld actief uitgebuit?
  • Inzicht in de betrouwbaarheid van updates: Terug naar de SLA en patchtijd voor kwetsbaarheidsherstel. Een van de grootste barrières om snel te handelen is het onvermogen om effectief te testen. Beheerders hebben twee keuzes: 1) Hun testen proberen op te schalen om er zeker van te zijn dat ze geen operationele impact hebben, of 2) de tijd laten meewegen in hun testproces en zaken zullen zichzelf oplossen als je maar lang genoeg wacht. Het probleem:, dreigingsactoren vinden het geweldig als je wacht. Had ik al vermeld dat uit hetzelfde RAND-rapport blijkt dat de gemiddelde houdbaarheid van een exploit zeven jaar is? Blijkbaar zijn sommige problemen heel lang onopgelost gebleven, waardoor er veel ‘laaghangend fruit’ overblijft voor dreigingsactoren.
  • Patch compliance: Er is veel variatie in compliance rapporten, maar de meeste houden rekening met het moment waarop uw onderhoudsvenster wordt geopend, niet met het moment waarop de update voor het eerst beschikbaar werd gesteld. Microsoft, Adobe en Oracle brengen de meeste beveiligingsupdates uit op een consistente en voorspelbare datum, maar Google, Apple, Mozilla en nog veel meer bedrijven doen dat niet. Het volgen van compliance voor een kwetsbaarheid vereist een heroriëntatie naar een meer granulair niveau om rekening te houden met de continue leveringsaard van hedendaagse software.

Als patchbetrouwbaarheid, risico gebaseerde prioritering en patch-compliance uitdagingen zijn die u ervan weerhouden om een SLA van 14 dagen te behalen voor kwetsbaarheidsherstel, dan heeft u wellicht behoefte aan een oplossing die verder gaat dan uw huidige patching-oplossing. Ivanti® Neurons for Patch Intelligence is ontworpen met het oog op deze uitdagingen. Bekijk het vandaag nog.