Help Net Securityによる今回のインタビューでは、CyviationのCEOであるEliran Almong氏が、航空会社のサイバー被害がなぜ地上で発生しているのか、そして航空機自体がなぜ監視の目から外れたままなのかを解説しています。同氏はSIEMに痕跡を残さないGNSSジャミングの実態や、自社チームが報告したPX4オートパイロットの脆弱性――ドローンの指令チャネルが署名のないメッセージを受け入れてしまう問題――についても詳しく語りました。
同氏は、Electronic Flight Bag(EFB)そのものよりも、その背後にあるデータローディングの連鎖の方が重要だと主張し、デジタルツインの有効性を説くとともに、保有機30機・セキュリティ担当者2名という体制の航空会社が最初に着手すべき対策を提示しています。
取締役会に説明する際、航空業界のサイバーリスクは航空機とその他の地上インフラの間でどのように分かれるのでしょうか。業界が「飛行機をハッキングする」という話題に固執するあまり、実際に被害が発生している場所から予算が逸れてしまっているのでしょうか。
私はこの問いを、取締役会がしばしば混同しがちな二つの議論に分けて説明しています。一つは「どこで金銭的損失が生じているか」、もう一つは「安全上の事故が起きる可能性はどれほど低いか」という点です。損失という観点では、両者に比較の余地はありません。実際に発生している被害のほとんどは地上――予約システム、地上ハンドリング、MRO(整備・修理・オーバーホール)のIT、乗務員スケジューリング、空港運用など――で起きています。ランサムウェアが着弾するのもここであり、次のインシデントが発生するのもここでしょう。航空機そのものが航空会社に重大なサイバー損失をもたらした事例は、これまでのところ一件もありません。
とはいえ、「飛行機をハッキングする」という話が過大評価されているからといって、航空機自体が無関係になるわけではありません。映画さながらに誰かが飛行中の操縦系統を乗っ取るという想像は、懐疑的に見て当然でしょう。しかし現実はもっと地味なものです。航空機は絶えず地上からデータを取り込んでいます――航法データベース、性能データ、EFBのコンテンツ、ロード可能なソフトウェアなどです。航空機は、誰も監視していないサプライチェーンの末端に位置する存在なのです。
ですから、私が取締役会に説明する際の枠組みは、「金銭的損失が生じるのは地上であり、それに応じた予算を確保すべきだ。一方、航空機については我々の目が届いていない、これは別の問題だ」というものです。予算配分の誤りは、航空機に予算を投じること自体ではなく、間違った問いに予算を投じることにあります。アビオニクスのバスに侵入テストを行うことよりも、自社の機材にどのようなソフトウェアが搭載されているかを把握することの方がはるかに重要です。
過去2年間、航空業界の環境で観測された攻撃者の行動のうち、経験豊富な企業SOCアナリストが見たら驚くようなものはありますか。
彼らの思考の枠組みを崩すのは、GNSS(全球測位衛星システム)への干渉です。SOCアナリストはパケットやエンドポイント、IDといった世界で生きていますが、そのいずれもスプーフィングやジャミングを検知することはできません。この2年間、東地中海、黒海、ペルシャ湾では、こうした事態が日常茶飯事になっており、乗務員が誤った位置情報を受け取ったり、慣性航法システムの精度が着陸後に整備が必要になるほど劣化したりしています。ログも警告も、SIEM上には何も表示されません。最初の兆候はパイロットが報告書を書くことです。検知エンジニアリングに慣れたアナリストにとっては、テレメトリが完全に存在しないという事態を受け入れるのは容易ではないでしょう。
もう一つ驚くべき点は、実は「何も悪用されていない」ケースがいかに多いかということです。ACARS、ADS-B、データローディングの連鎖の一部など、エコシステムの多くは、伝送媒体そのものがアクセス制御として機能していた時代に構築されました。つまり、突破すべき認証機構自体が存在しないのです。我々自身の研究がこれを如実に示しています。2026年4月、我々はPX4オートパイロット――膨大な数のドローンやUAVに搭載されている飛行制御ソフトウェア――に存在するCVE-2026-1579を報告しました。CISAはスコア9.8の勧告ICSA-26-090-02を発行しています。問題は単純で、MAVLinkメッセージ署名がデフォルトで無効になっているため、指令チャネルは署名のないコマンドを受け入れてしまい、ネットワーク上の攻撃者が機体を操縦できてしまうというものでした。巧妙な攻撃連鎖など存在しません。システムは設計通りに動作していただけなのです。
ここに認識の転換が必要です。IT分野では回避策(バイパス)を探しますが、航空分野ではむしろ、そもそも誰の認証も行っていなかった安全上重要なチャネルに出くわすことの方が多いのです。しかもこれは一度限りの話ではありません。我々は現在、他の飛行制御プラットフォームにもこの研究を拡大しています。
Electronic Flight Bagは航空業界において最も過小評価されている侵入経路なのでしょうか。それとも、EFBに注目することがロード可能なソフトウェア部品やデータローディングの連鎖から目を逸らしてしまっているのでしょうか。
EFBは確かに過小評価されていますが、それはあくまで症状の一つに過ぎません。EFBは市販のタブレット端末で、私的利用と混在して使われることも多く、性能データやチャートを保持し、航空会社が管理していないネットワークを通じて更新され、手でコックピットに持ち込まれます。地上から空への最も目に見えるデータの流れであるがゆえに、注目を集めているのです。しかし本当の脆弱性は、その背後にある連鎖――ロード可能なソフトウェア部品を配信するのと同じ連鎖――にあります。重要なのは、データロード時に完全性と出所を検証できるかどうか、そして後になって何がロードされたのかを再構築できるかどうかです。ほとんどの運航会社は、そのどちらもできていません。
これには構造的な理由もあります。航空機は企業ネットワークのようにはテストできません。機体に対して侵入テストを行えば耐空性証明が失われてしまうため、実施されておらず、結局のところ文書が証拠の代わりを務めているのが実情です。だからこそデジタルツインが有効なのです。我々は航空機のサブシステムや通信経路を十分な精度でモデル化し、実機ではできないことをツイン上で実行できるようにしています。ロード可能な部品を、実際に機材に届く前に悪意ある入力に対してテストしたり、事象を再現してそれがサイバー攻撃だったのか単なる故障だったのかを検証したりできるのです。
GPSスプーフィングやTCAS操作といった事象を対象とする、MITRE ATT&CKの航空版拡張である我々のAV-ATT&CKフレームワークに照らし合わせると、どのデバイスがどの手法によってアクセス可能かが明確になります。これにより、EFBやデータローディングは単に「保証する」対象から、「実際にテストできる」対象へと変わるのです。
航空会社は商業上の理由から、運航データを製造元(メーカー)から守っています。両者の間に立ちながら、どこからも信頼されないパイプライン役に成り下がらないためにはどうすればよいのでしょうか。
そうならないようにすることに尽きます。運航データは稼働率、整備の実践状況、路線の経済性などを明らかにするものであり、航空会社がそれをOEMやリース会社から守る正当な理由があります。したがって、データの所有権は運航会社側が保持し、開示の可否も運航会社が管理します。我々が顧客ごとに完全に分離されたインフラを運用しているのはまさにそのためで、ある航空会社の機材データが別の航空会社のデータに触れることは決してなく、分析も当該航空会社の管理下で行われ、外部に出るのは航空会社自身が選択した情報だけです。
成果として有用なのは、通常はフィード(データの流し込み)ではなく、具体的な発見事項やインジケーターです。ベンダーがOEMにとって機材データを収集する手段と化してしまえば、そのベンダーは自らの存在価値を損なうことになります。航空会社はそれを素早く見抜きます。また、可能だからといって何でも収集するのではなく、セキュリティ関連のテレメトリと運航データを分離しておくことも重要です。
保有機30機、ITセキュリティ担当者2名という航空会社にとって、信頼に足るセキュリティプログラムとはどのようなものでしょうか。
徹底した優先順位付けです。まず前提として、2人の担当者だけで脅威ハンティング、検知の仕組みづくり、そして航空機の監視までを同時にこなすことは不可能だという現実から出発する必要があります。第一に、航空機を含めた資産の棚卸しと依存関係の把握です――機材にどのようなソフトウェアが搭載されているか、それに何がデータを供給しているか、誰がそれに触れているか。地味な作業ですが、これなくして何も機能しませんし、この規模の組織であれば実現可能な取り組みです。第二に、地上インフラへの対応です。ここでこそ損失が発生するからです。あらゆる場所でのMFA(多要素認証)の導入、管理者アクセスやベンダーアクセスの厳格な制御(これらの多くが侵害の起点になるため)、そして単に稼働を確認するだけでなく実際に復元テストを行ったバックアップの整備です。第三に、航空機の可視化です。この規模であれば、自前で構築するのではなく購入すべきものです。2名分の枠のために採用するには、専門知識があまりに希少すぎます。
必要なのは、「あの航空機で何が起きたのか」という問いに、6週間もの調査を要さずに答えられる能力です。これもまた、共有のデジタルツインを推奨する理由です。独自の脅威インテリジェンスプログラムや、それ自体を目的化したフレームワークの追求は避けるべきです。そして、インシデント対応計画を必ず策定してください。保有機30機規模の組織では、「厳しい一週間」で済むか「大惨事」になるかの違いは、たいてい誰かが事前に最初の数時間の対応を考え抜いていたかどうかで決まるからです。
翻訳元: https://www.helpnetsecurity.com/2026/07/31/eliran-almong-cyviation-aviation-cyber-risk/
