Microsoft patcht 51 kwetsbaarheden op Patch Tuesday met geen enkele kritieke bug

Microsoft heeft tijdens de maandelijkse Patch Tuesday 51 kwetsbaarheden verholpen in Windows, Office, Edge en andere software. Daar zat een zeroday bij, maar opvallend is vooral dat geen enkele kwetsbaarheid een 'kritiek'-rating kreeg.

Tijdens de maandelijkse Patch Tuesday zijn voor Windows 11 KB5010386 en voor Windows 10 KB5010342 uitgebracht. Microsoft schrijft dat er patches zijn uitgebracht voor in totaal 51 bugs. Die zitten in Windows, Azure, Edge, Office en Visual Studio Code, maar ook in Components, Azure, Kestrel Web Server, de Codes-library, Dynamics en Hyper-V Server. 51 kwetsbaarheden is een opvallend laag aantal voor een Patch Tuesday, waarop recentelijk steeds vaker recordaantallen bugs worden gerepareerd.

Nog opvallender is dat geen van de CVE's die zijn gerepareerd een 'kritiek'-rating krijgt. Vrijwel alle kwetsbaarheden hebben een rating met 'belangrijk' gekregen, maar er zijn ook veel kwetsbaarheden die helemaal geen score hebben gekregen. Dat er geen kritieke bugs zijn, komt vrijwel nooit voor. In de meeste Patch Tuesdays worden een paar ernstige of kritieke lekken gerepareerd.

Een van de kwetsbaarheden die is gefixt was een zeroday. Dat is een lek waarvan details al voorafgaand aan de patchcyclus bekend zijn gemaakt. Het gaat om CVE-2022-21989, een privilege escalation in de kernel. Volgens Microsoft werd dat lek voor zover bekend niet uitgebuit.

Andere opvallende bugs zijn CVE-2022-21984, waarmee een remote code execution kon worden uitgevoerd in Windows DNS Server, en CVE-2022-21995, waarmee een aanvaller uit een Hyper-V-omgeving kon ontsnappen.

Reacties (42)

[CAPSLOCK2000]

Wat is dit nieuwsbericht tekend voor de tijd. Groot nieuws jongens, bij deze belangrijke leverancier is er een keer geen kritiek probleem gevonden. Net zo tekenend is dat CVE-2022-21984, remote code execution, niet als kritiek wordt gezien. Dat anderen op afstand jouw servers overnemen is blijkbaar gewoon.

Vanuit een bepaald perspectief klopt dat ook. Het is dagelijkse praktijk in de IT dat ernstige beveiligingsproblemen gevonden worden. Je kan niet iedere week in paniek blijven raken.

De vraag is wel wat je er dan mee doet. In paniek raken helpt niet, maar op de oude voet verder gaan ook niet. Daarbij zal je mee moeten nemen dat ernstige softwarefouten nog heel lang aan de orde van de dag zullen zijn. We moeten af van het idee dat dit soort fouten uitzonderlijk zijn en dat je dan een noodprocedure in werking stelt waarbij je mensen vraagt om extra werk te verichten, typisch buiten kantoortijd. In de IT is de regel sowieso dat als je iets meer dan twee keer moet doen, dat je moet gaan automatiseren.

Mijn pleidooi is dus eigenlijk dat je het uitrollen van patches een geautomatiseerd proces moet zijn wat zonder menselijk ingrijpen functioneert en nieuwe patches onmiddelijk in behandeling neemt. Daarmee zeg ik nog niet dat je alle patches altijd en overal blind moet installeren. Vooraf testen voor je patches naar productie doorzet is een goed idee maar dat moet een automatisch proces zijn.
Je moet niet wachten tot de volgende dag een beheerder de patch in een test-omgeving installeert om dan na 3 dagen van de tester te horen te krijgen dat er iets niet goed gaat. Dat hele proces moet automatisch gaan zodat je na 30 minuten weet dat een patch geen grote fouten bevat al je systemen zich normaal lijken te gedragen. Zodra je die zekerheid hebt kun je de patch op productie installeren.

Nu hoor ik mensen al roepen "dat kan bij ons niet", "onze omgeving mag niet zomaar down" of "software kan nooit alle fouten vinden". Dat is dan deel van het probleem dat je moet oplossen om wel tot een goede IT-omgeving te komen. Als een systeem zo belangrijk is dat het niet down mag dan heb je een risico wat je moet oplossen. Want alles gaat vroeg of laat kapot. Bouw het dus zo dat je niet direct in de problemen komt als het een keer stuk gaat. Zo ook met testen, software kan niet alle fouten vinden maar mensen ook niet, zeker als testen saai en repetitief is ("druk een keer op alle knopjes") dan haken mensen al snel af. Als iets zo belangrijk is dat je niet "zomaar" even onderhoud kan plegen dan is het ook belangrijk genoeg om het voortdurend te monitoren en te testen, automatisch dus.

Als je het hele proces van patchen en testen geautomatiseerd hebt dan kun je met een gerust hart patches installeren kort nadat ze beschikbaar komen. Natuulijk zal er nog steeds wel eens iets fout gaan en op dat moment zal je dan als nog je beheerders moeten vragen om wat extra werk te verrichten. Maar dat moet uitzonderlijk zijn, niet iedere maand.

Het is ook een uitstekende stimulans voor je IT'ers om dingen goed te regelen. Als je als IT'er kan voorkomen dat je 's avonds gebeld wordt dan doe je dat natuurlijk, iedereen heeft liever z'n avond vrij. Als je dan een keer op een donderdag wat extra doet om te voorkomen dat je dinsdagavond gebeld wordt dan voelt dat als goed deal. Als je zeker weet dat je toch iedere patchdag gevraagd wordt om overuren te maken dan ga je ook geen extra moeite doen om dat te voorkomen maar richt je je leven er op in en ga je die tijd elders compenseren. Voor de organisatie is dat een erg dure oplossing.

