Tenable ブログ
ブログ通知を受信するApache Log4j の脆弱点でサードパーティのソフトウェアが焦点に
Log4Shell として知られている重大な Log4j の脆弱性の緊急対応に急ぐ世界中の企業のセキュリティ責任者が最も早く知りたいのは「どうしたらこの脆弱性があるかないかが確認できるだろうか」という質問の答えではないでしょうか。
12/17 更新情報: Apache は、CVE-2021-45046 で報告されている 2 つ目の Log4j 脆弱点の 深刻度を「低」から「重大」(9.0 CVSSv3) に変更しました。一定の設定においてリモートコード実行の可能性があることが発覚したためです。詳細は、Tenable コミュニティの 投稿 をご覧ください。
Apache Log4j はどこにでもある、非常に広範囲に使用されているオープンソースのロギングのフレームワークなので、簡単には答えられません。
Log4j は企業のソースコード内で使用されている場合も多いばかりでなく、企業が購入するサードパーティ製品にもよく使われています。 すでに「シフトレフト」のアプローチを採用してソフトウェア開発ライフサイクルのセキュリティ(SSDL) を確保している企業は、社内でソースコードを分析してシステム内の脆弱点を検出して修正することができます。
SSDL には、静的アプリケーションセキュリティテスト (SAST) と動的アプリケーションセキュリティテスト (DAST)、サードパーティ依存度チェック、コンテナセキュリティ スキャン、脆弱性管理とインフラのコード化 (IaC) が必要になります。しかし、これらをすべて実施している企業でも、「左側にあるもの」すべてを捉えることは難しいでしょう。脆弱性管理とウェブアプリのスキャンも、特にサードパーティのソフトウェアに関しては極めて重要になります。 単に脆弱点の有り無しを検知するだけでは不十分で、企業のアプリ、資産、ビジネスプロセスなどが集合したコンテキストから、実際のリスク度を把握する必要があります。
最近の大統領指令は企業にソフトウェアの物品表 (SBOM) を作成するよう呼びかけていますが、SBOM を提供しているソフトウェアベンダーは稀です。例え SBOM を提供していたとしても、それを有効活用できるようなプロセスや機能を企業が持ち合わせているかというと、何光年も出遅れているとしか言いようがありません。ですから、log4j のような問題が発生すると、サイバーセキュリティの責任者に残されている選択肢はたった1つ、サードパーティベンダーに直接問い合わせることです。これには多大な労力が必要で、冗長で時間も多くかかる作業になり、ハッカーたちが脆弱点の搾取を目指して群がってくれば、企業は対応が苦しい状況に置かれます。
FAQ はこちらから: CVE-2021-45046、CVE-2021-4104: Log4Shell に関連した脆弱性についてよくあるご質問。
SSDL を活用し、 SBOM がプロセスに組み込まれている最も成熟した企業であっても、ギャップがあり、 Apache log4j に関して次のような最も重要な 5 つの質問に即答するのは難しいでしょう。
- 自社環境で使っているか?
- 自社インフラ内で使っているか?
- ビルドのパイプラインの中ではどうだろうか?
- インフラの提供者はどうだろうか ? (クラウドサービスプロバイダのサービスを導入している場合に特に関連性が高い )
- ソフトウェアの構成分析 (SCA) では Log4J のインスタンスをすべて発見できない事実を踏まえて、インフラのコード化 (IaC) 、脆弱性管理、ウェブアプリのスキャンなどのその他のコントロール手段を自社コード内のすべてのコンポーネントに対して適用しているか?
ボトムラインは次のようになります。Log4j に簡単な修正策はありません。自明のオプションと考えられやすいウェブアプリのファイヤーウォールの実装も、比較的簡単に回避されてしまうことが実証されています。責任のある企業は、コアソフトウェアを更新する作業を実行することと、この脆弱点が企業全体のリスクプロフィールをどのように影響するかを理解することが必要です。現在、対策を講じている企業は、緊急対応モードで意思決定しています。初期の危機が過ぎ去ったら、それで「使命達成」と宣言して手を引きたくなる誘惑にかられるでしょう。それでは大間違いというのが私共の見解です。セキュリティ第一のアプローチを基盤に自社のインフラの修正とシステムの管理に企業が労力をかける時代は、とうの昔に過ぎ去っています。
SSDL 推進に徹する Tenable では、Log4j 対策として以下を実行しています。
- ブロックゲートの設置による、Log4j その他の脆弱なソフトウェアインスタンスの使用禁止
- 脆弱性管理スキャンとウェブアプリスキャンの積極的かつ継続的な実行。お客様に出荷するリリース前の製品コードを含む、自社インフラ全体にあるすべての資産が対象
- すべての侵害の兆候と攻撃インジケーターに対応。ネットワークとホストレベルの両方でのコントロールの実施
さらに、脅威インテリジェンスを継続して監視して脅威環境を追跡し、必要に応じて対応を調整していきます。最終的に、自社環境内に何があるか把握し、サードパーティも含んだアタックサーフェスを熟知し、そしてリスクを積極的かつ迅速に軽減すること、これらが達成できなければ、どのようなインシデントにも対応することはできません。時間との勝負です。サイバー犯罪の強敵は、最新の脆弱性が発覚するやいなや攻撃できるように準備を整えており、脆弱性をそれぞれのユースケースの用途に合わせて悪用しています。 Lof4j は、今後エンタープライズソフトウェアを何十年にも渡って苦しめる連鎖反応を引き起こす出来事です。企業は、今すぐ、全力を投じて現行の体制を見直す必要があります。
もっと詳しく
- Tenable Log4j ソリューションセンターの詳細はこちらから: https://www.tenable.com/log4j
- SRT アラート: CVE-2021-44228: Apache Log4j における深刻なリモートコード実行の脆弱性の概念実証 (Log4Shell) が公開される
- FAQ : CVE-2021-44228、CVE-2021-45046、CVE-2021-4104: Log4Shell 関連の脆弱性についてよくある質問
- CTO の見解: Apache Log4jにおける非常に深刻な脆弱性を悪用する攻撃が見つかる
- Tenable はさまざまな方法で企業を支援しています。ユーザーコミュニティにアクセスして詳細をご覧ください。https://community.tenable.com/s/
関連記事
- Cloud
- Container security
- Continuous Monitoring
- Incident Response
- Log Analysis
- Threat Intelligence
- Threat Management
- Vulnerability Management
- Vulnerability Scanning