MI-natív megfelelés

A dokumentumoktól a strukturált megfelelési munkaterületig

Az MI-natív megfelelés azt jelenti, hogy a mesterséges intelligenciát egy strukturált, átvizsgálható megfelelési folyamaton belül használjuk – nem csupán egy csevegőrobotot illesztünk egy dokumentumtárhoz. A működési elv egyszerű: az MI felgyorsítja az előkészítést és az elemzést, a jelentős következményekkel járó döntéseket emberek hagyják jóvá, a bizonyítékok pedig minden alátámasztott állításhoz kapcsolódva maradnak.

Egy technológiai igazgató számára az architekturális kérdés az, hogy a rendszer képes-e leképezni a szervezet tényleges kontrolljait. Egy szabályzat a szándékolt viselkedést írja le. Egy konfigurációs export egy beállítást mutat. Egy elvégzett hozzáférési felülvizsgálat egy tevékenységet igazol. Ezek különböző típusú bizonyítékok, és a gördülékeny szöveg generálása nem teszi őket felcserélhetővé.

Egy hasznos munkaterület összekapcsolja a követelményeket, a kontrollokat, a rendszereket, a bizonyítékokat, a gazdákat, a feladatokat és a döntéseket. Ez a struktúra lehetővé teszi a csapatok számára, hogy az alátámasztott információkat több keretrendszerben is újrahasznosítsák anélkül, hogy a hasonló követelményeket egyenértékű kötelezettségekkel tévesztenék össze.

Miért teremtenek technikai adósságot a különálló keretrendszer-projektek

A szervezetek gyakran dokumentumokban tartják a szabályzatokat, mappákban a bizonyítékokat, táblázatokban a kockázatokat, projektkezelő eszközökben pedig a javítási feladatokat. Az auditnarratívákat aztán ezekből a szétszórt forrásokból állítják össze újra. Egy újabb keretrendszer bevezetése gyakran ugyanazon információk újabb másolatát hozza létre.

A következmények túlmutatnak az adminisztratív ráfordításon. Különálló csapatok egymásnak ellentmondó utasításokat adhatnak a mérnököknek ugyanarról a hozzáférés-szabályozási folyamatról. Az egyik értékelés elavult architektúraleírást használhat, a másik az aktuális változatot. Egy kidolgozott jelentés elfedhet egy megoldatlan megvalósítási hiányosságot.

A gyakorlati alternatíva egy közös kontrollmodell keretrendszer-specifikus nézetekkel. A megvalósítást egyszer tartsa karban, csatolja hozzá a megfelelő bizonyítékokat, és külön értékelje, mely követelményeket támogatja. Ez csökkenti a párhuzamos kéréseket anélkül, hogy eltüntetné a hatókörök, az értékelési időszakok vagy a jogi kötelezettségek közötti különbségeket.

Határozza meg az alkalmazhatóságot, mielőtt az MI-t a kontrollok összerendelésére kérné

Kezdje a szervezeti határral: mely szolgáltatás, jogi személy, rendszerek, helyszínek és szolgáltatók tartoznak bele? Rögzítse a keretrendszer verzióját és azt, hogy az egyes kötelezettségek miért alkalmazandók. Ellenkező esetben az MI hihetőnek tűnő összerendeléseket állíthat elő a tényleges hatókörön kívül eső követelményekre.

A megkülönböztetések számítanak:

• A BSI IT-Grundschutz, amely a Secani dokumentált munkafolyamatainak egyik központi eleme, egy információbiztonsági módszertant ötvöz egy modulokból álló kompendiummal. Modellezze a hatókörbe tartozó célobjektumokat, és válassza ki az alkalmazandó modulokat, ahelyett hogy a kompendiumot egységes ellenőrzőlistaként kezelné.
• Az ISO/IEC 27001 egy meghatározott alkalmazási területű információbiztonsági irányítási rendszerre vonatkozik. Az irányítási rendszerre vonatkozó követelmények, a kockázatkezelés, az alkalmazhatósági nyilatkozat, a belső audit és a vezetőségi átvizsgálás különálló eredménytermékek maradnak.
• A NIS2 nemzeti jogszabályokon keresztül valósul meg. Az alkalmazhatóság az ágazattól, a mérettől, a szolgáltatásoktól és a bevonási szabályoktól függ; a tanúsítás nem igazolja a megfelelést.
• A DORA elsősorban meghatározott pénzügyi szervezetekre vonatkozik. Az IKT-szolgáltatókat szerződéses kötelezettségek terhelhetik, míg a kijelölt kritikus szolgáltatókra külön felügyeleti rendszer vonatkozik.
• A GDPR szerinti kötelezettségek az adatkezeléstől és a szervezeti szerepköröktől függenek. A biztonsági bizonyítékok önmagukban nem igazolják a rendeletnek való megfelelést.

Az alkalmazhatóságot jóváhagyott bemenetként kezelje, ne a modell által csendben levont következtetésként. Bizonytalan esetekben hozzon létre kifejezett értelmezési feladatot egy felelős ellenőrrel.

Építse fel a bizonyítékmodellt, mielőtt dokumentumokat generálna

Egy gyakorlati minimális modellnek meg kell különböztetnie a követelményt, a megvalósított kontrollt, az alátámasztó bizonyítékot és az átvizsgálási döntést. Egy feltöltött fájl önmagában nem kontroll, és egy jóváhagyott szabályzat sem bizonyítja, hogy az eljárás következetesen működik.

A függőségek is a modell részét képezik. Egy ügyfeleknek szóló alkalmazás támaszkodhat egy identitásszolgáltatóra, felhőinfrastruktúrára és egy menedzselt ügyfélszolgálati csapatra. Egy függőségből származó bizonyítékot nem szabad automatikusan a teljes szolgáltatásra vonatkozó bizonyítéknak tekinteni.

Ez a struktúra láthatóvá teszi a gyenge lefedettséget: egy hozzáférési szabályzat lehet aktuális, miközben a felülvizsgálati nyilvántartások hiányoznak, vagy egy konfigurációról készült képernyőkép csak egyetlen környezetre vonatkozhat.

Az MI-t összerendelési javaslatokra használja, ne automatikus egyenértékűsítésre

Az MI segíthet a releváns szakaszok kinyerésében, kapcsolatok javaslásában, a hiányzó alátámasztás azonosításában és a kontrollleírások megfogalmazásában. Azonosított forrásverziókat és a tényleges megvalósítást adja meg neki – ne csak a kontrollok címét.

Egy hasznos összerendelési javaslat elmagyarázza, melyik rész fedi át egymást, milyen bizonyíték támasztja alá ezt az átfedést, és mi marad kezeletlen. A kapcsolatok gyakran több-a-többhöz jellegűek: egy kontroll több követelményt támogat, egy követelményhez pedig több kontroll szükséges.

Az incidenskezelés jól szemlélteti a határt. Egy közös reagálási folyamat több keretrendszert is támogathat, de a bejelentési küszöbök, a címzettek, a kiváltó események és a határidők eltérhetnek. Az operatív folyamat újrahasznosítása nem teljesít minden bejelentési kötelezettséget.

Az ellenőröknek az újrahasznosítás jóváhagyása előtt ellenőrizniük kell a hiányzó hatókört, az egymásnak ellentmondó forrásokat, az elavult hivatkozásokat és a megalapozatlan állításokat. Az indoklást őrizze meg a kapcsolattal együtt, hogy egy későbbi keretrendszer- vagy megvalósítási változást megalapozottan lehessen értékelni. Operatív kockázatnyilvántartási útmutatónk ugyanezt az átvizsgált támogatás elvét alkalmazza a forgatókönyvekre és a kockázatkezelési döntésekre.

A bizonyítékgyűjtés és a szövegezés eltérő garanciákat igényel

A bizonyítékokat mérvadó rendszerekből, ellenőrzött folyamat keretében gyűjtse, legyen szó kézi exportokról vagy egy értékelt gyűjtési mechanizmusról. Rögzítse, ki gyűjtötte, mikor, és milyen sokaságra terjed ki. Ne feltételezze, hogy egy MI-képességekkel rendelkező termék automatikusan hozzáfér az operatív rendszerekhez.

Az MI-vel támogatott adatkinyerésnek meg kell őriznie azt a forrásszakaszt vagy nyilvántartást, amely az egyes következtetéseket alátámasztja. Különösen gondosan vizsgálja át, ha a dokumentumok egymásnak ellentmondó állításokat tartalmaznak, a képernyőképekről hiányzik a dátum, vagy az exportált adatokból kimaradnak bizonyos fiókok. A hiányzó bizonyítékból kérdésnek vagy feladatnak kell lennie – nem pedig egy kitalált állításnak arról, hogy a kontroll működik.

A generált dokumentációhoz egységes szerkezetet használjon: cél, hatókör, megvalósítás, gazda, bizonyíték, kivételek és átvizsgálási állapot. Különböztesse meg a szándékolt eljárásokat a megfigyelt működéstől. A jelentéseknek átvizsgált kontrollokat kell használniuk, és fel kell tárniuk a lényeges hiányosságokat, ahelyett hogy a vázlatos javaslatokat végleges megfelelőségigazolássá alakítanák.

A feltöltött anyagokat is megbízhatatlan bemenetként kell kezelni. A dokumentumokba ágyazott utasítások nem írhatják felül az átvizsgálási munkafolyamatot, és nem engedélyezhetnek műveleteket. Az elemzéshez adott olvasási hozzáférés nem jelenthet engedélyt a kontrollok módosítására, a döntések jóváhagyására vagy a jelentések terjesztésére.

Kidolgozott példa: egy hozzáférési felülvizsgálat, több felhasználás

Vegyünk egy szemléltető SaaS-csapatot, amely egy éles szolgáltatást dokumentál. Tegyük fel, hogy van egy jóváhagyott hozzáférési szabályzata, egy dátummal ellátott identitásszolgáltatói exportja, negyedéves felülvizsgálati nyilvántartásai, valamint egy nyitott feladata két szükségtelen adminisztrátori fiók eltávolítására. Megtakarításokat vagy termékteljesítményt nem feltételezünk.

A csapat először meghatározza a határt: az éles fiókok beletartoznak; egy különálló kutatási környezet nem. Ezután a szabályzatot a szándékolt felülvizsgálati folyamathoz, az elvégzett nyilvántartásokat pedig a felülvizsgálati tevékenységhez kapcsolja.

Az MI javaslatot tesz egy hozzáférés-szabályozási leírásra és lehetséges keretrendszer-összerendelésekre. Az ellenőr három problémát talál:

• Az export lefedi az emberi fiókokat, de a szolgáltatási identitásokat nem.
• A felülvizsgálati nyilvántartások mutatják a döntéseket, de a két adminisztrátori fiók eltávolításának bizonyítéka hiányzik.
• A szabályzat negyedéves felülvizsgálatokat ír elő, miközben az egyik elvégzett felülvizsgálat késve történt meg.

Az ellenőr jóváhagyja az alátámasztott leírást, elutasítja azt az állítást, hogy minden kiemelt jogosultságú hozzáférést felülvizsgálnak, és feladatokat hoz létre a szolgáltatási identitások lefedésére és az eltávolítás ellenőrzésére. A keretrendszer-specifikus összerendelések megőrzik ezeket a korlátokat.

Az eredmény egy átvizsgált kontrollnyilvántartás körülhatárolt bizonyítékokkal és nyitott javítási feladatokkal. Hasznosabb, mint több magabiztos narratíva, mert a mérnökök tudják, mit kell kijavítaniuk, az auditorok pedig megvizsgálhatják, mi támasztja alá az állítást.

