Triajul alertelor de securitate: cine citește la 3 noaptea

Sophos a analizat 661 de cazuri de răspuns la incident din 70 de țări și a găsit un tipar care nu ține de tehnologie: 88% dintre payload-urile de ransomware sunt lansate în afara programului de lucru, iar 79% dintre acțiunile de exfiltrare, la fel. Atacatorii nu așteaptă noaptea din superstiție. Așteaptă momentul în care triajul alertelor de securitate se oprește, pentru că nu se mai uită nimeni.

Într-o firmă care nu are un centru de operațiuni de securitate, problema rareori e că nu vede nimic. Semnalele există deja: sshd, nginx, firewall, un antivirus care trimite mailuri. Problema e triajul — cine separă, și în cât timp, cele trei lucruri care contează de cele trei sute care nu contează. În multe firme, răspunsul onest la „în cât timp" e „luni dimineața".

De ce triajul alertelor de securitate e gâtuirea, nu detecția

De ce ai alertele e o discuție separată, purtată în articolul despre servere expuse la internet. Aici pornim de după: alerta există deja, e în coadă, și cineva trebuie să decidă ce e cu ea.

Cât de mare e mormanul depinde de ce numești „alertă". Vectra AI, într-un studiu pe 1.450 de practicieni, raportează o medie de 2.992 de alerte pe zi — numărate brut, din tot parcul de unelte; 69% dintre respondenți folosesc peste zece unelte de detecție și răspuns, 39% peste douăzeci. Prophet Security, într-un studiu pe 250 de respondenți, raportează un volum median de circa 100 de alerte pe zi — dar acolo se numără ce ajunge efectiv în coada unui analist, după filtrare. Diferența de treizeci de ori nu e o eroare de măsurare, e o definiție diferită a cuvântului „alertă". Amândouă sunt studii plătite de furnizori care vând soluția la problema măsurată; tocmai de aceea le dăm pe amândouă.

Ce se știe mai bine e cât din morman e gol. O cercetare Omdia comandată de Microsoft — 300 de practicieni SOC din organizații de peste 750 de angajați — a găsit 46% fals-pozitive și analiști care comută între 10,9 console în medie, iar 66% dintre echipe pierd o cincime din săptămână doar agregând date. SANS Detection & Response Survey 2025 pune fals-pozitivele pe primul loc între problemele de detecție pentru 73% dintre echipe, iar categoria „foarte frecvent" a urcat de la 13% la 20% într-un singur an.

Fiecare alertă costă timp de om, și nu puțin. Prophet măsoară un timp median de investigare de aproximativ 45 de minute (medie ~75), cu 64% dintre echipe peste 30 de minute, plus încă 23 de minute median doar în coadă, până se uită cineva. Înmulțește cu volumul tău real și obții numărul de oameni de care ai avea nevoie ca să nu rămână nimic pe dinafară. Aproape nicio firmă mijlocie nu are numărul acela.

Consecința e măsurată de toată lumea, cu rezultate care nu se suprapun: 42% dintre alerte „neinvestigate" la Omdia/Microsoft, 28% în medie (22% median) la Prophet, 63% „netratate" la Vectra. „Nimeni nu s-a uitat" și „nu s-a făcut nimic" nu sunt același lucru, iar populațiile studiate diferă. Ordinul de mărime rămâne însă, indiferent pe cine crezi: între aproximativ un sfert și două treimi din alerte nu ajung nicăieri. Prophet adaugă detaliul incomod — 60% dintre organizații au avut alerte ignorate care s-au dovedit ulterior incidente reale.

• Alerta serioasă intră sâmbătă la 2:40 și e citită luni la 9:15, în același ecran cu alte trei sute de notificări de rutină.
• Nimeni nu poate spune repede dacă alerta e relevantă aici: o campanie reală împotriva unui produs pe care firma nu-l rulează arată, în listă, exact ca una care contează.
• Omul care ar putea decide e același care ține și imprimantele, și backup-urile, și migrarea de la furnizorul de mail.
• După a treia alarmă falsă din aceeași sursă, regula e dezactivată „temporar" — și rămâne dezactivată.
• Când chiar se întâmplă ceva, nu există nicăieri un istoric al deciziilor: cine s-a uitat, ce a văzut, pe ce bază a închis.

În România, peste asta se așază o aritmetică simplă a personalului. Un raport DNSC arată că țara are sub 3% specialiști ICT din totalul forței de muncă ocupate, față de o medie europeană de 5%, iar lipsa personalului calificat și resursele financiare insuficiente sunt principalele obstacole în majoritatea sectoarelor evaluate. ISC2 găsește 33% dintre organizații fără resurse ca să-și încadreze adecvat echipa de securitate și 29% care nu-și permit oameni cu competențele necesare. Tot raportul DNSC arată și că aproape 70% dintre organizațiile evaluate își consideră securitatea „bună" sau „foarte bună" — încrederea nu urmează aceeași curbă ca personalul.

Cele două ceasuri: cât durează, de fapt, până afli

Întrebarea „cât durează până afli" primește două răspunsuri care par să se bată cap în cap. IBM, în Cost of a Data Breach Report 2026 (cercetare Ponemon, 602 organizații, breșe petrecute între martie 2025 și februarie 2026), măsoară 247 de zile în medie pentru identificarea și limitarea unei breșe — în creștere de la 241 în ediția precedentă, adică o inversare a mai multor ani de îmbunătățire. Sophos, pe cele 661 de cazuri de răspuns la incident, măsoară un dwell time median de 3 zile.

Nu se contrazic. Măsoară capetele opuse ale aceleiași distribuții: în cazurile care ajung la o echipă de răspuns mediana e de zile, pentru că acolo intruziunea a fost detectată; în statistica breșelor raportate e de luni. Distanța dintre cele două populații e exact ce cumperi când cumperi triaj.

Fereastra utilă e însă mult mai mică decât oricare dintre cifre. Sophos măsoară 3,4 ore median până când atacatorul ajunge la serverul de Active Directory. CrowdStrike descrie o intruziune în care exfiltrarea de date a început la 4 minute de la accesul inițial. La 3,4 ore, o alertă care stă 23 de minute în coadă și mai cere 45 de minute de investigare încă poate ajunge la timp. La 4 minute, nu.

Distanța dintre „s-a întâmplat" și „cineva a decis că merită raportat" se vede cel mai bine în datele naționale. Senzorii DNSC au colectat peste 25 de milioane de evenimente de securitate cibernetică în 2025, dintre care circa 5,88 milioane de tentative de brute-force. În același an, la DNSC au fost raportate 47 de incidente de brute-force. Cele două cifre nu sunt comparabile — una e telemetrie de senzori, cealaltă e raportare de incidente — și tocmai de asta sunt utile împreună: între ele stă triajul. Iar obligația de raportare nu îl așteaptă: termenele către DNSC pornesc cu avertizarea inițială la 24 de ore, detaliate în ghidul nostru de pregătire pentru DNSC. Nu poți raporta în 24 de ore ceva ce afli în trei săptămâni.

Detecția e ieftină și poate rula singură, non-stop. Judecata e scumpă și doarme noaptea. Acolo e gâtuirea, nu la senzori.

Ce poate și ce nu poate un model în triaj

Aici intră AI-ul, și tot aici încep exagerările. Datele de piață sunt neobișnuit de clare despre unde e câștigul. Prophet raportează că 72% dintre cei care folosesc AI în triaj văd o reducere de peste 25% a timpului de investigare, cu o medie în jur de o treime, iar 18% raportează peste 50%. SANS Institute, într-un sondaj pe 536 de practicieni sponsorizat de un consorțiu de furnizori concurenți între ei, arată adopția AI în securitate urcând de la 50% la 78% într-un an — dar și 63% dintre practicieni care raportează lipsuri semnificative atunci când AI-ul detectează sau răspunde la amenințări, în creștere de la 45%. Doar 27% își descriu implementarea ca „matură".

Cele două rezultate nu se exclud. „Îmi economisește timp" și „mă induce uneori în eroare" pot fi ambele adevărate pentru același om, în aceeași săptămână. Eșecurile raportate la SANS se grupează pe fals-pozitive, pe dificultatea de a identifica amenințări noi și pe output formulat cu încredere, dar greșit. E o descriere exactă a ce e un model de limbaj: bun la explicat și la prioritizat, prost la garantat. Când aceiași respondenți enumeră cele mai eficiente controale împotriva amenințărilor cu AI, pe primele locuri apar detecția comportamentală (45%), trainingul de conștientizare (45%) și revizuirea de către un analist uman (39%).

