Security Through Patching versus Architecture and Transparency
January’s somewhat abstruse announcement that LYNX Software Technologies’ MOSA.ic framework will be used to support the mission avionics component of the F-35’s Technology Refresh 3 (TR3) modernisation programme really is a big deal: it illustrates the depth of the US DoD’s commitment to the Modular Open Systems Architecture (MOSA) approach to computer systems in its flagship programmes and beyond.
Within the F-35 TR3 effort, MOSA.ic will be used to support development of the Integrated Core Processor, which is being undertaken by L3Harris and which processes data for the fighter’s communications, sensors, EW, guidance and control, cockpit and helmet displays. MOSA.ic supports a variety of operating systems such as LynxOS-178, Linux, Windows, third-party real-time operating systems and so-called ‘bare metal’ applications – programmes that run directly on processor chips without an operating system in between.
Central to MOSA is the use of standardised, publicly-available interfaces, through which modular chunks of software and hardware communicate. The big idea is to make it much easier and quicker to create and update the complex computer systems on which all modern platforms, weapons and supporting systems rely – on an almost plug-and-play basis – while eliminating dependence on any one supplier. This presents inherent risks that demand a comprehensive approach to cybersecurity, because MOSAs potentially create monocultures in which multiple systems have the same vulnerabilities, and a single exploit can work on many applications.
One expert cautioned that openness disseminates methodology widely and leads to the emergence of a loose community of users, implementers and observers with access to and understanding of the interface standards. This provides opportunities for adversaries and hackers to study the standards for weaknesses and potential attack vectors. He further emphasised that every interface is also a potential vector, because its very purpose is to move information into and between elements. The community itself might implement system components with different levels of rigour or security, and each component might contain an exploit.
Risk mitigation, he said, depends on understanding such communities and a commitment to the enforcement of standards, as well as continuous maintenance of the architecture and models by DoD and industry, with careful review of what is included when MOSAs are implemented. A vulnerability monitoring group should keep an eye on both standards and processes, while a robust quality process should be applied to all stages of implementation. Further, a list of vulnerable or bad implementations and practices for the architecture should be made available.
LYNX describes MOSA.ic as a development and integration framework that supports this kind of approach by enabling the creation of complex multi-core safety or security systems from simple, verified components. Lynx CTO Will Keegan stated that size and complexity within software components mitigate against their thorough examination and lead to programmes that have to be patched to correct bugs and vulnerabilities. “This strategy of implementing security through patching doesn’t make sense to us, and we really need to provide technology that just works,” he said. “We do that through architecture, we do that through transparency, we do that through verification of how interfaces work together and what those components are.”
As an idea, computer systems that work reliably and securely out of the box and never need patching have a whiff of the Holy Grail about them – whether they are open or not.