Zespół Fioletowy

https://chacker.pl/

Inżynieria wykrywania to proces budowania wykrywania wokół różnych TTP w celu poprawy wykrywania i reagowania. W przypadku drużyny fioletowej może się to rozpocząć od utworzenia przez zespół niebieski wykrycia, a następnie zespół czerwony pracuje nad przetestowaniem i udoskonaleniem tego wykrycia. Może to być również wynikiem przeglądu dziennika i udoskonalenia alertów po przeprowadzeniu symulacji zagrożenia lub emulacji. Fioletowy zespół może pomóc w tworzeniu, udoskonalaniu i testowaniu wykryć, co zapewnia organizacji więcej możliwości wyłapywania atakujących wcześniej w drzewie ataków. Fioletowe łączenie drużyn może być również wykorzystywane w ramach reagowania na pojawiające się zagrożenia. Zapewni to organizacji głębsze zrozumienie sposobu działania pojawiającego się zagrożenia, a także umożliwi wykrycie potencjalnych zagrożeń w odpowiedzi na opublikowanie dowodu słuszności koncepcji (POC) w terminie zerowym oraz wszelkich wiadomości, na które organizacja musi zareagować. W dalszej części tego rozdziału przyjrzymy się bliżej fioletowym zespołom.

Symulacja i emulacja zagrożeń

https://chacker.pl/

Wcześniej  przedstawiliśmy strukturę MITER ATT&CK, która pomaga kategoryzować różne etapy ataku i umożliwia opisanie taktyk, technik i procedur (TTP) stosowanych przez atakujących. Symulacja i emulacja zagrożeń łączą te drzewa ataków przy użyciu znanych TTP, aby pomóc zidentyfikować słabe punkty kontroli, zasad, praktyk i ludzi w środowisku. Testy te często rozpoczynają się od scenariusza „co będzie, jeśli” z udziałem podmiotu zagrażającego, ustalenia TTP i celu. Pomaga organizacji zrozumieć, co może zobaczyć atakujący, co mogą zobaczyć zespoły obrony i jakie kontrole, jeśli w ogóle, będą przeszkadzać atakującym w osiągnięciu ich celów. Mapując działania na TTP, testerzy mogą pomóc zespołowi niebieskiemu w mapowaniu technik, które działają w środowisku, nie działają w środowisku, i umożliwić tym zespołom mapowanie tych technik na kontrole i źródła danych, które wykrywają lub nie nie wykryć określonej aktywności. Mogą one w późniejszym czasie zostać wykorzystane do dodatkowej aktywności fioletowego zespołu. Symulacja zagrożeń to nie tylko jedna rzecz i jest to jeden z powodów, dla których znajduje się ona wyżej w modelu dojrzałości. Symulacje zagrożeń mogą obejmować połączenie phishingu, hakowania fizycznego, aplikacyjnego, sieciowego i sprzętowego. Symulacja zagrożeń jest podobna do testów penetracyjnych, ale kluczową różnicą jest to, że celem testów nie są po prostu „klejnoty koronne” organizacji, ale raczej przetestowanie ludzi, procesów i technologii organizacji w oparciu o techniki ataku. Symulacje zagrożeń również wymagają więcej planowania niż testy penetracyjne. Często z góry ustala się, jakie TTP zostaną użyte podczas ćwiczenia, i można stworzyć narzędzia, które konkretnie ćwiczą określone TTP, albo w celu określenia ich skuteczności, albo dlatego, że wiadomo, że ich skuteczność jest skuteczna. Po rozpoczęciu ćwiczenia niektóre TTP mogą nie działać lub mogą wystąpić problemy. Być może testerzy będą musieli dostosować lub zmienić TTP, nawet jeśli inne zostały zaplanowane ze względu na ograniczenia czasowe lub nieprzewidziane kontrole. Na przykład, jeśli wykorzystanie WinRM do ruchu bocznego jest zaplanowanym kluczowym TTP, tester może zamiast tego przejść na WMI, jeśli WinRM jest wyłączony w całym przedsiębiorstwie.

