Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

NSA waarschuwt systeembeheerders om BlueKeep-patch toe te passen

De NSA waarschuwt systeembeheerders hun netwerken te updaten zodat zij beschermd blijven tegen potentiële wormaanvallen. De veiligheidsdienst doelt daarbij op BlueKeep, een rdp-lek waarvoor inmiddels een patch beschikbaar is.

De waarschuwing van de NSA gaat specifiek over CVE-2019-0708, een kwetsbaarheid die ook wel BlueKeep wordt genoemd. Dat is een voormalige zero-daykwetsbaarheid die vooral oudere computersystemen treft. Windows XP en Windows 7, en Windows Server 2003, 2008 en 2008 R2 zijn daardoor vatbaar voor aanvallen. Microsoft heeft inmiddels een patch uitgebracht voor de kwetsbaarheid.

BlueKeep is een kwetsbaarheid in remote desktop services op Windows. Het is een vergelijkbaar probleem als die grote ransomwareaanvallen zoals WannaCry en (Not)Petya wisten uit te buiten en waardoor voor miljoenen euro's schade ontstond. De NSA waarschuwt dat als systemen kwetsbaar en niet up-to-date zijn, er opnieuw kans is op zo'n aanval. Hoewel er al een patch beschikbaar is hebben veel systeembeheerders die nog niet doorgevoerd. Er zijn nog steeds meer dan een miljoen kwetsbare systemen op internet aangesloten. Ook voor de kwetsbaarheden waar WannaCry en (Not)Petya gebruik van maakten waren al patches beschikbaar, maar die waren in veel gevallen niet doorgevoerd.

Het is de eerste keer dat de Amerikaanse veiligheidsdienst reageert op de situatie. Dat doet de NSA, die ook wel eens 'Never Say Anything' wordt genoemd, vrijwel nooit. De dienst heeft zich ook nooit uitgesproken over de controversiële diefstal van tools die door de ShadowBrokers-groep naar buiten werden gebracht.

"We roepen iedereen op tijd en middelen te steken in het leren kennen van je netwerk en om besturingssystemen van patches te voorzien. Dat is niet alleen belangrijk voor het beschermen van nationale veiligheidssystemen die de NSA beschermt, maar voor alle netwerken." De dienst geeft een aantal tips aan systeembeheerders, zoals het sluiten van tcp-poort 3389, en het inschakelen van Network Level Authentication. Ook zouden systeembeheerders remote desktop services moeten uitschakelen als ze die services niet nodig hebben.

De NSA is niet de enige partij die waarschuwt voor het patchen van systemen. Eerder deze week deed Microsoft hetzelfde.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Tijs Hofmans

Redacteur privacy & security

05-06-2019 • 15:57

74 Linkedin

Reacties (74)

Wijzig sortering
Gelijk even een open vraag aan de systeembeheerders (en anderen) hier: als ik meer wil leren over waarom het patchen van systemen zo moeilijk/duur is, kennen jullie dan goede resources waar ik daar meer over kan vinden? Websites, video's, twitteraars? Ik wil beter begrijpen waarom sommige bedrijven zo lang over patches doen maar vind het als niet-sysadmin moeilijk inbeelden...

Edit: inmiddels al heel erg veel nuttige reacties gekregen, dank iedereen! Fijn om zoveel betrokkenheid te zien bij zo'n noobvraag!

[Reactie gewijzigd door Tijs Hofmans op 6 juni 2019 09:25]

In veel organisaties is beschikbaarheid belangrijker dan vertrouwelijkheid en integriteit. Dat kan komen vanuit een praktisch perspectief, maar ook vanuit certificering of beloftes naar afnemers.

Een patch vormt altijd een risico. Ten eerste moet een systeem tijdelijk offline voor een effectieve installatie. Ten tweede kan een patch ervoor zorgen dat het systeem zich anders (en mogelijk onbetrouwbaarder) gaat gedragen. Een goed voorbeeld zijn de patches voor Spectre en Meltdown. Bij sommige transactieverwerkende systemen snoepen die wat af van de origineel beoogde piekcapaciteit, wat disastreuze gevolgen kan hebben in productie.

Alle risico's zijn te mitigeren, maar dat betreffen investeringen op infrastructuur- en applicatieniveau. Men zoekt liever de rand op van minimale beveiliging en voldoende compliance.

[Reactie gewijzigd door The Zep Man op 5 juni 2019 16:07]

In hoeverre is het effectief zulke dingen vooraf te testen, bijvoorbeeld in vm's of een aparte testomgeving?
In hoeverre is het effectief zulke dingen vooraf te testen, bijvoorbeeld in vm's of een aparte testomgeving?
95%+ van de tijd gaat het goed als je 'blind' patches installeerd, totdat het niet goed gaat en als je dan net een kritisch systeem heb dan kan het heel erg mis gaan.

En een aantal systemen updaten, geen probleem, een paar duizend systemen updaten kan issues veroorzaken. Daarnaast zit je ook nog eens met interactie met onderliggende systemen en applicaties die ergens op draaien, issues die daar naar boven komen zijn niet heel vaak voorgekomen, maar zeker wel eens.

Ik kan bv. Windows 10 patch 1903 op VMs, test machines, etc. testen, maar ik kan daar geen issues op een paar duizend werkstations mee uitsluiten. En zelfs het kleine percentage wat issues geeft zorgt voor een enorme berg werk als we het over duizenden werkstations hebben.

Daarnaast is 'beheer' vaak een ondergeschoven kindje en draait het puur om het in de lucht houden van de systemen, preventief onderhoud is anathema voor het budget.

@OruBLMsFrl Ik ken het fenomeen, legacy meuk welke nooit gedocumenteerd is, keuzes die ooit zijn gemaakt waarbij je afvraagt wat ze op dat moment aan het roken waren, etc. Laatst inderdaad zo iets als "Wat doet deze DC direct aan het internet???". Of een hele rits applicatie servers waarbij van alles bijelkaar is gegooit en je niet weet wat bij wat hoort. Als je vervolgens gaat checken bij de vermeende gebruikers blijkt dat de applicatie niet meer gebruikt wordt, al jaren niet meer... Scheelt natuurlijk een hoop werk, hoef je niet meer te beheren en te migreren naar een fatsoenlijke omgeving, maar je zit je zelf dan wel op het hoofd te krabben. En een klein lijstje zaken waar je een paar weken mee bezig zou moeten zijn groeit uit naar een lijst met honderd tickets wat maanden werk is omdat je steeds meer dingen vind die gefixed moeten worden (of uitgezocht, of naar buiten afgeschoten moeten worden en vervolgens in de fik worden gezet)... ;-)

En ik kan me inderdaad ook nog zo een gevalletje bedenken waarbij de marketing afdeling had besloten dat we langer open zouden zijn totdat ik bij een paar hoofden naar binnen liep of iemand ze al had verteld dat na zes uur een hele rits systemen niet beschikbaar zou zijn omdat dan al de backup begon. "Ja maar dan begint die toch gewoon later!" Euh... We hebben nu al regelmatig dat ie om 9:00 in de ochtend niet klaar is en vaak zelfs nog niet om 11:00... Die 4 uur later laten beginnen zou betekenen dat het regelmatig voor zou komen dat mensen tijdens hun werkdag niet in de systemen konden om hun werk te kunnen doen. Vervolgens waren die kosten posten voor tonnen te besteden aan AS400 uitbreiding en een nieuwe Taperobot/library er een heel stuk sneller doorheen...

Of inderdaad zolang geen updates gedaan zodat je update management tooling je de finger geeft en je doodleuk handmatig in de avond/nacht/weekend kan gaan updaten (en hopen dat er niet iets drastisch fout gaat)...

[Reactie gewijzigd door Cergorach op 6 juni 2019 17:53]

+1 op die interactie met oudere systemen. Hoeft niet eens het budget te zijn zelfs. @Tijs Hofmans

Typische casus bij dit soort ellende is een uitgebreid rekensysteem dat alles in een bedrijf aan elkaar knoopt, draait alleen op Windows 2003 vanwege legacy API gebruik. Systeem was ooit begonnen op NT4, toen 2000, maar verder dan 2003 is het echt niet op te rekken zonder grote aanpassingen te doen. Zonder dit systeem valt er bij het bedrijf niet tot nauwelijks te werken, hele afdelingen kunnen dan voor de dag naar huis gestuurd worden.

De applicatie werkt gelukkig nog prima, zet braaf print- en exportbestanden neer op diverse SMB paden. Vereist daarmee dat SMBv1 nog toegestaan is op het netwerk, want hoger gaat Windows 2003 niet. Via SMBv1 worden ook dagelijks bestanden van leveranciers in allerlei formaten ingelezen.

Het systeem heeft verder een klantenportal die op dezelfde server draait direct op de databestanden, server moet daarom aan internet gekoppeld zijn. De desktop applicatie om te bepalen wie wat op de portal mag zien kan ook alleen op die server zelf draaien, net als het technische beheer programma. Soms moet per direct een aanpassing gemaakt worden of is spoedonderhoud nodig. Om maar zo snel mogelijk op de server te kunnen komen staat RDP open.

Gelukkig wordt er sinds 2015 aan 'het nieuwe systeem' gewerkt dat dit alles moet vervangen. Dat nieuwe systeem is al twee jaar lang volgend jaar af, op een gegeven moment was het zelfs nog maar 3 maanden tot oplevering. Helaas werd dat na die uitgebreide ronde acceptatietesten opeens weer 12 maanden, nu nog 6.

Van het nieuwe systeem draait gelukkig wel al de planningsmodule, zo'n succes dat er inmiddels twee afdelingen geheel van afhankelijk zijn. Het oude systeem moet daarom nu wel echt iedere nacht naar het nieuwe systeem synchroniseren om de planningsmodule te voeden. Doorlooptijd van die synchronisatie is helaas zo rond de 12 uur, iedere avond en nacht.

In de ochtenden klagen de eerste gebruikers al dat het oude systeem dan nog zo traag is en er is zelfs al een zaterdagploeg in het leven geroepen omdat werken in de avond niet meer gaat. Verderop in het weekend loopt de full backup, maar door een decennium aan explosieve (data) groei duurt die inmiddels zo'n 36 uur, van zaterdagavond tot maandagochtend.

Updates installeren lijkt geen optie meer, want er staan inmiddels maar liefst 178 updates klaar en niemand durft te zeggen wat de doorlooptijd daarvan is, laat staan wat er mis zou kunnen gaan. Uitloop is ondenkbaar pijnlijk voor het bedrijf met dat het oude systeem nu al niet genoeg beschikbaar is om het werk normaal gedaan te krijgen.

Natuurlijk is er ook nog die ene functie van de module boekhouding van het oude systeem, maar daar wordt al over nagedacht, geen zorgen. Volgende maand opgelost en gelukkig is die planningsmodule van het nieuwe systeem zo'n succes, dat geeft vertrouwen. Einde jaar kijken we hierop terug en lachen we erom ;)
machtig! precies wat ik overal tegenkom!

Nu zit ik zelf in een bijzondere positie waarbij ik voor een project een compleet nieuwe architectuur, AD en infrastructuur(netwerk en KA) mag verzinnen en bouwen(naast de oude!).
Hier willen ze alles geleidelijk overzetten van oud naar nieuw, omdat het oude gewoon niet meer houdbaar en beheersbaar is.

Hier hebben ze gelukkig wel het verstand om gewoon de portemonnee te trekken om het weer goed te maken.
Wij hebben niet genoeg mogen investeren in onze storage om onze servers in testomgeving naast de echte te kunnen draaien
Aha, dus dan komt het toch weer op budget neer...
Budget ligt uiteraard bijna altijd ten grondslag aan iets wat niet kan... dat gaat ook ver voorbij ICT.
Lijken net echte bedrijven. ;)

