Ein deutsches Advisory-Format

Ordnungsmerkmale

erschienen in: <kes> 2004^#5, Seite 68

Zusammenfassung: Enge Zusammenarbeit bei der Erstellung und Verarbeitung von Security Advisories benötigt eine homogene Grundlage. Kernstück einer hierzu entstehenden deutschen Infrasturktur ist das Deutsche Advisory-Format (DAF): ein speziell auf die Belange der hiesigen CERT-Landschaft zugeschnittenes Austauschformat für Sicherheitsbulletins.

Autor: Von Bernd Grobauer, München, und Jürgen Sander, Hamburg

Mit jeder neuen Sicherheitslücke in einer populäreren Anwendung oder einem Betriebssystem beginnt bei vielen Computer Emergency Response Teams (CERTs) dasselbe Spiel: Informationen sammeln, das mit einer Schwachstelle verbundene Risiko abschätzen und Patches testen. Schließlich erstellt jedes CERTs ein Security Advisory mit den für die eigene Klientel relevanten Informationen und verteilt es. Wegen der konstant hohen Schwachstellenzahl benötigt die Erstellung von Security Advisories inzwischen deutlich mehr Arbeit als noch vor einigen Jahren; eine detaillierte Analyse von Schwachstellen und Gegenmaßnahmen bleibt dabei oft zwangsläufig auf der Strecke. Diese Defizite bei der Analyse ließen sich verringern, wenn CERTs bei der Advisory-Erstellung durch eine engere Kooperation weniger Aufwand betreiben müssten.

Eine Unterstützung der täglichen CERT-Arbeit oder gar Arbeitsteilung zwischen den Teams kann man durch einen gelegentlichen Informationsaustausch jedoch nicht erreichen. Dazu ist ein regelmäßiger und strukturierter Austausch erforderlich, der ähnliche Prozesse, gemeinsame Datenformate und eine geeignete Infrastruktur voraussetzt. Momentan verwenden aber fast alle CERTs ihr eigenes Advisory-Format. Dabei sind die Inhalte von Advisories verschiedener Teams meist sehr ähnlich, Unterschiede ergeben sich hingegen beispielsweise in der Ausführlichkeit der dargestellten Informationen, der Bewertungsskala für das Schwachstellenrisiko sowie den Kriterien und Regeln, die zur Risikobewertung herangezogen werden.

Mit dem bloßen Austausch von Security Advisories wäre also nichts gewonnen – Quellen dafür gibt es ohnehin genug. Der Austausch proprietärer Formate ist eine Sackgasse, die keine nähere Zusammenarbeit zulässt: Ein effizienter Austausch von Entwürfen oder die Nachbearbeitung fremder Advisories für die Veröffentlichung an die eigene Klientel ist nur über ein gemeinsames Austauschformat möglich. Im Rahmen des Deutschen CERT-Verbundes werden daher jetzt die Grundlagen für eine enge Kooperation deutscher CERTs bei der Erstellung von Security Advisories geschaffen. Kernstück ist ein gemeinsames Austauschformat, das Deutsche Advisory-Format (DAF,  www.cert-verbund.de/daf/), das derzeit CERT-Bund (BSI), DFN-CERT, PreSecure und Siemens-CERT entwickeln und pflegen.

Das DAF hat seinen Ursprung im European Security Promotion Programme (EISPP,  www.eispp.org), einem EU-geförderten Forschungsprogramm, an dem vier CERTs und zwei Sicherheitsorganisationen aus Deutschland, Frankreich, Italien, Schweden und Spanien teilnahmen. EISPP lief von Juni 2002 bis Januar 2004; unter anderem wurde ein standardisiertes Austauschformat für Advisories entwickelt und im Praxisbetrieb getestet. Derzeit nutzen interantional fünf Teams dieses Format im produktiven Einsatz.

Die Entwicklung des EISPP-Formates erfolgte unter der Federführung des Siemens CERT, das auch als Schnittstelle zwischen dem EISPP-Konsortium und dem Deutschen CERT-Verbund fungierte; bei der Überarbeitung des EISPP-Formates zur aktuellen Version 2.0 ab September 2003 war der Deutsche CERT-Verbund bereits eng einbezogen. In die Entwicklung des EISPP-Formats sind die Erfahrungen der an EISPP teilnehmenden CERTs, Feedback von europäischen und besonders auch deutschen CERTs sowie Best-Practice-Empfehlungen zum Thema Advisories eingeflossen.

Das EISPP-Format ist sehr mächtig und flexibel, was jedoch zwangsläufig zu großen Spielräumen bei der Verwendung führt. Da für eine enge Zusammenarbeit genauere Vereinbarungen nützlich sind, erarbeiten deutsche CERTs mit dem DAF derzeit ein auf ihre Bedürfnisse zugeschnittenes Profil des EISPP-Formats. Dabei bleibt einerseits die Nähe zur europäischen Entwicklung gewahrt, andererseits kann man bestehende Freiräume zur Anpassung an spezielle Bedürfnisse nutzen.

