Security & Trust Posture

Alright. We covered how we govern in Governance, risk & compliance: ISO intent, physical security, SSDLC, deception, T-Pot, the works.

This page answers the customer-shaped version of the same question:

"Why should I trust you with my DNS, my email, and my business on a VPS?"

Hosting is a trust business. Not a logo business. Not a "we have a firewall" business. Customers hand us keys to things that hurt when they break. This doc states what we protect, what we promise, and what we explicitly do not own before anyone opens CrowdSec rules or Vault policies in Volume 22.

My bias: I am a security person first. Trust posture is not marketing copy written after an incident. It is the contract between what we say publicly and what GRC and SSDLC prove internally.

---

What customers trust us with

Asset	Sensitivity	Our duty
Account & billing data	High	Protect, minimize retention, encrypt in transit and at rest
DNS control	Critical	Prevent hijack, audit every change
Email mailboxes	High	Isolation, anti-abuse, deliverability hygiene
VPS hypervisor boundary	Critical	Tenant isolation, patch cadence, no "noisy neighbor" escape
Backups we manage	High	Encrypt, test restore, strict access control
Customer app data inside VM	Varies	Shared responsibility (see below)

If it can take a customer offline or leak their data, we treat it like crown jewels. Even in lab phase. Especially in lab phase, because bad habits harden into architecture.

---

Shared responsibility model

Think AWS-style clarity at HostKid scale. No mystical "we secure everything" brochure language.

We are responsible for:

• Security of the platform (CloudStack, network underlay, portal, billing integration)
• Hypervisor and control-plane patching
• Physical and logical isolation between tenants at the infrastructure layer
• Platform monitoring, deception intel, and incident response for our faults
• SSDLC and change discipline so we do not ship trash code (see GRC / SSDLC)

Customer is responsible for:

• Security in their VPS (OS patches, app vulns, weak passwords)
• Application code and uploaded content
• Locking down SSH, guest firewalls, secrets in their app
• Backups they chose not to buy from us (if that becomes an option)

DNS hijack from a phished portal login is still our lane to detect and respond. Weak WordPress on their VPS is theirs to patch. Both can look like "you got hacked" in the ticket. Clarity upfront saves friendships.

---

Security principles (non-negotiables)

Principle	What it means here
Secure by default	No wide-open SSH on templates. Sensible baselines via cloud-init / Ansible.
Least privilege	Human admin, service accounts, API keys scoped minimally.
Everything auditable	Who provisioned what, who changed DNS, who logged into admin.
Secrets never in tickets or git	Vault / secret store. Volume 22.
Defense in depth	Segmentation + identity + monitoring + deception, not one magic firewall.
Fail closed	Auth errors deny access. No stack traces leaking internals to customers.

DevSecOps lens: security is a property of the provisioning pipeline, not a scan you run after launch. Same story as AI velocity + SSDLC in the GRC doc: ship fast, but fail the pipeline when quality regresses.

---

Trust boundaries (executive map)

Crossing a boundary requires identity, authorization, and logging. No anonymous shortcuts.

Detail diagrams and VLAN IDs land in Volume 5 and Volume 22. This is the executive picture you draw on a whiteboard before the audit.

---

Data classification (simple)

Class	Examples	Handling
Public	Marketing site, public docs	Integrity matters. No secret sprawl in repos.
Internal	Runbooks, non-customer metrics	Staff auth only. No pasting into public tickets.
Confidential	Customer PII, billing	Encrypt, strict RBAC, retention rules.
Restricted	Secrets, keys, payment tokens	Vault. Break-glass only. No copy-paste culture.

Maps to retention and backup rules in Volumes 18 and 22. Classification is boring until a breach lawyer asks "why was that CSV in Slack?"

---

High-level threat focus

Not a full STRIDE workshop. Executive priorities only. Detailed controls live in Volume 22. Risk register lives in Governance.

Threat	Why hosting cares
Account takeover	DNS or email hijack, resource fraud, reputation damage
Tenant escape	One VPS touching another customer's data
Abuse (spam, DDoS)	IP reputation, legal exposure, upstream null routes
Ransomware on platform	Backups and restore drills are not optional theater
Insider / leaked admin	MFA, break-glass, audit, phishing exercises
Supply chain	Compromised dependency, vendor, or AI-generated vuln in base code

We do not only harden against these. Deception and live attack dashboards (GRC doc) tell us what is still hitting the edge so mitigations stay honest.

---

What we tell customers (trust pack, future)

When we go public-facing, the trust pack includes:

Artifact	Purpose
Shared responsibility summary	One page, no lawyer fog
Data handling & retention overview	What we store, why, how long
Subprocessor list	Registrar, payments, colo, email upstream
Status page & incident comms policy	How we talk when things break
ISO 27001 roadmap (honest stage)	Alignment intent, not a fake badge

---

What this doc does not cover

Topic	Where it lives
Keycloak hardening, TLS cipher suites	Volumes 9, 22
Fail2ban, CrowdSec, WAF rules	Volume 22
T-Pot, honeypot VLANs, deception tuning	Volume 22 (intent in GRC doc)
Penetration test findings	Ops records / Volume 27
ISO control mapping, risk register	Governance, risk & compliance

---

Volume 0 wrap

You finished the executive layer of HostKid: what we are, how we make money, how boxes connect, how we measure health, how we govern, and what customers should trust us with.

Trust is the product. Everything else is packaging.

Next in the handbook: Volume 1, Internet fundamentals. Or revisit the Volume 0 overview anytime you need the map.