DE112020002552T5

DE112020002552T5 - System und verfahren für eine siem-regel-sortierung und bedingte ausführung

Info

Publication number: DE112020002552T5
Application number: DE112020002552.7T
Authority: DE
Inventors: Tim Scheideler; Arjun Udupi Raghavendra; Ivan Reedman; Matthias SEUL
Original assignee: International Business Machines Corp
Current assignee: Kyndryl Inc
Priority date: 2019-05-29
Filing date: 2020-04-28
Publication date: 2022-02-24
Also published as: CN113728581B; GB2598214B; US11516228B2; GB2598214A; US20230049773A1; US20200382525A1; WO2020240304A1; JP2022534841A; CN113728581A; GB202111756D0

Abstract

Ein Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas kann bereitgestellt werden. Das Verfahren umfasst ein Erzeugen eines Regelindex von Regeln und eines Indicator-of-Compromise-Index für jede der Regeln. Das Verfahren umfasst auch ein Verarbeiten des eingehenden Sicherheitsereignisses durch Anwenden der Regeln, ein Erhöhen eines aktuellen Regelzählers in Bezug auf eine ausgelöste Regel und ein Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers. Darüber hinaus umfasst das Verfahren ein Erzeugen eines Pseudosicherheitsereignisses aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise, ein Verarbeiten der Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln, ein Erhöhen eines aktuellen Regelzählers von Pseudosicherheitsereignissen und ein Erhöhen eines aktuellen Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse und ein Sortieren der Regeln sowie ein Sortieren innerhalb einer jeden Regel der Indicator-of-Compromise-Werte in dem Indicator-of-Compromise-Index.

Description

HINTERGRUND
Die Erfindung betrifft allgemein das Security Information and Event Management (nachstehend „SIEM“) und insbesondere ein Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasiertes Alarmschemas, ein zugehöriges SIEM-System zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas und ein Computerprogrammprodukt.
Die Sicherheit der Informationstechnologie (nachstehend „IT“) stellt eine Liste oberster Priorität von IT-Verantwortlichen dar. Die meisten vorhandenen aktuellen Security-Information-and-Event-Monitoring-Lösungen (nachstehend „SIEM“) erfordern einen Satz von komplexen Korrelationsregeln, die manuell eingesetzt, überwacht und optimiert werden müssen, um mögliche Sicherheitsbedrohungen wirksam zu identifizieren und zu erkennen, die zu Sicherheitsvorfällen führen können, welche sich auf ein Unternehmen auswirken.
Eine SIEM-Korrelationsregelengine erfordert gewöhnlich einen hohen Verbrauch an Systemressourcen (CPU und Hauptspeicher), da Korrelationsregeln Vergleichsoperationen, Filter und Schwellenwerte verwenden, um einer Reihe von Bedingungen zu entsprechen und um angesichts einer enormen Anzahl von erfassten Sicherheitsereignissen in Echtzeit bewertet zu werden.
Im Schnitt können Sicherheitsereignisse und -protokolle, die in einer typischen IT-Umgebung eines Unternehmens sowie von Sicherheitslösungen und -einheiten erzeugt werden, zwischen 1.000 Ereignissen pro Sekunde (nachstehend „EPS“) und 100.000 EPS schwanken und müssen gegebenenfalls über einen Satz von ungefähr durchschnittlich 100 bis 400 unterschiedlichen Regeln korreliert werden. Daher erzeugen die meisten der herkömmlichen SIEM-Technologien eine hohe Belastung auf Datenverarbeitungssystemen.
Ein Sicherheitsereignis (z.B. ein Protokolleintrag) wird durch einen statischen Regelsatz geparst. Statisch bedeutet, dass die Regeln von Menschen entwickelt und in einer festen Reihenfolge geordnet werden. Jedes Ereignis durchläuft den Regelsatz, entweder, indem es alle Regeln durchläuft, ohne einen Sicherheitsvorfall auszulösen, oder bis eine Regel einen Sicherheitsvorfall (auch als Verstoß bezeichnet) erzeugt, der ein weiteres Verarbeiten dieses bestimmten Ereignisses üblicherweise nicht mehr notwendig macht, da ein Sicherheitsvorfall von nun an weiter aufbereitet und verarbeitet wird.
Viele Regeln mit vielen Bedingungen, d.h., eine große Menge an erforderlichen Vergleichsoperationen beim Umgang mit langen Listen von Indicators-of-Compromise (nachstehend „loC“), z.B. eine Liste von böswilligen Internetprotokoll-Adressen (nachstehend „IP“-Adressen), müssen ausgewertet werden, bevor ein Verstoß erzeugt wird. Folglich werden Rechenressourcen möglicherweise verschwendet, wenn Regeln mit statischen loC-Listen in einer statischen Reihenfolge verarbeitet werden. Eine Verarbeitung von wichtigen Ereignissen kann verzögert werden, z.B., wenn ein schlauer Hacker das SIEM-System mit vielen Täuschungsereignissen flutet.
Es gibt mehrere Offenbarungen in Bezug auf ein Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas.
Angesichts der bekannten Technologien und der vorstehend skizzierten Probleme ist gegebenenfalls ein neuer Ansatz notwendig, um Sicherheitsvorfälle zu erzeugen, die weniger Rechenaufwand erforderlich machen und gleichzeitig die Erkennungsrate von Sicherheitsangriffen erhöhen.
KURZDARSTELLUNG
Gemäß einem Aspekt der vorliegenden Erfindung kann ein Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas bereitgestellt werden. Das Verfahren kann ein Erzeugen eines Regelindex von Regeln, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind, ein Erzeugen eines Indicator-of-Compromise-Index für jede der Regeln, wobei jeder Eintrag des Indicator-of-Include-Index einen Indikatorwert aufweist, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist, und ein Verarbeiten des eingehenden Sicherheitsereignisses durch sequenzielles Anwenden der Regeln umfassen.
Das Verfahren kann des Weiteren ein Erhöhen, in einem Regelinkrementierungsschritt, eines aktuellen Regelzählers in Bezug auf eine ausgelöste Regel, deren Verarbeitung einen Verstoß ausgelöst hat, und ein Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers umfassen.
Zusätzlich kann das Verfahren ein Erzeugen eines Pseudosicherheitsereignisses aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise, ein Verarbeiten der Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln umfassen, wobei das Verarbeiten ein Erhöhen eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse umfasst.
Das Verfahren kann ein Sortieren der Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten und ein Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten aktuellen Indicator-of-Compromise-Zählerwerten umfassen.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung kann ein Security-Information-and-Event Monitoring-System (nachstehend „SIEM“-System) zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas bereitgestellt werden. Das System kann eine erste Erzeugungseinheit enthalten, die so ausgelegt ist, dass sie einen Regelindex von Regeln erzeugt, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind, wobei die Erzeugungseinheit auch so ausgelegt ist, dass sie einen Indicator-of-Compromise-Index für jede der Regeln erzeugt. Jeder Eintrag des Indicator-of-Compromise-Index kann einen Indikatorwert aufweisen, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist. Das SIEM-System kann auch eine Korrelationsengine, die so ausgelegt ist, dass sie das eingehende Sicherheitsereignis durch sequenzielles Anwenden der Regeln verarbeitet, und ein Inkrementmodul, das so ausgelegt ist, dass es einen aktuellen Regelzähler in Bezug auf eine ausgelöste Regel erhöht, deren Verarbeitung einen Verstoß ausgelöst hat, wobei das Inkrementmodul auch so ausgelegt ist, dass es einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler erhöht, enthalten.
Das SIEM-System kann zusätzlich eine zweite Erzeugungseinheit enthalten, die so ausgelegt ist, dass sie ein Pseudosicherheitsereignis aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise erzeugt, wobei die Korrelationsengine auch so ausgelegt ist, dass sie die Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln verarbeitet, wobei das Verarbeiten ein Erhöhen, durch ein Pseudosicherheitsereignis-Zählermodul, eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen, durch einen Zähler für Indicator of Compromise für Pseudosicherheitsereignisse, eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse umfasst.
Als weitere Einheit kann das SIEM-System ein Sortiermodul enthalten, das so ausgelegt ist, dass es die Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten sortiert, und das so ausgelegt ist, dass es die Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten aktuellen Indicator-of-Compromise-Zählerwerten innerhalb einer jeden Regel sortiert.
Das vorgeschlagene Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas kann mehrere Vorteile und technische Wirkungen bieten:
Das vorgeschlagene Verfahren kann das Leistungsspektrum von SIEM-Lösungen in Bezug auf eine Menge an zu verarbeitenden Ereignissen sowie eine Erkennungshäufigkeit erhöhen. Vorhandene Datenverarbeitungsressourcen können effizienter genutzt werden, indem Verstöße in der Art von Sicherheitsereignissen schneller und wirksamer erzeugt werden.
Anstatt jedes eingehende Ereignis einen festen Satz von Regeln durchlaufen zu lassen, wobei jede Regel einen festen Satz von Indicators-of-Compromise enthalten kann, kann das Verfahren die Regeln dergestalt dynamisch sortieren, dass Regeln, die häufiger Verstöße erzeugen, in dem Regelsatz vorgezogen werden können. Man kann davon ausgehen, dass, nachdem ein Verstoß aus einem Ereignis erzeugt wurde, ein weiteres Verarbeiten des Ereignisses nicht mehr erforderlich ist; somit zielt die Lösung darauf ab, einen Verstoß mit so wenigen Vergleichsoperationen, d.h. Datenverarbeitungsressourcen, wie möglich auszulösen.
Um die Wahrscheinlichkeit für das Auslösen eines Verstoßes für eine Regel einzuschätzen, können zwei Aspekte berücksichtigt werden: erstens die Menge an Verstößen, die die Regel für einen gegebenen Satz von jüngsten Ereignissen ausgelöst hat, und zweitens die Menge an Verstößen, die eine Regel erzeugen würde, falls das zugrunde liegende System durch aktuell stattfindende Sicherheitsangriffskampagnen angegriffen wird.
Zusätzlich und auf ähnliche Weise können die Indicators-of-Compromise priorisiert werden, d.h., indem Ereignisattribute mit den berüchtigtsten Indicators-of-Compromise verglichen werden, bevor das Attribut mit weniger bekannten Indicators-of-Compromise verglichen werden kann. Dieser Ansatz kann notwendige Datenverarbeitungsressourcen einsparen.
Die Optimierung gemäß dem vorgeschlagenen SIEM-Ansatz kann daraus abgeleitet werden, dass ein eingehendes Sicherheitsereignis vornehmlich nur durch eine Teilmenge von Regeln verarbeitet wird und Ereignisattribute nur durch eine Teilmenge von Indicators-of-Compromise verglichen werden. Dies steht im Gegensatz zu herkömmlichen Lösungen, bei denen eingehende Sicherheitsereignisse gepuffert und verarbeitet werden, indem alle bekannten Regeln angewendet werden. Erst nachdem ein Ereignis und/oder ein zugehöriges Attribut im Rahmen des vollständigen Regelsatzes verarbeitet wurden, kann ein nächstes eingehendes Sicherheitsereignis bearbeitet werden. Somit kann ein wichtiges Ereignis für lange Zeit in eine Warteschlange gestellt werden, während viele nicht kritische Ereignisse verarbeitet werden.
Daher schlägt die vorgeschlagene Lösung einen Satz von Zwischenpufferspeichern vor, was es ermöglicht, eine Ausführung von Regeln, die nur selten einen Verstoß auslösen, zurückzustellen und es ermöglicht, mehr Ereignisse durch Regeln zu verarbeiten, die in dem gleichen gegebenen Zeitraum häufig Verstöße erzeugen. Insbesondere in Angriffsfällen verhindert das vorgeschlagene Verfahren proaktiv das Verzögern einer Erkennung von wichtigen Ereignissen, indem es vermeidet, dass zu viele Ressourcen auf Täuschungsereignisse verwendet werden.
Im Folgenden werden zusätzliche Ausführungsformen des erfindungsgemäßen Konzepts beschrieben.
Gemäß einer einzelnen bevorzugten Ausführungsform des Verfahrens kann das Sortieren der Regeln auch das Feststellen der gewichteten Regelzählerwerte umfassen, indem gewichtete vorherige Regelzählerwerte und gewichtete aktuelle Regelzählerwerte der Regel kombiniert - insbesondere addiert - werden. Auf diese Weise können nicht nur die jüngsten Ereignisse in der Verarbeitung widergespiegelt werden, sondern auch diejenigen, die in der Vergangenheit stattfanden. Indem ein Gewichtungsfaktor angewendet wird, kann die Bedeutung der vorherigen und der gegenwärtigen Ereignisse gemäß einer bestimmten Ausführung optimiert werden.
Gemäß einer weiteren bevorzugten Ausführungsform des Verfahrens umfasst das Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise auch ein Feststellen der gewichteten Indicator-of-Compromise-Zählerwerte, indem gewichtete vorherige loC-Zählerwerte und gewichtete aktuelle Indicators-of-Compromise-Zählerwerte (nachstehend „loC“-Zählerwerte) des jeweiligen Indicator of Compromise kombiniert - insbesondere addiert - werden. Somit kann das auf eine Gewichtung zwischen vorherigen und gegenwärtigen Ereignissen im Hinblick auf die Regeln angewendete Prinzip auch auf Indicators-of-Compromise in entsprechender Weise angewendet werden.
Gemäß einer einzelnen nützlichen Ausführungsform des Verfahrens kann der Regelinkrementierungsschritt auch ein Erhöhen des aktuellen Regelzählers um eine feste Zahl - z.B. um „1“ - oder um eine Zahl, die auf eine Schwere des Verstoßes hinweist, umfassen. Auch kann dieses Merkmal das Optimieren und Anpassen des zugrunde liegenden SIEM-Systems an tatsächliche Angriffsmuster unterstützen.
Gemäß einer weiteren nützlichen Ausführungsform des Verfahrens kann das Erhöhen des aktuellen Indicator-of-Compromise-Zählers auch ein Erhöhen des aktuellen Indicator-of-Compromise-Zählers um eine feste Zahl, z.B. um „1“, umfassen. Gegebenenfalls ist es auch möglich, den aktuellen Indicator-of-Compromise-Zähler je nach der Bedeutung des Werts des Indicator of Compromise innerhalb einer bestimmten Regel um eine andere - z.B. eine höhere Zahl - zu erhöhen.
Gemäß einer einzelnen vorteilhaften Ausführungsform des Verfahrens kann das Erzeugen des Pseudosicherheitsereignisses ein Anwenden von Tactic-Technique-Procedure-Informationen (nachstehend „TTP“-Informationen) umfassen, die Daten aus den empfangenen Daten über bekannte Angriffe identifizieren, wobei die empfangenen Daten über bekannte Angriffe über ein strukturiertes Bedrohungsinformationsausdruck-(Structured-Thread-Information-Expression-)Protokoll (nachstehend „STIX“-Protokoll) empfangen werden. Auf diese Weise können bekannte Sicherheitsbedrohungen an SIEM-Systeme verteilt werden, um für das SIEM-System zu trainieren, bevor möglicherweise Sicherheitsangriffe stattfinden. Dies kann mit einer Impfung des SIEM-Systems verglichen werden. Neueste und bedeutendste Sicherheitsangriffe können somit höher in dem Regelsatz des SIEM-Systems eingestuft werden. Auf diese Weise können Sicherheitsangriffe schneller erkannt werden, was dazu führt, dass weniger Datenverarbeitungsressourcen erforderlich sind, um den Angriff zu identifizieren.
Gemäß einer weiteren vorteilhaften Ausführungsform des Verfahrens kann das Erzeugen des Pseudosicherheitsereignisses ein Erzeugen eines Pseudosicherheitsereignisses für jede Phase einer Folge von teilweisen Cyberangriffen aufweisen, die durch Angriffsmuster dargestellt werden. Dazu kann ein Erzeugen einer Folge von Pseudosicherheitsereignissen gehören, von denen jedes an eine andere Phase einer Sicherheitsangriffskette oder-folge (auch als Cyberangriffskette bezeichnet) gerichtet sein kann.
Gemäß einer optionalen Ausführungsform des Verfahrens kann das Erzeugen des Pseudosicherheitsereignisses zusätzlich ein Erzeugen eines Pseudosicherheitsereignisses für jeden Indicator of Compromise umfassen, der sich auf eine jeweilige Regel bezieht. Somit kann das Prinzip, das verwendet wird, um die SIEM-Regeln im Hinblick auf bestimmte Sicherheitsangriffe wachsamer zu machen, auch auf Indicators-of-Compromise innerhalb einer gegebenen Regel angewendet werden
Gemäß einer zusätzlich bevorzugten Ausführungsform des Verfahrens kann das Erzeugen eines Pseudosicherheitsereignisses auch ein Zurücksetzen des aktuellen Regelzählers von Pseudosicherheitsereignissen auf Null und ein Zurücksetzen des aktuellen Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse auf Null umfassen. Da das Sortieren regelmäßig stattfinden oder auf andere Weise geplant werden kann, kann ein Setzen der Zähler für die Pseudosicherheitsereignisse auf Null eine einfache Möglichkeit darstellen, die aktuellen Zähler den vorherigen Zählern hinzuzufügen, sobald das Sortieren gestartet ist. Die aktuellen Zähler können dann beginnen, ihre Werte gemäß identifizierten und verarbeiteten Sicherheitsbedrohungen zu erhöhen.
Gemäß einer einzelnen zulässigen Ausführungsform des Verfahrens kann das Sortieren der Regeln in dem Regelindex das Feststellen des gewichteten Regelzählers RC_w durch: $\begin{array}{l} R C_{w} = P * v o r h e r i g e r R e g e l z \ddot{a} h l e r + (w_{1} * b e o b a c h t e t e E r e i g n i s s e) + (w_{2} \\ * P s e u d o s i c h e r h e i t s e r e i g n i s s e) \end{array}$
umfassen, wobei P = ein vordefinierter Prozentwert und w₁, w₂ = vordefinierte Gewichtungsfaktorwerte sind. Dasselbe Prinzip kann auf beide loC-Zähler, den aktuellen und den vorherigen, angewendet werden.
Gemäß einer zusätzlich vorteilhaften Ausführungsform kann das Verfahren auch ein Puffern des eingehenden Sicherheitsereignisses, nachdem eine vorher festgelegte erste Anzahl von Regeln verarbeitet wurde und innerhalb einer jeden verarbeiteten Regel eine vorher festgelegte zweite Anzahl von Indikatorwertgruppen verarbeitet wurde, und ein Fortsetzen der Verarbeitung des gepufferten Sicherheitsereignisses, wenn eine Verarbeitungslast von eingehenden Sicherheitsereignissen unter einen vordefinierten Lastschwellenwert fällt, umfassen.
Auf diese Weise kann die durch das Verfahren bzw. das zugehörige SIEM-System erzeugte Rechenlast auf die wichtigsten Sicherheitsbedrohungen, d.h. eingehende Sicherheitsereignisse, fokussiert werden. Regeln, die in dem Index von Regeln nicht so hoch eingestuft sind, können verarbeitet werden, wenn freie Verarbeitungsleistung zu einem späteren Zeitpunkt verfügbar wird.
Darüber hinaus können Ausführungsformen die Form eines zugehörigen Computerprogrammprodukts annehmen, auf das von einem durch einen Computer nutzbaren oder durch einen Computer lesbaren Datenträger aus zugegriffen werden kann, der Programmcode zur Verwendung durch einen Computer oder ein beliebiges Anweisungsausführungssystem oder in Verbindung mit einem Computer oder einem beliebigen Anweisungsausführungssystem bereitstellt. Zum Zweck dieser Beschreibung kann ein durch einen Computer nutzbarer oder durch einen Computer lesbarer Datenträger jede beliebige Vorrichtung sein, die Mittel enthalten kann, um das Programm zur Verwendung durch das Anweisungsausführungssystem, die Anweisungsausführungsvorrichtung oder - einheit oder zur Verwendung in Verbindung mit dem Anweisungsausführungssystem, der Anweisungsausführungsvorrichtung oder -einheit zu speichern, zu übertragen, weiterzugeben oder zu transportieren.
Figurenliste
Diese und weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung gehen aus der folgenden ausführlichen Beschreibung von veranschaulichenden Ausführungsformen der Erfindung hervor, die in Verbindung mit den beiliegenden Zeichnungen gelesen werden soll. Die verschiedenen Merkmale der Zeichnungen sind nicht maßstabsgetreu, da die Veranschaulichungen dem Fachmann das Verständnis der Erfindung in Verbindung mit der ausführlichen Beschreibung durch Übersichtlichkeit erleichtern sollen. In den Zeichnungen:
Bevorzugte Ausführungsformen der Erfindung werden lediglich beispielhaft und unter Bezugnahme auf die folgenden Zeichnungen beschrieben:

1 zeigt ein Blockschaltbild einer Ausführungsform des erfindungsgemäßen Verfahrens zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasiertes Alarmschemas;
2 zeigt ein Blockschaltbild eines Vergleichs von Attributwerten von Sicherheitsereignisregeln und zugehörigen Indicators-of-Compromise gemäß einer Ausführungsform;
3 zeigt ein Blockschaltbild einer Ausführungsform von einem Schema von Regeln, Gruppen von IoCs und einem Pufferspeicher gemäß einer Ausführungsform;
4 zeigt ein beispielhaftes Ergebnis von Regel- und Indicators-of-Compromise-Zählern (nachstehend „loC“-Zählern) gemäß einer Ausführungsform;
5 zeigt ein beispielhaftes Ergebnis von Regel- und loC-Zählern in Kombination mit einer Ressourcenzuordnung gemäß einer Ausführungsform;
6 zeigt eine Ausführungsform eines Blockschaltbilds von dem erfindungsgemäßen Security-Information-and-Event-Monitoring-System (nachstehend „SIEM“-System) zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas gemäß einer Ausführungsform;
7 zeigt eine Ausführungsform eines das SIEM-System gemäß 6 aufweisenden Datenverarbeitungssystems gemäß einer Ausführungsform;
8 zeigt eine Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung; und
9 zeigt Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung.

Es sei angemerkt, dass Ausführungsformen der Erfindung unter Bezugnahme auf verschiedene Gegenstände beschrieben werden. Insbesondere werden einige Ausführungsformen unter Bezugnahme auf Verfahrensansprüche beschrieben, wohingegen andere Ausführungsformen unter Bezugnahme auf Vorrichtungsansprüche beschrieben werden. Der Fachmann entnimmt jedoch der vorstehenden und der nachfolgenden Beschreibung, dass, vorbehaltlich anderer Angaben, neben jeder beliebigen Kombination aus Merkmalen, die zu einem Typ von Gegenstand gehören, auch jede beliebige Kombination zwischen Merkmalen, die sich auf verschiedene Gegenstände beziehen, insbesondere zwischen Merkmalen der Verfahrensansprüche und Merkmalen der Vorrichtungsansprüche, als eine in diesem Schriftstück zu offenbarende Kombination betrachtet wird.
Die vorstehend definierten Aspekte und weitere Aspekte der vorliegenden Erfindung gehen aus den Beispielen von Ausführungsformen, die nachstehend zu beschreiben sind, hervor und werden unter Bezugnahme auf die Beispiele von Ausführungsformen erklärt, auf welche die Erfindung jedoch nicht beschränkt ist.
AUSFÜHRLICHE BESCHREIBUNG
Ausführliche Ausführungsformen der beanspruchten Strukturen und Verfahren werden hierin offenbart; jedoch kann darauf hingewiesen werden, dass die offenbarten Ausführungsformen lediglich die beanspruchten Strukturen und Verfahren veranschaulichen, welche in verschiedenen Formen realisiert werden können. Diese Erfindung kann jedoch in vielen verschiedenen Formen realisiert werden und sollte nicht als auf die hierin dargelegten beispielhaften Ausführungsformen beschränkt ausgelegt werden. In der Beschreibung werden Einzelheiten von hinlänglich bekannten Merkmalen und Techniken gegebenenfalls weggelassen, um die dargestellten Ausführungsformen nicht unnötig zu überfrachten.
Ausführungsformen der vorliegenden Erfindung betreffen das Gebiet des Security Information and Event Management (nachstehend „SIEM“) und insbesondere ein Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas, ein zugehöriges SIEM-System zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas und ein Computerprogrammprodukt.
Im Kontext dieser Beschreibung werden gegebenenfalls die folgenden Konventionen, Begriffe und/oder Ausdrücke verwendet:

Der Begriff ‚Sicherheitsereignis‘ kann einen Eintrag in einem Sicherheitsprotokollsystem bezeichnen, in dem jede Interaktion mit anderen Systemen aufgezeichnet werden kann. Das Sicherheitsereignis kann eine Mehrzahl von Erscheinungsformen wie, ohne darauf beschränkt zu sein, eine E-Mail, einen Speichersystemzugriff, eine HTTP-Anforderung (HTTP steht für Hyper Text Transfer Protocol, nachstehend „HTTP“), eine Nachricht eines Social-Media-Systems, eine Datenbankanforderung haben, um nur ein paar zu nennen.

Der Begriff ‚Sicherheitsbedrohung‘ kann eine mögliche Gefahr bezeichnen, die eine Schwachstelle ausnutzen könnte, um die Sicherheit von Informationstechnologiesystemen zu verletzen, und daher möglichen Schaden anrichten könnte. Der Begriff betrifft das technische Gebiet der Computersicherheit und beschreibt einen möglichen Angriff, einen unerlaubten Zugriff oder eine mögliche Zerstörung oder Manipulation von Daten in Computer- oder Speichersystemen durch einen Eindringling oder ein eindringendes System oder eine Übernahme der Kontrolle über den Computer, das Speicher- oder Übertragungssystem. Die Sicherheitsbedrohungen rühren üblicherweise von einem Cyberangriff her.
Der Begriff ‚Verstoß‘ kann einen möglichen Angriff auf ein Datenverarbeitungssystem und/oder ein Netzwerksystem und alle Speichersysteme bezeichnen. Der Verstoß kann von einem SIEM-System erzeugt werden, wenn gefährliche Muster identifiziert wurden. Verstöße können auf jede Phase einer Kette von Cybersicherheitsangriffen bezogen sein.
Der Begriff ‚Cyberangriffskette‘ kann eine Folge von Teilangriffen auf ein Computer- oder ein ähnliches System bezeichnen. Jede Stufe oder Phase der Folge baut auf der vorherigen auf. Es gibt theoretische Modelle mit sieben und auch mit 18 Stufen einer Folge oder Kette von Cyberangriffen. Im Verlauf dieses Dokuments können die Begriffe „Folge von teilweisen Cyberangriffen“ und „Cyberangriffskette“ synonym verwendet werden.
Der Begriff ‚Regelindex von Regeln‘ kann eine sortierte Liste von Regeln zum Identifizieren von möglichen Cyberangriffen auf Datenverarbeitungssysteme und/oder Netzwerke und/oder Speichersysteme bezeichnen, wobei jede Regel einen bestimmten Satz von Indicators-of-Compromise haben kann, der ebenfalls in zugehörigen sortierten Listen verwaltet werden kann. Die Priorität innerhalb der sortierten Liste kann auf der Grundlage von Informationen geändert und aktualisiert werden, die über ein strukturiertes Bedrohungsinformationsausdruck-Protokoll (nachstehend „STIX“-Protokoll) von einem Sicherheitsverteidigungsanbieter einer vertrauenswürdigen Quelle von Informationstechnologie (nachstehend „IT“), z.B. über eine Tactic-Technique-Procedure (nachstehend „TTP“), die Regeldaten identifiziert, empfangen werden.
Der Begriff ‚Indicator of Compromise‘ (loC) kann in der Computerforensik und IT-Sicherheit ein in einem Netzwerk oder in einem Betriebssystem beobachtetes Artefakt bezeichnen, welches mit hoher Sicherheit auf ein Eindringen eines Computers hinweist. Typische IoCs sind Virussignaturen und Internetprotokoll-Adressen (nachstehend „IP“-Adressen), MDS-Hashes von Malware-Dateien oder URLs oder Domänennamen von Botnetz-Befehls- und Kontrollservern. Nachdem IoCs in einem Fehlerbehebungs- und Computerforensik-Prozess identifiziert wurden, können sie für eine Früherkennung von zukünftigen Angriffsversuchen unter Verwendung von Intrusion-Detection-Systemen und Antivirensoftware verwendet werden. Bekannte Indikatoren werden gewöhnlich innerhalb der Branche ausgetauscht.
Der Begriff ‚Attribut eines Sicherheitsereignisses‘ kann ein Element eines aufgezeichneten Sicherheitsereignisses bezeichnen. Ein Attributwert kann auf eine E-Mail-Adresse eines Absenders, eine IP-Adresse, einen Betreff einer E-Mail, ein bestimmtes Textfragment im Hauptteil einer E-Mail und auf einen Zugriff auf eine bestimmte Datenbank, einen Hashwert eines böswilligen Anhangs und viele andere Werte in Bezug auf Attribute von Sicherheitsereignissen bezogen sein.
Der Begriff ‚Pseudosicherheitsereignis‘ kann ein künstlich erzeugtes Sicherheitsereignis bezeichnen, das innerhalb eines SIEM-System seinen Ursprung hat, welches versucht, sich selbst auf zukünftige eingehende Sicherheitsereignisse vorzubereiten, die von außerhalb des SIEM-Systems kommen. Diese Pseudosicherheitsereignisse können auf Daten beruhen, die auf wahrscheinliche Sicherheitsangriffe hinweisen, und sie können hilfreich sein, um das SIEM-System wachsamer für erwartete Angriffe als für andere bekannte mögliche Angriffe zu machen. Auf diese Weise kann das SIEM-System für eine bestimmte Sorte von erwarteten Cyberangriffen in einer oder mehreren Phasen einer Cybersicherheitsfolge trainiert werden. Eine Priorisierung und Erkennungsfolge durch eine sortierte Liste von Regeln kann dazu beitragen, Datenverarbeitungsressourcen einzusparen.
Der Begriff ‚Structured Threat Information Expression‘ (STIX) kann eine Repository von gesammelten Ausdrücken von cybersicherheitsrelevanten Ausdrücken bezeichnen. STIX ist eine vom U.S. Department of Homeland Security angeführte Initiative des Büros für Cybersicherheit und Heimat. STIX ist eine gemeinschaftsorientierte, von der Community geleitete Initiative zur Definition und Entwicklung einer strukturierten Sprache (d.h. eines Protokolls), um Informationen zu Cyberbedrohungen darzustellen. Die STIX-Sprache bringt das gesamte Spektrum an Informationen über mögliche Cyberbedrohungen zum Ausdruck und ist bestrebt, vollkommen ausdrucksstark, flexibel, erweiterbar, automatisierbar und so lesbar wie möglich zu sein. Alle interessierten Parteien sind willkommen, um an der Entwicklung von STIX als Teil ihrer offenen, gemeinschaftsorientierten Community teilzunehmen. STIX-Anwendungsfälle umfassen (i) das Analysieren von Cyberbedrohungen ; (ii) das Angeben von Indikatormustern für Cyberbedrohungen; (iii) das Verwalten von Cyberbedrohungs-Abwehr- und Interventionsaktivitäten; (iv) die gemeinsame Nutzung von Informationen zu Cyberbedrohungen.
Der Begriff ‚Regeln identifizierende Tactic-Technique-Procedure (TTP)‘ kann einen Satz von Regeln bezeichnen, gemäß denen Cybersicherheitsangriffe mit einer hohen Wahrscheinlichkeit identifiziert werden können, da die Regeln auf dem aktuellen Stand gehalten werden können und Regeln mit zugehörigen Indicators-of-Compromise für jede Phase einer Folge von Sicherheitsangriffen vorschlagen können.
Im Folgenden werden die Figuren ausführlich beschrieben. Alle Anweisungen in den Figuren sind schematisch. Zunächst ist ein Blockschaltbild einer Ausführungsform des erfindungsgemäßen Verfahrens zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasiertes Alarmschemas angegeben. Danach werden weitere Ausführungsformen sowie Ausführungsformen des SIEM-Systems zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasiertes Alarmschemas beschrieben.
1 zeigt ein Blockschaltbild einer Ausführungsform des Verfahrens 100 zum Verarbeiten von Sicherheitsereignissen. Die Verarbeitung wird durch Anwenden eines regelbasierten Alarmschemas durchgeführt, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird. Zu Aktivitäten des Verfahrens 100 gehören ein Erzeugen, 102, eines Regelindex von Regeln. Die Regeln werden üblicherweise beim Empfang eines eingehenden Sicherheitsereignisses angewendet.
Das Verfahren 100 umfasst auch ein Erzeugen, 104, eines Indicator-of-Compromise-(loC-)lndex für jede der Regeln, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert enthält, der für einen Vergleich mit einem Attributwert eines Sicherheitsereignisses zu verwenden ist. In Wirklichkeit werden nur zugehörige IoCs und Attributwerte des Sicherheitsereignisses - üblicherweise eine Mehrzahl - verglichen, wie E-Mail-Adressen, IP-Adressen, Betreffzeilen oder Textelemente (im Falle einer E-Mail), Hashwerte und dergleichen.
Das Verfahren umfasst ein Verarbeiten, 106, des eingehenden Sicherheitsereignisses durch sequenzielles Anwenden der Regeln. Während des regulären Betriebs kann dies Sicherheitsereignis um Sicherheitsereignis geschehen, während ein aktueller Regelzähler in Bezug auf eine ausgelöste Regel erhöht wird, deren Verarbeitung einen Verstoß ausgelöst hat, und ein aktueller, die ausgelöste Regel betreffender Indicator-of-Compromise-Zähler erhöht wird. Aufgrund der Ausgestaltung des vorgeschlagenen Konzepts können nicht alle eingehenden Sicherheitsereignisse im Rahmen aller Regeln und aller IoCs verarbeitet werden.
Das Verfahren 100 kann des Weiteren ein Erzeugen, 108, eines Pseudosicherheitsereignisses - insbesondere, um den Regelsatz zu trainieren - aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise und ein Verarbeiten, 110, der Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln umfassen. Das Verarbeiten weist folglich ein Erhöhen, 112, eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen, 114, eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse auf.
Schließlich umfasst das Verfahren 100 ein Sortieren, 116, der Regeln in dem Regelindex gemäß einem jeweiligen gewichteten Regelzähler - insbesondere entsprechend ihrer Wahrscheinlichkeit für ein Auslösen eines Verstoßes, z.B. in absteigender Reihenfolge, und ein Sortieren, 118, innerhalb einer jeden Regel der Indicator-of-Compromise-Werte in dem Indicator-of-Compromise-Index gemäß ihrem gewichteten aktuellen Indicator-of-Compromise-Zähler, ebenfalls, z.B., in absteigender Reihenfolge.
2 zeigt ein Blockschaltbild 200 eines Vergleichs 220 gemäß einer Ausführungsform. Das Blockschaltbild 200 eines Vergleichs 220 von Attributwerten eines Sicherheitsereignisses 202 mit Regeln 210 und 218 und zugehörigen Indicators-of-Compromise 204, 206, 208, 212, 214, 216, 212, 214, 216, 222, 224, 226. Das Sicherheitsereignis 202 kann in das SIEM-System gelangen. Das Sicherheitsereignis 202 kann über ein oder mehrere Attribute verfügen: attribute_1 204, attribute_2 206, ..., attribute_n 208. Je nach dem Typ des Sicherheitsereignisses 202 können die Attribute 204, 206, 208 völlig unterschiedlich sein. Eingehende E-Mails können bei Vergleich mit einer Datenbankanforderung oder einem Netzwerkzugriff völlig unterschiedliche Attribute haben. Jedoch können Komponenten des SIEM-Systems so ausgelegt werden, dass sie die verschiedenen Attribute identifizieren und trennen und sie als verschiedene Attributtypen zur weiteren Verarbeitung verwalten.
Bei einer Art von Verarbeitung kann es sich um einen Vergleich von ausgewählten der Attribute 204, 206, 208 mit Indicators-of-Compromise IoC_1 212, loC_2 214, ..., loC_m 216 handeln. Dabei kann das SIEM-System nur diese Attribute mit Indicators-of-Compromise desselben Typs vergleichen, was dazu beitragen kann, dass es Datenverarbeitungsressourcen einspart. Es kann auch angemerkt werden, dass die IoCs zu verschiedenen Regeln gehören, z.B. rule_1 210, ..., rule_x 218. Üblicherweise werden in einem SIEM-System Hunderte oder mehr Regeln verwaltet. Es dürfte offensichtlich sein, dass die erforderlichen Datenverarbeitungsressourcen, die Attribute des Sicherheitsereignisses 202 mit Anreizen und den zugehörigen IoCs vergleichen, rechenintensiv sein können. Um diesen Rechenaufwand zu verringern, veranschaulicht die nächste Figur, wie ein Sortieren und Priorisieren von Gruppen von Regeln sowie anderen Mechanismen, z.B. Puffern, dazu betragen kann, die Rechenzeit zu verringern, um Cybersicherheitsangriffe, d.h. böswillige Sicherheitsereignisse, sicher zu identifizieren.
3 zeigt ein Blockschaltbild einer Ausführungsform 300, das veranschaulicht, gemäß welchem Regelsatz und welchen Gruppen von IoCs ein eingehendes Ereignis verarbeitet wird. Ein SIEM-Datensatz oder Sicherheitsereignis 304 werden in einer z.B. Protokolldatei zwischengespeichert (FIFO), bevor sie durch eine Korrelationsengine (einen Regelprozessor) geschickt werden. In herkömmlichen SIEM-Systemen werden die Regeln von einem Menschen in eine statische Reihenfolge gebracht. Jedes Ereignis wird durch eine jede Regel verarbeitet. In jeder Regel wird das Attribut des Sicherheitsereignisses mit einer statischen Liste von gegebenen IoCs verglichen. In einer einzelnen Ausführung kann die Verarbeitung für ein bestimmtes Sicherheitsereignis beendet werden, sobald ein Verstoß erzeugt wird, und in einer weiteren Ausführung wird das Sicherheitsereignis ungeachtet einer Erzeugung eines Verstoßes durch alle Regeln geparst. Der Satz von Regeln, wie durch 302 angegeben, weist eine Mehrzahl von Regeln auf: rule_1 304, rule_2 306, rule_3 308, ..., rule_n 310.
Die Effizienz der Verarbeitung von herkömmlichen SIEM-Systemen hängt in hohem Maße von durch einen Menschen getroffenen Entscheidungen der Festlegung der Reihenfolge der Regeln ab. Die Regelreihenfolge ist statisch und wird in Abhängigkeit von aktuellen Hacking-Kampagnen/Angriffsmustern in verschiedenen Phasen einer Folge von Cybersicherheitsangriffen nicht geändert. Auch für herkömmliche SIEM-Systeme gültig: Die IoCs werden üblicherweise heruntergeladen und nicht unter Berücksichtigung von Leistungsparametern sortiert.
Im Gegensatz dazu und wie in 3 gezeigt ist, werden die Regeln 304, 306, 308, 310 nach der Wahrscheinlichkeit für das Erzeugen von Verstößen sortiert. Innerhalb einer jeden Regel werden IoCs nach der Wahrscheinlichkeit für das Erzeugen eines Verstoßes sortiert. Somit wird ein Ereignis nicht mit allen IoCs einer Regel abgeglichen; vielmehr werden die IoCs gruppiert und die Attribute eines jeden Ereignisses werden mit einer bestimmten Gruppe von IoCs verglichen. Es sei darauf hingewiesen, dass das vorgeschlagene Konzept auch funktioniert, wenn Angreifer ihre Spuren verschleiern, indem sie ihre „Fingerabdrücke“ wie beispielsweise eine IP-Adresse, eine E-Mail-Adresse, eine Signatur von infizierten Dateien usw. dynamisch ändern. Es dürfte auch klar sein, dass die Liste von IoCs Tausende von Einträgen aufweisen kann.
Die nummerierten Pfeile in 3 zeigen die beispielhafte Reihenfolge, in der ein Sicherheitsereignis durch die Regeln verarbeitet wird und die Attribute des Sicherheitsereignisses 304 mit IoCs abgeglichen werden. Es gibt Gruppen 314, 316, 318 der „bekanntesten“ IoCs in der Regel rule_1 304 (die die höchste Wahrscheinlichkeit für das Erzeugen eines Verstoßes haben kann). Ein Pfeil 312 kann angeben, dass diese IoCs zuerst verwendet werden, um zu prüfen, ob durch das Anwenden der Regel rule_1 304 auf ein eingehendes Sicherheitsereignis 304 ein Verstoß erzeugt wird.
In der Regel rule_2 306 sind zwei weitere Gruppen von IoCs hoch eingestuft, was durch einen Pfeil 320 angegeben ist. In der Regel rule_3 308 wird zunächst nur eine Gruppe von IoCs, die durch einen Pfeil 322 angegeben ist, geprüft. Von hier ab dürfte klar sein, in welcher Abfolge 1, 2, 3, 4, 5, 6, 7, 8, 9 die Gruppen und entsprechenden IoCs verwendet werden, um festzustellen, ob das eingehende Sicherheitsereignis 304 möglicherweise böswillig ist und somit einen Verstoß erzeugen kann.
Überdies wird das aktuelle Ereignis nach dem Schritt fünf (Pfeil 5) in einem FIFO-Zwischenpufferspeicher 324 gehalten, damit das nächste Sicherheitsereignis durch die vielversprechendsten Regeln geparst werden kann. Erst wenn der Zustrom eingehender Sicherheitsereignisse abbricht oder der Zwischenpufferspeicher voll ist, werden eingehende Sicherheitsereignisse aus dem Zwischenpufferspeicher ab dem verbleibenden Schritt 6 verarbeitet.
Als ein vorher festgelegter Parameter benötigt das Verfahren die Anzahl von Regelteilmengen (oder Regelprioritätsstufen), z.B. 2 oder 5, und die Anzahl von Ereignis-Zwischenpufferspeichern. Die Anzahl der Ereignispufferspeicher muss mindestens um eins geringer als die Anzahl der Regelteilmengen sein, da die Pufferspeicher zwischen den Teilmengen der IoCs platziert werden.
Wie zu erkennen ist, wird in der zweiten loC-Gruppe der Regel rule_2 306 ein Verstoß 326 zur weiteren Verarbeitung außerhalb der hier beschriebenen Sortierung von Regeln und IoCs erzeugt.
Das beschriebene Verfahren weist mindestens vier Aspekte auf:

Bereite einen Index und Zähler vor (ein Mal ausgeführt);
Verarbeite Ereignisse (ausgeführt bei jedem eingehenden Ereignis);
Erzeuge Pseudosicherheitsereignisse aus Informationen überTTPs und verarbeite Pseudosicherheitsereignisse (regelmäßig ausgeführt, z.B. nachdem eine vordefinierte Anzahl von Ereignissen geparst wurde, nachdem ein vordefiniertes Zeitintervall verstrichen ist); und
Regelsortierung und Pufferspeicher-Platzierung (ausgeführt, nachdem Pseudosicherheitsereignisse verarbeitet wurden).

Im Einzelnen: Vorbereitung von Indizes und Zählern:

Erzeuge einen Index von allen Regeln und einen Index von allen Vergleichsoperationen (Ereignisattribut mit loC) innerhalb einer jeden Regel;
Weise zwei „aktuelle“ Ganzzahlzähler bei jedem Indexeintrag zu, einen Zähler für beobachtete Ereignisse (reale Ereignisse) und einen Zähler für durch dieses Verfahren erzeugte Ereignisse (Pseudosicherheitsereignisse, siehe unten). Diese Zähler werden als „aktuell“ bezeichnet, da sie in dem aktuellen Zeitfenster erzeugte Verstöße zählen.

Weise zwei „vorherige“ Ganzzahlzähler bei jedem Indexeintrag in der gleichen Weise wie vorstehend zu. Diese Zähler werden als „vorherig“ bezeichnet, da sie die Anzahl der zuvor gezählten Verstöße aufweisen.
Im Einzelnen: Verarbeitung von Sicherheitsereignissen:

Wenn eine Regel, die einen Verstoß erzeugt, die aktuellen Zähler, d.h. die Zähler für beobachtete oder aktuelle Ereignisse, erhöht. In einer einzelnen Ausführung kann der Zähler um eins erhöht werden, in einer weiteren Ausführung kann er um ein Maß für die Größe des Verstoßes erhöht werden.

Wenn eine Regel einen Verstoß erzeugt hat, werden die aktuellen Zähler des entsprechenden IoC, d.h., ein oder mehrere Zähler eines beobachteten Ereignisses für eine aktuelle Regel, die dem/den Attribut(en) des Ereignisses entsprach, erhöht.
Im Einzelnen: Erzeugung von Pseudosicherheitsereignissen aus Informationen überTTPs und parse Pseudosicherheitsereignisse:

Sowohl Regel- als auch loC-Pseudosicherheitsereigniszähler werden auf Null gesetzt.

Rufe TTPs, die IoCs enthalten, aus einer vertrauenswürdigen externen Quelle ab (z.B. unter Verwendung des STIX-Protokolls).
Erzeuge Pseudosicherheitsereignisse aus den Informationen von TTPs:

a. Für jede TTP, die erzeugt wurde, ein Pseudosicherheitsereignis je Phase in der Folge von Sicherheitsangriffen (auch als Angriffskette bezeichnet);
b. Der Ereignistyp (und Protokollquellentyp) wird der Phase der Folge von Sicherheitsangriffen entnommen;
c. Die Attribute werden aus dem loC gefüllt. Erzeuge ein Pseudosicherheitsereignis je IoC.

Betrachte als ein Beispiel den bekannten TTP Spear Phishing Campaign, Phase 2 „Weaponization“: Eine böswillige E-Mail wird aus der Domäne @benefit-city.com mit dem Betreff „Post für Dich“ oder „Foto für Dich“ mit einem vom Hashschlüssel 3CB5F identifizierten Virus gesendet. Erzeuge zwei Ereignisse „Einen Virus enthaltende Post empfangen“ von dem Protokollquellen-Mailserver mit den vorstehenden Attributen.
Lass die Pseudosicherheitsereignisse durch den Regelsatz laufen.
Erhöhe für jede Regel, die einen Verstoß durch ein Pseudosicherheitsereignis erzeugt, den aktuellen Pseudosicherheitsereigniszähler um eins (oder in einer weiteren Ausführung um eine Gewichtung, die der Kampagne zugewiesen ist, aus der das Pseudosicherheitsereignis stammte).
Wenn eine Regel einen Verstoß erzeugt hat, erhöhe den/die aktuellen Pseudosicherheitsereigniszähler des entsprechenden loC von dieser Regel wie in dem vorherigen Schritt.
Im Einzelnen: Regelsortierung und Pufferspeicher-Platzierung:

Neue Regelzähler und loC-Zähler werden aus vorherigen Zählern und aktuellen Zählern wie folgt berechnet: $\begin{array}{l} n e u e r Z \ddot{a} h l e r = P * v o r h e r i g e r R e g e l z \ddot{a} h l e r + (w_{1} * b e o b a c h t e t e E r e i g n i s s e) + \\ (w_{2} * P s e u d o s i c h e r h e i t s e r e i g n i s s e), \end{array}$
$\begin{array}{l} neuer Z \ddot{a} hler = P * vorheriger Z \ddot{a} hler + (w_{1} * beobachtete Ereignisse + w_{2} * \\ Pseudosicherheitsereignisse), \end{array}$
wobei P ein vordefinierter Prozentwert (z.B. 50 %) ist, um den Einfluss von vorherigen Ereignissen zu begrenzen, und w₁ und w₂ vordefinierte Gewichtungen sind, die den Einfluss von beobachteten Ereignissen und erwarteten Ereignissen durch in der TTP-Datenbank registrierte laufende Kampagnen ausgleichen.