Darstellungs- und Datenebene

Das EISPP-Format ist auf XML-Basis definiert: Eine XML Data Type Definition beschreibt die Syntax gültiger DAF-Advisories. Eine ausführliche Formatbeschreibung erklärt zudem die Verwendung des Formats und erläutert seine Semantik. Motivation für die Verwendung von XML war zum einen die Möglichkeit, XML-Standards und -Werkzeuge einsetzen zu können. Weiterhin ist hierdurch möglich, Datenebene und Darstellungsebene zu trennen. Dadurch muss der XML-Code eines DAF-Advisory allerdings für den Leser erst aufbereitet werden, was zunächst als Nachteil erscheinen mag, da ein zusätzlicher Bearbeitungsschritt nötig ist.

In der Praxis erweist sich diese Trennung jedoch schnell als klarer Vorteil, zumal die Aufbereitung durch XML-Standardmechanismen wie XSLT-Stylesheets erfolgen kann: Das DAF dient als Container für alle wesentlichen Daten, aus denen man die jeweils relevanten Daten zur Darstellung extrahieren kann, um für unterschiedliche Lesergruppen speziell zugeschnittene Versionen zu generieren. Ein weiterer wesentlicher Vorteil der Trennung von Daten- und Darstellungsebene ist die Möglichkeit, bestimmte Daten in maschinenlesbarer Form vorhalten zu können: Dies ist Voraussetzung für eine weitgehende Werkzeugunterstützung bei der Erstellung und beim Austausch von Advisories.

Schwachstellenbewertung

Als Grundlage für die Bewertung von Schwachstellen dienen Informationen über ihren Status, die Art der Ausnutzung, die hierdurch erzielbare Wirkung sowie Angriffsvoraussetzungen (vgl. Abb.).

Das Deutsche Advisory-Format (DAF) nutzt ein zweistufiges Bewertungsschema für Schwachstellen.

Status der Schwachstelle

Schwachstellen durchlaufen eine Art Lebenszyklus: Fehler, die möglicherweise eine Schwachstelle bedeuten, werden entdeckt, als tatsächliche Schwachstelle bestätigt, Tools zur Ausnutzung der Schwachstelle veröffentlicht (Exploits) und so weiter. Das DAF führt die zur Risikobewertung wesentlichen Stationen in diesem Lebenszyklus auf.

Art der Ausnutzung

Die Ausnutzung einer Schwachstelle kann manuell, automatisiert oder durch selbstreplizierenden Code erfolgen. Bei der manuellen Ausnutzung muss der Angreifer nicht-automatisierbare Schritte ausführen, um den Angriff auf die Gegebenheiten des Ziels anzupassen. Automatisierte Angriffe ermöglichen es hingegen, die Schwachstelle "auf Knopfdruck" zu nutzen. Würmer oder so genannte Bots führen schließlich selbstreplizierende Angriffe aus: Ein erfolgreich attackiertes System wird übernommen und greift dann seinerseits weitere Systeme an.

Auswirkung

Zur Angabe des Effekts, den man durch das Ausnutzen einer Schwachstelle erreichen kann, berücksichtigt das DAF, welche Sicherheitsziele verletzt werden können (z. B. Vertraulichkeit von Daten). Zusätzlich geht ein, in welchem Kontext die Verletzung von Sicherheitszielen möglich ist: bezogen auf eine Person, einen Service, ein komplettes System oder gar ein ganzes Netzwerk.

Angriffsvoraussetzungen

Bei den Angriffsvoraussetzungen unterscheidet das DAF zwischen lokalen Angriffen und solchen, die sich auch über das Netz durchführen lassen. Von Bedeutung ist zudem, ob der Angriff eine Interaktion des Opfers voraussetzt: Muss es zum Beispiel eine speziell präparierte E-Mail öffnen? Oder ist ein besonderer Netzzugriff erforderlich, um beispielsweise Pakete zu "sniffen" oder zu manipulieren?

Dringlichkeit

Aus dem Status der Schwachstelle und der Art ihrer Ausnutzung kann man die so genannte Dringlichkeit (auch Eintrittspotenzial genannt) zur Ergreifung von Gegenmaßnahmen ableiten: Eine automatisierte Schwachstelle, für die bereits Exploit-Code öffentlich verfügbar ist, muss beispielsweise dringender behandelt werden als eine mögliche Schwachstelle, die aller Voraussicht nach nur manuell auszunutzen wäre.

Schadenspotenzial

