2017/08/26

米海軍の相次ぐ船舶衝突事故とハッキングの関連性を考える

2017 年 8 月 26 日 Teri Radichel 著

米海軍の船舶、ジョン・S・マケインとフィッツジェラルドの衝突事故が連続したことで、米海軍のシステムを標的とする攻撃をすぐに疑ったセキュリティ関係者も多かったはずです。類似する衝突事故が連続して発生すれば、当然ながら、さまざまな憶測が飛び交います。裏付けのない推測は避けるべきですが、今回の一連の事故がサイバー攻撃によるものである可能性を探りたいという思いから、海軍の元関係者である知人にいくつか質問してみることにしました。

Defcon の「Using GPS Spoofing to Control Time(GPS スプーフィングを使った時間の制御)」というプレゼンテーションで、GPS の電波を妨害する機械によってナビゲーションシステムに誤った位置情報が表示される例が紹介されていました。たとえば、Uber の走行記録の詳細を書き換えることで、運賃を無料にできる可能性もあるそうです。Uber のある運転手にこの話をしたところ、「考えたくもない」と困惑していました。仮に、書き換えるのが航行システムの針路であったとしたら、その影響は、はるかに大きいものになるはずです。

ハッキングで海軍の船舶が完全に制御不能に陥る可能性はあるのか

海軍の潜水艦で OOD(Officer of the Deck、甲板の当直士官)だった経験がある友人に質問したところ、今回の事故は潜水艦ではないが、「おかしな話だ」と言っていました。すべての電気系統と航行システムが故障したとしても、周辺海域を監視する人間の当直が必ずいるため、規則に従わなかったり、針路を外れて航行したりする船舶がいたとしても、回避できるはずだということです。米海軍の「Lookout Training Handbook(見張り役の訓練ハンドブック)」によると、海上を航行する船舶には、平時であっても 3 人(正面の左右に 1 人ずつと船尾に 1 人)を配置するとされています。船舶の乗組員が常に見張りにつく必要があり、海軍の船舶においては、十分な操縦性を保ち、接近する船舶との衝突を回避できるようになっているはずです。

ジョン・S・マケインの衝突事故に関する Ars Technica の記事では、海軍のさまざまな技術をしても人的不足を補うことはできないと説明し、経験と訓練なしにこの任務にあたるのは容易ではないという、ある元海軍士官の話を紹介しています。この元士官は、新人の頃の経験談として、「前方を航行する漁船や商船だけでなく、追跡し、視認しなければならない対象は常に 40 を優に超えていた」とし、経験豊富な上官に指摘されて初めて問題に気付いたこともあったと話しています。訓練と経験が不可欠であるのは確かですが、十分な訓練を受けた乗組員が規則に従って監視していれば、ジョン・S・マケインの場合も、接近するコンテナ船に気付いていたはずです。

操舵不能になった可能性はあるのでしょうか。攻撃者に舵を乗っ取られ、接近する他の船舶を回避できなくなる恐れはあるのでしょうか。前述の記事は、舵が機能しなくなった可能性を指摘し、おそらくは IBNS(統合ブリッジ・航行システム)に何らかの原因があるとしています。私の知人である海軍関係者によれば、電子操舵システムの故障に備えて、これらの船舶には、手動の油圧式操舵システムが装備されており、そのシステムが故障すると、マストの先端のライトが赤く点灯し、船舶が操舵不能であることを他の船舶に知らせるようになっているそうです。混雑する海域を航行する大型船舶は、自動操縦を使用しないことになっており、そうすれば、警告に気付いて海軍の船舶を避けられたはずです。ところが、この記事によると、フィリピンの貨物船、ACX クリスタルは、米海軍のフィッツジェラルドとの衝突時に自動操縦で運航されていたようです。したがって、フィッツジェラルドのマストのライトに操舵不能の警告が点灯していたとしても、この貨物船は衝突を回避できなかったものと推測されます。

人的ミスか、あるいは、サイバー攻撃を疑うべきか

ほとんどの場合、手動操舵の手段を用意し、訓練された乗組員が任務にあたることで、衝突を回避できます。今回の事故では、多くの人が訓練不足を指摘しおり、事故の責任をとって、何人かの乗員が解任されましたが、はたして、人的ミスで片付けてしまって良いのでしょうか。訓練が不可欠であるのは事実であり、GPS データ改ざんの可能性がゼロではないため、船員たちは、古代から伝わる天体航法技術も学びます。また、複数の当直を配置して監視にあたるようになっており、電子制御のシステムを手動に切り替える方法も存在します。しかしながら、根本原因の徹底調査を怠れば、船舶のサイバー攻撃に対する脆弱性は解決されません。