Practica confirmă prudența. Torq a întrebat 450 de CISO și lideri de SOC: 97% sunt convinși că AI poate face triaj, dar doar 35% îl folosesc efectiv pentru asta, iar 9 din 10 vor să vadă cum ajunge modelul la o decizie înainte să-i extindă autonomia — 46% pun transparența și explicabilitatea pe primul loc între factorii care le-ar crește încrederea. În distribuția Prophet, 57% cer revizuire umană înainte de închiderea unei alerte, 44% lasă modelul să recomande și omul să execute, 30% permit execuție automată doar pentru acțiuni cu risc scăzut — și 0% acordă autonomie completă, nesupravegheată. Zero, într-un sondaj făcut de un furnizor care ar fi avut tot interesul la altă cifră.

Mai e un motiv, mai rar discutat, pentru care un model nu are ce căuta cu drepturi de execuție pe un server de producție. Prompt injection e riscul numărul unu în OWASP Top 10 for LLM Applications, ediția 2025, al doilea an consecutiv pe prima poziție, iar cauza e structurală: modelul primește instrucțiuni și date pe același canal, fără separare. Acum gândește-te ce e, de fapt, o linie de log: text scris de atacator, într-un câmp pe care el îl controlează. Dacă textul acela ajunge la un model care poate executa comenzi, nu ai construit un analist automat — ai construit exact scenariul LLM01. Mitigările din listă sunt plictisitoare și eficiente: segregarea explicită a conținutului extern, restricționarea privilegiilor, validarea inputului și om în buclă pentru operațiunile sensibile.

Cum arată un triaj care ține la 3 dimineața

Nimic din ce urmează nu presupune un SIEM sau o echipă în ture. Presupune doar că ordinea operațiilor e corectă.

1. 1Scrie ce înseamnă „grav" înainte să ai un incident, pe categorii: acces reușit față de tentativă, cont privilegiat față de cont de aplicație, serviciu expus față de serviciu intern. Fără pragul acesta, tot ce urmează e opinie.
2. 2Taie zgomotul înainte de coadă, nu în coadă. O alertă filtrată de un om a costat deja timp de om; una respinsă de o regulă deterministă nu a costat nimic.
3. 3Elimină explicit ce nu te poate atinge. O campanie reală, persistentă, împotriva unui produs pe care nu-l rulezi rămâne zgomot de fond — și e categoria cea mai ușor de automatizat corect.
4. 4Ține decizia de blocare deterministă: praguri, liste, reguli pe care le poți citi, testa și explica unui auditor. Modelul explică și prioritizează; regula decide.
5. 5Pune un canal care ajunge la un om în afara programului, nu un tablou de bord deschis luni dimineața. 88% dintre payload-urile de ransomware sunt lansate, după Sophos, în afara programului de lucru.
6. 6Prioritizează corecțiile după expunerea reală, nu după scorul brut: un CVSS 6,5 aflat pe lista CISA de vulnerabilități exploatate activ contează mai mult decât un 9,8 pe care nu-l exploatează nimeni. Un scanning recurent de vulnerabilități ține lista actualizată fără să depindă de memoria cuiva.
7. 7Păstrează ce s-a decis, nu doar ce s-a întâmplat. Un istoric al deciziilor de triaj e singurul lucru care face raportarea în 24 de ore posibilă și singurul care te scoate din discuția „cine a închis alerta aia".
8. 8Dacă nu ai pe cine pune de tură, externalizează partea de judecată, nu doar uneltele — un partener de securitate cibernetică cu plan de răspuns la incident scris și exersat.

Ce am construit noi — și ce încă nu face

Sentinel e răspunsul nostru la exact problema de mai sus, iar felul cel mai onest de a-l descrie e prin ce nu face. Detecția, scorarea și decizia rulează determinist, non-stop, la cost zero. Modelul e chemat doar pentru incidentele care trec pragul de severitate: citește ce s-a întâmplat și spune în română ce e real, ce e zgomot și ce ai de făcut, în sub două minute de la deschiderea incidentului, apoi redactează procedura de reparare. Se instalează pe infrastructura clientului și se predă cu documentație. O singură mașină sau o flotă, fără SIEM, fără agent extern, fără date trimise în afara serverului.

Cele patru limite ale modelului sunt publice, pentru că ele sunt, de fapt, arhitectura. Nu decide blocări. Nu execută nimic — planul pe care îl redactează trece printr-un validator determinist care îl refuză dacă nu e sigur; modelul redactează, validatorul decide. Nu stă pe calea critică: dacă API-ul e căzut sau bugetul e epuizat, detecția, blocarea și alertarea merg mai departe, marcate „analiză AI indisponibilă". Și nu depășește bugetul — plafonul e verificat înainte de fiecare apel.

La problema OWASP de mai sus, răspunsul e la fel de plictisitor pe cât trebuie să fie: liniile de log și căile HTTP sunt tratate ca date neîncrezute, cu delimitatori expliciți, iar transportul care citește fișiere de pe server rulează în modul plan — structural incapabil să modifice ceva. Există un test care plantează IGNORE PREVIOUS INSTRUCTIONS într-un access log și verifică că nu s-a executat nimic. Pe partea de blocare, lista de adrese protejate e hard-codată în cod, nu în configurație și nu în baza de date; regula de bază e policy accept, adică un deny-lister, nu un firewall; iar un fișier PANIC golește toate blocările în sub 60 de secunde. Blocarea automată se livrează oprită: în primele 72 de ore primești doar ce ar fi blocat.

Cifrele care urmează sunt de la un singur server al nostru, în 24 de ore — o instalare de producție pe AlmaLinux 9, cu 14 aplicații monitorizate. Nu sunt un eșantion și nu sunt „tipic": 1.055 de atacatori unici, 2.765 de evenimente ostile din 7.031 în total, 554 de incidente deschise din care 13 grave, 5 adrese blocate. Zgomotul e respins înainte de baza de date — circa 96.000 de diagnostice de motor pe zi nu ajung acolo — iar modelul e apelat doar pentru incidentele care trec pragul, de regulă câteva zeci pe zi. Un exemplu concret de triaj din același panou: „campanie activă împotriva GLPI, 560 de sondări". Reală, persistentă, țintită. Serverul nu rulează GLPI, deci e zgomot de fond — iar asta trebuie spus în clar, nu lăsat să ocupe primul loc într-un tablou de bord.

Ce nu face încă e tot public: logurile din containere nu sunt colectate, nu există un monitor dedicat de integritate a fișierelor dincolo de auditd, iar instalarea pe Debian e acoperită de teste, dar încă neverificată pe o gazdă Debian reală. Licența e per server, iar configurarea inițială și calibrarea de 72 de ore sunt incluse în toate variantele; arhitectura, limitele și platformele acoperite sunt descrise pe pagina produsului.

Concluzie

Detecția s-a ieftinit până la banalitate: orice server modern generează deja mai multe semnale decât poate citi cineva. Ce nu s-a ieftinit e judecata — cine se uită, în cât timp, și pe ce bază decide că un lucru contează. Diferența dintre o firmă care află în trei zile și una care află după luni de zile nu stă în unelte, stă în triaj, iar triajul se poate proiecta, nu doar spera. AI-ul ajută la partea de explicație și de prioritizare, unde e măsurabil bun; decizia de blocare rămâne acolo unde poate fi citită și testată. Dacă vrei să ne uităm împreună la ce generează acum serverele tale și cât din asta ajunge efectiv la un om, hai să discutăm 30 de minute.

Surse

• Sophos — „Active Adversary Report 2026", 661 de cazuri IR și MDR, noiembrie 2024 – octombrie 2025 (sophos.com)
• Microsoft Security Blog — „Unify now or pay later", cercetare Omdia comandată de Microsoft, N=300 practicieni SOC, februarie 2026 (microsoft.com/security/blog)
• SANS Institute — Detection & Response Survey 2025 (relatat de stamus-networks.com) și „2026 SANS AI Survey", N=536, iulie 2026 (sans.org)
• Prophet Security / ViB — „State of AI in the SOC 2026", N=250, august 2026 (prophetsecurity.ai) — studiu de furnizor „AI SOC"
• Vectra AI — „State of Threat Detection and Response 2026", N=1.450 (vectra.ai) — studiu de furnizor
• Torq — „2026 AI SOC Leadership Report", teren Sapio Research, 450 de CISO și lideri de SOC, martie 2026 (torq.io) — studiu de furnizor
• IBM — „Cost of a Data Breach Report 2026", cercetare Ponemon Institute, 602 organizații, iulie 2026 (ibm.com/reports)
• CrowdStrike — „2026 Global Threat Report", telemetrie proprie, februarie 2026 (crowdstrike.com)
• DNSC — raportul anual de activitate pentru 2025, aprobat prin Hotărârea CSAT nr. 117 din 7 august 2026 (relatat de agerpres.ro și business24.ro); raport DNSC privind deficitul de specialiști (relatat de europafm.ro)
• ISC2 — Cybersecurity Workforce Study 2025, decembrie 2025 (isc2.org)
• OWASP GenAI Security Project — Top 10 for Large Language Model Applications 2025, LLM01 Prompt Injection (owasp.org)
• CryptoITData — Sentinel, documentație de produs și date dintr-o singură instalare de producție (cryptoitdata.eu/sentinel)