Dacă vrei un proiect de portofoliu credibil pentru un rol de Security Data Engineer, una dintre cele mai bune alegeri este normalizarea logurilor din surse diferite într-o schemă comună. Nu este cel mai spectaculos demo, dar este genul de proiect care arată direct cum gândești datele de securitate, cum le structurezi și cum le faci utile pentru analiză, detecție și investigație.
De ce proiectul contează
În practică, echipele de securitate nu lucrează cu un singur tip de jurnal. Au loguri din Windows, Linux, firewall, VPN, identitate, endpoint sau aplicații cloud. Problema este că aceste surse descriu evenimente similare în moduri diferite. Modelul ASIM din Microsoft Sentinel explică tocmai utilitatea normalizării: detecțiile cross-source și interogările devin mai simple atunci când câmpurile rămân consistente. OCSF merge pe aceeași idee și propune un cadru comun pentru date de securitate, iar Elastic ECS oferă o structură standardizată pentru organizarea evenimentelor. Pentru un interviu, asta este o temă excelentă, pentru că dovedește că înțelegi o problemă reală, nu doar un exercițiu de laborator.
Cum alegi sursele de loguri
Nu ai nevoie de un volum mare de date. Mai util este să alegi două sau trei surse diferite și să arăți că poți reconcilia formate neomogene. Un exemplu bun este o combinație de autentificări Windows, evenimente SSH din Linux și loguri de firewall sau VPN. Acestea sunt suficient de diferite încât să demonstreze partea de parsare și mapare, dar suficient de cunoscute încât proiectul să poată fi explicat clar.
Scopul nu este să strângi cât mai multe fișiere, ci să arăți că poți identifica elementele esențiale ale unui eveniment: momentul, sursa, destinația, utilizatorul, tipul acțiunii și rezultatul. Exact aici începe munca de Security Data Engineering.
Cum definești schema comună
Partea cea mai importantă nu este parserul în sine, ci modelul de date pe care îl alegi. O schemă minimă și utilă poate include câmpuri precum timestamp, source.ip, destination.ip, user.name, host.name, event.action, event.category și event.outcome. Dacă păstrezi și logul original, ai un avantaj mare pentru trasabilitate și debugging. OpenTelemetry documentează explicit atributul log.record.original pentru păstrarea reprezentării originale a jurnalului, ceea ce susține această practică.
Aici trebuie să fii foarte clar în documentație. Explică de ce un anumit câmp ajunge în event.action și nu în event.category, cum tratezi valorile lipsă și ce faci atunci când două surse exprimă aceeași activitate în termeni diferiți. Un proiect bun nu ascunde ambiguitățile, ci le notează și le tratează coerent.
Cum verifici calitatea datelor
Un portofoliu matur nu se oprește la „am mapat logurile”. Arată și cum verifici dacă datele rezultate sunt utile. NIST, în ghidul său despre log management, tratează colectarea și gestionarea corectă a logurilor ca parte esențială a operațiunilor de securitate. În proiectul tău, asta se poate traduce în câteva controale simple: verifici dacă toate evenimentele au timestamp valid, măsori câte înregistrări nu au user.name, marchezi câmpurile pe care nu le poți mapa fără ambiguitate și păstrezi logul brut pentru audit.
Aceste verificări spun mult la interviu. Arată că nu vezi pipeline-ul doar ca transport de date, ci ca proces care trebuie să producă date coerente și reutilizabile.
Ce livrezi în portofoliu
Livrabilul ideal este simplu și verificabil: un README clar, un set mic de date anonimizate, codul de parsare și mapare și câteva exemple de interogări sau vizualizări pe schema comună. Nu este nevoie să promiți funcții pe care proiectul nu le are. Dacă nu ai construit detecții avansate, nu le menționa. Este mai convingător să arăți bine fundația: structură, consistență, documentare și limitări explicate onest.
Poți menționa și că schema ta este inspirată din OCSF, ECS sau ASIM, fără să pretinzi că ai implementat complet una dintre aceste specificații. O versiune redusă, dar bine argumentată, este suficientă pentru un proiect de portofoliu serios.
Cum explici proiectul la interviu
La interviu, proiectul devine valoros când îl poți prezenta ca pe o problemă de date, nu ca pe un simplu script. Poți vorbi despre diferențele dintre surse, despre deciziile de mapare, despre compromisurile dintre normalizare la ingestie și normalizare la interogare, temă discutată și în documentația Microsoft pentru ASIM. În plus, poți arăta cum o schemă comună face mai ușoare interogările, investigațiile și reutilizarea logicii de detecție.
Pentru un rol de Security Data Engineer, exact acest tip de proiect transmite cel mai bine că înțelegi baza tehnică a securității moderne: înainte de alerte bune și investigații rapide, ai nevoie de date comparabile, coerente și bine documentate.
