Kontorichtlinie für Domänenadministratoren (nach PCI-Prüfung)

Einer unserer Kunden ist ein Tier-1-PCI-Unternehmen, und ihre Prüfer haben uns als Systemadministratoren und unsere Zugriffsrechte einen Vorschlag unterbreitet.

Wir verwalten die vollständig auf Windows basierende Infrastruktur von rund 700 Desktops / 80 Servern / 10 Domänencontrollern.

Sie schlagen vor, dass wir zu einem System wechseln, in dem wir drei separate Konten haben:

DOMAIN.CO.UK\UserWS  
DOMAIN.CO.UK\UserSRV  
DOMAIN.CO.UK\UserDC  

• Wobei WS das Konto ist, das sich nur an WorkStations anmeldet, ist ein lokaler Administrator auf WorkStations
• Wo SRV das Konto ist, das sich nur bei Nicht-DC-Servern anmeldet, ist Local Administrator on Servers
• Wobei DC das Konto ist, das sich nur bei Domänencontrollern anmeldet, effektiv ein Domänenadministratorkonto

Es sind dann Richtlinien vorhanden, die verhindern, dass sich das falsche Konto bei dem falschen Systemtyp anmeldet (einschließlich des Entfernens der interaktiven Anmeldung für Domänenadministratorkonten auf Nicht-DC-Computern).

Auf diese Weise soll verhindert werden, dass eine gefährdete Arbeitsstation ein Anmeldetoken für Domänenadministratoren verfügbar macht und dieses für den Domänencontroller wiederverwendet.

Dies scheint nicht nur eine sehr aufdringliche Politik für unser tägliches Geschäft zu sein, sondern auch eine beträchtliche Menge an Arbeit, um einen relativ unwahrscheinlichen Angriff / Exploit anzugehen (dies ist meines Erachtens trotzdem, vielleicht verstehe ich die Machbarkeit dieses Exploits falsch). .

Ich bin daran interessiert, die Ansichten anderer Administratoren zu hören, insbesondere derjenigen, die an einem PCI-registrierten Unternehmen beteiligt waren, und Sie haben Erfahrungen mit ähnlichen Empfehlungen gemacht. Welche Richtlinien gelten für Administratoranmeldungen?

Für den Datensatz haben wir derzeit ein Domänenbenutzerkonto, das wir normalerweise verwenden, und ein Domänenadministratorkonto, das wir ebenfalls erhöhen, wenn wir die zusätzlichen Rechte benötigen. Ehrlich gesagt sind wir alle ein bisschen faul und verwenden häufig nur das Domänenadministratorkonto für den täglichen Betrieb, obwohl dies technisch gegen unsere Unternehmensrichtlinien verstößt (ich bin sicher, dass Sie das verstehen!).

Ich bin bei einem Tier 1 PCI-Anbieter. Wir haben so etwas mit ein paar Unterschieden.

Die Prüfer versuchen tatsächlich, ein sehr reales Problem zu beschreiben, leisten jedoch einen unglaublich schlechten Job, indem sie die Auswirkungen und die Bedarfsanalyse erklären.

Es ist jetzt effektiver, ein System durch die Verwendung eines Hash eines Kennworts oder eines vorhandenen Tokens zu gefährden. Einfach ausgedrückt, Ihr Angreifer benötigt Ihren Benutzernamen und Ihr Passwort nicht mehr. Es gibt jetzt einfachere Möglichkeiten, ein System anzugreifen. Unter keinen Umständen sollten Sie davon ausgehen oder daraus schließen, dass diese Art von Angriff unwahrscheinlich ist. Hash-Angriffe sind jetzt der defacto-Angriffsvektor .

Hash-Angriffe sind mit Smartcard-Konten tatsächlich schlimmer, was ironisch ist, da die meisten Leute erwarten, dass die Implementierung von Smartcards die Sicherheit eines Systems erhöhen würde.

