Home' RTCA Documents for Review : DO-356A Contents 281
© RTCA, 2018
external to the domain, and any internal safety-related security requirements and
objectives which apply to communications between neighboring devices within the
domain. They also specify those security requirements that might be applied to the
domain devices, but for which the domain itself takes responsibility.
Examples of possible contents of domain control rules and requirements include:
Allowed open ports and protocols and services,
Protocol restrictions across boundaries,
Technical requirements for authenticated logical channels such as VPN or SSL,
Associated security assurance requirements for the domain and for its devices,
Technical requirements for communications between particular domains, such as
from a passenger domain to a private domain, and
Safety-related security requirements and objectives for communication within the
A normal use of a domain will be to prevent devices outside the domain from
communicating or interfering with devices in the domain except for the authorized
connections with boundary devices. Non-boundary devices should satisfy security
requirements associated with the threat from their intended communications within the
domain, but need not consider the threat from unintended communications from outside
the domain, except if the severity of the impact of their failure is higher than is
appropriate for the assurance level of the domain. Boundary devices should consider
the threat from unintended communications from outside the domain since they are
open to such communications.
Domains may be used to provide confidentiality between devices internal to the domain
and external to the domain. Practically speaking, this use is limited to the extent that
confidentiality can be expressed in terms of allowed communications between devices
due to the technical difficulties in finding effective mechanisms for a third-party boundary
device to detect the passing of confidential information.
In the case of security, many of these separation requirements will be in the form of
prohibitions against certain forms of functionality (e.g ., limitations on dynamic ports,
limited access without authentication, no unspecified services), which can provide a
challenge in the verification phase and in the allocation of responsibilities between
developers and integrators.
It is possible and common-place to have a mix of assurance levels within a domain.
Often the point of specifying a domain with an assured boundary is to provide a “safe
haven” for weak systems and hosts. The overall security of the domain then depends
on complete control over the external interactions by the assured devices. (See the
discussions below on “intrinsic” and “enclaved” domains.)
Thus a domain will often accommodate a range of assurance levels for the devices and
networks which are allocated to a particular domain. There is no a-priori assurance
requirement for particular assurance levels or limitations, but designers may choose to
enforce such a range.
It might make sense that a dedicated line of defense has a similar security assurance
applied. The security assurance level should be driven by the target of the threat
scenarios that are protected by the security measures between the threat vector and
the target. A domain approach usually bundles many threat scenarios and protects them
with shared security measures.
Technical Basis for Network Security Domain Control
There are potentially many technical solutions for controlling and separating domains.
It is the purpose of this section to establish three broad classes of technical measures
that are common in airborne systems.
These definitions are dissimilar to traditional national security architectures in that their
emphasis is on integrity and availability over confidentiality. Airborne networks and
devices are traditionally designed with integrity and availability always in mind. For most
data, confidentiality has not been assessed as a significant airborne system concern.
Where it is a concern, specific provisions for confidentiality of that data may be made.
Links Archive Navigation Previous Page Next Page