Om het er maar niet over te hebben dat werken buiten kantooruren sowieso minder efficient is omdat mensen dan moe zijn en met hun hoofd bij de aardappelen of het voetbal zijn. En als er iets mis gaat en je hebt hulp nodig dan lukt dat niet want alle andere techneuten zitten thuis.

Tenslotte levert vaak patchen een stabielere omgeving op. Nu worden onderhoudsmomenten vaak gevreesd omdat er opeens een heleboel verandert en als dat mis gaat is heel moeilijk om aan te wijzen waar de fout zit. Dan is de neiging al snel om niks te veranderen tot het echt moet. Zo garandeer je haast de veranderingen vroeg of laat onoverzichtelijk groot worden.
Je moet dus de andere kant op, naar zo snel en vaak mogelijk patchen. Als er maar één patch is dan hoef je bij fouten niet te zoeken waar die vandaan komen en kun je al je aandacht direct op de problematisch patch richten. Zeker als je geen simpel geisoleerd probleem hebt maar er wat "afstand" zit tussen de patch en het probleem of wanneer problemen zich door de tijd heen ontwikkelen (de ene fout veroorzaak elders een volgende fout) is het erg prettig om er snel bij te zijn en niet achteraf een enorme reconstructie te moeten doen om te ontdekken waar of wanneer de 'root cause' is ontstaan.

Dus, patch early, patch often, patch automatically.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 15:16]

[lenwar]

In de basis klopt je pleidooi natuurlijk volledig vanuit het beheeroogpunt. Maar je gaat wel wat kort door de bocht op een aantal punten. Vroeg, vaak en automatisch patches. Geen problemen mee. Helemaal mee eens. Maar het moet 'mogelijk zijn'.

Je haalt het zelf al aan 'mijn omgeving kan niet plat, enz. enz. enz.'. Dat zijn inderdaad in de basis een non-argumenten. Als je omgeving niet plat kan, moet je inderdaad gaan kijken naar een betere omgeving. Dat wil niet zeggen dat je nu voorlopig nog met die omgeving opgescheept zit. Dus het is wel iets wat 'op dit moment' kan bestaan.

Als je bijvoorbeeld bij financiële instellingen kijkt, zit dat nog altijd vol met allerlei archaïsche systemen die producten moeten onderhouden/beheren die al lang niet meer verkocht worden en het overzetten naar een nieuw systeem vermogens kost. Denk aan specifieke soorten leningen, beleningen, beleggingen, enz. enz. Software die ooit in de jaren 70 is geschreven in COBOL, continue is gepatcht naar nieuwere OS'en/backends, enz. Van die applicaties die een paar dagen per jaar daadwerkelijk in gebruik zijn, voor het doorrekenen van de rentes, maar vanuit regelgeving wel dagelijks rapportages moeten uitspugen voor de ECB/DNB.
Nieuwe financiële software voor leningen/aandelen/enz. kennen de producten niet (want het waren bijvoorbeeld maar 15 banken op de wereld die ze verkochten), en de leveranciers vragen ettelijke vermogens om het er in te bouwen (tonnen tot miljoenen). (ik ken producten waar er spaardeposito's voor 300 jaar zijn vastgelegd tegen een bepaalde rente. Databases waar nog maar 30 items in zitten, maar die je nergens anders kwijt kan.) - Sommigen zijn daadwerkelijk in een slim ontworpen Exceldocument gezet dat rapportages uitzet en dat soort zaken, maar blijkbaar kon dat niet bij alles.

Bovenstaande is maar één van de voorbeelden waar je dus daadwerkelijk tegen allerlei gedoe aanloopt en waar testcycli potentieel erg veel gedoe zijn. (herstarten van een systeem kan een kalibratie aftrappen die 6 uur duurt, ik verzin maar wat, enz. enz.)

Uiteraard zijn het uitzonderingen, maar het bestaat weldegelijk en het is niet zo simpel om van die systemen af te komen. (niet zonder er een goede kosten-baten-afweging in te maken, want het eindeloos blijven onderhouden van oude systemen kost natuurlijk ook veel geld).

[CAPSLOCK2000]

In de basis klopt je pleidooi natuurlijk volledig vanuit het beheeroogpunt. Maar je gaat wel wat kort door de bocht op een aantal punten. Vroeg, vaak en automatisch patches. Geen problemen mee. Helemaal mee eens. Maar het moet 'mogelijk zijn'.

Dat wil niet zeggen dat je nu voorlopig nog met die omgeving opgescheept zit. Dus het is wel iets wat 'op dit moment' kan bestaan.

Als iedereen al zo'n omgeving had dan was mijn post niet nodig geweest
Maar hoe slecht de situatie ook is, als je wil verbeteren moet je inzetten op automatiseren. Automatisch testen hoort daar ook bij.
Als het niet mogelijk is dan moet je het mogelijk maken, dat is deel van je werk als IT'er. Dat het niet makkelijk is klopt want anders deden we het wel.

Als je bijvoorbeeld bij financiële instellingen kijkt, zit dat nog altijd vol met allerlei archaïsche systemen die producten moeten onderhouden/beheren die al lang niet meer verkocht worden en het overzetten naar een nieuw systeem vermogens kost.

Die systemen zijn gewoon slecht volgens de inzichten van nu. Alle respect voor de mensen die ze ooit gebouwd hebben en ze al die tijd in leven hebben gehouden. Ik kan ze niet verwijten dat ze niet volgens hedendaagse inzichten hebben gewerkt. Maar dat neemt niet weg dat de huidige situatie niet goed is. Dat je in zo'n situatie terecht bent gekomen is een kwestie van slecht lifecyclemanagement.
Dat is iets wat ik wel verwijtbaar vind want dat was in de jaren 80 ook wel bekend. We kunnen het er over hebben waarom het fout is gegaan, maar fout is het.


In mijn eigen ervaring zijn oude sytemen vaak zo moeilijk omdat niemand precies weet hoe ze ze werken en welke bugs eigenlijk features zijn, of andersom. Daarbij heerst de angst dat verandering betekent dat dingen onherstelbaar stuk gaan.

Ook daar geldt dat automatiseren en testen nodig zijn om er grip op te krijgen.

Bovenstaande is maar één van de voorbeelden waar je dus daadwerkelijk tegen allerlei gedoe aanloopt en waar testcycli potentieel erg veel gedoe zijn. (herstarten van een systeem kan een kalibratie aftrappen die 6 uur duurt, ik verzin maar wat, enz. enz.)

Dat is de huidige situatie. Ik probeer iedereen te overtuigen dat ze die situatie moeten veranderen door toe te werken naar systemen die je wel automatisch kan testen.
(Dat iets zes uur lang duurt zie ik op zich niet als bezwaar, de computer doet dat wel terwijl ik lig te slapen. Als er iemand zes uur naast moet gaan zitten dan is dat uiteraard wel een probleem maar dan moeten we dat automatiseren.)

[rob12424]

Als er instellingen zijn die aan regelgeving wat betreft ICT moeten voldoen dan zijn dat financiële instellingen wel. Heb jij nieuws gehoord over een bank die gehacked was? Waar veel geld verdwenen was? Nee niet echt. Banken hebben juist het geld en is het core business omdat geld te beveiligen (ik ken iemand die dat doet, dus weet een beetje waar ik over praat)

Het zijn juist bedrijven waar weinig geld is of op de verkeerde plek. Met informatie. Denk aan universiteiten enz. Daar moeten ze oude systemen draaien en ze willen het snel en makkelijk want het het is hun onderzoek. En collega's moeten er makkelijk bij kunnen. En dan heb je dus echt wetenschappers die de IT regels zat zijn en hun eigen pc maar even hacken voor admin rechten

Of Inplaats van eenvoud: elke groep verhuist in de zoveel jaar naar een ander instituut/instelling en heeft zijn eigen Linux distro maar moet ook op hun nieuwe instituut bij de data kunnen op het centrale netwerk. (Dan praat je over Novel en Suse 6 servers) En als je vraagt ben je niet bang gescooped te worden of dat je data gejat wordt. Is het antwoord: dan moeten ze nog de context hebben en die hebben ze niet dus ik wens ze Suc6!

De gebruikers zijn nog altijd de zwakste schakel!

[lenwar]

Uiteraard.
Misschien suggereerde ik iets verkeerd. Ik bedoelde alleen aan te geven dat 'snel en automatisch patchen' niet per se in alle mogelijke omgevingen mogelijk zijn (per definitie). Het wil uiteraard niet zeggen dat dat je serieuze streven moet zijn en dat 'het is onhandig' of 'ik heb geen tijd om alles iedere keer te testen' geen excuus is. In sommige (niche-)gevallen is het echt daadwerkelijk "onmogelijk" (expres met quotes, want voor alles is een oplossing alleen is het (bijvoorbeeld) financieel niet recht te praten)

Maar als we wat breder kijken: OS-patching is natuurlijk van kolossaal belang, maar er zijn ook natuurlijk vele lagen van beveiliging die ook significant bijdragen aan de beveiliging. En inderdaad de gebruikers zijn één van de zwakste schakels. Ik ben persoonlijk dan ook in de overtuiging dat een gebruiker geen toegang moet hebben tot wat voor data dan ook met z'n eigen account. Dus kort door de bocht: dat de account waar je mail op binnenkomt en waarmee je het internet op gaat, geen rechten heeft op wat voor bedrijfsapplicatie dan ook. Dat scheelt al een hele boel.

[Scoro]

Laten we ook eerlijk zijn en vermelden dat er eigenlijk al wat jaren een verschuiving is in de IT/Security-wereld.
Het NIST model gaat uit van 5 functions:

• identify
• protect
• detect
• respond
• recover

De Identify en Protect functions zijn belangrijk maar zijn eigenlijk ook een wat gepasseerd station.
Meer waarde is er gekomen in het Detect/Respond/Recover. Want je gaat sowieso een keer geraakt worden. Of bent dat al als bedrijf. Met alle zero-day's kan je er niet meer van uitgaan dat je Project nog veel gaat uitmaken.

[mlohnen]

Dat patch automatically liever niet de laatste tijd gezien de steekjes die MS laat vallen..

Update server : printen niet meer mogelijk
Update server : DC blijft rebooten

Fijne updates.. ik kijk het liever eerst even aan..

[CAPSLOCK2000]

Dat patch automatically liever niet de laatste tijd gezien de steekjes die MS laat vallen..

Update server : printen niet meer mogelijk
Update server : DC blijft rebooten

Fijne updates.. ik kijk het liever eerst even aan..

Ik zeg ook niet dat je ongetest moet installeren. Even aankijken is prima, maar dat moet je wel automatiseren. Want hoe doe je dat aankijken nu? Ga je zitten wachten tot de rest van de wereld een maand heeft getest? In de tussentijd zijn jouw systemen kwetsbaar en na die maand heb je nog steeds geen garantie dat de patch ook in jouw omgeving probleemloos werkt. En wat als de rest van de wereld ook besluit om het eerst eens een maand aan te kijken?

Mijn stelling is dus dat je dat "even aankijken" moet automatiseren door de patches in een test-omgeving te installeren en daar (automatisch) te laten testen. Zo kun je op korte termijn het vertrouwen krijgen dat een patch goed is.

[The Realone]

Is altijd zo'n lekkere dooddoener door mensen die een testomgeving hebben en niet inzien dat er een heleboel situaties zijn waar dit niet het geval is. En ook daar zijn weer legio redenen te bedenken waarom dat niet is waarbij je de vinger naar velen verschillende factoren kunt wijzen.
Toen ik in een omgeving werkte waar we geen degelijke testomgeving hadden keken we het ook aan, maar "even aankijken" is dan ook echt even en niet ineens de maand of langer waar jij mee komt. De echt grote en wijdverspreide problemen zijn binnen 2 dagen na Patch Tuesday wel uitgebreid in het nieuws (lees: de kanalen die je als professional hoort te kennen). Dan blijven daar iedere maand nog een handjevol zaken over die potentieel impact hebben op jouw omgeving. Die dek je af met een testomgeving, anders neem je die voor lief.

[CAPSLOCK2000]

Is altijd zo'n lekkere dooddoener door mensen die een testomgeving hebben en niet inzien dat er een heleboel situaties zijn waar dit niet het geval is. En ook daar zijn weer legio redenen te bedenken waarom dat niet is waarbij je de vinger naar velen verschillende factoren kunt wijzen.

Natuurlijk zie ik in dat die testomgeving er nu vaak niet is, dat is deel van het probleem dat ik aanstip. Ik krijg wel vaker te horen dat die test-omgeving er niet is vanwege een of andere reden. Meestal komt dat uiteindelijk neer op geld en tijd, op korte termijn. Naar mijn mening ben je op lange termijn duurder uit.

Toen ik in een omgeving werkte waar we geen degelijke testomgeving hadden keken we het ook aan, maar "even aankijken" is dan ook echt even en niet ineens de maand of langer waar jij mee komt.

Ook hier snap ik dat het in praktijk zo werkt, dat soort systemen heb ik ook. Je hebt het niet altijd voor het kiezen maar dat neemt niet weg dat de situatie niet goed is en en dat je er naar zou moeten streven om
die test-omgeving wel te krijgen. En als je die test-omgeving niet hebt dan zie ik dat als teken dat jij (of de opdrachtgever) het systeem niet echt belangrijk vindt. Dan kun je ook wel eens een storing voor lief nemen omdat een patch niet goed is.

Ook als je geen testomgeving hebt blijft de rest van mijn betoog overeind staan. Je applicaties testen en monitoren moet je automatiseren. Ook, nee juist, in je productieomgeving is monitoren heel belangrijk. Hoe meer automatische controles je hebt hoe meer vertrouwen je kan hebben dat er geen onverwachte problemen ontstaan en dat je snel kan reageren als ze toch ontstaan.

De echt grote en wijdverspreide problemen zijn binnen 2 dagen na Patch Tuesday wel uitgebreid in het

Maar ik heb ook gezien dat het fors meer dan die twee dagen duurt. Iedere organisatie is anders en hoe meer handwerk hoe groter de variatie van geval tot geval.

Daarbij worden de echte grote bugs binnen 2 dagen misbruikt, zie bijvoorbeeld log4j, daar werden wij binnen 24 uur na publicatie mee lastig gevallen.

Uiteindelijk is het allemaal een trade-off tussen prijs, beschikbaarheid en veiligheid. Natuurlijk komt daar niet altijd en overal dezelfde beslissing uit. Door te automatiseren kun je de verhoudingen veranderen.

[The Realone]

Kijk, je reactie is nu al vele malen genuanceerder dan je eerdere en dat was mijn punt.
IT kan een zwart geld zijn als het op geld aan komt. Organisaties, groot en klein, dienen prioriteiten te stellen en ik ga niet ontkennen dat je met een (goede) testomgeving aardig wat vinkjes kunt zetten, maar de praktijk is vaak anders. Het budget voor IT is altijd beperkt en ik heb genoeg organisaties gezien waar het geld naar andere zaken gaat die (nog) niet op orde zijn. Denk aan endpoints security, backup/disaster recovery, enz. Allemaal zaken die je op papier allang afgevinkt zou moeten hebben in een ideale wereld. Maar elke euro kun je maar 1 keer uitgeven en een FTE werkt 40 uur per week. Dan is het geen gek idee dat ze die testomgeving maar even aan de kant schuiven ten faveure van een betere backup strategie, of het risico van ransomware mitigeren, om maar wat voor de hand liggende zaken te noemen. Als het uitstellen van updates met een paar dagen daarin helpt, dan is dat geen domme keuze. Sowieso is het patchen van servers een x-aantal dagen na Patch Tuesday zeer gebruikelijk. Ik werk inmiddels voor een heel grote jongen en de servers die in de Early group zitten verbleken met de servers in de Normal of Late.

Als laatste wil ik nog zeggen dat een testomgeving geen golden bullet is. De capaciteit vrijmaken om dit op te zetten is 1 ding, maar je dient dit ook zeer secuur te onderhouden. Onlangs ging hier nog iemand de mist in omdat een ander de installatie van .NET 4.8 getest had op de testomgeving maar nooit doorgevoerd in productie. Tegelijkertijd de change in de testomgeving niet ongedaan gemaakt en bij de applicatieupgrade op test kwam een probleem niet naar voren die bij de andere .NET versie speelde.
Dat klinkt nogal knullig, maar ook dat is de praktijk.

[CAPSLOCK2000]

Kijk, je reactie is nu al vele malen genuanceerder dan je eerdere en dat was mijn punt.

Organisaties, groot en klein, dienen prioriteiten te stellen

Maar elke euro kun je maar 1 keer uitgeven en een FTE werkt 40 uur per week

Ik schets een ideaal einddoel. Ideale plaatjes zijn nooit genuanceerd. Als al het andere gelijk is, dan is een situatie met testomgeving is altijd beter dan een zonder, daar zijn we het denk ik wel over eens. Dat je niet alles tegelijk kan maar moet prioriteren is ook normaal. Mijn punt is dat de prioriteiten vaak verkeerd liggen en dat een testomgeving en geautomatiseerd testen en patchen worden onderschat en te weinig prioriteit/budget krijgen.

Dat andere zaken ook niet geregeld zijn is een verklaring maar geen excuus.
Als ik met een auto de weg op wil zal die auto op alle wettelijke verplichtingen moeten voldoen. Als ik zonder licht rijd kan ik ook niet tegen de politie zeggen dat ik het belangrijker vond om mijn remmen te laten repareren en dat ik geen geld of tijd had voor de lichten.

IT groeit altijd, "slimmer werken, niet harder" is misschien wel het belangrijkste principe in de IT. Een belangrijk deel daarvan is dat je zoveel mogelijk door de computer moet laten doen. Als je een goed georganiseerde IT-omgeving hebt dan zou het opzetten van een testomgeving een kleine moeite moeten zijn. Natuurlijk zijn een hoop omgevingen nog niet zo goed, maar daar zouden wel naar toe moeten werken.

Als het uitstellen van updates met een paar dagen daarin helpt, dan is dat geen domme keuze.

Als je in de tussentijd gehacked wordt dan was het wel een domme keuze. Uiteraard is het uiteindelijk een afweging tussen belangen en er is hoe dan ook altijd een vertraging tussen het moment dat een patch uitkomt en dat die daadwerkelijk op je server staat. Je wil de periode van uitstel zo kort mogelijk maken. Een goede /automatische/ testomgeving helpt daar enorm bij.

Misschien moet ik nog even benadrukken dat het "automatisch" het belangrijkste aspect is. Ook als je geen testomgeving hebt dan wil je het beheer van je systemen nog steeds automatiseren. Ook de beslissing om standaard 3 dagen te wachten met patchen kun je automatisch uit laten voeren.
Essentieel daarbij is dat het testen/monitoren ook automatisch is. Dat heb je toch nodig voor je productieomgeving. Als de applicatie gecrasht is of het SSL-certificaat gaat verlopen dan wil je dat zo snel mogelijk weten, of dat nu in test of productie is.

Als laatste wil ik nog zeggen dat een testomgeving geen golden bullet is.

Uiteraard want die gouden, of zilveren (hey Fred Brooks), kogels bestaan niet
Een testomgeving is een belangrijk middel om dit mogelijk te maken maar geen doel op zich. Voor we het te ver op blazen: in mijn eerste post ging er maar één zin over de test-omgeving en ik doe inderdaad de aanname dat je die hebt, dat hoort bij een goede omgeving net zoals ik er van uit ga dat er een professionele beheerder is die regelmatig patches installeert en dat die patches er uberhaupt zijn.

Mijn belangrijkste boodschap is dat je alle stappen van beheer moet automatiseren. In dit specieke geval heb ik het dan vooral over patches installeren en je systemen monitoren. Als je alles netjes automatiseert dan is een test-omgeving een (relatief) kleine moeite want die rol je dan ook automatisch uit. En als je eenmaal zo'n test-omgeving hebt dan is het verder automatiseren van je omgeving een stuk makkelijker. Daarom is het een uitstekende investering en een van de eerste dingen die je zou moeten doen als je een IT-omgeving op zet.


Dat de praktijk vaak niet goed is doet niks af aan het ideaalbeeld waar je naar toe wil werken.

De capaciteit vrijmaken om dit op te zetten is 1 ding, maar je dient dit ook zeer secuur te onderhouden. Onlangs ging hier nog iemand de mist in omdat een ander de installatie van .NET 4.8 getest had op de testomgeving maar nooit doorgevoerd in productie. Tegelijkertijd de change in de testomgeving niet ongedaan gemaakt en bij de applicatieupgrade op test kwam een probleem niet naar voren die bij de andere .NET versie speelde.
Dat klinkt nogal knullig, maar ook dat is de praktijk.

Je bewijst mijn stelling Dit soort situaties is precies waar het om gaat.
De kern van het probleem is dat iemand met de hand iets heeft geïnstalleerd en (waarschijnlijk) door menselijke slordigheid is dat nooit op productie terecht gekomen en het is ook niet opgemerkt dat er verschillen waren tussen test en productie.

In mijn ideale wereld zou die patch zijn getest in een vers geinstalleerd testomgeving. Als al je automatisch tests laten zien dat het goed gaat dan bouwt het systeem een nieuwe productieomgeving die exact identiek is aan de testomgeving (uiteraard met uitzonder van wachtwoorden en ip-adressen enzo).
Vervolgens wordt die nieuwe productieomgeving actief. Blijkt later dat er toch iets mis gaat dan (her)bouw je een productieomgeving volgens de vorige specificatie en ga je daar naar terug zodat je ademruimte hebt. Vervolgens ga je het probleem repliceren en los je het op. Daarna voeg je een automatische test op dit probleem toe aan je monitoringsysteem zodat je het de volgende keer wél in de testomgeving vangt.

Hoe verder je het hele proces automatiseert hoe sneller je het vertrouwen hebt dat een bepaalde patch naar productie kan omdat a) de functionaliteit hebt bewezen in je test en b) snel kan schakelen (vooruit of achteruit) als er toch nog iets mis gaat. Uiteraard is dit een continu proces, niemand kan vooraf alle mogelijke fouten en problemen voorzien. Je doet wat je kan en bij ieder prolbeem dat je tegenkomt verbeter je systeem verder. Als je een beetje schaal hebt wordt het steeds makkelijker om nieuwe systemen toe te voegen omdat die gebruik kunnen maken van controles die je voor andere systemen hebt ontwikkelt.

Voor de programmeurs, wat ik hier omschrijf is eigenlijk "test driven development" maar dan voor systeembeheer. Maar in plaats van alleen de applicatie test je het gehele systeem.

[mlohnen]

Niets op aan te merken, mee eens!
Dacht alleen eerst dat je bedoelde volledig geautomatiseerd dus gewoon de updates meteen erop

[Zezura]

L2TP VPN verbinding onmogelijk.
Verschrikkelijke bug.

[Reactie gewijzigd door Zezura op 23 juli 2024 15:16]

[Aardedraadje]

Net zo tekenend is dat CVE-2022-21984, remote code execution, niet als kritiek wordt gezien. Dat anderen op afstand jouw servers overnemen is blijkbaar gewoon.

Je laat wel belangrijke nuance weg: dit kan namelijk alleen als Dynamic Updates ingeschakeld staan, en die staan standaard uit. Dus daarom niet kritisch.

Edit: Blijkbaar is Dynamic updates wel een veel voorkomende configuratie, dus behoorlijk flauw van Microsoft om zich daar achter te verschuilen.

[Reactie gewijzigd door Aardedraadje op 23 juli 2024 15:16]

[CAPSLOCK2000]

Je laat echt wel belangrijke nuance weg: dit kan namelijk alleen als Dynamic Updates ingeschakeld staan, en die staan standaard uit. Dus daarom niet kritisch.

