Cybersecurity Fundamentals/Cyfun (adaptarea NIST CSF2.0) aduce ca noutate, așa cum am mai scris, introducerea domeniului Guvernare în cadrul cerințelor de securitate.

Nu știu cîte dintre ”organele de conducere” au fost informate cu privire la două contravenții care apar în OUG155/2024:

• nerespectarea de către membrii organelor de conducere ale entităților esențiale și importante a obligației de supraveghere a punerii în aplicare a măsurilor de gestionare a riscurilor;
• nerespectarea de către membrii organelor de conducere ale entităților esențiale și importante a obligației de alocare a resurselor

Mai jos urmează o explicație/exemplu de implementare a controalelor din subcategoria GV.OC plecînd de la cele de mai sus

1. GV.OC – contextul organizațional

Când o organizație începe să își construiască sau să își maturizeze guvernanța securității cibernetice, tentația este aproape mereu aceeași: să pornească direct cu măsuri tehnice, evaluări de risc, controale, procese de răspuns la incidente sau cerințe pentru furnizori. Toate acestea sunt necesare. Dar dacă lipsesc întrebările de bază, tot edificiul rămâne fragil.

• Ce protejăm, de fapt?
• De ce este acel lucru important pentru organizație?
• Cine depinde de noi?
• De cine depindem noi?
• Ce obligații ne limitează și ne definesc?
• Cine decide?
• Cine răspunde?

GV.OC nu trebuie tratat ca o secțiune introductivă sau ca un exercițiu de documentare „ca să fie”. O altă bifă…. În realitate, este cel mai important element al întregului program de securitate. Dacă este implementat superficial, celelalte categorii vor suferi. Dacă este implementat bine, devine fundamentul pe care se sprijină managementul riscului, continuitatea, conformitatea, relația cu furnizorii și chiar deciziile de investiții.

2. Securitatea trebuie legată de misiune, nu doar de tehnologie

Una dintre cele mai frecvente greșeli întîlnită în organizațiile autohtone este tratarea securității cibernetice ca disciplină exclusiv tehnică. Se vorbește despre rețele, endpointuri, aplicații, acces, loguri și protecție perimetrală. Toate aceste lucruri contează. Dar ele sunt mijloace, nu scop.

O organizație nu există pentru a-și proteja firewall-ul/AD-ul/ERP-ul/CRM-ul….

Orice organizație există pentru a-și îndeplini misiunea.

Din acest motiv, prima cerință în implementarea GV.OC este să legi securitatea de misiunea reală a organizației. Asta înseamnă să clarifici, în termeni de business, de ce contează securitatea pentru modelul de funcționare al organizației tale. Confidențialitatea, integritatea, disponibilitatea și conformitatea nu trebuie tratate ca termeni standard, ci reinterpretate în raport cu capacitatea organizației de a livra ceea ce promite. 

În loc să spui generic că trebuie protejate informațiile, trebuie să poți spune:

• ce tip de încredere trebuie protejat;
• ce conținut sau serviciu trebuie menținut autentic;
• ce operațiuni trebuie să rămână disponibile;
• ce obligații sunt atât de importante încât, dacă sunt încălcate, organizația nu mai poate funcționa în parametri acceptabili.

Aici începe de fapt guvernanța. Nu la tehnologie, ci la sens.

3. Contextul organizațional este baza deciziei

Un document de context organizațional nu trebuie să fie o descriere generală a companiei. El trebuie să explice, într-o formă utilă pentru managementul riscului, cum arată organizația, cum operează și ce elemente o fac vulnerabilă sau rezilientă.

Asta înseamnă că documentul trebuie să acopere cel puțin:

• activitățile relevante;
• funcțiile organizaționale;
• produsele și serviciile;
• lanțurile de aprovizionare și dependențele externe;
• problemele interne și externe care influențează securitatea 

Acest tip de conținut este important pentru că securitatea cibernetică nu protejează abstracțiuni cum sînt C-I-A. Ea protejează activități concrete: servicii livrate, date gestionate, platforme utilizate, parteneriate, obligații contractuale și reputație.

Dacă organizația nu și-a clarificat bine acest context, atunci toate etapele următoare vor fi construite pe presupuneri incomplete. Vei face evaluări de risc fără să știi exact ce este critic. Vei formula cerințe de securitate fără să știi exact cine depinde de tine. Vei defini obiective fără să fie clar ce trebuie de fapt susținut. 

4. Părțile interesate contează doar dacă le înțelegi așteptările

După misiune, al doilea punct important în GV.OC este identificarea părților interesate și a cerințelor acestora.Multe organizații ajung până la nivelul la care fac o listă cu:

• clienți,
• furnizori,
• autorități,
• angajați,
• parteneri.

Dar aici se opresc. Iar această abordare este insuficientă.

Valoarea reală apare abia când organizația poate răspunde clar la întrebarea: ce așteaptă aceste părți de la noi în materie de securitate, continuitate, încredere, conformitate și reziliență? Investitorii au așteptări legate de valoarea acțiunilor, profit și reputație. Conducerea are nevoie de control și raportare. Utilizatorii finali așteaptă disponibilitate și protecția datelor. Sursele jurnalistice așteaptă confidențialitate. Advertiserii și distribuitorii au așteptări contractuale și operaționale. Autoritățile au așteptări de conformitate și notificare. 

Pentru ca această abordare să fie suficientă, trebuie să știi:

• cine actualizează aceste informații;
• cum se identifică noi părți interesate;
• ce evenimente declanșează revizuirea;
• unde se păstrează evidențele modificărilor.

Asta face diferența între un template de context și un document cu adevărat operațional.

5. Cerințele legale și de reglementare nu sunt un apendice

O altă capcană frecventă este tratarea cerințelor legale și de reglementare ca o anexă standard. Se introduc câteva acte normative, eventual câteva trimiteri la GDPR sau NIS2, și subiectul este declarat închis. În realitate, cadrul legal este parte integrantă din contextul organizațional. El definește:

• obligațiile de notificare;
• obligațiile de protecție;
• limitele acceptabile de funcționare;
• cerințele de raportare și trasabilitate;
• consecințele juridice ale unui eșec de securitate.

Identificarea completă a obligațiilor trebuie să fie consolidată de funcția juridică și/sau de conformitate:

• funcția juridică sau de conformitate este Accountable pentru registrul cerințelor legale și pentru procedura de actualizare a acestora;
• CISO este Responsible sau Consulted pentru partea de securitate cibernetică, dar nu ar trebui să fie responsabil pentru interpretarea cadrului normativ.

6. Ordinea de lucru

Multe organizații vor să definească rapid măsurile de securitate: ce entități/unități funcționale intră, ce servicii intră, ce procese sunt incluse, ce este exclus (aducere aminte Contextul din ISO 27001). Dar acest lucru nu poate fi făcut corect înainte de a clarifica:

• contextul organizațional;
• serviciile și procesele critice;
• dependențele externe;
• obligațiile legale și contractuale;
• așteptările stakeholderilor.

Organizația are componente care depind de BIA, de validarea furnizorilor critici și de clarificarea anumitor zone legale sau organizaționale.  Trebuie să știi că GV.OC se construiește iterativ. Ordinea sănătoasă/corectă este:

1. misiune și context;
2. BIA și servicii critice;
3. stakeholderi și cerințe;
4. legal și conformitate;
5. domeniu de aplicare;
6. obiective și guvernanță.

Dacă această ordine este respectată, documentele se așază natural unul peste altul.

7. Obiectivele de securitate trebuie să fie efecte ale contextului

Un program matur de securitate nu se oprește la descriere, el produce obiective.

Obiectivele de securitate trebuie să fie măsurabile, nu rupte de realitate. Ele rezultă din misiune, din context, din cerințele părților interesate și din obligațiile externe. Testarea planurilor de continuitate, implementarea controalelor, instruirea rolurilor critice, reducerea riscurilor ridicate și notificarea în termen a incidentelor sunt exemple de obiective care au sens pentru business și pentru guvernanță. 

Aici este una dintre cele mai importante idei din GV.OC: obiectivele de securitate nu ar trebui inventate separat. Ele ar trebui să fie rezultatul firesc al contextului organizațional.

Când o organizație știe ce vrea să protejeze, de ce vrea să protejeze acel lucru, cine depinde de ea și ce obligații are, obiectivele apar natural. În absența acestui context, obiectivele tind să devină fie prea tehnice, fie prea generale, fie greu de apărat.

8. Cine trebuie să fie Accountable și cine Responsible

Poate cea mai practică întrebare care apare în implementarea GV.OC este: cine răspunde pentru acest domeniu?

GV.OC este transversal și include documente cu naturi foarte diferite: unele sunt strategice, altele operaționale, altele juridice, altele legate de continuitate sau de supply chain.

Recomandare:

Documentele principale din GV.OC

Context organizațional și alinierea managementului riscului cibernetic cu misiunea

• Accountable: CEO
• Responsible: CISO

Politica și procesul BIA

• Accountable: COO
• Responsible: BCM Manager

Serviciile critice

• Accountable: COO
• Responsible: ownerii de servicii și BCM Manager

Furnizori critici

• Accountable: Achiziții
• Responsible: Achiziții / Contract Manager, cu suport din partea CISO

Cerințele legale, de reglementare și contractuale

• Accountable: Juridic / Conformitate
• Responsible: Juridic / Conformitate/CISO

Părțile interesate și cerințele acestora

• Accountable: CEO
• Responsible: CISO

8. Ce înseamnă o implementare bună de GV.OC

O implementare bună (maturitate 3) de GV.OC nu înseamnă să ai multe documente. Nu înseamnă nici să ai un document foarte lung. Și nici să bifezi formal fiecare sub-control. Înseamnă, în esență, să poți demonstra că organizația:

• își înțelege misiunea;
• își înțelege contextul;
• știe ce servicii și capabilități sunt critice;
• știe cine sunt părțile interesate relevante și ce așteptări au;
• își cunoaște obligațiile;
• își distribuie responsabilitatea documentară și operațională la rolurile potrivite;
• și menține aceste informații actualizate.

Dacă aceste lucruri există și sunt coerente, restul cerințelor are șanse mari să fie corect abordate. Dacă lipsesc, toate celelalte documente riscă să fie doar bine redactate, nu și bine fundamentate. Din această perspectivă, GV.OC este probabil cea mai „executivă” parte a guvernanței cibernetice. Ea obligă organizația să spună clar ce este important, de ce este important și cine răspunde pentru menținerea acestui adevăr organizațional.

9. Fără GV.OC, securitatea rămâne birocratică

Fără un GV.OC bun, securitatea rămâne o listă de măsuri bifate într-un Excel
Cu un GV.OC bun, securitatea devine guvernanță.

O securitate matură nu începe cu „ce controale implementăm?”, ci cu „ce fel de organizație suntem și ce trebuie să protejăm ca să ne putem îndeplini misiunea?”. Odată ce răspunsul la această întrebare este clar, restul începe să se lege:

• riscul are sens,
• BIA are sens,
• cerințele furnizorilor au sens,
• monitorizarea are sens,
• iar responsabilitățile nu mai sunt arbitrare.

10. Pe scurt

Ca să implementezi GV.OC corect:

• pornești de la misiune, nu de la tehnologie;
• descrii contextul, nu doar infrastructura;
• identifici stakeholderii și așteptările lor reale;
• tratezi juridicul ca parte din context;
• construiești obiective care derivă din context;
• distribui responsabilitate la rolurile corecte.