Partea 1 a construit fundația de informații. Partea 2 implementează stratul de operațiuni care consumă acele informații: SIEM agregează și corelează telemetria, SOAR automatizează răspunsul, ambele conectate la topologia rețelei cu enclave clasificate care definește securitatea cibernetică pentru apărare. Produsele comerciale SIEM și SOAR există; ingineria lor pentru implementarea în apărare este unde majoritatea programelor subestimează munca. Partea 2 explică cum arată această muncă în realitate.

Cadrul la nivel de pilon se găsește în Ghidul complet al securității cibernetice pentru apărare; detalii mai profunde de inginerie SIEM/SOAR în SIEM și SOAR pentru integrare militară.

Pasul 1: Arhitectura de implementare per enclavă

Cea mai importantă decizie arhitecturală: nu rulați o singură instanță SIEM pe mai multe niveluri de clasificare. Fiecare enclavă clasificată rulează propriul stack SIEM/SOAR cu propriul depozit de date, propriul conținut de detectare, propriul jurnal de audit. Stack-urile sunt separate fizic; mișcarea datelor între ele trece prin soluții cross-domain acreditate, niciodată prin infrastructură partajată.

Raționamentul este structural: datele SIEM sunt un superset de clasificare al surselor pe care le ingestează. Un SIEM care agregează jurnalele de rețea SECRET deține conținut clasificat SECRET; îmbinarea acelui depozit cu jurnalele administrative NECLASIFICATE ar ridica inadvertent clasificarea depozitului administrativ prin efectul de agregare al SIEM-ului. Izolarea per enclavă previne aceasta.

Tiparul de implementare pentru exemplul de rulare:

  • SIEM NECLASIFICAT — rețele administrative, active orientate spre internet, gestionare furnizori. SaaS furnizat de vendor poate fi acceptabil aici.
  • SIEM NATO RESTRICȚIONAT — rețele de misiune de coaliție, infrastructură atașată FMN. Găzduit autonom pe infrastructură acreditată; SaaS furnizor rar acceptabil.
  • SIEM NATO SECRET — rețele clasificate operaționale. Găzduit autonom; izolat de internet; actualizări prin canale controlate.
  • SIEM clasificat național — sisteme naționale la clasificare mai înaltă. Furnizori unici care au acreditare națională; implementare personalizată.

Partajarea de informații cross-enclavă circulă prin propagarea CTI (mecanismul din Partea 1) și prin rapoarte de rezumat controlate — nu prin dashboarduri SIEM partajate.

Pasul 2: Pipeline-ul de agregare a jurnalelor

SIEM este, structural, un pipeline de jurnale cu detectare stratificată deasupra. Faceți pipeline-ul corect și detectarea devine tractabilă; faceți-l greșit și costul pipeline-ului domină tot restul.

Etapele pipeline-ului:

Colectare. Agenți pe endpoint-uri (Sysmon pe Windows, auditd pe Linux, agenți EDR ai furnizorilor), senzori de rețea (produse NDR, aparate IDS, colectori NetFlow), jurnale de aplicații (format personalizat și Syslog), jurnale de plan-control cloud (acolo unde cloud-ul este în domeniu), telemetrie OT (Partea 3 a acestei serii).

Normalizare. Formatele sursă eterogene normalizate la o schemă comună. Elastic Common Schema (ECS), OCSF, scheme specifice furnizorilor — alegeți una și aliniați-vă. Nepotrivirile de schemă în producție sunt o sursă recurentă de ratări în detectare.

Îmbogățire. Adăugați context pe care jurnalul brut îl lipsește: clasificarea activelor din inventar (Partea 1), etichete CTI din pipeline-ul de informații, context de atribute de utilizator din sistemele de identitate, geolocalizare, asociere cu actori de amenințare.

Rutare. Evenimentele circulă la nivelul hot al SIEM-ului pentru corelație live, la stocarea rece pe termen lung pentru retenția criminalistică și selectiv la SOAR pentru declanșarea playbook-urilor. Regulile de rutare sunt politică explicită.

Retenție. Securitatea cibernetică pentru apărare are cerințe de retenție lungă — campaniile stat-națiune rezidă luni sau ani. Pipeline-ul suportă retenție stratificată: hot (corelație live), warm (interogări criminalistice recente), cold (arhivare pe termen lung). Bugetele de retenție sunt decizii de program; bugetarea insuficientă forțează ștergerea prematură a datelor.

Pasul 3: Conținut de detectare ca și cod

Regulile de detectare out-of-the-box SIEM prind amenințările de tip marfă. Detectarea de grad de apărare prinde amenințările stat-națiune. Decalajul este conținutul de detectare: reguli adaptate la inventarul de active, modelul de amenințare și pipeline-ul CTI.

Disciplina conținutului-de-detectare-ca-și-cod:

Reguli Sigma ca format sursă. Sigma este formatul de reguli de detectare neutru față de furnizori; regulile scrise în Sigma se convertesc la Splunk, Elastic, Sentinel, QRadar și altele. Scrierea în Sigma menține detectarea portabilă; ajustarea specifică furnizorului are loc la implementare.

Reguli per activ și per actor de amenințare. Detectarea generică a "comenzii PowerShell codificate" prinde zgomot. "Comandă PowerShell codificată pe un host NATO SECRET de la un utilizator care nu se află în OU-ul de inginerie" este semnal. Inventarul de active și modelul de amenințare informează specificitatea regulii.

Testare CI față de date de evenimente capturate. Regulile de detectare sunt testate în unitate în CI. Urmele de evenimente capturate din incidente anterioare și exerciții red-team servesc drept adevăr fundamental. O modificare de regulă care nu mai detectează incidentul capturat este o regresie care blochează merge-ul.

Maparea MITRE ATT&CK. Fiecare regulă se mapează la una sau mai multe tehnici ATT&CK. Maparea permite analiza de acoperire (ce tehnici sunt bine acoperite, care sunt puncte oarbe) și raportarea de grad de achiziție a posturii defensive a platformei.

Gestionarea falselor pozitive. Regulile produc alerte. Alertele produc volum de muncă SOC. Disciplina de ajustare FP — măsurarea ratei FP per regulă, rafinarea regulilor pentru reducerea zgomotului, retragerea regulilor care nu pot fi ajustate — este structurală. SOC-urile care se îneacă în FP-uri ratează TP-urile.

Pasul 4: Ingineria playbook-urilor SOAR

SOAR (Security Orchestration, Automation, and Response) automatizează răspunsul la evenimentele detectate. Un playbook este un flux de lucru versionat, testat, revizuibil pe care SOAR îl execută la alertă.

Disciplina playbook-urilor:

Versionat în controlul surselor. Playbook-urile sunt cod — YAML, JSON, DSL-uri specifice furnizorilor. Trăiesc în depozitar alături de regulile de detectare, sunt revizuite înainte de implementare și sunt lansate prin același proces de control al modificărilor ca și codul aplicației.

Testat în CI. Urmele de incidente capturate servesc drept intrări de test. Un playbook care nu mai execută corect față de urma capturată blochează merge-ul.

Porți de confirmare umană pentru acțiuni cu consecințe. SOAR poate izola un host, dezactiva un cont de utilizator, bloca un interval de rețea, termina un proces. Fiecare dintre acestea are consecințe operaționale. Playbook-ul prezintă acțiunea propusă și necesită confirmarea explicită a unui om; decizia omului este înregistrată în jurnal.

Urmă de audit pentru fiecare acțiune automată. Chiar și acțiunile care se completează fără revizuire umană (îmbogățire alertă, creare bilet, căutare informații despre amenințări) sunt înregistrate în jurnal. Urma de audit este baza de dovezi pentru revizuirea post-acțiune.

Căi de rollback. O acțiune SOAR care a fost greșită — host greșit izolat, utilizator greșit dezactivat — trebuie să fie reversibilă. Ingineria playbook-ului acomodează aceasta de la bun început; retrofitarea reversiunii este muncă personalizată per acțiune.

Pasul 5: Integrarea cross-CERT

Securitatea cibernetică pentru apărare există într-o comunitate. CERT-uri naționale (CISA, BSI, ANSSI, CCN-CERT), CSIRT-uri specifice militare (US-CERT, NCSC, JCDC), CSIRT-uri de coaliție (NATO NCIRC), CSIRT-uri partenere. Platforma se integrează cu această comunitate bidirecțional.

Tiparele de integrare:

Consumul de informații primit. Avizele CERT circulă în pipeline-ul CTI (Partea 1) și declanșează actualizări ale regulilor de detectare. Avizele sensibile la timp (exploatarea activă a vulnerabilităților, atribuirea campaniei în curs) primesc tratament prioritar.

Raportarea incidentelor ieșite. Incidentele confirmate — în special cele care implică TTP-uri stat-națiune sau indicatori relevanți pentru coaliție — circulă ieșit la CERT-ul corespunzător prin STIX/TAXII sau canale formale de raportare a incidentelor. Raportarea respectă clasificarea: incidentele NATO SECRET merg la NCIRC, nu la un furnizor comercial.

Vânătoarea comună. Colaborări periodice de vânătoare a amenințărilor cu CERT-uri partenere — rularea interogărilor în mai multe medii naționale, căutarea TTP-urilor adversarului care apar doar în agregat. Vânătoarea comună este valoroasă operațional și complexă politic; urma de audit a platformei suportă revizuirea juridică și politică.

Participarea la exerciții. Locked Shields, Cyber Coalition, Crossed Swords — exerciții cyber NATO și ale partenerilor care testează coordonarea cross-CERT. Participarea este dovadă de grad de achiziție a capacității.

Concluzie cheie: Un stack SIEM/SOAR care operează în izolare prinde ce poate vedea local. Un stack integrat cu comunitatea CERT vede aceleași amenințări care au apărut deja în mediile partenere — de obicei cu zile mai devreme. Disciplina integrării comunității este cu efect de pârghie ridicat și subevaluată în specificațiile de achiziție.

Pasul 6: Ținte de performanță și scalabilitate

Ținte SIEM/SOAR care disting platformele operaționale de prototipuri:

  • Ingestia de jurnale susținută la rata operațională (de obicei 50K–500K evenimente/secundă pentru o implementare de apărare națională), cu gestionarea vârfurilor la 5× linia de bază.
  • Latența de detectare sub 60 de secunde de la sosirea evenimentului la generarea alertei pentru regulile sensibile la timp; sub 5 minute pentru regulile cu corelație intensivă.
  • Latența de execuție a playbook-ului sub 30 de secunde pentru predarea revizuirii umane; completarea întregului playbook în minute pentru căile automatizate.
  • Retenția stocării măsurată în ani pentru mediile cu clasificare înaltă; stratificată pentru gestionarea costurilor.
  • Performanța interogărilor sub 30 de secunde pentru interogările tipice ale analistului pe datele hot; sub 5 minute pentru interogările pe datele cold.
  • Disponibilitatea la 99,9%+ pentru componentele nivelului hot; operarea degradată acceptabilă la defecțiunile nivelului cold.

Ratarea acestor ținte este de obicei rezultatul scurtăturilor arhitecturale (ingestie sub-provizionată, indici rutați greșit, tipare de interogare naive). Programele care prototipează față de aceste ținte explicit prind scurtăturile înainte de implementarea operațională.

Pasul 7: Selectarea furnizorului pentru implementarea în apărare

Lista furnizorilor SIEM/SOAR deployabili în apărare este mai mică decât lista comercială. Criteriile:

Istoricul de acreditare. Furnizorii cu acreditare anterioară în rețelele clasificate NATO sau ale statelor membre au dovezi pe care revizuitorii de acreditare le găsesc credibile. Pornirea de la zero cu un furnizor neacreditat adaugă 12-24 de luni la implementare.

Deployabilitate în air-gap. Implementarea furnizorului trebuie să funcționeze în medii fără ieșire internet pentru actualizări, fluxuri de informații despre amenințări sau telemetrie. Produsele numai-cloud sunt excluse pentru clasificările mai înalte.

Poziționare fără ITAR pentru programele europene. Consultați Software de apărare fără ITAR pentru criterii. Implementările europene preferă din ce în ce mai mult furnizorii fără ITAR.

Portabilitatea conținutului de detectare. Suportul Sigma (sau un format neutru față de furnizori comparabil) menține conținutul de detectare al platformei portabil în tranzițiile de furnizori. Lock-in-ul furnizorului pe conținut de detectare este un risc strategic.

API-uri deschise. SIEM/SOAR se integrează cu tot restul din stack-ul cyber — platformă CTI, EDR, senzori de rețea, sisteme de identitate, ticketing. API-urile deschise sunt non-negociabile.

Criteriile detaliate de selecție a furnizorilor pentru software de apărare în general se găsesc în Cum să alegeți un furnizor de software de apărare.

Ce urmează

Partea 2 a construit stratul de operațiuni. Arhitectura SIEM/SOAR per enclavă, pipeline-ul de agregare a jurnalelor, conținut de detectare ca și cod, disciplina playbook-urilor SOAR, integrarea cross-CERT, ținte de performanță, selectarea furnizorului. Stack-ul detectează și răspunde acum la scară în cadrul arhitecturii cu enclave clasificate.

Partea 3 acoperă straturile specializate: apărarea ICS/OT pentru tehnologia operațională pe care instrumentele IT nu o abordează, pregătirea criminalisticii digitale pentru analiza post-compromis și soluțiile cross-domain care mișcă datele adecvate între enclave în timp ce previn fluxurile necorespunzătoare.