tnx, dat is inderdaad een belangrijk detail, ik heb me verder niet inhoudelijk in de meldingen verdiept. "remote code execution" komt automatisch in een vrij hoge klasse van ernst terecht.
In mijn wereldje is Dynamic Updates overigens een belangrijke feature die volop gebruikt wordt, in mijn beleving is het iets dat veel gebruikt wordt, maar ik zit dan ook erg ver in die hoek.

[beerse]

Groot gelijk. Maar een toevoeging: Patch niet alles tegelijk!
Bij meervoudig uitgevoerde systemen zoals ook geclusterde systemen en ook ad-domain-controllers, altijd 1 node patchen en testen of alles blijft werken. Dat testen kan heel goed door alles een paar dagen te laten draaien. Daarna in 2 of 3 blokken de overige systemen.

Voor het testen van de patches moet je ook de backup testen, dus tussen het patchen van 2 nodes van een cluster moet ook een backup zitten. Dat kan in veel gevallen een nachtje doorlooptijd hebben.
Ook het overzetten van de active node van een cluster moet altijd beide kanten op getest worden. En het overzetten van active cluster nodes moet je nooit te snel achter elkaar doen. Daarmee heb je voor die test al 2 'onderhouds momenten' nodig want een geplande node-switch doe je niet in bedrijfstijd.

Daarbij kan het ook helemaal geen kwaad om geduld te hebben. Zeker met kleinere omgevingen is het helemaal niet erg om een paar dagen te wachten om te zien of de markt de patches gewoon ontvangt of dat er berichten komen van uitdagingen met patches en/of de installatie.

Om kort te gaan: Ja regelmatig en bewust patchen is een must voor een professionele omgeving. Daar een beleid voor hebben en je daar aan houden, inclusief niet doorgaan met patchen als er wat aan de hand is maar in dat geval uitzoeken en zelf bepalen wat het beste is. Blind er in springen met de hele organisatie is nooit een goed idee.

[Reactie gewijzigd door beerse op 23 juli 2024 15:16]

[CAPSLOCK2000]

Groot gelijk. Maar een toevoeging: Patch niet alles tegelijk!
Bij meervoudig uitgevoerde systemen zoals ook geclusterde systemen en ook ad-domain-controllers, altijd 1 node patchen en testen of alles blijft werken. Dat testen kan heel goed door alles een paar dagen te laten draaien. Daarna in 2 of 3 blokken de overige systemen.

Goed punt, ik heb systemen die (zonder handmatige override) weigeren om te rebooten als hun partner niet beschikbaar is. In mijn ideaalbeeld zou dat ook gekoppeld zijn aan monitoring zodat er slim gekeken kan worden naar de totale toestand van een server maar zover ben ik nooit gekomen.

Voor het testen van de patches moet je ook de backup testen, dus tussen het patchen van 2 nodes van een cluster moet ook een backup zitten. Dat kan in veel gevallen een nachtje doorlooptijd hebben.

Goed punt van die backup. Overigens zijn moderne backupsystemen zo goed en snel dat de meeste van mijn systemen maar een paar minuten nodig hebben, daar zou je op kunnen wachten.

Ook het overzetten van de active node van een cluster moet altijd beide kanten op getest worden. En het overzetten van active cluster nodes moet je nooit te snel achter elkaar doen. Daarmee heb je voor die test al 2 'onderhouds momenten' nodig want een geplande node-switch doe je niet in bedrijfstijd.

Ik ben daar best extremistisch in. Ik vind dat je dit soort dingen in principe wel in bedrijfstijd moet doen. Dan zijn je mensen fris en aanwezig. Als er iets mis gaat kun je er dan iets aan doen. Wat je in mijn ogen moet voorkomen is dat er een probleem ontstaat dat moet worden opgelost door een vermoeide beheerder die in z'n eentje de nacht moet doorploeteren terwijl alle hulp en ondersteuning ligt te slapen.
Daar komt mijn andere principiele punt bij, als iets zo belangrijk is dat je het niet kan missen dan moet je voldoende redundantie hebben. Zelf probeer ik systemen die dubbel zijn uitgevoerd te vermijden en direct voor drievoudig te gaan. Dan kun je nog eens een van die systemen onderhouden zonder dat een SPOF te scheppen op de andere node. Drie is ook handiger in situaties waar er iets stuk is en je moet beslissen welk systeem je nog kan vertrouwen.

Uiteindelijk bestaan er geen systemen die nooit uit mogen, net zoals er geen systemen bestaan waar nooit iets fout gaat. In praktijk is alles een compromis tussen beschikbaarheid en prijs (en nog wat andere factoren). Maar de oplossing "afblijven" is de minst goede.

Netflix heeft het andere uiterste opgezocht. Daar draait een stuk software dat "chaosmonkey" heet. chaosmonkey schiet random processen af in de Netflix omgeving. Daar worden dus voortdurend opzettelijk dingen stuk gemaakt. Hun redenatie is dat hun systeem zo stabiel is, of moet zijn, dat klanten daar niks van merken. Ieder onderdeel moet op een willekeurig moment stuk kunnen gaan zonder dat de streams worden onderbroken.

Daarbij kan het ook helemaal geen kwaad om geduld te hebben. Zeker met kleinere omgevingen is het helemaal niet erg om een paar dagen te wachten om te zien of de markt de patches gewoon ontvangt of dat er berichten komen van uitdagingen met patches en/of de installatie.

Ook dat is weer een afweging. Ik ben blij dat wij geen week hebben gewacht om lo4j te patchen, dan waren we nat gegaan.

[beerse]

Over het overschakelen van cluster nodes tijdens productie tijd heb je in theorie wel gelijk. Maar in de praktijk zijn er veel te veel cluster systemen die bij het overschakelen de bestaande connecties laten crashen en dat wil je de klanten niet aan doen. Het overschakelen van actief/passieve clusters doe je daarom het liefst juist voor het begin van de productie tijd (zeg: 07:00). Detail: We hebben het hier over msWindows patches en dus over msWindows clusters. Die zijn in de regel active/passive.

Over 3-voudige (en meervoudige) clusters: Die zijn alleen interessant als alle nodes tegelijk actief zijn. Daarbij kan je in de regel wel een node uitschakelen zonder dat het de productie verstoort. Daarbij zou ik het omschakelen ook het liefst midden op de dag doen, bijvoorbeeld aan het einde van de lunch.

Dat ze bij netflix zoiets als 'chaosmonkey' hebben kan ik goed snappen. Dat zal qua beschikbaarheid en performance wel vergelijkbaar zijn met de grote constructie achter de google-zoek-machine. Maar dat zijn systemen die gewoon heel veel van de zelfde kleine acties doen: Web verzoeken van de klanten oppakken en verwerken. Bij netflix is dat het volgende blok van de film in jou buffer zetten. Bij google is het de volgende set van 20 zoek-antwoorden oplepelen.


Enneh over het lo4j issue en bijgaande patches: er waren meerdere mogelijkheden om die te pareren. Als je voor het uitkomen van de patches de installaties hebt geïsoleerd of anders hebt beveiligd, kan je de tijd nemen voor het patchen.

[gimbal]

"Dat anderen op afstand jouw servers overnemen is blijkbaar gewoon." - Na meer dan een decennia aan fixes te hebben gezien voor remote code execution exploits, eigenlijk wel ja.

Het is nog steeds niet acceptabel, maar wel gewoon. Het valt binnen de verwachtingen dat iemand dat ergens kan doen.

[jmvdkolk]

Er zijn ook operating systemen die vanaf de grond af beter gebouwd zijn, waarbij patch early, patch often, patch automatically niet nodig is. Sommige van die systemen lijken qua directe kosten duurder, maar de vraag is of ze ook echt duurder zijn als al deze ellende ermee voorkomen wordt. Dat is een andere aanpak die ook tot stabiele systemen leidt. Zo'n andere manier is natuurlijk niet de enige manier en nadenken hoe security voor Windows beter gemaakt kan worden is natuurlijk een goed idee.

Voor wie een idee wil hebben, ik doel bijvoorbeeld op IBM z/OS, het mainframe systeem waarvan al meer dan 30 jaar de dood wordt voorspeld.

[Highlands]

Bah patchen van systemen? Wat 1999. Lekker automatisch laten uitvoeren op de desktop. In het datacenter lekker door AWS/ Microsoft laten doen op hun SaaS/PaaS diensten.

[Climbon]

Even wat ademruimte is ook wel prettig na alle kritieke lekken de afgelopen maanden. Probleem bleek vaak ook niet eens zozeer het lek zelf te zijn maar ook de negatieve effecten van de patch. Voorafgaand aan de patchronde altijd even de ervaringen in het sysadmin subreddit polsen was vaak hard nodig.

[Polderviking]

Voorafgaand aan de patchronde altijd even de ervaringen in het sysadmin subreddit polsen was vaak hard nodig.

Ik update die ene Windows server die ik nog heb vaak net vóór patch teusday (meestal in het weekend) en houd idd ook o.a. die subreddit en het ict nieuws in de gaten, mits er niets kritiekerigs is uiteraard, dan heeft eventuele ellende een maand om om naar de oppervlakte te komen borrelen.

Vroeger vertrouwde ik updates eigenlijk blindelinks maar daar ben ik wel van genezen sinds het aanbreken van het Windows 8/10/11 tijdperk.

[Reactie gewijzigd door Polderviking op 23 juli 2024 15:16]

[Toff]

[...]
dan heeft eventuele ellende een week om om naar de oppervlakte te komen borrelen.

Je bedoelt een maand...

[Polderviking]

Yes, aangepast. Brainfart.

[skralan]

Voor de mensen die zich afvragen wat een CVE is (moest het zelf ook even opzoeken):
CVE - Common Vulnerabilities and Exposures

https://en.wikipedia.org/...erabilities_and_Exposures

[Chilly_Willy]

Wel erg dat het nieuws en opvallend is dat er geen enkele kwetsbaarheid de kritiek rating heeft

[L0g0ff]

Jammer dat je zo gedownmod wordt. Maar je slaat wel de spijker op zijn kop.

Laten we hopen dat het ook rustig blijft na het patchen van deze 51 fixes want sinds de zomer vorig jaar gaat het patchen van de MS updates niet helemaal soepel.

/edit

Toch denkt onze eigen ncsc wel iets zwaarder over de huidige patch ronde.

Ik denk als we een maandje wachten dat die important vanzelf critical gaan worden.

https://advisories.ncsc.nl/advisory?id=NCSC-2022-0105

