graph-the-network

ネットワークをグラフ化する

30個のセレクターのリストと30個のセレクターのグラフは同じ情報を含んでいますが、2つのクラスターがノードを共有していることがわかるのはグラフだけです。それがすべての根拠です。人間は行をまたいだ共通要素を見つけるのが苦手ですが、配置図ならすぐに見つけられます。初心者によくある誤りは、グラフを出力、つまりレポートの最後に描く図として扱うことです。グラフは最初のピボットから作る、調査案件の作業用メモリであり、レポートはそこから生成します。

2つ目のノードを追加する前にスキーマを決める

重複排除、中心性、クエリ、レポートの表など、後続の有用な作業はすべて、最初の10分間に行う判断に左右されます。ルールは2つです。

現実世界の事物1つにつきノード1つ。 別名は属性であり、ノードではありません。「J. Okonkwo」、「jokonkwo」、「Joseph Okonkwo」をそれぞれ別のノードにすると、計算するメトリクスはすべて誤りになります。次数が3つに分散するため、案件で最も重要な人物が周辺的に見え、重複データに分散してしまうため、2つのクラスターをつなぐ共通の関係も現れません。証拠に基づいて統合し、その統合内容（どのセレクターを、どの程度の確信度で統合したか）を記録してください。記録されていない統合は、2つのものが同一だという、監査不能な断定です。

人々がつまずきやすい例外があります。人物とそのアカウントは別の事物です。Person —operates→ Account とモデル化してください。運用者は変わることがあり、アカウントは共有されることもあるためです。これらを1つにまとめると、どちらの事実も表現できなくなります。

エッジタイプは固定された集合にする。 エッジのラベルを自由記述にすると、1つのグラフに owns、owned-by、ownership、is owner of が混在し、すべてを見つけるクエリは作れません。語彙を固定し、種類を絞り、方向性を一貫させ、案件ファイルの冒頭に記載してください。エンティティタイプ、エッジタイプ、必須属性、別名／統合の規約を含むスタータースキーマはこちらです： reference/schema-starter.md。

エッジにソースと確信度を記録する

これこそが、有用なグラフと見栄えのよいグラフを分ける実践であり、最も省略されがちなことです。

ノードの出所が問題になることはほとんどありません。主張の対象は関係性です。「この人物がこの会社を支配している」「このドメインはこのアクターが運用している」といったものです。そのため、各エッジには最低限、ソース（URL、ツール、または資料ID）、取得日時、ソースの評価（investigate-anything を参照）、確信度を持たせます。これらがなければ、登記申請によって裏付けられたエッジも、似た文面を投稿する2つのアカウントから推測されたエッジも同じように表示されます。いったん図にすると、弱い結びつきと強い結びつきの区別がつかなくなり、事実として推論に使われます。

確信度は視覚的に表現してください。確認済みは実線、可能性が高いものは破線、未確認のものは点線にします。次にグラフを見て、どれだけの構造を点線に頼っていたか確認してください。confirmed-only ビューを作り、それでも結論が成り立つか確認します。成り立たなくなるなら、その発見は最も弱いエッジに由来する見せかけです。

終了する可能性のあるエッジには、valid_from／valid_to で有効期間を追加してください。雇用、ドメイン登録、住所、役員就任、IPの名前解決などが該当します。時間情報のないグラフは、すべてが同時に存在していたと暗黙に断定し、実際には重複する時期がなかった人々の間に関係性を作り出します。同じ会社の役員を5年違いで務めていた2人に関係性はありませんが、時間情報のないグラフは関係があるかのように示します。

グラフが実際に示すもの

• 共有インフラストラクチャ。 1つの登録者メールアドレス、1つの分析用または広告用識別子、1つの TLS 証明書、1つの再利用されたアバターハッシュが、無関係に見えるサイトを結び付けます。who-owns-this-domain、find-hidden-subdomains、find-exposed-servers の結果をグラフに取り込むと、探し回らなくても、これらが次数の高いノードとして現れます。
• ブリッジ。 そのノードを取り除くと、グラフが互いにつながっていない複数の連結成分に分かれるノードです。実際には、2つのペルソナや2つのネットワークをつなぐ人物または資産であり、たいていはこれが発見事項になります。形式的には媒介中心性が高く、視覚的には2つの塊の間にあるノードです。
• 次数と媒介中心性。 次数が最も高いノードは、多くの場合、最も目立つ関係者、つまり公の役員、表向きの人物、または共有サービスです。実質的な支配者は、次数が中程度で媒介中心性が高い位置にいることがよくあります。つながりは少なくても、重要な相手とつながっています。両方を計算して比較してください。両者が異なる場合は、その違いを詳しく調べてください。
• コミュニティ。 モジュラリティ／コミュニティ検出によって、グラフをクラスターに分割します。主に、属するクラスターが不自然なノードを見つけるのに役立ちます。
• ギャップ。 密な近傍に1つのエッジしか持たないノードは、現実についての事実ではなく、収集上のギャップを示しています。疎な領域を次の調査の起点にしてください。

中心性は、調べるべき場所を示す手掛かりとして扱い、結論とは見なさないでください。中心性が測るのは現実だけでなく、収集状況でもあります。最も徹底的に列挙したものが、グラフの中心になります。

ツール

状況	使用するもの
ノードが約200未満で、アナリストが1人、最終的にレポートにまとめる必要がある	スプレッドシートまたは CSV のノード表とエッジ表を用意し、Graphviz で描画するか、Gephi にインポートする
パス、共有属性、「A と B をつないでいるのは誰か」といったクエリ駆動の作業	Cypher を使った Neo4j
レイアウト、指標、コミュニティ検出、プレゼンテーション	Gephi
ノードからの自動的なピボットが必要で、ライセンスも利用できる	Maltego

率直な標準案として、ほとんどの調査では、ノードとエッジの2つの CSV にシンプルな描画ツールを組み合わせるほうが、あらゆる重量級ツールより優れています。差分を確認でき、バージョン管理ができ、そのツールを使ったことのない人もレビューでき、上記のすべてにインポートできます。理由がある場合（変換処理の自動化や、頭の中で把握できないほど大きなグラフ）に Maltego や Neo4j を導入し、最初から使うことは避けてください。

Maltego のモデルは、使わない場合でも理解しておく価値があります。エンティティには変換処理が紐付きます。これは、あるエンティティを関連するエンティティに変換するサーバー側の検索処理です（ドメインからサブドメイン、IP、証明書へ）。変換処理は情報収集にあたるため、それぞれがあなたに帰属するネットワーク上のアクションとなり、結果には基になるデータソースの精度がそのまま反映されます。変換処理の出力を裏付けるのは Maltego 自身のグラフであり、現実ではありません。

Cypher を学ぶ価値がある理由は1つです。パスのクエリです。「この人物とこの企業の間に、最大4つの関係からなるつながりはあるか。あるなら、それは何か」と尋ねるのは、Neo4j ならクエリで済みますが、ほかの方法では手作業で骨の折れる作業になります。

MATCH p = shortestPath((a:Person {id:'p-kestrel'})-[*..4]-(c:Company {id:'c-nordvale'}))
RETURN p

機能比較、インポート形式、Gephi の CSV 列名、および各ツールが適さない状況については、reference/tool-comparison.md を参照してください。

問題が起きる箇所

つながりすぎ。 よくある失敗です。エッジを十分に増やすと、すべてがすべてにつながり、グラフは毛玉のようになって情報を伝えなくなります。価値の低いエッジが原因です。同じ国、同じレジストラ、同じホスティングプロバイダー、同じウェブメールのドメイン、同じ人気のある CDN IP などです。Cloudflare を使っている 2 つのサイトに関連があるとは限りません。Gmail アドレスを持つ 2 人に関連があるとは限りません。ルール：エッジを加える価値があるのは、それが識別力を持つ場合に限ります。無関係なエンティティの大部分が共有しているなら、それは関係ではなくコンテキストです。そのような情報はノードの属性としてモデル化するか、省きます。

共有サービスのエッジを関係と誤読する。 共有ホスティング、レジストラのプライバシー保護サービス、会社設立代行業者の登記住所、決済処理業者、メール転送サービスなどは、実在する共有ノードを生み出しますが、当事者間に関係があることを示すものではありません。そのノードに関わる他のエンティティがいくつあるか、必ず確認してください。400 社が登録している住所なら、それは代行業者の住所です。

エンティティ解決の誤り。分割と統合の両方。 1 人の人物を 3 人に分割すると発見が隠れ、2 人の人物を 1 人に統合すると存在しない関係を作り出します。統合のほうが危険です。グラフには、あなたが行った統合によって結ばれた 2 つのクラスターが、強い裏付けのように見えてしまうからです。統合はすべて、その根拠を記録し、必要に応じて解除できるようにしてください。

レイアウトによる信頼度のすり替え。 推定エッジが点線で描かれ、それがスクリーンショットにされ、さらに文章で説明され、3 段階後には、誰も出所をたどれないレポートの図に実線で描かれています。レポート用の図は必ずデータファイルから生成し、手作業で編集した画像から作らないでください。