Die Regeln werden nach einem Wert ihrer neuen Regelzähler in z.B. einer absteigenden Reihenfolge sortiert, d.h., die Regel mit dem höchsten Zähler ist die erste in dem Regelsatz; Regeln, die nie ausgelöst haben, befinden sich am unteren Ende des Regelsatzes und werden zuletzt ausgewertet.
Innerhalb einer jeden Regel werden die Listen von IoCs nach den neuen loC-Zählern sortiert, z.B. in absteigender Reihenfolge, d.h., die Attribute eines Ereignisses werden zuerst mit den IoCs abgeglichen, die in der Vergangenheit am häufigsten in Attributen gefunden wurden, d.h., sie werden zuerst mit den IoCs abgeglichen, die höchstwahrscheinlich zur Erzeugung eines Verstoßes beitragen.
Setze alle aktuellen Regel- und aktuellen loC-Zähler auf 0 zurück.
Weise den Wert eines jeden neuen Regelzählers einem jeden vorherigen Regelzähler und den Wert eines neuen loC-Zählers einem jeden vorherigen loC-Zähler zu, d.h. vorheriger Zähler = neuer Zähler.
Erzeuge eine vordefinierte Anzahl von Ereignispufferspeichern innerhalb des Regelsatzes. Die Platzierung der Regel wird an die Ausführungsreihenfolge angepasst (siehe unten).
4 zeigt ein Blockschaltbild eines beispielhaften Ergebnisses 400 von Regel- und loC-Zählern gemäß einer Ausführungsform. 4 zeigt ein vereinfachtes Beispiel eines Regelsatzes, der 7 Regeln enthält. Die Regeln in dem Regelsatz wurden unter Befolgung des Schritts 2 von „Regelsortierung und Pufferspeicher-Platzierung“ geordnet. Die IoCs wurden unter Befolgung des Schritts 3 geordnet. Horizontale Linien bezogen sich auf verschiedene Regeln. Je Regel - gezeigt als vertikale Linien - werden IoC-Zähler aufgeführt. Z.B. zeigt die Regel mit der höchsten Anzahl 96 Zählwerte, wobei zugehörige IoC-Zähler anzeigen: IoC1 = 80, IoC2 = 20, IoC3 = 20, IoC4= 5, IoC5 = 1, IoC6 = 1 usw. Zählwerte.
In diesem Beispiel wird der Regelzähler um eins erhöht, wenn die Regel einen Verstoß erzeugt hat (nicht um eine Größe 1 bis 10 des Verstoßes). Innerhalb einer Regel ist die Summe der loC-Zähler üblicherweise höher als der Regelzähler, da mehrere loC zum Auslösen eines Verstoßes beitragen, z.B. kann eine Regel die Bedingung bei Ereignisattributen, mail_address=„info@benefit-city.com“ UND Betreff=„Post für Dich“, aufweisen.
In diesem Beispiel wird die Anzahl der Regelteilmengen (Regelprioritätsstufen) auf 3 gesetzt und die Anzahl der Ereignispufferspeicher wird auf 2 gesetzt. Jede Regelteilmenge wird entweder von einem relativen oder einem absoluten loC-Zähler beschrieben.
Ebenfalls in diesem Beispiel wird die relative Anzahl von loC-Zählern zur Definition von Teilmengen verwendet. Zuerst (höchste Priorität, diagonale Streifen) werden die Regeln und Vergleichsoperationen durchgeführt, um 90 % der loC-Zähler (Anzahl von 307 von insgesamt 342) abzudecken, d.h., die Attribute eines Ereignisses werden zuerst mit IoCs, die eine überwältigende Trefferzahl haben, jedoch nur mit der Minderheit der IoCs (11 von 56) abgeglichen. Nachdem dieses Ereignis durch die erste Regelteilmenge verarbeitet wurde, wird das Ereignis gepuffert (vgl. 5) und ein weiteres eingehendes Ereignis wird durch die erste Regelteilmenge verarbeitet.
Die zweite Regelteilmenge (waagerechte Streifen) wird von den Regeln und Vergleichsoperationen definiert, die 98 % der loC-Trefferzähler (Anzahl von 335) unter Ausschluss der bereits geprüften IoCs abdecken. Abermals wird ein Ereignis, nachdem es durch den zweiten Regelsatz verarbeitet wurde, gepuffert.
Die dritte Regelteilmenge (keine Streifen) weist die restlichen Vergleichsoperationen auf.
Eine reale Ausführung weist üblicherweise ein paar 100 Regeln und Listen mit IoCs auf, die Tausende von Einträgen aufweisen. Um das Beispiel realistischer zu machen, muss man sich noch weit mehr Regeln am unteren Ende des Regelsatzes vorstellen, die selten auslösen und Tausende von Spalten hinzufügen, die IoCs mit Nullen auf der rechten Seite enthalten. Dadurch wird der Vorteil dieser Erfindung offensichtlicher.
In einer weiteren Ausführung ist die erste Regelteilmenge definiert als: Führe für ein gegebenes Ereignis alle Vergleichsoperationen aus, die nur IoCs mit einem Zähler ≥10 verwenden. Die zweite Regelteilmenge enthält alle Vergleichsoperationen, die IoCs mit einem Zähler zwischen 9 und 1 verwenden. Die dritte Regelteilmenge enthält alle Vergleichsoperationen, die IoCs verwenden, welche gemäß ihrem Zähler keine Verstöße ausgelöst haben.
Das Verfahren erfordert es, dass die Puffergrößen (in Bezug auf die Anzahl der Ereignisse oder Megabyte) und die Standardverteilung der Datenverarbeitungsressourcen (z.B. virtuellen CPUs) vordefiniert sind. Es empfiehlt sich, die Puffergröße für alle Pufferspeicher auf den gleichen Wert zu setzen und dem ersten Regelsatz mehr Datenverarbeitungsressourcen und dem letzten Regelsatz weniger Datenverarbeitungsressourcen zuzuweisen, z.B. 50 %, 25 %, 12,5 % usw.
5 zeigt ein beispielhaftes Ergebnis 500 von Regel- und loC-Zählern in Kombination mit einer Ressourcenzuordnung gemäß einer Ausführungsform.
Man betrachte das vorherige Beispiel an einem Computer mit 8 virtuellen CPUs; standardmäßig können 4, 2, 1 CPUs 506, 508, 510 zugewiesen werden, um Ereignisse in der ersten, zweiten bzw. dritten Regelteilmenge zu verarbeiten. Die verbleibende CPU wird für die Gesamtkoordinierung zugewiesen.
Falls der Pufferspeicher A 502 voll ist und die ersten 4 CPUs 506 daher inaktiv sind, werden sie vorübergehend zur Verarbeitung von Ereignissen in der zweiten Regelteilmenge (waagerechte Streifen) zugewiesen. Sobald die Auslastung des Pufferspeichers A 502 zurückgeht (z.B. unter 80 %), werden die vier CPUs 502 erneut zur Verarbeitung von Ereignissen in der ersten Regelteilmenge zugewiesen. Das gleiche Verfahren wird angewendet, wenn der Pufferspeicher B 504 vollläuft.
Auf diese Weise wird sichergestellt, dass eingehende Ereignisse durch die vielversprechendsten Regeln verarbeitet werden, um Verstöße zu erzeugen, und Ereignisattribute schnell mit den bekanntesten IoCs abgeglichen werden, so dass Angriffe schneller erkannt werden.
Eine Erweiterung der vorstehend dargestellten Version des Verfahrens ist ebenfalls möglich. In der vorstehenden Ausführung befasst sich das Verfahren mit einem dynamisch optimierten Regelsatz. Die beiden Sätze von Ergebnissen in Bezug auf aus zwei Eingabequellen ‚beobachtete Ereignisse‘ und ‚Pseudosicherheitsereignisse‘ erzeugte Verstöße werden gewichtet.
In einer weiteren Ausführung kann das System zwei Regelsätze verwalten. Ein Regelsatz (der primäre Regelsatz) kann auf der Grundlage der Erzeugung eines Verstoßes durch beobachtete Ereignisse (d.h. w₂=0) optimiert werden. Standardmäßig wird der primäre Regelsatz in die Regelengine geladen und verarbeitet Ereignisse.
Ein weiterer Regelsatz (der sekundäre Regelsatz) kann auf der Grundlage der Erzeugung eines Verstoßes durch beobachtete Ereignisse und Pseudosicherheitsereignisse mit einer signifikanten Gewichtung w₃ optimiert werden. Die Pseudosicherheitsereignisse werden durch das vorstehende Verfahren erzeugt und in einer Datenbank gespeichert. Das Verfahren „verarbeite Ereignisse“ wird um einen extra Schritt erweitert: Falls die Anzahl von beobachteten Ereignissen, die Pseudosicherheitsereignissen entsprechen, einen vorher festgelegten Schwellenwert überschreitet, ersetzt der sekundäre Regelsatz den primären Regelsatz. Nach einem vorher festgelegten Zeitraum (definiert als Anzahl von verarbeiteten Ergebnissen oder verstrichene Zeit) wird der primäre Regelsatz wieder in die Regelengine geladen, außer wenn Ereignisse, die Pseudosicherheitsereignissen entsprechen, nach wie vor beobachtet werden.
In einer weiteren Ausführung sind mehr als zwei Regelsätze definiert. Pseudosicherheitsereignisse werden nach Bedrohungsszenario (aus der TTP-Quelle abgerufen) gruppiert: Ein Regelsatz deckt ein oder mehrere Bedrohungsszenarien ab. Wie vorstehend wird der entsprechende Regelsatz in die Regelengine geladen, wenn die Anzahl beobachteter Ereignisse, die Pseudosicherheitsereignissen eines bestimmten Bedrohungsszenarios entsprechen, einen vorher festgelegten Schwellenwert überschreitet.
6 zeigt ein Blockschaltbild eines SIEM-Systems 600 zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird. Das SIEM-System 600 enthält eine erste Erzeugungseinheit 602, die so ausgelegt ist, dass sie einen Regelindex von Regeln erzeugt, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses angewendet werden. Dabei ist die Erzeugungseinheit 602 auch so ausgelegt, dass sie einen Indicator-of-Compromise-Index für jede der Regeln erzeugt. Jeder Eintrag des Indicator-of-Compromise-Index weist einen Indikatorwert auf, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist.
Das System 600 enthält auch eine Korrelationsengine 604, die so ausgelegt ist, dass sie das eingehende Sicherheitsereignis durch sequenzielles Anwenden der Regeln verarbeitet, und ein Inkrementmodul 606, das so ausgelegt ist, dass es einen aktuellen Regelzähler in Bezug auf eine ausgelöste Regel erhöht, deren Verarbeitung einen Verstoß ausgelöst hat, wobei das Inkrementmodul auch so ausgelegt ist, dass es einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler erhöht.
Eine zweite Erzeugungseinheit 608, die so ausgelegt ist, dass sie ein Pseudosicherheitsereignis aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise erzeugt. Die Korrelationsengine 604 ist auch so ausgelegt, dass sie die Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln verarbeitet. Dabei weist das Verarbeiten ein Erhöhen, durch ein Pseudosicherheitsereignis-Zählermodul, eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen, durch einen Zähler für Indicator of Compromise für Pseudosicherheitsereignisse, eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse auf.
Ein zusätzliches Sortiermodul 610 des SIEM-Systems 600 ist so ausgelegt, dass es die Regeln in dem Regelindex gemäß einem jeweiligen gewichteten Regelzähler sortiert, und auch so ausgelegt, dass es innerhalb einer jeden Regel die Indicator-of-Compromise-Werte in dem Indicator-of-Compromise-Index gemäß ihrem gewichteten aktuellen Indicator-of-Compromise-Zähler sortiert.
Ausführungsformen der Erfindung können zusammen mit praktisch jeder Art von Computer, ungeachtet der zur Speicherung und/oder Ausführung von Programmcode geeigneten Plattform, umgesetzt werden. 7 zeigt als ein Beispiel ein Datenverarbeitungssystem 700, das zum Ausführen von Programmcode in Bezug auf das vorgeschlagene Verfahren geeignet ist.
Das Datenverarbeitungssystem 700 ist lediglich ein Beispiel eines geeigneten Computersystems und sollte ungeachtet dessen, ob das Computersystem 700 ausführungsfähig und/oder in der Lage ist, jedwede der vorstehend dargelegten Funktionalität durchzuführen, nicht als Hinweis auf eine Einschränkung hinsichtlich des Nutzungsumfangs oder der Funktionalität von Ausführungsformen der hierin beschriebenen Erfindung verstanden werden. In dem Computersystem 700 gibt es Komponenten, die mit zahlreichen anderen Universal- oder Spezialdatenverarbeitungssystemumgebungen oder - konfigurationen betrieben werden können. Zu Beispielen für hinlänglich bekannte Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die gegebenenfalls zur Verwendung mit dem Computersystem/Server 700 geeignet sind, gehören, ohne auf diese beschränkt zu sein, Personal-Computer-Systeme, Server-Computersysteme, Thin Clients, Thick Clients, tragbare oder Laptop-Einheiten, Mehrprozessorsysteme, auf einem Mikroprozessor beruhende Systeme, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Mainframe-Computersysteme und verteilte Cloud-Computing-Umgebungen, die beliebige der vorstehenden Systeme oder Einheiten enthalten, und dergleichen. Das Computersystem/der Server 700 kann in dem allgemeinen Kontext von durch ein Computersystem ausführbaren Anweisungen, wie zum Beispiel Programmmodulen, die durch ein Computersystem 700 ausgeführt werden, beschrieben werden. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen und so weiter umfassen, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen ausführen. Das Computersystem/der Server 700 kann in verteilten Cloud-Computing-Umgebungen in die Praxis umgesetzt werden, in denen Aufgaben von fernen Verarbeitungseinheiten durchgeführt werden, die durch ein Übertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in fernen Speichermedien eines Computersystems, zu denen auch Hauptspeichereinheiten gehören, befinden.
Wie in der Figur gezeigt ist, ist das Computersystem/der Server 700 in Form einer Universal-Datenverarbeitungseinheit gezeigt. Zu den Komponenten des Computersystems/Servers 700 können, ohne darauf beschränkt zu sein, ein oder mehrere Prozessoren oder Verarbeitungseinheiten 702, ein Systemspeicher 704 und ein Bus 706 gehören, die verschiedene Systemkomponenten, darunter den Systemspeicher 704, mit dem Prozessor 702 verbinden. Der Bus 706 stellt eine oder mehrere von beliebigen Busstrukturen von mehreren Arten von Busstrukturen dar, darunter einen Speicherbus oder einen Speichercontroller, einen peripheren Bus, einen Accelerated Graphics Port und einen Prozessor- oder lokalen Bus, der beliebige einer Vielfalt an Busarchitekturen verwendet. Beispielhaft und nicht als Einschränkung gehören zu diesen Architekturen ein Industry-Standard-Architecture-(ISA-)Bus, ein Micro-Channel-Architecture-(MCA-)Bus, ein Enhanced-ISA-(EISA-)Bus, ein lokaler Video-Electronics-Standards-Association-(VESA-)Bus und ein Peripheral-Component-Interconnects-(PCI-)Bus. Das Computersystem/der Server 700 enthält üblicherweise eine Vielfalt an durch ein Computersystem lesbaren Datenträgern. Bei diesen Datenträgern kann es sich um jedwede verfügbaren Datenträger handeln, auf die von dem Computersystem/Server 700 zugegriffen werden kann, und zu ihnen gehören sowohl flüchtige und nicht flüchtige als auch austauschbare und nicht austauschbare Datenträger.
Zum Systemspeicher 704 können durch ein Computersystem lesbare Datenträger in Form von flüchtigem Speicher, wie beispielsweise ein Direktzugriffsspeicher (RAM) 708 und/oder ein Cache 710, gehören. Das Computersystem/der Server 700 kann des Weiteren weitere austauschbare/nicht austauschbare, flüchtige/nicht flüchtige Speichermedien eines Computersystems enthalten. Lediglich beispielhaft kann ein Speichersystem 712 für das Lesen von und das Schreiben auf einen nicht austauschbaren, nicht flüchtigen Magnetdatenträger (nicht gezeigt und üblicherweise als „Festplattenlaufwerk“ bezeichnet) bereitgestellt werden. Obgleich nicht gezeigt, können ein Magnetplattenlaufwerk für das Lesen von und das Schreiben auf eine(r) austauschbare(n), nicht flüchtige(n) Magnetplatte (z.B. eine „Diskette“) und ein optisches Plattenlaufwerk für das Lesen von oder das Schreiben auf eine(r) austauschbare(n), nicht flüchtige(n) optische(n) Platte, wie beispielsweise ein CD-ROM, ein DVD-ROM, oder andere optische Datenträger bereitgestellt werden. In diesen Fällen kann jedes Plattenlaufwerk durch eine oder mehrere Datenträgerschnittstellen mit dem Bus 706 verbunden werden. Wie weiter dargestellt und nachstehend beschrieben wird, kann der Speicher 704 mindestens ein Programmprodukt enthalten, das über einen Satz (z.B. zumindest einen) von Programmmodulen verfügt, die so konfiguriert sind, dass sie die Funktionen von Ausführungsformen der Erfindung ausführen.
Das Programm/Dienstprogramm, das über einen Satz (zumindest einen) von Programmmodulen 716 verfügt, kann beispielhaft, und nicht als Einschränkung, im Speicher 704 gespeichert sein, ebenso wie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten. Die Betriebssysteme, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine Kombination daraus können jeweils eine Ausführung einer Netzwerkumgebung umfassen. Die Programmmodule 716 führen im Allgemeinen die Funktionen und/oder die Vorgehensweisen von Ausführungsformen der Erfindung aus, die hierin beschrieben sind.
Das Computersystem/der Server 700 kann auch mit einer oder mehreren externen Einheiten 718 wie beispielsweise einer Tastatur, einer Zeigereinheit, einem Bildschirm 720 usw.; mit einer oder mehreren Einheiten, die einem Benutzer den Dialogverkehr mit dem Computersystem/Server 700 ermöglichen; und/oder beliebigen Einheiten (z.B. Netzkarte, Modem usw.), die dem Computersystem/Server 700 den Datenaustausch mit einer oder mehreren anderen Datenverarbeitungseinheiten ermöglichen, Daten austauschen. Ein solcher Datenaustausch kann über Eingabe-/Ausgabe-(E/A-)Schnittstellen 714 erfolgen. Dennoch kann das Computersystem/der Server 700 mit einem oder mehreren Netzwerken wie zum Beispiel einem lokalen Netz (LAN), einem allgemeinen Weitverkehrsnetz (WAN) und/oder einem öffentlichen Netz (z.B. dem Internet) über den Netzwerkadapter 722 Daten austauschen. Wie dargestellt ist, kann der Netzwerkadapter 722 mit den anderen Komponenten des Computersystems/Servers 700 über den Bus 706 Daten austauschen. Es sollte klar sein, dass auch andere Hardware- und/oder Software-Komponenten in Verbindung mit dem Computersystem/Server 700 verwendet werden könnten, obgleich diese nicht gezeigt sind. Zu Beispielen gehören, ohne darauf beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Anordnungen von Plattenlaufwerken, RAID-Systeme, Bandlaufwerke sowie Speichersysteme zur Datenarchivierung usw.
Zusätzlich kann das SIEM-System 600 zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas an das Bussystem 706 angeschlossen werden.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung erfolgten zum Zweck der Veranschaulichung, sollen jedoch nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Änderungen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang und Wesen der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt befindlicher Technologien am besten zu erklären bzw. um anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.
Die vorliegende Erfindung kann als ein System, ein Verfahren und/oder ein Computerprogrammprodukt realisiert sein. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem Medium kann es sich um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder ein Halbleitersystem für ein Weitergabemedium handeln. Zu Beispielen für einen durch einen Computer lesbaren Datenträger können ein Halbleiter- oder ein Solid-State-Speicher, ein Magnetband, eine austauschbare Computerdiskette, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), eine magnetische Festplatte und eine optische Platte gehören. Zu aktuellen Beispielen für optische Platten gehören ein Compact-Disk-Nur-Lese-Speicher (CD-ROM), eine CD-RW, eine digitale Videoplatte (DVD) und eine Blu-Ray-Disk.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übermittelte elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field-programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die hierin verwendete Terminologie dient lediglich dazu, bestimmte Ausführungsformen zu beschreiben und ist nicht als Einschränkung der Erfindung zu verstehen. In der Verwendung hierin sollen die Singular-Formen „ein“, „eine“ und „der“, „die“, „das“ auch die Pluralformen einschließen, sofern der Kontext nicht eindeutig etwas anderes angibt. Es wird des Weiteren darauf hingewiesen, dass die Begriffe „aufweist“ und/oder „aufweisend“, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten bezeichnen, das Vorhandensein oder das Hinzufügen von einem oder mehreren anderen/weiteren Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon jedoch nicht ausschließen.
Die entsprechenden Strukturen, Materialien, Vorgänge und Äquivalente von allen Mitteln oder Schritten plus Funktionselementen in den nachstehenden Ansprüchen sollen jedwede Struktur, jedwedes Material oder jedweden Vorgang zur Durchführung der Funktion in Kombination mit anderen beanspruchten Elementen, die im Einzelnen beansprucht werden, mit einschließen. Die Beschreibung der vorliegenden Erfindung erfolgte zum Zweck der Veranschaulichung und Erläuterung, soll aber nicht erschöpfend oder auf die Erfindung in der offenbarten Form beschränkt sein. Viele Änderungen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang und Wesen der Erfindung abzuweichen. Die Ausführungsformen werden gewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung bestmöglich zu erklären und um anderen Fachleuten das Verständnis der Erfindung hinsichtlich verschiedener Ausführungsformen mit verschiedenen Änderungen, wie sie für die jeweilige vorgesehene Verwendung geeignet sind, zu ermöglichen.
Kurz zusammengefasst, kann das erfindungsgemäße Konzept durch die folgenden Klauseln beschrieben werden:

Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwendung eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird, wobei das Verfahren umfasst: Erzeugen eines Regelindex von Regeln, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind; Erzeugen eines Indicator-of-Compromise-Index für jede der Regeln, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert enthält, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist; Verarbeiten des eingehenden Sicherheitsereignisses durch sequenzielles Anwenden der Regeln, wobei das Verarbeiten ein Erhöhen, in einem Regelinkrementierungsschritt, eines aktuellen Regelzählers in Bezug auf eine ausgelöste Regel, deren Verarbeitung einen Verstoß ausgelöst hat, und ein Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers umfasst; Erzeugen eines Pseudosicherheitsereignisses aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise; und Verarbeiten der Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln, wobei das Verarbeiten ein Erhöhen, in einem Regelinkrementierungsschritt, eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse, und ein Sortieren der Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten sowie ein Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten aktuellen Indicator-of-Compromise-Zählerwerten umfasst.

Das Verfahren, bei dem das Sortieren der Regeln auch ein Feststellen der gewichteten Regelzählerwerte umfasst, indem gewichtete vorherige Regelzählerwerte und gewichtete aktuelle Regelzählerwerte der Regel kombiniert werden.
Das Verfahren, bei dem das Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise auch ein Feststellen der gewichteten Indicator-of-Compromise-Zählerwerte umfasst, indem gewichtete vorherige Indicator-of-Compromise-Zählerwerte und gewichtete aktuelle Indicator-of-Compromise-Zählerwerte des jeweiligen Indicator of Compromise kombiniert werden.
Das Verfahren, bei dem der Regelinkrementierungsschritt auch ein Erhöhen des aktuellen Regelzählers um eine feste Zahl oder um eine Zahl, die auf eine Schwere des Verstoßes hinweist, umfasst.
Das Verfahren, bei dem das Erhöhen des aktuellen Indicator-of-Compromise-Zählers auch ein Erhöhen des aktuellen Indicator-of-Compromise-Zählers um eine feste Zahl umfasst.
Das Verfahren, bei dem das Erzeugen des Pseudosicherheitsereignisses ein Anwenden einer Tactic-Technique-Procedure (TTP) umfasst, die Daten aus den empfangenen Daten über bekannte Angriffe identifiziert, wobei die empfangenen Daten über bekannte Angriffe über ein strukturiertes Bedrohungsinformationsausdruck-(STIX- )Protokoll empfangen werden.
Das Verfahren, bei dem das Erzeugen des Pseudosicherheitsereignisses ein Erzeugen eines Pseudosicherheitsereignisses für jede Phase einer Folge von teilweisen Cyberangriffen umfasst, die durch Angriffsmuster dargestellt werden.
Das Verfahren, bei dem das Erzeugen des Pseudosicherheitsereignisses ein Erzeugen eines Pseudosicherheitsereignisses für jeden Indicator of Compromise umfasst, der sich auf eine jeweilige Regel bezieht.
Das Verfahren, bei dem das Erzeugen eines Pseudosicherheitsereignisses auch ein Zurücksetzen des aktuellen Regelzählers von Pseudosicherheitsereignissen auf Null und ein Zurücksetzen des aktuellen Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse auf Null umfasst.
Das Verfahren, bei dem das Sortieren der Regeln in dem Regelindex ein Feststellen des gewichteten Regelzählers RC_w durch $\begin{array}{l} R C_{w} = P * v o r h e r i g e r R e g e l z \ddot{a} h l e r + (w_{1} * b e o b a c h t e t e E r e i g n i s s e) + (w_{2} \\ * P s e u d o s i c h e r h e i t s e r e i g n i s s e) \end{array}$
umfasst, wobei P = ein vordefinierter Prozentwert und w₁, w₂ = vordefinierte Gewichtungsfaktorwerte sind.
Wobei das Verfahren auch ein Puffern des eingehenden Sicherheitsereignisses, nachdem eine vorher festgelegte erste Anzahl von Regeln verarbeitet wurde und innerhalb einer jeden verarbeiteten Regel eine vorher festgelegte zweite Anzahl von Indicator-of-Compromise-Zählergruppen verarbeitet wurde, und ein Fortsetzen der Verarbeitung des gepufferten Sicherheitsereignisses, wenn eine Verarbeitungslast von eingehenden Sicherheitsereignissen unter einen vordefinierten Lastschwellenwert fällt, umfasst.
Ein SIEM-System zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird, wobei das System enthält: eine erste Erzeugungseinheit, die so ausgelegt ist, dass sie einen Regelindex von Regeln erzeugt, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind, wobei die Erzeugungseinheit auch so ausgelegt ist, dass sie einen Indicator-of-Compromise-Index für jede der Regeln erzeugt, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert aufweist, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist; eine Korrelationsengine, die so ausgelegt ist, dass sie das eingehende Sicherheitsereignis durch sequenzielles Anwenden der Regeln verarbeitet; ein Inkrementmodul, das so ausgelegt ist, dass es einen aktuellen Regelzähler in Bezug auf eine ausgelöste Regel erhöht, deren Verarbeitung einen Verstoß ausgelöst hat, wobei das Inkrementmodul auch so ausgelegt ist, dass es einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler erhöht; eine zweite Erzeugungseinheit, die so ausgelegt ist, dass sie ein Pseudosicherheitsereignis aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise erzeugt; und wobei die Korrelationsengine auch so ausgelegt ist, dass sie die Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln verarbeitet, wobei das Verarbeiten ein Erhöhen, durch ein Pseudosicherheitsereignis-Zählermodul, eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen, durch einen Zähler für Indicator of Compromise für Pseudosicherheitsereignisse, eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse umfasst, und ein Sortiermodul, das so ausgelegt ist, dass es die Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten sortiert, und das so ausgelegt ist, dass es die Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten Indicator-of-Compromise-Zählerwerten innerhalb einer jeden Regel sortiert.
Das System, bei dem das Sortiermodul auch so ausgelegt ist, dass es die gewichteten Regelzählerwerte feststellt, indem es einen gewichteten vorherigen Regelzähler und einen gewichteten aktuellen Regelzähler der Regel kombiniert.
Das System, bei dem das Sortiermodul auch so ausgelegt ist, dass es die gewichteten Indicator-of-Compromise-Zählerwerte feststellt, indem es einen gewichteten vorherigen Indicator-of-Compromise-Zähler und einen gewichteten aktuellen Indicator-of-Compromise-Zähler des jeweiligen Indikatorwerts kombiniert.
Das System, bei dem das Inkrementmodul auch so ausgelegt ist, dass es den aktuellen Regelzähler um eine feste Zahl oder um eine Zahl, die auf eine Schwere des Verstoßes hinweist, erhöht.
Das System, bei dem das Inkrementmodul auch so ausgelegt ist, dass es den aktuellen Indicator-of-Compromise-Zähler um eine feste Zahl erhöht.
Das System, bei dem die zweite Erzeugungseinheit auch so ausgelegt ist, dass sie eine Tactic-Technique-Procedure (TTP) anwendet, die Daten aus den empfangenen Daten über bekannte Angriffe identifiziert, wobei die empfangenen Daten über bekannte Angriffe über ein strukturiertes Bedrohungsinformationsausdruck-(STIX-)Protokoll empfangen werden.
Das System, bei dem die zweite Erzeugungseinheit auch so ausgelegt ist, dass sie ein Pseudosicherheitsereignis für jede Phase einer Folge von teilweisen Cyberangriffen erzeugt, die durch Angriffsmuster dargestellt werden.
Das System, bei dem die zweite Erzeugungseinheit auch so ausgelegt ist, dass sie ein Pseudosicherheitsereignis für jeden Indicator of Compromise erzeugt, der sich auf eine jeweilige Regel bezieht.
Das System, bei dem die zweite Erzeugungseinheit auch so ausgelegt ist, dass er den aktuellen Regelzähler von Pseudosicherheitsereignissen auf Null zurücksetzt und den aktuellen Indicator-of-Compromise-Zähler für Pseudosicherheitsereignisse auf Null zurücksetzt.
Das System, bei dem das Sortiermodul auch so ausgelegt ist, dass es den gewichteten Regelzähler RC_w durch $\begin{array}{l} R C_{w} = P * v o r h e r i g e r R e g e l z \ddot{a} h l e r + (w_{1} * b e o b a c h t e t e E r e i g n i s s e) + (w_{2} \\ * P s e u d o s i c h e r h e i t s e r e i g n i s s e) \end{array}$
feststellt, wobei P = ein vordefinierter Prozentwert und w₁, w₂ = vordefinierte Gewichtungsfaktorwerte sind.
Wobei das System auch einen Zwischenspeicher enthält, der so ausgelegt ist, dass er das eingehende Sicherheitsereignis puffert, nachdem eine vorher festgelegte erste Anzahl von Regeln verarbeitet wurde und innerhalb einer jeden verarbeiteten Regel eine vorher festgelegte zweite Anzahl von Indikatorwertgruppen verarbeitet wurde, und auch so ausgelegt ist, dass er eine Fortsetzung der Verarbeitung des gepufferten Sicherheitsereignisses auslöst, wenn eine Verarbeitungslast von eingehenden Sicherheitsereignissen unter einen vordefinierten Lastschwellenwert fällt.
Ein Computerprogrammprodukt zum Verarbeiten von Sicherheitsereignissen durch Anwendung eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird, wobei das Computerprogrammprodukt ein durch einen Computer lesbares Speichermedium mit realisierten Programmanweisungen enthält, wobei die Programmanweisungen durch ein oder mehrere Datenverarbeitungssysteme oder Controller ausführbar sind, um das eine oder die mehreren Datenverarbeitungssysteme zu veranlassen: einen Regelindex von Regeln zu erzeugen, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind; einen Indicator-of-Compromise-Index für jede der Regeln zu erzeugen, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert enthält, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist; das eingehende Sicherheitsereignis durch sequenzielles Anwenden der Regeln zu verarbeiten, einen aktuellen Regelzähler in Bezug auf eine ausgelöste Regel zu erhöhen, deren Verarbeitung einen Verstoß ausgelöst hat; einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler zu erhöhen; ein Pseudosicherheitsereignis aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise zu erzeugen; und die Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln zu verarbeiten, wobei das Verarbeiten ein Erhöhen eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse, und ein Sortieren der Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten sowie ein Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten Indicator-of-Compromise-Zählerwerten umfasst.
Die hierin beschriebenen Programme werden auf der Grundlage der Anwendung, für die sie in einer bestimmten Ausführungsform der Erfindung ausgeführt werden, angegeben. Es ist jedoch darauf hinzuweisen, dass jedwede bestimmte Programm-Nomenklatur hierin lediglich aus Gründen der Zweckmäßigkeit verwendet wird, und somit sollte die Erfindung nicht auf eine ausschließliche Verwendung in einer bestimmten Anwendung, die von dieser Nomenklatur angegeben und/oder durch diese Nomenklatur stillschweigend vorausgesetzt wird, beschränkt sein.
Ausführungsformen der Erfindung können Endbenutzern durch eine Cloud-Computing-Infrastruktur bereitgestellt werden. Cloud-Computing bezieht sich im Allgemeinen auf die als ein Dienst über ein Netzwerk erfolgende Bereitstellung von skalierbaren Datenverarbeitungsressourcen. Formaler ausgedrückt, Cloud-Computing kann als eine Möglichkeit der Datenverarbeitung definiert werden, die eine Abstraktion zwischen der Datenverarbeitungsressource und ihrer zugrunde liegenden technischen Architektur (z.B. Server, Speicher, Netzwerke) bereitstellt, was einen komfortablen, bedarfsweisen Netzwerkzugriff auf einen gemeinsam genutzten Bestand an konfigurierbaren Datenverarbeitungsressourcen ermöglicht, die schnell bereitgestellt und mit minimalem Verwaltungsaufwand oder minimaler Interaktion eines Dienstanbieters freigegeben werden können. Folglich ermöglicht das Cloud-Computing einem Benutzer den Zugriff auf virtuelle Datenverarbeitungsressourcen (z.B. Speicher, Daten, Anwendungen und sogar ganze virtualisierte Datenverarbeitungssysteme) in „der Cloud“, ohne Rücksicht auf die zugrunde liegenden physischen Systeme (oder Standorte dieser Systeme), die zur Bereitstellung der Datenverarbeitungsressourcen verwendet werden.
Üblicherweise werden Cloud-Computing-Ressourcen einem Benutzer nutzungsorientiert bereitgestellt, wobei Benutzern nur die tatsächlich verwendeten Datenverarbeitungsressourcen berechnet werden (z.B. durch einen Benutzer verbrauchter Speicherplatz oder eine Anzahl von virtualisierten, durch den Benutzer instanziierter Systeme). Ein Benutzer kann jederzeit und von überall über das Internet auf beliebige der Ressourcen zugreifen, die sich in der Cloud befinden. Im Kontext der vorliegenden Erfindung kann ein Benutzer auf eine normierte Suchmaschine oder zugehörige, in der Cloud vorhandene Daten zugreifen. Zum Beispiel könnte die normierte Suchmaschine auf einem Datenverarbeitungssystem in der Cloud ausgeführt werden und normierte Suchen ausführen. In einem solchen Fall könnte die normierte Suchmaschine einen Korpus von Informationen normieren und einen Index der Normierungen an einer Speicherposition in der Cloud speichern. Damit wird einem Benutzer ermöglicht, von einem beliebigen Datenverarbeitungssystem aus, das an ein mit der Cloud verbundenes Netzwerk (z.B. das Internet) angeschlossen ist, auf diese Informationen zugreifen.
Es sei von vornherein klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing enthält. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen weiteren Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden.
Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften umfassen, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle.
Bei den Eigenschaften handelt es sich um die folgenden:On-Demand Self-Service:

Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.

Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
Bei den Dienstmodellen handelt es sich um die folgenden:

Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.

Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
Bei den Einsatzmodellen handelt es sich um die folgenden:

Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.

Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten aufweist.
Unter Bezugnahme auf 8 ist eine veranschaulichende Cloud-Computing-Umgebung 800 dargestellt. Wie gezeigt ist, enthält die Cloud-Computing-Umgebung 800 einen oder mehrere Cloud-Computing-Knoten 810, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie zum Beispiel ein elektronischer Assistent (PDA, personal digital assistant) oder ein Mobiltelefon 840A, ein Desktop-Computer 840B, ein Laptop-Computer 840C und/oder ein Automobil-Computer-System 840N Daten austauschen können. Die Cloud-Computing-Knoten 810 können miteinander Daten austauschen. Sie können physisch oder virtuell in ein oder mehrere Netzwerke wie private, Benutzergemeinschafts-, öffentliche oder hybride Clouds gruppiert werden (nicht gezeigt), wie vorstehend beschrieben wurde, oder in eine Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 800, Infrastruktur, Plattformen und/oder Software als Dienst anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten von in 8 gezeigten Datenverarbeitungseinheiten 840A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 810 und die Cloud-Computing-Umgebung 800 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
Unter Bezugnahme auf 9 ist ein Satz von funktionalen Abstraktionsschichten gezeigt, die von der Cloud-Computing-Umgebung 800 (wie in 8 gezeigt) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 9 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:

Eine Hardware- und Software-Schicht 960 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe-Computer 961; auf der RISC-(Reduced-Instruction-Set-Computer-)Architektur beruhende Server 962; Server 963; Blade-Server 964; Speichereinheiten 965; und Netzwerke sowie Netzwerkkomponenten 966. In einigen Ausführungsformen umfassen Software-Komponenten eine Netzwerk-Anwendungsserver-Software 967 und Datenbank-Software 968.

Die Virtualisierungsschicht 970 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 971; virtueller Speicher 972, zum Beispiel der Systemspeicher, wie in 7 gezeigt; virtuelle Netzwerke 973, darunter virtuelle private Netzwerke; virtuelle Anwendungen und Betriebssysteme 974; und virtuelle Clients 975.
In einem Beispiel kann eine Verwaltungsschicht 980 die nachstehend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 981 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 982 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können zu diesen Ressourcen Anwendungs-Software-Lizenzen gehören. Die Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 983 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 984 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 985 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.
Eine Arbeitslastschicht 990 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 991; Software-Entwicklung und Lebenszyklusverwaltung 992; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 993; Datenanalytikverarbeitung 994; Transaktionsverarbeitung 995; und Sicherheitsinformations- und Ereignisverwaltung 996. Die Sicherheitsinformations- und Ereignisverwaltung 996 kann sich auf das Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Schemas beziehen.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt auf jeder möglichen Integrationsstufe technischer Details handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übermittelte elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten, Konfigurationsdaten für eine integrierte Schaltung oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field-programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt enthält, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Der Ablaufplan und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufplan oder in den Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) enthält. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung erfolgten zum Zweck der Veranschaulichung, sollen jedoch nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Änderungen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt befindlicher Technologien am besten zu erklären bzw. um anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.

Claims

Verfahren zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird, wobei das Verfahren umfasst: Erzeugen eines Regelindex von Regeln, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind; Erzeugen eines Indicator-of-Compromise-Index für jede der Regeln, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert aufweist, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist; Verarbeiten des eingehenden Sicherheitsereignisses durch sequenzielles Anwenden der Regeln, wobei ein Verarbeiten des eingehenden Sicherheitsereignisses durch sequenzielles Anwenden der Regeln aufweist: Erhöhen, in einem Regelinkrementierungsschritt, eines aktuellen Regelzählers in Bezug auf eine ausgelöste Regel, deren Verarbeitung einen Verstoß ausgelöst hat, und Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers; Erzeugen eines Pseudosicherheitsereignisses aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise; und Verarbeiten der Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln, wobei ein Verarbeiten der Pseudosicherheitsereignisse aufweist: Erhöhen eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und Erhöhen eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse, Sortieren der Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten, und Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten aktuellen Indicator-of-Compromise-Zählerwerten.
Verfahren nach Anspruch 1, wobei das Sortieren der Regeln auch aufweist: Feststellen der gewichteten Regelzählerwerte, indem gewichtete vorherige Regelzählerwerte und gewichtete aktuelle Regelzählerwerte der Regel kombiniert werden.
Verfahren nach Anspruch 1 oder 2, wobei das Sortieren, innerhalb einer jeden Regel, der Indicators-of-Compromise auch aufweist: Feststellen der gewichteten Indicator-of-Compromise-Zählerwerte, indem gewichtete vorherige Indicator-of-Compromise-Zählerwerte und gewichtete aktuelle Indicator-of-Compromise-Zählerwerte des jeweiligen Indicator of Compromise kombiniert werden.
Verfahren nach einem der Ansprüche 1 bis 3, wobei der Regelinkrementierungsschritt auch aufweist: Erhöhen des aktuellen Regelzählers um eine feste Zahl oder um eine Zahl, die auf eine Schwere des Verstoßes hinweist.
Verfahren nach einem der Ansprüche 1 bis 4, wobei das Erhöhen des aktuellen Indicator-of-Compromise-Zählers auch aufweist: Erhöhen des aktuellen Indicator-of-Compromise-Zählers um eine feste Zahl.
Verfahren nach einem der Ansprüche 1 bis 5, wobei das Erzeugen des Pseudosicherheitsereignisses aufweist: Anwenden einer Tactic-Technique-Procedure (TTP), die Daten aus den empfangenen Daten über bekannte Angriffe identifiziert, wobei die empfangenen Daten über bekannte Angriffe über ein strukturiertes Bedrohungsinformationsausdruck-(STIX- )Protokoll empfangen werden.
Verfahren nach einem der Ansprüche 1 bis 6, wobei das Erzeugen des Pseudosicherheitsereignisses aufweist: Erzeugen eines Pseudosicherheitsereignisses für jede Phase einer Folge von teilweisen Cyberangriffen, die durch Angriffsmuster dargestellt werden.
Verfahren nach einem der Ansprüche 1 bis 7, wobei das Erzeugen des Pseudosicherheitsereignisses aufweist: Erzeugen eines Pseudosicherheitsereignisses für jeden Indicator of Compromise, der sich auf eine jeweilige Regel bezieht.
Verfahren nach einem der Ansprüche 1 bis 8, wobei das Erzeugen eines Pseudosicherheitsereignisses auch aufweist: Zurücksetzen des aktuellen Regelzählers von Pseudosicherheitsereignissen auf Null; und Zurücksetzen des aktuellen Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse auf Null.
Verfahren nach einem der Ansprüche 1 bis 9, wobei das Sortieren der Regeln in dem Regelindex aufweist: Feststellen des gewichteten Regelzählers RC_w durch $\begin{array}{l} R C_{w} = P * v o r h e r i g e r R e g e l z \ddot{a} h l e r + (w_{1} * b e o b a c h t e t e E r e i g n i s s e) + (w_{2} * \\ P s e u d o s i c h e r h e i t s e r e i g n i s s e), \end{array}$
wobei P = ein vordefinierter Prozentwert und w₁, w₂ = vordefinierte Gewichtungsfaktorwerte sind.
Verfahren nach einem der Ansprüche 1 bis 10, das auch aufweist: Puffern des eingehenden Sicherheitsereignisses, nachdem eine vorher festgelegte erste Anzahl von Regeln verarbeitet wurde und innerhalb einer jeden verarbeiteten Regel eine vorher festgelegte zweite Anzahl von Indicator-of-Compromise-Zählergruppen verarbeitet wurde; und Fortsetzen die Verarbeitung des gepufferten Sicherheitsereignisses, wenn eine Verarbeitungslast von eingehenden Sicherheitsereignissen unter einen vordefinierten Lastschwellenwert fällt.
SIEM-System zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird, wobei das System aufweist: eine erste Erzeugungseinheit, die so ausgelegt ist, dass sie einen Regelindex von Regeln erzeugt, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind, wobei die Erzeugungseinheit auch so ausgelegt ist, dass sie einen Indicator-of-Compromise-Index für jede der Regeln erzeugt, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert aufweist, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist; eine Korrelationsengine, die so ausgelegt ist, dass sie das eingehende Sicherheitsereignis durch sequenzielles Anwenden der Regeln verarbeitet; ein Inkrementmodul, das so ausgelegt ist, dass es einen aktuellen Regelzähler in Bezug auf eine ausgelöste Regel erhöht, deren Verarbeitung einen Verstoß ausgelöst hat, wobei das Inkrementmodul auch so ausgelegt ist, dass es einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler erhöht; und eine zweite Erzeugungseinheit, die so ausgelegt ist, dass sie ein Pseudosicherheitsereignis aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise erzeugt, wobei die Korrelationsengine auch so ausgelegt ist, dass sie die Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln verarbeitet, wobei das Verarbeiten ein Erhöhen, durch ein Pseudosicherheitsereignis-Zählermodul, eines aktuellen Regelzählers von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel, deren Verarbeitung den Verstoß ausgelöst hat, und ein Erhöhen, durch einen Zähler für Indicator of Compromise für Pseudosicherheitsereignisse, eines aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zählers für Pseudosicherheitsereignisse, und ein Sortiermodul aufweist, das so ausgelegt ist, dass es die Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten sortiert, und das so ausgelegt ist, dass es die Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten Indicator-of-Compromise-Zählerwerten innerhalb einer jeden Regel sortiert.
System nach Anspruch 12, wobei das Sortiermodul auch so ausgelegt ist, dass es die gewichteten Regelzählerwerte feststellt, indem es einen gewichteten vorherigen Regelzähler und einen gewichteten aktuellen Regelzähler der Regel kombiniert.
System nach einem der Ansprüche 12 oder 13, wobei das Sortiermodul auch so ausgelegt ist, dass es die gewichteten Indicator-of-Compromise-Zählerwerte feststellt, indem es einen gewichteten vorherigen Indicator-of-Compromise-Zähler und einen gewichteten aktuellen Indicator-of-Compromise-Zähler des jeweiligen Indikatorwerts kombiniert.
System nach einem der Ansprüche 12 bis 14, wobei das Inkrementmodul auch so ausgelegt ist, dass es den aktuellen Regelzähler um eine feste Zahl oder um eine Zahl, die auf eine Schwere des Verstoßes hinweist, erhöht.
System nach einem der Ansprüche 12 bis 15, wobei das Inkrementmodul auch so ausgelegt ist, dass es den aktuellen Indicator-of-Compromise-Zähler um eine feste Zahl erhöht.
System nach einem der Ansprüche 12 bis 16, wobei die zweite Erzeugungseinheit auch so ausgelegt ist, dass sie eine Tactic-Technique-Procedure (TTP) anwendet, die Daten aus den empfangenen Daten über bekannte Angriffe identifiziert, wobei die empfangenen Daten über bekannte Angriffe über ein strukturiertes Bedrohungsinformationsausdruck-(STIX-)Protokoll empfangen werden.
System nach einem der Ansprüche 12 bis 17, wobei die zweite Erzeugungseinheit auch so ausgelegt ist, dass sie ein Pseudosicherheitsereignis für jede Phase einer Folge von teilweisen Cyberangriffen erzeugt, die durch Angriffsmuster dargestellt werden.
System nach einem der Ansprüche 12 bis 18, wobei die zweite Erzeugungseinheit auch so ausgelegt ist, dass sie ein Pseudosicherheitsereignis für jeden Indicator of Compromise erzeugt, der sich auf eine jeweilige Regel bezieht.
System nach einem der Ansprüche 12 bis 19, wobei der zweite Generator auch so ausgelegt ist, dass er den aktuellen Regelzähler von Pseudosicherheitsereignissen auf Null zurücksetzt und den aktuellen Indicator-of-Compromise-Zähler für Pseudosicherheitsereignisse auf Null zurücksetzt.
System nach einem der Ansprüche 12 bis 20, wobei das Sortiermodul auch so ausgelegt ist, dass es den gewichteten Regelzähler RC_w durch $\begin{array}{l} R C_{w} = P * v o r h e r i g e r R e g e l z \ddot{a} h l e r + (w_{1} * b e o b a c h t e t e E r e i g n i s s e) + (w_{2} \\ * P s e u d o s i c h e r h e i t s e r e i g n i s s e) \end{array}$
feststellt, wobei P = ein vordefinierter Prozentwert und w₁, w₂ = vordefinierte Gewichtungsfaktorwerte sind.
System nach einem der Ansprüche 12 bis 21, das des Weiteren aufweist: einen Zwischenspeicher, der so ausgelegt ist, dass er das eingehende Sicherheitsereignis puffert, nachdem eine vorher festgelegte erste Anzahl von Regeln verarbeitet wurde und innerhalb einer jeden verarbeiteten Regel eine vorher festgelegte zweite Anzahl von Indikatorwertgruppen verarbeitet wurde, und der auch so ausgelegt ist, dass er eine Fortsetzung der Verarbeitung des gepufferten Sicherheitsereignisses auslöst, wenn eine Verarbeitungslast von eingehenden Sicherheitsereignissen unter einen vordefinierten Lastschwellenwert fällt.
Computerprogrammprodukt zum Verarbeiten von Sicherheitsereignissen durch Anwenden eines regelbasierten Alarmschemas, um festzustellen, ob ein empfangenes Sicherheitsereignis als Verstoß betrachtet wird, wobei das Computerprogrammprodukt aufweist: ein oder mehrere durch einen Computer lesbare, physische Speichermedien und Programmanweisungen, die auf mindestens einem Speichermedium des einen oder der mehreren physischen Speichermedien gespeichert sind, wobei die Programmanweisungen durch einen Prozessor ausführbar sind, wobei die Programmanweisungen aufweisen: Programmanweisungen, um einen Regelindex von Regeln zu erzeugen, wobei die Regeln beim Empfang eines eingehenden Sicherheitsereignisses anzuwenden sind; Programmanweisungen, um einen Indicator-of-Compromise-Index für jede der Regeln zu erzeugen, wobei jeder Eintrag des Indicator-of-Compromise-Index einen Indikatorwert aufweist, der für einen Vergleich mit einem Attribut eines Sicherheitsereignisses zu verwenden ist; Programmanweisungen, um das eingehende Sicherheitsereignis durch sequenzielles Anwenden der Regeln zu verarbeiten; Programmanweisungen, um einen aktuellen Regelzähler in Bezug auf eine ausgelöste Regel zu erhöhen, deren Verarbeitung einen Verstoß ausgelöst hat; Programmanweisungen, um einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler zu erhöhen; Programmanweisungen, um ein Pseudosicherheitsereignis aus empfangenen Daten über bekannte Angriffe und zugehörige Indicators-of-Compromise zu erzeugen; und Programmanweisungen, um die Pseudosicherheitsereignisse durch sequenzielles Anwenden der Regeln zu verarbeiten, wobei das Verarbeiten Programmanweisungen, um einen aktuellen Regelzähler von Pseudosicherheitsereignissen in Bezug auf die ausgelöste Regel zu erhöhen, deren Verarbeitung den Verstoß ausgelöst hat, und Programmanweisungen, um einen aktuellen, die ausgelöste Regel betreffenden Indicator-of-Compromise-Zähler für Pseudosicherheitsereignisse zu erhöhen, aufweist; Programmanweisungen, um die Regeln in dem Regelindex gemäß jeweiligen gewichteten Regelzählerwerten zu sortieren; und Programmanweisungen, um die Indicators-of-Compromise in dem Indicator-of-Compromise-Index gemäß gewichteten Indicator-of-Compromise-Zählerwerten innerhalb einer jeden Regel zu sortieren.