DE10249428B4

DE10249428B4 - Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems

Info

Publication number: DE10249428B4
Application number: DE10249428A
Authority: DE
Inventors: George S. Plano Gales; Richard L. Schertz; Richard P. Tarquini; Craig D. Anderson
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2001-10-31
Filing date: 2002-10-23
Publication date: 2005-01-27
Anticipated expiration: 2022-10-24
Also published as: GB0224532D0; DE10249428A1; GB2385168A; US20030135749A1

Abstract

Verfahren zum Definieren der Sicherheitsanfälligkeit eines Computersystems (30), das folgende Schritte umfaßt:
Spezifizieren eines Angriffs, der eine erkannte Anfälligkeit (300) des Computersystems darstellt, über eine Anfälligkeitsbeschreibungssprachen-Datei (VDL-Datei), wobei die VDL-Datei ferner
zumindest eine Eigenschaft des spezifizierten Angriffs (300, 318) spezifiziert;
zumindest eine Taktikdefinition (310, 312, 314) bezüglich des Erfassens der Anfälligkeit des spezifizierten Angriffs spezifiziert; und
eine Abhilfe (300) für die spezifizierte Anfälligkeit spezifiziert.

Description

Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Computersysteme und insbesondere auf ein Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems.
Computersystemsicherheitsthemen sind sehr wichtig geworden, da immer mehr Computer mit Netzwerken und dem Internet verbunden sind. Angriffe auf Computersysteme sind aufgrund der Entwicklung neuer Hacker-Tools zunehmend raffinierter geworden. Unter Verwendung dieser Tools können relativ unerfahrene Angreifer bei organisierten Angriffen auf eine oder mehrere anvisierte Einrichtungen teilnehmen. Verteilte Systemangriffe, wie z. B. Dienstverweigerungsangriffe (denial of service attacks) zielen im allgemeinen auf hunderte oder tausende ungeschützte oder gefährdete Internetknoten.
Ansprechend auf diese raffinierteren Angriffe werden neue Eindringschutz- und -erfassungssysteme entwickelt und entworfen, um Versuche, in Computernetzwerke einzudringen, zu überwachen und zu verhindern. Diese Eindringschutzsysteme haben typischerweise ein gewisses Wissen über bekannte Anfälligkeiten des Systems, das dieselben schützen, und über Eigenschaften bekannter Eindringangriffstools. Dieses Wissen wird typischerweise in einer Produktdokumentation aufgezeichnet oder in Tabellen oder Datenbanken gespeichert, die für jedes System oder Produkt spezifisch sind. Es gibt jedoch kein allgemeines oder Standardformat oder eine solche Darstellung des Wissens, was es für die Benutzer oder Systemadministratoren schwierig macht, auf diese Informationen zuzugreifen und dieselben zu verwenden, und es außerdem den Systementwicklern erschwert, die Informationen zu aktualisieren.

Die WO 01/65330/A2 befasst sich mit einem System zum Erfassen von Netzanwendungsanfälligkeiten. Ein Verfahren zum Erfassen von Sicherheitsanfälligkeiten bei einer Netzanwendung umfasst das Analysieren der Client-Anforderung und der daraus resultierenden Server-Antworten, um vordefinierte Elemente der Anwendungsschnittstelle mit externen Klienten und die Attribute dieser Elemente zu erfassen. Die Klientenanforderungen werden dann basierend auf einem vorderfinierten Satz von Änderungsregeln verändert, um dadurch Netzsummen zu erzeugen, die für die Anwendung einzigartig sind. Die Netzanwendung wird dann unter Verwendung der Nutzungen attackiert, wobei die Ergebnisse der Attacke auf eine anormale Anwendungsaktivität hin ausgewertet werden.

Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren zum Definieren der Sicherheitsanfälligkeit eines Computersystems mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 gelöst.

Bei einem Ausführungsbeispiel der vorliegenden Erfindung umfaßt ein Verfahren zum Definieren von Sicherheitsbedingungen eines Computersystems für den Zweck des Erfassers von Anfälligkeiten die Schritte des Spezifizierens eines Angriffs, der eine erkannte Anfälligkeit des Computersystems spezifiziert, des Spezifizierens zumindest einer Eigenschaft des spezifizierten Angriffs, des Spezifizierens zumindest einer Taktikdefinition bezüglich des Erfassens der Anfälligkeit des spezifizierten Angriffs, des Spezifizierens zumindest einer Eigenschaft der spezifizierten Taktikdefinition und des Spezifizierens einer Abhilfe für die spezifizierte Anfälligkeit.

Bei einem weiteren Ausführungsbeispiel der vorliegenden Erfindung umfaßt ein Verfahren zum Definieren von Anfälligkeitsbedingungen eines Systems gemäß einem vorbestimmten Format für den Zweck des Erfassens von Anfälligkeiten die Schritte des Spezifizierens eines Namens einer Anfälligkeit, die dem System zugeordnet ist, des Spezifizierens zumindest einer Eigenschaft der spezifizierten Anfälligkeit, des Spezifizierens einer Taktikdefinition bezüglich der spezifizierten Anfälligkeit, des Spezifizierens zumindest einer Eigenschaft der spezifizierten Taktikdefinition des Spezifizierens einer Rechenplattform des Systems und des Spezifizierens einer Abhilfe für die Anfälligkeit gemäß der spezifizierten Rechenplattform.

Bei noch einem weiteren Ausführungsbeispiel der vorliegenden Erfindung umfaßt ein System zum Spezifizieren von Anfälligkeiten eines Computersystems eine Anfälligkeitsbeschreibungsdatei, die eine Definition zumindest einer An fälligkeit und eine Definition zumindest eines Taktikelements für die Anfälligkeit enthält. Das System umfaßt ferner einen Interpretierer, der wirksam ist, um die Anfälligkeitsdefinitionen und Taktikelementdefinitionen in der Anfälligkeitsbeschreibungsdatei syntaktisch zu analysieren und die syntaktisch analysierten Definitionen nach einem vorbestimmten Format zu organisieren, und eine Datenspeicherung, die wirksam ist, um die syntaktisch analysierten und organisierten Anfälligkeits- und Taktikelementdefinitionen zu speichern, und durch ein oder mehrere Anfälligkeitsscanneranwendungen zugreifbar ist.

