Ein Projekt muss offensichtlich die Möglichkeit habem Meldungen über Sicherheitslücken von jedem zu bekommen. Die gewöhnlichen Adressen für Bug-Meldungen reichen aber nicht aus, da sie auch von jedem beobachtet werden können. Führen Sie desshalb einen getrennten Mailverteiler um Bug-Meldungen über Sicherheitslücken zu bekommen. Dieser Verteiler darf keine öffentlich zugänglichen Archive haben, und seine Anmeldungen müssen strengstens überwacht werden – nur langjährige, vertrauenswürdige Entwickler dürfen auf den Verteiler sein. Wenn Sie eine formale Definition darüber haben wollen was "vertrauenswürdig" ist, können Sie "jeder der seit zwei oder mehr Jahren commit Zugriff hat" verwenden, um Bevorzugung zu vermeiden. Das ist die Gruppe die Sicherheitslücken handhaben wird.

Im Idealfall sollte der Sicherheits-Verteiler nicht vor Spam geschützt oder moderiert werden, da Sie nicht wollen, dass eine wichtige Meldung gefiltert oder verzögert wird, nur weil an dem Wochenende keine Moderatoren online waren. Wenn Sie doch Software zum automatischen Schutz vor Spam benutzen, versuchen Sie es mit einer hohen Toleranz zu konfigurieren; es ist besser ein paar Spam-Mails durchkommen zu lassen, als eine Meldung zu verpassen. Damit der Verteiler effektiv ist, müssen Sie natürlich seine Adresse bewerben; in anbetracht, dass er nicht moderiert wird, wenn überhaupt, nur leicht vor Spam geschützt wird, versuchen Sie nie seine Adresse ohne irgend eine Art verschleierung der Adresse zu verbreiten, wie in „Verschleierung von Adressen im Archiv“ im Kapitel Kapitel 3, Technische Infrastruktur beschrieben. Glücklicherweise, muss die Verschleierung der Adresse sie nicht unbedingt unleserlich machen; siehe http://subversion.tigris.org/security.html, und schauen Sie sich den HTML Quellcode für die Seite als Beispiel an.

Was macht der sicherheits Verteiler also wenn es eine Meldung bekommt? Die erste Aufgabe ist zu evaluieren wie schwerwiegend und dringend es ist:

Man merke an, dass die Unteschiede von denen wir hier reden oft nur eine enge Spanne zwischen dringend und extrem dringend ist. Selbst wenn die Meldung von einer bekannten, wohl gesinnten Quelle kommt, könnte es immer noch andere im Netz geben, die diesen Bug schon vor langem entdeckt haben, und es nur nicht gemeldet haben. Der einzige Fall bei dem es nicht dringen ist, ist wenn der Bug von sich aus die Sicherheit nicht ernsthaft Kompromitiert.

Das "anonyer@globalehacker.net" Beispiel ist im übrigen nicht schertzhaft gemeint. Es kann durchaus sein, dass Sie Bug-Meldungen von anonymen Personen bekommen, die mit Ihren Worten nie ganz klar stellen ob sie auf Ihrer Seite sind oder nicht. Es macht keinen Unterschied: Wenn Sie eine Sicherheitslücke an Sie gemeldet haben, werden sie das gefühl haben Ihenen eine Gefallen getan zu haben, und Sie sollten entsprechend antworten. Danken Sie ihnen für die Meldung, geben Sie ein Datum an vor dem Sie vorhaben einen öffentlichen Fix freizugeben, und halten Sie sie den Kontakt. Manchmal werden sie Ihnen ein Datum geben – das heißt, eine implizite Drohung den Bug an einem bestimmten Datum bekannt zu geben, ob Sie bereit sind oder nicht. Das mag sich nach einschüchterndem Machtspiel anfühlen, aber es ist wahrscheinlich eher eine vorsorgliche Maßnahme die sich aus vergangener Enttäschung mit nicht reagierenden Software-Produzenten, welche die Sicherheitsmeldungen nicht ernst genug nahmen. In jedem Fall, können Sie es sich nicht leisten, dieser Person auf die Nerven zu gehen. Wenn der Bug ernst ist, hat er schließlich Wissen, welches Ihren Nutzern ernste Probleme bereiten könnte. Behandeln Sie solche Personen gut, und hoffen Sie darauf, dass sie auch gut behandelt werden.

Eine weitere Person die häufig Bugs meldet, ist der Sicherheitsprofi, jemand der davon lebt, Code zu überprüfen und sich auf dem Laufenden über die neusten Software-Schwachstellen hält. Diese Leute haben für gewöhnlich Erfahrung mit beiden Seiten des Zauns – sie haben sowohl Meldungen gemacht als auch bekommen, wahrscheinlich mehr als die meisten in Ihrem Projekt. Auch sie werden wahrscheinlich ein Frist setzen, vor dem eine Lücke geschlossen werden muss, vor sie an die öffentlichkeit gehen. Die Frist mag etwas verhandelbar sei, das hängt aber vom Meldenden ab; Fristen sind unter Sicherheitsexperten so ziemlich als die einzige Möglichkeit anerkannt worden, Organisationen zuverlässig dazu zu bringen, sich um Sicherheitsprobleme zeitnah zu kümmern. Betrachten Sie die Frist also nicht als unhöflich, sie ist eine altehrwürdige Tradition und es gibt gute Gründe dafür.

Sobald Sie wissen wie schwerwiegend und dringend eine Lücke ist, können Sie sich an dem Fix zu schaffen machen. Es gibt manchmal einen Kompromiss zwischen einen eleganten Fix und es schnell zu machen; das ist der Grund warum Sie sich vorher über die Dringlichkeit einigen müssen vor Sie anfangen. Halten Sie die Diskussion über den Fix natürlich auf die Mitglieder des Sicherheitsverteilers beschränkt, sowie auf den ursprünglichen Meldenden (wenn die beteiligt sein möchte) und solche Entwickler die aus technischen Gründen herangezogen werden müssen.

Committen Sie den Fix nicht zum Projektarchiv. Halten Sie ihn als Patch bereit bis zum Datum der Bekanntgabe. Wenn Sie es committen würden, selbst mit einem unscheinbaren Kommentar, könnte jemand die Änderung bemerken und verstehen. Sie wissen nie, wer Ihr Projektarchiv im Auge behält und warum sie vielleicht interesiert sein könnten. Commit-E-Mails abzuschalten würde nichts bringen; erstens weil sich die Lücke in der Reihe der E-Mails verdächtig aussehen würde, und die Daten wären immer noch im Projektarchiv. Machen Sie einfach die ganze Entwicklung in einem Patch und halten Sie ihn an einem privaten Ort, vielleicht ein getrenntes privates Projektarchiv, das nur denjenigen bekannt ist, die schon über den Bug Bescheid wissen. (Wenn Sie eine dezentralisierte Versionsverwaltung benutzen wie Arch oder SVK, können Sie die Arbeit mit kompletter Versionsverwaltung machen und dieses Projektarchiv einfach vorm Zugriff für Ausenstehende schützen.)

Sie haben vielleicht eine CAN-Nummer oder eine CVE-Nummer im Zusammenhang mit Sicherheitsproblemen gesehen. Diese Zahlen sehen für gewöhnlich zum Beispiel so "CAN-2004-0397" oder so "CVE-2002-0092" aus.

Beide Zahlenarten repräsentieren den gleichen Entitätstyp: Ein Eintrag in der Liste von "Common Vulnerabilities and Exposures" (de. "Verbreitete Schwachstellen und Aufdeckungen") die bei http://cve.mitre.org/ gepflegt wird. Der Sinn dieser Liste ist es standardisierte Namen für alle bekannte Sicherheitsprobleme zur verfügung zu stellen, damit jeder einen eindeutigen, kanonischen Namen bei der Diskussion eines solchen hat, und einen zentralen Ort zu haben, um mehr Informationen zu bekommen. Der einzige Unterschied zwischen einer "CAN"-Nummer und einer "CVE"-Nummer ist, dass erstere einen Kandidaten-Eintrag repräsentiert, welches noch nichtbestätigt wurde, und letzteres einen bestätigten Eintrag repräsentiert. Beide Typen sind jedoch für die Öffentlichkeit sichtbar, und die Nummer für einen Eintrag ändert sich nicht, wenn Sie bestätigt wird – der "CAN"-Prefix wird einfach mit "CVE" ersetzt.

