Obdobja varnostne podpore po EU CRA z ISO 27001

Torek je, ura je 08:20, lastnik izdelka za povezani prehod B2B pa prejme sporočilo regulirane stranke: “Prosimo, potrdite obdobje varnostne podpore za različico vdelane programske opreme 4.6, SLA za odziv na ranljivosti in ali bo naprava v času naše petletne pogodbe o storitvah še naprej upravičena do varnostnih posodobitev.”

Do 09:00 nabava posreduje vprašalnik za skrbni pregled po DORA. Ob 10:15 pravna služba vpraša, ali je oglaševano obdobje podpore skladno s pogodbami s strankami. Ob 11:00 je vodja informacijske varnosti vključen v pregled tveganj dobaviteljev po NIS2, ker izdelek v EU uporablja ponudnik upravljanih storitev. Po kosilu ekipa za zasebnost vpraša, ali bi nepodprta knjižnica API v izdelku lahko vplivala na varnost osebnih podatkov po GDPR.

Neprijetna resnica se pokaže hitro. Podjetje ima časovni načrt, proces uvajanja popravkov, koledar izdaj in portal za podporo strankam, nima pa upravljanih dokazil o obdobju varnostne podpore.

Ta vrzel je pomembna. V okviru EU Cyber Resilience Act obdobje varnostne podpore ni samo oznaka izdelka. Gre za zavezo življenjskega cikla, ki vpliva na obravnavo ranljivosti, razpoložljivost posodobitev, upravljanje odvisnosti od dobaviteljev, komuniciranje s strankami, pogodbene izjave in spremljanje po dajanju na trg. Za ponudnike SaaS, proizvajalce naprav, izdajatelje programske opreme, ponudnike storitev v oblaku in ponudnike storitev IKT obdobje podpore postane predmet skladnosti, ki ga bodo presojevalci in regulirani kupci preverjali.

Praktični odgovor ni še ena nepovezana preglednica za skladnost. Odgovor je upravljanje obdobja varnostne podpore znotraj sistema upravljanja informacijske varnosti ISO/IEC 27001:2022, nato pa preslikava istih dokazil na pričakovanja NIS2, DORA, GDPR, NIST CSF 2.0 in presoje po pristopu COBIT.

To je operativni model Clarysec: uporabite ISMS kot mehanizem za dokazila, uporabite izvršljive politike za opredelitev odgovornosti, uporabite Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za vzpostavitev sledljivosti in uporabite Zenith Controls: The Cross-Compliance Guide Zenith Controls kot kompas za skladnost med okviri.

Zakaj je obdobje varnostne podpore zdaj predmet presoje

Obdobje varnostne podpore odgovarja na preprosto vprašanje: kako dolgo bo proizvajalec za izdelek ali različico izdelka zagotavljal varnostne posodobitve, odpravo ranljivosti, navodila za ublažitev in povezano podporo strankam?

V praksi je ta odgovor odvisen od številnih dejavnikov:

• arhitekture izdelka in njegove vzdržljivosti,
• podpore komponent tretjih oseb in odprtokodnih odvisnosti,
• zavez dobaviteljev in ponudnikov storitev v oblaku,
• procesov za sprejem prijav ranljivosti, triažo, odpravo in razkritje,
• zmogljivosti inženiringa izdaj in testiranja,
• pogodbenih pogojev s strankami in regulativnih obveznosti,
• poti za odziv na incidente in obveščanje prejemnikov storitev,
• hrambe dokazil in zapisov o odobritvah.

Če proizvajalec obljubi pet let varnostne podpore, kritična kriptografska knjižnica pa po treh letih izgubi podporo, obdobje podpore postane odločitev o tveganju. Če je stranka finančni subjekt, zavezan DORA, isto obdobje podpore postane del zagotovil tretjih ponudnikov storitev IKT. Če izdelek obdeluje osebne podatke, lahko nepodprta programska oprema postane del odgovornosti za varnost obdelave po GDPR. Če izdelek podpira bistveni ali pomembni subjekt po NIS2, varnost življenjskega cikla postane vprašanje varnosti dobavne verige.

NIS2 ta vidik upravljanja izrecno poudarja. Article 20 zahteva, da upravljalni organi bistvenih in pomembnih subjektov odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirajo njihovo izvajanje in se usposabljajo. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganja, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, varno nabavo, varnim razvojem in vzdrževanjem, obravnavo in razkrivanjem ranljivosti, oceno učinkovitosti, kibernetsko higieno, kriptografijo, nadzorom dostopa, upravljanjem sredstev in avtentikacijo. Article 23 dodaja obveznosti postopnega poročanja o pomembnih incidentih.

