By Joe Wlad
By now, you’ve likely heard the latest report of security holes in unmanned ground control systems. This time, a key-logging virus has been found on one or more hard drives at the Nevada operations center for the Predator and Reaper unmanned vehicles. While the investigation is ongoing and impact of the virus is determined, the real concern is just how vulnerable are these systems and what might happen next? This is not the first time security gaps have been uncovered in unmanned vehicles. In 2009, Iraqi insurgents were able to intercept unencrypted video feeds from operational Predator UAVs using inexpensive software downloaded from the Internet.
People in the public and private sector are expressing deep concern over how things like this can happen and to how address these problems. As for the “how we got here” question, it’s relatively simple to answer. Essentially, the unmanned air vehicle has been a victim of its own success. Many of these programs, Global Hawk, Predator and others were never designed to be deployed in operational environments. In fact, the DoD in many cases, sought to build these vehicles as prototypes or proof-of-concepts. When the programs were awarded, the diligent contractors for these vehicles used the best of commercial technology to demonstrate the capabilities. The hope was that successful demonstrations would lead to production contracts where the systems could be designed to meet specific security and safety requirements.
However, the demonstrations went so well and the need for support in the war zones in Iraq and Afghanistan led the DoD to give operational birth to these systems before many of the safety and security requirements could be fully addressed. The designers of these vehicles built ground control stations using standard Windows and Linux platforms. They may even be using a virtualized platform based on either open-source or proprietary type-2 hypervisors like VMWare. It’s likely the operators who control the vehicles use standard methods of moving information to and from the UCS platform. This might include the use of removable media which is one of the suspected channels for propagation of the virus in Nevada.
To address the virus issues, the DoD must implement a routine of identifying security loopholes and vulnerabilities as they appear and then fixing each one – the so-called, patch-and-hope tactic. There is a better way to address these issues, and in time (we hope before the next problem appears) the DoD will deploy the next-generation of Unmanned Control Systems (UCS) which will be designed to address both safety and security requirements. This architecture will help operators avoid the problems of the past and ensure future unmanned systems are safe and secure.
Wind River is a member of the UCS Working Group and we are playing a big role in helping to define the safety requirements for the next-generation of UCS. This working group and the DoD have a goal to ensure that all of these systems are interoperable, safe and secure. At the foundation, the UCS architecture is defined as a partitioned platform where separation is provided by a time/space partitioned operating system which supports open standards such as ARINC653 or POSIX, cross-domain services for high assurance and mixed levels of safety criticalities. The exact architecture for any specific UCS platform can vary based on the use case.
There are a number of different use cases for these architectures, called deployment views. The UCS architecture can be fixed (as in the case of the operations center in Nevada), transportable (meaning mobile, but enabling direct vehicle control) and dismounted (meaning mobile and agile, but not necessarily enabling direct vehicle control). In each of these scenarios, the safety and security requirements of the UCS will vary. A UCS designer could use one or more of our products to address safety, security or both safety and security requirements, depending upon the use case of the UCS.
For the fixed system, the UCS designer may take advantage of Wind River MILS as the architecture solution which enables and supports DO-178B, Level A and Common Criteria EAL6+ certification. VxWorks MILS will provide UCS designers with the safety and security protections needed by fixed-platforms plus it will provide a migration path for software applications written on Linux or Windows platforms because both Windows and Linux are supported as guest operating systems on VxWorks MILS.
For the transportable or dismounted UCS platforms where security may be paramount, designers could use Wind River Linux Secure (which is certified to meet the Common Criteria security standard to EAL4+ or they could use our standard Wind River Hypervisor (which supports DO-178B, Level A requirements) for platforms where only safety is paramount. Additionally, all of our technology can be augmented with application run-time protection from McAfee. Wind River is working closely with our partner company, McAfee, to bring virus protection, security intelligence and threat assessment capabilities to embedded applications. The combined capabilities of Wind River and McAfee will enable future UCS application developers to protect us all from unwanted and potentially harmful behavior of unmanned systems.
For those who are interested in the specific safety and security requirements being addressed by the UCS Working Group, they are summarized below. :
- NATO STANAG 4671: UAV Systems Airworthiness Requirements
- RTCA DO-178B: Software Considerations in Airborne Systems and Equipment Certification
- DIACAP: DoD IA Certification and Accreditation Process
- CNSSI 1253: Security Categorization and Control Selection for National Security Systems
- MIL-STD-882D: System Safety
- MIL-HDBK-516B: Airworthiness Certification Criteria
You can learn more about UCS and the evolution of the architecture at: