Túl a táblázatos megfeleltetéseken

A szervezetek ritkán működnek egyetlen kiberbiztonsági keretrendszer alatt. Egy SaaS-szolgáltató törekedhet ISO 27001 tanúsításra, ügyfelei SOC 2 jelentést kérhetnek tőle, és az adatkezelési tevékenységei miatt GDPR-kötelezettségei is vannak. A szolgáltatásaitól, ágazatától, méretétől és a nemzeti átültetéstől függően a NIS2 is vonatkozhat rá. Egy védelmi beszállító a szabványok és szerződéses követelmények más kombinációjával szembesül, de ugyanazzal a mérnöki problémával találkozik: az egymást átfedő követelményeket egymástól elszigetelt munkaként tartják karban.

A táblázatos megfeleltetések segítenek ezt az átfedést azonosítani. Kevésbé megbízhatóvá válnak, ha egy „kapcsolódó” jelölésű sort „teljesítettként” értelmeznek, vagy ha senki sem tudja megmondani, mely dokumentumverziókat hasonlították össze.

A műszaki cél nem a keretrendszer-specifikus részletek megszüntetése. Hanem egy olyan újrafelhasználható megfeleltetési réteg kiépítése, amely megőrzi ezeket: mi osztható meg, mi marad lefedetlen, honnan ered a kapcsolat, és ki vizsgálta felül.

A NIST két kezdeményezése a probléma különböző részeivel foglalkozik: a National Online Informative References Program, röviden OLIR, és az OSCAL Control Mapping Model. Szerepük megértése segít a csapatoknak abban, hogy a statikus megfeleltetésektől karbantartható megfelelőségi infrastruktúra felé lépjenek.

Először válassza szét a követelményeket, a kontrollokat és a bizonyítékokat

Sok megfeleltetési projekt azért bukik el, mert három különböző objektumot ugyanabba a táblázatoszlopba tesz.

A követelmény egy forrásdokumentumból származó kötelezettséget, elvárást vagy kívánt eredményt ír le. A kontroll a szervezet válaszát írja le: egy tevékenységet, műszaki mechanizmust vagy irányítási folyamatot. A bizonyíték azt a következtetést támasztja alá, hogy ez a válasz létezik-e és a szándéknak megfelelően működik-e.

Több keretrendszer is foglalkozhat például a hozzáférés-kezeléssel. Egy szervezet kontrollja előírhatja a kiemelt hozzáférések negyedéves felülvizsgálatát a teljes éles környezetben. Bizonyíték lehet a felülvizsgált fióklista, a jóváhagyási rekordok, a kivételjegyek és annak igazolása, hogy a nem megfelelő jogosultságokat visszavonták.

Ezeknek az objektumoknak külön kapcsolatokra van szükségük:

• A követelmény–követelmény megfeleltetések a dokumentumforrások közötti átfedést azonosítják.
• A követelmény–kontroll megfeleltetések azt írják le, hogyan kezeli a szervezet egy elvárást.
• A kontroll–rendszer kapcsolatok azt rögzítik, hol működik a megvalósítás.
• A bizonyítéki kapcsolatok azt mutatják, mi támaszt alá egy megvalósítási vagy értékelési következtetést.

Egy közzétett megfeleltetés általában az első kapcsolatban segít. A másik hármat nem igazolja.

Ez a megkülönböztetés a különböző típusú bizonyosságok közötti helytelen összehasonlításokat is megakadályozza. Az ISO 27001 egy meghatározott hatókörű információbiztonsági irányítási rendszerre vonatkozik. A SOC 2 attesztációs jelentés, nem tanúsítás. A GDPR az adatkezelési tevékenységek és a szervezeti szerepkörök szerint ír elő kötelezettségeket. Egy tanúsítvány vagy jelentés nem igazolja a rendeletnek való megfelelést.

A hatókörnek ezért együtt kell járnia a megfeleltetési döntéssel. Egy éles környezeti hozzáférés-felülvizsgálat alátámaszthatja a SaaS-szolgáltatás értékelését, miközben semmit sem mond egy kizárt leányvállalatról vagy egy nem kapcsolódó HR-rendszerről. A hasonló megfogalmazás nem hidalhatja át ezt a határt.

Mivel járul hozzá az OLIR: megfeleltetési tudás kontextussal

Az OLIR szabványosított módot biztosít a szakértők számára arra, hogy leírják a referenciadokumentumok elemei és a támogatott NIST fókuszdokumentumok közötti kapcsolatokat. Fókuszdokumentum lehet például a NIST Cybersecurity Framework, a NIST SP 800-53 vagy a NIST AI Risk Management Framework.

Egy informatív hivatkozás összekapcsolhat például egy iparági követelményt egy NIST CSF 2.0 alkategóriával. Ez az elemek közötti kapcsolatra vonatkozó állítás, nem annak bizonyítéka, hogy egy szervezet bármelyiket megvalósította.

A program hasznos kontextust ad ezekhez az állításokhoz:

• Sablonok és konvenciók a támogatott fókuszdokumentumokhoz
• A megfeleltetett dokumentumokat és a beküldő szervezetet azonosító metaadatok
• Központi nyilvános katalógus
• Tervezet és végleges közzétételi státusz
• Nyilvános felülvizsgálati folyamat
• Információ arról, hogy a beküldő a megfeleltetett dokumentum tulajdonosa-e, vagy harmadik fél

A NIST három OLIR megfeleltetési stílust különböztet meg: a fogalmi megfeleltetést, a halmazelméleti kapcsolatmegfeleltetést és a támogató kapcsolatmegfeleltetést. Céljuk eltérő. Egy fogalmi megfeleltetés segíthet eligazodni az összefüggő gondolatok között, míg egy halmazelméleti kapcsolat konkrétabb állítást fogalmazhat meg arról, hogyan fedi át egymást két elem.

A megvalósítás tervezésénél ez a különbség számít. Az, hogy „ezek az elemek az incidenskezelésre vonatkoznak”, hasznos a feltáráshoz, de nem elegendő annak eldöntéséhez, hogy egy folyamat lefedi-e egy másik követelmény bejelentési feltételeit, címzettjeit vagy határidőit.

Az OLIR közzétételi státuszát és szerzőségét felülvizsgálati bemenetként kezelje. Egy kiadói tulajdonú megfeleltetés értékes betekintést nyújthat a szándékolt jelentésbe, de relevanciája továbbra is a vizsgált verzióktól és hatókörtől függ. A végleges közzététel nem fordítható le olyan belső következtetésre, hogy minden megfeleltetett kötelezettség teljesül.

Az OLIR-anyagok beszerzésének eredménye egy forrásnyilvántartás legyen: a felhasznált hivatkozás, annak státusza, a dokumentumverziók, a szerző fél, a lekérés dátuma és a tervezett felhasználás. Az eredetit tartsa meg minden normalizált ábrázolás mellett, hogy a felülvizsgálók rekonstruálni tudják az importálást.

Mivel járul hozzá az OSCAL: számítható kapcsolati modell

Az OSCAL, az Open Security Controls Assessment Language géppel olvasható modelleket biztosít kontrollkatalógusokhoz, profilokhoz, rendszerbiztonsági tervekhez, értékelési tervekhez, értékelési eredményekhez és kapcsolódó megfelelőségi információkhoz. Tágabb célja, hogy a biztonsági dokumentáció strukturált és cserélhető legyen, ne pedig a dokumentum elrendezésétől függjön.

Az OSCAL Control Mapping Model a dokumentumforrások kontrolljai és kontrollelemei közötti kapcsolatokat ábrázolja. Támogatja a JSON, YAML vagy XML formátumú, géppel olvasható ábrázolást, beleértve az egy teljes kontrollnál finomabb szintű kapcsolatokat is.

A modell kapcsolati szókincse tartalmazza az equal-to, equivalent-to, subset-of, superset-of, intersects-with és no-relationship értékeket. Ezek nem válhatnak a „nagyjából hasonló” egymással felcserélhető címkéivé.

Az irány számít. Az a forrás, amely egy cél részhalmaza, az összehasonlítás megfordításakor bővebb halmazzá válik. Egy importáló, amely a kapcsolat módosítása nélkül cseréli fel a dokumentumok helyét, megváltoztatja a jelentést.

A modell különbséget tud tenni olyan megfeleltetési alapok között, mint a szintaktikai hasonlóság, a szemantikai jelentés és a funkcionális eredmény. Két állítás közös terminológiát használhat, mégis eltérő intézkedéseket igényelhet; a különbözően megfogalmazott állítások pedig hasonló biztonsági funkciót szolgálhatnak.

A modell a származásra, a felelős felekre, a státuszra, a megbízhatóságra, a lefedettségre, a hiányosságokra és a megfeleltetési módszerekre vonatkozó kiegészítő kontextust is képes ábrázolni. Bizonyos működési információk inkább a körülvevő felülvizsgálati rendszerbe tartozhatnak, mint egy adott sémamezőbe. A megvalósított ábrázoláshoz kövesse a NIST modelldokumentációját, és rögzítse az eszközei által használt modell- vagy sémaverziót.

A géppel olvasható nem jelenti azt, hogy automatikusan helyes. A sémavalidálás ellenőrizheti a struktúrát és a megengedett értékeket. Azt azonban nem tudja megállapítani, hogy egy elemző két követelményre vonatkozó értelmezése megalapozott-e.

Az OLIR és az OSCAL különböző problémákat old meg

Az OLIR egy program, közzétételi folyamat, katalógus és a megfeleltetési állítások forrása. Az OSCAL a kapcsolatok tárolására, cseréjére és feldolgozására szolgáló műszaki ábrázolást biztosítja.

Egy szervezet ezért használhatja az OLIR-t egyik külső megfeleltetési forrásként, az OSCAL-t pedig kanonikus belső ábrázolásként. További források lehetnek a kiadók által biztosított megfeleltetések, a szabályozási elemzések, az ügyfélkövetelmények és a belsőleg felülvizsgált szakértői megfeleltetések.

Az OSCAL hatóköre tágabb, mint az OLIR NIST-orientált beküldési struktúrája. Megfelelő katalógusok vagy profilok közvetlen kapcsolatokat is ábrázolhatnak, például az IT-Grundschutz és az ISO 27001, a NIS2 és egy belső kontrollkönyvtár, vagy egy ügyfélkövetelmény és egy szervezeti kontroll között. Az ilyen kapcsolatok nem feltétlenül minősülnek OLIR-beküldésnek.

Egy gyakorlati architektúra így néz ki:

External and internal mapping sources
                 ↓
Source preservation and import
                 ↓
Document, version, and identifier resolution
                 ↓
Normalized mapping collections
                 ↓
Technical validation and expert review
                 ↓
Controls, implementations, evidence, and assessments
                 ↓
Gap analysis and change-impact work

A forrásállításokat tartsa külön a belső elfogadási döntésektől. Egy külső kiadó állíthat egyenértékűséget, miközben egy belső felülvizsgáló arra jut, hogy a szervezet hatókörében csak részleges újrafelhasználás megfelelő. Mindkét rekordot őrizze meg, ahelyett hogy csendben átírná a külső megfeleltetést.

Építse a megfeleltetési folyamatot kifejezett döntések köré

Tisztázza az alkalmazhatóságot a megfogalmazások összevetése előtt

Kezdjen a kötelezettségek és a bizonyossági célok nyilvántartásával. Minden forráshoz rögzítse az alkalmazandó verziót, a szervezeti szerepkört, az érintett szolgáltatásokat, a földrajzi kontextust, az értékelési határt és a felvétel indokát.

Ez megakadályozza, hogy egy ügyfélelvárást törvényi kötelezettségnek tekintsenek. Egy NIS2 hatálya alá tartozó ügyfél előírhat ellátásilánc-követelményeket anélkül, hogy beszállítója közvetlenül az irányelv hatálya alá kerülne. A NIS2 alkalmazhatósága a vonatkozó nemzeti jog szerinti önálló elemzést igényel.

Hasonlóképpen ne vegyen fel minden SOC 2 kategóriát pusztán azért, mert létezik. Rögzítse a tervezett megbízás hatókörét. Az ISO 27001 esetében őrizze meg az irányítási rendszerre vonatkozó követelményeket, a kockázatkezelést és az alkalmazhatósági nyilatkozat döntéseit, ahelyett hogy a szabványt egy A melléklet szerinti ellenőrzőlistára szűkítené.

Az eredmény egy hatóköri mátrix, amely megmutatja a felülvizsgálóknak, mely megfeleltetések lehetnek relevánsak, mielőtt időt fordítanának az értelmezésükre.

Normalizálja a dokumentumokat a struktúrájuk elvesztése nélkül

Minden importált azonosítót a megfelelő dokumentumkiadáshoz rendeljen. Őrizze meg a fejezethierarchiát, a kontrollazonosítókat, ahol elérhetők, az állításazonosítókat, valamint az eredeti hivatkozási helyet.

Egy hasznos belső kulcs a dokumentum azonosságát, verzióját és az elemazonosítót egyesíti. Egy megjelenítési címke önmagában nem biztonságos: az azonos kontrollszámok a különböző kiadásokban vagy publikációkban eltérő jelentésűek lehetnek.

Szükség esetén bontsa az összetett követelményeket felülvizsgálható elemekre. Ha egy bekezdés szabályzatot, kijelölt felelősségi köröket, tesztelést és jelentéstételt ír elő, egyetlen, az egész bekezdésre vonatkozó megfeleltetés három lefedetlen elvárást rejthet el. Őrizze meg a szülőkapcsolatot, hogy a felhasználók rekonstruálni tudják a forrás kontextusát.

A forrásszöveg tárolásakor tartsa tiszteletben a közzétételi és licencfeltételeket. Ahol a teljes szöveg tárolása nem megfelelő, a megengedett azonosítókat, hivatkozásokat és eredeti elemzési jegyzeteket őrizze meg.

Generáljon jelölteket, majd vizsgálja felül az állításokat

A jelöltek generálása épülhet meglévő megfeleltetésekre, közös terminológiára, biztonsági célokra vagy MI által támogatott elemzésre. Kimenete egy felülvizsgálati sor legyen, ne jóváhagyott megfeleltetési gyűjtemény.

Minden jelentős következménnyel járó állításnál a felülvizsgálóknak a tényleges elemeket kell megvizsgálniuk, és rögzíteniük kell a következőket:

• Kapcsolattípus és irány
• Az összehasonlítás alapja
• Feltételezések és hatóköri korlátozások
• Közös elvárások és lefedetlen különbségek
• A forrás származása és a megfeleltetési módszer
• Felülvizsgáló, döntés és a felülvizsgálat dátuma

A megbízhatósági szint hasznos a felülvizsgálat priorizálásához, de nem lefedettségi százalék. Egy felülvizsgáló nagyon biztos lehet abban, hogy két követelmény csak részben fedi át egymást. Az állításba vetett megbízhatóságot tartsa külön a megvalósítás állapotától és a bizonyítékok elégségességétől.

Egy jelölt elutasítása is értékes. Egy dokumentált no-relationship döntés megőrzése segít megakadályozni, hogy a jövőbeli importok vagy automatikus javaslatok újra és újra ugyanazt a félrevezető egyezést kínálják.

Validálja a struktúrát és a jelentést is

A jóváhagyás előtt futtasson műszaki ellenőrzéseket: a feloldatlan hivatkozásoknak, hiányzó verzióknak, érvénytelen kapcsolatértékeknek, duplikátumoknak és váratlan irányfordításoknak mind láthatónak kell lenniük.

Ezután végezzen szemantikai felülvizsgálatot. Kérdezze meg, hogy a kapcsolat megőrzi-e a szereplőt, az előírt intézkedést, a védett objektumot, az időzítést, a feltételeket és a várt eredményt. Jogi követelményeknél vonjon be olyan személyt, aki képes a kötelezettség értékelésére, ahelyett hogy kizárólag a biztonsági szakterületen belüli hasonlóságra hagyatkozna.

Használjon olyan munkafolyamat-állapotokat, mint a javasolt, felülvizsgálat alatt, meghatározott felhasználásra jóváhagyott, elutasított és felváltott. Ezek gyakorlati működési ajánlások, nem általános törvényi követelmények. Egy jóváhagyásnak meg kell határoznia, mit tesz lehetővé: feltárást, tervezést, a bizonyítékok újrafelhasználását vagy egy értékelési következtetés alátámasztását.

Tesztelje az importokat és exportokat mérnöki komponensként

Mielőtt a normalizált megfeleltetéseket a jelentéstételbe vinné, készítsen egy kis regressziós tesztkészletet szándékosan nehéz esetekkel: egy megfordított részhalmaz-kapcsolattal, egy feloldatlan állításazonosítóval, két egymásnak ellentmondó forrásállítással és egy felváltott kiadásra mutató megfeleltetéssel. Minden esethez határozza meg a várt eredményt. Egy importnak karanténba kell helyeznie a kétértelmű rekordokat, ahelyett hogy csendben a legújabbnak tűnő dokumentumot választaná, vagy elvetné az ellentmondó állítást.

Az ismételt importokat is tesztelje. Ugyanannak a gyűjteménynek a kétszeri importálása nem hozhat létre duplikált munkát, és nem írhat felül egy belső jóváhagyást. Használjon stabil azonosítókat, és őrizze meg a módosítási előzményeket, hogy egy megváltozott külső állítás felülvizsgálati eseménnyé váljon, ne láthatatlan cserévé.

Az adatcseréhez teszteljen egy teljes oda-vissza utat: exportáljon egy jóváhagyott mintát, importálja egy tiszta tesztkörnyezetbe, és hasonlítsa össze az azonosítókat, az irányt, az indoklást és a származást. Ha a munkafolyamat metaadatai nem vihetők át a választott ábrázolásban, dokumentálja a kísérő formátumot és annak korlátait. Ellenkező esetben egy technikailag érvényes export éppen azt a kontextust veszítheti el, amely a megfeleltetést megbízhatóvá tette.

Ezek gyakorlati mérnöki biztosítékok. Kiszámíthatóvá teszik az automatizálást anélkül, hogy azt sugallnák, hogy szoftvertesztekkel validálni lehet a mögöttes jogi vagy biztonsági értelmezést.

Hozzon létre közös kontrollokat a keretrendszerek ellaposítása nélkül

Miután a követelmények közötti kapcsolatok világossá váltak, határozzon meg egy közös kontrollkönyvtárat a valós működési tevékenységek köré. Az olyan területek, mint az identitáskezelés, a sebezhetőségkezelés, az incidenskezelés, a beszállítói bizonyosság és a helyreállítás, hasznos kiindulópontok.

Minden kontrollnak szüksége van egy felelős gazdára és egy olyan megvalósítási leírásra, amelyet egy másik mérnök végre tud hajtani. Az, hogy „a hozzáféréseket rendszeresen felülvizsgálják”, túl homályos. Határozza meg a lefedett rendszereket és fióktípusokat, a felülvizsgálót, a ritmust, a döntési kritériumokat, a kivételkezelési folyamatot és a keletkező bizonyítékokat.

Ne feltételezze, hogy a „legszigorúbb követelmény” automatikusan minden mást is teljesít. A követelmények összemérhetetlenek is lehetnek: a hosszabb naplómegőrzés segíthet egy bizonyossági célt, miközben a szükségességre és a hozzáférésre vonatkozó adatvédelmi kérdéseket vet fel. A gyakoribb felülvizsgálat nem pótolhat egy hiányzó jogi értékelést.

Használjon közös alapszintet kifejezett kiegészítésekkel:

A GDPR szerint az adatkezelés biztonsága kockázatalapú. A közös biztonsági kontrollok alátámaszthatják a 32. cikk teljesítését, de a jogalap, az átláthatóság, az adatkezelési nyilvántartások, az érintetti jogok, a szükség esetén elvégzendő adatvédelmi hatásvizsgálatok és a nemzetközi adattovábbítások saját értékelést igényelnek. Egy eszköznyilvántartás információt adhat az adatkezelési nyilvántartáshoz, de nem helyettesíti annak céljait, adatkategóriáit, címzettjeit és megőrzési információit.

Az ISO 27001 hasonlóképpen olyan irányítási rendszerbeli munkát is tartalmaz, amely pusztán a működési kontrollokból nem vezethető le. A hatókör, 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.

Használja fel újra a bizonyítékokat az értékelési kontextuson keresztül

Egy központi tár csak akkor csökkenti a párhuzamosságot, ha a felülvizsgálók értik, mit bizonyítanak az egyes elemek.

Gyakorlati ajánlásként rögzítse a bizonyíték felelősét, a gyűjtés dátumát, a lefedett időszakot, az érintett rendszereket, a forrást, a verziót, a hozzáférési korlátozásokat és az általa alátámasztott következtetést. A mögöttes elemet tartsa külön az értékelési megállapítástól.

Egy negyedéves hozzáférés-felülvizsgálati export megmutathatja, mely jogosultságok léteztek egy adott napon. A jóváhagyási rekord azt mutatja, ki vizsgálta felül őket. A javítási jegyek azt mutatják, hogy a nem megfelelő hozzáféréseket visszavonták-e. Egyik elem sem feltétlenül bizonyítja önmagában a teljes kontrollt.

Az idő is befolyásolja az újrafelhasználást. Egy SOC 2 Type II megbízás egy időszakon átívelő működést vizsgál, míg egy adott időpontra vonatkozó elem szűkebb intervallumot fed le. A gyűjtés tervezésekor különböztesse meg a kontroll gyakoriságát, az értékelési időszakot és az elem frissességét. Egy friss képernyőkép nem pótolja a hónapokra visszamenőleg hiányzó végrehajtási rekordokat.

Az értékelési hatókör ugyanilyen fontos. Ellenőrizze, hogy a bizonyíték lefedi-e a releváns szolgáltatást, populációt, környezetet és kontrollváltozatot. Az ügyfél által kezelt jogosultságokat válassza külön a szolgáltató által kezelt adminisztratív hozzáféréstől, ahelyett hogy egyetlen exportot mindkettő bizonyítékaként kezelne.

A bizonyítékok érzékeny információkat vagy személyes adatokat tartalmazhatnak. Alkalmazzon megfelelő hozzáférés-szabályozást, minimalizálja a szükségtelen tartalmat, és tudatosan határozza meg a megőrzést. Egy elem újrafelhasználása nem jelenti azt, hogy korlátozás nélküli eredetijét minden felülvizsgálóhoz eljuttatják.

Az eredmény minden közös kontrollhoz egy bizonyítéki terv: mit gyűjtenek, mikor, honnan, ki, és mely értékelési kérdéseket támaszthat alá.

Hangolja össze ezt a tervet egy közös bizonyossági naptárral. Az egymáshoz kapcsolódó felelősi interjúkat és bizonyítékellenőrzéseket ütemezze együtt, ahol a hatókörük egybeesik, miközben az értékelési következtetéseket külön tartja. Mielőtt az újrafelhasználásra támaszkodna, egyeztesse a bizonyítékokra vonatkozó elvárásokat az érintett értékelőkkel. Egy közös gyűjtési folyamat több megbízást is támogathat, de nem kényszerítheti az egyes értékelőket ugyanannak a mintának az elfogadására, és nem szüntetheti meg a további tesztelést. Az időszakos kontrolloknál a gyűjtést a végrehajtás idejére ütemezze, ne várjon vele az audit közeledtéig.

Kidolgozott példa: egy incidenskezelési folyamat, több bejelentési döntés

Vegyünk egy szemléltető, 45 munkavállalós SaaS-szervezetet. Tegyük fel, hogy éles szolgáltatása egy ISO 27001 szerinti IBIR hatókörébe tartozik, SOC 2 Security megbízásra készül, és különböző tevékenységeiben adatkezelőként és adatfeldolgozóként is kezel személyes adatokat. Tegyük fel azt is, hogy egy alkalmazhatósági értékelés megállapította a NIS2 szerinti kötelezettségeit a vonatkozó nemzeti átültetés alapján.

Ezek forgatókönyvbeli feltételezések, nem állítások a tipikus létszámról, a jogi alkalmazhatóságról vagy a projektráfordításról.

A szervezet az incidenskezelés köré importál megfeleltetési jelölteket, és meghatároz egy közös kontrollt, az IR-01-et: a bejelentett biztonsági eseményeket osztályozzák, incidensfelelőst rendelnek hozzájuk, kivizsgálják, elszigetelik és a lezárásig dokumentálják.

Ez a kontroll az egész programban hasznos, de a megfeleltetési felülvizsgálat több különálló elemet azonosít:

A csapat ezért az incidenskezelési folyamat konkrét elemeit felelteti meg, ahelyett hogy azt állítaná, hogy az IR-01 minden kapcsolódó kötelezettséget teljes mértékben teljesít.

