正規ライブラリに偽装した「Sharp7Extend」対策

攻撃名Sharp7Extend NuGet パッケージによるサプライチェーン攻撃標的Siemens S7 PLCと通信する.NETアプリケーション (エンジニアリングツール、HMIなど)攻撃ベクトルソフトウェアサプライチェーンの侵害（Typosquatting/NuGet パッケージ）最終目標遅延型の妨害・データ改ざん：ランダムなプロセス終了と、PLCへのサイレントな書き込み失敗

この攻撃は、ICS環境への侵入から最終的な影響に至るまで、複数の戦術（Tactics）にまたがって実行されます。

目的 (Tactics)手法 (Techniques)Sharp7Extendの実行内容開発不正なパッケージの作成 (T1607 - Supply Chain Compromise / Software Package Repository)既存の正当なライブラリ「Sharp7」に「Extend」を付けてTyposquattingパッケージを作成。パッケージ内に機能する正規コードと悪意のあるコード(~20行)を混在させる。開発検出回避メカニズムの構築 (T1200 - Defense Evasion)悪意のあるペイロードの実行を数十分～数年遅延させるメカニズムを組み込む。また、確率的実行（20%の確率でクラッシュ）により、障害をランダムなバグやハードウェア故障に偽装する。

目的 (Tactics)手法 (Techniques)Sharp7Extendの実行内容侵入サプライチェーンの侵害 (T0880 - Supply Chain Compromise)開発者が誤って悪意のあるNuGetパッケージ（Sharp7Extend）をエンジニアリングアプリケーションの依存関係に組み込む。

目的 (Tactics)手法 (Techniques)Sharp7Extendの実行内容起動拡張メソッドのハイジャック (T0801 - Application Access)C#の拡張メソッドを利用し、アプリケーション内のすべてのデータベースおよびPLC操作（PLCへの書き込み、読み出し）を透過的に傍受・ハイジャックする。起動時限式ペイロードの実行 (T0801 - Application Access)アプリケーション起動後、ペイロードが一定時間（30分～90分）後に起動し、その後、ランダムなプロセス終了（20%の確率）を開始する。

目的 (Tactics)手法 (Techniques)Sharp7Extendの実行内容隠蔽ノイズに紛れ込ませる (T0808 - Event Suppression)遅延起動により初期のコードレビューやテストを回避する。
確率的実行（ランダムなクラッシュ）により、問題の原因をネットワーク障害やハードウェア障害に誤認させる。隠蔽偽装 (T0806 - Masquerading)パッケージの99%が正規の機能コードであるため、コードレビューをすり抜ける。隠蔽偽のシグナル (T0808 - Event Suppression / False Signals)PLCへの書き込み失敗の際、アプリケーションには偽の成功信号を返し、データ完全性の問題を隠蔽する。

目的 (Tactics)手法 (Techniques)Sharp7Extendの実行内容可用性の低下プロセス終了 (T0829 - Program Termination)アプリケーションのランダムなプロセス終了を引き起こし、システムの安定性を損なう。データの完全性侵害プロセス制御の破壊 (T0804 - Manipulate Control / Process Data)PLCへのクリティカルな書き込み操作（WriteDBSingleByteなど）をサイレントに失敗させ、アクチュエーターや安全システムの設定を意図せず変更されないままにする（データ整合性の侵害）。

この攻撃が狙う脆弱性は、IEC 62443の以下の機能要件の欠如、または既存の防御策の不十分さを突いています。

IEC 62443 FR (機能要件)攻撃への脆弱性SL-4での対策要件 (重要)FR 3 - システム完全性 (SI)ソフトウェアの改ざん、特に偽の成功信号によるデータ完全性の侵害。Root of Trustに基づく実行前検証（HDR 3.14, EDR 3.14）、継続的監視と稼働中検証（SR 3.3, SR 6.2）によるデータ整合性の保証。FR 6 - イベント応答 (TRE)攻撃がランダムな障害に偽装されるため、インシデントとして迅速に特定できない。異常な挙動の自動検知と中央集権的な監査証跡の収集・分析（SR 2.8, SR 6.2）により、ステルス性の高い異常も系統的に特定する。FR 2 - 利用制御 (UC)認証された「アプリケーション」自体がマルウェアを介して不正な振る舞いをする。多要素認証（CR 1.1 RE(2)）や最小権限の原則（CR 2.1 RE(1)）に加え、モバイルコードの認証と完全性検証（SAR/HDR/NDR 2.4 RE(1)）を強制する。IEC 62443-4-1/2-4開発ライフサイクルとサプライチェーンにおけるセキュリティチェックの欠如。開発プロセス（4-1）とサービス提供（2-4）の両方で、使用する全ソフトウェアのSBOMの監査、依存関係の完全性検証を義務化する。

「Sharp7Extend」のようなサイバー攻撃のATT&CK分析結果から見て、IEC62443-4-2のSL-1やSL-2レベルだけでは対策が難しいと思います。

この種の脅威は-4-2の範囲外の防御策を必要とします。

記事にある脅威（Sharp7Extend NuGetパッケージによるSiemens PLC向けの攻撃）は、以下の理由から、PLCコンポーネント自体を対象とした防御策（IEC 62443-4-2）では効果が限定的です。

1. 攻撃対象レイヤーの違い:
   • IEC 62443-4-2は、PLCなどのIACSコンポーネント自体のセキュリティ機能（認証、通信の完全性、システム完全性など）を規定します。
   • この攻撃は、PLCと通信を行うエンジニアリングツールやカスタムアプリケーションのサプライチェーン（依存関係）を侵害します。
   • 侵害されたアプリケーションからPLCへ送信されるのは、PLCにとっては正当なプロトコル（S7通信）を用いたコマンドであるため、PLC側（-4-2の範囲）の認証や通信の暗号化といった防御は突破されます。
2. ステルス性の高い妨害:
   • 特に「サイレントな書き込み失敗」（約80%の書き込み操作が失敗しつつも成功信号を返す）は、PLC側でデータ整合性（FR7）の異常を検知する仕組みがなければ、システムレベルの異常としてしか認識されません。
   • また、時限起動や確率的な実行により、システムクラッシュもネットワーク障害やハードウェアの偶発的な故障と誤認されやすく、悪意のある攻撃としての特定が困難です。

この問題に対処するには、IEC 62443-4-1（製品開発ライフサイクル）や、IEC 62443-2-4（IACSサービスプロバイダのセキュリティプログラム要件）、およびIEC 62443-3-3（システムレベルの要件）で求められるサプライチェーンセキュリティと運用面の防御策が不可欠となります。

公開情報に基づき、この種のサプライチェーン攻撃およびステルス攻撃に対する具体的な対策は以下の通りです。

サプライチェーンの健全性を確保するための対策です。

1. 依存関係の衛生管理の徹底:
   • 公開元IDの厳格な検証:
     NuGetのエイリアス名だけでなく、公開元の信頼性、過去の活動、パッケージ署名などを徹底的に確認します。
   • タイポスクワットへの警告:
     Sharp7をSharp7Extendとするような、意図的な名前の類似による誤認を誘うパッケージをインストールしないよう、開発者への注意喚起と自動検出システムを導入します。
   • 依存関係スキャン:
     アプリケーションへの組み込み前（プリマージ）およびインストール時（ビルド時）に、依存関係の変更や追加されたコードをスキャンし、既知の脆弱性や不審なロジック（例：不必要なネットワーク通信、ファイルシステムアクセス、時限ロジック、確率的実行パターン）がないか監視します。
2. 最小権限の原則:
   • エンジニアリングツールを実行する環境（ワークステーション、サーバー）のネットワーク分離を徹底し、PLC通信に必要な最小限の権限のみを付与します。

攻撃がすり抜けた後の影響を最小限に抑え、検知するための対策です。

1. 書き込み操作の検証（Write Verification）の実装:
   • 最も重要な対策です。PLCへの書き込み操作が成功した後、実際にデータが期待通りに書き込まれたかを読み戻して検証するメカニズムを実装します。これにより、記事にあるような「サイレントな書き込み失敗」を検知できます。
   • 特に安全関連システム（SIS）に関わる設定値やパラメータの書き込みには、この検証を必須とします。
2. 通信成功率のベースライン監視:
   • PLC通信の成功率、応答時間、エラーレートについて、通常時のベースラインを設定し、逸脱を監視します。記事の攻撃による「確率的なプロセス終了」（20%のクラッシュ率）は、断続的な通信失敗や接続終了として現れるため、ベースラインからの異常な増加を検知することが重要です。
3. データ整合性の監査:
   • 重要な制御システムデータについて、定期的に整合性チェックを行い、不正な改ざんや期待値からの逸脱がないかを監査します。
4. 安全システムログの詳細なレビュー:
   • 安全システム（SIS）のログを詳細にレビューし、PLCからの指示の欠落や、安全機能の起動失敗といった異常がないかを確認します。

エンジニアリングツール内でこのソフトウェアを含めてコンパイルされると、IEC 62443-4-2の防御要件では防御は難しくなります！

今回の脅威（Sharp7Extend）は、ソフトウェアサプライチェーン攻撃という特性を持っています。

• 攻撃対象:
  PLCコンポーネント（IEC 62443-4-2の直接の対象）自体ではなく、そのコンポーネントと通信するエンジニアリングアプリケーションの依存関係（NuGetパッケージ）を狙っています。
• バイパスのメカニズム:
  悪意のあるコードは、正当な機能の中に埋め込まれ、C#の拡張メソッドを利用してPLCへの書き込み操作を透過的にハイジャックします。
• -4-2の限界:
  IEC 62443-4-2は「IACSコンポーネントの技術的セキュリティ要件」を定めていますが、この攻撃はコンポーネントの外部にある開発/インテグレーション環境を侵害します。PLCは、認証されたクライアントからの正規のプロトコルによる通信（S7通信）を受け入れているため、コンポーネントレベルの認証(FR1) や通信の完全性 (FR3)の要件だけでは、このアプリケーションレイヤーでの不正な操作を防ぎきることが困難です。

そこで、対策強化としてNIST CSFとIEC 62443 SL-4の多層防御対策であれば、効果が出てくると思います。

NIST CSFの5つの機能（Identify, Protect, Detect, Respond, Recover）と、IEC 62443の最高レベルの要件であるSL-4の能力を組み合わせることで、この種の高度なサプライチェーン攻撃に対してより包括的な防御・対応が可能になると考えられます。

NIST CSF 機能対策の方向性IEC 62443 SL-4での実現可能性と対応要件Identify (特定)ソフトウェアの供給元を厳格に管理し、意図しない脆弱性を特定する。IEC 62443-4-1 (製品開発): セキュアな製品ライフサイクル要件をサプライヤーに要求。
IEC 62443-2-4 (サービスプロバイダ): サプライチェーンの要件を契約に含める (SP.01.03, SP.01.04など)。Protect (防御)信頼されていないコードの実行を防ぎ、システム間のアクセスを厳格に制限する。強固な認証 (FR1): SL-4では、すべてのユーザー（人間、ソフトウェアプロセス、デバイス）に対して一意の認証と多要素認証が要求される。
最小機能 (FR7): 不必要な機能、ポート、プロトコル、サービスを禁止・制限する (CR 7.7)。
ソフトウェア完全性 (FR3): SL-4では、ソフトウェアの完全性（ハッシュ値など）の自動通知と、起動プロセスでのサプライヤーの信頼の根拠（Root of Trust）による認証が求められる (HDR 3.14 RE(1)など)。Detect (検知)異常な挙動やセキュリティ機能のバイパス試行を継続的に監視する。継続的監視 (FR6): SL-2以上で継続的監視が要求される (SR 6.2)。
イベント監査 (FR2): SL-4では、システム全体の中央集権的な監査証跡管理が要求され、標準フォーマットでのエクスポートが可能 (SR 2.8 RE(1))。
セキュリティ機能の検証 (FR3): SL-4では、通常運用中でもセキュリティ機能の動作検証をサポートする (SR 3.3 RE(2))。Respond (対応)侵害を封じ込め、影響を緩和し、インシデントに迅速に対応する。サービスプロバイダの対応 (IEC 62443-2-4): サイバーセキュリティインシデントの検知、報告、対応の能力 (SP.08.01 BR)。
隔離機能 (FR5): SL-3/SL-4では、ネットワーク境界での「モード insulaire（アイランドモード）」や「fermeture en cas d'échec（フェールクローズ）」といった緊急時の通信遮断機能が要求される (NDR 5.2 RE(2), RE(3))。Recover (復旧)迅速にシステムを復旧し、セキュリティ状態を再構築する。リカバリ (FR7): SL-1以上で「既知の安全な状態」への回復・再構築能力が要求される (CR 7.4)。
バックアップの検証 (FR7): SL-2以上でバックアップの信頼性検証（バックアップ検証）をサポートする (CR 7.3 RE(1))。

以上のように、IEC 62443-4-2（コンポーネント技術要件）のベースラインだけでは、この高度なサプライチェーン攻撃を防ぐのは非常に困難です。しかし、IEC 62443が要求する最高レベルのSL-4の要件を満たすシステムを構築すれば、以下のような多層的な防御が理論上可能です。

1. サプライチェーン管理（IEC 62443-4-1/2-4）:
   そもそもエンジニアリングツールの依存関係の信頼性を開発・導入段階で厳しくチェックする。
2. 実行前チェック（FR3/FR4）:
   侵害されたコンポーネントが実行される際、SL-4が要求するRoot of Trustに基づくソフトウェアの認証・完全性チェック（HDR 3.14 RE(1)など）に失敗し、起動や動作を阻止する。
3. 実行後監視（FR6）:
   もし実行されたとしても、通常運用中のサイレントな書き込み失敗や確率的なプロセス終了といった異常な動作を継続的監視（SR 6.2）によって検知する。
4. 緊急対応（FR5/CSF Respond）:
   脅威が検知された場合、アイランドモード/フェールクローズ（NDR 5.2 RE(2)/(3)）などの機能を使って、迅速に外部との通信を遮断し、影響を最小限に抑える。

この対策は、PLCなどの末端コンポーネントの強化だけでなく、開発・運用プロセス、ネットワーク全体にわたる最高レベルのセキュリティ機能の導入（SL-4が目指すもの）によって初めて可能になると言えます。

つまり、「Sharp7Extend」のような高度なソフトウェアサプライチェーン攻撃、特にステルス性の高い妨害機能を備えた脅威に対応するには、IEC 62443の最高レベルであるSL-4の能力と、NIST CSFの体系的なアプローチを組み合わせた、開発（サプライチェーン）から運用（監視）に至るまでの多層防御が不可欠です。

この脅威に対応するために、既存システムで補完すべきIEC 62443の主要要件と、それを実現するための具体的な導入計画をNIST CSFの5つの機能（Identify, Protect, Detect, Respond, Recover）に基づいてご提案します。

NIST CSFの5つの機能は、サプライチェーン攻撃というライフサイクル全体にわたる脅威に対して、取るべき行動の優先順位付けと体系化に役立ちます。

NIST CSF 機能目的具体的なアクション（導入計画）Identify (特定)ソフトウェア構成要素とそのリスクの明確化。SBOM (Software Bill of Materials) の作成・管理：エンジニアリングツール、カスタムコード、すべての依存関係（NuGetなど）のリストを維持する。
信頼性検証プロセスの確立：使用する外部ライブラリ（特にPLC通信ライブラリ）の公開元、デジタル署名、過去の活動実績を厳格に監査し、信頼性が低い場合は使用を禁止する。Protect (防御)不正なコンポーネントの実行阻止。Root of Trust (信頼の基点) の実装（SL-4要件）：エンジニアリングアプリケーションの実行時およびロード時に、コードが改ざんされていないこと（デジタル署名やハッシュ値）を検証する機能を強制する。
最小機能・権限の原則（FR7）：エンジニアリングワークステーションは、PLC通信に必要なポート/プロトコルのみに制限し、インターネット通信や不要なサービスを厳しく禁止・制限する。Detect (検知)ステルス性の高い妨害行為の特定。書き込み検証（Write Verification）の導入：制御システムアプリケーションに、PLCへの書き込み操作が完了した後、その設定値が実際に書き込まれたかを読み戻して検証するロジックを強制的に組み込む（特に安全関連データ）。
通信・プロセスベースラインの監視：PLC通信の成功率、応答時間、関連アプリケーション（エンジニアリングツールなど）のプロセス異常終了（クラッシュ）頻度を通常時のベースラインと比較し、異常な確率的挙動（公開情報で言及された20%のクラッシュなど）を検知する。Respond (対応)迅速な隔離と封じ込め。インシデント対応計画への追加：「サプライチェーン侵害」シナリオを組み込み、特定された不審なアプリケーションやワークステーションを即座にネットワークから隔離（アイランドモードへの移行など）する手順を確立する。
フォレンジック対応の強化：侵害されたアプリケーション/コンポーネントがどのように導入され、いつトリガーされたか（時間差起動）を追跡できるように、監査証跡の収集と長期保存を徹底する。Recover (復旧)セキュリティ状態の再構築。検証済みイメージからの復旧：マルウェアを含まないクリーンで検証済みのアプリケーション、ファームウェア、システムイメージからの迅速な復旧能力を確保する。
影響範囲の再検証：復旧後、影響を受けたPLCの全パラメータが正しい値であることを徹底的に検証するプロセスを義務付ける。

このサプライチェーン攻撃（特に時限式/確率的妨害）に対応するために、既存のIEC 62443-4-2（コンポーネント）の防御だけでなく、システム（3-3）およびライフサイクル（4-1/2-4）の要件から、特にSL-4で要求される高度なセキュリティ能力を補完する必要があります。

分野関連するIEC 62443要件SL-4での具体的な補完事項A. サプライチェーン/開発IEC 62443-4-1 (製品開発ライフサイクル要件)セキュリティ要件のライフサイクル全体への組み込み：ベンダーが提供するすべてのコンポーネント（ファームウェア、ライブラリ、ツール）の開発プロセスがSL-4に準拠していることを要求し、サプライチェーン全体の信頼性を確保する。B. サービスプロバイダIEC 62443-2-4 (サービスプロバイダ要件)契約によるサプライチェーンのセキュリティ義務化：SIerやメンテナンス業者などのサービスプロバイダに対し、開発・デプロイに使用するすべてのツールやライブラリの完全性検証を義務付ける（SP.01.03/SP.01.04）。C. コンポーネントの完全性IEC 62443-4-2 (HDR 3.14) - ソフトウェア完全性Root of Trust（信頼の基点）による検証の強制：SL-4では、不正なコンポーネントの実行を防ぐため、コンポーネントの起動時および実行時に、サプライヤーのRoot of Trustを用いてソフトウェアの完全性を自動的かつ透過的に検証する能力が必須となります。D. システムの監視/検証IEC 62443-3-3 (SR 3.3) - システム完全性セキュリティ機能の稼働中検証：SL-4では、通常運用中にセキュリティ機能が正しく動作しているかを検証する能力をサポートしなければなりません。これは、前述の「書き込み検証 (Write Verification)」をシステム全体のデータ完全性確保の手段として確立することを意味します。E. イベント監視/検知IEC 62443-3-3 (SR 6.2) - 継続的監視
IEC 62443-3-3 (SR 2.8) - イベント監査異常な挙動の自動検知：PLC通信のエラーレートや応答時間などの運用上の指標を継続的に監視し、記事で言及されたような確率的な、または時限的な妨害行為による異常な変動を自動で検知・通知するシステム（OT-IDSなど）を導入する。

以上ですが、対策を具体的に実施する場合は、高度な制御システムセキュリティ技術コンサル能力を必要とします。

ICS研究所にお気軽にお声がけください。