Log4j インシデントに暴露されたサイバー・セキュリティの駄目なところ

Log4j Reveals Cybersecurity’s Dirty Little Secret

2021/12/23 DarkReading — 技術系メディアが、インターネットが炎上していると報じ始めたら、重大な事態に陥っていることを意味する。Log4Shell と呼ばれる Log4j の脆弱性は、時間の経過と伴に、その深刻さが判明し、範囲と影響が拡大する一方である。米国の Cybersecurity and Infrastructure Security Agency (CISA) や英国の機関などが、直ちに対策を講じることを推奨しており、また、現代のハイテク業界の有名企業たちは、この数年で最も深刻なゼロデイ脅威に対して、深刻な脆弱性を抱えていることが判明している。

下流域にいるユーザー企業では、何百万ものデバイスやネットワークが致命的なリスクにさらされており、修正プログラムがリリースされると同時に、攻撃者はログ・ライブラリの脆弱性を利用するための、新たな難読化手法を編み出している。別の言い方をすれば、「最悪」ということだ。本当に酷い状況だ。

12月9日にセキュリティ研究者たちは、多数のインターネット・アプリケーションにおいて、特にユビキタスな企業システムで広く使用されている、Java ロギング・ライブラリである Log4j に存在するリモートコード実行の脆弱性 CVE-2021-44228 の PoC エクスプロイトを公開した。

その直後から、あらゆる組織が、ビジネスや接続性を推進する膨大な数のツールやサービスにおける悪用を特定し、早急な緩和へ向けて動き出した。今回の事態は、広く採用されているロギング・ソフトウェアの、基本的な部分の弱点を突いているため、この脆弱性が隠れている範囲を把握することはほとんど不可能だ。

その一方で、セキュリティ研究チームや脅威情報チームは、企業のリスク評価に役立つ情報／パッチ／リソース／ガイドなどのリリースに躍起になっている。それと同時に、複数の悪意のキャンペーンが登場し、脆弱なシステムに対して Log4Shell を悪用し、暗号解読機からトロイの木馬のバックドアにいたるまで、さまざまなマルウェアを展開し始めている。このような危機が明らかになって、まだ数日しか経っていないが、脅威アクターたちは素早く適応している。

私たちは過去の悪用から学び、次の悪用に備えているか？

WannaCry や SolarWinds のような過去の攻撃と余震があり、それらの名前がサイバー・セキュリティの失敗例として記憶されていくが、どこかでは、このような混乱を防ぐために何ができるかという会話が交わされているはずだ。多くの企業は、このような事態に対する準備ができず、自社のテクノロジー・スタックの中に、何があるのか分からない状況にある。影響を受けるシステムにパッチを適用することは、脅威を軽減するための手段だが、IT チームがネットワーク内の状況を完全に把握していなければ、迅速で的確な行動を取ることは不可能に近いだろう。

今回のような、大規模で迅速な攻撃は、ソフトウェア資産管理の重要性を明らかにしている。Log4j の脆弱性が発覚した直に後、世界中の CISO たちは自社のチームに対して、どのような危機にさらされているのか、と問いかけた。セキュリティ・チームがデバイスとソフトウェアの正確なカタログを持っていなければ、この質問に完全に答えることはできない。それは難しく、セキュリティ運用のフレームワークの中でも忘れられがちな要素だが、今回の Log4j の深刻な事態は、パッチを必要な場所に迅速に適用するための、全体像を把握することの重要性を示している。

もう一つの大きな問題は、中堅／中小企業やリソースに制約のある IT セキュリティ・チームへのトリクルダウンの影響だ。大手ハイテク企業は、当然のことながら、この脆弱性にいち早く対応し、専門家／研究者／開発者による艦隊を配備して、膨大な数のツール／サービスのアップデートを特定し、連鎖的に適用している。しかし、平均的な中小企業の IT リーダーは、数多くの責任を負っているため、パッチを当てるべきツールの数と、必要なパッチの数を掛け合わせることに苦労するだろう。

つまり、ここには汚い小さな秘密がある。ひとたび Log4j の問題が解決すると、多くの IT チームは他の問題で構成される長い業務リストに戻り、資産やアプリケーションの管理という、基本的であっても刺激的ではない作業を、再び脇へと追いやるだろう。彼らは、今回のサイクルで攻撃を避けることができれば成功だと考えるだろうが、次回に備えた適切な準備のために、隅々にまで目を向けることはないだろう。また、膨大な量のツール／アラート／パッチに圧倒され続け、警戒と保護を維持するために必要な、時間とリソースの確保に遅れをとることになる。このような悪循環は、何度も経験してきたことだが、このような状況に陥るべきでなはない。私たちは、もっと要求することができるし、そうすべきなのだ。

なにができるのか？

もっと良い方法がある。この機会に、需要なシステムに関わるサードパーティのテクノロジー・ベンダーを明確に評価し、カタログ化することだ。不正な技術を特定／排除し、ベンダーに対しては、顧客を守るための責任を負わせる。結局のところ、信頼できるベンダーの数が少ない方が、膨大で漠然としたツールやサービスが、一元管理されていない状況にあるより良いのだ。

今回の事態を機に、積極的にコミュニケーションをとるベンダーと、そうではないベンダーを、見極める必要があると考えている。テック・プロバイダーは最新情報や洞察を提供しているだろうか？彼らは、セキュリティ対策に自信を持っているだろうか？ これまでの経験と検証により、今後の信頼性を強化していける。

最後になるが、優れたインシデント対応計画とプレイブック (外部パートナーとの関わり方を含む) は、時間をかけて運用することで強化される。何がうまく機能し、何を改善する必要があるかを、早い段階から頻繁に記録すべきだ。そして、そのメッセージが、組織全体で理解されていることを確認してほしい。

より良い方向性

サイバー・セキュリティは、世界をつなぐソフトウェア・メーカーやサービス・プロバイダーの幅広いネットワークの間で警戒心を共有し、コミュニケーションを取りながら、信頼を必要とするチームスポーツである。しかし、ゲームの進め方には根本的な欠陥がある。そのため、ノイズが多く、混乱が多く、ツールが多すぎて、仕事を遂行するためのリソースが不足している。

Log4j は、このように小さな基本的なコードであっても、その脆弱性により、解明には何年もかかる連鎖的な影響が生じることを証明した。つまり、テクノロジーが悪用された場合に、きわめて脆弱であるという事実を改めて痛感させるものだ。しかし、組織や IT リーダーたちが、この状況を利用して、長年悩ませてきた問題に取り組むことができれば、サイバー・セキュリティへのアプローチを改善できるだろ。私たちは、脅威アクターに対して優位性を取り戻し、非常に不公平な戦いの、連鎖を断ち切ることができるのだ。

ソフトウェア資産管理の重要性と言われても、なかなか手がつけられないというケースが大半なのでしょう。Log4j のように、エンタープライズ・システムの随所に遍在しているソフトウェアの、それぞれが機能している場所を特定するには、なんらかのソフトウェア資産管理が必要です。以前に、「アプリケーションに含まれる Third-Party ライブラリの 79% が更新されていない？」という記事をポストしていますが、今回の Log4j と合わせて考え、来るべきものが来たと捉えるべきなのでしょう。そして、繰り返さないための、議論が活性化していくキッカケになるのだろうと期待します。