RAS AI衛星は無事なのにサービスが止まった：宇宙セキュリティと安全分析を「サービス喪失」から始めるべき理由
01要約
02場面：2022年2月24日、衛星は無傷だった
2022年2月24日未明、ヨーロッパ全域でKA-SAT衛星インターネット端末数万台が同時に接続を失いました。Viasatが3月30日に公表した説明によると、攻撃者は設定に誤りのあるVPN機器を通じて地上管理ネットワークに侵入し、内部から多数の家庭用モデムへ正規の管理コマンドを一斉に送りました。コマンドはモデムのフラッシュメモリ上の重要データを上書きし、モデムはネットワークに再接続できなくなりました。Viasatはその後、約3万台の交換用モデムを出荷しました。ドイツの風力発電機メーカーEnerconは、このネットワークを利用していた風力発電機5,800基（約11 GW）の遠隔監視・制御が途絶えたと明らかにしました。発電機は稼働を続けましたが、遠隔でリセットすることはできませんでした。
この事件で衛星そのものには何の問題もありませんでした。被害は、地上管理ネットワーク、管理コマンド、ユーザー端末という衛星の外にある制御経路から生じました。セキュリティ研究チームのSentinelLabsは、ワイパー型マルウェアが管理機能を通じて配布されたと結論づけ、Viasatの説明は不完全だとみなしましたが、被害が地上の管理経路から始まったという点では両者は一致しています。
New Space Economyの記事が言う「サービスチェーン全体」とは、まさにこのことです。衛星運用者の顧客が気にするのは、衛星がどれほど高度かよりも、データを受け取れるか、そしてそのデータを信頼できるかです。
03資産から始める分析が見落とすもの
| 出発点 | 最初に問うこと | この事件で見落としやすいもの |
|---|---|---|
| 衛星の資産から始める | 衛星バス、ペイロード、コマンドリンクが攻撃されたら？ | 衛星に一切触れない攻撃（管理ネットワーク → 端末） |
| 構成要素の故障から始める | ゲートウェイ局Aが故障したら？ Bが引き継ぐ | AとBが管理アカウントと設定テンプレートを共有していれば、両方が同時に止まる |
| サービス喪失から始める | ユーザーが通信を失う経路はすべて何か？ | なし（管理ネットワーク、端末、共有依存関係はロスにつながる経路なので分析範囲に入る） |
資産ベースの分析が間違っているという意味ではありません。TARAは資産と攻撃パスを具体的に評価するうえで不可欠です。ただし、何を資産とみなすかは、分析範囲を決めた時点ですでに決まっています。その範囲をロスから逆算して決めれば、衛星の外にある管理ネットワークと端末が抜け落ちることはありません。
STPAは最初からこの順序で進みます。ロスを定義し、ロスにつながるハザード状態を定め、コントロールストラクチャを描いたうえで、コントロールアクションごとに、それがどのように非安全なコントロールアクション（UCA）になり得るかを問います。故障と攻撃を別々に問うのではなく、制御がどのように誤り得るかを問うため、セキュリティ上のロスも同じ枠組みで扱えます。YoungとLevesonはこの手法をSTPA-Secという名前で提案しました（2014年）。
04例1：STPA、サービス喪失から出発する
教育用の架空の衛星通信サービスです（特定の運用者の設計ではありません）。静止軌道の通信衛星1機、ゲートウェイ局2局（AとB、冗長構成）、衛星管制センター、ユーザー端末を遠隔管理するネットワーク管理システム（NMS）で構成されます。加入者には家庭や企業のほか、遠隔設備監視や緊急通信の利用者も含まれます。
ロス
- L-1 ユーザーが通信サービスを失う（遠隔設備監視・緊急通信を含む）
- L-2 衛星の制御を失う（衛星の損傷と軌道上デブリの発生を含む）
L-1はセキュリティ事案が生むサービスのロスであり、L-2は安全と宇宙の持続可能性に関わるロスです。両者を同じ分析の中に置きます。
ハザード
- H-1 多数のユーザー端末が同時に動作不能になる（L-1）
- H-2 両方のゲートウェイ局が同時にサービスを提供できなくなる（L-1）
- H-3 衛星が承認されていないコマンドを実行する（L-2）
システムレベルの制約
- SC-1 端末管理コマンドは多数の端末を一度に動作不能にできてはならず、また元に戻せなければならない
- SC-2 冗長化されたゲートウェイ局は、管理アカウント、設定、管理ネットワークなどの共通の依存関係を共有してはならない
- SC-3 衛星は認証されたコマンドのみを実行しなければならず、コマンド認証は地上の業務ネットワークのアカウントから分離されていなければならない
UCA 5件
| ID | コントロールアクション | 非安全なコントロールアクション | ハザード |
|---|---|---|---|
| UCA-P-1 | 端末管理コマンド | NMSが、承認された運用作業ではない端末管理コマンド（フラッシュ上書きなど）を実行する | H-1 |
| UCA-P-2 | 端末管理コマンド | NMSが、段階的な確認なしに端末管理コマンドを全端末へ一斉に適用する | H-1 |
| UCA-N-3 | 端末管理コマンド | 多数の端末が応答しなくなっているのに、NMSが復旧コマンドを提供しない | H-1 |
| UCA-P-4 | ゲートウェイ局の設定変更 | NMSが同じ設定変更を両方のゲートウェイ局へ同時に適用する | H-2 |
| UCA-P-5 | 衛星コマンド | 衛星管制センターが、盗まれたアカウントで入力されたコマンドを衛星へ送信する | H-3 |
セキュリティ分析であればUCA-P-1とUCA-P-5は脅威として挙げられたはずですが、UCA-P-2とUCA-N-3は運用手順と設計の問題です。攻撃がなくても、不具合のあるファームウェアイメージを一つ全端末へ一斉に配信すれば同じロスが起こります。STPAでは、この四つが同じコントロールアクションの下に並びます。
ロスシナリオ 5件
| ID | UCA | シナリオの要旨 | 示していること |
|---|---|---|---|
| LS-1 | P-1 | リモートアクセス用VPN機器の設定ミスにより外部の者が管理ネットワークに侵入し、正規の運用者権限で管理コマンドを発行する。NMSはコマンドを発行したアカウントだけを確認し、コマンドが破壊的かどうかは確認しない | Viasat事件と同じ構造 |
| LS-2 | P-2 | NMSの配信アルゴリズムに段階的展開（少数の端末 → 確認 → 拡大）の概念がなく、どのコマンドも端末グループ全体へ一度に送られる | 攻撃がなくても同じロス |
| LS-3 | N-3 | フラッシュを消去された端末は遠隔管理チャネルそのものを失い、復旧コマンドを受信できない。端末状態のフィードバックが「応答なし」と「再起動中」を区別しないため、NMSが大規模な異常に気づくのが遅れる | 復旧経路が被害経路と同じ |
| LS-4 | P-4 | ゲートウェイ局AとBが同じ管理アカウントと同じ設定テンプレートを使用している。テンプレートの誤り一つ、あるいはアカウント一つの窃取が両方のゲートウェイ局に同時に及ぶ | 冗長化を無力化する共有依存関係 |
| LS-5 | P-5 | 衛星管制アカウントと端末管理アカウントが同じ社内アカウント体系を使用している。管理ネットワークへの侵入が管制アカウントの窃取につながり、誤った推進コマンドが軌道離脱とデブリのリスクにつながる | セキュリティ事案が安全上のロス（L-2）へとつながる経路 |
対策 6件
| ID | 対策 | 関連するシナリオ |
|---|---|---|
| CM-1 | 管理ネットワークへのリモートアクセスに多要素認証と定期的な設定レビューを導入し、フラッシュやファームウェアを変更する破壊的コマンドには2名承認を必須とする | LS-1 |
| CM-2 | 段階的展開（少数の端末 → 状態確認 → 拡大）と自動停止基準 | LS-2 |
| CM-3 | 端末に以前のファームウェア領域を残して遠隔管理チャネルなしでもロールバックできるようにし、ブート領域は管理コマンドで消去できないよう保護する | LS-3 |
| CM-4 | 端末の「応答なし」フィードバックを集約し、大規模な異常時に警報を出す | LS-3 |
| CM-5 | ゲートウェイ局ごとに管理アカウントと設定配信の時間枠を分離する | LS-4 |
| CM-6 | 衛星コマンドの認証を社内アカウント体系から分離し、コマンドリンクにコマンド認証を適用する（例：CCSDS SDLS） | LS-5 |
05例2：FTA、冗長化を無力化する共有依存関係
LS-4により、STPAの段階で共有依存関係があることはわかります。それが設計上の冗長化をどれほど損なうかは、故障の木（FTA）で明らかになります。
頂上事象は「ブロードバンドサービスの全面喪失」です。その下に三つの枝を置きます。
- 両方のゲートウェイ局が機能喪失（OR）：ゲートウェイ局AとBの装置の独立した故障が重なる（AND：ゲートウェイ局A装置故障、ゲートウェイ局B装置故障）、および共有依存関係によって両方のゲートウェイ局が同時に失われる（OR：共有管理アカウントの窃取、誤りのある共有設定テンプレートの配信）
- ユーザー端末の大規模な動作不能（AND）：管理ネットワークへの不正アクセス、破壊的な管理コマンドのチェックなしの一斉適用
- 衛星トランスポンダの故障
ポイントは、共有依存関係を冗長化（AND）の中に混ぜ込まず、冗長化のすぐ上に独立したORの枝として置くことです。冗長化の故障の木を「Aが故障し、かつBが故障する」とだけ描くと、両方のゲートウェイ局が同じアカウントとテンプレートを使っているという事実は木に現れず、カットセットはすべて2次に見えます。共通原因を独自の枝として描いて初めて、この一つの事象で両方のゲートウェイ局が止まるという論理が木に入ります。
| カットセット | 次数 | 意味 |
|---|---|---|
| {共有管理アカウントの窃取} | 1 | 冗長化されていても単一故障点 |
| {誤りのある共有設定テンプレートの配信} | 1 | 冗長化されていても単一故障点 |
| {衛星トランスポンダの故障} | 1 | 衛星1機の例なので、もともと単一故障点 |
| {ゲートウェイ局A装置故障, ゲートウェイ局B装置故障} | 2 | 設計者が意図した冗長化 |
| {管理ネットワークへの不正アクセス, 破壊的コマンドのチェックなしの一斉適用} | 2 | Viasat型 |
VisualProが算出したカットセットは全部で5つで、結果サマリーの最小カットセットタブには1次のカットセット3つが表示されます。設計文書には「ゲートウェイ局の冗長化」と書かれていても、衛星トランスポンダのほかに、サービス全体を止める単一故障点がさらに二つあるのです。これはまさに、記事が言う「衛星の数だけではレジリエンスを測れない」ということです。ゲートウェイ局を3局に増やしても、同じアカウントとテンプレートを共有している限り、この2行は残ります。CM-5でアカウントと設定配信をゲートウェイ局ごとに分ければ共有依存関係の枝はなくなり、残るのは各ゲートウェイ局の独立した故障で、これらは2次以上のカットセットになります。
セキュリティ事象には、故障率のように確率を割り当てることが困難です。この例では確率は計算せず、カットセットの構造だけを見ます。攻撃がどれほど容易かは、次のステップであるTARAで評価します。
06例3：TARA、同じシナリオの攻撃実現可能性
STPAで見つかったシナリオのうち、攻撃者が関与するのはLS-1とLS-5です。これらをTARAに持ち込み、攻撃パスと実現可能性を評価します。
| TARA項目 | LS-1から | LS-5から |
|---|---|---|
| 資産 | NMSの端末管理機能（完全性、可用性） | 衛星コマンド機能（完全性） |
| ダメージシナリオ | 多数の端末の動作不能によるサービス喪失 | 承認されていない推進コマンドによる衛星制御の喪失 |
| 攻撃パス | VPNの設定ミス → 管理ネットワークへのアクセス → 正規の権限による破壊的コマンド | 管理ネットワークへの侵入 → 共有アカウントの窃取 → コマンドの入力 |
| サイバーセキュリティ目標 | 破壊的な管理コマンドは承認された作業としてのみ実行される | 衛星コマンドは専用のコマンド認証がある場合にのみ実行される |
| 影響度 · 攻撃ベクトル | Severe · Network | Severe · Network |
| 攻撃実現可能性 · リスクレベル（VisualProで算出） | High · 5 | High · 5 |
| CAL（VisualProで算出） | CAL4 | CAL4 |
| リスク対応 | CM-1, CM-2 | CM-6 |
どちらの攻撃パスも影響度がSevereで、ネットワーク経由で到達できるため、VisualProは攻撃実現可能性をHigh、リスクレベルを最高の5、サイバーセキュリティ保証レベル（CAL）をCAL4と算出しました。つまり、衛星を直接攻撃しなくても、地上の管理経路だけで最高のリスクレベルになるということです。
STPAはロスがどこで始まるかを、FTAはロスに至るのにいくつの事象で足りるかを、TARAは攻撃者にとってどれほど容易かを問います。三つの問いへの答えが同じ名前とIDで一つのプロジェクトに収まっていて初めて、セキュリティ、信頼性、運用の各チームが同じ対策について議論できます。
07VisualProでこの流れが機能する理由
1STPA・FTA・TARAが一つのプロジェクトにまとまっています。
2STPAはロスから対策までをつなぎます。
3FTAはカットセットを計算し、単一故障点をすぐに示します。
4TARAは資産 → ダメージ → 脅威 → 攻撃パス → サイバーセキュリティ目標の流れで評価し、CALを自動算出します。
5MCP接続でAIと一緒に作業できます。
08明日確認すべきこと
衛星運用・サービス運用担当
- 自社のロス定義に「衛星の喪失」だけがあり、「ユーザーサービスの喪失」が抜けていないか？
- 端末を復旧不能にし得る端末管理コマンドはどれか。それらは段階的展開と2名承認を経ているか？
セキュリティ担当
- 地上管理ネットワークとリモートアクセス機器はTARAの範囲に含まれているか？
- 衛星管制アカウントは社内業務ネットワークのアカウント体系から分離されているか？
信頼性・システムエンジニアリング担当
- 冗長化されたゲートウェイ局や衛星が共有するアカウント、設定テンプレート、ソフトウェア、サプライヤーを、FTAで冗長化の上に独立した共通原因の枝として描いているか？
- 意図しない1次のカットセットが現れていないか？
09まとめ
10よくある質問
Q1宇宙セキュリティにはTARAだけで十分ではないのですか？ なぜSTPAとFTAも必要なのですか？
Q2STPA-Secは通常のSTPAとは異なる手法ですか？
Q3セキュリティ事象に確率を割り当てて、FTAを定量化してもよいですか？
Q4多数の衛星からなるコンステレーションなら、この問題は減るのではありませんか？
Q5何から始めればよいですか？
· New Space Economy, "Can Space Security Keep Pace With Growing Dependence on Satellites?", 2026年10月29日 — 記事を読む
· Defense Intelligence Agency, Challenges to Security in Space 2026
· Secure World Foundation, Global Counterspace Capabilities 2026（13か国の評価） — SWF Counterspace
· Viasat, KA-SAT Network cyber attack overview, 2022年3月30日 — Viasatの発表
· SentinelLabs, "AcidRain: A Modem Wiper Rains Down on Europe", 2022年3月31日 — 分析を読む
· Enerconの発表（2022年2月28日）に関する報道：風力発電機5,800基の遠隔監視が中断
· William Young, Nancy G. Leveson, "An Integrated Approach to Safety and Security Based on Systems Theory", Communications of the ACM 57(2), 2014 — DOI 10.1145/2556938
· Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — STPA Handbook（PDF） / MIT PSASS STAMP Tools
· CCSDS 355.0-B, Space Data Link Security Protocol