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
- Risicogebaseerde prioritering
- Geautomatiseerde aanpak van kwetsbaarheden
- Patch compliance
- Functieoverschrijdende gesprekken
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.
Reacties
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.