Zalecenia dotyczące testowania zabezpieczeń
Dotyczy tego Power Platform zalecenia dotyczącego dobrze zaprojektowanej listy kontrolnej zabezpieczeń:
| SE:09 | Ustanów kompleksowy schemat testowania, który łączy podejścia do zapobiegania problemom z zabezpieczeniami, weryfikowania implementacji zapobiegania zagrożeniom i testowania mechanizmów wykrywania zagrożeń. |
|---|
Testy nie są podstawą do dobrych zabezpieczeń. Testowanie to formą sprawdzania poprawności, która umożliwia upewninie się, że formanty działają zgodnie z założeniami. Testowanie jest także aktywnym sposobem wykrywania luk w zabezpieczeniach systemu.
Ustanowić rygor testowania przez proces i weryfikację z wielu perspektyw. Należy uwzględnić punkty widoków wewnętrznych, które testuje platformę testową, infrastrukturę oraz poza programem oceny, które testuje system jako zewnętrzne testy.
Niniejszy przewodnik zawiera zalecenia dotyczące testowania zabezpieczeń obciążenia. Wdrożyć te metody testowania, aby usprawnić wpadki w obciążeniach w celu atakowania i zachowania poufności, integralności i dostępności zasobów.
Definicje
| Termin | Definicja |
|---|---|
| Zastosowanie testów zabezpieczeń (AST) | Technikę cyklu życia programu Microsoft Security Development Lifecycle (SDL), która korzysta z testów na biały i zielonych polach w celu sprawdzenia luk w zabezpieczeniach kodu. |
| Testowanie czarnej skrzynki | Metodologia testowania, która sprawdza poprawność zachowania widocznego z zewnątrz aplikacji bez znajomości wewnętrznej części systemu. |
| Niebieski zespół | Zespół, który chroni przed atakami zespołu czerwonego podczas ćwiczeń. |
| Testy penetracyjne | Metody testowania, w których w celu sprawdzenia poprawności zabezpieczeń systemu są używane metody testowania. |
| Czerwony zespół | Zespół, który gra rolę przeciwnika i próbuje zhakować system w ćwiczeniach. |
| Cykl rozwoju bezpieczeństwa (SDL) | Zestaw ścisłych praktyk oferowanych przez Microsoft, które wspierają zapewnienie bezpieczeństwa i wymogi zgodności. |
| Cykl rozwoju oprogramowania (SDLC) | Wieloetapowy, systematyczne proces tworzenia systemów oprogramowania. |
| Testowanie białej skrzynki | Metodologia testowania, w której struktura kodu jest znana specjaliście. |
Kluczowe strategie projektowania
Testowanie jest strategiią, która nie można wyedytować, zwłaszcza jeśli chodzi o bezpieczeństwo. Pozwala on w sposób aktywny wykrywać i rozwiązać problemy związane z zabezpieczeniami, zanim będzie można je wykorzystać, oraz sprawdzić, czy zaimplementowane kontrolki zabezpieczeń działają zgodnie z projektami.
Zakres testowania musi obejmować aplikację, infrastrukturę oraz zautomatyzowane i procesy ludzi.
Uwaga
W tym wytycznych istnieje rozróżnienie między testowaniem a odpowiedzią na zdarzenie. Chociaż testowanie jest mechanizmem wykrywania, który najlepiej rozwiązać problemy przed rozpoczęciem środowiska produkcyjnego, nie należy mylić się z procesem wykrywania lub wykrywania, które zostało wykonane jako część odpowiedzi na zdarzenie. Aspekt odzyskiwania informacji o zdarzeniach zabezpieczeń został opisany w Zaleceniach dotyczących odpowiedzi na zdarzenia zabezpieczeń.
Należy zaangażować się w planowanie testowe. Zespół prac może nie projektować spraw testowych. To zadanie jest często scentralizowane w przedsiębiorstwie lub wykonane przez zewnętrznych ekspertów ds. zabezpieczeń. Zespół obsługi obciążenia powinien być zaangażowany w ten proces projektowy, aby zapewnić, że zapewnienia bezpieczeństwa są zintegrowane z funkcjami aplikacji.
Pomyśl się, że jest to błąd. Zaprojektuj sprawy testowe z założeniem, że system został atakowany. Dzięki temu można odkrywać potencjalne luk w zabezpieczeniach i według priorytetów testów.
Uruchom testy w ustrukturalryzowany sposób i w powtarzalnym procesie. W tym celu należy utworzyć rygor testowania w całym programie, typy testów, czynniki jazdy i zamierzone wyniki.
Użyj odpowiedniego narzędzia do tego zadania. Użyj narzędzi skonfigurowanych do pracy z pracą. Jeśli nie masz jeszcze narzędzia, kup je. Nie twórz tego. Narzędzia zabezpieczeń są wysoce wyspecjalizowane i tworzenie własnego narzędzia może spowodować. Jeśli zespół nie ma doświadczenia w tym zakresie, można skorzystać z wiedzy i narzędzi oferowanych przez zespoły korzystające z centralnych zespołów SecOps lub za pomocą działań zewnętrznych.
Konfigurowanie oddzielnych środowisk. Testy mogą zostać zakwalifikowane jako zakwalifikowane lub nie niszczące. Nie są to testy niespodziejące. Wskazują one problem, ale nie wpływają na funkcjonalność w celu uporządkowania problemu. Testy testów usuwają dane z bazy danych i mogą spowodować usunięcie z nich funkcji.
Testowanie w środowiskach produkcyjnych zapewnia najlepsze informacje, ale powoduje największe zakłócenie działania. Testy niekonsekwacyjne są przeprowadzane w środowiskach produkcyjnych. Testowanie w środowiskach nieprodukcjowych jest zazwyczaj mniej uciążliwe, ale może nie dokładnie odzwierciedlać konfigurację środowiska produkcyjnego w istotnych dla bezpieczeństwa sposobach.
Można utworzyć wyodrębniony sklonowanie środowiska produkcyjnego przy użyciu funkcji kopiowania środowiska. Jeśli jest skonfigurowanie potoku wdrażania, można wdrożyć swoje rozwiązania w dedykowanem środowisku testowym.
Zawsze oceniaj wyniki testów. Testowanie to nie wszystko, jeśli wyniki nie są używane do ustalania priorytetów działań i udoskonalania ich. Udokumentowanie wytycznych dotyczących zabezpieczeń, w tym najlepszych praktyk, które odkrywasz. Dokumentacja mająca wyniki i plany wyszukiwania zawiera informacje na temat różnych sposobów, na jakie osoby mogą spróbować spowodować bezpieczeństwo. Regularnie przeszukaj szkolenia dotyczące zabezpieczeń dla deweloperów, administratorów i testerów.
Podczas projektowania planów testowych należy myśleć o następujących pytaniach:
- Jak często ma być uruchamiany test i jak wpływa on na środowisko?
- Jakie są różne typy testów, które należy uruchomić?
Jak często mają być uruchamiane testy?
Przetestuj obciążenia regularnie, aby upewnić się, że zmiany nie wprowadzono zabezpieczeń i że nie ma żadnych zdumień. Zespół musi także być gotowy do odpowiadania na sprawdzania poprawności zabezpieczeń organizacji, które mogą zostać przeprowadzone w dowolnym czasie. Są też testy, które można uruchomić w odpowiedzi na zdarzenie zabezpieczeń. W poniższych sekcjach przedstawiono zalecenia dotyczące częstotliwości testów.
Procedury testowe
Standardowe testy są przeprowadzane cyklicznie w ramach standardowych procedur operacyjnych i w celu spełnienia wymagań związanych z zgodnością. Różne testy mogą być przeprowadzane na różnych harmonogramach, ale najważniejsze jest to, aby były one przeprowadzane okresowo i zgodnie z harmonogramem.
Te testy należy zintegrować z SDLC, ponieważ zapewniają głębię na każdym etapie. Przetestuj zestaw testowy w celu sprawdzenia tożsamości, przechowywania danych, transmisji i kanałów komunikacji. Przekieruj te same testy w różnych punktach cyklu życia, aby się upewnić, że nie ma żadnych osób. Rutynowe testy pomagają w ustanawianiu początkowych testów porównawczych. To jednak dopiero punkt początkowy. Gdy odkrywasz nowe problemy w tych samych punktach cyklu życia, dodajesz nowe sprawy testowe. Testy usprawniają się także z powtarzaniem.
Na każdym etapie tych testów należy sprawdzić poprawność kodu dodanego lub usuniętego albo ustawień konfiguracji, które zostały zmienione w celu wykrycia wpływu tych zmian na zabezpieczenia. Należy usprawnić testy za pomocą automatyzacji, tak aby można je było równowadze z przeglądami innych użytkowników.
Rozważ uruchamianie testów zabezpieczeń w ramach zautomatyzowanego planowanego lub zaplanowanego uruchomienia testowego. Im wcześniej użytkownik poznaje problemy z zabezpieczeniami, tym łatwiej znaleźć kod lub zmianę konfiguracji, która je powoduje.
Nie polegaj tylko na zautomatyzowanych testach. W celu wykrycia luk w zabezpieczeniach, które mogą chwycić tylko ludzie, można użyć testowania ręcznego. Testowanie ręczne jest dobrym rozwiązaniem w przypadku użycia w celu poznania i znalezienia nieznanego testowania.
Testy usprawnione
Udoskonalone testy zapewniają sprawdzanie poprawności danych w czasie. Alerty zabezpieczeń, które mogą mieć wpływ na obciążenie w tym czasie wyzwalają te testy. Jeśli alert zostanie eskalowany, może być konieczne wstrzymanie i przetestowanie działań w celu sprawdzenia skuteczności strategii strategii względem alertu.
Zaletą testów udoskonalanych jest przygotowanie się do rzeczywistego zdarzenia. Te testy mogą stanowić forcingową funkcję testowania akceptacji użytkowników (UAT).
Zespół zabezpieczeń może uruchomić inspekcję wszystkich prac i uruchomić te testy zgodnie z potrzebami. Jako właściciel obciążenia należy ułatwić sobie pracę z zespołami zabezpieczeń i wspólnie z nimi pracować. W celu przygotowania zespołu ds. zabezpieczeń należy odpowiednio przygotować czas potencjalnego klienta. Należy potwierdzić, że takie zakłócenie będzie konieczne, oraz przekazać je zespołowi i interesariuszom.
W innych przypadkach może być wymagane uruchomienie testów i zgłoszenie stanu zabezpieczeń systemu w celu zabezpieczenia przed potencjalnym zagrożeniem.
Kompromis: Ponieważ improwizowane testy są zdarzeniami zakłócającymi, spodziewaj się zmiany priorytetów zadań, co może opóźnić inne zaplanowane prace.
Ryzyko: Istnieje ryzyko nieznanego. Udoskonalone testy mogą być jednorazowe bez ustalonych procesów ani narzędzi. Ryzyko, że ryzyko wystąpienia zagrożenia istnieje jednak w przypadku przerwy w pracy. Należy oceniać te względy względem korzyści.
Testy zdarzeń zabezpieczeń
Istnieją testy, które wykrywają przyczynę zdarzenia zabezpieczeń u źródła. Te zdarzenia zabezpieczeń muszą zostać rozpoznane, aby zdarzenie nie zostało powtórzone.
Zdarzenia poprawiają także sprawy testowe w czasie, odkrywając istniejące zdarzenia. Zespół powinien wykorzystać wnioski z tego zdarzenia i regularnie włączać udoskonalenia.
Jakie są różne typy testów?
Testy można podzielić na kategorie według technologii i metodologii testów. Połączenie tych kategorii i rozwiązań w tych kategoriach w celu pełnego zakresu ubezpieczenia.
Dodając wiele testów i typów testów, można odkrywać:
- Bezpieczeństwo w kontrolkach zabezpieczeń lub kontrolkach ich przechowania.
- Nieprawidłowe konfiguracje.
- Obserwacja w metodach skalowalności i wykrywania.
Dobre modelowanie zagrożeń może wskazać kluczowe obszary, aby zapewnić zakres i częstotliwość testów. Aby uzyskać zalecenia dotyczące modelowania zagrożeń, zobacz Zalecenia dotyczące zabezpieczania cyklu życia projektowania.
Większość testów opisanych w tych sekcjach może być uruchamianych jako testy codzienne. Powtarzalność może jednak w niektórych przypadkach spowodować przerwanie kosztów. Warto uwzględnić te transakcje bardzo starannie.
Testy sprawdź poprawność kumulowania technologii
Oto kilka przykładów typów testów i ich obszarów fokusu. Ta lista nie jest pełne. Przetestuj cały stos, w tym skumulowany aplikacji, front end, back end, interfejsy API, bazy danych i wszystkie integracje zewnętrzne.
- Bezpieczeństwo danych: Przetestuj skuteczność szyfrowania danych i kontroli dostępu, aby upewnić się, że dane są odpowiednio chronione przed nieautoryzowanym dostępem i manipulacją.
- 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 przestrzegasz bezpiecznych praktyk kodowania i wychwycić błędy w czasie wykonywania, takie jak uszkodzenie pamięci i problemy z uprawnieniami.
- Tożsamość: Oceń, czy przypisania ról i kontrole warunkowe działają zgodnie z oczekiwaniami.
Metodologia testów
Istnieje wiele perspektyw dotyczących testów. Zaleca się, aby testować włączenie szacowania zagrożeń przez skonsulowanie ataków ze świata rzeczywistego. Mogą oni zidentyfikować potencjalne zagrożenie, swoje metody i wykorzystywane przez nie luki, które stanowią zagrożenie dla obciążenia. Atak należy wykonać możliwie jak najbardziej realistycznie. Użyj wszystkich potencjalnych zagrożeń, które są identyfikowane podczas modelowania zagrożeń.
Oto kilka korzyści z testowania podczas ataków ze świata rzeczywistego:
- Jeśli te ataków są częścią procedury testowej, do sprawdzenia obciążenia i upewnienia się, że atak może być atakowany, należy użyć perspektywy z zewnątrz.
- W zależności od dowiedzień zespół uaktualnia swoją wiedzę i poziom umiejętności. Zespół poprawia świadomość sytuacji i może sam oceniać swoją gotowości do odpowiadania na zdarzenia.
Przykłady testów zdumione to testy na wątło i biały pola, testy testów i ćwiczeń.
Testy w czarnej i białej skrzynce
Te typy testów oferują dwie różne perspektywy. W przypadku testów czarnej skrzynki nie są widoczne wewnętrzne części systemu. W oficjalnych testach serwer dobrze rozumie aplikację i ma nawet dostęp do kodu, dzienników, topologii zasobów i konfiguracji przeprowadzania eksperymentu.
Testy przeprowadzane w ramach testów symulujących ataki
Eksperci ds. zabezpieczeń, którzy nie są częścią zespołów ds. it lub zespołów aplikacji, przeprowadzają testy penetracji zwane takżepentest. Wyglądają w systemie w sposób, który złośliwe pole zakresu atakuje tablet. Ich celem jest znalezienie zabezpieczeń przez zbieranie informacji, analizowanie luk w zabezpieczeniach i raportowanie wyników.
Osoby te mogą potrzebować dostępu do poufnych danych w całej organizacji. Aby upewnić się, że dostęp nie jest nieprawidłowy, należy postępować zgodnie z regułami zobowiązania. Zapoznaj się z zasobami wymienionymi w sekcji Informacje pokrewne.
Testy przeprowadzane w ramach testów ćwiczeń
W tej metodologii zespołów istnieją dwa zespoły:
- Czerwony zespół jest przeciwnikiem próby modelowania ataków ze świata rzeczywistego. Jeśli te osoby odniosą sukces, znajdziesz luki w zabezpieczeniach i możesz ocenić, czy ich zabezpieczenia zostały naruszone.
- Niebieski zespół to zespół obsługi obciążenia, który broni przed atakami. Testują możliwość wykrywania i wykrywania ataków oraz reagowania na nie. Poprawność wszystkich zaimplementowanych danych w celu ochrony zasobów obciążenia.
Jeśli są one przeprowadzane jako procedury testowe, ćwiczenia gry w trakcie gry mogą zapewnić bieżącą widoczność i pewność, że jego elementy działają zgodnie z projektami. Ćwiczenia w ramach konfliktów mogą testować na różnych poziomach w ramach prac.
Popularną wybieraną przez wielu z najbardziej popularnych scenariuszy ataków jest Microsoft Defender dla Office 365 Trenowanie symulacji ataku.
Aby uzyskać więcej informacji, zobacz Szczegółowe informacje i raporty dla trenowania symulacji ataku.
Informacje o konfigurowaniu zespołu czerwonych i niebieskich można znaleźć w witrynie Zespoły czerwone w Microsoft Cloud.
Ułatwienia Power Platform
Rozwiązanie Microsoft Sentinel dla Microsoft Power Platform umożliwia klientom wykrywanie różnych działań, takich jak:
- Wykonanie Power Apps z nieautoryzowanych lokalizacji geograficznych
- Zniszczenie podejrzanych danych przez Power Apps
- Zbiorcze usuwanie w Power Apps
- Ataki wyłudzania informacji dokonywane za pośrednictwem Power Apps
- Działania przepływów Power Automate wykonywane przez odchodzących pracowników
- Łączniki Microsoft Power Platform dodawane do środowiska
- Aktualizacja lub usunięcie zasad ochrony przed utratą danych Microsoft Power Platform
Aby uzyskać więcej informacji, zobacz Rozwiązanie Microsoft Sentinel dla Microsoft Power Platform.
Aby uzyskać dokumentację produktu, zobacz Możliwości wyszukiwania zagrożeń Microsoft Sentinel.
Rozwiązanie Microsoft Defender for Cloud udostępnia skanowanie od kątem luk w zabezpieczeniach w różnych obszarach technologii. Aby uzyskać więcej informacji, zobacz Włączanie skanowania luk w zabezpieczeniach przy użyciu funkcji Zarządzanie lukami w Microsoft Defender.
W ramach metody testowania zabezpieczeń w programie DevSecOps metody testowania zabezpieczeń są elementem ciągłych i stałych ulepszeń. Ćwiczenia w ramach gry to typowe praktyki integrowane z potrzebami firmy Microsoft. Aby uzyskać więcej informacji, zobacz temat Zabezpieczenia w DevOps (DevSecOps).
Azure DevOps obsługuje narzędzia innych firm, które mogą być zautomatyzowane w ramach ciągłych integracji/ciągłych wdrożeń (CI/CD). Aby uzyskać więcej informacji, zobacz Włączanie DevSecOps z Azure i GitHub.
Informacje pokrewne
Najnowsze testy penetracyjne i oceny zabezpieczeń można znaleźć w portalu zaufania usług Microsoft.
Firma Microsoft przeprowadza szczegółowe testy Usługi firmy Microsoft w chmurze. To testy obejmują przetestowanie testów z wynikami opublikowanymi w portalu zaufania usług organizacji. Organizacja może wykonać własne testy pentracyjne w Microsoft Power Platform i Microsoft Dynamics 365. Wszystkie testy testy w chmurze muszą być zgodne z Regułami zaangażowania testowania penetracji Microsoft Cloud. Należy pamiętać, że w wielu przypadkach usługa Microsoft Cloud używa udostępnianej infrastruktury do hostów zasobów i zasobów należących do innych klientów. Należy ograniczyć wszystkie testy przeprowadzone na tych badaniach do zasobów i uniknąć niezamierzonych konsekwencji dla innych klientów.
Aby upewnić się, że dostęp nie jest nieprawidłowy, należy postępować zgodnie z regułami zobowiązania. Wskazówki dotyczące planowania i wykonywania ataków, które nie są wykonywane, można znaleźć w:
Na platformie Azure można atakować odmowa usługi (DoS). Pamiętaj, aby postępować zgodnie z zasadami określonymi w Testach symulujących ochronę przed atakami Azure DDoS Protection.
Lista kontrolna zabezpieczeń
Zapoznaj się z kompletną zestawem zaleceń.