Condividi tramite


Creare e pubblicare regole di analisi per le soluzioni di Microsoft Sentinel

Le regole di analisi di Microsoft Sentinel sono set di criteri. Definiscono il modo in cui vengono monitorati i dati, cosa viene rilevato e quali azioni vengono eseguite quando vengono soddisfatte condizioni specifiche. Queste regole consentono di identificare comportamenti sospetti, anomalie e potenziali minacce alla sicurezza analizzando i log e i segnali provenienti da varie origini dati.

Le regole di analisi di Microsoft Sentinel sono strumenti potenti per migliorare il comportamento di sicurezza di un'organizzazione perché rilevano e rispondono in modo proattivo alle potenziali minacce. Seguendo un approccio strutturato alla creazione e alla gestione di queste regole, le organizzazioni possono usare le funzionalità di Microsoft Sentinel per proteggere le risorse digitali e mantenere un'infrastruttura di sicurezza affidabile. Per altre informazioni, vedere Rilevamento delle minacce in Microsoft Sentinel.

Questo articolo illustra il processo di creazione e pubblicazione di regole di analisi nelle soluzioni Di Microsoft Sentinel.

Casi d'uso per le regole di analisi di Microsoft Sentinel

Le regole di analisi di Microsoft Sentinel possono essere applicate a un'ampia gamma di scenari per migliorare il monitoraggio della sicurezza e il rilevamento delle minacce. I casi d'uso comuni in cui può verificarsi questa situazione includono:

  • Rilevamento delle intrusioni: identificare tentativi di accesso non autorizzati o attività di accesso sospette che potrebbero indicare una potenziale violazione.
  • Rilevamento malware: monitorare le firme malware note o comportamenti insoliti che potrebbero suggerire la presenza di software dannoso.
  • Esfiltrazione di dati: rilevare trasferimenti di dati di grandi dimensioni o insoliti che potrebbero indicare che i dati vengono esfiltrati dalla rete.
  • Minacce Insider: identificare il comportamento anomalo degli utenti interni, ad esempio l'accesso a dati sensibili al di fuori delle normali ore o modelli.
  • Monitoraggio della conformità: garantire la conformità ai requisiti normativi monitorando attività o modelli di accesso specifici.
  • Ricerca di minacce: cercare in modo proattivo indicatori di compromissione o altri segni di attività dannose all'interno della rete.
  • Compromissione dell'account: rilevare i segnali che gli account utente potrebbero essere compromessi, ad esempio modelli di accesso geografici insoliti o più tentativi di accesso non riusciti.
  • Anomalie di rete: identificare modelli insoliti di traffico di rete che potrebbero indicare la presenza di una minaccia o di una configurazione errata.
  • Escalation dei privilegi: monitorare i tentativi di ottenere privilegi elevati all'interno della rete, che può essere un precursore di ulteriori attività dannose.
  • Sicurezza degli endpoint: assicurarsi che gli endpoint siano sicuri rilevando deviazioni dal comportamento normale o dalla presenza di software non autorizzato.

Creare e pubblicare regole di analisi

Le regole di analisi vengono create in formato YAML . È possibile usare questo esempio di regola di analisi come riferimento per creare query personalizzate: regola di analisi di esempio in GitHub.

Le sezioni seguenti forniscono una procedura dettagliata dei vari attributi di una regola di analisi.

ID

L'attributo id è costituito da un identificatore univoco globale standard (GUID). Generarlo usando qualsiasi strumento di sviluppo, un generatore online o il nuovo cmdlet New-GUID di PowerShell. Deve essere univoco tra gli altri GUID.

Questo campo è obbligatorio.

Tipologia

L'attributo kind rappresenta il tipo di regola.

Sono disponibili due valori accettati: scheduled e NRT (quasi in tempo reale). Il scheduled valore richiede la definizione di altre proprietà, tra cui queryFrequency, queryPeriodtriggerThreshold, e triggerOperator.

Questo campo è obbligatorio.

Nome

L'attributo name fornisce una breve etichetta che riepiloga il rilevamento. Assicurarsi che l'etichetta sia chiara e concisa per aiutare gli utenti a comprendere lo scopo della regola. Usare alertDetailsOverride per generare nomi dinamici per aiutare gli analisti a comprendere l'avviso. Questo attributo:

  • Usa la maiuscola tra maiuscole e minuscole di frase.
  • Non termina in un periodo.
  • Ha una lunghezza massima di 50 caratteri (quando possibile).

Questo campo è obbligatorio.

Descrizione

L'attributo description fornisce una descrizione dettagliata del rilevamento. La descrizione include informazioni sul comportamento rilevato, sull'effetto potenziale e sulle azioni consigliate. Questo attributo:

  • Usa la maiuscola maiuscola tra maiuscole e minuscole delle frasi.
  • Inizia con "Questa query cerca" o "Identifica".
  • È diverso da e più descrittivo rispetto al campo nome.
  • Lunghezza massima di 255 caratteri.
  • È minore o meno di cinque frasi.
  • Non descrive l'origine dati (connettore o tipo di dati).
  • Non fornisce una spiegazione tecnica per il linguaggio di query.

Questo campo è obbligatorio.

Gravità

L'attributo severity definisce il livello di gravità del rilevamento. La gravità riflette il potenziale effetto del comportamento rilevato e l'urgenza della risposta.

  • Informativo: l'evento imprevisto potrebbe non rappresentare direttamente una minaccia per la sicurezza, ma potrebbe essere di interesse per l'indagine di follow-up o per aggiungere contesto o consapevolezza della situazione a un analista.
  • Basso: l'effetto immediato è minimo e un attore di minacce deve eseguire più passaggi prima di ottenere un effetto su un ambiente.
  • Medium: l'attore di minacce potrebbe ottenere un certo effetto sull'ambiente con questa attività, ma l'effetto sarebbe limitato nell'ambito o richiede un'attività aggiuntiva.
  • Alta: l'attività identificata fornisce all'attore di minaccia l'accesso a un'ampia gamma di azioni per l'esecuzione di azioni nell'ambiente.

Nota

Le impostazioni predefinite del livello di gravità non sono una garanzia del livello di impatto corrente o dell'ambiente. Il livello di gravità si applica solo ai modelli di analisi di Microsoft Sentinel. In caso contrario, il servizio di sicurezza che ha emesso l'avviso controlla l'attributo severity nella tabella Avvisi. È possibile usare alertDetailsOverride per fornire un attributo dinamico severity che dipende dal risultato effettivo della query.

Connettori dati necessari

L'attributo requiredDataConnectors rappresenta l'elenco dei connettori dati che la regola deve funzionare correttamente, incluse le origini dati su cui viene eseguita la query della regola. Se non è presente alcun mapping del connettore dati corrente, è necessario usare una parentesi graffa aperta: requiredDataConnectors: [].

L'attributo connectorId specifica l'ID del connettore dati necessario in modo che la query funzioni correttamente. Se la query di rilevamento dipende dai dati recuperati da un connettore specifico, è necessario specificare qui l'ID connettore. Ad esempio, se la regola di analisi dipende dai dati di questo connettore, è necessario specificare come 1PasswordCCPDefinitionconnectorID .

L'attributo dataTypes rappresenta i tipi di dati da cui dipende la regola di analisi e indica il nome del tipo di dati a cui si fa riferimento nella dataTypes sezione del connettore. Ad esempio, se la query di ricerca dipende dai dati di questo connettore, è necessario specificare il tipo di dati come OnePasswordEventLogs_CL. Se la query di ricerca opera su una funzione/parser Kusto anziché sulla tabella (ad esempio Syslog, CommonEventFormato _CL), dataTypes è il nome/parser della funzione Kusto e non il nome della tabella.

Periodo di query

L'attributo queryPeriod rappresenta un periodo specificato durante il quale viene eseguita la query. Ad esempio: gli ultimi 3 giorni. Per questo attributo:

  • Usare il formato Linguaggio di query Kusto (KQL), TimeSpan ad esempio 3 giorni è 3d, 2 ore è 2h.
  • Assicurarsi che qualsiasi periodo di apprendimento o riferimento si trova entro questo intervallo di tempo.
  • Non usare un valore superiore al valore massimo supportato, ovvero 14d.

Questo campo è obbligatorio per le regole di analisi pianificate.

Frequenza query

L'attributo queryFrequency rappresenta la frequenza con cui viene eseguita la query. Per questo attributo:

  • Usare il formato KQL TimeSpan (ad esempio, 3 giorni è 3d, 2 ore è 2h).
  • Usare un queryFrequency oggetto minore o uguale a queryPeriod.
  • Seguire questa regola: se queryPeriod è maggiore o uguale a 2 giorni (2d), il queryFrequency valore non può essere minore di 1 ora (1h) e viene usato solo per i rilevamenti con gravità elevata.

Questo campo è obbligatorio per le regole di analisi pianificate.

Operator (Operatore)

L'attributo triggerOperator indica il meccanismo che attiva l'avviso. Ad esempio: maggiore di (gt) il set di numeri nell'attributo triggerThreshold (vedere Soglia trigger).

  • gt:Maggiore.
  • lt:Meno di.
  • eq: uguale a.

Questo campo è obbligatorio per le regole di analisi pianificate.

Soglia trigger

L'attributo triggerThreshold rappresenta la soglia che attiva l'avviso. Threshold è il valore a cui fa triggerOperator riferimento. I valori supportati includono qualsiasi numero intero compreso tra 0 e 10.000.

Ad esempio, se triggerOperator è impostato su gt e triggerThreshold è 1, l'avviso viene attivato quando un valore è maggiore di 1.

Questo campo è obbligatorio per le regole di analisi pianificate.

Tattiche

L'attributo tactics definisce l'oggetto MITRE ATT&CK tactics a cui si riferisce il rilevamento. Quando si definiscono le tattiche, gli utenti possono comprendere il contesto del rilevamento e come si inserisce nel panorama globale delle minacce. Per questo attributo:

  • ATT&CK Framework v13 è supportato.
  • I nomi non possono includere spazi. Ad esempio, InitialAccess o LateralMovement.

Questo campo è obbligatorio.

Tecniche pertinenti

L'attributo relevantTechniques definisce l'oggetto MITRE ATT&CK techniques a cui si riferisce il rilevamento. Quando si definiscono le tecniche, consente agli utenti di comprendere il contesto del rilevamento e il modo in cui rientra nel panorama globale delle minacce. Per questo attributo:

  • ATT&CK Framework v13 è supportato.
  • L'attributo corrisponde MITRE alle tattiche.
  • I nomi non possono includere spazi. Ad esempio, T1078 o T1078.001.

Questo campo è obbligatorio.

Query

L'attributo query definisce la logica di rilevamento. È consigliabile scrivere la query in KQL e assicurarsi che sia strutturata e facile da comprendere. È consigliabile creare una query efficiente ottimizzata per le prestazioni per garantire che possa essere eseguita su set di dati di grandi dimensioni senza influire sulle prestazioni. Assicurarsi che la query soddisfi i criteri seguenti.

Limitare la query a 10.000 caratteri. Se la sezione della query supera questo limite, è consigliabile ridurre il numero di caratteri. Un elenco statico di elementi usati per il confronto all'interno del corpo della query può causare un over del limite. È consigliabile spostare questi elenchi in una delle opzioni seguenti:

Ogni riga nel corpo della query deve avere almeno uno spazio all'inizio, ma due spazi sono standard per supportare la leggibilità.

Quando si invia una query per un tipo di dati non presente nella cartella Rilevamenti o query di ricerca, denominare la sottocartella che contiene i file YAML dopo la query della tabella. Ad esempio, se la query riguarda la AzureDevOpsAuditing tabella, creare una cartella denominata AzureDevOpsAuditing.

Definire nomi leggibili per costanti esplicite:

  • let FailedLoginEventID = 4625;
  • let countThreshold = 6;

È consigliabile usare i commenti per chiarire la query. Evitare di aggiungere commenti alla fine di una riga dell'istruzione di query. Aggiungere invece i commenti in una riga separata. Ad esempio:

  // Removing noisy processes for an environment, adjust as needed

Se si fa riferimento a un parser invece di un nome di tabella, assicurarsi di avere chiarezza nella descrizione includendo un commento accanto al riferimento alla funzione parser. Il parser deve prima essere importato nell'area di lavoro. In caso contrario, le query non lo riconoscono come valido.

Verificare che ogni campo dell'entità disponibile venga restituito a scopo di mapping. (Fare riferimento a Sezione Mapping di entità. Purificare la tabella restituita in modo che fornisca solo le proprietà che è necessario analizzare ulteriormente. Non è necessario un TimeGenerated filtro quando si usa un semplice lookback comando nell'intera query. Il queryPeriod valore in YAML controlla questo processo.

Per la base o l'esecuzione di un confronto cronologico, ad esempio il confronto tra oggi e i sette giorni precedenti, includere un filtro con limiti di tempo, | where TimeGenerated >= ago(lookback)ad esempio , perché il modello YAML attualmente non supporta più queryPeriod valori. Evitare di usare intervalli di tempo più brevi di un giorno, a meno che non esista un motivo specifico. Non è consigliabile impostare intervalli di tempo più lunghi di 14 giorni a causa di potenziali impatti sulle prestazioni.

Riepilogare quando necessario. Assicurarsi di includere il campo ora (in genere TimeGenerated) perché è necessario nel campo dell'entità. Includere sia i min() valori e max() come indicato di seguito: | summarize StartTime = max(TimeGenerated), EndTime = min(TimeGenerated). Usare le condizioni StartTime ed EndTime esclusivamente. Non assegnare i campi i nomi StartTimeUtc o EndTimeUtc, perché questi nomi possono essere in conflitto con le preferenze dell'esperienza utente.

Includere anche il maggior numero possibile di campi per aiutare l'utente a comprendere il contesto dell'avviso. È consigliabile includere almeno una delle entità primarie: Host, Accounto IP.

Questo campo è obbligatorio.

Impostazioni di raggruppamento di eventi

L'attributo eventGroupingSettings è correlato agli avvisi. Una regola di avviso può generare un avviso separato per ogni risultato della query. Ad esempio, una regola che identifica gli avvisi non Microsoft nel flusso di eventi potrebbe creare un avviso di Microsoft Sentinel per ogni avviso di origine.

  • Per generare un singolo avviso per tutti i risultati della query (impostazione predefinita), usare:

    eventGroupingSettings:
    aggregationKind: SingleAlert
    
  • Per generare un avviso separato per ogni risultato della query, usare:

    eventGroupingSettings:
    aggregationKind: AlertPerResult
    

Mapping di entità

L'attributo entityMappings è integrale quando si configurano regole di analisi pianificate. Arricchisce l'output della query (avvisi e eventi imprevisti) con informazioni essenziali che fungono da blocchi predefiniti di qualsiasi processo investigativo e azioni correttive che seguono.

entityType Rappresenta l'elenco standard di entità riconosciute da Microsoft Sentinel. Vedere i valori consentiti nella colonna Tipo di entità nella tabella Mapping entità.

Questo campo è obbligatorio.

Mapping campi

L'attributo fieldMappings rappresenta l'identificatore del campo nell'output della query corrispondente al tipo di entità. Vedere i valori consentiti nella colonna identificatori nella tabella Mapping entità. Per questo attributo:

  • Ogni modello può avere fino a 10 mapping di entità.

  • Ogni mapping di entità può avere fino a tre mapping dei campi, ovvero identificatori.

    entityMappings:
    - entityType: Account
      fieldMappings:
        - identifier: FullName
          columnName: AccountCustomEntity
    - entityType: Host
      fieldMappings:
        - identifier: FullName
          columnName: HostCustomEntity
    - entityType: IP
      fieldMappings:
        - identifier: Address
          columnName: ClientIP
    - entityType: DNS
      fieldMappings:
        - identifier: DomainName
          columnName: Name
    
    

Dettagli personalizzati

L'attributo customDetails integra i dati degli eventi negli avvisi, rendendoli visibili negli eventi imprevisti di sicurezza per una valutazione, un'indagine e una risposta più veloci. I dettagli personalizzati sono coppie chiave/valore di nomi di proprietà e colonne. Per altre informazioni, vedere Dettagli sugli eventi personalizzati di Surface negli avvisi in Microsoft Sentinel. È possibile definire fino a 20 dettagli personalizzati (ovvero coppie chiave/valore) per ogni modello.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Override dei dettagli dell'avviso

L'attributo alertDetailsOverride è un campo dinamico che è possibile usare per eseguire l'override dei dettagli dell'avviso. È possibile usare questo attributo per fornire più contesto o informazioni all'analista quando viene attivato l'avviso. Quando si usa questa funzionalità, assicurarsi che gli analisti ricevano informazioni pertinenti, inclusi i nomi di entità pertinenti, per facilitare una comprensione più rapida e più accurata dell'evento imprevisto. Le limitazioni includono:

  • È possibile includere un massimo di tre parametri in name o description.

  • L'oggetto name non deve superare i 256 caratteri, mentre description è limitato a 5.000 caratteri.

  • Il nome della colonna all'interno delle parentesi graffe deve corrispondere esattamente al nome della colonna prevista, senza spazi vuoti iniziali o finali , ad esempio , {{columnName}}non {{ columnName }}. Nell'esempio seguente, columnName1, columnName2dynamicTactic, e dynamicSeverity sono campi di output della query di avviso pianificata.

        alertDetailsOverride:
          alertDisplayNameFormat: free text with field names embedded using the format {{columnName}} # Up to 256 chars and 3 placeholders
          alertDescriptionFormat: free text with field names embedded using the format  {{columnName}} # Up to 5000 chars and 3 placeholders
          alertTacticsColumnName: dynamicTacticColumnName
          alertSeverityColumnName: dynamicSeverityColumnName
    
    
        alertDetailsOverride:
          alertDisplayNameFormat: rule {{columnName1}} display name
          alertDescriptionFormat: rule {{columnName2}} display name
          alertTacticsColumnName: dynamicTactic
          alertSeverityColumnName: dynamicSeverity
    

Versione

Quando un cliente crea una nuova query di ricerca dal modello, il modello version viene salvato. Se viene pubblicata una nuova versione del modello, i clienti ricevono una notifica nell'esperienza utente. Le versioni seguono il formato a, be c, in cui a è la versione principale, b è la versione secondaria ed c è la patch. Il campo della versione è l'ultima riga del modello.

Questo campo è obbligatorio.