Paweł Goleń, blog

Na początek cytat ze starego wpisu na blogu Microsoft Application Threat Modeling Blog:

Threats are realized through attacks which can materialize through certain vulnerabilities if they have not been mitigated with appropriate countermeasures.

Drugi cytat z wpisu Threat Modeling summary z innego bloga:

Attacker - Someone who could do harm to a system
Threat - An attacker goal
Vulnerability - A flaw in the system that could help an attacker realize a threat
Mitigation - Something to do to protect against a threat.
Attack - The process in which attackers takes advantage of a vulnerability
Asset - Something of value to valid users vendors and attackers

Dla mnie taka terminologia jest sensowna. Łatwo mi jest postrzegać zagrożenie jako cel intruza, który to cel intruz osiąga poprzez atak wykorzystujący podatność. Staram się tych definicji trzymać w miarę konsekwentnie, przy czym zdaję sobie sprawę, że istnieją ludzie, którzy uznają, że są one błędne. I będą mieli "jakieś wsparcie". Problem dotyczy przede wszystkim pojęcia zagrożenia (threat).

Przykład? Proszę bardzo, za książką: Certified Information Systems Security Professional Study Guide zagrożenie (threat) to (można sobie przeczytać stosowny fragment książki):

Threats - Any potential occurrence that may cause an undesirable or unwanted outcome for an organization or for a specific asset is a threat. Threats are any action or inaction that could cause damage, destruction, alteration, loss, or disclosure of assets or that could block access to or prevent maintenance of assets. (...)

Polecam też schemat na następnej stronie wspomnianej książki.

Mam nadzieję, że w tej chwili już się zgubiliście. Warto jednak zwrócić uwagę, że przykłady definicji tych pojęć, zwłaszcza pojęcia zagrożenia pochodzą z nieco różnych obszarów jakimi są threat modeling oraz risk management (by jeszcze bardziej zagmatwać, jeszcze jedna definicja pojęcia zagrożenia występująca w kontekście threat modeling oraz wpis Threat Modeling Terms and How To Use Them). Z tego powodu gdy muszę używać tych pojęć, staram się najpierw powiedzieć co pod tymi pojęciami rozumiem (przypomina mi to trochę czasy, z których zostało mi tylko i gdzie do oznaczenia niewiadomych w równaniach zamiast pospolitych x, y czy z używaliśmy ó albo innych, równie niestandardowych symboli).

A teraz przypisanie przykładów do pojęć:

• Zagrożenie - przejęcie sesji użytkownika,
• Podatność - brak encodingu danych wyjściowych, brak walidacji danych wejściowych,
• Atak - XSS

Tak, Cross-Site Scripting można (należy?) określić jako atak, a nie jako podatność. Tym razem ja mam pewne wsparcie w postaci OWASP Category:Attack, do której to kategorii zostało zaliczone Cross-Site Scripting, natomiast do podatności (Category:Vulnerability) zostały zaliczone brak walidacji oraz brak encodingu.

To teraz by świat nie był taki poukładany nieco inne podejście, tym razem za wikipedią Cross-Site Scripting staje się podatnością (... a type of computer security vulnerability typically found in web applications ...) Takie podejście też nie jest pozbawione sensu, bo choć do wystąpienia XSS brak walidacji i brak encodingu jest potrzebny, to nie jest to warunek wystarczający (rozważania na temat tego, czy brak encodingu oraz brak walidacji są warunkami koniecznymi sobie litościwie odpuszczę)... W takim przypadku za atak można uznać konkretny payload, być może wraz z całym scenariuszem wykorzystania.

Nie, to jeszcze nie koniec. Mogę jeszcze trochę zagmatwać :)

• Zagrożenie - wykonanie operacji w kontekście innego użytkownika,
• Podatność - możliwość przejęcia sesji użytkownika,
• Atak - XSS,

Dlaczego tak? Bo w końcu do czego potrzebna jest intruzowi sesja, do zapisania sobie jej identyfikatora w grubym zeszycie zatytułowanym Sesje, które przejąłem? A może jest to tylko krok prowadzący do prawdziwego celu? Tylko czy podatnością jest przejęcie sesji użytkownika czy raczej brak walidacji oraz brak encodingu prowadzące do podatności na atak XSS oraz brak zabezpieczenia cookie sesyjnego przez flagę httpOnly?

Z perspektywy (pen)testera zgłosiłbym prawdopodobnie:

• brak walidacji,
• brak encodingu,
• XSS (jako wynik poprzednich dwóch podatności),
• brak flagi httpOnly,

Patrząc z kolei od strony zabezpieczania aplikacji prawdopodobnie wyszedłbym od zabezpieczenia sesji przed przejęciem, co skutkowałoby (co najmniej) następującymi zaleceniami:

• oznaczenie cookie flagami Secure (jeśli jest HTTPS) oraz httpOnly,
• odpowiednie ustawienie ścieżki oraz domeny dla cookie,
• zmienianie cookie po uwierzytelnieniu,
• użycie mechanizmu sesji wbudowanego w framework,

Walidacja danych wejściowych oraz encoding danych wyjściowych z kolei byłyby generalnym zaleceniem/wymaganiem, które ma znaczenie praktycznie dla tak wielu aspektów aplikacji, że "trzeba je wyciągnąć przed nawias".

Mógłbym też myśleć o wykonaniu operacji w aplikacji (w kontekście innego użytkownika), co mogłoby mnie prowadzić do mniej więcej takich wniosków (tak, wiem, że jest to podobne do attack trees):

Mniej więcej, bo można do tej listy dodać więcej elementów, by nie szukać daleko - clickjacking. Do tego przykładu jeszcze wrócę, ale teraz proponuję chwilę pomyśleć nad tym co jest celem intruza, co podatnością, a co atakiem. Gdy już się dojdzie do zgody (z samym sobą) warto sobie uświadomić, że tak naprawdę potrzebne jest określenie środków zaradczych (countermeasures).

Podsumowując - kwestia nomenklatury wcale nie jest taka prosta, mam z nią spory problem, pociesza mnie to, że nie tylko ja. W tym temacie warto również przeczytać ten wpis: Threat Model vs Attack Model. Prawdopodobnie rzeczywiście powodem części zamieszania jest dość luźne używanie przez Microsoft pojęcia zagrożenia (threat) w kontekście, w którym lepszym pojęciem byłby cel ataku/atakującego. Z drugiej strony pojęcie zagrożenia pojawia się często w kontekście właściwym dla podatności lub ataku (patrz: Allegro: przerwa konserwacyjna) co mnie osobiście bardziej kopie, niż utożsamianie zagrożeń z celami intruza. Chętnie przestawię się na właściwą terminologię, ale niech ona poza niewątpliwą (?) zaletą bycia właściwą (zgodną z uświęconymi przez normy definicjami pojęć), będzie jeszcze używalna, czyli zrozumiała dla typowego odbiorcy.

Akcent humorystyczny - kiedy ostatni raz słyszeliście słowo komprymacja? Najlepiej w połączeniu z rozdymaniem :)