Condividi tramite

Modificare il contenuto per usare Advanced Security Information Model (ASIM) (anteprima pubblica)

  • Articolo

Il contenuto di sicurezza normalizzato in Microsoft Sentinel include regole di analisi, query di ricerca e cartelle di lavoro che funzionano con parser di normalizzazione unificati.

È possibile trovare contenuti normalizzati e predefiniti nelle raccolte e nelle soluzioni di Microsoft Sentinel, creare contenuti normalizzati o modificare contenuto personalizzato esistente per usare i dati normalizzati.

Questo articolo illustra come convertire le regole di analisi di Microsoft Sentinel esistenti per l'uso di dati normalizzati con Advanced Security Information Model (ASIM).

Per comprendere il modo in cui il contenuto normalizzato rientra nell'architettura ASIM, vedere il diagramma dell'architettura ASIM.

Suggerimento

Guardare anche il webinar di approfondimento sulla normalizzazione dei parser e sul contenuto normalizzato di Microsoft Sentinel o esaminare le diapositive. Per altre informazioni, vedere Passaggi successivi.

Importante

ASIM è attualmente in anteprima. Le condizioni aggiuntive per l'anteprima di Azure includono termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, anteprima o diversamente non ancora disponibili a livello generale.

Modificare il contenuto personalizzato per usare la normalizzazione

Per abilitare il contenuto personalizzato di Microsoft Sentinel per l'uso della normalizzazione:

  • Modificare le query per usare eventuali parser unificanti pertinenti alla query.

  • Modificare i nomi dei campi nella query per usare i nomi dei campi dello schema normalizzati.

  • Se applicabile, modificare le condizioni per usare i valori normalizzati dei campi nella query.

Normalizzazione di esempio per le regole di analisi

Si consideri, ad esempio, il client raro osservato con una regola di analisi DNS di ricerca DNS altamente inversa, che funziona sugli eventi DNS inviati dai server DNS Infoblox:

let threshold = 200;
InfobloxNIOS
| where ProcessName =~ "named" and Log_Type =~ "client"
| where isnotempty(ResponseCode)
| where ResponseCode =~ "NXDOMAIN"
| summarize count() by Client_IP, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (InfobloxNIOS
    | where ProcessName =~ "named" and Log_Type =~ "client"
    | where isnotempty(ResponseCode)
    | where ResponseCode =~ "NXDOMAIN"
    ) on Client_IP
| extend timestamp = TimeGenerated, IPCustomEntity = Client_IP

Il codice seguente è la versione indipendente dall'origine, che usa la normalizzazione per fornire lo stesso rilevamento per qualsiasi origine che fornisce eventi di query DNS. L'esempio seguente usa parser ASIM predefiniti:

_Im_Dns(responsecodename='NXDOMAIN')
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns(responsecodename='NXDOMAIN')) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Per usare i parser ASIM distribuiti nell'area di lavoro, sostituire la prima riga con il codice seguente:

imDns(responsecodename='NXDOMAIN')

Differenze tra parser predefiniti e distribuiti nell'area di lavoro

Le due opzioni nell'esempio precedente sono identiche a livello funzionale. La versione normalizzata indipendente dall'origine presenta le differenze seguenti:

  • I _Im_Dns parser normalizzati o imDnsvengono usati invece del parser Infoblox.

  • I parser normalizzati recuperano solo gli eventi di query DNS, quindi non è necessario controllare il tipo di evento, come eseguito da where ProcessName =~ "named" and Log_Type =~ "client" nella versione Infoblox.

  • Il SrcIpAddr campo viene usato invece di Client_IP.

  • Il filtro dei parametri del parser viene usato per ResponseCodeName, eliminando la necessità di clausole esplicite where .

Nota

Oltre a supportare qualsiasi origine DNS normalizzata, la versione normalizzata è più breve e più facile da comprendere.

Se lo schema o i parser non supportano i parametri di filtro, le modifiche sono simili, ad eccezione del fatto che le condizioni di filtro vengono mantenute dalla query originale. Ad esempio:

let threshold = 200;
imDns
| where isnotempty(ResponseCodeName)
| where ResponseCodeName =~ "NXDOMAIN"
| summarize count() by SrcIpAddr, bin(TimeGenerated,15m)
| where count_ > threshold
| join kind=inner (imDns
    | where isnotempty(ResponseCodeName)
    | where ResponseCodeName =~ "NXDOMAIN"
    ) on SrcIpAddr
| extend timestamp = TimeGenerated, IPCustomEntity = SrcIpAddr

Per altre informazioni sugli elementi seguenti usati negli esempi precedenti, vedere la documentazione di Kusto:

Per altre informazioni su KQL, vedere panoramica di Linguaggio di query Kusto (KQL).

Altre risorse:

Passaggi successivi

Questo articolo illustra il contenuto di Advanced Security Information Model (ASIM).

Per altre informazioni, vedi: