Dovezi DORA TLPT corelate cu controale ISO 27001

Este ora 07:40, într-o dimineață de luni, iar CISO al unei instituții de plată de dimensiune medie privește trei versiuni ale aceleiași întrebări incomode.

Consiliul de administrație vrea să știe dacă organizația poate rezista unei indisponibilități a portalului de plăți pentru clienți cauzate de ransomware. Autoritatea de reglementare vrea dovezi că testarea rezilienței operaționale digitale nu este un exercițiu PowerPoint. Auditul intern vrea o pistă clară de la obligațiile DORA la riscul TIC, controale ISO 27001, rezultatele testelor, planuri de remediere, dovezi de la furnizori și aprobarea conducerii.

CISO are un raport Red Team. SOC are capturi de ecran ale alertelor. Echipa de infrastructură are un jurnal de restaurare din backup. Juridicul are un instrument de urmărire a pregătirii pentru DORA. Achizițiile au atestări de la furnizorul cloud.

Nimic nu este conectat.

Aici eșuează multe programe DORA TLPT și de testare a rezilienței. Nu pentru că testarea este slabă, ci pentru că dovezile sunt fragmentate. Când un auditor întreabă „Arătați-mi cum dovedește acest test reziliența unei funcții critice sau importante”, răspunsul nu poate fi un folder plin cu capturi de ecran. Trebuie să fie un lanț de dovezi defensabil.

Acest lanț este zona în care un SMSI aliniat la ISO/IEC 27001:2022 ISO/IEC 27001:2022 devine puternic. ISO 27001 oferă structură pentru domeniul de aplicare, evaluarea riscurilor, selectarea controalelor, Declarația de aplicabilitate, controlul operațional, auditul intern, revizuirea de management și îmbunătățirea continuă. DORA adaugă presiunea sectorială. Metodologia Clarysec și instrumentele sale de conformitate transversală le conectează pe ambele într-un singur model de dovezi pregătit pentru audit.

DORA TLPT este un test de guvernanță, nu doar o simulare de atac

Testarea de penetrare bazată pe informații privind amenințările, sau TLPT, este ușor de interpretat greșit. Din punct de vedere tehnic, poate arăta ca un exercițiu Red Team sofisticat: informații privind amenințările, căi realiste de atac, discreție, tentative de exploatare, scenarii de mișcare laterală și validarea răspunsului Blue Team.

Pentru DORA, problema de fond este reziliența operațională digitală. Poate entitatea financiară să reziste, să răspundă și să se recupereze după o perturbare TIC severă care afectează procesele de afaceri? Poate demonstra că funcțiile critice sau importante rămân în limitele toleranțelor la impact? Poate managementul să demonstreze că riscul TIC este guvernat, finanțat, testat, remediat și îmbunătățit?

DORA Article 1 stabilește un cadru uniform al UE pentru securitatea rețelelor și a sistemelor informatice care susțin procesele de afaceri ale entităților financiare. Acesta acoperă managementul riscurilor TIC, raportarea incidentelor majore legate de TIC, testarea rezilienței operaționale digitale, managementul riscurilor TIC asociate terților, cerințele contractuale obligatorii pentru furnizorii TIC, supravegherea furnizorilor terți critici de servicii TIC și cooperarea în materie de supraveghere. DORA se aplică de la 17 ianuarie 2025.

Pentru organizațiile acoperite și de NIS2, DORA acționează ca act juridic sectorial al Uniunii pentru cerințele de securitate cibernetică suprapuse. În termeni practici, entitățile financiare trebuie să prioritizeze DORA pentru managementul riscurilor TIC, raportarea incidentelor, testare și riscul TIC asociat terților acolo unde regimurile se suprapun, menținând în același timp înțelegerea așteptărilor NIS2 pentru structurile de grup, furnizori și servicii digitale nefinanciare.

DORA plasează, de asemenea, responsabilitatea la nivelul cel mai înalt. Article 5 impune organismului de conducere să definească, să aprobe, să supravegheze și să implementeze măsurile privind riscul TIC. Aceasta include strategia de reziliență operațională digitală, politica de continuitate a activității TIC, planurile de răspuns și recuperare, planurile de audit, bugetele, politicile privind terții TIC, canalele de raportare și un nivel suficient de cunoștințe privind riscul TIC prin instruire periodică.

Prin urmare, întrebarea de audit nu este doar: „Ați rulat un TLPT?”

Este:

• A fost TLPT legat de funcții critice sau importante?
• A fost autorizat, încadrat în domeniul de aplicare, sigur și evaluat din punctul de vedere al riscului?
• Au fost incluși furnizorii, dependențele cloud și serviciile TIC externalizate, acolo unde este relevant?
• A generat testul dovezi privind detectarea, răspunsul, recuperarea și lecțiile învățate?
• Au fost constatările convertite în tratamentul riscului, remediere urmărită, retestare și raportare către management?
• A explicat Declarația de aplicabilitate ce controale din Anexa A ISO 27001 au fost selectate pentru gestionarea riscului?

De aceea, Clarysec tratează dovezile DORA TLPT ca pe o problemă de dovezi SMSI, nu doar ca pe un livrabil de testare de penetrare.

Construiți coloana vertebrală a dovezilor ISO 27001 înainte de începerea testului

ISO 27001 impune organizației să stabilească, să implementeze, să mențină și să îmbunătățească continuu un SMSI care păstrează confidențialitatea, integritatea și disponibilitatea printr-un proces de management al riscurilor. Clauzele 4.1–4.4 impun organizației să înțeleagă aspectele interne și externe, părțile interesate, obligațiile legale și de reglementare, interfețele și dependențele, apoi să documenteze domeniul de aplicare al SMSI.

Pentru o entitate reglementată de DORA, această etapă de definire a domeniului trebuie să surprindă explicit funcțiile critice sau importante, activele TIC, platformele cloud, operațiunile externalizate, sistemele de plăți, portalurile pentru clienți, serviciile de identitate, platformele de jurnalizare, mediile de recuperare și furnizorii terți de servicii TIC. Dacă domeniul TLPT nu se mapează înapoi la domeniul de aplicare al SMSI, pista de audit este deja slabă.

ISO 27001 Clauses 6.1.1, 6.1.2 și 6.1.3, împreună cu Clauses 8.2 și 8.3, impun un proces de evaluare a riscurilor și de tratare a riscurilor. Riscurile trebuie identificate în raport cu confidențialitatea, integritatea și disponibilitatea. Trebuie desemnați proprietari de risc. Probabilitatea și consecința trebuie evaluate. Controalele trebuie selectate și comparate cu Anexa A. Riscul rezidual trebuie acceptat de proprietarii de risc.

Aceasta este puntea dintre DORA și testarea pregătită pentru audit.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint de la Clarysec, în faza Risk Management, Step 13, descrie clar acest rol de trasabilitate:

SoA este, de fapt, un document-punte: leagă evaluarea/tratamentul riscului de controalele efective existente. Prin completarea sa, verificați încă o dată dacă ați omis vreun control.

Pentru DORA TLPT, Declarația de aplicabilitate nu trebuie să fie un artefact static de certificare. Aceasta trebuie să explice de ce controale precum securitatea furnizorilor, gestionarea incidentelor, pregătirea TIC pentru continuitatea activității, jurnalizarea, monitorizarea, managementul tehnic al vulnerabilităților, backup-urile, dezvoltarea securizată și testarea de securitate sunt aplicabile scenariului de reziliență.

Un scenariu practic de risc ar putea fi formulat astfel:

„Compromiterea credențialelor privilegiate ale furnizorului de identitate permite unui atacator să acceseze sistemele de administrare a procesării plăților, să modifice configurațiile de rutare și să perturbe o funcție critică de plată, generând indisponibilitatea serviciului, obligații de raportare către autorități, prejudicii pentru clienți și prejudicii reputaționale.”

Acest singur scenariu poate determina domeniul TLPT, cazurile de utilizare pentru detectare, implicarea furnizorilor, exercițiul de recuperare, raportarea către consiliul de administrație și setul de dovezi.

Zenith Blueprint recomandă și ca trasabilitatea de reglementare să fie explicită:

Faceți trimiteri încrucișate la reglementări: dacă anumite controale sunt implementate în mod specific pentru conformitatea cu GDPR, NIS2 sau DORA, puteți nota acest lucru fie în Registrul de riscuri, ca parte a justificării impactului riscului, fie în notele SoA.

Acest sfat este simplu, dar schimbă conversația de audit. În loc să spună unui auditor că DORA a fost luat în considerare, organizația poate arăta unde apare DORA în registrul de riscuri, SoA, programul de testare, setul de politici și revizuirea de management.

Mapați testarea DORA la controale ISO 27001 pe care auditorii le recunosc

DORA Article 6 așteaptă un cadru documentat de management al riscurilor TIC, integrat în managementul general al riscurilor. Anexa A ISO 27001 oferă catalogul de controale care face acest lucru operațional.

Pentru DORA TLPT și testarea rezilienței, aceste controale din Anexa A ISO/IEC 27001:2022 sunt deosebit de importante:

Zenith Controls: The Cross-Compliance Guide Zenith Controls de la Clarysec ajută organizațiile să evite tratarea acestor controale ca elemente izolate de listă de verificare. Acesta mapează controalele ISO/IEC 27002:2022 la atribute, domenii, capabilități operaționale, așteptări de audit și tipare între cadre.

De exemplu, Zenith Controls clasifică controlul ISO/IEC 27002:2022 5.30, pregătirea TIC pentru continuitatea activității, ca „Corectiv”, aliniat cu „Disponibilitate”, asociat conceptului de securitate cibernetică „Răspuns” și plasat în domeniul „Reziliență”. Această clasificare este utilă când se explică auditorilor de ce un exercițiu de recuperare nu este doar o operațiune IT, ci un control de reziliență cu rol definit în mediul de control.

Zenith Controls clasifică și controlul 8.29, Testarea securității în dezvoltare și acceptare, ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea, cu capabilități operaționale în securitatea aplicațiilor, asigurarea securității informației și securitatea sistemelor și rețelelor. Pentru constatările TLPT care se leagă de o slăbiciune de proiectare a aplicației, comportament API nesigur, flux de autentificare deficitar sau validare inadecvată, aceasta este calea de control către guvernanța dezvoltării securizate.

Controlul 5.35, Revizuirea independentă a securității informației, este de asemenea important. Acesta susține contestarea independentă, asigurarea guvernanței și îmbunătățirea corectivă. Echipele interne pot coordona testarea, dar dovezile pregătite pentru audit necesită revizuire, escaladare și supraveghere dincolo de persoanele care au construit sau au operat sistemele testate.

Protejați sistemul în timp ce îl testați

O presupunere periculoasă în testarea rezilienței este că testarea este automat benefică. În realitate, testarea intruzivă poate crea indisponibilități ale serviciilor, poate expune date sensibile, poate polua jurnale, poate declanșa mecanisme automate de apărare, poate întrerupe sesiunile clienților sau poate determina furnizorii să invoce proceduri de urgență.

Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy de la Clarysec oferă organizațiilor un model de guvernanță pentru executare sigură. Clauza 6.1 prevede:

Tipuri de teste: programul de testare de securitate trebuie să includă, cel puțin: (a) scanări de vulnerabilitate, constând în scanări automate săptămânale sau lunare ale rețelelor și aplicațiilor pentru identificarea vulnerabilităților cunoscute; (b) testare de penetrare, constând în testare manuală aprofundată a unor sisteme sau aplicații specifice de către testeri calificați pentru identificarea punctelor slabe complexe; și (c) exerciții Red Team, constând în simulări bazate pe scenarii ale unor atacuri reale, inclusiv inginerie socială și alte tactici, pentru a testa capabilitățile de detectare și răspuns ale organizației în ansamblu.

Pentru TLPT, componenta Red Team este evidentă, dar valoarea de audit provine din proiectarea programului. Scanările de vulnerabilitate, testarea de penetrare, exercițiile Red Team, exercițiile de reziliență și retestarea trebuie să formeze un ciclu, nu o colecție de teste neconectate.

Clauza 6.2 a aceleiași politici tratează executarea sigură:

Domeniu de aplicare și reguli de angajament: pentru fiecare test sau exercițiu, STC trebuie să definească domeniul de aplicare, inclusiv sistemele și intervalele IP incluse, metodele de testare permise, obiectivele, momentul și durata. Regulile de angajament trebuie documentate. De exemplu, sistemele sensibile operațional pot fi desemnate ca doar monitorizate, pentru a evita perturbarea, iar orice testare în producție trebuie să includă proceduri de revenire și oprire. Măsurile de siguranță, cum ar fi ferestrele de timp definite și canalele de comunicare, trebuie stabilite pentru a preveni întreruperile neintenționate ale serviciilor.

Aceasta se mapează direct la Zenith Blueprint, faza Controls in Action, Step 21, care se concentrează pe controlul 8.34 din Anexa A ISO 27001, Protecția sistemelor informatice în timpul testării de audit. Zenith Blueprint avertizează că auditurile, testele de penetrare, analizele criminalistice și evaluările operaționale pot implica privilegii ridicate, instrumente intruzive sau modificări temporare ale comportamentului sistemului. Acesta subliniază autorizarea, domeniul de aplicare, ferestrele de timp, aprobarea proprietarului de sistem, revenirea controlată, monitorizarea și gestionarea securizată a datelor de test.

Pachetul de dovezi pregătit pentru audit trebuie să includă:

• mandatul și obiectivele TLPT
• rezumatul informațiilor privind amenințările și justificarea scenariului
• funcțiile critice sau importante incluse în domeniu
• sistemele, intervalele IP, identitățile, furnizorii și mediile incluse în domeniu
• excluderile și sistemele doar monitorizate
• regulile de angajament
• evaluarea riscurilor pentru testarea în producție
• procedurile de revenire și oprire
• modelul de notificare SOC, inclusiv ce se comunică și ce se reține
• aprobări juridice, de confidențialitate și de la furnizori
• dovezi privind crearea și revocarea conturilor de test
• locația securizată de stocare pentru artefactele de test și jurnale

Un DORA TLPT care nu poate demonstra autorizarea sigură și controlul activității de testare poate evidenția lacune de reziliență, dar creează și lacune de guvernanță.

Transformați rezultatele TLPT în tratamentul riscului

Cel mai frecvent eșec post-test este problema raportului Red Team pus pe raft. Un raport de calitate este livrat, distribuit, discutat și apoi își pierde treptat energia. Constatările rămân deschise. Controalele compensatorii nu sunt documentate. Riscurile acceptate sunt informale. Retestarea nu mai are loc.

Security Testing and Red-Teaming Policy face acest lucru inacceptabil. Clauza 6.6 prevede:

Remedierea constatărilor: toate vulnerabilitățile sau punctele slabe identificate trebuie documentate într-un raport de constatări cu ratinguri de severitate. La primirea raportului, proprietarii de sistem sunt responsabili pentru crearea unui plan de remediere cu termene-limită; de exemplu, constatările critice trebuie remediate în termen de 30 de zile, iar constatările de severitate ridicată în termen de 60 de zile, în conformitate cu Politica de management al vulnerabilităților și al patch-urilor a organizației. STC trebuie să urmărească progresul remedierii. Retestarea trebuie efectuată pentru a confirma că problemele critice au fost rezolvate sau atenuate în mod adecvat.

Clauza 6.7 adaugă nivelul de guvernanță:

Raportare: la încheierea fiecărui test trebuie emis un raport formal. Pentru testarea de penetrare, raportul trebuie să includă un rezumat executiv, metodologia și constatări detaliate cu dovezi suport și recomandări. Pentru exercițiile Red Team, raportul trebuie să detalieze scenariile, căile de atac care au avut succes, ce a fost detectat de Blue Team și lecțiile învățate privind lacunele de detectare și răspuns. CISO trebuie să prezinte rezultate sintetizate și starea remedierii conducerii superioare și, după caz, să le includă în raportul anual de securitate către consiliul de administrație.

Aceasta se aliniază cu îndrumările ISO/IEC 27005:2022 privind tratamentul riscului: selectarea opțiunilor de tratament, determinarea controalelor din Anexa A ISO 27001 și din cerințele sectoriale, construirea unui Plan de tratament al riscurilor, desemnarea persoanelor responsabile, definirea termenelor, urmărirea stării, obținerea aprobării proprietarului de risc și documentarea acceptării riscului rezidual.

Fiecare constatare TLPT semnificativă trebuie să devină unul dintre următoarele patru lucruri: o acțiune de remediere, o îmbunătățire a controlului, o acceptare formală a riscului sau o cerință de retestare.

Scopul nu este să se producă mai multe documente. Scopul este ca fiecare document să explice următoarea decizie.

Testarea rezilienței trebuie să demonstreze recuperarea, nu doar detectarea

Un TLPT reușit poate arăta că SOC a detectat trafic de comandă și control, a blocat mișcarea laterală și a escaladat corect. Este valoros, dar testarea rezilienței DORA merge mai departe. Întreabă dacă organizația poate continua sau recupera servicii de afaceri.

Zenith Blueprint, faza Controls in Action, Step 23, explică controlul 5.30, Pregătirea TIC pentru continuitatea activității, într-un limbaj pe care orice CISO ar trebui să îl folosească în relația cu consiliul de administrație:

Din perspectiva auditului, acest control este adesea testat printr-o singură formulare: Arătați-mi. Arătați-mi ultimul rezultat al testului. Arătați-mi documentația de recuperare. Arătați-mi cât timp a durat comutarea în caz de avarie și revenirea. Arătați-mi dovezile că ceea ce a fost promis poate fi livrat.

Acest standard „Arătați-mi” face diferența dintre maturitatea politicilor și reziliența operațională.

Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME de la Clarysec, din secțiunea „Cerințe de implementare a politicii”, clauza 6.4.1, prevede:

Organizația trebuie să testeze atât capabilitățile BCP, cât și capabilitățile DR cel puțin anual. Testele trebuie să includă:

Secțiunea de aplicare a aceleiași politici, clauza 8.5.1, face explicită responsabilitatea pentru dovezi:

GM trebuie să se asigure că următoarele sunt menținute și pregătite pentru audit:

Pentru o entitate financiară reglementată de DORA, testarea anuală poate fi pragul minim, nu ambiția. Funcțiile critice sau importante cu risc mai ridicat trebuie testate mai frecvent, în special după schimbări de arhitectură, migrări către cloud, incidente majore, noi furnizori TIC, lansări materiale ale aplicațiilor sau schimbări în expunerea la amenințări.

Un pachet solid de dovezi pentru testarea rezilienței trebuie să includă:

• analiza impactului asupra activității care mapează funcția critică sau importantă
• RTO și RPO aprobate de proprietarii de business
• harta dependențelor sistemului, inclusiv identitate, DNS, rețea, cloud, bază de date, monitorizare, backup și servicii ale terților
• rezultatele testelor de backup și restaurare
• marcaje temporale pentru failover și failback
• dovezi privind funcționarea controalelor de securitate în timpul perturbării
• șabloane de comunicare pentru clienți, autoritatea de reglementare și comunicarea internă
• jurnale de participare ale comandantului incidentului și ale echipei de criză
• lecții învățate și acțiuni de îmbunătățire
• dovezi de retestare pentru lacunele anterioare de recuperare

Aici intră și GDPR în discuție. GDPR Articles 2 și 3 includ în domeniu majoritatea prelucrărilor SaaS și fintech ale datelor cu caracter personal ale UE. Article 4 definește datele cu caracter personal, prelucrarea, operatorul, persoana împuternicită și încălcarea securității datelor cu caracter personal. Article 5 impune integritate, confidențialitate și responsabilitate, ceea ce înseamnă că organizația trebuie să poată demonstra conformitatea. Dacă TLPT sau testarea recuperării utilizează date cu caracter personal din producție, copiază jurnale care conțin identificatori sau validează răspunsul la încălcări, măsurile de protecție a confidențialității trebuie documentate.

Dovezile furnizorilor sunt zona oarbă DORA pe care auditorii nu o vor ignora

Serviciile financiare moderne sunt asamblate din platforme cloud, aplicații SaaS, furnizori de securitate administrați, procesatori de plăți, platforme de date, furnizori de identitate, instrumente de observabilitate, echipe de dezvoltare externalizată și furnizori de backup.

DORA Article 28 impune entităților financiare să gestioneze riscul TIC asociat terților ca parte a cadrului de management al riscurilor TIC și să rămână pe deplin responsabile chiar și atunci când serviciile TIC sunt externalizate. Article 30 impune contracte scrise pentru serviciile TIC, cu descrieri ale serviciilor, condiții de subcontractare, locații de prelucrare, protecția datelor, acces și recuperare, niveluri de serviciu, asistență la incidente, cooperare cu autoritățile, drepturi de încetare, clauze mai stricte pentru funcțiile critice sau importante, drepturi de audit, măsuri de securitate, participare la TLPT acolo unde este relevant și aranjamente de ieșire.

Aceasta înseamnă că un scenariu TLPT nu se poate opri la firewall-ul organizației dacă funcția critică depinde de un furnizor.

Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME de la Clarysec, din secțiunea „Cerințe de implementare a politicii”, clauza 6.3.1, prevede:

Furnizorii critici sau cu risc ridicat trebuie revizuiți cel puțin anual. Revizuirea trebuie să verifice:

Security Testing and Red-Teaming Policy adaugă o cerință specifică de testare pentru furnizori în clauza 6.9:

Coordonarea testării cu terții: atunci când orice furnizor critic sau furnizor de servicii intră în domeniul securității generale a organizației, în conformitate cu Politica de securitate privind terții și furnizorii, organizația trebuie, acolo unde este fezabil, să obțină asigurări privind practicile lor de testare de securitate sau să coordoneze testarea comună. De exemplu, atunci când este utilizat un furnizor de servicii cloud (CSP), organizația se poate baza pe rapoartele sale de testare de penetrare sau îl poate include în scenarii Red Team colaborative, sub rezerva prevederilor contractuale.

Pentru dovezi DORA pregătite pentru audit, asigurarea furnizorilor trebuie legată de același scenariu de risc ca TLPT. Dacă furnizorul de identitate este esențial pentru recuperarea plăților, pachetul de dovezi trebuie să includă verificarea prealabilă a furnizorului, cerințe contractuale de securitate, clauze de suport pentru incidente, coordonarea testării, rapoarte de asigurare, dovezi privind nivelul serviciilor, strategie de ieșire și constrângeri privind testarea.

NIS2 Article 21 contează, de asemenea, pentru furnizorii SaaS, cloud, servicii administrate, securitate administrată, centre de date, CDN, servicii de încredere, DNS, TLD, piețe online, motoare de căutare și rețele sociale. Acesta impune o abordare all-hazards care acoperă analiza riscului, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, dezvoltarea securizată, evaluarea eficacității, instruirea, criptografia, controlul accesului, managementul activelor, MFA și comunicațiile securizate.

Rezultatul practic este simplu: entitățile financiare trebuie să construiască un singur model de dovezi care satisface mai întâi DORA, apoi să facă trimiteri încrucișate la așteptările NIS2 acolo unde sunt implicați furnizori, entități de grup sau servicii digitale nefinanciare.

Un registru practic Clarysec pentru dovezile TLPT

Să presupunem că scenariul este:

„Un actor de amenințare compromite un cont de administrator la o platformă SaaS de suport, pivotează în mediul operațiunilor de plată, modifică configurația și perturbă prelucrarea tranzacțiilor.”

Creați un registru de dovezi cu câte un rând pentru fiecare obiect de dovezi. Nu așteptați până la finalul testului. Completați-l în timpul planificării, execuției, remedierii și închiderii.

Apoi utilizați Zenith Blueprint Step 13 pentru a adăuga trasabilitate în registrul de riscuri și în Declarația de aplicabilitate. Fiecare element de dovezi trebuie să fie conectat la un scenariu de risc, proprietar de risc, control selectat, plan de tratament și decizie privind riscul rezidual.

Dacă o constatare se referă la o slăbiciune software, citați controalele de dezvoltare securizată și testare. Secure Development Policy-sme Secure Development Policy - SME de la Clarysec, din secțiunea „Cerințe de implementare a politicii”, clauza 6.5.2, impune:

Testarea trebuie documentată cu:

Dacă o constatare produce materiale criminalistice, păstrați lanțul de custodie. Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME de la Clarysec, din secțiunea „Cerințe de guvernanță”, clauza 5.2.1, prevede:

Fiecare element de probe digitale trebuie înregistrat cu:

Acesta este punctul pe care multe echipe îl ratează. Dovezile nu înseamnă doar rapoarte finale. Ele reprezintă înregistrarea controlată a cine a aprobat, cine a executat, ce s-a întâmplat, ce a fost detectat, ce a fost recuperat, ce a fost schimbat, ce rămâne expus și cine a acceptat acea expunere.

Cum inspectează auditorii aceleași dovezi TLPT

Dovezile DORA TLPT vor fi citite diferit în funcție de profilul auditorului. Clarysec proiectează pachete de dovezi astfel încât fiecare perspectivă să găsească ceea ce are nevoie, fără a forța echipele să dubleze munca.

COBIT 2019 apare în referința de conformitate transversală Zenith Blueprint pentru executarea sigură a auditului și testării, inclusiv DSS05.03 și MEA03.04. Relevanța nu este că COBIT înlocuiește DORA sau ISO 27001, ci că profesioniștii în asigurare de tip ISACA vor căuta executare controlată, monitorizare, evaluare și dovezi de conformitate.

Narațiunea pentru consiliul de administrație: ce trebuie să aprobe managementul

Raportarea către consiliul de administrație trebuie să evite teatrul tehnic. Consiliul nu are nevoie de payload-uri de exploit. Are nevoie de dovezi pentru decizii:

• Ce funcție critică sau importantă a fost testată?
• Ce scenariu de amenințare a fost simulat și de ce?
• A funcționat detectarea?
• A funcționat escaladarea răspunsului?
• Recuperarea a respectat RTO și RPO?
• Ce furnizori au fost implicați sau au impus constrângeri?
• Ce puncte slabe materiale rămân?
• Care este costul remedierii, proprietarul și calendarul?
• Ce riscuri reziduale necesită acceptare formală?
• Ce va fi retestat?

Aici devine importantă Clause 5 din ISO 27001. Conducerea de vârf trebuie să se asigure că politica de securitate a informației și obiectivele sunt stabilite, aliniate cu direcția strategică, integrate în procesele de afaceri, finanțate cu resurse, comunicate și îmbunătățite continuu. Rolurile și responsabilitățile trebuie alocate. Obiectivele trebuie să fie măsurabile acolo unde este practic și să țină seama de cerințele aplicabile și de rezultatele tratamentului riscului.

Dacă TLPT identifică faptul că timpul de recuperare este de șase ore față de o toleranță de business de patru ore, acesta nu este doar un element restant de infrastructură. Este o decizie de management care implică apetitul la risc, bugetul, angajamentele față de clienți, expunerea de reglementare, contractele, arhitectura și capacitatea operațională.

Eșecuri frecvente ale dovezilor în testarea rezilienței DORA

Revizuirile Clarysec identifică adesea aceleași lacune de dovezi la entitățile financiare și furnizorii de servicii TIC care se pregătesc pentru DORA.

În primul rând, domeniul TLPT nu se mapează la funcții critice sau importante. Testul poate fi impresionant tehnic, dar nu dovedește reziliența procesului de afaceri care interesează autoritățile de reglementare.

În al doilea rând, dependențele de furnizori sunt recunoscute, dar nu sunt susținute de dovezi. Echipele spun că furnizorul cloud, SOC administrat sau platforma SaaS este în domeniu, însă lipsesc contractele, drepturile de audit, permisiunile de testare, clauzele de suport pentru incidente și planurile de ieșire.

În al treilea rând, testarea creează dovezi, dar nu tratament. Constatările rămân într-un raport Red Team, în loc să fie convertite în actualizări ale registrului de riscuri, schimbări ale controalelor, proprietari, date, retestare și decizii privind riscul rezidual.

În al patrulea rând, recuperarea este presupusă, nu demonstrată. Politicile de backup există, dar nimeni nu poate arăta marcaje temporale de failover, verificări ale integrității restaurării, validarea accesului sau confirmarea din partea proprietarului de business.

În al cincilea rând, confidențialitatea și dovezile criminalistice nu sunt controlate. Jurnalele și capturile de ecran conțin date cu caracter personal, artefactele de test sunt stocate pe unități partajate, conturile temporare rămân active, iar lanțul de custodie al dovezilor este incomplet.

În al șaselea rând, raportarea de management este prea tehnică. Conducătorii de rang superior nu pot vedea dacă reziliența s-a îmbunătățit, dacă riscul este în limitele apetitului la risc sau ce decizii de investiții sunt necesare.

Fiecare dintre aceste lacune poate fi rezolvată prin tratarea DORA TLPT ca un flux structurat de dovezi ISO 27001.

Abordarea integrată Clarysec pentru reziliență pregătită pentru audit

Abordarea Clarysec combină trei niveluri.

Primul nivel este foaia de parcurs de implementare în 30 de pași Zenith Blueprint. Pentru acest subiect, Step 13 construiește trasabilitatea pentru tratamentul riscului și SoA, Step 21 protejează sistemele în timpul testării de audit, iar Step 23 validează pregătirea TIC pentru continuitatea activității. Acești pași transformă TLPT dintr-un eveniment tehnic într-un ciclu de guvernanță documentat.

Al doilea nivel este biblioteca de politici Clarysec. Security Testing and Red-Teaming Policy definește tipurile de testare, domeniul de aplicare, regulile de angajament, remedierea, raportarea și coordonarea cu furnizorii. Business Continuity Policy and Disaster Recovery Policy-sme stabilește așteptări pentru testarea anuală BCP și DR și dovezi de continuitate pregătite pentru audit. Third-Party and Supplier Security Policy-sme susține asigurarea furnizorilor. Secure Development Policy-sme se asigură că testarea de securitate este documentată. Evidence Collection and Forensics Policy-sme susține jurnalizarea dovezilor și disciplina lanțului de custodie.

Al treilea nivel este Zenith Controls, ghidul Clarysec de conformitate transversală. Acesta ajută la maparea controalelor ISO/IEC 27002:2022 la atribute, domenii, capabilități operaționale și așteptări între cadre. Pentru DORA TLPT, cel mai important tipar nu este un singur control. Este relația dintre testare, continuitate, gestionarea incidentelor, managementul furnizorilor, jurnalizare, monitorizare, dezvoltare securizată, revizuire independentă și guvernanță.

Când aceste niveluri funcționează împreună, problema de luni dimineață a CISO se schimbă. În loc de trei întrebări deconectate din partea consiliului, autorității de reglementare și auditului intern, organizația are o singură poveste a dovezilor:

„Am identificat funcția critică. Am evaluat riscul TIC. Am selectat și justificat controalele. Am autorizat și executat TLPT în siguranță. Am detectat, am răspuns și ne-am recuperat. Am implicat furnizorii acolo unde a fost necesar. Am documentat dovezile. Am remediat constatările. Am retestat. Managementul a revizuit și a acceptat riscul rămas.”

Aceasta este reziliență pregătită pentru audit.

Pași următori

Dacă programul dumneavoastră DORA TLPT este încă organizat în jurul rapoartelor, nu al lanțurilor de dovezi, începeți cu o parcurgere Clarysec a dovezilor.

Utilizați Zenith Blueprint Zenith Blueprint Step 13 pentru a conecta scenariile TLPT la riscuri, controale și Declarația de aplicabilitate. Utilizați Step 21 pentru a verifica autorizarea sigură, regulile de angajament, revenirea controlată, monitorizarea și curățarea. Utilizați Step 23 pentru a demonstra pregătirea TIC pentru continuitatea activității cu dovezi de recuperare.

Apoi aliniați documentele operaționale cu Security Testing and Red-Teaming Policy Security Testing and Red-Teaming Policy, Business Continuity Policy and Disaster Recovery Policy-sme Business Continuity Policy and Disaster Recovery Policy - SME, Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME, Secure Development Policy-sme Secure Development Policy - SME și Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME de la Clarysec.

În final, utilizați Zenith Controls Zenith Controls pentru a mapa transversal dovezile DORA TLPT la controale ISO 27001, NIS2, GDPR, COBIT 2019 și așteptările auditorilor.

Dacă doriți ca următorul test de reziliență să producă mai mult decât constatări, utilizați Clarysec pentru a-l transforma într-un lanț de dovezi defensabil. Descărcați seturile de instrumente, programați o evaluare a pregătirii dovezilor sau solicitați o prezentare a modului în care Clarysec mapează DORA TLPT la controale ISO 27001:2022, de la planificare până la aprobarea consiliului de administrație.