Home brief
The one number that matters, and how it moved.
Open P1 and P2 findings, what changed since your last visit and where to look first — in thirty seconds. Hollow points mark runs whose coverage was incomplete.
—
Surface map ownership perimeter · exposure · worst severity
Do this next
What changed all changes ▸
Scanned surface
| Host | Evidence · why it is listed | Exposure | Ports | Findings | Top priority |
|---|
What you declared
Assistant
Ask about the attack surface in plain language. Answers are generated by Anthropic's Claude from this client's stored results; questions and the results the assistant reads are sent to Anthropic.
Trends
How this client's attack surface and risk moved, run over run.
Surface map core = the client · inside the perimeter = attributed (MEDIUM+) · outside = held, never contacted
Run over run
Attack surface matrix asset criticality × internet exposure — click a cell to open those assets
What changed this cycle
Findings by severity
Priority distribution
Risk matrix severity × internet exposure — where the attack surface concentrates
Top exposed assets ranked by CVSS × EPSS × exposure × criticality, KEV override
| Asset | Priority | Score | Top finding | CVE | Intel |
|---|
Assets
Declare what belongs to the client; everything discovered under it is listed here with its ownership confidence.
Add or import
One entry per line, or a CSV. apex = a discovery seed; host = an explicit asset.
On this portal, scope you add or remove takes effect after BCiso's next sync — before its next scan.
Read-only for your role: the declared scope is listed beside this panel.
Declared scope
Attack surface overview a bird's-eye of what the active attack surface looks like today
Attack surface matrix asset criticality × internet exposure — click a cell to filter the inventory
Inventory
| Host | Evidence · why it is listed · likelihood | Confidence | Exposure | IPs | Ports | Tech | Criticality | Status | Label | Quick actions | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Loading the inventory… | |||||||||||
Evidence is how sure we are an asset is real; confidence is whether it is yours; criticality is how bad a compromise would be. Keys: j k move · Enter opens · x selects · [ ] previous / next client.
Findings
Everything the last assessment confirmed on gate-cleared assets, ranked by real-world risk. Detection only.
How severity and priority are computed
Severity is the check's own rating of the weakness (the check's own template or TLS check). Priority (P1–P5) is what to fix first:
0.35·CVSS + 0.30·likelihood + 0.20·exposure + 0.15·criticality scaled to 0–100 — P1 ≥ 80 · P2 ≥ 60 · P3 ≥ 40 · P4 ≥ 20 · P5 below. Likelihood is the CVE's EPSS (probability of exploitation in the next 30 days) when the local mirror has it. A finding with no CVE — default login, exposed .git, weak TLS — has no EPSS, so it uses a severity-based stand-in, calibrated so that on an exposed asset of medium criticality a finding lands in its severity's tier; unknown is not zero. KEV (CISA, exploited in the wild) multiplies the score ×1.5 and floors the tier at P2. Informational findings are capped at P5: context never turns a fingerprint into a risk. Exposure and criticality come from the asset (see Assets); a criticality override applies on the next run.Risk matrix severity × internet exposure — the hot cells are the real attack surface
| Asset | Finding | Severity | Priority | Score | CVE | Likelihood · intel | Context | |
|---|---|---|---|---|---|---|---|---|
| Loading findings… | ||||||||
Click (or tap) a row for its score anatomy, intelligence and every location. Keys: j k move · Enter opens · x selects · ← → step the open sheet.
Changes
What moved between runs, grouped by the run that saw it.
Scan runs
Proof of execution for every scan — the tools, commands and output behind each verdict.
Run on demand one-off — the saved profile is not changed
Run history
| When | Verification | Trigger | Profile | Tools | Coverage | Assets | Findings | Duration |
|---|
Run detail
Select a run above.
Scan policy
How BCiso scans this client — depth, tools, limits and schedule, with its consequences beside the editor.
Users & clients
Who can see and change each client's surface — and BCiso's own SA accounts.
Everyone
People, by client
Every client and its people: owners run the client, analysts work the surface, viewers read. Only BCiso creates and removes people.
BCiso team · SA
BCiso's own logins — an SA account is the super admin of this installation; two-step and Microsoft are set on the BCiso accounts page.
| Name | Access | Status | Two-step | Added | Actions |
|---|
BCiso account activity
Who created, renamed, disabled or removed a BCiso account, and who set or sent a password. Kept here, never in a client's log.
| When | Who | What | Detail |
|---|
Team
| Name | Role | Status | 2-step | Added |
|---|
Two-step verification is required of everyone from the first sign-in. Only BCiso can exempt a person, with a reason, logged.
Leave the password empty for a one-time link, or set one to create the account now with a temporary password.
Microsoft sign-in
Which Microsoft directories may sign in as this client's people. Empty: no Microsoft sign-in — its people use a password.
Or by hand: the client's Entra admin center → Overview → Tenant ID. Several? Separate them with commas.
On: a person whose Microsoft user name is their ProtectU address links on their first Microsoft sign-in — nobody links by hand.
Integration key
Service key for integrations (SIEM, ticketing). Owner-level access to this client only.
—
BCiso accounts
The people at BCiso who sign in as the operator — every client, every setting.
People
| Name | Status | 2-step | Microsoft | Added | Actions |
|---|
Manage… opens one person's card — password, two-step, Microsoft, enabled — each action saying what it does and, if blocked, why.
Invite a colleague
A one-time e-mail link, valid 72 hours. No temporary passwords for BCiso accounts — the mailbox is the proof.
Audit log
Every change and every scan, attributed to the acting user, service key or scheduler.
| When | Actor | Action | Detail |
|---|---|---|---|
| Loading the audit log… | |||
MCP access
Connect your own approved AI assistant to your ProtectU results, read-only.
AI-assistant access to clients' stored results over MCP — off until you enable each client.
Who receives the data. The console's Assistant: answers are generated by Anthropic's Claude from this client's stored results; questions and the results the assistant reads are sent to Anthropic. Over MCP, the AI assistant a client or BCiso connects reads the results — that assistant's vendor receives what it reads. Enable a client only with its recorded consent.
Service
Connecting an assistant
Pick your application and follow its steps. If this service cannot accept it yet, send BCiso its name.
What a person does to connect their own assistant — per person, read-only, never a scan, scope, users or keys.
BCiso assistants
Your own assistant (Claude Code, Claude Desktop): one account reads every client you enabled below, read-only, and is named in the access log.
| Account | Status | Requests | Refused | Last request |
|---|
OAuth clients
AI connectors that sign a person in with their ProtectU password instead of a pasted key. Each is registered here first.
| Application | Client id | Redirect URIs | Type | Registered |
|---|
Clients
| Client | Plan | AI access | Assistant accounts | Last request | Requests |
|---|
Requests, refusals and last-request times come from the MCP access log (no requests logged yet), kept apart from each client's audit log.
Access requests
People who asked for access from the sign-in page — approve into a client, or block.
Awaiting your decision
Loading…
Decided
Board brief
One page for management: the bottom line, the numbers, and what to do next.