Thema topic: vaste patchdagen producenten nuttig of onzin

[Bor]

Thema topic: vaste patchdagen producenten nuttig of onzin?

Welkom in weer een nieuw thema topic.

Onlangs zijn we gestart met een aantal nieuwe items in het Beveiliging & Virussen forum. Een nieuw item zijn de thema topics waarin ruimte is voor discussie over een bepaald wisselend onderwerp. Deze maand hebben we gekozen voor een thema rond het melden de vaste patch dagen die diverse leveranciers hanteren.

Steeds meer leveranciers / producenten van software volgen een systeem waarbij men patches uit brengt op een vaste dag in de maand. Een van de bekenste voorbeelden hiervan is Patch Tuesday van Microsoft maar ook andere bedrijven zoals Oracle volgen een soortgelijk model.

Het uitbrengen van patches op een vaste dag klinkt logisch maar is dit wel zo nuttig? Wat vind jij? Heeft het spreiden van het uitbrengen van patches, en security patches in het bijzonder eigenlijk wel duidelijke voordelen voor de gebruiker of draait het vooral om voordelen voor de producten / leverancier zelf? Pas jij thuis of professioneel jouw patch schema aan op de vaste dagen waarop patches worden uitgebracht? Laat jou mening eens horen. Het is de bedoeling dat er een interessante discussie ontstaat rond dit onderwerp.

Suggesties voor komende thema topics.

Heb je een suggestie voor een volgend thema topic? Dan willen wij van jou horen!
Je kunt jouw suggestie achterlaten in het volgende topic: aankondiging: thema topics .

Natuurlijk kun je ook altijd een direct message te sturen naar een van de auteurs van dit thema topic.
Een direct message kun je versturen door te klikken op het icoon bij de naam van een van de auteurs van dit thema topic.

[Anoniem: 238498]

Ik denk dat het weining uitmaakt of het een vaste dag is of willekeurig. Zolang het procedureel goed is vastgelegd hoe met dit soort zaken om te gaan is het lood om oud ijzer. Nu heeft MS de dinsdag ingesteld, maar je blijft ook nog de out of synch patches houden. Kwestie van goede afspraken en werkinstructies.

Thuis staat hij gewoon ingesteld via auto update: download en vragen voor installatie.

[iisschots]

Stucky gemaakt.

Ik zelf het het liefst zo snel mogelijk nadat hij beschikbaar is de patches. Maar ik kan vanuit bedrijven wel begrijpen dat ze vaste dagen gebruiken.

[Exorcist]

Ik vind vaste dagen zelf prettig, zeker met MS updates. Naast de WSUS server, die gecontroleerd updates binnenhaalt en uitrolt, is het ook van belang om evt. onstane problemen ná patches te kunnen herleiden na de patchronde van de dinsdag.

Soms is het toeval, maar als er op woensdag problemen ontstaan kijk ik eerst de updates na

[EdwinG]

Naar mijn mening moet bij het patchen van software onderscheid gemaakt worden tussen twee patchtypes.

• Beveiligingsupdates;
• Functionele updates.

Beveiligingsupdates
Bij beveiligingsupdates denk ik dat het instellen van een patchdag niet alleen onzinnig is, maar zelfs schadelijk, zeker voor bedrijven die minder dan maandelijks een patchdag houden, zoals bijvoorbeeld Adobe met een kwartaalschema. Gelukkig wordt af en toe afgeweken met een out-of-band patch, zelfs door Microsoft, die toch maandelijks updates uitgeeft.
Ik vraag me bij zo'n patchcyclus altijd af waarom er eigenlijk gewacht wordt, zeker met beveiligingsupdates, die naar mijn mening gepubliceerd moeten worden zodra ze klaar (en uiteraard getest) zijn. Het lijkt me erg onwaarschijnlijk dat deze updates allemaal precies op de patchdag klaar zijn. Dus houden we drie opties over:

• De updates zijn voor het afronden vertraagd, zodat ze precies op tijd klaar zijn;
• De updates zijn eerder klaar, en hadden dus eerder verspreid kunnen worden;
• De updates zijn nog niet volledig getest bij uitgifte.

