Home' RTCA Documents for Review : DO-356A Contents 86
© RTCA, 2018
Principle 10 – Partitioning
Architecture Principle 10:
Systems should share resources (software / complex hardware) only with other systems
that share the same security assurance level. Otherwise, security measures should be
employed to reduce risk between systems of differing security assurance levels.
If resources are shared between systems that have different security assurance levels,
an opportunity exists for a system of a higher security assurance level to be exposed to
the vulnerabilities of the lower security assurance level connected system.
Due to this concern, systems should be designed to partition resources (software /
complex hardware) into groups with similar security assurance levels. Where it is
necessary to share resources between systems of differing security assurance levels,
effort should be made to control those interfaces from exploitation. Wherever possible
the security assurance levels of the two systems should be made equal to the system
with the highest security assurance level to ensure the vulnerabilities of the lower
security assurance level system cannot be used to access the higher security assurance
SECURITY ARCHITECTURE AT ITEM LEVEL
This section examines security architecture principles at the Item Level.
Before system development can start, an item architecture is to be developed. This is
on the one hand the arrangement of physical components (hardware) and its interfaces
and on the other hand the software architecture (software components and its
interfaces). For the physical architecture, decision with regards to electronic
components (e.g . Program Logical Devices, power sources, etc.) and their interfaces
should be made. For the software aspects, operating systems, middleware, application
concepts, virtualization techniques and their interfaces need to be defined. When
defining the architecture, Attack Path Refinement should be performed to ensure that
the Security Measures defined at system level are adequately represented by the
implementation choices. It is likely that bypasses to Security Measures can be found
when developing the Security Measures only for functionality without assessing all
logical layers of attack.
Principle 11 – Ensure Proper Error Handling
Architecture Principle 11:
The item’s software should account for and properly handle input / output exceptions.
Exceptions that are not properly handled can result in item reboots and / or crashes.
Effort should be made to ensure software is designed to properly handle exceptions
caused by out-of-bounds inputs / outputs. A simple input error, whether that input is
from a malicious source or from user error, can result in undesired item behavior. In
some cases, the undesired behavior can be a forced reboot or crash which may impact
A significant amount of security vulnerabilities results from improper exception handling.
When software is properly designed to handle exceptions, it leads to an item that is
Principle 12 – Least Privilege
Architecture Principle 12:
Roles and permissions should be assigned at the lowest level required to accomplish
By segregating duties and times that items are accessible to any one function, you limit
potential damage that may be caused by errors, accidents or unauthorized access.
Links Archive Navigation Previous Page Next Page