標的型攻撃メール訓練サービスの選定要件｜RFP・比較表に入れたい20項目

標的型攻撃メール訓練サービスを選定する際、テンプレート数や料金だけを比較しても、導入後の運用まで含めた違いは見えにくくなっています。

特に従業員600人以上の企業では、対象者の登録・異動対応、部署や役職ごとの訓練設計、最新の攻撃を反映する仕組み、不審メールの報告、SOC・CSIRTとの連携、継続的な効果測定まで含めて要件を定義する必要があります。

RFP（提案依頼書）や比較表を作る場合は、「その機能があるか」だけではなく、「どの条件で利用できるか」「どの程度自動化できるか」「何を根拠に評価できるか」まで確認できる項目にしておくと、製品デモだけでは見えない違いを整理できます。

すでに候補サービスを探している場合は、先に標的型攻撃メール訓練サービス比較で各サービスの特徴を確認し、その後、本記事の20項目を使ってRFP・比較表を作成すると整理しやすくなります。

結論：RFPでは「対応可否」だけでなく条件と確認方法まで指定する

RFPや比較表では、各項目を単純な「○・×」だけで回答させないことがポイントです。

例えば「Entra IDと連携できますか」という質問だけでは、手動インポートなのか、自動同期なのか、部署・役職変更まで反映されるのかが分かりません。

比較表には、少なくとも次の列を用意します。

Must要件を満たさないサービスを先に除外し、その後にShould要件を比較すると、機能数の多さだけで製品を選ぶことを避けやすくなります。

標的型攻撃メール訓練サービスのRFP・比較表に入れたい20項目

1～3：対象者管理は「登録できるか」より異動まで追随できるかを見る

従業員数が増えるほど、訓練メールを配信する機能より、対象者情報を継続的に正しく保つ運用の方が負担になりやすくなります。

CSVで対象者を登録できるだけでは、入社、退社、部署異動、役職変更のたびに管理者がデータを更新する必要があります。月次や四半期で訓練する場合、対象者管理が手作業のままだと、担当者の作業量だけでなく、退職者への配信や異動前の部署での集計といったミスも起きやすくなります。

RFPでは「ディレクトリ連携あり」だけで終わらせず、次の点まで確認します。

• どのIdP・ディレクトリ・人事システムに対応しているか
• 自動同期の頻度
• 入退社や異動を自動反映できるか
• 部署、役職、拠点、雇用区分などを訓練条件に利用できるか
• 管理対象から除外するルールを設定できるか
• グループ会社や複数テナントを分けて管理できるか

対象者の決め方については、過去のクリック結果だけでなく、役割、権限、外部との接点、扱う情報などを組み合わせる方法を標的型攻撃メール訓練の頻度と対象者の決め方で整理しています。

4～8：シナリオは「テンプレート数」より情報源・更新速度・難易度を見る

シナリオを100種類、1,000種類用意していること自体は、現在の攻撃への追随力を示すものではありません。

RFPでは、シナリオ数だけではなく、「何をもとに作っているか」「新しい攻撃をどの程度の期間で反映するか」を確認します。

情報源としては、例えば次のようなものがあります。

• 自社SOCやメールセキュリティ製品で観測した攻撃
• 独自の脅威インテリジェンス
• 顧客から報告された不審メール
• CERTや政府機関の注意喚起
• 公開されているインシデントや攻撃キャンペーン

「AIでシナリオを生成できる」という説明を受けた場合も、AIの有無だけで比較せず、AIが参照する情報と更新経路を確認します。

また、クリック率を継続比較する場合は、シナリオ難易度も確認します。NISTのPhish Scaleは、フィッシングメールの人間にとっての検知難易度を評価し、クリック率や報告率を解釈する際の追加指標として利用するための方法です。

同じ10％のクリック率でも、見抜きやすいメールと、業務内容に自然に合致した見抜きにくいメールでは意味が異なります。難易度を記録できるか、少なくとも比較するシナリオの条件をそろえられるかを選定要件に入れておくと、導入後の評価がしやすくなります。

