[SD] Security Admin Best practices (Update 1)

Hier ein paar Tipps um eure Adminaccounts besser zu schützen [bzw. natürlich um euch Bestätigung zu geben, dass ihr heute schon das Richtige macht! 😉 ] Das wird natürlich keine vollständige Liste mit best practices, aber es gibt euch eine Idee, was ihr „mindestens“ tun solltet, um eure Adminaccounts zu schützen.

Dieser Post ist Teil der Security Demopalooza, in der ich #Security Themen
adressiere, die in meiner täglichen Arbeit oft/öfter gefragt werden. Für eine Liste der bisher behandelten Themen besuche einfach die
Übersichtsseite der Security Demopalooza.

Agenda:

  1. Persönlicher vs. universeller Adminaccount
  2. Priviledged Identity Management (PIM)
  3. Einführung einer PAW/SAW

Persönlicher vs. universeller Adminaccount

In unseren Events und auch 1:1 Unterhaltungen sprechen wir nie davon, dass spezielle Accounts für die Administration verwendet werden (sollen), also z.B. sowas wie „Exchange Admin1“, die von einer Admin „Erika Mustermann“ genutzt werden um eben Exchange zu administrieren.

Das ist kein Zufall oder Versehen!

Insb. aus Compliance Gründen, also z.B. der Nachweisbarkeit von strafbaren Handlungen ist es aus unserer Sicht sinnvoll eindeutige Identitäten zu verwenden, denn nur so kann ich mit einer großen Wahrscheinlichkeit nachweisen, dass Erika auch diejenige war, die die Mails vom Chef gelöscht hat.

Dies ist mit einem geteilten Account nicht möglich (bzw. sehr schwierig, insb. wenn Erika clever genug ist ihre Spuren zu verwischen)!!!

Und viel wichtiger noch aus einem anderen Grund sollten die tatsächlichen Useridentitäten verwendet werden:
Wenn ein Admin für die Exchange Administration immer den speziellen Account nutzt, wird es deutlich schwieriger zu identifizieren, ob der Mensch vor dem Bildschirm auch wirklich derjenige ist, den wir erwarten -> sprich unsere Erika ist und nicht etwa der Angreifer John Doe!

D.h. aus „Identity Protection“ Sicht (vgl. insb. meinen Blogpost zu #gopasswordless) ist es deutlich sinnvoller, wenn der Account nicht gewechselt wird, denn nur so kann die AI sicherstellen, dass der Account nicht kompromittiert ist. (Multi-Account User Nutzung führt zu verwässerten Daten und ist damit nicht hilfreich!)

Es spricht auch nichts dagegen [bzw. ist die Empfehlung für größere Organisationen] dedizierte, aber personalisierte (!) Admin Accounts für die Administration zu nutzen, siehe unten.

Und noch viel sinnvoller ist es dazu dann auch noch das Thema „Priviledged Identity Management“ (PIM) zu verwenden, um die Angriffsfläche deutlich zu verringern:

„Priviledged Identity Management“ (PIM)

Laut der Hans Böcklerstiftung ist die durchschnittliche Jahresarbeitszeit
1.658,7 Stunden
. Ein Jahr hat allerdings 8760 Stunden – also mehr als 5 mal so viele.
D.h., dass ein „normaler“ Account nur zu 1/5 der Zeit genutzt wird und den Rest der Zeit als „wehrloses Ziel“ Angreifern zur Verfügung steht.

Für mein Dafürhalten sind das genau 4/5 zu viel! [für die Mathematiker unter euch sollten es natürlich 5/5 des Rests sein, aber … 😉 ]

Die Frage ist nur: „ja, ähm, und, hm, was heißt das jetzt für mich?“

Hierzu gibt es verschiedene Ansätze. Ich präferiere den folgenden:
Einführen und Nutzen von zeitbasierter Rollennutzung, aka „Priviledged Identity Management„. Das sieht dann ungefähr so aus:

  1. Für „seltene“ Tätigkeiten, also Tätigkeiten, die nicht über den Tag „dauernd“ durchgeführt werden: Die Rechte um diese Tätigkeiten auszuführen sollten nur dann angefordert und ggf. genehmigt werden, wenn diese auch wirklich benötigt werden, z.B. im Kontext eines Support Tickets. Die Dauer der Genehmigung darf nicht länger als die eines Arbeitstages sein.
Screenshot: PIM Role settings for "Compliance Admin" showing settings for approval process, requiring a ticket and having only a short period of activation time
  1. Für „Standardtätigkeiten“, z.B. wenn Erika den ganzen Tag (oder zumindest einen Großteil) in den Tiefen des Exchangeservers arbeitet: Morgens ist die erste Tätigkeit, die Erika ausführt die, dass sie sich „anmeldet“, sprich per Klick sagt, dass sie jetzt anfängt zu arbeiten und ihr damit die Rolle des Exchange-Admins für 9h (also 8h+Pause+Overlap, bitte entsprechend auf die eigene Situation anpassen) ohne Freigabeprozess zugewiesen wird. Sollte sie aus welchen Gründen auch immer (z.B. Eskalation) die Rechte länger benötigen, so kann sie sich nach Ablauf der Zeit eine Verlängerung beantragen, sollte diese dann aber wieder „abgeben“, sobald sie die Arbeit beendet.
Screenshot: PIM Role settings for "Exchange Admin" showing standard settings

Die Vorteile einer solchen Vorgehensweise liegen auf der Hand:

  1. Die Angriffsfläche für Admin Accounts wird deutlich (um 4/5) reduziert
  2. Es ist immer nachweisbar wann wer welchen Zugriff auf Systeme und damit Daten hat(te), Stw. #compliance & #gdpr #dsgvo
  3. Kompromitierte Accounts haben keine standing-admin-rights und sind damit eine größere Herausforderung (insb. in Kombination mit „Identity Protection„) für Angreifer und tragen damit zu einer deutlich schnelleren Detektion und Abwehr bei

Hier noch eine Liste mit spannenden Ignite Videos zu dem Thema:

Protect the keys to your kingdom with Privileged Identity Management – BRK3248
Control and protect your data through privileged access management capabilities in – BRK3222

Das Thema PIM kann man natürlich automatisierien, am Einfachsten über den Microsoft Graph:

Im Bild der Graph Explorer mit dem aktivieren der Exchange Admin Rolle. Dies lässt sich z.B. über Powershell oder ein passendes Webfrontend automatisieren.

Einführung einer PAW/SAW

Oftmals werden – vor allem aus Bequemlichkeit – administrative Tätigkeiten von der „eigenen“ Maschine aus ausgeführt. In etwas weiter entwickelten Umgebungen auch schon mal über eine lokal oder zentral bereitgestellte VM oder Jump-Server.
Nur, diese Herangehensweise mitigiert nur selten die aktuellen Bedrohungen, die eindeutig über Identity Theft kommen. Und es ist i.d.R. einfacher von diesen VMs/Servers zurück auf die (nicht geschützte) Admin Maschine zu kommen.

Eine Privileged Admin Workstation (PAW) oder Secured Admin Workstation geht einen etwas anderen Weg, kurz hier, sonst für die längere Story die offizielle Dokumentation konsultieren:

  1. Der Admin erhält eine stark gehärtete Maschine, auf der eigentlich gar nichts möglich ist, außer sich mittels SmartCard anzumelden und Shielded VMs zu starten
  2. Der Admin hat die Möglichkeit eine „User VM“ zu starten, mit der er „normale Usertätigkeiten“ ausführt.
  3. Der Admin hat die Möglichkeit eine „Admin VM“ zu starten, mit der er seine Admin Tätigkeiten mit extra Service Admin Accounts ausführen kann, und nur diese!

Da das Erstellen und Verwalten von PAWs mit deutlichem Aufwand versehen ist, ist das eher eine Empfehlung für größere IT Organisationen.

Und, wer die Doku gelesen hat, der wird festgestellt haben, dass die Verwendung von PAWs gegen meine erste Best Practice verstößt, denn für die korrekte Nutzung werden eigene Service Admin Accounts (über PIM) benötigt.
Das widerspricht sich nur auf den ersten Blick. Wenn ich die Möglichkeit habe PAWs zu verwenden – und demnach entsprechende IT Resourcen verfügbar sind – dann kann ich auf die o.g. Identity Protection Gewinne verzichten, denn die Accounts sind zusätzlich überwacht und mit deutlich größeren Securityanforderungen gesegnet, als es bei kleineren Organisationen typischer Weise der Fall ist.

Auch hier wie immer der Aufruf: du/ihr seid managed Microsoft Partner und wollt in das Thema stärker hineingehen? Dann sprecht uns an und lasst uns gemeinsam gewinnen!

Weiterführende Links:


Beitrag veröffentlicht

in

, ,

von

Kommentare

Eine Antwort zu „[SD] Security Admin Best practices (Update 1)“

  1. […] PAW/SAWs – muss ich glaub ich nicht wirklich erklären warum […]