Kort sagt: Sårbarhetshantering i medelstora företag och SMF är en smal, återkommande cykel: känna till systemen, följa varningar på ett riktat sätt, bedöma efter risk, besluta, genomföra och dokumentera. Avgörande är inte dyra verktyg utan tydligt ansvar och en prioritering som tar hänsyn till nåbarhet, data och hotbild. PHP2Shell är ett bra övningsexempel eftersom alla stegen ingår.
Hundratals varningar, lite personal
Varje vecka publiceras nya säkerhetsluckor i operativsystem, programmeringsspråk, applikationer och tillägg. En koncern har ett team för detta. Ett medelstort företag har ofta en IT-chef, en eller två administratörer och flera externa leverantörer. Ingen kan läsa varje varning, och det behöver heller ingen göra.
Det som behövs är ett filter: Vilka varningar berör våra system, vilka av dem är brådskande och vem tar hand om dem? Saknas filtret händer en av två saker. Antingen ignoreras allt tills något inträffar, eller så väcker varje varning oro och den verkligt kritiska drunknar i bruset.
Sårbarhetshanteringens cykel
Ett hållbart förlopp för SMF kan beskrivas i sex steg:
- Kartlägga vad som körs. Utan förteckning ingen avstämning. Vilka webbplatser, servrar, PHP-versioner och applikationer driver ni, och var? Hur det går till visar Veta vad som körs: förteckning över alla webbplatser och servrar.
- Följa varningar. Prenumerera på få, pålitliga källor: varningar från BSI (tyska förbundskontoret för informationssäkerhet), meddelanden från tillverkarna av er programvara, säkerhetssidorna för er Linux-distribution och, för PHP, startsidan på php.net.
- Bedöma. Berör varningen oss? Om ja, hur brådskande är den? Mer om detta nedan.
- Besluta. Åtgärda, tillfälligt skydda, isolera systemet eller medvetet bära risken. Vem får besluta vad?
- Genomföra. Installera uppdateringen, sätta in en övergångsåtgärd, anlita en leverantör.
- Styrka och följa upp. Är luckan verkligen stängd? När ersätts en övergångslösning?
Därefter börjar cykeln om. Nya system tillkommer, gamla försvinner och nya varningar dyker upp.
För steg 2 hjälper en enkel regel: hellre läsa få källor regelbundet än många då och då. För en typisk medelstor webbmiljö räcker oftast varningarna från CERT-Bund (den tyska statens CERT) vid BSI, säkerhetsmeddelandena för den Linux-distribution ni använder, sidorna från CMS- och shopptillverkarna samt startsidan på php.net. Bestäm vem som läser dessa källor och inrätta en gemensam brevlåda eller kanal som inte hänger på en enskild person.
Det lönar sig också att titta utifrån. En regelbunden sårbarhetsskanning av de offentligt nåbara systemen visar om föråldrad programvara eller onödigt öppna tjänster syns. Den ersätter varken förteckning eller uppdateringar, men avslöjar system som inte står på någon lista.
Bedöma: vad som kommer först
CVSS-värdet, en standardiserad gradering av allvarlighetsgrad, är en bra utgångspunkt. För ordningen i det egna huset räcker det dock inte. Tre ytterligare frågor avgör:
| Fråga | Ökar brådskan | Minskar brådskan |
|---|---|---|
| Kan systemet nås från internet? | offentlig webbplats, webbshop, portal | endast internt, bakom VPN |
| Krävs inloggning för att utnyttja luckan? | nej, oautentiserat | ja, endast för administratörer |
| Vilka data hanterar systemet? | kunduppgifter, betalningar, inloggningar | offentligt innehåll utan konton |
| Finns det rapporter om angrepp? | angreppsförsök rapporterade | inga kända försök |
| Finns det en övergångsåtgärd? | nej | ja, med styrkt effekt |
PHP2Shell visar hur detta samspelar. Båda luckorna har ett CVSS-v4.0-värde på 9.2, tillåter kodkörning utan inloggning och berör offentligt nåbara webbservrar. Cloudflare och Patchstack rapporterade enligt medierna om angreppsförsök, och BSI bedömde läget som varningsnivå 3. Övergångsåtgärderna från php.net ger uttryckligen inget fullständigt skydd. Alla frågor pekar åt samma håll: agera direkt. Vad BSI konkret rekommenderade framgår av Vad BSI rekommenderar om PHP2Shell.
Besluta och dokumentera
Inte varje lucka går att stänga direkt. Ett äldre system körs på PHP 8.1, för vilket det inte längre finns några officiella uppdateringar (se PHP 8.1 och äldre: vad som gäller nu), och en verksamhetsapplikation tål ännu inte uppdateringen. Då behövs ett beslut, och det hör inte hemma enbart hos tekniken.
En bra beslutsnotering innehåller det berörda systemet, luckan, bedömningen, det valda alternativet, övergångsåtgärder, ansvarig person och ett datum för ny prövning. Bärs en risk medvetet är det ledningen som beslutar och inte administratören ensam. OWASP:s cheat sheet om hantering av sårbara beroenden rekommenderar likaså att riskacceptans uttryckligen förankras på ledningsnivå.
För en enda lista över öppna sårbarheter med status, ansvarig och datum. En tabell räcker. Viktigt är att den gås igenom regelbundet, till exempel vid den månatliga genomgången med ledningen.
Vad NIS2 och leverantörer har med saken att göra
För företag som omfattas av NIS2 är hanteringen av sårbarheter en del av skyldigheterna för riskhantering. Detaljerna beskrivs i NIS2 och säkerhet för webbservrar. Men även utan lagstadgad skyldighet är ett dokumenterat förlopp en fördel, till exempel gentemot kunder, försäkringsgivare och den egna ledningen.
Många steg kan läggas ut, till exempel att följa varningar eller att installera uppdateringar. Beslutet om risker och den samlade överblicken bör dock stanna i huset. Den som lämnar över hela cykeln till en leverantör vet i ett skarpt läge inte längre vilka system man överhuvudtaget har. Hur genomförandet organiseras som rutin beskriver Patchhantering som process i stället för brandkår.
Hur hjälper PHP SOS konkret?
- Vi tar tillsammans med er fram förteckningen över era webbplatser och servrar som grund för varje avstämning.
- Vi följer de relevanta varningarna för era system och levererar en bedömning i klartext med en rekommendation.
- Vi förbereder beslutsnoteringar för fall där en uppdatering inte går att göra direkt.
- Via säkerhetsövervakning kontrollerar vi löpande om system blir avvikande medan en lucka fortfarande är öppen.
Slutsats: Sårbarhetshantering i medelstora företag behöver inte vara stor, men den ska vara bindande. Den som känner till sina system, läser några goda källor och dokumenterar sina beslut reagerar snabbt och rätt vid nästa kritiska varning.
Vanliga frågor
Vad är sårbarhetshantering?
Ett återkommande förlopp där ett företag får veta om säkerhetsluckor i sina system, bedömer dem, åtgärdar eller medvetet accepterar dem och dokumenterar resultatet. Det handlar inte om ett verktyg utan om ansvar och beslut.
Räcker CVSS-värdet för att prioritera?
Det är en bra utgångspunkt men räcker inte. Avgörande är dessutom om det berörda systemet kan nås från internet, vilka data det hanterar och om angrepp redan har observerats. En lucka med högt värde på ett internt testsystem kan vänta, en lucka i webbshopen kan inte det.
Behöver ett litet företag ett eget verktyg för detta?
Inte till en början. En välskött förteckning över systemen, prenumererade säkerhetsmeddelanden och en tabell med öppna punkter räcker. Sårbarhetsskannrar lönar sig när antalet system växer eller när kontroller regelbundet måste kunna styrkas.
Får man medvetet låta bli att åtgärda en sårbarhet?
Ja, om risken har bedömts, beslutet fattas av ansvarig ledning och skrivs ner, helst med övergångsåtgärder och ett datum för ny prövning.