ドメインを測定する前に銀行エンティティを定義する
銀行ドメインの調査では、認可を受けた機関、持株会社、ブランド、支店、およびテクノロジー サービス プロバイダーを区別する必要があります。これらの部門は Web サイトを共有したり、異なるドメインを運営したりすることができ、合併やブランド変更を通じてその関係が変化する可能性があります。ブランドの公開 Web サイトでDNSを観察しても、法律機関の電子メール資産全体が自動的に記述されるわけではありません。したがって、エンティティとドメインのマッピングは証拠の一部であり、破棄すべき予備的な詳細ではありません。
この原稿は、銀行の母集団を収集したり、ドメインをスキャンしたりしない方法を提案します。実際の機関のセキュリティ、コンプライアンス、支払い能力、顧客リスクについては主張しません。目標は、曖昧なブランド名から構築された順位表ではなく、再現可能なマッピングと技術的に制限された結果を生み出すことです。
選択した管轄区域に適切な権限を使用する
米国の被保険銀行スコープの場合、 FDIC BankFind API ドキュメント 機関データを場所や支店データから区別します。これは有用な公式情報源構造であり、すべての銀行や金融サービスの世界的なリストではありません。別の管轄区域を対象とする研究は、関連する当局とその範囲を保持する必要があります。 1 つの不適格な銀行分母の下に異なる規制対象者を混在させないでください。
FDIC の文書には、主要なインターネット アドレスは機関によって報告され、リンクされたサイトは FDIC の管理外であるとも記載されています。その免責条項は解釈する上で重要です。リストされた Web サイトはソースでサポートされているマッピングの手掛かりであり、すべてのページを推奨したり、送信者ドメインの包括的な目録を保証するものではありません。 Web サイトのフィールドを完全なセキュリティ アサーションとして扱うのではなく、フィールドの出所と検証日を保持します。
フラットな名前リストの代わりに関係モデルを構築する
機関、関連する親グループ、支店または場所、およびパブリック ブランドに対して個別の識別子を作成します。サンプリングされた各ドメインを、その関係をサポートする特定のエンティティおよびソースにリンクします。合併、ブランド名変更、廃止されたドメインの発効日を記録します。よく知られた銀行グループのラベルが付いた 1 つの行では、複数の認可を受けた事業体やさまざまな運営上の責任が隠れてしまう可能性があります。
共有ドメインの重み付け方法を定義します。すべてのブランチを個別の認証展開としてカウントすると、大規模なブランチ ネットワークに不釣り合いな影響を与える可能性があります。親ドメインのみをカウントすると、独立した送信取り決めを持つ子会社を省略できます。どちらのアプローチも本質的にすべての質問に対して正しい答えというわけではありません。研究では、指標を計算する前に単位を選択し、その結果を説明する必要があります。
サンプル Web サイトを送信者資産から分離する
教育機関は、従業員へのメール、顧客への通知、カード サービス、調査、マーケティング、採用、および外部委託されたコミュニケーションに個別のドメインを使用する場合があります。通常、公開 Web サイトのサンプルでは、それらすべてが特定されるわけではありません。認可された調査範囲なしに、そのギャップを埋めるために、もっともらしいサブドメインを生成したり、顧客メッセージを検索したりしないでください。マッピングでは、ドメインがサンプリングされた Web サイトであるか、独立して証明された送信者であるか、未解決の候補であるかを示す必要があります。
RFC 7208 評価する SPF 関連するSMTP ID を使用します。 RFC 9989 評価する DMARC アライメント 表示されている From ドメインに追加し、ポリシー検出を定義します。これらのルールにより、制限が明確になります。つまり、ある Web ドメインでの公開では、別のドメインまたはサプライヤーが制御するルートを介して送信されるメッセージの認証を確立できません。
制御と帰属の不確実性を維持する
登録情報はドメイン関係を文書化するのに役立ちますが、現在の運用管理の証拠として扱うべきではありません。 RFC 9083 RDAP オブジェクト、ロール、イベントを定義します。 RFC 9537 実装されている場合の編集情報について説明します。プライバシーが保護されている、または不完全な回答は、銀行が所有権を隠しているという主張ではなく、可視性の制限にとどまるべきです。
同様に、共有DNSホストまたは送信プロバイダーは、機関がセキュリティ ポリシーまたは管理アカウントを共有することを確立しません。観察された依存関係を、推定されたコントロールとは別に記録します。所有権または送信者の帰属をサポートできない場合は、よく知られたサービス名から確実性を主張するのではなく、関係を未解決としてマークし、宣言されたルールに基づいて除外します。
DNS測定を個別に設計する
マップされたドメインのリストを固定し、正確な所有者名、レコード タイプ、リゾルバー コンテキスト、タイムスタンプ、再試行、およびパーサーのバージョンを指定します。正確な名前の検索と、現在適用可能なポリシーの検出を区別します。別のアナリストが結果を再現できるように、生の回答とエラー カテゴリを保持します。関連する証拠と範囲がなければ、失敗したクエリを銀行が認証を持っていないとして説明すべきではありません。
信頼できる観察結果と再帰的な観察結果を収集する場合は分離してください。複数の保存 TXTレコード およびプロトコル選択前の文字列。分類では、施設全体の合否を判断するものではなく、サンプリングされた名前で何が観察されたかを特定する必要があります。この作業では、 DNSクエリ、 SMTPプローブ、または受信メッセージのサンプルは収集されませんでした。
消費者のリスクとコンプライアンスの推論を回避する
DNS公開だけでは、顧客の財務情報が漏洩したかどうか、詐欺が発生したかどうか、または機関が法的要件を遵守したかどうかを示すことはできません。これらの結論には、さまざまな証拠と適格なレビューが必要です。ポリシーに関する観察が欠落している、または無効である場合は、銀行のサービスの安全性についての主張にならずに、研究の範囲内で技術的な発見を正当化することができます。
尺度、重み付け、および制限が透明で正当化されていない限り、単純化した認証スコアによって機関をランク付けしないでください。施行を要求するポリシーは、すべての正当なストリームが調整されていること、またはすべてのなりすましが防止されていることを証明するものではありません。この研究は、観察された設定値が低いことが顧客の経済的損失を直接予測することを示唆することを避けるべきです。
エンティティとドメインのマッピング ワークシート
管轄区域、権限ソース、ソース日付、機関識別子、エンティティ タイプ、親関係、ブランド、支店関係、およびサンプリングされたドメインの列を作成します。ドメイン リンクの証拠、発効日、マッピングの信頼性、ドメインの役割、クエリ プラン、および除外を追加します。 1 対多のマッピングを 1 行で忠実に表現できない場合は、リレーションシップ テーブルを保持します。
リリース パッケージには、マッピング、ソースの出所、正規化されたクエリ入力、生の観察結果、分類ルールが含まれている必要があります。査読者は、どのブランドや子会社が意図したものかを推測することなく、公開された調査結果をその機関と正確なドメインに遡って追跡できる必要があります。この方法では、機密性の高い顧客データ、アカウントの詳細、従業員の個人情報は不要であり、粉飾する目的で収集してはなりません。
架空の診断: グループ Web サイトがすべての子会社になる
架空の研究者が銀行グループの公開 Web サイトを選択し、観察されたポリシーをすべての子会社の結果として報告します。マッピングのレビューでは、ソースリストが複数の機関を区別しているのに対し、ドメイン証拠はグループのウェブサイトのみをサポートしていることが判明しました。修正案は、より狭い範囲の Web サイトの観察結果を公開し、より広範な送信者資産を未測定としてマークすることです。
チームはその後、承認されたサブドメインの証拠を入手し、改訂されたデータセット バージョンに基づいて範囲を拡大することができました。マッピングが不完全であるため、推測された名前でギャップを埋めたり、セキュリティ上の欠陥を示唆したりすることはできません。このシナリオは架空のものであり、実際の銀行、ドメイン、スキャン、またはコンプライアンスの申し立ては含まれません。
リリース状況
カタログには、エンティティとドメインのマッピングの公開と、サンプリングされた Web ドメインとより広範な送信者資産との区別が必要です。その元のマッピングは開いたままになります。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。この草案は、銀行固有の調査デザインを提供するものであり、入力されたデータセットや機関に関する調査結果ではありません。