Wanneer is een responsible disclosure beleid rechtsgeldig?

Een lezer vroeg me:

Sommige bedrijven hebben een responsible disclosure beleid en maken dit bekend op hun website. Ik zie alleen daarin steeds vaker iets over geheimhoudingsplicht voorkomen: je mag kwetsbaarheden wel zoeken en melden, maar zonder toestemming (of soms “zonder overleg”) niet publiceren. Maar het hele idee van responsible disclosure is toch juist dat je op zeker moment naar buiten treedt, natuurlijk wel op zorgvuldige wijze. Kunnen bedrijven dit zo stellen, is dit rechtsgeldig? Dan gaat toch het hele concept onderuit?

Een bedrijf dat responsible disclosure-beleid publiceert en daarin zegt dat er nimmer mag worden gepubliceerd zonder haar toestemming, is wat mij betreft misleidend bezig. Dat is niet wat de term responsible disclosure impliceert en het is zeer ergerlijk dat bedrijven op die manier doen alsof ze RP-beleid hebben.

Het hele idee achter responsible disclosure is dat kwetsbaarheden op zeker moment publiek móeten worden, omdat dan iedereen er rekening mee kan houden. Als de good guys hun mond moeten houden dan kunnen bedrijven kwetsbaarheden onder de pet houden. Wat slecht is voor de maatschappij, want de bad guys weten het toch wel. Natuurlijk is het ook weer niet de bedoeling dat kwetsbaarheden direct publiek worden, want dan kan er misbruik van worden gemaakt zonder dat het bedrijf het kon repareren.

De Leidraad over responsible disclosure uit 2013 van de overheid zoekt naar een middenweg. Het idee is dat melder en bedrijf in overleg treden over wanneer naar buiten te treden, met als vuistregel 60 dagen na de melding. Maar dát er naar buiten getreden wordt, staat daarbij voorop. En gezien het belang van security in ICT-systemen is dat ook niet meer dan logisch. Wie anno 2017 nog verdedigt dat security by obscurity beter is, kan beter wat anders gaan doen.

Of responsible disclosure beleid rechtsgeldig is, is een lastige vraag. Beleid is natuurlijk maar beleid, en dat kan zomaar veranderen. Belangrijkste is: wat dóet het, dat beleid. Zijn daar rechten of plichten aan te ontlenen? Plichten opleggen in beleid is erg moeilijk, want de wederpartij moet daar wel mee akkoord gaan. Je kunt dus niet op voorhand iemand aansprakelijk laten zijn voor alle schade die het gevolg is van een ontdekte kwetsbaarheid. Omgekeerd is het wél makkelijk mogelijk om het bedrijf te houden aan een toezegging. Met name dus de toezegging “wij zullen geen aangifte/schadeclaim doen als je je aan het beleid houdt”.

Arnoud

Mag je mensen ethisch scammen?

ring-bel-alarm-geluidEen lezer vroeg me:

Ik lees veel over ethisch hacken en vroeg me af of dat ook voor andere misdrijven geldt? Ik overweeg een “ethische scam” op te zetten. Ik adverteer producten voor €10, en wie geld overmaakt, krijgt een uitleg dat ze opgelicht zijn maar met tips hoe je dat voortaan herkent en wat je kunt doen om het te voorkomen. De €10 houd ik dan als vergoeding voor het advies.

Het strafrecht kent geen uitzondering voor misdrijven die je “ethisch” begaat. Ook hacken – computervredebreuk – is en blijft volgens de letter van de wet strafbaar als je het met de meest ethische nobele motieven begaat.

Alleen vinden we ondertussen dat iemand die dat zeer netjes doet, én zich netjes meldt én geen schade berokkent, niet veroordeeld zou moeten worden. Het belang van het melden van securitybreaches en datalekken weegt zwaar, en als er dan verder ook geen schade of persoonlijk gewin is, dan is er weinig reden iemand nog te vervolgen. Maar dat is geen wettelijke grond waar je je op kunt beroepen, het is coulance.

Deze ethische scam is een aardig idee maar ik denk dat hier heel wat minder draagvlak voor is. Bovendien berokken je mensen zo schade: die tien euro zijn ze kwijt. Dat je (ongevraagd) advies geeft, maakt niet uit. Ik zou dit dus dringend afraden.

Als je mensen hun geld zou teruggeven, dan is in ieder geval de schadecomponent eraf. De kans op vervolging wordt dan kleiner. Maar het blijft voor mij zeer dubieus.

Wat zouden jullie doen als je op deze manier werd “opgelicht”?

Arnoud

Mag ik mensen laten checken of hun OpenSSL aan Heartbleed lijdt?

