OT 環境での Log4Shell リスク:防御のための最適な手段を探る

Log4Shell Vulnerability Risks for OT Environments — and How You Can Better Protect Against Them

2021/12/19 SecurityIntelligence — Log4Shell の脆弱性を知らない (対応していない) IT 担当者はいない、と言っても過言ではないだろう。オペレーショナル・テクノロジー (OT) の分野も例外ではないが、この脆弱性が OT テクノロジーにおよぼす影響については、まだ完全には解明されていない。今月の初めに公開された、この脆弱性については、最新のパッチ情報を含め、ココで詳細を確認できる。IT 業界は、ネットワークを強化して不正侵入を防ごうとしているが、OT 環境では更に集中的なアプローチが必要になるかもしれない。

OT 分野における潜在的なリスク

OT 分野でのセキュリティ侵害は公表されていないが、この 10年間で開発された Java プログラムには Log4j が広く浸透しているため、Log4j を悪用しようとする攻撃者にとって、OT 分野は格好の標的となる。

OT ネットワークを持つ企業が、狙われる可能性も十分にある。たとえば、ある攻撃者が、脆弱なソフトフォン管理システムを介して、IT ネットワークに最初にアクセスする。そのシステムを、内部ネットワークへのプロキシとして動作するように設定した後に、情報収集のために dual homed に設定された、脆弱なロギング/モニタリング・システムを発見するかもしれない。IT/OTのネットワークで、このようなシステムにアクセスした攻撃者により、設計上安全でない可能性のある OT へのダイレクトなアクセスや、認証されていない OT デバイスに直接接続されている可能性のある、エンジニアリング・ワークステーションや HMI へのアクセスなどが引き起こされる可能性がある。

このシナリオで言及されている、すべての種類のデバイスにおいては、Log4Shell 関連の脆弱性について、少なくとも1つの勧告が公開されている。したがって、Log4Shell の脆弱性は、OT システムを構成/サポートする主要な技術に、影響をおよぼす可能性がある。その中には以下のようなものが存在する。

  • サーバー (例:ヒストリアン/エッジサーバー)
  • ワークステーション (例:HMI)
  • ネットワーク機器 (ファイアウォール/ルーター/スイッチ)
  • 組み込み機器 (例:Web カメラ/Car Navi/パーキングメーター/医療機器)

    OT セキュリティ・チームが取るべき行動

    Log4Shell の脆弱性 (CVE-2021-44228/CVE-2021-45046) は新しいものだが、目新しいものではない。OT 環境における最適な緩和策は、適切なシステム設計とアーキテクチャ (例:ISA 62443 リファレンスモデル) または、ゼロトラスト・アーキテクチャに見出すことができる。そのため、OT における Log4Shell の影響を抑制するための、IBM Security X-Force の重要な検討事項を以下に示す。

    1. リスクの高いシステムを特定し、可能な限り積極的にパッチを適用する
  • 企業ネットワークに最も近い場所にあるOTシステムは、最大のリスクにさらされており、脅迫者が OT へのピボット・ポイントとして活用する可能性が最も高いと言える。
  • ICS (Industrial Control System) の主要ベンダー (Siemens/Schneider/Prosys など) の中には、すでに勧告を発表しているところもある。これらのベンダーの勧告や、Log4j の実装を特定できるアクティブ・スキャン (実行可能な場合) を使用して、Log4j の特定と修復を優先する。
  • 一般的に、OT 環境には、パッチを当てられないデバイス/耐用年数が終了したデバイス/サイバー的に脆弱なデバイス/設計上安全ではないデバイスが溢れている。パッチを当てることができない場合には、これらのシステムが安全なゾーンに隔離されていること、および、緩和制御が行われていることを確認する。

    2. IT/OT のセグメンテーションと境界線の最低限の保護を行う
  • OT のサイバー・セキュリティでは、エンタープライズ・ゾーンは信頼されていないと考えられている。そのため、最大のリスク低減活動は、最小権限のルールセットにより、IT と OT の間のデータ・フローをビジネスに適したかたちで、ポート/プロトコルのみに制限し、ソース/デスティネーションを設定することだ。
  • この最小特権のルール・セットは、脅威アクターによる Log4j の Command and Control 機能を大幅に減少させるはずである。

    3. OTネットワークを監視する
  • 侵入検知システム (IDS : Intrusion Detection System) やネットワーク監視システムがOT ネットワークに導入されているケースでは、潜在的な悪用への迅速な対応のためにアラートを検出/エスカレートするよう、Log4Shell IOC をコンフィグレーションできる。OT IDS ベンダー (Armis/Claroty/Nozomi) による、一連の勧告に注意してほしい。
  • ログ管理ソフトウェアを使用して、悪用の試みを探し出す。
  • X-Force の Threat Hunting Frameworkを 使用では、仮説主導型の脅威探索が可能だ。サイバー・セキュリティ・チームは、TTP の網羅的なリストを作成し、今後のエクスプロイトの公開に際して、仮説に基づいたハンティングを実行することを推奨する。

    4.ソフトウェア部品表 (SBOM : Software Bill of Materials)
  • 一般的に、OT システムは独自の性質を持っている。これらのシステムの完全なソフトウェア・インベントリの入手は、多くの場合において困難である。ベンダーと協力して、ソフトウェア・インベントリを収集/維持/更新を行い、ベンダーがシステムで使用している可能性のあるコンポーネントを追跡する。

    5. OT のインシデント対応計画を更新/実践する
  • OT 環境専用のインシデント・レスポンス・プランを作成する。
  • インシデント対応チームのメンバーが、このようなイベントを効果的にサポートできるように、OT 用のプレイブック/順を作成し、リハーサルを行う。これらの演習から得られた教訓を活かして、計画を定期的に更新する。

    IIoT システムを見落とさないために

    さらに、企業は IIoT システムを無視してはいけない。これらのシステムは、組み込みデバイスやエッジ・デバイスを使用して、クラウド/プライベート・ネットワークに接続されており、そこには Webカメラ/医療機器/パーキングメーター/ナビゲーション・システムなどが含まれる。これらのデバイスが脆弱な状態で放置されると、攻撃者に対して、企業内およびクラウド環境内への侵入を許すことになる。

    ココで取り上げた一連の問題は、急速に変化/進化している。すべての OT セキュリティ・チームは、自身のシステムが、上記のように保護されていることを確認する必要がある。

    Log4j による侵害の可能性を疑う顧客には、IBM Security X-Force の米国ホットライン 1-888-241-9812 | グローバル・ホットライン (+001) 312-212-8034 で、24時間365日の支援を提供している。IBM の製品およびサービスに関する最新情報のリクエストは、このホットラインには送信しないでほしい。製品の状況に関する最新情報は、IBM PSIRT ブログに掲載されている速報で確認できる。

12月15日に「Log4J と攻撃者たち:IT/IoT/OT を狙うランサムウェア・ギャングから国家支援ハッカーまで」という記事をポストしましたが、そこには「今回の脆弱性により電力/製造/食品/飲料/輸送などの数多くの組織が、リモート操作による攻撃にさらされていると指摘する。なせなら、産業用アプリケーションで使用される、数多くのオープンソース・リポジトリに Log4j が存在するからだ」という記述がありました。今回の記事でも、Siemens/Schneider/Prosys などが Log4j への対応を開始していると記述されています。Log4j の深くて広範な依存関係などを考えると、SBOM (Software Bill of Materials) の時代になるのかなぁと思ってしまいます。→ Log4j まとめページ

%d bloggers like this: