Cloudflareが新たに発表したフィッシングに関するレポートによると、同社が検出したブランドなりすましメール10億件の大半は、SPF、DKIM、DMARCのメール認証プロトコルを「通過」していた。
この統計は少し誤解を招く。メールが「通過」したのは、ブランド側自身による適用制御が欠けていたからにすぎない。メール認証プロトコルを適用するという、見落とされがちな重要な手順の欠如が、フィッシングメールが圧倒的多数のサイバー攻撃や詐欺の根本原因であり続ける大きな理由だ。
なりすましメールを実際に減らすには、顧客がなりすましによる金銭的な結果をベンダーに負わせる必要がある。ここでは、次のトピックを通じて詳しく見ていく。
DMARCの失敗に金銭的な結果をもたらす方法
組織がDMARCを適用しない場合、攻撃者はそのブランドになりすますことができる。組織の観点では、なりすましを防ぐための時間の投資は、たとえ小さなものであっても、投資に見合う利益をもたらさない可能性がある。
なりすまされた組織は結果を免れるため、なりすましメールの被害者が苦しんでも痛みを感じない。怒れる顧客がその痛みを共有し始めたときにのみ、変化が起きる。
問題：なりすまされた組織は結果を免れている
なりすましメールの結果として被害を受けるのは、多くの場合、従業員がなりすましメールにだまされる何百、何千もの企業、非営利団体、その他の組織だ。なりすましメールには迷惑なスパムが含まれることもあるが、より多いのはフィッシングメールがより危険なペイロードを送り、認証情報の窃取、ビジネスメール詐欺（BEC）攻撃、またはランサムウェア攻撃につながるケースだ。
被害を受けた組織には、自社ブランドのなりすましを許している組織から補償を引き出す手段がほとんど、あるいはまったくない。一方、なりすまされている企業には行動を変える金銭的な動機がない。
解決策：メールなりすましの痛みを共有させる
組織が行使できる唯一の影響力は、ベンダーに対するものかもしれない。顧客は、ベンダーが自分たちをリスクにさらしていることに怒り、取引関係の条件として、サプライヤーにSPF、DKIM、DMARCのメール認証プロトコルを実装・適用するよう求めるべきだ。
ベンダーは販売を成立させる必要があるため、顧客が競合他社に乗り換えないよう、合理的な譲歩をする。同時に、組織がベンダーからのビジネスメール詐欺やフィッシング攻撃に引っかかる可能性もかなり高い。実際、送信者に心当たりがなくても、買掛金担当者は「支払い期限超過の請求書」や「支払期限を過ぎた明細書」という名前の、ウイルスを含むPDFファイルを開いてしまう。
確かに、小規模な組織には影響力がない。しかし、中規模の政府機関やフォーチュン5000企業であっても、メール認証プロトコルを契約条件の1つにするよう簡単に要求できる。要求する組織にとって、そのような条項を契約に加えるコストはほとんど、あるいはまったくなく、メールなりすましのリスクを大幅に減らせる。
3つすべてのメール認証プロトコルを実装するには時間がかかるが、大きな費用はかからない。ベンダーがこうした要求に応じても、なりすましメールの痛みを自分たちに戻すだけであり、金銭的な損害を受けることはない。
メールは「通過」するのではなく、バイパスを許されている
Cloudflareは最近、初の フィッシング脅威レポートを発表し、スパム、メール脅威、悪意のあるメッセージの中で検出したブランドなりすましが10億件を超えたと報告した。SPF、DKIM、DMARCなどのメール認証プロトコルはブランドを保護するはずだが、Cloudflareによると、「望ましくないメッセージの大半（89%）がSPF、DKIM、またはDMARCのチェックを『通過』した」という。
Cloudflareは、約8億9000万通のメールに、受信者をだまそうとする偽のブランドなりすましが含まれていると100%正確に判断できる。しかし、確実に「通過」を引用符付きで表記しなければならなかった。なぜなら、メール認証チェックがなりすましメールを失敗扱いにするのは、ほとんどの企業が実装していない非常に限定的な設定の場合だけだからだ。実際には、3つのプロトコルすべての設定が不十分なため、なりすましメールの大半は、なりすまされた組織によって認証のバイパスを単に許可されている。
SPFプロトコル：なりすましは通過し、正規メールは失敗する
SPFはSender Policy Frameworkの略で、メールサーバーが認可されたメールサーバーかどうかを記録する。組織は自分のドメインにSPFファイルを設定し、そのドメインを代表してメールを送信する正規のメールサーバーを列挙する。
SPFは偽のヘッダーによってなりすますことができ、悪意のある送信者はそこに自分のメールサーバーを記載できる。メールサーバーは、メール本文や受信者に表示される「From」フィールドに記載された偽装ドメインと照合する代わりに、隠されたヘッダーを読み取り、攻撃者の悪意あるドメインのSPFを検証する。「From」フィールドと一致する必要はまったくない。
SPFファイルが保守されていない場合、正規のメールでもSPFに失敗することがある。ドメイン上の新しいメールサーバーから送信された正規のメールは、そのサーバーがSPFファイルに登録されていなければ、単純に失敗する。MailChimpなどのメールサービスでは、MailChimpのメールサーバーへのSPF参照が含まれる場合があるほか、組織のSPFファイルにMailChimpのメールサーバーを追加する必要がある。
DKIMプロトコル：なりすましは通過し、正規メールは失敗する
DKIMはDomainKeys Identified Mailプロトコルの略で、組織のドメイン上でホストされる公開暗号鍵に基づく暗号化ハッシュ値を使い、組織がメールにデジタル署名できるようにする。
SPFと同様に、悪意のある送信者は悪意あるドメインにDKIMを実装し、自分のドメイン上でホストする公開暗号鍵を使ってスパムに署名できる。メールサーバーは、一致を確認するために、ヘッダー内の暗号鍵やドメインと「From」フィールドに表示されたドメインを比較しない。
SPFプロトコルと同じく、HubSpotなど正規の第三者メール送信者や新しいメールサーバーの設定が不十分だと、DKIMの失敗につながる。DKIMはエラーなしで公開するのも難しく、単純なタイプミスによって、すべてのDKIMプロトコルチェックが失敗する可能性がある。
当社のSPFとDKIMガイドでは、プロトコルを適切に設定する方法を詳しく説明している。
DMARCプロトコル：なりすましは通過し、正規メールは失敗する
DMARCは扱いにくい略語だが、正式名称であるDomain-based Message Authentication Reporting and Conformanceプロトコルに取って代わる。DMARCは、メール本文で受信者に表示される「From」フィールドに記載されたブランドのドメインを、そのドメインに登録されたSPFおよびDKIMプロトコルと照合して検証する仕組みを提供する。
なりすましメールがDMARCを「通過」する方法は2つある。
1つ目は、「Amazon」になりすます際に「Amaz0n」や「Arnazon」のような類似ドメインを送信者が使う場合だ。悪意のある送信者は、悪意ある類似ドメインにSPF、DKIM、DMARCを設定し、技術的にはなりすましドメインではない詐欺ドメインで、3つすべてのチェックを正当に通過できる。
2つ目は、こちらがはるかに一般的だが、なりすまされているドメインでは、DMARCプロトコルがアクティブな適用用に設定されていないことが多い。標準的なプロセスでは、DMARCは「p=none」設定で導入される。この設定では、プロトコルが一致しない場合にどう対処すべきか、受信メールサーバーやメールセキュリティツールに何の指示も与えない。
多くの場合、デフォルトではこれらのメッセージが配信され、これがSPF、DKIM、DMARCの認証チェックを「通過」したメール89%の大部分を占めると考えられる。これは技術的にはDMARCを通過していない。なりすましメールはチェックに失敗しているからだ。しかし、企業向けDMARCポリシーの半数未満しか、適用のための「p=reject」または「p=quarantine」認証レベルを満たしていないため、多くのなりすましメールは失敗しても、そのままフィルターをバイパスできる。
組織が自ドメインを使うメールの正規の送信元を慎重かつ徹底的に確立・記録していなければ、正規のメールでもDMARCに失敗する可能性がある。多くの組織は、社内および第三者のメールサーバーすべてでSPFやDKIMを適切に設定できていないのではないかと懸念している。マーケティングメールが拒否される可能性を恐れ、なりすまされる組織は保守的になり、DMARCの適用を単純に避ける。
関連記事：DMARCが失敗する理由：DMARCに関する3つの問題
標準的なメール保護では不十分
一部のメールサービスでは、「p=reject」のメールでさえ、隔離フォルダーやスパムフォルダーへの配信をデフォルトで許可する場合がある。同様に、メールセキュリティツールも、重要なビジネスメールをブロックしないよう、通常は過度に寛容な設定になっている。
セキュリティチームは、メールサーバー、メールSaaSプロバイダー、メールセキュリティツール内の設定を調整し、メール認証プロトコルに失敗したメールを明示的に拒否すべきだ。組織は可能な範囲で行動し、DMARCの「p=reject」および「p=quarantine」設定を尊重するとともに、メール認証プロトコルを適切に適用している組織から、少なくとも何らかの優位性を得る必要がある。
関連記事：企業・ビジネス向けにメールセキュリティを改善する方法
結論：なりすましは主に不便さの問題である
ブランドになりすました8億9000万通のメールは、SPF、DKIM、DMARCのプロトコルが適切に適用されていれば、おそらく通過しなかった。緩い配信フィルターは過度に寛容になりがちで、なりすましの兆候をメールから分析する負担を、最も弱いリンクである技術に詳しくない従業員に負わせる。
メール認証を適切に適用するには時間がかかるが、大きな費用はかからない。企業はマーケティングメールが配信されないことで不便を被りたくないため、その代わりに、他者が自社になりすました攻撃の被害を受けることを許している。
顧客は今こそ怒り、可能なところで、つまりベンダーに対して反発すべきだ。ベンダーは現在、見込み顧客を失うことを懸念しているが、実際の顧客を失うことをさらに強く懸念するようになる。セキュリティに抵抗する代わりに、営業チームが組織全体を動かし、メールなりすましを止めるよう働きかけ始めるだろう。