Două SOC-uri, aceleași tactici, rezultate opuse: lecțiile evaluării CISA

CISA a publicat la 25 august 2026 rezultatele a două evaluări red-team desfășurate simultan în organizații americane de infrastructură critică. Echipele au folosit tactici similare, iar în ambele medii evaluarea controlată a ajuns la compromitere de domeniu și acces la sisteme de business sensibile și resurse cloud. Răspunsul defensiv a fost însă radical diferit.

Ce s-a întâmplat în cele două medii

• Organizația A aparținea sectorului Government Services and Facilities. Organizația B aparținea sectorului Water and Wastewater Systems.
• În Organizația A, conturi implicite și alte configurări slabe au permis trimiterea unor mesaje de phishing dintr-o adresă internă și accesul inițial la stații de lucru.
• Evaluatorii au găsit credențiale în clar, chei cloud statice fără expirare și aplicații Entra ID cu permisiuni prea largi.
• Organizația A a primit alerte asociate activității, dar zgomotul, SOC-urile fragmentate, lipsa ownerilor și autoritatea limitată au împiedicat escaladarea eficientă.
• Organizația B a detectat execuția payloadurilor de phishing și a izolat stațiile afectate în aproximativ 2–20 de minute, întrerupând comunicațiile inițiale.
• CISA a continuat apoi evaluarea Organizației B printr-un host desemnat, pentru a simula o breșă deja produsă și a testa controalele din Active Directory, cloud și zona OT.

Diferența nu a fost numărul de produse de securitate

Organizația care nu a reacționat nu ducea lipsă de alerte sau instrumente. Problema a fost transformarea semnalului în decizie: alertele utile erau acoperite de falsuri pozitive, vizibilitatea era împărțită între mai multe echipe, proprietarul unui server nu putea fi identificat, iar analiștii nu aveau proceduri și autoritate suficientă pentru a interveni. CISA atribuie diferența oamenilor și proceselor care operau tehnologia.

Deciziile necesare, împărțite pe roluri

• Utilizatorii raportează mesajele interne neobișnuite și nu presupun că domeniul companiei dovedește legitimitatea solicitării.
• Help desk-ul recunoaște semnalele care nu sunt simple probleme de stație și păstrează ticketul, ora, utilizatorul și acțiunile deja efectuate.
• SOC-ul unește telemetria endpoint, identitate, e-mail și cloud într-o cronologie și documentează criteriile care transformă o alertă în incident.
• Administratorii Active Directory și cloud cunosc dinainte pașii pentru revocarea tokenurilor, izolarea conturilor și limitarea aplicațiilor cu permisiuni excesive.
• Ownerii de servicii răspund la apelurile de urgență și pot explica impactul izolării unui activ fără să blocheze răspunsul până la certitudine absolută.
• Managementul acordă echipelor defensive autoritatea clară de a izola sisteme în limite prestabilite și acceptă degradarea controlată a unui serviciu pentru limitarea incidentului.
• Echipele OT verifică barierele dintre IT, zona demilitarizată și sistemele operaționale și păstrează căi de continuitate independente.

Tabletop: alerta corectă care se pierde în coadă

Rulează exercițiul cu SOC, help desk, identity, cloud, administratori de sistem, owneri de servicii, OT și management. Fiecare inject trebuie să producă o decizie, un owner, un timp-limită și o dovadă verificabilă.

• Inject 1 — un e-mail intern neobișnuit declanșează alerte de severitate medie pe patru endpointuri, în timp ce coada conține sute de alerte mai severe. Cine îl prioritizează și de ce?
• Inject 2 — unul dintre endpointuri comunică extern, dar aplicația de business deschisă pe el este critică. Cine poate aproba izolarea imediată?
• Inject 3 — alerta indică un server SCCM, iar CMDB-ul nu are owner actual. Cine preia decizia și cum este reparată lacuna de ownership?
• Inject 4 — apar un token cloud și o aplicație Entra ID cu acces larg la e-mail. Este suficientă resetarea parolei sau trebuie revocate sesiuni, chei și granturi?
• Inject 5 — o credențială în clar permite acces privilegiat. Cine conservă dovada, cine rotește secretul și cum verifică dependențele înainte de schimbare?
• Inject 6 — activitatea ajunge la un bastion din zona OT, dar conexiunea externă este blocată. Ce izolezi, ce menții funcțional și cine coordonează continuitatea?

Cum măsori diferența dintre procedură și capacitate reală

• Timpul dintre prima alertă relevantă și declararea incidentului.
• Timpul până la identificarea ownerului sau activarea ownerului de rezervă.
• Timpul până la izolarea endpointului și întreruperea comunicației externe.
• Procentul incidentelor în care endpoint, identitate, e-mail și cloud apar în aceeași cronologie.
• Procentul conturilor și aplicațiilor privilegiate pentru care echipa poate revoca sesiuni, tokenuri și chei în intervalul stabilit.
• Numărul alertelor fals pozitive eliminate prin tuning fără pierderea scenariilor importante.
• Procentul participanților care diferențiază oprirea accesului inițial de verificarea unei compromiteri deja existente.

Ce rămâne necunoscut și ce nu trebuie generalizat

CISA a anonimizat organizațiile și nu publică toate detaliile arhitecturale. Rezultatele descriu două medii și nu demonstrează că un anumit produs, model de SOC sau sector va avea același rezultat. Evaluarea Organizației B a fost continuată deliberat după oprirea accesului inițial, astfel încât compromiterea ulterioară nu trebuie confundată cu un eșec identic de detecție.

Cum transformi evaluarea într-un modul Learning Awarely

Materialul poate deveni un parcurs diferențiat pe roluri: utilizatorul decide dacă raportează, analistul prioritizează, ownerul de serviciu estimează impactul, administratorul revocă accesul, iar managementul autorizează izolarea. Evaluarea trebuie să urmărească timpul și calitatea deciziei, nu memorarea tehnicilor CISA.

Learning Awarely poate distribui scenariile, evalua răspunsurile și păstra evidențe de finalizare și recertificare. Platforma nu înlocuiește SIEM, EDR, CMDB, controalele de identitate sau exercițiul tehnic autorizat și nu demonstrează singură că un SOC poate detecta un atac real.