セキュリティ脅威に備えるためのレジストリオペレータ向けフレームワーク

目的

これは、ICANNの新gTLDプログラム委員会 (NGPC) が、政府諮問委員会 (GAC) に対してICANNコミュニティへの参加を奨励し、レジストリオペレータ (RO) が特定のセキュリティ脅威に対応できるようなフレームワークを開発するための取り組みです。このフレームワークはレジストリが特定のセキュリティ脅威に対処するための方法を明確化した任意の文書であり、法的拘束力を持つものではありません。

このフレームワークは、レジストリオペレータが当該脅威に対応する裁量を持たない場合（レジストリの管轄裁判所から発された裁判所命令による場合など）を考慮していません。また、レジストリに影響する合意ポリシーを反映することもありません。

スコープ

このフレームワークは、セキュリティ脅威の通知に対してレジストリが取るべき対処について定めています。

セキュリティ脅威に備えるためのレジストリアクションカテゴリ

レジストリオペレータのジェネリックトップレベルドメイン (gTLD) ポリシーまたは利用規約には、通常レジストリオペレータが取ることのできる各種対処法が定められています。これらのポリシーは適用可能な法的、運用的、および技術的要件に基づいて開発されており、要件はレジストリおよび管轄区により異なります。ポリシーは新しい状況に対処するため、並びに過去のセキュリティ脅威¹で学んだ教訓を反映するために、ROの裁量、および合意ポリシーと法的要件により改訂される場合があります。

このリストはすべてを包括したものではありませんが、ROの問題対処オプションが多数明記されています。

既存ドメイン名

• レジストラに問題を連絡

  ドメイン名のレジストラントと契約関係にあるのはレジストラであるため、多くの場合にROはまずレジストラに「問題を伝える」こととなります。レジストラには、一定期間を設けてセキュリティ脅威の調査と適切な対処を依頼すべきです。レジストラが問題への対処を渋る、一向に対処する気配がないなどの理由で、その後の行動が妨げられないよう注意が必要です。

• ドメイン名の保持により、解決不能に

  serverHold ステータスを適用すると、TLDゾーンファイルからドメイン名が消去され、パブリックインターネット上でのドメイン名解決が不能となります² 。こうすることで、何かミスがあった場合も容易に復旧できます。

• ドメイン名をロックし、変更不能に

  セキュリティ脅威への対処に使われることは稀ですが、ロックステータス³を適用するとドメインの移転・削除・詳細情報の修正が不能となります（解決は可能）。ネームサーバの停止に伴ってドメイン名がロックされた場合などに観察される状態です。

• ドメイン名のネームサービスをリダイレクト

  レジストリはドメイン名のネームサーバを変更することができます。ドメイン名のネームサーバを変更することにより、ドメイン名に紐付くサービスがリダイレクトされ、シンクホール（トラフィックログ）が行われます。これにより、救済対象となる層を特定することが可能となります。

• ドメイン名の移転

  適切な資格を有するレジストラにドメインを移転することで、ライフサイクル、EPPステータスコード、失効管理を行いながらも当該ドメインの活用を阻止できます。

• ドメイン名の削除

  ドメイン名の削除は、注意深く適正評価を行い、適切な機関からの指示がない限りは一般的に推奨されません。削除が不適切だとしてドメイン名を復元したいとなった場合、ドメイン名をserverHold状態にした時と比べてより負荷がかかってしまうことになります。ドメイン名を削除するよりも、ドメイン凍結などでセキュリティ脅威を緩和する方がよほど効果的です。レジストラントは、ゾーンからドメインがパージされた後にいつでもドメイン名を再登録することができます。

• 何も行わない

  これも立派な対処のひとつです。レジストリポリシーでは特殊な状況下でのアクションが制限されている場合があり、その他の対処方法が見つからない場合は基本的に何も対処をしないことも多々あります。ROが「発覚した問題はセキュリティ脅威ではない」、もしくは「対処をすると、脅威よりも深刻な結果を招く」と判断した場合も同様です。通例として、ROはセキュリティ脅威の報告者に「報告されたセキュリティ脅威への対処法とその理由」を伝える必要があります。

未登録（DGAタイプ）ドメイン名

セキュリティ脅威は、まだ登録されていないドメイン名に関連する場合もあります。これは、自動ドメイン生成アルゴリズム (DGA) の結果として、ボットネットにより生成されたドメイン名について発生することが多いとされています。多くの場合、数千以上のドメイン名に脅威が広がる恐れがあります。

• ドメイン名の作成

  悪意のあるドメイン名を意識せずに登録してしまうという場合もありますが、これが監視された条件下でなされた場合は、コンピュータ緊急事態対策チーム (CERT) などのリサーチャーおよび公共安全機関が当該ドメイン名に対して適切な対処（シンクホール⁴など）を行うことができます。上記の移転オプションと同じく、これによって被害を受けるコンピュータを特定し、脅威の拡散を緩和できます。また、以下のブロックオプション⁵と同様に、悪意のあるユーザーによるドメイン名の利用は拒否されます。

  ROは通常、過去の未登録ドメインを適切な資格を有するレジストラまたはRO内部のレジストラのいずれに委任するかの決定権を有しています。ROは自身のレジストリ契約における特定契約条項に関して、ICANNより適切または必要な免除を要請する必要があります。これは現在、ICANNの「Expedited Registry Security Request (ERSR)」プロセスにて実施されています。免除の発効時期はICANNでの処理内容により異なります。

• ドメイン名登録のブロック

  合意に基づき、ROは要求されたドメイン名を予約することができます。要求者はROと連携し、必要に応じて適切なブロック期限を設定する必要があります。

セキュリティ脅威の報告

個々のROにとってソースの信憑性評価が重要となる一方で、セキュリティ脅威の深刻度についても階層が存在します。ROは過去の報告はもちろん、ソースの報告により提供された情報の質と水準に常に注意を払う必要があります。深刻度の定義と迅速に取るべき行動の内容はROのポリシーと決定に準じますが、基本的にはRO所在国、またはROが属する管轄区の裁判所命令により要求が出された国の法執行機関 (LEA) により正確に発行された報告に基づくものとします。

1. 司法当局を通じた報告

   報告者が政府系の法執行機関（国が定める法執行機関またはROが属する適切な管轄区におけるその他政府の公的安全機関を含む）である場合、このフレームワークではROに対し「当該報告の信憑性が極めて高く、最優先事項である」という認識を推奨しています。これらLEAからの報告は信頼性が高いものとして扱う一方で、ROはその内容が適切なセキュリティ脅威であることを調査し、情報元の妥当性を確認する必要があります。

2. RO認証ソースを通じた報告

   ROは独自の裁量により、国家認証機関やセキュリティ報告機関など、適切な分野において必要とされる専門知識を有する情報元からの報告を優先的に選ぶことができます。

3. その他ソースを通じた報告

   ROは公共の情報源から提供されたDNSの技術悪用などに関する報告に対して、必要に応じて適切に対処することが求められます。また適切な措置が取られていることを確認し、発覚した脅威に対して適切な認知を拡げることもROの役割です。これにはユーザー、一般市民、またROの技術分析により指名された者からの報告および要求を含みます。匿名の情報源から提供された報告についても、匿名だからという理由だけで無視すべきではありません。ROには匿名であろうとなかろうと、すべての報告に対して誠実に目を向け、提示されたメリットとエビデンスをきちんと受け止める姿勢が必要です。

レジストリの対応

以下の文章における「対応」とは、ROが自らのポリシーに基づいて実害があるとし、特定したセキュリティ脅威についての報告受領に伴って取るべきアクションのことを指します。これには、たとえば報告を提出した公的安全機関に「当該のセキュリティ脅威はROにより調査中」と返答するなどの行為も含まれます。

報告内容の受領に伴い、ROはまず「要求が現在処理中である」という受領確認の返答を迅速に行うことが求められます。最初の報告受領から24時間以内に、ROは当該要求の評価結果、その評価に基づき取るべきアクションの内容を可能な限り提供するよう努めるものとします。可能であれば、アクションの暫定スケジュールを提供するのも双方にとって有益です。

ROは自らのポリシーおよび以下の要素に基づく今後の対応に基づいて、当該要求を評価するものとします。

1. 優先度

   要求が明らかに「優先度高」にあたると判断された場合は、公共安全について特に複雑に考える必要はありません。「優先度高」は人命、重要インフラ、児童労働搾取などに関わる事象で、差し迫った脅威を与えうるものを指します。DNSへの重大な攻撃も「優先度高」にあたります。レジストリは社内のポリシーに基づいてこれらの判断を行う必要があります。DNS技術の悪用について「優先度高」に該当しないその他の事象は、すべてレジストリの悪用防止ポリシーに従って取り扱われます（レジストリが適切な法的裁量を有している場合）。

2. 報告の根拠

   各ROは社内ポリシーおよび確認プロセスに従って報告の根拠を精査し、疑問がある場合はその合法性を確認する必要があります。

3. 内容

   各要求の内容には検証が必要な情報やROへの特別要求などが含まれているため、すべての内容をくまなく精査しなければなりません。優先度が高い報告については、人命や重要インフラ、児童労働搾取などに脅威を与えうる明白な事実を添える必要があります。これら、ROへの特別要求を含む内容は、各ROの社内ポリシーに基づいて評価するとともに、必要に応じた救済ステップを検討していくものとします。

4. 責任の所在

   ROは特定のセキュリティ脅威の解決に対して、必ずしも最良の存在ではありません。それぞれのセキュリティ脅威を解決するにあたっては、まず適切な解決者を特定するのが一番の近道です。たとえば、悪意のある登録があった場合は、登録に関する問題に精通するレジストラまたはリセラーが解決者として最適です。システムがウイルスに感染してしまった場合は、レジストラントまたはそのホスティングプロバイダが当該システムへの管理者アクセスを維持しているため、この場合に最適な解決者となります。しかし、多くのレジストラントやレジストラに影響を及ぼす大規模な脅威については、レジストリオペレータが解決に適しています。

   要求が「優先度高」に該当し、合法かつ信頼できる情報源から提供されたものである場合、レジストリオペレータは受領から24時間以内に脅威の内容を確認し、脅威緩和のために今後取るべきステップを共有するものとします。事象が「優先度高」ではない場合、ROは24時間以内に（何も行動しない場合も含めて）今後の動きの詳細を返答することが奨励されます。ROは脅威の内容を分析してその結果を要求者に伝え、今後取る予定のアクションの理由（何も行動を起こさない場合はその理由）、またその他の機関により緩和政策を実施する場合はその旨を明確に伝えるものとします。

   また、ROは所属する管轄区内において、以下の能力を有する1社以上の競合する法執行機関（国家ハイテク犯罪ユニットなど）もしくは適切な公的安全機関と連携することが奨励されます。

   • セキュリティ脅威報告の評価
   • 適切な法執行機関および公的安全機関の選定および検証
   • ROおよび調査を担当する法執行機関従業員の間の調整

   ROはDNSの悪用を防ぐため、悪用されたドメイン名の情報をその他のROおよび競合する法執行機関に共有することが奨励されます。

5. プライバシーと機密性の尊重

   セキュリティ脅威の報告および解決策には、一般的にRO、法執行機関、または競合／関連機関によって個人を特定可能な情報 (PII) が含まれています。発覚したセキュリティ脅威に対応する際、ROは機密性、データセキュリティ、データ転送、データ保持の観点から、および各地域の法律、契約条件、法的要件などの範囲内でそれぞれのプライバシーポリシー、ベストプラクティスを尊重し、遵守するものとします。

   本フレームワークの再通知および更新は、ICANNのプロセスに基づき必要に応じて実施します。

---

¹ このフレームワークには、「gTLD内のドメインがファーミング、フィッシング、マルウェア、ボットネットなどのセキュリティ脅威にさらされているかを検証するため、定期的に技術分析を実施する」というレジストリオペレータの義務は定義されていません。また、レジストリオペレータに対して、「発覚したセキュリティ脅威および定期的なセキュリティチェックの結果として実施したアクションの数をまとめた統計報告」の作成を求めることもありません。このフレームワークは、必要となる定期技術分析においてレジストリオペレータ自身が発見したセキュリティ脅威への対応について定めたものではありません。しかし、レジストリオペレータはこれらのセキュリティチェックへの対応についても同様のフレームワークを適用することが可能です。

² 一般的に「凍結」といわれ、ドメイン自体を止めることなく、ROの管理下にある関連するDNSサービスを停止させることができます。

³ レジストリ「ロック」ステータスは、これら3つのEPPステータスの組み合わせとなります。

コード：serverTransferProhibited, serverDeleteProhibited, serverUpdateProhibited

⁴ 特定のサーバーに対する、悪意のあるダイレクトトラフィックを防ぐための技術として利用されています。

⁵ ログデータには個人を特定可能な情報 (PII) が含まれる可能性があります。これに伴う行為はすべて、ROが属する管轄区における適切な要件に従って実施しなければなりません。