Cybersecurity assurance

Security assurance is where the "structured argument supported by evidence" pattern shines hardest outside of safety. Common Criteria has been doing it formally since the 1990s. Modern automotive cybersecurity regulation (UNECE R155) mandates it. The argument is the same shape as a safety case — you just trade hazards for threats and safety goals for security objectives.

GSN works in security contexts without any extension. The notation is domain-neutral; the regulator-grade rigour transfers directly.

The standards stack

• ISO/IEC 15408 (Common Criteria) — Evaluation criteria for IT security. The Security Target / Protection Profile / Security Assurance Requirements machinery maps neatly onto GSN.
• ISO/SAE 21434 — Road vehicles cybersecurity engineering. Sibling to ISO 26262, increasingly required by UNECE R155.
• NIST SP 800-53 — Security and Privacy Controls for Information Systems. Common reference for federal and federal-adjacent systems.
• NIST SP 800-160 (vol 1 & 2) — Engineering Trustworthy Secure Systems / Developing Cyber-Resilient Systems. Explicitly assurance-case-friendly.
• ISO/IEC 27001 — Information Security Management Systems. More process-than-product, but the audit trail it produces feeds Solutions in a security argument.

What a security argument looks like

The structure is recognisably the same as a safety argument:

• Top-level claim: the system is acceptably secure against its threat model, within its operating context.
• Decomposition strategies: by threat (STRIDE, attack tree), by security objective (Common Criteria), by control family (NIST 800-53), by lifecycle phase.
• Sub-claims: each threat mitigated, each control effective, each residual risk accepted at the appropriate authority.
• Evidence (Solutions): threat-model documents, penetration-test reports, code-audit findings, control-implementation records, SBOM provenance, formal proofs where they exist.

The Context and Assumption nodes do real work here too: every claim is scoped by an assumed threat model, an assumed deployment environment, and a set of organisational controls the technical argument depends on.

An example fragment

A fragment arguing that an authentication subsystem mitigates credential-theft threats:

Each sub-Goal terminates in Solutions — the protocol specification, the rate-limiting implementation, the WebAuthn integration tests, the third-party pen-test report.

Where Lemmatica fits

• Threat models live in code reviews and architecture docs. Lifting them into a structured argument makes the security posture reviewable as a single artefact rather than an accumulating folder.
• Regulator submissions under UNECE R155 / ISO 21434 require a defendable argument structure. GSN is one of the most widely-recognised notations for this.
• Modular sub-cases via away goals let you separate cryptography, identity, network, and application-layer arguments while keeping a top-level traceability link.
• Dialectic extension (planned) is especially useful in security — a red-team finding maps cleanly onto a Challenge node, and its remediation onto the response.