Home' RTCA Documents for Review : DO-356A Contents 50
© RTCA, 2018
called an inherent vulnerability. Inherent vulnerabilities are characterized by intended
system function which is accessible (or has become accessible) in a threat scenario. In
these cases the function is required to be present and intended to be utilized by trusted
personnel or in a specific manner.
Inherent vulnerabilities exist when an interface provides functions intended for access
by authorized entities (people or systems), but which can be misused to cause harm. It
is impossible to provide a function with the necessary authority to accomplish something
potentially harmful and at the same time prevent all harm from its misuse. Rather, the
entity that interacts with such a function must be depended on (or “trusted”) not to
misuse the function. Functions with such dependencies on external systems or people
possess inherent vulnerabilities in that the dependency on the external entity is inherent
in the design. At the same time it is explicit, and intended, in the design.
Threat Scenario Structure and Detail
Threat Scenario Identification Structure and Degree of Detail is largely left to applicant.
However the structure and degree of detail of the threat scenarios can have a significant
impact on the downstream development processes and the eventual LoT evaluation
and risk acceptability.
As an objective of threat scenario development, the specific security protections that
prevent specific threat scenarios can be used to generate traceable security
requirements (including functional, architectural and assurance requirements). These
requirements (also subject to validation/completeness and correctness and refutation)
spawn verifications in accordance with the assigned SAL/DAL. These verifications are
traceable back to the original requirements which in turn relate back to originating threat
The advantage is that the entire downstream development process is now traceable to
the assertions and assumptions made in the Threat Scenarios and Risk Assessment.
This has the advantage of reducing ambiguity in the LoT evaluation.
The security requirements are closely connected to the threat scenarios that it has to
protect against. The threat scenarios show:
1. The targets that are protected/mitigated by the security measure.
2. The assets on the attack paths that are protected/mitigated by the security
3. The assets that are exposed.
4. The assets that are protected/mitigated.
5. The level of threat that was used as part of establishing the overall acceptable
6. Vulnerabilities that are considered in establishing the acceptable security risk.
The threat scenarios show the attacks that are handled by the security measure itself,
so may be allocated to the functional requirements for the security measure, depending
on the type of the security measure. For example a technical measure may have
functional system/subsystem/item requirements allocated while an organizational
measure has security guidance.
The associations defined by the threat scenarios may be allocated to the architectural
requirements for interactions (e.g . data flows, interfaces) between the
systems/subsystems/items associated with the attack path.
Interactions that were not considered in the threat scenarios may be prevented by
placement of the assets in the security architecture so that protection and separation
requirements are imposed and by allocation of security requirements and assurance
actions to prevent unintended function. Chapter 5 provides more detail about security
There are probably as many ways to view the various threat scenarios involving a
firewall as engineers, but consider the following example breakdown of individually
considered threat scenarios:
Attacker reconfigures the firewall configuration
Attacker attempts to bypass and tamper with firewall
Links Archive Navigation Previous Page Next Page