Home' RTCA Documents for Review : DO-356A Contents 278
© RTCA, 2018
USING DOMAINS TO DESCRIBE SECURITY ARCHITECTURE
One way to describe security architecture is through network based domains. While
domains can be used by the applicants at their discretion, they are not required,
therefore the domain discussion is limited to this appendix.
Networks have become more common within aircraft and provide greater connectivity
between systems than legacy point-to-point databuses. This enhances capability but
increases potential threats. Networks can be described as a domain with specific
architecture, perimeter and policies.
A domain as defined here is an architectural element finer than a domain of functions,
but potentially coarser than a network or subnetwork. The requirement is that a domain
is a set of controlled architectural entities in the sense that inter-domain communications
are subject to specifications and interface requirements. A domain is a collection of
technical requirements, and not an assurance domain.
Security (sub) domains can be defined hierarchically, and so can be
applied at any level of requirements management: aircraft, system, or
Security domains collect and manage functional requirements, and use Domain Control
Policies to manage the interaction and expectations between the domains. Security
domains aid in the communication of security risks and mitigations and simplify the
identification of overlapping requirements identified through the safety process.
Allocation of devices and networks to domains can be made on any basis, but one
important example is ARINC 811 and 664 Part 5 which provides for domains defined
primarily on the basis of functionality.
However, purely functional domains are insufficient for managing security policies. If
functional domains are to be used as part of the security measures, as security domains,
they need to be managed as part of the security architecture and security requirements.
Functional domains have been defined in special conditions and provide means to show
that those domains are identified and controlled and perform as an effective security
The reason for using security domains is to be able to create a level of architectural
security separation between domains based on the domain specifications themselves.
Capture current practices in safety assurance and network architecture,
Abstract those properties that would be most useful to security architectures and
Offer a unified approach to capturing trustworthiness relationships between
devices and networks in a heterogeneous architecture, and
Offer a unified approach to managing trustworthiness relationships between
domains in a heterogeneous architecture.
Within this guidance, a domain allows control of the local interfaces between domains,
similar in intent to Interface Control Documents, as the means of providing control of
Domains are not, and cannot be, completely separated from each other, due to the
heterogeneous communication requirements of modern aircraft systems.
Assigning domains simplify the task of assessing technical requirements by providing
separation properties. They will include systems of various assurance levels.
Links Archive Navigation Previous Page Next Page