Řízení období bezpečnostní podpory podle EU CRA pomocí ISO 27001

Je úterý 08:20 a vlastník produktu připojené B2B brány dostává zprávu od regulovaného zákazníka: „Potvrďte prosím období bezpečnostní podpory pro firmware verze 4.6, SLA pro reakci na zranitelnosti a zda zařízení zůstane způsobilé pro bezpečnostní aktualizace po celou dobu naší pětileté smlouvy o poskytování služeb.“

V 09:00 předává oddělení nákupu dotazník náležité péče podle DORA. V 10:15 se právní oddělení ptá, zda deklarované období podpory odpovídá zákaznickým smlouvám. V 11:00 je CISO přizván k přezkumu dodavatelského rizika podle NIS2, protože produkt používá poskytovatel řízených služeb v EU. Po obědě se tým ochrany soukromí ptá, zda nepodporovaná knihovna API v produktu může mít dopad na zabezpečení osobních údajů podle GDPR.

Nepříjemná skutečnost se ukáže rychle. Společnost má produktovou roadmapu, proces záplatování, kalendář vydání a portál zákaznické podpory, ale nemá řízené důkazy k období bezpečnostní podpory.

Tato mezera je významná. Podle aktu EU o kybernetické odolnosti není období bezpečnostní podpory jen produktovým označením. Jde o závazek v rámci životního cyklu, který ovlivňuje řešení zranitelností, dostupnost aktualizací, řízení dodavatelských závislostí, komunikaci se zákazníky, smluvní prohlášení a monitorování po uvedení na trh. Pro dodavatele SaaS, výrobce zařízení, vydavatele softwaru, poskytovatele cloudových služeb a poskytovatele služeb ICT se období podpory stává předmětem compliance, který budou prověřovat auditoři i regulovaní odběratelé.

Praktickou odpovědí není další izolovaná tabulka pro compliance. Řešením je řídit období bezpečnostní podpory uvnitř systému řízení bezpečnosti informací podle ISO/IEC 27001:2022 a stejné důkazy následně mapovat na NIS2, DORA, GDPR, NIST CSF 2.0 a auditní očekávání ve stylu COBIT.

To je provozní model Clarysec: používat ISMS jako základní mechanismus pro tvorbu a správu důkazů, vymahatelnými politikami vymezit odpovědnosti, pomocí Zenith Blueprint: 30krokové roadmapy auditora Zenith Blueprint vybudovat dohledatelnost a použít Zenith Controls: průvodce souladem napříč rámci Zenith Controls jako referenční mapu pro compliance napříč rámci.

Proč je období bezpečnostní podpory nově předmětem auditu

Období bezpečnostní podpory odpovídá na jednoduchou otázku: jak dlouho bude výrobce pro produkt nebo verzi produktu poskytovat bezpečnostní aktualizace, nápravu zranitelností, doporučení ke zmírnění rizik a související zákaznickou podporu?

V praxi tato odpověď závisí na řadě pohyblivých částí:

• architektuře produktu a jeho udržovatelnosti,
• podpoře komponent třetích stran a open-source závislostí,
• závazcích dodavatelů a cloudových služeb,
• procesech příjmu hlášení zranitelností, triáže, nápravy a oznamování,
• kapacitě release engineeringu a testování,
• smluvních podmínkách zákazníků a regulatorních povinnostech,
• postupech reakce na incidenty a oznamování příjemcům služeb,
• uchovávání důkazů a záznamech o schválení.

Pokud výrobce slíbí pět let bezpečnostní podpory, ale kritická kryptografická knihovna po třech letech přestane být podporována, období podpory se stává rozhodnutím o riziku. Pokud je zákazníkem finanční subjekt podléhající DORA, stejné období podpory se stává součástí ujištění o třetích stranách v oblasti ICT. Pokud produkt zpracovává osobní údaje, nepodporovaný software se může stát součástí odpovědnosti za zabezpečení zpracování podle GDPR. Pokud produkt podporuje základní nebo důležitý subjekt podle NIS2, bezpečnost životního cyklu se stává otázkou zabezpečení dodavatelského řetězce.

NIS2 tento pohled na správu a řízení výslovně potvrzuje. Article 20 vyžaduje, aby vedoucí orgány základních a důležitých subjektů schvalovaly opatření k řízení kybernetických rizik, dohlížely na jejich implementaci a absolvovaly školení. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování, bezpečného vývoje a údržby, řešení a oznamování zranitelností, posouzení účinnosti, kybernetické hygieny, kryptografie, řízení přístupu, správy aktiv a autentizace. Article 23 doplňuje odstupňované oznamovací povinnosti pro významné incidenty.

DORA vytváří podobný tlak na finanční subjekty. Vyžaduje řízení rizik v oblasti ICT, testování digitální provozní odolnosti, řízení incidentů a řízení rizik třetích stran v oblasti ICT. DORA Article 28 upravuje zásady řízení rizik třetích stran v oblasti ICT a Article 30 vyžaduje písemná smluvní ujednání s jasným popisem služeb, bezpečnostními opatřeními, podporou při incidentech, právy na audit, právy na ukončení a exitovými ujednáními.

GDPR přidává vrstvu ochrany soukromí. Pokud produkt zpracovává osobní údaje, správci a zpracovatelé potřebují vhodná technická a organizační opatření podle Article 32, smluvní jasnost podle Article 28 a připravenost na posouzení a oznámení porušení zabezpečení podle Articles 33 a 34.

Proto musí být období bezpečnostní podpory podle CRA řízeno jako skupina opatření v ISMS, nikoli jako izolované pole v produktovém řízení.

ISO 27001 jako páteř opatření pro období bezpečnostní podpory podle CRA

ISO/IEC 27001:2022 je cenná tím, že je škálovatelná, založená na rizicích a orientovaná na systém řízení. Vyžaduje, aby organizace definovala kontext, zainteresované strany, rozsah a vzájemně působící procesy a následně převedla právní, regulatorní a smluvní požadavky do posouzení rizik, ošetření rizik, provozních opatření a důkazů ISO/IEC 27001:2022.

Pro správu a řízení období bezpečnostní podpory to znamená, že organizace musí:

1. Identifikovat produkty, verze, moduly, cloudové služby a závislosti v rozsahu.
2. Identifikovat zainteresované strany včetně zákazníků, regulačních orgánů, distributorů, dovozců, integrátorů, zpracovatelů, dílčích zpracovatelů, partnerů pro reakci na incidenty a dodavatelů.
3. Zaznamenat právní, regulatorní a smluvní povinnosti týkající se podpory.
4. Posoudit rizika, která by mohla zabránit splnění závazků podpory.
5. Vybrat opatření pro řízení zranitelností, bezpečný vývoj, ujištění o dodavatelích, řízení incidentů, kontinuitu činností, ochranu soukromí a dokumentované informace.
6. Vytvořit poznámky k Prohlášení o použitelnosti, které vysvětlují, proč se opatření uplatňují.
7. Přezkoumat období podpory při změně architektury, dodavatelských závislostí, expozice hrozbám nebo závazků vůči zákazníkům.

Zenith Controls označuje tři tematicky související opatření ISO/IEC 27002:2022 za ústřední vazby pro tento problém správy a řízení: 5.31 právní, zákonné, regulatorní a smluvní požadavky, 8.8 řízení technických zranitelností a 8.25 bezpečný životní cyklus vývoje. Nejsou to jediná dotčená opatření, ale tvoří páteř správy a řízení.

Klíčová je dohledatelnost. Období podpory produktu má být dohledatelné od povinnosti k rizikovému scénáři, od rizikového scénáře k vybraným opatřením, od opatření k požadavkům politik a od požadavků politik k důkazům.

Zenith Blueprint, fáze řízení rizik, krok 13, tuto disciplínu dohledatelnosti popisuje přímo:

„Křížově odkazujte právní předpisy: Pokud jsou určitá opatření implementována konkrétně za účelem souladu s GDPR, NIS2 nebo DORA, můžete to uvést buď v Registru rizik (jako součást odůvodnění dopadu rizika), nebo v poznámkách k SoA.“

Zdroj: Zenith Blueprint: 30kroková roadmapa auditora, fáze řízení rizik, krok 13: Plánování ošetření rizik a Prohlášení o použitelnosti Zenith Blueprint

U období bezpečnostní podpory podle CRA nemá Prohlášení o použitelnosti pouze uvádět „řízení zranitelností se uplatňuje“. Má vysvětlit, že řízení zranitelností se uplatňuje proto, že společnost má závazky životního cyklu podle CRA, očekávání NIS2 v oblasti bezpečného vývoje a dodavatelského řetězce, požadavky zákazníků v rámci náležité péče podle DORA, bezpečnostní povinnosti podle GDPR tam, kde jsou zpracovávány osobní údaje, a smluvní přísliby podpory.

Od příslibu podpory k řízenému životnímu cyklu

Výrobcem definované období bezpečnostní podpory musí projít šesti testy správy a řízení.

Zaprvé musí být definováno. Organizace potřebuje standardní taxonomii, například aktivní podpora, pouze bezpečnostní podpora, rozšířená podpora, omezená podpora a nepodporovaný stav. Každý stav musí vysvětlovat dostupnost aktualizací, řešení zranitelností, komunikaci se zákazníky a eskalační cesty.

Zadruhé musí být posouzeno z hlediska rizik. Pět let podpory pro cloudově spravovaný SaaS produkt s řízenými aktualizačními kanály je něco jiného než pět let pro vestavěné zařízení s provozními omezeními, závislostmi na čipech třetích stran a zákazníkem spravovanými okny nasazení.

Zatřetí musí být schváleno. Produktový tým, bezpečnost, právní oddělení, ochrana soukromí, zákaznická podpora a odpovědné vedení musí schválit výchozí období i výjimky.

Začtvrté musí být komunikováno. Zákazníci musí rozumět datu zahájení podpory, datu ukončení, způsobu aktualizace, kanálu pro hlášení zranitelností, očekáváním nápravy, důsledkům ukončení podpory a dostupným možnostem prodloužení.

Zapáté musí být monitorováno. Závislosti se mění. Dodavatelé ukončují knihovny. Objevují se zranitelnosti. Mění se zákaznická prostředí. Správa a řízení období podpory musí zahrnovat monitorování životního cyklu komponent, přezkum dodavatelů, zdroje informací o zranitelnostech, logy záplat, testování vydání a poznatky z incidentů.

Zašesté musí být doloženo. Pokud auditor, regulační orgán nebo regulovaný zákazník požádá o důkazy, organizace musí předložit registr souladu, registr podpory produktů, posouzení rizik, mapování SoA, registr zranitelností, záznamy o záplatách, přezkumy dodavatelů, schválení vydání a oznámení zákazníkům.

Politiky Clarysec z toho činí praktický proces. Podniková Politika právního a regulatorního souladu Politika právního a regulatorního souladu vyžaduje:

„Všechny právní a regulační povinnosti musí být mapovány na konkrétní politiky, opatření a vlastníky v rámci systému řízení bezpečnosti informací (ISMS).“

Zdroj: Politika právního a regulatorního souladu, požadavky na implementaci politiky, článek 6.2.1 Politika právního a regulatorního souladu

U MSP začíná ekvivalentní disciplína jednodušším registrem. Politika právního a regulatorního souladu pro MSP Politika právního a regulatorního souladu – MSP uvádí:

„GM musí vést jednoduchý, strukturovaný Registr souladu, který obsahuje:“

Zdroj: Politika právního a regulatorního souladu pro MSP, požadavky na správu a řízení, článek 5.1.1 Politika právního a regulatorního souladu – MSP

Závazek k období podpory má být v registru souladu, pokud vyplývá z právního předpisu, zákaznické smlouvy, odvětvové regulace nebo očekávání regulovaného odběratele. Nemá existovat pouze v poznámkách k vydání nebo marketingových textech.

Vytvořte registr období bezpečnostní podpory podle CRA v jednom workshopu

Představte si dodavatele SaaS, který prodává připojené analytické zařízení logistickým poskytovatelům v EU a klientům z finančního sektoru. Produkt obsahuje vestavěného agenta, cloudové API, mobilní administrátorskou aplikaci a několik open-source knihoven. Obchod chce slíbit pět let bezpečnostní podpory pro každou hlavní verzi zařízení.

CISO může uspořádat cílený workshop s produktovým týmem, vývojem, právním oddělením, ochranou soukromí a řízením dodavatelů.

Krok 1: Vytvořte registr období podpory

Vytvořte jeden řádek pro každou verzi produktu a zahrňte:

• produkt a verzi,
• datum vydání,
• datum zahájení podpory,
• standardní datum ukončení bezpečnostní podpory,
• možnost rozšířené podpory,
• způsob doručení aktualizace,
• kanál pro oznamování zranitelností,
• cílovou lhůtu pro kritickou záplatu,
• roli při zpracování údajů, například správce, zpracovatel nebo obojí,
• kritické dodavatele a komponenty,
• dotčená odvětví zákazníků,
• vlastníka rizika,
• datum schválení,
• umístění důkazů.

Tento registr se stává dokumentovanou informací v rámci ISMS. Zenith Blueprint, fáze základů ISMS a vedení, krok 6, stanoví očekávání pro řízení dokumentů:

„Dokumenty mají mít řádnou identifikaci (název, případně číslo dokumentu nebo jedinečný identifikátor, autora), vhodný formát a přezkum a schválení přiměřenosti před použitím.“

Zdroj: Zenith Blueprint: 30kroková roadmapa auditora, fáze základů ISMS a vedení, krok 6: Dokumentované informace a budování knihovny ISMS Zenith Blueprint

Podniková Politika správy dokumentovaných informací a důkazů PIMS Politika správy dokumentovaných informací a důkazů PIMS uplatňuje podobné principy důkazů na dokumentaci ochrany soukromí:

„[Všichni] Privacy Lead / PIMS Manager MUSÍ před zveřejněním dokumentovaných informací PIMS přiřadit v REG12 identifikátor dokumentu, vlastníka, číslo verze, stav schválení, datum účinnosti a datum přezkumu.“

Zdroj: Politika správy dokumentovaných informací a důkazů PIMS, vytvoření, schválení, verzování a zveřejnění, článek 4.2.1 Politika správy dokumentovaných informací a důkazů PIMS

I když registr období podpory není ve výchozím stavu dokumentem ochrany soukromí, uplatňuje se stejná disciplína: vlastník, verze, schválení, datum účinnosti a datum přezkumu.

Krok 2: Propojte přísliby podpory s ošetřením rizik

Pro každou verzi produktu vytvořte rizikové scénáře, například:

• V podporované verzi je objevena kritická zranitelnost, ale vývojová kapacita není dostupná.
• Komponenta třetí strany přestane být podporována před koncem deklarovaného období bezpečnostní podpory.
• Dodavatel změní lokalitu hostingu nebo subdodavatele a ovlivní doručování aktualizací.
• Zranitelnost ovlivní osobní údaje a spustí posouzení porušení zabezpečení osobních údajů.
• Regulovaný finanční zákazník vyžaduje důkazy o odolnosti třetí strany v oblasti ICT.

Kapitoly ISO/IEC 27001:2022 6.1.1 až 6.1.3 poskytují plánovací rámec: identifikovat rizika, posoudit pravděpodobnost a dopady, přiřadit vlastníky rizik, vybrat způsoby ošetření, porovnat vybraná opatření s přílohou A, vytvořit Prohlášení o použitelnosti a získat schválení zbytkového rizika.

U rizika „nepodporovaná komponenta před datem ukončení podpory“ má záznam o riziku zahrnovat opatření ISO/IEC 27002:2022 5.31, 8.8 a 8.25 a dále dodavatelská opatření, například 5.19 bezpečnost informací ve vztazích s dodavateli, 5.20 řešení bezpečnosti informací ve smlouvách s dodavateli, 5.21 řízení bezpečnosti informací v dodavatelském řetězci ICT a 5.22 monitorování, přezkum a řízení změn dodavatelských služeb.

Krok 3: Nastavte pravidla důkazů pro zranitelnosti a záplaty

Období podpory je důvěryhodné pouze tehdy, pokud v jeho průběhu funguje řízení zranitelností.

Politika řízení zranitelností a záplat pro MSP Politika řízení zranitelností a záplat – MSP stanoví přísný požadavek pro naléhavou expozici:

„Kritické záplaty musí být aplikovány do 3 dnů od vydání, zejména u systémů dostupných z internetu.“

Zdroj: Politika řízení zranitelností a záplat pro MSP, požadavky na implementaci politiky, článek 6.1.1 Politika řízení zranitelností a záplat – MSP

Vyžaduje také záznamy připravené pro audit:

„Log záplat musí být veden a přezkoumáván během auditů a činností reakce na incidenty.“

Zdroj: Politika řízení zranitelností a záplat pro MSP, požadavky na správu a řízení, článek 5.4.1 Politika řízení zranitelností a záplat – MSP

Pro podniková prostředí vyžaduje podniková Politika řízení zranitelností a záplat Politika řízení zranitelností a záplat:

„Centralizovaný Registr řízení zranitelností musí být veden týmem bezpečnostního provozu a měsíčně přezkoumáván CISO nebo delegovanou autoritou.“

Zdroj: Politika řízení zranitelností a záplat, požadavky na správu a řízení, článek 5.1 Politika řízení zranitelností a záplat

Zenith Blueprint, fáze opatření v praxi, krok 19, vysvětluje provozní očekávání za opatřením ISO/IEC 27002:2022 8.8:

„Sledujte nové bezpečnostní chyby (prostřednictvím upozornění dodavatelů, CVE feedů apod.) pro svůj software a hardware. Posuďte, které jsou relevantní (používáme tento software? jak kritická je chyba?) a neprodleně aplikujte opravy nebo zmírňující opatření.“

Zdroj: Zenith Blueprint: 30kroková roadmapa auditora, fáze opatření v praxi, krok 19: Technologická opatření I Zenith Blueprint

Každá podporovaná verze produktu potřebuje důkazní stopu zranitelnosti: příjem hlášení, analýzu relevance, závažnost, dotčené verze, plán nápravy, vydání opravy, doporučení ke zmírnění, komunikaci se zákazníky a schválení uzavření.

Krok 4: Propojte bezpečný vývoj s délkou podpory

Bezpečnostní podpora začíná před vydáním. Závisí na vývojových postupech, které činí produkt udržovatelným.

Politika bezpečného vývoje pro MSP Politika bezpečného vývoje – MSP uvádí:

„Komponenty musí být pravidelně aktualizovány při vydání bezpečnostních záplat. Pokud je identifikována kritická zranitelnost, komponenta musí být okamžitě aktualizována nebo nahrazena.“

Zdroj: Politika bezpečného vývoje pro MSP, požadavky na implementaci politiky, článek 6.6.3 Politika bezpečného vývoje – MSP

Politika požadavků na zabezpečení aplikací pro MSP Politika požadavků na zabezpečení aplikací – MSP vyžaduje, aby smlouvy a požadavky:

„specifikovaly povinnosti týkající se oznamování zranitelností, reakčních dob a záplatování.“

Zdroj: Politika požadavků na zabezpečení aplikací pro MSP, požadavky na správu a řízení, článek 5.3.2 Politika požadavků na zabezpečení aplikací – MSP

Pokud společnost slíbí podporu do roku 2031, architektura musí umožňovat udržovatelné aktualizace, náhradu závislostí, zabezpečené build pipelines, regresní testování a nouzová vydání. Opatření ISO/IEC 27002:2022 pro bezpečný vývoj, bezpečnou architekturu, bezpečné kódování, bezpečnostní testování, outsourcovaný vývoj, oddělení prostředí a řízení změn se stávají předpoklady období podpory.

Jedna sada důkazů pro CRA, NIS2, DORA a GDPR

Stejné důkazy k období podpory mohou uspokojit různé regulatorní diskuse, ale každý rámec klade otázku jinak.

Dodavatelské závislosti jsou často místem, kde závazky podpory selžou. Podniková Politika řízení rizik dodavatelských závislostí Politika řízení rizik dodavatelských závislostí vyžaduje:

„Registr závislostí na dodavatelích: VMO musí vést aktuální registr všech kritických dodavatelů, včetně údajů jako poskytované služby/produkty; zda je dodavatel jediným zdrojem; dostupní alternativní dodavatelé nebo zastupitelnost; aktuální smluvní podmínky; a posouzení dopadu v případě, že by dodavatel selhal nebo byl kompromitován.“

Zdroj: Politika řízení rizik dodavatelských závislostí, požadavky na implementaci, článek 6.1 Politika řízení rizik dodavatelských závislostí

Zenith Blueprint, fáze opatření v praxi, krok 23, upozorňuje, že auditoři budou kontrolovat smlouvy s dodavateli a důkazy o monitorování dodavatelů:

„Auditoři budou přezkoumávat vzorky smluv nebo servisních dohod. Hledají výslovná ustanovení o bezpečnosti informací, například lhůty pro oznámení porušení zabezpečení, omezení přístupu, povinnosti zpracování údajů, požadavky na šifrování nebo práva na audit.“

Zdroj: Zenith Blueprint: 30kroková roadmapa auditora, fáze opatření v praxi, krok 23: Organizační opatření Zenith Blueprint

Pro zákazníky podléhající DORA je to kritické. Smlouvy o službách ICT podporujících kritické nebo důležité funkce potřebují jasné popisy služeb, podmínky subdodávek, bezpečnostní opatření, podporu při incidentech, práva na audit a kontrolu, práva na ukončení a přechodová ujednání. Dodavatel, který tyto závazky nedokáže podpořit, může výrobci znemožnit učinit důvěryhodný příslib období podpory.

Mapování opatření pro správu a řízení období podpory připravené pro audit

Toto mapování umožňuje týmům bezpečnosti, právnímu oddělení, produktovému týmu a obchodu mluvit jedním jazykem. Registr období podpory není pouze důkazem pro CRA. Je ujištěním o dodavateli pro NIS2, ujištěním o třetí straně pro DORA, podporou zabezpečení zpracování pro GDPR a artefaktem správy a řízení pro certifikaci ISO 27001.

Perspektiva ochrany soukromí: kdy se nepodporovaný stav stává nebezpečným

Správa a řízení období bezpečnostní podpory není pouze otázkou kybernetické bezpečnosti. Pokud produkt ukládá, přenáší nebo zpracovává osobní údaje, nepodporovaný software se může stát rizikem pro soukromí.

GDPR se vztahuje na zpracování v souvislosti s činnostmi provozovny v EU a může se vztahovat také na organizace mimo EU, které nabízejí zboží nebo služby fyzickým osobám v EU nebo monitorují jejich chování. Osobní údaje vymezuje široce a porušení zabezpečení osobních údajů chápe jako porušení zabezpečení vedoucí k náhodnému nebo protiprávnímu zničení, ztrátě, změně, neoprávněnému zpřístupnění nebo přístupu ke zpracovávaným osobním údajům.

Pro správu a řízení období podpory potřebují týmy ochrany soukromí vědět, které verze produktu zpracovávají PII, které systémy jsou stále podporovány a zda zranitelnosti ovlivňují důvěrnost, integritu nebo dostupnost osobních údajů.

Podniková Politika bezpečnosti PII a řízení přístupu Politika bezpečnosti PII a řízení přístupu vyžaduje:

„[Obě role] Vlastník systému / vlastník aplikace MUSÍ v REG12 zaznamenat pokrytí hodnocením zranitelností u systémů zpracovávajících PII alespoň čtvrtletně a po významné technické změně.“

Zdroj: Politika bezpečnosti PII a řízení přístupu, bezpečná konfigurace a řízení zranitelností, článek 4.7.4 Politika bezpečnosti PII a řízení přístupu

Podniková Politika řízení vztahů se zpracovateli, dílčími zpracovateli a třetími stranami v oblasti ochrany soukromí Politika řízení vztahů se zpracovateli, dílčími zpracovateli a třetími stranami v oblasti ochrany soukromí doplňuje průběžné monitorování u vysoce rizikových vztahů v oblasti ochrany soukromí:

„[Všichni] Vendor / Procurement Owner MUSÍ čtvrtletně monitorovat aktivní vysoce rizikové vztahy se zpracovateli a dílčími zpracovateli a každoročně ostatní aktivní vztahy se zpracovateli PII a dílčími zpracovateli PII vůči podmínkám due diligence, stavu smluv, stavu ujištění, otevřeným problémům a datům přezkumu v REG08.“

Zdroj: Politika řízení vztahů se zpracovateli, dílčími zpracovateli a třetími stranami v oblasti ochrany soukromí, průběžné monitorování, součinnost, rozhraní zpřístupnění a exit, článek 4.5.1 Politika řízení vztahů se zpracovateli, dílčími zpracovateli a třetími stranami v oblasti ochrany soukromí

Když se zranitelnost stane incidentem, podniková Politika řízení incidentů a porušení zabezpečení PII Politika řízení incidentů a porušení zabezpečení PII vyžaduje posouzení spouštěcích podmínek napříč rámci:

„[Podmíněně] Privacy Lead / PIMS Manager MUSÍ u každého incidentu s významným dopadem týkajícího se PII vyhodnotit použitelné právní, odvětvové, finančně-sektorové, kybernetickobezpečnostní, smluvní, zákaznické a službou vyvolané spouštěcí podmínky hlášení a zaznamenat výsledek použitelnosti v REG01, REG08 a REG10.“

Zdroj: Politika řízení incidentů a porušení zabezpečení PII, klasifikace a posouzení porušení zabezpečení, článek 4.2.6 Politika řízení incidentů a porušení zabezpečení PII

Toto je praktický průnik závazků podpory podle CRA, komunikace o incidentech podle NIS2, řešení závažných incidentů souvisejících s ICT podle DORA a odpovědnosti za porušení zabezpečení podle GDPR.

Jak auditoři testují stejný proces období podpory

Silný proces správy a řízení období podpory musí obstát v různých typech auditů. Důkazy se příliš nemění, mění se však pohled auditora.

NIST CSF 2.0 je užitečný jako komunikační vrstva, protože jeho funkce GOVERN zahrnuje právní, regulatorní, smluvní povinnosti a povinnosti v oblasti ochrany soukromí, cíle řízení rizik, ochotu podstupovat riziko, role, politiky a dohled. Výsledky pro dodavatelský řetězec pokrývají strategii dodavatelů, kritičnost, smlouvy, due diligence, monitorování, koordinaci incidentů a ustanovení pro ukončení vztahu.

Auditoři ve stylu COBIT a ISACA se často zaměřují na návrh správy a řízení: kdo vlastní rozhodnutí, jaký proces je definován, jaké metriky dokládají výkonnost, jak jsou schvalovány výjimky a jak je řešeno neustálé zlepšování.

Podniková Politika bezpečnosti informací Politika bezpečnosti informací zachycuje princip auditovatelnosti:

„Všechna implementovaná opatření musí být auditovatelná, podporovaná dokumentovanými postupy a uchovávanými důkazy o fungování.“

Zdroj: Politika bezpečnosti informací, požadavky na implementaci politiky, článek 6.6.1 Politika bezpečnosti informací

To je věta, kterou musí splnit každé období bezpečnostní podpory.

Prodloužit, zkrátit nebo ukončit podporu bez vytváření falešného ujištění

Nejtěžší okamžiky správy a řízení nenastávají při uvedení produktu na trh. Nastávají, když se změní realita.

Může být nutné podporu prodloužit, protože regulovaní zákazníci jsou na produktu závislí, migrace není proveditelná nebo odvětvový zákazník má smluvní potřeby kontinuity. Může být nutné podporu zkrátit nebo omezit, protože dodavatel ukončí bezpečnostní údržbu, komponentu již nelze opravit, platforma dosáhne technických limitů nebo architektura produktu nedokáže bezpečně podporovat určitou třídu zranitelností.

Řízená změna období podpory musí zahrnovat:

• spouštěcí událost změny, například ukončení životního cyklu dodavatele, kritickou zranitelnost, zákaznickou smlouvu nebo regulatorní změnu,
• dotčené produkty, verze, zákazníky a odvětví,
• analýzu dopadu na osobní údaje a kritické služby,
• přezkum proveditelnosti u dodavatelů a komponent,
• posouzení rizik a rozhodnutí o zbytkovém riziku,
• aktualizovaný registr období podpory,
• aktualizované oznámení zákazníkům a smluvní stanovisko,
• aktualizované poznámky k SoA tam, kde se mění opatření nebo povinnosti,
• schválení vedením a datum přezkumu.

Podniková Politika koordinovaného oznamování zranitelností Politika koordinovaného oznamování zranitelností je užitečná, pokud je změna vyvolána zranitelností:

„Pro všechny potvrzené zranitelnosti musí být vypracován plán nápravy nebo zmírnění. Implementace opravy musí být prioritizována podle závažnosti. Například kritické zranitelnosti musí být opraveny nebo zmírněny do 14 dnů, pokud je to proveditelné, nebo dříve, pokud je zjištěno aktivní zneužívání, zatímco méně závažné problémy musí být řešeny v přiměřené lhůtě.“

Zdroj: Politika koordinovaného oznamování zranitelností, požadavky na implementaci, článek 6.6 Politika koordinovaného oznamování zranitelností

Pokud nelze plnou opravu dodat okamžitě, mohou být dočasně přijatelná kompenzační opatření, vypnutá funkcionalita, zvýšené monitorování nebo doporučení zákazníkům ke konfiguraci, ale rozhodnutí musí být zdokumentováno a komunikováno.

Praktický kontrolní seznam Clarysec pro připravenost období podpory

Použijte tento kontrolní seznam před zveřejněním nebo obnovením jakéhokoli závazku k období bezpečnostní podpory podle CRA.

• Je produkt a verze uvedena v registru období podpory?
• Je datum ukončení podpory schváleno produktovým týmem, bezpečností a odpovědným vedením?
• Jsou právní, regulatorní a smluvní spouštěče mapovány v registru souladu?
• Je rizikový scénář období podpory zahrnut v registru rizik?
• Jsou opatření namapována v Prohlášení o použitelnosti, včetně 5.31, 8.8 a 8.25, kde jsou použitelná?
• Jsou kritičtí dodavatelé a komponenty namapováni v registru dodavatelských závislostí?
• Existují důkazy, že komponenty lze během období podpory záplatovat nebo nahradit?
• Jsou definovány odpovědnosti za příjem hlášení zranitelností, triáž, nápravu a oznamování?
• Jsou SLA pro kritické záplaty sladěna s politikou a zákaznickými smlouvami?
• Jsou uchovávány logy záplat, záznamy o vydání a rozhodnutí ke zranitelnostem?
• Jsou systémy s osobními údaji pokryty důkazy o hodnocení zranitelností tam, kde je zpracováváno PII?
• Jsou oznámení zákazníkům, prohlášení o podpoře a smluvní podmínky konzistentní?
• Existuje proces pro prodloužení, zkrácení nebo ukončení podpory se schválením rizika?
• Dostává přezkoumání vedením vstupy k rizikům období podpory, dodavatelům, zranitelnostem a incidentům?
• Lze do 48 hodin předložit důkazy pro zákaznický audit nebo dotaz regulačního orgánu?

Podniková Politika monitorování, auditu a zlepšování PIMS Politika monitorování, auditu a zlepšování PIMS posiluje disciplínu přezkoumání vedením u programů ochrany soukromí:

„[Obě role] Vrcholové vedení MUSÍ při každém přezkoumání vedením přezkoumat v REG12 vstupy týkající se neshod PIMS, nápravných opatření, výsledků monitorování, výsledků auditů, rizik pro soukromí, ujištění o dodavatelích a změn zainteresovaných stran.“

Zdroj: Politika monitorování, auditu a zlepšování PIMS, přezkoumání PIMS vedením, článek 4.3.5 Politika monitorování, auditu a zlepšování PIMS

U správy a řízení období bezpečnostní podpory musí stejný rytmus přezkoumání platit napříč ISMS: zranitelnosti, výkonnost záplatování, ujištění o dodavatelích, závazky vůči zákazníkům, incidenty, výjimky z podpory a nápravná opatření musí vstupovat do přezkoumání vedením.

Zajistěte obhajitelnost období bezpečnostní podpory

Akt EU o kybernetické odolnosti mění uvažování o bezpečnosti produktů. Nutí výrobce a poskytovatele softwaru myslet za den vydání. Období bezpečnostní podpory se stává příslibem životního cyklu, který musí být technicky navržen, řízen, monitorován a doložen.

Pro CISO je poučení jasné: nenechávejte období podpory pouze v produktovém marketingu. Pro manažery compliance: nevytvářejte samostatné silo důkazů pro CRA. Pro auditory: testujte, zda jsou závazky podpory dohledatelné k rizikům, opatřením, dodavatelům, incidentům a dokumentovaným schválením. Pro vlastníky společnosti: mějte na paměti, že důvěryhodné období podpory se může stát tržní výhodou, zejména při prodeji do odvětví regulovaných NIS2, finančním subjektům podle DORA a zákazníkům citlivým na ochranu soukromí.

Clarysec pomáhá organizacím tento přístup operacionalizovat prostřednictvím:

• Zenith Blueprint: 30krokové roadmapy auditora Zenith Blueprint pro budování dohledatelnosti ISMS, dokumentovaných informací, mapování SoA a připravenosti na audit,
• Zenith Controls: průvodce souladem napříč rámci Zenith Controls pro mapování opatření ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 a auditní očekávání,
• podnikových balíčků politik a balíčků politik pro MSP pro řízení zranitelností, bezpečný vývoj, právní soulad, dodavatelské závislosti, důkazy v oblasti ochrany soukromí a reakci na incidenty,
• praktických registrů a pracovních postupů pro důkazy, které mění přísliby období podpory v auditovatelnou správu a řízení.

Váš další krok je jednoduchý: vyberte jednu vlajkovou verzi produktu a vytvořte její důkazní složku k období bezpečnostní podpory. Namapujte povinnost, schvalte období podpory, otestujte proces zranitelností, ověřte dodavatelské závislosti, potvrďte komunikaci se zákazníky a uchovejte záznamy.

Pokud dokážete obhájit jeden produkt, můžete model škálovat. Pokud nedokážete obhájit jeden produkt, mezera není v dokumentaci. Je ve správě a řízení.

Stáhněte si Zenith Blueprint, použijte Zenith Controls k mapování svých důkazů nebo požádejte o posouzení připravenosti Clarysec, abyste proměnili období bezpečnostní podpory podle CRA ve správu a řízení podle ISO 27001 připravenou pro audit.