Die Dringlichkeit gibt das DAF auf einer Skala von sehr hoch bis sehr niedrig an. Diese Skala dient auch zur Bewertung des Schadenspotenzials. Zu dessen Ableitung schlägt das DAF eine Zuordnung vor, die sich bislang in den meisten Fällen bewährt hat: Eine Schwachstelle, durch die ein Benutzer von einem Service ausgesperrt werden kann, erhält beispielsweise ein sehr geringes Schadenspotenzial zugeordnet – ist es dagegen möglich, über ein komplettes System die Kontrolle zu erlangen, so ist das Schadenspotenzial sehr hoch.

Aktuelles Schadenspotenzial

Dringlichkeit und Schadenspotenzial werden im so genannten aktuellen Schadenspotenzial zusammengeführt, das über die zum Zeitpunkt der Bewertung ausgehende Gefahr Auskunft gibt. Dabei sind jedoch noch keine lokalen Begebenheiten berücksichtigt: Mit dem aktuellen Schadenspotenzial führt das DAF eine Messgröße ein, bei der alle das Schema anwendenden CERTs im Idealfall zum gleichen Ergebnis kommen sollten.

Unter Berücksichtigung der Angriffsvoraussetzungen kann dann jedes Team die Wahrscheinlichkeit für einen erfolgreichen Angriff auf die eigene Klientel abschätzen: Die Kombination von aktuellem Schadenspotenzial und dieser Wahrscheinlichkeit ergibt dann eine Risikoeinschätzung speziell für den eigenen Kundenkreis.

Ein solcher zweistufiger Prozess zur Schwachstellenbewertung, bei dem klientelspezifische Faktoren im ersten Schritt ausgeklammert werden, ist Grundvoraussetzung für die Zusammenarbeit von CERTs, da sich ausschließlich klientel-unabhängige Einschätzungen zum Austausch eignen. So kann ein CERT die Ergebnisse anderer Teams übernehmen oder zur Qualitätskontrolle mit der eigenen Einschätzung vergleichen. Unterschiede können darauf hindeuten, dass eines der CERTs eventuell Fakten übersehen oder in ihrer Bedeutung falsch eingeschätzt hat. Das DAF-Bewertungsschema für Schwachstellen hat sich in der Zusammenarbeit zwischen dem DFN CERT und dem Siemens-CERT bereits bewährt.

Perspektiven

Das DAF wird derzeit in Deutschland von DFN-CERT und Siemens-CERT produktiv eingesetzt. Beide Teams haben jeweils schon mehrere hundert Advisories im EISPP/DAF-Format geschrieben. Bei beiden CERTs zeigte sich durch den Umstieg auf das neue Format eine spürbare Qualitätssteigerung: Zum einen hat die Verwendung eines wohldefinierten Formats zu einer Angleichung der von verschiedenen Autoren desselben Teams geschriebenen Advisories geführt.

Zum anderen ergaben sich durch die Trennung von Daten- und Darstellungsebene Verbesserungen bei der Handhabung der Advisories. So nutzt beispielsweise das Siemens-CERT, das Advisories auf Deutsch und Englisch herausgibt, die Möglichkeit, mehrere Sprachversionen in einem DAF-Advisory vorzuhalten, was die Wartung wesentlich vereinfacht. Das DFN-CERT hat eine Schwachstellendatenbank mit seinem Advisory-System gekoppelt, sodass sich Schwachstellenbeschreibungen jetzt zwischen diesen beidem Datenbanken einfach austauschen lassen.

In absehbarer Zeit dürfte die Zahl deutscher CERTs, die das DAF verwenden, deutlich ansteigen: Auf der SYSTEMS 2004 stellt das CERT-Bund ( www.bsi.de/certbund/) ein Vorfallbearbeitungssystem (VBS) vor, das als Open-Source-Software allen Interessenten kostenlos zur Verfügung steht . Neben der für die Vorfallsbearbeitung nützlichen Trouble-Ticket-Funktionen bietet das VBS unter anderem auch Unterstützung zur Erstellung und Pflege von DAF-Advisories. Damit ermöglicht es erstmals die Verwendung von EISPP/DAF, ohne dass nennenswerte Eigenentwicklungen nötig wären. Die Chancen stehen also gut, dass sich die im Rahmen des deutschen CERT-Verbunds begonnene Zusammenarbeit von DFN- und Siemens-CERT bald auf weitere Teams ausweitet.

CERTs oder Hersteller, die das Deutsche Advisory-Format (DAF) einsetzen möchten, finden die Spezifikationen und weiterführende Informationen auf der DAF-Homepage unter  www.cert-verbund.de/daf/. Ein Umstieg auf DAF kann auch schrittweise erfolgen, indem man zunächst eine reduzierte Version von DAF verwendet. Die DAF-Beschreibung gibt hierzu entsprechende Empfehlungen.

Dr. Bernd Grobauer ist Senior Consultant beim CERT der Siemens AG. Jürgen Sander ist Senior Consultant bei der PRESECURE Consulting GmbH

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004^#5, Seite 68