2026 m. rugsėjo 11 d. gamintojams, tiekiantiems gaminius su skaitmeniniais elementais, prasideda viena pirmųjų operacinių Kibernetinio atsparumo akto (CRA) pareigų: apie aktyviai išnaudojamus pažeidžiamumus ir rimtus saugumo incidentus reikia pranešti per naują centralizuotą pranešimų platformą. Tai daugiau nei naujas atitikties terminas. Per kelias valandas reikia susieti gaminio tapatybę, paveiktas rinkas, techninį vertinimą ir taikomas priemones.
Skaitmeninis gaminio pasas arba su QR kodu susieta gaminio svetainė gali padėti vienareikšmiškai identifikuoti įrenginį ir vėliau informuoti naudotojus apie atnaujinimą. Tačiau tai nėra nei teisės aktuose nustatytas pranešimo kanalas, nei tinkama vieta konfidencialiai informacijai apie išnaudojimą saugoti. Todėl gamintojai jau dabar turėtų atskirti tris duomenų kelius: pranešimą institucijoms, viešą informaciją apie gaminį ir vidinę atnaujinimų istoriją.
Nauja paskata: liepos 27 ir 31 d. gairės
Europos Komisija paskelbė pirmąsias išsamias CRA gaires 2026 m. liepos 27 d.. Jose, be kita ko, aptariamos pranešimo pareigos, rizikos vertinimas, palaikymo laikotarpiai ir esminiai pakeitimai. Gairės nėra privalomos, tačiau 67 pavyzdžiais paaiškina, kaip įmonės gali praktiškai taikyti reglamentą.
Po keturių dienų, liepos 31 d., ENISA atnaujino savo informaciją apie vieno langelio pranešimų platformą. Joje dabar pateikiama planuojama eiga, numatyti įvesties laukai ir registracijos nurodymai. Platforma turėtų pradėti veikti iki 2026 m. rugsėjo 11 d.; Komisijos duomenimis, funkcionalumo ir saugumo bandymai jau vykdomi.
Laiko etapų seka yra svarbi: pagrindinės CRA pareigos iš esmės taikomos nuo 2027 m. gruodžio 11 d. Tačiau 14 straipsnis dėl pranešimo pareigų taikomas jau nuo 2026 m. rugsėjo 11 d. Tai patvirtina ir Reglamento (ES) 2024/2847 71 straipsnis, ir liepos 31 d. atnaujinta Komisijos CRA pranešimo procedūros apžvalga.
Trys duomenų erdvės vietoj vieno perkrauto gaminio paso
CRA pranešimo ir viešo gaminio puslapio tikslai skiriasi. Jei abu dalykai pateikiami viename duomenų rinkinyje, kyla rizika, kad incidentų komandai trūks informacijos arba viešajame žiniatinklyje bus paskelbta per daug neskelbtinų duomenų.
1. Konfidencialus pranešimas SRP, CSIRT ir ENISA
Vieno langelio pranešimų platforma yra teisės aktuose nustatytas įvesties kanalas. Reikia pranešti apie dviejų tipų įvykius: aktyviai išnaudojamą pažeidžiamumą, apie kurio neteisėtą išnaudojimą turima patikimų požymių, ir rimtą incidentą, kuris paveikia duomenų ar funkcijų prieinamumą, autentiškumą, vientisumą arba konfidencialumą.
Pranešime pateikiamas ne tik gaminio pavadinimas. ENISA tarp laukų nurodo, be kita ko, paveiktas valstybes nares, pirminį vertinimą, jau taikomas atsakomąsias priemones, galimus veiksmus naudotojams ir informacijos jautrumą. Vėlesniuose etapuose gali būti pateikiamas sunkumo lygis, poveikis, informacija apie užpuoliką ir techninė informacija apie saugumo atnaujinimą. Tokia informacija automatiškai nepriklauso laisvai pasiekiamame DPP puslapyje.
2. Vieša informacija apie gaminį ir saugumą
Viešasis duomenų kelias atsako į kitus klausimus: Kokį gaminį ir versiją turiu? Ar jis dar palaikomas? Ar prieinamas saugumo atnaujinimas? Ką konkrečiai turiu daryti kaip naudotojas? Tam gali būti prasmingas stabilus gaminio puslapis, pasiekiamas per QR kodą arba kitą duomenų laikmeną.
Viešajame puslapyje turėtų būti rodoma tik patvirtinta informacija: paveiktų modelių ir versijų sritys, prieinama saugi versija, diegimo nurodymai, pagalbos kontaktas ir paskelbimo laikas. Išnaudojimo detalės, vidinės aptikimo taisyklės, neužtaisyti atakos keliai ar asmens duomenys apie incidentą lieka apsaugotoje procedūroje. Sprendimą dėl viešo įspėjimo priima ne QR kodas: pagal CRA 17 straipsnį koordinuojanti CSIRT gali informuoti visuomenę arba pareikalauti, kad tai padarytų gamintojas, jei to reikia prevencijai ar poveikiui suvaldyti.
3. Vidinė atnaujinimų ir įrodymų istorija
Trečiasis kelias – atsekamas darbo įrašas. Jis susieja gaminio ID, aparatinės ir programinės įrangos versiją, programinės įrangos sudedamųjų dalių sąrašą, sužinojimo laiką, sprendimus dėl pirminio vertinimo, pranešimo etapus, pataisos patvirtinimą ir viešą pranešimą. Šioje istorijoje pakeitimai turi būti versijuojami, o ne tyliai perrašomi ankstesni vertinimai.
DPP veiklos atveju šis skirtumas yra esminis: viešajame rodinyje pateikiama dabartinė patvirtinta būklė, o vidinė istorija parodo, kaip ji susidarė. Kas jau tvarko gaminio duomenis pagal įvykius, gali taikyti tą patį principą kaip ir DPP atnaujinimams ir saityno kabliukams: įvykis suaktyvina tolesnius procesus, tačiau kiekvienas gavėjas gauna tik jo vaidmeniui skirtus laukus.
CRA laikrodis pradedamas skaičiuoti sužinojus
14 straipsnyje nustatyti laipsniški terminai. Apie aktyviai išnaudojamą pažeidžiamumą, nepagrįstai nedelsiant, bet ne vėliau kaip per 24 valandas nuo sužinojimo, reikia pateikti išankstinį įspėjimą. Per 72 valandas pateikiamas išsamesnis pranešimas apie pažeidžiamumą. Galutinė ataskaita turi būti prieinama ne vėliau kaip per 14 dienų nuo tada, kai parengiama taisymo arba poveikio mažinimo priemonė.
Rimto saugumo incidento atveju taip pat taikomas 24 valandų terminas išankstiniam įspėjimui ir 72 valandų terminas pranešimui apie incidentą. Galutinė ataskaita pateikiama per mėnesį nuo 72 valandų pranešimo. Taigi terminai pradedami skaičiuoti ne nuo CVE paskelbimo ir ne nuo kito reguliaraus leidimo, o nuo momento, kai laikoma, kad gamintojas buvo informuotas.
Praktikoje rekomenduojama aiški eiga:
- Užregistruoti gavimą iš pagalbos tarnybos, stebėsenos, tyrimų ar tiekimo grandinės, nurodant laiko žymą.
- Susieti gaminį ir versiją su stabilia vidine gaminio ID.
- Atsakingai komandai įvertinti išnaudojimą arba incidento sunkumą.
- Iš patvirtintų būtiniausių duomenų sudaryti 24 valandų rinkinį ir pateikti jį per SRP.
- Iki 72 valandų etapo papildyti technines išvadas, neprarandant pirminės būklės.
- Atskirai patvirtinti pataisą, veiksmą naudotojui ir viešą informaciją.
- Susieti galutinę ataskaitą su vidine istorija.
Šią seką reikėtų išbandyti pratybose dar prieš rugsėjį. ENISA pažymi, kad organizacijos gali automatizuoti savo vidinius procesus ir duomenų bazes, tačiau veikimo pradžioje platforma neteiks API. Todėl eksporto ir dviejų asmenų patikros procesas yra realesnis nei nepatikrinta tiesioginė integracija.
Bendra gaminio ID, bet atskiros prieigos teisės
Atskyrimas nereiškia, kad reikia tvarkyti tris nesusietas kopijas. Geresnis būdas – bendra nekintama gaminio nuoroda su pagal vaidmenį pritaikytais rodiniais.
Turėtų būti prieinami bent šie susiejimai:
- vidinė gaminio ID ir sąsaja su modeliu, partija arba serija;
- aparatinės, aparatinės programinės ir programinės įrangos versija;
- valstybės narės, kuriose paveikta versija buvo pateikta;
- saugumo vertinimo būsena ir sužinojimo laikas;
- nuorodos į 24 ir 72 valandų pranešimus bei galutinę ataskaitą;
- patvirtintas veiksmas naudotojui ir saugi tikslinė versija;
- viešo gaminio puslapio paskelbimo būsena.
Autorizaciją reikėtų modeliuoti laukų lygmeniu. Incidentų komandai ir už CRA atsakingiems asmenims reikia visos bylos. Pagalbai ir pardavimams reikia patvirtinto veiksmų nurodymo. Naudotojai mato tik viešą pranešimą. QR kodas idealiu atveju perduoda tik stabilią gaminio adresą; už jo esanti platforma pagal būseną ir vaidmenį sprendžia, kokia informacija pateikiama.
Ką gamintojai turėtų išbandyti iki rugsėjo
Tinkamam bandymo atvejui nereikia tikro pažeidžiamumo. Pasirinkite prijungtą gaminį, paveiktą programinės aparatinės įrangos versiją ir tris valstybes nares. Imituokite sužinojimą darbo dieną ir patikrinkite:
- Ar komanda per 24 valandas gali patvirtinti gaminių aprėptį ir būtiniausius duomenis?
- Ar aišku, kas kaip atstovas turi prisijungti prie SRP per EU Login?
- Ar galima papildyti 72 valandų informaciją, nepaskelbiant viešai konfidencialių detalių?
- Ar patvirtinus pataisą visomis reikiamomis kalbomis pateikiama patikrinta informacija naudotojams?
- Ar viešasis URL išlieka stabilus, kai keičiasi versija ir priemonės?
- Ar galima atsekti, kas, kada ir kurią būklę patvirtino?
Paskutiniam punktui padeda nuoseklus, versijuojamas duomenų tvarkymas. qr3 straipsnyje apie nuolatinį DPP atnaujinimą parodyta pagrindinė idėja: tapatybė išlieka stabili, o dalykiniai duomenys kontroliuojamai papildomi. CRA procese prie to prisideda griežtesnis konfidencialumo ir patvirtinimo sluoksnis.
Išvada: gaminio pasas yra platintojas, o ne pranešimų vieta
Naujosios gairės rugsėjo terminą paverčia praktiškai suprantamu. Gamintojams nereikia į savo skaitmeninį gaminio pasą įtraukti konfidencialios pažeidžiamumų duomenų bazės. Jiems reikia patikimos sąsajos tarp trijų aiškiai atskirtų sričių: pranešimo institucijoms, vidinių įrodymų ir patvirtintos informacijos naudotojams.
Bendra gaminio ID šias sritis susieja. Vaidmenys, patvirtinimai ir versijavimas neleidžia konfidencialiai informacijai patekti į išorę ir užtikrina, kad naudotojai laiku sužinotų apie prieinamą priemonę. QR kodas išlieka naudingas, bet sąmoningai neįmantrus: jis nuolat nukreipia į tinkamą gaminio kontekstą. Tikroji CRA atitiktis užtikrinama už jo veikiančiuose procesuose.
