Modelowanie zagrożeń w małym zespole to godzina spędzona przy tablicy: narysujcie, jak dane przepływają przez wasz produkt, zaznaczcie każde miejsce, w którym przechodzą z jednego poziomu zaufania na inny, i zadajcie sobie pytanie, co mógłby zrobić atakujący po drugiej stronie każdej z tych linii. Znalezione zagrożenia należy uszeregować według tego, jak poważne mogłyby być, a nie według tego, jak prawdopodobne wydają się – a następnie opuścić pomieszczenie z trzema pozycjami w rejestrze zadań. Frameworki pomagają dużym organizacjom uczynić ten proces powtarzalnym; nie są one jednak niezbędne, aby czerpać z niego większość korzyści.
Czym jest modelowanie zagrożeń, gdy pominie się samą metodologię
Wystarczy wpisać hasło „modelowanie zagrożeń”, a szybko trafisz w świat wielkich przedsiębiorstw: formalne procesy, specjalistyczne narzędzia, notacje diagramowe i architekt bezpieczeństwa, który tym wszystkim kieruje. Dla kierownika ds. inżynierii, który ma pod sobą zespół liczący od pięciu do dwudziestu osób i nie dysponuje specjalistą ds. bezpieczeństwa, brzmi to jak powód, by odłożyć to na czas nieokreślony.
W gruncie rzeczy idea ta jest prosta. Każdy system posiada punkty, w których przyjmuje dane wejściowe z źródeł, nad którymi nie ma pełnej kontroli: przeglądarki, telefonu, interfejsu API partnera, wewnętrznego użytkownika posiadającego mniejsze uprawnienia niż administrator. Te punkty to właśnie wasze powierzchnia ataku. Granica między “tym, nad czym mamy kontrolę” a “tym, nad czym jej nie mamy”, to granica zaufania. Modelowanie zagrożeń polega na celowym wyszukiwaniu takich granic i zadawaniu przy każdej z nich pytania: “a co, jeśli to, co znajduje się po drugiej stronie, jest wrogie?”.”
To pytanie jest celem samym w sobie. Wszystko inne w formalnym procesie modelowania zagrożeń — szablony, matryce punktacji, rejestry ryzyka — ma na celu zapewnienie, by pytanie to było zadawane w sposób spójny w dużych organizacjach. W małym zespole osoby, które stworzyły system, już wiedzą, gdzie znajdują się jego słabe punkty. Brakuje im jedynie godziny, podczas której te słabe punkty byłyby jedynym tematem rozmowy.
Działa to również jako zebranie wymagań dotyczących bezpieczeństwa dla zespołów, które nigdy nie miały jego formalnej wersji. Zamiast tego, by ktoś wpisał do specyfikacji “system musi być bezpieczny”, otrzymujemy konkretne stwierdzenia: “sesja gościa nie może mieć możliwości odczytania zamówienia z innej tabeli”, “synchronizacja z systemem POS musi odrzucać ceny, których nie da się dopasować do znanego produktu”. To są stwierdzenia, które można przetestować. “Bezpieczny” – nie.
Jak przeprowadzić sesję modelowania zagrożeń w ciągu godziny
Potrzebujesz osób, które znają system — kierownika projektu, inżynierów odpowiedzialnych za główne komponenty, a najlepiej kogoś, kto wie, jak produkt jest wykorzystywany na co dzień — oraz tablicy. Żadnych szablonów.
1. Narysuj schemat blokowy
Zacznij od pierwszej czynności użytkownika i podążaj za danymi. Ramy dla elementów, które działają (mobilna aplikacja internetowa, API, baza danych, panel administracyjny, system zewnętrzny, z którym się integrujesz), a strzałki dla tego, co przepływa między nimi. Niech to będzie z grubsza: celem jest obraz, co do którego wszyscy zgadzają się, że jest w przybliżeniu prawdziwy. Jeśli w połowie sesji ktoś powie “och, a jeszcze jest…”, to znaczy, że sesja przebiega prawidłowo — właśnie w przypadku nieudokumentowanych przepływów najczęściej pojawiają się problemy.
2. Wyznacz granice obszaru zaufania
Teraz narysuj linię w miejscach, gdzie dane przechodzą z jednego poziomu zaufania na drugi. Typowe miejsca to:
- między dowolnym urządzeniem klienckim a Twoim serwerem zaplecza;
- między użytkownikiem anonimowym a zalogowanym;
- między jedną funkcją wewnętrzną a drugą (kelner i kierownik to nie ta sama osoba);
- między Twoim systemem a dowolnym systemem strony trzeciej;
- między Twoim zapleczem a wszelkimi elementami, które wykonują kod lub przechowują dane, do których nie masz praw własności.
Każda strzałka przecinająca linię to pytanie, które zamierzasz zadać.
3. Wskaż najgorszy scenariusz dla każdego skrzyżowania
Przy każdym skrzyżowaniu zadaj sobie pytanie: “Gdyby osoba znajdująca się po drugiej stronie tej linii chciała wyrządzić krzywdę, co najgorszego mogłaby zrobić za pomocą tej strzałki?”. Zapisz odpowiedź w formie sprawa dotycząca znęcania się — krótkie zdanie sformułowane na wzór opisu użytkownika, ale z punktu widzenia atakującego. “Jako gość zmieniam identyfikator stolika w żądaniu i przeglądam rachunek innego stolika”. “Jako pracownik eksportuję całą listę gości”.”
Jeśli w sali zapadnie cisza, to właśnie tutaj STRIDE służy jako wskazówka. Skrót ten oznacza: spoofing, manipulację, zaprzeczenie, ujawnienie informacji, odmowę usługi oraz podwyższenie uprawnień. Przeczytaj te sześć słów na skrzyżowaniu i zobacz, które z nich zainspiruje cię do jakiegoś pomysłu — to wskazówka, a nie formularz do wypełnienia.
4. Klasyfikuj według skutków, a nie prawdopodobieństwa
Małe zespoły mają talent do przekonywania samych siebie, że nie ma ryzyka: “nikt by się tym nie przejmował”. Szacunki prawdopodobieństwa podczas godzinnej sesji to domysły przebrane za analizę; łatwiej jest osiągnąć porozumienie co do konsekwencji. Czy doszłoby do wycieku danych osobowych? Czy ktoś zapłaciłby mniej, a może w ogóle nie zapłacił? Czy spowodowałoby to wstrzymanie działalności firmy? Czy doprowadziłoby to do uszkodzenia danych w systemie, którego nie da się przywrócić do poprzedniego stanu?
Uporządkuj przypadki nadużyć według tego, jak poważne mogłyby być ich skutki. Zajmij się najpierw sprawami znajdującymi się na szczycie tej listy.
5. Dodaj trzy zadania do listy zadań do wykonania
Zanim ktokolwiek wyjdzie, wybierzcie trzy przedmioty o największych konsekwencjach i zamieńcie każdy z nich na kartkę z imieniem właściciela. Każda kartka opisuje łagodzenie skutków — sprawdzenie, ograniczenie, test, wpis w dzienniku — a nie niejasny zamiar. “Sprawdź, czy każde zlecenie zamówienia znajduje się w tabeli sesji, stosując test z wykorzystaniem identyfikatora z tabeli zewnętrznej” to zadanie. “Przyjrzyj się autoryzacji” — nie.
Liczba „trzy” jest celowa: to wystarczająco mało, by faktycznie wkrótce wprowadzić to do produkcji, a jednocześnie zmusza zespół do dokonania wyboru. Reszta pozostaje w notatkach na następny raz.
Przykład z naszej praktyki: trzy granice zaufania w jednym produkcie
MyRest jest to platforma dla restauracji, stworzona dla firmy myREST Sp. z o.o., polskiej firmy działającej od 2023 roku. Posiada część przeznaczoną dla gości, opartą na kodach QR, oraz panel administracyjny dla personelu, zawierający profile gości, listę potraw, których zabrakło, oraz statystyki dotyczące najlepiej sprzedających się pozycji i godzin szczytu. Całą architekturę determinował jeden wymóg: rozwiązanie musiało współpracować z istniejącym systemem kasowym restauracji, bez konieczności instalowania nowego sprzętu.
Jest to dobry przykład dydaktyczny, ponieważ granice zaufania są w nim widoczne bez konieczności przechodzenia jakiegokolwiek szkolenia. Wystarczy narysować to na tablicy, a trzy linie pojawiają się niemal natychmiast.
Granica nr 1: telefon gościa. Gość skanuje kod QR za pomocą własnego urządzenia. Może to być dowolna osoba, korzystająca z dowolnego urządzenia, mająca swobodę edytowania zamówień — dlatego wszystko po tej stronie jest traktowane jako niewiarygodne. Pytania, które nasuwają się w tym kontekście: czy gość może ingerować w zamówienie przy stole, które nie jest jego, zmieniając identyfikator? Czy może zmienić cenę lub sumę, zanim zamówienie dotrze do systemu zaplecza? Czy może on zasypywać system zamówieniami? Czy kod QR może zostać podmieniony lub ponownie wykorzystany w miejscu, do którego nie był przeznaczony?
Granica 2: pracownicy w panelu administracyjnym. Osoby znane, ale pełniące różne funkcje i posiadające różne uprawnienia. Panel zawiera profile gości oraz dane analityczne, a także zarządza listą blokowanych elementów widoczną dla gości. Pytania brzmią: czy dana rola może widzieć lub robić więcej, niż wymaga tego jej stanowisko? Kto może eksportować dane gości? Jeśli konto pracownika zostanie przejęte, jaki jest zasięg skutków? Czy ktoś może oznaczyć pozycje jako niedostępne lub je zmienić, nie pozostawiając śladu tego, kto to zrobił? Właśnie w tym miejscu przydają się porady od naszego podstawowe zasady bezpieczeństwa w branży hotelarskiej dotyczące rozdzielenia ról personelu, kierownictwa i administracji od samego początku nabiera konkretnego kształtu.
Granica 3: system kasowy. Łatwo to przeoczyć, bo nie wygląda to na zagrożenie. Jest to jednak system, nad którym nie mamy kontroli i którego nie możemy zmienić, a który znajduje się w samym centrum przepływu środków finansowych restauracji. Dane z niego pochodzące — identyfikatory pozycji, ceny, dostępność — przekraczają granicę zaufania, podobnie jak dane wprowadzane przez gości. Pytania brzmią: co się stanie, jeśli system wyśle coś nieoczekiwanego lub nieprawidłowego? Co, jeśli będzie działał wolno lub będzie niedostępny w godzinach szczytu? Co, jeśli wpłynie zamówienie, a system POS odpowie “OK”, ale w rzeczywistości nigdy go nie przetworzy? Nasz artykuł na temat integracji systemu POS z kuchnią porusza tę samą kwestię z perspektywy operacyjnej: Odpowiedź „200 OK” z terminala płatniczego nie oznacza, że zamówienie faktycznie dotarło do kuchni.
Trzy obszary, trzy bardzo różne rodzaje nadużyć: jeden – z natury anonimowy i wrogi, drugi – budzący zaufanie, ale charakteryzujący się nierównymi uprawnieniami, trzeci – zautomatyzowany i pozostający poza kontrolą użytkownika. Większość produktów łączących klientów, pracowników i starsze systemy ma właśnie taki charakter. Integracje trzeciego rodzaju stanowią sedno naszej Usługi integracji API, i to właśnie w takich sytuacjach nieprzemyślane “a co gdyby” często okazuje się później najdroższe.
Na co zwrócić uwagę
Dokument, którego nikt nie otwiera
Najczęstszą przyczyną niepowodzenia modelowania zagrożeń jest sytuacja, w której wynik dobrze przeprowadzonej sesji trafia do dokumentu, którego nikt już nie otwiera, podczas gdy opisane w nim zagrożenia pozostają tak samo aktualne jak wcześniej. Jeśli wynik nie znajduje się w zaległości w zakresie bezpieczeństwa, obok opisu funkcji wraz z właścicielami i szacunkami – tak się nie stało. Traktuj notatki z sesji jako źródło informacji do przyszłych zgłoszeń, a nie jako gotowy produkt.
W każdym razie przekształcenie tego w metodologię
Niektóre zespoły posuwają się za daleko: wdrażają kompletny framework, każda funkcja wymaga modelu, a sam proces staje się czymś, czego ludzie unikają. Wartość tkwi w pytaniu stawianym na każdym etapie, a nie w kompletności.
Modelowanie systemu, o którym marzysz
Narysuj to, co faktycznie działa, łącznie z zadaniem cron, które ktoś dodał w pośpiechu, oraz skrótem administratora, który miał być tylko tymczasowy. Modelowanie idealnej architektury nie uwzględnia rzeczywistych problemów, z którymi się borykasz.
Traktowanie tego jako zamiennika decyzji projektowych
Sesja pozwala zidentyfikować zagrożenia na granicach. Nie określa ona, jakich danych nie należy nigdy gromadzić ani gdzie przechowywane są poufne informacje — te kwestie lepiej rozstrzygnąć na wcześniejszym etapie. Nasz artykuł na temat decyzje dotyczące bezpieczeństwa, które przed pierwszą wersją nie wiązały się z żadnymi kosztami obejmuje tę stronę; te dwie metody najlepiej sprawdzają się w połączeniu.
Kiedy uruchomić to ponownie
Nie potrzebujesz przypomnienia w kalendarzu. Powtórz sesję, gdy zmieni się mapa zaufania: gdy dodasz nowa integracja (dostawca usług płatniczych, nowy terminal płatniczy, interfejs API partnera) lub gdy dodajesz nowy typ użytkownika (nowa rola pracownika, portal dla partnerów, publiczny interfejs API dla podmiotów zewnętrznych). Oba te elementy wyznaczają nowe granice, w których dotychczasowe założenia przestają obowiązywać. Dobrym bodźcem do zmiany jest również przeprojektowanie systemu uwierzytelniania; rutynowe prace nad funkcjami w ramach istniejących granic zazwyczaj nim nie są.
Wniosek
Modelowanie zagrożeń nie wymaga żadnego frameworka, specjalisty ani tygodnia pracy. Wystarczy jedna godzina, osoby, które stworzyły system, oraz tablica, na której narysuje się i podda analizie każdą granicę zaufania. Uszeregujcie znalezione zagrożenia według wagi konsekwencji, dodajcie trzy konkretne środki zaradcze do listy zadań do realizacji i wróćcie do tego zadania, gdy wprowadzicie integrację lub nowy typ użytkownika. Jeśli chcesz, aby ktoś jeszcze rzucił okiem na wytyczone przez ciebie granice – lub na te, które mogły ci umknąć – jest to część naszej Prace związane z kontrolą jakości i audytem bezpieczeństwa.
