Krótko: ISO 27001 i TISAX dotyczą serwerów WWW szczególnie przez trzy wymagania: podatności muszą być wykrywane i obsługiwane, dostawcy tacy jak firmy hostingowe i agencje muszą być nadzorowani, a incydenty bezpieczeństwa wymagają uregulowanego przebiegu. Sytuacja taka jak PHP2Shell jest dla każdego SZBI sprawdzianem w praktyce. Kto czytelnie udokumentuje ocenę, poprawkę i restart, ma dobrą podstawę do następnego audytu. Certyfikat ani etykieta nie zastępują poprawki.
Czym są ISO 27001 i TISAX, w dwóch akapitach
ISO/IEC 27001 opisuje wymagania wobec systemu zarządzania bezpieczeństwem informacji, w skrócie SZBI. Chodzi o uporządkowany cykl: ocenić ryzyka, ustalić środki, wdrożyć, sprawdzić i doskonalić. Aktualna edycja z 2022 roku zawiera w załączniku A katalog 93 środków w czterech tematach. Które z nich obowiązują, decyduje firma na podstawie oceny ryzyka i zapisuje to w deklaracji stosowania.
TISAX to rozpowszechniony w przemyśle motoryzacyjnym mechanizm badania i wymiany wyników. Zarządza nim ENX Association, podstawą jest katalog wymagań ISA, który utrzymuje ENX, a publikuje VDA (niemieckie Stowarzyszenie Przemysłu Motoryzacyjnego). Niezależni usługodawcy badawczy przeprowadzają ocenę, której zakres zależy od potrzeby ochrony i sięga od kontroli dokumentów po wizyty na miejscu. Wyniki są według ENX nadawane jako etykiety, obowiązują trzy lata i są udostępniane przez portal ENX tylko wybranym partnerom.
ISO 27001 a serwer WWW: jakie wymagania obowiązują?
Serwer WWW rzadko jest w SZBI osobnym rozdziałem. Pojawia się w kilku miejscach i właśnie tam powstają luki. Poniższy przegląd ogólnie przyporządkowuje najważniejsze tematy. Nie zastępuje spojrzenia do Państwa własnej deklaracji stosowania.
| Temat w SZBI | Co to oznacza dla serwera WWW | Dowód pomocny w audycie |
|---|---|---|
| Inwentarz aktywów | Każda strona, każdy serwer, każda wersja PHP jest zarejestrowana | Aktualna lista z operatorem, wersją, osobą odpowiedzialną |
| Postępowanie z podatnościami technicznymi | Komunikaty takie jak PHP2Shell są oceniane i obsługiwane | Zgłoszenie z oceną, decyzją, datą poprawki |
| Relacje z dostawcami | Firma hostingowa i agencja mają jasne obowiązki w zakresie bezpieczeństwa | Umowa, podział zadań, pisemne potwierdzenie stanu poprawek |
| Rejestrowanie i monitorowanie | Logi serwera WWW są przechowywane i analizowane | Zasada przechowywania, przykład analizy |
| Zarządzanie incydentami | Podejrzenie jest zgłaszane, oceniane i zamykane | Protokół incydentu, lessons learned |
| Zarządzanie konfiguracją | Ustawienia PHP i serwera WWW są określone | Konfiguracja docelowa i kontrola odchyleń |
W TISAX obowiązują porównywalne tematy, ponieważ katalog ISA jest uzgodniony z innymi ważnymi standardami. Dodatkowo niektóre cele kontroli, na przykład ochrona prototypów, wymagają szczególnej staranności przy systemach, przez które partnerzy wymieniają dane. Mogą to być także portale oparte na PHP.
PHP2Shell jako sprawdzian SZBI w praktyce
21.10.2026 projekt PHP opublikował wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji. Działający SZBI powinien w takiej sytuacji uruchomić łańcuch, który da się później udokumentować.
- Wpływ: Kto otrzymał komunikat i kiedy, i gdzie jest on zarejestrowany?
- Ocena: Które systemy są dotknięte? Wymaga to aktualnego inwentarza, zob. Wiedzieć, co działa.
- Decyzja: Poprawka, środek tymczasowy lub czasowe wyłączenie, z uzasadnieniem i nazwiskiem osoby decydującej.
- Wdrożenie: Stan pakietu, restart wszystkich procesów PHP, kontrola. Przy backportach dystrybucji liczy się dziennik zmian pakietu, a nie wyświetlany numer wersji; jak to wykazać, pokazuje artykuł Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
- Dostawcy: Pisemne potwierdzenie firmy hostingowej, że poprawki zainstalowano i dokonano restartu.
- Kontrola końcowa: Sprawdzenie pod kątem oznak kompromitacji od 17.10.2026, ponieważ poprawka nie cofa wcześniejszych włamań.
Jak z tego jednorazowego łańcucha uczynić trwały przebieg, opisują artykuły Zarządzanie podatnościami w średnich firmach i Zarządzanie poprawkami jako proces.
Częste słabości w dokumentacji
W praktyce dowód rzadko zawodzi z powodu techniki, a częściej przez luki w łańcuchu. Typowa jest strona, którą prowadzi dział merytoryczny z agencją i której brakuje w inwentarzu. Równie częste są umowy z firmą hostingową bez wypowiedzi o tym, jak szybko instalowane są aktualizacje bezpieczeństwa i czy klienci są informowani.
Kolejny klasyk: zgłoszenie poprawki jest zamknięte, ale nikt nie zrestartował procesów PHP. Formalnie punkt jest załatwiony, technicznie nadal działa stary kod. Dobry dowód zawiera więc nie tylko „aktualizację zainstalowano”, lecz także restart i kontrolę po nim.
Trudno jest też w przypadku systemów, których nie da się od razu załatwić, na przykład aplikacji na PHP 8.1. SZBI nie wymaga tu cudów, lecz świadomej decyzji: jakie środki tymczasowe obowiązują, kto zaakceptował pozostałe ryzyko i do kiedy zaplanowano przejście? Pisemna akceptacja ryzyka z datą wygaśnięcia jest w audycie wyraźnie lepsza niż po cichu działający stary system. Podobnie ważne są logi. Prasa branżowa i autorzy fachowi radzili po PHP2Shell przechowywać logi serwera od 20.10.2026. To, czy Państwa zasada przechowywania na to pozwala i czy logi leżą u firmy hostingowej, czy u Państwa, należy wyjaśnić przed następnym incydentem, a nie w jego trakcie.
Jeśli Państwa firma podlega dodatkowo NIS2, wymagania te się wzmacniają. Podstawowe zasady podaje artykuł NIS2 a bezpieczeństwo serwera WWW. To ogólna informacja, nie porada prawna.
Certyfikat lub etykieta opisuje stan systemu zarządzania w momencie badania. Nie chroni pojedynczego serwera przed nową luką. Decydujące jest, aby przebieg w razie awarii faktycznie zadziałał.
Jak konkretnie pomaga PHP SOS?
- Rejestrujemy Państwa serwery WWW i instalacje PHP tak, aby pasowały do inwentarza Państwa SZBI.
- Łatamy i dokumentujemy w ramach naszej usługi poprawek PHP: stan pakietu, restart, kontrola, z datą i dowodami.
- Formułujemy pytania do firm hostingowych i agencji i oceniamy ich odpowiedzi na potrzeby Państwa zarządzania dostawcami.
- Dostarczamy osobie odpowiedzialnej za SZBI fakty techniczne. Ocena w systemie zarządzania i audyt pozostają po stronie Państwa i Państwa jednostki badawczej.
Podsumowanie
ISO 27001 i TISAX nie wymagają konkretnego serwera WWW, ale zrozumiałego postępowania z nim. PHP2Shell pokazuje, czy inwentarz, obsługa podatności i nadzór nad dostawcami współgrają. Kto czytelnie udokumentuje łańcuch: wpływ, ocena, poprawka, restart i kontrola końcowa, ma pod kontrolą nie tylko audyt, ale przede wszystkim serwer.
Częste pytania
Czy strona internetowa firmy należy do zakresu stosowania ISO 27001?
To zależy od tego, jak Państwa firma określiła zakres stosowania. Jeśli strona przetwarza dane klientów, jest połączona z systemami wewnętrznymi lub prowadzi ją usługodawca, wiele przemawia za jej włączeniem albo przynajmniej ujęciem w zarządzaniu dostawcami.
Czy TISAX to certyfikat?
ENX Association mówi o ocenie (assessment) przeprowadzanej przez niezależnych usługodawców badawczych, której wyniki są nadawane jako etykiety TISAX. Według ENX etykiety obowiązują trzy lata i są celowo udostępniane partnerom przez portal ENX, nie są publiczne.
Czy po PHP2Shell muszę poinformować audytora?
Ogólnego obowiązku w tym zakresie nie ma. Państwa SZBI powinien jednak dokumentować, jak oceniono i potraktowano tę podatność. Te dokumenty zwykle są przeglądane podczas następnego audytu.
Jaka wersja ISO 27001 jest aktualna?
Miarodajna jest edycja ISO/IEC 27001:2022. Jej załącznik A porządkuje środki w czterech tematach: organizacyjnym, dotyczącym ludzi, fizycznym i technologicznym.