Coordinated Disclosure Timelines verstehen

Coordinated Disclosure erfordert die Balance zwischen zwei konkurrierenden Interessen: Organisationen Zeit für Fixes zu geben, während User nicht länger als nötig exponiert bleiben. Die Timeline, die du wählst, beeinflusst sowohl Security-Ergebnisse als auch Forscher-Beziehungen.

Standard Disclosure Timelines

Die meisten Organisationen nutzen 90-Tage-Disclosure-Timelines. Das ist nicht willkürlich. Es kommt von Google Project Zero, das 90 Tage als vernünftigen Kompromiss 2015 etablierte. Davor variierten Timelines wild, von sofortiger Disclosure bis zu unbestimmten Verzögerungen, die User jahrelang verwundbar ließen.

Der 90-Tage-Standard funktioniert für die meisten Vulnerabilities. Es ist genug Zeit, um für typische Issues einen Fix zu entwickeln, zu testen und zu deployen. Es ist kurz genug, dass User nicht für längere Perioden verwundbar bleiben. Organisationen, die

diesen Timeline anfangs widerstanden, haben ihre Prozesse größtenteils angepasst.

Einige Organisationen nutzen verschiedene Timelines. Microsoft nutzt traditionell 120 Tage. Viele Bug-Bounty-Plattformen defaulten auf 90 Tage, erlauben aber Extensions. Critical-Infrastructure-Organisationen handeln manchmal 180 Tage aus. Einige unabhängige Forscher bevorzugen 45 Tage, argumentierend dass Organisationen mit reifen Security-Programmen schneller sein sollten.

Wann Timelines starten

Die Disclosure-Timeline startet, wenn die Organisation den Empfang des Vulnerability-Reports bestätigt. Nicht wenn der Forscher ihn sendet, nicht wenn er in eine Queue kommt, sondern wenn jemand von der Organisation bestätigt, dass sie ihn empfangen und verstanden haben.

Diese Unterscheidung ist wichtig. Wenn ich Montag eine Vulnerability melde und zwei Wochen nichts höre, sollten diese zwei Wochen nicht gegen die 90-Tage-Timeline zählen. Die Organisation hatte die Information, hat aber nicht darauf reagiert. Klare Bestätigung verhindert spätere Disputes.

Eine ordentliche Bestätigung sagt etwas wie "Wir haben deinen Report erhalten und werden ihn untersuchen." Ein Auto-Reply zählt nicht. Der Forscher braucht Bestätigung, dass ein Mensch die Submission geprüft und als valide akzeptiert hat.

Timeline Extensions

Extensions passieren, und das ist okay wenn gerechtfertigt. Manchmal ist eine Vulnerability komplexer als sie erschien. Manchmal erfordert der Fix architektonische Änderungen, die mehr Zeit brauchen. Manchmal ist der betroffene Code in Legacy-Systemen, die schwer sicher zu modifizieren sind.

Vernünftige Extension-Requests beinhalten spezifische Rechtfertigungen und neue Timelines. "Wir brauchen weitere 30 Tage, um den Fix in unserer Staging-Umgebung zu testen" ist vernünftig. "Wir sind mit anderen Prioritäten beschäftigt" ist es nicht. Unbegrenzte Verzögerungen ohne spezifische Timeline sind nicht akzeptabel. Extensions ohne Status-Updates lassen Forscher fragen, ob du wirklich am Issue arbeitest.

Bei einer Extension-Anfrage erkläre warum und gib ein spezifisches neues Datum an. Die meisten Forscher gewähren vernünftige Extensions, wenn du ehrlich über die Situation kommunizierst.

Sofortige Disclosure

Einige Vulnerabilities erfordern sofortige öffentliche Disclosure und umgehen die übliche Timeline. Aktive Exploitation ändert alles. Wenn eine Vulnerability in the Wild exploited wird, gilt die übliche Timeline nicht. User müssen sofort Bescheid wissen, damit sie Schutzmaßnahmen ergreifen können, auch wenn kein Patch bereit ist.

Vendor-Unresponsiveness ist anders als ein Vendor, der mehr Zeit anfragt. Wenn du mehrere Kontaktversuche über mehrere Wochen gemacht hast und keine Antwort erhalten hast, ist das keine Coordinated Disclosure mehr. Du hast Good-Faith-Bemühungen gemacht, und der Vendor hat sich entschieden, nicht zu engagieren.

Critical-Infrastructure-Vulnerabilities, die sofortige Gefahr darstellen, erfordern möglicherweise schnelles Handeln. Vulnerabilities in Healthcare-Systemen, Utilities oder Transportinfrastruktur können manchmal nicht 90 Tage warten. Das Schadenspotenzial überwiegt den üblichen Coordination-Prozess.

Partial Disclosure

Einige Disclosure-Modelle veröffentlichen begrenzte Informationen, bevor die volle Timeline abläuft. Security-Teams könnten Indicators of Compromise oder Detection-Methoden veröffentlichen, ohne die zugrundeliegende Vulnerability zu enthüllen. Das hilft Defendern, Attacks zu erkennen, ohne Angreifern einen Roadmap zu geben.

Vendors kündigen manchmal an, dass eine Vulnerability existiert und dass ein Fix kommt, ohne Exploit-Details zu geben. Das alarmiert User, Updates zu priorisieren, ohne zu enthüllen, wie das Issue zu exploiten ist. Die Koordination dieser Ankündigung mit dem Forscher verhindert Verwirrung.

Timeline-Verstöße

Wenn jemand die vereinbarte Timeline verletzt, sind Optionen limitiert. Wenn ein Forscher früh publiziert, kann der Vendor sofort fixen und releasen wenn möglich, oder Usern erklären, dass ein Fix kommt. Öffentliche Kritik am Forscher backfired meist und entmutigt zukünftige Reports.

Wenn ein Vendor die Deadline verpasst, kann der Forscher gemäß der ursprünglichen Timeline publizieren. Einige Forscher gewähren eine Kulanzfrist von 7-14 Tagen, aber das ist nicht erforderlich. Die ursprüngliche Vereinbarung setzte die Deadline, und Vendors, die sie nicht einhalten können, hätten früher eine Extension anfordern sollen.

Manchmal entdeckt und publiziert eine Drittpartei unabhängig dieselbe Vulnerability, bevor die Timeline abläuft. Das passiert. Die ursprüngliche Timeline wird irrelevant, sobald die Information public ist. Beide Parteien sollten anerkennen, was passiert ist, und weitermachen.

Kulturelle Unterschiede

Disclosure-Timeline-Erwartungen variieren nach Region und Industrie. Asia-Pacific-Organisationen bevorzugen oft längere Timelines von 120-180 Tagen und weniger öffentliche Disclosure. Europäische Organisationen sind stark von GDPR-Anforderungen beeinflusst, mit formellen Breach-Notification-Timelines. Die USA haben einen Mix von Ansätzen, mit Government-Sektoren, die oft längere Timelines als Private Industry nutzen.

Open-Source-Projekte stellen einen einzigartigen Fall dar. Viele bevorzugen öffentliche Issue-Tracker von Anfang an, was "Disclosure" weniger relevant macht. Der gesamte Entwicklungsprozess passiert öffentlich, inklusive Security-Fixes. Private Disclosure an Maintainer passiert für ernste Issues, aber die Erwartung ist, dass Fixes öffentlich entwickelt werden.

Deine Timeline setzen

Wenn du ein Vulnerability-Disclosure-Programm etablierst, bedenke deine tatsächliche Fähigkeit, Issues zu fixen. Wie schnell kannst du Fixes entwickeln, testen und deployen? Wenn dein Release-Cycle monatlich ist, machen 90 Tage Sinn. Wenn du innerhalb von Tagen hotfixen kannst, könnte eine kürzere Timeline funktionieren.

Berücksichtige Koordinationsanforderungen. Erfordern Fixes Koordination mit Hardware-Herstellern, OS-Vendors oder Downstream-Usern? Addiere dafür Zeit. Security-Fixes brauchen Testing, weil einen Patch zu rushen, der Production bricht, schlimmer ist als sich extra Zeit zu nehmen, um es richtig zu machen.

Bedenke deine Kommunikationskapazität. Kann dein Team regelmäßige Kommunikation mit Forschern während der Timeline aufrechterhalten? Längere Timelines erfordern mehr Status-Updates. Forscher wollen wissen, dass du an ihrem Report arbeitest, nicht ihn ignorierst.

Timeline-Kommunikation

Regelmäßige Status-Updates verhindern Missverständnisse. Bestätige den Empfang sofort. Gib innerhalb einer Woche ein initiales Assessment zu Severity und Scope. Gib um Tag 30 ein Progress-Update. Teile um Tag 60 Fix-Status und Timeline. Bei Tag 90 release entweder den Fix oder fordere eine Extension mit spezifischer Rechtfertigung an.

Du musst in diesen Updates keine technischen Details enthüllen. "Wir haben die Root Cause identifiziert und entwickeln einen Fix" ist ausreichend. Forscher wollen wissen, dass du daran arbeitest, nicht die Implementierungsdetails deines Fixes.

Exceptions machen keine Regeln

Jede Disclosure hat einzigartige Umstände. Der 90-Tage-Standard funktioniert für die meisten Fälle, aber starre Einhaltung, wenn Umstände Flexibilität rechtfertigen, dient der Security nicht. Was zählt, ist Good-Faith-Collaboration zwischen Forscher und Organisation, mit beiden Parteien, die User-Security über ihre eigene Convenience priorisieren.

Das Ziel ist nicht perfekte Einhaltung einer Timeline. Das Ziel ist, Vulnerabilities gefixt zu bekommen, bevor sie exploited werden, während Forscher respektvoll behandelt werden. Manchmal dauert das 45 Tage, manchmal 120 Tage. Die Timeline ist ein Tool, um sicherzustellen, dass Progress passiert, nicht ein Selbstzweck.