Momelile cibernetice, pe înțelesul apărării: ce recomandă noul ghid CISA

Perimetrul cade. Nu e o ipoteză pesimistă, e premisa de la care pornește orice model Zero Trust: presupui că un atacator va obține, la un moment dat, un anumit nivel de acces în interior. Întrebarea care contează nu mai e dacă intră, ci cât de repede afli. Iar aici majoritatea organizațiilor stau prost: dwell time-ul — timpul dintre compromitere și detecție — se măsoară în continuare în săptămâni, nu pentru că atacul e subtil, ci pentru că nimic din rețea nu e pus acolo special ca să fie atins greșit.

Pe 16 septembrie 2026, agenția americană de securitate cibernetică — Cybersecurity and Infrastructure Security Agency (CISA) — a publicat un ghid dedicat exact acestei probleme: Using Cyber Decoys to Strengthen Detection and Response (TLP:CLEAR). Documentul e o resursă introductivă, gândită pentru organizații mici și medii și pentru echipele care abia acum se apropie de deception. Merită citit pentru că normalizează o idee care încă e tratată ca „exotică” în multe SOC-uri: momelile nu sunt un lux pentru echipe mature, ci un mecanism de detecție ieftin, incremental și cu semnal foarte curat.

Trecem prin ce spune ghidul și, la final, arătăm unde se leagă concret de munca noastră.

Ce sunt, de fapt, momelile

O momeală (în engleză decoy sau lure) este un activ care pare legitim — un sistem, un cont, un fișier, un set de credențiale — dar care nu are niciun rost operațional real. E pus acolo dintr-un singur motiv: nimic legitim nu are de ce să-l atingă. Prin urmare, prima atingere e, prin definiție, suspectă.

CISA folosește un vocabular precis, adaptat din glosarul MITRE Engage:

• Momeli (decoys / lures) — active care par sisteme, conturi sau date legitime, dar sunt concepute să distragă atacatorii, să le detecteze prezența sau să faciliteze colectarea de informații despre amenințare (CTI).
• Tripwires — momeli configurate astfel încât orice interacțiune (acces, tentativă de autentificare, execuție de comandă) generează o alertă. Orice momeală devine tripwire dacă e integrată cu monitorizare și alertare.
• Breadcrumbs — artefacte-momeală plasate intenționat pentru ca atacatorul să le urmeze, ducându-l spre alte momeli sau spre medii controlate.

Documentul separă clar două familii de momeli, prin comparație directă:

Atribut	Honeypot	Honeytoken
Nivel de operare	sistem / rețea	date / activ
Ce e	sistem sau serviciu-momeală, adesea cu vulnerabilități intenționate	element de date fără scop legitim, plasat printre active reale
Complexitate	medie spre mare	mică
Maturitate necesară	mare	mică
Exemple	servere, baze de date, pagini web, clienți	fișiere, înregistrări, conturi, credențiale, adrese de email, URL-uri false

Distincția e importantă operațional. Honeypot-ul e un sistem întreg pe care îl întreții și îl izolezi — costă timp și disciplină. Honeytoken-ul e un fir de date otrăvit pe care îl semeni printre cele reale — se implementează repede, cu maturitate scăzută, și produce exact același semnal de mare valoare: cineva a atins ceva ce nu trebuia atins.

De ce funcționează: semnal, nu zgomot

Problema clasică a unui SOC nu e lipsa de alerte, ci excesul lor. Detecția pe comportament și pe semnături produce mii de evenimente pe zi, dintre care multe sunt fals-pozitive. Analiștii triază ce e mai zgomotos, nu neapărat ce e mai important, și obosesc. Iar tehnicile living off the land (LOTL) — atacatorul care folosește uneltele native ale sistemului și credențiale valide — arată exact ca administrarea normală. Nu există anomalie de detectat.

Momelile inversează logica. CISA notează că operațiunile de tip Expose bazate pe momeli:

• generează alerte de înaltă fidelitate, care reprezintă comportamente cu utilizare legitimă mică sau nulă;
• reduc zgomotul, pentru că interacțiunile cu o momeală ar trebui să fie rare în operarea normală;
• oferă indicii mai timpurii și mai clare de compromitere, reducând timpul mediu până la detecție (MTTD).