heartbleed-bug-openssl-securityEen kritieke bug in beveiligingssoftware OpenSSL heeft het jarenlang mogelijk gemaakt om wachtwoorden en andere geheime data van servers te achterhalen. Voor hackers, maar ook de NSA, zo is gebleken. De pijnlijke fout, die Heartbleed is genoemd, is zeer wijdverspreid. Logisch dus dat mensen nu tools ontwikkelen om te zien of een site kwetsbaar is. Maar mag dat eigenlijk wel?

De kwetsbaarheid in de OpenSSL software zit hem in een stukje code dat wordt gebruikt om een beveiligde verbinding ‘open’ te houden. Om dat te doen, stuurt de client periodiek een signaal naar de server, die dan een korte reactie geeft. Een soort meten van de hartslag van de server; leeft hij nog? De reactie bestaat uit een kopie van het signaal, oftewel je herhaalt als server wat de client net tegen je zet (“Hallo?” “Hallo!” zeg maar).

Bij dat signaal staat hoe lang het is. En het probleem is dat de server dat opgegeven aantal bytes terugstuurt, ongeacht hoe lang de boodschap feitelijk was. Zeg je dus “64Hallo?” dan krijg je 64 tekens terug, waarvan de eerste vijf “Hallo?” zijn en de rest wat er toevallig in het servergeheugen staat. Dat kan dus van alles zijn, inclusief wachtwoorden en sessie-tokens van anderen. Zie ook deze xkcd. Daar gaat mijn hart ook wel even van bloeden ja.

Je site testen of deze kwetsbaar is, is dus zeer verstandig. Daar zijn tools voor, en natuurlijk is het volstrekt legaal dat te doen op je eigen site. Maar een hoop mensen willen ook testen of andere sites kwetsbaar zijn, bijvoorbeeld omdat ze daar hun webmail of andere belangrijke diensten hebben ondergebracht. Of omdat ze journalistiek nieuwsgierig zijn. Of omdat ze in willen breken. En daar ga je dan, juridisch: mág dat dan wel, andermans site testen op deze veiligheid?

Testen van een kwetsbaarheid is in theorie te zien als computervredebreuk. Het is van dezelfde orde als testen of iemands achterdeurslot met een balpen te openen is. Je dringt binnen in de server en verschaft je toegang tot gegevens waarvoor je niet geautoriseerd bent. Het gaat iets verder dan een portscan, waarbij je immers alleen maar legale verzoeken doet aan de server (“Dag, doet u aan POP3 of NTP?”) en de informatie die je dan krijgt, gebruikt om in te breken. Het testen op de Heartbleed-fout levert je meer informatie op dan de bedoeling is. Dus formeel ben je strafbaar.

Gezien de grote impact van de fout denk ik toch dat dit juridisch niet bezwaarlijk moet zijn. Wel moet je een duidelijk belang hebben bij het testen van die site én de beheerders op de hoogte stellen van de fout. Misbruik maken van de gevonden gegevens maakt het echt strafbaar.

Natuurlijk kun je zeggen, het is niet jouw taak om andermans websites te testen. Dat moeten ze zelf doen. Dat is ook zo. Alleen het teleurstellende feit is dat veel mensen dat gewoon niet dóen. En omdat ze daarmee ánderen in gevaar brengen (in tegenstelling tot dat achterdeurslot, waar ze alleen zelf last van hebben) vind ik het maatschappelijk verantwoord om dan toch aan de bel te trekken: “hoi, je bloedt andermans gegevens, dóe iets”.

Diverse mensen vroegen me ook of ze een site mogen opzetten die onderzoekt of een gegeven website kwetsbaar is (zoals Filippo). Ik denk dat dat wel mag, mits je de tool maar zo voorzichtig mogelijk opzet. Het liefst zegt hij alleen “ja/nee”, een datadump van wat de server lekt (bloedt?) laat zien, gaat echt te ver. En je zou nog een vertraging in kunnen bouwen. Eén site testen prima, twee of drie nou vooruit, maar wie twintig sites achter elkaar gaat testen is een beetje raar.

Helemaal netjes zou zijn dat je zegt, installeer eerst een bepaald bestandje op je website met een unieke naam, en dan controleert of dat bestandje bestaat op die website voordat je de test uitvoert. Dan weet je zeker dat de gebruiker aan de website gelieerd is. Maar dat voelt wat zwaar voor één korte test.

Arnoud

Minister: geen aangifte tegen ‘ethische’ hackers

bug-disclosureMinister 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:

  1. 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.
  2. Ontvangst van een melding wordt digitaal bevestigd, waarna organisatie en melder gaan overleggen over de verdere afhandeling.
  3. 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.)
  4. 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.”
  5. De organisatie houdt de melder op de hoogte van de voortgang.
  6. De organisatie kan desgewenst de melder credits geven in het persbericht dat de fout gefixt is (of in de patch.)
  7. De organisatie kan een beloning of waardering geven voor een melding, mits men zich aan de spelregels houdt.
  8. 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