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

Podsumowanie miesiąca: maj i czerwiec 2020

Właśnie jestem w pociągu do Katowic. Dwie godziny z hakiem do zużycia więc postanowiłem w końcu nadrobić zaległości i napisać podsumowanie zbiorcze dla maja i czerwca. Co prawda LTE na tej trasie pozostawia wiele do życzenia i pisanie jest toporne, ale albo teraz albo nigdy.

Retrospekcja maja i czerwca

Co udało mi się dowieźć:

  • Wypuściłem pierwszą edycję Akademii Bezpiecznego Kodu i pomimo tego, że jest to tylko jedna pozycja to żeby ją zrealizować musiał się wydarzyć szereg innych akcji

Czego nie udało mi się dowieźć:

Pole do poprawy jest, potok dodatkowych projektów również. Jak to mówi mój dobry kolega fraktal rodzi fraktal.

Aplikacje w obiegu

W maju i czerwcu kontynuowałem namiętne używanie Endela, Qbserve, oraz Auto Sleep. Do rotacji dołożyłem również aplikację Freedom.

Warto wspomnieć, że w maju Endel miał update i dorobił się nowych trybów muzycznych.

Freedom

Tak wygląda zablokowany Instagram

Freedom aplikuje nam proxy na poziomie systemu i w momencie kiedy ustawimy sobie blok czasowy to wycina nam dostęp do niechcianych stron na poziomie sieci. Działa zarówno na macOS jak i iOS.

Sposób nie jest idealny (na macOS można po prostu ubić proces, a na iOS VPN wyłącza się czasami sam z siebie), ale jeżeli sami ze sobą jesteśmy szczerzy to nie będziemy oszukiwać.

Reasumując

Zarówno maj jak i czerwiec uważam za udane. Co prawda nie udało mi się zrealizować wszystkiego co chciałem. Ba! Nie udało zrealizować się nawet połowy, jednak na koniec dnia wiem, że (1) zrealizowałem to co było dla mnie najważniejsze (odpalenie Akademii) oraz (2) coraz lepiej rozumiem temat produktywności.

W chwili obecnej mamy już drugą połowę lipca i jest lepiej niż było, a więc progres (a o to w życiu chodzi) jest kontynuowany. Usprawnianie procesu idzie czasami lepiej, czasami gorzej, ale cały czas idzie do przodu.

Slow but steady wins the race.

Podsumowanie miesiąca: kwiecień 2020

Pod koniec 2019 roku zacząłem odnosić wrażenie, że często jestem zajęty, a nie produktywny (pomimo tego, że pracuję całkiem sporo to nie dowożę tyle ile chcę i mogę). W związku z tym na początku tego roku postanowiłem przebudować od podstaw proces mojego działania.

Styczeń poświęciłem na obserwację tego, w jaki sposób pracuję, z jakich narzędzi korzystam, listowanie dostępnych opcji, i ogólne myślenie o tym, co może się u mnie sprawdzić. Po tym wszystkim postanowiłem, że narzędzi zmieniać nie będę i zostanę przy metodologii GTD, posiłkując się aplikacją Things jako głównym źródłem prawdy (miejsce, w którym ląduje wszystko, co przerabiam).

Jako uzupełnienie w niektórych projektach korzystam z kanbana poprzez Trello, ale podjąłem decyzję o mocnym ograniczeniu tego narzędzia.

Things ma tę wadę, że działa jedynie w ekosystemie Apple. Jednocześnie jest to również jego zaleta, ponieważ jest świetnie zgrany zarówno z macOS, jak i iOS. Dla przykładu: integracja skrótów pozwala bardzo szybko dodawać zadania z referencjami do różnego rodzaju zasobów w systemie (pliki, notatki, URL-e, et cetera), co BARDZO przyśpiesza dodawanie rzeczy „na później”.

Luty był pewnego rodzaju eksperymentem, gdzie wprowadziłem pierwszą wersję procesu planowania tygodni i miesięcy na podstawie wysokopoziomowego spojrzenia stworzonego w postaci mapy myśli (do mapowania myśli korzystam z aplikacji XMind).

Proces wygląda tak, że w każdą niedzielę w Things pojawia się projekt „Retrospekcja: tygodniówka” z zadaniami takimi jak:

  • Przegląd systemu (tj. wszystkiego co mam w Things),
  • Przegląd newsów (via RSS, korzystam z Inoreader),
  • Procesowanie artefaktów zbieranych z sieci przez cały tydzień w Instapaper,
  • Przegląd treningu (obecnie zatrzymany ponieważ siłownie są zamknięte),
  • Przegląd wysokopoziomowego spojrzenia (rzut okiem na wspomnianą powyżej mapę myśli),
  • Ocena poprzedniego tygodnia (leci do Evernote),
  • Plan tygodnia następnego (zaplanowanie zadań w Things).

