W poprzedniej części opisałem bardzo ogólnie metodykę SDL (Security Development Lifecycle). W tej części postaram się pokazać jak użyć UML w modelowaniu zagrożeń. Zaczynajmy.

UML w modelowaniu zagrożeń

Wykorzystanie języka UML w zakresie modelowania zagrożeń nie jest nową koncepcją. Skorzystali z niej między innymi Jurgens i Johnstone (odpowiednio Jurjens J. Secure Systems Development with UML. Johnstone M.N. Threat Modelling with Stride and UML). Inne modele, z jakimi można się spotkać przykładowo w książce Swiderskiego (Swiderski F., Snyder W. Modelowanie zagrożeń. Microsoft Press, 2005) wskazują na diagramy DFD, które nie są obecnie powszechnie stosowanym językiem specyfikowania systemów IT.

W swojej pracy staram się używać UML “sauté” – bez modyfikacji . Z tego też powodu postaram się użyć UML-a do wsparcia metodyki SDL. Istotą SDL są przepływy danych. Przepływy danych można w UML zaprezentować wieloma technikami. Mi najbardziej odpowiada diagram maszyny stanowej. To na nim pokazuje przepływy danych  w obszarze modelowania zagrożeń. Można też użyć diagramu aktywności.

Zauważ, że zastosowanie diagramów maszyny stanowej, nie koliduje z modelowaniem procesów biznesowych lub procesów systemowych za pomocą diagramów aktywności oraz modelowaniem działania aplikacji za pomocą diagramów sekwencji.

Zastosowanie diagramów maszyny stanowej nie wymaga stosowania innych elementów niż powszechnie wskazanych w specyfikacji języka UML. Zmienia się jedynie zakres znaczenia co wskazuję w tabeli 1.

Tabela 1. Notacja elementów maszyny stanowej w modelowaniu danych

Typ element SDL

Element diagram

maszyny stanowej

piktogram

Element zewnętrzny

aktor

clip_image002

Procesy (system w trakcie realizacji procesu jest w pewnym stanie)

stan

clip_image004

Magazyny danych

obiekt

ze stereotypem

<<date store>>

clip_image006

Przepływy danych

obiekt – Information Item

clip_image007

Wskazane w tabeli elementy odpowiadają koncepcji diagramów DFD wymaganych przez SDL, jako techniki stosowanej do modelowania przepływów danych.

Przepływy danych

Czas na przykład. Będzie nim model przepływu danych dla sklepu internetowego.

Modele zbudowane są na dwóch poziomach abstrakcji. Ogólnym (rys. 1) oraz szczegółowym (rys.2)

clip_image002

Rysunek 1. Model przepływu danych – wysoki poziom abstrakcji (oprac. własne)

clip_image004

Rysunek 2. Model przepływu danych – fragment (oprac. własne)

Na rysunku 1 linią przerywaną zaznaczono granice systemu. Należy także zauważyć, że model przepływu danych nie determinuje kolejności przepływu danych a jedynie wskazuje na ich przepływ oraz kierunek tego przepływu. 

Ustalenie rodzajów zagrożeń

Po zamodelowaniu przepływów czas na kolejny etap. Etap ten dotyczy ustalenia rodzajów zagrożeń, na jakie nasza aplikacja może być narażona. Jednym ze sposobów ustalenia zagrożeń jest zastosowanie taksonomii zagrożeń STRIDE, która jest stosowana przez firmę Microsoft – autora procesu SDL. Nazwa STRIDE odnosi się do pierwszych liter sześciu rodzajów zagrożeń:

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

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

Manipulacja (Tampering), które oznacza złośliwe modyfikowanie danych lub kodu.

Zaprzeczalność (Repudiation), które polega na wykorzystaniu braku w zabezpieczeniach, które nie pozwala na potwierdzenie lub zaprzeczenie wykonania pewnych działań przez napastnika, np. brak jest w systemie zapewnienia śledzenia niedozwolonych działań.

Ujawnienie informacji (Information disclosure), które dotyczy groźby ujawnienia informacji osobom, które są do odczytu tych informacji nieuprawnione.

Odmowa usługi (Denial-of-service), 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).

Zwiększenie uprawnień (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 napastnikó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ń.

Mapując elementy zagrożeń należy wziąć pod uwagę, że dany typ zagrożenia dotyczy tylko wybranych obszarów modelu przepływu danych. Sytuację tą (na podstawie SDL) przedstawia tabela 2.

Tabela 2. Mapowanie STRIDE na typy elementów diagram maszyny stanowej

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

Wskazanie zakresu możliwych zagrożeń wymaga przyporządkowania zagrożeń do poszczególnych artefaktów modelu przepływu danych. Przyporządkowanie to zaprezentowano na rysunku 3. Poszczególne elementy zagrożeń STRIDE zamodelowano jako element item ze stereotypem threat a relację pomiędzy zagrożeniem a artefaktem została zbudowana w oparciu zależność.

clip_image006

Rysunek 3. Przyporządkowanie zagrożeń do magazynów danych (oprac. własne)

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

W kolejnej części, już za tydzień, opiszę techniki modelowania ryzk i podatności.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close