Home' RTCA Documents for Review : DO-356A Contents 106
© RTCA, 2018
A7.7 Every identified vulnerability has been
evaluated for its environmental metrics to
determine applicability, specific impacts and
exploitability for the associated asset.
O7.5 Vulnerabilities are
to their evaluation.
A7.8 Corrective actions have been raised for
vulnerabilities that need mitigation.
A7.9 All known residual vulnerabilities have been
justified and are monitored.
A7.10 Vulnerabilities have been linked to
vulnerabilities issued from risk assessments
and risk assessments updated accordingly if
Security Refutation Introduction
As a generalization, when a set of requirements are generated in response to a negative
requirement/objective (specifying the absence of specific behaviors), then even though
a set of requirements are correct and complete (complies with ED-79A / ARP 4754A)
and properly developed (per item level standards), this does not mean that the resultant
assurances necessarily provides confidence in the absence of specific behaviors
beyond what is called process assurance.
For security, the set of positive requirements generated in response to a security risk
analysis can be determined to be “correct and complete” (as possible). But unfortunately
it is this set of correct and complete (validated) requirements that “drive” all the forth
coming (down-stream) assurances (verifications, etc.), not the higher-level security risk
assessment and higher-level security objectives. Further, the “attacks” considered in
the security risk assessment cannot be captured as a precise set of input conditions
because they are a product of (unspecified, unstructured and malicious) human
Consequently it is desirable to produce assurances outside those assurances
(verifications) generated by the set of (validated, usually positive) requirements to gain
confidence of system response to human malicious actions.
ED-203A / DO-356A introduces the term “Refutation” to describe and collect assurance
activities as a method for airworthiness security. This term is new because current
versions of ED-202A / DO-326A do not use the term, nor do the safety standards (ED-
79A / ARP 4754A, ED-12C / DO-178C, ED-80 / DO-254, etc.). Even though these
standards do not use the term “refutation”, these standards do discuss many refutation
activities as part of activities associated with safety/security assurance objectives.
Introducing the term Refutation helps focus the assurance activities into an
Airworthiness Security assurance method.
The term “Refutation” can be used in the sense of demonstrating the absence of a
theoretical problem, as in refuting the allegation of vulnerabilities. Hence, security
refutation is demonstrating the absence of security problems.
Refutation activities challenge the hypothesis that the formalized requirements will or
have produced, a design and implementation that is sufficiently faithful to the higher
level objectives, from which the requirements were derived. Refutation activities act as
an independent set of assurance activities beyond those assurance activities driven
from the formalized analysis and requirements. Anytime system complexity precludes
exhaustive testing that an unwanted behavior never occurs, refutation can be used to
formally demonstrate that an unwanted behavior has been precluded to an acceptable
level of confidence.
In the case of security, the role of attacker can be assumed to be independent of any
assumption made by the developer and then captured by requirements. When refutation
Links Archive Navigation Previous Page Next Page