ES CRA drošības atbalsta periodi ar ISO 27001 pārvaldību

Ir otrdienas 08:20, un savienotas B2B vārtejas produkta īpašnieks saņem ziņu no regulēta klienta: “Lūdzu, apstipriniet drošības atbalsta periodu aparātprogrammatūras versijai 4.6, ievainojamību reaģēšanas SLA un to, vai ierīce arī turpmāk būs tiesīga saņemt drošības atjauninājumus mūsu piecu gadu pakalpojumu līguma laikā.”

Līdz 09:00 iepirkumu komanda ir pārsūtījusi DORA sākotnējās izpētes anketu. Līdz 10:15 juridiskā funkcija jautā, vai reklamētais atbalsta periods atbilst klientu līgumiem. Līdz 11:00 informācijas drošības vadītājs tiek iesaistīts NIS2 piegādātāju riska pārskatīšanā, jo produktu ES izmanto pārvaldītu pakalpojumu sniedzējs. Pēc pusdienām privātuma aizsardzības funkcija jautā, vai neatbalstīta API bibliotēka produktā varētu ietekmēt personas datu drošību saskaņā ar GDPR.

Neērtais secinājums kļūst skaidrs ātri. Uzņēmumam ir ceļkarte, ielāpu process, laidienu kalendārs un klientu atbalsta portāls, taču tam nav pārvaldītu pierādījumu par drošības atbalsta periodu.

Šī nepilnība ir būtiska. Saskaņā ar ES Kibernoturības aktu drošības atbalsta periods nav tikai produkta marķējums. Tā ir dzīves cikla saistība, kas ietekmē ievainojamību apstrādi, atjauninājumu pieejamību, piegādātāju atkarību pārvaldību, komunikāciju ar klientiem, līgumiskos apliecinājumus un pēctirgus uzraudzību. SaaS piegādātājiem, ierīču ražotājiem, programmatūras izdevējiem, mākoņpakalpojumu sniedzējiem un IKT pakalpojumu sniedzējiem atbalsta periods kļūst par atbilstības objektu, ko pārbaudīs auditori un regulēti pircēji.

Praktiskais risinājums nav vēl viena atrauta atbilstības izklājlapa. Risinājums ir pārvaldīt drošības atbalsta periodu ISO/IEC 27001:2022 informācijas drošības pārvaldības sistēmā un pēc tam tos pašus pierādījumus kartēt pret NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT tipa audita gaidām.

Tas ir Clarysec darbības modelis: izmantot IDPS kā pierādījumu dzinēju, izmantot piemērojamās politikas atbildības noteikšanai, izmantot Zenith Blueprint: Auditoru 30 soļu ceļkarte Zenith Blueprint izsekojamības izveidei un izmantot Zenith Controls: Savstarpējās atbilstības ceļvedis Zenith Controls kā savstarpējās atbilstības kompasu.

Kāpēc drošības atbalsta periods tagad ir audita objekts

Drošības atbalsta periods atbild uz vienkāršu jautājumu: cik ilgi ražotājs nodrošinās drošības atjauninājumus, ievainojamību novēršanu, mazināšanas norādījumus un saistīto klientu atbalstu produktam vai produkta versijai?

Praksē šī atbilde ir atkarīga no daudziem mainīgiem elementiem:

• produkta arhitektūras un uzturamības;
• trešo pušu komponentu un atvērtā pirmkoda atkarību atbalsta;
• piegādātāju un mākoņpakalpojumu saistībām;
• ievainojamību ziņojumu pieņemšanas, triāžas, trūkumu novēršanas un izpaušanas procesiem;
• laidienu inženierijas un testēšanas kapacitātes;
• klientu līgumu noteikumiem un regulatīvajiem pienākumiem;
• reaģēšanas uz incidentiem un pakalpojumu saņēmēju informēšanas ceļiem;
• pierādījumu glabāšanas un apstiprinājumu ierakstiem.

Ja ražotājs sola piecu gadu drošības atbalstu, bet kritiska kriptogrāfiskā bibliotēka pēc trim gadiem vairs netiek atbalstīta, atbalsta periods kļūst par riska lēmumu. Ja klients ir finanšu vienība, uz kuru attiecas DORA, tas pats atbalsta periods kļūst par daļu no IKT trešo pušu apliecinājuma. Ja produkts apstrādā personas datus, neatbalstīta programmatūra var kļūt par daļu no GDPR apstrādes drošības pārskatatbildības. Ja produkts atbalsta būtisku vai svarīgu subjektu saskaņā ar NIS2, dzīves cikla drošība kļūst par piegādes ķēdes drošības jautājumu.

NIS2 šo pārvaldības aspektu padara tiešu. 20. pants prasa, lai būtisku un svarīgu subjektu vadības struktūras apstiprinātu kiberdrošības riska pārvaldības pasākumus, pārraudzītu to ieviešanu un saņemtu apmācību. 21. pants prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus, tostarp riska analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi, drošu izstrādi un uzturēšanu, ievainojamību apstrādi un izpaušanu, efektivitātes izvērtēšanu, kiberdrošības higiēnu, kriptogrāfiju, piekļuves kontroli, aktīvu pārvaldību un autentifikāciju. 23. pants papildina prasības ar pakāpeniskiem ziņošanas pienākumiem par nozīmīgiem incidentiem.

DORA rada līdzīgu spiedienu finanšu vienībām. Tā prasa IKT risku pārvaldību, digitālās darbības noturības testēšanu, incidentu pārvaldību un IKT trešo pušu riska pārvaldību. DORA 28. pants aptver IKT trešo pušu riska pārvaldības principus, savukārt 30. pants prasa rakstiskas līgumiskas vienošanās ar skaidriem pakalpojumu aprakstiem, drošības pasākumiem, palīdzību incidentu gadījumā, audita tiesībām, izbeigšanas tiesībām un izstāšanās kārtību.

GDPR pievieno privātuma slāni. Ja produkts apstrādā personas datus, pārziņiem un apstrādātājiem nepieciešami atbilstoši tehniskie un organizatoriskie pasākumi saskaņā ar 32. pantu, līgumiska skaidrība saskaņā ar 28. pantu un gatavība pārkāpuma izvērtēšanai un paziņošanai saskaņā ar 33. un 34. pantu.

Tāpēc CRA drošības atbalsta periods jāpārvalda kā IDPS kontroles pasākumu grupa, nevis kā izolēts produkta pārvaldības lauks.

ISO 27001 kā kontroles pasākumu mugurkauls CRA drošības atbalsta periodiem

ISO/IEC 27001:2022 ir vērtīgs, jo tas ir mērogojams, riskā balstīts un orientēts uz pārvaldības sistēmu. Tas prasa organizācijai definēt kontekstu, ieinteresētās puses, darbības jomu un savstarpēji saistītos procesus, pēc tam pārvērst tiesiskās, regulatīvās un līgumiskās prasības risku izvērtēšanā, riska apstrādē, darbības kontroles pasākumos un pierādījumos ISO/IEC 27001:2022.

Drošības atbalsta perioda pārvaldībai tas nozīmē, ka organizācijai jāveic šādas darbības:

1. Jāidentificē darbības jomā iekļautie produkti, versijas, moduļi, mākoņpakalpojumi un atkarības.
2. Jāidentificē ieinteresētās puses, tostarp klienti, regulatori, izplatītāji, importētāji, integratori, apstrādātāji, apakšapstrādātāji, incidentu reaģēšanas partneri un piegādātāji.
3. Jāreģistrē tiesiskie, regulatīvie un līgumiskie atbalsta pienākumi.
4. Jāizvērtē riski, kas varētu traucēt izpildīt atbalsta saistības.
5. Jāatlasa kontroles pasākumi ievainojamību pārvaldībai, drošai izstrādei, piegādātāju apliecinājumam, incidentu pārvaldībai, darbības nepārtrauktībai, privātumam un dokumentētai informācijai.
6. Jāizveido Piemērojamības paziņojuma piezīmes, kurās paskaidrots, kāpēc kontroles pasākumi ir piemērojami.
7. Jāpārskata atbalsta periods, ja mainās arhitektūra, piegādātāju atkarības, pakļautība apdraudējumiem vai klientu saistības.

Zenith Controls identificē trīs ar šo tēmu saistītus ISO/IEC 27002:2022 kontroles pasākumus kā šīs pārvaldības problēmas centrālos atskaites punktus: 5.31 Tiesiskās, normatīvās, regulatīvās un līgumiskās prasības, 8.8 Tehnisko ievainojamību pārvaldība un 8.25 Drošas izstrādes dzīves cikls. Tie nav vienīgie iesaistītie kontroles pasākumi, bet tie veido pārvaldības mugurkaulu.

Svarīgākais ir izsekojamība. Produkta atbalsta periodam jābūt izsekojamam no pienākuma līdz riska scenārijam, no riska scenārija līdz atlasītajiem kontroles pasākumiem, no kontroles pasākumiem līdz politikas prasībām un no politikas prasībām līdz pierādījumiem.

Zenith Blueprint, Risku pārvaldības posms, 13. solis, šo izsekojamības disciplīnu apraksta tieši:

“Veiciet regulējumu krustenisko salīdzināšanu: ja konkrēti kontroles pasākumi tiek ieviesti tieši, lai nodrošinātu atbilstību GDPR, NIS2 vai DORA, to var norādīt vai nu Riska reģistrā (kā daļu no riska ietekmes pamatojuma), vai SoA piezīmēs.”

Avots: Zenith Blueprint: Auditoru 30 soļu ceļkarte, Risku pārvaldības posms, 13. solis: Risku apstrādes plānošana un Piemērojamības paziņojums Zenith Blueprint

CRA drošības atbalsta periodam Piemērojamības paziņojumā nevajadzētu tikai norādīt “ievainojamību pārvaldība ir piemērojama”. Tajā jāpaskaidro, ka ievainojamību pārvaldība ir piemērojama tāpēc, ka uzņēmumam ir CRA dzīves cikla saistības, NIS2 drošas izstrādes un piegādes ķēdes gaidas, DORA klientu sākotnējās izpētes prasības, GDPR drošības pienākumi gadījumos, kad tiek apstrādāti personas dati, un līgumiski atbalsta solījumi.

No atbalsta solījuma līdz pārvaldītam dzīves ciklam

Ražotāja noteiktam drošības atbalsta periodam jāiztur seši pārvaldības testi.

Pirmkārt, tam jābūt definētam. Organizācijai nepieciešama standarta taksonomija, piemēram, aktīvs atbalsts, tikai drošības atbalsts, pagarināts atbalsts, ierobežots atbalsts un neatbalstīts statuss. Katram statusam jāizskaidro atjauninājumu pieejamība, ievainojamību apstrāde, komunikācija ar klientiem un eskalācijas ceļi.

Otrkārt, tam jābūt izvērtētam pēc riska. Piecu gadu atbalsts mākoņvidē pārvaldītam SaaS produktam ar kontrolētiem atjaunināšanas kanāliem atšķiras no piecu gadu atbalsta iegultai ierīcei ar lauka ierobežojumiem, trešo pušu mikroshēmu atkarībām un klienta pārvaldītiem ieviešanas logiem.

Treškārt, tam jābūt apstiprinātam. Produktam, drošības funkcijai, juridiskajai funkcijai, privātuma aizsardzības funkcijai, klientu atbalstam un atbildīgajai vadībai jāapstiprina pamatperiods un izņēmumi.

Ceturtkārt, tas ir jākomunicē. Klientiem jāsaprot atbalsta sākuma datums, beigu datums, atjaunināšanas metode, ievainojamību ziņošanas kanāls, trūkumu novēršanas gaidas, atbalsta beigu sekas un pieejamās pagarināšanas iespējas.

Piektkārt, tas ir jāuzrauga. Atkarības mainās. Piegādātāji pārtrauc bibliotēku uzturēšanu. Parādās ievainojamības. Klientu vides mainās. Atbalsta perioda pārvaldībā jāiekļauj komponentu dzīves cikla uzraudzība, piegādātāju pārskatīšana, ievainojamību plūsmas, ielāpu žurnāli, laidienu testēšana un incidentos gūtās mācības.

Sestkārt, tam jābūt pierādāmam. Ja auditors, regulators vai regulēts klients pieprasa pierādījumus, organizācijai jāspēj uzrādīt Atbilstības reģistru, produkta atbalsta reģistru, risku izvērtējumus, SoA kartējumu, ievainojamību reģistru, ielāpu ierakstus, piegādātāju pārskatīšanas ierakstus, laidienu apstiprinājumus un klientu paziņojumus.

Clarysec politikas padara to praktiski īstenojamu. Uzņēmuma Tiesiskās un regulatīvās atbilstības politika Tiesiskās un regulatīvās atbilstības politika prasa:

“Visi tiesiskie un regulatīvie pienākumi jākartē pret konkrētām politikām, kontroles pasākumiem un īpašniekiem informācijas drošības pārvaldības sistēmā (IDPS).”

Avots: Tiesiskās un regulatīvās atbilstības politika, Politikas ieviešanas prasības, punkts 6.2.1 Tiesiskās un regulatīvās atbilstības politika

SME gadījumā līdzvērtīga disciplīna sākas ar vienkāršāku reģistru. SME Tiesiskās un regulatīvās atbilstības politika-sme Tiesiskās un regulatīvās atbilstības politika - SME nosaka:

“Ģenerāldirektoram jāuztur vienkāršs, strukturēts Atbilstības reģistrs, kurā uzskaitīts:”

Avots: Tiesiskās un regulatīvās atbilstības politika-sme, Pārvaldības prasības, punkts 5.1.1 Tiesiskās un regulatīvās atbilstības politika - SME

Atbalsta perioda saistībai jābūt iekļautai Atbilstības reģistrā, ja to nosaka tiesību akti, klienta līgums, nozares regulējums vai regulēta pircēja gaidas. Tai nevajadzētu pastāvēt tikai laidiena piezīmēs vai mārketinga tekstos.

Izveidojiet CRA drošības atbalsta periodu reģistru vienā darbnīcā

Iedomājieties SaaS piegādātāju, kas pārdod savienotu analītikas iekārtu ES loģistikas pakalpojumu sniedzējiem un finanšu sektora klientiem. Produkts ietver iegultu aģentu, mākoņa API, mobilo administratora lietotni un vairākas atvērtā pirmkoda bibliotēkas. Pārdošanas komanda vēlas solīt piecu gadu drošības atbalstu katrai būtiskai iekārtas versijai.

Informācijas drošības vadītājs var organizēt mērķētu darbnīcu ar produkta, inženierijas, juridiskās, privātuma aizsardzības un piegādātāju pārvaldības funkcijām.

1. solis: izveidojiet atbalsta periodu reģistru

Izveidojiet vienu rindu katrai produkta versijai un iekļaujiet:

• produktu un versiju;
• laidiena datumu;
• atbalsta sākuma datumu;
• standarta drošības atbalsta beigu datumu;
• pagarinātā atbalsta iespēju;
• atjauninājumu piegādes metodi;
• ievainojamību izpaušanas kanālu;
• kritiskā ielāpa mērķtermiņu;
• datu apstrādes lomu, piemēram, pārzinis, apstrādātājs vai abi;
• kritiskos piegādātājus un komponentus;
• ietekmētos klientu sektorus;
• riska īpašnieku;
• apstiprināšanas datumu;
• pierādījumu atrašanās vietu.

Šis reģistrs kļūst par dokumentētu informāciju IDPS ietvaros. Zenith Blueprint, IDPS pamatu un vadības posms, 6. solis, nosaka dokumentu kontroles gaidas:

“Dokumentiem jābūt pienācīgai identifikācijai (nosaukumam, iespējams, dokumenta numuram vai unikālam identifikatoram, autoram), atbilstošam formātam un pirms izmantošanas jābūt pārskatītiem un apstiprinātiem attiecībā uz piemērotību.”

Avots: Zenith Blueprint: Auditoru 30 soļu ceļkarte, IDPS pamatu un vadības posms, 6. solis: Dokumentēta informācija un IDPS bibliotēkas izveide Zenith Blueprint

Clarysec uzņēmuma PIMS dokumentētās informācijas un pierādījumu pārvaldības politika PIMS dokumentētās informācijas un pierādījumu pārvaldības politika piemēro līdzīgus pierādījumu principus privātuma dokumentācijai:

“[All] Privātuma vadītājam / PIMS vadītājam JĀpiešķir dokumenta identifikators, īpašnieks, versijas numurs, apstiprinājuma statuss, spēkā stāšanās datums un pārskatīšanas datums REG12 pirms PIMS dokumentētās informācijas publicēšanas.”

Avots: PIMS dokumentētās informācijas un pierādījumu pārvaldības politika, Izveide, apstiprināšana, versiju pārvaldība un publicēšana, punkts 4.2.1 PIMS dokumentētās informācijas un pierādījumu pārvaldības politika

Pat ja atbalsta periodu reģistrs pēc noklusējuma nav privātuma dokuments, piemērojama tā pati disciplīna: īpašnieks, versija, apstiprinājums, spēkā stāšanās datums un pārskatīšanas datums.

2. solis: sasaistiet atbalsta solījumus ar riska apstrādi

Katrai produkta versijai izveidojiet riska scenārijus, piemēram:

• atbalstītā versijā tiek atklāta kritiska ievainojamība, bet inženierijas kapacitāte nav pieejama;
• trešās puses komponents kļūst neatbalstīts pirms deklarētā drošības atbalsta perioda beigām;
• piegādātājs maina mitināšanas vietu vai apakšuzņēmēju un ietekmē atjauninājumu piegādi;
• ievainojamība ietekmē personas datus un izraisa privātuma pārkāpuma izvērtēšanu;
• regulēts finanšu klients pieprasa pierādījumus par IKT trešo pušu noturību.

ISO/IEC 27001:2022 6.1.1 līdz 6.1.3 punkti nodrošina plānošanas mehānismu: identificēt riskus, izvērtēt iespējamību un sekas, piešķirt riska īpašniekus, atlasīt riska apstrādes pasākumus, salīdzināt atlasītos kontroles pasākumus ar A pielikumu, sagatavot Piemērojamības paziņojumu un iegūt atlikušā riska apstiprinājumu.

Riskam “neatbalstīts komponents pirms atbalsta beigu datuma” riska ierakstā jāiekļauj ISO/IEC 27002:2022 kontroles pasākumi 5.31, 8.8 un 8.25, kā arī piegādātāju kontroles pasākumi, piemēram, 5.19 Informācijas drošība attiecībās ar piegādātājiem, 5.20 Informācijas drošības noteikšana piegādātāju līgumos, 5.21 Informācijas drošības pārvaldība IKT piegādes ķēdē un 5.22 Piegādātāju pakalpojumu uzraudzība, pārskatīšana un izmaiņu pārvaldība.

3. solis: nosakiet ievainojamību un ielāpu pierādījumu prasības

Atbalsta periods ir ticams tikai tad, ja ievainojamību pārvaldība šajā periodā darbojas.

SME Ievainojamību un ielāpu pārvaldības politika-sme Ievainojamību un ielāpu pārvaldības politika - SME nosaka stingru prasību steidzamai pakļautībai riskam:

“Kritiskie ielāpi jāuzstāda 3 dienu laikā pēc laidiena, īpaši internetam pieejamām sistēmām.”

Avots: Ievainojamību un ielāpu pārvaldības politika-sme, Politikas ieviešanas prasības, punkts 6.1.1 Ievainojamību un ielāpu pārvaldības politika - SME

Tā prasa arī auditam gatavus ierakstus:

“Jāuztur ielāpu žurnāls, un tas jāpārskata auditu un incidentu reaģēšanas darbību laikā.”

Avots: Ievainojamību un ielāpu pārvaldības politika-sme, Pārvaldības prasības, punkts 5.4.1 Ievainojamību un ielāpu pārvaldības politika - SME

Uzņēmuma vidēs uzņēmuma Ievainojamību un ielāpu pārvaldības politika Ievainojamību un ielāpu pārvaldības politika prasa:

“Drošības operāciju komandai jāuztur centralizēts ievainojamību pārvaldības reģistrs, un informācijas drošības vadītājam vai deleģētai pilnvarotajai personai tas jāpārskata reizi mēnesī.”

Avots: Ievainojamību un ielāpu pārvaldības politika, Pārvaldības prasības, punkts 5.1 Ievainojamību un ielāpu pārvaldības politika

Zenith Blueprint, Kontroles pasākumi praksē posms, 19. solis, skaidro operacionālās gaidas aiz ISO/IEC 27002:2022 kontroles pasākuma 8.8:

“Sekojiet informācijai par jaunām drošības kļūdām (izmantojot piegādātāju brīdinājumus, CVE plūsmas u. c.) attiecībā uz jūsu programmatūru un aparatūru. Izvērtējiet, kuras ir būtiskas (vai mēs izmantojam šo programmatūru? cik kritiska ir kļūda?) un nekavējoties piemērojiet labojumus vai mazināšanas pasākumus.”

Avots: Zenith Blueprint: Auditoru 30 soļu ceļkarte, Kontroles pasākumi praksē posms, 19. solis: Tehnoloģiskie kontroles pasākumi I Zenith Blueprint

Katrai atbalstītai produkta versijai nepieciešama ievainojamību pierādījumu ķēde: ziņojumu pieņemšana, būtiskuma analīze, smaguma pakāpe, ietekmētās versijas, trūkumu novēršanas plāns, labojuma laidiens, mazināšanas norādījumi, komunikācija ar klientiem un slēgšanas apstiprinājums.

4. solis: sasaistiet drošu izstrādi ar atbalsta ilgumu

Drošības atbalsts sākas pirms laidiena. Tas ir atkarīgs no izstrādes praksēm, kas padara produktu uzturamu.

SME Drošas izstrādes politika-sme Drošas izstrādes politika - SME nosaka:

“Komponenti regulāri jāatjaunina, kad tiek izlaisti drošības ielāpi. Ja tiek identificēta kritiska ievainojamība, komponents nekavējoties jāatjaunina vai jāaizstāj.”

Avots: Drošas izstrādes politika-sme, Politikas ieviešanas prasības, punkts 6.6.3 Drošas izstrādes politika - SME

SME Lietojumprogrammu drošības prasību politika-sme Lietojumprogrammu drošības prasību politika - SME prasa, lai līgumos un prasībās:

“tiktu noteikti pienākumi attiecībā uz ievainojamību izpaušanu, reaģēšanas termiņiem un ielāpu uzstādīšanu.”

Avots: Lietojumprogrammu drošības prasību politika-sme, Pārvaldības prasības, punkts 5.3.2 Lietojumprogrammu drošības prasību politika - SME

Ja uzņēmums sola atbalstu līdz 2031. gadam, arhitektūrai jāatbalsta uzturami atjauninājumi, atkarību aizstāšana, droši būvēšanas konveijeri, regresijas testēšana un ārkārtas laidieni. ISO/IEC 27002:2022 kontroles pasākumi drošai izstrādei, drošai arhitektūrai, drošai kodēšanai, drošības testēšanai, ārpakalpojuma izstrādei, vides nodalīšanai un izmaiņu pārvaldībai kļūst par atbalsta perioda nodrošinātājiem.

Viena pierādījumu kopa CRA, NIS2, DORA un GDPR vajadzībām

Tie paši atbalsta perioda pierādījumi var apmierināt dažādas regulatīvās sarunas, taču katrs ietvars jautājumu uzdod citādi.

Piegādātāju atkarība bieži ir vieta, kur atbalsta saistības neizdodas. Uzņēmuma Piegādātāju atkarības risku pārvaldības politika Piegādātāju atkarības risku pārvaldības politika prasa:

“Piegādātāju atkarību reģistrs: Piegādātāju pārvaldības birojam jāuztur aktuāls visu kritisko piegādātāju reģistrs, ietverot tādu informāciju kā sniegtie pakalpojumi/produkti; vai piegādātājs ir vienīgais piegādes avots; pieejamie alternatīvie piegādātāji vai aizstājamība; pašreizējie līguma noteikumi; un ietekmes novērtējums gadījumam, ja piegādātājs nespētu sniegt pakalpojumu vai tiktu kompromitēts.”

Avots: Piegādātāju atkarības risku pārvaldības politika, Ieviešanas prasības, punkts 6.1 Piegādātāju atkarības risku pārvaldības politika

Zenith Blueprint, Kontroles pasākumi praksē posms, 23. solis, brīdina, ka auditori pārbaudīs piegādātāju līgumus un piegādātāju uzraudzības pierādījumus:

“Auditori pārskatīs līgumu vai pakalpojumu līmeņa vienošanos paraugus. Viņi meklē skaidri noteiktas informācijas drošības klauzulas, piemēram, paziņošanas termiņus pārkāpuma gadījumā, piekļuves ierobežojumus, datu apstrādes pienākumus, šifrēšanas prasības vai audita tiesības.”

Avots: Zenith Blueprint: Auditoru 30 soļu ceļkarte, Kontroles pasākumi praksē posms, 23. solis: Organizatoriskie kontroles pasākumi Zenith Blueprint

DORA klientiem tas ir kritiski. IKT pakalpojumu līgumiem, kas atbalsta kritiskas vai svarīgas funkcijas, nepieciešami skaidri pakalpojumu apraksti, apakšuzņēmēju izmantošanas nosacījumi, drošības pasākumi, palīdzība incidentu gadījumā, audita un pārbaudes tiesības, izbeigšanas tiesības un pārejas kārtība. Piegādātājs, kas nespēj atbalstīt šīs saistības, var liegt ražotājam sniegt ticamu atbalsta perioda solījumu.

Kontroles atbilstības kartējums auditam gatavai atbalsta perioda pārvaldībai

Šis atbilstības kartējums ļauj drošības, juridiskajām, produkta un pārdošanas komandām runāt vienā valodā. Atbalsta periodu reģistrs nav tikai CRA pierādījums. Tas ir piegādātāju apliecinājums NIS2 vajadzībām, trešo pušu apliecinājums DORA vajadzībām, atbalsts GDPR apstrādes drošībai un pārvaldības artefakts ISO 27001 sertifikācijai.

Privātuma aspekts: kad neatbalstīts kļūst nedrošs

Drošības atbalsta perioda pārvaldība nav tikai kiberdrošības jautājums. Ja produkts glabā, pārraida vai apstrādā personas datus, neatbalstīta programmatūra var kļūt par privātuma risku.

GDPR attiecas uz apstrādi ES uzņēmējdarbības vietas kontekstā un var attiekties arī uz ārpus ES esošām organizācijām, kas piedāvā preces vai pakalpojumus fiziskām personām ES vai uzrauga to uzvedību. Tas plaši definē personas datus un personas datu aizsardzības pārkāpumu uzskata par drošības pārkāpumu, kas izraisa apstrādāto personas datu nejaušu vai nelikumīgu iznīcināšanu, nozaudēšanu, pārveidošanu, nesankcionētu izpaušanu vai piekļuvi tiem.

Atbalsta perioda pārvaldībai privātuma komandām jāzina, kuras produkta versijas apstrādā PII, kuras sistēmas joprojām tiek atbalstītas un vai ievainojamības ietekmē personas datu konfidencialitāti, integritāti vai pieejamību.

Clarysec uzņēmuma PII drošības piekļuves kontroles politika PII drošības piekļuves kontroles politika prasa:

“[Both] Sistēmas īpašniekam / Lietotnes īpašniekam vismaz reizi ceturksnī un pēc būtiskas tehniskas izmaiņas REG12 jāreģistrē ievainojamību izvērtēšanas pārklājums sistēmām, kas apstrādā PII.”

Avots: PII drošības piekļuves kontroles politika, Droša konfigurācija un ievainojamību pārvaldība, punkts 4.7.4 PII drošības piekļuves kontroles politika

Uzņēmuma Apstrādātāju, apakšapstrādātāju un trešo pušu privātuma pārvaldības politika Apstrādātāju, apakšapstrādātāju un trešo pušu privātuma pārvaldības politika pievieno pastāvīgu uzraudzību augsta riska privātuma attiecībām:

“[All] Piegādātāja / iepirkuma īpašniekam reizi ceturksnī jāuzrauga aktīvās augsta riska apstrādātāju un apakšapstrādātāju attiecības un reizi gadā citas aktīvās PII apstrādātāju un apakšapstrādātāju attiecības, salīdzinot tās ar sākotnējās izpētes nosacījumiem, līguma statusu, apliecinājuma statusu, atvērtajām problēmām un pārskatīšanas datumiem REG08.”

Avots: Apstrādātāju, apakšapstrādātāju un trešo pušu privātuma pārvaldības politika, Pastāvīga uzraudzība, palīdzība, izpaušanas saskarne un izstāšanās, punkts 4.5.1 Apstrādātāju, apakšapstrādātāju un trešo pušu privātuma pārvaldības politika

Kad ievainojamība kļūst par incidentu, uzņēmuma PII incidentu un personas datu aizsardzības pārkāpumu pārvaldības politika PII incidentu un personas datu aizsardzības pārkāpumu pārvaldības politika prasa vairāku ietvaru trigeru izvērtēšanu:

“[Conditional] Privātuma vadītājam / PIMS vadītājam jāizvērtē piemērojamie tiesiskie, nozaru, finanšu sektora, kiberdrošības, līgumiskie, klientu un pakalpojumu saņēmēju ziņošanas trigeri katram augstas ietekmes personas datu incidentam un jāreģistrē piemērojamības rezultāts REG01, REG08 un REG10.”

Avots: PII incidentu un personas datu aizsardzības pārkāpumu pārvaldības politika, Klasifikācija un pārkāpuma izvērtēšana, punkts 4.2.6 PII incidentu un personas datu aizsardzības pārkāpumu pārvaldības politika

Šī ir praktiskā pārklāšanās starp CRA atbalsta saistībām, NIS2 incidentu komunikāciju, DORA būtisku IKT incidentu apstrādi un GDPR pārkāpumu pārskatatbildību.

