ELi CRA turbetoe perioodid ISO 27001 abil

On teisipäeva hommikul kell 08:20 ja ühendatud B2B-lüüsi tooteomanik saab reguleeritud kliendilt sõnumi: „Palun kinnitage püsivara versiooni 4.6 turbetoe periood, haavatavustele reageerimise SLA ning kas seadmele pakutakse turvauuendusi kogu meie viieaastase teenuslepingu jooksul.“

Kell 09:00 on hankeosakond edastanud DORA hoolsuskontrolli küsimustiku. Kell 10:15 küsib õigusosakond, kas reklaamitud tugiperiood on kooskõlas kliendilepingutega. Kell 11:00 kaasatakse CISO NIS2 tarnijariski ülevaatusse, sest toodet kasutab ELis tegutsev hallatud teenusepakkuja. Pärast lõunat küsib andmekaitsetiim, kas tootes olev toetuseta API teek võib GDPR alusel mõjutada isikuandmete turvalisust.

Ebamugav tõde ilmneb kiiresti. Ettevõttel on tegevuskava, paikamisprotsess, väljalaskekalender ja klienditoe portaal, kuid puudub juhitud turbetoe perioodi tõendusmaterjal.

See lünk on oluline. EU Cyber Resilience Act kontekstis ei ole turbetoe periood pelgalt tootesilt. See on elutsükli kohustus, mis mõjutab haavatavuste käsitlemist, uuenduste kättesaadavust, tarnijasõltuvuste juhtimist, kliendisuhtlust, lepingulisi kinnitusi ja turustamisjärgset seiret. SaaS-i pakkujate, seadmetootjate, tarkvaratootjate, pilveteenuse pakkujate ja IKT-teenuse osutajate jaoks muutub tugiperiood vastavusobjektiks, mida audiitorid ja reguleeritud ostjad kontrollivad.

Praktiline lahendus ei ole järjekordne eraldiseisev vastavustabel. Lahendus on juhtida turbetoe perioodi ISO/IEC 27001:2022 infoturbe juhtimissüsteemis ning vastendada sama tõendusmaterjal NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT-stiilis auditi ootustega.

See on Clarysec toimimismudel: kasuta ISMS-i tõendusmaterjali mootorina, kasuta jõustatavaid poliitikaid vastutuste määratlemiseks, kasuta Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint jälgitavuse loomiseks ning kasuta Zenith Controls: The Cross-Compliance Guide Zenith Controls raamistikeülese vastavuse kompassina.

Miks turbetoe periood on nüüd auditiobjekt

Turbetoe periood vastab lihtsale küsimusele: kui kaua pakub tootja tootele või tooteversioonile turvauuendusi, haavatavuste parandusmeetmeid, leevendusjuhiseid ja seotud kliendituge?

Praktikas sõltub vastus paljudest teguritest:

• toote arhitektuur ja hooldatavus;
• kolmandate osapoolte komponentide ja avatud lähtekoodiga sõltuvuste tugi;
• tarnijate ja pilveteenuste kohustused;
• haavatavuste vastuvõtu, triaaži, kõrvaldamise ja avalikustamise protsessid;
• väljalasete koostamise ja testimise suutlikkus;
• kliendilepingute tingimused ja regulatiivsed kohustused;
• intsidentidele reageerimise ja teenusesaajate teavitamise kanalid;
• tõendusmaterjali säilitamine ja heakskiidukirjed.

Kui tootja lubab viis aastat turbetuge, kuid kriitiline krüptograafiline teek jõuab kolme aasta pärast toetuseta staatusesse, muutub tugiperiood riskiotsuseks. Kui klient on DORA kohaldamisalasse kuuluv finantssektori üksus, muutub sama tugiperiood osaks kindlusest kolmandast isikust IKT-teenuse suhtes. Kui toode töötleb isikuandmeid, võib toetuseta tarkvara muutuda GDPR töötlemise turvalisuse vastutuse osaks. Kui toode toetab NIS2 alusel olulist või tähtsat üksust, muutub elutsükliturve tarneahela turbe küsimuseks.

NIS2 teeb selle juhtimisvaate selgesõnaliseks. Article 20 nõuab, et oluliste ja tähtsate üksuste juhtorganid kiidaksid heaks küberturbe riskijuhtimise meetmed, teostaksid rakendamise üle järelevalvet ja läbiksid koolituse. Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja korralduslikke meetmeid, sealhulgas riskianalüüsi, intsidentide käsitlemist, toimepidevust, tarneahela turvet, turvalist hankimist, turvalist arendust ja hooldust, haavatavuste käsitlemist ja avalikustamist, tõhususe hindamist, küberhügieeni, krüptograafiat, juurdepääsukontrolli, varahaldust ja autentimist. Article 23 lisab etapiviisilised oluliste intsidentide teatamiskohustused.

DORA tekitab finantssektori üksustele sarnase surve. See nõuab IKT-riski juhtimist, digitaalse tegevuskerksuse testimist, intsidendihaldust ja kolmandast isikust IKT-teenuse osutajatega seotud riskijuhtimist. DORA Article 28 käsitleb kolmandast isikust IKT-teenuse osutajatega seotud riskijuhtimise põhimõtteid ning Article 30 nõuab kirjalikke lepingulisi kokkuleppeid koos selgete teenusekirjelduste, turvameetmete, intsidendiabi, auditeerimisõiguste, lõpetamisõiguste ja väljumiskorraldustega.

GDPR lisab andmekaitsekihi. Kui toode töötleb isikuandmeid, vajavad vastutavad töötlejad ja volitatud töötlejad Article 32 alusel asjakohaseid tehnilisi ja korralduslikke meetmeid, Article 28 alusel lepingulist selgust ning Articles 33 ja 34 alusel valmisolekut rikkumist hinnata ja sellest teavitada.

Seetõttu tuleb CRA turbetoe perioodi juhtida nagu ISMS-i kontrollimeetmete kogumit, mitte käsitleda seda eraldiseisva tootehalduse väljana.

ISO 27001 kui CRA turbetoe perioodide kontrollimeetmete selgroog

ISO/IEC 27001:2022 on väärtuslik, sest see on skaleeritav, riskipõhine ja juhtimissüsteemile orienteeritud. See nõuab, et organisatsioon määratleks konteksti, huvitatud pooled, kohaldamisala ja omavahel toimivad protsessid ning teisendaks seejärel õiguslikud, regulatiivsed ja lepingulised nõuded riskihindamiseks, riskikäsitluseks, operatiivseteks kontrollimeetmeteks ja tõendusmaterjaliks ISO/IEC 27001:2022.

Turbetoe perioodi juhtimise puhul tähendab see, et organisatsioon peab:

1. tuvastama kohaldamisalasse kuuluvad tooted, versioonid, moodulid, pilveteenused ja sõltuvused;
2. tuvastama huvitatud pooled, sealhulgas kliendid, regulaatorid, levitajad, importijad, süsteemiintegraatorid, volitatud töötlejad, alltöötlejad, intsidentidele reageerimise partnerid ja tarnijad;
3. registreerima õiguslikud, regulatiivsed ja lepingulised tugikohustused;
4. hindama riske, mis võivad takistada tugikohustuste täitmist;
5. valima kontrollimeetmed haavatavuste halduse, turvalise arenduse, tarnijakindluse, intsidendihalduse, toimepidevuse, privaatsuse ja dokumenteeritud teabe jaoks;
6. koostama kohaldatavuse deklaratsiooni (Statement of Applicability, SoA) märkused, mis selgitavad, miks kontrollimeetmed kohalduvad;
7. vaatama tugiperioodi läbi, kui arhitektuur, tarnijasõltuvused, ohukokkupuude või kliendikohustused muutuvad.

Zenith Controls määratleb selle juhtimisprobleemi kesksete lähtepunktidena kolm teemaga seotud ISO/IEC 27002:2022 kontrollimeedet: 5.31 õiguslikud, seadusest tulenevad, regulatiivsed ja lepingulised nõuded, 8.8 tehniliste haavatavuste haldus ning 8.25 turvaline arenduse elutsükkel. Need ei ole ainsad seotud kontrollimeetmed, kuid need moodustavad juhtimise selgroo.

Võtmetähtsusega on jälgitavus. Toote tugiperiood peab olema jälgitav kohustusest riskistsenaariumini, riskistsenaariumist valitud kontrollimeetmeteni, kontrollimeetmetest poliitikanõueteni ning poliitikanõuetest tõendusmaterjalini.

Zenith Blueprint, riskijuhtimise etapi Step 13, kirjeldab seda jälgitavusdistsipliini otse:

„Viita regulatsioonidele risti: kui teatud kontrollimeetmed on rakendatud konkreetselt GDPR, NIS2 või DORA järgimiseks, saad selle märkida kas riskiregistris riskimõju põhjenduse osana või SoA märkustes.“

Allikas: Zenith Blueprint: An Auditor’s 30-Step Roadmap, riskijuhtimise etapp, Step 13: riskikäsitluse kavandamine ja kohaldatavuse deklaratsioon Zenith Blueprint

CRA turbetoe perioodi puhul ei tohi kohaldatavuse deklaratsioon öelda üksnes „haavatavuste haldus kohaldub“. See peab selgitama, et haavatavuste haldus kohaldub seetõttu, et ettevõttel on CRA elutsüklikohustused, NIS2 ootused turvalisele arendusele ja tarneahelale, DORA klientide hoolsuskontrolli nõuded, GDPR turbekohustused isikuandmete töötlemisel ning lepingulised tugilubadused.

Tugilubadusest juhitud elutsüklini

Tootja määratletud turbetoe periood peab läbima kuus juhtimistesti.

Esiteks peab see olema määratletud. Organisatsioon vajab standardset taksonoomiat, näiteks aktiivne tugi, ainult turbetugi, laiendatud tugi, piiratud tugi ja toetuseta staatus. Iga staatus peab selgitama uuenduste kättesaadavust, haavatavuste käsitlemist, kliendisuhtlust ja eskaleerimisteid.

Teiseks peab see olema riskihinnatud. Viieaastane tugi kontrollitud uuenduskanalitega pilvepõhisele SaaS-tootele erineb viieaastasest toest manussüsteemile, millel on kasutuskeskkonnast tulenevad piirangud, kolmandate osapoolte kiibisõltuvused ja kliendi hallatavad juurutusaknad.

Kolmandaks peab see olema heaks kiidetud. Toote-, turbe-, õigus-, andmekaitse- ja klienditoefunktsioon ning vastutav juhtkond peavad heaks kiitma baasperioodi ja erandid.

Neljandaks peab sellest olema teavitatud. Kliendid peavad mõistma toe alguskuupäeva, lõppkuupäeva, uuendusmeetodit, haavatavustest teatamise kanalit, parandusmeetmete ootusi, toe lõppemise tagajärgi ja kättesaadavaid pikendamisvõimalusi.

Viiendaks tuleb seda jälgida. Sõltuvused muutuvad. Tarnijad lõpetavad teekide toetamise. Haavatavused ilmnevad. Kliendikeskkonnad muutuvad. Tugiperioodi juhtimine peab hõlmama komponentide elutsükli seiret, tarnijate läbivaatamist, haavatavuste vooge, paikade logisid, väljalasete testimist ja intsidentidest saadud õppetunde.

Kuuendaks peab see olema tõendatud. Kui audiitor, regulaator või reguleeritud klient küsib tõendeid, peab organisatsioon suutma esitada vastavusregistri, toote tugiregistri, riskihindamise, SoA vastenduse, haavatavuste registri, paikamiskirjed, tarnijate ülevaatused, väljalasete heakskiidud ja klienditeated.

Clarysec poliitikad muudavad selle praktiliseks. Ettevõtte Õigusnormidele vastavuse poliitika Õigusnormidele vastavuse poliitika nõuab:

„Kõik õiguslikud ja regulatiivsed kohustused tuleb kaardistada konkreetsete poliitikate, kontrollimeetmete ja omanikega infoturbe juhtimissüsteemi (ISMS) raames.“

Allikas: Õigusnormidele vastavuse poliitika, poliitika rakendamise nõuded, punkt 6.2.1 Õigusnormidele vastavuse poliitika

VKE-de puhul algab samaväärne distsipliin lihtsamast registrist. VKE Õigusnormidele vastavuse poliitika Õigusnormidele vastavuse poliitika - VKE sätestab:

„GM peab pidama lihtsat, struktureeritud vastavusregistrit, mis sisaldab:“

Allikas: Õigusnormidele vastavuse poliitika - VKE, juhtimisnõuded, punkt 5.1.1 Õigusnormidele vastavuse poliitika - VKE

Tugiperioodi kohustus peab olema vastavusregistris, kui see tuleneb seadusest, kliendilepingust, sektori regulatsioonist või reguleeritud ostja ootusest. See ei tohi eksisteerida ainult väljalaskemärkmetes või turundustekstis.

Koosta CRA turbetoe perioodide register ühe töötoa käigus

Kujutle SaaS-i pakkujat, kes müüb ühendatud analüüsiseadet ELi logistikateenuse pakkujatele ja finantssektori klientidele. Toode sisaldab manustatud agenti, pilve API-t, mobiilset haldusrakendust ja mitut avatud lähtekoodiga teeki. Müük soovib lubada iga suurema seadmeversiooni jaoks viieaastast turbetuge.

CISO saab korraldada fookustatud töötoa toote-, arendus-, õigus-, andmekaitse- ja tarnijahalduse esindajatega.

Samm 1: loo tugiperioodide register

Loo iga tooteversiooni kohta üks rida ja lisa:

• toode ja versioon;
• väljalaskekuupäev;
• toe alguskuupäev;
• standardse turbetoe lõppkuupäev;
• laiendatud toe võimalus;
• uuenduste edastusmeetod;
• haavatavuste avalikustamise kanal;
• kriitilise paiga sihtaeg;
• andmetöötlusroll, näiteks vastutav töötleja, volitatud töötleja või mõlemad;
• kriitilised tarnijad ja komponendid;
• mõjutatud kliendisektorid;
• riskiomanik;
• heakskiidukuupäev;
• tõendusmaterjali asukoht.

See register muutub ISMS-i dokumenteeritud teabeks. Zenith Blueprint, ISMS-i aluste ja eestvedamise etapi Step 6, annab dokumendiohje ootuse:

„Dokumentidel peab olema nõuetekohane identifitseerimine (pealkiri, vajaduse korral dokumendinumber või unikaalne identifikaator, autor), asjakohane vorming ning läbivaatamine ja piisavuse heakskiit enne kasutamist.“

Allikas: Zenith Blueprint: An Auditor’s 30-Step Roadmap, ISMS-i aluste ja eestvedamise etapp, Step 6: dokumenteeritud teave ja ISMS-i teegi loomine Zenith Blueprint

Clarysec ettevõtte PIMS-i dokumenteeritud teabe ja tõendusmaterjali halduse poliitika PIMS-i dokumenteeritud teabe ja tõendusmaterjali halduse poliitika rakendab sarnaseid tõendusmaterjali põhimõtteid privaatsusdokumentatsioonile:

„[All] Privacy Lead / PIMS Manager PEAB enne PIMS-i dokumenteeritud teabe avaldamist määrama REG12-s dokumendi identifikaatori, omaniku, versiooninumbri, heakskiidustaatuse, jõustumiskuupäeva ja läbivaatamise kuupäeva.“

Allikas: PIMS-i dokumenteeritud teabe ja tõendusmaterjali halduse poliitika, loomine, heakskiitmine, versioonimine ja avaldamine, punkt 4.2.1 PIMS-i dokumenteeritud teabe ja tõendusmaterjali halduse poliitika

Isegi kui tugiperioodide register ei ole vaikimisi privaatsusdokument, kehtib sama distsipliin: omanik, versioon, heakskiit, jõustumiskuupäev ja läbivaatamise kuupäev.

Samm 2: seo tugilubadused riskikäsitlusega

Loo iga tooteversiooni kohta riskistsenaariumid, näiteks:

• toetatud versioonis avastatakse kriitiline haavatavus, kuid arendusvõimekus ei ole kättesaadav;
• kolmanda osapoole komponent muutub toetuseta enne deklareeritud turbetoe perioodi lõppu;
• tarnija muudab majutusasukohta või alltöövõtjat ja mõjutab uuenduste edastamist;
• haavatavus mõjutab isikuandmeid ja käivitab privaatsusrikkumise hindamise;
• reguleeritud finantsklient nõuab kolmandast isikust IKT-teenuse toimepidevuse tõendusmaterjali.

ISO/IEC 27001:2022 punktid 6.1.1 kuni 6.1.3 annavad planeerimismootori: tuvasta riskid, hinda tõenäosust ja tagajärgi, määra riskiomanikud, vali käsitlusmeetmed, võrdle valitud kontrollimeetmeid Annex A-ga, koosta kohaldatavuse deklaratsioon ja hangi jääkriski heakskiit.

Riski „toetuseta komponent enne toe lõppkuupäeva“ riskikirje peab sisaldama ISO/IEC 27002:2022 kontrollimeetmeid 5.31, 8.8 ja 8.25 ning tarnijakontrolle, nagu 5.19 infoturve tarnijasuhetes, 5.20 infoturbe käsitlemine tarnijalepingutes, 5.21 infoturbe juhtimine IKT tarneahelas ning 5.22 tarnijate teenuste seire, läbivaatamine ja muudatuste juhtimine.

Samm 3: kehtesta haavatavuste ja paikamise tõendusmaterjali reeglid

Tugiperiood on usutav ainult siis, kui haavatavuste haldus selle perioodi jooksul toimib.

VKE Haavatavuste ja paikade halduse poliitika Haavatavuste ja paikade halduse poliitika - VKE seab kiireloomulise kokkupuute korral range nõude:

„Kriitilised paigad tuleb rakendada 3 päeva jooksul alates väljalaskest, eriti internetile avatud süsteemide puhul.“

Allikas: Haavatavuste ja paikade halduse poliitika - VKE, poliitika rakendamise nõuded, punkt 6.1.1 Haavatavuste ja paikade halduse poliitika - VKE

See nõuab ka auditiks sobivaid kirjeid:

„Paikade logi tuleb pidada ja see tuleb auditite ning intsidentidele reageerimise tegevuste käigus läbi vaadata.“

Allikas: Haavatavuste ja paikade halduse poliitika - VKE, juhtimisnõuded, punkt 5.4.1 Haavatavuste ja paikade halduse poliitika - VKE

Ettevõtte keskkondades nõuab ettevõtte Haavatavuste ja paikade halduse poliitika Haavatavuste ja paikade halduse poliitika:

„Security Operations Team peab pidama keskset haavatavuste halduse registrit ning CISO või delegeeritud volitatud isik peab selle igakuiselt läbi vaatama.“

Allikas: Haavatavuste ja paikade halduse poliitika, juhtimisnõuded, punkt 5.1 Haavatavuste ja paikade halduse poliitika

Zenith Blueprint, kontrollimeetmete rakendamise etapi Step 19, selgitab ISO/IEC 27002:2022 kontrollimeetme 8.8 taga olevat operatiivset ootust:

„Ole kursis oma tarkvara ja riistvara uute turvavigadega (nt tarnijate teavituste, CVE-voogude jm kaudu). Hinda, millised neist on asjakohased (kas kasutame seda tarkvara? kui kriitiline viga on?) ning rakenda parandused või leevendusmeetmed viivitamata.“

Allikas: Zenith Blueprint: An Auditor’s 30-Step Roadmap, kontrollimeetmete rakendamise etapp, Step 19: tehnoloogilised kontrollimeetmed I Zenith Blueprint

Iga toetatud tooteversioon vajab haavatavuste tõendusahelat: vastuvõtt, asjakohasuse analüüs, tõsidus, mõjutatud versioonid, parandusplaan, parandusväljalase, leevendusjuhised, kliendisuhtlus ja sulgemise heakskiit.

Samm 4: seo turvaline arendus toe kestusega

Turbetugi algab enne väljalaset. See sõltub arenduspraktikatest, mis muudavad toote hooldatavaks.

VKE Turvalise arenduse poliitika Turvalise arenduse poliitika - VKE sätestab:

„Komponente tuleb regulaarselt uuendada, kui turvapaigad avaldatakse. Kui tuvastatakse kriitiline haavatavus, tuleb komponent viivitamata uuendada või asendada.“

Allikas: Turvalise arenduse poliitika - VKE, poliitika rakendamise nõuded, punkt 6.6.3 Turvalise arenduse poliitika - VKE

VKE Rakendusturbe nõuete poliitika Rakendusturbe nõuete poliitika - VKE nõuab, et lepingud ja nõuded:

„määratleksid haavatavuste avalikustamise, reageerimisaegade ja paikamise kohustused.“

Allikas: Rakendusturbe nõuete poliitika - VKE, juhtimisnõuded, punkt 5.3.2 Rakendusturbe nõuete poliitika - VKE

Kui ettevõte lubab tuge kuni aastani 2031, peab arhitektuur toetama hooldatavaid uuendusi, sõltuvuste asendamist, turvalisi ehituskonveiereid, regressioonitestimist ja erakorralisi väljalaskeid. ISO/IEC 27002:2022 kontrollimeetmed turvalise arenduse, turvalise arhitektuuri, turvalise programmeerimise, turbetestimise, allhankearenduse, keskkondade eraldamise ja muudatuste juhtimise kohta muutuvad tugiperioodi võimaldajateks.

Üks tõendusmaterjali kogum CRA, NIS2, DORA ja GDPR jaoks

Sama tugiperioodi tõendusmaterjal võib toetada eri regulatiivseid arutelusid, kuid iga raamistik esitab küsimuse erinevalt.

Tarnijasõltuvus on sageli koht, kus tugikohustused ebaõnnestuvad. Ettevõtte Tarnijasõltuvuse riskijuhtimise poliitika Tarnijasõltuvuse riskijuhtimise poliitika nõuab:

„Tarnijasõltuvuste register: VMO peab pidama ajakohast registrit kõigi kriitiliste tarnijate kohta, sealhulgas andmed osutatavate teenuste / tarnitavate toodete kohta; kas tarnija on ainus allikas; kättesaadavad alternatiivsed tarnijad või asendatavus; kehtivad lepingutingimused; ning mõju hinnang juhul, kui tarnija peaks ebaõnnestuma või kompromiteerituks osutuma.“

Allikas: Tarnijasõltuvuse riskijuhtimise poliitika, rakendusnõuded, punkt 6.1 Tarnijasõltuvuse riskijuhtimise poliitika

Zenith Blueprint, kontrollimeetmete rakendamise etapi Step 23, hoiatab, et audiitorid kontrollivad tarnijalepinguid ja tarnijaseire tõendusmaterjali:

„Audiitorid vaatavad üle näidislepingud või teenuslepingud. Nad otsivad selgesõnalisi infoturbeklausleid, näiteks rikkumisest teavitamise tähtaegu, juurdepääsupiiranguid, andmetöötluskohustusi, krüptimisnõudeid või auditeerimisõigusi.“

Allikas: Zenith Blueprint: An Auditor’s 30-Step Roadmap, kontrollimeetmete rakendamise etapp, Step 23: organisatsioonilised kontrollimeetmed Zenith Blueprint

DORA klientide jaoks on see kriitiline. Kriitilisi või olulisi funktsioone toetavate IKT-teenuste lepingud vajavad selgeid teenusekirjeldusi, alltöövõtu tingimusi, turvameetmeid, intsidendiabi, auditi- ja kontrolliõigusi, lõpetamisõigusi ning üleminekukorraldusi. Tarnija, kes ei suuda neid kohustusi toetada, võib takistada tootjal usutavat tugiperioodi lubamast.

Kontrollimeetmete vastendustabel auditivalmis tugiperioodi juhtimiseks

See vastendustabel võimaldab turbe-, õigus-, toote- ja müügitiimidel rääkida ühist keelt. Tugiperioodide register ei ole ainult CRA tõendusmaterjal. See on NIS2 jaoks tarnijakindluse tugi, DORA jaoks kolmanda osapoole kindlus, GDPR jaoks töötlemise turvalisuse tugi ja ISO 27001 sertifitseerimise juhtimisartefakt.

Privaatsusvaade: kui toetuseta tarkvara muutub ebaturvaliseks

Turbetoe perioodi juhtimine ei ole ainult küberturbe küsimus. Kui toode salvestab, edastab või töötleb isikuandmeid, võib toetuseta tarkvara muutuda privaatsusriskiks.

GDPR kohaldub töötlemisele ELis asuva üksuse tegevuse kontekstis ning võib kohalduda ka väljaspool ELi asuvatele organisatsioonidele, kes pakuvad ELis asuvatele isikutele kaupu või teenuseid või jälgivad nende käitumist. See määratleb isikuandmed laialt ning käsitab isikuandmetega seotud rikkumisena turberikkumist, mis põhjustab töödeldavate isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise, loata avalikustamise või neile juurdepääsu.

Tugiperioodi juhtimise puhul peavad andmekaitsetiimid teadma, millised tooteversioonid töötlevad isikut tuvastavat teavet, milliseid süsteeme veel toetatakse ning kas haavatavused mõjutavad isikuandmete konfidentsiaalsust, terviklust või käideldavust.

Clarysec ettevõtte Isikut tuvastava teabe (PII) turbe ja juurdepääsukontrolli poliitika PII turbe ja juurdepääsukontrolli poliitika nõuab:

„[Both] System Owner / Application Owner PEAB vähemalt kord kvartalis ja pärast olulist tehnilist muudatust registreerima REG12-s isikut tuvastavat teavet töötlevate süsteemide haavatavuste hindamise katvuse.“

Allikas: PII turbe ja juurdepääsukontrolli poliitika, turvaline seadistamine ja haavatavuste haldus, punkt 4.7.4 PII turbe ja juurdepääsukontrolli poliitika

Ettevõtte Volitatud töötlejate, alltöötlejate ja kolmandate osapoolte privaatsuse halduse poliitika Volitatud töötlejate, alltöötlejate ja kolmandate osapoolte privaatsuse halduse poliitika lisab kõrge privaatsusriskiga suhetele pideva seire:

„[All] Vendor / Procurement Owner PEAB jälgima aktiivseid kõrge riskiga volitatud töötlejate ja alltöötlejate suhteid kord kvartalis ning muid aktiivseid PII volitatud töötlejate ja alltöötlejate suhteid kord aastas REG08-s hoolsuskontrolli tingimuste, lepingu staatuse, kindluse staatuse, avatud probleemide ja läbivaatamise kuupäevade suhtes.“

Allikas: Volitatud töötlejate, alltöötlejate ja kolmandate osapoolte privaatsuse halduse poliitika, pidev seire, abi, avalikustamise liides ja väljumine, punkt 4.5.1 Volitatud töötlejate, alltöötlejate ja kolmandate osapoolte privaatsuse halduse poliitika

Kui haavatavusest saab intsident, nõuab ettevõtte PII intsidendi ja rikkumise halduse poliitika PII intsidendi ja rikkumise halduse poliitika mitme raamistiku teavitamise aluste hindamist:

„[Conditional] Privacy Lead / PIMS Manager PEAB iga suure mõjuga PII intsidendi puhul hindama kohaldatavaid õiguslikke, sektori-, finantssektori-, küberturbe-, lepingulisi, kliendi- ja teenusesaaja teavitamise aluseid ning registreerima kohaldatavuse tulemuse REG01-s, REG08-s ja REG10-s.“

Allikas: PII intsidendi ja rikkumise halduse poliitika, klassifitseerimine ja rikkumise hindamine, punkt 4.2.6 PII intsidendi ja rikkumise halduse poliitika

See on praktiline kokkupuutepunkt CRA tugikohustuste, NIS2 intsidendikommunikatsiooni, DORA oluliste IKT-intsidentide käsitlemise ja GDPR rikkumiste vastutuse vahel.

Kuidas audiitorid testivad sama tugiperioodi protsessi

Tugev tugiperioodi juhtimisprotsess peab vastu pidama mitmele auditeerimisstiilile. Tõendusmaterjal ei muutu palju, kuid audiitori vaatenurk muutub.

NIST CSF 2.0 on kasulik kommunikatsioonikihina, sest selle GOVERN Function hõlmab õiguslikke, regulatiivseid, lepingulisi ja privaatsuskohustusi, riskijuhtimise eesmärke, riskivalmidust, rolle, poliitikaid ja järelevalvet. Selle tarneahela tulemused katavad tarnijastrateegia, kriitilisuse, lepingud, hoolsuskontrolli, seire, intsidendikoordineerimise ja suhte lõpetamise sätted.

COBIT ja ISACA-stiilis audiitorid keskenduvad sageli juhtimismudelile: kes otsuse eest vastutab, milline protsess on määratletud, millised mõõdikud näitavad toimivust, kuidas erandeid heaks kiidetakse ja kuidas käsitletakse pidevat täiustamist.

Clarysec ettevõtte Infoturbepoliitika Infoturbepoliitika sõnastab auditeeritavuse põhimõtte:

„Kõik rakendatud kontrollimeetmed peavad olema auditeeritavad, toetatud dokumenteeritud protseduuridega ning säilitatud toimimise tõendusmaterjaliga.“

Allikas: Infoturbepoliitika, poliitika rakendamise nõuded, punkt 6.6.1 Infoturbepoliitika

See on lause, millele iga turbetoe periood peab suutma vastata.

Pikenda, lühenda või lõpeta tugi ilma vale kindlustunnet loomata

Kõige keerulisemad juhtimishetked ei teki toote turuletoomisel. Need tekivad siis, kui tegelikkus muutub.

Võib tekkida vajadus tuge pikendada, sest reguleeritud kliendid sõltuvad tootest, migreerimine ei ole teostatav või sektori kliendil on lepingulised toimepidevusvajadused. Võib tekkida vajadus tuge lühendada või piirata, sest tarnija lõpetab turvahoolduse, komponenti ei ole enam võimalik paigata, platvorm jõuab tehniliste piirideni või toote arhitektuur ei suuda haavatavuste klassi turvaliselt toetada.

Juhitud tugiperioodi muudatus peab hõlmama:

• muudatuse käivitajat, näiteks tarnija elutsükli lõppu, kriitilist haavatavust, kliendilepingut või regulatiivset muudatust;
• mõjutatud tooteid, versioone, kliente ja sektoreid;
• isikuandmete ja kriitilise teenuse mõjuhinnangut;
• tarnija ja komponendi teostatavuse ülevaatust;
• riskihindamist ja jääkriski otsust;
• ajakohastatud tugiperioodide registrit;
• ajakohastatud klienditeadet ja lepingulist positsiooni;
• ajakohastatud SoA märkuseid, kui kontrollimeetmed või kohustused muutuvad;
• juhtkonna heakskiitu ja läbivaatamise kuupäeva.

Ettevõtte Koordineeritud haavatavuste avalikustamise poliitika Koordineeritud haavatavuste avalikustamise poliitika on kasulik, kui muudatus tuleneb haavatavusest:

„Kõigi kinnitatud haavatavuste kohta tuleb koostada parandus- või leevendusplaan. Paranduse rakendamine tuleb prioriseerida raskusastme alusel. Näiteks tuleb kriitilised haavatavused parandada või leevendada võimaluse korral 14 päeva jooksul või aktiivse ärakasutamise tuvastamisel varem, samal ajal kui madalama tõsidusega probleemid tuleb lahendada mõistliku aja jooksul.“

Allikas: Koordineeritud haavatavuste avalikustamise poliitika, rakendusnõuded, punkt 6.6 Koordineeritud haavatavuste avalikustamise poliitika

Kui täielikku parandust ei saa kohe tarnida, võivad kompenseerivad kontrollimeetmed, funktsionaalsuse keelamine, suurendatud seire või kliendi konfiguratsioonijuhised olla ajutiselt vastuvõetavad, kuid otsus tuleb dokumenteerida ja sellest tuleb teavitada.

Praktiline Clarysec kontrollnimekiri tugiperioodi valmisolekuks

Kasuta seda kontrollnimekirja enne mis tahes CRA turbetoe perioodi kohustuse avaldamist või uuendamist.

• Kas toode ja versioon on kantud tugiperioodide registrisse?
• Kas toe lõppkuupäev on toote-, turbe- ja vastutava juhtkonna poolt heaks kiidetud?
• Kas õiguslikud, regulatiivsed ja lepingulised ajendid on vastavusregistris kaardistatud?
• Kas tugiperioodi riskistsenaarium sisaldub riskiregistris?
• Kas kontrollimeetmed on kaardistatud kohaldatavuse deklaratsioonis, sealhulgas vajaduse korral 5.31, 8.8 ja 8.25?
• Kas kriitilised tarnijad ja komponendid on tarnijasõltuvuste registris kaardistatud?
• Kas on tõendusmaterjali, et komponente saab tugiperioodi jooksul paigata või asendada?
• Kas haavatavuste vastuvõtu, triaaži, kõrvaldamise ja avalikustamise vastutused on määratletud?
• Kas kriitiliste paikade SLA-d on kooskõlas poliitika ja kliendilepingutega?
• Kas paikade logid, väljalaskekirjed ja haavatavuste otsused säilitatakse?
• Kas isikuandmete süsteemid on kaetud haavatavuste hindamise tõendusmaterjaliga seal, kus töödeldakse PII-d?
• Kas klienditeated, tugiväited ja lepingutingimused on omavahel kooskõlas?
• Kas on olemas protsess toe pikendamiseks, lühendamiseks või lõpetamiseks riskipõhise heakskiiduga?
• Kas juhtkonna läbivaatamised saavad sisendiks tugiperioodi riske, tarnijate teavet, haavatavusi ja intsidente?
• Kas kliendiauditi või regulaatori päringu korral saab tõendusmaterjali esitada 48 tunni jooksul?

Ettevõtte PIMS-i seire, auditi ja parendamise poliitika PIMS-i seire, auditi ja parendamise poliitika tugevdab privaatsusprogrammide juhtkonna läbivaatamise distsipliini:

„[Both] Tippjuhtkond PEAB iga juhtkonna läbivaatamise käigus REG12-s läbi vaatama PIMS-i mittevastavuse, parandusmeetme, seiretulemuse, audititulemuse, privaatsusriski, tarnijakindluse ja huvitatud poolte muutuste sisendid.“

Allikas: PIMS-i seire, auditi ja parendamise poliitika, PIMS-i juhtkonna läbivaatamine, punkt 4.3.5 PIMS-i seire, auditi ja parendamise poliitika

Turbetoe perioodi juhtimise puhul peab sama läbivaatamisrütm kehtima kogu ISMS-is: haavatavused, paikamise toimivus, tarnijakindlus, kliendikohustused, intsidendid, tugierandid ja parandusmeetmed peavad jõudma juhtkonna läbivaatamise sisendiks.

Muuda turbetoe periood kaitstavaks

EU Cyber Resilience Act muudab tooteturbe mõtteviisi. See suunab tootjaid ja tarkvarapakkujaid mõtlema väljalaskekuupäevast kaugemale. Turbetoe periood muutub elutsüklilubaduseks, mis tuleb projekteerida, juhtida, jälgida ja tõendada.

CISO-de jaoks on õppetund selge: ära lase tugiperioodil jääda ainult tooteturundusse. Vastavusjuhtide jaoks: ära loo eraldi CRA tõendusmaterjali silot. Audiitorite jaoks: testi, kas tugikohustused on jälgitavad riskide, kontrollimeetmete, tarnijate, intsidentide ja dokumenteeritud heakskiitudeni. Äriomanike jaoks: pea meeles, et usutav tugiperiood võib muutuda turueeliseks, eriti müügil NIS2-reguleeritud sektoritele, DORA finantssektori üksustele ja privaatsustundlikele klientidele.

Clarysec aitab organisatsioonidel selle rakendada järgmiste vahenditega:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ISMS-i jälgitavuse, dokumenteeritud teabe, SoA vastenduse ja auditivalmiduse loomiseks;
• Zenith Controls: The Cross-Compliance Guide Zenith Controls ISO/IEC 27002:2022 kontrollimeetmete kaardistamiseks NIS2, DORA, GDPR, NIST CSF 2.0 ja auditi ootustega;
• ettevõtte ja VKE poliitikapaketid haavatavuste halduse, turvalise arenduse, õigusnormidele vastavuse, tarnijasõltuvuste, privaatsuse tõendusmaterjali ja intsidentidele reageerimise jaoks;
• praktilised registrid ja tõendusmaterjali töövood, mis muudavad tugiperioodi lubadused auditeeritavaks juhtimiseks.

Sinu järgmine samm on lihtne: vali üks lipulaevaks olev tooteversioon ja koosta selle turbetoe perioodi tõendusmaterjali toimik. Kaardista kohustus, kiida tugiperiood heaks, testi haavatavuste protsessi, valideeri tarnijasõltuvused, kinnita kliendisuhtlus ja säilita kirjed.

Kui suudad kaitsta üht toodet, saad mudelit skaleerida. Kui sa ei suuda kaitsta üht toodet, ei ole lünk dokumentatsioonis. See on juhtimises.

Laadi alla Zenith Blueprint, kasuta Zenith Controls oma tõendusmaterjali kaardistamiseks või taotle Clarysec valmisolekuhindamist, et muuta CRA turbetoe perioodid auditivalmis ISO 27001 juhtimiseks.