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.
Dino, software leveren die via een browser geconsumeerd wordt heeft veel meer onderdelen dat de microservices aan de achterkant.
Door 1 keer per kwartaal een sprint in te plannen probeer je bij te blijven en door te abonneren op CVE’s en gerelateerd nieuws hoop je op tijd signalen op te vangen dat je direct actie moet ondernemen.
Mijn punt is vooral dat het patchen meer lagen kent dan wat er soms gesuggereerd wordt in het nieuws. Het is een belangrijk onderdeel wat we serieus nemen, maar het is echt niet gek dat sommige updates een paar maanden achter lopen.
Dus in dat kader is risico gebaseerd patchen (on-topic) logischer dan als maar proberen altijd alles direct te patchen.
Nu ben ik niet direct een fan van ISO 27001, maar het heeft me wel geleerd beter met risico’s om te gaan en te snappen hoe zo’n PDCA cirkel werkt.
@henri,
blijkbaar kom je dat tegen en hebben jullie over nagedacht.
Ik vind het moeilijk te rijmen met die agile hosannaverhalen over CI/CD pipelines, AB testing en fail fast and often.
Maar uiteindelijk dus toch maar weer kwartaalwatervallen.
@oudlid,
Adviseer je nou CentOS 7 en wijs je Henri op zijn verwantwoording stip op horizon te zetten ?
Opmerkelijk dat de z.g. hardware knuffelaars gewoon voor latest stable inclusief patches gaan.
Rocky Linux, Almalinux. Binary compatible RHEL releases. Zolang de code beschikbaar wordt gesteld gaat er altijd wel iemand builden.
34 miljard op tafel zal best maar je beschrijft zelf de chaos daarna waarbij jij als architect je handen wast in onschuld.
Nogmaals, swa heeft geautomatiseerd patchen en baseline Rocky 9.1 in place. Wat een prutser he.
indeed, CentOS7 is er uit, hebben nu Rocky 8.7 en 9.1 operationeel en life is good want ‘systemct –now enable dnf-automatic.timer’ is all it takes here. Het kan verkeren dus….
btw van CentOS 8 naar Rocky 8 / Alma 8 / Oracle Linux 8 / Springdale 8 / CentOS Stream 8 was destijds ook maar een kwestie van drie commandos runnen hier na het RedHat besluit…
Nee, ik wijs op het feit dat CentOS 7 pas op 30 juni 2024 EoL gaat waardoor ik vragen heb over de hink-stap-sprong van SWA. Maar gezien zijn antwoord waren er blijkbaar geen functionele redenen alleen emotionele terwijl ik me voor kan stellen dat er vanuit de applicatieve kant eisen en wensen zijn aangaande het platform. En ik ken SWA niet maar zijn logica van een inspanningsverplichting met een commando is als format C: voor een slecht geheugen.
Kwaliteit van resultaatverplichtingen gaat om het testen waarbij je uiteindelijk nog allerlei verschillende dingen kunt testen. Ook binnen devops kennen ze zoiets als testen want de CI gaat in de PDCA cycle niet om een configuratie item maar om zoiets als Continuous Integration. We geven SWA zijn koekje voor de levering van een platform om te testen want Henri staat al in de startblokken voor zijn sprint. En ik denk dat het een estafette gaat worden als ik zijn klachten over horizontale integratie lees.
De stip op de horizon die ik klaar zie staan is dan ook een volgende tester want de business wil niet alleen functionaliteit maar ook prestatie. En de volgende stip die ik in de verte zie staan gaat om efficiëntie want het moet niet alleen snel maar ook goedkoop. Bijna niet te zien maar de volgende stip gaat om betrouwbaar want hoewel het allemaal nooit als kritisch ontworpen is opeens iedereen er toch van afhankelijk. Beetje als het toiletpapier….
Of wordt de volgende stip herbruikbaarheid?
Dino,
Niets is eenduidig. Helemaal agile wordt niets als je een kathedraal wilt bouwen. Wij hebben gewoon een DevOps / OTAP straat. Dus heel veel gaat heel snel en in sprints… maar andere dingen gaan weer langzaam en als een waterval. We hebben ook nog een ISO 27001 ISMS.. daar heb je dan weer PDCA cycli waarin je nogmaals door de veranderingen heen gaat en de risico’s onderzoekt. Dat gaat a-synchroon. Je checkt IB beleid vooraf, uiteraard, maar nadat wijzigingen zijn doorgevoerd ga je speuren naar nieuwe risico’s en laat je bijvoorbeeld een pentest doen.
Het gaat gewoon om een beetje adaptief zijn. In het front-end foutjes maken bijvoorbeeld met een CSS aanpassing iets is anders dan een nieuwe functie in de API toevoegen.
oudlid doet aantal aannames over swa :
– maakt hinkstap sprongen
– documenteert niet
– denkt dat open software hetzelfde is als veilige software
– patcht/deployt niet om functionele redenen maar alleen emotionele, als soort amateur, een liefhebber ..
– “doet kwispelend als geconditioneerd hondje” “wat leverancier je zegt te doen zonder eigenlijk te weten wat je oplost met patches.”
Terwijl feitelijk van swa alleen bekend is dat hij keuze maakt mbt platform OS en geautomatiseerd patchen tot latest stable release voor elkaar heeft.
Als architect zeiken over opensource maar geen verantwoording nemen over de architectuur zelfs accepteren men druk bezig is met eigen schadow oplossingen te verzinnen.
En ondertussen maar klepperen over prestatie, efficientie, kosten, betrouwbaarheid, herbruikbaarheid. Zucht
Ga eens aan het werk 🙂
wat persoonlijke hygiene betreft dus : niet lullen maar poetsen
wat je werk betreft : niet lullen paar patchen
Henri, vind je fouten na een OS patch update niet gewoon in de OTAP straat, nadat OTA updated is ?
Als je OTA nou automatisch update en na acceptatie datzelfde voor P doet, heb je dan bijv last van “horizontale integratie” ?
Is in het hele agile idee iets bereiken niet altijd een estafette van sprints ?
Die pentesten kun je inderdaad beter uitbesteden, maar veel tests kun je zelf ook automatisch zelf uitvoeren.
Zelf draai ik bijv automatische nmap van remote locations, run elke dag pkg audits ( https://www.freebsd.org/cgi/man.cgi?query=pkg-audit&sektion=8&n=1 ) over mijn freebsd servers die aan internet verbonden zijn en check ik regelmatig de audit logs.
Dino,
OS patch updates volgen welk de route van de OTAP straat, maar zijn geen onderdeel van het DevOps proces.
Uiteindelijk vind elke verandering in code wel plaats via sprints. Maar de vorm van een sprint is want ons betreft niet altijd strak aan tijd gebonden. Scrum e.d. zijn mooi, maar het zuiver volgen van een methodiek is bij ons zeker geen doel op zich. Persoonlijk heb ik een hekel aan micro managen. Liever wat principes centraal stellen en zorgen dat iedereen een centrale visie deelt. Verder geen idee wat je precies vraagt, dus ook geen idee of ik antwoord geef op je vraag.
Uiteraard worden tests gebouwd als onderdeel van nieuwe functionaliteit. Maar tests zijn zelden compleet en slechts een hulpmiddel in het ontwikkelen van goede software.
Thanks voor de link, die heb ik intern gedeeld!
Zou verwachten dat OS patch updates meegenomen worden in DevOps-proces, je wilt tenslotte dat de boel blijft werken ook al komen de wijzigingen via een ander kanaal binnen. OS is onderdeel en dus ook van systeemtest, lijkt me. Das toch het hele topic, waar we over praten.
Tja, ik weet ook niet precies wat oudlid bedoelt met “We geven SWA zijn koekje voor de levering van een platform om te testen want Henri staat al in de startblokken voor zijn sprint. En ik denk dat het een estafette gaat worden als ik zijn klachten over horizontale integratie lees.”
Dus ik dacht, ik vraag even na of iets herkenbaar is 🙂
Wat betreft de verwachtingen moet Dino nog een keer de strekking van het artikel lezen, ik stel als advocaat van de duivel namelijk de verwachting ter discussie. Zoals de verwachting van papier na de boodschap, uiteindelijk dezelfde verrassing bij de kassa als je geen tegoed meer hebt. Ik bespeur niet alleen een slecht geheugen maar ook een gebrek aan inlevingsvermogen, het loketdenken waar ik iets over zei gaat namelijk om verder kijken.
Zo wijs ik niet op de nadelen van open source maar op de keus van een distributie, de uitbesteding van het maken van een package welke je eenvoudig kunt installeren vergeet nog even zoiets als het voorwerk. En zoals ik het begrijp heeft ook Rocky daar sponsors voor nodig omdat er niet zoiets is als ‘gratis’ in de ICT. We kunnen de kraan dichtdraaien als het om de verrassing bij de kassa gaat in mijn metaforen die te wollig zijn voor mijn criticasters maar dat is als het toiletpapier.
Waar begint DevOps en waar eindigt het want het paradigma laat nogal wat steken vallen als ik kijk naar toevoegingen zoals beveiliging. Want DevSecOps schijnt een tussenstap in de hink-stap-sprong tot zoiets als DevSecBisOps te zijn. Nu nog wachten wie het stuur heeft want ik vermoed dat er nog wat strijd tussen de verschillende partijen zal ontstaan, Dino en SWA moeten nog eens kijken wie er voor een positief tegoed op rekening voor de boodschappen zorgt. Of moet ik zeggen wie de kachel brandend houdt want een warm gevoel is leuk maar er warm bij zitten is nog wat anders.
Goh wat kan dat oudelidje toch hyperbolen en extrapoleren op lucht.
Neen, geen emotionele keuzes maar sterk gekoppeld aan de tijd frame en omstandigheden dat mensen hier een PhD doen.
Door nieuwe PhDers op machines te laten werken die tijdens hun drukke onderzoeksperiode geen EOL gaan ervaren, maar wel steeds up to date blijven en security patches krijgen (vol automatisch, tijdig en stabiel i might add) heb ik wel degelijk oog voor de business van onze HPC gehad.
Het over schakelen van C7 naar R8 / R9 voor het EOL van C7 is dus een vooruitziende keuze geweest omdat we hier flink wat hardware draaien en als dan alles last-minute-typical-excel-sheet-management-style-oh-crap-we-zijn-te-laat eind 2023 over moet, heeft iedereen er last van.
Oh en het behoeft geen enkele verdere uitleg dat HPC nu eenmaal een 100% Linux feesje is [https://top500.org/] !
Oudlid, werkelijkwaar, you are out of your depth here!