Tenable の CSO と CIO が語る「次の Log4j」に対応するためのインサイトとベストプラクティス

Tenable の CIO、Patricia Grant と CSO、Robert Huber が、IT・サイバーセキュリティ担当部署が Log4j のような大規模のサイバー危機に備えるために必要な詳しい情報とベスト プラクティスをご紹介します。

1 年前、Log4Shell の脆弱性が発見されたとき、IT とサイバーセキュリティチームは、このどこにでもある Log4j オープンソース コンポーネントの弱点に対する企業のエクスポージャーの評価と対策に奔走されました。

IT、エンジニアリング、サイバーセキュリティの各チームは、すぐに「総力戦」モードに移行し、昼夜を問わず、悪用されやすく非常に深刻な影響をもたらすゼロデイ脆弱性に起因する漏えいの阻止に懸命に取り組みました。

そして、この地球を揺るがす Log4j の脆弱性が判明して 1 年が経った今、この事件は「得られた教訓は何だったか」、「次に Log4j のような脆弱性が発見された際には対応できるのか」といったような重要な問いかけを私たちに投げかけています。

とりわけ Tenable が最近明らかにした現在の Log4j修復の状態に関する調査結果を踏まえると、これらの問いかには慎重に考える必要があります。世界中の 4 万に上る Tenable の顧客からのテレメトリデータの代表的なサンプリングを分析した結果では、2022 年 10 月 1 日の時点で次のことが判明しています。

• 企業の 72% は、Log4Shell に対して脆弱なままである
• 脆弱性があり完全な修復を行った資産でも、そのうち 29% の資産で再度 Log4Shell が発見されていた
• 完全に Log4j を修復できているのは、北米企業はほぼ 3 分の 1 (28%)、ヨーロッパ、中東、アフリカ の企業は 27%、アジア太平洋の企業は 25%、ラテンアメリカの企業は 21%

この記事では、Tenable の CIO であるパトリシア・グラントと CSO のロバート・フーバーが、詳細なプレイブック、チーム間のコラボレーション、資産の可視化が重要である理由など、Log4Shell のような悪影響の大きい脆弱性に対処するための集約した情報、推奨事項、専門知識をご紹介します。

コミュニケーションとコラボレーションはいつも積極的に

Log4j のような脆弱性に対して効果的な対応を行うには、基本的でありながらもとらえどころのない原則を基盤にする必要があります。それは、CIO、CSO、その他のサイバー脅威から会社を保護することに関与するすべての利害関係者の間で、既存の方法で適切かつ継続的なコミュニケーションをすることです。

たとえば、CIO と CSO の重要な連携において、テクノロジーの使用にまつわる安全性とコンプライアンスに関して、事前対応的なポリシーと手順を確立することが重要です。それにより、サイバーリスクの管理と軽減を行うための強固なセキュリティ衛生管理の基盤を構築しやすくなります。その際、ポリシー違反、脆弱性、設定ミス、その他の欠陥の検出と対処は、継続的かつ自動的に行う必要があります。

「CIO と CSO の間でコミュニケーションをとり、状況を把握して迅速な対応を実現するには、進捗状況がわかるダッシュボードで資産を可視化するのが一番です」とグラントは語ります。

コミュニケーションは、CIO と CSO の間だけではなく従業員間でも不可欠です。すべての従業員が会社のセキュリティの重要性を理解して、すべてのポリシーを理解して従うようにする必要があります。あらゆるポリシーには従うべき理由があります。従わない場合、会社全体に悪影響があるためです。

「『何をするのか』だけでなく、『それを行う理由』と、従わなかった場合の悪影響についても伝えることが重要です」と グラントは強調しています。

従業員のセキュリティ意識を高めることで、エンドユーザーのコンプライアンスが向上し、協調的な行動が促進されます。それにより、許可されていない IT 製品の使用といった危険な行動が発生する確率が減少します。Log4j のような高リスクのゼロデイ脆弱性のような場合、このような「シャドー IT」ツールは、企業にとって非常に危険な攻撃手法となります。

資産を完全に可視化

悪影響の大きい脆弱性にうまく対処するために整備しなければならないもう 1 つの基本的な要素は、包括的な資産の可視化です。脆弱性の性質とその深刻度、および侵害を受けた際の悪影響を理解したら、悪影響が出る場所と程度を迅速に判断する必要があります。

それには、IT とサイバーセキュリティの積極的な管理を行い、IT サービス管理 (ITSM)、脆弱性管理 (VM)、エンドポイントの検出と対応 (EDR) ソリューションのデータによって構成される資産データレイクなど、設定管理データベース (CMDB) または類似したリポジトリ内の IT 資産のインベントリを常に最新の状態に維持する必要があります。

「これができていないと、脆弱性が IT 環境のどこにあるのかという問いにすばやく正確に答えることが困難になります」とフーバー。オンプレミス上、クラウド上、リモート上にあるすべてのハードウェアおよびソフトウェア資産とそれらすべてのコンポーネントの詳細も、継続的に最新の状態に保つ必要があります。

レスポンスプレイブックのドラフト

Log4Shell が発生したとき、それが環境内のどこにあるかを検出し、影響を受けた資産に迅速に修正パッチを当てることも含めて、企業は、一刻も早く Log4Shell に対処しなければならない逼迫した状況を経験しました。「実際にどのように対応できたかを顧みれば、将来 Log4j と同等の危機が発生した際に、自社の脆弱性管理プログラムが果たしてうまく機能するのかどうかだいたい判断が付くはずです」とフーバーは指摘します。

以下は、自問すべき 5 つの重要な質問です。

1. 対応するのに十分なスキャナーとインフラが整っているか？
2. スキャンは十分な速度で実行できるか？
3. 修正パッチをすぐに自動的に適用できるか？
4. 事業は、大規模かつ緊急の脆弱性評価と修復キャンペーンに伴う運用上の混乱を乗り切ることができるか？
5. これらすべてをすばやく調整して実行できるか？

Tenable は、影響の大きい脆弱性に社内で対処するためのラピッドリスポンス (RR: 迅速対応) プレイブックを配布しています。このプレイブックには、調査、セキュリティ、IT、運用、法務、マーケティング、製品管理、経営幹部など、さまざまなチームのタスクと責任についての具体的な手順と詳細な説明が記載されています。

「このプレイブックはインシデント対応計画に非常に似ていますが、注目を集めている脆弱性に特化したものです。通常、すべての利害関係者はインシデント対応プロセスをしっかり把握していて内容にも同意しているので、迅速対応に際しても同意を得て適用できるでしょう」とフーバーは述べています。

この RR プレイブックで Tenable が達成したい目標は次のとおりです。

• 脆弱性への迅速な対応と対処
• 関係するチームの協力体制と効果的なコミュニケーション
• 全員が自分の責任と期待されていることを明確に理解すること
• 内外のコミュニケーションが明確で共通

RR プランが実施されると、Tenable は次のステップを行います。

• 戦略的意思決定を管理する RR エグゼクティブ チームを招集
• 関連する各チームの代表者で RR チームを編成
• 達成しなければならない主要な目標と目的を確立
• プレイブックにある行動すべき事項を実行
• 進捗状況を追跡して文書化し、必要に応じて戦略を修正
• インシデントが解除されたら、プランを完了して通常の運用に戻る

顧客やパートナーからの問い合わせに迅速に対応できるように準備

脆弱性への対処に奔走している時には、自分の企業が影響を受けているかどうか、ソフトウェアに修正パッチを適用する必要があるかどうか、などとといった顧客やパートナーからの問い合わせが殺到します。現在、ソフトウェア サプライ チェーンのリスクに対する意識が高まっているためです。

したがって、問い合わせに対する回答をあらかじめ準備しておく必要がありますが、これには困難を伴います。グラントとフーバーは次のことを推奨しています。

• まだ回答を用意していない場合は、すべてのソフトウェアの詳細なソフトウェア部品表 (SBOM) を作成して、これらの製品に含まれるすべての「構成要素」を把握できるようにする

• 動的および静的なアプリケーション セキュリティ テスト、サードパーティの依存関係またはソフトウェア構成の分析、 脆弱性管理、コンテナのセキュリティを確認するためのツールを使用して、ソフトウェア開発ライフサイクルの早い段階でセキュリティチェックとテストを組み込む。これにより、顧客にリリースするソフトウェアの信頼性が向上し、保証が改善されます

サプライヤーのセキュリティ体制を注意深く監視

一方、すべての IT プロバイダーのサイバーセキュリティの準備と実践状況を評価するための厳格なプロセスを用意し、それらサードパーティ ベンダーのリスクも管理する必要があります。それにより、ソフトウェア ベンダーやマネージド サービス プロバイダーの不注意によって発生する侵害のリスクを防止できます。

「ベンダーサプライチェーン全体の安全性は、その最も弱い部分で決まります」とグラントはコメントしています。

「発生するのかどうか」ではなく「いつ発生するのか」

結論として、Log4j 規模の危機の問題というのは、IT とサイバーセキュリティのリーダーが再び「直面するのかどうか」ではなく、「いつ直面するのか」を理解する必要があります。この記事で説明しているような対策は、企業が将来の脆弱性に対する「総力戦」に首尾よく対応できる立ち位置を確立するのに大いに役立つはずです。

「この特定のシナリオを使って机上でシミュレーションを行い、動きに慣れ、問題のある場所の特定とその改善を行うようにしてください」とフーバーは結んでいます。

Log4j の詳細については、Tenable Log4j リソースページをご覧ください。リソースページには、FAQ、ホワイト ペーパー、ブログ、プラグイン、方法に関するビデオ、オンデマンド ウェビナーなどへのリンクがあります。