Deutsches Advisory Format - Homepage
In den letzten Jahren haben deutsche CERTs aktiv daran gearbeitet, engere Kontakte zueinander zu knüpfen und Möglichkeiten zur verbindlichen Zusammenarbeit zu finden. Eine Konsquenz dieser Bestrebungen war die Gründung des Deutschen CERT Verbunds. Im Rahmen des CERT Verbundes werden derzeit in verschiedenen Projekten die Grundlagen für eine enge Kooperation deutscher CERTs geschaffen.
Kernstück einer Infrastruktur zur gemeinsamen Erstellung und Verarbeitung von Security Advisories ist das Deutsche Advisory Format (DAF), ein speziell auf die Belange der deutschen CERT-Landschaft zugeschnittenes Austauschformat für Security Advisories, welches von CERT-Bund, DFN-CERT, PRESECURE und Siemens-CERT entwickelt und gepflegt wird.
Die Zielsetzungen bei der Kooperation auf dem Gebiet der Security Advisories sind folgende:
- Verbesserung der Qualität der Meldungen
- Qualitätssicherung
- Entwicklung eines Modells für Systeminformationen
- Etablierung gemeinsamer Bewertungsmaßstäbe
- Freisetzung von Ressourcen zur Verbesserung der Analysefähigkeit
Ursprünge und Ziel des Projektes
DAF hat seinen Ursprung im European Security Promotion Programme (EISPP), einem EU-geförderten Forschungsprogramm an welchem vier CERTs und zwei Sicherheitsorganisationen aus Deutschland, Frankreich, Italien, Schweden und Spanien teilnahmen. In diesem Forschungsrogramm wurde unter anderem ein standardisiertes Advisory-Austauschformat entwickelt und im Praxisbetrieb getestet. Die Federführung bei der Entwicklung des EISPP-Formates oblag dem Siemens CERT, welches auch als Schnittstelle zwischen dem EISPP Konsortium und dem Deutschen CERT-Verbund fungierte, welcher bei der Überarbeitung des EISPP-Formates zur aktuellen Version 2.0 ab September 2003 eng eingebunden war.
Die hohe Flexibilität des EISPP-Formats ermöglicht einerseits große Freiräume bei der Verwendung des Formates, andererseits können diese Spielräme für eine enge Kooperation von CERTs auch kontraproduktiv sein. Mit dem DAF schaffen sich deutsche CERTs ein auf ihre Bedürfnisse zugeschnittenes Profil des EISPP-Formates, zum einen durch eine gemeinsame Interpretation von Bewertungsschemen, zum anderen durch nützliche Erweiterungen des EISPP-Formates. Gleichzeitig wird sichergestellt, daß ein Austausch von Daten zwischen dem EISPP-Format und DAF jederzeit möglich ist.
Weiterführende Informationen
Eine ausführliche Beschreibung des DAF-Profils und dessen Besonderheiten sind auf den folgenden Seiten zu finden:
- Format-Inhalte
- Daten- und Darstellungsebene
- Klassifizierungsschema für Schwachstellen
- System Informationen
Eine vollständige Beschreibung des DAF-Formats in englischer Sprache ist auf der folgenden Seite zu finden:
ToC |
Formatbeschreibung
Format-Inhalte
In die Entwicklung des EISPP-Formats flossen neben Best-Practice-Empfehlungen natürlich die Erfahrungen und Anforderungen der an EISPP teilnehmenden CERTs ein. Aber auch nicht am Projekt beteiligte CERTs lieferten im Rahmen von FIRST und TF-CSIRT konstruktiven Feedback. Auch die deutschen CERTs haben ihre Vorstellungen eingebracht, die sich letztendlich in DAF manifestieren. Die Inhalte von EISPP/DAF gliedern sich wie folgt:
- Identifikationsdaten
Jedes Advisory muß eindeutig identifizierbar sein. Dazu dienen Angaben über den Herausgeber, Seriennummer und Ausgabedatum sowie der Advisory-Titel. Identifikationsdaten werden oft auch dazu verwendet, einen Überblick über aktuelle Advisories in Form einer Liste z.B. auf einer Webseite zu geben: dazu können die Daten direkt aus dem DAF-Advisory bzw. seiner Datenbank-Repräsentation extrahiert werden.
- Entstehungsdaten
Werden zu einer Schwachstelle neue Fakten bekannt, so veralten u.U. die in einem bereits veröffentlichten Advisory angegeben Daten. Wird das Advisory angepaßt, so sollte eine Versionsliste Auskunft darüber geben, welche Änderungen vorgenommen wurden. Wird dagegen ein neues Advisory veröffentlicht, so sollte sowohl das alte als auch das neue Advisory aufeinander verweisen und den Leser über die Beziehung zwischen beiden Advisories informieren. So kann ein altes Advisory von einem neuen Advisory z.B. ergänzt oder für veraltet erklärt werden. DAF enthält sowohl eine Versionsliste als auch einen Mechanismus zur Angabe von Relationen zwischen Advisories desselben Herausgebers.
- Systeminformationen
Der erste Blick eines Administrators auf ein neues Advisory gilt normalerweise der Information darüber, welche Systeme betroffen sind: bei welchen Kombinationen von Betriebssystem und Anwendungssoftware tritt die Schwachstelle auf? Ist keines der betroffenen Systeme in Betrieb, so ist das Advisory irrelevant und muß nicht weiter beachtet werden. Systeminformationen werden deswegen oft als Basis für die Angabe von Benutzerprofilen verwendet, so daß Advisories zu nicht relevanten Systemen ausgefiltert werden können.
Das EISPP-Format enthält Standardfelder zur Angabe von Systeminformationen, allerdings wird kein Standardmodell zur konsistenten Angabe von maschinenlesbaren Informationen vorgegeben. Im Rahmen von DAF wird ein derartiges Modell entwickelt, so daß Benutzerprofile und darauf basierende Filtermechanismen herausgeberübergreifend verwendet werden können. Dieses Modell wird in einem gesonderten Kapitel genauer beschrieben. - Schwachstellenbewertung
Auch nachdem die nicht relevanten Advisories aussortiert sind, bleiben meist noch mehr als genug Advisories übrig. Bei der Priorisierung der zu bearbeitenden Advisories hilft dem Leser die vom Advisory-Herausgeber vorgenommene Schwachstellenbewertung, die im Idealfall als Risikoeinschätzung, z.B. auf einer Skala von "sehr hoch" bis "niedrig", für die Schwachstelle zusammengefaßt ist. DAF beinhaltet ein praxiserprobtes Bewertungsschema, welches sich auch in der Zusammenarbeit zwischen CERTs bewährt hat. Dieses Schema wird in einem gesonderten Abschnitt genauer beschrieben.
- Schwachstellenbeschreibung
Mit der Schwachstellenbeschreibung sollen dem Leser die für ihn relevanten Informationen über die Schwachstelle mitgeteilt werden. Je nach Kenntnisstand und Interesse der intendierten Leserschaft müssen dabei u.U. selbst einfachste Sachverhalte erklärt werden ("Was ist ein Webserver?"), oder aber -- bei einer sehr versierten Lesernschaft -- selbst technische Details über die Hintergründe der Schwachstelle erläutert werden. DAF bietet die Möglichkeit, Textblöcke in der Beschreibung mit maschinenlesbaren Markierungen zu versehen, die Auskunft über den Textinhalt geben (z.B. "Technische Grundlagen", "Diagnose-Informationen", "Technische Details"). Diese Markierungen unterstützen einerseits die Zusammenarbeit zwischen CERTs, da Textblöcke schnell zugeordnet werden können, und ermöglichen andererseits die Generierung verschiedener Advisory-Informationen aus einem DAF Advisory. So könnten z.B. für weniger versierte Leser die Textblöcke mit Detailinformationen weggelassen werden.
- Problembehebung
Essentieller Bestandteil eines jeden Advisories sind Informationen darüber, wie das durch eine Schwachstelle verursachte Problem behoben werden kann. Oft erfolgt die Problembehebung durch Einspielen eines Patches, einem Software-Upgrade oder -- falls der Hersteller des betroffenen Produktes noch nicht reagiert hat -- einem Workaround der zumindest das Risiko verringert, daß die Schwachstelle ausgenutzt werden kann. DAF erlaubt es, mehrere Lösungsansätze anzugeben, die z.B. nach betroffenen Systemen strukturiert werden können. Dies ist insbesondere dann nützlich, wenn im Advisory gleich Links zu Patches angegeben werden, welche sich im Normalfall von System zu System unterscheiden.
- Referenzen
Gibt es zu einer Schwachstelle ein Hersteller-Advisory, so sollte dieses in einem Advisory eines anderen Herausgebers bzgl. derselben Schwachstelle referenziert werden. Dafür, sowie für Verweise auf weitere Informationsquellen, bietet DAF die Möglichkeit, Referenzen in maschinenlesbarer Form anzugeben; auch Standardidentifikatoren für Schwachstellen wie CVE-Nummern werden in DAF in maschinenlesbarer Form festgehalten. Wie schon erwähnt können damit DAF-Advisories verschiedener Hersteller zur selben Schwachstelle einander automatisch zugeordnet werden. Für die Darstellung des Advisories können aus den maschinenlesbaren Informationen zudem oftmals Links automatisch generiert werden; ändert sich die Lage von Hersteller-Advisories z.B. durch Strukturänderungen auf einem Webserver, so genügt eine Änderung im Darstellungsmechanismus anstatt jedes einzelne Advisory anzupassen.
ToC |
Daten- und Darstellungsebene
Die grundsätzliche Anforderung an ein Austauschformat ist die "maschinelle Verarbeitbarkeit". Dazu müssen aber die Daten in einer Form vorgehalten werden, so dass diese effizient durch Programme extrahiert und verarbeitet werden können, nur so wird eine weitgehende Werkzeugunterstützung bei der Erstellung und dem Austausch von Meldungen möglich. Die Syntax und Semantik eines Formats muss daher wohl definiert sein.
Aus diesem Grund ist EISPP auf XML-Basis definiert. Die Syntax eines gültigen EISPP-Advisories wird mittels einer XML Data Type Definition (DTD) vorgegeben, die Semantik eines DAF-Advisories ist derdetaillierten Formatbeschreibung zu entnehmen. Durch die Verwendung von XML erfolgt eine Trennung der Datenebene und der Darstellungsebene, d.h. der eine EISPP/DAF Meldung beschreibende XML-Code muss erst für den Leser aufbereitet werden. Dies mag zunächst als Nachteil erscheinen, da schließlich ein weiterer Bearbeitungsschritt notwendig ist.
In der Praxis ergeben sich durch diese Trennung jedoch klare Vorteile. Eine im DAF-Format erstellte Nachricht dient als Container für alle wesentlichen Daten, aus denen dann die jeweils relevanten Daten zur Darstellung extrahiert werden können. Dadurch ist es möglich, verschiedene Versionen eines Advisories zu generieren, die speziell auf die jeweiligen Bedürfnisse einer Zielgruppe zugeschnitten sind. Hier müssen u.a. Personengruppen betrachtet werden, die sich durch Funktion, Tätigkeit oder aufgrund der Tiefe des technischen Fachwissens voneinander unterscheiden. Darüber hinaus können durch das Format auch gleichzeitig verschiedene Sprachversionen realisiert werden.
ToC |
Klassifizierungsschema für Schwachstellen
Im folgenden wird das Klassifizierungsschema zur Schwachstellenbewertung etwas näher beschrieben werden; der Abbildung 1 ist die schematische Darstellung des Schemas zu entnehmen. Eine gemeinsame Bewertung des Risikos einer Schwachstelle durch eine Gruppe von kooperierenden CERTs kann nur von allgemeiner Natur sein, da die die lokalen Gegebenheiten der Zielgruppe in den meisten Fällen von CERT zu CERT unterschiedlich sein werden. Aus diesem Grund wird in DAF ein zweistufiger Prozess zur Schwachstellenbewertung verwendet. Im ersten Schritt werden deshalb die klientelspezifischen Faktoren ausgeklammert. In dieser Phase kann z.B. ein CERT eine vorgenommen Einschätzung eines anderen CERTs übernehmen oder zur Qualitätskontrolle mit eignen Bewertungen vergleichen. Unterschiede in der Einschätzung des aktuellen Schadenspotentials sind ein Indikator, dass eventuell Fakten übersehen oder in ihrer Bedeutung falsch eingeschätzt wurden. Erst in einem zweiten Schritt kann dann die allgemeine Bewertung mit den klientelspezifischen Faktoren zusammengeführt werden, um dem Empfänger einer Sicherheitsmeldung die Einstufung zu erleichtern. Als Grundlage für die Bewertung von Schwachstellen dienen Informationen über den Status einer Schwachstelle, Art der Ausnutzung, die durch die Ausnutzung erzielbare Schadenswirkung sowie Angriffsvoraussetzungen.
Abbildung 1 : Klassifizierungsschema für Schwachstellen
Das DAF Bewertungsschema für Schwachstellen hat sich in der Zusammenarbeit zwischen dem DFN-CERT und dem Siemens-CERT bewährt. Auf die erste Stufe dieses Schemas wird in den nächsten Abschnitten detaillierter eingegangen, die exemplarische Umsetzung der zweiten Stufe ist Beispielen zu entnehmen.
Ermittlung des Eintrittspotenzials
Schwachstellen durchlaufen eine Art Lebenszyklus. DAF identifiziert vier Stationen in diesem Lebenszyklus die für eine Risikobewertung von Bedeutung sind. DAF unterscheidet hinsichtlich des Status einer Schwachstelle die folgenden Stationen:
- theoretisch
Es wird z.B. ein (Programmier-)Fehler entdeckt, der eventuell zu einem Sicherheitsloch führen kann. - ausnutzbar
Erfolgt ein Proof of Concept einer Sicherheitslücke, so spricht DAF von einer ausnutzbaren Schwachstelle. - aktiv
Gibt es Anzeichen dafür, dass die Schwachstelle bereits ausgenutzt (z.B. wenn ein exploit verfügbar ist) wird, so handelt es sich um eine aktive Schwachstelle. - exploit veröffentlicht
Der GAU tritt ein, wenn für die Schwachstelle ein Angriffstool veröffentlicht wird, so dass selbst unbedarfte Hacker Angriffe starten können, wird von einer Schwachstelle mit veröffentlichem Exploit gesprochen.
Abbildung 2 : Lebenszyklus einer Schwachstelle
Bei der Art der Ausnutzung wird differenziert, ob die Ausnutzung einer Schwachstelle entweder manuell, automatisiert oder selbstreplizierend erfolgt. Bei der manuellen Ausnutzung muss der Angreifer nicht-automatisierbare Schritte ausführen, um den Angriff auf die Gegebenheiten des Angriffsziels anzupassen. Automatisierte Angriffe hingegen erlauben es, dass eine Schwachstelle sozusagen auf Knopfdruck ausgenutzt werden kann. Selbstreplizierende Angriffe schließlich können z.B. durch Wurmprogramme und Bots durchgeführt werden, die nach einem erfolgreichen Angriff ein System übernehmen bzw. nutzen, um darüber weitere Systeme anzugreifen.
Das Eintrittspotenzial (Dringlichkeit) wird dabei auf einer Skala von sehr gering bis sehr hoch angegeben. Diese Skala findet ebenso bei der Bewertung des Schadenspotenzials oder des Risikos Anwendung. Die folgende Tabelle zeigt einen Überblick über die verschiedenen Kombinationen und enthält Vorschläge zur Ermittlung der Dringlichkeit bzw. des Eintrittspotenzials einer Schwachstelle.
Eintrittspotenzial | Verbreitungsmethode | ||
Status der Schwachstelle | manuell | automatisch | replizierend |
theoretisch | sehr gering | gering | mittel |
ausnutzbar | gering | mittel | hoch |
aktiv | mittel | hoch | hoch |
Exploit veröffentlicht | mittel | hoch | sehr hoch |
Ermittlung des Schadenspotenzials
Die Bewertung des Schadenspotentials erfolgt auf Grundlage des Effekts, der durch Ausnutzung einer Schwachstelle erreicht werden kann. Die notwendigen Angriffsvoraussetzungen für ein erfolgreiches Ausnutzen einer Sicherheitslücke werden bei dieser Herangehensweise als gegeben (worst case - Ansatz) angesehen. Zur Angabe des Effekts, betrachtet DAF, welche Sicherheitsziele verletzt werden können und in welchem Kontext dies geschehen kann. Neben den häufig aus der Literatur bekannten Sicherheitszielen: Integrität, Vertraulichkeit und Verfügbarkeit werden Verletzungen in Bezug auf die Systemkontrolle (teilweise oder vollständige Kontrolle durch einen Angreifer) sowie der Umgehung von Sicherheitsdiensten -- z.B. durch das Außerkraftsetzen einer Firewall -- erweitert. Der Kontext kann sich auf folgendes beziehen:
- Person (Benutzer)
- Dienst (Anwendung)
- IT-System
- Netzwerk
Die folgende Tabelle gibt einen Überblick über die verschiedenen Kombinationen und enthält Vorschläge zur Ermittlung des allgemeinen Schadenspotenzials.
Schadenspotenzial | Kontext | |||
Verlust | Benutzer | Dienst | System | Netzwerk |
Übernahme der Kontrolle | hoch | hoch | sehr hoch | sehr hoch |
Übernahme von Berechtigungen | mittel | mittel | hoch | hoch |
Integrität | gering | mittel | hoch | hoch |
Vertraulichkeit | sehr gering | gering | mittel | hoch |
Verfügbarkeit | sehr gering | gering | mittel | hoch |
Umgehung von Sicherheitsmaßnahmen | sehr gering | gering | mittel | hoch |
Ermittlung des aktuellen Eintrittspotenzials
Das aktuelle Schadenspotenzial enthält eine generelle Einschätzung der Bedrohung, die sich durch das Ausnutzen einer Schwachstelle ergeben kann. In Publikationen von anderen CERTs werden zur Darstellung des Sachverhalts u.a. auch die Begriffe allgemeines Risiko oder Bedrohung benutzt. Die Bewertung ergibt sich aus der Kombination der Werte für "Eintrittspotential" und "Schadenspotential".
aktuelles Schadenspotenzial | Schadenspotenzial | ||||
Eintrittspotenzial | sehr gering | gering | mittel | hoch | sehr hoch |
sehr gering | sehr gering | sehr gering | gering | gering | mittel |
gering | sehr gering | gering | gering | mittel | hoch |
mittel | gering | gering | mittel | hoch | hoch |
hoch | gering | mittel | hoch | hoch | sehr hoch |
sehr hoch | mittel | hoch | hoch | sehr hoch | sehr hoch |
Ermittlung des Risikos
Liegen einem CERT detaillierte Informationen über die örtlichen Gegebenheiten beim Empfänger einer Sicherheitsmeldung vor, kann eine Bewertung des Risikos erfolgen. Unter Berücksichtigung der Angriffsvoraussetzungen und der eingesetzten IT-Systeme kann die Wahrscheinlichkeit für einen erfolgreichen Angriff beim Empfänger abgeschätzt werden. Zusammen mit der durch DAF eingeführten Messgröße -- aktuelles Schadenspotenzial -- kann das spezifische Risiko, bezogen auf eine Schwachstelle, abgeleitet werden.
Auch für die zweite Bewertungsstufe unterstützt DAF den kooperierenden Ansatz. Zur Beurteilung der Angriffsvoraussetzungen wurde ein Kriterienkatalog und zur Beschreibung von IT-Systemen ein Modell erarbeitet. Bei den Angriffsvoraussetzungen unterscheidet DAF zwischen lokalen Angriffen und solchen, die über ein Netzwerk durchgeführt werden können. Jeweils unterteilt danach, ob der Angreifer ein Login oder Benutzerkennung, einen physikalischen Zugang zum System oder keines von beiden benötigt. Manche Angriffe setzen eine Interaktion eines Benutzers auf dem Zielsystem voraus (z.B. das Öffnen einer präparierten E-Mail), während für andere Angriffe ein Zugriff auf das Netzwerk erforderlich ist, indem sich das Zielsystem befindet, z.B. um Packete zu sniffen oder gar zu manipulieren.
ToC |
Modell für Systeminformationen
Um eine effiziente Zusammenarbeit zwischen CERTs zu ermöglichen, wurde für DAF auch ein Modell für die Beschreibung von IT-Systemen (Betriebssysteme und Anwendungen) definiert. Dadurch wird es möglich, auch Informationen über IT-Systeme in DAF-Advisories automatisch zu verarbeiten und Sicherheitsmeldungen anhand von genauen Benutzerprofilen zu verteilen. Die Spezifikation dieses Modells ist zum gegenwärtigen Zeitpunkt zwar grundsätzlich abgeschlossen, jedoch nicht der Aufbau einer Datenbank, in der alle aktuellen IT-Systeme enthalten sind.
Die Systemkategorisierung wird unterteilt in einen Kategoriebereich und einem Produktbereich. Der Kategoriebereich ist hierarchisch aufgebaut und fasst in verschiedenen Ebenen verwandte Produkte zusammen. Wesentlich für den Produktbereich ist die Standardisierung des Namensraums für Produktkategorien.
Eine detaillierte Beschreibung des Modells findet sich auf der CMSI Homepage.