Revisionssicheres Whitelisting für Use Cases in Splunk

Einleitung

Je größer eine Splunk Installation wird, je mehr Use Cases und Alerts z. B. aus Cyber Threat / Cyber Hygiene Analytics oder anderen Bereichen kommen, um so schneller wird deutlich, dass ein revisionssicheres und einfach zu bedienendes Whitelisting Verfahren erforderlich ist. Dieser Artikel beschreibt, wie dieses Erfordernis relativ einfach und vollständig in Splunk umgesetzt werden kann.

Zusammenfassung

Das vorgestellte Whitelisting Verfahren erlaubt mittels zweier Dashboards und dreier Lookup Files die revisionssichere Erstellung, Pflege und Dokumentation von Whitelisting Regeln für Splunk Alerts. Darüber hinaus werden zwei automatisierte Reports für Email Benachrichtigungen eingesetzt. Schließlich muss in jede Splunk Alert Search ein standardisierter Code Abschnitt einkopiert werden, damit die Whitelisting Rules verarbeitet werden.

Funktionalität

    • Dashboard SOC
      • Erfassung neuer Requests
      • Löschung zurückgewiesener Requests

    • Dashboard CTA / CISO RM
      • Annahme oder
      • Rückgabe neuer Requests

      • De-Aktivierung,
      • Re-Aktivierung oder
      • Re-Zertifizierung existierender Rules

    • Lookup Files
      • Use Case Verzeichnis
      • Neue Requests
      • Aktive Rules

    • Automatisierte Reports
      • mit Email Benachrichtigung
        • an CTA / CISO RM für neu erfasste Requests
        • an SOC für zurückgewiesene Requests

      • für BackUp der Lookup Files

    • Code Abschnitt (Exclusion Search) für Berücksichtigung der Whitelisting Rules
      • in jede Use Case Search einzufügen 
      • Einschränkungen der Gültigkeit jeder Regel über
        • konfigurierbare Dauer 
        • standardmäßig durch 5 Kriterien
          • Use Case ID und Application Identifier (fest)
          • 3 Key-Value Paare: Event Fields und Inhalte
            (erweiterbar auf gewünschte Anzahl falls erforderlich)

    • SPL Scripte (nicht automatisiert)
      • zur erstmaligen Generierung der Lookup Files
      • für den Restore der Lookup Files
      • für das Hinzufügen von Use Cases ins Use Case Verzeichnis


Vorteile

      • je nach Güte und Menge der Daten teils erhebliche Reduzierung der Arbeitslast im SOC
      • Reduzierung der Wartungshäufigkeit von Use Cases
      • Standardmäßige Einbindung der Exclusion Search in jede Use Case Neu-Entwicklung rüstet den Use Case automatisch für die Teilnahme am Whitelisting Verfahren

 

Lieferumfang und Preis 

Lieferumfang   In der Lieferung enthalten sind alle unter der obigen Überschrift "Funktionalität" aufgeführten Splunk Objekte enthalten.
Preis   auf Anfrage
Im Preis enthalten sind 2 Tage Aufwand für Implementation des Standards und Schulung der Mitarbeiter.
Anpassungen / Erweiterungen    Abrechnung nach Aufwand oder als Festpreis
Einbindung in Use Cases    Abrechnung nach Aufwand oder als Festpreis

 

Detailierte Beschreibung

Angenommene Ausgangssituation

Eine Gruppe - z. B. Cyber Threat Analytics oder CISO Risk Management - erstellt Use Cases für verschiedene Anwendungsfälle, abgeleitet aus MITRE ATT@CK. Sobald die Alerts ausgelöst werden, entsteht ein neues "notable". Notables werden von einer anderen Gruppe - z. B. dem SOC - abgearbeitet, also analysiert, weitergeleitet oder geschlossen.

Da die Daten in aller Regel nicht so 100%ig "sauber" sind, wie gern gewollt, wird das SOC im Laufe der Zeit immer wieder auf False Positives bzw. auf Ereignisse stoßen, die aufgrund von Daten Qualitätsproblemen nicht tiefer untersucht werden können. Diese Fälle kommen immer wieder vor und die Anzahl wird über die Zeit zunehmen. Hierdurch entstehen direkte Kosten, vor allem aber bindet es Kapazitäten im SOC, die besser für die Analyse "echter" sicherheits-relevanter Ereignisse verwendet werden sollte.

Konsequenz

Diese Situation führt in der Praxis dazu, dass die Alerts durch immer weitere Excludierungen (Wenn-Dann Konstrukte in der Splunk Processing Language SPL, wenn Sie so wollen) erweitert werden. Hierdurch wird der eigentliche Code hässlich und schlechter wartbar. Zusätzlich muss natürlich an anderer Stelle entsprechend dokumentiert werden, was warum von der Suche ausgenommen wurde und eine revisionskonforme regelmäßige Rezertifizierung kann auf dieser Basis nur sehr umständlich erfolgen.

Weiterhin muss für jedwede Änderung (Erweiterung oder Ergänzung der Ausschlüsse, temporäre De-aktivierung und ähnliches) jedes Mal der Code angefasst werden. Auch hierdurch steigt das mögliche Fehlerpotenzial auf die Dauer stark an. 

Um also das CTA Team vor überflüssigen und fehleranfälligen Wartungsarbeiten und das SOC also vor unnützen Analyse Tätigkeiten zu schützen, ist ein leicht bedienbares Whitelisting Verfahren erforderlich, dass es SOC Mitarbeitern erlaubt, Events von zukünftigen Alerts auszuschließen, die einmal als False Positive bzw. Unlösbares Event aufgrund von Datenqualitätsproblemen erkannt wurden.

Das Whitelisting Verfahren

Das hier vorgestellte Whitelisting Verfahren verwendet je zwei Dashboards und LookUp Files. Es ist als funktionsfähige Ausgangsbasis zu verstehen, die jederzeit erweitert und / oder den eigenen Bedürfnissen angepasst werden kann. Darüber hinaus lässt es sich selbstverständlich auch in einem mehr fachlichen Kontext als dem Cyber Security Umfeld einsetzen.

 Splunk_WL_Process_diagram.sml.png
Abb. 1: Der Whitelisting Prozess im Überblick

 

Exclusion Search - Kern des Verfahrens

Aktive und gültige Whitelisting Rules werden vom Kern des Verfahrens, der Exclusion Search, während der Laufzeit interpretiert und ausgeführt. Über Lookups werden die aktiven und gültigen Rules für den spezifischen Use Case ermittelt und die darin enthaltenen Key-Value Paare ("srch_field_x" = "srch_value_x"; siehe Folgeabschnitt) interpretiert und per "SEARCH NOT" Kommando von der Suche nach passenden Events ausgeschlossen.

Eine Whitelisting Regel ist dann gültig, wenn sie aktiv ist, d. h. sie darf nicht de-aktiviert bzw. re-aktiviert aber nicht re-zertifiziert sein und das Gültig-Bis Datum muss mindestens 1 Tag in der Zukunft liegen. Andernfalls wird die Regel überlesen.

 

Erfassung eines neuen Requests durch SOC

Das SOC stellt - außerhalb dieses Verfahrens - bei der Analyse eines Alerts und der zugrunde liegenden Events fest, dass es sich um einen False Positive (oder auch ein Datenqualtitätsproblem) handelt: z. B. haben die zyklischen Netzwerk Scans mithilfe von Nessus wieder einmal den "Brute-Force Login Trial" Alarm ausgelöst. Bei der Analyse ergibt sich schnell, dass dieser fehlerhafte Alarm immer dann ausgelöst wird, wenn eines der Quellsysteme ein Nessus Server ist. In diesem Fall ist das Splunk Event Feld "src_host" z. B. mit Werten der Art "nessus.prod##.ihre_domain.com" (wobei ## einer laufenden Nummer entspricht) gefüllt. 

EMon_WL.SOC.Overview.png
Abb. 2: Whitelisting Dashboard SOC - Überblick und Erfassung oder Bearbeitung neuer Requests

Der SOC Mitarbeiter ruft jetzt das Whitelisting Dashboard für das SOC Team auf (in der Grafik EMon_WL_SOC genannt). Sofort werden alle aktiven (akzeptierten) Whitelisting Rules angezeigt, sowie die noch nicht bearbeiteten neu gestellten Whitelisting Requests. Hier kann geprüft werden, ob bereits ein anderer Mitarbeiter des SOC Teams einen gleichlautenden Whitelisting Request gestellt hat, der nur noch nicht akzeptiert wurde.

Ist das nicht der Fall, wird der neue Request erfasst. Hierzu ist zuerst der Use Case aus einer Liste auszuwählen, für den der Request gelten soll. Bereits durch diese Auswahl werden die beschriebenen Listen Anzeigen bestehender Rules und Requests auf die passenden Einträge reduziert. Erneut kann überprüft werden, ob bereits eine vergleichbare Regel existiert. Anschließend kann eine Applikations-ID (idealerweise mit den CMDB Daten übereinstimmend) eingegeben werden, um eine weitere Einschränkung der Wirkweite der Whitelisting Regel zu erzwingen. Außerdem muss eine Begründung für den neuen Whitelisting Request erfasst werden.

Anschließend wird die auszuschließende Konstellation in den dafür vorgesehenen Feldern erfasst. Diese Felder sind immer paarweise organisiert. Im ersten Feld "srch_field" wird der Name des Splunk Event Fields erfasst und im zweiten Feld "srch_value" der zu suchende Wert. Für obiges Beispiel würden also die folgenden Einträge erfasst:

srch_field_1 = "src_host"
srch_value_1 = "nessus.prod*.ihre_domain.com"

Weitere Felder für die Erfassung von srch_fields und srch_values bleiben leer. Anschließend wird der Request durch Klick auf den Radio Button "submit" mit Namen, User-ID und Datum vervollständigt und  in die Lookup Datei für neue Requests geschrieben. Ein automatischer und regelmäßiger Report findet neu erzeugte Requests und benachrichtigt die festgelegten Personen (z. B. aus dem CTA Team oder aus dem CISO Risk Management) per Email über diese neuen Requests.

Neue Requests (oder solche die von CTA / CISO RM zurückgegeben wurden; Reject) können zur Überarbeitung selektiert werden ("Select" ganz rechts). In der Detailansicht stehen dann alle Felder für eine Überarbeitung zur Verfügung. Wird diese Ansicht mit der "save" Funktion verlassen, werden automatisch die Felder "rejectedBy", "rejectedOn" und "rejectReason" geleert, wodurch dieser Überarbeitete Request erneut in der Ansicht von CTA / CISO RM als neuer Request erscheint.

EMon_WL.SOC.Edit_Details.png
Abb. 3: Detailansicht eines neuen Requests im SOC Dashboard

 

Bearbeitung neuer Requests durch CTA / CISO RM

Die für Whitelisting Request Bearbeitung zuständigen Mitarbeiter (z. B. aus CTA oder CISO RM) öffnen ihr Dashboard (in der Grafik EMon_WL_CTA_RM genannt) und sehen sofort

    • eine Übersicht aller neuen (unbearbeiteten) Requests
    • eine Übersicht aktiver Rules

Für die Bearbeitung neuer Requests stehen Funktionen zum Akzeptieren oder Zurückweisen zur Verfügung. Aktive Regeln können mit den Funktionen "De-Aktivieren", "Re-Aktivieren" oder "Re-Zertifizieren" bearbeitet werden. Für die Zurückweisung kann eine Begründung erfasst werden.

Jede dieser Funktion zeigt das ausgewählte Objekte in der Detail Ansicht mit allen Informationen an. In dieser Ansicht kann dann entweder die gewünschte Aktion ausgeführt oder der Vorgang abgebrochen werden. Im Anschluss wird wieder die Übersicht zusammen mit einer entsprechenden Hinweismeldung angezeigt.

EMon_WL.CTARM.Overview.png
Abb. 4: Whitelisting Dashboard CTA/CISO RM - Überblick und Bearbeitung neuer Requests und existierender Regeln

 

Funktionsweise der möglichen Aktionen

Zurückweisung des neuen Requests

    • vervollständigen der Daten des neuen Requests mit der Begründung der Rückweisung, Namen, User-ID und Datum
    • speichern des aktualisierten Requests im Lookup File für neue Requests

Akzeptieren des neuen Requests

    • Errechnen der Gültigkeit der neuen Regel anhand des Standardwertes für die Gültigkeitsdauer (z. B. 3 Monate, 1 Jahr etc.; konfigurierbar)
    • vervollständigen der Daten des neuen Requests mit Namen, User-ID und Datum
    • speichern als neue Regel im Lookup File für existierende Whitelisting Regeln
    • löschen des Requests im Lookup File für neue Requests

De-Aktivieren einer aktiven Regel

    • Speicherung der De-Aktivierung mit Name, User-ID und Datum im Lookup File für existierende Whitelisting Regeln

Re-Aktivieren einer inaktiven Regel

    • Löschen der ehemaligen Gültigkeit der Regel (Erzwingt sofortige Re-Zertifizierung, damit die Regel wirksam wird)
    • Speicherung der Re-Aktivierung mit Name, User-ID und Datum im Lookup File für existierende Whitelisting Regeln

Re-Zertifizierung einer aktiven Regel

    • Errechnen der Gültigkeit der neuen Regel anhand des eingestellten Wertes für die Gültigkeitsdauer
    • Speicherung der Re-Zertifizierung mit Name, User-ID und Datum im Lookup File für existierende Whitelisting Regeln

 EMon_WL.CTARM.View_Details.png
Abb. 5: Whitelisting Dashboard CTA/CISO RM: Detailansicht einer existierender Regel mit Bearbeitungsoptionen

Hinweis:

Regeln können nicht gelöscht, sondern lediglich de-aktiviert werden. Auf diese Weise bleibt die Information über ehemals aktive Ausschlussregeln erhalten.