Strategie ITDR pentru ISO 27001, NIS2, DORA și GDPR

La ora 3:00 dimineața, într-o zi de marți, Sarah, CISO-ul FinScale, a fost trezită de tipul de alertă de care liderii moderni de securitate se tem tot mai des. O sesiune activă a unui dezvoltator senior, autentificată prin MFA cu doar câteva ore înainte, era utilizată dintr-o sursă neobișnuită pentru a enumera schemele bazelor de date de producție.

Nu exista niciun beacon de malware. Nicio notă de ransomware. Niciun exploit de firewall. Doar identitate.

SOC a detectat activitatea, dar răspunsul a fost necoordonat. Era vorba despre o ocolire MFA, un token de sesiune furat sau o compromitere a furnizorului de identitate însuși? Cine avea autoritatea de a închide sesiunea activă? Era suficientă revocarea parolei sau echipa trebuia să invalideze token-urile de refresh, să rotească credențialele API și să revizuiască acordurile OAuth? Până la conținerea activității, atacatorul fusese activ timp de 47 de minute.

În dimineața următoare, incidentul de securitate a devenit o problemă de guvernanță. Consiliul de administrație a solicitat o explicație clară, în limbaj accesibil, privind posibila eșuare a igienei cibernetice a FinScale conform NIS2. Echipa de conformitate dorea să știe dacă evenimentul putea fi clasificat drept incident major legat de TIC conform DORA. Departamentul juridic avea nevoie de un răspuns defensabil privind accesarea datelor cu caracter personal conform GDPR Article 32 și dacă era necesară o evaluare a încălcării securității datelor cu caracter personal. Auditorul extern a întrebat dacă controalele ISO/IEC 27001:2022 funcționau eficace, nu doar dacă erau documentate în politici.

Problema lui Sarah nu era lipsa instrumentelor. FinScale avea un furnizor de identitate, MFA, un SIEM, controale pentru endpoint-uri, jurnale cloud și un proces de răspuns la incidente. Problema era că managementul identității, jurnalizarea, monitorizarea, răspunsul la incidente, evaluarea impactului asupra confidențialității și gestionarea dovezilor funcționau în silozuri.

Aceasta este problema detecției și răspunsului la amenințările asupra identității în 2026. ITDR nu mai este doar o capabilitate a operațiunilor de securitate. Este un motor de dovezi pentru conformitatea transversală cu ISO/IEC 27001:2022, NIS2, DORA și GDPR Article 32.

Zenith Blueprint: foaia de parcurs în 30 de pași pentru auditori Zenith Blueprint, suita de politici Clarysec și Zenith Controls: ghidul de conformitate transversală Zenith Controls ajută organizațiile să transforme atacurile asupra identității din investigații haotice în procese de control repetabile și verificabile prin audit.

De ce detecția și răspunsul la amenințările asupra identității au devenit o temă la nivelul consiliului de administrație

Atacurile asupra identității funcționează deoarece abuzează de căi legitime de acces. Un atacator care fură un token de sesiune, înregistrează o aplicație OAuth malițioasă, compromite un cont de serviciu sau convinge un utilizator prin oboseala generată de solicitări MFA poate părea un utilizator valid pentru sistemele care verifică doar dacă autentificarea a reușit.

Acest lucru diferențiază ITDR de apărarea tradițională a perimetrului. Un program matur trebuie să poată răspunde la următoarele întrebări:

• Ce identități umane, de serviciu, de furnizor și de aplicație există?
• Ce identități sunt privilegiate, inactive, partajate sau federate extern?
• Ce evenimente de autentificare sunt normale, riscante sau imposibile?
• Ce acorduri OAuth, token-uri SaaS și credențiale API pot accesa date sensibile?
• Ce alerte declanșează clasificarea incidentelor, păstrarea dovezilor și procesul decizional de reglementare?
• Ce controale demonstrează că accesul la date cu caracter personal este protejat prin măsuri tehnice și organizatorice adecvate?

NIS2 transformă această temă într-o problemă 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 organizatorice adecvate și proporționale, inclusiv analiza riscurilor, gestionarea incidentelor, continuitatea activității, securitatea lanțului de aprovizionare, evaluarea eficacității controalelor, igienă cibernetică, instruire, controlul accesului, politica de management al activelor și autentificare multifactor sau autentificare continuă, după caz.

DORA exercită o presiune similară asupra entităților financiare. Aceasta impune un cadru documentat de management al riscurilor TIC, responsabilitatea organului de conducere, mecanisme de detecție, gestionarea incidentelor, clasificare, raportare, testarea rezilienței și managementul riscurilor asociate terților TIC. DORA se aplică de la 17 ianuarie 2025. Pentru entitățile financiare identificate și conform NIS2, DORA funcționează ca set de reguli sectoriale pentru obligațiile suprapuse privind riscurile TIC și incidentele.

GDPR adaugă stratul de responsabilitate privind confidențialitatea. Article 5 impune integritate, confidențialitate și responsabilitate. Article 4 definește amplu o încălcare a securității datelor cu caracter personal, inclusiv accesul neautorizat la date cu caracter personal. Article 32 impune măsuri tehnice și organizatorice adecvate pentru asigurarea unui nivel de securitate corespunzător riscului. În incidentele de identitate, jurnalele, controalele de acces, înregistrările de autentificare și dovezile incidentului devin esențiale pentru a demonstra dacă datele cu caracter personal au fost protejate.

ISO/IEC 27001:2022 este sistemul de management care poate reuni aceste obligații. Clauza 4 impune organizației să înțeleagă contextul, părțile interesate și cerințele legale, de reglementare și contractuale. Clauza 6 impune evaluarea riscurilor, tratarea riscurilor, aprobarea de către proprietarul riscului și păstrarea dovezilor. Anexa A include controale pentru managementul identității, autentificarea securizată, jurnalizare, monitorizare, gestionarea incidentelor, colectarea dovezilor, relațiile cu furnizorii, servicii cloud și protecția confidențialității.

ITDR trebuie inclus în SMSI deoarece riscul privind identitatea devine verificabil prin audit numai atunci când este inclus în domeniul de aplicare, are proprietar, este evaluat, tratat, monitorizat și îmbunătățit.

Scenariul de atac asupra identității care îi preocupă pe autoritățile de reglementare

Să luăm exemplul unui furnizor de fluxuri de lucru financiare în cloud care deservește clienți din UE. Acesta utilizează Microsoft 365, o platformă SaaS de suport pentru clienți, infrastructură cloud, un procesator de plăți și mai multe integrări bazate pe API. Un inginer senior de suport primește o solicitare convingătoare de reconectare a unei aplicații de productivitate. Ecranul de consimțământ OAuth solicită acces de citire la căsuța poștală și acces offline. Inginerul aprobă solicitarea.

În câteva minute, atacatorul utilizează token-ul pentru a căuta identificatori de clienți și atașamente de suport. Acesta enumeră apartenențele la grupuri și încearcă accesul la un portal de administrare. MFA era activată, dar atacatorul nu mai are nevoie de parolă deoarece token-ul acordă acces persistent. SOC observă acces neobișnuit la căsuța poștală, o nouă aplicație OAuth, încercări eșuate de acces la portalul de administrare și activitate dintr-o zonă geografică neobișnuită.

Acest singur scenariu traversează mai multe domenii de control:

• Ciclul de viață al identității, deoarece rolul și permisiunile utilizatorului determină raza de impact.
• Autentificare securizată, deoarece MFA singură nu a prevenit abuzul de token.
• Jurnalizare și monitorizare, deoarece detecția depinde de jurnalele furnizorului de identitate, ale SaaS și ale aplicațiilor.
• Răspuns la incidente, deoarece credențialele, sesiunile, token-urile și acordurile OAuth trebuie revocate rapid.
• Colectarea dovezilor, deoarece poate urma expunerea datelor cu caracter personal și raportarea către autorități.
• Guvernanța furnizorilor și a cloudului, deoarece jurnalele SaaS și API-urile de audit fac parte din lanțul dovezilor.
• Protecția confidențialității, deoarece accesul la date cu caracter personal trebuie evaluat conform GDPR.

Întrebarea corectă nu este „Ce instrument a eșuat?”. Întrebarea corectă este dacă organizația avea un lanț de controale ITDR proiectat, testat și verificabil prin audit.

Lanțul de controale ISO 27001:2022 din spatele unui ITDR eficace

Cele mai eficace programe ITDR conectează controale preventive, detective, corective și probatorii.

În Zenith Controls, controlul ISO/IEC 27001:2022 5.16 Managementul identității este tratat ca un control preventiv care susține confidențialitatea, integritatea și disponibilitatea. Acesta se conectează direct la 5.15 Controlul accesului, 5.17 Informații de autentificare, 5.18 Drepturi de acces, 5.19 Securitatea informației în relațiile cu furnizorii, 5.36 Conformitatea cu politicile, regulile și standardele pentru securitatea informației și 8.2 Drepturi de acces privilegiate.

Acest lucru contează deoarece detecția amenințărilor asupra identității eșuează atunci când guvernanța identității este slabă. Dacă un cont de serviciu nu este documentat, o identitate de furnizor nu este administrată sau un rol privilegiat nu are proprietar, monitorizarea poate detecta un eveniment, dar responsabilii cu răspunsul nu îl pot interpreta rapid.

Controlul 8.5 Autentificare securizată este o altă ancoră ITDR. În Zenith Controls, acesta se conectează la managementul identității, informații de autentificare, drepturi de acces privilegiate, restricționarea accesului la informații, activități de monitorizare, gestionarea incidentelor și protecția confidențialității PII. Autentificarea nu se încheie la autentificarea inițială. Managementul sesiunilor, gestionarea token-urilor, protecția credențialelor și trasabilitatea fac parte din aceeași poveste a dovezilor.

Controlul 8.16 Activități de monitorizare este balamaua dintre colectarea jurnalelor și luarea deciziilor. Acesta depinde de 8.15 Jurnalizare și susține 5.25 Evaluarea și decizia privind evenimentele de securitate a informației, 5.26 Răspunsul la incidente de securitate a informației și gestionarea incidentelor în sens mai larg. Pentru ITDR, 8.16 este punctul în care comportamentul suspect al identității devine un eveniment triat, un incident declarat sau un fals pozitiv documentat.

Tabelul nu este o mapare teoretică. Este lanțul practic de dovezi pe care un auditor, un membru al consiliului de administrație sau o autoritate de reglementare îl va aștepta după un incident de identitate.

Ce adaugă politicile Clarysec: proprietate, declanșatori și reguli privind dovezile

Instrumentele de identitate nu creează automat responsabilitate. În timpul unei crize, responsabilii cu răspunsul au nevoie de autoritatea de a revoca sesiuni, de a dezactiva conturi, de a exporta jurnale, de a păstra dovezi și de a lua decizii de escaladare. Auditorii trebuie să vadă că aceste acțiuni nu au fost improvizate.

Suita de politici Clarysec oferă acest model operațional.

Din Politica privind gestionarea conturilor de utilizator și a privilegiilor la nivel enterprise Politica privind gestionarea conturilor de utilizator și a privilegiilor, clauza 5.9 privind Cerințele de guvernanță prevede:

Organizația trebuie să mențină un inventar detaliat al tuturor credențialelor active și inactive, al conturilor privilegiate și al conturilor de serviciu la nivel de sistem. Acest inventar trebuie actualizat continuu și revizuit trimestrial.

Aceasta transformă inventarul identităților într-o obligație explicită de control. Este deosebit de important deoarece conturile de serviciu, cheile API și credențialele inactive sunt puncte oarbe frecvente în ITDR.

Aceeași politică prevede în clauza 5.8 privind Cerințele de guvernanță:

Toate activitățile administrative și acțiunile aferente conturilor privilegiate trebuie jurnalizate într-un mod rezistent la alterare și monitorizate pentru anomalii sau încălcări ale politicii.

Această clauză conectează managementul accesului privilegiat la detecție. O acțiune privilegiată nu este doar permisă sau refuzată. Ea trebuie monitorizată pentru comportamente care nu corespund utilizatorului, rolului, sursei, momentului sau procesului de afaceri.

Pentru organizațiile mai mici, Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME Politica privind gestionarea conturilor de utilizator și a privilegiilor - SME oferă o așteptare concisă în clauza 8.1.1 privind Aplicare și conformitate:

Responsabilul IT trebuie să revizuiască periodic jurnalele de sistem pentru tentative de acces neautorizat, anomalii de autentificare sau modificări de privilegii neaprobate.

Aici încep multe programe ITDR pentru IMM-uri. Nu este necesar un SOC mare. Sunt necesare proprietate nominală și revizuirea periodică a semnalelor corecte privind identitatea.

Politica de jurnalizare furnizează baza probatorie. Politica de jurnalizare și monitorizare - SME Politica de jurnalizare și monitorizare - SME specifică în clauza 5.4.2 privind Cerințele de guvernanță:

Jurnale de autentificare: tentative de autentificare reușite și eșuate, durata sesiunii, utilizarea MFA

Aceste câmpuri nu sunt opționale. Ele ajută la demonstrarea faptului dacă evenimentul suspect a implicat autentificare reușită, eșecuri repetate, utilizarea MFA, persistența sesiunii sau durată anormală.

Politica de jurnalizare și monitorizare la nivel enterprise Politica de jurnalizare și monitorizare extinde domeniul obligatoriu al jurnalelor în clauza 6.1.1 privind Cerințele de implementare a politicii:

Toate sistemele acoperite trebuie să genereze jurnale care capturează: 6.1.1.1 Autentificarea utilizatorilor și tentativele de acces 6.1.1.2 Activitățile utilizatorilor privilegiați 6.1.1.3 Modificările de configurare 6.1.1.4 Tentativele de acces eșuate sau evenimentele de sistem 6.1.1.5 Detecțiile de malware și alertele de securitate 6.1.1.6 Comunicările externe și declanșatoarele regulilor de firewall

Modificările de configurare sunt deosebit de importante în atacurile asupra identității. Atacatorii adaugă frecvent acorduri OAuth, creează reguli de redirecționare, înregistrează dispozitive, modifică metode MFA sau creează căi de acces de urgență.

Politica de răspuns la incidente conferă apoi autoritate responsabililor cu răspunsul. Politica de răspuns la incidente la nivel enterprise Politica de răspuns la incidente prevede în clauza 6.2.1 privind Cerințele de implementare a politicii:

SOC trebuie să izoleze imediat sistemele afectate, să revoce credențialele compromise sau să blocheze traficul malițios folosind firewall-uri sau instrumente de securitate a punctelor terminale.

Politica de răspuns la incidente - SME Politica de răspuns la incidente - SME prevede în clauza 4.2.2 privind Roluri și responsabilități:

Implementează acțiuni de conținere și recuperare, de exemplu prin dezactivarea accesului sau restaurarea backup-urilor.

Pentru ITDR, revocarea unei parole nu este suficientă. Procedurile operaționale trebuie să includă dezactivarea conturilor, revocarea sesiunilor, invalidarea acordurilor OAuth, rotirea secretelor, resetarea metodelor MFA și revizuirea permisiunilor delegate.

Gestionarea dovezilor face diferența dintre a răspunde și a demonstra. Politica privind colectarea dovezilor și activitățile criminalistice la nivel enterprise Politica privind colectarea dovezilor și activitățile criminalistice prevede în clauza 5.5 privind Cerințele de guvernanță:

Toate dovezile colectate trebuie identificate unic, etichetate și stocate într-un depozit securizat cu: 5.5.1 verificare a integrității, cum ar fi valori hash SHA-256 5.5.2 jurnale de acces marcate temporal 5.5.3 intrări în lanțul de custodie semnate de fiecare custode

