パロアルトネットワークスの提供するApache Log4jからの包括的保護

This post is also available in: English (英語)

2021年末に開示されたApache Log4jの脆弱性は2つの理由からとくにやっかいな問題となりました。第1の理由はApache Log4jが世界中の企業で広く利用されており、オープンソースソフトウェアや自社開発アプリケーションにバックエンドのロギングライブラリとして組み込まれていて影響範囲が大きいという点です。Apache Log4jの問題はほぼだれにでも影響するのです。第2の理由は修復に数週間かかりかねないという点です。最良の対策は最新バージョンにアップグレードすることですが、そのためにはまずパッチを当てねばならないインスタンスがどこにどれだけ存在しているか把握せねばなりませんし、Java 8がインストールされていることも確認しないといけません。パッチ適用前にJavaじたいをアップグレードするのは大仕事ですし、Log4jのパッチ適用前にテストサイクルを回してアプリケーションの動作への影響を調査するのも、年末に生産を停止するのもたいへんです。こうした理由から最新版への更新を何日あるいは何週間も見合わせるケースがあります。

パロアルトネットワークスはApache Log4jの脆弱性からどのようにしてお客様を保護しているのか

パロアルトネットワークスのお客様は、以下のような方法でApache Log4jのリモートコード実行脆弱性を悪用する攻撃から保護されています。さらに、影響を受けるアプリケーションを特定し、必要に応じてインシデント対応を行うための多くのソリューションも提供しています。

エクスプロイトの阻止

パロアルトネットワークスのお客様はアクティブな脅威防御セキュリティサブスクリプションを備えた次世代ファイアウォール、Cortex XDR、Prisma Cloudによる保護を受けています。これによりお客様組織の担当部門が脆弱性にパッチを適用するまでの時間を稼ぐことができます。

• 脅威防御セキュリティサブスクリプションを備えた次世代ファイアウォール(PA-Series、VM-Series、CN-Series)またはPrisma Accessは、同脆弱性に関連するセッションを自動的にブロックできます。
  • 弊社のセキュリティベストプラクティスをすでに実践されているお客様は、手動での介入なしに、これらの攻撃に対し自動的に保護されます。これらのシグネチャは、攻撃の第一段階をブロックします。
  • セキュリティプロファイルのベストプラクティスが適切なセキュリティポリシーに適用されていること、「Critical(緊急)」レベルの脆弱性が「reset(リセット)」または「default(デフォルト)」アクションに設定されていることを確認してください。
  • Log4jのリモートコード実行には外部にホストされたコードへのアクセスが必要です。Advanced URL Filtering セキュリティサービスは、常時監視を継続し、新たな未知/既知の悪意のあるドメイン/Webサイトによる安全でない外部への接続をブロックします。
  • 適切な出口方向(Egress)のアプケーションフィルタリングを使うことで攻撃の第2段階をブロックできます。「ldap」、「rmi-iiop」のApp-IDを利用すれば、信頼されていないネットワークや予期せぬ接続元との間のすべてのRMI、LDAPをブロックできます。
  • HTTPSを介した既知の攻撃をブロックするにはファイアウォール上で「SSL復号化」を有効にする必要があります。
  • Log4jが自社環境内にあるお客様は、各ベンダの指示にしたがい、アップグレードまたは緩和策の適用を行うようにし、脅威防御シグネチャだけにたよらないようにしてください。
  • さらに詳しくはこちらのクラウド配信型セキュリティサービスを利用したNGFWで、これらの脆弱性からお客様を保護する方法を確認してください。
• Cortex XDR agent 7.0以降およびコンテンツ290-78377をLinux上で実行しているCortex XDRのお客様は、Java Deserialization Exploit保護モジュールですべてのエクスプロイトチェーンから保護されています。Cortex XDRのお客様は、BTP (Behavioral Threat Protection) により、CVE-2021-44228に起因する様々な観測済みペイロードから保護されます。また、Cortex XDR Proをお使いのお客様でAnalyticsをお使いの場合は、この脆弱性に関連したエクスプロイト後のアクティビティが検出されます。
• Web Application and API Securityモジュールを有効にして、Enterprise EditionまたはCompute Editionで最新のコンソールバージョン（21.08.525, Update 2以上）を実行しているPrisma Cloudのお客様は、このCVEに対する仮想パッチを活用することで、積極的にエクスプロイトを特定し、防御することができます。利用中のPrisma Cloudが最新バージョンではない場合、Preventモードでカスタムルールを手動で作成して有効化できます。

インシデントスコーピング: どのシステムにパッチを当てる必要があるかを特定

新しいセキュリティ脆弱性が表面化するたび、攻守両サイドで脆弱なシステムの特定競争が始まります。この時点で防御側は「影響を受ける資産の全インベントリ」を把握していなければなりません。以下、パロアルトネットワークスがどのようにしてこの可視性を提供できるかを説明します。

• Prisma Cloud: Prisma Cloud Defenderエージェントは、継続的インテグレーション (CI) プロジェクト、コンテナイメージ、またはホストシステムが、2.14.1またはそれより古いバージョンの脆弱なLog4jパッケージまたはJARファイルを保持しているかどうかを検出できます。
• Cortex XSOAR: Cortex XSOARには、ワークフローの多くを自動化するプレイブックがあります。「CVE-2021-44228 - Log4j RCE'」パックをダウンロードすると、NGFW、Cortex XDR、SIEM製品全体で、この脆弱性のエクスプロイトを自動検出して防止できます。詳しくはXSOAR マーケットプレイスをご覧ください。
• Cortex Xpanse: この外部攻撃対象領域管理製品を使えば、資産の全インベントリを検証することで、脆弱性データの集約や必要な対策の伝達が容易になります。

インシデントレスポンス

Log4jの脆弱性に関連したインシデントが発生していることが予想される場合や、迅速な対応と復旧に追加のマンパワーが必要となった場合はUnit 42がお手伝いします。侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、infojapan@paloaltonetworks.com まで電子メールにてご連絡ください (ご相談は弊社製品のお客様には限定されません) 。
Log4jの脆弱性に関する詳細な調査結果についてはUnit 42によるまとめ記事をご覧ください。

Log4jからの教訓

自分はApache Log4jを使用していなくても、パートナー、顧客、サプライヤーが脆弱なコンポーネントを含むソフトウェアを使用している可能性があります。2021年末に見つかったこの脆弱性は、相互に依存しあう大規模なテクノロジエコシステムの脆さをあらわしています。サプライチェーンではよく知られている概念に「ブルウィップ効果」というものがあります。予測外の供給変動があったとき、その変動が積み重なり、結果的に実需の変動量から乖離したコスト高を個々の企業にもたらす、というものです。サイバーセキュリティ分野では、このブルウィップ効果のサイバーセキュリティ版とでも呼ぶべきものを私たちは体験しています。そこでは、たった1つの脆弱性がグローバルなインシデントにつながるようなインフラをもつことで、場にいる全員が影響を被ります。

最新のLog4jの分析結果と緩和策、最新の脆弱性更新情報にアクセスするには、引き続き Unit 42ブログやUnit 42によるApache Log4jの脅威に関する最新情報のブリーフィングのオンデマンドリプレイをご確認ください。