制御・運用技術（OT）および産業用モノのインターネット（IIoT）環境における Log4j の脆弱性に対して、防衛・検知・対応 するためのアクション

このブログは 「What actions customers can take to protect, detect, and respond to Log4j vulnerabilities in Operational Technology (OT) and Industrial Internet of Things (IIoT) environments」 を翻訳したものです。

この投稿では、2021年12月に公表されたLog4jの脆弱性に対応するためのガイダンスを提供します。この投稿では、問題の影響を受けやすいかどうかを確認する方法と、OTおよびIIoT環境の脆弱性に対処する方法について説明します。

Log4j の脆弱性（CVE-2021-44228、CVE-2021-45046）は、広く用いられているロギングプラットフォームの Apache Log4j における重大な脆弱性（CVSS 3.1 ベーススコア10.0）です。この脆弱性により、攻撃者は脆弱なプラットフォームでリモートコードを実行することができます。バージョン 2.0-beta-9 と 2.15.0 の間の Log4j のバージョン 2 が影響を受けます。この脆弱性は、Java プログラムによって使用される Java Naming and Directory Interface (JNDI) を使用して、通常はディレクトリ（この脆弱性の場合は通常は LDAP ディレクトリ）を介してデータを検索します。

Log4j は、開発者によって広く使用されているオープンソースの Java ロギングライブラリです。アプリケーションでのサードパーティライブラリの使用は、産業におけるデジタル変革が OT 領域に変化をもたらしているため、IT の問題だけでなく、OT/IIoT の問題でもあります。OT/IIoTの進化に伴って、OT 環境は生産オペレーションの生産性と効率を向上させるために、より多くのITソリューションを活用するようになっています。このため、Log4j が運用技術（OT）と産業用モノのインターネット（IIoT）システムに組み込まれ、OT/IIoT ベンダーがLog4jの自社製品への影響に関するアドバイザリを発表しているのは当然のことです。産業用制御システムおよび運用技術（ICS/OT）環境における Log4j の主な課題は、現時点では影響範囲を正確に特定するのが難しいことです。今後数週間、数か月以内に、OT インフラストラクチャにおけるこの特定の脆弱性の蔓延と影響の程度を理解し始めるでしょう。しかし、Log4jは確実に、その重要なOT/IIoTシステムを実行するために用いられており、 システムをリモートコード実行に対して脆弱にしています。さらに、攻撃者は、開発言語で Java を使用する独自開発の監視制御およびデータ収集（SCADA）、エンジニアリングワークステーション、ヒューマンマシンインターフェイス（HMI）、エネルギー管理システム（EMS）、および IIoT システムに対してこの脆弱性を利用する可能性があります。

ICS/OT ベンダー、および IIoT プラットフォームプロバイダーは、影響を受けるシステムの正確な情報を共有し、脆弱性を修正するパッチをリリースし、詳細なリスク緩和計画を提供し始めました。お客様は、Log4j の影響を受ける資産を直ちに特定し、パッチが利用可能になり次第、Log4j を用いるIT資産を最新バージョンにアップグレードし、ベンダーのソフトウェアアップデートに注意を払い続ける必要があります。また、お客様は、これらのシステムへのネットワークアクセスを監視および保護し、この脆弱性の悪用からシステムを保護するために、OTの全域においてサイバーセキュリティのベストプラクティスを実装する必要があります。ここでは、運用技術 (OT) および産業用モノのインターネット (IIoT) 環境における Log4j の脆弱性から保護、検出、および対応するためにお客様が実行できるいくつかの緩和手順を示します。

保護 — デバイスにパッチを適用します。また、パッチ適用対象を理解するために、所有しているものと場所を確実に把握します。ネットワーク接続の範囲を可能な限り制限することで、Log4j の脆弱性によるリスク/リスクを軽減できます。
影響を受ける可能性のあるデジタル資産の場所を特定 — 資産/ソフトウェアインベントリを使用して、Log4j に対して脆弱であると公表された既知のアプリケーションを特定できます。https://github.com/cisagov/log4j-affected-db#software-list をフォローして、管理されている脆弱なソフトウェアのリストを表示することができます。最新の情報については、個々のベンダーのサイトを確認することが重要です。

ICS/OT 資産をスキャン — 資産/ソフトウェアインベントリが利用できない場合、またはインベントリの情報を補うために、LinuxおよびWindowsシステムの両方で、CERT/CCが公開したツールなどを使用してICS/OT資産のターゲットスキャンを実行できます。多くの OT 侵入検知システム (IDS) ベンダーは、OT および IIoT 資産の脆弱性スキャンツールも提供しています。そのため、製造オペレーションに影響を与えないように必要な予防措置を講じた後、ベンダーに確認し、実行可能な場合はスキャンを実施してください。

システム内のソフトウェアコンポーネントを理解する — システム内のソフトウェアコンポーネントを理解することで、依存するコンポーネントにセキュリティの脆弱性があるかどうかを確認できます。コードが依存するライブラリのいずれかに欠陥が見つかった場合、開発/調達するソフトウェアの依存関係を辿って、影響を受けるかどうかを判断できます。OTシステムは通常、本質的に独自仕様であることに注意してください。これらのシステムの完全なソフトウェアの構成情報は、多くの場合、入手できません。ベンダーと協力してソフトウェアの構成情報を収集、保守、更新し、ベンダーがシステムで使用するコンポーネントを追跡します。

パッチ適用 — OT/IIoT 環境のアプリケーションやエンドポイント内でこれらの脆弱性を特定した場合は、可能な場合はパッチ適用によってできるだけ早く修正します。資産の所有者は、影響を受けるソフトウェア製品へのパッチの提供をベンダーに頼ることができます。重要なことはリスク評価を行うことと、最新のネットワークアーキテクチャを使い、これらの脆弱なシステムに外部ネットワークからどのようにアクセスできるかを判断し、最も重要な資産を最初に特定してパッチを適用することです。ベンダーシステムにパッチを適用する場合は、ベンダーが提供する手順に従い、OTシステムに適用する前にパッチの広範なテストを実施します。AWS は、AWS IoT ジョブを提供し、これを用いてオンプレミスのコンピューターとエッジゲートウェイにパッチを適用することができます。AWS IoT ジョブでは、AWS IoT および AWS Systems Manager Patch Manager に接続された 1 つ以上の IIoT デバイス対して、実行する一連のリモートオペレーションを定義し、送信することができます

サポートされていないシステムの隔離 — ICS/OT 環境におけるハードウェアおよびソフトウェアの更新サイクルが長くなるにつれて、現在サポートされていない ICS/OT 製品や、ソフトウェアベンダーがもはやない ICS/OT 製品が存在するのが一般的です。OT 環境には、通常、パッチが当たらない、サポートが終了した（EOL）、サイバー脆弱性がある、設計上安全ではない、といった機器が多くあるのが通常で、このような場合パッチを適用できないことがあります。パッチを適用できない脆弱な資産（たとえば、影響を受けるソフトウェアがインターネット上の敵によって調査される可能性が高い場合）や、より大きなネットワーク化されたシステム内で使用されている資産を直接アクセスできないようにします。IT/OT ネットワークセグメントを細かく分割することで、産業システムへの影響のリスクを大幅に減らすことができます。これは、Log4j の脆弱性に係わらず一般的なベストプラクティスです。

検出 — この脆弱性が環境に存在するかどうかを監視し、OT/IIoT システムからのアラートに対応し、それらが接続する IT 環境に特に注意を払います。

セキュリティ監視 — 侵入検知システム (IDS) とネットワーク監視システムが OT ネットワークに配備されている場合、異常なトラフィックパターン (JNDI LDAP/RMI アウトバウンドトラフィック、アウトバウンド接続を開始する DMZ システムなど) を監視し、Log4Shell Indicator of Cromise (IOC) を使用して設定し、潜在的な悪用への迅速な対応のためにアラートの警告レベルを上げます。ICS ベースのアクティブな Log4j の悪用をネットワークベースで検出する方法の最新情報については、OT IDS ベンダーの勧告に注意してください。エンタープライズネットワークとインターネットに最も近くに面している OT/IIoT システムは、最も大きなリスクにさらされており、企業や組織に脅威を与える脅威アクターが OT における起点として使用する可能性があります。同様に、脅威アクターは、侵害された OT/IIoT システムを通じて、エンタープライズ環境またはクラウド環境へと攻撃対象を変える可能性があります。セキュリティ監視は包括的であるべきで、OT、産業用エッジ、IT、クラウドを含む攻撃対象領域全体をカバーする必要があります。お客様は、AWS IoT Device Defender を使用して IoT デバイスのフリートを監査および監視し、デバイスの挙動の異常を検出できます。Amazon Inspector は、オンプレミスのコンピューターやエッジゲートウェイを含む、サポート対象のあらゆる AWS Systems Manager マネージドインスタンスに存在する Log4j の脆弱性を検査し、Amazon GuardDuty を使用してクラウド内の Log4j 脆弱性の悪用に関連するセキュリティ侵害の兆候を検出します。

