Esegui la migrazione degli avvisi CBN agli avvisi delle regole di rilevamento YARA-L
Questo documento fornisce dettagli su come eseguire la migrazione degli avvisi di normalizzazione basata sulla configurazione (CBN) agli avvisi di rilevamento YARA-L. In qualità di analista della sicurezza, con l'aiuto di questo documento, puoi continuare a ricevere notifiche per gli avvisi provenienti da sistemi di terze parti utilizzando la pagina Avvisi e indicatori di compromissione.
Esegui la migrazione degli avvisi CBN al motore di rilevamento YARA-L
Per eseguire la migrazione degli avvisi CBN, puoi assicurarti che gli avvisi CBN precedenti siano disponibili come avvisi delle regole di rilevamento utilizzando le seguenti opzioni.
Utilizzare la ricerca UDM
Utilizzando l'opzione di ricerca UDM, puoi visualizzare gli eventi con alert_state
impostato nei parser:
security_result.alert_state = "ALERTING"
Dai risultati di ricerca di UDM, puoi esplorare i seguenti campi per capire quali origini generano avvisi CBN nel tuo ambiente:
Metadata
>Vendor Name
Metadata
>Product Name
Scarica gli avvisi CBN predefiniti utilizzando l'API Strumenti e rivedi manualmente
L'approccio precedente ti aiuta a trovare gli avvisi che sono stati attivati, ma non copre lo scenario degli avvisi che non hai mai visto prima.
Puoi utilizzare il metodo dei parser backstory.googleapis.com/v1/tools/cbn
per scaricare i CBN predefiniti, selezionati o tutti e rivedere manualmente la logica del parser applicata per trovare avvisi basati su is_alert
o alert_state
.
Puoi trasferire gli avvisi CBN agli avvisi delle regole del motore di rilevamento YARA-L che utilizzi attivamente.
Esegui la migrazione degli avvisi di Windows Defender Antivirus che in precedenza venivano visualizzati in Enterprise Insights come avvisi CBN
L'esempio seguente mostra come eseguire la migrazione degli avvisi di Windows Defender Antivirus che in precedenza venivano visualizzati in Enterprise Insights come avvisi CBN.
Trova un avviso di esempio utilizzando uno degli approcci descritti in precedenza.
Utilizzando il visualizzatore di eventi di log non elaborati / UDM, copia i campi UDM selezionati che forniranno un rilevamento affidabile. Vedi l'esempio che segue:
metadata.vendor_name = "Microsoft" metadata.product_name = "Windows Defender AV" metadata.product_event_type = "MALWAREPROTECTION_STATE_MALWARE_DETECTED" principal.asset.hostname = "client02.example.local" security_result.action = "BLOCK" security_result.severity = "MEDIUM"
Crea una nuova regola del motore di rilevamento YARA-L.
rule windows_defender_av_monitored_events { meta: author = "Chronicle" description = "Migration of CBN alerts to Google Security Operations YARA-L detection engine rule alert." // Severity is set at the Outcome level via security_result.severity severity = "INFORMATIONAL" priority = "INFORMATIONAL" events: $windows_defender_av.metadata.vendor_name = "Microsoft" $windows_defender_av.metadata.product_name = "Windows Defender AV" $windows_defender_av.metadata.product_event_type = "MALWAREPROTECTION_STATE_MALWARE_DETECTED" $windows_defender_av.principal.asset.hostname = $host // optionally tune to only detection on ALLOW, i.e., failure to BLOCK //$windows_defender_av.security_result.action = "ALLOW" // optionally tune on severity of detection //$windows_defender_av.security_result.severity != "LOW" outcome: $risk_score = max( if ($windows_defender_av.security_result.severity = "UNKNOWN_SEVERITY", 0) + if ($windows_defender_av.security_result.severity = "LOW", 25) + if ($windows_defender_av.security_result.severity = "MEDIUM", 50) + if ($windows_defender_av.security_result.severity = "HIGH", 75) + if ($windows_defender_av.security_result.severity = "CRITICAL", 100) ) $severity = array_distinct($windows_defender_av.security_result.severity) condition: $windows_defender_av }
L'avviso CBN sembra utilizzare un campo che non è stato analizzato in UDM
Utilizzando l'opzione delle estensioni dell'analizzatore, puoi risolvere rapidamente questo scenario.
Ad esempio, l'avviso CBN di Corelight utilizza il campo notice
e invia avvisi condizionali solo se è vero:
if [notice] == "true" {
mutate {
replace => {
"is_significant" => "true"
"is_alert" => "true"
}
}
}
Poiché questo valore non è normalizzato in UDM per impostazione predefinita, puoi utilizzare un'estensione del parser Grok come segue per aggiungerlo come campo UDM di tipo Additional
:
filter {
mutate {
replace => {
"notice" => ""
}
}
grok {
match => { "message" => [ "(?P<message>\{.*\})$" ] }
on_error => "_grok_not_syslog"
overwrite => [ "message" ]
}
json {
on_error => "not_json"
source => "message"
array_function => "split_columns"
}
if ![not_json] {
if [notice] != "" {
mutate {
convert => {
"notice" => "string"
}
}
mutate {
replace => {
"additional_notice.key" => "notice"
"additional_notice.value.string_value" => "%{notice}"
}
}
mutate {
merge => {
"event1.idm.read_only_udm.additional.fields" => "additional_notice"
}
}
mutate {
merge => {
"@output" => "event1"
}
}
}
}
}
Puoi quindi utilizzarlo in una regola del motore di rilevamento YARA-L come segue e utilizzando la funzione Maps:
events:
// Corelight : Weird Log
(
$corelight.metadata.vendor_name = "Corelight" and
$corelight.metadata.product_name = "Zeek" and
// this requires a custom parser extension to extract notice
$corelight.metadata.product_event_type = "weird" and
$corelight.additional.fields["notice"] = "true"
)
Devi attivare e abilitare le regole create per gli avvisi. Per ulteriori informazioni, vedi Eseguire i dati in tempo reale delle regole.