Lücke als Sicherheitsinstrument – oder wie man APTs "live" fängt

(Danke an Sergey G. Brester für die Ideen zum Titel) sebres)

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

Um die logische Kohärenz des Materials zu bewahren, halte ich es für nötig, mit den Voraussetzungen zu beginnen. Also, das Problem:

1. Gezielte Angriffe sind die gefährlichste Art von Angriffen, obwohl ihr Anteil an der Gesamtheit der Bedrohungen relativ gering ist.
2. Ein wirklich effektives Mittel zum Schutz der Peripherie (oder ein Komplex solcher Mittel) wurde bisher noch nicht erfunden.
3. In der Regel verlaufen gezielte Angriffe in mehreren Phasen. Das Überwinden der Peripherie ist nur eine der anfänglichen Phasen, die (ihr dürft mich mit Steinen werfen) für das „Opfer“ keinen großen Schaden anrichtet, es sei denn, es handelt sich um DEoS-Angriffe (Destruction of Service) (Ransomware usw.). Wirklich schmerzhaft wird es erst später, wenn die eroberten Ressourcen für Pivoting und die vertiefte Entwicklung des Angriffs genutzt werden, und wir das nicht bemerkt haben.
4. Da wir echte Verluste erst erleiden, wenn Angreifer tatsächlich ihre Ziele (Anwendungsserver, Datenbanken, Datenspeicher, Repositories, kritische Infrastrukturelemente) erreichen, ist es logisch, dass eine der Aufgaben des Sicherheitsdienstes darin besteht, Angriffe vor diesem bedauerlichen Ereignis zu unterbrechen. Doch um etwas zu unterbrechen, muss man zuerst darüber informiert sein. Je früher, desto besser.
5. Daher ist für ein erfolgreiches Risikomanagement (das heißt, die Reduzierung von Schäden durch gezielte Angriffe) das Vorhandensein von Werkzeugen entscheidend, die eine minimalen TTD (time to detect – Zeit von der Eindringung 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 an?
   • „Sandkästen“. Eine weitere präventive Maßnahme, die noch weit von der Perfektion entfernt ist. Es gibt viele effektive Techniken zum Erkennen und Umgehen von Sandkästen oder Whitelisting-Lösungen. Die Jungs von der „dunklen Seite“ sind hier noch einen Schritt voraus.
   • UEBA (Systeme zur Verhaltensprofilierung und Erkennung von Abweichungen) kann theoretisch sehr effektiv sein. Allerdings ist das meiner Meinung nach etwas für die ferner Zukunft. In der Praxis ist es momentan sehr kostspielig, unzuverlässig und erfordert eine sehr reife und stabile IT- und Informationssicherheitsinfrastruktur, die bereits über alle Werkzeuge verfügt, die Daten für die Verhaltensanalyse generieren können.
   • SIEM ist ein gutes Werkzeug für Untersuchungen, allerdings ist es nicht in der Lage, etwas Neues oder Originelles zu erkennen und rechtzeitig zu präsentieren, weil die Korrelationsregeln im Wesentlichen dieselben Signaturen sind.

7. Daher besteht die Notwendigkeit für ein Tool, das:
   • erfolgreich in einer bereits kompromittierten Perimeterumgebung funktioniert,
   • erfolgreiche Angriffe in nahezu Echtzeit erkennt, unabhängig von den verwendeten Werkzeugen und Schwachstellen,
   • nicht von Signaturen/Regeln/Skripten/Politiken/Profilen und anderen statischen Elementen abhängt,
   • keine großen Datenmengen und deren Quellen für die Analyse benötigt.
   • würde es ermöglichen, Angriffe nicht als eine Art Risiko-Scoring zu definieren, das auf der „besten der Welt, patentierten und daher geschlossenen Mathematik“ beruht, die zusätzliche Untersuchungen erfordert, sondern praktisch als binäres Ereignis – „Ja, wir werden angegriffen“ oder „Nein, alles ist in Ordnung“.
   • war universell, effizient skalierbar und tatsächlich in jeder heterogenen Umgebung umsetzbar, unabhängig von der verwendeten physischen und logischen Netzwerktopologie.

Für die Rolle eines solchen Werkzeugs bewerben sich derzeit sogenannte Deception-Lösungen. Das sind Lösungen, die auf dem altbekannten Konzept der Honeypots basieren, jedoch mit einem völlig anderen Umsetzungsgrad. Dieses Thema ist derzeit eindeutig im Aufschwung.

Laut den Ergebnissen Gartner Security&Risc 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 von IDS (Intrusion Detection Systems)-Lösungen.

Eine ganze Sektion des letzten Berichts von Cisco über den Stand der IT-Sicherheit, die sich auf SCADA bezieht, basiert auf Daten eines der Marktführer, TrapX Security (Israel), deren Lösung seit einem Jahr in unserer Testregion im Einsatz ist.

TrapX Deception Grid ermöglicht den zentralisierten Aufbau und Betrieb massiver verteilter IDS, ohne die lizenztechnische Belastung und Hardwareanforderungen zu erhöhen. Tatsächlich ist TrapX ein Baukastensystem, das es ermöglicht, aus Elementen der bestehenden IT-Infrastruktur einen umfassenden Mechanismus zur Erkennung von Angriffen im gesamten Unternehmen zu schaffen, eine Art verteiltes Netzwerk-Alarmsystem.

Lösungstruktur

In unserem Labor analysieren und testen wir ständig verschiedene Neuheiten im Bereich IT-Sicherheit. Derzeit sind hier etwa 50 verschiedene virtuelle Server im Einsatz, einschließlich der Komponenten des TrapX Deception Grid.

Also, von oben nach unten:

1. TSOC (TrapX Security Operation Console) – das Gehirn des Systems. Dies ist die zentrale Steuerkonsole, über die die Konfiguration, Bereitstellung der Lösung und alle täglichen Aktivitäten erfolgen. Da es sich um einen Webservice handelt, kann es überall bereitgestellt werden – im Perimeter, in der Cloud oder bei einem MSSP-Anbieter.
2. TrapX Appliance (TSA) – ein virtueller Server, über den wir mithilfe eines Trunk-Ports die Subnetze verbinden, die wir unter Überwachung stellen möchten. Hier leben tatsächlich alle unsere Netzwerksensoren.

   In unserem Labor ist ein TSA (mwsapp1) implementiert, aber tatsächlich können es viele sein. Dies kann in großen Netzwerken nötig sein, in denen es keine L2-Verbindung zwischen den Segmenten gibt (ein typisches Beispiel – "Holding und Tochtergesellschaften" oder "Zentrale einer Bank und Filialen") oder wenn es isolierte Segmente im Netzwerk gibt, zum Beispiel SCADA. In jeder solchen Filiale/Segment kann sein eigener TSA implementiert und mit dem zentralen TSOC verbunden werden, wo alle Informationen zentral verarbeitet werden. Diese Architektur ermöglicht den Aufbau verteilter Überwachungssysteme, ohne dass eine umfassende Umstrukturierung des Netzwerks oder eine Störung der bestehenden Segmentierung erforderlich ist.

   Bei TSA können wir auch eine Kopie des ausgehenden Traffics über TAP/SPAN bereitstellen. Bei der Erkennung von Verbindungen zu bekannten Botnets, Command-Servern oder TOR-Sitzungen erhalten wir ebenfalls Ergebnisse in der Konsole. Dafür ist der Network Intelligence Sensor (NIS) verantwortlich. In unserer Umgebung wird diese Funktionalität auf der Firewall realisiert, weshalb wir sie hier nicht genutzt haben.

3. Application Traps (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 Geschäftsanwendungen zu identifizieren, die in einer Windows-Umgebung ausgeführt werden können. In unserem Labor haben wir einen solchen Server (FOS01) eingerichtet.

   

4. Emulated Traps – das Hauptkomponente der Lösung, das es uns ermöglicht, mit einer einzigen virtuellen Maschine ein sehr dichtes "Minenfeld" für Angreifer zu schaffen und das Netzwerk des Unternehmens, einschließlich aller VLANs, mit unseren Sensoren zu durchdringen. Der Angreifer sieht einen solchen Sensor oder phantomhafte Hosts als echten Windows-PC, Server, Linux-Server oder andere Geräte, die wir ihm zeigen möchten.

   
   
   Für das Wohl und aus Neugier haben wir eine Reihe von Testumgebungen eingerichtet – einen Windows-PC sowie Server verschiedener Versionen, Linux-Server, einen Geldautomaten mit Windows Embedded, SWIFT Web Access, einen Netzwerkdrucker, einen Cisco-Switch, eine IP-Kamera von Axis, ein MacBook, ein PLC-Gerät und sogar eine smarte Lampe. Insgesamt sind es 13 Hosts. Generell empfiehlt der Anbieter, solche Sensoren in einer Anzahl von mindestens 10 % der tatsächlichen Hosts bereitzustellen. Die Obergrenze liegt im verfügbaren Adressraum.

   Ein sehr wichtiger Aspekt ist, dass jeder dieser Hosts keine vollständige virtuelle Maschine ist, die Ressourcen und Lizenzen benötigt. Es handelt sich um eine «Scheinlösung», eine Emulation, einen Prozess auf TSA, der über eine Reihe von Parametern und eine IP-Adresse verfügt. Daher können wir sogar mit einem einzigen TSA das Netzwerk mit Hunderten solcher phantomhafter Hosts bereichern, die als Sensoren in einem Alarmsystem dienen. Diese Technologie ermöglicht eine kosteneffiziente Skalierung des Konzepts von „Honeypots“ in großem Maßstab für jedes große verteilte Unternehmen.

   Diese Hosts sind aus der Sicht eines Angreifers attraktiv, da sie Schwachstellen aufweisen und relativ leichte Ziele darstellen. Ein Angreifer erkennt die Dienste auf diesen Hosts und kann mit ihnen interagieren, sie angreifen, indem er Standardwerkzeuge und -protokolle verwendet (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus usw.). Allerdings ist es nicht möglich, diese Hosts zur Durchführung oder Entwicklung von Angriffen oder zur Ausführung eigenen Codes zu nutzen.

5. Die Kombination dieser beiden Technologien (FullOS und emulierte Fallen) ermöglicht eine hohe statistische Wahrscheinlichkeit, dass der Angreifer irgendwann auf ein Element unseres Signalenetzwerks stößt. Doch wie können wir sicherstellen, dass diese Wahrscheinlichkeit nahe 100% liegt?

   Jetzt kommen die sogenannten Deception-Tokens ins Spiel. Mit ihnen können wir alle verfügbaren PCs und Server des Unternehmens in unser verteiltes IDS integrieren. Die Tokens werden auf realen 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 von 'Brotkrumen' für die Angreifer, die sie in eine Falle locken. Zum Beispiel: angeschlossene Netzlaufwerke, Lesezeichen auf gefälschte Web-Admin-Panels im Browser und gespeicherte Passwörter dafür, gespeicherte ssh/rdp/winscp-Sitzungen, unsere Fallen mit Kommentaren in Hosts-Dateien, im Speicher gespeicherte Passwörter, Anmeldedaten nicht existierender Benutzern, Office-Dateien, deren Öffnung das System auslösen würde, und vieles mehr. Damit platzieren wir den Angreifer in einer verzerrten Umgebung, die mit Angriffswinkeln gesättigt ist, die für uns in Wirklichkeit keine Bedrohung darstellen, sondern im Gegenteil. Er hat keine Möglichkeit zu erkennen, wo die wahrhaftige Information und wo die falsche ist. Damit gewährleisten wir nicht nur eine schnelle Identifizierung des Angriffs, sondern verlangsamen auch seinen Verlauf erheblich.

Beispiel für die Erstellung eines Netzwerk-Täuschers und die Konfiguration von Tokens. Benutzerfreundliches Interface und keine manuelle Bearbeitung von Konfigurationen, Skripten usw.

In unserer Umgebung haben wir eine Reihe solcher Tokens auf FOS01 unter Windows Server 2012R2 und auf einem Test-PC unter Windows 7 konfiguriert und platziert. Auf diesen Maschinen läuft RDP, und wir "stellen" sie regelmäßig in die DMZ, wo auch eine Reihe unserer Sensoren (emulierte Täuscher) platziert ist. So erhalten wir einen stetigen Fluss von Vorfällen, sozusagen auf natürliche Weise.

Hier also eine kurze Statistik für das Jahr:

56.208 – festgestellte Vorfälle,
2.912 – entdeckte Angreifer-Hosts.

Interaktive, klickbare Karte der Angriffe

Das System generiert dabei keinen Mega-Log oder Ereignisstrom, in dem man lange nach Lösungen suchen muss. Stattdessen klassifiziert die Lösung die Ereignisse automatisch nach Typen und ermöglicht es dem Cybersicherheitsteam, sich zunächst auf die gefährlichsten zu konzentrieren – sobald die angreifende Partei versucht, Steuerungssitzungen (Interaktionen) zu initiieren oder wenn wir binäre Payloads (Infektionen) im Verkehr feststellen.

Alle Informationen zu den Vorfällen sind lesbar und werden meines Erachtens in einer verständlichen Weise präsentiert, selbst für Benutzer mit grundlegenden Kenntnissen im Bereich der IT-Sicherheit.

Die meisten der dokumentierten Vorfälle sind Versuche, unsere Hosts zu scannen oder einfache Verbindungen herzustellen.

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

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

Der Angreifer versucht, Code mithilfe von psexec auszuführen.

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

Der Angreifer versucht, eine SQL-Injektion in eine Falle durchzuführen, die den SWIFT Web Access imitiert.

Neben solchen "natürlichen" Angriffen haben wir auch mehrere eigene Tests durchgeführt. Einer der auffälligsten ist der Test zur Erkennungsgeschwindigkeit eines Netzwerkwurms im Netzwerk. Hierfür haben wir ein Tool von GuardiCore verwendet, das " Infection Monkey" heißt.. Dies ist ein Netzwerk-Wurm, der sowohl Windows als auch Linux infizieren kann, allerdings ohne eine spezifische 'nützliche' Last.
Wir haben ein lokales Kommandozentrum eingerichtet und auf einer der Maschinen die erste Instanz des Wurms gestartet, wobei wir weniger als anderthalb Minuten später die erste Benachrichtigung in der TrapX-Konsole erhalten haben. TTD 90 Sekunden im Vergleich zu durchschnittlich 106 Tagen …

Durch die Möglichkeit der Integration mit anderen Lösungsklassen können wir von schneller Bedrohungserkennung zu automatisierter Reaktion übergehen.

Die Integration mit NAC (Network Access Control)-Systemen oder CarbonBlack ermöglicht es beispielsweise, 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

Außerdem verfügt die Lösung über ein eigenes integriertes Ereigniskorrelationssystem.

Die Möglichkeiten überzeugten uns jedoch nicht, daher haben wir es in HP ArcSight integriert.

Die eingebaute Ticketingsystem hilft, mit den entdeckten Bedrohungen in Zusammenarbeit umzugehen.

Da die «Out-of-the-Box»-Lösung für die Bedürfnisse von Staatsbehörden und großen Unternehmen entwickelt wurde, ist dort natürlich ein rollenbasiertes Zugriffsmodell implementiert, die Integration mit AD sowie ein ausgefeiltes Berichtswesen und Trigger (Ereignisbenachrichtigungen) vorhanden. Zudem gibt es Orchestrierungsmöglichkeiten für große Unternehmensstrukturen oder MSSP-Anbieter.

Statt einer Zusammenfassung

Wenn ein solches Überwachungssystem, bildlich gesprochen, unseren Rücken absichert, dann fängt die Kompromittierung des Perimeter erst zu beginnen an. Das Wichtigste ist, dass es tatsächliche Möglichkeiten gibt, mit Sicherheitsvorfällen umzugehen, statt nur deren Folgen zu beseitigen.

Quelle: habr.com