# CSA STAR Level 1 — CAIQ v4 Self-Assessment (KIROSEC) — DRAFT

- **Status:** Draft self-assessment (gap analysis; not yet submitted to the STAR Registry)
- **Date:** 2026-07-22
- **Framework:** CSA Cloud Controls Matrix (CCM) v4 / Consensus Assessments
  Initiative Questionnaire (CAIQ) v4
- **STAR level:** **Level 1 — Self-Assessment** (free; no third-party audit)
- **Owner:** KIROSEC engineering

> **What this is.** CSA STAR **Level 1 is a self-assessment** — you complete the
> CAIQ v4 (the yes/no/N.A. answers to the ~197 CCM v4 controls across 17 domains)
> and publish it, free, to the **CSA STAR Registry**. There is **no eligibility
> gate** (no company-age / D-U-N-S requirement) and **no audit** — Level 1 is
> attested transparency. This document is a codebase-grounded *draft*: it maps our
> current posture per domain so we can then fill the official CAIQ spreadsheet
> honestly. Level 2 (STAR Attestation/Certification) requires a third-party
> SOC 2 / ISO 27001-based audit and is out of scope here.

## 1. How to read this

Per-domain posture:

| Posture | Meaning |
|---|---|
| **Implemented** | Control is in place and evidenced (usually in code — cross-referenced to the ASVS attestation). |
| **Partial** | Some of the control exists; gaps remain. |
| **Inherited** | Provided by an infrastructure provider under shared responsibility (Render / Vercel / managed Postgres / object storage), attested by *their* SOC 2 / ISO 27001. |
| **Planned** | Not yet in place — a policy/process a startup must stand up before submitting. |
| **N/A** | Not applicable to this architecture (with justification). |

The **application-layer** security detail behind many "Implemented" rows lives in
the companion **[OWASP ASVS 4.0.3 attestation](owasp-asvs-4.0.3-attestation.md)** —
CAIQ's technical domains (AIS, CEK, IAM, LOG, TVM, DSP) are largely answered by it.

## 2. Scope & shared-responsibility model

**Service:** KIROSEC — a multi-tenant security log-analysis platform (managed-cloud
SaaS console + customer portal + a cross-platform desktop analyzer), plus a
self-hosted deployment option.

**KIROSEC owns (application layer):** authentication & session management, tenant
isolation & authorization, application cryptography (at-rest case bundles, signed
licenses/packs, webhook signatures), input handling, application logging/audit,
data retention & redaction, secure SDLC, and the desktop client.

**Inherited from providers (shared responsibility):**

| Layer | Provider | They attest / KIROSEC owns |
|---|---|---|
| Backend compute (gateway) | **DigitalOcean** droplet (IaaS — ADR-069) | DigitalOcean (SOC 2, ISO 27001): datacenter **physical only**. KIROSEC **owns** OS, host, network hardening, TLS, patching, supervision, monitoring, backups |
| Frontends (console + portal) | **Vercel** | Edge/CDN, TLS termination, DDoS, platform security |
| Database | **Managed PostgreSQL** (Supabase/Neon) | Storage encryption at rest, backups, patching, physical security |
| Object storage | **S3-compatible / MinIO** | Durable storage, encryption at rest |
| Email | **MXroute (SMTP)** | Mail transport |
| Payments | **PayMongo** | PCI DSS (card data never touches KIROSEC) |

**Important (ADR-069, supersedes ADR-029):** the backend runs on self-managed
**IaaS** (a DigitalOcean droplet), not a managed PaaS. Only
**physical/datacenter** controls remain inherited (DigitalOcean is
ISO 27001); **OS, host, network, TLS, patching, process supervision, monitoring,
and backups are now KIROSEC-owned** — they moved from "Inherited" to "Owned/Planned"
below (raising IVS, LOG, BCR, TVM). The **database and frontends stay managed**
(Supabase/Neon + Vercel), so those controls remain inherited. Collect DigitalOcean's SOC 2 / ISO
27001 + Vercel's + the DB provider's SOC 2 for the CAIQ evidence pack.

## 3. Domain-by-domain assessment (CCM v4)

### A&A — Audit & Assurance — **Partial → Planned**
- ✅ This CAIQ + the ASVS attestation are the start of an assurance program; CI
  runs automated security gates (clippy, gitleaks, `cargo audit`, `pnpm audit`).
- ⛔ **Planned:** a formal internal audit schedule, an independent third-party
  assessment (SOC 2 Type I → II is the recommended next step), and a compliance
  register.

### AIS — Application & Interface Security — **Implemented**
- ✅ Strongest domain. Full detail in the ASVS attestation: no SQLi/XSS/XXE/
  path-traversal, output encoding, security response headers (HSTS/CSP/nosniff/
  X-Frame-Options), input validation, hostile-input parsing (never executed),
  signed-artifact verification. Contracts (`contracts/*.openapi.yaml`) define APIs
  before implementation; SDLC gates in CI.

