Rezumat tehnic
Idei cheie:

Textul critică analizele de risc cibernetic aparent corecte, care nu se traduc în decizii de inginerie și în mentenanța produsului. Prezintă o schimbare de paradigmă către o abordare bazată pe risc, în contextul real de utilizare și pe întregul ciclu de viață.

  • O „evaluare a riscului cibernetic” tipică este adesea un tabel cu low/medium/high: conformă cu cerințele de conformitate, dar fără impact asupra arhitecturii produsului sau asupra suportului.
  • Abordarea UE (CRA, MDR, Regulamentul privind mașinile 2023/1230) mută accentul întrebării către condițiile de utilizare și controlul riscului pe parcursul ciclului de viață.
  • Evaluarea riscului produsului nu este o analiză IT, un pentest și nici implementarea ISO 27001; se referă la capacitatea produsului și a producătorului de a menține securitatea în timp.
  • Vulnerabilitatea (de ex. CVE) este o eroare tehnică; riscul produsului rezultă din contextul de utilizare, integrare, comportamentul utilizatorilor, gestionarea patch-urilor și reacția la incidente.
  • Măsurile de securitate alese greșit pot crește riscul: MFA în OT, actualizările automate în IoMT, închiderea interfețelor în IoT creează noi vectori și efecte secundare.

În marea majoritate a companiilor tehnologice, procesul cunoscut drept evaluarea riscului cibernetic există deja. De regulă, ia forma unui tabel amplu, a unei matrici complicate sau a unui fișier de tip spreadsheet, dominat de valorile „low”, „medium” și „high”. Documentul conține o listă lungă de amenințări generice, descrieri scurte ale vulnerabilităților potențiale și un set de măsuri de control standard. Din punct de vedere formal, totul este în regulă: documentul este complet, semnat de conducere și arhivat în siguranță.

Problema este că, în practica inginerească, acest document nu schimbă absolut nimic.

Nu influențează arhitectura dispozitivului proiectat. Nu condiționează decizia privind modul de livrare a actualizărilor. Nu modifică modelul de suport post-vânzare și nu reevaluează relațiile cu furnizorii de componente. Este un document corect din perspectiva compliance, dar complet indiferent pentru securitatea cibernetică reală a produselor. Nu este însă vina lipsei de competențe în echipele de inginerie sau de security. Este o problemă de punct de plecare fundamental greșit.

Cele mai multe analize tradiționale de risc pornesc de la întrebarea: „Ce amenințări pot apărea?”. Între timp, noua abordare de reglementare a Uniunii Europene – vizibilă clar în acte precum Cyber Resilience Act (CRA), directivele medicale (MDR) sau noul regulament privind mașinile 2023/1230 – impune o perspectivă cu totul diferită. Aceasta începe cu întrebarea:

În ce condiții de utilizare poate produsul deveni un purtător de risc pentru utilizator, sistem sau piață – și poate producătorul să controleze acest risc pe întreg ciclul de viață?

Este o schimbare fundamentală de paradigmă. Evaluarea riscului cibernetic în contextul produsului nu este pur și simplu încă o analiză a amenințărilor pentru infrastructura IT. Nu este nici un test de penetrare și nici o aplicare mecanică a recomandărilor standardului ISO 27001. Este o analiză în profunzime a capacității atât a produsului, cât și a producătorului său, de a menține securitatea în timp, într-un mediu operațional real.

Vulnerabilitatea tehnică vs. riscul de produs – o distincție în securitatea cibernetică

Pentru ca evaluarea riscului să nu mai fie doar un tabel birocratic, ci să devină un instrument decizional pentru inginerie, trebuie să separăm cu precizie două noțiuni care, pe piață, sunt adesea confundate. Să reținem: vulnerabilitatea nu este același lucru cu riscul de produs.

  • Vulnerabilitatea tehnică este o eroare concretă, identificabilă, în software, în configurația hardware sau chiar în proiect. Poate fi o validare incorectă a datelor, o bibliotecă de programare învechită sau o breșă în mecanismul de autentificare. Astfel de erori sunt înregistrate în baze precum sistemul CVE (Common Vulnerabilities and Exposures). Însă aceasta rămâne o evaluare exclusiv la nivel tehnic.
  • Riscul de produs apare abia în momentul în care vulnerabilitatea menționată (sau chiar absența ei temporară) este plasată în realitățile dure ale utilizării.

Acest context include o serie de variabile: mediul de lucru (rețea deschisă sau izolată), modul de integrare cu alte sisteme, comportamentul utilizatorilor, disponibilitatea actualizărilor de securitate (așa-numitul patch management) și capacitatea organizațională a producătorului de a răspunde la incidente.

Un produs poate să nu aibă nicio vulnerabilitate cunoscută în ziua lansării și, totuși, să genereze un risc critic dacă dezvoltatorul său nu are procese de suport pe termen lung. Înțelegerea acestei diferențe ordonează întreaga muncă de inginerie. Pe aceasta se bazează abordarea bazată pe risc (risk-based approach). Măsurile de securitate trebuie să fie proporționale cu scenariile previzibile de abuz, nu cu o listă abstractă de pe internet.

Paradoxul măsurilor de securitate: când protecția crește riscul în IT și OT

În proiectarea securității cibernetice se pornește adesea de la presupunerea că adăugarea unui nou „lacăt” reduce întotdeauna riscul. Practica arată că uneori este exact invers. O măsură implementată fără înțelegerea contextului creează noi vectori de amenințare.

1. Autentificare puternică în mediul industrial (OT)

Să ne imaginăm implementarea autentificării multifactor (MFA) pe o mașină industrială. Din perspectiva IT este un pas exemplară, însă securitatea cibernetică în automatizarea industrială este o realitate cu totul diferită. În mediul de fabrică, echipamentul funcționează 24/7, iar intervențiile de service au loc sub presiunea timpului. Când rețeaua cedează, tehnicianul nu poate autoriza tokenul online. Producția se oprește. Efectul? Clientul frustrat dezactivează definitiv acest mecanism, ocolind complet protecția. Măsura care trebuia să protejeze a generat un risc operațional major.

2. Actualizări automate în dispozitive medicale (IoMT)

Rapiditatea cu care sunt remediate vulnerabilitățile reduce expunerea la atacuri, ceea ce în IT este o practică standard. Însă, în cazul echipamentelor medicale, o actualizare forțată în timpul unei proceduri poate schimba comportamentul sistemului sau poate întrerupe comunicarea cu rețeaua spitalului. În această situație, protecția tehnologică generează un risc clinic și de conformitate critic (încălcarea certificării MDR).

3. Închiderea interfețelor în echipamentele de consum (IoT)

Producătorul elimină fizic din dispozitivul smart home porturile locale de diagnostic, pentru a îngreuna accesul hackerilor. În practică, service-urile autorizate ajung să diagnosticheze defecțiunile prin interfețe instabile, ocolind criptarea, iar utilizatorii avansați instalează pe scară largă software modificat (custom firmware). Rezultatul este pierderea completă a controlului asupra propriului ecosistem de către producător.

O analiză reală a riscului cibernetic întreabă: „Cum se vor schimba stabilitatea, utilizabilitatea și siguranța întregului ecosistem după adăugarea acestui mecanism concret?”.

Cele mai frecvente 5 greșeli în analiza riscului pentru produse tehnologice

Evaluând procesele din companiile care introduc pe piață electronică și software, experții în securitate cibernetică observă tipare recurente.

  1. Copierea modelului IT corporativ în lumea produselor. Un produs nu este un centru de date. Funcționează într-un mediu necunoscut, adesea offline, configurat de persoane fără pregătire tehnică. Aplicarea instrumentelor IT la analiza unui produs se termină prin ignorarea problemelor-cheie: ciclul de viață al dispozitivului și lipsa actualizărilor impuse.
  2. Analiza amenințărilor abstracte în locul scenariilor reale. Completarea unui tabel cu formule precum „acces neautorizat” este inutilă din punct de vedere analitic. Analiza trebuie să se bazeze pe concret: Cine? Prin ce interfață? În ce scop? Cu ce efect?
  3. Ignorarea ciclului de viață al produsului (End-of-Life). Analiza riscului vizează, de regulă, momentul lansării. Între timp, riscul crește odată cu trecerea timpului – bibliotecile open-source îmbătrânesc, iar furnizorii de componente își încheie suportul. Fără a include modelul de mentenanță, analiza este falsă.
  4. Izolarea față de echipa de proiectare (R&D). Tratarea evaluării riscului ca pe o listă de bifat înainte de audit este o rețetă sigură pentru dezastru. Rezultatele trebuie să se întoarcă la ingineri sub forma unor cerințe arhitecturale ferme (Secure by Design).
  5. Fetișizarea tehnologiei în detrimentul procedurilor. Companiile investesc sume uriașe în criptografie avansată, dar nu știu cine, în organizație, este responsabil de lansarea unei corecții de securitate (patch) după raportarea unei vulnerabilități de către un cercetător (Vulnerability Disclosure Program).

