Rejestry i raporty z modelowania zagrożeń
Sytance · Zaktualizowano
Model zagrożeń rejestruje architekturę produktu, scenariusze ataków, środki kontroli bezpieczeństwa i wyniki weryfikacji. Powiązanie tych zapisów pozwala osobie dokonującej przeglądu prześledzić uzasadnienie od ataku do wybranego środka zaradczego. Przykład bramy pokazuje, jak te zapisy łączą się ze sobą; poniższe sekcje wyjaśniają, co należy rejestrować i jak to przeglądać.
Jak uporządkować model
Diagram i analizę należy przechowywać razem albo powiązać je za pomocą stabilnych identyfikatorów. W przypadku niewielkiego przeglądu wystarczy dokument; ustrukturyzowane zapisy stają się przydatne, gdy ten sam środek kontroli odpowiada na kilka zagrożeń lub zespół musi porównywać wydania.
W Sytance zespół edytuje architekturę i zapisy dotyczące zagrożeń w obszarze roboczym, a następnie łączy je z odpowiednimi wymaganiami, projektami i zapisami weryfikacji dotyczącymi bezpieczeństwa. Moduł dokumentacji wykorzystuje informacje z obszaru roboczego do przygotowania raportów.
Informacje o produkcie i założenia
Zidentyfikować wersję produktu, wdrożenie, przeznaczenie i osoby, które z niego korzystają. Określić części objęte analizą, zależności zewnętrzne i wszelkie wyłączenia wpływające na ścieżkę ataku.
Wytyczne OWASP dotyczące dekompozycji rozróżniają punkty wejścia, zasoby i poziomy zaufania. Wykorzystać te rozróżnienia do wyjaśnienia architektury, zamiast przedstawiać każdy zasób jako osobny proces na diagramie.
- Kontekst: produkt, wydanie, środowisko, przeznaczenie i właściciel przeglądu.
- Architektura: rewizja diagramu, procesy, magazyny, podmioty zewnętrzne i przepływy.
- Cele ochrony: dane i funkcje wymagające poufności, integralności lub dostępności.
- Założenia: każdy niepewny warunek, jego właściciel i sposób potwierdzenia.
Zapisz jeden scenariusz ataku w każdym rekordzie
Każdemu zagrożeniu nadać stabilny identyfikator i powiązać je z odpowiednim elementem lub przepływem na diagramie. Opisać, kto może zaatakować, jakiego dostępu potrzebuje, jakie działanie podejmuje, jaką słabość wykorzystuje i jakie są konsekwencje. Wskazać wszystkie warunki, od których zależy scenariusz.
Przykład TM-01: użytkownik bramy mający dostęp tylko do odczytu wywołuje API zapisu konfiguracji. Jeśli API sprawdza uwierzytelnienie, ale nie uprawnienie do zapisu, użytkownik może zmienić miejsce docelowe telemetrii. Zagrożony przepływ biegnie z przeglądarki do API zarządzania, a atak narusza integralność zapisanej konfiguracji.
Wpis zawierający jedynie „podniesienie uprawnień, wysokie ryzyko” nie wyjaśnia tego scenariusza. Należy dodać uzasadnienie oceny ryzyka: wymagane konto, ekspozycję punktu końcowego, realistyczny wpływ oraz uwzględnione istniejące środki kontroli.
Środki kontroli, wdrożenie i weryfikacja
Dla TM-01 proponowany środek kontroli AC-01 wymaga, aby API zarządzania sprawdzało uprawnienia do czynności i zasobów przy każdym zapisie konfiguracji. Zapis wdrożenia powinien wskazywać odpowiednią zmianę. Zapis weryfikacji powinien zawierać rzeczywisty wynik testu dla wskazanego wydania.
- Decyzja: ograniczyć, usunąć lub zaakceptować ryzyko wraz z uzasadnieniem i wskazaniem właściciela.
- Środek kontroli: wymagane zachowanie i etapy zagrożenia, na które odpowiada.
- Wdrożenie: komponent, odniesienie do zmiany i wersja produktu.
- Weryfikacja: konfiguracja testu, działanie, wynik oczekiwany, wynik zaobserwowany i odnośnik do dowodu.
- Pozostałe ryzyko: nierozstrzygnięte warunki i zatwierdzona decyzja z przeglądu.
Wyniki oczekiwane i zaobserwowane
W fikcyjnym przykładzie bramy oczekiwanym wynikiem jest odrzucenie żądania zapisu wysłanego przez użytkownika z dostępem tylko do odczytu oraz pozostawienie zapisanej konfiguracji bez zmian. Wynik zaobserwowany odnotowuje, co wydarzyło się podczas testu. Do czasu wykonania testu to pole pozostaje oczekujące.
To samo rozróżnienie dotyczy środków kontroli. „Weryfikacja podpisu zaplanowana” oraz „weryfikacja podpisu wdrożona i przetestowana” oznaczają różne poziomy pewności. Przy przekazywaniu zapisu do raportu lub innego narzędzia należy zachować to rozróżnienie.
Przegląd ukończonego modelu
Poprosić osobę dokonującą przeglądu, aby prześledziła jeden atak od diagramu do wybranego środka kontroli i wyniku testu. Jeśli nie można prześledzić tych powiązań, ustalić, czy brakuje zapisu, czy atak wymaga jaśniejszego wyjaśnienia.
Sprawdzić, czy wskazane wydanie odpowiada diagramowi, każdy scenariusz ma decyzję dotyczącą postępowania, a przy zaakceptowanym ryzyku wskazano osobę, która je zaakceptowała. Nierozstrzygnięte założenia pozostają na liście wraz z właścicielem i sposobem ich potwierdzenia.
Po zaktualizowaniu zapisów w obszarze roboczym otworzyć Dokumentację i wybrać odpowiedni raport. W zależności od konfiguracji obszaru roboczego i planu Sytance udostępnia podglądy HTML oraz eksport do PDF lub DOCX. Przed użyciem w przeglądzie sprawdzić wygenerowany raport pod kątem zgodności z aktualną wersją produktu, analizą i dowodami weryfikacji.