"IE noodpatch pas over maand geinstalleerd"
Veel bedrijven zullen de noodpatch voor het recente Internet Explorer zero-day lek pas over een maand uitrollen. Dat zegt Darien Kindlund, senior staff scientist bij het Amerikaanse beveiligingsbedrijf FireEye, tegenover Security.nl. "De meeste organisaties hanteren een cyclus van een maand om nieuwe patches te testen. Dus ondanks dat Microsoft een noodpatch heeft uitgebracht, verwachten we dat de aanvallen via dit lek zeker nog een maand zullen aanhouden voordat ze afnemen."
Volgens Kindlund is het een goed idee om bijvoorbeeld ook een alternatieve browser op de werkvloer te ondersteunen, zodat gebruikers een keuze hebben. "Het gaat niet om het gebruik van een bepaalde browser, maar het hebben van de mogelijkheid om op een andere browser over te stappen om flexibel met dit soort dreigingen om te gaan." De onderzoeker noemt dit een legitieme tactiek om veel van dit soort zero-day problemen te verhelpen.
Beveiligingslekken worden in alle browsers ontdekt, gaat Kindlund verder. Een zero-day kwetsbaarheid in Firefox zorgde een paar jaar geleden ervoor dat de Duitse overheid adviseerde om tijdelijke Firefox te weren.
"Als je weet dat een nieuw lek is gepubliceerd en je gebruikers eenvoudig kunnen omschakelen om hun werk te blijven doen, is dat een prima legitieme tactiek om het risico te verkleinen."
Defensie
Een aantal van de aanvallen die van het recente IE-lek misbruik maakten waren tegen Defensiebedrijven gericht. Dit soort bedrijven zijn vaker het doelwit, onder andere van malware die misbruik van een drie jaar oud lek in Adobe Reader maken. Je zou verwachten dat Defensiebedrijven over de meest recente versies van browser, PDF-lezer en kantoorsoftware beschikken, om zich via nieuwe beveiligingsmaatregelen beter te beschermen. De werkelijkheid is echter anders, stelt Kindlund.
"Het is lastig voor dit soort bedrijven om de software bij te houden die als een uitbreiding op hun primaire applicatie wordt beschouwt." Niet alleen worstelen deze organisaties met hun browser, maar ook alle plug-ins en aanvullende software kan volgens Kindlund voor problemen zorgen. Ook kan het voorkomen dat systemen vergeten raken of over meerdere versies van een bepaald programma beschikken.
Basis
"Patchmanagement zou echt de minimale basis voor dit soort organisaties moeten zijn, maar helaas is dat niet zo eenvoudig als het lijkt." Bij het upgraden naar Adobe Reader X en Office 2010, die allebei over een sandbox beschikken, wordt er tegen allerlei interne processen aangelopen, stelt de onderzoeker.
Zo moeten interne systemen met de nieuwe versie overweg kunnen. Iets dat makkelijker is gezegd dan gedaan. "Dat is de reden dat dit soort kwetsbaarheden en aanvallen nog steeds succesvol zijn."
Neem Access. We hebben databases die stammen uit het Office 97 tijdperk. Die zijn destijds geconverteerd naar 2003 en nu met 2010 loop je tegen exact dezelfde punten aan. Macro's doen niet meer wat ze voorheen wel deden... Maar het lastigste is dat binnen een flinke organisatie de geschiedenis en het eigenaarschap niet boven tafel te krijgen is. Afdeling x werkt met database y en dan doen ze al jaren en ooit heeft iemand dat zo opgezet, maar niemand weet nog hoe de vork in de steel steekt. Dat kost tijd.
Doe dat keer het aantal afdelingen en voor je het weet ben je een jaar verder.
Het is leuk dat er zo nu en dan nieuwe versies uitkomen van software, maar de leverancier gaat je vaak niet even helpen wanneer oude meuk het niet meer doet.
kortom: met het patchen van het IE lek is de gatenkaas één gaatje dichter geworden.
mbt de strekking van het artikel: helemaal mee eens. In een grote omgeving is het lastig (zo niet bijna onmogelijk) om alle patches snel en adequaat aan te brengen.
Dan denk ik dat het lek minder gevaarlijk is, dan het scenario waar ze al in zaten.
Soms is het ook de vraag als er een lek is hoe groot de kans is dat je kwestbaar bent als bedrijf.
Mis vaak ook veel meer informatie over een lek:
- Hoe schadelijk is het lek zonder admin rechten?
- Hoe schadelijk is het lek met Applocker? (BV alleen Program Files folder en Windows folder mogen executebles starten)
- Hoe schadelijk is het lek voor het bedrijf om tijdelijk internet toegang uit te schakelen en alleen intranet sites te gebruiken en wachten op de patch? Sommige bedrijven gaat dit makkelijker dan andere....
- Is alleen voor XP, Vista of Windows 7, dan wil je nog weten of 32 of 64 bit alleen geraakt wordt.
- Had bijvoorbeeld in IE lek vorige week ook over kunnen schakelen naar IE 64 bit? Was dat een optie geweest? (Op Windows 7)
- Is het uitschakelen van de bekende IP en DNS adressen van C&C servers voldoende?
Dan vraag ik me ook af wat er in die maand allemaal getest wordt en door wie.
Wij hadden de vorige cumulative update er uiteraard al op staan en ik heb die noodpatch gewoon ongetest dat zelfde weekend uitgerold.
We hebben altijd nog een andere browser achter de hand, en voor dit soort dingen geldt ook dat je een goed excuus hebt als er wat breekt.
Microsoft ondersteund elk product minimaal 10 jaar. Lijkt mij toch een redelijk termijn, ook voor grote bedrijven.
Lekker je business critical app naar de galemiezen helpen met een ongetest patch, ja dat is een goed idee.
Je kan beter even goed testen en in de tussentijd verbinding met het internet uit gooien, dan maar even geen security.nl
Op 2003/citrix server in VMWare loopt je systeem vast met deze patch. Dat voorkomt natuurlijk wel dat je geïnfecteerd raakt met iets engs.
In dit geval is de patch haast erger dan de malware?
Nee, dat is helaas niet altijd te verantwoorden. Als de security patch een business critical proces om zeep helpt of een bepaalde applicatie op de werkstation breekt, doordat die client applicatie b.v. alleen een bepaalde versie van Java accepteert, dan is dat zeker niet te verantwoorden zonder potentieel een miljoenenschade te riskeren, met name bij organisaties met tienduizenden of honderdduizenden werkplekken. Ja, het is zo dat in dat geval beter over de requirements nagedacht had moeten worden bij de aanschaf van het product, maar daar kun je in sommige gevallen de huidige asset owner niet mee lastig vallen.
Er zal gekeken moeten worden naar het risico dat wordt gelopen bij installeren of niet installeren van de patch. Soms zijn er alternatieve mogelijkheden om het risico te mitigeren of is de kans op uitbuiting zeer klein, waardoor beter niet dan wel kan worden gepatched. Het verhaal van Mysterio klinkt me ook zeer bekend in de oren, vooral bij organisaties die van mening zijn dat de IT afdeling niet snel genoeg kan leveren. Wat kun je dan krijgen: die ene programmerende collega, die alweer een paar jaar weg is zonder het source code beleid na te hebben geleefd, weet een mooie tool te bouwen die aan alle business specs voldoet. Voor je het weet is zo'n brakke tool mission-critical geworden en begint de ellende. Als de druk vanuit de business maar hoog genoeg is, kun je nog zo proberen je poot stijf te houden met een principe als "eigen brouwsels worden niet ondersteund"... als een Level 1 manager op de stoep staat gaat uiteindelijk toch iedereen rennen. Zij verdienen namelijk het geld, IT faciliteert in dat opzicht alleen.
Bij een beetje zichzelf respecterende fabrikant zijn bestandsformaten, talen en db-formaten gewoon upward compatible.
Bij access zitten er zelfs al binnen de versie verschillen in de scriptsyntax per landstaal :((
Op 2003/citrix server in VMWare loopt je systeem vast met deze patch. Dat voorkomt natuurlijk wel dat je geïnfecteerd raakt met iets engs.
In dit geval is de patch haast erger dan de malware?
Dit is beslist niet het geval, we draaien met deze patch in precies de bovenstaande configuratie.
Bedoel je soms dat de machine soms heel lang blijft hangen in het windows logoscherm met daaronder die bewegende balk bij het opstarten?
Dat is een probleem wat niet door deze patch veroorzaakt wordt.
Daarnaast ben ik van mening dat wanneer je als softwaremaker de keuze maakt om gebruik te maken van andere software componenten (even los van het OS), dat je je ook moet beseffen dat dit betekent dat je je ook flexibel moet opstellen als het gaat om updates, en zorgen dat je eigen software daar geen of nauwelijks hinder van heeft.
Echter de praktijk is dat vrijwel iedereen die toestemmingen uiteindelijk krijgt, omdat er in de tegenwoordige tijd altijd wel een of andere werkgerelateerde toepassing voor is.
En dat is dan in een gewoon bedrijf met kantoormedewerkers en productieleiders, geen IT bedrijf of zo iets.
kortom: met het patchen van het IE lek is de gatenkaas één gaatje dichter geworden.
mbt de strekking van het artikel: helemaal mee eens. In een grote omgeving is het lastig (zo niet bijna onmogelijk) om alle patches snel en adequaat aan te brengen.
en als het geen java is, dan wel flash, en als het geen flash is, dan wel... etc. etc. :)
whitelisting van websites is goeie methode, zoveel websites surfen mensen toch niet naar.
Weet iemand goeie website whitelists?
Omdat dat bijna niet te doen is.
Je kunt niet "toegang tot een website" verlenen. Dan moet je gaan uitzoeken wat die website allemaal nodig heeft om te functioneren en dat is veel te veel werk bij sommige websites. En error-prone want dan is er wat aan de site veranderd en dan werkt het ineens op subtiele wijze niet meer, omdat een of andere .css of .js ineens niet meer geladen wordt ofzo.
We hebben alleen blocklists. Een lijst van URLpatronen die altijd geblokkeerd is, en een lijst die gedurende werktijd geblokkeerd is en waarop met extra toestemming een uitzondering gemaakt kan worden. Daar staan de bekende timewasters zoals facebook, marktplaats, messenger diensten e.d. op.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