船舶がハッキングされる恐れはあるのでしょうか。2 人のセキュリティ研究者による実験で、離れた場所からデジタルシステムを乗っ取ることで、車の進路を変えられることがわかっています。海軍の航行システムは車のシステムとは大きく異なり、間違いなくセキュリティも強固ではありますが、誰かが船を攻撃して操縦しようと考えたとしても不思議はありません。そして、そのような可能性を考えることが、将来の事故の防止につながります。たとえば、Fred Kaplan 氏は自らの著書「Dark Territory: The Secret History of Cyber War」で、映画「ウォー・ゲーム」によって当時の大統領のセキュリティの潜在的な問題を認識するようになったと述べています。そして、可能性を検証する過程で潜在的なセキュリティの不備が調査され、その調査によって、攻撃に対して特に脆弱なシステムが明らかになり、国防システムが改善されたということです。

米国船の衝突事故では、どのような原因が考えられるのでしょうか。ある米海軍関係者が、船舶の追跡には AIS(自動識別システム)と VTS(船舶追跡サービス)が使われると説明してくれました。https://www.marinetraffic.com/ には、船舶のライブの位置情報が公開されています。2013 年の MIT Technology Review の記事で、船舶追跡のハッキングによってタンカーが視界から姿を消した例が説明されていますが、この攻撃では、AIS がハッキングされました。当時の攻撃で利用された脆弱性がすでに解決されている可能性は高いものの、システムやコードの変更に伴う、新たな脆弱性が存在する可能性があります。最近のある記事は、ロシアが GPS スプーフィングを使ったサイバー兵器をテスト中だと伝えています。近くを航行する船舶の位置情報が誤って報告されれば、そのデータを使って衝突を回避する、軍事用や民間の船の自動操縦システムに影響を与える恐れがあります。航行システムの GPS データが正しくなかった場合、それを使用する船員は、前方に何の障害物もないと信じてしまうことでしょう。

衝突した米海軍の船舶や民間船の操舵システムや何らかの航行システムに対する攻撃の可能性はあるのでしょうか。Mashable の記事には、セキュリティ研究者が船舶の衛星アンテナシステムをリモートでハッキングする方法が紹介されています。ある事故では、海軍の「スマート船」に読み込まれたデータが正しくなかったために航行不能になりました。バックアップシステムがあれば、通常の航行システムが故障したとしても、バックアップシステムが作動し、船員がシステムを切り替えて対処できるようになっているはずです。相次ぐ船舶事故の原因を検証した、「Why are our ships failing? Competence, overload, and cyber considerations」という記事では、バックアップシステム不備の疑いが検証されています。この記事の著者は、ジョン・S・マケインとフィッツジェラルドはどちらもイージス艦であり、2000 年代の始めから中頃に中国にイージス艦の設計図が盗まれたことがあると説明しています。Guardian 紙は、攻撃の 11 日前に中国がジョン・S・マケインに対して、領海内に侵入したとして、10 回近くも針路を変えるよう警告していたと伝えました。ある古いレポートで、ロシアは、アメリカの海事システムを無効にできると主張しています。さらには、セキュリティ研究者が発見した、一部の船舶のデータレコーダーの脆弱性によって、事故に関するデータが正しく記録されない可能性があるということもわかっています。

結論は…

具体的な証拠が見つからない限り、ジョン・S・マケインやフィッツジェラルドの事故がハッキングによるものであったかどうかを結論付けることはできません。調査が進めば、改ざんされていない航海記録や録音などの十分な証拠が見つかるでしょう。双方の言い分を根拠とし、結論を急いだ、さまざまな報道が続いていますが、調査チームがサイバー攻撃を疑うかどうかにかかわらず、十分な調査によって潜在的な攻撃ベクトルを検証し、その可能性を排除するよう努めるのは、良いことです。今回の一連の衝突事故がサイバー攻撃によるものではなかったとしても、攻撃ベクトルを検討することで、問題を発見して修正し、重大事故につながる恐れのあるシステム障害を防ぐことができます。前述のいくつかの記事から、船舶のシステムにもセキュリティの問題が存在するということ、また、攻撃の原因がどのようなものだったとしても、サイバーセキュリティに対する意識の訓練が軍および民間の船舶の乗組員にとって重要だということがわかります。— Teri Radichel(@teriradichel)