Dlaczego modelowanie zagrożeń ma znaczenie

Modelowanie zagrożeń to uporządkowany proces identyfikowania tego, co może pójść nie tak w systemie, zanim odkryją to napastnicy. Polega na analizie projektu, wyszczególnieniu możliwych zagrożeń i podjęciu decyzji, jak je ograniczyć.

Odpowiada na cztery podstawowe pytania:

• Co budujemy?
• Co może pójść nie tak?
• Co zamierzamy z tym zrobić?
• Czy wykonaliśmy dobrą pracę?

Modelowanie zagrożeń realizuje zasadę przesuwania bezpieczeństwa w lewo: zajmowania się bezpieczeństwem na wczesnym etapie cyklu wytwarzania, a nie dopiero po wdrożeniu.

Koszt naprawy błędu rośnie gwałtownie, im później zostanie on znaleziony:

• Faza projektowania — zmiana diagramu, niemal bez kosztów
• Programowanie — przepisanie części kodu
• Produkcja — awaryjna poprawka, incydent i możliwe naruszenie bezpieczeństwa

Znalezienie błędu w projekcie, zanim zostanie napisana choć jedna linia kodu, jest najtańszą dostępną metodą naprawy.

Modelowanie zagrożeń wymusza świadomą zmianę perspektywy: zamiast myśleć o tym, jak system powinien działać, należy zacząć myśleć o tym, jak można go nadużyć.

Obrońcy naturalnie skupiają się na funkcjach i prawidłowych ścieżkach działania. Napastnicy szukają:

• Danych wejściowych, które nie są walidowane
• Założeń dotyczących zaufania, które można podważyć
• Kroków, które można pominąć lub powtórzyć
• Danych, które powinny być chronione, ale nie są

Modelowanie sprawia, że myślenie w kategoriach przeciwnika staje się systematyczne, a nie przypadkowe.

Trzy pojęcia stanowią podstawę każdego modelu zagrożeń. Należy je rozróżniać:

• Zasób — coś wartościowego, co należy chronić (dane klientów, dane uwierzytelniające, dostępność)
• Zagrożenie — potencjalne niepożądane zdarzenie lub sprawca (napastnik kradnący dane)
• Podatność — słabość umożliwiająca zagrożeniu odniesienie skutku (brak sprawdzenia uprawnień)

Ryzyko pojawia się, gdy zagrożenie może wykorzystać podatność w celu zaatakowania cennego zasobu.

Nie można chronić czegoś, czego wcześniej nie zidentyfikowano. Każdy model zagrożeń należy zacząć od sporządzenia listy istotnych elementów.

Typowe kategorie zasobów:

Modelowanie zagrożeń jest najbardziej wartościowe w konkretnych momentach, a nie jako jednorazowe działanie:

• Podczas projektowania nowego systemu lub funkcji
• Podczas wprowadzania istotnej zmiany architektury
• Podczas dodawania nowej granicy zaufania (nowej integracji lub zewnętrznego API)
• Po incydencie bezpieczeństwa, aby znaleźć powiązane luki

Dojrzałe zespoły traktują je jako ciągły proces i wracają do modelu wraz z rozwojem systemu.

Modelowanie zagrożeń to praca zespołowa. Model stworzony przez jedną osobę pomija zbyt wiele kontekstu.

Skuteczna sesja obejmuje:

• Programistów, którzy wiedzą, jak system faktycznie działa
• Architektów, którzy rozumieją zamysł projektowy
• Inżynierów bezpieczeństwa, którzy znają wzorce ataków
• Właścicieli produktu, którzy rozumieją wpływ na biznes

To różnorodność perspektyw pozwala ujawnić zagrożenia, których nie dostrzegłaby żadna pojedyncza rola.

Istnieje kilka uporządkowanych metodyk; można je łączyć zależnie od potrzeb:

• STRIDE — kategoryzuje zagrożenia według typu; świetnie sprawdza się w przypadku projektów technicznych (zostanie omówiona w następnej lekcji)
• PASTA — koncentruje się na ryzyku i łączy zagrożenia z wpływem na biznes
• Drzewa ataku — modelują cele atakującego i ścieżki prowadzące do ich osiągnięcia
• DREAD — model punktowej oceny służący do ustalania priorytetów ryzyka

STRIDE jest najczęściej nauczanym punktem wyjścia, ponieważ jest metodyczny i przystępny.

Model zagrożeń jest użyteczny tylko wtedy, gdy prowadzi do konkretnych działań. Typowe rezultaty obejmują:

• diagram systemu i jego granic zaufania
• listę zidentyfikowanych zagrożeń, podzielonych na kategorie
• ocenę ryzyka dla każdego zagrożenia
• środki zaradcze lub decyzje o akceptacji ryzyka
• zadania przypisane właścicielom

Jeśli model zagrożeń kończy się dokumentem, na podstawie którego nikt nie podejmuje działań, oznacza to jego niepowodzenie.

Próby modelowania zagrożeń często kończą się niepowodzeniem w przewidywalny sposób. Należy unikać tych pułapek:

• Robienie wszystkiego naraz — próba zamodelowania całego systemu jednocześnie; zamiast tego należy ściśle zawęzić zakres
• Paraliż analityczny — niekończące się dyskusje bez podejmowania decyzji
• Traktowanie tego jako formalności — tworzenie dokumentu wyłącznie na potrzeby audytora i niepodejmowanie na jego podstawie żadnych działań
• Brak dalszych działań — identyfikowanie zagrożeń bez monitorowania wdrażania środków zaradczych

Zakres powinien być ograniczony, czas pracy z góry określony, a wyniki powiązane z rzeczywistymi zadaniami.

Jeśli nigdy wcześniej nie modelowali Państwo zagrożeń, warto zacząć od tego prostego podejścia:

• Narysować prosty diagram systemu i przepływów danych
• Zaznaczyć miejsca, w których dane przekraczają granicę zaufania
• Dla każdej granicy zastanowić się, co mógłby zrobić atakujący
• Zapisać najważniejsze zagrożenia oraz środek zaradczy dla każdego z nich
• Przypisać właścicieli i wrócić do tych zagadnień później

Nawet 30-minutowa sesja przy tablicy pozwala wykryć problemy, które w przeciwnym razie trafiłyby na produkcję.

Sprawdźcie Państwo swoją znajomość podstaw modelowania zagrożeń.

Dowiedzieli się Państwo, dlaczego modelowanie zagrożeń ma znaczenie:

• Modelowanie zagrożeń w uporządkowany sposób odpowiada na pytanie, co może pójść nie tak, zanim dowiedzą się o tym atakujący
• Przesuwa bezpieczeństwo w lewo, dzięki czemu usuwanie problemów jest znacznie tańsze
• Należy rozróżniać aktywa, zagrożenia i podatności; ryzyko powstaje na ich styku
• Modelowanie należy przeprowadzać na etapie projektowania i przy wprowadzaniu dużych zmian, z udziałem zespołu wielofunkcyjnego
• Należy unikać pułapek, takich jak robienie wszystkiego naraz czy brak dalszych działań, i zawsze uzyskiwać rezultaty prowadzące do konkretnych działań

Następnie poznają Państwo platformę STRIDE służącą do kategoryzowania zagrożeń.