100 procent veiligheid bestaat niet. Hackers vinden dagelijks nieuwe technieken of zwakke plakken om door de beveiliging heen te breken. Voor optimale weerbaarheid tegen hacking is security-beheer dus essentieel. Een van de basisuitgangspunten is dat virusscanners dagelijks kijken of er updates zijn.
Nog een voorbeeld dat zorgt voor een gedegen beveiliging van de kantoorautomatisering is Patch Tuesday, de tweede dinsdag van de maand waarop Microsoft de maandelijkse beveiligingsupdates voor de Windows-systemen en andere Microsoft-producten uitgeeft. Deze update-mechanismen zitten ook ingebouwd in de nieuwste generatie firewalls en inbraakpreventiesystemen. Toch wordt deze functionaliteit nauwelijks gebruikt. Kies in deze veranderende digitale wereld voor inbraakpreventie en vertrouw op het automatische update-mechanisme van de security-expert!
Vanuit securityoogpunt worden er plusminus tussen de vijftig en honderd beveiligingsadviezen per maand uitgegeven. Organisaties vertrouwen nog nauwelijks op de auto-update-mechanismen van de firewalls en inbraakpreventiesystemen. De reden is vaak duidelijk: bij elke update bestaat er immers de kans dat vertrouwd (web)verkeer wordt geblokkeerd. Je internetvoorzieningen – zoals webwinkels en de eigen website – functioneren als gevolg van een auto-update mogelijk niet 100 procent betrouwbaar. Het is dus een dilemma tussen beschikbaarheid versus security.
Zwakke plekken
Criminelen zoeken de zwakste plek in de beveiliging. Dit is veelal de gebruiker en niet de (web)applicatie in het hoog-beveiligde datacenter. Hackers hebben dus een zeer duidelijke focus om in te breken via het gebruikersnetwerk. Door een doelgerichte phishing–aanval probeert de crimineel in te breken in het netwerk van het doelwit. En na inbraak kijkt de crimineel hoe hij zijn weg binnen het netwerk en naar het datacenter kan vinden. Als je het met bovenstaande gedachte eens bent, kun je overwegen om het automatische update-mechanisme voor het gebruikersnetwerk scherper in te stellen.
De meeste leveranciers van de nieuwste generatie firewalls geven bij elk beveiligingsadvies een aantal extra parameters mee. Bij leverancier Check Point zijn dat bijvoorbeeld low, medium, high en critical. De belangrijkste is het dreigingsniveau. Op basis van deze extra parameters kunt u beslissen om vanaf een bepaald dreigingsniveau automatisch te filteren dan wel alleen te detecteren en monitoren. In het eerste geval wordt er direct bescherming geboden, in het tweede krijgt de security-expert een signaal wanneer er mogelijk herkenbare aanvallen plaatsvinden. Op deze manier kunt jezelf starten met het automatisch filteren vanaf een hoog dreigingsniveau en het automatisch alarmeren vanaf een middelhoog dreigingsniveau. Extra bescherming met voldoende zekerheid rondom beschikbaarheid.
Mijn ervaring is dat je met deze twee gedachtes aan de slag moet gaan om de beveiliging verder aan te scherpen. Start met het automatisch updaten van het gebruikersnetwerk vanaf een hoog of kritisch dreigingsniveau. Hierdoor zie je de bevestiging dat security-vendors op een hoog niveau acteren. Ditzelfde niveau kun je ook binnen de organisatie hanteren, je kiest precies dat niveau dat bij jouw beveiligings- en risicoprofiel past. Je ziet dat de auto-updates werken en de hele organisatie acteert op een hoger beveiligingsniveau. Na verloop van tijd zul je merken dat het vertrouwen in auto-update-mechanismen vergelijkbaar is met het vertrouwen in de onmisbare auto-update van doodgewone virusscanners. Dit betekent dat je met een gerust hart de beveiliging voor dit zeer belangrijke cybersecurity-aspect hebt geregeld. Een kleine stap voor de security-experts zorgt voor een grote stap voorwaarts in het verhogen van de weerbaarheid en het beveiligingsniveau van de ict-infrastructuur.
Bastiaan,
Zoals je al aangeeft werken service/applicaties niet altijd meer na aanbrengen van fixes en is het dus een stukje risico management (casino) om dit wel of niet automatisch te doen. Mooiste zou het patchen van de hele stack in een keer zijn als onderdeel van het change management proces. Als dan gelijk deze wijzigingen ook door verwerkt worden in test- en acceptatiesystemen dan scheelt dat al veel problemen. Maar zoals je al stelt zijn het veel fixes met niet alleen verschillende severities maar ook frequenties.
Natuurlijk blijft het een goede practice om patches aan te brengen maar mischien dan toch beter semi-automatisch om zodoende te voorkomen dat bij verstoring het zoeken naar RCA erg omslachtig wordt. Ook is het niet onverstandig om de ‘bijsluiter’ te lezen, iets wat dus bij een automatische uitrol niet gaat. En hoewel de service natuurlijk actief bewaakt wordt is wat extra oplettendheid na aanbrengen van patches ook nooit weg. Het zal tenslotte niet de eerste keer zijn dat de prestatie opeens in zakt.
Patchen is dus meer dan ‘set and forget’ zeker als het over gebruikers gaat. Want deze zetten nog weleens de virusscanner of firewall uit en negeren de kritische updates. En nog te vaak wordt het gedaan vanuit een puntoplossing waardoor bij verstoringen het gebruikelijk wijzen weer plaats vindt.
Puur uit veiligheidsoogpunt gezien is het eenvoudig weg beter om helemaal geen gebruik (meer) te maken van Microsoft produkten. Niet omdat Microsoft aktief meewerkt aan ongrondwettige afluister praktijken maar omdat het simpelweg wacht met het patchen van veiligheidslekken zodat niet alleen overheidsinstanties maar ook criminelen hier misbruik van kunnen maken. En er is dan ook al een stevige handel in het ontdekken van deze zwakke plekken en dit te verwerken in de nieuwste modulaire software tooling die de moderne criminele hacker tot zijn beschikking heeft.
@Johan
Als iedereen over zou overstappen op Linux of Apple, hoe lang denk je dan dat het duurt dat daar ook de eerste lekken misbruikt gaan worden?
Het “gemak” van Windows voor hackers is dat, als je eenmaal iets gevonden hebt, meteen heel veel systemen kunt hacken.
Op het moment dat je je systeem aan het internet hangt, maak je jezelf kwetsbaar, ongeacht het OS.
@Johan en Pa Va Ke
Dat Windows sinds versie 7 vele malen veiliger geworden is moet ik als doorgewinterde linuxgebruiker zelfs toegeven.
Natuurlijk is het waar dat MS patches nog steeds te laat uitbrengt en dat Linux daar nog steeds veel beter werkt. Linux kent ook een auto-update net als windows.
Malware gaat altijd over de grote aantallen, niemand heeft interesse in enkele procenten van de markt, en windows heeft nog steeds een groot marktaandeel. Hoe zeker je met linux bent kun je aan Android zien, bij voldoende grote aantallen sta je dan ook in het vizier van de malware-mafia.
De stelling dat je met MS-produkten per definitie onveilig bezig bent is niet waar. Dat MS “afluistert” geloof ik wel, maar dat doet niet alleen MS, ook Google, Apple, etc. etc.
Uitstekend verhaal Bastiaan; goed gebalanceerd, met aandacht voor het dilemma beschikbaarheid versus security.
Ik ben het met Ewout eens dat patch management een onderdeel van change management dient te zijn. Heb je bijvoorbeeld veel systemen die gepatcht moeten worden, dan kan één foute patch in een automatisch patch proces voor heel veel ellende zorgen. De meeste grote bedrijven hebben dan ook een eigen patch moment na het testen van de aangeleverde patches. Dat geldt niet alleen voor clients, want het automatch patchen van firewalls, viruswalls en routers, kan net zo goed heel vervelend uitpakken.
s
Ben het met Bastiaan eens om vanaf een bepaald dreigingniveau de toegang tot het gebruikersnetwerk automatisch te gaan filteren als de beheerorganisatie de patches niet snel genoeg kan testen. De toegang weer herstellen kan altijd nog.
Voor kleine bedrijven is een set and forget van het automatisch updaten handiger. Doen we ook bij onszelf. Gelukkig worden patches tegenwoordig beter getest dan in mijn begintijd, toen de helft van de patches meer kwaad deed dan goed.
Even aanhaken op reactie van Jan, de handel in 0-day exploits is het lucratiefst als je een groot aantal systemen kunt hacken. De prijs wordt bepaald door omvang en als ik de verhalen mag geloven zijn de kapitaal krachtigste afnemers de overheden.
De term 0-day heeft trouwens betrekking op de tijd die ligt tussen bekend worden van de kwetsbaarheid en het moment waarop de ontwikkelaar begint met het oplossen. En hier zit behalve eventuele verplichtingen naar overheden ook nog weleens een vertragende factor als commercieel belang tussen.
Sommige leveranciers geven een beloning als er een kwetsbaarheid gevonden wordt, andere ontkennen het bestaan ervan. Betreffende closed versus open source is er dus wel wat te zeggen tussen beide vormen op basis van transparantie. Maar onderzoek naar bugs in open source toonde aan dat er niet minder kwetsbaarheden in zitten.
@Ewout, mbt je eerste reactie. Heb je een onderbouwing dat semi automatisch patchen beter werkt dan automatisch patchen?
Ik ben namelijk een sterk voorstander van automatisch patchen, leg druk op mijn klanten dit ook te doen. De laatste tijd is het aantal incidenten van dat dingen ineens niet meer werken door een patch behoorlijk gedaald. Ik denk dat dit opweegt tegen de druk die je legt op de organisatie om hier governance over uit te voeren. Daarbij moet ik wel opmerken dat servers niet zelf rebooten en om een patch effectief te laten zijn moet dit wel gebeuren. Dus beheren zal je 🙂 (in een Azure scenario kun je overigens er wel voor kiezen dat reboots ook daadwerkelijk worden uitgevoerd, om downtime te voorkomen die je wel minimaal 2 instances live te hebben)
Als privé gebruiker heb ik overigens wel een nadeel gevonden in auto patchen. Het gebeurt me regelmatig dat ik SQL Server management studio open heb staan met een complexe query, of 60 schermen open heb staan tijdens research. Dan gebeurt het me nog wel eens dat ik de volgende ochtend na het inloggen ineens “Welcome” zie staan en ben ik 20 minuten bezig om alles weer te krijgen als de avond ervoor. Nu heb ik mezelf aangeleerd om alle notities en dergelijke op te slaan, maar het blijft een ergenis dat Windows steeds moet rebooten minimaal één keer per maand.
Henri,
Misschien moet ik zelf eens een opinie hier over schrijven want naast jouw verrassing met automatisch patchen ken ik er nog wel meer uit de praktijk. Aanbrengen van een patch – soms gewoon een work around – is uiteindelijk een wijziging die je vaak toch enigzins gecontroleerd wilt doen. Al was het maar om te voorkomen dat een systeem op het drukste moment van de dag gaat herstarten. Met semi-auromatisch bedoel ik hier dus in eerste instantie gepland. En als het even kan ook weloverwogen want ook over severity valt nog wel wat te zeggen, een beetje gezond verstand is nooit weg binnen het beheer.
P.S
In mijn reactie dacht ik verder dan enkel windows want daar is het patchen wel aardig te regelen. Kijkend naar de gebruikelijke opdeling in beheer zit er nog een behoorlijke uitdaging in het afstemmen van patchen. Dat is weliswaar meer organisatorisch dan technisch maar geldt ook voor de cloud. Hier vinden trouwens ook nog weleens onaangekondigde wijzigingen plaats met impact op de lopende services.
Dit zal heel sterk afhangen van je omgeving.
Gaat het om een lokale machine, dan kun je er makkelijk bij om de patch, indien nodig, terug te draaien.
Gaat het om een X aantal systemen in het veld die na een patch zich anders gaan gedragen (lees: ongewenst) dan is het terugdraaien een stuk complexer. In zo’n geval wil je de patch eerst graag lokaal testen op één machine, alvorens je de patch gaat installeren op de rest van je systemen.
Zeker bij grote en complexe systemen kan een patch onverwachte neveneffecten geven. Vooral als systemen helemaal gefinetuned zijn op performance, dan kan een op het oog simpele patch grote gevolgen hebben.
Bastiaan,
Ik heb slechte ervaring met “automatische updates” bij veel klanten.
Bij een klant heeft dit het mailsysteem op z`n kop gezet dus alles weer herstellen, bij andere heeft dit inloggen op VDI/TS|RDS omgeving geblokkeerd, bij andere heeft dit de servers blue screen na herstart bezorgd en nog ook veel problemen die ik ook op lokale pc van gebruiker heb gezien.
Wil je toch automatische updates gebruiken dan vind ik het zeer belangrijk om een recovery scenario klaar te hebben liggen. De oplossing die je hiervoor gebruik dient geschikt te zijn voor herstellen van verschillende diensten en/of onderdelen van je systeem.
Tegenwoordig zijn de meeste servers gevirtualiseerd. Door een snapshot van je systeem maken kun je de kans op ellende na automatische updates zeer kleiner maken. Voorwaarde hiervan is dat je de procedure hiervan al goed doorgetest hebt.