Für ein vollständigeres Verständnis der vorliegenden Erfindung, die Ziele und Vorteile derselben werden nachfolgend bevorzugte Ausführungsbeispiele der vorliegenden Erfindung mit Bezugnahme auf beiliegende Zeichnungen näher erläutert. Es zeigen:
1 ein vereinfachtes Blockdiagramm eines typischen verteilten Angriffs auf ein Computersystem;
2 ein Blockdiagramm eines Computersystems, das Netzwerk-basierte, Host-basierte und Inline-Eindringschutzsysteme verwendet, in denen die vorliegende Erfindung implementiert werden kann;
3 ein vereinfachtes Block- und Datenflußdiagramm eines Ausführungsbeispiels eines Anfälligkeitsbeschreibungssystems gemäß den Lehren der vorliegenden Erfindung; und
4 ein Datenbankdiagramm eines Ausführungsbeispiels einer Anfälligkeitsbeschreibungsdatenbank, die Informationen von einer Anfälligkeitsbeschreibungsdatei der vorliegenden Erfindung speichert.
Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung und dessen Vorteile werden durch Bezugnahme auf 1 bis 4 der Zeichnungen am besten verständlich, wobei gleiche Bezugszeichen für gleiche und entsprechende Teile der verschiedenen Zeichnungen verwendet werden.
1 ist eine vereinfachte Anordnung, die bei verteilten Systemangriffen auf eine Zielmaschine 30 üblich ist. Eine Angreifermaschine 10 kann die Ausführung eines verteilten Angriffs durch eine beliebige Anzahl von Angreiferclientmaschinen 20a bis 20n durch eine beliebige Anzahl von Techniken anzuweisen, wie z. B. eine Fernsteuerung durch „Roboter"-Anwendungen. Clientmaschinen, die auch als „Zombies" und „Angriffsagenten" 20a bis 20n bezeichnet werden, sind im allgemeinen Computer, die für die Öffentlichkeit über das Internet zugänglich sind oder anderweitig auf irgendeine Weise gefährdet sind. Die Clientmaschinen 20a bis 20n können geographisch verteilt sein. Ein verteilter Angriff kann durch einen Befehl, der auf der Angreifermaschine 10 ausgegeben wird, von den Clientmaschinen 20a bis 20b ausgelöst werden. Zahlreiche Typen verteilter Angriffe können gegen eine Zielmaschine 30 gestartet werden, wie z. B. Dienstverweigerungsangriffe. Die Zielmaschine 30 kann von den Angriffen so überlastet werden, daß sie echte Anforderungen nicht mehr bedienen oder auf dieselben antworten kann.
2 ist ein Diagramm eines Ausführungsbeispiels eines umfassenden Eindringschutzsystems (IPS = intrusion protection system), das Netzwerk-basierte, Host-basierte und Inline-Eindringschutzsysteme umfaßt, wie z. B. AttackDefender von der Hewlett-Packard Company. Netzwerk-basierte Eingriffschutzsysteme werden im allgemeinen an oder in der Nähe des Eintrittpunktes oder sogar der Grenze eines Netzwerks eingesetzt, wie z. B. einer Firewall bzw. einer Bandschutzmauer. Netzwerk-basierte Eindringschutzsysteme analysieren Daten, die vom Internet ankommen und sammeln Netzwerkpakete, um dieselben mit einer Datenbank verschiedener bekannter Angriffssignaturen oder Bitstrukturen zu vergleichen. Eine Warnung kann erzeugt und zu einem Verwaltungs system übertragen werden, das eine korrigierende Aktion durchführen kann, wie z. B. das Schließen der Kommunikation auf einem Tor der Brandschutzmauer, um die Lieferung der identifizierten Pakete in das Netzwerk zu verhindern. Netzwerk-basierte Eindringschutzsysteme liefern im allgemeinen eine Echtzeit- oder beinahe Echtzeiterfassung von Angriffen. Somit können Schutzaktionen ausgeführt werden, bevor das anvisierte System beschädigt wird. Ferner sind Netzwerkbasierte Eindringschutzsysteme besonders effektiv, wenn sie auf langsamen Kommunikationsverbindungen, wie z. B. ISDN und T1-Internetverbindungen implementiert sind. Darüber hinaus sind Netzwerk-basierte Eindringschutzsysteme leicht einzusetzen.
Host-basierte Eindringschutzsysteme, die auch als „Protokollwächter" (Log-Watcher) bezeichnet werden, erfassen ein Eindringen typischerweise durch Überwachen von Systemprotokollen. Allgemein befinden sich Host-basierte Eindringsysteme auf dem zu schützenden System. Host-basierte Eindringschutzsysteme erzeugen im allgemeinen weniger „Falsch-Positiv" oder Falschdiagnosen eines Angriffs als Netzwerkbasierte Eindringschutzsysteme. Außerdem können Hostbasierte Eindringschutzsysteme ein Eindringen auf der Anwendungsebene erfassen, wie z. B. die Analyse von Datenbankmaschinenzugriffsversuchen und Änderungen der Systemkonfigurationen. Protokoll-überwachende, Host-basierte Eindringschutzsysteme können im allgemeinen ein Eindringen nicht erfassen, bevor das Eindringen stattgefunden hat, und bieten daher wenig Unterstützung beim Verhindern von Angriffen. Protokoll-überwachende, Host-basierte Eindringschutzsysteme sind typischerweise nicht sinnvoll beim Verhindern von Dienstverweigerungsangriffen, weil diese Angriffe normalerweise ein System auf der Netzwerkschnittstellenkartentreiberebene beeinträchtigen. Da ferner Protokoll-überwachende, Host-basierte Eindringschutzsysteme dafür entworfen sind, einen speziellen Host zu schützen, können viele Typen von Netzwerk-basierten Angriffen nicht erfaßt werden, da derselbe nicht in der Lage ist, Netzwerk verkehr zu überwachen. Ein Host-basiertes Eindringschutzsystem kann durch Verwenden von Betriebssystemanwendungsprogrammschnittstellenhaken zum Verhindern von Eindringversuchen verbessert werden.
Inline-Eindringschutzsysteme umfassen eingebettete Eindringschutzfähigkeiten in dem Protokollstapel des Systems, das geschützt wird. Dementsprechend wird aller Verkehr, der durch das System empfangen wird und von dem System kommt, durch das Inline-Eindringschutzsystem überwacht. Inline-Eindringschutzsysteme überwinden viele der inhärenten Mängel von Netzwerk-basierten Eindringschutzsysteme. Beispielsweise sind Inline-Eindringschutzsysteme effektiv zum Überwachen von Verkehr auf Hochgeschwindigkeitsnetzwerken. Inline-Eindringschutzsysteme sind oft zuverlässiger als Netzwerk-basierte Eindringschutzsysteme, weil aller Verkehr, der für einen Server mit einem Inline-Eindringschutzsystem beabsichtigt ist, durch die Eindringschutzschicht des Protokollstapels verläuft. Außerdem kann ein Angriff verhindert werden, weil ein Inline-Eindringschutzsystem Daten löschen kann, die als einem Angriff zugeordnet identifiziert werden, anstatt die Daten zum Verarbeiten an die Anwendungsschicht weiterzuleiten. Darüber hinaus kann ein Inline-Eindringschutzsystem beim Verhindern von Angriffen wirksam sein, die auf verschlüsselten Netzwerkverbindungen auftreten, weil Inline-Eindringschutzsysteme in dem Protokollstapel bei einer Schicht eingebettet sein können, wo die Daten entschlüsselt wurden. Inline-Eindringschutzsysteme sind auch sinnvoll beim Erfassen und Verhindern, daß ein Gerät als ein Angriffsclient in einem verteilten Angriff verwendet wird, weil sowohl ausgehende als auch eingehende Daten dadurch überwacht werden.
Mit Bezugnahme auf 2 können ein oder mehrere Netzwerke 100 über einen Router 40 oder ein anderes geeignetes Gerät mit dem Internet 50 eine Schnittstelle bilden. Bei dem Netzwerk 100 sind beispielsweise zwei Ethernet-Netzwerke 55 und 56 über den Router 40 mit dem Internet 50 gekoppelt. Das Ethernetnetzwerk 55 umfaßt einen Firewall/Proxy-Server 60, der mit einem Webinhaltserver 61 und einem Dateitransportprotokollinhaltserver 62 gekoppelt ist. Das Ethernetnetzwerk 56 umfaßt einen Domainnamenserver (DNS = domain name server) 70, der mit einem Mailserver 71, einem Datenbankserver 72 und einem Dateiserver 73 verbunden ist. Die Netzwerk-basierten Eindringschutzsysteme, die bei den zweckgebundenen Vorrichtungen 80 und 81 eingesetzt werden, sind auf zwei Seiten eines Firewall/Proxy-Servers 60 angeordnet, um das Überwachen versuchter Angriffe gegen einen oder mehrere Netzwerkknoten 100 zu ermöglichen, und das Aufzeichnen erfolgreicher Angriffe zu ermöglichen, die den Firewall/Proxy-Server 60 erfolgreich durchdringen. Die Netzwerkeindringschutzgeräte 80 und 81 können jeweils Datenbanken 80a und 81a umfassen (oder alternativ mit denselben verbunden sein), die bekannte Angriffssignaturen enthalten. Dementsprechend kann das Netzwerkeindringschutzgerät 80 alle Pakete überwachen, die von dem Internet 50 eingehen. Gleichartig dazu überwacht und vergleicht das Netzwerkeindringschutzgerät 81 alle Pakete, die den Firewall/Proxy-Server 60 für die Lieferung zu dem Ethernet-Netzwerk 56 durchliefen.
Ein IPS-Verwaltungsknoten 85 kann auch in dem Netzwerk 100 enthalten sein, um die Konfiguration und Verwaltung der Eindringschutzsystemkomponenten zu ermöglichen, die in dem Netzwerk 100 enthalten sind. Bezüglich der Mängel von Host-basierten und Netzwerk-basierten Eindringschutzsystemen können Inline- und/oder Host-basierte Eindringschutzsysteme in jedem der verschiedenen Knoten der Ethernet-Netzwerke 55 und 56 implementiert sein, wie z. B. dem Knoten 85. Zusätzlich kann der Verwaltungsknoten 85 auf die Erfassung eines Eindringereignisses hin Warnungen von jeweiligen Knoten in dem Netzwerk 100 empfangen.
Vorzugsweise sind die Netzwerkeindringschutzgeräte 80 und 81 speziell zugewiesene Einheiten zum Überwachen von Netz werkverkehr auf zugeordneten Verbindungen des Netzwerkes 100. Um einen Eindringschutz in Hochgeschwindigkeitsnetzwerken zu ermöglichen, umfassen die Netzwerkeindringschutzsystemgeräte 80 und 81 vorzugsweise einen großen Aufnahme-RAM (random access memory = Direktzugriffsspeicher), zum Aufnehmen von Paketen, während dieselben an den jeweiligen Ethernet-Netzwerken 55 und 56 ankommen. Zusätzlich ist es vorzuziehen, daß Netzwerkeindringschutzgeräte 80 und 81 jeweils hardwarebasierte Filter zum Filtern von Hochgeschwindigkeitsnetzwerkverkehr umfassen. Die Filter können alternativ in Software implementiert sein, mit einem potentiellen Geschwindigkeitsverlust und entsprechenden potentiellen Verlusten bei Schutzfähigkeiten, die dadurch dem Netzwerk 100 geliefert werden. Darüber hinaus können die Netzwerkeindringschutzgeräte 80 und 81 beispielsweise durch Anfrage des IPS-Verwaltungsknoten 85 konfiguriert sein, um ein oder mehrere spezifische Geräte zu überwachen, anstatt aller Geräte auf einem Netzwerk. Beispielsweise kann das Netzwerkeindringschutzgerät 80 angewiesen werden, nur den Netzwerkdatenverkehr zu überwachen, der an den Webserver 61 gerichtet ist. Hybride Host-basierte und Inline-basierte Eindringschutzsystemtechnologien können auf allen anderen Servern auf den Ethernetzwerken 55 und 56 implementiert sein, die bei einem verteilten Systemangriff anvisiert werden können. Ein verteiltes Eindringschutzsystem, wie z. B. dasjenige, das oben beschrieben ist, kann auf jeder Anzahl von Plattformen, wie z. B. UNIX, Windows NT, Windows, Linux, usw., implementiert werden.
3 ist ein vereinfachtes Datenflußdiagramm eines Ausführungsbeispiels der vorliegenden Erfindung. Eine Anfälligkeitsbeschreibungssprachen (VDL = vulnerability description language) -Datei 200 ist vorzugsweise eine Textdatei mit einem Standardformat, die Sicherheits- und/oder Anfälligkeitsbeschreibungen von einem oder mehreren Computersystemen spezifiziert. Die VDL-Datei 200 umfaßt eine Sammlung von hierarchischen Sicherheitsspezifikationen, die durch Produkt-, Kategorie- und Gruppendefinitionen definiert sind. Die VDL-Datei 200 kann beispielsweise diese Definitionsebene umfassen (wobei die Sicherheitsdefinitionseinzelheiten entfernt sind):
Weitere Einzelheiten des VDL-Formats sind nachfolgend aufgeführt. Die VDL-Datei 200 kann die Anfälligkeit eines Computersystems, wie das Vorliegen derselben getestet werden kann, wie die Erfassung einer Anfälligkeit berichtet werden kann, und wie die Anfälligkeit repariert bzw. behoben werden kann, beschreiben. Beispielsweise kann ein Computersystem eine Anfälligkeit haben, es Netzwerkpartnern zu erlauben, beim Verwalten von NetBios-Namenkonflikten mit einem nicht authentifizierten Protokoll zu helfen, das einer Ausschaltung (Spoofing) ausgesetzt ist. Wenn dieselbe durch ein Netzwerkeindringschutzsystem oder ein Netzwerkschutzsystem verwendet wird, umfaßt die VDL-Datei 200 vorzugsweise eine Beschreibung von Angriffsdatensignaturen. Angriffs signaturen sind Strukturen in den übertragenen Daten oder Netzwerkrahmen, die einen Angriff anzeigen, wie z. B. „ping of death" (Klingeln des Todes).
Die VDL-Datei 200 kann durch einen VDL-Interpretierer 202 gelesen und kompiliert werden, der die Beschreibungen darin syntaktisch analysiert und dieselben in eine oder mehrere Tabellen in einer Konfigurationsdatenbank 204 organisiert. Alternativ kann ein Anwendungsprogramm die VDL-Datei 200 beim Einschalten oder während des Betriebs (on-the-fly) kompilieren oder interpretieren, und die Sicherheitsdefinitionsinformationen in dem Speicher speichern. Ein Beispiel, wie die Konfigurationsdatenbank 204 organisiert werden kann, ist in 4 gezeigt, die nachfolgend näher beschrieben wird. Der VDL-Interpretierer 202 kann die Daten in der Konfigurationsdatenbank 204 organisieren, gemäß einem Format und Layout, das durch einen Hersteller von Anwendungsprogrammen 206 spezifiziert ist, die dessen Daten verwenden, wie z. B. die Eindringschutzanwendungen 207 und die Anfälligkeitsbewertungsanwendungen 208. Die Eindringschutzanwendungen 207 und Anfälligkeitsbewertungsanwendungen 208 überwachen Netzwerkdaten, die durch einen Netzwerktreiber 210 von einem Netzwerk 212 gemäß den Sicherheitsdefinitionen, die in der Konfigurationsdatenbank 204 gespeichert sind, empfangen werden. Die Anwendungen 207 und 208 können auch mit dem Hostbetriebssystem 209 und den Hostanwendungen 211 eine Schnittstelle bilden.
Es gibt vier Gruppen von Informationen in den Sicherheitsdefinitionen, die in der VDL-Datei 200 dargelegt sind. Die erste Gruppe umfaßt Beschreibungen eines Sicherheitszustands, wie z. B. einer Anfälligkeit oder eines Angriffs, und wie dieselbe/derselbe zu reparieren oder zu verhindern ist. Diese Standardbeschreibungsformatzeichenfolgen umfassen PLATFORM (PLATTFORM), SEVERITY (HEFTIGKEIT), DESCRIPTION (BESCHREIBUNG), BRIEF_DESCRIPTION (KURZE_BESCHREIBUNG), EXPLANATION (ERKLÄRUNG), AUTO_FIX_DESCRIPTION (AUTO_REPARATUR_BESCHREIBUNG), und MANUAL_FIX_DESCRIPTION (MANUELLE_REPARATUR_BESCHREIBUNG). In VDL gibt es auch ein Konzept von Plattformen. Eine Sicherheitsdefinition, und auch ihre Taktikelemente (policy-Elemente), können für eine oder mehrere Plattformen definiert sein. Wenn das Sicherheitsprodukt auf einer spezifischen Plattform läuft, werden vorzugsweise nur Sicherheitsdefinitionen, die dieser speziellen Plattform zugewiesen sind, geltend gemacht, und nur Taktikelemente, die dieser speziellen Plattform zugewiesen werden, werden dem Benutzer präsentiert oder berichtet. Alternativ kann es ein Netzwerkadministrator vorziehen, Berichte bezüglich mehrerer Plattformen oder Knoten in dem Netzwerk zu empfangen. Die Plattformdefinition beschreibt typischerweise den Systemtyp, auf dem die Sicherheitsproduktanwendung läuft, wie z. B. ein Blackboxgerät, ein Agent, der auf einem Server läuft, usw. Der tatsächliche Text, der dem Benutzer oder Administrator des Sicherheitsprodukts angezeigt ist, ist in dem VDL gespeichert, was die Übersetzung zu einem ziemlich leichten Thema macht. Dieser Text wird sowohl in der Benutzerschnittstelle als auch bei gedruckten Berichten verwendet.
Die zweite Gruppe von Sicherheitsdefinitionen umfaßt Zeichenfolgen, die beschreiben, wie Audit- oder Erfassungsergebnisse präsentiert werden sollen. Diese Standardanfälligkeitsbeschreibungszeichenfolgen können beispielsweise folgende umfassen: GENERAL_RESULTS_TEXT (ALLGEMEINE_ERGEBNISSE _TEXT), BEGIN_INTERMEDIATE_RESULTS_TEXT_DEF (BEGINNE_ZWISCHENERGEBNISSE_TEXT_DEFINITION), END_INTERMEDIATE_RESULTS TEXT_DEF (ENDE_ZWISCHENERGEBNISSE_TEXT_DEFINITION), und BEGIN_DETAILED_RESULTS_TEXT_DEF (BEGINNE_DETAILLIERTE_ ERGEBNISSE_TEXT_DEFINITION), END_DETAILED_RESULTS_TEXT_DEF (ENDE_DETAILLIERTE_ERGEBNISSE_TEXT_DEFINITION). VDL liefert vorzugsweise ein dreilagiges Ergebnisberichtsmodell: allgemeine Ergebnisse, Zwischenergebnisse und detaillierte Ergebnisse. Allgemeine Ergebnisse sind Zusammenfassungsebenen- und Einzelzeilen-Zeichenfolgen. Zwischenergebnisse und detaillierte Ergebnisse werden normalerweise in einem Tabellenformat präsentiert, wobei die Spalten in dem VDL definiert sind. Ergebnisse werden normalerweise in der Benutzerschnittstelle der Anwendung präsentiert, und auch in Berichten. Es liegt an der Sicherheitsproduktanwendung, zu bestimmen, welche Berichtebene für welche spezielle Situation gewünscht wird.
Die dritte Gruppe von Sicherheitsdefinitionen umfaßt einen oder mehrere BEGIN_POLICY_DEF (BEGINNE_TAKTIK_DEFINITIONEN) und END_POLICY_DEF (ENDE_TAKTIK_DEFINITIONEN)-Abschnitte, die Taktikeinstellungen für eine Anfälligkeit oder ein Eindringen liefern. Taktikelemente sind benutzerkonfigurierbare Parameter für die spezielle Anfälligkeit oder das spezielle Eindringen. Normalerweise definieren die Taktikelemente, wie die Anfälligkeit oder das Eindringen erfaßt, berichtet oder repariert wird.
Die vierte Gruppe von Sicherheitsdefinitionen umfaßt Definitionen, die spezifizieren, wie ein Eingriff erfaßt werden soll. Diese Gruppe kann 0 oder mehr BEGIN_SIGNATURE_DEF (BEGINNE_SIGNATUR-DEFINITION) und END_SIGNATURE_DEF (ENDE_SIGNATUR_DEFINITION)-Abschnitte umfassen. Die Datenrahmen Bit- oder Bytestruktur, die einen bekannten Angriff anzeigt, wird in diesem Abschnitt definiert. Beispielsweise kann die Signaturdefinition für einen typischen verteilten „ping of death"-Angriff definiert werden durch: if((icmp)&&(65535<((ip[2:2] – ((ip[0:1]&0x0f)·4)) + ((ip[:2]&0x1fff)·8)))))
Optional kann ein PLUGIN-Schlüsselwort verwendet werden, um die Erfassungsaufgabe an ein anderes Anwendungsmodul zu delegieren. Das PLUGIN-Schlüsselwort liefert den Namen einer DLL (dynamically linked library = dynamisch verbundene Bibliothek) oder eines Objekts, das die Wiedererkennung des Eindringens handhaben wird. Die DLL wird an alle Pakete gesendet, die mit den SIGNATURE_DEF-Abschnitten übereinstimmen.
Es folgt eine detailliertere Beschreibung des VDL-Standardformats zum Beschreiben einer Computersystemanfälligkeit. Bisher sind Anfälligkeits- oder Eindringinformationen von Computersystemen typischerweise in Read Me-Dateien, Benutzerdokumentation, Datenbanken oder anderen Orten in Nicht-Standardformaten enthalten. Diese Dateien oder Handbücher können typischerweise nur von Menschen gelesen werden. Die VDL-Beschreibungen in den VDL-Dateien der vorliegenden Erfindung können sowohl von Menschen als auch Computerprogrammen gelesen werden, weil sie eine Standardsyntax und ein Standardformat liefern. Bei der nachfolgenden Beschreibung ist der Text in den winkligen Klammern Erklärungen oder Beschreibungen, die nicht wörtlich gemeint sind, Text nicht innerhalb winkliger Klammern sollte wörtlich genommen werden, und die Schlüsselwörter in allen Großbuchstaben sind vorgeschrieben, sofern sie nicht speziell als optional gekennzeichnet sind. Nachfolgend wird die allgemeine Struktur und das allgemeine Format einer VDL-Datei gemäß den Lehren der vorliegenden Erfindung gezeigt:
Der Produktdefinitionsabschnitt umfaßt alle anderen Abschnitte, die sich auf ein Produkt beziehen. Eine VDL-Datei kann mehrere Produktdefinitionsabschnitte enthalten. Ein Produktdefinitionsabschnitt wird verwendet, um den Name eines Sicherheitsprodukts zu spezifizieren, wie z. B. einer Eindringerfassungsanwendung, einer Eindringschutzanwendung oder eines Anfälligkeitsscanners. Das bevorzugte Format für die Produktdefinition ist:
Der Produktdefinitionsabschnitt ist beschrieben durch das BEGIN_SECURITY_PRODUCT-Schlüsselwort und ein passendes END_SECURITY_PRODUKT-Schlüsselwort. Der Abschnitt kann mehrere Taktikgruppendefinitionsabschnitte und mehrere Kategoriedefinitionsabschnitte enthalten.
Der Taktikgruppendefinitionsabschnitt ordnet eine Gruppe von Taktikelementdefinitionen oder Sicherheitselementdefinitionen einem Taktikordner zu. Ein oder mehrere Taktikgruppendefinitionsabschnitte können in einem Produktdefinitionsabschnitt oder einem Kategoriedefinitionsabschnitt erscheinen. Das bevorzugte Format ist:
Der Taktikordnername spezifiziert den vollständigen Namen des Ordners, der die eingeschlossenen Taktikelemente und Sicherheitselemente enthält. Ein Beispiel ist:
Bei diesem Beispiel werden alle eingeschlossenen Taktikelemente oder Sicherheitselemente in den „Meine Taktikelemen te"-Unterordner in dem „Meine Taktik"-Elternordner plaziert.
Der Kategoriedefinitionsabschnitt ordnet eine Gruppe verwandter Sicherheitselemente und Taktikelemente zu. Ein oder mehrere Kategoriedefinitionsabschnitte können in einem Produktdefinitionsabschnitt erscheinen. Ein Kategoriedefinitionsabschnitt kann ein oder mehrere Taktikgruppendefinitionsabschnitte enthalten. Das bevorzugte Format gemäß der vorliegenden Erfindung ist:
Der Taktikelementdefinitionsabschnitt wird verwendet, um alle Eigenschaften mit Bezug auf ein Taktikelement zu beschreiben. Taktikelemente entsprechen typischerweise Parametern, die erforderlich sind, um eine Prüfung durchzuführen oder ein Eindringen zu erfassen. Es gibt jedoch viele Taktikelemente, die allgemeine Einstellungen liefern, wie z. B. Zeitplankonfiguration und E-Mail-Konfiguration. Taktikelemente weisen typischerweise Vorgabewerte auf, die durch den Benutzer überarbeitet werden können. Die Daten für ein Taktikelement werden in einer Datenbank gespeichert. Die Taktik des Benutzers besteht aus der gesamten Sammlung von Taktikelementen in der Datenbank.
Der <Taktikelementname> spezifiziert den Namen des Taktikelements. Das Namenformat erlaubt vorzugsweise keine weißen Leerzeichen (d. h. Leerstellen oder Tabs). Die <Plattform> spezifiziert die Computerplattform, die für das Taktik/Sicherheitselement verwendet wird. Beispielhafte Plattformen können AGENT, APPLIANCE (VORRICHTUNG), MOBILE (MOBIL), AGENT_AND_APPLIANCE (AGENT_UND_VORRICHTUNG) oder ALL (ALLE) (Vorgabe) umfassen. Die Plattformspezifikation kann nicht vorgeschrieben sein. Die <Taktikelementerklärung> enthält Text, der das Taktikelement beschreibt und bei Berichten und/oder bei Bildschirmhilfedialogfenstern verwendet werden kann. Die <Taktikelementerklärung> kann einige Sätze enthalten, die das Taktikelement beschreiben. Diese Beschreibung kann in Berichten verwendet werden und kann auch verwendet werden, um eine zusätzliche Bildschirmhilfe zu liefern. Das <Typ> Feld spezifiziert den Typ von Taktikelement, der CHAR (Zeichen), NUMBER (Zahl), DROPLIST (Aufklappliste), CHECKBOX (Ankreuzfeld) oder CUSTOM (anwenderdefiniert)-Typen spezifizieren kann. Der CHAR-Typ zeigt an, daß das Taktikelement ein Bearbeitungsfeld benötigt, der NUMBER-Typ zeigt an, daß das Taktikelement ein Bearbeitungsfeld für Zahlen benötigt, der DROPLIST-Typ zeigt an, daß das Taktikelement eine Aufklappliste von Elementen benötigt, die CHECKBOX zeigt an, daß das Taktikelement ein Ankreuzfeld erfordert, und der CUSTOM-Typ zeigt an, daß das Taktikelement ein anwenderdefiniertes Dialogfeld erfordert, um eine Eingabe von dem Benutzer zu erhalten. Das <Vorgabewert>-Feld spezifiziert den Vorgabewert, der dem Taktikelement zugeordnet ist. Das Vorgabewertformat ist eine Zeichenfolge, die von doppelten Anführungszeichen umgeben wird. Die <untere Grenze>-Spezifikation ist nur gültig, wenn <Typ> NUMBER ist, und die untere Grenze für den Bereich gültiger Zahlen spezifiziert, die dem Taktikelement zugeordnet sind. Vorzugsweise wird es dem Benutzer nicht erlaubt, Zahlen einzugeben, die kleiner sind als <untere Grenze>. Falls <untere Grenze> spezifiziert ist, dann sollte <obere Grenze> ebenfalls spezifiziert sein. Gleichartig dazu wird es dem Benutzer nicht erlaubt, Zahlen einzugeben, die größer sind als <obere Grenze>. Die <Zeichenzahl> spezifiziert die maximale Zahl an Zeichen, die in dem Bearbeitungsfeld erlaubt sind, das einem Taktikelement zugeordnet ist. <Zeichensatz ausschließen> spezifiziert Zeichen, die in dem Bearbeitungsfeld, das einem Taktikelement zugeordnet ist, nicht erlaubt sind. <Zeichensatz einschließen> spezifiziert Zeichen, die in dem Bearbeitungsfeld erlaubt sind, das einem Taktikelement zugeordnet ist. Das <Liste>-Feld spezifiziert Elemente, die in dem Aufklapplistenfeld enthalten sein sollen. <prog id> spezifiziert die Prog ID eines COM-Objekts, die ein Dialogfeld anzeigen kann, das verwendet wird, um die anwenderspezifischen Taktikdaten zu gewinnen, wenn <Typ> CUSTOM ist. Die <Nur-Reparieren-Flag> wird verwendet, um anzuzeigen, daß das Taktikelement zum Reparieren eines Sicherheitsproblems und nicht zum Prüfen desselben gedacht ist. Falls dieses Flag nicht gesetzt ist, ist das Taktikelement sowohl zum Reparieren eines Sicherheitsproblems als auch zum Prüfen desselben.
Der Sicherheitselementdefinitionsabschnitt beschreibt vorzugsweise alle Eigenschaften bezüglich eines Sicherheitelements. Sicherheitselemente sind typischerweise das Thema, das geprüft oder erfaßt wird. Ein Sicherheitselement kann beispielsweise der „ping of death"-Angriff sein, der erfaßt werden soll, oder eine ReleaseNetBiosName-Anfälligkeit, die geprüft werden soll.
Der <Sicherheitselementname> spezifiziert den Namen des Sicherheitselements und enthält vorzugsweise keine weißen Stellen. Die <Sicherheitselementkurzbeschreibung> ist vorzugsweise ein vorgeschriebenes Feld und spezifiziert Text, der in einem Editor angezeigt ist, den ein Benutzer verwenden kann, um die Taktikelementdaten zu bearbeiten oder zu überprüfen. Dieser Editor kann ein speziell zugewiesener Taktikeditor sein, der eine Komponente einer graphischen Benutzeroberfläche ist. Der Text sollte die Sicherheitsprüfung, die durchgeführt werden soll, kurz beschreiben. Beispielsweise BRIEF_DESCRIPTION: „Administrator Kontonamen prüfen". Das <Sicherheitselementerklärung>-Feld wird verwendet, um Text zu spezifizieren, der erklärt, warum das spezifizierte Sicherheitselement ein Thema ist, und wie Hacker beispielsweise die Anfälligkeit ausnützen können, um das System zu schädigen. Das <Heftigkeit>-Feld spezifiziert die Heftigkeit einer potentiellen Anfälligkeit oder eines Angriffs auf einer vorbestimmten Scala, wie z. B. 1 bis 5. Die <Autoreparaturbeschreibung> enthält eine kurze Beschreibung dessen, was durch ein Autoreparaturmerkmal eines Anfälligkeitsbewertungssystems repariert wird, wie z. B. das INTELLIFIX-Merkmal des SFPROTECT-Systems. Diese Beschreibung kann ein oder mehrere Zeichenfolgenformatspezifizierer enthalten, wie z. B. %-Zeichen. Jedesmal, wenn das System ein % in <Autoreparaturbeschreibung> findet, ersetzt es dasselbe mit dem Parameter, der von der <Reparaturbeschreibungsanfrage> zurückgesendet wird. Vorzugsweise ist die Reihenfolge der Parameter, die durch die Anfrage zurückgesendet werden, die Reihenfolge, in der sie in die <Autoreparaturbeschreibung>-Zeichenfolge eingefügt werden. Das <Autoreparaturvergangenheitsbeschreibung>-Feld enthält eine kurze Beschreibung dessen, was durch das Autoreparaturmerkmal repariert wurde. Diese Beschreibung kann ein oder mehrere Zeichenfolgeformatspezifizierer (d. h. %-Zeichen) enthalten. Jedesmal, wenn das System ein % in der <Autoreparaturvergangenheitsbeschreibung> findet, ersetzt es dasselbe vorzugsweise mit dem Parameter, der von der <Reparaturbeschreibungsanfrage> zurückgesendet wird. Die Reihenfolge der Parameter, die durch die Anfrage zurückgesendet werden, ist vorzugsweise die Reihenfolge, in der sie in die <Autoreparaturvergangenheitsbeschreibung>-Zeichenfolge eingefügt werden. Das <Autoreparaturvergangenheitsbeschreibung>-Feld kann beispielsweise „Reparatur hat den Administratorkontonamen zu „%-Zeichen" geändert" spezifizieren. Die <Autoreparaturwarnung> wird verwendet, um eine kurze Warnung an die Benutzer zu enthalten, um sie an die Konsequenzen des Durchführens einer automatischen Abhilfe für das spezifizierte Sicherheitselement zu erinnern. Beispielsweise AUTO_FIX_WARNING: „Neuen Namen des Administratorkontos aufzeichnen und sichergehen, daß dieser neue Name an die anderen Administratoren kommuniziert wird". Falls das Sicherheitselement repariert werden kann ist dieses Feld vorzugsweise vorgeschrieben. Das <Reparaturbeschreibungsanfrage>-Feld spezifiziert eine Anfrage, die verwendet wird, um eine Autoreparaturbeschreibungszeichenfolge zu formatieren. Beispielsweise gilt FIX_DESCRIPTION_QUERY: „SELECT PolicySettings.PolicyItem FROM PolicySettings WHERE (((PolicySettings.SecurityID)=1000))" für: <Autoreparaturbeschreibung> und <Autoreparaturvergangenheitsbeschreibung>.
Das <manuelle Reparaturbeschreibung>-Feld wird verwendet, um eine Schritt-für-Schritt-Beschreibung zu spezifizieren, wie das Sicherheitsproblem manuell repariert werden kann. Beispielsweise MANUELL_FIX_DESCRIPTION: „Falls der Internetinformationsserver auf dem Betriebssystemdatenträger installiert wurde, muß er deinstalliert werden und auf einem anderen Datenträger neu installiert werden. Falls ein virtuelles Verzeichnis in dem Betriebssystemdatenträger eingerichtet wurde, Verwende die Microsoft Management Console, zum Ziehen, und Erzeuge dann ein neues virtuelles Verzeichnis auf einem alternativen Datenträger. Für mehr Informationen über virtuelle Verzeichnisse siehe Produktdokumentati on für den Windows NT 4,0 OptionPack". Dieses Feld ist vorzugsweise ebenfalls vorgeschrieben. Das <allgemeine Ergebnisse Text>-Feldenthält eine Zeichenfolge, die in dem allgemeinen Ergebnisfenster angezeigt werden soll. Für einen Anfälligkeitsscanner sollte es die Ergebnisse eines Sicherheitsprüfungen spezifizieren; für ein Eindringschutzsystem sollte es eine allgemeine Beschreibung des Angriffs enthalten, der erfaßt wurde. Beispielsweise kann „% von %-Dateien oder Unterverzeichnissen haben die Erlaubnisprüfung nicht bestanden" verwendet werden als die <allgemeine Ergebnisse>-Zeichenfolge für das Sicherheitselement, das verwendet wird, um Dateierlaubnisse zu prüfen. Dies ermöglicht es dem Benutzer, über den Status der Prüfung informiert zu werden. Das <detaillierte Anzeigeoption>-Feld spezifiziert vorzugsweise eine von drei Ebenen einer detaillierten Anzeige, die durch das Sicherheitselement verwendet werden sollen, einschließlich keine detaillierte Anzeige, normale Einzelheitenebene und optimierte detaillierte Anzeige. Das <Aktiviert>-Feld spezifiziert, ob das Sicherheitselement anfangs in dem Taktikeditor geprüft wird oder nicht. Sicherheitselemente sind durch Voreinstellung aktiviert. Das <plugin>-Feld spezifiziert den Namen eines Sicherheitsplugins, zum Zuordnen zu einem Sicherheitselement. Ein Plugin ist ein Objekt, das dynamisch in das System geladen werden kann. Der Plugin Name hat das Format: DLLName.Objektname.
Der Signaturdefinitionsabschnitt enthält Ausdrücke, die die Anzeigedatenstruktur eines Netzwerk-basierten Angriffs beschreiben. Eine oder mehrere <if-Aussagen> können verwendet werden, um eine Angriffssignatur zu beschreiben. Der Signaturdefinitionsabschnitt kann nur in einem Sicherheitselementdefinitionsabschnitt existieren. Es kann nur einen Signaturdefinitionsabschnitt pro Sicherheitselementdefinitionsabschnitt geben. Das allgemeine Format und die allgemeine Syntax des Signaturdefinitionsabschnittes ist:
Jede Sicherheitsdefinition kann mehrere Signaturausdrücke aufweisen:
Ein Beispiel ist nachfolgend gezeigt:
Das <Signaturausdruck>-Feld beschreibt die Bedingung(en) zum Erfassen eines Netzwerk-basierten Angriffs. Der Signaturausdruck kann mehrere Zeilen überspannen und muß die folgende allgemeine Syntax aufweisen:
oder der <Signaturausdruck> kann <if-Ausdruck>::(<if-Ausdruck>) | (<Operand> <Betreiber₂> <Operand>) oder <if-Ausdruck> :: (<if-Ausdruck>) | (<Operand><Betreiber₁>) sein, wobei <Betreiber₁> ein unärer Betreiber ist und <Betreiber₂> ein binärer Betreiber ist. Mögliche unäre Betreiber umfassen ein bitweises Komplement und NICHT. Mögliche binäre Betreiber umfassen logische, arithmetische und bitweise Operationen. <Operand> wird ausgedrückt durch <Protokollausdruck> | <allgemeine Zahl> <Taktikvariable>, wobei <Protokollausdruck> <Protokoll> {[offset: Bytelänge]} ist. <Protokoll> kann TCP, ICMP, UDP, IP, MAC, IGMP, GCP, PUP, RAW und andere Protokolle umfassen. Das Feld <allgemeine Zahl> umfaßt jeden „C" stilnumerischen Ausdruck, wie z. B. 0xfffff, 100. Das <Taktikvariable>-Feld umfaßt $: <Taktikelementname>. Das <Aktion>-Feld spezifiziert die Aktion, die durchgeführt werden soll, wenn der Signaturausdruck als wahr bewertet wird. Das <Aktion>-Feld kann LOG_FRAME spezifizieren (log frame jedesmal wenn der Signaturausdruck als wahr bewertet wird) und/oder INCREMENT_COUNTER (ein Zähler wird jedesmal inkrementiert, wenn der Signaturausdruck als wahr bewertet wird). Das <Richtung>-Feld spezifiziert die Richtung zum Anlegen des Signaturausdrucks, um anzuzeigen, ob der Datenfluß INBOUND und/oder OUTBOUND ist.
Der detaillierte Ergebnistextdefinitionsabschnitt wird verwendet, um das Formatieren der detaillierten Ergebnistabelle zu spezifizieren. Diese Informationen wird von einer DetailedResultsGrid (detaillierte Ergebnissegitter)-Steuerung verwendet, um zu bestimmen, wie die Daten für die detaillierte Ergebnisansicht formatiert werden sollen. Das allgemeine Format ist:
Der Zwischenergebnissetextdefinitionsabschnitt spezifiziert vorzugsweise das Formatieren der Zwischenergebnistabelle. Diese Informationen werden durch die DetailedResultsGrid-Steuerung verwendet, um zu bestimmen, wie die Daten für die Zwischenergebnisseansicht zu formatieren sind. Ein allgemeines Format ist:
Das <Anfangsblockspalte>-Feld wird verwendet, um den Text für den Spaltenanfangsblock einer Anzeigetabelle zu spezifizieren. Beispielsweise spezifizieren die folgenden <An fangsblockspalte>-Felder den Text, der in dem ersten und dem zweiten Spaltenanfangsblock der detaillierten Anzeigetabelle angezeigt werden soll. Bei diesem Beispiel würde der Spaltenanfangsblock für die erste Spalte angezeigt als „Benutzername". Der zweite Spaltenanfangsblock wird angezeigt als „Letzte Anmeldung".
Dies würde folgendes ergeben:
Das <Zelltext_Spalten>-Feld spezifiziert den Text, der in jeder Zelle einer Anzeigetabelle verwendet werden soll. Die Zeichenfolge kann Zeichenfolgenformatspezifizierer (d. h. %) enthalten. Falls <detaillierte Anzeigeoption> NORMAL-Anzeige ist, kommt die Anzeigezeichenfolge von den AuditObject-Feldern oder von einer gemeinsamen Anfrage der DetailedAuditResults (detaillierte Prüfungs- bzw. Auditergebnisse)-Tabelle und der DetailedAuditResultDetail (detaillierte Auditergebnissedetail)-Tabelle. Falls <detaillierte Anzeigeoption> OPTIMIERTE Anzeige ist, wird das CELLTEXT_COLFeld ignoriert. Die anzuzeigenden Informationen werden di rekt in das AuditObject-Feld in der DetailedAuditResult-Tabelle geschrieben. Die Tab-Zeichen in dem AuditObject-Feld werden als Begrenzer zum Plazieren von Text in die richtige Spalte verwendet.
Die VDL-Datei, deren Syntax und Format oben im Detail aufgeführt ist, wird vorzugsweise gelesen und syntaktisch analysiert, um die Anfälligkeitsinformationen, die darin spezifiziert sind, in ein Format zu organisieren, auf das zugegriffen werden kann und das durch Sicherheitsanwendungen, wie z. B. Anfälligkeitsscanner, Eindringerfassungssysteme und Eindringschutzsysteme, verwendet werden kann. 4 ist ein beispielhaftes Diagramm einer relationalen Datenbank einer Anfälligkeitsdatenbank, die verwendet werden kann, um die Daten zu speichern, die von der VDL-Datei 200 erhalten und syntaktisch analysiert wurden (3). Es sei von dem vorhergehenden daran erinnert, daß die VDL-Datei vorzugsweise vier Spezifikationstypen enthält:

1) Spezifikation der Anfälligkeit und des Angriffs, und wie dieselben zu verhindern oder zu reparieren sind
2) Spezifikation, wie die Audit- oder Erfassungsergebnisse präsentiert oder berichtet werden sollten
3) Spezifikation, welche Taktik oder Einstellungen eine spezielle Anfälligkeit oder ein spezielles Eindringen regeln
4) Spezifikation, wie ein Eindringen zu erkennen ist

Die Kategorie 1 Informationen, die in der VDL-Datei geliefert werden, werden in einer Sicherheitsdefinitionstabelle 300 gespeichert. Jedem Sicherheitselement wird ein eindeutiger Sicherheitsidentifizierer (SecurityID) zugewiesen, der verwendet wird, um die Informationen in mehreren anderen Tabellen in der Datenbank zu indexieren und mit der Sicherheitsdefinitionstabelle 300 zu verbinden. Es gibt typischerweise eine 1-zu-l-Entsprechung von einer Sicherheitselementspezifikation in der VDL-Datei mit einem Datenfeld in der Sicherheitsdefinitionstabelle 300. Informationen der Kategorie 2, wie Ergebnisse präsentiert und angezeigt werden sollten, sind in mehreren Tabellen gespeichert, einschließlich DetailedAuditResultsDetailDisplayStrings (detaillierte Auditergebnissedetailanzeigezeichenfolge)-Tabelle 302, DetailedAuditResultsDisplayStrings (detaillierte Auditergebnisseanzeigezeichenfolge)-Tabelle 304, IntermediateDetailDisplayStrings (Zwischeneinzelheitenanzeigezeichenfolge)-Tabelle 306 und GeneralAuditResults-DisplayStrings (allgemeines Auditergebnisseanzeigezeichenfolge)-Tabelle 308. Informationen der Kategorie 3 über Taktikeinstellungen werden in mehreren Tabellen gespeichert, einschließlich PolicyName (Taktikname)-Tabelle 310, Policy-Settings (Taktikeinstellungen)-Tabelle 312, PolicyItemAttributes (Taktikelementeigenschaften)-Tabelle 314 und der Policy (Taktik)-Tabelle 316. Es ist zu sehen, daß jedes Taktikelement einem Taktikelementidentifizierer zugewiesen ist, der verwendet wird, um die PolicyItemAttributes-Tabelle 314 mit der PolicySettings-Tabelle 312 zu verbinden. Alle PolicySetting-Tabellen 310 bis 316 sind außerdem durch SecurityID mit der Sicherheitsdefinitionstabelle 300 verbunden. Informationen in der Kategorie 4 werden in der SignatureDefinitions (Signatur Definition)-Tabelle 318 und der Plugin-Tabelle 320 gespeichert, die beide vorzugsweise durch SecurityID mit der Sicherheitsdefinitionstabelle verbunden sind. Eine PlatformDefinition (Plattformdefinition)-Tabelle 322 wird ferner verwendet, um die Computerplattforminformationen zu speichern, die in der Sicherheitselementdefinitionsbeschreibung der VDL identifiziert werden. Ferner werden Informationen bezüglich der Sicherheitsproduktspezifikation in der SecurityIDsCategory (SicherheitsID Kategorie)-Tabelle 324 und der ProductDefinition (Produktdefinition)-Tabelle 326 gespeichert. Die Tabellen 324 und 326 sind indexiert und über den SecurityIDCategory-Dateneintrag und einen Identifizierer, ProductID, der dem Sicherheitsprodukt zugewiesen ist, mit der Sicherheitsdefinitionstabelle 300 verbunden.
Die Anfälligkeitsinformationen, die in der Datenbank gespeichert sind, sind durch eine Anzahl von Sicherheitsproduktanwendungen zugreifbar, wie z. B. Eindringerfassungssystemen und Anfälligkeitsscannern. Eine graphische Benutzeroberfläche kann verwendet werden, um den Eintrag von Anfälligkeitsdaten in der VDL-Datei zu ermöglichen, und außerdem ein Bildschirmberichten der Erfassungs- und Auditergebnisse gemäß den Informationen, die in der VDL-Datei spezifiziert sind, zu liefern.
Gemäß der vorliegenden Erfindung wird eine Standardtextbasierte Syntax und ein Format zum Beschreiben des Sicherheitszustands eines Computersystems verwendet, so daß Benutzer die Beschreibung ohne weiteres betrachten, aktualisieren und modifizieren können, um sich an ändernde Bedingungen anzupassen. Ferner können aufgrund der Standardsyntax Computeranwendungen entwickelt werden, um die Informationen in der Anfälligkeitsbeschreibungsdatei zu lesen und zu verarbeiten, wie z. B. das syntaktische Analysieren der Daten, um dieselben in einer relationalen Datenbank zu speichern oder um die Daten während der Anwendungsausführung in einem Speicher zu speichern. Die Standardsyntax und das Standardformat der vorliegenden Erfindung ermöglichen eine Einheitlichkeit und Interoperabilität zwischen verschiedenen Anwendungen.

