A 7/2024. MK rendelet veszélytaxonómiája a gyakorlatban

/tudastar/veszelytaxonomia-gyakorlatban · Célkifejezés: veszélytaxonómia · Elsődleges modul: IT biztonsági keretrendszer

Miért nem elég a saját lista

A legtöbb szervezet, amely először készít kockázatértékelést, ötleteléssel kezdi: összeülnek, és összeírják, mi mehet félre. Ez a módszer három okból nem elég.

Hiányos. Az ötletelés azt találja meg, ami az adott csapatnak eszébe jut. Ami senkinek nem jut eszébe, az kimarad — és rendszerint pont az a baj, amire nem gondoltak.

Nem ismételhető. Jövőre más lesz a csapat, más lesz a lista, és a két értékelés nem lesz összehasonlítható. Márpedig az auditor pont azt kérdezi, hogy mi változott az előző értékelés óta.

Nem auditálható. Ha nincs rögzített katalógus, nem lehet megmutatni, hogy a szervezet minden releváns veszélyt végignézett. A hiány nem bizonyítható.

A taxonómia ezt oldja meg: minden komponensnél ugyanazt a listát kell végigvenni, és minden tételnél dönteni kell — releváns vagy sem, és ha nem, miért nem.

Hogyan épül fel egy veszélykatalógus

A szakmai gyakorlatban használt katalógusok — az ISO/IEC 27005:2022 mellékleteiben és az ENISA anyagaiban szereplők — nagyjából azonos logikát követnek: a veszélyeket eredet szerint csoportosítják. Tipikus csoportok a fizikai károkozás, a természeti események, az infrastruktúra kiesése, a műszaki meghibásodás, az információ kompromittálódása, a technikai támadás, a személyi okból bekövetkező funkciókiesés és a jogi jellegű fenyegetések.

Ez a csoportosítás nem önmagáért van. A gyakorlati haszna az, hogy kényszeríti a teljességet: a szervezet nem hagyhatja ki a fizikai és a személyi okokat csak azért, mert a csapat informatikus.

A konkrét, alkalmazandó katalógust minden esetben a hatályos rendelet melléklete adja; a saját kockázatértékelés ehhez igazodjon, ne egy általános szakirodalmi listához.

Komponensszintre bontani, nem rendszerszintre

A legfontosabb módszertani döntés. Ha a veszélyeket a teljes EIR-re rendeli hozzá, az eredmény használhatatlanul általános lesz: minden rendszer ki van téve mindennek.

Komponensszinten viszont értelmes kép áll össze. Egy adatbázis-kiszolgálónál az adatvesztés és az integritássérülés a fő szál, egy publikus webes felületnél a technikai támadás, egy szerverszobánál a fizikai és környezeti veszélyek. Ugyanaz a taxonómia, más eredmény — és ez az, amiből intézkedés lesz.

Négy gyakori hiba

A második a legalattomosabb. Ha valaki kitörli a nem releváns sorokat, a végeredmény szebb lesz, de az auditon nem lehet megmutatni, hogy a szervezet döntött róluk. A „nem releváns, mert…" is bizonyíték.

Veszélytől a kontrollig

A taxonómia önmagában nem cél. A lánc így néz ki: komponens → releváns veszély → sérülékenység → hatás és valószínűség → kockázati érték → kezelési döntés → védelmi intézkedés → bizonyíték. Ha ez a lánc bármelyik ponton megszakad, a kockázatértékelés díszdokumentummá válik.

A leggyakoribb szakadás a kezelési döntés és a védelmi intézkedés között van: a kockázat megkapja a besorolást, de nem lesz belőle feladat, felelős és határidő.

Hogyan segít ebben a Cybersensei

Az IT biztonsági keretrendszer komponensalapú kockázatértékelést futtat a rendelet veszélytaxonómiájával, ISO 27005:2022 szerinti módszertannal. A nem releváns tételek indoklással megmaradnak, a komponensváltozás pedig kikényszeríti az újraértékelést — így a kockázati kép nem projekttermék, hanem karbantartott adatbázis.

Gyakori kérdések

Használhatunk ISO 27005 katalógust a rendelet helyett? A módszertan hasznos hivatkozás, de az alkalmazandó katalógus a rendeleté. A kettő összekapcsolható.

Mennyire részletes legyen a komponensbontás? Addig, amíg a védelmi intézkedések értelmesen elkülönülnek. Ha két komponensnél ugyanaz a válasz mindenre, összevonhatók.

Kell minden veszélyhez számszerű valószínűség? Skála kell, és annak következetes használata. A látszólagos pontosság rosszabb, mint a jól dokumentált becslés.

Mi van, ha nincs elég adatunk a valószínűséghez? Akkor becsülni kell, és az indoklást rögzíteni. A becslés nem hiba; a rögzítetlen becslés az.