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

28 reacties

  1. 60 dagen is heel weinig. Veel bedrijven hebben een update cyclus van 3-6 maanden voor maatwerk software en dat is nog zonder de intake en beoordeling en prioritering van extern aangebrachte issues en zonder een externe opdrachtverleningsproces richting een externe softleverancier. 6 maanden zou een veel logischer termijn zijn.

    1. 6 maanden is idioot lang voor een beveiligingslek. We hebben het hier over persoonsgegevens of andere gevoelige informatie. Als ik meld dat ik zomaar in het papieren archief kan binnenlopen, dan zeggen ze toch ook niet dat ik drie maanden moet wachten omdat het aanbestedingstraject voor een nieuwe deur zo lang loopt?

      1. We hebben het hier over persoonsgegevens of andere gevoelige informatie

        Dat hoeft helemaal niet. Je hebt ernstige en niet ernstige lekken en dat is niet altijd evident. Vaak is de negatieve publiciteit rondom het lek ernstiger dan het lek zelf is. De disclosure is daarom heel vaak een ernstiger probleem dan het lek zelf.

    2. Jezus, welke professioneel bedrijf houd geen rekening met hotfixes in hun update cyclus? Nog nooit van Continous Integration gehoord zeker. Als je 6 maanden doet over het updaten van je software dan betwijfel ik of je bedrijfsproces wel bedoelt is voor het ontwikkelen van software of misbruikt wordt voor kantoorpolitiek, haantjesgedrag en managers die een gebrek aan kennis hebben.

    3. Voor security issues moeten ze dat tempo echt omhoog brengen. Dat moet gewoon onderdeel van je manier van werken worden, eventueel een dominant onderdeel, dat bepaalt hoe je veel andere dingen doet zodat je aan de security-eisen kan voldoen.

      Het “Week to Weak” report liet zien dat kwetsbaarheden gemiddeld een week na bekend worden uitgebuit worden. Toegegeven: de tijd voor bekend worden -> uitgebuit worden is waarschijnlijk gemiddeld een stuk korter dan de tijd voor bestaan -> bekend worden van een fout, maar het is wel een indicatie van hoe snel je moet zijn in deze tak van sport. Bijvoorbeeld, als je in jouw software een library gebruikt, en er wordt een beveiligingslek in die library bekend, dan zal het niet lang duren voordat iemand bedenkt dat jouw software dan waarschijnlijk kwetsbaar is. In dat scenario moet je klaar staan om in veel minder dan een week een update van je software uit te brengen die met een gepatchte library werkt.

    4. Als je binnen je softwareorganisatie een fast-path hebt voor het oppakken en oplossen van serieuze veiligheidsproblemen (de programmeurs die het probleem moeten oplossen mogen al het andere werk laten liggen), dan kun je binnen een week een hotfix gemaakt hebben die een paar dagen later getest en binnen twee weken uitgerold is.

      Ik heb ooit bij een organisatie gezeten waar we bij productieproblemen regelmatig binnen een dag een fix maakten en uitrolden naar (alleen) het systeem met problemen… Ik heb mijn mening over alle bedrijven die niet in staat zijn om fixes voor veiligheidsgaten binnen een maand uitgerold te hebben.

      1. Inderdaad, beveiligings- en andere kritische fouten gaan voor alles. Afhankelijk van waar de fout zit laat bij ons de aangewezen persoon (personen) al het andere wat het is tot de fout opgelost is. Doorgaans is de nieuwe versie er binnen 24 uur, langer dan twee dagen heeft het nooit geduurt.

      2. Als je binnen je softwareorganisatie een fast-path hebt voor het oppakken en oplossen van serieuze veiligheidsproblemen

        Er zijn echter ook veel minder serieuze veiligheidsproblemen die worden gemeld. Veel gemelde issue betreffen niet heel belangrijke informatie of hele beperkte datasets of zijn normaal geen doel voor hackers omdat de informatie eigenlijk niet echt boeiend is (niveau telefoonboek). Daarnaast kunnen er nog veel andere redenen zijn om software niet meteen aan te passen omdat er andere systemen afhnakelijk van zijn. De overheid kan bijvoorbeeld niet even snel DigID aanpassen zonder de aangesloten partijen te laten testen omdat het niet mag voorkomen dat door een release bijvoorbeeld burgers niet meer hun belastingaangifte kunnen aanleveren aan de belastingdienst

        Verder denk je vanuit een software organisatie maar de realiteit is dat de meeste organisaties voor hun software afhankelijk zijn van externe leveranciers en niet het vermogen hebben om een lek zelf te dichten. Soms kan een organisatie zelfs niet om over de ernst van een ingediend lek te oordelen zeker als de omschrijving door de indiener nogal cryptisch of te technisch is en niet duidelijk maakt wat de gevolgen van het lek eigenlijk zijn.

        Het is sowieso niet zinnig een te snelle standaard disclosure tijd te kiezen omdat de situatie niet voor iedereen gelijk is. Dat er organisaties die een bepaalde hotfix in een dag of een week kunnen doen zegt niks over alle hotfixes of alle organisaties. Bij het kiezen van een standaard voor dergelijke disclosures moet je juist ook rekening houden met de organisaties die minder goede ICT voorzieningen hebben en zorgen dat ook het merendeel daarvan in staat is om een oplossing te vinden voor de gemelde lekken.

        1. hAl, je hebt gelijk dat sommige lekken serieuzer zijn dan andere en dat je de minder serieuze lekken met een reguliere update kunt laten meelopen. Maar dan moet je wel de binnengekomen meldingen laten scannen door een competent persoon en dan kun je de “veiligheidsonderzoeker” snel (binnen een week) de resultaten van de eerste analyse doorgeven.

          Als je je als management van een organisatie voor bedrijfskritische processen afhankelijk maakt van je leveranciers, dan ga je in de problemen komen als jouw leveranciers je in de steek laten. Met alle gevolgen (weglopende klanten, lasten en boetes van de Autoriteit Persoonsgegevens) die daarbij horen. Zorg ervoor dat je competent genoeg bent om je leveranciers aan te sturen!

        2. Het is sowieso niet zinnig een te snelle standaard disclosure tijd te kiezen omdat de situatie niet voor iedereen gelijk is. Dat er organisaties die een bepaalde hotfix in een dag of een week kunnen doen zegt niks over alle hotfixes of alle organisaties. Bij het kiezen van een standaard voor dergelijke disclosures moet je juist ook rekening houden met de organisaties die minder goede ICT voorzieningen hebben en zorgen dat ook het merendeel daarvan in staat is om een oplossing te vinden voor de gemelde lekken.

          Dit lijkt mij niet relevant. Die organisaties zorgen er maar voor dat ze hun zaakjes wel op orde hebben. Het is toch van de zotte om nalatigheid te belonen met een ruimere deadline?

          1. Jij noemt het nalatigheid belonen maar vind voortijdige disclosure juist ook het in gevaar brengen van de privacy van bijvoorbeeld klanten van de lekkende bedrijven die er niks aan kunnen doen. Er wordt te gemakkelijk voorbijgegaan aan het feit dat de slachtoffers van hacks vaak gewone mensen zijn die niks kunnen doen aan die hacks.

            En ook vind ik het nogal makkelijk om te stellen dat bedrijven de zaakjes niet op orde hebben. Vaak is dat namelijk veroorzaakt door slecht opgeleverde producten van ICT leveranciers en kunnen die bedrijven waar de lekken worden gevonden daar zelf weinig of niets aan doen. Hoogstens jaag je hen op extra kosten door een spoedklus aan te vragen bij hun leveranciers en profiteren die ICT leveranciers dubbel van hun gemaakte fouten.

  2. je mag kwetsbaarheden wel zoeken en melden, maar zonder toestemming (of soms “zonder overleg”) niet publiceren.

    De “geheimhoudingsplicht” is gangbaar. Deze is ook opgenomen in de “Responsible Disclosure voor de Rijksoverheid” [1] en de “Leidraad om te komen tot een praktijk van Responsible Disclosure” [2].

    Specifiek:

    De Rijksoverheid lost het beveiligingsprobleem zo snel mogelijk op, maar uiterlijk binnen 60 dagen. De Rijksoverheid zal samen met u bepalen of en hoe over het gemelde probleem wordt bericht. Berichtgeving vindt pas plaats nadat het probleem is opgelost.

    Er zijn scenario’s denkbaar waar een lek wel kan worden gedicht in de toekomst, maar niet retro-actief in het verleden. Denk bijvoorbeeld aan reeds gepubliceerde (open) datasets waar iets mis is gegaan met anonimiseren: Bijvoorbeeld, een disclosure van een truuk om uit een gehashed IP het originele IP te herleiden is problematisch, omdat het kalf reeds verdronken is. Ik snap wel dat een ethisch hacker graag over gevonden vulnerabilities wil publiceren: Dit is het bouwen aan een professionele reputatie.

    Fox-IT, een gerenommeerd security bedrijf, houdt zelfs de volgende slag om de arm in haar beleid [3]:

    Het is helaas niet mogelijk bij voorbaat juridische stappen tegen u uit te sluiten. We willen elke situatie apart kunnen afwegen. We achten ons zelf moreel verplicht om aangifte te doen op moment dat we het vermoeden hebben dat de zwakheid of gegevens misbruikt worden, of dat u kennis over de zwakheid met anderen heeft gedeeld. U kunt er op rekenen dat een toevallige ontdekking in onze online-omgeving niet tot aangifte zal leiden.

    Als een gemeld probleem niet tijdig wordt opgelost, en zonder overleg wordt gepubliceerd, dan is simpelweg geen sprake van een “responsible disclosure”. De partij met het probleem in haar platform is dan “irresponsible” bezig, en de ethisch hacker met “zaakwaarneming”.

    [1] https://www.rijksoverheid.nl/onderwerpen/cybercrime/vraag-en-antwoord/responsible-disclosure

    [2] https://www.rijksoverheid.nl/onderwerpen/cybercrime/documenten/rapporten/2013/01/04/leidraad-om-te-komen-tot-een-praktijk-van-responsible-disclosure

    [3] https://www.fox-it.com/nl/responsible-disclosure-beleid/

    1. Als een gemeld probleem niet tijdig wordt opgelost, en zonder overleg wordt gepubliceerd, dan is simpelweg geen sprake van een “responsible disclosure”.

      Misschien juridisch niet, maar ethisch gezien zeker wel. Je lijkt hier even een essentieel punt van de geschiedenis achter responsible disclosure te missen; namelijk het feit dat publicatie als stok achter de deur werkt om onwillende organisaties te dwingen problemen op te lossen en transparent erover te zijn, zonder daarbij organisaties te benadelen die wel verantwoordelijk met lekken omgaan (zoals het geval zou zijn bij full disclosure).

      Dus sterker nog: een harde publicatie-deadline, met of zonder medewerking van de organisatie in kwestie, is een vereiste om iets “responsible disclosure” te kunnen noemen. Waar jij aan denkt is “coordinated disclosure”, en dat is iets heel anders.

      1. Ik doelde op Google die een Microsoft security bugs openbaarde voordat de patches beschikbaar waren. Dit was geen coordinated, of responsible disclosure, dit was een full disclosure. Ik blijf erbij: Als de organisatie niet reageert, of de ethisch hacker openbaart voordat het probleem is opgelost in een redelijke termijn, zonder overleg, dan is geen sprake van een “responsible disclosure”. Een “responsible disclosure” is niet eenzijdig.

        “Coordinated” is niet heel anders dan “responsible disclosure”. “Coordinated disclosure” is een MS rebrand van responsible disclosure (omdat die woordkeuze impliceert dat elke andere vorm van openbaring “irresponsible” zou zijn).

        1. Voor mijn gevoel voeg je nu twee situaties samen die dat niet verdienen: 1) De organisatie reageert niet 2) De hacker openbaart voor het probleem redelijkerwijs zou moeten zijn opgelost

          Situatie 1 is precies waar het hele RD beleid voor ontwikkeld is. Je wilt mensen dwingen om tot actie te komen, en de dwang komt uit “dit wordt over 60 dagen openbaar en dan heb je pas écht een probleem dus doe iets”.

          1. Anecdote: Ik heb meerdere responsible disclosures gedaan en nooit om organisaties te dwingen om tot actie te komen. Ikzelf vind deze dwangmatige opstelling een beetje lelijk, en gevaarlijk klinken: “Maak deze bug in 60 dagen, of anders!!!”.

            In de Leidraad is ook sprake van toestemming, overeenkomen, en overleg:

            De organisatie bepaalt in overleg met de melder de termijn waarop eventuele bekendmaking zal plaatsvinden. Een redelijke standaardtermijn die kan worden gehanteerd voor kwetsbaarheden in software is 60 dagen. Het verhelpen van kwetsbaarheden in hardware is lastiger te realiseren, hierbij kan een redelijke standaardtermijn van 6 maanden worden gehanteerd.
            In overleg kan het wenselijk zijn om deze termijn uit te breiden of in te korten, indien veel of juist weinig systemen afhankelijk zijn van het systeem ten aanzien waarvan de kwetsbaarheid gemeld wordt.
            Als een kwetsbaarheid niet of moeilijk op te lossen is, of indien er hoge kosten mee gemoeid zijn, kunnen melder en organisatie afspreken om de kwetsbaarheid niet openbaar te maken.
            Als melder en organisatie overeen komen dat de kwetsbaarheid openbaar wordt gemaakt dan maakt een melder het pas openbaar als alle betrokken organisaties goed zijn geïnformeerd en zij aangegeven hebben dat de kwetsbaarheid is opgelost, conform de gemaakte afspraken.

            Dit mag niet misbruikt worden om een PR-gevoelige bug onder het tapijt te vegen, maar er is dus wel normaalgesproken sprake van toestemming verkrijgen voordat tot publicatie mag worden overgegaan.

            En voor de definitie:

            Responsible disclosure binnen de ICT-wereld is het op een verantwoorde wijze en in gezamenlijkheid tussen melder en organisatie openbaar maken van ICT-kwetsbaarheden op basis van een door organisaties hiervoor vastgesteld beleid voor responsible disclosure.

            Als een disclosure niet op verantwoorde wijze gebeurd (Bijvoorbeeld: bug wordt gepubliceerd/gedeeld, zonder overleg, voordat deze is opgelost) of in samenwerking met melder en organisatie (Bijvoorbeeld: De organisatie reageert niet), dan is geen sprake van een responsible disclosure.

            1. Ikzelf vind deze dwangmatige opstelling een beetje lelijk, en gevaarlijk klinken: “Maak deze bug in 60 dagen, of anders!!!”.

              Dit blijkt helaas noodzakelijk. Ik zie ook niet waarom je problemen met dit beleid zou hebben, tenzij je doel is om het oplossen van veiligheidslekken een lagere prioriteit te geven – en het voorkomen daarvan is nu precies de bedoeling van dit beleid!

              In de Leidraad is ook sprake van toestemming, overeenkomen, en overleg:

              Die Leidraad kan zoveel zeggen, maar het is geen universeel woordenboek. De definitie van “responsible disclosure” verandert dus niet omdat de Leidraad er iets anders over vindt.

              Als een disclosure niet op verantwoorde wijze gebeurd (Bijvoorbeeld: bug wordt gepubliceerd/gedeeld, zonder overleg, voordat deze is opgelost) of in samenwerking met melder en organisatie (Bijvoorbeeld: De organisatie reageert niet), dan is geen sprake van een responsible disclosure.

              Zoals ik in mijn andere reactie al uitgelegd heb, is dit onjuist. Het zonder overleg publiceren van een lek als de deadline is verstreken is een essentieel onderdeel van het responsible-disclosure-proces. “Responsible” refereert hier niet enkel aan “verantwoordelijk tegenover de vendor”, maar ook aan “verantwoordelijk tegenover de maatschappij”. En het omzeilen van een lastige vendor is daar gewoon een onderdeel van.

              Je presenteert het hier alsof het de vendors zijn die de regels stellen, maar dat is dus niet zo. Het is in de praktijk nog steeds de keus aan de vinder om te bepalen hoe het lek te publiceren, en dan mag je als vendor blij zijn met een deadline van 60 dagen, wat al bijzonder ruim is (en m.i. veel te ruim). Daar doen beloftes over “geen aangifte doen” niets aan af.

              1. Zoals ik in mijn andere reactie al uitgelegd heb, is dit onjuist. Het zonder overleg publiceren van een lek als de deadline is verstreken is een essentieel onderdeel van het responsible-disclosure-proces. “Responsible” refereert hier niet enkel aan “verantwoordelijk tegenover de vendor”, maar ook aan “verantwoordelijk tegenover de maatschappij”. En het omzeilen van een lastige vendor is daar gewoon een onderdeel van.

                Misschien een kwestie van semantiek, maar ik zie responsible disclosure als een contract tussen twee partijen. Zoals een verkoopcontract niet eenzijdig kan worden afgesloten, zo kan een responsible disclosure niet gebeuren zonder samenwerking van twee partijen (de melder en de organisatie).

                Je gaat als melder het proces in met de hoop dat het probleem in samenwerking wordt opgelost. Reageert het bedrijf niet dan is het proces mislukt. Een eventuele disclosure is dan helemaal het pakkie van de melder: Er zijn bijvoorbeeld dan geen garanties/toezeggingen van geen-gerechtelijke-stappen clausule.

                Je presenteert het hier alsof het de vendors zijn die de regels stellen, maar dat is dus niet zo.

                Inderdaad. De vraag gaat over een responsible disclosure beleid. Dit beleid wordt opgesteld door de organisatie (niet de melder). De oplos-termijn dient, volgens gangbaar beleid, in samenwerking te worden vastgesteld, en dus niet: “Maakt me niet uit of dit een onoplosbaar probleem is, ik publiceer hoe dan ook in 60 dagen. Your move!”.

                Die Leidraad kan zoveel zeggen, maar het is geen universeel woordenboek. De definitie van “responsible disclosure” verandert dus niet omdat de Leidraad er iets anders over vindt.

                Die Leidraad is wel zeker relevant. Het gaat om rechtsgeldigheid van clausules in een responsible disclosure beleid. Een rechter zal eerder kijken naar de Leidraad, dan naar een “gangbare” definitie in de hackerwereld.

                1. Misschien een kwestie van semantiek, maar ik zie responsible disclosure als een contract tussen twee partijen.

                  Dat is het niet. Responsible disclosure is een gunst vanuit de infosec-gemeenschap tegenover vendors. Als vendors het spelletje niet meespelen, dan is die gunst net zo snel weer ingetrokken, en valt het terug naar full disclosure.

                  Zoals een verkoopcontract niet eenzijdig kan worden afgesloten, zo kan een responsible disclosure niet gebeuren zonder samenwerking van twee partijen (de melder en de organisatie).

                  Dat is onjuist; responsible disclosure vereist geen medewerking van de vendor, het enige dat vereist is is dat de melder de vendor de kans geeft om mee te werken.

                  Inderdaad. De vraag gaat over een responsible disclosure beleid. Dit beleid wordt opgesteld door de organisatie (niet de melder). De oplos-termijn dient, volgens gangbaar beleid, in samenwerking te worden vastgesteld, en dus niet: “Maakt me niet uit of dit een onoplosbaar probleem is, ik publiceer hoe dan ook in 60 dagen. Your move!”.

                  Een responsible-disclosure-beleid is een voorstel vanuit een vendor aan onderzoekers. Het staat melders vrij om dat voorstel te verwerpen. Voor responsible disclosure is het uitdrukkelijk niet vereist om vendor-beleid op te volgen – de machtsverhouding ligt andersom.

                  Die Leidraad is wel zeker relevant. Het gaat om rechtsgeldigheid van clausules in een responsible disclosure beleid. Een rechter zal eerder kijken naar de Leidraad, dan naar een “gangbare” definitie in de hackerwereld.

                  Tot het moment dat het publiceren van lekken als iets strafbaars gezien wordt, zijn de toezeggingen in zo’n beleid volkomen irrelevant. Medewerking van de vendor is, wederom, niet vereist.

        2. Ik doelde op Google die een Microsoft security bugs openbaarde voordat de patches beschikbaar waren. Dit was geen coordinated, of responsible disclosure, dit was een full disclosure.

          Onjuist. Dit was responsible disclosure.

          • Coordinated disclosure: De details worden vrijgegeven zodra de vendor daar toestemming voor geeft.
          • Responsible disclosure: De details worden vrijgegeven zodra de patch beschikbaar is, of de tijdslimiet voor het oplossen van het probleem verloopt.
          • Full disclosure: De details worden direct na de vondst vrijgegeven zonder daar de vendor van op de hoogte te stellen.

          Een beknopte geschiedenis: In den beginne was er coordinated disclosure (al had het die naam nog niet), maar bedrijven namen lekken niet serieus en ze werden niet opgelost, vaak met het argument dat “als de lekken niet publiek zijn, maakt het niet uit, want dan weet niemand dat ze bestaan”.

          Toen kregen de beveiligingsonderzoekers er genoeg van, kwam de insteek “okee, dan niet” naar voren, en werd het full disclosure om zo een vendor te dwingen de problemen op te lossen, door ze onder druk te zetten (want nu kon iedereen het lek misbruiken).

          Maar dat raakte ook de vendors die het wel tijdig opgelost zouden hebben, en dus werd responsible disclosure als een middenweg gevonden; de vendor krijgt een redelijk tijdsbestek om het probleem op te lossen en de patch uit te rollen, en als de vendor nalatig blijkt, dan gaat het lek alsnog als dwangmiddel publiek.

          De gedwongen publicatie is dus een essentieel deel van het beleid, om er zo voor te zorgen dat ook de nalatige vendors problemen oplossen. Dit is dan ook precies wat Google doet; ze geven de vendor 90 dagen (wat al erg ruim is), en als de vendor het dan nog niet opgelost heeft, dan pas gaat het lek publiek.

          1. Google & Full Disclosure: http://www.computerworld.com/article/2518900/security0/google-researcher-gives-microsoft-5-days-to-fix-xp-zero-day-bug.html

            Ormandy admitted that he reported the vulnerability to Microsoft only five days ago — on Saturday, June 5 — but said he decided to go public because of its severity, and because he believed Microsoft would have otherwise dismissed his analysis. “If I had reported the … issue without a working exploit, I would have been ignored,” he said in the Full Disclosure posting.

            Zie Google’s positie: https://security.googleblog.com/2010/07/rebooting-responsible-disclosure-focus.html

            BTW: Google gaf Microsoft laatst voor een actieve exploit 60 dagen, en publiceerde exact op de 60e dag (3 dagen voordat de geplande patch uitkwam).

            1. Google & Full Disclosure: http://www.computerworld.com/article/2518900/security0/google-researcher-gives-microsoft-5-days-to-fix-xp-zero-day-bug.html

              Dit lijkt me een geval dat meer naar full disclosure neigt, niet zozeer responsible disclosure. Echter dateert het van voor Project Zero (dat een responsible-disclosure-beleid vaststelde).

              BTW: Google gaf Microsoft laatst voor een actieve exploit 60 dagen, en publiceerde exact op de 60e dag (3 dagen voordat de geplande patch uitkwam).

              Ik zie daar geen probleem mee, behalve dat 60 dagen erg ruim is. De deadline is gesteld, Microsoft heeft die overschreden, dus het lek gaat publiek. Als Microsoft er niet genoeg prioriteit aan stelt om het op tijd op te lossen, is dat hun probleem. Het is geen geval van “kunnen”, het is een geval van “bereid zijn te investeren in”.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.