Kort sagt: Om ett angrepp berör mer än en enskild webbplats behöver ni en leverantör av incident response som arbetar igenom incidenten på ett strukturerat sätt. Vi tar hand om lägesbilden, begränsningen, rensningen och den säkra återställningen, med tydliga roller och fullständig dokumentation. Ni behåller besluten, vi sörjer för det tekniska underlaget.
Vad incident response innebär vid serverangrepp
Incident response är den ordnade hanteringen av en säkerhetsincident. I stället för hektiska enskilda åtgärder följer arbetet fasta faser: upptäcka och bedöma, begränsa, avlägsna, återställa, följa upp. Varje åtgärd dokumenteras med tidpunkt och motivering.
Särskilt viktigt är det för webbservrar. En server med PHP-applikationer innehåller ofta inloggningsuppgifter till databaser, betalningsleverantörer, e-postservrar och gränssnitt. Den som har tagit sig in där kan röra sig vidare. Läget efter PHP2Shell visar hur snabbt en sådan situation kan uppstå: kodkörning utan autentisering, mer än 22,6 miljoner exponerade instanser enligt Unit 42 och inga publicerade, bekräftade Indicators of Compromise.
När ni behöver en leverantör av incident response
- flera servrar eller applikationer är berörda eller kan vara det
- det finns misstanke om att personuppgifter eller betalningsuppgifter har läckt ut
- en angripare är möjligen fortfarande aktiv, till exempel genom pågående förbindelser eller nya konton
- det förekommer utpressning eller ett offentligt tillkännagivande av angreppet
- försäkringsbolag, myndigheter eller affärspartner förväntar sig ett dokumenterat förlopp
Vid en enskild angripen webbplats räcker ofta akuthjälp vid hackad webbplats. Övergången till fullständig incidenthantering går vi igenom med er så snart en större omfattning börjar visa sig.
Hur hjälper PHP SOS konkret?
- Triage och lägesbild: Vi klarlägger vad som har observerats, vilka system och data som kan vara berörda och vem som behöver involveras internt. Resultatet är en första, skriftlig lägesbild med öppna frågor.
- Säkra spår och begränsa: Loggar, filsystem och databaser säkras innan vi ingriper. Därefter isolerar vi berörda system, spärrar komprometterade åtkomster och bryter synliga förbindelser som angriparen har.
- Avlägsna: Vi stänger ingångsvägen, till exempel genom att patcha till de åtgärdade PHP-versionerna och starta om alla workers, tar bort bakdörrar och byter ut hemligheter. För detaljanalysen anlitar vi vid behov specialiserade partner för IT-forensik.
- Återställa: Systemen tas i drift igen på ett kontrollerat sätt, helst från rena källor eller på nyinstallerade servrar. Därefter övervakar vi dem extra noga med avseende på nya avvikelser.
- Följa upp: Ni får en slutrapport med tidslinje, orsaker, åtgärder och rekommendationer. Tillsammans fastslår vi vad som ska gå snabbare nästa gång.
Spara serverloggarna och ändra inga system innan säkringen är gjord. BSI (Tysklands federala myndighet för informationssäkerhet) rekommenderar vid PHP2Shell att webbservrar som inte genast kan patchas tas bort från nätet tillfälligt.
Roller och kommunikation under incidenten
En incident kräver tydliga ansvarsområden. En liten grupp har visat sig fungera väl: en beslutsbefogad person, en teknisk kontaktperson hos er och vi som teknisk ledning. Lägesmöten hålls med fasta mellanrum, och resultaten dokumenteras skriftligt.
Parallellt pågår uppgifter som vi inte tar över men för vilka vi levererar fakta: prövningen av en anmälningsskyldighet enligt GDPR inom 72 timmar, informationen till försäkringsgivaren, en eventuell polisanmälan och krishanteringen i kommunikationen mot kunder och partner.
Vad vi behöver från er och vad ni får
Vi behöver administrativ åtkomst till de berörda systemen, en översikt över infrastrukturen och leverantörerna, en beslutsbefogad person och beredskap att vid behov tillfälligt stänga av system. Befintliga nödlägesplaner, nätverksskisser och daterade säkerhetskopior är till hjälp.
Ni får ett löpande incidentprotokoll, regelbundna lägesbilder på begripligt språk, en slutrapport för ledning, dataskyddsombud och försäkringsgivare samt en prioriterad lista över förbättringar. Hur ni rustar er bättre inför nästa incident beskriver Ta fram en IT-nödlägesplan för webbservrar.
Typiska misstag under de första timmarna
Många incidenter blir svårare eftersom välmenande steg tas i fel ordning i all uppståndelse. Dessa mönster ser vi ofta:
- Genast installera om: Servern raderas och installeras om innan något har säkrats. Efteråt går det inte längre att klarlägga om data har läckt ut.
- Byta lösenord från det angripna systemet: Om angriparen fortfarande har åtkomst ser han de nya lösenorden också.
- Bara radera den synliga filen: Webshellen är borta, men den andra bakdörren i cronjobbet finns kvar.
- Patcha utan omstart: Nya PHP-filer ligger på disken, men de gamla workers fortsätter köra i minnet.
- Ingen för protokoll: Senare vet ingen längre vem som ändrade vad och när. Det försvårar samtal med försäkringsgivare och myndigheter.
Ett avstämt förlopp förhindrar dessa misstag utan att fördröja begränsningen.
Vad vi inte lovar
Vi lovar inte att varje incident blir fullständigt utredd; utan spår förblir frågor obesvarade, och det skriver vi också i rapporten. Vi ger ingen juridisk rådgivning och inga uttalanden om ansvar eller försäkringsskydd. Vårt mål är ett tydligt slut: Vi arbetar med incidenten tills den är avslutad och dokumenterad.
Vanliga frågor
Vad är skillnaden mellan incident response och IT-forensik?
Incident response syftar till att begränsa incidenten och återställa driften på ett säkert sätt. IT-forensik klarlägger i detalj och på ett bevissäkert sätt vad som har hänt. I praktiken går de i varandra, och forensiken säkrar ofta spår parallellt.
När bör jag anlita en leverantör av incident response?
Så snart det finns misstanke om att en angripare har haft åtkomst till system och ni inte säkert kan bedöma omfattningen. Ju tidigare spårsäkringen börjar, desto mer går att belägga i efterhand.
Vem fattar besluten under incidenten?
Besluten fattar ni, till exempel om avstängningar, kommunikation eller anmälningar. Vi förbereder de tekniska underlagen, visar alternativen med deras konsekvenser och genomför besluten.
Måste jag kontakta polisen?
En polisanmälan är i många fall meningsfull och för vissa försäkringar relevant. I Tyskland är polisens centrala kontaktpunkter för it-brottslighet (ZAC) ansvariga för detta. Om och när ni anmäler avgör ni tillsammans med er jurist.