議論の根拠としてのグラフ。 うまく配置されたグラフは、証拠に見合わないほど説得力を持ちます。レイアウトアルゴリズムが最適化するのは見た目であり、力学的レイアウトの図でノードが隣接していることは発見ではありません。画像ではなく、エッジを引用してください。

不完全なグラフでの指標。 ある主体だけを網羅的に列挙して作成したグラフで中心性を計算すれば、その主体が必ず首位になります。報告する指標には、ノートの収集範囲も併記してください。

信頼度の評価

グラフではなく、エッジを評価します。

• 確認済み — 権威ある一次記録（登記申請書、署名済み証明書、両端のエンドポイントで自己申告された相互リンク）に関係が記載されているか、循環参照のチェックに合格した、独立して収集された 2 つの情報源によって裏付けられているものです。
• 可能性が高い — 強力な情報源が 1 つあるか、識別力を持つほど珍しい特徴的な共有セレクター（セルフホスト型の分析 ID、珍しい再利用パスワードハッシュ、個人ドメインなど）があり、矛盾する証拠がないものです。
• 未確認 — 多くの無関係なエンティティが共有している可能性のある属性、または文体や時系列だけの相関です。点線で描くか、描かないでください。
• 却下 — 共有サービス、ブローカーフィード、または偶然の一致に由来すると判明したものです。却下したエッジも、理由を添えてファイルに残してください。そうしないと、次の分析者がまた追加してしまいます。

経路の強さは、その経路で最も弱いエッジによって決まります。報告する経路について、平均ではなく、エッジの信頼度の最低値を明記してください。

実例

ケース：一見無関係な、不正に関わる3つのドメイン。最初のピボットで得たノードとエッジを、2つのCSVに保持します。

3つすべてのWHOIS情報はプライバシー保護されているため、登録者のエッジは利用できず、明白なアプローチは行き詰まります。read-deleted-pages でアーカイブされたコピーを調べると、そのうち2つについてプライバシー保護前の登録スナップショットが見つかり、出典と日付が記録された、確度「confirmed」の Person —registered→ Domain エッジが2つ得られます。

IP解決を追加すると、3つすべてに加え、無関係なサイト40件をつなぐ見かけ上のハブが生まれます。共用CDNのアドレスです。次数だけで見るとグラフ内で最も中心的なノードですが、意味はありません。エッジから外し、ノード属性に変更すると、それに伴って複雑に絡み合った状態も解消します。

実際の橋渡しとなるのは、2つのドメインのアーカイブ済みHTMLと、対象範囲に含まれていなかった4つ目のサイトにある、セルフホスト型の分析用識別子です。その4つ目のサイトは、本名が掲載された個人ポートフォリオです。「confirmed」のみを表示したビューで媒介中心性を調べると、可視の登録者ではなく、その識別子が2つのクラスターをつないでいることが分かります。時間的なエッジからは、ポートフォリオでその識別子が使われなくなったのは3つ目のドメインが存在するようになる前だと分かるため、そのドメインはつながっていないままにします。そう明記することで、報告の誠実さを保てます。

ピボット

グラフから新たに得られたセレクター	スキル
共通する登録者のメールアドレスまたは個人ドメイン	who-owns-this-domain、what-an-email-reveals
共通する証明書またはサブドメインのパターン	find-hidden-subdomains
共通するIPアドレスまたはホスティングの痕跡	find-exposed-servers
複数のノードで再利用されているアバターまたは画像	find-the-original-image
新たに明らかになったハンドル名	hunt-a-handle
新たに明らかになった人物	find-anyone
新たに明らかになった企業または住所	x-ray-a-company、who-really-owns-it
ウォレットのクラスターと取引相手	follow-the-crypto
完成したエンティティマップ	write-the-intel-brief

法的事項と取り扱いに関する注意

ケースグラフは、特定された人物の情報を目的に合わせてまとめたものであり、個々の情報よりも機微性が高くなります。この手法は情報を集約することが目的であり、データ保護規制が精査するのもその集約です。第三者のノード（親族、同僚、同居人）はすぐに増えていきます。グラフをどこかに送る前に、目的に関係のない人物は削除し、公開する図表からも除外してください。ケースファイルは、../../ETHICS.mdに従い、ケースの他の情報と同じ暗号化および保持ルールで保管してください。ホスト型のグラフプラットフォームを使うと、ケース情報を第三者にアップロードすることになります。対象者のセレクターをクラウド変換ツールに入力する前に、それが許可されていることを確認してください。