Patchen is niet spannend en het levert zelden complimenten of promoties op. Toch is het in elke omgeving een kritieke risicopreventiefunctie die bij veel organisaties onderbelicht is. Totdat zij worden getroffen door een kostbare storing. Uit recent onderzoek blijkt dat zestig procent van de cybersecurity-kraken het gevolg is van niet-gepatchte kwetsbaarheden.
Waarom worden veel systemen binnen organisaties niet regelmatig gepatcht, terwijl er juist zoveel risico’s aan verbonden zijn? Zoals voor veel ondermaats presterende omgevingen geldt, heeft de oorzaak praktische, emotionele en operationele facetten.
- Praktisch
In een wereld waar we op afstand werken, zijn talloze beveiligingsbedreigingen. Toch komt patchen vaak pas op de tweede plaats, naast andere technieken tegen bedreigingen, zoals het toevoegen van nieuwe beveiligingsprotocollen. Er zijn daarnaast veel concurrerende prioriteiten voor de it-afdeling, waaronder het strategisch in kaart brengen van nieuw beleid en procedures voor werknemers op afstand en het helpen van de C-suite om de gewenste bedrijfsresultaten te realiseren.
- Emotioneel
Ten aanzien van patches heerst de angst dat ze de workflow mogelijk kunnen verstoren, zeker nu zoveel organisaties zich in een grootschalige transitie bevinden naar een meer remote/hybride werkomgeving. Beveiligings- of operationeel personeel wil geen misstappen maken, dus blijft het patchen doorgaans achterwege.
- Operationeel
Een belangrijke succesfactor voor patching is weten welke kwetsbaarheden de grootste bedreiging vormen, zodat die de juiste prioriteit kunnen krijgen. Veel organisaties worstelen echter met het beheren van de verscheidenheid aan applicaties in hun omgevingen, de inconsistente frequentie van updates en patches, en de vele softwarewijzigingen die operationele gevolgen voor gebruikers kunnen hebben.
Slimmer en sneller patchen
Door de grote vlucht die werken op afstand heeft genomen, zijn de zorgen over patchen gegroeid. Beveiligings- en operationele teams worden geconfronteerd met externe apparaten die zich buiten de netwerkperimeter bevinden en vol kwetsbaarheden kunnen zitten. Secops-zichtbaarheid in de apparaten van externe werknemers was voorheen niet zo’n prioriteit, maar in deze nieuwe werkelijkheid worden de aanzienlijke hiaten in effectieve patching blootgelegd.
Hoe kunnen organisaties deze barrières overwinnen om van patching een soepel lopend onderdeel van secops te maken en niet weer een lastig onderwerp tijdens teamvergaderingen? Patching technologieën bestaan al jaren, maar toch worstelen bedrijven nog steeds met het verhelpen van kwetsbaarheden. Dat is niet zozeer een technologische uitdaging voor bedrijven, maar een uitdaging van proces, politiek en operationele impact. Hierbij draait alles om de volgende strategische verbeteringen.
- Betrouwbaarheid van patches
Geen enkele beheerder kan het effect van updates op zijn omgeving volledig testen. Doorgaans proberen teams de impact te valideren door middel van testsystemen en gebruikerspilotgroepen – waardoor updates worden vertraagd tot het punt waarop een bedreiging escaleert. Vooruitgang op het gebied van ‘patch performance intelligence’ kan deze vertragingen verhelpen en patching versnellen op basis van crowdsourced telemetrie van patch-prestaties, gecombineerd met sociaal sentiment, verzameld via populaire sociale-media-outlets. Hiermee is secops in staat om sneller beslissingen te nemen over waar de testinspanningen zich op moeten richten om de efficiëntie te maximaliseren en operationele gevolgen te vermijden.
- Risicogebaseerde prioritering
Veel organisaties prioriteren herstelwerkzaamheden op basis van het risico dat leverancier eraan toekent. Door deze aanpak blijven veel kwetsbaarheden echter ongepatcht, en die hebben die daarmee een hoger risico om te worden misbruikt. Het is daarom van cruciaal belang dat de kennisbasis op dit vlak wordt uitgebreid. Door aanvullende statistieken te verzamelen van ‘bekende uitgebuite’ kwetsbaarheden heeft secops meer gegevens beschikbaar om patching te prioriteren op basis van reële risico’s voor de organisatie.
- Geautomatiseerde aanpak van kwetsbaarheden
Het omzetten van kennis en prioritering in actie – én rekening houdend met de beschikbare tijd van secops – betekent dat een hogere mate van automatisering noodzakelijk is. De enige manier om externe apparaten in de cloud effectief te patchen en beveiligen, is door meer automatisering aan het proces toe te voegen. Automatisering kan met behulp van machine learning verkregen meetgegevens proactief detecteren, diagnosticeren en automatisch configuratiewijzigingen, prestatie- en beveiligingskwetsbaarheden herstellen, nog voordat ze daadwerkelijk bedreiging worden.
- Patch compliance
Service level agreements (sla’s) zijn belangrijk vanuit een operationeel perspectief, maar voor het verhelpen van kwetsbaarheden zijn ze van cruciaal belang. Organisaties worstelen om bedreigingsactoren voor te blijven en moeten de blootstelling aan kwetsbaarheden nauwkeuriger bijhouden om ervoor te zorgen dat ze hun risicovenster verkleinen. Het is van cruciaal belang om een nauwkeuriger perspectief op patchniveau te krijgen, dat aansluit op de cve’s (common vulnerabilities and exposures), over hoelang de organisatie is blootgesteld en welke bedrijfsmiddelen buiten de sla’s vallen, om het algehele risico te verlagen.
- Functieoverschrijdende gesprekken
Secops is een nuttige uitdrukking, maar in werkelijkheid hebben de teams verschillende denkwijzen bij het aanpakken van data- en risicoproblematiek. De gemeenschappelijke basis die ze helpt om samen te werken en bedreigingen tot een minimum te beperken, is betere, objectieve informatie over het risico van kwetsbaarheden. Daarom is het verzamelen van bedreigingspatronen door middel van machine learning – gegevens die zijn te delen – een belangrijke factor die patching kan verbeteren. Betere gegevens leiden dan tot geïnformeerde beslissingen over patchprioritering, waardoor beide teams meer vertrouwen krijgen in het feit dat de bedreigingen met het hoogste risico het eerst worden aangepakt.
Belemmeringen wegnemen
Het is zeker mogelijk om de praktische, emotionele en operationele barrières voor verbeterde patching weg te nemen. Door gebruik te maken van geautomatiseerd herstel van kwetsbaarheden wordt de voortdurende strijd tussen tijd en prioriteiten van teams geëlimineerd. Daarnaast kan je door middel van machine learning informatie verzamelen over bekende exploits op basis van crowdsourced telemetrie, waardoor secops meer inzicht krijgt in de daadwerkelijke risico’s. Hiermee kunnen ze met een grotere betrouwbaarheid te werk gaan, omdat ze meer kennis tot hun beschikking hebben. Deze verbeterde gegevens over de betrouwbaarheid van patches leveren vervolgens automatisch bruikbare informatie, zodat teams sneller kunnen reageren op bedreigingen en de ‘time to patch’ kunnen verkorten, waardoor de operationele impact afneemt.
Napoleon is dood, lang leve Napoleon! Het voorschrijdend inzicht aangaande het patchen is nog niet het verhelderende licht dat het einde van de tunnel aangeeft of de koplampen van een aanstormende trein. Zo is bijvoorbeeld het aanbrengen van een patch een wijziging welke impact kan hebben op het functioneren van de service. Sommige functionaliteiten zijn namelijk geschreven op ‘design flaws’ welke later gecorrigeerd worden met een patch waardoor je allerlei workarounds aan moet brengen om het kaartenhuis overeind te houden. Even een server met n-op-n relaties aanpassen is dan ook wat anders dan een endpoint wijzigen want door de uitval van één server kan een heel land stil komen te staan. En uiteindelijk is patchen meer gelijk aan vaccineren dan aan pleisters plakken, laatste kun je namelijk eenvoudig verwijderen maar om de injectie van code in je systeem ongedaan te maken moet je nog weleens terugreizen in de tijd middels een snapshot. Een risicogebaseerde oriëntiering gaat om kijken welke klachten de buurman krijgt na het patchen.
@Een Oulid
En daarom bestaan er test-systemen. Niet simpelweg om een nieuw stukje Agile-functionaliteit te testen, maar in de ERP context vooral om regressie testen mee te doen, bijvoorbeeld na een package/transport met security patches. Terugreizen in de tijd in ERP is geen realistische optie want in de werkelijkheid wordt er nooit een flashback uitgevoerd op een produktie systeem vanwege de afhankelijkheid van transactie data met andere systemen.