Unified Security Control Plane (USCP) — End‑User Guide

Who this guide is for: the everyday user of the USCP web console — a security analyst, SOC operator, or auditor who opens the product in a browser to do their daily work. You do not need to know how USCP was installed, deployed, or licensed. You do not need to be a developer. Every task below is written as a numbered, click‑by‑click walkthrough, and the first time a piece of jargon appears it is explained in plain language.

How to read this guide

• If you have never signed in before, start at Part 2 (Signing in).
• If you can already sign in and just want to “get around,” read Part 3 (Getting around the console).
• If you want the step‑by‑step for a specific area (say, “how do I detonate a suspicious file?”), jump to Part 5 (Daily work by area) and find the matching heading.
• If something isn’t working or a menu is missing, read Part 8 (FAQ & self‑service troubleshooting) — it answers the most common “why can’t I…?” questions without needing to contact support.
• Every acronym is defined in Part 7 (Glossary).

Table of contents

1. Welcome & orientation
2. Signing in
3. Getting around the console
4. Personalizing the console (Settings)
5. Daily work by area
6. Common workflows / recipes
7. Glossary
8. FAQ & self‑service troubleshooting
9. Getting help

Part 1 — Welcome & orientation

What USCP is, in plain terms

The Unified Security Control Plane (USCP) is a single web application (a “console”) that a security team uses to run day‑to‑day security operations for their organization. Instead of logging into a dozen different tools, you sign into one place and, from there, you can:

• Watch for threats — see alerts, anomalies, and incidents pulled from your systems’ logs and telemetry (“telemetry” just means the stream of technical events your machines and software produce).
• Investigate — dig into a suspicious host, user, or file, and build up evidence.
• Respond — open a case (a tracked investigation), run automated playbooks (pre‑built response steps), isolate a host, block an address, or disable an account.
• Manage your estate — keep an inventory of the machines (“targets”) you protect and safely run commands on them through a recorded, brokered connection.
• Prove compliance — verify a tamper‑evident audit trail, pull evidence for auditors, and generate SLA reports.
• Govern access — manage who can log in, with what role, and check for risky combinations of permissions.

USCP is multi‑tenant. A tenant is one isolated organization’s workspace inside the platform. You only ever see your own tenant’s data; the platform keeps tenants strictly separated. Your session shows which tenant you are in.

What you can do depends on your role

USCP uses roles to decide what each person may do. The four you’ll encounter are:

Important: If you are a viewer or auditor (and not also an admin/operator), the console deliberately hides or disables the “manager” actions so you don’t click something you can’t do. Even if a control were shown, the server enforces your permissions independently — so you can browse freely without fear of breaking anything. When you’re read‑only, a small “Read‑only” badge appears next to your email in the top bar.

The big picture of the screen

After you sign in you land on the Overview (also called Home). From there the screen always has three fixed parts:

• A top bar across the very top (product name on the left; search, language, your identity, “Report a bug,” and “Sign out” on the right).
• A sidebar down the left (grouped links to every area of the product).
• The main content area in the middle/right, which changes as you click around.

Parts 3–5 walk through all of this in detail.

Part 2 — Signing in

USCP is passwordless by default — the normal way to sign in is to type your email and then enter a one‑time code that is emailed to you. There is no password to remember. Depending on how your organization set things up, you may instead use an authenticator app, a passkey, or your company’s single sign‑on (SSO). All of these are covered below.

Where do I go? Open the address your administrator gave you (for example https://uscp.yourcompany.com/) in a normal web browser. If you are not signed in, the console automatically sends you to the sign‑in page at /login.

2.1 The sign‑in screen

When you reach /login you see a card titled “Sign in.” It contains:

• A single field labelled Email with a note: “Enter your email — we’ll send a one‑time sign‑in code. No password.”
• A Continue button.
• Below a divider, a Single sign‑on section with a “work email” box and a “Continue with SSO →” button.
• Footer text reminding you that you can sign in with an emailed one‑time code, an authenticator app, or SSO — per your organization’s policy.

You do not choose your method from a menu. You type your email and click Continue; the system responds by showing you the correct next step (an email code box, or an authenticator‑code box). Here is each path.

2.2 Method A — Email one‑time code (the default, “passwordless”)

A one‑time code (often called an OTP, “one‑time passcode”) is a short number that is valid only briefly and only once. This is the default sign‑in.

1. On the sign‑in screen, click into the Email box and type your work email (the address your admin registered for you).
2. Click Continue.
3. The page shows a confirmation like “We emailed a sign‑in code to you@company.com. Enter it below.” and a new Email code box appears.
4. Open your email inbox and find the message from USCP. Copy the 6‑digit code.
5. Type (or paste) the code into the Email code box. The box only accepts digits, up to 6.
6. Click Sign in.
7. If the code is correct, you are taken straight to the Overview. Done.

If the code doesn’t work: you’ll see “That code was invalid or expired — try again.” Codes expire after a short time. Click nothing else — just request a fresh one by starting over: click “Use a different account” (which resets the form), re‑enter your email, and click Continue again to get a new code.

Note: For your security, the system always says a code was “emailed” even if the address isn’t recognized — it never reveals whether an email is registered. If no email arrives after a minute, check spam, confirm you typed the address exactly, and try again.

2.3 Method B — Authenticator app (TOTP)

TOTP stands for “Time‑based One‑Time Password.” It’s the rotating 6‑digit code shown by an authenticator app such as Microsoft Authenticator or Google Authenticator. If your organization uses this method, the flow is:

1. Type your username (in TOTP mode the field is labelled Username, not Email) and click Continue.
2. The message “Enter the 6‑digit code from your authenticator app.” appears with an Authenticator code box.
3. Open your authenticator app, find the entry for USCP, and read the current 6‑digit code.
4. Type it into the box and click Sign in. You land on the Overview.

Enrolling your authenticator the first time. You can only enter a TOTP code once your account has an authenticator enrolled. Enrolment is done inside the console (an administrator, or you if you hold a manager role, sets it up under Access control → Local accounts → Enrol TOTP). The enrolment screen shows:

• A Secret (Base32) string and an otpauth URI. In your authenticator app choose “add account” and either scan the code your admin shows you or paste the secret manually.
• A 6‑digit code box: type the current code your app shows and click Activate TOTP. Once it’s accepted, TOTP is active for your account and you can use Method B to sign in.

(If you don’t have a manager role, ask your administrator to enrol your authenticator — this is a one‑time setup.)

2.4 Method C — Passkey / WebAuthn

A passkey (the technology is called WebAuthn) lets you prove who you are with your device’s built‑in security — a fingerprint reader, face recognition, a Windows Hello PIN, or a hardware security key — instead of typing a code. Nothing secret is typed or emailed.

If your organization requires a passkey as the second factor, you will typically:

1. Sign in with SSO or your email as usual.
2. When prompted, your browser pops up its native passkey dialog (“Use your fingerprint,” “Insert your security key,” etc.).
3. Confirm with your fingerprint / face / PIN / key. You’re in.

Registering a passkey the first time happens after you have an authenticated session: the console asks your browser to create a passkey, and your browser guides you (touch the sensor, choose where to save the passkey). After that, future sign‑ins can use it. If you don’t see a passkey prompt, your organization may be using email codes or TOTP instead — that’s normal and set by policy.

2.5 Method D — Single sign‑on (SSO)

SSO means you sign in through your company’s own identity provider (IdP) — for example Okta, Microsoft Entra ID, Google Workspace, Ping, or ADFS — using the same login you use for other company apps. USCP figures out which provider to send you to based on your email’s domain (this is called home‑realm discovery — the “realm” is your organization’s identity system).

1. On the sign‑in screen, in the Single sign‑on box, type your work email (e.g. you@company.com).
2. Click “Continue with SSO →.”
3. Your browser is redirected to your company’s login page. Sign in there as you normally would (this may itself include your company’s MFA).
4. When your IdP confirms your identity, you’re returned to USCP and land on the Overview.

MFA is always required. “MFA” (multi‑factor authentication) means proving your identity two ways. USCP will not create a fully‑authenticated session on a single factor alone. Whether that second factor is an email code, a TOTP code, or a passkey depends on your organization’s policy.

2.6 When sign‑in fails — quick fixes

2.7 Signing out

To sign out, click the Sign out button at the far right of the top bar (a small “exit” icon). This ends your session and returns you to the sign‑in page. Always sign out on shared or public computers.

2.8 About sessions

A session is your signed‑in state. Sessions are time‑limited and end automatically after a period of inactivity or when they expire. If you leave the console open a long time and then click something, you may be bounced to the sign‑in page — that simply means your session expired; sign in again and continue. (If you hold a manager role, you can review and end sessions under Access control → Active sessions — see Part 5.)

Part 3 — Getting around the console

Once signed in, three things are always on screen: the top bar, the sidebar, and the main content. This part explains each, plus the two “power” tools every user should know — the command palette and the generic operation runner — and how to read the tables and results you’ll see everywhere.

3.1 The top bar

From left to right, the top bar contains:

• Product name & subtitle — “Unified Security Control Plane,” with a small count of how many capability domains are available.
• Search… ⌘K — opens the command palette (see 3.3). On Windows/Linux press Ctrl + K; on macOS press ⌘ + K.
• Language switcher — a dropdown to switch the console between English and Español. Your choice is remembered on this browser.
• Your identity (“who am I”) — a small circle with your initials, then your email. Hover to see your role(s) and tenant. If you are read‑only, a “Read‑only” badge appears here.
• Report a bug — opens a small form to send a diagnostic bug report (see Part 9).
• Sign out — the exit icon (see 2.7).

3.2 The sidebar (every group explained)

The sidebar is your main map. At the top are three always‑present links, then labelled groups, then a footer set of tools.

Top links:

• Overview — the home dashboard (Part 5.1).
• Logs & Flows — search raw logs, network flows, and the communication map (Part 5.24).
• Capability catalog — the full list of every feature (“capability”) your tenant may use, with its status (Part 5.25).

Grouped areas (these mirror how enterprise security consoles organize work):

• Identity & Access — Identity & session, Identity governance (IGA), Tenants. Managing who you are, checking risky permission combinations, and (for admins) tenant settings. Tenants and some identity screens only appear if you hold a manager role.
• Security Operations — Agentic SOC, Detection hub, CTEM / exposure, Data lake, intel & SOAR, Threat Analytics, Deception, Detonation, Digital Risk. This is the heart of daily threat work.
• Estate Management — Estate plane, OT / ICS, Fleet & Provisioning. Your inventory of machines and how you reach them.
• Governance & Trust — Policy plane, Audit & evidence, Lockbox & HYOK, SLA & private trust, Privacy & DSAR, Hardening & Drift. Rules, proof, and compliance.
• Platform — Licensing & updates, Integrations, Public & self‑serve, System health, Release & Supply Chain, Suite & MSP. The plumbing and status of the product.

Sidebar footer tools:

• Access control (managers only) — the IAM admin center (login methods, users, sessions, tokens; Part 5.23).
• Analytics — slice your security data by any dimension over time (Part 5.26).
• API Explorer — a built‑in, read‑only way to browse and try the product’s API (Part 5.27).
• Settings — personalize the console (Part 4).

Why don’t I see every item? The sidebar hides manager‑only areas (Tenants, Policy, Identity, Access control) from read‑only users. If a whole item is missing, it’s almost always your role. See Part 8.

3.3 The command palette (search and jump anywhere)

The command palette is the fastest way to move around — a search box that jumps to any area.

1. Press ⌘K (macOS) or Ctrl + K (Windows/Linux), or click Search… in the top bar.
2. Start typing what you want — e.g. “deception,” “cases,” “settings.”
3. Use the arrow keys to highlight a result and press Enter (or click it) to jump there.
4. Press Esc to close the palette without going anywhere.

The palette lists Go to Overview, Go to Settings, and every capability domain by name. It’s fully keyboard‑operable and works with screen readers.

3.4 The generic “run an operation” panel (how forms work)

Most areas of USCP have a purpose‑built screen (a real dashboard with tables, buttons, and charts). But a few areas present each action as a generic operation panel — a simple, consistent card that turns one API operation into a form. Once you understand this pattern, you can operate anything in the product.

Each operation panel looks like this:

• A title describing what it does (e.g. “Plant a honeytoken”).
• A small badge on the right showing the permission it needs (for example an entitlement key, session, public, or SCIM token).
• If it’s a read action with no inputs, it auto‑loads and shows the current data as a table or list, with a Refresh button to reload.
• If it’s a write action, it shows form fields derived from a sample. Fill them in and click the action button (labelled from the operation, e.g. “Plant →,” “Submit →”).

Field types you’ll see:

• Text / number boxes — type a value.
• Yes / No dropdowns — for true/false options.
• JSON boxes — for structured values (lists or nested objects). A small code box is pre‑filled with a valid example; edit it carefully, keeping the brackets and quotes intact. If you enter invalid JSON, the panel tells you exactly which field is wrong before sending anything.
• Path fields — some operations act on a specific item and show an input for its id (for example a user id). Type the id, then run.

Destructive actions (anything like a kill‑switch, deprovision, or delete) are shown with a red button so you notice them before clicking.

Running it: click the action button. It changes to “Working…” while it runs. When it finishes, a result appears below.

3.5 Reading a result (and the “Raw JSON” toggle)

Every result starts with a one‑line, plain‑language status:

• “OK (200)” (or similar) in green means it worked.
• A red line explains a failure in human terms. The most common are:
• Not signed in — your session ended; sign in again.
• Not licensed — this capability isn’t part of your tenant’s plan (Part 8).
• Not permitted for your role — your role can’t do this (Part 8).
• Not found — the item you referenced doesn’t exist.
• Network error — the console couldn’t reach the server.

Below the status, the data is rendered in a friendly view:

• An object becomes a two‑column list (label on the left, value on the right).
• A list of records becomes a table.
• True/false values show as a green ✓ yes or grey ✗ no badge.
• Long ids and hashes are shown in a monospace font so they’re easy to scan.

Click “Raw JSON” to see the exact underlying data (useful for copying an id), and “Formatted view” to switch back.

3.6 Reading tables, filtering, sorting, and exporting

Throughout the console you’ll meet a consistent, powerful data table. Here’s how to use it:

• Search — type in the Search… box above the table to filter rows to what matches your text.
• Sort — click a column header with a ↕ arrow to sort by it; click again to reverse. On some big tables (like Cases) sorting and searching apply to the entire dataset on the server, not just the page you’re viewing.
• Paging — use Previous / Next at the bottom to move between pages. The current page and result count are shown.
• Open a row — on tables where rows are clickable, click a row to open a detail drawer (a panel that slides in from the right). Press Esc or click the ✕ to close it.
• Export CSV — where an Export CSV button appears, click it to download the table as a spreadsheet‑friendly file (opens in Excel, Google Sheets, etc.). In client‑side tables this exports all filtered rows; in server‑driven tables it exports the rows currently loaded.

3.7 The API Explorer (browse and try the API)

The API Explorer (sidebar footer) is a built‑in, safe way to see every operation the running system exposes and to try read‑only ones — no external tools needed.

1. Click API Explorer.
2. Operations are grouped by tag; use the search box to filter by path or summary.
3. Each operation shows its method (GET/POST/…), path, and a one‑line summary.
4. For GET operations that need no parameters, a Send button appears — click it to run the call using your current session and see the JSON response.

There are also links to download the machine‑readable contract (openapi.yaml, asyncapi.yaml) for developers. As a user you’ll mostly use this to understand what’s available.

Part 4 — Personalizing the console (Settings)

Open Settings from the sidebar footer. Everything here is your preference on this browser (it’s remembered locally). Change a value and the console updates the preview immediately; click Save changes to keep it. A “Settings saved.” confirmation appears.

The Settings form (under Tenant preferences) has:

• Display name — a friendly name for yourself. Type it and Save.
• Theme — choose how the console looks:
• Dark (default) — light text on a dark background.
• Light — dark text on a light background.
• High contrast — a bolder, higher‑contrast dark theme for maximum readability/accessibility.
• Density — how tightly information is packed:
• Comfortable (default) — roomier spacing.
• Compact — tighter spacing to fit more on screen.
• Text direction — controls left‑to‑right vs right‑to‑left layout:
• Auto (default) — follows the language (right‑to‑left for languages like Arabic/Hebrew, left‑to‑right otherwise).
• LTR — force left‑to‑right.
• RTL — force right‑to‑left (the whole layout mirrors).
• Audit retention (days) — how long audit records are kept, in days (minimum 365; the default is 2555, about seven years). This is a preference field; your organization’s actual retention is governed by policy.

Language is not in this form — switch English/Español using the language dropdown in the top bar at any time.

Report a bug is also in the top bar, not Settings — see Part 9.

Accessibility note: the console is designed to meet accessibility standards — full keyboard operation, a “skip to main content” link, screen‑reader labels, focus‑trapped dialogs, and the high‑contrast theme above.

Part 5 — Daily work by area

This is the reference you’ll return to most. Each section explains, in plain language: what the area is, when you’d use it, click‑by‑click steps for the common task, what to type, and how to read the result. Areas are grouped the way the sidebar groups them.

Two ways an area is presented. Some areas are bespoke screens (rich dashboards — tables, tabs, charts, drawers). Others use the generic operation panels from Part 3.4 (a card per action). Each section says which, and the mechanics are identical to Part 3 either way.

5.1 Overview (Home)

What it is: your landing dashboard, led by your tenant’s security posture. It refreshes live as new events arrive.

How to read it:

• Top stat tiles: Open cases (and total), Critical & high (cases needing triage), SLA breached (open cases past their deadline), ATT&CK blind spots (attack techniques you have no detection for — see Glossary “ATT&CK”), and Audit chain (“Verified” means your tamper‑evident audit log is intact; “FAILED” means it needs attention).
• Open cases by severity — a donut chart splitting open cases into critical/high/medium/low. Click Cases → to go to the SOC.
• ATT&CK coverage — bars showing how many techniques are detected, mitigated, or blind. Click Detections → to improve coverage.
• Security activity — a 24‑hour timeline of events, a Notable events feed (mutating actions like a case opened or a break‑glass), and a Platform panel (licensing state, capability count, number of domains).
• Tip shown on the page: press ⌘K to jump anywhere.

If a panel can’t load, a red banner with a Retry button appears — click Retry.

Identity & Access

5.2 Identity & session

What it is: your own identity as the system sees it, plus (for admins) SCIM user/group provisioning. SCIM is the industry standard for automatically creating/updating user accounts from an HR or identity system.

When you’d use it: to confirm who you’re signed in as; admins use SCIM to list or manage provisioned users.

Presentation: generic operation panels.

Check who you are (any user):

1. Open Identity & session.
2. The “Who am I” panel auto‑loads and shows your email, roles, tenant, and user id.

SCIM operations (admins): panels to list, provision, get, patch, and deprovision SCIM users and groups. These carry a “SCIM token” badge — they require a machine token, not your browser session, so they’re normally driven by your identity system rather than clicked here. If you run one interactively without a token you’ll get an authorization error; that’s expected.

5.3 Identity governance (IGA)

What it is: IGA = Identity Governance & Administration — making sure people have the right access and no toxic combinations. Three tools live here:

• Separation of Duties (SoD) check — SoD means one person shouldn’t hold two powers that, together, let them commit and hide fraud (e.g. both “operator” and independent “auditor”). This checks a proposed grant.
• Leaver deprovisioning — plan the removal of all access for someone leaving.
• Access‑certification campaigns — periodic reviews where managers confirm who should keep access.

When you’d use it: before granting someone a new role (SoD check), when someone leaves (Leaver), or to see certification results.

Presentation: bespoke screen.

Run an SoD check:

1. Open Identity governance (IGA).
2. In Separation‑of‑duties check, enter the person’s existing roles (comma‑separated) and the new role you want to grant.
3. Click Check.
4. Read the verdict: a green Allowed badge means it’s fine; a red Toxic combination badge means the pairing is prohibited and should not be granted. Any other message (e.g. not licensed) is shown plainly — it does not mean “toxic.”

Plan a leaver:

1. In Leaver deprovisioning, enter the person’s identifier and their current roles/access.
2. Click Run. A deprovisioning plan is shown (what would be removed).

Certification campaigns are listed at the bottom with how many revocations each produced and when it ran.

5.4 Tenants (managers only)

What it is: self‑service settings for your own tenant. Presentation: bespoke screen. You’ll see:

• Tenant info — your tenant id.
• IP allowlist — restrict console access to specific network ranges (CIDRs, e.g. 203.0.113.0/24). Enter a comma‑separated list and Save.
• Roles — the built‑in roles and any custom roles.
• Lifecycle — Export your tenant’s data to a file, Suspend, or Delete the tenant (Delete asks you to type the tenant slug to confirm — a deliberate safety step).
• Organization (delegated admin) — link child tenants for oversight (used by MSPs and multi‑business‑unit orgs). Linking is consent‑based: a child clicks Generate invite code and shares it; a parent pastes it under Attach a child. Oversight shows only aggregate counts (open cases, findings), never a child’s raw data.

Security Operations

5.5 Agentic SOC (cases & autonomous agents)

What it is: the SOC — Security Operations Center — workspace. This single screen is where you manage cases and use agentic SOC helpers. A case is a tracked investigation/incident with its own severity, status, evidence, and history. Agentic SOC means optional AI agents that can triage, hunt, and suggest responses, always with a human in control and a kill switch to stop them instantly.

When you’d use it: all day — this is your incident queue.

Presentation: bespoke screen.

Open a new case:

1. Open Agentic SOC (labelled Cases / SOC in the sidebar under Security Operations).
2. In the New case form at the top, type a Title (e.g. “Suspicious login for jdoe”) and pick a Severity (critical/high/medium/low).
3. Click Open case. It appears in the queue below.

Work the queue:

1. Use the status filter (all / open / in progress / closed) and the Search box to find cases.
2. Click column headers to sort (e.g. by SLA or opened time). Cases past their SLA (deadline) show a red SLA breached badge.
3. Click a case row to open its detail drawer on the right.

Inside a case (the drawer):

• Header — severity, phase, priority, and SLA status.
• Lifecycle — the owner, and Move to: buttons for the legal next phases (triage → investigating → contained → eradicated → recovered → closed, and back where allowed). Click a phase to move the case.
• Assign… / Priority — click Assign… to set an owner (type an email/name, or leave blank to unassign). Click P1–P4 to set priority.
• Actions — Start (mark in‑progress), Run playbook (runs a standard triage playbook — enrich + notify SOC), and Close (asks you to confirm).
• Containment (red buttons) — Isolate host, Block IP / domain, Disable account. Each asks you for the target (host, IP, or account) then submits the response runbook.
• Chain of custody — a hash‑linked, tamper‑evident timeline of evidence. A green verified badge means the evidence chain is intact; a red badge points to the sequence number where it broke. Each entry shows its kind, description, time, and a short hash.
• Work notes — type a note and click Add to record analyst commentary; notes are timestamped and attributed.

Use the agentic SOC helper (bottom of the page):

• The scorecards show counts of investigations, executions, and escalations, and whether the model runs locally (“air‑gap local”).
• To run an investigation: pick a Kind (triage / hunt / enrich), type a Prompt in plain English (e.g. “investigate the impossible‑travel alert for user jdoe”), and click Run investigation. The result shows the agent’s steps and a Conclusion; expand Raw plan for detail.
• Kill switch: if an agent is misbehaving, click Trip kill switch (you’ll confirm) to immediately halt all agent automation for your tenant. Click Reset to re‑enable. (Read‑only users don’t see these buttons.)

5.6 Detection hub

What it is: where detections are authored and their ATT&CK coverage is tracked. A detection is a rule that watches your event data and raises an alert (a finding) when it matches something suspicious. ATT&CK is a public catalog of attacker techniques (each has an id like T1059); “coverage” is how many of those you can detect.

When you’d use it: to see live alerts, tune rules, and close “blind spots.”

Presentation: bespoke screen with three tabs.

Tab 1 — Live findings (the real alerts):

1. Open Detection hub → Live findings.
2. Optionally filter by Severity.
3. Read the table: severity, detection name/rule, what it grouped by (for correlation rules), event count, and when it fired.
4. To turn a finding into a ticket, pick a target under Escalate to (a configured ITSM connector — see Integrations) and click Escalate on that row. If no connector exists you’ll be told to add one first.

Tab 2 — Engine rules (manage the detection logic):

• Click Install starter pack to load a set of ready‑made rules.
• Add rule (JSON): paste a rule as a condition tree (AND/OR/NOT over field checks, with optional windowed correlation) and click Save rule. The placeholder shows the exact shape.
• Import Sigma rule: Sigma is an industry‑standard YAML format for detections. Paste a Sigma rule and click Import Sigma; unsupported syntax is reported rather than mis‑imported.
• Delete removes a rule (it stops evaluating new events).

Tab 3 — Detection library (lifecycle):

• New detection — give it an id/name, an ATT&CK technique (e.g. T1059), a log source, and a condition; it starts as draft.
• Coverage chips show each technique as detected (green), mitigated, or blind (red).
• In the table, Advance moves a detection through its lifecycle (draft → dry‑run → canary → deployed) and Retire takes it out of service (confirm first). Dry‑run means it runs without alerting so you can measure it; canary means it’s live for a small slice first.
• Efficacy shows true‑positives / false‑positives so you can judge quality.

5.7 CTEM / exposure

What it is: CTEM = Continuous Threat Exposure Management — continuously finding and prioritizing your weaknesses (vulnerabilities and exposed services) and understanding how an attacker could chain them to reach your most valuable assets (“crown jewels”). It includes BAS/validation (Breach‑and‑Attack Simulation — safely testing whether a technique would work).

When you’d use it: to run a vulnerability assessment, review open exposures, or map an attack path.

Presentation: bespoke screen with five tabs.

Run a vulnerability assessment:

1. Open CTEM / exposure → Vulnerability assessment.
2. In Scope, click chips to pick which Segments, Groups, and Targets to assess, and optionally which Attack vectors. Leaving scope empty means “the whole estate.”
3. Click Run assessment.
4. Read the Executive summary: number of findings by severity, an exposure score /100, peak CVSS (the standard 0–10 vulnerability severity score), and the top risk. Charts break findings down by severity, segment, service, and criticality.
5. Scroll to Detailed findings (each with CVE, CVSS, asset, service, whether it’s exploitable, and a recommendation) and Recommendations (grouped remediation guidance).
6. Export with Export PDF (uses your browser’s print‑to‑PDF) or Export Excel (CSV).

Other tabs:

• Exposures — the current open exposures across the estate, with charts and a table (read‑only overview).
• Attack paths — pick a Source (attacker entry) and Destination (empty = your crown jewels), optionally choose vectors, and click Compute attack path. If a path exists, you see the hop‑by‑hop route (with the CVE/technique used at each step) and a “hops to crown jewel” badge; otherwise “No path found.”
• Assets & scope — the inventory of assets, segments, groups, and how many are crown jewels.
• CVE feed — pull vulnerability data from a live source (NVD or OSV) by entering a service/keyword and clicking Fetch feed, or, for offline/air‑gapped sites, paste an exported feed and click Import entries. (Air‑gapped installs block live internet fetches by design.)

5.8 Data lake, intel & SOAR

What it is: three related tools:

• Security data lake — a big store of normalized security events you can search (federated search = one query across multiple sources). Events use the OCSF open schema.
• Threat intel — indicators of compromise (IOCs — e.g. a bad domain or IP) using the STIX/TAXII standards.
• SOAR — Security Orchestration, Automation & Response — cases and playbooks (this overlaps with the SOC screen).

When you’d use it: to hunt across raw event data, browse threat intel, or ingest data/indicators.

Presentation: bespoke screen.

Search the lake:

1. Open Data lake, intel & SOAR.
2. In the search card set a Region, an event class number (optional), and a limit, then click Run.
3. Results appear as a table (time, class, severity, message, region). The sources that answered are listed as chips. If a search fails, the reason is shown rather than a silent empty table.

Browse threat intel: the Indicators table auto‑loads the default collection’s IOCs (pattern and confidence).

Data operations (advanced):

• Ingest an event (OCSF) — set source/region, paste a JSON event, click Ingest event.
• Submit threat indicators (STIX bundle) — paste a STIX bundle JSON, click Submit indicators; it reports how many are active.
• CACAO playbook interchange — CACAO is a standard playbook format. Paste a playbook and Export → CACAO, or paste a CACAO bundle and Import CACAO.

5.9 Threat Analytics

What it is: behavioral and operational analytics over your real telemetry. This domain bundles several powerful lenses. Presentation: generic operation panels (one card per capability — read cards auto‑load; write cards have a small form and a Run button).

Here’s each capability, in plain language, and how to use it:

• UEBA — ranked entity anomaly scores. UEBA = User and Entity Behavior Analytics: it learns what “normal” looks like for each host/user and scores how abnormal recent behavior is. The entities panel auto‑loads a ranked list (highest anomaly first). To refresh the analysis, run UEBA scan (click Run on the scan card; the sample body is empty {} — just run it). View saved anomalies in the anomalies panel. Read it: higher score = more unusual = worth a look.
• ITDR — identity‑threat signals. ITDR = Identity Threat Detection & Response: watches for identity‑based attacks (e.g. impossible travel, credential abuse). The signals panel auto‑loads live signals; ITDR scan persists fresh detections.
• Correlation — group signals into incidents. Run Correlate signals into incidents ({} body, click Run) to cluster related alerts/anomalies into a single incident, then view them in Correlated incidents. Why: it reduces alert noise by showing one incident instead of many scattered signals.
• Posture score. The Security posture score panel auto‑loads a grade of your overall security hygiene. Snapshot posture records the current score so you can track the trend over time.
• Risk portfolio (ALE $). ALE = Annualized Loss Expectancy — the estimated dollars you’d lose per year from a risk. The portfolio panel auto‑loads your quantified risks in dollars. To model a new one, use Add a risk scenario: fill name, asset_value (what’s at stake), threat_freq (how often the threat occurs per year, e.g. 0.5), and vuln (how likely it succeeds, 0–1), then Run.
• SIEM hub. SIEM = Security Information and Event Management — the classic “all alerts in one place.” The overview and alerts panels auto‑load an aggregated view and a unified alerts feed.
• AIOps — operational anomaly health. AIOps watches the health/operations side (performance and reliability anomalies) rather than security. The health panel auto‑loads; AIOps scan refreshes it.

Typical use: start with UEBA entities to spot the most anomalous host, check ITDR signals for identity angles, run Correlation to bundle related signals into an incident, and glance at Posture score and Risk portfolio for the big picture.

5.10 Deception

What it is: honeytokens (decoys) and their tripwires. A honeytoken is a fake credential/file/record that no legitimate user should ever touch — so any interaction with it is a strong signal that someone is snooping. A trip is a recorded hit on a decoy.

When you’d use it: to plant decoys in sensitive spots and to review trips (high‑signal alerts).

Presentation: generic operation panels.

Plant a honeytoken:

1. Open Deception.
2. On Plant a honeytoken, fill name (e.g. decoy-cred), kind (e.g. credential), and placement (e.g. vault).
3. Click the action button. The new token appears in List honeytokens.

Review trips: the Trip event feed shows hits. Because decoys are never touched legitimately, treat any trip as suspicious and investigate (open a case, check the source IP). There’s also a Report a tripwire hit panel to log a trip manually (token + source IP).

5.11 Detonation

What it is: a sandbox for suspicious files/URLs. Detonation means opening a sample in a safe, isolated environment to watch what it does and get a verdict (malicious / suspicious / benign), so you never run it on a real machine. The provider is pluggable; there’s a built‑in simulation for testing.

When you’d use it: you have a suspicious attachment, download, or link and want to know if it’s dangerous.

Presentation: generic operation panels.

Submit a sample:

1. Open Detonation.
2. On Submit a sample for detonation, put a reference to the sample in sample_ref (e.g. a URL like https://…/payload.bin).
3. Click the action button. A job is created.

Read the verdict: open Detonation jobs + verdicts to see submitted jobs and their results. The Configured sandbox provider panel tells you which sandbox is in use.

5.12 Digital Risk

What it is: DRP = Digital Risk Protection — monitoring the outside world for threats to your brand and domains (e.g. typosquatting — lookalike domains like acme‑support.com — phishing pages, or leaked data). Findings come from your DRP feed.

When you’d use it: to track what assets are watched and review external findings.

Presentation: generic operation panels.

Register a monitored asset:

1. Open Digital Risk.
2. On Register a monitored asset, set kind (e.g. domain) and value (e.g. acme.com). Run.

Review findings: the DRP findings panel lists external issues (category like typosquat, with severity). There’s also an Ingest a finding panel to add one from your feed (asset, category, severity). Monitored assets lists what’s currently watched.

Estate Management

5.13 Estate plane

What it is: your estate — the inventory of machines (“targets”) you protect — plus the safe ways to reach them. Key ideas:

• PAM = Privileged Access Management: storing and injecting privileged credentials without ever exposing the secret.
• Brokered session = a mediated, recorded connection to a target. You never hold the password; the platform injects it, records everything, and you can verify the recording.
• Policy packs, fan‑out, and a kill‑switch let you act across many machines at once.

When you’d use it: to enrol machines, store credentials, open a recorded session and run a command, or halt everything in an emergency.

Presentation: bespoke, tabbed screen. Tabs: Targets, Credentials, PAM connectors, Agents, Topology, Capabilities, Host keys, Break‑glass, Advanced.

Enrol a target (Targets tab):

1. Open Estate plane → Targets.
2. Click + Enrol target.
3. Fill Hostname and Address (IP/FQDN) (required), then optionally ID, OS, Criticality (low → crown jewel), Group, Region, Owner, Channels (e.g. ssh, winrm), and Tags.
4. Under Credentials, tick any existing credential objects to bind.
5. Click Enrol target. It appears in the table. The stat tiles show totals, crown jewels, and any with configuration drift.

Create a reusable credential (Credentials tab): because secrets are injection‑only (never shown again), you create a credential object once and bind it to hosts.

1. Go to Credentials.
2. In New credential object, give it a Credential ID (name), pick a Credential source (Platform vault, or an external PAM like CyberArk / HashiCorp Vault / Delinea / AD‑LDAP), a Type (SSH key, SSH certificate, password, client cert), and a Username.
3. For a platform‑vaulted secret, paste the key/password/cert into the secret box (it’s write‑only). For an external PAM, you only provide a reference — the secret never leaves your vault.
4. Click Vault credential (or Link credential). It joins the Credential library and can be bound to hosts.

Open a brokered session and run a command:

1. On the Targets tab, click a target row to open its detail drawer.
2. In Brokered session, choose a Protocol (ssh/winrm/rdp/api) and a bound Credential, then click Open session. You’ll see confirmation that the session is opened and recorded.
3. Type a Command (e.g. uptime) and click Run; the output appears below.
4. Click Verify recording to confirm the session recording’s integrity — a green “Recording chain valid ✓” means the tamper‑evident record is intact.

Emergency stop (kill switch): on the Targets tab, click Kill switch, then Confirm to halt all estate actions. A red “Kill switch tripped” badge confirms it. (Managers only.)

Other tabs at a glance:

• PAM connectors — configure how the broker reaches an external vault (endpoint + sealed auth). Credentials whose source matches a connector are resolved through it at session time.
• Agents — for hosts that can’t accept inbound connections, enrol a pull agent. Enter the target id, click Issue token, and copy the token shown once — configure the host’s agent with it.
• Topology — a visual graph of control plane → zones → targets.
• Host keys — the pinned SSH/NETCONF fingerprints (trust‑on‑first‑use). A changed key is refused as a possible man‑in‑the‑middle; only Reset a pin when a host was legitimately re‑keyed (you’ll confirm).
• Break‑glass — request time‑boxed emergency privileged access to one target under M‑of‑N approval (several people must approve). Fill target, justification, TTL, and required approvals, then Request access; approvers click Approve.
• Advanced — the raw credential/pack/fan‑out operation panels.

5.14 OT / ICS

What it is: read‑only visibility into OT/ICS — Operational Technology / Industrial Control Systems, i.e. the computers that run physical processes (factory PLCs, sensors). These are grouped into Purdue zones — a standard model that layers an industrial network from the plant floor (zone 0/1) up to business systems (zone 4/5). USCP only watches OT; it never controls it.

When you’d use it: to see your OT asset inventory and its safety posture.

Presentation: generic operation panels.

• OT asset inventory — auto‑loads the assets discovered via sensors.
• Purdue‑zone rollup — auto‑loads assets grouped by zone.
• Read‑only safety posture — auto‑loads the current safety view.
• Ingest an OT asset / Seed simulated OT assets (UAT) — for feeding in sensor data or seeding demo data for testing (UAT = User Acceptance Testing).

Read it: zones help you confirm that plant‑floor devices aren’t unexpectedly reachable from higher, business layers.

5.15 Fleet & Provisioning

What it is: managing groups of enforcement points (“fleets”), zero‑touch provisioning (ZTP) — handing out enrollment tokens so new devices can join automatically — and data‑sovereignty topology (which region your data lives in).

When you’d use it: to organize fleets, mint enrollment tokens, or pin data residency.

Presentation: generic operation panels.

• List fleets auto‑loads; Create a fleet takes a name and tags.
• Mint an enrollment token — set a name, TTL (hours), max uses, and a template, then Run. List enrollment tokens shows existing ones.
• Sovereign topology + residency — view the region/residency map; Pin data residency sets a region (e.g. eu).

Governance & Trust

5.16 Policy plane

What it is: two policy surfaces:

• Host firewall — manage each target’s firewall rules (iptables on Linux, Windows Defender Firewall on Windows) like a firewall console.
• Access control (RBAC/ABAC) — the rules engine deciding who may do what. RBAC = Role‑Based Access Control (by role); ABAC = Attribute‑Based (by attributes/context). Publishing a policy needs a two‑person approval.

When you’d use it: to add/adjust firewall rules on a host, or to draft/simulate/publish access policies.

Presentation: bespoke screen with two tabs.

Manage a host firewall:

1. Open Policy plane → Host firewall.
2. Pick a Target from the dropdown. The table shows the managed policy (your desired rules).
3. Click Read live rules to see what’s actually on the host right now, or Import from host to replace the managed set with the host’s real rules.
4. Click + Add rule. In the editor set Action (allow/deny/reject), Direction, Protocol, Port/range, Source/Destination (CIDR), and a Comment; click Add rule.
5. In the table, toggle a rule on/off with its switch, or use Edit / Duplicate / Delete. Rules evaluate top‑to‑bottom; disabled rules are kept but not enforced. Changes push to the host over the brokered channel.

If you have no targets yet, this tab tells you to enrol a host in Estate → Targets first.

Access control (RBAC/ABAC) tab — generic operation panels: List policies, Create/draft a policy (name, effect allow/deny, actions, resources), Approve & publish (a second approver’s email — the two‑person rule), and Simulate a decision (enter a subject’s roles, an action, and a resource to see whether it would be allowed — a safe “what‑if”).

5.17 Audit & evidence

What it is: the tamper‑evident audit chain (every action is hash‑linked so tampering is detectable), a recent privileged‑activity timeline, and the evidence locker for auditors.

When you’d use it: to verify the audit log is intact, review recent sensitive actions, or (as an auditor) pull compliance evidence.

Presentation: bespoke screen.

Verify the audit chain:

1. Open Audit & evidence.
2. The Audit chain card shows a green verified badge (intact) or a red broken @ N badge (tampering detected at sequence N), plus the record count. Click Refresh to re‑check.
3. The Recent activity table lists sequence, time, actor, and action. Sort or Export it (audit-events).

Evidence locker (auditors): at the bottom. If you hold the auditor role you’ll see compliance controls (with freshness in days) and one‑click framework exports — click a framework button (e.g. CAIQ, SIG, CCM, 800‑53, OSCAL) to download an evidence bundle as JSON. If you don’t have the auditor role, a note explains it’s required — that’s expected, not an error.

5.18 Lockbox & HYOK

What it is: Customer Lockbox lets you approve or deny any request for the vendor/support to access your data (nothing happens without your yes). HYOK = Hold‑Your‑Own‑Key: encryption keys stay under your control so the vendor cannot decrypt your data without your grant.

When you’d use it: to review and decide access requests and to confirm your key posture.

Presentation: bespoke screen.

1. Open Lockbox & HYOK.
2. The HYOK key status card shows a green enabled or red disabled badge.
3. In the requests table, a pending request offers Approve and Deny buttons (Deny asks you to confirm). Approved/denied requests show a status badge. (Read‑only users see the list but not the buttons.)

5.19 SLA & private trust

What it is: monthly SLA reports (Service Level Agreement — the uptime/performance you’re promised) that are hash‑chained (tamper‑evident), plus a private trust portal.

When you’d use it: to review availability vs target and any SLA credits owed.

Presentation: bespoke screen.

1. Open SLA & private trust.
2. Click Generate SLA report to produce the latest period (optional).
3. Read the table: period, module, availability % (green if it met the target, red if not), target %, p99 latency, and any SLA credit % owed. Export as sla-reports.

5.20 Privacy & DSAR

What it is: DSAR = Data Subject Access Request — your legal right to get a copy of your data or have it erased. This screen acts on your own account.

When you’d use it: to export everything the platform holds about you, or to erase your account.

Presentation: bespoke screen.

• Export my data — click it to download a JSON file (dsar-export.json) of your data.
• Erase my data — click it, then confirm in the dialog. This permanently deletes your identity, sessions, passkeys, and role assignments, signs you out, and is irreversible (audit entries are retained under a legal exemption). Use with care.
• Request register — a table of past export/erasure requests (subject masked, kind, status).

5.21 Hardening & Drift

What it is: keeping configurations correct and sharing defensive intel. It includes:

• Config‑drift detection — capture a “golden” baseline of a target’s config, then detect when it drifts (changes) from it.
• Telemetry routing — rules for where events go.
• Collective defense — optionally share threat indicators (IOCs) with a trusted pool, using privacy‑preserving techniques.
• Policy twin — a “digital twin” to test policy changes safely before applying them (what‑if / regression).

When you’d use it: to baseline and check configs, evaluate routing, opt in/out of IOC sharing, or simulate a policy change.

Presentation: generic operation panels.

• Capture a config baseline — provide a target and its config, Run.
• Check current config vs baseline — provide the target and current config; the result shows any drift. Drift events auto‑loads past drifts.
• Telemetry routing rules auto‑loads; Evaluate an event’s routing shows where a sample event would go.
• Collective‑defense status auto‑loads; Opt in/out of IOC sharing toggles participation (opted_in true/false); Query the shared IOC pool returns shared indicators.
• Policy what‑if / regression — provide grants and scenarios to confirm a policy behaves as expected before you ship it.

Platform

5.22 Licensing & updates

What it is: your entitlement (“license”) posture and signed product updates. Entitlement = which capabilities your plan includes. If a license lapses, gated features fail closed (stop working) — so this screen warns you early.

When you’d use it: to check license state/expiry, see licensed modules, review usage metering, and (managers) apply signed updates.

Presentation: bespoke screen. Most controls are read‑only for everyone; applying updates and activating continuity are manager actions.

• Entitlement state — mode, state (green active or red), watermark, and expiry with a countdown badge (green with days left, amber when ≤30 days, red when expired).
• Licensed modules — chips of what you’re entitled to.
• Continuity & escrow — whether vendor‑continuity/escrow is configured and active (a safeguard if the vendor becomes unreachable). Managers can Activate continuity… by pasting a signed bundle and listing ≥2 approver emails (dual‑control).
• Usage & metering — a tamper‑evident, hash‑chained record of your usage (with a chain verified badge) for reconciliation/billing disputes.
• Signed updates — click Check for updates. Available updates list module, current→target version, and severity. Managers can Dry‑run (preview) or Apply each; a “breaking” badge warns of breaking changes.

5.23 Access control (IAM) (managers only)

What it is: the IAM (Identity & Access Management) admin center — login methods, MFA policy, local accounts, identity providers, sessions, tokens, and access rules. Presentation: bespoke, tabbed screen. Even if you’re not an admin, two tabs here matter to every user, so they’re highlighted below.

Tabs: Login methods, Local accounts, Identity providers, SSO role mapping, External auth, Service tokens, Active sessions, Access rules, Break‑glass.

• Login methods — turn SSO / local accounts on or off and choose the Required MFA (WebAuthn passkey / TOTP / email code / either / none‑not‑recommended). At least one login method must stay enabled.
• Local accounts — create a local user (username, email, ≥8‑char password, roles) and Enrol TOTP for it (this is the authenticator‑app enrolment from Part 2.3). You cannot assign a toxic role combination — the SoD engine blocks it here.
• Identity providers — register your enterprise OIDC and SAML IdPs; users are routed by email domain. Client secrets are sealed and never shown back. For SAML, the SP metadata/ACS URL to register at your IdP is displayed.
• SSO role mapping — map an IdP group or email domain to a USCP role for just‑in‑time provisioning; a Default rule applies when nothing else matches (otherwise new SSO users get operator).
• External auth — authenticate users against Active Directory (LDAP) or RADIUS; the bind credential is a PAM reference, not a stored secret.
• Service tokens — mint non‑interactive machine credentials (name, role, scopes, expiry). The plaintext token is shown once — copy it immediately. Rotate issues a replacement; Revoke kills it.
• Active sessions (useful to everyone with access here) — see every signed‑in session in the tenant (user, signed‑in/last‑seen/expiry, MFA). Revoke a suspicious session, or Sign out my other sessions to end all of your sessions except this one. Your current session is flagged and can’t be self‑revoked here.
• Access rules — optionally turn on fine‑grained RBAC (extra per‑role action:resource checks). It can only further restrict access, never grant more. Edit a role’s permissions as JSON, or Reset to defaults.
• Break‑glass — provision M‑of‑N sealed recovery codes for emergency admin access if your IdP is unreachable. Codes are shown once; store them offline, split among trusted people.

5.24 Logs & Flows (Observability)

What it is: deep search over collected syslog and Windows event logs, network flow records (who talked to whom), and a live communication topology map. Presentation: bespoke, tabbed screen. Tabs: Log search, Flows, Communication topology, Collectors.

Search logs:

1. Open Logs & Flows → Log search.
2. Set a time range (From/To, or the quick 1h / 6h / 24h buttons).
3. Type a Keyword (e.g. Failed password, 4625, UFW BLOCK) and optionally filter by Host, Severity, Source (syslog/winlog).
4. Click Search. You get stat tiles (matches, critical/error/warning counts), a Volume over time chart, and a results table. Click a row to open its full detail.
5. Save your current filters as a reusable Saved view with + Save; click a saved view’s name to re‑apply it.

Flows — filter by protocol/host/range to see connection records (source → destination, protocol/port, bytes, allow/deny) with charts. Communication topology — a graph and matrix of who talks to whom. Collectors (managers) — configure external log destinations (Syslog, Splunk HEC, HTTPS, OpenTelemetry, S3, Kafka) to forward events; per‑collector delivery health is shown.

Some panels may show a “sample data” badge when demonstrating with generated data rather than live telemetry — that’s clearly labelled.

5.25 Capability catalog

What it is: the full §53 capability matrix — every licensable feature (“capability”), its availability (GA = Generally Available, Beta = preview, Planned = roadmap), data classification, SLO class, whether it’s air‑gap‑ready and multi‑region, plus a signed Marketplace of installable packs/modules.

When you’d use it: to confirm what your tenant can do and to browse marketplace content.

Presentation: bespoke screen. Stat tiles summarize totals (GA/Beta/Planned/air‑gap‑ready). Use the availability filter chips to narrow the table. The Marketplace table lists signed modules with a content hash.

5.26 Analytics

What it is: an interactive way to count your security data by a dimension over time (like a pivot table). Presentation: bespoke screen.

1. Open Analytics.
2. Pick a Dataset (e.g. findings), a Dimension to group by (e.g. severity), and an Interval (hour/day/week).
3. Click Run.
4. See a donut By <dimension>, a Totals table, and a Time series table. Export any table to CSV.

5.27 API Explorer

See Part 3.7 — the built‑in, read‑only API browser/tester.

5.28 System health

What it is: a live status page for the platform itself — component checks with latency, an overall banner, build/runtime info, and cryptography posture. Presentation: bespoke screen.

1. Open System health (under Platform).
2. The banner reads “All systems operational” or “Degraded.” Component rows show API server, liveness, database+migrations, and licensing — each Operational/Down with latency. Click Re‑check to refresh.
3. Build & runtime shows version/revision/region. Cryptography & assurance shows FIPS mode, post‑quantum readiness, and the algorithm manifest (informational).

5.29 Public & self‑serve (Trust portal)

What it is: the public‑facing trust/status view — live status, certifications, and a capability summary. Presentation: bespoke screen (mostly read‑only). Open Public & self‑serve to see the suite status badge, component chips, a GA/Beta/Planned capability summary, and certification chips.

5.30 Release & Supply Chain

What it is: software supply‑chain transparency — release channels, self‑hosted release parity, signed‑release verification, the API contract registry, competitor‑config import, and data‑ops snapshots. Presentation: generic operation panels.

• Release channels / parity / pack auto‑load your release posture.
• Verify a signed release — paste a digest, signature, and public key to confirm a build is authentic.
• API contract registry auto‑loads.
• Import a competitor config — migrate rules from another product (e.g. Splunk searches) by pasting items.
• Data‑ops export snapshot — request an export snapshot ({} body, Run).

5.31 Suite & MSP

What it is: features for MSPs (Managed Security Service Providers) and multi‑suite deployments — managing customer tenants, a co‑managed SOC view, cross‑suite routing, air‑gap bundles, module hot‑reload, and the shared audit pipeline. Presentation: generic operation panels.

• MSP — managed tenants auto‑loads; add a managed tenant takes a tenant id and scope.
• Co‑managed SOC view, Cross‑suite routing table, Air‑gap update bundles, Shared audit pipeline posture, and Module registry auto‑load.
• Upsert a suite route and Register a module bundle are write panels for advanced/admin configuration.

Part 6 — Common workflows / recipes

These stitch the areas above into end‑to‑end tasks you’ll actually perform.

6.1 Investigate a suspicious host end‑to‑end

1. Spot it: open Threat Analytics → UEBA entities. Note the host with the highest anomaly score.
2. Corroborate: check ITDR signals for identity angles on that host/user, then run Correlation → Correlate signals into incidents and open Correlated incidents to see if the signals cluster into one incident.
3. Dig into logs: open Logs & Flows → Log search, filter by that Host over the last 24h, and search for suspicious keywords (e.g. Failed password, a process name). Save the view.
4. Test a sample: if you found a suspicious file/URL, open Detonation → Submit a sample, paste its reference, then read the verdict under Detonation jobs.
5. Open a case: in Agentic SOC, create a case (title + severity). In the case drawer, add work notes, move it to investigating, and if warranted use Containment → Isolate host.
6. Verify actions: open Audit & evidence and confirm your actions appear in the timeline and the chain is verified.

6.2 Respond to a deception trip

1. Open Deception → Trip event feed. A trip means someone touched a decoy — treat it as real.
2. Note the source IP and token.
3. In Logs & Flows, search that source IP to see what else it touched.
4. In Agentic SOC, open a case (severity high), and use Containment → Block IP / domain and/or Disable account as appropriate.
5. Record findings in the case work notes and move it through its lifecycle.

6.3 Run a posture review

1. Open Threat Analytics → Security posture score; note the grade, then Snapshot posture to record the trend.
2. Open CTEM → Vulnerability assessment, set scope (or leave empty for the whole estate), and Run assessment. Review the exposure score, top risks, and recommendations; Export PDF for stakeholders.
3. Open Detection hub → Detection library and address any blind ATT&CK techniques by authoring/advancing detections.
4. Check Overview for open critical/high cases and SLA breaches.

6.4 Check your risk portfolio (in dollars)

1. Open Threat Analytics → Quantitative risk portfolio; it auto‑loads your risks with their ALE ($).
2. To model a new risk, use Add a risk scenario: set name, asset_value, threat_freq (events/year), and vuln (0–1 likelihood of success), then Run.
3. Re‑open the portfolio panel (or Refresh) to see the updated dollar figures, and use them to prioritize spending.

6.5 Verify an audit record

1. Open Audit & evidence.
2. Confirm the Audit chain shows a green verified badge (click Refresh to re‑verify). A red broken @ N badge means the log was tampered with at record N — escalate immediately.
3. Find the action in the Recent activity table (sort by time or search). Export the events if you need them for a report.
4. Auditors: pull framework evidence from the Evidence locker with the one‑click export buttons.

6.6 Escalate a detection finding to a ticket

1. Open Detection hub → Live findings.
2. Ensure an ITSM connector exists (Integrations → ITSM — ServiceNow/Jira). If not, ask an admin to add one.
3. Pick the connector under Escalate to, then click Escalate on the finding’s row. The ticket reference is shown.

Part 7 — Glossary

• ABAC — Attribute‑Based Access Control. Access decided by attributes/context (department, device, time), not just role.
• AIOps — AI for IT Operations. Detects performance/reliability anomalies (the health side, not security).
• ALE — Annualized Loss Expectancy. Estimated money lost per year from a given risk.
• ATT&CK — MITRE ATT&CK, a public catalog of attacker techniques (each has an id like T1059). “Coverage” = how many you can detect.
• Auditor (role) — read‑only user who also gets the compliance evidence locker.
• BAS — Breach‑and‑Attack Simulation. Safely testing whether an attack technique would succeed.
• Break‑glass — emergency access under strict, audited controls for when normal login is unavailable.
• Brokered session — a mediated, recorded connection to a machine where the platform injects the credential so you never see it.
• CACAO — a standard format for security playbooks.
• CIDR — a way to write a range of IP addresses, e.g. 10.0.0.0/8.
• Command palette — the ⌘K/Ctrl+K search box to jump anywhere in the console.
• Correlation — grouping many related signals/alerts into a single incident to cut noise.
• Crown jewel — your most valuable/critical asset.
• CTEM — Continuous Threat Exposure Management. Continuously finding and prioritizing weaknesses.
• CVE — a public identifier for a specific known vulnerability (e.g. CVE‑2021‑44228).
• CVSS — Common Vulnerability Scoring System, a 0–10 severity score for a vulnerability.
• Detection / finding — a rule that watches events (detection) and the alert it raises (finding).
• DRP — Digital Risk Protection. Monitoring the outside world (brand, domains, leaks) for threats.
• DSAR — Data Subject Access Request. Your right to export or erase your personal data.
• Drift — when a system’s configuration changes away from its approved “golden” baseline.
• Entitlement / license — which capabilities your plan includes. Gated features “fail closed” if the license lapses.
• Estate / target — the set of machines you protect (estate); one such machine (target).
• Federated search — one query that runs across multiple data sources at once.
• Honeytoken — a decoy credential/file/record; any interaction with it is a strong intrusion signal.
• HYOK — Hold‑Your‑Own‑Key. You keep the encryption keys, so the vendor can’t decrypt your data without your grant.
• IAM — Identity & Access Management. Managing who can log in and what they can do.
• ICS / OT — Industrial Control Systems / Operational Technology. Computers that run physical processes.
• IdP — Identity Provider. Your company’s login system (Okta, Entra ID, Google, etc.) used for SSO.
• IGA — Identity Governance & Administration. Ensuring correct access and no toxic combinations.
• IOC — Indicator of Compromise. A piece of evidence of an attack (a bad domain, IP, file hash).
• ITDR — Identity Threat Detection & Response. Detecting identity‑based attacks.
• ITSM — IT Service Management (ServiceNow, Jira). Where tickets are filed.
• JSON — a text format for structured data used in some form fields; keep brackets/quotes intact.
• Kill switch — a control that instantly halts automated actions (SOC agents, or estate actions).
• Lockbox (Customer Lockbox) — you approve/deny any vendor access to your data.
• M‑of‑N — an approval rule where M out of N designated people must approve.
• MFA — Multi‑Factor Authentication. Proving identity in two ways (e.g. email + passkey).
• MSP — Managed Security Service Provider. A company that runs security for other organizations.
• OCSF — Open Cybersecurity Schema Framework. A common format for security events.
• OIDC — OpenID Connect. A modern SSO protocol.
• OTP / one‑time code — a short code valid once, briefly (emailed or from an authenticator app).
• PAM — Privileged Access Management. Storing/injecting privileged credentials without exposing them.
• Passkey / WebAuthn — sign in with your device’s fingerprint/face/PIN or a security key instead of a code.
• Playbook — a pre‑built sequence of response steps (SOAR).
• Posture score — a grade of your overall security hygiene.
• Purdue zone — a model layering an industrial network from the plant floor up to business systems.
• RADIUS / LDAP (AD) — standard directory/authentication systems for validating users.
• RBAC — Role‑Based Access Control. Access decided by your role.
• SAML — an older SSO protocol still widely used (ADFS, etc.).
• SCIM — a standard for auto‑provisioning user accounts from an identity system.
• SIEM — Security Information and Event Management. Central alert/event aggregation.
• SLA — Service Level Agreement. The uptime/performance you’re promised (with credits if missed).
• SoD — Separation of Duties. No single person should hold conflicting powers.
• SOAR — Security Orchestration, Automation & Response. Cases + playbooks + automation.
• SOC — Security Operations Center. The team/screen that watches for and responds to threats.
• SSO — Single Sign‑On. Logging into USCP via your company’s identity provider.
• STIX / TAXII — standards for describing (STIX) and sharing (TAXII) threat intelligence.
• Tenant — one isolated organization’s workspace in the platform.
• TOTP — Time‑based One‑Time Password, the rotating 6‑digit authenticator‑app code.
• Typosquatting — registering lookalike domains to impersonate a brand.
• UEBA — User and Entity Behavior Analytics. Scores how abnormal a host’s/user’s recent behavior is.
• ZTP — Zero‑Touch Provisioning. Devices join automatically using issued enrollment tokens.

Part 8 — FAQ & self‑service troubleshooting

“I can’t see a menu item that a colleague has.” Almost always your role. Manager‑only areas (Tenants, Policy plane, Identity, Access control) are hidden from viewer/auditor users. Some action buttons (create, delete, kill‑switch) are also hidden for read‑only users. If you truly need access, ask an admin to adjust your role. You can confirm your role in the top bar (hover your email) or via Identity & session → Who am I.

“I got ‘Not licensed’ / ‘License required’ (HTTP 402).” That capability isn’t in your tenant’s current entitlement bundle. It’s not a bug and not a permissions issue — the feature simply isn’t enabled for your plan. Check Licensing & updates for your licensed modules, and ask your administrator if you need it added.

“I got ‘Access denied / Not permitted for your role’ (HTTP 403).” Your role can’t perform that action (deny‑by‑default). Read‑only users see this for write actions. Ask an admin if you need elevated access. The message often includes the specific reason.

“I got ‘Not signed in’ or was bounced to the login page.” Your session expired or ended. Simply sign in again (Part 2) and continue where you left off. This is normal after a period of inactivity.

“A form field shows an error like ‘… is not valid JSON.’” A JSON field must be well‑formed. Start from the pre‑filled example, change only the values, and keep all braces {}, brackets [], quotes ", and commas intact. Don’t leave a trailing comma. The panel names the exact field that’s wrong and won’t send anything until it’s fixed.

“The page says ‘Network error — is the control plane reachable?’” The console couldn’t reach the server. Check your internet/VPN connection and try again; use Retry where offered, or check System health.

“A table is empty / a search returned nothing.” There may genuinely be no matching data in your selected time range or filters. Widen the range (e.g. the 24h quick button in Logs), clear filters, and search again. If a red message appears instead of an empty table, it’s explaining why (e.g. licensing) — read it.

“How do I export data?” Look for the Export CSV button above a table (downloads a spreadsheet‑friendly file). Some screens have dedicated exports: Audit (audit-events), CTEM (Export PDF / Excel (CSV)), Privacy (Export my data → JSON), SLA (sla-reports), and the Evidence locker framework buttons.

“I saw a ‘sample data’ badge.” Some observability views show generated demonstration data (clearly labelled) when live telemetry isn’t present. It’s not your real environment’s data.

“How do I switch language or theme?” Language: the dropdown in the top bar (English/Español). Theme, density, and text direction: Settings (Part 4).

“I need to end a session on another device.” If you have access to Access control → Active sessions, use Sign out my other sessions (ends all your sessions except the current one) or Revoke a specific one. Otherwise, ask an admin.

“A destructive button is red / asks me to confirm.” That’s intentional. Red buttons and confirmation dialogs guard actions like kill‑switches, deletes, erasure, and closing cases. Read the dialog and confirm only if you mean it. Press Esc to cancel.

“How do I report a bug?” See Part 9.

Part 9 — Getting help

USCP is designed so you can do your job without contacting support — but when you hit a genuine defect, use the built‑in bug reporter:

1. Click Report a bug in the top bar.
2. In the small pop‑up, type a short description of what happened and what you expected.
3. Click Send. This opens a pre‑filled support email that automatically includes helpful diagnostic context — the exact page (URL), your language, a timestamp, and your browser — so the support team can reproduce it. Click send in your email app.
4. Click Close to dismiss the pop‑up.

When to involve an administrator instead: your admin (someone with the admin/operator role) can help with things a user can’t self‑serve — changing your role, adding a capability/license, enrolling or resetting your MFA, creating your local account, configuring SSO/identity providers, adding integrations (Slack/PagerDuty/ITSM), and estate/policy changes. For everyday analysis, investigation, and response, everything you need is in this guide.

End of guide.