DataguardNXT · managed security platform · prototype handoff

DataguardNXT Console Prototypes

Three working, clickable consoles: the SOC analyst console for DataguardNXT staff, the partner console for MSPs and resellers, and the customer console. They share one demo data store, so an action in one console shows up in the others, the same way the real system should behave.

Open SOC analyst console Open partner console Open customer console

To share data between people and devices, run python3 server.py in the folder and open http://localhost:8080; everything is saved in a SQLite file. Open the consoles in separate tabs, side by side. Use Chrome or Edge. Opening the files straight from the folder works. If a browser keeps the consoles apart (Firefox does for local files), run python3 -m http.server 8080 in the folder and open http://localhost:8080.

The three products

Who uses each console

DataguardNXT staff

SOC analyst console

  • Case queue with SLA timers, AI review, requests from customers and partners
  • Tenants, pods, partners, onboarding approvals
  • Pipeline health: local collectors → central collector → Wazuh, single node or distributed, with a side panel per host
  • Health score rules, integration catalog, maintenance windows, staff and permissions
  • Four themes: light, dark, dusk, paper
dgnxt_soc_analyst_console.html

Switch role from the avatar menu: L1, L2, L3, platform engineer, SOC manager, platform admin.

MSP / reseller

Partner console

  • Portfolio of the partner's customers with health scores and an action queue
  • Opens each customer's console as that customer sees it
  • Onboarding requests, licences and renewals, AMC tickets, requests to DataguardNXT
  • Notification bell; Settings → Health rules shows the score rules read-only
dgnxt_partner_console.html

Demo partner: Northwind IT. Profiles: admin, engineer, sales, finance.

End customer

Customer console

  • Overview with the health score and how it was reached
  • Incidents, threat protection, resilience (backup), exposure
  • Tickets (including AMC tickets to their partner), renewals, maintenance windows
  • Compliance by framework, users and access, integrations catalog, reports
client-console/index.html

Switch tenant from the account menu (Oryx, Falcon, Dune, Pearl). Profiles: admin, IT member, viewer.

Demo walkthroughs

Flows that cross consoles

Each one shows a feature the backend has to support end to end. Click to expand.

Maintenance window

customeranalystpartner
  1. Customer console → Maintenance → Plan maintenance. Pick a system, a start time and hours.
  2. Analyst console → Requests (or Maintenance). The request has ACCEPT WINDOW and DECLINE.
  3. After accepting: while the window runs, cases from that tenant and source show MAINT · SLA PAUSED, the SLA clock stops and the ticker shows IN MAINTENANCE.
  4. Customer sees Requested → Accepted → Active now · SLA paused → Completed. The partner gets it in the bell.

Health score rules

analystcustomerpartner
  1. Analyst console as platform admin → Health score rules. Change points, caps or bands. This saves a draft with a preview per customer.
  2. Publish with a note. The version goes up (v1.0 → v1.1) and the exact changes are recorded.
  3. Customer and partner consoles update immediately. "How your score was reached" lists the changes and the score under the old and new rules. Both get a bell notification.

Partner onboards a customer

partneranalyst
  1. Partner console → Onboarding → Add customer. This sends an approval request to DataguardNXT.
  2. Analyst console → Onboarding. Approve or reject with a reason.
  3. Partner sees the decision. On approval the install kit (script and setup guide) unlocks. The enrolment token is never in the script.

Requests to DataguardNXT

partnercustomeranalyst
  1. Partner: service change, health-check call, maintenance window, suggestion. Customer: renewals, maintenance, service requests.
  2. Analyst console → Requests: customer and partner sections, type-specific actions, a reply thread.
  3. Status and replies flow back to the requester; the partner bell shows them.

AMC support tickets

partnercustomer
  1. Partner console → Settings → Customers & AMC: turn AMC on for a customer.
  2. Customer console → Tickets → New ticket: "Northwind IT (AMC support)" is now a recipient.
  3. Partner works the ticket and can escalate it to DataguardNXT.

Integration catalog

analystcustomerpartner
  1. Analyst console as platform admin → Integration catalog → + Add integration (or edit status, plans or the setup guide).
  2. Publish. Customer and partner catalogs (Integrations → Catalog) show new items marked NEW or BETA, and hidden items disappear.

Support view

analystpartnercustomer
  1. Analyst console → Tenants → a tenant → VIEW CUSTOMER CONSOLE or AS NORTHWIND IT SEES IT. The same buttons are on Partners & customers.
  2. The real console opens on that tenant or partner with a SUPPORT VIEW banner.

Compliance and users

customerpartner
  1. Customer console → Compliance: alert activity by framework (PCI DSS, GDPR, HIPAA, NIST 800-53, TSC) plus IT hygiene. Manage frameworks hides the ones a company doesn't need.
  2. Open a framework for its Dashboard (incidents over time, busiest requirements, machines, severity, rules), Requirements (incidents, monitored or nothing seen) and Events.
  3. Settings → Users & access: invite, change role, disable, reset MFA, remove; require MFA, SSO and partner access. Only Admins can change these.
  4. Plan names: the entry plan is Observe, the full service is Managed.

Integration request

customeranalyst
  1. Customer console (Falcon Bank, Advanced: no source limit) → Integrations → Catalog → pick an integration.
  2. The panel shows what you prepare (per connection method) and what DataguardNXT does. Request connection asks for a contact and a time, and for confirmation that the prerequisites are read.
  3. Analyst console → Requests: START SETUP, WAITING ON CUSTOMER, MARK CONNECTED. The customer sees Requested → Engineer connecting → Live under Integrations → Sources, and the catalog card turns Connected.

Health score presets

analystcustomerpartner
  1. Analyst console → Health score rules → Presets: rule sets for a type of customer (endpoint only, backup only, Observe, Plus, Advanced), each with its own points and bands.
  2. Relationship builder: WHEN a customer has a source type, a specific source or a package, THEN suggest a preset or switch on a rule. Checked top to bottom.
  3. Customers tab: what each customer sends, the suggested preset, an optional pinned preset, and the rules skipped because the data isn't there. Publish, and customer and partner consoles score with it.

Pipeline and host health

analyst
  1. Pipeline health → toggle SINGLE NODE / DISTRIBUTED.
  2. Click wazuh-01, CC-01 or any local collector to open its side panel: specs, usage, pipeline (buffer, queue, EPS, index), 24 h events, services, top processes.
  3. RESTART a service → restarting → back in N s, logged under Recent actions. LOG shows the service journal. FULL PROCESS VIEW opens a live process table.
Analyst console

Roles and permissions

✓ allowed · P = can propose; a manager approves in Staff & access → Approvals. The admin can edit this matrix in the console.

PermissionL1L2L3EngMgrAdmin
Partner profiles: admin sees everything. Engineer has everything except licences. Sales has portfolio, reports, requests, onboarding and licences. Finance has portfolio and licences only. Pages a profile can't use are hidden, and restricted actions show a message instead of acting.
Customer profiles: admin (everything, including approvals and settings), IT member (tickets, renewals and investigations; no approvals or settings), viewer (read only).
For the backend

Shared data the consoles exchange

In the prototype these live in browser storage, and a storage event refreshes the other open consoles. In production each collection becomes an API resource, and the storage event becomes a push (websocket or server-sent events) to the affected users.

CollectionWritten byRead byFields
reqsPartner, customer; analyst updates statusAll threeid, side (partner|customer), pid, tid, type, t, sum, src, svc, pri, from, at, st (New → Acknowledged/Scheduled/Done/Declined), thread[[who, text, at]], chg, mw{start, h}
onbPartner; analyst decidesPartner, analystid, partner, cust, pfx, contact, mail, plan, srcs[], site, st (new|approved|rejected|live), why, at
tksCustomer ↔ partnerCustomer, partner; analyst on escalationid, dir (c2p|p2c), tid, cust, partner, subj, pri, st, at, msgs[[who, text, at]]
renCustomer, partnerCustomer, partner; analyst when flaggedid, tid, cust, by, byName, item, vendor, date, remind, share, dg
amcPartnerCustomer, partner{ tenantId: true|false }
catalogAnalyst (admin publish)Customer, partnerver, at, by, items[{id, n, vendor, cat, modes, mb, t, status (available|beta|soon|hidden), plans, partner, guide[], isNew}]
score modelAnalyst (admin publish)All threepublished{ver, at, by, note, base, floor, bands{good, watch}, factors[{id, label, what, area, pts, cap, on}], changes[], prev}, draft, history[]

Health score formula

Start at base (100). For each factor that is on, subtract min(count × pts, cap). Clamp to [floor, 100]. Band: Good ≥ bands.good, Watch ≥ bands.watch, else At risk. The inputs are counted from the tenant's data and are never filtered.

decisions    cases waiting on the customer
backup_fail  workloads whose last backup failed
no_backup    workloads with no backup plan
kev          CISA known-exploited CVEs open
unprotected  devices with no security agent
degraded     sources not sending all data

Analyst-only state (stays server-side)

maintenance
windows: tid, src, start, end, why, by; ended early or extended
host actions
per host: at, who, action, result (restarts, replay, cert rotation)
approvals
L1 proposals for tuning and bans, approved by a manager
audit
every admin and tenant change, with actor and time
saved views
per analyst: named filter sets (pod, partner, customer, source)
Before you estimate

What is simulated

Mocked in the prototype

  • All tenants, cases, hosts and metrics are seeded demo data; times are relative to when the page loads
  • No login. Roles and profiles are switched from a menu
  • Service restarts, buffer replay, cert rotation, emails and SMTP only update the screen
  • Vendor connections (Bitdefender, FortiGate, Microsoft 365, Acronis and others) are not called

Behaviour to keep

  • Tenant identity is stamped from the collector certificate, never from the payload
  • The install script never contains the enrolment token
  • Drafts never reach customers until published (catalog, score rules)
  • Every change made on a customer's behalf is written to that tenant's change log

Older prototypes in the same folder (RecoverReady console and app, the first analyst console) are reference material and not part of this handoff.