見出し画像

「自社と顧客を保護するためのセキュリティ対策~なりすましメールやフィッシング~」でのご質問への回答

この度は、8/29(火)「自社と顧客を保護するためのセキュリティ対策~なりすましメールやフィッシング~」にご参加いただき、誠にありがとうございました。

ウェビナー中にいただいたご質問への回答を致します。

Q1.レポートはどんな意味があるのでしょうか?
メール受信側で、受け取ったメールが、正規のものか迷惑メールかって自動収集できないですよね?

A1.前半のDMARCに関するレポートかと思います。
大きくは2つに分かれていて、統計情報のみである集計レポート。
もうひとつは失敗レポート、フォレンジックレポートと呼ばれるもの。
今日は紹介を割愛させて頂きましたが、実際に認証に失敗したメールのヘッダー情報や認証結果が含まれるものになります。
現在は前半で紹介した集計レポートがメインで流通してますので、そちらが活用しやすいかと思います。
失敗レポートについても流量が増えれば活用しやすくなるかと思いますが、様々な観点でセキュリティリスクもありますので、現在はあまり普及していないかと思います。
これらを使って正規のもの、あるいは迷惑メールかというのは、分析ツールを使うことによってある程度キャッチすることもできるかと思います。

Q2.送信元メールサーバの一覧の画面にサーバのIPアドレスが表示されるようですが、IPに紐づくサービス名もわかるのでしょうか?

A2.我々の製品ではIPアドレスベースでグルーピングした結果を表示していますが、IPアドレスに対応する送信元のドメイン名であったり、組織の情報あるいはそのサービスの名前も一部表示されるようになっていますので、例えば自社でクラウドサービス(Amazon,Sendgrid)ビジネス系のSaaSを利用している場合はドメイン名、組織名などが活かせると思います。

Q3.PHISHINET/25のトライアルを実施するために、準備する事はありますか?

A3.専用の申込みフォームをご用意していますので、必要事項をご入力ください。
1つ目は正規のサイトの情報(ドメイン名、URL)をご提供頂ければと思います。
2つ目は正規のサイトのブランド名(日本語のブランド名、または英語で表記されたブランド名)をご提供ください。
また今後はロゴ画像を提供して頂くとより検知数、検知精度も高まりますのでご提供頂ければと思います。

Q4.DMARCは相手側のメールサーバーが対応している必要があると聞きました。

A4.送信する側では、今日ご紹介したDNS上での設定が必要になりますが、
一方で受信メールサーバ側では認証する仕組みというのを取り入れなければなりません。
受信する側がDMARCに対応していないメールサービス、メールサーバーはDMARC認証が働かないと考えて良いです。
ですが、最近の受信メールサーバ、あるいはクラウドサービスというのはほぼ必須でDMARCの認証技術を導入してますので、ほとんどはDMARCに対応している、なりすましメールを認知できると考えて良いかと思います。
一方でほとんどはDMARCに対応しているけど、レポートの分析という点で言えば一部のメールサービスのみが対応しています。
Gmail,MicroSoftなどが対応しているのでそういったデータを分析に活用することになります。

Q5.メールサーバーはどのぐらいの割合が対応しているのでしょうか?

A5.パーセンテージについては我々はキャッチしていませんが、最近はコンシューマー(個人)が使用しているメールはほとんどがGmailや携帯キャリアのメールアドレスが多いかと思います。
Gmailは既にDMARCに対応していますし、携帯キャリアのメールアドレスについては最近はNTTドコモがDMARCに対応していますので、そういったところが対応しているサービスだととらえて良いと思います。
法人向けのメールサービスについてはMicrosoft365がメインでされているプロバイダーかと思います。Microsoft365を利用されている場合はデフォルトでDMARCの認証対応、そしてDMARCのレポートの送信にも対応していますので、国内の企業、一定の割合でDMARCに対応しているかと思います。

Q6.今後のロードマップに記載のテイクダウンリクエストは、どのような流れでサイトを閉鎖までもちこむ想定でしょうか?

A6.PHISHNET/25で今後提供を予定している、テイクダウンリストの機能については詳細はまだ決まっていませんが、Webのダッシュボードでボタンが出現して、そのサイトを閉鎖したい場合はそれをクリックしてリクエストを押してホスティング事業者に自動的に送信するような流れになるかと思います。
ですが、テイクダウンリクエストしたからと言って必ずしも閉鎖に持ち込めるかというとそこは保証できないかなと思いますし、フィッシングサイトの生存時間は非常に短かったりするので、閉鎖のリクエストをする前に既に閉鎖されているケースもあるかと思います。

Q7.PHISHNET25で確認できる偽サイトを検知する対象の元ドメイン数の上限などありますでしょうか。

A7.実際にお客様のブランド名、またはドメイン名については申告制になっていますが、特にそちらについてドメイン数の制限というのはございません。

Q8.DMARCをとりあえず始めるにあたってp=noneで設定すれば影響はでないでしょうか?

A8.DMARCを導入する際に皆さんポリシーをどう設定したらよいか、
影響はないか心配されますが、今日ご紹介したポリシーのp=noneを設定頂ければ基本的にはメールの到達性には影響しないと思いますので、まずはp=noneから導入、どういった状況になるかをキャッチすると良いと思います。

Q9.Quarantineに設定したことによって、正規のメールが届かないといった誤検知が起きえますが、そのメールは受信側には、「迷惑メール」に分類されているのでしょうか

A9.Quarantineというのは隔離措置と言うように表現されていますが、
実際にどう取り扱われるかというのは基本的には受信側の仕様よるかと思います。ですので、迷惑メールフォルダに隔離する場合もございますし、件名などに迷惑メールであることを示す文字が付与されたりするケースもあるかと思いますので、特に一因で決まっているものではないかと思います。

Q10.Phishnet/25は自社の顧客の診断に活用可能でしょうか?

A10.自社の顧客というのは利用者(個人)を指しているのか、あるいはセキュリティのベンダーでマネンジメントサービスを展開している場合とあるかと思います。
前者の利用者(個人)に対して保護になり得るかと言えば、フィッシングサイトの注意喚起などをアナウンスするであったり、テイクダウンのリクエストをすることによって結果的にエンドユーザーを保護することになるかと思います。
後者のいわゆるMSSP(マネージドセキュリティ)のプロバイダーに関して言うとそういったお客様もこのサービスのターゲットとしていますので、自社の顧客企業を保護する観点でPHISHNET/25は非常に有効なサービスと言えるかと思います。

Q11.DMARC設定をquarantineで設定した際、隔離されたメールはどこ(送信ドメイン側?受信ドメイン側?)に保存されるのでしょう。
もし、受信者側で保存の場合、隔離できる環境がない際はどのような動きになるのでしょう。

A11.DMARCに対応していてポリシーがQuarantineの場合の取り扱いになるかと思いますが、いわゆる迷惑メールフォルダー、そういった機能を持ってる場合は恐らくは隔離されるというのは迷惑メールフォルダーに振り分けられることを指しているのだと思います。
そうでない場合は、件名に何らかの文字列が付与されたり、あるいはヘッダー上に認証結果が付与される。
具体的に Authentication-Results ヘッダーと呼ばれるヘッダーが存在していますので、そちらにDMARCの認証結果あるいは本来であればどう取り扱われるかなどが記載されるかと思います。

Q12.フィッシング対策強化の要請での対象ドメインは、「企業ドメイン」・「サービスドメイン」だとどちらになりますでしょうか?

A12.どちらが重要視されるかで言うとサービスドメインのほうがプライオリティが高いかと思います。ただ、コーポレートサイトをなりすます、これはエンドユーザーをだますというよりもそのブランド企業をおとしめるためになりすましたサイトが出現する場合もありますので、優先度としてはサービスドメイン、ただ両方対応したほうがベターかと思います。

Q13.DMARCのポリシーが既に受信拒否(reject)にできている、クレジットカードさんの事例はありますでしょうか?

A13.rejectになっているところはないかと思いますが、多くのクレジットカード会社さんは既にDMARC対応してQuarantineに設定しているところはいくつかあったと思います。