Politica privind colectarea dovezilor și activitățile criminalistice - SME Politica privind colectarea dovezilor și activitățile criminalistice - SME prevede în clauza 6.1.1 privind Cerințele de implementare a politicii:

Trebuie creată întotdeauna o copie criminalistică sau un export criminalistic; dovezile originale nu trebuie niciodată editate direct.

În scenariul FinScale, aceasta înseamnă că SOC exportă jurnalele furnizorului de identitate, jurnalele de audit SaaS, înregistrările de acces la căsuța poștală, înregistrările de consimțământ OAuth, înregistrările de revocare a sesiunii și alertele SIEM într-un depozit securizat, cu protecția integrității și lanț de custodie.

Construirea foii de parcurs ITDR cu Zenith Blueprint

Zenith Blueprint traduce lanțul de controale în pași de implementare.

În etapa „Controale în acțiune”, Step 19, Controale tehnologice I, Blueprint este direct cu privire la autentificare:

Acolo unde este posibilă, autentificarea exclusiv prin parolă trebuie evitată, în special pentru conturi administrative, console cloud, instrumente de acces la distanță și orice sistem expus la internet. MFA, folosind un al doilea factor, cum ar fi o cheie hardware, o aplicație mobilă sau un element biometric, este acum o cerință de bază, nu un lux. Aceasta atenuează riscurile de furt al credențialelor, phishing și atacuri de tip brute-force.

Același pas depășește problematica parolelor. El impune stocarea și transmiterea securizată a datelor de autentificare, gestionarea securizată a token-urilor API, a identificatorilor de sesiune și a credențialelor OAuth, instrumente de gestionare a secretelor pentru autentificarea machine-to-machine, rotirea token-urilor, controale privind durata de viață a sesiunii, flaguri securizate pentru cookie-uri și revizuirea jurnalelor de autentificare.

Step 22, Controale organizaționale, formalizează ciclul de viață al accesului. Acesta ghidează echipele să integreze alocarea și retragerea accesului cu HR, să efectueze revizuiri trimestriale documentate ale drepturilor de acces, să definească tipuri de identități, cum ar fi conturi individuale, partajate și de serviciu, să impună MFA pentru conturile privilegiate, să elimine conturile inactive și să rotească credențialele de serviciu.

Step 19 oferă și calea de îmbunătățire a jurnalizării: transmiterea jurnalelor critice către un SIEM sau un colector de jurnale, validarea retenției, urmărirea unui eveniment recent folosind jurnalele, documentarea caracteristicilor de integritate a jurnalelor și confirmarea alertării pentru autentificări eșuate sau escaladări ale privilegiilor. Sincronizarea timpului contează deoarece reconstrucția incidentului eșuează atunci când jurnalele furnizorului de identitate, SaaS, endpoint-urilor și cloud nu concordă la nivelul marcajelor temporale.

Step 23, Controale organizaționale pentru 5.19 până la 5.37, validează capabilitățile de gestionare a incidentelor. Acesta impune un plan de răspuns la incidente actualizat, evenimente raportabile definite, exerciții de tip tabletop, decizii documentate, înregistrări ale comunicărilor, lecții învățate și păstrarea dovezilor criminalistice, cum ar fi instantanee ale jurnalelor, backup-uri și izolare securizată.

O secvență ITDR pragmatică pentru Clarysec arată astfel:

1. Definirea tipurilor de identități și a proprietarilor.
2. Securizarea autentificării, token-urilor și sesiunilor.
3. Colectarea jurnalelor de autentificare, de privilegii și SaaS.
4. Monitorizarea comportamentelor riscante.
5. Definirea regulilor de decizie de la eveniment la incident.
6. Păstrarea dovezilor.
7. Raportarea, recuperarea și îmbunătățirea.

Un pachet de dovezi ITDR într-o săptămână

Un „pachet de dovezi pentru incident de identitate” focalizat este una dintre cele mai rapide modalități de a expune lacunele. Alegeți un scenariu cu risc ridicat, cum ar fi: „Un utilizator SaaS privilegiat acordă consimțământ unei aplicații OAuth neautorizate, iar token-ul este utilizat pentru a accesa date despre clienți.”

Apoi construiți pachetul de dovezi într-o săptămână.

Includeți cel puțin o urmă reală. Luați o anomalie benignă recentă de autentificare și demonstrați cum echipa trece de la alertă la identitatea utilizatorului, dispozitiv, IP sursă, metodă MFA, durata sesiunii, resurse SaaS accesate, date atinse și decizie de conținere. Dacă organizația nu poate reconstrui acest lanț într-un exercițiu tabletop, va întâmpina dificultăți în timpul unui incident real.

Rezultatul devine dovadă reutilizabilă pentru audituri interne ISO/IEC 27001:2022, testarea procesului de incidente TIC conform DORA, supravegherea igienei cibernetice conform NIS2 și responsabilitatea conform GDPR.

Maparea ITDR la NIS2, DORA și GDPR Article 32

Forța unui model ITDR unificat constă în faptul că aceleași dovezi satisfac mai multe obligații, respectând în același timp limbajul fiecărui cadru.

NIS2 Article 21 așteaptă măsuri tehnice, operaționale și organizatorice proporționale și bazate pe risc. Pentru ITDR, aceasta înseamnă controlul accesului, politica de management al activelor, igienă cibernetică, instruire, gestionarea incidentelor, evaluarea eficacității controalelor și MFA sau autentificare continuă, după caz. Article 23 creează raportare etapizată pentru incidente semnificative, inclusiv avertizare timpurie în 24 de ore, notificarea incidentului în 72 de ore și raport final în termen de o lună.

DORA Articles 8 to 14 impun identificarea activelor TIC și a dependențelor, protecție și prevenire, mecanisme de detecție, continuitate și recuperare, învățare și comunicare. Articles 17 to 19 impun gestionarea incidentelor, identificarea cauzei principale, indicatori de avertizare timpurie, clasificare în funcție de severitate și criticitatea serviciului, escaladare, notificarea organului de conducere, raportarea către autoritatea competentă și notificarea clienților atunci când interesele financiare sunt afectate.

GDPR impune măsuri tehnice și organizatorice adecvate și responsabilitate demonstrabilă. În atacurile asupra identității, întrebările GDPR includ dacă a avut loc acces neautorizat, ce date cu caracter personal au fost implicate, dacă măsurile de protecție funcționau și dacă sunt declanșate pragurile de notificare a încălcării.

Pentru firmele fintech, relația dintre NIS2 și DORA contează. DORA este tratată ca un cadru sectorial pentru entitățile financiare aflate în domeniu atunci când există obligații suprapuse privind riscul TIC și raportarea incidentelor. În practică, organizațiile trebuie să construiască un singur model de dovezi ITDR și să mapeze deciziile de raportare la ruta juridică aplicabilă.

Pentru organizațiile SaaS, cloud, servicii administrate, securitate administrată și platforme digitale, domeniul de aplicare NIS2 trebuie verificat cu atenție. NIS2 acoperă multe sectoare din Anexa I și Anexa II, inclusiv infrastructură digitală, furnizori de servicii de cloud computing, centre de date, servicii de încredere, DNS, registre TLD, furnizori de servicii administrate, furnizori de servicii de securitate administrate, piețe online, motoare de căutare și platforme de rețele sociale. Prin urmare, definirea domeniului de aplicare conform clauzei 4 ISO/IEC 27001:2022 și analiza părților interesate nu sunt simple formalități. Ele definesc obligațiile pe care SMSI trebuie să le abordeze.

Riscul de identitate asociat furnizorilor și SaaS

Incidentele de identitate depind adesea de dovezile furnizorilor. Poate furnizorul SaaS să exporte jurnale de audit? Afișează acesta evenimente de consimțământ OAuth? Susține controale de acces securizate, jurnalizare și capabilități de protecție a datelor? Asistența în caz de incident, locația datelor, subcontractarea, drepturile de acces și dispozițiile de ieșire sunt acoperite contractual?

Politica de utilizare a serviciilor cloud - SME Clarysec Politica de utilizare a serviciilor cloud - SME include o cerință directă din clauza 5.2.4 privind Cerințele de guvernanță:

Serviciul oferă controale de acces securizate, jurnalizare și capabilități de protecție a datelor

Această propoziție simplă este un control de achiziție. Dacă o platformă SaaS nu poate produce jurnalele de identitate necesare pentru răspuns la incidente, creează risc de conformitate.

DORA face acest lucru explicit prin obligațiile privind riscul asociat terților TIC. Entitățile financiare rămân responsabile pentru conformitate, trebuie să mențină registre ale contractelor de servicii TIC, să distingă funcțiile critice sau importante, să efectueze verificări prealabile, să evalueze riscul de concentrare, să includă drepturi de audit și acces, să definească asistența în caz de incident și să asigure strategii de ieșire.

În Zenith Controls, controlul ISO/IEC 27001:2022 8.16 Activități de monitorizare se conectează la 5.22 Monitorizarea, revizuirea și managementul schimbărilor pentru serviciile furnizorilor. Aceasta reflectă realitatea operațională. Alertele furnizorului de identitate, jurnalele de audit SaaS, activitatea administratorilor cloud și conturile furnizorilor de servicii administrate fac toate parte din suprafața ITDR.

Cum vor evalua auditorii ITDR

Un program ITDR solid trebuie să reziste la mai multe perspective de audit. Fiecare public pune întrebări diferite, dar dovezile trebuie să provină din același sistem de control.

Un auditor ISO/IEC 27001:2022 va întreba dacă amenințările asupra identității sunt incluse în evaluarea riscurilor, dacă proprietarii de risc au aprobat tratarea riscurilor, dacă Declarația de aplicabilitate include controalele relevante din Anexa A, dacă politicile sunt implementate și dacă dovezile arată că aceste controale funcționează. Auditorul poate eșantiona un cont privilegiat și poate urmări aprobarea, setarea MFA, activitatea din jurnale, revizuirea drepturilor de acces și retragerea accesului.

Un evaluator NIST CSF 2.0 va examina rezultatele GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND și RECOVER. ITDR se încadrează natural într-un profil delimitat la compromiterea identității, abuzul de token-uri SaaS sau utilizarea abuzivă a accesului privilegiat.

Un examinator DORA va căuta responsabilitatea organului de conducere, funcțiile de business susținute de TIC, mecanismele de detecție, criteriile de clasificare a incidentelor, escaladarea, regulile de comunicare cu clienții, analiza cauzei principale și dependențele față de terți TIC.

Un evaluator GDPR va întreba dacă organizația poate demonstra securitatea adecvată a datelor cu caracter personal. Acesta va examina restricționarea accesului, detecția accesului neautorizat, jurnalele care arată ce date ar fi putut fi accesate, evaluarea încălcării și dovezile de responsabilitate.

Un auditor COBIT 2019 sau cu abordare ISACA va examina guvernanța, obiectivele de control, proprietatea, monitorizarea performanței și asigurarea controalelor.

Zenith Controls este util aici deoarece acționează ca ghid de conformitate transversală. Nu creează „controale Zenith” separate. Mapează ariile de control ISO/IEC 27001:2022 la controale ISO conexe, alte standarde, așteptări de audit și relații de implementare.

Metrici care demonstrează că ITDR funcționează

Consiliile de administrație și auditorii nu au nevoie de zgomot brut din SIEM. Au nevoie de dovezi că funcționează controalele de identitate și că acestea se îmbunătățesc. Metricile ITDR utile includ:

• Procentul de conturi privilegiate cu MFA rezistentă la phishing.
• Numărul de conturi inactive mai vechi decât pragul politicii.
• Numărul de conturi de serviciu fără proprietar sau dată de rotire.
• Procentul de platforme SaaS critice care trimit jurnale de autentificare către SIEM.
• Timpul mediu de detectare a activității suspecte privind identitatea.
• Timpul mediu de revocare a sesiunilor și token-urilor compromise.
• Numărul de aplicații OAuth aprobate, respinse sau eliminate.
• Procentul de incidente de identitate cu pachete complete de dovezi.
• Numărul de constatări restante din revizuirea drepturilor de acces.
• Numărul de platforme ale furnizorilor care nu dispun de jurnalele de identitate necesare.

Aceste metrici trebuie să alimenteze revizuirea de management ISO/IEC 27001:2022, supravegherea guvernanței NIS2, raportarea riscurilor TIC conform DORA și discuțiile privind responsabilitatea GDPR.

Constatări frecvente de audit ITDR și remedieri

Clarysec observă frecvent cinci constatări recurente.

În primul rând, organizațiile activează MFA, dar nu monitorizează comportamentul MFA. Remediați prin jurnalizarea modificărilor metodei MFA, a provocărilor eșuate, a deplasărilor imposibile, a înregistrării de dispozitive noi și a solicitărilor push repetate.

În al doilea rând, conturile de serviciu sunt excluse din guvernanța identității. Remediați prin inventarierea conturilor la nivel de sistem, desemnarea proprietarilor, rotirea secretelor, eliminarea credențialelor încorporate și monitorizarea comportamentului API anormal.

În al treilea rând, consimțământul SaaS nu este administrat. Remediați prin restricționarea consimțământului utilizatorilor, revizuirea aplicațiilor OAuth, monitorizarea acordurilor noi, documentarea integrărilor aprobate și eliminarea aplicațiilor neutilizate.

În al patrulea rând, dovezile sunt modificate în timpul investigației. Remediați prin respectarea regulii din Politica privind colectarea dovezilor și activitățile criminalistice: creați copii sau exporturi criminalistice, nu editați niciodată direct originalele și stocați dovezile cu hash-uri și înregistrări ale lanțului de custodie.

În al cincilea rând, clasificarea incidentelor este prea lentă. Remediați prin definirea prealabilă a pragurilor pentru evenimentele de identitate, inclusiv compromiterea conturilor privilegiate, accesul la date cu caracter personal, abuzul de token-uri SaaS cu impact asupra clienților, perturbarea serviciilor critice și compromiterea identității unui furnizor.

Fiecare constatare are un răspuns prin control, politică și dovezi. Aceasta este valoarea practică a unui program ITDR unificat: definește ce trebuie să aibă proprietar, să fie monitorizat, testat, dovedit și îmbunătățit.

Transformați riscul privind identitatea în dovezi pregătite pentru audit

Dacă următorul incident de identitate s-ar produce mâine, ați putea demonstra cine a accesat ce, cum s-a autentificat, ce token sau sesiune a fost utilizată, ce date au fost atinse, cine a decis clasificarea de reglementare și ce acțiuni corective au fost finalizate?

Dacă răspunsul este incert, începeți cu un sprint focalizat de pregătire ITDR.

Utilizați Zenith Blueprint pentru a structura calea de implementare la nivel de autentificare, ciclul de viață al accesului, jurnalizare, monitorizare, răspuns la incidente și gestionarea dovezilor. Utilizați politicile Clarysec de control al accesului, jurnalizare, cloud, răspuns la incidente și criminalistică digitală pentru a atribui proprietatea și autoritatea de răspuns. Utilizați Zenith Controls pentru a mapa managementul identității, autentificarea securizată și activitățile de monitorizare la ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 și așteptările de audit.

Obiectivul este simplu: atacurile asupra identității trebuie să fie detectabile, conținute, raportabile și defensabile.

Clarysec vă poate ajuta să construiți un pachet de dovezi ITDR, să îl testați printr-un scenariu tabletop și să transformați constatările într-un plan de tratare a riscurilor pe care consiliul de administrație, autoritatea de reglementare și auditorul îl pot înțelege. Începeți prin revizuirea Politicii de jurnalizare și monitorizare, a Politicii privind gestionarea conturilor de utilizator și a privilegiilor - SME, a Zenith Blueprint și a Zenith Controls, apoi programați o evaluare a pregătirii ITDR pentru a transforma riscul privind identitatea în dovezi pregătite pentru audit.