鉄道とサイバーセキュリティー [6] New Rails, Old Mistakes: The Cybersecurity Gap in Greenfield Projects

2025年8月5日 2025年8月5日

mack0113

Cylus のCo-Founder and CTO　Miki Shifmanさんの投稿がLinkedIn に上がっていたので、日本語版をここに上げておきます。規格と実際とのギャップについて書かれているので、実践の参考になると思います。

サイバーセキュリティは鉄道プロジェクトの中核へ

サイバーセキュリティは急速に、新しい鉄道プロジェクトにおける重要な要素となっています。最近では、セキュリティに関する考慮が含まれていない入札案件を見かけることの方が珍しくなりました。これは大きな進歩の証です。しかし、より多くのプロジェクトがサイバーセキュリティを取り入れるようになると、善意で始まった取り組みであっても、共通して見られる“落とし穴”が明らかになってきました。こうした盲点を早期に認識することで、プロジェクトチームはビジョンを実際の保護策へと変えることができます。

ここでは、よく見られる3つのギャップと、その回避方法を紹介します。

1. 規格を参照するだけで、指針が不明確

IEC 62443 や CENELEC TS 50701 のような規格は、優れた出発点となります。最近ではこれらが参照される機会も増えており、喜ばしいことです。ただし、「規格に従う」と記載するだけで、その適用方法を定義しないケースがよくあります。たとえば、「IEC 62443 に従うこと」とだけ記載され、どのセキュリティレベル（SL）を目指すのかが示されていないと、現場は「何をもって達成とするか」が曖昧なままになります。

対策：

適用範囲と目的を明確にする
たとえば「IEC 62443-3-3 に従って、信号設備を含む運用ゾーンでSL3を達成すること」と具体的に示します。
リスク許容度や受容可能なリスクレベルを明文化する
多くの規格がリスクベースで構成されているため、自らのリスク姿勢を明示することで初めて実効性が生まれます。

2. 制御手段（コントロール）の羅列だけで文脈がない

要件の中に、ファイアウォール、ウイルス対策、侵入検知、ログ管理などの制御手段が列挙されていることはよくあります。これらは確かに重要な要素ですが、現実の運用環境と結びつけて記述されていないと、本当の効果を発揮しません。たとえば「ファイアウォールを導入すること」とだけ書かれていても、ゾーン構成やルール管理、変更手続きに言及がなければ、単に機器が設置されるだけでシステムとしては機能しない可能性があります。

対策：

制御手段を「単体のツール」ではなく「システムの一部」として記述する
例：「乗客向けWi-Fiと車上制御ネットワークのゾーン境界にファイアウォールを配置し、ゾーン分離を強制するよう設定する」
要件記述には具体性を持たせる
「IDSを導入すること」ではなく、「鉄道用途に適した挙動を監視できる産業用IDSを用いて、システム固有の異常を検知する」といった表現が求められます。
コントロールと脅威を結びつける
脅威モデリングを活用し、「なぜそのコントロールが必要なのか」「どのリスクを低減するのか」を明確にします。

3. 検証（バリデーション）工程の欠如

多くのプロジェクトは、紙の上ではしっかりとした要件を定めています。しかし、いざバリデーションとなると不十分なケースが目立ちます。設計段階でサイバーセキュリティが「チェックボックス」として扱われ、運用や試運転の段階での確認が行われないのです。これでは、要件が実際に満たされたかどうか、またその効果が持続しているかどうかを確認する手段がありません。

対策：

サイバーセキュリティの確認ポイントをライフサイクル全体に組み込む
アーキテクチャ設計、FAT（工場受入試験）、SAT（現地受入試験）、運用後の監査など、各段階でレビューを実施します。
「完了」の定義を明確にする
例：「ファイアウォールが設置されていること」ではなく、「ポリシーが適用されており、ログにはそれが反映され、立ち上げ後3か月間、週次でレビューされていること」など。
実環境での検証を行う
ペネトレーションテスト、レッドチーム演習、現地での確認などを通じて、実運用に即した検証を行います。