Least Privileges – ein Traum nicht nur für Träumer

Der Least Privileges Ansatz gehört bei vielen Unternehmen zu den eigenen Golden Rules. Das Konzept dahinter ist schnell verstanden, aber die Umsetzung auf dem Endpoint birgt viele Hürden. Hier geht es darum, was die Knackpunkte sind und wie man diese angeht.

Die Angreifer mögen zwar Social Engineering betreiben um Zugriff auf das vermeintliche Netzwerk zu bekommen. Aber das Ziel von Social Engineering ist, durch den Menschen auf den Endpoint und somit ins Netzwerk zu kommen. Wenn der Endpoint kompromittiert ist, soll das Konzept Least Privileges es dem Angreifer möglichst schwer machen oder sogar verunmöglichen, sein Ziel zu erreichen. Mit Least Privileges werden dem Benutzer nur die Berechtigungen zugesprochen, die er auch benötigt. Bei einer Kompromittierung des Benutzer-Accounts können auch nur die zugesprochenen Berechtigungen übernommen werden. Wenn der Benutzer nur wenig Rechte hat, können auch nur wenige Rechte ausgenutzt werden.

Um Least Privileges auf dem Endpoint umzusetzen, muss dafür eine Policy definiert und anschliessend konfiguriert werden. Aber was sind die entscheidenden Faktoren? Welche Benutzer kriegen welche Berechtigungen? Oder kann man sogar eine einheitliche Least Privileges Policy im ganzen Unternehmen verteilen? Ist das möglich?
Im Unternehmen trifft man unterschiedliche Benutzergruppen vor, die unterschiedliche Berechtigungen brauchen:

• • Der klassische Office Worker kriegt die Standardprogramme und das Arbeiten mit Standardrechten reicht meistens völlig aus.
  • Der Aussendienst-Mitarbeiter, muss da schon mal seinen Home Office Drucker installieren (lassen) können.
  • Die Marketing Abteilung soll ihre Kamera oder ihren Card Reader anschliessen können. Ohne, dass andere Gerätetypen wie USB-Sticks erlaubt sind.

Ich sehe in Unternehmen auch folgende Fälle, bei denen der Mitarbeiter weitreichende Berechtigungen benötigt:

• • Die Nutzung von alten Programmen, bei denen der normale Benutzer lokale administrative Berechtigungen dazu braucht (ja, auch das gibt es leider immernoch…).
  • Die Entwickler müssen rasch Dritt-Softwares installieren können oder sollen unsignierte und selbst geschriebene Scripts ausführen dürfen.
  • Der Service Desk, der für die Supportleistung lokale administrative Beerechtigungen auf den Endpoints hat.
  • Usw.

Diese und noch weitere Anforderungen führen dazu, dass die Prozentzahl von Accounts mit erhöhten Berechtigungen im Unternehmen ansteigt. Gemäss Statistik werden bei 80% der Netzwerkeinbrüchen Credentials von administrativen Accounts kompromittiert. Somit muss man A) verhindern, dass Credentials von administrativen Accounts komprimittiert werden und B) sicherstellen, dass die administrativen Accounts nur die nötigen Rechte besitzen. Mit den Windows Boardmitteln ist die Umsetzung eines Least Privileges sehr schwer umsetzbar. Es gibt allerdings dedizierte Lösungen dafür. Eine davon habe ich mir angeschaut.

Ich habe mir die Endpoint Privilege Management (EPM) Lösung von BeyondTrust im Detail angeschaut. Wie im letzten Blog Artikel (Application Whitelisting vs. 21. Jahrhundert – was Sie wissen müssen) erwähnt, bietet EPM eine zeitgemässes Application Whitelisting an. Es kann zusätzlich aber auch die Berechtigungen der Benutzer so anpassen, dass die nötige Berechtigung on-the-fly dem Benutzer zugewiesen wird. Der Aussendienst-Mitarbeiter kann zum Beispiel selbst den HP Treiber für seinen Home Office Drucker installieren. Ohne dass er dafür lokal administrative Berechtigungen besitzt. Aber wie funktioniert das?

Wenn der Aussendienst-Mitarbeiter das Setup des HP Treibers startet, merkt EPM, dass es sich hierbei um einen signierten Treiber von HP Inc. handelt. Da der Benutzer zu den Aussendienst-Mitarbeitern gehört, erweitert EPM das Access Token für das Setup on-the-fly. Dabei wird das Setup weiterhin im Benutzerkontext aber mit lokalen administrativen Berechtigungen ausgeführt. So braucht der Aussendienst-Mitarbeiter weder ein Local Admin Account, noch muss er ein Service Desk Ticket eröffnen, um den Treiber installieren zu lassen. Er ist selbst fähig, den HP Treiber zu installieren.

Im Video unten wird das Prinzip mit dem Anpassen des Access Token verdeutlicht. Als erstes werden die Parameter und Ausgaben des Programms whoami im Command Prompt erklärt. Dabei wird der aktive Benutzer mit seiner SID-Nummer angezeigt. Unterhalb werden seine Gruppenmitgliedschaften sowie die daraus resultierenden Privilegien aufgelistet. Auf der zweiten Folie wird links whoami als Standard Benutzer ausgeführt und rechts wird whoami mit der Access Token Erweiterung ausgeführt.

EPM ist zwar Agent-basiert, aber durch das Prinzip des Anpassens vom Access Token können lokale Admins sehr stark oder sogar komplett eleminiert werden. Die Kombination von Application Whitelisting und Privilege Management (Umsetzten des Least Privileges Anastzes durch Anpassen des Access Tokens) macht EPM von BeyondTrust in meinen Augen zu einem sehr starken und effektiven Tool.

www.tec-bite.ch/application-whitelisting-vs-21-jahrhundert-was-sie-wissen-muessen/