Microsoft Advanced Thread Analytics

Vorbemerkung: Es handelt sich hier nicht um einen Nachfolger der "Microsoft Firewall" TMG (Thread Management Gateway) und es ist keine Firewall, kein Antivirus-Produkt und nur bedingt ein Intrusion Detection System. Aber es hilft einer Firma, Missbrauch zu erkennen. Angeblich erfolgen unberechtigte Zugriffe zu 76% über kompromittierte Accounts und bleiben angeblich über 243 Tage "unbemerkt".

Microsoft Advanced Threat Analytics
https://youtu.be/-MGg_07MkgY

Da helfen komplexe Kennworte genauso wenige wie Lockout Policies und selbst wenn Kennworte all 60 Tage geändert werden, kann das schon zu lange sein.

Microsoft hat Ende 2014 die Firma "Aorato" gekauft und dies dürfte die erste Version unter Microsoft Label sein.

Funktionsweise

Microsoft adressiert das Problem nun mit diesem neuen Produkt, welches über verschiedene Server ermittelt, wo Benutzer normalerweise zugreifen und so Abweichungen erkennen soll.

Ich habe mir so eine Funktion eigentlich schon viel früher und als Bestandteil des Windows Betriebssystems gewünscht. Wenn ich mich von einem "neuen" Computer z.B. bei Facebook anmelde, dann bekomme ich eine Mail über diesen "ungewöhnlichen" Vorgang. Das ist zwar nicht unbedingt sicher, das ein potenter Angreifer vermutlich zuerst den Zugriff auf mein Postfach anstrebt und dann über eine Kennwort-Rücksetzfunktion den Zugriff erreicht. Dann kann er auch diese Meldung abfangen.

In einem Firmennetzwerk kann es natürlich anders durchgeführt werden. Hier gibt es nicht nur einen Dienst, sondern eine ganze Menge an Diensten, die von Anwendern regulär genutzt werden aber auch Dienste, die eben nicht von Anwendern genutzt werden. Wenn eine Software also einige Zeit "lernt", von welchen Endpunkten sich ein Anwender anmeldet und woraus er zugreift, kann man ungewöhnliche Endpunkte und Ziele recht einfach ausfindig machen. Natürlich macht ein neuer Endpunkt in einem Zeitfenster noch keinen Alarm aber wenn ein Anwender viele neue Ziele ansprechen will, dann sollte man zumindest hellhörig werden. Allerdings darf die Überwachung selbst natürlich gar nicht "sichtbar" werden. Wer also einen Dienst auf einem Domain-Controller oder Member-Server installiert, macht es einem Angreifer zu einfach diesen zu umgehen. Daher funktioniert "Advanced Thread Analytics" etwas anders und für Administratoren vielleicht ungewohnt:

  • Center Server
    Es gibt einen Server, der alle Daten konsolidiert und meldet. Er muss dazu nicht mal in der Domäne sein und per Default können über die Weboberfläche auch nur lokale administrative Benutzer oder Mitglieder ein einer eigens angelegten lokalen Gruppe zugreifen. Selbst Domänen-Administratoren sind also erst mal "außen vor", aber können sich natürlich berechtigen.
    Die gesammelten Daten landen aber nicht in einer Textdatei oder SQL-Datenbank, sondern ein einer MongoDB-Datenbank, also einer "NoSQL"-Datenbank die für große unstrukturierte Datenmengen optimiert sein soll. Wenn man den Aussagen glauben darf, dann können das einige Gigabyte bis zu Terabyte werden
  • Gateway-Server
    Diese Systeme sammeln die Daten, indem Sie auf einer Netzwerkkarte die Daten der Domain Controller als "Mirror-Port" mitlesen. Domain Controller haben meist nicht die gleiche hohe Netzwerklast wie Dateiserver etc., so dass ein Gateway-Server auch mehrere DCs parallel ablauschen kann.
  • Switch
    Sie benötigen natürlich einen Switch, der die Netzwerkverkehre der Domain Controller zu diesem Gateway Server spiegeln kann. Seit Windows 2012 Hyper-V kann auch ein Port einer VM gespiegelt werden:

In einem Übersichtsbild sieht das dann wie folgt aus:

 

Die Ports der interessanten Domain Controller werden über den Netzwerk-Switch gespiegelt zu einer eigenen Netzwerkkarte des Gateway-Systems kopiert, welches die Daten aufschnappt, filtert und über einen per MTLS abgesicherten sicheren Kanal zum Center-System übermittelt. Daher sind auf dem Center und dem Gateway entsprechende Zertifikate erforderlich. Der Center speichert die Daten in einer MungoDB für die spätere Auswertung und Alarmierung. Die Administration erfolgt über Webbrowser über den Port 443. Der Center braucht also zumindest zwei IP-Adressen, wenn auch die Verbindung der Gateways zum Center über Port 443 laufen muss.

Ich bin schon etwas überrascht, dass allein ein Port Mirroring mit dem Mitschneiden der Pakete eines DCs so tiefe Einblicke zulässt. Ich wäre davon ausgegangen, dass dank LDAPS und Kerberos und anderen Verschlüsslungen hier ein "Lauscher" nicht viel ermitteln kann. Ich hätte eher an einen kleinen Dienst auf den Servern getippt oder ein hoch geschraubtes Security-Eventlog samt Ausleseprozess.

Häufige Fragen und Antworten

Bei der Umsetzung habe ich mir einige Fragen gestellt und schon beantworten können. Vielleicht erspart dieser Abschnitt ihnen eine weitere Suche

  • Office 365 Abhängigkeit ?
    Auch wenn man den Eindruck gewinnen kann, dass heute jede Software immer auch mit Office 365 verbunden ist, so ist dies hier nicht der Fall. "Advanced Thread Analytics" ist eine aktuell nur On-Premises verfügbare Lösung. Rein technisch könnte ich mir aber schon vorstellen, dass die Funktion des "Center" auch in in der Cloud abgebildet werden kann und nur die Gateway-Systeme lokal arbeiten
  • Müssen Center und Gateway getrennt sein ?
    Es ist technisch möglich, beide Funktionen auf einem Server bzw. einer VM zu betreiben. Sie sollten das vom "Sizing" abhängig machen, wie viele Daten sie erwarten und was ihre Systeme verarbeiten können. Da zumindest die Gateway-Rolle alle Pakete der DCs über den Spiegel-Port bekommen, sollten Sie der VM aber zumindest zwei Netzwerkkarten spendieren.
    Microsoft empfiehlt diese Konfiguration nur für Labs und Tests. Sobald Sie aber einige DCs auch auf Hyper-V betreiben, müssen sie Gateway-Systeme auf dem Host mitlaufen lassen. Auch DCs in den Niederlassungen benötigen natürlich eigene lokale Gateway-Systeme
  • Gateway Software direkt auf dem DC installieren ?
    Aktuell kann ich noch nicht sagen, ob die Gateway-Software nicht einfach mit auf dem DC installiert werden könnte. So richtig erschließt es mir nicht, warum es kein entsprechendes Modul gibt.
  • Ist ein SIEM erforderlich ?
    Das Gateway kann per SYSLOG Daten von SIEM-Systemen erhalten und mit in die Überwachung einbinden. Wer ein SIEM hat, sollte dies betrachten. Aber "Advanced Thread Analytics" funktioniert auch ohne SIEM.
  • Lizenzierung
    "Advanced Thread Analytics" kann "einzeln" für ca. 80US$/User gekauft werden. Es ist aber auch in der Enterprise CAL Suite als auch in verschiedenen Office 365 Subscriptions enthalten. Bitte informieren Sie sich über ihren aktuellen Lizenzstatus
    http://www.microsoft.com/en-us/server-cloud/products/advanced-threat-analytics/purchasing.aspx
  • Sizing
    Die Gateway-Systeme müssen schnell genug (CPU und Netzwerk) sein, um die gespiegelten Datenpakete der überwachten Domaincontroller zu verarbeiten und die essentiellen Daten an den Center weiter zu geben. Der Center hingegen muss all diese Daten in der lokalen MongoDB ablegen, bewerten und alarmieren, bzw. auf Anfrage zu Auswertungen ausreichend schnell reagieren. Microsoft gibt hier eine breite Spanne an. So kann die Datenbank der Anmeldungen von einigen Gigabyte auch bis zu mehreren Terabyte anwachsen.

Deployment

Wie sie nun schon wissen, gilt es erst die "Center"-Rolle auf einem Server zu installieren um dann von dort aus auf anderen Servern die Gateway-Rolle zu installieren. Ich protokolliere hier nur ein paar Schritte, da das Produkt sicher weiter entwickelt wird und daher Bilder schnell veralten.

  • Installation des Center
    Mich hat bei der Installation des Center der folgende Konfigurationsdialog zur Anpassung der Daten aufgefordert. Dies sind alles die Default-Werte.

    Sie Sehe schon hier, dass sowohl für die Verbindung der Gateway-Systeme als auch der Zugriff auf die Verwaltungswebseite per Zertifikate gesichert werden kann. Ich bevorzuge immer die Zertifikate einer internen PKI aber es sind auch Selbstzertifikate möglich.
  • Erste Konfiguration
    Nach der Installation des Center muss über eine kurze Konfiguration das Dienstkonto angegeben werden, über welches die Identitäten aus dem Active Directory ausgelesen werden. Das Konto ist einfach nur ein "Domain User" und kein Administrator. Der Zugriff auf die Konfiguration ist nur lokalen Benutzern möglich die zugleich Administrator sind oder Mitglieder der lokalen Produkt-Gruppe.

    Nach der Eingabe der Anmeldedaten kann die Installationsquelle für das Gateway herunter geladen werden. Das ZIP-File ("Microsoft ATA Gateway Setup.zip") kann genutzt werden, um ein oder mehrere Gateways zu installieren.
  • Gateway installieren
    Auf dem Server, der dann als Gateway die gespiegelten Daten vom Switch erhält, wird das Setup aufgerufen. Das Gateway installiert den erforderlichen Dienst und verbindet sich dann mit dem hinterlegten Center.
  • Gateway konfigurieren
    Die Konfiguration des Gateway erfolgt dann über den zentralen Center. Hier gibt es nun weitere Felder, mit denen Sie das Gateway benennen und vor allem die Netzwerkkarte angeben können, die für den Mitschnitt der Daten genutzt wird:

    Damit ist die Konfiguration abgeschlossen und nun heißt es etwas warten. Es werden nun Daten gesammelt und nach einiger Zeit soll "Advanced Threat Analytics" gelernt haben, welche Zugriffe "normal" sind.

Auswerten

Und dann heißt es erst mal warten, denn es dauert etwas, bis die Gateways mehr und mehr Daten gesammelt haben und der Center basierend auf erkannten Mustern auf Unstimmigkeiten hinweist. Das wird am Anfang wohl häufiger passieren, bis die Lernkurve einen gewissen Stand erreicht hat.

Beispiel eines "Einbruchs" durch Kerberos Ticketklau
https://youtu.be/xvWJssUpU6w?t=10m10s

Weitere Links