BAE Systemsの破産通知センター（BNC）システムに影響を及ぼしたサイバーセキュリティインシデントにより、米国の連邦破産裁判所が通知の配布に利用するサービスが停止した。
このインシデントにより、BAE Systemsが連邦司法機関向けに運用し、全国の破産通知を作成・配布している破産通知センター（BNC）が機能停止に陥った。
Reutersによると、障害により関連ウェブサイトもオフラインとなり、破産手続きの進展を関係者に知らせるため裁判所が依存するサービスが中断している。
影響はウェブサイトにアクセスできないことにとどまらない。通知や命令の遅延により、債権者、債務者、弁護士が裁判手続きの進行状況を把握する作業が複雑になる可能性があるほか、裁判所の電子 filingシステムを通じて債権者リストを作成・印刷するユーザーの能力も影響を受けている。
現時点で判明しているインシデントの概要
SecurityWeekによると、この混乱が明らかになったのは10月9日で、BAE Systemsが米国裁判所管理局に対し、破産通知の処理に使われるシステムに影響するサービス中断を通知した。
司法機関は10月15日、サイバーセキュリティインシデントを公表し、破産通知センター（BNC）が影響を受けたことを確認した。
司法機関は10月15日の発表で、BNCのシステムと関連ウェブサイトが利用できず、同センターによる破産通知の作成・配布が停止したと説明した。
影響を受けたサービスにはbnc.uscourts.gov、bankruptcynotices.uscourts.gov、notices.uscourts.gov、および債権者の郵送先リストへのアクセスを支援するNational Creditor Registration Serviceが含まれる。テキサス東部地区裁判所は、電子および紙の通知送達を支える裁判所のポーリングと認証プロセスが中断したと述べた。
確認した公表資料では、インシデントの原因は特定されておらず、データにアクセスされたのか、盗まれたのかも明らかになっていない。
BAE SystemsはBleepingComputerに対し、セキュリティインシデントはBNCシステムに限定され、対処のため直ちに措置を講じたと説明した。同社はインシデントを調査し、司法機関と連携しているが、報道で引用された情報では、復旧時期はまだ確定していない。
この障害は、すべての裁判所通知チャネルに影響しているわけではない。アラバマ州中部地区の米国破産裁判所は、CM/ECFを通じた電子 filing通知は通常どおり継続しており、裁判所が発行する文書を届ける代替手段を検討していると述べた。
第三者依存が重大な障害点になるとき
企業は、依存するすべてのシステムを社内で構築・管理できるとは限らない。
サービスの外部委託は、コスト削減や管理業務の負担軽減に役立つ。しかしその代償として、一部の業務が、自社では完全には把握も制御もできないサプライチェーンリスクに依存することになる。
Black Hills Information SecurityのオーナーであるJohn Strand氏は、eSecurityPlanetに対し、「多くの人はいまだにコンピューターセキュリティをDMZという観点で考えている。守るべき内部ネットワークがあり、それを守るべき外部世界がある、という考え方だ」と説明する。
しかし現代の組織は、複数のサービスとしてのソフトウェア（SaaS）プラットフォーム、第三者との統合、外部システムを経由するデータの流れに依存している。「その境界は、人々が信じたいと思っているよりはるかに複雑だ」とStrand氏は語る。
これが今回のインシデントの中心にあるサプライチェーンリスクだ。組織は自社ネットワークを安全に保っていても、依存するプロバイダーでセキュリティインシデントが発生すれば、業務が中断する可能性がある。
セキュリティチームにとって、こうした依存関係は可用性をベンダーリスク管理の一部にする。顧客側のネットワークが利用可能なままでも、プロバイダーの障害によって不可欠な業務が中断する可能性があるためだ。
BAE Systemsのインシデントは、重要な公共機能を支える基盤となっている場合、こうした依存関係がいかに深刻なものになり得るかを示している。
Suzu LabsでセキュアAIソリューションとサイバーセキュリティを担当するシニアディレクターのJacob Krell氏は、破産通知を「適正手続きの仕組み」と表現し、司法機関が、破産手続きを進めるために裁判所が依存するサービスを単一の請負業者に担わせていると指摘する。
Krell氏は、「障害は法廷には一度も及ばなかった。それでも国内のすべての破産事件の予定表を書き換えた」と述べている。
同氏の懸念は目下の障害を超え、請負業者がサービスを提供できない場合の代替手段がないことにも及ぶ。「通知の仕組みに代替経路がないのはなぜなのか」と問いかけている。
組織にとってのより広い教訓はここにある。第三者プロバイダーはしばしば必要不可欠だが、提供するサービスがあまりにも重要になると、その障害によってベンダー自体をはるかに超えた範囲で業務が中断する可能性がある。
不可欠な外部委託サービスについて、組織はどの程度の期間なら障害に耐えられるのかを定め、代替プロセスをテストすべきだ。サービスによっては、第二のプロバイダー、手作業のワークフロー、社内機能などが選択肢になる。
防御側ができること
サイバーセキュリティの防御担当者は、あらゆる攻撃を防げるわけではない。しかし、攻撃が発生してからシステムが停止し続ける時間までの隔たりを縮めることはできる。
組織には テスト済みのインシデント対応計画と災害復旧計画が必要だ。そこには、影響を受けたシステムを隔離し、インシデントを調査し、安全で信頼できる運用を復旧し、不可欠なサービスをできるだけ早く継続する方法を定める。
今回のインシデントは、 復旧計画で第三者への依存を考慮することの必要性も改めて示している。セキュリティチームと事業部門は、どの重要プロバイダーにどのワークフローが依存しているのかを特定し、許容できる停止時間を定め、代替プロセスを発動する責任者を割り当てるべきだ。
復旧訓練では、影響を受けたベンダーのシステムにアクセスできなくても代替手段が機能するかを検証すべきだ。さらにチームは、遅延をどのように伝え、障害中に完了した作業を追跡し、サービス復旧後に未処理分をどのように整理するかも定めておく必要がある。
防御担当者の目標は、攻撃者を締め出すことだけではない。インシデントが防御を突破した場合でも、不可欠な業務を迅速に復旧できるようにすることも目標だ。
続きを読む： Frontline Educationの侵害は、ベンダーリスクのレビューで、ソフトウェアプロバイダーが依存するものまで調査すべき理由を浮き彫りにする。