Versione 0.6.0
Identificazione
| Voce | Riferimento |
|---|---|
| Data della versione | 10 novembre 2026 |
| Ambito | Console, Finding, Threat Intelligence e continuità della raccolta |
La versione 0.6.0 introduce miglioramenti alla continuità della sessione, alla generazione dei Finding, alle letture aggregate e alla raccolta degli eventi.
Dashboard, navigazione e inventario
| Area | Contenuto dichiarato | Lettura operativa |
|---|---|---|
| Conteggi log | Valori per tenant su 24 ore, 7 giorni, 30 giorni e storico ricercabile | Le finestre distinguono volume recente e dati ancora disponibili alla ricerca |
| Autenticazione | Riuso dell'autenticazione all'interno della singola richiesta | Riduzione delle verifiche ripetute nello stesso percorso |
| Sessione | Continuità dei dati mostrati durante il rinnovo | Il rinnovo non deve equivalere a un nuovo svuotamento della pagina |
| Navigazione | Navigazione persistente e badge aggregati | Il riepilogo non richiede il trasferimento completo degli elenchi |
| Inventario | Riepiloghi con trasferimento dei soli dati necessari | Riduzione del lavoro per mostrare il quadro iniziale |
| Integrazioni | Panoramica indipendente dalle attese del Data Plane e riuso dei token tecnici | Un'attesa del Data Plane non deve bloccare l'intera panoramica |
Guide correnti: Ricerca e hunting, Asset e detection, Sorgenti.
Finding e Threat Intelligence
La generazione dei Finding viene descritta come elaborazione di componenti indipendenti. Le prove restano tracciabili e un blocco è circoscritto alle componenti interessate. La presenza di una componente bloccata non deve essere confusa con l'esito di tutte le altre: il catalogo non promette che ogni componente produca comunque un risultato.
Le letture aggregate e il riuso controllato degli esiti stabili riducono il lavoro ripetuto, con monitoraggio delle query e della contesa. La revisione editoriale unifica le correzioni e introduce recupero parziale verificato e contesto IOC, preservando le evidenze e i limiti di costo.
Nel catalogo IOC sono dichiarati conteggi esatti, paginazione numerata e limiti espliciti di attesa. Durante il riempimento incrementale dello storico il reader mantiene la compatibilità: questo non equivale a dichiarare completato il recupero di tutti i dati storici.
Sono inoltre dichiarate verifiche editoriali più brevi e heartbeat accorpati. La manutenzione phishing evita di aprire transazioni quando non esiste lavoro dovuto.
Riferimenti: Finding e cluster, Threat Intelligence, Orchestrazione editoriale, Campagne phishing.
Raccolta, revoche e consegna degli alert
| Componente | Contenuto dichiarato |
|---|---|
| Vector | Riconciliazione a configurazione invariata, revoca delle ammissioni PostgreSQL e recupero del bootstrap |
| Routing Syslog | Uso di snapshot locali per il routing |
| Report Vector | Recupero dopo errori SQL transitori |
| Capture e staging Redis | Accodamento temporaneo, replay e revoche coordinate per isolare la raccolta dalle degradazioni PostgreSQL |
| Ingestione alert | Micro-batch e separazione dei lock tra ingestione ed effetti, quando abilitati dal profilo dell'ambiente |
Per controllare lo stato effettivo usa Stato piattaforma e i dettagli della sorgente Syslog. La presenza del codice o di una voce nel catalogo non dimostra l'attivazione del relativo profilo.
Requisiti e limiti dichiarati
- La disponibilità dipende da ruolo, tenant e configurazione dell'ambiente. Un profilo sperimentale Stage non è automaticamente attivo in produzione.
- Le code Redis volatili non conservano il backlog non ancora persistito in SQL in caso di riavvio o perdita della memoria. Accettazione temporanea e persistenza definitiva sono stati distinti.
- Il caricamento entro un secondo è un target da qualificare sul candidato nell'ambiente reale, non un tempo garantito da queste note. Lo stesso limite di evidenza vale per i miglioramenti prestazionali complessivi.
- Prima dell'aggiornamento verifica la compatibilità dei componenti e la procedura di migrazione prevista per l'ambiente.