Playbook für fehlgeschlagene Anmeldung – Handbuch

Wenn ein Anwender bestimmte nicht erfolgreiche Anmeldeversuche (gemäß der SIM-Konfiguration) unternimmt, wird ein Security Incident erstellt.

Diese nicht erfolgreichen Anmeldeversuche können entweder falsch positive Ergebnisse sein oder Versuche von Angreifern sein, Zugriff auf Anwender-E-Mail-Accounts zu erhalten. In solchen Szenarien kann das Playbook „Manuelle fehlgeschlagene Anmeldung“ Anleitungen bieten und dazu beitragen, die Untersuchung fehlgeschlagener Anmelde-Security Incidents zu optimieren.

Voraussetzungen

Erforderliche Rolle:

• sn_si.admin
• flow_designer

Spoke: Security Operations-Spoke installieren (sn_sec_Spoke)

Wichtige Funktionen

Das Playbook für fehlgeschlagene Anmeldung umfasst die folgenden Funktionen zur Untersuchung von Security Incidents:

1. Überprüft, ob der betroffene Anwender ein aktiver/inaktiver Anwender ist
2. Filtert erkennbare Elemente in der Liste der zulässigen Elemente
3. Bereichert die erkennbaren Elemente
4. Führt eine automatisierte Bedrohungssuche durch.
5. Sendet eine automatisierte E-Mail an den Anwender, um den fehlgeschlagenen Anmeldeversuch zu bestätigen.
6. Weist dem Analysten Aufgaben zu, um den Anwenderzugriff zu untersuchen
7. Identifiziert schädliche erkennbare Elemente und blockiert IPs und URLs.
8. Setzt das Anwenderpasswort zurück.
9. Aktualisiert den Status des Security Incidents
10. Weist einem Sicherheitsanalysten Aufgaben zu, um die Überprüfung nach dem Incident durchzuführen.

Fähigkeiten erforderlich

• Bedrohungssuche (Virensumme, Hybridanalyse)
• Anreicherung erkennbarer Elemente (Whois, ReverseWhois)
• Sichtungssuche (Splunk, QRadar)
• Blockierung erkennbarer Elemente (Prüfpunkt, Palo Alto)

Weitere Informationen finden Sie unter ServiceNow-Store .

Sicherheitsanalysten-Experience

Informationen zur schrittweisen Lösung von Sicherheitsbedrohungen finden Sie unter Lösen Sie Sicherheitsbedrohungen mit dem Playbook.

Playbook für fehlgeschlagene Anmeldung mit Flow Designer-Fähigkeiten verwenden

Erste Schritte

1. Melden Sie sich als Anwender mit den Rollen sn_si.user und Flow_Designer an.
2. Navigieren zu Flow Designer > Designer Und klicken Sie auf Anmeldung Fehlgeschlagen playbook.
3. Erstellen Sie eine Kopie der folgenden Flows, um das Playbook für fehlgeschlagene Anmeldung zu kopieren und die erforderlichen Änderungen vorzunehmen. (Dies ist ein optionaler Schritt. Führen Sie diesen Schritt nur aus, wenn Sie planen, den Flow anzupassen oder bestimmte Änderungen daran vorzunehmen).
   • Fehler bei der Anmeldung – Manuelles Playbook V1
   • Fehlgeschlagene Anmeldung: Analysieren Sie die Antwort des Anwenders, und aktualisieren Sie die Antwortaufgabe V1
4. Nehmen Sie die erforderlichen Änderungen entsprechend Ihren Anforderungen vor. (Dies ist ein optionaler Schritt. Führen Sie diesen Schritt nur aus, wenn Sie planen, den Flow anzupassen oder bestimmte Änderungen daran vorzunehmen).
5. Aktivieren Sie die Playbooks.
   • Aktivieren Sie den Haupt-Flow, um das im Basissystem verfügbare Playbook zu verwenden.
   • Aktivieren Sie die kopierten Flows, nachdem Sie Änderungen gemäß Ihren Anforderungen vorgenommen haben.

Die folgende Abbildung zeigt eine Kopie des Playbooks „Manuelle fehlgeschlagene Anmeldung“. Überprüfen Sie die folgenden Schritte, um ein Verständnis der verschiedenen Aktionen im Playbook zu erhalten.

Dieses Playbook wird ausgelöst und dem Security Incident zugeordnet, wenn die folgenden Bedingungen erfüllt sind:

• Kategorie ist „fehlgeschlagene Anmeldung“
• Hat mindestens einen betroffenen Anwender
• Security Incident wurde nicht geschlossen oder abgebrochen

Die folgenden Schritte führen Sie durch die Aktionen, Aufgaben und Subflows, die im Playbook „Manuelle fehlgeschlagene Anmeldung“ verfügbar sind.

1. Wenn die Ausführung des Playbooks beginnt, wird das Playbook in Schritt 1 automatisch mit einer Arbeitsnotiz aktualisiert, die anzeigt, dass der Security Incident mit der Kategorie „fehlgeschlagene Anmeldung“ zugewiesen wurde.
   
   
2. In Schritt 2 wird das Playbook aktualisiert und in den Status „Analyse“ versetzt.
3. In Schritt 3 überprüft das Playbook, ob der betroffene Anwender ein aktiver oder inaktiver Anwender ist. Wenn der Anwender inaktiv ist, wird dem Security Incident eine Arbeitsnotiz hinzugefügt, dass der Anwenderaccount inaktiv ist.
   
   
   Hinweis:

   In Schritt 3 des Flows prüft der Flow inaktive Anwender in sn_si_Incident Tabelle verfügbar in ServiceNow. Dieser Schritt wird als Leitfaden bereitgestellt und muss für Ihre spezifische Umgebung geändert werden. Wenn Sie diese Funktionalität verwenden möchten, empfehlen wir Ihnen, in Ihrer Umgebung eine Active Directory-Integration einzurichten. Sie können mit Ihrer Active Directory-Integration den Anwenderstatus ermitteln. Je nach Antwort können Sie die nächsten Schritte für Ihr Playbook entwerfen.

   Wenn Sie keine Active Directory-Integration haben, ersetzen Sie diesen Schritt durch eine manuelle Aufgabe, die der Sicherheitsanalysten mit dem IT-Team zusammenarbeiten kann, um den Anwender zu blockieren und mit den restlichen Schritten im Playbook fortzufahren.

