Start · Rozwiązania · Inne rozwiązania

Rozwiązanie · Inne rozwiązania

Ryzykowne logowania: kontekst, blokada, zgłoszenie i wyjaśnienie dla właściciela w kilka minut

Podejrzane logowania zatrzymane w minuty, nie na audycie

Każde oznaczone logowanie dostaje kontekst, playbook, powstrzymanie w granicach reguł, zgłoszenie i wyjaśnienie dla właściciela w Teams; analitycy rozstrzygają tylko konta chronione i spory.

Rozwiązanie działoweMicrosoft TeamsCzłowiek w pętli decyzyjnejAutomatyzacja deterministyczna
380incydentów logowania miesięcznie trafia do dwuosobowego zespołu bezpieczeństwa tej ilustracyjnej firmy logistycznej. Mediana czasu do reakcji: ponad pięć godzin.

Streszczenie dla zarządu

Wyzwanie

Wykryte w sekundy, powstrzymane po zmianach: każdy krok między alertem a działaniem to człowiek.

Co się zmienia

Natywny sygnał zostaje tam, gdzie jest.

Wartość biznesowa

Czas do powstrzymania spada ze zmian do minut dla spraw objętych playbookiem, bo nikt nie czeka na skrzynkę administratora.

Systemy w tle

Microsoft Entra ID przez Microsoft Graph; Microsoft Sentinel; ServiceNow

Problem biznesowy

Bezpieczeństwo

Wykrywanie jest w tej firmie problemem rozwiązanym; reagowanie nie. Entra ID Protection nadaje etykietę ryzyka, a Microsoft Sentinel zamienia ją w incydent, ale etykieta to nie decyzja. Decyzja wymaga kontekstu, który leży w czterech innych miejscach: czy osoba nadal jest zatrudniona, na urlopie albo w podróży (Workday); czy urządzenie jest zgodne z polityką (Intune); czy konto jest uprzywilejowane, współdzielone albo serwisowe (arkusz w zespole bezpieczeństwa); i czy istnieje już zgłoszenie (ServiceNow).

Dwuosobowy zespół zbiera to ręcznie, potem potrzebuje administratora, żeby unieważnić sesje lub wyłączyć konto, potrzebuje service desku, żeby dodzwonić się do użytkownika, a zgłoszenie pisze na końcu. Noce i weekendy należą do zewnętrznego dostawcy, który potrafi ocenić zdarzenie, ale nie ma uprawnień w tenancie, więc sobotnie wykrycie zamienia się w e‑mail, który ktoś czyta w poniedziałek.

Proces trwa, bo każde narzędzie dobrze obsługuje jeden krok, a przekazania między nimi to ludzie. Bezpieczeństwo odpowiada za decyzję, zespół tożsamości za uprawnienia, service desk za telefon, a użytkownik za historię, o którą nikt nie pytał do czwartego dnia.

Jak to wygląda dzisiaj

  1. SystemEntra ID Protection zgłasza wykrycie ryzyka, a Microsoft Sentinel otwiera incydent w kolejce
  2. OczekiwanieIncydent czeka na następną zmianę biurową; wszystko, co wykryto po piątkowym popołudniu, czeka do poniedziałku
  3. CzłowiekAnalityk sprawdza użytkownika w Workday, urządzenie w Intune, trzydzieści dni historii logowań, listę kont i ServiceNow, w pięciu kartach przeglądarki
  4. CzłowiekDecyduje „raczej w porządku” albo „raczej nie” i pisze e‑mail do administratora z prośbą o unieważnienie sesji lub wyłączenie konta
  5. OczekiwanieService desk dzwoni do użytkownika; nikt nie odbiera; druga próba następuje następnego dnia
  6. Ryzyko błęduPrawdziwe incydenty stoją w kolejce za fałszywymi alarmami ze współdzielonych urządzeń w magazynach, w kolejności wpływu
  7. Ryzyko błęduZgłoszenie powstaje na końcu, przełożony nigdy się nie dowiaduje, a incydent zamyka się jako „niegroźny” lub „powstrzymany” kilka dni po logowaniu
SystemOczekiwanieCzłowiekRyzyko błędu

Dlaczego obecny proces kosztuje więcej, niż się wydaje

Koszt rośnie tam, gdzie nikt na niego nie patrzy.

  • Czas do powstrzymania decyduje o tym, czy przejęte konto stanie się naruszeniem, a tutaj mierzy się go zmianami: analityka, administratora i service desku.
  • Godziny analityków idą na sprawdzenia zamiast na ocenę, więc drodzy ludzie wykonują pracę biurową, a dwa przypadki w tygodniu, które ich potrzebują, czekają w tej samej kolejce.
  • Oddzwanianie spada na service desk, który nie może niczego rozwiązać: nie widzi wykrycia, nie może niczego unieważnić i może jedynie prosić użytkownika o ponowny kontakt.
  • Użytkownicy uczą się, że telefon z bezpieczeństwa jest o niczym, i przestają odbierać, a to zła lekcja przed tym jednym telefonem, który ma znaczenie.
  • Nikt nie potrafi zaraportować średniego czasu do powstrzymania według typu wykrycia, więc o budżecie bezpieczeństwa dyskutuje się anegdotami, podczas gdy regulatorzy i ubezpieczyciele pytają właśnie o tę liczbę.

Koszt zaniechania

Dwanaście miesięcy sprawdzeń, e‑maili i oddzwaniania≈ 92 180 €
Trzy lata na tym samym grafiku zmian≈ 276 540 €
Pięćset wykryć miesięcznie, które dostarczą zestawy phishingowe (rocznie)≈ 121 290 €

Wykrycia rosną szybciej niż liczba użytkowników. Zestawy phishingowe automatyzują password spray i zmęczenie MFA, a kolejka rośnie razem z nimi, podczas gdy czas do powstrzymania pozostaje funkcją grafiku zmian. Wiersze wyceniają wyłącznie godziny.

NIS2 liczy zegar wczesnego ostrzeżenia od momentu powzięcia wiedzy, a ta wiedza ma znacznik czasu w Sentinel niezależnie od tego, czy ktoś zadziałał w ciągu 24 godzin. Kwestionariusze ubezpieczeniowe pytają o średni czas do powstrzymania, a „nie mierzymy tego” ma własną składkę.

Scenariusz ilustracyjny

Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.

Organizacja

Firma logistyczna z 6 500 użytkownikami, z których jedna trzecia to pracownicy pierwszej linii na współdzielonych skanerach i terminalach; Microsoft Entra ID P2, Microsoft Sentinel i Microsoft Intune; ServiceNow do zgłoszeń, Workday jako system kadrowy; dwuosobowy zespół bezpieczeństwa w godzinach biurowych i zewnętrzny dostawca w nocy.

Wolumen

Około 380 wykryć i incydentów związanych z logowaniem miesięcznie: nietypowa podróż, password spray, nieznane właściwości logowania, logowania z kont nieaktywnych od dziewięćdziesięciu dni, wyciekłe poświadczenia. Dwa na trzy dotyczą standardowych kont na zgodnych urządzeniach.

Obecny proces

Każdy incydent jest ręcznie wzbogacany o dane kadrowe, dane urządzenia, historię logowań i zgłoszenia, powstrzymywany przez administratora proszonego e‑mailem i wyjaśniany użytkownikowi telefonicznie; zgłoszenie powstaje na końcu.

Wąskie gardło

Mediana czasu od wykrycia do działania powstrzymującego to nieco ponad pięć godzin, w weekendy dłużej. 22 minuty pracy analityka na incydent idą na sprawdzenia i papierologię, zanim padnie jakakolwiek ocena.

Rozwiązanie

Każdy incydent Sentinel dotyczący logowania uruchamia proces UiPath: robot wzbogaca go o kontekst, a tabela reguł wybiera playbook. Rutynowe powstrzymanie wykonuje się dla kont standardowych, w ServiceNow otwiera się zgłoszenie z materiałem dowodowym, a użytkownik odpowiada na zadanie „czy to Ty?” w Microsoft Teams. Konta chronione zawsze zatrzymują się u analityka.

Potencjalny efekt

W modelowanym przypadku sprawy objęte playbookiem są powstrzymywane w minuty zamiast w godziny, około dwie trzecie incydentów zamyka się bez udziału analityka, a telefony service desku ustępują zadaniu w Teams. Liczby są modelem, nie pomiarem.

Proponowane rozwiązanie

Natywny sygnał zostaje tam, gdzie jest. Polityki ryzyka Entra ID Protection w Conditional Access pozostają pierwszą linią; my dodajemy reakcję. Reguła automatyzacji w Sentinel uruchamia się przy każdym nowym incydencie dotyczącym logowania i przez niewielki playbook w Azure Logic Apps przekazuje go, wraz z identyfikatorem incydentu, do wyzwalacza API w UiPath Orchestrator.

Robot wzbogacający składa w sekundy to, co analityk składał przez dwadzieścia minut: status zatrudnienia i przełożonego z Workday, zgodność urządzenia z Intune, trzydzieści dni wzorca logowań, klasę konta i ewentualne otwarte zgłoszenie w ServiceNow. Tabela reguł, indeksowana typem wykrycia i klasą konta, wskazuje playbook. Nieaktywne konto byłego pracownika zostaje wyłączone, a jego sesje unieważnione, ze zgłoszeniem P2. Nietypowa podróż na zgodnym urządzeniu z zaliczonym uwierzytelnianiem wieloskładnikowym dostaje zgłoszenie P4 i zadanie w Microsoft Teams z pytaniem do użytkownika, czy to było jego logowanie. Password spray trafia do zespołu bezpieczeństwa, a zaatakowane konta są oznaczane jako przejęte, żeby polityka ryzyka użytkownika wymusiła zmianę hasła. Konta uprzywilejowane, kadry zarządzającej i serwisowe nigdy nie docierają do robota powstrzymującego; zatrzymują się na zadaniu analityka w UiPath Action Center, wykonywanym w Teams.

Każde działanie zapisuje się w zgłoszeniu ServiceNow i w rekordzie UiPath Data Fabric z identyfikatorem incydentu, wersją reguły, każdą akcją i odpowiedzią użytkownika. Incydent w Sentinel zamyka się z klasyfikacją, przełożony dostaje krótką kartę w Teams, a Power BI raportuje czas do powstrzymania według typu wykrycia, zmiany i klasy konta. Nie ma tu komponentu AI: o powstrzymaniu decydują reguły, które da się wyjaśnić i skontrolować.

Wykorzystane funkcje natywne

Wykrycia ryzyka Microsoft Entra ID Protection i Conditional Access oparty na ryzyku (Entra ID P2); reguły automatyzacji Microsoft Sentinel z playbookiem Azure Logic Apps; wyzwalacze API, kolejki, magazyn poświadczeń i dziennik audytu UiPath Orchestrator; zadania UiPath Action Center jako powiadomienia z akcją w Microsoft Teams; Workflows w Microsoft Teams dla karty przełożonego; UiPath Data Fabric; Power BI

Co budujemy

Roboty wzbogacający i powstrzymujący, tabele reguł, karty dla użytkownika i przełożonego, zadanie analityka, szablon zgłoszenia ServiceNow, rekord dowodowy i raport

Integracje dedykowane

Microsoft Graph z uprawnieniami aplikacji do unieważniania sesji, wyłączania kont, potwierdzania ryzyka, historii logowań i zgodności Intune; Workday i ServiceNow przez konektory UiPath Integration Service; odczyt i zamykanie incydentów Sentinel przez konektor Microsoft Azure Sentinel lub Sentinel REST API

