Voor vrijwel elke organisatie is het lastig om zich effectief te verdedigen tegen cyberbedreigingen. Vaak kampen ze met personeelstekorten en beperkte budgetten, waardoor een goede balans tussen productiviteit en een optimale beveiliging ver te zoeken is. Daarom vijf best practices voor de implementatie van risico-gebaseerd patchbeheer.
Veel organisaties geven een hogere prioriteit aan vooruitgang, innovatie en productiviteit dan cybersecurity. Denk aan Twitter, waarvan de beveiliging volgens de voormalige beveiligingsbaas om precies die reden veel te wensen overlaat. Dit moedwillig beknibbelen op security is een groot bedrijfsrisico, zeker gezien de sterk toegenomen cyberaanvallen. Zelfs volwaardige security-teams kunnen het allemaal niet meer bijbenen. Wat hierbij kan helpen is het implementeren van een risico-gebaseerde patchbeheeroplossing.
Patching
Risk-based patch management (rbpm) houdt in dat het optreden tegen bedreigingen door middel van patching wordt beperkt tot bedreigingen met de hoogste prioriteit. Dit wordt bepaald op basis van zowel de externe bedreigingscontext als de interne beveiligingsomgeving van een organisatie.
Patching is op zichzelf al niet eenvoudig. Niet voor niets komen beveiligingsteams er nu soms al niet aan toe door de hoge werkdruk. Uit recent onderzoek blijkt dat maar liefst 71 procent van de it- en security-professionals patchen zowel tijdrovend als ingewikkeld vindt. Met een rbpm zijn de risico’s aanzienlijk te verlagen, zonder de werklast te verhogen.
Dit zijn vijf best practices om ermee te beginnen:
- Start met asset-discovery
Om effectief te kunnen patchen, moet je natuurlijk eerst weten wat er allemaal gepatcht moet worden. Elke rbpm-tool moet daarom beginnen met asset-discovery, ofwel het detecteren van devices. Welke bevinden zich op je netwerk? En welke eindgebruikersprofielen gebruiken ze? Voor de pandemie was dit relatief eenvoudig, de meeste bedrijfsmiddelen waren immers op kantoor. Nu worden ze overal en nergens gebruikt, en dit vraagt om een moderne benadering van assetmanagement. Een methode waar ze overal in kaart gebracht, beveiligd en onderhouden worden, zelfs als ze offline zijn.
- Zet iedereen op één lijn
Ondanks de beste bedoelingen zijn it-operations- en beveiligingsteams vaak met elkaar in conflict. Dit komt door de aard van hun rollen en aandachtsgebieden. Rbpm slaat een brug tussen deze organisaties door te eisen dat externe bedreigingen en interne beveiliging samen worden bekeken. Voor een optimale samenwerking moeten beide teams over dezelfde informatie beschikken en de risicoanalyses erkennen. Als iedereen op één lijn zit, is prioriteit te geven aan de meest kritieke kwetsbaarheden voor de gehele organisatie, in plaats van dat it-operations het gevoel heeft altijd achter de feiten aan te lopen.
- Gebruik een sla voor patchbeheer
Beveiligings- en it-operations teams moeten samenwerken om een effectieve rbpm-oplossing te creëren. Toch is dat makkelijker gezegd dan gedaan. Ze moeten er namelijk ook toe in staat worden gesteld en gemotiveerd raken om dit te doen. Dat doe je door middel van een service-level agreement (sla) voor patchbeheer tussen de beveiligings- en it-operationsteams. Dit voorkomt oeverloos gepraat en het helpt om de patchprocessen te standaardiseren. In zo’n sla moeten afdelingsdoelen en bedrijfsbrede doelen voor patchbeheer worden vastgelegd, maar ook best practices en onderhoudsvensters die voor alle partijen acceptabel zijn.
- Gebruik pilotgroepen voor patching
Met een goede rbpm-strategie kunnen it-operations en beveiligingsteams snel en in realtime kritieke kwetsbaarheden identificeren en die zo snel mogelijk patchen. Die snelheid mag echter geen nevenschade veroorzaken, zoals een overhaaste patch die bedrijfskritische software crasht of andere ongewenste problemen veroorzaakt. Pilotgroepen zijn hiervoor de oplossing. Pilotgroepen bestaan uit de belangrijke belanghebbenden die patches in een live omgeving kunnen testen voordat ze breed worden uitgerold. Idealiter weerspiegelen ze de bredere groep van gebruikers die de patch gaan ontvangen. Deze live-tests zijn vaak nauwkeuriger dan een testomgeving, waarin het vooralsnog onmogelijk is om de potentiële downstream-gevolgen van patches perfect te kunnen vaststellen. Als de pilotgroep een catastrofale fout identificeert, kan die snel worden verholpen met minimale gevolgen voor de organisatie. Hierbij is het belangrijk om pilotgroepen vooraf te vormen en op te trainen, zodat dit proces de voortgang van patches niet belemmert.
- Omarm automatisering
Rbpm helpt om kwetsbaarheden efficiënt en effectief te verhelpen en tegelijkertijd om de werklast voor IT-personeel te verlichten. Toch is het nog steeds een zware klus als het patchen handmatig wordt gedaan. Een RBPM-tool met automatiseringsmogelijkheden kan het werk drastisch versnellen, bijvoorbeeld door 24 uur per dag kwetsbaarheden te verzamelen, ze in context te plaatsen en prioriteiten te stellen. Dit kan zelfs het meest getalenteerde IT-team niet evenaren. Met automatisering is het bovendien mogelijk om een patch-implementatie te segmenteren om te testen op de resultaten en downstream-gevolgen, bijvoorbeeld op basis van verschillende pilotgroepen. Verder is het automatisch identificeren, prioriteren en installeren van patches, zonder overmatige menselijke handelingen, zeer effectief om de cyberrisico’s te verlagen.
Om nog eens terug te grijpen op het eerdergenoemde voorbeeld van Twitter: bij ongeveer dertig procent van de laptops van het bedrijf werden automatische software-updates geblokkeerd! Naast andere beveiligingsproblemen, resulteerde dit in meer dan vijftig incidenten bij Twitter in het afgelopen jaar. Reden temeer dus om automatisering te omarmen.
Nuances
Een rbpm-oplossing is altijd afhankelijk van de specifieke nuances van een organisatie. Denk aan het type gebruikers, de gebruikte softwareoplossingen, de werkprofielen, het publieke imago van de organisatie of de waarde van de bedrijfsgegevens. Daarom bestaat er ook geen standaard rbpm-strategie. Toch bieden deze best practices een goede basis voor elk rbpm-programma, waarmee een organisatie zijn beveiliging op een hoger niveau kan brengen.
Hyperbolen en extrapoleren op lucht vergeet SWA hopelijk niet de memo over duurzaamheid want ook de academische wereld van HPC wordt geraakt door hogere energieprijzen en CO2-footprints. Wat betreft Linux ging het meer om de keus van de distributie want in de wereld van HPC geldt dat overdaad schaadt als het om de bogus mips gaat. Oja, ik stomme architect die ooit de tuning deed van HPC systemen heb er geen verstand van maar I/O is nog vaak de bottleneck in het extrapoleren van het uitschalen.
Ja ja en nu is meneer OudLid ineens iemand die HPC-tuning gedaan heeft. Het wordt met de post fantastischer en ongeloofwaardiger!
Btw, IO is niet ‘het probleem’, leer over Amdahl. Er zijn meerdere bronnen die latency introduceren dan alleen IO. Ook voor die cloud-rakkers die denken dat ‘als je maar in de cloud zit, dan is alles oneindig.’ [https://www.csl.cornell.edu/~delimitrou/papers/2018.cacm.amdahlsTail.pdf]
Ik snap er natuurlijk niks van maar HPC gaat om snel data te verwerken, de berekeningen hoeven niet complex te zijn. Centralisatie van data via de cloud heeft dan ook een voordeel als we kijken naar nieuwe workloads in bijvoorbeeld fintech, de gaming en media sector. En als tijd geld is dan gaat optimalisatie om efficiëntie. Afstemming van een workload op de hardware betekent volgens de wet van Amdahl het wegnemen van vertragende bottlenecks. En ja, dat kan soms ook de code van onderliggende drivers zijn want overdaad schaadt als we kijken naar de microkernels.
Maar stoor je niet aan mij SWA want inefficiënte code vraagt om meer infrastructuur en deze is niet gratis. Ook niet in de cloud waar je moet betalen voor I/O welke nog even duur is als in de tijd van de plug-compatibele mainframe van Amdahl.
“Ik snap er natuurlijk niks van maar HPC gaat om snel data te verwerken, de berekeningen hoeven niet complex te zijn.”
In die eerste zin staat dus meteen al een onjuiste aanname en je interpreteert Amdahl foutief. you are clearly out of your depth dude!
enfin, live automatisch patchen behoeft geen enkel probleem te zijn en hangt sterk af van je gekozen software stack. het kan verkeren!
QED (google dat maar eerst eens want dat is ook maar wat snel data verwerken volgens jouw, as in, “pun intended” en dus over en uit wat mij betreft met jouw)!
Clearly out of my depth wist ik niet dat de P in HPC voor patchen staat, mijn vergissing dat ik dacht dat het om de verwerking van data ging. Ook stom van me dat ik bij parallele verwerkingen dacht aan de ‘message passing’ welke veelal om de afstemming tussen hardware en software gaat als we het over de stack hebben en niet alleen een besturingssysteem. Begrijp dat tweaking en tuning aangaande de juiste parameters tegenwoordig automatisch gaat. Vroeger was dus niet alles beter Dino want toen moest je nog aan best veel knoppen draaien.
Mee eens oudlid. Ik weet niet anders als HPC staat voor High Performance Computing. Sterker nog, ik kan HPC in combinatie met patchen niet eens eenvoudig terug vinden, behalve dan patches voor High Performance Computing.
Een hoop bla verder, maar binnenkort weer eens updaten naar Red Hat compatible 8.8 en 9.2 is kleine moeite en bespaart je veel werk achteraf. En is hpc patchen niet extra simpel omdat je nodes gecontroleerd uit je cluster kan halen tbv onderhoud en een nieuwe queue kan maken voor het testen.
In korte cycli waarde toevoegen, maar als je dat doet door in overleg OS features toe te voegen en kwetsbaarheden te verwijderen.. ist weer niet goed.
Op zich wat paradoxaal, mijn pleidoor voor updaten terwijl ik steeds stel dat vroeger alles beter was 🙂