What MISP to Microsoft Sentinel integration does for your SOC
MISP and Microsoft Sentinel integration moves indicators that your SOC curates in MISP into Microsoft Sentinel, where they can be matched against security logs and used in analytics rules. This topic covers two methods: misp2sentinel, a connector project that pushes MISP data into Sentinel, and the STIX objects upload API, which sends STIX-formatted indicators to the threat intelligence data in your Sentinel workspace. For a SOC that already maintains indicators in MISP, the practical gain is that the intelligence analysts curate is the same intelligence the detection layer uses, without manual copying between two tools and without a second, drifting copy of the list.
This page is a planning and build guide for the team that will run the integration. Connector behavior, required permissions, supported attribute types and API request fields change over time, so confirm exact details against the current misp2sentinel project documentation and Microsoft's Sentinel documentation before you settle on a design. Treat each design choice described here as a question to answer for your own environment. Confirm which ingestion path your Sentinel workspace and licensing currently support, which MISP version and connector version you will pin, and how each one is upgraded and tested over its lifecycle.
DeployOpen implements the integration inside your own MISP instance and your own Azure tenant. The MISP server, the connector runtime, the Microsoft Entra app registration and the Sentinel workspace remain under your administrators' control, and the permissions are granted within your tenant. Before work starts, ask for written confirmation of where the connector runs, which identity it authenticates as, which role that identity holds in MISP and Sentinel, and where the client secret or certificate used for authentication is stored and rotated. These answers determine who can revoke access and how quickly you can do it during an incident.
Your team should settle three decisions before the build starts. The first is the selection rule: distribution levels, tags, sharing groups and the to_ids flag decide which attributes leave MISP, and exporting everything tends to fill Sentinel with stale, low-confidence or out-of-scope indicators. The second is the approval owner, the person who signs off that an event is eligible for export. The third is expiry: agree how a revoked, expired or retracted indicator is removed from Sentinel as well as from MISP, and who checks that removal happened. Each decision changes both the build and the operating procedure, so record them in the scope before quoting begins.
What you need in place before connecting MISP to Sentinel
Each item below must be settled before the connector runs, and most of them sit with different teams. The MISP instance, the Microsoft Entra tenant, the Sentinel workspace and the host that runs misp2sentinel each need an owner and a confirmed setting. Check them in this order so that a failed upload is never the first test of any one item.
MISP 2.5 instance
MISP 2.5 is the version the project recommends for new deployments, and MISP 2.4 is end of life with security fixes only, so do not build a new connector against 2.4. The project lists an Ubuntu 24.04 installer as the recommended path, with Docker images, Ansible roles and RPM packages as alternatives. Pick one path, record the exact release you deploy, and confirm with the misp2sentinel project which 2.5 point release it expects.
Dedicated automation user and API key
Create a MISP user for the connector alone, with its own role and organization, so that its read access and activity log stay separate from people's accounts. Generate the API key for that user and store it in your secrets manager, keeping it out of shared scripts. Confirm which role permissions the connector needs to read the events and attributes it exports, and confirm the key can be rotated without interrupting the Sentinel upload schedule.
Sentinel workspace and identifiers
Identify the Log Analytics workspace that will receive the indicators, and record its workspace ID along with the subscription and resource group that contain it. Record the Microsoft Entra tenant ID that owns the workspace, because the connector authenticates against that tenant. Confirm that the workspace sits in the tenant and region your security operations team monitors and that Microsoft Sentinel is enabled on it.
Entra app registration and consent
The connector authenticates to the Sentinel upload API through a Microsoft Entra app registration. Confirm with the tenant administrator who may create app registrations, which API permissions the upload path requires, and whether an administrator must grant tenant-wide consent before the connector can run. Ask Microsoft for the exact permission names at build time, and start the approval request early because it often takes longer than the technical setup.
Network path to MISP and Azure
The connector host must reach the MISP API over HTTPS at the address your MISP instance publishes, and it must reach the Azure endpoints used for sign-in and for Sentinel ingestion. Test both paths from the actual host, including any proxy or egress firewall rules, and confirm that DNS resolves the MISP name from that network. Ask your network team to document the allowed destinations so the connector does not fail silently after a firewall change.
Tooling host with Python
misp2sentinel runs on a host you control, and that host needs a supported Python runtime plus the packages listed in the project's requirements. Confirm the exact Python version and dependencies with the project at build time, then plan a pinned virtual environment so that upgrades happen deliberately. Place the host under the same patching, logging and access controls as your other integration services, and keep its configuration and secrets outside the repository checkout.
How misp2sentinel and the STIX upload API move indicators
The data path has three stages: a scheduled job queries MISP through its API, converts the selected attributes into STIX objects, and submits them to the Microsoft Sentinel threat intelligence upload interface under the Entra app identity. Each stage can drop, duplicate or mistype indicators, so your team should know which component owns each step before anything is scheduled. MISP documents restSearch in its OpenAPI-described API, and the bundled PyMISP library wraps the same calls. The job should authenticate with an API key belonging to a dedicated MISP user, because that user's visibility determines which events and attributes the job can ever see.
The export stage determines what Sentinel receives. MISP exports STIX 1 and STIX 2 among its other formats, so the job must choose one of them. The version must match what the Sentinel upload interface accepts, and that acceptance rule should be confirmed in current Microsoft documentation and tested in a non-production workspace before the build starts. A mismatch can produce rejected batches or silently altered fields. Also check how each MISP attribute type maps to a STIX indicator pattern, and record which types the conversion skips, so that missing indicators can be explained later.
The first design decision is whether to run misp2sentinel as provided or to build a direct upload job on the STIX path. The provided tool reduces the code your team maintains, but you depend on its release pace and must confirm how it handles MISP and Sentinel API changes. A direct job puts every change in your hands, including updates when either API moves. For attribute filtering, a custom job can select on tags, attribute types, distribution levels and the to_ids flag using your own rules. For troubleshooting, a custom job can log each stage with counts, while a provided tool may require reading its code or logs to find where an indicator was lost. Confirm which filters the provided tool exposes before you commit.
Plan for failure at the identity and scheduling layers. The Entra app registration needs the permission that allows indicator uploads, and the required permission should be confirmed against Microsoft's current documentation. Rotate the MISP API key and the app's client secret on a schedule your operations team can follow, and record each rotation. Each run should write the number of attributes queried, converted, submitted and accepted. Alert on runs that return zero results, since an empty run often means a filter, key or permission problem rather than a quiet threat landscape. Indicator expiry is handled in the scheduling and expiry guidance for this topic.
Before selecting an approach, ask the implementation partner or your own engineers to answer four questions in writing: which STIX version the target Sentinel interface accepts, which attribute types and flags the job will send, who owns the code after handover, and how a rejected batch is traced back to the MISP event that produced it. Written answers make the trade-off between maintenance and control concrete, and they give the security team a basis for approving the design.
Configuration sequence from Entra app to first indicators in Sentinel
This sequence takes a MISP instance from no connection to a verified first batch of indicators in Microsoft Sentinel's threat intelligence view, with a check at each step. Each check confirms that identity, access, configuration and scheduling work before the next step depends on them. Confirm the exact permissions, configuration keys and upload behavior against the current misp2sentinel documentation and Microsoft's API documentation before you start.
Create a dedicated Entra app registration
The identity team creates a new app registration in the Entra tenant that hosts the Sentinel workspace, used only for this integration, and creates a service principal for it. Do not reuse an existing application or a person's account. Record the tenant ID, application ID and the service principal object ID in your change record. The step is done when the service principal appears in Enterprise applications and the app registration shows no unexpected owners or redirect configuration.
Grant the upload permission and store credentials
Assign only the API permission that the Sentinel threat indicator upload path requires, and confirm the exact permission name in Microsoft's current documentation for that API. Have an administrator grant consent, then create a client secret or certificate with a defined expiry date. Store the client ID, tenant ID and secret in your secrets store, with access limited to the host that runs the job. The step is done when a token request with those credentials succeeds and the app holds no other role assignments.
Create a read-only MISP automation user
The MISP administrator creates a dedicated automation user with a read-only role, so the job can read events and attributes but cannot change them. Generate an API key for that user and set its scope and expiry according to your MISP administration policy. Restrict the key to the sharing groups and tags the integration needs. The step is done when a restSearch call made with the key returns the expected events and when an attempted write with the same key is refused.
Install the connector on a locked-down host
The platform team installs misp2sentinel or the upload job you have chosen on a dedicated host that allows outbound access only to the MISP URL, the Entra token endpoint and the Sentinel upload endpoint. Set the tenant, workspace, MISP URL, filters and the secret reference in the configuration, and keep the secret out of files that other users can read. The step is done when the job starts, authenticates to both services and reports the configuration it loaded without printing the secret.
Run a dry run on a known event
Select one small, known MISP event with a small number of attributes that your team can describe from memory. Run the job in dry-run mode so it converts the event to STIX objects without sending anything to Sentinel. Compare the object count with the number of attributes you expect after your filters apply, and inspect the STIX output for correct indicator patterns, labels and expiry values. The step is done when the object count matches your expectation and every output object is one you intended to send.
Submit one test batch to Sentinel
Send a single batch containing the objects from the verified dry run, with sending enabled. Then open the threat intelligence view in the Sentinel workspace and search for the test indicators by value or by the label you assigned. Confirm that the indicator count and the expiry and confidence fields match the STIX output. The step is done when every test indicator appears in Sentinel with the values you expected, and the job log shows no rejected objects.
Schedule the job and confirm the first run
Schedule the job with your orchestration or cron tooling using the frequency your team agreed in the design phase. Set alerting on failed runs and on authentication failures so that expired credentials surface before indicators stop flowing. After the first scheduled run completes, check the job log, the object count against the MISP filter and the new indicators in Sentinel. The step is done when the scheduled run completes without errors and its output matches the test batch pattern.
Which MISP attributes to send and how they map to Sentinel indicators
This table lists the MISP attribute types and metadata fields that decide what reaches Microsoft Sentinel, the Sentinel indicator type each one maps to, and the filter to apply before upload. Read each row as a rule for the export job. Attribute types the upload path does not support must be excluded or handled deliberately, and every row must be confirmed against the current connector and Sentinel schema before go-live.
| MISP field | Sentinel indicator type | Filter to apply |
|---|---|---|
| IP addresses (ip-src, ip-dst) | IP address indicator | to_ids is true; review CIDR ranges before sending |
| Domains and hostnames (domain, hostname) | Domain name indicator | to_ids is true; exclude broad or shared parent domains |
| URLs (url) | URL indicator | to_ids is true; confirm the connector accepts full URL paths |
| File hashes (md5, sha1, sha256) | File hash indicator | to_ids is true; confirm which hash algorithms the upload path accepts |
| Email addresses (email-src, email-dst) | Email address indicator, if supported | Exclude unless the current schema supports the type; otherwise handle separately |
| Distribution level | Not sent as an indicator field; used to select records | Export only levels your sharing policy allows into Sentinel |
| Tags such as TLP markings | Label or tag, if the schema carries it | Include only TLP levels approved for your workspace; confirm the mapping |
| to_ids flag | Detection flag in the indicator payload | Send only attributes where to_ids is true |
| First seen, last seen and event organization | Validity window and source attribution fields | Confirm which fields set valid-from and expiry; keep the organization for audit |
Scheduling syncs and expiring indicators so Sentinel does not keep stale matches
The sync job is only as reliable as its indicator lifecycle, so define that lifecycle before go-live. Three things need decisions: how often the job runs, how it selects only the attributes that are new or changed since its last successful run, and how a revocation or expiry in MISP reaches Sentinel. Confirm with the misp2sentinel documentation whether the job tracks its last run with a timestamp, a state file or another mechanism, and whether it filters on the attribute's modification time. Also confirm whether the job can see deleted or disabled attributes at all. If it cannot, removals will never propagate unless you handle them another way.
Stale indicators are the main source of false positives in this integration. An IP address that served as command-and-control infrastructure last quarter may now belong to a shared hosting provider, and an analytics rule will keep firing on it if the Sentinel copy never expires. Ask whether MISP expiry or revocation maps to a validity or expiration field in the Sentinel upload, and which field the connector sets. Exact field names and their behavior must be confirmed in the connector and Sentinel documentation. Then test the path end to end: create one indicator with a short validity in a non-production workspace, expire it in MISP, and check what Sentinel shows and when.
Gaps are the opposite risk. A failed run, an expired Entra client secret, or an API throttling error means indicators stop arriving, and Sentinel shows nothing that signals the absence. Set an explicit validity period on every indicator the job sends, so that a removal that never arrives still ages out on a known schedule. Then add a run-status alert that fires on any failed run and on any run that sends zero indicators while MISP holds new matching attributes. Route the alert to the team that owns the job, and document the response, including who reruns the sync and how far back it must reach.
Securing the MISP to Sentinel path
Each control below sits on a different hop between MISP, the job that reads from it, and the Sentinel workspace that receives indicators. Together they limit what leaves MISP, who can change it, and how you find out when something goes wrong. Verify each one in your own environment before the first scheduled run.
Scoped Entra app and credentials
The Entra app registration should hold only the permission needed to upload indicators to the Sentinel workspace, and nothing broader in the tenant. Check the granted permissions, the registration owner, and who can add credentials to it. Prefer certificate-based credentials over a client secret, and confirm that the expiry date and rotation owner are recorded, so the connector does not fail silently when a credential lapses.
Read-only MISP automation user
Create a dedicated MISP user for the job with read access only, and confirm it cannot publish, edit or delete events or change instance settings. Assign it to an organization and sharing role that matches the data it is meant to export. Review that role's permissions after every MISP upgrade, since new features can add capabilities to existing roles.
Tag-based scoping of exported events
Export only events and attributes carrying an approved tag, such as one the sharing team applies after review, so unreviewed material never reaches the job. Test the filter with a sample run and confirm the returned items match what analysts expect. Ask who controls the tag, because anyone who can apply it can widen what leaves the instance.
Distribution and TLP enforcement
Confirm the job respects MISP distribution levels and sharing groups on each attribute, and that TLP markings are kept or mapped as your sharing rules require. Exclude restricted items before export, because Sentinel reaches a wider audience than the original sharing group. Test with one event at each distribution level and record the result.
Job host, configuration and log access
The host running the connector holds the Entra credential and the MISP API key, so treat it as a privileged system. Check that disk encryption, operating system patching and access restrictions are in place, that configuration files holding secrets are readable only by the service account, and that logs do not echo keys or full event payloads. Confirm who can administer the host and how that access is recorded.
Monitoring failed authentications and volume
Alert on failed sign-ins from the app identity in Entra and on failed MISP API calls from the automation user. Track the number of indicators uploaded per run and alert when it moves well outside the normal range, because a sudden spike can mean a tag was widened or a filter broke. Agree the baseline and the person who responds before go-live.
Common Sentinel upload failures and how to fix them
This table pairs common failures in a MISP to Microsoft Sentinel indicator pipeline with their likely causes and the first checks to make. Read each row in order, starting with identity and permissions, then mapping and data, then scheduling. Where the cause sits in the connector or in Microsoft's service, the fix says to confirm behavior before changing settings.
| Failure | Likely cause | Fix |
|---|---|---|
| Authentication or consent errors from Entra | The app registration lacks admin consent for the required API permission, the client secret has expired, or the tenant ID and client ID were copied from the wrong app. | Confirm the app registration, client ID, tenant ID and secret match the connector configuration. Check that admin consent is granted in Entra and that the secret is still valid. Review sign-in logs for the app to see the error code, then confirm the permission requirements with the connector project or Microsoft documentation. |
| Permission denied on the upload interface | The app service principal does not hold the role or scope needed on the Sentinel workspace, or the workspace resource ID points to a different subscription or resource group. | Verify the role assignment on the workspace, not only the subscription or tenant. Confirm the workspace resource ID and region in the connector settings. Check the Azure activity log for the denied operation to identify the missing permission. |
| Indicators accepted but not visible in Sentinel views | Indicators were ingested but are outside their validity window, use a type or field the view does not query, or are filtered by a rule or watchlist scope. | Check the valid-from and valid-until values and whether expired indicators were dropped. Query the threat indicators table directly in Log Analytics before assuming the upload failed. Confirm which Sentinel view and analytics rules read those indicators and adjust the mapping or query accordingly. |
| Schema or STIX validation rejections | Attributes were mapped to STIX object types or properties the upload API does not accept, or required fields such as pattern, name or indicator types are empty. | Review the rejection messages and the failing object in the connector logs. Limit the attribute types sent to those the mapping supports, fill required fields through the mapping, and test with a single event before a full run. Confirm supported STIX versions and object properties with the connector project and the Sentinel API documentation. |
| MISP API key or role errors that return empty results | The automation key belongs to a user whose role cannot read the events or attributes, or the key was rotated and the connector still uses the old value. | Use a dedicated automation user with a role that can read the events to be exported and check that the key is current in the connector configuration. Compare results from a direct API search in MISP with the connector output. Confirm the role and tag filters your deployment needs with your MISP administrator. |
| Duplicate or stale indicators after a schedule change | A new run created indicators without matching the earlier upload, or the schedule and expiry settings changed, so old indicators were never revoked or expired. | Review how the connector identifies indicators for updates and deletion, and whether a changed schedule re-sent the same objects. Check expiry and revocation settings and clean up affected indicators in Sentinel with a controlled bulk action. Confirm update and deletion behavior with the connector project before changing the schedule again. |
| Job timeouts on large events | A single event or a long export window contains more attributes than one run can upload within the platform limits, or the MISP API is slow under load. | Split the export by time window, tag or event size, and schedule runs outside peak MISP usage. Check MISP logs and PHP or worker timeouts on the MISP side and the connector run history on the other side. Confirm upload size and rate limits with Microsoft and the connector project. |
Questions buyers ask before hiring outside help for MISP and Sentinel
What does a MISP to Microsoft Sentinel integration cost?
DeployOpen does not publish prices. A quote follows from a written scope, and the scope decides most of the cost. The main drivers are:
- Number of MISP sources: each instance or community feed you push from adds configuration, mapping and testing.
- Attribute types: every indicator type you send to Sentinel needs a defined mapping and validation.
- Entra and Sentinel governance model: app registration, role assignment, workspace structure and approval steps change the effort.
- Testing scope: the depth of validation in a non-production workspace before go-live.
- Run monitoring: whether someone watches ingestion after go-live, which recurs over time.
Ask for the quote to separate one-time build work from any recurring support.
How long does a MISP and Sentinel integration take to deliver?
The timeline depends on the same scope drivers as cost, so DeployOpen does not quote a generic duration. The written scope sets the deliverables, the timeline and the dates agreed before work starts. Your team can shorten the path by preparing these items early:
- Access to the Entra tenant and the Sentinel workspace, with an admin who can approve app registration.
- A MISP API key for a dedicated account with the permissions the push requires.
- A decision on which events, tags and attribute types should leave MISP.
- Change windows for production, and a named approver for go-live.
If a date matters to your organization, make it a scope condition and ask for it in writing.
Can our team build a MISP and Sentinel integration alone?
A capable team can build it alone if it already has skills in four areas: MISP administration, Microsoft Entra app registration, Sentinel configuration and API scripting. Most gaps show up in indicator expiry, scheduling and error handling, so check those skills first. Outside help often covers design review, the build, testing against your governance model and a handover that leaves your engineers able to operate the integration. You can also split the work, for example keeping MISP content decisions in-house and having DeployOpen handle the Entra and Sentinel configuration. Write the split into the scope so ownership of each part is clear.
Do we need a MISP expert on staff before hiring a partner?
You do not need a dedicated MISP specialist to start, but you do need a named owner who decides what leaves MISP. That owner decides which events and tags are eligible, which distribution levels are allowed to reach Sentinel and which attribute types are useful for detection. Without that decision, the integration can push data that is noisy, sensitive or out of date. Your security operations lead or threat intelligence lead is often the right owner. Ask the partner to document these rules during the build and to train the owner on them before handover.
Do we need an existing MISP instance before the integration starts?
Yes, the integration pushes indicators from a MISP instance, so one must exist and be reachable from the path your scope defines. If you do not have one, deploying MISP is a separate work item that the written scope can include. If you already run MISP, confirm the version first. MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only, so the project advises against new 2.4 instances. An upgrade may need to happen before the integration work begins, and that affects both scope and sequencing.
What happens when the misp2sentinel connector or the Sentinel API changes?
A change in the connector or the Sentinel API can stop ingestion or alter how indicators are stored, and the failure may not be obvious at first. Plan for it before go-live:
- Pin versions: record the connector and library versions in use and change them only through tested updates.
- Test in a non-production workspace: validate each update against sample events before it reaches production.
- Monitor ingestion: watch for failed pushes, expired indicators and unexpected volume changes.
- Track vendor changes: confirm which Sentinel API the connector uses and check the upstream release notes.
A retainer can cover monitoring and planned updates. Ask the partner to state in writing who is responsible for each step.
How does fixed-scope delivery work, and when is a retainer needed?
Most DeployOpen engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, so you know what is included and what is excluded. A new request after that goes through a written change to the scope. Ongoing support is separate. A retainer covers ongoing support, upgrades and continuous testing, which suits teams that want someone responsible for the integration after the build ends. If your own team will run the integration, a retainer may be unnecessary, but ask for a handover plan and a support option in the quote so you can decide later.
How DeployOpen scopes, builds and supports the MISP and Sentinel integration
DeployOpen plans, implements and documents the connection between a self-hosted MISP instance and Microsoft Sentinel inside infrastructure you control. Each engagement starts with a written, fixed scope that sets which attributes leave MISP, how indicators are scheduled and expired, and how the result is handed over to your team.
How we scope
- Confirm the MISP version, hosting model and which events and tags are eligible to leave MISP
- Map which attribute types and distribution levels are sent to Sentinel and which stay internal
- Agree the Entra app registration, permissions and secret handling model in writing before build
- Record indicator expiry, scheduling and ownership rules as part of the fixed scope
How we build
- Install and configure the misp2sentinel connector in your environment with versions you approve
- Register the Entra application and wire the STIX objects upload API to your Sentinel workspace
- Test indicator ingestion, expiry behavior and duplicate handling against a representative sample of events
- Document configuration, filters and rollback steps so changes can be reviewed before they reach production
How we hand over
- Deliver runbooks covering scheduling, credential rotation, failed-push handling and expiry review
- Walk your SOC and platform team through the configuration and the tests used to verify it
- Provide written records of the scope, decisions and configuration changes made during the build
- Agree a handover checklist so ownership of the connector is clear before the engagement closes
How we support
- Ongoing support, upgrades and monitoring of the integration are available as a retainer
- Review the integration when MISP or Sentinel changes, and plan upgrades in a test environment first
- Confirm with your team which support scope and response arrangements apply before work starts
- Adjust filters and schedules through a change process agreed with your security operations owners
