Home' RTCA Documents for Review : DO-356A Contents 87
© RTCA, 2018
Wherever possible, items should be designed to allow for different levels of permissions
to limit access, i.e. no one item should have access to read, write, edit or execute within
the same role.
Privileges should be granted based on need and time. Therefore, assigned privileges
should be the minimum required to accomplish the functionally assigned tasks only
By implementing this principle, the potential impact of any errors, accidents or
unauthorized access to the item is minimized. This leads to a more secure item.
Principle 13 – Control Access to Connections
Architecture Principle 13:
Connections that are accessible to unauthorized users should be eliminated, or they
should be access-controlled.
If connections to items are accessible to unauthorized users, one should assume the
item can be exploited.
Once directly connected, one should assume that an attacker can then take advantage
of any trust relationships that item has to others in the system, easing an attacker’s
propagation through the system. This can potentially magnify the effects of a security
vulnerability. All efforts should be made to eliminate or control access to these
SECURITY CONSIDERATIONS IN AIRCRAFT DEVELOPMENT
Information Security introduces challenges in the aircraft development and in-service
processes. Special precautions need to be applied during the development process, to
address Security demands. The principles in this document aim to also address these
Security Measures need to be effective. However, Security Measures might weaken
over time. This can be due to a hardware or software vulnerability of the Security
Measure itself or in an independent object. In this case, a fix of the security vulnerability
should be available very quick. Refer back to Architecture Principle 8.
Security assurance levels call for activities that demonstrate that the fix is mature.
Additional testing and documentation might delay the implementation of a “hot fix”.
Intelligent architectures rely on Security Measures of both higher and lower assurance
levels so that such hot fixes can be applied on Security Measures with lower assurance
levels without losing the end-to-end security level that are ensured by the combination
of all Security Measures.
Security in Service
Security of components does not stop at its end of development. The ability of an
attacker to access traditional ground-based IT systems as well as aircraft systems is
increasing over time. New attack techniques are invented. Vulnerabilities become
known by the public. What is assumed to be secure today is not necessarily secure
This needs to be anticipated during aircraft development and architecture definitions.
The security architecture needs to be adaptable to a certain extent. Different security
barriers with different properties need to be developed so that a failure of one can be
compensated by another. This needs to be done in an intelligent manner so that it is
applicable for each Threat Scenario.
Verification, Validation and Refutation of Security Requirements
Requirements-based engineering defines the requirements a product shall comply with.
Testing ensures each requirement is verified to work as expected.
Links Archive Navigation Previous Page Next Page