Playbook for Failed Login Manual
Summarize
Summary of Playbook for Failed Login Manual
The Failed Login Manual playbook in ServiceNow Security Operations helps security teams efficiently investigate and respond to security incidents triggered by unsuccessful user login attempts. These attempts may be false positives or potential attacks targeting user email accounts. This playbook guides analysts through automated and manual steps to assess, enrich, and remediate incidents involving failed logins, streamlining incident handling and improving response accuracy.
Show less
Prerequisites
- User role: snsi.admin and flowdesigner
- Installation of the Security Operations Spoke (snsecspoke)
Key Features
- Determines if the affected user is active or inactive, using Active Directory integration if available, or manual steps otherwise.
- Filters observables against an allow list and enriches them with threat intelligence data from VirusTotal, Hybrid Analysis, Whois, and ReverseWhois.
- Performs automated threat lookups and sighting searches using integrations like Splunk or QRadar.
- Automates communication by sending emails to users to confirm failed login attempts and, if confirmed malicious, to reset passwords.
- Assigns investigative and review tasks to security analysts to ensure thorough incident handling and post-incident review.
- Identifies malicious IPs and URLs, with options to block them automatically via integrations such as CheckPoint and Palo Alto, or to escalate manually if blocking capabilities are unavailable.
- Updates the security incident status throughout the investigation process, moving through states like Analysis, Contain, and Review.
Using the Playbook
Security analysts with appropriate roles can access and customize the playbook via Flow Designer. The playbook can be copied and modified to fit specific organizational workflows. It triggers automatically when a security incident is categorized as a Failed Login and has one or more affected users, provided the incident is open.
The playbook executes a series of automated steps including incident updates, user status checks, observable enrichment, threat lookups, and response task creation. Depending on findings, it sends emails to users to verify login attempts, resets passwords if needed, and assigns manual tasks to analysts for further investigation and post-incident review.
Customization is encouraged, especially for integration with Active Directory and password reset processes, to align with the customer’s environment and security policies.
Benefits for ServiceNow Customers
- Accelerates investigation and response to failed login incidents with a structured, repeatable process.
- Reduces false positives by validating user status and confirming login attempts through automated user communication.
- Enhances threat detection by enriching observables and leveraging multiple threat intelligence sources.
- Improves security posture by automating blocking of malicious IPs and URLs and enforcing timely password resets.
- Facilitates compliance and continuous improvement through post-incident review tasks.
When a user makes certain unsuccessful login attempts (according to the SIM configuration), a security incident is created.
These unsuccessful login attempts may either be false positives or attempts made by attackers to obtain access to user email accounts. In such scenarios, the Failed Login Manual playbook can provide guidance and help optimize the investigation of failed login security incidents.
Prerequisites
- sn_si.admin
- flow_designer
Spoke: Install Security Operations Spoke (sn_sec_spoke)
Key capabilities
The Failed login playbook covers the following capabilities to investigate security incidents:
- Checks if the affected user is an active/inactive user
- Filters allowed list observables
- Enriches the observables
- Performs automated threat lookup.
- Sends automated email to the user to confirm the failed login attempt.
- Assigns tasks to analyst to investigate user access
- Identifies malicious observables and block IPs and URLs.
- Resets user password.
- Updates security incident status
- Assigns tasks to a security analyst to handle post-incident review.
Capabilities required
- Threat Lookup (Virus Total, Hybrid Analysis)
- Observable Enrichment (Whois, ReverseWhois)
- Sighting Search (Splunk, QRadar)
- Observable Blocking (CheckPoint, Palo Alto)
For more information, see the ServiceNow store.
Security analyst experience
To understand how to resolve security threats in a step-by-step manner, see Resolve security threats with the playbook.
Using Failed Login playbook with Flow Designer capabilities
- Login as a user with sn_si.user and flow_designer roles.
- Navigate to and click on the Failed Login playbook.
- Make a copy of the following flows to copy the Failed Login Playbook and make the necessary modifications. (This is an optional step. Follow this step only if you plan to customize or make specific changes to the flow).
- Failed Login Manual Playbook V1
- Failed Login - Parse User's reply and Update Response Task V1
- Make the necessary modifications according to your requirement. (This is an optional step. Follow this step only if you plan to customize or make specific changes to the flow).
- Activate the playbooks.
- Activate the main flow to use the playbook available with the base system.
- Activate the copied flows after making any modifications according to your requirements.
The following image shows a copy of the Failed Login Manual playbook. Review the steps below to get an understanding of the various actions in the playbook.
- Category is Failed Login
- Has one or more affected users
- Security incident isn’t closed or canceled
The following steps walks you through the actions, tasks, and subflows that are available in the Failed Login Manual playbook.
- When the playbook starts executing, in Step 1, the playbook is automatically updated with a
worknote showing the security incident with the failed login category has been assigned.
- In Step 2, the playbook is updated and moved to the Analysis state.
- In Step 3, the playbook checks if the Affected User is an active or inactive user. If the
user is inactive, a worknote is added to the security incident that the user account is
inactive.
Note:In step 3 of the flow, the flow checks inactive users in the sn_si_incident table available in ServiceNow. This step is provided as a guideline and must be modified for your specific environment. If you want to use this functionality, we recommend that you have an Active Directory integration set up in your environment. You can check with your Active Directory integration to find the user status and depending on the response, you can design the next steps for your playbook.If you don’t have an Active Directory integration, replace this step with a manual task for the security analyst to work with the IT team to block the user and move forward with the rest of the steps in the playbook.
- In Step 4, the observables for the security incident are retrieved.
- In Step 5, the observables are identified.
- If no observables are found, a manual response task is created in Step 6 and the flow
ends.
- If observables are found in Step 7, observables that aren’t allowed list are identified.
- If at least one of the observables is not allowed list, the following steps are performed:
- Steps 8.1 and 8.2 are executed. Observables are retrieved and an automated response task
is initiated.
- After the automated task has been created, Step 8.3 (8.3.1.1 and 8.3.2.1) is run and the
Enrich Observables and Threat Lookup integrations are executed. Note that these are subflows
that have been included in the playbook.
- In Step 8.4, after the integrations have been completed, the security incident record is updated.
- In Step 8.5, a new response task is created to indicate the next automated task that will take place.
- In Step 8.6, the Sighting Search integration will be run on the observables.
- After the Sighting Search subflow has been completed, in Step 8.7, the security incident is updated.
- In Step 8.8, the observables are checked to see if they are malicious.
- If the observables are not malicious, and if the user account is active, an automated email is sent to the user to reconfirm the unsuccessful login attempts. A manual response task is created to identify the observables and add them to the security incident. The playbook then ends at this stage.
- If the observables are malicious, three response tasks are created:
- An automated email is sent to the user to confirm (Yes or No) the unsuccessful login attempts. If the user responds Yes:
- The security incident status is updated to Contain.
- An automated email is sent to the user to reset the password.
- The Reset Password subflow is initiated and an email is sent to the user when the task has been completed.
Note:The Reset Password step is provided as a guideline. The steps in the flow reset the password for the user's account in the ServiceNow System. But the process to reset the password may be different depending on your environment. You can check with your Active Directory integration to reset the password of users automatically. If you don’t have an Active Directory integration, replace this step with a manual task for the security analyst to work with the respective IT team to reset users password and move forward with the rest of the steps in the playbook, upon completing the respective task. - If the user responds No, an automated email is sent to the user to reconfirm the response. The security analyst has to manually take appropriate actions.
- If the user doesn’t respond to the automated email, the security analyst must update the security incident manually and provide a response. A manual task is created to validate if the user account has been compromised.
- An automated email is sent to the user to confirm (Yes or No) the unsuccessful login attempts. If the user responds Yes:
- Steps 8.1 and 8.2 are executed. Observables are retrieved and an automated response task
is initiated.
- In Step 8.10.3, the security incident is state is updated.
- In Step 8.10.4, an automated task is created to verify if the Create Block Requests for Malicious IPs and URLs capability implementation is available. If the capability implementation is available, the Create Block Requests subflow is executed. If this isn’t available, the security incident is updated and a worknote is posted to indicate that the capability implementation isn’t available.
- In Step 9, the security incident is updated and the state is set to Review.
- In Step 10, a response task is created for the user to complete the post-incident review before closing the task.