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

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