Hacker: Full-disclosure goed voor eindgebruiker
Het openbaar maken van beveiligingslekken is het beste voor gebruikers en bedrijven, ook al heeft een leverancier geen patch ontwikkeld. Dat zegt H.D. Moore, de geestelijk vader van hackertoolkit Metasploit. Recentelijk hebben verschillende partijen nieuw beleid voor het publiek maken van kwetsbaarheden aangekondigd. Zo vindt Google dat lekken binnen zestig dagen moeten zijn opgelost, terwijl Microsoft voor "coordinated vulnerability disclosure" pleit. Tippingpoint hanteert voortaan een deadline van zes maanden en Rapid7, het bedrijf waar Moore voor werkt, heeft een constructie waarbij bedrijven zestig dagen de tijd krijgen.
In veel gevallen zetten bedrijven die onveilige software maken onderzoekers onder druk om informatie over een lek niet te publiceren. Rapid7 waarschuwt vijftien dagen nadat de leverancier is ingelicht het Computer Emergency Response Team (CERT), dat een deadline van 45 dagen aanhoudt. Volgens sommige bedrijven is het onverantwoord om een kwetsbaarheid te openbaren waar nog geen patch voor is. Eindgebruikers zouden daardoor onnodig risico lopen en worden opgezadeld met de verantwoordelijkheid die eigenlijk de leverancier moet dragen.
Verantwoordelijkheid
"Dit argument gaat ervan uit dat de onderzoeker en leverancier de enige mensen zijn die van een bepaald lek afweten. Keer op keer zien we gevallen waarbij een lek in het wild wordt ontdekt, maar al was gerapporteerd door een onderzoeker die met een leverancier wilde samenwerken", aldus Moore. "Wat één onderzoeker ontdekt, kan een andere onderzoeker met minder goedaardige motieven ook vinden. De kern van het probleem is dat het product een lek heeft. Discussiëren over de juiste openbaarmaking neemt niets weg van het feit dat de leverancier inderdaad verantwoordelijk is voor iedereen die een probleem in hun product misbruikt."
Voordelen
Moore ziet dan ook grote voordelen in het openbaren van beveiligingslekken. "Hoe meer eindgebruikers van een probleem afweten, hoe beter ze zich er tegen kunnen beschermen." Vanwege het grote aantal zero-day lekken die rondgaan, zouden de meeste bedrijven inmiddels wel weten hoe ze zich zonder patch moeten redden.
"Je kunt ervan uitgaan dat deze gebruikers een patch van de leverancier eisen en dat de leverancier zijn best doet om hieraan tegemoet te komen. Samengevat, het openbaren van een lek resulteert altijd in het zo snel als mogelijk verschijnen van een patch."
Tuurlijk. Mijn schoonmoeder van 76 volgt security.nl en andere community's om vervolgens via ssh haar router te tunen...
Dit argument is alleen leuk voor de tech savvy beheerders. 95% van de thuisgebruikers heeft geen idee waar het over gaat.
In de tussentijd worden andere creatieve geesten op een idee gebracht om snel even een exploit te maken voordat de vendor met een patch komt (die weinigen zullen installeren).
H.D. doet briljante dingen, maar hier ben ik het toch echt niet met hem eens.
als je niet weet wat de risico's zijn hoe kun je dan beschermen/beveiligen?
auto's kunnen tegenwoordig ook worden opgebroken (op afstand en zonder schade) maar als niemand mij vertelt hoe dit kan en hoe dit werkt, weet ik niet dat ik me daar tegen moet beschermen. Doordat ik op de hoogte ben van de werking wordt het voor mij makkelijker om te daar tegen te beschermen.
Het kan maar zo zijn dat het zelfde lek door iemand anders is gevonden die er in "the wild" gewoon al maanden misbruik aan het maken is, hoe wil jij je hier tegen beschermen als je dit niet weet?
Moore ziet dan ook grote voordelen in het openbaren van beveiligingslekken. "Hoe meer eindgebruikers van een probleem afweten, hoe beter ze zich er tegen kunnen beschermen." Vanwege het grote aantal zero-day lekken die rondgaan, zouden de meeste bedrijven inmiddels wel weten hoe ze zich zonder patch moeten redden.
Vaak ben ik het wel met Moore eens, maar deze keer niet. Het overgrote deel van de gebruikers hebben absoluut geen idee hoe zich tegen dergelijke zaken moeten beschermen. Dus zullen zij zich niet beschermen. Dus slaat egeltje de spijker op zijn kop.
Je hebt namelijk niets aan informatie dat iets onveilig is, maar waar mee je verders niets kan doen.
"responsible disclosure" is marketing praat voor 'geef ons de tijd, vertrouw ons, wij weten wat goed voor je is'...
Nou, keer op keer laten bedrijven zien dat we hen niet kunnen vertrouwen en dat we met een kluitje in het riet gestuurd worden.
Gewoon openbaar maken die lekken. Laat ze maar leren veilig programmeren (waarom zouden ze, immers, lekken plakken ze toch 1 keer in de maand waarbij de lekken niet bij uitzondering meer dan 3/4 jaar bekend zijn), stoppen van recyclen van oude NOG BRAKKERE code...
Sterker nog, ik vind dat het een wettelijke verplichting moet worden om lekken binnen 60 dagen te fixen.
Maar als je alles openbaart hebben meer criminelen dan thuisgebruikers er profijt van.
Thuis gebruiker kan vandaag de dag al niet meer bijhouden wat er allemaal kan met computers ze willen het alleen gebruiken.
Dan alle lekker openbaar maken zal voor de vader van Metasploit veel geld opleveren.
Het Gevolg en nadeel ervan is mij te risicovol tegenover dat ik de info kan krijgen.
Al vindt ik wel dat er een onafhankelijke instantie moet komen die acces op deze dingen heeft en een Rapport kan maken over de voortgang zodat we weten dat commerciele Vendors hun werk doen in plaats van onopgeloste problemen rond laten liggen.
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.
