Zalecenia dotyczące testowania zabezpieczeń
Dotyczy tego zalecenia listy kontrolnej dotyczącej zabezpieczeń platformy Azure Well-Architected Framework:
| SE:11 | Ustanów kompleksowy schemat testowania, który łączy podejścia w celu zapobiegania problemom z zabezpieczeniami, weryfikowaniu implementacji zapobiegania zagrożeniom i testowaniu 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 w systemie.
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, które testuje 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
| Termin | Definicja |
|---|---|
| Testowanie zabezpieczeń aplikacji (AST) | Technika cyklu projektowania zabezpieczeń firmy Microsoft (SDL), która używa metodologii testowania białych i czarnych ramek w celu sprawdzenia luk w zabezpieczeniach w kodzie. |
| Testowanie black-box | Metodologia testowania, która weryfikuje zewnętrznie widoczne zachowanie aplikacji bez znajomości wewnętrznych elementów systemu. |
| Niebieski zespół | Zespół, który broni przed atakami czerwonej drużyny w ćwiczeniu gry wojennej. |
| Testy penetracyjne | Metodologia testowania, która wykorzystuje etyczne techniki hakerskie w celu zweryfikowania ochrony przed zabezpieczeniami systemu. |
| Czerwony zespół | Zespół, który odgrywa rolę przeciwnika i próbuje zhakować system w ćwiczeniu gry wojennej. |
| Security Development Lifecycle (SDL) | Zestaw rozwiązań oferowanych przez firmę Microsoft, który obsługuje wymagania dotyczące zapewniania zabezpieczeń i zgodności. |
| Cykl życia tworzenia oprogramowania (SDLC) | Wieloestowy, systematyczny proces tworzenia systemów oprogramowania. |
| Testowanie białej skrzynki | Metodologia testowania, w której struktura kodu jest znana praktykowi. |
Kluczowe strategie projektowania
Testowanie to nienegocjacjalna strategia, szczególnie w przypadku zabezpieczeń. Umożliwia proaktywne odnajdywanie i rozwiązywanie problemów z zabezpieczeniami przed ich użyciem oraz sprawdzenie, czy wdrożone mechanizmy kontroli zabezpieczeń działają zgodnie z założeniami.
Zakres testowania musi obejmować aplikacje, infrastrukturę oraz zautomatyzowane i ludzkie procesy.
Uwaga
Te wskazówki odróżniają testy i reagowanie na zdarzenia. Mimo że testowanie to mechanizm wykrywania, który idealnie rozwiązuje problemy przed produkcją, nie powinien być mylony z korygowaniem ani badaniem, które jest wykonywane w ramach reagowania na zdarzenia. Aspekt odzyskiwania po zdarzeniach zabezpieczeń został opisany w temacie Zalecenia dotyczące reagowania na zdarzenia.
Protokół SDL zawiera kilka typów testów, które przechwytują luki w zabezpieczeniach w kodzie, weryfikują składniki środowiska uruchomieniowego i używają etycznego hackingu 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 odkryć potencjalne luki w zabezpieczeniach i odpowiednio określić priorytety testów.
Uruchamianie testów w sposób ustrukturyzowany i przy użyciu powtarzalnego procesu. Utwórz rygor testowania 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ępuje problem, ale nie zmieniają funkcjonalności 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ększe zakłócenia. Zwykle wykonujesz tylko testy niezniszczalne w środowiskach produkcyjnych. Testowanie w środowiskach nieprodukcyjnych jest zwykle mniej destrukcyjne, ale może nie odzwierciedlać dokładnie konfiguracji środowiska produkcyjnego w sposób, który jest ważny 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 można odkryć. 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ć bezpieczeństwo. 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ć?
Regularne testowanie obciążenia
Regularnie przetestuj 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ą ustalić początkowy test porównawczy. Jest to jednak tylko punkt wyjścia. W miarę odnajdowania nowych problemów w tych samych punktach cyklu życia dodajesz nowe przypadki testowe. Testy również poprawić przy użyciu powtórzeń.
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żonej dzięki przeglądom równorzędnym.
Rozważ uruchomienie testów zabezpieczeń w ramach zautomatyzowanego potoku lub zaplanowanego przebiegu testu. Im szybciej odnajdujesz problemy z zabezpieczeniami, tym łatwiej jest znaleźć kod lub zmianę konfiguracji, która je powoduje.
Nie polegaj tylko na testach automatycznych. Użyj testowania ręcznego, aby wykryć luki w zabezpieczeniach, które mogą przechwytywać tylko ludzka wiedza. Testowanie ręczne jest dobre w przypadku eksploracyjnych przypadków użycia i znajdowania nieznanych zagrożeń.
Improwizowane testy
Improwizowane testy zapewniają walidację 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 sposobu myślenia w celu zweryfikowania skuteczności strategii obrony, jeśli alert będzie eskalowany w nagłych wypadkach.
Korzyścią z improwizowanych testów jest gotowość do rzeczywistego incydentu. Te testy mogą być funkcją wymuszania wykonywania 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 realizacji z zespołami ds. zabezpieczeń, aby można było przygotować się. Potwierdź i przekaż swojemu zespołowi i uczestnikom projektu, że te zakłócenia są niezbędne.
W innych przypadkach może być wymagane uruchomienie testów i zgłoszenie stanu zabezpieczeń systemu przed potencjalnym zagrożeniem.
Kompromis: Ponieważ improwizowane testy są destrukcyjnymi zdarzeniami, należy oczekiwać ponownego zapisania zadań, które mogą opóźnić inne planowane prace.
Ryzyko: istnieje ryzyko nieznanego. Improwizowane testy mogą być jednorazowe bez ustalonych procesów lub narzędzi. Jednak dominującym 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 zwiększają również przypadki testowe w czasie, ujawniając istniejące luki. Zespół powinien zastosować wnioski wyciągnięte ze zdarzenia i rutynowo wprowadzać ulepszenia.
Stosowanie różnych 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 projektowania.
Większość testów opisanych w tych sekcjach może być uruchamiana jako rutynowe testy. Jednak powtarzalność może wiązać się z kosztami w niektórych przypadkach i powodować zakłócenia. Należy dokładnie rozważyć te kompromisy.
Testy sprawdzające stos 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 testowania
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 można zidentyfikować podczas modelowania zagrożeń.
Oto kilka zalet testowania za pomocą rzeczywistych ataków:
Gdy te ataki są częścią 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.
Niektóre przykłady symulowanych testów obejmują testy black-box i white-box, testy penetracyjne i ćwiczenia gry wojennej.
Testy black-box i white-box
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 pośrednictwem 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 taki sposób, w jaki złośliwi aktorzy określają obszar ataków. Ich celem jest znalezienie luk w zabezpieczeniach dzięki zbieraniu informacji, analizowaniu luk w zabezpieczeniach i raportowaniu 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. Zapoznaj się z zasobami wymienionymi w linkach pokrewnych.
Testy, które symulują ataki za pomocą ćwiczeń gry wojennej
W tej metodologii symulowanych ataków istnieją dwa zespoły:
Czerwony zespół jest przeciwnikiem próbującym modelować rzeczywiste ataki. W przypadku powodzenia znajdziesz luki w projekcie zabezpieczeń i ocenisz powstrzymanie promieni wybuchu ich naruszeń.
Niebieski zespół jest zespołem roboczym, który broni przed atakami. Testują swoją zdolność do wykrywania, reagowania i korygowania ataków. Weryfikują zabezpieczenia, które zostały zaimplementowane 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 projektem. Ćwiczenia gry wojennej mogą potencjalnie testować na różnych poziomach w ramach obciążeń.
Popularnym wyborem do symulowania realistycznych scenariuszy ataku jest Ochrona usługi Office 365 w usłudze Microsoft Defender Szkolenie z symulacji ataków.
Aby uzyskać więcej informacji, zobacz Szczegółowe informacje i raporty dotyczące Szkolenie z symulacji ataków.
Aby uzyskać informacje na temat konfiguracji red-team i blue-team, zobacz Microsoft Cloud Red Teaming.
Ułatwienia platformy Azure
Microsoft Sentinel to natywna kontrolka, która łączy funkcje zarządzania zdarzeniami zabezpieczeń (SIEM) i automatycznego reagowania na zdarzenia zabezpieczeń (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 przeprowadza 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żesz szybko uzyskać szczegółowe informacje za pomocą wizualizacji.
Aby uzyskać dokumentację produktu, zobacz Funkcje wyszukiwania zagrożeń w usłudze Microsoft Sentinel.
Microsoft Defender dla Chmury oferuje skanowanie luk w zabezpieczeniach dla różnych obszarów technologii. 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 dla Chmury.
Praktyka metodyki DevSecOps integruje testowanie zabezpieczeń w ramach ciągłego i ciągłego myślenia o ulepszaniu. Ćwiczenia gry wojennej to powszechna praktyka zintegrowana z rytmem działalności firmy Microsoft. Aby uzyskać więcej informacji, zobacz Zabezpieczenia w metodyce 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 Włączanie usługi DevSecOps za pomocą platformy Azure i usługi GitHub — Azure DevOps.
Pokrewne łącza
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ściowe
Testowanie zabezpieczeń aplikacji: Narzędzia, typy i najlepsze rozwiązania — zasoby usługi GitHub opisują typy metodologii testowania, które mogą testować ochronę aplikacji w czasie kompilacji i czasie wykonywania.
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ń.