Natomiast pod koniec każdego miesiąca (np. wczoraj) przechodzę przez projekt „Podsumowanie i planowanie kolejnego miesiąca” składającego się z:

  • Podsumowania poprzedniego miesiąca (szczegółowo w Evernote, luźno tutaj na blogu),
  • Przegląd wysokopoziomowego spojrzenia (tak jak wyżej),
  • Planowanie kolejnego miesiąca (rozpiska planu w Evernote i dodanie/modyfikacja odpowiednich projektów/zadań w Things).

Marzec i kwiecień upłynęły na doskonaleniu powyższych procesów i dowożeniu zaplanowanych projektów oraz zadań, które z nich wynikały.

Na chwilę obecną jest lepiej niż było, ale jeszcze nie osiągnąłem stanu, w który celuję. Bill Gates powiedział kiedyś, że większość ludzi przecenia to, co jest w stanie zrobić w rok, a nie docenia tego, co jest w stanie zrobić w ciągu dekady. W pełni się z tym zgadzam. Wiem, że przeceniałem ilość projektów i zadań, jakie jestem w stanie wykonać w danej jednostce czasu (dzień, tydzień, miesiąc). Nad tym problemem cały czas pracuję i zakładam, że do końca tego roku planowanie będzie trafne w większości przypadków (75% skuteczności będę uważał za sukces).

Retrospekcja kwietnia

Co udało się dowieźć:

Czego nie udało się dowieźć:

Nowe appki w obiegu

W kwietniu zacząłem korzystać z trzech nowych aplikacji: Endel, Qbserve, i Auto Sleep. Poniżej krótkie opisy każdej z nich.

Endel App

Różne tryby generowania melodii w aplikacji Endel

Pracując lubię słuchać muzyki. Do tej pory najczęstszym wyborem była muzyka klasyczna (Bach, Chopin, Liszt), muzyka elektroniczna (Tycho i Boards of Canada), oraz różne soundtracki z gier i filmów (World of Warcraft, Blade Runner, Mr. Robot, i tym podobne). Wszystko grało poprzez Spotify.

Na początku kwietnia postanowiłem wypróbować aplikację Endel, która generuje melodię na podstawie kilku zmiennych takich jak pogoda (lokalizacja via GPS) czy rytm serca (via Apple Watch).

Eksperyment uważam za udany – odkąd zacząłem korzystać z Endel to Spotify włączyłem dokładnie 2 razy. Jedyny minus to szybkie zżeranie baterii, ale jakoś będę musiał z tym żyć.

Qbserve

Qbserve sprytnie zlicza czas spędzony na komputerze

Jednym z największych problemów pracy przy komputerze są rozpraszacze dostępne na wyciągnięcie ręki. Jako pierwszy krok do rozwiązania tego problemu postanowiłem zmierzyć czas, jaki spędzam w różnych aplikacjach i na stronach WWW.

Po miesiącu zbierania statystyk wyszło, że na głupoty poświęcam więcej czasu niż na pracę (taką wisienką na torcie było 15h spędzonych na wykopie). Tak czy siak, podstawą jest świadomość. Teraz wiem ile czasu przelatuje mi przez ręce i podejmuję kroki, aby to optymalizować (konkretny sposób omówię po fazie testowania za miesiąc lub dwa).

Auto Sleep

Jestem w trakcie czytania książki Why We Sleep i co prawda problemów ze spaniem nie mam (do higieny snu przywiązuję wagę od wielu lat), ale chciałem przebadać jakość swojego snu.

Po kilku nocach przespanych z Apple Watch wyszło, że nie jest tak różowo jak mi się wydawało głównie pod kątem długości snu. Będę to poprawiał w tym i kolejnych miesiącach.

Reasumując

Pierwszy kwartał roku 2020 z bonusem w postaci kwietnia zleciał głównie na tworzeniu i optymalizacji procesu. Jest lepiej niż było, ale nie jestem jeszcze tam gdzie chcę być. Plan na maj jest już wstępnie ułożony. Teraz czeka mnie jeszcze przerzucanie projektów i zadań do Things oraz nadanie priorytetów.

Iterate upon success. 👋

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