Onboarding von Bedrohungsindikatoren in Splunk Enterprise Security: SolarWinds – Fortsetzung

Während euer Team die Sicherheitsempfehlungen von SolarWinds umsetzt, wollten wir euch zusätzliche Hinweise mitgeben, die euch helfen, Bedrohungsindikatoren zur Abwehr der Sunburst Backdoor-Malware wirkungsvoller in Splunk Enterprise Security (ES) einzubinden. Wenn ihr diese Tipps umgesetzt habt, könnt ihr mit dem Blogbeitrag „Sunburst Backdoor mit Splunk aufspüren“ fortfahren und weitere Maßnahmen ergreifen.

Die bestehende Methode zum Herunterladen von Indikatoren in Splunk Enterprise gibt es schon seit langem, ganz gleich, ob ihr ES 6.4 oder ältere Versionen wie ES 4.5 verwendet. Wir haben hier nun ein paar Tipps und Tricks zusammengestellt, die hoffentlich einige der Stolpersteine beseitigen, die euch in der Vergangenheit vielleicht ausgebremst haben. 

Die Probleme mit Feldern

Die größten Problemstellen beim Einlesen von Bedrohungsindikatoren entstehen durch die Benennung von Feldern. Das Threat Intelligence Framework erwartet, dass ganz bestimmte Header-Feldwerte verwendet werden. Hier findet ihr eine Referenz dazu.

Wenn ich beispielsweise eine Liste mit IP-Adressen einlese, erwartet das Framework, dass das Feld, das die IP-Adresse enthält, den Namen „IP“ trägt – nicht „dest“, „src“, „source_ip“ oder ähnliches, sondern schlicht und einfach „IP“. Analog dazu sucht das Framework Domain-Namen bei dem Feld „domain“. Hier seht ihr ein Beispiel aus dem oben angegebenen Link.

Zur Verdeutlichung verwenden wir beispielhaft das GitHub-Repository für die Sunburst-Backdoor, das Shannon Davis erstellt hat. Zuerst habe ich zwei Intelligence-Downloads namens SunburstDomain und SunburstIP erstellt. Darin habe ich den Typ, die Beschreibung und die URL konfiguriert, von der die Informationen abgerufen werden.

Wenn ich auf die Downloads klicke und nach unten scrolle, sehe ich Parsing-Optionen. Wie ihr seht, wird für Fields in der ersten Spalte der CSV-Datei nach Werten gesucht, die in das Feld „ip“ eingetragen werden, und die Spalte „description“ wird mit der Konstanten „SunburstIPListing“ ausgefüllt.

Analog dazu befinden sich bei unserem Domain-Download die Domain-Werte an erster Stelle in der Liste, weshalb wir mit $1 angeben, wo gesucht werden soll. Auch hier verwenden wir wieder eine Konstante als Beschreibung für die Liste. Dieses Mal ignoriere ich, dass ich den unterstützten Typ von Bedrohungsinformationen verwenden sollte, und nenne mein erstes Feld nicht „domain“, sondern „url_domain“.

Der Threat Intelligence-Download wird zwar gespeichert und die Datei lässt sich auch herunterladen, ich muss jedoch leider feststellen, dass diese Domains nicht in meine Lookups eingetragen werden. Was kann ich tun, um dieses Problem zu beheben?

Die gute Nachricht ist, dass es verschiedene Stellen gibt, die bei der Suche nach der Lösung überprüft werden können.

Tipps und Tricks

Als erstes stellt ihr sicher, dass die Intelligence-Downloads aktiviert sind.

Danach kontrolliert ihr, ob die Datei heruntergeladen wurde. Dazu navigiert ihr in Enterprise Security zu „Audit – Threat Intelligence Audit“. Unter „download_status“ sollte angegeben sein, dass die Bedrohungsliste heruntergeladen wurde. Ist dies nicht der Fall, ist wahrscheinlich die URL nicht korrekt.

