DE60313987T2

DE60313987T2 - Herstellung von regeln zur filterung von computerapplikationen

Info

Publication number: DE60313987T2
Application number: DE60313987T
Authority: DE
Inventors: Richard Toronto Ontario Reiner
Original assignee: Telus Communications Inc
Current assignee: Telus Communications Inc
Priority date: 2002-10-02
Filing date: 2003-10-01
Publication date: 2008-01-24
Anticipated expiration: 2023-10-02
Also published as: WO2004032445A2; ATE363174T1; JP2006501551A; AU2003271479A1; CA2500305A1; EP1547335A2; EP1547335B1; DE60313987D1; WO2004032445A3; US20060104202A1; AU2003271479A8

Description

Hintergrund der Erfindung
Diese Erfindung bezieht sich auf die Erleichterung der Regelerzeugung zum Abschirmen von Anfragen bzw. Anforderungen an eine Computeranwendung.
In Computernetzwerken wird Information in herkömmlicher Weise in der Form von Paketen bzw. Datenpaketen übertragen. Der Informationsfluss ist typischerweise in der Form einer an eine Computeranwendung gerichteten Anfrage bzw. Anforderung und einer Antwort auf die Anfrage durch die Anwendung. Wenn die Datenpakete von einer nicht vertrauenswürdigen Quelle eintreffen, wie etwa das öffentliche Internet, besteht ein Risiko, dass sie unzulässige Anfragen an die Computeranwendung umfassen oder enthalten. Eine derartige unzulässige Anfrage kann einen nichtautorisierten Versuch erzeugen, auf geschützte Information zuzugreifen, einen nichtautorisierten Versuch, Information zu verändern, oder einen Versuch, in den normalen Betriebsablauf der Anwendung störend einzugreifen (ein sogenannter "Dienstverweigerungs-Angriff").
Eine Anwendung auf einem Computer kann vor unzulässigen Anfragen durch ein Computer-Zugangsschutzsystem bzw. eine Firewall, die für die Anwendung bestimmte Datenpakete filtert, abgeschirmt werden. Genauer gesagt untersucht die Firewall Datenpakete und gibt sie entweder an die Anwendung weiter oder unterdrückt sie in Abhängigkeit davon, ob sie einem Satz vorbestimmter Zugriffsregeln entsprechen. Bekannte Firewalls zur Paketfilterung können Regeln anwenden auf die Nachrichtenköpfe der Datenpakete von einem oder mehreren der Verbindungsebenen, Netzwerkebenen und Transportebenen, um die verwendeten Protokolle zu überprüfen.
Ein anderer Ansatz zum Abschirmen einer Anwendung vor unzulässigen Anfragen ist es, eine Proxy-Firewall einzusetzen. Eine Proxy-Firewall wirkt als die Zieladresse für Datenpakete, die durch ein öffentliches Netzwerk eintreffen, und streift von jedem Datenpaket den Overhead ab, der zum Dirigieren des Datenpaketes durch das öffentliche Netzwerk hindurch verwendet worden ist. Mit diesem Ansatz werden jegliche Angriffe, die den Netzwerk-Overhead von Datenpaketen benutzen, vermieden. Bekannte Proxy-Firewalls können auch Regeln zum Überprüfen des Anwendungsprotokolls anwenden.
Obwohl paketfilternde Firewalls und Proxy-Firewalls darin effektiv waren, dass sie viele unzulässige Anforderungen abgeschirmt haben, treten immer noch erfolgreiche "Angriffe" auf, die derartige Zugangsschutzsysteme durchbrechen. Folglich besteht eine Notwendigkeit für Zugriffsregeln, die eine effektivere Abschirmung von Anforderungen an eine Computeranwendung ermöglichen.
US 6,311,278 , erteilt an Moran, offenbart ein Programm, das eine Kopie einer von einer Serveranwendung zu einem Client gesendeten Nachricht anfertigt und die Nachricht dann analysiert, um Anweisungen, Felder oder andere durch einen Benutzer wählbare Optionen für die Anwendung zu identifizieren: Diese stellen einen Satz von zulässigen Benutzeraktionen dar, was als ein Anwendungsprotokoll bezeichnet wird. Diese Protokolldaten werden dann gespeichert in einer Datenbank, die für einen Filter zugänglich ist, der die Protokolldaten verwendet, um zu bestimmen, ob eine von einem Client an den Server gesendete Nachricht auszufiltern ist. Der zulässige Satz von Aktionen kann vergrößert werden mit Information von anderen von dem Server an einen Client gesendeten Nachrichten. Die Protokolldaten können auf einer Sitzung-zu-Sitzung Basis gespeichert werden, d.h. ein Satz von zulässigen Aktionen kann in Assoziation mit Daten, die einen Client identifizieren, gespeichert werden, in welchem Fall die Protokolldaten von dem Filtermodul verwendet werden, um eine Protokoll-Richtlinie für jede einzelne Client-Server-Sitzung durchzusetzen.
GB 2,365,668 , erteilt an IBM, offenbart eine Verfahrensweise zum Klassifizieren eines Datenpakets unter Verwendung eines Klassifizierungsbaumes. Ausgehend von dem Hauptknoten wird das Datenpaket nacheinander zu jedem Nachfolgerknoten des Wurzelknotens weitergeleitet, bis ein bestimmter Nachfolgerknoten eine Satisfaktion mit seinen Knotenkriterien anzeigt. Die Datenpaketdaten werden dann nacheinander zu jedem Nachfolgerknoten des gegebenen Knotens weitergeleitet, bis ein Knoten eine Satisfaktion mit seinen Knotenkriterien anzeigt, usw. Nachdem das Datenpaket seine Reise durch den Baum vervollständigt hat oder in dem Baum nicht weiter vorankommen kann, ist das Datenpaket klassifiziert worden. Die Klassifizierung der Paketdaten kann benutzt werden, um eine Einsatzortrichtlinie, wie etwa eine Sicherheitsrichtlinie, umzusetzen.
Zusammenfassung der Erfindung
Um die Erzeugung von Regeln zum Abschirmen von Anwendungsebenen-Anfragen bzw. Anforderungen an eine Computeranwendung zu erleichtern, wird ein Probenraum von Anwendungs-Layer-Anfragen gemäß einem oder mehreren Gruppierungskriterien gruppiert. Jedes Gruppierungskriterium kann ein Merkmal einer Anwendungs-Layer-Anfrage sein, so dass jede Gruppierung Anwendungs-Layer-Anfragen mit einem gemeinsamen Merkmal enthält. Beispielsweise wo die Anwendungs-Layer-Anfragen dem Hyper-Texttransportprotokoll (HTTP, Englisch: Hyper-Text Transport Protocol) folgen, könnte ein gemeinsa mes Merkmal für einige Gruppierungen eine gemeinsame URI-Pfadnamen-Alonge sein.
Nach der vorliegenden Erfindung wird ein Verfahren bereitgestellt zum Erzeugen von Regelsätzen zum Abschirmen von Anwendungs-Layer-Anfragen bzw. Anforderungen bzw. für Layer-Anfragen in Abschirmungsanwendungen, wobei Anwendungs-Layer-Anfragen (10, 10', 10'') aus einem Probenraum von Anwendungs-Layer-Anfragen durch ein Merkmal der Anfragen gruppiert werden, gekennzeichnet durch: Empfangen eines Satzes von Datenmasken (54a, 54b, 54c), die für jeden Typ von Bestandteilen (12, 14, 16, 18, 20, 12', 14', 16', 18', 20', 25', 12'', 14'', 16'', 18'', 25'', 18a''', 25''') von derartigen Anfragen anwendbar sind; Erhalten bzw. Beschaffen eines Regelsatzes (5) für jede Anfragengruppierung durch: für jeden Typ von Bestandteilen der Anfragen, Identifizieren von Namen (24', 24'') und damit assoziierter Datenelemente (26', 26''), die in Anfragen der jeweiligen Anfragegruppe bestimmt werden; für jeden Namen: Erhalten bzw. Beschaffen einer Probengruppe von Datenelementen, wobei jedes Datenelement mit einem Auftreten des jeweiligen Namens assoziiert ist; Abgleichen der Probengruppe von Datenelementen mit einer vordefinierten Datenelementmaske; und Verknüpfen einer Regel (92), die mit der passenden Datenmaske für jeden Namen assoziiert ist.
Nach einem anderen Aspekt der Erfindung wird ein System bereitgestellt zum Erzeugen eines Regelsatzes zum Abschirmen von Anwendungs-Layer-Anfragen, umfassend: Mittel zum Gruppieren von Anwendungs-Layer-Anfragen (10, 10', 10'') aus einem Probenraum von Anwendungs-Layer-Anfragen durch ein Merkmal der Anforderungen; gekennzeichnet durch: Mittel zum Empfangen eines Satzes von Datenmasken (54a, 54b, 54c), die für jeden Typ von Bestandteilen (12, 14, 16, 18, 20, 12', 14', 16', 18', 20', 25', 12'', 14'', 16'', 18'', 25'', 18a''', 25''') der Anfragen anwendbar ist; Mittel zum Er halten bzw. Beschaffen eines Regelsatzes (5) für jede Anforderungsgruppierung durch: für jeden Typ von Bestandteilen der Anfragen, Identifizieren von Namen (24, 24'') und damit assoziierten Datenelementen (26', 26''), die in Anfragen von jeder Anfragegruppierung gefunden bzw. bestimmt werden: für jeden Namen: Erhalten bzw. Beschaffen einer Probengruppe von Datenelementen, wobei jedes Datenelement, das mit einem Auftreten des jeweiligen Namens assoziiert ist; Abgleichen der Probengruppe von Datenelementen mit einer vorbestimmten Datenelementmatrize bzw. – maske; und Verknüpfen einer Regel (92), die mit der für jeden Namen passenden Datenmaske assoziiert ist.
Zugehörige Systeme und computerlesbare Medien werden ebenfalls bereitgestellt.
Andere Merkmale und Vorteile werden nach einer Durchsicht der folgenden Beschreibung zusammen mit den Zeichnungen offensichtlich.
Kurze Beschreibung der Zeichnungen
In den Figuren, die Beispielausführungsformen der Erfindung beschreiben, gilt: 1A, 1B, 1C und 1D veranschaulichen die Inhalte von beispielhaften HTTP Anfragen;
2 ist ein Beispiel eines Teils einer Regelmaske gemäß dieser Erfindung in menschenlesbarer Form;
3 ist eine schematische Ansicht eines Systems, das Ausführungsformen dieser Erfindung einsetzt;
4 ist ein Ablaufdiagramm, das den Betrieb eines Teils des Systems der 3 veranschaulicht; und
5 ist ein Beispiel eines Teils eines Regelsatzes gemäß dieser Erfindung in menschenlesbarer Form.
Ausführliche Beschreibung
Pakete, die über das Internet übertragen worden sind, umfassen eine Verbindungsebene auf oberster Ebene, eine Netzwerkebene auf einem niedrigeren Niveau und eine Anwendungsebene auf einem unteren Niveau. Jeder der höheren Ebenen bzw. Lager ist im Wesentlichen ein Datenpaket. Folglich ist die Verbindungsebene ein Datenpaket mit einem Nachrichtenkopf und Daten, die ein Netzwerkebenenpaket umfassen,, und das Netzwerkebenendatenpaket weist einen Nachrichtenkopf und Daten auf, die ein Transportebenendatenpaket umfassen. Der Nachrichtenkopf der Verbindungsebene zeigt nahezu ausnamslos, dass das Protokoll, dem das Datenpaket folgt, das Internetprotokoll (IP) ist (ältere Protokolle sind heutzutage im Wesentlichen überholt und oder nicht in Verwendung im Internet). Wo das Datenpaket ein IP Datenpaket ist, ist die Netzwerkebene als ein IP Datagramm bekannt. Der Nachrichtenkopf der Transportebene wird das Transportprotokoll anzeigen, wobei das Transportsteuerungsprotokoll (TCP, Englisch: Transport Control Protocol) des IP das bei weitem verbreitetste Transportprotokoll ist, weil es zum Durchsuchen des Webs, für E-Mail und für Web-Dienste verwendet wird (wie das durch die Fachmänner in dem technischen Gebiet anerkannt wird, sind Web-Dienste Interaktionen von Maschine zu Maschine, wobei eine Anwendung Anfragen an andere Anwendungen ausführen kann).
Die Daten eines Transportebenen-Datenpakets umfassen die Anwendungsebene (die typischerweise über eine Anzahl von Transportebenen-Datenpaketen verteilt ist). Die Nummer des Ports an der Transportebene und/oder dem Kontext gibt einen Hinweis auf das Protokoll der Anwendungsebene. Wo das Transportprotokoll TCP ist, während das Protokoll der Anwendungsebene ein beliebiges von vielfältigen Anwendungsebenenprotokollen sein kann, sind die wichtigsten: Hyper- Textübertragungsprotokoll (HTTP, Englisch: Hyper-Text Transfer Protocol), gesichertes HTTP (HTTPS), Dateiübertragungsprotokoll (FTP, Englisch: File Transfer Protocol) und einfaches Mailübertragungsprotokoll (SMTP, Englisch: Simple Mail Transfer Protocol).
Bekannte Zugangsschutzsysteme bzw. Firewalls zum Filtern von Datenpaketen wenden Regeln an auf die Nachrichtenköpfe von Datenpaketen von einem oder mehreren der Verbindungsebenen, der Netzwerkebenen und der Transportebenen, um die benutzten Protokolle zu überprüfen. Bekannte Proxy-Firewalls können das Anwendungsprotokoll überprüfen. Eine jegliche der von den bekannten Firewalls zur Paketfilterung und Proxy-Firewalls angewendeten Regel weist eine Form auf, die "einfach universal" bezeichnet werden kann. Zur Erläuterung: Eine Regel spezifiziert einen Typ von Elementen, auf die sie angewendet wird. Die Regel ist eine einfach universale Regel, wenn sie auf alle Elemente des von der Regel spezifizierten Typs angewendet wird. Als ein Beispiel, in der Regel "alle Datenpakete müssen auf die Zielportnummer 80 adressiert sein", ist das Element, auf das die Regel angewendet wird, ein Datenpaket. Und weil diese Regel auf alle Datenpakete angewendet wird, ist sie eine einfache universale Regel.
Derzeit wird HTTP (oder HTTPS) zum Durchsuchen des Webs und für Web-Dienste verwendet. Eine HTTP Anforderung weist die folgende allgemeine Form auf:
<Verfahren> <URI> <HTTP Version>
<HTTP Nachrichtenköpfe mit eingebetteten Cookies>
<Hauptteil der Anfrage>
wobei "URI" einen Universalquellenbezeichner (Englisch: Universal Resource Identifier) bezeichnet. Der URI ist eine Verbindung zu einer Einheit im Web und ist gewöhnlich eine universale Internetadresse (URL, Englisch: Universal Re source Locator). Der URI enthält auch alle möglichen URI Parameter, die auch als GET Felder bekannt sind. Es können null oder mehrere Nachrichtenköpfe und null oder mehrere Cookies in der HTTP Anfrage enthalten sein. Der Hauptteil ist optional, und falls vorhanden, kann ein gemäß URI-codiertes Format, ein Formular mit mehrteilig codiertem Format, ein einfaches Objektzugangsprotokoll (SOAP, Englisch: Simple Object Access Protocol)-Format aufweisen, oder der Hauptteil kann einen nicht-strukturierten Inhalt aufweisen. Ein Hauptteil, der ein URI-codiertes Format oder ein Format mit mehrteiligem codierten Format aufweist, ist in Hyper-Textmarkierungssprache (HTML, Englisch: Hyper-Text Mark-up Language) oder erweitertem HTML (XHTML) geschrieben. Ein Hauptteil mit einem SOAP Format ist in erweiterbarer Markierungssprache (XML, Englisch: Extensible Mark-up Language) geschrieben.
Als Beispiel, sich der 1A zuwendend, weist eine HTTP Anfrage 10 die folgenden Bestandteile auf: ein GET Verfahren 12, eine URI 14, ein HTTP Versionsindikator 16 und Nachrichtenköpfe 18 mit darin eingebetteten Cookies 20. Diese besondere HTTP Anfrage weist keinen Hauptteil auf. Die URI besteht aus der URL 24 und URI Parametern 26.
Wie aus 1A ersichtlich sein wird, weist ein URI Parameter 26 das Format "Name"="Wert" auf (die beispielhafte HTTP Anfrage 10 weist zwei URI Parameter auf). Wie das typisch ist, identifizieren die URI Parameter die aktuelle Sitzung des Benutzers. Die Nachrichtenköpfe 18 weisen das Format "Name":"Wert" auf. Jedes Cookie weist ein Paar umfassend einen darin eingebetteten Namen und einen Wert auf, wobei jedes Paar durch einen Doppelpunkt getrennt ist. Folglich weisen Cookies 20 das Format: "Cookie":"Namel"="Wertl"; "Name2"="Wert2"; "Name3"="Wert3" ... auf.
1B veranschaulicht eine zweite beispielhafte HTTP Anfrage 10' mit einem POST Verfahren 12', einer URI 14', die keine URI Parameter aufweist, einem HTTP Versionsindikator 16' und Nachrichtenköpfen 18' mit einem eingebetteten Cookie 20'. Die HTTP Anfrage 10' weist ebenfalls einen Hauptteil 22' auf. Der Hauptteil besteht aus Feldern 25', die jeweils ein Paar umfassend einen Namen 24' und einen Wert 26' aufweisen. Der Nachrichtenkopf 18a' der Anfrage 10' zeigt an, dass der Hauptteil 22' ein URL-codiertes Format aufweist, folglich sind die Namen-Wert-Paare von der Form "Name"="Wert", wobei jedes Paar durch ein kaufmännisches Und-Zeichen [&] getrennt sind.
Die beispielhafte HTTP Anfrage 10'' der 1C weist die folgenden Bestandteile auf: eEin Verfahren 12'', eine URI 14'', einen HTTP Versionsindikator 16'', Nachrichtenköpfe 18'' und Felder 25'' des Hauptteils 22''. Es sei angemerkt, dass in den Nachrichtenköpfen keine Cookies eingebettet sind. Der Nachrichtenkopf 18a'' zeigt an, dass der Hauptteil 22'' ein codiertes Format in mehrteiliger Form aufweist. In einem Formular in mehrteiliger Form sind die Felder des Hauptteils als Teile bekannt. Der Nachrichtenkopf 18a'' spezifiziert eine Teilgrenze 28'', die jedes Teil abgrenzt. Eine Teilgrenze wird gefolgt durch eine oder mehrere Nachrichtenköpfe 30'', die den Namen 24'' des Datenfelds darin aufnehmen, gefolgt von dem Feldwert 26''.
Die beispielhafte HTTP Anfrage 10''' der 1D weist einen Nachrichtenkopf 18a'' auf, der anzeigt, dass der Hauptteil 22''' ein SOAP Format aufweist, so dass die Elemente 25''' der Bestandteile des Hauptteils folgendes umfassen: XML Elemente, deren Attribute und Datenobjekte gemäß der Spezifikation des SOAP Nachrichtenformats.
Es besteht eine Möglichkeit für ein Erzeugen einer nicht zulässigen Anfrage (der ein menschlicher Hacker oder eine Maschine sein kann), der beim Lancieren eines Angriffs auf eine Anwendung Bestandteile der tatsächlichen Nutzlastdaten (der Anwendungsebene) eines Datenpakets einsetzt. Folglich könnte ein Angriff Bestandteile einer HTTP Anfrage verwenden. Um derartige Angriffe zunichte zu machen, ist vorgesehen, Abschirmungsregeln für Bestandteile einer jeweiligen HTTP Anfrage zu erzeugen.
Der Ansatz für die Erzeugung von HTTP Abschirmungsregeln besteht darin, zunächst die Art der durch die Abschirmungsregeln zu schützenden Computeranwendung oder -anwendungen zu betrachten. Ein Regel-Entwerfer kann vielleicht nur allgemeine Kenntnis von allgemeinen Typen von Anwendungen haben. Oder der Entwickler kann Kenntnis der allgemeinen Domäne der abzuschirmenden Anwendungen) haben. Oder der Entwickler kann spezifische Kenntnis der Anwendung(en) haben. Die Kenntnis der Art der Datenelemente in Anwendungen (oder in einem Typ von Anwendung) kann aus den funktionellen Spezifikationen für diese (oder Proben von diesen) Anwendungen gewonnen werden; aufgrund dieser Art können Regelmasken geschrieben werden. Wo folglich der Regelentwickler von allgemeiner Kenntnis der gewöhnlichen Arten von Anwendungen ausgehend arbeitet, kann er/sie Regelmasken für allgemein angetroffene Datenelemente schreiben. Wo der Regelentwickler mit Kenntnis der allgemeinen Domäne der abzuschirmenden Anwendung(en) arbeitet, kann er/sie Regelmasken für Domänen-spezifische Datenelemente schreiben. Und wo der Regelentwickler mit Kenntnis der spezifischen, abzuschirmenden Anwendung(en) arbeitet, kann er/sie Regelmasken für anwendungsspezifische Datenelemente schreiben.
Web-Anwendungen beispielsweise, die Online Einkaufen oder einen Registrierungsprozess einschließen, kommen unausweichlich zu einem Punkt, wo sie ein Formular für einen Benutzer zum Ausfüllen und Einreichen präsentieren. Ein ausgefülltes Formular wird in einer Anfrage an die Anwendung in einem URL-codierten Format oder in einem codierten Format mit mehrteiliger Form ausgeführt. Die Felder des Hauptteils werden Namendaten, Adressdaten, Postleitzahlen (oder postalische Code)-Daten und typischerweise eine Telefonnummer aufweisen. Die Datenelemente dieser Felder können als gemeinhin in Datenelementen gefundene Daten angesehen werden.
Nimmt man eine Telefonnummer als ein Beispiel, dann kann der Regelentwickler eine Regelmaske für derartige Nummern enthaltende Felder schreiben. Ein Beispiel einer derartigen Regelmaske, geschrieben in menschlich lesbarer Form, wird in 2 veranschaulicht. (In der Praxis werden Regelmasken in symbolischerer Form geschrieben, wie etwa durch Verwendung einer Mustersprache, die als Regular Expressions (übersetzt etwa reguläre Ausdrücke) bekannt ist.) Sich der 2 zuwendend, weist eine Regelmaske 50 eine Anweisung 52 ihrer Anwendung auf, gefolgt von einer Serie von Datenelementmasken: eine Datenelementmaske 54a für Telefonnummern im nordamerikanischen Format; eine Datenelementmaske 54b für Telefonnummern im internationalen Format, und eine Datenelementmaske 54c für gebührenfreie Telefonnummern.
Wenn die Domäne der abzuschirmenden Anwendung(en) dafür bekannt ist, dass sie diejenige von Produktkatalogen ist, dann wird es Regelmasken geben, die für Datenelemente geschrieben sind, die spezifisch für Produktkataloge sind, wie etwa universale Preiscodierungen (UPC, Englisch: Universal Pricing Codes). In ähnlicher Weise wird es für Anwendungen vom Typ für Reisebuchungen Regelmasken geben, die für bei Reisebuchungen spezifische Datenelemente geschrieben sind, wie etwa die Codes von internationalen Flughäfen. Wenn die Art der abzuschirmenden, spezifischen Anwendung bekannt ist, dann gibt es Regelmasken, die spezifisch für diese Anwendung sind, wie etwa das erforderliche Format für eine Benutzer-ID.
Zusätzlich zu jeder der vorgenannten Regelmasken, die geschrieben werden können, wird der Regelentwickler zusammenfassende Regelmasken (Englisch: Abstract Rule Templates) schreiben für Datenelemente, die nicht von einer der vorgenannten spezifischeren Masken angepasst werden. (Folglich ist die Anweisung der Anwendung der zusammenfassenden Regelmaske die, dass sie für Datenelemente gilt, die nicht in anderer Weise abgeglichen werden.) Die Datenelementmaske für diese Regelmaske kann folgendes enthalten:

• eine Maske für numerische Daten
• eine Maske für alphabetische Daten
• eine Maske für alphanumerische Daten
• eine Maske für druckbare ASCII Zeichenketten
• eine Maske für allgemeine ASCII Zeichenketten
• eine Maske für UTF-8 Zeichenketten
• eine Maske für UCS-16 Zeichenketten

Diese Datenmasken sind aus Gründen, die im Folgenden offensichtlich werden, von spezifischer nach weniger spezifisch geordnet worden. Tatsächlich gilt, dass allgemein für eine beliebige Regelmaske, wo das Format von einigen der Datenmasken für die Regelmaske spezifischer als andere sind, dass Datenmasken von am spezifischsten zu am wenigsten spezifisch geordnet sind.
Mit Verweis auf 3 können Regelmasken für Domänen oder für gemeinhin angetroffene Datenelemente im voraus geschrieben und in einer in einer geeigneten Weise indexierten Datenbank 70 gespeichert werden. Die Datenbank kann mit einem Regelerzeuger 72 verbunden werden, der ein allgemeiner Computersein kann, der mit Regelerzeugungssoftware, die in einem computerlesbaren Medium 76, wie etwa einer Computerdiskette, einem Nur-Lese-Speicher (ROM) Chip oder einem von einer abgesetzten Quelle heruntergeladenen Datei, ausgeführt ist. Der Regelerzeuger ist auch verbunden zur Kommunikation mit einer Entwicklerschnittstelle 78 und mit einer Abschirmungsvorrichtung 82; der Regelerzeuger kann Daten über die Kommunikationsleitung 80 empfangen. Die Datenbank 70 speichert einen Probenraum von HTTP Anfragen, die für eine oder mehrere abzuschirmende Computeranwendungen gedacht sind. Die Anfragen des Probenraums sind entweder Teil der Computerpakete, die auf die Anwendung(en) adressiert ist, was Abschirmungsregeln erfordert, oder die aus derartigen Computerdatenpaketen abgestreift worden sind. Die Anfragen für den Probenraum. können auf der Kommunikationsleitung 80 empfangen werden und von der Datenbank in den Probenraum akkumuliert werden. Es wird angenommen, dass der Probenraum legitimierte Benutzungen von der einen oder mehreren Anwendungen repräsentiert. Folglich wird der Probenraum typischerweise erzeugt bevor Anfragen von einer nicht vertrauenswürdigen Quelle empfangen werden.
Mit Verweis auf 4, die den Betrieb des Regelerzeugers 72 veranschaulicht, um Regeln für die eine Abschirmung erfordernde(n) Anwendungen(en) zu erzeugen, kann ein Regelentwicklung über die Schnittstelle 78 dem Regelgenerator 72 geeignete Regelmuster in der Datenbank anweisen (S110). Zusätzlich kann der Entwickler weitere Regelmasken entwerfen, die für die abzuschirmende Anwendung(en) spezifische Regelmasken erzeugen und diese durch die Schnittstelle 78 zu dem Regelgenerator weiterleiten (S112).
Der Regelgenerator 72 gruppiert dann die HTTP Anfragen (S114). Das Gruppieren wird in einer hierarchischen Weise bewerkstelligt, d.h. es werden anfänglich HTTP Anfragen gruppiert, die ein erstes Kriterium erfüllen. Der Rest der HTTP Anfragen, die das erste Kriterium nicht erfüllen, wird dann gemäß einem zweiten Kriterium gruppiert, und der Rest dieser Gruppierung wird gemäß einem dritten Kriterium grup giert, usw. Die Gruppierungskriterien werden in der Reihenfolge ihrer Fähigkeit angewendet, die HTTP Anfragen in einer Weise zu gruppieren, die das Abgleichen von Datenelementen in einer Gruppe von Anfragen mit den Datenmasken in den Regelmasken fördert. In HTTP Anfragen ist jedes Datenelement typischerweise mit einem Namen assoziiert (wie oben im Zusammenhang mit den 1A bis 1D beschrieben). Und in einer beliebigen Anwendung wird, obwohl verschiedene Teile der Anwendung mit verschiedenen URIS adressiert werden, ein beliebiger eindeutiger Name in der Anwendung assoziiert mit Datenelementen, die ein Satzformat aufweisen. Wenn folglich die Gruppierungen so sein können, dass eine Vielzahl von Fällen für einen eindeutigen Namen besteht, dann wird eine gleichartige Vielzahl von Fällen von Datenelementen mit dem gleichen Format vorhanden sein, was die Übereinstimmung mit einer Datenmaske fördert. Der hierarchische Gruppierungsprozess führt folglich zu Gruppierungen, die geordnet sind von denjenigen mit einer höheren Wahrscheinlichkeit des Erzeugens von Abgleichungen zu denjenigen mit einer niedrigeren Wahrscheinlichkeit des Herstellens von Abgleichungen.
Die Anfragen innerhalb des Probenraums werden zuerst in Sammlungen ausgebildet, so dass jede Sammlung alle Anfragen für eine gegebene eindeutige URL umfasst. Diese Sammlungen werden dann gruppiert, um die Genauigkeit bezüglich der Erzeugung von Regeln zu fördern. Alle weiteren Gruppierungsoperationen agieren auf diesen Sammlungen.
Um eine schnelle Verarbeitung zu fördern, wird das Gruppieren der Anfragen zuerst ausgeführt auf der Grundlage der Eigenschaften von Anfragen, die allein durch Überprüfen der eindeutigen Anfrage-URI, die zu einer jeweiligen Sammlung gehört, beobachtbar sind, d.h. ohne Überprüfung der Nachrichtenköpfe, der Cookies, des Hauptteils, des Verfahrens oder der HTTP Version von Anfragen innerhalb der Sammlung.
Das erste Kriterium zum Gruppieren von Anfragen können Typindikatoren sein, wie etwa die Dateinamen-Alonge innerhalb des URI Pfadnamens. Folglich können beispielsweise die folgenden Gruppierungen (mit höchster Ordnung) ausgebildet werden:

• eine Gruppierung für HTTP Anfragen mit URIs mit bekannten "Bild"-Dateitypen, die durch die Dateinamen-Alongen dargestellt werden, einschließlich Alongen, die ".gif", ".jpg", ".jpeg", ".png" umfassen;
• eine Gruppierung für HTTP Anfragen mit URIS mit bekannten "HTML/CSS" Dateitypen, die durch Dateinamen-Alongen einschließlich ".htm", ".html", ".css" dargestellt werden;
• eine Gruppierung für HTTP Anfragen mit URIS mit bekannten Datentypen für "client-seitige Skripten", die durch Dateinamen-Alongen einschließlich ".js" dargestellt werden;
• eine Gruppierung für HTTP Anfragen mit URIs mit bekannten Dateitypen mit "dynamischem Inhalt", die durch Dateinamen-Alongen einschließlich ".jsp", ".asp", ".pl", ".php" dargestellt werden; und
• eine Gruppierung für HTTP Anfragen mit URIS mit einem beliebigen Dateityp, der durch eine anderweitig nicht erkennbaren Dateinamen-Alonge, die für die URIs von mehr als einer Schwellenzahl von HTTP Anfragen innerhalb des Probenraums auftritt.

Für den Rest der Anfragen, der durch die Anwendung der ersten Kriterien nicht gruppiert worden ist, wird ein Gruppierungskriterium zweiter Ordnung angewendet. Dieses zweite Kriterium ist der Präfix-Teil des Verzeichnisnamens des eindeutigen URI-Pfadnamens. Folglich können beispielsweise die folgenden Gruppierungen ausgebildet werden:

• eine Gruppierung für HTTP Anfragen mit URIs mit dem Präfix "/Images/" im URI-Pfadnamen;
• eine Gruppierung für HTTP Anfragen mit URIs mit dem Präfix "/skripts" im URI-Pfadnamen; und
• eine Gruppierung für HTTP Anfragen mit URIs mit einem Präfix mit beliebigen Pfadnamen in mehr als einer Schwellenanzahl der verbleibenden HTTP Anfragen angetroffen wird.

Optional kann der Rest der Anfragen, die weder gemäß dem ersten noch gemäß dem zweiten Kriterium gruppiert worden sind, aufgrund von Mustern, die innerhalb der URI der Anfragen gefunden werden, gruppiert werden. Beispielsweise können alle URIs mit der Teilzeichenkette "online/banking/application" zusammengruppiert werden. Ein beliebiger Rest kann gemäß der Länge der URI in der verbleibenden HTTP Anfrage gruppiert werden. Beispielsweise können alle URIS mit über 1000 Zeichen Länge zusammengruppiert werden.
Für einen beliebigen verbleibenden Rest wird dann die Sammlung der Anfragen für eine jeweils eindeutige URI geprüft, und es werden Invarianten (d.h. Eigenschaften, die invariant gegenüber allen Anfragen in einer beliebigen Sammlung sind) gesucht. Dann können zusätzliche Gruppierungen von Sammlungen auf der Basis dieser Invarianten durchgeführt werden. Diese Invarianten können zuerst in dem Inhaltstyp des Hauptteils der Anfrage gesucht werden, dann in der Größe der Anfragen, dann in dem Verfahren der Anfragen und zuletzt in einer beliebigen anderen Eigenschaft der Anfragen. Beispielsweise können die folgenden Gruppierungen auf der Grundlage des Inhaltstyps ausgebildet werden:

• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen Sammlung einen invarian ten Inhaltstyp "application/x-www-form-urlencoded" aufweist;
• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfragen einer jeweiligen der Sammlung, die einen invarianten bekannten Inhaltstyp, der Einreichungen in HTML Form darstellt, aufweisen, einschließlich "application/x-www-form-urlencoded" und "multipart/formdata";
• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfragen einer jeweiligen der Sammlungen einen invarianten, unbekannten Inhaltstyp aufweisen, wobei die Anzahl der in den Sammlungen repräsentierten Anfragen eine Schwellenzahl von Anfragen innerhalb des Probenraums übersteigen.

Für einen beliebigen Rest können dann auf der Grundlage der Nachrichtenköpfe der Anfrage zusätzliche Gruppierungen ausgeführt werden. Beispielsweise können die folgenden Gruppierungen auf der Grundlage der Nachrichtenköpfe der Anfrage ausgebildet werden:

• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Sammlung einen Transfer Encoding ("TE", übersetzt etwa Übertragungscodierung)-Nachrichtenkopf aufweist und wobei der Wert für den TE-Nachrichtenkopf invariant (d.h. der gleiche) für alle Anfragen in der Gruppierung ist;
• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Sammlungen einen "User-Agent" (übersetzt etwa "Benutzer-Agent")-Nachrichtenkopf aufweist und wobei der Wert für den User-Agent-Nachrichtenkopf invariant für alle Anfragen in der Gruppierung ist;
• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Sammlungen einen "Ac cept-Language" (übersetzt etwa "Akzeptanzsprache")-Nachrichtenkopf aufweist und wobei der Wert für den Accept-Language Nachrichtenkopf invariant für alle Anforderungen in der Gruppierung ist;
• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Gruppierung einen invarianten Nachrichtenkopfwert für je einen beliebigen gegebenen Nachrichtenkopf aufweist, wobei die Anzahl der in den Sammlungen dargestellten Anfragen eine Schwellenzahl von Anfragen innerhalb des Probenraums übersteigt.

Für einen beliebigen Rest können die folgenden Gruppen auf der Grundlage der Anfragengröße ausgebildet werden:

• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Sammlung eine invariante Größe des Hauptteils von über 1000 Bytes aufweist;
• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Sammlung Nachrichtenköpfe mit mehr als 500 Bytes aufweist.

Für einen beliebigen Rest können die folgenden Gruppierungen auf der Grundlage des Verfahrens der Anfrage ausgebildet werden:

• eine Gruppierung für Sammlungen von Anfragen, wobei die Anfrage einer jeweiligen der Sammlung ein PUT Verfahren aufweist;
• eine Gruppierung für Sammlungen von Anfragen, wo die Anfragen einer jeweiligen der Sammlung ein HERD oder GET Verfahren aufweist.

Schließlich kann jeder verbleibende Rest auf der Grundlage einer beliebigen anderen invarianten Eigenschaft der Anfra gen innerhalb jeder Sammlung gruppiert werden. Dies ist das Gruppierungskriterium mit der niedrigsten Ordnung.
Der Regelgenerator bzw. Regelerzeuger 72 kann dann die Gruppierungen an der Entwicklerschnittstelle 78 vorstellen, um es dem Regelentwickler zu ermöglichen, jegliche Gruppierung zu zerteilen, um zwei oder mehrere Gruppierungen auszubilden, oder um beliebige zwei oder mehrere Gruppierungen zu einer Gruppierung zusammenzufügen (S116).
Die Anfragen innerhalb einer jeglichen Gruppierung werden dann in ihre Bestandteile zerlegt (S118). Mit den HTTP Anfragen enthalten diese Bestandteile: Verfahren, URI, GET Felder (URI-Parameter), HTTP Version, Nachrichtenköpfe, Cookies, URL-codierte POST-Felder, mehrteilige Formular mit codierten POST-Feldern und SOAP-Elemente.
Dann bildet der Regelerzeuger 72 für jede Gruppierung (S120, S144), für jeden Bestandteiltyp (d.h. GET Felder, Nachrichtenköpfe, Cookies, usw.) einen Satz von allen Bestandteilnamen aus (d.h. einen Satz von allen Bestandteilnamen, die in einer oder mehreren Anfragen innerhalb der Gruppierung auftreten) (S122). Für jeden Namen in dem Satz (S126, S136) wird die Probengruppe des assoziierten Datenelements ausgebildet, wobei jedes Datenelement mit einem Auftreten des Namens assoziiert ist (S128).
Die Datenmasken von anwendbaren Exemplaren der ausgewählten Regelmasken werden dann auf jede Probengruppe von Datenelementen angewendet, um eine passende Datenmaske zu finden (S130). Beispielsweise ist die Regelmaske für Telefonnummern aus der 2 nur potentiell anwendbar auf ein Datenelement in einem Hauptteil einer Anfrage (d.h. in einem URI-codierten POST-Feld, einem in mehrfach Weise codierten POST-Feld oder einem SOAP-Element) oder in einem GST-Feld (URI-Parameter). Daher ist diese Regelmaske nur anwendbar, wo der HTTP Bestandteiltyp ein URL codiertes Feld, ein mehrteiliges codiertes Feld oder ein SOAP-Element im Hauptteil oder die URI-Parameter sind.
In der Situation, wo ein Regelmuster Datenelementmuster von höherem zu geringerem Spezifizierungsgrad aufweist, kann ein Datenelement, das mit einer Datenelementmaske mit geringerem Spezifizierungsgrad zusammenpasst, auch mit einer Datenelementmaske mit höherem Spezifizierungsgrad abgeglichen werden. Wie oben angemerkt, sind die Datenelementmasken von derartigen Regelmasken von höherem zu geringerem Spezifizierungsgrad in einer Regelmaske organisiert. Mit einer derartigen Organisation kann der Regelerzeuger 72 nach einer passenden Datenelementmaske suchen, wobei er bei Masken mit höherem Spezifizierungsgrad beginnt und die Suche beim Finden der ersten Datenelementmaske, die mit dem Format der Probengruppe von Datenelementen zusammenpasst, beendet.
Es sei zusammengefasst, dass in einer beliebigen Computeranwendung jeder eindeutige Namen in der Anwendung mit Datenelementen mit dem gleichen Format assoziiert sein wird. Folglich wird ein Name in einem Satz von Namen in einer Gruppe von Anfragen normalerweise mit Datenelementen mit einem identischen Format assoziiert. Es besteht auch die Möglichkeit, dass einige Namen in einer Gruppe von Anfragen verwendet werden, welche Gruppe in Assoziierung mit Datenelementen von verschiedenen Formaten ist (normalerweise aufgrund des in verschiedenen Computeranwendungen benutzten identischen Namens). In einer solchen Situation kann eine Probengruppe von Datenelementen nur dahingehend deklariert werden, dass sie mit einer der Datenelementmasken in der oben beschriebenen zusammenfassenden Regelmaske zusammenpasst. Derartige Übereinstimmungen können dem Regelentwickler (über die Schnittstelle 78) angezeigt werden, um eine Änderung der Anfragegruppen zu ermöglichen, um das Abgleichen zu verbessern.
Wenn eine Probengruppe von Datenelementen mit einer Datenelementmaske übereinstimmt, dann wird der entsprechende Name des Bestandteiltyps mit einer Regel verknüpft, was erfordert, dass jedes Auftreten des Namens dieses Bestandteiltyps ein assoziiertes Datenelement gemäß der abgeglichenen Datenelementmaske aufweist (S132). Es wird anerkannt, dass eine derartige Regel eine einfache universale Regel ist, weil sie auf alle Elemente dieses Bestandteiltyps angewendet werden kann.
Beispielsweise kann es vorkommen, dass eine Probengruppe von Datenelementen, die in dem Hauptteil der Anfrage mit dem Namen "telnr" assoziiert ist, mit dem Format von nordamerikanischen Telefonnummern von (xxx)xxx-xxxx übereinstimmt. In einem solchen Fall würde eine Regel erzeugt, die aussagt: Für alle Anfragen, in denen ein Name eines Hauptteils "telnr" ist, muss das assoziierte Datenelement das Format (xxx)xxx-xxxx aufweisen.
Die verknüpfte, einfache, universale Regel kann in den folgenden Weisen beschränkt werden:

• Der Regel kann, aufgrund der Extremwerte in der Probengruppe von Datenelementen, aus denen sie erzeugt worden ist, eine minimale Datenwertlänge (in Zeichen oder Bytes) und eine maximale Datenwertlänge (in Zeichen oder Bytes) zugewiesen werden;
• Wenn die Datenelementwerte vom numerischen Typ sind, kann, auf der Grundlage der Extremwerte in der Probengruppe von Datenelementen, aus denen sie erzeugt worden ist, der Regel ein minimaler numerischen Datenwert und ein maximaler numerischer Datenwert zugewiesen werden (S134).

Der Regelerzeuger 72 kann dann jede Gruppierung von HTTP Anfragen auf existentielle Invarianten hin untersuchen. Beispielsweise kann der Regelerzeuger nach mit Namen versehenen Elementen eines beliebigen Typs suchen, die niemals zu existieren fehlen werden (d.h. eine einfache existentielle Invariante), und/oder Elementtypen, die immer in einer spezifischen Anzahl existieren (d.h. eine komplexe existentielle Invariante). Für jede existentielle Invariante wird eine Regel, die eine Anforderung bezüglich der Existenz dieser Größe (oder dieser Anzahl von Größen) formuliert, mit der Gruppierung verknüpft, was eine verknüpfte existentielle Regel erzeugt (S138). Beispielsweise kann der Regelerzeuger bemerken, dass jede Anfrage in einer Gruppierung von HTTP Anfragen ein Cookie mit dem Namen "SessionID" aufweist. In einem solchen Fall kann der Regelerzeuger eine einfache existentielle Regel errichten, die erfordert, dass ein mit "SessionID" benannter Cookie für eine beliebige, in die Gruppierung fallende HTTP Anfrage erstellen (d.h. eine beliebige HTTP Anfrage mit der URI, dem Nachrichtenkopf oder anderen Merkmalen, die die Basis für die Gruppierung ausbildet). Oder der Regelerzeuger kann bemerken, dass jede Anfrage in einer Gruppierung zwischen drei und fünf POST-Feldern mit numerischen Werten aufweist. In einem solchen Fall kann der Regelerzeuger eine komplexe existentielle Regel erstellen, die zwischen drei und fünf POST-Feldern mit numerischen Werten für eine beliebige, in diese Gruppierung fallende HTTP Anfrage erfordert.
Dann kann jede Gruppierung von HTTP Anfragen auf statistische Eigenschaften hin untersucht werden. Für eine jegliche statistische Invariante, wird eine Regel, die eine Anforderung für diese statistische Anfrage formuliert, mit der URI Gruppierung verknüpft, was eine verknüpfte statistische Regel erzeugt (S140). Beispielsweise könnte eine statistische Regel lauten: "Nicht mehr als 5% der POST-Felder darf nullwertige (leere) Werte aufweisen".
Schließlich werden die daraus resultierenden, verknüpften Regeln (von allen Typen, d.h. einfache universale verknüpfte Regeln, existentielle verknüpfte Regeln, statistische verknüpfte Regeln) für jede Gruppe in einem vollständigen Regelsatz zusammengefasst. Der Regelsatz für eine Gruppierung weist Regeln auf, die auf jede beliebige nachfolgende HTTP Anfrage anwendbar sind, die ein Merkmal aufweisen, das das gleiche ist, wie das Merkmal, das die Basis für die Gruppe gebildet hat. Beispielsweise kann ein Regelsatz aus einer Gruppe resultieren, die aus HTTP Anfragen mit URIS mit der Dateinamen-Alonge ".gif" ausgebildet worden ist. In einem solchen Fall ist der Regelsatz auf eine beliebige nachfolgende HTTP Anfrage mit einer URI mit der Dateinamen-Alonge ".gif" anwendbar. Folglich ist dieses Merkmal ein "Trigger" für den Regelsatz. Daher wird das gemeinsame Merkmal, das die Basis für jede Gruppierung gebildet hat, in einer Triggerbedingung für einen Regelsatz ausgebildet, und jede Regel (von jedem Typ), die mit der Gruppierung verknüpft ist, erhält eine Bedingung, die dem Regelsatz hinzugefügt wird (S142).
Es wird aus der vorhergehenden Beschreibung der Art und Weise, wie die Gruppierungen ausgebildet werden, offensichtlich, dass eine HTTP Anfrage die Bedingung von mehr als einem Regelsatz erfüllen könnte. Wie jedoch oben beschrieben, sind die Gruppierungen hierarchisch geordnet, wobei sie allgemein von Gruppierungen mit einer höheren Wahrscheinlichkeit des Erzeugens von Übereinstimmungen zu solchen mit einer niedrigeren Wahrscheinlichkeit des Erzeugens von Übereinstimmungen fortschreiten. Aus Gründen der Verarbeitungseffizienz ist es allgemein angemessen, dass jede Anfrage nur durch einen Regelsatz abgeschirmt bzw. durchsucht wird. Folglich werden die Regelsätze in der gleichen Reihenfolge geordnet, in der die Gruppierungen geordnet sind. In Folge davon kann die Abschirmvorrichtung 82 beim Empfangen einer Anfrage eine von der Anfrage erfüllte Triggerbedingung suchen, beginnend mit den Regelsätzen der höchsten Ordnung (die eine höhere Wahrscheinlichkeit zum Erzeugen von Übereinstimmung aufweisen). Der erste Regelsatz in der geordneten Liste von Regelsätzen, für den gefunden wird, dass er eine Triggerbedingung aufweist, die von der Anfrage erfüllt worden ist, ist der Regelsatz, der auf die Anfrage angewendet wird.
5 veranschaulicht einen Teil eines beispielhaften Regelsatzes, ausgedrückt in menschlich lesbarer Form. (In der Praxis werden die Regeln für Anfragen typischerweise in einer Tabelle gespeichert und können symbolisch in einer Weise ausgedrückt werden, die eine feinere Unterscheidung ermöglicht, als dies in annehmlicher Weise in menschlich lesbarer Form ausgedrückt werden kann.) Sich der 5 zuwendend, weist ein Trigger 90 eine Anzahl von damit assoziierten Bedingungen 92 auf. Jede Bedingung ist eine der Regeln, die verknüpft ist mit der Gruppe von HTTP Anfragen, die auf der Grundlage des den Trigger 90 umfassenden URI-Merkmals errichtet worden ist.
Die geordneten Regelsätze können dann an die Abschirmungsvorrichtung 82 zum Abschirmen von nachfolgenden Anfragen an die Anwendung(en) weitergereicht werden (S146). Wahlweise können diese nachfolgenden HTTP Anfragen gespeichert werden, um den Probenraum von Anfragen in der Datenbank 70 zu vergrößern. In einem solchen Fall kann der Regelerzeuger 72 diesen größeren Probenraum von Anfragen später verarbeiten in dem Bestreben, verbesserte Regelsätze zu erzeugen.
Obwohl die Erfindung in Verbindung mit Anfragen, die dem HTTP Protokoll folgen, beschrieben worden ist, so wird offensichtlich, dass die Lehren der Erfindung Anwendungen auf Anfragen aufweisen, die einem anderen geeigneten Protokoll folgen.
Andere Modifikationen werden dem Fachmann in dem technischen Gebiet offensichtlich und daher ist die Erfindung in den Patentansprüchen definiert.

Claims

Ein Verfahren zum Erzeugen von Regelsätzen für Layer-Anfragen in Abschirmungsanwendungen, wobei Anwendungs-Layer-Anfragen (10, 10', 10'') aus einem Probenraum von Anwendungs-Layer-Anfragen durch ein Merkmal der Anfragen gruppiert werden, [umfassend]: Empfangen eines Satzes von Datenmasken (54a, 54b, 54c), die für jeden Typ von Bestandteilen (12, 14, 16, 18, 20, 12', 14', 16', 18', 20', 25', 12'', 14'', 16'', 18'', 25'', 18a''', 25''') der Anfragen anwendbar sind; gekennzeichnet durch: Erhalten eines Regelsatzes (5) für jede Anforderungsgruppe durch: für jeden Typ von Bestandteilen der Anfragen: Identifizieren von Namen der Bestandteile (24', 24'') und der damit assoziierten Datenelemente (26', 26''), die in Anfragen der jeweiligen Anfragegruppe bestimmt werden; für jeden Namen: Erhalten einer Probengruppe von Datenelementen, wobei jedes Datenelement mit einem Auftreten des jeweiligen Namens assoziiert ist; Abgleichen der Probengruppe der Datenelemente mit einer vordefinierten Datenmaske; und Verknüpfen einer Regel (92), die mit der passenden Datenmaske für jeden Namen assoziiert ist.
Das Verfahren nach Anspruch 1, wobei das Merkmal ein Segment des Zieladressindikators (14, 14', 14'') ist.
Das Verfahren nach Anspruch 2, wobei die Anwendungslayeranforderungen Hypertextprotokoll (HTTP, Englisch: Hypertext Protocol)-Anforderungen und der Zieladressindikator ein Universalquellenindikator (URI, englisch: Universal Resource Indicator) ist.
Das Verfahren nach Anspruch 3, wobei das Segment der URI eine URI Pfadnamen-Alonge (Englisch: Pathname Extension) ist.
Das Verfahren nach Anspruch 4, wobei die URI für jede Gruppierung verwendete Pfadnamen-Alonge vorbestimmt ist.
Das Verfahren nach Anspruch 4, wobei einige für die Gruppierung benutzte URI Pfadnamen-Alongen vorbestimmt sind und jeweils eine der anderen bestimmt ist als eine URI Pfadnamen-Alonge, die in der URI einer Schwellenzahl der Anforderungen verwendet wird.
Das Verfahren nach Anspruch 4, ferner umfassend, für einen Rest von HTTP Anforderungen, die nicht durch die Gruppierung gruppiert werden, Gruppieren von Anfragen des Rests durch Verzeichnisnamen-Präfixteile der URI Pfadnamen des Rests.
Das Verfahren nach Anspruch 7, wobei die für die Gruppierung benutzten Verzeichnisnamen-Präfixteile vorbestimmt sind.
Das Verfahren nach Anspruch 7, wobei einige der für die Gruppierung benutzten Verzeichnisnamen-Präfixteile vorbestimmt sind und jeweils eine der anderen als ein Verzeichnisnamen-Präfixteil, in der die URI einer Schwellenanzahl der Anforderungen benutzt wird, bestimmt wird.
Das Verfahren nach Anspruch 7, ferner umfassend für einen zweiten Rest von wiederum nicht gruppierten HTTP Anforderungen, Gruppieren der Anforderungen des zweiten Rests durch Zeichenkettenmuster innerhalb der URI Pfadnamen des zweiten Rests.
Das Verfahren nach Anspruch 10, ferner umfassend für einen dritten Rest von noch nicht gruppierten HTTP Anfragen: Gruppieren einer Teilmenge von Anfragen des dritten Rests, wobei jede Anfrage von jedem Rest eine gemeinsame Eigenschaft aufweist.
Das Verfahren nach Anspruch 11, wobei die gemeinsame Eigenschaft ein vorbestimmter Inhaltstyp ist.
Das Verfahren nach Anspruch 11, wobei die gemeinsame Eigenschaft eine der folgenden ist: ein vorbestimmter Inhaltstyps oder ein Inhaltstyp, der in einer Schwellwertanzahl der Teilmenge der Anforderungen verwendet wird.
Das Verfahren nach Anspruch 1, ferner umfassend: für jeden Namen Bestimmen einer Länge eines längsten Datenelements in dem Satz von Datenelementen und Verknüpfen einer weiteren Regel mit jedem Namen, der eine maximale erlaubbare Länge von Datenelementen als die Länge festlegt.
Das Verfahren nach Anspruch 1, wobei, [in Fällen] wo die Datenelemente in jedem Satz von Datenelementen in jedem Satz von Datenelementen numerisch sind, ein Wert eines größten, mit Wert versehenen Datenelements in dem Satz von Datenelementen und ein Wert eines Datenelements mit dem kleinsten Wert in dem Satz von Datenelementen bestimmt wird, und eine weitere Regel Verknüpfen mit jedem Namen, der einen maximalen erlaubbaren Wert von Datenelementen festsetzt, auf der Grundlage des Werts des größten, bewerteten Datenelements und eines minimalen, erlaubbaren Werts auf der Grundlage des Werts des kleinsten, mit Wert versehenen Datenelements.
Das Verfahren nach Anspruch 1, ferner umfassend, für jede Anforderungsgruppierung: Suchen nach einem in jeder Anfrage einer jeweiligen Anforderungsgruppierung vorhandenen Element, und beim Finden eines gegebenen, in jeder Anforderung einer jeweiligen Anforderungsgruppierung vorhandenen Elements, Aufstellen einer existentiellen Regel für die besagte jeweilige Anforderungsgruppierung, die die Existenz der gegebenen Elemente in einer minimalen Anzahl von Gruppierungen erfordert.
Das Verfahren nach Anspruch 16, wobei wenn das gegebene Element als vorhanden bestimmt wird, in jeder Anfrage einer jeweiligen Anfragengruppierung in mindestens einer gegebenen Anzahl von Auftreten die existentielle Regel für die jeweilige Anfragengruppierung aufgestellt wird, um die Existenz der gegebenen Elemente in einer minimalen Anzahl von Gruppierungen zu erfordern.
Das Verfahren nach Anspruch 1, ferner umfassend für jede Anforderungsgruppierung: Bestimmen eines statistischen Maßes einer Eigenschaft von Anforderungen in der Anforderungsgruppierung und Aufstellen einer statistischen Regel für die besagte jeweilige Anforde rungsgruppierung auf der Grundlage des statistischen Maßes.
Das Verfahren nach Anspruch 1, ferner umfassend für jede Anforderungsgruppierung: Aufstellen eines Triggers für den Regelsatz, wobei der Trigger ein Merkmal umfasst, mittels dessen jede Anforderungsgruppierung ausgebildet wurde, wobei der Trigger, wenn er vorhanden ist, als eine Basis zum Hervorrufen von jeder der Regeln dient.
Ein System zum Beschaffen eines Regelsatzes für Lageranfragen in Abschirmungsanwendungen, das System umfassend: Mittel zum Gruppieren von Anwendungs-Layer-Anfragen (10, 10', 10'') aus einem Probenraum von Anwendungs-Layer-Anfragen durch ein Merkmal der Anfragen; Mittel zum Empfangen eines Satzes von Datenmasken (54a, 54b, 54c), die für jeden Typ von Bestandteilen (12, 14, 16, 18, 20, 12', 14', 16', 18', 20', 25', 12'', 14'', 16'', 18'', 25'', 18a''', 25''') der Anfragen anwendbar ist; gekennzeichnet durch Mittel zum Erhalten eines Regelsatzes (5) für jede Anforderungsgruppierung durch: für jeden Typ von Bestandteilen der Anforderungen, Identifizieren von Namen der Bestandteile (24', 24'') und der assoziierten Datenelemente (26', 26''), die in Anforderungen von jeder Anforderungsgruppierung bestimmt werden; für jeden Namen: Erhalten einer Probengruppe von Datenelementen, wobei jedes Datenelement, das mit einem Auftreten des jeweiligen Namens assoziiert ist; Angleichen des Probenraums von Datenelementen mit einer vorbestimmten Datenmatrize; und Festsetzen einer Regel (92), die mit der abgeglichenen Datenmaske für jeden Namen verknüpft ist.
Ein computerlesbares Medium (76) enthaltend computerausführbare Anweisung, die, wenn sie in einen Prozessor (72) geladen werden, den Prozessor ausbilden zum: Ausführen des Verfahrens nach Anspruch 1.