Modelowanie zagrożeń – teoretycznie

Wprowadzenie

Każda firma lub instytucja wytwarzająca oprogramowanie powinna przeanalizować wymagania dotyczące bezpieczeństwa stawiane przed ich aplikacjami. Jedną z metod wspomagających wspomnianą analizę jest zastosowanie takich technik, które będą już w fazie projektowania, umożliwiały przeciwdziałanie zagrożeniom.

Należy zauważyć, iż im bardziej konkretny produkt jest wystawiony na potencjalne zagrożenia oraz im bardziej wartościowe informacje przetwarza, tym większe wyzwanie stoi przed zespołem zajmujących się bezpieczeństwem tego produktu. Co więcej, większość oprogramowania sprzedawanego klientom lub używanego przez organizacje albo biznes powinna przechodzić przez proces analizy bezpieczeństwa. Wyjątek od tej reguły mogą stanowić niektóre proste gry lub aplikacje rozrywkowe, które nie przetwarzają ważnych danych i/lub nie kontaktują się z Internetem.

Metodyka modelowania zagrożeń

Modelowanie zagrożeń (ang. Threat Modeling) swoim zakresem obejmuje identyfikację zasobów, które mogą być atakowane. Następny kroki to analiza zagrożeń i podatności atakowanego zasobu. Ostatnie kroki to ustalanie ryzyka i środków łagodzących. Z takich lub podobnych kroków składa się większość metodyk związanych z modelowaniem zagrożeń. Istotne jest to by metodyka wspierała zarówno analizę oprogramowania jak i umożliwiała badanie rozwiązań, które w istotnym stopniu bazują na infrastrukturze (np.: aplikacje mobilne, IoT).

Podstawowe pojęcia

W ramach niniejszego tekstu będę posługiwał się następującymi definicjami:

• Zagrożenie (ang. Threat) – każde potencjalne wystąpienie, złośliwe lub w inne rodzaju, które może mieć niepożądany wpływ na zasoby systemowe (pliki, klucze rejestru, przesyłanie danych itp.). Niepożądanymi efektami mogą być awaria systemu, możliwość odczytu poufnego pliku lub modyfikacji klucza rejestru itp.
• Podatność (ang. Vulnerability) – pewna niefortunna cecha, która umożliwia wystąpienie zagrożenia. Typowe przykłady to przepełnienie bufora, odblokowany port na firewall, możliwość wpisania kodu SQL na formatce wyszukiwania.
• Atak (ang. Attack) – działanie podejmowane przez złośliwego intruza, który wykorzystuje podatności w celu materializacji zagrożenia. Typowe ataki to usunięcie struktury bazy danych po wstrzyknięciu kodu w okno wyszukiwania lub ciągły reset aplikacji wynikający z przepełnienia bufora.

Ogólny proces modelowania zagrożeń

Modelowanie zagrożeń dla dużych systemów może być bardzo trudne. Jednym z rozwiązań może być modelowanie zagrożeń dla poszczególnych modułów, trzeba jednak mieć na uwadze, że to podejście może doprowadzić do pominięcia zagrożeń występujących dopiero po złożeniu tych modułów w całość. Innym rozwiązaniem może być wyznaczenie granic zaufania naszej aplikacji i modelowanie zagrożeń dla wszystkich składników z tych granic. Następnie sprawdzamy czy na zewnątrz tych granic są jeszcze jakieś składniki naszej aplikacji, które nie były wzięte pod uwagę.

Można wyszczególnić trzy etapy procesu modelowania zagrożeń. Należą do nich:

• przygotowanie – projektanci systemu, na podstawie danych wejściowych dostarczonych przez analityków, przygotowują opis systemu za pomocą diagramów DFD. Wyniki ich prac przekazywane są do pozostałych członków zespołu, aby mogli się z nimi zapoznać przed etapem analizy. Opis systemu obejmuje Elementy otoczenia systemu, procesy jakie zachodzą w systemie, magazyny danych oraz przepływy danych.
• analiza – identyfikacja wszystkich zagrożeń i dodanie ich do dokumentu modelu zagrożeń. W tym kroku nie są proponowane żadne środki łagodzące te zagrożenia.
• ustalanie środków łagodzących – zespół bada model systemu pod kątem rozwiązań umożliwiających zastosowania odpowiednich środków zaradczych dla zagrożeń zidentyfikowanych na etapie analizy.

