Heb je ook soms het gevoel dat je stilaan omsingeld wordt door updates en patches? Voortdurend zie je op je pc, op je smartphone, ja zelfs op je digitale televisie pop-up schermen die je aanmanen om zo snel mogelijk de voorgestelde update te installeren. Soms verbeteren die echt voelbaar je digitale leven, maar minstens even vaak betreft het security patches die enkel moeten voorkomen dat een ontdekt lek zou worden misbruikt door de eerste de beste hacker. Noodzakelijk, maar je wordt er niet meteen vrolijker van.
Als security manager of it-manager is het aantal patches dat je wordt aangereikt natuurlijk nog vele malen hoger. Zo hoog dat alle patches doorvoeren gewoonweg onwerkbaar wordt. Enerzijds heb je dan geen tijd meer voor andere taken en anderzijds loop je altijd het risico dat een update iets wat perfect werkte toch stuk maakt.
Een digitale infrastructuur beveiligen is sowieso een afweging van risico’s want 100 procent beveiliging bestaat niet en 99 procent is onbetaalbaar. Maar hoe bepaal je welke risico’s je bereid bent te nemen en welke je absoluut wil vermijden? Toegepast op het onhoudbaar aantal patches: alles patchen is onmogelijk, maar hoe bepaal je wat wel en wat niet?
Natuurlijk bestaan er security sites die je willen helpen bij het selecteren van de belangrijkste patches. Het zogeheten common vulnerability scoring system (kortweg cvss) bijvoorbeeld is een open industriestandaard voor het bepalen van de ernst van een vastgesteld lek. Perfect, denk je dan, laten we dit als leidraad gebruiken. Maar er is slechts één probleem mee: hier worden zo veel lekken als uiterst ‘critical’ beschouwd dat je nog geen stap vooruit bent.
Patches en hun prioriteit
Gelukkig bestaan er nog andere oplossingen, die je kwetsbaarheden scannen, in kaart brengen en dan via ingebouwde intelligentie online gaan checken welke lekken het populairst zijn bij hackers. En met online bedoelen we natuurlijk het dark web, want op basis van informatie die je kan vinden op hackersforums en andere voor de leek minder gekende informatiebronnen kan je wel degelijk weten welke kwetsbaarheden met grote waarschijnlijkheid zullen misbruikt worden. Op basis van die gecombineerde informatie heb je al een beter zicht op welke patches het dringendst nodig zijn.
Moeten we dan maar alles overlaten aan dergelijke oplossingen, en hopen dat ze de werking van onze systemen niet al te vaak verstoren, alles om de gemoedsrust te bewaren? Niet noodzakelijk. Ik raad organisaties aan om hun eigen patchritme aan te houden, aangezien dat meestal voor hun onderneming het beste compromis is tussen veiligheid en werkbaarheid. Maar als een nieuwe WannaCry zich aandient, een ernstige bedreiging die gebruik maakt van een algemeen voorkomend lek, dan is het toch wel raadzaam om even van dat ritme af te wijken.
Zelfs in dit tijdperk van security by design hoeven we niet meteen te verwachten dat het aantal lekken en patches zal afnemen. Systemen die ons helpen bij het ontdekken en inschatten van risico’s zullen dus ook steeds meer een noodzaak worden in plaats van een aangenaam extraatje. Wie zich vandaag al vertrouwd maakt met dergelijke systemen is in elk geval beter gewapend voor die toekomst.
Peter Beerten, business developer managed services bij SecureLink België
Reacties
Ze zongen het al zo lang geleden.
7 meiden op blote voeten.
Een school verder, het stedelijk gymnasium, daar zaten ze.
Al voelde ik al van alles in mijn Dingedong, mijn bloedhekel aan dat liedje nooit over gegaan.
Wat ik wou zeggen. Ze zongen "Alles heeft een ritme."
Neem de tijd voor alle dingen.
Alles kun je laten swingen.
Maar goed, dus ook patches. Blijkbaar.
Toch moet je er soms van afwijken, lezen we.
Bij WannaCry bijvoorbeeeld.
En van security by design hoeven we ook niet veel van te verwachten.
Nou, een fijne pasen met veel patchplezier !
Misschien moet deze bal worden terug gelegd bij de software leveranciers. Ik ken namelijk niet zo heel veel van deze leveranciers die hun test process en de daarmee gepaard gaande beveiligingstesten goed uitvoeren. Het is veel te vaak een kwestie van snel iets op de markt plempen en we zien achteraf wel of er iets nodig is aan beveiliging. Met als gevolg dat je inderdaad de ene patch na de andere krijgt. Dan hebben we het ook nog niet over de kosten die bedrijven eigenlijk zelf maken om die patches steeds te testen en te plaatsen in de productie-omgeving. Misschien moeten die eens neergelegd worden bij de software leveranciers. Ik denk dan dat er heel veel zal veranderen, want software makers geven daar liever geen geld aan uit.
@Hans ... ik denk dat je daar een terecht, maar ook gevoelig punt raakt. Het "als eerste op de markt zijn" weegt tegenwoordig zeer zwaar mee in de keuze om een product al dan niet op de markt te zetten.
Bij een product zoals een app is het relatief eenvoudig en goedkoop om een update/patch uit te brengen, waardoor dit risico makkelijk genomen wordt.
In het geval van, bijvoorbeeld, embedded software ligt dit een stuk moeilijker, denk aan terugroep acties van hele series auto's.
Nu ik dit schrijf bedenk ik me .... wel typisch dat een terugroepactie van bijvoorbeeld automerk X altijd breeduit bemeten wordt in de krant maar dat je zelden of nooit iets leest over de zoveelste patch of app Y......
Schot in de roos, de updateritis van vandaag geeft te denken.
Vroeger, lang lang geleden toen computers nog duur waren kreeg je 1 keer in 3 jaar een grote update en zelden patches, je had ook geen internet.
Ik weet niet of het aan mij ligt maar onder voortgang versta ik wat anders, het voelt als insucurity by design.
Het meest ergerlijk zijn "patches" die PC's met eenvoudige zakelijke toepassingen voor hele kleine bedrijfjes lam leggen omdat de leverancier van OS - DB - een of ander Platform niet getest heeft op terugwerkende kompatibiliteit bijv met MySQL. Alles een enorme verkwisting van manuren.
Ik heb heimwee naar VMS.
Ik heb nog grotere heimwee naar (IBM) MVS en mainframes; die PC , een Personal Computer, gebaseerd op de X386 hardware architectuur is het beginpunt van de klachten. Daarop volgend een niet standvastig gebruik van de interruptstructuur van die X386 en toen ook nog ongebreideld data in de inputkanalen proppen, weet je nog 'buffer overflow' ; alleen de zgn fishing aanvallen vallen niet in dit commentaar daarvoor is de ontvangen van (email)berichten zelf verantwoordelijk, maar de kwetsbaarheid van welke SQL database dan ook voor "vuile" sql-aanvragen lijkt mij ook een buffer en vooral een test probleem;
met het (IBM) SNA protocol en de reeds lang geleden ge-killde gestandaardiseerde netwerkprotocollen van DATANET waar je na een zeker aantal "push"-datablokken moest wachten op acknowledgement voor (goede) ontvangst was meer veiligheid te bouwen dan met TCP/IP hoe goed dat nu dan ook is;
maar heimwee helpt niet : in videoland heeft VHS ook gewonnen van Betamax en Philips' V2000, nu is alle video techniek digitaal, ook analoge techniek verliest zijn waarde op allerlei andere terreinen: we moeten door met X386 en de PC, maar een computersysteem met X386 techniek als server is geen PC meer, dus................
we blijven helaas verplicht de nieuwe software versies met de lading patches die volgen te aanvaarden als 'a fact of life'
Wen er maar aan want het gaat alleen nog maar erger worden. In de game industrie is early-acces vrij normaal en het begint ook steeds meer de zakelijke markt binnen te sluipen.
Inmiddels is er een hele markt ontstaan voor 0days en andere exploits waarbij het enige verweer het zo snel mogelijk patchen van gevonden lekken is. Een ander aspect is dat op het gebied van versleuteling een hele grote zwakke plek zit wat lastiger aan te pakken is omdat inlichtendiensten vaak een afweging maken tussen veiligheid en toegankelijkheid die in het nadeel van de gebruikers beslecht wordt.
De pijn van updaten zit em in de manier waarop bij sommigen devices / OSes updates gaan: met risico en veel tijd gepaard. Zorg voor een echte quality control en een vol automatische update procedure die daardoor nagenoeg zonder risico is en geen down time oplevert (van reboots en patches die pulled worden oid) en de pijn is weg. Dat kan en dat ervaar ik dagelijks op mijn RHEL machines.
Ja SWA, daarom draai ik ook al heel lang Linux op mijn Desktop/Server, en weet je wat?
Bij Kubuntu 16.04 (KDE Plasma 5.8.9) krijg ik inmiddels iedere dag of iedere 2e dag een rij updates.
Over 2 jaar stap ik misschien over naar een andere Distro, ook al verhelpt dat de updateritis niet.
Ik heb nog grotere heimwee naar (IBM) MVS en mainframes; die PC , een Personal Computer, gebaseerd op de X386 hardware architectuur is het beginpunt van de klachten. Daarop volgend een niet standvastig gebruik van de interruptstructuur van die X386 en toen ook nog ongebreideld data in de inputkanalen proppen, weet je nog 'buffer overflow' ; alleen de zgn fishing aanvallen vallen niet in dit commentaar daarvoor is de ontvangen van (email)berichten zelf verantwoordelijk, maar de kwetsbaarheid van welke SQL database dan ook voor "vuile" sql-aanvragen lijkt mij ook een buffer en vooral een test probleem;
met het (IBM) SNA protocol en de reeds lang geleden ge-killde gestandaardiseerde netwerkprotocollen van DATANET waar je na een zeker aantal "push"-datablokken moest wachten op acknowledgement voor (goede) ontvangst was meer veiligheid te bouwen dan met TCP/IP hoe goed dat nu dan ook is;
maar heimwee helpt niet : in videoland heeft VHS ook gewonnen van Betamax en Philips' V2000, nu is alle video techniek digitaal, ook analoge techniek verliest zijn waarde op allerlei andere terreinen: we moeten door met X386 en de PC, maar een computersysteem met X386 techniek als server is geen PC meer, dus................
we blijven helaas verplicht de nieuwe software versies met de lading patches die volgen te aanvaarden als 'a fact of life'
Jouw reactie
LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren