ANOMAL Service

Cloud- und Identity-Hardening: die häufigsten Fehlkonfigurationen schliessen

ANOMAL prüft Microsoft 365, Entra ID, Azure und AWS gegen CIS-Benchmarks und Hersteller-Baselines, mit Schwerpunkt auf Identität: Conditional Access, MFA, privilegierte Zugriffe, Session- und Token-Kontrollen sowie Legacy-Auth. Aus den Findings entsteht ein priorisierter Umsetzungsplan, den wir gemeinsam mit Ihrer IT abarbeiten. Die gehärtete Baseline wird anschliessend zur Erkennungsbasis für das SOC, sodass Abweichungen zu Alarmen werden.

Security ServicesAlleCloud- und Identity-Hardening: die häufigsten Fehlkonfigurationen schliessen

Warum Standard-Konfigurationen nicht reichen

Die meisten erfolgreichen Angriffe auf Cloud- und M365-Umgebungen nutzen keine Zero-Days, sondern Fehlkonfigurationen: fehlende MFA-Durchsetzung, zu breite Admin-Rollen, unbeschränkte Legacy-Protokolle, App-Consent ohne Prüfung. Cloud- und Identity-Hardening ist ein Projekt-Service, der diese Lücken systematisch findet und schliesst, bevor sie zu einem Business Email Compromise oder Token-Diebstahl führen.

Konfigurationsreview gegen CIS-Benchmarks

Microsoft 365 und Entra ID: Tenant-Einstellungen, Sicherheitsdefaults, administrative Rollen, Gastzugriffe.
Azure: Ressourcen-, Netzwerk- und Identitätskonfiguration gegen CIS-Benchmark und Herstellervorgaben.
AWS: IAM-Policies, Root-Account-Schutz, Logging und Netzwerkgrenzen gegen CIS-Benchmark.
Abgleich gegen Hersteller-Baselines, wo diese über CIS hinausgehen.

Identity-first: der eigentliche Kern des Hardenings

Conditional-Access-Design und -Test: Richtlinien, die Gerätezustand, Standort und Risiko kombinieren. Einzelne isolierte Regeln reichen nicht.
MFA-Durchsetzung mit phishing-resistenten Methoden. SMS- oder Push-Bestätigung allein genügt nicht.
Privilegierter Zugriff und Just-in-Time-Rollen, ohne dauerhaft aktive Admin-Rechte, orientiert an gängigen PAM-Prinzipien.
Session- und Token-Kontrollen: Lebensdauer, Bindung an Gerät/Netz, Widerruf bei Risikosignalen.
Abschaltung von Legacy-Auth-Protokollen und Review von App-Consent-Berechtigungen.

Diese Massnahmen zielen direkt auf die zwei häufigsten Bedrohungsmodelle in M365- und Cloud-Umgebungen: Token-Diebstahl und Session-Hijacking sowie Business Email Compromise.

Priorisierter Umsetzungsplan mit Ihrer IT

Aus dem Review entsteht ein priorisierter Plan nach Risiko und Umsetzungsaufwand. Die Umsetzung erfolgt gemeinsam mit Ihrer IT; ANOMAL begleitet fachlich und prüft die Wirkung jeder Änderung. Governance-Fragen rund um Rollen und Verantwortlichkeiten können optional in einer kurzen Begleitung mitgedacht werden.

Von der Baseline zur Erkennung im SOC

Die gehärtete Konfiguration wird dokumentiert und als Referenz an das SOC as a Service Schweiz übergeben. Abweichungen von dieser Baseline, etwa eine neu aktivierte Legacy-Auth-Methode oder eine unerwartet erweiterte Admin-Rolle, werden dadurch zu Alarmen statt zu unbemerkten Drifts. Für M365-Umgebungen läuft dies konkret über SOC Microsoft 365 Sentinel; für Identitätsangriffe generell über ITDR.

Abgrenzung zu Nachbarthemen

Angebot	Fokus	Ergebnis
Cloud- und Identity-Hardening	Konkrete Konfiguration in M365, Entra ID, Azure, AWS gegen CIS-Benchmarks.	Umgesetzte, verifizierte Härtung plus SOC-Detection-Baseline.
Zero-Trust- und NIST-Beratung	Architektur und Roadmap über mehrere Jahre.	Strategisches Zielbild, nicht die einzelne Konfigurationsänderung.
Vulnerability Management	Bekannte CVEs in Systemen und Software.	Laufender Patch- und Remediation-Zyklus, siehe Vulnerability Management Schweiz.
Managed ITDR / SOC-Detection	Laufender Betrieb: Erkennung von Angriffen auf Identitäten in Echtzeit.	24/7-Alarmierung auf Basis der gehärteten Baseline, siehe ITDR.

Häufige Fragen

Ist das ein einmaliges Projekt oder ein laufender Service?

Cloud- und Identity-Hardening ist ein Projekt: Review, priorisierter Plan, gemeinsame Umsetzung. Der laufende Schutz danach erfolgt über den [SOC as a Service Schweiz](/de/soc/soc-as-a-service-schweiz), der Abweichungen von der gehärteten Baseline erkennt.

Welche Umgebungen werden abgedeckt?

Microsoft 365, Entra ID, Azure und AWS. Umfang und Tiefe je Umgebung werden im Scoping festgelegt.

Wie unterscheidet sich das von Zero-Trust-Beratung?

Hardening liefert konkrete, umgesetzte Konfigurationsänderungen. Zero-Trust- und NIST-Beratung entwickelt das übergeordnete Architektur- und Roadmap-Bild, in das diese Änderungen eingebettet sind.

Setzt ANOMAL die Änderungen selbst um?

Die Umsetzung erfolgt gemeinsam mit Ihrer IT. ANOMAL priorisiert, begleitet fachlich und prüft die Wirkung jeder Änderung.

Was kostet Cloud- und Identity-Hardening?

Der Aufwand hängt von Anzahl Umgebungen und Ausgangslage ab und wird pro Kunde einzeln offeriert. Kostenkontext zum SOC generell steht auf [Was kostet ein SOC](/de/soc/was-kostet-ein-soc-schweiz).

Weiterlesen im Cluster

ITDR: Identity Threat Detection and Response für die Schweiz

ITDR (Identity Threat Detection and Response) erkennt Angriffe auf Identitäten selbst, nicht nur auf Endpoints oder Netzwerke. Ziel sind Konten, Tokens, Sessions, Berechtigungen und Identity-Provider wie Entra ID oder Okta. ITDR erweitert EDR und SIEM um Signale, die nur im Identity-Layer sichtbar sind: Impossible Travel, Consent-Phishing, Refresh-Token-Missbrauch, Rollen-Missbrauch, Angriffe auf Federation und Directory-Objekte. Für Schweizer Unternehmen mit M365, Entra ID und regulierten Prozessen ist ITDR heute so wichtig wie EDR vor fünf Jahren.

Token-Diebstahl und Session-Hijacking erkennen und stoppen

Token-Diebstahl bedeutet, dass Angreifer den Session- oder Refresh-Token eines bereits authentifizierten Nutzers stehlen und damit MFA umgehen. Der klassische Weg ist Reverse-Proxy-Phishing (Adversary-in-the-Middle), zunehmend auch Info-Stealer auf dem Endpoint. Ein SOC erkennt das über Token-Nutzung ausserhalb des Nutzerkontexts, nicht über den Login selbst. Verteidigung heisst: phishing-resistente MFA, Continuous Access Evaluation, Token-Bindung und Detection auf Refresh-Token-Wiederverwendung.

Business Email Compromise in Microsoft 365 erkennen und stoppen

Business Email Compromise (BEC) in Microsoft 365 ist selten ein Malware-Fall, sondern eine Kette aus Phishing, Session- oder Token-Diebstahl, Inbox-Regeln und OAuth-Consent-Missbrauch. Ein SOC erkennt BEC über korrelierte Signale aus Entra ID, Exchange Online und Defender for Cloud Apps, nicht über den E-Mail-Text allein. Reaktion heisst: Session widerrufen, Inbox-Regeln entfernen, OAuth-Consents zurückziehen, MFA neu erzwingen, dokumentiert nach ISG- und Versicherungslogik.

Zero Trust und SOC: Vom Prinzip zur wirksamen Detection

Zero Trust ist keine Produktkategorie, sondern ein Architekturprinzip: kein implizites Vertrauen gegenüber Netz, Gerät oder Konto, jede Anfrage wird laufend authentifiziert und autorisiert. Damit das Prinzip wirkt, braucht es ein SOC, das Identitäts-, Geräte- und Netzsignale korreliert und Verstösse gegen die definierten Policies erkennt. Ohne Detection bleibt Zero Trust ein Diagramm; ohne Zero-Trust-Fundament läuft das SOC ins Leere. Rahmen und Betriebsmodell im Detail auf [SOC as a Service Schweiz](/de/soc/soc-as-a-service-schweiz).

Kurzdefinitionen im Glossar nachschlagen