Nu kan er natuurlijk gezegd worden dat beveiligingsupdates best even kunnen wachten, mits er geen actief misbruik bekend is. Maar aan die redenering kleven twee bezwaren:

• 'bekend zijn': Wat als misbruik 'onder de radar' wel plaatsvindt?
• Als misbruik bekend wordt, ben je te laat. De update moet verspreid worden voor dat een lek actief misbruikt gaat worden, niet daarna.

Bedrijven (gebruikers van de software, in dit geval) kunnen altijd nog zelf een patchcyclus instellen, en besluiten of ze een uitgegeven update al dan niet direct installeren. Maar laat die keuze, zeker met beveiligingsupdates, wel aan de klant, en niet aan de producent.

Functionele updates
Voor functionele updates geldt een ander verhaal. Het in batches uitbrengen van updates kan het testen & implementeren van updates vereenvoudigen voor veel gebruikers. Bovendien zal support beter af te stemmen zijn op de updates. Dit kan de bereidheid om updates te installeren vergroten. Misschien helpen de patchdagen daarmee indirect om beveiligingsupdates te installeren.
Bovendien, als functionele updates op vaste tijden uitkomen, en beveiliginsupdates zo spoedig mogelijk, wordt het belang van de beveiligingsudpates nog eens benadrukt.

[Onbekend]

Aan de ene kant is het wel nuttig.
Op dinsdag komen de updates van Microsoft uit.
Als ik t/m donderdag geen negatieve berichten heb gelezen op de deze updates, zal ik ze ook gaan installeren. Eigenlijk is dat mijn installatiedag geworden.

Aan de andere kant maakt het mij totaal niet uit wanneer de updates worden aangeboden. Misschien is dat wel beter, en hoeven ze soms niet op maandag middag nog even snel een patch af te maken omdat hij dinsdag wordt uitgeleverd. Ze kunnen zo'n patch dan ook gewoon een dag daarna leveren.

Wat mij betreft mag een patch dus op elke dag aangeboden worden....

[sebastius]

Ik vind het een beetje raar. Ik krijg er niet het gevoel van dat ik (de consument) belangrijk ben en dat de patch zo snel mogelijk uitgebracht wordt. Nee, hij komt pas volgende week dinsdag. Dat is toch raar?

[alt-92]

EdwinG schreef op vrijdag 03 december 2010 @ 22:45:
Ik vraag me bij zo'n patchcyclus altijd af waarom er eigenlijk gewacht wordt, zeker met beveiligingsupdates, die naar mijn mening gepubliceerd moeten worden zodra ze klaar (en uiteraard getest) zijn. Het lijkt me erg onwaarschijnlijk dat deze updates allemaal precies op de patchdag klaar zijn. Dus houden we drie opties over:

• De updates zijn voor het afronden vertraagd, zodat ze precies op tijd klaar zijn;
• De updates zijn eerder klaar, en hadden dus eerder verspreid kunnen worden;
• De updates zijn nog niet volledig getest bij uitgifte.

Optie 2 dus, en optie 3 blijft altijd van kracht - simpelweg omdat je onmogelijk elke config bij een klant/enduser kan testen.

Nu kan er natuurlijk gezegd worden dat beveiligingsupdates best even kunnen wachten, mits er geen actief misbruik bekend is. Maar aan die redenering kleven twee bezwaren:

• 'bekend zijn': Wat als misbruik 'onder de radar' wel plaatsvindt?
• Als misbruik bekend wordt, ben je te laat. De update moet verspreid worden voor dat een lek actief misbruikt gaat worden, niet daarna.

'Security hotfixes zijn altijd een catch-22 geval.
Bij een 0day of een zogenaamde 0.5day exploit (en die laatste komen veel vaker voor dan een 0day) heb je al actief misbruik voordat je uberhaupt achter de oorzaak kan komen.
Daarnaast kan je ook nog eens een risico lopen door zo'n hotfix wel heel snel uit te brengen, maar het is een koud kunstje om die door een diff heen te trekken zodat je gelijk weet waar de vuln in zit.

En dan moet je een risico-afweging maken:
Een niet ITW voorkomende exploit zelf verspreiden en daarmee klanten die zich moeten houden aan change windows en procedures in direct gevaar brengen
Workarounds en mitigatietechnieken alvast in stelling brengen en het grootste deel van je klanten de gelegenheid geven zich voor te bereiden.

