Perioadele de suport de securitate CRA ale UE guvernate prin ISO 27001

Este ora 08:20 într-o marți, iar proprietarul de produs al unui gateway B2B conectat primește un mesaj de la un client reglementat: „Vă rugăm să confirmați perioada de suport de securitate pentru versiunea de firmware 4.6, SLA-ul pentru răspunsul la vulnerabilități și dacă dispozitivul va rămâne eligibil pentru actualizări de securitate pe durata contractului nostru de servicii de cinci ani.”

Până la ora 09:00, Achizițiile au transmis mai departe un chestionar de due diligence DORA. Până la 10:15, Juridicul întreabă dacă perioada de suport comunicată este aliniată cu contractele cu clienții. La 11:00, CISO este implicat într-o revizuire a riscului asociat furnizorilor în context NIS2, deoarece produsul este utilizat de un furnizor de servicii administrate din UE. După prânz, echipa de protecție a datelor întreabă dacă o bibliotecă API fără suport din partea furnizorului, inclusă în produs, ar putea afecta securitatea datelor cu caracter personal în temeiul GDPR.

Adevărul incomod devine rapid vizibil. Compania are o foaie de parcurs, un proces de aplicare a patch-urilor, un calendar de lansări și un portal de suport pentru clienți, dar nu are dovezi guvernate pentru perioada de suport de securitate.

Această lacună contează. În temeiul Actului UE privind reziliența cibernetică, perioada de suport de securitate nu este doar o etichetă de produs. Este un angajament privind ciclul de viață care afectează gestionarea vulnerabilităților, disponibilitatea actualizărilor, managementul riscului de dependență față de furnizori, comunicarea cu clienții, declarațiile contractuale și monitorizarea post-punere pe piață. Pentru furnizorii SaaS, producătorii de dispozitive, editorii de software, furnizorii cloud și furnizorii de servicii TIC, perioada de suport devine un obiect de conformitate pe care auditorii și cumpărătorii reglementați îl vor testa.

Răspunsul practic nu este încă un tabel de conformitate izolat. Răspunsul este guvernanța perioadei de suport de securitate în cadrul unui sistem de management al securității informației ISO/IEC 27001:2022, urmată de maparea acelorași dovezi la NIS2, DORA, GDPR, NIST CSF 2.0 și așteptările de audit de tip COBIT.

Acesta este modelul operațional Clarysec: utilizați SMSI ca motor de dovezi, utilizați politici aplicabile pentru definirea responsabilităților, utilizați Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pentru construirea trasabilității și utilizați Zenith Controls: The Cross-Compliance Guide Zenith Controls ca instrument de orientare pentru maparea cerințelor de conformitate între cadre.

De ce perioada de suport de securitate este acum un obiect de audit

O perioadă de suport de securitate răspunde la o întrebare simplă: cât timp va furniza producătorul actualizări de securitate, remedierea vulnerabilităților, îndrumări de atenuare și suport asociat pentru un produs sau o versiune de produs?

În practică, răspunsul depinde de numeroase elemente operaționale:

• arhitectura și mentenabilitatea produsului
• suportul pentru componente terțe și dependențe open-source
• angajamentele furnizorilor și ale serviciilor cloud
• procesele de primire, triere, remediere și divulgare a vulnerabilităților
• capacitatea de inginerie a lansărilor și de testare
• termenii contractelor cu clienții și obligațiile de reglementare
• căile de notificare pentru răspunsul la incidente și destinatarii serviciului
• păstrarea dovezilor și înregistrările de aprobare

Dacă un producător promite cinci ani de suport de securitate, dar o bibliotecă criptografică critică rămâne fără suport din partea furnizorului după trei ani, perioada de suport devine o decizie de risc. Dacă un client este o entitate financiară supusă DORA, aceeași perioadă de suport devine parte din asigurarea privind terții TIC. Dacă produsul prelucrează date cu caracter personal, software-ul fără suport din partea furnizorului poate deveni parte din responsabilitatea privind securitatea prelucrării conform GDPR. Dacă produsul susține o entitate esențială sau importantă conform NIS2, securitatea pe durata ciclului de viață devine o problemă de securitate a lanțului de aprovizionare.

NIS2 face explicită această dimensiune de guvernanță. Article 20 impune organelor de conducere ale entităților esențiale și importante să aprobe măsurile de management al riscurilor de securitate cibernetică, să supravegheze implementarea acestora și să primească instruire. Article 21 impune măsuri tehnice, operaționale și organizaționale adecvate și proporționale, inclusiv analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, achiziția securizată, dezvoltarea și mentenanța securizate, gestionarea și divulgarea vulnerabilităților, evaluarea eficacității, igiena cibernetică, criptografia, controlul accesului, managementul activelor și autentificarea. Article 23 adaugă obligații etapizate de raportare a incidentelor semnificative.

DORA creează o presiune similară pentru entitățile financiare. Impune managementul riscurilor TIC, testarea rezilienței operaționale digitale, gestionarea incidentelor și guvernanța riscului asociat terților TIC. DORA Article 28 acoperă principiile managementului riscului asociat terților TIC, iar Article 30 impune acorduri contractuale scrise, cu descrieri clare ale serviciilor, măsuri de securitate, asistență în caz de incident, drepturi de audit, drepturi de încetare și aranjamente de ieșire.

GDPR adaugă nivelul de protecție a datelor. Dacă produsul prelucrează date cu caracter personal, operatorii și persoanele împuternicite au nevoie de măsuri tehnice și organizatorice adecvate conform Article 32, claritate contractuală conform Article 28 și pregătire pentru evaluarea și notificarea încălcărilor securității datelor conform Articles 33 și 34.

De aceea, perioada de suport de securitate CRA trebuie guvernată ca o familie de controale SMSI, nu tratată ca un câmp izolat de management al produsului.

ISO 27001 ca bază de control pentru perioadele de suport de securitate CRA

ISO/IEC 27001:2022 este valoros deoarece este scalabil, bazat pe risc și orientat spre sistemul de management. Standardul impune organizației să definească contextul, părțile interesate, domeniul de aplicare și procesele care interacționează, apoi să transpună cerințele legale, de reglementare și contractuale în evaluarea riscurilor, tratamentul riscurilor, controale operaționale și dovezi ISO/IEC 27001:2022.

Pentru guvernanța perioadei de suport de securitate, aceasta înseamnă că organizația trebuie să:

1. Identifice produsele, versiunile, modulele, serviciile cloud și dependențele incluse în domeniul de aplicare.
2. Identifice părțile interesate, inclusiv clienți, autorități de reglementare, distribuitori, importatori, integratori, persoane împuternicite, persoane subîmputernicite, parteneri de răspuns la incidente și furnizori.
3. Înregistreze obligațiile de suport legale, de reglementare și contractuale.
4. Evalueze riscurile care ar putea împiedica îndeplinirea angajamentelor de suport.
5. Selecteze controale pentru managementul vulnerabilităților, dezvoltare securizată, asigurare privind furnizorii, gestionarea incidentelor, continuitatea activității, protecția datelor și informații documentate.
6. Creeze note ale Declarației de aplicabilitate care explică de ce se aplică anumite controale.
7. Revizuiască perioada de suport atunci când se schimbă arhitectura, dependențele față de furnizori, expunerea la amenințări sau angajamentele față de clienți.

Zenith Controls identifică trei controale ISO/IEC 27002:2022 relevante pentru subiect ca repere centrale ale acestei probleme de guvernanță: 5.31 cerințe legale, statutare, de reglementare și contractuale, 8.8 managementul vulnerabilităților tehnice și 8.25 ciclul de viață al dezvoltării securizate. Nu sunt singurele controale implicate, dar reprezintă coloana vertebrală a guvernanței.

Elementul esențial este trasabilitatea. O perioadă de suport pentru produs trebuie să fie trasabilă de la obligație la scenariul de risc, de la scenariul de risc la controalele selectate, de la controale la cerințele din politici și de la cerințele din politici la dovezi.

Zenith Blueprint, faza Risk Management, Step 13, descrie direct această disciplină a trasabilității:

„Corelați reglementările: dacă anumite controale sunt implementate în mod specific pentru conformitatea cu GDPR, NIS2 sau DORA, puteți consemna acest lucru fie în Registrul de riscuri (ca parte a justificării impactului riscului), fie în notele SoA.”

Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Risk Management, Step 13: Risk Treatment Planning and Statement of Applicability Zenith Blueprint

Pentru o perioadă de suport de securitate CRA, Declarația de aplicabilitate nu trebuie să spună doar „se aplică managementul vulnerabilităților”. Trebuie să explice că managementul vulnerabilităților se aplică deoarece compania are angajamente CRA privind ciclul de viață, așteptări NIS2 privind dezvoltarea securizată și lanțul de aprovizionare, cerințe de due diligence din partea clienților DORA, obligații de securitate GDPR acolo unde sunt prelucrate date cu caracter personal și promisiuni contractuale de suport.

De la promisiunea de suport la ciclul de viață guvernat

O perioadă de suport de securitate definită de producător trebuie să treacă șase teste de guvernanță.

În primul rând, trebuie definită. Organizația are nevoie de o taxonomie standard, cum ar fi suport activ, suport exclusiv pentru securitate, suport extins, suport limitat și fără suport din partea furnizorului. Fiecare stare trebuie să explice disponibilitatea actualizărilor, gestionarea vulnerabilităților, comunicarea cu clienții și căile de escaladare.

În al doilea rând, trebuie evaluată din perspectiva riscului. Cinci ani de suport pentru un produs SaaS administrat în cloud, cu canale de actualizare controlate, diferă de cinci ani pentru un dispozitiv integrat, cu constrângeri în teren, dependențe de cipuri terțe și ferestre de implementare gestionate de client.

În al treilea rând, trebuie aprobată. Funcțiile de produs, securitate, juridic, protecția datelor, suport clienți și managementul responsabil trebuie să aprobe perioada de referință și excepțiile.

În al patrulea rând, trebuie comunicată. Clienții trebuie să înțeleagă data de început a suportului, data de încetare, metoda de actualizare, canalul de raportare a vulnerabilităților, așteptările privind remedierea, consecințele încetării suportului și opțiunile disponibile de extindere.

În al cincilea rând, trebuie monitorizată. Dependențele se schimbă. Furnizorii întrerup suportul pentru biblioteci. Apar vulnerabilități. Mediile clienților se modifică. Guvernanța perioadei de suport trebuie să includă monitorizarea ciclului de viață al componentelor, revizuirea furnizorilor, fluxuri de informații privind vulnerabilitățile, jurnale ale patch-urilor, testarea lansărilor și lecții învățate din incidente.

În al șaselea rând, trebuie documentată prin dovezi. Dacă un auditor, o autoritate de reglementare sau un client reglementat solicită dovezi, organizația trebuie să poată prezenta Registrul de conformitate, registrul de suport al produselor, evaluarea riscurilor, maparea SoA, Registrul vulnerabilităților, înregistrările privind patch-urile, revizuirile furnizorilor, aprobările de lansare și notificările către clienți.

Politicile Clarysec fac acest lucru practic. Politica Enterprise Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy impune:

„Toate obligațiile legale și de reglementare trebuie mapate la politici, controale și proprietari specifici în cadrul Sistemului de management al securității informației (SMSI).”

Sursă: Legal and Regulatory Compliance Policy, Policy Implementation Requirements, clauza 6.2.1 Legal and Regulatory Compliance Policy

Pentru IMM-uri, disciplina echivalentă începe cu un registru mai simplu. Politica SME Legal and Regulatory Compliance Policy-sme Legal and Regulatory Compliance Policy - SME prevede:

„Directorul general trebuie să mențină un Registru de conformitate simplu și structurat care listează:”

Sursă: Legal and Regulatory Compliance Policy-sme, Governance Requirements, clauza 5.1.1 Legal and Regulatory Compliance Policy - SME

Un angajament privind perioada de suport trebuie inclus în Registrul de conformitate dacă este determinat de lege, contractul cu clientul, reglementarea sectorială sau așteptarea unui cumpărător reglementat. Nu trebuie să existe doar în notele de lansare sau în materialele de marketing.

Construiți un registru al perioadelor de suport de securitate CRA într-un singur atelier

Imaginați-vă un furnizor SaaS care vinde un echipament de analiză conectat către furnizori de logistică din UE și clienți din sectorul financiar. Produsul include un agent integrat, un API cloud, o aplicație mobilă de administrare și mai multe biblioteci open-source. Vânzările doresc să promită cinci ani de suport de securitate pentru fiecare versiune majoră a echipamentului.

CISO poate derula un atelier concentrat cu echipele de produs, inginerie, juridic, protecția datelor și managementul furnizorilor.

Pasul 1: Creați registrul perioadelor de suport

Creați câte un rând pentru fiecare versiune de produs și includeți:

