不審メールの報告後、誰が何をする？分析・返信・対処の運用設計

従業員が不審なメールを報告してくれたら、まず受け付ける。そのうえで、誰が調べ、何を返し、必要な対処を進めるかを決めます。報告を増やす取り組みと、受ける側の改善は並行して進められます。

報告ボタンを配っただけでは、受け取った後の仕事までは決まりません。共有メールボックスには届いていても担当がつかない、分析結果は出たのに報告者へ返答されない、といった状態を避けるには、作業ごとの担当と完了条件が必要です。

この記事では、不審メールを受ける情シス・CSIRTの仕事を整理します。専任チームがある場合も、少人数で兼務する場合も、いまの窓口から点検できます。

報告する仕組みと、受け取る体制を一緒に考える

ヤグラへの導入相談では、報告先が組織ごとに分かれ、確認する体制が足りないため、報告を求める範囲を絞っているという課題がありました。別の相談では、分析結果を従業員に自動返信すると、内容の誤解による追加操作や二重報告につながらないか、という懸念も出ています。

前者は受付後の処理、後者は返答後の行動の問題です。同じ報告機能を導入する場合でも、確かめるべきことは異なります。

大切なのは、報告を減らすことではありません。不審に思ったら相談できる状態を保ちながら、調べる仕事と伝える仕事を整理することです。IPAも、訓練の目的の一つとして、多数の報告を受けてから対応が完了するまでの作業を確認する考え方を示しています。IPAの解説

受付から完了までを、5つの作業に分ける

以下は、ヤグラが提案する整理例です。一人が複数の作業を担当しても構いません。自社の手順に合わせて各作業の担当を決め、次の人へ何を渡すかも書き添えてください。

受付通知と、調査結果の返信を区別する

「受け付けました」は、安全性を確認したという意味ではありません。受付時は、報告へのお礼、確認中であること、追加で伝えてほしい情報、問い合わせ先を案内します。

調査結果の返信では、分かったことと、まだ確認できていないことを分けます。判断が保留なら、結論を急いで作るより、追加確認の内容と次に案内するタイミングを伝える方が、報告者も状況を把握できます。

利用者がリンクを開いた、情報を入力したなどの申告がある場合は、その情報を分析・対処担当へ引き継ぎます。メール自体の判定と、利用者の操作に対する確認は、別に必要になるためです。

返信文は、結果の名称だけでなく、次の行動まで読める形にします。例えば確認中の案内なら、「現在確認しています。すでにリンクを開いたり情報を入力したりした場合は、その内容をこの窓口へお知らせください」といった文面が考えられます。これは文面例なので、自社の手順や連絡方法に合わせて調整してください。

返答した後も担当側に作業が残る場合は、利用者への案内済みと、対応完了を分けて記録します。返信の速さだけを優先して、未確認の事項を完了扱いにしないためです。

調査をまとめても、報告者ごとの情報は残す

同じ事象の報告をまとめれば、同じ調査を繰り返す手間を減らせる可能性があります。ただし、件名が同じという理由だけで一つにまとめると、送信元やリンク先が異なるメールを混同しかねません。

例えば、これは架空の運用例ですが、似た請求連絡が複数人から報告されたとします。内容が同じかを確認したうえで分析を共有しつつ、各報告者の受信日時、操作の有無、返信先は残します。調査はまとめても、全員が同じ状況とは限りません。

自動化する範囲は、返答後に起きる行動から決める

受付記録や担当者への通知は、自動化を検討しやすい作業です。一方、結果をどう解釈してもらうか、どの処置を実行するかには、利用者の理解や社内の権限が関わります。

導入相談で管理者だけへの結果通知を希望された背景にも、利用者が分析結果を誤解しないかという心配がありました。自動返信を使うかどうかは、速さだけでなく、受け取った人が次に何をするかまで含めて決めます。

自動返信を使う場合は、少なくとも次を確認してください。

• どの条件なら結果を返し、どの条件なら人の確認へ回すか

• 判断材料が足りない場合に、確認中であることを伝えられるか

• 利用者がすでに操作していた場合の連絡先が分かるか

• 結論が変わったときに訂正し、必要な人へ再連絡できるか

AIが使われているかどうかだけで、この判断は決まりません。既存の製品や内製の仕組みで対応できる部分もあります。Microsoft 365にも報告先や結果通知の設定があり、一部の自動調査・通知にはDefender for Office 365 Plan 2などの条件があります。契約と設定を確認し、現在の運用で不足する部分を見極めましょう。Microsoftの公式説明

止まっている場所から、運用を直す

新しい仕組みを一式入れる前に、直近の報告を一つ選び、受付から記録までたどってみてください。どこで待ち、誰が判断に迷ったかが分かれば、優先する改善も具体的になります。

次の表もヤグラの提案です。自社の担当や連絡ルールに合わせて調整してください。

少人数の組織なら、普段の担当と、不在時に連絡できる相手を決めるところから始められます。営業時間外の報告をすべて即時対応すると約束する必要はありませんが、緊急の兆候があるときの連絡方法は、通常の受付と分けて周知します。

また、処置を依頼した時点で完了にしないことも重要です。メールの削除などが必要な場合、実施権限を持つ人へ引き継ぎ、その結果を確認します。すぐ実施できない作業は、理由と次の担当を記録に残します。

部内で一巡させ、報告する側と受ける側の両方を確かめる

ヤグラの導入支援でも、報告ボタンを対象部署へ広げる前に、社内周知と部内テストを行う段取りがありました。小さく試すときは、ボタンを押せることに加えて、その後の作業まで確認します。

テスト用のメールで、受付通知が届くか、担当が引き受けるか、判断保留を扱えるか、結果を返せるかを一巡させます。類似の報告が続いた場合や、担当が不在の場合も、机上で流れを確かめるとよいでしょう。

訓練と本物の報告が混ざる状況も考慮します。訓練期間中だからという理由で報告を一括処理せず、対象を識別できるようにします。従業員に追加操作を求める場合も、社内で承認した確認手順に沿って案内します。

報告率とあわせて、未完了と待ち時間を見る

報告件数が増えた理由には、報告の習慣が広がったことも、同じメールが広く届いたことも考えられます。件数だけで、安全になったとも危険になったとも判断できません。

受け側の改善を確かめる指標として、ヤグラは次のような記録を提案します。

• 担当がついていない報告、判断を保留している報告の件数

• 受付から最初の返答まで、受付から必要な対応完了までの時間

• 担当者が実際に分析・返信・記録へ使った作業時間

• 追加確認、訂正、引継ぎ待ちが発生した理由

担当者の作業時間と、返答までの経過時間は分けます。分析が短くても、担当が決まらず待っていれば、報告者への回答は遅れます。平均だけでなく、長く残った報告の理由を見ると、次に直す箇所を見つけやすくなります。

集計では、報告した人数と、まとめて調べた事象の件数を分けます。複数の報告を一つの調査にまとめても、報告者が減ったように数え直さないようにしてください。

まずは今の窓口で、未完了の報告と次の担当を見えるようにする。そこから分析、返信、対処の順に改善し、従業員が安心して報告を続けられる運用へ育てていきましょう。

訓練全体の進め方は標的型メール訓練の解説、報告後の分析を支援する製品についてはPhishAIをご覧ください。

訓練で報告する行動を練習する場合は、フィッシング訓練の難易度を決める判断表も確認してください。

参考資料

• IPA「組織における標的型攻撃メール訓練は実施目的を明確に」（2017年7月31日）

• Microsoft Learn「User reported settings」