DE10249427A1 - System und Verfahren zum Definieren des Sicherheitszustands eines Computersystems - Google Patents

System und Verfahren zum Definieren des Sicherheitszustands eines Computersystems

Info

Publication number
DE10249427A1
DE10249427A1 DE10249427A DE10249427A DE10249427A1 DE 10249427 A1 DE10249427 A1 DE 10249427A1 DE 10249427 A DE10249427 A DE 10249427A DE 10249427 A DE10249427 A DE 10249427A DE 10249427 A1 DE10249427 A1 DE 10249427A1
Authority
DE
Germany
Prior art keywords
attack
specifying
security
specified
definition
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
DE10249427A
Other languages
English (en)
Other versions
DE10249427B4 (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 DE10249427A1 publication Critical patent/DE10249427A1/de
Application granted granted Critical
Publication of DE10249427B4 publication Critical patent/DE10249427B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die vorliegende Erfindung umfaßt ein Verfahren zum Bestimmen von Sicherheitszuständen eines Computersystems. Das Verfahren umfaßt die Schritte des Spezifizierens einer Identität eines Angriffs, des Spezifizierens zumindest einer Eigenschaft des spezifizierten Angriffs und des Spezifizierens zumindest einer Taktikdefinition bezüglich des spezifizierten Angriffs und des Spezifizierens zumindest einer Eigenschaft der spezifizierten Taktikdefinition.

Description

  • Die vorliegende Erfindung bezieht sich allgemein auf das Gebiet der Computersysteme und insbesondere auf ein System und Verfahren zum Definieren des Sicherheitszustands 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 des Sicherheitszustands 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 Sicherheitszuständen eines Computersystems, das Angriffen ausgesetzt wird, die Schritte des Spezifizierens einer Identität eines Angriffs, des Spezifizierens zumindest einer Eigenschaft des spezifizierten Angriffs, des Spezifizierens zumindest einer Taktik-(Policy-)Definition bezüglich des spezifizierten Angriffs, des Spezifizierens zumindest eines Attributs der spezifizierten Taktik.
  • Bei einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ist ein Verfahren zum Definieren von Anfälligkeitszuständen eines Systems, das mit einem globalen Netzwerk gemäß einem vorbestimmten Format gekoppelt ist, vorgesehen. Das Verfahren umfaßt die Schritte des Spezifizierens eines Namens eines Angriffs, des Spezifizierens zumindest eines Attributs des spezifizierten Angriffs, des Spezifizierens einer Taktikdefinition bezüglich des spezifizierten Angriffs und das Spezifizieren zumindest eines Attributs der spezifizierten Taktikdefinition.
  • Bei noch einem weiteren Ausführungsbeispiel der vorliegenden Erfindung umfaßt ein System zum Definieren von Sicherheitszuständen eines Computersystems gemäß einem vorbestimmten Format eine Anfälligkeitsbeschreibungsdatei, die eine Definition von zumindest einem Angriff und eine Definition von zumindest einer Taktik für den Angriff enthält. Das System umfaßt außerdem einen Interpretierer, der wirksam ist, um die Angriffs- und die Taktikelementdefinition in der Anfälligkeitsbeschreibungsdatei syntaktisch zu analysieren, und die syntaktisch analysierten Definitionen gemäß einem vorbestimmten Format zu organisieren. Die syntaktisch analysierten und organisierten Angriffs- und Taktikelementdefinitionen werden für einen Zugriff durch eine oder mehrere Sicherheitsanwendungen in einem Datenspeicher gespeichert.
  • 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 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 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 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 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 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 Produktdokumentation für den Windows NT 4,0 OptionPack". Dieses Feld ist vorzugsweise ebenfalls vorgeschrieben. Das <allgemeine Ergebnisse Text>-Feld enthält eine Zeichenfolge, die in dem allgemeinen Ergebnisfenster angezeigt werden soll. Für einen Anfälligkeitsscanner sollte es die Ergebnisse einer Sicherheitsprüfung 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 DetailedResultsGridSteuerung 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(allgemeine 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(SicherheitsIDKategorie)-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 Standardtext- basierte 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 des Sicherheitszustands eines Computersystems (30), das folgende Schritte umfaßt:
Spezifizieren einer Identität eines Angriffs (300, 324);
Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (318);
Spezifizieren zumindest einer Taktikdefinition (310) bezüglich des spezifizierten Angriffs; und
Spezifizieren zumindest einer Eigenschaft (314) der spezifizierten Taktikdefinition.
2. Verfahren gemäß Anspruch 1, das ferner folgende Schritte umfaßt:
Spezifizieren einer Rechenplattform (322) des Computersystems; und
Spezifizieren einer Datensignatur (318) des spezifizierten Angriffs auf der Rechenplattform.
3. Verfahren gemäß Anspruch 1 oder 2, das ferner folgende Schritte umfaßt:
Spezifizieren einer Sicherheitskategorie (300) des spezifizierten Angriffs; und
Spezifizieren zumindest einer Taktikgruppe (300) bezüglich der spezifizierten Sicherheitskategorie.
4. Verfahren gemäß einem der Ansprüche 1 bis 3, das ferner das Spezifizieren eines Sicherheitsprodukts (326) umfaßt, das auf dem Rechensystem ausgeführt wird.
5. Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (318) das Spezifizieren einer Identifikation der Heftigkeit umfaßt, die einer Verletzung des Computersystems durch den spezifizierten Angriff zugeordnet ist.
6. Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (318) das Spezifizieren einer Beschreibung des Angriffs (318) umfaßt.
7. Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (318) das Spezifizieren einer Erklärung umfaßt, weshalb der spezifizierte Angriff wichtig ist.
8. Verfahren gemäß einem der Ansprüche 1 bis 7, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (318) das Spezifizieren umfaßt, wie Informationen bezüglich des spezifizierten Angriffs (302, 304, 306, 308) dem Benutzer berichtet werden sollen.
9. Verfahren gemäß einem der Ansprüche 1 bis 8, bei dem das Spezifizieren zumindest einer Eigenschaft des spezifizierten Angriffs (318) das Spezifizieren einer Anwendung umfaßt, die wirksam ist, um auf eine Verletzung des Computersystems (300, 326) durch den spezifizierten Angriff anzusprechen.
10. Verfahren gemäß einem der Ansprüche 1 bis 9, bei dem das Spezifizieren einer Signatur des spezifizierten Angriffs (318) folgende Schritte umfaßt:
Spezifizieren eines Netzwerkprotokolls;
Spezifizieren einer Datenstruktur; und
Spezifizieren einer Aktion ansprechend auf das Erfassen des spezifizierten Netzwerkprotokolls und der Datenstruktur.
DE10249427A 2001-10-31 2002-10-23 Verfahren zum Definieren des Sicherheitszustands eines Computersystems Expired - Fee Related DE10249427B4 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/001,431 US20030159060A1 (en) 2001-10-31 2001-10-31 System and method of defining the security condition of a computer system

Publications (2)

Publication Number Publication Date
DE10249427A1 true DE10249427A1 (de) 2003-05-15
DE10249427B4 DE10249427B4 (de) 2005-04-28

Family

ID=21695982

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10249427A Expired - Fee Related DE10249427B4 (de) 2001-10-31 2002-10-23 Verfahren zum Definieren des Sicherheitszustands eines Computersystems

Country Status (3)

Country Link
US (1) US20030159060A1 (de)
DE (1) DE10249427B4 (de)
GB (1) GB2385689A (de)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7853833B1 (en) * 2000-09-08 2010-12-14 Corel Corporation Method and apparatus for enhancing reliability of automated data processing
US6947726B2 (en) * 2001-08-03 2005-09-20 The Boeing Company Network security architecture for a mobile network platform
US7359962B2 (en) * 2002-04-30 2008-04-15 3Com Corporation Network security system integration
US20040064722A1 (en) * 2002-10-01 2004-04-01 Dinesh Neelay System and method for propagating patches to address vulnerabilities in computers
US7188369B2 (en) * 2002-10-03 2007-03-06 Trend Micro, Inc. System and method having an antivirus virtual scanning processor with plug-in functionalities
US7454499B2 (en) 2002-11-07 2008-11-18 Tippingpoint Technologies, Inc. Active network defense system and method
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
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
US9197668B2 (en) * 2003-02-28 2015-11-24 Novell, Inc. Access control to files based on source information
US7516476B1 (en) * 2003-03-24 2009-04-07 Cisco Technology, Inc. Methods and apparatus for automated creation of security policy
US8984644B2 (en) 2003-07-01 2015-03-17 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
US20070113272A2 (en) 2003-07-01 2007-05-17 Securityprofiling, Inc. Real-time vulnerability monitoring
US9350752B2 (en) 2003-07-01 2016-05-24 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US9118709B2 (en) 2003-07-01 2015-08-25 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
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
US9100431B2 (en) 2003-07-01 2015-08-04 Securityprofiling, Llc Computer program product and apparatus for multi-path remediation
KR100558658B1 (ko) * 2003-10-02 2006-03-14 한국전자통신연구원 인-라인 모드 네트워크 침입 탐지/차단 시스템 및 그 방법
US7665119B2 (en) * 2004-09-03 2010-02-16 Secure Elements, Inc. Policy-based selection of remediation
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
US7761920B2 (en) * 2004-09-03 2010-07-20 Fortinet, Inc. Data structure for policy-based remediation selection
US20060018478A1 (en) * 2004-07-23 2006-01-26 Diefenderfer Kristopher G Secure communication protocol
US7765594B1 (en) * 2004-08-18 2010-07-27 Symantec Corporation Dynamic security deputization
US7703137B2 (en) * 2004-09-03 2010-04-20 Fortinet, Inc. Centralized data transformation
US7672948B2 (en) * 2004-09-03 2010-03-02 Fortinet, Inc. Centralized data transformation
US20060080738A1 (en) * 2004-10-08 2006-04-13 Bezilla Daniel B Automatic criticality assessment
US7895651B2 (en) 2005-07-29 2011-02-22 Bit 9, Inc. Content tracking in a network security system
US8984636B2 (en) 2005-07-29 2015-03-17 Bit9, Inc. Content extractor and analysis system
US8272058B2 (en) 2005-07-29 2012-09-18 Bit 9, Inc. Centralized timed analysis in a network security system
US8166547B2 (en) * 2005-09-06 2012-04-24 Fortinet, Inc. Method, apparatus, signals, and medium for managing a transfer of data in a data network
US7945955B2 (en) 2006-12-18 2011-05-17 Quick Heal Technologies Private Limited Virus detection in mobile devices having insufficient resources to execute virus detection software
US7917085B2 (en) * 2007-11-09 2011-03-29 Research In Motion Limited System and method for blocking devices from a carrier network
CN101499934A (zh) * 2008-01-29 2009-08-05 华为技术有限公司 在对等网络中诊断节点是否异常的方法、装置及系统
US9304955B2 (en) * 2012-12-18 2016-04-05 Advanced Micro Devices, Inc. Techniques for identifying and handling processor interrupts
US10382208B2 (en) * 2016-04-29 2019-08-13 Olympus Sky Technologies, S.A. Secure communications using organically derived synchronized processes
CN110636145B (zh) * 2018-06-22 2021-11-12 上海诺基亚贝尔股份有限公司 通信方法、设备和装置以及计算机可读存储介质
US10642979B1 (en) * 2019-09-19 2020-05-05 Capital One Services, Llc System and method for application tamper discovery

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2706652B1 (fr) * 1993-06-09 1995-08-18 Alsthom Cge Alcatel Dispositif de détection d'intrusions et d'usagers suspects pour ensemble informatique et système de sécurité comportant un tel dispositif.
US6279113B1 (en) * 1998-03-16 2001-08-21 Internet Tools, Inc. Dynamic signature inspection-based network intrusion detection
JP4700884B2 (ja) * 2000-04-28 2011-06-15 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータのセキュリティ情報を管理するための方法およびシステム
GB0022485D0 (en) * 2000-09-13 2000-11-01 Apl Financial Services Oversea Monitoring network activity
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
US7308715B2 (en) * 2001-06-13 2007-12-11 Mcafee, Inc. Protocol-parsing state machine and method of using same

Also Published As

Publication number Publication date
US20030159060A1 (en) 2003-08-21
GB0224536D0 (en) 2002-11-27
DE10249427B4 (de) 2005-04-28
GB2385689A (en) 2003-08-27

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
DE60111089T2 (de) Verfahren und Vorrichtung zum Analysieren von einer oder mehrerer Firewalls
DE60115615T2 (de) System, einrichtung und verfahren zur schnellen paketfilterung und -verarbeitung
DE60123672T2 (de) Computersystemschutz
DE112004000428B4 (de) Verfahren und Systeme zum Verwalten von Sicherheitsrichtlinien
DE60130902T2 (de) Verfahren zum Erkennen des Eindringens in ein Datenbanksystem
DE19741239C2 (de) Verallgemeinertes Sicherheitspolitik-Management-System und Verfahren
DE60102555T2 (de) Verhinderung der map-aktivierten modulmaskeradeangriffe
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
WO2003025758A2 (de) Vorrichtung und verfahren zur etablierung einer sicherheitspolitik in einem verteilten system
EP1298529A2 (de) Proxy-Einheit und Verfahren zum rechnergestützten Schützen eines Applikations-Server-Programms
DE10241974B4 (de) Überwachung von Datenübertragungen
DE60302003T2 (de) Handhabung von zusammenhängenden Verbindungen in einer Firewall
EP3824612B1 (de) Penetrationstestverfahren, computerprogramm und vorrichtung zur datenverarbeitung
DE10249426A1 (de) System und Verfahren zum Definieren von unbefugtem Eindringen auf ein Computersystem
DE10346923A1 (de) Ein Verfahren zum Schützen der Sicherheit von Netzwerkeindringungs-Erfassungssensoren
DE19734585C2 (de) Verfahren und Vorrichtung zur Überwachung von Informationsflüssen in Computersystemen
WO2022128829A1 (de) Gateway, speziell für ot-netzwerke
DE60031004T2 (de) Elektronisches sicherheitssystem und verfahren für ein kommunikationsnetz
LU500837B1 (de) Verfahren und zugehörige Computersysteme zur Sicherung der Integrität von Daten

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