修正が出ても被害は続く？「ゼロデイ」と「N-day」の違いと対処法

セキュリティの注意喚起には、「ゼロデイ」「N-day」という言葉が出てくる。これらは脆弱性が知られた時点や修正の状況を表す言葉だが、資料によって区切り方が異なる。　php2shell で国内のどのサービスが、いつ止まり、いつ戻ったかは、php2shell サービス停止まとめで確認できる。

修正が公開された後も、未更新のシステムは攻撃されるおそれがある。 開発・運用担当者は、発見、公表、修正の提供、自社での適用を分けて確認し、対応の優先順位を決めたい。

「ゼロデイ」とは？

ゼロデイは、製品の開発者がまだ把握していない脆弱性を指す。

脅威の調査では、修正が公開される前に悪用されたかを基準にする場合もある。Googleの脅威調査は、この基準でゼロデイの件数を集計している。

「N-day」とは？

N-dayは、情報が公表されている脆弱性や、それを利用する攻撃を指す。

Chromeの公式解説では、公開ソースコードに修正が加わってから利用者向けの更新が届くまでの間の攻撃も、N-dayに含めている。脆弱性の情報が公表されても、自社で使う製品の更新はまだ届いていない場合がある。

公表や修正の公開後も、未更新の環境にはN-dayの悪用リスクが残る。こうした被害を防ぐ対応の例が、PHPの脆弱性に伴う緊急メンテナンスだ。BASEは重大なPHPの脆弱性に対応するため、サービスを一時停止し、安全確保のためのメンテナンスを実施した。

対策時の考え方の違い

ゼロデイとN-dayでは、利用できる情報に差がある。公表状況と修正の提供状況に合わせて、対処を選ぶ。

修正内容の公開、利用製品向けの更新の提供、自社での適用は別の時点だ。対応の完了は、実際に動く環境へ修正が適用されたかで確認する。

確認の優先順位

CISAが公開する悪用済み脆弱性の一覧「KEV」や製品の公式勧告を使い、次の順に対処を進める。

1. 自社への影響を調べる。 利用製品、バージョン、設定を公式勧告と照合する。
2. 実際の悪用情報と公開範囲を確認する。 検証コードの公開と実際の攻撃での悪用を分け、KEVなどを調べる。掲載がない場合も、外部から接続できる範囲と扱うデータを確認する。
3. 対応内容と期限を決める。 公式勧告で修正済みバージョンや暫定的な回避策を確かめ、更新担当と適用期限を決める。
4. 適用後の状態を確認する。 稼働バージョン、更新漏れ、侵害の痕跡を確認し、対応結果を記録する。