Iar partea elegantă e că valoarea nu vine din cât de bun e un algoritm, ci dintr-o proprietate simplă a mediului: dacă un fișier, un cont sau o cheie API nu are niciun utilizator legitim, atunci orice atingere e, prin construcție, un indicator. N-ai ce fals-pozitiva. Documentul subliniază că momelile sunt utile mai ales împotriva tehnicilor LOTL, acolo unde abordările clasice pe semnături se descurcă prost.

Cadrul: MITRE Engage și ATT&CK

Ghidul nu propune improvizație. Structurează totul pe MITRE Engage — un cadru pentru planificarea, implementarea și evaluarea activităților de adversary engagement — și pe baza de cunoștințe MITRE ATT&CK, care descrie tacticile și tehnicile atacatorilor.

Engage grupează obiectivele în trei categorii:

• Expose — detectezi atacatorii care operează în mediu. Aici stau majoritatea câștigurilor rapide: momeli plasate acolo unde utilizatorii legitimi n-ar trebui să ajungă, configurate să producă alerte de înaltă fidelitate.
• Affect — impui cost atacatorului: îl deviezi spre sisteme-momeală, îi otrăvești recunoașterea cu conturi și servicii false, îl faci să piardă timp pe date fără valoare.
• Elicit — observi atacatorul într-un mediu controlat și realist, ca să colectezi CTI de mare valoare despre TTP-urile lui.

Recomandarea de ordine e clară și onestă: întâi Expose, apoi, unde are sens, Affect; la Elicit ajungi ultimul, pentru că cere medii realiste dar izolate, monitorizare matură și oameni care pot duce riscurile operaționale și legale. Nu sări treptele.

Peste asta, Engage descrie un proces în 10 pași, împărțit în trei faze — Prepare, Operate, Understand — de la evaluarea cunoștințelor despre adversar și despre propria organizație, până la analiza succeselor și eșecurilor care alimentează operațiunea următoare. Ideea de fond: deception-ul nu e un proiect cu final, e un ciclu.

Tipurile de honeytoken și de unde le iei

Pentru că honeytoken-urile sunt calea cu cea mai mică barieră de intrare, ghidul le detaliază. Orice activ care pare legitim și ar putea interesa un atacator poate fi honeytoken:

• Fișiere și documente care par să conțină informații sensibile și generează alerte când sunt deschise, copiate sau modificate.
• Înregistrări de date — intrări false plasate lângă cele reale; accesarea lor semnalează explorare neautorizată sau furt de date.
• Conturi dezactivate sau nefolosite; orice tentativă de autentificare e suspectă.
• Credențiale — parole, chei API sau token-uri false stocate în locuri controlate; folosirea lor indică o compromitere și ajută la identificarea locului de unde au fost furate.
• Adrese de email momeală plasate în directoare sau aplicații; un email trimis către ele indică acces neautorizat la magazia subiacentă.
• Artefacte web — URL-uri sau linkuri false fără rost de business; o cerere către ele generează alertă.

O strategie eficientă, spune CISA, folosește mai multe tipuri de token și le plasează în mai multe locuri (servere-cheie, stații de lucru, repository-uri cloud, sisteme de identitate), ghidată de CTI și de căile probabile de atac. Diversitatea crește șansa ca un atacator care ocolește un set de controale să declanșeze altul — și ajută apărătorii să deducă obiectivele și mișcarea atacatorului după token-urile atinse.

Pentru sursă, documentul enumeră patru abordări, fără să favorizeze un vendor: soluții open-source (bune pentru pilot și bugete mici), soluții comerciale (management centralizat, rapoarte, suport), implementări proprii (croite pe mediu, pentru echipe cu capacitate de dezvoltare) și abordări LOTL — folosirea uneltelor deja existente (EDR, IAM, DLP) pentru a desfășura și monitoriza momeli fără să cumperi tooling nou.

Cum planifici corect: ATT&CK, gap analysis, purple team

Partea cea mai utilă a ghidului nu e lista de momeli, ci metoda de a decide unde le pui. CISA descrie un proces care suprapune trei hărți ATT&CK:

