De la proiectare la pregătirea pentru audit: stăpânirea cerințelor de securitate a aplicațiilor pentru ISO 27001, DORA și NIS2

Neliniștea dinaintea auditului era palpabilă. Pentru Maria, CISO al unei companii fintech de dimensiuni medii, evaluarea de conformitate DORA care urma părea mai puțin o revizuire și mai mult un moment al adevărului. Echipa ei era competentă, infrastructura fusese securizată, însă o vulnerabilitate persistentă nu îi dădea pace: universul extins și haotic al aplicațiilor organizației.

Cea mai recentă preocupare era un nou portal de plăți destinat clienților, lansat rapid pe piață pentru atingerea obiectivelor trimestriale. Echipa de dezvoltare, lucrând într-un model agile agresiv, bifase toate cerințele funcționale. Însă, atunci când echipa Mariei a rulat o scanare preliminară, rezultatele i-au confirmat temerile.

Portalul nu avea reguli robuste de expirare a sesiunilor, câmpurile de intrare erau susceptibile la atacuri de injectare de bază, iar mesajele de eroare divulgau informații sensibile despre sistem. Nu erau exploit-uri sofisticate de tip zero-day; erau defecte fundamentale de proiectare. Cauza principală era dureros de clară. Cerințele de securitate nu fuseseră niciodată definite formal, documentate sau integrate în sprinturile de dezvoltare. Echipa primise un mandat vag de a „o face sigură”, însă, fără un plan concret, securitatea a rămas o preocupare ambiguă, adesea ignorată și tratată ulterior.

Acest scenariu nu este unic. El evidențiază lacuna critică cu care se confruntă mulți CISO și lideri de conformitate: transformarea intenției „facem securitate” în cerințe explicite și testabile de securitate a aplicațiilor, aliniate la standarde fundamentale precum ISO/IEC 27001:2022 și la reglementări majore precum NIS2, DORA și GDPR.

Costul ridicat al ambiguității: ce așteaptă, de fapt, conformitatea

Esența problemei Mariei constă într-un eșec organizațional frecvent: tratarea securității ca atribut de calitate, nu ca set de cerințe nenegociabile. O cerință de securitate eficace este specifică, măsurabilă și testabilă. „Aplicația trebuie să fie sigură” este o dorință. „Aplicația trebuie să impună expirarea sesiunilor inactive după 15 minute, să valideze toate datele furnizate de utilizatori în raport cu un set predefinit de caractere și să cripteze toate datele în tranzit utilizând TLS 1.3” este o cerință. Această claritate este ceea ce caută auditorii și ceea ce au nevoie dezvoltatorii pentru a construi software securizat.

În lipsa acesteia, apare o succesiune de eșecuri:

• Implementare inconsistentă: dezvoltatori diferiți interpretează „securizat” în moduri diferite, ceea ce duce la un ansamblu fragmentat de controale, cu lacune imprevizibile.
• Costuri crescute de remediere: identificarea și remedierea unui defect de proiectare în producție este exponențial mai costisitoare decât tratarea lui în faza de proiectare.
• Neconformități de audit: auditorii vor identifica rapid absența unui proces structurat pentru definirea cerințelor de securitate, ceea ce poate conduce la constatări majore.
• Risc pentru organizație: fiecare cerință nedefinită este un potențial vector de atac, expunând organizația la încălcări ale securității datelor, pierderi financiare și prejudicii reputaționale.

În standardele moderne, așteptarea este consecventă: securitatea trebuie definită ca cerințe, din timp, și legată de risc și de obligațiile legale. Ghidul ISO/IEC 27002:2022 pentru controlul 8.26, cerințe de securitate a aplicațiilor, prevede ca organizațiile să stabilească, să documenteze și să aprobe sistematic cerințele de securitate pe baza evaluării formale a riscurilor și a cerințelor de reglementare.

Acest principiu unic este elementul central pentru o gamă largă de mandate de conformitate. Maparea transversală a conformității realizată de Clarysec în Zenith Controls: Ghidul de conformitate transversală Zenith Controls arată cum acest concept apare peste tot:

• GDPR Articles 25 și 32 prevăd „protecția datelor încă din faza de proiectare” și „securitatea prelucrării”.
• NIS2 Article 21(2)(d)-(e) pune accent pe dezvoltare securizată și securitatea lanțului de aprovizionare.
• DORA Articles 6(4), 8, 10 și 11 impun managementul riscurilor TIC și securitate prin proiectare pentru entitățile financiare.
• NIST SP 800-53 Rev.5, prin controalele SA-4 și SA-15, solicită cerințe definite de securitate a sistemului și practici de dezvoltare securizată.
• COBIT 2019, prin procesele BAI03 și DSS05, cere ca cerințele legate de securitate să fie aliniate la obiectivele organizației și la conformitate înainte ca o soluție să fie construită.

Obiectivul este să definiți, în cuvintele Zenith Blueprint: Foaia de parcurs în 30 de pași pentru auditori Zenith Blueprint, „ce înseamnă securitatea pentru aplicațiile dumneavoastră înainte ca prima linie de cod să fie scrisă.”

De ce eșuează abordările tradiționale: liste de verificare, testare târzie și teatru de securitate

Majoritatea organizațiilor realizează deja, într-o formă sau alta, securitatea aplicațiilor. Problema este că rareori aceasta este structurată într-un mod care să reziste unei certificări ISO/IEC 27001:2022 sau unei examinări de reglementare.

Tiparele frecvente de eșec includ:

1. Liste de verificare generice: echipele reutilizează pentru fiecare proiect o „listă de verificare pentru programare securizată” de o pagină. Aceasta nu este legată de riscurile specifice ale aplicației, de sensibilitatea datelor sau de contextul de reglementare. Când un auditor întreabă cum se mapează lista la GDPR Article 25, nu există un răspuns clar.
2. Securitatea ca poartă târzie: cerințele de securitate nu sunt integrate în proiectare sau în user stories. Ele apar la final ca solicitare pentru un test de penetrare. Zenith Blueprint avertizează că „bazarea pe o listă de verificare de securitate la finalul proiectului nu funcționează; acele cerințe trebuie să modeleze arhitectura, să influențeze alegerile de biblioteci și să ghideze prioritizarea funcționalităților încă din prima zi.”
3. Lipsa trasabilității de la cerință la test: poate exista o cerință de a „cripta datele în tranzit”, însă fără un caz de testare asociat care să verifice aplicarea versiunii TLS, valabilitatea certificatului și robustețea suitei criptografice. Zenith Blueprint insistă că așteptările trebuie să fie măsurabile și testabile, iar testele de securitate trebuie mapate direct la cerințele corespunzătoare.
4. Gestionare ad-hoc a codului terților: aplicațiile moderne sunt adesea „asamblate din cod intern, biblioteci terțe, API-uri și servicii native cloud”, după cum notează Zenith Blueprint. Fără cerințe explicite pentru furnizori și componente open-source, riscul lanțului de aprovizionare rămâne un punct orb major, necontrolat.

Rezultatul este teatru de securitate: documentele există și testele sunt rulate, dar atunci când un auditor sau o autoritate de reglementare caută o narațiune coerentă a cerințelor, întregul proces se destramă.

Construirea fundației: de la politică la practică

O abordare disciplinată a securității aplicațiilor începe cu guvernanță clară. Politica nu este doar birocrație; este sursa oficială a adevărului, care conferă mandat echipelor și oferă auditorilor o declarație clară de intenție. La Clarysec, proiectăm politici care sunt atât autoritative, cât și practice.

Politica privind cerințele de securitate a aplicațiilor Politica privind cerințele de securitate a aplicațiilor stabilește reguli de bază nenegociabile. De exemplu, clauza 5.2 din „Cerințe de guvernanță” impune:

Toate aplicațiile trebuie să parcurgă validarea cerințelor de securitate în etapa de planificare sau achiziție, cu aprobare documentată din partea echipei de securitate a aplicațiilor.

Această directivă simplă previne mentalitatea „construim mai întâi, securizăm mai târziu”. Politica atribuie, de asemenea, responsabilități clare. Clauza 4.3.1 din „Roluri și responsabilități” prevede că dezvoltatorii trebuie să:

Implementeze aplicațiile în conformitate cu cerințele și standardele de securitate definite.

Astfel, răspunderea pentru securitate se mută de la o echipă de securitate separată, adesea percepută ca adversarială, către creatorii software-ului. În plus, politica leagă între ele domeniile distincte de securitate. Clauza 10.2 face referire la integrarea cu alte controale-cheie:

P4 – Politica de control al accesului. Definește standardele de management al identității și al sesiunilor care trebuie aplicate de toate aplicațiile, inclusiv autentificare puternică, principiul privilegiului minim și cerințe de revizuire a drepturilor de acces.

Pentru organizațiile mai mici, o politică adaptată precum Politica privind cerințele de securitate a aplicațiilor - IMM Politica privind cerințele de securitate a aplicațiilor - IMM asigură scalabilitatea acestor principii. Ea recunoaște că, deși riscurile sunt similare, implementarea trebuie să fie pragmatică. Ambele versiuni urmăresc, în final, același rezultat: integrarea deplină a securității aplicațiilor în SMSI și pregătirea pentru audit.

O foaie de parcurs practică: construirea cerințelor de securitate a aplicațiilor pregătite pentru audit

Politica stabilește „ce” și „de ce”, dar dezvoltatorii și managerii de proiect au nevoie de „cum”. Un ghid structurat de implementare este indispensabil pentru traducerea controalelor de nivel înalt în pași acționabili. Pasul 21 din Zenith Blueprint, care se concentrează pe controlul 8.26 din ISO/IEC 27002:2022, oferă o metodologie clară în șase pași.

Să parcurgem acest proces folosind portalul de plăți al Mariei ca exemplu.

Pasul 1: porniți de la risc și de la contextul de reglementare

Utilizând rezultatul evaluării riscurilor aliniate la ISO/IEC 27005:2024 (tratarea riscului), identificați mai întâi contextul:

• Aplicație: portal de plăți self-service pentru clienți.
• Date: PII, credențiale, token-uri de plată.
• Jurisdicții: UE, servicii financiare, găzduire în cloud.
• Reglementări: GDPR, DORA, PCI DSS.

Pe baza ghidului pentru controlul 8.26 din Zenith Controls și a standardelor ISO conexe (27034-1, 27017, 27701), categoriile inițiale de cerințe trebuie să includă identificarea și autentificarea, autorizarea, clasificarea datelor, validarea intrărilor, jurnalizarea și protecția datelor în tranzit și în repaus.

Pasul 2: creați sau adoptați un șablon de cerințe de securitate

Zenith Blueprint recomandă crearea unui șablon standardizat pentru a asigura că fiecare proiect răspunde acelorași întrebări fundamentale de securitate. Acest document trebuie să devină parte din setul de instrumente pentru inițierea proiectelor.

Secțiunile minime trebuie să includă:

• Numele aplicației, proprietarul și criticitatea.
• Categoriile de date și nivelurile de sensibilitate.
• Obligațiile de reglementare și contractuale aplicabile (GDPR, DORA etc.).
• Elemente privind peisajul amenințărilor (derivate din controlul 5.7 Informații privind amenințările).
• Cerințe specifice de securitate pe categorii (autentificare, jurnalizare etc.).
• Legături cu user stories și criterii de acceptare.
• Legături cu cazurile de testare (funcționale, de securitate, de penetrare).
• Cerințe pentru furnizori și componente terțe.

Pasul 3: integrați cerințele în artefactele agile

Cerințele de securitate trebuie integrate direct în user stories și criterii de acceptare. Pentru epicul „înregistrarea clientului” din proiectul portalului Mariei, aceasta înseamnă transformarea unei povești funcționale simple într-una care include securitatea încă din formulare.

• User story inițial: „Ca utilizator nou, pot crea un cont.”
• User story securizat: „Ca nou client, vreau să creez un cont securizat, astfel încât informațiile mele de plată să fie protejate.”
• Criterii de acceptare (cu securitate integrată):
  • Sistemul trebuie să impună o politică privind parolele puternice, în conformitate cu P4 – Politica de control al accesului.
  • Sistemul trebuie să solicite verificarea e-mailului printr-un link unic înainte de activarea contului.
  • Formularul de creare a contului trebuie protejat prin CAPTCHA pentru a preveni atacurile bot.
  • Toate încercările de înregistrare trebuie jurnalizate cu IP-ul sursă și amprenta dispozitivului.
  • Toate datele transmise prin formular trebuie sanitizate pentru a preveni cross-site scripting (XSS).

Acestea nu sunt sarcini de securitate separate; ele fac parte integrantă din definiția „finalizat” a funcționalității.

Pasul 4: legați cerințele de testarea de securitate

Utilizând controlul 8.29 Testare de securitate din Zenith Controls, vă asigurați că fiecare cerință are un caz de testare asociat. Astfel se închide bucla și se furnizează dovezi verificabile privind eficacitatea controalelor.

• Cerință: criptare în tranzit cu TLS 1.3. → Test: scanare automatizată pentru verificarea aplicării TLS, a valabilității certificatului și a suitelor criptografice aprobate.
• Cerință: validarea intrărilor pentru prevenirea SQL injection. → Test: scanare automatizată SAST/DAST și fuzzing manual în timpul QA.
• Cerință: expirarea sesiunii inactive după 15 minute. → Test: teste automate și manuale pentru confirmarea invalidării sesiunii pe partea de server după 15 minute de inactivitate.

Pasul 5: extindeți cerințele la lanțul de aprovizionare

Deoarece controlul ISO 8.26 este legat de securitatea furnizorilor (5.19, 5.20) și de dezvoltarea externalizată (8.30) în Zenith Controls, procesul trebuie să acopere codul terților. Pentru IMM-urile care depind puternic de biblioteci externe, clauza de politică din Politica privind cerințele de securitate a aplicațiilor - IMM este critică:

Orice instrument terț, plugin sau bibliotecă de cod extern utilizată într-o aplicație trebuie înregistrată și revizuită anual din perspectiva impactului asupra securității și a stării patch-urilor.

Această cerință simplă și pragmatică impune o mentalitate de software bill of materials (SBOM), care reprezintă o așteptare-cheie în reglementări precum NIS2. Pentru furnizorii majori, aceleași cerințe de securitate a aplicațiilor trebuie incluse în contracte, cu referire la ISO/IEC 27036-1 (securitatea lanțului de aprovizionare TIC).

Pasul 6: instituiți reevaluarea periodică

Pe măsură ce aplicațiile evoluează, evoluează și riscurile lor. Ghidul Zenith Blueprint privind reevaluarea periodică este esențial. Când integrați un nou API sau migrați către un alt serviciu cloud, contextul de risc se schimbă. Aceasta trebuie să declanșeze o revizuire a cerințelor de securitate existente pentru a confirma că rămân adecvate. Această abordare se aliniază cu ISO/IEC 27005:2024 (tratarea continuă a riscurilor) și transformă securitatea aplicațiilor într-o practică permanentă, nu într-un proiect punctual.

Deconstruirea ecosistemului de controale

Un control ISO nu există niciodată în izolare. Securitatea eficace se bazează pe o rețea interconectată de măsuri. Adevărata valoare a controlului 8.26 este obținută atunci când îi înțelegeți relația cu alte controale, perspectivă detaliată în Zenith Controls.

Controlul 8.26 este clasificat drept control preventiv, dar acționează ca nod central pentru întregul proces de dezvoltare securizată, conectându-se la:

• 8.25 - Ciclul de viață al dezvoltării securizate: acesta este cadrul general. Controlul 8.26 furnizează ce-ul specific (cerințele) care trebuie integrat în cum-ul procesului SDLC.
• 8.27 - Arhitectură securizată a sistemelor și principii de inginerie: cerințele determină deciziile arhitecturale, asigurând că securitatea este fundamentală.
• 8.28 - Programare securizată: după definirea cerințelor (de exemplu, „prevenirea SQL injection”), standardele de programare securizată le oferă dezvoltatorilor tehnicile necesare pentru a îndeplini cerința.
• 8.29 - Testarea de securitate în dezvoltare și acceptare: acest control validează că cerințele definite în 8.26 au fost implementate corect.
• 5.34 - Confidențialitatea și protecția PII: atunci când o aplicație prelucrează date cu caracter personal, cerințele din 8.26 trebuie să integreze principiile protecției datelor încă din faza de proiectare.
• 5.19 și 5.20 - Securitatea informației în relațiile cu furnizorii: pentru aplicațiile achiziționate sau externalizate, controlul 8.26 impune extinderea cerințelor de securitate în lanțul de aprovizionare.

Privirea acestor controale ca ecosistem, nu ca listă de verificare, vă permite să construiți un profil de risc al securității stratificat și defensabil.

Perspectiva auditorului: pregătirea pentru examinare

Auditorii gândesc în termeni de dovezi. Pentru a vă pregăti, trebuie să înțelegeți perspectivele diferite pe care le poate avea un auditor. Secțiunea privind metodologia de audit din Zenith Controls anticipează aceste abordări variate.

Înțelegerea acestor perspective vă permite să pregătiți un portofoliu complet de dovezi care demonstrează un proces viu, funcțional și integrat în organizație.

Busola conformității transversale: un proces, mai multe cadre

Pentru o companie precum cea a Mariei, satisfacerea DORA, GDPR și NIS2 este obligatorie. Maparea manuală a controalelor este o rețetă pentru efort duplicat și lacune de conformitate. O abordare centralizată și transversală a conformității oferă valoare semnificativă. Definirea cerințelor de securitate a aplicațiilor reprezintă implementarea practică a principiului „securitate prin proiectare” care stă la baza tuturor acestor reglementări moderne.

Prin implementarea unui proces robust pentru cerințele de securitate a aplicațiilor bazat pe ISO/IEC 27002:2022, construiți simultan dovezi pentru a satisface o parte semnificativă a acestor alte reglementări. Nu doar „faceți ISO”; construiți un program de securitate conform în mod universal.

De la haos la control: direcția de urmat

Povestea Mariei are un deznodământ pozitiv. Ea a folosit incidentul portalului de plăți ca accelerator al schimbării. Având la dispoziție un cadru clar de politici de la Clarysec și un ghid practic de implementare, și-a adus la aceeași masă echipele de dezvoltare, securitate și produs. Acestea au utilizat metodologia Zenith Blueprint pentru a defini retroactiv cerințele portalului, prioritizând remedierea în funcție de risc.

Mai important, au stabilit un nou mod de lucru. „Lista de verificare de securitate” a fost înlocuită cu sesiuni colaborative de proiectare. Când au sosit auditorii DORA, Maria a putut nu doar să le arate o aplicație securizată, ci și să demonstreze un proces matur și repetabil prin care toate aplicațiile viitoare urmau să fie construite pe o fundație de securitate.

Transformarea profilului de risc al securității aplicațiilor începe cu un singur pas structurat. Direcția de urmat este clară:

1. Stabiliți guvernanța: implementați o politică formală pentru definirea cerințelor de securitate a aplicațiilor. Șabloanele noastre, precum Politica privind cerințele de securitate a aplicațiilor, oferă un punct de pornire pregătit pentru audit.
2. Adoptați un cadru practic: utilizați Zenith Blueprint pentru a integra cerințele de securitate direct în ciclul de viață al dezvoltării, făcându-le acționabile, testabile și trasabile.
3. Înțelegeți contextul complet: folosiți Zenith Controls pentru a vedea cum acest control critic se conectează la ecosistemul mai larg de securitate și cum se mapează la DORA, NIS2, GDPR și altele.
4. Extindeți la portofoliu: după ce abordarea funcționează pentru o aplicație, extindeți-o la întregul portofoliu prin integrarea șablonului de cerințe de securitate în listele standard de verificare pentru inițierea proiectelor, în șabloanele agile și în procesele de achiziție.

Dacă doriți să accelerați această transformare, Clarysec oferă politici predefinite, foi de parcurs pentru implementare și mapări transversale de conformitate pentru a vă ajuta să treceți de la eforturi fragmentate la un program demonstrabil matur și pregătit pentru audit. Nu mai tratați securitatea aplicațiilor ca pe o inspecție la poarta finală. Începeți să o integrați în planul de proiectare al tuturor lucrurilor pe care le creați.