【要点抽出】フィッシング対策ガイドライン
2023年の情報セキュリティ10大脅威 個人部門1位は「フィッシングによる個人情報等の詐取」です。そんな困りごとへの対策ガイドラインを読んでみました。
何の本？
名前の通りフィッシング対策のノウハウをまとめたものです。
フィッシング対策協議会は、2005年に設立された、フィッシング対策に関する情報交換や対策を推進する団体です。
JPCERTが事務局となっており、執筆時点で126社が参加しているようです。
協議会には6つのワーキンググループがあり、本書は技術・制度検討WGにてまとめられたものです。
本書はフィッシング対策協議会のサイトで確認できる範囲でも2011年度があり、少なくとも10年以上のアップデートを続けられてきたものです。
構成は？
附録を除くと全36ページです。
目次以下の通りで、メインコンテンツは4章です。
1章 はじめに
2章 フィッシングに関する基礎知識
3章 フィッシング対策ガイドライン重要5項目
4章 WEB サイト運営者におけるフィッシング対策
目次上は5章 利用者におけるフィッシング対策もありますが、今回はこの内容は別の「利用者向けフィッシング対策ガイドライン」を見てねという記載のみなので割愛します。
2022年度からの変更点
最初に2022年度版と比較して変わった点を書きます。
主要な変更点
EV証明書が高い信頼性を得られる旨の記載が消去
BIMIに関する記載が追加
（22年度版でも書いていないわけではなかったが、だいぶ強調された）DMARCについて「reject」の重要性をより強調する形に
「4.5 フィッシング発生時の対応」の要点として、テイクダウンよりもURLフィルターへの登録を急ぐ旨が追加
構成面の変更点
5章「利用者におけるフィッシング詐欺対策」の内容が無くなり、利用者向けフィッシング詐欺対策ガイドラインへ誘導。本書はWebサイト運営者の対策に特化した形に
Webサイト運営者が考慮すべき要件が34個→29個に減
2022年版 要件7「Webサイトの正当性に係る情報を十分に提供する画面とする」が廃止
2022年度版 要件33「端末の安全性を確認すること」が廃止
2022年版 要件27,28が 2023年度版では要件24として一本化
2022年版 要件4「Web サイト運営者が利用者に送信するメールはテキスト形式とする」が要件3に統合
2022年度版 要件25「フィッシング詐欺発生時の行動計画を策定すること」が要件21に統合
その他の変更点
利用者向けのフィッシングの注意喚起について、知識のない人にも伝わるように分かりやすい表現を求める記載が追加
「4.3 フィッシング被害の発生を抑制するための対策」の冒頭に、フィッシング攻撃の6つの行動についての解説が追加
要件9 求める注意喚起の項目例に、公式アプリの利用やURLフィルタ、迷惑メールフィルタ等の利用を促す記載が追加
要件10 複数要素認証を突破する手法への対策が具体化。ワンタイムパスワードを求める目的をユーザに伝えること、WebAuthnへの言及。
要件20 廃止したドメイン名を第三者が取得してしまった後に、そのドメインを取り戻すことの困難さを解説する文章が追加
要件29 22年度版で求めていたバウンスメールの監視に加えてDMARCレポートの監視も追加となり、△→◎に変更
「4.5.4 フィッシングメール注意勧告」の中に、注意喚起の際の推奨事項とNG事項が記載
2章 フィッシングに関する基礎知識
基本的なフィッシングの手口は、以下の流れです。
攻撃者が正規のWebサイトのコンテンツをコピーして偽サイトを作る
利用者に対して偽サイトに誘導するようなメールを送る
利用者がそのメールに釣られてアクセスし、個人情報やパスワード等を入力する(場合によってはマルウェア感染も）
攻撃者がその情報を入手する
フィッシングにSMSを用いる場合は、上記の手法以外にも、利用者に電話かけさせて不正送金を狙う手法もあります。
正規の組織が普段利用者にSMS通知する際に、国際網を利用したSMS配信や携帯電話からのSMS配信を行っていた場合、攻撃者にとってはなりすましやすいターゲットになります。
逆に、国内直接接続でのSMS配信は比較的安心できるようです。
3章 フィッシング対策ガイドライン重要5項目
以下が挙げられていますが、4章と重複するのでそちらでまとめます。
利用者に送信するメールには「なりすましメール対策」を施すこと(要件1,2,4)
複数要素認証を要求すること(要件10)
ドメインは自己ブランドと認識して管理し、利用者に周知すること（要件19,20)
すべてのページにサーバー証明書を導入すること(要件6)
フィッシングについて利用者に注意喚起すること(要件21,22,25,26)
4章 WEB サイト運営者におけるフィッシング対策
本題のフィッシング対策の要件です。
そもそもフィッシングは、攻撃者と利用者の間で成り立ってしまうために、正規のWebサイト提供者が直接的にその攻撃を止めることはなかなか出来ません。それを踏まえた上で、可能な限りの利用者保護をしましょうという考え方が前提となります。
本書では、フィッシング対策を抑制策、検知策、発生後の対応策に分けて紹介しています。
全29要件に対して「◎：実施すべき / 〇：実施を推奨 / △：必要に応じて実施」の3分類がされています。
(ただし、△は22年度までありましたが、今回はありません）
なお、全29要件でカバーされるのは抑制策と検知策であり、発生後の対応策は要件とは別として書かれています。
フィッシング被害の発生を抑制するための対策
＜利用者 が正規メールとフィッシングメールを判別可能とする対策＞
[要件1] 利用者が確認できるように利用環境と分かりやすい説明に配慮した上で、どのように確認すればいいのかを分かりやすく端的に説明すること
せっかくBIMIによるロゴ表示やS/MIMEによる署名を行っていても、そのことが利用者に伝わらないと意味がないので、しっかりロゴや署名の確認方法を伝えてねというものです。
また、S/MIMEの電子署名をやるなら全ての送信用メールアドレスにやりなさいとも書いてあります。
[要件2] 外部送信用メールサーバーを送信ドメイン認証に対応させること
メール送信時にはSPF、DKIM、DMARC、BIMIの活用を求めています。
特にDMARCとBIMIは23年度版からより重視されており、DMARCについては受信制御ポリシーをnoneのまま運用せずにrejectにしてくれと強調しています。
[要件3] 利用者へのメール送信では、制作・送信に関するガイドラインを策定し、これに則って行うこと
自社が様々なメールを送るときに、ガイドラインを作っておくことを求めています。
このガイドラインの通りにメールが送られると、自然と「この会社からくるメールはこんな感じ」という統一感が生まれ、その企業を模した偽メールが来た時に利用者が「何かいつもと違う」と気づくことを期待しています。
また、できればメールはHTMLではなくテキストメールを推奨しています。
[要件4] 利用者に送信するSMSには国内直接接続の配信、または、RCS準拠サービスを利用すること
2章に記載の理由から、国内直接接続のSMS配信を求めています。
また、RCS(Rich Communication Service)はSMSの次世代版の位置づけであり、事業者が携帯キャリアから認証を得たことを示す「認証済マーク」が表示できるようです。
[要件5] 利用者に情報発信する手段および内容を周知すること
「当社がお客様にご連絡をする際はメールと郵送を使います！」とか、
「当社がお客様のパスワードを聞くことはありません！」みたいなことを明確にしておくことを求めています。
＜利用者が正規サイトを判別可能とする対策＞
[要件6] すべてのページにサーバー証明書を導入すること
HTTPS化するとともに、HTTPを無効化してHSTSの設定を求めています。
[要件7] パスワード強度に関するポリシーを利用者に示すこと
利用者にパスワードを設定させる際、「あなたが設定しようとしているパスワードの強度は高/中/低」みたいな強度が分かるようにしてあげてね、とあります。
事前に定めたパスワードポリシーを満たさない場合は、注意を表示したり受け付けないようにする必要があります。
[要件8] 色々なチャネルで利用者に対する脅威の状況を提供する
正規のWebサイト上やSNS、メルマガにて「最近当社を騙ったフィッシングが流行っています」みたいな情報を利用者に伝えることを求めています。
＜フィッシング被害を拡大させないための対策＞
[要件9] 利用者に端末を安全に保つよう、注意を促すこと
利用者に対して、各種セキュリティパッチの適用や、URLフィルタやメールフィルタ等の利用、公式アプリ利用を求めるなど、不正サイトへ誘導されないための対策を促しましょうとあります。
[要件10] 複数要素認証を要求すること
フィッシングには多要素認証が有効です。
ただし、最近は2要素目であるワンタイムパスワードさえも盗まれる事例が増えてきていることから、「当社がワンタイムパスワードを求めるのはこういう時だけです」を明記しておくとか、FIDO2のWebAuthnの導入についても推奨事例として書かれています。
[要件11] ポイントや資産の移動に限度額を設定すること
攻撃者はフィッシングの先にポイントの窃取や金銭の振り込みを狙いますので、そうした機能は1回あたりと1日あたりの上限値を設けることを求めています。
[要件12] ポイントや資産の移動時に利用者に通知を行うこと
要件11と同様の理由から、こうした操作が行われたら利用者にメールで通知しましょうとあります。
[要件13] 利用者の通常とは異なるアクセスに対しては追加のセキュリティを要求すること
リスクベース認証の導入を推奨しています。
[要件14] 登録情報を変更するページへの移動には再度認証を要求すること
利用者情報の登録や削除の際には再ログインを、できれば多要素認証を求めましょうとあります。
[要件15] 重要情報の表示については制限を行う
たとえログイン後の画面であっても、クレカ番号などはマスクして一部だけを表示することを求めています。
[要件16] 認証情報は厳格に管理すること（アカウントは不必要に発行しない）
タイトルの通りですが、サービスの内容によっては自社でアカウント管理をしなくて済む意味から外部サイトの認証に頼ったSSOとすることも有効とあります。
[要件17] アクセス履歴の表示
利用者自身が過去のアクセス日時やアクセス元IPアドレスを確認できるようにすることを求めています。
＜ドメイン名に関する配慮事項＞
[要件18] 利用者の認知しているWebサイト運営者名称から連想されるドメイン名とすること
Webサイトやメール送信時に用いるドメインについて、その企業が普段使っている呼称を用いて、co.jpのドメイン名にすることを求めています。
[要件19] 使用するドメイン名と用途の情報を利用者に周知すること
Webサイトとメール送信時のドメインをあわせた上で、「当社の正しいドメインはこれです！」と利用者に周知することを求めています。
その際、Webサイトに書いておくだけでは分からない利用者もいるため、郵便、新聞、テレビCMなど様々な手段を駆使すると良いとのことです。
[要件20] ドメイン名の登録、利用、廃止にあたっては、自社のブランドとして認識して管理すること
企業内のバラバラの部門がバラバラにドメインを申請しまくると、セキュリティ面でもブランド維持の面でもデメリットがあります。
そうならないように、管理者や管理ルール・手順をしっかり定めておくことを求めています。
「管理」とは、命名規則など以外にも以下の技術的考慮点も含みます。
・ドメイン乗っ取りを防ぐためのレジストラのサービスを活用する
・ドメイン管理サービスから届く重要連絡を確実に受け取れるように連絡先を保つ
・ドメインが不要になっても数年間は持ち続けてから廃止し（ドロップキャッチ対策）、DNSのCNAMEレコードを削除(サブドメインテイクオーバー対策)する
＜フィッシングへの備えと発生時の対応＞
[要件21] フィッシング対応に必要な機能を備えた組織編制とすること
一般のセキュリティ事案と同様に、IT部門やセキュリティ部門だけでなく、広報やコールセンター等の他部門とも連携する必要があります。
事前に役割分担や連絡体制を決めておく必要がある点も同様です。
[要件22] フィッシング被害に関する対応窓口を明記すること
フィッシングに気づいた利用者からの報告窓口を設けたり、金融系サービスでは即座にアカウントを停止できるような24時間の窓口を設けることを求めています。
[要件23] フィッシングの手法および対策に関わる最新の情報を収集すること
本書の附録にフィッシング関連情報を集められる情報サイトが掲載されています。CNET Japan、ITmedia、INTERNET Watch等です。
こうしたサイトから最新の攻撃動向についての情報収集を求めています。
[要件24] フィッシングサイトへの対応体制の整備をしておくこと
フィッシングサイトを見つけたらテイクダウンよりも、まずはURLフィルタに登録することを求めています(理由は後述)。
このURLフィルタとは、自組織のプロキシ等で運用しているフィルタの話ではなく、セキュリティソフトやWebブラウザベンダに申告することで、そのソフトやブラウザを使う一般の利用者が少しでも早くアクセスできなくなることを目指すものです。
＜利用者への啓発活動＞
[要件25] 利用者が実施すべきフィッシング対策啓発活動を行うこと
タイトルの通りですが、利用者に専門用語を使っても分からないからやさしく教えてあげて！とあります。
[要件26] フィッシング発生時の利用者への連絡手段を整備しておくこと
フィッシングが行われている旨を利用者に注意喚起するための連絡手段は事前に決めておく必要があります。
メールで知らせるなら事前にメールアドレスを抑えておく必要があるし、場合によっては電話番号や住所も必要です。
また、公式アプリは利用者に安全な手段で連絡できる手段と考えられるので、活用できると良いそうです。
フィッシング被害の発生を迅速に検知するための対策
[要件27] Webサイトに対する不審なアクセスを監視すること
自社Webサイトの各種ログを分析し、いつもよりログイン失敗が明らかに多いなど不審な兆候を見つける方法や、faviconやバナーファイル等へのアクセス状況を分析し、フィッシングサイト立ち上げを目的としたスクレイピングの通信を見つけることが推奨されています。
[要件28] フィッシング検知に有効なサービスを活用すること
フィッシングサイトの発生を24時間監視し、見つけたらURLフィルターへの登録やテイクダウンを行うサービスがあります。
あるいは、自組織のドメイン名に似たドメインが生まれたら発見してくれるようなサービス(多くはASMツールの一部だと思います）もあるので、活用を求めています。
[要件29] DMARCレポートやバウンスメールを監視すること
フィッシングが起きていることを発見できる可能性があるため、DMARCの集約レポートや失敗レポート、あるいは宛先不明時に返されるバウンスメールを分析することを求めています。
フィッシング被害が発生してしまった際の対応と対策
29の要件はここまでです。
発生後の対応については、以下5つのステップが紹介されています。
多くはインシデントハンドリングと同じですが、フィッシング対応ならではの動きとしてURLフィルタ登録やテイクダウンがあります。
ただし、フィッシングサイトは短期間で閉鎖されることが多く、テイクダウンは間に合わないことが多いようです。だからこそスピーディなURLフィルタ登録を重要視しています。
フィッシング被害の発見
フィッシング被害状況の把握
ここでは大きく「フィッシングサイトの危険性確認」と「フィッシングメールの流通量確認」を行います。
「フィッシングサイトの危険性確認」とは、対象のサイトがどれだけ自社サイトに似せてあるのか等、利用者を騙せそう度合いを判断します。
「フィッシングメールの流通量確認」とは、DMARC集約レポートを分析することでなりすましメールの量が把握できます。フィッシング被害対応活動
まずはURLフィルタへの登録、その後テイクダウン活動を行います。
テイクダウンは、Webサイト運営者自身がフィッシングサイトが稼働するISPに連絡を取る手段や、外部の専門サービスに頼る手段や、JPCERTなどの機関に頼る手段が挙げられています。組織の体力にあわせて選ぶことになると思います。
また、 フィッシングに気づいた利用者からの連絡が殺到する可能性があるため、対応窓口を設けて教育しておくとともに、発生時には速やかに利用者へ通知する必要があります。
ここでは注意喚起における推奨事項とNG事項が挙げられています。
推奨事項はユーザに寄り添った案内をすることなので割愛しますが、NG事項はそのまま引用します。
(最後の1点は推奨事項のような気がしますが…）
・ ユーザーに「URLが正しいかを判断させる」は困難
・ 「正しいメールアドレス・送信元の確認」も偽装できるため、NG
・ 「正しいドメインから始まるURLだから大丈夫」ではない
・ 利用者が誤ってクリックしないよう、フィッシングサイトのURLをそのまま掲載せず、無害化・画像化する
生じたフィッシング被害への対応
フィッシングを受けた利用者の具体的な被害を確認し、被害拡大しないための対策をとるとあります。
具体的には書かれていませんが、パスワード変更を利用者にしてもらう、クレジットカード番号を変えてもらうといったことかと思います。事後対応
振り返りや再発防止策などを行います。
感想
自組織のWebサイトそのものの保護に比べ、攻撃者と利用者の間で直接的に行われるフィッシングへの対策は、守る側からすると直感的に「そこまでやらなきゃならんのか」と思ってしまう部分があると思います。
S/MIMEによる署名やDMARCやBIMIといったなりすまし対策はまだしも、利用者の目線に立ってやさしく注意喚起をするところなどは民間企業がどこまでやることなのか…インターネットは利用者の自己責任ではないのか…等。
ただ、そうは言ってもお客様を守る必要はありますし、ブランド毀損などのレピュテーションリスクにもつながるし、やはりやるしかないのが辛いところです。
サイバーセキュリティ経営ガイドラインで「セキュリティは投資である」と述べられているように、騙されてしまった利用者を安心させながら適切に対応できると、かえって企業にとっての好感度アップにもつながりでしょうから、やるなら神対応と言われるくらいの対応策を目指したいですね。
また、そうしたことに力を入れていることが攻撃者にも伝われば、フィッシングのターゲットになりにくくなるかも…しれません。
＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら
この記事が気に入ったらサポートをしてみませんか？