Kā auditori testē vienu un to pašu atbalsta perioda procesu

Spēcīgam atbalsta perioda pārvaldības procesam jāiztur dažādi audita stili. Pierādījumi būtiski nemainās, bet mainās auditora skatpunkts.

NIST CSF 2.0 ir noderīgs kā komunikācijas slānis, jo tā GOVERN funkcija ietver tiesiskos, regulatīvos, līgumiskos un privātuma pienākumus, risku pārvaldības mērķus, riska apetīti, lomas, politikas un pārraudzību. Tā piegādes ķēdes rezultāti aptver piegādātāju stratēģiju, kritiskumu, līgumus, sākotnējo izpēti, uzraudzību, incidentu koordināciju un attiecību izbeigšanas noteikumus.

COBIT un ISACA tipa auditori bieži koncentrējas uz pārvaldības dizainu: kam pieder lēmums, kāds process ir definēts, kādi rādītāji parāda sniegumu, kā tiek apstiprināti izņēmumi un kā tiek īstenota nepārtraukta uzlabošana.

Clarysec uzņēmuma Informācijas drošības politika Informācijas drošības politika ietver auditējamības principu:

“Visiem ieviestajiem kontroles pasākumiem jābūt auditējamiem, atbalstītiem ar dokumentētām procedūrām un glabātiem darbības pierādījumiem.”

Avots: Informācijas drošības politika, Politikas ieviešanas prasības, punkts 6.6.1 Informācijas drošības politika

Šis ir teikums, kuram jāspēj atbilst katram drošības atbalsta periodam.

Pagariniet, saīsiniet vai izbeidziet atbalstu, neradot maldinošu apliecinājumu

Sarežģītākie pārvaldības brīži nav produkta palaišanas brīdī. Tie rodas, kad mainās realitāte.

Jums var būt jāpaplašina atbalsts, jo no produkta ir atkarīgi regulēti klienti, migrācija nav iespējama vai nozares klientam ir līgumiskas nepārtrauktības vajadzības. Jums var būt jāsaīsina vai jāierobežo atbalsts, jo piegādātājs pārtrauc drošības uzturēšanu, komponentu nav iespējams ielāpīt, platforma sasniedz tehniskās robežas vai produkta arhitektūra nevar droši atbalstīt noteiktu ievainojamību klasi.

Kontrolētai atbalsta perioda izmaiņai jāietver:

• izmaiņu trigeris, piemēram, piegādātāja dzīves cikla beigas, kritiska ievainojamība, klienta līgums vai regulatīvas izmaiņas;
• ietekmētie produkti, versijas, klienti un sektori;
• personas datu un kritisko pakalpojumu ietekmes analīze;
• piegādātāja un komponenta īstenojamības pārskatīšana;
• risku izvērtēšana un atlikušā riska lēmums;
• atjaunināts atbalsta periodu reģistrs;
• atjaunināts klientu paziņojums un līgumiskā pozīcija;
• atjauninātas SoA piezīmes, ja mainās kontroles pasākumi vai pienākumi;
• vadības apstiprinājums un pārskatīšanas datums.

Uzņēmuma Koordinētas ievainojamību izpaušanas politika Koordinētas ievainojamību izpaušanas politika ir noderīga, ja izmaiņas izraisa ievainojamība:

“Visām apstiprinātajām ievainojamībām jāizstrādā trūkumu novēršanas vai mazināšanas plāns. Labojuma ieviešana jāprioritizē pēc smaguma pakāpes. Piemēram, kritiskās ievainojamības, ja iespējams, jānovērš vai jāmazina 14 dienu laikā vai ātrāk, ja tiek konstatēta aktīva izmantošana, savukārt zemākas smaguma pakāpes problēmas jārisina saprātīgā termiņā.”

Avots: Koordinētas ievainojamību izpaušanas politika, Ieviešanas prasības, punkts 6.6 Koordinētas ievainojamību izpaušanas politika

Ja pilnu labojumu nevar piegādāt nekavējoties, kompensējošie kontroles pasākumi, atspējota funkcionalitāte, pastiprināta uzraudzība vai klienta konfigurācijas norādījumi var būt pieņemami uz laiku, taču lēmums ir jādokumentē un jākomunicē.

Praktisks Clarysec kontrolsaraksts gatavībai atbalsta periodam

Izmantojiet šo kontrolsarakstu pirms jebkuras CRA drošības atbalsta perioda saistības publicēšanas vai atjaunošanas.

