Rendszerbiztonsági terv: mit kell tartalmaznia és ki hagyja jóvá

/tudastar/rendszerbiztonsagi-terv · Célkifejezés: rendszerbiztonsági terv · Elsődleges modul: IT biztonsági keretrendszer

Miért ez a legtöbbet kért dokumentum

Mert ez az egyetlen irat, amelyből az auditor egyben látja, hogy a szervezet érti-e a saját rendszerét. Minden más dokumentum egy-egy részterületről szól; a rendszerbiztonsági terv összeköti őket.

Ebből az is következik, hogy nem lehet önállóan megírni. Ha nincs meg a rendszernyilvántartás, a kockázatértékelés és a kontrollértékelés, akkor a terv vagy üres általánosságokból áll, vagy kitalált tartalomból — és mindkettő azonnal látszik.

Milyen fejezetekből áll

Fejezet	Mit tartalmaz	Honnan jön
Azonosítás	A rendszer neve, kódja, státusza, lehatárolása	Rendszernyilvántartás
Működési koncepció	Mire való, milyen üzleti folyamatot támogat	Üzleti hatáselemzés
Adatkör	Milyen adatokat kezel, milyen érzékenységgel	Adatvagyon-leltár
Besorolás	A biztonsági osztály és az indoklása	Besorolási döntés
Architektúra	Rendszerelemek, kapcsolatok, függőségek, határok	CMDB / CI-nyilvántartás
Szerepkörök	Ki felel miért, és ki hagy jóvá mit	Szerepkör-katalógus
Kockázatok	A releváns kockázatok és a kezelési döntések	Kockázatértékelés
Védelmi intézkedések	A vonatkozó kontrollok és megvalósításuk módja	Kontrollértékelés
Eltérések	Helyettesítő intézkedések, elfogadott maradványkockázatok	Kockázatkezelési döntések
Kapcsolódó dokumentumok	Szabályzatok, eljárásrendek, tervek	Dokumentumnyilvántartás

A táblázat harmadik oszlopa a lényeg: a rendszerbiztonsági terv nem forrásdokumentum, hanem gyűjtő. Ha máshol nincs meg az adat, itt sem lesz igaz.

Négy tipikus hiba

Egy terv az egész szervezetre. A terv rendszerenként készül. Egyetlen, mindent lefedő dokumentum azt jelenti, hogy az EIR-lehatárolás nincs meg.

Nincs hatályba léptetve. A legjobb tartalom is elbukik, ha nincs jóváhagyó, dátum és verziószám. Tervezet nem bizonyíték.

Nem tükrözi a valóságot. Az architektúrafejezet a két évvel ezelőtti állapotot írja le. Az auditor a mintavételes ellenőrzésben ezt egy kérdéssel kideríti.

Sablonból másolt általánosságok. Ha a terv bármelyik másik szervezetre ráillene, akkor szakmai tartalma nincs. Ez a legkönnyebben felismerhető hiba, és a legrosszabb benyomást kelti.

Ki készíti, ki hagyja jóvá

Az IBF készíti elő és felel a szakmai tartalmáért, de az adatokat a rendszergazdáktól, az üzemeltetéstől és a folyamatgazdáktól kell felvenni. A jóváhagyás vezetői aktus, mert a tervben rögzített védelmi intézkedések erőforrást igényelnek.

Gyakorlati tanács: a jóváhagyást ne e-mailben kérje. Legyen dokumentált döntési pont, dátummal, hogy az audit során egyértelmű legyen, ki mit vállalt.

Mikor kell frissíteni

Periodikusan, és soron kívül minden olyan esetben, amikor a rendszer architektúrája, adatköre, felhasználói köre vagy besorolása lényegesen változik. Egy integráció bekötése, egy új modul élesítése vagy a szállító cseréje mind ilyen esemény.

A gyakorlatban ez akkor működik, ha a frissítés nem külön projekt, hanem a nyilvántartás változásából automatikusan következik.

Hogyan segít ebben a Cybersensei

Az IT biztonsági keretrendszer a nyilvántartás, a kockázatértékelés és a kontrollértékelés kimeneteiből integráltan állítja elő a rendszerbiztonsági tervet, jóváhagyható formában. A Governance modul a követelménykiválasztást és a testreszabást viszi, és a felülvizsgálat esedékességéről is a rendszer figyelmeztet.

Gyakori kérdések

Hány oldal legyen? Amennyi a rendszer összetettségéhez kell. A terjedelem nem minőségi mutató; a nyomon követhetőség az.

Lehet közös terv két hasonló rendszerre? Ha valóban egy EIR-t alkotnak, akkor egy terv. Ha külön rendszerek, akkor külön.

Kell hozzá titkosítási szint? A terv érzékeny dokumentum: a kezelését a szervezet saját minősítési rendje szerint kell szabályozni.

Kiadható a szállítónak? Részlegesen igen, a rá vonatkozó fejezetekre szűkítve, és nem teljes terjedelemben.

Mit kell tartalmaznia a rendszerbiztonsági tervnek?