1. Vulnerabilitățile tale — ce tactici și tehnici ți se aplică, dat fiind mediul și configurațiile.
2. Acoperirea defensivă — ce detectezi deja (EDR, SIEM, segmentare, IAM, SOAR) și unde ai găuri.
3. Capabilitățile adversarului — ce TTP-uri folosesc actorii care te vizează, din CTI și din incidente anterioare.

Suprapunerea lor scoate la iveală golurile de mare risc: tehnici pentru care ești vulnerabil, adversarii operează, dar detecția e slabă sau absentă. Acolo pui momelile. În scenariul din ghid — o organizație din sectorul apă și apă uzată — analiza scoate goluri clare pe phishing, pe execuția PowerShell (LOTL) și pe exfiltrarea către backup-uri cloud, iar momelile sunt proiectate exact pe acele tehnici (conturi false cu privilegii reduse, servicii pe porturi-momeală, token-uri de comandă sensibile pe stațiile de lucru).

Și, esențial: după ce plantezi, testezi. Ghidul cere emulare de amenințare, red teaming sau purple teaming cu tehnici ATT&CK relevante, ca să verifici că momelile chiar se declanșează și că alertele ajung la apărători și sunt tratate la timp. O momeală care nu produce o alertă vizibilă și acționabilă e doar un fișier în plus. Deception-ul se validează, nu se presupune.

Unde se leagă de Vigilum

Tot ghidul acesta descrie, în limbaj de recomandare oficială, exact principiul pe care l-am construit în Vigilum, platforma noastră de detecție prin deception: plantezi momeli credibile în infrastructura ta, aștepți, afli. Niciun proces legitim nu are motiv să le atingă, deci prima atingere e, prin definiție, un intrus.

Câteva puncte în care recomandările CISA și felul în care lucrăm se suprapun natural:

• Expose, întâi. Vigilum e centrat pe scopul cu cel mai bun raport efort/semnal din Engage: detecția, cu alerte de înaltă încredere. Mai puțin zgomot, mai multă certitudine.
• Momeli croite pe mediu, nu template. Ghidul insistă că momelile trebuie să fie plauzibile și informate de amenințare. Vigilum generează momelile pentru mediul tău concret — convențiile tale de denumire, stack-ul tău, topologia ta — nu un set identic la toți clienții. O momeală care nu se potrivește mediului nu e atinsă.
• Mișcare laterală cu atribuire. Exact cazul dificil din ghid — atacatorul cu credențiale valide care „arată ca un admin” — e cel pe care momelile îl rezolvă: nu cauți o anomalie, aștepți o atingere care n-are explicație legitimă.
• On-prem sau airgap. Documentul recomandă ca documentația momelilor să stea în afara mediului de producție, iar deception-ul să funcționeze și în rețele izolate. Vigilum rulează la tine în rack, inclusiv complet deconectat.
• Validare prin purple team. Pasul de emulare din ghid e chiar serviciul pe care îl facem de douăzeci de ani: testăm că momelile se declanșează și că răspunsul funcționează, cu tehnici ATT&CK reale. Uneltele reduc timpul mort; judecata rămâne a testerului.

Vigilum este în Early Access — deschidem accesul treptat, pentru echipe care vor să treacă de la „presupunem că suntem compromiși” la „aflăm în minute, nu în săptămâni”. Dacă ghidul CISA ți-a confirmat o intuiție pe care o aveai deja, hai să vorbim despre cum arată deception-ul în infrastructura ta.

În loc de concluzie

Momelile nu înlocuiesc EDR-ul, SIEM-ul sau segmentarea. Le completează, într-un loc unde acestea se descurcă prost: post-compromitere, împotriva atacatorului care folosește unelte legitime și credențiale furate. Meritul ghidului CISA e că spune asta simplu și că coboară bariera de intrare — cu honeytokens, orice echipă poate începe mâine, incremental, fără să-și rescrie arhitectura.

Iar principiul de fond e cât se poate de sobru: nu încerci să ghicești ce e rău. Pui în rețea câteva lucruri pe care nimic bun nu are de ce să le atingă — și aștepți prima atingere.

---

Sursă: Cybersecurity and Infrastructure Security Agency (CISA), „Using Cyber Decoys to Strengthen Detection and Response”, 16 septembrie 2026 (TLP:CLEAR). Cadre de referință: MITRE Engage™ și MITRE ATT&CK®.