Management und Wissen / Systemadministration

Bewusste Beschränkung

Best Practices für eine Verringerung der Angriffsfläche bei der Systemverwaltung

Auch wenn man es an sich „besser weiß“, haben viele Benutzer- und Admin-Konten in etlichen Organisationen noch immer zu viele Rechte. Das erleichtert womöglich den IT-Alltag, erhöht aber gleichzeitig erheblich die Angriffsfläche für Cyber-Attacken. Grund genug, um sich wieder einmal passende Best Practices anzusehen, empfiehlt unser Autor.

Von Lars Klinghammer, Hamburg

Heikle Fehlkonfigurationen, welche die Sicherheit der IT-Systeme gefährden, findet man immer wieder. Die meisten Unternehmen und ihre Security-Abteilungen wissen zwar in der Theorie, wie empfohlene Maßnahmen und Konfigurationen aussehen. In der Praxis sorgen aber verschiedene Randbedingungen wie zunehmender Kostendruck, geringe Personaldecke, ständig neue Technologie, die gleichzeitige Umsetzung verschiedener IT-Projekte sowie der Betrieb komplexer, heterogener Infrastrukturen für reichlich Stolpersteine.

In einem solchen Konglomerat muss man zwangsläufig priorisieren, was nur allzu häufig dazu führt, dass die IT-Sicherheit nicht immer den erforderlichen Stellenwert erhält und nicht selten mehr als Blocker denn als Chance wahrgenommen wird.

Die Schwachpunkte, die Microsoft weltweit am häufigsten bei seinen Kunden antrifft und die für Unternehmen die größten Herausforderungen darstellen, sind:

• der Diebstahl von Anmeldedaten,
• Rechteerhöhung von Benutzerkonten,
• ungenügendes Monitoring sowie
• das Fehlen definierter Incident-Response-Prozesse.

Allgemeine Empfehlungen

Um diesen Bedrohungen zu begegnen, hat Microsoft eine Reihe von Empfehlungen und Best Practices erstellt. Nicht alle diese Maßnahmen sind sofort in jeder Organisation umsetzbar, aber auch jede einzelne für sich ist bereits sinnvoll. Hier sollte man im Rahmen des Risikomanagements abwägen, welche Lösungen das beste Kosten-Nutzenverhältnis bieten und besonders relevant für die eigene IT-Umgebung sind.

Die im Folgenden kurz zusammengefassten Empfehlungen können unter anderem detailliert in den beiden englischsprachigen Dokumenten „Mitigating Pass the Hash and other credential theft technologies“ (V1 und V2) nachgelesen werden, die über www.microsoft.com/pth kostenlos verfügbar sind. Die darin beschriebenen Ansätze, um das Risiko für die oben genannten Bedrohungen zu reduzieren, lassen sich in folgende Unterpunkte aufteilen:

• Beschränkung und Schutz hoch-privilegierter Domänenkonten,
• Beschränkung und Schutz lokaler Konten mit Administratorenrechten,
• Beschränkung des ein und- ausgehenden Datenverkehrs mittels hostbased Firewall,
• zusätzliche Konfigurationen,
• administrative Prozesse.

Die Umsetzung der Empfehlungen zu diesen fünf Punkten, die fast alle mit „Bordmitteln“ des Betriebssystems zu erreichen sind, sollte die Angriffsfläche bereits erheblich reduzieren. Eine auffällige grundlegende Änderung in heutigen Securityprojekten und eine generelle Empfehlung ist darüber hinaus der „Assume-Breach“-Ansatz: Letztlich kann man längst nicht mehr davon ausgehen, dass interne IT-Landschaften nicht schon einmal Opfer eines Cyberangriffes geworden sind oder in absehbarer Zeit sein werden – auch darauf sollte die ITSicherheit eingestellt sein. Dazu gehört nicht zuletzt ein passendes Maß an Security-Monitoring.

Beschränkung und Schutz hoch-privilegierter Domänenkonten

Ein an sich sehr einfach umzusetzendes Designprinzip ist – auch im Unternehmen – die Nutzung isolierter Accounts für die Administration der Domänencontroller oder anderer besonders schützenswerter Systeme. Schwieriger ist es häufig in Outsourcing-Szenarien mit einer hohen Anzahl „externer und zumeist unkontrollierter“ Administratoren des Serviceproviders, diese eigentlich simplen Anforderungen in der Praxis konsequent umund durchzusetzen. Denn aus Sicherheitssicht darf der separate Administrationsaccount nicht „mail-enabled“ sein und nicht im Internet surfen können (technologisch unterbunden).

Als zusätzliche Maßnahmen sind hier vorzusehen:

• Administratoren müssen (ausschließlich!) für die Administration einen separaten Account nutzen.
• Die relevanten administrativen Accounts sind im Active Directory als „sensitive and cannot be delegated“ zu markieren.
• Domain-Administratoren und andere hochprivilegierte Konten müssen daran gehindert werden, sich an weniger vertrauenswürdigeren Systemen zu authentifizieren.
• Für die Durchführung administrativer Aufgaben müssen die Administratoren mit einer dedizierten, speziell gehärteten (gesicherten) Arbeitsstation ausgestattet werden.
• Dienste und zeitgesteuerte Aufgaben dürfen nicht so konfiguriert werden, dass sie unter hoch-privilegierten Konten auf Systemen einer niedrigen Sicherheitsstufe laufen.

Beschränkung und Schutz lokaler Konten mit administrativen Berechtigungen

Auch lokale Konten sind mit zusätzlichen Maßnahmen zu schützen, sofern sie administrative Berechtigungen besitzen:

• Beschränkungen über Gruppenrichtlinien (GPO), die verhindern, dass lokale Konten für eine Remote-Administration verwendet werden
• gezieltes Unterbinden von Network-Logon und Remote-Desktop-Logon-Berechtigungen für alle administrativen Konten
• Einsatz systemspezifischer Passwörter für lokale Administratorenkonten: Es muss unbedingt verhindert werden, dass ein und derselbe administrative Account mit dem gleichen Passwort auf mehreren Systemen verwendet werden kann (dies ist eine sehr häufig anzutreffende Fehlkonfiguration z. B. in Helpdeskszenarien). Diese Beschränkung lässt sich mit Tools von Drittanbietern umsetzen.

Einschränkung des eingehenden Datenverkehrs durch eine hostbasierte Firewall

Auch eine ausgeschaltete Windows-Firewall beziehungsweise das Fehlen einer hostbasierten Firewall von alternativen Anbietern ist eine in Unternehmen häufig anzutreffende (Fehl)Konfiguration. Dieses Vorgehen ist jedoch nicht zu empfehlen!

Leider gibt es in den meisten Umgebungen keine oder eine nur sehr beschränkte Beschreibung oder Definition der Kommunikationsbeziehungen, besonders bezüglich zulässiger und erwünschter eingehender Datenverbindungen – denn meist scheuen die zuständigen Abteilungen den Aufwand für die Konkretisierung solcher Kommunikationsbeziehungen. Um es Angreifern jedoch so schwer wie möglich zu machen, von einem System zum anderen zu springen, um dort nach neuen Schwachstellen und nützlichen Informationen zu suchen, sind entsprechende Policies extrem wichtig.

Zusätzlich zu diesen essenziellen Einstellungen sollte man die folgenden Konfigurationen vorsehen, um im Sinne einer Defence-in-Depth-Strategie weitere Schutzmechanismen zu implementieren:

• Unterbinden des Surfens mit hoch-privilegierten Accounts und von Serversystemen aus (besonders auf Domänen-Controllern)
• Standard-Benutzer müssen aus der Gruppe der lokalen Administratoren entfernt werden
• Konfiguration von Proxyservern, um den Internet-Zugang für sensitive Konten zu unterbinden
• kein E-Mail-Zugang für administrative Accounts
• ausschließliche Verwendung solcher Remote-Tools zur Administration, die keine wiederverwendbaren Credentials auf den Zielsystemen hinterlassen (diese sind z. B. im Anhang der o. g. PTH-Dokumente aufgelistet)
• Vermeidung der Anmeldung an Systeme einer niedrigeren Schutzstufe/Sicherheit, die eine höhere Wahrscheinlichkeit für eine Kompromittierung haben
• regelmäßige und zeitnahe Aktualisierung der Applikationen und des Betriebssystems
• Sicherung und sichere Verwaltung von Domänen-Controllern
• Deaktivieren und Entfernen der so genannten LM-Hashes

Administrative Prozesse und Vorgehensweisen

Eine Vielzahl weiterer Konfigurationen und Einstellungen, die das Betriebssystem anbietet, trägt dazu bei, die Sicherheit zu erhöhen und die Wahrscheinlichkeit eines Diebstahls von Credentials zu reduzieren:

• Anwendung des Least-Privileges-Prinzips – Benutzer sollten demnach nur mit den minimal benötigten Rechten ausgestattet werden
• Administrative Accounts sollten sich nur an so wenig wie möglich Systeme anmelden – diese Systeme müssen entsprechend gesichert sein
• Ausschluss, dass administrative Tätigkeiten auf Standardclients des Unternehmens ausgeführt werden
• Sicherstellen, dass sich Domänenadministratoren nicht an „normale“ nicht-kritische Systeme anmelden  (z. B. solche, die keine Domain-Controller oder Certification-Authorities sind)
• Einsatz von Group-Policies zu Logon-Einschränkungen bei einem Zugriff über Domänengrenzen hinweg möglichst „Selective Authentication“ verwenden
• lokale Administrator-Passwörter regelmäßig ändern
• Einsatz einer Netzwerksegmentierung und/oder Domänenisolierung (basierend z. B. auf IPSec)
• Einsatz starker Authentifizierung (z. B. mittels Zwei-Faktor-Verfahren)

Administrative Workstations

All die genannten Schritte sorgen für eine signifikante Verbesserung des Sicherheitsstatus einer IT-Infrastruktur. Eine vertiefende Frage, die bei Gesprächen mit Microsoft-Kunden in diesem Kontext regelmäßig gestellt wird, ist diejenige nach speziellen administrativen Workstations und welche Mechanismen dort zu ergreifen sind.