• produsul și versiunea
• data lansării
• data de început a suportului
• data standard de încetare a suportului de securitate
• opțiunea de suport extins
• metoda de livrare a actualizărilor
• canalul de divulgare a vulnerabilităților
• ținta pentru patch-urile critice
• rolul în prelucrarea datelor, cum ar fi operator, persoană împuternicită sau ambele
• furnizorii și componentele critice
• sectoarele de clienți afectate
• proprietarul de risc
• data aprobării
• locația dovezilor

Acest registru devine informație documentată în cadrul SMSI. Zenith Blueprint, faza ISMS Foundation and Leadership, Step 6, stabilește așteptarea privind controlul documentelor:

„Documentele trebuie să aibă identificare adecvată (un titlu, eventual un număr de document sau un identificator unic, un autor), un format adecvat și revizuire și aprobare privind caracterul adecvat înainte de utilizare.”

Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza ISMS Foundation and Leadership, Step 6: Documented Information and Building the ISMS Library Zenith Blueprint

Politica Enterprise Clarysec PIMS Documented Information Evidence Management Policy PIMS Documented Information Evidence Management Policy aplică principii similare privind dovezile pentru documentația de protecție a datelor:

„[Toți] Privacy Lead / PIMS Manager TREBUIE să atribuie un identificator de document, un proprietar, un număr de versiune, starea aprobării, data intrării în vigoare și data revizuirii în REG12 înainte de publicarea informațiilor documentate ale PIMS.”

Sursă: PIMS Documented Information Evidence Management Policy, Creation, approval, versioning, and publication, clauza 4.2.1 PIMS Documented Information Evidence Management Policy

Chiar dacă registrul perioadelor de suport nu este implicit un document de protecție a datelor, se aplică aceeași disciplină: proprietar, versiune, aprobare, dată de intrare în vigoare și dată de revizuire.

Pasul 2: Corelați promisiunile de suport cu tratamentul riscurilor

Pentru fiecare versiune de produs, creați scenarii de risc precum:

• O vulnerabilitate critică este descoperită într-o versiune suportată, dar capacitatea de inginerie nu este disponibilă.
• O componentă terță rămâne fără suport din partea furnizorului înainte de încheierea perioadei declarate de suport de securitate.
• Un furnizor schimbă locația de găzduire sau subcontractantul și afectează livrarea actualizărilor.
• O vulnerabilitate afectează datele cu caracter personal și declanșează evaluarea încălcării securității datelor.
• Un client financiar reglementat solicită dovezi privind reziliența terților TIC.

Clauzele ISO/IEC 27001:2022 6.1.1 până la 6.1.3 oferă mecanismul de planificare: identificați riscurile, evaluați probabilitatea și consecințele, desemnați proprietari de risc, selectați tratamentele, comparați controalele selectate cu Anexa A, produceți Declarația de aplicabilitate și obțineți aprobarea riscului rezidual.

Pentru riscul „componentă fără suport din partea furnizorului înainte de data de încetare a suportului”, înregistrarea de risc trebuie să includă controalele ISO/IEC 27002:2022 5.31, 8.8 și 8.25, plus controale privind furnizorii, cum ar fi 5.19 securitatea informațiilor în relațiile cu furnizorii, 5.20 abordarea securității informațiilor în acordurile cu furnizorii, 5.21 gestionarea securității informațiilor în lanțul de aprovizionare TIC și 5.22 monitorizarea, revizuirea și managementul schimbărilor serviciilor furnizorilor.

Pasul 3: Stabiliți reguli privind dovezile pentru vulnerabilități și patch-uri

O perioadă de suport este credibilă numai dacă managementul vulnerabilităților funcționează pe durata acesteia.

Politica SME Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy - SME stabilește o cerință strictă pentru expuneri urgente:

„Patch-urile critice trebuie aplicate în termen de 3 zile de la lansare, în special pentru sistemele expuse la internet.”

Sursă: Vulnerability and Patch Management Policy-sme, Policy Implementation Requirements, clauza 6.1.1 Vulnerability and Patch Management Policy - SME

De asemenea, impune înregistrări pregătite pentru audit:

„Trebuie menținut un registru al patch-urilor și acesta trebuie revizuit în timpul auditurilor și al activităților de răspuns la incidente.”

Sursă: Vulnerability and Patch Management Policy-sme, Governance Requirements, clauza 5.4.1 Vulnerability and Patch Management Policy - SME

Pentru mediile enterprise, politica Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy impune:

„Un Registru de management al vulnerabilităților centralizat trebuie menținut de echipa de operațiuni de securitate și revizuit lunar de CISO sau de autoritatea delegată.”

Sursă: Vulnerability and Patch Management Policy, Governance Requirements, clauza 5.1 Vulnerability and Patch Management Policy

Zenith Blueprint, faza Controls in Action, Step 19, explică așteptarea operațională din spatele controlului ISO/IEC 27002:2022 8.8:

„Rămâneți informați despre bug-urile noi de securitate (prin alerte ale furnizorilor, fluxuri CVE etc.) pentru software-ul și hardware-ul dumneavoastră. Evaluați care sunt relevante (folosim acest software? cât de critic este bug-ul?) și aplicați prompt remedieri sau măsuri de atenuare.”

Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controls in Action, Step 19: Technological Controls I Zenith Blueprint

Fiecare versiune de produs suportată are nevoie de o pistă de audit pentru vulnerabilități: primire, analiză a relevanței, severitate, versiuni afectate, plan de remediere, lansarea remedierii, îndrumări de atenuare, comunicare cu clienții și aprobare de închidere.

Pasul 4: Conectați dezvoltarea securizată la durata suportului

Suportul de securitate începe înainte de lansare. Acesta depinde de practici de dezvoltare care fac produsul mentenabil.

Politica SME Secure Development Policy-sme Secure Development Policy - SME prevede:

„Componentele trebuie actualizate periodic atunci când sunt lansate patch-uri de securitate. Dacă este identificată o vulnerabilitate critică, componenta trebuie actualizată sau înlocuită imediat.”

Sursă: Secure Development Policy-sme, Policy Implementation Requirements, clauza 6.6.3 Secure Development Policy - SME

Politica SME Application Security Requirements Policy-sme Application Security Requirements Policy - SME impune ca acordurile și cerințele să:

„specifice obligații pentru divulgarea vulnerabilităților, timpii de răspuns și aplicarea patch-urilor.”

Sursă: Application Security Requirements Policy-sme, Governance Requirements, clauza 5.3.2 Application Security Requirements Policy - SME

Dacă o companie promite suport până în 2031, arhitectura trebuie să permită actualizări mentenabile, înlocuirea dependențelor, fluxuri de build securizate, testare de regresie și lansări de urgență. Controalele ISO/IEC 27002:2022 pentru dezvoltare securizată, arhitectură securizată, programare securizată, testare de securitate, dezvoltare externalizată, separarea mediilor și managementul schimbărilor devin factori care fac posibilă perioada de suport.

Un singur set de dovezi pentru CRA, NIS2, DORA și GDPR

Aceleași dovezi privind perioada de suport pot susține discuții de reglementare diferite, însă fiecare cadru formulează întrebarea diferit.

Dependența față de furnizori este adesea locul în care eșuează angajamentele de suport. Politica Enterprise Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy impune:

„Registrul dependențelor față de furnizori: VMO trebuie să mențină un registru actualizat al tuturor furnizorilor critici, incluzând detalii precum serviciile/produsele furnizate; dacă furnizorul este unic; furnizorii alternativi disponibili sau substituibilitatea; termenii contractuali curenți; și o evaluare a impactului dacă furnizorul ar eșua sau ar fi compromis.”

Sursă: Supplier Dependency Risk Management Policy, Implementation Requirements, clauza 6.1 Supplier Dependency Risk Management Policy

Zenith Blueprint, faza Controls in Action, Step 23, avertizează că auditorii vor inspecta acordurile cu furnizorii și dovezile de monitorizare a furnizorilor:

„Auditorii vor revizui contracte sau acorduri de servicii eșantionate. Aceștia caută clauze explicite de securitate a informațiilor, cum ar fi termene de notificare a încălcărilor, restricții de acces, obligații de prelucrare a datelor, cerințe de criptare sau drepturi de audit.”

Sursă: Zenith Blueprint: An Auditor’s 30-Step Roadmap, faza Controls in Action, Step 23: Organizational controls Zenith Blueprint

Pentru clienții DORA, acest lucru este critic. Contractele pentru servicii TIC care susțin funcții critice sau importante necesită descrieri clare ale serviciilor, condiții de subcontractare, măsuri de securitate, asistență în caz de incident, drepturi de audit și inspecție, drepturi de încetare și aranjamente de tranziție. Un furnizor care nu poate susține aceste angajamente poate împiedica producătorul să formuleze o promisiune credibilă privind perioada de suport.

Tabel de corelare a controalelor pentru guvernanța perioadei de suport pregătită pentru audit

Acest tabel de corelare permite echipelor de securitate, juridic, produs și vânzări să vorbească aceeași limbă. Registrul perioadelor de suport nu este doar dovadă CRA. Este asigurare privind furnizorii pentru NIS2, asigurare privind terții pentru DORA, suport pentru securitatea prelucrării conform GDPR și un artefact de guvernanță pentru certificarea ISO 27001.

Dimensiunea protecției datelor: când lipsa suportului devine nesiguranță

Guvernanța perioadei de suport de securitate nu este doar o problemă de securitate cibernetică. Dacă produsul stochează, transmite sau prelucrează date cu caracter personal, software-ul fără suport din partea furnizorului poate deveni un risc privind protecția datelor.

GDPR se aplică prelucrării în contextul unui sediu din UE și se poate aplica și organizațiilor din afara UE care oferă bunuri sau servicii persoanelor din UE ori le monitorizează comportamentul. Definește datele cu caracter personal în sens larg și tratează o încălcare a securității datelor cu caracter personal ca o încălcare a securității care cauzează distrugerea, pierderea, modificarea, divulgarea neautorizată sau accesul neautorizat, accidental ori ilegal, la datele cu caracter personal prelucrate.

Pentru guvernanța perioadei de suport, echipele de protecție a datelor trebuie să știe ce versiuni de produs prelucrează PII, ce sisteme sunt încă suportate și dacă vulnerabilitățile afectează confidențialitatea, integritatea sau disponibilitatea datelor cu caracter personal.

Politica Enterprise Clarysec PII Security Access Control Policy PII Security Access Control Policy impune:

„[Ambele] Proprietarul de sistem / Proprietarul de aplicație TREBUIE să înregistreze acoperirea evaluării vulnerabilităților pentru sistemele care prelucrează PII în REG12 cel puțin trimestrial și după o schimbare tehnică semnificativă.”

Sursă: PII Security Access Control Policy, Secure configuration and vulnerability management, clauza 4.7.4 PII Security Access Control Policy

Politica Enterprise Processor Subprocessor Third Party Privacy Management Policy Processor Subprocessor Third Party Privacy Management Policy adaugă monitorizare continuă pentru relațiile de protecție a datelor cu risc ridicat:

„[Toți] Vendor / Procurement Owner TREBUIE să monitorizeze trimestrial relațiile active cu persoane împuternicite și subîmputernicite cu risc ridicat și anual celelalte relații active cu persoane împuternicite și subîmputernicite PII, în raport cu condițiile de due diligence, starea contractului, starea asigurării, problemele deschise și datele de revizuire din REG08.”

Sursă: Processor Subprocessor Third Party Privacy Management Policy, Ongoing monitoring, assistance, disclosure interface, and exit, clauza 4.5.1 Processor Subprocessor Third Party Privacy Management Policy

Când o vulnerabilitate devine incident, politica Enterprise PII Incident Breach Management Policy PII Incident Breach Management Policy impune evaluarea criteriilor de raportare în mai multe cadre:

„[Condițional] Privacy Lead / PIMS Manager TREBUIE să evalueze criteriile de raportare aplicabile, legale, sectoriale, din sectorul financiar, de securitate cibernetică, contractuale, ale clienților și ale destinatarilor serviciului pentru fiecare incident PII cu impact ridicat și să înregistreze rezultatul aplicabilității în REG01, REG08 și REG10.”

Sursă: PII Incident Breach Management Policy, Classification and breach assessment, clauza 4.2.6 PII Incident Breach Management Policy

Aceasta este suprapunerea practică dintre angajamentele de suport CRA, comunicarea incidentelor NIS2, gestionarea incidentelor majore TIC conform DORA și responsabilitatea privind încălcările securității datelor conform GDPR.

Cum testează auditorii același proces privind perioada de suport

Un proces solid de guvernanță a perioadei de suport trebuie să reziste mai multor stiluri de audit. Dovezile nu se schimbă semnificativ, dar perspectiva auditorului se schimbă.

