Un portofoliu bun pentru un Detection Engineer nu trebuie să arate că știi doar să scrii o regulă care „sună bine”, ci că înțelegi relația dintre date, tehnica adversarului și impactul operațional al unei alerte. Dacă vrei să fii luat în serios la interviu, cele mai convingătoare exemple sunt cele în care poți demonstra trei lucruri: cum ai scris sau adaptat o regulă Sigma, cum ai mapat detecția la MITRE ATT&CK și cum ai redus zgomotul fără să strici utilitatea regulii.
Primul pas este să tratezi fiecare exemplu din portofoliu ca pe un mini-proiect de detecție, nu ca pe un simplu fișier YAML pus pe GitHub. Documentația Sigma arată clar că o regulă serioasă are elemente precum title, logsource, detection, references, falsepositives, level și tags. Asta înseamnă că un proiect bun nu se oprește la logică, ci include context: ce vrei să detectezi, din ce sursă de loguri, de ce contează și în ce situații legitime poate apărea aceeași activitate.
În practică, un exemplu solid de portofoliu poate avea o structură simplă: descrierea scenariului, logurile folosite, regula Sigma, maparea ATT&CK, ipotezele de tuning și rezultatul după reducerea alertelor false. Nu ai nevoie de zece proiecte. Trei sau patru exemple bine explicate sunt mai utile decât o colecție lungă de reguli fără context.
La partea de reguli Sigma, angajatorul va observa rapid dacă ai înțeles diferența dintre o regulă generică și una gândită pentru utilizare reală. În portofoliu, merită să explici de ce ai ales anumite câmpuri, ce dependențe are regula față de sursa de log și cum ai setat severitatea. Sigma recomandă inclusiv documentarea posibilelor false positive, iar acest detaliu te ajută direct: arată că gândești ca un detection engineer, nu doar ca cineva care copiază reguli din comunitate.
Maparea MITRE ATT&CK nu ar trebui folosită doar ca ornament. MITRE descrie ATT&CK drept o bază de cunoștințe accesibilă public, construită pe tactici și tehnici observate în lumea reală. În plus, secțiunea MITRE ATT&CK Analytics subliniază că analytics reprezintă logică de detecție specifică platformei și detalii de implementare ale unei strategii de detecție. În portofoliu, asta înseamnă că nu e suficient să scrii „T1059” lângă regulă. Explică de ce regula ta se leagă de o anumită tehnică, ce comportament urmărește și ce date susțin detecția.
O formulă simplă și bună este aceasta: tactică, tehnică, sursă de date, logică de detecție, limitări. De exemplu, dacă o regulă urmărește execuții PowerShell suspecte, arată ce câmpuri ai folosit, ce condiții declanșează alerta și ce activitate legitimă ar putea semăna cu acel comportament. Exact aici începe partea care diferențiază un portofoliu matur de unul superficial.
Capitolul decisiv este reducerea alertelor false. Atât Microsoft, cât și Elastic fac o distincție importantă: dacă regula este prea largă, trebuie tunată; dacă regula este corectă, dar se lovește de activitate benignă specifică mediului, pot fi mai potrivite excepțiile. Elastic spune explicit că tuning înseamnă modificarea interogării, pragului sau programării unei reguli astfel încât să prindă evenimente cu adevărat suspecte, iar Microsoft recomandă fie excepții controlate, fie modificări mai detaliate ale regulii, inclusiv folosirea unor allowlist-uri sau watchlist-uri.
În portofoliul tău, nu spune doar că „am redus false positive”. Arată înainte și după. De exemplu: regula genera alerte pentru un cont de administrare legitim sau pentru un proces intern de automatizare; ai identificat modelul benign; ai separat cazul prin excepție sau tuning; apoi ai documentat compromisul. Dacă poți explica și riscul introdus de acea decizie, cu atât mai bine. Un recrutor tehnic sau un lead SOC vrea să vadă că știi să reduci zgomotul fără să creezi orbire operațională.
Mai este un aspect important: prezintă și limitele. Dacă regula ta depinde de Sysmon, de anumite Event ID-uri sau de o schemă de logare care nu există peste tot, spune asta clar. Dacă maparea ATT&CK este aproximativă sau regula are acoperire parțială, notează acest lucru. Un portofoliu credibil nu pare perfect; pare bine argumentat.
Dacă vrei un rezultat convingător, construiește fiecare proiect ca pe o poveste de detecție: ce problemă urmărești, ce date ai, ce regulă ai scris, cum ai mapat la ATT&CK, ce zgomot ai observat și cum l-ai redus responsabil. Exact această combinație de claritate tehnică și gândire operațională te poate diferenția într-un rol de Detection Engineer.