DORA ustvarja podoben pritisk za finančne subjekte. Zahteva upravljanje tveganj IKT, testiranje digitalne operativne odpornosti, upravljanje incidentov in upravljanje tveganj tretjih ponudnikov storitev IKT. DORA Article 28 obravnava načela upravljanja tveganj tretjih ponudnikov storitev IKT, Article 30 pa zahteva pisne pogodbene dogovore z jasnimi opisi storitev, varnostnimi ukrepi, podporo pri incidentih, pravicami do revizije, pravicami do odpovedi in izhodnimi ureditvami.

GDPR dodaja plast zasebnosti. Če izdelek obdeluje osebne podatke, upravljavci in obdelovalci potrebujejo ustrezne tehnične in organizacijske ukrepe po Article 32, pogodbeno jasnost po Article 28 ter pripravljenost na oceno kršitve in obveščanje po Articles 33 in 34.

Zato je treba obdobje varnostne podpore po CRA upravljati kot družino kontrol ISMS, ne kot izolirano polje upravljanja izdelka.

ISO 27001 kot kontrolni okvir za obdobja varnostne podpore po CRA

ISO/IEC 27001:2022 je koristen, ker je razširljiv, temelji na tveganjih in je usmerjen v sistem upravljanja. Od organizacije zahteva, da opredeli kontekst, zainteresirane strani, obseg in medsebojno delujoče procese, nato pa zakonske, regulativne in pogodbene zahteve prevede v oceno tveganja, obravnavo tveganja, operativne kontrole in dokazila ISO/IEC 27001:2022.

Za upravljanje obdobja varnostne podpore to pomeni, da mora organizacija:

1. opredeliti izdelke, različice, module, storitve v oblaku in odvisnosti v obsegu;
2. opredeliti zainteresirane strani, vključno s strankami, regulatorji, distributerji, uvozniki, integratorji, obdelovalci, podobdelovalci, partnerji za odziv na incidente in dobavitelji;
3. evidentirati zakonske, regulativne in pogodbene obveznosti podpore;
4. oceniti tveganja, ki bi lahko preprečila izpolnitev zavez glede podpore;
5. izbrati kontrole za upravljanje ranljivosti, varen razvoj, zagotavljanje zaupanja v dobavitelje, upravljanje incidentov, neprekinjeno poslovanje, zasebnost in dokumentirane informacije;
6. pripraviti opombe k izjavi o uporabnosti, ki pojasnijo, zakaj se kontrole uporabljajo;
7. pregledati obdobje podpore ob spremembah arhitekture, odvisnosti od dobaviteljev, izpostavljenosti grožnjam ali zavez strankam.

Zenith Controls kot osrednje referenčne točke za ta problem upravljanja določa tri povezane kontrole ISO/IEC 27002:2022: 5.31 Zakonske, statutarne, regulativne in pogodbene zahteve, 8.8 Upravljanje tehničnih ranljivosti in 8.25 Življenjski cikel varnega razvoja. To niso edine vključene kontrole, so pa hrbtenica upravljanja.

Ključna je sledljivost. Obdobje podpore izdelka mora biti sledljivo od obveznosti do scenarija tveganja, od scenarija tveganja do izbranih kontrol, od kontrol do zahtev politike in od zahtev politike do dokazil.

Zenith Blueprint, faza obvladovanja tveganj, Step 13, to disciplino sledljivosti opiše neposredno:

“Navzkrižno sklicevanje predpisov: Če so določene kontrole uvedene posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to navedete v registru tveganj (kot del utemeljitve vpliva tveganja) ali v opombah SoA.”

Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza obvladovanja tveganj, Step 13: načrtovanje obravnave tveganja in izjava o uporabnosti Zenith Blueprint

Za obdobje varnostne podpore po CRA izjava o uporabnosti ne sme zgolj navesti, da se “upravljanje ranljivosti uporablja”. Pojasniti mora, da se upravljanje ranljivosti uporablja zato, ker ima podjetje zaveze življenjskega cikla po CRA, pričakovanja NIS2 glede varnega razvoja in dobavne verige, zahteve strank po skrbnem pregledu po DORA, varnostne obveznosti po GDPR, kadar se obdelujejo osebni podatki, ter pogodbene obljube podpore.

Od obljube podpore do upravljanega življenjskega cikla

Obdobje varnostne podpore, ki ga določi proizvajalec, mora prestati šest preizkusov upravljanja.

Prvič, mora biti opredeljeno. Organizacija potrebuje standardno taksonomijo, kot so aktivna podpora, samo varnostna podpora, razširjena podpora, omejena podpora in brez podpore. Vsak status mora pojasniti razpoložljivost posodobitev, obravnavo ranljivosti, komunikacijo s strankami in eskalacijske poti.

Drugič, mora biti predmet ocene tveganja. Pet let podpore za izdelek SaaS, upravljan v oblaku z nadzorovanimi kanali posodobitev, se razlikuje od petih let podpore za vdelano napravo z omejitvami na terenu, odvisnostmi od čipov tretjih oseb in okni uvedbe, ki jih upravlja stranka.

Tretjič, mora biti odobreno. Osnovno obdobje in izjeme morajo odobriti produktna, varnostna, pravna in zasebnostna funkcija, podpora strankam ter odgovorno vodstvo.

Četrtič, mora biti sporočeno. Stranke morajo razumeti datum začetka podpore, končni datum, način posodobitve, kanal za poročanje o ranljivostih, pričakovanja glede odprave, posledice konca podpore in razpoložljive možnosti podaljšanja.

Petič, mora biti spremljano. Odvisnosti se spreminjajo. Dobavitelji ukinjajo knjižnice. Pojavljajo se ranljivosti. Okolja strank se spreminjajo. Upravljanje obdobja podpore mora vključevati spremljanje življenjskega cikla komponent, pregled dobaviteljev, vire ranljivosti, evidence popravkov, testiranje izdaj in pridobljene izkušnje iz incidentov.

Šestič, mora biti dokazljivo. Če presojevalec, regulator ali regulirana stranka zahteva dokazila, mora organizacija pokazati evidenco skladnosti, register podpore izdelkov, oceno tveganja, preslikavo SoA, register ranljivosti, zapise o popravkih, preglede dobaviteljev, odobritve izdaj in obvestila strankam.

Politike Clarysec to naredijo izvedljivo. Podjetniška Politika pravne in regulativne skladnosti Politika pravne in regulativne skladnosti zahteva:

“Vse zakonske in regulativne obveznosti morajo biti preslikane na konkretne politike, kontrole in lastnike znotraj sistema upravljanja informacijske varnosti (ISMS).”

Vir: Politika pravne in regulativne skladnosti, zahteve za izvajanje politike, klavzula 6.2.1 Politika pravne in regulativne skladnosti

Za MSP se enakovredna disciplina začne s preprostejšo evidenco. Politika pravne in regulativne skladnosti za MSP Politika pravne in regulativne skladnosti - MSP določa:

“Generalni direktor mora vzdrževati preprosto, strukturirano evidenco skladnosti, ki vključuje:”

Vir: Politika pravne in regulativne skladnosti za MSP, zahteve upravljanja, klavzula 5.1.1 Politika pravne in regulativne skladnosti - MSP

Zaveza glede obdobja podpore mora biti v evidenci skladnosti, če izhaja iz zakonodaje, pogodbe s stranko, sektorske regulative ali pričakovanj reguliranega kupca. Ne sme obstajati samo v opombah ob izdaji ali trženjskem besedilu.

Register obdobij varnostne podpore po CRA vzpostavite v eni delavnici

Predstavljajte si ponudnika SaaS, ki povezano analitično napravo prodaja logističnim ponudnikom v EU in strankam iz finančnega sektorja. Izdelek vključuje vdelanega agenta, API v oblaku, mobilno administratorsko aplikacijo in več odprtokodnih knjižnic. Prodaja želi za vsako večjo različico naprave obljubiti pet let varnostne podpore.

Vodja informacijske varnosti lahko izvede osredotočeno delavnico s produktno, inženirsko, pravno in zasebnostno funkcijo ter upravljanjem dobaviteljev.

Step 1: Ustvarite register obdobij podpore

Ustvarite eno vrstico za vsako različico izdelka in vključite:

• izdelek in različico,
• datum izdaje,
• datum začetka podpore,
• standardni končni datum varnostne podpore,
• možnost razširjene podpore,
• način dostave posodobitev,
• kanal za razkritje ranljivosti,
• cilj za kritični popravek,
• vlogo pri obdelavi podatkov, kot je upravljavec, obdelovalec ali oboje,
• kritične dobavitelje in komponente,
• prizadete sektorje strank,
• lastnika tveganja,
• datum odobritve,
• lokacijo dokazil.

Ta register postane dokumentirana informacija v okviru ISMS. Zenith Blueprint, faza vzpostavitve ISMS in voditeljstva, Step 6, podaja pričakovanje glede nadzora dokumentov:

“Dokumenti morajo imeti ustrezno identifikacijo (naslov, morda številko dokumenta ali enolični identifikator, avtorja), ustrezen format ter pregled in odobritev ustreznosti pred uporabo.”

Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza vzpostavitve ISMS in voditeljstva, Step 6: dokumentirane informacije in vzpostavitev knjižnice ISMS Zenith Blueprint

Podjetniška Politika upravljanja dokumentiranih informacij in dokazil PIMS Politika upravljanja dokumentiranih informacij in dokazil PIMS uporablja podobna načela dokazil za dokumentacijo zasebnosti:

“[Vsi] Vodja zasebnosti / vodja PIMS MORA pred objavo dokumentiranih informacij PIMS v REG12 dodeliti identifikator dokumenta, lastnika, številko različice, status odobritve, datum začetka veljavnosti in datum pregleda.”

Vir: Politika upravljanja dokumentiranih informacij in dokazil PIMS, ustvarjanje, odobritev, upravljanje različic in objava, klavzula 4.2.1 Politika upravljanja dokumentiranih informacij in dokazil PIMS

Tudi če register obdobij podpore privzeto ni dokument zasebnosti, velja ista disciplina: lastnik, različica, odobritev, datum začetka veljavnosti in datum pregleda.

Step 2: Zaveze glede podpore povežite z obravnavo tveganja

Za vsako različico izdelka ustvarite scenarije tveganj, kot so:

• v podprti različici je odkrita kritična ranljivost, vendar inženirske zmogljivosti niso na voljo;
• komponenta tretje osebe izgubi podporo pred koncem razglašenega obdobja varnostne podpore;
• dobavitelj spremeni lokacijo gostovanja ali podizvajalca in vpliva na dostavo posodobitev;
• ranljivost vpliva na osebne podatke in sproži oceno kršitve zasebnosti;
• regulirana finančna stranka zahteva dokazila o odpornosti tretjih ponudnikov storitev IKT.

Klavzule ISO/IEC 27001:2022 6.1.1 do 6.1.3 zagotavljajo načrtovalni mehanizem: opredelitev tveganj, oceno verjetnosti in posledic, določitev lastnikov tveganj, izbiro obravnav, primerjavo izbranih kontrol s Prilogo A, pripravo izjave o uporabnosti in pridobitev odobritve preostalega tveganja.

Za tveganje “nepodprta komponenta pred končnim datumom podpore” mora zapis tveganja vključevati kontrole ISO/IEC 27002:2022 5.31, 8.8 in 8.25 ter kontrole dobaviteljev, kot so 5.19 Informacijska varnost v razmerjih z dobavitelji, 5.20 Obravnavanje informacijske varnosti v dogovorih z dobavitelji, 5.21 Upravljanje informacijske varnosti v dobavni verigi IKT in 5.22 Spremljanje, pregledovanje in upravljanje sprememb storitev dobaviteljev.

Step 3: Določite pravila za dokazila o ranljivostih in popravkih

Obdobje podpore je verodostojno samo, če upravljanje ranljivosti v tem obdobju deluje.

Politika upravljanja ranljivosti in popravkov za MSP Politika upravljanja ranljivosti in popravkov - MSP določa strogo zahtevo za nujno izpostavljenost:

“Kritične popravke je treba namestiti v 3 dneh od izdaje, zlasti za sisteme, izpostavljene internetu.”

Vir: Politika upravljanja ranljivosti in popravkov za MSP, zahteve za izvajanje politike, klavzula 6.1.1 Politika upravljanja ranljivosti in popravkov - MSP

Zahteva tudi zapise, pripravljene za presojo:

“Vzdrževati je treba evidenco popravkov, ki se pregleda med revizijami in dejavnostmi odzivanja na incidente.”

Vir: Politika upravljanja ranljivosti in popravkov za MSP, zahteve upravljanja, klavzula 5.4.1 Politika upravljanja ranljivosti in popravkov - MSP

Za podjetniška okolja podjetniška Politika upravljanja ranljivosti in popravkov Politika upravljanja ranljivosti in popravkov zahteva:

“Centralizirani register upravljanja ranljivosti mora vzdrževati ekipa za varnostne operacije, mesečno pa ga mora pregledati vodja informacijske varnosti ali pooblaščeni organ.”