[Reactie gewijzigd door Koffiebarbaar op 5 juni 2019 16:32]

Zoals met ongeveer alles in de wereld.
Vooral SMB is kwetsbaar want hebben vaak niet het budget om een productie EN staging omgeving op te zetten. Het betekent niet per definitie dat je je budget moet verdubellen maar wel dat het budget hoger moet zijn.
Zoals hier ook al veel aangegeven kun je alles wel virtualiseren maar zijn er altijd elementen zoals bijvoorbeeld hardware wat zich anders kan gaan gedragen omdat de productie en staging uit verschillende merken bestaan of de setup van je infrastructuur toch niet helemaal 1-op-1 is.
SMB hebben vaak het budget niet maar ook het inzicht/visie van sommige bedrijven/managers werpen blokkades op want niet iedereen vindt ICT even belangrijk.
Daarnaast heb je nog mensen die struisvogel tactiek toepassen, pas als ze worden getroffen door malware en een schakel zoals anti-virus, backups, etc zijn niet aanwezig of voldoende toegepast leren ze ervan. Dan opeens wordt er wel budget vrij gemaakt.
niet enkel, zelfs bedrijven met voldoende budget duurt het nog minstens 3-4 weken eer de productie gepatched is. wij werken voor verschillende klanten en voeren dergelijke dingen uit.

Theoretisch zou elke omgeving een een OTAP landschap moeten hebben.
O: ontwikkeling T: Test A: Acceptatie P: productie
Afhankelijk van het budget kunnen sommige omgevingen geconsolideerd worden. vooral T&A zijn soms 1 en hetzelfde systeem. Daarbij komt ook nog eens dat je echt wil testen ook de test gegevens moet overzetten.
het ideale situatie is dus als volgt : Dag-1 backup wordt genomen van productie en op het doel systeem overgezet. Dag1 O (of T) wordt gepatched (systeem niet gegarandeerd beschikbaar ). en op OS niveau gecontroleerd of alles ok loopt. Dan heeft de business (klant of leverancier die de omgeving gebruikt) 1 week de tijd om te testen of alles ok is. vandaar dat soms met T begonnen wordt. Spreekt voor zich dat er tijdens die week geen functionele veranderingen aan het systeem mogen gebeuren om zeker te zijn dat men enkel de patches test en geen functionele veranderingen. De week daarop T (of O) , volgende week A en dan pas Productie
De Acceptatie omgeving wordt door zowel ontwikkelaars als (key-) eindgebruikers getest.
Dus zo zit je aan 4 weken eer productie gepatched indien er geen problemen zijn natuurlijk.
Dit zijn de algemene richtlijnen, en vooral wegens bugettaire redens wordt er hier en daar wel eens een shortcut genomen. vooral door het vele testen en de freeze periodes wordt dit slechts periodiek uitgevoerd. en dan spreken we over 1,2,3 max 4 keer per jaar.
Wat ik ook vaak zie gebeuren is dat men bvb 4 maintenace windows inplant maar dan om en om Applicatie en OS patched. Wegens applicatie of mogelijke reboot ligt het systeem minstens 1 dag stil, of is de operatie niet gegarandeerd. vandaar dat er ook vaak uitgekeken wordt naar verlengde weekends of feestdagen om dit in te plannen.
Hoe effectief het testen is hangt natuurlijk van de testen af. Bij ons worden patches eerst in een testomgeving uitgerold en hebben we een klein team dat dan aan het testen gaat. En als het gaat om patches voor client software is er daarna eerst nog een beperkte uitrol voordat deze naar alle machines wordt geduwd.

Maar de uitrol op servers in productie gebeurt ook op vaste tijdstippen. Het is zeer uitzonderlijk dat servers op een willekeurige nacht gaan herstart worden voor het doorvoeren van patches. Wanneer er 24/7 gewerkt wordt ga je op zoek naar de rustigste momenten om een herstart van de systemen uit te voeren. Zelfs bij noodpatches zal men dat nog altijd proberen 's nachts in het weekend uit te voeren.
Everybody has a testing environment. Some people are lucky enough enough to have a totally separate environment to run production in.

Patches worden meestal via het het DTAP (Development, Testing, Acceptance and Production) principe geïnstalleerd en af en toe Ring Based (groepen van servers). Bijna alles is op voorhand te testen de limitaties in de praktijk zijn vaak budget en politics (voornamelijk slecht management).
Wat dacht je in grote organisaties met honderden en soms duizenden applicaties. Wil je die allemaal opnieuw laten testen? Want het gebeurd nog steeds wel een keer per jaar dat er een applicatie er zomaar mee ophoudt en dat dit te wijten is aan een Windows patch.
Om hierop voort de borduren. Tijdens het vooronderzoek (en implementatie) van een stuk software moet beschikbaarheid, redundantie, patch management, backup en disaster recovery in acht worden genomen bij het design. Dit gebeurd tijdens de offertefase zelden waardoor het naderhand geïmplementeerd moet worden. Resultaat is een stuk software waarvan men niet weet hoe, wanneer en wat men moet updaten.
Daarnaast worden systeembeheerders ook niet gehoord in de onderzoeksfase wat hun eisen eigenlijk zijn.

Neem als voorbeeld een simpele website. Wanneer hier vooraf goed over na is gedacht en er een load balancer voor wordt gezet kan men prima overdag patchen en rebooten. In de praktijk worden er een aantal servers aangevraagd bij systeembeheer en krijgt men een paar weken later een e-mail met de vermelding dat er een nieuw intranet in productie is genomen. Geen procedures of back-up, DR of patch management. Omdat het basis slecht ontworpen is moeten patches dus in de praktijk buiten productie tijden geïnstalleerd worden. Niemand staat daar op wachten dus animo is klein.

Dit in combinatie met honderden servers waarvan 1 iemand nooit volledig kan omvatten hoe alles aan elkaar hangt en je hebt een normale grote organisatie. Binnen een normale organisatie is patchmanagement trouwens ook nog eens een subtaak die je erbij mag doen naast al je normale taken.

En dan komt de CISO de hoek om met een melding dat er een patch binnen een maand geïnstalleerd moet worden..
Goedendag Tijs. Dit heeft te maken met veel factoren waaronder maar niet beperkt tot: grote van de omgeving, of er alleen machines draaien van het bedrijf zelf of dat er ook voor klanten wordt gehost en daarmee overlegt moet worden, wat de werkdruk is en of er dus tijd vrij gemaakt kan worden in korte tijd, of er een change procedure is, of de systeembeheerder op de hoogte is van de dreiging/patch, of er systemen draaien die wellicht hinder kunnen ondervinden van de patch zelf of de procedure waar bijvoorbeeld een reboot bij nodig is. En hoe lang de test periode omvat.

Ik mis er vast nog een hoop maar dat zijn de dingen die mij als systeembeheerder als eerste omhoog komen.

[Reactie gewijzigd door magin12 op 5 juni 2019 16:08]

Goede lijst, thanks!
Gelijk even een open vraag aan de systeembeheerders (en anderen) hier: als ik meer wil leren over waarom het patchen van systemen zo moeilijk/duur is, kennen jullie dan goede resources waar ik daar meer over kan vinden? Websites, video's, twitteraars? Ik wil beter begrijpen waarom sommige bedrijven zo lang over patches doen maar vind het als niet-sysadmin moeilijk inbeelden...
Om te beginnen is er (natuurlijk) te veel werk en te weinig tijd. Dat is op zich geen oorzaak, maar het maakt alles wel een stuk moeilijker. Hoe meer tijd, geld en middelen je hebt, hoe beter je kan voorbereiden, oefenen en onderzoeken.

Ik denk dat de belangrijkste reden is dat onderhoud onzichbaar is als het goed gaat, en alleen zichtbaar is als het fout gaat. Als je te weinig middelen hebt om het goed voor te bereiden wordt de kans dat er iets mis gaat of langer duurt dan nodig snel groter.

Daarbij voegt onderhoud niks toe, je houdt alleen in stand wat je al hebt, en het is ook nog eens minder leuk dan iets nieuws bouwen. Daarom gaat de meeste aandacht meestal naar het bouwen van nieuwe systemen en niet naar de onderhoud van wat er al is. Doe je onderhoud dan gaan je gebruikers klagen, en met wat pech je baas ook. Bouw je iets nieuws dan krijg je complimenten.

Dat is opzich niet uniek aan IT, dat heb je overal. Wie onderhoud aan een snelweg of spoorlijn pleegt krijgt ook verwensingen naar z'n hoofd en het verzoek een nieuwe weg te bouwen in plaast van de snelweg te blokkeren, maar in de IT is het veel erger door het volgende punt:

Het volgende punt is het kennisaspect. Veel IT'ers hebben maar een zeer beperkte kennis van IT. Een hoop van die mensen hebben nooit een gedegen opleiding gehad maar zijn door baas aangewezen als beheerder en/of hebben alleen hobby-ervaring. Ik zeg niet dat hobbyisten altijd slecht zijn en mensen met een opleiding altijd goed, maar er het punt is dat er best veel beheerders zijn die weinig inzicht hebben in waar ze mee bezig zijn. Als er iets fout gaat dan missen ze de achtergrond en diepgang om problemen op te lossen, en ze hebben niet de om zich er in te verdiepen.

Dat leidt al snel tot een "afblijven zolang het werkt"-houding. Ze zijn doodsbang om iets te veranderen of om op het verkeerde knopje te drukken omdat ze niet het vertrouwen hebben dat ze eventuele problemen kunnen oplossen. Ik denk dat iedereen hier (IT'ers en niet-IT'ers) wel eens in die situatie heeft gezeten. Hoe langer zo'n situatie duurt hoe moeilijker het wordt om het nog te veranderen.

Het helpt ook niet dat bepaalde bedrijven al jaren lang verkondingen dat hun software zo gebruikersvriendelijk is dat iedereen er mee kan werken. Daardoor is het beeld ontstaan dat IT makkelijk is. De meeste mensen vinden IT helemaal niet makkelijk en schamen zich daar zelfs een beetje voor. De menselijke reactie is om IT dan maar te down-playen.

Nog een probleem dat ik veel zie is een verlammende complexiteit. Alles is met alles verweven en niemand weet hoe het werkt. Door de jaren heen wordt er steeds meer tegenaan gebouwd waardoor je steeds minder beweginsruimte hebt. De website kan niet worden geupgrade omdat PHP niet kan worden geupgrade omdat een andere website niet kan worden geupgrade omdat de achterliggende database niet kan worden geupgrade omdat daar ook de personeelsadminstratie op draait maar de leverancier is failliet en de data mag niet verloren gaan en alleen jantje weet hoe het zit maar die werkt niet meer, etc, etc, etc....

Bij het opzetten van een nieuw systeem zou je eigenlijk al moeten vastleggen hoe je het later kan upgraden en uiteindelijk uitfaseren. Met name de vraag hoe je ooit je data weer uit zo'n systeem krijgt is erg belangrijk.

Die die problemen samen zorgen er al snel voor dat "de bussiness" al snel eist dat ze niks van onderhoud willen merken. Systemen moeten (minstens) de hele werkdag beschikbaar zijn. In een ideale wereld waarin je alles dubbel hebt uitgevoerd en een test-omgeving om te oefenen kan dat. Als je dat niet hebt wordt het lastig en is je enige mogelijkheid om 's nachts te gaan werken. Daar moet je ook maar zin in hebben, als het fout gaat zit je met wat pech de hele nacht te werken en je collega's zijn er niet om te helpen. Wat je dan overhoudt is niks doen en wachten tot het stuk gaat.

Ik hoop dat dit een beetje inzicht geeft, anders kan ik nog wel een uurtje door gaan ;)
Net zoals @mterwoord al zegt.
Indien je een patch deployed wil je wel eerst weten of je daarmee je systeem niet om zeep helpt.
Elke aanpassing aan je systeem kan er voor zorgen dat een onderdeel corrupt kan raken

In het ergste geval moet je je systeem opnieuw installatie, al dan niet een roll back doen.
Tijd die je niet kan werken kost gewoon geld, want salaris moet worden uitbetaald ongeacht de werkzaamheden.

Als systeembeheer wil je weten wat de impact is van een uitrol (patch, upgrade, hardware change, nieuwe software installeren, etc etc.)
Zodra dat in orde en geakkoordeerd is door de betreffende afdelingen na het testen, dan kan er een begin gemaakt worden met het doorvoeren van de change.
Van welke afdelingen moet je doorgaans akkoord hebben voor je een patch doorvoert?
ICT afdelingen in grote bedrijven zijn heel rol en procedure gericht.
Ik bepaal hier in mijn hoedanigheid (mkb) gewoon op de natte vinger (licht overdreven) of ik een patch over onze werkvloer kan uitrollen maar als je tweeduizend desktops hebt met tailored software die niet zomaar neer mogen op basis van arbitraire lasten en voorwaarden spelen er andere krachten en moeten er verschillende disciplines binnen het ICT vak er een plasje over doen, managers niet op de laatste plek.

Men ziet een ICT'er vaak als iemand die gewoon veel van computers weet, maar in serieuze omgevingen heeft elke discipline een eigen persoon of zelfs eigen team. Denk aan werkplek beheer, serverbeheer, netwerkbeheer, databasebeheer, applicatie ontwikkeling en support om een paar voorbeelden te noemen.
Dat zijn geen omgevingen waar je met je goede intentie even een patch naar binnen hengst op basis goed vertrouwen en een schietgebedje. Zeker niet als dat ergens dingen kapot zou kunnen maken waar je die dus ook niet kan herstellen.

[Reactie gewijzigd door Koffiebarbaar op 5 juni 2019 16:45]

Alle afdelingen die geraakt kunnen. Verschilt per organisatie.
Soms kiezen ze er voor om een risico voor lief te nemen omdat de negatieve impact vele malen kleiner is dan de positieve impact.
Ik kan mij voorstellen dat, met complexe applicatielandschappen en bedrijfskritische applicaties, je dingen wilt testen voordat je ze installeert. Verdere bronnen etc heb hier hier niet van....
Kun je zo even in een VM testen.
Meeste beheerders lopen achter, omdat ze het risico niet willen van veel bugs en lekken. Die wachten af wat de recensies zijn van een bepaalde versie en als de meeste bugs eruit zijn gaan ze pas updaten.

Nooit een goed idee om een productie-omgeving direct over te laten gaan, dan vraag je om problemen.

[Reactie gewijzigd door Tourmaline op 5 juni 2019 16:08]

Nouja, "zo even" testen in een VM is niet voldoende. Als de productieomgeving ook virtueel draait is het wel prima in een aparte VM omgeving te doen, maar dan nog moet de host ook gepatched worden, en dit is niet te testen in een VM.
Er zijn al veel productieomgevingen die of op VM draaien of in de cloud.
Ja, maar die VM of cloud-instance draait ook op fysieke hardware. Vaak moet die ook gepatched worden, zoals bij de recente reeks CPU-bugs. Downtime is vaak onvermijdelijk, o.a. omdat niet alle platforms live-migration van VM's ondersteunen.
Alleen is dat vaak "cloudbased". Het is niet een lege term als dit juist wordt ingezet. Je virtuele omgeving draait namelijk niet op 1 systeem en bij grote organisaties, vaak in hun eigen datacenters. Je gaat dan niet alle systemen tegelijk updaten, dan rol het je gefaseerd uit. 1 of een paar servers die plat gaan buiten de kantooruren zou niet veel uit moeten maken.

Downtime is onvermijdelijk, ook de reden waarom MS rustig het systeem herstart als die denkt dat dat nodig is. Maar je kunt het spul wel dusdanig opzetten dat de downtime van 1 (of meerdere systemen) geen invloed zou moeten hebben op het bedrijfsproces.
Klopt, als je het goed opzet, maar dan komen we weer terug op het begin van deze thread. Vaak wordt er onvoldoende budget besteed om alles redundant uit te voeren. Met name in het MKB ontbreekt vaak de kennis of het budget om dit correct te doen en worden updates uitgesteld doordat downtime niet goed uitkomt of zelfs vergeten door onvoldoende monitoring. Is allemaal te voorkomen inderdaad.
Niet altijd een kwestie van besteden. Soms is het budget er gewoon niet. Een organisatie waar ik voor werkte had 2 datacenters. 1 was bedoelt als redundancy en was dus een mirror van datacenter 1.

Tot het financieel te krap werd, 1 datacenter te weinig was qua performance als op een dag iedereen toch aan het werk ging. Door gebrek aan budget, is men datacenter 2 gaan gebruiken en men gaan load balancen over de datacenters heen.

Even een derde datacenter erbij plaatsen of de huidige 2 upgraden is dusdanig kostbaar. Dat heb je niet 1,2,3 even geregeld.

MKB is inderdaad vaak een puinhoop, maar die kunnen vaak beter terecht bij een cloud provider zoals Amazon, Google of Microsoft. Beter investeren in een dubbele internet aansluiting dan zelf het beheer te doen van alles. Voor een paar kleine MKBs ben ik ook de handige IT harry. Er werken vaak minder dan 5 of 10 man in zo'n bedrijf en een dedicated ITer is gewoon geen ruimte voor. Die informeer ik ook met "Laat X of Y de exchange lekker beheren, hou een servertje lokaal voor backup mogelijkheden. Maar investeer liever in die glasvezel aansluiting en hou je DSL als backup zoals we dat vroeger met inbel deden.". Met moet het in veel gevallen gewoon helemaal niet meer zelf willen doen.
Simpele dingen kunnen in 'een' VM. Voor het nabootsen van een compleet systeem inclusief SAN kan je het wel leuk virtueel doen maar we stonden alsnog om middernacht updates terug te draaien toen het mis ging omdat virtueel toch niet hetzelfde is als fysiek...
Klopt, maar je kunt zo redelijk veel checken.
Tot je tegen een driver probleem aanloopt en die driver niet in je VM gebruikt wordt maar wel op de server zelf.
Bedrijven (bv Ziekenhuizen) die certificaten nodig hebben van leveranciers van elke patch alvorens ze die mogen toepassen op datzelfde systeem. Dwz dat de leverancier eerst de patch test voordat ze de klant de toestemming geven dat ze die patch mogen toepassen.
Ah, dat is een interessant punt, is dat als je legacy software draait of bedoel je als je specifieke hardware hebt zoals een MRI-scanner met bijbehorende firmware oid?
Ook voor bijvoorbeeld drivers van videokaarten waarmee complexe berekeningen worden uitgevoerd. De leverancier van de software die de berekeningen uitvoert zal een bepaalde versie van de driver valideren, dat is dan een versie waarvan zij een correcte werking garanderen.

Als een nieuwe versie driver beschikbaar komt moet deze eerst bij de leverancier door de molen voordat deze mag worden geïnstalleerd (is vaak ook afgedicht in SLA's). Binnen de organisatie van de klant zal deze vaak eerst in Test en Acceptatie worden geïnstalleerd om er zeker van te zijn dat er geen gekke dingen gebeuren, daarna wordt e.e.a. pas naar Productie uitgerold.
Zowel bij legacy software of specifieke hardware zou je de betreffende computers gewoon in een apart niet-internet-verbonden Vlan moeten plaatsen.
Dit heeft meerdere voordelen, ten eerste beveiliging, ten tweede voorkom je dat gebruikers op die systemen YouTube of andere content gaan bekijken en wordt de computer dus alleen gebruikt waar deze voor bedoeld is.
Veel bedrijven hebben nu eenmaal patch Windows: elke maand of zelfs elke 2 maanden. Andere teams zoals functioneel beheerders, applicatiebeheerders etc.. weten dan dat ze moeten opletten want er kan iets 'omvallen' als er gepatchd wordt.

Zomaar even patchen in bijvoorbeeld een industriële omgeving of een ziekenhuis waar er letterlijk doden kunnen vallen als software ineens niet meer werkt is vaak not done.

Helaas is patchen en niet slachtoffer worden veel minder zichtbaar en tastbaar voor bedrijven dan die keer dat software niet werkte toen er gepatchd werd.

[Reactie gewijzigd door ApexAlpha op 5 juni 2019 16:03]

change management, vaak door ITIL processen te implementeren. Is een noodzakelijk kwaad eens je IT omgeving groter begint te worden dan "ik ken alle andere IT'ers".
Omdat een OTAP omgeving gewoon geld kost. Simpelweg omdat het meer resources kost. 1 systeem is niet voldoende.

Het installeren, testen, publiceren kost tijd, kunde en dus geld.

https://nl.wikipedia.org/wiki/OTAP

https://www.computable.nl...geving-is-halve-werk.html
Wat ik vaak zie tijdens ISO 27001 implementatietrajecten die ik begeleid (zelf geen sysadmin achtergrond maar wel procesmatig in aanraking komende), is dat bij veel bedrijven (een deel van) IT achter de feiten aanloopt door:
1) Onvoldoende (gekwalificeerd) personeel in huis;
2) IT zelf niet op orde is en vaak op ad-hoc basis gewerkt wordt;
3) Er onvoldoende wordt ingezet door het management op IT. Dan kom je deels bij punt 1 terecht, maar dit laat wel zien dat het hoger management vaker niet dan wel prioriteit geeft aan IT. Punt 2 zie ik vaak bij bedrijven die reorganisaties achter de rug hebben, onlangs overgenomen zijn, etc.;het gaat niet om de 'gevestigde orde' qua bedrijven.
In grote omgevingen kan je niet simpelweg alle machines direct gaan patschen. Ten eerste zijn er procedures (die tijd nemen) om dat soort changes in goede banen te leiden. Ten tweede is er een prioriteit/hiërarchie die moet voorkomen dat kritische systemen er zomaar uitvliegen. je zal dus eerst de testomgeving updaten, dan de staging en dan pas productie.
Dat maakt dat bij de normale patchrondes het gerust enkele weken kan duren voor alles geüpdatet is - gesteld dat de risicoanalyses goed uitvallen.

Verder is bovenstaande uitgaande van grotere omgevingen waar zulke dingen meestal wel vastgelegd zijn (en er dus ook procedures zijn voor extra kritische/dringende patches). Maar er zijn zoveel middelgrote bedrijven waarbij er géén heel team is, geen formeel security of change management en de systeembeheerder té veel taken heeft. Maandelijks tijd vrijmaken/houden voor patches krijgt dan niet altijd de juiste prioriteit.

en dan rest nog het echt klein bedrijf. Met wat geluk hebben die een IT partner die dit voor hen opvolgt. Maar ze vertrouwen misschien net zo goed op het automatisch updaten (of "standaard veilig zijn") of de skill van een medewerker of kennis.
You cannot beat the best hackers, just focus on your work. Keep in mind a delay of 3x
Het heeft ook te maken met hoe er voorheen werd omgegaan met het patchen van systemen. Terwijl Microsoft nieuwe patches altijd testte op systemen die alle voorgaande security patches ook hadden geïnstalleerd, bleek in de praktijk dat bedrijven alleen de noodzakelijke patches installeerden, omdat heel wat patches de boel hadden gesloopt in het verleden. En door dit scenario (volledig gepatched tegen noodzakelijk gepatched) bleef er een hoog risico dat een losse patch problemen kon gaan geven. Eigenlijk een beetje kip-ei verhaal dus :) Microsoft heeft een afbeelding ter illustratie op de Windows as a Service docs pagina: https://docs.microsoft.co...s/waas-overview-patch.png

Voor Windows 10 (en de bijbehorende server OS'en die op dezelfde manier zijn gebouwd) brengt Microsoft daarom updates uit die cumulatief zijn. Meer info op: https://docs.microsoft.co...ment/update/waas-overview
Hey!
Ik lees allemaal de dingen hier die ik ook heb gezien.
Kwestie van onkunde, incompetentie, onwetendheid, budget en idioterie. Die heb je allemaal al gezien.

Ik weet nu bij een bedrijf waar, godzijdank, elke maand alles gepatched wordt. Daar zijn dan 2 man (soms 3) een paar uur in de nacht mee bezig. Omdat veel systemen redundant zijn ( I know right, niet alles, want dat zou alleen maar praktisch zijn) doen we een deel overdag. (Paar honderd serverts)

Ik heb ook op plaatsen gewerkt waar het te 'eng' was. Zoveel achterstallig onderhoud, dat je er bang van wordt.

En zo is het ook. Als je nooit, of sporadisch, onderhoud doet, dan wordt 'de delta' ook wel erg groot. Elke zoveel patchrondes is er 'een dingetje'. Dat is onhandig, had je al door omdat de test omgeving (TM, famous last...). En anders heeft de monitoring, of in het ergste geval de medewerker op op straffe van stokslagen 's morgens zeer vroeg aanwezig dient te zijn wat te doen.

Maar goed, als je dan een tijd dat niet zou doen, dan stapelen die dingetjes zich op ... En dan wordt het vervelend. En naar. En kijken we de andere kant maar op.

Vergelijking. Er zijn bedrijven die het noodaggregaat nooit testen, of op een veilige testmanier testen. Of een keer per jaar. Als er dan iets is, dan weet je minder goed wat er zou kunnen zijn. Als je nou (zoals sommigen) elke maand keihard test door een powerfeed uit te zetten, en kijkt of de reut normaal opstart dan heb je het in de vingers.
Mocht het stukgaan, dan hoop ik dat je er aan dacht om een dubbele powerfeed in te kopen ;)
Maar het gaat haast nooit fout, want elke maand test je het. Dan weet je dat het een ding kan zijn dat kennelijk je koelwater op kan zijn, want... Dat gebeurde voorig jaar ook, en sindsdien monitor je dat.

Resumerend: vaak doen, elke maand. Als het routine is, wordt het makkelijk.

Overigens, ook... Als je routine hebt, ben je voorspelbaar voor je gebruikers. Als iets kapot is, kunnen mensen denken, ohja! Dat aangekondigde onderhoud op de tweede woensdag, na de dinsdag met volle maan! Ze hebben het weer verkloot.. we bellen wel weer...
Daardoor is het beeld ontstaan dat IT makkelijk is. - Amen brother! Ik was bij een training in een zo'n conference zalencentrum. Na afloop borrelen, en loop daar een gezelschap binnen van een politiek partij (over mensen gesproken die het echt niet begrijpen). Ik raak daar in gesprek en er wordt mij gevraagd wat ik doe. Zoals de meeste zeg ik doodgewoon "Ik ben IT-er". Toen barstte men los. "Is iedereen tegenwoordig IT'er? Hoeveel hebben we er wel niet nodig?! Hoeveel IT'ers heb je nodig om een lamp te vervangen, HAHAHAHAAH". Ik dacht bij mezelf: "Moet je jezelf nou zien staan, beetje whatsappen, kalenderuinodigingen delen voor morgen ochtend met degene die naast je staat. Heb je enig idee hoeveel IT je in je hand hebt? Hoeveel mensen gewerkt hebben en werken aan de alle producten en diensten die jij zojuist geactiveerd en gebruikt hebt. Duizenden! Je zou jezelf die vraag moeten stellen, hoeveel ICT'ers hebben we eigenlijk nodig? Pannekoek". Maar in plaats daarvan lachte ik vriendelijk, ben omgekeerd en weggelopen naar de bar, nog maar een biertje halen.

Ik ben in te huren voor feesten en partijen,of als je hier echt diep op in wilt gaan ;)

[Reactie gewijzigd door Chud op 6 juni 2019 21:14]

"en dat de wet het niet eens toestaat om zonder te testen deze patches uit te rollen"

Bron?
Waar staat hier de betreffende wetgeving dan?
Jij zegt dat de wet het niet toestaat. Er is volgens mij geen wet die je verbied om (in je productie omgeving) patches uit te rollen zonder te testen.
Das natuurlijk wel gelijk het andere uiterste hè
(eentje uit de oude doos van persoonlijke ervaring) Bij een bedrijf waar wij voor werken (maar niet instaan voor patch beheer)
Had een ITer (uit een niet nader genomen Aziatisch land met veel "gespecialiseerd" IT-support) besloten dat een patch uitgerold moest worden naar alles, inclusief alle nodige prerequisites.
Dit naar aanleiding van een dergelijke melding.
Maar een van die prereq was ook een minimum versie van OS. met gevolg dat ook oude win 7 en zelfs XP een upgrade kregen naar windows 8, ook al konden de PC's en vooral de stuur programma's dit niet aan.
= wereldwijd alle productie stil.
Mochten wij bijspringen om alles te restoren , heeft een week geduurd eer alles weer up&running was.
vandaar het belang van een degelijke OTAP omgeving (zie boven)
De amerikaanse overheid zit echt veel dichter op cybersecurity dan wat we hier gewend zijn. ik kan alle sysadmins de mailings van US-NIST en US-CERT/CISA aanbevelen. Ten eerste omwille van netjes opgelijste kwetsbaarheden mét CVSS scores (en motivering), ten tweede omwille van praktische guidance mbt de afhandleing van belangrijke security problemen zoals dit.
ik volg deze mailings inmiddels al jaren (begonnen als professionele verplichting, nu meer uit interesse).
Bovendien publiceren ze ook guidance mbt best practices en hardening voor verschillende levels van "veilige omgevingen"

http://public.govdelivery...SDHSUSCERT/subscriber/new
De Nederlandse overheid doet dit overigens ook. Op de website van het NCSC staan onder andere beveiligingsadviezen. De RSS feed met beveiligingsadviezen wordt zeer regelmatig bijgehouden, voor alles van browsers tot professionele firewalls.

Ook brengt het NCSC jaarlijks adviezen uit over bijvoorbeeld welke versie van TLS met welke ciphers nog veilig zijn om te gebruiken, tweefactorauthenticatie, noem maar op.

Wellicht is de Nederlandse info niet zo compleet als die van hun Amerikaanse collega's maar het is zeker waard km in de gaten te houden!
ik ken deze bronnen ook! Maar de Amerikaanse gaan toch een heeeel stuk verder. Bovendien gaat het om mailings, en moet ik dus niet telkens op een website op zoek naar updates :)
Om je een idee te geven hier wat voorbeeldlinks naar de webversie van recente mailings:
SB19-154: Vulnerability Summary for the Week of May 27, 2019
AR19-133A: Microsoft Office 365 Security Observations

Het is natuurlijk sowieso een goed idee om meerdere bronnen te volgen.... en zeker niet alléén de Amerikaanse.
Ah, dat is wel een heel stuk uitgebreider ja. Die gaat in mijn lijstje.

Ik heb het NCSC-nieuws in m'n RSS reader staan en op werk geeft de Slack-bot voor iedere post een melding dus gelukkig hoef je er dus niet per se achteraan als je het een keer goed instelt. Dan moet je wel iemand zijn die nog RSS gebruikt there are dozens of us! en sinds de opkomst van social media is RSS toch wel een beetje ingestort.
Hehe, dat doet me denken aan dit artikel. https://www.huffpost.com/..._56425674e4b0364e0dbbe633
Als je dan kijkt naar het plaatje waar het populairder werd, dan zie je Nederland keihard groeien op het kaartje van Europa. :P
Wederom, waar is Vista?
Het lijkt weer alsof Vista hier niet door getroffen wordt, terwijl Server 2008 wel wordt genoemd en deze in de basis eigenlijk niet veel verschilt.
Wellicht dat @Tijs Hofmans hier wat over kan vertellen?
Vista is al 2 jaar uit de uitgebreide ondersteuning. Microsoft maakt daar dus geen patches meer voor. 2008 wordt nog ondersteund tot Januari volgend jaar.

Dat XP en 7 wel een patch krijgen is opmerkelijk, maar is dan ook net de uitzondering. Deze 2 OSen zijn al uit ondersteuning maar worden nog redelijk wat gebruikt (in tegenstelling tot Vista). Ik ben zelf geen voorstander van het feit dat MS er toch nog patches voor uitbrengt want dat geeft een slecht signaal naar beheerders die weigeren te upgraden.
Inderdaad out-of-support, net als XP en 7.
Maar net zoals voor XP en 7 is er wél een patch voor dit issue :)
Wel voor Vista, alleen hebben ze voor Vista er een andere update van gemaakt blijkbaar, maar resultaat is hetzelfde: https://support.microsoft...uidance-for-cve-2019-0708
Bij meerdere bedrijven heb ik al gemerkt dat er een afwachtende houding is op updates uit te rollen. Dit i.v.m. de KB artikels die nog wel eens problemen willen geven.
Tevens zijn er vaak ook nog test groepen in huis waar dit eerst wordt getest, voordat de grote uitrol plaats vind.
In het MKB kan het ook lui-/laksheid en/of onkunde zijn.
Ik ben momenteel student systeembeheerder en wat in onze opleiding steeds aan bod komt is het implementeren van redundancy en fail-overs.

Ongeacht of het om een patch gaat of niet, kan het altijd voorkomen dat één van je systemen uitvalt en/of er andere issues voorkomen.

In mijn stage op een school hebben wij bv alles virtueel draaien. We nemen elke dag een incremental backup en om de 2 weken een full back-up. Regelmatig testen wij een back-up door deze terug te plaatsen.

Aangezien we virtueel werken is het in ons geval eenvoudig om even een snapshot te restoren en de meest recente back-ups terug te plaatsen.

Het onderhandelen van goede SLA's is ook belangrijk in ons werk. Kan het niet tijdig opgelost worden, kan je desnoods de sla inschakelen. Wij hadden laatst ook problemen met onze exchange server dat niet snel kon opgelost worden door ons. Een telefoontje naar Microsoft en ze stuurden een team van 7 man om dit even op te lossen binnen 48 uur. Ondertussen draaide wel een extra exchange server.

Het lijkt mij in ieder geval best wel onverantwoordelijk om geen risks in te calculeren als systeembeheer en lijkt het mij ook één van onze taken om het management hiervan te overtuigen. Lukt dit niet, dan lijkt het mij ook geen bedrijf waar ik zou willen werken.

[Reactie gewijzigd door saucemarocain op 6 juni 2019 02:21]

Wilt de NSA nu hun reputatie verbeteren in tweakersgroeperingen .... :/
Goh, er is al veel geschreven over dit lek en bijhorende patch, maar leest iedereen wel alles? Dit lek kan alleen gebruikt worden, als Network Level Authentication (NLA) niet enabled is, en volgens mij staat dit gewoon standaard aan.. Dus controleer de NLA setting op je RDS omgeving en je bent ook al safe, dan kan die patch wel even wachten.
Ik vroeg mij dit zelf ook al af. NLA authenticeert al voordat de RDP sessie wordt opgezet...
Helaas zie ik zelf wel erg vaak dat NLA nog uit wordt gezet via een GPO vanwege 'historie'.
Hetzelfde geld voor de Windows Firewall en UAC.
Nee dat klopt niet. NLA is geen standaard enabled instelling op oudere OS versies welke kwetsbaar zijn.
NLA (Network Level Authentication) is per default enabled since Windows 8 / 8.1 and Windows Server 2012.
No Such Agency
Als wij als extra authenticatie DUO Security er tussen hebben zitten, zijn wij dan veilig met 2008 R2?

Op dit item kan niet meer gereageerd worden.


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True