Na kratko: Načrt ukrepanja ob IT-incidentu za spletne strežnike vnaprej določi, kdo v resni situaciji odloča, koga je mogoče doseči, kateri sistemi so lahko prizadeti in kateri koraki si sledijo v katerem vrstnem redu. Kdor želi izdelati načrt ukrepanja ob IT-incidentu, ne potrebuje debelega priročnika, temveč nekaj aktualnih strani, dosegljivih tudi brez delujoče IT. Položaj okoli PHP2Shell je dober povod, da to storite zdaj.
Zakaj načrt ukrepanja prihrani čas in škodo
V resni situaciji se prve ure pogosto izgubijo z iskanjem: kdo ima dostop do ponudnika gostovanja? Kje so varnostne kopije? Kdo odloči, ali spletna trgovina preide v stanje brez povezave? Koga je treba obvestiti? Načrt ukrepanja na ta vprašanja odgovori vnaprej, v miru.
PHP2Shell je pokazal, kako kratek je lahko čas. 20. 10. 2026 je php.net napovedal popravke, 21. 10. ob 16. uri po nemškem času so bili objavljeni, BSI pa je priporočil takojšnjo posodobitev ali začasen izklop. Podjetja z načrtom so vedela, koga poklicati in katere strežnike preveriti. Drugi so morali najprej ugotoviti, kje sploh teče PHP.
Izdelava načrta ukrepanja ob IT-incidentu: gradniki
Praktičen načrt za spletne strežnike obsega ta dela:
1. Vloge in odločitve. Kdo v sili vodi, kdo nadomešča, kdo sme sisteme ugasniti, kdo govori navzven? Zapišite imena in namestnike.
2. Seznam kontaktov. Interne kontaktne osebe, ponudnik gostovanja, agencija, IT-izvajalec, pooblaščenec za varstvo podatkov, pravno svetovanje, kibernetska zavarovalnica s številko police, pristojni nadzorni organ za varstvo podatkov, Zentrale Ansprechstelle Cybercrime (osrednja kontaktna točka za kibernetsko kriminaliteto) vaše nemške zvezne dežele. Ta seznam mora biti na voljo natisnjen.
3. Popis sistemov. Vsaka spletna stran, spletna trgovina in portal s strežnikom, ponudnikom gostovanja, načinom delovanja, različico PHP, aplikacijo, odgovorno osebo in vrsto obdelanih podatkov.
4. Pravila odločanja. Pod katerimi pogoji sistem odklopimo z omrežja? Kdo to sme odločiti? Kaj velja ponoči in ob koncu tedna?
5. Postopki. Kratka zaporedja korakov za tipične primere: znana kritična ranljivost, sum vloma, spletna stran popačena, odtok podatkov, izsiljevanje.
6. Poti prijave. Kdo preverja obveznost prijave po 33. členu GDPR, če je mogoče v 72 urah od seznanitve? Kdo prijavi BSI ob obveznosti po NIS2? Kdo obvesti zavarovalnico?
7. Obnovitev. Kje so varnostne kopije, kdo jih lahko povrne, koliko časa to traja, kdaj je bilo nazadnje preizkušeno?
Primer: postopek „kritična ranljivost PHP“
Tako je lahko videti postopek, kakršen je bil potreben pri PHP2Shell:
| Korak | Kdo | Rezultat |
|---|---|---|
| Oceniti obvestilo (php.net, BSI) | odgovorni za IT | prizadeti sistemi po popisu |
| Namestiti posodobitev, znova zagnati vse delavce | skrbnik ali izvajalec | dokaz s stanjem paketov in časom procesov |
| Kjer posodobitev ni mogoča: vmesni ukrepi ali z omrežja | odloča vodstvo | dokumentirana odločitev |
| Zavarovati dnevnike, preveriti sledi | skrbnik ali forenzika | najdba ali brez najdbe |
| Ob najdbi: sprožiti postopek incidenta | vodstvo ukrepanja | preveriti poti prijave |
Pomembno pri tem: popravek ranljivost zapre, ne odstrani pa predhodno vnesene škodljive programske opreme. Zato mora iskanje sledi biti trdno del postopka.
Določite, kako dolgo se dnevniki spletnih strežnikov hranijo in kje ležijo zunaj strežnika. Pri PHP2Shell je strokovni tisk priporočal hranjenje dnevnikov od 20. 10. 2026 naprej. Kdor dnevnike obdrži le nekaj dni, takih priporočil ne more izvesti.
Preventiva, ki načrt šele naredi učinkovit
Načrt je samo tako dober kot predpogoji za njim. Preverite, ali varnostne kopije po pravilu 3-2-1 obstajajo in so preizkušene, glej Varnostne kopije po pravilu 3-2-1. S ponudnikom gostovanja in agencijo pisno razjasnite, kdo ob kritičnih ranljivostih kaj prevzame. Dostopne podatke za primere v sili hranite varno, a dosegljivo, na primer v zaščitenem trezorju gesel z nujnim dostopom.
Pripravite tudi besedilne predloge: interna informacija, obvestilo strankam, napotek na statični vzdrževalni strani. Napotki so na strani Krizno komuniciranje po napadu.
Vadite in ohranjajte aktualnost
Načrt, ki ga nikoli niste vadili, skoraj vedno vsebuje vrzeli. Enkrat letno odigrajte scenarij, na primer „kritična ranljivost PHP v petek popoldne“, in zapišite, kje se zatika. Za začetek zadošča preprost preizkus: ali lahko druga oseba brez pomoči prve doseže ponudnika gostovanja, povrne varnostno kopijo in spletno stran preklopi v vzdrževalni način? Če ne, v načrtu nekaj manjka, večinoma dostop, telefonska številka ali opis. Prav take vrzeli naj vaje razkrijejo, preden postane resno. Načrt posodobite po vsaki vaji in vsaki bistveni spremembi. Kot metodološki okvir so primerni osnovna zaščita IT (IT-Grundschutz) urada BSI in standard BSI 200-4 o upravljanju neprekinjenosti poslovanja.
Pravnih vprašanj, na primer o obveznostih prijave, načrt ne razrešuje dokončno. Poskrbi, da so prave osebe pravočasno vključene. Ta stran je splošna informacija in ne pravno svetovanje.
Kako PHP SOS konkretno pomaga?
- Z vami izdelamo popis sistemov vaših spletnih strežnikov, vključno z načinom delovanja in različico PHP.
- Napišemo tehnične postopke za tipične scenarije in jih uskladimo s ponudnikom gostovanja in agencijo.
- Izvedemo vajo in ugotovitve vgradimo v načrt.
- V resni situaciji prevzamemo tehnično plat prek Incident Response, na željo podprto z varnostno pogodbo o vzdrževanju.
Pogosta vprašanja
Kako obsežen mora biti načrt ukrepanja ob IT-incidentu?
Čim krajši, čim obsežnejši je nujno. Za spletne strežnike pogosto zadošča nekaj strani s kontakti, seznamom sistemov, pravili odločanja in postopki. Pomembnejše od obsega je, da je načrt aktualen in ga v resni situaciji najdete.
Kje hraniti načrt ukrepanja?
Na vsaj enem mestu, ki je dosegljivo tudi brez delujoče IT, na primer natisnjeno ali na ločeni napravi. Načrt, ki leži samo na prizadetem strežniku ali v zaklenjenem omrežju podjetja, v resni situaciji ne pomaga.
Kako pogosto naj se načrt preverja?
Vsaj enkrat letno in po vsaki bistveni spremembi, na primer pri zamenjavi ponudnika gostovanja ali novi programski opremi. Smiselna je kratka vaja, pri kateri se odigra en scenarij.
Ali BSI ponuja predloge?
BSI obravnava upravljanje v sili v okviru osnovne zaščite IT (IT-Grundschutz) in v standardu BSI 200-4 o upravljanju neprekinjenosti poslovanja (Business Continuity Management). Ti so primerni kot okvir; za spletne strežnike se splača kratka, praktična različica.