Krótko: Zarządzanie podatnościami w średnich firmach i MŚP to szczupły, powtarzalny cykl: znać swoje systemy, śledzić komunikaty w sposób celowany, oceniać według ryzyka, podejmować decyzję, wdrażać i dokumentować. Decydujące nie są drogie narzędzia, lecz jasne odpowiedzialności i priorytetyzacja uwzględniająca dostępność, dane i sytuację ataków. PHP2Shell to dobry przykład do ćwiczeń, ponieważ występują w nim wszystkie te kroki.
Setki komunikatów, mało ludzi
Co tydzień publikowane są nowe luki bezpieczeństwa: w systemach operacyjnych, językach programowania, aplikacjach i wtyczkach. Koncern ma do tego zespół. Średnia firma ma często kierownika IT, jednego lub dwóch administratorów i kilku zewnętrznych usługodawców. Nikt nie jest w stanie przeczytać każdego komunikatu i nie musi.
Potrzebny jest filtr: które komunikaty dotyczą naszych systemów, które z nich są pilne i kto się nimi zajmie? Bez takiego filtra dzieje się jedno z dwojga. Albo wszystko jest ignorowane, aż coś się stanie, albo każdy komunikat wywołuje poruszenie, a naprawdę krytyczny ginie w szumie.
Cykl zarządzania podatnościami
Wytrzymały proces dla MŚP można opisać w sześciu krokach:
- Zarejestrować, co działa. Bez inwentarza nie ma porównania. Jakie strony, serwery, wersje PHP i aplikacje Państwo prowadzą i gdzie? Jak się to udaje, pokazuje artykuł Wiedzieć, co działa: inwentarz wszystkich stron i serwerów.
- Śledzić komunikaty. Zasubskrybować kilka rzetelnych źródeł: ostrzeżenia BSI, komunikaty producentów używanego oprogramowania, strony bezpieczeństwa dystrybucji Linuksa, a w przypadku PHP stronę główną php.net.
- Ocenić. Czy komunikat nas dotyczy? Jeśli tak, jak bardzo jest pilny? Więcej na ten temat poniżej.
- Zdecydować. Usunąć lukę, tymczasowo zabezpieczyć, odizolować system albo świadomie ponieść ryzyko. Kto może o tym decydować?
- Wdrożyć. Zainstalować aktualizację, wprowadzić środek tymczasowy, zlecić pracę usługodawcy.
- Udokumentować i dopilnować. Czy luka naprawdę jest zamknięta? Kiedy rozwiązanie tymczasowe zostanie zastąpione?
Potem cykl zaczyna się od nowa. Pojawiają się nowe systemy, stare znikają i ukazują się nowe komunikaty.
W kroku 2 pomaga prosta zasada: lepiej regularnie czytać kilka źródeł niż od czasu do czasu wiele. W typowym środowisku internetowym średniej firmy zwykle wystarczają komunikaty ostrzegawcze CERT-Bund przy BSI (niemiecki rządowy zespół CERT), komunikaty bezpieczeństwa używanej dystrybucji Linuksa, strony producentów CMS i sklepów oraz strona główna php.net. Proszę ustalić, kto czyta te źródła, i założyć w tym celu wspólną skrzynkę pocztową lub kanał, który nie zależy od jednej osoby.
Warto uzupełnić to spojrzeniem z zewnątrz. Regularne skanowanie podatności publicznie dostępnych systemów pokazuje, czy widoczne jest przestarzałe oprogramowanie lub niepotrzebnie otwarte usługi. Nie zastępuje ono inwentarza ani aktualizacji, ale wykrywa systemy, których nie ma na żadnej liście.
Ocena: co jest pierwsze w kolejce
Wartość CVSS, czyli znormalizowana klasyfikacja stopnia zagrożenia, to dobry punkt wyjścia. Do ustalenia kolejności we własnej firmie jednak nie wystarcza. Rozstrzygają trzy dodatkowe pytania:
| Pytanie | Zwiększa pilność | Zmniejsza pilność |
|---|---|---|
| Czy system jest dostępny z internetu? | publiczna strona, sklep, portal | tylko wewnętrznie, za VPN |
| Czy do wykorzystania luki potrzebne jest logowanie? | nie, bez uwierzytelnienia | tak, tylko dla administratorów |
| Jakie dane przetwarza system? | dane klientów, płatności, dostępy | treści publiczne bez kont |
| Czy są doniesienia o atakach? | zgłoszone próby ataków | brak znanych prób |
| Czy istnieje środek tymczasowy? | nie | tak, z udokumentowanym działaniem |
PHP2Shell pokazuje, jak to się układa w całość. Obie luki mają wartość CVSS v4.0 wynoszącą 9,2, umożliwiają wykonanie kodu bez logowania i dotyczą publicznie dostępnych serwerów WWW. Cloudflare i Patchstack zgłosiły według mediów próby ataków, a BSI oceniło sytuację jako poziom ostrzegawczy 3. Środki tymczasowe z php.net wyraźnie nie zapewniają pełnej ochrony. Wszystkie pytania wskazują ten sam kierunek: działać natychmiast. Co konkretnie zaleciło BSI, opisuje artykuł Co BSI zaleca w sprawie PHP2Shell.
Decydować i dokumentować
Nie każdą lukę da się zamknąć od razu. Stary system działa na PHP 8.1, dla którego nie ma już oficjalnych aktualizacji (zob. PHP 8.1 i starsze: co obowiązuje teraz), a aplikacja branżowa jeszcze nie znosi aktualizacji. Wtedy potrzebna jest decyzja, która nie należy wyłącznie do działu technicznego.
Dobra notatka decyzyjna zawiera dotknięty system, lukę, ocenę, wybraną opcję, środki tymczasowe, osobę odpowiedzialną i termin ponownej kontroli. Jeśli ryzyko jest świadomie ponoszone, decyduje kierownictwo, a nie sam administrator. Także OWASP Cheat Sheet dotyczący postępowania z podatnymi zależnościami zaleca wyraźnie umocować akceptację ryzyka na poziomie kierownictwa.
Proszę prowadzić jedną listę otwartych podatności ze statusem, osobą odpowiedzialną i terminem. Wystarczy tabela. Ważne, aby była regularnie przeglądana, na przykład na miesięcznym spotkaniu z zarządem.
Co z tym wspólnego mają NIS2 i usługodawcy
Dla firm objętych dyrektywą NIS2 postępowanie z podatnościami jest częścią obowiązków w zakresie zarządzania ryzykiem. Szczegóły opisuje artykuł NIS2 a bezpieczeństwo serwera WWW. Ale także bez obowiązku prawnego udokumentowany proces jest zaletą, na przykład wobec klientów, ubezpieczycieli i własnego zarządu.
Wiele kroków można zlecić na zewnątrz, na przykład śledzenie komunikatów lub instalowanie aktualizacji. Decyzja o ryzyku i całościowy przegląd powinny jednak zostać w firmie. Kto oddaje cały cykl usługodawcy, w razie awarii nie wie już, jakie w ogóle ma systemy. Jak zorganizować wdrażanie jako rutynę, opisuje artykuł Zarządzanie poprawkami jako proces, a nie straż pożarna.
Jak konkretnie pomaga PHP SOS?
- Razem z Państwem sporządzamy inwentarz stron i serwerów jako podstawę każdego porównania.
- Śledzimy dla Państwa systemów istotne komunikaty i dostarczamy ocenę jasnym językiem wraz z rekomendacją.
- Przygotowujemy notatki decyzyjne na przypadki, w których aktualizacja nie jest możliwa od razu.
- Za pomocą monitoringu bezpieczeństwa na bieżąco sprawdzamy, czy systemy nie zaczynają zachowywać się podejrzanie, dopóki luka jest otwarta.
Podsumowanie: Zarządzanie podatnościami w średniej firmie nie musi być duże, ale musi być wiążące. Kto zna swoje systemy, czyta kilka dobrych źródeł i zapisuje decyzje, przy następnym krytycznym komunikacie zareaguje szybko i właściwie.
Częste pytania
Czym jest zarządzanie podatnościami?
To powtarzalny proces, w którym firma dowiaduje się o lukach bezpieczeństwa w swoich systemach, ocenia je, usuwa albo świadomie akceptuje i dokumentuje wynik. Nie chodzi o narzędzie, lecz o odpowiedzialności i decyzje.
Czy wartość CVSS wystarczy do ustalania priorytetów?
To dobry punkt wyjścia, ale to za mało. Dodatkowo decyduje, czy dotknięty system jest dostępny z internetu, jakie dane przetwarza i czy ataki są już obserwowane. Luka o wysokiej wartości w wewnętrznym systemie testowym może poczekać, w sklepie internetowym nie.
Czy mała firma potrzebuje do tego własnego narzędzia?
Na początek nie. Wystarczy prowadzona lista systemów, zasubskrybowane komunikaty bezpieczeństwa i tabela z otwartymi punktami. Skanery podatności opłacają się, gdy rośnie liczba systemów lub gdy kontrole trzeba regularnie dokumentować.
Czy można świadomie nie usuwać podatności?
Tak, jeśli ryzyko zostało ocenione, decyzję podjęło odpowiedzialne kierownictwo i została ona zapisana na piśmie, najlepiej wraz ze środkami tymczasowymi i terminem ponownej kontroli.