Operating model & roadmap

12. Multi-client operating model

12.1 Tenant boundary

Treat each client as a separate security tenant even when websites share your infrastructure.

Separate:

identities
credentials
API tokens
SSH keys
network policy
directories and volumes
databases/schemas according to risk
backup namespaces and keys
evidence encryption contexts
scanner jobs and queues
reports
retention and deletion schedules
incident records

A shared dashboard may aggregate counts, but authorization and raw evidence checks remain tenant-scoped.

12.2 Client onboarding grammar

contract + authorization
-> identity and contacts
-> ownership proof
-> asset import
-> data classification
-> criticality and availability objectives
-> backup/recovery objectives
-> baseline audit
-> gap plan
-> approved hardening
-> verification
-> continuous monitoring

Required client facts:

• legal and operational owner;
• primary and emergency contacts;
• domains, VPS/provider accounts, repositories, DNS, storage, databases, and SaaS dependencies;
• production/staging distinction;
• data types and regulated obligations;
• maintenance windows;
• acceptable availability risk;
• recovery point and recovery time objectives;
• approved test modes and prohibited actions;
• incident authority and notification flow;
• evidence retention/deletion requirements.

12.3 Credential model

• prefer client-created, client-revocable identities;
• use short-lived credentials and workload identity where supported;
• avoid global agency credentials shared across clients;
• scope tokens to required resources and actions;
• store secrets in a central secret manager with tenant paths;
• audit all access;
• rotate on staff departure, suspected exposure, scope change, and defined schedule;
• emergency credentials are separately controlled and monitored.

12.4 Runner isolation

Recommended worker pools:

pool-readonly-client-A
pool-readonly-client-B
pool-passive-external
pool-active-staging
pool-change-client-A
pool-incident-emergency

At minimum, active-test and change workers must not share unrestricted credentials with passive scanners. High-risk clients should receive dedicated runners and evidence keys.

12.5 Client report grammar

A useful report answers:

1. What is protected and what remains unknown?
2. What changed since the last report?
3. Which attack paths are currently plausible?
4. Which controls are verified, partial, absent, or stale?
5. Which findings require the client’s decision?
6. Can the website be restored, and when was that proven?
7. What actions were performed under which authorization?
8. What evidence supports each claim?

Report sections:

executive risk shape
asset and exposure changes
control-state matrix
priority findings and attack paths
hardening changes and verification
backup/recovery results
monitoring/detection health
exceptions and expirations
authorization and evidence appendix

12.6 Service tiers

Baseline protection

• asset inventory;
• passive website checks;
• VPS read-only audit;
• patch/exposure findings;
• backup-status monitoring;
• periodic report.

Hardened protection

• baseline plus approved host/container hardening;
• FIM and central logging;
• CI/image scans;
• restoration testing;
• ASVS Level 1/selected Level 2 controls depending on application risk.

Resilient protection

• dedicated tenant runners;
• threat model and ASVS Level 2 target;
• staging active tests;
• immutable/artifact-based deployment;
• incident containment automation;
• recovery drills;
• attack-path and drift analysis.

High-assurance/custom

• specialized compliance mapping;
• stronger segmentation and key custody;
• independent review;
• ASVS Level 3 where justified;
• formal evidence and change controls;
• custom threat simulations in controlled environments.

12.7 Metrics that create client value

percentage of assets with current owner and evidence
unknown internet-exposed assets
public ports and routes reduced
privileged identities with MFA and current keys
median and worst patch latency
KEV affected/reachable count
control drift recurrence
P0/P1 time to contain/mitigate
backup success and age
restore success, data gap, and elapsed restoration time
website deployment security-gate pass rate
findings reopened after claimed remediation
exceptions approaching expiry

Avoid vanity metrics such as raw scan count or total alerts without validated outcomes.

10. Implementation roadmap

Phase 0 — operating authority

Deliverables:

• master service terms and rules of engagement reviewed for your jurisdiction and client contracts;
• per-client authorization template;
• data-processing, evidence, retention, and disclosure rules;
• emergency containment authority;
• scope and ownership-proof process;
• prohibited-action policy;
• client security contact tree.

Exit condition: the system can deny work that lacks legal and operational authority.

Phase 1 — asset and dependency truth

Build:

• client/tenant registry;
• domain, DNS, certificate, VPS, container, database, storage, account, and backup inventory;
• owner and criticality assignments;
• data classifications and flows;
• trust-boundary and dependency graph;
• lifecycle and unsupported-asset views.

Exit condition: every protected website maps to its host/runtime, identities, data stores, DNS/TLS, backups, monitoring, and owner.

Phase 2 — read-only collectors

Implement isolated collectors for:

• local drive/mount/encryption metadata;
• VPS packages, ports, services, accounts, firewall, SSH effective configuration, AppArmor/SELinux, storage, backups;
• Docker runtime and image metadata;
• DNS, TLS, HTTP headers, cookies, and public routes;
• Git/IaC/container scans;
• provider and identity audit logs where APIs permit.

Exit condition: collectors are versioned, allowlisted, timed out, tenant-scoped, and evidence-producing.

Phase 3 — control profiles and evidence

Load profiles for:

• encrypted workstation/working drive;
• removable transfer drive;
• backup repository;
• Ubuntu web VPS;
• Docker host and application container;
• passive website baseline;
• ASVS application level;
• detection and incident minimums.

Build the control evaluator:

profile + asset context + evidence -> unknown/absent/partial/verified/resilient

Exit condition: every dashboard claim can open the supporting evidence.

Phase 4 — planning engine

The planner should:

• calculate dependencies and blast radius;
• choose least-invasive actions;
• generate a before/after test set;
• identify console, backup, restore, and maintenance prerequisites;
• produce an Ansible diff or manual change plan;
• stop when evidence is stale or authorization is insufficient.

Exit condition: no hardening action goes directly from finding to execution.

Phase 5 — guarded hardening

Implement changes in this order:

1. provider account and recovery;
2. backups and restoration;
3. administrative identity and SSH safety;
4. network/firewall exposure;
5. patching and unsupported software;
6. file/secret permissions;
7. AppArmor/SELinux/systemd/container restrictions;
8. reverse proxy/TLS/application configuration;
9. logging/FIM/detection;
10. immutable or image-based deployment.

Use canaries, serial changes, health checks, and rollback.

Exit condition: change execution is separable from scan workers and requires explicit gates.

Phase 6 — website security verification

• passive external checks after every deployment;
• ASVS requirement mapping;
• authenticated read-only application inventory;
• staging active testing;
• synthetic authorization and business-logic test accounts;
• production active testing only under separate approval;
• CI security gates and post-deploy retests.

Exit condition: website security is verified across code, configuration, runtime, identity, and business logic.

Phase 7 — monitoring and incident control

• per-client telemetry boundaries;
• critical FIM and identity detections;
• provider/host/application/backup alerts;
• incident states and runbooks;
• emergency containment operations;
• immutable evidence ledger;
• restore drills and clean-room recovery.

Exit condition: the system can detect control failure and restore service, not merely prevent known issues.

Phase 8 — adaptive LAKA loop

observe -> compare -> explain -> prioritize -> plan -> authorize
-> execute -> verify -> monitor -> learn -> update grammar/profile

Use recurrence, drift acceleration, false-positive rate, restore results, and incidents to revise control rules.

Suggested production stack

API/UI: FastAPI + OpenAPI; optional GraphQL read model
Database: PostgreSQL
Queue: NATS, Redis Streams, or another durable job system
Policy: JSON Schema + OPA/Rego or Cedar for production authorization
Orchestration: Ansible/AWX for host changes
Passive web: OWASP ZAP Baseline plus purpose-built DNS/TLS/HTTP collectors
Code/image/IaC: Trivy; add SAST and dependency tools suited to each stack
Host telemetry: Wazuh/osquery/native audit and journald
Evidence: S3-compatible object store with object lock + signed manifests
Secrets: Vault or cloud KMS; SOPS/age for repository configuration
Dashboards: asset graph, control volume, findings, drift, recovery readiness

Core services

identity-service
tenant-service
authorization-service
asset-service
profile-service
policy-decision-service
planner-service
job-orchestrator
collector-workers
change-workers
evidence-service
finding-service
incident-service
reporting-service

Keep active-test workers, change workers, and evidence decryption privileges separated.

Data tables

clients
tenants
users
roles
authorizations
target_rules
assets
asset_relationships
data_flows
profiles
controls
control_applicability
jobs
policy_decisions
evidence_artifacts
findings
attack_paths
exceptions
changes
incidents
backup_tests
restore_tests
alerts

Dashboard dimensions

Do not show only a “security score.” Show:

• unknown assets and stale evidence;
• control state by layer;
• internet-exposed paths;
• client and tenant blast radius;
• KEV/EPSS/CVSS/local reachability separately;
• recurring drift and acceleration;
• mean and worst restore result;
• privileged identity age and MFA state;
• findings by owner and treatment state;
• authorization expiry and scope;
• scanner coverage and false-positive outcomes;
• evidence freshness and integrity.