Secure Score Quick Wins: risikoarme Massnahmen per PowerShell

Secure Score bleibt rot

Fünf Empfehlungen prüfen

Foto: geralt / Pixabay

Rot trotz sauberer Policy: Fünf Empfehlungen im Secure Score bleiben gern offen. Ein Prüfskript zeigt, welche Policy sie festhält, ein zweites setzt nur die ungefährlichen Änderungen.

Das Wichtigste in Kürze

• Der Secure Score bewertet alle aktiven Policies. Dazu zählen auch Default- und Built-in-Policies, die du nie angefasst hast.
• Zuerst prüfen, dann ändern. Ein lesendes Skript listet pro Policy, was offen ist.
• Nur Massnahmen mit geringem Betriebsrisiko setzt du sofort. Allowlists leeren kann dagegen legitimen Mailfluss brechen.
• Jede Änderung ist protokolliert. Der Stand vorher und nachher belegt das Ergebnis im Abschlussbericht.

Warum der Secure Score eine Empfehlung rot lässt

Du hast die Anti-Phishing-Policy sauber eingestellt, und trotzdem zeigt der Secure Score die Empfehlung „Quarantine messages from impersonated users“ als offen. Der Grund liegt in der Bewertung. Der Secure Score prüft jede aktive Policy, also auch die Default-Policy, die nie jemand bearbeitet hat. Erfüllt eine einzige den Wert nicht, bleibt die Empfehlung offen.

Dazu kommt ein zweites Problem. Manche Quick Wins greifen in den Mailfluss ein. Wer Allowed Sender Domains oder IP-Allowlists leert, riskiert, dass Mails von Partnern oder Systemen plötzlich in der Quarantäne landen. Ohne Inventar fehlt zudem die Grundlage für Planung und Abschlussbericht.

Deshalb trennt der Ansatz zwei Klassen. Massnahmen mit Betriebsrisiko Gering setzt du direkt um. Massnahmen mit Risiko Mittel gehen nur nach Absprache und mit einem Inventar der Versandquellen.

Das Toolkit im Überblick

Das Inventar nutzt die Graph-Ressource für den Secure Score. Mit dem Schalter -Deep liest es zusätzlich Conditional Access, Lizenzen, Consent, Intune und Exchange.

Die fünf hängenden Empfehlungen finden

Das Prüfskript läuft lesend und braucht eine Verbindung zu Exchange Online. Pro Policy bewertet es die Empfehlungen und gibt jeweils OK oder OFFEN aus.

foreach ($p in Get-AntiPhishPolicy) {
    $ok = $p.EnableTargetedUserProtection -and $p.TargetedUserProtectionAction -eq 'Quarantine'
    Add-Row 'Impersonation -> Quarantine' $p.Name $ok $p.TargetedUserProtectionAction
}
foreach ($p in Get-HostedContentFilterPolicy) {
    Add-Row 'High confidence spam -> Quarantine' $p.Name ($p.HighConfidenceSpamAction -eq 'Quarantine') $p.HighConfidenceSpamAction
    $allowed = @($p.AllowedSenderDomains).Count + @($p.AllowedSenders).Count
    Add-Row 'Keine Allowed Senders/Domains' $p.Name ($allowed -eq 0) "$allowed Einträge"
}
foreach ($p in Get-SafeLinksPolicy -ErrorAction SilentlyContinue) {
    Add-Row 'Safe Links for Office' $p.Name ([bool]$p.EnableSafeLinksForOffice) $p.EnableSafeLinksForOffice
}
foreach ($p in Get-HostedOutboundSpamFilterPolicy) {
    Add-Row 'Block users at message limit' $p.Name ($p.ActionWhenThresholdReached -eq 'BlockUser') $p.ActionWhenThresholdReached
}

Die Ausgabe zeigt dir, welche Policy eine Empfehlung festhält. Häufig ist es eine Preset- oder Default-Policy, die du nie bewusst angesehen hast. Welche Policies es gibt und wie sie zusammenspielen, erklärt Microsoft bei den Preset Security Policies.

Quick Wins setzen, mit Trockenlauf

Das zweite Skript ändert nur Massnahmen mit geringem Risiko:

• Impersonation-Treffer gehen in die Quarantäne.
• High-Confidence-Spam und -Phish gehen in die Quarantäne.
• Safe Links for Office wird aktiviert. Existiert keine Policy, legt das Skript eine an.
• Ausgehend wird ein Benutzer beim Erreichen des Limits blockiert (BlockUser).

Ein Kniff macht das Skript robust: Es filtert seine Wunschparameter gegen (Get-Command Set-…).Parameters. Kennt das Cmdlet einen Parameter nicht, etwa wegen eines alten Moduls oder fehlender Lizenz, gibt es eine Warnung statt eines Abbruchs.

function Get-SupportedParams {
    param([string]$CommandName, [hashtable]$Desired)
    $known = (Get-Command -Name $CommandName).Parameters
    $out = @{}
    foreach ($k in $Desired.Keys) {
        if ($known.ContainsKey($k)) { $out[$k] = $Desired[$k] }
        else { Write-Warning "$CommandName kennt '$k' nicht, übersprungen." }
    }
    $out
}

Jede Änderung läuft durch eine Funktion, die den Wert vorher und nachher ausgibt. Mit -WhatIf siehst du zuerst, was passieren würde. Am Ende erinnert das Skript an das, was es bewusst nicht anfasst: AllowedSenderDomains und IPAllowList.

Ablauf in sieben Schritten

1. Inventar vorher: Secure Score und Defender-Stand mit -Deep erfassen.
2. Hängende Empfehlungen prüfen: Mit Connect-ExchangeOnline verbinden und den Report in eine Datei schreiben.
3. Entscheiden: Nur Gering oder auch Mittel? Das klärst du mit dem Kunden.
4. Trockenlauf: Das Setz-Skript mit -WhatIf starten.
5. Umsetzen: Ohne -WhatIf laufen lassen und die Ausgabe ablegen.
6. Nach einem bis drei Tagen: Die Quarantäne auf Fehlalarme prüfen und die Quarantäne-Admins einweisen.
7. Nach 24 bis 48 Stunden: Den Score erneut inventarisieren und dokumentieren.

Der Score aktualisiert sich mit Verzögerung von bis zu 48 Stunden. Wer sofort nach dem Umsetzen misst, sieht noch den alten Wert.

Voraussetzungen und Rechte

Du brauchst Windows PowerShell 5.1 und das Modul ExchangeOnlineManagement. Safe Links und der Impersonation-Schutz setzen Defender for Office 365 Plan 1 voraus, etwa in Microsoft 365 Business Premium. Die Rolle Exchange- oder Security-Administrator genügt. Für die Quarantäne verbindest du dich zusätzlich mit Connect-IPPSSession.

Für das Inventar meldest du dich bei der Azure CLI an. Es braucht das Graph-Recht SecurityEvents.Read.All. Mit -Deep kommen Policy.Read.All, Directory.Read.All und DeviceManagementConfiguration.Read.All dazu. Die Beispielskripte tragen oben einen Konfigurationsblock. Fehlt die Admin-UPN, fragt das Skript danach. Im Lab genügt [email protected].

Typische Stolpersteine

Grenzen

Customer Lockbox bleibt unangetastet. Identity- und Device-Massnahmen wie Conditional Access oder Intune werden nur inventarisiert, nicht gesetzt. Die Mittel-Massnahmen brauchen eine Freigabe und ein Inventar der Versandquellen. Die Skripte hier sind gekürzte Beispiele und gehören vor dem Einsatz in ein Testlab. Passe ausserdem die Namen deiner Anti-Phishing-Policies an.

Einordnung: Was das für Microsoft-365-Admins und MSPs heisst

Der Secure Score ist ein Gradmesser, kein Ziel. Wer ihn mit Skripten anhebt, sollte jeden Schritt belegen können. Die Aufteilung nach Betriebsrisiko schützt dich vor dem klassischen Fehler, bei dem eine geleerte Allowlist den Mailfluss eines Kunden stört. Für MSPs lohnt sich das Muster doppelt: Das Prüfskript wiederholst du bei jedem Kunden, und das Protokoll ersetzt den manuellen Abschlussbericht. Aufbauend auf einer sauberen Mailauthentifizierung gewinnst du so Punkte, ohne den Betrieb zu riskieren. Die Anti-Phishing-Dokumentation hilft bei der Wahl der Werte.

Fazit

Ein roter Punkt im Secure Score hat meist eine vergessene Policy als Ursache. Ein lesendes Prüfskript findet sie in Minuten. Mit Trockenlauf, Vorher-Nachher-Protokoll und klarer Trennung nach Risiko hebst du den Score an, ohne den Mailfluss zu gefährden. Teste die Beispiele zuerst in einem Lab und plane die Quarantäne-Kontrolle fest ein.

Geschrieben von Andreas Brauckmann · So arbeitet die Redaktion