NIST CSF 2.0 este util ca nivel de comunicare, deoarece Funcția GOVERN include obligații legale, de reglementare, contractuale și de protecție a datelor, obiective de management al riscurilor, apetitul la risc, roluri, politici și supraveghere. Rezultatele sale privind lanțul de aprovizionare acoperă strategia privind furnizorii, criticitatea, contractele, due diligence, monitorizarea, coordonarea incidentelor și prevederile privind încetarea relației.

Auditorii de tip COBIT și ISACA se concentrează adesea pe proiectarea guvernanței: cine deține decizia, ce proces este definit, ce metrici arată performanța, cum sunt aprobate excepțiile și cum este gestionată îmbunătățirea continuă.

Politica Enterprise Clarysec Information Security Policy Information Security Policy surprinde principiul auditabilității:

„Toate controalele implementate trebuie să poată fi auditate, să fie susținute de proceduri documentate și de dovezi păstrate privind funcționarea.”

Sursă: Information Security Policy, Policy Implementation Requirements, clauza 6.6.1 Information Security Policy

Aceasta este propoziția pe care fiecare perioadă de suport de securitate trebuie să o poată îndeplini.

Extindeți, scurtați sau încheiați suportul fără a crea asigurare falsă

Cele mai dificile momente de guvernanță nu apar la lansarea produsului. Ele apar atunci când realitatea se schimbă.

Poate fi necesar să extindeți suportul deoarece clienții reglementați depind de produs, migrarea nu este fezabilă sau un client sectorial are nevoi contractuale de continuitate. Poate fi necesar să scurtați sau să restricționați suportul deoarece un furnizor retrage mentenanța de securitate, o componentă devine imposibil de patch-uit, o platformă atinge limite tehnice sau arhitectura produsului nu poate susține în siguranță o clasă de vulnerabilități.

O schimbare controlată a perioadei de suport trebuie să includă:

• evenimentul declanșator al schimbării, cum ar fi sfârșitul ciclului de viață la furnizor, o vulnerabilitate critică, un contract cu clientul sau o schimbare de reglementare
• produsele, versiunile, clienții și sectoarele afectate
• analiza impactului asupra datelor cu caracter personal și serviciilor critice
• revizuirea fezabilității pentru furnizori și componente
• evaluarea riscurilor și decizia privind riscul rezidual
• registrul perioadelor de suport actualizat
• notificarea actualizată către client și poziția contractuală actualizată
• notele SoA actualizate atunci când se schimbă controale sau obligații
• aprobarea conducerii și data revizuirii

Politica Enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy este utilă atunci când schimbarea este determinată de o vulnerabilitate:

„Pentru toate vulnerabilitățile confirmate trebuie elaborat un plan de remediere sau atenuare. Implementarea remedierii trebuie prioritizată în funcție de severitate. De exemplu, vulnerabilitățile critice trebuie remediate sau atenuate în termen de 14 zile, acolo unde este fezabil, ori mai repede atunci când este detectată exploatare activă, în timp ce problemele cu severitate mai redusă trebuie abordate într-un termen rezonabil.”

Sursă: Coordinated Vulnerability Disclosure Policy, Implementation Requirements, clauza 6.6 Coordinated Vulnerability Disclosure Policy

Dacă o remediere completă nu poate fi livrată imediat, controalele compensatorii, funcționalitatea dezactivată, monitorizarea sporită sau îndrumările de configurare pentru clienți pot fi acceptabile temporar, dar decizia trebuie documentată și comunicată.

Listă practică Clarysec pentru pregătirea perioadei de suport

Utilizați această listă de verificare înainte de publicarea sau reînnoirea oricărui angajament privind perioada de suport de securitate CRA.

• Produsul și versiunea sunt listate în registrul perioadelor de suport?
• Data de încetare a suportului este aprobată de funcția de produs, securitate și managementul responsabil?
• Factorii legali, de reglementare și contractuali sunt mapați în Registrul de conformitate?
• Scenariul de risc privind perioada de suport este inclus în Registrul de riscuri?
• Controalele sunt mapate în Declarația de aplicabilitate, inclusiv 5.31, 8.8 și 8.25, acolo unde sunt aplicabile?
• Furnizorii și componentele critice sunt mapate în registrul dependențelor față de furnizori?
• Există dovezi că pot fi aplicate patch-uri componentelor sau că acestea pot fi înlocuite pe durata perioadei de suport?
• Sunt definite responsabilitățile pentru primirea, trierea, remedierea și divulgarea vulnerabilităților?
• SLA-urile pentru patch-uri critice sunt aliniate la politici și la contractele cu clienții?
• Sunt păstrate jurnalele patch-urilor, înregistrările de lansare și deciziile privind vulnerabilitățile?
• Sistemele cu date cu caracter personal sunt acoperite de dovezi privind evaluarea vulnerabilităților acolo unde se prelucrează PII?
• Notificările către clienți, declarațiile de suport și termenii contractuali sunt consecvente?
• Există un proces pentru extinderea, scurtarea sau încheierea suportului cu aprobare de risc?
• Revizuirile de management primesc informații privind riscul perioadei de suport, furnizorii, vulnerabilitățile și incidentele?
• Pot fi produse dovezi în termen de 48 de ore pentru un audit al clientului sau o solicitare din partea autorității de reglementare?

Politica Enterprise PIMS Monitoring Audit Improvement Policy PIMS Monitoring Audit Improvement Policy consolidează disciplina revizuirii de management pentru programele de protecție a datelor:

„[Ambele] Conducerea de vârf TREBUIE să revizuiască neconformitățile PIMS, acțiunile corective, rezultatele monitorizării, rezultatele auditului, riscurile privind protecția datelor, asigurarea privind furnizorii și intrările privind schimbările părților interesate în REG12 în cadrul fiecărei revizuiri de management.”

Sursă: PIMS Monitoring Audit Improvement Policy, PIMS management review, clauza 4.3.5 PIMS Monitoring Audit Improvement Policy

Pentru guvernanța perioadei de suport de securitate, același ritm de revizuire trebuie aplicat în întregul SMSI: vulnerabilitățile, performanța patch-urilor, asigurarea privind furnizorii, angajamentele față de clienți, incidentele, excepțiile de suport și acțiunile corective trebuie să alimenteze revizuirea de management.

Faceți perioada de suport de securitate defensabilă

Actul UE privind reziliența cibernetică schimbă psihologia securității produselor. Îi determină pe producători și furnizorii de software să gândească dincolo de ziua lansării. Perioada de suport de securitate devine o promisiune privind ciclul de viață care trebuie proiectată, guvernată, monitorizată și documentată prin dovezi.

Pentru CISO, lecția este clară: nu lăsați perioada de suport doar în marketingul produsului. Pentru managerii de conformitate, nu construiți un siloz separat de dovezi CRA. Pentru auditori, testați dacă angajamentele de suport sunt trasabile la risc, controale, furnizori, incidente și aprobări documentate. Pentru responsabilii de business, rețineți că o perioadă de suport credibilă poate deveni un avantaj de piață, mai ales în vânzarea către sectoare reglementate NIS2, entități financiare DORA și clienți sensibili la protecția datelor.

Clarysec ajută organizațiile să operaționalizeze acest lucru prin:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pentru construirea trasabilității SMSI, a informațiilor documentate, a mapării SoA și a pregătirii pentru audit
• Zenith Controls: The Cross-Compliance Guide Zenith Controls pentru maparea controalelor ISO/IEC 27002:2022 la NIS2, DORA, GDPR, NIST CSF 2.0 și așteptări de audit
• pachete de politici Enterprise și SME pentru managementul vulnerabilităților, dezvoltare securizată, conformitate juridică, dependență față de furnizori, dovezi privind protecția datelor și răspuns la incidente
• registre practice și fluxuri de dovezi care transformă promisiunile privind perioada de suport în guvernanță auditabilă

Următorul pas este simplu: alegeți o versiune de produs reprezentativă și construiți dosarul său de dovezi privind perioada de suport de securitate. Mapați obligația, aprobați perioada de suport, testați procesul de vulnerabilități, validați dependențele față de furnizori, confirmați comunicarea cu clienții și păstrați înregistrările.

Dacă puteți susține un produs, puteți scala modelul. Dacă nu puteți susține un produs, lacuna nu este documentația. Este guvernanța.

Descărcați Zenith Blueprint, utilizați Zenith Controls pentru a vă mapa dovezile sau solicitați o evaluare Clarysec a nivelului de pregătire pentru a transforma perioadele de suport de securitate CRA în guvernanță ISO 27001 pregătită pentru audit.