Aanvulling:

- kan je i.p.v. patchen andere mitigerende maatregelen nemen?
- wat voor een OS draait er?

Hoe ga je om met kwetsbaarheden die geen CVE hebben, of zelfs geen CVSS score, zoals bv van Yokogawa of Moxa.

Als je vraagt naar een standaard die is er helaas niet.
We gebruiken zelf de Open Web Application Security Project (OWASP) virtual patching framework
https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html
Je kunt dit ombouwen naar enig andere applicatie en protocol.
Ik deel je mening dat er veel andere criterias zijn dan een deadline.

Mocht je voorbeeld willen richting werkgever dan zoek naar patching nightmares door BSOD bij KB integratie.
Voorbeeldje https://docs.microsoft.com/en-us/answers/questions/517537/windows-10-failed-boot-bsod-after-loading-2021-08.html

En bonus Printnightmare
https://tweakers.net/nieuws/184106/microsoft-brengt-noodpatch-uit-voor-printnightmare-bug.html
En je kan vast wel een voorbeeld vinden van een software pakket bij jullie waar zelfde ooit is gebeurd.

Patch niet snel maar secuur, gedocumenteerd en verantwoord gecommuniceerd naar alle responsible persons.
En nooit vanuit een paniek reactie van hoger op.

Houdt het simpel. Zorg dat je normale (beveiligs)updates binnen 30 dagen installeert.

Richt daarnaast een 'emergency patch proces' in voor kritische updates, die je binnen 48/72 uur installeert. Daarbij kan je 'kritische updates' baseren op de 'Hoog/Hoog' risicoscore van het NCSC. Daarvan komen er 20-30 uit per jaar.

Abonneren op de RSS feed of de Twitter van het NCSC volstaat dan en voorkomt dat je na moet denken over een uitgebreid framework of zelf analyses moet gaan maken.

Als je het toch uitgebreid wilt doen, dan kan dat binnen het CVSS raamwerk via de temporal en environmental scores. (Standaard wordt alleen de base temporal score meegenomen om het risico te bepalen.) Maar het kost veel tijd om dat voor elke kwetsbaarheid die uitkomt te gaan bepalen.

Ik denk dat het veel belangrijker is om te kijken naar de geschatte impact van een update en de mate waarin de
maker van de updates te vertrouwen is in het beoordelen daarvan.
En dan moet je die informatie natuurlijk wel krijgen!
Een buffer overrun die gefixed is door beter check op de bounds van die variabele dat is iets wat je zonder problemen
kunt implementeren want daar loopt de normale flow niet tegenaan.
Iets wat eigenlijk een ontwerpfout is (onveilig ontworpen) en wat dan hap-snap gefixed wordt door gebruiksscenario's
die op het eerste gezicht onwaarschijnlijk zijn te blokkeren, dat wordt al een heel ander verhaal. Zeker als niet precies
beschreven is wat er nu niet meer gaat werken.
Een aantal dagen wachten voor je updates installeert dat heeft alleen effect als je daarna heel goed gaat researchen
in welke mate anderen problemen kregen met die update en of hun situatie vergelijkbaar is met die van jou.
Reken er niet op dat de uitgever dat werk voor je doet (dwz patches terugtrekt als ze toch meer impact hadden dan gedacht).

Die randzaken moet je inderdaad meenemen in je risicobeoordeling. Security management is risk based. Dus niet zomaar blindelings gaan patchen. Het kan best zijn dat een kwetsbaarheid met een hoge CVSS score helemaal niet tot uiting komt / kan komen in jouw omgeving en dus niet zo'n hoog risico heeft.

Je kunt ISO27001/2 eens nalezen voor wat betreft vulnerability management, maar key message is dat het risk-based is.
1. Timely identification of vulnerabilities
2. Assessment of your organization's exposure to a vulnerability
3. Proper measures considering the associated risks.

De tijd waarbinnen je patches installeert zou gebaseerd moeten zijn op #2 dus inclusief de randzaken.

In de praktijk is het vaak te veel werk om dit voor elke update zo te doen, je kan standaard timelines definieren, evt. afhankelijk van hoe kritisch de applicatie is (of hoe kritisch de processen die het ondersteunt), patches groeperen, en/of bv integreren in release schedule. En voor updates met hoge CVSS de risico analyse doen om te kijken of je de timeline voor die patch moet vervroegen.

De serieuze issues (unauth RCE/OS level LPE) worden vaak binnen uren of dagen misbruikt. Let dus ook op het nieuws en de exploitcode sites. Externe services zijn altijd kritieker omdat de hele wereld/NL ip-space een aanvaller kan herbergen. Intern loop je minder gevaar maar je ziet nu wel vaker ransomware-bendes interne medewerkers omkopen voor initial access....

Er is nog een out-of-the-box methode die niet benoemd is in andere reacties:
Niet patchen. Maar elke dag nieuwe uitrol doen.

Dat is natuurlijk niet voor alles geschikt, maar als je servers zo inricht dat dat kan ben je helemaal af van deze problemen.
Je weet dan elke ochtend dat het allerlaatste van alles wordt gebruikt, of er ligt een melding bij de afdeling die er iets mee kan dat het systeem niet goed werkte met de nieuwste versies en dat daar die zelfde dag nog actie op moet komen.

Voor de rest zie je vaak tijdslijnen van uren (websites, mailservers dat soort dingen) tot 15/30 dagen inderdaad.

Het is zelden verantwoord om een uitrol te doen in productie voor er getest is. Daarnaast is er een andere reden waarom je iets langer wacht met patchen en dat is om te voorkomen dat er gebruik wordt gemaakt van gecompromitteerde repositories.

In geval van servers als je de zaken beetje goed in orde hebt heb je een nightbuild, edge of hoe je fabrikant het ook noemt release die in een alpha of beta status traject zit van alle varianten van je servers. Daar test je op of de code release voor veiligheid, stabiliteit, performance of gebruiks ervaring problemen zorgt. Beveiliging patches rol je dan vervolgens handmatig of in batch uit en feature updates komen vanzelf bij een volgende release cycle.

Maar blind op een update knop drukken of elke keer een full OS deployment is vragen om ellende en vaak in complete overtreding van je risico inperkings en mitigatie afspraken.

Even voorbeeldje uit verleden:
https://www.cybersecurity-help.cz/vdb/SB2021110418

i like this way of thinking, maar dit komt natuurlijk wel met iets meer detail: het heeft geen zin de uitrol te doen waarin die kwetsbaarheid nog steeds zit. De uitrol zelf moet dus ook gepatched worden en dat die patch die de uitrol BOEM doet doen eerst effe testen en in de tijd dat je zit te trouble shooten ben je wel kwetsbaar nog. Je zou dus kunnen kiezen om dit te verfijnen en automatisch elk uur patches door te voeren zodra zet beschikbaar zijn naast dat je elke dag die auto uitrol doet.

Dat elk uur 'yum update' doen, dat gaat eigenlijk heel goed in de praktijk bij bepaalde OSen kan ik je vertellen. Zelfs het automatisch herstarten van services is daarbij niet een probleem voor de meeste situaties. Wel merk ik wel eens dat een uitrol iets niet wilt na een tijdje door een kleine dep issue als je dingen gebruikt die buiten de cadance van het OS gaan. Dan gaat vaak de live update wel nog goed en ben je grotendeels beschermd, maar is je uitrol even wachtende op een tweak.

Kijk veel hiervan kan ook in een CI pipeline opgezet worden waarbij een server dmv KVM VMs die op spinnen en neer gaan die automatische uitrols (al dan niet met ansible) en updates vrijwel continue testen en pas als die goed gaan, gaat een update naar de echte omgeving. hier is helemaal niet veel hardware oid voor nodig. de KVM die op een lokale mirror server op elke keer na een rsync van updates zn testje doet en dan pas de rsync van updates doorvoert als alles ok is bevonden.

the point is dat testen ook geautomatiseerd kan worden in een fatsoenlijke CI lijn => update binnen, meteen vol automatisch op een VM in een test omgeving testen en dan als ok => meteen door productie repo waar dan afh van productie machine en afsrpaken meteen patchen of 'effe wachten want het is eng'. daar is gewoon een hele hoop winst meer te behalen dat alles maar 'wachten en met handje testen en eng enzo' en ondertussen powend gaan worden op je exchange oid.

Nouja het heeft voor 1 ding wel zin: eventuele modificaties in het systeem gedurende de dag die wis je uit.
Wij doen dit ook voor servers waar gebruikers op werken (Citrix): er is een "golden image" en alle servers krijgen daar
iedere nacht een verse copie van. Mocht er iemand gedurende de dag iets binnen gehaald hebben wat het systeem op
de een of andere manier besmet heeft dan is dat in ieder geval weg.
Van die golden image kunnen ook copieen gemaakt worden en gepatched worden om overdag met een kleinere groep
een patch te testen (op een aparte server instance) en als dat OK bevonden wordt dan kan die de productie in en
draaien de volgende dag alle servers daar weer mee. En uiteraard worden er een paar backups bewaard zodat je
in geval van problemen altijd een of meer stapjes terug kunt om het van daar uit opnieuw te proberen.

