Skip to main content

Security Operations Guide

If a term is unfamiliar, open the Glossary.

Security engineers and analysts use Dralvia to triage phishing, enforce policies, and kick off response actions.

Daily consoles​

ConsolePurposeTips
URL & Phishing Scanner (#/phishing)Review scan history, EvidencePacks, redirect timelinesExport packs for incident tickets via Download EvidencePack.
Web Access Protection (#/swg-policy)Manage category DB, inline coaching, and adaptive shadow browsingKeep policies in dry-run until you review Dry-run events + exceptions.
Email Protection (#/email-protection)Monitor safe-link rewrites, detonation verdicts, and BEC heuristicsUse the + Upload Suspicious Email entry for manual submissions.
Endpoint Protection (#/edr-console)Host inventory (active/inactive), alerts, isolation/decommissionIsolation calls map to /edr/isolation; decommission maps to /edr/hosts/<id>/decommission.
Identity Risk (#/identity-risk)Impossible travel + session hijack alertsEach alert links back to the underlying AuthSessionEvent.

Investigations​

  1. Start in EvidencePacks (Dralvia's exportable evidence reports): #/transparency lists every pack with Merkle proof so you can anchor timeline evidence.
  2. Shadow browse: use the adaptive shadow-browsing action in Web Access Protection to fetch sanitized DOM snippets for risky selectors.
  3. Escalate: click “Send to Security” in scan details or use the workspace TicketBridge case-ingest API to push a case into your SOC tooling.
  4. Contain: use #/edr-console to isolate a host or trigger the ransomware canary workflow.

Playbooks​

  • Suspicious link reported

    1. Scan via /scan.
    2. Trigger email protection rewrite for the original message.
    3. Add an SWG exception or policy tweak if it’s a sanctioned domain.

  • Brand impersonation detected

    1. Use adaptive shadow browsing to capture the login form snippet.
    2. Share the EvidencePack with legal/abuse for takedown.
    3. Add the domain to TrustedBrand list if it’s legitimate.

  • Impossible travel alert

    1. Open #/identity-risk.
    2. Review the two AuthSessionEvents that triggered the alert.
    3. Kick off forced password reset + session invalidation if suspicious.

Reporting & KPIs​

  • Use #/usage and #/pilot-kpis to export detections, latency, and campaign trends per workspace.
  • Compliance can request the latest DPIA/ROPA drafts from Dralvia support and link those documents plus EvidencePacks inside your ticketing tool.

Gateway telemetry​

  • The new Fabric Gateway workspace (#/fabric-gateway) lists every Envoy/front-door node, its health, version, and last-seen heartbeat. Use it to double-check that per-workspace gateways are alive before rolling out new policies.
  • The same console exposes passive access logs (method, host, status, latency, block/allow decision). Drill into a log entry to export the JSON artifact or download a CSV if your SOC needs to ingest it downstream.
  • The gateway APIs live under /fabric/gateway/*; edge agents can push batched logs by POSTing to /fabric/gateway/logs with your workspace ID and node token.

ZTNA monitor​

  • Private apps now sit behind Fabric ZTNA tunnels. Visit #/fabric-ztna to check tunnel status, relay version, and the latest allowed/blocked sessions.
  • The session panel lets you filter recent connections and download the audit JSON (user, application, bytes, duration, policy reason). Use it when investigating suspicious access or proving that block rules fired.
  • Your agent posts decisions to /fabric/ztna/sessions; use your onboarding package or contact support for field-level details.

Namespace quotas & NetworkPolicies​

  • Each workspace gets CPU/memory/pod/storage ceilings per namespace. Review and adjust them in Fabric Quotas (#/fabric-quotas) as needed.
  • NetworkPolicies are enabled by default on k3s/k3d clusters. Backend pods only accept traffic from admin and identity components, reducing blast radius if a workspace’s namespace is compromised.

Data residency​

  • Workspaces can opt into EU residency by tagging their namespace with residency: eu. Dralvia runs a dedicated shared-eu cluster (same on-prem footprint) so all EvidencePacks, audit exports, and billing meters stay inside EU storage roots.
  • Enterprise workspaces can see their data-residency posture (assigned region and how to request a change) in Enterprise Controls (#/enterprise-controls); Dralvia operates region assignment and replication.
  • Region metadata is tracked per workspace on the Dralvia side and reflected in your residency posture.
  • To request EU residency, use the region change request in Enterprise Controls or open a ticket with Dralvia support; the change shows in your residency posture once executed.

Header normalization​

  • Use Header Normalization (#/header-inline) to add or override security headers when you can’t edit an upstream stack fast enough. Rules are scoped per workspace and domain pattern.
  • Supported actions: Set/Override, Append, and Remove. Operations run in priority order and can target response, request, or both directions.
  • The built-in preview tool lets you paste current response headers, apply the rule set, and inspect the before/after diff before enabling the rule for users. Disable a rule (or delete it) instantly if it causes breakage.
  • Every change automatically records a before/after snapshot under the Audit Trail. Download the EvidencePack if compliance needs proof, or click Rollback to disable all rules that contributed to that change.
  • Want to block risky headers in CI? Use the dr-scan-url action so GitHub/Azure pipelines fail whenever HSTS/CSP findings trip.

Authenticated header scans​

  • Some portals only expose sensitive headers after you log in. Dralvia can now execute Playwright flows on your behalf (Chromium headless) to sign in, capture the issued session cookies, and include the Secure/HttpOnly/SameSite verdicts in the EvidencePack.
  • Provide your flow in the BAS Auth Crawl tab (or ask Dralvia support to load it for you). Each entry supports sign-in steps (goto, fill, click, wait_for_selector, wait) plus session_cookies patterns to inspect. Secrets stay in your vault by referencing env variables (username_env, password_env, action-level value_env).
  • When the job runs, the BAS Auth Crawl page shows a “Playwright available” badge for the target and renders a cookie table with any missing attributes flagged. EvidencePacks now contain a playwright_session module with the raw data so auditors can prove the session cookie posture.
  • Don’t want Playwright executing in a particular environment? Set DRALVIA_DISABLE_PLAYWRIGHT=1 and the backend will skip the flow (the job response will note that Playwright was disabled).

Automation hooks​

EventHook
Email rewrite verdictPOST /email/protect response contains safe_links to log or blocklist.
SWG decisionLog swg_dry_run_event rows to SIEM for trending.
EDR isolation/decommission/edr/isolation response includes signed action ID; /edr/hosts/<id>/decommission marks a host inactive without deleting history.

Mirror these runbooks in your internal wiki if needed, but treat this page as the single source of truth so workspace SOC teams stay aligned with Dralvia best practices.

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.

Next best actions​

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

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.

ErrorMeaningWhat to do now
401 UnauthorizedSession 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 ForbiddenYou 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 FoundThe 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 RequestsRate limit/quota window was exceeded.Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server ErrorBackend 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.