Re: [SystemSafety] GAO report on FAA cybersecurity vulnerabilities ... and an instance

From: jean-louis Boulanger < >
Date: Mon, 27 Apr 2015 18:12:33 +0200


yes it's the question.
In past, the separation between network (safe and non-safe) are very strong. And I am sure that in old plane this separation is physical. Yes for new device (train, plane, automotive) we want to open the door and need to add security in the box ....

2015-04-27 17:13 GMT+02:00 RICQUE Bertrand (SAGEM DEFENSE SECURITE) < bertrand.ricque_at_xxxxxx

> 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
> Bertrand.ricque_at_xxxxxx >
> -----Original Message-----
> From: Peter Bernard Ladkin [mailto:ladkin_at_xxxxxx > 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
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
>
> https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-09-27.pdf
> 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 www.rvs.uni-bielefeld.de
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCAAGBQJVPbs6AAoJEIZIHiXiz9k+l6EH/2IrI7eV1p/vVSpB1cRc1cRW
> sapr/CY/wPI2FjBsVeddYtVZNbIYFELq3wsSlIyB42SNXlxWRp/2vJE2CsYr2tq7
> Psc92hmNaVNqY/KG+hdqpa3nBZE5IhyHEHUm2KM8LBgVq9IUKINS5V0iQwoNlixN
> sHAX7G7KxAOQisXL9Cg4VVu739+H7H2USNNQXFp9xc2iz204FoDX25j8WFl7lBXD
> zN3ZKLuJPNZtV+K8YMPNcSqr+pyrla2uw58HbkXwiFUob9pIuw/P1VK22m8udbuS
> iqlLvp/e7Th+rhjgNqWVQ7vlHEfUUv3jLOfL3Wuw9l0QXPuARJuNbgvuyk7pFaE=
> =Vudg
> -----END PGP SIGNATURE-----
> #
> " 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
> systemsafety_at_xxxxxx >

-- 
Mr Jean-louis Boulanger



_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Mon Apr 27 2015 - 18:12:41 CEST

This archive was generated by hypermail 2.3.0 : Sun Feb 17 2019 - 08:17:07 CET