Artykuł pochodzi z wydania: Kwiecień 2022
O luce bezpieczeństwa nie zawsze dowiadujemy się od producenta sprzętu lub oprogramowania. Coraz częściej informacja trafia do nas z grup lub portali branżowych. A czasami dopiero incydent uświadomi nas o jej istnieniu.
Co jakiś czas spotykamy się z krytyczną luką w zabezpieczeniach. Nie na każdą z nich otrzymujemy od razu poprawkę, którą możemy zainstalować w naszych systemach. Szczególnie krytyczne są podatności zlokalizowane w zasobach wystawionych w strefach sieci dostępnych dla anonimowych użytkowników internetu.
> Podatności i patche
Liczba zgłoszonych podatności do bazy CVE w czasie powstawania artykułu wynosiła w przybliżeniu 200 000. Oczywiście dotyczy to różnego typu sprzętu i oprogramowania. Z roku na rok jest ich więcej, niestety również będących tzw. podatnościami typu zero-day. Szybkość działania jest w tym przypadku kluczowa – reakcja od momentu pozyskania informacji o podatności do podjęcia działań mających na celu jej usunięcie. Jeżeli nie jest możliwe usunięcie podatności – wykonanie tymczasowego obejścia problemu. Trudność w skutecznym zaradzeniu wykrytym podatnościom jest tym większa, im bardziej skomplikowaną i rozproszoną infrastrukturą zarządzamy.
Jednak wiele z zarejestrowanych podatności w bazie nvd.nist.gov może dotyczyć naszej infrastruktury. Gdy dodamy do tego podatności wynikające z błędów w konfiguracji, konieczne może okazać się wdrożenie całego procesu zarządzania podatnościami za pomocą specjalistycznego oprogramowania. Nawet w małych i średnich firmach oraz instytucjach możemy mieć do czynienia z dziesiątkami istotnych zasobów IT – od systemów operacyjnych czy aplikacji biznesowych do różnego rodzaju urządzeń mobilnych. W wielu z wykorzystywanych rozwiązaniach informatycznych pojawiają się podatności, które pozostawione mogą stanowić słabość łatwą do wykorzystania przez różnej maści automaty exploitujące i malware. Wykonując skanowanie podatności w niewielkiej infrastrukturze, możemy uzyskać wynik dziesiątek lub nawet setek wykrytych podatności. A ich liczba rośnie w każdym roku.
Administratorzy systemów IT świadomi konieczności zarządzania bezpieczeństwem stosują wytyczne producentów oraz dobre praktyki w celu uzyskania odpowiedniej konfiguracji urządzeń oraz oprogramowania. Jednak ich starania powinny być wspierane przez ciągłe monitorowanie zarówno poprzez skanowanie znanych podatności, jak i sprawdzanie informacji ze źródeł dostępnych na forach i grupach branżowych. Po potwierdzeniu istnienia podatności w naszym środowisku określamy możliwość jej wykorzystania. Uwzględniamy przy tym, jak działające urządzenia oraz systemy bezpieczeństwa minimalizują ryzyko wykorzystania wykrytej podatności.
Czy powinniśmy spodziewać się podatności w wykorzystywanym oprogramowaniu? Błędy w nim występują dosyć często. Ich wykrywanie w trakcie procesu produkcji oprogramowania jest czasochłonne i kosztowne. Duża część błędów powodujących luki w mechanizmach bezpieczeństwa jest niestety wykrywana już po wydaniu finalnej wersji oprogramowania. Staniemy więc przed pytaniem – jak zarządzać taką dużą liczbą podatności? Wykorzystując narzędzia do skanowania oraz pozyskując informacje ze źródeł dostępnych w internecie. Oczywiście używanie skanerów to podstawa, jednak nie powinno to być jedyne zadanie w ramach procesu zarządzania podatnościami. Jak pokazuje przykład podatności Log4j, powinniśmy mieć świadomość wykorzystywanych bibliotek open source i posiadać mechanizmy weryfikacji, czy w naszym oprogramowaniu wykorzystującym jedną z nich nie wykryto błędu biblioteki mogącego prowadzić do naruszenia bezpieczeństwa aplikacji.
> NIE TYLKO LOG4J
Obecnie częstym celem złośliwego oprogramowania są aplikacje webowe oraz urządzenia mobilne. Te pierwsze zlokalizowane w strefach zdemilitaryzowanych są otwarte na próby zainicjowania sesji przez dowolnego użytkownika internetu. W trakcie pracy na porcie TCP/443 aplikacje tego typu są wystawione na ciągłe skanowanie portów, fingerprinting oraz identyfikację słabych punktów. Podatność Log4j ujawniła powszechność stosowania tej biblioteki i ewentualną skalę możliwego wykorzystania wykrytej słabości za pomocą dostępnych od ręki i bardzo użytecznych exploitów.
[…]
Artur Cieślik
Autor jest redaktorem naczelnym miesięcznika „IT Professional”, audytorem CISA oraz audytorem wiodącym normy ISO/IEC 27001 i ISO 22301. Specjalizuje się w realizacji audytów bezpieczeństwa informacji, danych osobowych i zabezpieczeń sieci informatycznych. Jest konsultantem w obszarze architektury bezpieczeństwa i wdrażania Systemów Zarządzania Bezpieczeństwem Informacji. Trener i wykładowca z wieloletnim doświadczeniem.