Wie bereits beschrieben, ist es extrem wichtig, bei der Administration sensitiver Systeme sicher zu sein, dass diese nicht versehentlich kompromittiert werden. Ein Ansatz hierfür ist es, die Administration ausschließlich von vertrauenswürdigen, speziell gesicherten Systemen (Secure-Admin-Clients) aus durchzuführen. Die wesentlichsten Maßnahmen zu deren Sicherung sind:

• Jegliche Installationen und Updates (Betriebssystem, Treiber, Anwendungen etc.) müssen mit nachweisbar unveränderter Software erfolgen. Dies lässt sich beispielsweise verifizieren, indem die jeweilige Software über mindestens zwei unabhängige Wege heruntergeladen und der Hash der beiden Downloads miteinander verglichen wird (etwa über certutil –hashfile <Dateipfad>).
• Auf den Secure-Admin-Clients müssen die von Microsoft empfohlenen Sicherheitseinstellungen angewendet werden. Diese sind ausführlich im frei verfügbaren Security-Compliance-Management-(SCM)-Toolkit dokumentiert und damit auch implementierbar (www.microsoft.com/scm). Dieses Hilfsmittel ist generell als Startpunkt für alle Aktivitäten rund um die Härtung von Windows-Systemen sehr zu empfehlen.
• Nutzung aller Optionen, die (je nach Betriebssystem-Version) für einen Secure Boot zur Verfügung stehen.
• Nutzung von Software-Restriction-Policies und/ oder AppLocker: Mit diesen Betriebssystem-Tools können Administratoren ein White- oder Blacklisting von Anwendungen über Group-Policies konfigurieren, die genau definieren, welche Applikationen ausgeführt werden dürfen und welche nicht.
• Nutzung einer Festplattenverschlüsselung (Full-Volume-Encryption) – ob hierzu die von Microsoft mitgelieferte Version (BitLocker) oder die eines anderen Herstellers zum Einsatz kommt, ist egal.
• Blockieren der USB-Ports
• Netzwerkisolation und Sicherung mittels Windows-Firewall und IPSec
• Einsatz von Microsofts Enhanced-Mitigation-Experience-Toolkit (EMET, www.microsoft.com/emet) oder einem Äquivalent anderer Hersteller

Sicherlich sind nicht alle genannten Security-Maßnahmen kurzfristig umsetzbar. Man sollte diese daher in einem Prozess des Risikomanagements priorisieren und dann derart implementieren, dass mit möglichst wenig Aufwand ein möglichst großer Sicherheitsgewinn erzielt wird.

Security-Monitoring

Ein weiteres Phänomen, das Microsoft-Consultants häufig bei Kunden vorfinden, ist ein unangemessenes Security-Monitoring. Einerseits genügt es nicht, all die Sicherheitsmechanismen zum Schutz der IT-Infrastruktur zu implementieren, ohne zu verifizieren, dass diese auch wirklich greifen. Das „Spektrum der Unzulänglichkeit“ reicht aber von „gar nicht vorhanden“ bis „vollkommen übertrieben“: Andererseits führt übertriebenes Monitoring nämlich dazu, dass man durch ein schlechtes „Signal-Rausch-Verhältnis“ die wirklich relevanten Ereignisse leicht übersehen kann.

Mängel zeigen sich auch dann, wenn Filtermechanismen seit Jahren nicht hinterfragt oder angepasst wurden. Oft ist festzustellen, dass Unternehmen bei Fragen nach ihrer Monitoringstrategie gar keine definierte und strukturierte Herangehensweise besitzen. Das Ziel des Security-Monitorings muss es jedoch sein, sich auf die wirklich relevanten Dinge zu fokussieren.

Um dies zu erreichen, ist zunächst im Rahmen eines Assessments zu klären, welche Konten und Gruppen hoch-privilegiert und damit besonders bedeutsam sind. Außerdem sind die hochsicheren Systeme zu indentifizieren, die am genausten überwacht werden sollen. So lässt sich die Zahl der zu berücksichtigenden Events schon signifikant reduzieren. Anschließend muss man für die jeweiligen Konten und Systeme genau definieren, was als erwartetes Verhalten und was als alarmierend gilt.

Ein Beispiel für solche Überlegungen wäre: „Mitglieder der Gruppe Domänen-Administrator melden sich interaktiv nur in einem definierten Zeitintervall und nur von Systemen der Gruppe der Admin-Workstations an der Gruppe der Domänen-Controller an.“ Alles, was nicht in das definierte Raster passt, ist per Definition suspekt und muss überprüft werden.

Zu Beginn der Umsetzung dieses Ansatzes muss man naturgemäß mehr Aufwand in die Analyse investieren, aber schon nach kurzer Zeit werden Events immer spezifischer und aussagekräftiger. Eine Liste relevanter Ereignisse kann man zum Beispiel dem Dokument „Best Practice for Securing Active Directory“ entnehmen (www.microsoft.com/en-us/download/details.aspx?id=38785).

Lars Klinghammer ist Cybersecurity-Architect bei Microsoft Cybersecurity Global Practice, Worldwide Public Sector Services.