SecOps Online MeetUp #5

Jeszcze w sierpniu wziąłem udział w wydarzeniu SecOps Online MeetUp #5, gdzie standardowo opowiedziałem co nieco o bezpieczeństwie aplikacji, DevSecOps oraz automatyzacji.

Poruszyłem również kwestię narzędzi, które można zapuścić na własne aplikacje żeby zobaczyć co w trawie piszczy.

Kilka dni temu dostałem link do nagrania na YouTube. Polecam. ✌️

BTW. Jako uzupełnienie zachęcam do ściągnięcia mojego darmowego e-booka DevSecOps: Podstawy Automatyzacji Bezpieczeństwa

Sposoby oceny bezpieczeństwa w cyberbezpieczeństwie, część 2

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

Sposoby oceny bezpieczeństwa w cyberbezpieczeństwie, część 1

W trakcie codziennej pracy na lokalnym rynku stykam się z brakiem jednolitego zrozumienia tego czym jest ocena bezpieczeństwa oraz mieszaniem jej różnych rodzajów takich jak ocena podatności czy test penetracyjny.

Ponadto opis usług oferowanych przez dostawców często niepokrywa się z konkurencją ani tym jak rozumieją go sami zamawiający. W efekcie końcowym mają miejsce sytuacje, w których klient zamawia usługę X i dostaje efekt usługi Y. Co więcej, zamawiając po czasie od innego dostawcy “tę samą” usługę X otrzymuje zamierzony efekt usługi X, ale w tym momencie nie jest w stanie porównać stanu obecnego ze stanem przeszłym. W celu uproszczenia pominę jakość samych usług.

Całość prowadzi do nieprzyjemnych sytuacji dla obu stron, a w gruncie rzeczy sprawa jest prosta do rozwiązania — wystarczy przyjąć pewne ogólne definicje, a następnie przeprowadzić klienta odpowiednią dla niego ścieżką (czyli taką, która spełni jego faktyczne zapotrzebowanie).

Plan akcji

W niniejszej serii postów sklasyfikuję oraz wyjaśnię różnice i podobieństwa pomiędzy standardowymi sposobami oceny bezpieczeństwa stosowanymi w cyberbezpieczeństwie. Moim celem jest polepszenie zrozumienia tego tematu dla obu stron.

W tym tygodniu przedstawię spojrzenie wysokopoziomowe, a w kolejnych tygodniach będę analizował i omawiał każdy rodzaj z osobna. Temat jest szeroki więc poruszę również wątki poboczne takie jak różnice pomiędzy podejściem black-box i white-box czy rosnący na popularności temat bug bounty. Zapraszam!

Spojrzenie wysokopoziomowe

Z lotu ptaka standardowe sposoby oceny bezpieczeństwa w cyber można podzielić następująco:

  • Modelowanie zagrożeń (threat modeling)
  • Audyt bezpieczeństwa (security audit)
  • Ocena podatności (vulnerability assessment)
  • Test penetracyjny (penetration test)
  • Red team

Kolejność nie jest przypadkowa. Poniżej przedstawiam podział w formie diagramu, który można potraktować jako gradient (od lewej do prawej) gdzie każdy kolejny rodzaj jest progresją względem poprzedniego, stopniowo prowadząc do podniesienia bezpieczeństwa aplikacji, systemu, czy organizacji.

Sposoby oceny bezpieczeństwa w cyber

Głównymi cechami różnicującymi w moim modelu są:

  • 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?

Powyższe właściwości pozwalają w jasny sposób skontrastować rodzaje ocen bezpieczeństwa i jednocześnie prezentują proste do zapamiętania pytania, które można wykorzystać przy wyborze odpowiedniego dla siebie typu oceny. Nota bene: To jak wybierać odpowiedni dla swojego przypadku rodzaj oceny bezpieczeństwa opiszę w osobnym artykule.

W celu ułatwienia zrozumienia mojego modelu stworzyłem analogię ogrodzenia, w której:

  • Modelowanie zagrożeń możemy wykonać jeszcze przed budową płotu po to aby zdać sobie sprawę z zagrożeń jakie powinniśmy brać pod uwagę (pomoże nam to w budowie bezpieczniejszego ogrodzenia).
  • Audyt bezpieczeństwa wykonujemy po wybudowaniu płotu w momencie gdy chcemy sprawdzić czy nasze ogrodzenie spełnia normę czy standard (np. ISO 7900:2006).
  • Ocenę podatności wykonujemy po wybudowaniu płotu gdy chcemy odkryć jak największą ilość problemów bezpieczeństwa w naszym ogrodzeniu, ale bez wchodzenia w szczegóły tego czy (i jak) można je wykorzystać (np. dziura w płocie lub mała wysokość ogrodzenia względem terenu).
  • Zarówno test penetracyjny jak i red team powinny zostać wykonane po co najmniej kilku iteracjach oceny podatności po to aby wyeliminować tzw. low-hanging fruits. W obu tych rodzajach chcemy emulować realnego atakującego aby poznać łańcuchy ataków, czyli zobaczyć w jaki sposób można połączyć różne problemy bezpieczeństwa naszego ogrodzenia i elementów dodatkowych w celu uzyskania pożądanego efektu (przykładowy łańcuch ataku: wtargnięcie na teren poprzez pokonanie słabo wykonanego ogrodzenia, pozostanie niezauważonym dzięki udanemu atakowi Denial-of-Service na kamery wpięte do Internetu, i ostatecznie wykradnięcie materiału z magazynu).

