# Lessons learned: jobbá válni az incidens után

> Lessons learned egy IT-incidens után: mikor legyen az utólagos megbeszélés, mely kérdések számítanak, és hogyan lesz a tanulságokból határidős intézkedés.

Forrás: https://phpsos.de/hu/blog/lessons-learned-nach-vorfall/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A lessons learned egy IT-incidens után azt jelenti: a műszaki lezárás után az összes érintett leül, rekonstruálja a lefolyást, felelősök keresése nélkül megnevezi, mi ment jól és mi nem, és ebből felelősökkel és határidőkkel ellátott intézkedéseket vezet le. Ez a közel-incidensekre is érvényes, például egy simán lefutott PHP2Shell-hétre. Nem a jegyzőkönyv a döntő, hanem az utólagos ellenőrzés, hogy megvalósították-e az intézkedéseket.

## Miért olyan fontos az incidens utáni hét

Amikor a szerver ismét fut, és a javításokat telepítették, nagy a kísértés, hogy gyorsan visszatérjenek a mindennapokhoz. Éppen ekkor vész el a legértékesebb tudás: ki mit vett észre mikor? Hol hiányzott egy információ? Melyik döntés tartott túl sokáig? Néhány hét múlva ezt már senki sem tudja pontosan.

A 2026. októberi hét jó példa erre. Sok vállalkozás javította a PHP-szervereit, megkereste a tárhelyszolgáltatókat, elővigyázatosságból lekapcsolta a weboldalakat vagy mentette a naplókat. Még ha nem is állapítottak meg behatolást, sok tanulnivaló rejlik benne. Mennyi ideig tartott, mire kiderült, mely rendszerek érintettek? Ki hagyhatta jóvá a lekapcsolást, és elérhető volt-e az a személy?

