Four chapters apply the grammar to concrete domains: local and backup drives, Ubuntu/Debian-first VPS hosts, authorized passive-first testing of client-owned websites, and Docker images with their CI/CD supply chain. Each is defensive and gate-driven — verification before change, authorization before verification.
This material is a defensive specification and reference set. It is not an attack tool,
a scanner, a certification, or evidence of a completed assessment. It does not automate
exploitation; active or state-changing operations require a valid authorization manifest,
an in-scope target, an allowed mode, verified preconditions and verified rollback.
A backup drive and a working drive have different availability, mount, write, and key-management rules.
3.2 Storage security objectives
CONFIDENTIALITY stolen or misplaced media does not reveal client data
INTEGRITY unauthorized alteration is detectable
AVAILABILITY hardware failure or corruption does not destroy service
RECOVERABILITY known restore procedures meet client objectives
SEPARATION one client cannot read another client's data
MINIMIZATION unnecessary client data is not retained
DISPOSAL retired media cannot disclose recoverable client data
PROVENANCE backups and artifacts can be tied to an origin and time
3.3 Baseline drive profile
Control area
Required state
Evidence
Inventory
Serial/model/size/role/owner/location recorded
lsblk, hardware inventory, asset record
Encryption
Client-data volumes encrypted at rest; LUKS2 preferred on Linux where applicable
Recovery material separated from the encrypted drive; no keys in source repositories
key custody record, secret scan, recovery test
Filesystem ownership
Service accounts and operators have least required access
ownership/ACL report
Mount policy
nodev, nosuid, noexec applied where workload-compatible
findmnt output and exception records
Auto-mount
Untrusted removable media does not auto-execute or auto-mount into trusted paths
desktop/server policy evidence
Health
SMART/NVMe health collected and degradation alerts defined
health report and alert test
Integrity
Critical configuration and content monitored for change
FIM coverage and test event
Backup
At least one independent copy not writable by the production credential
repository ACLs and credential separation
Restore
Sample and full restore procedures tested
restore hashes, timestamps, outcome
Disposal
Cryptographic erase or approved destruction documented
disposal record
3.4 Encryption production rules
IF object contains client confidential data
AND medium can leave controlled possession
THEN encryption_at_rest = required
IF encryption key is stored on the same unprotected medium
THEN confidentiality claim = failed
IF full-disk encryption is enabled
BUT unlocked system exposes plaintext through remote compromise
THEN encryption controls theft/loss risk
NOT running-system compromise risk
IF a LUKS header or recovery key is required for restore
THEN header/key backup must be separated, encrypted, access-controlled, and tested
Do not reformat or re-encrypt a live device from automation without a verified backup, unmounted state, console access, power stability, explicit destructive approval, and a tested recovery path.
IF mount stores documents, uploads, cache, logs, or backups
AND executables are not required
THEN prefer noexec
IF mount does not require device files
THEN nodev
IF mount does not require setuid semantics
THEN nosuid
Compatibility tests are mandatory. Some application runtimes, package stores, or container layers require execution and need a narrower alternative rather than blind application.
the repository can be read using documented recovery material;
a restore produced expected files/data;
hashes or application checks passed;
the restored service can start in an isolated environment;
restoration time and data-loss interval were measured.
Snapshots are useful rollback points but do not automatically qualify as independent backups when they share the same account, region, provider, deletion authority, or failure domain.
Each client should have separate Unix groups, service identities, database credentials, backup namespaces, evidence encryption context, and retention rules. Do not rely only on naming conventions.
3.9 Removable-drive workflow
received -> quarantined -> identified -> read-only inspection
-> malware/content policy check -> approved import path
-> copied to encrypted working storage -> evidence recorded
-> unmounted -> physically secured
Unknown removable media must never be connected directly to a privileged production VPS. Use an isolated workstation or disposable environment.
3.10 Storage alerts
Create alerts for:
filesystem usage and inode pressure;
read-only remounts;
SMART/NVMe health degradation;
RAID/resilver failures;
LUKS/header errors;
failed mounts;
unexpected mount options;
backup failure, age, size anomaly, or retention deletion;
mass file modification or deletion;
permission/ownership drift;
unexpected new block devices;
evidence store tampering.
3.11 Storage incident grammar
IF mass modification OR ransomware indicator
THEN isolate write paths
AND preserve filesystem and process evidence
AND revoke compromised credentials
AND protect backup repositories from inherited access
BEFORE broad cleanup
IF physical drive is failing
THEN reduce writes
AND capture health evidence
AND replace/clone according to recovery policy
NOT run repeated destructive tests
4. VPS hardening grammar
This profile is Ubuntu/Debian-first and must be adapted for the actual distribution, provider, workload, and availability requirements.
A secure operating system cannot compensate for a compromised provider account. A secure provider account cannot compensate for a publicly exposed database. Evaluate every layer.
4.2 Golden order of operations
Confirm ownership, scope, emergency contact, and provider console access.
Inventory current ports, services, accounts, packages, storage, containers, and dependencies.
Take a provider snapshot where appropriate and verify an independent application/data backup.
Record current SSH, firewall, DNS, reverse-proxy, and health state.
Create or verify a non-root administrative identity with a working key and sudo.
Test a second SSH session before changing authentication or firewall rules.
Apply one control group at a time, using a canary host where possible.
Validate syntax before reload/restart.
Run service, application, security, and external reachability checks.
Observe logs and health; rollback when stop conditions trigger.
Retest the control objective and capture before/after evidence.
4.3 Provider-account controls
phishing-resistant MFA where available;
unique administrator identities rather than shared root accounts;
least-privilege API tokens with expiry and IP/workload restrictions where supported;
billing and security alerts;
separate production projects/accounts from experiments;
protected snapshot, image, DNS, and firewall permissions;
recovery codes stored separately;
account recovery paths tested;
no provider master token stored on a VPS it controls.
IF no explicit business purpose
THEN inbound = deny
IF administration service
THEN source should be management network, VPN, bastion, or explicitly approved addresses
NOT global exposure by default
IF database/cache/queue is not a public product endpoint
THEN public exposure = prohibited
IF reverse proxy terminates public HTTP/S
THEN application port should bind to loopback or private network
Maintain both provider-edge firewall policy and host firewall policy where practical. They are separate failure domains.
4.5 SSH grammar
Desired state:
Protocol 2
key-based authentication
password authentication disabled after key path verified
keyboard-interactive disabled unless explicitly required
root login disabled or tightly constrained
allow-groups or allow-users defined
strong modern algorithms supplied by current vendor defaults/policy
agent forwarding disabled unless required
X11 forwarding disabled unless required
TCP forwarding scoped to need
idle/session limits aligned to operations
verbose security logging
Lockout-prevention rule:
IF changing sshd OR firewall OR user/sudo configuration
THEN require:
provider console confirmed
+ second live admin session
+ tested non-root key login
+ validated sshd syntax
+ rollback command
+ staged reload before restart
Do not blindly copy a static cipher list from an old hardening guide. Prefer supported vendor policy and verify clients before removing algorithms.
4.6 Identity and privilege
one human identity per operator;
no routine shared root login;
sudo for attributable elevation;
service accounts have no interactive shell unless required;
file and secret access mapped to service identity;
temporary access expires;
stale accounts and keys are detected;
SSH authorized-key files are integrity-monitored;
secrets never appear in process arguments, shell history, world-readable environment files, images, or repositories;
emergency “break glass” access is separately protected, alerted, and reviewed after use.
4.7 Package and patch state
IF package is not required
THEN remove_or_disable
IF security update is available
THEN classify by exposure, reachability, KEV, exploit probability, technical severity,
asset criticality, compensating controls, and reboot/service impact
Use supported vendor repositories. Inventory third-party and manually installed binaries separately because normal package scanning may not fully cover them.
preserve Secure Boot where supported and operationally appropriate;
AppArmor/SELinux remains enabled and enforced where profiles exist;
use vendor-supported sysctl baselines rather than arbitrary internet snippets;
disable unneeded filesystems, modules, protocols, and services only after workload testing;
configure time synchronization because logs, certificates, authentication, and forensics depend on trustworthy time;
protect bootloader/console according to physical and provider threat model;
evaluate swap encryption and crash-dump sensitivity.
4.9 Service-manager controls
For systemd services, evaluate:
User / Group
NoNewPrivileges
PrivateTmp
ProtectSystem
ProtectHome
CapabilityBoundingSet
AmbientCapabilities
RestrictAddressFamilies
SystemCallFilter
ReadWritePaths
ReadOnlyPaths
MemoryDenyWriteExecute
LockPersonality
UMask
Do not apply every sandbox directive blindly. Generate an expected resource/access model, test in staging, and add restrictions incrementally.
4.10 Web-tier controls
public traffic reaches only the reverse proxy/load balancer;
TLS configuration, certificate automation, and renewal alerting are verified;
origin/application ports are private;
host routing rejects unknown hosts rather than serving a default tenant;
request/body/time limits exist;
administrative panels are isolated and strongly authenticated;
upload paths cannot execute code;
application and static content permissions are separated;
reverse proxy does not trust arbitrary forwarded headers;
logs avoid secrets and unnecessary personal data;
health endpoints reveal minimal information;
error pages do not expose stack traces or environment data.
4.11 Database controls
bind to private/loopback interfaces;
use per-application identities;
separate migration/admin identity from runtime identity;
enforce transport encryption where network crosses a trust boundary;
encrypt and protect backups;
test point-in-time or logical recovery as applicable;
restrict extension/plugin installation;
log privileged and schema-changing events;
rotate credentials without redeploying secrets into images;
avoid shared databases across clients unless tenant isolation is explicitly designed and tested.
4.12 File permissions
configuration: root-owned, service-readable only as required
secrets: service-specific, least-readable, never world-readable
web code: deployment identity writes; runtime normally reads
uploads: runtime writes; not executable
logs: service writes; monitoring reads
backups: backup identity writes; production identity cannot delete immutable history
4.13 Detection minimums
authentication successes/failures and sudo events;
account, group, key, and privilege changes;
firewall, SSH, reverse-proxy, and service configuration changes;
unexpected listening ports and processes;
package and kernel changes;
critical file integrity;
suspicious web/app events;
disk, memory, CPU, load, process count, and filesystem anomalies;
backup failures and restore test status;
malware/rootkit indicators where suitable;
time drift and log-pipeline interruption.
4.14 Hardening failure modes
Failure mode
Prevention
SSH lockout
second session, console access, syntax validation, canary, firewall preflight
Website outage
health checks, load balancer drain, rolling changes, rollback
Hidden dependency breakage
dependency inventory, staging, service telemetry
Firewall bypass
provider and host policy comparison, external verification
False sense of compliance
objective-based tests and evidence, not package presence
Backup destruction
separate credentials, immutability, independent account/copy
Tenant crossover
per-client identities, networks, paths, data stores, worker pools
Alert flood
tuned detection objectives, suppression with expiry, measured precision
Drift after deploy
immutable images or policy checks in pipeline plus post-deploy verification
4.15 VPS minimum release gate
A production web VPS is not “ready” until:
asset owner known
provider account protected
public ports justified
SSH access tested and constrained
firewall default-deny verified externally
supported OS/packages
automatic or managed security updates
AppArmor/SELinux active where applicable
application secrets separated
TLS and renewal verified
database not publicly exposed
critical files monitored
central logs functioning
independent encrypted backup completed
restore test passed
incident contact and containment path documented
current evidence attached
5. Authorized web-application testing grammar
5.1 Testing objectives
The testing system verifies technical controls, attack paths, and business risk while minimizing harm. It follows a passive-first progression and uses OWASP ASVS as the control target and the OWASP Web Security Testing Guide as the test-method library.
ownership/control proof through DNS TXT, HTTP token, provider evidence, or client attestation;
third-party exclusions;
test accounts and roles;
data handling rules;
production/staging distinction;
rate, concurrency, depth, and duration limits;
emergency stop contact;
prohibited actions;
agreed handling of discovered secrets or personal data.
Phase 1 — inventory and passive observation
DNS, TLS, certificate chain, protocol support;
HTTP redirects, headers, caching, cookie flags;
public routes from approved crawling;
technology disclosure and public metadata;
security contact and policy locations;
public storage/exposure checks limited to client-owned identifiers;
dependency and client-side asset inventory from delivered content;
ZAP Baseline or equivalent passive scanning.
Phase 2 — authenticated read-only verification
test-account login;
role and route inventory;
session and cookie lifecycle observation;
API schema import when supplied;
configuration/evidence review;
no state-changing operations unless the test account and endpoint behavior are explicitly approved.
Phase 3 — staging active tests
input validation and injection testing;
authentication, authorization, session, API, upload, and business-logic cases;
test data only;
cleanup and database reset;
explicit payload and endpoint allowlists;
rate and error stop thresholds.
Phase 4 — production active tests
Production active testing is exceptional. It requires a separate signed approval, precise payload classes, a low-impact proof objective, maintenance/observation coverage, rollback where relevant, and a stop-on-impact design. Prefer reproducing a production finding in staging rather than increasing production depth.
5.4 Safe production defaults
Allowed by default when authorized:
DNS lookup
TLS handshake and certificate inspection
HTTP HEAD/GET on public routes
robots/sitemap retrieval
brief bounded crawling
passive response analysis
security-header and cookie inspection
known public metadata retrieval
Not allowed by default:
credential guessing
password spraying
account lockout tests
phishing
social engineering
mass form submission
file upload payload execution
data extraction beyond a minimal proof
persistence
shell acquisition
denial-of-service or stress testing
cache poisoning against shared infrastructure
third-party targeting
production active scanner profiles
5.5 Stop conditions
Terminate immediately when any condition is met:
error rate, latency, or resource use crosses the agreed threshold;
the target begins returning widespread 5xx responses;
evidence suggests another tenant or third party is being touched;
real personal, payment, health, or secret data appears unexpectedly;
an operation changes production data outside the approved test dataset;
the scan leaves the allowed hostname/path/API operation set;
the emergency contact requests stop;
the runner loses telemetry or cannot enforce rate limits;
an unexpected authentication or authorization boundary is crossed;
one payment cannot settle multiple unrelated accounts;
approval cannot be performed by the requester where separation is required;
inventory cannot be consumed without an order state;
a cancelled subscription cannot retain privileged access;
a client user cannot move an object into another tenant by changing an identifier;
retries do not duplicate charges, emails, or destructive operations.
5.10 Evidence standard
Every finding includes:
exact target and environment
timestamp and tool version
authorization ID
test account/role (redacted identifier)
preconditions
minimal request/response evidence
expected vs actual result
impact without unnecessary data access
confidence and reproducibility
cleanup state
control mapping
recommended remediation objective
retest procedure
Redact authorization headers, session tokens, secrets, personal data, and sensitive payload content.
5.11 Passive scan command pattern
The included CLI builds a constrained ZAP Baseline container command. Baseline scanning spiders briefly and performs passive analysis; it is intentionally distinct from the ZAP Full Scan, which performs active attacks.
laka-sec web plan \
--authorization examples/client-authorization.yaml \
--target https://security-demo.example.com
no long-lived production credentials in CI variables;
secret scanning on current tree and history;
dependency lockfiles and controlled update process;
signed commits/tags or equivalent provenance where appropriate;
security changes mapped to tests and controls;
automated jobs pinned to trusted versions/digests where feasible.
6.4 Build controls
IF build runner handles production signing or deployment credentials
THEN runner must be isolated, ephemeral where feasible, and not shared with untrusted fork code
IF external contribution can modify workflow definitions
THEN privileged secrets must not be exposed to that execution context
Build outputs should be immutable and referenced by digest, not only mutable tags.
6.5 Image controls
minimal supported base image;
no package manager/cache residue not required at runtime;
no secrets in layers, environment defaults, or build arguments;
non-root runtime user;
explicit entrypoint and health check;
read-only root filesystem when compatible;
writable paths declared and bounded;
vulnerability, misconfiguration, secret, and license scanning;
SBOM generated;
artifact digest recorded;
provenance/signature verified before production;
rebuild rather than patching containers manually in place.
6.6 Runtime controls
run as non-root
prefer rootless engine where workload permits
no privileged containers
no host PID/network/IPC namespaces unless justified
no Docker socket mount into application containers
capabilities dropped by default; add only required capabilities
no-new-privileges
seccomp profile enabled
AppArmor/SELinux profile enabled
read-only filesystem where possible
resource limits
private network segmentation
explicit published ports
secret mounts rather than baked secrets
immutable image digest
central logs and runtime alerts
The Docker daemon/socket is a high-privilege control surface. Treat membership in the Docker group or socket access as equivalent to powerful host administration in many configurations.
This is a grammar example, not a universal drop-in configuration. Adapt writable paths, user IDs, health checks, ports, and profiles to the application.
component + version + source + image digest + CVE
+ vendor status + reachability + loaded/runtime status
+ public exposure + KEV + EPSS + CVSS vector
+ compensating controls + owner + remediation path + retest
An image scanner finding does not prove runtime exploitability, and lack of runtime reachability does not eliminate the need to update an exposed or future-deployable artifact. Keep both facts.
6.10 Supply-chain failure modes
poisoned dependency or base image;
mutable tag changes beneath an approved deployment;
CI secret exposed to untrusted code;
compromised maintainer identity;
build and production signing in the same unisolated runner;
SBOM not tied to the deployed digest;
scanner result from a different artifact than production;
