AiSOC v23.3.0

Security

• The enrichment service authenticates its callers, and the console's
  unauthenticated enrichment proxy is gone (GHSA-qf6m-hgwv-65f9). POST /enrich and /enrich/bulk ran behind no authentication, and two Next
  rewrites (/api/v1/enrichment/lookup, /api/v1/enrichment/bulk) made them
  same-origin reachable from any browser that could reach the console — an
  unauthenticated client could run enrichment lookups and spend the
  deployment's threat-intel provider quota (VirusTotal, AbuseIPDB, GreyNoise,
  …), and because the rate limiter was keyed on the request body's
  tenant_id, rotating that string minted a fresh bucket per request. The Go
  service now carries internal/tenantauth, a behaviour-identical port of
  the Python services' vendored tenant_scope contract: console HS256
  session tokens (alg-pinned, type=access, expiry, tenant claim) or the
  service token with a declared X-AiSOC-Tenant-ID, failing closed when
  neither is configured, with the same three-condition dev bypass. The rate
  limiter and cache are keyed on the authenticated tenant; a body naming any
  other tenant — or an arbitrary bucket-minting string — is refused. The two
  dead console rewrites were removed (nothing in the console calls them), and
  the real callers — fusion's fuse-time AlertEnricher, the investigator's
  enrich_ioc, the playbook enrich step, and the context bundle's
  threat-intel fetch — authenticate with the service token and the run's own
  tenant. Compose wires SECRET_KEY and the dev-bypass trio into the
  enrichment service like its Python siblings. Reported by naroSEC.

• Fusion POST /process no longer trusts the body's tenant_id
  (GHSA-qfvv-rf5p-6h69). The synchronous fusion entrypoint authenticated its
  caller but never intersected the submitted alert's tenant_id with the
  credential's scope, and required no role — so any logged-in user of any
  tenant, including viewer, could inject alerts into another tenant's live
  dedup/correlation/RBA state and register dedup fingerprints under the
  victim tenant, suppressing their real alerts. The route now resolves the
  tenant through scoped_tenant_or_403 (console claim, or the service
  token's declared X-AiSOC-Tenant-ID) and requires a role holding
  alerts:write, mirrored from the API's ROLE_PERMISSIONS and pinned by a
  drift test. The same contract now covers the sibling write routes:
  /ml/feedback (body tenant scoped + role-gated — cross-tenant feedback
  poisoned the ranker), /confidence/score (body tenant scoped),
  /ml/retrain (role-gated), and /dlq/replay refuses console sessions
  outright — its audited operator door is POST /api/v1/health/dead-letters/replay on the API, and the fusion-side route
  accepted any tenant's session with any role while bypassing the permission
  check and audit row. Reported by 1ceS1amese.

Added

• Cisco Secure Endpoint connector. cisco_secure_endpoint reads Cisco
  Secure Endpoint (formerly AMP for Endpoints) detections — threats,
  quarantines, exploit prevention, behavioural protection, indicators of
  compromise and threat hunting incidents — through GET /v1/events with
  HTTP Basic auth (#356). The region is a select over Cisco's three clouds
  (North America, Europe, Asia Pacific/Japan/China) rather than a URL, so the
  API key is only ever sent to a Cisco host. The window is read to the end
  through read_offset_pages at the documented 500-event maximum, with each
  following page built from the configured region rather than taken from
  metadata.links.next; the list is newest first, so a row pushed across a
  page boundary by an event recorded mid-read is dropped by its id. Only
  events Cisco rates with a severity are returned: policy updates, scans and
  installs carry none, and since these events are filed as OCSF 2001 Security
  Findings, which fusion promotes unconditionally, they would otherwise reach
  the queue as alerts; how many were skipped is logged as
  cisco_secure_endpoint.unrated_events_skipped. Severity keeps Cisco's Low,
  Medium, High and Critical, and Critical stays critical. Setup, regions
  and troubleshooting are on the new
  Cisco Secure Endpoint
  page.