Kiberizturības akts: iekļaujiet pienākumus produktu izstrādē

Kiberizturības akts (CRA) ievieš kiberdrošības pienākumus aptverto produktu ar digitāliem elementiem dzīves ciklā. Tehnoloģiju direktoram praktiskais uzdevums ir sasaistīt to, ko inženieri izstrādā, piegādā un uztur, ar pierādījumiem, kas nepieciešami šo pienākumu izpildes apliecināšanai.

Šai saiknei jādarbojas produkta un versijas līmenī. Visa uzņēmuma drošības politika nepaskaidro, vai konkrētai laidienam ir droši noklusējuma iestatījumi, kādas atkarības tas satur vai kā klienti saņems drošības atjauninājumu. Ievainojamības pieteikums, kas atzīmēts kā „novērsts”, nenosaka, kuras atbalstītās versijas joprojām ir pakļautas riskam.

Tāpēc noderīgs sākumpunkts ir produkta dzīves cikla modelis: tvērums, drošības prasības, laidiena pierādījumi, ievainojamību apstrāde, atbalsta saistības un atbildīgi lēmumi. Iebūvējiet šo modeli izstrādē, nevis veidojiet to atsevišķi pirms novērtējuma.

Definējiet produkta robežu, pirms piešķirat kontroles

CRA attiecas uz tā tvērumā esošiem produktiem ar digitāliem elementiem, tostarp aptverto aparatūru un programmatūru. Tas nav universāls noteikums katram SaaS pakalpojumam. Mitinātam pakalpojumam un klientiem izplatītai programmatūrai var būt nepieciešamas atšķirīgas analīzes, un jāpārbauda arī produktam neatņemama attālinātā datu apstrāde.

Izmantojiet Eiropas Komisijas CRA norādījumus kā sākotnējo atsauci, pēc tam atrisiniet produktam specifiskos juridiskos jautājumus. Reģistrējiet secinājumu, nevis paļaujieties uz komandas neformālu pieņēmumu.

Katram kandidātproduktam nosakiet:

• Ko klienti saņem: aparatūru, instalētu programmatūru, lejupielādējamus komponentus vai to kombināciju.
• Kuras attālinātās datu apstrādes funkcijas ir nepieciešamas, lai produkts veiktu savas funkcijas.
• Kā produkts tiek piegādāts ES tirgum un kura juridiskā persona to piegādā.
• Jūsu kā uzņēmēja lomu: ražotājs, importētājs, izplatītājs vai cita attiecīga loma.
• Piemērojamos izņēmumus, produktiem specifiskos tiesību aktus un atvērtā pirmkoda apsvērumus.
• Produkta kategoriju un no tās izrietošās atbilstības novērtēšanas prasības.

Atvērtajam pirmkodam nepieciešama īpaša uzmanība. Tas, kā tiek traktēta programmatūra, kas piegādāta ārpus komercdarbības, nenozīmē, ka komerciāls ražotājs var ignorēt tā produktā iegultos atvērtā pirmkoda komponentus. Nošķiriet augšupējā līdzstrādnieka pozīciju no jūsu atbildības par produktu, ko piegādājat.

Inženiertehniskajam nodevumam jābūt īsam tvēruma ierakstam ar arhitektūras diagrammu, produktu identifikatoriem, attiecīgajām komerciālajām juridiskajām personām, pieņēmumiem un apstiprinātu secinājumu. Nosauciet personu, kas atbild par šī secinājuma atkārtotu izskatīšanu, kad mainās funkcionalitāte vai izplatīšana.

Piemēram, lejupielādējamai pārvaldības lietotnei un tās mitinātajam analītikas pakalpojumam nevajadzētu automātiski saņemt vienu nediferencētu tvēruma lēmumu. Identificējiet, kuras funkcijas darbojas lokāli, kuras ir atkarīgas no pakalpojuma un vai šī attālinātā apstrāde ietilpst produkta robežās. Šī atšķirība ietekmē riska novērtējumu, atkarību ierakstus un atbildību par incidentiem.

Strādājiet, balstoties uz pašreizējiem ieviešanas datumiem

Komisija nosaka 2026. gada 11. septembri ziņošanas pienākumiem un 2027. gada 11. decembri galvenajām CRA prasībām. 2026. gada 7. oktobrī ziņošanas datums jau ir pagājis. Uztveriet gatavību ziņošanai kā pašreizēju darbības prasību, nevis uzdevumu, kas atlikts līdz atbilstības sagatavošanai.

Uzturiet redzamus divus darba virzienus:

Produktiem, kas piegādāti pirms galvenās piemērošanas datuma, jāpievērš uzmanība pārejas noteikumiem un būtiskām modifikācijām. Nepieņemiet, ka vecāks produkts nav būtisks ziņošanai tikai tāpēc, ka tā sākotnējais laidiens bija pirms 2027. gada decembra.

Uzturiet datētu juridisko prasību reģistru. Notikumu sliekšņiem, pakāpeniskiem ziņošanas termiņiem, saņēmējiem un iesniegšanas procedūrām pārbaudiet pašreizējo tiesību akta tekstu un oficiālos ieviešanas norādījumus. Neaizstājiet CRA specifisko procesu ar vispārīgu incidentu reaģēšanas veidni.

Pārvērtiet drošības prasības projektēšanas un laidiena kritērijos

CRA būtiskās prasības aptver produktu drošības īpašības un ievainojamību apstrādi. To ieviešanai jāseko produkta kiberdrošības riska novērtējumam, nevis universālam kontrolsarakstam, kas piemērots bez arhitektūras konteksta.

Sāciet ar to, kā produkts var radīt kaitējumu. Aprakstiet lietotājus, izvietošanas vides, atklātās saskarnes, priviliģētās operācijas, sensitīvos datus un paredzamu ļaunprātīgu izmantošanu. Iekļaujiet klienta darbības pieņēmumus: rūpnieciskā tīklā izvietotai iekārtai ir citāda atklātība un atjaunošanas ierobežojumi nekā darbvirsmas utilītai.

Šo darbu var atbalstīt praktisks draudu modelēšanas vingrinājums; OWASP draudu modelēšanas norādījumi piedāvā iedibinātu pieeju. Rezultātam jāsasaista draudi ar konkrētām prasībām, ieviešanas lēmumiem un testiem.

Apsveriet, kā pazīstamas prasības kļūst testējamas:

Šie ir praktiski ieviešanas piemēri, nevis piemērojamo prasību aizstājējs. Nosakiet atbilstību un pietiekamību ar riska novērtējuma palīdzību.

Pievienojiet drošības pieņemšanas kritērijus funkciju izstrādei. Jaunai administratīvai API jāienāk kopā ar lēmumiem par autentifikāciju, autorizāciju, ievaddatu apstrādi un žurnālēšanu, nevis ar solījumu, ka drošības komanda to pārbaudīs vēlāk. Pārskatiet draudu modeli, pievienojot attālinātu saskarni, priviliģētu komponentu vai jaunu uzticamības robežu.

Laidiena apstiprinājumā jāidentificē neatrisinātās ievainojamības, to izmantojamība, ietekmētās konfigurācijas un apstrāde. Piemērojiet CRA prasību darīt produktus pieejamus tirgū bez zināmām izmantojamām ievainojamībām, ņemot vērā riska novērtējumu un piemērojamās būtiskās prasības; riska reģistrēšana vai pieņemšana pati par sevi šo prasību neizpilda. Skenera rezultāts viens pats nevar pieņemt šo lēmumu: nozīme ir sasniedzamībai, priekšnosacījumiem un produkta uzvedībai. Un otrādi, zems skaitliskais smaguma vērtējums nav pietiekams iemesls ignorēt ievainojamību, kas jūsu izvietošanas modelī ir nozīmīga.

Laidiena ierakstam jāsasaista apstiprinātā pirmkoda revīzija, būvējuma artefakts, atkarību uzskaite, testu rezultāti un drošības lēmums. Tas padara novērtējumu atkārtojamu, kad klients vai iestāde vēlāk jautā par konkrētu versiju.

Padariet komponentu pienācīgu pārbaudi par būvēšanas procesa daļu

Trešo pušu komponenti rada pienākumus, kurus nevar izpildīt, pārsūtot augšupēju drošības paziņojumu. Jums jāsaprot, ko jūs piegādājāt, vai tas ir ietekmēts un kā to varat novērst.

CRA ievainojamību apstrādes prasībās ietver programmatūras materiālu saraksta prasību: plaši izmantotā, mašīnlasāmā formātā, kas aptver vismaz augstākā līmeņa atkarības. Kā praktisks ieteikums: apkopojiet dziļāku informāciju par atkarībām visur, kur jūsu būvēšanas rīki var sniegt uzticamus rezultātus. Tranzitīvās atkarības bieži nosaka atklātību.

SBOM ir noderīgs tikai tad, ja tas atbilst reālam produkta artefaktam. Sasaistiet to ar laidiena identifikatoru un būvējumu un nošķiriet piegādātos komponentus no tikai izstrādei paredzētiem rīkiem. Kur attiecināms, iekļaujiet programmaparatūru, operētājsistēmas pakotnes, iekļautās bibliotēkas un komerciālos komponentus; pakotņu pārvaldnieka eksportā vairāki no tiem var iztrūkt.

Veidojiet komponentu pārskatīšanu ap jautājumiem, kas maina inženiertehniskos lēmumus:

• Vai komponents tiek uzturēts, un vai tā atbalstītais kalpošanas laiks ir saderīgs ar mūsējo?
• Vai mēs varam savlaicīgi iegūt informāciju par ievainojamībām un drošības atjauninājumus?
• Vai mums ir piekļuve pirmkodam, piegādātāja ielāpu ceļš vai aizstāšanas stratēģija?
• Vai komponents ievieš priviliģētu izpildi vai jaunu ārēju savienojumu?
• Vai produktu joprojām var uzturēt, ja piegādātājs pārtrauc tā atbalstu?

Komerciāliem komponentiem iepirkumam jānosaka drošības kontakti, paziņošanas kārtība un piekļuve labojumiem. Piegādātāja termiņiem jāatstāj vieta jūsu pašu novērtējumam un ziņošanas pienākumiem. Produkta ražotājam joprojām nepieciešams iekšējs eskalācijas ceļš, ja piegādātāja atbilde ir nepilnīga.

Atvērtā pirmkoda atkarībām saglabājiet izcelsmes informāciju un reālistisku uzturēšanas plānu. Tas, ka repozitorijs ir publiski pieejams, nav pierādījums, ka kāds jūsu atbalsta perioda laikā izveidos saderīgu ielāpu.

Projektējiet atbalsta periodu un atjaunināšanas mehānismu kopā

Atbalsts ir inženiertehniska saistība ar komerciālām sekām. CRA parasti prasa vismaz piecu gadu atbalsta periodu, ja vien produkta paredzamais lietošanas laiks nav īsāks. Nosakiet piemērojamo periodu, izmantojot regulas kritērijus, nevis izvēloties patvaļīgu datumu, kas atbilst ceļvedim.

Reģistrējiet pamatojumu, paziņojiet klientiem nepieciešamo informāciju par atbalstu un sasaistiet to ar uzturētajām produkta versijām. Atbalsta saistībām jāņem vērā spēja piegādāt drošības atjauninājumus, nevis tikai jāsaglabā palīdzības dienesta adrese.

Pirms produkta atbalsta plāna apstiprināšanas pajautājiet, vai jūs varat:

• Pārbūvēt vecākus atbalstītos zarus ar uzturētām rīku ķēdēm.
• Droši izveidot, autentificēt un izplatīt drošības atjauninājumus.
• Testēt labojumus visās atbalstītajās aparatūras un izvietošanas konfigurācijās.
• Uzturēt parakstīšanas atslēgas un droši atjaunoties pēc atslēgas kompromitēšanas.
• Uzturēt pieejamu klientiem paredzēto informāciju par atjauninājumiem un drošību.
• Apstrādāt atkarības, kuru augšupējais atbalsts beidzas agrāk nekā jūsējais.

Drošības atjauninājumi atbalsta periodā parasti jānodrošina bez maksas, ievērojot regulas noteikumus. Katram šajā periodā izdotajam drošības atjauninājumam jāpaliek pieejamam vismaz desmit gadus pēc izdošanas vai atlikušo atbalsta perioda daļu, atkarībā no tā, kurš ir ilgāks. Plānojiet drošības labojumus atsevišķi no funkciju izstrādes, lai klienti netiktu nevajadzīgi spiesti pieņemt nesaistītas funkcionālas izmaiņas.

Pārbaudiet ne tikai veiksmīgo scenāriju. Pārtraukta instalēšana, nepietiekama krātuve, beigušies akreditācijas dati un neizdevusies verificēšana var pārvērst derīgu ielāpu par pieejamības problēmu. Izlemiet, kuri atjaunošanas mehānismi nepieciešami produkta riska profilam.

Atbalsta beigās klientu saziņai un iekšējiem ierakstiem jāsaskan. Neatstājiet lejupielādes lapu, kas liek domāt par turpmāku drošības uzturēšanu, ja produktu reģistrā teikts, ka saistības ir beigušās.

Izveidojiet ziņošanas rīcības rokasgrāmatu, kas iztur nenoteiktību

Parasts ievainojamības konstatējums, aktīvi izmantota ievainojamība un smags drošības incidents nav savstarpēji aizvietojami. CRA ziņošanas procesam nepieciešams dokumentēts attiecīgā ierosinātāja novērtējums, nevis automātiska ziņošana par katru skenera brīdinājumu un nevis automātiska jebkā noraidīšana bez pabeigtas tiesu ekspertīzes izmeklēšanas.

Rokasgrāmatai jāsākas ar pieņemšanu. Pētniekiem, klientu atbalstam, piegādātājiem un inženieru komandām nepieciešams zināms ceļš uz produktu drošības funkciju. Saglabājiet sākotnējo ziņojumu un reģistrējiet, kad attiecīgā informācija kļuva zināma; neatiestatiet uzzināšanas laika zīmogus, kad pieteikums pāriet citai komandai.

Notikumiem, par kuriem, iespējams, jāziņo, apkopojiet:

• Produktu identifikatorus un ietekmētās atbalstītās versijas.
• Pierādījumus par izmantošanu vai incidenta ietekmi, ar ticamības pakāpi un neskaidrībām.
• Zināmos uzbrukuma nosacījumus, ietekmētās funkcijas un izvietošanas pieņēmumus.
• Pieejamos mazināšanas pasākumus un korektīvo pasākumu statusu.
• Ierosinātāja novērtējumu, ziņošanas īpašnieku un piemērojamo termiņu aprēķinus.
• Iesniegtos paziņojumus, apstiprinājumus, turpmākos atjauninājumus un saziņu ar klientiem.

Pārbaudiet pakāpeniskos paziņošanas termiņus, galīgā ziņojuma prasības, saņēmējus un pašreizējo ziņošanas procedūru, salīdzinot ar oficiāliem avotiem. Aktīvi izmantotām ievainojamībām un smagiem incidentiem ir atšķirīgas ziņošanas detaļas; viens nokopēts termiņa lauks nav pietiekams.

Ieceliet galveno ziņošanas īpašnieku un aizvietotāju ar pilnvarām koordinēt inženiertehnisko, juridisko un klientu saziņu. Iepriekš sagatavojiet piekļuvi piemērojamajam ziņošanas mehānismam. Juridiskai pārskatīšanai jābūt pieejamai ziņošanas loga ietvaros, nevis jākļūst par neierobežotu apstiprināšanas rindu.

Izmēģiniet procesu ar nepilnīgu informāciju. Noderīgs mēģinājums sākas ar ticamu ziņojumu par izmantošanu, nenoteiktu ietekmēto versiju sarakstu un nepieejamu komponenta piegādātāju. Komandai jāspēj pieņemt savlaicīgu, dokumentētu ziņošanas lēmumu, kamēr izmeklēšana turpinās.

CRA ziņošana neaizstāj citus piemērojamos pienākumus. Produkta notikumam var būt nepieciešams arī novērtējums saskaņā ar datu aizsardzības tiesību aktiem vai klienta līgumu. Koordinējiet šos novērtējumus, bet saglabājiet to atsevišķos ierosinātājus, saņēmējus un lēmumu ierakstus.

Apstipriniet klasifikāciju, pirms izvēlaties novērtēšanas plānu

Produkta klasifikācija ietekmē pieejamo atbilstības novērtēšanas ceļu. Nepieņemiet, ka katram pieslēgtam produktam nepieciešams viens un tas pats ārējais novērtējums vai ka katrs ražotājs var paļauties uz iekšēju novērtējumu.

Nosakiet piemērojamo kategoriju pēc produkta funkcijām un regulas definīcijām un pielikumiem. Pēc tam apstipriniet atļauto ceļu, tostarp jebkādus nosacījumus, kas saistīti ar saskaņotajiem standartiem, atzītām specifikācijām, sertifikācijas shēmām vai trešās puses novērtējumu.

Standartu plānošanai nepieciešams skaidrs atkarību reģistrs: kuras atsauces ir piemērojamas, kāds ir to pašreizējais statuss un kas mainās, ja paredzētais ceļš nav pieejams. Izvairieties no laidiena plāna, kas ir atkarīgs no neapstiprināta pieņēmuma par standartiem vai novērtēšanas kapacitāti.

Pārskatiet klasifikāciju, kad mainās funkcionalitāte. Drošības pārvaldības vai tīkla kontroles spēju pievienošana var ietekmēt analīzi, taču funkcijas nosaukums vien nenosaka kategoriju. Novērtējiet faktisko funkciju un dokumentējiet secinājumu.

Uzturiet klasifikāciju, izvēlēto ceļu un atbilstības nodevumus saistītus ar tehnisko dokumentāciju. CE marķējumam un atbilstības deklarācijai jāseko piemērojamajam procesam; tie neaizstāj pamatā esošo prasību ieviešanu.

Uzturiet pierādījumu paketi, kas var izskaidrot laidienu

Tehniskajai dokumentācijai jāapraksta gan produkts, gan tā drošības lēmumu pamatojums. Saglabājiet riska novērtējumus un dokumentāciju, produktam mainoties, un piemērojiet likumā noteiktās glabāšanas prasības attiecīgajiem ierakstiem.

Noderīgā produkta pierādījumu paketē ietilpst tvēruma lēmums, arhitektūra, riska novērtējums, drošības prasības, informācija par komponentiem, verificēšanas rezultāti, ievainojamību apstrādes procedūras, atbalsta pamatojums un atbilstības ieraksti. Katram elementam nepieciešams īpašnieks un identificējama versija.

Izmantojiet stabilus identifikatorus, lai sasaistītu šos ierakstus. Ievainojamības ierakstam jāpaskaidro ietekmētās versijas, atklātība, apstrāde, laidiens un nepieciešamā saziņa. „Novērsts” bez versijas konteksta atstāj produkta pierādījumus nepilnīgus.

Esošie ISMS procesi var sniegt noderīgus pierādījumus par pārvaldību, piegādātājiem un drošu izstrādi. Tomēr ISO 27001 attiecas uz noteikta tvēruma informācijas drošības pārvaldības sistēmu; sertifikācija nepierāda atsevišķa produkta atbilstību CRA. Izmantojiet atkārtoti attiecīgos pierādījumus, neuzskatot ietvaru kartējumus par juridisku līdzvērtību.