UWAGA MITER Attack Navigator (https://mitre-attack.github.io/attacknavigator/) to doskonałe źródło informacji o mapowaniu TTP na potrzeby ćwiczenia. Ma możliwość opisywania TTP, a także wyróżniania tych używanych w ćwiczeniu i eksportowania ich do JSON w celu udostępnienia innym członkom zespołu. Ponadto można nakładać różne warstwy na inne, aby pokazać zakres TTP wykorzystywanych podczas różnych ćwiczeń symulacyjnych zagrożeń, aby skupić się na tym, co działa, a co jeszcze nie zostało przetestowane. Attack Navigator zawiera także łącza do taktyk i technik każdego TTP, dzięki czemu czytelnik może dowiedzieć się więcej na ich temat w oparciu o to, co zostało odwzorowane w ćwiczeniu.

Jeden z przykładów symulacji zagrożenia zaczyna się od tego, że ktoś wkracza do budynku biurowego, podążając za pracownikiem przez otwarte drzwi i wszczepiając fizyczne urządzenie sprzętowe w sieci (T1200). Stamtąd tester może użyć obiektu odpowiadającego do zatrucia LLMNR (T1577.001) w celu zebrania poświadczeń. Stamtąd osoba atakująca może złamać poświadczenia, a następnie użyć WinRM (T1021.006), aby przejść do innych systemów, dopóki tester nie znajdzie systemu z podwyższonymi poświadczeniami. Testerzy następnie zrzucili dane uwierzytelniające z LSASS (T1003.001) za pomocą Mimikatz i przechwycili hasło w postaci zwykłego tekstu dla konta administratora domeny. Mając te poświadczenia, testerzy mogą wykonać DCSync (T1003.006) względem kontrolera domeny, aby pobrać wszystkie poświadczenia domeny i utworzyć Złoty Bilet (T1588.001). Tego biletu można użyć do podszywania się pod użytkownika mającego dostęp do poufnej aplikacji internetowej, a następnie uzyskania dostępu do tej aplikacji za pośrednictwem zaatakowanego systemu poprzez wdrożenie VNC (T1021.005) w celu. Po zalogowaniu się do aplikacji testerzy mogą ukraść i wyeksportować arkusz kalkulacyjny spakowany za pomocą programu PowerShell (T1005.003), przenieść go z powrotem na urządzenie sprzętowe i wysłać go z powrotem do testera przez sieć komórkową (T1008). Emulacja zagrożeń jest podobna do symulacji zagrożeń w tym sensie, że koncentruje się na drzewach ataków i osiąganiu celów, ale głównym wyróżnikiem emulacji zagrożeń jest że emulacja wykonuje te same TTP, co rzeczywiste podmioty zagrażające, w przeciwieństwie do symulacji, które skupiają się wyłącznie na TTP lub celach. Emulowanie określonych protokołów TTP, zwłaszcza oprogramowania niestandardowego, może być trudne i zazwyczaj wymaga bliskiej współpracy z zespołem ds. analizy zagrożeń, który może pomóc w zbadaniu i określeniu, jakich protokołów TTP używa dany podmiot zagrażający. Zazwyczaj w przypadku emulacji zagrożeń tester rozpoczyna od rozpoznania aktorów zagrożeń, które potencjalnie będą atakować organizację klienta. Można tego dokonać na podstawie własnych badań testera lub uzyskać od organizacji zajmującej się badaniem zagrożeń, która może pomóc w dostarczeniu informacji o celach typowym podmiotom zagrażającym. Po wybraniu aktora zagrażającego tester zazwyczaj otrzymuje listę TTP i wskaźników naruszenia bezpieczeństwa (IOC). W dokumentach TTP szczegółowo opisano, w jaki sposób ugrupowanie zagrażające wykonuje różne etapy, od namierzania po eksfiltrację. IOC zazwyczaj zawierają skróty użytego złośliwego oprogramowania. Podczas ćwiczenia polegającego na emulacji zagrożenia tester dostosuje wiedzę do celu i pomoże zidentyfikować rodzaje rzeczy, do których może dążyć podmiot zagrażający, takie jak określone dane, konkretny wpływ lub określony dostęp. Po zidentyfikowaniu potencjalnego celu tester pobierze znane TTP i spróbuje przypisać je do prawdopodobnych łańcuchów ataków. W wielu przypadkach istnieją kroki, które nie są znane w zakresie działania ugrupowania zagrażającego, więc tester uzupełni je prawdopodobnymi TTP, które mają sens w kontekście. Następnie tester sprawdzi, jakie informacje na temat IOC można znaleźć. Jeśli istnieje złośliwe oprogramowanie, można przeprowadzić dodatkową analizę poprzez odwrócenie zespołów .NET, podstawowe odwrócenie plików binarnych lub zapisanie zachowania złośliwego oprogramowania. Jeśli to możliwe, tester może stworzyć lub zmodyfikować narzędzia, aby działały podobnie do tego, co robi znane szkodliwe oprogramowanie, aby testowanie było jak najbardziej realistyczne. Dodanie tych elementów do drzewa ataków pomoże zapewnić, że emulacja będzie jak najbardziej zbliżona do rzeczywistego atakującego.

UWAGA: Pobieranie próbek złośliwego oprogramowania i ich analizowanie może być niebezpieczne. Jeśli nie wiesz, jak bezpiecznie analizować tego typu próbki, zapoznaj się z rozdziałami 4 i 5 tej książki i dowiedz się, jak skonfigurować bezpieczne środowisko analityczne. Niezastosowanie się do tego może spowodować, że zostaniesz narażony na ryzyko ze strony prawdziwego ugrupowania zagrażającego, co może oznaczać bardzo zły dzień.

Jednym z przykładów może być APT33, znany również jako Elfin. Jest to podejrzana grupa irańska, której celem są sektory lotnictwa i energetyki. Dobrym miejscem do rozpoczęcia poszukiwań jest strona MITRE ATT&CK pod adresem https://attack.mitre.org/groups/G0064/. Po przejrzeniu informacji możesz ułożyć drzewo ataków zawierające lokalny przepływ technik aż do uzyskania dostępu do udziałów serwera plików zawierających informacje w Twojej organizacji, które mogą być celem. Patrząc na narzędzia, widzimy, że obecne są zarówno Ruler, jak i Empire, więc prawidłowe drzewo ataków może zaczynać się od rozpylania haseł (T1110.003) przy użyciu Ruler (S0358) przeciwko witrynom programu Outlook Web Access (T1078.004) połączonym z Internetem. Po znalezieniu prawidłowego konta przy użyciu tej techniki tester może zdecydować się na użycie PowerShell Empire (S0363) do poleceń i kontroli (C2) przy użyciu protokołu HTTPS (T1071.001). Aby dostarczyć ładunek, tester może zdecydować się na zbudowanie dokumentu Microsoft Word (T1024.002) zawierającego trojana ze złośliwym makrem napisanym w języku VBA (T1059.005), które uruchamia ładunek programu PowerShell (T1059.001). Po ustaleniu tego tester może utworzyć plik wykonywalny AutoIt (S1029), który można umieścić w klawiszach Uruchom w Rejestrze, aby uruchamiał się po zalogowaniu użytkownika (T1547.001). Ten plik binarny AutoIt może używać ładunków programu PowerShell zakodowanych w formacie Base64 (T1132.001) w celu zapewnienia trwałości. Gdy tester dostanie się do systemu, może użyć Empire do podniesienia uprawnień w celu ominięcia funkcji UAC i uruchomić Mimikatz (T1003.001) w celu zebrania danych uwierzytelniających, a następnie przenieść się w bok, korzystając z przechwyconych danych uwierzytelniających (T1078) do innych systemów. Za pomocą polecenia Net (S0039) tester może zidentyfikować użytkowników, którzy mogą przyznać podwyższony poziom dostępu, a następnie w dalszym ciągu używać Empire do przemieszczania się w bok i zrzucania poświadczeń, dopóki nie znajdą docelowych danych. Po znalezieniu danych docelowych tester może użyć programu WinRAR (T1560.001) do skompresowania i zaszyfrowania danych oraz wysłania ich na kontrolowany przez testera serwer FTP (T1048.003) w celu eksfiltracji. Po przeprowadzeniu symulacji lub emulacji zagrożenia tester zazwyczaj mapuje wszystkie punkty TTP i identyfikuje kody IOC używanych narzędzi oraz plików binarnych uruchomionych w systemach, a następnie przekazuje je zespołowi obrony (zespołowi niebieskiemu), aby spróbował określić, co zostało zaobserwowane, co przeoczone, a co zostało zauważone, ale nie podjęto żadnych działań. Wyniki te pomogłyby organizacji zrozumieć, w jaki sposób ten podmiot zagrażający miałby wpływ na organizację i jakie mechanizmy kontrolne powinny wyłapać część materiału. Najważniejszym wnioskiem jest to, jakie TTP należy wykryć, aby pomóc w proaktywnym wykrywaniu i blokowaniu tych aktorów zagrażających, tak aby organizacja ich wyprzedziła. Wadą tych ćwiczeń jest to, że zazwyczaj wymagają wielu dodatkowych badań, programowania i planowania. Z tego powodu regularne wykonywanie tych testów jest bardzo trudne, chyba że masz duży zespół, który może prowadzić badania i wspierać innych testerów. Testy te dają jednak najbardziej realistyczny obraz tego, jak konkretny podmiot zagrażający będzie wyglądał w Twoim środowisku, jak możesz sobie poradzić z punktu widzenia obrony i reagowania na określone TTP oraz gdzie należy poprawić stan bezpieczeństwa organizacji, aby wykryć i uniemożliwić temu ugrupowaniu zagrażającemu osiągnięcie celów w Twojej sieci.

Proces testowania

https://chacker.pl/

Testowanie zazwyczaj rozpoczyna się od rozmowy telefonicznej, podczas której omawiane są z klientem SOW i ROE. Ustalane są ramy czasowe testowania i uwzględniane są wszelkie inne wątpliwości lub tematy związane z testowaniem. Po uzgodnieniu wszystkich tych informacji ustalane są daty testów i tester może rozpocząć planowanie zaangażowania. Wszelkie zmiany w SOW lub ROE muszą być udokumentowane na piśmie, aby uniknąć nieporozumień. Proces ten powinien zostać udokumentowany jako część zasad i procesów zespołowych. Niezależnie od rodzaju testów, istnieje ogólny schemat testów penetracyjnych. Testowanie rozpoczyna się od rozpoznania, które obejmuje badanie przestrzeni IP, nazw DNS i innych aspektów testowania sieci, ale może obejmować wiele innych elementów w przypadku innych typów testów. Na przykład w przypadku testów fizycznych, częścią działań zwiadowczych może być przeglądanie zdjęć z rozpoznania powietrznego w Internecie lub zdjęć opublikowanych w Internecie z wydarzeń odbywających się w danej lokalizacji w celu uzyskania dodatkowych informacji. Stamtąd przeprowadzane jest odkrywanie, skanowanie, eksploatacja i posteksploatacja. Szczegóły tych testów różnią się w zależności od rodzaju testów penetracyjnych; mają one jednak charakter cykliczny. Po dokonaniu nowych odkryć dodatkowe rozpoznanie może rozpocząć dodatkowe kroki w celu ustalenia kolejnego zestawu kroków. O tym procesie napisano całe książki, dlatego skupimy się bardziej na procesie biznesowym niż na procesach technicznych. Po zakończeniu testów rozpoczyna się faza raportowania. Sprawozdawczość powinna zawierać streszczenie mające na celu umożliwienie czytelnikom nietechnicznym przeglądu tego, co raport oznacza dla organizacji. Obejmuje to aspekty wysokiego szczebla, takie jak cele osiągnięte przez testera, ogólny wpływ na organizację oraz ogólną strategię działań naprawczych i poprawy postawy organizacji. Narracja ataku pomaga przedstawić kroki podjęte podczas testowania i może zawierać szczegóły techniczne, które menedżerowie techniczni będą mogli zrozumieć na temat przebiegu ataku. Może to obejmować mapy ataków przedstawiające łańcuch ataków, kroki podjęte w celu osiągnięcia celów testowania, napotkane kontrole i wszelkie wykryte obejścia. Narracja ma na celu opowiedzenie czytelnikowi, co się wydarzyło i jaki był wpływ, a także dać innemu testerowi zrozumienie, jak odtworzyć ten test, jeśli zostanie mu przypisany ponownie. Sekcja raportu z wynikami zawiera listę problemów wykrytych podczas testowania i zazwyczaj zawiera ocenę wpływu, opis ustalenia, kroki umożliwiające jego odtworzenie, zrzuty ekranu służące jako dowód oraz sugestię rozwiązania. W niektórych raportach ocena wpływu może być wymieniona jako ryzyko, ale ponieważ niektórych elementów ryzyka nie można obliczyć, w rzeczywistości jest to postrzegany wpływ na środowisko. Dobry raport będzie zawierał opis sposobu obliczania tego wpływu, tak aby czytelnik mógł zrozumieć, co oznaczają oceny w kontekście. Ustalenia te powinny dotyczyć aktywów lub obszarów środowiska, na które mają wpływ, i powinny ograniczać się do jednej kwestii. Problemy, które wymagają rozwiązania wielu osób, mniej pomagają firmie, ponieważ nie można ich łatwo przypisać do grupy w celu rozwiązania. Raporty mogą zawierać inne elementy, w zależności od tego, o co jeszcze poprosi klient, takie jak informacje o datach, SOW, ROE, ograniczeniach testów, ewentualnych wynikach skanowania i inne aspekty, które zespół testujący uwzględnia we wszystkich swoich raportach. Raporty te powinny być jasne, zwięzłe i zrozumiałe dla docelowych odbiorców. W razie potrzeby mogą zostać udostępnione dodatkowe łącza, które pomogą czytelnikowi zrozumieć, jak rozwiązać problemy. Ten raport stanowi prawdziwą wartość w testowaniu i chociaż samo testowanie jest pomocne, bez raportu dotyczącego jakości uzyskanie trakcji w celu naprawienia problemów może być trudne i obniży jakość testowania.

Testy penetracji chmury

https://chacker.pl/

Testowanie w chmurze to nowa dyscyplina, która w chwili pisania tego tekstu nie jest zbyt dobrze rozwinięta. Celem testowania chmury jest identyfikacja luk związanych z chmurą i narażanie zasobów chmury. Zwykle robi się to poprzez wykrycie słabych punktów w zarządzaniu zasobami, łańcuchem dostaw, tożsamością i dostępem (IAM) lub kluczowymi aspektami zarządzania chmurą. Możliwymi celami mogą być pamięć masowa w chmurze, usługi w chmurze, serwery w chmurze i ogólnie dostęp do zarządzania chmurą. Rodzaje wniosków wynikających z testów w chmurze obejmują zarówno pliki dostępne w Internecie, jak i luki w konfiguracji, które mogą pozwolić na eskalację uprawnień lub przejęcie konta. W miarę wdrażania nowych usług w chmurze mogą one integrować się z innymi usługami w chmurze, a testowanie w chmurze może pomóc zidentyfikować słabe punkty w zabezpieczeniach integracji języka SAML (Security Assertion Markup Language) i innych narzędzi umożliwiających jednokrotne logowanie (SSO), które indywidualnie mogą nie zapewniać ryzyko, ale w połączeniu mogą prowadzić do kompromisu. SOW w przypadku testowania w chmurze są jeszcze trudniejsze, ponieważ oprócz tego, czego chce firma, różni dostawcy usług w chmurze mają własne zasady zaangażowania (ROE), które regulują ich usługi. Dlatego przed rozpoczęciem testowania upewnij się, że znasz wszystkie testowane komponenty i ROE dostawcy chmury. Niektórzy z tych dostawców mogą również mieć błąd programu nagród,więc jeśli znajdziesz słabe punkty, możesz je zgłosić na wiele sposobów. Wiele organizacji przenosi się do chmury, aby wyeliminować inne typy ryzyka, ale usługi w chmurze są często trudne do bezpiecznej konfiguracji i stwarzają inne możliwości błędnej konfiguracji i słabych punktów bezpieczeństwa. Bez testowania tych kontroli i tworzenia procesów, zasad i ram zapewniających bezpieczeństwo usług w chmurze firma może wprowadzić ryzyko, które nie jest kategoryzowane i oceniane za pomocą istniejących narzędzi i zasad.

Fizyczne testy penetracyjne

https://chacker.pl/

Testy fizyczne sprawdzają bezpieczeństwo fizycznych aspektów środowiska, w tym drzwi, okien, zamków i innych elementów sterujących zaprojektowanych w celu ochrony fizycznego dostępu do obszaru. Może to obejmować czynności takie jak otwieranie lub omijanie zamków, wkraczanie do otoczenia, omijanie czujników, omijanie alarmów i inne metody uzyskiwania dostępu do zasobu. Nawet takie aspekty, jak dotarcie do bankomatów, podlegałyby testom fizycznym, ponieważ przed oceną jakiegokolwiek innego systemu konieczne byłoby ominięcie zamków, alarmów i innych elementów. Testowanie urządzeń staje się coraz bardziej popularne, jak zobaczysz w rozdziałach Gray Hat Hacking dotyczących hakowania IoT w części IV książki. Testowanie urządzeń analizuje kombinację fizycznych aspektów urządzeń, w tym interfejsów fizycznych oraz wykorzystania oprogramowania sprzętowego i aplikacji, w celu naruszenia bezpieczeństwa samego urządzenia. Często dotyczy to sieci SCADA i innego sprzętu podłączonego do sieci. Testy fizyczne mogą być koordynowane przez zespoły ds. bezpieczeństwa sieci i bezpieczeństwa fizycznego, aby pomóc zrozumieć, w jaki sposób kontrole fizyczne mogą wpłynąć na stan bezpieczeństwa organizacji. Może to dotyczyć wszystkiego, począwszy od bezpieczeństwa centrum danych, poprzez łatwość przedostania się do zastrzeżonego obszaru, aż po pozostawienie złośliwych urządzeń w obszarze podłączonym do sieci. Te spostrzeżenia pomogą zespołom zajmującym się bezpieczeństwem sieciowym i fizycznym uzyskać dodatkowe zalecenia dotyczące zmniejszania skuteczności ataków fizycznych. Podkreśla to również, że niezależnie od tego, jak bezpieczna jest Twoja sieć, jeśli atakujący może odejść z Twoim serwerem bez zatrzymania go, Twoje dane nie są bezpieczne.

Testy penetracyjne aplikacji

https://chacker.pl/

Testowanie aplikacji ogranicza się do aplikacji, komponentu aplikacji lub małego zestawu aplikacji. Celem tego testu jest głębokie wgłębienie się w aplikację i określenie słabych punktów oprogramowania oraz ścieżek ataków w samym oprogramowaniu. Testerzy aplikacji mogą zajmować się aplikacjami internetowymi, aplikacjami skompilowanymi i zainstalowanymi (czasami nazywanymi aplikacjami „grubymi”), aplikacjami mobilnymi, a nawet interfejsami programowania aplikacji (API). Testowanie aplikacji zazwyczaj nie wykracza poza granice analizy poeksploatacyjnej w systemie operacyjnym. Testowanie aplikacji może być uwzględnione w programie dynamicznego testowania bezpieczeństwa aplikacji (DAST) lub statycznego testowania bezpieczeństwa aplikacji (SAST), który jest częścią procesu cyklu życia oprogramowania (SDLC). W takiej sytuacji aplikacje mogą być testowane w ustalonych odstępach czasu, w ramach określonych wydań wersji lub nawet w ramach zautomatyzowanych procesów, gdy ktoś dokona zmiany w kodzie. Testowanie aplikacji pozwala organizacji zrozumieć, w jaki sposób bezpieczeństwo aplikacji wpływa na postawę organizacji, co może prowadzić do tworzenia bezpieczniejszych produktów i eliminowania poprawek na późniejszym etapie procesu SDLC, których naprawienie może być bardziej kosztowne. Pomaga także w ocenie skuteczności kontroli, w tym kontroli biznesowych w aplikacji, a także typowych kontroli, takich jak zapory aplikacji internetowych (WAF) i inne kontrole bezpieczeństwa serwera WWW.

Testy penetracyjne sieci

https://chacker.pl/

Testowanie sieci dotyczy systemów operacyjnych, usług, domen i ogólnych topologii sieci. To właśnie o tym myśli większość ludzi, gdy słyszą wyrażenie „testy penetracyjne”. Celem tych testów jest zazwyczaj sprawdzenie środowiska sieciowego i określenie, czy ktoś może się do niego dostać, określenie możliwych ścieżek ataku, jakie może obrać osoba atakująca po wejściu do środka, oraz określenie, jaki będzie wpływ. Tester może być ograniczony do określonego obszaru sieci, np. tylko obwodu sieci, lub może uzyskać dostęp do wnętrza i być ograniczony do określonego obszaru sieci, np. środowiska PCI lub środowiska klienta. Testowanie sieci bada bezpieczeństwo przedsiębiorstwa przez pryzmat infrastruktury sieciowej, protokołów, komunikacji, systemów operacyjnych i innych systemów podłączonych do sieci. Powinien oceniać skuteczność zarządzania poprawkami i lukami w zabezpieczeniach, segmentację sieci, zarządzanie konfiguracją oraz skuteczność kontroli hosta i sieci.

Testy penetracyjne

https://chacker.pl

Testy penetracyjne badają luki w zabezpieczeniach po kolei, budując drzewa ataków. Drzewa ataków przedstawiają łącznie serię zdarzeń i przedstawiają wynik w taki sposób, że organizacje mogą kontekstualizować znaczenie luk w ich środowisku. Chociaż pojedyncza luka może mieć niską ocenę zgodnie ze wskaźnikiem CVSS (Common Vulnerability Scoring System) skanera podatności, łącząc ją z innymi lukami, osoba atakująca może osiągnąć znacznie większy wpływ. Te drzewa ataków pozwalają zespołowi ds. bezpieczeństwa zrozumieć, w jaki sposób kontrole będą wpływać na luki, a działy biznesowe będą mogły zobaczyć, jak te luki wpływają na firmę z punktu widzenia danych i procesów. Większość testerów penetracyjnych specjalizuje się w konkretnym obszarze: testowaniu sieci, aplikacji, testowaniu fizycznym, urządzeń lub w chmurze. Nie oznacza to, że jest to jedyny rodzaj testów, jaki wykonują, ponieważ ataki często przekraczają granice niektórych z tych komponentów. Testy penetracyjne regulowane są przez zestawienie prac (SOW), które pomoże zdefiniować parametry testów. SOW różnią się znacznie w zależności od celów testowania. W przypadku niektórych organizacji celem jest znalezienie wszystkiego, co może być nieprawidłowe w określonym obszarze, podczas gdy inne mogą mieć określone cele, które chcą, aby tester próbował naruszyć, co nazywa się testami penetracyjnymi zorientowanymi na cel. Testy penetracyjne zorientowane na cel zazwyczaj wyznaczają cele i ramy czasowe na zbadanie modelu zagrożenia. Klient zazwyczaj określa rodzaje rzeczy, którymi się martwi, np. ktoś żądający okupu za środowisko, kradzież tajemnic firmowych, naruszenie poufnych środowisk lub możliwość wpływu na środowiska SCADA. Tester rozpocznie od pozycji w sieci lub poza siecią, a następnie spróbuje dotrzeć do środowiska docelowego, poruszając się po sieci, podnosząc uprawnienia i poruszając się dalej, aż dotrze do celu. Testy penetracyjne pomagają uzyskać lepszy wgląd w wpływ luk w zabezpieczeniach sieci. Budując łańcuchy ataków, tester może pokazać, jak można łączyć kombinacje luk w zabezpieczeniach, aby osiągnąć rezultaty. W ten sposób można określić praktyczne skutki słabych punktów i ocenić skuteczność mechanizmów kompensujących. Krótko mówiąc, wiele organizacji uważa, że określone mechanizmy kontrolne wyłapią złośliwą aktywność i że niektórych luk w zabezpieczeniach nie będzie można wykorzystać; jednakże podczas testu penetracyjnego tester ocenia, co może zrobić atakujący. Prawidłowy raport z testu penetracyjnego nie będzie zawierał „potencjalnych ustaleń”. Zamiast tego będzie zawierać wyłącznie ustalenia, które można udowodnić i udokumentować za pomocą pism, rekomendacji i zrzutów ekranu. Zrozumienie tych praktycznych skutków pomaga organizacji ustalić priorytety i zaplanować zmiany w zabezpieczeniach, które ostatecznie pomogą zwiększyć bezpieczeństwo organizacji.

Zatwierdzone skanowanie pod kątem luk w zabezpieczeniach

https://chacker.pl/

Po wdrożeniu procesu zarządzania podatnościami organizacje mogą chcieć móc sprawdzić, czy wykryte luki nadają się do wykorzystania i czy nie istnieją żadne dodatkowe mechanizmy łagodzące, które mogłyby zatrzymać włamanie. Sprawdzone skanowanie podatności wypełnia tę lukę poprzez pobieranie wyników ze skanowania podatności i przeprowadzanie ręcznej weryfikacji wyników poprzez próbę wykorzystania luki. Jednak po wykorzystaniu luki testy zazwyczaj się zatrzymują, więc dalsze możliwości wykorzystania luki nie są badane. Wykorzystując serwery i usługi, tester usuwa wszelkie wątpliwości co do tego, czy system jest podatny na ataki. Wiele osób rozpoczyna przygodę z testami penetracyjnymi od wykonywania tego typu testów, ponieważ zakres jest ograniczony, cele są konkretne i często występuje wiele powtórzeń. Rozwijając swoje umiejętności w zakresie badania podatności, tworzenia ataku i wykonywania exploita, testerzy mogą udoskonalić swoje umiejętności ataku, aby przygotować się do bardziej zaawansowanych testów penetracyjnych. Nie wszystkie organizacje mają oddzielną funkcję przeprowadzania sprawdzonego skanowania pod kątem luk w zabezpieczeniach. Niektórzy po prostu polegają na uwierzytelnionych skanach w celu ustalenia luki w zabezpieczeniach, a następnie na tej podstawie wymuszają naprawę. Jednak w miarę rozwoju organizacji często staje się to aspektem programu, nawet jeśli nie jest on długotrwały.

Skanowanie podatności

https://chacker.pl/

Skanowanie pod kątem luk w zabezpieczeniach polega na uruchamianiu narzędzi w środowisku w celu znalezienia luk w zabezpieczeniach. Skanowanie pod kątem luk w zabezpieczeniach to działanie szerokie, ponieważ próbuje przetestować jak najwięcej zasobów w celu ustalenia, czy brakuje poprawek, ale może testować tylko znane problemy, dla których napisano testy. Z drugiej strony testy penetracyjne sięgają głęboko do zasobów, próbując odkryć nowe luki i skutki w niewielkim podzbiorze systemów. Zasadniczo istnieją dwa typy skanowania podatności na ataki: uwierzytelnione i nieuwierzytelnione. Większość organizacji zaczyna od wersji nieuwierzytelnionej, ponieważ jest to najłatwiejsze do wdrożenia. Wadą tego jest to, że podczas nieuwierzytelnionych skanów zazwyczaj na podstawie najlepszych starań domyśla się, czy dana usługa jest podatna na ataki, w związku z czym występuje wysoki odsetek wyników fałszywie pozytywnych (skaner pokazuje usługę jako podatną na ataki, gdy tak nie jest) lub fałszywie negatywnych ( skaner pokazuje, że usługa nie jest podatna na ataki, gdy jest podatna na ataki). Gdy organizacja przeprowadza skanowanie pod kątem luk w zabezpieczeniach, musi mieć drogę do naprawy. Jest to połączenie zarządzania poprawkami i procesami usuwania luk w zabezpieczeniach. Po wdrożeniu tych procesów często okazuje się, że występują fałszywe alarmy, więc organizacja przejdzie do zweryfikowanego skanowania pod kątem luk w zabezpieczeniach, aby ograniczyć liczbę fałszywych alarmów. Zatwierdzone skanowanie luk w zabezpieczeniach uwierzytelnia system w celu bezpośredniego zapytania o wersję oprogramowania, dzięki czemu może służyć zarówno jako identyfikacja wersji pod kątem luk, jak i potwierdzenie konsekwentnego stosowania poprawek. Oprócz bardziej wiarygodnych wyników skanowania, uwierzytelnione skanowanie może jeszcze bardziej usprawnić zarządzanie zasobami i zapasami. Identyfikacja zainstalowanych wersji oprogramowania, oprogramowania, które mogło zostać zainstalowane, które nie jest obsługiwane lub jest sprzeczne z zasadami, a także inne właściwości systemu mogą zostać zebrane w ramach tego procesu, aby dodać je do innych możliwości zarządzania i widoczności organizacji. Identyfikacja systemów na podstawie więcej niż tylko adresu IP może również umożliwić bardziej szczegółowe śledzenie podatności zasobów na hosty korzystające również z protokołu DHCP, co oznacza, że śledzenie trendów podatności zasobu na przestrzeni czasu jest bardziej niezawodne. Działający program zarządzania podatnościami jest podstawą pozostałych działań w Red Teaming. Bez zarządzania podatnościami testy penetracyjne są przydatne jedynie do celów zapewnienia zgodności, ale nawet wtedy wyniki zazwyczaj nie będą korzystne.