Kort sagt: Ved cybersikkerhed i logistikken handler det om portaler, der er brug for døgnet rundt: sporing af forsendelser, tidsvinduesbooking, ordreindtastning. Afklar, hvilke af dem der kører på PHP, lad rettelse og genstart bekræfte, og hold en manuel erstatningsvej klar, hvis en portal midlertidigt må tages af nettet.
Hvilke PHP-systemer der kører i logistik og spedition
Selve transportstyringssystemet er ofte en branchesoftware med egen drift. Rundt om det opstår webapplikationer, der ofte bygger på PHP: kundeportaler til ordreindtastning og sporing af forsendelser, tidsvindues- og rampebooking til leverandører og vognmænd, portaler til underleverandører, afleveringsbeviser med foto-upload, skadesanmeldelser og karrieresider til chauffører.
Mange af disse applikationer er egenudviklinger på basis af frameworks eller kører i containere. Ved containere sidder PHP i imaget. Hvordan man opdaterer rigtigt dér, beskriver siden Patch PHP i Docker-containere.
Hvilke data der ligger i logistikportaler
I logistikportaler ligger leverings- og afhentningsadresser, forsendelsesindhold og varværdier, tidsvinduer, nummerplader, chaufførnavne og telefonnumre, kundevilkår og afregningsdata. Via grænseflader er portalerne forbundet med TMS, lagerstyring, telematik og opdragsgivernes systemer.
Denne blanding er særligt værdifuld for angribere. Den, der ved, hvornår hvilken værdifuld last står ved hvilken rampe, kan forberede tyveri eller forfalskede afhentninger. Adgangsdata til grænseflader åbner desuden vejen til partnere i forsyningskæden.
Også chaufførdata fortjener opmærksomhed. Karrieresider og underleverandørportaler indeholder kopier af kørekort, dokumentation for kvalifikationer og kontaktdata, delvis fra chauffører i udlandet, som ved misbrug af deres data næppe finder støtte. Den, der samler disse dokumenter på webserveren, bør ikke opbevare dem dér længere end nødvendigt.
Logistik og cybersikkerhed: følger af en hændelse
- Stilstand ved rampen: Falder tidsvinduesbookingen ud, hober køretøjer sig op, og forsyningskæder går i stå.
- Manipulerede ordrer: En angriber med adgang til portalen kan ændre leveringsadresser eller afhentningsberettigelser.
- Forsyningskæde: Opdragsgivere forlanger oplysning om, hvorvidt deres data eller grænseflader er berørt. Under NIS2 kommer der for berørte virksomheder anmeldelsespligter til.
- Tillid: I en branche med tætte partnerskaber rygtes en hændelse hurtigt.
Kan ingen bekræfte, at PHP på jeres portalserver er patchet og genstartet, så tag portalen af nettet og skift til den manuelle erstatningsvej. Indtil rettelsen kan virtuel patching være en bro, men erstatter ikke opdateringen.
Typiske ansvarshuller i logistikvirksomheder
| System | Ofte passet af | Åbent spørgsmål |
|---|---|---|
| TMS og lagerstyring | Softwareudbyder | Hvilke webkomponenter bruger PHP? |
| Kunde- og tidsvinduesportal | Egenudvikling eller tjenesteudbyder | Hvem patcher image eller server? |
| Website og karriereside | Bureau og hostingudbyder | PHP-status bekræftet? |
| Grænseflader til opdragsgivere | It-afdeling | Hvilke adgangsdata ligger på webservere? |
I speditionsvirksomheder med flere lokationer kommer lokale løsninger til, som en filial selv har sat op, og som ikke står i noget centralt register.
Partneradgange: mange konti, lidt overblik
Logistikportaler lever af eksterne brugere: vognmænd, underleverandører, leverandører, kunder med flere lokationer. Over årene opstår der således hundredvis af konti, hvoraf mange er delte, forladte eller beskyttet med enkle adgangskoder. En angriber, der udfører kode på serveren, har ikke brug for disse konti, men kan oprette nye eller udvide rettighederne på eksisterende konti, uden at det opdages.
Undersøg derfor efter en hændelse også brugerstyringen: Hvilke konti er senest oprettet eller ændret, hvilke har udvidede rettigheder, hvilke er ikke brugt i flere måneder? Forladte konti bør I spærre, administratoradgange sikre med en anden faktor. Det hører også med i koordineringen med opdragsgivere, der har adgang til jeres portaler.
De første timer for it-ledelse og direktion
- List alle eksternt tilgængelige portaler, inklusive container-applikationer og filialernes løsninger.
- Lad for hvert system dokumentere PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 hhv. en bekræftet backport og genstart af alle processer.
- Sikr logs fra 20.10.2026. Henvisninger til analysen giver vejledningen Analysér webserverlogs.
- Forny adgangsdata til grænseflader, der er gemt på webservere, efter oprydningen.
- Informér vigtige opdragsgivere sagligt, så snart status er dokumenteret.
Hvordan hjælper PHP SOS konkret?
- Vi registrerer jeres portaler og grænseflader og prioriterer efter driftsform, PHP-version og betydning for driften.
- Vi patcher eller koordinerer opdateringer med softwareudbydere og tjenesteudbydere, bygger container-images om og dokumenterer genstarten.
- Ved mistanke overtager vi incident response med sikring af spor og kontrol af, om ordrer eller grænseflader er manipuleret.
- Vi leverer en kortfattet, dokumenterbar dokumentation, som I kan forelægge for opdragsgivere, forsikringsselskaber og eventuelt myndigheder.
Ofte stillede spørgsmål
Hvorfor er forsendelsesdata interessante for angribere?
Forsendelsesdata afslører, hvilken vare der hvornår står hvor, og hvem der henter den. Sådanne oplysninger kan bruges til lasttyveri, forfalskede afhentningsordrer eller svindel med falske vognmænd. Dertil kommer kundestamdata og vilkår, som er værdifulde for konkurrenter.
Falder vores spedition ind under NIS2?
Transportsektoren hører til de områder, som NIS2 omfatter, men om en virksomhed faktisk er berørt, afhænger af aktivitet og størrelse. Også uden direkte pligt videregiver opdragsgivere sikkerhedskrav via aftaler. Den bindende vurdering afklarer I med jeres juridiske rådgivning.
Hvordan fortsætter driften, når portalen er offline?
Hold en manuel erstatningsvej klar: tidsvinduer pr. telefon eller mail, statusmeddelelser via en forberedt udsendelsesliste, afhentningsnumre på papir. En planlagt erstatningsvej forhindrer, at medarbejdere under pres tager usikre genveje.
Vores PHP-applikationer kører i containere. Ændrer det noget?
Også i containere sidder PHP i imaget. I skal opdatere basis-imaget, bygge det om og udskifte de kørende containere. En opdatering alene på værten ændrer intet ved PHP i containeren.