Security review pack. Packetman saysWelcome to the security review pack. I'm Packetman. This page exists for one specific reader: the procurement, GRC, or vendor-risk reviewer at your organization who has been asked to evaluate DataStun as a vendor and needs answers to standard SIG-Lite or CAIQ-style questions without scheduling a call. The page below covers the architecture, the authentication and access model, how data is handled in transit and at rest, retention windows, subprocessors with their purpose, the vulnerability-disclosure address, an honest pre-commercial posture statement that says clearly what we have and what we don't have today, and the security contact. The companion page is /trust, which answers the "what does the agent on my machine actually see" question. Together those two pages should answer most of what a standard vendor questionnaire asks. If your reviewer has a question we haven't covered, the security contact at the bottom of this page is the right place to send it.

1. Architecture & data flow

DataStun is a three-tier system. The endpoint agent runs on customer machines (Linux / Windows / macOS) as a kardianos/service-managed background process. The tenant platform (ten) handles agent enrollment, telemetry ingest, customer dashboards, and billing. The reputation system (rep) handles destination-IP investigation and threat-feed ingestion.

Data flow

Key boundary properties

• Agents talk only to the tenant platform — never directly to the reputation system. There is no inbound port to the agent.
• The agent only opens outbound connections to tenant.datastun.com over TCP/443. No peer-to-peer fanout, no STUN-style NAT punching from the agent toward the platform.
• Cross-tenant isolation enforces at the database row level today (tenant_id on every customer-data row). Per-tenant database isolation lands on paid tiers as part of the federation rollout.
• The reputation system holds only data about IP addresses (geo, TLS posture, threat-feed membership). It does not hold customer fleet data.

2. Authentication & access control

Customer users

• Email + password (bcrypt-hashed, cost factor 12), with email verification on signup.
• OAuth via LinkedIn for the customer-facing dashboard. SAML / OIDC SSO ships on the Enterprise tier.
• Sessions are server-side, signed cookies; idle and absolute timeouts apply. No long-lived bearer tokens for browser use.
• Per-tenant role model: owner / admin / member, with parent-over-child inheritance for MSSP tenants.

Agents

• Per-agent API key with prefix dta_, HMAC-hashed at rest. Scope is limited to the single agent the key was issued to.
• Enrollment uses a single-use install-package token (dtet_ prefix) tied to the install-package’s tenant + tier-bound seat count.
• Per-key throttling on last_used_at (once per minute) limits replay-style abuse.

Staff & vendor-side access

• Staff-side dashboards (/staff/*) gate on an explicit email allowlist (STAFF_EMAIL_ALLOWLIST). A real RBAC role layer is on the iteration-2 roadmap.
• Production hosts are reachable only over the internal admin network. Customer data access is audit-logged.

3. Data handling, encryption, retention

In transit

• All agent ↔ platform traffic is HTTPS over TLS 1.2 or higher (Cloudflare-terminated TLS edge, modern cipher suite negotiation only).
• Internal hop from Cloudflare edge to the tenant platform is over Cloudflare Tunnel (mTLS-authenticated tunnel, no public origin port).
• Browser sessions also TLS 1.2+ via the same tunnel.

At rest

• Customer data lives in PostgreSQL 16 with full-disk encryption at the host layer.
• Secrets (API keys, OAuth credentials, session secrets) live in environment files outside the database, owned by the service user.
• Passwords are bcrypt-hashed (cost 12); password resets use single-use, time-bounded tokens.

Retention by data class

• Network flow records: 30 days (Individual), 90 days (Tribe), 365 days (Business), configurable up to 7 years (Enterprise). Configurable downward by tenant admin in the in-product privacy controls.
• Reputation cache: 7-day default TTL per IP. Stale entries are re-investigated, not deleted.
• Account & billing rows: retained for the life of the tenant; deleted on tenant deletion (one-click in the privacy controls).
• Support conversations: retained for the life of the tenant; deleted on tenant deletion.

Deletion

Tenant deletion is a single click in the in-product privacy controls. Deletion cascades through all per-tenant tables in a single transaction. Backups age out on a 30-day rolling window; deleted tenants drop out of backup at the latest backup-age boundary.

4. Subprocessors

The actual production list. We commit to updating this page when it changes.

Hosting / infrastructure: today on Bill’s in-region infrastructure. The Vultr migration adds a hosted-cloud subprocessor; this list is updated when that lands.

5. Vulnerability disclosure

If you find a security issue in any DataStun component, please report it to [email protected].

What we commit to

• Acknowledgement within 2 business days.
• Initial triage and severity assessment within 7 days.
• A target remediation window (calibrated to severity, not a one-size SLA) communicated in the triage response.
• Coordinated disclosure: we will not pressure or threaten responsible reporters. We will credit reporters in release notes unless they prefer otherwise.

What we ask

• Don’t test against production tenants you don’t own. We provide a sandbox tenant on request.
• Don’t exfiltrate customer data, run denial-of-service tests against shared infrastructure, or pivot from a found vulnerability.
• Give us a reasonable disclosure window before publishing.

A formal CVD policy and bug-bounty program will land alongside the SOC 2 work. Today the address and the commitments above are operative.

6. Pre-commercial posture (the honest part)

Pretending we have SOC 2 today would waste your time and ours. The honest answer is that the controls are in place, the documentation is being built, and the audit is on the roadmap. If your organization requires SOC 2 to use a vendor, please tell us — that signal accelerates the audit timeline.

7. Compliance framework crosswalk

Where DataStun sits today against common frameworks. Use this as a starting point; specific control mappings are available on request.

• GDPR / UK GDPR: lawful bases documented in the Privacy Policy. Customer is data controller; DataStun is data processor. Article 28 DPA available on request. Article 44 transfer measurement is the data-sovereignty rollup on Enterprise — see /sovereignty.
• CCPA / CPRA: customer data is processed only to provide the service. No sale of personal information. Tenant deletion path satisfies right-to-delete.
• HIPAA: BAA available on request for tenants in regulated environments. DataStun does not access protected health information; the agent observes connection metadata only.
• SOC 2: Type II audit not yet completed. Controls documentation in flight.
• ISO 27001: certification not yet pursued. Organizational and technical controls broadly aligned.
• PCI-DSS: DataStun does not process cardholder data. Customer payment information (when real billing replaces the simulated billing) will route through a PCI-compliant payment processor; no card data lands in the DataStun database.
• FedRAMP: not pursued today. Self-host (Custom tier) is the path for FedRAMP-boundary use cases.

8. Security contact & escalation

For security-review questions, vulnerability reports, or DPA / BAA / questionnaire requests:

• Vulnerability reports: [email protected]
• Vendor-review questions, DPA / BAA / questionnaire requests: [email protected]
• Existing customers: the in-product support flow under Account → Support is the fastest route for tenant-specific questions.

For questions this page didn’t answer, the contact form at /contact routes directly to the security inbox.