対応 — 疑わしいアクティビティが検出された資産に自動的に対応したり隔離したりするため仕組みを構築します。インシデント対応計画や手順書を準備し、これらを定期的に確認します。

調査とインシデント対応 — お客様は、脅威検出の手順やログ、SIEM などのツールを使用して、潜在的なセキュリティ侵害を調査し、悪意のあるアクティビティの兆候を探索し、適用可能な場合には対応と修復を行います。

お客様は AWS IoT Device Defender、Amazon Inspector、および Amazon GuardDuty とともにAWS Security Hub を 使用して、アラートを集約し、自動修復と対応を実施できます。Inspector がお客様の環境でこの脆弱性を検出したときに可視化するため、Security Hub を使用して AWS Chatbot 、Amazon Simple Notification Service 、またはチケットシステムを介してアラートの仕組みを構築することをお勧めします。長期的には、Security Hub を使用して、適切な場合にセキュリティアラートの自動修復と応答を有効にすることをお勧めします。こちらの一連のブログでは、Security Hub で自動修復と対応を設定する方法についてのアイデアを示します。

Apache Log4j セキュリティ脆弱性ウェブページで AWS の更新と緩和ガイダンスを確認および監視し、ベンダーと緊密に連携して、影響を受けるシステムの更新を監視します。さらに、CISA が提供する Apache Log4j 脆弱性ガイダンス、AWS セキュリティ速報に従い、Log4j の脆弱性に対する保護、検出、対応を行う AWS セキュリティサービスの詳細を学習します。

最後に、サポートされていないレガシーシステムを置き換える計画をできるだけ早く立てます。OTシステムには、20〜30年前のコンポーネント、またはそれよりも古いコンポーネントが含まれている可能性があります。一部のシステムは非常に古く、サイバーセキュリティに関するあらゆる懸念よりも前から存在している可能性があり、他のシステムは単にセキュリティ対策が不十分だったり、すでに製品寿命に達しているものもあります。老朽化した OT インフラストラクチャが業務に重大なリスクをもたらしていることがわかった場合、緩和戦略には、古い資産をアップグレード、交換、または廃止する計画が含まれるでしょう。全社的なセキュリティのリスクマネジメントを検討している場合、OT環境のモダナイゼーションは、組織が直面するリスクを減らすための主要な要因となります。

結論

このブログ投稿では、OT および IIoT 環境における Log4j の脆弱性を防御、検知、対応するために、お客様が階層化されたアプローチを採用できるようにする主要なアクションの概要を説明しました。この脆弱性の悪用の容易さ、影響を受ける可能性のあるアプリケーションの範囲の広さ、大規模な組織全体で包括的な修正を適用するのに必要な時間の長さを考慮して、AWS は、ICS/OT、IIoT、およびクラウド環境を保護するための、多層的かつ多層的な多層防御アプローチを採用することを推奨しています。IIoT ソリューションの AWS セキュリティゴールデンルール、OT向けのAWS セキュリティのベストプラクティスおよび AWS Well Architected Framework IoT Lens に従って、アーキテクチャのベストプラクティスに沿った IIoT ワークロードを設計、デプロイ、および設計することを推奨しています。

筆者について

Ryan Dsouza は、AWS の IIoT のプリンシパルソリューションアーキテクトです。ニューヨーク市に拠点を置く Ryan は、測定可能なビジネス成果を実現するために、幅広く奥深い AWS の機能を使用して、より安全でスケーラブルで革新的なソリューションの設計、開発、運用を支援しています。Ryan は、デジタルプラットフォーム、スマートマニュファクチャリング、エネルギー管理、ビルディングと産業オートメーション、およびさまざまな業界の OT/IIoT セキュリティで25年以上の経験があります。AWS 以前は、アクセンチュア、SIEMENS、ゼネラル・エレクトリック、IBM、AECOM に勤務し、デジタルトランスフォーメーションの取り組みにおいて顧客にサービスを提供していました。

このブログの翻訳はソリューションアーキテクトの大井が担当しました。