方法論
このサイトは、企業が公表した不正アクセス・情報漏えいを 1 件ずつ、公表文の引用を根拠にして侵入経路ごとに整理します。 「仕方なかったのか、防げたのか」は主観では付けず、下のルールに公表された事実を当てはめて機械的に判定します。
掲載の方針
- 各項目には根拠となる公表文の記載と出典を付けます。公表文の転載はせず、判定に必要な範囲だけを引用します
- エンジニアによる推定は、事案ページの「推定」の枠の中だけに書き、公表された事実と混ぜません
- 続報や最終報告で事実が増えたら、分類と判定を更新します。推定が事実で裏付けられたら事実の節へ移します
侵入経路の分類
| 分類 | 意味 |
|---|---|
既知の脆弱性known_vuln_unpatched | 公表済みの脆弱性（VPN 機器・CMS・ライブラリ）。パッチ公開日と侵入日が公表されたときだけ放置日数を計算する |
ゼロデイzero_day | 侵害時点でパッチが無かった脆弱性 |
自社実装の不備app_vuln | 自社で実装した機能の脆弱性（SQLi・認可不備・XSS・ファイルアップロードなど） |
設定不備misconfig | 公開ストレージ、管理画面の公開、デフォルトパスワードなど |
認証情報の漏えい・悪用credential_leak | 正規の ID・パスワードやシークレットを使われた。ソースコード・設定ファイル・ログへの露出など、漏れた経路が公表されているかは事案ごとに異なる |
リスト型攻撃credential_stuffing | 他所で漏れた ID・パスワードの組み合わせによる不正ログイン |
従業員端末の侵害endpoint_compromise | フィッシング、マルウェア、インフォスティーラーによる端末の乗っ取り |
ソーシャルエンジニアリングsocial_engineering | なりすまし電話・ヘルプデスク詐欺・MFA 疲労攻撃 |
委託先・サプライチェーンsupply_chain | 委託先・SaaS・依存パッケージ経由 |
内部不正insider | 従業員・元従業員による持ち出し |
紛失・誤送信physical | 紛失・盗難・誤送信。不正アクセスではないが区別のために分類する |
原因非公表undisclosed | 原因が公表されていない、または調査中 |
判定ルール
主な侵入経路について、上から順に最初に当てはまった条件で判定します。
| 判定 | 条件（どれか 1 つ） |
|---|---|
| 基本的な対策の不備に該当 | 設定不備／認証情報がソースコード・設定ファイル・ログに露出していた／既知の脆弱性で CISA KEV 掲載から 30 日以上経って侵入／管理系アクセスに MFA が無かったと公表 |
| 標準的な対策で防げた条件に該当 | 既知の脆弱性でパッチ公開から 30 日以上経って侵入／自社実装の不備のうち SQL インジェクション・認可不備 |
| 回避が難しい条件に該当 | ゼロデイ／パッチ公開から 7 日以内の悪用／MFA ありの状態でソーシャルエンジニアリングにより突破 |
| 判定に必要な事実が非公表 | 原因非公表、または上の判定に必要な事実が公表されていない |
閾値の根拠
7 日・30 日は暫定の値です。米 CISA の BOD 22-01（KEV 掲載から原則 2 週間で対応）などを参考にしています。 閾値を変えたときは、変更日と理由をこのページに残します。
訂正方針
事実の誤り、続報の見落とし、引用の不備に気づいた方は訂正依頼フォームからお知らせください。 確認のうえ修正し、修正日と内容を事案ページに残します。公表元の企業・団体からのご連絡も同じフォームで受け付けます。