Źródła informacji o podatnościach
Istnieje szereg źródeł informacji o potencjalnych podatnościach, które mogą być wykorzystane do identyfikacji słabości w zakresie bezpieczeństwa systemów informatycznych. Jednym z najbardziej znanych jest lista CVE (ang. common vulnerabilities and exposures) publikowana przez MITRE, zawierająca wykaz podatności w dostępnym na rynku oprogramowaniu, uzależnionych od zastosowanej wersji produktu, a niekiedy również funkcjonalności i konfiguracji.
Analiza własnych systemów informatycznych pod kątem występowania podatności CVE może odbywać się w sposób manualny, poprzez analizę wykorzystywanych wersji oprogramowania, czy zainstalowanych aktualizacji – takie podejście będzie jednak bardzo czasochłonne.
Proces może zostać jednak zautomatyzowany poprzez wykorzystanie skanerów podatności – narzędzi, które w sposób automatyczny identyfikują potencjalne luki w bezpieczeństwie systemów.
Ograniczenia skanerów podatności
Analizując możliwość wykorzystania skanerów należy zwrócić uwagę na ich ograniczenia i wynikające z nich fałszywe informacje – zarówno dotyczące wykrycia podatności jak i ich braku. Skanery bazują na informacjach o wersji zainstalowanego oprogramowania – na tej podstawie wyszukują w swojej bazie danych informacje o podatnościach i raportują je.
Informacja o wersji pozyskiwana jest z reguły na podstawie danych zwracanych przez samo oprogramowanie – jeżeli nie zostaną one dostarczone, wówczas skaner może nie być w stanie określić wersji oprogramowania (chyba, że w danym przypadku wykorzystuje również inne metody detekcji), jeżeli z kolei zostanie dostarczona fałszywa informacja, skaner wykorzysta ją przy raportowaniu podatności.
Wykrywanie wersji oprogramowania
Przykładem ilustrującym powyższy problem jest wykrywanie wersji serwera www bazujące na analizie nagłówków odpowiedzi na żądania http – jeżeli w nagłówku odpowiedzi nie będzie znajdować się informacja o wykorzystywanej wersji serwera to skaner może mieć problem z przeprowadzeniem identyfikacji. Jeżeli zaś, w wyniku utwardzania konfiguracji skanera, nagłówek będzie zawierał fałszywą informację, wówczas skaner udostępni informacje o podatnościach dotyczących wskazanej w nagłówku, nieprawdziwej wersji wykorzystywanego oprogramowania.
Opisany powyżej model wykrywania podatności odzwierciedla działanie skanera łączącego się z poszczególnymi usługami w sieci i pozyskującymi w ten sposób informacje o oprogramowaniu wykorzystywanym do ich udostępniania.
Oprócz opisanego wyżej problemu z identyfikacją wersji należy wspomnieć o kwestiach związanych z wpływem sieciowych mechanizmów zabezpieczających na możliwość przeprowadzenia takiego testu – praktyka wskazuje, że działający system IPS może skutecznie sparaliżować badanie.
Skanowanie usług udostępnianych w sieci wiąże się z ryzykiem niestabilności działania infrastruktury informatycznej. Skaner generuje znaczny ruch sieciowy, mogący powodować opóźnienia w transmisji danych i tym samym negatywnie wpływać na prawidłowe działanie uruchomionych aplikacji.
Może również, w szczególnych przypadkach, spowodować awarię badanych komponentów. Powyższe oznacza, że skany, jakkolwiek pozornie bezpieczne, muszą zostać odpowiednio zaplanowane, uwzględniając specyfikę testowanych systemów.
Mapowanie usług z wykorzystaniem nmap
Przed skanowaniem podatności w usługach udostępnionych w sieci informatycznej warto przeprowadzić mapowanie dostępnych usług z wykorzystaniem nmap. Jakkolwiek skanery podatności również posiadają mechanizmy rekonesansu, to jednak ich elastyczność jest tutaj zdecydowanie mniejsza. Wskazane podejście może być szczególnie przydatne w sytuacji, gdy identyfikacja podatności musi być powiązana z jednoczesnym ukrywaniem się przed systemem IPS.
Mapa zidentyfikowanych usług może posłużyć do precyzyjnego skonfigurowania polityki skanowania podatności, co – oprócz skrócenia czasu testów i zmniejszenia zbędnego ruchu sieciowego – również może ułatwić przeprowadzenie testów w środowisku chronionym przez zabezpieczenia sieciowe.
Skanowanie podatności może odbywać się również w oparciu o bezpośredni dostęp do badanego komponentu. W takim przypadku skaner loguje się, z reguły wykorzystując konto uprzywilejowane, w celu pozyskania informacji o uruchomionym oprogramowaniu, ich wersjach i aktualizacjach. Rozwiązanie to zapewnia dużo większą dokładność, redukując jednocześnie ryzyko błędnych informacji o podatnościach. Wiąże się ono z koniecznością udostępnienia danych uwierzytelniających, co może być wątpliwości w przypadku, gdy skan przeprowadzany jest przez podmiot zewnętrzny.
Badane urządzenie musi również obsługiwać protokół komunikacyjny zrozumiały dla skanera – o ile takowe nie mają z reguły problemu z komunikacją tekstową (np. poprzez SSH), o tyle raczej nie dają sobie rady z obsługą interfejsu graficznego (np. poprzez RDP).
Skaner, podczas swojego działania, wykorzystuje udostępnianą przez dostawcę bazę zawierającą informacje o podatnościach. Aby zapewnić efektywne identyfikowanie słabości infrastruktury informatycznej, baza ta musi odnosić się do wszystkich jej komponentów. Co więcej, baza ta musi być regularnie aktualizowana z uwagi na pojawiające się nowe podatności. W przypadku braku uaktualnień skaner staje się bezużyteczny.
W przypadku niektórych skanerów baza informacji o podatnościach może być samodzielnie rozszerzana o własne pluginy umożliwiające wykrywanie specyficznych podatności, które nie zostały uwzględnione przez dostawcę. W ramach realizowanych przez nas projektów rozwijaliśmy własne pluginy w oparciu o język skryptowy NASL, wykorzystywany zarówno przez niektóre skanery komercyjne jak i darmowy OpenVAS.
Wykorzystanie bezpośredniego dostępu do analizy bezpieczeństwa konfiguracji systemów
Skanowanie z wykorzystaniem bezpośredniego dostępu może być wykorzystane nie tylko do sprawdzenia wersji zainstalowanego oprogramowania i aktualizacji, lecz również do analizy bezpieczeństwa konfiguracji urządzenia. W takim przypadku weryfikacji podlegają uruchomione procesy i usługi, mechanizmy uwierzytelnienia, w tym polityki haseł, utwardzenie stosu TCP/IP, logowanie zdarzeń oraz inne parametry mające wpływ na ochronę systemu i przetwarzanych w nim informacji.
Ocena poprawności konfiguracji mechanizmów zabezpieczających odbywa się z reguły w odniesieniu do powszechnie uznanych standardów, w tym CIS Benchmarks, DISA STIG, rzadziej CCE (ang. Common Configuration Enumaration). Korzystając z omawianej funkcjonalności należy jednak ostrożnie podchodzić do raportów oceniających bezpieczeństwo konfiguracji i nie wprowadzać bezkrytycznie zalecanych zmian.
Może się bowiem okazać, że ich wdrożenie uniemożliwi prawidłowe działanie systemu z uwagi na wyłączenie potrzebnych usług lub protokołów sieciowych. Analiza konfiguracji, przeprowadzana przez pryzmat dobrych praktyk opisanych we wskazanych wyżej standardach, powinna uwzględniać specyficzne wymagania badanych systemów.
Analiza konfiguracji może być przeprowadzona nie tylko w oparciu o opisaną funkcjonalność skanerów, ale również z wykorzystaniem samodzielnie napisanych skryptów sczytujących poszczególne parametry konfiguracyjne. To podejście, jakkolwiek pozornie bardziej pracochłonne, może być w praktyce bardziej efektywne, umożliwiając analizę konfiguracji w zakresie adekwatnym do wymagań bezpieczeństwa danego systemu i udostępniając dane wynikowe w formacie ułatwiającym ich dalszą analizę.
Nie bez znaczenia jest również fakt, że dane uwierzytelniające umożliwiające zalogowanie na konto administracyjne nie są wprowadzane do skanera – w tym przypadku skrypty są wykonywane przez administratora, umożliwiając pełną kontrolę nad ich zawartością i działaniem.
Weryfikacja konfiguracji systemów nie powinna ograniczać się wyłącznie do sprawdzenia zgodności z przywołanymi wyżej standardami, ale powinna dodatkowo uwzględniać specyficzne wymagania bezpieczeństwa badanego środowiska.
Stąd analiza taka powinna uwzględniać między innymi zasadność stosowanych reguł filtracji ruchu sieciowego, czy konfiguracji mechanizmów wykrywania i reagowania na próby naruszeń bezpieczeństwa. Jakkolwiek proces ten do pewnego stopnia może być zautomatyzowany, to jednak manualny przegląd pozwala na dokładniejsze wykrycie anomalii mających negatywny wpływ na działanie zabezpieczeń.
Standardy i metody testowania
Badaniem podatności powinno być objęte również oprogramowanie wytwarzane przez lub na potrzeby organizacji. W tym jednak przypadku punktem odniesienia będą inne, niż poprzednio wymienione, standardy. Analiza podatności może uwzględniać standardy OWASP – w tym OWASP Web Security Testing Guide w przypadku aplikacji webowych, OWASP Mobile Application Security Testing Guide w przypadku aplikacji mobilnych, OWASP ASVS i inne.
Identyfikacja podatności w zastosowanych rozwiązaniach programistycznych powinna uwzględniać kwestie umieszczone na, publikowanej przez MITRE, liście CWE (common weakness enumeration) czy OWASP Cheat Sheet. Analiza bezpieczeństwa aplikacji nie musi ograniczać się do testów działającego oprogramowania (testy DAST – ang. Dynamic Application Security Testing), ale obejmować również analizę kodu źródłowego (testy SAST – ang. Static Application Security Testing) w sytuacji, gdy kod jest dostępny.
Jakkolwiek testy DAST i SAST mogą być realizowane przy pomocy narzędzi automatycznych, to jednak niektóre kategorie podatności są wykrywane praktycznie wyłącznie podczas testów manualnych – dotyczy to między innymi problemów z logiką aplikacji, wpływających na bezpieczeństwo jej i przetwarzanych przez nią danych.
Problemem jest również raportowanie przez skanery fałszywych podatności (na przykład podatności na ataki XSS i SQL Injection, czy błędnej obsługi mechanizmów CORS) – wszystko to sprawia, że identyfikowanie podatności w niestandardowym oprogramowaniu nie powinno ograniczać się wyłącznie do testów automatycznych, ale powinno uwzględniać również ręczną weryfikację poprawności działania mechanizmów zabezpieczających.
