PHP-hændelsen: Sårbarheder og leverandørkæde

En organisation, der anvender en ekstern hostingudbyder, forventer som udgangspunkt, at leverandøren håndterer sikkerheden i den underliggende infrastruktur. Det er ofte både hensigtsmæssigt og nødvendigt. Leverandøren har den tekniske indsigt, adgangen til systemerne og mulighed for at gennemføre sikkerhedsopdateringer.

Men leverandørens tekniske vurdering og organisationens vurdering af konsekvenserne er to forskellige ting.

En leverandør kan eksempelvis meddele, at der er implementeret midlertidige afværgeforanstaltninger, og at kunderne ikke behøver foretage sig noget. Det er en relevant oplysning, men den fortæller ikke nødvendigvis, om den konkrete tjeneste er berørt, eller hvilken risiko der fortsat eksisterer.

For en organisation, hvor hjemmesiden primært præsenterer virksomhedens ydelser, kan konsekvenserne være begrænsede. For en organisation, hvor den samme teknologi understøtter kritiske forretningsprocesser eller behandling af fortrolige oplysninger, kan situationen være væsentligt mere alvorlig.

En leverandør kan begrænse adgangen til bestemte funktioner, indføre yderligere filtrering eller isolere udsatte komponenter. Sådanne afværgeforanstaltninger kan reducere risikoen, mens der arbejdes på en permanent løsning, men de fjerner ikke nødvendigvis selve sårbarheden.

I forbindelse med PHP-sårbarhederne understregede PHP-projektet i sin officielle sikkerhedsmeddelelse, at midlertidige afværgeforanstaltninger ikke giver fuldstændig beskyttelse, og at sikkerhedsopdateringer er nødvendige.

Det rejser et vigtigt spørgsmål: Hvornår er leverandørens håndtering tilstrækkelig til, at organisationen kan fortsætte driften?

Svaret afhænger af, hvilke systemer der er berørt, hvilke oplysninger de behandler, deres betydning for driften og mulighederne for at begrænse konsekvenserne. En kritisk sårbarhed er ikke nødvendigvis ensbetydende med en uacceptabel risiko for alle organisationer, men leverandørens forsikring om, at situationen håndteres, kan heller ikke stå alene.

Mange organisationer har et overblik over deres væsentligste systemer og leverandører. Det er ikke nødvendigvis det samme som at kende de teknologiske afhængigheder bag de enkelte tjenester.

En hjemmeside kan eksempelvis være afhængig af en hostingudbyder, som anvender bestemte serverkomponenter, softwarebiblioteker og sikkerhedsløsninger. Kunden har ikke nødvendigvis indsigt i disse komponenter eller i, hvordan de opdateres.

Når en sårbarhed offentliggøres, bliver spørgsmålet derfor ikke kun, om organisationen selv anvender den berørte teknologi, men også om teknologien indgår i tjenester hos dens leverandører.

Det kræver ikke fuldt teknisk indblik i alle komponenter hos samtlige leverandører. Organisationen skal derimod kunne identificere sine væsentligste afhængigheder, forstå konsekvenserne af et sikkerhedsproblem og indhente relevante oplysninger fra leverandørerne.

Det er netop her, leverandørstyring og risikostyring mødes.

Leverandørstyring forbindes ofte med kontraktlige krav, sikkerhedserklæringer og indledende risikovurderinger. Men disse elementer fortæller ikke nødvendigvis, hvordan samarbejdet fungerer, når et alvorligt sikkerhedsproblem opstår.

Det er samtidig en del af tankegangen bag NIS2, hvor sikkerhed i leverandørkæden indgår som et væsentligt element i organisationens cybersikkerhedsrisikostyring. For organisationer omfattet af NIS2 handler det ikke alene om at stille sikkerhedskrav til leverandører, men også om at vurdere de risici, der følger af afhængigheden af deres tjenester.

Styrelsen for Samfundssikkerheds vejledninger om NIS2 beskriver blandt andet cybersikkerhedsforanstaltninger og leverandørkædesikkerhed.

I praksis betyder det, at organisationen skal have klare aftaler om sikkerhedsopdateringer, information ved alvorlige sårbarheder og opfølgning på leverandørens håndtering. Hvor omfattende opfølgningen skal være, afhænger af leverancens kritikalitet og den konkrete risiko.

Disse forhold bør være afklaret på forhånd. Ellers risikerer organisationen først at skulle etablere overblik, ansvar og kommunikationsveje, når situationen allerede er akut.

PHP-hændelsen viser, hvordan en teknisk sårbarhed kan udvikle sig til et spørgsmål om organisatorisk ansvar og risikostyring.

Leverandøren kan have ansvaret for at beskytte og opdatere den underliggende teknologi. Organisationen skal imidlertid have tilstrækkelig indsigt i sine afhængigheder til at kunne vurdere konsekvenserne og træffe nødvendige beslutninger.

For selv om en organisation kan overlade den tekniske sikkerhedshåndtering til en leverandør, kan den ikke overlade ansvaret for sine egne risici.