Matica zdieľanej zodpovednosti v cloude pre ISO, NIS2, DORA

COO fintech spoločnosti volá CISO v pondelok o 07:15.

Európsky bankový zákazník žiada dôkaz, že SaaS platforma spoločnosti dokáže splniť požiadavky DORA na riziká tretích strán v oblasti IKT. Obchodný tím už odoslal známy balík bezpečnostných podkladov dodávateľa: certifikát ISO, manažérske zhrnutie penetračného testu, certifikát kybernetického poistenia, oznámenie o ochrane údajov a správu o uistení poskytovateľa cloudových služieb.

Banka sa vracia s presnejšou otázkou:

„Ukážte nám, kto vlastní každú kontrolu vo vašom cloudovom prostredí. Vy, váš poskytovateľ cloudových služieb, váš poskytovateľ spravovanej databázy, váš poskytovateľ identít, váš dodávateľ logovania a všetci ďalší sprostredkovatelia. A potom ukážte dôkazy.“

Neskôr v ten deň má CISO zasadnutie predstavenstva. CEO položí rovnakú otázku jazykom organizácie: „Máme istotu, že táto platforma je bezpečná, a kto nesie zodpovednosť, ak sa niečo pokazí?“

Práve tu sa mnohé programy cloudového súladu zastavia.

Organizácia môže mať silného poskytovateľa cloudových služieb, dobré nástroje, primerané politiky a register rizík. Keď však má preukázať hranice zodpovednosti, dôkazy sú roztrúsené. Obstarávanie má zmluvy. Právne oddelenie má DPA. Technický tím má architektonické diagramy. Bezpečnostný tím má logy a cloudové konfigurácie. Tím ochrany súkromia má zoznam ďalších sprostredkovateľov. Tím compliance má Vyhlásenie o uplatniteľnosti. Nikto však nemá jeden riadený artefakt, ktorý po jednotlivých kontrolách uvádza, čo robí poskytovateľ, čo musí nakonfigurovať zákazník, ktorý ďalší sprostredkovateľ je zapojený, ktoré ustanovenie robí povinnosť vymáhateľnou a aké dôkazy má audítor očakávať.

Týmto artefaktom je matica zdieľanej zodpovednosti v cloude.

Nie všeobecná snímka od hyperscale poskytovateľa, podľa ktorej poskytovateľ zabezpečuje cloud a zákazník zabezpečuje to, čo je v cloude. Skutočná matica zdieľanej zodpovednosti v cloude pre ISO/IEC 27001:2022, NIS2, DORA a GDPR je záznam správy a riadenia. Obstojí pri zákazníckej due diligence, audite ISO, preskúmaní podľa DORA, preverení preukázateľnej zodpovednosti podľa GDPR aj pri vyšetrovaní incidentu.

Prečo sa zdieľaná zodpovednosť v cloude stáva auditným problémom

Model zdieľanej zodpovednosti sa zvyčajne vysvetľuje ako technická hranica. V IaaS poskytovateľ riadi fyzické priestory, hardvér, virtualizáciu a základnú infraštruktúru. Zákazník riadi identity, údaje, pracovné záťaže, pravidlá siete, voľbu šifrovania a konfigurácie. V SaaS poskytovateľ preberá väčšiu prevádzkovú zodpovednosť, ale zákazník naďalej vlastní prístup používateľov, správu a riadenie údajov, právny základ, konfiguráciu, očakávania monitorovania a eskaláciu incidentov.

Toto vysvetlenie je užitočné, ale neúplné.

Audítori, regulátori a podnikoví zákazníci sa nepýtajú iba „kto prevádzkuje kontrolu?“. Chcú vedieť:

• Kto je zodpovedný za riziko?
• Ktoré zmluvné ustanovenie robí túto zodpovednosť vymáhateľnou?
• Ktorá politika vyžaduje danú kontrolu?
• Ktorá cloudová služba, SaaS platforma alebo ďalší sprostredkovateľ je v rozsahu?
• Ktoré dôkazy preukazujú, že kontrola fungovala počas preskúmavaného obdobia?
• Ktorú požiadavku rámca dôkazy napĺňajú?
• Čo sa stane, ak poskytovateľ zmení svoju službu, lokalitu, subdodávateľa alebo stav kontrol?

ISO/IEC 27001:2022 z toho robí otázku systému manažérstva. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela interným a externým otázkam, zainteresovaným stranám, zákonným a zmluvným povinnostiam, rozsahu ISMS, rozhraniam a závislostiam. Kapitoly 6.1.1 až 6.1.3 vyžadujú posúdenie rizík, ošetrenie rizík, schválenie vlastníkom rizika, akceptáciu zostatkového rizika a Vyhlásenie o uplatniteľnosti. Kapitola 8.1 vyžaduje prevádzkové plánovanie a riadenie vrátane riadenia externe poskytovaných procesov, produktov a služieb relevantných pre ISMS.

Jednoducho povedané, ak poskytovateľ cloudových služieb, SaaS dodávateľ alebo ďalší sprostredkovateľ podporuje obchodný proces v rozsahu, nemôže stáť mimo ISMS. Musí byť viditeľný v rozsahu, rizikách, ošetrení rizík, zmluvnom riadení a dôkazoch.

NIS2 zvyšuje požiadavky. Article 21 vyžaduje, aby základné a dôležité subjekty zaviedli primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity, bezpečnosti dodávateľského reťazca, bezpečného nadobúdania, bezpečného vývoja, riešenia zraniteľností, posudzovania účinnosti, kybernetickej hygieny, kryptografie, bezpečnosti ľudských zdrojov, riadenia prístupu, správy aktív a viacfaktorovej autentifikácie alebo priebežnej autentifikácie, ak je to vhodné. Article 20 ukladá zodpovednosť za správu a riadenie riadiacim orgánom.

DORA je pre finančné subjekty ešte explicitnejšia. Uplatňuje sa od 17. januára 2025 a vyžaduje, aby finančné subjekty riadili riziká IKT, hlásenie závažných incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti a riziká tretích strán v oblasti IKT. Articles 28 až 30 vyžadujú riadenie rizík tretích strán v oblasti IKT, predbežné posúdenie rizika koncentrácie, zmluvné ochranné opatrenia, práva na audit a prístup, viditeľnosť subdodávok, práva na ukončenie a exit stratégie.

GDPR pridáva test preukázateľnej zodpovednosti. Article 5 vyžaduje, aby sa osobné údaje spracúvali spôsobom zabezpečujúcim integritu a dôvernosť, a Article 5(2) vyžaduje, aby prevádzkovateľ vedel preukázať súlad. Article 28 upravuje zmluvy so sprostredkovateľmi a ďalších sprostredkovateľov. Article 32 vyžaduje bezpečnosť spracúvania. Articles 33 a 34 vyžadujú oznamovanie porušenia ochrany osobných údajov, ak je to uplatniteľné.

Matica zdieľanej zodpovednosti v cloude sa stáva prepojením medzi týmito povinnosťami.

Definícia Clarysec: artefakt správy a riadenia, nie diagram

V projektoch Clarysec je matica zdieľanej zodpovednosti v cloude riadený záznam ISMS, ktorý prepája cloudové služby, dodávateľov, ďalších sprostredkovateľov, kontroly, politiky, zmluvné povinnosti, dôkazy a auditné očakávania.

Najsilnejšie vysvetlenie sa nachádza v Zenith Blueprint Zenith Blueprint, vo fáze Kontroly v praxi, krok 23:

„Poskytovatelia cloudových služieb zabezpečujú infraštruktúru, ale vy naďalej nesiete zodpovednosť za svoje údaje, svoje konfigurácie, svoje politiky prístupu a svoju pripravenosť na reakciu na incidenty.“

Ten istý krok vysvetľuje, že používanie cloudu sa musí považovať za súčasť ISMS vrátane klasifikácie cloudových služieb, pochopenia spracúvaných alebo ukladaných údajov, hodnotenia poskytovateľa, zmluvných ustanovení a riadenia zmien služieb. Tým sa zdieľaná zodpovednosť mení z konceptu na sledovateľnú štruktúru kontrol.

Zenith Controls Zenith Controls považuje kontroly ISO/IEC 27001:2022 Prílohy A a usmernenia ISO/IEC 27002:2022 5.20, 5.21 a 5.23 za centrálne kotvy:

• 5.20, riešenie informačnej bezpečnosti v dohodách s dodávateľmi.
• 5.21, riadenie informačnej bezpečnosti v dodávateľskom reťazci IKT.
• 5.23, informačná bezpečnosť pri používaní cloudových služieb.

Nie sú to izolované položky kontrolného zoznamu. Definujú chrbticu matice.

Podporné normy môžu maticu posilniť. ISO/IEC 27017 pomáha s bezpečnostnými praktikami špecifickými pre cloud. ISO/IEC 27018 a ISO/IEC 27701 podporujú správu a riadenie PII a ochrany súkromia. ISO/IEC 27005 podporuje posudzovanie rizík. ISO 22301 podporuje kontinuitu a odolnosť. ISO/IEC 27035 podporuje riadenie incidentov. ISO/IEC 20000-1 môže pomôcť tam, kde sú cloudové služby súčasťou poskytovania riadených služieb.

Minimálna použiteľná matica zdieľanej zodpovednosti

Zrelá matica nezačína 200 riadkami. Začína cloudovými službami, na ktorých záleží najviac.

Pre SaaS, fintech alebo regulovaný MSP Clarysec zvyčajne začína týmito položkami:

1. Produkčné cloudové prostredie určené pre zákazníkov.
2. Poskytovateľ identít.
3. Spravovaná databázová alebo úložisková služba.
4. Platforma logovania, monitorovania a SIEM.
5. Platobná, KYC, analytická alebo zákaznícka podporná SaaS služba.
6. Služba zálohovania a obnovy po havárii.
7. Poskytovateľ riadených služieb alebo poskytovateľ riadených bezpečnostných služieb.
8. Ďalší sprostredkovatelia, ktorí pristupujú k údajom zákazníkov, ukladajú ich alebo spracúvajú.

Prvá matica má obsahovať tieto stĺpce.

Praktický riadok logovania môže vyzerať takto.

Tento riadok nie je iba dokumentácia. Bezpečnostnému tímu hovorí, čo má nakonfigurovať, obstarávaniu, aký zmluvný jazyk má skontrolovať, tímu ochrany súkromia, aký tok údajov má zaznamenať, a audítorom, aké dôkazy majú vyžiadať.

Základ v politikách: ako z matice urobiť vymáhateľnú požiadavku

Matica zdieľanej zodpovednosti v cloude bez opory v politike je iba tabuľkový prehľad. Politiky Clarysec z nej robia vymáhateľnú požiadavku.

Pre MSP vyžaduje Politika používania cloudových služieb - MSP Politika používania cloudových služieb - MSP, časť „Požiadavky na správu a riadenie“, bod 5.3:

„Register cloudových služieb musí udržiavať poskytovateľ IT služieb alebo generálny manažér. Musí zaznamenávať:“

Tá istá politika pre MSP, bod 5.2.3, prepája správu cloudu s rizikom ochrany súkromia a lokality:

„Lokalizácia údajov a postupy ochrany súkromia sú v súlade s uplatniteľnými zákonnými požiadavkami (napr. GDPR)“

Pre podnikové prostredia Politika používania cloudových služieb Politika používania cloudových služieb, časť „Požiadavky na správu a riadenie“, bod 5.1 uvádza:

„Organizácia musí udržiavať centralizovaný register cloudových služieb vlastnený CISO, ktorý obsahuje:“

Bod 5.4 následne robí cloudové zodpovednosti zmluvne vymáhateľnými:

„Všetky zmluvy s poskytovateľmi cloudových služieb (CSP) musia obsahovať vymáhateľné ustanovenia pre:“

Správa a riadenie dodávateľov rozširuje maticu za hranicu bezprostredného poskytovateľa. Politika bezpečnosti tretích strán a dodávateľov - MSP Politika bezpečnosti tretích strán a dodávateľov - MSP, časť „Požiadavky na správu a riadenie“, bod 5.3.5 vyžaduje:

„Obmedzenia ďalšieho subdodávania bez schválenia“

Tá istá dodávateľská politika pre MSP, časť „Požiadavky na implementáciu politiky“, bod 6.3.1 pridáva pravidelné preskúmanie:

„Kritickí alebo vysokorizikoví dodávatelia musia byť preskúmaní najmenej raz ročne. Preskúmanie musí overiť:“

Na podnikovej úrovni Politika bezpečnosti tretích strán a dodávateľov Politika bezpečnosti tretích strán a dodávateľov, časť „Požiadavky na správu a riadenie“, bod 5.3 uvádza:

„Zmluvy s dodávateľmi musia obsahovať:“

Pre osobné údaje Politika ochrany údajov a súkromia Politika ochrany údajov a súkromia, časť „Uplatňovanie politiky a súlad“, bod 8.5.1 vyžaduje:

„Zmluvy so sprostredkovateľmi musia obsahovať:“

Pre viditeľnosť závislostí Politika riadenia rizík závislosti od dodávateľov Politika riadenia rizík závislosti od dodávateľov, bod 6.5.4 vyžaduje:

„Využitie dodávateľského vzťahu na získavanie aktualizácií o subdodávateľoch alebo závislostiach dodávateľského reťazca o jednu úroveň nižšie, ak by nás mohli ovplyvniť (napríklad ak sa kritický dodávateľ softvéru výrazne spolieha na knižnicu tretej strany, musí sa to zaznamenať).“

Pre logy poskytuje Politika logovania a monitorovania - MSP Politika logovania a monitorovania - MSP, časť „Požiadavky na správu a riadenie“, bod 5.5.1.3 konkrétnu zmluvnú požiadavku:

„Zmluvy musia vyžadovať, aby poskytovatelia uchovávali logy najmenej 12 mesiacov a poskytli prístup na požiadanie“

Spoločne tieto politiky robia z matice požadovaný záznam správy a riadenia, ktorý podporuje schvaľovanie dodávateľov, zavádzanie cloudových služieb, preukázateľnú zodpovednosť v oblasti ochrany súkromia, ročné preskúmanie a auditné dôkazy.

Mapovanie matice naprieč ISO/IEC 27001:2022, NIS2, DORA a GDPR

Klasickou chybou je vytvorenie štyroch samostatných zošitov súladu. Jedna kontrola môže splniť viacero povinností, ak sú zodpovednosť a dôkazy sledovateľné.

ISO/IEC 27001:2022 poskytuje motor ISMS: kontext, zainteresované strany, rozsah, vedenie, ošetrenie rizík, ciele, prevádzkové riadenie, hodnotenie výkonnosti a zlepšovanie. Príloha A poskytuje praktickú štruktúru kontrol.

NIS2 Article 21 sa prirodzene mapuje na rovnakú maticu prostredníctvom bezpečnosti dodávateľského reťazca, riešenia incidentov, kontinuity, riadenia prístupu, správy aktív a bezpečného nadobúdania. Article 20 robí maticu relevantnou pre predstavenstvo, pretože riadiace orgány musia schvaľovať opatrenia riadenia kybernetických rizík a vykonávať nad nimi dohľad.

DORA mení maticu na nástroj riadenia rizík tretích strán v oblasti IKT. Articles 5, 6 a 8 vyžadujú správu a riadenie, zdokumentované riadenie rizík IKT a identifikáciu aktív, funkcií a závislostí. Articles 17 až 19 vyžadujú detekciu incidentov, klasifikáciu, eskaláciu, komunikáciu a hlásenie. Articles 28 až 30 vyžadujú riadenie rizík tretích strán, analýzu rizika koncentrácie, zmluvné ustanovenia, kontroly subdodávania, práva na audit, práva na ukončenie a exit stratégie.

GDPR pridáva pohľad osobných údajov. Každý riadok cloudovej služby má identifikovať, či sa spracúvajú osobné údaje, či je poskytovateľ sprostredkovateľom alebo ďalším sprostredkovateľom, či je dôležitá lokalita údajov a aké zmluvné alebo DPA dôkazy existujú.

NIST CSF 2.0 pomáha komunikovať rovnakú maticu jazykom výsledkov. Funkcia GOVERN rieši kontext organizácie, právne a regulačné požiadavky, závislosti, riadenie rizík, roly, politiky a dohľad. Výsledky GV.SC sú osobitne užitočné pre kybernetické riziko dodávateľov vrátane rolí dodávateľov, kritickosti, zmluvných požiadaviek, due diligence, monitorovania, koordinácie incidentov a plánovania ukončenia.

COBIT 2019 pridáva pohľad uistenia a správy a riadenia. Pýta sa, či sú zodpovednosť za konanie, riadiace praktiky, vlastníctvo, monitorovanie a náprava problémov opakovateľné a podložené dôkazmi.

Budovanie matice od registra po dôkaz

Predstavte si SaaS spoločnosť, ktorá používa hyperscale IaaS platformu, spravovanú databázu, poskytovateľa identít tretej strany, SaaS platformu zákazníckej podpory a externý SIEM. Implementačný postup je priamočiary.

Krok 1: Začnite registrom cloudových služieb

Použite Politiku používania cloudových služieb alebo Politiku používania cloudových služieb - MSP ako spúšťač. Zaznamenajte každú cloudovú službu, vlastníka, účel, kategórie údajov, lokalitu, obchodnú funkciu, úroveň dodávateľa, vlastníka zmluvy a dátum preskúmania.

Ak služba ukladá záznamy zákazníkov, autentifikačné logy alebo tickety podpory, označte ju ako relevantnú z hľadiska ochrany súkromia. Ak podporuje dostupnosť produkčného prostredia, označte ju ako prevádzkovo kritickú. Ak podporuje kritickú alebo dôležitú funkciu finančného zákazníka, označte ju ako relevantnú z hľadiska DORA.

Krok 2: Pridajte domény zdieľanej zodpovednosti

Pre každú službu definujte zodpovednosti v kľúčových doménach.

Krok 3: Prepojte kontroly s rizikom a Vyhlásením o uplatniteľnosti

Zenith Blueprint, fáza Riadenie rizík, krok 13, vysvetľuje požiadavku sledovateľnosti:

„Krížovo odkazujte predpisy: Ak sú určité kontroly implementované osobitne na dosiahnutie súladu s GDPR, NIS2 alebo DORA, môžete to uviesť buď v registri rizík (ako súčasť odôvodnenia dopadu rizika), alebo v poznámkach SoA.“

Napríklad riziko „neoprávnený prístup k produkčným údajom zákazníkov cez chybnú konfiguráciu cloudu“ sa môže mapovať na riadenie prístupu, používanie cloudu, logovanie, kryptografiu, riadenie zraniteľností a dohody s dodávateľmi. SoA môže odkazovať na ISO/IEC 27001:2022 Prílohu A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 a 8.24, s poznámkami pre GDPR Article 32, NIS2 Article 21 a riadenie rizík IKT podľa DORA, ak je to uplatniteľné.

Krok 4: Pripojte dôkazy pred auditnou sezónou

Dôkazy majú byť navrhnuté priamo v matici, nie zbierané v panike.

Zoznam dôkazov mení zodpovednosť na dôkaz. Pomáha aj obchodným tímom rýchlejšie odpovedať na podnikovú due diligence, pretože môžu ukázať nielen certifikácie, ale aj vlastníctvo kontrol a prevádzkové dôkazy.

Ďalší sprostredkovatelia: slepé miesto väčšiny matíc

Ďalší sprostredkovatelia sú miestom, kde sa zdieľaná zodpovednosť mení na skutočné riziko dodávateľského reťazca.

SaaS poskytovateľ môže byť vaším sprostredkovateľom podľa GDPR. Tento poskytovateľ sa môže spoliehať na poskytovateľa cloudového hostingu, CDN, analytickú službu, platformu podpory, službu doručovania e-mailov, spravovanú databázu, poskytovateľa observability a spracovateľa platieb. Niektorí môžu pristupovať k osobným údajom. Niektorí môžu podporovať poskytovanie kritickej služby bez priameho nahliadania do údajov. Niektorí môžu byť mimo EÚ. Niektorí môžu byť nahraditeľní. Iní môžu vytvárať riziko koncentrácie.

DORA Article 29 vyžaduje posúdenie rizika koncentrácie pre kritické alebo dôležité služby IKT vrátane nahraditeľnosti, viacerých dohôd s tým istým alebo prepojenými poskytovateľmi, subdodávateľských reťazcov, subdodávateľov z tretích krajín, insolvenčného práva, obmedzení obnovy údajov a vymáhateľnosti ochrany údajov v Únii. DORA Article 30 vyžaduje zmluvné ustanovenia týkajúce sa podmienok subdodávania, lokalít, spracúvania a ukladania údajov, prístupu a obnovy, pomoci pri incidentoch, spolupráce s orgánmi, práv na audit, ukončenia a exitu.

NIS2 Article 21 podobne vyžaduje bezpečnosť dodávateľského reťazca pre priamych dodávateľov a poskytovateľov služieb, ako aj zohľadnenie špecifických zraniteľností dodávateľov, praktík kybernetickej bezpečnosti dodávateľov a postupov bezpečného vývoja.

