Security Incident Response playbook actions

  • Release version: Yokohama
  • Updated January 30, 2025
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Security Incident Response playbook actions

    This document outlines the various Flow Designer actions available in the Security Incident Response playbook for the Yokohama release. These actions enable automation and orchestration of security incident workflows within ServiceNow, helping customers efficiently manage and respond to security incidents by adding tags, tracking affected users, managing observables, and updating incident details.

    Show full answer Show less

    Key Features

    • Add Security Tags: Automatically attach security tags to incidents based on detected indicators of compromise (IOCs), facilitating quick categorization and prioritization.
    • Manage Observables: Add observables (URLs, IPs, hashes) to incidents with customizable delimiters, filter out allowed list observables, and log system activities when observables are excluded.
    • Affected Users Management: Retrieve and roll-up affected users from multiple child incidents to parent incidents, ensuring unique users are tracked without duplication. Also enables retrieval of primary affected users for targeted communications.
    • Configuration Items (CIs) Integration: Obtain configuration items related to affected users or observables (e.g., IP addresses linked to servers) to assist in assessing incident impact and updating incident severity or risk score.
    • Child Security Incident Handling: Retrieve all child incidents for a parent incident, enabling automated status updates and dynamic severity or risk scoring based on the number or state of child incidents.
    • Malicious Observable Detection: Determine if observables are malicious to escalate incidents appropriately.
    • User Interaction Email Notifications: Send emails to confirm user actions, such as verifying failed login attempts, and act based on user responses.
    • Allowed List Filtering: Filter out allowed list observables from incident processing to reduce noise and focus on relevant threats.
    • Password Reset Automation: Reset passwords for affected users automatically and notify users via email in scenarios like compromised accounts.
    • User Group Identification: Retrieve user group information for affected users to identify impacted teams or departments and coordinate response efforts.

    Practical Use for ServiceNow Customers

    These actions empower customers to automate routine and complex steps in security incident workflows, improving response times and accuracy. By using these prebuilt actions within Flow Designer, customers can:

    • Automatically tag and classify incidents based on detected threats.
    • Aggregate and correlate affected users and configuration items across related incidents.
    • Filter out non-threatening observables to focus investigation efforts.
    • Communicate efficiently with users impacted by security events.
    • Automatically escalate incidents based on severity indicators like malicious observables and child incident counts.
    • Enforce password resets and other remediation steps promptly.

    Implementing these actions within playbooks helps standardize security response processes, reduces manual effort, and enhances overall incident management effectiveness.

    This section describes the actions provided in the Flow Designer action library.

    Action Name Description Example scenario
    Add a security tag to the security incident Use this action to add a security tag automatically using flow designer logic. If the flow detects an IOC, the IOC Detected tag can be automatically added using this action.

    Flow:
    • Input: security incident, security tag
    • Output: not applicable
    Add observables to the security incident Use this action to add observables to a selected security incident.
    • By default, the list of observables are separated by the comma (,) delimiter but this can be modified. You can specify another single special character as a delimiter. While adding observables, the type (URL, IP address, hash) is automatically set.
    • When the observables are added to the security incident, the type (URL, IP address, hash) is automatically set.
    • When the observables are being added, the Filter Allowed list Observables option identifies allowed list observables and does not add them to the security incident's observables related list. An automated system activity (response) is added to indicate that these observables have been removed.
    • Input:
      • security incident
      • observables
      • delimiter
      • filter allowed list observables and post activity note
    • Output: not applicable
    Get affected users (Related Lists) from multiple security incidents V1 Retrieves all the affected users listed in the Affected Users related list for the specified security incidents. You may have parent security incidents with multiple child security incidents. Use this action to roll-up affected users from all the child security incidents to the corresponding parent security incidents. Only unique affected users are rolled-up and all duplicates are eliminated.
    • Input: security incidents
    • Output:
      • affected user
      • count
    Get affected users from multiple security incidents Retrieves the primary affected user for the specified security incident. It does not include the affected users from the Affected User related list.
    • While investigating a phishing security incident, send an email to the primary affected users (who reported the phishing incident) to confirm if any of the users clicked on the malicious links in the phishing email.
    • Update the parent security incident severity or risk score based on the count of primary affected users.
    • Input: security incidents
    • Output:
      • affected users
      • count
    Get affected users (related list) from a security incident Retrieves all the affected users listed in the Affected Users related list for a specified security incident.
    • Input: security incidents
    • Output:
      • affected users
      • count
    Add affected users to security incident Adds all affected users to a security incident. Suppose you have a parent security incident with multiple child security incidents. You can use this action to roll-up affected users from all the child security incidents to the corresponding parent security incident. Only unique affected users are rolled-up and all duplicates are eliminated.
    • Input:
      • security incident
      • user
    • Output: not applicable
    Get configuration items of the affected users Retrieves the configuration items (CIs) of all affected users. In phishing or malware scenarios, you can use this action to update the Affected Configuration Items (CI) related list and investigate the CIs. You can then update the severity or risk score of the security incident based on the number of identified CIs.
    • Input: users
    • Output:
      • configuration items
      • count
    Get all child security incidents for a security incident Retrieves all child security incidents related to a specific parent security incident. Example scenario: Use this action to:
    • Update the status of the child security incidents when their corresponding parent security incidents status get updated.
    • Update the severity or risk score of the security incident automatically based on the number of child security incidents.
    • Input:
      • security incident
      • incident state
    • Output:
      • child security incident
      • count
    Get configuration items for the observables (type IP address) Retrieves all configuration items (CIs) for observables of type IP address. An IP address observable can be associated with a configuration item. For example, the IP address of a server. If you use this action, you can retrieve information for the server.
    • Input: observable ip address
    • Output:
      • configuration items
      • count
    Is observable malicious Confirms the presence of one or more malicious observables in a set of observables. After the threat lookup has been completed and you have identified the presence of malicious observables, you can increase the severity or risk score of a security incident.
    • Input: security incident
    • Output: malicious (true/false)
    Send email to confirm user interaction Sends email in response to a user response. If a user tries multiple times to login to an application and fails, it results in a failed login scenario. In this case, an email is sent to the user to confirm whether the user attempted to login or not. Depending on the user response (Yes or No), different actions can be taken.

    Flow: Failed Login Manual playbook
    Filter out allowed list observables Use this action to allow list observables from a given set of observables. You can identify certain observables that can be ignored from a set of observables. These observables will not taken into account while resolving the security incident.
    • Input: security incident
    • Output:
      • allowed list observables
      • count
    Reset password for affected users Use this action to reset password for affected users. If a user account has been hacked or a user requests a password to be reset, an email is sent to the user to reset the password.

    Flow: Failed Login Manual playbook.
    Get user group for affected user Retrieves the user group details of affected users. In an organization, if two or more users report phishing emails, you can find out the group they belong to and identify if more users have been affected
    • Input: user
    • Output:
      • user groups
      • count