Jak działa proces po automatyzacji

  1. SystemEntra ID Protection oznacza logowanie; Sentinel otwiera incydent, a jego reguła automatyzacji w ciągu minuty przekazuje go do zadania UiPath
  2. AutomatyzacjaRobot wzbogaca incydent: status zatrudnienia i przełożony, zgodność urządzenia, trzydzieści dni wzorca logowań, klasa konta, otwarte zgłoszenia
  3. AutomatyzacjaTabela reguł dopasowuje typ wykrycia i klasę konta do playbooka i zapisuje wersję reguły
  4. CzłowiekKonta uprzywilejowane, kadry zarządzającej i serwisowe zatrzymują się na zadaniu analityka w Action Center, rozstrzyganym w Teams, zanim cokolwiek się wykona
  5. AutomatyzacjaDla kont standardowych wykonuje się powstrzymanie: sesje unieważnione, konto wyłączone albo ryzyko potwierdzone, żeby Conditional Access wymusił zmianę hasła
  6. AutomatyzacjaW ServiceNow otwiera się zgłoszenie z materiałem dowodowym; użytkownik dostaje w Teams zadanie „czy to Ty?”, a przełożony kartę
  7. CzłowiekUżytkownik potwierdza albo zaprzecza; spory i incydenty niepasujące do żadnego playbooka trafiają do analityka ze wszystkim, co zebrano
  8. AutomatyzacjaIncydent zamyka się w Sentinel i ServiceNow z wersją reguły i wynikiem, a rekord dowodowy zasila raport
SystemAutomatyzacjaCzłowiek

Model współpracy człowieka z automatyzacją

Automatyzacja obsługuje

  • Wzbogacenie każdego incydentu o status zatrudnienia, zgodność urządzenia, historię logowań, klasę konta i otwarte zgłoszenia
  • Wybór playbooka i rutynowe powstrzymanie na kontach standardowych: unieważnienie sesji, wyłączenie konta, potwierdzenie ryzyka
  • Zgłoszenie w ServiceNow, zamknięcie w Sentinel, rekord dowodowy i raport
  • Zadanie potwierdzenia dla użytkownika i kartę dla przełożonego w Teams, z zapisaną odpowiedzią

Ludzie decydują

  • Analitycy zatwierdzają lub odrzucają powstrzymanie na kontach uprzywilejowanych, kadry zarządzającej i serwisowych
  • Analitycy badają spory i incydenty, które nie pasują do żadnego playbooka
  • Bezpieczeństwo jest właścicielem tabel reguł i co miesiąc przegląda je na tle incydentów z poprzedniego miesiąca
  • Service desk obsługuje użytkowników, do których Teams nie dotarł

Przed i po

PrzedPo
Czas od wykrycia do działania powstrzymującegomediana nieco ponad pięć godzinminuty dla spraw z playbookiem; jedno zadanie analityka dla kont chronionych
Minuty analityka na incydentokoło 22, głównie sprawdzeniawyłącznie ocena, w sprawach przekazanych przez reguły
Jak dociera się do użytkownikatelefony z service desku, często bez odpowiedzizadanie w Teams, z odpowiedzią i zapisem
Materiał dowodowy na incydentzgłoszenie pisane na końcu, z pamięciidentyfikator, wersja reguły, akcje i odpowiedzi w jednym rekordzie

Systemy i integracje

Nie dokładamy technologii, żeby architektura wyglądała poważniej. Każdy element poniżej ma w tym procesie konkretne zadanie.

Wejścia

  • dzienniki logowań i wykrycia ryzyka Entra ID
  • incydenty Microsoft Sentinel
  • status zatrudnienia i przełożony z Workday
  • zgodność urządzeń z Intune
  • otwarte zgłoszenia w ServiceNow
  • lista kont chronionych

Warstwa automatyzacji

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

Systemy docelowe

  • Microsoft Entra ID przez Microsoft Graph
  • Microsoft Sentinel
  • ServiceNow
  • Power BI

Punkty styku z człowiekiem: zadania Action Center w Microsoft Teams dla analityków i użytkowników; karta przełożonego w Teams; podsumowanie na kanale bezpieczeństwa; service desk dla użytkowników nieosiągalnych w Teams

dzienniki logowań i wykrycia ryzyka Entra IDUiPath OrchestratorUiPath RobotsMicrosoft Entra ID przez Microsoft Graphzadania Action Center w Microsoft Teams dla analityków i użytkowników

Wykorzystane technologie

Microsoft Entra ID Protection

wykrycia ryzyka i Conditional Access oparty na ryzyku jako pierwsza linia; potwierdzenie przejęcia konta wymusza zmianę hasła

A
Microsoft Sentinel

zamienia wykrycia ryzyka w incydenty; reguła automatyzacji i playbook Azure Logic Apps przekazują każdy z nich robotowi

A
UiPath Robots + UiPath Orchestrator

wyzwalacz API odbiera incydent; roboty wzbogacają, stosują reguły i powstrzymują; kolejki, ponowienia i audyt

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

odczytuje i zamyka incydenty, otwiera zgłoszenia, sprawdza status zatrudnienia, publikuje podsumowanie na kanale

A
Microsoft Graph (Entra ID i Intune)

unieważnianie sesji, wyłączanie kont, potwierdzanie ryzyka, historia logowań, zgodność urządzeń

A
UiPath Action Center w Microsoft Teams

decyzja analityka o kontach chronionych i potwierdzenie użytkownika

A
Workflows w Microsoft Teams (Power Automate)

karta Adaptive Card dla przełożonego, publikowana z webhooka wywoływanego przez robota

A
UiPath Data Fabric i Power BI

rekord dowodowy na incydent; czas do powstrzymania według typu wykrycia, zmiany i klasy konta

A
Apotwierdzona funkcja produktu (dokumentacja producenta)

Ilustracyjny model ekonomiczny

Ile to jest warte, policzone krok po kroku.

Model ilustracyjny
380 incydentów miesięcznie × 12 × 22 min pracy analityka= 1 672 h / rok
1 672 h × 63 € pełnego kosztu analityka × 65% udziału playbooków≈ 68 468 € / rok
4 560 incydentów rocznie × 8 min oddzwaniania service desku= 608 h / rok
608 h × 39 € pełnego kosztu service desku≈ 23 712 € / rok
Roczna pula uwolnionego nakładu (ilustracyjnie)≈ 92 180 €

Praca analityka i oddzwanianie service desku to dwa strumienie wycenione poniżej i żadnego z nich nie zmierzono u klienta. Obsługa przez analityka to 22 minuty na incydent, z których uwalnia się udział objęty playbookiem: 65% w tym środowisku zdominowanym przez pierwszą linię. Oddzwanianie kosztuje desk 8 minut na incydent i zastępuje je zadanie w Teams. 63 € za godzinę to pełny koszt analityka wraz z uśrednioną stawką zewnętrznego dostawcy. 39 € za godzinę to pełny koszt service desku w Europie Środkowej. Dwa strumienie o dwóch stawkach nie mieszczą się w jednej linii kalkulatora. Opłaty za SOC, licencje i koszty naruszeń są poza modelem.

Korzyści biznesowe

  • Czas do powstrzymania spada ze zmian do minut dla spraw objętych playbookiem, bo nikt nie czeka na skrzynkę administratora
  • Czas analityków przesuwa się ze sprawdzeń na ocenę, jedyną rzecz, której dwuosobowy zespół nie może nikomu oddelegować
  • Użytkownicy odpowiadają na zadanie w Teams w kilka sekund zamiast ignorować telefon, a odpowiedź staje się częścią zapisu
  • Każdy incydent niesie ten sam materiał dowodowy w tych samych polach, więc audytor i ubezpieczyciel dostają raport zamiast opowieści
  • Fałszywe alarmy kosztują minuty robota zamiast godzin analityka, więc prawdziwe incydenty wypływają szybciej w krótszej kolejce