A személyesadat-incidensek esetében a GDPR 33. cikke különbséget tesz a szerepkörök között. Az adatfeldolgozó indokolatlan késedelem nélkül értesíti az adatkezelőt. Az adatkezelő indokolatlan késedelem nélkül, és ha lehetséges, legkésőbb 72 órával azután, hogy tudomást szerzett az incidensről, értékeli a felügyeleti hatóság értesítését, kivéve, ha az incidens valószínűleg nem jár kockázattal a természetes személyek jogaira és szabadságaira nézve. Magas kockázat esetén a 34. cikk alapján – annak kivételei mellett – az érintettek tájékoztatása is szükséges lehet.

A NIS2 23. cikke szerinti jelentős incidensek esetében az uniós bejelentési struktúra 24 órás korai figyelmeztetést, 72 órás bejelentést és általában a bejelentést követő egy hónapon belüli zárójelentést tartalmaz. A szervezet ellenőrzi az alkalmazandó nemzeti és ágazati szabályokat, ahelyett hogy ezt az összefoglalót tekintené teljes bejelentési eljárásának.

Az incidensrekord ennek megfelelően külön tartalmazza a kiváltó okok értékelését és a tudomásszerzés időbélyegeit. Ahol több kötelezettség is alkalmazandó, határidőik párhuzamosan futnak. Az ISO-orientált elszigetelési munka nem halasztja el a jogi bejelentési döntést.

A bizonyítékcsomag tartalmazza a jegy előzményeit, a döntési naplót, a kommunikációs jóváhagyásokat, a benyújtási rekordokat ott, ahol bejelentés történt, és az indoklást ott, ahol nem volt szükség bejelentésre. Egy asztali gyakorlat teszteli az elágazási logikát a biztonsági, jogi, szolgáltatásüzemeltetési és kommunikációs résztvevőkkel.

A megfeleltetés eredménye pontos: a reagálási mechanizmust újra fel kell használni, a különálló bejelentési kötelezettségeket meg kell őrizni, és a megvalósítást és a bizonyítékokat is értékelni kell. A fennmaradó hiányosságok felelőshöz rendelt feladatokká válnak – például egy nem tesztelt hatósági kapcsolattartási útvonal vagy az adatfeldolgozótól az adatkezelő felé történő eszkaláció hiányzó utasításai.

Tegye a változáshatás-elemzést elsőrendű munkafolyamattá

Egy megfeleltetési könyvtár megbízhatatlanná válik, ha csak a kezdeti beállításkor használt keretrendszerek nevét rögzíti.

Ha egy forrás megváltozik, ne csak az azonosítókat hasonlítsa össze. A követelmények szétválhatnak, összeolvadhatnak, átnevezhetik, kibővíthetik vagy áthelyezhetik őket anélkül, hogy a számozás ezt egyértelműen jelezné. Hozzon létre dokumentumszintű változásrekordot, és azonosítson minden olyan megfeleltetést, amely a megváltozott elemekhez kapcsolódik.

Egy gyakorlati frissítési sorrend:

1. Őrizze meg az előző kiadást és a jóváhagyott megfeleltetéskészletet.
2. Importálja az új kiadást különálló azonosítókkal és verziómetaadatokkal.
3. Azonosítsa a megváltozott elemeket és az érintett kapcsolatokat.
4. Jelölje meg felülvizsgálatra az érintett elfogadási döntéseket.
5. Értékelje újra a kontrollokat, a bizonyítéki terveket és a keretrendszer-specifikus kiegészítéseket.
6. Hagyja jóvá a módosított döntéseket, és őrizze meg a felváltott előzményeket.

A működési változásoknak ugyanezt a folyamatot kell elindítaniuk. Egy új felhőszolgáltató bevonása, az identitásarchitektúra megváltoztatása vagy egy szolgáltatás hatókörbe vonása érvénytelenítheti a bizonyítékok újrafelhasználását akkor is, ha a keretrendszer nem változott.

A származtatott megfeleltetések különös gondosságot igényelnek. Az OLIR képes Derived Relationship Mappings előállítására annak összehasonlításával, hogyan viszonyul két referenciadokumentum egy közös fókuszdokumentumhoz. A NIST ezeket nem hiteles kiindulópontokként írja le, nem pedig ellenőrzött közvetlen megfeleltetésként. Ha A kapcsolódik C-hez és B is kapcsolódik C-hez, abból nem következik, hogy A és B egyenértékű.

A származtatott kapcsolatokat a vizsgálatok priorizálására használja. Ne terjesszen tovább megfelelőségi következtetéseket egy gráfon pusztán azért, mert létezik egy útvonal.

Próbálja ki a megfeleltetési réteget, mielőtt mindent migrálna

Válasszon ki egy reprezentatív szolgáltatást és néhány olyan kontrollterületet, ahol érdemi átfedés és látható különbségek is vannak. A hozzáférés-felülvizsgálatok, a beszállítókezelés és az incidenskezelés hasznos jelöltek, mert felszínre hozzák a hatóköri, felelősségi, bizonyítéki és jogi értelmezési kérdéseket.

A pilotnak behatárolt, átvizsgálható eredménytermékeket kell előállítania:

• Alkalmazhatósági és hatóköri nyilvántartás
• Verziózott forrásdokumentumok vagy megengedett forráshivatkozások
• Felülvizsgált megfeleltetési állítások származással és indoklással
• Közös kontrollok felelősökkel és működési eljárásokkal
• Keretrendszer-specifikus kiegészítések és nyitott hiányossági feladatok
• Bizonyítéki tervek és minta értékelési döntések
• Tesztelt frissítési eljárás

A pilotot aszerint értékelje, hogy egy másik felülvizsgáló reprodukálni tudja-e a következtetéseit. Meg tudja-e magyarázni, miért hagytak jóvá egy kapcsolatot, megtalálja-e a releváns forrást, azonosítja-e a lefedetlen elvárásokat, és látja-e, mely rendszereket fedik le a bizonyítékok?

Gyakori hibák: teljes kontrollterületek egyenértékűként való megfeleltetése, a kivételek megjegyzésekbe rejtése, a közös kontrollok elsődleges felelős nélkül hagyása, valamint a bizonyítékok elérhetőségének összekeverése a hatékony működéssel. További hiba egy nagy megfeleltetési könyvtár felépítése, mielőtt tesztelnék, hogy támogat-e egy tényleges értékelést.

A Secaniban egy megalapozott kezdő munkafolyamat a reprezentatív szolgáltatás és az azt támogató célobjektumok modellezése, a felelősök és felülvizsgálók megnevezése, valamint a meglévő bizonyítékok összekapcsolása a követelményekkel, kontrollokkal és döntésekkel. A hiányzó anyagok és a nyitott kérdések feladatokká válnak. Az MI által támogatott javaslatok tervezetek maradnak, amíg egy személy nem ellenőrzi a forrásokat, és nem hagyja jóvá a döntést nyomon követhető rekorddal. A Secani összekapcsolt bizonyítékokra és felülvizsgálatra épülő megközelítése a megfeleltetési döntéseket a forrásaikhoz, felelőseikhez és megvalósítási kontextusukhoz kötve tartja.

Egy konkrét keretrendszerpárosításhoz lásd: NIS2 és ISO 27001.

A megvalósítás előtt fontos kérdések

Megtarthatjuk a táblázatokat a pilot alatt?

Igen. Egy táblázat lehet felülvizsgálati felület, ha megőrzi a verziókat, az irányt, az indoklást, a hatókört és a származást. A korlát nem maga a rács, hanem a gyenge validálás, a különálló bizonyítékok és a nehézkes változáskezelés. Az adatmodellt a felület kiválasztása előtt határozza meg.

Jóváhagyhatja az MI a nagy megbízhatóságú megfeleltetéseket?

Nem. Egy generált javaslatba vetett megbízhatóság nem felelős felülvizsgálati döntés. Használja az MI-t a jelöltek és a különbségek felszínre hozására, majd követeljen meg emberi jóváhagyást a jelentős következménnyel járó megfeleltetési és bizonyítéki következtetésekhez.

Mi legyen a következő lépés?

Vegyen egy meglévő megfeleltetési sort, és rekonstruálja annak indoklását. Azonosítsa mindkét forrásverziót, olvassa el a megfeleltetett elemeket, fogalmazza meg a kapcsolatot és az irányt, dokumentálja a lefedetlen különbséget, és kapcsolja egy valós kontrollhoz és bizonyítékcsomaghoz. Ha ez a rekord kiállja a független felülvizsgálatot, ismételje meg a módszert a pilot egészében. Ez az újrafelhasználható megfelelőségi infrastruktúra alapja.