Modelowanie zagrożeń: architektura, scenariusze ataków i zabezpieczenia
Sytance · Zaktualizowano
Modelowanie zagrożeń to uporządkowana metoda identyfikowania sposobów ataku na produkt i doboru środków ograniczających ryzyko. Analiza rozpoczyna się od architektury produktu i wyjaśnia, jak atak mógłby się powieść, na co wpłynąłby oraz jak zostanie sprawdzone proponowane zabezpieczenie.
Wersja produktu i wdrożenie
Model zagrożeń dotyczy konkretnej wersji produktu i konkretnego wdrożenia. Brama podłączona do internetu oraz ta sama brama w odizolowanej sieci konserwacyjnej mogą mieć inne punkty wejścia i założenia operacyjne.
Należy zaprosić osoby znające architekturę, rozwój, sposób użytkowania produktu i bezpieczeństwo. Przed spotkaniem należy zebrać wystarczające materiały, aby opisać zwykłe działanie od początku do końca.
- Wydanie, obsługiwane wdrożenie i zamierzeni użytkownicy.
- Architektura, interfejsy zewnętrzne i wymieniane dane.
- Uprawnienia każdego użytkownika, usługi i procesu lokalnego.
- Dane wrażliwe, dane uwierzytelniające i funkcje produktu wymagające ochrony.
- Istniejące środki kontroli i wszelkie założenia, które należy jeszcze potwierdzić.
Przepływy danych i granice zaufania
Diagram przepływu danych (DFD) przedstawia podmioty zewnętrzne, procesy, magazyny danych i ich przemieszczanie się. Granica zaufania oznacza zmianę poziomu zaufania lub uprawnień. Może występować między przeglądarką a API, między dwoma kontami systemu operacyjnego albo między urządzeniem a usługą zdalną.
Dla każdego przepływu określić kierunek, opis danych i mechanizm ochrony. Etykieta „chmura” ukrywa zbyt wiele, jeśli kilka usług ma różne tożsamości i uprawnienia. Należy rozdzielić te elementy, gdy różnica wpływa na analizę.
W przykładzie bramy przemysłowej należy zacząć od przeglądarki operatora, API zarządzania bramą, lokalnego magazynu konfiguracji, lokalnego sterownika, usługi telemetrycznej i usługi aktualizacji. Połączenia zarządzania i telemetrii oznaczyć jako połączenia TLS. Weryfikację podpisu aktualizacji traktować jako proponowany środek kontroli, dopóki nie zostanie potwierdzona jego implementacja.
Od kategorii STRIDE do scenariuszy ataku
STRIDE dzieli zagrożenia na podszywanie się, manipulowanie, zaprzeczalność, ujawnienie informacji, odmowę usługi i podniesienie uprawnień. Należy używać tych kategorii jako podpowiedzi przy analizie każdego istotnego procesu i przepływu. Sama nazwa kategorii nie opisuje ataku.
Na przykład użytkownik mający dostęp tylko do odczytu wysyła żądanie zmiany konfiguracji bezpośrednio do API zarządzania. Jeśli API sprawdza logowanie, ale nie uprawnienie do wykonania czynności, użytkownik może zmienić konfigurację bramy. Wskazuje to podmiot, punkt wejścia, brakujący środek kontroli i wpływ.
Powiązać każdy scenariusz z odpowiednim interfejsem, procesem lub przepływem na diagramie. Scenariusze z różnymi warunkami ataku lub środkami kontroli wymagają odrębnej analizy. Jeśli jakiś warunek jest nieznany, na przykład uwierzytelnianie interfejsu sterownika, zapisać, co należy potwierdzić.
Priorytety ryzyka i środki kontroli bezpieczeństwa
Priorytety ryzyka zależą od potrzebnego dostępu i możliwości atakującego, prawdopodobieństwa powodzenia oraz konsekwencji dla produktu. Uzgodniona metoda oceny ryzyka ujednolica te osądy. Uzasadnienie oceny liczbowej pozwala innym ją zweryfikować.
Należy wybrać działanie, które zespół może wdrożyć. W scenariuszu zmiany konfiguracji API powinno egzekwować uprawnienia wywołującego przy każdej operacji zapisu. Trzeba przypisać właściciela, docelowe wydanie i kontrolę potwierdzającą działanie zabezpieczenia.
Istniejące TLS chroni połączenie transportowe; nie potwierdza, że zalogowany użytkownik może zmienić konfigurację. Środek kontroli należy ocenić względem dokładnego etapu ataku, który ma zatrzymać. Jeśli zespół akceptuje pozostałe ryzyko, powinien zachować uzasadnienie i wskazać osobę uprawnioną do podjęcia tej decyzji.
Weryfikacja i aktualizowanie modelu
Proponowany środek kontroli i zweryfikowany środek kontroli to różne stany. Wdrożone zabezpieczenie należy powiązać z odpowiednią zmianą i jej wynikiem weryfikacji. W przykładzie API należy wysłać żądanie zapisu jako użytkownik mający dostęp tylko do odczytu i potwierdzić zarówno jego odrzucenie, jak i brak zmiany konfiguracji.
Model należy przeglądać po zmianie interfejsu, uprawnień, komponentu, wdrożenia lub mechanizmu aktualizacji. Nowe informacje o podatnościach również mogą unieważnić wcześniejsze założenie. Należy zachować poprzednią wersję modelu, aby zespół mógł wyjaśnić, których wydań dotyczyła decyzja.