### BCR — Business Continuity & Operational Resilience — **Planned**
- ✅ Managed Postgres provides automated backups (Inherited); stateless gateway is
  redeployable; releases are versioned.
- ⛔ **Planned:** a documented **Business Continuity / Disaster Recovery plan**
  with RTO/RPO targets, tested restore procedures, and a backup-verification
  cadence. (Highest-priority governance gap.)

### CCC — Change Control & Configuration Management — **Implemented → Partial**
- ✅ All changes via Git + PRs; CI enforces tests/clippy/fmt/contract validation
  before merge; ADRs govern architecture changes; releases are versioned
  (`releases/releases.json`) with a changelog.
- ⛔ **Partial:** formalize a documented change-management policy and a
  segregation-of-duties/approval rule for production deploys.

### CEK — Cryptography, Encryption & Key Management — **Implemented → Partial**
- ✅ AES-256-GCM (case bundles), Argon2id (passwords + KDF), Ed25519 (licenses/
  packs, client-verified), HMAC-SHA256 (webhooks), CSPRNG throughout; TLS
  (rustls) everywhere, verification never disabled. (ASVS V6/V9.)
- ⛔ **Partial (key management):** secrets are env-seeded with **no rotation /
  `kid` versioning / managed secret store** — the tracked ASVS V6.4.2 gap. Stand
  up a rotation runbook + a secret manager.

### DCS — Datacenter Security — **Inherited / N/A**
- KIROSEC operates no datacenters. Physical/environmental controls are Inherited
  from **DigitalOcean** (SOC 2 / ISO 27001) / Vercel / the managed DB + object-storage providers
  — cite their SOC 2 / ISO 27001 in the CAIQ.

### DSP — Data Security & Privacy Lifecycle — **Implemented → Partial**
- ✅ 2-year default retention with legal-hold + purge API; field-level report
  **redaction** (source hashes/chain-of-custody never redacted); tenant data
  isolation server-derived; GDPR-aligned privacy + cookie pages + consent-gated
  first-party analytics; self-serve account deletion. Reset/verify tokens hashed
  at rest.
- ⛔ **Partial:** publish a **data classification policy**, a **sub-processor
  list** and a customer **Data Processing Agreement (DPA)**; implement encrypted
  per-tenant integration-secret storage before shipping integrations (ASVS V8.3.7).

### GRC — Governance, Risk & Compliance — **Planned**
- ✅ Non-negotiable security rules documented (CLAUDE.md), ADRs, threat model.
- ⛔ **Planned:** a formal **information-security policy set**, a **risk register /
  risk-assessment process**, defined security roles/ownership, and a compliance
  calendar. Core governance work for a maturing startup.

### HRS — Human Resources Security — **Planned**
- ⛔ **Planned:** background-check policy (where lawful), security onboarding/
  offboarding, acceptable-use and confidentiality agreements, security-awareness
  training. Standard early-stage gap; document as the team grows.

### IAM — Identity & Access Management — **Implemented → Partial**
- ✅ Server-derived tenant scope (never client input), deny-by-default, no IDOR/
  BOLA (cross-tenant denial tests), Argon2id passwords + 12-char + common-password
  policy, brute-force lockout (user + admin), **server-side logout / session
  revocation**, enumeration-safe flows, separate hardened platform-admin boundary.
  (ASVS V2/V3/V4.)
- ⛔ **Partial:** **MFA** (TOTP/WebAuthn) not yet available — the tracked ASVS
  V2.2.2/V4.3.1 gap; and internal least-privilege access to production systems
  needs a documented policy.

### IPY — Interoperability & Portability — **Implemented**
- ✅ Open, documented formats: canonical event JSON schema, OpenAPI contracts,
  encrypted case-bundle export/import, self-serve account deletion (data removal),
  and a **self-hosted deployment option** (no lock-in). Reports export to
  standard formats.

### IVS — Infrastructure & Virtualization Security — **Owned / Partial** (changed by ADR-029)
- ✅ Network egress fail-closed CORS; the desktop's `online` Cargo feature gates
  all egress (air-gap capable); single-tenant logical isolation enforced in-app.
  On the droplet: **owned** host hardening — DigitalOcean Cloud Firewall + `ufw`,
  `fail2ban`, `unattended-upgrades`, SSH key-only, non-root user, Caddy-terminated
  TLS (`infrastructure/droplet/`, ADR-069).
- **Inherited:** hypervisor + physical from DigitalOcean (SOC 2 / ISO 27001); edge/CDN from
  Vercel; storage from the managed DB.
- ⛔ **Partial:** formalize the host-hardening baseline as a written standard,
  add config drift/patch tracking, and document the network architecture + trust
  boundaries (partly in the threat model).

### LOG — Logging & Monitoring — **Partial**
- ✅ Append-only audit log for sensitive actions (entitlement/billing/admin/sync);
  no secrets in logs; admin login success/failure/lockout audited.
- ⛔ **Partial:** the audit **hash-chain (`hash_prev`) + request context is not yet
  populated**, and auth events (login/reset/invite) aren't all audited (tracked
  ASVS V7.2/V7.3); no centralized log aggregation / alerting / anomaly detection
  yet. Stand up log shipping + retention + alerting.

### SEF — Security Incident Management & Forensics — **Planned**
- ✅ Evidence integrity is a product feature (source hashes, tamper-evident
  bundles) — forensic-friendly by design.
- ⛔ **Planned:** a documented **Incident Response plan** (roles, severity levels,
  customer-notification/breach-notification timelines per GDPR), and an on-call/
  escalation process. High-priority governance gap.

### STA — Supply Chain, Transparency & Accountability — **Partial**
- ✅ Dependencies lockfile-pinned (`Cargo.lock`, `pnpm-lock.yaml`); CI runs
  `cargo audit` + `pnpm audit` + `gitleaks`; `dependabot.yml` for cargo/npm/
  actions; artifacts (packs/licenses) are signature-verified.
- ⛔ **Partial:** publish a **sub-processor/vendor inventory** with their
  compliance evidence, and a vendor-risk-review process; add SBOM generation.

### TVM — Threat & Vulnerability Management — **Partial**
- ✅ `cargo audit` + `pnpm audit` in CI (advisory), gitleaks secret scanning,
  Dependabot, `clippy -D warnings`; a maintained **threat model**; ASVS
  self-assessment with a tracked remediation backlog.
- ⛔ **Partial:** promote dependency audits from advisory to blocking once the
  baseline is clean (e.g. the tracked `quick-xml` advisory), add periodic
  penetration testing, and a coordinated vulnerability-disclosure (`security.txt`
  / disclosure policy).

### UEM — Universal Endpoint Management — **Partial / N/A**
- The desktop analyzer is customer-operated software, not a KIROSEC-managed fleet;
  it is **offline-first**, imports are never executed, and updates are
  signature-verified.
- ⛔ **Partial (internal):** document endpoint management for KIROSEC's own
  workforce devices (disk encryption, MDM) as the team grows.

## 4. Before you submit — the startup governance checklist

Level 1 is honest self-attestation, so partial/planned answers are fine — but a
credible CAIQ needs these **organizational artifacts** written down (they don't
exist in the repo yet). None require spend; they require decisions:

1. **Information Security Policy set** (GRC) — the umbrella policies.
2. **Business Continuity / DR plan** with RTO/RPO + a tested restore (BCR).
3. **Incident Response plan** incl. GDPR breach-notification timelines (SEF).
4. **Risk register / risk-assessment process** (GRC/A&A).
5. **Sub-processor list + customer DPA** (DSP/STA) — you already process PII.
6. **HR security basics** — onboarding/offboarding, confidentiality, awareness (HRS).
7. **Access-control policy** for production (least privilege, review cadence) (IAM).
8. **Vendor-risk review** + collect Render/Vercel/DB/PayMongo SOC 2 reports (STA).

## 5. Do we qualify to submit Level 1 today?

**Yes.** There is no eligibility gate. You can complete and publish the CAIQ v4 now.
The **technical domains (AIS, CEK, IAM, IPY, DSP, TVM)** will present strongly
(the ASVS work backs them); the **governance/process domains (GRC, BCR, SEF, HRS,
A&A, STA)** will honestly show startup-stage "planned" answers, and **DCS/IVS** are
largely Inherited. That's an expected and legitimate Level 1 profile.

## 6. Submission steps

1. Download the official **CAIQ v4 spreadsheet** from CSA
   (cloudsecurityalliance.org) — it enumerates all ~197 CCM controls.
2. Fill each control's answer (Yes / No / N.A.) + notes, using this document's
   per-domain posture and the ASVS attestation as the evidence base.
3. Write the "planned" governance artifacts in §4 first (they turn several "No"s
   into "Yes, see policy X").
4. Submit the completed CAIQ to the **CSA STAR Registry** (free Level 1 listing).
5. Keep it current — re-assess when architecture or controls change (same trigger
   as the ASVS attestation: the `security-review` skill).

## 7. Maintaining this assessment

Living document. Update alongside the ASVS attestation whenever a
security-relevant change lands. When the governance artifacts in §4 are written,
flip the corresponding domains from **Planned** to **Implemented** with a
reference to the policy document.