Te trzy słowa branża odmienia przez wszystkie przypadki, często w jednym zdaniu i najczęściej zamiennie. „Mamy ryzyko SQLi”, „to krytyczne zagrożenie”, „podatność na atak”… A przecież każde z nich znaczy co innego, i to nie jest pedanteria. Od tego, które słowo pada, zależy, CO robisz dalej i KTO to robi.
Teza jest prosta: trzy pojęcia, trzy różne pytania, trzy różne reakcje. Rozłożymy je w trzech krokach. Najpierw definicje, na jednej analogii. Potem oś czasu, na której zobaczysz, gdzie pracuje modelowanie zagrożeń. Na końcu trzy pomyłki, które ta zbitka realnie kosztuje. Zapraszamy do lektury.
Bójka w pubie
Mamy analogię w rękawie, bo tłumaczy to lepiej niż niejedna definicja. Spopularyzował ją Casey John Ellis (założyciel Bugcrowd), a my podpisujemy się pod nią obiema rękami.
Zagrożenie (ang. threat) to pijany gość w pubie, który chce Ci przyłożyć. Istnieje niezależnie od Ciebie; możesz najwyżej wiedzieć, że tam jest. I rzecz ważna: zagrożenie nie musi mieć twarzy. Bywa, że wychodzi od zagrażającego (ang. threat actor, czyli tego pijanego gościa), ale równie dobrze może istnieć samo z siebie. W pubie to śliska podłoga, na której się przewrócisz. W systemie: awaria zasilania, pożar serwerowni, zwykły błąd człowieka. Nie za każdym zagrożeniem stoi napastnik.
Podatność (ang. vulnerability) to Twoja szklana szczęka albo to, że stoisz akurat w zasięgu jego ręki. Leży po TWOJEJ stronie, więc masz na nią wpływ. I tu niuans dla dociekliwych: podatność to nie to samo co słabość (ang. weakness). Podatność jest konkretną instancją słabości. „Szklana szczęka” jako cecha, którą miewają ludzie, to słabość, czyli cała klasa problemu. To, że akurat TY z taką szczęką stoisz dziś w TYM pubie w zasięgu ręki, to już podatność, czyli konkretny przypadek. Programista rozpozna dokładnie tę parę: CWE (ang. Common Weakness Enumeration) kataloguje słabości, a CVE (ang. Common Vulnerabilities and Exposures) konkretne podatności.
Ryzyko (ang. risk) to realna szansa, że oberwiesz, przez którą próbujesz wyrazić jak bardzo Cię to zaboli. I właśnie „jak bardzo zaboli” jest tu sednem. Wyobraź sobie, że zamachuje się na Ciebie Twój dwulatek: zagrożenie jest (chce uderzyć), podatność jest (nie zdążysz się uchylić), a ryzyko i tak jest znikome. Siła to masa razy przyspieszenie; jeśli cios nie robi krzywdy, ryzyko jest niskie, choćby zagrożenie i podatność były realne.
| Pojęcie | Co to jest | Czyje jest | Co z tym robisz |
|---|---|---|---|
| Zagrożenie | to, co może zaszkodzić (napastnik albo żywioł) | cudze, zewnętrzne | unikasz, przeciwdziałasz |
| Podatność | konkretna słabość, którą da się wykorzystać | Twoje, wewnętrzne | usuwasz, łatasz |
| Ryzyko | szansa razy skutek, w danym kontekście | wypadkowa obu | akceptujesz, mitygujesz albo transferujesz |
Na zagrożenie nie masz wpływu, bo jest na zewnątrz; na podatność masz, bo jest Twoja; ryzyko to wypadkowa obu, osadzona w kontekście i mierząca, jak bardzo zaboli, jeśli się zmaterializuje.
To jednak dopiero wstęp do tematu ryzyka, fascynującego, bo z jednej strony znajomego każdemu, a z drugiej trudnego do prostego, spójnego ujęcia. Zainteresowanych głębią odsyłamy do metodyki FAIR (ang. Factor Analysis of Information Risk).
Oś czasu: gdzie na niej pracuje modelowanie zagrożeń
Po co komu ta precyzja w praktyce? Ponieważ każde z trzech pojęć żyje w innym momencie, a modelowanie zagrożeń celuje w bardzo konkretny punkt tej osi.
Kiedy modelujesz „w przód”, na etapie projektu, podatności jeszcze nie ma: nie ma kodu ani serwera, w którym mogłaby zamieszkać. Jest za to zagrożenie, bo zagrożeniem jest samo WPROWADZENIE konkretnej podatności. Dlatego modelowanie szuka zagrożeń, a pentest znajduje podatności (rozkładamy to przy modelowaniu kontra pentest).
Skoro na tym etapie nie ma jeszcze podatności ani ekspozycji, nie ma też z czego policzyć ryzyka. Dlatego zagrożeniom nadaje się nie ryzyko, lecz krytyczność. I tu od razu prostujemy sprawę: krytyczność też nie jest celem samym w sobie. Chodzi o PRIORYTET, czyli o to, czym zająć się najpierw; krytyczność jedynie pomaga go ustalić.
Modelowanie zagrożeń pracuje na lewym końcu osi: tam, gdzie podatność da się jeszcze UNIEMOŻLIWIĆ, a nie tylko załatać.
Trzy pomyłki, które ta zbitka kosztuje
Każda z pomyłek ma swój koszt. Trzy wracają najczęściej.
„Ryzyko SQLi” bez kontekstu. Ta sama podatność ma różne ryzyko w zależności od tego, gdzie siedzi. SQLi w panelu publicznej aplikacji webowej to inne ryzyko niż identyczna SQLi w panelu wewnętrznym, z którego korzystają trzy zaufane osoby w organizacji. Krytyczność jest w obu przypadkach taka sama, ryzyko już nie. A kto myli te słowa, ten nie umie porównać zagrożeń między sobą.
Zagrożenie mylone z podatnością. Zespół, który traktuje je jak jedno, czeka z reakcją, „aż coś się pojawi”, czyli aż zagrożenie zamieni się w podatność w gotowym systemie. A wtedy jest już drogo, i cała przewaga proaktywnego działania znika.
„Zarządzamy zagrożeniami” tam, gdzie trzeba łatać podatności. Albo odwrotnie. To prosta droga do dobrania złego narzędzia do złej roboty: zagrożeniom zapobiegasz projektem, podatności wyłapujesz skanem i łatką, a o ryzyku decydujesz świadomie. Pomylenie pojęć to pomylenie narzędzi.
Słowo wskazuje właściciela: inżynier łata podatność, zespół przeciwdziała zagrożeniom, a ryzykiem zarządza biznes.
Co robić, jak żyć?
Cztery praktyczne nawyki:
- Nazywaj rzeczy precyzyjnie. Pomaga prosty szablon zdania: „zagrożenie X, wykorzystujące potencjalną podatność Y, o krytyczności Z”. W dokumentacji trzymaj się tej precyzji obowiązkowo. Na żywej sesji, jeśli przychodzi z trudem, nie rób z niej blokera: ważniejsze, żeby rozmowa się toczyła, a słownik poprawisz w zapisie.
- Na sesji nie licz ryzyka. Nadaj zagrożeniu krytyczność i idź dalej.
- Dobierz narzędzie do pojęcia. Zagrożeniom zapobiegaj na etapie projektu (sesja krok po kroku), podatności wyłapuj testami i łataj (modelowanie a pentest), a o ryzyku decyduj razem z biznesem.
- Naucz zespół tej triady na analogii. Bójka w pubie wchodzi w pięć minut i zostaje na lata.
Precyzja w tych trzech słowach to nie semantyczny luksus, tylko najtańszy sposób, żeby każdy w zespole wiedział, na co ma zareagować i czym. Ta sama zasada dotyczy innej mylonej trójki: procesu, sesji i modelu.
Damy Ci znać, gdy opublikujemy coś nowego.
Artykuł albo odcinek podcastu. Bez spamu. W każdej chwili możesz się wypisać.
Zapisując się, akceptujesz politykę prywatności.
Referencje i wzmianki: Casey John Ellis (analogia bójki w pubie; Bugcrowd); NIST Glossary (weakness / vulnerability); FAIR / Open FAIR (metodyka analizy ryzyka); Threat Modeling Manifesto; OWASP (terminologia); Adam Shostack.