Für Skeptiker wie mich ist es auch gut zu wissen, wohin die Dateien mit den Bedrohungsinformationen heruntergeladen wurden. Wechselt über die Befehlszeile zum Verzeichnis $SPLUNK_HOME/etc/apps/SA-ThreatIntelligence/local/data/threat_intel/. Wenn die Dateien erfolgreich heruntergeladen wurden, können die beiden Dateien SunburstDomain und SunburstIP im Dateisystem angezeigt werden. Die Benennungsregeln der Dateien basieren auf den in den Intelligence-Downloads angegebenen Namen.

Ich weiß jetzt, dass die Dateien vorhanden sind. Doch wie kann ich feststellen, ob sie geparst und in Lookups geladen werden?

In der unteren Hälfte des Dashboards „Threat Intelligence Audit“ findet ihr alle Auditlogs im Zusammenhang mit dem Parsen und Laden der Bedrohungsinformationen. Es empfiehlt sich also durchaus, hier nachzusehen. Allerdings ist das Dashboard auf die letzten 1000 Events beschränkt. Wenn ich mich also auf meine beiden Downloads konzentrieren möchte, ist es eine gute Idee, das Dashboard zu öffnen und dann meine eigenen Dateinamen hinzuzufügen.

eventtype=threatintel_internal_logs (SunburstIP.csv OR SunburstDomain.csv)

Wenn ich mir diese beiden Events näher ansehe, möchte ich betonen, wie erhebend ein Sieg bzw. niederschmetternd eine Niederlage ist (ihr kennt bestimmt auch diese Fernsehsendungen, die sich den schönsten Siegen bzw. den schmerzhaftesten Niederlagen im Sport widmen). Das zweite Event in der folgenden Abbildung zeigt, dass die IP-Adressen in die Collection geschrieben wurden. IP-Adressen werden also geladen!!!

Das erste Ereignis löst einen Fehler aus. Dies liegt daran, dass ich „url_domain“ statt „domain“ als Feldnamen verwendet habe, was bei der Verarbeitung der Datei zu einem Ausnahmefehler führt. Das Framework weiß nicht, was es mit den heruntergeladenen Daten tun soll, weshalb es einen Fehler zurückgibt und mit anderen Dingen fortfährt. Danach solltet ihr bei Events auf jeden Fall suchen, und wenn dieser Fehler auftritt, überprüft ihr die Parsing-Optionen, um sicherzustellen, dass die verwendeten Feldnamen von ES definiert sind.

Nach den domainbezogenen Indikatoren möchte ich mich nun der IP-Adresse widmen. Es gibt hier ein paar Zwischenschritte, mit denen ich euch aber nicht langweilen möchte – in der Präsentation „Enterprise Security Biology“ von der .conf2017 wird all das ausführlich behandelt. Wir möchten jetzt jedoch erreichen, dass Daten in den KVStore in die verschiedenen Bedrohungserfassungen geladen werden, und zwar abhängig vom Indikatortyp.

| inputlookup ip_intel | search description=SunburstIPListing

In diesem Fall kann ich die Tabelle ip_intel durchsuchen, um festzustellen, ob die Indikatoren geladen wurden. Da ich mich auf die Liste SunburstIPListing konzentrieren möchte (das war die Beschreibung, die ich zu den Parsing-Optionen hinzugefügt habe), kann ich | search verwenden, um meine Ergebnisse auf genau diese Liste einzugrenzen.

An diesem Punkt übernimmt dann das Threat Intelligence-Framework: Es wird laufend eine Reihe gespeicherter Suchvorgänge ausgeführt, um Events mit den verschiedenen Bedrohungserfassungen zu korrelieren und die Daten in das threat_activity-Datenmodell zu schreiben. Die Korrelationssuche wird dann regelmäßig ausgeführt, extrahiert dabei die neuen Einträge aus dem Datenmodell und erstellt auffällige Events daraus.

Ich hoffe, dieser Blog war hilfreich für euch und trägt dazu bei, dass ihr das Onboarding dieser Bedrohungsindikatoren in eure Instanz von Splunk Enterprise Security optimieren könnt.

^{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Onboarding Threat Indicators into Splunk Enterprise Security: SolarWinds Continued.}