Perspektywa zarządu

  • Średni czas do powstrzymania według typu wykrycia, zmiany i klasy konta staje się liczbą, którą CISO może pokazać codziennie
  • W kolejce zostają tylko sprawy wymagające oceny, więc obciążenie dwuosobowego zespołu jest przewidywalne, a zakres nocnego dostawcy jest regułą
  • Tabele reguł są wersjonowane i wydawane, więc każde powstrzymanie da się przypisać do reguły, która je nakazała
  • Telefony bezpieczeństwa znikają ze statystyk service desku, a przełożeni tego samego dnia dowiadują się, że konto w ich zespole zostało dotknięte i dlaczego

Wpływ na KPI zarządu

mediana czasu do powstrzymania według typu wykryciaudział incydentów obsłużonych bez analitykaodsetek odpowiedzi użytkowników na zadanie potwierdzeniaincydenty zamknięte z kompletnym materiałem dowodowymotwarte incydenty starsze niż jedna zmiana

Bezpieczeństwo i nadzór

Zaufanie do automatyzacji buduje się na śladzie, nie na deklaracji.

  • Robot powstrzymujący działa pod jednostką usługi Entra z wyłącznie tymi uprawnieniami Graph, których wymagają jego playbooki, ograniczoną jednostkami administracyjnymi do kont standardowych; listę chronioną egzekwuje sam katalog
  • Sekrety nigdy nie leżą w przepływie: robot pobiera je w czasie wykonania z Azure Key Vault przez magazyn poświadczeń Orchestrator, a dziennik audytu Orchestrator rejestruje każde zadanie i ponowienie
  • Każde działanie zapisuje się z identyfikatorem incydentu, wersją reguły i wynikiem w rekordzie Data Fabric i w zgłoszeniu ServiceNow, więc każde powstrzymanie da się odtworzyć
  • Tabele reguł zmieniają się wyłącznie przez przeglądnięte wydanie z imiennie wskazanym zatwierdzającym w zespole bezpieczeństwa
  • Dane kadrowe ograniczają się do statusu i przełożonego. Przetwarzanie pozostaje w Państwa tenancie Microsoft 365 w granicach EU Data Boundary i w regionie EU UiPath Automation Cloud; żaden model językowy nie bierze w tym udziału

Dlaczego teraz

01

NIS2 uruchamia zegar wczesnego ostrzeżenia w chwili powzięcia wiedzy, a ta ma znacznik czasu w Sentinel. Reakcja, która czeka do poniedziałku, to opóźnienie podlegające zgłoszeniu, a ubezpieczyciele pytają o średni czas do powstrzymania w formularzu odnowienia polisy

02

Wykrywanie jest w większości środowisk Microsoft 365 E5 gotowe: Entra ID Protection i Sentinel są licencjonowane i działają. Godziny leżą w reakcji: modelowane 7 700 € miesięcznie z tabeli powyżej

03

Reguły automatyzacji Sentinel, wyzwalacze API Orchestrator, ograniczone uprawnienia Graph i zadania Action Center w Teams to udokumentowane funkcje; złożenie ich w całość to inżynieria, nie badania

Kluczowe role zarządcze

CISO

Średni czas do powstrzymania staje się minutami dla spraw rutynowych i raportowaną liczbą dla wszystkich, według typu wykrycia i zmiany

CIO

Zespół bezpieczeństwa skaluje się wraz z wykryciami bez dodawania zmian, a service desk przestaje wykonywać telefony bezpieczeństwa, których nie może rozwiązać

Szef service desku

Oddzwanianie znika ze statystyk desku; widzi on tylko użytkowników, do których Teams nie dotarł, z dołączonym materiałem dowodowym

Najczęstsze pytania i obiekcje

Nasz dostawca SOC już to obsługuje.

Obsługuje triage. Powstrzymanie nadal wymaga kogoś z uprawnieniami w Państwa tenancie i znajomością Państwa danych kadrowych. Robot daje dostawcy zadanie i zgłoszenie zamiast e‑maila do Państwa administratora.

Automatyczne wyłączanie zablokuje członka zarządu.

Konta chronione nigdy nie docierają do robota powstrzymującego; uniemożliwia to sam katalog, a trafiają one zawsze do analityka. Konta pierwszej linii na współdzielonych urządzeniach dostają zadanie potwierdzenia, nie blokadę.

Conditional Access już blokuje ryzykowne logowania.

Blokuje albo dodatkowo weryfikuje logowanie i tak powinno być. Nie otwiera zgłoszenia, nie sprawdza, czy osoba odeszła w zeszłym miesiącu, nie unieważnia istniejących sesji i nie informuje przełożonego; to właśnie jest praca ręczna.

Kiedy to nie jest właściwe rozwiązanie

  • Brak Entra ID P2 albo Sentinel: brakuje sygnału i najpierw trzeba uporządkować licencje
  • Platforma SOAR już wykonuje te playbooki; wtedy roboty pokrywają tylko systemy, do których ona nie sięga, jak HR i kolejka zgłoszeń
  • Mniej niż około tysiąca użytkowników, gdzie wolumen incydentów rzadko uzasadnia playbooki, a dyżur z właściwymi uprawnieniami załatwia większość spraw

Pytanie na najbliższe posiedzenie

Gdyby napastnik zalogował się na jedno z naszych kont w sobotę rano, kiedy dowiedziałby się o tym ktoś z uprawnieniami do zablokowania go i który zapis by to udowodnił?

Podejście wdrożeniowe

Co dokładnie dostarczamy i czego potrzebujemy na start.

Dostarczamy

  • Klasyfikację Państwa incydentów z ostatniego kwartału według typu wykrycia i klasy konta, z jednym projektem playbooka na typ uzgodnionym z bezpieczeństwem, HR i service deskiem
  • Tabele reguł, z listą kont chronionych egzekwowaną w katalogu, a nie w regułach
  • Roboty wzbogacający i powstrzymujący, playbook Logic Apps i wyzwalacz API Orchestrator, które łączą z nimi Sentinel
  • Karty dla użytkownika i przełożonego, zadanie analityka, szablon zgłoszenia ServiceNow, rekord dowodowy i raport Power BI
  • Kilka tygodni pracy w trybie „tylko rekomenduj”, żeby analitycy widzieli, co robot by zrobił, zanim to zrobi

Potrzebujemy od Państwa

  • Wdrożonych Entra ID P2 i Sentinel oraz eksportu incydentów z ostatniego kwartału z usuniętymi nazwiskami
  • Zasilenia statusem zatrudnienia i przełożonym z Workday, ograniczonego do tych dwóch pól
  • Listy kont chronionych i właściciela tabel reguł w zespole bezpieczeństwa
  • Jednostki usługi (service principal) dla robota powstrzymującego, ograniczonej jednostkami administracyjnymi do kont standardowych

Etapy

Rozpoznanie

Klasyfikacja incydentów z ostatniego kwartału; uzgodnione typy wykryć, klasy kont i lista chroniona

Projekt

Tabele reguł, playbooki, szablony zgłoszeń, karty, model bezpieczeństwa i uprawnienia Graph

Budowa

Roboty wzbogacający i powstrzymujący, przekazanie z Sentinel, zadania i karty w Teams, rekord dowodowy, raport

Tryb „tylko rekomenduj”

Każdy playbook proponuje, ale nie działa; analitycy przez kilka tygodni poprawiają reguły

Uruchomienie bezobsługowe

Rutynowe powstrzymanie na kontach standardowych działa bez nadzoru; konta chronione pozostają za analitykiem

Skalowanie

Nocny dostawca pracuje na tych samych kartach; nowe typy wykryć stają się playbookami

Działowe. O nakładzie decyduje liczba utrzymywanych typów wykryć, jakość zasilenia kadrowego i inwentarza kont oraz systemy poza ServiceNow, które muszą nieść zgłoszenie.