Esecuzione di una regola sui dati in tempo reale
Quando crei una regola, inizialmente questa non ricerca rilevamenti in base a eventi ricevuti nel tuo account Google Security Operations in tempo reale. Tuttavia, devi impostare per cercare rilevamenti in tempo reale impostando l'opzione di attivazione/disattivazione Live Regola. da attivare.
Per impostare una regola come attiva, completa i seguenti passaggi:
Vai alla Dashboard regole.
Fai clic sull'icona dell'opzione Regole per una regola e imposta Regola in tempo reale su Attivata.
Regola in tempo reale
Puoi visualizzare i rilevamenti generati da una regola attiva scegliendo Visualizza rilevamenti regole.
Quota di regole
Fai clic sul pulsante Capacità per visualizzare i limiti al numero di regole che possono essere attivate come attive. Si trova nell'angolo superiore destro del Dashboard regole.
Google Security Operations impone i seguenti limiti di regole:
- Quota di regole per più eventi: mostra il numero attuale di regole per più eventi attivate come attive e il numero massimo di regole che possono essere attivate come attive. Ulteriori informazioni sulla differenza tra le regole per evento singolo e le regole Evento multiplo sono disponibili qui.
- Quota totale regole: mostra il numero totale attuale di regole abilitate come attive in tutti i tipi di regole e il numero massimo di regole che possono essere attivate come attive.
Ulteriori informazioni sui diversi tipi di regole sono disponibili qui.
Esecuzioni delle regole
Le esecuzioni di regole in tempo reale per un determinato bucket temporale dell'evento verranno attivate con frequenza decrescente. Ci sarà un'ultima esecuzione di pulizia, dopodiché non verrà più avviata l'esecuzione.
Ogni esecuzione viene eseguita sulle ultime versioni degli elenchi di riferimento utilizzati nelle regole, oltre che sull'arricchimento dei dati su eventi ed entità più recente.
Ciò significa che alcuni rilevamenti possono essere generati retroattivamente se vengono rilevati solo dalle esecuzioni successive. Ad esempio, l'ultima esecuzione potrebbe utilizzare la versione più recente dell'elenco di riferimento, che ora rileva più eventi, e i dati di eventi ed entità possono essere sottoposti a nuovo trattamento a causa di nuovi arricchimenti.
Latenze di rilevamento
Vari fattori determinano il tempo necessario per generare un rilevamento da una regola attiva. Il seguente elenco include i diversi fattori che contribuiscono ai ritardi nel rilevamento:
- Tipi di regole
- Frequenza corsa
- Ritardo di importazione
- join contestuali
- Dati UDM arricchiti
- Problemi relativi al fuso orario
- Elenchi di riferimento
Tipi di regole
- Le regole per un singolo evento vengono eseguite quasi in tempo reale in modalità flusso. Se possibile, utilizza queste regole per ridurre al minimo la latenza.
- Le regole per più eventi vengono eseguite in modo pianificato, il che porta a una latenza più elevata a causa del tempo tra un'esecuzione pianificata e l'altra.
Frequenza di pubblicazione
Per ottenere rilevamenti più rapidi, utilizza una frequenza di esecuzione più breve e una finestra di corrispondenza più piccola. L'utilizzo di finestre di corrispondenza più brevi (meno di un'ora) consente esecuzioni più frequenti.
Ritardo nell'importazione
Assicurati che i dati vengano inviati a Google Security Operations non appena si verifica l'evento. Quando esamini un rilevamento, presta attenzione ai timestamp dell'evento e dell'importazione UDM.
Join contestuali
Regole multievento che con dati contestuali, come UEBA o Entity Graph, potrebbero avere ritardi maggiori. I dati contestuali devono essere prima generati da Google SecOps.
Dati UDM arricchiti
Google SecOps arricchisce gli eventi con i dati di altri eventi. Per identificare se una regola sta valutando un campo arricchito, esamina il Visualizzatore eventi. Se la regola sta valutando un campo arricchito, il rilevamento potrebbe subire ritardi.
Problemi relativi al fuso orario
Le regole vengono eseguite più spesso per i dati in tempo reale. I dati potrebbero arrivare in tempo reale, ma Google SecOps potrebbe comunque trattarli come dati in ritardo se l'ora dell'evento non è corretta a causa di problemi con il fuso orario. Il fuso orario predefinito di Google SecOps SIEM è UTC. Se i dati originali hanno un timestamp evento impostato su un fuso orario diverso da UTC, aggiorna il fuso orario dei dati. Se non è possibile aggiornare il fuso orario all'origine log, contatta l'assistenza in modo da poter eseguire l'override del fuso orario.
Regole di non esistenza
Le regole che verificano la non esistenza (ad esempio quelle che contengono !$e o #e=0) vengono eseguite con un ritardo di almeno un'ora per garantire che i dati abbiano il tempo di arrivare.
Elenchi di riferimento
Le esecuzioni delle regole utilizzano sempre la versione più aggiornata di un elenco di riferimento. Se l'elenco di riferimento è stato aggiornato di recente, un nuovo rilevamento potrebbe apparire in ritardo perché il rilevamento potrebbe essere incluso nei nuovi contenuti dell'elenco aggiornato durante le successive esecuzioni della regola pianificata.
Per ottenere latenze di rilevamento inferiori, ti consigliamo di procedere nel seguente modo:
- Invia i dati dei log a Google Security Operations non appena si verifica l'evento.
- Controlla le regole per vedere se è necessario usare dati non esistenti o arricchiti di contesto.
- Configura una frequenza di esecuzione inferiore.
Stato della regola
Le regole attive possono avere uno dei seguenti stati:
Attivata: la regola è attiva e funziona normalmente come regola attiva.
Disabilitata: la regola è disattivata.
Con restrizioni: le regole attive possono essere inserite in questo stato quando mostrano. utilizzo delle risorse insolitamente elevato. Le regole limitate vengono isolate dalle altre regole attive le regole del sistema per mantenere la stabilità di Google Security Operations.
Per le regole attive limitate, l'esecuzione corretta delle regole non è garantita. Tuttavia, se l'esecuzione della regola ha esito positivo, i rilevamenti vengono conservati e disponibili da esaminare. Le regole attive limitate generano sempre un messaggio di errore. che includono informazioni su come migliorare le prestazioni della regola.
Se il rendimento di una regola Limitata non migliora entro tre giorni, la sua diventa In pausa.
In pausa: le regole attive entrano in questo stato quando erano in stato Con restrizioni. per 3 giorni e non ha mostrato alcun miglioramento del rendimento. Esecuzioni per Questa regola è in pausa e sono stati inviati messaggi di errore contenenti informazioni su come migliorare le prestazioni della regola.
Per ripristinare lo stato Attivata di qualsiasi regola attiva, segui questi passaggi: best practice YARA-L per migliorare le prestazioni della regola e salvarlo. Dopo aver salvato la regola, verrà reimpostato sullo stato Attivato e l'operazione richiederà almeno un'ora , prima che la regola torni allo stato Con restrizioni.
Puoi potenzialmente risolvere i problemi di prestazioni di una regola configurandola a essere eseguite con meno frequenza. Ad esempio, puoi riconfigurare una regola affinché ogni 10 minuti o di corsa una volta all'ora o una volta ogni 24 ore. Tuttavia, se cambi la frequenza di esecuzione di una regola non tornerà allo stato Attivato. Se apporti una piccola modifica alla regola e la salvi, puoi: reimposta automaticamente lo stato Attivato.
Gli stati delle regole vengono visualizzati nella dashboard delle regole e sono accessibili anche tramite l'API Detection Engine. Errori generati dalle regole nella classe Con restrizioni o In pausa sono disponibili utilizzando Metodo API ListErrors. L'errore indicherà che lo stato della regola è Limitata o In pausa. e ti indirizza alla documentazione su come risolvere il problema.