2021 年 12 月 9 日、世界の他の国々が新型コロナウイルス感染症のパンデミックとの戦いを続けている一方で、世界中のコンピューター ネットワークで新たな戦いが始まろうとしていました。これは、これまでに発生した中で最も集中的なサイバーセキュリティ コミュニティの対応の 1 つにつながることになります。

その日、アリババのセキュリティ エンジニアは、Apache Software Foundation (ASF) に、以前に報告した脆弱性が WeChat で議論されていると電子メールで通知しました。Log4j に影響する脆弱性は、世界中の何千ものソフトウェア パッケージのシステム アクティビティに関する情報を収集および管理するために使用される、オープンソースの Java ベースのログ フレームワークです。

WeChat のディスカッションには、概念実証エクスプロイトの編集されたスクリーンショットが含まれていました。セキュリティ エンジニアが 2021 年 11 月 24 日にこの脆弱性を報告していたため、ASF はすでに Log4j の脆弱性への対処に取り組んでいました。しかし、ASF の対応チームとセキュリティ コミュニティ全体が、凶悪な攻撃者が悪用する前に脆弱性を修復するために全力を尽くす必要があることは明らかでした。

ASF は Log4j をアップグレードし、これに一般公開される共通脆弱性および暴露 (CVE) 識別子を割り当てました。同時に、米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ局 (DHS CISA) などの政府機関、企業、セキュリティ専門家は、リスク態勢を評価し、できるだけ早くリスクを軽減するために取り組み始めています。

クラウドソースのセキュリティ プラットフォームである Bugcrowd の CEO、Ashish Gupta もその一人でした。 12 月のその日、脆弱性の全容がまだ明らかになっていましたが、彼と彼のグローバル チームは、直ちに行動を起こす必要があることを認識していました。

「これが大きな問題になることは明らかでした。どこに脆弱性があるのかを顧客が理解できるよう、全力を注ぐ必要があります。」とグプタ氏は電話で説明しました。セキュリティ管理.

Bugcrowd は、自社のセキュリティ エンジニアと研究プラットフォームへのフィードバックを活用して、脆弱性を優先順位付けし、クライアントに情報を提供しました。そして公開から数か月が経過しましたが、その作業はまだ進行中です。

「これはロングテールの脆弱性であり、注視する必要があります」とグプタ氏は言います。 「私たちにはそれに対応するシステムがあり、ファイアウォールがありました。DHS が潜在的な敵対者を出し抜く方法についての考えを提供してくれたことが役に立ちました。かなり大規模で非常に影響力の大きい脆弱性に対処するために、多くの優れた構成要素が用意され、展開されていました。」

被害の評価

今週から出た新しい報告書によると、その初期評価は正しかったということです。2021 年 12 月の Log4j 脆弱性の公開とその既知の影響を取り巻くイベントを分析しました。最初のレビューでは、CSRB は約 80 の組織と個人を参加させて、脆弱性のタイムラインを作成し、その影響を理解しました。

「この記事の執筆時点では、取締役会は重要なインフラストラクチャ システムに対する重大な Log4j ベースの攻撃を認識していません。」と報告書は述べています。 「やや驚くべきことに、委員会はまた、これまで一般的に言えば、脆弱性の重大度を考慮すると、Log4j の悪用は多くの専門家が予測したよりも低いレベルで発生していることも発見しました。」

委員会は分析を通じて、Log4j の開示から 5 日後に Cloudflare が 1 秒あたり 400 件の脆弱性悪用の試行を観察したことを発見しました。 Cisco Talos は、 を観察したことも報告しました。IoT ボットネット MiraiLog4j を悪用しています。チェックポイントの研究者が観察を報告した脆弱性を悪用。および他のサイバーセキュリティ研究者も同様のレベルの活動を報告しました。

委員会は、「地域、業界、またはエコシステムにわたる悪用傾向」を研究し理解するための信頼できる情報源がないため、Log4j エクスプロイトがどのように使用されたかについての結論に達するのは困難であると説明した、と報告書は述べている。 「多くの組織は、特定の Log4j 悪用に関する情報さえ収集しておらず、報告は依然としてほとんどが自主的なものです。」

しかし、委員会のレビューで判明したのは、この脆弱性はほぼすべてのネットワーク組織に影響を及ぼし、それに対処するには迅速な措置が必要であるということでした。今年初めにシスコが議会証言で説明し、Bugcrowd の CEO が証言したように、多くの企業やベンダーは、Log4j が公開された後、どこで使用されたかを特定する調査期間に着手しました。

「ペース、プレッシャー、宣伝が防御の課題を複雑化させた。セキュリティ研究者はすぐに Log4j の追加の脆弱性を発見し、混乱と『パッチ疲れ』を引き起こした。防御側は、善意の研究者による脆弱性スキャンと脅威アクターを区別するのに苦労し、対応者は問題への対処方法に関する信頼できる情報源を見つけるのが難しいと感じた」と報告書は説明している。 「これは、史上最も集中的なサイバーセキュリティ コミュニティの対応の 1 つとして最高潮に達しました。」

たとえば、Gupta 氏は、数千人の Bugcrowd 研究者が、Log4j がネットワークにどのような影響を与えたかについて、数百人の顧客に意見を提供したと述べています。これらは独自の発見である場合もありますが、研究者が同じ資産上で実行されている同じ特定の Log4Shell エクスプロイトを発見している場合もありました。

しかし、Log4j への応答は同等ではありませんでした。 2021 年 12 月以前に Log4j の使用方法を理解し、リスクを管理しインシデントに対応するための技術リソースとプロセスを備えていた組織は、より効果的な行動を取ることができました。しかし理事会は、このカテゴリーに該当する組織はほとんどなく、ほとんどの組織が対応にかなりの時間を費やしていることを意味していると判明しました。

たとえば、委員会は、米国連邦政府のある部門が Log4j の脆弱性への対応に 33,000 時間を費やしたことを発見しました。そうすることは、他のミッションクリティカルな作業が遅れることを意味しました。このハイレベルな緊急対応も貢献しました。サイバーセキュリティ専門家の燃え尽き症候群.

開示に関する懸念

別のブログ投稿で、取締役会メンバー、Luta Security の創設者兼 CEO の Katie Moussouris が次のように述べています。すべての組織にとって、Log4j インシデントから学んだことです。これには、資産インベントリの作成、迅速なアップデートの展開の実践、組織がアップデートのプロセスに精通できるようにベンダーとの関係を構築することが含まれます。 

Log4Shell の脆弱性は、2021 年 11 月 24 日に Alibaba Cloud セキュリティ チームのセキュリティ エンジニアによって中国で最初に発見されました。エンジニアはこの脆弱性を ASF に報告しました。この事件の評価において取締役会は、中国政府が影響を受ける企業に通知する前にまず脆弱性を開示するよう要求する可能性があり、これにより中国が攻撃的優位性を得るのではないかとの懸念を表明した。

「[中華人民共和国]政府の既知の実績を考慮すると、これは憂慮すべき見通しである知的財産の盗難、情報収集、人権活動家と反体制派の監視、および軍事サイバー作戦」と理事会は説明した。

ムスリー氏はブログ投稿で、理事会は意見を提出していないものの、米国政府などが同様の要件を採用する可能性を個人的に懸念していると説明した。

「パッチが利用可能になる前に、修正プログラムの作成を担当する組織のみが脆弱性について知る必要があります」と彼女は書いています。 「脆弱性の調整と公開の際に政府機関を禁輸措置に追加することは、私たちの安全性を有意に強化するものではありませんが、パッチの準備が整う前に漏洩のリスクを大幅かつ劇的に増加させます。また、政府が運営する未パッチの脆弱性の宝庫という、新たな価値の高い目標を生み出すことにもなります。複数のソフトウェア ベンダーの脆弱性を 1 か所に集約すると、そのバグのデータベースが壊れてしまった場合、パンドラの箱イベントが発生するリスクが高まります。侵害されました。”

前進

Log4j の対応から学び、将来のインシデントにさらに備えるために、理事会は 4 つのカテゴリに分類された 19 の推奨事項を作成しました。Log4j の継続的なリスクへの対処、既存のベスト プラクティスの推進安全衛生、より良いソフトウェア エコシステムを構築し、将来に投資します。

「理事会は、コミュニティが次の Log4j タイプのイベントを未然に防ぐための改善を実施すると同時に、現在のリスクに介入して修復するための措置を講じるべきであると指摘している」と報告書には記載されています。 「したがって、私たちの推奨事項は、継続的な警戒の必要性と、サイバーセキュリティのプロセス、フレームワーク、ポリシーを改善するための既存のセキュリティ衛生のベストプラクティスおよび投資の中期的な導入に向けた推進を組み合わせたものです。さらに、最適なレベルの能力と成熟度でエコシステム全体を保護するスケールの変革をもたらすには、新たな投資と斬新なアプローチが必要です。」

たとえば、推奨事項の 1 つは、ソフトウェア開発者が安全なソフトウェア開発のトレーニングを受けることを提案しています。米国連邦政府は、高等教育機関や研修プログラムに投資し関与することで、この取り組みを主導することができるだろう。理事会はまた、大学とコミュニティーカレッジはサイバーセキュリティトレーニングを取り入れ、コンピューターサイエンスプログラミングの学位取得のための安全な開発実践を取り入れるべきだと述べた。

もう 1 つの推奨事項には、重要なサービスに対するオープンソース ソフトウェアのメンテナンス サポートのパイロットを作成することが含まれていました。

「オープンソース開発者は、通常、ソフトウェアの維持費、特にシステム全体に深く広範囲に展開されることが多い古いバージョンの維持費を支払われません」と委員会は書いている。 「Log4j はその特に極端な例でした。オープンソース ソフトウェアを使用する組織にはメンテナンスの負担がかかり、費用も時間もかかり、予測不可能な場合があります。組織はオープンソース ソフトウェアのメンテナンス コストを予測し、信頼できる情報源からその情報を入手できる必要があります。重要なオープンソース ソフトウェアのメンテナンスに資金を提供することで、大規模なセキュリティのより持続可能なモデルを推進し、アップデートと緩和策をタイムリーかつ効果的に配布できるようになります。」

その他の推奨事項は、サイバー安全性報告システムの有効性の調査、ソフトウェア セキュリティ リスク評価センター オブ エクセレンスの確立の実現可能性の検討、安全なソフトウェアの構築に必要なインセンティブ構造の検討など、より前向きなものでした。これらの取り組みにより、サイバーセキュリティ コミュニティは、ネットワーク全体で広く使用されている Log4j やその他のオープンソース ソフトウェアの脆弱性による将来のリスクを軽減できる有利な立場に立つことができます。

「Log4j はシステムに深く埋め込まれたままであり、私たちのレビューに利用できる短い期間内でも、コミュニティの関係者は新たな侵害、新たな脅威アクター、新たな知見を特定しました」と委員会は書いています。 「私たちはこの脆弱性に関連するリスクに対して常に警戒し、このレビューで説明されているベスト プラクティスを適用する必要があります。」

Log4j やその他のオープンソース ソフトウェアの脆弱性がどのように変化するかをコミュニティが確実に理解できるようにするための警戒とスキャンは、私たちが前進する上で重要になる、とグプタ氏は言います。

「戦術、技術、手順は進化します」と彼は付け加えます。 「Log4j を通じて生まれるマルウェア、ワーム、ランサムウェアに警戒する必要があります。」