Preto Clarysec považuje mapovanie ďalších sprostredkovateľov za povinné rozšírenie správy a riadenia dodávateľov, nie iba za zoznam pre ochranu súkromia. Register ďalších sprostredkovateľov má ukazovať, ktorý dodávateľ používa ďalšieho sprostredkovateľa, ktorá služba od neho závisí, či sa spracúvajú osobné údaje, či podporuje kritickú funkciu, región spracúvania, ak je relevantný, prenesené zmluvné povinnosti, práva na schválenie alebo námietku, dostupné uistenie, spôsob monitorovania a možnosť exitu.

Zenith Blueprint, fáza Kontroly v praxi, krok 23 uvádza:

„Pri každom kritickom dodávateľovi identifikujte, či používa subdodávateľov (ďalších sprostredkovateľov), ktorí môžu pristupovať k vašim údajom alebo systémom. Zdokumentujte, ako sa vaše požiadavky informačnej bezpečnosti prenášajú na tieto strany, buď prostredníctvom zmluvných podmienok vášho dodávateľa, alebo vašich vlastných priamych ustanovení.“

Toto je úroveň dôkazov, ktorú audítori očakávajú, keď sa pýtajú, či sú cloudové zodpovednosti riadené aj ďalej v reťazci.

Ako audítori testujú tú istú maticu

Silná matica zdieľanej zodpovednosti v cloude obstojí pri viacerých štýloch auditu, pretože je postavená na vlastníctve, vymáhateľnosti a dôkazoch.

Matica nie je cieľom sama osebe. Je mapou, podľa ktorej audítori testujú, či je systém správy a riadenia skutočný.

ISO audítor môže vybrať riziko cloudového prístupu s vysokým dopadom a sledovať ho od registra rizík po SoA, potom k revíziám prístupových práv, dôkazom MFA a monitorovacím upozorneniam. Posudzovateľ DORA môže vybrať kritického poskytovateľa IKT a vyžiadať si exit test, analýzu subdodávania a zmluvné práva na audit. Posudzovateľ GDPR sa môže zamerať na výmaz, lokalizáciu údajov, oznamovanie porušení ochrany údajov a transparentnosť ďalších sprostredkovateľov.

Bežné vzorce zlyhania

Najčastejšie zlyhania zdieľanej zodpovednosti nie sú exotické.

Po prvé, organizácie sa spoliehajú na správy o uistení poskytovateľa bez ich mapovania na zodpovednosti zákazníka. Poskytovateľ cloudových služieb môže preukázať fyzickú bezpečnosť, odolnosť infraštruktúry a kontroly platformy, ale nie to, či bol váš úložný bucket súkromný, či roly IAM dodržiavali zásadu minimálnych oprávnení alebo či boli logy povolené.

Po druhé, zmluvy obsahujú generický bezpečnostný jazyk, ale nie lehoty pre incidenty, práva na prístup k logom, práva na audit, obmedzenia subdodávania, ustanovenia o vrátení údajov alebo podporu pri ukončení. Zenith Blueprint, fáza Kontroly v praxi, krok 23 zvýrazňuje typické oblasti dodávateľských dohôd, ako sú dôvernosť, riadenie prístupu, technické a organizačné opatrenia, lehoty pre incidenty, právo na audit, kontroly subdodávateľov a ustanovenia pri ukončení zmluvy.

Po tretie, ďalší sprostredkovatelia sú uvedení na účely ochrany súkromia, ale nie sú prepojení s bezpečnosťou, kontinuitou alebo rizikom koncentrácie. Nadväzujúci poskytovateľ observability alebo podpory sa nemusí nikdy objaviť v registri rizík, hoci jeho výpadok alebo porušenie ochrany údajov môže ovplyvniť poskytovanie služieb zákazníkom.

Po štvrté, SoA uvádza, že kontrola je uplatniteľná, ale nikto nevie predložiť prevádzkové dôkazy. Cloudové logovanie môže byť označené ako implementované, ale organizácia nevie preukázať nastavenia uchovávania, revízie prístupových práv, riešenie upozornení alebo záväzky poskytovateľa k prístupu k logom.

Po piate, plány reakcie na incidenty nezohľadňujú závislosť od poskytovateľa. Ak poskytovateľ oznámi incident platformy, kto posudzuje dopad na zákazníka? Kto určuje, či je potrebné oznámenie podľa NIS2, DORA alebo GDPR? Kto kontaktuje dotknutých zákazníkov? Čo ak je koreňová príčina u ďalšieho sprostredkovateľa?

