Deploying EFBs securely

It may come as a surprise to some to discover that electronic flight bag security at airlines is often quite variable. Whilst some use an MDM, a lot don’t. Of those who do, PINs are often weak. Some airlines actively encourage pilots to use their devices for personal use. We’ve heard stories of an EFB being passed to the pilot’s kids to watch Netflix on, whilst driving to the airport.

That said, there are a number of challenges for EFB security that make a conventional corporate-style lockdown unsuitable. An outage of an EFB app can ground a fleet, so care and testing is needed. Finding the right balance of security requires an assessment of the risks involved and a deep understanding of how these devices are used in the cockpit and during pre-flight planning.

Here are some thoughts on the subject; thoughts for some airlines who we believe need to do more to secure these devices:

Generally, dual business/personal use of an EFB should be discouraged. An EFB is a safety-critical device; it’s not for watching Netflix, personal email and web browsing. Whilst MDM vendors may argue that allowing flight/personal use is fine through segregation, we’re not so sure.

Portable EFBs

I’ll start with iOS, as it’s probably the most popular EFB platform and perhaps the easier mobile platform to secure:

Use a mobile device management platform (MDM) that offers containerisation rather purely policy enforcement

This brings encryption, segregation, a VPN equivalent and strong device security controls. Jailbreaking, for example, can be controlled and managed to ensure that sensitive data and safety critical apps are protected

Using the MDM, remove the AppStore from the device. Instead, use the ‘store’ function from within the MDM, allowing much more control of the apps that can be loaded. This also allows operators to push their own apps and run them in the secure MDM enclave on the device. Consider also removing the web browser from the device, using a browser provided by the MDM instead. Again, this offers greater control over content.

Create a testing environment on the ground where system and app updates can be quickly tested for stability. This means that updates can be deployed quickly, to ensure that devices remain secure.

Track and monitor the operating system and application versions on the EFBs. Whilst auto-pushing updates would be unwise, given the potential for an update to be installed at a critical phase of planning or flight, devices can be monitored and action taken if the users do not apply updates.

Authentication to the iOS device must be addressed. We have seen EFBs without PINs, also EFBs with a PIN that is the first four digits of the pilot’s birthday. This simply isn’t acceptable, as it offers little to no protection to the device.

Whilst pilots may counter that PINs can be hard to remember, using an MDM allows for remote unlocking by ground operations if the PIN has been forgotten.

Biometric authentication such as FaceID is a must, but it should also be underpinned by a 6 digit PIN that is not a crew birthdate!

Careful consideration also needs to be given to screen lock timing. On the ground, one would ideally lock the screen after a few seconds, to prevent unauthorised tampering, however one does not want a short lockout time in the air. FaceID makes unlocking easy, but not if the pilot is sporting sunglasses or wearing an oxygen mask whilst dealing with a cabin decompression!

Further, Quick Reference Handbooks (QRH) for dealing with emergency conditions are starting to move from paper to EFBs. The last thing a pilot needs when dealing with an airborne incident is to spend valuable seconds unlocking an EFB. Some EFB charting and perf apps prevent the screen from locking when they are in use. This is a great move, but if one navigates away from these apps, the device screen lock settings will take over.

A compromise may have to be found. One solution might be to work out a method to prevent the EFB from locking if ground speed exceeds say 50 knots, perhaps in a reverse of ‘driving mode’?

Android

Given the reduced control over the ecosystem compared to iOS, Android devices can present more security challenges. Operating system updates can be delayed as they filter through layers of QA and customisation from Google to the device manufacturer to a cell carrier and finally to the device.

Choose Android devices where the ‘lag’ from Google to device is as short as possible. Examples of this include the Google Pixel Slate and Samsung Galaxy range of tablets, among several brands.

Rooting (aka jailbreaking) of some Android devices can be very easy with some devices, though others are much harder, hence even greater requirement for an MDM compared to iOS.

‘Sideloading’ of custom apps from SD cards or over USB is also easy through the Android Debug Bridge (ADB). Hence, it is important to disable USB connectivity and the SD card. This may bring practical challenges, but can be an important step in securing Android EFBs.

Follow similar lock-down steps as with iOS: MDM, strong PIN, removal of the browser and apps outside of the MDM, biometric auth, screen locking, a testing environment for update stability evaluation.

Android also offers a ‘kiosk’ mode which may be useful for an EFB with a small number of applications

Android devices are considered to be a little more exposed to viruses and malware than iOS devices, though a strong lock down and MDM should prevent these becoming an issue. You may want to consider running an anti-virus / anti-malware package.

Windows

Whilst less common in the cockpit than iOS and Android, some EFBs run Windows. The lock down requirements vary significantly between the version of Windows in use and the interfaces presented by the device.

Microsoft offers strong device management through Active Directory or InTune, so a conventional lock down that one might apply to a laptop user would be a good start. That said, any lock down can be undone through poor choice of local admin credentials.

Bear in mind that there may be some custom requirements for an EFB that would make a ‘corporate laptop’ style lock down inappropriate. A program of evaluation would be wise, working closely with your pilots

Connectivity

Consideration should be given to maintaining remote connectivity for updates for both the operating system and software. Some EFBs may be used for in-flight updates of weather, NOTAMs, routing etc, though this is operator-dependent.

At home bases where there is corporate Wi-Fi, a device profile can be pushed via MDM. When away from base, consideration should be given to using an integrated SIM for cellular access.

Use of free Wi-Fi (hotels etc) should be discouraged or blocked. In flight, it’s advisable for EFBs to connect to a separate Wi-Fi access point, rather than the cabin passenger Wi-Fi. Whilst a good lock-down of the pax Wi-Fi network will mitigate risk, having a separate network for flight operations is wise. This is increasingly important as EFBs start to interface with the FMC and cockpit displays.

As the passenger Wi-Fi network connectivity is likely to be delivered by a third party, it has the potential to become congested if large numbers of passengers use it concurrently. By having a separate SSID, the operator has greater ability to control network quality of service (QoS) and ensure that critical EFB traffic is prioritised.

Additional considerations

An EFB may contain electronic Passenger Information Lists (ePIL). In some countries there will be additional regulatory overheads on personally identifiable information (PII) that mandate a certain level of lockdown that is at odds with practical use of the EFB in flight operations. For example, one privacy regulation requires a minimum 8-digit PIN on a mobile device containing PII, plus an auto-screen lock after 60 seconds.

Summary

Electronic flight bags bring safety, weight, cost and efficiency gains. They are here to stay and their use should be encouraged.

However, some airlines have not got the balance between usability, functionality and security quite right yet. That needs to be addressed.