Vir: Politika upravljanja ranljivosti in popravkov, zahteve upravljanja, klavzula 5.1 Politika upravljanja ranljivosti in popravkov

Zenith Blueprint, faza kontrol v praksi, Step 19, pojasnjuje operativno pričakovanje za kontrolo ISO/IEC 27002:2022 8.8:

“Bodite obveščeni o novih varnostnih napakah (prek opozoril dobaviteljev, virov CVE itd.) za svojo programsko in strojno opremo. Ocenite, katere so relevantne (ali uporabljamo to programsko opremo? kako kritična je napaka?) ter hitro uporabite popravke ali ukrepe za ublažitev.”

Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza kontrol v praksi, Step 19: tehnološki nadzorni ukrepi I Zenith Blueprint

Vsaka podprta različica izdelka potrebuje sled dokazil o ranljivostih: sprejem prijave, analizo relevantnosti, resnost, prizadete različice, načrt odprave, izdajo popravka, navodila za ublažitev, komunikacijo s strankami in odobritev zaključka.

Step 4: Varen razvoj povežite s trajanjem podpore

Varnostna podpora se začne pred izdajo. Odvisna je od razvojnih praks, zaradi katerih je izdelek mogoče vzdrževati.

Politika varnega razvoja za MSP Politika varnega razvoja - MSP določa:

“Komponente je treba redno posodabljati, ko so izdani varnostni popravki. Če je ugotovljena kritična ranljivost, je treba komponento nemudoma nadgraditi ali zamenjati.”

Vir: Politika varnega razvoja za MSP, zahteve za izvajanje politike, klavzula 6.6.3 Politika varnega razvoja - MSP

Politika zahtev za varnost aplikacij za MSP Politika zahtev za varnost aplikacij - MSP zahteva, da pogodbe in zahteve:

“določajo obveznosti za razkritje ranljivosti, odzivne čase in nameščanje popravkov.”

Vir: Politika zahtev za varnost aplikacij za MSP, zahteve upravljanja, klavzula 5.3.2 Politika zahtev za varnost aplikacij - MSP

Če podjetje obljubi podporo do leta 2031, mora arhitektura podpirati vzdrževalne posodobitve, zamenjavo odvisnosti, varne gradbene cevovode, regresijsko testiranje in nujne izdaje. Kontrole ISO/IEC 27002:2022 za varen razvoj, varno arhitekturo, varno kodiranje, varnostno testiranje, zunanji razvoj, ločevanje okolij in upravljanje sprememb postanejo omogočevalci obdobja podpore.

En nabor dokazil za CRA, NIS2, DORA in GDPR

Ista dokazila o obdobju podpore lahko podprejo različne regulativne pogovore, vendar vsak okvir vprašanje zastavi drugače.

Odvisnost od dobaviteljev je pogosto točka, na kateri zaveze podpore odpovejo. Podjetniška Politika upravljanja tveganj odvisnosti od dobaviteljev Politika upravljanja tveganj odvisnosti od dobaviteljev zahteva:

“Register odvisnosti od dobaviteljev: VMO mora vzdrževati ažuren register vseh kritičnih dobaviteljev, vključno s podatki, kot so zagotovljene storitve/izdelki; ali je dobavitelj en sam vir; razpoložljivi alternativni dobavitelji ali zamenljivost; trenutni pogodbeni pogoji; in ocena vpliva, če bi dobavitelj odpovedal ali bil kompromitiran.”

Vir: Politika upravljanja tveganj odvisnosti od dobaviteljev, zahteve za izvajanje, klavzula 6.1 Politika upravljanja tveganj odvisnosti od dobaviteljev

Zenith Blueprint, faza kontrol v praksi, Step 23, opozarja, da bodo presojevalci pregledali dogovore z dobavitelji in dokazila o spremljanju dobaviteljev:

“Presojevalci bodo pregledali vzorčne pogodbe ali sporazume o storitvah. Iščejo izrecne klavzule o informacijski varnosti, kot so časovni roki za obvestila o kršitvah, omejitve dostopa, obveznosti obdelave podatkov, zahteve glede šifriranja ali pravice do revizije.”

Vir: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza kontrol v praksi, Step 23: organizacijski ukrepi Zenith Blueprint

