Udostępnij za pośrednictwem


Krok nr 5. Opracowywanie i testowanie przypadków użycia

Dotyczy:

  • Microsoft Defender XDR

Zalecane metody wdrażania Microsoft Defender XDR w centrum operacji zabezpieczeń (SOC) zależą od bieżącego zestawu narzędzi, procesów i zestawu umiejętności zespołu SOC. Utrzymanie higieny cybernetycznej na różnych platformach może być trudne ze względu na ogromną ilość danych pochodzących z dziesiątek, jeśli nie setek źródeł bezpieczeństwa.

Narzędzia zabezpieczeń są ze sobą powiązane. Włączenie jednej funkcji w technologii zabezpieczeń lub zmiana procesu może z kolei złamać inną. Z tego powodu firma Microsoft zaleca zespołowi SOC sformalizowanie metody definiowania i określania priorytetów przypadków użycia. Przypadki użycia ułatwiają definiowanie wymagań i procesów testowych dla operacji SOC w różnych zespołach. Tworzy metodologię przechwytywania metryk, aby określić, czy odpowiednie role i kombinacja zadań są dopasowane do odpowiedniego zespołu z odpowiednim zestawem umiejętności.

Opracowywanie i formalizowanie procesu przypadków użycia

SOC powinna zdefiniować wysoki poziom standardu i proces opracowywania przypadków użycia, które byłyby regulowane przez zespół nadzoru SOC. Zespół nadzoru SOC powinien współpracować z Twoją firmą, działem IT, działem prawnym, kadrą i innymi grupami, aby ustalić priorytet przypadków użycia soc, które ostatecznie trafią do elementów runbook i podręczników zespołu SOC. Priorytetowe przypadki użycia są oparte na celach, takich jak zgodność lub prywatność.

Działania związane z nadzorem SOC związane z opracowywaniem przypadków użycia obejmują:

  • Wymagania
  • Potrzeby kadrowe lub szkoleniowe
  • Licencje na oprogramowanie
  • Kontraktowanie dostawcy
  • Zarządzanie planem
  • Obsługa rejestru przypadków użycia
  • Obsługa/aktualizowanie szablonów

Aby ułatwić procesy tworzenia elementów runbook i podręczników, utwórz drzewo decyzyjne przypadków użycia. Na tej ilustracji przedstawiono przykład.

Proces podejmowania decyzji w sprawie użycia

Po zdefiniowaniu i zatwierdzeniu standardowego przypadku użycia wysokiego poziomu następnym krokiem jest utworzenie i przetestowanie rzeczywistego przypadku użycia. W poniższych sekcjach użyto scenariuszy ochrony przed wyłudzaniem informacji i zagrożeń oraz skanowania luk w zabezpieczeniach jako przykładów.

Przykład przypadku użycia 1: nowy wariant wyłudzania informacji

Pierwszym krokiem tworzenia przypadku użycia jest przedstawienie przepływu pracy przy użyciu tablicy scenariuszy. Oto przykład tablicy historii wysokiego poziomu dla nowego powiadomienia o wyłudzaniu informacji dla zespołu analizy zagrożeń.

Przepływ pracy przypadku użycia kampanii chroniącej przed wyłudzaniem informacji

Wywołaj przepływ pracy przypadku użycia, na przykład 1

Po zatwierdzeniu tablicy scenariuszy następnym krokiem jest wywołanie przepływu pracy przypadków użycia. Oto przykładowy proces kampanii chroniącej przed wyłudzaniem informacji.

Szczegółowy przepływ pracy przypadków użycia dla kampanii chroniącej przed wyłudzaniem informacji

Przykład przypadku użycia 2: skanowanie zagrożeń i luk w zabezpieczeniach

Innym scenariuszem, w którym można użyć przypadku użycia, jest skanowanie zagrożeń i luk w zabezpieczeniach. W tym przykładzie soc wymaga, aby zagrożenia i luki w zabezpieczeniach były korygowane względem zasobów za pośrednictwem zatwierdzonych procesów, które obejmują skanowanie zasobów.

Oto przykładowa scenorys wysokiego poziomu dla Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft Defender zasobów.

Przepływ pracy przypadku użycia dla Zarządzanie zagrożeniami i lukami

Wywołaj przepływ pracy przypadku użycia, na przykład 2

Oto przykładowy proces skanowania zagrożeń i luk w zabezpieczeniach.

Szczegółowy przepływ pracy przypadków użycia dla Zarządzanie zagrożeniami i lukami

Analizowanie danych wyjściowych przypadków użycia i wyciągniętych wniosków

Po zatwierdzeniu i przetestowaniu przypadku użycia należy zidentyfikować luki między zespołami ds. zabezpieczeń wraz z osobami, procesami i zaangażowanymi technologiami Microsoft Defender XDR. Microsoft Defender XDR technologie powinny być analizowane w celu określenia, czy są w stanie osiągnąć pożądane wyniki. Można je śledzić za pomocą listy kontrolnej lub macierzy.

Na przykład w przykładzie scenariusza ochrony przed wyłudzaniem informacji zespoły SOC mogły wprowadzić odkrycia w tej tabeli.

Zespół SOC Wymóg Osoby spełniać wymagania Proces spełniający wymagania Odpowiednia technologia Zidentyfikowano lukę Dziennik zmian przypadków użycia Wykluczenie (Y/N)
Zespół ds. analizy zagrożeń i analizy Źródła danych prawidłowo zasilają aparaty analizy zagrożeń. Analityk/inżynier analizy zagrożeń Ustanowione wymagania dotyczące źródła danych, wyzwalacze analizy zagrożeń z zatwierdzonych źródeł Microsoft Defender for Identity, Ochrona punktu końcowego w usłudze Microsoft Defender Zespół analizy zagrożeń nie używał skryptu automatyzacji do łączenia interfejsu API Microsoft Defender XDR z aparatami intel zagrożeń Dodawanie Microsoft Defender XDR jako źródeł danych do aparatów zagrożeń

Aktualizowanie książki przebiegu przypadku użycia

N
Zespół ds. monitorowania Źródła danych prawidłowo podają pulpity nawigacyjne monitorowania Alerty & monitorowania & warstwy 1,2 SOC Przepływ pracy raportowania wskaźnika bezpieczeństwa centrum zgodności & zabezpieczeń Badanie alertów w Microsoft Defender XDR

Monitorowanie wskaźnika bezpieczeństwa

Brak mechanizmu zgłaszania przez analityków SOC pomyślnego wykrywania nowych wariantów wyłudzania informacji w celu poprawy wskaźnika bezpieczeństwa

Wyświetlanie raportów zabezpieczeń poczty e-mail w portalu Microsoft Defender

Dodawanie procesu śledzenia poprawy wskaźnika bezpieczeństwa do przepływów pracy raportowania N
Zespół inżynierów i secops Aktualizacje kontroli zmian są wprowadzane w elementach Runbook zespołu SOC Inżynier SOC warstwy 2 Procedura powiadamiania o zmianie kontrolki dla elementów Runbook zespołu SOC Zatwierdzone zmiany w urządzeniach zabezpieczeń Zmiany Microsoft Defender XDR łączności z technologią zabezpieczeń SOC wymagają zatwierdzenia Dodaj Microsoft Defender for Cloud Apps, Defender for Identity, Defender for Endpoint, Security & Compliance Center do elementów runbook SOC T

Ponadto zespoły SOC mogły wykonać odkrycia opisane w poniższej tabeli w odniesieniu do scenariusza zarządzania lukami w zabezpieczeniach usługi Defender opisanego powyżej:

Zespół SOC Wymóg Osoby spełniać wymagania Proces spełniający wymagania Odpowiednia technologia Zidentyfikowano lukę Dziennik zmian przypadków użycia Wykluczenie (Y/N)
Nadzór SOC Wszystkie zasoby połączone z zatwierdzonymi sieciami są identyfikowane i kategoryzowane Nadzór SOC, właściciele BU, właściciele aplikacji, właściciele zasobów IT itp. Scentralizowany system zarządzania zasobami umożliwiający odnajdywanie i wyświetlanie listy kategorii i atrybutów zasobów na podstawie ryzyka. ServiceNow lub inne zasoby.

Spis urządzeń platformy Microsoft 365
Odnaleziono tylko 70% zasobów. Microsoft Defender XDR śledzenie korygowania obowiązujące tylko w przypadku znanych zasobów Dojrzałe usługi zarządzania cyklem życia zasobów w celu zapewnienia, że Microsoft Defender XDR ma 100% pokrycia N
Zespół inżynierów & SecOps Wysoki wpływ i krytyczne luki w zabezpieczeniach zasobów są korygowane zgodnie z zasadami Inżynierowie secOps, analitycy SOC: luka w zabezpieczeniach & zgodności, inżynieria zabezpieczeń Zdefiniowany proces kategoryzowania luk w zabezpieczeniach wysokiego ryzyka i krytycznych pulpity nawigacyjne Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft Defender Usługa Defender for Endpoint zidentyfikowała urządzenia o dużym wpływie i wysokim poziomie alertów bez planu korygowania ani implementacji zalecanego działania firmy Microsoft Dodaj przepływ pracy do powiadamiania właścicieli zasobów, gdy działanie korygujące jest wymagane w ciągu 30 dni dla zasad; Zaimplementuj system biletów, aby powiadomić właścicieli zasobów o krokach korygowania. N
Zespoły monitorujące Stan zagrożenia i luki w zabezpieczeniach jest zgłaszany za pośrednictwem firmowego portalu intranetowego Analityk SOC warstwy 2 Automatycznie generowane raporty z Microsoft Defender XDR pokazujące postęp korygowania zasobów Badanie alertów w Microsoft Defender XDR