Podsumowanie

W dzisiejszym poście poznaliśmy wysokopoziomowy podział standardowych rodzajów ocen bezpieczeństwa w cyber. Została również przedstawiona analogia ogrodzenia, która jest pomocna w zrozumieniu klasyfikacji dla osób związanych nieco luźniej z cyberbezpieczeństwem.

Z moich obserwacji wynika, że największe problemy z jednakowym zrozumieniem po obu stronach (dostawców i klientów) dotyczą oceny podatności, testów penetracyjnych, oraz ćwiczeń red team. W związku z tym kolejność opisywania zacznę właśnie od nich i w kolejnym poście wrócę z opisami oceny podatności oraz testów penetracyjnych. Do następnego! ✌️

Referencje

OWASP Application Security Verification Standard 4.0

Na początku marca pojawiła się nowa wersja OWASP Application Security Verification Standard (ASVS), który jest de facto podstawowym narzędziem w ocenie bezpieczeństwa aplikacji zarówno na naszym podwórku jak i za granicą.

Zmian względem poprzedniej wersji 3.0.1 wydanej w 2016 roku jest sporo, zarówno od strony samych wytycznych jak i ogólnego “ducha” dokumentu. W związku z tym postanowiłem wypisać co ciekawsze punkty, lecimy!

  • Wyrównanie wytycznych “V2: Authentication” oraz “V3: Session Management” ze standardem NIST 800-63-3 Digital Identity Guidelines — świetny ruch, standardy branżowe powinny mieć punkty wspólne wszędzie gdzie tylko można;
  • Zmiana układu sekcji, która pomaga w dodawaniu/usuwaniu odpowiednich wytycznych z zakres audytu (np. jeżeli aplikacja nie korzysta z JSON Web Tokens to cała sekcja związana z JWT może zostać w prosty sposób pominięta);
  • Zmapowanie podatności do odpowiednich rodzajów wyznaczonych przez Common Weakness Enumeration (CWE), oczywiście w miarę możliwości bo nie wszystko da się przełożyć 1:1;
  • Wyrównanie całości poziomu 1 (L1) z wymogami OWASP Top 10 2017 (jedynym wyjątkiem jest tutaj A10 czyli logowanie) co ułatwia adoptowanie Top 10 bo pieczemy dwie pieczenie na jednym ogniu;
  • Poziom 1 (L1) w nowej wersji ASVS zapewnia zgodność z Sekcjami 6.5+ standardu PCI DSS 3.2.1 innymi słowy — implementując ASVS na poziomie 1 spełnimy wymagania związane z Sekcjami 6.5+ standardu PCI DSS w projektach, które tego  wymagają;
  • Zmiana podejścia do architektury aplikacji z monolitów server-side na to co dzisiaj jest już chlebem powszednim czyli: server-less API,  functional programming na produkcji, producenci (API) i cały wachlarz konsumentów (desktop, web, mobile), chmury, kontenery, CI/CD i związana z tym wszystkim kultura DevSecOps;
  • Porzucenie kontrolek związanych z aplikacjami mobilnymi na rzecz standardu OWASP Mobile Application Security Verification Standard;
  • Zapewnienie możliwości przetestowania całego poziomu 1 (L1) podejściem black-box bez dostępu do dokumentacji, kodu źródłowego, deweloperów et cetera. Jedynym wyjątkiem jest A10 (Top 10), które wymaga zrzutów ekranu, wywiadów i ogólnego dowodu na logowanie.

Ponadto da się wyczuć mocny nacisk na:

  1. Testowanie podejściem hybrydowym wszystkich trzech poziomów (w dokumencie brzmi to jak zwykły white-box);
  2. Automatyzację wszystkiego co można z poziomu potoku CI/CD (np. narzędzia SAST i DAST powinny być używane w trybie ciągłym już na etapie wytwarzania aplikacji, a nie dopiero w momencie oceny podatności czy testu penetracyjnego).

Osobiście bardzo podoba mi się uwypuklenie podnoszenia poprzeczki w procesie wytwórczym oprogramowania, oraz zabranie głosu w sprawie ograniczeń związanych z podejściem black-box połączonej z rekomendacją hybrydowej oceny bezpieczeństwa aplikacji wychodzącej poza sam dostęp do instancji aplikacji i włączającej również przegląd kodu źródłowego czy wywiady z deweloperami.

Podsumowując nowa wersja ASVS bardzo dobrze wpasowuje się w dzisiejszy sposób wytwarzania, działania, i utrzymywania aplikacji. Jest to krok w dobrym kierunku, który był potrzebny już od dłuższego czasu (3 lata w IT to długo). Kudos w stronę autorów!

Przegląd i omówienie tegorocznego programu Black Hat USA

Największa oraz najbardziej prestiżowa konferencja związana z cyberbezpieczeństwem jest już tuż-tuż, a więc jak co roku o tej porze wygospodarowałem chwilę czasu na zapoznanie się z programem i wybranie tego co z mojej perspektywy jest najbardziej warte obserwacji.

Muszę przyznać, że jestem bardzo pozytywnie zaskoczony pod względem ilości solidnego materiału w tegorocznej edycji BH:USA. Niestety nie będę miał okazji być w Las Vegas fizycznie więc pozostaje mi czekać z niecierpliwością na slajdy, papierki, i nagrania.