4. In Schritt 4 werden die erkennbaren Elemente für den Security Incident abgerufen.
5. In Schritt 5 werden die erkennbaren Elemente identifiziert.
6. Wenn keine erkennbaren Elemente gefunden werden, wird in Schritt 6 eine manuelle Antwortaufgabe erstellt, und der Flow endet.
   
   
7. Wenn erkennbare Elemente in Schritt 7 gefunden werden, werden erkennbare Elemente identifiziert, die nicht zulässig sind.
8. Wenn mindestens eines der erkennbaren Elemente nicht zulässig ist, werden die folgenden Schritte ausgeführt:
   1. Die Schritte 8,1 und 8,2 werden ausgeführt. Erkennbare Elemente werden abgerufen, und eine automatisierte Antwortaufgabe wird initiiert.
      
      
   2. Nachdem die automatisierte Aufgabe erstellt wurde, wird Schritt 8,3 (8.3.1.1 und 8,3.2,1) ausgeführt, und die Integrationen „erkennbare Elemente anreichern“ und „Bedrohungssuche“ werden ausgeführt. Beachten Sie, dass dies Subflows sind, die im Playbook enthalten wurden.
      
      
   3. In Schritt 8,4 wird der Security Incident-Datensatz aktualisiert, nachdem die Integrationen abgeschlossen wurden.
   4. In Schritt 8,5 wird eine neue Antwortaufgabe erstellt, um die nächste automatisierte Aufgabe anzugeben, die ausgeführt wird.
   5. In Schritt 8,6 wird die Integration der Sichtungssuche für die erkennbaren Elemente ausgeführt.
      
      
   6. Nachdem der Subflow „Sichtungssuche“ abgeschlossen wurde, wird der Security Incident in Schritt 8,7 aktualisiert.
   7. In Schritt 8,8 werden die erkennbaren Elemente überprüft, um festzustellen, ob sie böswillig sind.
   8. Wenn die erkennbaren Elemente nicht schädlich sind und der Anwenderaccount aktiv ist, wird eine automatisierte E-Mail an den Anwender gesendet, um die fehlgeschlagenen Anmeldeversuche erneut zu bestätigen. Eine manuelle Antwortaufgabe wird erstellt, um die erkennbaren Elemente zu identifizieren und dem Security Incident hinzuzufügen. Das Playbook endet dann in dieser Phase.
   9. Wenn die erkennbaren Elemente schädlich sind, werden drei Antwortaufgaben erstellt:
      1. Zur Bestätigung wird eine automatisierte E-Mail an den Anwender gesendet (Ja oder Nein) Die nicht erfolgreichen Anmeldeversuche. Wenn der Anwender mit „Ja“ antwortet:
         1. Der Status des Security Incidents wird auf aktualisiert Enthalten .
         2. Eine automatisierte E-Mail wird an den Anwender gesendet, um das Passwort zurückzusetzen.
         3. Der Subflow „Passwort zurücksetzen“ wird initiiert, und eine E-Mail wird an den Anwender gesendet, wenn die Aufgabe abgeschlossen wurde.
         Hinweis:

         Der Schritt „Passwort zurücksetzen“ wird als Leitfaden bereitgestellt. Die Schritte im Flow setzen das Passwort für den Account des Anwenders im ServiceNow-System zurück. Der Prozess zum Zurücksetzen des Passworts kann jedoch je nach Umgebung unterschiedlich sein. Sie können mit Ihrer Active Directory-Integration überprüfen, ob das Passwort von Anwendern automatisch zurückgesetzt wird. Wenn Sie keine Active Directory-Integration haben, ersetzen Sie diesen Schritt durch eine manuelle Aufgabe, die der Sicherheitsanalysten mit dem jeweiligen IT-Team zusammenarbeiten kann, um das Passwort des Anwenders zurückzusetzen und mit den restlichen Schritten im Playbook fortzufahren, nachdem die entsprechende Aufgabe abgeschlossen wurde.
      2. Wenn der Anwender mit „Nein“ antwortet, wird eine automatisierte E-Mail an den Anwender gesendet, um die Antwort erneut zu bestätigen. Der Sicherheitsanalyst muss die entsprechenden Maßnahmen manuell ergreifen.
      3. Wenn der Anwender nicht auf die automatisierte E-Mail antwortet, muss der Sicherheitsanalyst den Security Incident manuell aktualisieren und eine Antwort bereitstellen. Eine manuelle Aufgabe wird erstellt, um zu validieren, ob der Anwenderaccount gefährdet wurde.
      
      
      
9. In Schritt 8.10.3 wird der Status des Security Incident aktualisiert.
10. In Schritt 8.10.4 wird eine automatisierte Aufgabe erstellt, um zu überprüfen, ob die Funktionsimplementierung „Blockanforderungen für schädliche IPs und URLs erstellen“ verfügbar ist. Wenn die Fähigkeitsimplementierung verfügbar ist, wird der Subflow „Blockanforderungen erstellen“ ausgeführt. Wenn dies nicht verfügbar ist, wird der Security Incident aktualisiert, und eine Arbeitsnotiz wird veröffentlicht, um anzuzeigen, dass die Fähigkeitsimplementierung nicht verfügbar ist.
11. In Schritt 9 wird der Security Incident aktualisiert, und der Status wird auf festgelegt Überprüfen .
12. In Schritt 10 wird eine Antwortaufgabe erstellt, damit der Anwender die Überprüfung nach dem Incident abschließen kann, bevor er die Aufgabe schließt.