# Partner API (Deprecated) Source: https://docs.contraforce.com/api-reference-hidden/partner-api The legacy Partner API has been retired. Use the v2 API. The Partner API is **deprecated** and is no longer the supported integration path. New work should use the v2 API. The Partner API was a single-purpose Sentinel-only integration surface served from `https://api.contraforce.com/`. It is being retired in favor of the v2 API, which: * Authenticates with [Service Accounts](/guides/general-support/service-accounts) instead of the legacy partner key flow. * Covers every SIEM source we support (Sentinel, Defender XDR, CrowdStrike, QRadar, Splunk, SentinelOne) under the same source-prefixed routes. * Returns RFC 7807 [ProblemDetails](/api-reference/errors) for every error. * Is documented end-to-end on this site rather than out-of-band on GitHub. ## Where to go next Every v2 endpoint reachable by a service account, grouped by scope. Request and response examples for the v2 API. Every error code, what triggers it, and how to resolve it. Create the credentials that authenticate v2 API requests. The legacy `https://api.contraforce.com/oauth/token` endpoint referenced in older documentation is **not** valid for the v2 API. Authenticate against `https://portal.contraforce.com/api/v2/...` using HTTP Basic with your service-account `clientId` / `clientSecret`. # Agent tool execute kql Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-execute-kql /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/agent/tools/kql/query # Agent tool get device timeline Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-get-device-timeline /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/agent/tools/devices/{deviceId}/timeline # Agent tool get kql table columns Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-get-kql-table-columns /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/agent/tools/kql/tables/columns # Agent tool get user details Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-get-user-details /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/agent/tools/users/{userId} # Agent tool list directory logs Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-list-directory-logs /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/agent/tools/users/{userId}/directory-logs # Agent tool list kql tables Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-list-kql-tables /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/agent/tools/kql/tables # Agent tool list signin logs Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-list-signin-logs /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/agent/tools/users/{userId}/signin-logs # Agent tool related incidents Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-related-incidents /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/agent/tools/incidents/{source}/{incidentId}/related-by-entity # Agent tool submit gamebook Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-submit-gamebook /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/agent/tools/incidents/{source}/{incidentId}/gamebooks # Agent tool submit investigation Source: https://docs.contraforce.com/api-reference/agent-tools/agent-tool-submit-investigation /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/agent/tools/incidents/{source}/{incidentId}/investigation # Check azure subscription owner Source: https://docs.contraforce.com/api-reference/azure-resources/check-azure-subscription-owner /api-reference/openapi.json get /api/v2/azure-resources/subscriptions/is-owner # List azure nsgs Source: https://docs.contraforce.com/api-reference/azure-resources/list-azure-nsgs /api-reference/openapi.json get /api/v2/azure-resources/subscriptions/{subscriptionId}/network-security-groups # List azure resource groups Source: https://docs.contraforce.com/api-reference/azure-resources/list-azure-resource-groups /api-reference/openapi.json get /api/v2/azure-resources/subscriptions/{subscriptionId}/resource-groups # List azure sentinels Source: https://docs.contraforce.com/api-reference/azure-resources/list-azure-sentinels /api-reference/openapi.json get /api/v2/azure-resources/subscriptions/{subscriptionId}/resource-groups/{resourceGroup}/sentinels # List azure subscriptions Source: https://docs.contraforce.com/api-reference/azure-resources/list-azure-subscriptions /api-reference/openapi.json get /api/v2/azure-resources/subscriptions # List azure workspaces Source: https://docs.contraforce.com/api-reference/azure-resources/list-azure-workspaces /api-reference/openapi.json get /api/v2/azure-resources/subscriptions/{subscriptionId}/resource-groups/{resourceGroup}/workspaces # Update analytical rule Source: https://docs.contraforce.com/api-reference/azure-resources/update-analytical-rule /api-reference/openapi.json put /api/v2/azure-resources/analytical-rules/{ruleId} # Validate azure workspace Source: https://docs.contraforce.com/api-reference/azure-resources/validate-azure-workspace /api-reference/openapi.json get /api/v2/azure-resources/subscriptions/{subscriptionId}/resource-groups/{resourceGroup}/workspaces/{workspaceName}/validate # Get datasource workspaces across workspaces Source: https://docs.contraforce.com/api-reference/cross-workspace-data-sources/get-datasource-workspaces-across-workspaces /api-reference/openapi.json get /api/v2/datasources/across-workspaces # List datasource anomalies across workspaces Source: https://docs.contraforce.com/api-reference/cross-workspace-data-sources/list-datasource-anomalies-across-workspaces /api-reference/openapi.json post /api/v2/datasources/across-workspaces/anomalies # List gamebooks history across workspaces Source: https://docs.contraforce.com/api-reference/cross-workspace-gamebooks/list-gamebooks-history-across-workspaces /api-reference/openapi.json get /api/v2/gamebooks/across-workspaces/history # Bulk update incidents across workspaces Source: https://docs.contraforce.com/api-reference/cross-workspace-incidents/bulk-update-incidents-across-workspaces /api-reference/openapi.json post /api/v2/incidents/across-workspaces/bulk-update # List incidents across workspaces Source: https://docs.contraforce.com/api-reference/cross-workspace-incidents/list-incidents-across-workspaces /api-reference/openapi.json post /api/v2/incidents/across-workspaces # Get connected datasources Source: https://docs.contraforce.com/api-reference/data-sources/get-connected-datasources /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/datasources # Endpoint Reference Source: https://docs.contraforce.com/api-reference/endpoints Every v2 API endpoint reachable by a service account, grouped by scope. The v2 API is REST + JSON over HTTPS. Every request authenticates with a [service account](/guides/general-support/service-accounts) using HTTP Basic, every response is wrapped in a standard envelope, and every error is RFC 7807 [ProblemDetails](/api-reference/errors). **Base URL** ``` https://portal.contraforce.com/api/v2 ``` **Authentication** ``` Authorization: Basic ``` **Conventions** * `Content-Type: application/json` (or `multipart/form-data` for SOP uploads) * Property names are camelCase; enum values are PascalCase (`Sentinel`, `High`, `TwentyFourHours`) * Workspace IDs and most other identifiers are GUIDs * Source segment values: `Sentinel`, `DefenderXDR`, `CrowdStrike`, `QRadar`, `Splunk`, `SentinelOne` Endpoints marked **Portal Only** in the codebase are excluded from this reference — they are gated to browser sessions and are not reachable by service accounts. *** ## Workspace-Scoped Endpoints Path prefix: `/workspaces/{workspaceId}/...` The workspace ID is a GUID and identifies the customer environment the request operates against. The credential's service account must have a role on the target workspace, otherwise the request returns `403 INSUFFICIENT_WORKSPACE_ROLE`. Every incident is the child of one SIEM source — the source is encoded as a route segment, not a query parameter. | Method | Path | Description | | ------ | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `GET` | `/workspaces/{workspaceId}/incidents/{source}/{incidentId}` | Get the full incident detail, including alerts, entities, investigation details, and evidence. | | `GET` | `/workspaces/{workspaceId}/incidents/{source}/{incidentId}/evidence` | Get the evidence table for an incident. | | `GET` | `/workspaces/{workspaceId}/incidents/{source}/{incidentId}/last-gamebook` | Get the last gamebook run for an incident, or `404` if none has run. | | `GET` | `/workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments` | List comments on an incident. | | `GET` | `/workspaces/{workspaceId}/incidents/{source}/by-entity` | Find incidents in this source related to a specific entity. | | Method | Path | Description | | -------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | `DELETE` | `/workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments/{commentId}` | Delete a comment. Requires `?extensionId=` identifying the integration that owns the comment. | | Method | Path | Description | | ------ | -------------------------------------------------------------------- | ---------------------------------------------------------------------- | | `GET` | `/workspaces/{workspaceId}/gamebooks/rules/{incidentTitle}` | Get playbooks matching an incident title. | | `GET` | `/workspaces/{workspaceId}/gamebooks/history` | List gamebook execution history. Supports `?query=` and `?pageToken=`. | | `GET` | `/workspaces/{workspaceId}/gamebooks/history/{gamebookId}/playbooks` | Get the playbooks recorded against a specific gamebook run. | | `GET` | `/workspaces/{workspaceId}/gamebooks/by-incident/{incidentId}` | List all gamebooks that have run for an incident. | | Method | Path | Description | | ------ | --------------------------------------- | --------------------------------------------- | | `GET` | `/workspaces/{workspaceId}/datasources` | List data sources connected to the workspace. | **Read** (`tickets:read`): | Method | Path | Description | | ------ | ------------------------------------------ | --------------------------------------------------------------------- | | `GET` | `/workspaces/{workspaceId}/tickets/search` | Search service tickets. Supports `?groupingId=` and `?ticketNumber=`. | **Manage** (`tickets:manage`): | Method | Path | Description | | ------ | -------------------------------------------- | ----------------------------------------- | | `POST` | `/workspaces/{workspaceId}/tickets/link` | Link a service ticket to an incident. | | `POST` | `/workspaces/{workspaceId}/tickets/unlink` | Unlink a service ticket from an incident. | | `PUT` | `/workspaces/{workspaceId}/tickets/priority` | Update ticket priority. | | Method | Path | Description | | ------ | -------------------------------------------------------------- | -------------------------- | | `GET` | `/workspaces/{workspaceId}/investigation/users/signin-logs` | List user sign-in logs. | | `GET` | `/workspaces/{workspaceId}/investigation/users/directory-logs` | List directory audit logs. | Some incident operations that don't yet thread an explicit SIEM source through their handlers (`/{incidentId}/summary`, `/{incidentId}/entities`, `/{incidentId}/alert-rules`, `assign`, `status`, `bulk`, comment create/update, `/high`) have been removed from the v2 surface. They will return once their handlers operate against an explicit source rather than implicitly defaulting to Sentinel. *** ## Cross-Workspace Endpoints These endpoints span every workspace your service account can see — no workspace ID in the path. The handlers filter results to the workspaces the credential has been mapped to. | Scope | Method | Path | Description | | ------------------ | ------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | | `incidents:read` | `POST` | `/incidents/across-workspaces` | List incidents across all visible workspaces. | | `gamebooks:read` | `GET` | `/gamebooks/across-workspaces/history` | List gamebook history across visible workspaces. Supports `?workspaces=`, `?statuses=`, `?currentPage=`, `?query=`. | | `datasources:read` | `POST` | `/datasources/across-workspaces/anomalies` | List data connector anomalies across visible workspaces. | | `datasources:read` | `GET` | `/datasources/across-workspaces` | Group connected data sources by workspace. Repeat `?workspaceIds=` for each workspace ID. | ### Paginating `/incidents/across-workspaces` The cross-workspace incidents list uses opaque continuation tokens. The first request leaves the token map empty; every subsequent request echoes the previous response's tokens back unchanged. Tokens are server-encrypted strings — treat them as a single blob the API gave you, never parse or construct one yourself. **First request:** ```json theme={null} POST /api/v2/incidents/across-workspaces { "isFirstCall": true, "workspacePageTokens": [], "sources": ["Sentinel"], "timeFilterSelection": { "type": "TwentyFourHours" } } ``` **Response (truncated):** ```json theme={null} { "data": { "incidents": [ /* ...page of incidents... */ ], "sourcePageTokens": [ { "workspaceId": "6eca6a1f-b7d1-4bb8-a055-35ad6bb4b9b1", "sourceTokens": { "Sentinel": "Gd41DJgGnsDnbYHEdqbFaAKzlIbg6NVK...CQM8=" } } ], "moreIncidentsAvailable": true } } ``` **Next-page request — set `isFirstCall: false` and pass `sourcePageTokens` back verbatim as `workspacePageTokens`:** ```json theme={null} POST /api/v2/incidents/across-workspaces { "isFirstCall": false, "workspacePageTokens": [ { "workspaceId": "6eca6a1f-b7d1-4bb8-a055-35ad6bb4b9b1", "sourceTokens": { "Sentinel": "Gd41DJgGnsDnbYHEdqbFaAKzlIbg6NVK...CQM8=" } } ], "sources": ["Sentinel"], "timeFilterSelection": { "type": "TwentyFourHours" } } ``` Iterate until the response returns `moreIncidentsAvailable: false`. A workspace that has finished paging drops out of `sourcePageTokens` on subsequent responses; do not synthesize entries for it. Page size is server-controlled. A token that has been modified or hand-built returns `400 VALIDATION_ERROR` with the message `One or more pagination tokens are invalid. Use the tokens from the previous response unmodified.` Recover by restarting from the first call with an empty `workspacePageTokens` array. *** ## Organization-Scoped Endpoints These endpoints operate on the organization (service provider). The credential's service account must hold the relevant org-level scope; workspace mappings are not required. **Read** (`webhooks:read`): | Method | Path | Description | | ------ | ------------------------------------------------- | ------------------------------------------------------------------------------------------- | | `GET` | `/webhooks` | List all webhook configurations. | | `GET` | `/webhooks/{id}` | Get a webhook by ID. | | `GET` | `/webhooks/{id}/delivery-logs` | List delivery logs. Supports `?from=`, `?to=`, `?pageSize=`, `?continuationToken=`. | | `GET` | `/webhooks/{id}/delivery-logs/{logId}?createdAt=` | Get a single delivery log entry. `createdAt` is the ISO-8601 partition key and is required. | **Manage** (`webhooks:manage`): | Method | Path | Description | | -------- | ----------------------------------------------------------- | ---------------------------------------------------------------- | | `POST` | `/webhooks` | Create a webhook configuration. | | `PUT` | `/webhooks/{id}` | Update a webhook configuration. | | `DELETE` | `/webhooks/{id}` | Delete a webhook configuration. | | `POST` | `/webhooks/{id}/pause` | Pause delivery. | | `POST` | `/webhooks/{id}/resume` | Resume a paused webhook. | | `POST` | `/webhooks/{id}/enable` | Re-enable a webhook auto-disabled by repeated delivery failures. | | `POST` | `/webhooks/{id}/credentials` | Update webhook authentication credentials. | | `POST` | `/webhooks/{id}/test` | Send a test event. | | `POST` | `/webhooks/{id}/delivery-logs/{logId}/redeliver?createdAt=` | Redeliver a previously failed event. | **Read** (`org:service-accounts:read`): | Method | Path | Description | | ------ | ------------------------ | ---------------------------- | | `GET` | `/service-accounts` | List service accounts. | | `GET` | `/service-accounts/{id}` | Get a service account by ID. | **Manage** (`org:service-accounts:manage`): | Method | Path | Description | | -------- | ---------------------------------------------------------- | ------------------------------------------------------------ | | `POST` | `/service-accounts` | Create a service account. | | `PUT` | `/service-accounts/{id}` | Update a service account. | | `DELETE` | `/service-accounts/{id}` | Delete a service account. | | `POST` | `/service-accounts/{id}/disable` | Disable a service account. | | `POST` | `/service-accounts/{id}/enable` | Re-enable a disabled service account. | | `POST` | `/service-accounts/{id}/credentials` | Issue a new credential. The `clientSecret` is returned once. | | `POST` | `/service-accounts/{id}/credentials/{credentialId}/revoke` | Revoke a credential. | **Read** (`org:users:read`): | Method | Path | Description | | ------ | ------------------------ | ------------------------------------ | | `GET` | `/users` | List organization users. | | `GET` | `/users/{userId}` | Get a user by ID. | | `GET` | `/users/profile` | Get the calling principal's profile. | | `POST` | `/users/workspace/users` | Get users for a specific workspace. | **Manage** (`org:users:manage`): | Method | Path | Description | | -------- | ------------------ | ---------------------------------------- | | `POST` | `/users` | Add users to the organization. | | `PUT` | `/users` | Update a user. | | `PUT` | `/users/profile` | Update the calling principal's profile. | | `DELETE` | `/users/{id}` | Remove a user from the organization. | | `POST` | `/users/workspace` | Assign users to a workspace with a role. | **Roles** (`org:users:roles`): | Method | Path | Description | | ------ | -------------------------- | ------------------------------------ | | `PUT` | `/users/organization/role` | Change a user's organizational role. | **Read** (`org:azure:read`): | Method | Path | Description | | ------ | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | `GET` | `/azure-resources/subscriptions` | List Azure subscriptions visible to the org's tenant. | | `GET` | `/azure-resources/subscriptions/is-owner?subscriptionId=` | Check whether the calling principal is an Owner of the subscription. | | `GET` | `/azure-resources/subscriptions/{subscriptionId}/network-security-groups` | List NSGs in a subscription. | | `GET` | `/azure-resources/subscriptions/{subscriptionId}/resource-groups` | List resource groups in a subscription. | | `GET` | `/azure-resources/subscriptions/{subscriptionId}/resource-groups/{resourceGroup}/workspaces` | List Log Analytics workspaces in a resource group. | | `GET` | `/azure-resources/subscriptions/{subscriptionId}/resource-groups/{resourceGroup}/sentinels` | List Sentinel instances in a resource group. | | `GET` | `/azure-resources/subscriptions/{subscriptionId}/resource-groups/{resourceGroup}/workspaces/{workspaceName}/validate` | Validate a Sentinel-attached workspace. | **Manage** (`org:azure:manage`): | Method | Path | Description | | ------ | --------------------------------------------------------- | ------------------------------------- | | `PUT` | `/azure-resources/analytical-rules/{ruleId}?enabled=true` | Enable or disable an analytical rule. | *** ## What Comes Back Every successful response is wrapped in the standard envelope: ```json theme={null} { "data": { /* … endpoint-specific payload … */ }, "meta": { "requestId": "0HN8Q3V0001", "timestamp": "2026-04-15T20:00:00.0000000+00:00" } } ``` List endpoints add a `pagination` block; see the [object models](/api-reference/models) page for shapes per endpoint family. Error responses are RFC 7807 ProblemDetails (`application/problem+json`) with a stable `code` extension you can switch on — the [error reference](/api-reference/errors) lists every code. # Error Reference Source: https://docs.contraforce.com/api-reference/errors Every v2 API error code, the HTTP status it ships with, and how to act on it. The v2 API surfaces every error as an [RFC 7807 ProblemDetails](https://datatracker.ietf.example/doc/html/rfc7807) document, served as `application/problem+json`. Switch on the `code` extension — it's part of the contract and won't move under your feet. The `title` and `detail` strings are human-readable and may be reworded between releases. ## Response shape ```json theme={null} { "type": "https://docs.contraforce.com/api-reference/errors", "title": "Resource not found", "status": 404, "detail": "Incident 'INC-12345' not found", "instance": "/api/v2/workspaces/6eca6a1f-b7d1-4bb8-a055-35ad6bb4b9b1/incidents/Sentinel/INC-12345", "code": "NOT_FOUND", "requestId": "0HNLBAGCRD4RN:00000003", "timestamp": "2026-04-15T20:00:00.0000000+00:00" } ``` | Field | Source | Description | | ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `type` | RFC 7807 | URI identifying the problem class. Points at this reference page (`https://docs.contraforce.com/api-reference/errors`); the `code` extension is the programmatic discriminator. | | `title` | RFC 7807 | Short, stable per-`code` summary. | | `status` | RFC 7807 | HTTP status code, mirrored in the response status line. | | `detail` | RFC 7807 | Per-instance message describing what went wrong. | | `instance` | RFC 7807 | URI of the failing request. | | `code` | extension | **Stable identifier you should switch on.** See the catalogue below. | | `requestId` | extension | Trace identifier for the failed request. Quote this when contacting support. | | `timestamp` | extension | UTC ISO-8601 timestamp the failure was generated at. | | `target` | extension, optional | Field or identifier the error refers to. | | `errors` | extension, optional | Field-keyed validation error map. Empty key means an object-level error. | ## Validation responses When binding fails or a [FluentValidation](https://docs.fluentvalidation.example/) rule rejects, the response includes an `errors` map: ```json theme={null} { "type": "https://docs.contraforce.com/api-reference/errors", "title": "Validation failed", "status": 400, "detail": "One or more validation errors occurred.", "instance": "/api/v2/workspaces/.../incidents/Sentinel/INC-12345/comments", "code": "VALIDATION_ERROR", "errors": { "content": ["'Content' must not be empty."], "extensionId": ["'Extension Id' is required."], "": ["At least one of source or workspaceId must be provided."] }, "requestId": "0HNLBAGCRD4RN:00000007", "timestamp": "2026-04-15T20:00:00.0000000+00:00" } ``` Keys are JSON property paths; the empty key carries object-level errors that aren't tied to a specific field. *** ## Error code catalogue | Code | Status | When you see it | What to do | | ----------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `VALIDATION_ERROR` | 400 | A required field is missing, malformed, or rejected by validation. The `errors` extension carries the per-field detail. | Inspect the `errors` map. Empty keys map to object-level errors; named keys map to JSON paths. | | `BAD_REQUEST` | 400 | A 400 not classified as a validation failure (e.g. a malformed body the framework couldn't parse at all). | Inspect `detail`. Confirm the body matches the documented shape. | | `UNAUTHORIZED` | 401 | Missing or invalid `Authorization` header, revoked or rotated `clientSecret`, or a disabled service account. | Re-authenticate with valid credentials. If you rotated, update both halves of the credential. | | `FORBIDDEN` | 403 | Authenticated, but the calling principal can't perform this action on this resource. | Check that the credential carries the scope the endpoint requires and that the service account has the right workspace role. | | `INSUFFICIENT_SCOPE` | 403 | The credential is missing one of the scopes required by the endpoint. | Add the scope to the credential in the portal. Scopes follow the `{resource}:{action}` convention. | | `INSUFFICIENT_WORKSPACE_ROLE` | 403 | The calling principal has no role on the target workspace. | Have an organization admin assign a workspace role to the service account. | | `MFA_REQUIRED` | 403 | The user-flow path requires MFA from the configured IdP. | Complete the MFA challenge in the portal. Service accounts do not encounter this code. | | `USER_NOT_REGISTERED` | 403 | The authenticated user is not registered in the ContraForce user store. | An organization admin must sync or invite the user before they can call the API. | | `EXTENSION_NOT_ENABLED` | 400 | The endpoint requires an integration (e.g. Defender XDR, Jira) that hasn't been consented and enabled for this workspace. | Enable the integration via the workspace configuration endpoints or in the portal. | | `NOT_FOUND` | 404 | A workspace, incident, gamebook, or other addressed resource doesn't exist or isn't visible to the credential. | Verify the IDs in the path. For workspace-scoped routes, confirm the workspace is mapped to the service account. | | `METHOD_NOT_ALLOWED` | 405 | Wrong HTTP verb on the route. | Check the [endpoint reference](/api-reference/endpoints) for the correct verb. | | `CONFLICT` | 409 | The resource version on the server differs from yours, the same operation was already performed, or two concurrent writes collided. | Refetch the resource and retry with the latest state. | | `UNSUPPORTED_MEDIA_TYPE` | 415 | Wrong `Content-Type` header for the body shape. | Use `application/json` for JSON requests, `multipart/form-data` for SOP uploads. | | `RATE_LIMITED` | 429 | Too many requests in the rolling window. | Honor `Retry-After` if present, otherwise back off exponentially. | | Code | Status | When you see it | What to do | | ---------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | `INTERNAL_ERROR` | 500 | An unhandled exception. | Retry once; if persistent, contact support and quote the `requestId`. | | `UPSTREAM_ERROR` | 502 | A downstream SIEM or EDR returned a 5xx, or our credential to the upstream is broken. Authentication failures from upstream services are also collapsed onto this code so we don't leak which side of the integration is misconfigured. | Retry after a short backoff. If persistent, contact support — only we can resolve broken upstream credentials. | | `TIMEOUT` | 504 | An upstream operation didn't finish within our timeout window, or our HTTP client to the upstream timed out. | Retry after a short backoff. For long-running queries (KQL, advanced hunting), narrow the time window. | *** ## Mapping behavior A few specific cases are worth calling out because they affect how you should design retries and surface failures to your own users. When a downstream SIEM rejects a request with a 4xx (404 for an unknown ID, 400 for an unparseable filter, 409 for a conflict, 429 for rate-limit, 408/504 for timeout), the v2 API surfaces that as the matching 4xx — `NOT_FOUND`, `VALIDATION_ERROR`, `CONFLICT`, `RATE_LIMITED`, `TIMEOUT` — rather than collapsing onto an opaque 502. That way your retry logic can act on what's actually wrong. Only opaque or 5xx upstream failures stay as `UPSTREAM_ERROR`. Upstream 401/403 also stay opaque (they mean *our* credential to the upstream is broken; that's not something you can fix). When the caller disconnects mid-request, the response is an empty `499` and no ProblemDetails body is written. Treat 499 as "request was cancelled before we could respond" — your client probably already knows. Some development-mode payloads previously carried a `traceId` extension from ASP.NET. The v2 contract is `requestId` only. Quote the `requestId` value when contacting support — we can correlate it to backend logs without you needing to share anything else. *** ## Correlating with our logs Every `requestId` is also recorded in our backend logs. Including it in support requests dramatically shortens triage: > Hello, I'm seeing intermittent 502 `UPSTREAM_ERROR` on `POST /api/v2/incidents/across-workspaces`. Example `requestId`: `0HNLBAGCRD4RN:00000003` at `2026-04-15T20:00:00Z`. We can pull the full backend trace and pinpoint the failure without needing the request body or your credentials. # Get playbooks by gamebook id Source: https://docs.contraforce.com/api-reference/gamebooks/get-playbooks-by-gamebook-id /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/gamebooks/history/{gamebookId}/playbooks # Get playbooks by incident title Source: https://docs.contraforce.com/api-reference/gamebooks/get-playbooks-by-incident-title /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/gamebooks/rules/{incidentTitle} # List gamebooks history Source: https://docs.contraforce.com/api-reference/gamebooks/list-gamebooks-history /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/gamebooks/history # List incident gamebooks Source: https://docs.contraforce.com/api-reference/gamebooks/list-incident-gamebooks /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/gamebooks/by-incident/{incidentId} # Assign incident Source: https://docs.contraforce.com/api-reference/incidents/assign-incident /api-reference/openapi.json put /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/assignee # Create incident comment Source: https://docs.contraforce.com/api-reference/incidents/create-incident-comment /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments # Delete incident comment Source: https://docs.contraforce.com/api-reference/incidents/delete-incident-comment /api-reference/openapi.json delete /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments/{commentId} # Get incident by id Source: https://docs.contraforce.com/api-reference/incidents/get-incident-by-id /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId} # Get incident comments Source: https://docs.contraforce.com/api-reference/incidents/get-incident-comments /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments # Get incident evidence Source: https://docs.contraforce.com/api-reference/incidents/get-incident-evidence /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/evidence # Get incident last gamebook Source: https://docs.contraforce.com/api-reference/incidents/get-incident-last-gamebook /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/last-gamebook # Get incidents by entity Source: https://docs.contraforce.com/api-reference/incidents/get-incidents-by-entity /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/incidents/{source}/by-entity # Update incident comment Source: https://docs.contraforce.com/api-reference/incidents/update-incident-comment /api-reference/openapi.json put /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments/{commentId} # Update incident status Source: https://docs.contraforce.com/api-reference/incidents/update-incident-status /api-reference/openapi.json put /api/v2/workspaces/{workspaceId}/incidents/{source}/{incidentId}/status # Introduction Source: https://docs.contraforce.com/api-reference/introduction Example section for showcasing API endpoints If you're not looking to build API reference documentation, you can delete this section by removing the api-reference folder. ## Welcome There are two ways to build API documentation: [OpenAPI](https://mintlify.com/docs/api-playground/openapi/setup) and [MDX components](https://mintlify.com/docs/api-playground/mdx/configuration). For the starter kit, we are using the following OpenAPI specification. View the OpenAPI specification file ## Authentication All API endpoints are authenticated using Bearer tokens and picked up from the specification file. ```json theme={null} "security": [ { "bearerAuth": [] } ] ``` # List directory logs Source: https://docs.contraforce.com/api-reference/investigation/list-directory-logs /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/investigation/users/directory-logs # List signin logs Source: https://docs.contraforce.com/api-reference/investigation/list-signin-logs /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/investigation/users/signin-logs # Object Models Source: https://docs.contraforce.com/api-reference/models Copy-pasteable JSON request and response examples for the ContraForce v2 API. Use these models as a reference when building integrations. Request and response bodies use `application/json` (or `multipart/form-data` for SOP uploads). Successful responses are wrapped in the standard envelope; error responses follow RFC 7807 ProblemDetails — see the [error reference](/api-reference/errors) for the full catalogue. *** ## Response Envelopes ### Success response ```json theme={null} { "data": { ... }, "meta": { "requestId": "0HN8Q3V0001", "timestamp": "2026-04-15T20:00:00.0000000+00:00" } } ``` ### Paginated response ```json theme={null} { "data": [ ... ], "pagination": { "continuationToken": "eyJjb250...", "hasMore": true }, "meta": { "requestId": "0HN8Q3V0001", "timestamp": "2026-04-15T20:00:00.0000000+00:00" } } ``` ### Error response Errors are RFC 7807 ProblemDetails, served as `application/problem+json`. Switch on the stable `code` extension; the `title` and `detail` strings are human-readable and may be reworded between releases. ```json theme={null} { "type": "about:blank", "title": "Resource not found", "status": 404, "detail": "Incident 'INC-12345' not found", "instance": "/api/v2/workspaces/.../incidents/Sentinel/INC-12345", "code": "NOT_FOUND", "requestId": "0HN8Q3V0002", "timestamp": "2026-04-15T20:01:00.0000000+00:00" } ``` The full set of `code` values, validation `errors` map shape, and resolution guidance live on the [error reference](/api-reference/errors) page. *** ## Incidents ### Incident object Returned by `GET /workspaces/{workspaceId}/incidents/{source}/{incidentId}`: ```json theme={null} { "source": "Sentinel", "incident": { "id": "INC-12345", "title": "Suspicious sign-in from anonymous IP address", "severity": "High", "status": "Active", "workspaceId": "ws-abc123", "createdAt": "2026-04-15T10:30:00Z", "updatedAt": "2026-04-15T14:22:00Z" }, "investigationDetails": { "entities": [ ], "alerts": [ ] }, "evidence": { }, "gamebookCatalog": { } } ``` **Enum values:** | Field | Values | | ---------- | --------------------------------------------------------------------------- | | `source` | `Sentinel`, `DefenderXDR`, `CrowdStrike`, `QRadar`, `Splunk`, `SentinelOne` | | `severity` | `Informational`, `Low`, `Medium`, `High` | | `status` | `New`, `Active`, `Closed` | ### Incident comment Response object from `GET /workspaces/{workspaceId}/incidents/{source}/{incidentId}/comments`: ```json theme={null} { "id": "comment-001", "message": "Confirmed this was a legitimate admin action.", "createdTime": "2026-04-15T16:00:00Z", "authorEmail": "analyst@contoso.example", "authorName": "Jane Doe", "isActivityComment": false, "isAgentComment": false, "agentName": null, "isClosingComment": false, "ticketNoteId": null, "ticketId": null } ``` ### List incidents across workspaces Request body for `POST /incidents/across-workspaces`: ```json theme={null} { "severities": ["High", "Medium"], "statuses": ["New", "Active"], "sources": ["Sentinel", "DefenderXDR"], "timeFilterSelection": { "type": "SevenDays" }, "isFirstCall": true, "query": "malware", "assigneeEmails": ["analyst@contoso.example"], "includeUnassigned": true } ``` **Time filter enum values for `type`:** `TwentyFourHours`, `SevenDays`, `ThirtyDays`, `Custom` When using `Custom`, include `customStartUtc` and `customEndUtc`: ```json theme={null} { "timeFilterSelection": { "type": "Custom", "customStartUtc": "2026-04-01T00:00:00Z", "customEndUtc": "2026-04-15T23:59:59Z" } } ``` *** ## Webhooks For the full list of event types, their payload schemas, and delivery behavior, see the [Webhook Event Reference](/api-reference/webhook-events). ### Webhook configuration Response object from `GET /webhooks/{id}`: ```json theme={null} { "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "serviceProviderId": "00000000-0000-0000-0000-000000000001", "targetAccountId": "00000000-0000-0000-0000-000000000001", "targetAccountName": "Contoso MSP", "workspaceId": null, "name": "SIEM-ingest-prod", "url": "https://siem.contoso.example/api/webhook", "status": "Active", "eventTypes": ["incident.created.v1", "incident.closed.v1"], "monitoredAccountIds": [ "11111111-1111-1111-1111-111111111111", "22222222-2222-2222-2222-222222222222" ], "authenticationType": "Bearer", "hasSigningToken": true, "disableReason": null, "disabledAt": null, "createdAt": "2026-03-01T12:00:00Z", "lastModifiedAt": "2026-04-10T09:30:00Z" } ``` ### Create webhook Request body for `POST /webhooks`: ```json theme={null} { "name": "SIEM-ingest-prod", "url": "https://siem.contoso.example/api/webhook", "eventTypes": ["incident.created.v1", "incident.closed.v1"], "monitoredAccountIds": [ "11111111-1111-1111-1111-111111111111" ], "authenticationType": "Bearer", "token": "your-bearer-token", "signingToken": "your-hmac-signing-secret" } ``` **Enum values for `authenticationType`:** `None`, `Bearer`, `Basic`, `ApiKey` ### Delivery log Response object from `GET /webhooks/{id}/delivery-logs/{logId}`: ```json theme={null} { "id": "log-001", "webhookConfigurationId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "eventType": "incident.created.v1", "httpStatusCode": 200, "success": true, "requestUrl": "https://siem.contoso.example/api/webhook", "requestHeaders": { "Content-Type": "application/json" }, "requestBody": "{ ... }", "responseBody": "OK", "durationMs": 142, "createdAt": "2026-04-15T19:30:00Z", "redelivered": false } ``` *** ## Service Accounts ### Service account Response object from `GET /service-accounts/{id}`: ```json theme={null} { "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901", "accountId": "00000000-0000-0000-0000-000000000001", "name": "Jira-incident-sync-prod", "description": "Syncs incidents to Jira Service Management", "isActive": true, "organizationalRole": "Member", "clientSecretPrefix": "cf_sa_", "credentialExpirationDate": "2027-04-15T00:00:00Z", "workspaceAssignments": [ { "workspaceId": "ws-abc123", "workspaceName": "Contoso Prod", "role": "Analyst" } ], "credentials": [ { "id": "cred-001", "scopes": ["incidents:read", "incidents:write"], "status": "Active", "expiresAt": "2027-04-15T00:00:00Z", "lastUsedAt": "2026-04-15T19:00:00Z", "createdAt": "2026-04-01T12:00:00Z" } ], "lastUsedAt": "2026-04-15T19:00:00Z", "createdAt": "2026-04-01T12:00:00Z", "lastModifiedAt": "2026-04-10T09:30:00Z" } ``` ### Create service account Request body for `POST /service-accounts`: ```json theme={null} { "name": "Jira-incident-sync-prod", "description": "Syncs incidents to Jira Service Management", "organizationalRole": "Member", "workspaceAssignments": [ { "workspaceId": "ws-abc123", "role": "Analyst" } ], "scopes": ["incidents:read", "incidents:write"], "expirationDate": "2027-04-15T00:00:00Z" } ``` ### Credential created (shown once) Response from `POST /service-accounts/{id}/credentials`: ```json theme={null} { "clientId": "b2c3d4e5-f6a7-8901-bcde-f12345678901", "clientSecret": "cf_sa_aBcDeFgHiJkLmNoPqRsTuVwXyZ012345678==", "id": "cred-002", "scopes": ["incidents:read"], "status": "Active", "expiresAt": "2027-04-15T00:00:00Z", "lastUsedAt": null, "createdAt": "2026-04-15T20:00:00Z" } ``` The `clientSecret` is returned **only once** in this response. Store it immediately in a secrets manager. *** ## Users ### User object Response object from `GET /users/{userId}`: ```json theme={null} { "id": "61eec97d-57b2-5b00-686e-8544a1b2c3d4", "displayName": "Jane Doe", "email": "jane.doe@contoso.example", "organizationalRole": "Member", "isActive": true } ``` # Create service account Source: https://docs.contraforce.com/api-reference/service-accounts/create-service-account /api-reference/openapi.json post /api/v2/service-accounts # Create service account credential Source: https://docs.contraforce.com/api-reference/service-accounts/create-service-account-credential /api-reference/openapi.json post /api/v2/service-accounts/{id}/credentials # Delete service account Source: https://docs.contraforce.com/api-reference/service-accounts/delete-service-account /api-reference/openapi.json delete /api/v2/service-accounts/{id} # Disable service account Source: https://docs.contraforce.com/api-reference/service-accounts/disable-service-account /api-reference/openapi.json post /api/v2/service-accounts/{id}/disable # Enable service account Source: https://docs.contraforce.com/api-reference/service-accounts/enable-service-account /api-reference/openapi.json post /api/v2/service-accounts/{id}/enable # Get service account Source: https://docs.contraforce.com/api-reference/service-accounts/get-service-account /api-reference/openapi.json get /api/v2/service-accounts/{id} # List service accounts Source: https://docs.contraforce.com/api-reference/service-accounts/list-service-accounts /api-reference/openapi.json get /api/v2/service-accounts # Revoke service account credential Source: https://docs.contraforce.com/api-reference/service-accounts/revoke-service-account-credential /api-reference/openapi.json post /api/v2/service-accounts/{id}/credentials/{credentialId}/revoke # Update service account Source: https://docs.contraforce.com/api-reference/service-accounts/update-service-account /api-reference/openapi.json put /api/v2/service-accounts/{id} # Link ticket Source: https://docs.contraforce.com/api-reference/service-tickets/link-ticket /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/tickets/link # Search tickets Source: https://docs.contraforce.com/api-reference/service-tickets/search-tickets /api-reference/openapi.json get /api/v2/workspaces/{workspaceId}/tickets/search # Unlink ticket Source: https://docs.contraforce.com/api-reference/service-tickets/unlink-ticket /api-reference/openapi.json post /api/v2/workspaces/{workspaceId}/tickets/unlink # Update ticket priority Source: https://docs.contraforce.com/api-reference/service-tickets/update-ticket-priority /api-reference/openapi.json put /api/v2/workspaces/{workspaceId}/tickets/priority # Add user Source: https://docs.contraforce.com/api-reference/users/add-user /api-reference/openapi.json post /api/v2/users # Add workspace users Source: https://docs.contraforce.com/api-reference/users/add-workspace-users /api-reference/openapi.json post /api/v2/users/workspace # Get user Source: https://docs.contraforce.com/api-reference/users/get-user /api-reference/openapi.json get /api/v2/users/{userId} # Get user profile Source: https://docs.contraforce.com/api-reference/users/get-user-profile /api-reference/openapi.json get /api/v2/users/profile # Get workspace users Source: https://docs.contraforce.com/api-reference/users/get-workspace-users /api-reference/openapi.json post /api/v2/users/workspace/users # List users Source: https://docs.contraforce.com/api-reference/users/list-users /api-reference/openapi.json get /api/v2/users # Remove user Source: https://docs.contraforce.com/api-reference/users/remove-user /api-reference/openapi.json delete /api/v2/users/{id} # Update org role Source: https://docs.contraforce.com/api-reference/users/update-org-role /api-reference/openapi.json put /api/v2/users/organization/role # Update user Source: https://docs.contraforce.com/api-reference/users/update-user /api-reference/openapi.json put /api/v2/users # Update user profile Source: https://docs.contraforce.com/api-reference/users/update-user-profile /api-reference/openapi.json put /api/v2/users/profile # Webhook Event Reference Source: https://docs.contraforce.com/api-reference/webhook-events Every event type ContraForce can deliver to a webhook endpoint, with the delivery envelope, headers, payload schemas, and retry behavior. ContraForce delivers events to your endpoint over HTTPS as signed JSON. This page lists every event type the platform can send, the exact body shape for each, and the delivery rules that apply to all of them. Webhooks are managed under **Settings → Developer Integrations** in the portal, or through the [`/webhooks` endpoints](/api-reference/endpoints) with the `webhooks:read` and `webhooks:manage` scopes. *** ## Event Types | Event type | Display name | Routing | Fires when | | ---------------------------------- | ----------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `webhook.test.v1` | Webhook Test | Manual | You use **Send test** on a webhook to verify connectivity. | | `incident.created.v1` | Incident Created | Subscription | A new incident is ingested into a monitored workspace. Also used by the manual **Trigger webhook** action on an incident. | | `incident.closed.v1` | Incident Closed | Subscription | An incident reaches Closed, including closures performed in the vendor's own portal. | | `gamebook.run.v1` | Gamebook Run | Subscription | A Gamebook is dispatched against an incident, by an analyst or by the AI agent. | | `agent.investigation.completed.v1` | Agent Investigation Completed | Externally configured | A Security Delivery Agent finishes an investigation and reaches a verdict whose classification card points at a webhook. | ### Routing models The webhook lists the event type in its `eventTypes` array. Every active webhook in scope receives the event. Scope resolution covers the incident's own account plus any managing service provider accounts. A service provider webhook with a non-empty `monitoredAccountIds` list only receives events from the accounts it lists; an empty list means all managed accounts. Subscribing alone does not opt a webhook in. An owning entity has to name the webhook explicitly. Today this applies only to `agent.investigation.completed.v1`, where an Agent Configuration's classification card selects the target webhook. The webhook must *also* keep `agent.investigation.completed.v1` in its `eventTypes`. If it is unsubscribed while still bound to a classification card, the delivery is recorded as **Failed** in the delivery log rather than dropped silently. `webhook.test.v1` is only produced by the **Send test** action against one specific webhook. It is not a subscribable event. The incident **Trigger webhook** action is also manual, but it reuses `incident.created.v1` so that existing receivers process it without code changes. Subscription matching is bypassed for that fire, though `monitoredAccountIds` is still enforced. *** ## The Delivery Envelope Every event, regardless of type, is delivered as the same outer envelope. The event-specific schema lives under `data`. ```json theme={null} { "type": "incident.created.v1", "timestamp": "2026-08-03T14:22:07.881Z", "isTest": false, "occurredAt": "2026-08-03T14:21:55.000Z", "data": { } } ``` | Field | Type | Description | | ------------ | ------- | ----------------------------------------------------------------------------------- | | `type` | string | The event type. Matches the `X-CF-Schema` header. | | `timestamp` | string | ISO 8601 time the delivery attempt was built. | | `isTest` | boolean | `true` for test deliveries only. | | `occurredAt` | string | ISO 8601 time the underlying event happened, which can be earlier than `timestamp`. | | `data` | object | The event payload. Shape depends on `type`. | Verify the signature over the full raw body, envelope included. Do not sign or hash only the `data` object. All payload property names are camelCase. *** ## Request Headers | Header | Value | Notes | | ---------------- | ------------------------------------ | ------------------------------------------------------------- | | `Content-Type` | `application/json` | Body is UTF-8 encoded JSON. | | `X-CF-Schema` | The event type | Branch on this. Default-ignore types you do not recognize. | | `X-CF-Event-Id` | GUID | Stable per logical event. Use it to deduplicate. | | `X-CF-Timestamp` | ISO 8601 timestamp | Reject if more than 5 minutes from your clock. | | `X-CF-Signature` | Base64 HMAC-SHA256 | See below. | | `X-CF-Test` | `true` or `false` | `true` only for test deliveries. | | `Authorization` | `Bearer ` or `Basic ` | Present only if you configured authentication on the webhook. | *** ## Verifying the Signature The signature covers the timestamp and the exact raw request body: ``` signature = Base64( HMAC_SHA256( signing_key, X-CF-Timestamp + "." + raw_body ) ) ``` The `signing_key` is the secret shown once when the webhook was created, unless you supplied your own signing token override when setting bearer-token credentials, in which case it is that token. ```python verify.py theme={null} import base64, hashlib, hmac, time from datetime import datetime, timezone def verify(signing_key: str, headers: dict, raw_body: bytes) -> bool: ts = headers["X-CF-Timestamp"] sent = headers["X-CF-Signature"] signed = ts.encode() + b"." + raw_body expected = base64.b64encode( hmac.new(signing_key.encode(), signed, hashlib.sha256).digest() ).decode() if not hmac.compare_digest(expected, sent): return False age = abs(time.time() - datetime.fromisoformat(ts).replace(tzinfo=timezone.utc).timestamp()) return age <= 300 ``` ```csharp Verify.cs theme={null} static bool Verify(string signingKey, string timestamp, string sentSignature, byte[] rawBody) { var signed = System.Text.Encoding.UTF8.GetBytes(timestamp + ".") .Concat(rawBody).ToArray(); using var hmac = new System.Security.Cryptography.HMACSHA256( System.Text.Encoding.UTF8.GetBytes(signingKey)); var expected = Convert.ToBase64String(hmac.ComputeHash(signed)); var match = System.Security.Cryptography.CryptographicOperations.FixedTimeEquals( System.Text.Encoding.UTF8.GetBytes(expected), System.Text.Encoding.UTF8.GetBytes(sentSignature)); var age = Math.Abs((DateTimeOffset.UtcNow - DateTimeOffset.Parse(timestamp)).TotalSeconds); return match && age <= 300; } ``` *** ## `webhook.test.v1` A synthetic connectivity check, sent only by the **Send test** action on a single webhook. It carries `X-CF-Test: true` and `isTest: true`, and is signed exactly like a live event, so you can validate your verification code end to end before any real traffic arrives. The payload mirrors the `incident.created.v1` shape with fixed sample values. ```json theme={null} { "type": "webhook.test.v1", "timestamp": "2026-08-03T14:22:07.881Z", "isTest": true, "occurredAt": "2026-08-03T14:22:07.881Z", "data": { "accountId": "11111111-1111-1111-1111-111111111111", "accountName": "Contoso Production", "incidentId": "test-00000000-0000-0000-0000-000000000000", "incidentNumber": 0, "title": "Test Incident — Webhook Connectivity Verification", "description": "This is a test event generated by ContraForce to verify your webhook endpoint is configured correctly and receiving events.", "severity": "Informational", "source": "contraforce", "sourceDisplayName": "ContraForce", "createdAt": "2026-08-03T14:22:07.881Z", "lastActivityAt": "2026-08-03T14:22:07.881Z", "alertProductNames": ["ContraForce EventCast"], "alerts": [ { "title": "Webhook Test Alert", "severity": "Informational", "productName": "ContraForce EventCast", "vendorName": "ContraForce" } ], "owner": { "displayName": "ContraForce Test User", "email": "test-user@example.com" }, "entities": [ { "type": "account", "displayName": "test-account@example.com" }, { "type": "host", "displayName": "DESKTOP-TEST001" }, { "type": "ip", "displayName": "192.0.2.1" } ] } } ``` Test deliveries are excluded from the auto-disable circuit breaker, so a failing test never takes a live webhook offline. *** ## `incident.created.v1` Fires when a new incident is ingested into a workspace the webhook monitors. The same event type is emitted by the incident **Trigger webhook** action so that receivers do not need a separate code path for a manually replayed incident. ```json theme={null} { "type": "incident.created.v1", "timestamp": "2026-08-03T14:22:07.881Z", "isTest": false, "occurredAt": "2026-08-03T14:21:55.000Z", "data": { "accountId": "11111111-1111-1111-1111-111111111111", "accountName": "Contoso Production", "incidentId": "a7f3c1e2-0000-4b1a-9c3d-5f6e7a8b9c0d", "incidentNumber": 4242, "title": "Suspicious sign-in from impossible travel", "description": "Multiple sign-ins from geographically distant locations within a short window.", "severity": "High", "source": "sentinel", "sourceDisplayName": "Microsoft Sentinel", "owner": { "displayName": "Jane Doe", "email": "jdoe@contoso.example" }, "createdAt": "2026-08-03T14:21:55.000Z", "lastActivityAt": "2026-08-03T14:21:58.000Z", "occurredAt": "2026-08-03T14:21:55.000Z", "alertProductNames": ["Microsoft Entra ID Protection"], "alerts": [ { "title": "Impossible travel activity", "severity": "High", "productName": "Microsoft Entra ID Protection", "vendorName": "Microsoft" } ], "entities": [ { "type": "Account", "displayName": "jdoe@contoso.example" }, { "type": "IP", "displayName": "198.51.100.24" } ] } } ``` ### Fields | Field | Type | Description | | --------------------------- | -------------- | ------------------------------------------------------------------------------------------------------ | | `accountId` / `accountName` | string | The workspace the incident belongs to. | | `incidentId` | string | The source system's incident identifier. | | `incidentNumber` | number \| null | The incident number shown in the portal. | | `title` | string | Incident title. | | `description` | string | Incident description, empty string when the source provides none. | | `severity` | string | `Informational`, `Low`, `Medium`, `High`, or `Critical`. | | `source` | string | Detection source, **lowercased** for this event, for example `sentinel`, `defenderxdr`, `crowdstrike`. | | `sourceDisplayName` | string | Human-readable source name. | | `owner` | object \| null | Assigned owner, omitted when unassigned. | | `createdAt` | string | ISO 8601 creation time. | | `lastActivityAt` | string \| null | ISO 8601 time of the most recent activity. | | `occurredAt` | string | Duplicate of `createdAt`, retained for receivers that read it from `data`. | | `alertProductNames` | string\[] | Distinct product names across the incident's alerts. | | `alerts[]` | array | Each with `title`, `severity`, `productName`, `vendorName`. | | `entities[]` | array | Each with `type` and `displayName`. `Ip` and `Url` are normalized to `IP` and `URL`. | Null fields are omitted from this payload rather than serialized as `null`. Treat a missing `owner` or `lastActivityAt` as absent. *** ## `incident.closed.v1` Fires when an incident reaches Closed, whichever route got it there: the portal, a bulk close, the AI agent, or the public API. Closures performed directly in the vendor's own console are also picked up by reconciliation and delivered here, distinguished by `closedBy.origin`. ```json theme={null} { "type": "incident.closed.v1", "timestamp": "2026-08-03T16:04:12.117Z", "isTest": false, "occurredAt": "2026-08-03T16:04:12.117Z", "data": { "accountId": "11111111-1111-1111-1111-111111111111", "accountName": "Contoso Production", "incidentId": "a7f3c1e2-0000-4b1a-9c3d-5f6e7a8b9c0d", "incidentNumber": 4242, "title": "Suspicious sign-in from impossible travel", "severity": "High", "source": "Sentinel", "sourceDisplayName": "Microsoft Sentinel", "classification": "TruePositive", "classificationReason": "MaliciousActivity", "comment": "Confirmed credential theft. User reset and sessions revoked.", "closedAt": "2026-08-03T16:04:12.117Z", "closedBy": { "displayName": "Jane Doe", "origin": "analyst" } } } ``` ### Fields | Field | Type | Description | | --------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------- | | `accountId` / `accountName` | string | The workspace the incident belongs to. | | `incidentId` | string | The source system's incident identifier. | | `incidentNumber` | number \| null | The incident number shown in the portal. | | `title` | string | Incident title. | | `severity` | string | Incident severity at close. | | `source` | string | Detection source in PascalCase for this event, for example `Sentinel`. | | `sourceDisplayName` | string | Human-readable source name. | | `classification` | string \| null | Canonical ContraForce classification: `TruePositive`, `FalsePositive`, `BenignPositive`, or `Undetermined`. | | `classificationReason` | string \| null | Canonical reason name, when one was recorded. | | `comment` | string \| null | Free-text closing comment, when one was provided. | | `closedAt` | string | ISO 8601 close time. | | `closedBy.displayName` | string | Closing analyst, or the upstream source label for vendor-portal closures. | | `closedBy.origin` | string | `analyst` for closures through ContraForce, `upstream` for closures detected in the vendor's portal. | Branch on `classification`, not on vendor strings. ContraForce normalizes every source's closure vocabulary into the four canonical values, so your integration does not have to track vendor enum changes. See [Incident classification](/concepts/incident-classification). *** ## `gamebook.run.v1` Fires when a Gamebook is dispatched to the executor against an incident, whether an analyst started it from the portal or public API, or the AI agent did. Gamebooks awaiting approval do not fire this event while queued. The event is emitted when the run is actually dispatched. ```json theme={null} { "type": "gamebook.run.v1", "timestamp": "2026-08-03T15:10:44.502Z", "isTest": false, "occurredAt": "2026-08-03T15:10:44.502Z", "data": { "accountId": "11111111-1111-1111-1111-111111111111", "accountName": "Contoso Production", "incidentId": "a7f3c1e2-0000-4b1a-9c3d-5f6e7a8b9c0d", "incidentNumber": 4242, "title": "Compromised account containment", "source": "Sentinel", "gamebookId": "3c9d1b7e-2f44-4a86-8c11-9e0f7d5a2b31", "gamebookTitle": "Compromised account containment", "playbooks": ["Disable user", "Revoke sign-in sessions"], "runAt": "2026-08-03T15:10:44.502Z", "runBy": { "displayName": "Jane Doe" } } } ``` ### Fields | Field | Type | Description | | --------------------------- | -------------- | ------------------------------------------------------------------------------- | | `accountId` / `accountName` | string | The workspace the incident belongs to. | | `incidentId` | string | The source system's incident identifier. | | `incidentNumber` | number \| null | The incident number shown in the portal. | | `title` | string | The gamebook title. Duplicates `gamebookTitle`; it is not the incident title. | | `source` | string | Detection source of the incident in PascalCase, for example `Sentinel`. | | `gamebookId` | string | GUID of the gamebook that ran. | | `gamebookTitle` | string | Display title of the gamebook. | | `playbooks` | string\[] | Display names of the playbooks in the dispatched gameplan. | | `runAt` | string | ISO 8601 dispatch time. | | `runBy.displayName` | string | The triggering identity: an analyst's name, or the AI agent's service identity. | *** ## `agent.investigation.completed.v1` Fires once per investigation, when a Security Delivery Agent completes and reaches a classification whose card has a webhook custom action configured. This event is configured per classification on an Agent Configuration card, not as a broadcast subscription. Set it up under [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents) by enabling **Advanced** mode and choosing a webhook as the **custom action** for a classification. Full walkthrough and troubleshooting: [Agent Investigation Completed Webhook](/guides/agent-center/agent-investigation-webhook). ```json theme={null} { "type": "agent.investigation.completed.v1", "timestamp": "2026-08-03T14:31:09.740Z", "isTest": false, "occurredAt": "2026-08-03T14:31:02.310Z", "data": { "workspace": { "id": "11111111-1111-1111-1111-111111111111", "alias": "contoso", "name": "Contoso Production" }, "agent": { "id": "5b2e9c4a-77d1-4c0b-a8f3-2d6e1c9b0a55", "name": "Tier 1 Triage Agent" }, "incident": { "id": "a7f3c1e2-0000-4b1a-9c3d-5f6e7a8b9c0d", "number": 4242, "source": "Sentinel", "title": "Suspicious sign-in from impossible travel", "severity": "High", "status": "Active" }, "verdict": { "classificationBucket": "TruePositive", "classificationReason": "MaliciousActivity", "classificationReasonComment": "Confirmed credential theft", "comment": "Sign-in originated from a known-malicious ASN minutes after a login from the user's usual location." }, "gamebookRecommendation": { "incidentNumber": 4242, "incidentTitle": "Suspicious sign-in from impossible travel", "playbooks": [ { "playbookId": "disable-user", "affectedEntity": "Account", "entityId": "jdoe@contoso.example", "sequence": 1 } ] } } } ``` ### Fields | Field | Type | Description | | ------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------- | | `workspace.id` / `alias` / `name` | string | The ContraForce workspace the incident belongs to. | | `agent.id` / `name` | string | The Security Delivery Agent that ran the investigation. | | `incident.id` | string | The source system's incident identifier. | | `incident.number` | number | The incident number shown in the portal. | | `incident.source` | string | Detection source in PascalCase, for example `Sentinel`. | | `incident.title` | string | Incident title. | | `incident.severity` | string | Incident severity. | | `incident.status` | string | Incident status at completion. | | `verdict.classificationBucket` | string | The agent's verdict. One of `TruePositive`, `BenignPositive`, `FalsePositive`, `Undetermined`. | | `verdict.classificationReason` | string \| null | Reason code for the classification. | | `verdict.classificationReasonComment` | string \| null | Free-text reason detail. | | `verdict.comment` | string | The agent's investigation summary comment. | | `gamebookRecommendation` | object \| null | Present only when the agent recommended gamebooks. | | `gamebookRecommendation.playbooks[]` | array | Each with `playbookId`, `affectedEntity`, `entityId`, and `sequence`. | *** ## Delivery Rules These apply to every event type. ### Retries Delivery is at-least-once. A failed attempt is retried with a fixed backoff, up to **10 attempts** within a **5 minute** window from the first attempt. Whichever limit is hit first ends the retry budget and the event is dead-lettered. | Next attempt | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | | ------------ | -- | --- | --- | --- | --- | --- | --- | --- | --- | | Backoff | 5s | 10s | 15s | 20s | 30s | 30s | 40s | 50s | 60s | Retries are triggered by HTTP `408`, `429`, `500`, `502`, `503`, and `504`, and by connection or timeout errors. Any other non-success status is treated as a permanent failure and is not retried. A `Retry-After` header is honored when it is longer than the scheduled backoff, clamped to the 5 minute retry window. Retries reuse the same `X-CF-Event-Id`. Make your handler idempotent and deduplicate on that value. ### Event IDs `incident.created.v1` and `incident.closed.v1` and `gamebook.run.v1` derive a deterministic event ID from the underlying subject, so a republished event produces the same ID and can be deduplicated. Test events and manually triggered incident fires get a fresh ID per fire, which is what distinguishes a manual replay from the original automatic event. ### Auto-disable If **5 or more distinct incidents** fail final delivery to the same webhook within a rolling **24 hours**, the webhook is automatically disabled and stops receiving events. Test deliveries never count toward this threshold. Re-enable it with `POST /webhooks/{id}/enable` or from the webhook detail page in the portal, after fixing the endpoint. ### Requirements for your endpoint * Must be reachable over HTTPS. Plain HTTP, localhost, and private network addresses are rejected at configuration time. * Must respond within **30 seconds**. Acknowledge with a 2xx immediately and do the real work asynchronously. * Response bodies are read up to 1 MB for the delivery log; anything larger is truncated. * Should default-ignore unknown values of `X-CF-Schema` so new event types do not break your handler. *** ## Subscribing Set the event types when you create or update a webhook. At least one is required. ```json theme={null} { "name": "SIEM-ingest-prod", "url": "https://siem.contoso.example/api/webhook", "eventTypes": [ "incident.created.v1", "incident.closed.v1", "gamebook.run.v1" ], "monitoredAccountIds": [ "11111111-1111-1111-1111-111111111111" ], "authenticationType": "Bearer", "token": "your-bearer-token", "signingToken": "your-hmac-signing-secret" } ``` `webhook.test.v1` is not subscribable. `agent.investigation.completed.v1` must be listed here *and* selected on an Agent Configuration classification card before it delivers anything. Delivery outcomes for every event are visible per webhook under **Settings → Developer Integrations**, and through `GET /webhooks/{id}/delivery-logs`. Questions about webhook events? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Create webhook Source: https://docs.contraforce.com/api-reference/webhooks/create-webhook /api-reference/openapi.json post /api/v2/webhooks # Delete webhook Source: https://docs.contraforce.com/api-reference/webhooks/delete-webhook /api-reference/openapi.json delete /api/v2/webhooks/{id} # Enable webhook Source: https://docs.contraforce.com/api-reference/webhooks/enable-webhook /api-reference/openapi.json post /api/v2/webhooks/{id}/enable # Get webhook Source: https://docs.contraforce.com/api-reference/webhooks/get-webhook /api-reference/openapi.json get /api/v2/webhooks/{id} # Get webhook delivery log Source: https://docs.contraforce.com/api-reference/webhooks/get-webhook-delivery-log /api-reference/openapi.json get /api/v2/webhooks/{id}/delivery-logs/{logId} # List webhook delivery logs Source: https://docs.contraforce.com/api-reference/webhooks/list-webhook-delivery-logs /api-reference/openapi.json get /api/v2/webhooks/{id}/delivery-logs # List webhooks Source: https://docs.contraforce.com/api-reference/webhooks/list-webhooks /api-reference/openapi.json get /api/v2/webhooks # Pause webhook Source: https://docs.contraforce.com/api-reference/webhooks/pause-webhook /api-reference/openapi.json post /api/v2/webhooks/{id}/pause # Redeliver webhook Source: https://docs.contraforce.com/api-reference/webhooks/redeliver-webhook /api-reference/openapi.json post /api/v2/webhooks/{id}/delivery-logs/{logId}/redeliver # Resume webhook Source: https://docs.contraforce.com/api-reference/webhooks/resume-webhook /api-reference/openapi.json post /api/v2/webhooks/{id}/resume # Test webhook Source: https://docs.contraforce.com/api-reference/webhooks/test-webhook /api-reference/openapi.json post /api/v2/webhooks/{id}/test # Update webhook Source: https://docs.contraforce.com/api-reference/webhooks/update-webhook /api-reference/openapi.json put /api/v2/webhooks/{id} # Update webhook credentials Source: https://docs.contraforce.com/api-reference/webhooks/update-webhook-credentials /api-reference/openapi.json post /api/v2/webhooks/{id}/credentials # After the Breach: A Complete Playbook for Business Recovery and Stakeholder Communication Source: https://docs.contraforce.com/blog/after-the-breach Most cybersecurity content focuses on prevention and detection. But what happens in the days, weeks, and months after an incident is what determines whether your organization recovers or spirals. This playbook covers the full post-incident journey — from immediate stabilization through long-term recovery — including the communication, legal, and operational steps that most organizations aren't prepared for. *** ## The First 72 Hours: Stabilize and Assess The period immediately following incident containment is chaotic. Your security team is exhausted, leadership wants answers, and every stakeholder has a different urgent question. Having a structured approach prevents the response from creating new problems. ### Confirm Containment Before Pivoting to Recovery Before any recovery work begins, verify with your incident response team (internal or external) that the attacker has been fully evicted from your environment. Premature recovery — rebuilding systems while the attacker still has access — is one of the most common and costly mistakes in incident response. Confirm that attacker access has been revoked across all affected accounts and systems, that compromised credentials have been reset, that the initial access vector has been identified and closed, and that monitoring is in place to detect any re-entry attempts. ### Establish a Recovery Command Structure Incident response and business recovery require different skills and different leadership. Designate a Recovery Lead — ideally someone from operations or business leadership, not your security team — to coordinate the recovery effort. Your security team should remain focused on forensic investigation and monitoring while the Recovery Lead manages the restoration of business operations. Create a clear chain of communication. Who reports to whom? Who authorizes decisions about system restoration priority? Who speaks to customers, regulators, and the press? Establishing this structure before the chaos peaks is essential. ### Assess the Blast Radius Work with your incident response team to document exactly what was affected. Determine which systems, data, and services were compromised, encrypted, destroyed, or accessed without authorization. Categorize the impact into operational impact (which business processes are disrupted), data impact (what data was accessed, exfiltrated, or destroyed), and financial impact (revenue loss, recovery costs, potential fines). This assessment drives every decision that follows — what to restore first, who to notify, and what to tell stakeholders. ## Week 1: Begin Restoration and Notification ### Prioritize System Restoration by Business Impact Not all systems are equally critical. Work with business unit leaders to rank systems by their impact on revenue, customer commitments, and safety. Restore the systems that keep your business running first, then work outward to supporting systems and lower-priority services. For each system, decide whether to restore from backup, rebuild from scratch, or implement a temporary workaround. Restoring from backup is faster but requires confidence that your backups are clean and weren't compromised. Rebuilding takes longer but ensures a known-good state. Document every restoration decision and the rationale behind it. ### Activate Your Legal and Regulatory Notification Obligations Data breach notification laws vary by jurisdiction, and failing to notify on time carries its own penalties. In the United States, 50 states plus the District of Columbia, Guam, Puerto Rico, and the U.S. Virgin Islands all have separate breach notification laws. Notification timelines range from 30 to 90 days depending on the state, with some states requiring notification "without unreasonable delay." At the federal level, HIPAA requires notification within 60 days for breaches affecting 500 or more individuals. The SEC requires publicly traded companies to disclose material cybersecurity incidents within four business days of determining materiality. Defense contractors have 72-hour notification requirements under DFARS. If you have EU customers or employees, GDPR requires notification to the relevant Data Protection Authority within 72 hours of becoming aware of a breach involving personal data, and notification to affected individuals "without undue delay" if the breach poses a high risk to their rights and freedoms. Engage your breach counsel early. They will help you map your notification obligations based on the data involved, the jurisdictions affected, and the nature of the incident. Getting this wrong creates legal exposure on top of the operational disruption you're already managing. ### Notify Your Cyber Insurance Carrier If you haven't already, formally notify your carrier in writing. Provide a summary of what happened, what data was affected, and what response actions have been taken. Request approval for any recovery expenditures that you expect the policy to cover. Keep your carrier informed throughout the recovery process — surprises during the claims process rarely end well. ## Weeks 2 Through 4: Communicate with Stakeholders Communication after a breach is where many organizations do the most lasting damage — not from the breach itself, but from how they handle the message. Silence, deflection, and corporate jargon erode trust far more than the incident itself. ### Communicating with Customers Customers want to know three things: what happened, how it affects them, and what you're doing about it. Tell them clearly and directly. Avoid vague language like "a security event" when what happened was a ransomware attack or data exfiltration. Acknowledge the impact honestly, explain what steps you've taken to contain and remediate the incident, describe what you're doing to prevent recurrence, and provide specific actions they should take (change passwords, monitor accounts, enroll in credit monitoring if applicable). Provide a dedicated channel for questions — a phone number, email address, or web page — and staff it with people who can actually answer questions. Nothing frustrates an affected customer more than being routed to a generic support queue. ### Communicating with Employees Your employees are stakeholders too, and they're often the most anxious. They want to know whether their personal data was affected, whether their jobs are at risk, and what the company is doing. Be transparent with your workforce. If employee data was compromised, tell them immediately with the same specificity and support you'd offer customers. Provide clear guidance on what they should do to protect themselves. Also address operational concerns. If workflows have changed, systems are unavailable, or processes are disrupted, give employees clear instructions on interim procedures. The faster you reduce uncertainty, the faster productivity recovers. ### Communicating with Regulators Regulatory communications should be factual, precise, and managed by your legal team. Provide the information required by the relevant notification statute and nothing more. Voluntary over-disclosure can create additional legal exposure. Your breach counsel will advise on the appropriate level of detail for each jurisdiction and regulator. ### Communicating with the Media If your breach attracts media attention, designate a single spokesperson and prepare a written statement. Keep the statement factual, empathetic, and forward-looking. Acknowledge what happened, express concern for affected individuals, and outline the steps you're taking. Avoid speculation about the attacker, the scope of the breach (until you're confident in your assessment), or blame. Do not say "we take security seriously" — it has become a meaningless cliche that signals the opposite of what you intend. If you have a communications or PR team, activate them immediately. If you don't, your cyber insurance policy likely includes access to crisis communications professionals. Use them. ### Communicating with Partners and Vendors If the breach affects data you share with partners or vendors, or if it originated through a supply chain compromise, those partners need to be notified promptly. Beyond legal obligations, maintaining trust with business partners requires honesty and speed. Provide them with enough technical detail to assess their own exposure and take protective action. ## Months 1 Through 3: Recover and Rebuild ### Conduct a Post-Incident Review Once the immediate crisis has passed, conduct a thorough post-incident review (sometimes called a "lessons learned" or "after-action" review). This should involve everyone who participated in the response, including IT, security, legal, communications, executive leadership, and any external parties (forensics firms, breach counsel, insurance carrier). The review should document the full timeline of the incident from initial compromise to detection to containment to recovery. Identify what worked well in the response and what didn't. Assess where detection was too slow and why. Evaluate whether the incident response plan was followed and where it broke down. Catalog specific improvements needed in technology, process, and people. The output of this review should be a prioritized action plan, not a shelf document. Assign owners and deadlines to every improvement item. ### Address Root Causes, Not Just Symptoms If the attacker gained access through an unpatched VPN appliance, patching that appliance is necessary but insufficient. The root cause question is: why wasn't it patched? Was there no vulnerability management program? Was there a program but no enforcement? Was there enforcement but no visibility into that asset? Dig until you find the systemic issue and fix that. Otherwise, the next incident will follow a different path to the same outcome. ### Rebuild Trust Through Visible Action Customers, partners, and employees will judge your organization not by the breach, but by your response to it. Organizations that communicate transparently, act decisively, and demonstrably improve their security posture often emerge with stronger relationships than they had before. Consider publishing a summary of the improvements you've made (without revealing specific vulnerabilities). Offer affected customers ongoing monitoring or protection. If appropriate, share anonymized lessons learned with your industry peers or through ISACs (Information Sharing and Analysis Centers). ## Building Long-Term Resilience ### Update Your Incident Response Plan If your plan didn't work perfectly during the incident — and no plan survives first contact — update it based on what you learned. Test the updated plan through a tabletop exercise within 90 days of the incident. ### Invest in Detection and Response Gaps The post-incident review will almost certainly reveal gaps in your detection and response capabilities. Whether that means deploying managed detection and response, improving log retention and analysis, or adding identity threat detection, invest in closing the gaps that allowed the incident to progress as far as it did. ### Establish a Regular Cadence of Testing Tabletop exercises should happen at least twice a year, with at least one involving executive leadership and external partners (legal, insurance, communications). Penetration testing should occur annually at minimum. Backup restoration tests should happen quarterly. Recovery readiness isn't something you build once. It's something you practice continuously. *** ## Key Takeaways The breach itself is rarely what destroys an organization. It's the slow, fumbled, opaque response that follows. Having a recovery playbook, clear communication templates, and a practiced command structure transforms a crisis into a manageable business challenge. Prepare for the aftermath with the same rigor you apply to prevention. *** [*ContraForce helps organizations detect, respond to, and recover from security incidents with clarity and speed. Learn more about our platform.*](https://www.contraforce.com) # 10 Ways ContraForce Uniquely Automates Multi-Tenant Management of Microsoft Sentinel and Defender Source: https://docs.contraforce.com/blog/agentic-ai/10-ways-multi-tenant-automation Discover the 10 unique ways ContraForce automates multi-tenant management of Microsoft Sentinel and Microsoft Defender for Endpoint. **Who is this for?** MSP/MSSP Partners, Security Engineers **April 25, 2025** · ContraForce Team · 5 min read Managing Microsoft Sentinel and Defender for Endpoint across multiple customer tenants presents significant operational challenges. Here are 10 ways ContraForce uniquely automates multi-tenant security operations. ## 1. Unified Incident Queue All incidents from all customer tenants flow into a single, prioritized queue: * No portal pivoting between customer environments * Severity-based prioritization across the entire portfolio * Context-aware grouping of related incidents ## 2. Cross-Tenant Entity Enrichment When investigating an entity, ContraForce automatically enriches it with data from the relevant customer tenant: * User sign-in history from Entra ID * Device details from Defender for Endpoint * Activity logs from Microsoft 365 ## 3. Gamebook-Driven Response Pre-built response workflows execute consistently across all tenants: * Same investigation steps regardless of customer * Consistent documentation and audit trails * Reduced training burden for analysts ## 4. Automated Gamebook Mapping Incidents automatically map to appropriate Gamebooks based on type and severity: * No manual selection required * Consistent handling of similar incidents * Faster time to first action ## 5. Security Delivery Agents AI agents autonomously handle investigation and response: * Triage incidents at machine speed * Execute response actions with supervision * Document findings automatically ## 6. Centralized Detection Management (CMS) Deploy and manage detection rules across all customer Sentinel workspaces: * Toggle-based rule deployment * Bulk operations across tenants * Version control and rollback ## 7. Multi-Tenant Response Actions Execute response actions in any customer tenant without context switching: * Isolate devices across tenants * Disable accounts in any customer Entra ID * Block threats portfolio-wide ## 8. Unified Reporting Generate reports across your entire customer portfolio: * Incident trends across all customers * Response time metrics * Coverage and gap analysis ## 9. Customer-Aware Context Every action is performed in the context of the right customer: * Automatic tenant selection * Customer-specific configurations respected * Audit trails per customer ## 10. Scalable Architecture The platform scales with your customer base: * Add customers without adding complexity * Consistent performance as you grow * No per-tenant infrastructure to manage ## The Cumulative Effect These 10 capabilities combine to enable: | Metric | Without ContraForce | With ContraForce | | ---------------------------- | ------------------- | ---------------- | | **Customers per analyst** | 10-15 | 100+ | | **Mean time to investigate** | 30+ minutes | Minutes | | **Response consistency** | Variable | 100% | | **Portal pivoting** | Constant | Eliminated | ## Quick Summary * Unified incident queue eliminates portal pivoting with severity-based prioritization across all customers. * Gamebooks and Security Delivery Agents ensure consistent, automated investigation and response. * Centralized Detection Management (CMS) enables toggle-based rule deployment across all Sentinel workspaces. * Multi-tenant response actions and customer-aware context enable portfolio-wide threat blocking. * The result: 100+ customers per analyst, minutes to investigate, and 100% response consistency. Explore multi-tenant capabilities Configure AI automation Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # How MSSPs Can Implement the New CISA Guidance for SIEM and SOAR Source: https://docs.contraforce.com/blog/agentic-ai/cisa-siem-soar-guidance Understanding the new CISA guidance for SIEM and SOAR and how MSSPs can implement these recommendations with ContraForce. **Who is this for?** MSP/MSSP Partners, Security Engineers **June 10, 2025** · ContraForce Team · 4 min read CISA has released new guidance for organizations implementing SIEM and SOAR solutions. For MSSPs managing security operations across multiple customers, this guidance has significant implications for how you deliver services. ## Key CISA Recommendations The guidance emphasizes several critical areas: ## 1. Centralized Log Collection CISA recommends organizations centralize security logs from all critical systems. For MSSPs, this means: * Ensuring comprehensive log coverage across customer environments * Normalizing data for consistent analysis * Maintaining appropriate retention periods ## 2. Automated Detection and Response The guidance strongly advocates for automation to reduce response times: * Automated triage of common alert types * Pre-defined response playbooks for known threats * Reduced mean time to respond (MTTR) ## 3. Threat Intelligence Integration CISA emphasizes the importance of threat intelligence: * Integration with threat intel feeds * Automated correlation with known indicators * Context-aware alerting ## How ContraForce Helps MSSPs Comply ContraForce is designed to help MSSPs implement these recommendations across their entire customer base: ## Centralized Operations * Unified view of all customer Microsoft Sentinel and Defender for Endpoint environments * Consistent log ingestion and normalization * Multi-tenant visibility without portal pivoting ## Automated Response * Gamebooks provide pre-defined response workflows * Security Delivery Agents automate investigation and response * Consistent outcomes across all customer environments ## Built-in Intelligence * Entity enrichment with threat intelligence * Automated correlation of indicators * Risk-based prioritization ## Implementation Roadmap For MSSPs looking to align with CISA guidance: | Phase | Focus Area | ContraForce Capability | | ----- | ---------------------- | ------------------------------ | | **1** | Log centralization | Microsoft Sentinel integration | | **2** | Detection deployment | CMS for rule management | | **3** | Response automation | Gamebook workflows | | **4** | Continuous improvement | Security Delivery Agents | ## Quick Summary * CISA guidance emphasizes centralized log collection, automated detection/response, and threat intelligence integration. * MSSPs must implement these capabilities across their entire customer base. * ContraForce provides centralized operations, Gamebook-driven automation, and built-in threat intelligence. * A phased implementation roadmap helps MSSPs align with CISA recommendations using ContraForce capabilities. Connect Microsoft Sentinel Deploy detection content Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # 7 Essential Features to Become a Managed Security Service Provider Source: https://docs.contraforce.com/blog/agentic-ai/mssp-essential-features The 7 essential features and capabilities needed to become a successful managed security service provider. **Who is this for?** MSP/MSSP Partners, Security Leaders **March 4, 2025** · ContraForce Team · 5 min read Transitioning from a traditional MSP to a managed security service provider (MSSP) requires specific capabilities. Here are the 7 essential features you need to successfully deliver managed security services. ## 1. Multi-Tenant Security Visibility You need to see security events across all customer environments: * **Unified dashboard** — Single view of all customer incidents * **Cross-tenant search** — Find threats portfolio-wide * **Customer context** — Understand each customer's environment Without multi-tenant visibility, you'll spend more time switching between environments than actually securing them. ## 2. Incident Detection and Triage You need the ability to detect and prioritize security incidents: * **SIEM integration** — Connect to customer security tools * **Alert correlation** — Group related alerts into incidents * **Priority scoring** — Focus on what matters most Detection is the foundation of security services. Without it, you're reacting to customer complaints, not proactively protecting them. ## 3. Investigation Capabilities When incidents occur, you need tools to investigate: * **Entity enrichment** — Context about users, devices, IPs * **Timeline views** — Understand the sequence of events * **Log search** — Dig into raw data when needed Investigation speed directly impacts your ability to contain threats before they cause damage. ## 4. Response Automation You need the ability to take action on threats: * **Containment actions** — Isolate devices, disable accounts * **Remediation workflows** — Standardized response procedures * **Supervised automation** — AI-assisted response with oversight Manual response doesn't scale. Automation is essential for profitable security delivery. ## 5. Reporting and Documentation You need to demonstrate value to customers: * **Incident reports** — Documentation of what happened and what you did * **Trend analysis** — Show improvement over time * **Compliance support** — Help customers meet requirements Reporting justifies your value and supports customer compliance needs. ## 6. Customer Communication You need efficient ways to communicate with customers: * **Notification automation** — Keep customers informed without manual effort * **Escalation procedures** — Clear paths for critical issues * **Self-service portals** — Let customers see their security status Good communication builds trust and reduces support burden. ## 7. Operational Scalability You need an operating model that scales: * **Standardized processes** — Consistent delivery across all customers * **Automation** — Reduce manual effort per customer * **Platform leverage** — Technology that multiplies analyst effectiveness Scalability is what makes security services profitable. ## Building Your MSSP Practice | Feature | DIY Approach | Platform Approach | | --------------------------- | -------------------- | ------------------------ | | **Multi-tenant visibility** | Per-tenant portals | Unified platform | | **Detection** | Custom per customer | Centralized management | | **Investigation** | Manual, tool-hopping | Integrated workflow | | **Response** | Custom playbooks | Standardized Gamebooks | | **Reporting** | Manual reports | Automated dashboards | | **Communication** | Email/phone | Integrated notifications | | **Scalability** | Linear growth | Exponential leverage | ## Quick Summary * MSSPs need multi-tenant visibility, strong detection and triage, and fast investigations to protect all customers effectively. * Scalable response automation and standardized workflows are critical to keeping security services profitable. * Clear reporting, documentation, and communication prove ongoing value and support customer compliance. * Operational scalability, powered by automation and a unified platform, turns linear effort into leveraged growth. * A platform approach replaces fragmented DIY tools with integrated capabilities across visibility, response, and reporting. Get started with ContraForce Explore multi-tenant capabilities Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Security Delivery Platform: Re-imagining Security Services Source: https://docs.contraforce.com/blog/agentic-ai/security-delivery-platform-reimagining How Security Delivery Platforms are reimagining managed security services for MSPs and MSSPs. **Who is this for?** MSP/MSSP Partners, Security Leaders **February 28, 2025** · ContraForce Team · 5 min read The managed security services market is evolving. Traditional approaches that worked a decade ago are struggling to scale with modern threats and customer expectations. Security Delivery Platforms represent a fundamental reimagining of how security services are delivered. ## The Problem with Traditional MSSP Models Traditional MSSP delivery models face significant challenges: ## Scale Limitations * **Analyst-dependent** — Every customer requires human attention * **Linear growth** — Adding customers means adding headcount * **Margin pressure** — Labor costs erode profitability ## Consistency Challenges * **Knowledge silos** — Expertise concentrated in individuals * **Variable quality** — Outcomes depend on who's working * **Training burden** — Constant investment in skill development ## Technology Fragmentation * **Portal pivoting** — Jumping between customer environments * **Inconsistent tooling** — Different approaches per customer * **Integration overhead** — Custom work for each deployment ## The Security Delivery Platform Approach Security Delivery Platforms fundamentally rethink service delivery: ## Multi-Tenant by Design * Single platform, all customers * No portal pivoting * Consistent visibility and control ## Automation First * AI agents for investigation and response * Gamebook workflows for consistency * Human oversight, not human dependency ## Platform Native * Deep integration with security ecosystems * Native capabilities, not bolt-ons * Continuous improvement through platform updates ## Key Capabilities of a Security Delivery Platform | Capability | Traditional MSSP | Security Delivery Platform | | ----------------------- | ---------------------- | --------------------------- | | **Customer visibility** | Per-tenant portals | Unified multi-tenant view | | **Investigation** | Manual, analyst-driven | AI-assisted, automated | | **Response** | Custom per customer | Standardized Gamebooks | | **Scale** | Linear with headcount | Exponential with automation | | **Consistency** | Varies by analyst | Enforced by platform | ## The Economic Impact Security Delivery Platforms change the economics of managed security: * **More customers per analyst** — 10x improvement possible * **Lower cost per incident** — Automation reduces unit economics * **Higher margins** — Scale without proportional cost increase * **Better outcomes** — Consistency improves customer satisfaction ## Getting Started For service providers considering a Security Delivery Platform: 1. **Assess current model** — Understand your scale limitations 2. **Evaluate platforms** — Look for multi-tenant, automation-first design 3. **Start with core use cases** — Don't try to transform everything at once 4. **Measure outcomes** — Track improvements in efficiency and quality ## Quick Summary * Traditional MSSP models face scale, consistency, and technology fragmentation challenges. * Security Delivery Platforms are multi-tenant by design with automation-first architecture. * Key benefits: 10x more customers per analyst, lower cost per incident, and consistent outcomes. * Platform-native integration eliminates portal pivoting and custom per-customer work. * Start by assessing your current model and evaluating platforms with multi-tenant automation. Learn about ContraForce Explore AI-powered automation Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # The SIEM Vendor Landscape Is Changing. What Does That Mean for MDR Providers? Source: https://docs.contraforce.com/blog/agentic-ai/siem-vendor-landscape Understanding the evolving SIEM vendor landscape and its implications for MDR providers and managed security services. **Who is this for?** MSP/MSSP Partners, Security Leaders **May 13, 2024** · ContraForce Team · 4 min read The SIEM market is undergoing significant transformation. Major acquisitions, new entrants, and evolving technology are reshaping how organizations approach security information and event management. For MDR providers, these changes present both challenges and opportunities. ## What's Changing ## Market Consolidation We've seen significant M\&A activity in the SIEM space: * Major vendors acquiring complementary technologies * Cloud-native SIEM platforms gaining market share * Traditional on-premises solutions facing migration pressure ## Technology Evolution SIEM capabilities are expanding: * **XDR convergence** — SIEM and XDR boundaries blurring * **Cloud-native architectures** — Scalability without infrastructure management * **AI/ML integration** — Automated detection and investigation * **SOAR convergence** — Response automation built-in ## Customer Expectations End customers expect more from their security investments: * Faster time to value * Reduced operational complexity * Better outcomes, not just more alerts ## Implications for MDR Providers ## Platform Strategy MDR providers need to consider: * Which SIEM platforms to support * How to manage multi-platform environments * Investment in platform-specific expertise ## Service Differentiation As SIEM capabilities become more commoditized: * Outcomes matter more than technology * Operational excellence becomes differentiator * Customer experience drives retention ## Economic Considerations Changing economics affect profitability: * Cloud SIEM pricing models vary significantly * Platform consolidation may reduce complexity * Automation is essential for margin protection ## How to Navigate the Change ## Build on Strong Foundations Focus on platforms with: * Strong market position and investment * Clear roadmap and vision * Robust partner ecosystem ## Invest in Operations Regardless of underlying SIEM: * Standardize your operational model * Automate repetitive tasks * Focus on outcomes over activities ## Stay Platform-Agnostic Maintain flexibility: * Abstract your operations from specific platforms * Build expertise across multiple technologies * Use multi-platform tools for consistency ## ContraForce Approach ContraForce helps MDR providers navigate this changing landscape by providing: * **Multi-platform support** — Work across Microsoft, Splunk, CrowdStrike, and IBM * **Consistent operations** — Same Gamebooks and workflows regardless of platform * **Microsoft focus** — Deepest integration with the fastest-growing ecosystem ## Quick Summary * The SIEM market is transforming through consolidation, cloud-native platforms, and XDR/SOAR convergence. * MDR providers must decide which platforms to support and how to differentiate on outcomes, not technology. * Automation is essential for protecting margins as cloud SIEM pricing models evolve. * ContraForce provides multi-platform support with consistent operations and deep Microsoft integration. Learn about ContraForce Explore multi-tenant capabilities Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # What Are Security Delivery Agents? Understanding Agentic AI in Security Operations Source: https://docs.contraforce.com/blog/agentic-ai/what-are-security-delivery-agents Security Delivery Agents are autonomous AI agents that investigate and respond to security incidents — not chatbots, not copilots, but agents that take action on your behalf. **Who is this for?** Security Engineers, CISOs, and Technical Decision-Makers **February 2026** · ContraForce Team · 6 min read The term "AI" gets applied to everything from simple automation to sophisticated reasoning systems. In security operations, understanding the difference matters — because the gap between a chatbot and an autonomous agent is the gap between answering questions and actually solving problems. ## Copilots vs. Agents: A Critical Distinction Most AI tools in security today are **copilots** — they assist humans but don't act independently. A copilot might suggest a query, summarize an alert, or draft a response. But the human still makes decisions and executes actions. **Agents** are different. An agent: * Perceives its environment (incoming incidents, entity data, historical context) * Reasons about what to do (investigation steps, response actions) * Takes action autonomously (executes queries, runs playbooks, updates incidents) * Learns from outcomes (refines recommendations based on results) Security Delivery Agents in ContraForce are true agents. They don't wait for you to ask questions — they investigate incidents, gather context, and execute responses based on your configured policies. ## Why Security Operations Needs Agents Security operations has a structural problem: the volume of incidents exceeds human capacity to investigate them thoroughly. Most SOC teams operate in triage mode, quickly classifying alerts and hoping the important ones get attention. Copilots don't solve this problem. They make individual analysts slightly faster, but they don't change the fundamental math. You still need a human in the loop for every incident. Agents change the equation by handling incidents end-to-end: | Capability | Copilot | Agent | | ------------------- | -------------------------- | --------------------------------------------------------- | | Analyze an incident | Suggests analysis steps | Performs analysis automatically | | Gather context | Recommends what to look up | Queries sign-in logs, device timelines, related incidents | | Determine response | Suggests actions to take | Executes response actions through Gamebooks | | Document findings | Drafts notes for review | Writes incident comments automatically | | Handle volume | One incident at a time | Processes incidents in parallel across workspaces | ## What "Agentic" Actually Means The term "agentic AI" describes systems that act with autonomy toward goals. Key properties include: **Goal-directed behavior** — Agents work toward objectives (investigate this incident, contain this threat) rather than responding to individual prompts. **Persistent context** — Agents maintain awareness of the environment across multiple interactions, understanding how entities relate and how incidents connect. **Tool use** — Agents invoke external systems (query APIs, execute playbooks, update records) to accomplish their goals. **Adaptive execution** — Agents adjust their approach based on what they discover, rather than following rigid scripts. Security Delivery Agents exhibit all these properties. When an incident arrives, the agent determines what investigation is needed, gathers relevant context, decides on appropriate response actions, and executes them — all without human intervention for routine cases. ## The Trust Question Autonomous agents raise an obvious concern: how do you trust an AI to take security actions in production? ContraForce addresses this through progressive autonomy: 1. **Start manual** — Run agent investigations on-demand and review every output 2. **Automate investigation** — Let agents analyze incidents automatically, but review before action 3. **Enable response** — Allow agents to execute Gamebooks, with confidence thresholds controlling when actions proceed This phased approach lets you build confidence in agent behavior before granting broader autonomy. You also maintain human-in-the-loop controls for sensitive actions and comprehensive audit trails for everything agents do. ## The Future of Security Operations Agentic AI represents a fundamental shift in how security operations can work. Instead of humans doing repetitive investigation with AI assistance, agents handle routine work while humans focus on judgment calls, exception handling, and strategic improvements. This isn't about replacing analysts. It's about making analyst capacity go further — handling the incident volume that would otherwise be impossible to address thoroughly. ## Quick Summary * Copilots assist humans; agents act autonomously toward goals * Security Delivery Agents investigate incidents, gather context, and execute responses * Agentic AI properties: goal-directed, persistent context, tool use, adaptive execution * Progressive autonomy lets you build trust before enabling full automation * Agents handle volume; humans handle judgment and strategy Configure Security Delivery Agents in your environment Deploy the infrastructure that powers autonomous agents Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Named Security Orchestration Solution of the Year in 2025 CyberSecurity Breakthrough Awards Source: https://docs.contraforce.com/blog/company/cybersecurity-breakthrough-awards-2025 ContraForce has been named Security Orchestration Solution of the Year in the 2025 CyberSecurity Breakthrough Awards program. **Who is this for?** All ContraForce partners and customers **October 9, 2025** · ContraForce Team · 2 min read ContraForce today announced it has been named "Security Orchestration Solution of the Year" in the 2025 CyberSecurity Breakthrough Awards program conducted by CyberSecurity Breakthrough, a leading independent market intelligence organization that recognizes the top companies, technologies, and products in the global information security market today. The CyberSecurity Breakthrough Awards program is devoted to honoring excellence and recognizing the innovation, hard work, and success in a range of information security categories, including Cloud Security, Threat Detection, Risk Management, Fraud Prevention, Mobile Security, Email Security, and many more. "We are incredibly honored to receive this recognition from CyberSecurity Breakthrough," said Stan Golubchik, CEO and Co-Founder of ContraForce. "This award validates our approach to security orchestration — making it possible for service providers to automate and scale their security operations without the complexity typically associated with traditional SOAR platforms." ContraForce's Security Delivery Platform enables MSPs and MSSPs to orchestrate security operations across Microsoft Sentinel, Defender for Endpoint, and other security tools through a unified, multi-tenant platform. The platform's Gamebook-driven workflows and Security Delivery Agents automate incident investigation and response, reducing manual effort and improving consistency across customer environments. The mission of the CyberSecurity Breakthrough Awards is to honor excellence and recognize innovation in the information security industry. This year's program attracted thousands of nominations from across the globe. ## About ContraForce ContraForce is an AI-powered Security Delivery Platform built to help service providers deliver scalable MXDR and security outcomes across every customer they support. ContraForce operationalizes Microsoft Sentinel, Defender for Endpoint, Entra ID, and Azure AI into a unified, multi-tenant platform that enables service providers to investigate, respond, and automate security faster and more cost effectively. Learn about Gamebook automation Get started with ContraForce Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce's New US Distribution Agreement with Ingram Micro Source: https://docs.contraforce.com/blog/company/ingram-micro-distribution ContraForce announces a US distribution agreement with Ingram Micro, making it easier for MSPs to access the ContraForce Security Delivery Platform. **Who is this for?** MSP/MSSP Partners in the United States **December 17, 2024** · ContraForce Team · 2 min read ContraForce is pleased to announce a new US distribution agreement with Ingram Micro, one of the world's largest technology distributors. This partnership will allow US-based MSPs to access the ContraForce Security Delivery Platform through Ingram Micro's extensive distribution network. "Partnering with Ingram Micro represents a significant expansion of our go-to-market capabilities in the United States," said Stan Golubchik, CEO and Co-Founder of ContraForce. "Ingram Micro's extensive network and deep relationships with MSPs will help us reach more service providers who are looking to scale their security operations." ## What This Means for MSPs Through this distribution agreement, US-based MSPs can: * **Access ContraForce through Ingram Micro** — Leverage existing Ingram Micro relationships * **Maximize Microsoft investment** — Operationalize Microsoft Sentinel and Defender for Endpoint * **Scale security delivery** — Deliver consistent security outcomes across all customers ## About Ingram Micro Ingram Micro is a leading technology distributor with a global presence and deep expertise in helping partners deliver value to their customers. Their Cloud platform provides access to a curated marketplace of cloud solutions. ## About ContraForce ContraForce is an AI-powered Security Delivery Platform built to help service providers deliver scalable MXDR and security outcomes across every customer they support. Get started with ContraForce Explore multi-tenant capabilities Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Selected for Microsoft for Startups Pegasus Program Source: https://docs.contraforce.com/blog/company/microsoft-pegasus-program ContraForce has been selected for the Microsoft for Startups Pegasus Program, recognizing our innovative approach to security service delivery. **Who is this for?** All ContraForce partners and customers **March 26, 2025** · ContraForce Team · 2 min read ContraForce is excited to announce our selection for the Microsoft for Startups Pegasus Program. This elite program is designed for high-growth B2B startups that are building innovative solutions on Microsoft technology. The Pegasus Program provides advanced support, resources, and access to Microsoft's enterprise customer network, helping selected startups accelerate their growth and market presence. "Being selected for the Pegasus Program is a significant recognition of ContraForce's commitment to building enterprise-grade security solutions on Microsoft technology," said Stan Golubchik, CEO and Co-Founder of ContraForce. "This partnership will help us accelerate our mission of making enterprise-grade security accessible to service providers of all sizes." ## What This Means for Partners ContraForce's participation in the Pegasus Program strengthens our Microsoft relationship and provides: * **Deeper Microsoft integration** — Enhanced collaboration with Microsoft product teams * **Enterprise resources** — Access to advanced technical and business support * **Market acceleration** — Opportunities to reach more enterprise customers ## Built on Microsoft ContraForce is purpose-built for the Microsoft security stack: | Integration | Capability | | ------------------------- | ------------------------------------------------------ | | **Microsoft Sentinel** | Incident ingestion, log search, CMS detection rules | | **Defender for Endpoint** | Defender incidents, device isolation, file quarantine | | **Microsoft Entra ID** | Sign-in logs, user account actions, session revocation | | **Azure AI Foundry** | Infrastructure for Security Delivery Agents | Connect Microsoft Sentinel Deploy Defender for Endpoint integration Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Recognized as a Microsoft Security Excellence Awards Finalist for Security Software Development Company Source: https://docs.contraforce.com/blog/company/microsoft-security-excellence-finalist ContraForce has been named a finalist in the Microsoft Security Excellence Awards for Security Software Development Company, recognizing our innovation and customer impact in the security landscape. **Who is this for?** All ContraForce partners and customers **November 19, 2025** · ContraForce Team · 2 min read Dallas, Texas, United States — ContraForce today announced it is a Security Software Development Company award finalist in the Microsoft Security Excellence Awards. The company was honored among a global field of industry leaders that demonstrated exceptional innovation, engineering excellence, and customer impact across the security landscape over the past 12 months. "We are incredibly proud to be recognized as a finalist for Security Software Development Company," said Stan Golubchik, CEO and Co-Founder of ContraForce. "Our team has built with purpose from day one, focused on helping service providers deliver security at scale with automation and AI. This recognition reflects our deep alignment with Microsoft's security vision and our commitment to making high-quality security delivery accessible for all." At the Microsoft Security Excellence Awards on January 26, 2026, Microsoft will honor finalists in six award categories that highlight partner trailblazers, solution innovators, customer and technology champions, and changemakers. This is the sixth year Microsoft has recognized partners for outstanding contributions in the global security ecosystem. All finalists are members of the Microsoft Intelligent Security Association (MISA), a community of leading security vendors whose solutions integrate with Microsoft's security technologies to protect customers against evolving threats. "I am very pleased to extend my warmest congratulations to this year's finalists for the Microsoft Security Excellence Awards. These are presented each year to recognize the outstanding achievements of our Microsoft Intelligent Security Association members as they improve customers' ability to identify and respond to security threats. Our community is made up of the most reliable and trusted security vendors worldwide. This year we received hundreds of quality submissions from partners and Microsoft stakeholders, so this year's finalists stood out in a crowd of exceptional talent. It is my pleasure to acknowledge and celebrate their work over the past year," said Maria Thomson, Director, Microsoft Intelligent Security Association. MISA was created to bring together Microsoft leaders, software development companies, and services partners to collaborate in defending against sophisticated security threats and making the world safer. MISA members and Microsoft security leaders will vote to determine this year's winners, providing an opportunity for peers to recognize exceptional contributions to shared customers. ## About ContraForce ContraForce is an AI-powered Security Delivery Platform built to help service providers deliver scalable MXDR and security outcomes across every customer they support. ContraForce operationalizes Microsoft Sentinel, Defender for Endpoint, Entra ID, and Azure AI into a unified, multi-tenant platform that enables service providers to investigate, respond, and automate security faster and more cost effectively. The company's mission is to make enterprise-grade security accessible for all businesses through automation, AI, and Microsoft-native integrations. Learn more at [contraforce.com](https://www.contraforce.com). Connect Microsoft Sentinel to ContraForce Deploy Defender for Endpoint integration Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Honored as 2024 SC Awards Winner Source: https://docs.contraforce.com/blog/company/sc-awards-winner-2024 ContraForce has been honored as a winner in the 2024 SC Awards, recognizing excellence in cybersecurity solutions. **Who is this for?** All ContraForce partners and customers **September 18, 2024** · ContraForce Team · 2 min read ContraForce is proud to announce that we have been honored as a winner in the 2024 SC Awards. The SC Awards are one of the most prestigious recognitions in the cybersecurity industry, celebrating the best solutions, services, and professionals who work to protect organizations from cyber threats. This recognition reflects ContraForce's commitment to innovation in security service delivery and our focus on helping MSPs and MSSPs scale their security operations effectively. "Being recognized as an SC Awards winner validates the hard work our team has put into building a platform that truly serves the needs of managed security service providers," said Stan Golubchik, CEO and Co-Founder of ContraForce. "We're honored to be recognized alongside so many innovative companies in the cybersecurity space." The SC Awards evaluate solutions across multiple criteria including innovation, customer satisfaction, and real-world impact. ContraForce's platform stood out for its unique approach to multi-tenant security operations and AI-driven automation. ## About ContraForce ContraForce is an AI-powered Security Delivery Platform built to help service providers deliver scalable MXDR and security outcomes across every customer they support. Learn about the ContraForce platform Explore multi-tenant capabilities Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Completes SOC 2 Type II for the Fourth Time Source: https://docs.contraforce.com/blog/company/soc-2-type-ii-fourth-time ContraForce has completed SOC 2 Type II certification for the fourth consecutive time, demonstrating ongoing commitment to security and trust. **Who is this for?** All ContraForce partners and customers **December 5, 2024** · ContraForce Team · 2 min read ContraForce is proud to announce the successful completion of our fourth consecutive SOC 2 Type II audit. This achievement demonstrates our continued commitment to maintaining the highest standards of security, availability, and confidentiality. SOC 2 Type II is a rigorous third-party audit that evaluates an organization's controls over an extended period, typically 6-12 months. Unlike a Type I audit, which evaluates controls at a specific point in time, Type II provides assurance that controls are not only designed properly but are also operating effectively over time. "Completing our fourth SOC 2 Type II audit reflects our unwavering commitment to security and trust," said Stan Golubchik, CEO and Co-Founder of ContraForce. "Our partners and their customers can be confident that ContraForce maintains the highest standards of operational security." ## Continuous Security Commitment This fourth successful completion demonstrates: * **Consistent excellence** — Four consecutive years of meeting SOC 2 Type II requirements * **Operational maturity** — Controls that work effectively day in and day out * **Partner confidence** — Assurance that data is protected by proven security practices ## About SOC 2 Type II The SOC 2 framework, developed by the American Institute of CPAs (AICPA), evaluates controls related to: * Security * Availability * Processing integrity * Confidentiality * Privacy ContraForce's SOC 3 report, which provides a summary of our SOC 2 Type II audit results, is available for partners who require it for their own compliance documentation. Get started with ContraForce Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # The Complete Cyber Insurance Buying Guide: What Every Business Needs to Know Before, During, and After a Policy Source: https://docs.contraforce.com/blog/complete-cyber-insurance-buying-guide Cyber insurance has gone from a niche product to a business necessity in just a few years. But buying the right policy is confusing, filing a claim is stressful, and too many organizations discover gaps in their coverage only after an incident. This guide covers the entire lifecycle — from understanding what cyber insurance actually covers to navigating the claims process when things go wrong. *** ## What Cyber Insurance Actually Covers Cyber insurance policies generally fall into two broad categories of coverage: first-party and third-party. **First-party coverage** protects your organization directly. This typically includes incident response costs (forensics, legal counsel, crisis communications), business interruption losses caused by a cyber event, data restoration expenses, ransomware payments and negotiation costs (where legally permitted), notification costs for informing affected individuals, and credit monitoring services for impacted customers or employees. **Third-party coverage** protects you against claims from others. This includes legal defense costs if you're sued after a breach, regulatory fines and penalties (where insurable by law), settlements or judgments from affected parties, and media liability related to data breaches. Some policies bundle both into a single package. Others are modular, letting you select coverage areas individually. The specifics vary significantly between carriers, which is why reading the actual policy language — not just the marketing summary — matters. ## What Cyber Insurance Typically Does Not Cover Understanding exclusions is just as important as understanding coverage. Common exclusions include: **Prior known incidents.** If you were aware of a vulnerability or breach before the policy period and didn't disclose it, the resulting claim will almost certainly be denied. **Failure to maintain minimum security standards.** Many policies include a "minimum security requirements" clause. If you represented that you had multi-factor authentication deployed but didn't, or claimed you patched critical vulnerabilities within 30 days but didn't, the carrier can deny the claim. **Nation-state attacks.** Some policies include a "war exclusion" or "hostile act" exclusion that can apply to cyberattacks attributed to foreign governments. This has been tested in court multiple times with inconsistent outcomes, making it one of the most contested areas in cyber insurance. **Infrastructure outages caused by third parties.** If your cloud provider has an outage that disrupts your business, your cyber policy may not cover the resulting losses unless you have specific "system failure" or "dependent business interruption" coverage. **Intentional or criminal acts by the insured.** If the breach was caused by an employee acting maliciously with the knowledge of management, coverage is typically excluded. **Improvements and upgrades.** Cyber insurance pays to restore you to your pre-incident state. It won't fund security upgrades, new tools, or improvements to your infrastructure — even if those improvements are desperately needed after the breach. ## How Premiums Are Calculated Insurers evaluate your organization across several dimensions to set your premium. Understanding these factors gives you leverage to reduce costs. **Industry and size** form the baseline. Healthcare, financial services, and retail tend to pay higher premiums due to the volume and sensitivity of the data they handle. Revenue and employee count further refine the estimate. **Security posture** is increasingly the biggest variable. Carriers now routinely assess whether you have multi-factor authentication across all remote access and privileged accounts, endpoint detection and response deployed on all devices, a tested incident response plan, regular employee security awareness training, immutable or air-gapped backups, a vulnerability management program with defined patching SLAs, and email authentication controls (DMARC, DKIM, SPF). Organizations that can demonstrate strong controls in these areas typically see significantly lower premiums. Those that can't may struggle to get coverage at all. **Claims history** matters. Prior incidents, especially recent ones, will increase your premium or narrow your coverage terms. **Coverage limits and deductibles** are the final lever. Higher limits cost more. Higher deductibles cost less. Most small and mid-sized businesses carry between $1M and $5M in coverage, though the right amount depends on your risk exposure. ## How to Buy Cyber Insurance: A Step-by-Step Process **Start with a broker who specializes in cyber.** General insurance brokers can place a cyber policy, but a specialist broker understands the nuances of policy language, knows which carriers are paying claims reliably, and can negotiate terms that a generalist won't think to ask for. Ask for references from companies in your industry. **Get your security house in order before applying.** The application process has become a security assessment in its own right. Carriers will ask detailed questions about your security controls, and your answers become representations — essentially warranties. If you overstate your security posture and later file a claim, the carrier can deny it based on material misrepresentation. Be honest, even if it means your premium is higher. **Compare at least three quotes.** Policies vary dramatically in coverage terms, exclusions, sub-limits, and retroactive dates. Don't compare on price alone. Look at the scope of incident response services included, whether the policy covers regulatory investigations, how "computer system" and "security failure" are defined, whether social engineering and funds transfer fraud are covered, and what the waiting period is for business interruption claims. **Negotiate the panel.** Most cyber policies include a pre-approved panel of breach counsel, forensics firms, and crisis communications agencies. If you already have relationships with specific providers, ask the carrier to add them to the panel. Using off-panel vendors can reduce or eliminate reimbursement. **Review the policy annually.** Your risk profile changes as your business grows, adopts new technology, enters new markets, or faces new regulatory requirements. An annual review ensures your coverage keeps pace. ## How to File a Claim and Maximize Your Recovery When an incident happens, the first 48 hours determine whether your claim succeeds or fails. Here's how to navigate it. **Notify your carrier immediately.** Most policies require notification within a specific timeframe — often 72 hours of discovering the incident. Late notification is one of the most common reasons claims are denied or reduced. When in doubt, notify early and provide details later. **Engage your breach counsel first.** Before you call your IT team, your PR agency, or your forensics firm, call the breach counsel on your policy's panel. Communications routed through legal counsel may be protected by attorney-client privilege, which can be critical if litigation follows. Your breach counsel will quarterback the entire response and ensure everything is documented properly for the claim. **Document everything.** Every cost, every decision, every communication should be recorded. Carriers require detailed documentation to process claims, and gaps in your records create gaps in your reimbursement. Keep receipts, invoices, time logs, and a running timeline of the incident and response. **Don't authorize major expenditures without carrier approval.** If you need to hire a forensics firm, engage a crisis communications agency, or make a ransomware payment, get your carrier's written approval first. Unauthorized expenses may not be reimbursed, even if they were reasonable and necessary. **Track business interruption losses carefully.** If your operations are disrupted, document the financial impact daily. Compare actual revenue to projected revenue using historical data. Track the costs of any temporary workarounds, overtime, or manual processes. Business interruption claims are often the largest component of a cyber insurance payout, and they require the most rigorous documentation. ## Red Flags That Your Policy May Not Protect You Review your current policy for these warning signs: A retroactive date that doesn't cover your full history with the carrier. If your retroactive date resets each year, incidents that began before the current policy period may not be covered. Sub-limits that are too low to be meaningful. A policy with a $5M aggregate limit but a $100K sub-limit on ransomware payments or business interruption doesn't provide the protection the headline number suggests. Vague definitions of "security failure" or "computer system" that could allow the carrier to argue your specific incident doesn't qualify. No coverage for dependent or contingent business interruption. If a vendor, supplier, or cloud provider is compromised and your business is disrupted as a result, you need this coverage. Exclusions for "failure to maintain" security controls without clearly defining what those controls are. *** ## Key Takeaways Cyber insurance is a critical layer of your risk management strategy, but it's not a substitute for strong security. The best outcomes happen when your security program reduces the likelihood and impact of incidents, and your insurance policy covers the residual risk that remains. Buy thoughtfully, document relentlessly, and review annually. *** [*ContraForce helps organizations strengthen their security posture — which also happens to reduce your cyber insurance premiums. Learn more about our platform.*](https://www.contraforce.com) # How to Build a Cybersecurity Budget and Justify ROI to Your Board Source: https://docs.contraforce.com/blog/how-to-build-a-cybersecurity-budget When a breach costs the average organization millions in damages, lost revenue, and reputational harm, cybersecurity spending isn't optional — it's a business imperative. Yet for many security leaders, the hardest part isn't choosing the right tools. It's convincing the CFO and the board that the investment is worth it. This guide walks you through building a cybersecurity budget from scratch, calculating return on investment, and presenting a compelling business case to non-technical decision-makers. *** ## Why Cybersecurity Budgeting Is Different Unlike most business investments, cybersecurity ROI doesn't show up as revenue growth. It shows up as risk reduction — the breach that didn't happen, the downtime you avoided, the regulatory fine you never paid. That makes it harder to quantify, but not impossible. The key shift is framing cybersecurity as risk management rather than a cost center. Every dollar you spend should map to a specific risk you're reducing, and that risk should be expressed in language your board already understands: financial exposure, operational disruption, and regulatory liability. ## Step 1: Assess Your Current Risk Exposure Before you can build a budget, you need to understand what you're protecting and what happens if you fail. Start by cataloging your organization's critical assets: customer data, intellectual property, financial systems, operational technology, and employee records. For each asset category, estimate the financial impact of a compromise. Consider direct costs like incident response, legal fees, and regulatory fines. Factor in indirect costs like business interruption, customer churn, and reputational damage. Industry benchmarks can help here — IBM's annual Cost of a Data Breach Report provides median costs segmented by industry, company size, and breach type. Document your current security controls alongside each asset. Where you have gaps, you have risk. Where you have risk, you need budget. ## Step 2: Benchmark Against Your Industry Cybersecurity spending varies significantly by industry, company size, and regulatory environment. As a starting point, most industry analysts recommend allocating between 5% and 15% of total IT budget to cybersecurity, with regulated industries (healthcare, finance, defense contractors) trending toward the higher end. However, benchmarks are just that — benchmarks. A 200-person manufacturing company with operational technology exposure has a very different risk profile than a 200-person SaaS company. Use benchmarks to sanity-check your budget, not to set it. Key benchmarking sources include Gartner's annual IT spending forecasts, the SANS Institute's security spending surveys, and Deloitte's CISO survey data. Your cyber insurance carrier may also provide industry-specific guidance. ## Step 3: Build Your Budget by Category A well-structured cybersecurity budget typically breaks down into five categories: **Prevention and protection** covers endpoint protection, firewalls, email security, identity and access management, vulnerability management, and patch management. This is your first line of defense and usually accounts for the largest share of spending. **Detection and response** includes security monitoring (SIEM or MDR), threat intelligence feeds, incident response retainers, and forensics capabilities. If you're outsourcing to a managed detection and response provider, this line item may consolidate several sub-categories. **People and training** encompasses security team salaries, security awareness training for all employees, certifications, and any outsourced security operations (vCISO, managed SOC). For smaller organizations without a dedicated security team, this category might be entirely outsourced. **Compliance and governance** covers audit preparation, compliance tooling, policy development, penetration testing, and risk assessments. If your organization is subject to frameworks like HIPAA, PCI DSS, SOC 2, or CMMC, budget here tends to be non-negotiable. **Business continuity and recovery** includes backup and disaster recovery solutions, cyber insurance premiums, tabletop exercises, and incident response plan development. ## Step 4: Calculate ROI Using the Risk Reduction Model The most effective way to calculate cybersecurity ROI is the Annualized Loss Expectancy (ALE) model. It works like this: First, estimate the Single Loss Expectancy (SLE) — how much a single security incident would cost your organization. Use your risk assessment from Step 1 and industry breach cost data to arrive at a realistic number. Next, estimate the Annualized Rate of Occurrence (ARO) — how likely that incident is to happen in a given year. Threat intelligence data, your industry's breach frequency, and your current security posture all inform this number. Multiply SLE by ARO to get your Annualized Loss Expectancy. This is the expected cost of doing nothing. Now compare that number to the cost of the security investment that would reduce that risk. If a $150,000 MDR deployment reduces your expected annual loss from $800,000 to $200,000, you've generated $450,000 in risk-adjusted value — a 3x return. Present this calculation for each major risk area, and your board has a clear, financially grounded picture of why the budget matters. ## Step 5: Present It in Language Your Board Speaks Technical jargon kills budget requests. Your board doesn't need to understand the difference between EDR and XDR. They need to understand three things: what's the risk, what does the investment cost, and what happens if we don't invest. Structure your presentation around these elements: **The threat landscape** in two minutes or less. Use one or two statistics relevant to your industry. Keep it brief and alarming without being alarmist. **Your current exposure** expressed as financial risk. "We currently have \$4.2M in unmitigated cyber risk based on our assessment" is more compelling than a list of missing controls. **The proposed budget** tied to specific risk reductions. Each line item should answer the question "what risk does this eliminate or reduce?" **The cost of inaction** compared to the cost of investment. If your ALE exceeds your proposed budget, the math makes the case for you. **A phased approach** if the full budget is too large to approve at once. Prioritize the investments that address the highest-risk gaps first and propose a multi-year roadmap. ## Step 6: Track and Report on Effectiveness Once your budget is approved, your job isn't done. Boards expect to see that the money was well spent. Establish key performance indicators that demonstrate the value of your security program over time. Useful KPIs include mean time to detect and respond to threats, number of incidents prevented or contained, reduction in vulnerability exposure over time, employee phishing simulation click rates, and audit or compliance findings resolved. Report on these quarterly, and tie improvements directly back to the investments that enabled them. This builds credibility for future budget requests and keeps cybersecurity visible at the board level. *** ## Key Takeaways Cybersecurity budgeting isn't about buying tools — it's about managing business risk with financial discipline. Map every dollar to a risk, express that risk in financial terms, and present the investment as what it is: protection of revenue, reputation, and operational continuity. When you speak the board's language, the budget conversation gets much easier. *** [*ContraForce helps organizations build and operate security programs that deliver measurable results. Learn more about our platform.*](https://www.contraforce.com) # How to Build Your Cybersecurity Stack: A Vendor-Neutral Guide for Small and Mid-Sized Businesses Source: https://docs.contraforce.com/blog/how-to-build-your-cybersecurity-stack Every cybersecurity vendor will tell you their platform is the one you need. This guide takes a different approach. Instead of pitching products, it walks you through the categories of security tools your organization actually needs, how to evaluate vendors in each category, what questions to ask in demos, and how to build a stack that works together — all without telling you which brand to buy. *** ## Why "Best of Breed" vs. "Platform" Is the Wrong Starting Question The cybersecurity industry loves this debate: should you pick the best individual tool in each category, or consolidate onto a single platform? The honest answer is that it depends entirely on your team's size, skills, and capacity to manage multiple tools. A 5,000-person company with a 15-person security team can manage and integrate best-of-breed tools across categories. A 200-person company with one IT generalist who also handles security cannot — and shouldn't try. For most SMBs, fewer tools that work well together will outperform a collection of best-in-class products that nobody has time to configure, tune, or monitor. Start with your team's operational capacity, not with a product comparison spreadsheet. ## The Core Categories Every Organization Needs Regardless of your size or industry, your security stack needs to cover these fundamental areas. You don't need a separate tool for each one — many products span multiple categories — but you need coverage in all of them. ### 1. Endpoint Protection **What it does:** Protects laptops, desktops, servers, and mobile devices from malware, ransomware, and other threats. Modern endpoint protection goes beyond traditional antivirus to include behavioral detection, machine learning-based analysis, and automated response capabilities. **What to look for:** Detection capabilities that go beyond signature-based matching, automated response actions (isolate a compromised device, kill a malicious process), integration with your operating systems and device management tools, a cloud-based management console that doesn't require on-premises infrastructure, and clear reporting that shows you what's being blocked and why. **Questions to ask vendors:** What's your detection rate for novel (zero-day) threats, and how is that measured? How does the agent perform on older or lower-powered hardware? What happens when a device is offline — does protection continue? How are false positives handled, and what's the typical false positive rate your customers see? Can your tool integrate with our existing device management or IT ticketing system? **Common mistakes:** Deploying endpoint protection but never reviewing the alerts it generates. An endpoint tool that fires 200 alerts a day and nobody triages them is providing a false sense of security. If you don't have the staff to monitor alerts, pair your endpoint tool with a managed detection and response service. ### 2. Identity and Access Management **What it does:** Controls who can access what across your organization. This includes single sign-on (SSO), multi-factor authentication (MFA), directory services, privileged access management, and lifecycle management (onboarding and offboarding users). **What to look for:** Support for MFA across all applications, not just some. Phishing-resistant MFA methods (hardware keys, passkeys) in addition to push notifications and SMS. Integration with your existing directory (Active Directory, Azure AD / Entra ID, Google Workspace). Automated provisioning and deprovisioning tied to your HR system or onboarding process. Clear audit logs showing who accessed what and when. **Questions to ask vendors:** How do you handle MFA for legacy applications that don't natively support it? What's the user experience for employees — how many extra clicks or steps does authentication add? How quickly can we deprovision access when someone leaves the organization? Do you support conditional access policies (different requirements based on location, device, risk level)? What happens if the MFA service itself goes down — is there a secure fallback? **Common mistakes:** Deploying MFA for email and VPN but not for cloud applications, admin consoles, or remote desktop. Attackers will find and exploit the gaps. Also, failing to revoke access promptly when employees leave — orphaned accounts are one of the most common attack vectors in SMB breaches. ### 3. Email Security **What it does:** Protects your organization from phishing, business email compromise (BEC), malware delivered via email, and spam. Email remains the number one attack vector, making this category non-negotiable. **What to look for:** Inbound filtering that catches phishing, malware, and impersonation attempts. Protection against business email compromise, including detection of display name spoofing, look-alike domains, and vendor impersonation. URL rewriting and time-of-click analysis (checking links when the user clicks, not just when the email arrives). DMARC, DKIM, and SPF configuration and monitoring to prevent spoofing of your own domain. Outbound DLP (data loss prevention) to catch sensitive data leaving via email. **Questions to ask vendors:** How do you detect BEC attempts that don't contain malware or malicious links — pure social engineering? Can you show me examples of phishing emails your product caught that native Microsoft or Google security missed? How do you handle encrypted attachments? What's your approach to quarantine — who reviews quarantined messages and how quickly can legitimate emails be released? Do you provide any user-facing tools (report phishing button, real-time warnings on suspicious emails)? **Common mistakes:** Relying solely on the built-in security features of Microsoft 365 or Google Workspace. These provide a baseline, but dedicated email security solutions consistently catch threats that native controls miss — particularly sophisticated BEC and targeted phishing. ### 4. Backup and Recovery **What it does:** Ensures you can restore your data and systems after a ransomware attack, accidental deletion, hardware failure, or any other destructive event. **What to look for:** Automated, regular backups of all critical data and systems. At least one copy that is immutable (cannot be modified or deleted, even by an administrator) or air-gapped (physically or logically separated from your production network). Tested restoration capabilities — not just backup jobs that complete, but confirmed ability to restore data and bring systems back online. Granular recovery (restore a single file, mailbox, or database) in addition to full system recovery. Clear recovery time objectives (RTO) and recovery point objectives (RPO) that match your business requirements. **Questions to ask vendors:** How are backups protected from ransomware that specifically targets backup systems? Can you demonstrate a full system restore? How long does it take? What's the retention policy, and can we customize it? Are backups encrypted in transit and at rest? If your backup service goes down, can we still access our backup data? **Common mistakes:** Having backups but never testing restoration. The time to discover that your backups are corrupted, incomplete, or too slow to restore is not during a ransomware incident. Test quarterly at minimum. ### 5. Security Monitoring and Detection **What it does:** Watches your environment for suspicious activity, correlates events across multiple data sources, and alerts you (or responds automatically) when something looks wrong. **What to look for:** For most SMBs, this means either a SIEM (Security Information and Event Management) system or a managed detection and response (MDR) service — or both. The critical question is whether you have staff to monitor and respond to alerts 24/7. If you do, a SIEM with well-tuned detection rules may work. If you don't — and most SMBs don't — an MDR service provides the security operations center (SOC) capability you need without building one in-house. Look for coverage across your key data sources: endpoint, identity/authentication, email, cloud, and network. Correlation capabilities that connect related events into a coherent picture rather than firing isolated alerts. Low noise — the ratio of actionable alerts to false positives matters more than the total number of detections. And clear escalation and response procedures, whether that's your internal team acting on alerts or a managed service taking response actions on your behalf. **Questions to ask vendors:** What data sources do you ingest, and what's the cost model (per device, per GB, flat rate)? What's your median time to detect a real threat in your customer base? If you're an MDR provider, what response actions can you take on my behalf — and what requires my approval first? How do you handle after-hours alerts? Can you show me an example of a real incident you detected and resolved for a customer similar to us? **Common mistakes:** Buying a SIEM and expecting it to work out of the box. SIEMs require significant tuning, rule development, and ongoing maintenance to be effective. If you don't have a security analyst to manage it, the SIEM becomes an expensive log storage system. ### 6. Vulnerability Management **What it does:** Identifies known vulnerabilities in your systems, applications, and infrastructure so you can patch or mitigate them before attackers exploit them. **What to look for:** Automated scanning of internal and external assets on a regular cadence. Accurate asset discovery — you can't patch what you don't know about. Risk-based prioritization that accounts for exploitability, exposure, and business context, not just CVSS scores. Integration with your patch management or IT operations workflow. Reporting that helps you track remediation progress over time. **Questions to ask vendors:** How do you prioritize vulnerabilities — is it just CVSS score, or do you factor in real-world exploitability and asset criticality? How do you handle assets that can't be patched (legacy systems, OT devices)? What's the false positive rate on your scans? Can you integrate with our ticketing system to automatically create remediation tasks? How do you handle cloud assets and containers? **Common mistakes:** Running vulnerability scans but not acting on the results. A scan that identifies 500 vulnerabilities is useless if nobody triages, prioritizes, and remediates them. Pair your scanning tool with a clear remediation workflow and SLAs. ### 7. Security Awareness Training **What it does:** Educates your employees to recognize and report phishing attempts, social engineering, and other threats that target human behavior rather than technology. **What to look for:** Engaging, regularly updated content that reflects current threats — not annual compliance videos from five years ago. Simulated phishing campaigns that test employees with realistic scenarios and provide immediate feedback. Reporting that identifies high-risk individuals and departments. Short, frequent training modules (5 to 10 minutes monthly) rather than annual hour-long sessions. Content that's available in the languages your workforce needs. **Questions to ask vendors:** How often is your content library updated? Can you customize phishing simulations to mimic the specific threats our industry faces? What happens when an employee fails a simulation — is the follow-up training automatic? Do you provide metrics we can report to leadership (click rates over time, reporting rates, training completion)? Can the platform integrate with our email security tool so reported phishing goes to the right place? **Common mistakes:** Treating security awareness as a check-the-box compliance exercise. The goal isn't 100% training completion — it's measurable behavior change. Track phishing simulation click rates, reporting rates, and time-to-report over time. ## How to Evaluate Vendors: A Practical Framework When comparing products in any category, evaluate across five dimensions: **Effectiveness** is the most important and hardest to assess. Ask for third-party test results (AV-TEST, MITRE ATT\&CK evaluations, SE Labs), customer references in your industry, and proof-of-concept trials in your environment. Marketing claims are not evidence. **Operational fit** means the tool works with your team's skills, your existing infrastructure, and your operational cadence. A powerful tool that requires a dedicated full-time analyst to operate is the wrong tool for a team of two. **Integration** determines whether the tool plays well with the rest of your stack. Ask specifically about API availability, pre-built integrations with tools you already use, and data export capabilities. Siloed tools that don't share data create blind spots. **Total cost of ownership** goes beyond the license fee. Factor in implementation time, training, ongoing management effort, and any infrastructure requirements. A tool that costs $10,000 per year but requires $30,000 in staff time to operate costs \$40,000. **Vendor viability** matters because you're entering a relationship, not making a one-time purchase. Assess the vendor's financial stability, customer retention rates, product roadmap, and support quality. A startup with a great product that goes out of business in two years leaves you rebuilding. ## What Order to Build In If you're starting from scratch, build in this order. Each layer provides the foundation for the next. **First**, deploy MFA everywhere and get your identity and access management under control. Identity compromise is the leading attack vector, and no other security investment matters if attackers can log in with stolen credentials. **Second**, deploy endpoint protection across all devices. This gives you visibility into your most common attack surface and the ability to contain threats at the device level. **Third**, implement email security beyond your native provider's built-in protections. This addresses the most common delivery mechanism for phishing and malware. **Fourth**, establish backup and recovery with at least one immutable or air-gapped copy. This is your safety net for when everything else fails. **Fifth**, add security monitoring — either a managed service or, if you have the staff, a SIEM — to gain visibility across your environment and detect threats that bypass your preventive controls. **Sixth**, implement vulnerability management to systematically identify and remediate weaknesses before attackers find them. **Seventh**, launch security awareness training to address the human element that technology alone can't solve. This order isn't rigid — your specific risk profile may shift priorities. But for most SMBs, it represents the highest-impact sequence. *** ## Key Takeaways Building a cybersecurity stack isn't about buying the most expensive tools or checking the most boxes. It's about covering the fundamentals well, choosing tools that match your team's capacity, and ensuring everything works together. Start with identity, build outward, and never deploy a tool you don't have the capacity to operate. *** [*ContraForce provides a unified security operations platform that integrates across your existing stack. Learn more about our platform.*](https://www.contraforce.com) # ContraForce Blog Source: https://docs.contraforce.com/blog/index Insights on agentic AI, security service delivery, and the future of managed security — from the team building the platform. ## Product Announcements The latest features, modules, and platform capabilities shipping to ContraForce partners. Upload your SOPs and associate them with Security Delivery Agents A new operating model for managed security delivery AI agents that automate incident investigation and response at scale Enhanced investigation for Microsoft Sentinel and Defender for Endpoint Support for Splunk, CrowdStrike Falcon XDR, and IBM QRadar A better way to manage detection content across workspaces Improved incident response efficacy with automation Hyperautomate XDR without Microsoft Sentinel Platform hosted in more regions worldwide Streamline case management with Datto Autotask ## Outcomes & Value How service providers are transforming security delivery — real metrics, real operational impact. How to manage more customers without hiring more analysts 5 ways to help customers lower their cyber insurance premiums ## Agentic AI & Security Thought leadership on autonomous AI agents in cybersecurity and what it means for service providers. Understanding agentic AI in security operations Unique multi-tenant automation for Microsoft Sentinel and Defender How Security Delivery Platforms transform managed security Implementing new CISA guidance with ContraForce What market changes mean for MDR providers Essential capabilities to become a successful MSSP What the year ahead means for managed security ## Company & Ecosystem Awards, partnerships, certifications, and milestones from the ContraForce team. Recognized for Security Software Development Company Named Security Orchestration Solution of the Year Honored in the 2024 SC Awards program Selected for Microsoft for Startups Pegasus Fourth consecutive SOC 2 Type II completion New US distribution partnership with Ingram Micro Questions or feedback? Reach us at [support@contraforce.com](mailto:support@contraforce.com). # 5 Ways ContraForce Helps MSPs Reduce Their Customers' Cyber Insurance Costs Source: https://docs.contraforce.com/blog/outcomes-value/msp-cyber-insurance-costs How MSPs using ContraForce can help their customers qualify for better cyber insurance terms, lower premiums, and improved coverage through measurable security improvements. **Who is this for?** MSP/MSSP Partners **July 2, 2025** · ContraForce Team · 4 min read ## The Situation In recent years, companies purchasing cyber insurance have faced a rapidly evolving landscape marked by rising premiums, stricter underwriting requirements, and increased scrutiny of cybersecurity practices. Insurers are now demanding detailed evidence of risk mitigation efforts – such as the existence of threat detection and response capabilities – before issuing or renewing policies. Coverage limits have tightened, and exclusions for certain types of attacks, like ransomware, have become more common. As a result, businesses are increasingly focused on strengthening their security posture not only to reduce the likelihood of a breach but also to qualify for more favorable insurance terms and lower premiums. This shift has made cybersecurity a strategic priority as part of a company's risk management and financial planning. ## MSPs Can Play a Critical Role MSPs (Managed Service Providers) can play a critical role in helping companies navigate the evolving cyber insurance landscape. By delivering robust, managed security services, MSPs can help their clients meet insurers' stricter requirements—such as threat detection and response capabilities. MSPs can also provide documentation and reporting that demonstrate a strong security posture, which is often required during the underwriting process. Furthermore, they can help businesses rapidly respond to threats and reduce dwell time, a key factor insurers consider when assessing risk. Ultimately, by partnering with an MSP, companies can not only improve their chances of obtaining cyber insurance but also potentially reduce premiums and avoid policy exclusions through measurable, ongoing risk reduction. ## ContraForce Helps MSPs ContraForce can help Managed Service Providers (MSPs) reduce their customers' cyber insurance costs by improving their cybersecurity posture and demonstrating measurable security controls. Here's how: ## 1. Centralized Security Posture Management ContraForce aggregates and normalizes security data from various endpoint and SIEM tools, with SIEM tools themselves collecting data from many security data sources, giving MSPs a unified view of a customer's security landscape. This makes it easier to: * Identify and remediate security incidents faster * Show continuous compliance with security frameworks like NIST, CIS, and ISO 27001 * Provide evidence of risk mitigation strategies during insurance underwriting or renewal processes ## 2. Real-Time Threat Detection and Response ContraForce enables rapid detection and response across Microsoft Defender, Microsoft Sentinel, and other integrated tools. Insurance providers favor businesses that: * Can detect and contain breaches quickly * Use automated response workflows to limit damage * Maintain audit logs and incident documentation These capabilities lower the perceived risk, which insurers consider when calculating premiums. ## 3. Demonstrable Risk Reduction ContraForce quantifies improvements in risk posture over time, for example fewer active threats. MSPs can report on these results for their customers so they can: * Proactively communicate security maturity to insurance underwriters * Justify reduced premiums or qualify for better coverage terms ## 4. Compliance Mapping and Reporting Cyber insurance providers often require evidence of controls like endpoint detection and response (EDR) tools. ContraForce helps MSPs: * Continuously monitor for gaps in required controls * Generate compliance-ready reports for policy applications or audits ## 5. Cost-Effective, Scalable SOC Services By delivering SOC-as-a-Service capabilities through ContraForce, MSPs can offer enterprise-grade security to small and mid-sized businesses (SMBs) without them having to build their own SOC. This enhances their customers' security profile at a fraction of the cost. Having SOC capabilities can positively influence insurance rates for SMBs. ## Lower Insurance Costs As a result of outsourcing security services to an MSP powered by ContraForce, customers can lower their cyber insurance costs by demonstrating: **Enhanced visibility and response** — Real-time visibility into threats and faster incident response significantly reduce the likelihood and severity of breaches. Insurers recognize this as a strong indicator of lower risk, which can lead to better premiums and policy terms. This is especially true when it comes to ransomware. Breaches are a precursor to ransomware. By reducing the likelihood of breaches, organizations can mitigate their ransomware exposure and materially influence their premiums. **Compliance and reporting** — Compliance tracking ensures critical security controls are continuously monitored and documented. This makes it easier to prove compliance with insurer requirements, reducing the underwriting burden and potentially qualifying the business for discounts. **Quantifiable and demonstrated cyber risk reduction** — By showing measurable improvements – like increased control coverage, and a reduction in active threats – companies can demonstrate lower risk to insurers. This data-driven approach helps justify lower premiums and improved coverage. **Meeting insurer-required controls more effectively** — Insurers often mandate specific security measures (e.g., endpoint protection). Ensuring these controls are properly implemented and maintained, reducing the chance of coverage denials or surcharges. For customers working with MSPs who use ContraForce, these measures should lead to lower risk, fewer incidents, reduced claims and lower cyber insurance costs. ## Quick Summary * Cyber insurance underwriting now requires evidence of threat detection and response capabilities. * MSPs can help customers meet these requirements through ContraForce-powered security services. * Five key capabilities: centralized posture management, real-time detection, demonstrable risk reduction, compliance reporting, and scalable SOC services. * ContraForce provides documentation and metrics that support insurance applications and renewals. * The result: lower premiums, better coverage terms, and reduced policy exclusions for customers. Get started with ContraForce Learn about incident workflows Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Scaling Security Delivery Without Scaling Headcount Source: https://docs.contraforce.com/blog/outcomes-value/scale-security-delivery How MSPs and MSSPs use ContraForce to manage more customers, close incidents faster, and deliver consistent security outcomes — without hiring more analysts. **Who is this for?** MSP/MSSP Partners and Security Team Leadership **February 2026** · ContraForce Team · 5 min read The economics of managed security have always been challenging: more customers means more incidents, and more incidents means more analysts. ContraForce breaks this pattern by automating the work that used to require human attention at every step. ## The Scaling Problem Traditional security operations scale linearly. Add 10 new customers, and you need proportionally more analyst capacity to handle their incidents. This creates a ceiling on growth — you can only expand as fast as you can hire and train. The bottleneck isn't technology. It's the manual work between detection and resolution: triaging alerts, gathering context, investigating entities, executing response actions, and documenting outcomes. ## How ContraForce Changes the Math ContraForce automates each stage of the incident lifecycle: | Stage | Traditional Approach | ContraForce Approach | | --------------------- | --------------------------------------- | -------------------------------------------------------------------------- | | **Triage** | Analyst reviews each alert manually | Security Delivery Agents analyze automatically | | **Context Gathering** | Analyst queries multiple tools | Entity Insights aggregate sign-in logs, device timelines, and threat intel | | **Investigation** | Analyst correlates data across systems | Agents correlate related incidents and entity activity | | **Response** | Analyst executes actions in each tenant | Gamebooks execute consistent response actions across workspaces | | **Documentation** | Analyst writes incident notes | Agents document findings and actions automatically | ## Multi-Tenant Operations at Scale Managing security across dozens or hundreds of customer workspaces introduces complexity that compounds the scaling problem. ContraForce addresses this directly: * **Command Dashboard** provides a unified view of incidents across all workspaces — no switching between customer portals * **Workspace filters** persist across pages, letting you focus on specific customers without reconfiguring views * **Gamebooks** execute the same response actions consistently across every workspace * **Security Delivery Agents** operate across your entire customer base from a single deployment ## Operational Efficiency in Practice Service providers using ContraForce report measurable operational improvements: * **Incident triage time** drops from minutes to seconds with automated agent analysis * **Response consistency** improves because Gamebooks enforce standardized workflows * **Analyst capacity** increases as routine investigation work shifts to agents * **Customer coverage** expands without proportional team growth ## The Role of Automation Automation doesn't replace your analysts — it amplifies them. SDAs handle the repetitive investigation work while your team focuses on complex incidents, customer relationships, and strategic improvements. The goal isn't fewer people. It's more customers served at higher quality without burning out your team. ## Quick Summary * Traditional security operations scale linearly with headcount * ContraForce automates triage, context gathering, investigation, response, and documentation * Multi-tenant features eliminate the overhead of managing separate customer environments * Security Delivery Agents handle routine work so analysts focus on high-value activities * Service providers scale customer coverage without proportional team growth Unified incident visibility across all customer workspaces Automated response workflows for consistent security operations Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Improves Case Management with Datto Autotask PSA Integration Source: https://docs.contraforce.com/blog/product-announcements/autotask-psa-integration ContraForce announces integration with Datto Autotask PSA to streamline case management for MSPs. **Who is this for?** MSP/MSSP Partners **April 29, 2024** · ContraForce Team · 2 min read ContraForce is pleased to announce our integration with Datto Autotask PSA, enabling MSPs to streamline their security case management workflows. ## Unified Case Management Many MSPs use Autotask PSA as their central ticketing system. This integration allows you to: * **Create tickets automatically** — Security incidents in ContraForce create corresponding tickets in Autotask * **Sync status updates** — Changes in ContraForce reflect in Autotask and vice versa * **Maintain single source of truth** — All work tracked in your existing PSA ## How It Works 1. Configure the Autotask integration in ContraForce workspace settings 2. Map incident severities to Autotask priority levels 3. Define which incident types should create tickets 4. Enable automatic ticket creation When a security incident is processed in ContraForce, a corresponding ticket is created in Autotask with: * Incident summary and details * Affected customer information * Link back to ContraForce for investigation * Severity-appropriate priority level ## Benefits for MSPs | Benefit | Description | | ------------------------ | ----------------------------------------- | | **Reduced duplication** | No need to manually create tickets | | **Improved tracking** | All security work visible in PSA | | **Consistent workflows** | Same process for all incident types | | **Better reporting** | Security metrics in your existing reports | ## Getting Started The Autotask integration is available now for all ContraForce partners: 1. Navigate to workspace integrations 2. Select Datto Autotask PSA 3. Complete the authorization flow 4. Configure ticket creation rules ## Quick Summary * ContraForce now integrates with Datto Autotask PSA for streamlined case management. * Security incidents automatically create corresponding tickets in Autotask. * Status updates sync bidirectionally between ContraForce and Autotask. * MSPs get unified tracking, consistent workflows, and security metrics in their existing PSA reports. Configure notification settings Learn about incident workflows Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # A Better Way to Manage Detection Content Source: https://docs.contraforce.com/blog/product-announcements/detection-content-management ContraForce introduces an improved way to manage detection content across Microsoft Sentinel workspaces with the Content Management System. **Who is this for?** MSP/MSSP Partners, Security Engineers **October 16, 2024** · ContraForce Team · 3 min read ContraForce is excited to announce significant improvements to how service providers manage detection content across their customer Microsoft Sentinel workspaces. ## The Challenge of Detection Content at Scale Managing detection rules across dozens or hundreds of customer Sentinel workspaces presents significant challenges: * **Inconsistent coverage** — Different rules enabled in different workspaces * **Manual deployment** — Time-consuming process to deploy or update rules * **No centralized visibility** — Difficult to see what's deployed where * **Change management overhead** — Tracking which customers have which versions ## Introducing ContraForce CMS The ContraForce Content Management System (CMS) provides a toggle-based interface for deploying and managing detection rules across all your customer Sentinel workspaces: ## Centralized Rule Management * View all available detection rules in a single dashboard * See deployment status across all customer workspaces * Toggle rules on or off for individual or multiple customers ## Curated Detection Library * Access ContraForce's curated library of detection rules * Rules optimized for common threat scenarios * Regular updates as new threats emerge ## Bulk Operations * Deploy rules to multiple workspaces simultaneously * Update rule configurations across your entire customer base * Roll back changes if needed ## How It Works 1. Navigate to the CMS module in your ContraForce workspace 2. Browse available detection rules 3. Select target customer workspaces 4. Toggle rules on to deploy Rules are deployed directly to customer Sentinel workspaces, ensuring they run natively within Microsoft's infrastructure. ## Quick Summary * Centralize management of detection rules across all customer Microsoft Sentinel workspaces. * Use a toggle-based CMS interface to deploy, update, and roll back rules at scale. * Leverage a curated, regularly updated library of ContraForce detection content. * Perform bulk operations to keep coverage consistent and reduce manual change management. Deploy the Content Management System Connect Microsoft Sentinel Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Improve Incident Response Efficacy with ContraForce Gamebook Automation and Mapping Source: https://docs.contraforce.com/blog/product-announcements/gamebook-automation-mapping ContraForce introduces enhanced Gamebook automation and mapping capabilities to improve incident response efficacy across customer workspaces. **Who is this for?** MSP/MSSP Partners, SOC Analysts **October 15, 2024** · ContraForce Team · 3 min read ContraForce is pleased to announce enhanced Gamebook automation and mapping capabilities, designed to improve incident response efficacy across your customer workspaces. ## What Are Gamebooks? Gamebooks are ContraForce's SOP-driven incident response workflows. They guide analysts through investigation and response steps, ensuring consistent outcomes regardless of who is handling the incident. ## Automated Gamebook Mapping ContraForce now automatically maps incidents to the appropriate Gamebook based on incident type, severity, and other characteristics. This means: * **Faster time to action** — No manual Gamebook selection required * **Consistent response** — Same incident types handled the same way * **Reduced training burden** — Analysts don't need to memorize which Gamebook to use ## Enhanced Automation Modes Gamebooks now support three automation levels: | Mode | Behavior | | -------------- | ---------------------------------------------------- | | **Manual** | Analyst reviews and approves each step | | **Automatic** | Steps execute automatically with analyst supervision | | **Autonomous** | Full automation with minimal analyst involvement | ## Improved Action Visibility * See exactly which actions will be taken before execution * Clear indicators for reversible vs. irreversible actions * Detailed logs of all actions taken ## Getting Started Gamebook automation is available now in all ContraForce workspaces: 1. Navigate to workspace settings 2. Configure Gamebook automation preferences 3. Set default automation levels per incident type 4. Monitor automated actions in the activity log ## Quick Summary * Gamebooks are SOP-driven workflows that ensure consistent incident response across all analysts. * Automated Gamebook mapping assigns the right workflow to each incident based on type and severity. * Three automation modes (Manual, Automatic, Autonomous) let you control the level of human oversight. * Improved visibility shows exactly which actions will be taken before execution. Learn about Gamebook fundamentals Set up Security Delivery Agents Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Platform to Be Hosted in More Regions Around the World Source: https://docs.contraforce.com/blog/product-announcements/global-hosting-regions ContraForce announces expanded global hosting capabilities to support partners and customers worldwide. **Who is this for?** All ContraForce partners and customers **November 25, 2024** · ContraForce Team · 2 min read ContraForce is pleased to announce the expansion of our platform hosting to additional regions around the world, enabling partners to serve customers with data residency requirements more effectively. ## Global Platform Availability As ContraForce grows internationally, we're investing in infrastructure to support partners worldwide: * **Regional data processing** — Data stays within specified geographic boundaries * **Lower latency** — Faster response times for regional users * **Compliance support** — Meet local data residency requirements ## New Regions In addition to our existing US hosting, ContraForce is expanding to: * **Europe** — EU-based infrastructure for European customers * **United Kingdom** — Dedicated UK hosting * **Asia-Pacific** — Regional presence for APAC partners ## What This Means for Partners Partners can now: * **Select hosting region** when onboarding new workspaces * **Meet customer requirements** for data locality * **Expand internationally** with confidence ## Data Residency For customers with specific data residency requirements: | Region | Data Processing | Storage | | ------------------ | --------------- | ------- | | **United States** | US | US | | **Europe** | EU | EU | | **United Kingdom** | UK | UK | | **Asia-Pacific** | APAC | APAC | ## Getting Started Partners interested in regional hosting options should contact their ContraForce account team to discuss requirements and availability. ## Quick Summary * ContraForce is expanding platform hosting beyond the US to multiple global regions. * New regions include Europe, the United Kingdom, and Asia-Pacific to support local customers. * Regional hosting improves data residency alignment, latency, and compliance support. * Partners can choose hosting regions per workspace to meet customer and regulatory requirements. * Contact your ContraForce account team to enable or discuss regional hosting options. Get started with ContraForce Set up new workspaces Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Makes Incident Investigation Even Easier for Microsoft Sentinel and Defender for Endpoint Source: https://docs.contraforce.com/blog/product-announcements/incident-investigation-improvements ContraForce introduces improvements to incident investigation for Microsoft Sentinel and Microsoft Defender for Endpoint incidents. **Who is this for?** MSP/MSSP Partners, SOC Analysts **June 17, 2025** · ContraForce Team · 3 min read ContraForce is pleased to announce significant improvements to incident investigation capabilities for Microsoft Sentinel and Microsoft Defender for Endpoint incidents. ## Faster, More Intuitive Investigation The latest updates to the ContraForce Workbench make it easier than ever to investigate security incidents: ## Unified Incident View * All related alerts consolidated into a single incident view * Timeline of events across all data sources * Entity relationships visualized in the Entity Context Graph ## Enhanced Entity Enrichment When you investigate an entity, ContraForce now automatically enriches it with: * **User entities** — Sign-in logs, audit history, group memberships, risk signals * **Device entities** — Device details, installed software, recent activity * **IP addresses** — Geolocation, threat intelligence, historical activity * **Files** — Hash lookups, prevalence data, detection history ## Streamlined Actions Take response actions directly from the investigation view: * Isolate devices without leaving the incident * Disable user accounts with a single click * Block IPs or URLs across customer tenants * Quarantine files and soft-delete malicious emails ## Improved Context The Workbench now provides more context to help analysts make faster, more informed decisions: | Enhancement | Benefit | | ----------------------- | ------------------------------------------------- | | **Related incidents** | See other incidents involving the same entities | | **Historical patterns** | Understand if this behavior is normal | | **Threat intelligence** | Automatic correlation with known threats | | **Customer context** | Relevant information about the affected workspace | ## Quick Summary * Unified incident view consolidates all related alerts and shows entity relationships in the Entity Context Graph. * Enhanced entity enrichment automatically adds sign-in logs, device details, threat intelligence, and more. * Streamlined response actions let you isolate devices, disable accounts, and block threats without leaving the incident. * Improved context includes related incidents, historical patterns, and threat intelligence correlation. Learn about the investigation interface Explore entity enrichment Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Introducing Security Delivery Agents: AI-Powered Incident Response at Scale Source: https://docs.contraforce.com/blog/product-announcements/security-delivery-agents Security Delivery Agents automate incident investigation and response across multi-tenant environments, enabling MSPs and MSSPs to scale security operations without scaling headcount. **Who is this for?** MSP/MSSP Partners and Security Team Leadership **February 2026** · ContraForce Team · 4 min read Security Delivery Agents (SDAs) are now generally available in ContraForce. These AI agents automatically investigate incidents, enrich context with sign-in logs and device timelines, and execute response actions through Gamebooks — giving your team the capacity to handle more incidents without adding headcount. ## What Security Delivery Agents Do SDAs handle the repetitive, time-consuming work of incident investigation. When an incident arrives, the agent: * **Analyzes the incident context** using sign-in logs, audit trails, device timelines, and related incidents * **Enriches entity information** by pulling threat intelligence and historical activity patterns * **Recommends or executes response actions** based on your configured confidence thresholds * **Documents findings** with detailed comments for analyst review This isn't a chatbot or copilot. SDAs are autonomous agents that take action on your behalf, following the same workflows your analysts would — just faster and at scale. ## A Phased Approach to Automation ContraForce designed SDAs with a progressive adoption model. You control how much automation to enable: | Phase | Mode | What Happens | | ----------- | ------------------- | ---------------------------------------------------------------- | | **Phase 1** | Manual | You select incidents and trigger agent investigation on demand | | **Phase 2** | Automatic by Status | Agents run automatically on new, active, or closed incidents | | **Phase 3** | Automatic Gamebooks | Agents execute response playbooks based on confidence thresholds | Start with manual execution to see how agents analyze your incident types. Once you trust the outputs, enable automatic execution. When you're confident in agent accuracy, allow Gamebook execution for full autonomous response. ## Human-in-the-Loop Controls Even with full automation enabled, you maintain control: * **Confidence thresholds** determine when agents can take action versus when they require approval * **Status filters** control which incidents trigger automatic processing * **Gamebook authorization** must be explicitly granted before agents can execute response actions * **Audit trails** capture every agent action for compliance and review ## Why This Matters for Service Providers For MSPs and MSSPs managing multiple customer workspaces, SDAs change the math on security operations: * **Scale without headcount** — Handle 10x the incident volume with the same team * **Consistent quality** — Every incident gets the same thorough investigation * **Faster response** — Automated triage means faster time-to-resolution * **Multi-tenant ready** — Agents work across all your customer workspaces from day one ## Quick Summary * Security Delivery Agents automate incident investigation and response * Three-phase adoption: manual → automatic by status → automatic Gamebooks * Agents use sign-in logs, device timelines, and threat intelligence for context * Confidence thresholds and human-in-the-loop controls keep you in charge * Deploy once, scale across all customer workspaces Step-by-step guide to configuring Security Delivery Agents Deploy the Azure AI infrastructure that powers SDAs Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # The ContraForce Security Delivery Platform Source: https://docs.contraforce.com/blog/product-announcements/security-delivery-platform-launch Introducing the ContraForce Security Delivery Platform — a new operating model for managed security delivery built on Microsoft Azure and AI. **Who is this for?** MSP/MSSP Partners, IT Service Providers, Security Service Providers **November 17, 2025** · Stan Golubchik · 3 min read ## Introducing the ContraForce Security Delivery Platform **A new operating model for managed security has arrived.** For years, we've been building toward one vision: Enable every Microsoft-focused service provider to deliver enterprise-grade MXDR to every customer without needing a massive SOC or enterprise-scale team. Today, that vision becomes real. We're officially launching the ContraForce Security Delivery Platform. This brings Microsoft's next-generation security and AI capabilities directly inside ContraForce, and gives service providers the ability to deliver fully automated, scalable MXDR services across their entire customer base. This is not an add-on. This is not an iteration. This is a new operating model for managed security delivery. ## Why the industry needs a new model Service providers are being asked to deliver more with less: * More customers * More incidents * More compliance * More 24/7 coverage * More visibility * More expectations All while battling staffing shortages, shrinking margins, and the complexity of managing dozens or hundreds of distinct customer environments. Traditional SOC models built for single-tenant enterprise teams simply do not scale for the multi-tenant realities of MSPs and MSSPs. So we built something that does. ## The ContraForce Security Delivery Platform What this means for Service Providers (and your customers): ## Microsoft-native, deeply integrated security foundation Built directly on Microsoft Azure and Azure AI Foundry. Deep integrations with Microsoft Sentinel, Defender for Endpoint, and Entra ID. No extra overhead, no extra infrastructure, no patchwork tools. This is Microsoft-powered security, operationalized for Service Providers. ## Autonomous Security Delivery Agents Our Security Delivery Agents powered by Azure AI and Microsoft's emerging agent frameworks autonomously handle: * Triage * Investigation * Disposition * Response * Documentation For every customer tenant, with supervised or autonomous execution. Think of them as always-on security analysts with precision consistency and no fatigue. ## 60× faster investigations and response What used to take 30 minutes of investigation, disposition, and response now takes 30 seconds. Faster outcomes. Fewer escalations. Fewer breaches. This is what "AI-delivered security" actually looks like. ## 10× more customer capacity per analyst Onboard more customers without hiring more analysts. Scale service delivery without scaling overhead. This is how you grow margins while growing your customer base. ## 93% lower cost-per-incident Shift unit of labor work from human to AI compute economics. Labor-driven costs drop dramatically with AI agent incident processing. Human incident management costs go from $15 per incident to under $1 per incident in AI compute cost. We've seen cost-per-incident fall under \$0.25 per incident. This is how MXDR becomes truly profitable at scale. ## Global MXDR delivery from a single control plane Deploy Security Delivery Agents across any tenant, anywhere. Unify operations across Sentinel, Defender for Endpoint, and more with no portal pivoting. Your analysts stay in one place. Your customers get faster outcomes. Your economics flip in your favor. ## Why this matters This launch isn't just great news for the businesses our service providers protect. It transforms the economics and scalability of managed security itself. With the ContraForce Security Delivery Platform, Service Providers can: * Scale accounts without scaling teams * Launch high-value MXDR offerings in days, not months * Deliver consistent outcomes across all tenants * Strengthen recurring revenue and margins * Operate with predictable, automated workflows * Become strategic security advisors — not reactive responders This is the first time AI-driven, multi-tenant MXDR has been built for Service Providers, not retrofitted to them. ## A milestone years in the making This platform reflects the combined effort of two teams: * **ContraForce** — designing and scaling a platform purpose-built for multi-tenant security operations. * **Microsoft** — powering the foundational security architecture and AI frameworks that make agentic security delivery possible. Thank you to every engineer, partner manager, architect, and early design partner who helped bring this to life. Together, we are enabling Service Providers to deliver security in a way that simply wasn't possible a few years ago. ## This is only the beginning The launch of the ContraForce Security Delivery Platform marks the start of a new era where: * AI agents deliver consistent, autonomous operations * Multi-tenant orchestration becomes standard * Unit economics improve dramatically * Service Providers can finally scale security delivery without scaling complexity More capabilities. Deeper integrations. Expanding service provider support. All coming next. If you're a Microsoft-aligned Service Provider looking to scale MXDR, accelerate response, and transform margins — this is your moment. Let's build the future of security delivery together. **Stan Golubchik** CEO & Co-Founder, ContraForce ## Quick Summary * The ContraForce Security Delivery Platform is a new operating model for managed security built on Microsoft Azure and AI. * Security Delivery Agents autonomously handle triage, investigation, response, and documentation. * Achieve 60× faster investigations, 10× more customer capacity per analyst, and 93% lower cost-per-incident. * Designed for Microsoft-focused MSPs and MSSPs to scale MXDR services without scaling headcount. * Deep integrations with Microsoft Sentinel, Defender for Endpoint, and Entra ID with no extra infrastructure required. Get started with the ContraForce platform Configure autonomous security agents Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Adds Support for Splunk, CrowdStrike Falcon XDR, and IBM QRadar SIEM Source: https://docs.contraforce.com/blog/product-announcements/siem-xdr-platform-support ContraForce expands platform support to include Splunk Enterprise Security, CrowdStrike Falcon XDR, and IBM QRadar SIEM. **Who is this for?** MSP/MSSP Partners, Security Engineers **July 23, 2024** · ContraForce Team · 3 min read ContraForce is excited to announce expanded platform support, now including Splunk Enterprise Security, CrowdStrike Falcon XDR, and IBM QRadar SIEM alongside our existing Microsoft Sentinel and Defender for Endpoint integrations. ## Multi-Platform Security Operations Service providers often manage customers with diverse security technology stacks. This expansion allows you to: * **Consolidate operations** — Manage incidents from multiple platforms in one place * **Apply consistent workflows** — Use Gamebooks across all supported platforms * **Scale efficiently** — Same operational model regardless of underlying technology ## New Platform Integrations ## Splunk Enterprise Security * Ingest notable events from Splunk ES * Correlate Splunk data with other security sources * Execute response actions through Splunk's SOAR capabilities ## CrowdStrike Falcon XDR * Receive detections from Falcon platform * Leverage Falcon's endpoint response actions * Integrate with existing Falcon deployments ## IBM QRadar SIEM * Pull offenses from QRadar * Enrich with QRadar's event context * Coordinate response across hybrid environments ## Why This Matters Many MSPs and MSSPs support customers with non-Microsoft security stacks. With this expansion: * **No more portal pivoting** — Work from a single interface * **Consistent service delivery** — Same quality of service regardless of platform * **Flexible customer support** — Onboard customers without forcing technology changes ## Microsoft Remains Core While we're expanding platform support, Microsoft Sentinel and Defender for Endpoint remain our core focus: * Deepest integration with Microsoft security stack * Full Security Delivery Agent support * CMS for detection content management ## Quick Summary * ContraForce now supports Splunk Enterprise Security, CrowdStrike Falcon XDR, and IBM QRadar SIEM. * Consolidate incidents from multiple security platforms into a single operational interface. * Apply consistent Gamebook workflows regardless of underlying technology. * Microsoft Sentinel and Defender for Endpoint remain the core focus with the deepest integration. Connect Microsoft Sentinel Deploy Defender for Endpoint integration Questions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Your SOPs Now Power Your Security Delivery Agents Source: https://docs.contraforce.com/blog/product-announcements/sop-knowledge-base ContraForce launches the SOP Knowledge Base — upload your Standard Operating Procedures and associate them with Security Delivery Agents for policy-driven incident response. **Who is this for?** MSP/MSSP Partners, SOC Leaders, and Security Team Leadership **March 2026** · ContraForce Team · 4 min read Every security team builds institutional knowledge over years of operational experience. Classification criteria. Response procedures. Escalation paths. Remediation steps. That knowledge lives in documents scattered across SharePoint, Confluence, Google Drive, and shared folders. Until today, none of it was accessible to your Security Delivery Agents. That changes now. ## Introducing the SOP Knowledge Base The SOP Knowledge Base is a new capability inside ContraForce that lets you upload your Standard Operating Procedures and associate them directly with Security Delivery Agents. Two SOP types. Two purposes. **Classification SOPs** define how incidents get categorized and prioritized. You can associate multiple Classification SOPs with a Security Delivery Agent, but only one is activated per investigation — ensuring consistent severity decisions while giving you flexibility across different scenarios. **Response SOPs** define how incidents get investigated and remediated. Each Security Delivery Agent supports multiple Response SOPs, so the right procedures are available regardless of incident type. Upload your documents. Tag them. Map them to MITRE ATT\&CK techniques. Associate them with the agents that need them. Done. ## Why This Matters Security Delivery Agents are powerful. They triage, investigate, enrich, and recommend actions at machine speed. But speed without context is not delivery. It is automation. Delivery means the agent follows your procedures. It classifies incidents the way your team classifies them. It responds the way your team responds. It applies the institutional knowledge your analysts have built over years. The SOP Knowledge Base bridges that gap. Your agents stop operating with generic patterns and start operating with your patterns. For MSPs and MSSPs managing multiple tenants, this is the difference between a tool that runs fast and a platform that delivers consistently. Every workspace gets its own SOP library. Every agent gets the procedures that match the client's requirements. Every incident gets handled according to the SOPs you defined. ## How It Works The SOP Knowledge Base lives inside the ContraForce Agent Center as a dedicated section in the left navigation. **Upload.** Drag and drop your SOP documents. Launch formats include Markdown and plain text, with PDF, Word, HTML, and RTF coming soon. ContraForce extracts and indexes the content automatically. **Categorize.** Assign each SOP as either Classification or Response. Add tags for organization. Map to MITRE ATT\&CK techniques so the right SOP surfaces for the right threat. **Associate.** Link SOPs to Security Delivery Agents from either direction. Navigate from the SOP detail view to add agents, or from the agent detail page to add SOPs. Changes take effect immediately. **View.** Read SOP content directly inside ContraForce without switching to external systems. See which agents use each SOP. See which SOPs each agent has. Full visibility into the connection between your procedures and your delivery. All SOP data is workspace-scoped. Tenant isolation is enforced at the infrastructure level. No cross-tenant data exposure. No shared indexes. ## What This Unlocks This release is the foundation for SOP-aware agent execution. Security Delivery Agents now have access to your procedures at runtime, enabling context-aware incident handling that follows your organization's specific guidelines. For teams already running ContraForce: * Your agents get smarter without retraining. Upload the SOPs. Associate them. The agents reference them during incident handling. * New analyst onboarding accelerates. The SOPs that define how your team operates are now embedded in the platform, not buried in a folder. * Governance gets concrete. Auditors and clients can see exactly which procedures govern each agent's decisions. For MSPs evaluating ContraForce: * This is how you standardize delivery across every client without building custom runbooks per tenant. * This is how you prove to clients that their security operations follow documented, auditable procedures. * This is how you scale a security practice without scaling tribal knowledge. ## Built for the Way You Already Work You do not need to rewrite your SOPs. You do not need to learn a proprietary format. Upload the documents your team already maintains. ContraForce handles the parsing, indexing, and association. At launch, ContraForce supports Markdown and plain text files — the formats security teams already use for version-controlled docs and lightweight playbooks. Support for Word, PDF, HTML, and RTF is coming soon. ## Available Now The SOP Knowledge Base is available to all ContraForce customers as part of the Phase 2: Trust and Control release. No additional cost. No configuration required. Log in to Agent Center and start uploading. Security Delivery Agents work on their first alert from any connected tool. Now they work on that first alert with your SOPs guiding every decision. **AI that acts. Humans who decide. Now with your procedures built in.** *** Ready to see it in your tenant? [Book a demo](https://cal.com/contraforce/30-minutes-with-stan) or reach out to your ContraForce account representative. Full setup guide, file formats, association workflows, and best practices. Learn how Security Delivery Agents automate incident response at scale. # Incident Classification Source: https://docs.contraforce.com/concepts/incident-classification How ContraForce classifies closed incidents with a single canonical taxonomy across every detection module ContraForce records a closing classification on every classified incident using one canonical taxonomy, regardless of which detection module the incident came from. Analysts pick from the same four verdicts and the same reason list everywhere; ContraForce translates to each vendor's native vocabulary behind the scenes. ## Canonical classifications | Order | Classification | Meaning | Color | | ----- | --------------- | ---------------------------------------------------------------- | ------ | | 1 | True Positive | Confirmed malicious activity | Red | | 2 | False Positive | The detection was wrong; no suspicious activity occurred | Orange | | 3 | Benign Positive | Real activity that was confirmed benign, expected, or authorized | Green | | 4 | Undetermined | No firm verdict was reached | Blue | This order and color scheme appear consistently across the close dialogs, the Incidents inbox classification column and filters, and the Command Center Classification Trends widget. ## Classification reasons Each reason applies to specific classifications. The reason list shown when closing an incident is scoped to the classification you pick; it is the same list for every detection module. | Classification | Valid reasons | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | True Positive | Multistage Attack, Malware, Malicious User Activity, Unwanted Software, Phishing, Compromised User, APT, Suspicious Activity, Other | | False Positive | Not Malicious, Not Enough Data To Validate, Inaccurate Data, Incorrect Alert Logic, Other | | Benign Positive | Security Testing, Confirmed User Activity, Line Of Business Application, Security Personnel, Suspicious But Expected, Other | | Undetermined | Unknown, Other | A reason is required whenever a classification is set. Your exact choice is always preserved in ContraForce, even when the vendor's own vocabulary cannot store it (see the per-module tables below). ## Per-module translation ContraForce writes your verdict back to the vendor when the vendor supports it, translating to the nearest native value. The tables below show the write-back mapping per module. ### Microsoft Sentinel Sentinel's classifications match the canonical four one to one. Its reason vocabulary is fixed per classification, so canonical reasons outside that set degrade to Sentinel's default for the classification. | Canonical | Sentinel classification | Sentinel reason | | -------------------------------------- | ----------------------- | --------------------- | | True Positive (any reason) | TruePositive | SuspiciousActivity | | False Positive + Inaccurate Data | FalsePositive | InaccurateData | | False Positive + Incorrect Alert Logic | FalsePositive | IncorrectAlertLogic | | False Positive (other reasons) | FalsePositive | InaccurateData | | Benign Positive (any reason) | BenignPositive | SuspiciousButExpected | | Undetermined | Undetermined | none | ### Microsoft Defender XDR All fifteen Defender determinations are canonical ContraForce reasons, so most verdicts round-trip exactly. | Canonical | Defender classification | Defender determination | | --------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | True Positive | TruePositive | The chosen reason (Multistage Attack, Malware, Malicious User Activity, Unwanted Software, Phishing, Compromised User, APT, Other) | | False Positive | FalsePositive | The chosen reason (Not Malicious, Not Enough Data To Validate, Other) | | Benign Positive | InformationalExpectedActivity | The chosen reason (Security Testing, Confirmed User Activity, Line Of Business Application, Security Personnel, Other) | | Undetermined | Unknown | none | Reasons Defender cannot store for the mapped classification (for example a Sentinel-origin reason like Inaccurate Data) are written as Other; the canonical reason stays intact in ContraForce. ### SentinelOne SentinelOne records an analyst verdict and has no reason concept. Reasons are preserved in ContraForce only. | Canonical | SentinelOne analyst verdict | | --------------- | --------------------------- | | True Positive | true\_positive | | False Positive | false\_positive | | Benign Positive | false\_positive | | Undetermined | undefined | When reading from SentinelOne, both `suspicious` and `undefined` map to Undetermined. ### CrowdStrike Falcon CrowdStrike's unified Alerts API has no classification concept, so there is no vendor write-back. Classifications on CrowdStrike incidents live entirely in ContraForce: the full canonical taxonomy is available when closing, and the verdict, reason, and comment are stored and displayed by ContraForce. ## Closures made in the vendor's portal When an incident is closed in the vendor's own console instead of through ContraForce, ContraForce reconciles the closure: the vendor's classification is translated to the canonical taxonomy, an activity entry attributed to the upstream source is added to the incident's audit trail, closure metrics are recorded, and the `incident.closed.v1` webhook fires with `closedBy.origin` set to `upstream`. ## Webhooks The `incident.closed.v1` webhook event carries the canonical classification and reason names, never raw vendor vocabulary. See the API reference for the payload schema. ## Historical data Before this taxonomy unified, ContraForce carried vendor-specific classification values. Historical data is translated on read: | Legacy value | Canonical value | | ----------------------------- | --------------- | | InformationalExpectedActivity | Benign Positive | | Unknown | Undetermined | | NonIssue | Benign Positive | | PolicyViolation | Benign Positive | | QradarFalsePositive | False Positive | | Undefined | Undetermined | | Suspicious | Undetermined | API consumers see canonical names in all responses; requests that still send legacy names are accepted and translated. # Microsoft Defender for Endpoint Module Source: https://docs.contraforce.com/defender-for-endpoint-module Enable endpoint visibility and management in ContraForce by consenting the Microsoft Defender for Endpoint enterprise application. The Microsoft Defender for Endpoint enterprise application enables ContraForce to access Microsoft Defender for Endpoint (MDE) data. Once consented, you gain visibility into endpoints across your managed tenants and can perform response actions directly from ContraForce. This enterprise application is required for device insights and endpoint-related Gamebook actions in ContraForce. ## What This Application Enables View all devices managed by Defender for Endpoint across your workspaces Access device information including OS, health state, and exposure level See device-related incidents and timeline data during investigations Execute endpoint Gamebooks (with additional consent) *** ## Features Enabled Once consented, the Microsoft Defender for Endpoint enterprise application enables the following capabilities: ### Entity Insights During incident investigation, access device-related insights: | Insight | Description | | --------------------- | -------------------------------------------- | | **Device Timeline** | Chronological view of events on the endpoint | | **Device Info** | Detailed hardware and software information | | **Related Incidents** | Other incidents involving the same device | ### Incident Data The application also enables: * Bi-directional incident streaming from Defender for Endpoint * Fetching incident entities and evidence * Alert timelines and investigation audit trails For full endpoint response capabilities (isolate, scan, quarantine), you'll also need to consent the **Gamebooks for Defender for Endpoint** enterprise application. *** ## Permissions The Microsoft Defender for Endpoint enterprise application requests the following Microsoft Graph and Defender API permissions: ### Required Permissions | Permission | Type | Purpose | | -------------------------------- | ----------- | ------------------------------------------ | | **Machine.Read.All** | Application | Read device information from MDE | | **Machine.ReadWrite.All** | Delegated | Access device details during user sessions | | **SecurityEvents.Read.All** | Application | Read security alerts and incidents | | **SecurityEvents.ReadWrite.All** | Delegated | Update incident status and assignments | These permissions grant read access to endpoint data across the tenant. Ensure you have proper authorization before consenting on behalf of customers. ### Permission Types Explained | Type | Description | Use Case | | --------------- | -------------------------------- | ------------------------------- | | **Application** | Runs without user context | Background data synchronization | | **Delegated** | Runs on behalf of signed-in user | Interactive portal access | *** ## Prerequisites Before consenting this enterprise application: MDE must be deployed and active in the target tenant Microsoft 365 Business Premium, E3, or E5 (or standalone MDE license) Cloud App Admin, Application Admin, or Global Admin role in the target tenant The workspace must be created and the tenant onboarded *** ## How to Consent ### Step 1: Navigate to Workspace Modules Go to the **Workspaces** page in ContraForce Find the workspace you want to configure Click the **gear icon** or **Modules** to access workspace settings ### Step 2: Add the Module Click the **Add Module** button Choose **Microsoft Defender for Endpoint** from the list Click **Confirm** to add the module to the workspace ### Step 3: Consent Permissions Click on the **Microsoft Defender for Endpoint** module you just added Scroll down to see the list of permissions required Click the **Consent** button to start the consent flow Sign in with a Cloud App Admin, Application Admin, or Global Admin account from the target tenant Review and accept the requested permissions Microsoft Defender for Endpoint permission consent The consent flow is a 3-step process. Ensure you complete all steps for the application to function correctly. *** ## Verifying Consent After consenting, verify the application is working: ### In ContraForce 1. Navigate to the **Endpoints** page 2. Select the workspace you just configured 3. Confirm devices are populating in the list ### In Microsoft Entra ID 1. Go to **Azure Portal** > **Microsoft Entra ID** > **Enterprise Applications** 2. Search for "ContraForce" or the application name 3. Verify the application appears with **Enabled** status 4. Check **Permissions** to confirm grants are in place *** ## Capability Matrix The Microsoft Defender for Endpoint integration capabilities vary by license: | Capability | Business Premium | E3 | E5 | | --------------------------------- | :--------------: | :-: | :-: | | **Incident Management** | | | | | Bi-directional incident streaming | ✓ | ✓ | ✓ | | Fetch incident entities | ✓ | ✓ | ✓ | | Fetch incident evidence | ✓ | ✓ | ✓ | | Alert timelines | ✓ | ✓ | ✓ | | **Device Insights** | | | | | Device info | ✓ | ✓ | ✓ | | Device timeline | ✓\* | ✓\* | ✓ | | Related incidents | ✓\* | ✓\* | ✓ | | **Endpoint Management** | | | | | View device list | ✓ | ✓ | ✓ | | View device info | ✓ | ✓ | ✓ | \*Requires Microsoft Defender for Endpoint Plan 2 add-on View the complete Defender capability matrix including Gamebook actions *** ## Related Enterprise Applications The Microsoft Defender for Endpoint application works alongside other ContraForce enterprise applications: | Application | Purpose | | ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | **[Gamebooks for Defender for Endpoint](/guides/technical/contraforce-gamebooks-for-defender-for-endpoint-enterprise-application)** | Endpoint response actions (isolate, scan, quarantine) | | **[Gamebooks for Identity](/guides/technical/contraforce-gamebooks-for-identity-enterprise-application)** | User response actions (disable, reset password) | | **[Microsoft 365 Response](/guides/technical/contraforce-microsoft-365-response-enterprise-application)** | Email response actions (delete email) | | **[Azure Response](/guides/technical/contraforce-azure-response-enterprise-application)** | Azure resource response actions | For a complete MXDR setup, consent all relevant enterprise applications based on the response capabilities you need. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ---------------------------- | ------------------------ | ----------------------------------------------------------------- | | **No devices showing** | Consent incomplete | Re-run the consent flow and complete all steps | | **Consent fails** | Insufficient permissions | Use a Cloud App Admin, Application Admin, or Global Admin account | | **Partial data** | MDE not fully deployed | Verify MDE is active on target devices | | **Stale device data** | Sync delay | Wait 15-30 minutes for initial sync | | **Permission denied errors** | Consent revoked | Check Entra ID enterprise apps and re-consent | ### Checking Consent Status In the workspace modules view, consented applications show a green checkmark or "Consented" status. If you see "Not Consented" or a warning icon, re-run the consent process. ### Revoking Consent If you need to revoke consent: 1. Go to **Azure Portal** > **Microsoft Entra ID** > **Enterprise Applications** 2. Find the ContraForce Defender for Endpoint application 3. Go to **Properties** and set **Enabled for users to sign-in** to **No** 4. Or delete the application entirely Revoking consent will disable MDE data access in ContraForce for that workspace. *** ## Best Practices Add and consent the Microsoft Defender for Endpoint module during initial workspace onboarding for a smoother setup experience. Create a dedicated service account with Cloud App Admin or Application Admin permissions for consenting enterprise applications across customer tenants. Track which enterprise applications are consented for each workspace to simplify troubleshooting. If you need Gamebook response actions, consent both Microsoft Defender for Endpoint and Gamebooks for Defender for Endpoint at the same time. Always verify Defender for Endpoint data is flowing into ContraForce after completing the consent flow. *** ## Related Guides Overview of all ContraForce enterprise applications Enable endpoint response actions Full Defender feature capabilities *** Questions about the Microsoft Defender for Endpoint enterprise application? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Entity Insights Source: https://docs.contraforce.com/entity-insights Enrich your investigations with detailed entity insights. View sign-in logs, audit trails, threat intelligence, and related incidents for users, devices, IPs, and more. Entity Insights provide rich context during incident investigations. Instead of switching between tools to gather information about affected users, devices, or IP addresses, ContraForce surfaces relevant data directly within the incident view. Available insights vary by entity type and your connected data sources. The more integrations you have enabled, the richer your entity insights will be. ## Why Entity Insights Matter Access critical context without leaving ContraForce See related incidents, logs, and threat intel in one place Make informed response choices with full entity context *** ## Available Insights by Entity Type ContraForce provides different insights depending on the entity type associated with an incident. **User entities** include accounts, identities, and mailboxes. | Insight | Description | | --------------------- | ----------------------------------------------------------------------- | | **Related Incidents** | Other incidents involving this user | | **Sign-In Logs** | Authentication history including locations, devices, and outcomes | | **Audit Logs** | Administrative actions and changes made by or to this user | | **User Insights** | Account details, group memberships, risk score, and profile information | *Use cases: Investigating compromised accounts, tracking lateral movement, understanding user behavior patterns* **Device entities** include endpoints, servers, and mobile devices. | Insight | Description | | --------------------- | ------------------------------------------------------------ | | **Timeline** | Chronological view of events and activities on the device | | **Related Incidents** | Other incidents involving this device | | **Device Insights** | Hardware details, OS version, security state, exposure level | *Use cases: Tracking malware spread, understanding attack chains, assessing device health* **IP entities** include source and destination addresses from network activity. | Insight | Description | | --------------------- | ----------------------------------------------------- | | **Related Incidents** | Other incidents involving this IP address | | **IP Insight Logs** | Geolocation, reputation, ASN, and historical activity | *Use cases: Identifying malicious infrastructure, tracking C2 communications, investigating data exfiltration* **Email entities** include messages, attachments, and sender/recipient information. | Insight | Description | | --------------------- | --------------------------------------------------------------- | | **Email Insights** | Message details, headers, attachments, and delivery information | | **Related Incidents** | Other incidents involving this email or sender | *Use cases: Investigating phishing campaigns, tracking malicious attachments, analyzing email-based attacks* **File entities** include executables, documents, scripts, and their hashes. | Insight | Description | | --------------------- | --------------------------------------------------------------------- | | **Related Incidents** | Other incidents involving this file or hash | | **File Insights** | File metadata, hash values, detection ratios, and threat intelligence | *Use cases: Tracking malware variants, identifying suspicious files, correlating file-based IOCs* **URL entities** include web addresses and domains involved in incidents. | Insight | Description | | --------------------- | ---------------------------------------------------------------- | | **Related Incidents** | Other incidents involving this URL or domain | | **URL Insights** | Domain reputation, registration details, and threat intelligence | *Use cases: Investigating phishing links, blocking malicious domains, tracking web-based threats* *** ## Accessing Entity Insights Follow these steps to view insights for any entity in an incident. From the Command Page, click the **Incident ID** in the Incidents table to open the compact incident overview Click the **diagonal arrows** icon (next to the X) in the top right corner to open the detailed incident view Click the **Entities** tab to see all associated entities Click the **three dots (⋮)** on any entity row to see available insights Choose the insight you want to view from the dropdown menu Entity insights menu for a user *** ## Working with Insights ### Multiple Insights You can open multiple insights simultaneously: * Each insight opens in its own **tab** within the popup window * Switch between tabs to compare information * The popup window can be **resized** for better viewing Multiple entity insight tabs ### Insight Details Each insight type displays relevant information in an organized format: **Columns typically include:** * Timestamp * Sign-in status (Success/Failure) * IP address and location * Device and browser information * Conditional access results * Risk level **Filter by:** Date range, status, location, risk level **Columns typically include:** * Timestamp * Activity type * Target resource * Initiated by (user/service) * Result (Success/Failure) **Filter by:** Date range, activity type, target **Information displayed:** * Display name and UPN * Job title and department * Manager * Group memberships * Account status * Risk score * Last sign-in **Information displayed:** * Device name and ID * OS platform and version * Health state * Exposure level * Last seen timestamp * Compliance status * Logged-on users **Information displayed:** * Geolocation (country, city) * ASN and ISP * Reputation score * Associated domains * Historical activity * Threat intelligence matches **Information displayed:** * File name and path * SHA256, SHA1, MD5 hashes * File size * First/last seen * Detection ratio * Threat intelligence enrichment *** ## Related Incidents The **Related Incidents** insight is available for all entity types and shows other incidents where the same entity appears. ### Why This Matters * **Pattern Detection** — Identify if an entity is repeatedly involved in security events * **Attack Chain Analysis** — Understand how an attacker moved through your environment * **Scope Assessment** — Determine the full impact of a compromise * **False Positive Identification** — Recognize legitimate activity that triggers multiple alerts ### Using Related Incidents | Column | Description | | --------------- | ---------------------------------- | | **Incident ID** | Click to open the related incident | | **Title** | Brief description of the incident | | **Severity** | High, Medium, Low, Informational | | **Status** | Current state of the incident | | **Created** | When the incident was detected | If you see the same entity in multiple high-severity incidents, prioritize investigating that entity—it may indicate an active compromise. *** ## Threat Intelligence Enrichment Some entity insights include threat intelligence from integrated sources. ### Supported Enrichments | Entity Type | Threat Intel Data | | -------------- | -------------------------------------------------------- | | **IP Address** | Reputation, malicious activity history, blocklist status | | **File/Hash** | VirusTotal detections, malware family, first seen date | | **URL/Domain** | Reputation, phishing indicators, domain age | | **User** | Compromised credential alerts, risk indicators | Threat intelligence enrichment requires integration with tools like VirusTotal or Microsoft Defender Threat Intelligence. Contact your administrator to enable additional enrichment sources. *** ## Integration-Specific Insights Available insights depend on which integrations are connected to your workspace. ### Microsoft Defender for Endpoint * Device timeline and alerts * User sign-in and audit logs * Email trace and threat detection * File and URL analysis ### Microsoft Sentinel * Log Analytics query results * Custom entity enrichments * Watchlist matches * Threat intelligence indicators ### Third-Party Integrations Additional insights may be available based on your connected tools: * **CrowdStrike** — Device details, detection history * **SentinelOne** — Agent status, threat indicators *** ## Best Practices Always check Related Incidents first. If an entity appears in multiple incidents, it may be the key to understanding the attack scope. Compare sign-in logs with the incident timeline. Look for unusual locations, impossible travel, or authentication failures before the incident. When investigating compromised accounts, review audit logs for privilege changes, group membership modifications, or unusual administrative actions. For device-based incidents, the timeline shows the sequence of events leading to detection—crucial for understanding initial access and lateral movement. Copy important insight data to incident comments for team visibility and post-incident documentation. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ------------------------- | ----------------------------------- | ------------------------------------------------------ | | **No insights available** | Entity type not supported | Check the Capabilities Matrix for supported entities | | **Missing sign-in logs** | Entra ID integration not connected | Verify Azure AD/Entra ID connector status | | **Empty device timeline** | Defender for Endpoint not onboarded | Confirm MDE integration is enabled | | **No threat intel data** | Enrichment source not configured | Contact admin to enable VirusTotal or other TI sources | *** ## Related Guides Complete incident investigation workflow Deep dive investigation interface Take action on entities after investigation *** Questions about entity insights? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Agent Execution History Source: https://docs.contraforce.com/guides/agent-center/agent-execution-history Monitor and audit Security Delivery Agent activity with a complete history of every execution, including status, token usage, and incident details. View a complete audit trail of Security Delivery Agent executions to monitor agent performance, troubleshoot failures, and demonstrate compliance with response policies. The Execution History tab on the Agent Details page provides a sortable table of every time an agent has processed an incident. Each row captures when the execution occurred, who triggered it, which incident was processed, the data source, severity, token consumption, and the outcome — giving you full visibility into automated response activity. *** ## What Can You Do Here? Review every execution an agent has performed, with timestamps and outcomes. Identify failed executions and investigate causes using status and token data. Track AI token consumption per execution to understand cost and complexity. *** ## Prerequisites | Requirement | Description | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Agent Center Deployed** | Azure AI Foundry infrastructure must be provisioned. See [Deploying Agent Center](/guides/onboarding/agent-center-deployment). | | **Security Delivery Agent Configured** | At least one agent must be created and configured. See [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents). | | **ContraForce Roles** | Organizational Admin or Agent Admin role required. | *** ## Accessing Execution History From the left navigation menu, select **Agent Center**. Click the name of the agent you want to review. This opens the Agent Details page. On the Agent Details page, click the **Execution History** tab (next to the **Configuration** tab). Agent Execution History You will see a table displaying all past executions for that agent, sorted by date with the most recent entries at the top. *** ## Understanding the Execution History Table The Execution History table contains the following columns: | Column | Description | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Date** | Timestamp of when the agent execution occurred (e.g., `Feb 19, 2026 03:10 PM`). | | **Triggered By** | The user or process that initiated the execution. Displays the name of the user for manual triggers (e.g., via the Actions menu) or auto-trigger events. | | **Incident** | The incident number the agent processed. Displayed as a clickable link (e.g., `#149631`) that navigates directly to the incident detail page. | | **Source** | The data source the incident originated from (e.g., `Microsoft Sentinel`, `Microsoft Defender for Endpoint`). | | **Severity** | The severity level of the incident: **High**, **Medium**, **Low**, or **Informational**. | | **Tokens** | The number of AI tokens consumed during the execution. Displays `—` if the execution did not complete successfully. | | **Status** | The current state of the execution, displayed as a color-coded badge. | ### Execution Statuses | Status | Color | Description | | ------------- | -------- | ----------------------------------------------------------------------------------- | | **Completed** | 🟢 Green | The agent successfully finished processing the incident. | | **Running** | 🔵 Blue | The agent is currently processing the incident. | | **Failed** | 🔴 Red | The execution encountered an error and did not complete. Token count will show `—`. | *** ## Using Execution History ### Investigate a Processed Incident Click any **Incident** link (e.g., `#149631`) in the table to navigate directly to that incident's detail page. From there, you can review the full incident timeline, entity context graph, and any Gamebook actions that were executed. ### Identify Failed Executions Filter or scan for rows with a **Failed** status. Failed executions typically show `—` in the Tokens column, indicating the agent did not complete its analysis. Common causes include: | Possible Cause | What to Check | | --------------------------------- | ---------------------------------------------------------------- | | Agent Center infrastructure issue | Verify the Logic App is enabled in the Azure Portal | | Connectivity to data source | Confirm the workspace module consent is active | | Token or rate limit exceeded | Review token consumption trends in recent executions | | Incident no longer available | Check if the incident was deleted or merged in the source system | If failures persist, contact [support@contraforce.com](mailto:support@contraforce.com) with the agent name, affected incident numbers, and the timestamps of the failed executions. ### Monitor Token Consumption The **Tokens** column shows how many AI tokens were consumed per execution. This helps you understand the complexity of agent processing and monitor usage. Executions that involve larger incidents with more entities and evidence will typically consume more tokens. Compare token counts across similar incidents to establish a baseline. Unusually high token usage on a routine incident may indicate the agent is processing excessive data or encountering retry loops. *** ## Best Practices Check the Execution History tab periodically to confirm agents are processing incidents as expected. Look for patterns in failures, unexpected token spikes, or gaps in execution activity. If the same incident appears multiple times with a Failed status, the issue is likely environmental (permissions, connectivity) rather than incident-specific. Check the troubleshooting table above. The Execution History table serves as an audit trail for automated response activity. Use it to demonstrate that incidents were triaged and processed within your SLA requirements. Cross-reference Execution History entries with the Gamebook Activity widget on the Command Dashboard to verify that agent-initiated Gamebooks completed successfully. *** ## Troubleshooting | Issue | Possible Cause | Solution | | --------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | No entries in Execution History | Agent has not processed any incidents yet | Verify the agent Mode is set to **On Queue**, or manually trigger an investigation from an incident's **Actions** menu | | All executions show Failed | Agent Center infrastructure issue | Check that the Logic App is enabled in the Azure Portal and that Azure AI Foundry resources are healthy | | Incident link returns an error | Incident was deleted or merged | Verify the incident exists in the source system (Sentinel or Defender for Endpoint) | | Token column shows `—` | Execution failed before completion | Review the Status column — failed executions do not record token usage | | Execution History tab not visible | Feature not available in your environment | Confirm Agent Center is deployed and you have the required roles | *** ## Related Guides Set up and configure agents using the three-phase adoption model. Deploy the Azure AI Foundry infrastructure required for agents. Learn how incidents flow through ContraForce. Monitor agent activity and incident trends from mission control. *** Questions about Agent Execution History? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Agent Investigation Completed Webhook Source: https://docs.contraforce.com/guides/agent-center/agent-investigation-webhook Receive, verify, and parse the agent.investigation.completed.v1 webhook that ContraForce sends when a Security Delivery Agent finishes investigating an incident. When a Security Delivery Agent finishes investigating an incident, ContraForce can send a signed webhook to an endpoint you control. Use it to escalate true-positive incidents into your SIEM, ticketing, or on-call tooling at the moment the agent reaches a verdict. This event is configured per classification on an Agent Configuration card, not as a broadcast subscription. It is delivered **only** to the webhook a classification card points to. Set it up under [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents) by enabling **Advanced** mode and choosing a webhook as the **custom action** for a classification. *** ## When It Fires The event fires once per investigation, when the agent completes and reaches a classification, for any classification whose policy has a webhook custom action configured. The event type (schema) is: ``` agent.investigation.completed.v1 ``` *** ## Request Headers Every delivery includes these headers. Use them to verify authenticity before trusting the body. | Header | Value | Notes | | ---------------- | ------------------------------------ | ------------------------------------------------------------- | | `X-CF-Schema` | `agent.investigation.completed.v1` | The event type. | | `X-CF-Event-Id` | A unique event identifier (GUID) | Use it to deduplicate retries. | | `X-CF-Timestamp` | ISO 8601 timestamp | Reject if it is more than 5 minutes from your clock. | | `X-CF-Signature` | Base64-encoded HMAC-SHA256 signature | See verification below. | | `X-CF-Test` | `true` | Present only for test deliveries. | | `Authorization` | `Bearer ` or `Basic ` | Present only if you configured authentication on the webhook. | Retries reuse the same `X-CF-Event-Id`. Treat delivery as at-least-once and make your handler idempotent. *** ## Verifying the Signature The signature covers the timestamp and the exact raw request body: ``` signature = Base64( HMAC_SHA256( signing_key, X-CF-Timestamp + "." + raw_body ) ) ``` The `signing_key` is the secret shown once when the webhook was created, unless you supplied your own signing token override when setting bearer-token credentials, in which case it is that token. Compute the signature over the unparsed request body bytes, before any JSON deserialization. Concatenate the `X-CF-Timestamp` value, a literal `.`, and the raw body. HMAC-SHA256 it with your signing key and Base64-encode the result. Compare your value to `X-CF-Signature` using a constant-time comparison. Reject on mismatch. Reject the request if `X-CF-Timestamp` is more than 5 minutes from current time, to limit replay. ```python verify.py theme={null} import base64, hashlib, hmac, time from datetime import datetime, timezone def verify(signing_key: str, headers: dict, raw_body: bytes) -> bool: ts = headers["X-CF-Timestamp"] sent = headers["X-CF-Signature"] signed = ts.encode() + b"." + raw_body expected = base64.b64encode( hmac.new(signing_key.encode(), signed, hashlib.sha256).digest() ).decode() if not hmac.compare_digest(expected, sent): return False age = abs(time.time() - datetime.fromisoformat(ts).replace(tzinfo=timezone.utc).timestamp()) return age <= 300 ``` ```csharp Verify.cs theme={null} static bool Verify(string signingKey, string timestamp, string sentSignature, byte[] rawBody) { var signed = System.Text.Encoding.UTF8.GetBytes(timestamp + ".") .Concat(rawBody).ToArray(); using var hmac = new System.Security.Cryptography.HMACSHA256( System.Text.Encoding.UTF8.GetBytes(signingKey)); var expected = Convert.ToBase64String(hmac.ComputeHash(signed)); var match = System.Security.Cryptography.CryptographicOperations.FixedTimeEquals( System.Text.Encoding.UTF8.GetBytes(expected), System.Text.Encoding.UTF8.GetBytes(sentSignature)); var age = Math.Abs((DateTimeOffset.UtcNow - DateTimeOffset.Parse(timestamp)).TotalSeconds); return match && age <= 300; } ``` *** ## Payload The body is JSON with camelCase fields. Like every ContraForce webhook, the event-specific payload is nested under `data` inside a common envelope: ```json theme={null} { "type": "agent.investigation.completed.v1", "timestamp": "2026-08-03T14:31:09.740Z", "isTest": false, "occurredAt": "2026-08-03T14:31:02.310Z", "data": { "workspace": { "id": "00000000-0000-0000-0000-000000000000", "alias": "contoso", "name": "Contoso Production" }, "agent": { "id": "agent-identifier", "name": "Tier 1 Triage Agent" }, "incident": { "id": "source-system-incident-id", "number": 4242, "source": "Sentinel", "title": "Suspicious sign-in from impossible travel", "severity": "High", "status": "Active" }, "verdict": { "classificationBucket": "TruePositive", "classificationReason": "MaliciousActivity", "classificationReasonComment": "Confirmed credential theft", "comment": "Sign-in originated from a known-malicious ASN minutes after a login from the user's usual location." }, "gamebookRecommendation": { "incidentNumber": 4242, "incidentTitle": "Suspicious sign-in from impossible travel", "playbooks": [ { "playbookId": "disable-user", "affectedEntity": "Account", "entityId": "jdoe@contoso.example", "sequence": 1 } ] } } } ``` Sign and verify the full raw body, envelope included. Do not compute the signature over the `data` object alone. ### Fields Field paths below are relative to `data`. | Field | Type | Description | | ------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------- | | `workspace.id` / `alias` / `name` | string | The ContraForce workspace the incident belongs to. | | `agent.id` / `name` | string | The Security Delivery Agent that ran the investigation. | | `incident.id` | string | The source system's incident identifier. | | `incident.number` | number | The incident number shown in the portal. | | `incident.source` | string | Detection source, for example `Sentinel`. | | `incident.title` | string | Incident title. | | `incident.severity` | string | Incident severity, for example `High`. | | `incident.status` | string | Incident status at completion. | | `verdict.classificationBucket` | string | The agent's verdict. One of `TruePositive`, `BenignPositive`, `FalsePositive`, `Undetermined`. | | `verdict.classificationReason` | string \| null | Reason code for the classification. | | `verdict.classificationReasonComment` | string \| null | Free-text reason detail. | | `verdict.comment` | string | The agent's investigation summary comment. | | `gamebookRecommendation` | object \| null | Present only when the agent recommended gamebooks. | | `gamebookRecommendation.playbooks[]` | array | Recommended gamebooks, each with `playbookId`, `affectedEntity`, `entityId`, and `sequence`. | Branch on `verdict.classificationBucket`. It is a stable, vendor-neutral value, so your integration does not need to handle source-specific classification strings. *** ## Testing Use the **Send test** action on the webhook in **Developers** to deliver a synthetic event. Test deliveries carry `X-CF-Test: true` and use sample data. They are signed identically to live events, so you can validate your verification code end to end. *** ## Troubleshooting | Symptom | Likely cause | Resolution | | --------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No events arrive | The classification card does not point to this webhook, or Advanced mode is off | Confirm the webhook is set as the custom action for the classification and that Advanced mode is enabled and saved | | Events stop arriving | The webhook was deleted, paused, disabled, or unsubscribed | The classification card shows a binding warning. Fix the webhook in Developers. Skipped deliveries are recorded as **Failed** in the delivery log, not dropped silently | | Signature check fails | Verifying a parsed body instead of the raw bytes, or using the wrong key | Sign the raw request body, and use the signing token override if one was set | | Duplicate events | Normal retry behavior | Deduplicate on `X-CF-Event-Id` | *** ## Other Event Types This is one of five events ContraForce can deliver. For the complete list, including incident creation, incident closure, and gamebook runs, see the [Webhook Event Reference](/api-reference/webhook-events). Questions about the agent investigation webhook? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Defender for Endpoint On-Queue Source: https://docs.contraforce.com/guides/agent-center/defender-for-endpoint-on-queue Enable Security Delivery Agents to automatically detect and respond to Microsoft Defender for Endpoint incidents without Sentinel forwarding. ## Overview Agent On-Queue for Defender for Endpoint allows ContraForce Security Delivery Agents to automatically detect and respond to incidents originating directly from Microsoft Defender for Endpoint with no Microsoft Sentinel forwarding required. Previously, agents could only auto-trigger on incidents ingested through Sentinel. Customers using Defender for Endpoint directly had to manually trigger agent actions. With this update, ContraForce polls Defender for Endpoint for new incidents approximately every **2 minutes**, automatically triggering your agent to triage and respond in order to deliver the autonomous SOC experience with minimal time-to-respond. If your environment already forwards Defender for Endpoint incidents to Microsoft Sentinel (`FetchToSentinel = true`), your existing agent workflow is unaffected. This feature is designed for environments where Sentinel forwarding is **not** configured. ## How It Works ContraForce continuously polls the Microsoft Defender for Endpoint security API for new incidents across all eligible customer accounts. When a new incident is detected: 1. The platform identifies the incident and checks it against previously processed incidents to prevent duplicates. 2. A notification is queued for processing. 3. ContraForce validates that the account has a deployed agent with the appropriate severity capability for the incident. 4. The agent is automatically triggered on-queue to investigate and respond — just as it would for Sentinel-ingested incidents. The entire pipeline runs automatically. No manual intervention is required once configured. ## Prerequisites Before Agent On-Queue for Defender for Endpoint can activate for a workspace, **all** of the following must be true: The account must have an **Active** or **Trial** ContraForce subscription. The Defender for Endpoint security provider must be enabled for the workspace. See [Defender for Endpoint Module Deployment](/guides/onboarding/defender-for-endpoint-module-deployment) for setup instructions. Microsoft consent must be granted for the Defender for Endpoint module. This is the same single **Consent** action completed on the **Modules** tab when deploying the Defender module, granted by a **Global Administrator**. The workspace must **not** be configured to forward Defender for Endpoint incidents to Sentinel. If `FetchToSentinel` is enabled, incidents are ingested through the existing Sentinel pipeline instead. A Security Delivery Agent must be deployed via [Agent Center](/guides/onboarding/agent-center-deployment) with the **ProcessIncident** capability enabled for the target incident severity levels (High, Medium, Low, Informational). Not sure if your workspace meets these requirements? Navigate to **Agent Center** in the ContraForce portal and verify your agent's status shows **On Queue**. If the agent is deployed but not processing Defender for Endpoint incidents, review the prerequisites above. ## What Changes for You ### If you use Defender for Endpoint without Sentinel This is the feature for you. Once the prerequisites are met, your agent will begin automatically processing Defender for Endpoint incidents within approximately 2 minutes of their creation. No configuration changes are needed on your end — the platform handles everything. ### If you already forward to Sentinel Nothing changes. Your incidents continue to flow through the Sentinel ingestion pipeline as before. The Defender for Endpoint polling pipeline automatically excludes accounts with Sentinel forwarding enabled. ### If you use both Accounts are evaluated individually. Workspaces with Sentinel forwarding enabled use the Sentinel pipeline. Workspaces without Sentinel forwarding use the new Defender for Endpoint polling pipeline. There is no overlap or duplicate processing. ## Configuring Your Agent for Defender for Endpoint Incidents If you already have a Security Delivery Agent deployed and configured, no additional setup is required. The platform automatically detects eligible workspaces and begins polling. To deploy or configure an agent: 1. Navigate to **Agent Center** from the left navigation menu. 2. Deploy your agent following the [Agent Center Deployment](/guides/onboarding/agent-center-deployment) guide. 3. Configure the agent's **ProcessIncident** capability and select which severity levels the agent should handle automatically. 4. Set the agent mode to **On Queue**. Once the agent is on-queue with ProcessIncident enabled, ContraForce will begin polling Defender for Endpoint and triggering the agent for matching incidents. For a phased rollout, start with the agent in **Manual** mode where the agent suggests actions and you approve. Once you're confident in the response quality, move to **Automatic** or **Full Autonomous** mode. See [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents) for details on agent modes. ## Verifying It's Working After setup, confirm that the pipeline is active: 1. **Check Agent Center** — Verify your agent status shows **On Queue** and the mode is set to your preferred level (Manual, Automatic, or Autonomous). 2. **Monitor the Command Dashboard** — New Defender for Endpoint incidents should appear on the [Command Dashboard](/guides/getting-started/command-dashboard) within approximately 2 minutes of creation in Defender. 3. **Review Gamebook Activity** — When the agent processes an incident, you'll see corresponding Gamebook activity in the [Gamebook Activity](/guides/getting-started/what-are-gamebooks) widgets and the incident's Workbench. 4. **Check Agent Execution History** — Navigate to Agent Center to review the agent's execution history and confirm incidents are being processed. ## Incident Detection Timing ContraForce polls Defender for Endpoint approximately every **2 minutes**. This means: * New incidents are typically detected within 2 minutes of appearing in Defender for Endpoint. * The agent is triggered immediately after detection and validation. * End-to-end time from incident creation to agent response initiation is typically **under 5 minutes**. ## Troubleshooting | Issue | Likely Cause | Resolution | | -------------------------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | Agent not processing Defender for Endpoint incidents | Agent not set to "On Queue" mode | Navigate to **Agent Center** and set the agent mode to **On Queue** | | Incidents not appearing from Defender for Endpoint | Module consent not granted | Re-run the **Consent** action from the workspace **Modules** tab using **Global Administrator** credentials | | Duplicate incidents appearing | Sentinel forwarding is also enabled | Verify the workspace is not forwarding Defender for Endpoint incidents to Sentinel. Only one ingestion path should be active | | Agent triggers for wrong severity levels | ProcessIncident capability misconfigured | Review the agent's severity capability settings in **Agent Center** and adjust which severity levels are handled | | No incidents detected despite active Defender for Endpoint incidents | Account eligibility not met | Verify all [prerequisites](#prerequisites) are satisfied — subscription status, module enablement, module consent, and agent deployment | | Agent was working but stopped processing | Subscription lapsed or consent revoked | Confirm subscription is still Active/Trial and re-grant module **Consent** if needed | If the issue persists after reviewing the above, contact [**support@contraforce.com**](mailto:support@contraforce.com) with: * Workspace name * Agent status screenshot from Agent Center * Approximate timestamp of the incident that was not processed * Any error messages visible in the portal ## Frequently Asked Questions **Do I need to change anything if I'm already using Sentinel?** No. If your workspace forwards Defender for Endpoint incidents to Sentinel, your existing pipeline continues to work. The Defender for Endpoint polling pipeline automatically skips your account. **Can I use both Sentinel and direct Defender for Endpoint ingestion for the same workspace?** No. Each workspace uses one ingestion path. If Sentinel forwarding is enabled, incidents come through Sentinel. If it's disabled, incidents come through the Defender for Endpoint polling pipeline. This prevents duplicate processing. **What response actions are available for Defender for Endpoint incidents?** The same Gamebook response actions available for any incident — device isolation, account disabling, password resets, IP/URL blocking, file quarantine, email deletion, and more. See the [Microsoft Defender Capability Matrix](/guides/technical/microsoft-defender-capability-matrix) for the full list based on your license. **Is there any additional cost for this feature?** No. Agent On-Queue for Defender for Endpoint is included with your existing ContraForce subscription and agent deployment. No additional modules or licenses are required beyond the standard Defender module and Agent Center. **What happens if the polling service restarts?** Polling state is persisted per account. If the service restarts, it resumes from the last known position with a configurable overlap window to ensure no incidents are missed. # SOP Knowledge Base Source: https://docs.contraforce.com/guides/agent-center/sop-knowledge-base Upload, manage, and associate Standard Operating Procedures with AI Agents to ensure consistent, policy-driven incident response. Upload your team's Standard Operating Procedures directly into ContraForce, then associate them with AI Agents so every incident is handled according to your organization's specific policies. **Who is this for?** Organizational Admins and Agent Admins who manage Security Delivery Agents and want to standardize incident classification and response procedures. SOP Knowledge Base is located in the **Agent Center** section of the left navigation menu. *** ## SOP Types ContraForce supports two types of SOPs, each designed for a different phase of incident handling. ### Classification SOPs Classification SOPs define how incidents should be categorized and prioritized. These contain your organization's specific severity definitions, escalation criteria, and triage procedures. Each AI Agent can have **multiple** Classification SOPs associated with it, but only **one** Classification SOP is activated per investigation. This ensures that every incident processed by that Agent follows a single, consistent classification standard while giving you the flexibility to maintain several classification approaches for different scenarios. ### Response SOPs Response SOPs contain procedures for how to respond to and remediate security incidents. These include containment steps, investigation workflows, communication protocols, and recovery procedures. Each AI Agent can have **multiple** Response SOPs associated with it, and each Response SOP can be shared across **multiple** Agents. This many-to-many relationship means you can assign your phishing response playbook to three different Agents without duplicating the document. *** ## Supported File Formats SOP Knowledge Base accepts the following document formats: | Format | Extensions | | ---------- | ---------- | | Markdown | `.md` | | Plain Text | `.txt` | Additional formats (PDF, Word, HTML, RTF) are coming soon. Maximum file size is 10 MB per document. *** ## Uploading an SOP Navigate to **Agent Center** in the left navigation menu, then select **SOP Knowledge Base**. Click the **Upload SOP** button. The upload modal will appear. Choose either **Classification** or **Response** to categorize the SOP. This determines how the SOP can be associated with AI Agents. Drag and drop your file into the upload area, or click to browse and select a file from your computer. Enter a **title** for the SOP. Optionally, add **tags** for easier searching and organization, and map the SOP to relevant **MITRE ATT\&CK** techniques. Click **Save** to upload the SOP. ContraForce extracts and indexes the document content automatically. *** ## Viewing SOP Content After uploading, you can view the full content of any SOP directly within ContraForce without switching to an external application. 1. Open **Agent Center → SOP Knowledge Base**. 2. Click on any SOP in the list to open the detail view. 3. The detail panel displays the extracted document content, metadata (type, tags, MITRE ATT\&CK mappings, version), and timestamps. You can also download the original file at any time from the detail view. *** ## Associating SOPs with AI Agents You can create SOP-Agent associations from either direction. ### From the SOP detail page 1. Open the SOP you want to associate. 2. Select the **Linked Agents** tab. 3. Click **Add Agent** and select one or more AI Agents from the list. 4. The association takes effect immediately. ### From the Agent detail page 1. Navigate to **Agent Center** and select the Agent you want to configure. 2. Scroll to the **Associated SOPs** section. 3. Click **Add SOP** and select the SOPs you want to associate. 4. You can associate multiple Classification SOPs with an Agent, but only one will be activated per investigation. Changes to SOP-Agent associations take effect immediately. There is no separate publish or deploy step. *** ## Updating an SOP SOP Knowledge Base does not support in-place editing. To update an SOP, upload a new version of the file. All existing Agent associations are preserved when you update the document. Use the **version** field on the SOP to track changes over time. *** ## Searching and Filtering SOPs The SOP list view provides several ways to find the right document quickly: * **Search** by SOP title or content keywords. * **Filter by type** to show only Classification or Response SOPs. * **Sort** by last updated date, title, or associated agent count. Each SOP card in the list displays the SOP type, associated agent count, tags, and last updated timestamp. *** ## Roles and Permissions SOP access follows the ContraForce role-based access control model. | Role | Permissions | | --------------------------------------------------- | ---------------------------------------------------- | | Organizational Admin | Full access: create, view, update, and delete SOPs | | Agent Admin | Create, view, and update SOPs | | Workspace-level roles (Analyst, Incident Responder) | View SOPs associated with Agents they have access to | *** ## How AI Agents Use SOPs When an AI Agent processes an incident, it retrieves the content from its associated SOPs to inform its investigation and response decisions. This means the Agent follows your organization's specific procedures rather than relying on generic response patterns. * **Classification SOPs** guide how the Agent categorizes incident severity and priority. * **Response SOPs** guide the specific containment, investigation, and remediation steps the Agent recommends or executes. For best results, write your SOPs with clear, structured headings and step-by-step procedures. The more structured your document, the more effectively the AI Agent can reference the relevant section during incident handling. *** ## Best Practices **Start with your most critical playbooks.** Upload the SOPs your team uses most frequently first, such as phishing response, ransomware containment, and business email compromise procedures. **Use tags consistently.** Apply tags like `phishing`, `ransomware`, `insider-threat`, or `data-exfiltration` so SOPs are easy to find and can be matched to relevant incidents. **Map to MITRE ATT\&CK techniques.** Associating SOPs with specific techniques helps surface the right procedure when an incident involves those techniques. **Keep SOPs focused.** Rather than uploading one massive document covering everything, break your procedures into focused SOPs by incident type or response phase. This makes Agent associations more precise and retrieval more effective. **Review and update regularly.** Upload new versions of your SOPs as your procedures evolve. ContraForce preserves all Agent associations when you update a document. *** ## Frequently Asked Questions There is no hard limit on the number of SOPs per workspace. We recommend organizing your SOPs thoughtfully and associating only the most relevant procedures with each Agent. Yes. Both SOP types support many-to-many associations, so a single SOP can be linked to multiple Agents. For Classification SOPs, multiple can be associated with an Agent, but only one is activated per investigation. The association is removed automatically. The Agent will continue to function but will no longer reference that SOP during incident handling. SOPs are scoped to individual workspaces. To use the same SOP in multiple workspaces, upload the document to each workspace separately. No. SOP associations take effect immediately. There is no redeployment or restart required. *** ## Related Guides Set up and configure agents using the three-phase adoption model. Monitor and audit agent activity with a complete execution trail. Deploy the Azure AI Foundry infrastructure required for agents. Learn how incidents flow through ContraForce. *** Questions about SOP Knowledge Base? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce and Cyber Insurance Source: https://docs.contraforce.com/guides/contraforce-and-compliance/contraforce-and-cyber-insurance # How ContraForce Helps You Meet Cyber Insurance Requirements Cyber insurance applications have gotten harder. Carriers have moved beyond simple checklists. They now want verified controls, documented response timelines, and real evidence that your security stack is doing what you say it does. If you're using ContraForce, you're already covered on most of what they're asking for. This article breaks down exactly how. *** ## What Carriers Are Looking For Every insurance provider structures their application differently, but the core requirements have converged around the same set of controls. Here's what shows up on virtually every application in 2025: * 24/7 security monitoring with a SOC or equivalent * Endpoint detection and response (EDR or XDR) * Centralized log management (SIEM) * A documented and tested incident response plan * Vulnerability management and patching * MFA enforcement and identity monitoring * Email security and anti-phishing controls ContraForce addresses all of these through a single platform. Here's how each one maps. *** ## 24/7 MXDR: Your SOC Answer The most common question on any cyber insurance form: *"Do you have 24/7 security monitoring with detection and response capabilities?"* ContraForce runs AI-powered Managed Extended Detection and Response around the clock. Our AI agents monitor, triage, investigate, and respond to threats across endpoints, identity, email, and cloud workloads without gaps in coverage. When something malicious is detected, the platform can isolate endpoints, disable compromised accounts, and contain the threat automatically, all with timestamped audit trails. That documented "alert-to-action timeline" is exactly what underwriters are looking for when they evaluate SOC maturity. *** ## Microsoft Sentinel: SIEM in Your Tenant Carriers are increasingly requiring SIEM as a baseline control, especially for larger policies. ContraForce deploys Microsoft Sentinel directly in your Azure tenant, collecting and correlating logs from across your environment: endpoints, identity, email, cloud workloads, and network sources. Our AI layer cuts through the noise so real threats get surfaced fast. Log retention is configurable to meet whatever window your carrier requires (90, 180, or 365 days), and because everything lives in your tenant, your data stays under your control. *** ## Microsoft Defender for Endpoint: EDR That's Actually Managed Nearly every carrier requires EDR on all in-scope endpoints. ContraForce manages Microsoft Defender for Endpoint as a fully managed service, providing real-time detection, automated response, and forensics. Defender telemetry flows directly into Sentinel, so your detection and response pipeline is unified rather than siloed. You get endpoint coverage reports showing exactly which devices are protected, which is the evidence carriers want to see. *** ## Incident Response: Documented by Default Carriers don't just want to know you have an incident response plan. They want to see that it's structured, tested, and produces real documentation. ContraForce handles this natively. Every incident follows a structured lifecycle (detection, triage, investigation, containment, eradication, recovery) and each step is documented automatically. The platform generates post-incident reports with full timelines, indicators of compromise, and actions taken. No scrambling to assemble evidence after the fact. *** ## Vulnerability Management: Continuous, Not Quarterly Through the Defender for Endpoint integration, ContraForce surfaces software vulnerabilities, misconfigurations, and missing patches across your managed endpoints on an ongoing basis. Findings are prioritized by exploitability so you're focused on what actually matters. Remediation is tracked over time, which gives you the patch cadence documentation carriers ask about. *** ## Identity Monitoring: Watching the Front Door MFA enforcement is configured in Microsoft Entra ID, but ContraForce adds the monitoring layer on top. Through Sentinel and Defender for Identity, the platform detects suspicious sign-in patterns, brute force attempts, impossible travel events, and MFA bypass techniques. If an identity-based threat is detected, ContraForce can trigger automated responses (password resets, account disablement) before an attacker can move laterally. *** ## Certifications That Back It Up Some carriers ask about the certifications of your security providers. ContraForce is **SOC 2 Type II** certified, was named **Microsoft Security ISV of the Year 2024**, and is listed on the **Azure Marketplace** as an IP co-sell eligible, MACC-decrementable solution. These aren't just badges. They're independently verified proof that the platform meets enterprise-grade security and operational standards. *** ## Cheat Sheet: Application Questions and ContraForce | **They Ask** | **You Answer** | | ------------------------------- | ----------------------------------------------------------------------------- | | 24/7 SOC or managed monitoring? | ContraForce AI-powered MXDR, continuous and automated with escalation paths | | EDR/XDR on all endpoints? | Managed Microsoft Defender for Endpoint with coverage reporting | | SIEM in place? | Microsoft Sentinel deployed in your Azure tenant | | Incident response plan? | Built into the platform with structured workflows and automatic documentation | | Vulnerability scanning? | Continuous via Microsoft Defender Vulnerability Management | | MFA monitoring? | Identity threat detection through Sentinel + Defender for Identity | | Email security? | Managed Microsoft Defender for Office 365 | | Provider certifications? | SOC 2 Type II · Microsoft Security ISV of the Year 2024 | *** ## A Few Tips When Filling Out Applications **Be specific.** Generic answers like "yes, we have EDR" leave money on the table. Describe the product, who manages it, and what happens when a threat is detected. The more context you give, the better your quote. **Use the appendix.** If the form doesn't give you enough space, attach additional documentation. Dashboards, incident reports, and coverage summaries all strengthen your application. **Be honest.** Misrepresenting your controls doesn't just risk a denied application. It can void your coverage when you need it most. **Start early.** Most carriers need 60 to 90 days when controls need to be implemented. ContraForce deploys in about an hour into your existing Azure tenant, which compresses that timeline significantly. *** ## Bottom Line ContraForce covers the technical controls that show up on virtually every cyber insurance application (SOC, SIEM, EDR, incident response, vulnerability management, identity monitoring) through a single platform built on the Microsoft security stack. If you need help mapping ContraForce to a specific carrier's form, reach out to our team. We've been through the process and we're happy to help you get it right. *** *ContraForce is SOC 2 Type II certified, Microsoft Security ISV of the Year 2024, and available on the Azure Marketplace.* # ContraForce Success Teams Channel Source: https://docs.contraforce.com/guides/general-support/contraforce-success-teams-channel ## Setting Up a Shared Teams Channel with ContraForce Support This guide walks you through configuring your Microsoft 365 tenant to enable a shared Teams channel with the ContraForce Success Team. Using shared channels allows direct collaboration without guest accounts or switching tenants. ## Overview Microsoft Teams shared channels use B2B direct connect, which enables seamless collaboration between organizations. Once configured, you can participate in a shared channel directly within your own Teams environment. ## Prerequisites * Cloud App Admin, Application Admin, Global Admin, or External Identity Provider Administrator role in Microsoft Entra * Microsoft 365 subscription with Teams enabled * Access to the Microsoft Entra admin center ## Configuration Steps ### Step 1: Access Cross-Tenant Settings 1. Navigate to the [Microsoft Entra admin center](https://entra.microsoft.com) 2. Go to **External Identities** → **Cross-tenant access settings** Direct link: `https://entra.microsoft.com/#view/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/~/CrossTenantAccessSettings` ### Step 2: Add ContraForce as a Partner Organization 1. Click **Add organization** 2. Enter the domain: `contraforce.com` 3. Click **Add** ### Step 3: Configure Outbound Access 1. Locate **contraforce.com** in your list of organizations 2. Click **Inherited from default** in the **Outbound access** column 3. Select the **B2B direct connect** tab 4. Configure the following settings: | Setting | Recommended Value | Notes | | ------------------------- | ----------------- | --------------------------------------------------------------------------------- | | **Users and groups** | Allow access | Select "Select users and groups" if you need to limit which users can collaborate | | **External applications** | Allow access | Enables access to Teams shared channels | 5. Click **Save** ### Step 4: Wait for Propagation Cross-tenant access changes can take up to 24 hours to fully propagate across Microsoft's systems. If the shared channel doesn't appear immediately, check again the following day. ## Accepting the Shared Channel Invitation Once your tenant is configured and ContraForce sends a shared channel invitation: 1. Open Microsoft Teams 2. Look for a notification about the shared channel invitation 3. Accept the invitation 4. The shared channel will appear in your Teams sidebar ## Troubleshooting ### Shared channel not appearing * Verify B2B direct connect settings are saved correctly * Confirm the changes have had time to propagate (up to 24 hours) * Ensure the user accepting the invitation is included in the allowed users/groups ### Access denied errors * Check that **Outbound access** is configured (not just Inbound) * Verify **External applications** is set to **Allow access** ## Additional Resources * [Microsoft: Collaborate with external participants in a shared channel](https://learn.microsoft.com/en-us/microsoft-365/solutions/collaborate-teams-direct-connect) * [Microsoft: Allow B2B direct connect with all organizations](https://learn.microsoft.com/en-us/microsoft-365/solutions/allow-direct-connect-with-all-organizations) ## Need Help? If you encounter issues during setup, contact ContraForce Support and include: * Screenshot of your Cross-tenant access settings for contraforce.com * Any error messages you're receiving * The email address of the user attempting to join the shared channel Need help? Contact the ContraForce Support team at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Support SLA Definitions Source: https://docs.contraforce.com/guides/general-support/contraforce-support-sla-definitions Below are Support SLAs definitions for ticket requests submitted to the ContraForce Support Team. Tickets can be submitted to [support@contraforce.com](mailto:support@contraforce.com) or through a form found [here](https://share.hsforms.com/12AusdcHkRFiW1eB28pmXYg4nupn). If you would like to discuss the SLAs listed below, feel free to contact us! Below is an overview of available categories for ticket submissions as well as options for ticket priority. ## Ticket Categories: * **General Support** * Issues or questions about overall ContraForce features or use of the platform. * **Technical** * Technical issues or questions about specific ContraForce features or requirements. * **Report a bug** * Issues related to errors or bugs found within the ContraForce platform. * **Suggest a new feature** * Ideas for a new feature within ContraForce or design enhancements. ## Ticket Priority: * **Low** * User experience is hindered, but no functionality is broken. * **Medium** * Functionality is broken, but the impact is minor. Examples could be UI related or errors. * **High** * Critical features are broken, but workarounds are available. * **Urgent** * Critical features are broken, and no workaround is available. ## SLA Definitions: Time to first reply A response is considered overdue if it exceeds the time period outlined per ticket severity. * **Low** * Response Turnaround: 8 Hours * Overdue: 24 Hours * **Medium** * Response Turnaround: 4 Hours * Overdue: 8 Hours * **High** * Response Turnaround: 1 Hours * Overdue: 8 Hours * **Urgent** * Response Turnaround: 1 Hour * Overdue: 1 Hour ## SLA Definitions: Time to close * **Low** * Response turnaround: 24 Hours * Overdue: 72 Hours * **Medium** * Response turnaround: 12 Hours * Overdue: 36 Hours * **High** * Response turnaround: 4 Hours * Overdue: 12 Hours * **Urgent** * Response Turnaround: 1 Hour * Overdue: 4 Hours ## Customer Portal Tickets submitted by anyone in your organization are visible inside the Customer Portal. Before viewing tickets, you will be asked to register. The Customer Portal can be found [here](https://docs.contraforce.com/tickets-view). New tickets can also be submitted from the Customer Portal. # ContraForce User Management Source: https://docs.contraforce.com/guides/general-support/contraforce-user-management Users can be added to the ContraForce Portal. Additionally, ContraForce has built in user roles to further control access. ## Managing Users Adding users is not part of workspace onboarding — you manage your team at any time after your modules are deployed. User and group management is handled directly in the ContraForce portal — no separate enterprise application consent is required. Group-to-workspace mapping is managed entirely within the portal. Add new users from the **Settings → User Management** tab. If your user has the correct permissions, the **Add User** button is available on the top right of the page next to the **Search** bar. Settings, User Management tab with the Add User button Click **Add User** to open the **Invite people to the organization** dialog. Use **Search team members** to find an existing team member by name (or add a new one), then click **Add User**. Each user is assigned a role that controls their access. A table showing the different capabilities of each role is shown below, and additional information about ContraForce roles can be found in the [Roles & Permissions reference](/guides/general-support/roles-and-permissions-reference). Invite people to the organization dialog | User Type | View Incident Data | Manage Users | Run Gamebooks | Manage Data Connectors | Manage Endpoints | | ---------------------- | ------------------ | ------------ | ------------- | ---------------------- | ---------------- | | **Admin** | x | x | x | x | x | | **Incident Analyst** | x | | | | | | **Incident Responder** | x | | x | | x | | **Data Source Admin** | x | | | x | | If you have questions about the user management process in ContraForce, please contact us at [support@contraforce.com](mailto:support@contraforce.com). # Offboarding Procedure Source: https://docs.contraforce.com/guides/general-support/offboarding-contra-force Complete guide to removing ContraForce resources from your Microsoft Entra directory and Azure subscription. This guide covers the steps required to fully offboard ContraForce from your environment. Follow these procedures to remove all ContraForce enterprise applications, Azure resources, and role assignments. Offboarding removes all ContraForce functionality from your environment. Ensure you have exported any data you need before proceeding. This action cannot be undone without re-onboarding. ## Offboarding Overview During onboarding, ContraForce deploys resources to your environment. Complete offboarding requires removing: ContraForce service principals in Microsoft Entra ID Resource groups, Logic Apps, and API connections RBAC permissions granted to ContraForce AI agent resource groups (if deployed) *** ## Before You Begin ### Prerequisites Ensure you have **Cloud App Admin**, **Application Admin**, or **Global Admin** access to Microsoft Entra ID Ensure you have **Owner** or **Contributor** access to the Azure subscription Note which ContraForce modules and features are currently deployed Export any incident data, reports, or configurations you need to retain ### What Was Deployed? The resources you need to remove depend on your deployment: | Deployment Type | Resources to Remove | | ------------------------ | --------------------------------------------------------------- | | **Defender Module Only** | Enterprise applications only | | **XDR + SIEM Module** | Enterprise applications + Apollo resources + Sentinel resources | | **With AI Agents** | All above + Agent Center resource groups | *** ## Step 1: Remove Enterprise Applications Enterprise applications consented during onboarding must be removed from Microsoft Entra ID. ### Accessing Enterprise Applications Go to [entra.microsoft.com](https://entra.microsoft.com) Navigate to **Identity** > **Applications** > **Enterprise applications** Use the search box to find "ContraForce" Go to [portal.azure.com](https://portal.azure.com) Click **Microsoft Entra ID** in the left navigation Click **Enterprise applications** under Manage Use the search box to find "ContraForce" ### Applications to Remove Remove the following enterprise applications: | Application Name | Application ID | | -------------------------------------- | -------------------------------------- | | **ContraForce API** | `24d97bc0-8f2b-45d5-8e0b-7fe286732ef2` | | **ContraForce Portal** | `8b7cb435-9526-47ee-b79a-34433f0daad2` | | **ContraForce Sentinel Hunting** | `6bf1c74d-7ade-4671-a507-166936f89a1f` | | **ContraForce for MDE** | `6efccc6a-f0d3-49e5-92d0-17d4afa9ba52` | | **ContraForce Gamebooks for MDE** | `ad7b0e79-3c37-4408-bf8f-eb89522cc920` | | **ContraForce Gamebooks for Identity** | `36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a` | | **ContraForce Gamebooks for Email** | `44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d` | ### Deleting an Enterprise Application For each application in the list above: Click on the application name in the list Click **Properties** in the left navigation Click **Delete** at the top of the page Confirm when prompted Not all applications may be present—only delete applications that exist in your directory. The applications present depend on which modules and features were enabled during onboarding. *** ## Step 2: Remove Azure Resources (Sentinel Deployments) If you deployed the **XDR + SIEM module** with Microsoft Sentinel, remove the following Azure resources. Skip this step if you only deployed the Defender module without Sentinel integration. ### Remove Apollo Resource Group The Apollo resource group contains the infrastructure for real-time incident notifications. Go to [portal.azure.com](https://portal.azure.com) Click **Resource groups** in the left navigation Search for `rg-contraforce-apollo` Click the resource group, then click **Delete resource group** Type the resource group name to confirm, then click **Delete** #### Resources in Apollo Resource Group The following resources are removed when you delete this resource group: | Resource Type | Name | | ----------------------- | --------------------- | | Log Analytics Workspace | contraforce-apollo-\* | | Application Insights | contraforce-apollo-\* | | Function App | contraforce-apollo-\* | | App Service Plan | contraforce-apollo-\* | | Storage Account | contraforceapollo\* | ### Remove Sentinel Workspace Resources Resources were also deployed to the resource group containing your Microsoft Sentinel workspace. Find the resource group containing your Sentinel workspace Find and delete: `microsoftsentinel-Publish-Incident-To-Apollo` Find and delete: `Publish-Incident-To-Apollo` In Sentinel, go to **Automation** and delete: `Run-Playbook-Publish-Incident-To-Apollo` #### Deleting Individual Resources For each resource: Click on the resource name Click **Delete** in the toolbar Confirm deletion when prompted *** ## Step 3: Remove Role Assignments ContraForce was granted RBAC permissions on your Azure resources. These should be removed. ### Finding Role Assignments Go to the resource group containing your Sentinel workspace Click **Access control (IAM)** in the left navigation Click the **Role assignments** tab Search for "ContraForce" in the list ### Role Assignments to Remove | Service Principal | Role | Scope | | ------------------- | -------------------- | ----------------------- | | **ContraForce API** | Sentinel Contributor | Sentinel resource group | | **ContraForce API** | Reader | Sentinel resource group | ### Removing a Role Assignment Check the box next to the role assignment Click **Remove** in the toolbar Click **Yes** to confirm removal You can also use Azure CLI to remove role assignments: ```bash theme={null} az role assignment delete --assignee "24d97bc0-8f2b-45d5-8e0b-7fe286732ef2" --resource-group "your-sentinel-rg" ``` *** ## Step 4: Remove Agent Resource Groups (If Applicable) If you deployed ContraForce AI Agents, additional resource groups must be removed. Skip this step if you did not deploy AI Agents. Most deployments do not include agents. ### Agent Center Resource Group Search for resource group: `cf-rg-agent-center` Click **Delete resource group** Type the name and confirm deletion #### Resources in Agent Center | Resource Type | Description | | -------------------------- | ------------------ | | AI Foundry | AI model hosting | | CosmosDB | Agent data storage | | Container Apps Environment | Agent runtime | | Virtual Network | Network isolation | | Key Vaults | Secret management | | Storage Accounts | Agent file storage | ### Per-Agent Resource Groups Each deployed agent has its own resource group: Search for resource groups matching: `cf-rg-agent-*` Delete each agent resource group individually Confirm each deletion when prompted *** ## Step 5: Remove Azure Lighthouse Delegation (If Applicable) If Azure Lighthouse was configured for cross-tenant management, remove the delegation. In Azure Portal, search for **Service providers** Click **Service provider offers** to see active delegations Locate the ContraForce delegation Click the delegation, then click **Delete** *** ## Offboarding Checklist Use this checklist to ensure complete removal: ### Enterprise Applications * [ ] ContraForce API removed * [ ] ContraForce Portal removed * [ ] ContraForce Sentinel Hunting removed * [ ] ContraForce for MDE removed * [ ] ContraForce Gamebooks for MDE removed * [ ] ContraForce Gamebooks for Identity removed * [ ] ContraForce Gamebooks for Email removed ### Azure Resources (Sentinel Deployments) * [ ] `rg-contraforce-apollo` resource group deleted * [ ] `microsoftsentinel-Publish-Incident-To-Apollo` API connection deleted * [ ] `Publish-Incident-To-Apollo` Logic App deleted * [ ] `Run-Playbook-Publish-Incident-To-Apollo` Automation Rule deleted * [ ] ContraForce API role assignments removed ### Agent Resources (If Applicable) * [ ] `cf-rg-agent-center` resource group deleted * [ ] All `cf-rg-agent-*` resource groups deleted ### Azure Lighthouse (If Applicable) * [ ] ContraForce delegation removed *** ## Verifying Complete Removal After completing the offboarding steps, verify removal: ### Check Enterprise Applications In Entra ID, search Enterprise applications for "ContraForce" Confirm no ContraForce applications appear ### Check Azure Resources In Azure Portal, use the global search for "contraforce" Confirm no ContraForce resources appear ### Check Role Assignments Check Access Control (IAM) on your Sentinel resource group Confirm no ContraForce service principals have assignments *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ------------------------------------ | -------------------------- | ------------------------------------------------------------------------ | | **Can't delete enterprise app** | Insufficient permissions | Ensure you have Cloud App Admin, Application Admin, or Global Admin role | | **Resource group won't delete** | Resources have locks | Remove resource locks before deleting | | **Role assignment won't remove** | Permission denied | Ensure you have Owner access to the subscription | | **Can't find Apollo resource group** | Different naming | Search for "contraforce" in all resource groups | | **Logic App deletion fails** | Automation rule dependency | Delete the automation rule first | ### Resource Locks If you encounter "Cannot delete due to resource locks": Open the resource group in Azure Portal Click **Locks** in the left navigation Delete any locks on the resource group Attempt to delete the resource group again *** ## Re-Onboarding After Offboarding If you need to reconnect ContraForce in the future: 1. Contact the ContraForce team for a new workspace invite link 2. Follow the standard onboarding process from the **Workspace Center** 3. All resources will be recreated 4. Historical data from before offboarding will not be available Offboarding is permanent. If you think you may reconnect in the future, consider disabling functionality instead of fully removing it. Contact [support@contraforce.com](mailto:support@contraforce.com) to discuss options. *** ## Getting Help If you encounter issues during offboarding: [support@contraforce.com](mailto:support@contraforce.com) Open a support ticket *** ## Related Guides Overview of all service principals Complete resource documentation Re-onboarding the Defender module Re-onboarding the SIEM module *** Questions about offboarding? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # User Roles & Permissions Source: https://docs.contraforce.com/guides/general-support/roles-and-permissions-reference Complete reference for all ContraForce roles including organization-level and workspace-level permissions, use cases, and assignment best practices. This reference provides complete details on all ContraForce roles, their permissions, and guidance on when to use each role. ContraForce uses a two-tier role system: **Organization Roles** control platform-wide access, while **Workspace Roles** control what users can do within specific customer workspaces. *** ## Role System Overview ContraForce roles operate at two levels: Control who can access the platform and manage organization-wide settings. Assigned in **Settings → User Management**. Control what actions users can perform within a specific customer workspace. Assigned per-workspace in **Workspace Settings**. ### How Roles Work Together A user needs **both** an organization role AND a workspace role to work effectively: ``` Organization Role → Grants platform access + Workspace Role → Grants workspace-specific permissions = Complete user access ``` A user with an organization role but no workspace role can log in but won't see any customer data. A user must be assigned to at least one workspace with a workspace role to be useful. *** ## Organization Roles Organization roles are assigned at the partner/organization level and determine platform-wide capabilities. ### Organization Roles Summary | Role | Description | Typical Users | | ----------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------ | | **Organization Admin** | Full platform control including billing, settings, and user management | Business owners, IT directors, platform administrators | | **Organization Member** | Standard platform access, can be assigned to workspaces | SOC analysts, engineers, account managers | ### Organization Admin Full administrative control over the ContraForce platform. | Capability | Access | | ------------------------------------------- | ------ | | View organization dashboard | ✓ | | Manage organization settings | ✓ | | Create and delete workspaces | ✓ | | Add and remove organization users | ✓ | | Create and manage organization groups | ✓ | | Assign users to workspaces | ✓ | | View billing and usage | ✓ | | Manage API keys | ✓ | | Configure SSO/authentication | ✓ | | Access all workspaces (with workspace role) | ✓ | * Platform administrators responsible for ContraForce setup * Business owners who need full visibility * IT directors managing the security operations team * Personnel responsible for billing and licensing * Limit to 2-3 trusted individuals * Ensure at least two Organization Admins for continuity * Document who has this role and why * Review quarterly for appropriateness ### Organization Member Standard platform access for team members who work within workspaces. | Capability | Access | | ------------------------------------------------ | ------ | | View organization dashboard | ✓ | | Manage organization settings | — | | Create and delete workspaces | — | | Add and remove organization users | — | | Create and manage organization groups | — | | Assign users to workspaces | — | | View billing and usage | — | | Manage API keys | — | | Configure SSO/authentication | — | | Access assigned workspaces (with workspace role) | ✓ | * SOC analysts handling daily incident triage * Security engineers managing integrations * Account managers reviewing customer status * Any team member who doesn't need admin capabilities * Default role for most team members * Combine with appropriate workspace roles * Add to organization groups for easier workspace assignment *** ## Workspace Roles Workspace roles control what a user can do within a specific customer workspace. Users can have different roles in different workspaces. ### Workspace Roles Summary | Role | View Incidents | Respond to Incidents | Manage Gamebooks | Configure Modules | Manage Users | | ---------------------- | :------------: | :------------------: | :--------------: | :---------------: | :----------: | | **Admin** | ✓ | ✓ | ✓ | ✓ | ✓ | | **Incident Responder** | ✓ | ✓ | ✓ | — | — | | **Incident Analyst** | ✓ | — | — | — | — | | **Data Source Admin** | ✓ | — | — | ✓ | — | | **Content Admin** | ✓ | — | — | CMS Only | — | *** ### Admin Full control over a workspace including user management and configuration. **Incident Management** | Capability | Access | | ---------------------------------- | ------ | | View incidents | ✓ | | View incident details and entities | ✓ | | Update incident status | ✓ | | Update incident severity | ✓ | | Assign incidents | ✓ | | Add comments | ✓ | | Close incidents | ✓ | | Delete incidents | ✓ | **Response Actions** | Capability | Access | | ------------------------ | ------ | | Run Gamebooks | ✓ | | Create custom Gamebooks | ✓ | | Execute response actions | ✓ | | Isolate endpoints | ✓ | | Disable user accounts | ✓ | | Block IPs/URLs | ✓ | **Configuration** | Capability | Access | | ----------------------- | ------ | | Configure modules | ✓ | | Manage data connectors | ✓ | | Configure notifications | ✓ | | Manage CMS rules | ✓ | | Deploy detection rules | ✓ | **Administration** | Capability | Access | | --------------------------- | ------ | | Add users to workspace | ✓ | | Remove users from workspace | ✓ | | Assign workspace roles | ✓ | | Add groups to workspace | ✓ | | View workspace settings | ✓ | | Modify workspace settings | ✓ | * SOC managers overseeing a specific customer * Lead analysts with full responsibility for a workspace * Customer success managers who need to configure workspaces * Technical account managers during onboarding * Assign to SOC managers and team leads * Limit to personnel who need user management capabilities * Consider using Incident Responder instead if user management isn't needed * Appropriate for your most senior analysts on premium customers *** ### Incident Responder Can investigate incidents and execute response actions, but cannot configure the workspace. **Incident Management** | Capability | Access | | ---------------------------------- | ------ | | View incidents | ✓ | | View incident details and entities | ✓ | | Update incident status | ✓ | | Update incident severity | ✓ | | Assign incidents | ✓ | | Add comments | ✓ | | Close incidents | ✓ | | Delete incidents | — | **Response Actions** | Capability | Access | | ------------------------ | ------ | | Run Gamebooks | ✓ | | Create custom Gamebooks | ✓ | | Execute response actions | ✓ | | Isolate endpoints | ✓ | | Disable user accounts | ✓ | | Block IPs/URLs | ✓ | **Configuration** | Capability | Access | | ----------------------- | ------ | | Configure modules | — | | Manage data connectors | — | | Configure notifications | — | | Manage CMS rules | — | | Deploy detection rules | — | **Administration** | Capability | Access | | --------------------------- | ------- | | Add users to workspace | — | | Remove users from workspace | — | | Assign workspace roles | — | | Add groups to workspace | — | | View workspace settings | Limited | | Modify workspace settings | — | * Tier 2 SOC analysts who handle escalations * Senior analysts who need to take response actions * Incident handlers during active investigations * On-call personnel who may need to respond after hours * Default role for experienced SOC analysts * Appropriate for personnel who need response capabilities * Use for Tier 2 and above analysts * Consider for on-call rotation members *** ### Incident Analyst Read-only access to incidents for monitoring and analysis without response capabilities. **Incident Management** | Capability | Access | | ---------------------------------- | ------ | | View incidents | ✓ | | View incident details and entities | ✓ | | Update incident status | — | | Update incident severity | — | | Assign incidents | — | | Add comments | ✓ | | Close incidents | — | | Delete incidents | — | **Response Actions** | Capability | Access | | ------------------------ | ------ | | Run Gamebooks | — | | Create custom Gamebooks | — | | Execute response actions | — | | Isolate endpoints | — | | Disable user accounts | — | | Block IPs/URLs | — | **Configuration** | Capability | Access | | ----------------------- | ------ | | Configure modules | — | | Manage data connectors | — | | Configure notifications | — | | Manage CMS rules | — | | Deploy detection rules | — | **Administration** | Capability | Access | | --------------------------- | ------ | | Add users to workspace | — | | Remove users from workspace | — | | Assign workspace roles | — | | Add groups to workspace | — | | View workspace settings | — | | Modify workspace settings | — | * Tier 1 SOC analysts who triage and escalate * Customer stakeholders who want visibility into their incidents * Compliance officers reviewing security events * Account managers monitoring customer status * Junior analysts in training * Use for Tier 1 analysts who escalate rather than respond * Appropriate for customer users who need read-only access * Good for personnel in training before promoting to Responder * Use for account managers who need visibility without action capability *** ### Data Source Admin Can configure modules and data connectors but cannot respond to incidents. **Incident Management** | Capability | Access | | ---------------------------------- | ------ | | View incidents | ✓ | | View incident details and entities | ✓ | | Update incident status | — | | Update incident severity | — | | Assign incidents | — | | Add comments | ✓ | | Close incidents | — | | Delete incidents | — | **Response Actions** | Capability | Access | | ------------------------ | ------ | | Run Gamebooks | — | | Create custom Gamebooks | — | | Execute response actions | — | | Isolate endpoints | — | | Disable user accounts | — | | Block IPs/URLs | — | **Configuration** | Capability | Access | | ----------------------- | ------ | | Configure modules | ✓ | | Manage data connectors | ✓ | | Configure notifications | ✓ | | Manage CMS rules | — | | Deploy detection rules | — | **Administration** | Capability | Access | | --------------------------- | ------- | | Add users to workspace | — | | Remove users from workspace | — | | Assign workspace roles | — | | Add groups to workspace | — | | View workspace settings | ✓ | | Modify workspace settings | Limited | * Integration engineers setting up data connectors * Technical onboarding specialists * Engineers troubleshooting data flow issues * Personnel responsible for module configuration * Use for technical staff who configure but don't respond * Appropriate for onboarding and integration work * Good for separation of duties (config vs. response) * Consider for customer IT admins managing their own connectors *** ### Content Admin Can manage CMS detection rules but cannot configure other modules or respond to incidents. **Incident Management** | Capability | Access | | ---------------------------------- | ------ | | View incidents | ✓ | | View incident details and entities | ✓ | | Update incident status | — | | Update incident severity | — | | Assign incidents | — | | Add comments | ✓ | | Close incidents | — | | Delete incidents | — | **Response Actions** | Capability | Access | | ------------------------ | ------ | | Run Gamebooks | — | | Create custom Gamebooks | — | | Execute response actions | — | | Isolate endpoints | — | | Disable user accounts | — | | Block IPs/URLs | — | **Configuration** | Capability | Access | | ----------------------- | ------ | | Configure modules | — | | Manage data connectors | — | | Configure notifications | — | | Manage CMS rules | ✓ | | Deploy detection rules | ✓ | | Enable/disable rules | ✓ | | Configure auto-updates | ✓ | **Administration** | Capability | Access | | --------------------------- | ------- | | Add users to workspace | — | | Remove users from workspace | — | | Assign workspace roles | — | | Add groups to workspace | — | | View workspace settings | Limited | | Modify workspace settings | — | * Detection engineers managing rule deployments * Security engineers tuning detection coverage * Personnel responsible for Sentinel rule management * Content specialists focused on detection quality * Use for personnel focused specifically on detection rules * Good for separation of duties (detection vs. response) * Appropriate for detection engineering teams * Consider pairing with Incident Analyst for visibility *** ## Role Comparison Matrix ### By Functional Area | Capability | Admin | Responder | Analyst | Data Source | Content | | --------------------- | :---: | :-------: | :-----: | :---------: | :-----: | | View incidents | ✓ | ✓ | ✓ | ✓ | ✓ | | View details/entities | ✓ | ✓ | ✓ | ✓ | ✓ | | Update status | ✓ | ✓ | — | — | — | | Update severity | ✓ | ✓ | — | — | — | | Assign incidents | ✓ | ✓ | — | — | — | | Add comments | ✓ | ✓ | ✓ | ✓ | ✓ | | Close incidents | ✓ | ✓ | — | — | — | | Delete incidents | ✓ | — | — | — | — | | Capability | Admin | Responder | Analyst | Data Source | Content | | ----------------- | :---: | :-------: | :-----: | :---------: | :-----: | | Run Gamebooks | ✓ | ✓ | — | — | — | | Create Gamebooks | ✓ | ✓ | — | — | — | | Isolate endpoints | ✓ | ✓ | — | — | — | | Disable users | ✓ | ✓ | — | — | — | | Block IPs/URLs | ✓ | ✓ | — | — | — | | Quarantine files | ✓ | ✓ | — | — | — | | Reset passwords | ✓ | ✓ | — | — | — | | Capability | Admin | Responder | Analyst | Data Source | Content | | ----------------------- | :---: | :-------: | :-----: | :---------: | :-----: | | Configure modules | ✓ | — | — | ✓ | — | | Manage connectors | ✓ | — | — | ✓ | — | | Configure notifications | ✓ | — | — | ✓ | — | | Manage CMS rules | ✓ | — | — | — | ✓ | | Deploy detection rules | ✓ | — | — | — | ✓ | | Capability | Admin | Responder | Analyst | Data Source | Content | | ---------------------- | :---: | :-------: | :-----: | :---------: | :-----: | | Add workspace users | ✓ | — | — | — | — | | Remove workspace users | ✓ | — | — | — | — | | Assign roles | ✓ | — | — | — | — | | Add groups | ✓ | — | — | — | — | | View settings | ✓ | Limited | — | ✓ | Limited | | Modify settings | ✓ | — | — | Limited | — | *** ## Common Role Assignments ### By Team Structure | Team Member | Org Role | Typical Workspace Role | | -------------------- | ------------------- | ---------------------- | | SOC Manager | Organization Admin | Admin | | Tier 2 Analyst | Organization Member | Incident Responder | | Tier 1 Analyst | Organization Member | Incident Analyst | | Detection Engineer | Organization Member | Content Admin | | Integration Engineer | Organization Member | Data Source Admin | | Account Manager | Organization Member | Incident Analyst | | Customer CISO | — (workspace only) | Incident Analyst | | Customer IT Admin | — (workspace only) | Data Source Admin | ### By Customer SLA | SLA Tier | Recommended Team Roles | | ------------ | ------------------------------------------------------- | | **Premium** | Admin (manager) + Incident Responder (analysts) | | **Standard** | Incident Responder (lead) + Incident Analyst (analysts) | | **Basic** | Incident Analyst (monitoring only) | *** ## Best Practices Assign the minimum role needed for each user's responsibilities. Start with Incident Analyst and promote to Responder only when response capabilities are needed. Create organization groups like "SOC Tier 1" and "SOC Tier 2" with predetermined workspace roles. This ensures consistency across all customer workspaces. Consider separating Data Source Admin and Content Admin roles from incident response roles. This provides better audit trails and separation of duties. Reserve the Admin role for personnel who genuinely need user management capabilities. Most analysts should be Incident Responders or Incident Analysts. Maintain a record of who has what role and why. Review quarterly to ensure assignments are still appropriate. A user can have different roles in different workspaces. A senior analyst might be Admin for a premium customer but Incident Responder for standard customers. *** ## Frequently Asked Questions No, each user has one role per workspace. However, they can have different roles in different workspaces. If a user needs capabilities from multiple roles, assign the higher-privilege role. Admin can manage users and modify workspace settings. Incident Responder has the same operational capabilities (investigating, responding) but cannot add/remove users or change configuration. Generally no. Customer users should only be added at the workspace level (not organization level) to ensure they can only see their own data. Custom roles are not currently supported. Use the predefined roles that best match your needs. Contact support if you have specific requirements not met by existing roles. Go to the workspace settings, find the user in Users & Groups, edit their assignment, and change their role from Incident Analyst to Incident Responder. Incident Analyst is typically appropriate for customer stakeholders who need visibility into their security posture without the ability to take response actions. *** ## Related Guides Setting up users and groups for partners Managing customer workspaces Automated response actions (requires Responder role) Detection rule management (requires Content Admin role) *** Questions about roles and permissions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Service Accounts Source: https://docs.contraforce.com/guides/general-support/service-accounts Create and manage non-human identities for programmatic access to the ContraForce v2 API, with per-credential API scopes and cross-workspace authorization. Service accounts are non-human identities that your applications, scripts, and integrations use to call the ContraForce v2 API. Each service account authenticates with a Client ID and Client Secret, and every credential carries its own set of granular API scopes that determine exactly what it can do across the organization. **Who is this for?** Organization Admins and security engineers who need to connect external tools, SIEM pipelines, ticketing systems, or custom automations to ContraForce without using a human user account. ## Prerequisites * **Organization Admin** role, or the `org:service-accounts:manage` API scope on an existing credential * A clear understanding of the API scopes the integration needs — start with the minimum and expand as required Service accounts can only call the **v2 API** (`https://portal.contraforce.com/api/v2/...`). Requests to the v1 API are rejected with `403 Forbidden`. ## How Authorization Works Authorization for service accounts is driven by **API scopes on each credential**. Scopes are the single source of truth for what a credential is allowed to do. * **Scopes decide *what*** — each scope (for example, `incidents:read`) authorizes a specific class of API action. * **Cross-workspace by default** — v2 endpoints that span workspaces (such as `POST /api/v2/incidents/across-workspaces`) run as scope-authorized calls and return data from every workspace the service account can see in one request. There is no need to target a single workspace per call. * **Multiple credentials per account** — a single service account can carry several credentials, each with a different scope set and expiration. This enables zero-downtime rotation and lets one integration hold read-only scopes while another carries write scopes. ## Where to Find Service Accounts Navigate to **Settings → Developer Integrations** in the ContraForce Portal. Service accounts appear in the **Integrations** table alongside webhooks, marked with a key icon and the type **Service Account**. ## Creating a Service Account In the Portal, go to **Settings → Developer Integrations** and click **Add Integration → Service Account**. Provide a **Name** (up to 200 characters) and an optional **Description** (up to 1000 characters). Use a name that identifies the calling system — for example, `SIEM-ingest-prod` or `Ticketing-bridge`. Pick the scopes the first credential should carry. Scopes follow the `{resource}:{action}` pattern and are grouped into **Workspace Scopes** (operate on workspace-owned resources such as incidents and Gamebooks) and **Organization Scopes** (operate on org-level resources such as users and webhooks). Follow least-privilege. Grant only the scopes the integration actually calls. You can always issue a second credential with broader scopes later. Choose an expiration date if the credential should automatically stop working after a certain point. Leave blank for a credential that never expires. Click **Create**. ContraForce returns the **Client ID** and a **Client Secret**. The Client Secret is shown **once** and cannot be retrieved again. Copy it immediately into your secret store (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, etc.). If you lose it, revoke the credential and issue a new one. ## Authenticating to the v2 API Service accounts use **HTTP Basic authentication** (RFC 7617). Encode `ClientId:ClientSecret` in Base64 and send it in the `Authorization` header. ```bash theme={null} curl https://portal.contraforce.com/api/v2/incidents/across-workspaces \ -H "Authorization: Basic $(echo -n 'CLIENT_ID:CLIENT_SECRET' | base64)" \ -H "Content-Type: application/json" \ -d '{"isFirstCall": true}' ``` On success, ContraForce records usage metadata on the credential (`LastUsedAt`) and writes an entry to the service account's **Request Logs**. ### Authentication failures | Response | Likely cause | | ------------------ | ------------------------------------------------------------------------------------- | | `401 Unauthorized` | Invalid Client ID, invalid Client Secret, or malformed `Authorization` header | | `403 Forbidden` | Credential is revoked, expired, or the service account is disabled | | `403 Forbidden` | Request targets a v1 route (`/api/...` without `/v2/`) — service accounts are v2-only | | `403 Forbidden` | Authenticated but the credential is missing the scope the endpoint requires | ## API Scopes Reference Scopes are granted **per credential**. A service account can hold multiple credentials with different scope sets. ### Workspace scopes Authorize actions against workspace-owned resources. Cross-workspace endpoints use these scopes and automatically return only data from workspaces the service account is allowed to see. | Scope | Grants | | -------------------- | ------------------------------------------------------------- | | `incidents:read` | View incidents, entities, evidence, alert rules, and comments | | `incidents:write` | Assign incidents, update status, and perform bulk updates | | `incidents:comments` | Create, update, and delete incident comments | | `gamebooks:read` | View Gamebooks, Gamebook history, and incident Gamebooks | | `datasources:read` | View connected data sources | | `tickets:read` | Search service tickets | | `tickets:manage` | Link and unlink tickets to incidents | | `investigation:read` | View user sign-in logs and directory logs | ### Organization scopes Authorize actions on org-level resources. | Scope | Grants | | ----------------------------- | -------------------------------------------------------- | | `webhooks:read` | View webhook configurations and delivery logs | | `webhooks:manage` | Create, update, delete, pause, resume, and test webhooks | | `org:users:read` | View organization users and profiles | | `org:users:manage` | Add, update, and remove users | | `org:users:roles` | Assign and modify organizational roles | | `org:service-accounts:read` | View service accounts and credentials | | `org:service-accounts:manage` | Create, update, disable, and delete service accounts | Write scopes imply their matching read scope. Granting `incidents:write` automatically authorizes `incidents:read` on the same endpoint set. Every v2 endpoint grouped by scope with full route paths Copy-pasteable JSON request and response examples ## Managing the Service Account Open a service account's detail page from **Settings → Developer Integrations** to manage it. The page has three tabs: **General**, **Request Logs**, and **Audit**. ### General tab * **Disable** — Blocks all credentials on the service account from authenticating. Use this for a temporary freeze (for example, during an incident). * **Enable** — Re-activates a disabled service account. * **Delete** — Permanently removes the service account and all its credentials. Cannot be undone. * **Edit** — Update name and description. Deleting a service account breaks every integration using its credentials. Disable first and monitor **Request Logs** for any stragglers before deleting. ### Credential management Each credential shows its prefix (first 6 characters), status, expiration, scopes, last-used timestamp, and creation date. | Action | What it does | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | **New Credential** | Issues an additional credential with its own scopes and expiration. Use for rotation or to split read vs. write integrations. | | **Revoke** | Immediately invalidates a credential. Cannot be undone. | ### Request Logs tab Shows every API call made using any credential on the service account: timestamp, HTTP method, path, response status, latency, and source IP. Use this to audit integration behavior or troubleshoot `403` failures. ### Audit tab Shows lifecycle events — creation, updates, credential issuance, revocation, disable/enable, and deletion — attributed to the Portal user who performed each action. ## Rotating a Credential (Zero Downtime) Because a service account can hold multiple active credentials, you can rotate secrets without an outage. On the service account's **General** tab, click **New Credential**. Select the same scopes as the credential you're rotating and copy the new Client Secret immediately. Update your integration's secret store with the new Client Secret. Deploy the configuration change. Check **Request Logs** and confirm that requests are coming in. The new credential's **Last used** timestamp updates within seconds of the first authenticated call. Once all traffic has shifted, click **Revoke** on the old credential. Any residual caller using the old secret will receive `403 Forbidden`. ## How Service Accounts Work * **Identity** — Each service account is an organization member with `IsServiceAccount = true`. It is not visible in **Settings → User Management** and cannot sign in to the Portal. * **Client ID** — The stable GUID of the service account. Safe to share. * **Client Secret** — 32 cryptographically random bytes, Base64-encoded. Stored as a SHA-256 hash (for authentication lookups) and as AES-256-GCM ciphertext wrapped by an RSA key in Azure Key Vault (envelope encryption). The plaintext is shown only at creation. * **Authorization** — Every v2 endpoint declares a required scope. On each request, the authentication middleware resolves the credential, confirms it is active and unexpired, and projects its scopes onto the request principal. The endpoint's scope filter then allows or denies. Endpoints that span workspaces filter returned data to the set of workspaces the service account is entitled to see. * **Isolation** — Service accounts are deliberately restricted to the v2 API. The v2 design uses resource-based routing with per-request scope authorization, removing an authorization bypass that existed in v1. ## Best Practices * **One service account per integration.** Don't share credentials across systems — it fragments audit trails and breaks rotation. * **Split read and write.** Issue separate credentials for read-only monitoring and write automations on the same service account, so a leak of the monitoring secret can't mutate state. * **Minimum scopes.** Grant read-only scopes first. Add write scopes only when an integration actually needs to mutate state. * **Expiration everywhere.** Set a credential expiration for anything non-critical and renew on a schedule. * **Name for humans.** Future-you will grep the audit log. `Jira-incident-sync-prod` beats `sa-3`. * **Monitor the Request Logs.** A sudden drop in traffic usually means a rotation went wrong. A sudden spike may mean a runaway script. ## Troubleshooting | Symptom | Fix | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `401 Unauthorized` immediately after creation | Verify the `Authorization` header is `Basic ` with no whitespace | | `403 Forbidden` with "Service accounts must use the v2 API" | Change the URL to `/api/v2/...` | | `403 Forbidden` on a specific endpoint only | The credential is missing the required scope. Issue a new credential with the correct scope. | | `403 Forbidden` with "credential is not active" | The credential was revoked or expired. Issue a new credential. | | `403 Forbidden` with "service account is disabled or not found" | Re-enable the service account under **Settings → Developer Integrations** | | Cross-workspace endpoint returns an empty list | The service account has no visible workspaces, or no data matched the filters in visible workspaces. | | Credential works intermittently | Confirm no other integration is rotating the same credential. Use one credential per integration. | If you have questions about service accounts or need help planning an integration, contact us at [support@contraforce.com](mailto:support@contraforce.com). # User Management Source: https://docs.contraforce.com/guides/general-support/user-group-management Add users to ContraForce, assign roles, and control access permissions across your organization and workspaces. ContraForce provides flexible user management with role-based access control. Add users from your Entra ID directory, assign organizational and workspace roles, and control exactly what each team member can access. ## **Recommended Default Groups** Setting up default groups during initial configuration saves time and ensures consistent access patterns. **Suggested Partner Groups** | Group Name | Description | Suggested Workspace Role | | :-------------------- | :------------------------------------------ | :--------------------------- | | SOC Tier 1 | Front-line analysts handling initial triage | Incident Analyst | | SOC Tier 2 | Senior analysts with response capabilities | Incident Responder | | SOC Managers | Team leads overseeing operations | Admin | | Integration Engineers | Technical staff managing connectors | Data Source Admin | | Account Managers | Customer relationship managers | Incident Analyst (read-only) | ContraForce integrates with Microsoft Entra ID (formerly Azure AD) to pull user identities. Users must exist in Entra ID before they can be added to ContraForce. ## User Management Overview Control who can manage users, groups, and workspace settings across your organization Define what users can do within specific customer workspaces *** ## User Roles at a Glance ContraForce uses a two-tier role system: **Organizational Roles** control administrative access, while **Workspace Roles** control operational access. ### Workspace Roles Quick Reference | Role | View Incidents | Run Gamebooks | Manage Endpoints | Manage Data Connectors | Manage Users | | ---------------------- | :------------: | :-----------: | :--------------: | :--------------------: | :----------: | | **Admin** | ✓ | ✓ | ✓ | ✓ | ✓ | | **Incident Responder** | ✓ | ✓ | ✓ | — | — | | **Incident Analyst** | ✓ | — | — | — | — | | **Data Source Admin** | ✓ | — | — | ✓ | — | View detailed permissions for all organizational and workspace roles *** ## When to Add Users Adding users is **not** part of module onboarding. First, sign in at [portal.contraforce.com](https://portal.contraforce.com), grant the core ContraForce app consents, and deploy your modules. Once your organization is set up, add and manage users at any time from **Settings**. Add at least one Org Admin early. This ensures you always have full access to manage users, groups, and workspaces. *** ## Adding and Managing Users You add and manage users through the **Settings** page. User and group management is handled entirely within the ContraForce portal — no separate enterprise application consent is required. ### Step 1: Access User Management Click **Settings** in the navigation menu Click the **User Management** tab The user list displays all users with access to ContraForce Settings, User Management tab ### Step 2: Add New Users Click the **Add User** button in the top right corner Search for the user by name or email in the Entra ID directory Click the user to select them Choose organizational and workspace roles Click **Add** to complete the process Invite people to the organization dialog The **Add User** button only appears if your account has User Admin or Org Admin permissions. *** ## Understanding Role Types ### Organizational Roles Organizational roles control administrative functions across your entire ContraForce instance: | Role | Add/Manage Users | Add/Manage Groups | Add Workspaces | View All Workspaces | | ------------------- | :--------------: | :---------------: | :------------: | :-----------------: | | **Org Admin** | ✓ | ✓ | ✓ | ✓ | | **User Admin** | ✓ | ✓ | — | — | | **Workspace Admin** | — | — | ✓ | ✓ | | **Org Member** | — | — | — | — | ### Workspace Roles Workspace roles control what users can do within specific customer workspaces: **Full access to all workspace features** * View and manage all incidents * Run any Gamebook action * Manage endpoints and data connectors * Configure workspace settings * Manage workspace users *Best for: Team leads, senior analysts, workspace owners* **Operational access for active response** * View all incidents * Run Gamebook response actions * Manage endpoints (isolate, scan, etc.) * Cannot manage data connectors or users *Best for: SOC analysts who need to take action* **Read-only access for investigation** * View all incidents * Cannot run Gamebooks * Cannot manage endpoints * Cannot modify configurations *Best for: Junior analysts, read-only stakeholders* **Integration management focus** * View all incidents * Manage data connectors * Cannot run Gamebooks * Cannot manage endpoints *Best for: Integration specialists, IT administrators* *** ## User Groups Simplify access management by organizing users into groups. ### Benefits of Groups Assign workspace access to multiple users at once Update group membership instead of individual users Ensure team members have the same permissions ### Creating Groups Groups are managed on the **Group Management** tab under **Settings**. Settings, Group Management tab with the Add Group button Go to **Settings** > **Group Management** Click **Add Group** and enter a name Search for and add users to the group Assign the group to workspaces with appropriate roles *** ## Assigning Users to Workspaces Users need workspace assignments to access customer data. ### Individual Assignment 1. Open the workspace settings 2. Navigate to **Users** or **Access** 3. Click **Add User** 4. Select the user and assign a workspace role 5. Save changes ### Group Assignment 1. Open the workspace settings 2. Navigate to **Groups** or **Access** 3. Click **Add Group** 4. Select the group and assign a workspace role 5. All group members inherit access Use groups for teams that need access to the same set of workspaces. This makes onboarding new team members faster—just add them to the appropriate group. *** ## Managing Existing Users ### Viewing User Details Click any user in the User Management list to view: * Assigned organizational role * Workspace assignments and roles * Group memberships * Last login time ### Editing User Roles Click the user in the User Management list Modify organizational or workspace roles as needed Click **Save** to apply the new permissions ### Removing Users Click the user you want to remove Click the **Remove User** or **Delete** button Confirm the removal when prompted Removing a user revokes all their access to ContraForce immediately. This action cannot be undone—you'll need to re-add the user if you want to restore access. *** ## Best Practices Assign the minimum role necessary for each user's job function. Start with Incident Analyst and escalate to Responder or Admin only when needed. Create groups that mirror your team structure (e.g., "Tier 1 Analysts", "Senior Responders"). This simplifies access management as team members change. Review user assignments quarterly to ensure former team members have been removed and current roles are still appropriate. Maintain records of who has access to which workspaces and why. This helps with compliance audits and access reviews. Don't give everyone Admin access. Reserve Admin roles for users who genuinely need to manage configurations and other users. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ------------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------- | | **Can't see Add User button** | Missing User Admin or Org Admin role | Contact your administrator for elevated permissions | | **User not found in dropdown** | User doesn't exist in Entra ID | Verify user exists in Microsoft Entra ID | | **Consent flow fails** | Insufficient admin privileges | Admin consent for ContraForce enterprise applications requires a **Global Administrator** account | | **User can't access workspace** | No workspace assignment | Assign user directly or via group to the workspace | | **User has wrong permissions** | Incorrect role assignment | Edit user and assign correct workspace role | *** ## Related Guides Complete permissions for all roles Manage workspace settings Service principals and consent Managing multiple customers *** Questions about user management? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Command Dashboard Source: https://docs.contraforce.com/guides/getting-started/command-dashboard Your central hub for monitoring incidents, managing workspaces, and overseeing security operations across all your Microsoft tenants. The Command Dashboard is ContraForce's mission control center—a unified dashboard that gives you complete visibility into security incidents, gamebooks queued, and human and agent actions that are audited—across all your managed tenants. ContraForce Command ## Overview The Command Dashboard serves as your central hub for overseeing multiple Microsoft tenants through a single, intuitive dashboard. By default, it displays data for all onboarded tenants, with the option to customize your view by filtering specific workspaces. The Command Dashboard is designed for MSPs, MSSPs, and security teams managing tenants and environments. All data updates in real-time as incidents are detected and resolved. ## Dashboard Cards The Command Dashboard features four key data cards that provide at-a-glance insights into your security posture: Displays the number of incidents based on severity and total incidents closed across workspaces. Filter workspaces to see incidents per workspace. Shows closed incident trends based on classification as well as incident rule trends based on last detections triggered over time. See how your humans and agents are performing in one place. Track incidents managed by users based on incident severity level. View all queued gamebooks that are processing or awaiting for approval. Click any incident to review and approve gamebook runs. ## Incidents Table The Incidents table is the heart of the Command Dashboard, displaying all security incidents across your connected workspaces. ### Table Columns | Column | Description | | ------------------ | ---------------------------------------------------------- | | **Severity** | Incident severity level (High, Medium, Low, Informational) | | **Workspace** | The tenant/workspace where the incident occurred | | **Incident Title** | Brief description of the incident | | **Incident ID** | Unique identifier (click to view details) | | **Creation Time** | When the incident was first detected | | **Status** | Current state (New, Active, Closed) | | **Owner** | Analyst assigned to the incident | ### Filtering Options You can filter the incidents table by: * **Workspace** — Select specific workspaces to focus on * **Severity** — Filter by High, Medium, Low, or Informational * **Status** — Show only New, Active, or Closed incidents ### Incident Handling at Scale Rather than updating incidents manually in batches, **Security Delivery Agents** running **on queue** automatically triage and act on incidents as they arrive. See [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents). ## Workspace Filtering The workspace filter at the top of the Command Dashboard allows you to customize your view: 1. Click the **Workspace Filter** dropdown 2. Select one or more workspaces to display 3. Your selection persists as you navigate to other pages in ContraForce Your workspace filter selection is maintained across all ContraForce pages during your session. This allows you to focus on specific customers without re-selecting filters on each page. ## Accessing Incident Details To view detailed information about any incident: 1. Locate the incident in the Incidents table 2. Click the **Incident ID** (hyperlinked) 3. The Incident Details page opens with full investigation capabilities From the Incident Details page, you can: * View the complete incident timeline * See all affected entities * Run Gamebook response actions * Add comments and update status ## Next Steps A complete workflow for triaging, investigating, and resolving incidents. Manage workspace settings from one central location. Learn how to properly classify incidents to improve detection accuracy. Explore all multi-tenant management capabilities. *** Need help? Contact the ContraForce Support team at [support@contraforce.com](mailto:support@contraforce.com). # Configuring Security Delivery Agents Source: https://docs.contraforce.com/guides/getting-started/configuring-security-delivery-agents Configure and use Security Delivery Agents to automate incident investigation and response through a phased adoption approach. Security Delivery Agents (SDAs) automate incident investigation and response within ContraForce. This guide walks you through configuring agents using a phased approach, allowing you to gradually increase automation as you become comfortable with agent capabilities. Security Delivery Agents follow a three-phase adoption model: manual execution, automatic execution based on severity, and automatic gamebook execution. This progressive approach helps you build confidence in agent behavior before enabling full automation. ## What Can You Do Here? Trigger agent analysis on individual incidents Configure agents to run automatically based on incident status Allow agents to execute response playbooks automatically Control when automated actions are permitted Use Advanced mode to act differently per classification *** ## Prerequisites Before configuring Security Delivery Agents, ensure you meet the following requirements. | Requirement | Description | | ------------------------- | ------------------------------------------------------- | | **Agent Center Deployed** | Azure AI Foundry infrastructure must be provisioned | | **ContraForce Roles** | Organizational Admin and Workspace Owner roles required | Prerequisites to Configure Security Delivery Agents: * Agent Center must be fully deployed in your environment * ContraForce Role: Organizational Admin * ContraForce Workspace Role: Owner *** ## Phase 1: Manual Agent Execution In this initial phase, you manually select individual incidents and trigger the agent to run investigations. This allows you to evaluate agent performance before enabling automation. ### Running Agent Investigation Navigate to the incident you want to investigate Select **Actions** from the incident toolbar Select one of the following options: * **Run Agent Investigation** — Agent analyzes the incident and provides findings without taking remediation actions * **Run Agent Investigation and Response** — Agent analyzes the incident and executes recommended response actions Examine the agent's findings and recommendations ### Investigation Options | Option | Description | When to Use | | ---------------------------------------- | ---------------------------------- | --------------------------------------------------------- | | **Run Agent Investigation** | Analysis only, no response actions | When you want to review findings before taking action | | **Run Agent Investigation and Response** | Analysis plus automated response | When you trust the agent to execute appropriate responses | Start with investigation-only runs to understand how the agent analyzes your specific incident types before enabling response actions. *** ## Phase 2: Automatic Execution Based on Severity Once you're comfortable with agent behavior, configure automatic execution based on incident severity and status. The status filters below are the standard configuration. To scope automatic execution to specific **severities**, or to switch the trigger to **Manual**, enable **Advanced** mode and use the [True-Positive Policy](#advanced-configuration-true-positive-policy) settings. With Advanced disabled, behavior is exactly as described in this section. ### Configuring Automatic Execution Open **ContraForce Agent Center** from the main navigation Change the **Mode** setting to **On Queue** to enable automatic processing Select which incident statuses trigger automatic agent execution: * **New** — Agent runs on newly created incidents * **Active** — Agent runs on incidents currently being worked * **Closed** — Agent runs on closed incidents for retrospective analysis Apply your settings to activate automatic execution ### Status Filter Options **Process new incidents automatically:** * Agent triggers immediately when incidents are created * Provides rapid initial triage and analysis * Recommended for high-volume environments **Process incidents under investigation:** * Agent assists with ongoing investigations * Provides additional context and recommendations * Useful for augmenting analyst workflows **Process closed incidents:** * Agent performs retrospective analysis * Identifies missed indicators or patterns * Supports continuous improvement efforts *** ## Phase 3: Automatic Gamebook Execution In this advanced phase, you enable the agent to automatically execute gamebooks based on confidence thresholds. ### Enabling Automatic Gamebook Execution Open **ContraForce Agent Center** from the main navigation Toggle **Allow Agent to run gamebooks** to enabled Configure the confidence threshold that determines when the agent automatically executes gamebook actions Apply your settings to activate automatic gamebook execution ### Understanding Confidence Levels | Confidence Level | Behavior | Recommended For | | ---------------- | --------------------------------------------------- | ------------------------------------------------- | | **High** | Agent requires strong evidence before taking action | Production environments, sensitive systems | | **Medium** | Balanced approach between automation and caution | Most standard deployments | | **Low** | Agent takes action with less certainty | Test environments, high-volume low-risk scenarios | Lower confidence thresholds result in more aggressive automation. Start with higher thresholds and adjust based on observed accuracy and your risk tolerance. *** ## Advanced Configuration: True-Positive Policy By default, every agent investigation ends in one post-investigation flow regardless of the agent's verdict. **Advanced** mode replaces that single flow with a policy that acts on the agent's classification, so a True Positive can be escalated for analyst action while a False Positive is closed out. Advanced mode is opt-in and reversible. While it is **disabled**, agent behavior is exactly as described in Phases 1 to 3, with no change. Enabling it only adds the trigger and per-classification settings below. ### Enabling Advanced Mode Open **ContraForce Agent Center** and select the agent you want to configure. Enable the **Advanced** toggle. The trigger and classification settings appear. Choose the **severities** the agent runs on, and a **trigger mode**: * **On-Queue** — the agent runs automatically when a matching incident arrives. * **Manual** — the agent runs only when you trigger it from the incident **Actions** menu. For each classification, set what happens when the agent reaches that verdict (see below). Apply your settings. Save is blocked until the webhook list has loaded, so a policy is never saved against an unverified webhook. ### Per-Classification Policy When Advanced mode is on, each of the four classifications has its own policy. For an explanation of the classifications themselves, see [Incident Classifications](/guides/getting-started/incident-classifications). | Setting | Description | | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Gamebooks** | Gamebooks queued for the incident when the agent reaches this classification. | | **Assignee** | The owner the incident is assigned to. | | **Status** | The status the incident moves to (for example, keep a True Positive open for analyst action instead of closing it). | | **Custom action** | An optional webhook fired when the agent reaches this classification. Use this to escalate into your own SIEM, ticketing, or on-call tooling. | The common True-Positive Policy pattern: for **True Positive**, keep the incident open, assign it to your response queue, and set a webhook custom action so your team is paged. For **False Positive** and **Benign Positive**, close the incident with no webhook. ### The Custom Action Webhook The custom action sends the **Agent investigation completed** event (`agent.investigation.completed.v1`) the moment the investigation finishes. The payload carries the agent's verdict and the incident context, signed so your endpoint can verify it. This event is **selected here, on the classification card**. It is not a broadcast subscription: only the webhook a classification card points to receives it. For the payload schema, headers, and signature verification, see [Agent Investigation Completed Webhook](/guides/agent-center/agent-investigation-webhook). If the webhook a card points to is later deleted, paused, disabled, or unsubscribed from the event, the card shows a warning with a link to fix it in **Developers**, and the skipped delivery is recorded as **Failed** rather than dropped silently. Check the card if escalations stop arriving. *** ## Configuration Summary **Manual Execution:** * User selects individual incidents * User triggers agent via Actions menu * User reviews results before any response * Best for: Initial evaluation and building trust **Automatic by Status:** * Agent runs automatically on matching incidents * Mode set to On Queue * Status filters control which incidents are processed * Best for: Scaling investigation capacity **Automatic Gamebooks:** * Agent executes response playbooks automatically * Confidence level controls action threshold * Full automation of investigation and response * Best for: Mature environments with validated agent accuracy *** ## Best Practices Start with Phase 1 to understand agent behavior before enabling automation. Each phase builds on the previous one. Use Phase 1 to validate that agent analysis aligns with your expectations and incident handling procedures. Begin with higher confidence thresholds and lower them gradually based on observed accuracy. Even with full automation enabled, periodically review agent actions to ensure expected behavior. Keep records of which phases are enabled and your confidence threshold settings for troubleshooting and auditing. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | -------------------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Agent not processing incidents | Mode not set to On Queue | Verify Mode is set to On Queue in Agent Center | | Gamebooks not executing | Feature not enabled | Confirm "Allow Agent to run gamebooks" is toggled on | | Too many automated actions | Confidence threshold too low | Increase confidence level setting | | Agent missing incidents | Status filters misconfigured | Review and adjust status filter selections | | Investigation not starting | Missing permissions | Verify Organizational Admin and Workspace Owner roles | | Escalation webhook not arriving | Card's webhook deleted, paused, disabled, or unsubscribed | Check the classification card for a binding warning; fix the webhook in Developers. Skipped deliveries appear as Failed in the delivery log | | Advanced settings have no effect | Advanced toggle disabled | Enable the Advanced toggle and save; without it the standard Phase 1 to 3 behavior applies | If you encounter persistent issues with Security Delivery Agent configuration, contact [support@contraforce.com](mailto:support@contraforce.com) with your configuration details and observed behavior. *** ## Related Guides Deploy Microsoft Foundry infrastructure to manage your AI agents Learn about automated SOP-driven response actions Overview of incident handling in ContraForce Understanding ContraForce role requirements Payload, headers, and signature verification for the custom action event *** Questions about Security Delivery Agent configuration? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Content Management System (CMS) Source: https://docs.contraforce.com/guides/getting-started/content-management-system Deploy and manage security detection rules across Microsoft Sentinel environments with toggle-based activation—no KQL expertise required. The Content Management System (CMS) transforms security detection engineering from a specialized discipline into an accessible, scalable process. Deploy expert-authored detection rules to your Sentinel workspaces with simple toggles—no complex configuration, no KQL expertise required. CMS is available for workspaces with the **Microsoft Sentinel module** deployed. Within CMS, a library of expert-developed detection rules are available under the Sentinel Marketplace tab. Your existing rules can be viewed under the Analytic Rules tab. ## Why CMS? Detection content written by security engineers covering MITRE ATT\&CK Enable rules with a toggle—no complex configuration, no multi-step installations Deploy the same rules across one customer or hundreds Keep detection rules current as threats evolve, with optional auto-update *** ## The Problem CMS Solves Security teams face what we call "the content storm"—the overwhelming challenge of creating, deploying, and maintaining detection rules at scale. ### Traditional Challenges Writing effective detection rules requires deep knowledge of KQL (Kusto Query Language), understanding of attack techniques, and familiarity with Microsoft Sentinel's rule configuration options. This expertise is expensive and hard to find. Threats evolve constantly. Detection rules that worked yesterday may miss today's attack variants. Keeping rules current across multiple customer environments is a never-ending task. What works for one Sentinel workspace becomes exponentially harder when managing dozens or hundreds of customer environments. Microsoft's native interface requires navigating through each tenant individually. Deploying a single rule in Sentinel's native interface involves multiple steps—finding the template, configuring parameters, setting schedules, mapping entities. Multiply this across hundreds of rules and many tenants, and the burden becomes unsustainable. *** ## How CMS Works ### Detection Rule Library CMS provides access to a continuously updated library of detection rules organized by data source. Each rule includes: | Attribute | Description | | ------------------------- | ----------------------------------------------------- | | **Display Name** | Clear, descriptive name for the detection | | **Description** | What the rule detects and why it matters | | **Severity** | Risk level (Low, Medium, High) to prioritize response | | **MITRE ATT\&CK Mapping** | Tactics and techniques the detection covers | | **Query** | The underlying KQL logic (visible for transparency) | | **Version** | CalVer format (e.g., 2024.01.15) for tracking updates | | **Query Frequency** | How often the rule runs | | **Query Period** | The time window the rule analyzes | ### Simple Deployment Deploying a detection rule is as simple as toggling a switch: Click the toggle switch next to any rule CMS retrieves the rule definition from the secure repository The rule is transformed into Microsoft Sentinel's API format An authenticated API call deploys the rule to your workspace Deployment status updates in real-time ### Automated Updates When our security engineering team improves a detection rule—whether to catch new attack variants, reduce false positives, or optimize performance—CMS can automatically update the rule in your environment. You control whether updates happen automatically or require manual approval based on your change management requirements. ### Version Management Every rule is versioned using Calendar Versioning (CalVer). You can see: * Which version is currently deployed * Whether a newer version is available * The history of changes to any rule This transparency lets you make informed decisions about when and whether to update. *** ## Key Capabilities For MSSPs and organizations with multiple Sentinel workspaces, CMS enables deployment across all environments from a single interface. * Deploy to one customer or one hundred—the process is identical * Consistent detection coverage across your entire customer base * No need to log into each Azure tenant separately Enable or disable any rule with a single click. * No navigating through Azure portals * No complex configuration forms * At-a-glance visibility into which rules are active, disabled, or have updates available When you deploy or remove a rule, you see immediate feedback: * Deployment in progress indicator * Success confirmation * Error details with actionable information if something goes wrong CMS respects your organization's permission structure: * Control who can deploy new rules * Control who can enable automatic updates * Control who can remove deployed rules * Maintain audit trails of all changes *** ## Analytic Rules Per Data Source Type CMS provides detection rules for threats across your Microsoft Sentinel data sources, which include some of the following coverage: * Active Directory * Entra ID * Sign-in analytics * Exchange Online * SharePoint * Teams * Azure Activity * Security Center * NSG * Windows Security Events * Defender for Endpoint * DNS Analytics * Firewall logs via Syslog * Network flow data The CMS library continuously expands with new detections mapped to MITRE ATT\&CK and D3FEND Each data source has its own collection of rules tailored to the specific threats and attack patterns relevant to that telemetry. ## Technical Architecture ### Direct Integration with Microsoft Sentinel CMS communicates directly with Microsoft Sentinel through the Azure Resource Manager (ARM) API: | Advantage | Description | | ---------------- | ----------------------------------------------------------- | | **Reliability** | No intermediate systems that could fail or introduce delays | | **Speed** | Rule deployments complete in seconds, not minutes | | **Transparency** | Every deployment operation is logged with full details | ### Background Processing Rule deployments run as background jobs: * Your browser doesn't need to stay open during deployment * Multiple deployments can run simultaneously * Failed deployments automatically retry * Notifications alert you when operations complete ### Secure Rule Storage Detection rules are stored in a dedicated Azure Cosmos DB database with: * Encryption at rest * Version history preservation * Geographic redundancy * High availability *** ## Benefits by Role * **Faster onboarding** — Start detecting threats immediately with pre-built rules * **Less context switching** — Manage detection content alongside incident response in one platform * **Confidence** — Know that detection rules are authored by security experts and continuously updated * **Focus on what matters** — Spend time on custom detections specific to your environment, not maintaining standard rules * **Transparency** — Review the underlying queries to understand exactly what each rule does * **Control** — Choose between automatic updates and manual approval based on your change management requirements * **Scale efficiently** — Manage detection content for all customers from one interface * **Differentiate services** — Offer managed detection content as a value-added service * **Reduce costs** — Minimize the specialized expertise needed for detection engineering * **Onboard faster** — Deploy comprehensive detection coverage to new customers in minutes * **Reduce risk** — Comprehensive threat detection without building an in-house detection engineering team * **Optimize spending** — Achieve broad coverage at a fraction of the cost of custom development * **Maintain compliance** — Documentation and audit trails support compliance requirements * **Stay current** — Automatic updates ensure protection against emerging threats *** ## Getting Started ### Prerequisites A ContraForce account with appropriate permissions A Microsoft Sentinel workspace connected to ContraForce Data Source Admin, Content Admin, or Organization Admin role ### Deploying Your First Rule Go to the **Content Management** section in ContraForce Choose the data source you want to deploy content for Review available rules and their descriptions, MITRE mappings, and severities Toggle the rules you want to deploy to **Enabled** Watch the real-time status as rules deploy to your workspace CMS rule deployment interface CMS Library ### Configuring Automatic Updates Click on a deployed rule to open its details Toggle the **Auto-Update** option to enabled When new versions are released, they deploy automatically You can enable auto-update for individual rules or set a workspace-wide default. Rules with auto-update disabled will show an "Update Available" indicator when new versions are released. *** ## Frequently Asked Questions No. CMS-deployed rules are tracked separately and won't interfere with rules you've created manually in Sentinel. They coexist peacefully with your custom detections. CMS rules are deployed as-is to ensure consistency and supportability. If you need custom modifications, you can use the rule as a template and create your own version in Sentinel directly. You'll see an error message with details about what went wrong. Common causes include permission issues or temporary Azure API unavailability. Failed deployments can be retried with a single click. Our security engineering team continuously develops new detections based on emerging threats, customer feedback, and industry research. New rules are added regularly. Yes. Each rule version includes information about what was modified—whether it's an improvement to detection logic, a reduction in false positives, or a performance optimization. You need the **Data Source Admin**, **Content Admin**, or **Organization Admin** role in ContraForce. You also need appropriate permissions in the target Azure tenant for Sentinel API access. Yes. CMS supports bulk deployment across multiple Sentinel workspaces. Select the workspaces you want to target and enable the rules—they deploy to all selected workspaces simultaneously. *** ## Best Practices Begin by enabling rules with low false positive rates and high detection value. As you gain confidence in the system, expand to broader coverage. For general-purpose detection rules, enable auto-update to stay current with threat landscape changes. Reserve manual approval for rules where you need tight change control. Use the MITRE ATT\&CK mappings to ensure you have detection coverage across the kill chain. Identify gaps and enable rules that address them. Only enable rules for data sources you actually have connected. Enabling rules without the corresponding telemetry will result in rules that never fire. Periodically review which rules are generating incidents. Rules that never trigger may indicate missing data sources or detections that aren't relevant to your environment. *** ## Learn More A Better Way to Manage Detection Content How MSSPs Can Implement CISA Guidance 10 Ways ContraForce Automates Multi-Tenant Management Permissions for Users managing CMS across tenants *** ## Related Guides XDR vs XDR + SIEM modules Configure incident notifications *** Questions about the Content Management System? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Incident Classifications Source: https://docs.contraforce.com/guides/getting-started/incident-classifications Learn how to properly classify incidents as True Positive, False Positive, Benign Positive, or undetermined to improve detection accuracy and reporting. Properly classifying incidents is essential for accurate reporting, tuning detection rules, and understanding your security posture. This guide explains when to use each classification type. ## Classification vs Status Before diving into classifications, it's important to understand the difference between **Status** and **Classification**: **Work state** of the investigation * **New** — Not yet reviewed * **Active** — Under investigation * **Closed** — Investigation complete **Outcome** of the investigation * True Positive * False Positive * Benign Positive * Undetermined **Status** tracks *where you are* in the investigation process. **Classification** documents *what you found* when the investigation is complete. *** ## Classification Types ### True Positive The incident represents an **actual security threat** that required response. **When to use:** * Confirmed malicious activity was detected * A real attack or compromise occurred * Threat actor activity was identified * Malware, phishing, or unauthorized access was verified **Examples:** * User credentials were actually compromised * Malware was confirmed running on an endpoint * Data exfiltration attempt was verified * Unauthorized access to sensitive resources occurred True Positives validate that your detection rules are working correctly. Document the threat details in comments for future reference. *** ### Benign Positive The detection was **technically correct**, but the activity was **legitimate** and authorized. **When to use:** * Suspicious-looking activity was actually authorized * A user performed unusual but legitimate actions * IT/Admin activities triggered security alerts * Penetration testing or security assessments caused alerts **Examples:** * Admin legitimately accessed multiple systems during maintenance * User traveled and logged in from an unusual location * Authorized penetration test triggered alerts * New software deployment caused unusual process behavior Benign Positives help identify opportunities for tuning. Consider creating exceptions or adjusting detection thresholds for known legitimate activities. *** ### False Positive The incident was **incorrectly triggered** due to flawed detection logic or bad data. **When to use:** * Detection rule logic is flawed or too broad * Inaccurate or corrupted data triggered the alert * Misconfiguration caused incorrect detection * The alert has no basis in actual activity **Sub-classifications:** | Reason | Description | | ------------------------- | --------------------------------------------------------------------------- | | **Inaccurate data** | The data used to generate the alert was incorrect, incomplete, or corrupted | | **Incorrect alert logic** | The detection rule itself is flawed and needs to be modified or disabled | **Examples:** * Alert triggered on a non-existent user due to log parsing error * Detection rule matches normal business activity too broadly * Time zone misconfiguration caused false temporal correlation * Deprecated system generated alerts for decommissioned resources False Positives indicate detection problems that should be addressed. Report patterns of False Positives to improve detection quality. *** ### Undetermined The investigation was **inconclusive**—the cause or outcome couldn't be determined. **When to use:** * Insufficient evidence to reach a conclusion * Logs or data needed for investigation are unavailable * The incident doesn't fit other classification categories * Investigation was abandoned due to resource constraints **Examples:** * Relevant logs expired before investigation completed * Activity was suspicious but couldn't be verified either way * Source system was decommissioned, preventing further analysis * Alert context was insufficient for determination When using Undetermined, always add detailed comments documenting what was discovered during the investigation. This helps if the incident needs to be revisited later. *** ## Quick Reference | Classification | Meaning | Action | | ------------------- | -------------------------------------- | -------------------------------------------------- | | **True Positive** | Real threat confirmed | Document threat details, validate response actions | | **Benign Positive** | Correct detection, authorized activity | Consider tuning or adding exceptions | | **False Positive** | Incorrect detection | Report for rule improvement | | **Undetermined** | Inconclusive investigation | Document findings in comments | *** ## Classification Decision Tree Use this flow to determine the correct classification: ```mermaid theme={null} flowchart TD A[Incident Investigation Complete] --> B{Was there actual\nmalicious activity?} B -->|Yes| C[True Positive] B -->|No| D{Was the detection\ntechnically correct?} D -->|Yes| E{Was the activity\nauthorized?} D -->|No| F[False Positive] E -->|Yes| G[Benign Positive] E -->|No/Unknown| H{Can you determine\nthe cause?} H -->|No| I[Undetermined] H -->|Yes| B ``` *** ## Best Practices Document your investigation findings regardless of classification. This creates an audit trail and helps with future investigations of similar incidents. Work with your team to establish classification guidelines. Consistent classification improves metrics accuracy and detection tuning. Regularly review classification trends. High False Positive rates indicate detection rules that need tuning. High Benign Positive rates suggest exception lists need updating. Use Undetermined only when you genuinely cannot determine the outcome. Overuse of Undetermined reduces the value of your classification data. *** ## Related Guides Complete workflow for managing incidents. Complete workbench to manage your incident resolution. *** Questions about classifications? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Incident Management Source: https://docs.contraforce.com/guides/getting-started/incident-management A complete workflow for triaging, investigating, and resolving security incidents in ContraForce. This guide walks you through the recommended workflow for managing security incidents in ContraForce—from initial triage to resolution. ContraForce empowers analysts to efficiently manage incidents across multiple tenants and data sources. This workflow is designed to help you resolve incidents faster and deliver better service to your customers. ## Workflow Overview Focus on specific tenants or view all incidents across your environment Route incidents to the appropriate analyst Review the incident summary, entities, timeline, and evidence Execute automated response actions with one click Document findings and close with proper classification ## 1. Workspace Filtering The Command Page allows you to customize which incidents are displayed by filtering on Workspace, Severity, and Status. These filters persist as you navigate between pages in ContraForce. ### Setting Your Workspace Filter Click the workspace dropdown menu in the top bar of the Command dashboard Choose one or more workspaces to display The Incidents table updates to show only data from selected workspaces Workspace Filter Command Page ## 2. Setting Your Incident Assignees Filter Click the assignee dropdown menu in the top bar of the Command Page Choose one or more workspaces to display The Incidents table updates to show only incidents from selected assignees Workspace filter dropdown ### Additional Filters Beyond workspace filtering, you can further refine your view: | Filter | Options | Use Case | | ------------ | -------------------------------- | ------------------------------------ | | **Severity** | High, Medium, Low, Informational | Focus on critical incidents first | | **Status** | New, Active, Closed | View only incidents requiring action | | **Module** | Sentinel, Defender for Endpoint | Filter by security product | When filtering by status, you'll see statuses organized by module (Sentinel, Defender for Endpoint, etc.). This helps you quickly identify incidents by source. *** ## 2. Incident Assignment Proper incident assignment ensures the right analyst handles each incident and provides clear ownership for tracking. ### Individual Assignment To assign a single incident: 1. Locate the incident in the Incidents table 2. Click the dropdown in the **Owner** column 3. Select an analyst from the list of portal users Ownership is recorded in ContraForce for every incident source, including SentinelOne and CrowdStrike, whose APIs cannot carry a ContraForce analyst as the assignee. For SentinelOne this is ContraForce-only: the threat stays unassigned in the SentinelOne console. For CrowdStrike you can optionally mirror assignments onto the Falcon alert as a bound service account — see [Assignment Writeback](/guides/onboarding/crowdstrike-detection-and-response-modules). ### Handling Incidents at Scale Select multiple incidents in the Incidents table to close or reassign them in one action. A bulk close applies a single classification, reason, and optional comment across the selection; a bulk reassign sets one owner, or unassigns. Both work across a selection that spans workspaces and incident sources. For hands-off triage, **Security Delivery Agents** running **on queue** automatically triage and act on incidents in bulk as they arrive, so you don't have to process them batch by batch. See [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents). *** ## 3. Incident Summary The Incident Summary provides a complete view of an incident with all the context you need for investigation. ### Accessing the Summary Click any **Incident ID** in the Incidents table to open its Summary view. Incident Summary overview ### Incident Tabs **Summary** – Overview of the incident including severity, status, affected assets, and key details at a glance. **Rule** – Shows the detection rule that triggered the incident, including rule logic, conditions, and configuration. **Entities** – Lists all related entities (users, devices, IPs, domains, files) involved in or affected by the incident. **Timeline** – Chronological view of all events and actions related to the incident from detection through resolution. **Logs** – Raw log data and events associated with the incident for deeper investigation. **Comments** – Collaboration space for analysts and AI agents to add notes, findings, and communicate about the investigation. **Audit** – Track record of all changes made to the incident (status updates, assignments, modifications) with timestamps and user attribution. ## 4. Gamebook Responses Gamebooks SOP driven AI-generated and human created response actions that let you quickly respond to incidents. Available Gamebook actions are determined by the entity types present in the incident. Agents automatically suggests relevant actions based on the output of the investigation and incident classification. ### Using Suggested Gamebooks If a Gamebook has been previously executed for similar incidents, agents suggest it automatically: Gamebook response panel with completed actions ### Creating a Custom Gamebook Click the dropdown next to "Edit" and select **Create New Gamebook** Click entity icons in the Entity Graph to see available response actions * Use the arrows to navigate through action options * Click the green **+** icon to add an action * Click the red **-** icon to remove an action Click **Approve Gamebook** to execute all selected actions ### Gamebook Approval Workflow Some Gamebook actions require approval before execution: Actions with a **red lock icon** require approval from a user with appropriate permissions in the tenant. **To request approval:** 1. Build your Gamebook as usual 2. Click **Request Gamebook Approval** (instead of Run Gamebook) 3. The request is sent to authorized approvers **To approve a Gamebook:** * Approvers can approve directly from the incident, or * Use the **Gamebook Activity** tab to review and approve pending requests *** ## 5. Incident Closure After completing your investigation and response, close the incident with proper documentation. Close Incident modal ### Quick Close from Gamebook After a Gamebook completes, a green **Close Incident** button appears at the bottom of the Gamebook context group. ### Closure Fields | Field | Options | Purpose | | ------------------ | ------------------------------------------------------------ | --------------------------------------------------- | | **Classification** | True Positive, False Positive, Benign Positive, Undetermined | Required. Categorizes the incident outcome | | **Comment** | Free text | Optional note about why you're closing the incident | Need help understanding classifications? See [Understanding Incident Classifications](/guides/getting-started/understanding-incident-classifications) for detailed guidance. *** ## Putting It Together The ContraForce incident management workflow is designed to help you: Filter and prioritize incidents across all your tenants from one dashboard Execute proven response actions with Gamebooks instead of manual remediation Maintain complete audit trails with comments, classifications, and history *** ## Related Guides Learn more about the central incident dashboard. Deep dive into SOP driven automated response actions. Learn how to manage incidents in your workbench. Understand True Positive, False Positive, and more. *** Questions about this workflow? Contact us at [support@contraforce.com](mailto:support@contraforce.com). We're happy to help optimize your incident management process. # Multi-Tenant Features Source: https://docs.contraforce.com/guides/getting-started/multi-tenant-features Manage security delivery across all your customers from a single unified platform. Built for MSPs and MSSPs. ContraForce is purpose-built for MSPs and MSSPs managing multiple customer environments. View incidents, run response actions, and monitor security posture across all your tenants—without switching between portals. Whether you manage 5 tenants or 500, ContraForce scales with your business. All multi-tenant features are included in the platform at no additional cost. ## Why Multi-Tenant Matters Traditional security tools force analysts to log into each customer environment separately. ContraForce eliminates this friction: View all customer incidents in one unified dashboard. SOP workflows automated across every tenant. One analyst can manage more customers effectively. *** ## Command Dashboard: Your Central Hub The **Command Dashboard** is the heart of ContraForce's multi-tenant capabilities. It provides a unified view of all security incidents across your managed tenants. Command Dashboard multi-tenant view ### What You Can See | Function | Multi-Tenant Capability | | ---------------------------- | ------------------------------------------------ | | **Multi-Tenant Dropdown** | Filter down on one or many workspaces in seconds | | **Closed Incident Trends** | Closed incidents trends across workspaces | | **Incident Rule Trends** | Detections triggered by rules across workspaces | | **Latest Gamebook Activity** | Recent response actions across workspaces | ### Default Behavior By default, the Command Dashboard displays data for all onboarded workspaces. This gives you immediate visibility into your entire customer base without any configuration. Start your day on the Command Dashboard to quickly identify which customers need attention. Trends and recent activity allow you to focus where it matters. *** ## Workspace Filtering While seeing everything is powerful, sometimes you need to focus. The **Workspace Filter** lets you customize your view. ### How It Works Click the workspace dropdown in the top navigation bar Check the workspaces you want to display (one, several, or all) All dashboard cards and tables update to show only selected workspaces Workspace filter selection ### Filter Persistence Your workspace selection **persists as you navigate** between pages in ContraForce: * Command Page → Incidents Page → Gamebooks Page * Your selected workspaces remain active throughout your session * No need to re-select filters on each page This persistence is especially useful when you're focused on a specific customer's issues and need to investigate across multiple ContraForce features. ### Additional Filters Beyond workspace filtering, you can further refine the Incidents table by: | Filter | Options | Use Case | | ------------ | -------------------------------- | ----------------------------- | | **Severity** | High, Medium, Low, Informational | Prioritize critical incidents | | **Status** | New, Active, Closed | Focus on open investigations | | **Module** | Sentinel, Defender for Endpoint | Filter by security product | *** ## Multi-Tenant Incident Management Managing incidents across tenants follows the same workflow—but with added context about which customer is affected. ### Incident Table Columns The Incidents table includes workspace identification: | Column | Description | | ------------------ | --------------------------------------------- | | **Severity** | Incident severity level | | **Workspace** | Which customer/tenant the incident belongs to | | **Incident Title** | Description of the incident | | **Incident ID** | Unique identifier (click to investigate) | | **Creation Time** | When the incident was detected | | **Status** | Current investigation state | | **Owner** | Assigned analyst | ### Incident Handling Across Tenants You don't process cross-tenant incidents with a manual bulk action. **Security Delivery Agents** running **on queue** triage and act on incidents across all your tenants automatically as they arrive. See [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents). *** ## Multi-Tenant Gamebook Activity Track automated response actions across your entire customer base. ### Gamebook Activity Card The Command Page shows **Latest Gamebook Activity** with: * **Workspace** — Which customer the action was performed on * **Status** — Success, Failed, Pending Approval * **Incident** — Linked incident ID * **Owner** — Who initiated the action ### Approval Workflows When Gamebook actions require approval, you can manage all pending requests from one location: 1. Navigate to the **Gamebook Activity** tab 2. View pending approvals across all tenants 3. Approve or reject with full context ## Workspace Management The **Workspaces Page** provides administrative control over your tenants. ### Pre-Onboarding Prepare customer environments before full deployment: * Create workspace placeholders * Configure initial settings * Streamline the onboarding process ### Post-Onboarding Management After onboarding, manage workspace configurations: * View onboarding status * Access workspace settings * Monitor integration health Complete guide to the Workspace Manager. *** ## Best Practices for Multi-Tenant Operations Use consistent workspace names that clearly identify customers. This makes filtering and incident triage faster. Define which incident types require immediate attention vs. scheduled review. Use severity filtering to prioritize. For large deployments, consider assigning analysts to specific workspace groups to build customer familiarity. Start each day with a Command Page review across all tenants to catch emerging issues early. Don't wait for incidents to reveal data flow problems. Check Data Connector Anomalies regularly. *** ## Related Guides Deep dive into the central dashboard. Complete incident workflow guide. Manage tenant configurations. Manage Users and Groups. *** Questions about multi-tenant features? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Platform Permissions and Consent Source: https://docs.contraforce.com/guides/getting-started/platform-permissions-and-consent ## Introduction Before ContraForce can operate in your Microsoft Entra tenant, a sufficiently privileged user must grant permission for ContraForce applications to access tenant data. This article explains which permissions ContraForce requires, when they're requested, and why. ## How ContraForce Connects to Your Environment ContraForce uses a modular set of Microsoft Entra ID applications to securely connect with your environment. Each application is purpose-built for a specific function and requests only the permissions it needs. This design follows the **principle of least privilege**—you only grant permissions for the capabilities you actually use. For example, if you don't use Gamebooks to respond to endpoint threats, you never need to consent to the ContraForce Gamebooks for MDE application. ## ContraForce Applications | Application | Purpose | | ---------------------------------- | ------------------------------------------------ | | ContraForce API | Core platform connectivity and coordination | | ContraForce Portal | Secure sign-in with your Microsoft account | | ContraForce Sentinel Hunting | Query logs and investigate incidents in Sentinel | | ContraForce for MDE | View and manage Defender for Endpoint devices | | ContraForce Gamebooks for Identity | Automated response actions for user accounts | | ContraForce Gamebooks for MDE | Automated response actions for endpoints | | Microsoft 365 Response | Automated response actions for email threats | During onboarding, you'll consent to **ContraForce API** and **ContraForce Portal**. The remaining applications can be consented to later from **Settings → Permissions** based on the capabilities you need. ## Application Details ### ContraForce API The core connection that allows ContraForce to communicate with your Microsoft environment. This application coordinates all platform operations—from onboarding your workspace to managing Azure resources—and securely connects the other ContraForce services. ### ContraForce Portal Enables secure sign-in to ContraForce using your Microsoft work account. This application verifies your identity and displays your basic profile information (name and email) within the platform. ### ContraForce Sentinel Hunting Allows ContraForce to query your Microsoft Sentinel workspace for deeper investigation. This powers the Advanced Hunting feature and retrieves raw log evidence to give analysts full context behind security incidents. ### ContraForce for Defender for Endpoint (MDE) Connects ContraForce to Microsoft Defender for Endpoint so you can view and manage protected devices. This provides visibility into device health, alerts, and security posture across your environment. ### ContraForce Gamebooks for Identity Powers automated response actions for user-related threats. When a Gamebook runs, this application can lock out compromised accounts, reset passwords, and revoke active sessions—containing identity-based attacks in seconds instead of hours. ### ContraForce Gamebooks for MDE Powers automated response actions for endpoint threats through Microsoft Defender. When a Gamebook runs, this application can isolate compromised devices from your network, quarantine malicious files, and trigger antivirus scans—stopping threats before they spread. ### Microsoft 365 Response Powers automated response actions for email-based threats. When a Gamebook runs, this application can delete malicious emails from user mailboxes, block dangerous senders, and purge phishing messages across your organization—neutralizing email attacks before users can click. ## Onboarding and Consent Flow 1. Sign in at [portal.contraforce.com](https://portal.contraforce.com) with a Microsoft work account 2. Consent to **ContraForce API** permissions 3. Consent to **ContraForce Portal** permissions These two core consents are presented as **two separate** Microsoft consent prompts. Additional application permissions can be granted later as needed from **Settings → Permissions**. Granting these consents requires a **Global Administrator**. Microsoft Graph app-only permissions cannot be granted by Cloud App Admin or Application Admin accounts. The first time anyone from your tenant signs in at [portal.contraforce.com](https://portal.contraforce.com), a Global Administrator consents the core ContraForce applications. You first sign in with a Microsoft work account and consent to the **ContraForce API**, then you're prompted to consent the permissions requested for the **ContraForce Portal** application. After these consents, you land on the **Command** page, where a **Get started** checklist guides you through any remaining setup. ## Learn More For detailed information about Microsoft's consent framework, see Microsoft's [Application model overview](https://learn.microsoft.com/en-us/entra/identity-platform/application-model) and [consent experience documentation](https://learn.microsoft.com/en-us/entra/identity-platform/application-consent-experience). Understanding the Microsoft Entra ID permissions and enterprise applications required for ContraForce workspace deployments. ## Getting Help Email [support@contraforce.com](mailto:support@contraforce.com) for assistance Schedule a call for hands-on help with your first deployment # What are Gamebooks? Source: https://docs.contraforce.com/guides/getting-started/what-are-gamebooks Automate incident response with AI-generated response actions. Gamebooks let you isolate devices, disable users, block IPs, and more—without manual intervention. Gamebooks are SOP-driven incident response workflows powered by ContraForce's response engine, IRIS. Instead of manually logging into multiple consoles to contain a threat, you can execute proven response actions with a single-click across any workspace. Think of Gamebooks as your incident response playbook—automated. No API mapping, no coding, no scripting. Select the response actions you need, click run, and ContraForce handles the execution across your integrated security tools. AI agents can autonomously choose the correct response actions based on entity types and the classification of the incident. ## Why Gamebooks? Traditional incident response requires analysts to: 1. Identify affected entities (users, devices) 2. Log into each security tool separately 3. Manually execute containment actions 4. Document what was done **Gamebooks compress this into seconds:** Execute multiple actions across tools instantly The right response every time Complete history of every action taken *** ## Available Gamebook Actions Gamebook actions are organized by entity type. ContraForce automatically shows relevant actions based on the entities involved in each incident. ### User Actions | Action | Description | Use Case | | -------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------- | | **Invalidate Existing Sessions** | Terminates all active sessions | Compromised account, suspicious activity | | **Lockout User** | Prevents user from signing in | Confirmed account compromise | | **Reset User Password** | Forces password reset on next login | Credential theft suspected | | **Reset MFA** | Removes all registered MFA methods, forcing re-registration at next sign in | Attacker-registered MFA, lost or compromised authenticator | | **Unlock User** | Re-enables a locked account | After remediation is complete | **Reset MFA vs. Reset User Password.** These are complementary, not interchangeable. *Reset User Password* invalidates the credential the user types; *Reset MFA* deletes the second factors they present (Microsoft Authenticator, phone/SMS, FIDO2 security keys, software OATH tokens, Windows Hello for Business, Temporary Access Pass, and email/platform methods). It does **not** change the password. When you suspect an attacker has enrolled their *own* authenticator on a compromised account, a password reset alone leaves that rogue factor in place: run **Reset MFA** to strip it, and pair it with **Reset User Password** for full credential containment. After the reset the user re-registers MFA on their next sign in, so confirm an enrollment path (and any Conditional Access / registration-campaign policies) is in place before running it. ### Endpoint Actions | Action | Description | Use Case | | -------------------------- | ------------------------------------------------- | -------------------------------- | | **Isolate Endpoint** | Disconnects device from network (except Defender) | Active malware, lateral movement | | **Scan Endpoint** | Triggers antivirus/EDR scan | Suspicious file activity | | **Release from Isolation** | Restores network connectivity | After threat is contained | | **Quarantine File** | Moves malicious file to quarantine | Known malware detected | ### Network Actions | Action | Description | Use Case | | ------------------ | ------------------------------------------------------- | ---------------------------------- | | **Block Cloud IP** | Adds IP to Azure Network Security Group (NSG) blocklist | C2 communication, malicious source | ### Email Actions | Action | Description | Use Case | | ---------------- | ------------------------------------ | -------------------------- | | **Delete Email** | Removes malicious email from mailbox | Phishing, malware delivery | Available actions depend on your connected modules. For example, endpoint actions require Microsoft Defender for Endpoint module to be configured. *** ## How to Access Gamebooks From the Command Page, click any **Incident ID** to open the Incident Summary Click the dropdown next to **Edit** and select **Create New Gamebook** The Gamebook Workbench opens with the Entity Context Graph Accessing Gamebook Workbench ## Building a Gamebook Creating a Gamebook is intuitive—select entities, choose response actions, and execute. ### Step 1: Select an Entity **Left-click** an entity in the Entity Context Graph (user, device, IP, etc.). The response action menu appears showing available response actions. Entity selection in Gamebook ### Step 2: Add Actions * With the **left-click** menu open, select available response actions * Click a response action to load it into the Gamebook * Click the **red - icon** to remove an action ### Step 3: Repeat for Other Entities Select additional entities and add their actions. You can build comprehensive response workflows targeting multiple entity types. ### Step 4: Review & Execute Your selected actions appear in the **Gamebook Card**: Gamebook actions queue | Column | Description | | ---------- | ----------------------------------- | | **Action** | The response action to be performed | | **Entity** | Target of the action | | **Status** | "Pending" before execution | Click **Run Gamebook** to execute all actions. ## Gamebook Execution Status After clicking Run Gamebook, monitor the execution: | Status | Meaning | | ------------ | ------------------------------ | | **Pending** | Action queued, not yet started | | **Running** | Action currently executing | | **Finished** | Action completed successfully | | **Failed** | Action encountered an error | If an action fails, check the Gamebook Activity page for error details. Common causes include permission issues or connectivity problems with the target system. ## Gamebook Approval Workflow Manage the team members responsible for approving Gamebooks that require manual authorization. Only users with the **Workspace Owner** role can be assigned as Gamebook approvers. ### Gamebook Approval Configuration Within each workspace settings page, under **General,** scroll to the bottom and configure the **Gamebook Configuration** settings based on your SOP for that specific workspace. Approval required indicator Some response actions (Reset user password) requires the end user of the workspace to have Cloud App Admin, Application Admin, or Global Admin role. As a Service Provider, you can approve this action on your end without the end user consent. ### Approving Gamebooks Users with approval permissions can approve from: Open the incident and approve directly from the Gamebook status Review all pending approvals in one centralized queue Once approved, the Gamebook executes automatically. ## Gamebook History Track all Gamebook activity across your environment from the dedicated **Gamebooks Page**. ### Accessing Gamebook History Click the **Gamebooks icon** (triangle) in the navigation bar—it's the 2nd icon from the top. Gamebooks page navigation ### What You Can See The Gamebooks page shows: | Filter | Description | | -------------------- | ------------------------------- | | **Completed** | Successfully executed Gamebooks | | **Waiting Approval** | Pending approval requests | | **Failed** | Gamebooks with errors | ### Viewing Details Click the **dropdown arrow** on any row to expand and see: * Individual action results * Execution timestamps * Error messages (if failed) * Entity details Gamebook history expanded view Use the workspace filter to view Gamebook history for specific tenants. This is useful when reviewing activity for a particular customer. ## Unsupported Entities Not all entity types support Gamebook actions due to technical limitations with module integrations. **Common reasons:** * Integration doesn't expose response APIs * Entity type not yet supported * Permissions not configured for response actions If you need specific response capabilities, contact [support@contraforce.com](mailto:support@contraforce.com) to discuss your requirements. ## Best Practices Prioritize actions that stop the threat from spreading—isolate devices, disable compromised accounts, block malicious IPs. Configure approval requirements for actions like device isolation that could impact business operations. Always verify the Gamebook Card shows the correct entities and actions before clicking Run. Check the Gamebooks page regularly for failed actions that may need manual intervention. After running a Gamebook, add comments to the incident explaining what actions were taken and why. ## Gamebook Actions Quick Reference | Entity | Actions Available | | ------------ | --------------------------------------------------------------- | | **User** | Invalidate Sessions, Lockout, Reset Password, Reset MFA, Unlock | | **Endpoint** | Isolate, Scan, Release from Isolation, Quarantine File | | **Network** | Block IP | | **Email** | Delete Email | ## Related Guides Your toolset for security delivery Complete incident workflow guide Classify incidents after response Configure approval permissions *** Questions about Gamebooks? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Workbench Overview Source: https://docs.contraforce.com/guides/getting-started/workbench-overview Create custom incident response workflows with AI-mapped playbooks and one-click actions. Visualize entities, build Gamebooks, and resolve incidents faster. The Security Workbench is your investigation and response command center. Visualize affected entities, build custom response workflows, and execute remediation actions—all from a single interface. ContraForce Security Workbench ## What is the Workbench? The Workbench combines investigation and response into one powerful experience: Automatically recommended response actions based on affected entity types See all related entities in an interactive context graph Click-through investigation for entities without writing queries Chain multiple actions into comprehensive Gamebooks The Workbench is where investigation meets action. Instead of switching between tools, you can analyze the threat and respond to it in the same place. *** ## Accessing the Workbench From the Command Page, click any **Incident ID** in the Incidents table The Incident Summary opens with overview information Click the dropdown next to **Edit** and select **Create New Gamebook** *** ## Workbench Layout The Security Workbench is organized into several key areas: ### Incident Header At the top of the Workbench, you'll find: | Element | Description | | ------------------ | --------------------------------------------------- | | **Incident Title** | Name and ID of the incident | | **Status** | Current state (New, Active, Closed)—editable inline | | **Owner** | Assigned analyst—editable inline | | **Severity** | Incident severity level | You can update the Status and Owner directly from the Workbench without leaving the page. ### Entity Graph The central visualization showing all entities involved in the incident: * **Users** — Accounts that were affected or involved * **Devices** — Endpoints implicated in the incident * **IPs** — Network addresses related to the activity * **Files** — Suspicious files or hashes detected * **URLs/Domains** — Web resources involved Click any entity icon to: * View entity details * See other incidents involving this entity * Access available response actions ### Tabs Overview of the incident including description, timeline summary, and key indicators. Detailed list of all affected entities with expandable details and cross-incident correlation. Team collaboration space. Add investigation notes and view comments from other analysts. Complete audit trail of all actions taken on this incident, including previously run Gamebooks. *** ## Building a Gamebook Gamebooks are response workflows you build or agents can build by selecting response actions for each affected entity. ### Step 1: Select an Entity Left-click an entity icon in the Entity Context Graph. The response actions appear already mapped to the entity type selected. Entity action carousel ### Step 2: Browse Available Actions By left-clicking entities, you will be able to utilize the following response actions: | Entity Type | Response Actions | | ----------- | ---------------------------------------------------------------------------------- | | **User** | Invalidate sessions, lockout user, reset user password, reset MFA, and unlock user | | **Device** | Isolate device, run AV scan, unisolate device | | **IP** | Block Azure Network Security Group (NSG) | | **File** | Quarantine file, block hash | Available actions depend on the entity type and your connected modules. Gamebook response actions automatically map to actions that are relevant and executable. ### Step 3: Add Actions to Gamebook * Click the **+ icon** to add a response action to your Gamebook * Hover over the action in the Gamebook and the **red - icon** will remove a response action * Repeat for each entity you want to take action on Gamebook with actions added ### Step 4: Review Your Gamebook As you add actions, they load in the **Gamebook card**. ### Step 5: Execute the Gamebook Verify all actions in the Gamebook are correct Execute all actions in the Gamebook Status updates from "Pending" to "Running" to "Finished" Gamebook execution complete *** ## Gamebook Approval Workflow Some Gamebooks require approval before execution, indicated by a \*\*Approve \*\*button in the Gamebooks page or in the Gamebook within the Workbench. Actions with approval requirements are typically high-impact operations like device isolation or reset user password. This prevents accidental execution. ### Requesting Approval 1. Build your Gamebook as usual (including locked actions) 2. Click **Request Gamebook Approval** instead of Run Gamebook 3. The request is sent to users with approval permissions ### Approving Gamebooks Approvers can approve requests from: * **The incident itself** — Open the incident and approve directly * **Gamebook Activity tab** — Review all pending approvals in one place Gamebook Activity Approval * **Gamebook Activity page** — Review all pending approvals in one place Gamebook Page Approvals Loading previous Gamebooks is especially useful for recurring incident types. Build a response once, reuse it across similar incidents. ## Gamebook Activity Page Track all Gamebooks in one queue across your every workspace from the dedicated **Gamebooks Page**. Gamebook Activity page ### What You Can See | Column | Description | | --------------- | ------------------------------------ | | **Status** | Success, Failed, Pending Approval | | **Incident** | Linked incident ID | | **Actions** | What actions were performed | | **Time to Run** | Execution duration | | **Workspace** | Which tenant the actions ran against | ### Expanding Details Click any row to expand and see: * Individual action results * Error messages (if any failed) * Timestamps for each step * Entity details ## Best Practices Focus your initial response on the most critical entities—compromised users, infected devices, or malicious IPs that pose immediate risk. Add comments as you investigate. This creates a record for your team and helps with post-incident review. Always review the complete Gamebook Card before clicking Run. Verify you're taking action on the correct entities. Before building a new Gamebook, check the History tab. A previous response may already exist that you can reuse or adapt. Regularly check the Gamebook Activity page to ensure actions completed successfully and catch any failures early. *** ## Related Guides Deep dive into Gamebook capabilities. Complete incident workflows. Available entity enrichment data. Classify incidents after resolution. *** Need help with the Security Workbench? Contact us at [support@contraforce.com](mailto:support@contraforce.com) # Workspace Environments Source: https://docs.contraforce.com/guides/getting-started/workspace-environments Review the users, licenses, and endpoints ContraForce can see in a workspace, and confirm which response actions its connections actually support. The **Environments** tab on a workspace's settings page shows what ContraForce can actually see inside that customer's tenant: which identities and licenses exist, which endpoints are onboarded, and which response actions the current connections support. Environments is a read-only view. Nothing on this tab changes a customer's configuration, and no user or device data is stored by ContraForce. Every list is fetched live from the provider when you open the page. ## When to use it Confirm endpoints are onboarded and licenses are in place before declaring a workspace live See at a glance whether a response action is unavailable because of licensing or a missing module Find devices that could be onboarded to Defender but are not See how many seats of each security license are assigned ## Opening the tab From the [Workspace Center](/guides/getting-started/workspace-manager), click a workspace card to open its settings page Select the **Environments** tab Click any row to drill into that provider's detail view The landing view lists every connected environment for the workspace. | Column | What it shows | | ---------------- | ----------------------------------------------------------------------------------- | | **Environment** | Microsoft, CrowdStrike, or SentinelOne | | **Connections** | Which products that environment contributes | | **Status** | **Connected** when the underlying module is configured, otherwise **Not connected** | | **Last updated** | When inventory for that environment was last collected | Only providers with a configured detection module appear. If a workspace shows **No environments connected**, no detection module has been set up for it yet. *** ## Microsoft The Microsoft environment is split into two cards. ### Microsoft Entra ID Three counters summarise the directory: | Counter | Meaning | | ------------------ | ------------------------------------------------- | | **Total users** | Every user account in the tenant directory | | **Enabled users** | Accounts that are not disabled | | **Licensed users** | Accounts holding at least one license of any kind | Below the counters are two tabs. **Licenses** lists the tenant's security-relevant subscriptions with seat usage, for example *Microsoft 365 E5 — 7 of 7 assigned*. Assigned seat counts come from Microsoft's own tenant-wide totals, so they match what the Microsoft 365 admin center reports. The list is deliberately filtered to security-relevant SKUs; unrelated subscriptions are not shown. **Users** lists directory accounts with their user principal name, enabled state, and whether they hold a license. Filter by **Licensed** or **State**, or search by name or user principal name. Search queries the complete directory, not just the rows on screen. Large tenants show a sample in the table with a note saying so, but searching still finds any matching user. The card also reports **Product Detected** for Entra ID Protection, and lists the **Identity gamebook capabilities** available in this workspace: invalidate existing sessions, lockout user, reset MFA, reset user password, and unlock user. ### Microsoft Defender Three counters summarise endpoint coverage: | Counter | Meaning | | -------------------- | -------------------------------------------------------------- | | **Total endpoints** | Devices known to Defender | | **Onboarded** | Devices reporting into Defender | | **Can be onboarded** | Devices Defender has discovered but that are not yet reporting | **Can be onboarded** is the most useful number on this tab for finding coverage gaps. These are real devices Defender already knows about that are not yet protected. The endpoint table lists each device with its operating system, health, onboarding state, and last seen time, and is searchable by name, OS, or status. Underneath, the card shows **Defender products detected**, the state of **Native automations** (AIR, ZAP, and attack disruption), and the **Defender gamebook capabilities** available: isolate endpoint, release from isolation, scan endpoint, and quarantine file. ## CrowdStrike and SentinelOne Each shows total, active, and contained endpoint counts, a searchable endpoint table with platform, agent version, status, and last seen, and the response gamebook capabilities its connection supports. ## Reading capability states Every capability row carries a state. | State | Meaning | | ----------------- | -------------------------------------------------------------------------- | | **Available** | The action can be dispatched in this workspace today | | **Not connected** | The gamebook module providing the action is not connected | | **Not licensed** | The tenant's licensing does not include the action | | **Not observed** | Applies to native automations: ContraForce has not seen this mechanism act | A capability marked **Not licensed** cannot be enabled from ContraForce. It requires a licensing change in the customer's Microsoft tenant. ## Refreshing Each card has a **Refresh** button that re-collects inventory immediately, and a **Last collected** timestamp beneath it. Refresh requires the **Owner** or **Content Admin** workspace role; everyone who can open the workspace settings page can read the tab. *** ## Permissions and consent Directory inventory reads through the **Microsoft Defender XDR** module's connection, so that module must be connected before the Entra ID card shows anything. If it is not, the card explains that instead of showing counters. ContraForce reads the directory with two Microsoft Graph application permissions on the Defender XDR app registration: | Permission | Used for | | ----------------------- | ------------------------------------- | | `Organization.Read.All` | License subscriptions and seat counts | | `User.Read.All` | User counts and the directory listing | Both are read-only. Neither allows ContraForce to modify users, licenses, or the tenant. ### Granting the directory permission Tenants that connected Defender XDR before this permission was introduced need to reconsent the module once. Until they do, the Entra ID card shows a **Microsoft Defender consent required** notice in place of the counters. Go to the workspace's **Environments** tab and open the **Microsoft** environment In your own tenant, click **Grant consent** to be taken to the Microsoft consent screen. For a managed customer's tenant, click **Copy consent link** instead and send it to that tenant's administrator. A partner administrator cannot consent inside a customer's directory. A Global Administrator or Privileged Role Administrator reviews and approves the permissions You are returned to the Environments tab and the counters populate Consent must be granted by a **Global Administrator** or **Privileged Role Administrator** in the tenant being consented. Other roles cannot approve application permissions. Because these are application permissions, Microsoft shows the Defender XDR app registration's full permission set on the consent screen rather than only the new entry. Approving does not add anything beyond what the app registration declares. The same list is shown on the module's configuration page under **Microsoft Graph**. ## Troubleshooting Directory inventory is read through the Defender XDR connection. Connect that module on the workspace's **Modules** tab, then return to Environments. The module was consented before the directory permission was added. Follow the consent steps above to reconsent it once. Click **Refresh** on the Entra ID card. If it persists, confirm the approval completed in Microsoft and that it was granted in the correct tenant. Your account has no role on this workspace. A workspace owner needs to grant you access. Refreshing the page will not change this. Large tenants are capped for page performance and show a note saying so. Use the search field, which queries the provider's complete inventory. ## Related Manage workspaces, modules, and per-workspace settings Which capabilities each Microsoft license tier unlocks The app registrations ContraForce uses and what each one needs How consent works across the platform # Workspace Center Source: https://docs.contraforce.com/guides/getting-started/workspace-manager Manage customer tenants, pre-onboard new customers, monitor workspace health, and configure modules from one central location. The **Workspace Center** is your administrative control panel for every customer tenant. Monitor active workspaces at a glance, pre-onboard new customers, and drill into per-workspace settings. Workspaces represent individual customer tenants in ContraForce. Each workspace has its own data, configurations, modules, and user permissions. ## What Can You Do Here? Create workspace placeholders before customer admins complete their setup Edit module settings, integrations, and access from the per-workspace settings page See which workspaces are healthy, need attention, or are still onboarding Manage module consents and workspace-level access *** ## Accessing the Workspace Center Find the **Workspaces** icon in the left navigation bar Click the icon to open the Workspace Center Workspaces icon in the left navigation ## Workspace Center Overview The Workspace Center is split into two tabs and a row of rollup KPI cards. Workspaces overview ### Rollup KPI cards The cards at the top of the page show counts at a glance and are clickable shortcuts. | Card | What it shows | What clicking does | | ------------------------ | ---------------------------------------------------------------- | ------------------------------------------------------------------ | | **Workspaces connected** | Active customer workspaces in a healthy state | Switches to the Workspaces tab with the **All** filter | | **Need attention** | Active workspaces that have a missing module or undeployed agent | Switches to the Workspaces tab with the **Needs attention** filter | | **Onboarding** | Pre-onboarded workspaces awaiting customer admin setup | Switches to the Onboarding tab | ### Tabs | Tab | What it contains | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Workspaces** | Active customer workspaces. Search, filter by health, and click a card to open its settings page | | **Onboarding** | Pre-onboarded workspaces awaiting customer admin setup. Add a new workspace from here, or click an existing card to see its onboarding progress | *** ## Workspace Cards Each workspace renders as a card. Click any card to open its settings page (no gear or equalizer button needed). Workspace card ### What's on a card | Element | Description | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | **Status light** (top-right corner) | Green: healthy. Amber: needs attention. Blue: pre-onboarded. Hidden on the service provider's own workspace | | **Workspace name** | The customer's friendly name | | **Tenant ID** | The customer's Microsoft Entra tenant ID, in muted text below the name | | **Inline chip** | "Your workspace" on the service provider's own card; "Service provider" if the row represents the MSP itself with no monitoring on it | | **Modules pill** | Visible on the Workspaces tab. Healthy when at least one detection module is configured | | **Agent pill** | Visible on the Workspaces tab. Healthy when an Agent Center is deployed | Health pills only appear on the Workspaces tab. The Onboarding tab uses the blue **pre-onboarded** status light instead, since health checks are not meaningful until the customer admin completes their onboarding. *** ## Search and Filter Both tabs include a **Search by workspace name** field that filters cards as you type. The Workspaces tab also has filter chips: | Filter | Description | | ------------------- | ----------------------------------------------------------------------------- | | **All** | Every active workspace, regardless of health | | **Needs attention** | Active workspaces with a missing detection module or no deployed Agent Center | | **Healthy** | Active workspaces with both a detection module and an Agent Center deployed | The Onboarding tab does not have filter chips. Use search to narrow the list when you have many pre-onboarded workspaces. *** ## Opening Workspace Details Click any card to open the workspace's settings page. Workspace details The settings page exposes four areas: * **General** 1. **Account Information and Service Provider Information**: account identifiers, points of contact, account ID, account type, and subscription information 2. **Allow Service Providers to Run Gamebooks**: manage the team members responsible for approving Gamebooks that require manual authorization. Only users with the Workspace Owner role can be assigned as Gamebook Approvers * **Modules**: configure and manage detection and response modules * **IAM**: manage users, groups, and permissions at the workspace level * **Notifications**: configure the notifications module for Microsoft Sentinel *** ## Pre-Onboarding a Customer Workspace Pre-onboarding lets you prepare a customer's workspace before they complete onboarding themselves. The customer admin receives an invite email and finishes the rest. See [Customer Workspace Onboarding](/guides/onboarding/customer-workspace-onboarding) for the customer-side flow. ### Why pre-onboard? Configuration is ready when the customer is Verify settings before the customer is invited Schedule onboardings in advance ### Creating a pre-onboarded workspace Click the **Onboarding** tab at the top of the Workspace Center The button is in the top-right of the toolbar. The right-hand rail panel opens with the **Add workspace** form Preonboard customer workspace | Field | Description | | ---------------------------------- | ---------------------------------------------------------- | | **Workspace name** | Friendly label you'll use to refer to this customer | | **Tenant ID** | The customer's Microsoft Entra tenant ID | | **Primary point-of-contact email** | The customer admin who will receive the invite | | **Detection modules** | Pre-select the security tools the customer is bringing | | **Response modules** | Pre-select the response capabilities the customer will use | ContraForce sends an invite email to the POC. The new workspace appears as a card on the Onboarding tab with a **Pending customer setup** badge Preonboarded customer workspace Click any pre-onboarded card to see its onboarding progress in the right-hand rail. Use this to confirm which modules the customer has connected so far. ### When the customer finishes onboarding You'll receive a real-time **Customer onboarding complete** notification in the portal. The card moves from the Onboarding tab to the Workspaces tab, and the status light flips from blue (pre-onboarded) to green (healthy) or amber (needs attention) based on what the customer connected. For the post-go-live verification runbook, see [Workspace Onboarding Verification](/guides/onboarding/workspace-onboarding-checklist). *** ## Module Management Each workspace can have different modules enabled based on customer needs. Open a workspace's settings page (click the card), then go to the **Modules** tab. ### Available modules | Module | Description | Key features | | ------------------------------- | ------------------------------ | ---------------------------------------------------------------------- | | Microsoft Defender for Endpoint | Microsoft Defender integration | Endpoint detection, response actions, device management | | Microsoft Sentinel | Microsoft Sentinel integration | Log analysis, custom alerts, threat hunting | | SentinelOne XDR | SentinelOne XDR integration | Read SentinelOne alerts and respond to SentinelOne endpoints | | CrowdStrike | CrowdStrike Falcon integration | CrowdStrike detection and response | | Notifications | Incident notification engine | Email notifications for Microsoft Sentinel incidents based on severity | ### Configuring modules Click the workspace card to open its settings page Navigate to the module you want to configure Enable or disable features, set thresholds, configure options Click **Consent** to authorize required permissions for the module Apply the configuration ### Module-specific settings Basic workspace settings: * Workspace name * Alias name * Domain * Points of contact * Email address * Subscription ID * Subscription type Enable or disable ContraForce modules: * Microsoft Sentinel (Detection + Response) Prerequisites to manage this module: * Microsoft Entra Role: Global Administrator (required to grant the module Consent) * ContraForce Workspace Role: Owner * Microsoft Subscription Permission: Owner You can access the Content Management System for Microsoft Sentinel by clicking the icon in the Microsoft Sentinel module. * Microsoft Defender for Endpoint (Detection + Response) Prerequisites to manage this module: * Microsoft Entra Role: Global Administrator (required to grant the module Consent) * ContraForce Workspace Role: Owner * SentinelOne XDR (Detection + Response) Prerequisites to manage this module: * ContraForce Workspace Role: Owner * Gamebooks for Defender XDR (Response for endpoints) * Gamebooks for Identity (Response for users) * Gamebooks for Microsoft 365 (Response for emails) * Gamebooks for Azure (Response for Azure NSG) * Gamebooks for SentinelOne (Response for endpoints) Group Management. Workspace Roles: * Owner * Content Admin * Incident Responder * Incident Analyst Use Role Management. User Roles: * Owner * Content Admin * Incident Responder * Incident Analyst Notification Settings: Prerequisites to manage this module: * ContraForce Workspace Role: Owner * Sentinel Module Configured Microsoft Sentinel Notifications Settings Based on Severity: * High * Medium * Low * Info *** ## Permission Consent Some features require explicit consent to Microsoft enterprise applications. ### Why consent is required ContraForce uses Microsoft Graph API and other APIs to: * Read security alerts and incidents * Execute response actions (isolate devices, disable users) * Access log data for analysis These permissions must be granted by a tenant administrator. ### Granting consent Click the workspace card to open its settings page Find the module that needs consent A Microsoft authentication window opens Sign in with a **Global Administrator** account. ContraForce uses app-only Microsoft Graph permissions, so Cloud App Admin or Application Admin cannot grant this consent Review the requested permissions and click **Accept** Consent requires **Global Administrator** privileges in the customer's Microsoft tenant. Work with your customer's IT team if you don't have Global Administrator access. Complete guide to platform users, groups, permissions, and modules *** ## Best Practices Name workspaces consistently (for example, "CustomerName: Primary") so they're easy to identify in search and filters. Create pre-onboarded workspaces before onboarding calls so the customer admin can complete their onboarding immediately. Periodically click the **Need attention** rollup card to surface workspaces missing a detection module or Agent Center. Token expirations or policy changes can affect access. Open a workspace's Modules tab to confirm everything still shows **Connected**. Keep records of which modules and settings are enabled for each customer for support and renewal conversations. *** ## Troubleshooting ### Common Issues | Issue | Possible cause | Solution | | ------------------------------------------------ | ----------------------------------------- | -------------------------------------------------------------------------- | | Workspace shows no data | Consent not completed | Re-run consent flow with admin credentials | | Module won't enable | Missing permissions | Verify required permissions are granted | | Pre-onboarded card never moves to Workspaces tab | Customer admin hasn't finished onboarding | Resend the invite or contact the POC | | Configuration won't save | Validation error | Check for required fields or invalid values | | Status light is amber | Detection module or Agent Center missing | Open the workspace card and complete the missing module or deploy an agent | If you encounter persistent issues with workspace configuration, contact [support@contraforce.com](mailto:support@contraforce.com) with the workspace name and error details. *** ## Related Guides Granting access, Agent Center, connecting your own sources What customer admins see after the invite email Post-go-live verification runbook Managing multiple workspaces *** Questions about the Workspace Center? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Deploying Agent Center Source: https://docs.contraforce.com/guides/onboarding/agent-center-deployment Deploy Microsoft Foundry infrastructure through ContraForce to enable automated security operations with Security Delivery Agents. The AI Agent Center enables you to deploy Microsoft Foundry infrastructure directly through ContraForce, powering automated incident investigation and response capabilities with Security Delivery Agents (SDAs). Agent Center leverages Microsoft Foundry to provision the AI infrastructure required for automated security operations. Once deployed, you can configure Security Delivery Agents to handle incidents automatically. ## What Can You Do Here? Provision Microsoft Foundry resources through ContraForce Deploy Security Delivery Agents for automated response Configure agents to investigate and respond to incidents Allow agents to execute response playbooks automatically *** ## Prerequisites Before deploying Agent Center, ensure you meet the following requirements. ### User Requirements | Requirement | Description | | ---------------------- | ----------------------------------------------------------------------------------------------- | | **Subscription Owner** | Owner-level access to the Azure subscription where Agent Center infrastructure will be deployed | | **ContraForce Role** | Organizational Admin or Agent Admin role in ContraForce | | **Provisioning** | Users do not need to be separately provisioned for ContraForce | ### Required Tooling | Tool | Purpose | | --------------------- | ------------------------------------------------------------- | | **Microsoft Foundry** | Microsoft Foundry platform for AI infrastructure provisioning | You must have Owner permissions on the Azure subscription to successfully deploy Agent Center infrastructure. Work with your Azure administrator if you don't have the required access. *** ## Deploying Agent Center Navigate to [portal.contraforce.com](https://portal.contraforce.com) and sign in with your credentials From the main dashboard, locate and select the **Agent Center** option Follow the on-screen prompts to configure and provision the Microsoft Foundry infrastructure in your environment Once infrastructure provisioning completes, deploy your first Security Delivery Agent (SDA) to begin automated incident handling The deployment process handles all Azure resource provisioning automatically. You don't need to manually configure Microsoft Foundry resources. *** ## Post-Deployment Configuration After successfully deploying Agent Center, configure your Security Delivery Agents to match your operational requirements. ### Configuration Options **Run agents on-demand:** * Select individual incidents for investigation * Choose between investigation-only or investigation with response * Review agent findings before taking action **Configure severity-based automation:** * Set agents to run automatically on new incidents * Filter by incident status (New, Active, Closed) * Define which severity levels trigger automatic execution **Enable automatic response actions:** * Allow agents to execute gamebooks * Set confidence thresholds for automated actions * Control which response types are permitted *** ## Best Practices Confirm you have Subscription Owner access before starting the deployment process to avoid interruptions. Begin with Phase 1 (manual execution) to understand how agents analyze your specific incident types before enabling automation. Monitor agent investigation results to ensure accuracy and tune configurations as needed. Keep records of your Agent Center settings for troubleshooting and future reference. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | --------------------------------- | ------------------------------ | ------------------------------------------------------------------- | | Deployment fails | Insufficient Azure permissions | Verify Subscription Owner access | | Agent Center not visible | Missing ContraForce role | Confirm Organizational Admin or Agent Admin role assignment | | Infrastructure provisioning stuck | Azure resource limits | Check Azure subscription quotas and limits | | SDA deployment fails | Prerequisites incomplete | Ensure Microsoft Foundry infrastructure deployed successfully first | If you encounter persistent issues with Agent Center deployment, contact [support@contraforce.com](mailto:support@contraforce.com) with your subscription details and error messages. *** ## Related Guides Set up automated incident investigation and response Learn about automated response playbooks Overview of incident handling in ContraForce Understanding ContraForce role requirements *** Questions about Agent Center deployment? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Content Management System Source: https://docs.contraforce.com/guides/onboarding/cms-module This guide walks you through setting up and using the Content Management System (CMS) to deploy expert-authored detection rules to your Microsoft Sentinel environments. By the end, you'll have comprehensive threat detection coverage across your workspaces. CMS requires the **Microsoft Sentinel module**. If you only have the Defender module deployed, you'll need to upgrade before using CMS. See [Module Overview](/guides/onboarding/contraforce-module-overview) for details. ## Before You Begin ### Prerequisites Ensure you have the following before starting: Your workspace must have the Microsoft Sentinel module deployed with Microsoft Sentinel connected You need **Data Source Admin**, **Content Admin**, or **Organization Admin** role in ContraForce Your ContraForce service principal must have appropriate permissions in the target Sentinel workspace Data connectors should be configured for the data sources you want detection rules for ### Required Roles | ContraForce Role | Can Deploy Rules | Can Enable Auto-Update | Can Remove Rules | | ---------------------- | :--------------: | :--------------------: | :--------------: | | **Organization Admin** | ✓ | ✓ | ✓ | | **Content Admin** | ✓ | ✓ | ✓ | | **Data Source Admin** | ✓ | ✓ | ✓ | | **Incident Responder** | — | — | — | | **Incident Analyst** | — | — | — | View complete permissions for all roles *** ## Step 1: Access the Content Management System From the ContraForce navigation menu, click **Content Management** or **CMS** If you manage multiple workspaces, select the workspace you want to configure from the dropdown The CMS dashboard displays available data sources and deployment status CMS dashboard overview *** ## Step 2: Understand the CMS Interface ### Dashboard Overview The CMS interface is organized by data source, with each section showing: | Element | Description | | --------------------- | --------------------------------------------------------- | | **Data Source Name** | The telemetry source (e.g., Azure AD, Microsoft 365) | | **Available Rules** | Total number of detection rules available for this source | | **Deployed Rules** | How many rules are currently active in your workspace | | **Updates Available** | Rules with newer versions ready to deploy | ### Rule List View Clicking into a data source shows all available rules: CMS rule list view | Column | Description | | ----------------- | ------------------------------------------- | | **Toggle** | Enable/disable switch for the rule | | **Rule Name** | Detection rule display name | | **Severity** | Low, Medium, or High | | **MITRE Tactics** | ATT\&CK framework mapping | | **Version** | Current rule version (CalVer format) | | **Status** | Deployed, Not Deployed, or Update Available | | **Auto-Update** | Whether automatic updates are enabled | ### Rule Details Click any rule to view complete details: * Full description of what the rule detects * MITRE ATT\&CK tactics and techniques * Query frequency and time period * The actual KQL query (for transparency) * Version history and changelog *** ## Step 3: Review Your Data Connectors Before deploying rules, verify which data sources are active in your Sentinel workspace. Rules deployed for data sources without active connectors will never trigger. Only enable rules for data sources you have connected. ### Check Data Connector Status Go to the **Data Connectors** page in ContraForce Note which connectors show "Connected" status Map your connected sources to CMS data source categories ### Common Data Source Mappings | Connector | CMS Data Source Category | | ------------------------------- | ------------------------ | | Azure Active Directory | Azure AD / Entra ID | | Microsoft 365 | Microsoft 365 | | Microsoft Defender for Endpoint | Windows Security Events | | Azure Activity | Azure Activity | | Azure Security Center | Azure Security Center | | Syslog | Linux Syslog | *** ## Step 4: Deploy Your First Detection Rules Start with a focused deployment to familiarize yourself with the process. ### Recommended Starting Point We recommend starting with **Azure AD / Entra ID** rules if you have that connector active. These rules detect: * Suspicious sign-in activity * Privilege escalation attempts * Conditional access policy changes * Service principal abuse * And more identity-based threats ### Deploying Rules Click on **Azure AD** (or your chosen data source) in the CMS dashboard Browse the list of available detection rules Click on a few rules to understand what they detect and their severity Toggle the switch to **Enabled** for rules you want to deploy Watch the status indicator—it will show "Deploying" then "Deployed" Enabling a detection rule ### Deployment Status Indicators | Status | Meaning | | -------------------- | --------------------------------------------------- | | **Not Deployed** | Rule is available but not active | | **Deploying** | Rule deployment in progress | | **Deployed** | Rule is active in your Sentinel workspace | | **Failed** | Deployment encountered an error (click for details) | | **Update Available** | Newer version exists for a deployed rule | Start with 5-10 high-severity rules to validate the deployment process before enabling broader coverage. *** ## Step 5: Bulk Deployment (Optional) Once comfortable with individual deployments, you can enable multiple rules at once. ### Enable All Rules for a Data Source Navigate to the data source category Click **Enable All** or use the bulk selection checkboxes Review the rules to be deployed and confirm The dashboard shows deployment progress for all rules ### Bulk Deployment Considerations Consider enabling only High and Medium severity rules initially to minimize noise while you tune your environment. For large deployments, consider enabling one data source category at a time. This makes it easier to identify which rules generate the most valuable alerts. After bulk deployment, monitor incident volume for a few days. Disable rules that generate excessive false positives while you investigate. *** ## Step 6: Configure Automatic Updates Keep your detection rules current by enabling automatic updates. ### Understanding Auto-Update When enabled, CMS automatically deploys new rule versions when they're released: * **Security improvements** — Updated logic to catch new attack variants * **False positive reduction** — Refined queries to reduce noise * **Performance optimization** — More efficient queries that run faster ### Enabling Auto-Update Enable auto-update for individual rules: Click on a deployed rule to view its details Enable the **Auto-Update** switch The rule will now automatically update when new versions are released Enable auto-update for multiple rules: Use checkboxes to select multiple deployed rules Click **Enable Auto-Update** from the bulk actions menu All selected rules will auto-update going forward Set auto-update as the default for all new deployments: Navigate to CMS Settings or Workspace Settings Toggle **Auto-Update by Default** to enabled All newly deployed rules will have auto-update enabled **When to disable auto-update:** If you have strict change management requirements, disable auto-update and manually review each update before deploying. The "Update Available" indicator will alert you to new versions. *** ## Step 7: Deploy to Additional Workspaces For MSSPs managing multiple customers, replicate your detection coverage across workspaces. ### Multi-Workspace Deployment Go back to the main CMS dashboard Use the workspace selector to switch to another customer Enable the same rules for consistency across your customer base ### Deployment Templates (Coming Soon) ContraForce is developing deployment templates that let you define a standard rule set and deploy it across multiple workspaces simultaneously. Contact [support@contraforce.com](mailto:support@contraforce.com) to express interest. *** ## Step 8: Verify Deployment in Sentinel Confirm your rules are active in Microsoft Sentinel. ### Verification Steps Navigate to your Microsoft Sentinel workspace in the Azure portal Click **Analytics** in the Sentinel navigation Click the **Active rules** tab Search for rules deployed by CMS—they'll have consistent naming ### What to Look For | Verification Point | Expected Result | | ------------------------ | ----------------------------------------------- | | Rule exists in Analytics | Rule appears in Active rules list | | Rule is enabled | Status shows "Enabled" | | Rule is running | "Last run" shows recent timestamp | | Rule configuration | Query, frequency, and period match CMS settings | *** ## Post-Deployment Checklist After completing your initial CMS deployment: Record which rules you've enabled for each workspace Configure [incident notifications](/guides/technical/contraforce-notifications) for new Sentinel incidents Watch the Command Page for new incidents generated by your rules Assess which rules are generating value vs. noise Disable noisy rules or work with ContraForce to improve detections Enable additional data sources and rules as you gain confidence *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ------------------------ | ---------------------- | ----------------------------------------------------- | | **Deployment fails** | Permission issue | Verify Sentinel API permissions are granted | | **Deployment fails** | Azure API unavailable | Wait and retry—temporary outages happen | | **Rule never fires** | No matching data | Verify data connector is active and sending logs | | **Rule never fires** | Query period too short | Check if relevant events occurred in the query window | | **Too many incidents** | Rule too broad | Consider disabling or requesting rule tuning | | **Can't see CMS option** | Wrong module | Verify XDR + SIEM module is deployed | | **Can't deploy rules** | Insufficient role | Request Data Source Admin or higher role | ### Getting Help If you encounter issues: 1. **Check the error message** — CMS provides detailed error information 2. **Verify permissions** — Ensure your role allows rule deployment 3. **Check Sentinel access** — Confirm the ContraForce service principal has API access 4. **Contact support** — Email [support@contraforce.com](mailto:support@contraforce.com) with workspace details *** ## Recommended Deployment Strategy ### Phase 1: Foundation (Week 1) Focus on identity and access: * ✅ Azure AD / Entra ID rules (all severities) * ✅ Enable auto-update for these rules * ✅ Monitor for 5-7 days ### Phase 2: Expand (Week 2) Add Microsoft 365 and Azure infrastructure: * ✅ Microsoft 365 rules * ✅ Azure Activity rules * ✅ Azure Security Center rules ### Phase 3: Complete (Week 3+) Enable remaining data sources: * ✅ Windows Security Events * ✅ Linux Syslog * ✅ Network Security Groups * ✅ DNS Analytics * ✅ Any additional connected sources ### Phase 4: Optimize (Ongoing) Continuous improvement: * Review incident quality weekly * Disable low-value rules * Enable new rules as they're released * Ensure auto-update is enabled for standard rules *** ## Next Steps Deep dive into CMS capabilities Handle incidents generated by CMS rules Configure alerts for new incidents *** Questions about CMS onboarding? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Module Overview Source: https://docs.contraforce.com/guides/onboarding/contraforce-module-overview Users have the option to deploy two different modules when they onboard ContraForce to their environment. This article will cover what is included in each module. ## Overview ContraForce has two modules that can be selected during the deployment process. There is the Defender module and then there is the XDR + SIEM module. Each module supports different products and can be selected based on the needs of the environment. Detection sources are managed from the **Detection modules** section of a workspace. ContraForce's XDR detection modules include **Microsoft Defender XDR**, **CrowdStrike Falcon**, and **SentinelOne**; the XDR + SIEM module adds **Microsoft Sentinel**. Each module shows whether it is **Configured** and **Enabled**, and you can add modules with **Add Module**. Detection modules ### ContraForce Defender Module The ContraForce Defender module supports onboarding environment where Defender for Endpoint has been deployed. The onboarding guide for the Defender module can be found [here](/guides/onboarding/defender-for-endpoint-module-deployment). When the Defender module is deployed, the following ContraForce features are not available: * SIEM Incidents * Sentinel Advanced Threat Hunting **Defender Module Notifications** Email notifications will not be generated by ContraForce for new incidents in the Defender for Endpoint Module. Email notifications will be sent for Gamebook runs in ContraForce. Deployment of ContraForce will not interrupt the existing Defender notification configuration. More information about Contraforce notifications can be found [here](https://docs.contraforce.com/knowledge/contraforce-notifications). ## ContraForce XDR + SIEM Module The ContraForce XDR + SIEM module expands on the Defender module as the XDR + SIEM includes the Defender module as well as support for Microsoft Sentinel and more. The onboarding guide for Microsoft Sentinel can be found [here](https://docs.contraforce.com/knowledge/bring-your-sentinel-contraforce-deployment-overview). Onboarding of a XDR + SIEM module unlocks the functionality of the XDR + SIEM Incidents and Sentinel Advanced Threat Hunting pages. Additionally, onboarding a XDR + SIEM module allows the user to customize notifications per workspace from the **Notifications** tab of the workspace settings. Incident notifications can be toggled by severity (High, Medium, Low, Info), with the recipients who receive them listed below. Incident notification preferences Gamebook notifications can be toggled by event (Gamebook ran, Gamebook queued), with their own recipient list. Gamebook notification preferences If you have any questions about the modules deployed by ContraForce, please feel free to contact us at [support@contraforce.com](mailto:support@contraforce.com). # CrowdStrike Falcon Detection and Response Modules Source: https://docs.contraforce.com/guides/onboarding/crowdstrike-detection-and-response-modules Connect the CrowdStrike Falcon Detection and Response modules to a ContraForce workspace to ingest Falcon detections as incidents and enable endpoint response actions. **Who is this for?** Workspace Admins or Security Engineers who manage a workspace that uses CrowdStrike Falcon. This guide walks you through creating the CrowdStrike API clients, configuring both modules in ContraForce, and verifying that alerts flow end-to-end. ## Before You Begin ### What These Modules Do CrowdStrike integrates with ContraForce through two separate modules: **Detection ingestion and investigation** * Pulls Falcon detections from the CrowdStrike Alerts API * Surfaces every detection as its own ContraForce incident * Round-trips status changes and comments back to Falcon **Gamebook response actions** * Powers Contain and Lift Containment Gamebooks * Powers On-Demand Scan Gamebooks * Required for any Gamebook that acts on a CrowdStrike-managed device The two modules use separate CrowdStrike API clients so each client has only the scopes it needs. ### Prerequisites An active CrowdStrike Falcon subscription with at least one product line in scope (EPP, IDP, or any of the product lines listed in **Select Alert Types** below). Access to **API Clients and Keys** under **Support and resources → Resources and tools** in the Falcon console. This typically requires the Falcon Administrator role. A ContraForce workspace created for the tenant, with your account assigned the **Workspace Admin** role. Identify which CrowdStrike cloud your tenant is deployed in. You need this for the **Base URL** field when configuring each module. ### CrowdStrike Cloud Base URLs CrowdStrike has multiple regional clouds. Use the Base URL that matches your tenant: | Cloud | Base URL | | ----------------- | ---------------------------------- | | US-1 (Commercial) | `https://api.crowdstrike.com` | | US-2 | `https://api.us-2.crowdstrike.com` | | EU-1 | `https://api.eu-1.crowdstrike.com` | ContraForce does not currently support CrowdStrike's US-GOV-1 cloud. Contact [support@contraforce.com](mailto:support@contraforce.com) if you have a GovCloud tenant. You can confirm which cloud your tenant is in by looking at the URL of your Falcon console. A console URL of `https://falcon.us-2.crowdstrike.com` means you're on US-2. *** ## Step 1 — Create the Detection API Client in Falcon The scopes you grant on the Detection API client depend on which **Falcon tier** the customer is licensed for. Pick the matching column below — the tier you choose here must match what you select on the ContraForce configuration page in Step 3. 1. Navigate to **Support and resources → Resources and tools → API Clients and Keys** in the Falcon console 2. Click **Create API client** 3. Set **Client name** to `ContraForce Detection` 4. Set **Description** to `ContraForce alert ingestion and status writeback` 5. Under **API scopes**, grant the scopes for the customer's tier, then click **Create**: For tenants on **Falcon Insight (EDR) only.** Cases workbench is not available on this tier. | Resource | Permission | Why | | ----------------------------------- | ------------ | ----------------------------------------- | | **Alerts** | Read + Write | Ingest detections and update their status | | **User Management** | Read | Resolve assignee names on detections | | **Hosts** | Read | Resolve device metadata on detections | | **IOCs (Indicators of Compromise)** | Read | Resolve IOC context on alert entities | For tenants licensed for **Falcon Insight XDR.** Cases workbench is active. | Resource | Permission | Why | | ----------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------- | | **Alerts** | Read + Write | Ingest detections and update their status | | **Cases** | Read + Write | Resolve case context for detections that reference a case (used by detail views and reserved for upcoming Cases features) | | **User Management** | Read | Resolve assignee names on detections | | **Hosts** | Read | Resolve device metadata on detections | | **IOCs (Indicators of Compromise)** | Read | Resolve IOC context on alert entities | For tenants licensed for **NG-SIEM.** Same detection-as-incident shape as the other tiers, plus the LogScale-backed Process Tree ancestor walk and Events Timeline are unlocked. | Resource | Permission | Why | | ----------------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------- | | **Alerts** | Read + Write | Ingest detections and update their status | | **Cases** | Read + Write | Resolve case context for detections that reference a case (used by detail views and reserved for upcoming Cases features) | | **User Management** | Read | Resolve assignee names on detections | | **Hosts** | Read | Resolve device metadata on detections | | **IOCs (Indicators of Compromise)** | Read | Resolve IOC context on alert entities | | **NGSIEM** | Read + Write | Run LogScale searches for Process Tree and Events Timeline. Write is needed to start search jobs | Copy the **Client ID** and **Client Secret** to a secure location — the secret is only shown once. The Client Secret is shown once at creation time and cannot be retrieved later. If you lose it, you must reset the secret from the same API client in Falcon. *** ## Step 2 — Create the Response API Client in Falcon Repeat the process for a second API client that ContraForce will use for Gamebook response actions. 1. In the same **API Clients and Keys** menu, click **Create API client** 2. Set **Client name** to `ContraForce Response` 3. Set **Description** to `ContraForce Gamebook response actions` 4. Under **API scopes**, grant the scopes listed below, then click **Create**: | Resource | Permission | | ------------------------- | ------------ | | **Hosts** | Read + Write | | **On-Demand Scans (ODS)** | Read + Write | Copy the **Client ID** and **Client Secret** for the Response client. Creating two separate API clients — one for Detection, one for Response — follows the principle of least privilege. The Detection client never needs to contain a device or run a scan, and the Response client never needs to read an alert. *** ## Step 3 — Configure the CrowdStrike Falcon Module in ContraForce 1. In the ContraForce portal, navigate to **Workspaces** → your workspace → **Modules** 2. Locate the **CrowdStrike Falcon** card and click **Configure** 3. Pick the **Falcon licensing tier** that matches the customer's CrowdStrike SKU. The required-scopes list, the incidents-table preview copy, and the verification panel all update based on this selection: | Tier | When to pick it | Effect on the platform | | ------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Falcon Insight (EDR)** | Customer is on Falcon Insight (EDR) only — no Cases workbench, no NG-SIEM SKU | Each Falcon detection becomes its own incident in the table | | **Falcon Insight XDR** | Customer is licensed for XDR with Cases workbench but no NG-SIEM SKU | Each Falcon detection becomes its own incident; case context is resolvable on detections that reference a case | | **Falcon NG-SIEM** | Customer is licensed for NG-SIEM | Same detection-as-incident shape, plus LogScale-backed Process Tree ancestor walk and Events Timeline are unlocked | The tier you pick must match the customer's actual Falcon SKU. The required scopes and which advanced features (Process Tree ancestor walk, Events Timeline) unlock depend on the tier — see [CrowdStrike Falcon Integration → Tier Selection](/guides/technical/crowdstrike-falcon-integration#tier-selection-—-what-you-pick-on-the-configuration-page) for the full breakdown. 1. Fill in the following fields: | Field | Value | | ----------------- | ----------------------------------------------------------------- | | **Base URL** | The Base URL for your CrowdStrike cloud (see table above) | | **Client ID** | The Client ID from the Detection API client you created in Step 1 | | **Client Secret** | The Client Secret from the Detection API client | 1. Click **Test Connection** to verify the credentials reach CrowdStrike and have the scopes the selected tier requires 2. Review the **Verification panel** that appears below the form: * ✓ on a row means the API client has that scope and the tenant exposes the corresponding capability * ✗ on a row means the scope or capability is missing for the tier you picked — fix it in the Falcon console before saving * ℹ︎ on a row means the API client has more capability than the tier you picked uses (e.g. NG-SIEM is reachable but you picked Falcon Insight XDR) — pick a higher tier to unlock the advanced features 3. Click **Save** If Test Connection fails with a scope-missing error, return to the Falcon console and verify the scopes listed in Step 1 for the tier you picked. ### What You'll See After Saving The configuration page surfaces a "What you'll see in the incidents table" preview directly under the tier dropdown, so you can confirm the choice before saving. After Save, the incidents table reflects that preview the next time the poller runs (typically within a few minutes). ### Tune Which Products Are Ingested (Optional) After the credentials are saved, an **Alert Types** card appears as a sibling to the Configuration Information card. Use it to narrow which CrowdStrike products ContraForce ingests into the analyst queue — useful when you're contracted to triage only a subset of the products the customer's Falcon tenant emits. | Product | Wire form | Surfaces | | ------------------------- | ------------ | ------------------------------------------------- | | **Endpoint (EPP)** | `epp` | Falcon Insight endpoint-protection detections | | **Identity (IDP)** | `idp` | Falcon Identity Protection alerts | | **Mobile** | `mobile` | Falcon for Mobile alerts | | **Data Protection** | `dp` | Falcon Data Protection alerts | | **NG-SIEM** | `ngsiem` | NG-SIEM correlation alerts | | **XDR** | `xdr` | Cross-platform correlated detections | | **Cloud Workload (CWPP)** | `cwpp` | Falcon Cloud Security workload-protection alerts | | **OverWatch** | `overwatch` | Falcon OverWatch managed-threat-hunting alerts | | **Third-Party** | `thirdparty` | Alerts ingested from integrated third-party tools | The card is **tier-aware** by default to cut UI noise: | Tier | Default checkbox shortlist | | ------------------------ | -------------------------- | | **Falcon Insight (EDR)** | EPP | | **Falcon Insight XDR** | EPP, IDP, XDR | | **Falcon NG-SIEM** | All products | Click **Show all products** above the checkbox list (visible on EDR / XDR tiers) to reveal the full catalog when the customer has non-standard add-ons (e.g. EDR with the Mobile add-on). The toggle auto-defaults to "show all" when the persisted selection already includes products outside the tier shortlist. Saving the Alert Types card is **independent of Test Connection**. Changing the product selection does not require re-validating credentials or re-saving the Detection module — the card has its own Save button. Leaving every product checked, or unchecking every product, both fall through to "ingest all products." This preserves backwards-compatibility for workspaces created before the per-product filter shipped, and acts as a friendly fallback if you accidentally clear every box. ### Choose a Vendor-Side Service Account (Optional) By default, when one of your analysts takes a CrowdStrike-sourced incident in ContraForce, the assignment is recorded in the ContraForce audit log only and the underlying Falcon alert stays unassigned. This is the right default for tenants where every analyst already has a Falcon login, but in MSSP topologies most ContraForce analysts have no matching principal in the customer's Falcon tenant. The **Assignment Writeback** card lets you bind one CrowdStrike user (typically a named service account in the customer's Falcon tenant, e.g. `Stratascale ContraForce`) so that ContraForce mirrors every analyst assignment onto the underlying Falcon alert as that user. The end customer sees someone is actively engaged in their own Falcon console, without you having to provision a per-analyst account in every customer's tenant. | State | Behavior | | :----------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **None (default)** | Assignment is recorded in the ContraForce audit log only. No vendor write. | | **Bound** | The selected Falcon user is PATCHed onto the alert as the vendor-side assignee on every analyst assignment in ContraForce. Unassigning in ContraForce also clears the assignee on Falcon. | To bind a service account: On the Assignment Writeback card, click **Change**. ContraForce queries the customer's Falcon user-management API (this requires the **User Management: Read** scope on the Detection client, already part of every tier in Step 1). Type a name or email into the search box; the picker filters the live Falcon user list as you type. Pick the user that should appear as the assignee on the customer's Falcon console. Click **Save Service Account**. Future analyst assignments in ContraForce immediately mirror onto the underlying Falcon alert as the chosen user. To stop writing back, click **Remove** on the bound state, then **Save Service Account**. The card returns to **None** and the audit-only behavior resumes. The ContraForce audit log is always the source of truth for who actually picked up an incident, regardless of what shows on the Falcon side. The writeback only controls visibility in the customer's Falcon console. The writeback only affects detections (alerts that contain a colon-shaped composite ID). Legacy case-shaped IDs continue to behave as audit-only. If the Falcon PATCH fails (network blip, Falcon-side outage, the bound user was deleted), ContraForce records the failure in the trace logs and continues with the audit-only assignment so your queue stays responsive. *** ## Step 4 — Configure the CrowdStrike Falcon Response Module 1. On the same **Modules** page, locate the **CrowdStrike Falcon Response** card and click **Configure** 2. Fill in the following fields: | Field | Value | | ----------------- | -------------------------------------------------------------------- | | **Base URL** | Same Base URL as the Detection module | | **Client ID** | The Client ID from the **Response** API client you created in Step 2 | | **Client Secret** | The Client Secret from the **Response** API client | 1. Click **Test Connection** to verify the credentials reach CrowdStrike and have the required scopes 2. Click **Save** A successful test means Gamebook response actions are ready for CrowdStrike-managed devices. *** ## Step 5 — Verify End-to-End The Detection module polls CrowdStrike on a short interval. New alerts appear in ContraForce within a few minutes of being generated in Falcon. Navigate to the **Command Dashboard**. CrowdStrike incidents should appear alongside incidents from other sources. Click into a CrowdStrike incident and verify that the **Entities** and **Timeline** tabs are populated with alert data. If the Response module is configured, open a CrowdStrike incident where the affected entity is a device and confirm that **Contain**, **Lift Containment**, and **On-Demand Scan** Gamebook actions are available. *** ## What Each Module Unlocks | Capability | Requires Detection | Requires Response | | ----------------------------------------------------- | :----------------: | :---------------: | | Ingest CrowdStrike Falcon detections as incidents | ✓ | | | Round-trip status, assignment, and comments to Falcon | ✓ | | | Receive real-time incident updates in the portal | ✓ | | | Run Contain and Lift Containment Gamebooks | | ✓ | | Run On-Demand Scan Gamebooks | | ✓ | | Trigger Security Delivery Agents on new incidents | ✓ | | You can configure the Detection module without the Response module if you don't need Gamebook response actions for CrowdStrike devices. Configuring only the Response module without Detection is not a supported configuration — you'd have no incidents for the Gamebooks to run on. *** ## Troubleshooting | Issue | Likely cause | Fix | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Test Connection fails with `missing the 'Alerts: Read' scope` | The Detection API client does not have Alerts: Read granted | Return to **API Clients and Keys** in Falcon, edit the Detection client, enable **Alerts: Read**, and save | | Test Connection fails with `missing the 'Hosts: Write' scope` | The Response API client does not have Hosts: Write granted | Edit the Response client and enable **Hosts: Write** | | Test Connection fails with a generic OAuth error | The **Base URL** does not match the tenant's actual CrowdStrike cloud | Verify the Base URL against the cloud table above; cross-check against the Falcon console URL | | Verification panel shows ✗ on **Cases workbench** for XDR / NG-SIEM tier | The Detection API client does not have **Cases: Read + Write** granted | Edit the Detection client and add Cases: Read + Write, then re-run Test Connection. Without it, ContraForce can ingest detections normally but won't be able to resolve case context on detections that reference a case | | Verification panel shows ✗ on **NG-SIEM** for the NG-SIEM tier | The Detection API client does not have **NGSIEM: Read + Write** granted, or the tenant does not have the NG-SIEM SKU | Edit the Detection client and add NGSIEM: Read + Write; if the scope still doesn't appear in the Falcon console it means the tenant isn't licensed for NG-SIEM and you should pick the XDR tier instead | | Process Tree shows only the triggering process (no ancestors) | Tenant tier was set to EDR or XDR, or the NG-SIEM scope is missing | Confirm the customer is licensed for NG-SIEM and the tier dropdown reflects that; verify the NGSIEM scope on the Detection client | | Detection Events Timeline is empty on the NG-SIEM tier | NG-SIEM scope missing, or the alert's process lifetime predates the `base_sensor` retention horizon | Check the verification panel for ✗ on NG-SIEM; if the scope is fine, the older detection's events have aged out — see the [retention disclosure](/guides/technical/crowdstrike-falcon-integration#crowdstrike-data-retention-—-how-it-affects-the-platform) | | Incidents table is empty even though detections are firing in Falcon | Time filter or product filter on the queue is excluding everything; or the API client lost its **Alerts: Read** scope | Widen the date filter to a known-detection window, confirm Alerts: Read is still granted, and re-test the connection | | Gamebook response actions are greyed out | The Response module is not configured | Complete Step 4 to configure the Response module | | Agent comments do not appear in Falcon | The Detection API client does not have Alerts: Write | Add **Alerts: Write** to the Detection client | | Incident owner you assigned in ContraForce isn't reflected in Falcon | The Assignment Writeback card is set to **None** (the default), so the assignment is audit-only on the ContraForce side | Bind a Falcon service account on the Assignment Writeback card (see [Choose a Vendor-Side Service Account](#choose-a-vendor-side-service-account-optional)) and re-assign the incident | | Assignment Writeback card shows "Failed to load Falcon users" | The Detection API client does not have the **User Management: Read** scope | Edit the Detection API client in Falcon, add **User Management: Read**, and re-run Test Connection | | Bound service account no longer appears as the Falcon-side assignee | The bound user was disabled or deleted in the customer's Falcon tenant | Open the Assignment Writeback card, click **Change**, pick a still-active user, and save | ### Rotating an API Secret CrowdStrike secrets do not expire automatically, but some organizations rotate them on a schedule. 1. In Falcon, open the affected API client and click **Reset secret** 2. Copy the new secret 3. In ContraForce, reopen the affected module (Detection or Response) 4. Paste the new secret into **Client Secret** and click **Save** 5. Click **Test Connection** to verify *** ## Related Documentation What the integration does, what each tier unlocks, and how Falcon's retention shapes the data shown in the platform Learn how Gamebook response actions work Triage and resolve incidents in ContraForce Explore investigation context for an incident's entities Detailed role reference for ContraForce users *** Questions about connecting CrowdStrike Falcon to ContraForce? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Customer Workspace Onboarding Source: https://docs.contraforce.com/guides/onboarding/customer-workspace-onboarding Step-by-step guide for customer admins completing onboarding after their service provider has pre-onboarded their workspace. This guide is for **customer admins** whose service provider has pre-onboarded their workspace in ContraForce. You'll receive an invite email from your service provider. Click the link to start. **Who is this for?** * Customer security or IT admins finishing the workspace their MSP/MSSP started for them * Global Administrators in the customer's Microsoft Entra tenant who need to grant ContraForce access If your sign-in fails before you reach your workspace, jump to [Troubleshooting: Sign-in failed](#troubleshooting-sign-in-failed). *** ## Prerequisites | Requirement | Why | | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | **Microsoft Entra Global Administrator** | Required to grant ContraForce consent. Microsoft Graph app-only permissions can only be granted by a Global Administrator | | **Invite email from your service provider** | The link in this email is your onboarding entry point | | **Pop-ups allowed for `portal.contraforce.com`** | The Microsoft consent prompts open in a popup window | | **Azure Subscription Owner** | Only if you'll deploy the **Microsoft Sentinel** module, which deploys supporting Azure infrastructure | Granting consent requires a **Global Administrator**. Cloud App Admin and Application Admin roles cannot grant the app-only permissions ContraForce needs. If you aren't a Global Administrator, forward your invite link to a Global Admin in your organization and have them sign in instead. *** ## How onboarding works Your service provider has already created your workspace and pre-selected the **Detection** and **Response** modules you need. Your job is to sign in, grant ContraForce access to your tenant, and grant **Consent** for each module on the **Modules** tab. There's no completion screen to wait for. Your workspace is onboarded when its **status light turns green** on its card in the Workspace Center. Your service provider receives a real-time notification the moment your workspace goes live. *** ## Step 1: Grant ContraForce Access to Your Tenant When you click the link in your invite email, you'll be redirected to Microsoft to sign in. The first time anyone from your organization signs in, a Global Administrator must approve the core ContraForce app. ContraForce requests two core consents — **ContraForce API** and **ContraForce Portal** — as **two separate** Microsoft consent prompts. Accept both. Open the email from your service provider and click the onboarding link. You'll be taken to **portal.contraforce.com**. You'll be redirected to Microsoft. Sign in with your Global Admin credentials. Microsoft displays a consent screen listing the permissions ContraForce needs to read security data from your tenant. Check **Consent on behalf of your organization** and click **Accept**. Microsoft consent dialog showing ContraForce API permissions A second Microsoft consent prompt appears for the ContraForce Portal. Check **Consent on behalf of your organization** again and click **Accept**. Second Microsoft consent screen with the org-wide checkbox highlighted This is a one-time approval. Once a Global Admin grants both core consents, the rest of your team can sign in normally. *** ## Step 2: Consent to Your Modules After the core consents are granted, open your workspace and go to the **Modules** tab. The modules your service provider pre-selected are already listed for you — you just grant **Consent** for each one. From the Workspace Center, open the workspace your service provider created for you. Each pre-selected detection and response module appears here with a **Consent** action. A Microsoft consent window opens. Sign in if prompted, review the permissions, and click **Accept**. Consent is granted **per module** — repeat for each module on the tab. You can consent to modules in any order. **Microsoft Sentinel customers:** Consenting to the Sentinel module automatically deploys the supporting Azure infrastructure in your subscription, including the Azure Lighthouse delegation, the Apollo resource group, and the Sentinel-side automation. You don't need to run a separate Azure deployment step. To deploy Sentinel, you must be an **Azure Subscription Owner**. Allow a few minutes for resources to appear. Response modules (such as Gamebooks for Defender XDR, Identity, Microsoft 365, Azure, and SentinelOne) enable Gamebook actions like isolating devices, disabling users, and quarantining files. Consent to them the same way — a single **Consent** per module. *** ## Step 3: Confirm Your Workspace Is Live There's no completion screen. Your workspace is onboarded when its **status light turns green** on its card in the Workspace Center. | Status light | What it means | | ------------ | --------------------------------------------------------------------------- | | **Blue** | Pre-onboarded — your service provider created the workspace and invited you | | **Amber** | A module or agent is still missing — finish consenting to your modules | | **Green** | Onboarded and live — incidents will begin to flow in | Your service provider receives a real-time notification when your workspace goes live, so they'll know you're ready. *** ## Adding Users (After Onboarding) Adding users is **not** part of onboarding. Once your workspace is live, add teammates from **Settings → User Management** using the **Invite people to the organization** dialog. Manage groups from **Settings → Group Management**. *** ## Troubleshooting: Sign-in Failed If you click your invite link and see a **Sign In Failed** page, it's almost always because: * You aren't a Global Administrator and ContraForce hasn't been pre-approved for your tenant yet * A previous sign-in attempt got into a bad state Need admin approval ### What to do This clears any stale session that might be blocking sign-in. Sign in. Microsoft will show the consent screen. Accept both core consents, and you'll proceed into your workspace. Or copy the **Admin Consent Link** from the page and send it to a Global Admin in your organization. Once they accept, return to your invite link and click **Try Again**. Don't keep retrying the same sign-in repeatedly without signing out. Repeated failures can compound the bad-session state and require a browser cache clear to recover. *** ## Next Steps Deploy and consent to the Defender for Endpoint module Your home base for incident triage across your environment How to triage, investigate, and respond to incidents Automated response workflows you can run from any incident *** **Need help?** Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Microsoft Defender for Endpoint Module Source: https://docs.contraforce.com/guides/onboarding/defender-for-endpoint-module-deployment This guide walks you through deploying the ContraForce Defender module, enabling you to manage Microsoft Defender for Endpoint incidents, run Gamebook response actions, and monitor endpoints across your managed workspaces. The Defender module is designed for environments using Microsoft Defender for Endpoint (Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps). If you also use Microsoft Sentinel, consider the **XDR + SIEM** module instead. ## Before You Begin ### Prerequisites Ensure you have the following before starting deployment: An active Microsoft Defender for Endpoint deployment in the target tenant **Global Administrator** access to the Microsoft tenant being onboarded — required to grant admin consent for ContraForce enterprise applications. Cloud Application Administrator and Application Administrator cannot grant consent for Microsoft Graph application permissions. Access to [portal.contraforce.com](https://portal.contraforce.com), plus your workspace **invite link** if you are a customer admin onboarding an invited workspace ### Supported Licenses The Defender module works with the following Microsoft 365 licenses: | License | Supported | Notes | | ------------------------------------ | :-------: | ----------------------------------------- | | **Microsoft 365 Business Premium** | ✓ | Full XDR capabilities | | **Microsoft 365 E3** | ✓ | Full XDR capabilities | | **Microsoft 365 E5** | ✓ | Full XDR capabilities + advanced features | | **Standalone Defender for Endpoint** | ✓ | Endpoint features only | View detailed feature availability by license tier *** ## Module Options ContraForce offers two deployment modules. Choose based on your security stack: **Microsoft Defender for Endpoint only** * Defender for Endpoint incidents * Endpoint management * Identity and email response * Gamebook actions *Choose this if you don't use Microsoft Sentinel* **Defender for Endpoint + Microsoft Sentinel** * Everything in Defender module * Sentinel incidents * Advanced threat hunting * Data connectors * Custom notifications by severity *Choose this if you use Sentinel alongside Defender* ### Feature Comparison | Feature | Defender Module | XDR + SIEM Module | | ------------------------------- | :-------------: | :---------------: | | Defender for Endpoint Incidents | ✓ | ✓ | | Endpoint Management | ✓ | ✓ | | Gamebook Response Actions | ✓ | ✓ | | Entity Insights | ✓ | ✓ | | Sentinel Incidents | — | ✓ | | Advanced Threat Hunting | — | ✓ | | Data Connectors | — | ✓ | | Custom Severity Notifications | — | ✓ | Not sure which module to choose? Start with the Defender module if you only use Defender products. You can upgrade to XDR + SIEM later if you add Sentinel. *** ## Deployment Process You deploy the Defender module directly in the ContraForce portal — there is no separate setup tool to launch. Sign in, grant the core ContraForce app consents, then enable and consent the Defender module from your workspace's **Modules** tab. Granting consent requires the **Global Administrator** role to authorize the enterprise applications. Cloud Application Administrator and Application Administrator cannot grant consent for Microsoft Graph application permissions. Global Administrator is required for the one-time consent only and is not retained; activate it just-in-time with Privileged Identity Management (PIM) and deactivate afterward. ### Step 1: Sign In and Grant Core App Consents Open [portal.contraforce.com](https://portal.contraforce.com). If you were invited to a workspace, open your **invite link** instead — it routes you to the portal sign-in. Authenticate with a **Global Administrator** account from the target tenant. The first time anyone from your tenant signs in, a Microsoft consent prompt appears for **ContraForce API**. Review the requested permissions and click **Accept**. A second, separate Microsoft consent prompt appears for **ContraForce Portal**. Review the requested permissions and click **Accept**. **ContraForce API** and **ContraForce Portal** are consented as two separate Microsoft prompts. Both are required for all ContraForce deployments, regardless of module selection. *** ### Step 2: Open the Modules Tab After the core app consents complete, open the workspace you are onboarding and go to its **Modules** tab. This is where you enable and consent each module for the workspace. If a module was pre-selected for your workspace during invitation (for example, **Detection** and **Response**), you'll find it listed here ready to consent. *** ### Step 3: Consent the Microsoft Defender for Endpoint Module On the **Modules** tab, enable and consent the Microsoft Defender for Endpoint module. Find **Microsoft Defender for Endpoint** in the module list on the **Modules** tab. Click **Consent** for the module. A Microsoft consent window opens. Sign in with your **Global Administrator** account, review the requested permissions, and click **Accept**. Consent is granted **per module** on the **Modules** tab with a single **Consent** action. The single Consent authorizes ContraForce to operate the module for the workspace. *** ### Step 4: Consent Response (Gamebook) Modules To enable Gamebook response actions, consent the response modules you need — each with a single **Consent** on the **Modules** tab. Consent this module to enable endpoint response actions (isolate, scan, offboard). Consent the response modules that match your environment (see the table below). | Module | Purpose | When to Consent | | -------------------------- | ----------------------------------------------- | ----------------------------------------- | | **Gamebooks for Identity** | User response actions (disable, reset password) | If managing Microsoft Entra ID identities | | **Microsoft 365 Response** | Email response actions (delete email) | If using Defender for Office 365 | | **Azure Response** | Azure resource response actions | If responding to Azure-based threats | For each module, click **Consent**, complete the Microsoft authentication flow, and click **Accept** on the permissions prompt. *** ### Step 5: Confirm the Workspace Is Live There is no completion screen. Your workspace is onboarded when its **status light turns green** on its card in the **Workspace Center**. Open the **Workspace Center** and find your workspace card. A **green** status light means the workspace is live. A **blue** light means it is pre-onboarded and still awaiting consent; **amber** means a module or agent is still missing. Defender for Endpoint incidents begin syncing to ContraForce (this may take 15-30 minutes). Open the **Command** page to confirm incidents are appearing. Open an incident and confirm Gamebook response actions are available. If you don't see incidents immediately, verify that incidents exist in Microsoft Defender for Endpoint. ContraForce only displays incidents that exist in the source system. *** ## Adding Users Adding users is **not** part of module deployment. Once your workspace is live, invite your team from the organization settings. Go to **Settings → User Management** and open the **Invite people to the organization** dialog to add users and assign roles. Manage groups in **Settings → Group Management**. | Role | Best For | | ---------------------- | ------------------------------------------- | | **Admin** | Team leads, workspace owners | | **Incident Responder** | SOC analysts who need response capabilities | | **Incident Analyst** | Junior analysts, read-only access | | **Data Source Admin** | Integration specialists | View detailed permissions for each role *** ## Defender Module Limitations When using the Defender module (without SIEM), the following features are **not available**: | Feature | Status | Alternative | | -------------------------------- | ------------- | --------------------- | | SIEM Incidents | Not available | Upgrade to XDR + SIEM | | Sentinel Advanced Threat Hunting | Not available | Upgrade to XDR + SIEM | | Data Connectors page | Empty | Upgrade to XDR + SIEM | | Custom severity notifications | Not available | Upgrade to XDR + SIEM | ### Notifications **Defender Module Notification Behavior:** * Email notifications are **not** generated by ContraForce for new Defender for Endpoint incidents * Email notifications **are** sent for Gamebook runs * ContraForce does not interrupt existing Defender notification configurations Learn more about ContraForce notification options *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ------------------------------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Consent fails** | Insufficient permissions | Verify you're using a **Global Administrator** account. Cloud Application Administrator and Application Administrator cannot grant consent for Microsoft Graph application permissions | | **Consent window doesn't open** | Pop-up blocker | Disable the pop-up blocker for portal.contraforce.com and click **Consent** again | | **No incidents appearing** | Sync in progress | Wait 15-30 minutes for initial sync | | **No incidents appearing** | No incidents in Defender | Verify incidents exist in the Microsoft Defender for Endpoint portal | | **No MDE device data** | MDE consent incomplete | Re-consent the Microsoft Defender for Endpoint module on the **Modules** tab | | **Gamebooks unavailable** | Module not consented | Consent **Gamebooks for Microsoft Defender for Endpoint** on the **Modules** tab | | **Status light not green** | Module or agent still missing | Confirm every required module shows consented on the **Modules** tab | ### Getting Help If you encounter issues during deployment: 1. **Check consent status** on the workspace **Modules** tab 2. **Verify admin permissions** in the target tenant 3. **Review error messages** for specific guidance 4. **Contact support** at [support@contraforce.com](mailto:support@contraforce.com) *** ## Related Documentation ### Enterprise Applications Overview of all ContraForce service principals Detailed permissions reference Endpoint response permissions Core portal permissions ### Next Steps Learn the incident workflow Start using response actions Add and manage users Navigate your dashboard *** Questions about Defender module deployment? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # How to integrate Autotask PSA to ContraForce. Source: https://docs.contraforce.com/guides/onboarding/how-to-integrate-autotask This article outlines the steps required to integrate Autotask PSA with ContraForce. ## Overview This article outlines how to connect an Autotask instance to the ContraForce Platform. Once connected, users can link an Autotask ticket to an incident or create a new Autotask ticket tied to an incident. ## Creating a Service Account in Autotask For the integration into ContraForce, a Service Account user needs to be created in Autotask. You will need the details about the created Service Account user when integrating Autotask to ContraForce. ![Autotask service account](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/undefined.jpeg) *A screen shot of an example Autotask service account user profile* ## Integration Steps 1. Log in to your ContraForce account and navigate to the Workspaces section. Locate the desired workspace you wish to integrate with, then click on the slider icon adjacent to the dropdown arrow. 2. Within the workspace overview page, scroll down to the IT Service Management section and click the blue "+" symbol. 3. Select Autotask and input the following details: * **Endpoint: [https://.autotask.net/ATServicesRest/](https://.autotask.net/ATServicesRest/)** * The endpoint is the URL of your Autotask instance. * **Integration Code** * Select Custom, assign a name, copy the Tracking Identifier value from the Autotask service account user profile. * **Username** * Credentials > Username (Key) from the Autotask service account user profile. * **Secret** * Credentials > Password (Secret) from the Autotask service account user profile. 4. After inputting all details, click the "Test" button to see if any errors populate. After running a successful test, click Save. 5. On the workspace overview page, you will see Autotask under IT Service Management. ## Using Autotask with Multiple ContraForce Workspaces. The integration for Autotask does not need to be configured within each workspace that is onboarded to ContraForce. To use Autotask with multiple ContraForce workspaces, Autotask should be configured within your Parent workspace. # Microsoft Sentinel Integration Source: https://docs.contraforce.com/guides/onboarding/microsoft-sentinel-module Deploy the Microsoft Sentinel module to enable SIEM integration, real-time incident streaming, detection rules via CMS, and advanced threat hunting capabilities. The Microsoft Sentinel module connects ContraForce to your Microsoft Sentinel workspace, enabling centralized monitoring, real-time incident streaming, and the ability to act on Sentinel security data directly from the ContraForce platform. **What this module adds:** Sentinel incident ingestion, Content Management System (CMS) for detection rules, email notifications, log search, and Azure Lighthouse cross-tenant management. **Who is this for?** Workspace Admins and Data Source Admins deploying the Sentinel module from the **Modules** tab of a workspace in the ContraForce portal. *** ## Prerequisites Before starting, ensure you have the following: **Global Administrator** — required to grant admin consent for ContraForce enterprise applications (service principals). Cloud Application Administrator and Application Administrator cannot grant consent for Microsoft Graph application permissions. ContraForce Workspace Role: **Owner** or **Admin** Microsoft Subscription Permission: **Owner** — required to deploy the supporting Azure infrastructure ### Additional Requirements | Requirement | Details | | --------------------------- | ---------------------------------------------------- | | **Microsoft Sentinel** | Active Sentinel workspace in your Azure subscription | | **Log Analytics Workspace** | The workspace linked to your Sentinel deployment | | **Resource Group Access** | Ability to create resources in the subscription | | **No Conflicting Policies** | Azure Policy must allow Lighthouse delegations | If you don't have Subscription Owner permissions, the Azure deployment will fail. Contact your Azure administrator to obtain the necessary access or have them complete the deployment with you. **Consent model.** ContraForce enterprise applications are consented with **application (app-only)** Microsoft Graph permissions. Admin consent for Microsoft Graph application permissions must be granted by a **Global Administrator** — Cloud Application Administrator and Application Administrator cannot grant it. Global Administrator is required for the one-time consent only and is not retained; activate it just-in-time with Privileged Identity Management (PIM) and deactivate afterward. Because actions run as the application (no signed-in user required), operator control is enforced through **Gamebook approval gates** — only Workspace Owners can approve high-impact actions — and a complete **audit trail** in the Gamebooks History page. *** ## What Gets Deployed When you deploy the Sentinel module, ContraForce **automatically** provisions the Azure resources needed for integration. You do not deploy Lighthouse or the streaming infrastructure as separate manual steps — they are created as part of module deployment. | Component | Purpose | | ------------------------- | --------------------------------------------------------- | | **Azure Lighthouse** | Cross-tenant delegation for multi-tenant management | | **Apollo Resource Group** | Infrastructure for incident streaming | | **Logic App** | Streams Sentinel incidents to ContraForce in real-time | | **Automation Rule** | Triggers the Logic App when incidents are created/updated | | **Role Assignments** | Grants ContraForce service principals access to Sentinel | Complete list of all deployed resources with details *** ## Step 1: Open the Modules Tab Sign in at [portal.contraforce.com](https://portal.contraforce.com), open the **Workspace Center**, and select the workspace you want to configure. Open the workspace and select the **Modules** tab. This is where every module is enabled and consented. Find the **Microsoft Sentinel** module in the list of available modules. *** ## Step 2: Verify Prerequisites Before deploying, confirm you hold the required roles. The deployment will not complete without them. | Prerequisite | Required Value | | --------------------------------- | -------------------- | | Azure Role for Microsoft Tenant | Global Administrator | | ContraForce Workspace Role | Owner or Admin | | Microsoft Subscription Permission | Owner | If you're missing any of these, obtain the required permissions before proceeding. The deployment will fail without proper access. *** ## Step 3: Consent the Microsoft Sentinel Module Consent is a **single action per module** on the **Modules** tab. Clicking **Consent** grants everything ContraForce needs for this module in one step. On the **Microsoft Sentinel** module, click **Consent**. A Microsoft consent window opens. Sign in with **Global Administrator** credentials. Review the requested permissions and click **Accept** to consent on behalf of your organization. Consenting the module **automatically deploys** the supporting Azure resources — Azure Lighthouse delegation, the Apollo resource group, and the Sentinel-side Logic App and automation rule. You may be prompted to sign in with an account that has **Subscription Owner** permissions so the resources can be created. Apollo resources are created in the customer's Azure subscription. Standard Azure charges may apply for Logic App executions. ### What the Sentinel Module Grants | Capability | Description | | --------------------------- | ---------------------------------------------------- | | **Cross-tenant visibility** | View and manage Sentinel from the ContraForce portal | | **Incident access** | Read and update incidents across tenants | | **Query execution** | Run Log Analytics queries for threat hunting | | **Rule deployment** | Deploy detection rules via CMS | ### Resources Created in Your Subscription | Resource | Type | Purpose | | -------------------------- | --------------- | --------------------------------- | | **cf-apollo-\[workspace]** | Resource Group | Container for streaming resources | | **cf-incident-stream** | Logic App | Processes and forwards incidents | | **cf-sentinel-connection** | API Connection | Authenticates to Sentinel | | **cf-incident-trigger** | Automation Rule | Triggers on incident changes | ### Threat Hunting Permissions The Sentinel module grants the **ContraForce Sentinel Hunting** application read access to your Log Analytics data. | Application | Permissions | Purpose | | -------------------------------- | -------------------- | -------------------------------------- | | **ContraForce Sentinel Hunting** | Log Analytics Reader | Execute KQL queries for threat hunting | Enterprise application details and permissions *** ## Step 4: Verify Module Status A workspace module is live when its status indicator turns **green** on its card. Confirm the Sentinel module is fully deployed: * Microsoft Sentinel module status light shows **green** * Sentinel incidents begin streaming into the Command Dashboard ### Test Incident Sync Navigate to the **Command Dashboard** in ContraForce. Look for incidents with the Sentinel source indicator. Click an incident to confirm entity enrichment and details are loading. Incidents may take 5-15 minutes to appear initially. If you have existing incidents in Sentinel, they should sync automatically. *** ## Post-Deployment Steps ### Configure Notifications With the Sentinel module active, you can now configure email notifications: Navigate to workspace **Settings → Notifications**. Select which severity levels should trigger notifications. Click **Save** to apply your notification preferences. Complete guide to notification setup ### Deploy Detection Rules Use the Content Management System to deploy detection rules to your Sentinel workspace: Go to **Content Management System** in the left navigation. Choose the workspace you just deployed. Review available detection rules and enable those matching your data sources. Deploy detection rules to your Sentinel workspace *** ## Troubleshooting ### Common Issues | Issue | Cause | Solution | | --------------------------- | ------------------------- | ----------------------------------------------------------- | | Subscription not visible | Insufficient permissions | Sign in with a Subscription Owner account | | Deployment fails | Azure Policy restrictions | Check for policies blocking Lighthouse or resource creation | | Lighthouse delegation fails | Existing delegation | Remove the existing Lighthouse delegation and retry | | Consent fails | Insufficient role | Grant consent with Global Administrator credentials | | No incidents appearing | No incidents in Sentinel | Verify incidents exist in the Sentinel portal | | Apollo Logic App disabled | Deployment issue | Manually enable the Logic App in the Azure portal | | Consent popup blocked | Browser settings | Allow popups from portal.contraforce.com | ### Verifying Azure Resources To verify resources deployed correctly: Navigate to [portal.azure.com](https://portal.azure.com). Search for the Apollo resource group (cf-apollo-\[workspace]). Confirm the Logic App exists and is **Enabled**. In Sentinel, go to **Automation → Automation Rules** and verify the ContraForce rule exists. ### Lighthouse Troubleshooting If Lighthouse delegation fails: 1. **Check Azure Policy** — Some organizations restrict Lighthouse delegations 2. **Remove existing delegations** — Conflicting delegations can cause failures 3. **Verify permissions** — Subscription Owner is required 4. **Check tenant settings** — Ensure cross-tenant access isn't blocked 1) Go to Azure Portal → Service providers 2) Find any existing ContraForce delegations 3) Click on the delegation and select **Delete** 4) Wait for deletion to complete 5) Retry the deployment in ContraForce 1. Go to Azure Portal → Resource Groups 2. Open the cf-apollo-\[workspace] resource group 3. Click on the Logic App resource 4. Click **Enable** if the Logic App is disabled 5. Verify the Logic App shows "Enabled" status *** ## Module Capabilities Unlocked With the Sentinel module deployed, you now have access to: Real-time incident ingestion from Microsoft Sentinel Instant alerts when new incidents are created Deploy and manage detection rules at scale Query Log Analytics for threat hunting Manage multiple Sentinel workspaces from one portal Execute KQL queries across customer environments *** ## Next Steps Set up email alerts for incidents Use CMS to deploy Sentinel rules Grant team access in Settings → User Management Start triaging Sentinel incidents *** ## Related Guides Defender for Endpoint integration Complete resource reference Detection rule management *** Need help with Sentinel module deployment? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Platform Notifications Source: https://docs.contraforce.com/guides/onboarding/notifications-module Configure email notifications for security incidents, Gamebook activity, and system alerts. Customize by severity and workspace. ContraForce keeps your team informed with configurable email notifications. Receive alerts when new incidents are detected, Gamebooks complete, or when issues require attention—all customizable by severity and workspace. Notification capabilities vary by module. The XDR + SIEM module offers full customization, while the XDR-only module has limited notification options. ## Notification Overview Get notified when new security incidents are detected Receive updates when Gamebook actions complete Choose which severity levels trigger notifications *** ## Notification Capabilities by Module Notification features depend on which ContraForce module you've deployed: | Feature | Defender Module | XDR + SIEM Module | | -------------------------------------------- | :-------------: | :---------------: | | Sentinel incident notifications | — | ✓ | | Defender for Endpoint incident notifications | — | — | | Gamebook completion notifications | ✓ | ✓ | | Severity-based filtering | — | ✓ | | Per-workspace customization | — | ✓ | | Distribution group support | — | ✓ | **Defender Module Users:** ContraForce does not generate email notifications for new Defender for Endpoint incidents. Use Microsoft Defender's built-in notification settings for Defender alerts. ContraForce notifications are sent only for Gamebook activity. Deploying ContraForce does not interrupt or override your existing Microsoft Defender notification configuration. *** ## Email Notification Details ### Sender Address All ContraForce notifications are sent from: ``` noreply@notifications.contraforce.com ``` Add this address to your email allowlist to ensure notifications aren't blocked by spam filters. ### Email Content Incident notification emails include: | Field | Description | | ------------------------ | ----------------------------------------------- | | **Title** | Incident name/description | | **Description** | Summary of the security event | | **Severity** | High, Medium, Low, or Informational | | **Incident ID** | Unique identifier for tracking | | **MITRE Tactics** | Associated attack techniques | | **Entities** | Affected users, devices, IPs, etc. | | **View Incident Button** | Direct link to open the incident in ContraForce | ## Configuring Notifications ### Accessing Notification Settings Click **Settings** in the navigation menu Click the **Notifications** tab Adjust settings by workspace and severity **Direct link:** [Settings > Notifications](https://portal.contraforce.com/settings/notifications) ### Severity-Based Filtering For Microsoft Sentinel deployments, you can customize which severity levels trigger notifications: **High severity incidents** typically indicate active threats requiring immediate response. *Recommendation: Always enable* **Medium severity incidents** indicate potential threats that need investigation. *Recommendation: Enable for most teams* **Low severity incidents** are often informational or low-risk events. *Recommendation: Enable based on team capacity* **Informational incidents** are typically audit events or low-priority alerts. *Recommendation: Disable to reduce noise, unless required for compliance* ### Per-Workspace Configuration Configure different notification preferences for each customer workspace: 1. Navigate to **Settings > Notifications** 2. Select the **Workspace** you want to configure 3. Enable or disable severity levels for that workspace 4. Save changes Use per-workspace configuration to match notification settings to each customer's SLA. High-priority customers might need all severities enabled, while others might only need High alerts. *** ## Distribution Group Notifications Send notifications to a team distribution list instead of individual users. ### Use Cases Route all alerts to a shared SOC mailbox for team visibility Send to a distribution group that routes to the current on-call analyst Route to an email address that auto-creates tickets in your ITSM Keep customers informed by CCing their security team ### Setting Up Distribution Groups Distribution group notifications require setup assistance from the ContraForce team: Determine the distribution group email address you want to use Provide the email address during onboarding or contact [support@contraforce.com](mailto:support@contraforce.com) The ContraForce Engineering team configures the distribution group Test that notifications are reaching the distribution group Distribution group setup is typically completed during onboarding. If you need to add or change distribution groups later, contact support. *** ## Gamebook Notifications Gamebook notifications are available for **all modules** (XDR and XDR + SIEM). ### When You'll Receive Notifications | Event | Notification Sent | | ------------------------------- | :---------------: | | Gamebook execution started | — | | Gamebook completed successfully | ✓ | | Gamebook failed | ✓ | | Gamebook requires approval | ✓ | | Gamebook approved | ✓ | ### Gamebook Email Content Gamebook notifications include: * Gamebook name * Target incident * Actions executed * Execution status (Success/Failed) * Workspace name * Link to view details *** ## Notification Best Practices Begin with High severity notifications enabled for all workspaces. Add Medium and Low severities gradually based on team capacity to avoid alert fatigue. Route notifications to a shared mailbox so the entire SOC team has visibility. This prevents missed alerts when individuals are unavailable. Set up email folder rules to automatically categorize ContraForce notifications by workspace or severity for easier triage. Route notifications to an email address that creates tickets in your ITSM (ServiceNow, Jira, etc.) for automatic tracking and SLA management. Regularly review notification settings. If you're experiencing alert fatigue, consider disabling lower severity levels or refining detection rules. Add `noreply@notifications.contraforce.com` to your email allowlist to prevent notifications from being caught by spam filters. *** ## Integrating Notifications with Other Tools ### Email-to-Ticket Integration Many ITSM platforms support email-based ticket creation: | Platform | Method | | --------------------------- | ------------------------------- | | **ServiceNow** | Configure inbound email actions | | **Jira Service Management** | Use email request channel | | **Autotask** | Set up email-to-ticket rules | | **ConnectWise** | Configure email connector | For tighter integration, consider using the [ContraForce Partner API](/guides/technical/contraforce-api-documentation). ### Microsoft Teams / Slack For real-time team notifications: 1. Create an email-enabled channel in Teams or Slack 2. Use that email address as a distribution group in ContraForce 3. Notifications appear directly in your chat platform *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ---------------------------------- | ---------------------- | --------------------------------- | | **Not receiving notifications** | Spam filter blocking | Add sender to allowlist | | **Not receiving notifications** | Wrong module deployed | Verify you have XDR + SIEM module | | **Not receiving notifications** | Severity disabled | Check notification settings | | **Missing workspaces in settings** | Permissions issue | Verify you have admin access | | **Distribution group not working** | Not configured | Contact ContraForce support | | **Too many notifications** | All severities enabled | Disable Informational and Low | ### Testing Notifications To verify notifications are working: 1. Ensure notification settings are enabled for the workspace 2. Wait for a new incident to be detected (or ask ContraForce to send a test) 3. Check your inbox (including spam/junk folders) 4. Verify the email contains expected content *** ## Frequently Asked Questions All notifications are sent from `noreply@notifications.contraforce.com` ContraForce does not send email notifications for Defender for Endpoint incidents directly. Use Microsoft Defender's built-in notification settings for those alerts. ContraForce sends notifications for Sentinel incidents (XDR + SIEM module) and Gamebook activity (all modules). Contact [support@contraforce.com](mailto:support@contraforce.com) with the email address you want to use. The ContraForce Engineering team will configure it for your account. Email templates are standardized and cannot be customized. For custom notification formatting, consider routing emails to a ticketing system that can reformat them. Notifications are sent in near real-time when incidents are detected and processed by ContraForce. Typical delay is under 5 minutes. ContraForce currently supports email notifications only. For SMS or push, route email notifications to a service like PagerDuty or Opsgenie. *** ## Related Guides XDR vs XDR + SIEM modules *** Questions about notifications? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Platform Onboarding Source: https://docs.contraforce.com/guides/onboarding/platform-onboarding Get your service-provider organization up and running on ContraForce: grant Microsoft access, set up the Agent Center, connect your own security tools, and pre-onboard customer workspaces. This guide walks you through getting your **service-provider organization** up and running on ContraForce. By the end, you'll be ready to pre-onboard your first customer. **Who is this for?** * **MSP/MSSP partners** setting up your parent tenant before onboarding customers * **Internal security teams** deploying ContraForce for your own organization If a teammate gets stuck at sign-in, jump to [Troubleshooting: Sign-in failed](#troubleshooting-sign-in-failed). *** ## Prerequisites | Requirement | Why | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | **Microsoft Entra Global Administrator** | Required the very first time anyone from your tenant signs in, to grant ContraForce permission to read security data | | **ContraForce sign-up link** | Provided by your account team | | **Pop-ups allowed for `portal.contraforce.com`** | Microsoft consent prompts open in popup windows | If your tenant has a "Do not allow user consent" policy, the consent must be completed by a Global Administrator. Non-admin users will see a Sign In Failed page. See [Troubleshooting: Sign-in failed](#troubleshooting-sign-in-failed) below. *** ## Step 1: Grant ContraForce Access to Your Tenant Before anyone in your organization can sign in, a Microsoft Entra **Global Administrator** has to grant ContraForce permission to read security data from your tenant. **This is a one-time approval.** Use the link your account team shared with you. You'll be redirected to Microsoft. Sign in with your Global Admin credentials. Microsoft displays a consent screen listing the permissions ContraForce needs. Review the list and click **Next**. Microsoft consent dialog showing ContraForce Portal permissions Microsoft may ask you to consent a second time: once for the ContraForce platform API and once for the ContraForce Portal. Check **Consent on behalf of your organization** and click **Accept**. Microsoft consent dialog showing ContraForce API permissions *** ## Step 2: Sign In for the First Time Once consent is granted, create a workspace for your organization. Create a workspace for your organization The platform detects that this is a brand-new tenant and creates your account automatically. You'll land on the **Command** page. Service provider getting started *** ## Step 3: The Get Started Checklist The **Get started with ContraForce** panel is your home base for setup. It lists the activities your organization still needs to complete. | Item | What it does | | --------------------------- | ------------------------------------------------------------------------------- | | **Create your account** | Already done by signing in for the first time | | **Setup agent center** | Choose where ContraForce-hosted automation runs | | **Connect sources** | Connect your own security tools so your SOC team can use ContraForce internally | | **Add customer workspaces** | Pre-onboard the customers you'll be managing | Each unchecked item has a **Start** button on the right that takes you straight to the relevant page. You can dismiss the panel at any time using the ✕ in the top right; it will also self-hide once every item is complete. *** ## Step 4: Set Up Your Agent Center Click **Start** next to **Setup agent center**. This is where you choose how the ContraForce automation engine runs for your organization. Deploy your agent center You can either deploy your agent here or skip it and continue with the other items. If you deploy an agent, the **Setup agent center** item shows a green checkmark when you return to the Command page. Detailed Agent Center setup, requirements, and configuration options *** ## Step 5: Connect Detection Sources to Your Own Workspace Click **Start** next to **Connect sources**. This jumps you straight to the detection-source picker for your own workspace. Connect your detection sources Select the security tools your team uses, then follow the prompts to authorize ContraForce to read from each one. Once at least one detection source is connected, the **Connect sources** item on the checklist will check off. Connecting Microsoft Sentinel triggers ContraForce to deploy the supporting Azure infrastructure in your subscription automatically. You don't need a separate Azure deployment step. Provisioning runs in the background after you grant consent. *** ## Step 6: Add a Customer Workspace Click **Start** next to **Add customer workspaces**. You'll land on the **Workspace Center** with the **Onboarding** tab active and the **Add workspace** rail panel already open on the right. Add customer workspace Fill in the customer details: | Field | Description | | ---------------------------------- | ------------------------------------------------------------- | | **Workspace name** | Friendly label you'll use to refer to this customer | | **Tenant ID** | The customer's Microsoft Entra tenant ID | | **Primary point-of-contact email** | The customer admin who will complete onboarding on their side | | **Detection modules** | Pre-select the security tools the customer is bringing | | **Response modules** | Pre-select the response capabilities the customer will use | Pre select customer modules Click **Send Invite**. ContraForce sends an invite email to the POC, and the new workspace appears as a card in the Onboarding tab with a **Pending customer setup** badge. customer workspace preonboarded Repeat this step for every customer you want to manage. When the customer admin finishes onboarding their workspace, you'll receive a real-time notification in the portal so you know their workspace is live. What your customer sees on their side after they receive the invite email *** ## Troubleshooting: Sign-in Failed If a teammate sees the **Sign In Failed** page after trying to log in, it usually means one of three things: * The Microsoft admin consent step was skipped * A non-admin user tried to sign in before consent was granted * A previous sign-in session is stuck Consent failed ### What to do, in order This bounces you back to a clean state without applying a half-completed consent. Copy the admin consent link from the page and forward it to your Global Admin. Sign-In failed Your admin clicks the link, signs in as a Global Administrator, and walks through the Microsoft consent prompts. First consent permission Second consent permission FirsThridt consent permission Permissions Approved Wait until your admin reaches the **Permissions Approved** card before you try again. Once consent is approved, you can sign in normally and proceed to create your workspace. Sign-In again Create workspace again *** ## Next Steps Set up groups before onboarding customers What your customer sees on their side Manage multiple customers efficiently Plan role assignments for your team *** Questions about platform onboarding? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # SentinelOne Detection and Response Modules Source: https://docs.contraforce.com/guides/onboarding/sentinelone-module Connect the SentinelOne Detection and Response modules to a ContraForce workspace to ingest threats and enable endpoint response actions. **Who is this for?** Workspace Admins or Security Engineers who manage a workspace that uses SentinelOne Singularity. This guide walks you through creating two SentinelOne Service Users, configuring both modules in ContraForce, and verifying that threats flow end-to-end. ## Before You Begin ### What These Modules Do SentinelOne integrates with ContraForce through two separate modules: **Threat ingestion and investigation** * Polls the SentinelOne Threats API for new threats * Classifies them as ContraForce Incidents or Detections * Round-trips status changes and analyst notes back to SentinelOne * Records incident ownership in ContraForce (not written back to SentinelOne) **Gamebook response actions** * Powers Contain and Lift Containment Gamebooks (Network Quarantine) * Powers On-Demand Scan Gamebooks * Required for any Gamebook that acts on a SentinelOne-managed endpoint The two modules use separate SentinelOne Service Users so each has only the role it needs. **Incident ownership is tracked in ContraForce, not in SentinelOne.** A SentinelOne threat has no owner or assignee property, and analysts working through a service provider rarely hold an account in the customer's SentinelOne tenant. Assigning an owner in ContraForce therefore records the assignment in ContraForce, where every user who can see the incident can see who owns it. The SentinelOne console will continue to show the threat with no assignee. Status changes and analyst notes are unaffected — those still round-trip to SentinelOne. Unlike the CrowdStrike module, there is no option to mirror ownership to the vendor, because SentinelOne has no field to write it to. ### Prerequisites An active SentinelOne Singularity subscription with endpoint agents deployed and reporting to the management console. Access to **Settings → Users → Service Users** in the SentinelOne console. Creating Service Users typically requires the SentinelOne **Admin** role at the scope you plan to integrate. A ContraForce workspace created for the tenant, with your account assigned the **Workspace Admin** role. Identify the full URL of your SentinelOne management console (for example, `https://yourtenant.sentinelone.net`). You will enter this as the **Endpoint** when configuring the Detection module. You can confirm the Management Console URL by logging in to SentinelOne — the base URL in your browser (without any path after the hostname) is the value you will use. Do not include a trailing slash. ### Scope of Access SentinelOne scopes roles by **Global → Account → Site → Group**. For most integrations, set the scope of each Service User to **Site** and pick the specific sites you want ContraForce to monitor. Use **Account** only if ContraForce should cover every site in the account. *** ## Step 1 — Create the Detection Service User in SentinelOne 1. In the SentinelOne console, navigate to **Settings → Users → Service Users** 2. Click **Actions → Create New Service User** 3. Set **Name** to `ContraForce Detection` 4. Set **Description** to `ContraForce threat ingestion and status writeback` 5. Set **Scope of access** to **Site** (pick the sites ContraForce will monitor) or **Account** if all sites are in scope 6. Assign the built-in role **SOC** 7. Set an expiration date for the API token — SentinelOne supports up to 1 year. Pick a date that fits your rotation policy 8. Click **Create** SentinelOne will display the **API Token** on the confirmation screen. The API Token is shown once at creation time and cannot be retrieved later. Copy it to a secure location immediately. If you lose it, you must regenerate the token from the same Service User. If your organization doesn't use the built-in **SOC** role, you can create a custom role with the following permissions instead: **Threats** (View, Modify), **Threat Notes** (View, Add, Edit, Delete), and **Activity** (View). *** ## Step 2 — Create the Response Service User in SentinelOne Repeat the process for a second Service User that ContraForce will use for Gamebook response actions. 1. In **Settings → Users → Service Users**, click **Actions → Create New Service User** 2. Set **Name** to `ContraForce Response` 3. Set **Description** to `ContraForce Gamebook response actions` 4. Set **Scope of access** to match the Detection Service User 5. Assign the built-in role **IR Team** 6. Set an expiration date and click **Create** Copy the **API Token** for the Response Service User. If your organization doesn't use the built-in **IR Team** role, you can create a custom role with the Detection permissions above plus **Endpoints / Agents** (View, Disconnect, Reconnect, Initiate Scan). Creating two separate Service Users — one with SOC for Detection, one with IR Team for Response — follows the principle of least privilege. The Detection user can't disconnect an endpoint, and the Response user doesn't get more threat access than it needs. *** ## Step 3 — Configure the SentinelOne Detection Module in ContraForce 1. In the ContraForce portal, navigate to **Workspaces** → your workspace → **Modules** 2. Locate the **SentinelOne Detection** card and click **Configure** 3. Fill in the following fields: | Field | Value | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Endpoint** | The full URL of your SentinelOne console, for example `https://yourtenant.sentinelone.net` — no trailing slash and no `/web/api/...` path | | **API Token** | The token from the Detection Service User you created in Step 1 | 1. Click **Test Connection** to verify the credentials reach SentinelOne and have the required permissions 2. Click **Configure and Save** If **Test Connection** fails, see the [Troubleshooting](#troubleshooting) table before saving. *** ## Step 4 — Configure the SentinelOne Response Module in ContraForce 1. On the same **Modules** page, locate the **SentinelOne Response** card and click **Configure** 2. Fill in the following fields: | Field | Value | | ------------- | ----------------------------------------------------------------------------------------------------- | | **Endpoint** | Inherited from the Detection module — read-only. Edit it on the Detection card if it needs to change. | | **API Token** | The token from the Response Service User you created in Step 2 | 1. Click **Test Connection** and then **Configure and Save** A successful test means Gamebook response actions are ready for SentinelOne-managed endpoints. *** ## Step 5 — Verify End-to-End The Detection module polls SentinelOne on a short interval. New threats appear in ContraForce within a few minutes of being generated in SentinelOne. Navigate to the **Command Dashboard**. SentinelOne threats should appear alongside incidents from other sources. Click into a SentinelOne-sourced incident and verify that the **Entities** and **Timeline** tabs are populated with threat data. If the Response module is configured, open a SentinelOne incident where the affected entity is an agent and confirm that **Contain**, **Lift Containment**, and **On-Demand Scan** Gamebook actions are available. *** ## What Each Module Unlocks | Capability | Requires Detection | Requires Response | | ------------------------------------------------------- | :----------------: | :---------------: | | Ingest SentinelOne threats as incidents or detections | ✓ | | | Round-trip status and analyst notes to SentinelOne | ✓ | | | Assign an incident owner (recorded in ContraForce only) | ✓ | | | Receive real-time incident updates in the portal | ✓ | | | Run Contain and Lift Containment Gamebooks | | ✓ | | Run On-Demand Scan Gamebooks | | ✓ | | Trigger Security Delivery Agents on new incidents | ✓ | | You can configure the Detection module without the Response module if you don't need Gamebook response actions for SentinelOne endpoints. Configuring only the Response module without Detection is not a supported configuration — you'd have no incidents for the Gamebooks to run on. *** ## Troubleshooting | Issue | Likely cause | Fix | | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Test Connection fails with a URL / format error | The **Endpoint** is blank, has a trailing slash, or includes a path like `/web/api/...` | Re-enter the bare console URL, e.g. `https://yourtenant.sentinelone.net` | | Test Connection fails with `401 Unauthorized` | The API token is wrong, expired, or was rotated in SentinelOne | Regenerate the token for the affected Service User and paste the new value into ContraForce | | Test Connection fails with `403 Forbidden` on threats | The Detection Service User's role is missing **Threats: View** (or the SOC role was customized) | Verify the **SOC** role is assigned, or check that your custom role has Threats (View, Modify) | | Gamebook response actions are greyed out on SentinelOne incidents | The Response Service User's role is missing Network Quarantine or Initiate Scan permissions | Verify the **IR Team** role is assigned to the Response Service User, or check that your custom role has Endpoints / Agents (View, Disconnect, Reconnect, Initiate Scan) | | No threats appear after 15 minutes | No unresolved threats exist in the scope assigned to the Detection Service User | Verify threats exist in the SentinelOne console within the Sites or Account you selected | | Status updates from ContraForce don't appear in SentinelOne | The Detection Service User's role is missing **Threats: Modify** | Re-assign the SOC role or grant Threats: Modify in the custom role | | An owner assigned in ContraForce doesn't appear in SentinelOne | Expected behavior — SentinelOne threats have no owner field | None needed. Ownership is tracked in ContraForce; status and analyst notes still round-trip | | Polling stopped working after a while | The Detection API token's expiration date has passed | Rotate the token — see the section below | ### Rotating an API Token SentinelOne API tokens expire (up to 1 year). Plan to rotate before expiration. 1. In SentinelOne, navigate to **Settings → Users → Service Users** 2. Open the affected Service User (Detection or Response) 3. Click **Actions → Regenerate API Token** 4. Copy the new token immediately — it is only shown once 5. In ContraForce, reopen the affected module (Detection or Response) 6. Paste the new token into **API Token** and click **Configure and Save** 7. Click **Test Connection** to verify *** ## Related Documentation Learn how Gamebook response actions work Triage and resolve incidents in ContraForce Explore investigation context for an incident's entities Detailed role reference for ContraForce users *** Questions about connecting SentinelOne to ContraForce? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # User & Group Management for Partners Source: https://docs.contraforce.com/guides/onboarding/user-group-management-for-providers Comprehensive guide for MSP/MSSP partners to understand and configure user management, groups, and permissions across parent and child workspaces. This guide addresses the most common challenges MSP/MSSP partners face when setting up user and group management in ContraForce. Understanding the relationship between parent (partner) and child (customer) workspaces is essential for a smooth onboarding experience. ## **Recommended Default Groups** Setting up default groups during initial configuration saves time and ensures consistent access patterns. **Suggested Partner Groups** | Group Name | Description | Suggested Workspace Role | | :-------------------- | :------------------------------------------ | :--------------------------- | | SOC Tier 1 | Front-line analysts handling initial triage | Incident Analyst | | SOC Tier 2 | Senior analysts with response capabilities | Incident Responder | | SOC Managers | Team leads overseeing operations | Admin | | Integration Engineers | Technical staff managing connectors | Data Source Admin | | Account Managers | Customer relationship managers | Incident Analyst (read-only) | > ## For Azure Administrators > > For MSP/MSSP teams already fluent in Azure and Entra administration, ContraForce's user and group management model will feel intuitive once you establish these mental mappings: > > 1. Organization = Root Management Group: The top-level scope where you establish identities that can flow down > 2. Workspace = Subscription / Administrative Unit: The isolation boundary where customer-specific access lives > 3. Organization Groups = Inherited RBAC: Create once, assign many times, automatic access when group membership changes > 4. Workspace Users = AU-scoped delegation: Strictly bounded to one customer's data > 5. Two locations = Two scopes: Just like Azure has IAM blades at different levels, ContraForce has Organization Settings and Workspace Settings > > The key transferable skill is **thinking hierarchically about access scope**—a discipline your team has already developed managing Azure governance at scale. This guide is specifically designed for **MSP/MSSP partners** managing multiple customer workspaces. If you're a single-tenant customer, see the standard [User Management](/guides/general-support/user-management) guide. ## Understanding the Two-Tier Model ContraForce uses a two-tier user management model that separates partner-level access from customer-level access. This is the **most important concept** to understand before configuring users and groups. Your organization's workspace where you manage your team and oversee all customer workspaces Individual customer workspaces where you manage customer-specific users and access ### How the Tiers Work Together ```mermaid theme={null} flowchart TD A[Partner Organization] --> B[Partner Workspace] B --> C[Partner Users & Groups] B --> D[Customer Workspace 1] B --> E[Customer Workspace 2] B --> F[Customer Workspace 3] D --> G[Customer 1 Users & Groups] E --> H[Customer 2 Users & Groups] F --> I[Customer 3 Users & Groups] C --> D C --> E C --> F ``` **Key Insight:** Users and groups created at the **child (customer) level** are only visible within that specific workspace. Users and groups created at the **parent (partner) level** can be assigned access across ALL workspaces. *** ## The Two Places for User & Group Management One of the most common points of confusion is that there are **two different locations** to manage users and groups, each serving a different purpose. ### Location 1: Organization Settings (Partner Level) **Path:** Settings → User Management This is where you manage users and groups for your **partner organization**: | What You Manage | Scope | | -------------------- | --------------------------- | | Partner team members | Access to all workspaces | | Partner user groups | Cross-workspace permissions | | Organizational roles | Partner-level capabilities | Settings-Users ### Location 2: Workspace Settings (Customer Level) **Path:** Workspaces → \[Select Customer] → IAM → Users & Groups This is where you manage users and groups for a **specific customer workspace**: | What You Manage | Scope | | ------------------------ | ------------------- | | Customer users | This workspace only | | Customer groups | This workspace only | | Workspace-specific roles | This workspace only | Workspace-Settings-IAM ### Quick Reference: Where to Go | I Want To... | Go To | | ------------------------------------------------------------ | --------------------- | | Add a partner analyst who needs access to multiple customers | Organization Settings | | Create a group for your SOC team to access all workspaces | Organization Settings | | Add a customer's IT admin to view their own workspace | Workspace Settings | | Create a customer-specific group | Workspace Settings | | Manage your own organization's users | Organization Settings | | Grant a customer limited access to their incidents | Workspace Settings | *** ## Parent vs Child: When to Use Each ### Use Parent (Organization) Level When: Your internal team needs access to multiple or all customer workspaces. Adding them at the organization level lets you assign them to any workspace without recreating their account. **Example:** Adding a new SOC analyst who will handle incidents for 10 customers. Create groups like "Tier 1 Analysts," "Tier 2 Engineers," or "Account Managers" at the organization level, then assign these groups to relevant workspaces. **Example:** Create a "SOC Team" group, add your analysts, then assign this group to all customer workspaces. When you need consistent permissions across multiple customers, define them at the organization level. **Example:** All Tier 1 analysts should have "Incident Responder" role across all customer workspaces. ### Use Child (Workspace) Level When: Customers who need to view their own incidents, reports, or dashboards should be added at the workspace level. **Example:** Adding a customer's CISO who wants to review their security incidents. Groups that only make sense for a specific customer should be created at the workspace level. **Example:** A customer's "Security Committee" group that reviews monthly reports. When customers need read-only or limited access to their workspace. **Example:** A customer's compliance officer who needs incident audit access. *** ## Step-by-Step: Setting Up Partner Users ### Adding a Partner Team Member Go to **Settings** → **User Management** Click the **Add User** button Enter the user's email address (must match their Microsoft Entra ID account) Select the appropriate organization-level role: * **Organization Admin** — Full platform access * **Organization Member** — Standard access Click **Save** to create the user Assign the user to specific customer workspaces (see next section) ### Assigning Users to Customer Workspaces After creating a user at the organization level, grant them access to customer workspaces: Navigate to the **Workspaces** page Click on the customer workspace you want to configure Click the workspace card to open its settings page Select the **Users & Groups** tab Add the organization user or group to this workspace Select the role for this specific workspace: * **Admin** — Full workspace control * **Incident Responder** — Investigate and respond * **Incident Analyst** — View and analyze * **Data Source Admin** — Manage integrations *** ## Step-by-Step: Setting Up Groups Groups simplify permission management by letting you assign roles to multiple users at once. ### Creating an Organization Group Go to **Settings** → **User Management** → **Groups** tab Click **Create Group** Enter a descriptive name (e.g., "SOC Tier 1 Analysts") Select users to add to this group Click **Save** to create the group ### Assigning a Group to Workspaces Navigate to the customer workspace → **IAM** → **Users & Groups** Click **Add Group** Choose the group from your organization Select the workspace role for all group members Click **Save** to apply **Best Practice:** Create groups at the organization level and assign them to workspaces. This way, when you add a new team member to a group, they automatically get access to all workspaces that group is assigned to. *** ## Recommended Default Groups Setting up default groups during initial configuration saves time and ensures consistent access patterns. ### Suggested Partner Groups | Group Name | Description | Suggested Workspace Role | | ------------------------- | ------------------------------------------- | ---------------------------- | | **SOC Tier 1** | Front-line analysts handling initial triage | Incident Analyst | | **SOC Tier 2** | Senior analysts with response capabilities | Incident Responder | | **SOC Managers** | Team leads overseeing operations | Admin | | **Integration Engineers** | Technical staff managing connectors | Data Source Admin | | **Account Managers** | Customer relationship managers | Incident Analyst (read-only) | ### Setting Up Default Groups Before onboarding customers, create your standard groups at the organization level Add your team members to the appropriate groups Document what each group is for and what role it should receive When onboarding new customers, assign these groups with consistent roles **Pro Tip:** Create a simple spreadsheet mapping your groups to workspace roles. This becomes your "template" for onboarding new customers and ensures consistency. *** ## Common Permission Scenarios ### Scenario 1: New SOC Analyst Joining Your Team **Goal:** Add a new analyst who needs to handle incidents for all customers. Settings → User Management → Add User → Enter email → Save Add user to your "SOC Tier 1" or appropriate group The user automatically inherits access to all workspaces the group is assigned to ### Scenario 2: Customer Wants to View Their Incidents **Goal:** Give a customer's security team read-only access to their workspace. Workspaces → Select Customer → IAM Users & Groups → Add User → Enter customer email Select "Incident Analyst" role for read-only access ### Scenario 3: Partner User Can't Access a Workspace **Goal:** Troubleshoot why a partner user can't see a specific customer workspace. Verify the user exists in Settings → User Management Verify the user is in a group that has workspace access Go to the workspace settings and verify the user or their group is listed Ensure a workspace role is assigned (not just added to the workspace) ### Scenario 4: User Has Wrong Permissions **Goal:** User can view incidents but can't respond to them. **Cause:** User has "Incident Analyst" role instead of "Incident Responder." Navigate to the affected workspace Locate in Users & Groups Change role from Incident Analyst to Incident Responder Click Save to apply *** ## Workspace Roles Reference | Role | View Incidents | Respond to Incidents | Manage Gamebooks | Configure Modules | Manage Users | | ---------------------- | :------------: | :------------------: | :--------------: | :---------------: | :----------: | | **Admin** | ✓ | ✓ | ✓ | ✓ | ✓ | | **Incident Responder** | ✓ | ✓ | ✓ | — | — | | **Incident Analyst** | ✓ | — | — | — | — | | **Data Source Admin** | ✓ | — | — | ✓ | — | | **Content Admin** | ✓ | — | — | CMS Only | — | View complete permissions for all roles *** ## Troubleshooting ### Common Issues | Issue | Cause | Solution | | ------------------------------------------------ | ----------------------------- | -------------------------------------------------- | | **User can't see any workspaces** | Not assigned to any workspace | Add user/group to workspaces in workspace settings | | **User can see workspace but can't do anything** | No role assigned | Assign a workspace role to the user or their group | | **User can't add modules** | Insufficient role | User needs Admin or Data Source Admin role | | **Can't add users to workspace** | Not a workspace Admin | Need Admin role on that workspace | | **Group changes not reflected** | Caching | Refresh browser; changes may take a few minutes | | **Customer user sees other customers' data** | Added at wrong level | Remove from org level, add only at workspace level | ### Permission Troubleshooting Flow ```mermaid theme={null} flowchart TD A[User Can't Access Something] --> B{Is user in Organization?} B -->|No| C[Add user to Organization] B -->|Yes| D{Is user assigned to Workspace?} D -->|No| E[Add user/group to Workspace] D -->|Yes| F{Does user have correct Role?} F -->|No| G[Update workspace role] F -->|Yes| H[Check module-specific permissions] C --> D E --> F G --> I[Issue Resolved] H --> I ``` *** ## Best Practices Set up your standard groups (SOC Tier 1, Tier 2, Managers, etc.) before onboarding any customers. This creates a consistent template to follow. Assigning groups to workspaces instead of individual users makes it much easier to onboard new team members—just add them to the appropriate group. Create a simple reference document showing which groups get which roles. This ensures consistency across all customer onboardings. Never add customer users at the organization level unless they need cross-workspace access. This prevents accidental data exposure. Name groups clearly (e.g., "SOC-Tier1-Analysts" not "Group1") so anyone can understand their purpose. Review user and group assignments quarterly to remove departed employees and ensure permissions are still appropriate. After setting up permissions, test access with a non-admin account to verify users see what they should see. *** ## Onboarding Checklist Use this checklist when onboarding a new customer workspace: ### Pre-Onboarding (One-Time Setup) * Create standard organization groups (SOC Tier 1, Tier 2, etc.) * Add your team members to appropriate groups * Document group-to-role mappings ### Per-Customer Onboarding * Create/configure customer workspace * Assign organization groups to workspace with appropriate roles * Verify partner team can access the workspace * Add customer users at workspace level (if needed) * Create customer-specific groups (if needed) * Test access with a non-admin account * Document any customer-specific permission requirements *** ## Frequently Asked Questions The two locations serve different purposes: Organization Settings manages your partner team (who may need access to multiple customers), while Workspace Settings manages access to a specific customer (including customer users who should only see their own data). Not if set up correctly. Customer users should only be added at the workspace level, not at the organization level. This ensures they can only see their own workspace. Add them to an organization group that's already assigned to all customer workspaces. They'll inherit access automatically. Yes. A user might be an Admin in one workspace and an Incident Responder in another. Roles are assigned per-workspace. They lose access to all workspaces that group was assigned to (unless they have individual access or belong to another group with access). Yes, if you give them the Admin role on their workspace. They can then add/remove users within their workspace only. *** ## Related Guides Complete permissions for each role Managing customer workspaces Full onboarding process Cross-workspace management *** Questions about user and group management? Contact us at [support@contraforce.com](mailto:support@contraforce.com) or request hands-on onboarding support for your first few customer deployments. # Workspace Permissions and Consent Source: https://docs.contraforce.com/guides/onboarding/workspace-onboarding Understanding the Microsoft Entra ID permissions and enterprise applications required for ContraForce workspace deployments. # Understanding Enterprise Applications Before ContraForce can protect your organization, specific Microsoft Entra ID permissions must be granted to enable secure communication between ContraForce services and your Microsoft environment. This article explains the enterprise applications deployed during onboarding and the permissions each requires. ## Getting Started **ContraForce Portal:** [portal.contraforce.com](https://portal.contraforce.com) ### Required Roles for Onboarding To complete the ContraForce onboarding process and consent to the required enterprise applications, the following roles must be assigned to the user performing the onboarding: | Role | Purpose | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Global Administrator** | Required to grant admin consent for ContraForce enterprise applications (service principals) in Microsoft Entra ID. Cloud Application Administrator and Application Administrator cannot grant consent for Microsoft Graph application permissions. | | **Subscription Owner** | Required only for Microsoft Sentinel onboarding and Agent Center/agent deployment. Not needed for XDR-only module. | If your organization separates these roles across different users, coordinate with both administrators to complete the onboarding process. **Consent model.** ContraForce enterprise applications are consented with **application (app-only)** Microsoft Graph permissions. Admin consent for Microsoft Graph application permissions must be granted by a **Global Administrator** — Cloud Application Administrator and Application Administrator cannot grant it. Global Administrator is required for the one-time consent only and is not retained; activate it just-in-time with Privileged Identity Management (PIM) and deactivate afterward. Because actions run as the application (no signed-in user required), operator control is enforced through **Gamebook approval gates** — only Workspace Owners can approve high-impact actions — and a complete **audit trail** in the Gamebooks History page. ## Overview of ContraForce Enterprise Applications ContraForce uses a modular application architecture designed around the principle of least privilege. Rather than requesting all permissions through a single application, ContraForce distributes responsibilities across purpose-built enterprise applications. This approach ensures that each application only receives the permissions necessary for its specific function. When you onboard with ContraForce, the following enterprise applications are registered in your Microsoft Entra tenant: | Application | Primary Function | | ---------------------------------- | --------------------------------------------------------- | | ContraForce API | Core API services and Azure resource management | | ContraForce Portal | User authentication and profile management | | ContraForce Sentinel Hunting | Log Analytics queries and incident evidence retrieval | | ContraForce for MDE | Microsoft Defender for Endpoint visibility and management | | ContraForce Gamebooks for Identity | Identity-based automated response actions | | ContraForce Gamebooks for MDE | Endpoint-based automated response actions | ## Onboarding Consent Flow ### Initial Registration 1. Navigate to [portal.contraforce.com](https://portal.contraforce.com) 2. Click **Register with Microsoft** 3. Sign in with your Microsoft Work account (must have the Global Administrator role to grant admin consent for the service principals; Subscription Owner also needed for Sentinel and Agent Center) 4. Consent to the **ContraForce API** permissions 5. Consent to the **ContraForce Portal** permissions The **ContraForce API** and **ContraForce Portal** consents appear as two separate Microsoft consent prompts. After these core app consents are granted, you configure module-specific permissions per workspace from the **Modules** tab. ### Additional Permissions After initial onboarding, additional enterprise application permissions can be configured from **Settings → Permissions** within the ContraForce portal based on the features your organization requires. ## Enterprise Application Details ### ContraForce API The ContraForce API is the core service principal that enables communication between ContraForce services and Microsoft APIs including Microsoft Graph and Azure Resource Manager. | Permission | Type | Admin Consent | Purpose | | ----------------------------------------------- | --------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `offline_access` | Delegated | No | Enables refresh token acquisition for persistent sessions | | `openid` | Delegated | No | Allows sign-in using OpenID Connect | | `profile` | Delegated | No | Retrieves signed-in user's name and object ID | | `Application.Read.All` | Delegated | Yes | Evaluates which ContraForce service principals have been consented | | `RoleManagement.Read.Directory` | Delegated | Yes | Evaluates user roles for Portal access control | | `User.Read.All` | Delegated | Yes | Reads user profile data for user management operations | | `user_impersonation` (Azure Service Management) | Delegated | No | Used throughout platform operation, not only at onboarding: backs Microsoft Sentinel access; enumeration of subscriptions, resource groups, and identity role assignments; and, with AI Agents, reading model capacities and quotas and pushing agent model and harness updates | ### ContraForce Portal The ContraForce Portal service principal handles user authentication through Microsoft's OpenID Connect implementation and retrieves basic profile information for signed-in users. | Permission | Type | Admin Consent | Purpose | | ---------------- | --------- | ------------- | --------------------------------------------- | | `offline_access` | Delegated | No | Enables refresh token acquisition | | `openid` | Delegated | No | Allows sign-in using OpenID Connect | | `profile` | Delegated | No | Retrieves signed-in user's name and object ID | ### ContraForce Sentinel Hunting This service principal enables direct queries to your Microsoft Sentinel workspace for incident investigation and advanced hunting capabilities. | Permission | Type | Admin Consent | Purpose | | --------------------------- | --------- | ------------- | ------------------------------------------------------------------------------- | | `Data.Read` (Log Analytics) | Delegated | No | Queries Log Analytics workspace data for incident evidence and advanced hunting | ### ContraForce for MDE This service principal provides visibility into Microsoft Defender for Endpoint data, enabling endpoint monitoring and threat intelligence display in the ContraForce portal. | Permission | Type | Admin Consent | Purpose | | -------------------------------------------------- | --------- | ------------- | --------------------------------------------------- | | `ThreatHunting.Read.All` | Delegated | Yes | Enables threat hunting queries | | `SecurityAlert.Read.All` | Delegated | Yes | Displays Microsoft Graph Security alerts | | `SecurityIncident.Read.All` | Delegated | Yes | Displays Microsoft Graph Security incidents | | `SecurityIncident.ReadWrite.All` | Delegated | Yes | Manages Microsoft Graph Security incidents | | `Incident.Read` (Microsoft Threat Protection) | Delegated | Yes | Reads threat protection incidents | | `Incident.ReadWrite` (Microsoft Threat Protection) | Delegated | Yes | Manages threat protection incidents | | `AdvancedQuery.Read` (WindowsDefenderATP) | Delegated | Yes | Queries raw event and incident data | | `Alert.Read` (WindowsDefenderATP) | Delegated | Yes | Displays Defender alerts | | `Machine.Read` (WindowsDefenderATP) | Delegated | Yes | Retrieves endpoint profile details | | `Score.Read` (WindowsDefenderATP) | Delegated | Yes | Displays Threat and Vulnerability Management scores | | `Vulnerability.Read` (WindowsDefenderATP) | Delegated | Yes | Displays vulnerability information | ### ContraForce Gamebooks for Identity This service principal enables automated response actions targeting user entities, including session invalidation, account lockout, and password reset capabilities. **Delegated Permissions (on-behalf-of flows)** | Permission | Type | Admin Consent | Purpose | | ----------------------------------------- | --------- | ------------- | -------------------------------------------- | | `User.ReadWrite.All` | Delegated | Yes | Invalidates user sessions and locks accounts | | `User.AuthenticationMethod.ReadWrite.All` | Delegated | Yes | Resets user passwords | | `User.ManagedIdentities.All` | Delegated | Yes | Manages user identities | | `UserAuthenticationMethod.ReadWrite` | Delegated | Yes | Resets user passwords | **Application Permissions (Default)** | Permission | Type | Admin Consent | Purpose | | -------------------- | ----------- | ------------- | -------------------------------------------------------------------------------- | | `User.ReadWrite.All` | Application | Yes | Enables automated session invalidation and account lockout without user presence | Application permissions allow ContraForce to execute Gamebook actions without requiring a service provider user to be signed in. Password reset runs on-behalf-of (delegated) by default; enabling the optional **service-provider password reset** add-on lets it run app-only via a customer-consented permission and an Authentication Administrator directory role. See the [Enterprise Applications Reference](/guides/technical/enterprise-applications#contraforce-gamebooks-for-identity). ### ContraForce Gamebooks for MDE This service principal enables automated response actions targeting endpoint entities, including device isolation, antivirus scans, and file quarantine operations. **Delegated Permissions (on-behalf-of flows)** | Permission | Type | Admin Consent | Purpose | | --------------------------- | --------- | ------------- | ---------------------------------------------------- | | `Machine.Isolate` | Delegated | Yes | Isolates endpoints from the network | | `Machine.Offboard` | Delegated | Yes | Offboards endpoints from Defender | | `Machine.Scan` | Delegated | Yes | Initiates Microsoft Defender Antivirus scans | | `Machine.StopAndQuarantine` | Delegated | Yes | Stops file execution and quarantines malicious files | | `Alert.ReadWrite` | Delegated | Yes | Reads and writes Defender alerts | **Application Permissions (Default)** | Permission | Type | Admin Consent | Purpose | | --------------------------- | ----------- | ------------- | ---------------------------------------- | | `Machine.Isolate` | Application | Yes | Isolates endpoints without user presence | | `Machine.Scan` | Application | Yes | Initiates scans without user presence | | `Machine.StopAndQuarantine` | Application | Yes | Quarantines files without user presence | Application permissions enable service providers to execute endpoint response actions in customer tenants without requiring a user to be actively signed in. ## Why This Architecture? ContraForce's modular application architecture provides several benefits: * **Principle of Least Privilege** — Each application only requests the permissions necessary for its specific function * **Granular Control** — Organizations can enable only the features they need without granting unnecessary permissions * **Reduced Friction** — Service providers can onboard customers incrementally based on their security maturity * **Improved Security Posture** — Limiting permissions reduces potential attack surface ## Managing Permissions After onboarding, you can review and manage ContraForce enterprise application permissions in two locations: 1. **ContraForce Portal:** Navigate to **Settings → Permissions** to consent to additional service principals 2. **Microsoft Entra Admin Center:** Review enterprise applications and their granted permissions under **Enterprise Applications** For questions about specific permissions or to request changes to your ContraForce configuration, contact your ContraForce support: [support@contraforce.com](mailto:support@contraforce.com). # Workspace Onboarding Verification Source: https://docs.contraforce.com/guides/onboarding/workspace-onboarding-checklist Post-onboarding verification runbook for service providers. Use this checklist after a customer admin finishes consenting their modules to confirm the deployment is healthy. A focused verification runbook to run **after a customer admin finishes onboarding their workspace**. Use it to confirm every part of the deployment is healthy before declaring the workspace go-live. **Who is this for?** Service-provider operations and onboarding leads verifying a freshly onboarded customer workspace. For the steps that come before this point (pre-onboarding the customer, the customer's own onboarding journey), see: Pre-onboard the customer workspace What the customer admin sees on their side *** ## Core Verification Run these checks first. Any failure here blocks go-live. * The customer workspace shows **Active** status (not **Pending customer setup**) in your Workspace Center * You received the **Customer onboarding complete** real-time notification in the portal * Open the customer's workspace and confirm every pre-selected module shows **Connected** * Navigate to the **Command Dashboard** filtered to the customer workspace and verify incidents appear (allow 5 to 15 minutes for initial sync) * Open an incident and confirm the **Workbench** loads with entity context and timeline * Verify Gamebook response actions appear on incident entities (do not execute on production entities) **Don't test response actions on production entities.** Gamebook actions like "Isolate Device" or "Disable User" execute immediately. Use a test account or device if you want to verify functionality. *** ## Sentinel-Specific Verification Skip this section if the customer is on Defender-only. * Sentinel incidents are syncing alongside Defender for Endpoint incidents * Azure Lighthouse delegation completed successfully in the customer's subscription * Supporting Azure infrastructure deployed by Sentinel consent shows **Active** * Navigate to **Content Management System (CMS)** and verify the detection rule library is accessible * Log search is functional Sentinel Azure infrastructure is provisioned in the background after the customer grants Sentinel consent. If verification fails, allow 5 to 10 extra minutes for the deployment to complete before retrying. *** ## If Something Fails | Symptom | Likely cause | Where to look | | ----------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Workspace stuck in **Pending customer setup** | Customer hasn't finished consenting their modules | Resend the invite or contact the POC | | Module shows **Not Connected** in the customer's view | Consent skipped or denied | Customer can re-open the picker from their Get Started checklist ([Re-opening pickers](/guides/onboarding/customer-workspace-onboarding#re-opening-the-detection-or-response-picker)) | | No incidents appearing after 30 minutes | No active incidents in source system | Check Defender, Sentinel, or CrowdStrike console for existing incidents | | Sentinel infrastructure didn't deploy | Insufficient Azure permissions | Verify customer admin has Subscription Owner | | Gamebook actions unavailable on entities | Response module not connected | Customer reconnects the response module from their Modules tab | For sign-in failures encountered by the customer admin, point them to the [Customer onboarding sign-in failed troubleshooting](/guides/onboarding/customer-workspace-onboarding#troubleshooting-sign-in-failed). *** ## After Verification Passes Two follow-ups close out the onboarding. ### Assign your team to the workspace Use organization-level groups rather than individual users so future onboardings are consistent. | Role | Best for | | ------------------ | ------------------------------------------- | | Admin | Team leads, workspace owners | | Incident Responder | SOC analysts who need response capabilities | | Incident Analyst | Junior analysts, read-only access | | Data Source Admin | Integration specialists | | Content Admin | Detection engineers (Sentinel only) | Detailed user and group setup, including organization-level groups ### Configure notifications (Sentinel only) Severity filters, distribution group setup, and test notification verification *** ## Go-Live Communication * Notify the customer that ContraForce is live on their environment * Share relevant documentation links with the customer team * Confirm the customer knows how to reach your delivery team * Document any customer-specific configuration notes or permission exceptions * Schedule a follow-up check-in within 7 days to review initial incident volume and rule tuning *** **Need help?** Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Auditing Enterprise App Permissions Source: https://docs.contraforce.com/guides/technical/auditing-enterprise-app-permissions Independently verify the permissions granted to ContraForce enterprise applications in your Microsoft Entra ID tenant using read-only audit scripts. **Who is this for?** IT administrators, security teams, and change advisory board (CAB) reviewers who need to independently verify the permissions granted to ContraForce enterprise applications before or after onboarding. ## Overview ContraForce provides two audit scripts that enumerate the permissions granted to ContraForce enterprise applications in your Microsoft Entra ID tenant. Both scripts produce an identical JSON output that you can compare against the [Enterprise Applications Reference](/guides/technical/enterprise-applications) to verify that only the documented permissions are in place. Choose the script that fits your environment: | | PowerShell | Python | | -------------------- | ----------------------------------------------- | ------------------------------------------------ | | **Best for** | Microsoft-native environments | Cross-platform / CLI-first teams | | **Runtime** | PowerShell 7.0+ (`pwsh`) | Python 3.10+ | | **Auth method** | Microsoft Graph PowerShell SDK | Azure CLI (`az login`) | | **Dependencies** | `Microsoft.Graph` modules (Microsoft-published) | `azure-identity` (Microsoft-published) + `httpx` | | **Government cloud** | `-Cloud AzureUSGovernment` | `-c AzureUSGovernment` | These scripts are **read-only**. They do not create, modify, or delete any objects in your tenant. All API calls are HTTP `GET` requests to Microsoft Graph. ## What the Scripts Access Both scripts make read-only queries to the Microsoft Graph REST API. The specific endpoint depends on your cloud environment: | Environment | Graph API Base | Identity Platform | | ---------------- | ---------------------------------- | ----------------------------------- | | Commercial / GCC | `https://graph.microsoft.com/v1.0` | `https://login.microsoftonline.com` | | GCC High / DoD | `https://graph.microsoft.us/v1.0` | `https://login.microsoftonline.us` | No other endpoints are contacted beyond the Microsoft identity platform for token acquisition. | Graph API Endpoint | Purpose | | ---------------------------------------------------- | ----------------------------------------------------------------------------------- | | `GET /me` | Resolve the authenticated operator's identity (UPN and object ID) | | `GET /organization` | Resolve the tenant ID | | `GET /servicePrincipals` | Look up ContraForce and Microsoft resource API service principals by name or app ID | | `GET /servicePrincipals/{id}/oauth2PermissionGrants` | Read delegated permission grants for each application | | `GET /servicePrincipals/{id}/appRoleAssignments` | Read application permission assignments for each application | ### Data in the Output File The output JSON contains: * **Application names and app IDs** for each ContraForce enterprise application * **Permission names and descriptions** resolved to human-readable values * **The resource API** each permission targets (Microsoft Graph, WindowsDefenderATP, etc.) * **Metadata**: timestamp, tenant ID, cloud environment, authenticated operator, and tool version The output does not contain secrets, tokens, or user data beyond the operator identifier. In government cloud environments, the operator's UPN is automatically redacted and replaced with their Entra object ID (an opaque GUID). See [Output File Access Control](#output-file-access-control) for handling guidance. ## Directory Role Assignments The scripts on this page report **Microsoft Graph permission grants** — delegated (`oauth2PermissionGrants`) and application (`appRoleAssignments`). They do **not** enumerate **Entra directory role** memberships, which are a separate authorization mechanism that Graph permission audits do not surface. One ContraForce capability uses a directory role. If you enable the optional **service-provider password reset** add-on on the Identity module, the **ContraForce Gamebooks for Identity** service principal is assigned the **Authentication Administrator** role so the Reset Password Gamebook can run app-only (see the [Enterprise Applications Reference](/guides/technical/enterprise-applications#contraforce-gamebooks-for-identity)). Review that assignment directly with the same read-only access the audit scripts already use (`Directory.Read.All`): ```powershell PowerShell theme={null} # Connect-MgGraph -Scopes "Directory.Read.All" # Commercial app ID shown; government environments use a different ID (contact support). $sp = Get-MgServicePrincipal -Filter "appId eq '36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a'" Get-MgRoleManagementDirectoryRoleAssignment -Filter "principalId eq '$($sp.Id)'" | ForEach-Object { $def = Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $_.RoleDefinitionId [pscustomobject]@{ ServicePrincipal = $sp.DisplayName; Role = $def.DisplayName } } ``` ```bash Graph API theme={null} # Requires Directory.Read.All. Resolve the service principal object id, then its role assignments. GET https://graph.microsoft.com/v1.0/servicePrincipals(appId='36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a')?$select=id GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=principalId eq ''&$expand=roleDefinition ``` An empty result means the add-on is not enabled (or has been turned off). When it is enabled, the expected assignment is **Authentication Administrator** — a role scoped to non-administrator users that cannot reset passwords for Global Administrators or other higher-privileged roles. ## Applications Audited In **commercial (AzureCloud)** environments, both scripts use built-in app IDs that match the [Quick Reference](/guides/technical/enterprise-applications#quick-reference) table: | Application | App ID | | ---------------------------------- | -------------------------------------- | | ContraForce API | `24d97bc0-8f2b-45d5-8e0b-7fe286732ef2` | | ContraForce Portal | `8b7cb435-9526-47ee-b79a-34433f0daad2` | | ContraForce for MDE | `6efccc6a-f0d3-49e5-92d0-17d4afa9ba52` | | ContraForce Gamebooks for MDE | `ad7b0e79-3c37-4408-bf8f-eb89522cc920` | | ContraForce Gamebooks for Identity | `36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a` | | ContraForce Gamebooks for Email | `44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d` | | ContraForce Sentinel Hunting | `6bf1c74d-7ade-4671-a507-166936f89a1f` | You can verify these app IDs in the **Microsoft Entra Admin Center** under **Enterprise Applications** before running the scripts. **Government cloud environments** use different app IDs. Contact [support@contraforce.com](mailto:support@contraforce.com) to obtain the app IDs for your environment. Pass them to the script via `-AppsFile` (PowerShell) or `--apps-file` (Python) — a JSON file containing an array of objects with `Name`/`AppId` (PowerShell) or `name`/`app_id` (Python) fields. ## Prerequisites **Runtime:** [PowerShell 7.0+](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell) (`pwsh`, not Windows PowerShell 5.1) **Microsoft Graph modules:** ```powershell theme={null} Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Applications -Scope CurrentUser ``` **Required Graph scopes:** `Application.Read.All` and `Directory.Read.All` **Authenticate before running:** ```powershell theme={null} # Commercial / GCC (-Cloud AzureCloud, the default) Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" # GCC High (-Cloud AzureUSGovernment) Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" -Environment USGov # DoD (-Cloud AzureUSGovernment) Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" -Environment USGovDoD ``` For environments without a browser, use device code flow: ```powershell theme={null} Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" -UseDeviceCode ``` **Runtime:** [Python 3.10+](https://devguide.python.org/versions/) (older versions will produce a clear error message) **Azure CLI:** [Install the Azure CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) and sign in: ```bash theme={null} # Commercial / GCC az login # GCC High / DoD az cloud set --name AzureUSGovernment az login ``` **Python packages:** ```bash theme={null} pip install azure-identity httpx ``` The script uses `AzureCliCredential` from the Microsoft-published `azure-identity` library, which reuses your existing `az login` session. The `httpx` library handles HTTP communication with the Graph API. For stricter environments, pin exact versions: `pip install azure-identity==1.19.0 httpx==0.28.1`. If your organization uses an internal package mirror, install from that source instead of public PyPI. ### Minimum Permissions The account running the script needs read access to service principals and their permission grants. The minimum Microsoft Entra ID role is **Directory Reader**, or you can grant the following Microsoft Graph API permissions directly: | Graph Permission | Type | Purpose | | ---------------------- | --------- | ----------------------------------------------------- | | `Application.Read.All` | Delegated | Read service principal properties and app roles | | `Directory.Read.All` | Delegated | Read delegated permission grants and role assignments | These are **read-only** permissions. They do not grant the ability to modify applications, permissions, or any other tenant objects. ## Running the Scripts ```powershell theme={null} # Commercial (default) pwsh -File Audit-EnterpriseApps.ps1 # Custom output path pwsh -File Audit-EnterpriseApps.ps1 -OutputPath ./audit-2026-02-12.json # Government (GCC High / DoD) — requires -AppsFile pwsh -File Audit-EnterpriseApps.ps1 -Cloud AzureUSGovernment -AppsFile ./gov-apps.json ``` The `-Cloud` parameter value must match the cloud you authenticated to with `Connect-MgGraph -Environment`. The script validates this and exits with an error if there is a mismatch. Government environments require `-AppsFile` because app IDs differ from commercial. ```bash theme={null} # Commercial (default) python audit_enterprise_apps.py # Custom output path python audit_enterprise_apps.py -o audit-2026-02-12.json # Government (GCC High / DoD) — requires --apps-file python audit_enterprise_apps.py -c AzureUSGovernment -a gov-apps.json ``` The `-c` flag must match the Azure CLI cloud set via `az cloud set --name`. Government environments require `az cloud set --name AzureUSGovernment` before `az login` and `--apps-file` (`-a`) because app IDs differ from commercial. Both scripts display progress as they resolve permissions and will report a summary when complete. A **non-zero exit code** means one or more applications were not found in the tenant — this is expected if you haven't consented all ContraForce applications (for example, Sentinel Hunting is only required for XDR + SIEM deployments). ## Government Cloud Environments (GCC High / DoD) Both scripts support Microsoft Azure Government cloud environments used by public sector organizations subject to CMMC, FedRAMP, or ITAR requirements. Both scripts use the same `-Cloud` / `-c` parameter values, which match the `az cloud set --name` values: | Cloud | Value | PowerShell | Python | | --------------------------- | ------------------- | -------------------------- | ---------------------- | | Commercial (default) | `AzureCloud` | `-Cloud AzureCloud` | `-c AzureCloud` | | Government (GCC High / DoD) | `AzureUSGovernment` | `-Cloud AzureUSGovernment` | `-c AzureUSGovernment` | When running in a government cloud environment, the scripts automatically: 1. **Use the correct Graph endpoint** — `graph.microsoft.us` instead of `graph.microsoft.com` 2. **Redact the operator's UPN** — Records the Entra object ID (an opaque GUID) instead of the User Principal Name in the `generatedBy` metadata field 3. **Restrict output file permissions** — Limits file access to the current user only (PowerShell: Windows ACL; Python: POSIX `chmod 600`) You can also redact the UPN in commercial environments using the `-RedactUPN` switch (PowerShell) or `--redact-upn` flag (Python). The script validates that the connected session matches the requested cloud environment. If you specify `-Cloud AzureUSGovernment` but are connected to a commercial Graph session, the script will exit with an error and instructions to reconnect. ## Audit Scripts ```powershell Audit-EnterpriseApps.ps1 icon="terminal" expandable theme={null} #Requires -Version 7.0 #Requires -Modules Microsoft.Graph.Authentication, Microsoft.Graph.Applications <# .SYNOPSIS Audits ContraForce enterprise application permissions in the current Microsoft Entra ID tenant. .DESCRIPTION Queries Microsoft Graph for all documented ContraForce enterprise applications, resolves their delegated and application permissions to human-readable names, and outputs a structured JSON file suitable for diffing against documentation. Supports Commercial, GCC High, and DoD cloud environments. Requires: - Microsoft.Graph PowerShell modules: Install-Module Microsoft.Graph.Applications -Scope CurrentUser - An authenticated Microsoft Graph session with Directory.Read.All: Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" -Environment USGov - The target tenant must have the ContraForce enterprise applications consented .PARAMETER OutputPath Path for the output JSON file. Defaults to enterprise-apps-audit.json in the current directory. .PARAMETER Cloud The Microsoft cloud environment to audit. Uses the same values as 'az cloud set --name': AzureCloud (Commercial) or AzureUSGovernment (GCC High / DoD). Defaults to AzureCloud. .PARAMETER AppsFile Path to a JSON file listing the applications to audit. Each entry must have 'Name' and 'AppId' fields. Required for government cloud environments where app IDs differ from commercial. Contact support@contraforce.com for your environment's app IDs. .PARAMETER RedactUPN When set, records the operator's Entra object ID instead of the User Principal Name in the generatedBy metadata field. Automatically enabled for AzureUSGovernment to avoid recording PII in audit artifacts. .EXAMPLE pwsh -File Audit-EnterpriseApps.ps1 pwsh -File Audit-EnterpriseApps.ps1 -OutputPath ./audit-2026-02-12.json pwsh -File Audit-EnterpriseApps.ps1 -Cloud AzureUSGovernment -AppsFile ./gov-apps.json -OutputPath ./audit-gov.json #> param( [string]$OutputPath = "enterprise-apps-audit.json", [ValidateSet("AzureCloud", "AzureUSGovernment")] [string]$Cloud = "AzureCloud", [string]$AppsFile, [switch]$RedactUPN ) $ErrorActionPreference = "Stop" # ── Cloud environment metadata ─────────────────────────────────────────────── $EnvironmentNames = @{ "AzureCloud" = "Commercial" "AzureUSGovernment" = "US Government (GCC High / DoD)" } # Maps our -Cloud parameter values to the Connect-MgGraph -Environment values # that Microsoft Graph PowerShell SDK uses internally. GCC High uses "USGov" # and DoD uses "USGovDoD" — both map to our single "AzureUSGovernment" value. $ValidMgEnvironments = @{ "AzureCloud" = @("Global") "AzureUSGovernment" = @("USGov", "USGovDoD") } # ── Pre-flight: verify Microsoft Graph authentication ───────────────────────── $context = Get-MgContext if (-not $context) { $suggestedEnv = $ValidMgEnvironments[$Cloud][0] $envFlag = if ($Cloud -ne "AzureCloud") { " -Environment $suggestedEnv" } else { "" } Write-Error ("No active Microsoft Graph session. Connect first:`n" + " Connect-MgGraph -Scopes 'Application.Read.All','Directory.Read.All'$envFlag`n" + " Connect-MgGraph -Scopes 'Application.Read.All','Directory.Read.All'$envFlag -UseDeviceCode") exit 1 } # Validate the connected environment matches the requested one. # Connect-MgGraph -Environment uses "Global", "USGov", "USGovDoD" internally, # so we check against the valid set for the -Cloud value the operator chose. if ($context.Environment -notin $ValidMgEnvironments[$Cloud]) { $validList = $ValidMgEnvironments[$Cloud] -join "' or '" Write-Error ("Environment mismatch: connected to '$($context.Environment)' " + "but -Cloud '$Cloud' expects '$validList'.`n" + "Disconnect and reconnect to the correct environment:`n" + " Disconnect-MgGraph`n" + " Connect-MgGraph -Scopes 'Application.Read.All','Directory.Read.All' -Environment $($ValidMgEnvironments[$Cloud][0])") exit 1 } # Resolve operator identity via Graph API (avoids parsing access tokens) $meResponse = Invoke-MgGraphRequest -Uri '/me?$select=id,userPrincipalName' -Method GET $operatorOid = $meResponse.id $operatorUpn = $meResponse.userPrincipalName # Auto-enable UPN redaction for government environments $effectiveRedact = $RedactUPN.IsPresent -or ($Cloud -ne "AzureCloud") $generatedBy = if ($effectiveRedact) { $operatorOid } else { $operatorUpn } $envDisplayName = $EnvironmentNames[$Cloud] Write-Host "Environment: $envDisplayName ($Cloud)" -ForegroundColor Green Write-Host "Authenticated as: $generatedBy (Tenant: $($context.TenantId))" -ForegroundColor Green # ── ContraForce enterprise applications to audit ────────────────────────────── # App IDs differ by cloud environment. The commercial IDs are built-in; # government cloud app IDs are provided by ContraForce upon request and # passed via -AppsFile. if ($AppsFile) { $AppsToAudit = Get-Content $AppsFile -Raw | ConvertFrom-Json } elseif ($Cloud -eq "AzureCloud") { $AppsToAudit = @( @{ Name = "ContraForce API"; AppId = "24d97bc0-8f2b-45d5-8e0b-7fe286732ef2" } @{ Name = "ContraForce Portal"; AppId = "8b7cb435-9526-47ee-b79a-34433f0daad2" } @{ Name = "ContraForce for MDE"; AppId = "6efccc6a-f0d3-49e5-92d0-17d4afa9ba52" } @{ Name = "ContraForce Gamebooks for MDE"; AppId = "ad7b0e79-3c37-4408-bf8f-eb89522cc920" } @{ Name = "ContraForce Gamebooks for Identity"; AppId = "36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a" } @{ Name = "ContraForce Gamebooks for Email"; AppId = "44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d" } @{ Name = "ContraForce Sentinel Hunting"; AppId = "6bf1c74d-7ade-4671-a507-166936f89a1f" } ) } else { Write-Error ("Government cloud environments require -AppsFile.`n" + "App IDs differ by cloud environment. Contact support@contraforce.com`n" + "to obtain the app IDs for your environment.") exit 1 } # ── Well-known first-party resource APIs ────────────────────────────────────── # Maps Entra object IDs → friendly names for the Microsoft APIs that ContraForce # integrates with. Object IDs are tenant-local so we resolve them at runtime. $ResourceAPIs = @( "Microsoft Graph" "Windows Azure Service Management API" "WindowsDefenderATP" "Microsoft Threat Protection" "Log Analytics API" ) # ── Friendly display names for resource APIs ────────────────────────────────── $FriendlyNames = @{ "Windows Azure Service Management API" = "Azure Service Management" } # ── Permission lookup tables ───────────────────────────────────────────────── $AppRoleLookup = @{} # resourceSPId -> { roleId -> { name, description } } $DescByNameLookup = @{} # resourceSPId -> { scopeName -> description } $ResourceNameById = @{} # resourceSPId -> friendly name function Register-ServicePrincipal { param( [Parameter(Mandatory)]$Sp, [string]$FriendlyName ) $id = $Sp.Id $ResourceNameById[$id] = if ($FriendlyName) { $FriendlyName } else { $Sp.DisplayName } $roles = @{} foreach ($role in $Sp.AppRoles) { $roles[$role.Id] = @{ name = $role.Value; description = $role.Description } } $AppRoleLookup[$id] = $roles $descByName = @{} foreach ($scope in $Sp.Oauth2PermissionScopes) { $descByName[$scope.Value] = $scope.AdminConsentDescription } $DescByNameLookup[$id] = $descByName } # ── Resolve resource API service principals ─────────────────────────────────── Write-Host "Resolving resource API service principals..." -ForegroundColor Cyan foreach ($apiName in $ResourceAPIs) { $sp = Get-MgServicePrincipal -Filter "displayName eq '$apiName'" ` -Property Id, DisplayName, AppRoles, Oauth2PermissionScopes -Top 1 if (-not $sp) { Write-Warning "Resource API not found in tenant: $apiName" continue } $friendly = if ($FriendlyNames.ContainsKey($sp.DisplayName)) { $FriendlyNames[$sp.DisplayName] } else { $sp.DisplayName } Register-ServicePrincipal -Sp $sp -FriendlyName $friendly Write-Host " Resolved: $friendly ($($sp.Id)) — $($AppRoleLookup[$sp.Id].Count) app roles, $($DescByNameLookup[$sp.Id].Count) delegated scopes" } # ── Also index ContraForce apps themselves (they expose internal scopes) ────── # Why startswith('ContraForce')? # Some ContraForce apps delegate to each other via custom oauth2 scopes (e.g. the # Portal app exposes scopes consumed by the API app). To resolve these internal # cross-app scopes to human-readable names instead of raw GUIDs, we index ALL # service principals whose display name starts with "ContraForce" — not just the # 8 customer-facing apps listed in $AppsToAudit. Permissions that originate from # these internal apps are tagged with "internal": true in the output so auditors # can distinguish them from Microsoft first-party API permissions. $AllCFServicePrincipals = Get-MgServicePrincipal ` -Filter "startswith(displayName, 'ContraForce')" ` -Property Id, DisplayName, AppRoles, Oauth2PermissionScopes -All foreach ($cfSp in $AllCFServicePrincipals) { if (-not $ResourceNameById.ContainsKey($cfSp.Id)) { Register-ServicePrincipal -Sp $cfSp } } # ── Audit each application ─────────────────────────────────────────────────── $results = [System.Collections.Generic.List[object]]::new() foreach ($app in $AppsToAudit) { Write-Host "`nAuditing: $($app.Name) ($($app.AppId))..." -ForegroundColor Cyan # Find the service principal in this tenant $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'" ` -Property Id, DisplayName, AppId -Top 1 if (-not $sp) { Write-Warning " NOT FOUND in tenant — skipping" $results.Add([ordered]@{ applicationName = $app.Name appId = $app.AppId status = "NOT_FOUND" delegatedPermissions = @() applicationPermissions = @() }) continue } $spId = $sp.Id # ── Delegated permissions (oauth2PermissionGrants) ──────────────────────── $grants = Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $spId -All $delegated = [System.Collections.Generic.List[object]]::new() foreach ($grant in $grants) { $resourceId = $grant.ResourceId $resourceName = if ($ResourceNameById.ContainsKey($resourceId)) { $ResourceNameById[$resourceId] } else { $resourceId } $isInternal = $resourceName -like "ContraForce *" $scopeNames = ($grant.Scope -split ' ') | Where-Object { $_ -ne '' } | Sort-Object foreach ($scope in $scopeNames) { $desc = if ($DescByNameLookup.ContainsKey($resourceId) -and $DescByNameLookup[$resourceId].ContainsKey($scope)) { $DescByNameLookup[$resourceId][$scope] } else { $null } $delegated.Add([ordered]@{ permission = $scope api = $resourceName type = "Delegated" description = $desc internal = $isInternal }) } } # ── Application permissions (appRoleAssignments) ────────────────────────── $assignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $spId -All $appPerms = [System.Collections.Generic.List[object]]::new() foreach ($assignment in $assignments) { $resourceName = $assignment.ResourceDisplayName $resourceId = $assignment.ResourceId $roleId = $assignment.AppRoleId # Resolve the role ID to a permission name and description $permName = $roleId $desc = $null if ($AppRoleLookup.ContainsKey($resourceId)) { $lookup = $AppRoleLookup[$resourceId] if ($lookup.ContainsKey($roleId)) { $permName = $lookup[$roleId].name $desc = $lookup[$roleId].description } } # Use friendly resource name if available $friendlyResource = if ($ResourceNameById.ContainsKey($resourceId)) { $ResourceNameById[$resourceId] } else { $resourceName } $appPerms.Add([ordered]@{ permission = $permName api = $friendlyResource type = "Application" description = $desc }) } # Sort for stable output $sortedDelegated = $delegated | Sort-Object { $_.api }, { $_.permission } $sortedAppPerms = $appPerms | Sort-Object { $_.api }, { $_.permission } $results.Add([ordered]@{ applicationName = $sp.DisplayName appId = $sp.AppId status = "OK" delegatedPermissions = @($sortedDelegated) applicationPermissions = @($sortedAppPerms) }) Write-Host " Delegated: $($delegated.Count) | Application: $($appPerms.Count)" } # ── Build output document ──────────────────────────────────────────────────── $output = [ordered]@{ metadata = [ordered]@{ generatedAt = (Get-Date -Format "o") tenantId = $context.TenantId environment = $Cloud generatedBy = $generatedBy toolVersion = "2.1.0" description = "ContraForce enterprise application permissions snapshot for documentation auditing." } applications = @($results) } $fullPath = [System.IO.Path]::GetFullPath($OutputPath) $json = $output | ConvertTo-Json -Depth 10 # Normalize to LF line endings $json = $json -replace "`r`n", "`n" [System.IO.File]::WriteAllText( $fullPath, "$json`n", [System.Text.UTF8Encoding]::new($false) ) # ── Restrict file permissions for government environments ───────────────────── # In GCC High and DoD environments, restrict the output file so only the current # user can read/write it. This prevents other accounts on shared jump boxes from # accessing tenant permission data. if ($Cloud -ne "AzureCloud") { try { $acl = Get-Acl -Path $fullPath $acl.SetAccessRuleProtection($true, $false) # disable inheritance, remove inherited rules $currentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name $rule = [System.Security.AccessControl.FileSystemAccessRule]::new( $currentUser, [System.Security.AccessControl.FileSystemRights]::FullControl, [System.Security.AccessControl.AccessControlType]::Allow ) $acl.SetAccessRule($rule) Set-Acl -Path $fullPath -AclObject $acl Write-Host " File permissions restricted to current user." -ForegroundColor Yellow } catch { Write-Warning "Could not restrict file permissions on '$fullPath': $_" } } Write-Host "`nAudit complete. Output written to: $OutputPath" -ForegroundColor Green Write-Host "Environment: $envDisplayName" Write-Host "Applications audited: $($results.Count)" Write-Host "Tenant: $($context.TenantId)" # ── Exit with non-zero code if any apps were not found ──────────────────────── $failures = @($results | Where-Object { $_.status -eq "NOT_FOUND" }) if ($failures.Count -gt 0) { Write-Warning "$($failures.Count) application(s) were not found in the tenant." exit 1 } ``` ```python audit_enterprise_apps.py icon="python" expandable theme={null} #!/usr/bin/env python3 """Audit ContraForce enterprise application permissions in Microsoft Entra ID. Queries Microsoft Graph for all documented ContraForce enterprise applications, resolves their delegated and application permissions to human-readable names, and outputs a structured JSON file suitable for diffing against documentation. Requires: - Python 3.10+ (older versions will produce a clear version error). See https://devguide.python.org/versions/ for supported Python versions. - ``azure-identity>=1.19`` and ``httpx>=0.28``:: pip install azure-identity httpx - Azure CLI (``az login``) session — used by ``AzureCliCredential`` for token acquisition - The target tenant must have the ContraForce enterprise applications consented Usage: python audit_enterprise_apps.py python audit_enterprise_apps.py -o audit-2026-02-12.json python audit_enterprise_apps.py -c AzureUSGovernment python audit_enterprise_apps.py -c AzureUSGovernment -o gov-audit.json """ import argparse import dataclasses import importlib.util import json import os import stat import sys import time from datetime import datetime, timezone from typing import Any # ── Requires: Python 3.10+, azure-identity>=1.19, httpx>=0.28 ──────────────── # Mirrors PowerShell's #Requires — validate before any third-party import. if sys.version_info < (3, 10): # noqa: UP036 print( f"Python 3.10+ is required (running {sys.version.split()[0]})", file=sys.stderr, ) raise SystemExit(1) _REQUIRED_PACKAGES = [ ("httpx", "httpx>=0.28"), ("azure.identity", "azure-identity>=1.19"), ] _missing = [spec for mod, spec in _REQUIRED_PACKAGES if importlib.util.find_spec(mod) is None] if _missing: print( f"Missing required packages: {', '.join(_missing)}\n" "Install via: pip install azure-identity httpx", file=sys.stderr, ) raise SystemExit(1) del _REQUIRED_PACKAGES, _missing import httpx # noqa: E402 from azure.core.exceptions import ClientAuthenticationError # noqa: E402 from azure.identity import AzureCliCredential, CredentialUnavailableError # noqa: E402 TOOL_VERSION = "2.1.0" # ── Cloud environment endpoints ─────────────────────────────────────────────── # Microsoft Graph endpoints differ by cloud environment. Commercial (including # GCC) uses graph.microsoft.com; GCC High and DoD use graph.microsoft.us. # See: https://learn.microsoft.com/en-us/graph/deployments CLOUD_ENVIRONMENTS: dict[str, dict[str, str]] = { "AzureCloud": { "graph_base": "https://graph.microsoft.com/v1.0", "graph_scope": "https://graph.microsoft.com/.default", "name": "Commercial", }, "AzureUSGovernment": { "graph_base": "https://graph.microsoft.us/v1.0", "graph_scope": "https://graph.microsoft.us/.default", "name": "US Government (GCC High / DoD)", }, } # ContraForce enterprise applications to audit (Commercial / AzureCloud only). # App IDs differ by cloud environment. Government cloud app IDs are provided # by ContraForce upon request and passed via --apps-file. COMMERCIAL_APPS = [ {"name": "ContraForce API", "app_id": "24d97bc0-8f2b-45d5-8e0b-7fe286732ef2"}, {"name": "ContraForce Portal", "app_id": "8b7cb435-9526-47ee-b79a-34433f0daad2"}, {"name": "ContraForce for MDE", "app_id": "6efccc6a-f0d3-49e5-92d0-17d4afa9ba52"}, {"name": "ContraForce Gamebooks for MDE", "app_id": "ad7b0e79-3c37-4408-bf8f-eb89522cc920"}, { "name": "ContraForce Gamebooks for Identity", "app_id": "36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a", }, { "name": "ContraForce Gamebooks for Email", "app_id": "44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d", }, { "name": "ContraForce Sentinel Hunting", "app_id": "6bf1c74d-7ade-4671-a507-166936f89a1f", }, ] # Well-known first-party resource APIs that ContraForce integrates with. RESOURCE_APIS = [ "Microsoft Graph", "Windows Azure Service Management API", "WindowsDefenderATP", "Microsoft Threat Protection", "Log Analytics API", ] # Friendly display names for resource APIs. FRIENDLY_NAMES: dict[str, str] = { "Windows Azure Service Management API": "Azure Service Management", } @dataclasses.dataclass class PermissionRegistry: """Lookup tables for resolving permission IDs to human-readable names.""" app_roles: dict[str, dict[str, dict[str, str | None]]] = dataclasses.field( default_factory=dict, ) delegated_scopes: dict[str, dict[str, dict[str, str | None]]] = dataclasses.field( default_factory=dict, ) resource_names: dict[str, str] = dataclasses.field(default_factory=dict) _scope_desc_by_name: dict[str, dict[str, str | None]] = dataclasses.field( default_factory=dict, repr=False, ) def index_service_principal(self, sp: dict, *, friendly_name: str | None = None) -> None: """Index a service principal's roles and scopes for later resolution.""" sp_id = sp["id"] self.resource_names[sp_id] = friendly_name or sp["displayName"] self.app_roles[sp_id] = { role["id"]: {"name": role["value"], "description": role.get("description")} for role in sp.get("appRoles") or [] } scopes_by_id: dict[str, dict[str, str | None]] = {} desc_by_name: dict[str, str | None] = {} for scope in sp.get("oauth2PermissionScopes") or []: desc = scope.get("adminConsentDescription") scopes_by_id[scope["id"]] = {"name": scope["value"], "description": desc} desc_by_name[scope["value"]] = desc self.delegated_scopes[sp_id] = scopes_by_id self._scope_desc_by_name[sp_id] = desc_by_name def resolve_scope_description(self, resource_id: str, scope_name: str) -> str | None: """Look up a delegated scope description by name.""" return self._scope_desc_by_name.get(resource_id, {}).get(scope_name) class AuditAuthError(Exception): """Raised when Azure CLI authentication fails.""" class GraphClient: """Lightweight Microsoft Graph client backed by httpx and AzureCliCredential.""" def __init__(self, *, cloud: str = "AzureCloud") -> None: env = CLOUD_ENVIRONMENTS[cloud] self._graph_base = env["graph_base"] self._graph_scope = env["graph_scope"] try: self._credential = AzureCliCredential() self._token = self._credential.get_token(self._graph_scope) except (CredentialUnavailableError, ClientAuthenticationError) as e: raise AuditAuthError( "Azure CLI is not authenticated. Run 'az login' first.\n" "For government cloud: az cloud set --name AzureUSGovernment && az login" ) from e self._http = httpx.Client( timeout=httpx.Timeout(30.0, connect=10.0), ) self._refresh_auth() # Resolve identity from Microsoft Graph API rather than decoding the # access token JWT on the client side. Access tokens are intended for # the resource server, not the client — decoding them without signature # verification is architecturally incorrect and raises red flags in # security reviews. Using /me and /organization is both correct and # eliminates the need for a JWT verification library. self._resolve_identity() def _resolve_identity(self) -> None: """Resolve authenticated user and tenant identity from Microsoft Graph.""" me_resp = self._request_with_retry( f"{self._graph_base}/me", params={"$select": "id,userPrincipalName"}, ) if me_resp is not None: me = me_resp.json() self.user_upn: str = me.get("userPrincipalName", "") self.user_oid: str = me.get("id", "") else: self.user_upn = "" self.user_oid = "" print( " WARNING: Could not resolve user identity from /me.", file=sys.stderr, ) org_resp = self._request_with_retry( f"{self._graph_base}/organization", params={"$select": "id"}, ) if org_resp is not None: orgs = org_resp.json().get("value", []) self.tenant_id: str = orgs[0]["id"] if orgs else "" else: self.tenant_id = "" print( " WARNING: Could not resolve tenant from /organization.", file=sys.stderr, ) # NOTE: Remove quotes when minimum version is Python 3.14+ (PEP 649). def __enter__(self) -> "GraphClient": # quoted: class name isn't bound yet return self def __exit__(self, *exc: object) -> None: self._http.close() def _refresh_auth(self) -> None: """Refresh the bearer token if it is within 5 minutes of expiry.""" if self._token.expires_on - time.time() < 300: self._token = self._credential.get_token(self._graph_scope) self._http.headers["Authorization"] = f"Bearer {self._token.token}" def _request_with_retry( self, url: str, params: dict[str, str] | None = None, *, max_retries: int = 3, ) -> httpx.Response | None: """GET with retry and 429/Retry-After handling.""" for attempt in range(max_retries + 1): self._refresh_auth() try: resp = self._http.get(url, params=params) if resp.status_code == 429: try: retry_after = int(resp.headers.get("Retry-After", 2**attempt)) except ValueError: retry_after = 2**attempt print(f" Throttled, retrying in {retry_after}s...", file=sys.stderr) time.sleep(retry_after) continue resp.raise_for_status() return resp except httpx.HTTPError as e: if attempt < max_retries: time.sleep(2**attempt) continue print( f" WARNING: Graph call failed after {max_retries + 1} attempts: {url}\n" f" {e}", file=sys.stderr, ) return None return None def paginated_get(self, url: str, params: dict[str, str] | None = None) -> list[dict]: """GET with automatic @odata.nextLink pagination.""" all_values: list[dict] = [] current_url: str | None = url current_params = params while current_url: resp = self._request_with_retry(current_url, current_params) if resp is None: print( f" WARNING: Pagination interrupted — returning {len(all_values)} " f"partial result(s) for {url}", file=sys.stderr, ) break data = resp.json() all_values.extend(data.get("value", [])) current_url = data.get("@odata.nextLink") current_params = None # nextLink includes query params return all_values def list_service_principals( self, *, odata_filter: str, select: list[str], ) -> list[dict]: """Query /servicePrincipals with an OData filter.""" return self.paginated_get( f"{self._graph_base}/servicePrincipals", params={"$filter": odata_filter, "$select": ",".join(select)}, ) def get_oauth2_permission_grants(self, sp_id: str) -> list[dict]: """Get delegated permission grants for a service principal.""" return self.paginated_get( f"{self._graph_base}/servicePrincipals/{sp_id}/oauth2PermissionGrants", ) def get_app_role_assignments(self, sp_id: str) -> list[dict]: """Get application permission assignments for a service principal.""" return self.paginated_get( f"{self._graph_base}/servicePrincipals/{sp_id}/appRoleAssignments", ) def resolve_resource_apis(graph: GraphClient, registry: PermissionRegistry) -> None: """Resolve resource API service principals and populate the registry.""" print("\033[36mResolving resource API service principals...\033[0m") select = ["id", "displayName", "appRoles", "oauth2PermissionScopes"] for api_name in RESOURCE_APIS: results = graph.list_service_principals( odata_filter=f"displayName eq '{api_name}'", select=select, ) if not results: print(f" WARNING: Resource API not found in tenant: {api_name}", file=sys.stderr) continue sp = results[0] sp_id = sp["id"] friendly_name = FRIENDLY_NAMES.get(sp["displayName"], sp["displayName"]) registry.index_service_principal(sp, friendly_name=friendly_name) print( f" Resolved: {friendly_name} ({sp_id})" f" — {len(registry.app_roles[sp_id])} app roles," f" {len(registry.delegated_scopes[sp_id])} delegated scopes" ) def index_contraforce_apps(graph: GraphClient, registry: PermissionRegistry) -> None: """Index ContraForce apps for internal cross-app scope resolution. Some ContraForce applications delegate to each other via custom OAuth2 scopes (e.g., the Portal delegates to the API). This queries for ALL service principals whose displayName starts with ``ContraForce`` — not just the seven audited apps — so that cross-app scopes resolve to human-readable names instead of raw GUIDs in the output. This broader query does NOT grant any additional access; it only reads public service principal metadata visible to any authenticated directory reader. Permissions returned from this query are tagged with ``"internal": true`` in the output to distinguish them from permissions that grant access to tenant data. """ cf_sps = graph.list_service_principals( odata_filter="startswith(displayName, 'ContraForce')", select=["id", "displayName", "oauth2PermissionScopes"], ) for cf_sp in cf_sps: if cf_sp["id"] not in registry.resource_names: registry.index_service_principal(cf_sp) def audit_delegated_permissions( graph: GraphClient, sp_id: str, registry: PermissionRegistry, ) -> list[dict[str, Any]]: """Query and resolve delegated permissions (oauth2PermissionGrants).""" grants = graph.get_oauth2_permission_grants(sp_id) delegated: list[dict[str, Any]] = [] for grant in grants: resource_id = grant["resourceId"] resource_name = registry.resource_names.get(resource_id, resource_id) is_internal = resource_name.startswith("ContraForce ") scope_names = sorted(s for s in grant.get("scope", "").split() if s) for scope in scope_names: delegated.append({ "permission": scope, "api": resource_name, "type": "Delegated", "description": registry.resolve_scope_description(resource_id, scope), "internal": is_internal, }) return sorted(delegated, key=lambda p: (p["api"], p["permission"])) def audit_application_permissions( graph: GraphClient, sp_id: str, registry: PermissionRegistry, ) -> list[dict[str, Any]]: """Query and resolve application permissions (appRoleAssignments).""" assignments = graph.get_app_role_assignments(sp_id) app_perms: list[dict[str, Any]] = [] for assignment in assignments: resource_name = assignment.get("resourceDisplayName", "") resource_id = assignment["resourceId"] role_id = assignment["appRoleId"] # Resolve the role ID to a permission name and description role = registry.app_roles.get(resource_id, {}).get(role_id) perm_name = role["name"] if role else role_id desc = role["description"] if role else None app_perms.append({ "permission": perm_name, "api": registry.resource_names.get(resource_id, resource_name), "type": "Application", "description": desc, }) return sorted(app_perms, key=lambda p: (p["api"], p["permission"])) def audit_app( graph: GraphClient, app: dict[str, str], registry: PermissionRegistry, ) -> dict[str, Any]: """Audit a single enterprise application.""" print(f"\n\033[36mAuditing: {app['name']} ({app['app_id']})...\033[0m") results = graph.list_service_principals( odata_filter=f"appId eq '{app['app_id']}'", select=["id", "displayName", "appId"], ) if not results: print(" WARNING: NOT FOUND in tenant — skipping", file=sys.stderr) return { "applicationName": app["name"], "appId": app["app_id"], "status": "NOT_FOUND", "delegatedPermissions": [], "applicationPermissions": [], } sp = results[0] sp_id = sp["id"] delegated = audit_delegated_permissions(graph, sp_id, registry) app_perms = audit_application_permissions(graph, sp_id, registry) print(f" Delegated: {len(delegated)} | Application: {len(app_perms)}") return { "applicationName": sp["displayName"], "appId": sp["appId"], "status": "OK", "delegatedPermissions": delegated, "applicationPermissions": app_perms, } def parse_args() -> argparse.Namespace: """Parse command-line arguments.""" parser = argparse.ArgumentParser( description="Audit ContraForce enterprise application permissions in Microsoft Entra ID.", ) parser.add_argument( "-o", "--output", default="enterprise-apps-audit.json", help="Path for the output JSON file (default: enterprise-apps-audit.json)", ) parser.add_argument( "-c", "--cloud", choices=list(CLOUD_ENVIRONMENTS), default="AzureCloud", help=( "Cloud environment to audit: AzureCloud (default) or" " AzureUSGovernment (GCC High / DoD). Must match the environment" " set with 'az cloud set --name '." ), ) parser.add_argument( "-a", "--apps-file", help=( "Path to a JSON file listing the applications to audit. Each entry" " must have 'name' and 'app_id' fields. Required for government" " cloud environments where app IDs differ from commercial." " Contact support@contraforce.com for your environment's app IDs." ), ) parser.add_argument( "--redact-upn", action="store_true", help=( "Record the operator's Entra object ID instead of UPN in output" " metadata. Automatically enabled for government environments." ), ) return parser.parse_args() def main() -> int: """Run the enterprise application audit and return exit code.""" args = parse_args() cloud = args.cloud # Resolve the application list: built-in for commercial, file-based for gov if args.apps_file: with open(args.apps_file, encoding="utf-8") as f: apps_to_audit = json.load(f) elif cloud == "AzureCloud": apps_to_audit = COMMERCIAL_APPS else: print( "ERROR: Government cloud environments require --apps-file.\n" "App IDs differ by cloud environment. Contact support@contraforce.com\n" "to obtain the app IDs for your environment.", file=sys.stderr, ) return 1 try: graph = GraphClient(cloud=cloud) except AuditAuthError as e: print(f"ERROR: {e}", file=sys.stderr) return 1 with graph: # Auto-enable UPN redaction for government cloud environments redact_upn = args.redact_upn or cloud != "AzureCloud" generated_by = graph.user_oid if redact_upn else graph.user_upn tenant_id = graph.tenant_id env_name = CLOUD_ENVIRONMENTS[cloud]["name"] print( f"\033[32mAuthenticated as: {generated_by}" f" (Tenant: {tenant_id}, Environment: {env_name})\033[0m" ) registry = PermissionRegistry() resolve_resource_apis(graph, registry) index_contraforce_apps(graph, registry) results = [audit_app(graph, app, registry) for app in apps_to_audit] # Build output document output = { "metadata": { "generatedAt": datetime.now(timezone.utc).isoformat(), # noqa: UP017 "tenantId": tenant_id, "generatedBy": generated_by, "toolVersion": TOOL_VERSION, "environment": cloud, "description": ( "ContraForce enterprise application permissions snapshot" " for documentation auditing." ), }, "applications": results, } output_json = json.dumps(output, indent=2, ensure_ascii=False) + "\n" with open(args.output, "w", encoding="utf-8", newline="\n") as f: f.write(output_json) # Restrict file permissions for government cloud environments if cloud != "AzureCloud": try: os.chmod(args.output, stat.S_IRUSR | stat.S_IWUSR) except OSError: print( f" WARNING: Could not restrict file permissions on {args.output}.\n" ' On Windows, run: icacls /inheritance:r /grant:r "%USERNAME%":F', file=sys.stderr, ) print(f"\n\033[32mAudit complete. Output written to: {args.output}\033[0m") print(f"Applications audited: {len(results)}") print(f"Tenant: {tenant_id}") print(f"Environment: {env_name}") if redact_upn: print("Operator identity: redacted (object ID used)") # Exit with non-zero code if any apps were not found failures = [r for r in results if r["status"] == "NOT_FOUND"] if failures: print( f"\nWARNING: {len(failures)} application(s) were not found in the tenant.", file=sys.stderr, ) return 1 return 0 if __name__ == "__main__": sys.exit(main()) ``` ## Understanding the Output Both scripts produce a JSON file with the same structure. Here's an abbreviated example: ```json Output Schema theme={null} { "metadata": { "generatedAt": "2026-02-12T18:30:00.000000+00:00", "tenantId": "your-tenant-id", "generatedBy": "admin@company.example", "toolVersion": "2.1.0", "environment": "AzureCloud", "description": "ContraForce enterprise application permissions snapshot for documentation auditing." }, "applications": [ { "applicationName": "ContraForce API", "appId": "24d97bc0-8f2b-45d5-8e0b-7fe286732ef2", "status": "OK", "delegatedPermissions": [ { "permission": "Application.Read.All", "api": "Microsoft Graph", "type": "Delegated", "description": "Allows the app to read applications and service principals on behalf of the signed-in user.", "internal": false } ], "applicationPermissions": [] } ] } ``` ### Key Fields | Field | Description | | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `status` | `OK` if the application was found and audited. `NOT_FOUND` if the application is not consented in the tenant. | | `type` | `Delegated` (on-behalf-of user) or `Application` (app-only, no user context). See [Permission Types Explained](/guides/technical/enterprise-applications#permission-types-explained). | | `internal` | `true` for permissions between ContraForce applications (e.g., Portal delegating to API). These are internal platform scopes and do not grant access to your tenant data. Only present on delegated permissions. | | `environment` | The cloud environment the audit was run against (`AzureCloud` or `AzureUSGovernment`). Matches the `az cloud set --name` value. | | `generatedBy` | The authenticated operator. In government environments, this is an Entra object ID (GUID) rather than a UPN. | | `toolVersion` | Include this when sharing audit results with ContraForce support for traceability. | ### Internal Scope Resolution You may notice the output includes delegated permissions where the `api` field shows a ContraForce application name (e.g., `"ContraForce Portal"`) and `"internal": true`. These are cross-application delegations where one ContraForce app delegates to another via custom OAuth2 scopes. To resolve these internal scopes to human-readable names instead of raw GUIDs, the scripts query for all service principals whose display name starts with `ContraForce` — not just the seven applications listed in the audit table. This broader query: * **Does not grant additional access** — it reads public service principal metadata that any authenticated directory reader can see * **Is clearly tagged** — all permissions from internal apps are marked `"internal": true` in the output * **Improves readability** — without this, internal scopes would appear as opaque GUIDs that are difficult to review ### Comparing Against Documentation To verify your tenant's permissions match the documented permissions: 1. Run the audit script to produce `enterprise-apps-audit.json` 2. Open the [Enterprise Applications Reference](/guides/technical/enterprise-applications) 3. For each application in the JSON output, compare its `delegatedPermissions` and `applicationPermissions` against the corresponding tables in the reference 4. Permissions marked `"internal": true` are ContraForce-to-ContraForce delegations and are not listed in the reference tables ### Comparing Across Audit Runs To track permission changes over time, save each audit output with a date-stamped filename: ```bash theme={null} # Date-stamped output python audit_enterprise_apps.py -o audit-2026-02-12.json # Later, compare against a previous audit diff audit-2026-01-15.json audit-2026-02-12.json ``` Because the scripts sort all permissions alphabetically and produce deterministic JSON output, standard text diff tools (`diff`, VS Code's built-in compare, or `Compare-Object` in PowerShell) will surface only actual permission changes — not ordering noise. Store audit outputs alongside your change management records. The `metadata.generatedAt` and `metadata.toolVersion` fields provide traceability for each snapshot. ## Output File Access Control The audit output reveals your tenant's permission surface for ContraForce applications. While it does not contain secrets or tokens, it should be treated as internal documentation. **Government cloud environments:** Both scripts automatically restrict the output file so only the current user can read or write it: * **PowerShell (Windows):** Removes inherited ACL entries and grants `FullControl` only to the current user via `Set-Acl` * **Python (POSIX):** Sets file mode to `600` (`chmod u=rw,go=`) via `os.chmod` **Commercial environments:** File permissions are not restricted automatically. If you are running the audit on a shared workstation or jump box, consider restricting access manually: ```powershell theme={null} icacls enterprise-apps-audit.json /inheritance:r /grant:r "%USERNAME%":F ``` ```bash theme={null} chmod 600 enterprise-apps-audit.json ``` ## Using This Output as Audit Evidence The audit output is designed to serve as evidence in change advisory board (CAB) reviews, compliance audits, and periodic access reviews. **For CAB / Change Management:** * Run the audit before and after onboarding a new ContraForce module * Include both snapshots in your change record to show exactly which permissions were added * The `toolVersion` field ensures reviewers know which version of the script produced the output **For Periodic Access Reviews (CMMC, SOC 2, FedRAMP):** * Schedule monthly or quarterly audit runs and archive the output alongside your review documentation * Use date-stamped filenames (e.g., `audit-2026-Q1.json`) for easy retrieval * Compare successive outputs using `diff` to identify any permission drift **For Incident Response:** * If you suspect unauthorized permission changes, run an immediate audit and compare against your most recent baseline * The `generatedAt` timestamp provides a verifiable point-in-time snapshot Store audit outputs in a version-controlled repository or a tamper-evident storage location (such as an Azure Storage account with immutable blob policies) to maintain an auditable chain of custody. ## Troubleshooting | Issue | Cause | Resolution | | --------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `NOT_FOUND` for some applications | Application not consented in tenant | Expected if you haven't deployed all modules. See [Applications by Module](/guides/technical/enterprise-applications#applications-by-module). | | PowerShell: "No active Microsoft Graph session" | `Connect-MgGraph` not run | Run `Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"` first. For government cloud, add `-Environment USGov` (GCC High) or `-Environment USGovDoD` (DoD). | | PowerShell: "Environment mismatch" | `-Cloud` value does not match the `Connect-MgGraph -Environment` session | Disconnect with `Disconnect-MgGraph` and reconnect with the correct `-Environment` flag matching your `-Cloud` value. | | "Government cloud environments require -AppsFile / --apps-file" | No apps file provided for government cloud | App IDs differ by cloud environment. Contact [support@contraforce.com](mailto:support@contraforce.com) for your environment's app IDs and provide them via `-AppsFile` (PowerShell) or `--apps-file` (Python). | | Python: "Azure CLI is not authenticated" | `az login` not run or session expired | Run `az login` to authenticate. For government cloud, run `az cloud set --name AzureUSGovernment` first. | | Python: "Missing required packages" | `azure-identity` or `httpx` not installed | Run `pip install azure-identity httpx` | | Python: "Python 3.10+ is required" | Running on an older Python version | Install [Python 3.10 or newer](https://devguide.python.org/versions/) | | Script takes a long time | Microsoft Graph API throttling | Normal in large tenants. The scripts handle `429 Retry-After` responses automatically. | | Permissions don't match documentation | Permissions changed since last documentation update | Contact [support@contraforce.com](mailto:support@contraforce.com) with the audit JSON and `toolVersion` | *** ## Related Resources Complete reference for all ContraForce enterprise applications and their permissions All Azure resources provisioned during ContraForce onboarding ContraForce platform roles and what each can do Step-by-step guide to onboarding your parent workspace Questions about the audit scripts or enterprise application permissions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Azure Resources Deployed Source: https://docs.contraforce.com/guides/technical/azure-resources-deployed Complete reference of all Azure resources, enterprise applications, and role assignments provisioned during ContraForce onboarding. This article documents all Azure resources that ContraForce provisions during the onboarding process. Use this reference to understand what's deployed in your environment, verify deployments, and plan for offboarding if needed. The resources deployed depend on your module selection (XDR vs XDR + SIEM) and whether you enable AI Agents. Not all resources apply to every deployment. ## Deployment Overview ContraForce deploys resources across several Azure components: Service principals in Microsoft Entra ID for API access and authentication Cross-tenant delegation for MSSP management scenarios Real-time incident notification system for Sentinel AI agent hosting environment (optional) ### Resources by Module | Resource Category | Defender Module | XDR + SIEM Module | With AI Agents | | -------------------------------- | :-------------: | :---------------: | :------------: | | Core Enterprise Applications | ✓ | ✓ | ✓ | | Defender Enterprise Applications | ✓ | ✓ | ✓ | | Azure Lighthouse | — | ✓ | ✓ | | Apollo Resource Group | — | ✓ | ✓ | | Sentinel Resource Deployments | — | ✓ | ✓ | | Agent Center Resource Group | — | — | ✓ | | Per-Agent Resource Groups | — | — | ✓ | *** ## Phase 1: Initial Onboarding The first phase provisions core enterprise applications required for all ContraForce deployments. ### Enterprise Applications These applications are provisioned and consented during initial setup: | Application | Application ID | Purpose | | ---------------------- | -------------------------------------- | ------------------------------------- | | **ContraForce API** | `24d97bc0-8f2b-45d5-8e0b-7fe286732ef2` | Core platform API access | | **ContraForce Portal** | `8b7cb435-9526-47ee-b79a-34433f0daad2` | User authentication and portal access | These two applications are required for all ContraForce deployments, regardless of module selection. They are consented when you first sign in at [portal.contraforce.com](https://portal.contraforce.com), as separate **ContraForce API** and **ContraForce Portal** Microsoft consent prompts granted by a **Global Administrator**. ### Permissions Granted | Application | Permission Type | Permissions | | ---------------------- | --------------- | -------------------------------------- | | **ContraForce API** | Application | SecurityEvents.Read.All, User.Read.All | | **ContraForce Portal** | Delegated | User.Read, openid, profile | **Consent model.** ContraForce enterprise applications are consented with **application (app-only)** Microsoft Graph permissions. Admin consent for Microsoft Graph application permissions must be granted by a **Global Administrator** — Cloud Application Administrator and Application Administrator cannot grant it. Global Administrator is required for the one-time consent only and is not retained; activate it just-in-time with Privileged Identity Management (PIM) and deactivate afterward. Because actions run as the application (no signed-in user required), operator control is enforced through **Gamebook approval gates** — only Workspace Owners can approve high-impact actions — and a complete **audit trail** in the Gamebooks History page. *** ## Phase 2: Module-Specific Applications Additional enterprise applications are consented based on your module selection and enabled features. ### Microsoft Defender for Endpoint Applications | Application | Application ID | Purpose | | --------------------------------- | -------------------------------------- | --------------------------------- | | **ContraForce for MDE** | `6efccc6a-f0d3-49e5-92d0-17d4afa9ba52` | Defender for Endpoint data access | | **ContraForce Gamebooks for MDE** | `ad7b0e79-3c37-4408-bf8f-eb89522cc920` | Endpoint response actions | ### Identity Applications | Application | Application ID | Purpose | | -------------------------------------- | -------------------------------------- | ----------------------------------------------- | | **ContraForce Gamebooks for Identity** | `36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a` | User response actions (disable, reset password) | ### Microsoft Sentinel Applications | Application | Application ID | Purpose | | -------------------------------- | -------------------------------------- | ---------------------------------------- | | **ContraForce Sentinel Hunting** | `6bf1c74d-7ade-4671-a507-166936f89a1f` | Log Analytics queries for threat hunting | ### Email Applications | Application | Application ID | Purpose | | ----------------------------------- | -------------------------------------- | ------------------------------------ | | **ContraForce Gamebooks for Email** | `44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d` | Email response actions (soft delete) | *** ## Phase 3: Microsoft Sentinel Core Components For XDR + SIEM deployments, additional Azure resources establish the connection between your Sentinel environment and ContraForce. This phase only applies to **XDR + SIEM module** deployments. XDR-only deployments skip this phase. ### Azure Lighthouse Delegation Azure Lighthouse enables cross-tenant management without credential sharing. | Resource | Type | Description | | ----------------------------------- | ------------ | ----------------------------------------------------- | | **ContraForceLighthouseDeployment** | ARM Template | Assigns Sentinel resource group to ContraForce tenant | #### What Lighthouse Enables * Cross-tenant visibility into your Sentinel workspace * Incident management without logging into your tenant * Centralized management for MSSPs Azure Lighthouse delegates **Azure resource access only** (Sentinel Contributor + Reader on the Sentinel resource group). It does **not** delegate identity, mailbox, or endpoint response. Those capabilities are provided by the consented ContraForce enterprise applications in each tenant — through per-tenant application consent, or GDAP for CSP relationships. Azure Lighthouse is distinct from Microsoft 365 Lighthouse and from GDAP. Azure Lighthouse is the Microsoft-recommended approach for MSSP scenarios. It provides secure delegated access without sharing credentials or creating guest accounts. ### Role Assignments | Principal | Role | Scope | | ------------------- | -------------------- | ----------------------- | | **ContraForce API** | Sentinel Contributor | Sentinel Resource Group | | **ContraForce API** | Reader | Sentinel Resource Group | ### Resource Provider Registrations The following resource providers are registered in your subscription: | Resource Provider | Purpose | | --------------------- | --------------------------------------- | | **Microsoft.Network** | Network resources for Apollo deployment | | **Microsoft.Storage** | Storage accounts for Apollo deployment | *** ## Phase 4: Apollo Resource Group Apollo enables real-time Sentinel incident notifications. A dedicated resource group is created with supporting infrastructure. ### Resource Group Details | Property | Value | | ------------ | ---------------------------------------------- | | **Name** | `rg-contraforce-apollo` | | **Purpose** | Real-time incident notification infrastructure | | **Location** | Same region as your Sentinel workspace | ### Resources Deployed | Resource | Type | Purpose | | -------------------- | ------------------------- | ------------------------- | | **Function App** | Microsoft.Web/sites | Processes incident events | | **App Service Plan** | Microsoft.Web/serverfarms | Hosts the Function App | | Resource | Type | Purpose | | --------------------------- | ---------------------------------------- | ------------------------------ | | **Log Analytics Workspace** | Microsoft.OperationalInsights/workspaces | Apollo diagnostics and logging | | **Application Insights** | Microsoft.Insights/components | Function App monitoring | | Resource | Type | Purpose | | ------------------- | --------------------------------- | -------------------- | | **Storage Account** | Microsoft.Storage/storageAccounts | Function App storage | | Resource | Type | Purpose | | -------------------------- | --------------------------------------- | ---------------------------------- | | **Apollo Role Definition** | Microsoft.Authorization/roleDefinitions | Custom role for Apollo access | | **Role Assignment** | Microsoft.Authorization/roleAssignments | Apollo RG to Lighthouse delegation | ### Apollo Architecture ```mermaid theme={null} flowchart LR A[Sentinel Incident] --> B[Automation Rule] B --> C[Logic App] C --> D[Function App] D --> E[ContraForce Platform] ``` *** ## Phase 5: Sentinel Resource Group Deployments Resources are also deployed directly into your existing Sentinel resource group to enable incident streaming. ### Resources in Sentinel Resource Group | Resource | Type | Name | | ------------------- | ------------------------------------------ | ---------------------------------------------- | | **API Connection** | Microsoft.Web/connections | `microsoftsentinel-Publish-Incident-To-Apollo` | | **Logic App** | Microsoft.Logic/workflows | `Publish-Incident-To-Apollo` | | **Automation Rule** | Microsoft.SecurityInsights/automationRules | `Run-Playbook-Publish-Incident-To-Apollo` | ### How Incident Streaming Works A new incident is created in Microsoft Sentinel The `Run-Playbook-Publish-Incident-To-Apollo` automation rule detects the new incident The `Publish-Incident-To-Apollo` Logic App is triggered The Logic App sends incident data to the Apollo Function App The incident appears in the ContraForce Command Page in near real-time *** ## Phase 6: Agent Center Resource Group (Optional) If you deploy ContraForce AI Agents, a dedicated resource group hosts the core agent infrastructure. AI Agents are an optional feature. Most deployments do not include agent infrastructure. Skip this section if you haven't enabled AI Agents. ### Resource Group Details | Property | Value | | ------------ | --------------------------------------------- | | **Name** | `rg-cf-agent-center` | | **Purpose** | Core infrastructure for ContraForce AI agents | | **Location** | Configured during agent deployment | ### Resources Deployed | Resource | Type | Purpose | | -------------- | -------------------------------------------- | ------------------- | | **AI Foundry** | Microsoft.MachineLearningServices/workspaces | AI model management | | **CosmosDB** | Microsoft.DocumentDB/databaseAccounts | Agent data storage | | Resource | Type | Purpose | | ---------------------------------- | ---------------------------------------- | ------------------------- | | **Container Apps Environment** | Microsoft.App/managedEnvironments | Agent runtime environment | | **Container App (Infrastructure)** | Microsoft.App/containerApps | Infrastructure management | | **Log Analytics Workspace** | Microsoft.OperationalInsights/workspaces | Container Apps logging | | Resource | Type | Purpose | | ------------------------------ | ---------------------------------- | ------------------------ | | **Virtual Network (VNET)** | Microsoft.Network/virtualNetworks | Network isolation | | **Azure Subnet** | Subnet | Container Apps subnet | | **Private Endpoint Subnet** | Subnet | Private endpoints | | **Cosmos DNS Zone** | Microsoft.Network/privateDnsZones | CosmosDB DNS resolution | | **Key Vault DNS Zone** | Microsoft.Network/privateDnsZones | Key Vault DNS resolution | | **CosmosDB Private Endpoint** | Microsoft.Network/privateEndpoints | Secure CosmosDB access | | **Key Vault Private Endpoint** | Microsoft.Network/privateEndpoints | Secure Key Vault access | | Resource | Type | Purpose | | -------------------- | ------------------------------------------------ | ---------------------------- | | **Key Vaults** | Microsoft.KeyVault/vaults | Secret management | | **Managed Identity** | Microsoft.ManagedIdentity/userAssignedIdentities | Container App authentication | | Resource | Type | Purpose | | ------------------- | --------------------------------- | --------------------------------- | | **Storage Account** | Microsoft.Storage/storageAccounts | Infrastructure management storage | *** ## Phase 7: Per-Agent Resource Groups (Optional) A dedicated resource group is created for each AI agent deployed per workspace. ### Resource Group Naming | Property | Pattern | | --------------- | ------------------------ | | **Name Format** | `rg-cf-agent-{agent-id}` | | **Example** | `rg-cf-agent-abc123` | ### Resources Per Agent | Resource | Type | Purpose | | --------------------------- | ----------------------------------------------------- | ------------------------- | | **AI Foundry Project** | Microsoft.MachineLearningServices/workspaces/projects | Agent-specific AI project | | **OpenAI Model Deployment** | Microsoft.CognitiveServices/accounts/deployments | LLM for agent reasoning | | **Container App** | Microsoft.App/containerApps | Agent application runtime | Each workspace can have multiple agents, each with its own resource group. Monitor your Azure costs if you deploy many agents across many workspaces. *** ## Complete Resource Summary ### By Deployment Type **Enterprise Applications:** * ContraForce API * ContraForce Portal * ContraForce for MDE * ContraForce Gamebooks for MDE * ContraForce Gamebooks for Identity * ContraForce Gamebooks for Email **Azure Resources:** None **Enterprise Applications:** * All XDR applications * ContraForce Sentinel Hunting **Azure Resources:** * Azure Lighthouse delegation * Role assignments (Sentinel Contributor, Reader) * Apollo Resource Group (`rg-contraforce-apollo`) * Sentinel Logic App and API Connection * Sentinel Automation Rule **Enterprise Applications:** * All XDR + SIEM applications **Azure Resources:** * All XDR + SIEM resources * Agent Center Resource Group (`rg-cf-agent-center`) * Per-Agent Resource Groups (`rg-cf-agent-*`) ### Enterprise Application Quick Reference | Application | App ID | Required For | | ---------------------------------- | -------------------------------------- | ------------------- | | ContraForce API | `24d97bc0-8f2b-45d5-8e0b-7fe286732ef2` | All deployments | | ContraForce Portal | `8b7cb435-9526-47ee-b79a-34433f0daad2` | All deployments | | ContraForce for MDE | `6efccc6a-f0d3-49e5-92d0-17d4afa9ba52` | Endpoint visibility | | ContraForce Gamebooks for MDE | `ad7b0e79-3c37-4408-bf8f-eb89522cc920` | Endpoint response | | ContraForce Gamebooks for Identity | `36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a` | User response | | ContraForce Sentinel Hunting | `6bf1c74d-7ade-4671-a507-166936f89a1f` | Threat hunting | | ContraForce Gamebooks for Email | `44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d` | Email response | *** ## Verifying Deployed Resources ### Check Enterprise Applications Navigate to [entra.microsoft.com](https://entra.microsoft.com) Click **Identity** > **Applications** > **Enterprise applications** Search for "ContraForce" to see all provisioned applications Each application should show "Enabled" status ### Check Azure Resources Navigate to [portal.azure.com](https://portal.azure.com) Search for "contraforce" or "cf-agent" in resource groups Open each resource group and confirm expected resources exist ### Check Role Assignments Find your Sentinel resource group in Azure Portal Click **Access control (IAM)** Click **Role assignments** tab Search for "ContraForce" to verify assignments *** ## Cost Considerations ### Included Resources Most ContraForce resources have minimal Azure cost impact: | Resource Type | Typical Cost | | -------------------------- | ---------------- | | Enterprise Applications | Free | | Azure Lighthouse | Free | | Role Assignments | Free | | Logic App (Consumption) | \~\$0.01-1/month | | Function App (Consumption) | \~\$1-5/month | ### Potentially Significant Costs AI Agent deployments can incur significant Azure costs depending on usage: * **AI Foundry / OpenAI**: Pay-per-token pricing * **Container Apps**: Compute costs based on usage * **CosmosDB**: Storage and throughput costs Monitor your Azure spending if you enable AI Agents. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | --------------------------------- | ------------------------ | -------------------------------------------------- | | **Missing enterprise apps** | Consent incomplete | Re-run consent flow in workspace settings | | **Apollo resource group missing** | Deployment failed | Check deployment history in Azure; contact support | | **Logic App not running** | Disabled or failed | Enable the Logic App in Azure Portal | | **No incidents syncing** | Automation rule disabled | Enable the automation rule in Sentinel | | **Role assignment missing** | Manual removal | Re-run onboarding or manually add assignments | ### Viewing Deployment History Navigate to your Azure subscription Click **Deployments** in the left navigation Search for "ContraForce" or "Apollo" Check deployment status and error messages *** ## Related Guides Complete SIEM module deployment guide Defender module deployment guide Service principal details and permissions *** Questions about deployed resources? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Partner API Overview Source: https://docs.contraforce.com/guides/technical/contraforce-api-documentation ContraForce has a publicly available API that can be used for integrations into various platforms. ## GitHub Documentation Full documentation for the ContraForce API can be found using the link to GitHub below. [GitHub ContraForce API](https://github.com/ContraForce/contraforce-api) ## Overview The ContraForce API can be used for integrations into various platforms, such as ITSMs or other SOAR platforms. The API can be broken down into 5 components, which are listed below. * [Incident Object](https://github.com/ContraForce/contraforce-api/blob/main/Docs/incident-object.md) * [List Incidents Request](https://github.com/ContraForce/contraforce-api/blob/main/Docs/list-incidents.md) * [Get Incident Details Request](https://github.com/ContraForce/contraforce-api/blob/main/Docs/get-incident-details.md) * [List Incident Entities Request](https://github.com/ContraForce/contraforce-api/blob/main/Docs/list-incident-entities.md) * [List Incident Evident Request](https://github.com/ContraForce/contraforce-api/blob/main/Docs/list-incident-evidence.md) If you have any questions about the ContraForce API, contact the Support team at [support@contraforce.com](mailto:support@contraforce.com). # Microsoft Defender for Endpoint Enterprise Application Source: https://docs.contraforce.com/guides/technical/contraforce-defender-for-endpoint-enterprise-application This article provides an overview of the Microsoft Defender for Endpoint enterprise application. **ContraForce for MDE Overview** The Microsoft Defender for Endpoint enterprise application is used to facilitate visibility and management access for Microsoft Defender for Endpoint data, aggregating MDE data in the ContraForce portal. ![MDE permissions 1](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/image-png-Sep-09-2025-03-11-10-2997-PM.png) ![MDE permissions 2](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/image-png-Sep-09-2025-03-11-42-8106-PM.png) If you have any questions, contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Gamebooks for Identity Enterprise Application Source: https://docs.contraforce.com/guides/technical/contraforce-gamebooks-for-identity-enterprise-application This article provides an overview of the ContraForce Gamebooks for Identity enterprise application. **ContraForce Gamebooks for Identity Overview** The ContraForce Gamebooks for Identity enterprise application is used to authorize Gamebook executions that target User entities. Specifically, the service principal requires User.ReadWrite.All and User.AuthenticationMethod.ReadWrite.All scopes. These scopes are consented with application (app-only) permissions, allowing the service principal to run Gamebook actions without a signed-in user present. Password Reset runs in an on-behalf-of flow (delegated, with a signed-in user) by default; when a customer enables the optional service-provider password reset add-on, it runs app-only via a customer-consented `User-PasswordProfile.ReadWrite.All` permission plus an **Authentication Administrator** directory role assigned to this service principal (see the [Enterprise Applications Reference](/guides/technical/enterprise-applications#contraforce-gamebooks-for-identity)). Because application actions execute unattended, operator control is enforced through Gamebook approval gates (only Workspace Owners can approve high-impact actions) and a complete audit trail in the Gamebooks History page. ![Gamebooks for Identity permissions](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/image-png-Sep-09-2025-03-12-46-9239-PM.png) If you have any questions, contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Microsoft 365 Response Enterprise Application Source: https://docs.contraforce.com/guides/technical/contraforce-microsoft-365-response-enterprise-application This article provides an overview of the Microsoft 365 Response enterprise application. ## Microsoft 365 Response Overview The Microsoft 365 Response enterprise application is used to facilitate the delete email Gamebook in ContraForce. The enterprise app does not have the ability to send email. ![M365 Response permissions](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/image-png-Sep-09-2025-03-16-37-5219-PM.png) If you have any questions, contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Notification Modules Source: https://docs.contraforce.com/guides/technical/contraforce-notification-modules This article will provide an overview of the notification capabilities within ContraForce. ## Overview ContraForce provides notifications for Microsoft Sentinel incidents. For further documentation on product capabilities for individual XDR and SIEM integrations, refer to [this](https://docs.contraforce.com/knowledge/contraforce-capabilities-matrix) document. ## FAQs * What is the email address ContraForce will send notifications from? * [noreply@notifications.contraforce.com](mailto:noreply@notifications.contraforce.com) * How do I adjust email notification settings. * Within [Settings > Notifications](https://portal.contraforce.com/settings/notifications) you can adjust preferences according to incident severity and workspace. * What is included in an incident email notification? * Title * Description * MITRE Tactics * Entities * Link to open the incident in ContraForce # ContraForce Release Notes Source: https://docs.contraforce.com/guides/technical/contraforce-release-notes With each product release, we document changes to the ContraForce Portal. Product releases can include bug fixes, new features, and performance related improvements. ## Release Notes: ## September 5th, 2025 This release brings important updates to the *Content Management (CMS).* Users will find a new tab called rules. In the rules tab, users will be able to view all the analytical rules that exist in the specified workspace Microsoft Sentinel. Additionally, users will be able to manage a specific rules state by being able to enable/disable the rule through the ContraForce platform. If you have any questions, please contact us at [support@contraforce.com](mailto:support@contraforce.com). **New Feature(s)** * Sentinel Rules Tab * Users will now be able see all the existing rules a specific Sentinel has deployed. * Enable/Disable Rule * Users can manage rule status by enabling or disabling rules through the ContraForce Portal ## August 18th, 2025 This release brings important updates to the *Gamebook Workbench and Gamebook Approvers.* Users will find an improved layout and user experience when creating gamebooks. Additionally, users will be able to add specific gamebook approvers if the service provider needs to run actions that need approval, or if the service provider doesn't have permissions to run gamebooks directly. **New Feature(s)** * Gamebook Approver Management * Users will now be able to choose add gamebook approvers within the workspace settings. The user will need a workspace owner role to manage. Only workspace owners of the managed account will be available as options. **UI Enhancements** * Gamebook Workbench Layout * The gamebook workbench has a new and improved layout that will enhance the user experience when queuing and executing gamebooks. ## July 18th, 2025 This release brings important updates to workspace management. Specifically when managing detection and response modules. This will make it simpler and more efficient when adding modules to a workspace. Additionally, the Microsoft Defender Module has an option to ignore Defender incidents if the Sentinel module in that workspace has Defender incidents being forwarded to it. This will remove the duplication of incidents in the incident queue for desired workspaces. **New Feature(s)** * Microsoft Defender module incident toggle * This will ignore Microsoft Defender incidents if the workspace has the Sentinel receiving Defender incidents. If customers configure the Microsoft Defender for Endpoint data connector through the Azure Portal to forward incidents and alerts to Sentinel, users would see duplicate incidents in the ContraForce incident queue. **UI Enhancements** * Workspace Management Enhancements * Workspace General Account Information * General account information shown for a given workspace * Ability to update the following properties * Alias name for workspace * Domain for account * Primary contact name * Primary contact email * Service Provider Information * Modules Tab * Clean view of detection and response modules added to the workspace * Module specific pages that describe the purpose of the module * Ticketing Module Relocation * Ticketing module information now is seen in account settings ## May 28, 2025 *This release brings key feature additions and interface enhancements designed to streamline incident investigation and standardize the user experience. A new **Rule** tab for Microsoft Sentinel incidents provides deeper insights by displaying the rule description, query, entity mappings, frequency, and period — with the added ability to run or modify the query directly in log search. UI improvements include the unification of ContraForce's incident **Status** (New, Active, Closed) and **Severity** (High, Medium, Low, Informational) labels for consistency across modules, as well as updates to the **Evidence** tab table for improved readability and navigation.* **New Feature(s)** * Rule tab for Microsoft Sentinel incidents * View rule details like rule description, rule query, entity mapping, rule frequency and period. * Run/modify rule query in log search to see results **UI Enhancements** * ContraForce Status & Severity Unification * Status: New, Active, Closed * Severity: High, Medium, Low, Informational * Updated Evidence Tab Table ## May 9, 2025 *This release introduces focused enhancements aimed at refining user experience and system usability. Updates include an enhanced device timeline for improved incident context, integrated log search functionality directly within the incident detail page, dynamic adjustment of audit and sign-in log tables based on dock height, and a crucial fix addressing schema detection issues within the Monaco editor. If you have any questions, please contact us at [support@contraforce.com](mailto:support@contraforce.com).* **New Feature(s)** * Added Log Search capability within Incident Detail Pages. **UI Enhancements** * Improved Device Timeline * Dynamic adjustment of Audit and Sign-in log table heights. **Bug Fix** * Monaco Editor schema detection when switching workspace ## Apr 25, 2025 *This release introduces powerful enhancements to streamline security operations and improve user efficiency. The **Log Search** experience has been upgraded with a unified page, allowing analysts to seamlessly query both Microsoft Sentinel and Defender data from a single interface. Users can now easily toggle between modules per workspace using a new dropdown selector and export query results directly to CSV for reporting and collaboration purposes.* *Additionally, onboarding **Microsoft Sentinel** has been enhanced with automated scanning of connected data sources. Upon integration, ContraForce will now detect and display supported data sources within the CMS Analytics page, giving users immediate visibility into their logging environment and improving detection content management.* **UI & Performance Enhancements** * Enhanced Log Search Page * Unified log search page * Dropdown shows sentinel and defender module option for each supported workspace * Export results from query to CSV * Scanning Data Sources from Microsoft Sentinel * Onboarding Microsoft Sentinel will now scan connected data sources and display supported data sources in our CMS analytics page ## April 18, 2025 *This release brings a comprehensive set of updates focused on enhancing system stability, performance, and user experience. Key improvements include entity insights data, bug fixes for error handling, UI enhancements for a more intuitive interface, performance optimizations, and strengthened security measures. A significant highlight is the new Jira Service Desk (JSD) integration, providing streamlined ticket management and synchronization capabilities.* **New Features** * Added comprehensive support for Jira Service Desk, including ticket creation, synchronization, linking, comments management, and enhanced response handling. **UI & Performance Enhancements** * Implemented IAM assignment change tracking for improved data consistency. * Added validation logic to the detection module. * Enhanced browser routing and deep-linking capabilities with right-click support. * Set default behavior to fetch new and active incidents. * Improved email property handling, defaulting to UPN if email is null. * Updated AutoTask module to automatically sync configuration upon addition. * Integrated real-time updates for ServiceNow tickets within the UI. * Improved Autotask API response handling to manage null values effectively. * Enabled the create button for gamebooks after execution. * Optimized logic for deleting email search parameters. **Bug Fixes & Resolutions** * Fixed Email Entity Insights KQL query errors. * Resolved issues causing gamebooks to hang. * Corrected RBAC linkage issues affecting gamebook activities like Retry/Approve. * Addressed a bug causing gamebook history not to update for new accounts. * Fixed error occurring when canceling wizards in the Security Modules page. * Prevented Ticketing tab from appearing in incidents when ITSM is not configured. * Corrected errors when creating tickets without user information. * Resolved urgency field and service ticket form layout issues in ServiceNow. * Fixed the inability to bulk-update incidents. * Corrected "Audit Logs" error when selecting "Load More." * Validated and corrected links in Apollo email notifications for gamebook approvals. * Addressed loading issues with CrowdStrike incident details. * Fixed ownership assignment bugs in Defender incidents. * Improved resizing behavior for audit logs, sign-in logs tables, and evidence tabs. ## Feb 27, 2025 *This release brings a comprehensive set of updates focused on enhancing system stability, performance, and user experience. Key improvements include defender for endpoint alert process tree, bug fixes for error handling, UI enhancements for a more intuitive interface, performance optimizations, and strengthened security measures.* **Improvements** * Process tree for Defender for Endpoint alerts shows tree for multiple alerts * Updated the process tree so that clicking a node properly aligns its title, content, and clickable areas. * Added a copy button for the email subject in insights. * Displayed group and role details in user insights. * Removed extra action buttons from the endpoint details modal. * Minimize button icon and enabled auto-maximization for investigation canvas. * Enabled the minimize dock view feature. * Enhanced the device timeline display by adding UTC conversion for local times. **Bugs** * Fixed an error that caused exceptions when an account was not found. * Resolved spacing and fixed-height issues in the device timeline. * Corrected deprecated MudSwitch attribute warnings. * Resolved issues in the Notifications tab. * Fixed data mismatches in Defender incidents. * Corrected tree view labels on the Advanced Hunting page. * Resolved incident closing status errors. **Security & Validation** * Upgraded vulnerable and deprecated packages—including a migration to MudBlazor v8.0. * Added assignment validation when editing Workspace Groups and during group assignment. * Implemented enhanced exception handling for Defender for Endpoint incident errors. ## Jan 31, 2025 *This release contains some reported bugs from our users and a few improvements.* **Improvements** * Unified Incidents Page * The incidents table found in the command page now has the filter for source. * The ContraForce platform now has unified incidents page **Bugs** * Workspace Owner Assignment - Preonboarding * The user that preonboards a customer workspace will be added to the workspace as Owner * Workspace Module Validation Post Onboarding * Validation checks are now executed when the onboarding finished * CMS UI Rule Deployment Bug * A spinning wheel wouldn't go away after a successful rule deployment. * Investigation Canvas UI error * Errors occur when opening investigation canvas * Related Incidents query for Defender for Endpoint incidents * Updated query to fetch related incidents for a specific entity in a Defender for Endpoint incident. * User Feedback * Tabs for entity types when an incident a lot of entities * The number of alerts in alert attack activity title * The subject of the email insights. * Group membership validation * Workspace role assignment with groups issues resolved. ## Dec 13, 2024 *This release contains Crowdstrike Gamebooks and some reported bugs from our users.* If you have any questions, please feel free to contact us at [support@contraforce.com](mailto:support@contraforce.com). **New** * Crowdstrike Gamebooks: improving our current integration * Scan Endpoint: users will be able to target and scan a specific endpoint with a gamebook action through Crowdstrike * Isolate Endpoint: users will be able to target and isolate a specific endpoint with a gamebook action through Crowdstrike **Bugs** * Add/Update user error fix: there were issues when adding/updating users in the user management tab. this release fixes the inconsistencies ## Dec 7, 2024 *This release includes updates to provide user management across multiple workspaces and the ability to add multiple tenants to an end-customer tenant. Additionally, this release includes our ServiceNow integration for ticket management and association to incidents in ContraForce.* **New** * ContraForce IAM - This feature includes some powerful user management and access functionality. This will enable organization/user administrators to grant access to users in desired workspaces. * Organization roles * Organization Admin * User Admin * Workspace Admin * Org Member * Workspace roles * Workspace Owner * Workspace Content Admin * Incident Responder * Incident Analyst * ServiceNow Ticket Management - this integration will now allow users to create/associate and manage tickets that is connected to their organizations ServiceNow instance ## Sep 9, 2024 *This release includes our improved IP address entity insights* If you have any questions, please feel free to contact us at [support@contraforce.com](mailto:support@contraforce.com). **Improvements** * ContraForce Insights now supports IP address entity * for every IP address that appears as an entity in a ContraForce incident, ContraForce Insights will pull in signin logs from that IP address and will show if the signins are from a registered device ## September 3rd, 2024 *This release includes our new detection module SentinelOne. This includes gamebook actions for assets (endpoints) registered in SentinelOne* If you have any questions, please feel free to contact us at [support@contraforce.com](mailto:support@contraforce.com). **New** * SentinelOne Integration * Threats (incidents) are now available in the ContraForce platform * Gamebook actions available to SentinelOne * Disconnect from network (isolate endpoint gamebook) * Reconnect to network (unisolate endpoint gamebook) * Initiate scan (scan endpoint gamebook) **Improvements** * New and improved nav bar menu. This will help users navigate the platform in a better way. **Bug fixes** * n/a ## August 2, 2024 *This release includes our new detection module Splunk. This will be a beta release of Splunk and will role out enhancements over time.* If you have any questions about version 2024.08.02 please feel free to contact us at [support@contraforce.com](mailto:support@contraforce.com). **New** * CalVer versioning system is going to be used from now on * *Splunk Module (Beta) -* Splunk notable events will be now visible as a ContraForce incident in the platform. Features include: * Assign users to notable events * Change notable event status * filtering notable events by title, severity, status and time * ***Entities and alert timelines are only supported in Splunk notable events when Microsoft Defender logs are present*** **Improvements** * n/a **Bug fixes** * CSS bugfix with gamebook queue in incident detail page ## July 15, 2024 *This release includes the launch of the UIE 2.0 and Service Provider Onboarding.* **New** * *Unified Investigation Experience (UIE) 2.0* is now available in production. This release standardized an investigation of an incident for a user in the ContraForce platform. Every incident, regardless of source (SIEM or XDR), will have ContraForce insights and enriched entities available in the incident detail view and gamebook workbench. * For *User/Account* entity, sign-in and audit logs are displayed in a table with a time filter option * For *IP Address* entity, ContraForce specific insights are displayed in the insights tab * Related incidents tab shows a related incident feed that shows an incident investigation audit with incident closing comment (if incident is closed) * *Service Provider Onboarding* has enabled service providers to get started and pre-onboard their customers faster than ever. In a few steps, service providers can connect their ticketing system (AutoTask), add users, and pre-onboard customers before they get to the main ContraForce platform. **Improvements** * New quick link buttons in incident table * Gamepad button - takes you straight to desired incident gamebook workbench * Expand button - takes you straight to the incident detail **Bug fixes** * n/a ## June 4th, 2024 *This release includes the launch of the Email Gamebook Actions and Microsoft Entra ID Sign-in logs.* **New** * General availability of *Email Gamebook* actions. The email gamebook actions allows users to remove specific emails from an inbox when phishing or malicious activity is suspected. This is the first action that we are making available related to email. More to come in the future. * Microsoft Entra ID sign-in logs for an account entity in gamebook workbench * In the gamebook workbench, you can now click on an Account entity and it will fetch sign-in logs from Microsoft Entra ID. This will only fetch sign-in logs from that account entity if the user exist in the specific Microsoft Entra ID tenant. **Improvements** * Incident caching * this allows the incident data to be cached temporarily so that the incident data doesn't have to be fetched again. This has increased efficiency and load times of the portal. **Bug fixes** * n/a # ContraForce's Microsoft Sentinel Hunting Enterprise Application Source: https://docs.contraforce.com/guides/technical/contraforce-sentinel-hunting-enterprise-application This article provides an overview of ContraForce's Microsoft Sentinel Hunting enterprise application. **ContraForce's Microsoft Sentinel Hunting service principal** ContraForce's Microsoft Sentinel Hunting enterprise application is used to call the Log Analytics API with the Data.Read scope. In the delegated, on-behalf-of flow, this allows ContraForce's Microsoft Sentinel Hunting enterprise application to send direct queries to a Microsoft Sentinel workspace on behalf of the signed in user. We use this for providing deeper incident context via raw event/"evidence" logs, and for running queries from the Microsoft Sentinel Advanced Hunting page. ![Sentinel Hunting permissions](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/image-png-Sep-09-2025-02-56-33-2711-PM.png) If you have any questions, contact us at [support@contraforce.com](mailto:support@contraforce.com). # CrowdStrike Falcon Integration Source: https://docs.contraforce.com/guides/technical/crowdstrike-falcon-integration How ContraForce integrates with CrowdStrike Falcon — what it ingests, how the tier you declare changes the experience, and how Falcon's retention policy shapes what you see in the platform. ContraForce integrates with CrowdStrike Falcon to bring every Falcon detection into the unified Command Dashboard as a ContraForce incident, and to power Gamebook response actions on Falcon-managed devices. The integration is split across two CrowdStrike API clients — one for ingestion, one for response — so each client carries only the scopes it needs. **Detection-first ingestion.** Each Falcon detection becomes its own ContraForce incident across every tier (EDR, XDR, NG-SIEM). Cases and automated leads are not surfaced as incidents — they are CrowdStrike's analyst- and AI-curated groupings over the underlying detections, and ingesting them too would either double-count the signal or leave detections that never roll into a case or lead as silent blind spots. A first-class **ContraForce Cases** primitive that sits above incidents (cross-source) is on the roadmap as separate work. This page describes **what the integration does** and **what the tier you pick on the configuration page unlocks**. For the step-by-step setup, see [CrowdStrike Falcon Detection and Response Modules](/guides/onboarding/crowdstrike-detection-and-response-modules). ## What the Integration Does Polls CrowdStrike's unified Alerts API on a continuous loop and surfaces every new Falcon detection in the Command Dashboard as a ContraForce incident. Hydrates the detection with process tree, events timeline, device, and identity context drawn from CrowdStrike NG-SIEM and the alert payload itself. Status changes you make in ContraForce (New → In Progress → Closed) PATCH back to CrowdStrike via the Alerts API. Assigning a CrowdStrike incident in ContraForce always records the owner in the ContraForce audit log. If the workspace has a CrowdStrike service account bound on the Assignment Writeback card, the assignment is also PATCHed onto the underlying Falcon alert as that service account. See the callout below. Powers the Contain, Lift Containment, and On-Demand Scan Gamebooks on Falcon-managed devices via the Response API client. Triggers Security Delivery Agents on every CrowdStrike incident that lands in the unified pipeline. **Why owner assignment defaults to audit-only.** In MSSP topologies the ContraForce user (Entra UPN) frequently has no matching principal in the customer's CrowdStrike tenant, so pushing the assignment directly to Falcon either fails or lands on the wrong account. Recording the assignment locally lets every ContraForce user who can see the incident see the assigned owner without requiring a vendor-side identity match. The list view and the incident detail both hydrate the owner from the audit log on read. **The optional service-account writeback** lets you opt back into vendor-side visibility without giving up the MSSP-friendly default. You bind one Falcon user (typically a named service account in the customer's tenant) on the workspace's Assignment Writeback card; from then on every analyst assignment in ContraForce is mirrored onto the underlying alert as that bound user, and unassigning in ContraForce clears the Falcon-side assignee. The CF audit log is still the source of truth for which analyst actually picked up the incident; the writeback only controls what the customer sees on the Falcon side. Writeback failures (Falcon outage, deleted user, missing scope) are logged but do not fail the CF-side assignment, so the analyst queue stays responsive even when the vendor is degraded. *** ## Tier Selection — What You Pick on the Configuration Page When you configure the Detection module in ContraForce, you pick which Falcon **tier** the customer is licensed for. The tier you declare drives which scopes the API client needs and which advanced investigation surfaces (Process Tree ancestor walk, Events Timeline) unlock. **It does not change the ingestion shape** — every Falcon detection becomes its own ContraForce incident on every tier. There are three options: **For tenants on Falcon Insight (EDR) only.** Cases workbench is not available on this tier. | Behaviour | What you get | | --------------------------------------- | ---------------------------------------------------------------------------- | | **Incidents table shape** | Each Falcon detection becomes its own incident | | **Case context** | Not available — Cases workbench doesn't exist on this tier | | **Process Tree** | Falls back to the alert payload's 3-level lineage (no NG-SIEM ancestor walk) | | **Events Timeline** | Falls back to the detection alerts on the device itself (no LogScale events) | | **Agents on queue / gamebook auto-run** | Trigger on every detection | | **"Incidents Detected" metric** | Counts every detection ingested | **For tenants licensed for Falcon Insight XDR.** Cases workbench is active and used to resolve case context on detections that reference a case (and reserved for upcoming Cases features). | Behaviour | What you get | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Incidents table shape** | Each Falcon detection becomes its own incident (same as EDR) | | **Case context** | Available — case metadata can be resolved on detections that reference a case. Cases themselves are not surfaced as incidents (see the Detection-first ingestion note above) | | **Process Tree** | Falls back to the alert payload's 3-level lineage (NG-SIEM SKU is required for the ancestor walk) | | **Events Timeline** | Falls back to the detection alerts on the device itself | | **Agents on queue / gamebook auto-run** | Trigger on every detection | | **"Incidents Detected" metric** | Counts every detection ingested | **For tenants licensed for NG-SIEM.** Same detection-as-incident shape as the other tiers, plus the LogScale-backed Process Tree ancestor walk and the Events Timeline are unlocked. | Behaviour | What you get | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Incidents table shape** | Each Falcon detection becomes its own incident (same as EDR / XDR) | | **Case context** | Available — case metadata can be resolved on detections that reference a case. Cases themselves are not surfaced as incidents | | **Process Tree** | Full NG-SIEM ancestor walk via `ProcessRollup2` events on the `base_sensor` repository — surfaces System / smss.exe / winlogon.exe / userinit.exe / explorer.exe / etc. ancestors of the alerted process | | **Events Timeline** | Real Falcon EDR telemetry from `base_sensor` (process starts, DLL / library loads, registry / ASEP, file create / new executable / new script, DNS, network in/out, logon) scoped to the alert's process lineage | | **Agents on queue / gamebook auto-run** | Trigger on every detection | | **"Incidents Detected" metric** | Counts every detection ingested | The tier you declare must match the customer's actual Falcon SKU. The ingestion shape is the same on every tier — it's the **scopes** the API client needs and the **advanced investigation surfaces** that change. Picking NG-SIEM on a tenant that doesn't have the NG-SIEM SKU will produce missing-scope errors during Test Connection; picking EDR on an XDR / NG-SIEM tenant will leave the Process Tree ancestor walk and Events Timeline locked. ### How the Pipeline Works The ingestion shape is uniform across tiers — every Falcon detection becomes a ContraForce incident — and every downstream consumer reads from the same unified incident pipeline: | Stage | Behaviour | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Poller** (continuous) | Pulls alerts from CrowdStrike's Alerts API and filters out container types (cases, automated leads, legacy CrowdScore incidents) so only Falcon detections enter the pipeline | | **Interactive incidents-table query** | Same deny-list filter so what you see on a refresh matches what was queued | | **`IncidentDetected` audit / metric** | Written once per detection that enters the pipeline | | **Gamebook auto-run subscriber** | Triggers on every detection that lands in the pipeline | | **Agents on queue** | Same — agents trigger on every detection in the pipeline | The tier you declare on the configuration page only changes which scopes the API client needs and which advanced investigation surfaces unlock. It does not change the ingestion shape. *** ## Per-Product Allow-List Independent of the tier, each workspace can narrow ingestion to a subset of CrowdStrike's `product` values via the **Alert Types** card on the Detection module configuration page. Useful for MSSPs whose contract scope is narrower than the customer's full Falcon SKU. ### How the filter is applied The allow-list is enforced at every ingestion site so the queue, stats, agents, and gamebook auto-run all see the same shape: | Site | Filter behaviour | | --------------------------------------- | ---------------------------------------------------------------------------------------------- | | **Poller** (continuous) | Drops alerts whose `product` is outside the allow-list before queueing to the unified pipeline | | **Interactive incidents-table query** | Same allow-list applied post-hydration so refresh matches the queue | | **Stats / "Incidents detected" metric** | Counts only alerts that pass the allow-list | | **Related-incidents-by-entity** | Same allow-list applied to related-incident search results | Detections from products outside the allow-list never reach the pipeline — they are dropped at the retriever / poller layer, not hidden in the UI. Re-enabling a product surfaces its detections from the next poll cycle onward; previously dropped detections are not back-filled. ### Persistence model | Stored value | Meaning | | -------------------------------------------- | -------------------------------------------------------------- | | `null` (default for pre-existing workspaces) | "Ingest all products" — no narrowing applied | | Empty list | Same as `null` — friendly fallback when every box is unchecked | | Explicit list (e.g. `["epp", "idp"]`) | Ingest only the listed products; everything else is dropped | Changing the allow-list is **independent of credential save**. The Alert Types card has its own Save button and does not require Test Connection or Client Secret re-entry. ### Tier-driven shortlist The Alert Types card only shows the products typical for the declared tier by default to keep the UI compact: | Tier | Default checkbox shortlist | | ------------------------ | ------------------------------------------------- | | **Falcon Insight (EDR)** | `epp` | | **Falcon Insight XDR** | `epp`, `idp`, `xdr` | | **Falcon NG-SIEM** | All products (toggle hidden — no narrowing to do) | A "Show all products" toggle reveals the full catalog for non-standard SKU combos (e.g. EDR + Mobile add-on). The toggle auto-defaults to "show all" when the persisted selection already includes products outside the tier shortlist, so saved selections are never hidden. The shortlist is a UX hint rather than a hard licensing gate — the source of truth for tier-to-product availability still lives on the CrowdStrike side. ### Why a CF-side filter CrowdStrike's OAuth scopes don't expose per-product granularity — the only available scope is `alerts.read` across all products. So the filter has to live in ContraForce code; we cannot narrow at the API-client level. *** ## Verification Panel After you click **Test Connection** on the configuration page, ContraForce runs a live probe of the API client and renders a verification panel below the form. The panel **doesn't override your tier choice** — it confirms the claim against what's actually present on the API client: | Indicator | Meaning | | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ✓ on **Cases workbench** | The Cases endpoint returned data — case context resolution will work on detections that reference a case | | ✗ on **Cases workbench** | Cases endpoint returned no data — add `Cases: Read + Write` to the API client and confirm the tenant has the workbench enabled. Detections still ingest normally without it; only case-context resolution is degraded | | ✓ on **NG-SIEM** | NG-SIEM is reachable; if the tenant has retention metadata, the panel shows the approximate `base_sensor` retention horizon | | ✗ on **NG-SIEM** (NG-SIEM tier picked) | Add `NGSIEM: Read + Write` to the API client and confirm the tenant has the NG-SIEM SKU before saving | | ℹ︎ on **NG-SIEM** (EDR / XDR tier picked) | NG-SIEM is reachable on this client but the declared tier doesn't use it; pick the NG-SIEM tier to unlock the Process Tree ancestor walk and Events Timeline | The verification panel is informational — you can save with a missing-required indicator, but the corresponding feature won't work until you add the scope and re-test. *** ## CrowdStrike Data Retention — How It Affects the Platform The data ContraForce surfaces from CrowdStrike is bounded by Falcon's own retention policy. The Falcon console may have access to additional historical data that ContraForce doesn't query. ### Where retention shows up in the platform | Surface | What's bounded | By what | | -------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Detection Events Timeline** (NG-SIEM tier) | The events shown for a detection | The `base_sensor` repository's retention horizon on your Falcon NG-SIEM SKU. ContraForce reads this from the NG-SIEM `repos-metadata` endpoint at Test Connection / Save and persists it on the workspace; the Detection Events Timeline only queries within that window. | | **Process Tree ancestors** (NG-SIEM tier) | How far back the ancestor walk reaches | Same `base_sensor` retention. Ancestor processes that started before the retention window are missing from the tree. The Falcon console can sometimes show ancestors beyond this because it has access to repositories ContraForce doesn't query. | | **Detection visibility** | The earliest incident you can investigate in ContraForce | CrowdStrike's standard alert retention. Detections older than that no longer come back from the Alerts API at all. | | **Module configuration page** | How fresh the verification panel's NG-SIEM retention number is | The probe runs on Test Connection / Save. If retention has changed since you last saved, the displayed number may be stale until the next save. | ### What this means in practice **The Detection Events Timeline and Process Tree are subsets, not the full Falcon view.** ContraForce surfaces a banner above both surfaces on CrowdStrike incidents to remind you that the data shown is bounded by your tenant's NG-SIEM retention policy. If you need data beyond the retention window — older ancestors in the process tree, older events in the timeline — you must query the Falcon console directly. | Symptom you might see | Likely cause | | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Process tree stops at a process you'd expect to have a parent | Parent process started before the `base_sensor` retention horizon | | Events Timeline shows fewer events than the Falcon console for the same detection | Detection's process lifetime spans events older than the NG-SIEM retention window | | Detection Events Timeline is empty on the NG-SIEM tier | Either NG-SIEM scope is missing on the API client, or the tenant's retention is shorter than the alert's process lifetime — the verification panel and the saved retention horizon will tell you which | | Older incidents from a few months ago aren't accessible | The CrowdStrike Alerts / Cases retention has expired for those records on the tenant side | ### Tuning the retention horizon ContraForce does not control your CrowdStrike retention — it's set by the customer's NG-SIEM SKU. To change it: 1. Open the Falcon console 2. Navigate to **Next-Gen SIEM → Configuration → Settings → Data ingest** (path may vary by tenant) 3. Adjust the retention policy on the `base_sensor` repository according to your subscription terms 4. After the change takes effect, run **Test Connection** on the ContraForce configuration page so the new horizon persists on the workspace *** ## How the Pieces Fit Together ```mermaid theme={null} flowchart LR subgraph Falcon["CrowdStrike Falcon"] AlertsAPI[Alerts API] CasesAPI[Cases API] NGSIEM[NG-SIEM
base_sensor] Hosts[Hosts API] ODS[On-Demand Scans] end subgraph Iris["ContraForce"] Poller[Detection Poller] Pipeline[Unified Incident Pipeline] Dashboard[Command Dashboard] Insights[Entity Insights] Gamebooks[Gamebook Engine] Agents[Agents on Queue] Audit[Audit Log] end AlertsAPI -->|polls detections| Poller Poller -->|every detection| Pipeline Pipeline --> Dashboard Pipeline --> Agents Pipeline -->|IncidentDetected| Audit Pipeline -->|on new incident| Gamebooks Insights -->|process tree, events| NGSIEM Insights -->|case context| CasesAPI Gamebooks -->|Contain / Lift / Scan| Hosts Gamebooks -->|Scan| ODS Dashboard -->|owner read| Audit Dashboard -->|status / comments| AlertsAPI ``` The Detection API client carries the scopes for everything in the top-half (detection ingestion + investigation + case-context resolution + status writeback); the Response API client carries the scopes for the Hosts / ODS gamebook actions in the bottom half. *** ## Related Documentation Step-by-step setup with per-tier scope requirements How Gamebook response actions work Investigation context for an incident's entities Detailed role reference for ContraForce users *** Questions about the CrowdStrike Falcon integration? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Enterprise Applications Reference Source: https://docs.contraforce.com/guides/technical/enterprise-applications Complete reference for all ContraForce enterprise applications, their permissions, and what each enables in your environment. ## Overview ContraForce uses a modular application architecture designed around the **principle of least privilege**. Rather than requesting all permissions through a single application, ContraForce distributes responsibilities across purpose-built enterprise applications registered in your Microsoft Entra ID tenant. Each application only receives the permissions necessary for its specific function. This means you only grant permissions for the capabilities you actually use. For example, if you don't use Gamebooks to respond to endpoint threats, you never need to consent the ContraForce Gamebooks for MDE application. **Consent model.** ContraForce enterprise applications are consented with **application (app-only)** Microsoft Graph permissions. Admin consent for Microsoft Graph application permissions must be granted by a **Global Administrator** — Cloud Application Administrator and Application Administrator cannot grant it. Global Administrator is required for the one-time consent only and is not retained; activate it just-in-time with Privileged Identity Management (PIM) and deactivate afterward. Because actions run as the application (no signed-in user required), operator control is enforced through **Gamebook approval gates** — only Workspace Owners can approve high-impact actions — and a complete **audit trail** in the Gamebooks History page. ## Quick Reference | Application | App ID | Required For | Consent Timing | | ---------------------------------- | -------------------------------------- | --------------------------- | -------------------------------- | | ContraForce API | `24d97bc0-8f2b-45d5-8e0b-7fe286732ef2` | All deployments | First sign-in (core app consent) | | ContraForce Portal | `8b7cb435-9526-47ee-b79a-34433f0daad2` | All deployments | First sign-in (core app consent) | | ContraForce for MDE | `6efccc6a-f0d3-49e5-92d0-17d4afa9ba52` | Endpoint visibility | Module consent | | ContraForce Gamebooks for MDE | `ad7b0e79-3c37-4408-bf8f-eb89522cc920` | Endpoint response actions | Module consent | | ContraForce Gamebooks for Identity | `36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a` | User response actions | Module consent | | ContraForce Gamebooks for Email | `44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d` | Email response actions | Module consent | | ContraForce Sentinel Hunting | `6bf1c74d-7ade-4671-a507-166936f89a1f` | Log search & threat hunting | Module consent (XDR + SIEM only) | ## Applications by Module Every ContraForce deployment requires these two core applications: * **ContraForce API** — Core platform connectivity * **ContraForce Portal** — User authentication and portal access Core applications plus: * **ContraForce for MDE** — Endpoint visibility and incident data * **ContraForce Gamebooks for MDE** — Endpoint response actions * **ContraForce Gamebooks for Identity** — User response actions * **ContraForce Gamebooks for Email** — Email response actions Everything in XDR, plus: * **ContraForce Sentinel Hunting** — Log Analytics queries and threat hunting *** ## Core Applications ### ContraForce API The core service principal that enables communication between ContraForce services and Microsoft APIs including Microsoft Graph and Azure Resource Manager. This application coordinates all platform operations — from onboarding your workspace to managing Azure resources. **App ID:** `24d97bc0-8f2b-45d5-8e0b-7fe286732ef2` #### Delegated Permissions | Permission | Admin Consent | Purpose | | ----------------------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `offline_access` | No | Enables refresh token acquisition for persistent sessions | | `profile` | No | Retrieves signed-in user's name and object ID | | `Application.Read.All` | Yes | Evaluates which ContraForce service principals have been consented | | `RoleManagement.Read.All` | Yes | Evaluates user roles for Portal access control | | `RoleManagement.ReadWrite.Directory` | Yes | Assigns the password-reset directory role to the *Gamebooks for Identity* app when a customer enables the service-provider password reset add-on | | `User.Read.All` | Yes | Reads user profile data for user management operations | | `user_impersonation` (Azure Service Management) | No | Used throughout platform operation, not only at onboarding: backs Microsoft Sentinel access; enumeration of subscriptions, resource groups, and identity role assignments; and, with AI Agents, reading model capacities and quotas and pushing agent model and harness updates | *** ### ContraForce Portal Handles user authentication through Microsoft's OpenID Connect implementation and retrieves basic profile information for signed-in users. This application enables secure sign-in to ContraForce using your Microsoft work account. **App ID:** `8b7cb435-9526-47ee-b79a-34433f0daad2` #### Delegated Permissions | Permission | Admin Consent | Purpose | | ---------------- | ------------- | --------------------------------------------- | | `offline_access` | No | Enables refresh token acquisition | | `openid` | No | Allows sign-in using OpenID Connect | | `profile` | No | Retrieves signed-in user's name and object ID | *** ## Detection & Visibility Applications ### ContraForce for MDE (Microsoft Defender for Endpoint) Provides visibility into Microsoft Defender for Endpoint data, enabling endpoint monitoring, incident ingestion, and threat intelligence display in the ContraForce portal. This application provides device health, alert, and security posture data from Defender for Endpoint. **App ID:** `6efccc6a-f0d3-49e5-92d0-17d4afa9ba52` Requires Microsoft Defender for Endpoint to be deployed and active in the target tenant. Compatible with Microsoft 365 Business Premium, E3, E5, or standalone MDE licenses. #### Delegated Permissions | Permission | API | Admin Consent | Purpose | | -------------------------------- | --------------------------- | ------------- | --------------------------------------------------- | | `ThreatHunting.Read.All` | Microsoft Graph | Yes | Enables threat hunting queries | | `SecurityAlert.Read.All` | Microsoft Graph | Yes | Displays security alerts | | `SecurityIncident.Read.All` | Microsoft Graph | Yes | Displays security incidents | | `SecurityIncident.ReadWrite.All` | Microsoft Graph | Yes | Manages security incidents | | `Incident.Read` | Microsoft Threat Protection | Yes | Reads threat protection incidents | | `Incident.ReadWrite` | Microsoft Threat Protection | Yes | Manages threat protection incidents | | `AdvancedHunting.Read` | Microsoft Threat Protection | Yes | Queries raw event and incident data | | `Alert.Read` | WindowsDefenderATP | Yes | Displays Defender alerts | | `Machine.Read` | WindowsDefenderATP | Yes | Retrieves endpoint profile details | | `Score.Read` | WindowsDefenderATP | Yes | Displays Threat and Vulnerability Management scores | | `Vulnerability.Read` | WindowsDefenderATP | Yes | Displays vulnerability information | | `File.Read.All` | WindowsDefenderATP | Yes | Read file profiles | #### Application Permissions | Permission | API | Admin Consent | Purpose | | -------------------------------- | --------------------------- | ------------- | --------------------------------------------------- | | `SecurityAlert.Read.All` | Microsoft Graph | Yes | Displays security alerts | | `SecurityIncident.Read.All` | Microsoft Graph | Yes | Displays security incidents | | `SecurityIncident.ReadWrite.All` | Microsoft Graph | Yes | Manages security incidents | | `ThreatHunting.Read.All` | Microsoft Graph | Yes | Enables threat hunting queries | | `Incident.ReadWrite.All` | Microsoft Threat Protection | Yes | Manages threat protection incidents | | `Incident.Read.All` | Microsoft Threat Protection | Yes | Reads threat protection incidents | | `AdvancedHunting.Read.All` | Microsoft Threat Protection | Yes | Queries raw event and incident data | | `Alert.Read.All` | WindowsDefenderATP | Yes | Displays Defender alerts | | `Machine.Read.All` | WindowsDefenderATP | Yes | Retrieves endpoint profile details | | `Vulnerability.Read.All` | WindowsDefenderATP | Yes | Displays vulnerability information | | `Score.Read.All` | WindowsDefenderATP | Yes | Displays Threat and Vulnerability Management scores | | `File.Read.All` | WindowsDefenderATP | Yes | Read file profiles | *** ### ContraForce Sentinel Hunting Calls the Log Analytics API to send direct queries to a Microsoft Sentinel workspace on behalf of the signed-in user. This enables deeper incident context via raw event and evidence logs, and powers the Advanced Hunting page in ContraForce. **App ID:** `6bf1c74d-7ade-4671-a507-166936f89a1f` Only required for the **XDR + SIEM module**. Not needed for XDR-only deployments. #### Delegated Permissions | Permission | API | Admin Consent | Purpose | | ----------- | ----------------- | ------------- | ----------------------------------------------------------------------------- | | `Data.Read` | Log Analytics API | Yes | Queries Log Analytics workspace data for incident evidence and threat hunting | *** ## Response Applications (Gamebooks) These enterprise applications enable Gamebook response actions. Each application is scoped to a specific entity type, ensuring least-privilege access for automated incident response. ### ContraForce Gamebooks for MDE Enables automated response actions targeting **endpoint entities**, including device isolation, antivirus scans, and file quarantine operations. **App ID:** `ad7b0e79-3c37-4408-bf8f-eb89522cc920` #### Delegated Permissions (on-behalf-of flows) | Permission | Admin Consent | Purpose | | --------------------------- | ------------- | ---------------------------------------------------- | | `Machine.Isolate` | Yes | Isolates endpoints from the network | | `Machine.Offboard` | Yes | Offboards endpoints from Defender | | `Machine.Scan` | Yes | Initiates Microsoft Defender Antivirus scans | | `Machine.StopAndQuarantine` | Yes | Stops file execution and quarantines malicious files | | `Machine.ReadWrite` | Yes | Read and write machine information | | `User.Read` | Yes | Sign in and read user profile | #### Application Permissions (Default) | Permission | Admin Consent | Purpose | | --------------------------- | ------------- | ---------------------------------------- | | `Machine.Isolate` | Yes | Isolates endpoints without user presence | | `Machine.Scan` | Yes | Initiates scans without user presence | | `Machine.StopAndQuarantine` | Yes | Quarantines files without user presence | | `Machine.ReadWrite.All` | Yes | Read and write all machine information | | `Machine.Offboard` | Yes | Offboards endpoints from Defender | **Service Provider Mode:** Application permissions enable MSPs/MSSPs to execute endpoint response actions in customer tenants without requiring a user to be actively signed in. For each module, click **Consent** on the workspace **Modules** tab to grant these permissions. #### Enabled Gamebook Actions | Action | Description | | ---------------- | --------------------------------------------------------------------------------- | | Isolate Device | Disconnects the endpoint from the network while maintaining Defender connectivity | | Unisolate Device | Restores full network connectivity to a previously isolated endpoint | | Quick Scan | Initiates a quick antivirus scan on the endpoint | | Full Scan | Initiates a comprehensive antivirus scan on the endpoint | | Quarantine File | Stops a file from executing and quarantines it | | Offboard Device | Removes the endpoint from Defender for Endpoint management | *** ### ContraForce Gamebooks for Identity Enables automated response actions targeting **user entities**, including session invalidation, account lockout, password reset, and MFA reset capabilities. **App ID:** `36b0d51c-4c0f-4810-9cc4-bfbd40c7dd4a` #### Delegated Permissions (on-behalf-of flows) | Permission | Admin Consent | Purpose | | ---------------------------------------- | ------------- | ----------------------------------------------------------------------------- | | `User.ReadWrite.All` | Yes | Invalidates user sessions and locks accounts | | `UserAuthenticationMethod.ReadWrite.All` | Yes | Resets user passwords and removes a user's registered MFA methods (Reset MFA) | | `User.ReadWrite` | Yes | Read and write access to user profile | | `User.Read` | Yes | Sign in and read user profile | | `User.EnableDisableAccount.All` | Yes | Enable and disable user accounts | | `Directory.Read.All` | Yes | Read directory data | | `AuditLog.Read.All` | Yes | Read audit log data | #### Application Permissions (Default) | Permission | Admin Consent | Purpose | | ------------------------------- | ------------- | -------------------------------------------------------------------------------- | | `User.ReadWrite.All` | Yes | Enables automated session invalidation and account lockout without user presence | | `User.EnableDisableAccount.All` | Yes | Enable and disable user accounts | | `Directory.Read.All` | Yes | Read directory data | | `AuditLog.Read.All` | Yes | Read all audit log data | | `RoleManagement.Read.Directory` | Yes | Read all directory RBAC settings | #### Application Permissions (Service Provider Password Reset add-on) These are consented **only if** a customer enables the optional **service-provider password reset** add-on (Identity module → **Allow service provider to reset passwords**). The add-on lets the **Reset Password** Gamebook run app-only, without an on-behalf-of signed-in user. Enabling it is a customer decision and must be authorized by a **Global Administrator** or **Privileged Role Administrator** in the customer tenant. | Permission | Admin Consent | Purpose | | ------------------------------------ | ------------- | ------------------------------------------------------------------------------------ | | `User-PasswordProfile.ReadWrite.All` | Yes | Sets a new password on a user's `passwordProfile` so Reset Password can run app-only | **Directory role grant.** Enabling the add-on also assigns the **Authentication Administrator** Entra directory role to the *ContraForce Gamebooks for Identity* service principal in your tenant. This is a privileged role: it allows password and authentication-method management for **non-administrator** users only — it **cannot** reset passwords for Global Administrators or other higher-privileged roles, and a pre-flight check blocks those targets. The assignment is made only with explicit customer consent, and turning the add-on off removes it. Because this grant is a **directory role** rather than a Microsoft Graph application permission, it does **not** appear in the enterprise-app permission audit scripts. See [Auditing Enterprise App Permissions](/guides/technical/auditing-enterprise-app-permissions#directory-role-assignments) for how to review it. When the add-on is **not** enabled, **Reset Password** runs through the **delegated** (on-behalf-of) flow and requires a signed-in user with sufficient privileges. The modern Graph `resetPassword` endpoint does not support application-only calls, so app-only resets use the `passwordProfile` path enabled by the add-on above. #### Enabled Gamebook Actions | Action | Description | | --------------- | ---------------------------------------------------------------------------------------------------------- | | Disable Account | Blocks the user from signing in to any Microsoft service | | Enable Account | Restores sign-in access for a previously disabled account | | Reset Password | Generates a new temporary password for the user | | Reset MFA | Deletes the user's registered multi-factor authentication methods, forcing re-registration at next sign in | | Revoke Sessions | Invalidates all active refresh tokens and session cookies | *** ### ContraForce Gamebooks for Email (Microsoft 365 Response) Facilitates email response actions through the delete email Gamebook. This application can delete malicious emails from user mailboxes and purge phishing messages across the organization. **App ID:** `44dbf6fe-45e3-48a3-bac3-f8d4cf1dba6d` #### Delegated Permissions | Permission | Admin Consent | Purpose | | ---------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `Mail.ReadWrite` | No | Allows the app to create, read, update, and delete mail in all mailboxes without a signed-in user. Does not include permission to send mail. | #### Application Permissions | Permission | Admin Consent | Purpose | | ---------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `Mail.ReadWrite` | Yes | Allows the app to create, read, update, and delete mail in all mailboxes without a signed-in user. Does not include permission to send mail. | This application does **not** have the ability to send email. It requires Microsoft 365 Exchange licenses to be active in the target tenant. #### Enabled Gamebook Actions | Action | Description | | ----------------- | --------------------------------------------------------------- | | Soft Delete Email | Removes a malicious or suspicious email from the user's mailbox | *** ## Managing Users and Groups Group-to-workspace mapping is managed directly in the ContraForce portal under **Settings → User Management**. ContraForce no longer provisions a separate User Management enterprise application for group management. *** ## Permission Types Explained ContraForce uses two types of Microsoft Entra ID permissions: | Type | Description | Use Case | | -------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Application (app-only)** | Runs without a user context. The application acts with its own identity. | The default for ContraForce enterprise applications — automated investigation and response actions that execute without a signed-in user | | **Delegated** | Runs on behalf of a signed-in user. The application can only do what the signed-in user has permission to do. | Portal sign-in (OIDC) and the specific on-behalf-of flows that require a user, such as password reset | ContraForce enterprise applications are consented with **application (app-only)** permissions, so response actions can execute in a customer tenant without requiring an operator to be signed in. Because these actions run unattended, operator control is enforced through **Gamebook approval gates** and a complete **audit trail** in the Gamebooks History page. A small number of flows use delegated permissions with a signed-in user — for example, **password reset** runs on-behalf-of by default, unless a customer enables the **service-provider password reset** add-on, which lets it run app-only via a customer-consented `passwordProfile` permission and directory role (see [ContraForce Gamebooks for Identity](#contraforce-gamebooks-for-identity)). *** ## Managing Permissions After onboarding, you can review and manage enterprise application permissions in two locations: **From the ContraForce Portal:** Navigate to **Settings → Permissions** to consent additional service principals or review existing consent status. **From Microsoft Entra Admin Center:** Go to **Enterprise Applications** to review all ContraForce applications registered in your tenant and their granted permissions. *** ## Revoking Consent If you need to revoke consent for any ContraForce enterprise application: 1. Go to **Azure Portal → Microsoft Entra ID → Enterprise Applications** 2. Find the ContraForce application you want to revoke 3. Click **Properties** 4. Set **Enabled for users to sign-in** to **No** (to disable) or **Delete** the application entirely Revoking consent will disable the associated ContraForce capabilities for that workspace. For example, revoking the ContraForce for MDE application will stop Defender for Endpoint device and incident data from appearing in ContraForce. *** ## Troubleshooting | Issue | Likely Cause | Resolution | | ------------------------------------ | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Consent popup doesn't appear | Pop-up blocker active | Disable pop-up blocker for `portal.contraforce.com` | | Consent fails with permissions error | Insufficient privileges | Verify the account has the **Global Administrator** role. Admin consent for Microsoft Graph application permissions cannot be granted by Cloud Application Administrator or Application Administrator | | Application shows "Not Configured" | Consent flow incomplete | Re-run consent from workspace settings (gear icon) | | Gamebook actions unavailable | Service principal not consented | Consent the relevant Gamebooks application for the entity type | | Defender for Endpoint data missing | MDE application not consented | Consent the ContraForce for MDE application | *** ## Related Resources Independently verify enterprise application permissions in your tenant Step-by-step guide to onboarding your parent workspace Onboard customer workspaces with the right modules Complete reference of all Azure resources ContraForce deploys ContraForce platform roles and what each can do Questions about enterprise applications or permissions? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Understanding Events, Alerts, and Incidents Source: https://docs.contraforce.com/guides/technical/events-vs-alerts-vs-incidents ContraForce ingests data from over 100 available data sources into three classes: events, alerts, and incidents. Each class corresponds with the other and understanding the relationship between each w ## Introduction One of the foundations of security incident response is understanding your environment's data. It can be compared to putting together pieces of a puzzle. Data from different sources is correlated based on security engineering rules to generate incidents that need to be reviewed. The purpose of this article is to explain how data is streamed into ContraForce and how ContraForce can help take the guesswork out of incident response. ## How do we go from Event to Incident? ![Events to incidents flow](https://7831355.fs1.hubspotusercontent-na1.net/hubfs/7831355/MicrosoftTeams-image%20\(31\).png) The diagram above shows how events are grouped into alerts to then generate incidents. Lets look at what each stage means. ## Events Events include everything that has been observed on a system or environment. Event data can be thought of as audit logs. Events can be generated from a user, an application, or even a process. Many events simply generated from day to day activities or updates. Events are the foundation for detecting security incidents as the first steps an attacker may take will be captured. ## Alerts Alerts are a group of events that are related to a certain action or observation. Most data-sources have native rules and logic to generate alerts. The ContraForce engine automatically ingests and reviews alerts generated by connected data sources as they are streamed into ContraForce. ## Incidents Incidents are generated from security rules that have been created. If a number of alerts that match a security rule, an incident is generated. Additionally, rules can correlate alerts from multiple data sources to generate incidents. This allows users to manage security operations from a single dashboard with total visibility into all their connected data sources. ## What do I need to pay attention to? Between events, alerts, and incidents there is a lot of data. Of these three, Incidents are what need to be reviewed according to their assigned severity. Incident severity can be informational, low, medium, and high. Incidents with a high severity have the most potential for a business critical security event. ## Simplified Incident Response With ContraForce, all of your security data is in one place. Reduce the workload of managing security incidents and the guess work of how to eradicate threats with simple incident management guidance. # Microsoft Defender Capability Matrix Source: https://docs.contraforce.com/guides/technical/microsoft-defender-capability-matrix Complete feature reference for ContraForce capabilities with Microsoft Defender products across Business Premium, E3, and E5 licenses. This capability matrix details which ContraForce features are available for Microsoft Defender for Endpoint based on your Microsoft 365 license tier. Use this reference to understand what capabilities you can leverage and what dependencies may apply. This matrix only covers the **Microsoft Defender for Endpoint module** capabilities. ## Understanding the Matrix ### Legend | Symbol | Meaning | | :----: | --------------------------------------- | | ✓ | Capability fully available | | ✓(1) | Requires Microsoft Entra ID connection | | ✓(2) | Requires Microsoft Sentinel connection | | ✓(3) | Requires Defender for Endpoint Plan 2 | | ✓(4) | Requires Microsoft 365 Exchange license | | — | Not available | ### License Tiers Small/medium business license with Defender for Business Enterprise license with Defender for Endpoint P1 Full enterprise license with Defender for Endpoint P2 *** ## Incident Investigation Core capabilities for investigating security incidents detected by Microsoft Defender for Endpoint. ### Incident Management | Capability | Business Premium | E3 | E5 | | ------------------------------------- | :--------------: | :-: | :-: | | Bi-directional streaming of incidents | ✓ | ✓ | ✓ | | Fetching incident entities | ✓ | ✓ | ✓ | | Fetching incident evidence (logs) | ✓ | ✓ | ✓ | | Incident alert timelines | ✓ | ✓ | ✓ | | Incident investigation audit | ✓ | ✓ | ✓ | All core incident management features are available across all license tiers. ContraForce provides full incident visibility regardless of your Microsoft 365 license. *** ## Entity Enrichment & Triage Capabilities for enriching entity data and correlating related incidents during investigation. ### User Insights | Capability | Business Premium | E3 | E5 | | ----------------------- | :--------------: | :--: | :--: | | Related incident search | ✓ | ✓ | ✓ | | Sign-in logs | ✓(1) | ✓(1) | ✓(1) | | Audit logs | ✓(1) | ✓(1) | ✓(1) | | Entra ID profile | ✓(1) | ✓(1) | ✓(1) | **(1)** User insights require Microsoft Entra ID to be connected to ContraForce. Consent the appropriate enterprise applications during onboarding. ### IP Address Insights | Capability | Business Premium | E3 | E5 | | -------------------- | :--------------: | :--: | :--: | | Sign-in log activity | ✓(2) | ✓(2) | ✓(2) | | Related incidents | ✓(3) | ✓(3) | ✓ | **(2)** IP sign-in activity requires Microsoft Sentinel connection (XDR + SIEM module). **(3)** Some IP insights require Defender for Endpoint Plan 2 on Business Premium and E3. ### Device Insights | Capability | Business Premium | E3 | E5 | | ----------------- | :--------------: | :--: | :-: | | Device info | ✓ | ✓ | ✓ | | Device timeline | ✓(3) | ✓(3) | ✓ | | Related incidents | ✓(3) | ✓(3) | ✓ | **(3)** Device timeline and related incidents require Defender for Endpoint Plan 2 add-on for Business Premium and E3 licenses. ### Email Insights | Capability | Business Premium | E3 | E5 | | ----------------- | :--------------: | :--: | :-: | | Related incidents | ✓ | ✓ | ✓ | | Email info | ✓(3) | ✓(3) | ✓ | ### File Insights | Capability | Business Premium | E3 | E5 | | ----------------- | :--------------: | :-: | :-: | | Related incidents | ✓ | ✓ | ✓ | | File info | ✓ | ✓ | ✓ | ### URL Insights | Capability | Business Premium | E3 | E5 | | ----------------- | :--------------: | :--: | :-: | | Related incidents | ✓ | ✓ | ✓ | | URL info | ✓(3) | ✓(3) | ✓ | *** ## Log Search Advanced hunting and log query capabilities. | Capability | Business Premium | E3 | E5 | | ----------------------------- | :--------------: | :--: | :-: | | Log search (Advanced Hunting) | ✓(3) | ✓(3) | ✓ | Log search requires Defender for Endpoint Plan 2 for Business Premium and E3 licenses. E5 includes this capability natively. *** ## Endpoint Management Capabilities for managing and monitoring endpoints through ContraForce. | Capability | Business Premium | E3 | E5 | | ---------------- | :--------------: | :-: | :-: | | View device list | ✓ | ✓ | ✓ | | View device info | ✓ | ✓ | ✓ | All endpoint visibility features are available across all license tiers. ContraForce surfaces all devices managed by Defender for Endpoint. *** ## Gamebook Response Actions Automated response capabilities organized by entity type. ### Endpoint Actions | Capability | Business Premium | E3 | E5 | | --------------------------- | :--------------: | :-: | :-: | | Isolate endpoint | ✓ | ✓ | ✓ | | Anti-virus scan of endpoint | ✓ | ✓ | ✓ | | Remove from isolation | ✓ | ✓ | ✓ | Endpoint Gamebook actions require the **Gamebooks for Microsoft Defender for Endpoint** enterprise application to be consented. ### File Actions | Capability | Business Premium | E3 | E5 | | --------------- | :--------------: | :-: | :-: | | Quarantine file | ✓ | ✓ | ✓ | ### User Actions | Capability | Business Premium | E3 | E5 | | ---------------------------- | :--------------: | :--: | :--: | | Invalidate existing sessions | ✓(1) | ✓(1) | ✓(1) | | Reset user password | ✓(1) | ✓(1) | ✓(1) | | Lock out user | ✓(1) | ✓(1) | ✓(1) | | Unlock user | ✓(1) | ✓(1) | ✓(1) | **(1)** User Gamebook actions require Microsoft Entra ID connection and the **Gamebooks for Identity** enterprise application. ### IP Address Actions | Capability | Business Premium | E3 | E5 | | -------------------- | :--------------: | :-: | :-: | | Block IP (Azure NSG) | — | — | — | IP blocking via Azure Network Security Groups is planned for future release. ### Email Actions | Capability | Business Premium | E3 | E5 | | ----------------- | :--------------: | :--: | :--: | | Soft delete email | ✓(4) | ✓(4) | ✓(4) | **(4)** Email actions require a Microsoft 365 Exchange license and the **Microsoft 365 Response** enterprise application. *** ## Dependencies Reference ### Dependency (1): Microsoft Entra ID **Required for:** User insights, User Gamebook actions **How to enable:** 1. During onboarding, consent the ContraForce enterprise applications 2. The Gamebooks for Identity service principal must be consented for user response actions **Enterprise Applications:** * ContraForce API * ContraForce Portal * Gamebooks for Identity ### Dependency (2): Microsoft Sentinel **Required for:** IP sign-in activity **How to enable:** 1. Deploy the XDR + SIEM module instead of XDR-only 2. Connect your Sentinel workspace during onboarding Complete Sentinel onboarding guide ### Dependency (3): Defender for Endpoint Plan 2 **Required for:** Device timeline, IP/Email/URL detailed insights, Log search **How to enable:** * E5 licenses include Plan 2 natively * Business Premium and E3 require the Defender for Endpoint Plan 2 add-on **License options:** | Base License | Add-on Required | | ---------------- | ---------------------------- | | Business Premium | Defender for Endpoint Plan 2 | | Enterprise E3 | Defender for Endpoint Plan 2 | | Enterprise E5 | Included | ### Dependency (4): Microsoft 365 Exchange **Required for:** Email Gamebook actions (soft delete) **How to enable:** 1. Ensure users have Exchange Online licenses 2. Consent the Microsoft 365 Response enterprise application Microsoft 365 Response enterprise application details *** ## Complete Capability Summary ### By License Tier **Full capabilities:** * All incident management features * Endpoint management (view devices) * All endpoint Gamebook actions * File quarantine * Basic entity insights **With Entra ID:** * User insights (sign-in, audit, profile) * User Gamebook actions **With Exchange:** * Email soft delete **Requires Plan 2 add-on:** * Device timeline * Advanced log search * Detailed IP/Email/URL insights **Full capabilities:** * All incident management features * Endpoint management (view devices) * All endpoint Gamebook actions * File quarantine * Basic entity insights **With Entra ID:** * User insights (sign-in, audit, profile) * User Gamebook actions **With Exchange:** * Email soft delete **Requires Plan 2 add-on:** * Device timeline * Advanced log search * Detailed IP/Email/URL insights **Full capabilities:** * All incident management features * Endpoint management (view devices) * All endpoint Gamebook actions * File quarantine * Device timeline * Advanced log search * All entity insights (IP, Email, URL, File) **With Entra ID:** * User insights (sign-in, audit, profile) * User Gamebook actions **With Exchange:** * Email soft delete ### Quick Reference by Feature Area | Feature Area | Dependencies | Notes | | ------------------- | ------------------------------------- | ------------------------------- | | Incident Management | None | Full capability on all licenses | | Endpoint Management | None | Full capability on all licenses | | Endpoint Gamebooks | Gamebooks for Defender for Endpoint | Full capability on all licenses | | User Insights | Entra ID (1) | Same across all licenses | | User Gamebooks | Entra ID (1) + Gamebooks for Identity | Same across all licenses | | Device Timeline | Plan 2 (3) | Native on E5 | | Log Search | Plan 2 (3) | Native on E5 | | Email Actions | Exchange (4) + M365 Response | Same across all licenses | | IP Sign-in Activity | Sentinel (2) | Requires XDR + SIEM module | *** ## Maximizing Your Capabilities User insights and user Gamebook actions are essential for identity-based investigations. Ensure you consent all identity-related enterprise applications during onboarding. If you frequently need device timelines, advanced hunting, or detailed entity insights, the Defender for Endpoint Plan 2 capabilities are worth the investment. The XDR + SIEM module adds Sentinel incidents, advanced threat hunting, CMS, and IP sign-in insights. Consider upgrading if you use Sentinel. Many capabilities require specific enterprise applications. Review the [Enterprise Applications Overview](/guides/technical/enterprise-applications) and consent all applications relevant to your needs. *** ## Related Guides Deploy the Defender module All service principals and permissions Response action capabilities *** Questions about capabilities or licensing? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Microsoft Defender Native Automations Source: https://docs.contraforce.com/guides/technical/microsoft-defender-native-automations How Microsoft Defender's native automations (AIR, ZAP, and Automatic Attack Disruption) work, how ContraForce surfaces their status per Workspace, and how the Security Delivery Agent defers to them so it does not waste effort on work Defender already did. Many of your customers run Microsoft Defender with its native automations turned on. Those automations investigate, remediate, and even contain threats on their own, often before a ContraForce analyst or the Security Delivery Agent ever looks at the incident. This page explains what Defender's automations do by themselves, how ContraForce makes their status visible per Workspace, and where the Security Delivery Agent defers to them so no agent compute is spent on incidents Defender already resolved. Coordination today covers **incident dispatch**, not individual response actions. The agent stands down when Defender already handled an incident, but ContraForce does not yet re-check ZAP or containment state at the moment a Gamebook action runs. Part 2 marks exactly which behaviors are live and which are not. This is a reference page for service providers managing customer Workspaces. For setting up the Defender integration itself, see [Microsoft Defender for Endpoint Module](/defender-for-endpoint-module) and the [Microsoft Defender Capability Matrix](/guides/technical/microsoft-defender-capability-matrix). ## Part 1: Defender's Native Automations Microsoft Defender ships three distinct automation mechanisms. They trigger on different signals, act at different layers, and sit at opposite ends of the severity spectrum. Understanding which is which is the key to understanding how ContraForce coordinates with each. **Automated Investigation and Response.** Investigates alerts of specific types and applies or queues remediation. Frequently auto-resolves benign incidents. **Zero-hour Auto Purge.** Retroactively quarantines or junks malicious mail already sitting in the mailbox, up to 48 hours after delivery. **Automatic Attack Disruption.** Contains active, high-confidence attacks at machine speed, without waiting for approval. ### Automated Investigation and Response (AIR) [AIR](https://learn.microsoft.com/defender-xdr/m365d-autoir) is triggered by **alert type, not by incident severity**. Defender launches an automated investigation when it sees alerts such as suspicious email, attachment, or URL activity; compromised-account signals; [Zero-hour Auto Purge](https://learn.microsoft.com/defender-office-365/zero-hour-auto-purge) actions; user submissions (user-reported phishing); user-click alerts; and suspicious mailbox behavior. An analyst can also start an investigation manually. Which alerts launch an investigation is driven by Defender's Threat-management alert policies, specifically those with **Automated investigation = Yes**. Once running, an investigation produces findings and recommended actions. Whether Defender applies remediation automatically or holds it for analyst approval depends on the tenant's [automation level](https://learn.microsoft.com/defender-endpoint/automation-levels): full automation remediates automatically, while semi-automation queues actions in the Action Center for approval. **AIR frequently auto-resolves benign incidents.** When an investigation finds no threat, Defender resolves the incident on its own. Microsoft notes this is a common outcome in user-submission scenarios, where a user reports a message as phishing and the investigation clears it. This is exactly the pattern ContraForce's settling window is designed for (see Part 2). **A Defender product change that does not affect the integration.** As of 2026-09-01, Microsoft is folding the standalone Defender for Endpoint AIR investigation experience into the default protection stack; it will no longer run as a separate investigation experience or be available for manual triggering in Defender for Endpoint. ContraForce reads incident and alert **state**, not AIR investigation objects, so this transition does not change how the integration behaves. AIR capabilities for Defender for Office 365 remain available. ### Zero-hour Auto Purge (ZAP), Defender for Office 365 [ZAP](https://learn.microsoft.com/defender-office-365/zero-hour-auto-purge) retroactively neutralizes phishing, spam, and malware email, and Microsoft Teams messages, that were already delivered to cloud mailboxes. Because spam and malware signatures update continuously, a message that was clean at delivery can be re-judged as malicious afterward. ZAP acts on that message **up to 48 hours after delivery**, across all cloud mailboxes. It is on by default for high-confidence phishing and malware. The action ZAP takes depends on the verdict and on the tenant's anti-spam, anti-malware, and anti-phishing policies: it may quarantine the message or move it to Junk Email. Like AIR, ZAP is driven by verdict and policy, **not by incident severity**. **ZAP has a long tail and a visibility gap.** Two facts shape how ContraForce coordinates with it: * **The 48-hour window is far longer than any dispatch delay.** A message can be purged well after an incident lands in ContraForce, so ZAP cannot be accounted for with a short settling delay alone. Accounting for it fully requires a re-check at the moment a remediation is about to run, which ContraForce does not perform today (see Part 2). * **ZAP is not recorded in Exchange mailbox audit logs.** It is a system action visible through [Threat Explorer](https://learn.microsoft.com/defender-office-365/zero-hour-auto-purge#how-to-see-if-zap-moved-your-message) by filtering the **Additional action** column for the value **ZAP**. Allowlists and Exchange mail-flow (transport) rules can also override ZAP, so coverage is not uniform across a tenant. ### Automatic Attack Disruption (Defender XDR) [Automatic Attack Disruption](https://learn.microsoft.com/defender-xdr/automatic-attack-disruption) correlates signals across Defender XDR into a single high-confidence incident for active, sophisticated attacks: ransomware campaigns, business email compromise, and adversary-in-the-middle. It operates at the incident level and is inherently high severity. This is the opposite end of the spectrum from AIR's benign auto-resolutions. When Attack Disruption fires, it **contains the attack automatically, without approval, regardless of the tenant's automation-level settings**. Its [response actions](https://learn.microsoft.com/defender-xdr/automatic-attack-disruption#automated-response-actions) include: contain device, contain IP, isolate device, disable user (including Entra-only cloud-native accounts), revoke user sessions, and OAuth app containment. **Attack Disruption acts without approval and cannot be gated by automation level.** Because it contains live attacks at machine speed, there is no approval step to wait on and no automation setting that holds it back. Any coordinating system must assume the containment is already in effect. ContraForce never delays an attack-disruption incident: it is excluded from the settling window and the agent engages immediately. Note that ContraForce does not currently block a Gamebook action against an entity Defender has already contained. Containment state is surfaced for awareness, not enforced at action time, so analysts should check the Action Center before running a containment action on an attack-disruption incident. You can recognize an attack-disruption incident by several signals: the **Attack Disruption** incident tag in the queue and on the incident page, a **(attack disruption)** suffix appended to the incident title, the actions listed in the Action Center, and the [DisruptionAndResponseEvents](https://learn.microsoft.com/defender-xdr/advanced-hunting-disruptionandresponseevents-table) advanced-hunting table. ### Comparison at a Glance | Mechanism | What triggers it | What it does | Severity / scope | How ContraForce accounts for it | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **AIR** | Specific alert types (suspicious email / URL / attachment, compromised account, ZAP, user submissions, user-click, suspicious mailbox behavior) or a manual analyst action | Runs an automated investigation, produces findings and recommended actions, applies or queues remediation, and auto-resolves incidents where no threat is found | Any severity; commonly low or benign (user-reported phishing) | Adaptive settling window on low-severity incidents, plus a pre-dispatch skip when AIR has already resolved or merged the incident | | **ZAP** | Updated spam / malware / phishing signals matching already-delivered mail or Teams messages, up to 48 hours after delivery | Retroactively quarantines or junks the message per the anti-spam, anti-malware, and anti-phishing policies | Not tied to incident severity; acts at the message level | Visibility only today. The Native Automations card reports whether ZAP is active in the tenant; ContraForce does not yet check ZAP before proposing an email remediation | | **Attack Disruption** | High-confidence correlation of XDR signals for an active, sophisticated attack (ransomware, BEC, adversary-in-the-middle) | Contains the attack without approval: contain device / IP, isolate device, disable user, revoke sessions, OAuth app containment | Inherently high severity; acts at the incident level | Never delayed. Attack-disruption incidents are excluded from the settling window, so the agent engages immediately | ## Part 2: How ContraForce Complements Defender's Automations ContraForce assumes Defender's automations are running and coordinates around them in two ways: it makes their status visible to you per Workspace, and it makes the Security Delivery Agent automation-aware at dispatch time so the agent does not investigate an incident Defender already closed. ### Visibility: The Defender XDR Module Configuration Tab The Defender XDR module's **Configuration** tab gives you a per-Workspace read on what Defender is actually doing, so you are not guessing whether a customer's automations are on. A per-mechanism status for AIR, ZAP, and Attack Disruption: * **Active**, with an observed count and recency * **Not observed**, meaning licensed (or licensing unknown) but no events in the probe window * **Not licensed**, asserted only when the license read succeeded and the SKU is absent * Before any probe has run, the card is empty and prompts you to click **Run detection** The status is derived by behavioral probing: Defender advanced hunting plus Microsoft Graph, using the consent already collected when the module was onboarded. The hunting and alert reads need no additional scope. Two views of the customer's Defender footprint side by side: * **License truth:** which Defender products the Workspace is licensed for * **Signal truth:** which products are actually emitting alerts Comparing the two surfaces "licensed but no signal" gaps, where a product is paid for but silent. **License truth requires one extra permission.** The license half of the Detected Products card reads Microsoft Graph `subscribedSkus`, which needs `Organization.Read.All` admin consent on the Defender app registration. Without it the probe degrades gracefully: the automation states still populate from hunting data, but license truth is unavailable and the "licensed but no signal" gap list is suppressed rather than guessed. An empty gap list therefore means either no gaps or no license read, so confirm consent before reading it as a clean bill of health. The probe runs automatically when the Defender module is consented at onboarding, and on demand whenever you click the **Run detection** button on the card. There is no scheduled background refresh today, so for a long-lived Workspace the card reflects the last time the probe actually ran. The **Last detected** timestamp under the card tells you how stale the reading is. ### An Automation-Aware Security Delivery Agent The Security Delivery Agent is built to defer to Defender's own automation at dispatch time. Two behaviors keep it from spending an investigation on work Defender already did. **"Not observed" does not disable the settling window.** Absence of evidence is not evidence of absence, so a mechanism the probe did not observe is still treated as possibly active. The gate stays conservative rather than assuming an automation is off. Immediately before dispatching the agent, ContraForce re-checks the **live** Defender incident state. If the incident was resolved by AIR, or was merged or redirected into another incident, the agent is skipped entirely: no investigation runs, no agent compute is spent, and a **skipped: handled by Defender automation** entry is written to the Workspace activity log for auditability. You keep a clear record of why the agent stood down. For **low and informational severity** Defender XDR incidents, ContraForce briefly holds the incident before running the agent, giving Defender's AIR a chance to auto-resolve it first (the common outcome for user-reported phishing). The length of the hold is derived per Workspace from how quickly that tenant's incidents actually auto-resolve, bounded to between 5 and 30 minutes. **Medium and high severity incidents, and attack-disruption incidents, are never delayed**: the agent engages immediately. The window is set automatically from the probe. There is no manual override: the Native Automations card displays the current value as a read-only chip so you can see what the agent is waiting for. The net effect for you is that the agent does not investigate incidents Defender already resolved, and no agent compute is spent on them. **Not yet covered: ZAP dedup and containment guards at action time.** Both coordination points below are on the roadmap but are not implemented today. Neither the agent nor a Gamebook currently re-checks ZAP or Defender containment state before proposing a response action: * **ZAP.** Because ZAP acts up to 48 hours after delivery, an email remediation can be proposed for a message Defender already purged. ContraForce detects whether ZAP is active in the tenant, but does not check individual messages at action time. * **Attack-disruption containment.** ContraForce does not block an action against an entity Defender has already contained. Until these ship, treat the Action Center as the source of truth before running an email or containment action on a Defender incident. ### Guidance for Service Providers Use the **Detected Products** card to confirm which Defender automations a customer is actually licensed for before you count on them to handle a class of incidents. A "licensed but no signal" gap means an automation you expect to fire may not be. Check that `Organization.Read.All` is consented first. Without it there is no license truth, and the gap list is suppressed rather than populated, so it will look clean whether or not gaps exist. The probe does not refresh on a schedule. If a customer enables an automation, changes licensing, or onboards a new Defender product, the card keeps showing the previous reading until someone clicks **Run detection**. Check the **Last detected** timestamp before treating the card as current. Each Defender automation is covered differently today: * **AIR auto-resolution** is handled by the settling window plus the pre-dispatch skip. * **ZAP** is detected for visibility only. There is no pre-action dedup at Gamebook time yet, so an email action can be proposed for a message ZAP already purged. * **Attack Disruption** is never delayed and the agent engages immediately, but ContraForce does not block an action against an already-contained entity. ## What This Means for You * **Defender's automations run on their own terms.** AIR triggers on alert type and often auto-resolves benign incidents; ZAP purges bad mail up to 48 hours after delivery; Attack Disruption contains live attacks without approval. None of the three keys off ContraForce incident severity except in the sense that Attack Disruption is inherently high severity. * **ContraForce coordinates at the incident level.** The Configuration tab shows you what each automation is doing per Workspace, and the Security Delivery Agent defers to Defender through a pre-dispatch skip and an adaptive settling window. * **You save agent effort without losing coverage.** Low and informational severity incidents get a chance to auto-resolve before the agent spends compute on them, while medium, high, and attack-disruption incidents are engaged immediately. * **Action-level coordination is not there yet.** ZAP dedup and containment guards at Gamebook-action time are not implemented, so the Action Center remains the source of truth before running an email or containment action. ## Related Documentation Consent the module and enable Defender data and response in ContraForce Which ContraForce capabilities are available by Defender license tier How the Security Delivery Agent runs on the incident queue How Gamebook response actions work *** Questions about how ContraForce coordinates with Microsoft Defender's native automations? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Configure Notifications Source: https://docs.contraforce.com/guides/technical/notifications-configuration Customize email notifications for Microsoft Sentinel incidents by severity and workspace. Configure alerts for your SOC team with per-customer granularity. ContraForce provides customizable email notifications for Microsoft Sentinel incidents, allowing you to configure alerts by severity level for each workspace. Keep your team informed about critical security events while filtering out noise. **Module Requirement:** Full notification customization is available with the **XDR + SIEM module**. The XDR-only module has limited notification capabilities (Gamebook notifications only). ## Notification Capabilities by Module | Feature | Defender Module | XDR + SIEM Module | | --------------------------------- | :-------------: | :---------------: | | Sentinel incident notifications | — | ✓ | | Severity-based filtering | — | ✓ | | Per-workspace customization | — | ✓ | | Gamebook completion notifications | ✓ | ✓ | | Distribution group support | — | ✓ | **Defender Module Users:** ContraForce does not generate email notifications for Defender for Endpoint incidents. Use Microsoft Defender's built-in notification settings for Defender alerts. Deploying ContraForce will not interrupt your existing Defender notification configuration. *** ## SIEM Notification Overview With the XDR + SIEM module, you can: Choose which incident severities trigger notifications—High, Medium, Low, or Informational Set different notification preferences for each customer workspace Route notifications to shared mailboxes or team distribution lists One-click access to incidents directly from notification emails *** ## Configuring Notification Settings ### Accessing Settings Click **Settings** in the ContraForce navigation menu Click the **Notifications** tab Select the workspace you want to configure from the dropdown **Direct link:** [portal.contraforce.com/settings/notifications](https://portal.contraforce.com/settings/notifications) ### Notification Settings Interface ContraForce notification settings interface The notification settings interface displays: | Element | Description | | ---------------------- | ----------------------------------------------- | | **Workspace Selector** | Choose which workspace to configure | | **Severity Toggles** | Enable/disable notifications per severity level | | **Recipient Display** | Shows current notification recipients | | **Save Button** | Apply changes to the selected workspace | *** ## Severity-Based Filtering Customize which severity levels generate email notifications for each workspace. ### Default Behavior By default, notifications are **enabled for all severity levels** when a workspace is onboarded: * ✅ High severity — Enabled * ✅ Medium severity — Enabled * ✅ Low severity — Enabled * ✅ Informational — Enabled ### Configuring Severities Choose the workspace from the dropdown Click the toggle for each severity level to enable or disable Click **Save** to apply your changes Severity toggle settings ### Severity Level Guidance **High severity incidents** indicate active threats requiring immediate response. **Examples:** * Active malware execution * Credential theft detected * Ransomware activity * Privilege escalation attacks **Recommendation:** Always keep enabled for all workspaces **Medium severity incidents** indicate potential threats needing investigation. **Examples:** * Suspicious sign-in activity * Unusual data access patterns * Policy violations * Reconnaissance activity **Recommendation:** Enable for most workspaces; disable only if generating excessive noise **Low severity incidents** are often informational or low-risk events. **Examples:** * Minor policy alerts * Informational detections * Low-confidence alerts **Recommendation:** Enable based on team capacity and customer SLA **Informational incidents** are typically audit events or very low-priority alerts. **Examples:** * Audit log events * Configuration changes * Informational notices **Recommendation:** Disable for most workspaces to reduce noise; enable only for compliance requirements *** ## Per-Workspace Configuration MSSPs managing multiple customers can configure different notification settings for each workspace. ### Use Cases | Scenario | Configuration | | ------------------------------- | -------------------------------------- | | **Premium SLA customer** | All severities enabled | | **Standard SLA customer** | High and Medium only | | **Development/test workspace** | High only or disabled | | **Compliance-focused customer** | All severities including Informational | ### Configuring Multiple Workspaces Select workspace, set severity preferences, save Use the dropdown to select the next workspace Adjust severity settings for this workspace Continue for all workspaces requiring custom settings Document your notification configuration for each customer. This helps maintain consistency and simplifies troubleshooting when customers report notification issues. *** ## Email Notification Details ### Sender Address All ContraForce notifications are sent from: ``` noreply@notifications.contraforce.com ``` Add this address to your email allowlist and your customers' allowlists to ensure notifications aren't blocked by spam filters. ### Email Content Each incident notification email includes: | Field | Description | | ------------------------ | ------------------------------------------ | | **Subject Line** | Incident title with severity indicator | | **Incident ID** | Unique identifier for tracking | | **Severity** | High, Medium, Low, or Informational | | **Description** | Summary of the security event | | **MITRE Tactics** | Associated ATT\&CK techniques | | **Entities** | Affected users, devices, IPs, etc. | | **View Incident Button** | Direct link to the incident in ContraForce | ### Example Email Example ContraForce notification email The **View Incident** button opens the incident directly in the ContraForce Portal, allowing immediate investigation and response. *** ## Distribution Group Notifications Route notifications to a team distribution list instead of individual users for better team visibility. ### Benefits Entire SOC team sees all alerts in a shared inbox Alerts aren't missed when individuals are unavailable Route to on-call rotation distribution groups Use email-to-ticket systems for automatic tracking ### Setting Up Distribution Groups Distribution group notifications require setup assistance from ContraForce: Determine the distribution group email address (e.g., `soc-alerts@yourcompany.example`) Share the email address during initial workspace onboarding For existing workspaces, email [support@contraforce.com](mailto:support@contraforce.com) ContraForce Engineering team configures the distribution group Test that notifications are reaching the distribution group Distribution group changes require ContraForce support assistance. Self-service distribution group configuration is planned for a future release. ### Common Distribution Group Patterns | Pattern | Email Example | Use Case | | --------------------- | ----------------------------------------------------------------- | ---------------------------------- | | **SOC Team Inbox** | [soc-team@company.example](mailto:soc-team@company.example) | Shared visibility for all analysts | | **Customer-Specific** | [customer-alerts@msp.example](mailto:customer-alerts@msp.example) | Dedicated inbox per customer | | **On-Call Rotation** | [oncall@company.example](mailto:oncall@company.example) | Routes to current on-call analyst | | **Ticketing System** | [tickets@company.example](mailto:tickets@company.example) | Auto-creates tickets in ITSM | *** ## Gamebook Notifications Gamebook notifications are available for **all modules** (XDR and XDR + SIEM). ### Gamebook Notification Events | Event | Notification Sent | | ------------------------------- | :---------------: | | Gamebook completed successfully | ✓ | | Gamebook execution failed | ✓ | | Gamebook requires approval | ✓ | | Gamebook approved/rejected | ✓ | ### Gamebook Email Content * Gamebook name and type * Target incident details * Actions executed * Execution status (Success/Failed/Pending) * Workspace name * Link to view details Gamebook notifications help track automated response actions across your customer base, providing audit trails for compliance and visibility into response activity. *** ## Integration with External Tools ### Email-to-Ticket Integration Route notifications to ITSM platforms that support email-based ticket creation: | Platform | Setup Method | | --------------------------- | ------------------------------- | | **ServiceNow** | Configure inbound email actions | | **Jira Service Management** | Use email request channel | | **Autotask** | Set up email-to-ticket rules | | **ConnectWise** | Configure email connector | | **Zendesk** | Use support email address | ### Microsoft Teams / Slack For real-time chat notifications: Set up an email address for your Teams channel or Slack workspace Provide this email to ContraForce as your notification recipient Notifications appear directly in your team chat *** ## Best Practices Begin with High severity only, monitor for a week, then gradually enable Medium and Low based on team capacity and incident quality. Configure severity settings to match your SLA with each customer. Premium customers might get all severities; standard customers might only get High and Medium. Individual email notifications risk being missed. Distribution groups ensure the entire team has visibility into alerts. Route notifications to your ITSM for automatic ticket creation, SLA tracking, and audit trails. Add `noreply@notifications.contraforce.com` to email allowlists for your organization and your customers. Monthly review notification settings. If a severity level generates too much noise, consider disabling it while you tune detection rules. *** ## Troubleshooting ### Common Issues | Issue | Possible Cause | Solution | | ------------------------------- | ------------------------ | ----------------------------------------------------------- | | **Not receiving notifications** | Spam filter blocking | Add sender to allowlist | | **Not receiving notifications** | Wrong module deployed | Verify XDR + SIEM module is active | | **Not receiving notifications** | Severity disabled | Check notification settings | | **Not receiving notifications** | Distribution group issue | Contact support to verify configuration | | **Too many notifications** | All severities enabled | Disable Informational and Low | | **Delayed notifications** | Email server delays | Check your mail server; ContraForce sends in near real-time | | **Missing workspaces** | Permissions issue | Verify you have admin access to the workspace | ### Testing Notifications To verify notifications are working: Confirm notification settings are enabled for the workspace Ensure the sender address isn't blocked Wait for a new Sentinel incident (or ask ContraForce to send a test) Check inbox, spam, and junk folders Confirm the email contains expected incident details *** ## Frequently Asked Questions All notifications are sent from `noreply@notifications.contraforce.com` No, ContraForce does not send notifications for Defender for Endpoint incidents. Use Microsoft Defender's built-in notification settings. ContraForce notifications are for Sentinel incidents (XDR + SIEM module) and Gamebook activity. Contact [support@contraforce.com](mailto:support@contraforce.com) with the email address. The ContraForce Engineering team will configure it for your account. Email templates are standardized and cannot be customized. For custom formatting, route emails to a ticketing system that can transform them. Notifications are sent in near real-time when Sentinel incidents are processed. Typical delay is under 5 minutes from incident creation. Currently, notifications are configured at the workspace level, not per-user. All recipients for a workspace receive the same notifications based on severity settings. ContraForce currently supports email only. For SMS or push, route email notifications to PagerDuty, Opsgenie, or similar services. *** ## Related Guides XDR vs XDR + SIEM module comparison Deploy the XDR + SIEM module Handling incidents from notifications Automated response actions *** Questions about notifications? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Parallel Incident Deduplication Source: https://docs.contraforce.com/guides/technical/parallel-incident-deduplication How ContraForce keeps a single copy of an incident that exists in both Microsoft Defender XDR and Microsoft Sentinel, and what that means for notifications, agents, webhooks, and metrics. Microsoft keeps a Defender XDR incident and its Microsoft Sentinel counterpart synchronised, and presents them to you as one "parallel incident". ContraForce reads both APIs, so without a rule that same real-world incident arrives twice under two different vendor IDs. ContraForce resolves this **per incident**: it keeps the incident on the side it originated and discards the mirror. No configuration is required, and there is no toggle to set. Deduplication only applies to a workspace with **both** the Microsoft Defender XDR and Microsoft Sentinel detection modules connected. See [Detection module state](#detection-module-state). ## How ContraForce decides Both systems label the origin of an incident, and ContraForce reads those labels directly. There is no cross-API lookup, no correlation database, and no dependence on which copy arrives first. | Side | The incident is discarded when | | :--------------------- | :------------------------------------------------------------------------------------------------------------- | | Microsoft Sentinel | `providerName` is `Microsoft 365 Defender`, or is `Microsoft XDR` and the alert products are Defender-produced | | Microsoft Defender XDR | every alert on the incident has `serviceSource` of `microsoftSentinel` | | Either | Nothing else. Anything not positively identified as a mirror is kept. | That last row is deliberate. An unreadable label, an unfamiliar provider, or a provider call that fails all mean "show the incident". A duplicate is a visible annoyance; a discarded incident is silent data loss. ### The providerName values you will see | Value | Meaning | | :----------------------- | :---------------------------------------------------------------------------------------------------------------------- | | `Azure Sentinel` | Created in Sentinel. Never treated as a mirror. | | `Microsoft 365 Defender` | Forwarded into Sentinel by the Defender XDR connector. The Defender incident is the original. | | `Microsoft XDR` | The workspace is onboarded to the Defender portal, so both representations exist. The alert products decide the origin. | ## The three forwarding scenarios The Defender XDR data connector in Microsoft Sentinel has **Connect incidents & alerts** enabled, so Defender incidents are pushed into Sentinel. Those forwarded copies carry `providerName` of `Microsoft 365 Defender`. * **Kept:** the Defender XDR incident, attributed to Defender. * **Discarded:** the Sentinel copy. * **Unaffected:** incidents created natively in Sentinel, which carry `Azure Sentinel` and are never mirrors. In the portal, an incident that originated in Defender shows **Microsoft Defender XDR** as its source, even though a copy also exists in your Sentinel workspace. The Sentinel workspace is onboarded to the Microsoft Defender portal, so Sentinel analytic rules surface as Defender incidents. Those incidents carry `providerName` of `Microsoft XDR`, and their alerts have a `serviceSource` of `microsoftSentinel`. * **Kept:** the Sentinel incident, attributed to Sentinel. * **Discarded:** the Defender mirror. * **Unaffected:** genuinely Defender-produced incidents in the same workspace, which are kept and attributed to Defender. Incidents created manually, through the API, or by a playbook exist **only** in Sentinel even in a fully onboarded workspace. They carry `Azure Sentinel` and are always kept. This is why ContraForce deduplicates per incident rather than suppressing a whole source. Neither connector is forwarding. Each system holds its own incidents and there are no mirrors. * **Kept:** everything, from both sources. * Nothing is discarded, and behaviour is identical to a workspace with a single detection module. A workspace can move into this state and back out of it without any configuration change in ContraForce, because the decision is made per incident at the time it arrives. Forwarding in **both** directions at once is common, not exceptional. A workspace onboarded to the Defender portal will typically show Sentinel-origin incidents in Defender **and** Defender-origin incidents in Sentinel. Because the rule is applied per incident, each one is resolved on its own evidence and the correct copy survives in both directions simultaneously. ## Detection module state Deduplication is only safe when ContraForce actually reads both systems. Before discarding a mirror, ContraForce checks that the **counterpart detection module is connected and enabled** on the workspace. | Workspace modules | Behaviour | | :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------ | | Defender XDR **and** Sentinel | Deduplication applies in both directions. | | Defender XDR only | Nothing is discarded. A Sentinel-origin incident is the only copy ContraForce will ever fetch, so it is kept and attributed to Defender. | | Sentinel only | Nothing is discarded. A forwarded Defender incident is the only copy ContraForce will ever fetch, so it is kept and attributed to Sentinel. | | Neither | Not applicable. | Disabling one of the two detection modules changes deduplication behaviour immediately. A workspace that was discarding mirrors will start keeping them, because the counterpart is no longer being read. Incident volume in the queue will rise accordingly. This is correct: it is better to show a duplicate than to hide the only copy. ## Downstream effects The decision is made **once, at ingestion**, before any other processing occurs. A discarded mirror never becomes an incident in ContraForce, so it creates no state anywhere downstream. | Area | Effect on a discarded mirror | | :----------------------- | :--------------------------------------------------------------------------------------------------------------------------------------- | | Incident queue | Never appears. Only the surviving copy is listed. | | Email notifications | None sent. Recipients receive one notification per real-world incident. | | Agent runs | Not triggered. An agent runs once, against the surviving incident. | | Gamebook auto-run | Not triggered. | | Webhooks | No event is delivered. Subscribers receive one event per real-world incident. | | Real-time portal updates | Not pushed. | | Audit trail | No **Incident Detected** entry is written. | | SLA tracking | No timer is started and no SLA state is created. | | Metrics and dashboards | Not counted. Incident counts, classification breakdowns, and closure statistics reflect real-world incidents rather than vendor records. | If your incident counts fell when this behaviour was introduced, that is the duplication being removed. The count now reflects distinct real-world incidents. Historical aggregates computed before the change still include the duplicates and are not retroactively corrected. ### Direct links still work Deduplication is applied when **listing** incidents, not when fetching one. A direct link to a mirrored incident still opens and displays it. This is intentional: a link shared in a ticket, an email, or a chat message continues to resolve rather than returning "not found". ## What this replaced Earlier versions of ContraForce offered a per-workspace toggle to suppress an entire source. That approach was withdrawn because it cannot be made correct: * A workspace commonly forwards in both directions, so there is no single source that is safely redundant. * Suppressing Microsoft Sentinel discards incidents that never reach Defender at all, including any created manually, through the API, by a playbook, or in a secondary workspace. The toggle no longer exists and no action is required. Any previously configured value is ignored. ## Troubleshooting Confirm both detection modules are connected and enabled on the workspace. With only one connected, ContraForce keeps every incident by design. If both are connected, check the `providerName` on the Sentinel incident. A value other than the three listed above is not recognised as a mirror and the incident is kept deliberately, so that an unfamiliar label never causes data loss. Attribution follows origin, not arrival. An incident created by a Sentinel analytic rule is attributed to Sentinel even when it also appears in the Defender portal, and an incident created by Defender is attributed to Defender even when it also appears in your Sentinel workspace. Deduplication never removes the last copy, so a missing incident is unlikely to be caused by it. Check the time filter first: the incident list filters on incident **creation** time, while the Microsoft Defender portal displays last activity time. An older incident with recent activity appears recent in Defender and falls outside a short creation-time window in ContraForce. # Onboarding Workspaces Source: https://docs.contraforce.com/onboarding-customer-workspaces Overview of the ContraForce onboarding flow: how a service provider gets set up, then how a customer admin completes their workspace. ContraForce onboarding is split into two parts. Pick the guide that matches your role. Grant Microsoft access, set up your Agent Center, connect your own security tools, and pre-onboard customer workspaces. Your service provider has pre-onboarded your workspace. Click the invite link, grant consent, and consent each module on the **Modules** tab. ## Before You Begin ### What both sides need | Requirement | Who needs it | | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | **Microsoft Entra Global Administrator** | First sign-in from each tenant requires an admin to grant ContraForce consent (one-time) | | **Pop-ups allowed for `portal.contraforce.com`** | Microsoft consent prompts open in popup windows | | **Active Microsoft 365 license** with Defender capabilities (Business Premium, E3, or E5) | Customer side, for Defender-based detection and response | ### What service providers also need | Requirement | Why | | --------------------------------------------- | ---------------------------------------------------------- | | **ContraForce sign-up link** | Provided by your account team to start your own onboarding | | **Customer's Microsoft Entra tenant ID** | Required to pre-onboard a workspace for them | | **Customer's primary point-of-contact email** | Receives the invite that starts the customer's onboarding | ### What customers also need | Requirement | Why | | ------------------------------------------- | ------------------------------------------------------------------------------- | | **Invite email from your service provider** | The link in this email is your onboarding entry point | | **Azure Subscription Owner** | Only required if Microsoft Sentinel is among the pre-selected detection modules | *** ## How the Two Parts Connect ```mermaid theme={null} sequenceDiagram participant MSP as Service Provider participant CF as ContraForce participant Customer as Customer Admin MSP->>CF: Sign up via portal.contraforce.com link MSP->>CF: Grant Microsoft consent (Global Admin) MSP->>CF: Set up Agent Center, connect own sources MSP->>CF: Add customer workspace with pre-selected modules CF->>Customer: Invite email Customer->>CF: Click invite link, grant Microsoft consent Customer->>CF: Consent each module on the Modules tab CF->>MSP: Real-time notification: customer workspace is live ``` *** ## Module Reference The detection and response modules your customer ends up using depend on what your service provider pre-selects when adding the workspace from the **Workspace Center → Onboarding** tab. Use this matrix to decide what to pre-select. | Capability | Defender for Endpoint | Sentinel | | ------------------------------- | :-------------------: | :------: | | Defender for Endpoint incidents | ✓ | ✓ | | Entity enrichment | ✓ | ✓ | | Gamebook response actions | ✓ | ✓ | | Multi-tenant management | ✓ | ✓ | | Sentinel incidents | – | ✓ | | Detection rules (CMS) | – | ✓ | | Email notifications | – | ✓ | | Log search | – | ✓ | | Azure Lighthouse | – | ✓ | Selecting Sentinel as a detection module triggers ContraForce to deploy the supporting Azure infrastructure in the customer's subscription automatically. The customer doesn't run a separate Azure deployment step. ### Per-module deep-dives What Sentinel adds and what gets deployed in the customer's Azure subscription Defender for Endpoint detection and response details CrowdStrike detection and response options SentinelOne detection and response Content Management System for Sentinel detection rules (Sentinel only) Email notifications for incidents (Sentinel only) *** ## Verifying a Successful Deployment There is no completion screen. A workspace is onboarded when its **status light turns green** on its card in the Workspace Center. Run these checks once the customer has consented their modules. ### Immediate verification * The customer's card moves from the **Onboarding** tab to the **Workspaces** tab in your Workspace Center * The card's status light goes **blue** (pre-onboarded) to **green** (live). An **amber** light means a module or agent is still missing * You received the real-time notification that the customer's workspace is live * Incidents start appearing on the Command Dashboard within 5 to 15 minutes ### If incidents don't appear * Check the source system (Defender, Sentinel, CrowdStrike) for active incidents. ContraForce syncs existing incidents, so if there are none in the source, none will appear in ContraForce * Verify each pre-selected module shows as consented on the customer's **Modules** tab * For Sentinel customers, allow a few extra minutes after module consent for the Azure infrastructure to finish deploying *** ## Common Issues | Issue | Likely cause | Solution | | ------------------------------------------------------ | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Consent popup doesn't appear | Pop-up blocker | Allow pop-ups for `portal.contraforce.com` | | Consent fails with permissions error | Non-admin user | Forward the admin consent link to a Global Admin | | **Sign In Failed** page | Consent skipped or stuck session | See troubleshooting in [Part 1](/guides/onboarding/platform-onboarding#troubleshooting-sign-in-failed) or [Part 2](/guides/onboarding/customer-workspace-onboarding#troubleshooting-sign-in-failed) | | No incidents appearing | No active incidents in source | Check Defender/Sentinel/CrowdStrike console | | Customer card stays **blue** on the **Onboarding** tab | Customer hasn't consented their modules yet | Resend the invite or contact the POC | *** ## Next Steps After Onboarding Learn how to triage and respond to incidents Automated response workflows Monitor security posture across workspaces Manage multiple customers efficiently *** Questions about onboarding? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Overview Source: https://docs.contraforce.com/overview Welcome to the ContraForce documentation. Learn how to streamline your security delivery with AI-powered triage, investigation, and response. ## Getting Started with ContraForce Get your security delivery platform up and running in minutes. Follow our onboarding guide to connect your first workspace. ## Core Platform Features Master the tools that power your security delivery. Your central hub for monitoring incidents across all tenants in a single dashboard. Learn the workflow for triaging, investigating, and responding. Create custom response workflows with AI-mapped responses and SOPs. Automate incident response with pre-built and custom response actions. ## Multi-Tenant Management Designed for MSSPs and service providers managing multiple customers. View and manage incidents across all customer tenants from one interface. Pre-onboard customers and manage workspace configurations. Manage your Microsoft Sentinel detection content across every tenant. Pre-onboard customers and manage workspace configurations. ## Connect Your Modules Deploy with Microsoft security products and ContraForce modules. Connect your Microsoft Sentinel for incident management and more. Connect Defender for Endpoint, Defender for Endpoint, and Entra ID. Deploy and configure your Content Management System. Connect your notifications module for Microsoft Sentinel ## Understanding the Basics Key concepts for getting the most out of ContraForce. Understand roles including organization-level and workspace-level permissions. Understand roles, and permissions across your workspaces. ## Need help? Reach our support team at [support@contraforce.com](mailto:support@contraforce.com) for assistance. Stay updated with the latest features, fixes, and improvements. # ContraForce Release Notes Source: https://docs.contraforce.com/release-notes ### Improvements * Incidents that Microsoft syncs between Defender XDR and Sentinel now appear once instead of twice. Deduplication applies to workspaces with both detection modules connected, and produces one inbox entry, one notification, one webhook, one agent run and one SLA timer per real incident. The Defender and Sentinel forwarding toggles have been removed, and any previously configured value is ignored. See [Parallel incident deduplication](https://docs.contraforce.com/guides/technical/parallel-incident-deduplication#the-three-forwarding-scenarios) for how each forwarding scenario is resolved. * Ticketing configuration has moved from Settings to Workspace Center, alongside Workspaces, Onboarding and SLA. Existing Settings links redirect automatically. ### Bug Fixes * A failed content rule deploy now records why it failed, so the reason can be reviewed in the audit trail instead of disappearing with the on-screen message. * Importing rules from a Sentinel workspace in your own tenant now reports a clear permission error naming the Azure access required, instead of a generic "contact support" failure. * ContraForce administrators can now view and edit a workspace's module configuration through OmniView. ### Bug Fixes * **Connecting Microsoft Sentinel now works with least-privilege roles** - Contributor combined with either User Access Administrator or Role Based Access Control Administrator is accepted, alongside Owner and any custom role carrying the same permissions. Previously some correctly configured accounts were refused. * **Permission messages name the exact permission you are missing** - when a connection cannot proceed, the message lists the specific Azure permissions required and where to grant them, instead of naming only a role. That means you can grant precisely what is needed rather than over-granting. * **A failed check is no longer reported as a missing permission** - if the permission check itself cannot complete, because of a network problem or a temporary Azure issue, ContraForce now says so plainly instead of suggesting your access is misconfigured. ### New Features * **Organization Settings now has an Audit tab** - see who changed what across your organization in one place. It covers users added, removed, updated, and synced, group changes, organizational role and gamebook permission changes, organization and notification settings, and ticketing integration setup. Your existing webhook and API client activity now appears here too, so the whole organization reads as one trail. * **Every entry names the time, the person, and the target** - each record shows when it happened, who did it and their email, a plain-language description of the activity, and the resource that changed. Narrow the view to a date range when you are looking into a specific window. ### Bug Fixes * **Incidents closed in your security tools are now reflected in ContraForce** - when an analyst closes an incident directly in Defender, Sentinel, CrowdStrike or SentinelOne, ContraForce now detects the closure, including when an incident is later reopened upstream or its classification is corrected. * **Connecting Microsoft Sentinel tells you immediately when access cannot be granted** - the connection previously reported success and left a workspace that was never wired up in Azure. It now stops at the point of failure and names the resource group and the role that are missing, so you know exactly what to ask for. * **Gamebook history offers a retry instead of failing quietly** - a brief interruption while loading gamebook history now shows a clear error with a retry, rather than an empty view. ### New Features * **ContraForce is available as a Microsoft Sentinel solution** - the platform is now packaged for distribution through Microsoft Sentinel Content Hub. ### Improvements * **Temporary storage interruptions are reported clearly** - transient faults now surface as a retryable error rather than a generic failure. ### Bug Fixes * **Administrators can finish setup with any role that can approve ContraForce** - completing an invitation previously required a Global Administrator or Privileged Role Administrator. Every role Microsoft Entra allows to grant that approval can now complete setup. * **A missing organization approval is no longer reported as the wrong problem** - when an organization had not yet approved ContraForce, the setup page said the signed-in user's role was insufficient. It now explains that approval is needed and offers to grant it in one click. * **Module permissions are checked before you are sent to Microsoft** - the setup wizard now tells you up front when your role cannot approve a module's permissions, instead of sending you to Microsoft only to be refused and returned with an error. * **Connecting Microsoft Sentinel checks the right level of ownership** - owning a single resource group appeared to satisfy the subscription ownership requirement, allowing a connection that then failed without explanation. The check now looks at the subscription itself. * **Setup no longer reports success when nothing is connected** - the final step said ContraForce would start delivering security even when no detection source was ready to send data. It now says what is still outstanding. ### Improvements * **Manual investigations no longer pile up on a busy agent** - an agent now takes at most three analyst-triggered investigations at a time. Trigger another while three are running and ContraForce tells you the agent is busy investigating other incidents so you can retry in a moment, instead of accepting work that slows down the investigations already under way. ### Bug Fixes * **Long-running agent investigations are no longer shown as failed** - when an agent's investigation ran longer than the connection timeout, the run could be marked failed with a raw network error even though the agent was still working, and its result was then discarded. Run status now reflects what the agent actually did, and a result that arrives late corrects the record. * **Changing one incident severity no longer resets your other notification settings** - toggling a severity switch on a workspace's Notifications tab discarded that account's agent run preferences and recipients, cost alert budget and thresholds, and spend approval settings. Every other setting is now preserved. * **Content Management Center loads reliably in all regions** - the UK South portal returned "Operation failed" on every Content Management Center load. It now opens normally. ### Security * **Indicators in incident notification emails are no longer clickable** - URLs, domains, and IP addresses in incident emails are now shown in a defanged form, so your email client cannot turn a potentially malicious indicator into a live link. The View Incident button and recommended playbook links still work, and indicators inside the portal are unchanged. ### Improvements * **Agents pick up the next queued incident sooner** - an agent now frees up for the next queued incident after a 10-minute window, separate from the longer window used to decide a run never reported back. Queued incidents move through faster during busy periods. * **A more consistent interface** - the command palette, What's New panel, cookie consent notice, and page layouts have been rebuilt on the current design system. ### New Features * **Ready-made detections for ContraForce activity in Sentinel** - the ContraForce data connector now ships with analytic rules covering privileged access changes, destructive workspace actions, and machine credential activity, so suspicious ContraForce administration surfaces as Sentinel incidents without you writing the queries. ### Improvements * **Agents no longer run twice on the same work** - an agent is now limited to one run at a time, with further triggers queued behind it rather than starting alongside. Runs are more predictable and no longer duplicate effort during busy periods. * **SLA settings now live in Workspace Center** - service level configuration has moved alongside the rest of your workspace settings. * **A quicker agent creation wizard** - new agents default to On Queue mode, workspace aliases are shown so you can tell similar workspaces apart, and the agent name is prefilled. * **Standard operating procedures are now called Operating Procedures** - page titles and breadcrumbs updated to match how teams refer to them. * **Detection content stays in step with your workspaces** - reconciliation now detects and reports drift between the content ContraForce manages and what is actually deployed in your Sentinel workspaces, with clearer authoring and sync visibility. ### Bug Fixes * **Agents pick up every incident during a burst** - when several incidents arrived at once, an automatically triggered agent could miss some. All incidents in a burst are now processed. * **Completed agent runs are no longer left marked as failed** - if the connection dropped at the moment a run reported completion, it could stay marked failed and go unbilled despite finishing its work. Completion is now recorded reliably. ### New Features * **Stream ContraForce activity into Microsoft Sentinel** - a ContraForce data connector is now available for Microsoft Sentinel. Once connected, workspace audit activity flows into a dedicated table in your Sentinel workspace, so ContraForce actions sit alongside the rest of your security telemetry for hunting, correlation, and retention. Each connection is scoped to a single workspace. ### Improvements * **Consistent dialogs across the interface** - opening an incident from a link in an email, a Teams card, or a webhook now shows the same incident view as clicking the row in the incidents table. Gamebook and module setup dialogs have been rebuilt to match the rest of the interface. * **Redesigned sign-in landing screens** - the sign-in failure and admin consent screens now match the rest of the product. ### Bug Fixes * **The Environments tab no longer flashes an error before it loads** - opening the tab briefly showed a red "Environment unavailable" message before the content appeared. It now shows a loading indicator, and recovers on its own from momentary connection problems instead of reporting a failure. * **Administrators can open the Environments tab** - administrators who could open every other tab on a workspace were refused access to Environments. They can now read it, in line with every other tab on that page. * **Granting directory access no longer re-approves every ContraForce permission** - the consent prompt for user and license visibility asked an administrator to re-approve ContraForce's entire permission set. It now runs through the Microsoft Defender XDR connection, so only that module's permissions are involved. ### New Features * **See your workspace's licensing and endpoint coverage** - a new Environment tab in workspace settings shows the security licenses in your tenant and how many seats are assigned, which users hold them, and which endpoints are onboarded to Defender versus still available to onboard. A capability matrix shows which response actions your current licensing supports, and anything that cannot be read is shown as unknown rather than reported as unavailable. Each card refreshes on demand and shows when it was last checked. ### Improvements * **Investigation panels rebuilt on the new interface** - entity insight and investigation panels have been rebuilt, with a redesigned process tree, an actionable related incidents view, and reworked sign-in and audit log inspectors. * **Agent model upgrades keep your throughput capacity** - upgrading an agent's model now carries over the throughput capacity your current deployment is tuned to, instead of resetting it to a default. ### Bug Fixes * **Long-running investigations are no longer reported as failed** - an agent investigation that ran past the gateway timeout could be marked failed and send a failure notification even though it had finished successfully. Runs are now given time to report their real outcome first. * **Agent run history shows every run in the selected range** - the account view showed only a fraction of the runs performed, and did not change when the time range was widened. Counts and breakdowns now cover the entire selected range. ### Bug Fixes * **Assign an owner to SentinelOne incidents** - the owner control is no longer greyed out on SentinelOne incidents, so you can take ownership, hand work off, and see who is handling what. Ownership is tracked inside ContraForce and is not written back to SentinelOne, which has no owner field of its own. * **Incident owners now show in the all-workspaces view** - for service providers, an owner assigned from inside a customer workspace previously appeared on the incident itself but left the owner column blank in the all-workspaces incident list. SentinelOne and CrowdStrike incidents now show the assigned owner in both places. ### New Features * **V2 is now the default experience** - every user now gets the modern ContraForce interface automatically. The classic view and the option to switch back to it have been removed. ### Bug Fixes * **Improved incident detail layout on smaller screens** - the Audit and Entities tables on the incident detail page no longer overflow or clip columns on narrower or laptop-width screens, and the layout gives the investigation panel more room instead of squeezing it against a fixed-width response panel. ### New Features * **Agent status policy controls** - choose No Change in the Status after run dropdown so an agent preserves the incident status unless a transition is deliberately configured. ### Bug Fixes * **SLA-aware status options** - SLA pause states are available only when SLA Management is enabled and the assigned workspace has an SLA configuration, preventing invalid or misleading agent policies. ### New Features * **Multi-select and bulk actions in the incidents table** - select multiple incidents at once and close or reassign them in a single step. Bulk close applies the classification and reason you choose to every incident, correctly mapped for each detection source, even when your selection spans multiple workspaces and sources. Any incidents you do not have permission to change are listed by workspace so nothing fails silently. ### Bug Fixes * Self-hosted ServiceNow customers can now enter their actual instance URL when configuring ticketing, instead of being limited to the standard hosted-instance name format. This restores incident sync and ticket creation for self-hosted ServiceNow deployments. * Fixed the Detected Products card so Business Premium, Defender for Business, and other SMB-tier license SKUs are correctly recognized and displayed, instead of being hidden or shown as raw IDs and causing automation coverage to be misreported as "Not licensed." ### New Features * **Bring-your-own credential for Sentinel incident ingestion** - connect Microsoft Sentinel to ContraForce using a credential you provision and control, scoped to incident ingestion only. The portal shows a one-time deployment card with the ingestion URL, client ID, and secret, and you can rotate or revoke the credential from the portal at any time. A leaked credential cannot be used to inject incidents into any other workspace. ### Improvements * **Dedicated Gamebooks settings tab** - gamebook configuration now has its own tab in workspace settings, with approver management and run-permission controls as a first-class area instead of being at the bottom of the General tab. The tab is deep-linkable and available to workspace owners. * **SOP Knowledge Base workflow overhaul** - linking agents to an SOP is now a single search, select, and confirm pass with a full checkbox list, and already-linked agents are shown so they cannot be double-linked. Markdown SOPs can be edited and saved in place with a reviewable diff and a revert option before saving, and the preview dialog was redesigned with a comfortable reading width, document identity (name, version, and size), and an always-visible Close button. ### New Features * **Content deployment to workspaces** - deploy analytic rules from a content repository to one, several, or all of your Microsoft Sentinel workspaces. Each target is checked before you deploy, results are reported per workspace, and a single rule can be rolled back in one workspace without affecting the others. ### Bug Fixes * Fixed an issue where the incidents list could appear empty. If one incident carried a field value the portal did not recognize, the remaining incidents on that page stopped loading. Widening the date range or including closed incidents made it more likely to happen. ### New Features * **Cost Management Center** - a single place in the portal to track and manage agent spend, workspace licenses, and billing across all your workspaces. ### New Features * When creating a Security Delivery Agent in your own cloud, you can now choose the AI model and deployment type (Global Standard or Data Zone Standard) right in the creation wizard, with plain-language guidance on where data is processed. Only models available in your Agent Center's region are offered, and Azure quota is verified before you continue — so a deployment can no longer fail at the last step because of missing capacity. ### Improvements * Upgrading an agent to the newest GPT-5.5 / GPT-5.6 models is now allowed only once the agent runtime supports them, preventing failed incident investigations from premature upgrades. * New Agent Centers use serverless infrastructure for their database, billing only for actual usage. ### Defender Automation Awareness * The Security Delivery Agent now recognizes what Microsoft Defender's own automation (automated investigation, attack disruption, and incident merging) has already handled. Incidents Defender resolved or merged are skipped before the agent spends any compute, and every skip is recorded in the activity log - eliminating duplicate work and reopened tickets. New Native Automations and Detected Products sections on the Defender XDR configuration tab show which automations are actually firing and which Defender products are licensed and emitting signal, with an on-demand Run detection action. ### Agent Notifications * Workspace teams can now opt in to email alerts when an autonomous agent run fails to submit a gamebook, so failed response actions no longer go unnoticed in an incident comment. The new toggle lives under workspace Notifications -> Agent Runs, reuses the existing agent-run recipient list, and is off by default. ### Defender Response Actions * Response actions on Microsoft Defender incidents (such as invalidating a user's sessions) now run reliably on the first attempt. Previously they could fail intermittently and only succeed after several retries, depending on which server handled the request. ### SOP Template Library * Service providers can now browse a curated library of pre-built Classification and Response playbook templates covering common incident scenarios, and promote the ones that match their environment straight into their active SOP library instead of authoring from scratch. Every template is validated so the agent's classification verdicts are reproducible and its response steps are complete and technically correct, giving new and existing service providers reliable, agent-ready triage and response coverage from day one. ### Workspace Management * Organization admins and workspace admins can once again manage who has access to a workspace (adding, editing, and removing users and groups), regardless of whether they personally hold the workspace Owner role. This restores access that was inadvertently narrowed to Owner-only in the redesigned workspace management screen. ### Bug Fixes * Workspace Owners can now manage incident notification settings even when the Sentinel module is not fully configured. Previously the Notifications page showed a "Configuration unavailable" warning and blocked incident severity preferences and recipients until Sentinel setup was finished, even though incident notifications are not exclusive to Sentinel. ### Bug Fixes * Closing a Microsoft Defender XDR incident as False Positive with the reason "Not Malicious" now saves correctly. Previously this specific reason could fail with "Request body is incorrect" and the incident stayed open. ### Bug Fixes * Manually triggered agent investigations now show the agent's tool-by-tool activity live in the portal, the same as automatic on-queue runs. Previously a manual run showed no real-time progress, leaving analysts unsure whether the agent was working. ### Bug Fixes * Agent users are now protected in Workspace IAM and User Management. Previously an admin could change an agent's role or remove it, which silently stopped the workspace's AI agent from responding. Agent accounts are now clearly marked and locked from edits. ### Bug Fixes * Closing a Microsoft Defender XDR incident with a benign or true-positive classification reason (such as "Confirmed User Activity", "Compromised User", or "Not Malicious") now succeeds. Previously these closes failed with "Request body is incorrect" and the incident stayed open. ### Improvements * Service providers can now turn off the agent metadata header on incident comments the Security Delivery Agent posts to Microsoft Sentinel and Defender. With it off, the comment shows only the agent's written summary, for a cleaner read in the native security console. ### Bug Fixes * When adding a customer workspace, the detection and response module names now display in full instead of being cut off mid-name. ### Improvements * Analytic rule updates now deploy more reliably to Workspaces with auto-update enabled, and the rule version shown in the portal always matches what is running in Microsoft Sentinel. ### Bug Fixes * Mailbox entities in the incident investigation graph no longer offer user account containment actions (lockout, password reset, MFA reset, session invalidation). User containment remains available on the related user account entities, and mailbox entities without an applicable response action now show "No options available" instead of a misleading error message. ### Bug Fixes * The Security Delivery Agent no longer assigns itself to Microsoft Defender XDR incidents when its assign-self setting is turned off. Incidents the agent investigates keep their existing owner — or stay unassigned — unless the agent is explicitly configured to take ownership. Analysts updating an unassigned incident's status still become its owner, as before. * Manually triggering an agent investigation is now offered only to users whose role can complete it (Owner and Incident Responder), so runs no longer start and then fail partway with "Failed to submit the investigation result." ### New Features * Connect SentinelOne FedRAMP GovCloud (`s1gov.net`) consoles, with a dedicated static egress IP you can add to your allowlist. ### Security * Ongoing security and reliability hardening across the platform, resolving findings from continuous code analysis. No change to day-to-day behavior. ### Bug Fixes * Automatic agent investigations that finished after a brief connection timeout are no longer shown as failed. When the agent completes the investigation and reports back, the run is now correctly recorded as completed with its usage. ### Features * **Failed agent run notifications** — Configure recipients per workspace to be emailed whenever an agent run fails, with the agent, run, and workspace context needed to act. Recipients are independent from Incident and Gamebook notifications. ### Improvements * Incident detail now fills the full height of large screens, removing the empty space that used to sit below the cards. * The Add Users picker shows each person's name and email, so people with the same name are easy to tell apart. * Dropdown pickers now reveal their options as soon as you focus them, instead of appearing empty until you start typing. * Corrected the "API Token" label casing on the ticketing details view. ### Bug Fixes * Automatic agents now process every incident during a burst. When many incidents arrive for the same customer at once, runs are queued and worked through one at a time per customer, so none are silently skipped. * Microsoft Defender XDR incidents are no longer skipped when a newly created incident has a lower internal id than one already processed. Incidents are now tracked by when they were created, so anything visible in the Defender portal is reliably ingested. ### Bug Fixes * Fixed a sign-in issue that could trap the portal in a loop on Firefox; signing in now works reliably across Firefox, Chrome, and Edge. * Fixed an issue where Microsoft Defender XDR incidents created during a brief polling interruption could be missed; incidents are now reliably re-scanned and ingested once polling recovers. ### Performance * Opening an incident is now dramatically faster. Incidents with many alerts that previously took 30 or more seconds to load now return in a few seconds, in the portal and through the API. Evidence loads on demand when you open the Evidence tab. ### Bug Fixes * Resolved an issue where some administrator accounts could be incorrectly denied access. * The incident comments API now correctly identifies an incident's closing comment. ### Bug Fixes * Turning on automated password resets for end-customer users is now reliable: after granting Microsoft consent the setting enables itself instead of needing a second click, and tenants that need an additional consent are guided through it instead of getting stuck. ### Bug Fix * Bulk **Delete Email** remediation now handles messages that share a reference correctly. Plan rows without a specific entity no longer collide, so every targeted email is actioned. ### Feature * Deployed security detection rules now stay up to date automatically as new versions are published, across all ContraForce regions. ### Bug Fix * Web Application Firewall analytic rules now deploy correctly; a rule name-matching issue had previously prevented them from being applied. ### Feature * New **Reset MFA** response action: responders can clear a user's registered multi-factor authentication methods from a Gamebook so the user must re-enroll MFA at next sign-in — available in the portal and to the Security Delivery Agent, with no extra admin consent. ### Bug Fix * Approving a queued Gamebook now runs it. Previously the approval appeared to do nothing and the Approve button kept returning; approved response plans now dispatch and show a running state. ### Bug Fix * Log Search now runs KQL queries reliably again across Microsoft Sentinel and Microsoft Defender XDR workspaces; queries had begun returning an error instead of results. ### Feature * New plans, pricing, and a Billing & Plan management screen: plan tiers now carry entitlements, XDR Only vs. XDR + SIEM is gated by tier, extra workspaces are billed automatically, and investigations are metered with trial limits enforced. * Service providers can now run automated password resets for end-customer users directly when the capability is enabled. * Incident classifications are now consistent across detection modules, with a new Classification Trends widget showing how classifications break down over time. * Admins can view and edit an account's Trial End Date when changing its subscription status from the modernized Admin Center. * ContraForce is now available on a UK-resident platform stack, with tooling to migrate existing customers from US to UK. ### Bug Fix * The Quarantine File gamebook now runs successfully (it previously failed with an invalid-hash error). * Customers onboarded to Sentinel without the ContraForce Apollo deployment now reliably receive their incidents. ### New Features * You can now send an incident notification email to the end customer on demand from the incident's Actions menu — pick recipients (with quick-select from saved workspace contacts), then either send the "View Incident" email or send and escalate the incident to Waiting on Customer. Every manual send is recorded in the incident's audit trail. * A new "Trigger webhook" action on the incident detail page lets you push the current incident to any of the workspace's enabled webhooks on demand. The delivery is signed, audited, and appears in the webhook's events log just like an automatic delivery, marked as manually triggered. * End-customer workspaces now have a read-only Agents tab showing which AI agent is assigned and its configuration, plus a Run History view with a time filter and links to related incidents. ### Bug Fixes * Incident and gamebook links in notification emails now open regardless of how old the incident is or which time filter you have selected — deep links from emails, webhooks, and ITSM tools no longer fail with "couldn't load incident." Gamebook notification email subjects now also show the workspace, source, severity, and incident title at a glance. ### Bug Fixes * Incident closure metrics now keep the classification reason, so the "By reason" breakdown in Command Center is accurate. You can also now see incidents your service provider closed on your behalf in your own workspace's Command Center. ### Improvements * You can now click a matched SOP chip in an AI agent's investigation activity to open and read the full standard operating procedure that guided the agent's classification. * The Ticketing integration details page has a refreshed look and feel consistent with the latest ContraForce experience. ### Bug Fixes * Pre-onboarded workspaces now activate automatically once the customer connects their selected security modules and grants admin consent. * Service providers can mark a pre-onboarded workspace as onboarded directly from the Onboarding tab. * The User Management settings tab now prompts to connect tenant directory access when it's missing. ### Improvement * Improved the reliability of Microsoft Sentinel incident detection — incidents keep flowing into ContraForce even when the underlying infrastructure isn't reliably deployed or available, thanks to an automatic fallback ingestion path. ### Bug Fix * Fixed the Incidents page filter chips overflowing past the right edge of the table card on wider desktop screens; they now wrap and stay contained within the panel. ### Improvement * Redesigned the Log Search results experience: a readable, resizable, searchable grid where you can expand any record to see full detail, with reliable workspace switching and a Stop button that truly cancels a running query. ### Bug Fix * Fixed a Security Analytics issue where a rule could appear multiple times and Deploy/Undeploy didn't always reflect the correct state. ### New Features * Get notified the moment a gamebook runs in a workspace, whether an analyst or the AI Agent started it. A new Gamebooks tab in workspace notification settings lets you toggle "Gamebook ran" and "Gamebook queued" events and maintain a dedicated recipient list, separate from incident notification recipients and gamebook approvers. * New `gamebook.run.v1` webhook event: subscribe a webhook to receive a signed delivery whenever a gamebook runs, ideal for automatically opening tickets in your ITSM. * The workspace Notifications page is now organized into Incidents and Gamebooks tabs. ### Bug Fix * Log Search and Advanced Hunting now always run against the workspace you've selected — partner users querying a managed customer's Microsoft Defender no longer see intermittent consent errors, and results stay scoped to the chosen workspace. ### New Features * **One classification language across every detection module.** Closing an incident now uses four clear verdicts (True Positive, False Positive, Benign Positive, Undetermined) with a curated reason list per verdict, consistent across Microsoft Sentinel, Microsoft Defender, SentinelOne, and CrowdStrike. The verdict you pick is preserved exactly in ContraForce, even when the connected security tool cannot store it. * **Classification Trends in Command Center.** A new widget breaks down closed incidents by verdict, reason, and detection module. Click any verdict to jump straight to the matching incidents in the inbox. * **Filter the inbox by classification and reason.** New filters, columns, and shareable links let you slice closed incidents by how they were classified. * **Closures made in your security tools now flow into ContraForce.** When an incident is closed directly in the vendor console, ContraForce records the closure with its classification, adds an audit entry, and counts it in your closure metrics. * **New `incident.closed.v1` webhook.** Subscribed integrations are notified whenever an incident closes, including the classification, reason, and whether an analyst or an upstream tool closed it. ### Bug Fixes * **Agent Center: Models & Quotas now shows only self-hosted agents.** ContraForce-hosted (Our Cloud) agents no longer appear in configuration that only applies to your own cloud. * **Agent Center: usage chart is readable in light theme.** Axis labels no longer render invisible against a light background. * **Agent Center: run cost is no longer shown for ContraForce-hosted agents.** Cost figures appear only for agents running in your own cloud, where they reflect your actual spend. * **Agent model upgrades reliably switch the running agent to the new model.** Updating an agent's model from Models & Quotas now re-points the agent's runtime at the newly provisioned model deployment and notifies you when the upgrade completes, with success and failure counts per agent. ### New Features * **Restart a failed Agent Center deployment.** When an Agent Center deployment fails, you can now delete it and start fresh with different settings (region, resource group, or subscription) instead of only retrying the same configuration. We also remind you to remove the old Azure resource group so it doesn't sit idle. ### Bug Fixes * **Agent updates now tell you whether they actually finished.** You get a clear success or failure notification when a background agent update completes — with actionable detail (like a permissions issue) on failure — instead of only a "started" message. * **Cleaner agent investigation comments on forwarded incidents.** Agent investigation comments on Microsoft Defender incidents forwarded to Sentinel now appear as a single, clean activity card instead of broken fragments. * **More reliable Sentinel onboarding.** Onboarding now verifies subscription-owner access before deploying, preventing customers from being onboarded without the required ContraForce infrastructure. ### Bug Fixes * **SLA chip no longer sticks on "At Risk" once the target is met.** When an incident's time-to-first-response (or resolution) crossed into At Risk but was then handled in time, the SLA chip kept showing "At Risk"; it now flips to On Track once met. Only a genuine breach stays red. * **Re-onboarding a previously-removed workspace now works cleanly.** Removing a pre-onboarded customer workspace could leave the customer's account record pointing at the deleted workspace, stranding them with no access on the next sign-in. Removing a workspace now cleans up those records, so re-onboarding the same customer provisions them correctly. ### Improvements * **SLA state changes are now recorded in the incident audit trail.** Every SLA tier change (At Risk, Breached, or Met) for both the response and resolution clocks, plus SLA clock pause and resume, now appears as an entry in the incident's audit tab, so you can see exactly when and how an incident tracked against its SLA. ### Bug Fixes * Fixed an issue where a SentinelOne detection module could appear connected while silently failing to pull threats. Configuration problems are now surfaced immediately, and a module cannot be enabled until it is fully configured, closing a hidden detection-coverage gap. ### New Features * **See the SLA applied to a workspace.** Workspace settings now has a read-only SLA tab showing the response and resolution targets configured for that workspace, so customers and service providers can confirm what's in effect at a glance. The configuration name on an incident's SLA timeline links straight to it. ### Bug Fixes * **SLA now tracks on service-provider-managed workspaces.** When a service provider assigned an SLA configuration to a customer workspace, that workspace's incidents weren't picking it up. Assigned configurations now track correctly, and SLA chips no longer freeze in cross-workspace views. * **Delete Email gamebook runs again.** The delete-email response action was failing with "Unable to run the delete email gamebook" because the mail entity wasn't resolved to the identifier the mailbox provider expected. It now resolves the message and completes the action. * **Command palette shortcut works in the new UI.** Ctrl+K (Windows/Linux) and ⌘K (macOS) now open Quick actions in the V2 portal, and the shortcut hint shows the correct key for your OS. * **Consistent incident view from agent history.** Clicking an incident in an agent's Execution History now opens the V2 incident view, matching the rest of the portal. ### Security * **Hardened email lookups.** The delete-email path now guards its mailbox lookup against message-identifier injection. ### New Features * **Incident SLA tracking.** Configure per-workspace response and resolution targets for each severity. The incident inbox gains "Time to First Response" and "MTTR" columns showing a live countdown chip on every row — "SLA 12m left", "At Risk 5m left", "Breached 3m over", or "On Track" once settled. Chips tick down without re-loading and update in real time when any analyst changes status or assignment from any session. The incident detail header carries the same chip alongside a dedicated SLA tab with the configured targets and the running clock. Entering an On Hold or Waiting on Customer status (introduced 2026-05-27) freezes both the response and resolution clocks; resuming continues from where they left off. Available as an opt-in feature — contact your ContraForce contact to enable it on your tenant. ### New Features * **Security Delivery Agents now read the actual content of phishing emails.** Body, headers, embedded URLs, and attachment metadata are fetched automatically using your existing Microsoft 365 Response connection, so the agent can flag social-engineering patterns, sender spoofing, and suspicious links without an analyst opening the message. * **New "On Hold" and "Waiting on Customer" incident statuses.** Analysts can pause incidents that are blocked on a vendor RFI, a scheduled change window, or a pending customer reply, instead of leaving them as `Active`. The new statuses are ContraForce-native and don't write back to the upstream source. * **Vendor-side status changes now appear in the audit timeline.** When an incident is closed or reopened from the Azure portal (or another upstream tool), an attributed audit row is now recorded in ContraForce, so the CF view and the upstream view never silently disagree. * **Per-run agent token breakdown and dollar cost.** Every Security Delivery Agent run records its prompt / cached / completion token counts and the USD cost, visible on the per-agent execution history and the agent-center "Recent runs" strip. A row-level "Breakdown" link opens the detailed dialog. ### Improvements * **Agent token-usage telemetry.** Per-run baseline, per-tool-call sizes, and per-turn API usage are now captured so upcoming agent cost optimizations are measurable. ### Bug Fixes * **Stale Microsoft sessions now silently recover.** When a signed-in user's Microsoft session quietly went stale — token expiry, signing in elsewhere, or a Conditional Access change — the portal was dropping them on a "We couldn't load your session" error screen and forcing a manual retry. The portal now routes them through interactive re-authentication silently and returns them to where they were, keeping analysts in flow. * **MSP-managed agent configurations now save webhooks correctly.** When an MSP managing a customer workspace tried to save an Agent configuration that referenced a webhook on a classification card, the save was failing with "Failed to save agent configuration" and leaving the webhook orphaned. The save now succeeds and the webhook binding is persisted as expected. ### Improvements * **Dependency refresh for security and reliability.** Updated the third-party libraries the platform depends on to pick up the latest bug fixes, security patches, and performance improvements. No visible behavior changes — customers benefit from a more reliable platform with fewer known vulnerabilities. ### New Features **Onboarding affordances restored on the new portal.** The Command page now shows the setup prompt for admins who haven't completed onboarding, the invite-admin flow for non-admin teammates, and the dismissible getting-started checklist after setup. These existed on the classic experience and are now consistent across both. **"Connect tenant" recovery on the Agent Center.** Self-service customers who open the Agent Center before completing the broader ContraForce API consent now see the same recoverable "Connect tenant" banner that already appears on detection module configuration pages. After granting consent, the admin lands back on the originating page and continues — no support ticket required. ### Bug Fixes **Module configuration consent prompt fixes.** Two small timing bugs in the "Connect tenant" recovery flow on module configuration pages were addressed: the prompt now appears reliably on the very first visit (previously hidden in cases where the consent gap surfaced on the module fetch itself), and it no longer briefly re-appears immediately after a successful consent grant (the post-consent propagation wait was missing a second probe). ### Bug Fixes * **AI Query Assistant restored.** The natural-language KQL generator is working again. Analysts can ask for a query in plain English and get a usable KQL statement back, instead of the silent error the endpoint had been returning. * **Module configuration no longer crashes for un-consented tenants.** Self-service onboarded users who hadn't yet completed Entra admin consent for the ContraForce API were hitting a JSON-parse cascade on the Sentinel, Defender XDR, and Agent Center module configuration pages. The pages now detect the missing consent and surface an actionable "Connect tenant" prompt that walks the admin through the grant flow, so customers can self-unblock without contacting support. ### New Features **Advanced classification actions for Security Delivery Agents.** Agent Configuration cards now support an **Advanced** mode where each classification verdict (true positive, benign positive, false positive, etc.) can be assigned a custom action. Pair a classification with a webhook to receive a signed `agent.investigation.completed.v1` event at the moment the agent reaches that verdict — useful for escalating true-positive incidents into your SIEM, ticketing, or on-call tooling. See [Configuring Security Delivery Agents](/guides/getting-started/configuring-security-delivery-agents) and [Agent Investigation Completed Webhook](/guides/agent-center/agent-investigation-webhook). ### Improvements * Pagination tokens returned from `POST /api/v2/incidents/across-workspaces` are now opaque to API consumers. Partners continue to round-trip tokens unchanged from response to next request; only the internal token format has changed. A token that has been hand-modified or hand-built is rejected with `400 VALIDATION_ERROR` rather than failing further down the stack. See the worked example under [Cross-Workspace Endpoints](/api-reference/endpoints#paginating-incidentsacross-workspaces). ### New Features **The redesigned ContraForce Portal is now generally available.** Starting today, the new portal is the default experience for everyone. You will land on v2 the next time you sign in. v2 brings: * A refreshed visual language built around higher-density, more scannable information. * Reorganized navigation that surfaces the actions analysts actually reach for. * Reworked incident, gamebook, agent, SOP, log search, and command pages with consistent layouts and a unified design system. Prefer the classic experience? Open the user menu (top right) and pick **Switch to classic experience.** Your choice is remembered per browser, so you can move between the two while you get used to v2. ### Bug Fixes * Resolved an intermittent issue that could prevent the v2 incident agent from starting an investigation. ### Bug Fixes * `GET /workspaces/{workspaceId}/incidents/{source}/{incidentId}` now returns the full incident detail (alerts, entities, investigation details, evidence, and the gamebook catalog) by default. Previously the endpoint returned the same lightweight payload as the cross-workspace list, with the richer fields hidden behind an undocumented `?withDetails=true` query parameter. Partners integrating from Logic Apps, Power Automate, or any OpenAPI-driven client now get the documented response without needing to know the flag exists. * Cross-workspace incident requests that target a workspace where the requested incident source is not enabled (for example, asking for a Defender XDR incident on a workspace where only Sentinel is onboarded) now return a clear `404 NOT_FOUND` with a message naming the source, instead of an opaque `500` or `502`. The same applies when an incident does not exist in the workspace's underlying tenant — partners receive a `404` they can handle, not an upstream-error response. * The portal's incident detail page and gamebook workbench now display a friendly "Incident unavailable" banner with a working breadcrumb when a stale or deleted incident is opened from a saved link, instead of hanging on a loading skeleton. ### Improvements * The cross-workspace incidents list (`POST /incidents/across-workspaces`) now publishes its pagination protocol in the OpenAPI spec. The continuation-token mechanism (`isFirstCall`, `workspacePageTokens` on the request, `sourcePageTokens` and `moreIncidentsAvailable` on the response) is fully described so partners can build paging loops against a documented contract. ### Bug Fixes * The workspace selector in the top navigation now filters the Workspaces page, the Log Search page's workspace and module selector, and the Agent Center (including the Overview tab and the Recent Runs strip). Previously these pages ignored the selector and continued to show data from every workspace you have access to, which made it hard to focus on a subset of customers. ### Bug Fixes * Microsoft Sentinel and Microsoft Defender XDR module setup now accepts administrators whose subscription permissions come from inheritance (management group or tenant root), Entra group membership, or the Contributor and User Access Administrator combination. The form previously rejected these valid permission patterns with a "you must have Owner" message even when the user could fully administer the subscription. * Fixed a stuck-loading state on the module configuration screens when viewing a workspace owned by a tenant other than your active tenant. The Azure role prerequisite would spin indefinitely; it now resolves immediately so you can see why the module cannot be configured. ### Portal * Introduced an in-portal release notes side panel. When new releases ship, a release-notes indicator appears in the top navigation with an unread badge showing how many you have not yet seen. The panel is also reachable from the user-avatar dropdown so you can revisit the release history at any time. ### Bug Fixes * Resolved a character-encoding issue that prevented certain punctuation marks from displaying correctly in incident classifications. * Fixed an issue where Microsoft Defender XDR agent investigation comments could render as broken JSON when the comment payload was larger than Defender's per-comment character limit. Long agent investigation comments now stitch back together correctly in both the Microsoft Defender XDR portal and the ContraForce incident view. ### v2 API * Incident management is now available in the v2 API. Customers integrating ContraForce through the v2 OpenAPI specification can read and update incidents programmatically, alongside the existing v1 endpoints. ### SOP Knowledge Base * The SOP upload experience now accepts Microsoft Word (`.docx`) files. Uploaded Word documents are stored, indexed, and searchable alongside your existing PDF and Markdown SOPs, so you can publish SOPs straight from your Word library without converting them first. ### Agent Center * Added a new **Models & Quotas** panel that shows the AI models powering your Security Delivery Agents, including version, capacity, and live per-region usage with a progress bar — so you can see capacity headroom at a glance. * Restricted models now display a badge and a direct link to the access-request flow, making it clear which models require additional access and where to ask for it. * You can now upgrade a deployed agent to a newer model directly from the Agent Center without filing a ticket. The upgrade flow lists the models actually available in your environment, and upgraded agents start using the new model immediately. * Redesigned the **Resources** tab with grouped cards organized by resource role, plus a live health chip on each resource (Available, Degraded, Unavailable, or Unknown). When something goes wrong, you can identify the unhealthy resource without leaving the portal. ### Bug Fixes * Fixed an issue where Organization Admins could not create workspaces or Security Delivery Agents despite having the correct role assignment. * Fixed an issue where Microsoft Defender XDR incident comments displayed as fragmented "(N of M)" pieces instead of complete messages. ### Incident Management * Comments posted on Microsoft Defender and SentinelOne incidents now show the original author from the source platform, matching the experience already in place for Microsoft Sentinel incidents. ### Bug Fixes * Fixed an issue where bulk-closing incidents did not refresh the aggregate counts on the Command Dashboard. * Fixed an issue where bulk incident updates could silently fail mid-operation, leaving some incidents unchanged. ### Bug Fixes * Fixed a security issue where deleted user accounts could retain portal access until the next sign-in cycle. ### Portal * Users can now opt into the new UI experience individually from their profile, allowing teams to evaluate the new design at their own pace before broader rollout. * Let us know if you'd like to enable the new UI for your team or have any feedback on the design! ### Bug Fixes * Improved SentinelOne incident polling reliability and refined threat-handling behavior. ### Bug Fixes * Fixed an issue where analysts could lose visibility into an incident after Microsoft Defender merged it with another incident. ### OmniView * Introduced the **OmniView Metrics Dashboard**, surfacing customer health scores, operational and business metrics, and a flagged-accounts view in a single analytics dashboard. * The Account Overview page has been redesigned with a health-score summary, configured modules, and Security Delivery Agent activity metrics so service providers can assess each account at a glance. ### Bug Fixes * Fixed an issue where a user's organization role could revert to its original value after a User Management sync. * Fixed an issue where Microsoft Sentinel marketplace scanned sources failed to display when duplicate data source records existed with different casing. * Fixed an issue where analytic rule queries returned no results when data source ID casing did not match exactly. * Fixed an issue where Sync Users deactivated service accounts not matching identities in their directory. ### Incident Management * The Command Palette now supports searching incidents across all of your workspaces, so you can jump directly to an incident regardless of which workspace it belongs to. ### API Reference * Published an actively maintained OpenAPI specification for the v2 ContraForce API, making it easier to generate clients and integrate ContraForce with your own tooling. ### Agent Center * Agent creation now validates available GPT quota during setup, surfacing capacity issues before you finish configuring the agent. ### Bug Fixes * Fixed an "Agent not found" toast that appeared when OmniView admins loaded executions for a managed account's agent. ### Bug Fixes * Fixed an issue where EventCast webhook configurations were not delivered correctly for MSP tenants. ### Agent Center * The SOP Knowledge Base is now integrated directly into agent deployment — agents pick up relevant SOPs as part of the configuration flow, removing the need to attach them as a separate step. ### Agent Center * Starter SOP templates are available for new customers, providing ready-made examples that accelerate Security Delivery Agent onboarding. * Reach out to your ContraForce contact to get these SOPs for your organization and start customizing them for your team. * SOPs now persist with full backend support, ensuring uploaded procedures are durably stored and accessible to agents at runtime. ### REST API * Customer API Clients are now available. Create and manage API clients with scoped permissions and workspace-level access from a new portal experience that includes a creation wizard, a details page with scope and audit tabs, and a request-log viewer for monitoring usage. ### Workspace Management * The subscription picker for the Microsoft Sentinel module and Agent Center configuration now supports searching by subscription ID, making it easier to locate the right subscription in tenants with many subscriptions. ### Performance Improvements * Added additional health monitoring across all platform services for improved reliability and faster detection of service disruptions. ### Bug Fixes * Fixed an issue where Gamebook orchestration could stall on timer cancellation, leaving Gamebooks stuck in a Running state. ### User Profile * You can now set your preferred time zone in your user profile, and the platform will display all dates and times in your local zone. * Hovering over any date or time displays a tooltip showing the original UTC value, removing ambiguity when collaborating across time zones. ### Bug Fixes * Fixed an issue where the incident audit log could fail to render certain entries from the unified incident pipeline. ### Incident Management * When you close an incident with a comment, that comment now appears in the **Comments** tab in addition to the **Summary**, keeping the full conversation history in one place. ### Incident Management * Comments posted by Security Delivery Agents now display with a distinct visual treatment so analysts can quickly distinguish AI-generated comments from human analyst input. * Incident notification emails now include the source platform in the subject line, making it easier to filter and route alerts. ### Workspace Management * Added a read-only **Workspace Reader** workspace role that gives end customers and auditors view-only access to incidents and reports without permission to make changes. ### Agent Center * Security Delivery Agents now support a configurable **Should Assign Self** option that controls whether an agent automatically assigns itself as the incident owner during processing. ### Bug Fixes * Fixed an issue where the workspace name was missing from the **Role Assignment** view in User Management. * Improved reliability when removing role assignments so changes apply consistently on the first attempt. ### Log Search * Introduced an **AI Query Assistant** for Advanced Hunting Log Search. Describe what you're looking for in plain language and the assistant generates the corresponding query for you. ### Incident Management * Incident tables and dashboards now auto-refresh, so the data you see stays current without manually refreshing the page. ### Bug Fixes * Improved error handling for SentinelOne Gamebook actions so failures surface clearly instead of leaving Gamebooks in an ambiguous state. ### Agent Center * Introduced the **SOP Knowledge Base** — a centralized library of security operating procedures for your Security Delivery Agents. Upload SOPs via drag-and-drop with type selection and metadata, browse and filter them in a dedicated list view, and preview content in a slide-over detail panel. * Link SOPs to specific agents and update procedures over time with edit, re-upload, and cascade-delete actions. Each agent's details page now includes an SOP section showing its associated procedures. ### Workspace Management * Onboarding role validation now accepts Cloud Application Administrator and Application Administrator in addition to Global Administrator, supporting least-privilege Microsoft Entra ID deployments. ### Performance Improvements * Removed the cookie consent banner by switching analytics to session-only storage, simplifying first-load behavior for portal users. ### Agent Center * You can now review a complete history of every Security Delivery Agent execution from the **Execution History** tab on the Agent Details page. Each entry captures the timestamp, trigger source, incident, data source, severity, AI token usage, and outcome — providing full visibility for compliance and troubleshooting. * The portal now displays a notification when a Security Delivery Agent update is available, so you can update without checking manually. ### Workspace Management * Organization Admins can now permanently delete inactive accounts and all associated data, preventing stale accounts from consuming resources or cluttering the platform. ### Bug Fixes * Fixed an issue where the **Configure and Save** button on the agent configuration page was always enabled, even when no changes had been made or the user lacked the required permissions. ### Bug Fixes * Fixed an error that prevented non-partner users from loading the multi-workspace incident list. ### Agent Center * Security Delivery Agents can now automatically detect and respond to Microsoft Defender for Endpoint incidents without requiring Microsoft Sentinel forwarding. Once configured, ContraForce polls Defender for Endpoint for new incidents and triggers your agent automatically — enabling a fully autonomous response workflow for environments using Defender for Endpoint directly. ### Bug Fixes * Fixed an issue where users in tenants with 50 or more Microsoft Entra ID group memberships silently lost real-time incident updates and portal connectivity. ### Gamebook Improvements * Reviewers can now **Deny** a Gamebook queued for approval, removing it from the queue rather than leaving it pending indefinitely. ### Bug Fixes * Fixed a permissions issue where users with the Incident Analyst role could submit a Gamebook for approval, but it could execute instead of waiting for review. ### Bug Fixes * Fixed a layout issue where incident table filters appeared misaligned on screens under 1800px wide. * Fixed an issue where the **Link Ticket** dialog only showed Jira projects A–F (approximately 10 results) and search had no effect, preventing analysts from linking incidents to projects not in the initial list. * Fixed an issue where Security Delivery Agents failed to update incident status due to a validation error, causing automation rules to not apply correctly. * Fixed an issue where audit log entries for agent-triggered status changes and owner assignments recorded the incorrect account ID. ### CMS Updates * Improved detection rule reliability by fixing issues with multi-table rule deployment. * Improved several detection rules for better accuracy and fewer false positives. ### Workspace Management * You can now delete a pre-onboarded tenant that hasn't completed setup, simplifying workspace cleanup. * Workspace tags now display more relevant contextual information, replacing the outdated "Configuration (XDR + SIEM)" label. ### Gamebook Improvements * Added a **Workspace** column to the Gamebook Activity view, making it easier to identify which workspace each Gamebook execution belongs to. ### Bug Fixes * Fixed a crash on the incidents list when viewing multiple workspaces caused by a module configuration change. * Fixed "Last Modification" in Group Management displaying "0 days ago" instead of the actual date. ### Agent Center * Improved Security Delivery Agent reliability when investigating workspaces where certain Gamebook extensions are not enabled. ### Bug Fixes * Fixed an issue where Gamebooks could get stuck in a pending or running status. * Fixed visual rendering issues in several portal components. ### Incident Management * Added an **Assign to me** quick-action button to incident details and the incident modal, enabling analysts to claim incidents faster. * Incident IDs now appear consistently in the breadcrumb, URL, and page header for easier reference and sharing. * Consolidated workspace filtering — individual table workspace filters have been replaced by the global workspace filter at the top of the page for a cleaner, more consistent experience. ### Gamebook Improvements * The Gamebook approval button now displays an informative tooltip explaining why approval is unavailable when prerequisites haven't been met. ### Bug Fixes * Fixed an issue in the Agent Center where pressing Enter during agent creation would prematurely submit the form. * Fixed a data source usage query failure affecting Google Workspace Reports. ### Dock Panel Navigation * The dock panel now opens to the **Browse** tab by default when expanded, providing faster access to workspaces and navigation. * The **Recent** tab now correctly displays workspaces you've recently accessed, improving workspace discovery. * Added a visual indicator to the active dock panel tab, making it easier to see which tab is currently selected. ### Bug Fixes * Fixed an issue where the dock panel collapsed when navigating between workspaces. * Reduced unnecessary re-renders when interacting with dock panel tabs. ### Incident Details Redesign * The incident details experience has been redesigned with improved entity organization, clearer section navigation, and faster load times. * Entity lists in incident details now show enriched context directly in the list view. * Incident tabs have been reordered to show **Comments** first, followed by **Audit**, improving the workflow for analysts reviewing incident activity. ### Data Source Activity Monitoring * Data source activity charts now update in real-time, giving administrators immediate visibility into ingestion health without refreshing. * Added a new "Last Seen" indicator to quickly identify stale or disconnected data sources. ### Agent Center * Improved agent investigation messaging — when an agent investigation takes longer than expected, the notification now indicates that the agent will continue working in the background rather than showing a timeout error. ### Bug Fixes * Fixed time zone display issues in incident timestamps. * Resolved entity context panel occasionally not loading for certain entity types. * Fixed an issue where the Agent Center failed to display available agent updates. * Removed an inaccurate tooltip from the Log Search run button. ### Agent Deployment * Simplified agent deployment with a new guided wizard that validates Azure prerequisites before provisioning. * Added deployment status notifications so administrators know when agents are ready. ### Filter Persistence * Filters across the Command dashboard, Incidents, and Gamebooks pages now persist across sessions, reducing repetitive filter configuration. ### Bug Fixes * Fixed agent configuration page not loading when no agents were deployed. * Resolved intermittent failures when saving notification preferences. * Fixed Gamebook Activity filter not correctly displaying queued Gamebooks. ### Platform Performance * Optimized incident list queries, reducing load times by up to 40% for high-volume workspaces. * Improved caching for workspace metadata, reducing redundant API calls during navigation. * The Incidents page now defaults to a 3-hour time filter instead of 24 hours, improving initial load times for high-volume workspaces. ### Gamebook Execution * Gamebook execution logs now stream in real-time, providing immediate feedback during manual and automated runs. ### Bug Fixes * Fixed memory leak in the incident polling service. * Resolved rare race condition causing duplicate incident entries in the UI. * Fixed an issue where pre-onboarding a new workspace did not correctly assign owner access to the administrator. * Fixed an issue where administrators could not access agent configuration from the Agent Center. ### Workspace Manager * Added tooltips to the **CMS** and **Settings** icons in the Workspace Manager, matching the tooltip pattern used elsewhere in the portal. ### Bug Fixes * Fixed an issue where workspace group membership changes were not reflected until page refresh. * Resolved CMS rule deployment failures for workspaces with special characters in their names. * Fixed entity search returning incomplete results for IP addresses. * Corrected tooltip alignment issues in the Command dashboard widgets. * Fixed entity context menu in the Gamebooks workbench requiring a second click to show available actions. * Fixed an error when viewing the Alert Rule tab for incidents from Microsoft Defender for Endpoint and other non-Sentinel sources. * Fixed incident closure failing for Microsoft Defender for Endpoint incidents. * Fixed the **Configure and save** button remaining clickable after completing Microsoft Sentinel configuration. ### Content Management System (CMS) Migration * Analytical rules, security content, and CMS capabilities are now fully integrated into the IRIS platform, delivering a unified experience for managing detection rules and security content without switching between tools. ### Platform Upgrade to .NET 10 * The platform has been upgraded to .NET 10, improving performance, security, and long-term supportability across all services. ### Agent Center Enhancements * Administrators can now update agent container images directly from the Agent Center, reducing operational overhead when deploying new agent versions. * Agent efficacy improvements: agents now have access to sign-in logs, directory logs, device timelines, and related incidents as investigation tools — enabling richer, more accurate automated investigations. * Default AI model capacity increased to 150K tokens per minute, improving agent throughput for high-volume environments. ### Gamebook Fixes * Resolved an issue where the gamebook approval button was not functioning correctly in the incident detail modal. ### Notification Settings * Users can now toggle severity-based notifications without requiring recipients to be configured first, simplifying initial notification setup. ### Filtering Experience * Filters across the portal now persist as you navigate between pages, eliminating the need to re-apply filters repeatedly. ### Bug Fixes * Fixed an issue where API error responses with empty bodies caused client-side errors. * Fixed null reference errors when agents array was uninitialized. * Resolved issues with SentinelOne and Azure response module configuration logic. * Fixed security rule detail page errors. ### Command 2.0 Dashboard * The Command page has been redesigned with a new dashboard layout featuring at-a-glance operational metrics, giving security teams immediate visibility into their security posture. ### New Dashboard Widgets * **Incident Tracker Overview** — Track open, in-progress, and resolved incidents across all workspaces in a single view. * **Closed Incident Rule Trends** — Understand which detection rules are driving the most resolved incidents over time. * **Workspace Closed Incident Trends** — Compare incident resolution performance across workspaces. * **Gamebook Activity Widget** — Monitor active gamebook executions and their current status in real time. * **Gamebook History Widget** — Review past gamebook runs with outcomes and timing for post-incident analysis. ### Agent Deployment Improvements * Added support for selecting preferred AI models in the Agent Center. * Continued support for standard agent deployment alongside newer deployment options for existing customers. ### CrowdStrike Integration Enhancements * Incident descriptions from CrowdStrike are now automatically generated with richer context. * CrowdStrike incident comments are now fetched from audit logs, providing a complete conversation history within IRIS. ### SentinelOne Integration Enhancements * Added support for SentinelOne threat classifications (verdicts), giving analysts clearer disposition information. * Fixed incident description formatting for SentinelOne incidents. ### Bug Fixes * Fixed workspace filter not resetting to "All Workspaces" correctly. * Resolved inaccurate time filtering for the 24-hour filter option. * Fixed custom time filter unable to change from an existing custom selection. * Fixed duplicate rule entity mapping errors. ### Audit Trail System * A comprehensive audit trail is now available for incident updates, entity investigations, and status changes. Security teams can review a full history of who did what and when — critical for compliance and post-incident review. * Audit logs for user sign-in and directory events are now queryable within the platform. ### Agent Improvements for General Availability * Agents now automatically trigger investigations on new incidents, reducing mean-time-to-respond without manual intervention. * Real-time gamebook status updates are now streamed to the UI — no more refreshing to see investigation progress. * Gamebook execution results are now visible directly on the Gamebook page. * Agent response flow improved with better error handling and detailed comments when issues occur. * Prevented duplicate agent investigations on the same incident. * Agent UI refined for general availability readiness. ### Workspace Group Management * Group member details, including member lists, are now visible in the group viewing slider within workspace settings. ### Data Source Activity * The data source activity graph has been enhanced for better readability and alignment. ### Bug Fixes * Fixed time filter refresh behavior on the incidents page. * Fixed agent response button remaining active when agent is not properly configured. * Fixed Defender incident comment creation for comments exceeding 1,000 characters. * Resolved incorrect log search results for Microsoft Defender data sources. * Fixed data source query results mapping to use column names instead of index positions, improving reliability. ### Ticketing Orchestrator * Introduced a new ticketing orchestration layer that improves reliability and consistency when creating and managing tickets across integrated ticketing systems (Jira, ServiceNow, Autotask). ### Agent Flow Optimization * The agent investigation and response flow has been optimized for performance, with improved classification mapping and enriched logging for better troubleshooting. ### Time Filter Improvements * Time filters throughout the portal now correctly display in local time instead of UTC, and the refresh behavior has been improved. ### Bug Fixes * Fixed ticket creation for Microsoft Defender incidents in Autotask. * Resolved entity context menu appearing for non-Microsoft sourced incidents. ### CMS 3.0 Release * The Content Management System has been finalized with an updated user interface, improved rule details pages, and refined commenting capabilities for security content collaboration. ### Notification System * A new notification settings system allows workspace administrators to configure alert recipients, severity thresholds, and notification preferences per workspace — ensuring the right people are notified about the right events. * Notification recipients can be added and removed directly from workspace settings. ### Agent Center * A redesigned Agent Center creation experience with step validation, an Azure region picker for selecting agent resource locations, and an improved configuration details view. * Agent deployment reliability has been significantly increased with improved error handling and processing time. ### Feature Flag Cleanup * Gamebooks 2.0 and Workspace Management features are now generally available — feature flags have been removed, making these capabilities available to all users by default. ### Bug Fixes * Fixed deployment table routing when switching workspaces. * Fixed notification delivery issues identified during QA. * Resolved IAM management component flag check issues. Questions about the release notes? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # ContraForce Capabilities Matrix Source: https://docs.contraforce.com/staging/contraforce-capabilities-matrix Complete feature reference for ContraForce capabilities across all supported security integrations — Microsoft Sentinel, Defender for Endpoint, CrowdStrike, SentinelOne, and more. This matrix shows which ContraForce features are available for each supported security integration. Use it to understand what your team can do based on the tools deployed in your customer environments. Looking for Microsoft Defender for Endpoint-specific capability details by license tier (Business Premium, E3, E5)? See the [Microsoft Defender Capability Matrix](/guides/technical/microsoft-defender-capability-matrix). *** ## Legend | Symbol | Meaning | | :----: | ---------------------------------------- | | ✓ | Capability fully available | | ✓(1) | Requires Microsoft Entra ID connection | | ✓(2) | Requires Microsoft Defender for Endpoint | | ✓(3) | Requires Microsoft 365 Exchange license | | — | Not available | *** ## Supported Integrations | Category | Integration | | ------------- | ---------------------------------------------------------------- | | **SIEM** | Microsoft Sentinel | | **XDR / EDR** | Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne | | **Identity** | Microsoft Entra ID | | **Email** | Microsoft 365 Exchange | *** ## Incident Management Unified incident queue with cross-workspace handling, bidirectional sync, and analyst assignment. | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ------------------------------ | :----------------: | :-------------------: | :----------------: | :---------: | | Bidirectional incident sync | ✓ | ✓ | ✓ | ✓ | | Fetch incident entities | ✓ | ✓ | ✓ | ✓ | | Fetch incident evidence (logs) | ✓ | ✓ | — | — | | Alert timelines | ✓ | ✓ | ✓ | — | | Investigation audit trail | ✓ | ✓ | ✓ | ✓ | *** ## Entity Enrichment & Triage Contextual intelligence for users, devices, IPs, files, emails, and URLs during investigations. ### User Insights | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ----------------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Related incident search | ✓ | ✓ | — | — | | Sign-in logs | ✓ | ✓(1) | — | — | | Audit logs | ✓ | ✓(1) | — | — | | Entra ID profile | ✓ | ✓(1) | — | — | ### Device Insights | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ----------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Device info | ✓ | ✓ | — | — | | Device timeline | ✓ | ✓(2) | — | — | | Related incidents | ✓ | ✓(2) | — | — | ### IP Address Insights | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ----------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Sign-in activity | ✓ | — | — | — | | Related incidents | ✓ | ✓(2) | — | — | ### Email, File & URL Insights | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ---------- | :----------------: | :-------------------: | :----------------: | :---------: | | Email info | ✓ | ✓(2) | — | — | | File info | ✓ | ✓ | — | — | | URL info | ✓ | ✓(2) | — | — | **(1)** Requires Microsoft Entra ID connection. **(2)** Requires Defender for Endpoint — included with E5 or available as an add-on for Business Premium and E3. *** ## Log Search Direct query access to log data for deep investigation and threat hunting. | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ----------------------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Log search (Advanced Hunting) | ✓ | ✓(2) | — | — | *** ## Gamebook Response Actions Automated response playbooks for endpoint, file, identity, and email threats. ### Endpoint Actions | Action | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ---------------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Isolate device | ✓(2) | ✓ | — | ✓ | | Anti-virus scan | ✓(2) | ✓ | — | ✓ | | Release from isolation | ✓(2) | ✓ | — | ✓ | ### File Actions | Action | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | --------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Quarantine file | ✓(2) | ✓ | — | — | ### User Actions | Action | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ------------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Invalidate sessions | ✓(1) | ✓(1) | — | — | | Reset password | ✓(1) | ✓(1) | — | — | | Lock user | ✓(1) | ✓(1) | — | — | | Unlock user | ✓(1) | ✓(1) | — | — | ### Email Actions | Action | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ----------------- | :----------------: | :-------------------: | :----------------: | :---------: | | Soft delete email | ✓(3) | ✓(3) | — | — | **(1)** Requires Microsoft Entra ID connection and the Gamebooks for Identity enterprise application. **(2)** Requires Defender for Endpoint — Sentinel gamebook actions execute through Defender for Endpoint. **(3)** Requires Microsoft 365 Exchange license and the Microsoft 365 Response enterprise application. *** ## Endpoint Management View and manage devices across your customer environments. | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ------------------- | :----------------: | :-------------------: | :----------------: | :---------: | | View device list | — | ✓ | — | — | | View device details | — | ✓ | — | — | *** ## Content Management System (CMS) Deploy and manage detection rules across workspaces. | Capability | Microsoft Sentinel | Defender for Endpoint | CrowdStrike Falcon | SentinelOne | | ------------------------ | :----------------: | :-------------------: | :----------------: | :---------: | | Deploy detection rules | ✓ | — | — | — | | Remove detection rules | ✓ | — | — | — | | Auto-update subscription | ✓ | — | — | — | CMS requires the **XDR + SIEM module**. Microsoft Sentinel must be connected to use CMS. *** ## Incident Notifications Email notifications when new incidents arrive. | Integration | Email Notification | | ------------------------------- | :----------------: | | Microsoft Sentinel | ✓ | | Microsoft Defender for Endpoint | — | | CrowdStrike Falcon | — | | SentinelOne | — | Incident email notifications require the **XDR + SIEM module**. Email notifications for Gamebook activity are available across all modules. *** ## Related Guides XDR capabilities by Microsoft 365 license tier Deploy the Defender for Endpoint module Deploy the XDR + SIEM module Service principal permissions reference *** Questions about capabilities or integrations? Contact us at [support@contraforce.com](mailto:support@contraforce.com). # Submit a Support Ticket Source: https://docs.contraforce.com/submit-ticket Open a support request with the ContraForce team and we'll get back to you promptly. Our support team typically responds within **1 business day**. For urgent security incidents, email [support@contraforce.com](mailto:support@contraforce.com) directly with "URGENT" in the subject line. ## Open a Ticket Click here to open the support ticket form. The more detail you provide, the faster we can help. ## What to Include To help us resolve your issue quickly, please include: The exact workspace name where you're experiencing the issue. What you were doing when the issue occurred, step by step. Any error messages, screenshots, or screen recordings that show the problem. When the issue started — include date, time, and timezone if possible. ## Other Ways to Reach Us [support@contraforce.com](mailto:support@contraforce.com) Browse our docs for guides.