SecOps - 41203 - Custom data connectors are configured in Microsoft Sentinel for in-scope sources without a built-in connector

[Manoj Kesana (Manoj-Kesana)]

No description provided.

[Copilot]

Pull request overview

Adds a new SecOps assessment (Test ID 41203) to evaluate whether Microsoft Sentinel workspaces have at least one customer-/partner-authored codeless (custom) data connector configured, and provides the accompanying markdown description for reporting/remediation context.

Changes:

• Introduces Test-Assessment-41203 PowerShell test to enumerate Sentinel workspaces, query data connectors/definitions, classify “custom” connectors by publisher, and emit a summarized markdown table.
• Adds Test-Assessment.41203.md narrative/remediation content for the new assessment.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/powershell/tests/Test-Assessment.41203.ps1	New assessment implementation that queries Sentinel workspaces and evaluates presence of custom codeless connectors.
src/powershell/tests/Test-Assessment.41203.md	New assessment documentation/remediation text and results placeholder.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Aleksandar Nikolić (alexandair)]

Manoj Kesana (@Manoj-Kesana) Please, address my feedback.

Suggestion: Include inaccessible or unresolved workspace rows in the report. The current table is built only from confirmed onboarded workspaces, so an Investigate result does not show every workspace that caused it.

[Aleksandar Nikolić (alexandair)]

Any non-Microsoft publisher is incorrectly classified as customer-authored

Code: Test-Assessment.41203.ps1#L138-L179
Specification: /ztspecs/specs/secops/41203.md#L94-L101

$builtInPublishers = @('Microsoft', 'Microsoft Corporation')
...
IsCustom = -not [string]::IsNullOrWhiteSpace($publisher) -and
    $builtInPublishers -notcontains $publisher

The specification requires a non-Microsoft publisher to also be absent from a known commercial-vendor list. The implementation has no such list and no customer-organization identity to compare against. It therefore marks any partner-authored CCF connector, such as one published by an ISV or MSSP, as custom and can return Pass when the tenant has no customer-authored connector.

This is not a theoretical distinction: Microsoft documents Microsoft-supported, partner-supported, and community-supported connector authors. A publisher other than Microsoft does not establish customer authorship.

Required change: classify a connector as customer-authored only from affirmative evidence. Implement the specification's maintained commercial-vendor exclusion and customer publisher matching, or return Investigate when authorship cannot be established. Apply the same rule to $customDefinitions; it currently has the same false-positive behavior.

[Aleksandar Nikolić (alexandair)]

A successful workspace masks failed API calls and inaccessible workspaces

Code: Test-Assessment.41203.ps1#L208-L224
Error capture: Test-Assessment.41203.ps1#L112-L130
Specification: /ztspecs/specs/secops/41203.md#L103

$passed = $passedItems.Count -gt 0
...
if (-not $passed -and ($investigateItems.Count -gt 0 -or
    $forbiddenWorkspaces.Count -gt 0 -or
    $unresolvedWorkspaces.Count -gt 0)) {
    $customStatus = 'Investigate'
}

Once any workspace has a connector classified as custom, $passed is true and the Investigate branch is disabled. The final result is therefore Pass even when:

• Q1 or Q2 failed for another Sentinel workspace;
• Sentinel onboarding could not be checked for another workspace; or
• another workspace was inaccessible due to permissions.

That contradicts the explicit specification rule that a Q1 or Q2 error returns Investigate, and it hides incomplete tenant coverage behind one successful workspace.

Required change: unresolved connector/onboarding results must take precedence over Pass. Compute Investigate first whenever any relevant workspace or query is unresolved. Add focused tests for mixed states, especially one Pass plus one Q1 failure, one Q2 failure, and one inaccessible workspace.

[Aleksandar Nikolić (alexandair)]

The code declares Pillar = 'SecOps', while the specification declares Data. Because the specification resides under specs/secops and the workshop task is SecOps, the code value is likely intentional and the specification likely needs correction.

[Aleksandar Nikolić (alexandair)]

Companion documentation overstates what the check proves

Documentation: Test-Assessment.41203.md#L1
Specification: /ztspecs/specs/secops/41203.md#L54-L56

The implementation documentation says the check confirms a "customer- or partner-authored custom connector." The specification says the check confirms a customer-authored connector and explicitly excludes known commercial vendors. Align the documentation after fixing classification so users are not told that a partner connector satisfies the control.