Sviluppare una soluzione SIEM per Microsoft Sentinel

Le soluzioni Microsoft Sentinel consentono ai fornitori di software indipendenti (ISV) e ai partner di raggruppare un connettore dati con contenuti di sicurezza correlati, ad esempio cartelle di lavoro, regole analitiche, query di ricerca proattiva, playbook e parser, in un unico pacchetto installabile. I clienti possono quindi individuare e distribuire queste soluzioni dall'hub del contenuto Microsoft Sentinel e Azure Marketplace.

Learn

Prima di iniziare la creazione, completa i passaggi seguenti:

• Informazioni sulle Microsoft Sentinel. Informazioni sul funzionamento di Microsoft Sentinel, su che cos'è una soluzione e su come i clienti individuano e installano soluzioni dall'hub del contenuto. Vedere Che cos'è Microsoft Sentinel? ed esplorare il catalogo delle soluzioni.

• Identifica cosa creare. Decidere quale tipo di connettore si prevede di usare e quali tipi di contenuto SIEM si desidera includere nella soluzione. I tipi di contenuto SIEM includono cartelle di lavoro, regole analitiche, query di ricerca, playbook e parser. Per indicazioni sui tipi di connettore, vedere Creare un connettore dati .

• Esaminare la documentazione. Esaminare le linee guida generali per i contributi per Microsoft Sentinel e il wiki di Microsoft Sentinel GitHub.

• Diventa un Cloud Partner e crea un account editore. Le soluzioni vengono pubblicate tramite il Microsoft Partner Center. È necessario un account di pubblicazione prima di poter inviare la soluzione a Azure Marketplace. Per altre informazioni, vedere Creare un account marketplace commerciale nel Centro per i partner.

Costruire

Nella fase di compilazione si configura l'ambiente di sviluppo, quindi si crea il connettore e il contenuto della soluzione.

Configurare l'ambiente

Prima di compilare, configurare l'ambiente di sviluppo in modo da poter creare, testare e inviare il contenuto della soluzione.

Creare una copia tramite fork e clonare il repository

Per creare una copia tramite fork e clonare il repository Azure-Sentinel, seguire questa procedura:

1. In GitHub passare al repositoryAzure-Sentinel e selezionare Fork.

2. Clona il tuo fork sul computer locale.

   git clone https://github.com/<your-github-username>/Azure-Sentinel.git
   cd Azure-Sentinel
   

3. Aggiungere l'"upstream" remoto in modo da poter eseguire il pull delle modifiche più recenti:

   git remote add upstream https://github.com/Azure/Azure-Sentinel.git
   

Configurare un'area di lavoro di sviluppo/test

È necessaria un'area di lavoro Microsoft Sentinel funzionante per sviluppare e convalidare il connettore e il contenuto prima dell'invio. Consultare Configurare Microsoft Sentinel.

Dopo che l'area di lavoro è stata configurata, assegnare le autorizzazioni seguenti:

• Collaboratore di Microsoft Sentinel nell'area di lavoro per distribuire e gestire le risorse
• Log Analytics Contributor nell'area di lavoro per creare e gestire tabelle personalizzate e regole di raccolta dati (DCR)
• Collaboratore nel gruppo di risorse per distribuire i modelli ARM durante i test

Eseguire l'onboarding nel portale di Defender

Esegui l'onboarding dell'area di lavoro nel portale Defender per convalidare l'installazione della soluzione, garantire un'acquisizione dei dati senza problemi nella piattaforma unificata per le operazioni di sicurezza e testare il processo end-to-end prima della pubblicazione. Per altre informazioni, vedere Microsoft Sentinel nel portale di Microsoft Defender.

Creare una soluzione

Una soluzione Microsoft Sentinel è una cartella di file di contenuto e connettore che lo strumento di creazione pacchetti assembla in un pacchetto distribuibile. Creare la struttura di cartelle, aggiungere i file di creazione del pacchetto, quindi compilare ogni tipo di contenuto.

Creare la struttura di cartelle della soluzione in GitHub

Per configurare la struttura di cartelle della soluzione, seguire questa procedura:

1. Creare e passare a un nuovo ramo del fork. Usa un nome descrittivo, ad esempio add-<YourSolutionName>-solution:

   git checkout -b add-<YourSolutionName>-solution
   

2. Creare una cartella con il nome della soluzione in Solutions/:

   Solutions/<YourSolutionName>/
   ├── Data/
   │   └── Solution_<YourSolutionName>.json
   ├── SolutionMetadata.json
   ├── ReleaseNotes.md
   ├── Data Connectors/
   ├── Workbooks/
   ├── Analytic Rules/
   ├── Hunting Queries/
   ├── Playbooks/
   └── Parsers/
   

   File/Cartella	Obbligatorio	Contenuto
   Data/Solution_<YourSolutionName>.json	Obbligatorio	Manifesto della soluzione che elenca ogni file di contenuto nella soluzione e guida lo strumento di creazione del pacchetto
   SolutionMetadata.json	Obbligatorio	Metadati dell’editore e del marketplace: ID editore, ID offerta, categorie e informazioni di assistenza
   ReleaseNotes.md	Obbligatorio	Tabella della cronologia delle modifiche versionata, necessaria per ogni invio del pacchetto
   Data Connectors/	Opzionale	File JSON del connettore o codice Funzioni di Azure per i connettori basati su funzioni
   Workbooks/	Opzionale	Screenshot dei file JSON della cartella di lavoro e delle anteprime nere/bianche
   Analytic Rules/	Opzionale	Modelli di regole di analisi YAML
   Hunting Queries/	Opzionale	Modelli di query di ricerca YAML
   Playbooks/	Opzionale	File JSON del playbook e definizioni dei connettori personalizzati di App per la logica di Azure
   Parsers/	Opzionale	Definizioni YAML di funzioni/parser Kusto

   Le sottocartelle di contenuto sono facoltative. Creare solo le cartelle applicabili alla soluzione. Non è necessario includere ogni tipo di contenuto, ma soddisfare i requisiti minimi del contenuto migliora il punteggio di qualità.

   Per un esempio di struttura di cartelle completa, aprire la cartella Soluzioni/ nel repository ed esplorare alcune delle soluzioni esistenti.

Creare i file di pacchettizzazione della soluzione

Data/Solution_<YourSolutionName>.json

Questo file guida lo strumento di creazione pacchetti V3. Elenca ogni file di contenuto nella soluzione e controlla come vengono assemblati in mainTemplate.json. Ogni tipo di contenuto è una matrice. Aggiungere una voce per ogni file per ciascun contenuto di cui si dispone. Per altre informazioni sullo strumento di creazione pacchetti, vedere Creare un pacchetto della soluzione.

Nell'esempio seguente la soluzione ha due regole analitiche, quindi la "Analytic Rules" matrice ha due voci. Se, ad esempio, non stai creando alcun playbook, rimuovi completamente la chiave "Playbooks" dal file.

{
  "Name": "Contoso MyProduct",
  "Author": "Contoso - support@contoso.com",
  "Logo": "<img src=\"https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Logos/contoso.svg\" width=\"75px\" height=\"75px\">",
  "Description": "The Contoso MyProduct solution for Microsoft Sentinel enables you to ingest MyProduct logs into Microsoft Sentinel.",
  "BasePath": "C:/GitHub/Azure-Sentinel/Solutions/Contoso MyProduct",
  "Version": "1.0.0",
  "Metadata": "SolutionMetadata.json",
  "TemplateSpec": true,
  "Data Connectors": [
    "Data Connectors/ContosoMyProduct.json"
  ],
  "Workbooks": [
    "Workbooks/ContosoMyProductWorkbook.json"
  ],
  "Analytic Rules": [
    "Analytic Rules/ContosoMyProductSuspiciousLogin.yaml",
    "Analytic Rules/ContosoMyProductDataExfiltration.yaml"
  ],
  "Hunting Queries": [
    "Hunting Queries/ContosoMyProductThreatHunt.yaml"
  ],
  "Parsers": [
    "Parsers/ContosoMyProduct.yaml"
  ],
  "Playbooks": [
    "Playbooks/ContosoMyProduct-EnrichIncident/azuredeploy.json"
  ]
}

