DE10249428A1 - System und Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems - Google Patents

System und Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems

Info

Publication number
DE10249428A1
DE10249428A1 DE10249428A DE10249428A DE10249428A1 DE 10249428 A1 DE10249428 A1 DE 10249428A1 DE 10249428 A DE10249428 A DE 10249428A DE 10249428 A DE10249428 A DE 10249428A DE 10249428 A1 DE10249428 A1 DE 10249428A1
Authority
DE
Germany
Prior art keywords
attack
specifying
vulnerability
security
specified
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE10249428A
Other languages
English (en)
Other versions
DE10249428B4 (de
Inventor
George S Gales
Richard L Schertz
Richard P Tarquini
Craig D Anderson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Publication of DE10249428A1 publication Critical patent/DE10249428A1/de
Application granted granted Critical
Publication of DE10249428B4 publication Critical patent/DE10249428B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die vorliegende Erfindung umfaßt ein Verfahren zum Definieren von Sicherheitsbedingungen eines Computersystems für den Zweck des Erfassens von Anfälligkeiten. Das Verfahren umfaßt 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.

Description

  • Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Computersysteme und insbesondere auf ein System und 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.
  • 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 Erfassens 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 Anfä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:
  • Fig. 1 ein vereinfachtes Blockdiagramm eines typischen verteilten Angriffs auf ein Computersystem;
  • Fig. 2 ein Blockdiagramm eines Computersystems, das Netzwerk-basierte, Host-basierte und Inline- Eindringschutzsysteme verwendet, in denen die vorliegende Erfindung implementiert werden kann;
  • Fig. 3 ein vereinfachtes Block- und Datenflußdiagramm eines Ausführungsbeispiels eines Anfälligkeitsbeschreibungssystems gemäß den Lehren der vorliegenden Erfindung; und
  • Fig. 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 Fig. 1 bis 4 der Zeichnungen am besten verständlich, wobei gleiche Bezugszeichen für gleiche und entsprechende Teile der verschiedenen Zeichnungen verwendet werden.
  • Fig. 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.
  • Fig. 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 Verwaltungssystem ü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 Netzwerk-basierte 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 Netzwerk- basierte Eindringschutzsysteme. Außerdem können Host- basierte 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, Netzwerkverkehr 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 Eindringschutzsystemen. 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 Fig. 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 55und 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 Hostbasierten 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 Netzwerkverkehr 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-Verwaltungsknotens 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.
  • Fig. 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. Angriffssignaturen 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 Fig. 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]&0 × 0f).4)) + ((ip[:2]&0 × 1fff).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:

    BEGIN_POLICY_GROUP: "\ Meine Taktik\ Meine Taktikelemente"
  • Bei diesem Beispiel werden alle eingeschlossenen Taktikelemente oder Sicherheitselemente in den "Meine Taktikelemente"-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 Sicherheitselements. 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 Produktdokumentatian 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> <Betreiber2> <Operand>) oder <if- Ausdruck>:: (<if-Ausdruck>)|(<Operand><Betreiber1>) sein, wobei <Betreiber1> ein unärer Betreiber ist und <Betreiber2> 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 <Anfangsblockspalte>-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_COL- Feld ignoriert. Die anzuzeigenden Informationen werden direkt 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. Fig. 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 (Fig. 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-1-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 GeneralAuditResultsDisplayStrings(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 (10)

1. 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;
Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318);
Spezifizieren zumindest einer Taktikdefinition (310, 312, 314) bezüglich des Erfassens der Anfälligkeit des spezifizierten Angriffs; und
Spezifizieren einer Abhilfe (300) für die spezifizierte Anfälligkeit.
2. Verfahren gemäß Anspruch 1, das ferner das Spezifizieren zumindest einer Eigenschaft der spezifizierten Taktikdefinition (314) umfaßt.
3. Verfahren gemäß Anspruch 1 oder 2, das ferner das Spezifizieren einer Rechenplattform (322) des Computersystems umfaßt.
4. Verfahren gemäß einem der Ansprüche 1 bis 3, das ferner folgende Schritte umfaßt:
Spezifizieren einer Sicherheitskategorie (300) des spezifizierten Angriffs; und
Spezifizieren zumindest einer Taktikgruppe (300, 314) bezüglich der spezifizierten Sicherheitskategorie.
5. Verfahren gemäß einem der Ansprüche 1 bis 4, das ferner das Spezifizieren eines Anfälligkeitsscanners (326) umfaßt, der auf dem Computersystem (30) läuft.
6. 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.
7. 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.
8. 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.
9. 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.
10. Verfahren gemäß einem der Ansprüche 1 bis 9, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (300, 318) das Spezifizieren einer Quelle einer Abhilfe (300) umfaßt, die wirksam ist, um die spezifizierte Anfälligkeit zu reparieren.
DE10249428A 2001-10-31 2002-10-23 Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems Expired - Fee Related DE10249428B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/001410 2001-10-31
US10/001,410 US20030135749A1 (en) 2001-10-31 2001-10-31 System and method of defining the security vulnerabilities of a computer system

Publications (2)

Publication Number Publication Date
DE10249428A1 true DE10249428A1 (de) 2003-05-15
DE10249428B4 DE10249428B4 (de) 2005-01-27

Family

ID=21695887

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10249428A Expired - Fee Related DE10249428B4 (de) 2001-10-31 2002-10-23 Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems

Country Status (3)

Country Link
US (1) US20030135749A1 (de)
DE (1) DE10249428B4 (de)
GB (1) GB2385168A (de)

Families Citing this family (76)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040073617A1 (en) 2000-06-19 2004-04-15 Milliken Walter Clark Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail
US7882555B2 (en) * 2001-03-16 2011-02-01 Kavado, Inc. Application layer security method and system
US6947726B2 (en) * 2001-08-03 2005-09-20 The Boeing Company Network security architecture for a mobile network platform
US6546493B1 (en) * 2001-11-30 2003-04-08 Networks Associates Technology, Inc. System, method and computer program product for risk assessment scanning based on detected anomalous events
AU2002360844A1 (en) 2001-12-31 2003-07-24 Citadel Security Software Inc. Automated computer vulnerability resolution system
US7543056B2 (en) 2002-01-15 2009-06-02 Mcafee, Inc. System and method for network vulnerability detection and reporting
US7243148B2 (en) * 2002-01-15 2007-07-10 Mcafee, Inc. System and method for network vulnerability detection and reporting
US7257630B2 (en) * 2002-01-15 2007-08-14 Mcafee, Inc. System and method for network vulnerability detection and reporting
US7694128B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for secure communication delivery
US7903549B2 (en) 2002-03-08 2011-03-08 Secure Computing Corporation Content-based policy compliance systems and methods
US7693947B2 (en) 2002-03-08 2010-04-06 Mcafee, Inc. Systems and methods for graphically displaying messaging traffic
US8561167B2 (en) 2002-03-08 2013-10-15 Mcafee, Inc. Web reputation scoring
US8132250B2 (en) 2002-03-08 2012-03-06 Mcafee, Inc. Message profiling systems and methods
US7096498B2 (en) 2002-03-08 2006-08-22 Cipher Trust, Inc. Systems and methods for message threat management
US6941467B2 (en) * 2002-03-08 2005-09-06 Ciphertrust, Inc. Systems and methods for adaptive message interrogation through multiple queues
US7124438B2 (en) 2002-03-08 2006-10-17 Ciphertrust, Inc. Systems and methods for anomaly detection in patterns of monitored communications
US7870203B2 (en) 2002-03-08 2011-01-11 Mcafee, Inc. Methods and systems for exposing messaging reputation to an end user
US20060015942A1 (en) 2002-03-08 2006-01-19 Ciphertrust, Inc. Systems and methods for classification of messaging entities
US8578480B2 (en) 2002-03-08 2013-11-05 Mcafee, Inc. Systems and methods for identifying potentially malicious messages
US7359962B2 (en) * 2002-04-30 2008-04-15 3Com Corporation Network security system integration
IL149583A0 (en) * 2002-05-09 2003-07-06 Kavado Israel Ltd Method for automatic setting and updating of a security policy
US7448067B2 (en) * 2002-09-30 2008-11-04 Intel Corporation Method and apparatus for enforcing network security policies
US7454499B2 (en) * 2002-11-07 2008-11-18 Tippingpoint Technologies, Inc. Active network defense system and method
WO2004051437A2 (en) * 2002-12-02 2004-06-17 Elemental Security System and method for providing an enterprise-based computer security policy
US8122498B1 (en) 2002-12-12 2012-02-21 Mcafee, Inc. Combined multiple-application alert system and method
US8312535B1 (en) 2002-12-12 2012-11-13 Mcafee, Inc. System, method, and computer program product for interfacing a plurality of related applications
US8990723B1 (en) 2002-12-13 2015-03-24 Mcafee, Inc. System, method, and computer program product for managing a plurality of applications via a single interface
US8239941B1 (en) 2002-12-13 2012-08-07 Mcafee, Inc. Push alert system, method, and computer program product
US9237514B2 (en) 2003-02-28 2016-01-12 Apple Inc. System and method for filtering access points presented to a user and locking onto an access point
US7526800B2 (en) * 2003-02-28 2009-04-28 Novell, Inc. Administration of protection of data accessible by a mobile device
US7308703B2 (en) * 2002-12-18 2007-12-11 Novell, Inc. Protection of data accessible by a mobile device
US7353533B2 (en) * 2002-12-18 2008-04-01 Novell, Inc. Administration of protection of data accessible by a mobile device
US8091117B2 (en) 2003-02-14 2012-01-03 Preventsys, Inc. System and method for interfacing with heterogeneous network data gathering tools
US7627891B2 (en) * 2003-02-14 2009-12-01 Preventsys, Inc. Network audit and policy assurance system
US9197668B2 (en) * 2003-02-28 2015-11-24 Novell, Inc. Access control to files based on source information
US7299497B2 (en) * 2003-06-30 2007-11-20 Microsoft Corporation Determining relative attack surface
US20070113272A2 (en) * 2003-07-01 2007-05-17 Securityprofiling, Inc. Real-time vulnerability monitoring
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
US9118710B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc System, method, and computer program product for reporting an occurrence in different manners
US9118708B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Multi-path remediation
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118711B2 (en) * 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US8984644B2 (en) 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US8201257B1 (en) 2004-03-31 2012-06-12 Mcafee, Inc. System and method of managing network security risks
US7519954B1 (en) 2004-04-08 2009-04-14 Mcafee, Inc. System and method of operating system identification
US7966658B2 (en) * 2004-04-08 2011-06-21 The Regents Of The University Of California Detecting public network attacks using signatures and fast content analysis
US7698275B2 (en) * 2004-05-21 2010-04-13 Computer Associates Think, Inc. System and method for providing remediation management
US20050268117A1 (en) * 2004-05-27 2005-12-01 International Business Machines Corporation Method and system for dynamic security checking of heterogeneous database environments
US7761920B2 (en) * 2004-09-03 2010-07-20 Fortinet, Inc. Data structure for policy-based remediation selection
US8171555B2 (en) * 2004-07-23 2012-05-01 Fortinet, Inc. Determining technology-appropriate remediation for vulnerability
US7774848B2 (en) 2004-07-23 2010-08-10 Fortinet, Inc. Mapping remediation to plurality of vulnerabilities
US20060018478A1 (en) * 2004-07-23 2006-01-26 Diefenderfer Kristopher G Secure communication protocol
US7665119B2 (en) 2004-09-03 2010-02-16 Secure Elements, Inc. Policy-based selection of remediation
US7672948B2 (en) * 2004-09-03 2010-03-02 Fortinet, Inc. Centralized data transformation
US7703137B2 (en) * 2004-09-03 2010-04-20 Fortinet, Inc. Centralized data transformation
US20060101517A1 (en) * 2004-10-28 2006-05-11 Banzhof Carl E Inventory management-based computer vulnerability resolution system
US8635690B2 (en) 2004-11-05 2014-01-21 Mcafee, Inc. Reputation based message processing
US7278163B2 (en) * 2005-02-22 2007-10-02 Mcafee, Inc. Security risk analysis system and method
US7937480B2 (en) 2005-06-02 2011-05-03 Mcafee, Inc. Aggregation of reputation data
US8341622B1 (en) * 2005-12-15 2012-12-25 Crimson Corporation Systems and methods for efficiently using network bandwidth to deploy dependencies of a software package
US8214497B2 (en) 2007-01-24 2012-07-03 Mcafee, Inc. Multi-dimensional reputation scoring
US7779156B2 (en) 2007-01-24 2010-08-17 Mcafee, Inc. Reputation based load balancing
US7949716B2 (en) 2007-01-24 2011-05-24 Mcafee, Inc. Correlation and analysis of entity attributes
US8179798B2 (en) 2007-01-24 2012-05-15 Mcafee, Inc. Reputation based connection throttling
US8763114B2 (en) 2007-01-24 2014-06-24 Mcafee, Inc. Detecting image spam
US8185930B2 (en) 2007-11-06 2012-05-22 Mcafee, Inc. Adjusting filter or classification control settings
US8045458B2 (en) 2007-11-08 2011-10-25 Mcafee, Inc. Prioritizing network traffic
US8160975B2 (en) 2008-01-25 2012-04-17 Mcafee, Inc. Granular support vector machine with random granularity
US8589503B2 (en) 2008-04-04 2013-11-19 Mcafee, Inc. Prioritizing network traffic
US8069471B2 (en) 2008-10-21 2011-11-29 Lockheed Martin Corporation Internet security dynamics assessment system, program product, and related methods
US8621638B2 (en) 2010-05-14 2013-12-31 Mcafee, Inc. Systems and methods for classification of messaging entities
US10282550B1 (en) * 2015-03-12 2019-05-07 Whitehat Security, Inc. Auto-remediation workflow for computer security testing
US10581819B1 (en) * 2015-12-17 2020-03-03 Ca, Inc. Network traffic scanning of encrypted data
US11093617B2 (en) * 2017-10-04 2021-08-17 Servicenow, Inc. Automated vulnerability grouping
US10740471B2 (en) * 2018-06-05 2020-08-11 Rapid7, Inc. Vulnerability inference

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5528516A (en) * 1994-05-25 1996-06-18 System Management Arts, Inc. Apparatus and method for event correlation and problem reporting
US5913024A (en) * 1996-02-09 1999-06-15 Secure Computing Corporation Secure server utilizing separate protocol stacks
US5949973A (en) * 1997-07-25 1999-09-07 Memco Software, Ltd. Method of relocating the stack in a computer system for preventing overrate by an exploit program
US6088804A (en) * 1998-01-12 2000-07-11 Motorola, Inc. Adaptive system and method for responding to computer network security attacks
WO1999066383A2 (en) * 1998-06-15 1999-12-23 Dmw Worldwide, Inc. Method and apparatus for assessing the security of a computer system
EP0999489A2 (de) * 1998-11-06 2000-05-10 Citibank, N.A. Verfahren und System zur Auswertung von Informationssicherheit
US6871284B2 (en) * 2000-01-07 2005-03-22 Securify, Inc. Credential/condition assertion verification optimization
EP1269286B1 (de) * 2000-03-03 2008-11-19 International Business Machines Corporation System zur bestimmung von schwächen von web-anwendungen
WO2001084285A2 (en) * 2000-04-28 2001-11-08 Internet Security Systems, Inc. Method and system for managing computer security information
US20020116639A1 (en) * 2001-02-21 2002-08-22 International Business Machines Corporation Method and apparatus for providing a business service for the detection, notification, and elimination of computer viruses
US6944775B2 (en) * 2001-07-26 2005-09-13 Networks Associates Technology, Inc. Scanner API for executing multiple scanning engines

Also Published As

Publication number Publication date
GB0224532D0 (en) 2002-11-27
GB2385168A (en) 2003-08-13
DE10249428B4 (de) 2005-01-27
US20030135749A1 (en) 2003-07-17

Similar Documents

Publication Publication Date Title
DE10249428B4 (de) Verfahren zum Definieren der Sicherheitsanfälligkeiten eines Computersystems
DE10249427A1 (de) System und Verfahren zum Definieren des Sicherheitszustands eines Computersystems
DE69922857T2 (de) Rechnersicherheit durch Virusuntersuchung
DE60016613T2 (de) Abschreckungssystem gegen aufschaltung und missbrauch
DE60115615T2 (de) System, einrichtung und verfahren zur schnellen paketfilterung und -verarbeitung
DE112004000428B4 (de) Verfahren und Systeme zum Verwalten von Sicherheitsrichtlinien
DE60111089T2 (de) Verfahren und Vorrichtung zum Analysieren von einer oder mehrerer Firewalls
DE60132833T2 (de) Computersystemschutz
DE60130902T2 (de) Verfahren zum Erkennen des Eindringens in ein Datenbanksystem
DE60213391T2 (de) Persönlicher Firewall mit Positionsdetektion
DE60102555T2 (de) Verhinderung der map-aktivierten modulmaskeradeangriffe
DE19741239C2 (de) Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren
DE112013000387B4 (de) Dynamisches Abtasten einer Webanwendung durch Verwendung von Webdatenverkehrs- Informationen
DE112011101831B4 (de) Schutz vor websiteübergreifenden Scripting-Attacken
DE112011103273B4 (de) Verfahren, Computerprogrammprodukt und Vorrichtung zur Weitergabe von Identitäten über Anwendungsebenen unter Verwendung von kontextabhängiger Zuordnung und gesetzten Werten
EP3251012B1 (de) Prüfsystem zur prüfung eines computers eines computersystems in einem prüfnetzwerk
DE69919560T2 (de) Verfahren und system zur vorbeugung von unerwüschten betätigungen von ausführbaren objekten
EP1298529A2 (de) Proxy-Einheit und Verfahren zum rechnergestützten Schützen eines Applikations-Server-Programms
WO2003025758A2 (de) Vorrichtung und verfahren zur etablierung einer sicherheitspolitik in einem verteilten system
DE10241974B4 (de) Überwachung von Datenübertragungen
DE60302003T2 (de) Handhabung von zusammenhängenden Verbindungen in einer Firewall
DE10249426A1 (de) System und Verfahren zum Definieren von unbefugtem Eindringen auf ein Computersystem
DE19734585C2 (de) Verfahren und Vorrichtung zur Überwachung von Informationsflüssen in Computersystemen
DE10346923A1 (de) Ein Verfahren zum Schützen der Sicherheit von Netzwerkeindringungs-Erfassungssensoren
CH715183B1 (de) Penetrationstestverfahren zum Prüfen der Vulnerabilität eines Computersystems.

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8327 Change in the person/name/address of the patent owner

Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE

8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee