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.
@datouwelid
“En ik weet dat het voor een kwispelende SWA allemaal te wollig wordt als je geconditioneerd bent op het belletje.”
joh, je kent me niet dus hou eens op te wauwelen over mensen die je helemaal niet kent…
Die Dino, altijd goed in de ‘blame meme’ want de architect kan ontwerpen wat hij/zij wil maar als dingen anders geïmplementeerd worden dan bedoeld dan heb je de papieren werkelijkheid en Schaduw IT in realiteit. Misschien was FTP service wel gecontracteerd maar deze was niet gedocumenteerd en zeker niet volgens de best practice geïmplementeerd. Wat betreft een ijsberg is de asset discovery dan ook bijna net als vroeger alleen met een andere vraagstelling als ik kijk naar de tools. Door IP fingerprinting is een hacker beter geïnformeerd dan de CISO en dan laat ik het achterstallige onderhoud waar rood lint omheen zit nog even buiten beschouwing.
Want on-topic in risk-based patch management schijnt er nog zoiets te zijn als historische incompabiliteit want de ouwe jongens die hun eigen loket blijven verdedigen vergeten in de ‘blame meme’ dat een coherente en consistente verzameling principes alleen uitwisselbaar zijn als het om een standaard gaat. Want architectuur is tenslotte meer dan alleen de infrastructuur knuffelen en ik schreef zo’n 10 jaar geleden al over het verschil tussen beheersbaar en beheerbaar want het in toom houden van systemen is lastig als je de teugels uit handen hebt gegeven.
Vroeger was het niet beter maar overzichtelijk met één repository waar release management de regie over had want kijkend naar ontwerpen op basis van alle specificaties met het MoSCoW-principe is luxe als de overbodigheid van een warme werkkamer sinds we de regie over de gaskraan uit handen hebbben gegeven. In deze ‘blame meme’ valt Brussel niks te verwijten want de nieuwe realpolitik van een ander jouw oorlog uit laten vechten is tenslotte ook een vorm van uitbesteding. Oja, zoals dat ik Twitter als een dienst zie zo zie ik natuurlijk ook Github als een dienst.
Hoezo ken ik je niet SWA? Misschien dat ik je niet persoonlijk ken maar je reacties geven me een beeld van je instelling als het om de rol van een beheerder gaat die servers knuffelt. Seen that, been there & done it want kwispelend als een geconditioneerd hondje doe je wat leverancier je zegt te doen zonder eigenlijk te weten wat je oplost met patches. Als ik een achterdeurtje wil dan weet ik wel hoe ik deze zo snel mogelijk krijg, on-topic gaat het om risk-based patch management:
https://openssf.org/oss-security-mobilization-plan/
Vertrouwen is goed maar controle is nog altijd beter als we kijken naar een controle op de code, het is hiermee tenslotte als met de voorwaarden die ook niemand leest. Als wauwelende gek schreef ik jaren geleden daarom al eens iets over de sores over de sources omdat open niet gelijk is aan veilig. En zoiets als gratis bestaat niet in de ict als we kijken naar economische en politieke belangen want door de hond gebeten of de kat gekrabd is er veel onderling wantrouwen over de code.
“Misschien dat ik je niet persoonlijk ken maar je reacties geven me een beeld van je instelling als het om de rol van een beheerder gaat die servers knuffelt. ”
Ik ben niet alleen een beheerder bijvoorbeeld en ik heb zeker al niet met maar wat servers te maken. Misschien heb je het niet door, maar je komt wel heel arrogant over met je wauwerige posts en ongefundeerde aannames.
Tis je gelukt oudlid. Zoveel gek gewauwel trek ik niet meer.
Maar wie weet je collegas nog wel :
https://www.computable.nl/artikel/blogs/cloud-computing/7440331/5260614/cloud-fomo-vermijden-met-on-premise-infrastructuur.html
Die collega’s ken je ook vast vanuit hun rol en seen that, been there enzo..
Als software/cloud architect merk ik dat men het vooral heeft over het patchen van operating systemen en standaard software.
Zeker als je zelf ook software maakt en levert krijgt patchbeleid een geheel andere dimensie. Dit omdat een stuk software uit verschillende onderdelen bestaat zoals front-end, API laag, back-end, databases, etc.
One does not simply install patches in software development….
Het aantal dependencies van een softwarestack gaat gemakkelijk over de 200 heen.
Wat is mijn punt? Geen idee, maar patch beheer is niet 1 ding of discipline of verantwoordelijkheid van 1 afdeling…
Ha Henri,
Heb je dat bij eigen software ook? Dat een zootje ongeregeld het allemaal te lang vindt duren en ze zelf maar aan de slag gaan? Shadow development 😛
En 200 dependenties, da’s best veel als je bedenkt dat microservices juist bedoeld zijn om niet noodzakelijke afhankelijkheden zoveel mogelijk te vermijden.
Henri,
Misschien moet je een punt maken door als software/cloud architect een stip op de horizon te zetten als het gaat om de releases. Ik stelde op 28 oktober 2020 trouwens als reactie op de opinie van Jan over de updateritis dat de opeenstapeling van de afhankelijkheden in de runtimes als roadmap velen werkeloos maakt. Tel hierbij een goede afweging van de risico op en je begrijpt waarom je niet elke scheet van de leverancier af hoeft te vegen.
“Serviceability is the measure of and the set of the features that support the ease and speed of which corrective maintenance and preventive maintenance can be conducted on a system.”
SWA zelf vertelde dat hij in amper 2 jaar machines van CentOS 6 naar CentOS 8 heeft gebracht om vervolgens bij Rocky te eindigen. Als cloud architect heb je vast wel klanten horen klagen hierover omdat IT voor veel organisaties een costcenter is doordat het een ondersteunende rol heeft waardoor het hele verhaal van patchen een mannetje bellen wordt.
Wat betreft het punt in managed services gaat regeren (één letter minder dan reageren) vooral om vooruitzien want ontwerpen van onderhoudbaarheid gaat om de houdbaarheid van oplossingen als ik het in mijn gebruikelijke wolligheid mag zeggen. En om coherent in mijn reacties te blijven heb ik hierin geen bezwaar tegen de replatforming van SWA. Tenslotte is er Europese regelgeving welke leveranciers van hardware verplicht tot duurzaamheid van de oplossing. Wij van WC-eend houden daarom in de eerste plaats van open standaarden om zodoende de herbruikbaarheid te vergroten.
“Complex breiwerk van afhankelijkheden die niet onder architectuur tot stand zijn gekomen. Realiteit is een circus aan koppelvlakken met allerlei afhankelijkheden”.
“Van een toiletrol naar de rol van een CISO die naar het blijkt alleen maar in naam de functie heeft is Schaduw IT ondertussen een groeiende probleem.”
Aldus oudlid, de architect, die zijn achterdeurtje pas veegt als het op begint te vallen.
Eerst totale structurele chaos, hulpeloosheid en zelfs anarchie beschrijven en het dan over “een goede afweging van de risico” gaan hebben, om te beslissen of je wel niet gaat patchen 😛
Merk ook op dat swa het als enige over de kwaliteit van software heeft en dat de rest dat al opgegeven lijkt te hebben..
Wat zou die stip aan de horizon nou zijn .. kwalitatief goede software ?
Weet je wat, als je nou eens begint met patchen 🙂
Als Dino geen inhoudelijke argumenten heeft dan heeft hij geen actieve herinnering meer. Gelukkig herinner ik me artikel over CentOS nog want SWA zal vast de weloverwogen keus hebben gemaakt om van CentOS 6 naar 8 te gaan om uiteindelijk te eindigen op Rocky terwijl on-topic blijven zitten op CentOS 7 misschien handiger was:
https://www.computable.nl/artikel/nieuws/development/7112467/250449/red-hat-neemt-afscheid-van-centos.html
Risk-based klinkt $34 miljard op de tafel toch wat anders dan het plan van een doorstart met Rocky als we kijken naar de link van Dino als reactie. Kracht van een community is indrukwekkend maar zoals ik op 25 april 2014 schreef weet je niet wie er straks nog roeit als je met een vereniging in zee gaat. Money talks ook voor Rocky want zonder de investeerders bloedt het dood als ik kijk naar de kosten van zoiets als een infrastructuur voor de distributie van code.
Vergeetachtigheid van Dino is makkelijk als we kijken naar de complexiteit van afhankelijkheden in alle strategische commerciële belangen. Als het om de dark side van ICT gaat dan is het opmerkelijk dat niemand zich druk maakt over de $7,5 miljard die Microsoft eerder betaalde voor Github om code te verspreiden maar dat iedereen struikelt over de verspreiding van een mening door Elon Musk.