Endpoint Response Guide

Use this playbook when working with the EDR sensors, isolation controls, and ransomware canaries. If a term is unfamiliar (for example EDR, quota, or rate limit), open the Glossary.

Quick start (10 minutes)

1. Open #/edr-console and confirm at least one host is online.
2. Register one pilot host with a friendly name and owner.
3. Trigger one controlled isolation test on the pilot host.
4. Confirm host status changed and events appear in the timeline.
5. Release host and document the reason.

Deep dive setup flow (GUI + API parity)

Prerequisites

• Active workspace API key.
• At least one enrolled endpoint sensor sending telemetry.
• Operator account with EDR write permissions.

Exact fields to fill

• Host registration: host_id, friendly_name, owner, platform, optional tags.
• Isolation request: host_id, reason.

Step-by-step flow

1. GUI: in #/edr-console, open Register host, fill exact fields, and save.
2. API parity: GET /api/edr/hosts?limit=200 to confirm the host exists.
3. GUI: click Isolate host for the pilot endpoint.
4. API parity: POST /api/edr/isolation with host_id + reason.
5. Validate state with GET /api/edr/hosts/{host_id}/state.
6. Decommission test path (optional): POST /api/edr/hosts/{host_id}/decommission.

Expected result

• Host appears in inventory with expected metadata.
• Isolation state transitions are visible in UI and API.
• Audit/event timeline contains operation records.

Rollback path

1. Release host from isolation in UI (or run the corresponding release operation your workspace uses).
2. Re-check host state endpoint until normal.
3. If metadata is incorrect, update host registration and refresh inventory.

Annotated screenshot

Figure: Register host, isolate with reason, and validate state transition.

Sensor deployment

• Linux: install the eBPF sensor package supplied by Dralvia (deb/rpm/daemonset). Set the workspace ID + host ID during install.
• Windows/macOS: deploy the user-mode collector from the Dralvia agent bundle (macOS build available) or package it with your RMM.
• Registration: after installation, visit #/edr-console → Register host to associate metadata (hostname, friendly name, owner, tags).

Alerts & telemetry

• Process, network, canary, and custom alerts flow into #/edr-console and /edr/events.
• Every alert is linked to EvidencePack (Dralvia's exportable evidence report) entries so you can export findings.
• Use filters (platform, severity, workspace) to drill down quickly.

Isolation workflow

1. Identify the host in #/edr-console.
2. Click Isolate host (or call POST /edr/isolation with host_id).
3. Monitor the status banner (pending → isolating → isolated). If it fails, check sensor connectivity.
4. After remediation, click Release host and note the reason for the audit log.

Ransomware canaries

• Sensors deploy canary files in protected directories. Alerts appear if the file changes unexpectedly.
• When triggered, automate a TicketBridge case and consider isolating the host immediately.

Host inventory and decommission

• The Endpoint Protection now shows an active badge per host plus the friendly name you provided at registration.
• To retire a server/VM, click Decommission in #/edr-console (or call POST /edr/hosts/<id>/decommission). The host remains in history but is marked inactive so quotas and alerts ignore it.
• Use the Include inactive filter to review previously decommissioned hosts. Reactivate by re-registering with the same host ID.
• Host inventory, recent telemetry, and isolation audit rows now paginate at 3 items per page in the console.

Incident response checklist

1. Contain: isolate host, revoke credentials via IdP.
2. Eradicate: run your IR tooling (EDR scripts, memory dump, etc.).
3. Recover: release host once clean, restore files if needed.
4. Lessons learned: log actions in TicketBridge, update EvidencePack, and feed any new indicators into SWG/email policies.

Include this guide in your SOC onboarding and map the isolation API into your orchestration tooling for faster response.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace account.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Review current status/health/last update indicators before making changes.
3. Apply one change at a time and save.
4. Run the available validate/probe/refresh action.
5. Confirm the expected output appears (status change, new event, successful result).
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest data from backend APIs without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

GUI -> API quick map

GUI action	API endpoint	Expected outcome
Load hosts table	GET /api/edr/hosts?limit=200	Returns workspace host inventory.
Load recent activity	GET /api/edr/events/recent?limit=200	Returns latest EDR events for workspace hosts.
Isolate host	POST /api/edr/isolation	Host enters isolated state.
Decommission host	POST /api/edr/hosts/{host_id}/decommission	Host marked inactive for operations/quotas.
Verify host state	GET /api/edr/hosts/{host_id}/state	Confirms current host lifecycle state.

Copy-paste curl examples

BASE_URL="https://dralvia.tech"
API_KEY="YOUR_TENANT_API_KEY"
HOST_ID="host-123"

curl -sS "$BASE_URL/api/edr/hosts?limit=50" \
  -H "X-API-Key: $API_KEY"

curl -sS -X POST "$BASE_URL/api/edr/isolation" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $API_KEY" \
  -d "{\"host_id\":\"$HOST_ID\",\"reason\":\"suspicious-process\"}"

Postman collection notes

• Set collection variables: base_url, api_key, host_id.
• Add collection-level header: X-API-Key: {{api_key}}.
• Validate by running GET /api/edr/hosts first, then POST /api/edr/isolation.

Idempotency and retry guidance

• GET endpoints are safe to retry.
• POST /api/edr/isolation and decommission are state-changing: check host state before repeating.
• If timeout occurs, run GET /api/edr/hosts/{host_id}/state first, then retry only if state was not changed.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• Web Access Protection and dry-run events
• Identity risk and OAuth response
• EvidencePack verification and transparency log
• Risk economics and plan recommendation
• Autonomous readiness and probes

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.