Security grammar

0. System overview

0.1 Mission

The LAKA Volumetric Security Grammar System protects client websites by joining four capabilities into one governed operating model:

1. asset and trust-boundary knowledge;
2. defensive verification and authorized ethical testing;
3. reversible hardening and remediation;
4. detection, containment, restoration, and learning.

It is not a single scanner. It is a policy-controlled security language that can select tools, restrict their behavior, preserve evidence, and prove whether a control remains effective.

0.2 The four execution planes

PLANE 0 — KNOWLEDGE
assets, owners, dependencies, data flows, authorizations, profiles, evidence

PLANE 1 — OBSERVE
inventory, passive web checks, configuration audit, logs, package/image/IaC analysis

PLANE 2 — PROVE
staging tests, authenticated control verification, recovery drills, controlled simulations

PLANE 3 — CHANGE
hardening, patching, credential rotation, isolation, rollback, restoration

A worker belongs to one plane. A read-only worker must not inherit change credentials. An active-test worker must not inherit backup-deletion rights. A reporting worker must not inherit infrastructure access.

0.3 The six security loops

GOVERN   -> define authority, ownership, policy, constraints, and risk decisions
IDENTIFY -> map assets, identities, data, dependencies, exposure, and attack paths
PROTECT  -> apply least privilege, encryption, segmentation, secure configuration, and backups
DETECT   -> observe control failure, compromise indicators, drift, and evidence loss
RESPOND  -> validate, contain, communicate, preserve evidence, and eradicate
RECOVER  -> restore trusted service, verify security, measure RPO/RTO, and learn

The loops are connected. For example, a failed restore test changes the permitted-change state: destructive changes remain plan-only until recovery evidence is current.

0.4 The volumetric security cube

Treat every security claim as a position in a multidimensional cube:

LAYER       device | storage | host | identity | network | runtime | application | data | recovery
LIFECYCLE   design | build | deploy | operate | change | incident | restore | retire
MODE        inventory | passive | audit | active | change | containment | recovery
STATE       unknown | absent | partial | verified | resilient
CHANGE      baseline | minor | major | structural | paradigm
TENANCY     client | tenant | environment | trust boundary | object
TIME        event | current evidence | drift | recurrence | expiry | trend

A control is complete only when the system knows:

what it protects
where it applies
when its evidence was collected
how it can fail
how failure is detected
who owns the response
whether it can be reversed
how far failure can propagate
whether recovery has been proven

0.5 The execution kernel

Every proposed operation passes the same deterministic kernel:

INPUT
  authorization + target + mode + action + profile + tool + limits + evidence plan

VALIDATE
  identity -> authority -> date -> scope -> target ownership -> mode -> prohibited actions

SIMULATE
  expected effects -> blast radius -> dependency effects -> lockout risk -> rollback path

DECIDE
  deny | plan-only | read-only execute | human approval required | guarded execute

RUN
  isolated worker + least privilege + timeout + rate ceiling + stop conditions + kill switch

PROVE
  signed result + logs + configuration hash + evidence hash + redaction + cleanup status

LEARN
  control state + finding + drift + recurrence + profile update + next verification date

0.6 Non-negotiable invariants

INV-01  No valid authorization, no target action.
INV-02  No exact scope match, no execution.
INV-03  Passive observations never silently escalate to active tests.
INV-04  Active tests and changes use separate credentials and workers.
INV-05  No verified backup and rollback, no mutating change.
INV-06  No current evidence, no claim of control effectiveness.
INV-07  No retest, no finding closure.
INV-08  No successful isolated restore, no claim of recoverability.
INV-09  Cross-tenant evidence is an incident and immediate stop condition.
INV-10  Language models may propose operations but cannot bypass policy decisions.

0.7 Primary system objects

Client
└── Tenant / Environment
    ├── Authorization
    ├── Asset graph
    │   ├── drive / backup
    │   ├── VPS / network / identity
    │   ├── container / pipeline / artifact
    │   └── domain / website / API / database
    ├── Threat model
    ├── Control profiles
    ├── Jobs and policy decisions
    ├── Evidence ledger
    ├── Findings and exceptions
    ├── Changes and rollbacks
    └── Incidents and recovery tests

