Paweł Goleń, blog

Na wspomnianych diagramach wyróżnić można kilka podstawowych elementów:

• Data store,
• Data flow,
• Interactor,
• Process,

Każdemu z tych elementów można przyporządkować zagrożenia pewnego typu. Tu właśnie pojawia się STRIDE:

• Spoofing,
• Tampering,
• Repudiation,
• Information disclosure,
• Denial of Service,
• Elevation of privilege,

Oczywiście można mieć zastrzeżenia do takiej klasyfikacji zagrożeń, nie jest ona doskonała, ale jest. Przyporządkowanie kategorii zagrożeń do poszczególnych elementów diagramów DFD wygląda w sposób następujący:

• Data store: Tampering, Repudiation, Information disclosure, Denial of Service,
• Data flow: Tampering, Information dislcosure, Denial of Service,
• Interactor: Spoofing, Repudiation,
• Process: Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, Elevation of priviledge,

EDIT: dodałem repudiation dla data store by informacje tu zawarte były zgodne z tym, co jest stosowane w Microsoft SDL Threat Modeling Tool. Istnieją różne wersje powyższej matrycy, niektóre uwzględniają jeszcze repudiation dla data flow.

Każdej grupie zagrożeń można przyporządkować security property, której dotyczy (lub odwrotnie, nie jest to istotne):

• Spoofing: Authentication (uwierzytelnienie),
• Tampering: Integrity (integralność),
• Repudiation: Non-repudiation (niezaprzeczalność),
• Information disclosure: Confidentiality (poufność),
• Denial of Service: Availability (dostępność),
• Elevation of privilege: Authorization (autoryzacja),

Jak w praktyce wykorzystać diagramy DFD? Na początek przypomnienie jednego z diagramów:

Można na nim wyróżnić następujące elementy:

• Aktorzy: Klient, WebService,
• Procesy: Aplikacja, Import,
• "Składnice" danych: System plików, baza danych,
• Przepływy danych:
  • Klient - Aplikacja,
  • Aplikacja - Klient,
  • System plików - Aplikacja,
  • Aplikacja - Baza danych,
  • Baza danych - Aplikacja,
  • WebService - Import,
  • Import - Baza danych,

Dodatkowo mamy zaznaczone dwie granice trust boundary.

Zarówno Klient jak i WebService znajdują się poza trust boundary. Z racji typu tych obiektów należy uwzględnić spoofing oraz repudiation. Domyślnie należy uznać, że zagrożenia tego typu istnieją, no chyba, że uwodnione zostanie, że jest inaczej. Do tego jednak potrzebna jest coś więcej, niż diagram DFD - potrzebna jest znajomość aplikacji. W tym przypadku niech to będzie aplikacja przeznaczona dla kierowców, na której mogą sprawdzić ceny paliw w swoich okolicach. Dostęp do aplikacji jest anonimowy, nie są zakładane żadne konta, użytkownik podaje swoją pozycję i otrzymuje informację o najbliższych stacjach i cenach paliw na nich. Informacja na temat stacji i cen paliw jest okresowo uaktualniana poprzez proces importu danych za pośrednictwem usługi WebService.

W takim przypadku dla klienta trudno mówić o możliwości podszycia się pod innego użytkownika, skoro użytkowników nie ma. Podobnie w przypadku (nie)zaprzeczalności. Informacja czy ktoś (przypominam - jest to anonimowe) skorzystał z tej usługi nie jest specjalnie istotna. Nie oznacza to, że nie trzeba prowadzić logów (choćby serwera HTTP czy serwera aplikacyjnego), oznacza to jednak, że działania klienta w aplikacji nie muszą być w pełni rozliczalne.

Usługa WebService dostarcza informacji o stacjach i cenach paliw. Czy (nie)zaprzeczalność jest tutaj istotna? To zależy, jeśli serwis pełni rolę wyłącznie informacyjną i nie daje żadnych gwarancji dla swoich użytkowników, to podanie nie do końca prawdziwych informacji nie jest istotne. Jeśli jednak klienci oczekują rzetelnych, sprawdzonych informacji wówczas możliwość udowodnienia, że takie a nie inne informacje zostały otrzymane z WebService może być istotne. Podobnie w przypadku ewentualnego podszywania się pod usługę. Jeśli źródło danych ma być zaufane a podanie nieprawdziwych informacji może przynieść komuś (konkurencji?) zysk, warto uwzględnić zagrożenie spoofingiem.

Co z data store? W tym przypadku są dwa: system plików oraz baza danych, dla nich należy zastanowić się nad modyfikacją danych (tampering), ujawnieniem danych (information disclosure) oraz odmową usługi (denial of service). Przy tej analizie należy uwzględnić fakt, że zarówno system plików jak i baza danych znajdują się w "zaufanym środowisku" i dostęp do nich jest ograniczony (cokolwiek by to w tym wypadku nie znaczyło). Może okazać się więc, że jedynym wartym uwzględnienia zagrożeniem jest odmowa usługi, a właściwie nawet bardziej dostępność, co może już bardziej nadawać się na rozważania dotyczące ciągłości działania i odzyskiwania po awarii, niż tematu bezpieczeństwa i modelowania zagrożeń.

W analogiczny sposób należy postąpić dla procesów i przepływów danych. W przypadku przepływów danych należy zwrócić szczególną uwagę na te, które przekraczają trust boundary. Aby atakujący mógł skutecznie zaatakować aplikacje, musi mieć możliwość interakcji z nią. W przypadku tej przykładowej aplikacji ma tylko dwie możliwości takiej interakcji.

Nie w każdym przypadku wystarczą diagramy DFD na tak dużym poziomie abstrakcji. Może okazać się, że do dekompozycji aplikacji potrzebnych jest wiele diagramów, które reprezentują na przykład każdy przypadek użycia. Ogólna zasada postępowania nie ulega jednak w takich przypadkach zmianie.