Egy incidens közben nincs idő arról vitatkozni, ki jogosult lekapcsolni egy szervert, vagy kinek kell szólni a vezetőségnél vasárnap hajnalban. Ezeket a kérdéseket nyugodt időszakban kell eldönteni és leírni. Az incidenskezelési terv pontosan erre való: rögzíti a döntéseket, mielőtt szükség lenne rájuk.
A terv azt írja le, hogyan működik a szervezet, amikor baj van: ki vezeti az eseményt, és mikor kell egy döntést feljebb vinni. Ide tartozik az is, milyen csatornán tartják a kapcsolatot a résztvevők. A műszaki lépések (naplómentés, izolálás, helyreállítás) mellette külön forgatókönyvekben szerepelnek. Az első órák konkrét teendőiről az első 24 óráról szóló cikk szól, ez az írás az ehhez szükséges keretet mutatja be.
Mit tartalmaz egy incidenskezelési terv
Egy hatvanoldalas dokumentumot incidens közben senki nem olvas el, ezért a használható terv rövid, és érdemes kettéválasztani: egy vékony törzsdokumentumra és mellé tett, témánként egy-két oldalas mellékletekre. A törzsbe az alábbiak kerülnek:
- Hatály és fogalmak. Mit tekint a szervezet biztonsági eseménynek és mit incidensnek, mely rendszerekre és telephelyekre vonatkozik a terv. Ha van OT-környezet, azt külön meg kell nevezni, mert ott más a mérlegelés.
- Súlyossági besorolás és az ehhez kötött eszkalációs szabályok.
- Szerepkörök névvel, helyettessel és elérhetőséggel, valamint az, hogy melyik szerep miről dönthet.
- Kommunikációs rend: belső csatornák, tartalék csatorna és a külső tájékoztatás rendje.
- Külső kapcsolatok: incidenskezelési partner, biztosító, jogi tanácsadó, hatóságok, kulcsszállítók elérhetősége.
- Jogszabályi és szerződéses bejelentések: melyik helyzetben kit kell értesíteni, és ki felel érte.
- Lezárás és tanulságok: ki írja meg az utólagos jelentést, és hogyan kerülnek vissza a változtatások a tervbe.
A mellékletek közé jellemzően a kapcsolati lista, a bejelentési sablonok, a bizonyíték-megőrzési utasítás és a gyakori forgatókönyvek (zsarolóvírus, kompromittált fiók, adatszivárgás) rövid lépéslistái kerülnek. A terv akkor használható, ha papíron vagy a vállalati hálózattól független helyen is megvan. Ha a fájlszerver titkosítva van, a rajta tárolt terv sem nyitható meg.
Súlyossági szintek és eszkalációs szabályok
A súlyossági szint dönti el, mennyi ember és milyen gyorsan mozdul. Ha minden riasztás vezetői szintre jut, a vezetők idővel megszokják és figyelmen kívül hagyják őket. Ha viszont semmi nem jut fel, egy komoly eset napokig az ügyeleti sorban ragadhat. A legtöbb szervezetnek három vagy négy szint elég, a lényeg, hogy a besorolás szempontjai előre le legyenek írva.
| Szint | Jellemző helyzet | Ki kap értesítést |
|---|---|---|
| Alacsony | Egyedi, behatárolt esemény, például egy megfertőzött munkaállomás, amelyet a végpontvédelem elszigetelt | Ügyeletes üzemeltető, a rendes munkarendben |
| Közepes | Több gépet vagy egy kiemelt fiókot érint, de az üzletmenet nem állt le | Az incidenskezelés vezetője, az IT vezetője |
| Magas | Kritikus rendszer kiesése, adatszivárgás gyanúja, vagy tartományi szintű kompromittálódás jele | A felső vezetés kijelölt tagja, jogi és kommunikációs felelős |
| Kritikus | Szervezeti szintű leállás vagy folyamatbiztonsági kockázat | Ügyvezetés, válságstáb, külső partnerek |
A szempontok legyenek mérhetők: érintett rendszerek köre, érintett adatok típusa, az üzleti folyamatra gyakorolt hatás, és az, hogy van-e jele aktív támadói jelenlétnek. Egy „elég súlyosnak tűnik” típusú érzés alapján két ügyeletes ugyanazt az eseményt eltérően sorolná be.
A jogszabályi bejelentési kötelezettséget szinttől függetlenül vizsgálni kell. Egy személyes adatot érintő adatvédelmi incidens a GDPR 33. cikke alapján, egy NIS2 hatálya alá tartozó szervezet jelentős incidense az irányelv 23. cikke alapján már magas szinten is bejelentést tehet szükségessé.
Felfelé könnyű, lefelé indoklással
Bevált szabály, hogy bizonytalanság esetén a magasabb szintet kell választani, és a szintet bárki emelheti, aki az eseményen dolgozik. Csökkenteni viszont csak az incidenskezelés vezetője tudja, írásban rögzített indokkal. Ez azért fontos, mert az első órákban kevés az információ, és egy ártalmatlannak tűnő riasztás mögött is lehet kiterjedt behatolás.
Az eszkalációnak időkorlátja is legyen. A terv rögzíti, hány percen belül kell visszaigazolnia az értesítést annak, akit hívtak, és ki a következő a láncban, ha nem válaszol. Hétvégére és szabadságra külön helyettesítési rend kell, mert egy incidens gyakran munkaidőn kívül kezdődik vagy derül ki.
Szerepkörök és döntési jogkörök
Kis szervezetben egy személy több szerepet is vihet, nagyobb eseménynél egy szerep mögött több ember áll, ezért a terv szerepeket határoz meg, és ezekhez rendel neveket. Ami nem maradhat ki: minden szerephez tartozzon helyettes, és mindkettőjük elérhetősége legyen a tervben.
- Az incidenskezelés vezetője koordinál, prioritást állít, és ő dönt a műszaki lépések sorrendjéről. Ő ritkán nyúl billentyűzethez, az ő dolga az áttekintés.
- Műszaki vezető: a vizsgálatot és a megfékezést irányítja, a rendszergazdákkal és a külső szakértőkkel dolgozik.
- Üzleti döntéshozó, a felső vezetés kijelölt tagja. Hozzá tartoznak azok a döntések, amelyeknek üzleti ára van: egy szolgáltatás leállítása, egy telephely leválasztása, a hatósági bejelentés jóváhagyása.
- Kommunikációs felelős: belső tájékoztatás, ügyfelek és partnerek, sajtó.
- Jogi és adatvédelmi felelős: bejelentési kötelezettségek, szerződéses értesítések, bizonyítékok jogi kezelése.
- Jegyzőkönyvvezető: időbélyeggel rögzít minden megfigyelést, döntést és lépést. Nélküle az utólagos jelentés és a hatósági bejelentés emlékezetből készül.
A döntési jogköröket érdemes táblázatban is leírni, döntésenként. Ki választhat le egy hálózati szegmenst? Ki tilthat le egy vezetői fiókot? Ki hívhat be külső szakértőt, és ki dönthet a rendőrségi feljelentésről? Ha ez nincs leírva, a döntés jellemzően annál köt ki, aki éppen elérhető, vagy senkinél.
Kommunikáció, amikor a levelezés sem megbízható
A kompromittált környezetben a vállalati levelezés, a csevegőalkalmazás és a videóhívás is a támadó látókörében lehet. Ha a támadónak tartományi adminisztrátori joga van, a levelezést is olvashatja, és látja, hogyan tervezik a kitiltását. Ezért a tervnek előre rögzítenie kell egy sávon kívüli csatornát, amely nem függ a vállalati identitáskezeléstől és a vállalati hálózattól.
Mi lehet a tartalék csatorna
- Telefonhívás és SMS ismert, a tervben szereplő számokra.
- Különálló csoport egy üzenetküldő alkalmazásban, amelyet nem a vállalati fiókokkal használnak, és a résztvevők már előre beléptek.
- Kijelölt konferenciahívás-szám vagy fizikai helyszín, ahol a válságstáb összeül.
A tartalék csatornát nem incidens közben kell megnyitni. Ha a csoportot csak akkor hozzák létre, hirtelen nem lesz meg mindenkinek a telefonszáma, és senki nem tudja ellenőrizni, valóban a kolléga csatlakozott-e.
A hívó személyazonossága
Az incidens a social engineering kedvező terepe: kapkodás van, és mindenki segíteni akar. Egy „gyorsan állítsd vissza a jelszavamat, kizártak” kérés egy támadótól is érkezhet. A tervben legyen visszahívási szabály: érzékeny kérést csak akkor teljesítenek, ha a kérőt a kapcsolati listán szereplő számon visszahívták.
Kifelé egy hang
Az ügyfeleknek, partnereknek és a sajtónak szóló közlés egy kézben legyen, előre jóváhagyott üzenetvázlatokkal. A munkatársak tudják, hogy kérdés esetén kihez irányítsák a hívót. A terv szabályozza azt is, mit tehetnek közzé a munkatársak a közösségi médiában az eset ideje alatt.
Asztali gyakorlat: a terv kipróbálása
Amíg egy tervet senki nem próbált ki, nem derül ki, hogy a benne leírt elérhetőségek és döntési utak működnek-e. Az asztali gyakorlat (tabletop) során a résztvevők egy tárgyalóban, éles rendszerek érintése nélkül játszanak végig egy forgatókönyvet. A NIST SP 800-84 útmutatója a tervek tesztelésének egyik alapmódszereként írja le.
Hogyan épül fel
- Cél és forgatókönyv. Egy reális, a szervezetre szabott helyzet: zsarolóvírus péntek este, egy vezetői postafiók átvétele, vagy egy kulcsszállító incidense, amely a saját rendszereket is érinti.
- Résztvevők. Akik a tervben szerepet kaptak, a felső vezetés kijelölt tagjával együtt. A vezetői részvétel nélkül az üzleti döntések próbája elmarad.
- Bejátszások. A levezető szakaszonként új információt ad: „a mentőszerver sem elérhető”, „egy újságíró telefonál”, „a biztosító kéri az első jelentést”. Minden bejátszás után a csoport kimondja, mit tesz és ki dönt.
- Megfigyelő. Valaki, aki nem vesz részt a döntésekben, csak jegyzetel: hol akadt el a csoport, mi hiányzott a tervből, ki nem tudta, mi a dolga.
- Utólagos értékelés. Közvetlenül a gyakorlat után, amíg friss. Az eredmény egy rövid, felelőssel és határidővel ellátott javítási lista.
Az első gyakorlatokon jellemzően egyszerű hiányok jönnek elő, például egy elavult telefonszám vagy egy döntés, amelyről senki nem tudja, kinek a hatásköre. Gyakran az is kiderül, hogy a mentésből való visszaállítás tényleges ideje messze elmarad az üzleti elvárástól (RTO). Ezek egy tárgyalóban nyugodtan javíthatók, éles incidens közben már nem. Évente legalább egy gyakorlat, és minden nagyobb szervezeti vagy rendszerváltozás után egy újabb segít abban, hogy a terv ne avuljon el.
A NIST SP 800-61 mint keret
Nem kell a semmiből kitalálni a terv szerkezetét. Az amerikai szabványügyi intézet (NIST) SP 800-61 kiadványa széles körben hivatkozott, nyilvános incidenskezelési útmutató. A 2012-es második kiadás négy fázisban írja le a folyamatot:
- előkészítés,
- észlelés és elemzés,
- megfékezés, felszámolás és helyreállítás,
- az incidens utáni tevékenység, benne a tanulságok levonásával.
A 2025 áprilisában megjelent harmadik kiadás ezt a modellt a NIST Cybersecurity Framework 2.0 funkcióihoz igazította. Az incidenskezelés így a teljes kockázatkezelés részévé válik: az irányítás (Govern), az azonosítás és a védelem a felkészülést adja, az észlelés, a válaszadás és a helyreállítás (Detect, Respond, Recover) az incidens kezelését. Ebből a gyakorlatban az következik, hogy a terv karbantartását, a szerepkörök kijelölését és a tanulságok visszavezetését a vezetésnek kell számon kérnie, az IT egyedül ezt nem tudja garantálni.
Európai szervezeteknél a NIS2 irányelv (EU 2022/2555) a kockázatkezelési intézkedések között kifejezetten említi az incidenskezelést és az üzletmenet-folytonosságot. Ipari szervezeteknél az IEC 62443 szabványsorozat is kitér az incidensek kezelésére. A NIST-keret ezekhez kiindulópontként használható: a négy fázisra épülő szerkezet átvehető, és a saját szerepkörökkel és rendszerekkel tölthető ki.
Kapcsolódó szolgáltatás: Incidenskezelési készenlét →