[Reactie gewijzigd door L0g0ff op 23 juli 2024 15:16]

[lenwar]

Nou ja... Erg niet. Maar wel opvallend. Het zegt ook vooral iets over de complexiteit van de systemen die zij hebben ontwikkeld. Een besturingssysteem is een soort ecosysteem/organisme met een (gechargeerd) ontelbaar aantal factoren, die ieder kritieke fouten kan bevatten. En dan hebben we het alleen nog maar over de Windows platformen. Daar komen de Hyper-V en Azure platformen nog bij.

Het doet me eigenlijk eerder afvragen hoeveel ongepubliceerde kritieke zaken er nog open staan, die volgende maand (of later?) pas worden gepatched. Ik bedoel dit niet flauw of denigrerend richting wie dan ook overigens, want met het portfolio van Microsoft is het bijna onrealistisch dat er niet minimaal iedere maand wel een aantal kritieke patches moeten zijn.

[Boeshnl]

Mijn grootste vraag is dan. Is de bug van de random reboot van de AD server ook opgelost?

[wildhagen]

Die was 3 weken geleden al gepatched: nieuws: Microsoft publiceert Windows-fixes voor vpn-issues en bootloop domein...

[Paul Evenhuis]

Windows 10 is best een goed beestje

[ggj87]

Ik vind het de beste Windows tot nu toe. Er mag alleen nog minder bloatware in zitten. Je kunt een hoop weghalen maar niet alles. Zou wel leuk zijn als je dat zelf kan verwijderen

[Dennisb1]

Ik durf onze systemen momenteel niet eens te updaten. Heb al een maand lang last van een schala aan problemen hier op de zaak na de vorige update ronde... Ook na een rollback.

Laat staan de VPN issues met L2TP en ipsec. De lachwekkende optionele update die je met moeite moet installeren helpt niet altijd om dat probleem te fixen.

Onze Citrix farm heeft nog het meeste last, de helft van de Citrix farm staat inmiddels uit en de andere helft lijkt er vreemd genoeg (nog) geen last van te hebben. Citrix heeft nog geen patch weten te maken maar de Citrix Universal DLL Injection Driver crasht met behoorlijke regelmaat sindsdien ondanks de rollback. Forum staat er vol mee bij Citrix.

[Reactie gewijzigd door Dennisb1 op 23 juli 2024 15:16]

[iliaswhoelse]

Hopelijk is het dit keer ook een simpele update en gaan er niet x aantal andere dingen kapot.

[tweakkjoost]

Bij mij draait m'n windows 11 systeem stukken beter. Ook de verkenner reageert lekker snel.

[beerse]

Dergelijke geluiden heb ik bij iedere upgrade van msWindows gehoord. Wxp was beter dan W2k, W7 was beter dan Wvista, W10 was beter dan W8 en van de tussen liggende updates/upgrades viel ook vaak wel iets positiefs te horen.

Uiteindelijk is het mijn ervaring dat de nieuwe versie als schoon en nieuwe installatie wordt vergeleken met een systeem dat al een paar jaar draait en een redelijke update geschiedenis achter de rug heeft. Een frisse installatie van Wxp was ook altijd beter dan een lang-lopende. Een frisse (eigen) W10 installatie is ook altijd beter dan een installatie die al een tijdje mee gaat.

Eerlijk is eerlijk, van de oudere upgrades heeft microsoft altijd aangegeven dat een verse installatie de beste is en dat een upgrade niet echt uitgebreid werd ondersteunt, waar met de huidige stap van W10 naar W11 aanvankelijk alleen als upgrade beschikbaar was.

[gimbal]

"Een frisse (eigen) W10 installatie is ook altijd beter dan een installatie die al een tijdje mee gaat." - niet noodzakelijk. Eigenlijk vanaf Windows 8 merk ik nog maar weinig van verpaupering over de tijd heen. Ja omdat mijn SSD begon vol te slibben en dan niet dankzij het OS maar dankzij specifieke stukken software die tijdelijke bestanden aanmaken alsof het geen tijdelijke bestanden zijn.

Windows 7 en below was het op een gegeven moment dat de harddisk 5 minuten na booten nog steeds volop aan het ratelen was en geen cleanup die dat nog ging verbeteren. Dan was het inderdaad wel tijd om naar een frisse installatie te gaan (ik ging zelf voor elke 6 maanden). Nooit echt begrepen wat dat nu precies veroorzaakte, het enige wat ik wel eens gelezen heb is dat het met de grote hoeveelheden DLLs te maken had die software in de Windows directory wilde deponeren.

[Reactie gewijzigd door gimbal op 23 juli 2024 15:16]

[McNutters]

weet Microsoft deze keer wel zeker dat er "geen enkele kritieke bug" is?

[beerse]

Microsoft heeft geen enkele patch als kritiek aangewezen. Daarmee kan ze voor jou nog steeds kritiek zijn, dat is ook afhankelijk van jou invulling van 'kritiek' en 'patch' of 'bug'.
Natuurlijk zijn er nog wel kritieke bugs in de diverse systemen die door deze patchbundels worden bijgewerkt.

Uiteindelijk zijn er heel veel organisaties die op hun eigen manier naar microsoft en de patches kijkt en afhankelijk van opmerkingen bij patches gaan bepalen of ze bepaalde patches wel of niet gaan invoeren of dat ze er wel of niet een bepaalde spoed achter zetten.

Microsoft heeft 1 (één) patch advies en dat is alle patches doorvoeren op het moment dat ze uitkomen. Niet een onderscheid maken tussen kritiek of niet kritiek. Niet een onderscheid maken tussen bugs en functionele updates, Niet een onderscheid maken tussen drivers en software en firmware.

[MischaBoender | IA]

Nee, die wordt over een paar dagen pas bekend gemaakt en dan krijgen we een critical out-of-band security update.