みずほではお客様が安心してサービスを利用できるよう、多面的なセキュリティ対策を推進してきました。ますます増加・高度化するフィッシングメールへの対策もその一つです。

マーケティングメールには電子署名を用いてなりすましを検知できるS/MIMEを導入し、お客様がなりすましメールの被害に遭うリスクを減らしてきました。さらに、実際にみずほをかたるフィッシングサイトが検知されればテイクダウンを実施し、被害の防止に努めてきました。

しかし、こうした対策はどちらかというと、受信側での受け身の対策、事後の対策です。我々側からもっと能動的に、お客様を守る攻めのセキュリティができないかと考えていました。

そうしたタイミングで浮上してきた技術がDMARCでした。海外も含め多くの企業でDMARC導入が進んでいることも受け、みずほとしてのセキュリティ戦略の一つに取り入れ、2022年夏から本格的に導入に向けて動き始めました。

DMARCソリューションの選定に当たってまず重視したのは、市場での実績でした。可視化だけ行うnoneというポリシーでのDMARC導入によって認証に失敗したメールが届かなくなることは技術的にあり得ないとは言え、その懸念を払拭するためにも多くの実績を持つソリューションを導入することが重要だと考え、国内の金融機関がどういった手段でDMARCを導入しているか情報収集し、多くの金融機関で導入がされている2製品に絞込みを行いました。そこから、詳細な比較検討を実施し、特に可視化だけではなくポリシー強化の実績の多い「Proofpoint EFD」を採用することとしました。

もう一つ重視したのがサポート体制です。Proofpoiont EFDの導入において、英語での対応に加えて日本語でのサポートも得られることを重視していました。

コンサルティングやレポートを通じて、実績に基づく知見が得られる点もポイントでした。DMARCレポートでDMARC認証のPass率が100％になることは非常に稀なため、どこかで思い切ってquarantineやrejectへのポリシー移行を決心しなければなりません。その際に、Passできないメールの原因を仕様面から詳しく解説してもらえることに加え、他社での導入実績に基づくポリシー移行の判断基準のアドバイスが得られることが大きいと考えました。

障壁となったのは、ポリシーをnoneに設定する際のシステム所管部やビジネス所管部に漂う「メール送信に不具合が生じるのではないか」という懸念でした。一般的にはDMARCのポリシーがnoneであることが原因でメールが届かなくなることはありませんが、DMARCについてまだ十分に理解されていなかったことから、懸念が払拭されていませんでした。

ボトムアップでの取り組みと並行して、CISOの協力を得てIT部門のトップに話を通し、トップダウンでも推進していきました。ビジネス所管部が多数あることで不安の払拭に時間がかかり延期についても検討したこともありましたが、CISOからの後押しもあってプロジェクトを推進することができました。

ポリシーのnoneからrejectへの移行を検討し始めていたちょうどその頃に、GoogleとYahoo!が「メール送信者ガイドライン」を公表しました。この中でDMARCについても言及されていましたが、以前からの準備も相まって、DMARC導入におけるこの追い風にうまく乗り、対策を加速できました。

NRIセキュアからは、「すぐに導入できますよ」といった絵空事ではなく、技術に基づき、また実態に即して、地に足の付いた提案をいただけている点を評価しています。

メールはその仕組み上、誰でもみずほの名前を騙ることができてしまいますが、noneのポリシーとはいえDMARCを導入することで、どのサーバからみずほを騙るメールが送られているかといった情報が徐々に見えるようになってきました。

もちろん、DMARCを導入したからと言ってすべてのフィッシングメールが防げるわけではなく、あくまで多層防御の一つと理解しています。とはいえ、フィッシングメールや詐欺メールが横行する中、DMARCは金融機関に求められるセキュリティ要件として必須と言っていい技術であり、対策していなければ外部からの見る目にも影響します。今後は、DMARC認証をパスしたメールに対し企業やブランドのロゴを表示させ、類似ドメインや無関係なドメインから送られてくるフィッシングメールを見破りやすくするBIMI（Brand Indicators for Message Identification）の導入も検討しています。