Claims

Verfahren zum Definieren der Sicherheitsanfälligkeit eines Computersystems (30), das folgende Schritte umfaßt: Spezifizieren eines Angriffs, der eine erkannte Anfälligkeit (300) des Computersystems darstellt, über eine Anfälligkeitsbeschreibungssprachen-Datei (VDL-Datei), wobei die VDL-Datei ferner zumindest eine Eigenschaft des spezifizierten Angriffs (300, 318) spezifiziert; zumindest eine Taktikdefinition (310, 312, 314) bezüglich des Erfassens der Anfälligkeit des spezifizierten Angriffs spezifiziert; und eine Abhilfe (300) für die spezifizierte Anfälligkeit spezifiziert.
Verfahren gemäß Anspruch 1, das ferner das Spezifizieren zumindest einer Eigenschaft der spezifizierten Taktikdefinition (314) über die VDL-Datei umfaßt.
Verfahren gemäß Anspruch 1 oder 2, das ferner das Spezifizieren einer Rechenplattform (322) des Computersystems über die VDL-Datei umfaßt.
Verfahren gemäß einem der Ansprüche 1 bis 3, das ferner folgende Schritte umfaßt: Spezifizieren einer Sicherheitskategorie (300) des spezifizierten Angriffs über die VDL-Datei; und Spezifizieren zumindest einer Taktikgruppe (300, 314) bezüglich der spezifizierten Sicherheitskategorie über die VDL-Datei.
Verfahren gemäß einem der Ansprüche 1 bis 4, das ferner das Spezifizieren eines Anfälligkeitsscanners (326), der auf dem Computersystem (30) läuft, über die VDL-Datei umfaßt.
Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318) das Spezifizieren einer Identifikation der Heftigkeit umfaßt, die einer Verletzung des Computersystems durch den Angriff zugeordnet ist.
Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318) das Spezifizieren einer Beschreibung des Angriffs (300, 318) umfaßt.
Verfahren gemäß einem der Ansprüche 1 bis 7, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318) das Spezifizieren einer Erklärung umfaßt, weshalb der spezifizierte Angriff wichtig ist.
Verfahren gemäß einem der Ansprüche 1 bis 8, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318) das Spezifizieren umfaßt, wie Informationen bezüglich des spezifizierten Angriffs (302, 304, 306) einem Benutzer berichtet werden sollen.
Verfahren gemäß einem der Ansprüche 1 bis 9, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318) das Spezifizieren ei ner Quelle einer Abhilfe (300) umfaßt, die wirksam ist, um die spezifizierte Anfälligkeit zu reparieren.