詳しくは標的型攻撃メール訓練の効果測定方法－NIST Phish Scaleで解説しています。

9～11：配信機能は自社の攻撃リスクとメール環境に合わせる

メール以外にSMS、QRコード、電話などを使う攻撃もありますが、対応チャネルが多い製品を無条件に高く評価する必要はありません。

自社で実際に想定する攻撃と対象者を先に決め、その訓練を実施できるかを確認します。

例えば、SMSを業務でほとんど利用しない企業と、従業員が業務用スマートフォンで顧客とやり取りする企業では、SMS訓練の優先度が異なります。

配信面では、次のような項目を確認します。

• 部署ごとに異なる日時で配信できるか
• 全員へ同時送信せず分散できるか
• 海外拠点のタイムゾーンへ対応できるか
• 訓練の実施時期をランダム化できるか
• Microsoft 365やGoogle Workspaceで必要となる許可設定
• セキュリティ製品によるURL検査やサンドボックスが訓練結果へ与える影響
• 配信前にテスト送信できるか

訓練頻度についても「毎月できるか」だけではなく、対象者や攻撃リスクに合わせて変更できる設計かを確認します。

12～15：クリック後ではなく「報告→調査→対応」まで比較する

英国NCSCは、すべてのフィッシングメールを従業員が見抜くことを前提にせず、疑わしいメールを簡単・迅速に報告できる環境を整えることを案内しています。また、クリックした従業員を責める文化は、インシデントの報告を遅らせる可能性があるとしています。

そのため、RFPではクリック率だけではなく、不審メールの報告機能を独立した要件として扱います。

確認したいのは、例えば次の項目です。

• Outlook等からワンクリックで報告できるか
• 訓練メールへの報告を正しく記録できるか
• 本物の不審メールも同じ仕組みで報告できるか
• 報告率を取得できるか
• 受信から報告までの時間を取得できるか
• 報告後に担当者へ通知できるか
• SIEM、SOC、CSIRT、チケット管理システム等へ連携できるか

訓練を従業員教育だけで終わらせず、報告後の初動まで確認する場合は、標的型攻撃メール訓練を「インシデント対応訓練」に変えるで、初報から調査・封じ込めまでの時間を測る考え方を整理しています。

訓練後の教育についても、「クリックした人へ動画を見せられるか」だけでは判断しません。危険な操作の種類、過去の傾向、役割や権限などに応じて、教育内容や再訓練を変えられるかを確認します。

16～20：効果測定・セキュリティ・運用支援・TCOを最後に確認する

標的型攻撃メール訓練を継続運用する場合、導入時の機能だけでなく、1年後に改善を説明できるデータが残るかも選定要件になります。

最低限、次のような指標を比較できるか確認します。

• クリック率
• 添付ファイル操作率
• 認証情報入力率
• 報告率
• 報告までの時間
• 同じ対象者が繰り返し危険な操作をした割合
• 部署・役職・拠点ごとの差
• シナリオ難易度を考慮した推移

NIST SP 800-50 Rev.1は、サイバーセキュリティとプライバシーの学習プログラムをライフサイクルとして管理し、リスクや対象者の役割に応じた学習、評価指標、継続的な改善へつなげる考え方を示しています。

監査や経営報告で利用する場合は、画面上のダッシュボードだけでなく、期間別・部署別のデータを出力できるか、過去データをどの程度保存できるかも確認します。

管理画面とデータのセキュリティ

標的型攻撃メール訓練サービスには、従業員の氏名、メールアドレス、所属、役職、訓練結果などが登録される場合があります。

RFPでは、次の項目も確認します。

• 管理画面のSSO・MFA
• 管理者権限の分離
• 操作ログ
• 保存される従業員データ
• データ保存期間
• 契約終了時の削除方法
• データ保管場所
• 再委託先・サブプロセッサ
• インシデント発生時の通知条件

運用支援とTCO

同じサービスでも、自社でシナリオ設計から配信まで行う場合と、ベンダーへ運用を委託する場合では必要な工数と費用が異なります。

見積もりは対象人数だけで比較せず、次の条件をそろえて依頼します。

• 対象人数
• 年間の訓練回数
• 配信通数
• eラーニングの有無
• 不審メール報告機能
• SMS等の追加チャネル
• ディレクトリ連携
• API・SIEM等の連携
• 初期設定支援
• シナリオ作成支援
• 定例レポート・報告会
• サポート窓口

初年度だけでなく、次年度以降の更新費用やユーザー増加時の単価も含めてTCOを比較します。

RFPではMustとShouldを分ける

20項目すべてを必須にすると、候補サービスが必要以上に絞られたり、利用しない機能へコストを支払ったりする可能性があります。

例えば、ある企業では次のように分けられます。

Mustの例：

• 自社の対象人数へ対応できる
• 部署・役職別に対象者を分けられる
• 自社のIdPや人事情報と同期できる
• 不審メールの報告を記録できる
• 報告率と報告時間を取得できる
• 必要な管理者セキュリティ要件を満たす
• 監査・経営報告に必要なデータを出力できる

Shouldの例：

• SMS等のマルチチャネル訓練
• 高度な自動パーソナライズ
• SIEM等とのAPI連携
• ベンダーによるシナリオ設計支援

どの項目をMustにするかは、自社の訓練目的、既存システム、SOC・CSIRT体制、対象人数によって変わります。

「AI対応」は単独の選定要件にしない

最近はAIによるメール生成や個別教育を掲げるサービスも増えています。

ただし、RFPに「AI機能を搭載していること」とだけ記載すると、実際の運用価値を比較しにくくなります。

AIを評価する場合は、次のように要件を分解します。

• AIが何を参照して訓練メールを作るのか
• 従業員データをAIへ入力するのか
• 入力データがモデル学習に利用されるか
• 役割・権限・訓練結果のどの情報を使って個別化するのか
• 自動生成したシナリオを管理者が確認できるか
• 誤った内容や不適切なメールを防ぐレビュー機能があるか

「AI搭載」という製品ラベルではなく、自社が必要とする結果へ分解して比較します。

RFP回答後は2～3製品に絞ってPoCで確認する

RFPだけでは、管理画面の操作性、ディレクトリ同期、メール到達性、報告ボタン、レポート作成の工数などを十分に確認できません。

書面比較で候補を絞った後は、可能であれば同じ条件でPoCを実施します。

特にPoCで確認したいのは、次のような項目です。

• 対象者同期にかかる作業
• シナリオ作成・配信までの管理工数
• 自社メール環境での到達性
• 不審メール報告の操作
• 報告率・報告時間の取得
• レポート作成とデータ出力
• 管理者権限の使い分け
• SOC・CSIRTへの連携

PoCの具体的な評価方法は、標的型攻撃メール訓練のPoC設計方法｜評価15項目で整理しています。

RFP・比較表を作る際の記入フォーマット

実際の比較表では、次の形式にするとベンダーごとの差を残しやすくなります。

上記のMust / Shouldは例です。自社の環境に合わせて変更してください。

サービスごとの料金、対象者管理、シナリオ、報告機能、自動化などを確認する場合は、標的型攻撃メール訓練サービス比較と組み合わせると、候補抽出からRFP、PoCまでを分けて進められます。

また、RFPや比較・採点方法を社内で共有する場合は、標的型攻撃メール訓練サービスの比較・選び方－600名以上の組織向け選定ガイドも利用できます。

出典

• SP 800-50 Rev.1, Building a Cybersecurity and Privacy Learning Program – NIST
• The NIST Phish Scale User Guide is Now Available! – NIST
• Phishing attacks: defending your organisation – UK National Cyber Security Centre
• Four Cybersecurity Essentials for SLTTs – CISA