Wymienione kroki w sposób ogólny prezentują proces analizy ryzyka, którego wynikiem są wytworzone produkty.

Produkty procesu modelowania zagrożeń

Głównym produktem wynikowym procesu modelowania zagrożeń jest dokument (lub dokumenty), który opisuje ma wysokim poziomie abstrakcji tworzone oprogramowanie (często w postaci diagramów przepływu danych – DFD), wykazuje elementy, które powinny być w szczególny sposób chronione oraz wymienia potencjalne zagrożenia uporządkowane według stopnia ryzyka. Dokument ten może także zawierać listę środków łagodzących te zagrożenia.

Opis aplikacji powinien zawierać:

• Scenariusze wykorzystania, które obejmują konfigurację wdrożeń i powszechne zastosowanie aplikacji u klientów.
• Zależności zewnętrzne, które obejmują produkty, składniki i usługi, od których zależy aplikacja.
• Założenia dotyczące bezpieczeństwa usług oferowanych przez inne składniki.
• Uwagi o bezpieczeństwie zewnętrznym zawierające informacje na temat bezpiecznego działania systemu, przydatne dla administratorów i użytkowników końcowych.

Powyższe artefakty powinny wytworzyć osoby z grupy projektowej, np. architekt, menadżer projektu lub analityk. Przy wyborze osoby odpowiedzialnej za ten proces musi zostać uwzględniony poziom i zakres jej wiedzy dotyczący dziedziny bezpieczeństwa.

STRIDE

W swojej praktyce od lat w zakresie modelowania zagrożeń bazuję na Cyklu Projektowania Zabezpieczeń (ang. The Security Development Lifecycle, SDL), który został opracowany przez Microsoft ponad 20 lat temu. Metoda ta bazuje na STRIDE, którego autorami są Praerit Garg i Loren Kohnfelder. Mimo swojego wieku, podejście to jest podejściem uniwersalnym. Zmianie ulegają opisywane zasoby, zagrożenia i ryzyka a sama metoda pozostaje. Znamienny jest fakt, ze ostatnia aktualizacja SDL miała miejsce w 2018 roku.

Nazwa STRIDE odnosi się do pierwszych liter sześciu grup zagrożeń:

• Spoofing Identity
• Tampering
• Repudiation
• Information disclosure
• Denial-of-service
• Elevation-of-privileges

Podszywanie się pod inną tożsamość (ang. Spoofing Identity), które pozwala intruzowi udawać coś lub kogoś innego, np. inną osobę/użytkownika, lub inne urządzenie, z którym nasza aplikacja się komunikuje.

Manipulacja (ang. Tampering), które oznacza złośliwe modyfikowanie danych lub kodu. Nieautoryzowana manipulacja danych może dotyczyć danych zapisanych, jak i danych przesyłanych pomiędzy dwoma urządzeniami.

Zaprzeczalność (ang. Repudiation), które polega na wykorzystaniu braku w zabezpieczeniach, które nie pozwala na potwierdzenie lub zaprzeczenie wykonania pewnych działań przez intruza. Oznacza to, że nie można udowodnić kto i kiedy dokonał zmiany. Ofiara ataku nie może zaprzeczyć, że to wykonania danej czynności, nie może udowodnić także wykonania danej akcji.

Ujawnienie informacji (ang. Information disclosure), które dotyczy groźby ujawnienia informacji osobom, które są do odczytu tych informacji nieuprawnione. Zdolność użytkownika do odczytu pliku, do którego on lub on nie miał dostępu, a także zdolność intruza do odczytu danych podczas przesyłania między dwoma komputerami, są zagrożeniami ujawnienia. Należy pamiętać, że zagrożenie to różni się od zagrożenia fałszowaniem, ponieważ tutaj sprawca uzyskuje dostęp do informacji bezpośrednio, a nie musi sfałszować legalnego użytkownika.

Odmowa usługi (anf. Denial-of-Service, DoS), która polega na zablokowaniu lub ograniczeniu (pogorszeniu) dostępu do usługi dla jej użytkowników, np. przez chwilowe wyłączenie serwera WWW lub zablokowanie kanału dostępu (np. łącza internetowego).

Podniesienie uprawnień (ang. Elevation-of-privileges), która dotyczy sytuacji, w której użytkownik uzyskuje większe uprawnienia, niż te, które zostały dla niego przypisane. Problem ten dotyczy zarówno intruzów zewnętrznych, jak i docelowych użytkowników aplikacji, którzy uzyskują zwiększone uprawnienia, aby mieć np. możliwość dostępu do danych, do których nie mają uprawnień.

Tak zidentyfikowane grupy zagrożeń mogą być zmapowane na elementy

Mapując elementy na grupy zagrożeń należy wziąć pod uwagę, że dany typ zagrożenia dotyczy tylko wybranych elementów.

Typ elementu	S	T	R	I	D	E
Element zewnętrzne	X		X
Procesy		X		X	X
Magazyny danych		X	X	X	X
Przepływy danych	X	X	X	X	X	X

Warto zauważyć, że mapowanie elementów na zagrożenia sklasyfikowane w STRIDE ogranicza zakres spekulacji.

Zagrożenia i planowanie środków łagodzących

Ostatnie dwa kroki to identyfikacja poszczególnych zagrożeń w kontekście już konkretnej grupy zagrożeń. Przykładowo należy wypisać wszystkie zagrożenia związane z Elementami zewnętrznymi, które są związane z Podszywanie się pod inną tożsamość (ang. Spoofing Identity). Dość często w takim przypadku korzysta się z drzew zagrożeń.

Drzewa te w zależności kontekstu, systemu, opisywanej sytuacji, różnią się zagrożeń. Budowanie drzew zagrożeń wymaga specjalistycznej wiedzy zakresu bezpieczeństwa danego typu aplikacji. Należy pamiętać, iż każdy system może mieć inne drzewo zagrożeń. Jeśli nie dysponujesz drzewami zagrożeń zastanów się nad potencjalnymi atakami na twoje rozwiązanie.

Przed ostatnim krokiem jest planowanie środków łagodzących zagrożenie. Środki łagodzenia zagrożenie to działania, jakie zostaną podjęte celem mitygacji zagrożenia.

Ostatnim krokiem jest ustalenie ryzyka. Ustaleni ryzyka ma za zadanie oszacowanie prawdopodobieństwa wystąpienia danego rodzaju ataku i tym samym ukierunkowanie działań łagodzących w konkretnym kierunku. Najcześciej korzystam z modelu DREAD.

• Damage – Obrażenia – jak zły byłby atak?
• Reproducibility – Odtwarzalność – jak łatwo odtworzyć atak?
• Exploitability – Możliwość wykorzystania – ile pracy wymaga uruchomienie ataku?
• Affected users – Dotknięci użytkownicy – na ile osób to wpłynie?
• Discoverability – Wykrywalność – jak łatwo jest wykryć zagrożenie?

Przygotowanie odpowiedniego arkusza z szacunkami ryzyka pomaga podjąć kolejne decyzje.

Reasumując. Modelowanie zagrożeń jest jednym z najważniejszych etapów wpływających na poprawę bezpieczeństwa oprogramowania. Powodem tego jest fakt, że etap ten odbywa się na początku procesu wytwarzania oprogramowania i pozwala zidentyfikować w projekcie problemy przed rozpoczęciem programowania, co z kolei może w znacznym stopniu ograniczyć koszty usuwania tych problemów w dalszych etapach cyklu życia oprogramowania.

Powodzenia w modelowaniu zagrożeń 🙂

Cześć praktyczna została opisana w tekście: Modelowanie zagrożeń – praktycznie