Przykład STRIDE: brama przemysłowa
Sytance · Zaktualizowano
STRIDE wykorzystuje sześć kategorii zagrożeń do analizy możliwych ataków na system. Poniższa fikcyjna brama przemysłowa ilustruje po jednym scenariuszu dla każdej kategorii, wraz z proponowanym środkiem kontroli i kryterium testu. Przykłady opisują możliwe ataki i zaplanowane testy.
Brama i jej granice zaufania
Operator używa przeglądarki do wywołania API zarządzania bramą. API odczytuje lokalny magazyn konfiguracji i zapisuje w nim dane. Lokalny sterownik wysyła dane operacyjne do bramy, która przekazuje telemetrię do usługi zdalnej. Oddzielna usługa aktualizacji dostarcza pakiety oprogramowania układowego.
W tym przykładzie połączenia zarządzania i telemetrii korzystają z TLS. Uwierzytelnianie interfejsu sterownika i mechanizm zaufania dla aktualizacji pozostają nierozstrzygniętymi kwestiami projektu. Sama lokalizacja w sieci lokalnej nie potwierdza tożsamości ani uprawnień nadawcy.
- Przeglądarka → API zarządzania: sesje, żądania statusu i zmiany konfiguracji.
- API zarządzania → magazyn konfiguracji: zapisane ustawienia i dostęp do wpisów tajnych.
- Lokalny sterownik → brama: dane wejściowe dotyczące działania z sieci obiektu.
- Brama → usługa telemetryczna: tożsamość urządzenia i dane telemetryczne.
- Usługa aktualizacji → brama: metadane pakietu i zawartość oprogramowania układowego.
Podszycie się pod tożsamość na interfejsie sterownika
Atakujący w sieci obiektu wysyła wiadomości podszywające się pod lokalny sterownik. Jeśli brama ufa wyłącznie adresowi źródłowemu, sfałszowane dane operacyjne mogą trafić do strumienia telemetrycznego.
Proponowany środek kontroli: ustanowić tożsamość urządzenia i weryfikować ją przed przyjęciem wiadomości. Jeśli sterownik nie obsługuje uwierzytelniania, ocenić inne sposoby ochrony interfejsu i nadal możliwe ataki. Sam segment sieci nie potwierdza pochodzenia wiadomości.
Kryterium weryfikacji: wiadomości pochodzące od nierozpoznanej tożsamości testowej są odrzucane, a wiadomości od zatwierdzonego sterownika nadal działają. Zarejestrować odrzucenie i potwierdzić, że sfałszowana wartość nie dotarła do usługi telemetrycznej.
Naruszenie integralności oprogramowania układowego przed instalacją
Atakujący zastępuje pakiet pobrany z przejętego punktu dystrybucji. Szyfrowanie transmisji do tego punktu nie potwierdza, że producent autoryzował pakiet.
Proponowany środek kontroli: przed instalacją zweryfikować podpis pakietu względem autoryzowanego źródła zaufania. Powiązać weryfikację z bajtami przeznaczonymi do instalacji i dozwolonym produktem. Oddzielnie określić sposób obsługi starszych podpisanych wersji i unieważnionych kluczy podpisywania.
Kryterium weryfikacji: zmodyfikowany pakiet i pakiet podpisany niezaufanym kluczem są odrzucane przed instalacją. Po odrzuceniu brama musi pozostać w określonym stanie roboczym lub odzyskiwania.
Nieidentyfikowalne zmiany konfiguracji
Upoważniony operator zmienia miejsce docelowe telemetrii, ale zapis nie zawiera tożsamości konkretnej osoby ani wyniku. Zespół nie może wiarygodnie przypisać zmiany ani odróżnić zapisu zakończonego powodzeniem od odrzuconego żądania.
Proponowany środek kontroli: rejestrować uwierzytelnioną tożsamość, czynność, cel, czas i wynik. Chronić dostęp do dziennika i określić zachowanie po zapełnieniu pamięci. Nie umieszczać w dzienniku haseł ani tokenów dostępu.
Kryterium weryfikacji: kontrolowana zmiana powoduje utworzenie odpowiedniego zapisu, nieuprawniony użytkownik nie może go edytować, a zachowanie audytowe przy pełnym magazynie odpowiada udokumentowanej polityce.
Ujawnienie wpisów tajnych podczas odczytu konfiguracji
Punkt końcowy statusu zwraca pełny obiekt konfiguracji, w tym poświadczenie usługi telemetrycznej. Użytkownik uprawniony do wyświetlania statusu otrzymuje informacje, których nie potrzebuje do wykonywania swojej roli.
Proponowany środek kontroli: zwracać odpowiedź dostosowaną do celu, pomijając pola tajne, oraz egzekwować uprawnienia podczas odczytu konfiguracji. Szyfrowanie transmisji nie eliminuje problemu nadmiernej ilości zwracanych danych.
Kryterium weryfikacji: sprawdzić odpowiedzi dla każdej obsługiwanej roli i potwierdzić, że wartości poufne nie pojawiają się w odpowiedziach, błędach ani dziennikach.
Przetwarzanie danych wejściowych wyczerpuje zasoby bramy
Nadawca dostarcza zbyt duże lub powtarzające się wiadomości sterownika. Parsowanie i buforowanie zużywają zasoby potrzebne bramie również do zarządzania i telemetrii.
Proponowany środek kontroli: ograniczyć rozmiary wiadomości i kolejek, walidować dane wejściowe przed kosztownym przetwarzaniem i odizolować przetwarzanie krytyczne. Limity ustalić na podstawie zmierzonej wydajności i wymaganego zachowania produktu przy przeciążeniu.
Kryterium weryfikacji: w zatwierdzonym środowisku testowym przeprowadzić uzgodnione testy przeciążeniowe i obserwować pamięć, głębokość kolejki, dostępność usług oraz odzyskiwanie działania. Limity akceptacji wynikają z wymagań tego produktu; nie zakłada się uniwersalnej wartości granicznej.
Użytkownik tylko do odczytu dociera do operacji zapisu
Użytkownik może się zalogować i wyświetlić status. Wywołuje bezpośrednio API zapisu konfiguracji, z pominięciem interfejsu. Jeśli API sprawdza wyłącznie uwierzytelnienie, użytkownik uzyskuje uprawnienie zastrzeżone dla administratorów.
Proponowany środek kontroli: na serwerze egzekwować uprawnienia do czynności i zasobów w każdej ścieżce zapisu. Zachować tę samą regułę dla zwykłych żądań, operacji zbiorczych i punktów końcowych konserwacji.
Kryterium weryfikacji: bezpośrednie żądania zapisu z konta mającego dostęp tylko do odczytu kończą się niepowodzeniem, a zapisana konfiguracja pozostaje niezmieniona. Powtórzyć test na koncie upoważnionym, aby potwierdzić, że zamierzona operacja nadal działa.
Zakres i pozostałe ryzyka
Sześć kategorii odpowiada definicjom STRIDE firmy Microsoft. Scenariusze ataków i środki kontroli zależą od opisanej powyżej architektury bramy.
Rzeczywisty produkt może mieć kilka scenariuszy ataku należących do jednej kategorii, a jeden atak może pasować do kilku kategorii. Analiza powinna też obejmować interfejsy produkcyjne, konserwacyjne i odzyskiwania, jeśli produkt je ma.
Po wdrożeniu i przetestowaniu środka kontroli należy ocenić nadal możliwe ataki według uzgodnionych kryteriów ryzyka. Wynikowa decyzja dotyczy analizowanego wydania produktu.