Cum să realizezi o analiză conformă cu Cyber Resilience Act? 7 pași inginerești

Evaluarea riscului cibernetic trebuie să înceteze să mai fie o povară birocratică. Mai jos se află un model operațional de piață, aliniat cu abordarea unională (inclusiv cerințele CRA).

  1. Definește limitele produsului. Produsul nu înseamnă doar hardware. Include și aplicația mobilă, cloud-ul, serverele OTA și interfețele API.
  2. Descrie realitatea dură a mediului de utilizare. Nu descrie mediul de laborator. Răspunde la întrebări despre conectivitatea reală la internet, competențele utilizatorilor și posibilitățile de acces fizic la dispozitiv.
  3. Identifică scenariile de abuz (Threat Modeling). Renunță la listele generice. Folosește metode și instrumente inginerești verificate de estimare a riscului, pentru a te concentra pe vectori de atac preciși, adaptați domeniului tău.
  4. Cuantifică consecințele non-financiare. Evaluează riscul de oprire a producției, riscurile pentru sănătate sau încălcarea obligațiilor de reglementare.
  5. Pune întrebarea despre control. Ca producător, poți preveni, detecta și reacționa rapid la scenariul de abuz identificat?
  6. Proiectează mecanisme de protecție proporționale. Deciziile privind criptarea sau separarea rețelei trebuie să rezulte direct din răspunsurile oferite în pașii anteriori.
  7. Proiectează procesul de mentenanță (Lifecycle). Documentează politica de livrare a patch-urilor de securitate, perioada de suport și canalele de comunicare cu clientul.

Concluzie: Ce ar trebui să rezulte dintr-o evaluare riguroasă a riscului?

Finalul unei evaluări corecte a riscului de securitate cibernetică al produsului nu ar trebui să fie niciodată un poem dens, plin de text, pentru auditor. Din această muncă trebuie să rezulte artefacte tangibile: o hartă clară a limitelor sistemului, decizii arhitecturale ferme în R&D, un buget aprobat pentru politica de actualizări și o trasabilitate de audit coerentă care demonstrează conformitatea cu directivele UE.

O organizație matură din punct de vedere tehnologic nu mai întreabă: „Suntem 100% în siguranță?”. În schimb, întreabă: „Unde anume suntem expuși și putem gestiona asta în timp?”.

Produsul tău este pregătit pentru noile reglementări?

Securitatea este un proces, nu un certificat obținut o singură dată. Dacă nu vrei ca evaluarea riscurilor din compania ta să fie doar „hârțogărie”, merită să acționezi proactiv. Vezi cum să pregătești în mod real produsul pentru Cyber Resilience Act (CRA) în anii 2026-2027, înainte să apară standardele armonizate oficiale.

Oceń post

Evaluarea riscului cibernetic al produselor: De ce majoritatea analizelor de securitate sunt, în aparență, corecte, dar în practică inutile?

Deoarece, de regulă, îndeplinește cerințele de conformitate, dar nu influențează deciziile inginerești: arhitectura, actualizările, suportul post-vânzare sau relațiile cu furnizorii. În consecință, este corectă din punct de vedere formal, dar indiferentă din punct de vedere practic.

Nu de la o listă de pericole abstracte, ci de la condițiile de utilizare în care produsul poate deveni un purtător de risc și de la faptul dacă producătorul este capabil să controleze acest risc pe întregul ciclu de viață. Această abordare este coerentă cu perspectiva de reglementare vizibilă, între altele, în CRA, MDR și în regulamentul privind mașinile 2023/1230.

Vulnerabilitatea tehnică este o eroare concretă în software, configurație sau proiectare (de exemplu, o breșă în autentificare) și poate fi înregistrată, de pildă, ca CVE. Riscul produsului apare abia în contextul utilizării reale, al integrării, al comportamentelor utilizatorilor, al disponibilității actualizărilor și al capacității producătorului de a reacționa.

Nu — un mecanism ales greșit poate crește riscul, deoarece creează noi vectori de probleme operaționale. Exemplele din text arată că MFA în OT, actualizările automate în IoMT sau „blocarea” interfețelor în IoT pot duce la ocolirea măsurilor de securitate ori la riscuri operaționale și de conformitate.

Aceasta include, printre altele, copierea modelului corporativ din IT în lumea produselor, bazarea pe generalități în locul scenariilor („cine, cum, de ce și cu ce efect”), precum și ignorarea ciclului de viață și a problemelor de tip End-of-Life. Rezultatul este o analiză care nu indică decizii reale de proiectare și nici acțiuni de mentenanță.

Distribuie: LinkedIn Facebook