Big Brother für privilegierte Benutzer? Warum sich Admins „auf die Finger schauen“ lassen sollten

Die Gefahr von Identitätsdiebstahl ist höher denn je. Cyber-Kriminelle versuchen, sich über privilegierte Benutzer Zugriff auf IT-Systeme zu verschaffen. Haben sie ihr Ziel erreicht, steht ihnen Tür und Tor offen. Ist der Fall eines erfolgreichen Angriffs erst einmal eingetreten, haben Forensiker nur begrenzte Möglichkeiten das Vorgehen eines Angreifers nachzuvollziehen.

Ganz abgesehen vom entstandenen Schaden für das Unternehmen. Nicht so mit Privileged Access Monitoring.

Kontrollverlust

Durch die wachsende Anzahl an Systemen, verlieren wir sukzessive den Überblick über Einsatz und Nutzung privilegierter Accounts –umgangssprachlich auch Admin-Accounts genannt.

Wer hat die Hoheit auf welchen Systemen? Was dürfen Administratoren und was tun sie? Wer hat was wann geändert und wie? Warum funktioniert dieses oder jenes nicht mehr oder anders? Wie kommt wer auf welches System? Welche Accounts für Services sind mit welchen Berechtigungen im Einsatz?
Die Komplexität hat einen Grad erreicht, an welchem wir die IT nicht mehr beherrschen. Wir brauchen Werkzeuge, die uns helfen, die Kontrolle zu behalten.

Da sich Unternehmen auf ihr Kerngeschäft konzentrieren müssen und nicht ausreichend qualifiziertes IT-Personal zur Verfügung steht, geben wir den Betrieb einzelner Anwendungen oder Systeme „nach außen“ – an Dienstleister, die für uns unterschiedlichste Leistungen erbringen. Natürlich brauchen diese dazu privilegierte Accounts. Wir stellen die Zugänge augenscheinlich „sicher“ über VPN zur Verfügung. Eine verschlüsselte Verbindung sorgt dafür, dass die Daten auf dem Weg nicht einsehbar sind. Dennoch wissen wir nicht, was der externe Dienstleister inhaltlich auf unseren Systemen macht.

Hinzu kommt, dass externe Dienstleister, aber auch Händler oder  Zulieferer, Zugang zu sensiblen unternehmensinternen und personenbezogenen Daten brauchen. Eine Vereinbarung für ADV (Auftragsdatenverarbeitung) regelt zwar den Datenschutz auf dem Papier, die Kontrolle und Prüfung gestaltet sich im Alltag jedoch schwer.

Technischer Hintergrund bei Fernzugriffen

Privilegierte Nutzer (meist Admins) nutzen SSH, RDP, ICA, TELNET, VNC und andere Protokolle, um von der Ferne aus ihre Arbeiten an den Systemen zu erledigen – umgangssprachlich „Remote Session“. Die meisten der Protokolle lassen sich verschlüsselt benutzen. Das klingt zunächst sicher, ist es aber nur für den Übertragungsweg. Hier werden die Daten zwischen dem Client und dem Server auf dem Weg verschlüsselt. Eine inhaltliche Kontrolle wird in der Regel nicht vorgenommen.

Für alle Fernzugriffe braucht es einen entsprechenden Serverdienst, welcher den Zugriff überhaupt erst möglich macht. Dieser prüft, ob ein Benutzer über das entsprechende Protokoll zugreifen darf oder nicht. Der Serverdienst protokolliert dabei auch erfolgreiche und fehlgeschlagene Logins. Ist die Verbindung aber erst einmal hergestellt, kann der Benutzer entsprechend seiner Berechtigung alle Befehle in beliebiger Reihenfolge absetzen, ohne dass es vom System im Log protokolliert wird. Als Administrator darf er in der Regel ohnehin alles – so auch seine Spuren verwischen. Ein Angreifer versucht genau das. Es empfiehlt sich daher, Log Daten grundsätzlich an ein zentrales Log Management zu senden, damit diese nicht manipuliert werden können.

Warum Big Brother?

Auch wenn wir ein Log Management haben, gibt es eine Lücke in der Nachvollziehbarkeit dessen, was privilegierte Nutzer auf den Systemen tun. Um diese Lücke zu schließen und die damit verbundenen Risiken zu senken, gibt es das Privileged Access Monitoring, kurz PAM. Meine Kollegin hat in ihrem Beitrag bereits darüber berichtet, was das genau ist und wie es eingesetzt wird – und was es Unternehmen bringt. Aus Sicht des Unternehmens sind die Vorteile klar auf der Hand.

Aber wie ist das aus Sicht des Admins, des privilegierten Benutzers? Er fühlt sich kontrolliert, in seinem Freiraum und Handeln eingeschränkt, in seiner Leistung überwacht. Muss er Angst haben, dass jeder Schritt seiner Arbeit bei der Aufzeichnung von Sitzungen zur Leistungskontrolle herangezogen wird? Theoretisch möglich ist das mit dieser Technik.

Wenn ich mich mit IT-Leitern oder Verantwortlichen für IT-Sicherheit im Unternehmen unterhalte und das Thema anspreche, bekomme ich in 99% der Fälle ein Bild des Vertrauens zu seinen Admins gespiegelt. „Wir wollen unsere Mitarbeiter gar nicht überwachen“. „Wenn wir diesen Kollegen nicht vertrauen, wie wollen wir dann konstruktiv zusammenarbeiten?“. Liebe Admins, ihr braucht euch hier also keine Sorgen machen.

Meiner Meinung nach erledigen privilegierte Benutzer in der Administration auf  Unternehmensservern, die kritisch für den Betriebsablauf sind, nichts anderes, als ihre Arbeit. Private Informationen werden hier nicht genutzt, anders als beispielsweise auf den eigenen lokalen Laptops. Um die Privatsphäre brauchen wir uns hier demnach auch keine Sorgen zu machen.

Anders bei Cyber-Kriminellen, die versuchen an Daten ranzukommen und Identitäten privilegierter Nutzer zu diesem Zweck auszunutzen. Diese gilt es zu überführen, in dem man nachvollziehen kann, was und wie diese vorgegangen sind.

Für den Admin selbst gibt es aus meiner Sicht zwei wichtige Nutzenargumente bei der Nutzung von PAM:

1. Nachvollziehbarkeit und Nachweis

Der Admin ist in der Lage selbst nachzuvollziehen, was und wie er etwas auf einem System getan hat. Hat er ein System, das er optimiert, und versucht iterativ unterschiedliche Einstellungen an Konfigurationsparametern, kann er je nach Auswirkung schnell und einfach nachvollziehen, wie er den Weg zurück gehen kann, damit es wieder wird,  wie es war. Ohne Restore aus Backups oder Config Management Umgebungen nutzen zu müssen. Zudem er kann damit nachweisen, dass er richtig gehandelt hat. Sollte der Admin doch mal einen Fehler gemacht haben, kann er daraus lernen. Was mich direkt zum zweiten Argument bringt:

2. Wissenssicherung und Schulungszweck

Admins sind in der Lage, Aufzeichnungen als Schulungszweck und zur Nachvollziehbarkeit und somit zur Wiederholbarkeit zu nutzen. Hat ein Admin vor zwei Jahren ein System neu aufgesetzt und soll ein ähnliches oder gleiches System entstehen oder/und sollen Teamkollegen die Aufgabe übernehmen, muss das Wissen über Ablauf und Inhalt bereitgestellt werden. Unter Umständen hat der Admin ursprünglich Unterstützung durch einen externen Dienstleister genutzt. Der Mitarbeiter und Wissensträger ist jedoch leider nicht mehr verfügbar.

Wir wissen, um welches System es sich handelt und wann es installiert und konfiguriert wurde. Daher können wir mit Hilfe von PAM und dessen Aufzeichnungen nun exakt nachvollziehen und lernen, wie das System aufgesetzt wurde. Das Wissen ist somit nicht verloren, sondern kann wieder genutzt und weitergegeben werden. Das spart viel Ärger und Zeit.

Fazit

Ich möchte daher Admins ermutigen sich zu öffnen und PAM als Unterstützung und nicht als Kontrolle zu sehen. Ich möchte sie ermutigen, für sich und die Kollegen Transparenz und Nachvollziehbarkeit für das eigene Handeln zu schaffen.

Andererseits aber auch für den Fall eines Angriffs vorbereitet zu sein. Cyber-Kriminelle werden uns immer einen Schritt voraus sein, wenn sie effektiv sein wollen. Wichtig ist, daraus zu lernen, wie sie vorgehen, um zu erkennen, wie man sich schützen kann.

PAM muss dafür natürlich an der richtigen Stelle sitzen, an der keiner vorbeikommt – wie eine unsichtbare Röhre als einziger Weg von A nach B. Noch besser, wenn der Angreifer gar nicht merkt, dass er durch eine Röhre mit Überwachungskameras geht. Dann wird er uns genau das zeigen, was uns so brennend interessiert.

Produktempfehlung und Ausblick

Mein persönlicher Favorit am Markt ist nach wie vor die Shell Control Box von Balabit. Das liegt daran, weil sie neben den genannten Funktionen eine der ältesten Firewalls der Next Generation ist und die Anwender- und Protokollkontrolle schon viele Jahre implementiert hat. So lassen sich Regeln definieren nach den Fragen:

  • Wer (User) darf wann (Time) mit welchem Protokoll (SSH, RDP, ICA, TELNET, VNC) auf welchen Server (IP)?
  • Welche Authentifizierung (Radius, Local, LDAP,…) soll verwendet werden?
  • Was zeichnen wir auf?

Noch granularer lässt sich innerhalb des Protokolls entscheiden:

  • Der Admin darf eine Shell via SSH, aber kein SCP (secure copy) oder X11-Weiterleitungen (die als VPN „versteckt“ verwendet werden könnten) nutzen
  • Der Admin darf eine RDP Terminal Session, aber die Zwischenablage nicht nutzen und auch keine lokalen Laufwerke in die Remote Session mappen

Balabit hat ihre Lösung konsequent und sinnvoll weiterentwickelt und lässt sie ein Bestandteil von SIEM, Log Management und User Behaviour Analytics werden. Dazu mehr in einem weiteren Artikel.

1 Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

CAPTCHA *