Re: [SystemSafety] GAO report on FAA cybersecurity vulnerabilities

From: SPRIGGS, John J < >
Date: Thu, 30 Apr 2015 07:42:07 +0000

I misunderstood the original posting because the "Ethernet" bus is an ARINC bus too, ARINC664.

-----Original Message-----
Sent: 27 April 2015 16:14
To: Peter Bernard Ladkin; The System Safety List Subject: Re: [SystemSafety] GAO report on FAA cybersecurity vulnerabilities ... and an instance

I was not really taking into account the strength of the network but more basically the physical access. The question is: Are the ARINC buses ou the critical avionics boxes physically interconnected to the Ethernet buses (both technical in the cockpit and entertainment in the cabin) ?

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82

-----Original Message-----
Sent: Monday, April 27, 2015 6:30 AM
To: RICQUE Bertrand (SAGEM DEFENSE SECURITE); The System Safety List Subject: Re: [SystemSafety] GAO report on FAA cybersecurity vulnerabilities ... and an instance

Hash: SHA256

On 2015-04-20 10:15 , RICQUE Bertrand (SAGEM DEFENSE SECURITE) wrote:
> I am rather skeptical. The avionics are on ARINC bus, and even if it
> is connected through a firewall to an IP network (why ?) I don't see it can be possible to enter an avionics box.

Firewalls aren't necessarily invulnerable. Why, Sony had firewalls! It didn't stop one of the world's poorest states distributing their private internal communications to the world. And you don't need to hack into a box to influence critical control. You just need to add/alter/remove messages on a communications network.

My opinion about physical separation, or an "air gap" as it's called, is hardly unique amongst security people, in fact it's the norm.

What do you think is so special about ARINC buses? ARINC committees are not necessarily renowned for their digital-security expertise. Are ARINC 429 and ARINC 629 buses perfectly secure? That rather depends on your threat model, I would say :-) .

At the time of MH 370 I spent a little time educating myself about the SAFEbus (ARINC 659). One of the designers is here, and the other on another mailing list, and there are also other avionics specialists here who have worked with it who were helpful. I am fairly convinced that SAFEbus is impervious to spurious messages and message loss, because it has a form of ID-less slot-based one-to-one communication protocol whose scheduling is unique to the individual aircraft and must be known in advance - it's not practically detectable through experimentation.

Two pieces of flight-critical kit have exhibited failure modes, generating pilot-uncommanded pitch excursions; one on the Boeing 777 in 2005 out of Perth, and the other on the Airbus A330, in 2008 also near Perth (twice!). Both of these occurred after the respective aircraft types were more than a decade in service. Such anomalies are inadvertent failures, and the conditions under which they occur have a random (therefore statistical) nature.

But security penetrations do not have a statistical nature. Firewalls as as "fit for purpose" as anything else (I grant it is likely fair to assume that avionics firewalls are a little more robust than Sony's). The likelihood of penetration is (in my terminology) quasi-Boolean - it is largely dependent upon a competent penetrator having a go at the kit, and whether such a penetrator is having a go or not at a specific time is not a statistical quantity in any reasonable sense.

I don't know why you would think penetrating an avionics box should be necessary. All that's necessary to disturb operations is to affect the messages on the communications buses. Take a look at Ross Anderson's Cambridge group's experiments with actual bank ATMs. The protocols of the ATMs supposedly use quasi-real nonces belonging to pseudo-one-time pads, but the group found that a significant number of ATMs *in their neighborhood* were vulnerable to replay attacks!

A number of years ago, Ross and colleagues discovered that the lauded chip-and-PIN protocol used in European bank cards was broken, and wrote an award-winning paper saying so and showing how. Of course, they had already informed banks in plenty of time about the vulnerability, to give them time to fix it. And the banks had done nothing. They said "that's not a practical attack". So a little time later, a student build a piece of HW to exploit the attack, and successfully demonstrated it on video at a local bank branch (with of course the organisational cooperation of the branch). The response of the banks was to try to pressure the university to suppress the M.Sc. dissertation. They didn't succeed.

Now, banks are relatively digital-security-aware organisations, since they lose untold sums in "wire fraud" every year and have done for decades. Nevertheless, as the examples show, they do some odd things, such as trying to ignore pervasive security problems. Is avionics different? Much of the avionics flying around today has not necessarily been co-designed by security experts. Even were the protocols to have been designed by security-aware people, the threat model is changing - attacks are possible today that would have been regarded as implausible at the time of design. There is an FAA survey of data-transfer technology in DOT/FAA/AT-09/27 at Which of those protocols do you imagine are *not* vulnerable to attack?

PBL Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Je suis Charlie Tel+msg +49 (0)521 880 7319

-----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJVPbs6AAoJEIZIHiXiz9k+l6EH/2IrI7eV1p/vVSpB1cRc1cRW sapr/CY/wPI2FjBsVeddYtVZNbIYFELq3wsSlIyB42SNXlxWRp/2vJE2CsYr2tq7 Psc92hmNaVNqY/KG+hdqpa3nBZE5IhyHEHUm2KM8LBgVq9IUKINS5V0iQwoNlixN sHAX7G7KxAOQisXL9Cg4VVu739+H7H2USNNQXFp9xc2iz204FoDX25j8WFl7lBXD zN3ZKLuJPNZtV+K8YMPNcSqr+pyrla2uw58HbkXwiFUob9pIuw/P1VK22m8udbuS iqlLvp/e7Th+rhjgNqWVQ7vlHEfUUv3jLOfL3Wuw9l0QXPuARJuNbgvuyk7pFaE= =Vudg
" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."

" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system." #

The System Safety Mailing List

immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses caused as a result of viruses and it is your responsibility to scan or otherwise check this email and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). All companies are registered in England and their registered office is at 4000 Parkway, Whiteley, Fareham, Hampshire, PO15 7FL.

The System Safety Mailing List
Received on Thu Apr 30 2015 - 09:42:23 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST