Data Leak Detection — 漏洩データの横断検索
プラットフォームがインデックス化した漏洩文書の集積に対する検索エンジンです。対象はダンプ、コンボリスト、インフォスティーラーのログ、フォーラムへの投げ込み、そして顧客自身が持ち込んだ資料。検索はフェデレーテッド方式で、1件のリクエストが設定済みのすべてのインデックスサーバに送られ、応答は統合されて単一の結果として返ります。
概要
各文書は断片（チャンク）に分割された状態でインデックスに入ります。検索語は、断片の本文（重み3）、ファイル名（重み2）、セクションとタイトルのメタデータに対して、タイプミスへの許容度を持たせて突き合わせられます。返るのは最大3件のスニペットで、検索語が文の途中で強調表示されるため、アナリストはファイルを開かずに文脈を読めます。
結果には3種類の集計が添えられ、絞り込みにも所見の診断にも使えます。ファイル種別ごと、カテゴリごと、取得元ソースごとの3つです。たとえば「同じCNPJが、あるソースでは15件の表計算ファイルに、別のソースでは1通のメールにだけ現れる」といったことは、この集計から分かります。
内部の仕組み
フェデレーションとページング。 プラットフォームは環境設定からインデックスサーバを検出し、そのすべてに問い合わせます。集計はキーごとに合算され、結果は統合済みの集合全体に対して関連度で並べ直され、そのうえでページングされます。1台が落ちても残りが応答し、障害は記録として残ります。検索が最も遅いノードに人質に取られることはありません。
フェイルクローズの分離。 グローバル管理者以外に対しては、組織によるフィルタが常に適用されます。インデックス済み文書の一部に組織フィールドがまだ存在しない場合でも、です。この挙動は意図したものです。フィールドを持たない文書は条件に合致せず、表示されません。以前の実装は、フィールドが無いときにフィルタを外して全件を返していましたが、少なく返す側に倒す設計へ変更しました。漏洩データの検索において、偽陰性は不便ですが、顧客間のデータ混入は事故です。
ソースをまたいだハッシュ照合。 同じファイルは複数の経路で出回ります。プラットフォームは各文書のsha256、sha1、md5を、出現回数と初出・最終出現の日付とともに保持します。これは全文検索では答えられない問いに答えます。「このダンプは新規なのか、それとも3月のものを再梱包しただけなのか」という問いです。
確信度を明示した帰属付け。 各ハッシュには帰属情報を付与できます。攻撃者、キャンペーン、流通経路（Telegram、フォーラム、ペーストサイト、マーケットプレイス、スティーラーログ、ダークウェブ、クリアウェブ、パートナーのフィード、手動アップロード）、URL、投稿者のハンドル、そして判断根拠です。確信度は3段階で、各段階の基準を明示しています。低は自動ヒューリスティック、中はソース間の相関、高は複数のシグナルを伴う人手レビューが必須です。レビュー担当者の氏名と日付は記録に残ります。
主な機能
- 構造化セレクタ：メールアドレス、ドメイン、URL、IPv4、IPv6、電話番号、Bitcoinアドレス、Ethereumアドレス、CPFとCNPJ（ブラジルの個人・法人の登録番号）
- PDF、DOCX、XLSX、PPTX、HTML、EML、および ZIP・RAR・7z 圧縮ファイルからのテキスト抽出
- 保存済み検索。組織内での共有は任意で、編集できるのは作成者または組織管理者
- JSONまたはCSVでのエクスポート。上限は100、500、1,000、5,000件から選択
- 6種類のイベント（検索、閲覧、ダウンロード、エクスポート、検索の保存、検索の削除）の監査記録。IP、クエリ、フィルタ、結果件数、応答時間を保持
ユースケース
- 自社の認証情報が最近のダンプに出ているか、どの経路で出回ったかを確認する
- 販売されているデータベース上で、顧客のCPF・CNPJがどこまで露出しているかを追跡する
- 「新規」と称して売られているダンプが既に出回っていたかを、出現回数から判定する
- インシデント通知やテイクダウン申請のために、出所の証跡をまとめる
本モジュールが行わないこと
- 保存済み検索はアラートを発報しません。 再利用のためにクエリを保存するだけで、スケジュール実行はしません。通知付きの継続監視はThreat Monitoringの役割で、同じ集積を検索対象にします
- HaveIBeenPwned、DeHashed、およびそれに類する外部サービスへの問い合わせは行いません
- 社内ディレクトリへの書き込みは行いません。Active DirectoryやEntra IDでのパスワード強制変更やアカウント無効化はしません
- 高い確信度での自動的な帰属付けは行いません。最上位の確信度には人による署名が必要です
- 抽出したテキストをリレーショナルDBには保持しません。テキストは検索インデックス側にあります
連携
- マルチサーバ構成のOpenSearch（インデックス
ooda_leaks_*） - Airflow（インデックス投入前にOCRが必要な文書の処理）
- OODA Threat Monitoring（同じ集積に対する定期検索）、OODA EASM（漏洩と外部公開資産の相関付け）
SLA・保証
集計をマージするフェデレーテッドインデックス · 組織単位のフェイルクローズ分離 · 全クエリを監査記録