Momeli cibernetice: ghidul CISA pentru detecție internă

Ce problemă încearcă să rezolve

Documentul pornește de la trei constatări pe care majoritatea echipelor le recunosc imediat: volume mari de alerte, multe dintre ele fals pozitive; capacitate limitată de analiză, care duce la oboseală de alertă; și dificultatea de a detecta activitatea post-compromitere, mai ales când atacatorii folosesc unelte native ale sistemului și credențiale legitime.

Ideea centrală este că o momeală bine plasată produce semnal cu zgomot aproape zero. Nu pentru că detectează mai bine, ci pentru că nimeni nu are motiv să o atingă. CISA formulează asta ca generare de alerte de înaltă fidelitate pentru comportamente care au puțină sau nicio utilizare legitimă, cu reducerea zgomotului pentru că interacțiunile cu momelile ar trebui să fie rare în operarea normală.

Documentul precizează explicit că se ocupă de momeli desfășurate în interiorul mediului propriu, în rețele, sisteme și servicii interne, și nu de honeypot-uri tradiționale expuse în internet. Distincția merită reținută, pentru că schimbă complet discuția despre risc și despre ce anume monitorizezi.

• ▸CISA — Using Cyber Decoys to Strengthen Detection and Response
• ▸CISA — anunțul publicării ghidului, 16 septembrie 2026

Vocabularul, pentru că termenii nu sunt sinonime

• ▸Momeli, sau lures: active care par sisteme, conturi sau date legitime, dar sunt proiectate să distragă atacatorii, să le detecteze prezența sau să sprijine colectarea de informații despre amenințări.
• ▸Tripwire: o momeală configurată astfel încât orice interacțiune, fie ea acces, încercare de autentificare sau execuție de comandă, generează o alertă. Documentul notează că orice momeală poate funcționa ca tripwire dacă este integrată cu monitorizare și alertare corespunzătoare.
• ▸Breadcrumbs: artefacte plasate intenționat pe care atacatorii sunt încurajați să le urmeze, ducând către alte active-momeală sau către medii controlate.
• ▸Honeytoken: elemente de date sau obiecte logice fără nicio utilizare legitimă de business, plasate printre active reale pentru a detecta accesul neautorizat sau exfiltrarea.
• ▸Honeypot: sisteme sau servicii-momeală, adesea cu funcționalitate limitată dar realistă și cu vulnerabilități intenționate.

De ce un honeytoken este punctul realist de start

Ghidul include o comparație directă între honeypot și honeytoken care răspunde la întrebarea practică „de unde încep”. Honeypot-ul operează la nivel de sistem sau rețea, are complexitate medie spre mare și cere maturitate de securitate ridicată. Honeytokenul operează la nivel de date sau activ, are complexitate mică și cere maturitate mică.

Tipurile enumerate sunt concrete: fișiere și documente care par să conțină informații sensibile și alertează la deschidere, copiere sau modificare; înregistrări de date false plasate lângă cele reale; conturi dezactivate sau nefolosite, la care orice încercare de autentificare este suspectă; credențiale false, parole, chei API sau tokenuri plasate în locații controlate, a căror folosire indică o compromitere și ajută la identificarea locului de unde au fost obținute; adrese de e-mail-momeală plasate în directoare sau aplicații; și artefacte web, adică URL-uri fără nicio utilizare legitimă, la care orice cerere generează alertă.

Credențialele-momeală merită o notă aparte. Utilitatea lor nu este doar că semnalează o compromitere, ci că îți spun de unde a fost luată credențiala. Dacă plasezi tokenuri diferite în locuri diferite, alerta îți indică și traseul atacatorului prin mediu.

• ▸CISA — tipuri de honeytokenuri și comparația cu honeypot-urile

Exemplul din ghid și detaliul pe care nu îl poți sări

Scenariul dat de CISA este simplu: un manager de proiect are un share de rețea personal cu rapoarte lunare pentru un proiect sensibil. Echipa de securitate evaluează share-ul ca țintă probabilă și plasează în el câteva fișiere-momeală cu nume precum Project_Metrics.xlsx și Budget_Data.docx, cu conținut realist dar fictiv, instrumentate astfel încât orice acces declanșează o alertă.

Pasul care face mecanismul să funcționeze este al treilea: echipa îl informează pe managerul de proiect că fișierele sunt momeli și îi cere să nu le deschidă și să nu le mute. Tocmai pentru că share-ul este accesibil doar lui și el știe despre momeli, orice interacțiune cu acele fișiere devine un indicator puternic de activitate neautorizată în cont sau în share.

Dacă sari acest pas, obții exact opusul: o sursă constantă de alerte false, produse de utilizatorul legitim, care în câteva săptămâni va fi dezactivată de cineva obosit de ea. Fidelitatea alertei nu vine din tehnologie, ci din faptul că ai eliminat, prin comunicare, singura interacțiune legitimă posibilă.

Pentru acoperire mai largă, ghidul recomandă mai multe tipuri de tokenuri în mai multe locuri, pe servere-cheie, stații de lucru, depozite cloud și sisteme de identitate, folosind informațiile despre amenințări și cunoașterea căilor probabile de atac. Diversitatea crește probabilitatea ca un atacator care ocolește un control să declanșeze altul.

• ▸CISA — exemplu de honeytoken tripwire pe un share de proiect

Legătura directă cu registrul tău de vulnerabilități

Ghidul enumeră trei cazuri de utilizare pentru tripwire-uri. Primele două sunt previzibile: protejarea activelor sau datelor critice, prin share-uri și fișiere-momeală care seamănă cu depozite sensibile, și protejarea personalului-cheie, prin momeli pe stațiile de lucru ale directorilor, în conturi de e-mail sau în share-uri personale.

Al treilea este cel care ar trebui să intereseze o echipă de management al vulnerabilităților: acoperirea vulnerabilităților sau slăbiciunilor cunoscute, folosind tripwire-uri drept controale compensatorii acolo unde remedierea este întârziată sau complexă. Exemplul dat de CISA este alertarea la execuția de PowerShell pe stațiile unde utilizatorii obișnuiți nu au nevoie de PowerShell.

Tradus în practica zilnică: fiecare excepție din registrul tău de patch-uri este astăzi o linie care spune „știm, dar nu putem încă”. Un tripwire plasat în jurul acelui sistem transformă excepția dintr-un risc acceptat pasiv într-un risc monitorizat. Nu remediază nimic, iar ghidul nu pretinde asta. Dar schimbă ce știi dacă cineva ajunge acolo, iar asta este o diferență pe care o poți documenta la o revizuire.

Cele patru proprietăți pe care CISA le cere unui tripwire eficient merită folosite ca listă de verificare: să fie informat de amenințări, adică proiectat pe baza informațiilor curente și a modelului propriu de amenințare; distinct de comportamentul normal, adică orice interacțiune să fie inerent neobișnuită sau neautorizată; detectabil, adică instrumentat astfel încât să genereze alerte în sistemele de monitorizare existente; și acționabil, adică legat de proceduri clare de investigare și răspuns.

• ▸CISA — proiectarea și utilizarea tripwire-urilor
• ▸MITRE Engage — cadrul de referință folosit în ghid

Unde se oprește ghidul, și de ce este bine că se oprește acolo

Documentul folosește cadrul MITRE Engage, care grupează obiectivele în trei categorii: Expose, adică detectarea atacatorilor din mediu; Affect, adică impunerea de costuri și reducerea valorii acțiunilor lor; și Elicit, adică observarea în siguranță a atacatorilor pentru colectarea de informații în timp real.

CISA este explicită în privința ordinii: organizațiile ar trebui să stabilească întâi capabilități de bază de tip Expose și, unde este cazul, activități selectate de tip Affect, înainte de a lua în calcul Elicit. Pentru elicitare, documentul cere medii foarte realiste dar izolate, capabilități mature de monitorizare și logare, și personal calificat capabil să gestioneze riscurile operaționale și juridice asociate.

Aceasta este o precauție care merită citită de două ori. A detecta un intrus prin fișiere-momeală este o activitate defensivă obișnuită. A-l ține deliberat într-un mediu controlat ca să îl observi este altceva, cu implicații juridice și operaționale care nu se rezolvă cu entuziasm tehnic. Ghidul nu interzice nimic, dar pune Elicit la capătul drumului, nu la început.

În privința uneltelor, documentul descrie patru abordări fără să recomande produse: soluții open-source, potrivite pentru pilot și bugete limitate; soluții comerciale, uneori parte din platforme EDR mai largi; implementări proprii, pentru organizații cu capacitate de dezvoltare; și abordări care folosesc ce ai deja, adică platforme EDR, sisteme de identitate și acces sau unelte de prevenire a pierderii de date, pentru a desfășura și monitoriza honeytokenuri fără achiziții suplimentare. Ultima variantă este, pentru majoritatea echipelor mici, singura realistă în trimestrul curent.

• ▸CISA — Expose, Affect, Elicit și precauțiile pentru elicitare
• ▸MITRE ATT&CK — baza de cunoștințe folosită pentru planificare

Cum arată un început onest și ce dovezi păstrezi

Awarely Monitor ajută la urmărirea vulnerabilităților, a responsabililor, a excepțiilor și a dovezilor deciziilor până la închidere. Nu desfășoară momeli, nu generează honeytokenuri, nu colectează alerte din mediul tău și nu înlocuiește un SIEM sau un EDR. Plasarea momelilor, instrumentarea alertelor și investigarea lor rămân în uneltele de detecție și în procesul de răspuns al organizației.

• ▸Pornește de la inventar. Primul pas de planificare din ghid cere inventare de active IT și OT, diagrame de rețea, capabilitățile de detecție existente, logurile și regulile disponibile, rezultatele testelor de penetrare anterioare și informațiile despre amenințări relevante pentru sector. Fără prima linie, restul este ghicit.
• ▸Alege două sau trei locuri unde nicio interacțiune legitimă nu este posibilă, nu zece. Un cont de serviciu dezactivat, un fișier într-un share cu un singur utilizator informat, o cheie API falsă într-un loc pe care doar un atacator l-ar căuta.
• ▸Verifică înainte de plasare că alerta ajunge undeva unde cineva o citește și că există o procedură scrisă pentru ce se întâmplă după. O momeală fără destinatar este o momeală fără rost.
• ▸Informează explicit proprietarii legitimi ai locurilor unde plasezi momeli și păstrează dovada acestei comunicări. Este pasul care face alerta credibilă mai târziu.
• ▸Documentează pentru fiecare momeală: unde este, ce tip este, ce declanșează alerta, cine a fost informat, unde ajunge alerta și când a fost verificată ultima dată că funcționează.
• ▸Leagă momelile de excepțiile din registrul de vulnerabilități pe care le acoperă, astfel încât o revizuire să poată vedea ce risc a fost acceptat și ce monitorizare compensatorie a fost pusă în loc.