Start · Lösungen · Weitere Lösungen

Lösung · Weitere Lösungen

Riskante Anmeldungen in Minuten angereichert, eingedämmt, ticketiert und dem Nutzer erklärt

Verdächtige Anmeldungen in Minuten gestoppt, nicht im Audit

Jede markierte Anmeldung wird angereichert, einem Playbook zugeordnet, im Rahmen der Regeln eingedämmt, ticketiert und in Teams erklärt; Analysten entscheiden nur geschützte Konten und Einsprüche.

AbteilungslösungMicrosoft TeamsMensch in der EntscheidungDeterministische Automatisierung
380anmeldebezogene Vorfälle pro Monat erreichen das zweiköpfige Sicherheitsteam dieses illustrativen Logistikunternehmens. Median bis zur Eindämmung: gut fünf Stunden.

Kurzfassung für die Geschäftsführung

Herausforderung

In Sekunden erkannt, über Schichten hinweg eingedämmt: Jeder Schritt zwischen Alarm und Aktion ist ein Mensch.

Was sich ändert

Das native Signal bleibt, wo es ist.

Geschäftlicher Nutzen

Die Zeit bis zur Eindämmung fällt für Playbook-Fälle von Schichten auf Minuten, weil niemand mehr auf das Postfach eines Administrators wartet.

Beteiligte Systeme

Microsoft Entra ID über Microsoft Graph; Microsoft Sentinel; ServiceNow

Geschäftsproblem

Sicherheit

Erkennung ist in diesem Unternehmen gelöst, Reaktion nicht. Microsoft Entra ID Protection vergibt das Risikolabel, Microsoft Sentinel macht daraus einen Vorfall, doch ein Label ist keine Entscheidung. Für die Entscheidung fehlt Kontext, der an vier anderen Stellen liegt: ob die Person noch beschäftigt, im Urlaub oder auf Reisen ist (Workday), ob das Gerät compliant ist (Intune), ob das Konto privilegiert, geteilt oder ein Dienstkonto ist (eine Tabelle im Sicherheitsteam), und ob bereits ein Ticket existiert (ServiceNow).

Ein zweiköpfiges Team trägt das von Hand zusammen, braucht danach einen Administrator, der Sitzungen widerruft oder das Konto deaktiviert, braucht den Service Desk, der den Nutzer telefonisch erreicht, und schreibt das Ticket zuletzt. Nächte und Wochenenden gehören einem externen Dienstleister, der zwar triagieren kann, aber keine Rechte im Tenant hält; aus einer Erkennung am Samstag wird so eine E-Mail, die jemand am Montag liest.

Der Ablauf hält sich, weil jedes Werkzeug einen Schritt gut abdeckt und die Übergaben dazwischen Menschen sind. Die Sicherheit besitzt die Entscheidung, das Identity-Team die Rechte, der Service Desk das Telefon, und der Nutzer besitzt eine Erklärung, nach der bis zum vierten Tag niemand gefragt hat.

Wie es heute läuft

  1. SystemMicrosoft Entra ID Protection meldet eine Risikoerkennung, Microsoft Sentinel eröffnet daraus einen Vorfall in der Warteschlange
  2. WartezeitDer Vorfall wartet auf die nächste Bürostunde; alles, was nach Freitagnachmittag auffällt, wartet bis Montag
  3. MenschDer Analyst schlägt den Nutzer in Workday nach, das Gerät in Intune, dreißig Tage Anmeldehistorie, die Kontenliste und ServiceNow, in fünf Browser-Tabs
  4. MenschEr entscheidet „vermutlich harmlos“ oder „vermutlich nicht“ und bittet einen Administrator per E-Mail, Sitzungen zu widerrufen oder das Konto zu deaktivieren
  5. WartezeitDer Service Desk ruft den Nutzer an; niemand nimmt ab; ein zweiter Versuch folgt am Tag darauf
  6. FehlerrisikoEchte Vorfälle stehen hinter Fehlalarmen von geteilten Geräten in den Depots, in der Reihenfolge des Eingangs
  7. FehlerrisikoDas Ticket entsteht zuletzt, die Führungskraft erfährt nie davon, und der Vorfall schließt Tage nach der Anmeldung als „harmlos“ oder „eingedämmt“
SystemWartezeitMenschFehlerrisiko

Warum der heutige Ablauf mehr kostet, als er scheint

Die Kosten wachsen dort, wo niemand hinsieht.

  • Die Zeit bis zur Eindämmung entscheidet, ob aus einem übernommenen Konto ein meldepflichtiger Sicherheitsvorfall wird, und sie wird hier in Schichten gemessen: der des Analysten, der des Administrators und der des Service Desks.
  • Analystenstunden fließen in Abfragen statt in Beurteilung, teuer bezahlte Fachleute erledigen Büroarbeit, und die zwei Fälle pro Woche, die wirklich Beurteilung brauchen, warten in derselben Warteschlange.
  • Rückrufe landen bei einem Service Desk, der sie nicht lösen kann: Er sieht die Erkennung nicht, darf nichts widerrufen und kann den Nutzer nur bitten, noch einmal anzurufen.
  • Nutzer lernen, dass ein Anruf der Sicherheit folgenlos bleibt, und gehen nicht mehr ran, was die falsche Lehre für den einen Anruf ist, der zählt.
  • Berichtet werden kann die mittlere Zeit bis zur Eindämmung je Erkennungstyp nicht, also wird über das Sicherheitsbudget mit Anekdoten verhandelt, während Aufsicht und Versicherer genau diese Zahl verlangen.

Kosten des Nichthandelns

Zwölf Monate Abfragen, E-Mails und Rückrufe≈ 92.180 €
Drei Jahre im selben Schichtmuster≈ 276.540 €
Fünfhundert Erkennungen pro Monat, die Phishing-Kits liefern werden (pro Jahr)≈ 121.290 €

Erkennungen wachsen schneller als die Zahl der Nutzer. Phishing-Kits automatisieren Password Spray und MFA-Ermüdung, die Warteschlange wächst mit ihnen, während die Zeit bis zur Eindämmung eine Funktion des Schichtplans bleibt. Die Zeilen bewerten ausschließlich Stunden.

NIS2 startet die Frist für die Frühwarnung mit der Kenntnisnahme, und diese Kenntnisnahme trägt in Sentinel einen Zeitstempel, gleich ob innerhalb der 24 Stunden jemand gehandelt hat. Versicherungsfragebögen erfragen die mittlere Zeit bis zur Eindämmung, und „wir messen das nicht“ hat eine eigene Prämie.

Illustratives Szenario

Eine plausible Organisation mit realistischen Größenordnungen. Die Zahlen sind zum Nachrechnen mit Ihren Daten gedacht, kein Kundenergebnis.

Organisation

Ein Logistikunternehmen mit 6.500 Nutzern, ein Drittel davon Beschäftigte in der Fläche an geteilten Scannern und Terminals; Microsoft Entra ID P2, Microsoft Sentinel und Microsoft Intune; ServiceNow für Tickets, Workday als Personalsystem; ein zweiköpfiges Sicherheitsteam zu Bürozeiten und ein externer Dienstleister in der Nacht.

Volumen

Rund 380 anmeldebezogene Erkennungen und Vorfälle pro Monat: untypische Reisen, Password Spray, unbekannte Anmeldeeigenschaften, Anmeldungen an seit neunzig Tagen ruhenden Konten, geleakte Zugangsdaten. Zwei von drei betreffen Standardkonten auf compliant gemeldeten Geräten.

Heutiger Ablauf

Jeder Vorfall wird von Hand um Personal-, Geräte-, Anmelde- und Ticketdaten angereichert, von einem per E-Mail gebetenen Administrator eingedämmt und dem Nutzer telefonisch erklärt; das Ticket entsteht zuletzt.

Engpass

Der Median von der Erkennung bis zur eindämmenden Aktion liegt bei gut fünf Stunden, am Wochenende höher; 22 Minuten Analystenzeit je Vorfall gehen in Abfragen und Schriftverkehr, bevor überhaupt beurteilt wird.

Lösung

Jeder Sentinel-Vorfall mit Anmeldebezug startet einen UiPath-Prozess: Ein Robot reichert an, eine Regeltabelle wählt das Playbook, die routinemäßige Eindämmung läuft für Standardkonten, in ServiceNow öffnet sich ein Ticket mit den Belegen, und der Nutzer beantwortet in Microsoft Teams die Aufgabe „Waren Sie das?“. Geschützte Konten halten immer bei einem Analysten.

