Zalecenia dotyczące reagowania na zdarzenia zabezpieczeń

Dotyczy rekomendacji listy kontrolnej zabezpieczeń platformy Azure Well-Architected Framework:

SE:12	Zdefiniuj i przetestuj efektywne procedury reagowania na zdarzenia, które obejmują spektrum zdarzeń, od zlokalizowanych problemów po odzyskiwanie po awarię. Jasno zdefiniuj, który zespół lub osoba uruchamia procedurę.

W tym przewodniku opisano zalecenia dotyczące implementowania reagowania na zdarzenia zabezpieczeń dla obciążenia. W przypadku naruszenia zabezpieczeń systemu systematyczne podejście reagowania na zdarzenia pomaga skrócić czas potrzebny na identyfikowanie i eliminowanie zdarzeń zabezpieczeń oraz zarządzanie nimi. Zdarzenia te mogą zagrażać poufności, integralności i dostępności systemów i danych oprogramowania.

Większość przedsiębiorstw ma centralny zespół ds. operacji zabezpieczeń (znany również jako Security Operations Center (SOC) lub SecOps. Odpowiedzialność zespołu ds. operacji zabezpieczeń polega na szybkim wykrywaniu, określaniu priorytetów i klasyfikacji potencjalnych ataków. Zespół monitoruje również dane telemetryczne związane z zabezpieczeniami i bada naruszenia zabezpieczeń.

Jednak masz również odpowiedzialność za ochronę obciążenia. Ważne jest, aby każda komunikacja, badanie i działania wyszukiwania zagrożeń to wspólny wysiłek między zespołem ds. obciążeń i zespołem SecOps.

Ten przewodnik zawiera zalecenia dla Ciebie i twojego zespołu ds. obciążeń, które ułatwiają szybkie wykrywanie, klasyfikację i badanie ataków.

Definicje

Okres	Definicja
Alerty	Powiadomienie zawierające informacje o zdarzeniu.
Wierność alertu	Dokładność danych określających alert. Alerty o wysokiej wierności zawierają kontekst zabezpieczeń, który jest potrzebny do podjęcia natychmiastowych działań. Alerty o niskiej wierności nie zawierają informacji lub zawierają szum.
Wynik fałszywie dodatni	Alert informujący o incydencie, który się nie wydarzył.
Zdarzenie	Zdarzenie wskazujące nieautoryzowany dostęp do systemu.
Reagowanie na zdarzenia	Proces, który wykrywa, reaguje i ogranicza ryzyko związane z incydentem.
Triage (klasyfikacja)	Operacja reagowania na zdarzenia, która analizuje problemy z zabezpieczeniami i określa ich priorytety.

Kluczowe strategie projektowania

Ty i Twój zespół wykonują operacje reagowania na zdarzenia, gdy wystąpi sygnał lub alert dotyczący potencjalnego naruszenia zabezpieczeń. Alerty o wysokiej wierności zawierają duży kontekst zabezpieczeń, który ułatwia analitykom podejmowanie decyzji. Alerty o wysokiej wierności powodują niską liczbę wyników fałszywie dodatnich. W tym przewodniku założono, że system alertów filtruje sygnały o niskiej wierności i koncentruje się na alertach o wysokiej wierności, które mogą wskazywać na rzeczywiste zdarzenie.

Przypisywanie powiadomienia o zdarzeniu

Alerty zabezpieczeń muszą docierać do odpowiednich osób w zespole i w organizacji. Ustanów wyznaczony punkt kontaktu w zespole ds. obciążeń, aby otrzymywać powiadomienia o zdarzeniach. Powiadomienia te powinny zawierać jak najwięcej informacji o zasobie, który został naruszony i system. Alert musi zawierać kolejne kroki, aby zespół mógł przyspieszyć działania.

Zalecamy rejestrowanie powiadomień i akcji dotyczących zdarzeń oraz zarządzanie nimi przy użyciu wyspecjalizowanego narzędzia, które przechowuje dziennik inspekcji. Korzystając ze standardowych narzędzi, można zachować dowody, które mogą być wymagane do potencjalnych dochodzeń prawnych. Poszukaj możliwości wdrożenia automatyzacji, która może wysyłać powiadomienia na podstawie obowiązków podmiotów odpowiedzialnych. Zachowaj jasny łańcuch komunikacji i raportowania podczas zdarzenia.

Korzystaj z rozwiązań do zarządzania zdarzeniami zabezpieczeń (SIEM) i rozwiązań automatycznego reagowania na zabezpieczenia (SOAR), które zapewnia Organizacja. Alternatywnie możesz uzyskać narzędzia do zarządzania zdarzeniami i zachęcić organizację do standaryzacji ich dla wszystkich zespołów obciążeń.

Badanie za pomocą zespołu klasyfikacji

Członek zespołu, który otrzymuje powiadomienie o zdarzeniu, jest odpowiedzialny za skonfigurowanie procesu klasyfikacji, który obejmuje odpowiednie osoby na podstawie dostępnych danych. Zespół klasyfikacji, często nazywany zespołem mostka, musi zgodzić się na tryb i proces komunikacji. Czy to zdarzenie wymaga asynchronicznych dyskusji lub wywołań mostka? Jak zespół powinien śledzić i komunikować postępy w badaniach? Gdzie zespół może uzyskiwać dostęp do zasobów incydentów?

Reagowanie na zdarzenia to kluczowy powód, aby zapewnić aktualność dokumentacji, na przykład układ architektury systemu, informacje na poziomie składnika, klasyfikację prywatności lub klasyfikację zabezpieczeń, właścicieli i kluczowe punkty kontaktu. Jeśli informacje są niedokładne lub nieaktualne, zespół mostu traci cenny czas, próbując zrozumieć, jak działa system, kto jest odpowiedzialny za poszczególne obszary i jaki może być wpływ zdarzenia.

W celu przeprowadzenia dalszych badań należy zaangażować odpowiednie osoby. Możesz uwzględnić menedżera zdarzeń, oficera zabezpieczeń lub potencjalnych klientów skoncentrowanych na obciążeniach. Aby zachować fokus klasyfikacji, wyklucz osoby spoza zakresu problemu. Czasami oddzielne zespoły badają incydent. Może istnieć zespół, który początkowo bada problem i próbuje rozwiązać ten problem, a inny wyspecjalizowany zespół, który może wykonywać kryminalistyki w celu głębokiego badania w celu ustalenia szerokich problemów. Środowisko obciążenia można poddać kwarantannie, aby umożliwić zespołowi kryminalistycznemu wykonywanie badań. W niektórych przypadkach ten sam zespół może obsłużyć całe dochodzenie.

W początkowej fazie zespół klasyfikacji jest odpowiedzialny za określenie potencjalnego wektora i jego wpływu na poufność, integralność i dostępność (nazywaną również CIA) systemu.

W ramach kategorii CIA przypisz początkowy poziom ważności, który wskazuje głębokość uszkodzenia i pilność korygowania. Oczekuje się, że ten poziom zmieni się wraz z upływem czasu, ponieważ więcej informacji zostanie odnalezionych na poziomie klasyfikacji.

W fazie odnajdywania ważne jest, aby określić natychmiastowy przebieg działań i planów komunikacyjnych. Czy istnieją jakieś zmiany w stanie uruchamiania systemu? Jak można powstrzymać atak, aby zatrzymać dalsze wykorzystanie? Czy zespół musi wysłać komunikację wewnętrzną lub zewnętrzną, taką jak odpowiedzialne ujawnienie? Rozważ wykrywanie i czas odpowiedzi. Możesz być prawnie zobowiązany do zgłaszania niektórych rodzajów naruszeń do organu regulacyjnego w określonym przedziale czasu, który jest często godzinami lub dniami.

Jeśli zdecydujesz się zamknąć system, następne kroki prowadzą do procesu odzyskiwania po awarii (DR) obciążenia.

Jeśli system nie zostanie zamknięty, określ, jak skorygować zdarzenie bez wpływu na funkcjonalność systemu.

Odzyskiwanie po zdarzeniu

Traktuj zdarzenie zabezpieczeń, takie jak awaria. Jeśli korygowanie wymaga ukończenia odzyskiwania, użyj odpowiednich mechanizmów odzyskiwania po awarii z perspektywy zabezpieczeń. Proces odzyskiwania musi zapobiegać wystąpieniu prawdopodobieństwa cyklu. W przeciwnym razie odzyskiwanie z uszkodzonej kopii zapasowej ponownie wprowadza problem. Ponowne wdrażanie systemu z tą samą luką w zabezpieczeniach prowadzi do tego samego zdarzenia. Sprawdź poprawność kroków i procesów trybu failover i powrotu po awarii.

Jeśli system nadal działa, oceń wpływ na uruchomione części systemu. Kontynuuj monitorowanie systemu, aby upewnić się, że inne cele dotyczące niezawodności i wydajności są spełnione lub ponownie spełnione przez wdrożenie odpowiednich procesów degradacji. Nie naruszaj prywatności z powodu ograniczania ryzyka.

Diagnostyka jest procesem interaktywnym do momentu zidentyfikowania wektora oraz potencjalnej poprawki i powrotu. Po zdiagnozowaniu zespół pracuje nad korygowaniem, który identyfikuje i stosuje wymaganą poprawkę w akceptowalnym okresie.

Metryki odzyskiwania mierzą czas potrzebny do rozwiązania problemu. W przypadku zamknięcia może istnieć pilność dotycząca czasów korygowania. Aby ustabilizować system, stosowanie poprawek, poprawek i testów oraz wdrażanie aktualizacji zajmuje trochę czasu. Określ strategie ograniczania, aby zapobiec dalszym szkodom i rozprzestrzenianiu się incydentu. Opracowanie procedur eliminacji w celu całkowitego usunięcia zagrożenia ze środowiska.

Kompromis: Istnieje kompromis między celami niezawodności a czasem korygowania. Podczas zdarzenia prawdopodobnie nie spełniasz innych wymagań niefunkcjonalnych ani funkcjonalnych. Na przykład może być konieczne wyłączenie części systemu podczas badania zdarzenia lub może być konieczne przełączenie całego systemu w tryb offline do momentu określenia zakresu zdarzenia. Osoby podejmujące decyzje biznesowe muszą jawnie zdecydować, jakie są dopuszczalne cele podczas incydentu. Jasno określ osobę, która jest odpowiedzialna za daną decyzję.

Informacje na temat zdarzenia

Zdarzenie ujawnia luki lub punkty podatne na zagrożenia w projekcie lub implementacji. Jest to szansa na poprawę, która jest oparta na lekcjach dotyczących aspektów projektowania technicznego, automatyzacji, procesów opracowywania produktów, które obejmują testowanie i skuteczność procesu reagowania na zdarzenia. Zachowaj szczegółowe rekordy zdarzeń, w tym akcje podjęte, osie czasu i wyniki.

Zdecydowanie zalecamy przeprowadzanie strukturalnych przeglądów po zdarzeniu, takich jak analiza głównej przyczyny i retrospektywy. Śledź i ustalaj priorytety wyników tych przeglądów i rozważ użycie tego, czego nauczysz się w przyszłych projektach obciążeń.

Plany poprawy powinny obejmować aktualizacje prób i testowania zabezpieczeń, takie jak próbne ciągłości działania i odzyskiwanie po awarii (BCDR). Użyj kompromisu zabezpieczeń jako scenariusza przeprowadzania przechodzenia do szczegółów BCDR. Przechodzenie do szczegółów może sprawdzić, jak działają udokumentowane procesy. Nie powinno być wielu podręczników reagowania na zdarzenia. Użyj pojedynczego źródła, które można dostosować na podstawie rozmiaru zdarzenia i powszechnej lub zlokalizowanej efektu. Ćwiczenia są oparte na hipotetycznych sytuacjach. Przeprowadź ćwiczenia w środowisku o niskim ryzyku i uwzględnij fazę nauki w ćwiczeniach.

Przeprowadź przeglądy po zdarzeniu lub postmortems, aby zidentyfikować słabe strony w procesie reagowania i obszarach poprawy. Na podstawie lekcji uzyskanych z incydentu zaktualizuj plan reagowania na zdarzenia (IRP) i mechanizmy kontroli zabezpieczeń.

Wysyłanie niezbędnej komunikacji

Zaimplementuj plan komunikacji, aby powiadomić użytkowników o zakłóceniach i poinformować zainteresowanych stron o korygowaniu i ulepszeniach. Inne osoby w organizacji muszą otrzymywać powiadomienia o wszelkich zmianach w punkcie odniesienia zabezpieczeń obciążenia, aby zapobiec przyszłym zdarzeniu.

Generowanie raportów zdarzeń do użytku wewnętrznego i, w razie potrzeby, w celu zapewnienia zgodności z przepisami lub celów prawnych. Ponadto należy przyjąć standardowy raport formatu (szablon dokumentu ze zdefiniowanymi sekcjami), który zespół SOC używa dla wszystkich zdarzeń. Przed zamknięciem badania upewnij się, że każdy incydent ma skojarzony z nim raport.

Ułatwienia platformy Azure

Microsoft Sentinel to rozwiązanie SIEM i SOAR. Jest to jedno rozwiązanie do wykrywania alertów, widoczności zagrożeń, proaktywnego wyszukiwania zagrożeń i reagowania na zagrożenia. Aby uzyskać więcej informacji, zobacz Co to jest usługa Microsoft Sentinel?

Upewnij się, że portal rejestracji platformy Azure zawiera informacje kontaktowe administratora, aby operacje zabezpieczeń mogły być powiadamiane bezpośrednio za pośrednictwem procesu wewnętrznego. Aby uzyskać więcej informacji, zobacz Aktualizowanie ustawień powiadomień.

Aby dowiedzieć się więcej na temat ustanawiania wyznaczonego punktu kontaktu, który odbiera powiadomienia o zdarzeniach platformy Azure z Microsoft Defender dla chmury, zobacz Konfigurowanie powiadomień e-mail dotyczących alertów zabezpieczeń.

Dopasowanie organizacji

Cloud Adoption Framework dla platformy Azure zawiera wskazówki dotyczące planowania reagowania na zdarzenia i operacji zabezpieczeń. Aby uzyskać więcej informacji, zobacz Operacje zabezpieczeń.

Linki pokrewne

• Automatyczne tworzenie zdarzeń na podstawie alertów zabezpieczeń firmy Microsoft
• Przeprowadzanie kompleksowego wyszukiwania zagrożeń przy użyciu funkcji polowania
• Konfigurowanie powiadomień e-mail na potrzeby alertów zabezpieczeń
• Omówienie reagowania na zdarzenia
• Gotowość zdarzenia platformy Microsoft Azure
• Nawigacja i badanie zdarzeń w usłudze Microsoft Sentinel
• Kontrola zabezpieczeń: reagowanie na zdarzenia
• Rozwiązania SOAR w usłudze Microsoft Sentinel
• Szkolenie: wprowadzenie do gotowości zdarzeń platformy Azure
• Aktualizowanie ustawień powiadomień Azure Portal
• Co to jest SOC?
• Co to jest usługa Microsoft Sentinel?

Lista kontrolna zabezpieczeń

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna zabezpieczeń