Nach Hyper-V HGS und VM Absicherung mit VMWare folgt nun der dritte Teil unserer (E) SAE Deep Dive Serie. Vielleicht folgt Ihr uns ja auf LinkedIn, Xing, Facebook, Instagram oder Twitter und habt schon unsere Infografiken zu den Top Ten (E) SAE Maßnahmen gesehen. Falls nicht, holt das unbedingt nach 😊:

• LAPS
• Reduce high privileged service accounts
• Change all non-personal passwords
• Separate admin accounts

Doch warum erzählen wir euch das? Weil wir uns entschieden haben, in dieser Blog-Serie jeder Maßnahme aus unserer Top Ten Liste, der kosteneffektivsten Maßnahmen, einen Post zu widmen.

Heute starten wir mit der Trennung von administrativen und nicht-administrativen Benutzerkonten. Dabei geht es um die Verwendung separater Konten für die tägliche produktive Arbeit, wie E-Mail und Office-Anwendungen, und für die Administration von Systemen. Ziel der Maßnahme ist, dass ein Konto für die produktive Arbeit niemals administrative Berechtigungen für Infrastruktur, Server-Systeme oder Backend-Anwendungen besitzt. Das Thema ist sicherlich nicht neu und wird schon mehr als ein Jahrzehnt propagiert. Das BSI zum Beispiel sieht im IT-Grundschutz-Kompendium die Trennung von Benutzer- und Administrationskonten in den Umsetzungshinweisen zum Baustein SYS.2.1 Allgemeiner Client vor:

SYS.2.1.M2 Rollentrennung

Grundsätzlich kann zwischen Kennungen für Benutzer- und Administratoren unterschieden werden. Nur Administratoren verwalten die IT-Systeme, während normale Benutzerkennungen nur die Rechte besitzen, um ihre arbeitsplatzspezifischen Aufgaben erfüllen zu können. Normale Benutzerkennungen dürfen keine Administrationsrechte besitzen, damit das Betriebssystem und die Konfiguration der Clients vor versehentlicher, fahrlässiger oder vorsätzlicher Modifikation durch die Benutzer geschützt werden.

Trotzdem sehen wir bei unseren Kunden immer wieder, dass dieses Prinzip nicht eingehalten wird. Daher möchten  wir noch einmal an einem Beispiel aufzeigen, warum die Trennung wichtig ist.

2011 war die Sicherheitsfirma RSA Security von einem Hack betroffen. Einige Mitarbeiter hatten eine Phishing-Mail mit einem Excel-Anhang erhalten. Einer der Mitarbeiter öffnete die Excel-Datei mit dem Namen 2011 Recruitment Plan.xls, die ein Makro enthielt, das eine Zero-Day-Lücke im Adobe Flash Player ausnutzte und die Remote Control-Software Poison Ivy installierte. Die Beschreibung des Hacks im RSA-Firmenblog lässt einige Details aus, doch nachdem sich Poison Ivy üblicherweise ins Windows-Systemverzeichnis installiert, hatte der Benutzer, der die Excel-Datei öffnete, ganz offensichtlich lokale Administratorenrechte auf dem Windows-Endgerät. Dies eröffnete dem Angreifer die Möglichkeit, einen Fuß ins Firmennetzwerk zu bekommen und von dort aus Server zu sondieren und bei Auffinden von Schwachstellen diese zu übernehmen. (Es ist nicht ganz klar, ob das Konto des Endbenutzers noch administrative Berechtigungen im Backend hatte. Trotzdem verdeutlicht das Szenario die Gefahr, in die man sich hier begibt.) Der Angreifer gelangte in den Besitz von sensiblen Daten zur Berechnung der One-Time-Passwörter (OTP) und RSA Security musste letztendlich rund 40 Millionen SecurID-Tokens ihrer Kunden ersetzen. Die Gesamtkosten für den Konzern wurden mit 66 Millionen US-Dollar beziffert.

Dieses Beispiel illustriert dann auch schon deutlich, dass Konten für die produktive Arbeit, mit denen insbesondere auf E-Mails zugegriffen wird, keine lokalen Administrationsberechtigungen und administrativen Berechtigungen auf Infrastruktur, Server, Middleware und Applikationen besitzen dürfen.

In unserer nachfolgenden Infografik (nicht vergessen, uns auf LinkedIn, Xing, Facebook, Instagram und Twitter zu folgen, um keine der Grafiken zu verpassen 😉) stellen wir das Ganze noch einmal schematisch dar.

Bob nutzt dasselbe Konto für seine tägliche Arbeit und für die Administration von Servern. Bob wird Opfer einer Phishing-Attacke und der Angreifer kann mit Bobs Konto Malware wie z.B die im RSA-Beispiel genannte Remote Control-Software installieren und ohne weitere Privilege Escalation Daten aus dem Firmennetzwerk entwenden.

Die sichere Vorgehensweise ist in der folgenden Grafik visualisiert. Alice ist an ihrem Office-PC mit ihrem normalen Arbeitskonto angemeldet und führt damit ihre tägliche Arbeit aus. Dieses Konto hat keine weitergehenden Berechtigungen, auch keine lokalen Administrationsberechtigungen auf ihrem Office-PC. Da Phishing-Attacken immer anspruchsvoller werden und wie Fälle in der jüngeren Vergangenheit gezeigt haben, auch von gut geschulten Mitarbeitern schwer zu erkennen sind, kann auch Alice ein Opfer davon werden, jedoch sind die Auswirkungen des Angriffs abgemildert. Der Angreifer muss eine Möglichkeit einer Privilege Escalation finden, um ein Tool, wie z.B. mimikatz ausführen zu können. Mimikatz wäre dann in der Lage, Kennwörter, Hashes, PINs und Kerberos Tickets direkt aus dem Hauptspeicher auszulesen oder Kennworteingaben mitzuschneiden. Dies erfordert jedoch Administrationsberechtigungen auf dem Windows-System.

Klar ist auch, dass die reine Trennung der Konten allein noch kein vollumfassendes Sicherheitskonzept widerspiegelt. Selbstverständlich müssen weitere Mechanismen implementiert werden, dedizierte Admin-Konten sind hier nur der Anfang. Schaut einfach in die nächsten Blogartikel, um mehr zu erfahren…

Zusammenfassend kann man sagen, kleine Ursache große Wirkung. Für uns ganz klar die Nummer 1 der kosteneffektiven Maßnahmen. Ich hoffe wir konnten das Thema wieder in Erinnerung rufen, gehört hat es sicherlich schon jeder von euch. Ich bin sicher, dass es bei euch allen auch strikt umgesetzt ist, oder 😉?