Kort sagt: ISO 27001 och TISAX berör webbservrar framför allt genom tre krav: Sårbarheter måste upptäckas och hanteras, leverantörer som hostingleverantörer och byråer måste styras, och säkerhetsincidenter behöver ett reglerat förlopp. Ett läge som PHP2Shell är ett praktiskt prov för varje ISMS. Den som dokumenterar bedömning, patch och omstart spårbart har en god grund inför nästa revision. Ett certifikat eller en märkning ersätter inte patchen.
Vad ISO 27001 och TISAX är, i två stycken
ISO/IEC 27001 beskriver kraven på ett ledningssystem för informationssäkerhet, kort ISMS. Det avser en ordnad cykel: bedöma risker, fastställa åtgärder, genomföra, kontrollera och förbättra. Den aktuella utgåvan från 2022 innehåller i bilaga A en katalog med 93 åtgärder i fyra teman. Vilka av dem som gäller avgör företaget på grundval av sin riskbedömning och dokumenterar det i tillämplighetsförklaringen.
TISAX är den kontroll- och utbytesmekanism som är utbredd i bilindustrin. Den styrs av ENX Association, grunden är kravkatalogen ISA, som ENX underhåller och VDA publicerar. Oberoende granskningsleverantörer genomför en bedömning vars omfattning beror på skyddsbehovet och sträcker sig från dokumentgranskning till besök på plats. Resultaten tilldelas enligt ENX som märkningar (labels), gäller i tre år och delas via ENX-portalen bara med utvalda partner.
ISO 27001 vid webbservern: vilka krav gäller?
En webbserver är sällan ett eget kapitel i ISMS. Den dyker upp på flera ställen, och det är just där luckor uppstår. Följande översikt ordnar de viktigaste temana i allmänna ordalag. Den ersätter inte en blick i er egen tillämplighetsförklaring.
| Tema i ISMS | Vad det betyder för webbservern | Underlag som hjälper vid revisionen |
|---|---|---|
| Förteckning över tillgångar | Varje webbplats, varje server, varje PHP-version är registrerad | Aktuell lista med driftansvarig, version, ansvarig person |
| Hantering av tekniska sårbarheter | Meddelanden som PHP2Shell bedöms och hanteras | Ärende med bedömning, beslut, patchdatum |
| Leverantörsrelationer | Hostingleverantör och byrå har tydliga säkerhetsskyldigheter | Avtal, arbetsfördelning, skriftlig bekräftelse av patchstatus |
| Loggning och övervakning | Webbserverns loggar bevaras och utvärderas | Regel för bevarande, exempel på en utvärdering |
| Incidenthantering | Misstanke rapporteras, bedöms och avslutas | Incidentprotokoll, lessons learned |
| Konfigurationshantering | PHP- och webbserverinställningar är fastställda | Målkonfiguration och avvikelsekontroll |
Vid TISAX gäller jämförbara teman eftersom ISA-katalogen är samordnad med andra betydande standarder. Dessutom kräver vissa kontrollmål, till exempel skydd av prototyper, särskild omsorg om system via vilka partner utbyter data. Det kan också vara portaler baserade på PHP.
PHP2Shell som praktiskt prov för ISMS
Den 21.10.2026 publicerade PHP-projektet versionerna 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre. Ett fungerande ISMS bör i det läget utlösa en kedja som senare går att belägga.
- Ankomst: Vem fick meddelandet när, och var är det registrerat?
- Bedömning: Vilka system berörs? Det förutsätter en aktuell förteckning, se Veta vad som körs.
- Beslut: Patch, övergångsåtgärd eller tillfällig avstängning, med motivering och namn på den som beslutar.
- Genomförande: Paketstatus, omstart av alla PHP-processer, kontroll. Vid distributionens backporter räknas paketets changelog, inte det visade versionsnumret; hur man styrker det visar Kontrollera PHP-version och patchstatus på rätt sätt.
- Leverantörer: Skriftlig bekräftelse från hostingleverantören att patchen installerats och omstart gjorts.
- Efterkontroll: Kontroll av tecken på komprometterande sedan 17.10.2026, eftersom en patch inte gör tidigare intrång ogjorda.
Hur ni gör denna engångskedja till ett varaktigt förlopp beskriver Sårbarhetshantering för medelstora företag och Patchhantering som process.
Vanliga svagheter i dokumentationen
I praktiken stupar underlaget sällan på tekniken utan på luckor i kedjan. Typiskt är en webbplats som en fackavdelning driver med en byrå och som saknas i förteckningen. Lika vanliga är hostingavtal utan någon uppgift om hur snabbt säkerhetsuppdateringar installeras och om kunder informeras.
En annan klassiker: Patchärendet är stängt men ingen har startat om PHP-processerna. Formellt är punkten avklarad, tekniskt körs den gamla koden vidare. Ett bra underlag innehåller därför inte bara ”uppdatering installerad” utan också omstarten och en kontroll efteråt.
Svårt blir det också med system som inte går att patcha direkt, till exempel en applikation på PHP 8.1. Här kräver ett ISMS inga underverk men ett medvetet beslut: Vilka övergångsåtgärder gäller, vem har godtagit den kvarstående risken och till när är övergången planerad? En skriftlig riskacceptans med utgångsdatum är vid revisionen klart bättre än ett äldre system som tyst fortsätter att köras. Lika viktiga är loggarna. Fackpressen och fackförfattare rådde efter PHP2Shell att bevara serverloggar från och med 20.10.2026. Om er regel för bevarande räcker till för det och om loggarna ligger hos hostingleverantören eller hos er bör vara klarlagt före nästa incident, inte under den.
Om ert företag dessutom omfattas av NIS2 förstärks dessa krav. Grunddragen står under NIS2 och säkerhet för webbservrar. Det är allmän information, ingen juridisk rådgivning.
Ett certifikat eller en märkning beskriver ett ledningssystems tillstånd vid granskningstillfället. Det skyddar ingen enskild server mot en ny lucka. Avgörande är att förloppet verkligen fungerar i ett skarpt läge.
Hur hjälper PHP SOS konkret?
- Vi registrerar era webbservrar och PHP-installationer så att de passar in i förteckningen i ert ISMS.
- Vi patchar och dokumenterar med vår PHP-patchtjänst: paketstatus, omstart, kontroll, med datum och underlag.
- Vi formulerar frågorna till hostingleverantörer och byråer och bedömer deras svar för er leverantörshantering.
- Vi levererar de tekniska fakta till er ISMS-ansvariga. Bedömningen i ledningssystemet och revisionen ligger kvar hos er och ert granskningsorgan.
Slutsats
ISO 27001 och TISAX kräver ingen särskild webbserver men ett spårbart sätt att hantera den. PHP2Shell visar om förteckning, sårbarhetshantering och leverantörsstyrning samverkar. Den som belägger kedjan av ankomst, bedömning, patch, omstart och efterkontroll på ett rent sätt har inte bara revisionen utan framför allt servern under kontroll.
Vanliga frågor
Hör företagets webbplats till tillämpningsområdet för en ISO 27001?
Det beror på hur ert företag har fastställt tillämpningsområdet. Behandlar webbplatsen kunduppgifter, är den ansluten till interna system eller drivs den av en leverantör talar mycket för att inkludera den eller åtminstone fånga den genom leverantörshanteringen.
Är TISAX ett certifikat?
ENX Association talar om en bedömning (assessment) av oberoende granskningsleverantörer, vars resultat tilldelas som TISAX-märkningar (labels). Märkningarna gäller enligt ENX i tre år och delas via ENX-portalen riktat med partner, de är inte offentliga.
Måste jag informera min revisor efter PHP2Shell?
Någon allmän skyldighet till det finns inte. Ert ISMS bör dock dokumentera hur ni har bedömt och hanterat sårbarheten. Dessa underlag granskas typiskt vid nästa revision.
Vilken version av ISO 27001 gäller i dag?
Avgörande är utgåvan ISO/IEC 27001:2022. Dess bilaga A ordnar åtgärderna i fyra teman: organisatoriska, personrelaterade, fysiska och teknologiska.