W październiku opublikowałem pierwszą część z serii opisującej sposoby oceny bezpieczeństwa w cyberbezpieczeństwie. Opisałem w niej spojrzenie wysokopoziomowe oraz przedstawiłem analogię ogrodzenia przydatną szczególnie dla osób mniej technicznych. Jeżeli jeszcze nie miałeś okazji zapoznać się z częścią pierwszą, to polecam zrobić to przed lekturą dzisiejszego postu.

Teraz wracam do tematu z częścią drugą opisującą różnice i podobieństwa pomiędzy oceną podatności a testem penetracyjnym. Z mojego doświadczenia wynika, że to właśnie te dwa rodzaje oceny bezpieczeństwa wywołują największy problem z jednakowym zrozumieniem zarówno po stronie dostawców jak i klientów (analogicznie po stronie działów bezpieczeństwa i interesariuszy). Efektywne działanie wymaga jednakowego i obustronnego zrozumienia, tak więc zaczynajmy! 👉

Właściwości modelu

Od publikacji ostatniego posta minęło trochę czasu, a więc przypomnę, że za główne cechy różnicujące sposoby oceny bezpieczeństwa przyjmuję:

  • Cel. Co chcemy osiągnąć?
  • Zakres. Co bierzemy pod uwagę?
  • Czas. Ile mamy czasu?
  • Rozmiar zespołu. Ilu ludzi musimy zaangażować aby osiągnąć zadowalający ROI?
  • Możliwość automatyzacji. W jakim stopniu jesteśmy w stanie zautomatyzować prace?

Przechodząc kolejno przez każdą z powyższych właściwości różnice i podobieństwa pomiędzy rodzajami ocen powinny się wyklarować.

Ocena podatności (vulnerability assessment)

Celem oceny podatności danego środowiska (aplikacji, systemu, czy sieci) jest znalezienie jak największej ilości podatności (w tym defektów w zaimplementowanych kontrolkach bezpieczeństwa). Idziemy w szerokość i nie interesują nas łańcuchy ataków tylko podatności same w sobie. Podejmowanie prób eksploitacji, tworzenia łańcuchów ataków, czy eskalacji jest zbędne i może być niemile widziane — czas prac jest skończony, a więc próby eksploitacji są podejmowane kosztem znalezienia większej ilości podatności. Przykładowo mając podatność typu SQL Injection w aplikacji i wykonując ocenę podatności wystarczy najprostszy Proof-of-Concept pokazujący, że payload jest wykonywany (np. użycie funkcji SLEEP()). Dalsza eksploitacja jest zbędna (np. próba dumpowania bazy danych).

Celem pobocznym oceny podatności jest powtarzalność przez co proces zorientowany jest na listę/standard co ułatwia mierzenie zmian jakości w czasie (np. OWASP Application Security Verification Standard).

Wyprowadzanie podatności nie jest konieczne i zależy od (1) krytyczności podatności, (2) krytyczności aplikacji/systemu, i (3) ogólnego profilu ryzyka organizacji. Poprawienie problemu jest lepsze niż sama wiedza o problemie, a sama wiedza o problemie jest lepsza niż niewiedza.

Zakres jest wąski i dla pojedynczego projektu ogranicza się do konkretnej aplikacji czy systemu, ale ocena podatności może być używana“od ogółu do szczegółu”. Przykładowo można poddać ocenie najpierw cały system, następnie każdą aplikację wchodzącą w skład systemu, kończąc na pojedynczych modułach (np. ocena podatności biblioteki używanej w aplikacji). Trudno sobie wyobrazić test penetracyjny stu linijkowego kawałka JavaScript-u wykorzystywanego w aplikacji jako moduł zaciągany via npm, ale ocenę podatności tego samego kawałka kodu można (i powinno się!) przeprowadzić.

W środowisku produkcyjnym często można spotkać dodatkowe mechanizmy obronne (np. instancję WAF-a), które utrudniają testowanie bezpieczeństwa. W ocenie podatności tego typu narzędzia powinny być wyłączone ponieważ interesują nas podatności w naszej aplikacji/systemie, a nie w przykładowym WAF-ie. Stąd też wynika możliwość testowania w środowisku nieprodukcyjnym (np. w środowisku testowym).

Nietrudno wyobrazić sobie sytuację, w której ocena podatności aplikacji w środowisku z włączonym WAF-em nie wykazała żadnych podatności. Następnie nastąpiła migracja aplikacji do innego środowiska z inną konfiguracją WAF-a i aplikacja nagle okazała się podatna. W takim wypadku testowany był WAF, a nie sama aplikacja. Wykonując ocenę podatności taka sytuacja nie powinna mieć miejsca (co innego w testach penetracyjnych czy red teamingu).

Czas trwania jednej iteracji liczony jest najczęściej w tygodniach (od jednego do kilku), a co za tym idzie efekt pracy odzwierciedla wąski kawałek w czasie. Ma to znaczenie dla aplikacji tworzonych w metodologiach zwinnych, gdzie na początku większy ROI może przynieść implementacja wybranych składowych Secure SDL czy DevSecOps.

Prace wykonywane są najczęściej w małych zespołach (1-3 osoby). Warto uwypuklić, że pojedyncza osoba jest w stanie przeprowadzić ocenę podatności na zadowalającym poziomie (w wyniki testu penetracyjnego przeprowadzonego przez pojedynczą osobę bym powątpiewał — z doświadczenia wiem, że różne spojrzenia są krytyczne dla powodzenia).

Sporo aspektów pracy można automatyzować wykonując skany podatności (vulnerability scans) zarówno dla aplikacji jak i infrastruktury. W przypadku aplikacji skany podatności można realizować poprzez narzędzia klasy Software Composition Analysis (SCA), Variant Analysis (VA), Static Analysis (SAST), Dynamic Analysis (DAST), czy Interactive Analysis (IAST). Natomiast w przypadku infrastruktury można wykorzystać skanery podatności takie jak Nessus, Rapid7, czy OpenVAS.

Na odpowiednio wysokim poziomie abstrakcji skan podatności infrastruktury wykonany Nessusem jest tym samym czym skan podatności wykonany narzędziem SAST na kodzie źródłowym aplikacji. W obu przypadkach wykorzystujemy listę znanych podatności (w tym klas podatności) i sprawdzamy ją (1) serwer po serwerze (Nessus na infrastrukturze) albo (2) linia po linii (SAST na aplikacji).

Procesy takie jak Secure SDL (MSSDL, SAMM, BSIMM) czy DevSecOps starają się automatyzować jak największą ilość aspektów związanych z oceną podatności już na etapie wytwarzania oprogramowania (tzw. “shift-left security” odnoszące się do miejsca pierwszego kontaktu aplikacji z bezpieczeństwem w procesie wytwórczym).

Ważnym punktem przy omawianiu oceny podatności jest to, że wiele osób (szczególnie od strony wykonawców) utożsamia ocenę podatności ze skanem podatności. Jest to błędne spojrzenie na rzeczywistość wynikające z braku zrozumienia pojęcia “ocena podatności”, które jest dużo szersze niż pojęcie “skan podatności”. Każdy skan podatności jest oceną podatności, ale nie każda ocena podatności jest skanem podatności.

TL;DR: Tabelka podsumowująca cechy oceny podatności:

Test penetracyjny (penetration test)

Celem testu penetracyjnego danego środowiska (aplikacji, systemu, sieci) jest obejście mechanizmów bezpieczeństwa i “wejście” do środowiska (często poprzez łączenie różnych podatności w łańcuchy ataków dające większe możliwości niż każda podatność sama w sobie). Idziemy w głębokość nie szerokość, a więc nie interesują nas podatności same w sobie tylko co-i-jak możemy dzięki nim uzyskać. Próby eksploitacji, tworzenia łańcuchów ataków, czy eskalacji w obrębie systemu są głównymi czynnościami w testach penetracyjnych. Przykładowo mając podatność CMD Injection w aplikacji powinna zostać podjęta próba eksploitacji oraz eskalacji w obrębie systemu operacyjnego (np. uzyskanie dostępu do powłoki systemowej via bind/reverse shell, a następnie podwyższenie uprawnień w obrębie OS-a dzięki podatnościom w konfiguracji, oprogramowaniu, czy nawet samym kernelu).

Testy penetracyjne mogą posiadać ustalony odgórnie cel (np. kradzież PII z bazy danych) i w takim wypadku sukces pentestu zależy od osiągnięcia celu.

Główną wartością dostarczaną przez testy penetracyjne jest miara bezpieczeństwa systemu oraz obecnych w nim mechanizmów bezpieczeństwa zwalidowana poprzez aktywne próby ataku. Przedwczesne wykonywanie testów penetracyjnych (tj. bez uprzednich iteracji oceny podatności) przynosi niski ROI.

🔗 twitter.com/_JoeSullivan/status/1149121190570668033

Istnieją standardy wykonywania pentestów (np. Penetration Testing Execution Standard), ale od strony technicznej testy penetracyjne wymagają kreatywności, a co za tym idzie wachlarz umiejętności i doświadczenie zespołu pentesterskiego mają krytyczny wpływ na powodzenie. Dwa różne zespoły pentesterskie nigdy nie wykonają identycznego testu penetracyjnego, dlatego występuje brak powtarzalności.

Zakres jest szeroki, ale ograniczony do technologii i bazuje na białej-liście (klient dostarcza listę zasobów wchodzących w zakres). Testów penetracyjnych nie można wykonywać w oderwaniu od innych części systemu ponieważ z założenia mają one za zadanie ujawnienie słabości systemu jako całości, tj. podatności w samych komponentach jak i podatności wynikających z interakcji pomiędzy komponentami.

Testy penetracyjne powinny zostać wykonane albo w środowisku produkcyjnym albo w kopii 1:1 środowiska produkcyjnego. Sytuacja, w której środowisko aplikacji ma znaczący wpływ na zaistnienie lub krytyczność danej podatności jest jak najbardziej możliwa. Pierwszym z brzegu przykładem może być jakakolwiek web aplikacja z podatnością SSRF osadzona w środowisku AWS. W takim przypadku to właśnie środowisko aplikacji ma znaczący wpływ na możliwości dalszej eksploitacji, a co za tym idzie krytyczność podatności.

Testy penetracyjne, w przeciwieństwie do oceny podatności, mogą i powinny być wykonywane z włączonymi wszystkimi docelowymi mechanizmami obronnymi (np. aktywna instancja WAF-a). W pentestach często ma miejsce znajdowanie podatności typu 0-day w oprogramowaniu stron trzecich.

Czas trwania testu penetracyjnego liczony jest najczęściej w tygodniach (od jednego do kilku) i odzwierciedla wąski kawałek w czasie.

Prace wykonywane są najczęściej w małych zespołach (2-4 osoby). Testy penetracyjne wymagają działania zespołowego ponieważ różne spojrzenia są krytyczne dla powodzenia, a pojedyncza osoba ma ograniczoną ilość tematów w których może być SME. Oczywiście nie wszyscy muszą uczestniczyć w projekcie w pełnym wymiarze czasu.

Na większości etapów prac istnieje możliwość automatyzacji, ale nie jest to automatyzacja pełna. Każdy aspekt wymaga manualnej oceny i wyboru przez operatora odpowiedniego narzędzia. Nie można (i nigdy nie będzie można) kupić i puścić automatu, który sam wykona nam test penetracyjny.

Testy penetracyjne znajdują się w ostatnich fazach cyklu wytwórczego (np. faza Release w MSSDL). To ocena podatności, a nie testy penetracyjne, jest głównym narzędziem służącym do budowania bezpieczeństwa w procesach takich jak Secure SDL (MSSDL, SAMM, BSIMM) czy DevSecOps.

Niestety zdarzają się sytuacje gdzie klient oczekuje wyników zbliżonych do mieszanki oceny podatności i testu penetracyjnego chcąc jednocześnie otrzymać (1) jak najwięcej podatności i (2) przykładowe łancuchy ataków wraz z eskalacją. Są też oczywiście sytuacje odwrotne, w których klient faktycznie chce usługę testu penetracyjnego, a otrzymuje wyniki oceny podatności (lub jeszcze gorzej: skanu podatności). Ogólny stan w jakim jesteśmy dobrze oddaje poniższy twitt i jak widać nie jest to problem ani nowy ani lokalny dla Polski:

🔗 twitter.com/HockeyInJune/status/1062007169518891008

TL;DR: Tabelka podsumowująca cechy testu penetracyjnego:

Kwestia ryzyka

Dodatkowym elementem zarówno oceny podatności jak i testów penetracyjnych jest ocena krytyczności (severity) związana z każdym zidentyfikowanym problemem co pozwala na zarządzanie ryzykiem. Bardzo ważne jest to, że wykonawca nie jest w stanie ocenić ryzyka, a jedynie oszacować stopień krytyczności od strony technicznej danej podatności czy łańcucha ataku. Do tematu wrócę w przyszłości (aktualnie rozpisany jest w części 5).

Podsumowanie

Ocena podatności i testy penetracyjne mają wiele punktów wspólnych od strony taktyk, technik, i procedur. Różnice pomiędzy oceną podatności a pentestami wynikają ze spojrzenia wysokopoziomowego na cel, zakres, czas, rozmiar zespołu, czy możliwość automatyzacji — a nie konkretnych czynności operacyjnych.

Podstawowym sposobem oceny bezpieczeństwa aplikacji, systemu, czy sieci jest właśnie ocena podatności, a nie test penetracyjny. Przedwczesne testy penetracyjne przynoszą niezadowolający ROI ponieważ bez wcześniejszych iteracji oceny podatności, pentesty na pewno zakończą się sukcesem i zamiast otrzymać szeroką listę problemów bezpieczeństwa możemy skończyć z 1-2 łancuchami ataków, których wyprowadzenie będzie miało mały wpływ na ogólną posturę organizacji.

Mam nadzieję, że dzisiejszy post pomoże Ci w wyborze odpowiedniego rodzaju oceny bezpieczeństwa. W kolejnej części opiszę Red Teaming (dużo podobieństw z pentestami) oraz Bug Bounty (mix wszystkiego), a jej wypuszczenie planuję na drugą połowę marca. Do następnego! 👋

Referencje