M365-Assessment: Wo Tenants wirklich verwundbar sind

Microsoft 365 ist in den meisten Unternehmen der grösste einzelne Angriffsvektor: Identitäten, E-Mail, Dateien und Kollaboration laufen in einem Tenant zusammen. Entsprechend lohnend ist ein strukturiertes Assessment — und entsprechend ähnlich sehen sich die Befunde.

Kurz gesagt: Ein Microsoft-365-Security-Assessment prüft die Konfiguration eines Tenants systematisch gegen bekannte Angriffspfade — Identitäten, Zugriffsregeln, E-Mail-Schutz, Freigaben und Logging. Es ist kein Penetrationstest und kein Produktverkauf, sondern eine priorisierte Liste der Lücken, die ein Angreifer nach dem ersten Phishing-Klick tatsächlich nutzen würde.

Was geprüft wird

Ein Assessment arbeitet sich durch die Ebenen des Tenants:

• Identitäten (Entra ID): MFA-Abdeckung — wirklich für alle, auch Admins und Service-Konten? Conditional-Access-Regeln, privilegierte Rollen, Gäste-Konten.
• Legacy-Authentifizierung: alte Protokolle wie IMAP oder SMTP-Auth, die MFA schlicht umgehen — der Klassiker unter den offenen Türen. Microsofts eigene Telemetrie zeigt seit Jahren, dass ein Grossteil der Password-Spray-Angriffe über Legacy-Protokolle läuft.
• E-Mail-Sicherheit: Anti-Phishing-Richtlinien, Weiterleitungsregeln (ein beliebtes Persistenz-Werkzeug nach Konto-Übernahmen), SPF/DKIM/ DMARC der eigenen Domains.
• Freigaben: SharePoint- und OneDrive-Einstellungen — was darf anonym, was organisationsweit geteilt werden?
• Defender-Konfiguration und Logging: Sind die Signale, die man im Ernstfall braucht, überhaupt eingeschaltet und lang genug aufbewahrt?

Identität, Kommunikation, Daten: Jede Ebene hat eigene Kontrollen — und der eine übersehene Punkt liegt fast immer auf der Identitätsebene.

Wie ein Assessment abläuft

Ein sauberes Assessment braucht keinen Eingriff in den Betrieb. Der Ablauf, den ich für sinnvoll halte:

1. Scope klären. Welche Tenants, welche Domains, welche Lizenzen? Ein Tenant mit Business Premium hat andere Möglichkeiten als einer mit E5 — und andere Ausreden.
2. Lesenden Zugriff einrichten. Eine Rolle wie Global Reader oder Security Reader genügt für fast alle Prüfungen. Niemand braucht Global Admin, um zu lesen.
3. Automatisiert erheben. Werkzeuge wie Maester oder ScubaGear (dazu unten mehr) liefern in Minuten hunderte Prüfpunkte mit Beleg. Das ist die Faktenbasis — nicht das Ergebnis.
4. Manuell einordnen. Jede Abweichung wird gegen den konkreten Kontext gelesen: Ist die Legacy-Auth-Ausnahme für den Scanner wirklich nötig? Gibt es eine kompensierende Kontrolle?
5. Priorisieren und nachtesten. Das Resultat ist eine Liste nach Angriffsrelevanz, nicht nach Alphabet — und nach der Umsetzung läuft dieselbe Prüfung nochmals, damit «behoben» belegt ist.

Für einen Tenant mittlerer Grösse ist das ein Aufwand von zwei bis vier Arbeitstagen, die Umsetzung der Befunde nicht eingerechnet. Der Bericht sollte für die Geschäftsleitung auf einer Seite lesbar sein und für die IT auf zwanzig — beides aus denselben Daten. Ein Bericht, den nur die IT versteht, verändert kein Budget.

Die üblichen Verdächtigen

Nach einigen Assessments wiederholen sich die Muster. Die Befunde, die fast immer auftauchen:

• MFA gilt «für alle» — ausser für die drei ältesten Admin-Konten oder ein paar Service-Accounts, die «sonst nicht funktionieren».
• Legacy-Auth ist «deaktiviert» — bis auf die eine Ausnahme für den Multifunktionsdrucker, die den ganzen Tenant offenlässt.
• Conditional Access existiert, aber als gewachsene Sammlung von Einzelregeln mit Lücken dazwischen — und niemand weiss mehr, warum Regel sieben eine Ausnahme für die Geschäftsleitung hat.
• Die Break-Glass-Konten haben seit Jahren dasselbe Passwort und niemand überwacht ihre Anmeldungen.
• Mehr Global Admins als nötig, oft mit ihrem Alltagskonto — jeder davon ist ein direkter Weg zur vollständigen Übernahme.
• Benutzer dürfen beliebigen Apps Zugriff auf ihre Daten erteilen (App Consent) — Phishing über OAuth-Apps braucht dann nicht einmal ein Passwort.
• Gastkonten aus Projekten vor drei Jahren sind noch aktiv.
• Das Audit-Log ist eingeschaltet, aber niemand hat je hineingeschaut.

Der Punkt ist nicht, dass diese Dinge exotisch wären. Der Punkt ist, dass sie in fast jedem Tenant gleichzeitig vorkommen — und ein Angreifer nur einen davon braucht.

Welche Lizenz welche Kontrolle erlaubt

Viele Befunde haben dieselbe Ursache: Die Einstellung wäre da, aber die Lizenz fehlt — oder sie ist da und niemand weiss es. Die Kurzform:

• Business Basic / Standard: nur Security Defaults (MFA für alle, Legacy-Auth blockiert), keine Conditional-Access-Regeln.
• Business Premium / E3: Entra ID P1 — Conditional Access, Authentifizierungsstärken, Gerätebedingungen; Defender for Office P1 mit Safe Links und Safe Attachments; Intune.
• E5 / Entra ID P2: dazu risikobasierte Richtlinien (Identity Protection), Privileged Identity Management für zeitlich begrenzte Admin-Rechte, Access Reviews für Gäste.

Ein Assessment prüft deshalb nicht nur «ist die Einstellung gesetzt?», sondern auch «ist das Beste, was diese Lizenz hergibt, ausgeschöpft?». Erstaunlich oft ist Business Premium vorhanden und wird wie Business Standard betrieben.

Womit man prüft

Man muss das nicht von Hand tun. Neben dem eingebauten Secure Score gibt es inzwischen sehr gute freie Werkzeuge: Maester bündelt mehrere Prüfkataloge (EIDSCA, CISA ScuBA, CIS) in einem PowerShell-Testframework auf Pester-Basis. Jeder Test hat eine Erklärung, einen Schweregrad und einen Link zur Einstellung — und weil es Tests sind, lassen sie sich als Pipeline wiederkehrend ausführen. Härtung wird damit testbar wie Code: Ändert jemand eine Conditional-Access-Regel, schlägt der Test am nächsten Morgen an. CISAs ScubaGear prüft den Tenant gegen die amerikanischen Baseline-Vorgaben und erzeugt einen Bericht pro Dienst (Entra, Exchange, SharePoint, Teams, Defender). Beide liefern konkrete, nachvollziehbare Befunde statt eines abstrakten Scores.

Warum Secure Score nicht genügt

Microsofts Secure Score ist ein brauchbarer Einstieg, aber er bewertet Konfigurationen, nicht Angriffspfade. Ein Tenant mit ordentlichem Score kann trotzdem eine triviale Eskalation von einem kompromittierten Benutzerkonto zu globalen Admin-Rechten offenlassen. Dazu kommt: Der Score belohnt teils Einstellungen, die Lizenzen voraussetzen, die das Unternehmen gar nicht hat, und gewichtet Punkte nach Microsofts Massstab, nicht nach dem eigenen Risiko. Ein Assessment denkt vom Angriff her: Was passiert nach dem ersten Phishing-Klick? Wie so ein Klick zustande kommt, zeigt die Phishing-Simulation an acht realistischen Beispielen.

Der Score bewertet Punkte, der Angreifer sucht Pfade: Vom ersten kompromittierten Konto führt oft eine kurze Kette bis zu den höchsten Rechten.

Zehn Massnahmen mit der grössten Wirkung

Wenn ich priorisieren müsste — und in Assessments muss man das —, sähe die Liste so aus:

1. Phishing-resistente MFA für alle Admin-Rollen
2. Legacy-Authentifizierung per Conditional Access blockieren
3. Zwei Break-Glass-Konten: lange Passphrasen, von CA ausgenommen, Anmeldungen alarmiert
4. Conditional-Access-Baseline: MFA für alle Benutzer, Block bei hohem Anmelderisiko
5. Externe Auto-Weiterleitungen deaktivieren
6. SPF, DKIM und DMARC für alle eigenen Domains
7. Anonyme Freigaben und Gastzugriff bewusst einschränken
8. Privilegierte Rollen aufräumen — so wenige Global Admins wie möglich
9. Audit-Logging aktivieren und Aufbewahrung prüfen
10. Wiederkehrend testen statt einmalig härten — z. B. mit Maester automatisiert

Nichts davon ist exotisch, das meiste kostet keine Lizenz — nur Sorgfalt. Genau deshalb sind es die Punkte, an denen sich in fast jedem Tenant zuerst etwas gewinnen lässt. Wie die einzelnen Einstellungen konkret aussehen — mit Portal-Pfad, Lizenzbedarf und Fallstricken —, steht in Microsoft 365 härten: 12 Einstellungen.

Was ein Assessment nicht leistet

Ehrlichkeit gehört dazu: Ein Konfigurations-Assessment findet keine kompromittierten Konten — dafür braucht es Log-Analyse und Threat Hunting. Es bewertet keine Endgeräte, auf denen der Tenant genutzt wird; ein ungepatchter Laptop mit gültigem Token ist ein Problem, das in Entra ID nicht sichtbar ist. Und es ersetzt keinen Prozess: Der schönste Bericht nützt nichts, wenn die Befunde ein Jahr später unverändert im Ordner liegen.

Wer die Befunde danach als Massnahmen nachverfolgen will, statt sie in einer Tabelle zu verlieren, findet in CISO Assistant ein passendes Open-Source-Werkzeug. Und wie viel Budget Security insgesamt braucht, zeigt der Security-Budget-Check als Richtwert für Schweizer Unternehmen.