En aangezien het bedrijfsleven de grootste partij van belang is voor bepaalde leveranciers zal er ook meer gekeken worden naar een manier waarbij Change management en processen ingezet kunnen worden dan lukraak op elk moment van de dag één of andere fix uit te brengen.

[CAPSLOCK2000]

Zodra een patch uitkomt gaan krakers kijken of ze er misbruik van kunnen maken.
Als patches dus op willekeurige momenten uit komen moet een groot bedrijf permanent iemand klaar hebben staan om te reageren. Met vaste patch dagen is dat beter te controleren.

Voor gebruikers is het voordeel dat voorspelbaarheid geeft. Als er iets stuk gaat op patchdag dan kunnen gebruikers raden dat het probleem aan de patches ligt. Als beheerder kun je vaak toch niet helemaal overzien wat voor gevolgen een patch gaat hebben.

[Khaine]

CAPSLOCK2000 schreef op zaterdag 04 december 2010 @ 17:51:
Zodra een patch uitkomt gaan krakers kijken of ze er misbruik van kunnen maken.
Als patches dus op willekeurige momenten uit komen moet een groot bedrijf permanent iemand klaar hebben staan om te reageren. Met vaste patch dagen is dat beter te controleren.

Is dat niet juist andersom? De patches zijn er toch voor omdat de krakers niet wachten tot dinsdag met het publiceren/misbruiken van een lek? Patches fixen die lekken toch juist? Of bedoel je dat er bij het uitbrengen van een patch gezocht wordt naar systemen die die patch nog niet hebben, om zodoende dat lek te misbruiken?

Voor gebruikers is het voordeel dat voorspelbaarheid geeft. Als er iets stuk gaat op patchdag dan kunnen gebruikers raden dat het probleem aan de patches ligt. Als beheerder kun je vaak toch niet helemaal overzien wat voor gevolgen een patch gaat hebben.

Bij goede documentatie van een patch weet je als systeembeheerder juist heel goed wat er allemaal voor gevolgen zullen zijn. Je hoort van het netwerk / de systemen die je beheert te weten hoe deze op zijn gebouwd. Eventuele vervelende details door patches die custom settings overschrijven kunnen we heel lastig terug te vinden zijn, dat ben ik met je eens.


Zelf voor thuis maakt het mij weinig uit. Wanneer een patch binnenkomt (en dan heb ik het vooral over kernel-updates, voor zover je dat patch noemen kunt) trek ik meestal voordien een backupje.

[downtime]

Khaine schreef op zaterdag 04 december 2010 @ 19:10:
Is dat niet juist andersom? De patches zijn er toch voor omdat de krakers niet wachten tot dinsdag met het publiceren/misbruiken van een lek? Patches fixen die lekken toch juist? Of bedoel je dat er bij het uitbrengen van een patch gezocht wordt naar systemen die die patch nog niet hebben, om zodoende dat lek te misbruiken?

Vulnerabilities zijn vaak maar bekend bij een kleine groep mensen, bijvoorbeeld security specialisten, totdat Microsoft er een patch voor uitbrengt. Dan weet elke wannabe hacker van het lek en gaat op zoek naar mogelijkheden om het te misbruiken.

Overigens ben ik zelf wel voorstander van vaste dagen waarop patches gepubliceerd worden (voor zover het risico uitstel toelaat).
De voorspelbaarheid van een maandelijkse release maakt het mogelijk om lang tevoren het uitrollen van een patch te plannen zodat je binnen uren/dagen na de release up-to-date kunt zijn. Als je die voorspelbaarheid niet hebt, duurt het plannen (vooral in grote bedrijven) langer en zijn bedrijven langer kwetsbaar voor een risico wat snel toeneemt als Microsoft het bestaan van die vulnerability eenmaal bekend heeft gemaakt.

Uitzondering zijn natuurlijk de vulnerabilities waarvoor al exploits "in het wild" voorkomen, daarvoor moeten de patches natuurlijk wel direct uitgebracht worden, desnoods tussen reguliere releases in. Maar dat gebeurt ook wel.

[alt-92]