Ein CAN/CVE-Eintrag entält selber nicht eine vollständige Beschreibung von dem Bug und wie Sie sich vor ihm schützen. Stattdessen, enthält es eine kurze Beschreibung und eine Liste von Verweisen auf externe Ressourcen (wie die Archive des Verteilers) wo Leute detalliertere Infomationen nachschlagen können. Der wirkliche Sinn von http://cve.mitre.org/ ist einen wohl organisierten Ort zu haben, in dem jede Schwachstelle einen Namen haben und eine klare Route zu weiteren Daten haben kann. Siehe http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 als Beispiel für einen Eintrag. Beachten Sie, dass Verweise sehr kurz gehalten sein können, mit Quellen die als kryptische Abkürzungen erscheinen. Ein Schlüssel zu diesen Abkürzungen befindet sich bei http://cve.mitre.org/cve/refs/refkey.html.

Wenn Ihre Schwachstelle die Kriterien für ein CVE erfüllt, kann es sein, dass Sie dafür eine CAN-Nummer bekommen wollen. Der Prozess dafür ist absichtlich umständlich gehalten: Im Prinzip müssen Sie jemanden kennen, oder jemanden kennen der jemand anderen kennt. Das ist nicht so verrückt wie es sich anhören mag. Damit die CVE-Redaktion es vermeiden kann von unechten oder schlecht geschriebenen Vorschlägen überwältigt wird, nehmen Sie nur Vorschläge von Quellen, die sie bereits kennen und denen Sie vertrauen. Damit Ihre Lücke in der Liste aufgenommen wird, müssen Sie desshalb einen Pfad von Bekanntschaften von Ihrem Projekt hin zu der CVE-Redaktion finden. Fragen Sie bei Ihren Entwicklern nach; einer von Ihnen wird wahrscheinlich jemand anderen kennen der bereits durch den CAN-Prozess gelaufen ist, oder der jemand kennt der es gemacht hat, usw. Der Vorteil dieser Methode ist auch, das irgendwo in der Kette jemand sein kann, der genug weiß, um Ihnen sagen zu können, dass a) es nicht als Lücke oder Aufdeckung nach den Kriterien von MITRE zählen würde, es also keinen Sinn hat es vorzuschlagen, oder b) dass die Lücke bereits eine CAN- oder CVE-Nummer hat. Letzteres kann passieren, wenn der Bug bereits auf einer andern Liste für Sicherheitsberatung veröffentlicht wurde, zum Beispiel bei http://www.cert.org/ oder auf dem BugTraq-Mailverteiler bei http://www.securityfocus.com/. (Wenn das passiert ist, ohne das Ihr Projekt davon erfahren hat, dann sollten Sie sich sorgen machen, was noch möglicherweise abläuft worüber Sie nichts wissen.)

Wenn Sie überhaupt eine CAN/CVE-Nummer bekommen, werden Sie sie wahrscheinlich im frühen Stadium Ihrer Bug-Untersuchung bekommen, damit alle weitere Kommunikation sich auf diese Nummer beziehen kann. CAN-Einträge stehen unter einem Embargo bis zu dem Veröffentlichungsdatum; Der Eintrag wird als leerer Platzhalter existieren (damit Sie den Namen nicht verlieren), es wird aber keine Informationen über die Lücke enthüllen, bist zu dem Datum an dem Sie den Bug und den Fix bekanntgeben.

Weitere Informatione über den CAN/CVE-Prozess kann bei http://cve.mitre.org/about/candidates.html gefunden werden, und eine besonders klare Darstellung von dem Nutzen eines Open-Source-Projekts der CAN/CVE-Nummern befindet sich auf http://www.debian.org/security/cve-compatibility.

Sobald Ihr Sicherheitsteam (also die Entwickler die auf dem sicherheits Verteiler sind, oder die zu einer bestimmten Meldung herangezogen wurden) eine Fix bereit hat, müssen Sie entscheiden wie Sie es Verbreiten wollen.

Wenn Sie den Fix einfach zu Ihrem Projektarchiv committen, oder sonstwie der Welt bekanntgeben, zwingen Sie effektiv alle die Ihre Software benutzen sofort zu aktualisieren oder das Risiko einzugehen, gehackt zu werden. Es ist deshalb manchmal angemessen, für bestimmte Nutzer eine Vorankündigung zu machen. Das gilt insbesondere bei Client-Server-Software, bei dem es wenige wohl bekannte Server geben kann, die verlockende Ziele für Angreifer sind. Die Administratoren dieser Server wären dankbar darüber einen zusetzlichen Tag oder zwei für die Aktualisierung zu haben, damit Sie bereits geschützt sind, wenn die Lücke öffentlich bekannt wird.

Vorankündigung bedeutet lediglich eine E-Mail an diese Administratoren zu senden, vor dem Veröffentlichungsdatum, in dem Sie ihnen über die Lücke bescheid geben und wie sie es beheben können. Sie sollten eine Vorankündigung nur an Personen schicken, die Sie diese diskrete Information anvertrauen können. Die Qualifikation um eine Vorankündigung zu erhalten hat also zwei Bedingungen: Der Empfänger muss eine große Installation in Betrieb haben, wichtige Server bei dem eine Kompromitierung etwas ernstes wäre, und der Empfänger muss jemanden sein, der sich über das Sicherheitsproblem vor dem Veröffentlichungsdatum verplappert.

Senden Sie jede E-Mail mit einer Vorankündigung einzeln (eines nach dem anderen) an jedem Empfänger. Senden Sie nicht an die komplette Liste von Empfängern auf ein mal, da sie dann ihre gegenseitigen Namen sehen würden – was zur Folge hat, dass Sie im Grunde genommen jedem Empfänger über die Tatsache aufmerksam machen, dass jeder andere Empfänger möglicherweise die Sicherheitslücke auf seinem Empfänger hat. Es an alle mittels einem blinden CC (BCC) zu schicken ist auch keine gute Lösung, da manche Administratoren ihre Mail-Konten mit Spam-Filtern schützen, die entweder BCC-Mails blockieren, oder ihre Priorität reduzieren, da heutzutage sehr viel Spam mit BCC verschickt wird.

Hier ist ein Beispiel E-Mail für eine Vorankündigung:

Von: Ihr Name hier
An: admin@grosser-bekannter-server.de
Antwort-an: Ihr Name hier (nicht die Adresse des Sicherheitsverteilers)
Betreff: Vertrauliche Meldung einer Scanly-Sicherheitslücke.


Diese E-Mail ist eine vertrauliche Vorankündigung einer 
Sicherheitsmeldung zum Scanley-Server.

Bitte leiten Sie keinen Teil dieser E-Mail an irgend jemand weiter. Die
öffentliche Bekanntgabe wird nicht vor dem 19. Mai stattfinden, und
wir würden die Information gerne bis dann unter Verschluss halten.

Sie erhalten diese E-Mail, da (wir denken, dass) Sie einen Scanley-Server
betreiben, und wir ihn lieber gepatcht hätten, bevor die Sicherheitslücke
am 19ten Mai bekannt gegeben wird.

Verweise:
===========

   CAN-2004-1771: Scanley Speicherüberlauf in Abfragen

Sicherheitslücke:
==============

   Der Server kann dazu gebracht werden, beliebige Befehle auszuführen,
   wenn die Locale des Servers falsch konfiguriert ist und der Client
   eine fehlerhafte Abfrage macht.

Sicherheitsgrad:
=========

   Sehr ernst, kann die Ausführung von beliebigen Code auf dem Server
   zur Folge haben.

Provisorische Lösungen:
============

   Die 'natural-language-processing'-Einstellung in der 
   scanley.conf auf 'off' zu stellen, schließt die Sicherheitslücke.

Patch:
======

   Der folgende Patch gilt für Scanley 3.0, 3.1, und 3.2.

   Eine neu Version (Scanley 3.2.1) wird am oder kurz vor dem 19. Mai
   veröffentlicht werden, damit es zur gleichen Zeit verfügbar istm wie
   die Bekanntgabe der Lücke. Sie können dem Patch jetzt anwenden oder
   einfach auf die neue Version warten. Der einzige Unterschied 
   zwischen 3.2 und 3.2.1 wird diese Patch sein.

[...Patch folgt hier...]

Wenn Sie eine CAN-Nummer haben, geben Sie sie bei der Vorankündigung mit an (wie oben gezeigt), selbst wenn die Information unter Verschluss steht und die MITRE Seite desshalb leer sein wird. Die CAN-Nummer erlaubt es dem Empfänger mit sicherheit zu wissen, dass der Bug über den sie eine Vorankündigung bekommen haben, der gleiche ist von dem sie später durch öffentliche Kanäle erfahren, also müssen sie sich keine Sorgen darüber machen, ob weitere Schritte notwendig sind, was genau der Sinn einer CAN/CVE-Nummer ist.

Der letzte Schritt bei der Handhabung einer Sicherheitslücke, ist den fix öffentlich zu verteilen. Sie sollten in einer einzigen, umfangreichen Meldung, das Problem beschreiben, die CAN/CVE-Nummer angeben, falls vorhanden, beschreiben wie das Problem zu umgehen ist, und wie es permanent 'gefixed' werden kann. 'Fix' bedeutet für gewöhnlich auf eine neuere Version der Software zu aktualisieren, obwohl es manchmal die Anwendung von einem Patch bedeuten kann, insbesondere wenn die Software sowieso meistens vom Quellcode-Format aus betrieben wird. Wenn Sie doch eine neue Version machen, sollte es sich von einer existierenden Version durch genau diesen sicherheits-Patch unterscheiden. So können konservative Administratoren, aktualisieren, ohne sich sorgen zu machen, was sie noch beeinflussen könnten; sie müssen sich also keine Sorgen über zukünftige Upgrades machen, da der sicherheits Patch als Folge in allen zukünftigen Versionen enthalten sein wird. (Details der Abläufe für neue Versionen werden in „Sicherheitsupdates“ im Kapitel Kapitel 7, Paket-Erstellung, Veröffentlichung, und tägliche Entwicklung behandelt.)

Ob der öffentliche Fix eine neue Version zur Folge hat oder nicht, machen Sie die Meldung mit ungefähr der der gleichen Priorität wie Sie eine neue Version machen würden: Senden Sie eine E-Mail an den announce Verteiler des Projekts, machen Sie eine neue Pressemitteilung, aktualisieren Sie den Freshmeat-Eintrag, usw. Während Sie nie versuchen sollten, die Existenz einer Sicherheitslücke herunterzuspielen, aus Sorge um den Ruf des Projekts, können Sie durchaus den Ton und die Gewichtung der Sicherheitsmeldung anpassen, um den Ernst des Problems zu entsprechen. Wenn die Sicherheitslücke nur eine kleine Offenlegung von Informationen ist, nicht eine Lücke die es erlaubt den kompletten Computer des Anwenders zu übernehmen, mag es keinen all zu großen Wirbel gerechtfertigen. Sie können sich sogar Entscheiden den announce Verteiler damit abzulenken. Wenn das Projekt schließlich jedes mal Wolf schreit, werden sich die Nutzer denken, dass die Software weniger sicher ist, als das tatsächlich der Fall ist, und es möglicherweise nicht glauben wenn Sie wirklich ein riesiges Problem ankündigen müssen. Siehe http://cve.mitre.org/about/terminology.html als eine gute Einführung zu dem Problem der Beurteilung wie schwerwiegend eine Sicherheitslücke ist.

Im Allgemeinen, wenn Sie sich nicht sicher sind, wie Sie ein Sicherheitsproblem behandeln sollen, suchen Sie sich jemand Erfahrenen und reden Sie darüber. Lücken zu handhaben und zu bewerten, ist größtenteils eine angelernte Fähigkeit und es ist leicht, die ersten paar Male Fehler zu machen.