Ein Loch als Sicherheitsinstrument – 2, oder wie man APT «auf den Köder» fängt

(Danke für die Idee des Titels, Sergey G. Brester) sebres)

Kollegen, das Ziel dieses Artikels ist es, Erfahrungen aus einem Jahr Testbetrieb einer neuen Klasse von IDS-Lösungen auf Basis von Deception-Technologien zu teilen.

Um die logische Kohärenz der Darstellung zu wahren, halte ich es für notwendig, mit den Voraussetzungen zu beginnen. Also, das Problembewusstsein:

1. Gezielte Angriffe sind die gefährlichste Art von Angriffen, obwohl ihr Anteil an der Gesamtanzahl der Bedrohungen relativ gering ist.
2. Es gibt noch kein garantiert effektives Mittel zum Schutz des Perimeters (oder einen Komplex solcher Mittel).
3. In der Regel verlaufen gezielte Angriffe in mehreren Phasen. Das Überwinden des Perimeters ist nur eine der Anfangsphasen, die (werfen Sie mir Steine, wenn Sie wollen) nicht viel Schaden für das 'Opfer' anrichtet, es sei denn, es handelt sich um DEoS-Angriffe (Destruction of Service) (Ransomware usw.). Der wirkliche 'Schmerz' beginnt später, wenn die erbeuteten Ressourcen für das Pivoting und die vertiefte Entwicklung des Angriffs genutzt werden und wir das nicht bemerken.
4. Da wir echte Verluste erst erleiden, wenn die Angreifer tatsächlich ihre Angriffsziel erreichen (Anwendungsserver, Datenbanken, Datenspeicher, Repositories, Elemente der kritischen Infrastruktur), ist es logisch, dass eine der Aufgaben des Sicherheitsdienstes darin besteht, Angriffe vor diesem tragischen Ereignis zu unterbrechen. Aber um etwas zu unterbrechen, muss man zuerst davon wissen. Und je früher – desto besser.
5. Daher ist es entscheidend für ein erfolgreiches Risikomanagement (also die Minderung von Verlusten aus gezielten Angriffen), über Werkzeuge zu verfügen, die eine minimale TTD (time to detect – Zeit vom Eindringen bis zur Entdeckung des Angriffs) gewährleisten. Je nach Branche und Region beträgt dieser Zeitraum im Durchschnitt 99 Tage in den USA, 106 Tage in der EMEA-Region, 172 Tage in der APAC-Region (M-Trends 2017, A View From the Front Lines, Mandiant).
6. Was bietet der Markt?
   • „Sandkästen“. Eine weitere präventive Maßnahme, die weit von der Idealvorstellung entfernt ist. Es gibt zahlreiche effektive Techniken, um Sandkästen oder Whitelisting-Lösungen zu entdecken und zu umgehen. Die Leute von der „dunklen Seite“ sind hier bisher einen Schritt voraus.
   • UEBA (Verhaltensprofilierung und Abweichungserkennungssysteme) kann theoretisch sehr effektiv sein. Aber meiner Meinung nach ist das etwas, das in ferner Zukunft liegen wird. In der Praxis ist es derzeit sehr teuer, unzuverlässig und erfordert eine reife und stabile IT- und Sicherheitsinfrastruktur, in der bereits alle Werkzeuge vorhanden sind, die Daten für die Verhaltensanalyse generieren.
   • SIEM ist ein gutes Werkzeug für Untersuchungen, aber es ist nicht in der Lage, etwas Neues, Originelles rechtzeitig zu erkennen und anzuzeigen, weil die Korrelationsregeln dieselben Signaturen sind.

7. Daher besteht die Notwendigkeit für ein solches Werkzeug, das:
   • unter Bedingungen eines bereits kompromittierten Perimeters erfolgreich arbeitet,
   • erfolgreiche Angriffe in nahezu Echtzeit entdeckt, unabhängig von den verwendeten Werkzeugen und Schwachstellen,
   • nicht von Signaturen/Regeln/Szenarien/Politiken/Profilen und anderen statischen Dingen abhängt,
   • keine großen Datenmengen und ihre Quellen für die Analyse benötigt,
   • Angriffe nicht als eine Art Risiko-Scoring infolge der Arbeit einer "weltbesten, patentierten und daher geschützten Mathematik" definiert, die zusätzliche Untersuchungen erfordert, sondern praktisch als binäres Ereignis – "Ja, wir werden angegriffen" oder "Nein, alles ist in Ordnung",
   • universell ist, effektiv skalierbar und in jeder heterogenen Umgebung wirklich implementierbar, unabhängig von der verwendeten physischen und logischen Netzwerktopologie.

Auf die Rolle eines solchen Werkzeugs bewerben sich derzeit die sogenannten Deception-Lösungen. Das sind Lösungen, die auf dem alten, bewährten Konzept von Honeypots basieren, jedoch mit einem völlig anderen Umsetzungsgrad. Dieses Thema ist derzeit eindeutig im Aufschwung.

Laut den Ergebnissen Gartner Security & Risk Management Summit 2017 Deception-Lösungen gehören zu den Top 3 Strategien und Werkzeugen, die empfohlen werden.

Laut dem Bericht TAG Cybersecurity Annual 2017 ist Deception eines der Hauptentwicklungsrichtungen für IDS (Intrusion Detection Systems).

Eine gesamte Sektion des neuesten Berichts von Cisco zur IT-Sicherheit, die SCADA gewidmet ist, basiert auf den Daten eines der Marktführer, TrapX Security (Israel), deren Lösung bereits seit einem Jahr in unserer Testumgebung läuft.

TrapX Deception Grid ermöglicht den zentralen Aufbau und Betrieb massierter, verteilter IDS, ohne die Lizenzbelastung und Hardwareanforderungen zu erhöhen. Tatsächlich ist TrapX ein Baukastensystem, das es ermöglicht, aus Bausteinen der bestehenden IT-Infrastruktur einen großen Mechanismus zur Erkennung von Angriffen auf Unternehmensebene zu schaffen, eine Art verteilte Netzwerksignalisierung.

Lösungstruktur

In unserem Labor untersuchen und testen wir ständig verschiedene Neuheiten im Bereich IT-Sicherheit. Aktuell sind hier etwa 50 unterschiedliche virtuelle Server eingerichtet, einschließlich der Komponenten von TrapX Deception Grid.

Also, von oben nach unten:

1. TSOC (TrapX Security Operation Console) – das Gehirn des Systems. Dies ist das zentrale Management-Panel, über das die Konfiguration, Bereitstellung der Lösung und die gesamte tägliche Arbeit erfolgt. Da es sich um einen Webservice handelt, kann es überall eingerichtet werden – an der Peripherie, in der Cloud oder bei einem MSSP-Anbieter.
2. TrapX Appliance (TSA) – ein virtueller Server, an den wir über einen Trunk-Port die Subnetze anschließen, die wir überwachen möchten. Hier ''leben'' auch alle unsere Netzsensoren.

   In unserem Labor ist ein TSA (mwsapp1) bereitgestellt, aber tatsächlich kann es davon viele geben. Dies kann in großen Netzwerken notwendig sein, in denen zwischen den Segmenten keine L2-Konnektivität existiert (typisches Beispiel – ''Holding und Tochterunternehmen'' oder ''Hauptsitz einer Bank und Filialen'') oder wenn es in Netzwerken isolierte Segmente gibt, beispielsweise in der industriellen Automatisierung. In jedem solchen Standort/Segment kann ein eigener TSA bereitgestellt und mit dem zentralen TSOC verbunden werden, auf dem alle Informationen zentral verarbeitet werden. Diese Architektur ermöglicht den Aufbau verteilter Überwachungssysteme, ohne dass eine grundlegende Umstrukturierung des Netzwerks oder eine Störung der bestehenden Segmentierung erforderlich ist.

   Außerdem können wir an der TSA eine Kopie des ausgehenden Datenverkehrs über TAP/SPAN einspeisen. Im Falle von Verbindungen zu bekannten Botnets, Command-and-Control-Servern oder TOR-Sitzungen erhalten wir auch Ergebnisse in der Konsole. Dafür ist der Network Intelligence Sensor (NIS) verantwortlich. In unserer Umgebung wird diese Funktionalität an der Firewall realisiert, daher haben wir sie hier nicht verwendet.

3. Anwendungstraps (Full OS) – traditionelle Honeypots auf Basis von Windows-Servern. Es sind nicht viele erforderlich, da die Hauptaufgabe dieser Server darin besteht, IT-Dienste an die nächste Ebene von Sensoren bereitzustellen oder Angriffe auf Business-Anwendungen zu erkennen, die in einer Windows-Umgebung ausgerollt werden können. In unserem Labor haben wir einen solchen Server installiert (FOS01).

   

4. Emulierte Traps – der Hauptbestandteil der Lösung, der es uns ermöglicht, mit nur einer einzigen virtuellen Maschine ein sehr dichtes „minesweeper“-Feld für Angreifer zu schaffen und das Unternehmensnetzwerk, einschließlich aller seiner VLANs, mit unseren Sensoren zu saturieren. Ein Angreifer sieht einen solchen Sensor oder phantomhaften Host als echten Windows-PC oder -Server, Linux-Server oder ein anderes Gerät, das wir ihm zeigen möchten.

   
   
   Zur besseren Veranschaulichung und aus Neugier haben wir für jede Art von Gerät eine Reihe bereitgestellt – Windows-PCs und Server verschiedener Versionen, Linux-Server, einen Geldautomaten mit Windows Embedded, SWIFT Web Access, einen Netzwerkdrucker, einen Cisco-Switch, eine Axis-IP-Kamera, ein MacBook, ein PLC-Gerät und sogar eine smarte Glühbirne. Insgesamt sind das 13 Hosts. Generell empfiehlt der Anbieter, solche Sensoren in einer Anzahl von mindestens 10% der Anzahl der realen Hosts zu implementieren. Die obere Grenze ist der verfügbare Adressraum.

   Ein sehr wichtiger Punkt ist, dass jeder solcher Hosts keine vollwertige virtuelle Maschine ist, die Ressourcen und Lizenzen benötigt. Es handelt sich um einen „Fake“, eine Emulation, einen Prozess auf TSA, der eine Reihe von Parametern und eine IP-Adresse hat. Daher können wir selbst mit einem einzigen TSA das Netzwerk mit Hunderten solcher phantomhaften Hosts versorgen, die als Sensoren in einem Alarmsystem fungieren. Diese Technologie ermöglicht es, das Konzept der „Honeypots“ wirtschaftlich effizient im Maßstab jedes großen verteilten Unternehmens zu skalieren.

   Diese Hosts sind aus der Perspektive von Angreifern attraktiv, da sie Schwachstellen enthalten und relativ leichte Ziele darstellen. Ein Angreifer sieht Dienste auf diesen Hosts und kann mit ihnen interagieren, sie angreifen, indem er Standardwerkzeuge und -protokolle (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus usw.) verwendet. Es ist jedoch nicht möglich, diese Hosts zur Angriffsentwicklung oder zum Ausführen eigenen Codes zu nutzen.

5. Die Kombination dieser beiden Technologien (FullOS und emulierte Fallen) ermöglicht eine hohe statistische Wahrscheinlichkeit, dass ein Angreifer früher oder später auf ein Element unseres Signalsystems stößt. Aber wie kann man sicherstellen, dass diese Wahrscheinlichkeit nahe bei 100 % liegt?

   Es kommen so genannte Tokens (Deception tokens) ins Spiel. Dank ihnen können wir alle verfügbaren PCs und Server des Unternehmens in unser verteiltes IDS integrieren. Die Tokens werden auf echten PCs der Benutzer platziert. Es ist wichtig zu verstehen, dass Tokens keine Agenten sind, die Ressourcen verbrauchen und Konflikte verursachen können. Tokens sind passive Informationselemente, eine Art „Brotkrumen“ für die angreifende Seite, die sie in eine Falle führen. Zum Beispiel verbundene Netzlaufwerke, Links zu gefälschten Web-Admin-Oberflächen im Browser und gespeicherte Passwörter zu diesen, gespeicherte ssh/rdp/winscp-Sitzungen, unsere Fallen mit Kommentaren in Hosts-Dateien, in den Speichern gespeicherte Passwörter und Anmeldeinformationen für nicht existierende Benutzer, Bürodokumente, deren Öffnung die Auslösung des Systems hervorrufen würde, und vieles mehr. So versetzen wir den Angreifer in eine verzerrte Umgebung, gesättigt mit den Angriffsvektoren, die für uns tatsächlich keine Bedrohung darstellen, sondern eher das Gegenteil. Er hat keine Möglichkeit zu erkennen, wo die wahre Information liegt und wo die falsche. Auf diese Weise sichern wir nicht nur eine schnelle Erkennung eines Angriffs, sondern verlangsamen auch dessen Verlauf erheblich.

Beispiel für die Erstellung einer Netzwerkfalle und die Konfiguration von Tokens. Benutzerfreundliche Oberfläche und keinerlei manuelle Anpassung von Konfigurationen, Skripten usw.

In unserer Umgebung haben wir eine Reihe solcher Tokens auf FOS01 unter Windows Server 2012R2 und einem Test-PC unter Windows 7 konfiguriert und platziert. Auf diesen Maschinen läuft RDP, und wir „hängen“ sie regelmäßig in die DMZ, wo auch mehrere unserer Sensoren (emulierte Fallen) platziert sind. Auf diese Weise erhalten wir einen konstanten Fluss von Vorfällen, sozusagen auf natürliche Weise.

Hier also eine kurze Statistik für das Jahr:

56 208 – Vorfälle wurden registriert,
2 912 – Quellenhosts von Angriffen wurden entdeckt.

Interaktive, klickbare Karte der Angriffe.

Dabei erzeugt die Lösung kein Mega-Log oder eine Ereignisliste, die schwer zu durchschauen ist. Stattdessen klassifiziert die Lösung die Ereignisse selbst nach ihren Typen und ermöglicht es dem Sicherheitsteam, sich zunächst auf die gefährlichsten zu konzentrieren – wenn der Angreifer versucht, Steuerungs­sitzungen zu initiieren (Interaction) oder wenn wir in unserem Verkehr binäre Payloads (Infection) feststellen.

Alle Informationen über Ereignisse sind lesbar und werden, meiner Meinung nach, in einer leicht verständlichen Form präsentiert, selbst für einen Benutzer mit grundlegenden Kenntnissen in der Informationssicherheit.

Die meisten der erfassten Vorfälle sind Versuche, unsere Hosts oder einzelne Verbindungen zu scannen.

Oder Versuche, Passwörter für RDP zu knacken.

Es gab jedoch auch interessantere Fälle, insbesondere als es den Angreifern 'gelang', ein Passwort für RDP zu erraten und Zugang zum lokalen Netzwerk zu erhalten.

Der Angreifer versucht, Code mit psexec auszuführen.

Der Angreifer fand eine gespeicherte Sitzung, die ihn in eine Falle in Form eines Linux-Servers führte. Sofort nach der Verbindung mit einem vorbereiteten Befehlssatz versuchte er, alle Protokolldateien und die entsprechenden Systemvariablen zu löschen.

Der Angreifer versucht, eine SQL-Injection auf einer Falle durchzuführen, die den SWIFT Web Access emuliert.

Neben solchen 'natürlichen' Angriffen haben wir auch einige eigene Tests durchgeführt. Einer der aussagekräftigsten ist der Test zur Erkennung von Netzwerkwürmern im Netzwerk. Dafür haben wir das Tool von GuardiCore verwendet, das heißt Infection Monkey. Es ist ein Netzwerkwurm, der Windows und Linux infizieren kann, jedoch ohne eine 'nützliche' Payload.
Wir haben ein lokales Kommandozentrum eingerichtet, auf einem der Maschinen den ersten Wurm-Exemplar gestartet und erhielten die erste Benachrichtigung in der TrapX-Konsole innerhalb von anderthalb Minuten. TTD 90 Sekunden im Vergleich zu durchschnittlich 106 Tagen …

Dank der Möglichkeit zur Integration mit anderen Lösungsklassen können wir nicht nur von schneller Bedrohungserkennung zu automatischer Reaktion übergehen.

So wird zum Beispiel die Integration mit NAC (Network Access Control)-Systemen oder mit CarbonBlack es ermöglichen, kompromittierte PCs automatisch vom Netzwerk zu trennen.

Die Integration mit Sandboxes ermöglicht es, Dateien, die an Angriffen beteiligt sind, automatisch zur Analyse zu übermitteln.

Integration mit McAfee

Auch die Lösung verfügt über ein integriertes System zur Ereigniskorrelation.

Aber wir waren mit ihren Möglichkeiten nicht zufrieden, daher haben wir sie mit HP ArcSight integriert.

Das integrierte Ticket-System hilft uns, mit den entdeckten Bedrohungen "gemeinsam" umzugehen.

Da die Lösung von Anfang an für die Bedürfnisse von staatlichen Stellen und großen Unternehmenssegmenten entwickelt wurde, verfügt sie natürlich über ein Rollenzugriffsmodell, Integration mit AD, ein ausgeklügeltes Berichtswesen und Trigger (Ereignisbenachrichtigungen), sowie eine Orchestrierung für große Holdingstrukturen oder MSSP-Anbieter.

Statt eines Lebenslaufs

Wenn es ein solches Überwachungssystem gibt, das, bildlich gesprochen, unseren Rücken deckt, dann fängt die Kompromittierung des Perimeters erst an. Das Wichtigste ist, dass wir die echte Möglichkeit haben, gegen IKT-Incidents zu kämpfen, anstatt nur die Folgen zu beseitigen.

Quelle: habr.com