SolutionMetadata.json

Questo file contiene i metadati del marketplace e dell'editore usati durante la certificazione del Centro per i partner.

{
  "publisherId": "contoso",
  "offerId": "contoso-myproduct-sentinel",
  "firstPublishDate": "2026-06-15",
  "lastPublishDate": "2026-06-15",
  "providers": [
    "Contoso"
  ],
  "categories": {
    "domains": [
      "Security - Threat Intelligence"
    ]
  },
  "support": {
    "name": "Contoso",
    "email": "support@contoso.com",
    "tier": "Partner",
    "link": "https://support.contoso.com"
  }
}

publisherId e offerId provengono dall'offerta del Centro per i partner. support.tier deve essere "Partner" per le soluzioni ISV. Per i valori validi categories.domains , vedere il catalogo delle soluzioni.

ReleaseNotes.md

Il ReleaseNotes.md file registra la cronologia delle modifiche per la soluzione. Questo file viene convalidato durante i controlli della PR. Le voci mancanti o non valide comportano il rifiuto della richiesta pull.

La tabella deve avere esattamente tre colonne con questi nomi di intestazione esatti (inclusi i marcatori in grassetto):

| **Version** | **Date Modified (DD-MM-YYYY)** | **Change History** |
|---|---|---|
| 1.0.1 | 12-06-2026 | Updated analytic rule query to fix false positives. |
| 1.0.0 | 01-06-2026 | Initial solution release. |

Regole di convalida

• Formato della versione: X.Y.Z Non includere il prefisso v. Sono necessarie tutte e tre le parti.
• Le versioni sono elencate in ordine decrescente, con la più recente all'inizio della riga
• Formato data: DD-MM-YYYY con trattini (non YYYY-MM-DD)
• Le intestazioni di colonna devono corrispondere esattamente, inclusi i marcatori **bold**
• La cella Cronologia modifiche non deve essere vuota
• Aggiungere una nuova riga per ogni aggiornamento della versione, incluse le correzioni di errori di digitatura

La versione in ReleaseNotes.md deve corrispondere alla versione in SolutionMetadata.jsonData/Solution_*.json, e al nome file zip del pacchetto.

Aggiungere il logo

Posizionare il logo Logos/<YourProductName>.svg nella radice del repository. Fai riferimento ad esso in Data/Solution_<YourSolutionName>.json usando un tag HTML <img> che punta all'URL raw di GitHub:

"Logo": "<img src=\"https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/Logos/YourProductName.svg\" width=\"75px\" height=\"75px\">"

Il file SVG deve soddisfare i requisiti seguenti:

Un logo pulito usa solo gli attributi fill e stroke direttamente sugli elementi path, senza attributi id a meno che non facciano riferimento a un elemento <defs>. Per un esempio minimamente valido, vedi Logos/XBOW.svg.

Creare un connettore dati

Se si sta creando un connettore usando il flusso di lavoro dell'agente di intelligenza artificiale, vedere Creare connettori personalizzati usando l'agente di intelligenza artificiale in Microsoft Sentinel anziché seguire la procedura seguente.

Scegliere il tipo di connettore

Microsoft Sentinel supporta diversi tipi di connettore, molti dei quali usano Codeless Connector Framework (CCF). Scegliere quella più adatta all'origine dati e all'esperienza del cliente desiderata.

Compilare la definizione del connettore

I passaggi dettagliati della build variano in base a ogni tipo di connettore. I passaggi dettagliati della build variano in base a ogni tipo di connettore. Seguire le indicazioni per il tipo scelto dalla tabella dei tipi di connettore. .

Usare le soluzioni seguenti nel repository Azure-Sentinel come riferimenti per ogni tipo di connettore.

Quando il file JSON del connettore è completo, collocalo nella sottocartella Data Connectors/ della cartella della soluzione e assegnagli il nome ProviderNameApplianceName.json (senza spazi).

Testare il connettore

Creare il contenuto

Oltre al connettore dati, arricchire la soluzione con contenuto SIEM che consente ai clienti di ottenere valore immediato dai dati. I contenuti SIEM aggiuntivi comprendono:

• Cartelle di lavoro
• Regole analitiche
• Ricerca di query
• Playbook
• Parser

Questo contenuto è facoltativo ma consigliato. Per i requisiti minimi e l'assegnazione dei punteggi di qualità, vedere Microsoft Sentinel linee guida sulla qualità della soluzione.

Creare cartelle di lavoro

Le cartelle di lavoro sono dashboard e visualizzazioni che consentono ai clienti di comprendere i dati. Per creare una cartella di lavoro, vedere Creare cartelle di lavoro per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout della cartella di lavoro, vedere gli esempi di riferimento seguenti nel repository Azure-Sentinel:

• Microsoft Entra ID - AzureActiveDirectorySignins.json
• XBOW - XBOW.json
• PaloAlto-PAN-OS - PaloAltoOverview.json

Creare regole di analisi

Le regole analitiche sono modelli che rilevano le minacce nei dati. Ogni regola è un file YAML. Per creare una regola analitica, vedere Creare regole di analisi per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout delle regole di analisi, vedere gli esempi di riferimento seguenti nel repository di Azure-Sentinel:

• Microsoft Entra ID - FailedLogonToAzurePortal.yaml
• Falco CrowdStrike - CriticalOrHighSeverityDetectionsByUser.yaml
• XBOW - XbowCriticalHighFindings.yaml

Creare query di ricerca

Le query di ricerca sono modelli che consentono ai clienti di cercare in modo proattivo le minacce nei dati. Vengono visualizzati nella scheda Ricerca perché gli analisti possano eseguirli manualmente. Condividono la stessa struttura YAML delle regole analitiche, ma non sono automatizzate; I campi di esecuzione programmata non si applicano e causano un fallimento della revisione se inclusi. Per creare una query di ricerca, vedere Creare query di ricerca per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout delle query di ricerca, vedere gli esempi di riferimento seguenti nel repository di Azure-Sentinel:

• Okta Single Sign-On - AdminPrivilegeGrant.yaml
• PaloAlto-PAN-OS - Palo Alto - segnalazione di potenziale beaconing. yaml
• Firewall di Azure - Firewall di Azure - Prima volta da IP di origine a destinazione tramite porta.yaml

Creare playbook

I playbook sono flussi di lavoro automatizzati per la risposta che aiutano i clienti a rispondere alle minacce presenti nei propri dati. Ogni playbook è un flusso di lavoro di App per la logica di Azure esportato come modello ARM. I due file obbligatori sono azuredeploy.json e readme.md, inseriti in Solutions/<YourSolutionName>/Playbooks/<PlaybookName>/. Per creare un playbook, vedi Creare playbook per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout dei playbook, vedere gli esempi di riferimento seguenti nel repository Azure-Sentinel:

• Microsoft Entra ID - Block-AADUser (incidente + allarme + attivazione di entità)
• CrowdStrike Falcon - CrowdStrike_Base (Key Vault + schema base del playbook)
• Okta Single Sign-On - OktaCustomConnector (modello ARM per connettore personalizzato)

Creare parser

Un parser è una funzione Kusto salvata nell'area di lavoro Log Analytics che si colloca prima dei dati di log grezzi e li normalizza in campi puliti e interrogabili. Invece di scrivere la logica di estrazione dei campi in ogni query, i clienti chiamano l'alias del parser una volta e ottengono risultati strutturati. I parser vengono definiti come file YAML e distribuiti automaticamente quando un cliente installa la soluzione. Per creare un parser, vedere Creare parser per Microsoft Sentinel.

Per indicazioni sulla progettazione e il layout del parser, vedere gli esempi di riferimento seguenti nel repository di Azure-Sentinel:

• Cloudflare CCF - Cloudflare.yaml
• Falco CrowdStrike - Replicatore CrowdStrike V2.yaml

Prova il pacchetto

Il test segue il pacchetto → distribuire → abilitare → ciclo di convalida . Il ciclo è lo stesso indipendentemente dalla quantità di contenuto creato. Lo strumento di creazione pacchetti V3 converte i file della soluzione in un modello arm distribuibile (mainTemplate.json). Distribuisci il modello nell'area di lavoro di sviluppo di Microsoft Sentinel, abilita ciascun tipo di contenuto e verifica che funzioni prima di inviare una PR.

Ripetere questo ciclo durante la compilazione. Non è necessario completare tutti i tipi di contenuto prima di iniziare il test. Crea il pacchetto e distribuiscilo man mano che completi ciascun tipo di contenuto, verifica che funzioni, quindi aggiungi altro contenuto e crea nuovamente il pacchetto.

Se la soluzione include un connettore dati, testare il connettore prima di compilare contenuto dipendente, ad esempio regole di analisi e cartelle di lavoro. Tutto il contenuto SIEM dipende dal flusso di dati nelle tabelle corrette con lo schema corretto. Se il connettore non funziona o lo schema non corrisponde a quello previsto dalle regole, sarà necessario rielaborare il contenuto dipendente. Assicurarsi che i dati vengano trasmessi per primi per risparmiare tempo.

Imballare la tua soluzione

Dopo aver sviluppato e testato i componenti della soluzione Microsoft Sentinel, la creazione dei pacchetti è il passaggio critico successivo del ciclo di vita della soluzione. Lo strumento di creazione di pacchetti consolida tutto il contenuto della soluzione, ovvero connettori dati, parser, cartelle di lavoro, regole analitiche, query di ricerca, Azure connettori personalizzati delle app per la logica e playbook, in un formato standardizzato per la distribuzione. Per altre informazioni, vedere Creare un pacchetto di una soluzione SIEM per Microsoft Sentinel.

Vai al mercato

Quando si seleziona Go live, la soluzione passa attraverso un controllo di certificazione finale prima di diventare disponibile pubblicamente. Dopo la certificazione, la soluzione viene elencata nell'hub del contenuto Microsoft Sentinel e visibile nell'area di lavoro Sentinel di ogni tenant del cliente in Hub contenuto. È anche rilevabile su Azure Marketplace. La soluzione è ora disponibile per tutti i clienti Microsoft Sentinel. Per maggiori informazioni, consulta Pubblica soluzioni SIEM su Microsoft Sentinel.

Da questo momento in poi, qualsiasi aggiornamento alla soluzione, ad esempio modifiche al contenuto, correzioni di bug e incrementi di versione, richiede una nuova pull request su GitHub, una nuova versione del pacchetto e un nuovo invio al Partner Center con il file ZIP aggiornato. Per tenere traccia dello stato e dei problemi di supporto post-pubblicazione, vedere Tenere traccia della soluzione dopo la pubblicazione nel Centro per i partner.

Contenuti correlati

• Creare un pacchetto di una soluzione SIEM per Microsoft Sentinel.
• Creare un connettore senza codice per Microsoft Sentinel
• catalogo delle soluzioni Microsoft Sentinel
• Linee guida generali sui contributi per Microsoft Sentinel