Za stranke, zavezane DORA, je to kritično. Pogodbe za storitve IKT, ki podpirajo kritične ali pomembne funkcije, potrebujejo jasne opise storitev, pogoje podizvajanja, varnostne ukrepe, pomoč pri incidentih, pravice do revizije in pregleda, pravice do odpovedi ter prehodne ureditve. Dobavitelj, ki teh zavez ne more podpreti, lahko proizvajalcu prepreči verodostojno obljubo obdobja podpore.

Preslikava kontrol za upravljanje obdobja podpore, pripravljeno na presojo

Ta preslikava omogoča, da varnostne, pravne, produktne in prodajne ekipe uporabljajo isti jezik. Register obdobij podpore ni samo dokazilo po CRA. Je zagotovilo dobavitelja za NIS2, zagotovilo tretjih oseb za DORA, podpora varnosti obdelave za GDPR in artefakt upravljanja za certifikacijo ISO 27001.

Vidik zasebnosti: ko nepodprto postane nevarno

Upravljanje obdobja varnostne podpore ni le vprašanje kibernetske varnosti. Če izdelek hrani, prenaša ali obdeluje osebne podatke, lahko nepodprta programska oprema postane tveganje za zasebnost.

GDPR se uporablja za obdelavo v okviru dejavnosti ustanovitve v EU in se lahko uporablja tudi za organizacije zunaj EU, ki posameznikom v EU ponujajo blago ali storitve ali spremljajo njihovo vedenje. Osebne podatke opredeljuje široko, kršitev varnosti osebnih podatkov pa obravnava kot kršitev varnosti, ki povzroči nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje ali dostop do obdelovanih osebnih podatkov.

Za upravljanje obdobja podpore morajo ekipe za zasebnost vedeti, katere različice izdelkov obdelujejo PII, kateri sistemi so še podprti in ali ranljivosti vplivajo na zaupnost, celovitost ali razpoložljivost osebnih podatkov.

Podjetniška Politika varnosti PII in nadzora dostopa Politika varnosti PII in nadzora dostopa zahteva:

“[Oboje] Lastnik sistema / lastnik aplikacije MORA vsaj četrtletno in po bistveni tehnični spremembi v REG12 evidentirati pokritost ocenjevanja ranljivosti za sisteme, ki obdelujejo PII.”

Vir: Politika varnosti PII in nadzora dostopa, varna konfiguracija in upravljanje ranljivosti, klavzula 4.7.4 Politika varnosti PII in nadzora dostopa

Podjetniška Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti dodaja stalno spremljanje visoko tveganih razmerij zasebnosti:

“[Vsi] Lastnik dobavitelja / nabave MORA četrtletno spremljati aktivna visoko tvegana razmerja z obdelovalci in podobdelovalci ter letno druga aktivna razmerja z obdelovalci in podobdelovalci PII glede na pogoje skrbnega pregleda, status pogodbe, status zagotovil, odprta vprašanja in datume pregledov v REG08.”

Vir: Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti, stalno spremljanje, pomoč, vmesnik za razkritje in izstop, klavzula 4.5.1 Politika upravljanja obdelovalcev, podobdelovalcev in tretjih oseb na področju zasebnosti

Ko ranljivost postane incident, podjetniška Politika upravljanja incidentov in kršitev varnosti PII Politika upravljanja incidentov in kršitev varnosti PII zahteva oceno sprožitvenih pogojev v več okvirih:

“[Pogojno] Vodja zasebnosti / vodja PIMS MORA za vsak incident v zvezi z osebno določljivimi podatki z velikim vplivom oceniti veljavne zakonske, sektorske, finančno-sektorske, kibernetskovarnostne, pogodbene, strankine in s prejemniki storitev povezane sprožitvene pogoje za poročanje ter izid uporabljivosti evidentirati v REG01, REG08 in REG10.”

Vir: Politika upravljanja incidentov in kršitev varnosti PII, razvrščanje in ocena kršitve, klavzula 4.2.6 Politika upravljanja incidentov in kršitev varnosti PII

To je praktično prekrivanje med zavezami podpore po CRA, komunikacijo o incidentih po NIS2, obravnavo večjih incidentov IKT po DORA in odgovornostjo za kršitve po GDPR.

Kako presojevalci preizkušajo isti proces obdobja podpore

Močan proces upravljanja obdobja podpore mora prestati različne sloge presoje. Dokazila se ne spremenijo bistveno, spremeni pa se pogled presojevalca.

NIST CSF 2.0 je uporaben kot komunikacijska plast, ker njegova funkcija GOVERN vključuje zakonske, regulativne, pogodbene in zasebnostne obveznosti, cilje upravljanja tveganj, apetit po tveganju, vloge, politike in nadzor. Njegovi rezultati za dobavno verigo zajemajo strategijo dobaviteljev, kritičnost, pogodbe, skrbni pregled, spremljanje, koordinacijo incidentov in določbe ob zaključku razmerja.

Presojevalci po pristopu COBIT in ISACA se pogosto osredotočajo na zasnovo upravljanja: kdo je lastnik odločitve, kateri proces je opredeljen, kateri kazalniki kažejo uspešnost, kako se odobrijo izjeme in kako se obravnava nenehno izboljševanje.

Podjetniška Politika informacijske varnosti Politika informacijske varnosti povzema načelo preverljivosti:

“Vse uvedene kontrole morajo biti preverljive, podprte z dokumentiranimi postopki in hranjenimi dokazili o delovanju.”

Vir: Politika informacijske varnosti, zahteve za izvajanje politike, klavzula 6.6.1 Politika informacijske varnosti

To je stavek, ki ga mora izpolnjevati vsako obdobje varnostne podpore.

Podaljšajte, skrajšajte ali zaključite podporo brez ustvarjanja lažnega zagotovila

Najtežji trenutki upravljanja niso ob lansiranju izdelka. Nastopijo, ko se spremeni realnost.

Podporo boste morda morali podaljšati, ker so regulirane stranke odvisne od izdelka, migracija ni izvedljiva ali ima sektorska stranka pogodbene potrebe po neprekinjenosti. Podporo boste morda morali skrajšati ali omejiti, ker dobavitelj umakne varnostno vzdrževanje, komponente ni več mogoče popraviti, platforma doseže tehnične omejitve ali arhitektura izdelka ne more varno podpreti določenega razreda ranljivosti.

Nadzorovana sprememba obdobja podpore mora vključevati:

• sprožilni dogodek spremembe, kot je konec življenjske dobe dobavitelja, kritična ranljivost, pogodba s stranko ali regulativna sprememba,
• prizadete izdelke, različice, stranke in sektorje,
• analizo vpliva na osebne podatke in kritične storitve,
• pregled izvedljivosti pri dobaviteljih in komponentah,
• oceno tveganja in odločitev o preostalem tveganju,
• posodobljen register obdobij podpore,
• posodobljeno obvestilo strankam in pogodbeno stališče,
• posodobljene opombe SoA, kadar se spremenijo kontrole ali obveznosti,
• odobritev vodstva in datum pregleda.

Podjetniška Politika usklajenega razkrivanja ranljivosti Politika usklajenega razkrivanja ranljivosti je uporabna, kadar spremembo sproži ranljivost:

“Za vse potrjene ranljivosti je treba pripraviti načrt odprave ali ublažitve. Izvedba popravka se prednostno razvrsti glede na resnost. Kritične ranljivosti je treba na primer odpraviti ali ublažiti v 14 dneh, kadar je to izvedljivo, oziroma prej, kadar je zaznano aktivno izkoriščanje, medtem ko je treba težave nižje resnosti obravnavati v razumnem roku.”

Vir: Politika usklajenega razkrivanja ranljivosti, zahteve za izvajanje, klavzula 6.6 Politika usklajenega razkrivanja ranljivosti

Če celovitega popravka ni mogoče dostaviti takoj, so lahko začasno sprejemljive kompenzacijske kontrole, onemogočena funkcionalnost, povečano spremljanje ali navodila strankam za konfiguracijo, vendar mora biti odločitev dokumentirana in sporočena.

Praktični kontrolni seznam Clarysec za pripravljenost obdobja podpore

Ta kontrolni seznam uporabite pred objavo ali obnovitvijo katere koli zaveze glede obdobja varnostne podpore po CRA.

• Ali sta izdelek in različica navedena v registru obdobij podpore?
• Ali so končni datum podpore odobrili produktna funkcija, varnostna funkcija in odgovorno vodstvo?
• Ali so zakonski, regulativni in pogodbeni dejavniki preslikani v evidenci skladnosti?
• Ali je scenarij tveganja obdobja podpore vključen v register tveganj?
• Ali so kontrole preslikane v izjavi o uporabnosti, vključno s 5.31, 8.8 in 8.25, kjer je to uporabljivo?
• Ali so kritični dobavitelji in komponente preslikani v registru odvisnosti od dobaviteljev?
• Ali obstajajo dokazila, da je komponente mogoče popraviti ali zamenjati v obdobju podpore?
• Ali so odgovornosti za sprejem prijav ranljivosti, triažo, odpravo in razkritje opredeljene?
• Ali so SLA za kritične popravke usklajeni s politiko in pogodbami s strankami?
• Ali se evidence popravkov, zapisi izdaj in odločitve o ranljivostih hranijo?
• Ali so sistemi z osebnimi podatki pokriti z dokazili o ocenjevanju ranljivosti, kadar se obdelujejo PII?
• Ali so obvestila strankam, izjave o podpori in pogodbeni pogoji medsebojno skladni?
• Ali obstaja proces za podaljšanje, skrajšanje ali zaključek podpore z odobritvijo tveganja?
• Ali vodstveni pregledi prejemajo vhodne informacije o tveganjih obdobja podpore, dobaviteljih, ranljivostih in incidentih?
• Ali je mogoče dokazila predložiti v 48 urah za presojo stranke ali poizvedbo regulatorja?

Podjetniška Politika spremljanja, presoje in izboljševanja PIMS Politika spremljanja, presoje in izboljševanja PIMS krepi disciplino vodstvenega pregleda za programe zasebnosti:

“[Oboje] Najvišje vodstvo MORA med vsakim vodstvenim pregledom v REG12 pregledati vhodne informacije o neskladnostih PIMS, korektivnih ukrepih, rezultatih spremljanja, rezultatih presoj, tveganjih zasebnosti, zagotovilih dobaviteljev in spremembah zainteresiranih strani.”

Vir: Politika spremljanja, presoje in izboljševanja PIMS, vodstveni pregled PIMS, klavzula 4.3.5 Politika spremljanja, presoje in izboljševanja PIMS

Za upravljanje obdobja varnostne podpore mora enaka periodika pregleda veljati v celotnem ISMS: ranljivosti, uspešnost nameščanja popravkov, zagotovila dobaviteljev, zaveze strankam, incidenti, izjeme podpore in korektivni ukrepi morajo biti vhodni podatki vodstvenega pregleda.

Poskrbite, da bo obdobje varnostne podpore zagovorljivo

EU Cyber Resilience Act spreminja način razmišljanja o varnosti izdelkov. Proizvajalce in ponudnike programske opreme usmerja k razmišljanju onkraj dneva izdaje. Obdobje varnostne podpore postane obljuba življenjskega cikla, ki mora biti tehnično zasnovana, upravljana, spremljana in podprta z dokazili.

Za vodje informacijske varnosti je sporočilo jasno: obdobje podpore ne sme ostati samo v produktnem trženju. Za vodje skladnosti: ne gradite ločenega silosa dokazil za CRA. Za presojevalce: preverite, ali so zaveze podpore sledljive do tveganj, kontrol, dobaviteljev, incidentov in dokumentiranih odobritev. Za lastnike podjetja: verodostojno obdobje podpore lahko postane tržna prednost, zlasti pri prodaji sektorjem, reguliranim z NIS2, finančnim subjektom DORA in strankam, občutljivim na zasebnost.

Clarysec organizacijam pomaga to operacionalizirati z:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za vzpostavitev sledljivosti ISMS, dokumentiranih informacij, preslikave SoA in pripravljenosti na presojo,
• Zenith Controls: The Cross-Compliance Guide Zenith Controls za preslikavo kontrol ISO/IEC 27002:2022 na NIS2, DORA, GDPR, NIST CSF 2.0 in pričakovanja presoje,
• paketi podjetniških politik in politik za MSP za upravljanje ranljivosti, varen razvoj, pravno skladnost, odvisnosti od dobaviteljev, dokazila zasebnosti in odziv na incidente,
• praktičnimi registri in delovnimi tokovi dokazil, ki obljube glede obdobja podpore spremenijo v preverljivo upravljanje.

Vaš naslednji korak je preprost: izberite eno vodilno različico izdelka in vzpostavite njeno mapo dokazil o obdobju varnostne podpore. Preslikajte obveznost, odobrite obdobje podpore, preizkusite proces obravnave ranljivosti, preverite odvisnosti od dobaviteljev, potrdite komunikacijo s strankami in hranite zapise.

Če lahko zagovarjate en izdelek, lahko model razširite. Če ne morete zagovarjati enega izdelka, vrzel ni dokumentacija. Vrzel je upravljanje.

Prenesite Zenith Blueprint, uporabite Zenith Controls za preslikavo svojih dokazil ali zahtevajte oceno pripravljenosti Clarysec, da obdobja varnostne podpore po CRA pretvorite v upravljanje ISO 27001, pripravljeno na presojo.