Security Threat Modeling (skrót: STM) to, jak wskazuje tłumaczenie nazwy, analiza zagrożeń związanych z bezpieczeństwem IT dla systemu, aplikacji, interfejsu, modelu operacyjnego (chmura vs OnPrem) itp. Tego typu analiza zagrożeń nie ogranicza się do systemów IT, ale jest ważna zawsze, gdy firmy i organizacje pracują z aktywami wymagającymi ochrony.

 

Prosty przykład spoza świata IT: jeśli właściciel domu zainstalował w swoim salonie czujnik dymu, który powinien włączyć alarm w momencie powstania dymu, to właściciel domu "przeanalizował" zagrożenie wdychania dymu z pożaru i "złagodził" to zagrożenie za pomocą czujnika dymu.


W zastosowaniu do świata technologii informatycznych oznacza to, że możliwe zagrożenia dla systemu informatycznego są analizowane i ograniczane. Najlepiej zrobić to jeszcze przed opracowaniem systemu. W naszym przykładzie z powstaniem dymu lub ognia w domu, np. przy budowie domu należy zwrócić uwagę na materiały niepalne, co stanowi ewentualne "złagodzenie".


Stwierdzamy również, że analiza zagrożeń powinna być centralną częścią procesu tworzenia oprogramowania, tak aby zidentyfikowane niebezpieczeństwa mogły zostać przetworzone podczas "budowy" systemu.

 

Dlaczego Security Threat Modeling?

Popatrzmy na przykład domu: decyzje podjęte z wyprzedzeniem mogą mieć znaczący wpływ na bezpieczeństwo nieruchomości. Oczywiście można (i należy) zainstalować czujniki dymu, ale czy nie byłoby lepiej, gdybyśmy od początku stosowali niepalne materiały budowlane?


Analiza zagrożeń może zapobiec niekorzystnym lub błędnym decyzjom dotyczącym architektury IT, jeszcze zanim powstanie linijka kodu. Ponadto analiza zagrożeń może być przydatna do zrozumienia i uzupełnienia wymagań bezpieczeństwa systemu.


Przykład ze świata IT: czy dane muszą być szyfrowane? Nie jest to konieczne na serwerze, ale gdy są używane na urządzeniach mobilnych, już powinny być. Jak widać, istnieje ścisła zależność pomiędzy scenariuszem zagrożenia, środkami zapobiegawczymi (mitygacyjnymi) i wymaganiami systemowymi. Dzięki uwzględnieniu wymagań (bezpieczeństwa) na wczesnym etapie projektowania rozwiązania, można dostarczyć znacznie bezpieczniejszy system.

 

Jak w praktyce przeprowadzić Security Threat Modeling?

Najprościej rzecz ujmując, Security Threat Modeling to nic innego jak wczesne rozważenie, co i gdzie może się wydarzyć w odniesieniu do bezpieczeństwa IT i odpowiednie zdefiniowanie strategii ochrony opartej na tym punkcie, w celu uniknięcia najgorszego scenariusza. W tym celu należy odpowiedzieć na następujące pytania:

 

  1. Co jest w trakcie opracowywania?
  2. Co może się stać?
  3. Co można z tym zrobić?
  4. Jak ocenia się ogólną sytuację?
  5. Jak wyglądała jakość analizy?

 

Każde z tych pięciu pytań należy traktować jako krok w procesie analizy zagrożeń.

 

Krok 1: Co jest w trakcie opracowywania?

Popularnym sposobem opisu systemu informatycznego są schematy techniczne. Schematy przepływu danych są idealne w naszej sytuacji. Wszystkie interfejsy i przepływy danych są widoczne na tym schemacie. Bo tylko tam, gdzie dane są dostępne i/lub „przepływają”, pojawiają się zagrożenia.


Jako przykład przyjrzyjmy się „typowej” aplikacji internetowej: nasza aplikacja działa w centrum danych i składa się z proxy, aplikacji internetowej i bazy danych. Oczywiście każda aplikacja internetowa ma też co najmniej jednego aktora, czyli użytkownika, który ma dostęp do proxy, a więc do aplikacji internetowej i bazy danych przez Internet.


