明日のゼロデイ脆弱性に今日から備える方法

ゼロデイ脆弱性への対処方法

ソフトウェアセキュリティの世界では、状況が一夜にして変わることがあります。ある日、アプリケーションやシステムがクラウド上で安全に稼働していても、翌日には新たな悪用可能な脆弱性がニュースになり、環境全体から脆弱なコンポーネントを見つけて修正するため、時間との競争が始まります。

ゼロデイ脆弱性とは、新たに発見されたセキュリティ上の問題です。「当面は使用を中止する」以外に修正策がない場合も多く、セキュリティチームを大きく混乱させます。幸い、組織はゼロデイ脆弱性が発生する（または発見される）前から、事前に備えることができます。

ゼロデイ脆弱性がリスクとなる理由

現在のアプリケーションの多くは、膨大な依存関係や外部リソースのネットワークで構成されています。1つのアプリケーションに、数十ものオープンソースコンポーネントやサードパーティ製ソフトウェアが含まれることもあります。ゼロデイ脆弱性が一般に知られると、脆弱なコンポーネントを使用する組織は、できるだけ早くそれを特定して修正しなければなりません。時間内に修正できなければ、ゼロデイ攻撃の被害に遭うおそれがあります。

ゼロデイエクスプロイトによる影響とは？

ゼロデイエクスプロイトが成功すると、金銭的損失から評判の失墜まで、組織に深刻な影響を及ぼす可能性があります。攻撃者はこうした脆弱性を利用して、リモートでコードを実行したり、機密データを盗み出したり、重要な業務を妨害したりできます。ゼロデイ脆弱性は発見されるまで未知であるため、ファイアウォールやウイルス対策ソフトウェアなどの従来のセキュリティ対策では、悪用を防げないことが少なくありません。そのため、攻撃の影響を最小限に抑えるには、迅速な検知、緩和、パッチ適用が欠かせません。

ゼロデイ脆弱性のライフサイクル

ゼロデイ脆弱性は発生のスピードが速く、ライフサイクルも誰が発見するかによって大きく異なるため、特にリスクが高くなります。就寝時には知られていなかった脆弱性が、翌朝にはニュースやフォーラムを賑わせていることもあります。以下は、オープンソースライブラリにおける典型的なゼロデイ脆弱性の想定タイムラインです（自社開発アプリケーションでも同様の流れになることがあります）。

• 開発者がオープンソースライブラリを選択。更新されたコードと新しいライブラリが本番環境にリリースされる。

• 脆弱性の発見。その後数日、数か月、あるいは数年のうちに、セキュリティ研究者（理想的なケース）または悪意ある攻撃者（最悪のケース）が脆弱性を発見します。攻撃者は脆弱性の悪用を始め、セキュリティ研究者は悪用の可能性を調査し始めます。

• 脆弱性の認知。メンテナーは脆弱性を把握しますが、まだ修正策はありません。

• 脆弱性の公表。脆弱なライブラリのメンテナーまたは脆弱性を特定したセキュリティ研究者が、影響を受ける顧客または一般に向けて脆弱性の情報を公開します。

• ゼロデイ脆弱性へのパッチ適用。ベンダーが修正策をリリースします。多くの場合、ポイントリリースとして提供されます（脆弱性が複数のリリースにまたがって存在していた場合、複数回にわたることもあります）。完全な修正がリリースされるまでの時間は、複雑さに応じて数時間から数か月までさまざまです。

• 顧客による修正の適用。最後に、影響を受ける顧客がパッチを適用します。脆弱なコンポーネントのすべての使用箇所を特定して修正を適用するまでにかかる時間によって、このプロセスは数か月、あるいは数年かかることもあります。

• 攻撃の継続。パッチのリリース後も、攻撃者は野放しの未修正システムを見つけようと、脆弱性の悪用を試み続けます。そのため、組織はビルドとデプロイのプロセスに定期的なセキュリティスキャンを必ず組み込む必要があります。

この間には多くの段階があり、関係するチームがベストプラクティスに沿ったセキュリティ情報開示ポリシーに従うかどうかによって、脆弱性の影響は大きく変わります。

ゼロデイ脆弱性への計画的な備えに役立つ6つのヒント

ゼロデイ脆弱性は頻繁に発生し、毎年、何千もの組織が対応に追われています。2022年には、Googleが確認した実際に悪用されたゼロデイ脆弱性は41件に上りました。つまり、組織がゼロデイ脆弱性に直面するかどうかではなく、いつ直面するかが問題なのです。

こうした脆弱性は頻繁に発生するため、組織は事前に備えておく必要があります。緊急事態が起きていないときに企業が準備を進めておけば、ゼロデイ脅威が発生した際にすぐ対応し、解決に取り組めます。具体的な対策は次のとおりです。

1. 開発においてセキュリティを最優先する。

セキュリティを最優先するとは、開発者が脆弱性の発生に応じて、SDLC全体を通じて修正することです。セキュリティ上の問題が発生した時点で対処するほうが、問題が下流工程へと持ち越され、長いリストになるまで何日も何週間も待ってから修正するより、はるかに効率的です。

セキュリティを最優先する姿勢は、開発者を困らせるのではなく、セキュリティチームとの協力を促します。このような連携は、より強固なDevSecOps文化につながります。開発チームとセキュリティチームが日頃から協力し合っていれば、ゼロデイ脆弱性が発生した際も、より効果的に問題を解決できます。

2. 強固なセキュリティプロセスを整備する。

強固でシフトレフトを重視したアプリケーションセキュリティプロセスでは、大きなマイルストーンの終わりまでテストを待つのではなく、SDLC全体を通じて脆弱性の発見と修正に取り組みます。たとえば、開発者がプルリクエストを作成するたびに、自社開発コードに対して静的アプリケーションセキュリティテスト（SAST）を実施する組織もあります。

こうしたプロセスでは、ソフトウェア構成分析（SCA）でサードパーティの依存関係をすべて特定し、ソフトウェア部品表（SBOM）で詳細に記録することも重要です。今日の開発プロセスは非常に速いため、多くの組織が自動化ツールを活用して、依存関係をリアルタイムで継続的に追跡しています。

組織が日常的に強固なセキュリティプロセスを活用していれば、ゼロデイ脆弱性によって侵害されたサードパーティリソースを使うプロジェクトをはるかに簡単に特定し、迅速に修正できます。

3. 定期的にセキュリティ評価と監査を行う。

組織がセキュリティ評価と監査を定期的に行うことも重要です。評価の具体的な内容は業界やビジネスニーズによって異なりますが、多くの場合、次の5つの段階のいずれかを実施します。

• 潜在的な脅威の特定

• 環境内の機密データの特定

• 攻撃対象領域のマッピング

• プロセス上の課題の評価

• プロセス改善のロードマップの策定

こうした手順を定期的に実施することで、組織はセキュリティプログラムを最適な状態に保つことができます。評価は、現在のセキュリティ態勢を深く理解するうえでも役立ちます。この知識と準備があれば、ゼロデイエクスプロイトの防止がはるかに容易になります。

4. 従業員の意識向上を促す。

従業員の意識向上も、ゼロデイ脆弱性の防止に役立ちます。効果的なトレーニングプログラムでは、開発者が安全なコーディング手法をインタラクティブかつ興味を持てる形で学べます。開発チームの教育に効果的な方法の1つは、脆弱性スキャンと併せて修正ガイダンスを提供することです。たとえば、一部のスキャナーは、各脆弱性がなぜリスクとなるのか、どう修正すればよいのかを説明します。

実践的なセキュリティ教育を通じて、開発者は自身のコードと潜在的なセキュリティリスクへの理解を深めることができます。その結果、ゼロデイ脆弱性が発生した際も、より効率的に解決できるようになります。

5. 独自のプレイブックを作成する。

次のゼロデイ脆弱性が発生するまで、対応手順の文書化を待つ必要はありません。次の脆弱性への対処方法について、プレイブックやチェックリストを作成しましょう。関係者、影響の評価方法、調査が必要なインベントリ、社内（必要に応じて社外）への調査結果と影響の伝え方などを含めます。特に重要なのは、プレイブックの保管場所を全員が把握していることです。次の重大な脆弱性が発生する前に、ソースコードとコンテナのインベントリを追跡するツールを導入し、備えを強化しましょう。

6. 最新のセキュリティ情報を常に把握する。

新たなゼロデイ脆弱性の情報を常に把握するために、組織は情報源も決めておく必要があります。ゼロデイ脆弱性がニュースになったときは時間が勝負です。チームが事前に準備しておけば、修正に注力すべき箇所をすばやく把握できます。

Snyk Vulnerability Database（VulnDB）を基盤とするSnykは、進行中の脆弱性に関する詳細情報を提供し、その解決方法も、多くの場合クリック1つで提示します。脆弱性の修正に必要な情報をチームが早く入手できるほど、緩和やパッチ適用も迅速に進められます。

また、VulnDBに直接アクセスすれば、話題の最新脆弱性を確認できます。

最近のゼロデイ攻撃

最近のゼロデイエクスプロイトとして、まず思い浮かぶ重大な事例はLog4Shellです。Javaアプリケーションに影響するLog4jのリモートコード実行脆弱性で、CVSS評価は最高スコアの10でした。多くの企業が環境全体でLog4jを使用しており、間接的な依存関係を通じて利用している場合も多かったため、ほとんどの大手企業が影響を受けました。

最近の事例には、ほかにも次のようなものがあります。

• CVE-2023-44487：深刻度の高いHTTP/2 Rapid Resetのゼロデイ脆弱性。

• CVE-2023-38545：cURLにおける、深刻度の高いヒープベースのバッファオーバーフロー。

• CVE-2023-4863：攻撃者が悪意を持って細工されたWebP画像を使ってGoogle Chromeを悪用できる重大な脆弱性。

• CVE-2022-3602 and CVE-2022-3786：バッファオーバーランに関連する、OpenSSLの深刻度の高い2つの脆弱性。

• CVE-2022-42889：Apache Commons Textで任意のコード実行を可能にする、深刻度の高い脆弱性。

• Spring4Shell：Spring Frameworkにおける、重大なJavaのリモートコード実行（RCE）脆弱性。

上記の深刻度「高」または「重大」の脆弱性をはじめ、多くの脆弱性が24か月の間に発生しており、大きな欠陥がいかに頻繁に明らかになるかを示しています。つまり、セキュリティチームが無視できる問題ではありません。

SnykのAppSecツールでゼロデイ脆弱性を発見・修正

適切なツールがあれば、チームは協力しながら効率的にゼロデイ脆弱性へ対応できます。Snyk Code、Snyk Open Source、Snyk Containerなどのアプリケーションセキュリティソリューションを活用すれば、開発チームとセキュリティチームはゼロデイ脆弱性が発見され次第、すぐに特定して修正できます。また、Snyk Insightsは、組織にとって重要なリスクに注力し、優先順位を付けるのに役立ちます。

さらに、業界をリードするセキュリティインテリジェンスで、最新のゼロデイ脆弱性やその他の脅威を常に把握し、その情報を活用して当社のソリューションを強化しています。

SDLC全体を通じてセキュリティ上の問題を修正し、次のゼロデイ脆弱性の被害を防ぐ開発者を第一に考えたAppSecソリューションについて、詳しくご覧ください。