Cyber Security Operations · Gaborone · Southern Africa
info@augcyba.com  ·  Client portal →
Capability 01 / Xaelo

Automated triage & case orchestration.

Xaelo is our purpose‑built triage platform. It is the spine of our CSOC: it ingests, enriches, classifies and routes events through the appropriate analyst tier. Where commodity SOAR products demand months of integration work, Xaelo is shaped to our operating model from the ground up.

The platform runs as a small group of services behind authenticated, encrypted endpoints; access is mediated by the same Vault identity plane that governs the rest of our estate.

Bespoke Triage Enrichment Case routing
Xaelo triage engine Live
142
events / min
14.2 k
processed today
3
tier queues
Pipeline enrich → classify → route
Enrich
142/m
Classify
142/m
Route
84/m
Case in flight INC-2026-0142
family: credential-stuffing
0.92
Routed → Tier 2 queue
Tier routing last 1 h
Tier 1
64
Tier 2
18
IR
2
Capability 02 / Vault

Zero‑trust secrets & identity.

Our HashiCorp Vault deployment is the foundation of our identity model. Human access is mediated by Active Directory via LDAP; applications authenticate via AppRole with response‑wrapped SECRET_IDs. Database access uses dynamic credentials, scoped per‑application.

Every privileged operation is logged with a request identifier, source address and authenticated identity, and shipped to our SIEM. If audit logging fails, the platform fails closed.

LDAPS AppRole Dynamic DB creds HMAC audit SoD enforced

Identity model

DomainExamplesScope
Vault platform vault‑admin, vault‑operator, vault‑auditor Platform administration, KV, audit
CSOC operations csoc‑tier1, csoc‑ir, csoc‑engineer Tiered, secret/csoc/**
Applications fga‑app, sirp‑backend, soc‑triage AppRole, per-app KV + dynamic DB

Manager and Auditor roles are explicitly forbidden from overlapping - verified weekly.

Capability 03 / Tiko‑Ceemo

Real-Time Infrastructure Events Alerting.

Tiko‑Ceemo is our state‑change alerting service. It dispatches critical alerts over the Meta WhatsApp Business API and piggy‑backs over the WhatsApp messaging tunnel, improving the movement of the traffic. Alerts fire only on state transitions, which keeps the channel meaningful and within WhatsApp’s policy envelope, and minimises data‑costs to engineering and technical staff.

The implementation supports multiple recipients, runs against a temporary or permanent system‑user token, and is ready for an optional webhook to receive delivery status and replies.

Meta WhatsApp API State-change Approved templates Multi-recipient Webhook-ready

Phase 1

Meta setup

Developer account, business account, app, and the WhatsApp product with a test phone number for the full development cycle.

Phase 2

Approved template

A utility‑category template - tiko_ceemo_alert - carrying service, state and detection‑time placeholders.

Phase 3

Production token

A permanent system‑user token, scoped to whatsapp_business_messaging and whatsapp_business_management.

Phase 4

Backend integration

Environment‑driven configuration, with state‑change detection and an ingest endpoint protected by token.

Phase 5

Optional webhook

A public URL for delivery and reply events, registered against the WhatsApp app and verified by a shared token.

Status

Implementation

Outbound alerts, templates, state‑change detection and multi‑recipient support are live. Webhook and retry logic are on the roadmap.

Capability 04 / Sentinel

Automated firewall audit.

Sentinel continuously compares firewall configurations against a client‑specific baseline and against industry standards. Each drift produces a finding: severity, owner, recommended remediation, and the diff that caused it.

Findings are shipped to the SIEM and surfaced in a living register, queryable by analyst tier or by client unit. The output is evidence, not a static PDF.

Baselines Industry standards Drift detection Continuous SIEM-queryable

A finding looks like

SeverityHigh
RuleInbound  ANY → mgmt port
BaselineDeny outside corp‑jump
Detected2026‑05‑21 09:14 UTC
OwnerPlatform/Networks
RemediationRestrict source, request change ticket
Capability 05 / Intelligence Sharing

Regulator‑grade intelligence sharing.

A structured platform that allows us to securely report incidents to the regulators of the markets we operate in. It enforces consistent reporting taxonomy, supports redaction policies, and produces a signed submission envelope that the regulator can verify independently.

The platform also archives historical submissions. When a regulator asks “has this happened before, and what did you do?” the answer is a query, not a project.

Signed envelopes Taxonomy-driven Redaction Auditable archive
Submission Pipeline #INC-2026-0142
  1. 01
    Taxonomy enforced
    schema incident.v2 · 14 fields validated
  2. 02
    Redaction applied
    3 PII fields masked · policy v1.4
  3. 03
    Envelope signed
    ed25519 + sha-256 manifest
  4. 04
    Archived (immutable)
    urn:augcyba:submission:0142
  5. 05
    Delivered to regulator
    BoB CSIRT · structured JSON-LD
Envelope signature Verified
Algorithm
ed25519 + sha-256
Issuer
augmenta-csoc
Recipient
BoB · CSIRT
Signed at
14:32:18 SAST
Fingerprint a5e4 f29c 08d3 7b6a   c5e1 9f2b 4a8d 6e3f

Want a deeper walkthrough?

We can step through any of these platforms under NDA, including the operating manual and a sanitised audit trail.