Ik gebruikte de dinsdag t/m de vrijdagmorgen om de wereld te laten betatesten en zette vrijdagmiddag na het lezen van
de bekende forums (geen vervelende problemen met KBxxxxxx?) de updates in een testomgeving om ze dan in het
weekend uit te kunnen rollen. Dat heeft altijd goed gewerkt. Nu doet een extern bedrijf het en die wachten altijd tot
de laatste donderdag van de maand. Zit ik verder niet mee, het is nu hun verantwoordelijkheid.

Of ze konden ook gewoon de keuze geven aan de eindgebruiker en de IT dienst, in plaats van die keuze voor ons te maken. Wanneer er nu bijvoorbeeld exploits worden gepatched weet je dit maar pas die dinsdag. Dat noemt "Security by obscurity" en is een doorn in de IT wereld.

Je kan zeggen van Microsft wat je wilt maar het patchmanagement beleid van Microsoft is nog steeds iets waar meerdere leveranciers (GOOGLE ANDROID !)een voorbeeld aan kunnen nemen.

Dit is juist een requirement in het bedrijfsleven? Voorspelbaarheid is van groot belang. Je weet nu al wanneer je changes, hebt in je infrastructuur, of juist wanneer je bepaalde changes niet moet inplannen. Je kan je resources hiervoor gereed hebben, zonder adhoc acties te moeten uitzetten.

In een Enterprise van groot belang.

Ik weet het niet hoor, maar het updatebeleidssysteem van de meeste Linux distro's, dáár moet men een voorbeeld aan nemen. Zodra er een patch is, meteen uitsturen die hap. Vaak lees ik ergens een veiligheidslek, en nog geen moment erna zit 'ie al in de updates. Zó hoort het. Wachten tot de derde dinsdag is belachelijk. Als er een veiligheidsissue bekend wordt op de dag ná die "patch tuesday" ben je dus een maand lang kwetsbaar. Hoe stom is dat?

Volgens mij wisten we dit al. (of zouden het kunnen weten)

Bijv. https://www.security.nl/posting/365341/Microsoft+patchdinsdag+bestaat+10+jaar

Als je de update om 19.00 doet, is er niet alleen de maandag om dingen op te pakken. Of werken beheerders nooit op een dinsdag gedurende kantoortijd?

De blog is gericht op de Amerikaanse tijd (10:00 's ochtends Pacific Time)

ik bepaal wanner ik update en niet ms, wacht af wat er nu weer verkeerd is gegaan !!!!!!!!!!!

En hoe denk je dat grote bedrijven dit aanpakken? Dat zie iedere security update werkelijk meteen gaan patchen? Vergeet niet dat in een bedrijf er vaak een test traject vooraf gaat, voordat updates geïnstalleerd worden. Bij een update ieder moment, loopt je dus altijd te updaten, en voordat je update geïnstalleerd is, is de volgende al uit, en kan al weer opnieuw beginnen.

Of hoe denk je dat dit met je eind gebruikers gecommuniceerd kan worden. Updates kunnen op ieder moment geïnstalleerd worden? Of meerdere keren? Of hoe denk je dat ind gebruikers het vinden als iedere x dagen reboots krijgt voor updates?
Of als er security updates uitkomen en deze week is zijn er diverse andere changes planned.

Dat wordt niet geaccepteerd, dus worden updates uit uitgesteld.

Je weet het inderdaad niet. Door de ketenafhankelijkheden krijg je dat er nooit voor elkaar. Het onverwacht instorten van het systeem omdat e rf met succes updates op het os zijn uitgevoerd heeft tot veel te veel problemen geleid.
In het uitzonderlijke geval dat er snel een update uitgerold moest worden bleek dat ook op een Windows Desktop goed mogelijk te zijn en dat centraal gecontroleerd aangestuurd. Iets wat met linux onmogelijk bleek. Ik praat dan over 20k + desktop doosjes met volledige stacks..

Weer zo'n zinloze rapportage uit de kleine karma4 omgeving. De ervaringen die jij hebt, in jouw kleine wereldje, zijn niet representatief voor de grote mensen werkelijkheid. Dat wil je maar niet vatten niet?

Microsoft is ook weer niet zo stom hoor. Als er echt iets aan de hand is, brengen ze echt wel een 'out-of-band' update uit, dit hebben we de afgelopen jaren regelmatig meegemaakt!

In onze omgeving (50.000 gebruikers) hebben we een volledig opgetuigde test omgeving en een chain van WSUS servers.
De test omgeving krijgt direct alle updates en als blijkt dat die geen problemen veroorzaken dan gaat het (afhankelijk van de server en plaats in het netwerk) binnen 1 of 2 weken naar productie.

EEA is behoorlijk eenvoudig op te tuigen, maar dan wel een 100% betrouwbare test omgeving :)
Na de juli updates bleek onze test AD Azure sync server prima te werken maar toen de .NET update naar productie ging niet. Maar goed; Les geleerd en nu zijn die 2 ook exact hetzelfde.

Zeker als je je servers gevirtualiseerd hebt is een (kleine) testomgeving helemaal niet zo lastig. Voor wat extra RAM- en DISK-ruimte (CPU is normaal gesproken niet van belang) is zoiets onbetaalbaar.
Bij ons is ook de "eigenaar" van de server van belang en is onderlinge communicatie key; Als er een ESET update komt voor onze AV server dan is er altijd overleg tussen de diverse beheerders bijvoorbeeld.

Als ik kijk naar de falende instanties (US overheid komt vaak in het nieuws met gehackte systemen) dan ben ik wel blij dat ons IT team veel te zeggen heeft. Iedereen, van manager tot accountbeheerder tot basale beheerder in ons team komt uit de praktijk en kan invloed uitoefenen. En we voelen ons verantwoordelijk. Dat gevoel mis ik bij al die instanties die ten prooi vallen aan niet of slecht IT beheer "omdat dat geld kost" en de conciërge verantwoordelijk maakt voor de IT Infra.
Je mag goed beheer en procedures verwachten maar de praktijk wijst heel anders uit. En vaak is het dan "hoe groter, hoe slechter" want verantwoordelijkheid is makkelijk af te schuiven en "het is 16:55 dus ik ga naar huis".

Schoovoorbeeld hoe het moet en hoe het moet werken.

Helaas zit hier vaak het probleem, OS staat hier helemaal los van. Het is verantwoordelijkheid krijgen, nemen en doen.

Die komen toch 3-4 keer per dag? Zitten jullie de hele dag in overleg dan?

Dan is deze read ook wel even interresant :


Klaarblijkelijk zijn er toch wel wat IT experts en gebruikers die issues hebben en bewust achter lopen met updates wat dus weer flinke implicaties voor security algemeen heeft.

en hier de follow up:

https://www.computerworld.com/article/3294984/microsoft-windows/windows-updaters-express-frustrations-microsoft-responds.html

tja . . . een groot bedrijf met commerciele belangen, die blijven gewoon doen waar ze zin in hebben en je kijkt maar of je mee wilt of niet dus . . . het zal ze in de centjes pijn moeten gaan doen voordat ze bijsturen weer.

Dit betreft waarschijnlijk applicatie updates, niet definitie updates.

Het wereldje van de evangelist is de beperking op wat er werkelijk speelt. De reactie van op de man spelen is zijn onvermogen om open te staan voor wat er gebeurt. Kijk even naar de post van Nedfox. Er zijn er meer dan ik die wel open staan voor wat organisatie nodig hebben. Je hebt LHM niet gevolgd? Ongelooflijk hoe die vast zaten in een os gebeuren en de organisatie lieten barsten. Het lijkt verdacht veel op de ten onder gegane communistische geleide economie.

Dit werkt niet in een Enterprise omgeving.

Als alles goed is ingeregeld wordt een een test daarna een acceptatie en daarna een productieomgeving geupdate.

De (thuis)eindgebruiker heeft nog steeds een keuze wanneer hij/zij de updates installeert. De eindgebruiker op de werkvloer heeft niks te zeggen over de updates natuurlijk.

er zijn ook situaties (enterprise omgevingen van een ander type) waarbij een OTAP in zijn puurste vorm en of striktste zin een onmogelijk kostbare aangelegenheid is =>

1) en dus is je absoluut geformuleerde stelling onjuist.
2) alternatieve maatregelen en werkwijzen worden gehanteerd die misschien ook nog wel eens zouden kunnen werken en tot verbeteringen kunnen resulteren in die traditionele OTAP waterval clubjes.

Ik zei ook als het goed ingeregeld is.

Het klopt dat niet iedere Enterprise omgeving een test-acceptatie omgeving heeft.

Dit neemt niet weg dat als je updates kunt testen je dit ook moet doen.

Daarom is het zo handig dat Microsoft een vast moment in de maand heeft waarop updates uitkomen

Dat is wel erg lang met de huidige snelheid waarmee criminelen na een patchronde hun malware hebben aangepast.
Bij ons gaan de testsystemen op donderdag door de cyclus. Die worden uitgebreid getest en op vrijdag gaat productie over naar de nieuwe versies. Dan komen de dinsdag erna nog een paar minder kritieke systemen.
Sinds we het op deze manier doen, hebben we misschien 1 of 2 minor problemen gehad. Die waren eigenlijk allemaal terug te voeren op verkeerde configuraties i.p.v. verkeerde patches.

Peter

alleen een relevant argument als in de praktijk gebeleken is dat updates issues opleveren, nietwaar? wat ik bedoel te stellen is dat hele OTAP gedoe een reactie is op een wellicht onwenselijke situatie die misschien ook anders kan zijn?

Valt wel mee hoor. Ik heb hier een omgeving met 5000 desktops, waarbij we pas na 3 weken de updates installeren op de productie omgeving. En dat is nog vrij snel.