Khaine schreef op zaterdag 04 december 2010 @ 19:10:
Of bedoel je dat er bij het uitbrengen van een patch gezocht wordt naar systemen die die patch nog niet hebben, om zodoende dat lek te misbruiken?

Inderdaad
Je pakt de patch, en legt er de niet-gefixte files naast en voila; je weet waar je buffer overflow zit en schrijft (of copy/paste) je exploit daarop.

[dutch_camel]

downtime schreef op zaterdag 04 december 2010 @ 22:47:
... Overigens ben ik zelf wel voorstander van vaste dagen waarop patches gepubliceerd worden (voor zover het risico uitstel toelaat).
De voorspelbaarheid van een maandelijkse release maakt het mogelijk om lang tevoren het uitrollen van een patch te plannen zodat je binnen uren/dagen na de release up-to-date kunt zijn. Als je die voorspelbaarheid niet hebt, duurt het plannen (vooral in grote bedrijven) langer en zijn bedrijven langer kwetsbaar voor een risico wat snel toeneemt als Microsoft het bestaan van die vulnerability eenmaal bekend heeft gemaakt...

Sluit ik me bij aan. We hanteren in ons bedrijf Change Management, en willen niet ad-hoc van alles installeren. Sommige patches moeten we eerst testen. Wanneer er vaste dagen zijn dat we patches kunnen verwachten, kunnen we resources inplannen om te testen. In de sector waar ik werk is het wel belangrijk om te testen, omdat we ook tal van oudere systemen hebben staan, die juist niet gepatched moeten worden.
Daarbij wordt in sommige patches ongewenste toegevoegde functionaliteit aangeboden waar je niet op zit te wachten. Ook dat is prettig om (liever vooraf) te constateren voordat we het in de Productie omgeving gaan gooien, of los laten op een van onze Productie servers.

[mieJas]

Het lijkt me wel zo interessant dat security updates snel de deur uit kunnen en -in het slechtste geval- geen week moeten blijven liggen. De enige doelgroep die zoiets niet wil, hebben één of ander patch management systeem met een testpool (al dan niet in the field). Patch Tuesday is in mijn ogen dan ook volledig nutteloos.

[Anoniem: 294759]

sebastius schreef op zaterdag 04 december 2010 @ 00:15:
Ik vind het een beetje raar. Ik krijg er niet het gevoel van dat ik (de consument) belangrijk ben en dat de patch zo snel mogelijk uitgebracht wordt. Nee, hij komt pas volgende week dinsdag. Dat is toch raar?

Nee, dat is het niet. Bepaalde fixes kunnen ook gewoon wachten als het maar geen 'critical patch' is. Want daarvan heb ik liever dat die gelijk uitgebracht worden.

En niet alles draait om de consument. Consument moet ook begrijpen dat bepaalde zaken gewoon tijd nodig heeft om het goed uit te brengen. Van te snel iets uitbrengen heeft nooit iets goeds gebracht.

Als beheerder zeg ik dat ik het liever heb dat er op een bepaalde vast moment heb waarvan ik kan verwachten dat er fixes uitgebracht zullen worden. Dan kan ik in ieder geval er op plannen om te testen.

[ Voor 14% gewijzigd door Anoniem: 294759 op 09-12-2010 11:24 ]

[Bor]

Wat vinden jullie van de reden dat het gefaseerd uitbrengen van patches goedkoper zou zijn voor bedrijven? Volgens mij is het vooral goedkoper voor de producent gezien je als klant natuurlijk zelf kunt beslissen gefaseerd te gaan patchen.

[Onbekend]

Het bedrijf (de klant dus) kan van tevoren capaciteit inplannen. Bij adhoc-patches kan dat niet.

Zelf vraag ik mij af of bedrijven een groot risico nemen als ze elke patch pas na een week gaan installeren.
Het is alleen interessant voor hackers die ook daadwerkelijk weten dat een bedrijf zijn software niet gepatched heeft. Anders doen die hackers al die moeite ook voor niets.

[jbhc]

Waarom de patch niet gewoon online als hij klaar is en de gebruiker laten beslissen wanneer de updates (dagelijks / wekenlijks /maandelijks / enz) moeten worden geinstallerd.

[@r!k]

jbhc schreef op maandag 27 december 2010 @ 23:51:
Waarom de patch niet gewoon online als hij klaar is en de gebruiker laten beslissen wanneer de updates (dagelijks / wekenlijks /maandelijks / enz) moeten worden geinstallerd.

Omdat je dan dus weer extra risico loopt met hackers die massaal een exploit gaan proberen te schrijven.

Ik ben voorstander van een vaste dag, niet alleen vanwege het risico op exploits op deze manier kleiner maken maar ook vanwege de complexiteit van organisaties tegenwoordig en op deze manier een vast schema aan te houden is van de installatie van patches. Op deze manier is het ook makkelijker in te passen in je bedrijfsvoering en kun je je er beter op voorbereiden.

En in het geval van MS komt er nog wel eens een out of band patch uit die dan in uitzonderingsgevallen alsnog onmiddelijk geinstalleerd kan worden indien nodig.

[Razwer]

@r!k schreef op dinsdag 28 december 2010 @ 13:29:
[...]


Omdat je dan dus weer extra risico loopt met hackers die massaal een exploit gaan proberen te schrijven.

Ik ben voorstander van een vaste dag, niet alleen vanwege het risico op exploits op deze manier kleiner maken maar ook vanwege de complexiteit van organisaties tegenwoordig en op deze manier een vast schema aan te houden is van de installatie van patches. Op deze manier is het ook makkelijker in te passen in je bedrijfsvoering en kun je je er beter op voorbereiden.

En in het geval van MS komt er nog wel eens een out of band patch uit die dan in uitzonderingsgevallen alsnog onmiddelijk geinstalleerd kan worden indien nodig.

Zo doen "wij" het ook.

Client patches releasen we wel zsm, en hebben ze een week voor om te kiezen wanneer ze die willen installen en anders gaat het alsnog "vanzelf". Servers is fijn overuren schrijven. Vooral de exchange rollups tikken aan
_{Dat doet me herinneren, ik moet snel morgen ff wat leuk speelgoed (hardware) uitkiezen voor mn uren geld}

[Anoniem: 379651]

Richting de leek is een vaste dag wel zo handig. Niet alleen omdat het hele idee van patchen (en daarmee het verhogen van de veiligheid & stabiliteit) dan beter blijft hangen in het geheugen maar ook omdat het dan gemakkelijker voor de leek is om deze patchen te implementeren in de geïnstalleerde software.

Voor de producent lijkt het mij eigenlijk ook gemakkelijker, omdat je op die manier duidelijker kunt voorspellen op welke dagen je veel dataverkeer kan verwachten en je daar dus beter op kunt voorbereiden.

Voor mijzelf - maakt het geen bal uit.

[Bor]

Onbekend schreef op maandag 27 december 2010 @ 21:57:
Het bedrijf (de klant dus) kan van tevoren capaciteit inplannen. Bij adhoc-patches kan dat niet.

Waarom zou dat niet kunnen? Niet meer dan een kwestie van opsparen lijkt mij (zeker bij non security patches).

[Onbekend]

Ik bedoelde dat je ruim op tijd weet dat er een patch aan zit te komen.
Als je ineens ziet dat er een zeer belangrijke patch uitgekomen is, moet je ook snel deze patch testen.


Ik wacht eerst altijd minimaal 2 dagen met het installeren van patches. Als een patch problemen oplevert, zie ik dat wel op internet verschijnen, en ben ik er nog geen "slachtoffer" van geworden.

[Anoniem: 379085]

Qua werkplanning vind ik een vaste patch dag prettig...
1x per maand, haal je de nieuwe patches binnen en werk je, je installatie bestanden/ wsus / images bij.
Gestructureerd alles na lezen en doorvoeren indien geaccepteerd.

Je gebruikers worden dan ook maar 1x per maand gestoord dat ze 1..5 updatesvoor geschoteld krijgen..
Als ze dat om de dag krijgen, worden ze ook niet vrolijk.

Dit is natuurlijk een werkwijze wat je zelf hanteert. als een leverancier dit nog een keer doet is het opzich wel makkelijk, in 1 lijst zie je dan gelijk welke update wel boeiend is en welke minder