Security analysisセキュリティは後付けできない - ECSS-E-ST-80C と IEEE P3536 が宇宙セキュリティを設計段階に引き上げた
VisualPro Tech Brief
セキュリティは後付けできない
ECSS-E-ST-80C と IEEE P3536 が宇宙セキュリティを設計段階に引き上げた
宇宙システムセキュリティ | ライフサイクル・設計段階の標準 | 業界動向ブリーフ
ECSS-E-ST-80CIEEE P3536IEEE P3349CCSDS SDLSNIST IR 8270
01概要（TL;DR）— 宇宙セキュリティを「設計要件」にした2つの出来事
宇宙システムのセキュリティは、長らく運用段階の問題として扱われてきました。地上局のアクセス制御、リンクの暗号化、異常の監視など、打ち上げ後に行うものでした。この前提がここ2年で変わりました。セキュリティは設計・開発段階の要件となり、それを定めた標準が2つ登場しました。
ECSS-E-ST-80C『Space engineering — Security in space systems lifecycles』は2024年7月1日に発効しました。欧州宇宙標準化協力機構（ECSS）のエンジニアリング部門が発行した標準で、宇宙・地上・打ち上げ・支援の各セグメントを対象とし、初期定義から廃棄までのライフサイクル全体にわたってセキュリティ要求を課しています。
IEEE P3536『Standard for Space System Cybersecurity Design』は、2026年3月26日にIEEE SA標準化委員会で承認されました。衛星の製造者と運用者に対し、設計段階でサイバーセキュリティを組み込むことを求める初の国際技術標準であり、地上システム、宇宙機、リンク、統合レイヤにまたがるコンポーネントレベルの設計プロセスを定義しています。
セキュリティを考慮せずに作られた設計に監視やパッチを重ねるのではなく、システムをどう設計するかによって攻撃の類型そのものを排除する。
— Gregory Falco、IEEE 宇宙システムサイバーセキュリティワーキンググループ議長（コーネル大学）
2つの標準は性格が異なります。ECSSは欧州の宇宙プロジェクトで契約上引用される枠組みです。一方、IEEE P3536は自主的な標準で、独自の強制手段を持たず、普及は契約・保険会社・規制当局・輸出管理制度を通じて進みます。この違いを混同すると、対応の優先順位を誤ります。
02なぜ今なのか — 宇宙セキュリティを設計段階に引き上げた3つの変化
1ライフサイクル全体が対象範囲にライフサイクル規定
ECSS-E-ST-80Cが扱うのは運用セキュリティではなく、ライフサイクルにおけるセキュリティ管理です。セキュリティ機能（情報セキュリティマネジメントシステムなど）の実装、設計情報の保護、そして特に重要な点として、セキュリティリスクアセスメントによって機密性の高い情報を特定し、それに応じた保護表示と保護措置を適用することを求めています。適用対象は機密指定の政府プロジェクトに限らず、非機密のミッションにも及びます。
適用除外も同じく明確です。正式なシステムセキュリティ認定（System Security Accreditation）プロセスはこの標準の範囲外であり、組織の既存ポリシーと衝突する企業セキュリティ上の制約を課すこともありません。プロジェクトの特性に合わせたテーラリングが認められています。
適用除外も同じく明確です。正式なシステムセキュリティ認定（System Security Accreditation）プロセスはこの標準の範囲外であり、組織の既存ポリシーと衝突する企業セキュリティ上の制約を課すこともありません。プロジェクトの特性に合わせたテーラリングが認められています。
2セキュリティが設計段階へ（Secure by Design）設計段階
IEEE P3536は、サイバーセキュリティ管理策を5つの領域にわたって定義しています。地上システム、宇宙機、両者をつなぐリンクセグメント、そしてミッションを結び付けるAPI・データリンク・試験環境を含む統合レイヤに加え、5番目の分科会がユーザーセグメント（端末、タブレット、基地局、航法・リモートセンシングアプリケーション）を扱います。
注目すべきはその適用範囲です。大型の国家プログラムだけを想定したものではなく、モジュール型の商用オフザシェルフ（COTS）システム、キューブサット、小型衛星バスに対しても技術的なサイバーセキュリティ仕様を提供します。商業宇宙への参入障壁が下がるにつれ、設計セキュリティの要求もその層まで降りてきたのです。
注目すべきはその適用範囲です。大型の国家プログラムだけを想定したものではなく、モジュール型の商用オフザシェルフ（COTS）システム、キューブサット、小型衛星バスに対しても技術的なサイバーセキュリティ仕様を提供します。商業宇宙への参入障壁が下がるにつれ、設計セキュリティの要求もその層まで降りてきたのです。
3標準の体系が一気に厚みを増した標準体系の拡大
IEEE P3349『Standard for Space System Cybersecurity』は、同じワーキンググループ（S2CY）で管理策の観点から並行して策定が進められています。米国ではNIST IR 8270が、商用衛星運用にサイバーセキュリティフレームワークを適用する方法を示しています。リンク層ではCCSDS SDLSが宇宙データリンクのセキュリティプロトコルを提供し、脅威に関する知識体系としてはThe Aerospace CorporationがSPARTAを維持しています。
これらすべてが求めるものは一つに収束します。資産を特定し、脅威を導出し、リスクを評価し、対策を要求に落とし込み、それが実装・検証されたことを証拠として残すこと。自動車や防衛分野でTARAと呼ばれている流れそのものです。
これらすべてが求めるものは一つに収束します。資産を特定し、脅威を導出し、リスクを評価し、対策を要求に落とし込み、それが実装・検証されたことを証拠として残すこと。自動車や防衛分野でTARAと呼ばれている流れそのものです。
032つの標準が実際に求めるもの
ECSS-E-ST-80Cの概要
| 項目 | 内容 |
|---|---|
| 正式名称 | Space engineering — Security in space systems lifecycles |
| 発効 | 2024年7月1日 |
| セグメント | 宇宙、地上、打ち上げ、支援（宇宙機、ロケット、ペイロード、関連する地上インフラ） |
| ライフサイクル範囲 | 初期定義から廃棄まで |
| 主な要求 | セキュリティ機能（ISMSなど）、ライフサイクルのセキュリティ管理、設計情報の保護、リスクアセスメントに基づく機密情報の特定と保護表示・保護措置 |
| 適用対象 | 機密指定の政府プロジェクトと非機密のミッションの両方 |
| 適用範囲外 | 正式なシステムセキュリティ認定（System Security Accreditation）プロセス、組織のポリシーと衝突する企業セキュリティ上の制約 |
| テーラリング | プロジェクトの特性に応じて許容（ECSS-S-ST-00のガイダンス） |
IEEE P3536が区分する5つの領域
| 領域 | 対象範囲 | 分析で扱うべき事項 |
|---|---|---|
| 地上システム | 管制センター、地上局、運用ネットワーク | アクセス制御の侵害、コマンドの偽造、内部脅威 |
| 宇宙機 | 衛星バス、オンボードソフトウェア、内部バス | コマンド受理ロジック、ソフトウェアのアップロード経路、セーフモード |
| リンクセグメント | アップリンク、ダウンリンク、中継 | ジャミング、スプーフィング、リプレイ、暗号運用 |
| 統合レイヤ | API、データリンク、試験環境 | インターフェースの信頼境界、試験環境における資産の露出 |
| ユーザーセグメント | 端末、タブレット、基地局、航法・リモートセンシングアプリケーション | エンドユーザー端末を経由した侵入、アプリケーションデータの完全性 |
混同しやすい2つの組み合わせ 第一に、IEEE P3349とP3536は別の標準です。同じワーキンググループ（S2CY）から出ていますが、P3349はどのような保護を備えるべきか（管理策）を、P3536はどのように設計するか（プロセス）を規定します。一方は規範的、もう一方は手続き的です。
第二に、ECSS-E-ST-80CとECSS-Q-ST-80Cは同じ番号に見えますが、まったく別の標準です。Eはエンジニアリング部門（セキュリティ）、Qは製品保証部門（ソフトウェア製品保証）です。文書を引用するときや契約要求をレビューするときは、必ず部門を示す文字を確認してください。
第二に、ECSS-E-ST-80CとECSS-Q-ST-80Cは同じ番号に見えますが、まったく別の標準です。Eはエンジニアリング部門（セキュリティ）、Qは製品保証部門（ソフトウェア製品保証）です。文書を引用するときや契約要求をレビューするときは、必ず部門を示す文字を確認してください。
04宇宙プログラムにはすでに分析体系がある — 今、その隣にセキュリティが並ぶ
宇宙分野は、ほかのほぼどの分野よりも長く、厳格に信頼性・安全分析を実践してきました。ECSS-Q-ST-30-02CはFMEA/FMECAの原則と要求を定め、故障モードをクリティカリティ（重大度と発生確率を組み合わせた尺度）によって分類します。ECSS-Q-ST-40ファミリーはハザード分析の原則、プロセス、要求を定義しています。
E-ST-80CとP3536が加えるのは、新しい分析手法ではなく、新しい原因の軸です。これまでの原因はランダム故障と設計・製造上の欠陥でした。そこに今、意図を持つ行為者が加わります。
| 既存の分析（ECSS Q部門） | 新たに求められるセキュリティ活動 | 共有されるもの |
|---|---|---|
| FMEA / FMECA（Q-ST-30-02C） | 脅威シナリオの影響評価 | 同一の機能・構造分解 |
| ハザード分析（Q-ST-40ファミリー） | セキュリティリスクアセスメント | リスクの特定・分類手順 |
| FTA・信頼性分析 | 攻撃パス分析 | 事象の論理と最小カットセット |
| 要求の分解とトレース | セキュリティ要求の分解とトレース | 要求の階層と設計への割り当て |
| 検証エビデンスパッケージ | 対策の有効性を示すエビデンス | レビュー・監査対応の根拠 |
問題は2つの軸が別々のツールにあるときに生じる 安全分析が信頼性チームのFMECAに、セキュリティ分析が別の脅威分析シートにあると、同じ衛星を二度モデル化することになり、セキュリティ侵害が引き起こすミッションロスがFMECAに反映されません。逆に、安全のために導入した冗長構成が攻撃者にとって何を意味するのかも検討されません。
宇宙では、この漏れのコストがほかの分野より高くなります。コンタクトの機会は限られ、物理的なアクセスは不可能で、ミッションは10年を超えて続きます。設計で見逃したものを後から捉える余地はほとんどありません。だからこそ、2つの標準はいずれも設計を対象としているのです。
宇宙では、この漏れのコストがほかの分野より高くなります。コンタクトの機会は限られ、物理的なアクセスは不可能で、ミッションは10年を超えて続きます。設計で見逃したものを後から捉える余地はほとんどありません。だからこそ、2つの標準はいずれも設計を対象としているのです。
05VisualProによる支援
1つの構造ツリー、5つの分析構造の共有
FMEA、FTA、HARA、TARA、STPAが1つのシステム構造データベースを共有します。衛星バス、ペイロード、地上局、リンクを1つのツリーに載せれば、IEEE P3536が定義する5つの領域が同じツリーのノードになります。信頼性分析とセキュリティ分析が1つのモデルを参照します。
TARA — 資産からセキュリティ要求まで標準への対応
資産の特定、脅威シナリオの導出、リスクアセスメント、対策、セキュリティ要求までをツール内で実施し、トレースします。ECSS-E-ST-80Cが求めるセキュリティリスクアセスメントと機密資産の特定、そしてP3536の設計プロセスが想定する成果物は、この流れの上に位置します。
分析間のトレーサビリティ（デジタルスレッド）中核となる価値
脅威→対策→セキュリティ要求→検証項目、そして故障モード→影響→重大度→設計対策が、1つのデータベースで結び付けられています。設計変更や新たな脅威が生じると関連する分析も合わせて更新されるため、レビューの時点で生きたトレーサビリティを示すことができます。
MCPベースのAIエージェント連携AI連携
FMEA、FTA、HARA、TARA、STPAに対応するVisualProのMCP（Model Context Protocol）機能により、ClaudeなどのAIエージェントがツールと直接通信できます。脅威・ハザード候補の特定からスコアリング案の作成までを対話形式で進められ、分析者は検証と判断に集中できます。
06よくある質問（FAQ）
Q1IEEE P3536は義務ですか？
いいえ。P3536は自主的な標準であり、独自の強制手段を持ちません。その効力は、調達契約、保険会社の引受条件、規制当局による参照、輸出管理制度から生まれます。ECSS-E-ST-80Cは性格が異なり、欧州の宇宙プロジェクトで契約上引用される枠組みです。欧州のプログラムへの参入を検討しているならECSSが先であり、P3536は設計プロセスの国際的なベースラインとして扱うのが適切です。
Q2ECSS-E-ST-80CとECSS-Q-ST-80Cは同じ標準ですか？
いいえ。番号は似ていますが部門が異なります。E-ST-80Cはセキュリティ（エンジニアリング部門）、Q-ST-80Cはソフトウェア製品保証（製品保証部門）です。実務でよく混同される点なので、文書を引用するときや契約要求をレビューするときは、必ず部門を示す文字を確認してください。
Q3自動車のサイバーセキュリティ（ISO/SAE 21434）の経験は宇宙に活かせますか？
方法論の流れはそのまま活かせます。資産の特定、脅威シナリオ、リスクアセスメント、対策の導出、トレーサビリティという骨格は、TARAと宇宙セキュリティ標準で共通です。異なるのは、セグメント構成（地上、リンク、軌道、ユーザー）、コンタクト機会の制約（可視時間帯と帯域幅）、ミッション寿命（10年以上）、そして準拠する標準です。新たに学ぶべきなのは分析手法ではなく、ドメイン固有の制約と標準の体系です。
Q4VisualProはECSS形式の成果物を直接出力できますか？
正確に申し上げると、VisualProが標準形式で出力できるのはAIAG-VDA FMEA、ISO 26262 HARA（ASIL）、ISO/SAE 21434 TARA、FTAです。ECSS-Q-ST-30-02CのFMECAは項目構成とクリティカリティの算出方法が異なるため、項目のマッピングが必要です。ただし、分析の実体である構造分解、故障モード、影響、重大度、対策、トレーサビリティは同じデータベースで管理されるため、プロジェクトの形式に合わせた出力定義は導入時に協議のうえ構成します。
07今すぐ始める（Next Step）
宇宙システムにおいて、安全とセキュリティはもはや別々の段階の活動ではありません。ECSS-E-ST-80Cはセキュリティをライフサイクル全体に、IEEE P3536は設計段階に位置付けました。そして2つの標準が求める成果物は、すでに実施している信頼性・安全分析と同じ構造の上に構築してこそ、コストを抑えられます。自動車、防衛、航空、ロボット、半導体の分野で実績のあるVisualProで、脅威分析と故障分析を1つの構造の上に載せることから始めましょう。
脅威分析と故障分析を1つの構造の上に — VisualProで宇宙セキュリティ標準に対応。
参考資料：ECSS, “ECSS-E-ST-80C — Security in space systems lifecycles” (2024-07-01) · CYSAT News, “IEEE Approves First Space Cybersecurity Design Standard” (2026-07-10) · IEEE SA, “P3349 — Standard for Space System Cybersecurity” · NIST IR 8270 · ECSS-Q-ST-30-02C FMEA/FMECA