ES CRA saugumo palaikymo laikotarpiai taikant ISO 27001

Antradienį 08:20 prijungto B2B tinklų sietuvo produkto savininkas gauna reguliuojamo kliento žinutę: „Prašome patvirtinti programinės aparatinės įrangos 4.6 versijos saugumo palaikymo laikotarpį, reagavimo į pažeidžiamumus SLA ir tai, ar įrenginys išliks tinkamas saugumo naujiniams visą mūsų penkerių metų paslaugų sutarties laikotarpį.“

Iki 09:00 pirkimų skyrius persiunčia DORA deramo patikrinimo klausimyną. 10:15 teisės skyrius klausia, ar reklamuojamas palaikymo laikotarpis atitinka klientų sutartis. 11:00 informacijos saugumo vadovas (CISO) įtraukiamas į NIS2 tiekėjų rizikos peržiūrą, nes produktą ES naudoja valdomų paslaugų teikėjas. Po pietų privatumo komanda klausia, ar nebepalaikoma produkto API biblioteka gali paveikti asmens duomenų saugumą pagal GDPR.

Nemaloni tiesa paaiškėja greitai. Įmonė turi veiksmų planą, pataisų diegimo procesą, išleidimų kalendorių ir klientų palaikymo portalą, tačiau neturi valdomų saugumo palaikymo laikotarpio įrodymų.

Ši spraga reikšminga. Pagal ES Kibernetinio atsparumo aktą saugumo palaikymo laikotarpis nėra vien produkto etiketė. Tai gyvavimo ciklo įsipareigojimas, darantis įtaką pažeidžiamumų valdymui, naujinių prieinamumui, tiekėjų priklausomybių valdymui, komunikacijai su klientais, sutartiniams pareiškimams ir stebėsenai po pateikimo rinkai. SaaS tiekėjams, įrenginių gamintojams, programinės įrangos leidėjams, debesijos paslaugų teikėjams ir IRT paslaugų teikėjams palaikymo laikotarpis tampa atitikties objektu, kurį tikrins auditoriai ir reguliuojami pirkėjai.

Praktinis atsakymas nėra dar viena atskira atitikties skaičiuoklė. Reikia saugumo palaikymo laikotarpį valdyti ISO/IEC 27001:2022 informacijos saugumo valdymo sistemoje, o tuos pačius įrodymus susieti su NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT tipo audito lūkesčiais.

Toks yra Clarysec veiklos modelis: naudoti ISVS kaip įrodymų variklį, taikyti įgyvendinamas politikas atsakomybėms apibrėžti, naudoti Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint atsekamumui sukurti ir naudoti Zenith Controls: The Cross-Compliance Guide Zenith Controls kaip kelių atitikties režimų orientyrą.

Kodėl saugumo palaikymo laikotarpis dabar yra audito objektas

Saugumo palaikymo laikotarpis atsako į paprastą klausimą: kiek laiko gamintojas teiks produkto arba produkto versijos saugumo naujinius, pažeidžiamumų šalinimą, rizikos mažinimo gaires ir susijusį klientų palaikymą?

Praktikoje šis atsakymas priklauso nuo daugelio elementų:

• Produkto architektūros ir palaikomumo
• Trečiųjų šalių komponentų ir atvirojo kodo priklausomybių palaikymo
• Tiekėjų ir debesijos paslaugų įsipareigojimų
• Pranešimų apie pažeidžiamumus priėmimo, pirminio vertinimo, šalinimo ir atskleidimo procesų
• Išleidimų inžinerijos ir testavimo pajėgumų
• Klientų sutarčių sąlygų ir reglamentavimo įpareigojimų
• Reagavimo į incidentus ir pranešimo paslaugų gavėjui kanalų
• Įrodymų saugojimo ir patvirtinimų įrašų

Jei gamintojas pažada penkerių metų saugumo palaikymą, tačiau kritinė kriptografinė biblioteka po trejų metų tampa nebepalaikoma, palaikymo laikotarpis tampa rizikos sprendimu. Jei klientas yra finansų sektoriaus subjektas, kuriam taikoma DORA, tas pats palaikymo laikotarpis tampa trečiųjų šalių IRT patikinimo dalimi. Jei produktas tvarko asmens duomenis, nebepalaikoma programinė įranga gali tapti GDPR tvarkymo saugumo atskaitomybės dalimi. Jei produktas palaiko esminį ar svarbų subjektą pagal NIS2, gyvavimo ciklo saugumas tampa tiekimo grandinės saugumo klausimu.

NIS2 aiškiai iškelia šį valdysenos aspektą. 20 straipsnyje reikalaujama, kad esminių ir svarbių subjektų valdymo organai patvirtintų kibernetinio saugumo rizikos valdymo priemones, prižiūrėtų jų įgyvendinimą ir dalyvautų mokymuose. 21 straipsnyje reikalaujama tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių, įskaitant rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, saugų kūrimą ir priežiūrą, pažeidžiamumų valdymą ir atskleidimą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, prieigos kontrolę, turto valdymą ir autentifikavimą. 23 straipsnyje šios pareigos papildomos etapinėmis pareigomis pranešti apie reikšmingus incidentus.

DORA sukuria panašų spaudimą finansų sektoriaus subjektams. Ji reikalauja IRT rizikos valdymo, skaitmeninės veiklos atsparumo testavimo, incidentų valdymo ir trečiųjų šalių IRT rizikos valdysenos. DORA 28 straipsnis apima trečiųjų šalių IRT rizikos valdymo principus, o 30 straipsnyje reikalaujama rašytinių sutartinių susitarimų su aiškiais paslaugų aprašymais, saugumo priemonėmis, pagalba incidentų atveju, audito teisėmis, nutraukimo teisėmis ir pasitraukimo susitarimais.

GDPR prideda privatumo sluoksnį. Jei produktas tvarko asmens duomenis, duomenų valdytojams ir duomenų tvarkytojams reikia tinkamų techninių ir organizacinių priemonių pagal 32 straipsnį, sutartinio aiškumo pagal 28 straipsnį ir pasirengimo pažeidimo vertinimui bei pranešimui pagal 33 ir 34 straipsnius.

Todėl CRA saugumo palaikymo laikotarpis turi būti valdomas kaip ISVS kontrolės priemonių šeima, o ne kaip atskiras produkto valdymo laukas.

ISO 27001 kaip CRA saugumo palaikymo laikotarpių kontrolės pagrindas

ISO/IEC 27001:2022 yra vertingas, nes yra lankstus mastelio požiūriu, rizika grindžiamas ir orientuotas į valdymo sistemą. Jis reikalauja, kad organizacija apibrėžtų kontekstą, suinteresuotąsias šalis, taikymo sritį ir sąveikaujančius procesus, o tada teisinius, reglamentavimo ir sutartinius reikalavimus paverstų rizikos vertinimu, rizikos tvarkymu, operacinėmis kontrolės priemonėmis ir įrodymais ISO/IEC 27001:2022.

Saugumo palaikymo laikotarpio valdysenai tai reiškia, kad organizacija turi:

1. Nustatyti į taikymo sritį patenkančius produktus, versijas, modulius, debesijos paslaugas ir priklausomybes.
2. Nustatyti suinteresuotąsias šalis, įskaitant klientus, reguliavimo institucijas, platintojus, importuotojus, integratorius, duomenų tvarkytojus, subtvarkytojus, reagavimo į incidentus partnerius ir tiekėjus.
3. Užregistruoti teisinius, reglamentavimo ir sutartinius palaikymo įpareigojimus.
4. Įvertinti rizikas, kurios galėtų sutrukdyti įvykdyti palaikymo įsipareigojimus.
5. Parinkti kontrolės priemones pažeidžiamumų valdymui, saugiam kūrimui, tiekėjų patikinimui, incidentų valdymui, veiklos tęstinumui, privatumui ir dokumentuotai informacijai.
6. Parengti Taikomumo pareiškimo pastabas, paaiškinančias, kodėl kontrolės priemonės taikomos.
7. Peržiūrėti palaikymo laikotarpį, kai keičiasi architektūra, tiekėjų priklausomybės, grėsmių ekspozicija ar klientų įsipareigojimai.

Zenith Controls nurodo tris su šia tema susijusias ISO/IEC 27002:2022 kontrolės priemones kaip pagrindinius šios valdysenos problemos atskaitos taškus: 5.31 teisiniai, įstatyminiai, reglamentavimo ir sutartiniai reikalavimai, 8.8 techninių pažeidžiamumų valdymas ir 8.25 saugaus kūrimo gyvavimo ciklas. Tai nėra vienintelės susijusios kontrolės priemonės, tačiau jos sudaro valdysenos pagrindą.

Svarbiausia – atsekamumas. Produkto palaikymo laikotarpis turi būti atsekamas nuo įpareigojimo iki rizikos scenarijaus, nuo rizikos scenarijaus iki pasirinktų kontrolės priemonių, nuo kontrolės priemonių iki politikos reikalavimų ir nuo politikos reikalavimų iki įrodymų.

Zenith Blueprint, rizikos valdymo etapas, 13 žingsnis, šią atsekamumo discipliną aprašo tiesiogiai:

„Kryžmiškai susiekite reglamentus: jei tam tikros kontrolės priemonės įgyvendinamos konkrečiai tam, kad būtų laikomasi GDPR, NIS2 arba DORA, tai galite pažymėti Rizikų registre (kaip rizikos poveikio pagrindimo dalį) arba SoA pastabose.“

Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, rizikos valdymo etapas, 13 žingsnis: rizikos tvarkymo planavimas ir Taikomumo pareiškimas Zenith Blueprint

CRA saugumo palaikymo laikotarpiui Taikomumo pareiškime neturi būti vien parašyta „pažeidžiamumų valdymas taikomas“. Jame turi būti paaiškinta, kad pažeidžiamumų valdymas taikomas todėl, kad įmonė turi CRA gyvavimo ciklo įsipareigojimus, NIS2 saugaus kūrimo ir tiekimo grandinės lūkesčius, DORA klientų deramo patikrinimo reikalavimus, GDPR saugumo įpareigojimus, kai tvarkomi asmens duomenys, ir sutartinius palaikymo pažadus.

Nuo palaikymo pažado iki valdomo gyvavimo ciklo

Gamintojo nustatytas saugumo palaikymo laikotarpis turi atitikti šešis valdysenos kriterijus.

Pirma, jis turi būti apibrėžtas. Organizacijai reikia standartinės taksonomijos, pavyzdžiui: aktyvus palaikymas, tik saugumo palaikymas, išplėstinis palaikymas, ribotas palaikymas ir nepalaikoma būsena. Kiekviena būsena turi paaiškinti naujinių prieinamumą, pažeidžiamumų valdymą, komunikaciją su klientais ir eskalavimo kelius.

Antra, jis turi būti įvertintas rizikos požiūriu. Penkerių metų palaikymas debesijos paslaugų valdomam SaaS produktui su kontroliuojamais naujinimo kanalais skiriasi nuo penkerių metų palaikymo įterptajam įrenginiui, turinčiam eksploatavimo lauko sąlygomis apribojimų, trečiųjų šalių lustų priklausomybių ir klientų valdomų diegimo langų.

Trečia, jis turi būti patvirtintas. Produkto, saugumo, teisės, privatumo, klientų palaikymo funkcijos ir atskaitinga vadovybė turi patvirtinti bazinį laikotarpį ir išimtis.

Ketvirta, apie jį turi būti komunikuojama. Klientai turi suprasti palaikymo pradžios datą, pabaigos datą, naujinimo metodą, pranešimo apie pažeidžiamumus kanalą, šalinimo lūkesčius, palaikymo pabaigos pasekmes ir galimas pratęsimo parinktis.

Penkta, jis turi būti stebimas. Priklausomybės keičiasi. Tiekėjai nutraukia bibliotekų palaikymą. Atsiranda pažeidžiamumų. Keičiasi klientų aplinkos. Palaikymo laikotarpių valdysena turi apimti komponentų gyvavimo ciklo stebėseną, tiekėjų peržiūrą, pažeidžiamumų informacijos srautus, pataisų žurnalus, išleidimų testavimą ir incidentų metu įgytas pamokas.

Šešta, jis turi būti pagrįstas įrodymais. Jei auditorius, reguliavimo institucija ar reguliuojamas klientas paprašo įrodymų, organizacija turi pateikti atitikties registrą, produkto palaikymo registrą, rizikos vertinimą, Taikomumo pareiškimo susiejimą, pažeidžiamumų registrą, pataisų įrašus, tiekėjų peržiūras, išleidimų patvirtinimus ir klientų pranešimus.

Clarysec politikos tai paverčia praktika. Įmonės Teisinės ir reglamentavimo atitikties politika Teisinės ir reglamentavimo atitikties politika reikalauja:

„Visi teisiniai ir reglamentavimo įpareigojimai turi būti susieti su konkrečiomis politikomis, kontrolės priemonėmis ir savininkais Informacijos saugumo valdymo sistemoje (ISVS).“

Šaltinis: Teisinės ir reglamentavimo atitikties politika, politikos įgyvendinimo reikalavimai, 6.2.1 punktas Teisinės ir reglamentavimo atitikties politika

MVĮ lygiavertė disciplina prasideda nuo paprastesnio registro. MVĮ Teisinės ir reglamentavimo atitikties politika-sme Teisinės ir reglamentavimo atitikties politika - SME nustato:

„Generalinis vadovas turi tvarkyti paprastą, struktūrizuotą Atitikties registrą, kuriame nurodoma:“

Šaltinis: Teisinės ir reglamentavimo atitikties politika-sme, valdysenos reikalavimai, 5.1.1 punktas Teisinės ir reglamentavimo atitikties politika - SME

Palaikymo laikotarpio įsipareigojimas turi būti atitikties registre, jei jį lemia teisės aktas, kliento sutartis, sektoriaus reglamentavimas arba reguliuojamo pirkėjo lūkestis. Jis neturi egzistuoti tik išleidimo pastabose ar rinkodaros tekste.

Sukurkite CRA saugumo palaikymo laikotarpių registrą vienose dirbtuvėse

Įsivaizduokite SaaS tiekėją, kuris ES logistikos paslaugų teikėjams ir finansų sektoriaus klientams parduoda prijungtą analitikos įrenginį. Produktą sudaro įterptasis agentas, debesijos API, mobilioji administratoriaus programa ir kelios atvirojo kodo bibliotekos. Pardavimų komanda nori pažadėti penkerių metų saugumo palaikymą kiekvienai pagrindinei įrenginio versijai.

Informacijos saugumo vadovas (CISO) gali surengti kryptingas dirbtuves su produkto, inžinerijos, teisės, privatumo ir tiekėjų valdymo komandomis.

1 žingsnis: sukurkite palaikymo laikotarpių registrą

Kiekvienai produkto versijai sukurkite po vieną eilutę ir įtraukite:

• Produktą ir versiją
• Išleidimo datą
• Palaikymo pradžios datą
• Standartinę saugumo palaikymo pabaigos datą
• Išplėstinio palaikymo parinktį
• Naujinių pristatymo metodą
• Pažeidžiamumų atskleidimo kanalą
• Kritinės pataisos tikslinį terminą
• Duomenų tvarkymo vaidmenį, pavyzdžiui, duomenų valdytojas, duomenų tvarkytojas arba abu
• Kritinius tiekėjus ir komponentus
• Paveikiamus klientų sektorius
• Rizikos savininką
• Patvirtinimo datą
• Įrodymų vietą

Šis registras tampa dokumentuota informacija ISVS. Zenith Blueprint, ISVS pagrindų ir lyderystės etapas, 6 žingsnis, pateikia dokumentų kontrolės lūkestį:

„Dokumentai turėtų turėti tinkamą identifikavimą (pavadinimą, galbūt dokumento numerį ar unikalų identifikatorių, autorių), tinkamą formatą ir būti peržiūrėti bei patvirtinti dėl tinkamumo prieš naudojimą.“

Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, ISVS pagrindų ir lyderystės etapas, 6 žingsnis: dokumentuota informacija ir ISVS bibliotekos kūrimas Zenith Blueprint

Clarysec įmonės PIMS dokumentuotos informacijos ir įrodymų valdymo politika PIMS dokumentuotos informacijos ir įrodymų valdymo politika panašius įrodymų principus taiko privatumo dokumentacijai:

„[Visi] Privatumo vadovas / PIMS vadovas PRIVALO priskirti dokumento identifikatorių, savininką, versijos numerį, patvirtinimo būseną, įsigaliojimo datą ir peržiūros datą REG12 prieš paskelbdamas PIMS dokumentuotą informaciją.“

Šaltinis: PIMS dokumentuotos informacijos ir įrodymų valdymo politika, kūrimas, patvirtinimas, versijų valdymas ir paskelbimas, 4.2.1 punktas PIMS dokumentuotos informacijos ir įrodymų valdymo politika

Net jei palaikymo laikotarpių registras pagal numatytuosius nustatymus nėra privatumo dokumentas, ta pati disciplina taikoma: savininkas, versija, patvirtinimas, įsigaliojimo data ir peržiūros data.

2 žingsnis: susiekite palaikymo pažadus su rizikos tvarkymu

Kiekvienai produkto versijai sukurkite rizikos scenarijus, pavyzdžiui:

• Palaikomoje versijoje aptinkamas kritinis pažeidžiamumas, tačiau nėra inžinerinių pajėgumų.
• Trečiosios šalies komponentas tampa nebepalaikomas iki deklaruoto saugumo palaikymo laikotarpio pabaigos.
• Tiekėjas pakeičia prieglobos vietą arba subtiekėją ir tai paveikia naujinių pristatymą.
• Pažeidžiamumas paveikia asmens duomenis ir inicijuoja privatumo pažeidimo vertinimą.
• Reguliuojamas finansų sektoriaus klientas reikalauja IRT trečiųjų šalių atsparumo įrodymų.

ISO/IEC 27001:2022 6.1.1–6.1.3 punktai suteikia planavimo mechanizmą: nustatyti rizikas, įvertinti tikimybę ir pasekmes, priskirti rizikos savininkus, parinkti rizikos tvarkymo būdus, palyginti pasirinktas kontrolės priemones su A priedu, parengti Taikomumo pareiškimą ir gauti likutinės rizikos patvirtinimą.

Rizikai „nebepalaikomas komponentas iki palaikymo pabaigos datos“ rizikos įraše turi būti nurodytos ISO/IEC 27002:2022 kontrolės priemonės 5.31, 8.8 ir 8.25, taip pat tiekėjų kontrolės priemonės, tokios kaip 5.19 informacijos saugumas santykiuose su tiekėjais, 5.20 informacijos saugumo įtraukimas į tiekėjų susitarimus, 5.21 informacijos saugumo valdymas IRT tiekimo grandinėje ir 5.22 tiekėjų paslaugų stebėsena, peržiūra ir pakeitimų valdymas.

3 žingsnis: nustatykite pažeidžiamumų ir pataisų įrodymų taisykles

Palaikymo laikotarpis patikimas tik tada, kai pažeidžiamumų valdymas tuo laikotarpiu veikia.

MVĮ Pažeidžiamumų ir pataisų valdymo politika-sme Pažeidžiamumų ir pataisų valdymo politika - SME nustato griežtą reikalavimą skubiai ekspozicijai:

„Kritinės pataisos turi būti pritaikytos per 3 dienas nuo išleidimo, ypač į internetą nukreiptoms sistemoms“

Šaltinis: Pažeidžiamumų ir pataisų valdymo politika-sme, politikos įgyvendinimo reikalavimai, 6.1.1 punktas Pažeidžiamumų ir pataisų valdymo politika - SME

Ji taip pat reikalauja auditui tinkamų įrašų:

„Pataisų žurnalas turi būti tvarkomas ir peržiūrimas auditų bei reagavimo į incidentus veiklų metu“

Šaltinis: Pažeidžiamumų ir pataisų valdymo politika-sme, valdysenos reikalavimai, 5.4.1 punktas Pažeidžiamumų ir pataisų valdymo politika - SME

Įmonės aplinkoms įmonės Pažeidžiamumų ir pataisų valdymo politika Pažeidžiamumų ir pataisų valdymo politika reikalauja:

„Saugumo operacijų komanda turi tvarkyti centralizuotą Pažeidžiamumų valdymo registrą, kurį kas mėnesį peržiūri CISO arba deleguota institucija.“

Šaltinis: Pažeidžiamumų ir pataisų valdymo politika, valdysenos reikalavimai, 5.1 punktas Pažeidžiamumų ir pataisų valdymo politika

Zenith Blueprint, kontrolės priemonių taikymo etapas, 19 žingsnis, paaiškina operacinį lūkestį, susijusį su ISO/IEC 27002:2022 kontrole 8.8:

„Sekite informaciją apie naujas saugumo klaidas (per tiekėjų įspėjimus, CVE srautus ir pan.) savo programinei ir aparatiniai įrangai. Įvertinkite, kurios aktualios (ar naudojame šią programinę įrangą? kiek kritinė ši klaida?) ir nedelsdami pritaikykite pataisas arba rizikos mažinimo priemones.“

Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, kontrolės priemonių taikymo etapas, 19 žingsnis: technologinės kontrolės priemonės I Zenith Blueprint

Kiekvienai palaikomai produkto versijai reikia pažeidžiamumų įrodymų pėdsako: pranešimo priėmimo, aktualumo analizės, sunkumo, paveiktų versijų, taisomųjų veiksmų plano, pataisos išleidimo, rizikos mažinimo gairių, komunikacijos su klientais ir uždarymo patvirtinimo.

4 žingsnis: susiekite saugų kūrimą su palaikymo trukme

Saugumo palaikymas prasideda prieš išleidimą. Jis priklauso nuo kūrimo praktikų, kurios leidžia produktą prižiūrėti.

MVĮ Saugaus kūrimo politika-sme Saugaus kūrimo politika - SME nustato:

„Komponentai turi būti reguliariai atnaujinami, kai išleidžiamos saugumo pataisos. Jei nustatomas kritinis pažeidžiamumas, komponentas turi būti nedelsiant atnaujintas arba pakeistas.“

Šaltinis: Saugaus kūrimo politika-sme, politikos įgyvendinimo reikalavimai, 6.6.3 punktas Saugaus kūrimo politika - SME

MVĮ Taikomųjų programų saugumo reikalavimų politika-sme Taikomųjų programų saugumo reikalavimų politika - SME reikalauja, kad sutartys ir reikalavimai:

„nustatytų įpareigojimus dėl pažeidžiamumų atskleidimo, reagavimo terminų ir pataisų diegimo.“

Šaltinis: Taikomųjų programų saugumo reikalavimų politika-sme, valdysenos reikalavimai, 5.3.2 punktas Taikomųjų programų saugumo reikalavimų politika - SME

Jei įmonė pažada palaikymą iki 2031 m., architektūra turi palaikyti prižiūrimus naujinimus, priklausomybių pakeitimą, saugius surinkimo konvejerius, regresinį testavimą ir neatidėliotinus išleidimus. ISO/IEC 27002:2022 kontrolės priemonės, susijusios su saugiu kūrimu, saugia architektūra, saugiu programavimu, saugumo testavimu, išoriniu kūrimu, aplinkų atskyrimu ir pakeitimų valdymu, tampa palaikymo laikotarpio įgalinančiomis priemonėmis.

Vienas įrodymų rinkinys CRA, NIS2, DORA ir GDPR

Tie patys palaikymo laikotarpio įrodymai gali tenkinti skirtingas reglamentavimo diskusijas, tačiau kiekviena sistema klausimą formuluoja skirtingai.

Tiekėjų priklausomybė dažnai yra vieta, kur palaikymo įsipareigojimai žlunga. Įmonės Tiekėjų priklausomybės rizikos valdymo politika Tiekėjų priklausomybės rizikos valdymo politika reikalauja:

„Tiekėjų priklausomybės registras: VMO turi tvarkyti naujausią visų kritinių tiekėjų registrą, įskaitant tokias detales kaip teikiamos paslaugos / produktai; ar tiekėjas yra vienintelis šaltinis; galimi alternatyvūs tiekėjai arba pakeičiamumas; esamos sutarties sąlygos; ir poveikio vertinimas, jei tiekėjas nustotų veikti arba būtų kompromituotas.“

Šaltinis: Tiekėjų priklausomybės rizikos valdymo politika, įgyvendinimo reikalavimai, 6.1 punktas Tiekėjų priklausomybės rizikos valdymo politika

Zenith Blueprint, kontrolės priemonių taikymo etapas, 23 žingsnis, įspėja, kad auditoriai tikrins tiekėjų susitarimus ir tiekėjų stebėsenos įrodymus:

„Auditoriai peržiūrės sutarčių ar paslaugų susitarimų pavyzdžius. Jie ieškos aiškių informacijos saugumo nuostatų, pavyzdžiui, pranešimų apie pažeidimus terminų, prieigos apribojimų, duomenų tvarkymo įpareigojimų, šifravimo reikalavimų arba audito teisių.“

Šaltinis: Zenith Blueprint: An Auditor’s 30-Step Roadmap, kontrolės priemonių taikymo etapas, 23 žingsnis: organizacinės kontrolės priemonės Zenith Blueprint

DORA klientams tai kritiška. IRT paslaugų, palaikančių svarbias ar ypatingos svarbos funkcijas, sutartims reikia aiškių paslaugų aprašymų, subtiekimo sąlygų, saugumo priemonių, pagalbos incidentų atveju, audito ir patikrinimo teisių, nutraukimo teisių ir pereinamojo laikotarpio susitarimų. Tiekėjas, kuris negali palaikyti šių įsipareigojimų, gali sutrukdyti gamintojui pateikti patikimą palaikymo laikotarpio pažadą.

Kontrolės priemonių susiejimas auditui tinkamai palaikymo laikotarpio valdysenai

Šis susiejimas leidžia saugumo, teisės, produkto ir pardavimų komandoms kalbėti viena kalba. Palaikymo laikotarpių registras nėra vien CRA įrodymai. Tai tiekėjų patikinimas NIS2 kontekste, trečiųjų šalių patikinimas DORA kontekste, tvarkymo saugumo pagrindimas GDPR kontekste ir valdysenos artefaktas ISO 27001 sertifikavimui.

Privatumo aspektas: kai nepalaikoma tampa nesaugu

Saugumo palaikymo laikotarpio valdysena nėra vien kibernetinio saugumo klausimas. Jei produktas saugo, perduoda arba tvarko asmens duomenis, nepalaikoma programinė įranga gali tapti privatumo rizika.

GDPR taikomas duomenų tvarkymui ES įsisteigimo kontekste ir taip pat gali būti taikomas ne ES organizacijoms, siūlančioms prekes ar paslaugas asmenims ES arba stebinčioms jų elgseną. Jis plačiai apibrėžia asmens duomenis ir asmens duomenų saugumo pažeidimą laiko saugumo pažeidimu, dėl kurio netyčia ar neteisėtai sunaikinami, prarandami, pakeičiami, be leidimo atskleidžiami tvarkomi asmens duomenys arba suteikiama prieiga prie jų.

Palaikymo laikotarpio valdysenai privatumo komandos turi žinoti, kurios produkto versijos tvarko PII, kurios sistemos vis dar palaikomos ir ar pažeidžiamumai daro poveikį asmens duomenų konfidencialumui, vientisumui arba prieinamumui.

Clarysec įmonės PII saugumo prieigos kontrolės politika PII saugumo prieigos kontrolės politika reikalauja:

„[Abu] Sistemos savininkas / Taikomosios programos savininkas PRIVALO bent kartą per ketvirtį ir po esminio techninio pakeitimo REG12 užregistruoti sistemų, tvarkančių PII, pažeidžiamumų vertinimo aprėptį.“

Šaltinis: PII saugumo prieigos kontrolės politika, saugus konfigūravimas ir pažeidžiamumų valdymas, 4.7.4 punktas PII saugumo prieigos kontrolės politika

Įmonės Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politika Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politika prideda nuolatinę didelės rizikos privatumo santykių stebėseną:

„[Visi] Tiekėjo / pirkimų savininkas PRIVALO kas ketvirtį stebėti aktyvius didelės rizikos duomenų tvarkytojų ir subtvarkytojų santykius, o kitus aktyvius PII duomenų tvarkytojų ir subtvarkytojų santykius – kasmet, vertindamas juos pagal deramo patikrinimo sąlygas, sutarties būseną, patikinimo būseną, atvirus klausimus ir peržiūros datas REG08.“

Šaltinis: Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politika, nuolatinė stebėsena, pagalba, atskleidimo sąsaja ir pasitraukimas, 4.5.1 punktas Duomenų tvarkytojų, subtvarkytojų ir trečiųjų šalių privatumo valdymo politika

Kai pažeidžiamumas tampa incidentu, įmonės PII incidentų ir pažeidimų valdymo politika PII incidentų ir pažeidimų valdymo politika reikalauja kelių sistemų inicijavimo sąlygų vertinimo:

„[Sąlyginai] Privatumo vadovas / PIMS vadovas PRIVALO kiekvienam didelio poveikio PII incidentui įvertinti taikomas teisines, sektorines, finansų sektoriaus, kibernetinio saugumo, sutartines, klientų ir paslaugos gavėjų pranešimo inicijavimo sąlygas ir užregistruoti taikomumo rezultatą REG01, REG08 ir REG10.“

Šaltinis: PII incidentų ir pažeidimų valdymo politika, klasifikavimas ir pažeidimo vertinimas, 4.2.6 punktas PII incidentų ir pažeidimų valdymo politika

Tai praktinė CRA palaikymo įsipareigojimų, NIS2 incidentų komunikacijos, DORA reikšmingų IRT incidentų valdymo ir GDPR pažeidimų atskaitomybės sankirta.

Kaip auditoriai tikrina tą patį palaikymo laikotarpio procesą

Stiprus palaikymo laikotarpio valdysenos procesas turi atlaikyti skirtingus audito stilius. Įrodymai daug nesikeičia, tačiau skiriasi auditoriaus perspektyva.

NIST CSF 2.0 naudingas kaip komunikacijos sluoksnis, nes jo GOVERN funkcija apima teisinius, reglamentavimo, sutartinius ir privatumo įpareigojimus, rizikos valdymo tikslus, rizikos apetitą, vaidmenis, politikas ir priežiūrą. Jo tiekimo grandinės rezultatai apima tiekėjų strategiją, kritiškumą, sutartis, deramą patikrinimą, stebėseną, incidentų koordinavimą ir santykių pabaigos nuostatas.

COBIT ir ISACA tipo auditoriai dažnai sutelkia dėmesį į valdysenos projektavimą: kas yra sprendimo savininkas, koks procesas apibrėžtas, kokie rodikliai rodo veiksmingumą, kaip tvirtinamos išimtys ir kaip vykdomas nuolatinis tobulinimas.

Clarysec įmonės Informacijos saugumo politika Informacijos saugumo politika įtvirtina audituojamumo principą:

„Visos įgyvendintos kontrolės priemonės turi būti audituojamos, pagrįstos dokumentuotomis procedūromis ir saugomais veikimo įrodymais.“

Šaltinis: Informacijos saugumo politika, politikos įgyvendinimo reikalavimai, 6.6.1 punktas Informacijos saugumo politika

Šį sakinį turi gebėti pagrįsti kiekvienas saugumo palaikymo laikotarpis.

Pratęskite, sutrumpinkite arba užbaikite palaikymą nesukurdami klaidingo patikinimo

Sudėtingiausi valdysenos momentai įvyksta ne produkto išleidimo metu. Jie atsiranda pasikeitus realybei.

Gali reikėti pratęsti palaikymą, nes reguliuojami klientai priklauso nuo produkto, migracija neįmanoma arba sektoriaus klientas turi sutartinių tęstinumo poreikių. Gali reikėti sutrumpinti arba apriboti palaikymą, nes tiekėjas nutraukia saugumo priežiūrą, komponento nebeįmanoma pataisyti, platforma pasiekia technines ribas arba produkto architektūra negali saugiai palaikyti tam tikros pažeidžiamumų klasės.

Kontroliuojamas palaikymo laikotarpio pakeitimas turi apimti:

• Pakeitimo inicijavimo sąlygą, pavyzdžiui, tiekėjo eksploatacijos pabaigą, kritinį pažeidžiamumą, kliento sutartį arba reglamentavimo pokytį
• Paveiktus produktus, versijas, klientus ir sektorius
• Asmens duomenų ir kritinės paslaugos poveikio analizę
• Tiekėjų ir komponentų įgyvendinamumo peržiūrą
• Rizikos vertinimą ir likutinės rizikos sprendimą
• Atnaujintą palaikymo laikotarpių registrą
• Atnaujintą kliento pranešimą ir sutartinę poziciją
• Atnaujintas Taikomumo pareiškimo pastabas, kai keičiasi kontrolės priemonės arba įpareigojimai
• Vadovybės patvirtinimą ir peržiūros datą

Įmonės Koordinuoto pažeidžiamumų atskleidimo politika Koordinuoto pažeidžiamumų atskleidimo politika naudinga, kai pakeitimą lemia pažeidžiamumas:

„Visiems patvirtintiems pažeidžiamumams turi būti parengtas taisomųjų veiksmų arba rizikos mažinimo planas. Pataisos įgyvendinimas turi būti prioritetizuojamas pagal sunkumą. Pavyzdžiui, kritiniai pažeidžiamumai, kai įmanoma, turi būti ištaisyti arba sumažinti per 14 dienų, arba greičiau, kai aptinkamas aktyvus išnaudojimas, o mažesnio sunkumo klausimai turi būti sprendžiami per pagrįstą terminą.“

Šaltinis: Koordinuoto pažeidžiamumų atskleidimo politika, įgyvendinimo reikalavimai, 6.6 punktas Koordinuoto pažeidžiamumų atskleidimo politika

Jei visos pataisos negalima pateikti nedelsiant, laikinai gali būti priimtinos kompensuojančios kontrolės priemonės, išjungtas funkcionalumas, sustiprinta stebėsena arba klientų konfigūravimo gairės, tačiau sprendimas turi būti dokumentuotas ir komunikuotas.

Praktinis Clarysec kontrolinis sąrašas pasirengimui dėl palaikymo laikotarpio

Naudokite šį kontrolinį sąrašą prieš paskelbdami arba atnaujindami bet kokį CRA saugumo palaikymo laikotarpio įsipareigojimą.

• Ar produktas ir versija įtraukti į palaikymo laikotarpių registrą?
• Ar palaikymo pabaigos datą patvirtino produkto komanda, saugumo komanda ir atskaitinga vadovybė?
• Ar teisiniai, reglamentavimo ir sutartiniai veiksniai susieti atitikties registre?
• Ar palaikymo laikotarpio rizikos scenarijus įtrauktas į rizikų registrą?
• Ar kontrolės priemonės susietos Taikomumo pareiškime, įskaitant 5.31, 8.8 ir 8.25, kai taikoma?
• Ar kritiniai tiekėjai ir komponentai susieti tiekėjų priklausomybių registre?
• Ar yra įrodymų, kad komponentus galima pataisyti arba pakeisti palaikymo laikotarpiu?
• Ar apibrėžtos pranešimų apie pažeidžiamumus priėmimo, pirminio vertinimo, šalinimo ir atskleidimo atsakomybės?
• Ar kritinių pataisų SLA suderinti su politika ir klientų sutartimis?
• Ar saugomi pataisų žurnalai, išleidimų įrašai ir sprendimai dėl pažeidžiamumų?
• Ar asmens duomenų sistemos padengtos pažeidžiamumų vertinimo įrodymais, kai tvarkomi PII?
• Ar klientų pranešimai, palaikymo pareiškimai ir sutartinės sąlygos nuoseklūs?
• Ar yra procesas palaikymui pratęsti, sutrumpinti arba užbaigti su rizikos patvirtinimu?
• Ar vadovybės peržiūrai teikiama informacija apie palaikymo laikotarpio riziką, tiekėjus, pažeidžiamumus ir incidentus?
• Ar įrodymai gali būti pateikti per 48 valandas kliento auditui arba reguliavimo institucijos paklausimui?

Įmonės PIMS stebėsenos, audito ir tobulinimo politika PIMS stebėsenos, audito ir tobulinimo politika sustiprina vadovybės peržiūros discipliną privatumo programoms:

„[Abu] Aukščiausioji vadovybė PRIVALO kiekvienos vadovybės peržiūros metu REG12 peržiūrėti PIMS neatitiktis, korekcinius veiksmus, stebėsenos rezultatus, audito rezultatus, privatumo riziką, tiekėjų patikinimą ir suinteresuotųjų šalių pokyčių įvestis.“

Šaltinis: PIMS stebėsenos, audito ir tobulinimo politika, PIMS vadovybės peržiūra, 4.3.5 punktas PIMS stebėsenos, audito ir tobulinimo politika

Saugumo palaikymo laikotarpio valdysenai toks pats peržiūros ritmas turi būti taikomas visoje ISVS: pažeidžiamumai, pataisų diegimo veiksmingumas, tiekėjų patikinimas, klientų įsipareigojimai, incidentai, palaikymo išimtys ir korekciniai veiksmai turi būti teikiami vadovybės peržiūrai.

Padarykite saugumo palaikymo laikotarpį pagrindžiamą

ES Kibernetinio atsparumo aktas keičia produkto saugumo logiką. Jis verčia gamintojus ir programinės įrangos teikėjus galvoti plačiau nei tik apie išleidimo dieną. Saugumo palaikymo laikotarpis tampa gyvavimo ciklo pažadu, kuris turi būti suprojektuotas, valdomas, stebimas ir pagrįstas įrodymais.

Informacijos saugumo vadovo (CISO) pamoka aiški: neleiskite, kad palaikymo laikotarpis liktų vien produkto rinkodaroje. Atitikties vadovams – nekurkite atskiro CRA įrodymų siloso. Auditoriams – tikrinkite, ar palaikymo įsipareigojimai atsekami iki rizikos, kontrolės priemonių, tiekėjų, incidentų ir dokumentuotų patvirtinimų. Verslo savininkams – atminkite, kad patikimas palaikymo laikotarpis gali tapti rinkos pranašumu, ypač parduodant NIS2 reguliuojamiems sektoriams, DORA finansų sektoriaus subjektams ir privatumui jautriems klientams.

Clarysec padeda organizacijoms tai įgyvendinti praktiškai per:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, skirtą ISVS atsekamumui, dokumentuotai informacijai, Taikomumo pareiškimo susiejimui ir pasirengimui auditui sukurti
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, skirtą ISO/IEC 27002:2022 kontrolės priemonėms susieti su NIS2, DORA, GDPR, NIST CSF 2.0 ir audito lūkesčiais
• Įmonių ir MVĮ politikų rinkinius pažeidžiamumų valdymui, saugiam kūrimui, teisinei atitikčiai, tiekėjų priklausomybei, privatumo įrodymams ir reagavimui į incidentus
• Praktinius registrus ir įrodymų darbo eigas, kurios palaikymo laikotarpio pažadus paverčia audituojama valdysena

Kitas jūsų žingsnis paprastas: pasirinkite vieną pagrindinę produkto versiją ir sukurkite jos saugumo palaikymo laikotarpio įrodymų bylą. Susiekite įpareigojimą, patvirtinkite palaikymo laikotarpį, patikrinkite pažeidžiamumų procesą, validuokite tiekėjų priklausomybes, patvirtinkite komunikaciją su klientais ir išsaugokite įrašus.

Jei galite pagrįsti vieną produktą, galite modelį mastelinti. Jei negalite pagrįsti vieno produkto, spraga nėra dokumentacijoje. Tai valdysenos spraga.

Atsisiųskite Zenith Blueprint, naudokite Zenith Controls įrodymams susieti arba paprašykite Clarysec pasirengimo vertinimo, kad CRA saugumo palaikymo laikotarpiai taptų auditui tinkama ISO 27001 valdysena.