Warnmeldungen: Best Practices

Document created by RSA Information Design and Development on Apr 17, 2018
Version 1Show Document
  • View in full screen mode
 

In den Best Practices finden Sie Guidelines zum Schreiben, Verwalten und Bereitstellen von Regeln sowie zur Bewahrung der Systemintegrität für die ESA-Services.

Grundlegendes zu Event Stream Analysis-Regeltypen

Der Event Stream Analysis-Service bietet erweiterte Streamanalysen wie Korrelation und komplexe Ereignisverarbeitung mit hohen Durchsätzen und niedriger Latenz. Er ist in der Lage, große Mengen verteilter Ereignisdaten aus den Concentrators zu verarbeiten. Damit Sie effektive Regeln erstellen, sollten Sie bei der Arbeit mit Event Stream Analysis die Faktoren berücksichtigen, die sich auf den Ressourcenverbrauch auswirken. 

Jedes von ESA empfangene Ereignis wird bewertet, um festzustellen, ob es möglicherweise eine Regel auslöst. Drei Typen von Regeln können bereitgestellt werden, um zu bestimmen, wie die ESA-Engine mit dem eingehenden Ereignis verfährt. Diese Regeltypen wirken sich jeweils unterschiedlich auf die Systemressourcenauslastung aus. Alle drei Regeltypen können über die Regelerstellung oder erweiterte EPL-Regeln erstellt bzw. über RSA Live heruntergeladen werden. Die Tabelle unten enthält die Regeltypen und deren mögliche Auswirkungen auf die Systemressourcen.

                       
RegeltypBeschreibung

Einfache Filterregel

Diese Regel steht nicht in Beziehung zu anderen Ereignissen. Zum Zeitpunkt der Aufnahme wird diese Regel anhand einer Reihe von Bedingungen bewertet. Wenn diese Bedingungen zutreffen, wird eine Warnmeldung erzeugt. Wenn keine Bedingungen zutreffen, wird das Ereignis schnell von der Engine freigegeben, um Arbeitsspeicher zur Verfügung zu stellen. Diese Regeln beanspruchen keinen Speicher, da die Ereignisse nicht über die Erstbewertung hinaus beibehalten werden. Die Bereitstellung von weiteren einfachen Filterregeln führt nicht zu einem Anstieg der Nutzung von Arbeitsspeicherressourcen. Wenn die Filterbedingung allerdings zu allgemein ist, können zu viele Warnmeldungen erzeugt werden. Die Systemressourcen werden dann durch das Speichern und Abrufen dieser Warnmeldungen belastet.
Beispiel: Sie können eine Regel schreiben, durch die eine Warnmeldung erzeugt wird, wenn HTTP-Netzwerkaktivitäten über einen Port eingehen, der kein Standard-HTTP-Port ist.

Ereignisfensterregel

Diese Regel bewertet eine Reihe von Ereignissen über einen Zeitraum im Hinblick auf bestimmte Bedingungen. Zum Zeitpunkt der Aufnahme wird diese Regel anhand einer Reihe von Bedingungen bewertet. Treffen diese Bedingungen zu, verbleibt das Ereignis für eine festgelegte Dauer im Speicher. Nach Ablauf der angegebenen Zeit werden die Ereignisse aus dem Zeitfenster entfernt, wenn die Anzahl der erfassten Ereignisse nicht den Schwellenwert erreicht, um eine Warnmeldung auszulösen. Der Arbeitsspeicherverbrauch solcher Regeln hängt stark von der Ereigniseingangsrate (Datenverkehr) ab, der Menge von Daten pro Ereignis und der im Ereignisfenster festgelegten Zeitdauer. Jedes zutreffende Ereignis wird im Arbeitsspeicher behalten, bis das Zeitfenster vergangen ist. Je länger das Zeitfenster dauert, desto größer ist die Menge der Daten. Beispiel: Sie können eine Regel schreiben, die eine Warnmeldung erzeugt, wenn ein Benutzer sich nicht in einem Zeitrahmen von zehn Minuten fünfmal an einem System anmeldet.

Gefolgt-von-Regel

Diese Regel bewertet eine Kette von eingehenden Ereignissen, um zu bestimmen, ob die Reihenfolge von Ereignissen einer festgelegten Bedingung entspricht. Zum Zeitpunkt der Aufnahme wird diese Regel anhand einer Reihe von Bedingungen bewertet. Treffen die Bedingungen zu, findet eine von zwei Aktionen statt:

  • Ist dies das erste Ereignis der Sequenz, wird ein neuer Ereignis-Thread gestartet und das Ereignis als Kopf der Sequenz beibehalten.
  • Gehört das Ereignis zu einem vorhandenen Ereignis-Thread, wird es dieser Sequenz hinzugefügt.

