企業は詳細な推奨事項に従い、既存のパッチを適用し、log4j に即座に対応してベスト プラクティスを適用できます。 しかし、第 XNUMX ステップでは、ソフトウェア サプライ チェーンに関連するプロセスを全般的に検討する必要があります。
結局のところ、ギャップがどれほどセキュリティに関連しているとしても、Log4Shell でさえ、ソフトウェア サプライ チェーンの欠陥のあるコンポーネント「にすぎません」と、トレンドマイクロの IoT セキュリティ エバンジェリスト ヨーロッパのウド シュナイダー氏は述べています。
Log4Shell - ソフトウェア サプライ チェーンを知っていますか?
もちろん、Log4Shell の脆弱性によってもたらされる重大な脅威には、即時の対応が必要です。 しかし、第 XNUMX ステップでは、企業は通常、ソフトウェア サプライ チェーンに関連するプロセスや文書化された (?) 依存関係について自問する必要があります。
数日前に知られた Log4Shell の脆弱性は誰もが知っており、世界中のセキュリティ専門家が警戒を続けています。 BSI は、脆弱な Log4J ライブラリが Java 環境におけるいわば「」ログ標準であるため、「極めて重大な脅威状況」について述べています。 したがって、何千ものアプリケーションやインターネット サービスでも使用されています。 さらに、この脆弱性は悪用されやすく、多くの場合リモートで悪用され、最終的には任意のコマンドの実行が可能になります。 サイバーセキュリティの観点から見るとまさに悪夢です。 組織は、当社の詳細な推奨事項に従い、既存のパッチを適用し、即時に対応するためのベスト プラクティスを適用できます。 しかし、第 4 ステップでは、ソフトウェア サプライ チェーンに関連するプロセスを全般的に検討する必要があります。 結局のところ、LogXNUMXShell でさえ、その脆弱性がどれほどセキュリティに関連していても、ソフトウェア サプライ チェーンにおける欠陥コンポーネント「にすぎない」のです。
Log4Shell で欠陥のあるビルディング ブロックを削除する
ソフトウェアのサプライチェーンとその背景を理解するには、電子製品の製造などの「現実の」世界に目を向けることが役立ちます。 アセンブリのいわゆる「部品表」（BOM – Bill of Materials）は一般的です。 単一の回路基板をアセンブリとして見る場合、適切な部品リストには、抵抗、コンデンサ、ダイオード、IC など、使用されるすべてのコンポーネントのリストが含まれています。 正確なパラメータ、メーカー、価格、供給源、そして最終的にはシリアル番号または少なくともバッチ情報も各コンポーネントに保存されます。
コンポーネントの製造元から、バッチの特定のコンポーネントが指定された温度値に対応していないという情報がある場合、どのボード (それぞれ独自のシリアル番号を持つ) が a) 影響を受けているか、b) 影響を受けているかを正確に追跡することができます。 ）アクションの必要性があるかどうか。 適切な措置を開始する必要がある場合、どのアセンブリが影響を受けるかに関する情報 (シリアル番号に基づく) は、当然ながら非常に役立ちます。 最終的に、この手順はほぼ意のままに「アセンブリ」を続けていき、最終的には CERN の LHC のような大規模な施設が完成するまで続きます。 このような大型のマシンであっても、小さな SMD コンポーネントの故障がマシン全体の故障を引き起こす可能性があります。 たとえば、欠陥のあるバッチが判明した場合、最終的には取り付けられている個々の抵抗器を検証できる必要があります。
ソフトウェア部品表 (SBOM)
これはまさにソフトウェア サプライ チェーン、つまり SBOM の仕組みです。」 そして特に Log4Shell に戻ります。このギャップの影響を受けているかどうか、すぐに言えますか? Log4J を使用する独自のソフトウェアを使用すれば、おそらくこの質問にすぐに答えることができます。 多くの場合、GitHub や GitLab などの SCM サービスでも、そのような機能を直接提供しています。 しかし、一時的な依存関係についてはどうでしょうか? 使用しているサードパーティ ライブラリは内部で Log4J を使用していますか? あるいはさらに悪いことに、あなたが使用しているライブラリは、Log4J を使用するライブラリに依存するライブラリを使用していますか? サービス プロバイダーが購入したソフトウェアは Log4J に依存していますか? 購入したクラウド サービスは Log4J を使用していますか?
SBOM コンテンツ (画像: トレンドマイクロ)。
SBOM に取り組む必要がある、答えが必要な質問に次ぐ質問。 Log4Shell は、ソフトウェア サプライ チェーンが文書化されていない場合に発生する問題を明確に示します。 しかし騙されないでください。 Log4Shell は確かに現時点では最悪のシナリオです。 しかし、安全に直接関係のない単純な「欠陥」であっても、影響を受けるかどうかという問題は重要です。
ドキュメントの依存関係
基本的に、SBOM は依存関係を文書化することを目的としています。 これらは、ソフトウェア (コンポーネント) の形での依存関係である場合もありますが、サービス、ライセンス、サーバーなどの形式の依存関係である場合もあります。 特にソフトウェアの依存関係のモデリングに関しては、時間の経過とともに、CycloneDX と SPDX という XNUMX つの交換フォーマットが登場しました。 どちらも、可能性のある依存関係を含むさまざまなソフトウェア コンポーネントを記述できます。
しかし、説明的な言葉だけでは十分ではありません。 むしろ、特定の環境についても説明し、最新の状態に保つ必要があります。 もちろん、これらの説明は手動で作成できます。また、外部サービスに依存する場合など、他に選択肢がない場合もあります。 しかし、ソフトウェアの説明を作成する場合、手作業では意味がありません。 ここで、これらの記述の作成と保守は、CI/CD パイプラインの一部として完全に自動的に行われる必要があります。 基本的に、ビルド プロセスへの統合とビルド アーティファクトのスキャンという XNUMX つのアプローチがあります。
CI/CD 統合 – ビルドプロセス
ビルドプロセス中の SBOM の作成 (画像: トレンドマイクロ)。
CycloneDX と SPDX の両方には、ビルド プロセスに直接統合できるツールがあります。 これらは、「ソースで」(一時的な) 依存関係を直接抽出します。 これらは、ライブラリ、実行可能ファイルだけでなく、コンテナまたはコンテナ レイヤーの場合もあります。 直接統合により、たとえば、完成品には存在せず、ビルド中のみに存在する依存関係を追跡することも可能になります。
CI/CD 統合 – ビルドアーティファクト
ビルド プロセスに直接介入することが許可されていない場合でも、CycloneDX および SPDX には最終結果を「後から」スキャンするツールがあります。 つまり、これらのツールは、たとえば Java アプリケーションから依存関係を抽出し、文書化します。 これらのツールは常に完成結果のみを確認するため、最終結果から依存関係を推測することができなくなり、一部の依存関係が単純に見落とされる可能性が十分にあります。
脆弱性の監視
ビルドプロセス後の SBOM 作成 (画像: トレンドマイクロ)。
脆弱性の監視のみに関心がある企業の場合、これらのツールの多くは脆弱性データベースとの直接の関連付けも提供します。 これは、出力には、見つかったコンポーネントだけでなく、脆弱性のリストも含まれることを意味します。 これは、たとえば、snyk、Trend Micro Application Security、または Trend Micro Container Security を CI/CD パイプラインに統合することに相当します。
OWASP 依存関係トラック
ライセンス、在庫、配布の程度の追跡と文書化にも役割がある場合は、（追加で）他のソリューションも利用できます。 この環境では、OWASP (Open Web Application Security Project) の依存関係追跡ツールが有力なツールの XNUMX つであることは間違いありません。 オープンソース ソリューションとして、通常は CI/CD パイプラインに統合され、CycloneDX/SPDX データ (マニュアル、API) 経由、またはビルド プロセスから直接、そこで SBOM データを受け取ります。 さらに、Dependency Track は、さまざまな脆弱性データベースからの脆弱性データを自動的に保存し、(履歴) ビルドと脆弱性からのデータを継続的に関連付けます。 一致した内容は、それに応じてダッシュボードに表示されるか、チャットおよび CI/CD 統合を介して直接報告されるか、またはオプションで自動修正のためにツールに転送されます。
依存関係追跡の統合 (画像: https://github.com/DependencyTrack/dependency-track )
依存関係追跡は、「Log4Shell の影響を受ける場所」という質問に簡単に答えることができるデータベースです。 この回答には、ソフトウェアの現在のバージョンだけでなく、古いバージョンの説明も含まれています。 したがって、（パッチが十分に適用されているため）現在のバージョンでは企業が影響を受けていないが、34 の古いバージョンが影響を受けていることが判明する可能性があります。 インストールされているバージョンの数に関する情報も追跡すると、これは十分に根拠のあるリスク評価にとってほぼ完璧なデータとなります。
Log4j、Log4Shell、およびサプライチェーンに関する結論
最後に、最初に提示された質問に答えられることが重要です。「私たちは (直接またはソフトウェア サプライ チェーンで) Log4J を使用していますか?」 もしそうなら、どの程度 (バージョン、ディストリビューション) Log4Shell の影響を受けますか? この質問に答えるのに必要な労力は、ソフトウェア サプライ チェーンをどの程度洞察しているのか、そしてそこを支援するツールを使用する価値があるかどうかを示す指標となります。
ツールに関しては、「影響を受けるかどうか」という質問「だけ」であるかどうかを明確にすることが重要です。 この場合、snyk などのツールや、GitHub や GitLab に統合されたオプションが役立ちます。 一方、より包括的なビューが必要な場合は、ソフトウェア アーティファクトをキャプチャしてカタログ化するための他のソリューションがあります。 これらは商用と無料の両方です。 オープン ソース キャンプの中で、Dependency Track がここで最も広く普及していることは間違いありません。
ただし、最終的には、セキュリティのギャップはソフトウェア サプライ チェーン管理の重要な議論であるが、それだけではないことに注意する必要があります。
詳しくは TrendMicro.com をご覧ください
トレンドマイクロについて トレンド マイクロは、IT セキュリティの世界有数のプロバイダーとして、デジタル データ交換のための安全な世界の構築を支援しています。 30 年以上にわたるセキュリティの専門知識、グローバルな脅威研究、および絶え間ない革新により、トレンドマイクロは企業、政府機関、および消費者に保護を提供します。 当社の XGen™ セキュリティ戦略のおかげで、当社のソリューションは、最先端の環境向けに最適化された防御技術の世代を超えた組み合わせの恩恵を受けています。 ネットワーク化された脅威情報により、より優れた迅速な保護が可能になります。 クラウド ワークロード、エンドポイント、電子メール、IIoT、およびネットワーク向けに最適化された当社のコネクテッド ソリューションは、企業全体にわたって一元化された可視性を提供し、より迅速な脅威の検出と対応を実現します。