CRA 2026: Datoteka o sigurnosti proizvoda uz ISO 27001
Proizvođač povezanih uređaja poziva svoju direktoricu informacijske sigurnosti (CISO), Mariju, na sastanak u petak poslijepodne. Prodaja je upravo osigurala europski distribucijski ugovor. Pravni odjel pita može li tvrtka poduprijiti usklađenost s Aktom o kibernetičkoj otpornosti. Inženjering tvrdi da je sigurni razvoj “uglavnom pokriven” jer postoje pregledi koda, SAST i zakrpavanje. Nabava kaže da su dobavljači “pod NDA-om”. Timovi proizvoda imaju ovisnosti firmvera u jednom alatu, popise cloud API-ja u drugom, a prijave ranjivosti u Jira. Funkcija usklađenosti ima dokaze za certifikaciju prema ISO/IEC 27001:2022, ali oni su organizirani oko korporativnog ISMS-a, a ne oko svakog proizvoda stavljenog na tržište EU-a.
Zatim slijedi neugodno pitanje: “Ako tijelo EU-a, klijent, prijavljeno tijelo ili veliki distributer u 2026. zatraži Datoteku o sigurnosti proizvoda, možemo li je dostaviti u jednom tjednu?”
Za mnoge dobavljače softvera, proizvođače pametnih uređaja i pružatelje povezanih usluga iskren je odgovor ne. Ne zato što nemaju sigurnosne kontrole, nego zato što su dokazi o sigurnosti proizvoda raspršeni. Zapisi o sigurnom razvoju nalaze se kod inženjeringa. SBOM-ovi se generiraju po izradi, ali se njima ne upravlja. Koordinirano objavljivanje ranjivosti postoji kao web-stranica, ali nije uvijek povezano s trijažom, ispravcima, sigurnosnim obavijestima i praćenjem nakon stavljanja na tržište. Sigurnost dobavljača zakopana je u ugovorima nabave. Prijavljivanje incidenata pripada sigurnosnim operacijama, dok dokumentacija o usklađenosti pripada usklađenosti proizvoda.
Akt EU-a o kibernetičkoj otpornosti mijenja operativni model. Kibernetička sigurnost proizvoda više nije samo najbolja praksa ili ugovorno obećanje. Ona postaje obveza dokazivanja tijekom životnog ciklusa. Organizacije moraju moći pokazati kako su zahtjevi kibernetičke sigurnosti ugrađeni u dizajn, razvoj, izdavanje, postupanje s ranjivostima, ažuriranja i praćenje nakon stavljanja proizvoda na tržište.
Tu ISO/IEC 27001:2022 postaje snažan alat, ako se pravilno primijeni. On sam po sebi nije shema certifikacije proizvoda, ali njegov ISMS te kontrole rizika, imovine, dobavljača, sigurnog razvoja, ranjivosti i incidenata mogu pružiti okosnicu CRA Datoteke o sigurnosti proizvoda. Cilj nije stvoriti još jedan silos usklađenosti. Cilj je pretvoriti postojeći ISMS u sustav dokaza na razini proizvoda.
Kako Clarysecov Zenith Blueprint: revizorov plan u 30 koraka navodi u fazi 2, koraku 8, Arhitektura dokaza:
“Dokazi se ne bi trebali prikupljati na kraju revizijskog ciklusa. Trebaju biti ugrađeni u kontrolu, dodijeljeni vlasniku, vremenski označeni procesom i ponovno uporabljivi za svaku obvezu koja isto pitanje postavlja drugim riječima.”
Ta rečenica obuhvaća srž spremnosti za CRA. Pitanje nije samo: “Imamo li siguran razvoj?” Pitanje je: “Možemo li dokazati siguran razvoj, poznavanje komponenti, postupanje s ranjivostima i praćenje nakon stavljanja na tržište za ovaj proizvod, ovu verziju, ovo izdanje i ovo tržište?”
CRA Datoteka o sigurnosti proizvoda živi je sustav dokaza
CRA Datoteka o sigurnosti proizvoda ne smije se tretirati kao statični PDF koji se jednom izradi prije izdanja i zatim zaboravi. Treba biti strukturirani dosje koji opisuje sigurnosnu priču proizvoda od koncepta do završetka podrške.
Korisna datoteka objašnjava:
- Što je proizvod i kako je namijenjen za uporabu.
- Koji softver, firmver, usluge u oblaku i ovisnosti trećih strana uključuje.
- Koji su rizici kibernetičke sigurnosti procijenjeni.
- Koji su sigurnosni zahtjevi primijenjeni.
- Kako je proveden siguran razvoj.
- Kako se ranjivosti zaprimaju, trijažiraju, ispravljaju i objavljuju.
- Kako se isporučuju sigurna ažuriranja.
- Kako se kontroliraju dobavljači i komponente otvorenog koda.
- Kako se eskaliraju incidenti i aktivno iskorištene ranjivosti.
- Kako se proizvod prati nakon stavljanja na tržište.
Za CISO-a to je izazov dokazivanja u okviru ISMS-a. Za rukovoditelja usklađenosti proizvoda to je tehnička dokumentacija. Za inženjering to su DevSecOps i upravljanje izdanjima. Za izvršne rukovoditelje to su pristup tržištu i kontrola odgovornosti.
Pogreška je tretirati ih kao odvojene tokove rada. Bolji je model izgraditi datoteku dokaza na razini proizvoda koja se mapira na kontrole ISO/IEC 27001:2022 i ISO/IEC 27002:2022, a zatim iste dokaze dodatno mapira na NIS2, DORA, GDPR, NIST i COBIT 2019 gdje je relevantno.
Clarysecov Zenith Controls: vodič za višestruku usklađenost opisuje to kao lanac kontrola–dokaz–revizor:
“Datoteka dokaza za višestruku usklađenost treba mapirati svaku obvezu na operativnu kontrolu, ponavljajući dokazni objekt, odgovornog vlasnika i revizijsku perspektivu kojom će se dokaz osporavati.”
To je disciplina potrebna za pripremu za CRA. Datoteka o sigurnosti proizvoda nije samo mapa. Ona je prevoditeljski sloj između inženjeringa proizvoda, upravljanja sigurnošću, ocjenjivanja usklađenosti i potvrda prema zahtjevima klijenata.
Najprije izgradite okosnicu dokaza o proizvodu
Datoteci je potrebna dosljedna struktura prije nego što timovi počnu učitavati zapise. Bez jasne okosnice dokazi postaju hrpa snimki zaslona, izvoza i PDF-ova politika koju nijedan revizor ne može pratiti.
Za radionice spremnosti za CRA, Clarysec obično preporučuje sljedeću strukturu Datoteke o sigurnosti proizvoda za organizacije koje već upravljaju ISMS-om prema ISO/IEC 27001:2022.
| Odjeljak Datoteke o sigurnosti proizvoda | Primarni dokazi | Teme kontrola ISO/IEC 27001:2022 i ISO/IEC 27002:2022 | Tipični vlasnik |
|---|---|---|---|
| Definicija proizvoda i namijenjena uporaba | Opis proizvoda, arhitektura, tok podataka, model implementacije | A.5.9 Popis informacija i druge povezane imovine, A.5.8 Informacijska sigurnost u upravljanju projektima, procjena rizika | Vlasnik proizvoda |
| Popis komponenti i ovisnosti | SBOM, popis materijala firmvera, mapa ovisnosti u oblaku | A.5.9 Popis imovine, A.8.9 Upravljanje konfiguracijom, A.8.8 Upravljanje tehničkim ranjivostima | Voditelj inženjeringa |
| Dokazi sigurnog razvoja | Modeli prijetnji, pregledi sigurnog dizajna, zapisi pregleda koda, rezultati sigurnosnog testiranja | A.8.25 Sigurni životni ciklus razvoja softvera, A.8.27 Sigurna arhitektura sustava i načela inženjeringa, A.8.28 Sigurno kodiranje, A.8.29 Sigurnosno testiranje tijekom razvoja i prihvata | Inženjering i AppSec |
| Postupanje s ranjivostima i CVD | Politika objavljivanja, zapisi zaprimanja, dnevnički zapisi trijaže, SLA-ovi za ispravke, predlošci sigurnosnih obavijesti | A.8.8 Upravljanje tehničkim ranjivostima, A.5.24 Planiranje i priprema upravljanja incidentima informacijske sigurnosti, A.5.26 Odgovor na incidente informacijske sigurnosti | Sigurnosne operacije |
| Dokazi dobavljača i otvorenog koda | Procjene dobavljača, ugovorne odredbe, pregled OSS-a, podrijetlo komponenti | A.5.19 Informacijska sigurnost u odnosima s dobavljačima, A.5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, A.5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu | Nabava i pravni poslovi |
| Dokazi sigurnog ažuriranja i izdanja | Odobrenja izdanja, zapisi potpisivanja, planovi povrata, napomene o zakrpama | A.8.32 Upravljanje promjenama, A.8.24 Uporaba kriptografije, A.8.9 Upravljanje konfiguracijom | Voditelj izdanja |
| Praćenje nakon stavljanja na tržište | Izvori podataka o ranjivostima, telemetrija, prijave klijenata, pregledi incidenata, periodični pregled rizika | A.8.15 Zapisivanje događaja, A.8.16 Aktivnosti praćenja, A.5.25 Procjena i odluka o događajima informacijske sigurnosti, kontinuirano poboljšanje | CISO i sigurnost proizvoda |
| Paket usklađenosti i revizije | Mapiranje kontrola, odobrenje uprave, indeks zadržanih dokaza | Upravljanje ISMS-om, A.5.28 Prikupljanje dokaza, interna revizija, preispitivanje od strane uprave | Rukovoditelj usklađenosti |
Ova tablica ne zamjenjuje pravne obveze tehničke dokumentacije. Ona poslovanju daje operativni model za njihovo dokazivanje.
U Zenith Blueprintu, faza 1, korak 3 usmjerava se na definiranje opsega i granica. Za CRA taj korak postaje specifičan za proizvod. Definirajte obitelj proizvoda, verzije softvera, pretpostavke implementacije, korisničke uloge, povezane usluge, kanale ažuriranja i razdoblje podrške. Ako je opseg ISMS-a “Korporativni SaaS i platforma za upravljanje uređajima”, CRA datoteka i dalje mora odgovoriti na uže pitanje: “Koji se proizvod s digitalnim elementima stavlja na tržište EU-a i što je uključeno u taj proizvod?”
Mapirajte siguran razvoj na zapise na razini proizvoda
Središte Datoteke o sigurnosti proizvoda čine dokazi o ugrađenoj sigurnosti. ISO/IEC 27001:2022 pruža sustav upravljanja. ISO/IEC 27002:2022 pruža smjernice za provedbu kroz kontrole kao što su A.8.25 Sigurni životni ciklus razvoja softvera, A.8.27 Sigurna arhitektura sustava i načela inženjeringa, A.8.28 Sigurno kodiranje i A.8.29 Sigurnosno testiranje tijekom razvoja i prihvata.
Važan pomak je od općih tvrdnji o sigurnom razvoju prema zapisima specifičnima za izdanje. “Provodi se pregled koda” nije dovoljno. Datoteka treba pokazati koje je izdanje pregledano, koji su rizici razmotreni, koji su sigurnosni testovi prošli, koje su ranjivosti prihvaćene ili otklonjene te tko je odobrio izdanje.
Clarysecova Enterprise Politika sigurnog razvoja osmišljena je kako bi nametnula taj dokazni trag. U točki 6.1, Zahtjevi životnog ciklusa sigurnog razvoja, navodi:
“Svako izdanje proizvoda ili usluge mora održavati dokumentirane dokaze o sigurnosnim zahtjevima, pregledu dizajna, aktivnostima sigurnog kodiranja, sigurnosnom testiranju, odlukama o otklanjanju ranjivosti i odobrenju izdanja prije implementacije u produkcijsko okruženje.”
Ta je točka korisna za CRA jer siguran razvoj pretvara u ponovljiv obrazac dokaza. Revizor ne mora zaključivati da se siguran razvoj dogodio. Može pregledati zapis izdanja.
Za pametni termostat, medicinski IoT uređaj, industrijski senzor ili proizvod povezan sa SaaS-om, dokazi sigurnog razvoja trebaju uključivati:
- Sigurnosne zahtjeve proizvoda mapirane na identificirane rizike.
- Model prijetnji ili analizu scenarija zlouporabe za proizvod i povezane usluge.
- Pregled arhitekture, uključujući granice povjerenja i vanjska sučelja.
- Standard sigurnog kodiranja i dokaz potvrde upoznatosti ili osposobljavanja razvojnih inženjera.
- SAST, DAST, analizu sastava softvera, skeniranje tajnih vrijednosti i analizu firmvera gdje je primjenjivo.
- Prijave za otklanjanje nalaza visokog rizika.
- Zapise prihvaćanja rizika uz poslovno i sigurnosno odobrenje.
- Kontrolni popis kontrolne točke izdanja koji pokazuje da su sigurnosni kriteriji ispunjeni.
- Dokaze kriptografskog potpisivanja i cjelovitosti ažuriranja.
- Pretpostavke o razdoblju podrške i završetku životnog vijeka.
Drugi standardi pomažu ojačati metodu. ISO/IEC 27005 podupire pristup riziku iza tih zapisa. ISO/IEC 27017 koristan je kada su usluge u oblaku dio ekosustava proizvoda. ISO/IEC 27035 podupire postupanje s incidentima. ISO/IEC 29147 i ISO/IEC 30111 posebno su relevantni za objavljivanje ranjivosti i postupanje s ranjivostima. ISO/IEC 27036 podupire sigurnost dobavljača, što je važno kada proizvod uključuje razvoj softvera povjeren vanjskim izvođačima, ugrađene module, upravljane usluge u oblaku ili biblioteke trećih strana.
U Zenith Controlsu, CRA dokazi sigurnog razvoja obično se mapiraju oko tema kontrola ISO/IEC 27002:2022 kao što su informacijska sigurnost u upravljanju projektima, sigurni životni ciklus razvoja softvera, sigurno kodiranje, sigurnosno testiranje, upravljanje promjenama i upravljanje tehničkim ranjivostima. Vodič ih također povezuje s popisom imovine i kontrolama dobavljača, jer nijedan proces sigurnog razvoja nije potpun ako organizacija ne može identificirati komponente koje isporučuje.
Tretirajte SBOM kao regulirani dokaz o proizvodu
Software Bill of Materials često se tretira kao tehnički artefakt. Za spremnost za CRA treba ga tretirati kao dokaz o proizvodu.
Korisni SBOM pokazuje koje su komponente u proizvodu, koje se verzije koriste, odakle potječu, koje se licence primjenjuju, koje ih ranjivosti pogađaju i koja ih izdanja sadrže. Za firmver i ugrađene proizvode to može uključivati pakete operativnog sustava, bootloadere, biblioteke, upravljačke programe, spremnike, module trećih strana i ovisnosti na strani oblaka potrebne za rad proizvoda.
Problem je u tome što mnoge organizacije generiraju SBOM-ove, ali njima ne upravljaju. Cjevovod izrade može proizvesti SPDX ili CycloneDX datoteku, ali nitko ne provjerava potpunost. Sigurnosni alati mogu označiti ranjivosti, ali rezultati nisu vezani uz verzije proizvoda. Nabava može odobriti dobavljača, ali popis komponenti tog dobavljača nije usklađen s izdanim proizvodom.
Clarysecova Enterprise Politika upravljanja imovinom uređuje ovu prazninu u upravljanju u točki 5.2, Popis informacija i povezane imovine:
“Informacijska imovina i povezane tehnološke komponente moraju se identificirati, dodijeliti vlasniku, klasificirati gdje je primjenjivo i održavati u popisu koji podupire procjenu rizika, upravljanje ranjivostima, kontrolu promjena i revizijske dokaze.”
Za CRA ta točka postaje specifična za proizvod. SBOM je dio popisa povezanih tehnoloških komponenti. Potrebni su mu vlasnik, pravilo zadržavanja, postupak provjere i poveznica s upravljanjem ranjivostima.
Praktično pravilo za SBOM dokaze jednostavno je: svaka izdana verzija proizvoda mora imati odobren popis komponenti koji se može povezati s artefaktom izdanja. Ako organizacija ne može povezati SBOM s točnom slikom firmvera, aplikacijskim paketom, sažetkom spremnika ili SaaS izdanjem, SBOM je slab dokaz.
| Provjera | Dokazi za prikupljanje | Kriteriji prolaznosti |
|---|---|---|
| Povezanost s izdanjem | ID izdanja, sažetak izrade, verzija firmvera, sažetak spremnika ili ID paketa | SBOM se jasno mapira na izdani artefakt |
| Potpunost komponenti | SBOM datoteka, izvješće skeniranja ovisnosti, ručne iznimke | Izravne i tranzitivne ovisnosti obuhvaćene su ili su iznimke opravdane |
| Status ranjivosti | SCA izvješće, prijave ranjivosti, prihvaćanja rizika | Poznati iskoristivi nalazi ili nalazi visokog rizika imaju korektivnu radnju ili odobrenu iznimku |
| Povezanost s dobavljačem | Izjave dobavljača o komponentama, potvrde trećih strana, uvjeti podrške | Kritične isporučene komponente imaju dokaze dobavljača |
| Licenca i podrijetlo | Skeniranje licenci, zapis repozitorija izvornog koda, odobreni izvor paketa | Podrijetlo i uporaba komponenti dokumentirani su |
| Zadržavanje i pristup | Putanja repozitorija dokaza, vlasnik, pravilo zadržavanja | Funkcija usklađenosti može dohvatiti SBOM i povezane zapise u definiranom roku |
Ako više od dva retka ne zadovolje kriterije, problem obično nije SBOM alat. Problem je upravljanje. Datoteka o sigurnosti proizvoda treba evidentirati korektivnu radnju u ISMS-u jer je slabost CRA dokaza ujedno i pitanje djelotvornosti kontrola prema ISO/IEC 27001:2022.
Povežite CVD s postupanjem s ranjivostima i upravljanjem izdanjima
Koordinirano objavljivanje ranjivosti jedno je od najvidljivijih područja spremnosti za CRA jer ga vanjski istraživači, klijenti i nadležna tijela mogu izravno testirati. Objavljivanje stranice za prijavu ranjivosti ili datoteke security.txt korisno je, ali to su samo ulazna vrata. Datoteka o sigurnosti proizvoda mora dokazati da pozadinski proces funkcionira.
Dokaziv skup dokaza za CVD i postupanje s ranjivostima treba uključivati:
- Javni kanal za objavljivanje i upute za podnošenje.
- Postupak potvrde primitka prema istraživaču.
- Kriterije trijaže, uključujući procjenu ozbiljnosti i iskoristivosti.
- Analizu utjecaja na proizvod.
- Vlasništvo nad otklanjanjem i ciljane rokove.
- Predloške sigurnosnih obavijesti klijentima i komunikacije o ažuriranju.
- Dokaze o sigurnom razvoju i testiranju zakrpa.
- Zapise o koordiniranom objavljivanju gdje je primjenjivo.
- Naučene lekcije i analizu ponavljajućih trendova ranjivosti.
Clarysecova Enterprise Politika upravljanja ranjivostima, točka 6.3, Zaprimanje, trijaža i otklanjanje ranjivosti, navodi:
“Prijavljene ranjivosti moraju se evidentirati, procijeniti za zahvaćenu imovinu i proizvode, prioritizirati prema riziku i iskoristivosti, dodijeliti odgovornom vlasniku te pratiti kroz otklanjanje, provjeru, komunikaciju i zatvaranje.”
Ta točka povezuje CVD sa SBOM-om, popisom imovine, inženjerskim prijavama, upravljanjem izdanjima i praćenjem nakon stavljanja na tržište. To je ujedno točka koju će revizori prirodno testirati: pokažite zapis zaprimanja, pokažite zahvaćene proizvode, pokažite trijažu, pokažite ispravak, pokažite komunikaciju s klijentima, pokažite zatvaranje.
Postojeću Politiku upravljanja incidentima informacijske sigurnosti također treba proširiti tako da obuhvati ranjivosti proizvoda koje postaju incidenti ili zahtijevaju vanjsku obavijest. ISO/IEC 27002:2022 A.5.24 obuhvaća planiranje i pripremu upravljanja incidentima, A.5.25 obuhvaća procjenu i odluku o događajima informacijske sigurnosti, A.5.26 obuhvaća odgovor na incidente informacijske sigurnosti, a A.5.27 obuhvaća učenje iz incidenata.
U Zenith Controlsu, upravljanje ranjivostima tretira se i kao preventivno i kao korektivno. Preventivna strana uključuje popis imovine, siguran razvoj, praćenje dobavljača i sigurnu konfiguraciju. Korektivna strana uključuje otkrivanje, trijažu, zakrpavanje, komunikaciju i eskalaciju incidenata. Ta je razlika važna jer je postupanje s ranjivostima nakon stavljanja proizvoda na tržište dio obveze životnog ciklusa proizvoda, a ne naknadna aktivnost.
Dokazi dobavljača skrivena su slabost
Datoteka o sigurnosti proizvoda često će biti najstrože propitivana upravo ondje gdje se proizvođač oslanja na druge. To uključuje ugrađene module, razvoj firmvera povjeren vanjskim izvođačima, white-label komponente, hosting u oblaku, mobilne SDK-ove, platne usluge, kriptografske biblioteke i pružatelje upravljane podrške.
Čest obrazac neuspjeha jest ugovorna apstrakcija. Proizvođač kaže: “Naš dobavljač odgovoran je za to.” Pod povećalom sigurnosti proizvoda to nije dovoljno. Organizacija mora pokazati da je rizik dobavljača identificiran, da su sigurnosni zahtjevi priopćeni, da se dokazi prikupljaju, da se ranjivosti koordiniraju i da se promjene kontroliraju.
Clarysecova Enterprise Politika sigurnosti trećih strana i dobavljača, točka 7.1, Zahtjevi sigurnosti dobavljača, navodi:
“Dobavljači koji razvijaju, upravljaju, obrađuju, podržavaju ili bitno utječu na informacijske sustave, proizvode ili usluge moraju se procjenjivati prema riziku te moraju podlijegati sigurnosnim zahtjevima koji obuhvaćaju pristup, upravljanje ranjivostima, obavješćivanje o incidentima, podugovaranje, neprekidnost poslovanja i dostavu dokaza.”
Za CRA je izraz “bitno utječu na proizvode” ključan. Ako komponenta dobavljača može unijeti ranjivost, poremetiti ažuriranja, izložiti podatke klijenata ili kompromitirati cjelovitost uređaja, pripada Datoteci o sigurnosti proizvoda.
Ista politika može poduprijeti i ugovaranje SBOM-a. Točka 7.3 navodi:
“Za sve softverske komponente trećih strana, biblioteke ili operativne sustave koji se integriraju u proizvode društva s digitalnim elementima dobavljač mora, na zahtjev, dostaviti strojno čitljiv Software Bill of Materials (SBOM) u standardnom formatu kao što su SPDX ili CycloneDX. Ovaj zahtjev mora biti ugrađen u sve ugovore o nabavi i ugovore s dobavljačima.”
Snažan paket dokaza dobavljača treba uključivati klasifikaciju dobavljača prema utjecaju na proizvod, sigurnosne zahtjeve u ugovorima, dokaze sigurnog razvoja dobavljača za kritične komponente, obveze dobavljača za objavljivanje ranjivosti, SBOM ili izjave o komponentama gdje je izvedivo, podršku za zakrpe i rokove završetka životnog vijeka, zapise periodičnih pregleda i putove eskalacije za ranjivosti koje potječu od dobavljača.
ISO/IEC 27002:2022 A.5.19, A.5.20 i A.5.21 daju ključne teme kontrola dobavljača. ISO/IEC 27036 dodaje dubinu sigurnosti odnosa s dobavljačima. U smislu višestruke usklađenosti, NIS2 naglašava opskrbni lanac i postupanje s ranjivostima. DORA naglašava rizik IKT trećih strana za financijske subjekte. GDPR postaje relevantan kada proizvod ili njegove usluge u oblaku obrađuju osobne podatke. COBIT 2019 postavlja upravljanje dobavljačima kao pitanje korporativnog upravljanja tehnologijom, a ne samo kao pitanje sigurnosnih operacija.
Praćenje nakon stavljanja na tržište pretvara dokaze u operacije
Najzrelije organizacije za sigurnost proizvoda razmišljaju izvan izdanja. Pitaju: “Kako ćemo znati da je ovaj proizvod postao rizičan nakon što je na terenu?”
Praćenje nakon stavljanja na tržište treba obuhvatiti signale iz izvora podataka o ranjivostima, obavještajnih podataka o iskorištavanju, korisničke podrške, telemetrije, bug bounty programa ili prijava istraživača, obavijesti dobavljača, dnevničkih zapisa u oblaku, zapisa incidenata i podataka o radu na terenu. Treba uključivati i periodični pregled rizika proizvoda kada se promijene uvjeti prijetnji.
Clarysecova Enterprise Politika zapisivanja događaja i praćenja, točka 5.4, Sigurnosno praćenje i pregled, navodi:
“Događaji relevantni za sigurnost moraju se prikupljati, pregledavati, eskalirati i zadržavati na način koji podupire pravodobno otkrivanje, istragu, odgovor na incidente, izvješćivanje o usklađenosti i kontinuirano poboljšanje.”
Za povezane proizvode to se mora pažljivo tumačiti. Praćenje mora poštovati privatnost, minimizaciju podataka i pravna ograničenja, osobito kada telemetrija uključuje osobne podatke ili operativne podatke klijenata. Mapiranje na GDPR važno je. Timovi za sigurnost proizvoda trebaju surađivati s timovima za privatnost kako bi definirali koja je telemetrija nužna za sigurnost, kako se minimizira, koliko se dugo zadržava i kako se klijenti obavješćuju.
Dokazi praćenja nakon stavljanja na tržište trebaju uključivati plan praćenja sigurnosti proizvoda, izvore obavještajnih podataka o ranjivostima, kanale zaprimanja prijava klijenata, kanale obavješćivanja dobavljača, opseg pregleda telemetrije ili dnevničkih zapisa, zapisnike periodičnih pregleda rizika proizvoda, praćenje usvajanja zakrpa, analizu trendova incidenata i ulazne podatke za preispitivanje od strane uprave.
U Zenith Blueprintu, faza 5, korak 30 usmjerava se na kontinuirano poboljšanje i spremnost za nadzor. Za CRA upravo tu Datoteka o sigurnosti proizvoda postaje živa datoteka. Svako izdanje proizvoda, ranjivost, promjena dobavljača i signal s terena trebaju ažurirati zapis dokaza.
Jedna datoteka dokaza, mnoga pitanja usklađenosti
Dobro oblikovana CRA Datoteka o sigurnosti proizvoda smanjuje dupliciranje jer isti dokazi odgovaraju na više pitanja usklađenosti. Jezik se mijenja, ali stvarnost kontrola često je slična.
| Dokazni objekt | Relevantnost za CRA | Tema ISO/IEC 27001:2022 i ISO/IEC 27002:2022 | Relevantnost za NIS2, DORA, GDPR, NIST i COBIT 2019 |
|---|---|---|---|
| Procjena rizika proizvoda | Pokazuje da su sigurnosni rizici razmotreni tijekom dizajna i životnog ciklusa proizvoda | Procjena rizika, A.5.8 Informacijska sigurnost u upravljanju projektima, A.8.25 Sigurni životni ciklus razvoja softvera | NIS2 upravljanje rizicima, DORA upravljanje IKT rizicima, NIST Govern and Identify, COBIT upravljanje rizicima |
| SBOM i popis komponenti | Pokazuje poznavanje softverskih komponenti i izloženosti ranjivostima | A.5.9 Popis imovine, A.8.9 Upravljanje konfiguracijom, A.8.8 Upravljanje tehničkim ranjivostima | NIS2 opskrbni lanac, DORA osviještenost o IKT imovini, NIST Asset Management, COBIT upravljanje imovinom |
| Zapisi sigurnog razvoja | Pokazuju da je sigurnost ugrađena u dizajn i izdanje | A.8.25 Sigurni životni ciklus razvoja softvera, A.8.27 Sigurna arhitektura, A.8.28 Sigurno kodiranje, A.8.29 Sigurnosno testiranje | NIST Protect, COBIT upravljanje izgradnjom i promjenama, GDPR ugrađena sigurnost gdje su uključeni osobni podaci |
| CVD i prijave ranjivosti | Pokazuju sposobnost zaprimanja, procjene, otklanjanja i komunikacije o ranjivostima | A.8.8 Upravljanje tehničkim ranjivostima, A.5.24 Planiranje incidenata, A.5.26 Odgovor na incidente | NIS2 postupanje s ranjivostima, DORA procesi za incidente i ranjivosti, NIST Respond |
| Dokazi dobavljača | Pokazuju da se ovisnostima proizvoda upravlja | A.5.19 Odnosi s dobavljačima, A.5.20 Ugovori s dobavljačima, A.5.21 IKT opskrbni lanac | NIS2 sigurnost opskrbnog lanca, DORA rizik IKT trećih strana, COBIT upravljanje dobavljačima |
| Praćenje nakon stavljanja na tržište | Pokazuje kontinuirani nadzor sigurnosti proizvoda | A.8.15 Zapisivanje događaja, A.8.16 Aktivnosti praćenja, A.5.25 Procjena događaja, kontinuirano poboljšanje | NIS2 otkrivanje incidenata, DORA praćenje, NIST Detect, GDPR podrška otkrivanju povreda |
| Zapisi o prijavljivanju incidenata | Pokazuju spremnost za eskalaciju i obavješćivanje | A.5.24 Planiranje incidenata, A.5.25 Procjena događaja, A.5.26 Odgovor na incidente, A.5.27 Učenje iz incidenata | NIS2 i DORA izvješćivanje, GDPR procjena povrede, NIST Respond and Recover |
Zenith Controls osmišljen je za takvu ponovnu uporabu. Mapira teme kontrola ISO/IEC 27002:2022 na atribute kao što su preventivna, detektivna i korektivna svrha kontrole, koncepti kibernetičke sigurnosti, operativne sposobnosti i sigurnosna svojstva. Za CRA to pomaže CISO-u objasniti zašto jedan dokazni objekt, primjerice sigurnosni pregled izdanja, podupire siguran razvoj, obradu rizika, kontrolu promjena, upravljanje ranjivostima i spremnost za reviziju.
Pripremite se za različite revizijske perspektive
CRA Datoteku o sigurnosti proizvoda mogu propitivati ISO revizor, tim unutarnje revizije, tim za potvrde prema zahtjevima klijenata, pregledavatelj usklađenosti proizvoda, regulator, procjenitelj koji se oslanja na NIST ili COBIT revizor obučen prema ISACA-i. Svi će postavljati slična pitanja kroz različitu perspektivu.
| Revizijska perspektiva | Što će pitati | Snažni dokazi |
|---|---|---|
| Revizor ISO/IEC 27001:2022 | Upravlja li se sigurnošću proizvoda unutar ISMS-a, procesa rizika, modela kompetencija, operativnih kontrola i ciklusa kontinuiranog poboljšanja? | Opseg ISMS-a, procjena rizika, Izjava o primjenjivosti, zapisi sigurnog razvoja, nalazi interne revizije, preispitivanje od strane uprave |
| Certifikacijska perspektiva ISO/IEC 27006-1:2024 | Jesu li revizijski dokazi pouzdani, primjereno uzorkovani i povezani s certificiranim sustavom upravljanja? | Indeks dokaza, logika uzorkovanja, razgovori s vlasnicima, zadržani zapisi, praćenje korektivnih radnji |
| Procjenitelj usmjeren na NIST | Možete li pokazati upravljanje, identifikaciju imovine, zaštitne mjere, otkrivanje, odgovor i oporavak za životni ciklus proizvoda? | Registar rizika proizvoda, SBOM, plan praćenja, radni tok ranjivosti, operativne upute za incidente |
| COBIT 2019 ili ISACA revizor | Jesu li ciljevi sigurnosti proizvoda upravljani, mjereni, dodijeljeni vlasnicima i usklađeni s rizikom organizacije i isporukom vrijednosti? | RACI, metrike, odobrenja politika, upravljanje dobavljačima, izvješćivanje upravi, prihvaćanje rizika |
| Pregledavatelj usklađenosti proizvoda | Pokazuje li tehnička datoteka zahtjeve kibernetičke sigurnosti, kontrole dizajna, postupanje s ranjivostima i praćenje proizvoda nakon stavljanja na tržište? | Indeks Datoteke o sigurnosti proizvoda, arhitektura, SBOM, dokazi testiranja, CVD zapisi, dokazi ažuriranja |
| Procjenitelj sigurnosti klijenta | Možete li dokazati da se proizvod sigurno razvija i podržava tijekom životnog ciklusa? | Sažetak sigurnog SDLC-a, sažetak penetracijskog testiranja, postupak objavljivanja ranjivosti, politika podrške za zakrpe, potvrde dobavljača |
Ista slaba točka bit će izložena na različite načine. Ako se SBOM-ovi generiraju, ali se ne zadržavaju, ISO revizor vidi problem kontrole zapisa i operativne kontrole. NIST procjenitelj vidi slabost u upravljanju imovinom i ranjivostima. COBIT revizor vidi slabo upravljanje informacijskom imovinom. Pregledavatelj proizvoda vidi nedostatnu tehničku dokumentaciju.
Plan u 30 koraka, prilagođen spremnosti za CRA
Zenith Blueprint sprječava timove za usklađenost da odmah prijeđu na prikupljanje dokumenata. Za CRA plan u 30 koraka postaje program dokaza sigurnosti proizvoda.
Faza 1 počinje mapiranjem obveza i opsega. Identificirajte koji su proizvodi, verzije, komponente, usluge u oblaku i procesi podrške u opsegu. Potvrdite namijenjenu uporabu, kategorije korisnika, tržišta i razdoblje sigurnosne podrške.
Faza 2 gradi arhitekturu dokaza. Definirajte indeks Datoteke o sigurnosti proizvoda, vlasnike dokaza, zahtjeve zadržavanja, strukturu repozitorija i radni tok odobravanja. Uskladite se s inženjerskim sustavima umjesto nametanja ručnih učitavanja.
Faza 3 provodi operativne kontrole. Siguran razvoj, generiranje SBOM-a, postupanje s ranjivostima, dokazi dobavljača, kontrolne točke izdanja, sigurna ažuriranja i eskalacija incidenata moraju funkcionirati kao stvarni procesi.
Faza 4 testira spremnost za reviziju. Odaberite izdanje proizvoda i provedite probnu reviziju. Može li tim dohvatiti SBOM? Može li dokazati sigurnosno testiranje? Može li pokazati kako je ranjivost trijažirana? Može li povezati dokaze dobavljača s komponentama proizvoda?
Faza 5 ugrađuje nadzor i poboljšanje. Praćenje nakon stavljanja na tržište, analiza trendova ranjivosti, pregledi dobavljača i ulazni podaci za preispitivanje od strane uprave održavaju datoteku ažurnom.
| Četverotjedni sprint spremnosti za CRA | Izlazni rezultat |
|---|---|
| Odaberite jedan vodeći EU proizvod | Definirani su opseg proizvoda, verzije, usluge i razdoblje podrške |
| Izradite indeks Datoteke o sigurnosti proizvoda | Dokumentirani su odjeljci dokaza, vlasnici i pravila zadržavanja |
| Mapirajte kontrole ISO/IEC 27001:2022 na odjeljke datoteke | Mapiranje kontrola na dokaze dostupno je za reviziju |
| Priložite jedno nedavno izdanje kao uzorak dokaza | Povezani su zapisi sigurnog razvoja, testiranja i odobrenja izdanja |
| Generirajte ili provjerite SBOM | Popis komponenti povezan je s artefaktom izdanja |
| Pratite jednu ranjivost od otkrivanja do zatvaranja | Testirani su CVD, trijaža, otklanjanje, komunikacija i dokazi zatvaranja |
| Pratite jednu komponentu dobavljača do ugovora i sigurnosnih dokaza | Dokazi sigurnosti dobavljača povezani su s proizvodom |
| Pregledajte signale praćenja nakon stavljanja na tržište za posljednje tromjesečje | Dokumentirani su obavještajni podaci s terena i pregled rizika |
| Evidentirajte praznine kao korektivne radnje u ISMS-u | Slabosti CRA postaju upravljana poboljšanja kontrola |
| Izvijestite upravu o statusu spremnosti | Izvršni rukovoditelji dobivaju zrelost dokaza, a ne neodređenu aktivnost kontrola |
Ovaj sprint obično brzo pokaže stvarno stanje. Organizacije rijetko ne uspijevaju zato što nemaju nikakve kontrole. Ne uspijevaju zato što kontrole nisu povezane na razini proizvoda.
Uobičajene praznine u spremnosti za CRA prije 2026.
Među dobavljačima softvera, proizvođačima uređaja i pružateljima povezanih usluga ponavljajuće su praznine dosljedne.
Prvo, opseg ISMS-a previše je korporativan. Obuhvaća organizaciju, ali nedovoljno detaljno životni ciklus proizvoda. Rješenje je izraditi priloge i datoteke dokaza na razini proizvoda.
Drugo, SBOM-ovi postoje, ali im se ne vjeruje. Generiraju ih alati, ali se ne pregledavaju, odobravaju, zadržavaju niti povezuju s odlukama o ranjivostima. Rješenje je upravljanje SBOM-om, a ne samo proizvodnja SBOM-a.
Treće, CVD je javno vidljiv, ali operativno nije zreo. Prijave stižu, ali kriteriji trijaže, ciljevi odgovora, odobrenja sigurnosnih obavijesti i dokazi zatvaranja nisu dosljedni. Rješenje je integrirati CVD s upravljanjem ranjivostima, upravljanjem incidentima i upravljanjem izdanjima.
Četvrto, dokazi dobavljača su plitki. Kritični dobavljači komercijalno su odobreni, ali nisu procijenjeni prema utjecaju na sigurnost proizvoda. Rješenje je klasifikacija dobavljača prema riziku proizvoda i obvezni dokazi za kritične komponente.
Peto, praćenje nakon stavljanja na tržište je reaktivno. Timovi reagiraju na hitne ranjivosti, ali ne provode periodične preglede rizika proizvoda. Rješenje je planirani sigurnosni pregled nakon stavljanja na tržište povezan s izvješćivanjem upravi.
Šesto, revizijski dokazi previše su ručni. Timovi za usklađenost prikupljaju snimke zaslona. Rješenje su dokazi ugrađeni u dizajn procesa, uz uporabu inženjerskih sustava, radnih tokova za prijave i repozitorija kao vjerodostojnih izvora.
Izgradite datoteku dokaza prije nego što je rok izgradi umjesto vas
Akt o kibernetičkoj otpornosti nagrađuje organizacije koje mogu dokazati sigurnost proizvoda kao operativnu disciplinu. Stvara rizik za organizacije koje dokaze tretiraju kao vježbu usklađenosti u zadnji trenutak.
Započnite s jednim proizvodom. Izradite jednu Datoteku o sigurnosti proizvoda. Mapirajte je na ISO/IEC 27001:2022 i ISO/IEC 27002:2022. Priložite dokaze sigurnog razvoja, SBOM, CVD zapise, potvrde dobavljača i praćenje nakon stavljanja na tržište. Provedite simulaciju revizije prije nego što to učini netko izvana.
Clarysec vam može pomoći ubrzati taj put uz Zenith Blueprint, Zenith Controls, Enterprise Politiku sigurnog razvoja, Politiku upravljanja ranjivostima, Politiku upravljanja imovinom, Politiku sigurnosti trećih strana i dobavljača, Politiku zapisivanja događaja i praćenja i Politiku upravljanja incidentima informacijske sigurnosti.
Vaše najvažnije pitanje za CRA 2026 nije: “Imamo li sigurnosne kontrole?”
Ono glasi: “Možemo li dokazati sigurnost proizvoda, izdanje po izdanje, komponentu po komponentu, ranjivost po ranjivost, nakon što je proizvod već na tržištu?”
Izgradite datoteku dokaza sada, povežite je sa svojim ISMS-om i učinite svako buduće izdanje proizvoda spremnim za reviziju po dizajnu.
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
