CRA 2026: produkta drošības lieta ar ISO 27001
Savienotu ierīču ražotājs piektdienas pēcpusdienā sasauc sanāksmi ar savu galveno informācijas drošības vadītāju Mariju. Pārdošanas komanda tikko ir nodrošinājusi Eiropas izplatīšanas līgumu. Juridiskais dienests jautā, vai uzņēmums var pamatot atbilstību Kibernoturības aktam. Inženierijas komanda norāda, ka droša izstrāde ir “pamatā nosegta”, jo tiek veikta koda pārskatīšana, SAST un ielāpu uzstādīšana. Iepirkums saka, ka piegādātāji ir “pakļauti NDA”. Produktu komandām aparātprogrammatūras atkarības atrodas vienā rīkā, mākoņpakalpojumu API uzskaite — citā, bet ievainojamību pieteikumi — Jira. Atbilstības funkcijai ir ISO/IEC 27001:2022 sertifikācijas pierādījumi, taču tie ir strukturēti ap korporatīvo IDPS, nevis ap katru produktu, kas tiek laists ES tirgū.
Tad seko neērtais jautājums: “Ja ES iestāde, klients, paziņotā struktūra vai nozīmīgs izplatītājs 2026. gadā pieprasīs produkta drošības lietu, vai mēs to varēsim sagatavot vienas nedēļas laikā?”
Daudziem programmatūras piegādātājiem, viedierīču ražotājiem un savienotu pakalpojumu sniedzējiem godīga atbilde ir — nē. Ne tāpēc, ka tiem nebūtu drošības kontroles pasākumu, bet tāpēc, ka produkta drošības pierādījumi ir izkliedēti. Drošas izstrādes ieraksti atrodas pie inženierijas komandas. SBOM tiek ģenerēti katram būvējumam, bet netiek pārvaldīti. Koordinēta ievainojamību izpaušana pastāv kā tīmekļa lapa, bet ne vienmēr ir sasaistīta ar triāžu, labojumiem, paziņojumiem un pēctirgus uzraudzību. Piegādātāju drošība ir paslēpta iepirkuma līgumos. Ziņošana par incidentiem pieder drošības operācijām, savukārt atbilstības dokumentācija — produktu atbilstības funkcijai.
ES Kibernoturības akts maina darbības modeli. Produkta kiberdrošība vairs nav tikai labā prakse vai līgumiska solījuma jautājums. Tā kļūst par dzīves cikla pierādījumu pienākumu. Organizācijām jāspēj parādīt, kā kiberdrošības prasības ir iestrādātas projektēšanā, izstrādē, izlaišanā, ievainojamību apstrādē, atjauninājumos un uzraudzībā pēc produkta laišanas tirgū.
Tieši šeit ISO/IEC 27001:2022 kļūst īpaši noderīgs, ja to izmanto pareizi. Tas pats par sevi nav produkta sertifikācijas shēma, taču tā IDPS, risku, aktīvu, piegādātāju, drošas izstrādes, ievainojamību un incidentu kontroles pasākumi var veidot CRA produkta drošības lietas pamatu. Mērķis nav radīt vēl vienu atbilstības silosu. Mērķis ir pārveidot esošo IDPS par produkta līmeņa pierādījumu sistēmu.
Kā Clarysec Zenith Blueprint: auditora 30 soļu ceļkarte norāda 2. fāzes 8. solī par pierādījumu arhitektūru:
“Pierādījumi nav jāvāc audita cikla beigās. Tie jāiestrādā pašā kontroles pasākumā, jāpiešķir īpašniekam, procesam jāpiešķir laikspiedols, un tiem jābūt atkārtoti izmantojamiem visām prasībām, kas dažādos vārdos uzdod vienu un to pašu jautājumu.”
Šis teikums precīzi raksturo CRA gatavības būtību. Jautājums nav tikai: “Vai mums ir droša izstrāde?” Jautājums ir: “Vai mēs varam pierādīt drošu izstrādi, komponentu pārzināšanu, ievainojamību apstrādi un pēctirgus uzraudzību šim produktam, šai versijai, šim laidienam un šim tirgum?”
CRA produkta drošības lieta ir dzīva pierādījumu sistēma
CRA produkta drošības lietu nedrīkst uztvert kā statisku PDF dokumentu, kas vienreiz sagatavots pirms izlaišanas un pēc tam aizmirsts. Tai jābūt strukturētai lietai, kas parāda produkta drošības stāstu no ieceres līdz atbalsta beigām.
Noderīga lieta paskaidro:
- Kas ir produkts un kā tas paredzēts lietošanai.
- Kādu programmatūru, aparātprogrammatūru, mākoņpakalpojumus un trešo pušu atkarības tas ietver.
- Kādi kiberdrošības riski tika izvērtēti.
- Kādas drošības prasības tika piemērotas.
- Kā tika veikta droša izstrāde.
- Kā ievainojamības tiek saņemtas, triāžētas, novērstas un izpaustas.
- Kā tiek piegādāti droši atjauninājumi.
- Kā tiek kontrolēti piegādātāji un atvērtā pirmkoda komponenti.
- Kā tiek eskalēti incidenti un aktīvi izmantotas ievainojamības.
- Kā produkts tiek uzraudzīts pēc laišanas tirgū.
CISO tas ir IDPS pierādījumu izaicinājums. Produkta atbilstības vadītājam tā ir tehniskā dokumentācija. Inženierijai tā ir DevSecOps un laidienu pārvaldība. Vadībai tā ir piekļuve tirgum un atbildības kontrole.
Kļūda ir uztvert šīs jomas kā atsevišķas darba plūsmas. Labāks modelis ir izveidot produkta līmeņa pierādījumu lietu, kas sasaistīta ar ISO/IEC 27001:2022 un ISO/IEC 27002:2022 kontroles pasākumiem, un pēc tam to pašu pierādījumu kopumu krusteniski sasaistīt ar NIS2, DORA, GDPR, NIST un COBIT 2019, ja tas ir piemērojams.
Clarysec Zenith Controls: starpatbilstības ceļvedis to raksturo kā ķēdi no kontroles pasākuma uz pierādījumu un auditoru:
“Starpatbilstības pierādījumu lietā katrs pienākums jāsasaista ar darbībā esošu kontroles pasākumu, atkārtojamu pierādījumu objektu, atbildīgo īpašnieku un audita prizmu, ar kuru tas tiks apstrīdēts.”
Tieši šāda disciplīna ir vajadzīga CRA sagatavošanai. Produkta drošības lieta nav tikai mape. Tā ir tulkošanas kārta starp produkta inženieriju, drošības pārvaldību, atbilstības novērtēšanu un klientu apliecinājumu.
Vispirms izveidojiet produkta pierādījumu mugurkaulu
Pirms komandas sāk augšupielādēt ierakstus, lietai ir vajadzīga konsekventa struktūra. Bez skaidra mugurkaula pierādījumi kļūst par ekrānuzņēmumu, eksportu un politiku PDF dokumentu kaudzi, ko auditors nevar izsekot.
CRA gatavības darbnīcās Clarysec parasti iesaka šādu produkta drošības lietas struktūru organizācijām, kurās jau darbojas ISO/IEC 27001:2022 IDPS.
| Produkta drošības lietas sadaļa | Primārie pierādījumi | ISO/IEC 27001:2022 un ISO/IEC 27002:2022 kontroles pasākumu tēmas | Tipiskais īpašnieks |
|---|---|---|---|
| Produkta definīcija un paredzētais lietojums | Produkta apraksts, arhitektūra, datu plūsma, izvietošanas modelis | A.5.9 Informācijas un citu saistīto aktīvu uzskaite, A.5.8 Informācijas drošība projektu vadībā, risku izvērtēšana | Produkta īpašnieks |
| Komponentu un atkarību uzskaite | SBOM, aparātprogrammatūras materiālu saraksts, mākoņpakalpojumu atkarību karte | A.5.9 Uzskaite, A.8.9 Konfigurāciju pārvaldība, A.8.8 Tehnisko ievainojamību pārvaldība | Inženierijas vadītājs |
| Drošas izstrādes pierādījumi | Draudu modeļi, droša dizaina pārskatīšanas, koda pārskatīšanas ieraksti, drošības testēšanas rezultāti | A.8.25 Drošas izstrādes dzīves cikls, A.8.27 Droša sistēmu arhitektūra un inženierijas principi, A.8.28 Droša kodēšana, A.8.29 Drošības testēšana izstrādē un akceptēšanā | Inženierija un AppSec |
| Ievainojamību apstrāde un CVD | Izpaušanas politika, saņemšanas ieraksti, triāžas žurnāli, labojumu SLA, paziņojumu veidnes | A.8.8 Tehnisko ievainojamību pārvaldība, A.5.24 Informācijas drošības incidentu pārvaldības plānošana un sagatavošanās, A.5.26 Reaģēšana uz informācijas drošības incidentiem | Drošības operācijas |
| Piegādātāju un atvērtā pirmkoda pierādījumi | Piegādātāju izvērtējumi, līgumiskās klauzulas, OSS pārskatīšana, komponentu izcelsme | A.5.19 Informācijas drošība attiecībās ar piegādātājiem, A.5.20 Informācijas drošības prasību iekļaušana piegādātāju līgumos, A.5.21 Informācijas drošības pārvaldība IKT piegādes ķēdē | Iepirkums un juridiskais dienests |
| Drošu atjauninājumu un laidienu pierādījumi | Laidienu apstiprinājumi, parakstīšanas ieraksti, izmaiņu atcelšanas plāni, ielāpu piezīmes | A.8.32 Izmaiņu pārvaldība, A.8.24 Kriptogrāfijas izmantošana, A.8.9 Konfigurāciju pārvaldība | Laidienu pārvaldnieks |
| Pēctirgus uzraudzība | Ievainojamību plūsmas, telemetrija, klientu ziņojumi, incidentu pārskatīšana, periodiska risku pārskatīšana | A.8.15 Žurnālfiksēšana, A.8.16 Uzraudzības darbības, A.5.25 Informācijas drošības notikumu izvērtēšana un lēmumu pieņemšana, nepārtraukta uzlabošana | Galvenais informācijas drošības vadītājs un produkta drošība |
| Atbilstības un audita pakotne | Kontroles pasākumu kartējums, vadības apstiprinājums, glabāto pierādījumu indekss | IDPS pārvaldība, A.5.28 Pierādījumu vākšana, iekšējais audits, vadības pārskatīšana | Atbilstības vadītājs |
Šī tabula neaizstāj juridiskās tehniskās dokumentācijas pienākumus. Tā uzņēmumam dod darbības modeli šo pienākumu pierādīšanai.
Zenith Blueprint 1. fāzes 3. solis koncentrējas uz piemērošanas jomas un robežu definēšanu. CRA kontekstā šis solis kļūst produktspecifisks. Definējiet produktu saimi, programmatūras versijas, izvietošanas pieņēmumus, lietotāju lomas, savienotos pakalpojumus, atjauninājumu kanālus un atbalsta periodu. Ja IDPS darbības joma ir “korporatīvais SaaS un ierīču pārvaldības platforma”, CRA lietai joprojām jāatbild uz šaurāku jautājumu: “Kurš produkts ar digitāliem elementiem tiek laists ES tirgū, un kas ietilpst šajā produktā?”
Sasaistiet drošu izstrādi ar produkta līmeņa ierakstiem
Produkta drošības lietas pamatā ir pierādījumi par drošību pēc projektēšanas. ISO/IEC 27001:2022 nodrošina pārvaldības sistēmu. ISO/IEC 27002:2022 nodrošina ieviešanas vadlīnijas, izmantojot tādus kontroles pasākumus kā A.8.25 Drošas izstrādes dzīves cikls, A.8.27 Droša sistēmu arhitektūra un inženierijas principi, A.8.28 Droša kodēšana un A.8.29 Drošības testēšana izstrādē un akceptēšanā.
Svarīgā pāreja ir no vispārīgiem apgalvojumiem par drošu izstrādi uz laidienam specifiskiem ierakstiem. Ar “mēs veicam koda pārskatīšanu” nepietiek. Lietai jāparāda, kurš laidiens tika pārskatīts, kādi riski tika ņemti vērā, kuri drošības testi tika sekmīgi izpildīti, kuras ievainojamības tika pieņemtas vai novērstas un kurš apstiprināja laidienu.
Clarysec Enterprise Drošas izstrādes politika ir izstrādāta, lai nodrošinātu šo pierādījumu pēdu. Tās 6.1. punktā “Drošas izstrādes dzīves cikla prasības” noteikts:
“Katram produkta vai pakalpojuma laidienam pirms nodošanas ražošanas vidē jāuztur dokumentēti pierādījumi par drošības prasībām, dizaina pārskatīšanu, drošas kodēšanas darbībām, drošības testēšanu, lēmumiem par ievainojamību novēršanu un laidiena apstiprinājumu.”
Šis punkts CRA vajadzībām ir noderīgs, jo pārvērš drošu izstrādi atkārtojamā pierādījumu modelī. Auditoram nav jāsecina, ka droša izstrāde notika. Viņš var pārbaudīt laidiena ierakstu.
Viedajam termostatam, medicīniskai IoT ierīcei, industriālam sensoram vai ar SaaS savienotam produktam drošas izstrādes pierādījumos jāietver:
- Produkta drošības prasības, kas sasaistītas ar identificētajiem riskiem.
- Draudu modelis vai ļaunprātīgas izmantošanas gadījumu analīze produktam un savienotajiem pakalpojumiem.
- Arhitektūras pārskatīšana, tostarp uzticamības robežas un ārējās saskarnes.
- Drošas kodēšanas standarts un pierādījums par izstrādātāju apliecinājumu vai apmācību.
- SAST, DAST, programmatūras sastāva analīze, noslēpumu skenēšana un aparātprogrammatūras analīze, ja piemērojams.
- Trūkumu novēršanas pieteikumi augsta riska konstatējumiem.
- Riska pieņemšanas ieraksti ar biznesa un drošības apstiprinājumu.
- Laidiena vārtu kontrolsaraksts, kas parāda, ka drošības kritēriji ir izpildīti.
- Kriptogrāfiskās parakstīšanas un atjauninājumu integritātes pierādījumi.
- Atbalsta perioda un dzīves cikla beigu pieņēmumi.
Citi standarti palīdz nostiprināt metodi. ISO/IEC 27005 atbalsta riskos balstītu pieeju, kas ir šo ierakstu pamatā. ISO/IEC 27017 ir noderīgs, ja mākoņpakalpojumi veido daļu no produkta ekosistēmas. ISO/IEC 27035 atbalsta incidentu apstrādi. ISO/IEC 29147 un ISO/IEC 30111 ir īpaši nozīmīgi ievainojamību izpaušanai un ievainojamību apstrādei. ISO/IEC 27036 atbalsta piegādātāju drošību, kas ir būtiski, ja produkts ietver ārpakalpojuma programmatūru, iegultus moduļus, pārvaldītus mākoņpakalpojumus vai trešo pušu bibliotēkas.
Zenith Controls CRA drošas izstrādes pierādījumi parasti tiek kartēti ap ISO/IEC 27002:2022 kontroles pasākumu tēmām, piemēram, informācijas drošību projektu vadībā, drošas izstrādes dzīves ciklu, drošu kodēšanu, drošības testēšanu, izmaiņu pārvaldību un tehnisko ievainojamību pārvaldību. Ceļvedis tos sasaista arī ar aktīvu uzskaiti un piegādātāju kontroles pasākumiem, jo neviens drošas izstrādes process nav pilnīgs, ja organizācija nevar identificēt komponentus, ko tā piegādā.
Uztveriet SBOM kā reglamentētus produkta pierādījumus
Software Bill of Materials bieži tiek uztverts kā tehnisks artefakts. CRA gatavībai tas jāuztver kā produkta pierādījums.
Noderīgs SBOM parāda, kādi komponenti ir produktā, kādas versijas tiek izmantotas, no kurienes tie nāk, kādas licences ir piemērojamas, kādas ievainojamības tos ietekmē un kuros laidienos tie ir iekļauti. Aparātprogrammatūras un iegulto produktu gadījumā tas var ietvert operētājsistēmas pakotnes, sāknētājus, bibliotēkas, draiverus, konteinerus, trešo pušu moduļus un mākoņpuses atkarības, kas nepieciešamas produkta darbībai.
Problēma ir tā, ka daudzas organizācijas SBOM ģenerē, bet tos nepārvalda. Būvēšanas konveijers var izveidot SPDX vai CycloneDX datni, bet neviens nevalidē pilnīgumu. Drošības rīki var atzīmēt ievainojamības, bet rezultāti nav sasaistīti ar produktu versijām. Iepirkums var apstiprināt piegādātāju, bet šī piegādātāja komponentu saraksts netiek salīdzināts ar izlaisto produktu.
Clarysec Enterprise Aktīvu pārvaldības politika risina šo pārvaldības trūkumu 5.2. punktā “Informācijas un saistīto aktīvu uzskaite”:
“Informācijas aktīvi un saistītie tehnoloģiju komponenti jāidentificē, tiem jāpiešķir īpašnieks, tie jāklasificē, ja piemērojams, un jāuztur uzskaitē, kas atbalsta risku izvērtēšanu, ievainojamību pārvaldību, izmaiņu kontroli un audita pierādījumus.”
CRA kontekstā šis punkts kļūst produktspecifisks. SBOM ir daļa no saistīto tehnoloģiju komponentu uzskaites. Tam ir vajadzīgs īpašnieks, glabāšanas noteikums, validācijas process un sasaiste ar ievainojamību pārvaldību.
Praktisks SBOM pierādījumu noteikums ir vienkāršs: katrai izlaistajai produkta versijai jābūt apstiprinātai komponentu uzskaitei, ko var sasaistīt ar laidiena artefaktu. Ja organizācija nevar savienot SBOM ar precīzu aparātprogrammatūras attēlu, lietotnes pakotni, konteinera digest vai SaaS laidienu, SBOM ir vājš pierādījums.
| Pārbaude | Vācamie pierādījumi | Izpildes kritēriji |
|---|---|---|
| Sasaiste ar laidienu | Laidiena ID, būvējuma hešs, aparātprogrammatūras versija, konteinera digest vai pakotnes ID | SBOM skaidri sasaistās ar izlaisto artefaktu |
| Komponentu pilnīgums | SBOM datne, atkarību skenēšanas pārskats, manuāli izņēmumi | Tiešās un pārejošās atkarības ir fiksētas vai izņēmumi ir pamatoti |
| Ievainojamību statuss | SCA pārskats, ievainojamību pieteikumi, riska pieņemšanas | Zināmi izmantojami vai augsta riska konstatējumi ir novērsti vai tiem ir apstiprināts izņēmums |
| Sasaiste ar piegādātāju | Piegādātāja komponentu deklarācijas, trešo pušu apliecinājumi, atbalsta noteikumi | Kritiskiem piegādātajiem komponentiem ir piegādātāja pierādījumi |
| Licence un izcelsme | Licenču skenēšana, pirmkoda repozitorija ieraksts, apstiprināts pakotnes avots | Komponenta izcelsme un izmantošana ir dokumentēta |
| Glabāšana un piekļuve | Pierādījumu repozitorija ceļš, īpašnieks, glabāšanas noteikums | Atbilstības funkcija var izgūt SBOM un saistītos ierakstus noteiktā laikā |
Ja vairāk nekā divas rindas neizpildās, problēma parasti nav SBOM rīks. Tā ir pārvaldība. Produkta drošības lietā jāreģistrē korektīvā darbība IDPS, jo CRA pierādījumu vājums vienlaikus ir arī ISO/IEC 27001:2022 kontroles efektivitātes jautājums.
Sasaistiet CVD ar ievainojamību apstrādi un laidienu pārvaldību
Koordinēta ievainojamību izpaušana ir viena no redzamākajām CRA gatavības jomām, jo ārējie pētnieki, klienti un iestādes var to tieši pārbaudīt. Ievainojamību izpaušanas lapas vai security.txt datnes publicēšana ir noderīga, taču tā ir tikai priekšdurvis. Produkta drošības lietai jāpierāda, ka aizmugures process darbojas.
Aizstāvamam CVD un ievainojamību apstrādes pierādījumu kopumam jāietver:
- Publisks izpaušanas kanāls un iesniegšanas norādījumi.
- Pētnieka ziņojuma saņemšanas apstiprinājuma process.
- Triāžas kritēriji, tostarp smaguma pakāpes un izmantojamības izvērtēšana.
- Produkta ietekmes analīze.
- Novēršanas atbildība un mērķa termiņi.
- Klientu paziņojumu un atjauninājumu komunikācijas veidnes.
- Pierādījumi par drošu ielāpu izstrādi un testēšanu.
- Koordinētas publicēšanas ieraksti, ja piemērojams.
- Gūtās atziņas un atkārtotu ievainojamību tendenču analīze.
Clarysec Enterprise Ievainojamību pārvaldības politika 6.3. punktā “Ievainojamību saņemšana, triāža un novēršana” noteikts:
“Par ziņotajām ievainojamībām jāizveido žurnāla ieraksti, tās jāizvērtē attiecībā uz ietekmētajiem aktīviem un produktiem, jāprioritizē atbilstoši riskam un izmantojamībai, jāpiešķir atbildīgajam īpašniekam un jāizseko līdz novēršanai, verifikācijai, komunikācijai un slēgšanai.”
Šis punkts sasaista CVD ar SBOM, aktīvu uzskaiti, inženierijas pieteikumiem, laidienu pārvaldību un pēctirgus uzraudzību. Tas ir arī punkts, ko auditori dabiski testēs: parādiet saņemšanas ierakstu, parādiet ietekmētos produktus, parādiet triāžu, parādiet labojumu, parādiet komunikāciju klientiem, parādiet slēgšanu.
Jūsu esošā Informācijas drošības incidentu pārvaldības politika jāpaplašina, lai aptvertu arī produkta ievainojamības, kas kļūst par incidentiem vai prasa ārēju paziņošanu. ISO/IEC 27002:2022 A.5.24 aptver incidentu pārvaldības plānošanu un sagatavošanos, A.5.25 aptver informācijas drošības notikumu izvērtēšanu un lēmumu pieņemšanu, A.5.26 aptver reaģēšanu uz informācijas drošības incidentiem, bet A.5.27 aptver mācīšanos no incidentiem.
Zenith Controls ievainojamību pārvaldība tiek skatīta gan kā preventīva, gan kā koriģējoša darbība. Preventīvā puse ietver uzskaiti, drošu izstrādi, piegādātāju uzraudzību un drošu konfigurāciju. Koriģējošā puse ietver atklāšanu, triāžu, ielāpu uzstādīšanu, komunikāciju un incidentu eskalāciju. Šis nošķīrums ir būtisks, jo pēctirgus ievainojamību apstrāde ir daļa no produkta dzīves cikla pienākuma, nevis pēcdoma.
Piegādātāju pierādījumi ir slēptais vājums
Produkta drošības lieta visbiežāk tiks visstingrāk apstrīdēta tur, kur ražotājs paļaujas uz citiem. Tas ietver iegultus moduļus, ārpakalpojuma aparātprogrammatūras izstrādi, white-label komponentus, mākoņpakalpojumu mitināšanu, mobilos SDK, maksājumu pakalpojumus, kriptogrāfiskās bibliotēkas un pārvaldīto atbalsta pakalpojumu sniedzējus.
Biežais neveiksmes modelis ir līgumiska abstrakcija. Ražotājs saka: “Par to ir atbildīgs mūsu piegādātājs.” Produkta drošības pārbaudē ar to nepietiek. Organizācijai jāparāda, ka piegādātāju risks ir identificēts, drošības prasības ir paziņotas, pierādījumi ir savākti, ievainojamības tiek koordinētas un izmaiņas tiek kontrolētas.
Clarysec Enterprise Trešo pušu un piegādātāju drošības politika 7.1. punktā “Piegādātāju drošības prasības” noteikts:
“Piegādātāji, kas izstrādā, ekspluatē, apstrādā, atbalsta vai būtiski ietekmē informācijas sistēmas, produktus vai pakalpojumus, jāizvērtē atbilstoši riskam, un tiem jāpiemēro drošības prasības, kas aptver piekļuvi, ievainojamību pārvaldību, paziņošanu par incidentiem, apakšuzņēmējus, nepārtrauktību un pierādījumu nodrošināšanu.”
CRA kontekstā frāze “būtiski ietekmē produktus” ir kritiska. Ja piegādātāja komponents var ieviest ievainojamību, traucēt atjauninājumus, atklāt klientu datus vai kompromitēt ierīces integritāti, tas pieder produkta drošības lietai.
Tā pati politika var atbalstīt arī SBOM prasības līgumos. 7.3. punktā noteikts:
“Par visiem trešo pušu programmatūras komponentiem, bibliotēkām vai operētājsistēmām, kas integrējamas uzņēmuma “produktos ar digitāliem elementiem”, piegādātājam pēc pieprasījuma jānodrošina mašīnlasāms Software Bill of Materials (SBOM) standarta formātā, piemēram, SPDX vai CycloneDX. Šī prasība jāiekļauj visos iepirkuma un piegādātāju līgumos.”
Spēcīgā piegādātāju pierādījumu pakotnē jāietver piegādātāju klasifikācija pēc ietekmes uz produktu, drošības prasības līgumos, piegādātāju drošas izstrādes pierādījumi kritiskiem komponentiem, piegādātāju ievainojamību izpaušanas saistības, SBOM vai komponentu deklarācijas, ja iespējams, ielāpu atbalsta un dzīves cikla beigu termiņi, periodiskas pārskatīšanas ieraksti un eskalācijas ceļi piegādātāju izcelsmes ievainojamībām.
ISO/IEC 27002:2022 A.5.19, A.5.20 un A.5.21 nodrošina galvenās piegādātāju kontroles pasākumu tēmas. ISO/IEC 27036 padziļina piegādātāju attiecību drošību. Starpatbilstības izteiksmē NIS2 uzsver piegādes ķēdi un ievainojamību apstrādi. DORA uzsver IKT trešo pušu risku finanšu struktūrām. GDPR kļūst piemērojams, ja produkts vai tā mākoņpakalpojumi apstrādā personas datus. COBIT 2019 piegādātāju pārvaldību ierāmē kā uzņēmuma tehnoloģiju pārvaldības jautājumu, ne tikai kā drošības operāciju jautājumu.
Pēctirgus uzraudzība pārvērš pierādījumus operācijās
Nobriedušākās produktu drošības organizācijas domā tālāk par laidienu. Tās jautā: “Kā mēs uzzināsim, ka šis produkts pēc nonākšanas lietošanā ir kļuvis riskants?”
Pēctirgus uzraudzībai jāaptver signāli no ievainojamību plūsmām, izmantošanas izlūkošanas, klientu atbalsta, telemetrijas, bug bounty vai pētnieku ziņojumiem, piegādātāju paziņojumiem, mākoņpakalpojumu žurnāliem, incidentu ierakstiem un ekspluatācijas veiktspējas datiem. Tai jāietver arī periodiska produkta risku pārskatīšana, ja mainās apdraudējumu vide.
Clarysec Enterprise Žurnālfiksēšanas un uzraudzības politika 5.4. punktā “Drošības uzraudzība un pārskatīšana” noteikts:
“Drošībai nozīmīgi notikumi jāapkopo, jāpārskata, jāeskalē un jāglabā tā, lai atbalstītu savlaicīgu atklāšanu, izmeklēšanu, reaģēšanu uz incidentiem, atbilstības ziņošanu un nepārtrauktu uzlabošanu.”
Savienotiem produktiem tas jāinterpretē rūpīgi. Uzraudzībai jāievēro privātums, datu minimizēšana un tiesiskie ierobežojumi, īpaši, ja telemetrija ietver personas datus vai klientu operacionālos datus. GDPR kartēšana ir svarīga. Produktu drošības komandām jāstrādā ar privātuma komandām, lai definētu, kāda telemetrija ir nepieciešama drošībai, kā tā tiek minimizēta, cik ilgi tā tiek glabāta un kā klienti tiek informēti.
Pēctirgus uzraudzības pierādījumos jāietver produkta drošības uzraudzības plāns, ievainojamību izlūkošanas avoti, klientu ziņojumu saņemšanas kanāli, piegādātāju paziņošanas kanāli, telemetrijas vai žurnālu pārskatīšanas tvērums, periodisko produkta risku pārskatīšanu protokoli, ielāpu ieviešanas izsekošana, incidentu tendenču analīze un vadības pārskatīšanas ievaddati.
Zenith Blueprint 5. fāzes 30. solis koncentrējas uz nepārtrauktu uzlabošanu un gatavību uzraudzībai. CRA kontekstā šeit produkta drošības lieta kļūst par dzīvu lietu. Katram produkta laidienam, ievainojamībai, piegādātāja izmaiņai un ekspluatācijas signālam jāatjaunina pierādījumu ieraksts.
Viena pierādījumu lieta, daudzi atbilstības jautājumi
Labi izstrādāta CRA produkta drošības lieta samazina dublēšanos, jo tie paši pierādījumi atbild uz vairākiem atbilstības jautājumiem. Valoda mainās, bet kontroles realitāte bieži ir līdzīga.
| Pierādījumu objekts | Nozīme CRA | ISO/IEC 27001:2022 un ISO/IEC 27002:2022 tēma | Nozīme NIS2, DORA, GDPR, NIST un COBIT 2019 |
|---|---|---|---|
| Produkta risku izvērtēšana | Parāda, ka drošības riski tika ņemti vērā produkta projektēšanā un dzīves ciklā | Risku izvērtēšana, A.5.8 Informācijas drošība projektu vadībā, A.8.25 Drošas izstrādes dzīves cikls | NIS2 risku pārvaldība, DORA IKT risku pārvaldība, NIST Govern un Identify, COBIT risku pārvaldība |
| SBOM un komponentu uzskaite | Parāda zināšanas par programmatūras komponentiem un pakļautību ievainojamībām | A.5.9 Uzskaite, A.8.9 Konfigurāciju pārvaldība, A.8.8 Tehnisko ievainojamību pārvaldība | NIS2 piegādes ķēde, DORA IKT aktīvu pārzināšana, NIST aktīvu pārvaldība, COBIT pārvaldītie aktīvi |
| Drošas izstrādes ieraksti | Parāda, ka drošība tika iestrādāta projektēšanā un laidienā | A.8.25 Drošas izstrādes dzīves cikls, A.8.27 Droša arhitektūra, A.8.28 Droša kodēšana, A.8.29 Drošības testēšana | NIST Protect, COBIT būvēšanas un izmaiņu pārvaldība, GDPR drošība pēc projektēšanas, ja iesaistīti personas dati |
| CVD un ievainojamību pieteikumi | Parāda spēju saņemt, izvērtēt, novērst un komunicēt ievainojamības | A.8.8 Tehnisko ievainojamību pārvaldība, A.5.24 Incidentu plānošana, A.5.26 Reaģēšana uz incidentiem | NIS2 ievainojamību apstrāde, DORA incidentu un ievainojamību procesi, NIST Respond |
| Piegādātāju pierādījumi | Parāda, ka produkta atkarības tiek pārvaldītas | A.5.19 Attiecības ar piegādātājiem, A.5.20 Piegādātāju līgumi, A.5.21 IKT piegādes ķēde | NIS2 piegādes ķēdes drošība, DORA IKT trešo pušu risks, COBIT piegādātāju pārvaldība |
| Pēctirgus uzraudzība | Parāda nepārtrauktu produkta drošības pārraudzību | A.8.15 Žurnālfiksēšana, A.8.16 Uzraudzības darbības, A.5.25 Notikumu izvērtēšana, nepārtraukta uzlabošana | NIS2 incidentu atklāšana, DORA uzraudzība, NIST Detect, GDPR pārkāpumu atklāšanas atbalsts |
| Ziņošanas par incidentiem ieraksti | Parāda gatavību eskalācijai un paziņošanai | A.5.24 Incidentu plānošana, A.5.25 Notikumu izvērtēšana, A.5.26 Reaģēšana uz incidentiem, A.5.27 Mācīšanās no incidentiem | NIS2 un DORA ziņošana, GDPR pārkāpuma izvērtēšana, NIST Respond un Recover |
Zenith Controls ir izstrādāts šādai atkārtotai izmantošanai. Tas kartē ISO/IEC 27002:2022 kontroles pasākumu tēmas uz tādiem atribūtiem kā preventīvs, atklājošs un koriģējošs kontroles mērķis, kiberdrošības koncepcijas, operacionālās spējas un drošības īpašības. CRA kontekstā tas palīdz CISO paskaidrot, kāpēc viens pierādījumu objekts, piemēram, laidiena drošības pārskatīšana, atbalsta drošu izstrādi, riska apstrādi, izmaiņu kontroli, ievainojamību pārvaldību un gatavību auditam.
Sagatavojieties dažādām auditoru perspektīvām
CRA produkta drošības lietu var apstrīdēt ISO auditors, iekšējā audita komanda, klientu apliecinājuma komanda, produkta atbilstības pārskatītājs, regulators, uz NIST balstīts izvērtētājs vai ISACA apmācīts COBIT auditors. Katrs uzdos līdzīgus jautājumus caur atšķirīgu prizmu.
| Auditora prizma | Ko viņi jautās | Spēcīgi pierādījumi |
|---|---|---|
| ISO/IEC 27001:2022 auditors | Vai produkta drošība tiek pārvaldīta IDPS, risku procesā, kompetences modelī, darbības kontroles pasākumos un nepārtrauktas uzlabošanas ciklā? | IDPS darbības joma, risku izvērtēšana, Piemērojamības paziņojums, drošas izstrādes ieraksti, iekšējā audita konstatējumi, vadības pārskatīšana |
| ISO/IEC 27006-1:2024 sertifikācijas perspektīva | Vai audita pierādījumi ir uzticami, atbilstoši atlasīti un sasaistīti ar sertificēto pārvaldības sistēmu? | Pierādījumu indekss, izlases loģika, īpašnieku intervijas, glabātie ieraksti, korektīvo darbību izsekošana |
| Uz NIST orientēts izvērtētājs | Vai varat parādīt pārvaldību, aktīvu identificēšanu, aizsardzības pasākumus, atklāšanu, reaģēšanu un atjaunošanu produkta dzīves ciklam? | Produkta riska reģistrs, SBOM, uzraudzības plāns, ievainojamību darbplūsma, incidentu rokasgrāmatas |
| COBIT 2019 vai ISACA auditors | Vai produkta drošības mērķi tiek pārvaldīti, mērīti, tiem ir īpašnieks un tie ir saskaņoti ar uzņēmuma risku un vērtības nodrošināšanu? | RACI, metrikas, politiku apstiprinājumi, piegādātāju pārvaldība, vadības ziņošana, riska pieņemšana |
| Produkta atbilstības pārskatītājs | Vai tehniskā lieta parāda kiberdrošības prasības, dizaina kontroles pasākumus, ievainojamību apstrādi un pēctirgus uzraudzību produktam? | Produkta drošības lietas indekss, arhitektūra, SBOM, testēšanas pierādījumi, CVD ieraksti, atjauninājumu pierādījumi |
| Klienta drošības izvērtētājs | Vai varat pierādīt, ka produkts tiek droši izstrādāts un atbalstīts visā tā dzīves ciklā? | Drošas SDLC kopsavilkums, ielaušanās testēšanas kopsavilkums, ievainojamību izpaušanas process, ielāpu atbalsta politika, piegādātāju apliecinājums |
Tas pats vājais punkts tiks izgaismots atšķirīgi. Ja SBOM tiek ģenerēti, bet netiek glabāti, ISO auditors redz ierakstu kontroles un darbības kontroles problēmu. NIST izvērtētājs redz aktīvu un ievainojamību pārvaldības vājumu. COBIT auditors redz vāju informācijas aktīvu pārvaldību. Produkta pārskatītājs redz nepietiekamu tehnisko dokumentāciju.
30 soļu ceļkarte, pielāgota CRA gatavībai
Zenith Blueprint palīdz atbilstības komandām nepāriet uzreiz pie dokumentu vākšanas. CRA vajadzībām 30 soļu ceļkarte kļūst par produkta drošības pierādījumu programmu.
fāze sākas ar pienākumu un piemērošanas jomas kartēšanu. Identificējiet, kuri produkti, versijas, komponenti, mākoņpakalpojumi un atbalsta procesi ietilpst tvērumā. Apstipriniet paredzēto lietojumu, lietotāju kategorijas, tirgus un drošības atbalsta periodu.
fāze veido pierādījumu arhitektūru. Definējiet produkta drošības lietas indeksu, pierādījumu īpašniekus, glabāšanas prasības, repozitorija struktūru un apstiprināšanas darbplūsmu. Saskaņojiet to ar inženierijas sistēmām, nevis uzspiediet manuālas augšupielādes.
fāze ievieš darbības kontroles pasākumus. Drošai izstrādei, SBOM ģenerēšanai, ievainojamību apstrādei, piegādātāju pierādījumiem, laidiena vārtiem, drošiem atjauninājumiem un incidentu eskalācijai jādarbojas kā reāliem procesiem.
fāze testē gatavību auditam. Izvēlieties produkta laidienu un veiciet simulētu auditu. Vai komanda var izgūt SBOM? Vai tā var pierādīt drošības testēšanu? Vai tā var parādīt, kā ievainojamība tika triāžēta? Vai tā var sasaistīt piegādātāju pierādījumus ar produkta komponentiem?
fāze iestrādā uzraudzību un uzlabošanu. Pēctirgus uzraudzība, ievainojamību tendenču analīze, piegādātāju pārskatīšana un vadības pārskatīšanas ievaddati uztur lietu aktuālu.
| Četru nedēļu CRA gatavības sprints | Rezultāts |
|---|---|
| Izvēlieties vienu vadošo ES produktu | Produkta tvērums, versijas, pakalpojumi un atbalsta periods ir definēti |
| Izveidojiet produkta drošības lietas indeksu | Pierādījumu sadaļas, īpašnieki un glabāšanas noteikumi ir dokumentēti |
| Sasaistiet ISO/IEC 27001:2022 kontroles pasākumus ar lietas sadaļām | Auditam ir pieejams kartējums no kontroles pasākuma uz pierādījumu |
| Pievienojiet vienu nesenu laidienu kā pierādījumu paraugu | Drošas izstrādes, testēšanas un laidiena apstiprinājuma ieraksti ir sasaistīti |
| Ģenerējiet vai validējiet SBOM | Komponentu uzskaite ir sasaistīta ar laidiena artefaktu |
| Izsekojiet vienu ievainojamību no atklāšanas līdz slēgšanai | Tiek pārbaudīti CVD, triāžas, novēršanas, komunikācijas un slēgšanas pierādījumi |
| Izsekojiet vienu piegādātāja komponentu līdz līgumam un drošības pierādījumiem | Piegādātāju drošības pierādījumi ir sasaistīti ar produktu |
| Pārskatiet pēctirgus uzraudzības signālus par pēdējo ceturksni | Ekspluatācijas izlūkošana un risku pārskatīšana ir dokumentēta |
| Reģistrējiet trūkumus kā IDPS korektīvās darbības | CRA vājumi kļūst par pārvaldītiem kontroles uzlabojumiem |
| Ziņojiet vadībai par gatavības statusu | Vadība saņem pierādījumu brieduma novērtējumu, nevis neskaidru kontroles aktivitāšu sarakstu |
Šis sprints parasti ātri atklāj patieso situāciju. Organizācijas reti cieš neveiksmi tāpēc, ka tām nav neviena kontroles pasākuma. Tās cieš neveiksmi tāpēc, ka kontroles pasākumi nav savienoti produkta līmenī.
Biežākie CRA gatavības trūkumi pirms 2026. gada
Programmatūras piegādātājiem, ierīču ražotājiem un savienotu pakalpojumu sniedzējiem atkārtotie trūkumi ir konsekventi.
Pirmkārt, IDPS darbības joma ir pārāk korporatīva. Tā aptver organizāciju, bet ne pietiekamu produkta dzīves cikla detalizāciju. Risinājums ir izveidot produkta līmeņa pielikumus un pierādījumu lietas.
Otrkārt, SBOM pastāv, bet tiem neuzticas. Tos ģenerē rīki, bet tie netiek pārskatīti, apstiprināti, glabāti vai sasaistīti ar lēmumiem par ievainojamībām. Risinājums ir SBOM pārvaldība, ne tikai SBOM izveide.
Treškārt, CVD ir publiski redzams, bet operacionāli nepietiekami nobriedis. Ziņojumi pienāk, taču triāžas kritēriji, reaģēšanas mērķi, paziņojumu apstiprinājumi un slēgšanas pierādījumi ir nekonsekventi. Risinājums ir integrēt CVD ar ievainojamību pārvaldību, incidentu pārvaldību un laidienu pārvaldību.
Ceturtkārt, piegādātāju pierādījumi ir pārāk virspusēji. Kritiski piegādātāji tiek komerciāli apstiprināti, bet netiek izvērtēta to ietekme uz produkta drošību. Risinājums ir piegādātāju klasifikācija pēc produkta riska un obligāti pierādījumi kritiskiem komponentiem.
Piektkārt, pēctirgus uzraudzība ir reaktīva. Komandas reaģē uz steidzamām ievainojamībām, bet neveic periodiskas produkta risku pārskatīšanas. Risinājums ir plānota pēctirgus drošības pārskatīšana, kas sasaistīta ar vadības ziņošanu.
Sestkārt, audita pierādījumi ir pārmērīgi manuāli. Atbilstības komandas dzenā ekrānuzņēmumus. Risinājums ir pierādījumi pēc projektēšanas, izmantojot inženierijas sistēmas, pieteikumu darbplūsmas un repozitorijus kā autoritatīvus avotus.
Izveidojiet pierādījumu lietu, pirms termiņš to izdara jūsu vietā
Kibernoturības akts dod priekšrocības organizācijām, kas spēj pierādīt produkta drošību kā darbības disciplīnu. Tas rada risku organizācijām, kas pierādījumus uztver kā pēdējā brīža atbilstības vingrinājumu.
Sāciet ar vienu produktu. Izveidojiet vienu produkta drošības lietu. Sasaistiet to ar ISO/IEC 27001:2022 un ISO/IEC 27002:2022. Pievienojiet drošas izstrādes pierādījumus, SBOM, CVD ierakstus, piegādātāju apliecinājumu un pēctirgus uzraudzību. Veiciet audita simulāciju, pirms to jūsu vietā izdara kāds ārējs pārbaudītājs.
Clarysec var palīdzēt paātrināt šo ceļu ar Zenith Blueprint, Zenith Controls, Enterprise Drošas izstrādes politiku, Ievainojamību pārvaldības politiku, Aktīvu pārvaldības politiku, Trešo pušu un piegādātāju drošības politiku, Žurnālfiksēšanas un uzraudzības politiku un Informācijas drošības incidentu pārvaldības politiku.
Jūsu svarīgākais CRA 2026 jautājums nav: “Vai mums ir drošības kontroles pasākumi?”
Tas ir: “Vai mēs varam pierādīt produkta drošību — laidienu pēc laidiena, komponentu pēc komponenta, ievainojamību pēc ievainojamības — pēc tam, kad produkts jau ir tirgū?”
Izveidojiet pierādījumu lietu tagad, sasaistiet to ar savu IDPS un padariet katru nākamo produkta laidienu gatavu auditam pēc projektēšanas.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
