Modelowanie zagrożeń systemów informatycznych z wykorzystaniem języka UML – SDL

Cykl Projektowania Zabezpieczeń (ang. The Security Development Lifecycle, SDL) jest zaproponowanym przez Microsoft 13 etapowym procesem tworzenia znacząco bezpieczniejszego oprogramowania[1]. Metodykę tą wybrałem z dwóch powodów. Po pierwsze swoim zakresem obejmuje cały cykl życia procesu wytwórczego oprogramowania a po drugie jest stosowana w praktyce przez jej twórcę – firmę Microsoft. Ważna zaletą jest to, że specyfikacja jest dostępna bezpłatnie na stronach firmy Microsoft.

Wspomniane 13 obszarów wsparcia SDL to (zgodnie z [2])

  • · Edukacja i świadomość
  • · Narodziny projektu
  • · Definiowanie i stosowanie najlepszych metod projektowania
  • · Ocena ryzyka produktu
  • · Analiza ryzyka
  • · Tworzenie dokumentów i narzędzi i najlepszych metod zabezpieczenia klientów
  • · Zasady bezpiecznego kodowania
  • · Zasady bezpiecznego testowania
  • · Kampania bezpieczeństwa
  • · Końcowy przegląd bezpieczeństwa
  • · Planowanie reakcji na problemy z bezpieczeństwem
  • · Publikacja produktu
  • · Reagowanie na problemy bezpieczeństwa w praktyce

 

W ramach niniejszego tekstu ograniczam się tylko do obszaru związanego z analizą ryzyka. W kolejnych dwóch punktach przedstawię artefakty i procesy, które definiują analizę ryzyka w SDL, i które stanowią bazę do trzeciej części tekstu (publikacja za tydzień) – metody modelowania zagrożeń w UML.

Artefakty

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.

Proces

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
  • analiza
  • ustalanie środków łagodzących

 

W kroku pierwszym 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.

W drugim kroku następuje 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.

Na tym etapie zespół bada model systemu pod kątem rozwiązań umożliwiających zastosowania odpowiednich środków zaradczych dla zagrożeń zidentyfikowanych na etapie analizy.

Każdy z wymienionych etapów może zostać podzielony na konkretne działania. I tak etap pierwszy obejmuje:

  • · Zdefiniowanie scenariuszy użycia.
  • · Zgromadzenie listy zależności zewnętrznych.
  • · Zdefiniowanie założeń bezpieczeństwa.
  • · Zanotowanie uwag o bezpieczeństwie zewnętrznym.

 

Etap drugi to identyfikacja i analiza zagrożeń czyli zgodnie z SDL:

  • · Utworzenie diagramów przepływu danych (DFD) modelowanej aplikacji.
  • · Ustalenie typów zagrożeń.
  • · Rozpoznanie zagrożeń dla systemu.

Etap trzeci obejmuje:

  • · Ustalenie ryzyka.
  • · Zaplanowanie środków łagodzących.

Wymienione kroki w sposób ogólny prezentują proces analizy ryzyka. Każdy z wymienionych etapów wymaga szeregu czynności. Czynności te, wraz z propozycją użycia języka UML zostaną opisane już za tydzień.


[1]Microsoft. SDL [online] www.microsoft.com/security/sdl/default.aspx

[2]Howard M., Lipner S. Cykl projektowania zabezpieczeń. Microsoft Press, 2006

Podobne wpisy

  • Modelowanie zagrożeń systemów informatycznych z wykorzystaniem języka UML–przykład 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 […]
  • Diagramy sekwencji a komponenty Diagramy sekwencji są techniką, która idealnie nadaje się do zaprojektowania przepływu komunikatów pomiędzy klasami. Problem może powstać wtedy, gdy chcemy zaprezentować komunikację (użyte […]
  • Jak żyć Panie Premierze? W czasie ostatnich wyborów, jeden z uczestników spotkania wyborczego zapytał: “Jak żyć Panie Premierze?” Przekładając na grunt modelowania często słyszę: “Jak modelować?”. I o ile daleko […]
  • Model Driven Architecture modele PIM a PSM Zazwyczaj sporo mówi się na temat tego, że model musi być odseparowany od swojej implementacji. Oznacza to, że w pierwszej fazie modelowania nie należy zastanawiać się nad tym, jak będzie […]
  • Cechy perfekcyjnych wymagań na system Jakość opisu wymagań jest bardzo ważna i tego nie muszę nikomu tłumaczyć. Standard  ANSI/IEEE 830  formułuje  szereg  zaleceń,  jakie  powinna  spełniać dobrze napisana specyfikacja […]
Reklama

Leave a Comment

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