• Vai produkts un versija ir iekļauti atbalsta periodu reģistrā?
• Vai atbalsta beigu datumu ir apstiprinājis produkts, drošības funkcija un atbildīgā vadība?
• Vai tiesiskie, regulatīvie un līgumiskie pamatojumi ir kartēti Atbilstības reģistrā?
• Vai atbalsta perioda riska scenārijs ir iekļauts riska reģistrā?
• Vai kontroles pasākumi ir kartēti Piemērojamības paziņojumā, tostarp 5.31, 8.8 un 8.25, ja tie ir piemērojami?
• Vai kritiskie piegādātāji un komponenti ir kartēti piegādātāju atkarību reģistrā?
• Vai ir pierādījumi, ka komponentus atbalsta perioda laikā var ielāpīt vai aizstāt?
• Vai ir definētas atbildības par ievainojamību ziņojumu pieņemšanu, triāžu, trūkumu novēršanu un izpaušanu?
• Vai kritisko ielāpu SLA ir saskaņoti ar politiku un klientu līgumiem?
• Vai tiek glabāti ielāpu žurnāli, laidienu ieraksti un lēmumi par ievainojamībām?
• Vai personas datu sistēmām ir ievainojamību izvērtēšanas pierādījumi, ja tiek apstrādāti PII?
• Vai klientu paziņojumi, atbalsta paziņojumi un līguma noteikumi ir konsekventi?
• Vai pastāv process atbalsta pagarināšanai, saīsināšanai vai izbeigšanai ar riska apstiprinājumu?
• Vai vadības pārskatīšanā tiek saņemta ievade par atbalsta perioda riskiem, piegādātājiem, ievainojamībām un incidentiem?
• Vai pierādījumus var sagatavot 48 stundu laikā klienta auditam vai regulatora pieprasījumam?

Uzņēmuma PIMS uzraudzības, audita un uzlabošanas politika PIMS uzraudzības, audita un uzlabošanas politika pastiprina vadības pārskatīšanas disciplīnu privātuma programmām:

“[Both] Augstākajai vadībai katras vadības pārskatīšanas laikā REG12 jāpārskata PIMS neatbilstību, korektīvo darbību, uzraudzības rezultātu, audita rezultātu, privātuma risku, piegādātāju apliecinājuma un ieinteresēto pušu izmaiņu ievades.”

Avots: PIMS uzraudzības, audita un uzlabošanas politika, PIMS vadības pārskatīšana, punkts 4.3.5 PIMS uzraudzības, audita un uzlabošanas politika

Drošības atbalsta perioda pārvaldībai tāds pats pārskatīšanas ritms jāpiemēro visā IDPS: ievainojamībām, ielāpu veiktspējai, piegādātāju apliecinājumam, klientu saistībām, incidentiem, atbalsta izņēmumiem un korektīvajām darbībām jānonāk vadības pārskatīšanā.

Padariet drošības atbalsta periodu aizstāvamu

ES Kibernoturības akts maina produkta drošības domāšanu. Tas mudina ražotājus un programmatūras nodrošinātājus domāt tālāk par laidiena dienu. Drošības atbalsta periods kļūst par dzīves cikla solījumu, kas jāinženierē, jāpārvalda, jāuzrauga un jāpierāda.

Informācijas drošības vadītājiem mācība ir skaidra: neļaujiet atbalsta periodam palikt tikai produkta mārketingā. Atbilstības vadītājiem — neveidojiet atsevišķu CRA pierādījumu silosu. Auditoriem — pārbaudiet, vai atbalsta saistības ir izsekojamas līdz riskam, kontroles pasākumiem, piegādātājiem, incidentiem un dokumentētiem apstiprinājumiem. Uzņēmuma īpašniekiem — atcerieties, ka ticams atbalsta periods var kļūt par tirgus priekšrocību, īpaši pārdodot NIS2 regulētiem sektoriem, DORA finanšu vienībām un privātuma ziņā jutīgiem klientiem.

Clarysec palīdz organizācijām to operacionalizēt, izmantojot:

• Zenith Blueprint: Auditoru 30 soļu ceļkarte Zenith Blueprint IDPS izsekojamības, dokumentētas informācijas, SoA kartējuma un gatavības auditam izveidei;
• Zenith Controls: Savstarpējās atbilstības ceļvedis Zenith Controls ISO/IEC 27002:2022 kontroles pasākumu kartēšanai pret NIS2, DORA, GDPR, NIST CSF 2.0 un audita gaidām;
• uzņēmuma un SME politiku pakotnes ievainojamību pārvaldībai, drošai izstrādei, tiesiskajai atbilstībai, piegādātāju atkarībām, privātuma pierādījumiem un reaģēšanai uz incidentiem;
• praktiskus reģistrus un pierādījumu darbplūsmas, kas atbalsta perioda solījumus pārvērš auditējamā pārvaldībā.

Jūsu nākamais solis ir vienkāršs: izvēlieties vienu vadošā produkta versiju un izveidojiet tās drošības atbalsta perioda pierādījumu lietu. Kartējiet pienākumu, apstipriniet atbalsta periodu, testējiet ievainojamību procesu, validējiet piegādātāju atkarības, apstipriniet komunikāciju ar klientiem un saglabājiet ierakstus.

Ja varat aizstāvēt vienu produktu, varat mērogot modeli. Ja nevarat aizstāvēt vienu produktu, nepilnība nav dokumentācijā. Tā ir pārvaldībā.

Lejupielādējiet Zenith Blueprint, izmantojiet Zenith Controls savu pierādījumu kartēšanai vai pieprasiet Clarysec gatavības izvērtēšanu, lai CRA drošības atbalsta periodus pārvērstu auditam gatavā ISO 27001 pārvaldībā.