Understand Nova DRX

Nova Detection and Response eXchange coordinates supported response actions in the customer's security tools. DRX checks the proposed action, required permissions, policies and approvals before attempting it.

DRX records the trigger, proposed action, checks, approval, execution progress and reported result. A proposal is not permission to act, and a successful check is not an executed action. Review the provider's reported result before marking the response complete.

Command Center

Shows response readiness, trigger activity, proposals, execution health, and effectiveness in operating context.

Automation Studio

Lets authorized teams build, inspect and validate response playbooks.

Action Exchange

Provides a closed catalog of named, provider-specific outcomes instead of open-ended remote commands.

Integration Hub

Shows provider readiness, supported outcomes, and connection health before an action is eligible.

Response proposals

Keeps the proposed action, affected systems, supporting evidence, reason and required approvals together for review.

Effectiveness and governance

Retains execution evidence, outcomes, tuning decisions, and change history for later review.

1. 01
   Trigger

   Receive a deduplicated event, reviewed proposal, or authorized manual request.

2. 02
   Validate

   Check the playbook, supported action, customer scope, target, and integration readiness.

3. 03
   Simulate

   Review the intended path without treating simulation as a provider action or completed response.

4. 04
   Approve

   Apply the configured policy and any required separation between requester and approver.

5. 05
   Act

   Attempt only the supported provider outcome for the verified customer scope.

6. 06
   Prove

   Retain the request, decision, execution evidence, reported result, and review history.

Trusted customer scope

The action stays bound to the verified customer and optional organization context.

Supported-action catalog

Only named outcomes implemented for the selected provider can enter the execution path.

Non-mutating simulation

Simulation checks the intended path and stops before a provider change is treated as executed.

Approval policy

High-impact actions can require durable separation between requester and approver.

Fail-closed readiness

Unsupported outcomes, missing readiness, unavailable customer access, or failed controls block action.

Response record

The control path and provider-reported outcome remain available after the moment of action.

• Notify collaboration, email, and on-call destinations with an approved security summary.
• Create issues or incidents in supported case-management and security tools.
• Forward approved security records to supported security-data destinations.
• Enrich or share selected threat indicators through supported intelligence providers.
• Perform selected identity, endpoint, network, cloud-workload, storage, and email containment outcomes.
• Perform selected recovery or release outcomes when the provider and customer policy support them.

• Choose a small set of real response outcomes and define the expected customer approval for each one.
• Confirm the exact provider, target type, region, product plan, and customer-owned access available for the test.
• Test validation, simulation, approval, success, partial completion, failure, and reversal paths where applicable.
• Verify that the final record shows scope, action, decision, actor context, and provider-reported result.
• Do not treat a public integration page as confirmation that the provider is activated for a specific customer environment.