ここでいう「ゼロデイ」とは
この解説では GTIG の報告書に沿い、パッチが一般公開される前の悪用を扱います。NIST は、それまで未知だった脆弱性を重視しています。どちらも、世界中の誰一人その不具合を知らないという意味ではありません。 [1] [2]
更新前と、修正が有効になった後
模式的なアプリケーションであり、顧客事例ではありません。考えられる一つの流れを示すもので、未知の脆弱性をすべて検出できるという意味ではありません。
ゼロデイ攻撃では、修正が公開される前に脆弱性が悪用されます。
更新より先に攻撃が届く
リクエストが脆弱性のある機能に到達します。この時点では、対応する更新はまだ提供されていません。
修正を稼働させ、効果を確認
新しい版が実際に稼働しています。対象機能を絞った検証で、修正の効果を確認します。
図は一つの攻撃経路を示しています。過去の攻撃や別の経路は、個別に調査する必要があります。
更新のインストールだけでは足りない理由
不具合はすでに存在する
アプリケーションは通常の処理を続けていますが、ある機能にはセキュリティ上の不具合が存在します。警告が出ていないことは、その機能に脆弱性がない証明にはなりません。
到達できる経路
特別なリクエストが影響を受ける機能に到達します。図のアクセスを制限すると、この経路はアクセス制御で止まります。アプリケーション内の不具合は残り、別の経路は未確認のままです。
判明と修正は別の状態
この例では、まず開発元へ通知され、その後に修正パッケージが公開されます。開発元が知っていることと、更新を利用できることは別です。告知だけで、すべての環境が影響を受けるとは判断できません。
パッケージとプロセスは違う
パッケージを導入しても、この例の実行中インスタンスは当初、古いコードを使い続けます。別途有効化して初めて新しい版が稼働します。製品によって必要な操作は異なります。
修正の具体的な効果を確かめる
実際の稼働バージョンと影響を受ける機能を確認します。証拠が示すのはこの状態とこの検証の結果であり、あらゆる攻撃への安全保証ではありません。先ほどの攻撃が成功していた場合、インシデント調査は別途必要な未完了の作業です。
警戒を解除する前の三つの問い
- 影響を受ける版と機能を実際に使用していますか。どの経路から到達できますか。
- 導入されたパッケージは何ですか。各インスタンスが実際に使っている版は何ですか。
- 何を確認すれば修正を裏付けられますか。足りない証拠や、別途調べるべきインシデントの可能性はありませんか。
告知を、範囲の明確な確認作業へ
警告は調査を始めるきっかけです。対象システム、機能、許可された試験経路を定め、初期状態を記録します。暫定措置と恒久的な修正は分けて扱います。
NIST のパッチ管理には優先順位付け、導入、検証が含まれます。この図はその区別を説明する例であり、すべての製品に使える導入手順ではありません。
外部セキュリティ分析は、公開システムと設定上の問題の把握に役立ちます。特定機能と悪用可能性の確認には、合意した適切な侵入テスト範囲が必要です。すべてのゼロデイの発見を約束するものではありません。 [3]