Magának a támadásnak a műszaki lépéseit az [Ellenőrzőlista egy feltörés után](https://phpsos.de/hu/ratgeber/checkliste-nach-dem-hack/) tárgyalja. Ez a cikk utána kapcsolódik be: mit tanulunk ebből?

## Lessons learned az IT-incidensnél: az utólagos megbeszélés alapszabályai

Az utólagos megbeszélés nem törvényszék. Aki attól tart, hogy a hibáknak személyes következményei vannak, csak a történet felét meséli el. Ezért az alapelv: az okokat a folyamatokban, eszközökben és információkban keressük, nem bűnösöket. Az emberek abból a tudásból cselekedtek, amellyel az adott pillanatban rendelkeztek.

Hívjon meg mindenkit, aki érintett volt, a külsőket is, mint a tárhelyszolgáltató, az ügynökség vagy a szolgáltató, amennyire lehetséges. Tervezzen két órát. Kérjen előre anyagot: ticketeket, csevegési előzményeket, e-maileket, jegyzeteket, naplókivonatokat. Ebből készül az idővonal, a megbeszélés gerince. Hogyan építheti fel rendesen, azt az [Egy incidens idővonalának elkészítése](https://phpsos.de/hu/blog/zeitleiste-eines-vorfalls/) írja le.

A moderálást ne az a személy vállalja, aki az incidenst operatívan vezette. Különben a saját döntéseit értékelné. Semleges például valaki egy másik osztályról vagy egy külső partner.

## A folyamat hat lépésben

1. **Az idővonal bemutatása:** Mi történt mikor, az első jelentéstől a lezárásig? Az idővonal hiányosságait megjelölni, nem találgatni.
2. **Mi ment jól?** Tudatosan a pozitívval kezdje. Ez megmutatja, mit kell megtartani, és oldja a hangulatot.
3. **Hol akadt?** Minden késedelmet, hiányzó információt és bizonytalanságot összegyűjtenek, kezdetben a megoldásokról való vita nélkül.
4. **Az okok tisztázása:** A legfontosabb pontoknál többször kérdezzen rá a miértre. „A javítás későn jött” megállapítás, „senki sem tudta, hogy a régi szerveren még fut PHP” ok.
5. **Intézkedések rögzítése:** Minden okhoz egy konkrét intézkedés, egy felelős személy és egy határidő.
6. **Utólagos ellenőrzés megállapodása:** Egy időpont négy-nyolc hét múlva, amikor ellenőrzik, mi valósult meg.

## Tipikus kérdések és intézkedések egy PHP-helyzet után

A következő táblázat azokat a kérdéseket mutatja, amelyek egy olyan helyzet után, mint a PHP2Shell, gyakran felmerülnek, és lehetséges válaszokat intézkedések formájában. Nem mindegyik illik minden vállalkozásra; a tekintet élesítésére szolgál.

| Kérdés az utólagos megbeszélésen | Tipikus megállapítás | Lehetséges intézkedés |
|---|---|---|
| Hogyan értesültünk a résről? | Véletlenül a hírekből | Célzottan feliratkozni a php.net és a BSI biztonsági közleményeire |
| Tudtuk, mely rendszerek érintettek? | A lista hiányos, egy régi rendszert elfelejtettek | Az összes weboldal és szerver leltára PHP-verzióval |
| Ki dönthetett a lekapcsolásról? | Nem világos, a döntés késett | A döntési jogkört rögzíteni a vészhelyzeti tervben |
| Megerősítette a tárhelyszolgáltató a javítást? | Csak szóban vagy egyáltalán nem | Írásos megerősítést kérni, a szerződést kiegészíteni |
| Újraindították az összes PHP-folyamatot? | Nem ellenőrizték | Az újraindítást és az ellenőrzést rögzített lépésként felvenni |
| Rendelkezésre álltak a naplók 10. 20-tól? | Részben már felülíródtak | A megőrzési időt meghosszabbítani, a naplókat központilag menteni |
| Hogyan zajlott a kommunikáció belül és kívül? | A munkatársak a sajtóból értesültek | Belső első tájékoztatást előkészíteni |

Azt is rögzítse, mit nem változtat tudatosan. Néha egy megállapítás ismert, de az intézkedés aránytalan lenne. Egy dokumentált döntés jobb, mint a csendes elfelejtés.

> **Tipp:**
> A jegyzőkönyvben válassza szét az igazolt tényeket, a valószínű feltevéseket és a nyitott kérdéseket. Éppen a PHP2Shell után, amelyhez nincsenek közzétett, megerősített Indicators of Compromise, fontos ez a szétválasztás.

## A jegyzőkönyvtől a változásig

A lessons learned leggyakoribb kudarca banális: a jegyzőkönyvet elküldik, és utána nem történik semmi. Három szokás segít ez ellen. Először: minden intézkedés abba a rendszerbe tartozik, amelyben amúgy is dolgoznak, vagyis a ticketrendszerbe vagy a feladatlistába, nem egy külön dokumentumba. Másodszor: az utólagos ellenőrzés rögzített időpontot kap a vezetés naptárában. Harmadszor: az eredmények beépülnek a vészhelyzeti tervbe, a kapcsolattartói listába és a gyakorlatokba.

Aki a felismeréseket a következő valódi incidensre való várakozás nélkül akarja ellenőrizni, végigjátszhatja őket egy [vészhelyzeti gyakorlaton az asztalnál](https://phpsos.de/hu/blog/notfalluebung-am-tisch/). Ahol pedig az utólagos megbeszélés megmutatja, hogy a frissítések túlságosan a véletlentől függtek, megéri az átalakítás [patchmenedzsmentté mint folyamattá](https://phpsos.de/hu/blog/patch-management-prozess/).

Az adatvédelem, a biztosítás és adott esetben a hatóságok számára a zárójelentés ráadásul fontos dokumentum. A jogi értékelés, például hogy szükséges volt-e bejelentés a GDPR 33. cikke szerint, azonban az adatvédelmi tisztviselőhöz vagy az ügyvédhez tartozik, nem a műszaki utólagos megbeszélésre.

## Hogyan segít konkrétan a PHP SOS?

- A naplókból, ticketekből és jegyzetekből idővonalat készítünk az incidensről, és megjelöljük a hiányosságokat.
- Semleges helyként moderáljuk az utólagos megbeszélést, és ügyelünk rá, hogy okokat keressenek bűnösök helyett.
- A műszaki megállapításokat intézkedésekre fordítjuk le ráfordítás-becsléssel és prioritással.
- Kísérjük az utólagos ellenőrzést, és kívánságra magunk valósítjuk meg a műszaki intézkedéseket, ahogyan azt az [incidenskezelésünk](https://phpsos.de/hu/leistungen/incident-response/) előirányozza.

## Összegzés

Egy incidens eléggé drága. Aki nem értékeli ki, a következő alkalommal még egyszer fizet. Egy őszinte, felelősök keresése nélküli utólagos megbeszélés, egy rendes idővonal és névvel meg határidővel ellátott intézkedések egy nehéz hétből tartós biztonságnyereséget csinálnak.


## Gyakori kérdések

**Mikor legyen a lessons learned megbeszélés?**  
Amikor az incidens műszakilag lezárult, de az emlékek még frissek. A gyakorlatban bevált egy időpont a lezárás után nagyjából egy-két héttel. Korábban gyakran hiányzik a távolság, később elhalványulnak a részletek.

**Utólagos megbeszélést közel-incidens után is tartani kell?**  
Megéri. Egy olyan helyzet, mint a PHP2Shell, amelyben a végén nem történt semmi, ettől még megmutatja, hol akadtak a folyamatok. Ezek a felismerések különösen értékesek, mert kár nélkül jöttek létre.

**Ki vezeti az utólagos megbeszélést?**  
A legjobb, ha olyasvalaki, aki az incidenst nem maga vezette operatívan. Így a moderálás semleges marad, és senkinek sem kell a saját döntéseit védenie. Ez lehet külső szolgáltató is.

**Mi lesz az eredményekkel?**  
Minden felismerésből egy intézkedés lesz felelős személlyel és határidővel. A vészhelyzeti tervet, a kapcsolattartói listát és a dokumentációt módosítják. Néhány hét múlva valaki ellenőrzi, mit valósítottak meg ténylegesen.

## Források

- [BSI: információk vállalkozásoknak](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [GDPR 33. cikk](https://dsgvo-gesetz.de/art-33-dsgvo/)