ベンダーや業界専門家からサイバー攻撃について恐ろしい話が多く語られているものの、実際に壊滅的な被害をもたらす攻撃はそれほど多くありません。しかし、ジャガー・ランドローバー（JLR）への攻撃はまさに壊滅的なものでした。
JLRの侵害は、数十万ドルの損失で済むような迷惑レベルの攻撃ではありませんでした。生産は数週間にわたって完全に停止し、ロイターによれば英国経済には20億ドル以上の損失が発生し、最大5,000の組織に影響を与えました。実際に仕事を失った人々もいます。
JLRを存続させるため、英国政府は約20億ドルのローン保証で介入せざるを得ませんでした。
悪夢が現実に
JLRへの攻撃は、製造業が理論上起こり得ると認識していた悪夢のシナリオでした。それが現実に起きたことで、多くの製造業組織は自社が同じ運命をたどらないために何ができるのかを慌てて検討することになりました。
すぐに明らかになった問題のひとつは、サプライチェーンが製造業にとって最も弱いセキュリティ上のリンクのひとつだということです。実際、JLRへの攻撃は、サードパーティの請負業者が使用していた認証情報の侵害という、同社のサプライチェーンから発生しました。
攻撃者はどのようにしてサプライチェーンへ侵入しているのでしょうか。その強力な手口のひとつが、製造業者やそのサプライチェーンパートナーが利用するソフトウェアアプリケーションの開発ツールやプロセスを狙うことです。
それがJLRを陥れた攻撃の種類だったのかどうかは分かりません。攻撃の発端に関する詳細は公開されていません。しかし重要な教訓は、製造業者とそのサプライチェーンパートナーが、ソフトウェアプロバイダーにセキュアな開発手法の採用を徹底させていなければ、JLRが受けたレベルの攻撃に対して無防備な状態になってしまう、ということです。
サプライチェーンが照準に
ソフトウェア開発を通じたサプライチェーンへの攻撃は新しいものではありませんが、依然として強力かつ危険です。これまでに行われた最も有名なサイバー攻撃のいくつかはこの手口を伴っており、その中には悪名高い2020年のSolarWindsへの攻撃、2021年のKaseya VSAへの攻撃、2023年のVoIPプロバイダー3CXへの攻撃などがあります。
攻撃者は最近、新たなアプローチを編み出しました。ソフトウェア開発プロセスに悪意のあるNode Package Manager（NPM）を投入するというものです。JavaScript開発者は、再利用可能なコードを共有・インストールするためにNPMを利用します。
NPMが悪意のあるものだった場合、攻撃は急速に拡散し、数か月にわたって潜伏し、あらゆる種類のアプリケーションに紛れ込む可能性があります。
NPMを狙った最近の例のひとつがShai-Huludクリプトスティーラーであり、サイバーセキュリティプロバイダーが利用するものを含め、500以上のNPMパッケージが侵害されたと報告されています。
NPM攻撃は、攻撃者がサプライチェーンに侵入するために見出した手口のひとつにすぎません。たとえば、攻撃者はソフトウェアベンダーのアップデートを改ざんしたり、ソフトウェアの脆弱性を悪用したりすることもできます。
結論として、サプライチェーンのアプリケーションは脆弱であり、製造業者はパートナーが使用しているアプリが安全であることを確認する必要があります。
より綿密な評価の必要性
サプライチェーンがリスクにさらされている状況では、製造業者は既存および候補となるパートナーを、セキュアソフトウェア開発ライフサイクル（SSDLC）の実践という観点から評価する必要があります。
ほとんどのOT（オペレーショナルテクノロジー）環境では、調達時の評価はベンダーの財務健全性、サービスレベル契約、インフラセキュリティに重点が置かれます。しかし、ソフトウェア開発プロセスに潜む脆弱性、すなわちサプライチェーンアプリを台無しにしかねない問題は見落とされがちです。
だからこそ、厳格なSSDLCの実践を製造業者とそのサプライチェーンパートナーの双方で確保することが非常に重要なのです。製造業者がパートナーに対してSSDLCの実践を徹底しなければ、操業停止、財務損失、コンプライアンス違反、評判の失墜といったリスクにさらされることになります。
SSDLC：単なるコンプライアンスのチェック項目ではない
SSDLCがこれほど重要かつ有効なのはなぜでしょうか。まず第一に、EUのNIS2指令の下で、正式な文書化されたSSDLCプロセスが義務付けられているからです。
また、セキュリティを開発後の付け足しとして扱うのではなく、ソフトウェア作成プロセス全体に組み込むという、根本的な発想の転換を体現しているからでもあります。
要件定義の段階で脆弱性を発見できれば、修正にかかる時間は数時間で済むかもしれません。同じ欠陥がリリース後に見つかった場合、緊急対応に数週間を要する可能性があります。
実務上、成熟したSSDLCの実装には次のような要素が含まれます。
- セキュリティ・バイ・デザイン：コードを書く前にセキュリティ要件を定義し、脅威モデリングを実施する。
- セキュアコーディングの実践：開発者にセキュリティ教育を行い、コードレビューと自動セキュリティテストを必須とする。
- 依存関係の管理：サードパーティコンポーネントを精査・追跡し、SBOM（ソフトウェア部品表）を通じて維持管理する。
- セキュアなリリースパイプライン：アップデートに署名し、完全性を検証し、堅牢化されたチャネルを通じて配信する。
- 脆弱性管理：協調的な情報開示プロセスと、セキュリティ問題に対する明確な対応タイムラインを定める。
製造業者にとってこれは、生産ラインを制御し、重要システムを管理し、産業オペレーションを接続するソフトウェアに対して、最初の1行のコードから最終的なデプロイメントに至るまでセキュリティが組み込まれていることを意味します。
セキュア開発の確かな証拠：IEC 62443-4-1認証
業界認証は、開発プロセスにおけるSSDLCの活用を測る信頼できる指標です。さまざまなセキュリティ認証が存在しますが、製造業のサプライチェーンにとって特に重要なのがIEC 62443-4-1です。
IEC 62443ファミリーの規格は、産業用オートメーションおよび制御システムのセキュリティ、すなわち製造業者がまさに事業を行っている環境を対象としています。
この枠組みの中で、IEC 62443-4-1はセキュアな製品開発ライフサイクル要件に特化しており、OTソフトウェアサプライヤーを評価するうえで最も厳格かつ関連性の高い規格のひとつを提供します。
一般的な情報セキュリティフレームワークとは異なり、IEC 62443-4-1認証は、サプライヤーが稼働時間が極めて重要で、パッチ適用の時間枠が限られ、ソフトウェア障害が物理世界の結果を招き得る産業環境向けに特別に設計された実践を導入していることを示します。
IEC 62443-4-1認証は、ソフトウェアサプライヤーが単に「セキュリティを約束している」のではなく、すべての製品に対して体系的にセキュリティを設計・組み込んでいることを、具体的かつ第三者によって検証された証拠として提供します。OEM（相手先ブランド製造業者）、システムインテグレーター、製造業および重要インフラ分野のエンドユーザーにとって、これは信頼の重要な土台となります。
評価の再考
SSDLCを念頭にパートナーを評価する際、製造業者は次の点に留意すべきです。
- SSDLCの要件を調達プロセスに組み込む：RFP（提案依頼書）や契約書にセキュア開発要件を明記し、サプライヤーに対して初期段階から期待値を明確にする。
- 構造化された証拠を要求する：認証の適用範囲、監査人レポート、SBOM記録、テスト結果などをデューデリジェンスの一環として求める。
- 関連性の高い認証を優先する：産業環境で稼働する製品ベンダーにはIEC 62443-4-1を特に重視し、組織的なセキュリティガバナンスにはISO/IEC 27001を、必要に応じてクラウド特有の認証を補完的に確認する。
- 成熟度を継続的に評価する：単純な二者択一のアンケートを超え、サプライヤーを成熟度の連続体として評価し、ベンダーマネジメントに継続的なモニタリングを組み込む。
製造業者はもはや、サプライヤーのセキュリティ評価をインフラとオペレーションだけに焦点を当てた形式的な作業として扱う余裕はありません。脆弱性が生まれるのは開発ライフサイクルであり、そこでこそ製造業者は脆弱性が未然に防がれていることを確認しなければならないのです。
Acronis TRUについて
Acronis Threat Research Unit（TRU）は、脅威インテリジェンス、AI、リスク管理を専門とするサイバーセキュリティのエキスパートチームです。TRUチームは新たな脅威を調査し、セキュリティインサイトを提供するとともに、ガイドライン、インシデント対応、教育ワークショップを通じてITチームを支援します。
