製造業にとって安全なソフトウェア開発ライフサイクルが重要な理由

ベンダーや業界の専門家がサイバー攻撃について怖い話をする割には、実際に壊滅的な被害をもたらす攻撃は比較的少ない。しかし、ジャガー・ランドローバー（JLR）の攻撃はそうだった。

JLRの侵害は、数十万ドル程度の迷惑な攻撃ではなかった。ロイター通信によると、この攻撃は数週間にわたって生産を完全に停止させ、英国経済に20億ドル以上の損害を与え、5000もの組織に影響を与えた。ロイター通信によれば、5000もの組織が影響を受けたという。

英国政府は、JLRの経営を維持するために20億ドル近い融資保証に踏み切らなければならなかった。

悪夢が現実に

JLRの攻撃は、理論的には起こりうるとメーカーが知っていた悪夢のシナリオだった。それが実際に起こったとき、多くの製造業は同じ運命に見舞われないようにするにはどうしたらよいかと奔走した。

すぐに明らかになった問題がある：サプライ・チェーンは製造業者にとって最も脆弱なセキュリティ・リンクのひとつである。結局のところ、JLRの攻撃は、サードパーティの請負業者が使用する認証情報の漏洩によって、同社のサプライチェーンから発生した。

攻撃者はどのようにしてサプライチェーンに侵入しているのだろうか？一つの強力な手口は、メーカーとそのサプライチェーン・パートナーが使用するソフトウェア・アプリケーションの開発ツールや開発プロセスを標的にすることである。

JLRを墜落させたような攻撃ではないかもしれないし、そうかもしれない。しかし、重要な教訓は、メーカーとそのサプライ・チェーン・パートナーが、ソフトウェア・プロバイダーが安全な開発手法を使用していることを確認することに用心深くなければ、JLRが受けたようなレベルの攻撃を受ける可能性があるということだ。

狙われるサプライチェーン

ソフトウェア開発を通じたサプライチェーンへの攻撃は目新しいものではないが、強力で危険なものであることに変わりはない。2020年のSolarWindsへの悪名高い攻撃、2021年のKaseya VSAへの攻撃、2023年のVoIPプロバイダー3CXへの攻撃など、これまでに行われた最も有名なサイバー攻撃にはこの手口が使われている。

攻撃者は最近、新たなアプローチを開発した：それは、悪意のあるノード・パッケージ・マネージャー（NPM）をソフトウェア開発プロセスに組み込むというものだ。JavaScriptの開発者は、再利用可能なコードを共有しインストールするためにNPMを使用する。

NPMが悪意のあるものである場合、攻撃は急速に広がり、何カ月も耐え、あらゆる種類のアプリケーションに入り込む可能性がある。

NPMを標的とした最近の例としては、Shai-Hulud cryptostealerがあり、サイバーセキュリティ・プロバイダーが使用するいくつかのNPMパッケージを含む500以上のNPMパッケージを侵害したと報告されている。

NPM攻撃は、攻撃者がサプライチェーンに侵入するために発見した手法の1つに過ぎない。例えば、攻撃者はソフトウェア・ベンダーのアップデートを侵害し、ソフトウェアの脆弱性を悪用することもできる。

要するに、サプライチェーンのアプリケーションは脆弱であり、メーカーはパートナーが使用するアプリケーションが安全であることを確認する必要があるということだ。

a.fl_button { background-color：#border：1px solid #3b59aa; color：#text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; margin：4px 2px; cursor: pointer; padding：12px 28px; } .fl_ad { background-color：#width: 95%; margin: 15px auto 15px auto; border-radius: 8px; border：1px solid #d6ddee; box-shadow: 2px 2px #728cb8; min-height: 200px; display: flex; align-items: center; } .fl_lef>a>img { margin-top: 0px !important; } .fl_rig>p { font-size: 16px; } .grad-text { background-image: linear-gradient(45deg, var(–dawn-red), var(–iris)54%, var(–aqua)); -webkit-text-fill-color: transparent; -webkit-background-clip: text; background-clip: text; } .fl_rig h2 { font-size: 18px!important; font-weight: 700; color：color: #333; line-height: 24px; font-family：font-family: Georgia, times new roman, Times, serif; display: block; text-align: left; margin-top: 0; } .fl_lef { display: inline-block; min-height: 150px; width: 25%; padding：10px 0 10px 10px; } .fl_rig { padding：10px; display: inline-block; min-height: 150px; width: 100%; vertical-align: top; } .fl_lef>a>img { border-radius: 8px; } .cz-news-title-right-area ul { padding-left: 0px; } @media screen and (max-width: 1200px) { .fl_ad { min-height: 184px; } .fl_rig>p { margin: 10p10px; } .fl_rig { padding：0 10px 10px 10px; width: 100%; } } @media screen and (max-width: 400px) { .cz-story-navigation ul li:first-child { padding-left: 6px; } .cz-story-navigation ul li:last-child { padding-right: 6px; } } }.

より緊密な評価の必要性

サプライチェーンが危険にさらされている今、製造業者は、安全なソフトウェア開発ライフサイクル（SSDLC）を実践している既存および潜在的なパートナーを評価する必要があります。

ほとんどの運用技術（OT）環境では、調達評価はベンダーの財務健全性、サービスレベル契約、インフラセキュリティに重点を置いています。しかし、ソフトウェア開発プロセスの脆弱性、つまりサプライチェーン・アプリを妨害する可能性のある問題は、見落とされがちです。

これが、メーカーとそのサプライチェーンパートナーの双方にとって、厳格な SSDLC の実践が非常に重要である理由です。メーカーがパートナーの間でSSDLCの実践を確保しない場合、運用のダウンタイム、金銭的損失、コンプライアンス違反、風評被害に直面するリスクがあります。

SSDLC：コンプライアンスチェックボックス以上のもの

SSDLC がこれほど重要で効果的な理由は何でしょうか？手始めに、これは EU NIS 2 指令の下で義務付けられているもので、正式な SSDLC プロセスを文書化する必要があります。

また、SSDLC は、セキュリティを開発後の付加的なものとして扱うことから、ソフトウエアの作成プロセス全体に組み込むことへの根本的な転換を意味する。

要件分析中に発見された脆弱性は、修正に数時間かかるかもしれない。同じ欠陥がリリース後に発見された場合、緊急対応に数週間を要するかもしれない。

実際には、成熟した SSDLC の実装には次のようなものがある：

• 設計によるセキュリティ：コードを記述する前に、セキュリティ要件を定義し、脅威をモデル化する。
• セキュアなコーディングの実践： 開発者がセキュリティのトレーニングを受け、必須のコードレビューと自動化されたセキュリティテストを実施する。
• 依存関係の管理：ソフトウエア部品表（SBOM：Software Bill of Materials）を 活用して、サードパーティコンポーネントを検証、追跡、保守 する
• セキュアなリリースパイプライン：アップデートは署名され、完全性がチェックされ、厳重なチャネルを通じて配信される。
• 脆弱性管理：セキュリティ問題に対する調整された開示プロセスと明確な対応スケジュール。

製造業にとって、これは、生産ラインを制御し、重要なシステムを管理し、産業オペレーションを接続するソフトウェアが、コードの最初の行から最終的な配備に至るまでセキュリティを備えていることを意味する。

セキュアな開発の確実な証明IEC 62443-4-1認証

業界認証は、開発プロセスで SSDLC が使用されていることを示す信頼できる指標です。さまざまなセキュリティ認証が存在するが、IEC 62443-4-1 は製造サプライチェーンにとって特に重要である。

IEC 62443 規格ファミリーは、特に産業用オートメーションと制御システムのセキュリティに対応しており、製造業が活動する環境そのものである。

この枠組みの中で、IEC 62443-4-1 は、セキュアな製品開発ライフサイクル要件にのみ焦点を当て、OT ソフトウェアサプライヤを評価するための最も厳密で関連性の高い規格の 1 つを提供しています。

一般的な情報セキュリティフレームワークとは異なり、IEC 62443-4-1 認証は、サプライヤーが、アップタイムが重要であり、パッチ適用期間が制限され、ソフトウェアの不具合によって物理的な世界に影響を及ぼす可能性がある産業環境向けに特別に設計された手法を実装していることを証明します。

IEC 62443-4-1 認証は、ソフトウェア・サプライヤーが、単にセキュリティを約束するだけでなく、すべての製品に体系的なセキュリティ・エンジニアリングを施していることを、第三者によって検証された具体的な証拠となる。製造業や重要インフラの相手先商標製品製造業者（OEM）、システム・インテグレーター、エンド・カスタマにとって、これは重要な信頼の基盤となる。

評価の再考

SSDLC を念頭にパートナーを評価する場合、製造業者は以下を行うべきである：

• SSDLC の基準を調達プロセスに組み込む：サプライヤが当初から期待されることを理解できるよう、RFP や契約に安全な開発要件を含める。
• 構造化された証拠を要求する：デューディリジェンスの一環として、認証スコープ、審査員報告書、SBOM の記録及び試験結果を要求する。
• 関連する認証に優先順位をつける：特に、産業環境で運用される製品ベンダーについては、IEC 62443-4-1、組織のセキュリティガバナンスについてはISO/IEC 27001、該当する場合はクラウド固有の認証を確認する。
• 成熟度を継続的に評価する：ベンダー管理に継続的なモニタリングを組み込み、二元的なアンケートを超えて、成熟度の連続性に沿ってサプライヤーを評価する。

製造業者は、サプライヤのセキュリティ評価をインフラと運用だけに焦点を当てたものとして扱う余裕はもはやない。開発ライフサイクルこそが脆弱性の発生源であり、メーカーは脆弱性を確実に防止しなければならないのです。

アクロニスTRUについて

アクロニスのスレットリサーチユニット（TRU）は、脅威インテリジェンス、AI、リスク管理を専門とするサイバーセキュリティ専門家チームです。TRUチームは新たな脅威を研究し、セキュリティに関する洞察を提供し、ガイドライン、インシデント対応、教育ワークショップでITチームをサポートします。

最新のTRUリサーチを見る

アクロニスが後援・執筆