Damit Vulnerabilities vergleichbar werden, haben mehrere Hersteller das »Common Vulnerability Scoring System« (CVSS) entwickelt. Als unabhängiger Risikoindex angedacht, bezieht er die Zusammensetzung des Unternehmensnetzes mit ein, um die Gefahr für diese individuelle Struktur zu bewerten.

Mit Cisco, ISS, Microsoft, Qualys und Symantec haben sich bereits mehrere Schwergewichte im Sicherheitsbereich der CVSS-Idee verpflichtet.

Derzeit gibt es von Vulnerabilities viel zuviel. In zu vielen Produkten, zu vielen Applikationen, zu viel Ursprüngen und Informationsquellen. Ein Wirrwarr, Durcheinander, ein gefährlicher Dschungel, der jeden an den Rand des Wahnsinns treibt, der in diesem Wildwuchs den Durchblick behalten will. Aber was bleibt den Sicherheitsverantwortlichen anderes übrig, als sich durch alle diese Informationen zu quälen? Natürlich helfen ihm einige Plattformen, seien es unabhängige Bugtraq-Listen, das CERT oder SANS-Institut. Auch einige kommerzielle Dienstleister wie Patchlink oder Qualys unterstützen ihn, indem sie gefundene Schwächen zusammenfassen und dokumentieren. Aber können diese Quellen erahnen oder gar wissen, ob die als riskant eingestufte Vulnerability in dem eigenen Netzwerk mit der völlig individuellen Zusammenstellung von Soft- und Hardware ähnlich gefährlich ist wie im Netz des Herrn Mustermann gegenüber? Und sind ihre Angaben nicht immer noch zu internetzentrisch, ihre Bewertungen nicht vergleichbar?

Es bliebe dann noch die Möglichkeit, den Herstellern zu vertrauen, ihnen und ihrer Risikowertung. Ein großer Kraftakt, will man bei allen wichtigen und weniger wichtigen Produkten im Netz verfolgen, was die jeweiligen Anbieter herausgeben. Leider auch ein unzureichender Ausweg, da auf ihm zwei wichtige Antworten nicht zu finden sind: ist diese Schwäche im eigenen Netz tatsächlich so riskant, wie der Hersteller meint? Wie lassen sich die Risiko-Angaben zweier Hersteller gegeneinander abwägen? Denn nur dann weiß der Administrator, wo er den Hebel zuerst anzusetzen, welche Schwäche er als allererste zu beseitigen hat, weil sie für ihn und seine wichtigsten Prozesse im Netz das größte Risiko darstellen.

Das ist heutzutage eine der wichtigsten Aufgaben, da Angriffe, in welcher Form auch immer, sich gezielt gegen die Vulnerabilities richten. Schwächen, die gerade erst bekannt wurden und gegen die in kürzester Zeit Angriffsverfahren entwickelt werden. Diese Frist zwischen Publizierung und Attacke ist immens geschrumpft. Lag sie vor zwei Jahren noch bei mehr als einem Monat, ist sie heute auf wenige Tage geschwunden. Einige Antiviren-Hersteller erwarten, dass sie auf einen Tag, ja auf wenige Stunden oder Minuten zusammenschmilzt. Auch wenn diese extremen Bedingungen nicht eintreffen, so bleibt Reaktionszeit der wichtigste Faktor in diesem Wettlauf. Wer sich zu spät über relevante Schwächen informiert oder Zeit mit unwichtigeren Patches verliert, senkt unmittelbar das Sicherheitsniveau seiner kritischen Infrastruktur. Auch die unzureichende Informationspolitik der Hersteller und fehlende Vergleichswerte haben direkten Einfluss auf die Effizienz und den Wirkungsgrad künftiger Angriffe. Das hat zwar auch schon früher zugetroffen, nur sind die Folgen heutzutage auf Grund der globalen Natur und Geschwindigkeit der Wurmattacken viel größer.

Die Situation ist absolut unbefriedigend und gefährlich. Daher hat die amerikanische Regierung, verkörpert in dem »National Infrastructure Advisory Council« (NIAC), schon im Jahr 2003 ein Projekt ins Leben gerufen, das ein globales Framework für die Veröffentlichung von Security-Vulnerabilities schaffen will. Das Niac ist Bestandteil des »Department of Homeland Security«, eine nach den Terrorangriffen auf New York neu geschaffene Institution, die solchen Attacken innerhalb der Vereinigten Staaten vorbeugend entgegenwirken soll. Das Department wird getrieben von der Sorge, dass auch Informationssysteme in kritischen Bereichen wie den Banken-, Transport- oder Energiesektor Ziel von Angriffen werden könnte. Sie haben vor allem Vulnerabilities als wunden Punkt in diesen Bereichen ausgemacht.

Übergreifender Risikoindex

Als Ergebnis ihres Projekts wurde auf der diesjährigen RSA-Konferenz im Februar in San Fransisco das »Common Vulnerability Scoring System« (CVSS) vorgestellt. Dieses Rating-System legt einheitliche, plattformübergreifend geltende Maßstäbe für das Risikopotenzial aufgedeckter Vulnerabilities fest. In die Bewertung sollen nicht nur externe Faktoren einfließen, sondern auch eigene, vom Administrator festgelegte Kriterien. Dazu definiert CVSS mathematische Schemata, die der Verantwortliche eigenen Bedürfnissen anpasst. So sollen Schwächen nicht nur vergleichbar werden, sondern auch nach internen, individuellen Bedingungen gewichtet sein.

Gestützt und weiterentwickelt wird das CVSS-Konzept derzeit von den Herstellern Cisco, EBay, ISS, Microsoft, Qualys und Symantec. Ebenfalls mit an Bord sind Vertreter des CERT/CC und von MITRE. Letztere ist eine gemeinnützige Organisation im öffentlichen Sektor. Finanziert wird sie unter anderem vom US-amerikanischen Verteidigungsministerium.

Schon während des Roundtables des Security-Forums Ende Januar hat die Idee für Skepsis unter den Teilnehmern gesorgt. Soll man Herstellern trauen? Wie wirkt es, wenn Konkurrenten kooperieren? Dieser Index kann doch nicht unabhängig sein, da er von Herstellerinteressen getrieben wird. Am Ende wollen diese doch nur neue Produkte verkaufen. Dass dieser Index auf letzteren Punkt ebenfalls hinausläuft, ist zwangsläufig. Das Engagement soll sich auch finanziell rechnen, alles andere wäre naiv gedacht.

Fakt bleibt, dass dieser Index eine klaffende Lücke schließen könnte. Eine Lücke, die vollkommen unabhängige Institutionen wie das »Bundesamt für Sicherheit in der Informationstechnik« noch nicht einmal zu lösen versuchen. Wenn dieses Rating-System bewirkt, dass nur eine Attacke weniger gravierend ausfällt, weil einige Unternehmen gezielter und damit rechtzeitig Vulnerabilities beseitigten, wäre jedem Internet-gebundenen Unternehmen und Privatanwender schon geholfen.

Dabei haben sich die Hersteller dazu verpflichtet, den CVSS-Standard offen und frei verfügbar zu halten. Er soll interoperabel, flexibel, leicht zu verstehen und zu implementieren sein. Vergleichbar mit dem »Common Vulnerabilities and Exposures«-Standard (CVE), der Standardkennungen für Software-Schwächen festlegt und übrigens auch von MITRE betreut wird. Das neue Rating-System soll die CVE-Datenbank natürlich einpflegen.

Definitionsfragen

Wer die Grundlage für einen Risikoindex legen möchte, muss erst einmal definieren, was er unter Risiko und Vulnerability versteht. Die Study-Group der CVSS hat sich zu diesem Zweck an den Vorgaben im »Vulnerability Disclosure Framework«-Bericht orientiert, den das Niac im Januar 2004 vorlegte. Dieser Bericht erklärt: Eine Schwäche ist festgelegt als mehrere Bedingungen, unter denen implizit oder explizit die Vertraulichkeit, Integrität und/oder Verfügbarkeit eines Informationssystems gefährdet werden. Daraus ergeben sich ungewollte oder unerwartete Effekte, die auf den Opfersystemen geschehen. Hier nur einige Beispiele:

• Es werden Befehle unter anderem Usernamen ausgeführt,

• Datenzugriffe sind möglich, die über bestehende Rechte hinausreichen,

• Ein User kann sich als anderer User oder Dienst innerhalb eines Systems ausgeben,

• einen abnormen Denial-of-Service verursachen,

• Daten absichtlich oder unabsichtlich, aber unwiederbringbar zerstören sowie

• eine Schwäche im Verschlüsselungsprozess ausnutzen, um die Berechnung des Chiffrier-Keys und damit den Schlüsselbruch zu beschleunigen.

Die Ursachen der Vulnerabilities sind zahlreich und durchaus verschieden. Design-Fehler in Soft- und Hardware, aber auch verpfuschte administrative Prozesse oder mangelndes Risikobewusstsein lassen Schwächen in der Abwehrarchitektur entstehen. Genauso verursacht mangelndes Wissen im Bereich der IT-Sicherheit gefährliche Konfigurationsfehler. Auch sie fallen unter die Kategorie Vulnerability. Weniger bekannt ist, dass technologische Fortschritte und Verbesserungen bestehender Praktiken genauso zu Schwächen führen können, falls sie die Gegenseite als Grundlage für Angriffe auf kritische Informationssysteme missbrauchen könnten. Wenn die bestehende Software beispielsweise weitere Webdienste unterstützt, die völlig neue Wege öffnen, sie zu attackieren, erzeugt dieses Update Risiken.

Alle diese Faktoren soll der CVSS-Index abbilden, damit er Informationssystem-Schwächen adäquat beschreibt. Was die verantwortliche Study-Group aber ausklammert, sind einige externe Gefahrenfaktoren. Dazu gehören Abhängigkeiten zwischen Schwächen. Einige Vulnerabilities lassen sich nur dann ausnutzen, wenn vorher ein anderer Fehler missbraucht wurde. Wenn beispielsweise eine verwundbare Applikation hinter einer fehlerhaft aufgesetzten Firewall platziert ist, so wird die augenscheinliche Anfälligkeit der Firewall den Risikoindex für die Applikation keineswegs in die Höhe treiben. Unabhängig ob die Firewall löchrig oder stringent eingestellt ist und den Exploit gegen die bekannte Applikationsschwäche daher aufhält, der Risikoindex für die Anwendung bleibt gleich.

Der CVSS-Index besitzt auch keine Kapazitäten, um das Angriffspotenzial bekannter und neuer Exploits einzuberechnen, die sich gegen einen bereits bekannten Fehler richten. Diese Faktoren ändern sich laufend, da Angreifer neue Tricks und Tools entwickeln und ihre Angriffsverfahren verfeinern. Diesen Bereich muss aus Sicht der CVSS-Study-Goup ein anderes Instrument, ein anderer Index abdecken. Es ist außerdem bisher nicht geplant, eine Datenbank mit den CVSS-Werten aufzusetzen und sie zu aktualisieren. Das wäre insofern auch wenig logisch, da der Anwender die externen Festlegungen immer um seine persönlich bestimmten Faktoren ergänzen soll. Dadurch wird der Risiko-Grundwert im Einzelfall absolut abgeschwächt oder gesteigert, so dass allgemeine Datenbankinformationen am eigentlichen Sinn vorbeizielen würden.

Der bisher angedachte Risikoindex ist metrisch aufgebaut und setzt sich aus einzelnen Komponenten oder Charakteristika zusammen, die sich quantitativ und qualitativ messen lassen. Diese Werte sind in drei große Gruppen aufgeteilt: »base« (grundlegend), »temporal« und »environmental« (umgebungsabhängig). Für jede dieser Gruppen gelten bestimmte Regeln. Die Basisgruppe enthält Werte, die für eine bestimmte Schwäche gültig sind und – ganz wichtig – sich über Zeit oder in anderen Umgebungen nicht verändern. Die Temporal-Gruppe dagegen enthält alle Charakterzüge einer Schwäche, die zeitabhängig sind und sich mit ihrem Alter verändern. Die der Umgebungsgruppe schließlich lassen die individuellen Rahmenbedingungen des Unternehmensnetzes in die Kalkulation einfließen. Der endgültige CVSS-Wert gibt das Risiko einer Schwäche an, wie es zu einer gewissen Zeit in einem spezifischen Netzwerkzustand bestand.

Basisgruppe

Sobald eine Schwäche komplett analysiert und katalogisiert ist, bleiben einige ihrer Aspekte über die Zeit konstant. Diese unveränderbaren Eigenschaften sind vor allem in den »Access-« und »Impact«-Bereichen zu finden. In den Letzteren fällt, inwieweit die Schwäche die Vertraulichkeit und Integrität der Daten auf dem Opfersystem korrumpiert. Wie stark mindert sie die Verfügbarkeit der Daten? Wie massiv hebt sie die Rechte auf und schaltet den Zugriff auf sensible Daten frei, obwohl diese nur autorisierte Anwender sehen dürfen? Erlaubt die Schwäche gar, dass unautorisierte User Daten modifizieren, wohlmöglich unbemerkt?

Unter dem Access-Wert ist angelegt, wie die Wunde im System zu erreichen ist. Darunter fällt einmal der Access-Vektor, also wie die Schwäche zu erreichen ist. Muss der Angreifer sich lokal Zugang verschaffen, sei es, indem er physisch vor Ort ist, oder kann er auch remote über das Web-Interface auf die Schwäche zugreifen? In diese Access-Kalkulation gehört auch die Access-Komplexität. Hier ist wiedergegeben, wie viel Aufwand der Angreifer betreiben muss, um die Schwäche auszunutzen, hat er erst einmal Zugang zum Opfersystem. Muss er Code erst auf die Zielmaschine laden, oder kann er direkt mit Datenfluten einen Buffer-Overflow auslösen?

Als dritter Wert fließt »Authentication« mit in den Access ein. Dieser ist vom Access-Vektor verschieden und geht davon aus, dass der Angreifer bereits Zugang zum Zielsystem hat. Wenn eine Authentifizierung nötig ist, um die Vulnerability auszunutzen, wird auf Grund des hohen Aufwands der Risikowert des Access insgesamt gesenkt. Bei niedrigem Aufwand ohne Authentifizierung gilt natürlich das Gegenteil.

Zeit und Umgebung

Eine Schwäche altert und verändert im Laufe der Zeit einige ihrer Charakterzüge. Es ist typisch, dass die Zahl potenzieller Opfersysteme auf ihrem Höhepunkt ist, wenn eine Schwäche erstmals publik wird. Die Zahl der Exploits und die Menge der Gegenmaßnahmen sind zu diesem Zeitpunkt im gesamten Lebenszyklus der Vulnerability nahezu auf ihrem niedrigsten Niveau. Im Verlauf verschiebt sich das Bild natürlich. Denn die ersten Patches werden entwickelt und reparieren die ersten Systeme, so dass die Zahl potenzieller Opfer sinkt. In gleichem Maße aber steigt das Risiko, weil die Menge der Werkzeuge wächst, die auf diese Schwäche angesetzt sind. Die temporale Gruppe soll genau diesen Wandel widerspiegeln. Sie kalkuliert dieses zeitabhängige Risiko mit den Werten »Exploitability« (Angreifbarkeit) und »Remediation« (Gegenmaßnahmen).

Alle diese bisherigen Faktoren können bei jeder Netzstruktur anders gewichtet sein. In der einen ist der Access-Vektor und somit das Risiko insgesamt niedrig, weil sich die eine Schwäche nur lokal ausführen lässt. In der anderen ist die gleiche Schwäche auf einer der wichtigsten Produktionsmaschinen aufgetaucht, die zudem per Webservice ans Internet gekoppelt ist. Das Risiko ist hier also viel höher.

Daher will es CVSS dem Administrator möglich machen, seine höchsteigenen Bedingungen einfließen zu lassen. Dazu hat die Study-Group in der Umgebungsmatrix oder »Environmental Metrics« zwei grundlegende Bereiche definiert.

Der »Collateral Damage«-Wert gibt an, wie hoch das Schadenspotenzial der Schwäche in dem jeweiligen Netz ist. Darunter fallen finanzielle, physikalische und personelle Verluste. Hierein sollte auch fließen, inwieweit die Reputation des Unternehmens leidet, sobald diese Schwäche auf dem kritischen System tatsächlich ausgenutzt wird. Diese Werte sind absichtlich recht breit angelegt, damit ein individueller Anwender sie an die jeweiligen Rahmenbedingungen anpassen kann.

Der Wert »Target Distribution« gibt die Zahl der Systeme an, die wohlmöglich von dieser Vulnerability betroffen sind. Er soll als netzwerkspezifischer Indikator fungieren, der die Prozentzahl der geschwächten Systeme wiedergibt.

Pragmatische Anwendung

Die CVSS-Study-Group möchte dabei die Verantwortung für die Grunddefinitionen gerne einer unabhängigen Organisation anvertrauen. Dazu hat sie das Niac aufgefordert, eine entsprechende Vereinigung zu finden. Diese gewünschte Organisation soll die CVSS-Matrizen und Formulare, in denen die Werte eingetragen werden, auf globaler Ebene betreuen.

Der angedachte Prozess soll wie folgt funktionieren: Der Hersteller der Hard- oder Software erkennt die Schwäche oder wird über sie informiert. Er trägt im nächsten Schritt die Basiswerte in einem standardisierten Formular ein, für das die unabhängige Organisation verantwortlich ist. Sicherheitsdienstleister und andere -Spezialisten tragen ihrerseits die temporalen Werte ein, indem sie permanent die aktuelle Situation im Internet beobachten. Somit ist der aktuelle Bedrohungsstatus der Vulnerability akkurat, da möglichst alle Exploits berücksichtigt sind. Der Anwender selbst definiert in seinem CVSS-Werkzeug, das er natürlich kaufen muss, seine eigene Netzwerk-Policy. Sie fließt bei jeder neuen Vulnerability, die seinem Werkzeug gemeldet wird, automatisch ein. Sie gewichtet und filtert auch Meldungen heraus, die für das Netzwerk irrelevant sind, weil die betroffene Plattform dort nicht implementiert ist.

Die Basis- und Temporal-Berechnung ist bei der neu gemeldeten Schwäche bereits erfolgt und wird nur mit den netzwerkspezifischen Parametern neu kalkuliert. Am Ende soll geklärt sein, ob und wie riskant die Vulnerability für das Unternehmen ist. Unabhängig davon, ob die Schwäche neu erkannt wurde oder ein aggressiveres Angriffswerkzeug ihr Gefahrenpotenzial erhöht hat.

Damit der CVSS-Index eine Chance auf Erfolg hat, müssen die meisten Soft- und Hardware-Hersteller sich dazu entschließen, ihn zu unterstützen. Und es muss eine Organisation gefunden werden, die vertrauenswürdig und unabhängig genug für diese Aufgabe ist. Die an der Study-Group beteiligten Hersteller haben sich bereits dazu bekannt, diesen Risikoindex zu unterstützen. Angesichts ihres Marktgewichts hat CVSS durchaus eine Chance. [ pm ]