Daily Defender News
Aboutmerill.net
Microsoft Sentinel
Cloud and workloads

Develop a SIEM solution for Microsoft Sentinel

4 September 2026Doc update+413 / −0 lines

In brief

The new guide covers the ISV solution lifecycle: learning, building, testing, publishing, previewing, and go-to-market. It explains packaging connectors with security content and lists development workspace permissions and Defender portal onboarding steps.

What Defender admins need to know

Administrators supporting solution development may need to provide a Sentinel workspace, assign the documented permissions, and onboard it to the Defender portal.

Summaries are generated from the documentation change itself.

Documentation change

View full page diffView on Microsoft Learn

The comparison below shows only the changed extract. Use the full-page view for complete context.

new file mode 100644

title: Develop a SIEM solution for Microsoft Sentinel description: Learn how to develop a SIEM solution for Microsoft Sentinel. ms.service: microsoft-sentinel ms.subservice: sentinel-siem author: EdB-MSFT ms.author: edbaynash ms.reviewer: rmoriarty ms.topic: concept-article ms.date: 06/30/2026 ai-usage: ai-assisted ms.custom: msecd-doc-authoring-1012

Develop a SIEM solution for Microsoft Sentinel

Microsoft Sentinel solutions let independent software vendors (ISVs) and partners bundle a data connector with related security content such as workbooks, analytic rules, hunting queries, playbooks, and parsers into a single, installable package. Customers can then discover and deploy these solutions from the Microsoft Sentinel content hub and Azure Marketplace.

PhaseActivities
LearnLearn about Sentinel, identify what to build, create publisher accounts, set up your environment
BuildProvision your environment, build your connector and solution content
TestPackage your solution, test it, submit a pull request, and resolve feedback
PublishCreate an offer in Partner Center, test the preview, and go live
PreviewInform customers, resolve support issues, monitor for four weeks
Go to MarketRemove the preview flag, listen to customers, enhance your solution

Learn

Before you begin building, complete the following steps:

Build

In the build phase, you set up your development environment, then create your connector and solution content.

Provision your environment

Before building, configure your development environment so you can author, test, and submit solution content.

Fork and clone the repository

To fork and clone the Azure-Sentinel repository, follow these steps:

  1. In GitHub, go to the Azure-Sentinel repository and select Fork.

  2. Clone your fork to your local machine:

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

  3. Add the upstream remote so you can pull in the latest changes:

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

Set up a dev/test workspace

You need a working Microsoft Sentinel workspace to develop and validate your connector and content before submitting. See Onboard Microsoft Sentinel.

After your workspace is provisioned, assign the following permissions:

  • Microsoft Sentinel Contributor on the workspace to deploy and manage resources
  • Log Analytics Contributor on the workspace to create and manage custom tables and data collection rules (DCRs)
  • Contributor on the resource group to deploy ARM templates during testing

Onboard to the Defender portal

Onboard your workspace to the Defender portal in order to validate your solution installation, ensure seamless ingestion into the Unified Security Operations Platform, and test end-to-end before publishing. For more information, see Microsoft Sentinel in the Microsoft Defender portal.

Build a solution

A Microsoft Sentinel solution is a folder of connector and content files that the packaging tool assembles into a deployable package. Create the folder structure, add the packaging files, then build each content type.

Create your solution folder structure in GitHub

To set up your solution's folder structure, follow these steps:

  1. Create and switch to a new branch on your fork. Use a descriptive name such as add-<YourSolutionName>-solution:

    git checkout -b add-<YourSolutionName>-solution

  2. Create a folder with your solution name under Solutions/:

    Solutions/<YourSolutionName>/
├── Data/
│   └── Solution_<YourSolutionName>.json
├── SolutionMetadata.json
├── ReleaseNotes.md
├── Data Connectors/
├── Workbooks/
├── Analytic Rules/
├── Hunting Queries/
├── Playbooks/
└── Parsers/
    File / FolderRequiredContents
    Data/Solution_<YourSolutionName>.jsonRequiredSolution manifest that lists every content file in the solution and drives the package creation tool
    SolutionMetadata.jsonRequiredPublisher and marketplace metadata: publisher ID, offer ID, categories, and support info
    ReleaseNotes.mdRequiredVersioned change history table, required for every package submission
    Data Connectors/OptionalConnector JSON files, or Azure Functions code for function-based connectors
    Workbooks/OptionalWorkbook JSON files and black/white preview screenshots
    Analytic Rules/OptionalYAML analytic rule templates
    Hunting Queries/OptionalYAML hunting query templates
    Playbooks/OptionalPlaybook JSON files and Azure Logic Apps custom connector definitions
    Parsers/OptionalYAML Kusto function/parser definitions

    The content subfolders are optional. Only create the folders that apply to your solution. You aren't required to include every content type, but meeting the minimum content requirements improves your quality score.

    For an example of a complete folder structure, open the Solutions/ folder in the repository and browse some of the existing solutions.

Create the solution packaging files

Data/Solution_<YourSolutionName>.json

This file drives the V3 packaging tool. It lists every content file in your solution and controls how they're assembled into mainTemplate.json. Each content type is an array. Add one entry per file for each piece of content you have. For more information on the packaging tool, see Package your solution.

In the following example, the solution has two analytic rules, so the "Analytic Rules" array has two entries. If for example, you aren't creating any playbooks, remove the "Playbooks" key from the file entirely.

{
  "Name": "Contoso MyProduct",
  "Author": "Contoso - [email protected]",
  "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"
  ]
}
FieldNotes
NameAlphanumeric and spaces only. No hyphens, underscores, or symbols.
AuthorFormat: Organization - [email protected]
LogoHTML <img> tag pointing to your logo SVG at the raw GitHub URL under Logos/. See Add your logo for file requirements and validation rules.
BasePathYour local repo path to the solution folder. Not used at runtime.
VersionMust match SolutionMetadata.json and mainTemplate.json.
TemplateSpecCheck existing solutions in the repo for the correct value for your connector type.
Content arraysOne entry per file. Add all files for a given content type to its array. Remove the key entirely if you have no content of that type. Don't leave an empty array. Paths are relative to BasePath.

SolutionMetadata.json

This file contains the marketplace and publisher metadata used during Partner Center certification.

{
  "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": "[email protected]",
    "tier": "Partner",
    "link": "https://support.contoso.com"
  }
}

publisherId and offerId come from your Partner Center offer. support.tier should be "Partner" for ISV solutions. For valid categories.domains values, see the solutions catalog.

FieldNotes
publisherIdYour Partner Center publisher ID.
offerIdYour Partner Center offer ID. This value is set when you create the offer in Partner Center and cannot be changed after creation. The value must match the Offer ID in Partner Center exactly. A mismatch causes certification failure. See Package a SIEM solution for Microsoft Sentinel for how the offer ID is created.
firstPublishDateISO 8601 date. Set once and don't change it after initial publishing.
lastPublishDateUpdate to match each new release.
providersArray of vendor/product provider names.
categories.domainsOne or more domain categories from the solutions catalog.
categories.verticalsOptional industry verticals. Omit if not applicable.
support.tier"Partner" for ISV, "Microsoft" for Microsoft, "Community" for community.

ReleaseNotes.md

The ReleaseNotes.md file records the change history for your solution. This file is validated during PR checks. Missing or malformed entries cause PR rejection.

The table must have exactly three columns with these exact header names (including the bold markers):

| **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. |

Validation rules

  • Version format: X.Y.Z Don't include a v prefix. All three parts are required.
  • Versions are listed in descending order with the newest in the row first
  • Date format: DD-MM-YYYY with hyphens (not YYYY-MM-DD)
  • Column headers must match exactly, including the **bold** markers
  • Change History cell must not be empty
  • Add a new row for every version bump, including typo fixes

The version in ReleaseNotes.md must match the version in SolutionMetadata.json, Data/Solution_*.json, and the Package zip filename.

Add your logo

Place your logo at Logos/<YourProductName>.svg in the root of the repository. Reference it in Data/Solution_<YourSolutionName>.json using an HTML <img> tag pointing to the raw GitHub URL:

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

The SVG file must meet the following requirements:

CheckRequirement
File format.svg extension only. PNG, JPEG, or other formats aren't allowed.
File size≤ 5 KB
style= attributeNot allowed. Remove all inline style="..." attributes from elements.
cls= attributeNot allowed
xmlns:xlink namespaceNot allowed. Remove from the <svg> root element.
data-name attributeNot allowed. Illustrator adds these attributes as layer names. They must be removed.
xlink:hrefNot allowed. Use inline SVG paths instead of embedded image references.
<title> tagNot allowed. Remove any <title>...</title> elements.
Embedded PNGNot allowed. Any <image> elements referencing .png files are rejected
Element id valuesIf any id="..." attributes are present, every value must be a valid UUID (for example, id="a1b2c3d4-e5f6-4789-abcd-0123456789ab"). Human-readable IDs like id="Layer_1" fail. All IDs must be unique within the file.

A clean logo uses only fill and stroke attributes directly on path elements, with no id attributes unless referencing a <defs> element. For a minimal valid example, see Logos/XBOW.svg.

Build a data connector

If you're building a connector using the AI agent workflow, see Create custom connectors using AI agent in Microsoft Sentinel instead of following the steps below.

Choose your connector type

Microsoft Sentinel supports several connector types, many of which use the Codeless Connector Framework (CCF). Choose the one that best fits your data source and desired customer experience.

Connector typeBest forGuidance
CCF pollingREST APIs that your connector calls on a schedule. Fully SaaS, with no agent or VM required. Includes built-in health monitoring and full Microsoft support.Create a codeless connector for Microsoft Sentinel
CCF pushData sources that push logs to a Microsoft Sentinel endpoint.Microsoft Sentinel CCF push connectors (preview)
CCF blobData sources that write logs to Azure Blob Storage or Azure Data Lake Storage.Set up the Azure Storage connector
CCF GCPData sources that write logs to Google Cloud Storage.GCP data connector reference
CEFOn-premises appliances that emit Common Event Format logs. Data lands in the well-known CommonSecurityLog table.Connect CEF-formatted logs
SyslogOn-premises appliances that can only emit raw Syslog. Least preferred; queries require KQL parsing.Collect syslog data sources
Azure Functions(legacy)REST APIs when CCF isn't viable due to technical limitations. Use only as a last resort. Contact [email protected] before building to confirm eligibility.Azure Functions connector template
Build the connector definition

Detailed build steps are specific to each connector type. Detailed build steps are specific to each connector type. Follow the guidance for your chosen type from the connector type table. .

Use the following solutions in the Azure-Sentinel repository as references for each connector type.

Connector typeReference example
CCF pollingSentinelOne CCF polling connector
CCF pushJamf Protect CCF push connector
CCF blobCloudflare CCF blob connector
CCF GCPGoogle Cloud Platform audit logs connector
CEF / SyslogCisco ISE CEF and Syslog connectors

When your connector JSON is complete, place it in the Data Connectors/ subfolder of your solution folder and name it ProviderNameApplianceName.json (no spaces).

Test your connector

Build your content

In addition to the data connector, enrich your solution with SIEM content that helps customers get immediate value from your data. Additional SIEM content includes:

  • Workbooks
  • Analytic rules
  • Hunting queries
  • Playbooks
  • Parsers

This content is optional but recommended. For minimum requirements and quality scoring, see Microsoft Sentinel solution quality guidelines.

Create workbooks

Workbooks are dashboards and visualizations that help customers understand their data. To create a workbook, see Create workbooks for Microsoft Sentinel.

See the following reference examples in the Azure-Sentinel repository for guidance on workbook design and layout:

Create analytic rules

Analytic rules are templates that detect threats in your data. Each rule is a YAML file. To create an analytic rule, see Create analytic rules for Microsoft Sentinel.

See the following reference examples in the Azure-Sentinel repository for guidance on analytic rule design and layout:

Create hunting queries

Hunting queries are templates that help customers proactively search for threats in their data. They appear in the Hunting blade for analysts to run manually. They share the same YAML structure as analytic rules, but are not automated; scheduled execution fields don't apply and cause a review failure if included. To create a hunting query, see Create hunting queries for Microsoft Sentinel.

See the following reference examples in the Azure-Sentinel repository for guidance on hunting query design and layout:

Create playbooks

Playbooks are automated response workflows that help customers respond to threats in their data. Each playbook is an Azure Logic Apps workflow exported as an ARM template. The two required files are azuredeploy.json and readme.md, placed in Solutions/<YourSolutionName>/Playbooks/<PlaybookName>/. To create a playbook, see Create playbooks for Microsoft Sentinel.

See the following reference examples in the Azure-Sentinel repository for guidance on playbook design and layout:

Create parsers

A parser is a Kusto function saved to your Log Analytics workspace that sits in front of raw log data and normalizes it into clean, queryable fields. Instead of writing field extraction logic in every query, customers call the parser alias once and get structured results. Parsers are defined as YAML files and deployed automatically when a customer installs your solution. To create a parser, see Create parsers for Microsoft Sentinel.

See the following reference examples in the Azure-Sentinel repository for guidance on parser design and layout:

Test your package

Testing follows the package → deploy → enable → validate cycle. The cycle is the same regardless of how much content you've built. The V3 packaging tool converts your solution files into a deployable ARM template (mainTemplate.json). Deploy the template to a Microsoft Sentinel development workspace, enable each content type, and confirm it works before submitting a PR.

Repeat this cycle as you build. You don't need to finish all content types before you start testing. Package and deploy as you complete each content type, verify it works, then add more content and repackage.

If your solution includes a data connector, test the connector first before building dependent content like analytic rules and workbooks. All SIEM content depends on data flowing into the right tables with the correct schema. If the connector isn't working or the schema doesn't match what your rules expect, you'll need to rework the dependent content. Make sure the data is flowing first to save time.

Package your solution

After you've developed and tested your Microsoft Sentinel solution components, packaging is the next critical step in the solution lifecycle. The packaging tool consolidates all your solution content—data connectors, parsers, workbooks, analytic rules, hunting queries, Azure Logic apps custom connectors, and playbooks—into a standardized format for deployment. For more information, see Package a SIEM solution for Microsoft Sentinel.

Go to market

When you select Go live, the solution goes through a final certification check before becoming publicly available. After certification, the solution is listed in the Microsoft Sentinel content hub and visible in every customer tenant's Sentinel workspace under Content hub. It'ss also discoverable in the Azure Marketplace. The solution is now available to all Microsoft Sentinel customers. For more information, see Publish SIEM solutions to Microsoft Sentinel.

From this point, any update to the solution, such as content changes, bug fixes, and version bumps requires a new GitHub PR, a new package version, and a new Partner Center submission with the updated zip. For tracking post-publish status and support issues, see Track your solution after publishing in Partner Center.

Related content