Our S.O.S. line:
+49 89 262 025954
Our team of experts is ready to assist your organization in the event of a cyberattack.
details
Legyen szó NIS2-megfelelésről, ISO/IEC 27001-ről vagy más információbiztonsági követelményrendszerről, előbb-utóbb eljutunk a kontrollokhoz. A szervezetnek nemcsak azt kell meghatároznia, hogy milyen védelmi intézkedéseket, szabályozásokat és gyakorlatokat alkalmaz, hanem azt is igazolnia kell, hogy azok valóban működnek.
A valóság azonban ritkán követi tökéletesen a kontroll listákat.
Előfordulhat, hogy egy régi rendszer technikailag nem támogat egy előírt biztonsági funkciót. Egy fejlesztés csúszik, egy kritikus rendszer nem állítható le, vagy egy új kontroll bevezetése több hónapos projektet igényel. Ilyenkor könnyen előállhat az a helyzet, hogy pontosan tudjuk, mit kellene megvalósítani, de az adott pillanatban erre nincs lehetőség.
A kérdés ilyenkor nem az, hogy figyelmen kívül hagyhatjuk-e a kontrollt, hanem az, hogy hogyan kezeljük szabályozottan azt a helyzetet, amikor az elvárt védelem nem az eredetileg meghatározott módon valósul meg.
Nem minden hiányzó kontroll kontrollkivétel
Fontos különbséget tenni aközött, hogy egy kontroll:
Ez a három helyzet GRC-szempontból egészen mást jelent.
Ha például egy kontroll olyan technológiára vonatkozik, amelyet a szervezet egyáltalán nem használ, megfelelő indoklással beszélhetünk alkalmazhatósági eltérésről.
Ettől megkülönböztetjük azt az esetet, amikor a kontroll célja releváns, de az előírt megoldás technikailag nem használható. Ekkor jöhet szóba egy helyettesítő vagy kompenzáló intézkedés.
És megint más helyzet, amikor egyszerűen még nem sikerült bevezetni a szükséges kontrollt. Az, hogy „a projekt három hónapot csúszik”, önmagában nem teszi nem alkalmazhatóvá a kontrollt.
A hazai kiberbiztonsági szabályozás kifejezetten foglalkozik az eltérésekkel és a helyettesítő védelmi intézkedésekkel.
A 7/2024. (VI. 24.) MK rendelet lehetőséget biztosít bizonyos egyedi eltérések alkalmazására, például a működési környezetből, a fizikai infrastruktúrából vagy az adott rendszer sajátosságaiból fakadóan. A rendelet azt is lehetővé teszi, hogy meghatározott feltételek mellett egy szervezet helyettesítő védelmi intézkedést alkalmazzon. (1. melléklet, 4. pont)
Ez azonban nem egy általános „felmentési lehetőség”. A rendelet szerint a helyettesítő intézkedésnek egyenértékű vagy összemérhető védelmet kell biztosítania az eredeti kontrollal. A szervezetnek fel kell mérnie és a saját kockázatkezelési rendje szerint el kell fogadnia a kapcsolódó kockázatot, dokumentálnia kell, hogy az alternatív megoldás hogyan biztosít megfelelő biztonsági szintet, valamint azt is, hogy az eredeti intézkedés miért nem alkalmazható. A döntést a szervezet vezetőjének vagy a kockázat felvállalására jogosult személynek jóvá kell hagynia.
Vagyis egy kompenzáló kontroll nem azt jelenti, hogy:
„ezt most nem tudjuk megcsinálni, ezért leírjuk, hogy kivétel.”
Hanem azt, hogy:
„az eredeti megoldás az adott környezetben nem alkalmazható megfelelően, ezért azonosítottuk a kockázatot, kialakítottunk egy másik védelmi megoldást, igazoltuk annak megfelelőségét, és a fennmaradó kockázatot az arra jogosult személy elfogadta.”
A kettő között audit szempontból jelentős különbség van.
Az 1/2025. (I. 31.) SZTFH rendelet 6. melléklete külön jelöli azokat a követelménycsoportokat, amelyek az audit során „értékelésből nem kizárhatóak”.
Ilyen többek között az információbiztonsági szabályzat, az elektronikus információs rendszerek biztonságáért felelős személy, az intézkedési terv és annak mérföldkövei, az EIR-nyilvántartás, illetve egyes hozzáférés-felügyeleti, adathordozó-kezelési és fizikai hozzáférési kontrollok. A teljes kör a rendelet 6. mellékletének G oszlopában található.
Itt azonban van egy lényeges különbség.
Az „értékelésből nem kizárható” megjelölés nem egyszerűen azt jelenti, hogy az adott követelményhez soha semmilyen eltérés vagy helyettesítő intézkedés nem kapcsolódhat. A szabályozás az alkalmazhatóság vizsgálatát, a szervezet által dokumentált eltéréseket és helyettesítő intézkedéseket, valamint az auditor saját kizárási lehetőségét külön kezeli. Az 1/2025. SZTFH rendelet 4. melléklete ráadásul kifejezetten előírja az eltérések és helyettesítő védelmi intézkedések nyilvántartását.
Ezért a kontrollkivételek kezelésénél nem elegendő egyetlen „kivétel” státusz. A mögötte lévő jogcímet és indoklást is pontosan meg kell határozni.
Az ISO/IEC 27001 valamivel más logikát követ.
Az A melléklet kontrolljai nem olyan értelemben kötelező ellenőrzőlista elemei, hogy minden szervezetnek minden kontrollt azonos módon kellene megvalósítania. A szervezet a kockázatértékelés és a kockázatkezelés alapján határozza meg a szükséges kontrollokat, majd ezeket összeveti az A melléklettel. Az Alkalmazhatósági Nyilatkozatban (Statement of Applicability, SoA) dokumentálnia kell a szükséges kontrollokat, valamint indokolnia kell az A melléklet kontrolljainak kizárását is.
Ez azonban itt sem jelent szabad kezet. A szabványtörzs (tehát a 4–10. fejezetben felsoroltak) egyetlen követelményének kizárása sem fogadható el az alkalmazási terület leírása szerint.
Ha egy kontroll például jogszabályi, szerződéses vagy más kötelező követelmény miatt szükséges, azt nem lehet egyszerűen a SoA-ban „nem alkalmazhatóként” megjelölni azért, mert a megvalósítása nehéz vagy költséges.
Ha pedig egy szükséges kontroll átmenetileg nem működik vagy még nincs bevezetve, azt célszerű a szervezet kontrollkivételi és kockázatkezelési folyamatán keresztül kezelni. Ettől azonban maga a megfelelőségi hiány nem feltétlenül szűnik meg.
Vegyünk egy egyszerű példát. Egy szervezet egyik kritikus, régi üzleti alkalmazása nem támogatja a többtényezős hitelesítést (MFA). Az alkalmazás cseréje már folyamatban van, de csak 7 hónap múlva fejeződik be.
A legrosszabb megoldás az lenne, ha erről mindenki tudna, mégsem történne semmi.
Ehelyett a szervezet például korlátozhatja az alkalmazás elérését kizárólag menedzselt eszközökre és belső hálózatra, szigoríthatja a hozzáférési jogosultságokat, fokozott naplózást és felügyeletet vezethet be, valamint rendszeresen felülvizsgálhatja a felhasználói fiókokat.
Ez azonban még nem elég. A döntést dokumentálni is kell.
Egy jól kialakított kontrollkivétel legalább az alábbiakat tartalmazza:
A lejárati idő különösen fontos. Egy kontrollkivételből ugyanis meglepően könnyen lesz állandó működési gyakorlat. Ha a „három hónapra engedélyezett kivétel” két évvel később is ugyanabban az Excel-táblában szerepel, miközben az eredeti felelős már nem dolgozik a cégnél, a projekt pedig rég lekerült a vezetői riportokról, az már nem kontrollkivétel, hanem kontrollhiány.
A megfelelően működő kontrollkivétel-kezelés ezért valójában maga is egy GRC-kontroll.
Meghatározza, hogy ki kérhet eltérést, ki értékeli annak kockázatát, ki hagyhatja jóvá, milyen bizonyítékokat kell csatolni hozzá, milyen időközönként kell felülvizsgálni, és mikor kell megszüntetni. Így egy audit során a szervezet nem azt próbálja megmagyarázni, hogy „ezt a kontrollt még nem sikerült megvalósítanunk”, hanem be tud mutatni egy követhető döntési folyamatot, kockázatértékelést, felelőst, kompenzáló intézkedéseket és egy jóváhagyott intézkedési tervet.
A kontrollkivétel célja ugyanis nem a kontroll megkerülése, hanem annak biztosítása, hogy amikor az eredeti kontroll nem alkalmazható vagy nem valósítható meg az elvárt módon, a kockázat akkor se maradjon gazdátlanul.
A kontrollkivételek megfelelő kezelése egyszerre igényel szabályozási, kockázatkezelési és technikai szemléletet.
A White Hat IT Security segíthet a kontrollok alkalmazhatóságának felmérésében, az eltérések és helyettesítő védelmi intézkedések kialakításában, a kapcsolódó kockázatok értékelésében, valamint egy auditálható kontrollkivétel-kezelési folyamat és nyilvántartás létrehozásában.
Így a kivétel nem egy audit előtt előkerülő magyarázat lesz, hanem a szervezet tudatos és dokumentált kockázatkezelésének része.
Irányítási, kockázatkezelési és megfelelőségi szolgáltatások | White Hat IT Security
A kvantumszámítástechnika sokáig elsősorban kutatási és technológiai témának tűnt. Compliance szempontból azonban egyre kevésbé lehet úgy tekinteni rá, mint valamire, amivel majd akkor kell foglalkozni, amikor megjelennek az első igazán nagy teljesítményű kvantumszámítógépek. A kvantumszámítógépek qubitekkel dolgoznak, és bizonyos számításokat [...]
