非アクティブ化されたアカウントへのアクセス試行 Playbook の使用

次のステップは、非アクティブ化されたアカウントへのアクセス試行 Playbook で使用できるアクション、タスク、およびサブフローのウォークスルーを示しています。

始める前に

必要なロール：

• sn_si.admin
• flow_designer

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

手順

1. Playbook がトリガーされて実行が開始されたら、ステップ 1 で、非アクティブ化されたアカウントへのアクセスがアクティブなユーザーによって行われたかどうかを確認する必要があります。
2. ステップ2では、非アクティブ化されたアカウントへのアクセスの試行がアクティブな従業員によって行われたかどうかを確認する必要があります。

   図 : 1. 非アクティブ化されたアカウント Playbook へのアクセスが試行されました

   

3. 非アクティブ化されたアカウントへのアクセスがアクティブな従業員によって行われた場合は、次の手順を実行します。
   1. ステップ 3 では、ユーザーが非アクティブな従業員になる原因となったプロジェクトまたはテスト ケースがユーザーにあったかどうかを確認する必要があります。
   2. ステップ 4 で、ユーザーが非アクティブな従業員になる原因となったプロジェクトまたはテストケースがユーザーになかった場合は、IT サポートチームと協力して構成ミスを修正する必要があります。
      フローが終了します。
   3. 手順 5 で、ユーザーが非アクティブな従業員になる原因となったプロジェクトまたはテスト ケースがユーザーにある場合は、次の手順を実行します。
      1. ステップ 6 で、これまでの結果を文書化するための応答タスクを作成します。
      2. ステップ 7 で、インシデントの事後レビューを開始するための応答を作成します。

         ステップ 8 では、インシデントの事後レビューの後、フローが終了します。

4. 手順 9 で、非アクティブ化されたアカウントへのアクセスがアクティブな従業員によって行われなかった場合は、次の手順を実行します。
   1. ステップ 10 では、ユーザーのログインが成功したかどうかを確認する必要があります。
   2. ステップ 11 では、従業員がいつオフボーディングされたかを確認する必要があります。
   3. 手順 12 では、Splunk のイベントを調査して、期間中のユーザーのアクティビティを調べる必要があります。
   4. 手順 13 では、これまでの調査に基づいて、ユーザーがデータを盗み出したかどうかを判断する必要があります。
   5. ステップ 14 で、ユーザがデータを盗み出さなかった場合は、次の手順を実行します。
      1. 手順 15 では、IT サポート チームと協力してアクティブなセッションを終了し、アカウントを無効にする必要があります。
      2. ステップ 16 では、これまでの結果を文書化するための応答タスクを作成する必要があります。
      3. ステップ 17 では、インシデントの事後レビューを開始する応答タスクを作成する必要があります。

      ステップ 18 では、インシデントの事後レビューの後、フローが終了します。

      図 : 2. 非アクティブ化されたアカウントへのアクセス試行 Playbook の使用

      

5. 手順 19 で、ユーザーがデータを盗み出した場合は、次の手順を実行します。
   1. ステップ 20 では、悪意のあるユーザをロックアウトし、アクティブなセッションをすべて破棄する必要があります。
   2. ステップ21では、ITサポートチームと協力してすべてのアカウントを無効にする必要があります。
   3. ステップ 22 では、リソースが通常の状態に復元され、悪意のあるアクティビティがないことを確認する必要があります。
      必要に応じて、リソースを再イメージ化できます。
   4. ステップ 23 では、封じ込めを解除し、システムを運用標準に戻す必要があります。
   5. ステップ 24 では、タスクをクローズする前にインシデントの事後レビューを完了するための応答タスクが作成されます。