Category Archives UML

Myślę, że czasem warto się pochwalić drobnymi osiągnięciami. W 2013 roku miałem okazję współpracować z Ministerstwem Sprawiedliwości. Brałem udział w projekcie SIWPM (System Informatyczny Wspierający Procesy Merytoryczne). Zadaniem tego systemu jest wsparcie pracowników sądu w ich pracy od biura podawczego poprzez zarządzanie aktami (tzw. kalendarz)  kończąc na wsparciu czynności wydawania orzeczeń.

Kilkanaście miesięcy konsultowałem, wspomagałem z ramienia MS proces zbierania wymagań. Pracując z sędziami, sekretarzami, spędzając na analizie setki godzin,  wydaje się, że dość dobrze poznałem specyfikę pracy naszego sądownictwa. 

Istotne jest jednak to, że brałem udział w jednym z tych projektów, w których Zamawiający nie tylko miał wizję systemu ale także wymusił powstanie obszernej dokumentacji analitycznej.

Wynik tej pracy to ponad 600 przypadków użycia i ponad 500 prototypów ekranów. Zidentyfikowano i opisano ponad 2900 scenariuszy użycia systemu.

Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście modelowania procesów biznesowych i systemowych (patrz tekst:  Diagramy procesów systemowych). Oba diagramy bardzo podobne do siebie choć BPMN 2.0 to już mega możliwości. Myślę, że kluczem do decyzji jest zastosowanie (czyt. Twoje potrzeby)

Lubię używać diagramów aktywności gdy:

Powszechnym jest iż czym większa organizacja tym więcej systemów informatycznych. U moich klientów są ich dziesiątki. Tak tak. Przez lata zbiera się ich trochę bo każdy rok to zmiany w procesach biznesowych i bardzo często dodanie nowego systemu. Znam firmy, w których stajnia Augiasza to najlepsze określenie na zaistniałą sytuację.  Co więcej firma albo modeluje procesy biznesowe w oderwaniu od IT albo nie modeluje ich wcale. Czasem modele biznesowe powstają w innym narzędziu niż pracuje IT.

Jak wobec tego poradzić sobie w takiej sytuacji?

Moją propozycją są diagramy procesów systemowych czyli  diagramy aktywności prezentujący proces biznesowy w kontekście używanych systemów lub komponentów oraz ludzi – użytkowników systemów.

Pozwolę sobie przytoczyć kilka dobrych praktyk związanych z architekturą.

Struktura poszczególnych modułów powinna być na tyle prosta, aby można ją było w pełni zrozumieć.

2. Moduły powinny być luźno ze sobą powiązane, tzn. powinna być możliwa zmiana implementacji jednego modułu, bez znajomości implementacji pozostałych modułów i bez wpływania na ich zachowanie.

3. Łatwość wprowadzania zmian w projekcie powinna pozostawać w rozsądnej relacji do prawdopodobieństwa wymaganych zmian;

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 mi do Premiera i jego problemów dot. rządzenia krajem, tak blisko mi do problemów z modelowaniem. Otóż UML zna już sporo osób. Nieformalnym standardem w zakresie narzędzi jest Enterprise Architect, który jest używany Problem…

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