Monitorowanie wskaźnika bezpieczeństwa

Brak widoków ani raportów pulpitu nawigacyjnego przekazywanych właścicielom zasobów dotyczących zagrożeń i stanu luk w zabezpieczeniach zasobów. Twórca skrypt automatyzacji, aby wypełnić stan korygowania luk w zabezpieczeniach zasobów o wysokim ryzyku i krytycznym znaczeniu dla organizacji. N

W takich przykładowych przypadkach użycia testy ujawniły kilka luk w wymaganiach zespołu SOC, które zostały ustanowione jako punkty odniesienia dla obowiązków każdego zespołu. Lista kontrolna przypadków użycia może być tak kompleksowa, jak to konieczne, aby upewnić się, że zespół SOC jest przygotowany do integracji Microsoft Defender XDR z nowymi lub istniejącymi wymaganiami SOC. Ponieważ jest to proces iteracyjny, proces tworzenia przypadków użycia i zawartość wyjściowa przypadku użycia naturalnie służą do aktualizowania i dojrzewania elementów Runbook SOC z wyciągniętymi doświadczeniami.

Aktualizowanie produkcyjnych elementów Runbook i podręczników

Po skorygowaniu wszystkich luk w testach przypadków użycia zebrane w nich wnioski i metryki można włączyć do produkcyjnych elementów Runbook zespołu SOC (procesów operacyjnych) i podręczników (odpowiedzi na zdarzenia i procedury eskalacji).

Konserwację elementów runbook i podręczników zespołu SOC można organizować na wiele sposobów. Każdy zespół SOC może być odpowiedzialny za własne lub może istnieć jedna scentralizowana wersja dla wszystkich zespołów do udostępniania w centralnym repozytorium. Zarządzanie elementami runbook i podręcznikami dla poszczególnych organizacji zależy od rozmiaru, zestawu umiejętności, ról i podziału obowiązków. Po zaktualizowaniu elementu Runbook powinien nastąpić proces aktualizacji podręcznika.

Używanie standardowej struktury na potrzeby eskalacji

Podręczniki to kroki, które zespoły SOC muszą wykonać w przypadku wystąpienia rzeczywistego zdarzenia w oparciu o pomyślną integrację i test przypadku użycia. Dlatego konieczne jest, aby SOC przestrzegała sformalizowanego podejścia do reagowania na zdarzenia, takiego jak NIST Incident Response Standard , który stał się jednym z wiodących standardów branżowych w zakresie reagowania na zdarzenia.

Czteroetapowy proces reagowania na zdarzenia NIST obejmuje cztery fazy:

  1. Przygotowanie
  2. Wykrywanie i analiza
  3. Hermetyzowanie, eliminowanie i odzyskiwanie
  4. Działanie po zdarzeniu

Przykład: Śledzenie działania fazy przygotowywania

Jednym z podstawowych podstaw podręcznika eskalacji jest zapewnienie niewielkiej dwuznaczności co do tego, co każdy zespół SOC ma robić przed, w trakcie i po zdarzeniu lub zdarzeniu. W związku z tym dobrym rozwiązaniem jest wyświetlenie listy instrukcji krok po kroku.

Na przykład faza przygotowania może obejmować macierz zadań if/then lub XoR. W przypadku nowego przykładowego przypadku użycia wariantu wyłudzania informacji taka macierz może wyglądać następująco:

Dlaczego eskalacja jest uzasadniona? Następny krok
Alert w monitorowaniu SOC oceniony jako wyzwalany krytycznie>przez 500/godzinę Przejdź do podręcznika A, sekcji 2, działania 5 (z linkiem do sekcji podręcznika)
eCommerce zgłosiło potencjalny atak DDoS Wywoływanie podręcznika B-Sekcja C, Działanie 19 (z linkiem do sekcji podręcznika)
Kierownictwo zgłosiło podejrzaną wiadomość e-mail jako próbę wyłudzania informacji Przejdź do podręcznika 5, sekcji 2, działania 5 (z linkiem do sekcji podręcznika)

Po wykonaniu fazy przygotowania organizacje powinny wywoływać pozostałe fazy zgodnie z opisem WUS:

  • Wykrywanie i analiza
  • Hermetyzowanie, eliminowanie i odzyskiwanie
  • Działanie po zdarzeniu

Następny krok

Krok 6. Identyfikowanie zadań konserwacji SOC

Porada

Chcesz dowiedzieć się więcej? Zaangażuj się w społeczność rozwiązań zabezpieczających firmy Microsoft w naszej społeczności technicznej Społeczność techniczna usługi Microsoft Defender XDR.