Praktisks piemērs: atkarības trūkums atbalstītā iekārtā

Apsveriet ilustratīvu ražotāju, kas ES piegādā tīklam pieslēgtu iekārtu. Pieņemsim, ka tās tvērums un klasifikācija ir pārskatīti, divi laidienu zari joprojām tiek atbalstīti un par iekļautu bibliotēku ziņots, ka tā citur tiek aktīvi izmantota uzbrukumos.

Pirmais uzdevums nav slēgt augšupējo brīdinājumu. Inženieri identificē, kuri iekārtas būvējumi satur ievainojamo bibliotēku un vai ietekmētā funkcija ir sasniedzama. SBOM liecina, ka tā ir abos zaros, taču konfigurācijas analīze rāda atšķirīgu atklātību. Šī atšķirība tiek reģistrēta kopā ar pamatojošiem pierādījumiem.

Pēc tam produktu drošības īpašnieks novērtē, vai pieejamie fakti atbilst piemērojamajam CRA ziņošanas ierosinātājam. Nenoteiktība par vienu izvietošanas konfigurāciju tiek reģistrēta; tā neattaisno lēmuma īpašnieka nenosaukšanu. Ziņošanas rīcības rokasgrāmata sniedz pašreizējos paziņošanas posmus un procedūru.

Inženieri izstrādā pagaidu mazināšanas pasākumu un ielāpotu būvējumu katram ietekmētajam zaram. Testi aptver ievainojamo ceļu, parastu darbību un autentificētu atjauninājuma instalēšanu. Ja vienā zarā nevar izmantot augšupējo ielāpu, komanda reģistrē tā alternatīvo apstrādi un atlikušo risku, nevis atzīmē visu produktu kā novērstu.

Saziņā ar klientiem tiek norādītas ietekmētās versijas, tūlītējās aizsardzības darbības un tas, kā iegūt atjauninājumu. Atklāšanas laiks tiek saskaņots ar piemērojamajām ievainojamību apstrādes prasībām un jebkuriem pamatotiem drošības apsvērumiem.

Pabeigtais ieraksts sasaista brīdinājumu, ietekmēto būvējumu analīzi, ziņošanas lēmumu, iesniegumus, ja tie nepieciešami, ielāpu iesūtījumus, testu rezultātus, laidiena artefaktus un saziņu. Pārskatītājs tagad var rekonstruēt gan inženiertehnisko reakciju, gan atbilstības lēmumu.

Sāciet ar vienu produktu un vienu pilnīgu pierādījumu ķēdi

Izvēlieties reprezentatīvu atbalstītu produktu un izsekojiet vienu nesenu laidienu un vienu ievainojamību cauri dzīves ciklam. Trūkstošas saites uz versijām, neskaidras atbalsta saistības un nepieejamas ziņošanas procedūras ātri kļūs redzamas. Pārvērtiet katru robu uzdevumā ar īpašnieku, pēc tam paplašiniet modeli visā portfelī.

Secani var atbalstīt šo pierādījumu darbplūsmu, sasaistot prasības, pierādījumus, īpašniekus, uzdevumus un pārskatīšanas lēmumus. Inženiertehniskie rīki paliek darbības avoti būvējumiem, laidieniem un ievainojamībām; atbilstības darbvieta saista šos ierakstus ar piemērojamo pienākumu. Saglabājiet cilvēka apstiprinājumu skaidru kartējumiem un secinājumiem un saglabājiet izsekojamību līdz avotiem, izmantojot MI atbalstītus melnrakstus.

Tūlītējais nākamais solis ir pārbaudīt ziņošanas rīcības rokasgrāmatu. Paralēli pieprasiet, lai nākamajam produkta laidienam būtu piesaistīts tvēruma lēmums, aktuāls riska novērtējums, komponentu uzskaite un drošības apstiprinājums. Tas izveido atkārtojamu inženiertehnisko praksi, kamēr turpinās atbilstības sagatavošana.