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 includono:

  • Rilevamento delle intrusioni: identificare tentativi di accesso non autorizzati o attività di accesso sospette che potrebbero indicare una potenziale violazione.
  • Rilevamento di malware: monitorare le firme di 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.
  • Insider Threats: identificare il comportamento anomalo degli utenti interni, come l'accesso a dati sensibili al di fuori delle normali ore o schemi.
  • 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 potrebbe 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 . Usa questi esempi di regole di analisi come modelli per creare le tue:

Le sezioni seguenti forniscono una descrizione dettagliata dei diversi attributi di una regola di analisi.

Regola di esempio per l'analisi

Di seguito è riportata una regola di analisi di esempio in formato YAML.

id: aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
name: Anomalous login from unknown IP
description: |
  Identifies login attempts from IP addresses not seen in the past 14 days.
severity: Medium
requiredDataConnectors:
  - connectorId: ContosoMyProduct
    dataTypes:
      - ContosoMyProduct_CL
queryFrequency: 1h
queryPeriod: 14d
triggerOperator: gt
triggerThreshold: 0
tactics:
  - InitialAccess
relevantTechniques:
  - T1078
status: Available
query: |
  ContosoMyProduct_CL
  | where TimeGenerated > ago(1h)
  | where EventType == "Login"
  | summarize count() by SrcIpAddr, UserName
  | extend Name = tostring(split(UserName, '@', 0)[0])
  | extend UPNSuffix = tostring(split(UserName, '@', 1)[0])
entityMappings:
  - entityType: Account
    fieldMappings:
      - identifier: Name
        columnName: Name
      - identifier: UPNSuffix
        columnName: UPNSuffix
  - entityType: IP
    fieldMappings:
      - identifier: Address
        columnName: SrcIpAddr
version: 1.0.0
kind: Scheduled

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.

Kind

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. Per le regole NRT, omettere queryFrequency, queryPeriod, triggerOperator e triggerThreshold.

Questo campo è obbligatorio.

Name

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:

  • Utilizza la maiuscola in formato frase.
  • Non termina con un punto.
  • Ha una lunghezza consigliata inferiore a 50 caratteri, e un massimo assoluto di 100 caratteri.
  • Evita le parole "sospetto" e "indiziato". Usa invece "Imprevisto", "Anomalo" o "Raro".

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 in formato frase.
  • Inizia con "Questa ricerca cerca" o "Identifica".
  • È diverso da e più descrittivo rispetto al campo nome.
  • Lunghezza massima di 255 caratteri.
  • È composto da cinque frasi o meno.
  • Non descrive l'origine dati (connettore o tipo di dati).
  • Non fornisce una spiegazione tecnica per il linguaggio di query.
  • Usa solo caratteri ASCII. Le lineette em, le virgolette tipografiche e altri caratteri non ASCII non superano la convalida.

Questo campo è obbligatorio.

Severity

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 delle minacce ampio accesso per compiere azioni nell'ambiente.

Note

Le impostazioni predefinite del livello di gravità non sono una garanzia del livello di impatto corrente né dell'impatto ambientale. 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.

Condizione

L'attributo status indica la prontezza per la produzione della regola:

  • Available: regole pronte per l'uso in produzione.
  • InPreview: regole beta.
  • Deprecated: regole in fase di eliminazione graduale.

Connettori dati necessari

L'attributo requiredDataConnectors rappresenta l'elenco dei connettori dati necessari affinché la regola funzioni correttamente, incluse le origini dati contro cui viene eseguita la query della regola. Se non è presente alcun mapping del connettore dati attuale, è 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 connectorID come 1PasswordCCPDefinition.

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 interrogazione

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

  • Utilizzare il formato del 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 delle interrogazioni

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 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 numero impostato nell'attributo triggerThreshold (vedere Soglia di attivazione).

  • gt: maggiore di.
  • lt: minore di.
  • eq: uguale a.

Questo campo è obbligatorio per le regole di analisi pianificate.

Soglia di attivazione

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 v16 è supportato.
  • I nomi usano PascalCase e non possono includere spazi. Ad esempio: InitialAccess o LateralMovement.
  • È possibile definire un massimo di cinque tattiche per ogni regola.
  • I valori validi sono: Reconnaissance, ResourceDevelopmentInitialAccess, Execution, Persistence, PrivilegeEscalation, DefenseEvasion, CredentialAccessDiscoveryLateralMovementCollectionCommandAndControlExfiltratione .Impact

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 v16 è supportato.
  • Ogni tecnica deve appartenere ad almeno uno degli elementi elencati tactics.
  • I nomi non possono includere spazi. Ad esempio: T1078 o T1078.001.
  • È possibile definire al massimo 10 tecniche per regola.

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. Assicurati 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 superamento 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 che non è presente nella cartella Rilevamenti o nella cartella delle Query di indagine, nominare la sottocartella che contiene i file YAML con il nome della tabella interrogata. 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. Per 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 alla sezione mappature di entità.) Sanitizzare la tabella restituita in modo che fornisca solo le proprietà che devi 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 stabilire un baseline o eseguire un confronto storico, come ad esempio il confronto tra oggi e i sette giorni precedenti, includere un filtro con limiti di tempo, come | where TimeGenerated >= ago(lookback), perché attualmente il modello YAML non supporta più valori queryPeriod. 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 il valore min() che max() come segue: | 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.

I nomi delle colonne nella tabella personalizzata devono usare camelCase (ad esempio, SrcIpAddr o UserName).

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. I tipi supportati includono Account, HostIP, URL, File, Process, DNS, AzureResourceFileHashRegistryKeyRegistryValueSecurityGroupMailboxe .MailMessage Consultare i valori consentiti nella colonna Tipo di entità nella tabella di mapping delle entità.

Questo campo è obbligatorio.

Mappature dei campi

L'attributo fieldMappings rappresenta l'identificatore del campo nell'output della query corrispondente al tipo di entità. Consultare i valori consentiti nella colonna degli identificatori nella Tabella di mapping delle entità. Per questo attributo:

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

  • Ogni mapping di entità può avere fino a tre mapping di campo (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. I nomi delle chiavi devono contenere 20 caratteri o meno.

    customDetails:
      Computers: Computer
      IPs: ComputerIP

Override dei dettagli di 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 bianchi 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

Configurazione degli eventi imprevisti

L'attributo incidentConfiguration controlla la creazione degli eventi imprevisti e il raggruppamento degli avvisi in eventi imprevisti. Usarlo per definire il modo in cui gli avvisi generati da questa regola vengono aggregati in eventi imprevisti.

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.

  • Last updated on