Möglicher Effekt

Im modellierten Fall werden Playbook-Fälle in Minuten statt in Stunden eingedämmt, rund zwei Drittel der Vorfälle schließen ohne Analysten, und der Telefonrückruf weicht einer Aufgabe in Teams. Die Zahlen sind ein Modell, keine Messung.

Vorgeschlagene Lösung

Das native Signal bleibt, wo es ist. Die Risikorichtlinien von Entra ID Protection in Conditional Access bleiben die erste Linie; wir ergänzen die Reaktion. Eine Automatisierungsregel in Sentinel greift bei jedem neuen Vorfall mit Anmeldebezug und übergibt ihn über ein schlankes Playbook in Azure Logic Apps zusammen mit der Vorfallkennung an einen API-Trigger in UiPath Orchestrator.

Der Anreicherungs-Robot stellt in Sekunden zusammen, was der Analyst in zwanzig Minuten zusammengestellt hat: Beschäftigungsstatus und Führungskraft aus Workday, Gerätekonformität aus Intune, dreißig Tage Anmeldemuster, die Kontenklasse und ein etwaiges offenes Ticket in ServiceNow. Eine Regeltabelle, indiziert über Erkennungstyp und Kontenklasse, benennt das Playbook. Das ruhende Konto eines Ausgeschiedenen wird deaktiviert und seine Sitzungen werden widerrufen, mit einem Ticket der Priorität P2; eine untypische Reise auf einem konformen Gerät mit bestandener mehrstufiger Authentifizierung erhält ein P4-Ticket und eine Aufgabe in Microsoft Teams mit der Frage an den Nutzer, ob die Anmeldung von ihm stammt; Password Spray geht an das Sicherheitsteam, und die betroffenen Konten werden als kompromittiert bestätigt, damit die Benutzerrisikorichtlinie den Kennwortwechsel erzwingt. Privilegierte Konten, Konten der Geschäftsleitung und Dienstkonten erreichen den Eindämmungs-Robot nie; sie halten bei einer Analystenaufgabe in UiPath Action Center, die in Teams erledigt wird.

Jede Aktion wird in das ServiceNow-Ticket und in einen Datensatz in UiPath Data Fabric geschrieben, mit Vorfallkennung, Regelversion, jeder Aktion und der Antwort des Nutzers. Der Sentinel-Vorfall schließt mit seiner Klassifizierung, die Führungskraft erhält eine kurze Karte in Teams, und Power BI berichtet die Zeit bis zur Eindämmung nach Erkennungstyp, Schicht und Kontenklasse. Eine KI-Komponente gibt es nicht: Über die Eindämmung entscheiden Regeln, die sich erklären und prüfen lassen.

Genutzte native Funktionen

Risikoerkennungen von Microsoft Entra ID Protection und risikobasiertes Conditional Access (Entra ID P2); Automatisierungsregeln in Microsoft Sentinel mit einem Azure Logic Apps Playbook; API-Trigger, Warteschlangen, Anmeldeinformationsspeicher und Prüfpfad von UiPath Orchestrator; UiPath Action Center Aufgaben als Benachrichtigungen mit Aktion in Microsoft Teams; Workflows in Microsoft Teams für die Karte der Führungskraft; UiPath Data Fabric; Power BI

Was wir bauen

Die Anreicherungs- und Eindämmungs-Robots, die Regeltabellen, die Karten für Nutzer und Führungskraft, die Analystenaufgabe, die ServiceNow-Ticketvorlage, den Belegdatensatz und den Bericht

Individuelle Integration

Microsoft Graph mit Anwendungsberechtigungen für Sitzungswiderruf, Kontodeaktivierung, Risikobestätigung, Anmeldehistorie und Intune-Konformität; Workday und ServiceNow über Konnektoren des UiPath Integration Service; Lesen und Schließen der Sentinel-Vorfälle über den Microsoft Azure Sentinel Konnektor oder die Sentinel REST API

So läuft der automatisierte Prozess

  1. SystemEntra ID Protection markiert eine Anmeldung; Sentinel eröffnet den Vorfall, und seine Automatisierungsregel übergibt ihn binnen einer Minute an einen UiPath-Job
  2. AutomatisierungDer Robot reichert den Vorfall an: Beschäftigungsstatus und Führungskraft, Gerätekonformität, dreißig Tage Anmeldemuster, Kontenklasse, offene Tickets
  3. AutomatisierungDie Regeltabelle ordnet Erkennungstyp und Kontenklasse einem Playbook zu und schreibt die Regelversion mit
  4. MenschPrivilegierte Konten, Konten der Geschäftsleitung und Dienstkonten halten bei einer Analystenaufgabe in Action Center, die in Teams beantwortet wird, bevor etwas läuft
  5. AutomatisierungFür Standardkonten läuft die Eindämmung: Sitzungen widerrufen, Konto deaktivieren oder Risiko bestätigen, damit Conditional Access den Kennwortwechsel erzwingt
  6. AutomatisierungIn ServiceNow öffnet sich ein Ticket mit den Belegen; der Nutzer erhält in Teams die Aufgabe „Waren Sie das?“ und die Führungskraft eine Karte
  7. MenschDer Nutzer bestätigt oder widerspricht; Einsprüche und Vorfälle ohne passendes Playbook gehen mit allem Gesammelten an den Analysten
  8. AutomatisierungDer Vorfall schließt in Sentinel und ServiceNow mit Regelversion und Ergebnis, und der Belegdatensatz speist den Bericht
SystemAutomatisierungMensch

Modell der Zusammenarbeit von Mensch und Automatisierung

Die Automatisierung übernimmt

  • Die Anreicherung jedes Vorfalls um Beschäftigungsstatus, Gerätekonformität, Anmeldehistorie, Kontenklasse und offene Tickets
  • Die Playbook-Auswahl und die routinemäßige Eindämmung auf Standardkonten: Sitzungen widerrufen, Konto deaktivieren, Risiko bestätigen
  • Das ServiceNow-Ticket, den Abschluss in Sentinel, den Belegdatensatz und den Bericht
  • Die Bestätigungsaufgabe für den Nutzer und die Karte für die Führungskraft in Teams, mit protokollierter Antwort

Menschen entscheiden

  • Analysten geben die Eindämmung auf privilegierten Konten, Konten der Geschäftsleitung und Dienstkonten frei oder lehnen sie ab
  • Analysten prüfen Einsprüche und Vorfälle, die zu keinem Playbook passen
  • Die Sicherheit besitzt die Regeltabellen und überprüft sie monatlich anhand der Vorfälle des Vormonats
  • Der Service Desk übernimmt die Nutzer, die über Teams nicht erreichbar waren

Vorher und nachher

VorherNachher
Zeit von der Erkennung bis zur eindämmenden AktionMedian gut fünf StundenMinuten für Playbook-Fälle; eine Analystenaufgabe für geschützte Konten
Analystenminuten je Vorfallrund 22, überwiegend Abfragenausschließlich Beurteilung, in den von den Regeln übergebenen Fällen
Wie der Nutzer erreicht wirdAnrufe des Service Desks, oft ohne Antworteine Aufgabe in Teams, beantwortet und protokolliert
Belege je Vorfallein zuletzt aus dem Gedächtnis geschriebenes TicketKennung, Regelversion, Aktionen und Antworten in einem Datensatz

Systeme und Integrationen

Wir fügen keine Technologie hinzu, damit eine Architektur seriös aussieht. Jedes Element unten hat hier eine konkrete Aufgabe.

Eingaben

  • Anmeldeprotokolle und Risikoerkennungen aus Entra ID
  • Vorfälle aus Microsoft Sentinel
  • Beschäftigungsstatus und Führungskraft aus Workday
  • Gerätekonformität aus Intune
  • offene Tickets aus ServiceNow
  • die Liste der geschützten Konten

Automatisierungsschicht

  • UiPath Orchestrator
  • UiPath Robots
  • UiPath Integration Service
  • UiPath Action Center
  • UiPath Data Fabric
  • Azure Logic Apps (Sentinel-Playbook)

Zielsysteme

  • Microsoft Entra ID über Microsoft Graph
  • Microsoft Sentinel
  • ServiceNow
  • Power BI

Berührungspunkte für Menschen: Action Center Aufgaben in Microsoft Teams für Analysten und Nutzer; die Karte der Führungskraft in Teams; die Zusammenfassung im Sicherheitskanal; der Service Desk für Nutzer, die über Teams nicht erreichbar sind

