Zalecenia dotyczące testowania zabezpieczeń
Dotyczy tego zalecenia listy kontrolnej zabezpieczeń usługi Azure Well-Architected Framework:
| SE:11 | Ustanów kompleksowy schemat testowania, który łączy podejścia w celu zapobiegania problemom z zabezpieczeniami, weryfikowania implementacji zapobiegania zagrożeniom i testowania mechanizmów wykrywania zagrożeń. |
|---|
Rygorystyczne testowanie jest podstawą dobrego projektu zabezpieczeń. Testowanie jest taktyczną formą weryfikacji, aby upewnić się, że kontrolki działają zgodnie z oczekiwaniami. Testowanie to również proaktywny sposób wykrywania luk w zabezpieczeniach systemu.
Ustanów rygor testowania za pomocą cykli i weryfikacji z wielu perspektyw. Należy uwzględnić wewnętrzne punkty widzenia, które testuje platformę i infrastrukturę oraz oceny zewnętrzne testujące system, taki jak zewnętrzna osoba atakująca.
Ten przewodnik zawiera zalecenia dotyczące testowania stanu zabezpieczeń obciążenia. Zaimplementuj te metody testowania, aby zwiększyć odporność obciążenia na ataki i zachować poufność, integralność i dostępność zasobów.
Definicje
| Okres | Definicja |
|---|---|
| Testowanie zabezpieczeń aplikacji (AST) | Technika cyklu życia programowania zabezpieczeń firmy Microsoft (SDL) korzystająca z metodologii testowania białych i czarnych ramek do sprawdzania luk w zabezpieczeniach w kodzie. |
| Testowanie czarnej skrzynki | Metodologia testowania, która weryfikuje zewnętrznie widoczne zachowanie aplikacji bez znajomości wewnętrznych elementów systemu. |
| Niebieski zespół | Zespół, który broni się przed atakami czerwonej drużyny w ćwiczeniu gry wojennej. |
| Testy penetracyjne | Metodologia testowania wykorzystująca etyczne techniki hakerskie do weryfikowania zabezpieczeń systemu. |
| Czerwony zespół | Zespół, który odgrywa rolę przeciwnika i próbuje włamać się do systemu w ćwiczeniu gry wojennej. |
| Security Development Lifecycle (SDL) | Zestaw rozwiązań oferowanych przez firmę Microsoft, które obsługują wymagania dotyczące zapewniania zabezpieczeń i zgodności. |
| Cykl życia tworzenia oprogramowania (SDLC) | Wieloestopniowy, systematyczny proces tworzenia systemów oprogramowania. |
| Testowanie białej skrzynki | Metodologia testowania, w której struktura kodu jest znana praktykowi. |
Kluczowe strategie projektowania
Testowanie jest strategią nienegocjacyjną, szczególnie w przypadku zabezpieczeń. Umożliwia ono proaktywne odnajdywanie i rozwiązywanie problemów z zabezpieczeniami przed ich wykorzystaniem oraz sprawdzenie, czy wdrożone mechanizmy kontroli zabezpieczeń działają zgodnie z założeniami.
Zakres testowania musi obejmować aplikacje, infrastrukturę oraz procesy zautomatyzowane i ludzkie.
Uwaga
Te wskazówki rozróżniają testowanie i reagowanie na zdarzenia. Mimo że testowanie jest mechanizmem wykrywania, który idealnie rozwiązuje problemy przed produkcją, nie należy go mylić z korygowaniem ani badaniem wykonywanym w ramach reagowania na zdarzenia. Aspekt odzyskiwania po zdarzeniach zabezpieczeń został opisany w temacie Zalecenia dotyczące reagowania na zdarzenia.
SDL obejmuje kilka typów testów, które przechwytują luki w kodzie, weryfikują składniki środowiska uruchomieniowego i używają etycznego hakowania w celu przetestowania odporności systemu na zabezpieczenia. SDL to kluczowe działanie shift-left. Należy uruchamiać testy, takie jak analiza kodu statycznego i automatyczne skanowanie infrastruktury jako kodu (IaC), jak najszybciej w procesie programowania.
Zaangażuj się w planowanie testów. Zespół ds. obciążeń może nie projektować przypadków testowych. To zadanie jest często scentralizowane w przedsiębiorstwie lub wykonywane przez zewnętrznych ekspertów ds. zabezpieczeń. Zespół ds. obciążeń powinien być zaangażowany w ten proces projektowania, aby zapewnić integrację gwarancji zabezpieczeń z funkcjonalnością aplikacji.
Pomyśl jak osoba atakująca. Zaprojektuj przypadki testowe przy założeniu, że system został zaatakowany. Dzięki temu można wykryć potencjalne luki w zabezpieczeniach i odpowiednio określić priorytety testów.
Uruchamianie testów w sposób ustrukturyzowany i przy użyciu powtarzalnego procesu. Skompiluj zestaw testów wokół cykli, typów testów, czynników jazdy i zamierzonych wyników.
Użyj odpowiedniego narzędzia dla zadania. Użyj narzędzi skonfigurowanych do pracy z obciążeniem. Jeśli nie masz narzędzia, kup to narzędzie. Nie kompiluj go. Narzędzia zabezpieczeń są wysoce wyspecjalizowane, a tworzenie własnego narzędzia może powodować ryzyko. Skorzystaj z wiedzy i narzędzi oferowanych przez centralne zespoły SecOps lub za pomocą środków zewnętrznych, jeśli zespół ds. obciążeń nie ma tej wiedzy.
Konfigurowanie oddzielnych środowisk. Testy można sklasyfikować jako destrukcyjne lub niezniszczające. Testy niezniszczalne nie są inwazyjne. Wskazują, że wystąpił problem, ale nie zmieniają funkcji w celu rozwiązania problemu. Testy destrukcyjne są inwazyjne i mogą uszkodzić funkcjonalność, usuwając dane z bazy danych.
Testowanie w środowiskach produkcyjnych zapewnia najlepsze informacje, ale powoduje najwięcej zakłóceń. Zwykle wykonujesz tylko testy niezwiązane ze strukturą w środowiskach produkcyjnych. Testowanie w środowiskach nieprodukcyjnych jest zwykle mniej uciążliwe, ale może nie odzwierciedlać dokładnie konfiguracji środowiska produkcyjnego w sposób istotny dla zabezpieczeń.
Jeśli wdrażasz przy użyciu technologii IaC i automatyzacji, rozważ utworzenie izolowanego klonu środowiska produkcyjnego na potrzeby testowania. Jeśli masz ciągły proces rutynowych testów, zalecamy użycie dedykowanego środowiska.
Zawsze oceniaj wyniki testu. Testowanie to zmarnowany wysiłek, jeśli wyniki nie są używane do określania priorytetów akcji i wprowadzania ulepszeń w górę. Udokumentowanie wytycznych dotyczących zabezpieczeń, w tym najlepszych rozwiązań, które odkryjesz. Dokumentacja, która przechwytuje wyniki i plany korygowania, kształci zespół na różne sposoby, na które osoby atakujące mogą próbować naruszyć zabezpieczenia. Przeprowadzaj regularne szkolenia w zakresie zabezpieczeń dla deweloperów, administratorów i testerów.
Podczas projektowania planów testów zastanów się nad następującymi pytaniami:
Jak często oczekujesz uruchomienia testu i jak ma to wpływ na środowisko?
Jakie są różne typy testów, które należy uruchomić?
Jak często oczekujesz, że testy będą uruchamiane?
Regularnie testuj obciążenie, aby upewnić się, że zmiany nie powodują zagrożeń bezpieczeństwa i że nie ma żadnych regresji. Zespół musi być również gotowy do reagowania na weryfikacje zabezpieczeń organizacji, które mogą być przeprowadzane w dowolnym momencie. Istnieją również testy, które można uruchomić w odpowiedzi na zdarzenie zabezpieczeń. W poniższych sekcjach przedstawiono zalecenia dotyczące częstotliwości testów.
Testy rutynowe
Rutynowe testy są przeprowadzane w regularnym tempie, w ramach standardowych procedur operacyjnych i w celu spełnienia wymagań dotyczących zgodności. Różne testy mogą być uruchamiane w różnych cyklach, ale kluczem jest to, że są one przeprowadzane okresowo i zgodnie z harmonogramem.
Należy zintegrować te testy z zestawem SDLC, ponieważ zapewniają one ochronę w głębi każdego etapu. Zdywersyfikuj zestaw testów, aby zweryfikować zabezpieczenia tożsamości, magazynu danych i transmisji oraz kanałów komunikacyjnych. Przeprowadź te same testy w różnych punktach cyklu życia, aby upewnić się, że nie ma żadnych regresji. Testy rutynowe pomagają w ustaleniu początkowego testu porównawczego. Jest to jednak tylko punkt wyjścia. W miarę odkrywania nowych problemów w tych samych punktach cyklu życia dodajesz nowe przypadki testowe. Testy są również ulepszane z powtórzeniem.
Na każdym etapie te testy powinny weryfikować kod, który został dodany lub usunięty, lub ustawienia konfiguracji, które uległy zmianie, aby wykryć wpływ tych zmian na bezpieczeństwo. Należy poprawić skuteczność testów dzięki automatyzacji, zrównoważoną recenzjami równorzędnymi.
Rozważ uruchomienie testów zabezpieczeń w ramach zautomatyzowanego potoku lub zaplanowanego przebiegu testu. Im szybciej odnajdziesz problemy z zabezpieczeniami, tym łatwiej jest znaleźć kod lub zmianę konfiguracji, która je powoduje.
Nie polegaj tylko na testach automatycznych. Używanie testowania ręcznego do wykrywania luk w zabezpieczeniach, które mogą przechwycić tylko ludzka wiedza. Testowanie ręczne jest przydatne w przypadku przypadków użycia eksploracyjnego i znajdowania nieznanych zagrożeń.
Improwizowane testy
Improwizowane testy zapewniają weryfikację zabezpieczeń do punktu w czasie. Alerty zabezpieczeń, które mogą wpływać na obciążenie w tym czasie, wyzwalają te testy. Mandaty organizacyjne mogą wymagać wstrzymywania i testowania myślenia w celu zweryfikowania skuteczności strategii obrony, jeśli alert eskaluje do sytuacji awaryjnej.
Korzyścią z improwizowanych testów jest gotowość do rzeczywistego incydentu. Te testy mogą być funkcją zmuszaną do przeprowadzania testów akceptacyjnych użytkowników (UAT).
Zespół ds. zabezpieczeń może przeprowadzać inspekcję wszystkich obciążeń i uruchamiać te testy zgodnie z potrzebami. Jako właściciel obciążenia musisz ułatwić i współpracować z zespołami ds. zabezpieczeń. Negocjuj wystarczająco dużo czasu na prowadzenie z zespołami ds. zabezpieczeń, aby można było przygotować się. Potwierdzanie i komunikowanie się z zespołem i uczestnikami projektu, że te zakłócenia są niezbędne.
W innych przypadkach może być wymagane uruchamianie testów i zgłaszanie stanu zabezpieczeń systemu pod kątem potencjalnego zagrożenia.
Kompromis: Ponieważ improwizowane testy są zakłócającymi zdarzeniami, należy oczekiwać ponownego pisania zadań, co może opóźnić inne planowane prace.
Ryzyko: istnieje ryzyko nieznanego. Improwizowane testy mogą być jednorazowe bez ustalonych procesów lub narzędzi. Ale głównym ryzykiem jest potencjalna przerwa w rytmie działalności. Należy ocenić te zagrożenia w stosunku do korzyści.
Testy zdarzeń zabezpieczeń
Istnieją testy, które wykrywają przyczynę zdarzenia zabezpieczeń w jego źródle. Te luki w zabezpieczeniach należy rozwiązać, aby upewnić się, że zdarzenie nie jest powtarzane.
Zdarzenia poprawiają również przypadki testowe w miarę upływu czasu, odkrywając istniejące luki. Zespół powinien zastosować wnioski wyciągnięte z incydentu i rutynowo wprowadzać ulepszenia.
Jakie są różne typy testów?
Testy można podzielić na kategorie według technologii i metodologii testowania. Połącz te kategorie i podejścia w tych kategoriach, aby uzyskać pełne pokrycie.
Dodając wiele testów i typów testów, można odkryć:
Luki w mechanizmach kontroli zabezpieczeń lub mechanizmach kontroli wyrównywujących.
Błędy konfiguracji.
Luki w metodach obserwacji i wykrywania.
Dobre ćwiczenie modelowania zagrożeń może wskazywać kluczowe obszary w celu zapewnienia pokrycia i częstotliwości testów. Aby uzyskać zalecenia dotyczące modelowania zagrożeń, zobacz Zalecenia dotyczące zabezpieczania cyklu życia programowania.
Większość testów opisanych w tych sekcjach może być uruchamiana jako rutynowe testy. Jednak powtarzalność może powodować koszty w niektórych przypadkach i powodować zakłócenia. Należy dokładnie rozważyć te kompromisy.
Testy sprawdzające poprawność stosu technologii
Oto kilka przykładów typów testów i ich obszarów fokusu. Ta lista nie jest wyczerpująca. Przetestuj cały stos, w tym stos aplikacji, fronton, zaplecze, interfejsy API, bazy danych i wszelkie integracje zewnętrzne.
Zabezpieczenia danych: przetestuj skuteczność szyfrowania danych i kontroli dostępu, aby upewnić się, że dane są prawidłowo chronione przed nieautoryzowanym dostępem i manipulowaniem.
Sieć i łączność: przetestuj zapory, aby upewnić się, że zezwalają tylko na oczekiwany, dozwolony i bezpieczny ruch do obciążenia.
Aplikacja: Przetestuj kod źródłowy za pomocą technik testowania zabezpieczeń aplikacji (AST), aby upewnić się, że stosujesz bezpieczne praktyki kodowania i przechwytujesz błędy środowiska uruchomieniowego, takie jak uszkodzenie pamięci i problemy z uprawnieniami. Aby uzyskać szczegółowe informacje, zobacz te linki społeczności.
Tożsamość: oceń, czy przypisania ról i kontrole warunkowe działają zgodnie z oczekiwaniami.
Metodologia testów
Istnieje wiele perspektyw na metodologie testowania. Zalecamy testy umożliwiające wyszukiwanie zagrożeń przez symulowanie rzeczywistych ataków. Mogą identyfikować potencjalne podmioty zagrożeń, ich techniki i luki w zabezpieczeniach, które stanowią zagrożenie dla obciążenia. Jak najbardziej realistyczne ataki. Użyj wszystkich potencjalnych wektorów zagrożeń, które są identyfikowane podczas modelowania zagrożeń.
Oto kilka zalet testowania za pomocą rzeczywistych ataków:
Podczas wykonywania tych ataków w ramach rutynowego testowania należy użyć perspektywy zewnętrznej, aby sprawdzić obciążenie i upewnić się, że obrona może wytrzymać atak.
Na podstawie poznanych lekcji zespół uaktualnia swoją wiedzę i poziom umiejętności. Zespół zwiększa świadomość sytuacyjną i może samodzielnie ocenić gotowość do reagowania na zdarzenia.
Przykładami symulowanych testów są testy czarnej skrzynki i białej skrzynki, testowania penetracyjnego i ćwiczeń w grze wojennej.
Testowanie czarnej skrzynki i białego pudełka
Te typy testów oferują dwie różne perspektywy. W testach czarnej skrzynki wewnętrzne systemu nie są widoczne. W testach białych tester dobrze rozumie aplikację, a nawet ma dostęp do kodu, dzienników, topologii zasobów i konfiguracji do przeprowadzania eksperymentu.
Testy, które symulują ataki za pomocą testów penetracyjnych
Eksperci ds. zabezpieczeń, którzy nie należą do zespołów IT lub aplikacji organizacji, przeprowadzają testy penetracyjne ani pentestowanie. Przyglądają się systemowi w sposób, w jaki złośliwi aktorzy mają zakres obszaru ataku. Ich celem jest znalezienie luk w zabezpieczeniach przez zbieranie informacji, analizowanie luk w zabezpieczeniach i raportowanie wyników.
Praktycy mogą potrzebować dostępu do poufnych danych w całej organizacji. Postępuj zgodnie z regułami zaangażowania, aby upewnić się, że dostęp nie jest niewłaściwy. Zobacz zasoby wymienione w linkach pokrewnych.
Testy, które symulują ataki za pomocą ćwiczeń w grze wojennej
W tej metodologii symulowanych ataków istnieją dwa zespoły:
Czerwony zespół jest przeciwnikiem próbującym modelować rzeczywiste ataki. Jeśli są one skuteczne, znajdziesz luki w projekcie zabezpieczeń i ocenisz, czy promień wybuchu zawiera ich naruszenia.
Niebieski zespół jest zespołem roboczym, który broni przed atakami. Testują swoją zdolność do wykrywania, reagowania i korygowania ataków. Weryfikują one zabezpieczenia wdrożone w celu ochrony zasobów obciążeń.
Jeśli są one przeprowadzane jako rutynowe testy, ćwiczenia gry wojennej mogą zapewnić ciągłą widoczność i pewność, że obrona działa zgodnie z założeniami. Ćwiczenia gier wojennych mogą potencjalnie testować na różnych poziomach w ramach obciążeń.
Popularnym wyborem do symulowania realistycznych scenariuszy ataków jest Szkolenie z symulacji ataków Ochrona usługi Office 365 w usłudze Microsoft Defender.
Aby uzyskać więcej informacji, zobacz Szczegółowe informacje i raporty dotyczące Szkolenie z symulacji ataków.
Aby uzyskać informacje o konfiguracji red-team i blue-team, zobacz Microsoft Cloud Red Teaming.
Ułatwienia platformy Azure
Microsoft Sentinel to natywna kontrolka łącząca funkcje zarządzania zdarzeniami zabezpieczeń (SIEM) i automatycznego reagowania na zabezpieczenia (SOAR). Analizuje zdarzenia i dzienniki z różnych połączonych źródeł. Na podstawie źródeł danych i ich alertów usługa Microsoft Sentinel tworzy zdarzenia i wykonuje analizę zagrożeń na potrzeby wczesnego wykrywania. Dzięki inteligentnej analizie i zapytaniom można aktywnie polować na problemy z zabezpieczeniami. Jeśli wystąpi zdarzenie, możesz zautomatyzować przepływy pracy. Ponadto za pomocą szablonów skoroszytów można szybko uzyskać szczegółowe informacje za pomocą wizualizacji.
Aby uzyskać dokumentację produktu, zobacz Funkcje wyszukiwania zagrożeń w usłudze Microsoft Sentinel.
Microsoft Defender for Cloud oferuje skanowanie luk w zabezpieczeniach dla różnych obszarów technologicznych. Aby uzyskać szczegółowe informacje, zobacz Włączanie skanowania luk w zabezpieczeniach przy użyciu Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft Defender — Microsoft Defender for Cloud.
Praktyka metodyki DevSecOps integruje testowanie zabezpieczeń w ramach ciągłego i ciągłego doskonalenia myślenia. Ćwiczenia gier wojennych to powszechna praktyka zintegrowana z rytmem biznesu w firmie Microsoft. Aby uzyskać więcej informacji, zobacz Zabezpieczenia w usłudze DevOps (DevSecOps).
Usługa Azure DevOps obsługuje narzędzia innych firm, które można zautomatyzować w ramach potoków ciągłej integracji/ciągłego wdrażania. Aby uzyskać szczegółowe informacje, zobacz Enable DevSecOps with Azure and GitHub - Azure DevOps (Włączanie metodyki DevSecOps za pomocą platformy Azure i usługi GitHub — Azure DevOps).
Linki pokrewne
Postępuj zgodnie z regułami zaangażowania, aby upewnić się, że dostęp nie jest niewłaściwy. Aby uzyskać wskazówki dotyczące planowania i wykonywania symulowanych ataków, zobacz następujące artykuły:
Możesz symulować ataki typu "odmowa usługi" (DoS) na platformie Azure. Pamiętaj, aby postępować zgodnie z zasadami określonymi w artykule Testowanie symulacji usługi Azure DDoS Protection.
Linki społeczności
Testowanie zabezpieczeń aplikacji: Narzędzia, typy i najlepsze rozwiązania — zasoby usługi GitHub opisują typy metodologii testowania, które mogą testować ochronę środowiska uruchomieniowego i czas kompilacji aplikacji.
Standard wykonywania testów penetracyjnych (PTES) zawiera wskazówki dotyczące typowych scenariuszy i działań wymaganych do ustanowienia punktu odniesienia.
OWASP Top Ten | OWASP Foundation zapewnia najlepsze rozwiązania w zakresie zabezpieczeń dla aplikacji i przypadków testowych, które obejmują typowe zagrożenia.
Lista kontrolna zabezpieczeń
Zapoznaj się z pełnym zestawem zaleceń.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla