妥協した DKIM 秘密キーを使用すると、攻撃者は影響を受ける署名ドメインで検証する署名を作成できる可能性があります。イベントを署名機関のインシデントとして扱います。 DNSレコードの置き換えは封じ込めの一部にすぎず、 DKIM検証だけでは、承認された署名者と同じキーを保持している攻撃者を区別することはできません。
影響を受ける当局を確立する
秘密キーを使用して、署名ドメイン、セレクター、キー管理者、およびすべてのサービスを識別します。シークレットをチケットやチャットにコピーすることなく、関連する監査ログ、構成、および代表的な不審なメッセージを保存します。発見時間、おそらく暴露時間枠、既知のものと疑わしいものを記録します。
秘密キーの盗難と署名サービスへの不正アクセスを区別します。アカウントへのアクセス権を持つ攻撃者は、そのアクセスが阻止されない限り、キーのローテーション後も署名を続ける可能性があります。 DNS管理の侵害は、独自の対応を必要とするもう 1 つの依存関係です。インシデント所有者の下でこれらの調査を調整します。
新たな悪用を阻止し、古い検証パスを取り消します
承認されたインシデント プロセスを通じて、影響を受ける署名ルートまたは資格情報を一時停止します。 RFC 6376空の p 値を公開することによる取り消しが許可されています。また、キーを削除すると、不在が表示されると正常に取得できなくなります。プラットフォームでサポートされている応答を選択し、正確な応答を確認します。 セレクタ とドメインを変更する前に。
失効はすべての受信者で即座に行われるわけではありません。キャッシュされたDNSデータと評価済みのメッセージにより、時間に依存する境界が作成されます。 DNSを変更すると、配信されたメールの署名が遡って無効になったり、不正なメッセージが受け入れられなかったことを証明したりすることは約束できません。
通常のローテーションのオーバーラップにより、キューに入れられた正当なメッセージの検証が保持されます。侵害中に、公開されたキーを検証可能にしておくことで、攻撃者の能力を保護することもできます。インシデント所有者は、日常的な重複スケジュールを自動的に適用するのではなく、メールの遅延に対する封じ込めを比較検討する必要があります。
クリーンなパスを通じて署名を復元する
漏洩の原因に対処した後、信頼できるサポートされているプロセスを通じて交換キーマテリアルを生成します。古い証拠と新しい証拠を区別できるように、新しくサポートされるセレクターを優先します。現在の暗号化要件を適用します。 RSA 署名の場合、 RFC 8301では rsa-sha1 ではなく rsa-sha256 が必要であり、少なくとも 2048ビット キー。
応答例: セレクター sales1 が公開され、その署名アカウントが含まれています。クリーンな署名者は sales2 を使用しますが、sales1 は取り消されます。新しい管理メールは sales2 で検証され、From と一致します。 sales1 で署名された遅延メールは失敗する可能性があります。この例では、インシデントの完了や普遍的な受信者の動作の保証ではなく、明示的なトレードオフについて説明します。
回復を検証し、不確実性を維持する
1 つのメールボックスだけでなく、影響を受けるすべてのルートをテストします。生のメッセージと信頼できる結果を保存し、新しいセレクターを検査し、確認します アライメント 侵害された資格情報によって署名が許可されなくなったことを確認します。暴露期間のプロバイダー ログと受信者レポートを確認します。レポートはすべての受信者を網羅しているわけではなく、各メッセージの送信者を証明しているわけではないことに注意してください。
封じ込め、 DNS観察、代替展開、顧客への影響評価のタイムラインを維持します。フォレンジック コピーをアクセス制御しておきます。残りの調査と修正されたキー保管またはアクセス障害のために、特定された所有者のみがインシデントをクローズします。新しい署名が成功すると、回復ルートが機能することが証明されます。それ自体では、以前の誤用の全範囲を確立するものではありません。
緊急事態の前に机上で運動をする
この合成タイムラインでは、サービス アカウント A が sales1 を保持し、クリーン アカウント B が sales2 を保持します。 0 分目に A を含めます。1 分目に sales1 の取り消しを公開します。 2 分の時点では、架空のリゾルバーには古いキャッシュされたキーがまだ残っているため、そこで古い署名が検証可能のままである可能性があります。 3 分目に、クリーン Sales2 ルートを開始します。 30 分時点で、 DNSのみからの回復を宣言するのではなく、ルートごとに受信結果とアクセス証拠を収集します。これらのタイミングは順序を示すものであり、約束された伝播間隔を示すものではありません。
この表には、古いアクセスの無効化、暴露原因の封じ込め、新しい鍵の公開、新しい署名の検証、新しい署名の調整という 5 つの必要な回復観察が提案されています。新しいメールが通過するが、古いアクセスが依然としてアクティブであるシナリオでは、回復ゲートに失敗します。 5 つすべてを満たすシナリオは、モデル化されたゲートを通過します。どちらの観測セットも合成されたものです。テーブルトップ プログラム、テナント、またはメッセージ テストは実行されませんでした。実際のインシデント発生中は、実際の封じ込め、キャッシュの観察、承認、メッセージのテストが依然として必要です。
未解決の各回復ゲートに所有者を割り当てる
記述されたケース KEY-01 では、置換セレクター sales2 がd=example.org,を使用して From sales@example.orgに対して整列された署名を生成するが、古いサービス アカウントはアクティブなままであると想定しています。インシデントの所有者は、回復を常にオープンにし、アクセスの封じ込めに対処する必要があります。メール管理者の署名テストが成功しても、そのギャップを埋めることはできません。古いリゾルバー キャッシュと過去の悪用範囲は不明のままです。アイデンティティと結果は、実際に実行されたインシデントではなく、教示の前提として規定されています。