Hallo ihr Sicherheitsexperten,
die moderne IT-Welt ist komplex und hält einige Herausforderungen für Security Operations-Teams bereit. Es werden heute mehr Apps integriert und miteinander vernetzt als je zuvor. Cloud-Services und SaaS-Lösungen, die an verschiedenen Stellen im Unternehmen ohne Beteiligung der IT-Abteilung eingekauft werden, erhöhen die Komplexität zusätzlich.
Die SOC-Preisfrage lautet: Was muss unbedingt zuerst mit Monitoring-Tools überwacht werden und warum?
Es kann eine gewaltige Aufgabe sein, sämtlichen Eigentümern von Anwendungen und Diensten mitzuteilen, welche Art von Aktivitäten protokolliert und an das SOC gesendet werden müssen. Darüber hinaus lässt sich oft nur schwer sagen, welche Benachrichtigung es wert ist, vom SOC manuell überprüft zu werden.
Die Datenschutzbehörde des Vereinigten Königreichs, ICO (Information Commissioner Office), hat jetzt klar gemacht, dass man diese Aufgabe strategisch angehen und absolut ernst nehmen sollte!
Vor einiger Zeit habe ich einen Blog-Artikel über den SIEM-Prozess und die Schritte geschrieben, die beim Ausarbeiten einer erfolgreichen Roadmap zu priorisieren sind. Bei diesem Artikel habe ich mich für einen Top-Down-Ansatz entschieden. Meiner Meinung nach hat diese Methodik auch weiterhin absolut ihre Berechtigung, ganz gleich, ob ihr sie auf Information Governance oder eure SIEM Use Cases anwendet. Eine Alternative könnte die Implementierung von MITRE ATT&CK und die Umsetzung bekannter Taktiken und Techniken zur Feststellung von Monitoring-Zielen sein. Leider erhält man bei diesem Ansatz mit MITRE ATT&CK keine Antwort auf die Frage, was zuerst durch Monitoring überwacht werden soll. Ihr müsstet diese Entscheidung also selbst treffen und könntet auch nicht den gesamten Abdeckungsbereich von MITRE ATT&CK überwachen.
In diesem Blog-Post möchte ich euch die wichtigsten Lehren vorstellen, die wir aus einem der aktuellsten Sicherheitsverstöße ziehen sollten (Stand November 2020). British Airways (BA) geriet in die Schlagzeilen, da das Unternehmen gehackt und Kundendaten gestohlen wurden. Es gab Spekulationen hinsichtlich der genauen Geschehnisse und ihrer möglichen Ursachen.
Warum Leute im Bereich Cyber Security über die Strafbescheide des britischen ICO Bescheid wissen sollten
Der Strafbescheid des britischen ICO für British Airways wurde erst vor kurzem veröffentlicht. Der Bericht enthält viele wertvolle Details, aus denen Fachleute für Informationssicherheit viel lernen können.
Bußgeldbescheid – nicht nur für Experten
Wenn man aus erster Hand von einer unabhängigen Quelle erfahren kann, wie ein Angriffs- und Einbruchsszenario aussieht, ist dies nicht nur für Cyber-Security-Fachleute von Vorteil, sondern auch für das Informationssicherheitsmanagement wertvoll. Der Bericht zum Strafbescheid verdeutlicht, warum bestimmte Sicherheitskontrollen als angemessen betrachtet werden und warum es notwendig ist, über einen angemessenen Incident Response-Plan und entsprechende Prozesse zu verfügen, wie etwa die Benachrichtigung der Rechtsabteilung und Teams für die Krisenkommunikation. Diese Schritte waren auch Thema unseres Webinars „A Day in the Life of a GDPR Breach“. Bei der Vorbereitung auf dieses Webinar habe ich als Informationssicherheitsexperte eine ganze Menge gelernt. Die Arbeit mit dem Datenschutzbeauftragten hier bei Splunk hat mir dabei gezeigt, dass ein EU-DSGVO-Verstoß weit über die IT hinausgeht.
Ab Seite 17 liest sich das ICO-Dokument wie ein konstruiertes Beispiel, obwohl die Grundlage des Papiers ja ein echter Fall ist, der vom ICO untersucht und bestätigt wurde.
FAKTEN – der Angriff
Schritt 1: Erstzugriff (Initial Access)
Der Angreifer kompromittierte fünf Benutzerkonten, die dem Drittanbieter „Swissport“ zugeordnet waren. Das Benutzerkonto, das für die Anmeldung genutzt wurde, gehörte einem Swissport-Mitarbeiter mit Sitz in Trinidad und Tobago. Der Angreifer konnte sich mit diesen Zugangsdaten bei einer Citrix-Session anmelden.
Schritt 2: Ausbruch aus Citrix
Dem Angreifer gelang es, externe Tools zum Ausspähen des Netzwerks in die Citrix-Session einzuschleusen und sie zu starten, indem er die Benutzerzugangsdaten und spezielle, nicht näher definierte Techniken nutzte.
Schritt 3: Rechteausweitung (Privilege Escalation)
Beim Ausspähen erlangte der Angreifer Zugriff auf eine Datei, die den Benutzernamen und das Kennwort für ein Domänenadministratorkonto mit privilegiertem Zugriff enthielt. Diese Angaben waren in einer Textdatei auf einem Server gespeichert.
Die Schritte 4 bis 6 sind im Bericht ausgeblendet
Diese Schritte sind im Bericht zwar ausgeblendet, doch Cybersicherheitsexperten würden hier von „Seitwärtsbewegung & Sammeln“ (Lateral Movement & Collection) sprechen. Der Angreifer konnte den Benutzernamen und das Kennwort eines Datenbanksystem-Administrators herausfinden.
Schritt 7: Verletzung des Schutzes personenbezogener Daten (Personal Data Breach); XML-Datei
Bei der Seitwärtsbewegung bzw. dem Sammeln fand der Angreifer einen Server mit Logdateien einer Anwendung, die für BA-Rückerstattungen verwendet wurde. Unglücklicherweise war aufgrund eines menschlichen Fehlers eine Testfunktion aktiviert, die im Produktionssystem nicht verwendet werden sollte. Durch diesen Fehler konnte die Anwendung Zahlungskartendetails unverschlüsselt für eine Aufbewahrungsfrist von 95 Tagen in das Debugging-Protokoll schreiben. Diese unnötige Protokollierung war seit Dezember 2015 aktiv und unbemerkt. Der Angreifer hatte in dieser Zeit möglicherweise Zugang zu den Daten von etwa 108.000 Zahlungskarten.
Schritt 8: Verletzung des Schutzes personenbezogener Daten (Personal Data Breach); Zahlungskartendaten
Durch weitere Lateral Movement & Collection-Aktivitäten fand der Angreifer Dateien, die Code für die BA-Website enthielten. Der Angreifer leitete die Zahlungskartendaten von Kunden für einen Zeitraum von 15 Tagen auf eine andere Website um. Die dafür eingesetzten Techniken wurden nicht offengelegt.
Entdeckung und Meldung des Sicherheitsverstoßes
- Innerhalb von 90 Minuten nach der Benachrichtigung durch Dritte hatte BA den bösartigen Code gesperrt und die Schwachstelle eingedämmt. Nach weiteren 20 Minuten waren alle URL-Pfade blockiert, die von BA-Netzen zu der böswilligen Seite umleiteten.
- Am nächsten Tag wurden der Information Commissioner, Acquirer-Banken, Zahlungssysteme und fast eine halbe Million betroffener Kunden über die Sicherheitsverletzung informiert.
Fehler: Vorbeugende Maßnahmen
Laut ICO hätte eine Multi-Faktor-Authentifizierung den Schutz vor der Übernahme eines Benutzerkontos erhöht, doch der Commissioner fügt noch einige weitere interessante Vorschläge und Hinweise hinzu. Es wird auf mehrere Citrix-Anleitungen für die Sicherheitsoptimierung verwiesen sowie auf Sicherheitsleitfäden des ICO und Bedrohungsberichte von Mandiant und Citrix zu Angriffstechniken in Bezug auf Jailbreaking und Virtualisierung bei Sicherheitsproblemen. Dies zeigt, wie wichtig es in der heutigen Welt für Cyber-Security-Manager und -Experten ist, systematische Security-Berichte zu verfolgen und zu lesen, da dies schlicht zu den Aufgaben in ihrem Verantwortungsbereich zählt.
Fehler: Erkennungsmaßnahmen
Wenn man den Ablauf des Angriffs kennt, wird klar, was durch Monitoring überwacht werden sollte. Das ICO weist speziell auf mehrere Best Practice-Abhandlungen für die Protokollierung hin, wie etwa das Dokument NCSC - Introduction Logging for Security Purposes des National Cyber Security Center. Die folgende Liste enthält einige wichtige Punkte, die BA durch besseres Monitoring und Prüfen von Benachrichtigungen abdecken hätte können, um den Verstoß frühzeitig zu entdecken:
- Monitoring nicht autorisierter bzw. neuer Nutzung von Anwendungen innerhalb einer Citrix-Umgebung
- Monitoring und Protokollierung des Zugriffs auf relevante Daten, die hartcodierte Zugangsdaten enthalten
- Monitoring der Erstellung und Aktivierung von Gastkonten
- Monitoring administrativer Aktivitäten, wenn ein Benutzerkonto zu einer lokalen Admin-Gruppe hinzugefügt wird
- Monitoring fehlgeschlagener Anmeldeversuche beim Systemadministratorkonto
- Die Nutzung privilegierter Konten sollte überwacht und geprüft werden.
- Monitoring nicht autorisierter Änderungen am Website-Code in Produktionssystemen
Könnt ihr für jede Netzwerk-Appliance, jedes Betriebssystem, jede Datenbank, jede Geschäftsanwendung und jede Office-Anwendung die folgenden Punkte als zutreffend abhaken?
- Diese Arten von Events werden protokolliert (die richtige Protokollierungsstufe ist konfiguriert),
- sie werden zentral gespeichert,
- sie führen zu einer Warnung oder sind Teil eurer Benachrichtigungs-Pipeline/Priorisierungskette, um rechtzeitig geprüft zu werden.
Seht euch unsere Security Essentials-App an – sie deckt alle diese Use Cases ab! Splunk Enterprise Security ist genau das, was ihr braucht, wenn ihr diese Use Cases operationalisieren, Benachrichtigungen priorisieren und Workflows erstellen möchtet.
Ein Wort zur Cloud
Ihr glaubt, dass all dies für euch nicht relevant ist, da ihr sämtliche Daten in der Cloud verwaltet? Außerdem nutzt ihr verwaltete Kubernetes-Services und Microservices? Dann ersetzt den Begriff „Benutzerkonten“ einfach durch „API-Schlüssel“. Verwendete Schlüssel, neu erstellte Schlüssel, neue Berechtigungen, die zu vorhandenen Schlüsseln hinzugefügt werden usw.
Informationssicherheitsmanagement ist keine Zauberei und auch kein Buch mit sieben Siegeln mehr. Ich hoffe, dass euch diese Hinweise und Erkenntnisse helfen, euer Sicherheitsprogramm zu optimieren!
Schöne Grüße,
Matthias
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: 7 High-Risk Events to Monitor Under GDPR: Lessons Learned from the ICO’s BA Penalty Notice.
