AEP-67 engineering for system assurance in NATO programmes

What it is

AEP-67 is the NATO Allied Engineering Publication that tells a programme how to engineer "system assurance" into an electronic, firmware or software-based system across its whole life cycle. It defines system assurance as "the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle." It is a guidebook rather than a specification, and it is carried by STANREC 4808: the recommendation of nations to use it is recorded there, which means AEP is Allied Engineering Publication, and reaches a supplier the way any Allied Publication does, because a specific NATO programme's own agreement calls for it.

The current edition is Edition B, Version 1, promulgated October 2017, superseding the original Edition 1. It is unclassified and free of charge, published by the NATO Standardization Office for the CNAD's Life Cycle Management Group.

The assurance case: claims, arguments, evidence

AEP-67's organising idea is the assurance case: a linked set of claims about a system's critical assurance properties, arguments that justify each claim, and evidence that supports each argument. A claim has to be a clear, testable statement, not an action, and it decomposes into sub-claims until each connects to retrievable evidence. The guidebook sets out minimum conditions for the case: it has to be relevant to the system's actual operating environment, claims have to be justified by arguments and arguments by evidence, and the whole case has to be built iteratively and kept alive throughout the life cycle rather than written once and filed away. It also has to be delivered with the system at handover, not left behind with the development team. An auditor working from this document does not look for a single sign-off; they look for a traceable chain from a stated claim, through its argument, to named evidence.

What it covers, and what it deliberately does not

The guidebook is scoped tightly to security-related assurance: confidentiality, integrity, availability, authentication, accountability (including non-repudiation) and auditability. It says so directly, and just as directly says what is out of scope: "it does not address assurance for quality, safety, or dependability," though it notes that an adversary able to subvert a system's security can, as a side effect, undermine those other properties too. It also treats assurance as a property of the whole system rather than of any one part: a system built entirely from well-assured elements is not automatically assured, because assurance depends on how the parts are combined, not only on how each was built.

Agreement processes: acquisition and supply

Where elements are bought rather than built in-house, AEP-67 asks the acquirer to weigh a supplier's reputation, qualifications, processes and tools, and to prefer standards-based interfaces and defence-in-depth so that one weak supplier cannot undo the whole system. Commercial and government off-the-shelf elements get particular attention, because an acquirer typically has little influence over an off-the-shelf product's future direction, and the guidance expects supplier-selection evidence, defect history, product assessments, relevant certifications the supplier already holds, to be written down and kept traceable.

Project processes: planning, risk, configuration and information

The work breakdown structure is expected to name assurance activities explicitly: threat assessment, assurance-case development and maintenance, assurance-focused peer review, static and binary source-code analysis, and penetration testing. Major decision gates have to pass measurable assurance criteria, such as static-analysis results and red-team findings, before a programme proceeds. Risk management draws on named vulnerability sources (the Common Vulnerabilities and Exposures, Common Weakness Enumeration and Common Attack Pattern Enumeration and Classification catalogues) and treats probabilities qualitatively rather than numerically, because an intelligent adversary does not behave like a random failure and can choose the worst moment to attack. Configuration management has to produce an audit trail of who changed what and when, kept immutable to support accountability, apply least privilege to changes, and run a patch-triage process that weighs the risk of a known vulnerability against the risk of an unproven patch. Information management requires marking and protecting assurance-sensitive material and coordinating tightly with configuration management.

Technical processes: requirements through disposal

Requirements analysis separates intrinsic functions, which deliver the mission, from defensive functions, which protect it, and grades the system's criticality from Highest, where compromise causes catastrophic mission failure within seconds to minutes (Table 3-4), down to Low. Architectural design works through concrete techniques: least privilege, isolation and containment, monitoring and response, tolerance to partial failure, identification and authentication, cryptography, and ten named anti-tamper mechanisms running from tamper-evident seals to enclosures that zero their data if someone drills into them. Implementation is organised around named threat sources, an unintentional defect, a rogue authorised developer, an unauthorised intruder, a compromised supplier, each paired with countermeasures such as compiler warnings enabled from the start, static and dynamic analysis tooling, and paired development with peer review. Verification and validation call for a documented strategy covering static analysis, fuzz testing, penetration testing and red-teaming, and, for the most critical elements, formal proof techniques, carried out by people with the specific skills to interpret the results. Transition requires the installed system to be hardened, unnecessary services disabled, and delivery protected against tampering through chain of custody and tamper-evident packaging. Operation and training require users to be trained on what to do and what not to do, including recognising social engineering, and the system to be monitored for drift from its expected configuration. Maintenance requires patches to be authenticated, sometimes through a public key built into the deployed system, and requires that a correction never itself introduce a new vulnerability. Disposal requires sanitisation proportionate to sensitivity, up to incineration, since a well-resourced adversary may otherwise recover data from overwritten or degaussed media.

An auditor working from AEP-67 is, in the end, looking for a live set of cross-referenced artefacts rather than a certificate: a criticality determination, a work breakdown structure that names assurance tasks, static-analysis and peer-review records, red-team results, training records, and a disposal record, all traceable back to the claims in the assurance case.

Standards named alongside it

AEP-67's own structure is built throughout on ISO/IEC 15288:2008, the systems and software engineering life cycle standard, and its Annex A surveys related civil information-security management work, ISO 9001, ISO/IEC 27001, ISO/IEC 27002 and ISO/IEC 27005, as background rather than as requirements the guidebook itself imposes. It is carried by STANREC 4808, the NATO recommendation that records nations' agreement to use it.

Standards it references

• ISO/IEC 27001Background
• ISO 9001Background
• ISO/IEC 27005Background
• ISO/IEC 27002Background