Managed hosting door True

Beveiligingsgat: roepen of zwijgen?

Belangen van leveranciers, beheerders en gebruikers botsen

 

In security-land woedt al jaren een felle discussie over het wel of niet onthullen van beveiligingsgaten. Het huidige dns-gat is stilgehouden tot er patches waren. De hacker die claimt via Intel-chips pc’s te kunnen kraken, heeft Intel nog niets verteld.

De security-wereld kent vele conflicten, maar de meest fundamentele is wel die over het wel of niet onthullen van beveiligingsgaten. Het gaat om het wereldkundig maken van zowel het bestaan van een gat als informatie daarover. Openbaar maken dient volgens de voorstanders als waarschuwing voor beheerders en stelt hun in staat een gat af te dekken. De tegenstanders stellen juist dat de mededeling vooral nut heeft voor crackers die dan een gat (beter of eerder) kunnen misbruiken. De Computable-experts reageren.

Toezicht nodig

Bernhard van der Feen, product solution manager security bij Microsoft, ziet wel wat in beide kanten van de discussie. "Tja, een eeuwigdurende discussie en beide kampen hebben gelijk. De leverancier heeft zonder publicatie minder behoefte om snel patches te leveren, maar het ongenuanceerd publiceren vergroot het risico op misbruik van een probleem. Dat geeft maar weer aan dat we een toezichthouder moeten hebben waar de meldingen worden gedaan en die op straffe van boetes toeziet op snelle oplossing."

Hij ziet een rol voor de overheid, liefst boven het landsniveau: "Ik denk dat Eurocommissaris Neelie Kroes die kar wel wil trekken. En het probleem van wie er dan bij open source verantwoordelijk is? Dat is simpel, het bedrijf dat verdient bij keuze van de software moet betalen - en bij open source is dat... de klant."

Niet onder de pet houden

Sinclair Koelemij, operations teamleader voor network solutions and security services bij Honeywell Process Solutions, zegt beslist: "Het bekende ‘onder de pet houden' is geen oplossing." Hij licht toe: "Ten eerste zijn er wettelijke beperkingen, Amerikaanse bedrijven hebben bijvoorbeeld de plicht de hun bekende problemen te publiceren. Ook de Nederlandse rechter heeft recent in het geval van de OV chipkaart problemen de zijde van de onderzoekers gekozen en de leverancier die publicatie van de hack techniek wilde voorkomen in het ongelijk gesteld."

René Visser, Senior Consultant en Docent Oversite en Haagse Hogeschool, is ook voorstander van onthulling. "Het is vanuit verschillende perspectieven noodzakelijk dat kwetsbaarheden gemeld worden door zowel een leverancier als de 'test/hacker'-gemeenschap."

Hij wijst echter ook op een andere verantwoordelijke partij: de ondernemer, de eindgebruiker. "Die is vanuit verschillende wetgevingen verantwoordelijk voor goed ondernemerschap en zijn eigen eindproduct. Als bank, telco of energieleverancier heb je zelfs een leveringsplicht, dus dienen bepaalde diensten beschikbaar te blijven. Bij het inzetten van middelen zou ik dus als ondernemer (risico manager of security specialist) willen weten wat het risico is (bij inzet van een product) en waar de zwakheden (beperkingen) zitten. Dit alleen al om indien nodig tegenmaatregelen te introduceren."

Onwil leveranciers

Koelemij reageert dat er vaak al wel tijd is voor tegenmaatregelen: "Het is op dit ogenblik al zo dat de onderzoeksfirma's de leveranciers van software en hardware een beperkte tijd geven om te reageren voordat ze de problematiek openbaar maken." Een probleem volgens hem is dat leveranciers nogal eens terughoudend zijn vanwege de kosten voor het doorvoeren van de benodigde verbeteringen. "Publicatie is dan een goede stimulans. Intel zou niet blij zijn met het imago dat Motorola-chips beter zijn. Hetgeen natuurlijk niet zo is, elke chip heeft zijn problemen het is een kwestie van focus of ze wel of niet ontdekt worden."

Volgens Visser is er nóg een argument voor het bekend maken van gaten: er zijn bugs die al jaren bij leveranciers bekend zijn, maar die niet opgelost worden. "Het zelfregulerende karakter van het eerst bekend maken bij de leverancier en die dan de tijd geven om orde op zaken te stellen, werkt dus niet." Hij beschuldigt de leveranciers er ook van dat ze om kostenredenen de kwaliteit laag houden en hun producten slechts minimaal testen.

Drempel en reikwijdte

Koelemij legt uit dat niet het bestaan van een lek belangrijk is, maar het gemak waarmee het te misbruiken is in combinatie met de reikwijdte. Het gaat dus om de hoogte van de drempel in relatie tot de beoogde buit."

Over de geclaimde kraakmogelijkheid via Intel-processoren is hij wel bezorgd: "Het nieuwe hier zou zijn dat er malware ontwikkeld is, of kan worden, die besturingssysteemonafhankelijk is. Dit verplaatst de beveiligingsproblematiek naar de bios-ontwikkelaars en de chipfabrikanten. Met de toenemende afhankelijkheid van ict is beveiliging een primaire taak geworden voor alle bedrijven en dat wordt helaas nogal eens over het hoofd gezien."

Lokaal misbruik

Erik Westhovens

Erik Westhovens van DeltaISIS merkt op dat hackers al makkelijke middelen hebben.

Cio Erik Westhovens van DeltaISIS is ook voorstander van het openbaar maken van beveiligingsgaten. Volgens hem valt het gevaar van de bugs in Intel-chips wel mee. Hij erkent wel dat bugs in processoren zijn te misbruiken, maar stelt dat dat toch lokaal moet gebeuren. "In kleine kring is bekend dat er een klein aantal bugs in de Intel processoren zitten die inderdaad kunnen leiden tot aanvallen van buitenaf. Voor het gemak word daar het probleem neergelegd. Maar een potentiële hacker moet dan wel eerst toegang tot de pc krijgen en dan zijn exploit voor de ‘errata' kunnen runnen."

De hedendaagse cracker heeft echter makkelijkere middelen tot zijn beschikking. "Vele malen gemakkelijker is het, en dan maar meteen een bug blootleggend, gebruik te maken van root kits. Met behulp van atsiv (inmiddels ook al verouderd) loop je redelijk gemakkelijk door alle beveiliging heen. Atsiv word door virusscanners wel gevonden, maar ook dat is vrij simpel te omzeilen."

Besloten onthulling

Westhovens bekijkt beide kanten van de disclosure-discussie: "Ja, maak alle beveiligingsissues bekend. Daarmee geef je hackers op een korte termijn veel informatie, maar na een kleine week is dat opgelost en werkt het niet meer. Nee, maak beveiligingsissues niet bekend. Probleem is dan dat veel mensen onbewust niet de juiste maatregelen treffen."

Hij lijkt dus vóór openbaarmaking te zijn, maar komt nog met een nuance: "Er moet een gesloten circuit komen van beveiligingsexperts die de informatie krijgen en daarmee aan de slag gaan. Zodra er dan een oplossing is, is er ruimschoots tijd om juiste maatregelen te treffen."

Koelemij van Honeywell Process Solutions ziet hier geen brood in. "Ik zou niet zo goed weten wie er in dat "gesloten circuit van beveiligingsexperts" plaats moeten nemen. Wie zou buitengesloten moeten (en kunnen) worden? Zou Frankrijk accepteren dat de VS beveiligingsproblematiek voor zich houdt? Zou de Rabobank voor zijn beveiliging afhankelijk willen zijn van de ING? Een raffinaderij afhankelijk van de beveiligingsexperts van een bank? Op het gebied van terrorisme bestaat deze uitwisseling ook tussen veiligheidsdiensten, maar dat is wel een clubje van vriendjes met de nodige wederzijdse scepsis."

Status quo

Al met al ziet hij meer in de huidige ‘beveiligingswedloop' dan in Westhovens suggestie van besloten onthulling aan een selecte groep beveiligingsexperts. "Zo'n clubje leidt tot veel meer problemen dan het mee blijven rennen in deze ‘rat race' van onderzoek, publicaties, en betaalde bescherming. Dat is een economische cyclus die alleen te doorbreken is door de perfect beveiligde oplossing te ontwikkelen, helaas is dit een beveiligingsdoel dat we nooit bereiken."

Ook Visser van de Haagse Hogeschool is kritisch over besloten onthulling binnen een select gezelschap. "Juridisch gezien is het heel raar dat bedreigingen dan gedeeltelijk of bij een beperkte groep bekend zijn. Zit ik niet in de groep, dan weet ik niets en kan ik dus ook het risico niet beheersen. Terwijl ik wettelijk wel aansprakelijk kan zijn. Verder zal ik de schade die is ontstaan door het gebruik van ondeugdelijke apparatuur (waarvan mij de beperkingen niet zijn gemeld) ook willen verhalen."

‘Maak het ze niet te makkelijk’

Lex Borger, principal consultant bij Logica, neigt naar stilhouden: "Onmiddelijke onthulling van alle details van een nieuwe kwetsbaarheid is niet goed voor de algemene veiligheid. Zelfs onthulling achteraf via documentatie bij de patch is niet aan te raden. Hackers hebben soms slechts uren nodig om een exploit te maken, maak het ze nou niet té makkelijk."

Hij erkent de geconstateerde terughoudendheid van leveranciers. "Onthulling is wel het ultieme machtsmiddel van de ontdekker van de kwetsbaarheid. Als de softwareproducent geen acceptabele oplossing levert in een redelijke tijd, kan de ontdekker overgaan tot onthulling. Zo wordt de softwareproducent gehouden aan een eerlijke marktafweging. Dit is essentieel voor het veilig houden van de software in de markt."

De trend dat er vaker vroeg wordt onthuld, vind Borger een zorgelijke ontwikkeling. "Kennelijk grijpen ontdekkers nu echter vaker en sneller naar dit machtsmiddel. Is de pendule te ver doorgezwaaid? Het zou daarom helpen als er goede richtlijnen afgesproken worden over het proces naar zo'n onthulling toe. Dan kan de markt de ontdekker eventueel aanspreken op zijn verantwoordelijkheid."

Wel stilgehouden

De voorzichtig voorgestelde beperkte onthulling, aan betrokken partijen, is precies wat er is gebeurd met het nu onthulde gat in het dns-protocol (domain name system). Dat lek is in januari al ontdekt, maar stilgehouden tot alle grote ict-leveranciers hun zaakjes op orde hadden. Alleen waren de betrokkenen bij het gat in dat internet-basisprotocol er al vrij snel van overtuigd dat ze actie moesten ondernemen. Dit vertelt ontdekker Dan Kaminsky, die de onthulling pas in juli deed en toen nog in vage bewoordingen. Later kwam hij met meer details, nadat er onbedoeld al informatie over het gat was uitgelekt door een Amerikaans beveiligingsbedrijf.

Niet stilgehouden

Aan de andere kant van het disclosure-conflict bevindt zich bijvoorbeeld hacker Kris Kaspersky (geen relatie met de gelijknamige antivirusleverancier). Die beveiligingsonderzoeker kwam laatst in het nieuws met claims dat hij pc's kan kraken middels fouten in Intel-processoren. Hij wil dit in oktober demonstreren op een beveiligingsconferentie. Chipproducent Intel was echter bij de aankondiging niet op de hoogte gebracht van Kaspersky's bevindingen.

Nederland

Ook in Nederland speelt de security-discussie over publiceren of stilhouden. De onderzoekers van de Radboud Universiteit die gaan publiceren over het kraken van de ov-chipkaart, werden bedreigd met een publicatieverbod. Chipproducent NXP, de voormalige halfgeleiderdivisie van Philips, spande een kort geding aan. Publicatie van de kraakmethode voor de Mifare Classic rfid-chip zou namelijk een groot beveiligingsrisico zijn, aldus NXP. De chip dient ook voor toegangspassen van de Rijksoverheid. Overigens hebben de onderzoekers al sinds maart bewust geen details over de zwakke plek onthuld. Dit om belanghebbenden, zoals NXP maar ook de NS en de Nederlandse overheid, tijd te geven voor beschermende maatregelen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2657306). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

Mijn mening hierover:

1. Direct de fabrikant van het product op de hoogte stellen en met "open source codesample" meesturen wat het gebrek aantoont! Dan ben je meteen van het welles-nietes spelletje af!
Des te eerder word de fabrikant gemotiveerd om zijn product goed en (weer) waterdicht te maken.

2. Weigert de fabrikant dit lek te dichten, meteen de exploit openbaar maken. Wie weet geeft dit anderen - die er wel belang bij hebben - wel de gelegenheid, om het lek te dichten.

Vroeg of laat komt een exploit toch aan het licht ;-)
Dan kun je er maar beter als de kippen bij zijn.

En zeker geen doofpot gaan vormen, het lijk wel spioneren mogelijk maken!

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×