0.8 Minimum viable deployment

Operator CLI
   |
Authorization + policy gate
   |-------------------------------|
Read-only collector          Plan-only hardening
   |                               |
Local drive/VPS facts        Ansible --check --diff
   |
Passive website worker
   |
Evidence JSON -> control evaluation -> prioritized finding -> remediation plan

The included repository implements this minimum safe kernel. Production phases add isolated queues, tenant-scoped identities, signed evidence, provider APIs, authenticated staging tests, approval workflows, and guarded change execution.

1. LAKA security grammar

1.1 Purpose

The grammar converts security work from disconnected tools and checklists into a constrained language. Every observation, test, control, change, alert, and recovery action becomes a typed sentence that can be validated before execution and measured afterward.

The system is defensive by construction:

NO AUTHORIZATION -> NO TARGETING
NO SCOPE MATCH -> NO EXECUTION
NO EVIDENCE -> NO CLAIM
NO VERIFIED ROLLBACK -> NO MUTATING CHANGE
NO OWNER -> NO ACCEPTED RISK
NO RETEST -> NO CLOSED FINDING

1.2 Security sentence

A complete security sentence is:

[OWNER] authorizes [ACTOR]
TO perform [ACTION]
ON [OBJECT]
WITHIN [BOUNDARY]
UNDER [CONDITIONS]
AGAINST [THREAT or CONTROL REQUIREMENT]
USING [TOOL + PROFILE]
AT [RATE + DEPTH + TIME WINDOW]
PRODUCING [EVIDENCE]
SO THAT [OUTCOME]
WITH [FEEDBACK]
SUBJECT TO [CONSTRAINTS]
AND [STOP CONDITIONS]
ELSE [FAILURE / ROLLBACK PATH].

Example:

Client ACME authorizes scanner-worker-03
TO run passive web verification
ON https://shop.example.com
WITHIN the production HTTP boundary
UNDER a 1 request/second ceiling during the approved window
AGAINST TLS, security-header, cookie, exposure, and configuration requirements
USING ZAP Baseline plus TLS/DNS collectors
PRODUCING hashed JSON and HTML evidence
SO THAT control drift becomes visible
WITH failed controls opening remediation tickets
SUBJECT TO no authentication, no form submission, and no active payloads
AND stop-on-5xx-rate, latency, or tenant-boundary conditions
ELSE terminate, preserve logs, and notify the emergency contact.

1.3 Core types

Object

What is being protected or acted upon.

OBJECT :=
  drive | partition | filesystem | backup_set | key | endpoint
  | vps | operating_system | account | ssh_service | firewall | process
  | container | image | registry | secret | pipeline | artifact
  | domain | dns_zone | certificate | website | api | route | session
  | database | queue | cache | object_store | log_stream
  | tenant | client | policy | authorization | evidence | finding

Every object has:

object_id
client_id
tenant_id
kind
owner
custodian
criticality
classification
environment
location
trust_boundary
dependencies
data_flows
internet_exposure
lifecycle_state

Condition

The circumstances in which a control or test has meaning.

CONDITION :=
  environment + exposure + identity + privilege + data_class
  + dependency_state + threat_state + time_state + maintenance_state
  + backup_state + rollback_state + evidence_state

Conditions must be explicit. “SSH is secure” is incomplete. “Production SSH on public interface, key-only authentication, root login disabled, current configuration validated, emergency console confirmed” is testable.

Threat

A possible event that can produce harm.

THREAT := actor + capability + intent + opportunity + technique
          + entry_point + precondition + target + potential_effect

Threats include malicious actors, accidental administrators, dependency compromise, provider failure, hardware failure, lost keys, configuration drift, and recovery failure.

Weakness

The condition that allows a threat to cross a boundary.

WEAKNESS :=
  vulnerability | misconfiguration | missing_control | excessive_privilege
  | exposed_secret | unsafe_default | weak_process | stale_asset
  | untested_backup | blind_spot | insecure_dependency | trust_error

Control

A mechanism intended to change likelihood, impact, detection, response, or recovery.

CONTROL :=
  prevent | reduce | isolate | detect | delay | contain | recover
  | govern | prove | warn | compensate | transfer | accept

A control is not considered implemented merely because a package is installed. A valid control record requires:

intent + configuration + coverage + owner + test + evidence
+ failure_signal + response + review_frequency

Action

What the system may do.

ACTION :=
  discover | inventory | classify | map | inspect | audit | compare
  | simulate | verify | scan_passively | test_actively
  | plan_change | apply_change | validate_change | rollback
  | monitor | alert | triage | contain | eradicate | restore | learn
  | accept_risk | transfer_risk | retire_asset

Tool

The mechanism that performs an action. Tools are replaceable implementations; the grammar is the stable abstraction.

TOOL := collector | scanner | policy_engine | orchestrator | agent
        | configuration_manager | evidence_store | ticketing_system
        | SIEM | EDR | backup_tool | key_manager | human_reviewer

Tool records must include version, source, execution identity, privileges, configuration hash, allowed modes, output parser, timeout, rate ceiling, and known limitations.

Evidence

Observable support for a claim.

EVIDENCE :=
  command_output | configuration_snapshot | packet_metadata | log_event
  | screenshot | report | hash | signature | restore_result
  | test_result | ownership_proof | approval | change_record

Evidence qualities:

authenticity
integrity
completeness
freshness
reproducibility
scope_alignment
collection_method
confidence
sensitivity
retention

Outcome

The produced state, not merely the performed action.

OUTCOME := verified | failed | partial | blocked | unknown | regressed
           | contained | restored | accepted | superseded

Feedback

How results alter the system.

FEEDBACK :=
  open_finding | close_finding | raise_priority | lower_priority
  | create_change | trigger_retest | adjust_profile | add_detection
  | revise_scope | revoke_credential | isolate_asset | update_playbook
  | train_operator | modify_architecture

Constraint

A hard or soft limit.

CONSTRAINT :=
  authorization | law | contract | privacy | availability | latency
  | budget | skill | compatibility | maintenance_window | rate_limit
  | data_residency | provider_capability | evidence_retention

Failure mode

How an action or control can cause harm or fail silently.

FAILURE_MODE :=
  lockout | outage | false_positive | false_negative | evidence_loss
  | scope_escape | tenant_crossing | secret_exposure | data_mutation
  | alert_fatigue | recovery_failure | policy_bypass | stale_exception
  | rollback_failure | dependency_breakage | unauthorized_execution

1.4 Mandatory authorization grammar

AUTHORIZATION :=
  authorization_id
  + legal_client_identity
  + approving_human
  + valid_from
  + valid_until
  + explicit_targets
  + explicit_environments
  + allowed_modes
  + forbidden_actions
  + rate_and_impact_limits
  + data_handling_rules
  + emergency_contact
  + ownership_proof

Scope matching

TARGET_ALLOWED(target) :=
  exact_url_match
  OR exact_hostname_match
  OR approved_wildcard_hostname_match
  OR exact_ip_match
  OR approved_cidr_contains_ip

A parent domain does not automatically authorize subsidiaries, third-party SaaS, CDN origin networks, shared hosting neighbors, payment processors, analytics services, or customer-controlled integrations.

Modes

inventory   := metadata and ownership discovery
passive     := observation without attack payloads or state changes
audit       := local read-only verification
active      := payloads intended to exercise a weakness
change      := configuration or software mutation
containment := emergency isolation or revocation
recovery    := restoration or failover

Decision production

IF mode IN {inventory, passive, audit}
AND authorization_is_current
AND target_matches_scope
AND action_not_forbidden
THEN plan_or_execute_read_only

IF mode IN {active, change, containment, recovery}
AND all_read_only_conditions
AND maintenance_window_confirmed
AND ownership_proof_verified
AND backup_verified
AND rollback_verified
AND emergency_contact_reachable
AND kill_switch_configured
THEN allow_controlled_execution
ELSE plan_only_or_deny

Containment can use an emergency authorization path, but that path must be pre-authorized in the client agreement and must preserve evidence before destructive cleanup whenever feasible.

1.5 Control grammar

CONTROL_RECORD :=
  control_id
  + objective
  + applicable_objects
  + required_conditions
  + implementation
  + verification
  + evidence
  + frequency
  + owner
  + failure_signal
  + response
  + exception
  + mapping

Example:

control_id: VPS-SSH-004
objective: Prevent password-based remote access
applies_to: [vps, ssh_service]
required_conditions:
  environment: production
  exposure: public-or-management-network
implementation:
  desired_state:
    PasswordAuthentication: "no"
    KbdInteractiveAuthentication: "no"
verification:
  command: [sshd, -T]
  assertions:
    - passwordauthentication == no
    - kbdinteractiveauthentication == no
evidence:
  format: json
  freshness: 24h
frequency: daily
owner: platform-security
failure_signal: configuration drift or SSH validation failure
response: open P1 if public; P2 if management-only
exception:
  requires_expiry: true
mapping: [NIST-CSF-PR.AA, ASVS-V6]

1.6 Finding grammar

FINDING :=
  finding_id
  + observation
  + affected_object
  + condition
  + weakness
  + attack_path
  + impact
  + evidence
  + confidence
  + cvss_vector_if_applicable
  + epss_probability_if_cve
  + kev_boolean_if_cve
  + reachability
  + compensating_controls
  + owner
  + priority
  + treatment
  + due_state
  + retest

Findings never close on “developer says fixed.” Closure requires a retest against the same control objective and preservation of before/after evidence.

1.7 Change grammar

CHANGE :=
  baseline_snapshot
  + desired_state
  + diff
  + dependency_analysis
  + lockout_analysis
  + availability_analysis
  + backup_restore_evidence
  + rollback_procedure
  + staged_canary
  + approval
  + execution
  + health_checks
  + security_retest
  + observation_window
  + closure_or_rollback

Rule:

IF change_can_affect_access OR networking OR boot OR storage OR encryption
THEN console_or_out_of_band_access MUST be confirmed before apply.

1.8 Test grammar

TEST :=
  test_id
  + control_objective
  + target
  + preconditions
  + method
  + mode
  + payload_class
  + rate
  + depth
  + timeout
  + stop_conditions
  + expected_result
  + evidence_parser
  + cleanup
  + confidence_model

Testing proceeds from least invasive to most invasive:

ownership proof
-> inventory
-> passive observation
-> authenticated read-only audit
-> configuration comparison
-> staging active test
-> production active test only when specifically justified and approved

1.9 Rule precedence

When rules conflict, apply this order:

1. Safety and legal authorization.
2. Tenant isolation and privacy.
3. Availability and recovery constraints.
4. Explicit client policy.
5. Control profile requirement.
6. Tool default.
7. Operator preference.

A lower-priority rule can never override a higher-priority prohibition.

1.10 State machines

Asset state

unknown -> discovered -> owned -> classified -> baselined
-> hardened -> monitored -> degraded -> contained -> restored -> retired

Finding state

observed -> validated -> prioritized -> assigned
-> planned -> mitigating -> retest_pending
-> closed | accepted_with_expiry | false_positive_with_evidence

Control state

unknown -> absent -> planned -> implemented -> verified
-> drifting -> failed -> compensated -> restored -> superseded

Authorization state

draft -> ownership_verified -> approved -> active
-> suspended | expired | revoked -> archived

1.11 Universal deny rules

Deny any job when:

• the target is not an exact scope match;
• authorization has expired or has not begun;
• the mode is not explicitly allowed;
• a forbidden action is requested;
• the scanner would cross a tenant boundary;
• production active scanning lacks explicit approval;
• a mutating change lacks rollback and restoration evidence;
• secrets are embedded in command arguments or report output;
• rate, depth, duration, or concurrency exceeds the manifest;
• target health crosses a stop threshold;
• the requested tool or executable is not allowlisted;
• output cannot be tied to a tool version and configuration hash;
• the operator attempts to bypass evidence capture.