Skip to main content
The Aerospace Safety Solution implements DO-326A as a dedicated threat assessment framework built on the STRIDE threat model, with automated Security Assurance Level (SAL) calculation and integration into the broader V-model traceability structure.

​
Why Security and Safety Are Separate — but Connected

A common misconception is that DO-326A is just “safety with a different name.” The distinction matters:
  • Safety (ARP 4761, DO-178C, DO-254) asks: What can go wrong due to failure or malfunction?
  • Security (DO-326A) asks: What can go wrong due to intentional, adversarial action?
A hydraulic actuator that fails due to wear is a safety concern. An attacker who spoofs sensor data to trigger false actuator commands is a security concern. The same system element — the same failure outcome — but a fundamentally different causal chain requiring a different analytical framework. In the Aerospace Safety Solution, both frameworks share the same System Element hierarchy as their organizational backbone. The aircraft decomposition (aircraft → system → subsystem → component) built during ARP 4754A system development analysis provides the context for DO-326A threat identification. This is not accidental: DO-326A requires that security threats be anchored to specific system assets, and those assets are already defined in the safety model.

​
The STRIDE Mental Model

DO-326A adopts the STRIDE threat classification taxonomy, organizing threats into six categories that together cover the full attack surface of a system: diagram Each category maps to a specific type of security property violation. Together they ensure that no attack angle is missed during threat elicitation. The threatCategory field on each securityThreat work item records which STRIDE category applies.

​
Attack Surface Classification

Alongside the threat category, every threat in the risksheet is tagged with an attack surface — the entry point an attacker would need to exploit:
Attack SurfaceWhat It Represents
NetworkRemote access via data networks or communication links
PhysicalRequires direct physical presence (ports, panels, hardware)
SoftwareExploits vulnerabilities in software components
HumanSocial engineering, insider threat, procedural manipulation
Supply ChainCompromise introduced during manufacturing or procurement
WirelessRF, Bluetooth, GNSS spoofing, or other wireless vectors
This classification shapes the countermeasure strategy. A wireless spoofing threat and a supply chain compromise threat call for entirely different mitigations, even if both could trigger the same safety outcome.

​
How SAL Is Calculated

The Security Assurance Level (SAL) is the DO-326A analogue to DAL in safety analysis. Where DAL flows down from failure condition severity, SAL is computed from two independent dimensions:
  • Likelihood — how probable is it that a threat actor would successfully execute this attack? (4 levels: unlikely → almost certain)
  • Impact — what is the consequence if the attack succeeds? (4 levels: negligible → catastrophic)
The solution computes SAL automatically from a 4×4 matrix:
NegligibleMinorMajorCatastrophic
UnlikelySAL-0SAL-0SAL-1SAL-2
PossibleSAL-0SAL-1SAL-2SAL-3
LikelySAL-1SAL-2SAL-3SAL-3
Almost CertainSAL-2SAL-3SAL-3SAL-3
The initialSAL and residualSAL fields are populated by the risksheet formula engine — they are not manually entered. The analyst’s job is to set likelihood and impact; the system derives the assurance level.
The same initial/residual structure used in FMEA (RPN before and after mitigation) applies here: the initial SAL is assessed before countermeasures are defined; the residual SAL is re-evaluated after countermeasures are applied. The delta between the two demonstrates the effectiveness of the security controls.

​
The Threat Assessment Workflow

The DO-326A Security Threat Risksheet organizes analysis into five guided views, each corresponding to a phase of the threat assessment:
  1. Identify Threats — enumerate attack scenarios, classify by STRIDE category and attack surface, link to the affected system element
  2. Initial Assessment — score likelihood and impact before any countermeasures are considered; initial SAL is auto-calculated
  3. Security Controls — define countermeasures (by ID and title), set countermeasure status, review initial SAL in context
  4. Residual Assessment — re-score likelihood and impact after countermeasures are in place; residual SAL confirms risk reduction
  5. Full Analysis — consolidated view for review and reporting
This mirrors the pattern used across all Aerospace Safety Solution risk analysis tools: identify → assess → mitigate → verify residual risk.

​
Security Requirements Traceability

Threat identification alone is not sufficient for certification. DO-326A also requires that security requirements — the design responses to identified threats — are traceable from system level through design implementation to verification evidence. The DO-326A Security Requirements Traceability PowerSheet handles this traceability layer with three column groups:
  • Security Requirements (purple) — the security-specific requirements derived from threat analysis
  • Design Implementation (blue) — design elements that implement the countermeasures
  • Security Verification (orange) — verification activities and evidence confirming the controls work
Two views are available: Security Overview (system requirements only) and With Design Reqs (full decomposition including design-level requirements). The split mirrors the ARP 4754A system/design decomposition pattern.

​
Integration with the Broader Standards Framework

Every securityThreat work item is linked to the same SystemElement used by FHA failure conditions, FMEA failure modes, and design requirements. The system decomposition you build for ARP 4754A compliance is reused — without modification — as the asset inventory for DO-326A threat analysis.
The Standards Compliance Overview dashboard tracks DO-326A alongside ARP 4754A, ARP 4761, DO-178C, DO-254, DO-160G, and MIL-STD-882E. The Certification Readiness Scorecard provides per-standard readiness metrics so program managers can see security certification posture alongside safety certification posture in a single view.
In the Aero1 Flight Control Computer reference project, DO-326A metrics show as N/A in the Certification Readiness Scorecard because no security threats have been populated yet. This is expected for a new project — the framework is in place, awaiting threat elicitation.
For the safety assessment side of the same system, see ARP 4761 Safety Assessment Coverage and ARP 4754A System Development Assurance. For the design assurance layers that security requirements must trace through, see DO-178C Software Airworthiness and DO-254 Hardware Design Assurance.
Code: .polarion/tracker/fields/securityThreat-threatCategory-enum.xml (0.67) · modules/RiskTemplates/SecurityThreatTemplate/attachments/risksheet.json (0.65) · .polarion/nextedy/sheet-configurations/DO-326A Security Requirements Traceability.yaml (0.62) · .polarion/tracker/fields/securityThreat-attackSurface-enum.xml, securityThreat-likelihood-enum.xml, securityThreat-impact-enum.xml, securityThreat-sal-enum.xml (0.59) · .polarion/pages/spaces/_default/Safety Assessment Summary/page.xml, Common Cause Analysis Report/page.xml, Security Threat Assessment/page.xml, Hara Risk Matrix Report/page.xml (0.54) · .polarion/nextedy/models/rtm.yaml (0.53) · .polarion/tracker/fields/securityThreat-custom-fields.xml (0.52) · datasets/sol-aero-ui-walkthrough/summary.md, navigation.md, dashboards/home-dashboard.md, dashboards/role-dashboards.md, dashboards/standards-compliance.md, risksheet-views/risksheet-views.md, work-item-types/data-model.md (0.50) · .polarion/tracker/fields/complianceObjective-standard-enum.xml, complianceObjective-status-enum.xml, complianceRequirement-complianceStatus-enum.xml, complianceRequirement-evidenceType-enum.xml (0.47) · .polarion/nextedy/sheet-configurations/DO-254 Objectives Compliance Matrix.yaml (0.45)