01 - Inginerie de detectare: de la disciplină la script la conductă
Într-un peisaj de amenințări cibernetice în continuă evoluție, capacitatea de a detecta activitatea rău intenționată înainte de a provoca daune semnificative reprezintă adevărata diferență între o organizație rezistentă și una vulnerabilă. De zeci de ani, detectarea amenințărilor a fost încredințate regulilor scrise ad-hoc, semnăturilor antivirus și intuițiilor individuale ale analiștilor SOC. Astăzi, această abordare artizanală nu mai este durabilă: volumul de bușteni, complexitatea Infrastructurile native din cloud și sofisticarea atacatorilor necesită o abordare inginerie şi sistematică.
Așa s-a născut Inginerie de detectare: o disciplină care aplică principii de inginerie software la procesul de creare, testare, implementare și întreținere a software-ului reguli de detectare. Nu mai este vorba de a scrie interogări izolate într-un SIEM, ci de a construi conducte automate, versiunea detecțiilor ca cod, testați-le cu date simulați și măsurați-le cu metrici obiective.
Ce veți învăța în acest articol
- Ce este Ingineria Detectării și de ce a devenit o disciplină autonomă
- Evoluția de la scripturi ad-hoc la conducte CI/CD pentru detectare
- Ciclul de viață complet al unei detecții: ipoteză, dezvoltare, testare, implementare, reglare
- Principalele tipuri de detecție: bazată pe semnătură, comportamentală, bazată pe anomalii
- Valori de calitate: Rata pozitivă adevărată, Rata pozitivă falsă, MTTD, MTTR
- Ecosistemul SIEM/SOAR și sursele cheie de date
- Conceptul de conducte Detection-as-Code și CI/CD pentru regulile de securitate
- Exemple practice cu reguli Sigma, scripturi Python și configurații YAML
Ce este ingineria detectării
La Inginerie de detectare și procesul sistematic de proiectare, dezvoltare, testarea și întreținerea logicii care identifică activitățile rău intenționate în cadrul telemetriei a unei organizatii. Această telemetrie include jurnalele de la punctele finale, infrastructura cloud, furnizori de identitate, aplicații web, sisteme de rețea și multe altele.
Spre deosebire de abordarea tradițională, în care un analist SOC a scris o interogare în SIEM ca răspuns la un incident specific, Detection Engineering adoptă a fluxul de lucru structurat amintește de dezvoltarea software-ului modern: versiunea codului, revizuirea codului, testare automată, implementare continuă și monitorizare a performanței în producție.
„Detection Engineering este pentru SOC ceea ce Software Engineering este pentru codificare: transformă un ad-hoc, activitate reactivă într-o disciplină sistematică, măsurabilă și în continuă îmbunătățire.”
- SANS Institute, 2025 Detection Engineering Survey
Cei trei piloni ai ingineriei detectării
Disciplina se bazează pe trei piloni interconectați care îi definesc maturitatea:
- Inteligența amenințărilor - Înțelegeți cine sunt adversarii, ce tehnici folosesc (MITRE ATT&CK) și ce active ale organizației sunt expuse riscului. Fără o înțelegere adâncimea amenințărilor, detecțiile vor fi generice și nu foarte eficiente.
- Ingineria datelor - Asigurați-vă că jurnalele necesare sunt colectate, normalizate și disponibil pentru analiză. O detecție perfectă și inutilă dacă datele pe care operează nu sunt prezente sau sunt de proastă calitate.
- Inginerie software - Aplicați cele mai bune practici de dezvoltare software: control versiuni, testare, CI/CD, documentație, metrici. Detectările trebuie tratate ca cod de producție.
Evoluția: de la scripturi ad-hoc la disciplina inginerească
Calea care a condus la ingineria modernă de detectare poate fi împărțită în patru faze distincte, fiecare caracterizată printr-un nivel crescând de maturitate și automatizare.
Faza 1: Era semnăturilor (1990-2005)
Formele timpurii de detectare s-au bazat pe semnături statice: modele cunoscute de malware, hash-uri de fișiere rău intenționate, șiruri specifice în încărcăturile utile de rețea. Fiecare antivirus și IDS (Intrusion Detection System) a menținut o bază de date de semnături care a fost actualizată periodic. Abordarea a funcționat destul de bine cu amenințările cunoscute, dar a fost complet nevăzută la noi variante sau atacuri personalizate.
Faza 2: Era scripturilor SIEM (2005-2015)
Odată cu răspândirea celui dintâi SIEM (Informații de securitate și management al evenimentelor), analiștii au început să scrie interogări și corelații personalizate. Fiecare analist avea propria abordare, propriile scripturi, propriile convenții de denumire. Au fost create reguli direct în interfața web SIEM, fără versiuni, fără testare, fără documentație standardizate. Când un analist a părăsit organizația, detecțiile sale deveneau adesea de neînțeles pentru succesori.
Faza 3: Nașterea ingineriei de detectare (2015-2022)
Între 2015 și 2022, comunitatea de securitate începe să recunoască nevoia de a abordare mai structurată. Se nasc formate standard precum Sigma (2017) pentru regulile de detectare, cadrul MITRE ATT&CK devine referinta universale pentru cartografierea tehnicilor adversarilor și primele echipe de detectare dedicate Ingineria apare în organizațiile mai mature.
Faza 4: Detectare ca cod și conductă CI/CD (2022-prezent)
Astăzi, cele mai avansate organizații tratează detecțiile exact ca codul software. Regulile sunt scrise în formate declarative (Sigma, YAML), versionate în depozite Git, testat automat cu date simulate, implementat prin conducta CI/CD și monitorizat cu tablouri de bord dedicate. Potrivit SANS 2025 Detection Engineering Survey, 60% dintre organizații mențin echipe dedicate de inginerie de detectare, cu 70% a întreprinderilor cu peste 5.000 de angajați care și-au constituit deja echipe structurate.
| Fază | Perioadă | Abordare | Instrumente | Limite |
|---|---|---|---|---|
| Semnături statice | 1990-2005 | Potrivirea modelului pe semnăturile cunoscute | Antivirus, IDS (Snort) | Zile zero invizibile, latență mare |
| Scripturi SIEM | 2005-2015 | Interogări ad-hoc în SIEM | Splunk, ArcSight, QRadar | Unversioned, netestat, cunoștințe izolate |
| Inginerie de detectare | 2015-2022 | Flux de lucru structurat cu standarde | Sigma, ATT&CK, ELK | Încă o mulțime de procese manuale |
| Detectare ca cod | 2022-prezent | Conducta CI/CD, toate versiuni | Git, CI/CD, Sigma, SOAR | Necesită maturitate organizațională |
Ciclul de viață al unei detectări
Fiecare detecție urmează un ciclu de viață bine definit, care garantează calitatea, eficacitatea și mentenabilitatea în timp. Ciclul constă din șase faze fundamentale, fiecare cu livrabile și criterii specifice de calitate.
1. Ipoteza (Ipoteza)
Totul începe cu unul ipoteza amenințării. Analistul sau inginerul de detectare identifică o tehnică specifică de atac (de exemplu, „Un atacator ar putea folosi PowerShell pentru a descărca și a executa încărcături utile rău intenționate") și formulați o ipoteză despre cum această activitate s-ar manifesta în jurnalele disponibile. Sursele pentru ipoteze includ:
- Inteligența amenințărilor - Raport privind campaniile active, TTP-urile observate
- MITRE ATT&CK - Tehnici adaptate unor tactici specifice
- Accident post-mortem - Lecții învățate din incidentele anterioare
- Descoperirile echipei Roșii - Rezultatele testelor de penetrare și teaming violet
- Analiza decalajului - Tehnici ATT&CK fără acoperire de detecție
2. Dezvoltare (dezvoltare)
Cu ipoteza definită, inginerul de detectare scrie regula de detectare. Aceasta presupune alegerea formatului (Sigma, interogare nativă SIEM, script Python), definiția a jurnalelor surse necesare, a logicii de selecție și filtrare și a documentației metadate (autor, severitate, mapare ATT&CK, false pozitive cunoscute).
3. Testare și validare (testare)
Înainte de implementare, detectarea trebuie validată în raport cu date reale și simulate. Testarea include: test adevărat pozitiv (regula detectează atacul simulat?), testare fals pozitivă (regula generează alerte privind activitățile legitime?), e testarea performanței (regula este suficient de eficientă asupra volumelor de jurnal de producție?).
4. Desfăşurare
Implementarea are loc prin conducte automate care convertesc regula în format nativ pentru SIEM țintă, implementați-l în mediul de producție și verificați corectitudinea acestuia operare. În mediile mature, acest proces este complet automatizat prin CI/CD.
5. Monitorizare și metrici
Odată în producție, detecția este monitorizată constant. Valorile cheie includ volumul alertelor generate, raportul adevărat/fals pozitiv, timpul mediu detecție (MTTD) și impactul asupra sarcinii analiștilor SOC.
6. Tuning și întreținere
Pe baza datelor colectate în producție, detecția este perfecționată continuu. The reglarea poate include adăugarea de excepții pentru false pozitive recurente, extinderea de logica pentru a acoperi variatii ale tehnicii, sau deprecierea regulii daca nu mai mult relevante.
Cea mai bună practică: Purple Teaming
Il echipă violet accelerează semnificativ bucla de feedback de ciclul de viață de detectare. Combinând abilitățile ofensive ale echipei Roșii cu cele defensive al Echipei Albastre, este posibil să se simuleze tehnici reale de atac și să se valideze detecțiile în timp real, reducând timpul dintre ipoteză și detectarea validată de la săptămâni la ore.
Tipuri de detectare: de la IOC la Comportament
Detectările pot fi clasificate în funcție de logica de detectare utilizată. Fiecare tip are avantaje și limitări specifice, iar un program matur de detectare le combină totul într-un mod stratificat.
1. Detectare bazată pe semnătură
Căutări de detectare pe bază de semnătură modele exacte în date: fișier hash șiruri de caractere cunoscute, specifice în comenzi, adrese IP sau domenii malițioase cunoscute (IOC - Indicators de compromis). Este cel mai simplu și mai rapid tip, cu o rată de fals pozitive foarte scăzută, dar complet ineficiente împotriva amenințărilor noi sau variante.
title: Emotet Loader Hash Detection
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects known Emotet loader by file hash
author: Detection Engineering Team
date: 2025/10/15
references:
- https://attack.mitre.org/software/S0367/
logsource:
category: file_event
product: windows
detection:
selection:
Hashes|contains:
- 'SHA256=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
- 'SHA256=a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a'
- 'MD5=d41d8cd98f00b204e9800998ecf8427e'
condition: selection
falsepositives:
- Unlikely, known malicious hashes
level: critical
tags:
- attack.execution
- attack.t1204.0022. Detectarea comportamentală
Se caută detectii comportamentale secvențe de acțiuni sau model de comportamente care indică activitate suspectă, indiferent de IOC-urile specifice. De exemplu, în loc să cauți un anumit hash de Mimikatz, o detecție comportamentală ar putea căuta orice proces care accesează memoria LSASS pentru a extrage acreditările. Această abordare este mult mai rezistentă la evaziune, deoarece atacatorii se pot schimba propriile lor instrumente, dar cu greu pot schimba tehnica de bază.
title: Suspicious LSASS Process Access - Credential Dumping
id: b2c3d4e5-f6a7-8901-bcde-f12345678901
status: experimental
description: |
Detects process access to LSASS memory, a common technique
for credential dumping (T1003.001). Focuses on behavior
rather than specific tool signatures.
author: Federico Calo
date: 2025/11/20
references:
- https://attack.mitre.org/techniques/T1003/001/
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010' # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
- '0x1038' # Read memory access
- '0x1FFFFF' # PROCESS_ALL_ACCESS
filter_legitimate:
SourceImage|endswith:
- '\MsMpEng.exe' # Windows Defender
- '\csrss.exe' # Client Server Runtime
- '\wmiprvse.exe' # WMI Provider
- '\svchost.exe' # Service Host
filter_system:
SourceUser|contains: 'SYSTEM'
SourceImage|startswith: 'C:\Windows\System32\'
condition: selection and not filter_legitimate and not filter_system
falsepositives:
- Legitimate security tools performing memory scanning
- EDR solutions with high-privilege access
level: high
tags:
- attack.credential_access
- attack.t1003.0013. Detectare bazată pe anomalii
Detectările bazate pe anomalii stabilesc a linia de bază a normalității e raportează abateri semnificative. De exemplu, dacă un utilizator se conectează de obicei de la un cu sediul în Italia în timpul orelor de lucru, ar fi o autentificare din China la ora 3 dimineața o anomalie. Această abordare poate detecta amenințări complet necunoscute (de zi zero), dar tinde să genereze mai multe fals pozitive, mai ales în medii dinamice.
4. Vânătoarea de amenințări
Vânătoarea de amenințări este un proces proactiv și bazat pe ipoteze în care cel analiștii caută în mod activ amenințările care ar fi putut scăpa de detectarea automată. Spre deosebire de detectarea automată, vânătoarea de amenințări este exploratorie și adesea produce noi detectii care sunt apoi codificate si automatizate.
| Tip de detectare | Precizie | Acoperire Zero Day | False pozitive | Întreţinere | Exemplu |
|---|---|---|---|---|---|
| Bazat pe semnătură | Foarte sus | Nici unul | Foarte scăzut | Ridicat (actualizare IOC) | Fișiere hash, IP-uri rău intenționate |
| Comportamental | Ridicat | Bun | Moderați | Medie | Acces LSASS, mișcare laterală |
| Bazat pe anomalii | Variabilă | Excelent | Ridicat | Ridicat (reglare de bază) | Conectare anormală, trafic neobișnuit |
| Vânătoarea de amenințări | Foarte sus | Excelent | Minimum (manual) | Ridicat (necesită analiști) | Analiza exploratorie, ipoteze |
Valori de calitate pentru detectii
O detectare nu este utilă dacă nu este măsurabile. Valori de calitate vă permit să evaluați eficacitatea regulilor de detectare, să ghidați procesul reglarea și justificarea investițiilor în programul Inginerie Detectie.
Metrici operaționale fundamentale
| Metric | Descriere | Ţintă | Cum să îmbunătățești |
|---|---|---|---|
| MTTD (Timp mediu de detectare) | Timp mediu de la momentul activității rău intenționate până la generarea alertei | < 4 ore (echipa de top: < 30 min) | Acoperire mai bună a jurnalului, detectare în timp real |
| MTTR (Timp mediu pentru a răspunde) | Timp mediu de la detectare până la izolare/rezolvare | < 4 ore | Automatizare SOAR, manuale definite |
| Adevărata rata pozitivă (TPR) | Procentul de alerte care corespund amenințărilor reale | > 80% pentru critic, > 60% pentru ridicat | Reglare continuă, filtrare avansată |
| Rata fals pozitivă (FPR) | Procentul de alerte generate pentru activități legitime | < 25% pentru critici | Lista albă, context îmbogățit, corelație |
| Rata fals negative (FNR) | Procentul de amenințări reale nedetectate | < 1% | Echipa violet, vânătoare de amenințări |
| Acoperire ATT&CK | Procentul de tehnici MITRE ATT&CK acoperite de cel puțin o detectare | > 70% din tehnicile relevante | Analiză regulată a decalajelor, prioritizare |
Calculul scorului de detectare
O abordare practică pentru a evalua calitatea generală a programului de detectare și a Scorul de maturitate de detectare, care combină mai multe valori într-un singur scor normalizat. Iată un exemplu de calcul în Python:
from dataclasses import dataclass
from typing import List
@dataclass(frozen=True)
class DetectionMetrics:
"""Immutable snapshot of detection performance metrics."""
rule_id: str
true_positives: int
false_positives: int
false_negatives: int
total_alerts: int
avg_detection_time_minutes: float # MTTD
avg_response_time_minutes: float # MTTR
@property
def precision(self) -> float:
"""TP / (TP + FP) - How many alerts are real threats."""
denominator = self.true_positives + self.false_positives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def recall(self) -> float:
"""TP / (TP + FN) - How many real threats are caught."""
denominator = self.true_positives + self.false_negatives
return self.true_positives / denominator if denominator > 0 else 0.0
@property
def f1_score(self) -> float:
"""Harmonic mean of precision and recall."""
p, r = self.precision, self.recall
return 2 * (p * r) / (p + r) if (p + r) > 0 else 0.0
def calculate_maturity_score(metrics_list: List[DetectionMetrics]) -> dict:
"""Calculate overall detection program maturity score.
Returns an immutable dict with aggregated metrics.
"""
if not metrics_list:
return {"score": 0, "grade": "F", "details": {}}
avg_precision = sum(m.precision for m in metrics_list) / len(metrics_list)
avg_recall = sum(m.recall for m in metrics_list) / len(metrics_list)
avg_f1 = sum(m.f1_score for m in metrics_list) / len(metrics_list)
avg_mttd = sum(m.avg_detection_time_minutes for m in metrics_list) / len(metrics_list)
avg_mttr = sum(m.avg_response_time_minutes for m in metrics_list) / len(metrics_list)
# Weighted maturity score (0-100)
precision_score = avg_precision * 25 # 25% weight
recall_score = avg_recall * 25 # 25% weight
f1_component = avg_f1 * 20 # 20% weight
mttd_score = max(0, (240 - avg_mttd) / 240) * 15 # 15% weight (240min = 4h target)
mttr_score = max(0, (240 - avg_mttr) / 240) * 15 # 15% weight
total_score = (precision_score + recall_score + f1_component
+ mttd_score + mttr_score) * 100
grade_thresholds = [
(90, "A"), (80, "B"), (70, "C"), (60, "D")
]
grade = next(
(g for threshold, g in grade_thresholds if total_score >= threshold),
"F"
)
return {
"score": round(total_score, 1),
"grade": grade,
"details": {
"avg_precision": round(avg_precision, 3),
"avg_recall": round(avg_recall, 3),
"avg_f1": round(avg_f1, 3),
"avg_mttd_minutes": round(avg_mttd, 1),
"avg_mttr_minutes": round(avg_mttr, 1),
"total_rules_evaluated": len(metrics_list),
},
}
# Esempio di utilizzo
sample_metrics = [
DetectionMetrics("SIGMA-001", 45, 5, 2, 50, 15.0, 35.0),
DetectionMetrics("SIGMA-002", 120, 30, 8, 150, 8.5, 22.0),
DetectionMetrics("SIGMA-003", 200, 15, 5, 215, 3.2, 12.0),
]
result = calculate_maturity_score(sample_metrics)
print(f"Detection Maturity Score: {result['score']} ({result['grade']})")
print(f"Details: {result['details']}")Atenție: Vanity Metrics
Evitați măsurarea succesului programului dvs. de detectare cu ajutorul număr total a regulilor sau cel numărul de alerte generate. Acestea sunt metrici valori de vanitate care pot masca probleme serioase. O organizație cu 50 detecție de înaltă fidelitate și mult mai sigură decât una cu 5.000 de reguli care generează mii de fals pozitive, provocând oboseală alertă în rândul analiștilor.
Ecosistemul SIEM/SOAR
Il SIEM (Informații de securitate și management al evenimentelor) și inima a infrastructurii de inginerie de detectare. Și platforma care colectează, normalizează, corelează și analizează jurnalele din toate sursele din organizație. The AVÂNTA (Security Orchestration, Automation and Response) completează SIEM automatizarea răspunsurilor la alerte prin intermediul unor manuale predefinite.
Prezentare generală a principalelor platforme SIEM
| Platformă | Tip | Limbajul de interogare | Puncte forte | Caz de utilizare ideal |
|---|---|---|---|---|
| Splunk Enterprise | On-Prem / Cloud | SPL | Maturitate, ecosistem de aplicații, flexibilitate | Întreprinderi complexe, SOC mature |
| SIEM elastic | Open Source / Cloud | KQL / EQL / ES|QL | Open source, scalabilitate, cost | Echipe cu buget redus, native din cloud |
| Microsoft Sentinel | Cloud (Azure) | KQL | Integrare Azure/M365, AI încorporat | Organizații centrate pe Microsoft |
| Google SecOps (Cronică) | Cloud (GCP) | YARA-L | Retenție nelimitată, viteză | Volume mari de date, GCP |
| CrowdStrike Falcon LogScale | Nor | Interogare LogScale | Ingestie rapidă, compresie | Organizații CrowdStrike |
| Logica sumo | Nor | Sumo Logic Interogare | SaaS nativ, ușurință în utilizare | Cloud-first, SaaS-heavy |
Surse fundamentale de date
Calitatea detecțiilor depinde direct de calitatea și caracterul complet al datelor disponibile. Iată sursele fundamentale de date pentru un program eficient de detectare:
- Telemetria punctului final - Jurnalele de proces, evenimentele sistemului de fișiere, modificările de registry, conexiuni de rețea. Surse: EDR (CrowdStrike, SentinelOne, Microsoft Defender), Sysmon
- Telemetria rețelei - NetFlow, interogări DNS, metadate HTTP/TLS, PCAP selectiv. Surse: firewall, IDS/IPS, proxy, rezolutor DNS
- Identitate și acces - Evenimente de autentificare, escaladare a privilegiilor, se modifică apartenența la grup. Surse: Active Directory, Entra ID, Okta, CyberArk
- Jurnalele de audit în cloud - Apeluri API, modificări de configurare, creare de resurse. Surse: AWS CloudTrail, jurnal de activitate Azure, jurnal de audit GCP
- Jurnalele aplicației - Jurnalele de acces la serverul web, erorile aplicației, evenimentele WAF. Surse: Nginx, Apache, CloudFront, aplicații personalizate
- Securitate e-mail - Tentative de phishing, atașamente rău intenționate, detecție BEC. Surse: Microsoft Defender pentru O365, Proofpoint, Mimecast
Normalizarea datelor: Fundația Invizibilă
Fără normalizarea datelor, detectiile sunt fragile si nu portabile.
Fiecare SIEM și fiecare sursă utilizează formate diferite pentru aceleași concepte: o „eșec de conectare”
poate arata ca EventID 4625 pe Windows, sshd: Failed password
în Linux, sau {"eventType": "user.session.start", "outcome": "FAILURE"}
în Okta. Adoptă o schemă de normalizare precum ECS (Elastic Common Schema),
OCSF (Open Cybersecurity Schema Framework) sau modelul de date Sigma permite
pentru a scrie detecția o singură dată și a o aplica pe orice sursă.
Detectarea ca cod: paradigma modernă
Detectare ca cod (DaC) și abordarea care aplică practicile de dezvoltare software pentru gestionarea regulilor de detectare. În loc să creezi și să modifici reguli prin interfața grafică SIEM, detecțiile sunt scrise ca cod, versionate în depozitele Git, supuse revizuirii codului prin solicitări de extragere, testate automat și livrate prin conducte CI/CD.
Avantajele Detection-as-Code
Comparativ cu abordarea tradițională
- Versiune - Fiecare modificare este urmărită în Git, cu posibilitatea de rollback
- Revizuirea codului - Detectările sunt supuse unei evaluări inter pares înainte de implementare
- Teste automate - Validare automată cu date pozitive și negative
- Reproductibilitatea - Întreaga stare a detecțiilor poate fi reconstruită din depozit
Beneficii operaționale
- Viteză - Detectările intră în producție în minute, nu în zile
- Consecvență - Standardele de calitate aplicate uniform
- Pista de audit - Trasabilitate completă pentru conformitate
- Colaborare - Mai multe echipe pot contribui la același depozit
Structura unui depozit de detectare ca cod
detections/
rules/
credential_access/
lsass_memory_access.yml
brute_force_login.yml
kerberoasting.yml
execution/
powershell_encoded_command.yml
suspicious_wmi_execution.yml
lateral_movement/
psexec_usage.yml
rdp_from_unusual_source.yml
persistence/
scheduled_task_creation.yml
registry_run_key.yml
tests/
credential_access/
lsass_memory_access_test.json
brute_force_login_test.json
execution/
powershell_encoded_command_test.json
config/
sigma_config.yml
siem_mappings.yml
exclusions.yml
pipelines/
ci.yml
cd.yml
docs/
CONTRIBUTING.md
STYLE_GUIDE.md
REVIEW_CHECKLIST.md
README.mdConducta CI/CD pentru detectii
Conducta de detectare CI/CD automatizează întregul proces de la comitere la producție. Iată un exemplu de configurare pentru GitHub Actions:
name: Detection CI/CD Pipeline
on:
pull_request:
paths: ['rules/**', 'tests/**']
push:
branches: [main]
paths: ['rules/**']
jobs:
validate:
name: Validate Sigma Rules
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install sigma-cli
run: pip install sigma-cli pySigma-backend-splunk pySigma-backend-elasticsearch
- name: Lint Sigma Rules
run: |
sigma check rules/ --validation-config config/sigma_config.yml
echo "All rules pass validation"
- name: Verify ATT&CK Mapping
run: |
python scripts/verify_attack_tags.py rules/
echo "All rules have valid ATT&CK mappings"
test:
name: Test Detection Logic
needs: validate
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run True Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type true_positive
- name: Run False Positive Tests
run: |
python scripts/run_tests.py \
--rules-dir rules/ \
--tests-dir tests/ \
--test-type false_positive
- name: Generate Coverage Report
run: python scripts/coverage_report.py --output reports/coverage.json
deploy:
name: Deploy to SIEM
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- name: Convert Sigma to Splunk SPL
run: |
sigma convert \
--target splunk \
--pipeline splunk_windows \
rules/ \
--output converted/splunk/
- name: Deploy to Splunk via API
env:
SPLUNK_TOKEN: ${{ secrets.SPLUNK_API_TOKEN }}
SPLUNK_URL: ${{ secrets.SPLUNK_URL }}
run: |
python scripts/deploy_splunk.py \
--rules-dir converted/splunk/ \
--splunk-url "$SPLUNK_URL" \
--token "$SPLUNK_TOKEN"
- name: Update ATT&CK Coverage Map
run: python scripts/update_attack_coverage.pyFluxul complet de detectare ca cod
- Inginerul de detectare creează o nouă regulă Sigma într-o ramură Git
- Deschide o cerere de tragere cu regula și testele aferente
- Conducta CI realizează validarea sintactică, testarea TP/FP și verificarea cartografierii ATT&CK
- Un evaluator peer aprobă PR după verificarea logicii, a documentației și a acoperirii
- Fuzionarea în principal activează conducta CD care convertește regula și o distribuie către SIEM
- Tablourile de monitorizare urmăresc performanța de detectare în producție
Scrierea detecțiilor eficiente: principii și modele
Diferența dintre o detecție mediocră și una excelentă constă în profunzimea detectării înțelegerea tehnicii de atac, în calitatea filtrării fals pozitive și în caracterul complet al documentației. Iată principiile de bază.
Principiul 1: Începeți cu tehnica, nu cu instrumentul
Nu scrieți o detecție pentru „Mimikatz” - scrieți o detecție pentru tehnică di descărcarea acreditărilor prin accesul la memorie LSASS (T1003.001). Această abordare o acoperă automat toate instrumentele care implementează aceeași tehnică, inclusiv acelea viitor necunoscut încă.
Principiul 2: Detectarea stratului (piramida de detectare)
Implementați detectarea pe mai multe niveluri pentru aceeași tehnică. O detectare bazată pe hash (trivial de evitat) poate încă captura atacatori nesofisticați, în timp ce a Detectarea comportamentală le surprinde pe cele mai avansate. Această abordare stratificată și cunoscut ca Detectare în profunzime.
Principiul 3: Documentați întotdeauna contextul
Fiecare detecție trebuie să includă: motivare (de ce această detectare există), cel Cartografiere ATT&CK (ce tehnică acoperă), i fals pozitive cunoscute (care activități legitime pot declanșa regula) și manual de răspunsuri (ce trebuie să facă analistul atunci când detectia este declanșată).
Exemplu complet: Detectare cu Log Analysis Python
"""
Brute Force Detection Module
MITRE ATT&CK: T1110.001 - Brute Force: Password Guessing
Detects multiple failed login attempts followed by a success.
"""
from dataclasses import dataclass, field
from datetime import datetime, timedelta
from collections import defaultdict
from typing import Optional
@dataclass(frozen=True)
class LoginEvent:
"""Immutable representation of a login event."""
timestamp: datetime
username: str
source_ip: str
success: bool
service: str # 'ssh', 'rdp', 'web', 'vpn'
@dataclass(frozen=True)
class BruteForceAlert:
"""Immutable alert generated by the detector."""
username: str
source_ip: str
failed_count: int
time_window_minutes: int
first_attempt: datetime
last_attempt: datetime
successful_login: bool
severity: str # 'medium', 'high', 'critical'
mitre_technique: str = "T1110.001"
@dataclass(frozen=True)
class DetectionConfig:
"""Immutable configuration for brute force detection."""
failed_threshold: int = 5
time_window_minutes: int = 10
lockout_threshold: int = 20
whitelist_ips: tuple = ()
monitored_services: tuple = ('ssh', 'rdp', 'web', 'vpn')
class BruteForceDetector:
"""Stateless brute force detection engine.
Analyzes login events and produces alerts when
brute force patterns are detected.
"""
def __init__(self, config: Optional[DetectionConfig] = None):
self._config = config or DetectionConfig()
def analyze(self, events: list[LoginEvent]) -> list[BruteForceAlert]:
"""Analyze a batch of login events for brute force patterns.
Returns a new list of alerts (no mutation of input).
"""
# Group events by (source_ip, username)
grouped = defaultdict(list)
for event in events:
if (event.service in self._config.monitored_services
and event.source_ip not in self._config.whitelist_ips):
key = (event.source_ip, event.username)
grouped[key].append(event)
alerts = []
for (source_ip, username), user_events in grouped.items():
sorted_events = sorted(user_events, key=lambda e: e.timestamp)
alert = self._check_brute_force(source_ip, username, sorted_events)
if alert is not None:
alerts.append(alert)
return alerts
def _check_brute_force(
self, source_ip: str, username: str, events: list[LoginEvent]
) -> Optional[BruteForceAlert]:
"""Check if events match a brute force pattern."""
window = timedelta(minutes=self._config.time_window_minutes)
failed_events = [e for e in events if not e.success]
if len(failed_events) < self._config.failed_threshold:
return None
# Check if failures cluster within the time window
for i, start_event in enumerate(failed_events):
window_end = start_event.timestamp + window
window_failures = [
e for e in failed_events[i:]
if e.timestamp <= window_end
]
if len(window_failures) >= self._config.failed_threshold:
# Check for subsequent successful login
success_after = any(
e.success and e.timestamp >= start_event.timestamp
for e in events
)
severity = self._calculate_severity(
len(window_failures), success_after
)
return BruteForceAlert(
username=username,
source_ip=source_ip,
failed_count=len(window_failures),
time_window_minutes=self._config.time_window_minutes,
first_attempt=window_failures[0].timestamp,
last_attempt=window_failures[-1].timestamp,
successful_login=success_after,
severity=severity,
)
return None
def _calculate_severity(self, failed_count: int, success: bool) -> str:
"""Determine alert severity based on pattern characteristics."""
if success and failed_count >= self._config.lockout_threshold:
return "critical" # Many failures + success = likely compromised
if success:
return "high" # Fewer failures + success = suspicious
if failed_count >= self._config.lockout_threshold:
return "high" # Many failures = active attack
return "medium" # Moderate failures = possible attackMITRE ATT&CK: Cadrul de Referință
Cadrul MITRE ATT&CK (Tactici adverse, tehnici și comun Cunoștințe) și referința universală pentru cartografierea și clasificarea tehnicilor adversarilor. Pentru Detection Engineering, ATT&CK oferă un limbaj comun de descris Ce căutăm și o matrice pentru a măsura acoperire ale noastre detectarea.
Cum să utilizați ATT&CK pentru inginerie de detectare
- Prioritizare - Nu toate tehnicile ATT&CK sunt create egale relevante pentru organizația dvs. Identificați tehnicile cele mai utilizate de adversari în sectorul dvs. (informații privind amenințările) și concentrați resursele asupra acestora.
- Analiza decalajului - Harta detectiile existente pe tehnici ATT&CK pentru a vizualiza zonele neacoperite. Utilizați Navigator ATT&CK pentru creați hărți termice care arată acoperirea curentă.
-
Etichetarea - Fiecare regulă Sigma și de detectare trebuie să includă etichete ATT&CK
corespunzătoare (de ex.
attack.t1003.001). Acest lucru vă permite să agregați metrici pentru tehnică și tactică. - Măsurare - Urmăriți procentul de tehnici acoperite pentru fiecare tactică (Acces inițial, Execuție, Persistență etc.) și definiți obiective realiste de acoperire.
| Tactici | Exemple de tehnici | Surse cheie de date | Detectarea dificultăților |
|---|---|---|---|
| Acces inițial | T1566 Phishing, T1190 Exploit Public App | E-mail, WAF, proxy | Medie |
| Execuţie | T1059 Command-Line, T1204 User Execution | Sysmon, EDR, jurnalele de proces | Scăzut-Mediu |
| Persistenţă | T1053 Sarcină programată, T1547 Boot Autostart | Registrul, sistemul de fișiere, EDR | Medie |
| Escaladarea privilegiilor | T1068 Exploatarea, T1078 Conturi valide | EDR, jurnale AD, audit în cloud | Ridicat |
| Evaziunea apărării | T1070 Îndepărtarea indicatorului, T1027 Obscurcare | EDR, Sysmon, AMSI | Foarte sus |
| Acces la acreditări | T1003 OS Credential Dumping, T1110 Brute Force | Jurnalele EDR, AD, jurnalele de autentificare | Medie |
| Mișcarea laterală | Servicii de la distanță T1021, Transfer lateral de scule T1570 | Rețea, jurnale AD, EDR | Ridicat |
| Exfiltrarea | T1048 Exfiltration Over Alt Protocol, T1567 Web Service | DLP, proxy, DNS, NetFlow | Foarte sus |
Structura și rolurile echipei
Un program eficient de inginerie de detectare necesită o combinație de abilități care se întâlnesc rar la o singură persoană. Structura echipei variază în funcție de dimensiunea organizației, dar rolurile cheie sunt bine definite.
Roluri cheie
- Inginer detectie - Rolul central. Scrie, testează și menține regulile de detectare. Necesită abilități în inteligența amenințărilor, limbaje de interogare SIEM, scripting (Python) și familiaritatea cu jurnalele platformei țintă. Conform sondajului SANS 2025, 60% dintre organizații au cel puțin un inginer de detectare dedicat.
- Analist de informații despre amenințări - Oferă context asupra amenințărilor: care sunt Grupurile APT sunt active, ce tehnici folosesc, ce indicatori să caute. Îi hrănește ipoteza de detecție cu inteligență acționabilă.
- Data Engineer / Log Architect - Se ocupa de calitate si disponibilitate de date: integrarea de noi surse de jurnal, normalizare, analizare și gestionare a infrastructurii de colectare.
- Analist SOC - Utilizatorul final al detectărilor. Oferă feedback fundamental pentru calitatea alertelor: prea multe fals pozitive? Alerta nu poate fi acționată? Lipsesc informații de context?
- Echipa Rosie / Echipa Violet - Simulați tehnicile adversarilor pentru a valida detectiile. Feedback-ul echipei roșii este cel mai eficient mecanism de îmbunătățire acoperire și fidelitate față de reguli.
Organizare pentru echipe mici
Nu orice organizație își poate permite o echipă dedicată de inginerie de detectare. Pentru echipele de securitate mai mici (3-5 persoane), abordarea recomandată este:
- Atribuiți 20-30% din timp a analiștilor SOC de la Detection Engineering
- Adopta Regulile comunității Sigma ca linie de referință (depozitul SigmaHQ)
- Implementați a proces de feedback structurat din triajul alert
- Utilizare Detectare ca cod chiar și cu conducte simple (Git + script de implementare)
- Se concentreze pe 10-15 cele mai relevante tehnici ATT&CK pentru sectorul dvs
Caz real: de la accident la conducta de detectare
Pentru a concretiza conceptele discutate, să vedem un exemplu realist de ilustrat întregul drum de la descoperirea unui gol până la detectarea în producție.
Scenariu: compromis prin comanda codificată PowerShell
În timpul unui exercițiu de echipă violet, Echipa Roșie reușește să execute o sarcină utilă rău intenționată
folosind PowerShell cu o comandă codificată Base64 (-EncodedCommand).
Atacul nu este detectat de detectările existente deoarece au fost doar în căutare
șiruri specifice de comenzi PowerShell cunoscute, nu modelul de codificare generic.
Pasul 1: Ipoteza si Analiza
Inginerul de detectare formulează ipoteza: „Orice utilizare a PowerShell
-EncodedCommand într-un mediu de întreprindere ar trebui să fie considerat suspect, deoarece
Software-ul legitim are rareori nevoie să-și codifice comenzile.” Analiza
din jurnalele din ultimele 30 de zile confirmă: din 50.000 de execuții PowerShell, doar 12 folosesc
-EncodedCommand, și toate sunt atribuite unui script de automatizare IT cunoscut.
Pasul 2: Regula Sigma
title: Suspicious PowerShell Encoded Command Execution
id: f4a3b2c1-d5e6-7890-abcd-ef0123456789
status: test
description: |
Detects execution of PowerShell with encoded commands (-enc,
-EncodedCommand). Legitimate use is rare in enterprise environments.
Attackers commonly use this to obfuscate malicious payloads.
author: Federico Calo
date: 2025/12/01
modified: 2025/12/15
references:
- https://attack.mitre.org/techniques/T1059/001/
- https://attack.mitre.org/techniques/T1027/010/
logsource:
category: process_creation
product: windows
detection:
selection_powershell:
Image|endswith:
- '\powershell.exe'
- '\pwsh.exe'
selection_encoded:
CommandLine|contains:
- '-enc '
- '-EncodedCommand'
- '-encodedcommand'
- '-ec '
filter_known_automation:
ParentImage|endswith: '\sccm_agent.exe'
User|contains: 'SVC_AUTOMATION'
condition: selection_powershell and selection_encoded and not filter_known_automation
falsepositives:
- SCCM automation scripts (filtered)
- Custom IT automation using encoded commands (add to filter)
level: high
tags:
- attack.execution
- attack.t1059.001
- attack.defense_evasion
- attack.t1027.010Pasul 3: testare, implementare și rezultate
Regula este testată cu 5 scenarii pozitive adevărate (variante ale comenzii codificate) și 20 scenarii fals negative (execuții PowerShell legitime). După implementare prin conductă CI/CD, în primele 30 de zile detectarea generează 8 alerte: 6 pozitive adevărate (scripturi suspecte de analizat), 1 fals pozitiv (nou script de automatizare de adăugat la filtru) și 1 critic adevărat pozitiv care duce la descoperirea accesului neautorizat.
Rezultate măsurabile
- Precizie: 87,5% (7 TP din 8 alerte totale)
- MTTD: redus de la „nedetectat” la 4,2 minute (timp mediu de generare a alertelor)
- Acoperire ATT&CK: +2 tehnici (T1059.001, T1027.010) adăugate pe hartă
- Impact real: 1 deficiență activă descoperită și conținută în 45 de minute
Concluzii și pașii următori
Ingineria detectării reprezintă o schimbare fundamentală de paradigmă în domeniul securității operațională. Nu este vorba doar de a scrie reguli mai bune în SIEM, ci de a construi a proces complet de inginerie care se întinde pe întreg ciclul de viață de detecții: de la ipoteza amenințării până la validarea în producție.
Puncte cheie de reținut:
- Calitatea bate cantitatea - 50 de detectii de inalta fidelitate sunt la infinit mai utile decât 5.000 de reguli care generează zgomot de alertă.
- Tratați detecțiile ca un cod - Versiune, revizuire de cod, teste automate și conductele CI/CD nu sunt opționale, sunt fundamentale.
- Măsurați totul - MTTD, MTTR, precizie, rechemare, acoperire ATT&CK. Fără măsurători, îmbunătățirea continuă este imposibilă.
- Începeți de la tehnică - Hartă detecții la MITRE ATT&CK și concentrare resurse privind tehnicile cele mai relevante pentru organizația dvs.
- Investește în calitatea datelor - O detectare perfectă și inutilă fără ea datele pentru a opera. Normalizarea și integrarea surselor de jurnal sunt fundamentul invizibil al întregului program.
În articolul următor
În următorul articol al seriei vom aprofunda în ele Regulile Sigma: cel format standard pentru scrierea detecțiilor portabile. Vom vedea sintaxa completă, modificatori avansați, backend-uri de conversie pentru SIEM-urile majore și vom construi un set complet de reguli pentru cele mai critice tehnici ATT&CK.