Wenn ein Konto aufgrund eines Pass-the-Hash-Angriffs kompromittiert wird, besteht die übliche Reaktion darin, das Kennwort des Kontos zu ändern. Dadurch wird der zur Authentifizierung verwendete Hash geändert. Auch ein normaler Ablauf / eine normale Änderung des Kennworts kann einen Einbruch zur Folge haben, da der Hash des Angreifers zu scheitern beginnt. Bei Smartcards wird das Kennwort jedoch vom System verwaltet (der Benutzer gibt das Kennwort niemals zur Authentifizierung ein), sodass sich der Hash niemals ändert. Dies bedeutet, dass bei Smartcard-Konten ein Einbruch möglicherweise viel länger unbemerkt bleibt als bei einem Konto, das ein Kennwort verwendet.

Ich würde folgende Abhilfemaßnahmen in Betracht ziehen:

• Ändern Sie bei Smartcard-fähigen Konten, die viele große Unternehmen für besonders privilegierte Konten verwenden, das Kennwort des Kontos in regelmäßigen Abständen. Dies ändert den Hash. Sie können den Hash auch ändern, indem Sie die Smartcard deaktivieren, um das Konto zu aktivieren, und dann die Smartcard erneut aktivieren. Microsoft führt dies alle 24 Stunden durch. Sie müssen jedoch die potenziellen Auswirkungen bewerten, die dies in Ihrer Umgebung verursachen kann, und einen vernünftigen Zeitplan erstellen, damit Sie keine zusätzlichen Probleme verursachen.

• Auf Workstations würde ich Domänenkonten nach Möglichkeit überhaupt nicht für Verwaltungszwecke verwenden. Wir haben ein lokales Konto, das zur Erhöhung für Operationen vom Typ UAC verwendet werden kann. Dies entspricht 99,9% der meisten Höhenanforderungen. Workstations sind aufgrund der fehlenden Änderungskontrolle und der Existenz von Java JRE und Flash in der Regel Hot-Attack-Vektoren.

  Dieser Ansatz funktioniert für uns, da wir über einen formalen Mechanismus zum Verwalten und Erzwingen des Kennworts für die lokalen Konten verfügen und das Kennwort auf jedem System eindeutig ist und eine sichere Methode zum Anfordern des Kennworts vorhanden ist. Es gibt auch kommerzielle Anwendungen, die diese Funktion ausführen können.

• Wenn Sie keine lokale Kontolösung für Arbeitsstationen bereitstellen können, sollte ein separates Domänenkonto für den Administratorzugriff auf Arbeitsstationen verwendet werden, und dieses Konto sollte nicht für den Administratorzugriff auf Server verwendet werden. Eine weitere Möglichkeit besteht darin, nicht interaktive Remote-Support-Verwaltungstools zu verwenden, die LocalSystem zum Ausführen von Aktivitäten verwenden, sowie einen von Windows getrennten Authentifizierungsmechanismus.

• Verwenden Sie für die Konten mit den höchsten Berechtigungen (Unternehmensadministrator, Domänenadministrator usw.) nur einen Jump-Server. Dieser Server unterliegt den strengsten Sicherheits-, Änderungs- und Überwachungsbestimmungen. Für alle anderen Funktionen des Typs "Administrator" sollten Sie ein separates Administratorkonto in Betracht ziehen. Der Jump-Server sollte täglich neu gestartet werden, um die Prozesstoken aus dem LSA-Prozess zu löschen.

• Führen Sie keine administrativen Aufgaben von Ihrer Workstation aus. Verwenden Sie einen gehärteten Server oder einen Jump-Server.

• Ziehen Sie in Betracht, einfach zurückgesetzte VMs als Jump-Box zu verwenden, die nach jeder Sitzung zurückgesetzt werden können, um den Speicher zu leeren.

Weitere Lektüre:

https://blogs.technet.com/b/security/archive/2012/12/06/new-guidance-to-mitigate-determined-adversaries-favorite-attack-pass-the-hash.aspx

Microsoft Security Intelligence Report, Band 13, Januar - Juni 2012
http://www.microsoft.com/security/sir/archive/default.aspx

Lesen Sie den Abschnitt "Verteidigung gegen Pass-the-Hash-Angriffe".

Besiege gefürchtete Pass-the-Hash-Angriffe
https://www.infoworld.com/d/security/defeat-dreaded-pass-the-hash-attacks-179753