In beiden Fällen verbleibt das Ereignis im Arbeitsspeicher. Der Umfang der Ressourcennutzung hängt bei diesem Regeltyp besonders von der Kundenumgebung ab. Wenn die Filterbedingung viele Ereignis-Threads erzeugt, werden für jeden neuen Thread Ressourcen verbraucht (zusätzlich zum Ereignis). Wenn zudem der Ereignis-Thread nie das Ende erreicht (also keine Warnmeldung erzeugt wird), wird das gesamte Ereignis auf unbestimmte Zeit im Arbeitsspeicher gespeichert.  Beispiel: Sie könnten eine Regel schreiben, die eine Warnmeldung erzeugt, wenn die Anmeldung eines Benutzers an einem Server fehlschlägt, der Benutzer sich dann erfolgreich anmeldet und anschließend ein neues Konto erstellt.

 

Zusätzlich zur oben erörterten Speichernutzung verbraucht die Erzeugung von Warnmeldungen Systemressourcen. Jede erzeugte Warnmeldung muss zum Abrufen gespeichert und zudem von NetWitness Respond verarbeitet werden. Dieser Prozess verwendet Speicherplatz auf dem Datenträger zum Speichern, nutzt Datenbankspeicher und erhöht die CPU-Auslastung durch Ausführung von Abfragen. 

Berücksichtigen Sie beim Schreiben und Bereitstellen von Regeln, dass jede dieser Aktionen sich zulasten der Systemressourcen auswirkt. Anhand der Anleitungen in den folgenden Abschnitten können Sie den Verbrauch auf einem ordnungsgemäßen Niveau halten und mögliche Probleme im Falle von Systemüberlastungen entdecken. 

Best Practices für das Schreiben von Regeln

Hierbei handelt es sich um allgemeine Richtlinien für das Schreiben von Regeln.

  • Warnmeldungen für Ereignisse mit ausführbaren Aktionen erstellen. Der Zweck einer Warnmeldung ist, Sie auf ein Ereignis hinzuweisen, das sofort bestimmte Aktionen erfordert. Für Ereignisse, die keine Aktion erfordern oder über die Sie nur informiert sein müssen, können Sie einen Bericht erstellen.
  • Neue Regeln als Testregeln konfigurieren, um ihre Ausführung in der Umgebung zu beobachten. Wenn Sie neue Regeln als Testregeln bereitstellen, werden sie bei einer Überschreitung des konfigurierten Schwellenwerts für den Arbeitsspeicher deaktiviert. Im Falle der Deaktivierung einer Testregel können Sie auch mithilfe der Snapshot-Funktion für den Arbeitsspeicher sehen, wie viel Speicher verwendet wurde. Weitere Informationen finden Sie unter Verwenden von Testregeln.
  • Erstellen von Warnmeldungsbenachrichtigungen erst, nachdem die Regel getestet und optimiert wurde. Auf diese Weise stellen Sie sicher, dass Sie nicht übermäßig viele Warnmeldungen erhalten, falls eine Regel sich anders als erwartet verhält. 
  • Regeln müssen spezifisch sein, damit Sie die Ressourcennutzung beschränken können. Beschränken Sie die Nutzung mithilfe der folgenden Guidelines:
    • Schließen Sie mit den Filtern der Regel alle bis auf die erforderlichen Ereignisse aus, um die Regel korrekt auszulösen.
    • Definieren Sie die Fenster (Zeitfenster für die Korrelation) so kurz wie möglich.
    • Begrenzen Sie die Ereignisse, die Sie dem Fenster hinzufügen. Wenn Sie zum Beispiel nur IDS-Ereignisse anzeigen möchten, fügen Sie dem Zeitfenster nur solche Ereignisse hinzu. 
  • Regeln müssen für eine verwaltbare Menge von Warnmeldungen optimiert werden. Wenn Sie übermäßig viele Warnmeldungen erhalten, geht deren Zweck und Nutzen verloren. Beispiel: Sie möchten Informationen über verschlüsselten Datenverkehr in andere Länder erhalten. Möglicherweise können Sie aber die Liste auf die Länder eingrenzen, die ein bekanntes Risiko darstellen. Sie beschränken dadurch die Warnmeldungen auf eine Menge, die Sie verwalten können.

Best Practices zur Verwendung von RSA Live-Regeln

