ゼロデイとは、開発元が修正プログラムを提供する前に悪用されたり、存在が知られたりしているソフトウェアの脆弱性のことです。製品やサービスの名前ではなくセキュリティ用語なので、導入して使うものではなく、料金もありません。
ゼロデイとは
名前は、開発元が対策に使える猶予が「0日」であることに由来します。欠陥そのものを「ゼロデイ脆弱性」、それを突く攻撃を「ゼロデイ攻撃」と呼びます。
通常の脆弱性対応は、公表され、パッチが配られ、利用者が適用するという順に進みます。ゼロデイではこの順序が崩れ、攻撃が先に始まります。パッチを欠かさず当てている組織でも、修正が存在しない間は防げません。これが一般的な脆弱性との決定的な違いです。
実際の事例
当サイトで取り上げた2件が、ゼロデイの性質をよく示しています。
ひとつは PHP2Shell です。The Register によると、AWS はこの脆弱性への攻撃が公表より前に始まっていたと明らかにしました。公表を受けてパッチを当てても、それ以前に侵入されていた可能性は残ります。
もうひとつは Cisco のメール関連製品です。The Register によると、攻撃者が最上位の root 権限を得られる種類の欠陥が、修正前の段階で悪用されていました。悪用したのは正体不明の犯罪者とされています。
どちらも当サイトで確認できたのは報道の見出しの範囲で、対象の製品名やバージョン、被害規模は分かっていません。
使い方ではなく対策:エンジニアがやること
「ゼロデイ 使い方」で調べている方の多くが必要としているのは、対策の方法だと考えられます。
- 外部に公開しているサーバーやメール関連機器を棚卸しし、ゼロデイの報道が出たときに影響の有無をすぐ判断できるようにする - パッチ適用で終わらせず、公表前の期間も含めてログを調べ、侵入の痕跡を確認する - 権限を最小限にし、ネットワークを分離して、1台が侵害されたときの被害を限定する
2点目は、PHP2Shell の事例から特に重要だと言えます。3点目は、root 権限を奪われる Cisco のような事例に備えるものです。
料金:企画・DX 担当が見積もるべき費用
ゼロデイ自体に料金はありません。費用が発生するのは守る側で、資産管理、ログ監視、緊急時の対応体制などが主な項目です。金額は環境の規模や構成で変わるため、ここでは目安を示しません。
企画担当者が押さえたいのは、「定例のパッチ適用だけでは防げないリスクがある」という前提です。緊急停止やメンテナンスをどう判断するかを、事前に決めておく必要があります。
誰が関わるのか:開発元や競合はあるか
ゼロデイは製品ではないので、特定の開発元や競合はありません。関わるのは、欠陥を修正する製品ベンダー、攻撃を見つけて公表する事業者や研究者、そして悪用する攻撃者です。PHP2Shell では AWS が、攻撃の時期を明らかにする役割を担いました。
投資家にとっての論点は、用語そのものではなく、検知や対応を手がけるセキュリティ企業の動向です。ただし、個別のゼロデイ報道が各社の業績にどう影響するかは、ここで挙げた事例からは判断できません。


