我々は今、定期的に成功の衝撃的な結果を目の当たりにしている。 プッシュ爆撃 攻撃が一般的な攻撃手法になるにつれて、その手口は巧妙化しています。今日、組織はより多くの多要素認証（MFA）プッシュボミング攻撃に直面している。攻撃者は次に、ユーザーのスマートフォンに届くプッシュ通知を要求することができる。
迅速な爆撃攻撃は、次の点に依存している。 「MFA疲れ」.予期せぬプッシュ通知を受け取ることは普通のことではないにもかかわらず、ユーザーはその要求を承認するかもしれない。ユーザーが正しい選択をして、最初にリクエストを拒否したとしても、メッセージに消耗したり混乱したりするかもしれない。たった一度の「allow」で、攻撃者は認証される。環境の構造やその他のセキュリ ティ管理によっては、脅威者は企業のアプリケーション、ネットワーク、ファイルにアクセスすることができる。我々は最近、以下の仕様について詳述した。 ID Plus というブログで、これらの攻撃を検知し、防御するために使用している。 MFAプロンプト爆弾攻撃からの保護.
MFA疲れへの対処は、ほとんどの組織にとって興味深いセキュリティ上の課題である。この種の攻撃は日常茶飯事ではないはずだが、もし発生したら、セキュリティ・チームはそれを知って対応する必要がある。攻撃を受けていることを意味するだけでなく、いくつかの認証情報がすでに漏洩している可能性も高い。迅速な爆撃は、発生率が低く、リスクが高いというカテゴリーに入ります。この記事では、セキュリティ・オペレーション・チームの視点から、この種の攻撃に対処するための基本的な方法を概説します。
プッシュ爆撃に備え、MFA疲労と闘うためには、人的要素から始める必要がある。
- ユーザーの意識.利用者は、意識するだけでは不十分である。情報提供を受け、警戒し、関心を持つ必要がある。しかし同時に、サイバーセキュリティに対する意識の醸成は、ユーザーにとって容易でなければ失敗する。年1回のセキュリティ意識向上トレーニングを受けることは、コンプライアンスのニーズを満たすかもしれないし、一定の効果は得られるかもしれないが、高度な攻撃に対抗するには十分ではない。ユーザーには、自分がコミュニケーションを開始したのでなければ、それは疑わしいと考えるべきだと伝えるべきである。ユーザーが適切なツールやトレーニングを受けていれば、チャンスはあるかもしれない。
- ユーザー教育。 不正なPush-to-Authリクエストを受ける可能性があること、そして、100回見た同じダイアログで自動的に「ok」をクリックしてはいけないことを、エンドユーザに知ってもらうようにしてください。このメッセージが一部の、あるいはほとんどのユーザーに届くように、セキュリティ・プログラムでは、ユーザーへの何らかの定期的なコミュニケーションと、そのコミュニケーションを持続させる方法を用意する必要があります。例えば、電子メールによるアラートを検討したり、すべてのユーザーがアクセスできる持続的なブログ・ページにアラートを掲載したり、他の会社の文書やセキュリティ・ランディング・ページにアラートへのリンクを追加したり、サイバーセキュリティ啓発月間のテーマにしたりすることが考えられます。
- ユーザーリソース。 MFA Fatigue攻撃やPrompt Bombing攻撃を成功させるには、攻撃者がすでにユーザーの認証情報を持っている可能性が高いことを覚えておいてほしい。より高度な攻撃者はスピアフィッシングを開始し、SMS、WhatsAppアラート、電話、または電子メールをユーザーに送信して、MFA Fatigueに混乱を加える可能性があります。ユーザーがこのような試みに対抗できるようになるには、問題を報告する方法に自信を持ち、ヘルプデスク、サービスデスク、セキュリティチームがどのようにユーザーとコミュニケーションを取るかを本当に理解する必要がある。繰り返しになるが、ここでの認識とは、毎年のトレーニングのことではなく、ユーザーへの継続的なコミュニケーションと、必要なリソースを見つける方法や物事がどのように機能すべきかの一般的な理解のことである。すべてのユーザーがすぐにサービスデスクに電話することを知っていて、サービスデスクが最新の文書を持っている場合、またはチームの誰かがこのリソースの存在を思い出し、それを見つけることができる場合であっても、組織は十分な位置にあります。
- ユーザーの行動 トレーニングを受けていないリソースのないユーザーは良いターゲットだ。ユーザーは、適切なツール（Teams、Slackなど）を介してサービスデスクへの連絡を常に要求し、最初に確認された連絡がなければ電話を受け付けないことを知っていますか？期待値を設定し、ユーザーが不明な場合に確認する方法を与えます。
要約すると、あなたのセキュリティ・プログラムについてこれらの質問をし、その答えを必要に応じてプロセスの強化に役立てるべきである：
- 予期せぬプッシュ認証リクエストを受けた場合、ユーザーはどうすればいいか知っているだろうか？
- ユーザーはセキュリティ問題を迅速に報告できるか？
- すべてのユーザーがサービスデスクへの連絡方法を知っていますか？
- サービスデスクは、セキュリティ問題への対応方法を知っていますか？
- ユーザーはセキュリティ・チームに直接連絡する手段を持っていますか？
- ユーザーは、サービスデスクがどのように合法的にコンタクトを取るのか、またそのメカニズム以外のコンタクトは信用すべきではないことを知っていますか？
- ユーザーは、連絡先が正当なものであるかどうかを確認する方法を知っていますか？
MFA疲れを防ぐ第一の方法は、MFA疲れを起こさせないことだ。パスワードを使わないことで、ユーザ名とパスワードのペアが何ヶ月も続くという主な攻撃ベクトルを排除することができる。プライマリファクターにFIDOを使うことを検討しよう。しかし、FIDOはまだすべての人にとって実用的ではないかもしれない。
セキュリティではよくあることだが、最善の技術的対策は多層防御である。以下に、考慮すべき点をいくつか挙げる。あなたの環境に最も適したものを選んでください：
- もしまだユーザー名とパスワードに頼っているのであれば、少なくともパスワード保管庫を導入しているか、あるいは最も機密性の高いアクセス用に完全なPrivileged Authentication Management（PAM）ソリューションを導入していることを確認してください。また、それが適切に使用されていることも確認してください。
- 認証情報が漏洩した疑いがある場合は、強制的にパスワードをリセットしてください。リセットを行うことで、今後のプッシュボムを防ぐことができます。
- パスワードを恣意的に変更することはベストプラクティスではないとはいえ（理由はいくつもある）、パスワードの変更を強制することで、漏洩した認証情報がプッシュボミングに簡単に使用できる時間を制限することができる。
- MFA 設定を見直し、アクセス・パターンが理にかなっていることを確認する。どんなに優れた MFA ソリューションでも、限定的な検証で過剰なアクセスを許可するような構成にすることは可能です。
- 常識的なパスワードのベストプラクティスも適用される。ユーザーを教育し、サービス間でパスワードを共有すべきでない理由を説明する。そうすることで、万が一漏洩が発生した場合でも、プッシュボミングの攻撃対象が限定される。
- プッシュ認証に頼りすぎている場合、または機密性の高いデータを保護する場合は、ソフトトークンまたはハードトークンを使用してワンタイムパスワード（OTP）の要求頻度を増やすことを検討してください。OTPリクエストは、攻撃シナリオでは攻撃者に見られ、ユーザーに届くことはありません。
偽のプッシュ認証リクエストをプログラムで検知するには、多くのことがうまく機能する必要がある。認証システムからのログが適切なレベルに設定され、適切なログコレクターに送られ、適切に解析され、適切なアラートを生成するためのコンテンツが用意されていなければならない。そこから、24時間365日体制で監視しているセキュリティ・オペレーション・センター（SOC）がこのアラートを受信し、次に何をすべきかの最新ランブックとともに認識しなければならない。これは簡単なことではありません。様々なツールやメカニズムによって労力を軽減することができますが、重要なのは、気になるログイベントを特定し、自分にとって重要な閾値を検討し、アラートを受け取ったときに取るべき行動を把握し、プロセス全体を検証する必要があるということです。
1回のプッシュ認証拒否に対して意味のあるアラートを出すことを検討し、ノイズが多すぎるようであればチューニングを下げるとよいでしょう。覚えておいてほしいのは、ユーザーがよく訓練されていれば、問題を非常に迅速に知らせてくれる可能性があるということだ。SIEMがログを解析してアラートを出し、SOCがそれを検知して対応するよりも速いかもしれません。バックアップ・プランを持ち、セキュリティと監視を何重にも重ねることは常に良いことだ。
ログ・イベントと攻撃に基づくwhat-ifシナリオをレビューする。適切なデータを特定し、受信できるようにする必要があります。最も関心のある項目として、プッシュ・リクエストを拒否したユーザーに特有のログ・イベントをチェックする。もう1つの関心項目は、放棄されたプッシュ認証リクエストです。
不正なプッシュ・リクエストを検知するということは、クレデンシャルの漏洩も検知している可能性が高いことを忘れないでください。つまり、ユーザーがプッシュ要求に「No」と言ったとしても、企業ネットワーク内にユーザー名とパスワードの組み合わせでアクセスできる場所があれば、すでに何らかのリスクにさらされている可能性があります。不正なプッシュ認証リクエストの検出があれば、漏洩したクレデンシャルの検出メカニズムとして機能します。
RSAのユーザーは、ID Plusがリスクベース認証やその他の機能をどのように使用しているかを見ることができます。 即座の爆撃を察知し、防御する.
プッシュボミングに対する適切な対応は、あなたが納得できる閾値に依存する。しかし、予期しないPush to Authenticateが1回発生しただけでも、ユーザーはセッションを切断され、パスワードの変更を余儀なくされるはずである。ただし、このような事態が発生する可能性は低い。念には念を入れて。パスワードを変更することで、特定のユーザー認証情報を使った将来的な攻撃の可能性も防ぐことができる。
パスワードが古くなってきたとはいえ、組織においてパスワードが MFA の一部になっているのであれば、パスワードのリセットを強制する信頼できるプロセスを開発し、文書化する。攻撃者がネットワークにアクセスできる時間が長ければ長いほど、被害は大きくなります。対応時間を考慮する。アラートを受信した場合、迅速かつ積極的に信頼できるチャネルでユーザーやその管理者に連絡を取り、電子メールのフォームレターなど、組織に適した連絡方法を決定して、ユーザーやその管理者に何が起こったかを知らせ、警戒を促します。コミュニケーションは、将来的なセキュリティ上の懸念に対して配当となる信頼を築く上で大きな役割を果たします。
プッシュボムは攻撃の一種であることを念頭に置き、貴社の環境に対する可能性とリスクに関連するプログラム全体において、プッシュボムへの対応に優先順位をつけるべきである。攻撃者が成功した場合、被害を抑え、迅速に復旧できるようにするためには、他のセキュリティ対策に頼らざるを得ません。
