White Paper

Whitepaper: Building Safe and Secure Systems for Autonomous Platforms

Issue link: https://read.uberflip.com/i/1427516

Contents of this Issue

Navigation

Page 6 of 7

WHITE PAPER Building Safe and Secure Processing Systems for Future Autonomous Platforms mrcy.com 7 The goal is to ensure that responses to new security threats do not affect the safety of the system and, likewise, that the static nature of present safety systems does not force known vulnerabilities to persist in the field. As alluded to earlier, a malicious actor with a foothold in a system can degrade safety faster than any component failure. To this end, the modern defense industry is creating new holistic capabilities and approaches that address the need for safe and secure mission-critical systems. Using Kerckhoffs' principle to disclose information Kerckhoffs' principle for general security states that "a cryptographic system should be secure even if everything about the system, except the key, is public knowledge." In other words, by designing a system according to Kerckhoffs' principle, the public availability of system blueprints will provide an adversary no leverage as all security is reliant on the key, which is unavailable and undisclosed. This allows physical security techniques like algorithms to be exposed for broad scrutiny as part of the safety-certification process. Minimizing "detect and react " strategies Systems security engineering should either minimize reliance on detect and react strategies or minimize the impact of potential failures through failure mode effects and criticality analysis (FMECA) or other analysis methods. This reduces the need for situational awareness to determine if a hurried retreat to a more secure state is required because, if all states are equally secure, no action is required. Modern cockpits feature large screens to display fused sensor, navigation, environmental, threat and mission information. They all require various levels of safety certification and security for deployment. Another approach that minimizes the impact of detect and react in safe systems is to restrict the asynchronous nature of these reactions by establishing a set of limited threat-detection reactions. Limiting the breadth of these reactions aids system determinism and mitigates any detrimental effect on these systems. Fault-tolerant responses also reduce the impact of detect and react. When implemented, the reaction to a detected cyber event is to move to a redundant container while cleaning the infected one, although this approach introduces its own issues, as redundant processing schemes are, by their very nature, a security risk. In general, "detect and failover " can be easily made consistent with safety, while "detect and change" behavior is more problematic. Treating software as a control path When you treat security software in a manner analogous to how maps and charts are treated on an aircraft, continuously changing components (virus definitions, for example) are treated like data, while the software that manages, manipulates and controls those changes is assured as safe and only modified if rigorous, overseeing control processes are in place. This approach may be viewed as an extension of DO-178 and DO-326. Architecting a system with isolation Looking to the future, the imposition of strong architectural partitions offers promise as a means to limit the ripple effect of changes across a system. For example, if a container for "untrusted, non-safety-certifiable" software can be established and adequately isolated from safety-critical processing functions, it could be argued that the container 's software could be arbitrarily replaced without reassuring the system because the container has no influence. This would allow features to be updated without the need to recertify the entire system. Isolation reinforces security because attacks would be contained, thus minimizing attack surfaces.

Articles in this issue

Links on this page

view archives of White Paper - Whitepaper: Building Safe and Secure Systems for Autonomous Platforms