Dit werkt op zich prima en je voorkomt er mee dat je ooit "patches terug moet draaien" wat wellicht niet altijd goed kan.
Door dit mechanisme achter de hand te hebben kun je ook met wat minder testwerk volstaan, omdat het altijd mogelijk
is "op de rode knop te drukken" (dan moet wel iedereen afmelden en opnieuw aanmelden)

Tja je moet wat als de patchsoftware van lage kwaliteit is. Een hoop werk voor een patch van 150k die je overal binnen 1 sec hebt geinstalleerd.

Volautomatisch gemaakt = nagenoeg geen werk daarna.
Het kost alleen bij het opzetten, de eerste keer, tijd. Maar dat is met golden images altijd wel het geval natuurlijk.

Nee het is juist minder werk! Omdat meerdere servers van diezelfde golden image draaien, je hoeft maar 1 keer
te patchen en al je servers zijn gepatched.
En omdat je niet zo streng hoeft te testen en niet op de fabrikant hoeft te vertrouwen dat alle patches altijd terug
te draaien zijn, want je kunt met een paar muisklikken terug naar de vorige image die je bewaard hebt waar die
patch nog niet in zat.
Dit geldt niet alleen voor systeemupdates, maar ook voor applicaties die updated of toegevoegd zijn. Mocht er
iets niet meer werken dan heb je altijd nog een werkende situatie achter de hand, wat het risico veel kleiner maakt.
En als je een heel groot bedrijf bent kun je besluiten om gepatchte systemen eerst aan een deel van de gebruikers
te geven om te kijken of die gaan piepen, en dan hoef je niet iedereen lastig te vallen met de fallback.

Tot op heden samen met de tip die verwijst naar Virtual Patching het beste antwoord op mijn vraag. Dank hiervoor!

niet om het een of ander, hoe ben jij nu in staat te bepalen wat het beste is als je voorheen met de vraag bent gekomen? het enige wat je kunt doen is zeggen dat dit je het beste LIJKT vooralsnog, toch? geheel de zaak overzien en snappen kun je namelijk nog niet.

hier dan een goed bedoeld addertje on het gras uit de praktijk:

die ISO items lijkt heel zinnig en om eerlijk te zijn ook eerder joh duh boeren verstand gebruiken, maar de crux zit em in de lastigheid van de juiste risico inschattingen.

te vaak en te veel merk ik dat de beheerder in IT organisaties "zich niet voor kan stellen dat iemand zo slim en handig etc is" => een risico als laag in schatten => powned. wat hier aan de hand is is weer met beperkte kennis van zaken verantwoordlijk voor iets zijn. daarbij horen multi-dimensionele aanpakken. ja goede risico management, maar ook best practises en een goed ingeregelde organisatie die dat werk dan naar behoren (en geverifieerd) doet. en dan heb je natuurlijk nog dat als er een patchje binnen komt die heel vlot doorgevoer kan zijn, ook al is het met een klein ingeschat risico gepaard, je het beste een organisatie of omgeving kunt hebben die die patch dan ook vlotjes door kan voeren. nog beter is zo dat je een organistaie / omgeving hebt waarbij je ook efficient patches die mis lopen vlot terug kunt draaien. en helemaal geweldig zal zijn asl je omgeving / organisatie dat ook nog eens aan juniors (druk maar op knop no thinking involved) voor het dagelijkse gedoe over kan laten.

afgelopen week ook weer zo een discussie met de pkexec patch. de update was er, was een kwetsie van 'yum update' te runnen et voila klaar, maar iemand in de organistaie vond het maar eng en lastig en discussie discussie discussie en toen eventjes verderop gewezen op een publikelijke POC exploit en gedemonstreerd dat je daarmee kakkend simpel root kreeg en toen ja ok dan maar "yum update" runnen. hadden we dit niet laten zien, die POC, dan was dat systeem met meerdere gebruikers nog steeds niet gepatched! daartegenover een omgeving waarbij die "yum update" elke dag automatisch draait en bij een issue een "yum history undo" gedaan kan worden, die was ASAP vanzelf zonder moete gepatched en had een veel kortere tijd dat het systeem kwetsbaar was. helemaal mooi is als dat system dagelijke een 'oscap oval eval' rapport genereerd dat met vele groene vinkjes laat ZIEN duidelijk voor iedereen (aan het SOC oid) dat de machine up to date en gepatched is volgens de laatste RHSAs.

lang verhaal in het kort, vertrouw niet alleen op papieren ISO afspraken en regels, je hebt met inperfecte mensen te maken die ook nog eens van alles in twijfel gaan brengen zodra iets te complex of groots voor ze wordt. probeer zo veel mogelijk automatisch te laten lopen en 'agile' te zijn.

die ironie dan ook:

https://www.theregister.com/2022/01/28/iso_down/

regels op papier doen gene ene zier!