Kibernetinio atsparumo aktas: įtraukite įpareigojimus į produktų kūrimą

Kibernetinio atsparumo aktas (CRA) įtraukia kibernetinio saugumo įpareigojimus į jam priskirtų produktų su skaitmeniniais elementais gyvavimo ciklą. Technologijų vadovui praktinis uždavinys yra susieti tai, ką inžinerijos komanda kuria, tiekia ir prižiūri, su įrodymais, kurių reikia šiems įpareigojimams įrodyti.

Ši sąsaja turi veikti produkto ir versijos lygmeniu. Visai įmonei taikoma saugumo politika nepaaiškina, ar konkreti versija turi saugius numatytuosius nustatymus, kokias priklausomybes ji turi ar kaip klientai gaus saugumo atnaujinimą. Pažeidžiamumo užduotis, pažymėta kaip „ištaisyta“, neparodo, kurios palaikomos versijos tebėra pažeidžiamos.

Todėl naudingas atspirties taškas yra produkto gyvavimo ciklo modelis: taikymo sritis, saugumo reikalavimai, išleidimo įrodymai, pažeidžiamumų tvarkymas, palaikymo įsipareigojimai ir atskaitingi sprendimai. Šį modelį įtraukite į kūrimo procesą, o ne rinkite jį atskirai prieš vertinimą.

Prieš priskirdami kontrolės priemones, apibrėžkite produkto ribas

CRA taikomas į jo taikymo sritį patenkantiems produktams su skaitmeniniais elementais, įskaitant atitinkamą aparatinę ir programinę įrangą. Tai nėra visuotinė taisyklė kiekvienai SaaS paslaugai. Talpinamai paslaugai ir klientams platinamai programinei įrangai gali reikėti skirtingų analizių, o neatskiriamą produkto dalį sudarantį nuotolinį duomenų apdorojimą taip pat reikia išnagrinėti.

Kaip pradinę nuorodą naudokite Europos Komisijos CRA gaires, tada išspręskite konkrečiam produktui kylančius teisinius klausimus. Užfiksuokite išvadą, o ne pasikliaukite neformalia komandos prielaida.

Kiekvienam galimam produktui nustatykite:

• Ką gauna klientai: aparatinę įrangą, įdiegiamą programinę įrangą, atsisiunčiamus komponentus ar jų derinį.
• Kurios nuotolinio duomenų apdorojimo funkcijos būtinos, kad produktas galėtų atlikti savo funkcijas.
• Kaip produktas tiekiamas ES rinkai ir kuris subjektas jį tiekia.
• Jūsų kaip ekonominės veiklos vykdytojo vaidmenį: gamintojas, importuotojas, platintojas ar kitas susijęs vaidmuo.
• Taikomas išimtis, konkretiems produktams skirtus teisės aktus ir su atvirojo kodo programine įranga susijusius aspektus.
• Produkto kategoriją ir iš jos kylančius atitikties vertinimo reikalavimus.

Atvirajam kodui reikia ypatingo dėmesio. Ne komercinės veiklos metu tiekiamai programinei įrangai taikoma tvarka nereiškia, kad komercinis gamintojas gali ignoruoti į jo produktą įtrauktus atvirojo kodo komponentus. Atskirkite pirminio kūrėjo padėtį nuo savo atsakomybės už tiekiamą produktą.

Inžinerinis rezultatas turėtų būti trumpas taikymo srities įrašas su architektūros diagrama, produkto identifikatoriais, susijusiais komerciniais subjektais, prielaidomis ir patvirtinta išvada. Įvardykite asmenį, atsakingą už šios išvados peržiūrą, kai keičiasi funkcionalumas ar platinimas.

Pavyzdžiui, atsisiunčiamai valdymo programai ir jos talpinamai analitikos paslaugai neturėtų būti automatiškai priimtas vienas neišskaidytas taikymo srities sprendimas. Nustatykite, kurios funkcijos veikia vietoje, kurios priklauso nuo paslaugos ir ar tas nuotolinis duomenų apdorojimas patenka į produkto ribas. Šis skirtumas turi įtakos rizikos vertinimui, priklausomybių įrašams ir atsakomybei už incidentus.

Remkitės dabartinėmis įgyvendinimo datomis

Komisija pranešimo įpareigojimams nurodo 2026 m. rugsėjo 11 d., o pagrindiniams CRA reikalavimams 2027 m. gruodžio 11 d. 2026 m. spalio 7 d. duomenimis, pranešimo data jau praėjo. Pasirengimą pranešti laikykite dabartiniu veiklos reikalavimu, o ne užduotimi, atidedama iki pasirengimo atitikties vertinimui.

Abi darbo kryptis laikykite matomas:

Produktams, tiektiems iki pagrindinės taikymo datos, reikia atkreipti dėmesį į pereinamąsias nuostatas ir esminius pakeitimus. Nemanykite, kad senesnis produktas nesvarbus pranešimų požiūriu vien todėl, kad jo pirminė versija buvo išleista iki 2027 m. gruodžio.

Tvarkykite datuotą teisinių reikalavimų registrą. Dėl įvykių ribų, pakopinių pranešimo terminų, gavėjų ir pateikimo procedūrų tikrinkite dabartinį teisės akto tekstą ir oficialias įgyvendinimo gaires. Nepakeiskite CRA specifinio proceso bendru reagavimo į incidentus šablonu.

Paverskite saugumo reikalavimus projektavimo ir išleidimo kriterijais

CRA esminiai reikalavimai apima produkto saugumo savybes ir pažeidžiamumų tvarkymą. Jų įgyvendinimas turėtų remtis produkto kibernetinio saugumo rizikos vertinimu, o ne visuotiniu kontroliniu sąrašu, taikomu be architektūrinio konteksto.

Pradėkite nuo to, kaip produktas gali sukelti žalą. Aprašykite naudotojus, diegimo aplinkas, prieinamas sąsajas, privilegijuotas operacijas, jautrius duomenis ir numatomą netinkamą naudojimą. Įtraukite kliento veiklos prielaidas: pramoniniame tinkle įdiegtas įrenginys turi kitokį poveikį ir atkūrimo apribojimus nei stalinio kompiuterio įrankis.

Šiam darbui gali padėti praktinis grėsmių modeliavimas; OWASP grėsmių modeliavimo gairės siūlo nusistovėjusį metodą. Rezultatas turėtų susieti grėsmes su konkrečiais reikalavimais, įgyvendinimo sprendimais ir testais.

Pažiūrėkite, kaip žinomi reikalavimai tampa testuojami:

Tai praktiniai įgyvendinimo pavyzdžiai, o ne taikomų reikalavimų pakaitalas. Aktualumą ir pakankamumą nustatykite per rizikos vertinimą.

Į funkcijų kūrimo darbus įtraukite saugumo priėmimo kriterijus. Nauja administravimo API turėtų atsirasti su autentifikavimo, autorizavimo, įvesties tvarkymo ir žurnalų registravimo sprendimais, o ne su pažadu, kad saugumo komanda ją patikrins vėliau. Peržiūrėkite grėsmių modelį, kai pridedate nuotolinę sąsają, privilegijuotą komponentą ar naują pasitikėjimo ribą.

Išleidimo patvirtinime turėtų būti nurodyti neišspręsti pažeidžiamumai, jų išnaudojamumas, paveiktos konfigūracijos ir tvarkymas. Taikykite CRA reikalavimą tiekti produktus rinkai be žinomų išnaudojamų pažeidžiamumų, atsižvelgdami į rizikos vertinimą ir taikomus esminius reikalavimus; rizikos užfiksavimas ar priėmimas savaime šio reikalavimo neįvykdo. Vien skenerio rezultatas negali priimti šio sprendimo: svarbu pasiekiamumas, išankstinės sąlygos ir produkto elgsena. Ir atvirkščiai, maža skaitinė sunkumo įvertis nėra pakankama priežastis ignoruoti pažeidžiamumą, kuris jūsų diegimo modelyje yra reikšmingas.

Išleidimo įrašas turėtų susieti patvirtintą išeitinio kodo versiją, kompiliavimo artefaktą, priklausomybių inventorių, testų rezultatus ir saugumo sprendimą. Taip vertinimą galima atkurti, kai klientas ar institucija vėliau klausia apie konkrečią versiją.

Padarykite komponentų išsamų patikrinimą kompiliavimo proceso dalimi

Trečiųjų šalių komponentai sukuria įpareigojimų, kurių negalima įvykdyti tiesiog persiunčiant pirminio kūrėjo saugumo pranešimą. Turite suprasti, ką pristatėte, ar tai paveikta ir kaip galite tai ištaisyti.

CRA pažeidžiamumų tvarkymo reikalavimuose numatytas programinės įrangos komponentų sąrašo reikalavimas: dažnai naudojamu, mašininiu būdu skaitomu formatu, apimančiu bent aukščiausio lygio priklausomybes. Praktiškai rekomenduojama fiksuoti gilesnę priklausomybių informaciją visur, kur jūsų kompiliavimo įrankiai gali pateikti patikimus rezultatus. Netiesioginės priklausomybės dažnai lemia poveikį.

SBOM naudingas tik tada, kai jis atitinka realų produkto artefaktą. Susiekite jį su versijos identifikatoriumi ir kompiliavimu, atskirkite pristatomus komponentus nuo vien kūrimui naudojamų įrankių. Kur aktualu, įtraukite programinę aparatinę įrangą, operacinės sistemos paketus, kartu pateikiamas bibliotekas ir komercinius komponentus; paketų tvarkyklės eksportas gali praleisti kelis iš jų.

Komponentų peržiūrą kurkite aplink klausimus, kurie keičia inžinerinius sprendimus:

• Ar komponentas prižiūrimas ir ar jo palaikymo laikotarpis suderinamas su mūsų?
• Ar galime laiku gauti informaciją apie pažeidžiamumus ir saugumo atnaujinimus?
• Ar turime prieigą prie išeitinio kodo, tiekėjo pataisų kanalą ar pakeitimo strategiją?
• Ar komponentas įveda privilegijuotą vykdymą ar naują išorinį ryšį?
• Ar produktą vis dar galima prižiūrėti, jei tiekėjas nustos jį palaikyti?

Komercinių komponentų atveju pirkimų skyrius turėtų nustatyti saugumo kontaktus, pranešimų tvarką ir prieigą prie pataisymų. Tiekėjo terminai turi palikti laiko jūsų pačių vertinimui ir pranešimo įpareigojimams. Produkto gamintojui vis tiek reikia vidinio eskalavimo kelio, kai tiekėjo atsakymas neišsamus.

Atvirojo kodo priklausomybėms išsaugokite kilmės informaciją ir realistišką priežiūros planą. Tai, kad saugykla viešai prieinama, nėra įrodymas, kad kas nors per jūsų palaikymo laikotarpį parengs suderinamą pataisą.

Palaikymo laikotarpį ir atnaujinimų mechanizmą projektuokite kartu

Palaikymas yra inžinerinis įsipareigojimas su komercinėmis pasekmėmis. CRA paprastai reikalauja ne trumpesnio kaip penkerių metų palaikymo laikotarpio, nebent numatomas produkto naudojimo laikotarpis yra trumpesnis. Taikomą laikotarpį nustatykite pagal reglamento kriterijus, o ne rinkitės savavališką datą, kad ji tiktų plėtros planui.

Užfiksuokite pagrindimą, praneškite klientams reikalaujamą informaciją apie palaikymą ir susiekite ją su prižiūrimomis produkto versijomis. Palaikymo įsipareigojimas turi apimti gebėjimą teikti saugumo atnaujinimus, o ne vien pagalbos tarnybos adreso išlaikymą.

Prieš patvirtindami produkto palaikymo planą, paklauskite, ar galite:

• Iš naujo sukompiliuoti senesnes palaikomas šakas naudodami prižiūrimus įrankių rinkinius.
• Saugiai parengti, autentifikuoti ir platinti saugumo atnaujinimus.
• Testuoti pataisymus visose palaikomose aparatinės įrangos ir diegimo konfigūracijose.
• Prižiūrėti pasirašymo raktus ir saugiai atsigauti po rakto kompromitavimo.
• Išlaikyti klientams skirtą informaciją apie atnaujinimus ir saugumą prieinamą.
• Tvarkyti priklausomybes, kurių pirminis palaikymas baigiasi anksčiau nei jūsų.

Saugumo atnaujinimai palaikymo laikotarpiu paprastai turi būti teikiami nemokamai, laikantis reglamento nuostatų. Kiekvienas tuo laikotarpiu išleistas saugumo atnaujinimas turi likti prieinamas ne trumpiau kaip dešimt metų nuo jo išleidimo arba likusį palaikymo laikotarpį, atsižvelgiant į tai, kuris laikotarpis ilgesnis. Saugumo pataisymus planuokite atskirai nuo funkcijų kūrimo, kad klientai be reikalo nebūtų verčiami priimti nesusijusių funkcinių pakeitimų.

Testuokite ne tik sėkmingą scenarijų. Nutrūkęs įdiegimas, nepakankama atmintis, pasibaigęs prisijungimo duomenų galiojimas ir nepavykusi patikra gali tinkamą pataisą paversti prieinamumo problema. Nuspręskite, kokių atkūrimo mechanizmų reikia atsižvelgiant į produkto rizikos profilį.

Pasibaigus palaikymui, komunikacija su klientais ir vidiniai įrašai turėtų sutapti. Nepalikite atsisiuntimo puslapio, kuris leidžia manyti, kad saugumo priežiūra tęsiasi, kai produktų registre nurodyta, jog įsipareigojimas baigėsi.

Sukurkite pranešimo vadovą, kuris atlaiko neapibrėžtumą

Įprastas pažeidžiamumo radinys, aktyviai išnaudojamas pažeidžiamumas ir didelis saugumo incidentas nėra tas pats. CRA pranešimo procesui reikia dokumentuoto atitinkamos paskatos vertinimo, o ne automatinio pranešimo apie kiekvieną skenerio įspėjimą ir ne automatinio visko atmetimo, kol neužbaigtas teismo ekspertizės tyrimas.

Vadovas turėtų prasidėti nuo informacijos priėmimo. Tyrėjams, klientų aptarnavimui, tiekėjams ir inžinerijos komandoms reikia žinomo kelio į produkto saugumo funkciją. Išsaugokite pradinį pranešimą ir užfiksuokite, kada sužinota atitinkama informacija; nenustatykite sužinojimo laiko žymų iš naujo, kai užduotis perduodama kitai komandai.

Apie įvykius, apie kuriuos galbūt reikia pranešti, surinkite:

• Produkto identifikatorius ir paveiktas palaikomas versijas.
• Išnaudojimo ar incidento poveikio įrodymus, nurodant patikimumą ir neapibrėžtumus.
• Žinomas atakos sąlygas, paveiktas funkcijas ir diegimo prielaidas.
• Turimas rizikos mažinimo priemones ir taisomųjų priemonių būseną.
• Paskatos vertinimą, už pranešimą atsakingą asmenį ir taikomų terminų skaičiavimus.
• Pateiktus pranešimus, patvirtinimus, vėlesnius atnaujinimus ir komunikaciją su klientais.

Pakopinius pranešimo terminus, galutinės ataskaitos reikalavimus, gavėjus ir dabartinę pranešimo procedūrą patikrinkite pagal oficialius šaltinius. Aktyviai išnaudojamiems pažeidžiamumams ir dideliems incidentams taikomos skirtingos pranešimo detalės; vieno nukopijuoto termino lauko nepakanka.

Paskirkite pagrindinį už pranešimą atsakingą asmenį ir pavaduotoją, turinčius įgaliojimus koordinuoti inžinerinę, teisinę ir klientams skirtą komunikaciją. Iš anksto pasirūpinkite prieiga prie taikomo pranešimo mechanizmo. Teisinė peržiūra turėtų būti prieinama per pranešimo laikotarpį, o ne virsti neribota patvirtinimo eile.

Procesą išbandykite su neišsamia informacija. Naudingos pratybos prasideda nuo patikimo pranešimo apie išnaudojimą, neaiškaus paveiktų versijų sąrašo ir nepasiekiamo komponento tiekėjo. Komanda turėtų gebėti laiku priimti dokumentuotą sprendimą dėl pranešimo, kol tyrimas tęsiasi.

CRA pranešimai nepakeičia kitų taikomų pareigų. Produkto įvykis taip pat gali reikalauti vertinimo pagal duomenų apsaugos teisę ar sutartį su klientu. Šiuos vertinimus koordinuokite, tačiau išsaugokite atskiras jų paskatas, gavėjus ir sprendimų įrašus.

Prieš rinkdamiesi vertinimo planą, patvirtinkite klasifikaciją

Produkto klasifikacija turi įtakos galimam atitikties vertinimo būdui. Nemanykite, kad kiekvienam prijungtam produktui reikia to paties išorinio vertinimo ar kad kiekvienas gamintojas gali remtis vidiniu vertinimu.

Taikomą kategoriją nustatykite pagal produkto funkcijas ir reglamento apibrėžtis bei priedus. Tada patvirtinkite leidžiamą būdą, įskaitant visas sąlygas, susijusias su darniaisiais standartais, pripažintomis specifikacijomis, sertifikavimo schemomis ar trečiosios šalies vertinimu.

Standartų planavimui reikia aiškaus priklausomybių registro: kurios nuorodos taikomos, kokia jų dabartinė būsena ir kas pasikeičia, jei laukiamas būdas nepasiekiamas. Venkite, kad išleidimo planas priklausytų nuo nepatvirtintos prielaidos apie standartus ar vertinimo pajėgumus.

Klasifikaciją peržiūrėkite, kai keičiasi funkcionalumas. Saugumo valdymo ar tinklo kontrolės galimybių pridėjimas gali turėti įtakos analizei, tačiau vien funkcijos pavadinimas kategorijos nenulemia. Įvertinkite faktinę funkciją ir dokumentuokite išvadą.

Klasifikaciją, pasirinktą būdą ir atitikties rezultatus laikykite susietus su technine dokumentacija. CE ženklinimas ir atitikties deklaracija turi atitikti taikomą procesą; jie nepakeičia pagrindinių reikalavimų įgyvendinimo.

Palaikykite įrodymų paketą, galintį paaiškinti išleistą versiją

Techninė dokumentacija turėtų apibūdinti ir produktą, ir jo saugumo sprendimų pagrindimą. Kintant produktui, išsaugokite rizikos vertinimus ir dokumentaciją, o atitinkamiems įrašams taikykite teisės aktuose nustatytus saugojimo reikalavimus.

Naudingą produkto įrodymų paketą sudaro taikymo srities sprendimas, architektūra, rizikos vertinimas, saugumo reikalavimai, komponentų informacija, patikros rezultatai, pažeidžiamumų tvarkymo procedūros, palaikymo pagrindimas ir atitikties įrašai. Kiekvienam elementui reikia atsakingo asmens ir atpažįstamos versijos.

Šiems įrašams susieti naudokite pastovius identifikatorius. Pažeidžiamumo įraše turėtų būti paaiškintos paveiktos versijos, poveikis, tvarkymas, išleista versija ir reikalinga komunikacija. „Ištaisyta“ be versijos konteksto palieka produkto įrodymus neišsamius.

Esami ISMS procesai gali suteikti naudingų valdymo, tiekėjų ir saugaus kūrimo įrodymų. Tačiau ISO 27001 susijęs su apibrėžtos apimties informacijos saugumo valdymo sistema; sertifikavimas neįrodo atskiro produkto atitikties CRA. Atitinkamus įrodymus naudokite pakartotinai, tačiau nelaikykite susiejimų su sistemomis teisiniu lygiavertiškumu.

Pavyzdys: priklausomybės trūkumas palaikomame įrenginyje

Panagrinėkime iliustracinį gamintoją, ES tiekiantį prie tinklo jungiamą įrenginį. Tarkime, jo taikymo sritis ir klasifikacija peržiūrėtos, dvi išleidimo šakos tebėra palaikomos, o apie kartu pateikiamą biblioteką pranešama, kad ji kitur aktyviai išnaudojama.

Pirmoji užduotis nėra uždaryti pirminio kūrėjo saugumo pranešimą. Inžinerijos komanda nustato, kuriuose įrenginio kompiliavimuose yra pažeidžiama biblioteka ir ar paveikta funkcija yra pasiekiama. SBOM rodo, kad ji yra abiejose šakose, tačiau konfigūracijos analizė parodo skirtingą poveikį. Šis skirtumas užfiksuojamas kartu su jį pagrindžiančiais įrodymais.

Tada produkto saugumo savininkas įvertina, ar turimi faktai atitinka taikomą CRA pranešimo paskatą. Neapibrėžtumas dėl vienos diegimo konfigūracijos užfiksuojamas; jis nepateisina to, kad sprendimą priimantis asmuo lieka neįvardytas. Pranešimo vadove pateikiami dabartiniai pranešimo etapai ir procedūra.

Inžinerijos komanda parengia laikiną rizikos mažinimo priemonę ir pataisytą kompiliavimą kiekvienai paveiktai šakai. Testai apima pažeidžiamą kelią, įprastą veikimą ir autentifikuoto atnaujinimo įdiegimą. Jei vienoje šakoje pirminio kūrėjo pataisos naudoti negalima, komanda užfiksuoja alternatyvų tvarkymą ir liekamąją riziką, o ne pažymi visą produktą kaip ištaisytą.

Komunikacijoje su klientais nurodomos paveiktos versijos, neatidėliotini apsaugos veiksmai ir tai, kaip gauti atnaujinimą. Atskleidimo laikas derinamas su taikomais pažeidžiamumų tvarkymo reikalavimais ir bet kokiais pagrįstais saugumo sumetimais.

Užbaigtas įrašas susieja saugumo pranešimą, paveiktų kompiliavimų analizę, sprendimą dėl pranešimo, prireikus pateiktus pranešimus, pataisų pakeitimus, testų rezultatus, išleidimo artefaktus ir komunikaciją. Peržiūrėtojas dabar gali atkurti ir inžinerinį atsaką, ir atitikties sprendimą.

Pradėkite nuo vieno produkto ir vienos išsamios įrodymų grandinės

Pasirinkite reprezentatyvų palaikomą produktą ir atsekite vieną neseniai išleistą versiją bei vieną pažeidžiamumą per visą gyvavimo ciklą. Trūkstamos sąsajos su versijomis, neaiškūs palaikymo įsipareigojimai ir nepasiekiamos pranešimo procedūros greitai taps matomi. Kiekvieną spragą paverskite užduotimi su atsakingu asmeniu, tada išplėskite modelį visam produktų portfeliui.

Secani gali palaikyti šį įrodymų darbo procesą, susiedama reikalavimus, įrodymus, atsakingus asmenis, užduotis ir peržiūros sprendimus. Inžineriniai įrankiai lieka veikiančiais kompiliavimų, išleidimų ir pažeidžiamumų šaltiniais; atitikties darbo erdvė šiuos įrašus susieja su taikomu įpareigojimu. Susiejimams ir išvadoms išlaikykite aiškų žmogaus patvirtinimą, o naudodami DI padedamus juodraščius išsaugokite šaltinių atsekamumą.

Neatidėliotinas kitas žingsnis yra išbandyti pranešimo vadovą. Lygiagrečiai reikalaukite, kad kita produkto versija turėtų susietą taikymo srities sprendimą, aktualų rizikos vertinimą, komponentų inventorių ir saugumo patvirtinimą. Taip sukuriama pakartojama inžinerinė praktika, kol vyksta pasirengimas atitikties vertinimui.