AnmeldeprotokolleUiPath OrchestratorUiPath RobotsMicrosoft Entra ID über Microsoft GraphAction Center Aufgaben in Microsoft Teams für Analysten

Eingesetzte Technologien

Microsoft Entra ID Protection

Risikoerkennungen und risikobasiertes Conditional Access als erste Linie; die Bestätigung einer Kontoübernahme treibt den Kennwortwechsel

A
Microsoft Sentinel

macht aus Risikoerkennungen Vorfälle; eine Automatisierungsregel und ein Azure Logic Apps Playbook übergeben jeden davon an den Robot

A
UiPath Robots + UiPath Orchestrator

der API-Trigger nimmt den Vorfall an; Robots reichern an, wenden die Regeln an und dämmen ein; Warteschlangen, Wiederholungen und Prüfpfad

A
UiPath Integration Service (Konnektoren Microsoft Azure Sentinel, ServiceNow, Workday, Microsoft Teams)

liest und schließt Vorfälle, öffnet Tickets, prüft den Beschäftigungsstatus, postet die Kanalzusammenfassung

A
Microsoft Graph (Entra ID und Intune)

Sitzungswiderruf, Kontodeaktivierung, Risikobestätigung, Anmeldehistorie, Gerätekonformität

A
UiPath Action Center in Microsoft Teams

die Analystenentscheidung zu geschützten Konten und die Bestätigung des Nutzers

A
Workflows in Microsoft Teams (Power Automate)

die Adaptive Card für die Führungskraft, gepostet über einen Webhook, den der Robot aufruft

A
UiPath Data Fabric und Power BI

der Belegdatensatz je Vorfall; Zeit bis zur Eindämmung nach Erkennungstyp, Schicht und Kontenklasse

A
Abestätigte Produktfunktion (Herstellerdokumentation)

Illustratives Wirtschaftlichkeitsmodell

Was es wert ist, mit offener Rechnung.

Illustratives Modell
380 Vorfälle pro Monat × 12 × 22 Min. Analystenaufwand= 1.672 h / Jahr
1.672 h × 63 € Vollkosten je Analystenstunde × 65 % Playbook-Anteil≈ 68.468 € / Jahr
4.560 Vorfälle pro Jahr × 8 Min. Rückruf im Service Desk= 608 h / Jahr
608 h × 39 € Vollkosten im Service Desk≈ 23.712 € / Jahr
Jährlich freigesetzter Aufwandspool (illustrativ)≈ 92.180 €

Analystenaufwand und Rückrufe des Service Desks sind die beiden Ströme, die unten bewertet werden, und keiner davon wurde bei einem Kunden gemessen. Der Analystenaufwand beträgt 22 Minuten je Vorfall, davon wird der Playbook-Anteil frei: 65 % in dieser stark von der Fläche geprägten Umgebung. Rückrufe kosten den Desk 8 Minuten je Vorfall und werden durch die Aufgabe in Teams ersetzt. 63 € je Stunde sind Vollkosten eines Analysten einschließlich des Mischsatzes des externen Dienstleisters; 39 € je Stunde sind Vollkosten im Service Desk in Mitteleuropa. Zwei Ströme mit zwei Sätzen passen nicht in eine Kalkulatorzeile. SOC-Gebühren, Lizenzen und Schadenskosten liegen außerhalb des Modells.

Geschäftlicher Nutzen

  • Die Zeit bis zur Eindämmung fällt für Playbook-Fälle von Schichten auf Minuten, weil niemand mehr auf das Postfach eines Administrators wartet
  • Analystenzeit verschiebt sich von Abfragen auf Beurteilung, das Einzige, was ein zweiköpfiges Team nicht delegieren kann
  • Nutzer beantworten eine Aufgabe in Teams in Sekunden, statt einen Anruf zu ignorieren, und die Antwort wird Teil des Protokolls
  • Jeder Vorfall trägt dieselben Belege in denselben Feldern, also erhalten Prüfer und Versicherer einen Bericht statt einer Erzählung
  • Fehlalarme kosten Robotminuten statt Analystenstunden, also tauchen echte Vorfälle früher und in einer kürzeren Warteschlange auf

Sicht der Geschäftsleitung

  • Die mittlere Zeit bis zur Eindämmung nach Erkennungstyp, Schicht und Kontenklasse wird zu einer Zahl, die der CISO täglich zeigen kann
  • In der Warteschlange bleiben nur Fälle, die Beurteilung brauchen, damit die Auslastung eines zweiköpfigen Teams planbar wird und der Umfang des Nachtdienstleisters eine Regel ist
  • Regeltabellen sind versioniert und werden freigegeben, also lässt sich jede Eindämmung der Regel zuordnen, die sie angeordnet hat
  • Sicherheitsanrufe verschwinden aus der Statistik des Service Desks, und Führungskräfte erfahren am selben Tag, dass ein Konto in ihrem Team betroffen war und warum

KPIs für die Geschäftsführung

Median der Zeit bis zur Eindämmung je ErkennungstypAnteil der ohne Analysten bearbeiteten VorfälleAntwortquote der Nutzer auf die Bestätigungsaufgabemit vollständigen Belegen geschlossene Vorfälleoffene Vorfälle älter als eine Schicht

Sicherheit und Governance

Vertrauen in Automatisierung entsteht durch den Prüfpfad, nicht durch ein Versprechen.

  • Der Eindämmungs-Robot läuft unter einem Entra-Dienstprinzipal mit ausschließlich den Graph-Berechtigungen, die seine Playbooks brauchen, über Verwaltungseinheiten auf Standardkonten begrenzt; die geschützte Liste setzt das Verzeichnis selbst durch
  • Geheimnisse liegen nie im Ablauf: Der Robot bezieht sie zur Laufzeit aus Azure Key Vault über den Anmeldeinformationsspeicher des Orchestrator, und dessen Prüfpfad protokolliert jeden Job und jede Wiederholung
  • Jede Aktion wird mit Vorfallkennung, Regelversion und Ergebnis in den Data Fabric Datensatz und in das ServiceNow-Ticket geschrieben, sodass sich jede Eindämmung rekonstruieren lässt
  • Regeltabellen ändern sich ausschließlich über ein geprüftes Release mit namentlich benanntem Freigebenden im Sicherheitsteam
  • Personaldaten beschränken sich auf Status und Führungskraft; die Verarbeitung bleibt in Ihrem Microsoft 365 Tenant innerhalb der EU Data Boundary und in der EU-Region von UiPath Automation Cloud; ein Sprachmodell ist nicht beteiligt

Warum jetzt

01

NIS2 startet die Frist für die Frühwarnung mit der Kenntnisnahme, und diese trägt in Sentinel einen Zeitstempel. Eine Reaktion, die bis Montag wartet, ist eine meldepflichtige Verzögerung, und Versicherer erfragen die mittlere Zeit bis zur Eindämmung im Verlängerungsformular

02

Die Erkennung ist in den meisten Microsoft 365 E5 Umgebungen fertig: Entra ID Protection und Sentinel sind lizenziert und laufen. Die Stunden liegen in der Reaktion, modellierte 7.700 € pro Monat aus der Tabelle oben

03

Automatisierungsregeln in Sentinel, API-Trigger im Orchestrator, eng gefasste Graph-Berechtigungen und Action Center Aufgaben in Teams sind dokumentierte Funktionen; die Zusammenstellung ist Ingenieurarbeit, keine Forschung

Relevante Führungsrollen

CISO

Die mittlere Zeit bis zur Eindämmung wird für Routinefälle zu Minuten und für alle Fälle zu einer berichteten Zahl, nach Erkennungstyp und Schicht

CIO

Das Sicherheitsteam wächst mit den Erkennungen mit, ohne Schichten zu ergänzen, und der Service Desk führt keine Sicherheitsanrufe mehr, die er nicht lösen kann

Leitung Service Desk

Rückrufe verschwinden aus der Statistik des Desks; er sieht nur noch die Nutzer, die über Teams nicht erreichbar waren, samt Belegen

Häufige Fragen und Einwände

Unser SOC-Dienstleister macht das bereits.

Er triagiert. Die Eindämmung braucht weiterhin jemanden mit Rechten in Ihrem Tenant und mit Kenntnis Ihrer Personaldaten. Der Robot gibt Ihrem Dienstleister eine Aufgabe und ein Ticket statt einer E-Mail an Ihren Administrator.

Automatisches Deaktivieren sperrt irgendwann ein Vorstandsmitglied aus.

Geschützte Konten erreichen den Eindämmungs-Robot nie; das Verzeichnis selbst verhindert es, und sie gehen immer an einen Analysten. Konten in der Fläche auf geteilten Geräten erhalten eine Bestätigungsaufgabe, keine Sperre.

Conditional Access blockiert riskante Anmeldungen doch schon.

Es blockiert die Anmeldung oder fordert zusätzlich auf, und das ist richtig so. Es öffnet kein Ticket, prüft nicht, ob die Person letzten Monat ausgeschieden ist, widerruft keine bestehenden Sitzungen und informiert die Führungskraft nicht; genau das ist die Handarbeit.

Wann dies nicht die richtige Lösung ist

  • Kein Entra ID P2 oder kein Sentinel: Das Signal fehlt, und die Lizenzierung kommt zuerst
  • Eine SOAR-Plattform führt diese Playbooks bereits aus; dann decken Robots nur die Systeme ab, die sie nicht erreicht, etwa den Personalbereich und die Ticketwarteschlange
  • Weniger als etwa tausend Nutzer, wo das Vorfallvolumen Playbooks selten rechtfertigt und eine Rufbereitschaft mit den richtigen Rechten das meiste davon erledigt

Eine Frage für die nächste Sitzung

Hätte sich am Samstagmorgen ein Angreifer an einem unserer Konten angemeldet, wann hätte jemand mit dem Recht zur Sperrung davon erfahren, und welcher Datensatz würde das belegen?

Vorgehen bei der Umsetzung

Was wir liefern und was wir für den Start brauchen.

Wir liefern

  • Ihr letztes Quartal an Vorfällen, klassifiziert nach Erkennungstyp und Kontenklasse, mit je einem Playbook-Entwurf pro Typ, abgestimmt mit Sicherheit, Personalbereich und Service Desk
  • Die Regeltabellen, wobei die Liste der geschützten Konten im Verzeichnis durchgesetzt wird und nicht in den Regeln
  • Die Anreicherungs- und Eindämmungs-Robots, das Logic Apps Playbook und den Orchestrator-API-Trigger, der Sentinel mit ihnen verbindet
  • Die Karten für Nutzer und Führungskraft, die Analystenaufgabe, die ServiceNow-Ticketvorlage, den Belegdatensatz und den Power BI Bericht
  • Einen Betrieb im Empfehlungsmodus über mehrere Wochen, damit Analysten sehen, was der Robot getan hätte, bevor er es tut

Wir benötigen von Ihnen

  • Entra ID P2 und Sentinel im Einsatz sowie den Vorfallexport des letzten Quartals ohne Namen
  • Eine Zulieferung von Beschäftigungsstatus und Führungskraft aus Workday, beschränkt auf diese beiden Felder
  • Die Liste der geschützten Konten und einen Verantwortlichen für die Regeltabellen im Sicherheitsteam
  • Einen Dienstprinzipal für den Eindämmungs-Robot, über Verwaltungseinheiten auf Standardkonten begrenzt

Etappen

Analyse

Vorfälle des letzten Quartals klassifiziert; Erkennungstypen, Kontenklassen und die geschützte Liste abgestimmt

Konzeption

Regeltabellen, Playbooks, Ticketvorlagen, Karten, Sicherheitsmodell und Graph-Berechtigungen

Aufbau

Anreicherungs- und Eindämmungs-Robots, Übergabe aus Sentinel, Aufgaben und Karten in Teams, Belegdatensatz, Bericht

Empfehlungsmodus

Jedes Playbook schlägt vor, handelt aber nicht; Analysten korrigieren über mehrere Wochen die Regeln

Unbeaufsichtigter Start

Die routinemäßige Eindämmung auf Standardkonten läuft unbeaufsichtigt; geschützte Konten bleiben hinter einem Analysten

Skalierung

Der Nachtdienstleister arbeitet auf denselben Karten; neue Erkennungstypen werden zu Playbooks

Abteilungsweit. Den Aufwand bestimmen die Zahl der gepflegten Erkennungstypen, die Qualität der Personalzulieferung und der Kontenübersicht sowie die Systeme jenseits von ServiceNow, die das Ticket tragen müssen.