-
Notifications
You must be signed in to change notification settings - Fork 530
Open
Labels
buguse for describing something not working as expecteduse for describing something not working as expectedneeds triageuse to identify issue needing triage from Filigran Product teamuse to identify issue needing triage from Filigran Product team
Description
Description
The microsoft-defender-intel-synchronizer connector exhibits multiple production-impacting defects that make it slow and unreliable on larger TAXII feeds and cause some indicators to be silently skipped. Documentation and samples also do not reflect current behavior or supported configuration.
Main symptoms:
- Very slow ingestion on large TAXII collections. Syncs can take many minutes and place excessive load on the OpenCTI backend.
- Hostname indicators are not created in Defender even when confidence and score are high.
- passive_only mode does not consistently prevent modifying calls in all code paths and preflight logs are misleading.
- README, docker-compose, and config samples omit supported configuration for per-collection overrides and show a legacy login URL.
Environment
- OS (where OpenCTI server runs): Ubuntu 22.04 (containers)
- OpenCTI version: 6.8.x
- OpenCTI client: connector container microsoft-defender-intel-synchronizer (rolling)
- Other environment details:
- Microsoft 365 Defender GCC endpoint: https://api-gcc.securitycenter.microsoft.us
- Docker Compose deployment
- TAXII collections: 2 to 3 feeds, each up to ~15k indicators per run
Reproducible Steps
Steps to create the smallest reproducible scenario:
- Deploy the connector with two sizable TAXII collections and default configuration (CSV list).
- Include at least one indicator with a Hostname observable (e.g., pattern [hostname:value = 'example.bad']) and score/confidence 100.
- Run a sync on the current rolling connector.
- Optionally set MICROSOFT_DEFENDER_INTEL_SYNCHRONIZER_PASSIVE_ONLY=true and run preflight + sync again.
Expected Output
- Sync completes quickly enough to be operational on large feeds.
- Hostname indicators are handled as domain names and created in Defender.
- In passive_only=true, no modifying API requests are sent, and preflight logs clearly indicate that write checks were skipped.
- Docs and samples describe per-collection overrides for TAXII collections and reference the correct login URL.
Actual Output
- Sync is slow on large feeds and increases backend load.
- Hostname indicators are silently skipped and never appear in Defender.
- In passive_only=true, modifying requests can still be attempted in some paths, and preflight reports a successful write check even when no write should occur.
- Docs and samples do not show advanced per-collection overrides and list https://login.microsoft.com instead of https://login.microsoftonline.com.
Additional information
- Long runtimes and heavy backend queries make regular synchronization impractical at scale.
- Teams cannot rely on Hostname indicators being enforced in Defender.
- Passive runs intended for audit can still appear to perform writes due to inconsistent guards and logging.
Screenshots (optional)
Metadata
Metadata
Assignees
Labels
buguse for describing something not working as expecteduse for describing something not working as expectedneeds triageuse to identify issue needing triage from Filigran Product teamuse to identify issue needing triage from Filigran Product team