Minister Opstelten van Veiligheid en Justitie wil niet dat bedrijven en organisaties aangifte doen tegen hackers met goede bedoelingen, die veiligheidsproblemen aankaarten, las ik bij Tweakers. In een brief aan de Tweede Kamer beschrijft hij dat het ‘de voorkeur’ heeft dat een bedrijf beleid ontwikkelt voor responsible disclosure en daarin verklaart geen aangifte te zullen doen als mensen conform dat beleid bugs op verantwoorde wijze komen melden. Creatief!
Om bedrijven te helpen zulk beleid te maken, heeft het NCSC een Leidraad om te komen tot een praktijk van Responsible Disclosure opgesteld. Deze beschrijft in voor mij heldere taal wat kwetsbaarheden zijn, waarom je meldingen daarvan via responsible disclosure wilt opvangen en hoe zo’n proces eruit moet zien.
Het proces is eigenlijk vrij simpel:
- De organisatie stelt een meldpunt op voor meldingen over kwetsbaarheden, en alloceert ook capaciteit om meldingen op te vangen en door te leiden naar de verantwoordelijke afdeling.
- Ontvangst van een melding wordt digitaal bevestigd, waarna organisatie en melder gaan overleggen over de verdere afhandeling.
- In dat overleg wordt een termijn afgesproken waarna de melder de kwetsbaarheid openbaar mag maken, bij voorkeur 60 dagen als het gaat om software en zes maanden bij hardware. (Want hardwarelekken zijn niet zo simpel te fixen.)
- Bij een niet of moeilijk op te lossen kwetsbaarheid (of bij hoge kosten) kan worden afgesproken geen disclosure te doen. Ik had graag gezien dat daar “in zeer uitzonderlijke gevallen” komt te staan, want de standaardzin van bedrijfsjuristen bij meldingen wordt nu “Vanwege de hoge kosten en het zeer moeilijk op te lossen karakter van deze kwetsbaarheid is het u verboden hiervan publicatie te doen.”
- De organisatie houdt de melder op de hoogte van de voortgang.
- De organisatie kan desgewenst de melder credits geven in het persbericht dat de fout gefixt is (of in de patch.)
- De organisatie kan een beloning of waardering geven voor een melding, mits men zich aan de spelregels houdt.
- De organisatie belooft in het beleid geen juridische stappen te nemen tegen de melder indien conform het beleid wordt gehandeld.
En ja, zo’n belofte is juridisch bindend, je kunt een bedrijf daarmee om de oren slaan als ze alsnog aangifte gaan doen of een kort geding tegen publicatie beginnen.
Wat houden die “conform het beleid”-spelregels nu in?
Allereerst moet de melder de melding doen bij de organisatie zelf, en wel op een vertrouwelijke manier. Ook moet dat zo snel mogelijk na ontdekking. En hij publiceert pas conform de afspraken hierboven.
Belangrijke vuistregel voor de melder is “niet op onevenredige wijze te handelen”. Zo is social engineering categorisch uitgesloten – we wéten immers al dat mensen eenvoudig te hacken zijn. Ook brute forcen mag niet (hoi Nieuwe Revu) want dat gaat niet over kwetsbaarheden.
Meer specifiek mag er niet meer worden gedaan dan strikt nodig om de kwetsbaarheid aan te tonen. Je mag bijvoorbeeld geen backdoors installeren, of gegevens aanpassen, kopiëren of verwijderen. Wil je bewijzen dat je van alles kunt lezen, lees dan een directory; wil je bewijzen dat je kunt schrijven, maak dan een nieuw leeg bestand aan. En toegang delen met je vrienden mag ook niet.
Hoewel ik hierboven een tikje cynisch klink soms, moet ik zeggen dat ik het een mooi initiatief vind. En de regels klinken ook logisch en werkbaar voor een bona fide organisatie. Natuurlijk is er ruimte voor misbruik of te kwader trouw inzetten van de regels, maar het is een hele verbetering ten opzichte van het grijze gebied dat er nu is.
Ik denk dat wij een (gratis) generator gaan bouwen voor RD-beleid. Wat zou er volgens jullie zeker in moeten? Missen jullie nog dingen?
Arnoud
” wil je bewijzen dat je kunt schrijven, maak dan een nieuw leeg bestand aan” Eens echter als het om een simpele kwetsbaarheid gaat als een sql injectie dan zou je ook het aanpassen van 1 record moeten toestaan. (want schrijven op disc is natuurlijk niet altijd mogelijk bij een hack) Niet destructief, maar bijvoorbeeld aan je eigen gegevens een extra spatie of een letter toevoegen. Of een overduidelijk fake record toevoegen, zolang het maar niet destructief is en duidelijk voor de gehackte partij wat het gevaar is.
Brenno de Winter heeft er een iets andere kijk op:
http://www.hpdetijd.nl/2013-01-03/responsible-disclosure-richtlijn-is-onverantwoord-risico/
Intrigerend. Volgens mij is het niet zo eenduidig “lek kan niet gedicht = mond houden” maar dat stukje had wel iets meer pro-melder gekund.
Belangrijkste zorgpunt vind ik ondertussen wel dat je geen data mag kopiëren. Hoe bewijs je dan dat de hack werkelijk bestaat?
Ik vrees dat Brenno, terecht, vreest dat de RD-richtlijn meer ter bescherming van het bedrijfsleven is dan om de hacker een veilige gelegenheid te bieden het gevonden lek te melden.
In het stuk staat aangegeven dat je bv. met een directory listing kan bewijzen dat je toegang tot het systeem hebt gehad. Dat geeft voldoende geloofwaardigheid om voor het bedrijf een onderzoek te starten naar het lek, daarmee kan de kwestbaarheid bevestigd worden en als het goed is zal ook in de logs op de server inzichtelijk zijn dat er toegang is geweest.
Ik ben professioneel doemdenker. Een bedrijf kan in die situatie zeggen “Er is niks van waar, er is geen kwetsbaarheid, ga weg” en het gat heel provisorisch dichten. Als je dan naar de pers wil stappen (wat je goed recht is) dan moet je aan de journalist wel bewijs kunnen laten zien. Het is de vraag of je het dan nog gereproduceerd krijgt.
Verder zoals elders gemeld zijn niet alle fouten te vertalen naar “maak een directorylisting”. Als ik met een SQL kwetsbaarheid alle patiëntrecords kan listen, dan weet ik niet wat het equivalent is van “directorylisting”. De patiëntnamen zijn immers een stuk gevoeliger. Of, heel simpel, als ik andermans order kan opvragen door een ID aan te passen. Wat moet ik dan doen om safe te blijven?
Natuurlijk, maar het hele punt is dat je dit soort computervredebreuk juist wilt toestaan omdat het alleen maar nuttig is voor de maatschappij. Net zoals het toegestaan bij mij in te breken als je ziet dat er brand in mijn keuken is.
Een directory listing bewijst alleen maar dat er een directory listing mogelijk is. Elke zichzelf (niet) respecterende PR-medewerker zal dan keihard volhouden dat er wel een lijst van bestanden was maar dat de bestanden zelf prima beveiligd waren.
Na dat groene-hart-akkefietje is Brenno’s andere kijk ook heel begrijpelijk en in mijn ogen ook zeer terecht. “Nee meneer, uw informatie is hier volkomen veilig, wij beschermen onze digitale klokkenluiders”. Even later: “ja we hebben toch maar wel aangifte gedaan”. Hoezo bescherming? Het is veel verstandiger om te vertrouwen op de bronbescherming van een goede journalist.
Dat soort gedonder heeft ervoor gezorgd dat de overheid héél veel vertrouwen is kwijtgeraakt. Dat zal ze nu door jaren van consequent en consencieus gedrag terug moeten winnen (en met al die instanties die langs elkaar heen werken lijkt me dat eerlijk gezegd schier onmogelijk).
Vertrouwen komt te voet en gaat te paard.
Hoe moet ik dat zien ? Die aangifte zal (mogelijk) een strafrechtelijk gevolg hebben. Daar heeft een dergelijke belofte toch geen effect op ? Of zou je dan achteraf moeten proberen de schade te gaan verhalen op het bedrijf dat die belofte gedaan heeft ? Is er dan voldoende verband tussen het onafhankelijk door het OM te nemen besluit om te vervolgen en het schenden van die belofte ?
Dat verband lijkt me inderdaad te moeilijk. Wél kan ik een argument voorstellen dat je zegt, mij was beloofd dat dit oké was dus van onrechtmatigheid of wederrechtelijkheid is geen sprake en dus geen strafbaar gedrag.
Na een hoop gedonder oppakken vastzetten en pas na een half jaar door de rechter vrijgesproken?
Een bespottelijk korte termijn. Software onwikkelingtrajecten hebben meestal termijnen van 6 maanden tot een jaar. Snelle publicatie van informatie over software lekken leidt ofwel tot kwetsbaarheid bij burger omdat het lek niet tijdig gedicht kan worden of wel tot gehaaste patches die ook weer extra risico’s op fouten met zich meebrengen.
Je hebt het hier niet over een volledig ontwikkelingstraject, maar over aanpassen van een al opgeleverd product. Dan is 60 dagen geen onredelijke termijn.
Je bedoelt een bespottelijk lange termijn. Als mijn gegevens vrij toegangelijk zijn voor iedereen -want als de ‘ethische hacker’ erbij kan zijn er natuurlijk ook andere (misschien minder ethische) hackers die hetzelfde gat in de beveilinging gevonden hebben- wil ik dat de toegang nog het liefst dezelfde dag afgesloten word.
Een bedrijf dat zo’n beveiligingsgat langer dan 60 dagen open laat staan kan ik niet serieus meer nemen…
Dat is niet waar. 99% van de malware aanvallen die gebruik maken van een lek doen dat met een lek dat reeds bekend en vaak zelfs al geptachted is. Juist door de publiek gemaakt informatie op sites als megasploit worden malwarebouwer getriggerd om lekken te misbruiken.
Slecht in heel weinig gevallen komt het voor dat een zero day al wordt misbruikt voordat deze bekend is gemaakt door een security researcher of de patchend softwarebouwer. Ik geloof dat er voor alle Micrsoft producten bij elkaar elk jaar maar iets van gevaarlijk 1 of23 zero day lekken zijn die al actief misbruikt worden voordat iemand ze heeft gepubliceerd.
Het is vrijwel altijd zo dat misbruik van lekken pas onstaat na publicatie van die lekken en vaak ook pas na patchen van die lekken omdat er altijd partijen zijn (bijvoorbeeld met illegale versies van windows) die (automatische) patches niet doorvoeren of heel traag doorvoeren.
Consumenten hebben dus juist heel veel last van publicatie van lekken. Zeker als er nog geen patch voorbeschikbaar is.
In dat geval is er geen enkel excuus om 60 dagen te wachten. Het bedrijf kan het lek dan dezelfde dag nog dichten.
Hoe weet je dat? Het probleem is dat lieden met kwade bedoelingen dit juist niet aan de grote klok hangen (Ze hebben er immers alle belang bij het bestaan van het lek zo lang mogelijk geheim te houden). De kans is dus vrij groot dat lekken die gevonden worden door security researchers al lang bekend zijn in de ‘scene’.Wil je echt 60 dagen of meer wachten om een lek te dichten waarvan de kans groot is dat het al misbruikt wordt?
Ja, de kans dat een nog niet gepubliceerd ernstig lek misbruikt wordt is namelijk heel klein en als het al gebeurt dan is het misbruik ook nog heel beperkt omdat de bezitter van de zeroday detectie wil vermijden. De kans dat na publicatie een ernstig lek misbruikt wordt is bijna 100% . Bovendien is het misbruik dan meestal massaal om zoveel mogelijk ongepatchte machines zo snel mogelijk te infecteren.
Publicatie van een lek is dus juist bijna altijd de belangtrijkste trigger voor het misbruik van dat lek en is dus daarom altijd nadelig voor consumenten. Zeker publicatie van lek als er nog geen patch beschikbaar is. Publicatie van een software is vrijwel nooit goed te praten tenzij een softwarebedrijf botweg weigert een lek op te lossen.
@hAl:
Aanvallen tegen ongepubliceerde gaten worden dus vooral tegen systemen ingezet waar de aanvaller verwacht dat er een aanzienlijke buit valt te halen. (En de motivatie om de inbraak publiekelijk bekend te maken minimaal is.) Aanvallen tegen ongepubliceerde gaten worden ook nauwelijks gedetecteerd door de meeste detectiesystemen… Kortom, zoveel zinnigs is er niet te zeggen. Het potentieel voor aanzienlijke schade is er zeker!Aangezien steeds meer bedrijven via Agile methodes werken zou het repareren van een dergelijke melding binnen de eerstvolgende sprint opgepakt moeten worden. Aangezien een sprint twee tot drie weken duurt zou dat het probleem moeten oplossen. Eventueel komt er nog een tweede en desnoods een derde sprint bij indien het erg complex is, maar dergelijke meldingen horen een top prioriteit te hebben. Maar goed, er wordt gesproken over 60 dagen en ik zou eerder 45 werkdagen kiezen. Dat zijn precies drie sprints om het probleem op te lossen. Een mooi aantal. Maar goed, lang niet ieder bedrijf werkt op deze manier. De oude waterval-methodes zijn ook nog steeds erg populair maar is in deze gevallen niet flexibel genoeg.
Slechts een heel beperkt deel van bestaande applicaties zijn/worden agile ontwikkeld. Veelal bovendien in een project waarna het product aan een staande beheers organisatie wordt overgedragen die niet Agile werkt en die dan nog de bugs (en dus ook de lekken) moet oplossen. Die hebben vaak lijsten met tientallen of honderden bugs die opgelost moeten worden. Het is niet gezegd dat bugs die door derden zii gevonden de enige zijn of zelfs maar dat ze de meeste ernstige bugs zijn. Door publicatie van een lek wordt dat echter vrijwl zeker direct een aanvalsvector op een product en wordt een beheersorganisate gedowngen voorrang te geven aan de gepubliceerde lekken en niet niet noodzakelijk aan de meest ernstige bekende bugs die eingelijk de meeste prioriteit verdienen.
Voortijdige publicatie kan ook ernstig de capaciteit belasten omdat voor sommige vitale onderdelen van software uitgebreide testtrajecten ALTIJD vereist zijn om risico’s op schade bij klanten te voorkomen. Als dat testtraject toch al gepland stond voor een toekomstige release kan een patch inbouwen in die release misschine 100 uur werk zijn terwijl het dubbel doen van dat uitgebreide testtraject wel 1000 uur extra kan kosten. Uren van ervaren mensen die je vaak gewoon niet beschikbaar hebt op een zeer korte termijn.
Ja en nee. Of applicaties nou wel of niet Agile worden ontwikkelt maakt voor de ernst van de bug uiteindelijk niets uit. Je kunt je zelfs afvragen of een onschuldige bug waarmee de hacker geen privacy-gevoelige informatie kan benaderen en waarmee hij de boel niet kan saboteren eigenlijk wel ernstig genoeg is om direct te repareren. Dat is een afweging die ieder bedrijf zal moeten maken, maar die 60 dagen zorgen wel voor een stevige stok achter de deur. Stel voor dat WordPress een bug heeft waarmee je ook artikelen kunt lezen die nog niet gepubliceerd zijn. Aangezien Arnoud regelmatig van tevoren al wat artikelen schrijft zonder ze direct te publiceren betekent dit dat je nu al de posts van morgen en overmorgen zou kunnen lezen. Is dat ernstig genoeg om direct te repareren? Niet echt. Zou het een ramp zijn indien die bug nu bekend gemaakt wordt in mijn volgende post zodat iedereen hier al vooruit kan lezen? Lijkt mij niet. Zou het dan een probleem zijn als die hack bekend wordt? Niet echt, nee. Ja, Arnoud zou graag willen weten hoe die bug werkt zodat hij deze toegang tot toekomstige posts kan dichtgooien, maar het heeft geen prioriteit.
Dit is toe te passen op al dit soort bugs die door hackers gevonden worden. In diverse gevallen kan een bedrijf gewoon reageren met “Okay, niet ernstig. Maak maar bekend en we plaatsen het op de ToDo lijst.” Eventueel publiceert het bedrijf zelf het probleem, om gebruikers te waarschuwen dat ze met “CTRL-W” per ongeluk hun browser-tab dichtgooien of dat het invoeren van een bepaald woord het systeem doet crashen waarna ze opnieuw moeten opstarten. Per situatie moet je beoordelen of de ernst van de mogelijke schade of overlast ernstig genoeg is.
Je moet dan als bedrijf bepalen of publicatie van de bug ernstig genoeg is om direct maatregelen te nemen. Zo ja, dan is iedere dag dat de bug niet is gepatcht al een dag teveel en 60 dagen zou meer dan genoeg moeten zijn om het ontwikkel-team op volle kracht de bug te laten oplossen en een nieuwe patch op te leveren. Maar als een bug niet ernstig genoeg is om binnen 60 dagen op te lossen dan kun je je afvragen of publicatie van de bug wel ernstige complicaties kan opleveren. Maken 60 dagen dan veel uit? Zo ja, dan moet je toch terug naar de situatie waarin het team op volle kracht de bug gaat oplossen. Zoniet, dan maakt het weinig uit of de bug nu of over pas 60 dagen wordt gepubliceerd.
Maar Arnoud zou wel graag een uitstel willen van 60 dagen want hij wil vast niet dat iedereen nu al weet wat hij volgende week vrijdag gaat publiceren. 🙂
En nee, Arnoud. Ik heb geen lek in WordPress ontdekt. Ik zeg het maar even voor het geval je nu opeens super-nerveus wordt… 😉
Het grootste probleem is de uitzondering als een lek niet gemaakt kan worden vele bedrijven gaan nu proberen zich hier achter te schuilen. Ik denk zelf dat de minister ook daarbij gelijk had moeten zeggen dat bedrijven het product niet langer op publieke plaatsen mag gebruiken of in verbinding met internet mogen staan. Nu is het iemand die de fout netjes meld volgende keer iemand die geen goede bedoelingen heeft.
Het probleem waarvoor men hier een oplossing zoekt is dat hackers van het kaliber Henk Krol zelfs door de digibeten die bij onze politie werkt gepakt kunnen worden. Maar mensen die zo laagdrempelig bezig zijn gaan niet eerst in de paperassen duiken voordat ze gaan rondneuzen op de website van het Groene Hart Ziekenhuis.
Dat nog even afgezien van de onzin van het vooraf verbieden van sommige intrustion-technieken.
De minister mag terug naar Start en krijgt geen tweehonderd gulden.
Ethiek gaat over de opvattingen wat goed en fout is in het menselijk gedrag, en in de beroepsethiek gelden die normen voor een specifieke doelgroep. Dus als je niet weet wie de organisatie is, of je niet weet in hoeverre je iemand met je hulp iemand anders kan benadelen, moet je wel goed weten wanneer je de verantwoordelijkheid overneemt, meneer Opstelten.
Het is een hele stap vooruit dat de overheid zich achter een procedure voor “responsible disclosure” schaart. Jammer dat het allemaal heel vrijblijvend blijft, voor rechtszekerheid had ik graag gezien dat er een aantal harde uitspraken was gedaan: – Justitie zal hackers die zich aan de “responsible disclosure” richtlijnen houden niet vervolgen. – Uitlevering van hackers kan alleen plaatsvinden als bewezen is dat ze de “responsible disclosure” richtlijnen niet gevolgd hebben. – Wanneer een organisatie geen gepubliceerde contactprocedure heeft om veiligheidsproblemen te melden, dan geldt een contactpoging naar een willekeurig adres van de organisatie als “melding” voor justitie.
Verder mis ik nog een aantal punten: – Wat moet/mag een hacker doen als hij/zij niet binnen redelijke tijd (enkele werkdagen) een bevestiging van ontvangst van de melding krijgt. – Hoe gaan we conflicten over interpretatie van de richtlijnen oplossen? In een openbare rechtszaak? – Mag een organisatie software of systemen blijven verkopen (inzetten) als daar bekende veiligheidsgaten inzitten die niet verholpen gaan worden?
Over het laatste punt: het is redelijk om aan een hacker te vragen om zijn mond te houden over een veiligheidsissue wanneer het systeem waar de bug in zit toch al uitgefaseerd wordt. Maar ik denk dat de hacker de samenleving een dienst bewijst wanneer hij voorkomt dat een nieuw systeem, met “onfixbare” veiligheidsproblemen, in gebruik genomen wordt.
Absoluut mee oneens. Ook in een systeem dat uitgefaseerd wordt zullen lekken gemaakt moeten worden. Hoe lang mag een lek systeem volgens jou uitgefaseerd worden dan?
En als een systeem met onoplosbare beveiligingslekken in gebruik is genomen, dan moet het gewoon gemeld en buitengebruik gesteld worden. kost misschien wat geld, maar het is volkomen onacceptabel dat een onveilig systeem met privacy gevoelige gegevens in gebruik blijft.
Op het moment dat de beveiligingsfout aleen maar toestaat om bijvoorbeeld de hele database te wissen, maar de gegevens veilig zijn moet zo’n organisatie zelf weten wat ze doen. Als ze vanaf het moment dat het bekend is maar wel alle verantwoordelijkheid voor kosten op hun bord krijgen bij voortdurend gebruik.
En bij (semi) overheid, graag op kosten (privé) van de bestuurders.
@N.P.: Hoe lang mag een lek systeem volgens jou uitgefaseerd worden dan? Ik kan termijnen noemen, maar wat redelijk is hangt van de omstandigheden af. Op ben bereid om een organisatie 4 tot 6 maanden de tijd te geven om een softwaresysteem te vervangen en 12 tot 18 maanden voor een hardwaresysteem; dat is van melding tot voltooiing van de vervanging. 18 maanden is aan de korte kant waar het gaat om dingen die bij de consument staan, denk aan PIN-pas, OV-Chipkaart, de chip in het paspoort of (van ander kaliber) WiFi routers, kabel- en ADSL-modems.
[Mieke van der Weij-modus] “Responsible disclosure”? Waarom moet dat nou weer in het Engels? Verantwoordelijke onthulling? Verantwoord blootleggen, signaleren? [/Mieke van der Weij-modus]
Een betere term dan “responsible disclosure” zou wel mooi zijn, maar ik weet er geen die ook nog soepel van de tong loopt. Ethisch verantwoord lekken? Lek-klokkenluiden?
“Verantwoordelijk klokkenluiden”? 🙂
+1
Waarom niet gewoon “klokkeluiden”. Desnoods digitale klokkeluider, internetklokkenluider of (hoi apple) iKlokkeluider.
Ik vraag me toch af wat de impact is van dit voorstel.
Houdt dit in dat aangifte doen tegen hackers die niet succesvol zijn geweest nu per definitie zinloos is (voor zover deze in de praktijk al zinvol waren)? Immers elke betrapte hacker zal zeggen dat hij opzoek was naar een kwetsbaarheid en dat het echt zijn bedoeling was dit volgens de responsible disclosure kenbaar te maken?
Of, stel dat iemand mij een mail stuurt dat hij morgen de beveiliging van mijn systeem gaat checken en dit netjes zal melden als hij want kan vinden, moet ik dit dan maar goed vinden omdat hij een “ethical hacker” is? Ok; deze heb ik nooit meegemaakt. Maar toch. Ik vind het maar een rare richtlijn. Het wekt bij mij de indruk dat iets wat we eerder strafbaar hebben verklaar nu weer makkelijk recht (no pun intended) te praten is.
Ik heb zelf in het verleden (i.o.v. mijn werkgever) bedrijven (technisch) bijgestaan die een vage email hadden ontvangen over een kwetsbaarheid in hun site. Die bedrijven gingen op basis daarvan duizenden euros uitgeven om een onderzoek te laten doen of die hacker wel echt zo vriendelijk was als dat hij deed voorkomen. Afhankelijk van de omvang van de organisatie was dit in enkele gevallen toch echt wel een financiële klap. Overigens in een enkel geval was er ook wel bewijs dat de hacker zichzelf echt wel meer informatie had toegeëigend dan hij bekend had gemaakt. Dus helemaal onterecht is die angst ook weer niet.
En hoe zit het vervolgens met de inbreker in je huis die achteraf claimt alleen maar te willen demonstreren waar de veiligheid in het geding is? Komt er ivm rechtsgelijkheid voor deze inbrekers ook een vergelijkbaar protocol waarmee hij/zij aan vervolging kan ontsnappen?
Omdat we prima weten hoe de beveiliging van het gemiddelde huis eruit ziet, is er niet echt een algemeen belang dat vereist dat dergelijk onderzoek zomaar moet kunnen. Al is het maar omdat je sloten ook in de winkel kunt kopen en dáármee kunt testen of ze wel stevig genoeg zijn.
Het is echter mogelijk om legaal in te breken, denk aan Alberto Stegeman die erin slaagde op Schiphol alle beveiliging te passeren en bij het vliegtuig van de koningin te komen. Of een actualiteitenprogramma paar jaar terug dat door een buurt liep met een oud-inbreker die uitlegde hoe makkelijk elk huis open te breken was. Ik meen zelfs dat ze daar soms echt naar binnen gingen, maar kan me niet meer herinneren of ze nu vroegen “mogen we even laten zien hoe makkelijk dit is” of de bewoners lieten schrikken door gewoon ineens binnen te staan. Maar als je ’t doet met een camera erbij dan lijkt iedereen het doodnormaal te vinden.
Lang niet alle hackers zijn ook cyberinbrekers. Ben je dagelijks bezig met de techniek, en heb je verstand van beveiliging, dan kom je ook wel eens kwetsbaarheden tegen zonder er actief naar op zoek te gaan. En zelfs als iemand wel actief op zoek gaat, maar dat doet met goede bedoelingen, vind ik de vergelijking met inbrekers te kort door de bocht. Er zijn weinig inbrekers die huizen binnendringen en vervolgens zonder schade of diefstal een briefje met tips achterlaten voor de bewoners; bij hackers is dat echter gelukkig wel een gangbare ethiek.
Wat dat betreft kun je veel hackers beter vergelijken met slotenmakers dan met inbrekers: hackers zijn niet alleen degenen die de beveiliging testen, maar ook degenen die aan de bel trekken, en die de technieken verzinnen om het geheel vervolgens beter te beveiligen. Reken maar dat elk stukje techniek dat jou op internet beschermt tegen kwaadwillenden, door hackers is bedacht en gemaakt.
Ik vind mijzelf geen hacker maar ik heb wel veel vaardigheden waarmee ik de titel “Hacker” zo zou verdienen. Ik heb een goede kennis van beveiliging en heb in het verleden wel eens de beveiliging uitgetest van applicaties die ik op mijn werk maakte. Dat was ook noodzakelijk, omdat mijn werkgever indertijd software produceerde voor het Electronisch betalingsverkeer van grote bedrijven. En verrassend genoeg denken veel bedrijven niet goed na over beveiliging van hun systemen. Maar goed, dat is in de electronische wereld. Een analogie met de fysieke wereld is lastiger omdat de toegang tot beveiligde plekken vereist dat je er ook fysiek aanwezig bent. Een computer hacken zou je zelfs vanaf de achterkant van de maan kunnen doen, mits je maar een snelle internet-verbinding hebt met onze planeet. (Sorry, ben de Star Trek serie “Deep Space Nine” aan het bekijken…)
In de werkelijke wereld zou je in principe zo snel mogelijk een melding willen doen, omdat kwetsbaarheden maar eenmalig zijn. Als ik een dure camera in mijn auto neerleg en de deur niet afsluit is dat slordig en een beveiligingslek, maar die camera kan maar eenmalig gestolen worden. Als ik merk dat iemand een camera in een auto heeft laten liggen kan ik controleren of de deur op slot is. Zoniet, dan kan ik de moeite nemen om de camera onder de voorstoel neer te leggen en een briefje achter te laten voor de eigenaar over waar de camera is opgeborgen. Maar ik kan ook gewoon even de auto bewaken indien ik verwacht dat de eigenaar binnen een paar minuten weer terug is en hem erop aanspreken. Als ik vermoed dat de eigenaar langer weg blijft zou ik mogelijk zelfs contact kunnen opnemen met de politie om hen in te lichten over een auto met waardevolle spullen erin die open en onbewaakt ergens staat. Als ik een bos sleutels op straat vind kan ik in de buurt gaan zoeken naar een woning waar de sleutels op passen maar in dit geval is het verstandiger om de sleutels bij het dichtbijzijndste politiebureau af te geven. En wat mij een keer overkwam was dat een bejaard echtpaar ongeduldig stond te wachten tot hun geld eruit kwam. Maar het duurde hen te lang en ze dachten dat er geen geld uit zou komen. Ze liepen dus weg en op dat moment was ik aan de beurt en kwam er meteen 100 Euro uit die automaat! Tja, ik riep het echtpaar meteen terug omdat ze duidelijk hun geld waren vergeten. Maar het doet mij ook denken of het eigenlijk wel verstandig is dat ouderen nog met een pas geld uit de muur kunnen pinnen, indien ouderen zo slordig met geld omgaan. En met deze lange discussie kom ik bij een kwetsbare groep in onze maatschappij die wel zouden kunnen leren van “estetisch inbreken”, ofwel dat iemand inbreekt in hun huis om hen te waarschuwen dat ze kwetsbaar zijn. Veel ouderen worden te gemakkelijk opgelicht doordat iemand bij hun voordeur aanklopt met een excuus of ze even mogen binnenkomen, om vervolgens wat geld of waardevolle spullen te verliezen. (Of erger!) Omdat ouderen problemen kunnen hebben met hun geheugen zou voor deze groep ook noodzakelijk zijn dat ze keer op keer weer gewezen worden op de gevaren, zonder hen te paranoia te maken. Dat is lastig en vereist een team van mensen die met ouderen om kunnen gaan maar ook kennis hebben van hoe criminelen tewerk gaan. Kortom, dat is een taak die politie-agenten het beste kunnen uitvoeren, in burger.
Maar goed, een agent mag sowieso meer dan een normale burger als het gaat om de beveiliging van mensen en hun eigendommen. Ze mogen de wet niet breken, maar kunnen wel erg ver gaan. Maar ja, in de echte wereld, zoals ik al aangaf, is diefstal van een voorwerp eenmalig en dan ben je het kwijt. Op het Internet kunnen gegevens keer op keer weer gestolen worden, wat de noodzaak voor meer “bewakers” noodzakelijk maakt.
(weggehaald en opnieuw gepost omdat ik de threading niet doorhad.)
Als ik niet zeker weet dat een bedrijf redelijk omgaat met responsible disclosures dan doe ik anoniem aangifte. In principe geef ik veiligheidsproblemen altijd aan, maar ik kan me ook situaties voorstellen waar responsible disclosure niet gaat werken.
Daeken bijvoorbeeld vond een lek in de hardware van hotelkamersloten. Dit lek was zo slecht, dat de gehele organisatie in twijfel werd getrokken. Elke audit zou dit probleem hebben geconstateerd. Hij heeft het lek gepubliceerd op een hackersconventie, omdat hij wist dat de onderwereld al gebruik maakte van dit lek. Voor veel security researchers is het in de publiciteit komen met een lek een goede manier om zich te profileren.
Google en Facebook hebben in mijn ervaring een zeer relaxte manier van melden. Beiden hebben een whitehat bounty programma. Als ik een hack bij de overheid zou vinden dan zou ik mezelf even goed achter de oren krabben alvorens aangifte te doen.
Brute-forcing is ook een lek. Een systeem kan zich wapenen tegen brute-forcen, door bijvoorbeeld het aantal login-attempts te loggen en hier een timer of tijdelijke ban op te plaatsen. Social engineering is ook een legitiem lek. Als je iemands Apple account kunt hacken door simpelweg op te bellen en de “maiden name” te melden dan blijkt hieruit duidelijk een zwakke schakel. Deze zou men ook moeten oppakken.
Als brute-forcing of social engineering niet onder responsible disclosure vallen dan verdwijnen hierbij toch niet de zwakke schakels? Deze technieken worden evengoed gebruikt door de onderwereld.
Security@ email adressen zou elke organisatie moeten hebben. Ipv een robots.txt denk ook aan een hackers.txt waar contactpunten voor melden in kunnen worden opgenomen. Ook kun je een extra tabel aanmaken in de database met hierin de meldpunten “tabel.hackers”.
Het grootste obstakel waar ik tegenaan loop is het ontbreken van een meldpunt, of confirmatie van mijn meldingen.
Arnoud, wat is de juridische vorm waarin het OM zichzelf kan binden om aangiften waarin de ‘strafbare’ handeling aan bepaalde voorwaarden voldoet te seponeren? En dan als vervolgvraag: is het niet beter om dat in de wet zelf te regelen? Allerlei landen hebben in wetten over computervredebreuk uitzonderingen opgenomen voor onderzoekers. Vallen ethische hackers hier niet ook onder? Wellicht kan zelfbinding door het OM echter preciezer beschreven worden, en daardoor meer zekerheid bieden voor hackers, dan de toch altijd wat generieke wetsteksten.
Het beste is inderdaad om dat in de wet op te nemen. Nadeel is dan dat het óf heel breed en vaag moet worden (om alles te dekken) waardoor je er niets aan hebt, óf heel specifiek en duidelijk maar dan moet elk jaar die wet op de schop en dat is niet handig.
Het OM heeft de “Aanwijzingen” als instrument. Zij legt daarin vast hoe zij omgaat met aangiftes in bepaalde categorieën. Je kunt als burger daar rechten aan ontlenen. Een mooi voorbeeld is de Aanwijzing intellectuele-eigendomsfraude, die vastlegt wanneer het OM strafrechtelijk optreedt tegen bijvoorbeeld auteursrechtschending. Een strafrechtszaak tegen betrokkenen bij een filesharingnetwerk werd geseponeerd door het Gerechtshof omdat het OM in strijd met deze aanwijzing had gehandeld: Terugblik: OM niet ontvankelijk in P2P-strafzaak (gastpost). Citaat van hof: