メインコンテンツまでスキップ

企業向けハニーポットの設計と運用

企業向けハニーポットの設計と運用の結論、主分析、判断材料、前提と限界を一枚にまとめた詳細図

先に結論​

企業がハニーポットを導入する目的は、攻撃をたくさん集めることではない。防御や対応に必要な問いを先に決め、正当な通信がほぼ来ない観測面から得た証拠を、検知、対応、投資の判断へ変えることなのだ。

設計の順番は次のようになる。

  1. 誰が何を判断するかを決める
  2. その判断に必要なPriority Intelligence Requirement（PIR）を定める
  3. 許可範囲と停止条件をRules of Engagement（RoE）にする
  4. 本番から隔離した最小機能のセンサーを作る
  5. 必要なデータだけを、感度に応じて分離して保存する
  6. 観測を分析し、利用者へ配布し、判断結果を次の設計へ戻す

「ログが増えた」だけでは成功ではない。PIRへ期限内に答え、その結果が検知ルール、監視優先度、対応手順、またはリスク受容の変更に使われて、初めて活動として一周するのだ。

ハニーポットは設備ではなく活動である​

ハニーポットを「インターネットに置いて待つ箱」と考えると、収集量だけが評価指標になりやすい。しかし、データは文脈と分析を経なければThreat Intelligence（脅威インテリジェンス）にはならない。

価値は、次の関係で考えるとよい。

CTI価値 = 意思決定への適合性 × 証拠品質 × 適時性 × 再利用性
          - 収集・分析・法務・運用・第三者被害のリスクとコスト

大量のIPアドレスやPayloadを保存しても、利用者、期限、判断、確信度、Feedbackがなければ、それは観測データの倉庫なのだ。反対に件数が少なくても、データ境界、停止手順、検知反映を検証できれば成果になる。

最初に「誰の、どの判断か」を決める​

Operational Objectiveは「攻撃を集める」より具体的にする。たとえば「公開認証面の探索系列から、既存WAFとSIEMへ追加する検知候補を四半期ごとに決める」であれば、利用者と成果が見える。

PIRは、一つの事実や活動を問い、一つの判断へ接続する。

PIR-ID: HP-PIR-002
利用者: SOC検知責任者
問い: 過去30日、公開認証面で観測した探索系列のうち、
      既存SIEMで未検知かつ再現可能な系列はあるか。
判断: 新しい相関ルールを本番化するか。
期限: 毎月第3営業日
必要データ: route family、時刻、匿名visit、認証試行順序、Canary到達、SIEM hit
除外: 単一IPだけの一致、User-Agentだけの一致、HTTP 200だけの一致
停止条件: Rawに実在資格情報または規制対象データを確認

「誰が攻撃しているか」「すべての新しい攻撃を見つける」といった問いは、単一センサーでは答えられない。本人性や帰属を扱うなら、独立した情報源、法的権限、確信度基準が別に必要なのだ。

成功条件と停止条件を同時に作る​

成功だけを定義すると、危険なデータや想定外の操作を前にしても収集を続けてしまう。設計時には成功、失敗、pause、stop、再開を同じ表に置く。

種別条件例
成功PIRへ期限内に回答し、一つ以上の検知・防御判断へ利用された
分析品質根拠、代替仮説、確信度、観測限界が判断ごとに記録された
安全外向き悪用0件、実データ混入0件、禁止フィールドの通常ログ露出0件
運用停止判断から15分以内にRaw取得停止、30分以内に公開経路切離し
失敗収集は継続したが、利用者、判断、Feedbackがなかった
即時停止実資格情報、規制対象データ、第三者攻撃への悪用、出口制御逸脱、未承認構成を確認した

停止権限は現場にも与える。外向き悪用や未承認データを確認したとき、経営承認を待たずに一時停止できなければ安全装置として遅い。再開は原因、影響、修正、証跡、追加リスクをレビューした別承認にするのだ。

責任者を一人に集めない​

ハニーポットは、Security部門だけで完結しない。技術的には小さなセンサーでも、個人情報、違法・有害データ、ドメイン、証明書、第三者被害、廃止後の名前空間まで責任が広がる。

役割主な責任
Executive Sponsor目的、予算、残余リスク、高リスクな配置を承認する
CTI LeadPIR、収集計画、分析基準、配布、Feedbackを管理する
Sensor Owner隔離、patch、出口制御、再構築、停止を管理する
SOC/CSIRTalert受領、相関、escalation、Incident Response移管を行う
Detection Engineering観測を検知候補へ変え、誤検知とrollbackを評価する
Legal/Privacy適法性、通知、保持、共有、越境を確認する
Data Owner保存先、分類、アクセス、保持、削除、監査を承認する
Domain/DNS OwnerDNS、証明書、誤到達、廃止を管理する

少なくとも四半期ごとにPIR、アクセス権、保持期間、出口制御、通知先、停止手順を見直す。担当者の異動、ドメイン変更、クラウド移行、対話レベル変更は臨時レビューのtriggerなのだ。

Rules of Engagementを先に書く​

RoEは、活動の許可範囲と非交渉の停止条件を一つの文書にする。最低限、次を含める。

  • 目的、PIR、利用者、対象期間
  • 対象ドメイン、IP、クラウドアカウント、ネットワーク境界
  • 許可するサービス、応答、Lure、対話レベル
  • 禁止する実データ、実認証、外向き通信、実行機能
  • 取得項目、保存先、暗号化、保持、削除、共有範囲
  • 監視時間、alert条件、on-call、IR移管条件
  • 成功、失敗、pause、stop、再開、廃止条件
  • 誤到達、第三者被害、違法・有害データへの対応
  • 構成変更、緊急変更、例外、リスク受容の承認者
  • After Action ReviewとFeedbackの期限

第三者への侵入、hack back、盗取認証情報の再利用、管理権限外の基盤への働きかけは含めない。能動性は、自組織が管理・承認する環境内で囮や観測条件を変える範囲に限定する。

対話レベルと活動の成熟度を分ける​

低対話・高対話は、攻撃者へ許す操作の深さである。PIRへどの程度指向しているか、CTIのサイクルが回っているかとは別の軸なのだ。

対話レベル得られる情報主なリスク
低対話偵察、探索、初期Payload、試行系列識別されやすく、侵入後行動は見えない
高対話実行後TTP、tool、永続化、C2試行侵害、踏み台、監視負荷、証拠・法務リスク
Hybrid広い観測と深い挙動の両立経路複雑化、移送時の識別、制御逸脱

高対話型だから上位とは限らない。大量のコマンドを取得しても、PIR、分析、利用者、Feedbackがなければ、深いtelemetryが増えただけである。企業の最初のPoCでは、低対話型で安全境界と完全なサイクルを確認する方が扱いやすい。

実サービスらしさは一つの物語で作る​

ログイン画面だけを置いても、補助ページ、Cookie、エラー、画面遷移、技術履歴が矛盾すれば、すぐに不自然になる。MITRE EngageがNarrativeと呼ぶ観点では、囮の役割、利用者、技術履歴、正常動線、管理動線、更新履歴、Lureを一つの物語として設計する。

実在企業名、実社員、実顧客、実ticket、実credentialを複製してはいけない。組織固有性を上げるほど説得力は増すが、ブランド誤認やSocial Engineeringへの再利用リスクも増える。承認済みの合成情報を使うのだ。

安全境界は四つの面に分ける​

推奨構成では、公開センサー、制御面、収集面、分析面を分離する。

Internet / monitored zone
          |
          v
  Edge controls / Rate limit
          |
          v
  Isolated honeypot sensor
     |        |
     |        +-- deny-by-default egress
     |
     +--> normalized event pipeline --> analytics / SIEM
     |
     +--> bounded sensitive capture --> restricted short-term vault

Management plane --> separate identity, MFA, audit
Analysis plane   --> text-safe tooling, no auto-open, no auto-execute

本番とは別アカウント、別network、別secretを使い、本番SSO、社員directory、顧客DB、実メール配送へ接続しない。公開応答と収集処理も分け、分析基盤の障害で公開面が500になる構成を避ける。

特に高対話化で重要なのはegress controlである。原則denyとし、DNS、HTTP、SMTP、SSH、任意TCP/UDP、cloud metadata、内部アドレスへの通信を個別に制御する。通信許可は「観測に使えそう」ではなく、PIRとRoEから導く。

データは三層へ分ける​

すべてをRawで保存すると、分析価値より先に管理リスクが膨らむ。収集項目は感度と用途で分ける。

層内容用途管理
正規化event時刻、分類、状態、粗い属性、匿名ID傾向、比較、alert比較的長期、分析権限
短期運用log高関心event、error、degraded障害・即時確認短期、運用者限定
機微RawPath、Query、Body、file、PCAPPayload・未知挙動分析最短保持、強い制限、個別監査

Path、Query、Bodyには実在資格情報が含まれる前提で扱う。User-Agent、Referer、header、ファイル名にもtokenや識別子が入り得る。受信した式、URL、HTML、fileを分析画面が自動解釈・実行しないようにする。

IPを単純にhash化しても匿名化とは限らない。入力空間が小さく再識別できるため、必要なら鍵付きHMAC、rotation、用途分離を使い、アクセス制御と保持制限も残す。何を収集するかの詳しい論点は、ハニーポットでどこまで情報を収集するべきかに分けている。

観測をCTIへ変換する​

FIRSTのCTI Curriculumに沿うと、活動は六段階で回る。

段階実施内容必須証跡
DirectionPIR、利用者、判断、期間、停止条件PIR、RoE、承認
Collectionセンサー、Lure、項目、期間を割り当てるCollection Plan、構成版
Processing正規化、分類、重複排除、機微情報分離schema、処理code、品質記録
Analysis相関、仮説評価、代替説明、確信度SQL、分析記録
Dissemination適切な相手へ期限内に配布するreport、ticket、検知PR
Feedback利用結果をPIRとセンサーへ戻す決定記録、AAR、次期PIR

たとえば、同じ匿名visitでdiscovery → auth → sensitiveが記録されたことはデータである。「認証面を確認した後に設定情報らしき経路へ進んだ系列」は情報になる。そこへbaseline、既存SIEMの検知有無、代替仮説、確信度、推奨する相関条件、rollbackを加え、判断者へ期限内に渡してCTI成果物になるのだ。

HTTP 200、認証formへのPOST、Canary到達、単一IPの一致は、実行、侵入、権限取得、標的意図を証明しない。観測事実、分析判断、未確認事項を分け、High、Moderate、Lowなどの分析確信度は証拠の質として付ける。

小さく始めて、昇格を承認制にする​

導入は次の順で進める。

Phase実施内容次へ進む条件
0Charter、PIR、法務、RoE、責任分界を作る目的・禁止事項・停止権限が承認済み
1隔離した低対話型PoCを公開する外向き悪用がなく、再構築と停止を実証
2限定Rawと最小CTI cycleを試すPIRへの回答と利用者Feedbackを記録
3仮説別のvariantや対照を設ける比較可能な成果と検知・防御判断を提示
4必要な場合だけ保護対象の名前空間でpilot法務・経営を含む追加リスク受容
5定常運用または撤去価値、費用、残余リスクを定期評価

最初から高対話型や実ドメイン直下を選ぶ必要はない。独立した低対話センサーでは答えられないPIRが残り、追加価値が追加リスクを上回る場合だけ昇格する。DNSを向けただけ、保存量を増やしただけ、画面を特定製品風にしただけでは成熟した活動にはならないのだ。

導入前の最小チェック​

  • PIRは一つの判断と期限へ接続しているか
  • 本番のidentity、network、secret、dataから隔離したか
  • egressはdeny-by-defaultか
  • 実認証、実コマンド、upload、外部fetchを必要なく実装していないか
  • 通常event、短期log、Rawを分離したか
  • Rawの上限、保持、自動削除、kill switchがあるか
  • 収集不能、sampling、WAF前段拒否を「通信なし」と誤読しないか
  • 観測事実、分析判断、未確認事項を分けるreport形式があるか
  • 現場が即時停止できるか
  • DNS、証明書、保存データまで含む廃止手順があるか

この十項目を説明できない段階では、機能追加より設計の穴を埋める方が先なのだ。

参考資料​