Der Elastic Stack als SaaS-basiertes Schweizer Taschenmesser für Ihre Sicherheit

Sicherheit steht bei RS2 immer an erster Stelle. Unser Hauptprodukt, BankWORKS, ist eine umfassende integrierte End-to-End-Lösung rund um die Zahlungsverarbeitung, von der Endgerät-Transaktionserfassung bis hin zur Zahlungserfüllung und Buchführungsintegration. Die Software wird weltweit von kleinen und großen, einfach wie komplex strukturierten Banken, Zahlungsverarbeitern und Zahlungsdienstanbietern eingesetzt. Wir bieten unser Produkt auch als gehosteten verwalteten Dienst an.

Als Team müssen wir in sämtlichen Geschäftsbereichen sicherstellen, dass die Daten nicht gefährdet oder weitergegeben werden. Gleichzeitig müssen wir verschiedene Compliance-Anforderungen erfüllen und dafür sorgen, dass unser alltäglicher Geschäftsbetrieb reibungslos abläuft.

Im November 2017 haben wir beschlossen, unser Sicherheitsteam zu erweitern. Vor dem Antrag auf zusätzliches Personal wollten wir jedoch versuchen, einige der manuellen Prozesse beim Umgang mit Vorfällen und Sicherheitsereignissen zu vereinfachen. An dieser Stelle begann unsere Reise mit dem Elastic Stack.

Die Reise vom Angebot bis zur Produktion

Die Anfänge

Ich hatte den Elastic Stack bereits in anderen Bereichen und für persönliche Projekte eingesetzt und wollte das Produkt dem Team vorstellen. Ich war der Meinung, dass der Funktionsumfang und die Skalierbarkeit des Produkts unseren Anforderungen gewachsen waren.

In den ersten Tagen in meiner neuen Rolle bei RS2 habe ich Elasticsearch- und Kibana-Instanzen (Version 6 in diesem Fall) in einem virtuellen Computer auf meinem Laptop eingerichtet, einige Beats in der VM installiert (packetbeat, auditbeat, metricbeat und filebeat) und sämtliche Daten direkt an Elasticsearch gesendet. Der gesamte Prozess dauerte etwa eine Stunde (davon 40 Minuten für Download und Installation des Betriebssystem-ISOs), und ich hatte Kibana bereits mit aussagekräftigen Daten ausgefüllt.

Ein Kollege stimmte mir nach einer kurzen Vorführung zu, dass wir auf einem guten Weg sind. Wir beschlossen, eine Demo mit echten Daten zu erstellen, um unsere Vorgesetzten von der Effektivität zu überzeugen. Wir haben als Datenbasis einige Netzwerkgeräte und vorhandene Server genommen, für die keine Änderungen an unserem Produktionsnetzwerk erforderlich waren (mit den verschiedenen Beats und Logstash), sowie einige externe Integrationen.

Cloud-Auswertung

In meinen bisherigen Rollen habe ich große Elastic-Bereitstellungen über mehrere Server hinweg gehostet. Ich hatte mich jedoch noch nie mit dem Elastic Cloud-Angebot befasst. RS2 befand sich zu dieser Zeit in einem Infrastruktur-Freeze aufgrund der bevorstehenden Migration in die Cloud. Aus diesem Grund und angesichts knapper Deadlines und Ressourcen habe ich mir Elastic Cloud näher angesehen. Als Sicherheitsexperte war ich zunächst skeptisch. Ich wollte mich vergewissern, dass der Dienst mit ausreichender Sicherheit entwickelt wurde.

Ich habe mein Cluster eingerichtet und einige Sicherheitstests durchgeführt, um besonders offensichtliche Sicherheitslücken oder Schwachstellen aufzudecken. Hier sind meine Erkenntnisse:

• Mit Elastic können Sie zwischen AWS und GCP als Backend-Cloudanbieter wählen und erben somit sämtliche Sicherheitsfunktionen und Compliance-Zertifizierungen.
• Für jedes Cluster werden separate Netzwerke verwendet, nicht die Standardsubnetze der einzelnen Anbieter.
• Die Elasticsearch- und Kibana-URLs verwenden moderne TLS-Einstellungen und Verschlüsselungsmodule.
• Die Elasticsearch-Transportports werden zufällig ausgewählt.
• Die URLs für die einzelnen Instanzen sind ebenfalls komplett zufällig generiert, Kundennamen können also nicht enumeriert werden.
• Direkter IP-Zugriff ist ohne die Cluster-ID nicht möglich.
• Die Lösung verwendet die neueste Version des Elastic Stack sowie eine aktuelle Version von Java 8.

Das Puzzle fügt sich zusammen

Nachdem ich mein Cloud-Cluster eingerichtet hatte, konnte ich die Datenflüsse planen. Das folgende Diagramm zeigt die Architektur für die Machbarkeitsstudie.

Da wir mit X-Pack arbeiten, setzen wir Watcher ausgiebig für das Alerting-Framework ein. Wir haben diese Lösung mit einem eigenen Slackbot und den Watcher Webhook-Aktionen integriert.

Demo-Vorbereitung - Arbeiten mit den Daten

Zunächst wollten wir unsere Logs möglichst umfassend analysieren und anreichern. Die Anreicherung ist im Sicherheitsbereich der Schlüssel zu einer schnellen Behebung von Vorfällen, da Untersuchungen viel schneller abgeschlossen werden. Außerdem werden Falschmeldungen herausgefiltert. Mit verschiedenen Logstash-Filter-Plugins habe ich all dies mühelos erledigt. Um unser vorhandenes Log-Archivierungstool zu berücksichtigen, habe ich außerdem mehrere Logstash-Ausgaben eingerichtet, um Daten gleichzeitig an unser Elastic-Cluster und an das vorhandene Archivierungstool zu senden.

Hier sehen Sie einige der Anreicherungsvorgänge für unsere analysierten Logs:

• GeoIP-Daten (Standort und ASN)
• Suche in Malware-IPs
• Suche nach erlaubten Benutzeranmeldungen
• Analyse der Benutzer-Agents
• URL-Dekodierung

Dies ist eine unvollständige Liste der Anreicherungen für unsere Machbarkeitsstudie. Seit der Umstellung in den Produktionsbetrieb haben wir viele weitere Operationen hinzugefügt.

Nachdem ich die Daten schick aufbereitet hatte, konnte ich individuelle Dashboards parallel zu den integrierten Dashboards erstellen, um die bereits erwähnten Anreicherungsfeatures zu nutzen. Hier sind nur einige Beispiele für die individuellen Kibana-Dashboards, die wir für die Machbarkeitsstudie entwickelt haben (sensible Daten wurden entfernt):

Außerdem habe ich einige elegante Integrationen in die Demonstration eingebaut, um zu zeigen, wie einfach wir Daten zu Elastic hinzufügen können. Letztendlich ist das System nur ein weiterer Index. Ein Beispiel hierfür ist die Integration mit dem beliebten Dienst „Have I been Pwned“ von Troy Hunt. Dieser Dienst bietet eine praktische REST API an, mit der Sie abfragen können, ob eine bestimmte E-Mail-Adresse in veröffentlichten Datenverstößen auftaucht. Wir haben eine Überwachung eingerichtet, um über neue Einträge für unsere Domäne informiert zu werden.

Alerting

Das Alerting-Framework in unserer Machbarkeitsstudie (die später in Produktion eingesetzt wurde) diente hauptsächlich dazu, alle umsetzbaren Daten in Slack zu verarbeiten. Hier sehen Sie einige Beispiele für die bearbeiteten Daten im Slackbot. Hier ist alles enthalten, was Analysten brauchen, um eine Untersuchung zu beginnen. Die verwendeten Daten wurden von unterschiedlichen Beats und den analysierten Logs aus Netzwerkgeräten mit Logstash gesammelt.

Die Datensätze enthielten unter anderem:

• SMTP Relay-Logs, Authentifizierungs-Logs und Paketfilter-Logs aus unseren Firewalls
• DNS-Anfragen auf Paketebene mithilfe von Packetbeat
• SSH/SFTP-Logs mit einer Kombination aus Wazuh und Filebeat
• Eine Liste von Prozessen mit dem jeweiligen Status, mit Metricbeat
• Überwachung ausgehender Netzwerksockets mit Auditbeat auf *nix-Systemen

Hier sind nur einige Beispiele für die individuellen Slackbot-Warnungen, die wir für die Machbarkeitsstudie entwickelt haben (sensible Daten wurden entfernt):

• TeamViewer-Verbindungswarnung
  
  
• Firewall-Anmeldewarnung
  
  
• Malware-Warnung
  
  

Resultat

Selbstverständlich war die Machbarkeitsstudie ein Riesenerfolg, und wir haben die Genehmigung für den Umzug in die Produktionsumgebung erhalten. Hier sind noch einmal die wichtigsten Faktoren für den Erfolg dieser Machbarkeitsstudie:

• Die herausragende Benutzerfreundlichkeit und Geschwindigkeit der Elastic Cloud sowie ihr Funktionsumfang (vorkonfigurierte integrierte Backups, Resilienz und Hochverfügbarkeit, X-Pack im Paket für unsere Bereitstellungsgröße enthalten)
• Die Möglichkeit, Eingangsdaten mühelos in nützliche und umsetzbare Informationen umzuwandeln (die Machbarkeitsstudie war innerhalb von drei Tagen implementiert, inklusive aller in diesem Blogeintrag beschriebenen Aufgaben: Analyse, Dashboards, Anreicherung, Alerting-Framework usw.)
• Die Möglichkeit, das System parallel und ohne Unterbrechung zu allen vorhandenen Prozessen einzurichten

Umgang mit Upgrades

Nach einigen Wochen im Produktionsbetrieb hat Elastic ein Update veröffentlicht. Ich hatte bereits zu vor große Elastic-Bereitstellungen mit X-Pack aktualisiert und war neugierig zu sehen, wie dieser Prozess in der Cloud-Plattform funktioniert. Wir mussten lediglich die neue Version in einem Dropdownmenü auswählen. Der komplette Rest wurde automatisch und ohne Unterbrechungen erledigt.

Fazit

Unsere Reise mit Elastic war damit natürlich noch nicht am Ende. Wir fügen ständig weitere Datenquellen und Anreicherungen hinzu (z. B. Korrelation mit unseren Personalverwaltungssystemen, um Urlaubsdaten abzufragen, oder physische Zugangskontrollsysteme, um herauszufinden, ob sich Personen in den korrekten Gebäuden aufhalten) und erstellen Ad-hoc-Warnungen für neu erkannte Bedrohungen und bösartige Aktivitäten. Außerdem sind wir dabei, verschiedene unserer internen Tools zu integrieren.

Wir freuen uns auf die Zukunft von Security Analytics mit Elastic. Elastic fügt mit jedem Update zusätzliche Komponenten ein, die das Leben von Analysten erleichtern und ihren Alltag erfüllter gestalten. Außerdem freuen wir uns ebenso sehr auf die anstehenden Upgrades für die Elastic Cloud. RS2 wird ohne Zweifel von den umfassenden Features profitieren, nicht nur für Security Analytics, sondern über das gesamte Unternehmen hinweg.