Hierbei handelt es sich um Richtlinien für die RSA Live-Regeln.

  • RSA Live-Regeln in kleinen Batches bereitstellen: Nicht jede Regel ist für jede Umgebung geeignet. Stellen Sie Ihre RSA Live-Regeln in kleinen Batches bereit, damit Sie sie in Ihrer Umgebung testen können. Dies ist die beste Methode, um sicherzustellen, dass die RSA Live-Regeln erfolgreich funktionieren. Durch die Bereitstellung in kleinen Batches können Sie viel einfacher feststellen, ob eine bestimmte Regel einen Fehler aufweist. 
  • Die entsprechenden Beschreibungen der RSA Live-Regeln beachten: ESA-Regeln passen nicht allgemein. Es werden nicht alle Regeln in Ihrer Umgebung funktionieren. In den Regelbeschreibungen erfahren Sie, welche Parameter geändert werden müssen, um eine Regel in der Umgebung erfolgreich bereitzustellen.
  • Eigene Parameter festlegen:  RSA Live-Regeln haben Parameter, die geändert werden müssen. Wenn Sie die Parameter unverändert beibehalten, funktioniert die Regel vielleicht nicht oder verbraucht zu viel Speicher.
  • Neue Regeln als Testregeln bereitstellen, damit Sie ihre Auswirkung in der Umgebung beobachten können: Wenn Sie neue Regeln als Testregeln bereitstellen, werden sie bei einer Überschreitung des konfigurierten Schwellenwerts für den Arbeitsspeicher deaktiviert. Weitere Informationen finden Sie unter Verwenden von Testregeln.

Best Practices für die Bereitstellung von Regeln

Hierbei handelt es sich um allgemeine Richtlinien für die Bereitstellung von Regeln.

  • Neue Regeln in kleinen Batches bereitstellen, damit Sie ihre Auswirkung in der Umgebung beobachten können: Umgebungen sind unterschiedlich. Regeln müssen daher unter Berücksichtigung der Speichernutzung, der Menge an Warnmeldungen und der effektiven Erkennung von Ereignissen optimiert werden.
  • Regeln vor dem Konfigurieren von Warnmeldungsbenachrichtigungen testen: Erstellen Sie Warnmeldungsbenachrichtigungen erst, nachdem die Regel getestet und optimiert wurde. Auf diese Weise stellen Sie sicher, dass Sie nicht übermäßig viele Warnmeldungen erhalten, falls eine Regel sich anders als erwartet verhält.
  • Systemintegrität während des Bereitstellungsprozesses überwachen: Überwachen Sie bei der Bereitstellung von Regeln als Teil des Prozesses die Systemintegrität. Die Gesamtspeicherauslastung für ESA können Sie auf der Registerkarte „Integrität und Zustand“ prüfen. Weitere Informationen finden Sie unter „Anzeigen von Statistiken zu Integrität und Zustand“ in Troubleshooting für ESA.

Best Practices für die Systemintegrität

Hierbei handelt es sich um allgemeine Richtlinien für die Systemintegrität.

  • Neue Regeln als Testregeln definieren: Durch neue Regeln verursachte Speicherprobleme sind weit verbreitet. Legen Sie neue Regeln als Testregeln fest, um dieses Problem zu vermeiden. Bei einer Überschreitung des konfigurierten Schwellenwerts für den Arbeitsspeicher werden alle Testregeln deaktiviert, damit das System weiter über ausreichenden Speicher verfügt.  Weitere Informationen zu Testregeln finden Sie unter Verwenden von Testregeln.
  • Schwellenwerte im Modul "Integrität und Zustand" festlegen, um eine Warnmeldung bei zu hoher Speicherauslastung zu erhalten: Das Modul „Integrität und Zustand“ enthält Metriken zur Nachverfolgung der Speicherauslastung. Sie können für die Warnmeldungen und Benachrichtigungen festlegen, dass Sie eine E-Mail erhalten, wenn die Schwellenwerte überschritten werden.  Weitere Informationen zu den anzeigbaren Speicherstatistiken finden Sie unter „Anzeigen von Statistiken zu Integrität und Zustand“ in Troubleshooting für ESA
  • Überwachen Sie für jede Regel im Modul „Integrität und Zustand“ die Speicherkennzahlen. Sie können für jede aktive Regel im Modul „Integrität und Zustand“ den geschätzten Speicherverbrauch anzeigen lassen. Sie können diese Informationen verwenden, um sicherzustellen, dass Regeln nicht zu viel Speicher verbrauchen. Weitere Informationen zu den anzeigbaren Speicherstatistiken erhalten Sie unter „Anzeigen von Statistiken zu Integrität und Zustand“ in Troubleshooting für ESA
Previous Topic:Erste Schritte mit ESA
You are here
Table of Contents > Erste Schritte mit ESA > Best Practices

Attachments

    Outcomes