W ramach swojej działalności zawodowej programiści, pentesterzy i specjaliści ds. bezpieczeństwa muszą zajmować się procesami takimi jak Vulnerability Management (VM), (Secure) SDLC.
Pod tymi wyrażeniami kryją się różne zestawy stosowanych praktyk i narzędzi, które są ze sobą powiązane, chociaż ich użytkownicy są różni.
Postęp techniczny nie osiągnął jeszcze poziomu, w którym jedno narzędzie może zastąpić człowieka do analizy bezpieczeństwa infrastruktury i oprogramowania.
Warto zrozumieć, dlaczego tak się dzieje i z jakimi problemami się borykamy.
Procesy
Proces zarządzania podatnościami ma na celu ciągłe monitorowanie bezpieczeństwa infrastruktury i zarządzanie poprawkami.
Proces Secure SDLC („bezpieczny cykl rozwoju”) ma na celu utrzymanie bezpieczeństwa aplikacji podczas rozwoju i działania.
Podobną częścią tych procesów jest proces Oceny Podatności – ocena podatności, skanowanie podatności.
Główna różnica między skanowaniem maszyn wirtualnych i SDLC polega na tym, że w pierwszym przypadku celem jest wykrycie znanych luk w oprogramowaniu lub konfiguracji innych firm. Na przykład nieaktualna wersja systemu Windows lub domyślny ciąg znaków społeczności dla SNMP.
W drugim przypadku celem jest wykrycie podatności nie tylko w komponentach innych firm (zależnościach), ale przede wszystkim w kodzie nowego produktu.
Stwarza to różnice w narzędziach i podejściach. Moim zdaniem zadanie znalezienia nowych luk w aplikacji jest o wiele ciekawsze, ponieważ nie sprowadza się do pobierania odcisków palców wersji, zbierania banerów, wymuszania haseł itp.
Aby zapewnić wysokiej jakości automatyczne skanowanie podatności aplikacji, wymagane są algorytmy uwzględniające semantykę aplikacji, jej przeznaczenie i konkretne zagrożenia.
Skaner infrastruktury często można zastąpić zegarem, jak to ująłem . Chodzi o to, że czysto statystycznie możesz uznać swoją infrastrukturę za podatną na ataki, jeśli nie aktualizowałeś jej, powiedzmy, przez miesiąc.
Narzędzia
Skanowanie, podobnie jak analizę bezpieczeństwa, można przeprowadzić przy użyciu czarnej lub białej skrzynki.
Black Box
Podczas skanowania czarną skrzynką narzędzie musi mieć możliwość współpracy z usługą poprzez te same interfejsy, za pośrednictwem których pracują z nią użytkownicy.
Skanery infrastruktury (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose itp.) wyszukują otwarte porty sieciowe, zbierają „banery”, określają wersje zainstalowanego oprogramowania i przeszukują swoją bazę wiedzy w poszukiwaniu informacji o lukach w tych wersjach. Próbują także wykryć błędy konfiguracyjne, takie jak domyślne hasła lub otwarty dostęp do danych, słabe szyfry SSL itp.
Skanery aplikacji internetowych (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP itp.) potrafią także identyfikować znane komponenty i ich wersje (np. CMS, frameworki, biblioteki JS). Główne etapy skanera to indeksowanie i rozmycie.
Podczas indeksowania skaner zbiera informacje o istniejących interfejsach aplikacji i parametrach HTTP. Podczas fuzzowania do wszystkich wykrytych parametrów wstawiane są zmutowane lub wygenerowane dane, aby wywołać błąd i wykryć podatność.
Takie skanery aplikacji należą odpowiednio do klas DAST i IAST - Dynamicznego i Interaktywnego Testowania Bezpieczeństwa Aplikacji.
white Box
Istnieje więcej różnic w przypadku skanowania białą skrzynką.
W ramach procesu maszyny wirtualnej skanery (Vulners, Incsecurity Couch, Vuls, Tenable Nessus itp.) często uzyskują dostęp do systemów poprzez wykonanie uwierzytelnionego skanowania. Dzięki temu skaner może pobrać zainstalowane wersje pakietów i parametry konfiguracyjne bezpośrednio z systemu, bez domyślania się ich z banerów usług sieciowych.
Skanowanie jest dokładniejsze i kompletne.
Jeśli mówimy o skanowaniu whiteboxowym (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs itp.) aplikacji, to najczęściej mamy na myśli statyczną analizę kodu i wykorzystanie odpowiednich narzędzi klasy SAST – Static Application Security Testing.
Problemy
Istnieje wiele problemów ze skanowaniem! Z większością z nich mam do czynienia osobiście w ramach świadczenia usługi skanowania budynków i bezpiecznych procesów programistycznych, a także podczas prowadzenia prac związanych z analizą bezpieczeństwa.
Zwrócę uwagę na 3 główne grupy problemów, które potwierdzają rozmowy z inżynierami i szefami służb bezpieczeństwa informacji w różnych firmach.
Problemy ze skanowaniem aplikacji internetowych
- Trudność wdrożenia. Aby było to skuteczne, skanery muszą zostać wdrożone, skonfigurowane, dostosowane do każdej aplikacji, przydzielone środowisko testowe do skanowania i wdrożone w procesie CI/CD. W przeciwnym razie będzie to bezużyteczna procedura formalna, która da jedynie fałszywe pozytywne wyniki
- Czas trwania skanowania. Nawet w 2019 roku skanery słabo radzą sobie z deduplikacją interfejsów i mogą spędzać dni na skanowaniu tysiąca stron z 10 parametrami na każdej, uznając je za różne, chociaż odpowiada za nie ten sam kod. Jednocześnie decyzja o wdrożeniu do produkcji w ramach cyklu rozwojowego musi zostać podjęta szybko
- Słabe rekomendacje. Skanery dają dość ogólne zalecenia i nie zawsze programista może z nich szybko zrozumieć, jak zmniejszyć poziom ryzyka i co najważniejsze, czy trzeba to zrobić już teraz, czy też nie jest to jeszcze straszne
- Destrukcyjny wpływ na aplikację. Skanery mogą równie dobrze przeprowadzić atak DoS na aplikację, jak również mogą utworzyć dużą liczbę podmiotów lub zmienić istniejące (na przykład utworzyć dziesiątki tysięcy komentarzy na blogu), więc nie należy bezmyślnie uruchamiać skanowania na produkcji
- Niska jakość wykrywania podatności. Skanery zwykle korzystają ze stałej tablicy ładunków i mogą łatwo przeoczyć lukę, która nie pasuje do znanego scenariusza zachowania aplikacji.
- Skaner nie rozumie funkcji aplikacji. Same skanery nie wiedzą, czym jest „bankowość internetowa”, „płatność”, „komentarz”. Dla nich są tylko linki i parametry, więc ogromna warstwa możliwych luk w logice biznesowej pozostaje całkowicie odkryta; nie pomyślą o podwójnym odpisie, szpiegowaniu cudzych danych po ID czy zwiększeniu salda poprzez zaokrąglanie
- Skaner nie rozumie semantyki stron. Skanery nie czytają FAQ, nie rozpoznają captcha, same nie wymyślą jak się zarejestrować, a potem ponownie zalogować, że nie można kliknąć „wyloguj” i jak podpisywać żądania przy zmianie parametru wartości. W rezultacie większość aplikacji może w ogóle nie zostać przeskanowana.
Problemy ze skanowaniem kodu źródłowego
- Fałszywie pozytywne. Analiza statyczna to złożone zadanie, które wiąże się z wieloma kompromisami. Często trzeba poświęcić dokładność, a nawet drogie skanery dla przedsiębiorstw dają ogromną liczbę fałszywych alarmów
- Trudność wdrożenia. Aby zwiększyć dokładność i kompletność analizy statycznej, konieczne jest dopracowanie reguł skanowania, a pisanie tych reguł może być zbyt pracochłonne. Czasami łatwiej jest znaleźć wszystkie miejsca w kodzie, w których występuje jakiś błąd i je naprawić, niż napisać regułę wykrywającą takie przypadki
- Brak wsparcia zależności. Duże projekty zależą od dużej liczby bibliotek i frameworków rozszerzających możliwości języka programowania. Jeśli w bazie wiedzy skanera nie będzie informacji o „upadkach” w tych frameworkach, stanie się to martwym punktem i skaner po prostu nawet nie zrozumie kodu
- Czas trwania skanowania. Znalezienie luk w kodzie jest zadaniem złożonym pod względem algorytmów. Dlatego proces ten może zająć dużo czasu i wymagać znacznych zasobów obliczeniowych.
- Niski zasięg. Pomimo zużycia zasobów i czasu skanowania twórcy narzędzi SAST nadal muszą iść na kompromis i analizować nie wszystkie stany, w jakich może znajdować się program
- Powtarzalność wyników. Wskazanie konkretnej linii i stosu wywołań, które prowadzą do luki, jest świetne, ale w rzeczywistości często skaner nie dostarcza wystarczających informacji, aby sprawdzić obecność luki z zewnątrz. W końcu usterka może tkwić również w martwym kodzie, który jest nieosiągalny dla atakującego
Problemy ze skanowaniem infrastruktury
- Niewystarczający zapas. W dużych infrastrukturach, zwłaszcza tych oddzielonych geograficznie, często najtrudniej jest określić, które hosty należy przeskanować. Innymi słowy, zadanie skanowania jest ściśle powiązane z zadaniem zarządzania aktywami
- Złe ustalanie priorytetów. Skanery sieciowe często dają wiele wyników z wadami, których nie można wykorzystać w praktyce, ale formalnie ich poziom ryzyka jest wysoki. Konsument otrzymuje zgłoszenie, które jest trudne do zinterpretowania i nie jest jasne, co należy poprawić w pierwszej kolejności.
- Słabe rekomendacje. Baza wiedzy skanera często zawiera jedynie bardzo ogólne informacje na temat luki i sposobu jej naprawienia, dlatego administratorzy będą musieli uzbroić się w Google. Sytuacja jest nieco lepsza w przypadku skanerów typu whitebox, które mogą wydać określone polecenie naprawy
- Wykonany ręcznie. Infrastruktura może mieć wiele węzłów, co oznacza potencjalnie wiele wad, których raporty należy analizować i analizować ręcznie przy każdej iteracji
- Słaby zasięg. Jakość skanowania infrastruktury zależy bezpośrednio od wielkości bazy wiedzy o podatnościach i wersjach oprogramowania. W której, , nawet liderzy rynku nie posiadają kompleksowej bazy wiedzy, a bazy darmowych rozwiązań zawierają mnóstwo informacji, których liderzy nie posiadają
- Problemy z patchowaniem. Najczęściej łatanie luk w infrastrukturze polega na aktualizacji pakietu lub zmianie pliku konfiguracyjnego. Dużym problemem jest to, że system, zwłaszcza starszy, może zachowywać się w nieprzewidywalny sposób w wyniku aktualizacji. Zasadniczo będziesz musiał przeprowadzić testy integracyjne na działającej infrastrukturze w środowisku produkcyjnym.
Podchodzi do
Jak to może być?
Więcej o przykładach i sposobie radzenia sobie z wieloma z wymienionych problemów opowiem w kolejnych częściach, ale na razie wskażę główne kierunki, w jakich możesz pracować:
- Agregacja różnych narzędzi skanujących. Przy prawidłowym użyciu kilku skanerów można osiągnąć znaczny wzrost bazy wiedzy i jakości detekcji. Możesz znaleźć jeszcze więcej luk niż suma wszystkich skanerów uruchomionych osobno, a jednocześnie możesz dokładniej ocenić poziom ryzyka i przedstawić więcej rekomendacji
- Integracja SAST i DAST. Możliwe jest zwiększenie zasięgu DAST i dokładności SAST poprzez wymianę informacji między nimi. Ze źródeł możesz uzyskać informacje o istniejących trasach, a za pomocą DAST możesz sprawdzić, czy podatność jest widoczna z zewnątrz
- Uczenie maszynowe™. W 2015 roku I (i ) o wykorzystaniu statystyk, aby dać skanerom intuicję hakerów i przyspieszyć ich działanie. Jest to z pewnością pożywka dla rozwoju zautomatyzowanej analizy bezpieczeństwa w przyszłości.
- Integracja IAST z autotestami i OpenAPI. W ramach potoku CI/CD możliwe jest stworzenie procesu skanowania w oparciu o narzędzia pracujące jako proxy HTTP oraz testy funkcjonalne działające po HTTP. Testy i kontrakty OpenAPI/Swagger dadzą skanerowi brakujące informacje o przepływach danych i umożliwią skanowanie aplikacji w różnych stanach
- Prawidłowa konfiguracja. Dla każdej aplikacji i infrastruktury należy stworzyć odpowiedni profil skanowania, biorąc pod uwagę ilość i charakter interfejsów oraz zastosowane technologie
- Dostosowywanie skanera. Często aplikacji nie można przeskanować bez modyfikacji skanera. Przykładem jest bramka płatnicza, w której każde żądanie musi zostać podpisane. Bez napisania konektora do protokołu bramy skanery będą bezmyślnie bombardować żądaniami z błędnym podpisem. Konieczne jest także napisanie specjalistycznych skanerów pod kątem konkretnego rodzaju wady, np
- Zarządzanie ryzykiem. Zastosowanie różnorodnych skanerów oraz integracja z systemami zewnętrznymi takimi jak Asset Management i Threat Management pozwoli na wykorzystanie wielu parametrów do oceny poziomu ryzyka, dzięki czemu kadra zarządzająca będzie mogła uzyskać adekwatny obraz aktualnego stanu bezpieczeństwa inwestycji czy infrastruktury
Bądź na bieżąco i przerwijmy skanowanie podatności!
Źródło: www.habr.com