[SEC] Security patching in het bedrijf

[Bor]

Security patching is in vele bedrijfsomgevingen nog steeds een issue en uitdaging. De noodzaak om up 2 date te blijven is de laatste jaren regelmatig onder de aandacht gebracht in vakliteratuur en andere media.

Welke tools en technieken gebruiken jullie in het bedrijf om te zorgen dat clients en servers up 2 date blijven? Gebruiken jullie dezelfde tools en procedures voor de clients als de servers? Verschilt de patching techniek per platform? Lopen jullie voorop met patches of is het beleid om enkele tijd te wachten? Worden patches uitgebreid getest en welke procedures volgen jullie hiervoor?

Het is de bedoeling ons in dit topic te focussen om de bedrijfsomgeving. Het patchen van thuis systemen valt buiten het doel van dit topic.

Ik ben benieuwd naar de reacties.

[sh4d0wman]

Onze omgeving bestaat voornamelijk uit thin clients en Windows servers.

De thin clients updaten via een FTP server, ze draaien een linux achtig embedded OS. Deze rollen we eerst uit op enkele test thin clients, daar draaien we een week mee en vervolgens rollen we het overal uit.

Windows servers updaten we handmatig, we hebben 1 server als testserver. Deze krijgt de updates zodra ze beschikbaar komen van Microsoft. Daar testen we een dag tot een week mee (afhankelijk van type en hoeveelheid updates) en vervolgens rollen we ze uit over de andere servers.
Het testen bestaat uit het nalopen van de Eventlog na installatie, rebooten van de server en vervolgens de werking van de meest belangrijke applicaties.

Laptops staan op automatisch updaten omdat we er niet zo veel zicht op hebben wanneer ze weer eens een het netwerk hangen. We proberen minimaal 1x per maand de laptops bij ons binnen te halen om te controleren of windows updates en anti-vir updates nog up to date zijn. Laptops zijn bij ons alleen in gebruik voor eventuele presentaties buiten de deur.

Antivir updates komen automagisch binnen en gaan gelijk door naar alle clients.

Waar we meer aandacht aan moeten schenken zijn onze switches en printers. Daar controleren we amper op nieuwe firmware/updates.

[Nvidiot]

Een vraag aan jullie: wat doen jullie qua patching van losse applicaties? Denk dan aan applicaties zoals Adobe Reader, Flash, Java, etc. Hoe houd je bij of daar updates voor zijn en welke clients die nog niet geinstalleerd hebben?

Gebruiken jullie daar iets als dit voor? http://secunia.com/vulnerability_scanning/corporate/

[Verwijderd]

sh4d0wman schreef op vrijdag 20 februari 2009 @ 09:52:

We proberen minimaal 1x per maand de laptops bij ons binnen te halen om te controleren of windows updates en anti-vir updates nog up to date zijn. Laptops zijn bij ons alleen in gebruik voor eventuele presentaties buiten de deur.

Dus dan krijgen jullie 1 x per maand een zwaar besmate gehackte laptop binnen? Gebruiken jullie hiervoor een NAC oplossing? Of hebben jullie een andere oplossing, policy voor het aansluiten van mogelijk ongepatche apperatuur op het netwerk?

[Bor]

Nvidiot schreef op vrijdag 20 februari 2009 @ 10:57:
Een vraag aan jullie: wat doen jullie qua patching van losse applicaties? Denk dan aan applicaties zoals Adobe Reader, Flash, Java, etc. Hoe houd je bij of daar updates voor zijn en welke clients die nog niet geinstalleerd hebben?

Gebruiken jullie daar iets als dit voor? http://secunia.com/vulnerability_scanning/corporate/

De secunia vulnerability scanner gebruik ik niet. Ik vraag me ook af hoe betrouwbaar dergelijke producten zijn. Daarbij wil je werkstations vaak zo identiek mogelijk houden in een grote omgeving. Een nieuwe update kun je dan centraal uitdelen bv via GPO als het een Windows domein betreft of op een andere manier met de deployment producten die je gebruikt.

[Nvidiot]

Bor de Wollef schreef op vrijdag 20 februari 2009 @ 16:05:
[...]
De secunia vulnerability scanner gebruik ik niet. Ik vraag me ook af hoe betrouwbaar dergelijke producten zijn. Daarbij wil je werkstations vaak zo identiek mogelijk houden in een grote omgeving. Een nieuwe update kun je dan centraal uitdelen bv via GPO als het een Windows domein betreft of op een andere manier met de deployment producten die je gebruikt.

Dat snap ik, maar hoe houd je dan bij dat er een belangrijke update is voor Adobe Reader of Flash of een van de andere applicaties op je systeem? Dagelijks Bugtraq lezen? Toevallig op het nieuws horen?

[Bor]

Veel leveranciers bieden de mogelijkheid tot e-mail notificatie etc. Daar kun je natuurlijk ook gebruik van maken. Leveranciers van gespecialiseerde software dienen patches etc vaak zelf aan.

Ik denk overigens dat een goed patching mechanisme ingericht is op procedures die rekening houden met de gebruikte platformen en technieken in een bedrijf. Het patchen van een Citrix omgeving zal anders verlopen dan het patchen van een Windows XP client.

[ Voor 40% gewijzigd door Bor op 20-02-2009 17:33 ]

[OkselFris]

Ons bedrijf een international bedrijf met 150 locaties wereldwijd, gebruikt Landesk Patchmanager als onze update tool. Voordeel hiervan is dat het tenminste een beetje netwerk vriendelijk is (d.m.v peer to peer) en meerdere producten ondersteund dan alleen windows. Security is een hot issue binnen dit bedrijf. Testen van patches doen we in principe binnen 5 dagen. daarna worden patches naar alle office systemen gereleased. dit is een korte periode maar uit ervaring weet ik dat echte problemen met patches pas naar voren komen in de live environment. Zodra de patches gereleased zijn zal een client ze oppakken en de gebruiker vragen om een rebooot, dit kan men echter uitstellen tot maximaal 10 uur, wat dus geen enkele gebruiker echt zal storen tijdens zijn werkzaamheden. Mocht een patch toch problemen geven dan kunnen we de installatie van patches via Landesk snel ongedaan maken. Voor productie systemen hebben wij 1 maal per maand een onderhouds schema, alleen in dit onderhouds window worden patches gereleased. Voor emergency patches hebben we weer een andere procedure. In dit geval hebben worden de patches onmiddelijk gereleased en Landesk geeft de gebruikers maar 10 minuten de tijd om alle programma's af te sluiten, daarna volgt een automatische reboot. Voor alle systemen wordt dezelfde tool gebruikt, aangezien dit wel zo makkelijk is voor rapportage aan de security manager

[ Voor 4% gewijzigd door OkselFris op 20-02-2009 23:40 ]

[Virtugon]

Bij ons hebben we een centrale update server voor Windows OS alsmede de door IT ondersteunde applicaties zoals Office, Adobe Reader, Flash etc. etc.
Ook hebben we een centrale Linux repository voor de Linux machines en de door IT ondersteunde packages.

De updates worden eerst in een testomgeving gecontroleerd alvorens ze worden verspreid over het netwerk.

[Bor]

Virtugon schreef op zaterdag 21 februari 2009 @ 10:47:
Bij ons hebben we een centrale update server voor Windows OS alsmede de door IT ondersteunde applicaties zoals Office, Adobe Reader, Flash etc. etc.
Ook hebben we een centrale Linux repository voor de Linux machines en de door IT ondersteunde packages.

De updates worden eerst in een testomgeving gecontroleerd alvorens ze worden verspreid over het netwerk.

Op basis van welk product is de centrale update server ingericht?

Hoe gaan jullie om met het updaten van servers waar downtime eigenlijk niet gewenst is maar welke bv ook niet geclustered zijn aangeboden? Dat vind ik altijd een grote uitdaging omdat voor veel updates een reboot nodig is. Onze Citrix farm heeft een scheduled reboot op een tijdstip dat het zo min mogelijk overlast veroorzaakt voor de organisatie maar hoe doe je zo iets goed op productie servers waarbij er eigenlijk niet echt een goed tijdstip is voor downtime voor patching?

[ Voor 19% gewijzigd door Bor op 21-02-2009 10:52 ]

[Virtugon]

Bor de Wollef schreef op zaterdag 21 februari 2009 @ 10:51:
Op basis van welk product is de centrale update server ingericht?

Systeembeheer gebruikt bij het bedrijf waar ik nu werkzaam ben Shavlik NetChk Protect voor de updates van Windows systemen.

Bor de Wollef schreef op zaterdag 21 februari 2009 @ 10:51:
Hoe gaan jullie om met het updaten van servers waar downtime eigenlijk niet gewenst is maar welke bv ook niet geclustered zijn aangeboden? Dat vind ik altijd een grote uitdaging omdat voor veel updates een reboot nodig is. Onze Citrix farm heeft een scheduled reboot op een tijdstip dat het zo min mogelijk overlast veroorzaakt voor de organisatie maar hoe doe je zo iets goed op productie servers waarbij er eigenlijk niet echt een goed tijdstip is voor downtime voor patching?

Alle servers die cruciaal zijn voor de ondersteuning van een of meer kritische bedrijfsprocessen zijn dubbel uitgevoerd. Systeembeheer update elke keer eerste de eerste helft van de servers, kijkt het een week aan en gaat dan verder met de mirrors.
Ons maintenance window is elke dinsdag tussen 04:00 en 07:00 zodat dit inderdaa de minste overlast veroorzaakt.
Omdat de kritische servers redundant zijn opgesteld heeft het rebooten van een set op deze manier geen of weinig impact.

[Bor]

Wat doen jullie met het testen van updates / patches? Is er iets van een testgroep servers en werkstations gedefineerd? Een groep gebruikers in een test groep voor applicaties?

[ Voor 52% gewijzigd door Bor op 28-02-2009 11:46 ]

[Bor]

Wat doen jullie in het geval een rollback van een patch nodig blijkt? Niet elke patch / update is even makkelijk terug te draaien. Ik ben bezig met het onderzoeken / beschrijven van een goede manier om patches te testen. Een rollback procedure hoort hier ook bij echter vind ik hier erg weinig informatie over.

[Bor]

Kleine kick omdat ik hoop dat er meer mensen zullen reageren.