Situația actuală: PHP2Shell. Două vulnerabilități critice PHP (CVSS 9.2) permit cod malițios fără autentificare. Patchuri din 21.10.2026.Ce este de făcut acum →

Exercițiu de urgență la masă: simularea unui incident pe serverul web

Un exercițiu la masă costă o după-amiază și arată dacă planul dumneavoastră de urgență rezistă. Aici găsiți un scenariu gata făcut pentru un incident pe un server web PHP.

Stadiu 5 min de cititManagement și juridic

Pe scurt: Un exercițiu tabletop în IT simulează la masă un incident de securitate: o moderare oferă pas cu pas noi informații despre situație, participanții decid ca în caz real, iar la final rezultă o listă de îmbunătățiri concrete. Pentru serverele web se potrivește un scenariu după modelul PHP2Shell, deoarece atinge simultan tehnica, deciziile în condiții de incertitudine, protecția datelor și comunicarea.

De ce un plan funcționează abia prin exersare

Multe companii au acum un plan de urgență. Dacă funcționează se vede însă abia când cineva îl folosește sub presiunea timpului. Se află în el numărul de telefon corect? Știe conducerea că trebuie să decidă asupra unei opriri? Cunoaște furnizorul de servicii accesele? Astfel de întrebări le lămurește un exercițiu la masă în câteva ore.

Săptămâna din octombrie 2026 a arătat cât de repede poate escalada o situație: anunț prealabil de la php.net la 20.10., patchuri la 21.10. la ora 16 ora Germaniei, nivelul de avertizare portocaliu al BSI, opriri ale unor site-uri publice potrivit presei. Cine exersase în prealabil această succesiune a avut de improvizat mai puțin. Desfășurarea în detaliu o descrie Cronologia PHP2Shell. Cum vă construiți singur planul aflați la Elaborarea unui plan IT de urgență pentru serverele web; aici este vorba despre exersare.

Exercițiu tabletop în IT: roluri și pregătire

Un exercițiu bun necesită puține materiale, dar roluri clare. Moderarea conduce prin scenariu, introduce informații și ține timpul. Ea nu participă la discuție, ci pune întrebări. Un proces-verbal notează deciziile, întrebările deschise și fiecare loc în care cineva spune „asta n-aș ști acum”. Opțional, o altă persoană observă cum decurge comunicarea.

Participanții sunt oamenii care în caz real acționează efectiv: conducerea, IT-ul intern sau furnizorul extern de servicii, responsabilii cu protecția datelor, comunicarea, la nevoie achizițiile sau departamentul juridic. Important este să fie prezenți și înlocuitori, deoarece incidentele nu țin cont de planurile de concediu.

Pregătirea include: planul de urgență actual pe hârtie, lista de contacte, o prezentare a site-urilor și serverelor și o încăpere fără întreruperi. Stabiliți dinainte că este vorba despre învățare, nu despre note. Cine se teme că se face de râs nu spune ce nu știe.

Un scenariu gata făcut: breșă critică în PHP vineri după-amiază

Scenariul următor este fictiv, dar se orientează după modelul unei situații reale. Adaptați sistemele și numele la mediul dumneavoastră. Fiecare injecție primește zece până la douăzeci de minute de discuție.

Pas Injecția moderării Întrebarea directoare pentru grup
1 Presa de specialitate raportează o breșă critică în PHP, patchurile sunt anunțate, dar încă nu sunt disponibile. Cine află primul despre asta și cine trebuie informat?
2 Patchurile apar după-amiaza. BSI recomandă actualizare imediată, altfel oprire temporară. Care dintre sistemele noastre sunt afectate și de unde știm?
3 Furnizorul de hosting nu răspunde. Un server propriu rulează cu o versiune PHP fără actualizare oficială. Aplicăm patch, oprim sau așteptăm și cine decide?
4 Magazinul online urmează să facă o acțiune în weekend. Vânzările insistă să nu se oprească nimic. Cum cântărim veniturile și riscul și cum documentăm decizia?
5 Un administrator găsește luni un fișier PHP necunoscut în dosarul de upload. Ce facem mai întâi, ce lăsăm intenționat? Cine securizează probele?
6 Nu este clar dacă au ieșit date ale clienților. Cine evaluează o posibilă obligație de notificare și când curge termenul?
7 O jurnalistă întreabă de ce site-ul este offline. Cine vorbește în exterior și ce spunem cât știm puține?

Pasul 6 atinge RGPD. În exercițiu este suficient să se clarifice procedura: cine implică responsabilii cu protecția datelor și când. Evaluarea juridică rămâne la specialiști; principiile privind termenul se află în art. 33 RGPD.

Constatări tipice și cum le consemnați

Anumite lacune apar la aproape fiecare prim exercițiu. Lipsește o listă completă a site-urilor care rulează pe ce servere cu ce versiune PHP. Datele de contact ale furnizorului de hosting sunt vechi sau stocate doar într-o căsuță poștală care nu este accesibilă în caz de urgență. Nimeni nu știe sigur dacă conducerea poate dispune singură o oprire sau dacă trebuie să aprobe altcineva.

Consemnați fiecare constatare în trei părți: ce am stabilit, ce schimbăm și cine se ocupă de asta până când. O constatare fără responsabil rămâne, din experiență, nerezolvată. Ordonați punctele după efect: un număr de urgență lipsă se remediază repede și ajută imediat, o nouă soluție de monitorizare necesită planificare.

Pentru evaluarea structurată după exercițiu se potrivește aceeași procedură ca după un incident real. Ea este descrisă în articolul Lessons learned: cum deveniți mai buni după incident. Lista de contacte, care în exercițiu arată de obicei slăbiciuni, este tratată în Contacte de urgență: cine trebuie informat și când?.

Sfat

Repetați exercițiul după șase până la douăsprezece luni cu un alt scenariu, de exemplu un site spart cu redirecționare către pagini străine. Astfel verificați dacă măsurile din prima rundă au fost cu adevărat puse în aplicare.

Cum ajută PHP SOS concret?

  1. Adaptăm scenariul la site-urile, serverele și furnizorii dumneavoastră reali și pregătim injecțiile.
  2. Moderăm exercițiul la distanță sau prin videoconferință și ne reținem cu evaluările până când grupul a decis.
  3. Livrăm apoi un proces-verbal cu constatări, măsuri, responsabili și termene.
  4. La cerere, exersăm ulterior partea tehnică, adică inventarierea, patchul și căutarea de urme, așa cum o parcurge Incident Response în caz real.

Concluzie

Un exercițiu de urgență la masă este cea mai ieftină cale de a găsi slăbiciunile unui plan de urgență înainte ca un incident real s-o facă. O după-amiază, un scenariu realist și o evaluare sinceră sunt suficiente pentru început. Decisiv este ca din fiecare constatare să rezulte o sarcină cu nume și dată.

Întrebări frecvente

Ce este un exercițiu tabletop?

Un exercițiu în care participanții discută împreună un incident la masă, fără a lucra pe sisteme reale. O moderare introduce treptat informații noi, iar grupul decide și își motivează deciziile. Astfel devin vizibile lacunele din plan, responsabilități și listele de contacte.

Cine ar trebui să participe la un exercițiu de urgență?

Toți cei care în caz de urgență decid sau acționează: conducerea, IT-ul sau furnizorul de servicii, protecția datelor, comunicarea și, dacă există, persoana responsabilă pentru chestiunile de asigurare. Mai mult de opt până la zece persoane fac runda greoaie.

Cât durează un exercițiu tabletop?

Pentru o primă rulare sunt suficiente două până la trei ore, inclusiv evaluarea. Mai important decât durata este ca rezultatele să fie consemnate și măsurile să fie atribuite cu termen.

Trebuie scenariul să fie realist?

Ar trebui să se potrivească mediului dumneavoastră, dar nu trebuie să fie exact până în detaliu. Un scenariu după modelul unei situații reale precum PHP2Shell pare credibil și orientează discuția spre decizii, nu spre detalii tehnice.

Surse

Contact imediat

Fiecare oră contează. Scrieți-ne acum.

Descrieți pe scurt sistemul, versiunea PHP și ce ați observat. Ne vom face auziți, clarificăm situația și lucrăm la distanță până când incidentul este încheiat și documentat.

Ajutor imediat