Odrabiając zaległości RSS'owe przeczytałem ciekawy wpis firmy Matasano - Ninja Threat Modeling. Szkoda czasu na dłuższe streszczenie tego wpisu, obrazuje on podejście do modelowania zagrożeń w sytuacji kiedy aplikacja już istnieje. Czy kogoś to jeszcze dziwi? Powtórzę, "kiedy aplikacja już istnieje".
Żyjemy w części planety, w której jeszcze moim skromnym zdaniem bardzo słabo rozwinięty jest cykl powstawania i rozwoju aplikacji, szczególnie jeśli chodzi o aspekt bezpieczeństwa - mam na myśli głównie kraj, w którym żyję, czyli Polskę. Jednym z elementów takiego cyklu życia aplikacji jest modelowanie zagrożeń. W pierwotnym zamyśle powinno ono być przeprowadzane jak najwcześniej, zanim programiści zaczną implementować założenia aplikacji.
Niestety często bardzo ciężko o to z kilku powodów:
- niska świadomość osób pracujących przy tworzeniu i rozwoju aplikacji (nie czują potrzeby przeprowadzenia modelowania, nie widzą wartości dodanej - w tym przygotowanie stosownej dokumentacji, która właściwie im samym jest _potrzebna_ stanowi problem, jeszcze nikt nigdy im o tym nie wspomniał)
- opór związany z naciskami po stronie biznesu by system/aplikacja była gotowa na zadany termin - mam w tym temacie różne doświadczenia, widziałem sytuacje kiedy stosowny zespół nie chciał współpracować przy modelowaniu, bo był "zajęty", bo oni nie wiedzą jak to działa, realizują to co chce "biznes" (zaraz, zaraz... ale chyba bez scenariuszów testów akceptacyjnych nie można iść do testowania danego procesu?)
- brak stosownych zapisów w umowie zlecający-wykonawca... i kilka innych.
Aby jakość testów penetracyjnych była możliwie wysoka, ale też adekwatna do ustaleń pomiędzy zlecającym pentest, a wykonującym, moim skromnym zdaniem powinno być przeprowadzone modelowanie zagrożeń na koniec, szczególnie jeżeli nie zostało przeprowadzone wcześniej. Przykładowe podejście do tematu można znaleźć w podanym na samym początku poście firmy Matasano. Jeżeli kogoś zniechęciły problemy na jakie można się natknąć przy modelowaniu zagrożeń na początku projektu aplikacji to mam nienajlepsze wiadomości ;) Jeżeli nie udało się przeprowadzić modelowania na początku to tym bardziej jest duże prawdopodobieństwo, że na koniec będzie z tym kłopot. Mimo tych przeciwności, nazwę to roboczo "losu", WARTO przeprowadzać takie modelowanie na koniec - przed testami bezpieczeństwa.
Dlaczego tytułowy "Threat Modeling in The End" jest warty świeczki?
Bo mam obawę, że bez niego testy penetracyjne to klasyczne, próby przełamania aplikacji w rozumieniu całej rodziny wstrzyknięć (słowo klucze to m.in.: XSS, SQL Injection), testy kontroli dostępu na "chybił trafił" (czyt. bez wiedzy o rolach w aplikacji) czy wytknięcie używania SSL'a w wersji 2. Bez odpowiedniego przygotowania do testów bezpieczeństwa w części przypadków, szczególnie kiedy pentester nie ma doświadczenia z obranym w aplikacji modelem biznesowym, trudno jest mi sobie wyobrazić dobrze opracowane scenariusze testów. Częściowo zahaczyłem o temat we wpisie: Testowanie logiki biznesowej. Moim zdaniem pentest bez uwzględnienia innych aspektów systemu niż tylko (nie)użyte mechanizmy bezpieczeństwa dla przykładowo, podatności wymienionych w OWASP Top 10, jest niepełny[1].
PS
Na blipie zauważyłem zainteresowanie tematem modelowania :-) Dla dobra Nas wszystkich.
[1] - wyjątkiem będą testy, które mają sprawdzić aplikację właśnie _tylko_ pod tym kątem.
Subskrybuj:
Komentarze do posta (Atom)
6 komentarze:
Chętnie dowiedziałbym się, jaką rolę w "modelowaniu zagrożeń" powinny wg Ciebie pełnić poszczególne osoby jakkolwiek zaangażowane w cykl życia aplikacji. Ew. w jaki sposób powinny w uczestniczyć w "modelowaniu".
Jest to do zrobienia jeżeli podpiszesz się pod swoim komentarzem, a nie pozostaniesz anonimowy. Ewentualnie zapraszam do bezpośredniego kontaku.
Ogólnie odpowiadając, rolą poszczególnych osób jest dostarczenie wsadu potrzebnego do przeprowadzenia modelowania oraz wspólna identyfikacja zagrożeń. Wszystko to zależy jeszcze od momentu, w których modelowanie przeprowadzamy.
Na czym ten wsad w ogólności polega?
Jaki dostarcza programista a jaki jego klient? To bardzo ciekawe.
Czy osoby inne niż "IT Securitate" mają wystarczające przygotowanie w zakresie identyfikacji zagrożeń?
---
Nie mogę się podpisać. Boję się, że to będzie "nieetyczne".
Wsad polega głównie na dokumentacji projektu. Dokumentacja najlepiej by składała się z takich elementów jak: wymagania biznesowe, przypadki użycia, proponowana architektura aplikacja, podział na role w aplikacji, flow dla implementowanych procesów, opis wybranych technologii, proponowane zabezpieczenia. Na pierwszy rzut oka może to przerażać, ale większość z tego powstaje, tak czy inaczej - nie na potrzeby samego modelowania. Elastyczny konsultant, który prowadzi lub pomaga przy modelowaniu i widzi problemy ze zrozumieniem zagadnień, brak czasu na przygotowanie rysunków przed spotkaniami, powinien sprowokować sytuację kiedy powstaną rysunki odręczne, a później sam przeniesie je do wersji elektronicznej - w końcu za coś mu płacą :) Wszystko wyżej wymienione będzie pochodziło od takich ludzi jak: biznes (czyt. zleceniodawca), programista, administrator systemów/sieci, jeżeli jest to architekt oraz PM, którego najlepiej ubrać w gromadzenie dokumentacji i pilnowanie terminów z nią związanych.
Z jedną uwagą, to wszystko może być dość płynne. Ja zawsze staram się dopasować do środowiska, warunków jakie w nim panują. Uważam, że prawie zawsze (proszę nie łapać mnie za słowa) da się przeprowadzić modelowanie zagrożeń.
Na koniec, moim zdaniem osoby, które na co dzień nie zajmują się bezpieczeństwem, a mają trochę doświadczenia w swojej dziedzinie potrafią identyfikować zagrożenia. Przykładowo przedstawiciel biznesu wie jakie dane będą przetwarzane przez zlecaną do stworzenia aplikację i w związku z tym może wskazać zagrożenia: wyciek danych zawierających dane kartowe. Jest trochę za późno żeby się rozpisywać na ten temat, ale podobnie będzie z pozostałymi uczestnikami modelowania. Innym, b. ważnym aspektem towarzyszącym modelowaniu jest podnoszenie świadomości w każdej grupie osób zaangażowanych w tworzenie i rozwój aplikacji na temat zagrożeń oraz podatności, które mogą do nich prowadzić.
PS
Wyjątkowo zgadzam się na publikowanie anonimowych komentarzy. Przypominam, że ten blog nie jest związany z żadną konkretną firmą, może to pozwoli na podpisanie się pod kolejnym komentarzem. Nawet jeśli jest Pan/Pani z innego banku niż ja ;-)
A co jeśli zleceniodawca i zespół programistyczny przyjmą jakże popularną i czasem skuteczną metodykę analizy i projektowania przez iteracyjne prototypowanie ?
Nie chcę wdawać się w polemikę nt metodyk programistycznych, ale gdy projekty są nieduże, zespoły małe i zgrane a programiści "branżowi" - zwykle nie traci się czasu na sterty diagramów UMLowych (do których i tak mało kto zajrzy). O ile w ogóle zleceniodawca je pojmie. Co innego prototyp.
Czy warto wtedy generować to o czym Pan pisze li tylko dla modelowania zagrożeń ?
Tym bardziej gdy celem modelowania zagrożeń nie jest jak widzę bezpośrednie zaspokojenie potrzeb zleceniodawcy a jedynie ułatwienie audytu bezpieczeństwa aplikacji. (pentest to w moim uznaniu _wąskie_ pojęcie).
A gdyby modelowanie zagrożeń wraz z szacowaniem ryzyka (a w tym z kolei pentest) przeprowadzić (a potem cyklicznie odświeżać) w ramach audytu bezpieczeństwa aplikacji ?
Czy Pana zdaniem takie podejście kłóci się z ideą modelowania zagrożeń? A może ma rację bytu?
Moim skromnym zdaniem nie ma większego (nowego) problemu by zastosować modelowanie zagrożeń w przypadku projektowania przez iteracyjne prototypowanie - bez względu na przyjętą metodę. Modelowanie może mieć różną postać i powinno być dopasowane do realiów w jakich ma być przeprowadzone. Wpis pod tyłułem "Threat Modeling in The End" miał tylko wskazać jedno z możliwych podejść do tematu by podnieść jakość testów bezpieczeństwa. Nie trzymałbym się tego przykładu kurczowo, bo do niczego dobrego to nie doprowadzi. Modelowanie nie jest jednorazową czynnością, to proces.
Nie chcę przestrzelić z oceną "na oko" jak bardzo nieduży jest rodzaj projektów, które Pan wspomina, ale z mojego doświadczenia powiem, że temat zamyka się zazwyczaj na kilku (2-4) diagramach, w dodatku nie muszą być to diagramy czysto UMLowe - do modelowania przy takiej wielkości projektów tyle najczęściej wystarcza. W dodatku, co może być dla Pana jeszcze ciekawe, prototyp może być środkiem kompensującym np. brak diagramów.
Powyższym mam nadzieję odpowiedział na pytanie odnoście wartości diagramów "tylko dla modelowania zagrożeń". :)
W moim odczuciu potrzeb zleceniodawcy samo pojęcie modelowania zagrożeń może mu niewiele mówić. Jak pokazuje praktyka aktualnie jest mała świadomość z nim związana. W zależności od projektu, a właściwie wymagań biznesowych i rodzaju przetwarzanych danych zleceniodawca mniej albo więcej będzie mówił o bezpieczeństwie. Modelowanie zagrożeń "na początku", a nie "na końcu" to zorganizowany proces mogący zastąpić analizę ryzyka wykonywaną ad-hoc lub w ogóle pomijaną w procesie projektowania systemu/aplikacji. Zadaniem modelowania w moim wydaniu jest podniesienie jakości analizy ryzyka, upewnienie się, że jest świadomość przed czym się zabezpieczyliśmy, a przed czym nie lub w jakim stopniu, to szansa na uniknięcie błędów w samym projekcie, których później usuwanie jest (bardzo) trudne, a czasami niemożliwe i wiele więcej. Modelowanie może pomóc przy audycie bezpieczeństwa aplikacji, ale jest to proces, który powinien być przeprowadzany przed audytem - wtedy niesie wartość modelowania "na końcu".
Odpowiadając na kolejne pytanie: Tak, bez względu co ma Pan na myśli pisząc o audycie bezpieczeństwa aplikacji i kiedy jest on wg. Pana wizji wykonywany. Można przyjąć taką metodę modelowania i będzie ono miało swoje plusy.
Przy modelowaniu zagrożeń moim zdaniem jest jedna zasada: im później tym trudniej i wartość może być mniejsza. Są od tej zasady wyjątki, zależy od potrzeb i konkretnych przypadków. Ważne by robić to świadomie, a reszta przyjdzie dużo łatwiej.
Bardzo się cieszę z Pana komentarzy ponieważ sprowokowały one szersze wyjaśnienie mojej wizji modelowania. Niestety blog, a właściwie mój czas jaki mogę dla bloga poświęcić nie pozwala mi na większe zaangażowanie związane z rozszerzaniem tego i podobnych tematów w ramach wpisów. Jeżeli jest Pan zainteresowany tematem to zapraszam do kontaktu poza blogiem.
PS
Piszę do Pana per Pan, a nie znam właściwie płci, jeżeli mam przyjemność z Panią to z góry przepraszam i proszę o stosowną informację.
Prześlij komentarz