Category Archives modelowanie zagrożeń

W poprzedniej części zaprezentowałem model przepływu danych oparty o diagram maszyny stanowej. Zaproponowałem także mechanizm mapowania elementów z diagramu maszyny stanowej na zagrożenia (w oparciu o STRIDE z SDL). Dziś kolejna czwarta i ostania cześć, w której zaprezentuje techniki dokumentacji ryzyk oraz podatności. Na końcu opiszę jak dokumentować mechanizmy łagodzące oraz zrobię krótkie podsumowanie. Zapraszam do lektury. 

Ustalenie ryzyka

Sklasyfikowane klasy zagrożeń wymagają doprecyzowania ryzyka dla każdej z klas.

clip_image002[7]

Rysunek 4. Drzewo zagrożeń – manipulowanie przy przepływie danych (na podst. [1])

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.

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.

Jak pisałem kilka tygodni temu przygotowałem trochę większy tekst. Tym razem na temat  modelowania zagrożeń systemów informatycznych.

Co tydzień w każdą środę będę publikował  jedną cześć. Łącznie będzie poza tym wpisem 3 części. Zapraszam do lektury.

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.

Close