可能なパスワードスプレー Playbook を使用する

次のステップでは、可能なパスワードスプレー Playbook で利用可能なアクション、タスク、およびサブフローのウォークスルーを示します。

始める前に

必要なロール：

• sn_si.admin
• flow_designer

Security Operations スポーク (sn_sec_spoke) がインストールされていることを確認します。

手順

1. Playbook がトリガーされて実行が開始されたら、ステップ 1 で、アクティビティが顧客の IP アドレスから発信されているかどうかを確認する必要があります。
   パスワード スプレー攻撃を実行している IP アドレスを特定します。たとえば、アラートの TXID (トランザクション ID) を使用して、F5 ログと照合します。
2. ステップ 2 で、アクティビティが顧客の IP アドレスから発生した場合は、次の手順を実行します。
   1. 手順 3 では、パスワード スプレー攻撃の可能性に関するインシデント後のレビューを開始する必要があります。
   2. ステップ 4 では、フローは終了します。
3. 手順 5 で、アクティビティが顧客の IP アドレスから発信されていない場合は、アラートの詳細から攻撃者のソース IP を特定します。
4. ステップ 6 では、オープンソース インテリジェンス (OSINT) ツールを使用して IP レピュテーションと、過去 7 日間のこれらの IP からのトラフィック パターンを検証する必要があります。

   図 : 1. 可能なパスワードスプレープレイブック

   

5. ステップ7では、パスワードスプレー攻撃を使用して正常にログインしたユーザー名を特定する必要があります。
6. ステップ 8 では、失敗したログインの数とパターンを特定する必要があります。
7. ステップ9では、真陽性の指標を特定する必要があります。
   • 過去 60 日間のソース IP からのトラフィックを確認します。履歴トラフィックは、真陽性を示すことはできません。
   • 認証失敗があるユーザー名パターンとカウントを確認します。カウントが大きいほど、真陽性である確率が高くなります。
   • ユーザー名は辞書ベース(AからZまで)のように見え、admin、sysadmin、rootなどの一般的な管理者名を持っている場合があります
   • 同じアラートがjohn.doe、johnd、jdoe、john_doe、jdoe7 などで失敗する可能性があるように、同じユーザー名でもスプレー攻撃のパターンが異なる場合があります。これは、攻撃者が一般的なユースケースに基づいてユーザー名パターンを推測していることを示しています。
   • 上記の手順の F5 ログのユーザー エージェントと URI に注目し、IOC が Red Condor アラートに関連しているかどうかを確認します。それらが一致した場合、それは真陽性のイベントです。
8. ステップ10では、これまでに行われた調査に基づいて、これがパスワードスプレー攻撃の可能性があるかどうかを確認する必要があります。
9. ステップ 11 で、これがパスワード スプレー攻撃の可能性である場合は、次の手順を実行します。
   1. ステップ 12 では、適切なチームと調整して、必要なアカウントをロックアウトし、悪意のあるアクティビティを調査する必要があります。

      図 : 2.

      

   2. ステップ 13 では、パスワード スプレー攻撃の可能性についてインシデント後のレビューを開始する必要があります。
   3. ステップ 14 で、フローは終了します。
10. 手順 15 では、これがパスワード スプレー攻撃の可能性ではないかどうかを確認する必要があります。
11. 手順 16 で、これがパスワード スプレー攻撃の可能性に当てはまらない場合は、次の手順を実行します。
    1. ステップ 17 では、これまでの結果を文書化する必要があります。
    2. 手順 18 では、パスワード スプレー攻撃の可能性に関するインシデント後のレビューを開始する必要があります。
    3. ステップ 19 で、フローは終了します。
12. ステップ 20 では、ピアおよび GIR マネージャーに相談してガイダンスを得る必要があります。
13. ステップ 21 では、タスクをクローズする前にインシデントの事後レビューを完了するための応答タスクが作成されます。