Kort sagt: ISO 27001 og TISAX berører webservere især gennem tre krav: Sårbarheder skal opdages og behandles, leverandører som hostingudbydere og bureauer skal styres, og sikkerhedshændelser kræver et reguleret forløb. En situation som PHP2Shell er en praksistest for ethvert ISMS. Den, der dokumenterer vurdering, patch og genstart forståeligt, har et godt grundlag til næste audit. Et certifikat eller label erstatter ikke patchen.
Hvad ISO 27001 og TISAX er, i to afsnit
ISO/IEC 27001 beskriver kravene til et ledelsessystem for informationssikkerhed, kort ISMS. Det drejer sig om et ordnet kredsløb: vurdere risici, fastlægge foranstaltninger, gennemføre, kontrollere og forbedre. Den aktuelle udgave fra 2022 indeholder i bilag A et katalog med 93 foranstaltninger i fire temaer. Hvilke af dem der gælder, afgør virksomheden på grundlag af sin risikovurdering og fastholder det i erklæringen om anvendelighed.
TISAX er den prøvnings- og udvekslingsmekanisme, der er udbredt i bilindustrien. Den styres af ENX Association, grundlaget er kravkataloget ISA, som ENX vedligeholder, og som VDA offentliggør. Uafhængige prøvningsleverandører gennemfører en assessment, hvis omfang afhænger af beskyttelsesbehovet og rækker fra dokumentgennemgange til besøg på stedet. Resultaterne tildeles ifølge ENX som labels, gælder i tre år og deles via ENX-portalen kun med udvalgte partnere.
ISO 27001 på webserveren: Hvilke krav gælder?
En webserver er sjældent et eget kapitel i ISMS'et. Den dukker op flere steder, og netop dér opstår hullerne. Det følgende overblik ordner de vigtigste temaer generelt. Det erstatter ikke et blik i jeres egen erklæring om anvendelighed.
| Tema i ISMS'et | Hvad det betyder for webserveren | Dokumentation, der hjælper i auditten |
|---|---|---|
| Fortegnelse over aktiver | Hvert website, hver server, hver PHP-version er registreret | Aktuel liste med driftsansvarlig, version, ansvarlig |
| Håndtering af tekniske sårbarheder | Meldinger som PHP2Shell vurderes og behandles | Ticket med vurdering, beslutning, patch-dato |
| Leverandørforhold | Hostingudbyder og bureau har klare sikkerhedspligter | Kontrakt, arbejdsdeling, skriftlig bekræftelse af patch-status |
| Logføring og overvågning | Webserverlogs opbevares og evalueres | Opbevaringsregel, eksempel på en evaluering |
| Hændelsesstyring | Mistanke meldes, vurderes og afsluttes | Hændelsesprotokol, lessons learned |
| Konfigurationsstyring | PHP- og webserverindstillinger er fastlagt | Soll-konfiguration og afvigelseskontrol |
Ved TISAX gælder sammenlignelige temaer, fordi ISA-kataloget er afstemt med andre betydelige standarder. Desuden kræver nogle prøvningsmål, f.eks. beskyttelse af prototyper, særlig omhu ved systemer, over hvilke partnere udveksler data. Det kan også være portaler på PHP-basis.
PHP2Shell som praksistest for ISMS'et
Den 21.10.2026 udgav PHP-projektet versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Til PHP 8.1 og ældre findes der ikke længere officielle opdateringer. Et fungerende ISMS bør i denne situation udløse en kæde, som senere kan dokumenteres.
- Indgang: Hvem har modtaget meldingen hvornår, og hvor er den registreret?
- Vurdering: Hvilke systemer er berørt? Det forudsætter en aktuel oversigt, se Vid, hvad der kører.
- Beslutning: Patch, midlertidig foranstaltning eller midlertidig nedlukning, med begrundelse og navnet på den beslutningstagende person.
- Gennemførelse: Pakkestatus, genstart af alle PHP-processer, kontrol. Ved distributionens backports tæller pakkens changelog, ikke det viste versionsnummer; hvordan man dokumenterer det, viser Kontrollér PHP-version og patchstatus korrekt.
- Leverandører: Skriftlig bekræftelse fra hostingudbyderen om, at der er patchet og genstartet.
- Efterkontrol: Undersøgelse for tegn på kompromittering siden 17.10.2026, fordi en patch ikke gør tidligere indbrud ugjort.
Hvordan I gør denne engangskæde til et varigt forløb, beskriver Sårbarhedshåndtering for mindre og mellemstore virksomheder og Patch management som proces.
Hyppige svagheder i dokumentationen
I praksis strander dokumentationen sjældent på teknikken, men på huller i kæden. Typisk er et website, som en fagafdeling driver sammen med et bureau, og som mangler i oversigten. Lige så hyppige er hostingkontrakter uden udsagn om, hvor hurtigt sikkerhedsopdateringer indspilles, og om kunder informeres.
En anden klassiker: Patch-ticketten er lukket, men ingen har genstartet PHP-processerne. Formelt er punktet afsluttet, teknisk kører den gamle kode videre. Et godt bilag indeholder derfor ikke kun "opdatering indspillet", men også genstarten og en kontrol bagefter.
Det bliver også vanskeligt ved systemer, der ikke kan patches med det samme, f.eks. en applikation på PHP 8.1. Her kræver et ISMS ingen mirakler, men en bevidst beslutning: Hvilke midlertidige foranstaltninger gælder, hvem har accepteret den resterende risiko, og hvornår er skiftet planlagt? En skriftlig risikoaccept med udløbsdato er i auditten klart bedre end et stiltiende videreløbende ældre system. Lige så vigtige er logs. Fagpressen og fagforfattere rådede efter PHP2Shell til at opbevare serverlogs fra og med 20.10.2026. Om jeres opbevaringsregel rækker til det, og om logs ligger hos hostingudbyderen eller hos jer, bør være afklaret før næste hændelse, ikke undervejs.
Hvis jeres virksomhed desuden er omfattet af NIS2, forstærkes disse krav. Hovedtrækkene står under NIS2 og webserversikkerhed. Det er generel information, ikke juridisk rådgivning.
Et certifikat eller label beskriver et ledelsessystems tilstand på prøvningstidspunktet. Det beskytter ingen enkelt server mod en ny sårbarhed. Det afgørende er, at forløbet faktisk virker i en nødsituation.
Hvordan hjælper PHP SOS konkret?
- Vi registrerer jeres webservere og PHP-installationer, så de passer ind i oversigten i jeres ISMS.
- Vi patcher og dokumenterer med vores PHP-patchservice: pakkestatus, genstart, kontrol, med dato og bilag.
- Vi formulerer spørgsmålene til hostingudbydere og bureauer og vurderer deres svar til jeres leverandørstyring.
- Vi leverer de tekniske fakta til jeres ISMS-ansvarlige. Vurderingen i ledelsessystemet og auditten forbliver hos jer og jeres prøvningsorgan.
Konklusion
ISO 27001 og TISAX kræver ikke en bestemt webserver, men en forståelig omgang med den. PHP2Shell viser, om oversigt, sårbarhedsbehandling og leverandørstyring spiller sammen. Den, der dokumenterer kæden af indgang, vurdering, patch, genstart og efterkontrol rent, har ikke kun auditten, men frem for alt serveren under kontrol.
Ofte stillede spørgsmål
Hører virksomhedens website med i anvendelsesområdet for en ISO 27001?
Det afhænger af, hvordan jeres virksomhed har fastlagt anvendelsesområdet. Behandler websitet kundedata, er det forbundet med interne systemer, eller drives det af en leverandør, taler meget for at inddrage det eller i det mindste at registrere det via leverandørstyringen.
Er TISAX et certifikat?
ENX Association taler om en assessment gennem uafhængige prøvningsleverandører, hvis resultater tildeles som TISAX-labels. Labelsene gælder ifølge ENX i tre år og deles målrettet med partnere via ENX-portalen, de er ikke offentlige.
Skal jeg efter PHP2Shell informere min auditor?
Der findes ingen generel pligt til det. Jeres ISMS bør dog dokumentere, hvordan I har vurderet og behandlet sårbarheden. Disse dokumenter gennemgås typisk i næste audit.
Hvilken version af ISO 27001 er aktuel?
Afgørende er udgaven ISO/IEC 27001:2022. Dens bilag A ordner foranstaltningerne i fire temaer: organisatorisk, personrelateret, fysisk og teknologisk.