EFB Tampering. Holdover Time

TL;DR

• Holdover applications are a relatively new method of calculating the effectiveness of anti-icing fluid sprayed onto aircraft wings. Applications such as these have additional attack surfaces as the developer and source databases need to be considered
• Airlines often view limits as targets to maximise efficiency and minimise cost. Regulators need to take this into account when creating cybersecurity guidance and rulesets.  When assessing risk, Regulators should assume that airlines will not comply with non-mandated guidance policies
• Applications distributed from public app stores are likely to be secure. Applications published on third party or internal sources won’t necessarily comply with the same secure coding guidelines
• PTP were able to modify manuals on an EFB – in extreme cases this could result in an incident or accident depending on the manual and information that were changed

Introduction

A quick search online for EFB applications shows plenty of third party software available to use on EFBs.  Many of these applications are available for download on public app stores.  Some of these applications are developed by small software companies, others by large well known software developers.  It is not for us to speculate how much involvement or oversight state regulators have had in the development and testing of these EFB applications, but we should keep in mind that there are thousands of EFB applications available and they can originate from anywhere in the world.

With regards to EFB integrity, often the complication with third party applications, as opposed to performance applications, is the added risk of using different data sources as well as the potential for using software which has not been risk-assessed or security tested to the same standard as that of aircraft manufacturers.  Performance applications will complete calculations locally and any required data is entered by the pilot.  Many third party applications complete calculations locally but require access to databases online to source required information.  In some cases, these databases are connected to other databases which feed into them.  This creates more attack surfaces for tampering with an EFB.

Regulation

Cybersecurity is a relatively new consideration with regards to operationally critical applications within the Flight Deck, hence airline cybersecurity policies are also relatively new and are being continually developed.

It is not uncommon for airlines to use regulatory “limits” as targets in an attempt to reduce costs.  The problem with this arises when Regulators create policy which they consider to be a limit but also include guidance along with it.  Phrases (or “grey” wording) such as “it is recommended” or “should be considered” are non-specific and place the decision with the airline, and wording of this nature is common in civil aviation guidance and policy documents.  In certain cases guidance of this nature is disregarded by some airlines.

As a strategy when assessing risk, Regulators should assume that airlines will NOT comply with guidance, because it is just that, guidance.  Where a cybersecurity policy is deemed important, it needs to be mandated.

Third Party Applications

Third party applications are downloaded from a variety of sources including public or company/internal app stores, or are web-based applications.  Applications which are distributed from public app stores, in particular Apple, have to comply with certain secure coding guidelines.  These applications are going to be more difficult to tamper with as at a minimum, guidelines will ensure strong TLS connections are used and clear text HTTP connections will not be made.

Applications published on third party or internal source may not have the same requirements for applications to be coded in a secure method.   This could allow for insecure applications to be distributed to an employee’s device, penetration testing and code reviews should always be undertaken on any internally developed or third party apps.

The security of the device itself will provide a level of protection.  A user having set a weak password, or even no password at all, could result in a malicious threat actor having direct access to any applications on the end device.  Any applications which provide sensitive information should require additional “in app” authentication, similar to what is used in banking applications.  Good practice would also dictate that an MDM should be used to push secure policies down to any devices which are used to access company information.  MDMs can be configured with a wide range of policies and checks, the most pertinent on an EFB would be:

• Ensuring the base OS is up to date, mitigating any OS level vulnerabilities
• Ensure that a strong complex password is set
• Ensuring that screens lock in a reasonable time after a period of inactivity (30 seconds – unless the application will be required for longer durations without interactions e.g. charts)
• Ensuring that a password is required as soon as the screen is locked.

Targets and potential data access/tampering consequences

Target:  AIRCRAFT MANUALS

Potential consequence:  Hull loss

Background:

Manuals are one of the most common items to find on an EFB and in some airlines the only function of the EFB is to enable storage and viewing of manuals.  This is for two reasons:

1. Cost saving due to reduced fuel burn (up to 100kg of manuals removed from every aircraft)
2. Ability to update manuals with more ease. Large airlines sometimes have to print hundreds of thousands of pages for a manual update, something that can occur relatively frequently.

There are benefits for the pilots too.  Routinely carrying heavy manuals around all day caused back injuries to many pilots.  EFBs also enable pilots to quickly search for items instead of having to manually flick through pages to find relevant information and enables easy updating.

Tampering:

PTP was able to modify manuals stored on an EFB.  The result of this when tested with airline pilots in our simulator was that when the pilots reviewed a particular manual for a specific item, the information displayed was incorrect.

Manuals we were able to modify on an EFB include:

• Flight Crew Operating Manual (FCOM): System information and description, procedures, limitations, normal and emergency procedures, supplementary techniques, performance data.
• Flight Crew Training Manual (FCTM): Practical and training-oriented information.  Contains techniques for flying the aircraft, in short a guide to flying the aircraft.
• Airline Operations Manuals (OM’s): Often divided into multiple manuals, these contain information, rules and regulations relevant to the airline as a whole (often not type specific). Commonly include fatigue and flight time limitations, emergency procedures, safety precautions, airline policies (fuel/diversion/minimum flight altitudes etc.), navigation requirements and a whole host more.
• Performance Manual: Take-off and landing performance data and calculations, runway degradation information, emergency procedure policies and data e.g. depressurisation and drift-down (engine failure above maximum one engine inoperative altitude).
• Checklists: Normal, abnormal and emergency.
• Minimum Equipment Lists (MEL) / Configuration Deviation Lists (CDL): Aircraft deficiency management and policy.  Approval of internal and external parts which may be missing or inoperative at the commencement of a flight as well as procedures for operating with inoperative parts.
• Weight & Balance Manual: Limits, instructions on how to load aircraft safety, centre of gravity considerations, requirements for loading of cargo and passengers.
• Bulletins and Notices: Updates and notices which contain important information relevant to the safety of a flight.

Discussing all the potential consequences of modifying manuals is an insurmountable task as almost any and every scenario is possible because it depends on what is modified and in what way.  Some of the potential outcomes from scenarios we created include:

• Mechanical failure
• Loss of control
• Runway excursion
• Loss of important systems e.g. hydraulics/electrics
• Operating outside the limitations of aircraft design
• Operating outside the limitations of the law

Example:

The Minimum Equipment List (MEL) is consulted when an aircraft has a deficiency or an inoperative component.  If it is permissible to fly with the inoperative item in question, the MEL will state the duration and any conditions that apply when doing so.  There are hundreds upon hundreds of items listed in the MEL, ranging from insignificant with no real noticeable change in procedures to potentially significant with pilots modifying their procedures to account for the inoperative item.

Having modified a MEL item on an EFB, commercial pilots in our simulator performed their tasks as if they were departing on a routine flight.  The scenario included an inoperative fuel pump – a not uncommon deficiency to fly with.

The correct MEL stated that the Rectification Interval was 3 days, i.e. the fuel pump may be inoperative for up to 3 days.  On the 4^th day after the failure occurred the fuel pump must be fixed otherwise the aircraft should not depart.  It isn’t the case that on the 4^th day it becomes unsafe to operate with that failure, instead the intervals are there to prevent airlines from operating aircraft with failures for long periods of time (bad practice).

Of more significance was the Operations Procedure which required minimum amounts of fuel to be increased in the tank.  This is to ensure the other operable pump in the tank is covered at all stages of flight and a failure to maintain the minimum stated fuel quantity would make it possible to starve the pump of fuel during certain manoeuvres.

The modifications we made included:

• Changing the rectification interval from 3 to 10 days
• Removing the Maintenance Procedure
• Modifying the Operations Procedure to state that a different pump would maintain pressure and that there was no requirement to maintain a minimum fuel quantity in the tank

Having reviewed the MEL, the pilots did not notice the error.

Correct MEL

Tampered MEL

It should be noted that in this scenario even if the fuel pump were to be starved, an engine failure is not a certainty – in fact in many cases it would still be unlikely.  The fuel would have to be at a relatively low level (for example on landing), and aircraft generally have a gravity fuel feeding system which enables fuel supply to the engine even with all pumps failed.  This however can be susceptible to the same issue – manoeuvring can prevent the flow of fuel to the engine.  However, even with one engine failed aircraft fly perfectly well and pilots routinely train for such events.

Some of the risk is mitigated through pilot and engineer experience – obvious errors would be likely to be picked up as pilots would recognise a change of policy.  Subtle changes could, however, be more of an issue as they are at greater risk of going unnoticed and subtle changes could still create dangerous situations.

Summary:

The potential for applying incorrect procedures resulting in an incident or accident could be significant depending on the manual that was tampered with.  The fuel pump example has been used to illustrate the kind of issues that could potentially be created by the modification of important information.

In order to achieve such an outcome a malicious hacker would need to have a good understanding of the manuals, procedures and systems that they intended to modify, as well as an understanding of what would flag up to pilots as obviously incorrect information.  Essentially, they would probably need to be pilots themselves.  The significance of all of this is that manuals such as those described above should be stored securely on devices, protected with security layers and only modifiable at the source – not on the device.

Target:  HOLDOVER APPLICATIONS

Potential consequence:  Hull loss

Background:  De-icing and Anti-icing

When it comes to cold weather pilots inspect the aircraft surfaces carefully prior to departing.  The reason for this is the presence of frozen precipitation on an aircraft can have catastrophic consequences.  In the aviation world, precipitation stuck or frozen to the aircraft is known as “contaminant”.  You may have seen a pilot walk through the cabin to inspect the wing of the aircraft prior to take-off, it is likely he is looking to see if contaminant is present on the wing.

In order for aircraft to “fly” the wing must generate lift.  Any contaminant on the wing disrupts airflow and therefore reduces lift.  This is why aircraft are de-iced prior to flight when departing from airports where there is cold weather.  It is common for airlines to have a “clean wing” policy, which means that no contaminant of any form (except de/anti-icing fluid) is acceptable on the wing, or horizontal and vertical stabilisers.  Other limitations exist for contaminant on the fuselage.

When aircraft are de-iced, they are sprayed with a chemical solution which dissolves any contaminant.  If icing conditions have passed (i.e. the wing/aircraft won’t ice up again) then de-icing is all that is needed prior to the aircraft flying.  However, when precipitation/icing conditions are still present, a protective layer is sprayed over the aircraft surfaces to prevent further accumulation of contaminant (ice/snow etc).  This process is called anti-icing.

There are a variety of different chemical solutions used to anti-ice aircraft.  Each chemical solution has a different holdover time and as aircraft wings are not all made of the same material, aircraft often have specific times applicable only to that aircraft type.

Once an aircraft has been anti-iced, there is a specific time window in which the solution should remain effective.  After this time, the solution may not prevent further ice accumulation and the pilots have to decide whether it is safe to depart or whether the aircraft needs another coat of anti-icing.  This time window is called the “holdover time”.

Sadly, there have been numerous accidents in the past due to incorrect assessment of the wing and also due to exceedance of the holdover time without another assessment being carried out.

In 1989 an Air Ontario F28 crashed after take-off from Dryden Airport.  The aircraft achieved 49 seconds of flight due to ice and snow on the wings preventing the aircraft from climbing and achieving sufficient altitude to clear the trees beyond the end of the runway.

Report: https://reports.aviation-safety.net/1989/19890310-1_F28_C-FONF.pdf

Video (animation):  https://www.youtube.com/watch?v=vV1gxJqZXL0

In 1992, a USAir F28 attempted to take-off with contaminant on the wings resulting in an aerodynamic stall and the aircraft crashing moments after departure.  35 minutes passed between leaving the stand and take-off (de-icing fluid used had a safe holdover time of 11 minutes).

Report:  http://libraryonline.erau.edu/online-full-text/ntsb/aircraft-accident-reports/AAR93-02.pdf

Holdover calculation and applications:

The method of calculating holdover time has generally been via a paper chart or PDF on an EFB (see tampering with aircraft manuals above).  However it has been difficult to make the calculation precise since a variety of factors need to be considered.  Therefore, holdover times have been traditionally quite conservative as the charts were unable to take into account all the different weather possibilities, hence they made “worst case” presumptions about the conditions.

More recently, holdover applications have been developed by various software companies.  These applications are particularly useful as they calculate the holdover time for the pilots, and crucially some of them use actual weather information for the airfield in question instead of generic data.  This has the added benefit of creating a more precise calculation (generally a longer holdover time) by using present airfield meteorological data and can prevent costly delays, aircraft returns for more anti-icing and extra fuel cost.

Image 1:  Data entry in Holdover Time Calculator

In terms of threats, remotely tampering with an installed application on an EFB is going to be difficult, but tampering with the weather data obtained by the application may not be as much of a challenge.  As a result the many of the thousands of airport weather stations worldwide along with their internet connectivity and data transfer security should also be considered.

Example:

Image 2 below is an unmodified holdover time application which has calculated that as a minimum the anti-icing fluid should be effective until 11:56 (55 minutes duration after fluid application).  As a maximum, it may still be effective up until 14:31 (210 minutes duration).  Once the “minimum end time” has passed, pilots would be likely to have the wing re-assessed for contamination.  Note the temperature in the image:  -5⁰C.

Image 2:  Correct holdover time calculation

Having modified the temperature at JFK from -5⁰C to -3⁰C (a subtle change that is unlikely to be noticed), the application produced entirely different results for the holdover time calculation (see Image 3).

Image 3: Result of manipulated airport temperature on holdover calculation

The pilots would now expect the anti-icing fluid to be effective up until 13:11, some 75 minutes AFTER it has potentially become ineffective.  The result of this would be that they would be unlikely to reinspect the wing or have another coating of anti-icing until after 13:11, so it would be perfectly acceptable for them to take-off at say 12:56 – one hour after the correct minimum end time.

Why couldn’t pilots simply go and check the wing from the cabin?  Well, they could.  However, it is rather difficult to assess the state of the wing from the cabin.  The fluid would still be present (it generally looks like green or orange slime), and the wing would appear coated.  It is almost impossible to accurately assess whether the fluid is effective or not from inside the aircraft – inspections of this nature are of more use to determine if anti-icing is needed in the first place, not whether the anti-icing fluid is still effective.  It is the holdover calculation that primarily assesses the effectiveness of the anti-icing fluid.  In this scenario the pilots’ impression would be that the anti-icing fluid on the wing was still effective and working, when it isn’t.

Summary:

3^rd party applications such as Holdover Time Calculators are critical to the safety of flight.
The security of applications that aren’t in public app stores but are used by pilots should be considered by airlines whose pilots or crew use them.  The coding of these applications should be reviewed to ensure they maintain a similar if not better standard of security than the applications in public app stores. MDM really becomes critical here – if none exists then the security of the device could be questionable, if it does exist then the policies need to be reviewed and updated frequently.  The security of the data sources e.g. airport weather stations and their internet connectivity also need to be scrutinised.

Other notable incidents/accidents:

• Scandinavian MD-81 at ARN in 1991. Ice accumulation on the wings prior to departure broke away from the wings and was ingested by the engines resulting in the failure of both engines.

Report: https://reports.aviation-safety.net/1991/19911227-0_MD81_OY-KHO.pdf

Video:  https://www.youtube.com/watch?v=xzNkx1vBTJQ

• Air Florida 737 at DCA in 1982. Aircraft attempted to take-off with snow/ice on the wings which resulted in the aircraft being unable to climb and colliding with a bridge over the Potomac River.

Report:  https://www.ntsb.gov/investigations/AccidentReports/Pages/AAR8208.aspx

Video: https://www.youtube.com/watch?v=6ckGmOgdMXY

• Continental Airlines DC-9 at DEN in 1987. Aircraft stalled on take-off as a result of ice on the wings.  NTSB final report states “accident is attributable to the Captain’s failure to have the plane de-iced a second time”

Report: https://www.ntsb.gov/investigations/AccidentReports/Reports/AAR8809.pdf