Obdobia bezpečnostnej podpory podľa CRA EÚ s ISO 27001

Je utorok 08:20 a vlastník produktu pre pripojenú B2B bránu dostane správu od regulovaného zákazníka: „Potvrďte, prosím, obdobie bezpečnostnej podpory pre verziu firmvéru 4.6, SLA pre reakciu na zraniteľnosti a to, či zariadenie zostane oprávnené dostávať bezpečnostné aktualizácie počas našej päťročnej servisnej zmluvy.“

O 09:00 oddelenie obstarávania preposiela dotazník hĺbkového preverenia podľa DORA. O 10:15 sa právne oddelenie pýta, či je zverejnené obdobie podpory v súlade so zákazníckymi zmluvami. O 11:00 sa CISO zapája do preskúmania rizika dodávateľského reťazca podľa NIS2, pretože produkt používa poskytovateľ spravovaných služieb v EÚ. Po obede sa tím ochrany súkromia pýta, či nepodporovaná knižnica API v produkte môže ovplyvniť bezpečnosť osobných údajov podľa GDPR.

Nepríjemná skutočnosť sa ukáže rýchlo. Spoločnosť má produktový plán, proces záplatovania, kalendár vydaní aj portál zákazníckej podpory, ale nemá riadené dôkazy k obdobiu bezpečnostnej podpory.

Na tejto medzere záleží. Podľa aktu EÚ o kybernetickej odolnosti nie je obdobie bezpečnostnej podpory iba produktovým označením. Je to záväzok počas životného cyklu, ktorý ovplyvňuje riešenie zraniteľností, dostupnosť aktualizácií, riadenie závislostí od dodávateľov, komunikáciu so zákazníkmi, zmluvné vyhlásenia a monitorovanie po uvedení na trh. Pre dodávateľov SaaS, výrobcov zariadení, vydavateľov softvéru, cloudových dodávateľov a poskytovateľov IKT služieb sa obdobie podpory stáva predmetom súladu, ktorý budú testovať audítori aj regulovaní kupujúci.

Praktickou odpoveďou nie je ďalšia izolovaná tabuľka súladu. Riešením je riadiť obdobie bezpečnostnej podpory v rámci systému manažérstva informačnej bezpečnosti podľa ISO/IEC 27001:2022 a následne mapovať tie isté dôkazy na NIS2, DORA, GDPR, NIST CSF 2.0 a auditné očakávania v štýle COBIT.

Toto je prevádzkový model Clarysec: používať ISMS ako dôkazový mechanizmus, používať vynútiteľné politiky na definovanie zodpovedností, používať Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint na budovanie sledovateľnosti a používať Zenith Controls: The Cross-Compliance Guide Zenith Controls ako kompas pre súlad naprieč rámcami.

Prečo je obdobie bezpečnostnej podpory dnes predmetom auditu

Obdobie bezpečnostnej podpory odpovedá na jednoduchú otázku: ako dlho bude výrobca poskytovať bezpečnostné aktualizácie, nápravu zraniteľností, usmernenia na zmiernenie rizík a súvisiacu zákaznícku podporu pre produkt alebo verziu produktu?

V praxi táto odpoveď závisí od viacerých pohyblivých častí:

• Architektúra produktu a jeho udržiavateľnosť
• Podpora komponentov tretích strán a open-source závislostí
• Záväzky dodávateľov a cloudových služieb
• Príjem hlásení o zraniteľnostiach, triáž, náprava a procesy zverejňovania
• Kapacita na vydávanie a testovanie
• Zákaznícke zmluvné podmienky a regulačné povinnosti
• Postupy reakcie na incidenty a oznamovania príjemcom služieb
• Uchovávanie dôkazov a záznamy o schválení

Ak výrobca prisľúbi päť rokov bezpečnostnej podpory, ale kritická kryptografická knižnica stratí podporu po troch rokoch, obdobie podpory sa stáva rozhodnutím o riziku. Ak je zákazník finančným subjektom podliehajúcim DORA, to isté obdobie podpory sa stáva súčasťou uistenia o IKT tretích stranách. Ak produkt spracúva osobné údaje, nepodporovaný softvér sa môže stať súčasťou preukázateľnej zodpovednosti za bezpečnosť spracúvania podľa GDPR. Ak produkt podporuje základný alebo dôležitý subjekt podľa NIS2, bezpečnosť životného cyklu sa stáva otázkou bezpečnosti dodávateľského reťazca.

NIS2 túto rovinu správy a riadenia výslovne zdôrazňuje. Article 20 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného nadobúdania, bezpečného vývoja a údržby, riešenia a zverejňovania zraniteľností, posudzovania účinnosti, kybernetickej hygieny, kryptografie, riadenia prístupu, správy aktív a autentifikácie. Article 23 dopĺňa odstupňované oznamovacie povinnosti pri významných incidentoch.

DORA vytvára podobný tlak pre finančné subjekty. Vyžaduje riadenie IKT rizík, testovanie digitálnej prevádzkovej odolnosti, riadenie incidentov a správu a riadenie rizika IKT tretích strán. DORA Article 28 pokrýva zásady riadenia rizika IKT tretích strán a Article 30 vyžaduje písomné zmluvné dojednania s jasnými opismi služieb, bezpečnostnými opatreniami, súčinnosťou pri incidentoch, právami na audit, právami na ukončenie a dojednaniami o exite.

GDPR pridáva vrstvu ochrany súkromia. Ak produkt spracúva osobné údaje, prevádzkovatelia a sprostredkovatelia potrebujú primerané technické a organizačné opatrenia podľa Article 32, zmluvnú jasnosť podľa Article 28 a pripravenosť na posúdenie porušenia ochrany osobných údajov a jeho oznámenie podľa Articles 33 a 34.

Preto sa obdobie bezpečnostnej podpory podľa CRA musí riadiť ako súbor kontrol ISMS, nie ako izolované pole v produktovom riadení.

ISO 27001 ako kontrolná chrbtica období bezpečnostnej podpory podľa CRA

ISO/IEC 27001:2022 je cenná preto, že je škálovateľná, založená na riziku a orientovaná na systém manažérstva. Vyžaduje, aby organizácia definovala kontext, zainteresované strany, rozsah a vzájomne pôsobiace procesy a následne premietla právne, regulačné a zmluvné požiadavky do posudzovania rizík, ošetrenia rizík, prevádzkových kontrol a dôkazov ISO/IEC 27001:2022.

Pre správu a riadenie obdobia bezpečnostnej podpory to znamená, že organizácia musí:

1. Identifikovať produkty, verzie, moduly, cloudové služby a závislosti v rozsahu.
2. Identifikovať zainteresované strany vrátane zákazníkov, regulátorov, distribútorov, dovozcov, integrátorov, sprostredkovateľov, ďalších sprostredkovateľov, partnerov pre reakciu na incidenty a dodávateľov.
3. Zaznamenať právne, regulačné a zmluvné povinnosti týkajúce sa podpory.
4. Posúdiť riziká, ktoré by mohli brániť splneniu záväzkov podpory.
5. Vybrať kontroly pre riadenie zraniteľností, bezpečný vývoj, uistenie dodávateľov, riadenie incidentov, kontinuitu činností, ochranu súkromia a zdokumentované informácie.
6. Vytvoriť poznámky k vyhláseniu o uplatniteľnosti, ktoré vysvetľujú, prečo sa kontroly uplatňujú.
7. Preskúmať obdobie podpory pri zmene architektúry, závislostí od dodávateľov, vystavenia hrozbám alebo zákazníckych záväzkov.

Zenith Controls identifikuje tri tematicky súvisiace kontroly ISO/IEC 27002:2022 ako ústredné oporné body tohto problému správy a riadenia: 5.31 Právne, zákonné, regulačné a zmluvné požiadavky, 8.8 Riadenie technických zraniteľností a 8.25 Bezpečný životný cyklus vývoja. Nie sú to jediné relevantné kontroly, ale tvoria chrbticu správy a riadenia.

Kľúčom je sledovateľnosť. Obdobie podpory produktu má byť sledovateľné od povinnosti k rizikovému scenáru, od rizikového scenára k vybraným kontrolám, od kontrol k požiadavkám politík a od požiadaviek politík k dôkazom.

Zenith Blueprint, fáza riadenia rizík, krok 13, opisuje túto disciplínu sledovateľnosti priamo:

„Krížovo odkazujte predpisy: Ak sa určité kontroly implementujú 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 k SoA.“

Zdroj: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fáza riadenia rizík, krok 13: Plánovanie ošetrenia rizík a vyhlásenie o uplatniteľnosti Zenith Blueprint

Pri období bezpečnostnej podpory podľa CRA nemá vyhlásenie o uplatniteľnosti iba konštatovať, že „riadenie zraniteľností sa uplatňuje“. Má vysvetliť, že riadenie zraniteľností sa uplatňuje preto, lebo spoločnosť má záväzky životného cyklu podľa CRA, očakávania NIS2 v oblasti bezpečného vývoja a dodávateľského reťazca, požiadavky zákazníkov podľa DORA v rámci hĺbkového preverenia, bezpečnostné povinnosti podľa GDPR tam, kde sa spracúvajú osobné údaje, a zmluvné záväzky podpory.

Od prísľubu podpory k riadenému životnému cyklu

Výrobcom definované obdobie bezpečnostnej podpory musí prejsť šiestimi testami správy a riadenia.

Po prvé, musí byť definované. Organizácia potrebuje štandardnú taxonómiu, napríklad aktívna podpora, iba bezpečnostná podpora, rozšírená podpora, obmedzená podpora a nepodporovaný stav. Každý stav musí vysvetľovať dostupnosť aktualizácií, riešenie zraniteľností, komunikáciu so zákazníkmi a eskalačné postupy.

Po druhé, musí byť posúdené z hľadiska rizika. Päť rokov podpory pre cloudovo spravovaný SaaS produkt s riadenými aktualizačnými kanálmi je iné ako päť rokov podpory pre vstavané zariadenie s prevádzkovými obmedzeniami v teréne, závislosťami od čipov tretích strán a oknami nasadenia, ktoré riadi zákazník.

Po tretie, musí byť schválené. Produktový tím, bezpečnostný tím, právne oddelenie, ochrana súkromia, zákaznícka podpora a zodpovedné vedenie musia schváliť základné obdobie aj výnimky.

Po štvrté, musí byť komunikované. Zákazníci musia rozumieť dátumu začiatku podpory, dátumu ukončenia, spôsobu aktualizácie, kanálu na hlásenie zraniteľností, očakávaniam nápravy, dôsledkom ukončenia podpory a dostupným možnostiam predĺženia.

Po piate, musí byť monitorované. Závislosti sa menia. Dodávatelia ukončujú podporu knižníc. Objavujú sa zraniteľnosti. Zákaznícke prostredia sa menia. Správa a riadenie obdobia podpory musí zahŕňať monitorovanie životného cyklu komponentov, preskúmanie dodávateľov, zdroje informácií o zraniteľnostiach, záznamy o záplatách, testovanie vydaní a poučenia z incidentov.

Po šieste, musí byť preukázané dôkazmi. Ak audítor, regulátor alebo regulovaný zákazník požiada o dôkaz, organizácia musí predložiť register súladu, register podpory produktov, posúdenie rizík, mapovanie SoA, register zraniteľností, záznamy o záplatách, preskúmania dodávateľov, schválenia vydaní a oznámenia zákazníkom.

Politiky Clarysec to robia prakticky použiteľným. Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy vyžaduje:

„Všetky právne a regulačné povinnosti musia byť mapované na konkrétne politiky, kontroly a vlastníkov v rámci systému manažérstva informačnej bezpečnosti (ISMS).“

Zdroj: Legal and Regulatory Compliance Policy, Požiadavky na implementáciu politiky, bod 6.2.1 Legal and Regulatory Compliance Policy

Pre MSP sa rovnaká disciplína začína jednoduchším registrom. SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME uvádza:

„Generálny riaditeľ (GM) musí viesť jednoduchý, štruktúrovaný register súladu, v ktorom sú uvedené:“

Zdroj: Legal and Regulatory Compliance Policy-sme, Požiadavky na správu a riadenie, bod 5.1.1 Legal and Regulatory Compliance Policy - SME

Záväzok obdobia podpory má byť v registri súladu, ak vyplýva zo zákona, zákazníckej zmluvy, sektorovej regulácie alebo očakávania regulovaného kupujúceho. Nemá existovať iba v poznámkach k vydaniu alebo v marketingovom texte.

Vytvorte register období bezpečnostnej podpory podľa CRA počas jedného workshopu

Predstavme si dodávateľa SaaS, ktorý predáva pripojené analytické zariadenie poskytovateľom logistiky v EÚ a klientom vo finančnom sektore. Produkt obsahuje vstavaného agenta, cloudové API, mobilnú administračnú aplikáciu a viacero open-source knižníc. Obchodný tím chce prisľúbiť päť rokov bezpečnostnej podpory pre každú hlavnú verziu zariadenia.

CISO môže zorganizovať zameraný workshop s produktovým tímom, vývojom, právnym oddelením, ochranou súkromia a riadením dodávateľov.

Krok 1: Vytvorte register období podpory

Vytvorte jeden riadok pre každú verziu produktu a zahrňte:

• Produkt a verzia
• Dátum vydania
• Dátum začiatku podpory
• Štandardný dátum ukončenia bezpečnostnej podpory
• Možnosť rozšírenej podpory
• Spôsob doručovania aktualizácií
• Kanál na zverejňovanie zraniteľností
• Cieľ pre kritickú záplatu
• Rola pri spracúvaní údajov, napríklad prevádzkovateľ, sprostredkovateľ alebo oboje
• Kritickí dodávatelia a komponenty
• Dotknuté zákaznícke sektory
• Vlastník rizika
• Dátum schválenia
• Umiestnenie dôkazov

Tento register sa stáva zdokumentovanou informáciou v rámci ISMS. Zenith Blueprint, fáza základov ISMS a vedenia, krok 6, stanovuje očakávanie riadenia dokumentov:

„Dokumenty majú mať riadnu identifikáciu (názov, prípadne číslo dokumentu alebo jedinečný identifikátor, autora), vhodný formát a preskúmanie a schválenie primeranosti pred použitím.“

Zdroj: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fáza základov ISMS a vedenia, krok 6: Zdokumentované informácie a budovanie knižnice ISMS Zenith Blueprint

Enterprise politika Clarysec PIMS Documented Information Evidence Management Policy PIMS Documented Information Evidence Management Policy uplatňuje podobné zásady dôkazov na dokumentáciu ochrany súkromia:

„[All] Privacy Lead / PIMS Manager MUSÍ pred zverejnením zdokumentovaných informácií PIMS prideliť v REG12 identifikátor dokumentu, vlastníka, číslo verzie, stav schválenia, dátum účinnosti a dátum preskúmania.“

Zdroj: PIMS Documented Information Evidence Management Policy, Vytvorenie, schválenie, verziovanie a zverejnenie, bod 4.2.1 PIMS Documented Information Evidence Management Policy

Aj keď register období podpory štandardne nie je dokumentom ochrany súkromia, uplatňuje sa rovnaká disciplína: vlastník, verzia, schválenie, dátum účinnosti a dátum preskúmania.

Krok 2: Prepojte prísľuby podpory s ošetrením rizík

Pre každú verziu produktu vytvorte rizikové scenáre, napríklad:

• V podporovanej verzii sa zistí kritická zraniteľnosť, ale vývojový tím nemá dostupnú kapacitu.
• Komponent tretej strany prestane byť podporovaný pred koncom deklarovaného obdobia bezpečnostnej podpory.
• Dodávateľ zmení miesto hostovania alebo subdodávateľa a ovplyvní doručovanie aktualizácií.
• Zraniteľnosť ovplyvní osobné údaje a spustí posúdenie porušenia ochrany osobných údajov.
• Regulovaný finančný zákazník vyžaduje dôkazy o odolnosti IKT tretích strán.

ISO/IEC 27001:2022 body 6.1.1 až 6.1.3 poskytujú plánovací mechanizmus: identifikovať riziká, posúdiť pravdepodobnosť a dôsledky, priradiť vlastníkov rizík, vybrať ošetrenia, porovnať vybrané kontroly s prílohou A, vypracovať vyhlásenie o uplatniteľnosti a získať schválenie zvyškového rizika.

Pre riziko „nepodporovaný komponent pred dátumom ukončenia podpory“ má záznam rizika obsahovať kontroly ISO/IEC 27002:2022 5.31, 8.8 a 8.25, ako aj dodávateľské kontroly, napríklad 5.19 Informačná bezpečnosť vo vzťahoch s dodávateľmi, 5.20 Riešenie informačnej bezpečnosti v zmluvách s dodávateľmi, 5.21 Riadenie informačnej bezpečnosti v IKT dodávateľskom reťazci a 5.22 Monitorovanie, preskúmanie a riadenie zmien dodávateľských služieb.

Krok 3: Nastavte pravidlá dôkazov pre zraniteľnosti a záplaty

Obdobie podpory je dôveryhodné iba vtedy, ak počas neho funguje riadenie zraniteľností.

SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME stanovuje prísnu požiadavku pre urgentné vystavenie riziku:

„Kritické záplaty musia byť aplikované do 3 dní od vydania, najmä pri systémoch dostupných z internetu.“

Zdroj: Vulnerability and Patch Management Policy-sme, Požiadavky na implementáciu politiky, bod 6.1.1 Vulnerability and Patch Management Policy - SME

Vyžaduje aj záznamy pripravené na audit:

„Musí sa viesť záznam o záplatách a preskúmavať počas auditov a činností reakcie na incidenty.“

Zdroj: Vulnerability and Patch Management Policy-sme, Požiadavky na správu a riadenie, bod 5.4.1 Vulnerability and Patch Management Policy - SME

Pre podnikové prostredia Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy vyžaduje:

„Tím bezpečnostných operácií musí viesť centralizovaný register riadenia zraniteľností, ktorý mesačne preskúmava CISO alebo delegovaná autorita.“

Zdroj: Vulnerability and Patch Management Policy, Požiadavky na správu a riadenie, bod 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, fáza Controls in Action, krok 19, vysvetľuje prevádzkové očakávanie za kontrolou ISO/IEC 27002:2022 8.8:

„Sledujte nové bezpečnostné chyby (prostredníctvom upozornení dodávateľov, zdrojov CVE atď.) pre svoj softvér a hardvér. Posúďte, ktoré sú relevantné (používame tento softvér? aká kritická je chyba?) a bezodkladne aplikujte opravy alebo zmierňujúce opatrenia.“

Zdroj: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fáza Controls in Action, krok 19: Technologické kontrolné opatrenia I Zenith Blueprint

Každá podporovaná verzia produktu potrebuje dôkazovú stopu zraniteľnosti: príjem hlásenia, analýzu relevantnosti, závažnosť, dotknuté verzie, plán nápravy, vydanie opravy, usmernenie na zmiernenie rizík, komunikáciu so zákazníkom a schválenie uzavretia.

Krok 4: Prepojte bezpečný vývoj s trvaním podpory

Bezpečnostná podpora sa začína pred vydaním. Závisí od vývojových postupov, ktoré umožňujú udržiavať produkt.

SME Secure Development Policy-sme Secure Development Policy - SME uvádza:

„Komponenty musia byť pravidelne aktualizované pri vydaní bezpečnostných záplat. Ak sa identifikuje kritická zraniteľnosť, komponent musí byť okamžite aktualizovaný alebo nahradený.“

Zdroj: Secure Development Policy-sme, Požiadavky na implementáciu politiky, bod 6.6.3 Secure Development Policy - SME

SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME vyžaduje, aby zmluvy a požiadavky:

„špecifikovali povinnosti týkajúce sa zverejňovania zraniteľností, reakčných lehôt a záplatovania.“

Zdroj: Application Security Requirements Policy-sme, Požiadavky na správu a riadenie, bod 5.3.2 Application Security Requirements Policy - SME

Ak spoločnosť sľubuje podporu do roku 2031, architektúra musí podporovať udržiavateľné aktualizácie, nahrádzanie závislostí, bezpečné build pipeline, regresné testovanie a núdzové vydania. Kontroly ISO/IEC 27002:2022 pre bezpečný vývoj, bezpečnú architektúru, bezpečné programovanie, bezpečnostné testovanie, outsourcovaný vývoj, oddelenie prostredí a riadenie zmien sa stávajú predpokladmi obdobia podpory.

Jedna sada dôkazov pre CRA, NIS2, DORA a GDPR

Tie isté dôkazy k obdobiu podpory môžu podporiť rôzne regulačné diskusie, ale každý rámec kladie otázku inak.

Závislosť od dodávateľov je často miestom, kde záväzky podpory zlyhávajú. Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy vyžaduje:

„Register závislostí od dodávateľov: VMO vedie aktuálny register všetkých kritických dodávateľov vrátane údajov, ako sú poskytované služby/produkty; či je dodávateľ jediným zdrojom; dostupní alternatívni dodávatelia alebo nahraditeľnosť; aktuálne zmluvné podmienky; a posúdenie dopadu, ak by dodávateľ zlyhal alebo bol kompromitovaný.“

Zdroj: Supplier Dependency Risk Management Policy, Implementačné požiadavky, bod 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, fáza Controls in Action, krok 23, upozorňuje, že audítori budú kontrolovať zmluvy s dodávateľmi a dôkazy o monitorovaní dodávateľov:

„Audítori preskúmajú vzorky zmlúv alebo servisných dohôd. Hľadajú výslovné doložky informačnej bezpečnosti, napríklad lehoty na oznámenie porušenia ochrany údajov, obmedzenia prístupu, povinnosti spracúvania údajov, požiadavky na šifrovanie alebo práva na audit.“

Zdroj: Zenith Blueprint: An Auditor’s 30-Step Roadmap, fáza Controls in Action, krok 23: Organizačné opatrenia Zenith Blueprint

Pre zákazníkov podliehajúcich DORA je to kritické. Zmluvy na IKT služby podporujúce zásadné alebo dôležité funkcie potrebujú jasné opisy služieb, podmienky subdodávok, bezpečnostné opatrenia, súčinnosť pri incidentoch, práva na audit a kontrolu, práva na ukončenie a dojednania o prechode. Dodávateľ, ktorý tieto záväzky nedokáže podporiť, môže výrobcovi znemožniť dôveryhodný prísľub obdobia podpory.

Mapovanie kontrol pre správu a riadenie obdobia podpory pripravenú na audit

Toto mapovanie umožňuje tímom bezpečnosti, právneho oddelenia, produktu a predaja hovoriť jedným jazykom. Register období podpory nie je iba dôkazom CRA. Je uistením dodávateľov pre NIS2, uistením tretích strán pre DORA, podporou bezpečnosti spracúvania pre GDPR a artefaktom správy a riadenia pre certifikáciu ISO 27001.

Pohľad ochrany súkromia: keď sa nepodporované stáva nebezpečným

Správa a riadenie obdobia bezpečnostnej podpory nie je iba otázkou kybernetickej bezpečnosti. Ak produkt ukladá, prenáša alebo spracúva osobné údaje, nepodporovaný softvér sa môže stať rizikom ochrany súkromia.

GDPR sa uplatňuje na spracúvanie v kontexte prevádzkarne v EÚ a môže sa vzťahovať aj na organizácie mimo EÚ, ktoré ponúkajú tovar alebo služby jednotlivcom v EÚ alebo monitorujú ich správanie. Osobné údaje definuje široko a porušenie ochrany osobných údajov chápe ako porušenie bezpečnosti vedúce k náhodnému alebo nezákonnému zničeniu, strate, zmene, neoprávnenému poskytnutiu alebo prístupu k spracúvaným osobným údajom.

Pri správe a riadení období podpory musia tímy ochrany súkromia vedieť, ktoré verzie produktov spracúvajú PII, ktoré systémy sú ešte podporované a či zraniteľnosti ovplyvňujú dôvernosť, integritu alebo dostupnosť osobných údajov.

Enterprise PII Security Access Control Policy Clarysec PII Security Access Control Policy vyžaduje:

„[Both] Vlastník systému / vlastník aplikácie MUSÍ zaznamenať pokrytie posúdení zraniteľností pre systémy spracúvajúce PII v REG12 najmenej štvrťročne a po podstatnej technickej zmene.“

Zdroj: PII Security Access Control Policy, Bezpečná konfigurácia a riadenie zraniteľností, bod 4.7.4 PII Security Access Control Policy

Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy dopĺňa priebežné monitorovanie vysokorizikových vzťahov v oblasti ochrany súkromia:

„[All] Vlastník dodávateľa / obstarávania MUSÍ štvrťročne monitorovať aktívne vysokorizikové vzťahy so sprostredkovateľmi a ďalšími sprostredkovateľmi a ročne ostatné aktívne vzťahy so sprostredkovateľmi a ďalšími sprostredkovateľmi PII voči podmienkam due diligence, stavu zmluvy, stavu uistenia, otvoreným otázkam a dátumom preskúmania v REG08.“

Zdroj: Processor Subprocessor Third Party Privacy Management Policy, Priebežné monitorovanie, súčinnosť, rozhranie poskytovania údajov a exit, bod 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Keď sa zraniteľnosť stane incidentom, Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy vyžaduje posúdenie spúšťačov podľa viacerých rámcov:

„[Conditional] Privacy Lead / PIMS Manager MUSÍ vyhodnotiť uplatniteľné právne, sektorové, finančno-sektorové, kybernetickobezpečnostné, zmluvné, zákaznícke a voči príjemcom služieb relevantné spúšťače hlásenia pre každý incident s vysokým dopadom týkajúci sa PII a zaznamenať výsledok uplatniteľnosti v REG01, REG08 a REG10.“

Zdroj: PII Incident Breach Management Policy, Klasifikácia a posúdenie porušenia ochrany údajov, bod 4.2.6 PII Incident Breach Management Policy

Toto je praktický prienik medzi záväzkami podpory podľa CRA, komunikáciou incidentov podľa NIS2, riešením závažných incidentov súvisiacich s IKT podľa DORA a preukázateľnou zodpovednosťou pri porušení ochrany údajov podľa GDPR.

Ako audítori testujú rovnaký proces obdobia podpory

Silný proces správy a riadenia období podpory musí obstáť pri viacerých auditných štýloch. Dôkazy sa veľmi nemenia, mení sa však pohľad audítora.

NIST CSF 2.0 je užitočný ako komunikačná vrstva, pretože jeho funkcia GOVERN zahŕňa právne, regulačné, zmluvné a súkromnoprávne povinnosti, ciele riadenia rizík, apetít na riziko, roly, politiky a dohľad. Jeho výsledky pre dodávateľský reťazec pokrývajú stratégiu dodávateľov, kritickosť, zmluvy, hĺbkové preverenie, monitorovanie, koordináciu incidentov a ustanovenia pre ukončenie vzťahu.

Audítori v štýle COBIT a ISACA sa často zameriavajú na návrh správy a riadenia: kto rozhodnutie vlastní, aký proces je definovaný, aké metriky preukazujú výkonnosť, ako sa schvaľujú výnimky a ako sa rieši neustále zlepšovanie.

Enterprise Information Security Policy Clarysec Information Security Policy zachytáva zásadu auditovateľnosti:

„Všetky implementované kontroly musia byť overiteľné auditom, podporené zdokumentovanými postupmi a uchovávanými dôkazmi o prevádzke.“

Zdroj: Information Security Policy, Požiadavky na implementáciu politiky, bod 6.6.1 Information Security Policy

Toto je veta, ktorú musí vedieť splniť každé obdobie bezpečnostnej podpory.

Predĺžte, skráťte alebo ukončite podporu bez vytvárania falošného uistenia

Najťažšie momenty správy a riadenia nenastávajú pri uvedení produktu. Nastávajú vtedy, keď sa zmení realita.

Podporu možno budete musieť predĺžiť, pretože regulovaní zákazníci od produktu závisia, migrácia nie je uskutočniteľná alebo sektorový zákazník má zmluvné potreby kontinuity. Podporu možno budete musieť skrátiť alebo obmedziť, pretože dodávateľ ukončí bezpečnostnú údržbu, komponent sa stane prakticky neopraviteľným, platforma dosiahne technické limity alebo architektúra produktu nedokáže bezpečne podporiť určitú triedu zraniteľností.

Riadená zmena obdobia podpory musí zahŕňať:

• Spúšťač zmeny, napríklad koniec životnosti u dodávateľa, kritická zraniteľnosť, zákaznícka zmluva alebo regulačná zmena
• Dotknuté produkty, verzie, zákazníkov a sektory
• Analýzu dopadu na osobné údaje a kritické služby
• Preskúmanie uskutočniteľnosti na úrovni dodávateľov a komponentov
• Posúdenie rizík a rozhodnutie o zvyškovom riziku
• Aktualizovaný register období podpory
• Aktualizované oznámenie zákazníkom a zmluvnú pozíciu
• Aktualizované poznámky SoA, ak sa menia kontroly alebo povinnosti
• Schválenie manažmentom a dátum preskúmania

Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy je užitočná, keď je zmena vyvolaná zraniteľnosťou:

„Pre všetky potvrdené zraniteľnosti sa vypracuje plán nápravy alebo zmiernenia. Implementácia opravy sa prioritizuje podľa závažnosti. Napríklad kritické zraniteľnosti sa opravia alebo zmiernia do 14 dní, ak je to uskutočniteľné, alebo skôr, ak sa zistí aktívne zneužívanie, zatiaľ čo problémy s nižšou závažnosťou sa riešia v primeranej lehote.“

Zdroj: Coordinated Vulnerability Disclosure Policy, Implementačné požiadavky, bod 6.6 Coordinated Vulnerability Disclosure Policy

Ak úplnú opravu nemožno dodať okamžite, dočasne môžu byť prijateľné kompenzačné kontroly, deaktivovaná funkcionalita, zvýšené monitorovanie alebo zákaznícke konfiguračné usmernenie, rozhodnutie však musí byť zdokumentované a komunikované.

Praktický kontrolný zoznam Clarysec pre pripravenosť obdobia podpory

Použite tento kontrolný zoznam pred zverejnením alebo obnovením akéhokoľvek záväzku obdobia bezpečnostnej podpory podľa CRA.

• Je produkt a verzia uvedená v registri období podpory?
• Je dátum ukončenia podpory schválený produktovým tímom, bezpečnostným tímom a zodpovedným manažmentom?
• Sú právne, regulačné a zmluvné dôvody mapované v registri súladu?
• Je rizikový scenár obdobia podpory zahrnutý v registri rizík?
• Sú kontroly mapované vo vyhlásení o uplatniteľnosti vrátane 5.31, 8.8 a 8.25 tam, kde sú uplatniteľné?
• Sú kritickí dodávatelia a komponenty mapovaní v registri závislostí od dodávateľov?
• Existujú dôkazy, že komponenty možno počas obdobia podpory záplatovať alebo nahradiť?
• Sú definované zodpovednosti za príjem hlásení o zraniteľnostiach, triáž, nápravu a zverejňovanie?
• Sú SLA pre kritické záplaty zosúladené s politikou a zákazníckymi zmluvami?
• Uchovávajú sa záznamy o záplatách, záznamy o vydaniach a rozhodnutia o zraniteľnostiach?
• Sú systémy s osobnými údajmi pokryté dôkazmi o posúdení zraniteľností tam, kde sa spracúvajú PII?
• Sú oznámenia zákazníkom, vyhlásenia o podpore a zmluvné podmienky konzistentné?
• Existuje proces na predĺženie, skrátenie alebo ukončenie podpory so schválením rizika?
• Dostáva preskúmanie manažmentom vstupy o rizikách obdobia podpory, dodávateľoch, zraniteľnostiach a incidentoch?
• Dajú sa dôkazy predložiť do 48 hodín pre zákaznícky audit alebo regulačné preverenie?

Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy posilňuje disciplínu preskúmania manažmentom pre programy ochrany súkromia:

„[Both] Vrcholový manažment MUSÍ počas každého preskúmania manažmentom preskúmať v REG12 vstupy týkajúce sa nezhôd PIMS, nápravných opatrení, výsledkov monitorovania, výsledkov auditu, rizík ochrany súkromia, uistenia dodávateľov a zmien zainteresovaných strán.“

Zdroj: PIMS Monitoring Audit Improvement Policy, Preskúmanie PIMS manažmentom, bod 4.3.5 PIMS Monitoring Audit Improvement Policy

Pri správe a riadení období bezpečnostnej podpory má rovnaký rytmus preskúmania platiť naprieč ISMS: zraniteľnosti, výkonnosť záplatovania, uistenie dodávateľov, záväzky voči zákazníkom, incidenty, výnimky z podpory a nápravné opatrenia majú vstupovať do preskúmania manažmentom.

Urobte obdobie bezpečnostnej podpory obhájiteľným

Akt EÚ o kybernetickej odolnosti mení spôsob uvažovania o bezpečnosti produktov. Tlačí výrobcov a poskytovateľov softvéru k tomu, aby premýšľali nad rámec dňa vydania. Obdobie bezpečnostnej podpory sa stáva prísľubom životného cyklu, ktorý musí byť navrhnutý, riadený, monitorovaný a doložený dôkazmi.

Pre CISO je ponaučenie jasné: nenechajte obdobie podpory iba v produktovom marketingu. Pre manažérov súladu: nevytvárajte samostatné dôkazové silo pre CRA. Pre audítorov: testujte, či sú záväzky podpory sledovateľné k rizikám, kontrolám, dodávateľom, incidentom a zdokumentovaným schváleniam. Pre vlastníkov organizácie: pamätajte, že dôveryhodné obdobie podpory sa môže stať trhovou výhodou, najmä pri predaji sektorom regulovaným NIS2, finančným subjektom podliehajúcim DORA a zákazníkom citlivým na ochranu súkromia.

Clarysec pomáha organizáciám zaviesť tento prístup do praxe prostredníctvom:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint na budovanie sledovateľnosti ISMS, zdokumentovaných informácií, mapovania SoA a pripravenosti na audit
• Zenith Controls: The Cross-Compliance Guide Zenith Controls na mapovanie kontrol ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 a auditné očakávania
• Balíkov politík pre podniky a MSP pre riadenie zraniteľností, bezpečný vývoj, právny súlad, závislosti od dodávateľov, dôkazy ochrany súkromia a reakciu na incidenty
• Praktických registrov a dôkazových pracovných tokov, ktoré premieňajú prísľuby období podpory na auditovateľnú správu a riadenie

Váš ďalší krok je jednoduchý: vyberte jednu kľúčovú verziu produktu a vytvorte jej dôkazový spis k obdobiu bezpečnostnej podpory. Namapujte povinnosť, schváľte obdobie podpory, otestujte proces zraniteľností, validujte závislosti od dodávateľov, potvrďte komunikáciu so zákazníkmi a uchovajte záznamy.

Ak viete obhájiť jeden produkt, viete model škálovať. Ak neviete obhájiť jeden produkt, medzerou nie je dokumentácia. Medzerou je správa a riadenie.

Stiahnite si Zenith Blueprint, použite Zenith Controls na mapovanie svojich dôkazov alebo požiadajte o posúdenie pripravenosti Clarysec, aby ste obdobia bezpečnostnej podpory podľa CRA premenili na správu a riadenie podľa ISO 27001 pripravenú na audit.