Zodpovednosť manažmentu: prečo by to malo zaujímať predstavenstvo

NIS2 Article 20 vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie. DORA Article 5 vyžaduje, aby riadiaci orgán definoval, schvaľoval, dohliadal a niesol zodpovednosť za nastavenie riadenia rizík IKT vrátane politík tretích strán v oblasti IKT, plánov kontinuity a obnovy, plánov auditov, školení a reportovacích kanálov.

Tým sa mení účel matice. Už nejde iba o bezpečnostný pracovný hárok. Stáva sa dôkazom, že manažment vie:

• Ktoré cloudové služby podporujú kritické činnosti.
• Ktoré tretie strany a ďalší sprostredkovatelia sú významní.
• Ktoré povinnosti sa uplatňujú podľa zákazníckych zmlúv, GDPR, NIS2 a DORA.
• Ktoré zodpovednosti zostávajú organizácii.
• Ktoré záväzky poskytovateľov sú zmluvne vymáhateľné.
• Ktoré medzery vyžadujú financovanie, nápravné opatrenia alebo akceptáciu rizika.

Pre MSP je dôležitá proporcionalita. Menší subjekt nepotrebuje ťažkopádnu byrokraciu, ale stále potrebuje dokumentáciu, monitorovanie, odolné systémy, detekciu zdrojov rizík IKT, identifikáciu kľúčových závislostí od tretích strán, opatrenia kontinuity, testovanie, získané poznatky a pravidelné preskúmanie tam, kde je v rozsahu.

Matica je jedným z najefektívnejších proporcionálnych nástrojov, pretože konsoliduje povinnosti namiesto ich násobenia.

30-dňový sprint na prípravu cloudového modelu na audit

Ak neviete odpovedať, kto vlastní každú cloudovú kontrolu, aké dôkazy ju preukazujú a ktorý ďalší sprostredkovateľ ju môže ovplyvniť, váš model zdieľanej zodpovednosti je stále diagram, nie artefakt správy a riadenia.

Praktický 30-dňový sprint vyzerá takto:

1. Vytvorte alebo aktualizujte register cloudových služieb pomocou Politiky používania cloudových služieb alebo Politiky používania cloudových služieb - MSP.
2. Identifikujte kritické služby, spracúvanie osobných údajov, systémy určené pre zákazníkov a relevantnosť z hľadiska DORA alebo NIS2.
3. Vytvorte prvú maticu okolo kontrol ISO/IEC 27001:2022 Prílohy A 5.20, 5.21 a 5.23 pomocou Zenith Controls.
4. Prepojte každý riadok s registrom rizík a Vyhlásením o uplatniteľnosti pomocou kroku 13 v Zenith Blueprint.
5. Overte ustanovenia dodávateľov a sprostredkovateľov pomocou Politiky bezpečnosti tretích strán a dodávateľov, Politiky bezpečnosti tretích strán a dodávateľov - MSP a Politiky ochrany údajov a súkromia.
6. Pridajte dôkazy o uchovávaní logov, eskalácii incidentov, schvaľovaní ďalších sprostredkovateľov, právach na audit a exite.
7. Preskúmavajte kritických dodávateľov každoročne a po významných zmenách, incidentoch, nových ďalších sprostredkovateľoch alebo auditných zisteniach.

Cieľ je jednoduchý. Keď sa zákazník, audítor, regulátor alebo predstavenstvo spýta „kto vlastní túto kontrolu?“, nehľadáte v zmluvách, ticketoch a priečinkoch. Otvoríte maticu, ukážete vlastníka, ukážete ustanovenie, ukážete dôkazy a ukážete nadväzujúcu stopu.

Clarysec vám môže pomôcť premeniť balíky uistenia poskytovateľov cloudových služieb na integrovanú maticu zdieľanej zodpovednosti pre audity ISO/IEC 27001:2022, pripravenosť na NIS2, riziká tretích strán v oblasti IKT podľa DORA, preukázateľnú zodpovednosť podľa GDPR a due diligence podnikových zákazníkov.

Začnite registrom. Vybudujte maticu. Pripojte dôkazy. Potom ju používajte ako dôkaz pre predstavenstvo, že cloudové riziko nie je outsourcované, ale riadené.