Oprócz odpowiedzialnego architekta, podczas tworzenia schematu przepływu danych zawsze należy skonsultować się z jednym lub kilkoma programistami i administratorami systemu. Jest to jedyny sposób, aby na koniec tego kroku stworzyć schemat, który będzie poprawny w opinii wszystkich zaangażowanych, a poprawny schemat ma fundamentalne znaczenie dla późniejszego procesu Security Threat Modeling.

 

Krok 2: Co może się stać?

Po stworzeniu schematu przepływu danych w systemie, kolejnym krokiem jest zastanowienie się, co może się wydarzyć. Warto przyjąć tutaj pewne założenia, aby ograniczyć scenariusze zagrożeń.


Przykład: patrząc na przykład systemu z kroku 1, założenie, że używany jest aktualny system operacyjny pozwala z góry wykluczyć niektóre zagrożenia. Ale uwaga: Takie założenia również powinny być zawsze weryfikowane i uwzględniane w analizie zagrożeń.


Niektóre pytania o to "co może się stać” są oczywiste:

 

  • Czy serwer internetowy jest naprawdę tym, za który się podaje?
  • Czy dane pomiędzy proxy a aplikacją internetową mogą być zmanipulowane?
  • Jak aplikacja internetowa zapewnia, że baza danych otrzymała dane?
  • Czy poprzez aplikację internetową użytkownik może również zobaczyć architekturę, która za nią stoi?
  • Czy aplikacja internetowa (lub baza danych) może zostać uszkodzona przez duże obciążenie?
  • Czy użytkownik może robić rzeczy związane z aplikacją internetową, do których nie ma uprawnień?

 

Oczywiście tę listę można kontynuować niemal w nieskończoność. Ważne rzeczy można zatem łatwo przeoczyć. Dlatego w tych kwestiach należy zastosować metodologię. Opieramy się tu na tzw. metodzie STRIDE, opracowanej przez Microsoft. STRIDE oznacza:

 

  • S: Spoofing
  • T: Tampering
  • R: Repudiation
  • I: Information Disclosure
  • D: Denial of Service
  • E: Elevation of Privilege

Dzięki tej metodzie możemy skategoryzować nasze pytania "Co może się wydarzyć?" i zmniejszyć ryzyko przeoczenia czegoś poprzez ustrukturyzowane podejście. Ściśle rzecz biorąc, każde zagadnienie wymienione powyżej jako przykład można przyporządkować do tych kategorii.

 

Krok 3: Co można z tym zrobić?

Na końcu pytania „Co może się stać?” powinna znaleźć się lista zagrożeń dla każdej interakcji i danych wymienionych na schemacie przepływu danych. W kolejnym kroku przeanalizujemy listę i zajmiemy się napotkanymi zagrożeniami. Można to zrobić na cztery różne sposoby:


Łagodzenie oznacza podjęcie działań mających na celu zmniejszenie zagrożenia lub utrudnienie jego wykorzystania.


Przykład: hasła do interfejsu administracyjnego zmniejszają zagrożenie, że ktoś podszyje się pod administratora.


Eliminacja jest często osiągana poprzez odrzucanie funkcji.


Przykład: można zabezpieczyć interfejs administracyjny hasłami, ale zagrożenie ze strony kogoś podszywającego się pod administratora nadal istnieje. Wyłączenie interfejsu administracyjnego spowodowałoby zniknięcie tego zagrożenia.


Przeniesienie następuje poprzez scedowanie zagrożenia na inną osobę.


Przykład: można pozostawić uwierzytelnianie interfejsu administracyjnego usłudze Active Directory.


Akceptacja ma miejsce, gdy decydujemy się nic nie robić ze zidentyfikowanym zagrożeniem. Może to mieć różne, czasem całkiem uzasadnione skutki. Często są to decyzje oparte na stosunku korzyści do kosztów.


Mamy teraz listę zagrożeń i różne strategie radzenia sobie z tymi zagrożeniami. W kolejnym kroku należy ocenić środki łagodzące i uporządkować je według priorytetów. Wybrane środki łagodzące są uwzględniane w procesie tworzenia oprogramowania. Można to zrobić za pomocą np. historii użytkownika lub po prostu bugów.


Przykład: haker może doprowadzić do awarii bazy danych za pomocą wielu automatycznych żądań.


Na koniec tego działania zapewne pojawi się wiele zadań, które trzeba będzie zrealizować. Ale przed wdrożeniem oceniamy wszystkie zagrożenia i środki, aby przeprowadzić analizę stosunku korzyści do kosztów.

 

Krok 4: Jak ocenia się ogólną sytuację?

W poprzednich dwóch działaniach zidentyfikowano wiele zagrożeń i możliwych środków zaradczych. Kolejnym krokiem jest uporządkowanie tych zagrożeń i środków zaradczych według priorytetów. W tym celu dla każdego zagrożenia określane jest tzw. ryzyko zagrożenia.


Jeden ze sposobów określenia ryzyka zagrożenia ma formę następującego wzoru:

 

Ryzyko zagrożenia = prawdopodobieństwo wystąpienia × wpływ

 

Istnieją różne podejścia do oceny tego ryzyka zagrożeń, np.: Microsoft Bug Bar lub CVSS (Common Vulnerability Scoring System).


W dużych firmach zazwyczaj jest to również zapisane w polityce bezpieczeństwa firmy. Dla uproszczenia, prawdopodobieństwo wystąpienia i wpływ można podzielić na cztery powszechnie stosowane kategorie oceny ryzyka: bardzo wysokie, wysokie, średnie i niskie.


Istnieje wiele różnych sposobów oceny zagrożenia. W pierwszym etapie ważne jest skoordynowane podejście do oceny zagrożeń, które jest stosowane w sposób stały i konsekwentny.


Po ocenie wszystkich zagrożeń bez środków zaradczych należy ponownie ocenić te zagrożenia z uwzględnieniem środków zaradczych. Ostatni krok ma cele dokumentacyjne i jest przydatny do zrozumienia decyzji w późniejszym czasie.

 

Krok 5: Jak wyglądała jakość analizy?

Ostatnim krokiem w Security Threat Modeling jest ocena jakości analizy zagrożeń.

 

Weryfikacja architektury

Najpierw należy wrócić do schematu przepływu danych i sprawdzić, czy nadal jest on poprawny. Nierzadko zdarza się, że decyzje architektoniczne są zmieniane w krótkim czasie: Dodawane są funkcje, przypadki użycia nie brane wcześniej pod uwagę przynoszą ze sobą inne zbiory danych, zmieniają się interakcje między systemami. Dlatego należy zaktualizować lub uzupełnić schemat przepływu danych.

 

Sprawdzanie zagrożeń

Należy oczywiście zidentyfikować nowe zagrożenia wynikające ze zmienionej architektury. Następnie trzeba jeszcze raz sprawdzić wszystkie zidentyfikowane zagrożenia pod kątem ich złagodzenia. W tym celu musimy ponownie przejrzeć listę zagrożeń i zadać następujące pytania: Czy wszystkie możliwe niebezpieczeństwa zostały omówione? Czy wszystkie zagrożenia zostały odpowiednio złagodzone?

 

Testy środków

Wszystkie środki należy przetestować. Testy mogą być wykonywane ręcznie lub automatycznie. Wszystkie środki, które mają być wdrożone, powinny mieć również odpowiednią jakość. W najlepszej sytuacji testy te powinny być zintegrowane z istniejącymi ramami testowymi podczas rozwoju oprogramowania.

 

Wniosek

Oczywiście „prawdziwe” Security Threat Modeling jest znacznie bardziej szczegółowe i złożone niż opisany tutaj proces. Jasne powinno być jednak, jak ważne jest włączenie bezpieczeństwa w sposób koncepcyjny do procesu rozwoju oraz jego aktualizowanie w regularnych odstępach czasu – na przykład podczas opracowywania nowej funkcjonalności lub zmiany modelu operacyjnego.


Przedstawiona tu metoda analizy, wraz z rozważaniami dotyczącymi łagodzenia skutków oraz stosunku korzyści do kosztów, zapewnia większe bezpieczeństwo od samego początku.
Udostępnij ten artykuł