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.
Zeker is patching niet eenvoudig en het is er ook niet beter op geworden door hoge frequenties met de agile software ontwikkeling welke een bijzondere lage focus heeft op beveiliging. Wat betreft het dweilen met de kraan open lijkt risk-based patch management me dan ook het paard achter de wagen spannen, het gaat tenslotte niet alleen om security patches als we kijken naar het change proces als geheel.
Wat betreft de asset-discovery versus een CI is de ‘lijn’ absoluut interessant als we overwegen dat een SLA om een service gaat en niet om één asset. Hele verhaal mist nog zoiets als de 180 graden ommekeer want 30% uitval van laptops omdat deze onvoldoende beschermd zijn legt het probleem tenslotte bij degene die het op moet lossen want zo’n 70% van patches wordt door de gebruiker uitgesteld.
Hmm patching… vannochtend nog de Rocky 9.1 over de system gehaald, reboot et voila alles weer patched. Klaar in 5 minuten. Het kan verkeren denk ik maar….
Je kunt het wel heel ingewikkeld maken, maar met een backup, OTAP, baseline, een change window + een swa ben je er meestal al en die heeft elk bedrijf vanzelfsprekend op orde ;-). Op zich ook wel bijzonder met met die wendbare commit often gedachte patching ineens een probleem zou zijn. Al die systemen die nog RHEL6 draaien. Met cloud zou het allemaal verleden tijd zijn. Business aan het roer enzo.
Volgens het artikel zijn natuurlijk weer de adviseurs en de tools noodzakelijk.
Een wereld van 7×24 dienstverlening kent uiteindelijk een andere planning als we voorbij het loket gaan van monolithische besturingssystemen waar klaar in 5 minuten om de zelfbevrediging van ICT uit de jaren 80 gaat. Want de dicht getimmerde mainframe met ‘groene’ terminals voor toegang was uiteindelijk geen blijvertje. Vroeger was alles beter want maandelijks werden de patches gedaan en dan kon er niet overgewerkt worden. Maar maatschappelijk is er wat veranderd want tegenwoordig werken we de klok rond waardoor SLA van 99,9999% uptime ook geldt voor geplande downtime.
Het is de ommekeer in de jaren 90 die voor een 180 graden andere service belevenis zorgde doordat opeens de gebruiker centraal kwam te staan. SOA van klaar in 5 minuten hield echter geen rekening met de beveiliging. Dit werd er altijd een beetje bij geknutseld waardoor het fort goed beveiligd was maar in de end-to-end stack (de lijn) van open systemen de ramen wagenwijd open stonden. Vooral ‘achterwaartse ondersteuning’ gaat tenslotte om risico gebaseerd accepteren van beveiligingsissues met onveilige services en protocollen.
De huidige ommekeer verlegt de focus van applicaties en systemen naar informatie, toegangsbeheer hierin wordt mede doordat we niet meer in het fort werken namelijk steeds belangrijker. Tenslotte is een migratie naar de cloud ook de gebruikelijke cyclische beweging van data centralisatie. Want als we naar de vervangbaarheid kijken dan is Twitter een dertien-in-een-dozijn oplossing voor zoiets als de zelfbevrediging aangaande emotionele incontinentie.
In vrijwel all bedrijven waar ik gewerkt heb, is slechts een fractie van de systemen echt business critical en is hoge beschikbaarheid nodig. Die ontwerp je dan met iets clusterachtigs HA, failover met nodes die gelijke taken uitvoeren en die je onafhankelijk van elkaar kunt patchen en testen, booten, whatever, zonder dat de dienst daar last van heeft.
Voor de rest heb je gewoon geplande downtime.
Dat oeverloos gezwets van oudlid geeft uiteindelijk toch wel aan waar het probleem zit.
de business en gebruiker aan het roer waar de stuurman dit zou moeten zijn.
Die zou ook wel hard vooruit willen, maar bij voorkeur om de ijsberg heen.
Verantwoording leggen waar die hoort is een business feestje.
Als daaruit voortkomt dat de commitment-sprintgedreven teams en de gebruikers mee mogen raddraaien.
en dat het verstandiger is budget te spenderen aan agile coaches dan een beetje OTAP traject, LCM en goede architectuur,
dan eindig je inderdaad met een neerwaartse beweging en je beste stuurlui aan wal.
Wat een enorm geleuter en ingewikkelde riskbased systemen ipv he swa, dankjewel voor het upgraden en patchen. Kost je wel weinig tijd en hoort bij je vak, maar toch bedankt.
de afsluiting met Twitter spreekt boekdelen.
Om u nog beter van dienst te kunnen zijn schofferen we al het personeel, sturen we hele mission critical afdelingen naar huis,
waarschuwen we voor faillissement en herstellen we Trumps account.
@oudlid
Het is onduidelijk of je 2e post nu een reactie is of niet want het zit vol van incoherente wollige wauwerigheid in mijn ogen.
het moge duidelijk zijn dat wij hier op de systemen dagelijks automatisch de updates doorvoeren en dat de theoretische risico’s die vaak benoemd worden om dat niet automatisch te doen, vaak hun oorsprong terug vinden in de (inmiddels typische) kwaliteit van de software en updates van de fabrikant in kwestie. het kan verkeren stel ik. patchen hoeft namelijk geen probleem te zijn en er is ook al helemaal geen enorm battle plan voor nodig als de software die je gebruikt van bepaalde kwaliteit is.
Altijd leuk om te lezen dat ‘ouwe jongens’ het met elkaar eens zijn terwijl ze me feitelijk gelijk geven over het probleem. Want in de incoherente wollige wauwerigheid van een SLA versus een OLA wordt vergeten dat serviceketens uit diverse systemen bestaan en al lang niet meer vertikaal door de architectuur gaan als gevolg van onvolprezen SOA paradigma. En de hele keten is vaak niet eens geheel onder beheer als we kijken naar uitbestedingen en de service contracten hierin. Geplande downtime wordt dan ook niet bepaald door de afdeling ICT maar door de business zodat betaalterminals niet plat liggen op Black Friday omdat er een update op de servers uitgerold wordt op het meest ongelukkige moment van het jaar.
Natuurlijk kun je een SPoF voorkomen door het allemaal goed te ontwerpen maar dat is de theorie want in de praktijk hebben we het over een complex breiwerk van afhankelijkheden die niet onder architectuur tot stand zijn gekomen. Realiteit is een circus aan koppelvlakken met allerlei afhankelijkheden waarin 52 maal 5 minuten aan downtime door wekelijkse patches op besturingssystemen voor irritatie bij de business zorgt over de updateritis. En het is dan ook niet voor niks dat er ‘risk-based’ voor uitstel gekozen wordt met niet zelden het afstel van achterstallig onderhoud.
Oja, Twitter is meer een dienst dan een oplossing als ik kijk naar mogelijkheden tot toegang want dat patchen technisch geen probleem hoeft te zijn leerde ik in de jaren 90 toen idee van DevOps nog de pijplijn heette met jaarlijks 3 major releases en 6 minor releases op de core en een veelvoud ervan op de satellieten die binnen het SOA paradigma gebruikt werden voor de toegang. De keuze ging toen om Windows en Novell want Linux werd nauwelijks gebruikt en apps bestonden nog niet. Hoe anders ziet de wereld er nu uit met de gebruikers die mogen kiezen tussen Apple, Windows en iets met Linux omdat de strijd om de software een verloren strijd is door de cloud. En zo ook met de aloude kassa welke door een selfservice uitcheck is vervangen omdat chartaal geld vervangen wordt.
Omarm de automatisering, automatiseer jezelf weg!
Wie geeft nou wie gelijk ?
automatiseer je zelf weg. Precies wat swa dee.
vroeger was alles beter, inderdaad het patchen ook. wat je zegt.
en dan die business aan het roer.
visieloos in het donker eerst voorwaarts en later neerwaarts zoals bij titanic.
gewoon hopen dat het goed gaat..
Of riskbased voor uitstel kiezen, dan kun je altijd nog afstellen,
want hebben we het nou over irritatie gebaseerd patch management 😉 ?
smorgens na de eigen pipeline elke keer billen vegen is ook niet altijd leuk,
maar hoort er beetje bij denk ik dan, en als je niet doet kleven er op den duur smerige nadelen aan.
Wat is er nou zo moeilijk om met de IT afdeling tot een compromis te komen over
wat een goede patchfreqentie zou zijn en om blackfriday of feestdagen keertje te skippen.
Ook bijzonder hoe de eigen architectenrol wordt beschreven :
“complex breiwerk van afhankelijkheden die niet onder architectuur tot stand zijn gekomen.
Realiteit is een circus aan koppelvlakken met allerlei afhankelijkheden”.
Bassie stond erbij en keek ernaar, maar misschien is voor actie inderdaad een togaf master certified architect nodig.
Verder compleet negeren dat de meeste systemen helemaal niet 24/7 up moeten zijn om het af te sluiten.
dank voor je bijdrage, volgende keer beter
Die Dino, als hij de voorraad op de rol niet controleert voordat hij z’n dagelijkse boodschap doet dan vergeet hij de operationele planning welke voor verrassingen in de afhankelijkheid zorgt. En ik weet dat het voor een kwispelende SWA allemaal te wollig wordt als je geconditioneerd bent op het belletje. Maar gaat verwachting dat het gratis toiletpapier tot de service behoort niet om zoiets als te goed van vertrouwen?
Wat betreft niet de gecontracteerde oplossing van FOSS automatiseren sommigen zich allesbehalve weg als we kijken naar het breiwerk aan ongedocumenteerde oplossingen. 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. Onder architectuur werken gaat ook om de papieren tijgers temmen van de contracten want de vrijblijvendheid van een community oplossing is kiezen voor een vereniging van goedwillende vrijwilligers. En uiteraard is daar niks mis mee maar quid pro quo kun je weinig eisen als het om de verbintenis met een gesloten beurs gaat.
Oja, ik ben bekend met het fenomeen van scripten om dingen te automatiseren maar ook dat is code welke onderhoud nodig heeft. En budgettair schijnt dat nog vaak een probleem te zijn als we kijken naar de adoptie van FOSS, een soort van gratis toiletpapier als ik kijk naar wat problemen ermee in de keten. Je kunt namelijk wel handelingen in een proces automatiseren maar niet de kennis als we kijken naar de web-enabled toiletrol die voor Dino de voorraad controleert. En pay-per-use geven we nog een keus in het aantal lagen en de zachtheid, het enkel laagse schuurpapier is gratis omdat we de luxe wegbezuinigd hebben.
The architect die niet ontwerpt.
de business die geen zaken doet.
de It afdeling die alleen mag jaknikken.
“omdat we de luxe wegbezuinigd hebben”. So now its “we” 😉
van PINO naar CISO in name only en Shadow IT rules.
https://www.youtube.com/watch?v=on-y9Pv-CJA The lunatics have taken over the asylum.
Lijkt erop het “we kunnen ze niet vinden” meer over gekwalificeerde business van toepassing is dan de IT