Kort sagt: Når et angreb rammer mere end ét enkelt website, har I brug for en incident response-leverandør, som afvikler hændelsen struktureret. Vi overtager situationsbilledet, inddæmningen, oprydningen og den sikre genopretning, med klare roller og fuldstændig dokumentation. I beholder beslutningerne, vi sørger for det tekniske grundlag.
Hvad incident response ved serverangreb betyder
Incident response er den ordnede behandling af en sikkerhedshændelse. I stedet for hektiske enkeltindgreb følger arbejdet faste faser: erkende og vurdere, inddæmme, fjerne, genoprette, efterbehandle. Hver foranstaltning noteres med tidspunkt og begrundelse.
Netop ved webservere er det vigtigt. En server med PHP-applikationer indeholder ofte adgangsdata til databaser, betalingsudbydere, mailservere og grænseflader. Den, der er trængt ind dér, kan bevæge sig videre. Situationen efter PHP2Shell viser, hvor hurtigt sådan en situation kan opstå: kodeudførelse uden godkendt login, mere end 22,6 millioner eksponerede instanser ifølge Unit 42 og ingen offentliggjorte, bekræftede Indicators of Compromise.
Hvornår I har brug for en incident response-leverandør
- flere servere eller applikationer er berørt eller kan være berørt
- der er mistanke om, at personoplysninger eller betalingsdata er sluppet ud
- en angriber er muligvis stadig aktiv, f.eks. gennem løbende forbindelser eller nye konti
- der er en afpresning eller en offentlig bekendtgørelse af angrebet
- forsikring, myndigheder eller forretningspartnere forventer et dokumenteret forløb
Ved ét enkelt angrebet website er akuthjælp ved hacket website ofte nok. Overgangen til den fulde hændelseshåndtering aftaler vi med jer, så snart et større omfang tegner sig.
Hvordan hjælper PHP SOS konkret?
- Triage og situationsbillede: Vi afklarer, hvad der er observeret, hvilke systemer og data der kan være berørt, og hvem der internt skal inddrages. Resultatet er et første, skriftligt situationsbillede med åbne spørgsmål.
- Sikre spor og inddæmme: Logs, filsystemer og databaser sikres, før vi griber ind. Derefter isolerer vi berørte systemer, spærrer kompromitterede adgange og afbryder angriberens kendelige forbindelser.
- Fjerne: Vi lukker indgangen, f.eks. ved at rette til de rettede PHP-versioner og genstarte alle workers, fjerner bagdøre og udskifter hemmeligheder. Til detaljeanalysen inddrager vi om nødvendigt specialiserede partnere til it-forensik.
- Genoprette: Systemer går kontrolleret i drift igen, helst fra rene kilder eller på nyopsatte servere. Bagefter overvåger vi dem skærpet for nye uregelmæssigheder.
- Efterbehandle: I får en afslutningsrapport med tidslinje, årsager, foranstaltninger og anbefalinger. Sammen fastholder vi, hvad der skal gå hurtigere næste gang.
Gem serverlogs, og ændr ingen systemer, før der er sikret. BSI anbefaler ved PHP2Shell midlertidigt at tage webservere af nettet, som ikke kan rettes med det samme.
Roller og kommunikation under hændelsen
En hændelse kræver klare ansvarsområder. En lille kreds har vist sig at fungere: en person med beslutningskompetence, en teknisk kontaktperson hos jer og os som teknisk ledelse. Situationsmøder finder sted med faste mellemrum, og resultater noteres skriftligt.
Parallelt kører opgaver, som vi ikke overtager, men hvortil vi leverer fakta: vurderingen af en anmeldelsespligt efter GDPR inden for 72 timer, underretningen af forsikringsselskabet, en mulig anmeldelse og krisekommunikationen over for kunder og partnere.
Hvad vi har brug for fra jer, og hvad I får
Vi har brug for administrative adgange til de berørte systemer, et overblik over infrastruktur og tjenesteudbydere, en person med beslutningskompetence og beredskab til om nødvendigt at slukke systemer midlertidigt. Nyttige er eksisterende beredskabsplaner, netværksskitser og backups med dato.
I får en løbende hændelsesprotokol, regelmæssige situationsbilleder i letforståeligt sprog, en afslutningsrapport til direktionen, databeskyttelsesrådgiveren og forsikringsselskabet samt en prioriteret liste over forbedringer. Hvordan I stiller jer bedre til næste hændelse, beskriver Opret en it-beredskabsplan for webservere.
Typiske fejl i de første timer
Mange hændelser bliver værre, fordi velment handlede skridt i ophidselsen sker i den forkerte rækkefølge. Disse mønstre ser vi ofte:
- Straks sætte op påny: Serveren slettes og geninstalleres, før der er sikret. Bagefter kan man ikke længere afklare, om data er sluppet ud.
- Skifte adgangskoder fra det angrebne system: Hvis angriberen stadig har adgang, ser vedkommende de nye adgangskoder med.
- Kun slette den synlige fil: Webshellen er væk, den anden bagdør i cronjobbet bliver.
- Rette uden genstart: Nye PHP-filer ligger på disken, de gamle workers kører videre i hukommelsen.
- Ingen fører protokol: Senere ved ingen længere, hvem der ændrede hvad og hvornår. Det besværliggør samtaler med forsikringsselskab og myndigheder.
Et afstemt forløb forhindrer disse fejl uden at forsinke inddæmningen.
Hvad vi ikke lover
Vi lover ikke, at enhver hændelse opklares fuldstændigt; uden spor forbliver spørgsmål åbne, og det skriver vi også sådan i rapporten. Vi yder ikke juridisk rådgivning og udtaler os ikke om ansvar eller forsikringsdækning. Vores mål er en klar afslutning: Vi arbejder på hændelsen, indtil den er afsluttet og dokumenteret.
Ofte stillede spørgsmål
Hvad er forskellen på incident response og it-forensik?
Incident response har til formål at inddæmme hændelsen og genoprette driften sikkert. It-forensik opklarer i detaljer og med bevismæssig holdbarhed, hvad der er sket. I praksis griber de to ind i hinanden; forensikken sikrer ofte spor parallelt.
Hvornår bør jeg inddrage en incident response-leverandør?
Så snart der er mistanke om, at en angriber har haft adgang til systemer, og I ikke sikkert kan vurdere omfanget. Jo tidligere sikringen af spor begynder, desto mere kan senere dokumenteres.
Hvem træffer beslutningerne under hændelsen?
Beslutningerne træffer I, f.eks. om nedlukninger, kommunikation eller anmeldelser. Vi forbereder det tekniske grundlag, viser mulighederne med deres konsekvenser og gennemfører beslutningerne.
Skal jeg inddrage politiet?
En anmeldelse er i mange tilfælde fornuftig og relevant for visse forsikringer. De centrale kontaktpunkter for cyberkriminalitet hos politiet er ansvarlige herfor. Om og hvornår I anmelder, beslutter I sammen med jeres advokat.