Tegye eseményvezéreltté a megfelelés karbantartását

A folyamatos megfelelésnek azt kell jelentenie, hogy a bizonyítékokat és a döntéseket a releváns változások bekövetkeztével karbantartják. Nem szabad azt sugallnia, hogy az MI folyamatosan bizonyítja minden kontroll hatékonyságát.

Gyakorlati ajánlásként kombinálja az ütemezett felülvizsgálatokat változáshoz kötött kiváltó eseményekkel: új szolgáltató, megváltozott hitelesítési kialakítás, módosított keretrendszer, lejárt bizonyítéki időszak vagy jelentős incidens. Azonosítsa az érintett kontrollokat, összerendeléseket, gazdákat és jelentéseket, majd szükség esetén kérjen friss bizonyítékokat.

Tartsa külön az állapotokat: a javasolt, a bizonyítékra váró, az átvizsgált, a jóváhagyott és a nyitott javítású állapot nem olvadhat egyetlen zöld jelzésbe. Kövessen nyomon olyan mérőszámokat, mint a késedelmes felülvizsgálatok, a megalapozatlan állítások, a nyitott kivételek és a bizonyítékok kora. Ezek világosabban mutatják a munkaterhet és a megfelelőségigazolás minőségét, mint a dokumentumok száma.

Védje magát a megfelelési munkaterületet is

A megfelelési anyagok felfedik az architektúrát, a gyengeségeket, a belső folyamatokat és esetenként személyes adatokat is. A tárhely helye mellett értékelje a szolgáltatói hozzáférést, a további adatfeldolgozókat, a megőrzést, a törlést, a modellhasználati feltételeket és az alkalmazandó adattovábbítási megoldásokat. Az uniós vagy németországi adattárolási hely önmagában nem igazolja a szuverenitást vagy a GDPR-nak való megfelelést.

Alkalmazza a legkisebb jogosultság elvét, és válassza szét a szövegezést a jóváhagyástól. A bizonyítékok feltöltése előtt védje a hitelesítő adatokat és a szükségtelen személyes információkat. Követelje meg a lényeges változások nyomon követhetőségét, és határozza meg, hogyan kérdőjelezhetik meg az ellenőrök egy MI-következtetést. Az emberi jóváhagyásnak az alátámasztás megvizsgálását és a bizonytalanság feloldását kell jelentenie, nem egy várólista végigkattintását.

Kezdje egyetlen átvizsgálható munkafolyamattal

A Secani támogatja a fókuszált kezdést: modellezzen egy szolgáltatást vagy szervezeti egységet valós célobjektumok segítségével, kapcsolja össze rendszereivel és külső szolgáltatóival, és nevezze meg a gazdákat és az ellenőröket. Töltse fel a meglévő szabályzatokat, exportokat, képernyőképeket és leírásokat; kapcsolja őket azokhoz a követelményekhez, kontrollokhoz, rendszerekhez vagy döntésekhez, amelyeket alátámasztanak. Az MI-vel támogatott javaslatokat vázlatként használja, ellenőrizze a forrásaikat, és őrizze meg a megjegyzéseket, a jóváhagyásokat és az időbélyegeket. A hiányzó vagy elavult bizonyítékokból hozzon létre feladatokat, ahelyett hogy dokumentumokba temetve hagyná őket.

Az első ciklushoz válasszon ki egy kontrollcsaládot és egy rövid felülvizsgálati ütemet. A bővítés előtt követeljen meg egyértelmű megvalósítási leírást, aktuális alátámasztó bizonyítékokat, átvizsgált összerendeléseket és kijelölt felelőssel rendelkező hiányosságokat. A Secani dokumentációja bemutatja ezt a kezdő munkafolyamatot. A siker egy nyomon követhető döntés, amelyet a következő ellenőr is reprodukálni tud – nem csupán a generált szöveg nagyobb gyűjteménye.