Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • Security Operations
Table of Contents
Choose your release version
    Home Orlando Security Incident Management Security Operations Security Incident Response Security incident creation Security incident automatic creation Create security incidents from User Reported Phishing emails

    Create security incidents from User Reported Phishing emails

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Create security incidents from User Reported Phishing emails

    Use this feature to create security incidents from user reported phishing emails.

    The enhanced User Reported Phishing functionality includes aggregation capabilities, email header extraction, and configuration.

    • Users can report phishing emails in multiple ways:
      • Emails can be forwarded as attachments.
      • If the Wombat plugin has been configured with the Microsoft Outlook client, users can:
        • Click the Report Phish button.
        • Forward phishing emails from a mobile device using the Report Phish option.

        Report phishing emails
      • Users can upload a phishing email (in .eml format).
        Report phishing emails as attachments
    • User reported phishing includes aggregation business logic that identifies duplicate phishing emails reported by users in an organization. Users can use this capability to:
      • Aggregate duplicate or similar user reported phishing incidents (company initiated phishing campaigns).
      • Avoid triaging duplicate user reported phishing incidents and reduce the manual effort involved in consolidating incidents.
      • Enable security analysts to work on a single user reported phishing incident.
    • Provides phishing email headers within the user reported phishing incident.
      • Security analysts can scan for key email header information within the incident.
      • Manual effort in gathering header information from other sources is no longer required.
    • The original phishing email submitted is stored as a Phishing Email Record in a new table.
      • Security analysts can view details of the original phishing email like phishing email content, headers, origin.
    • Security administrators can configure and make certain enhancements that include:
      • Configurations to extract email headers from the email body (Report Phish submissions).
      • Filters to capture selected headers.
      • Configurations to handle parent-child incident association when duplicate phishing email records are identified.
      • Flow Designer configurations to modify aggregation business logic based on the requirements.

    Important installation instructions

    The User Reported Phishing feature available in this release is an enhanced version of the existing user reported phishing functionality available in the London release.

    This enhancement replaces the existing User Reported Phishing design. The new design includes the following updates:
    • The User Reported Phishing inbound actions (Type = Forward and Type = New) available prior to the Security Incident Response 9.0 release are now disabled. Security incidents are no longer created through the disabled inbound actions.
    • A new Create Phishing Email inbound action is now available.
    • The Security Operations spoke application must be installed for the new design to take effect. This includes the Transform user-reported phishing emails to security incidents flow which is a new flow that contains the security incident creation and aggregation business logic for the new design. This is available in an inactive state by default. You must activate this flow for this new design to take effect and to create security incidents from the phishing email records.
    • The existing User Reported Phishing rules have been preserved during this upgrade.
    Note: If you use custom email inbound actions and custom workflows for user reported phishing submissions, you must review both the old and new designs for conflicting or overlapping functionalities.
    This following are the details of this enhancement:
    • Reporting the phishing email in multiple ways: See Create security incidents from User Reported Phishing emails for details. The phishing email is then moved to the sn_si_phishing_email table.
    • Creating phishing email records: If the email-matching rules are met (See Set up ingestion rules for User Reported Phishing), the Create Phishing Email inbound action creates a phishing email record. The parsed email headers are stored in the cmsn_si_phishing_email_header table and associated with the phishing email as a related list.
    • Aggregating similar phishing records into a single security incident: The Transform user-reported phishing emails to security incidents flow creates security incidents from the phishing email records and aggregates similar records into a single incident. The aggregation conditions can be modified as required in this flow.
    The following image shows the differences between the old and the new designs:
    User Reported Phishing: Differences

    Required components and plugins

    To use the enhanced User Reported Phishing feature, you must install the following plugins in the recommended order.

    A list of plugins, the minimum version required, and the order of installation is given in the table below:
    Order of installation Plugins to be updated Minimum version
    1 Security Integration Framework 9.0.3
    2 Security Support Common 9.0.4
    3 Security Common Orchestration 9.0.0
    4 Threat Core 9.1.0
    5 Security Incident 9.0.1
    6 Security Operations Spoke 9.0.0
    7 Security Incident Response UI 9.0.0
    Note: To use all the new functionality, you must install the latest version of these plugins. But to use the enhanced User Reported Phishing functionality, you must install the minimum versions listed below.

    Set up ingestion rules for User Reported Phishing

    As a user with the sn_si.admin role, you can define email matching rules to filter user reported phishing emails based on specific criteria. For example, you can define a rule where all emails sent either directly or through the Report Phish button to security@acme.com are categorized as user reported phishing emails.

    Before you begin

    Role required: sn_si.admin

    Procedure

    1. Navigate to Security Operations > Email Processing > User Reported Phishing Properties.
    2. Click New to create a new Email Matching Rule.
    3. Enter a name and define one or more conditions for the rule. Click Submit to save the rule. The following are some sample rules:
      • ToRule: Filter emails that have been sent directly or forwarded to security@example.com email id. Example of a ToRule
      • UserID Rule: Filter emails that have been sent from a specific email id. Example of UserID Rule

    Define User Reported Phishing properties

    Define the header information that must be captured from user reported phishing emails.

    Before you begin

    Role required: sn_si.admin

    About this task

    Use these options to configure the following user reported phishing settings.
    • Configuration to extract email headers from the email body. (Report Phish submissions.)
    • Filter to select headers.
    • Enable or disable parent-child association.

    Procedure

    1. Navigate to Security Operations > Email Processing > User Reported Phishing Properties.
      User Reported Phishing Properties
    2. Specify the configuration for extracting email headers from the email body:
      • Enter a string that identifies the beginning of the email header.
      • Enter a string that identifies the end of the email header.
        Note: Apply these settings only to headers captured as part of the email body of the phishing email. For instance, if the Wombat plugin has configured with the Microsoft Outlook client, when the user clicks the Report Phish button, the email headers are captured as per the configuration defined here. The header information is not captured if the phishing email is forwarded as an attachment.
    3. Specify filters to eliminate headers that are not required for investigating the security incident.
      • Enter a comma-separated list of email headers that must be captured from the user reported phishing email. If you don't specify any value here, all the header information is captured.
    4. Finally, enable or disable parent-child association.
      • Select Yes to indicate that child security incidents must be created when user reported phishing emails are aggregated. If you select No, child security incidents are not created, but the user reported phishing emails are associated with the security incident and the security incident record is updated. See Transform user-reported phishing emails to security incidents for more information on how the child security incidents are created.

    Phishing email records created from user reported phishing emails

    User reported phishing emails are converted to security incidents based on the email matching rules that have been defined.

    When a new phishing email is reported, the following actions take place:
    • An email record is created in the sys_email table.
    • The Create Phishing Email inbound action runs on the email record and uses the Email Matching Rules (see Set up ingestion rules for User Reported Phishing) to determine if it is a phishing email.
    • When it has been identified as a phishing email, a phishing email record is created in the sn_si_phishing_email table.
    • Finally, the Transform user-reported phishing emails to security incidents flow is applied to convert the phishing email record to a security incident.

    To view the email details, navigate to Security Incident > Show All Phishing Emails. A list of phishing email records are displayed. Click the date link in the Created column to view the email record.


    Phishing email with ToRule
    Table 1. Security Incident Phishing Email Details
    Field Name Description
    Number The number assigned to the user-reported phishing email.
    Subject The subject of the email. The subject rule is useful in simulated phishing campaigns or tests. In this case, organizations send deceptive emails to their own staff to test their response to phishing and similar email attacks.

    In simulated phishing email tests, if the Microsoft Outlook email client with the Wombat plugin is being used, the user can click the Report Phish button to report the phishing email. The email is sent to the Security Operations team with Simulated Phishing appended to the Subject of the email. This is used to identify the email as a simulated phishing email.

    From The email address from where this phishing email originated. This information is available if the phishing email is forwarded as .EML file attachment or if the original headers are embedded in the email.

    If the user forwarded the phishing email directly, the From address may not be available.

    Reported by The email id of the user who reported this phishing email. Click the Information icon to view additional details.
    Message id The id assigned to the message.
    Matched URP rule The User Reported Phishing rule that is to be applied on this email. Click the Information icon to view additional details.
    URP ingestion rule

    As you can see, in this example, the Condition field shows that the ToRule is applied on this email and a security incident is created. See Set up ingestion rules for User Reported Phishing for more information on defining email matching rules.

    State When a new phishing email record is created in the sn_si_phishing_email table, the State field is set to New. When this email record is converted to a security incident (see Transform user-reported phishing emails to security incidents), the State field is updated to Processed.
    Header origin This field indicates how the email headers originated or how the user reported the phishing email:
    • Email Header: The user forwarded the phishing email to the security operations team.
    • Email Text Body:
      • The user clicked on the Report Phish option (if the Wombat plugin has been configured with the email client).
      • Based on the User Reported Phishing rule defined, the phishing email is forwarded to the security operations team.
    • EML Attachment Header:
      • Attachment: The user forwarded the email as an attachment (.EML file).
      • Service catalog submission: The user downloaded the email as a .EML file to the desktop and then uploaded it to a specified location. The security incident is then created from the email.
    • EML Attachment Body:
      • The user clicked on the Report Phish option (if the Wombat plugin has been configured with the email client).
      • Based on the User Reported Phishing rule defined, the phishing email is forwarded as an attachment to the security operations team.
    Security Incident This field is blank when the user-reported-phishing email is first reported. When the Transform user-reported phishing emails to security incidents flow has been executed, this email is converted to a security incident record and the number of this record is displayed here.
    Raw headers This field shows the complete header information extracted from the email as defined in the Define User Reported Phishing properties page. The headers are parsed into key value pairs and displayed in the Phishing Email Headers list.
    Phishing email headers
    Body This is the body of the user-reported phishing email.

    Transform user-reported phishing emails to security incidents

    The Transform Phishing Email to Security Incident flow is a new flow that converts or transforms phishing email records to security incidents.

    Before you begin

    Note: To enable the User Reported Phishing functionality, you must make a copy of the flow and activate it. If you have created custom inbound actions and custom flows to handle user reported phishing submissions, flow modifications suggested here are not required.
    • Role required: sn_si.admin
    • Flow Designer spoke must be installed.

    About this task

    This flow is automatically launched when a user reported phishing email record with the State set to New is created. This flow contains the logic to:
    • Aggregate security incidents.
    • Update security incidents with relevant notes.
    • Add header data.
    • Create child incidents as required.

    Procedure

    • Navigate to Flow Designer > Designer to view the flows available with the Security Operations spoke.
      Security Operations Flows
    • Click the Transform Phishing Email to Security Incidents link to view the flow.
    • This flow is provided with the base system and is in Read Only mode and cannot be used. Click the more icon More icon, make a copy of the flow and open it for your use. You can now make changes to your flow, such as modifying trigger conditions or actions, or adding and removing actions. After making the necessary changes, you must activate ( See Activate a Security Incident Response flow) the flow so that it can be executed.
      Transform Phishing Email to Security Incidents flow

      This figure shows the trigger and the steps executed with the flow. The-right hand panel shows the data flow. Click on an icon to expand the step and view the details.

    • Click the Trigger icon. In the first step, you define or set the trigger for the flow. Specify the conditions for the trigger and task to be performed when the conditions are met. This flow is initiated when a New record is uploaded to the sn_si_phishing_email table.
      Transform flow: trigger
    • In step 1, the flow verifies if the Create child incidents for aggregated email submissions? flag is enabled or disabled in the Transform user-reported phishing emails to security incidents page.
      Transform flow: Action 1
    • In step 2, the oldest parent security incident is identified. Notice the icon in step 2. This indicates that the Phishing Email Aggregation Subflow will be executed as part of this step.
      Transform flow: Action 2

      Click the action designer icon to see a detailed view of the action. This subflow checks the phishing email and matches it with an existing security incident based on the specified criteria.

      Transform flow: Phishing Email Aggregation subflow
      These two actions are performed when this subflow is executed. Click on the link of the first action to view additional details.
      Transform flow: Subflow: Action
      This action checks the emails that match the criteria for the new incoming email based on conditions such as:
      • Security Incident State is not Closed.
      • Subject or From value match the email matching rule conditions defined (See Set up ingestion rules for User Reported Phishing).
      If these conditions are met, you can see the number of records that match the criteria in the Max Results field. The oldest or the first record in the list is designated as the parent record against which the security incidents will be aggregated.
    • Step 3 is applicable only if the Create child incidents for aggregated email submissions? flag was set to No in the Transform user-reported phishing emails to security incidents page. In this case, the phishing email is associated with the security incident record and the flow ends.

      Transform flow: Action 3
    • If the Create child incidents for aggregated email submissions? was set to Yes, the flow continues to run and a new security incident is created based on the user-reported phishing email.
      Transform flow: Action 4
    • In step 5, users who received the phishing email (employees in the To and CC list of the phishing email) are added to the Affected Users related list in the security incident record.
      Transform form: Action 4
    • In step 6, allow listed observables are filtered from the list of observables in the security incident. These allow listed observables will not be added to the security incident.
      Transform flow: Filter allow listed obeservables
    • In step 7, unknown observables from the user-reported phishing email are identified and added to the Observables related list.
      Transform flow: Add observables
    • In step 8, an email search query is generated which is a combination of the Subject and the From address of the email. This information is useful in identifying the employees in the organization who have been phished.
      Transform flow: Create email search query
    • In step 9, the user reported phishing email is associated with the security incident and the security incident record (created in step 4) is updated.
      Transform flow: Update security incident record
    • In step 10, the parent security incident is identified and a check is made to see if it is an open security incident record.
      Transform flow: Look up security incident record
    • If the parent security is active, notes are added to the child and the parent security incident records indicating how they are associated with each other.
    • In step 12, if no Affected Users were found (in step 5 of the flow), a worknote is added and the security incident record is updated.
      Transform flow: Add worknote for unmatched users
    • In step 13, a worknote is added with the list of allow listed observables.
      Transform flow: Add list of allow listed observables

    What to do next

    You can click Test to simulate the actions in the flow before it is published. After testing the flow, click Activate to activate the flow so that it can be executed.

    Click Executions to view the execution details of the flow.


    Transform flow: Execution details

    When the flow has been executed, the phishing email record is converted to a security incident. See Security incident records created from phishing email records

    Security incident records created from phishing email records

    Phishing email records stored in the sn_si_phishing_email table are converted to security incidents records.

    To view the security incident associated with the phishing email record, click Security incident > Phishing Email > Show All Phishing emails.


    Phishing email table

    Click the link in the Security Incident column associated with the phishing email record. The security incident details are displayed.


    Security incident associated with the phishing email record

    Related lists

    Scroll down to the Related Links section of the security incident and click Show All related list. View details like child security incidents, affected users, associated phishing emails.

    Child security incidents

    Click the Child Security Incidents tab. You can see a list of child security incidents associated with the parent security incident based on the aggregation logic that has been applied. For every child record added, an automated system activity is added (in the Worknote section) to the parent record. This notifies the security analyst about the aggregated child record.
    Note: You can see the child security incidents here only if the Create child incidents for aggregated emails submissions flag is set to Yes in the User Reported Phishing Properties page. See Define User Reported Phishing properties for details.

    Child security incidents

    Associated phishing emails

    Click the Associated Phish Emails tab. You see a list of phishing email records (duplicate records) associated with the parent phishing email record.
    Associcated phishing email records

    Associated phishing email headers

    Click the Associated Phish Emails tab. You see the phishing email header details that have been captured as part of the security incident. You can view the rolled-up headers of all child records and phishing email records aggregated to the parent security incident.
    Associated phishing email headers

    Whitelisted observables

    As the Transform user-reported phishing emails to security incidents flow is being executed, you can monitor the status of the security incident. When certain observables are marked as whitelisted, they are not added to the Observables Related list. By whitelisting the observables, you can ensure that only the important details are displayed. For example, if www.google.com is one of the URLs that has been whitelisted, the following system message is displayed.
    Whitelisted observables

    Whitelisting observables ensures that only the important observables are monitored.

    Capturing unmatched users

    Some email ids in the To and CC list of the phishing email may not belong to users in the organization. These email ids are categorized as unmatched users and are not included in the Affected Users Related list. A worknote indicating that these are unmatched users is displayed.
    Unmatched users

    User Reported Phishing in the Security Analyst Workspace

    You can view security incidents associated with the phishing email records in the Security Analyst Workspace.

    Navigate to Security Incident > New UI. The workspace opens in a separate browser tab. Click on the security incident associated with the phishing email record to view the security incident.
    URP security incident: New UI
    Click the binoculars icon. The original phishing email is displayed.
    URP security incident: New UI - phishing email
    In the Explore tab, click Incidents > Child Security Incidents.
    URP security incident: New UI - child security incidents
    Click Incidents > Associated Phish Headers > . You can view the rolled up headers of all child records and phishing email records aggregated to the parent security incident.
    URP: New UI - Email headers
    Click on the phishing email link to view the phishing email record associated with the security incident.
    URP: New UI: phishing email record
    Click the Incident Timeline tab.
    URP: New UI: worknotes
    You can view the system updates that highlight:
    • Identified duplicate child records.
    • Whitelisted observables.
    • Unmatched users who received the phishing email but do not belong to the Affected Users list.

    Frequently Asked Questions

    This section covers some of the frequently asked questions about the enhanced User Reported Phishing feature.

    1. I have installed the new Security Incident Response spoke but I cannot view any user reported phishing incidents.

      By default, the User Reported Phishing functionality has been disabled.

      To enable this feature, you must make a copy of the read-only Transform user-reported phishing emails to security incidents flow and activate it before use.

    2. While ingesting phishing emails and converting them into security incidents, what precautionary measures are used to handle malicious links and attachments in the phishing emails?

      The ServiceNow anti-virus scanner scans such malicious attachments and links. However, to ensure that security analysts can investigate the incidents accurately, the Security Incident Response application captures all the artefacts that are part of a phishing email. But the User Reported Phishing functionality mutes the malicious links in the phishing email so that security analysts don't accidentally click these links. Regarding malicious attachments, security analysts must be cautious about downloading them.

    3. Do we capture all malicious files that are part of the phishing emails for security incident enrichment?

      Yes, we capture all files from the phishing emails. You can view these details are available as part of security incident observables in the form of a file hash.

    4. Do we send malicious files and links from phishing emails to a sandbox instance for investigation?

      Currently, we do not support out-of-the-box sandbox integrations for investigating malicious files and links.

    5. Is there a time window or a trigger that defines the duration in which incoming duplicate phishing email records are associated with a parent security incident?

      Duplicate phishing email records are aggregated only to an active parent security incident. If the parent incident is closed or canceled, then the incoming new duplicate phishing email will be created as a new security incident. However, in this scenario, within the new security incident, you can view the closed or canceled parent security incident in the Similar Security Incident related list.

      Note: This behavior can be configured using the flow designer.
    6. Does the User Report Phishing feature support the use of only the Microsoft Outlook Wombat plugin to capture email header details?

      The User Reported functionality has been built to parse email headers and complies with RFC822 standards. So, similar to the Wombat plugin, all other Microsoft Outlook plugins that capture email headers based on RFC822 standards are supported.

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Create security incidents from User Reported Phishing emails

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Create security incidents from User Reported Phishing emails

      Use this feature to create security incidents from user reported phishing emails.

      The enhanced User Reported Phishing functionality includes aggregation capabilities, email header extraction, and configuration.

      • Users can report phishing emails in multiple ways:
        • Emails can be forwarded as attachments.
        • If the Wombat plugin has been configured with the Microsoft Outlook client, users can:
          • Click the Report Phish button.
          • Forward phishing emails from a mobile device using the Report Phish option.

          Report phishing emails
        • Users can upload a phishing email (in .eml format).
          Report phishing emails as attachments
      • User reported phishing includes aggregation business logic that identifies duplicate phishing emails reported by users in an organization. Users can use this capability to:
        • Aggregate duplicate or similar user reported phishing incidents (company initiated phishing campaigns).
        • Avoid triaging duplicate user reported phishing incidents and reduce the manual effort involved in consolidating incidents.
        • Enable security analysts to work on a single user reported phishing incident.
      • Provides phishing email headers within the user reported phishing incident.
        • Security analysts can scan for key email header information within the incident.
        • Manual effort in gathering header information from other sources is no longer required.
      • The original phishing email submitted is stored as a Phishing Email Record in a new table.
        • Security analysts can view details of the original phishing email like phishing email content, headers, origin.
      • Security administrators can configure and make certain enhancements that include:
        • Configurations to extract email headers from the email body (Report Phish submissions).
        • Filters to capture selected headers.
        • Configurations to handle parent-child incident association when duplicate phishing email records are identified.
        • Flow Designer configurations to modify aggregation business logic based on the requirements.

      Important installation instructions

      The User Reported Phishing feature available in this release is an enhanced version of the existing user reported phishing functionality available in the London release.

      This enhancement replaces the existing User Reported Phishing design. The new design includes the following updates:
      • The User Reported Phishing inbound actions (Type = Forward and Type = New) available prior to the Security Incident Response 9.0 release are now disabled. Security incidents are no longer created through the disabled inbound actions.
      • A new Create Phishing Email inbound action is now available.
      • The Security Operations spoke application must be installed for the new design to take effect. This includes the Transform user-reported phishing emails to security incidents flow which is a new flow that contains the security incident creation and aggregation business logic for the new design. This is available in an inactive state by default. You must activate this flow for this new design to take effect and to create security incidents from the phishing email records.
      • The existing User Reported Phishing rules have been preserved during this upgrade.
      Note: If you use custom email inbound actions and custom workflows for user reported phishing submissions, you must review both the old and new designs for conflicting or overlapping functionalities.
      This following are the details of this enhancement:
      • Reporting the phishing email in multiple ways: See Create security incidents from User Reported Phishing emails for details. The phishing email is then moved to the sn_si_phishing_email table.
      • Creating phishing email records: If the email-matching rules are met (See Set up ingestion rules for User Reported Phishing), the Create Phishing Email inbound action creates a phishing email record. The parsed email headers are stored in the cmsn_si_phishing_email_header table and associated with the phishing email as a related list.
      • Aggregating similar phishing records into a single security incident: The Transform user-reported phishing emails to security incidents flow creates security incidents from the phishing email records and aggregates similar records into a single incident. The aggregation conditions can be modified as required in this flow.
      The following image shows the differences between the old and the new designs:
      User Reported Phishing: Differences

      Required components and plugins

      To use the enhanced User Reported Phishing feature, you must install the following plugins in the recommended order.

      A list of plugins, the minimum version required, and the order of installation is given in the table below:
      Order of installation Plugins to be updated Minimum version
      1 Security Integration Framework 9.0.3
      2 Security Support Common 9.0.4
      3 Security Common Orchestration 9.0.0
      4 Threat Core 9.1.0
      5 Security Incident 9.0.1
      6 Security Operations Spoke 9.0.0
      7 Security Incident Response UI 9.0.0
      Note: To use all the new functionality, you must install the latest version of these plugins. But to use the enhanced User Reported Phishing functionality, you must install the minimum versions listed below.

      Set up ingestion rules for User Reported Phishing

      As a user with the sn_si.admin role, you can define email matching rules to filter user reported phishing emails based on specific criteria. For example, you can define a rule where all emails sent either directly or through the Report Phish button to security@acme.com are categorized as user reported phishing emails.

      Before you begin

      Role required: sn_si.admin

      Procedure

      1. Navigate to Security Operations > Email Processing > User Reported Phishing Properties.
      2. Click New to create a new Email Matching Rule.
      3. Enter a name and define one or more conditions for the rule. Click Submit to save the rule. The following are some sample rules:
        • ToRule: Filter emails that have been sent directly or forwarded to security@example.com email id. Example of a ToRule
        • UserID Rule: Filter emails that have been sent from a specific email id. Example of UserID Rule

      Define User Reported Phishing properties

      Define the header information that must be captured from user reported phishing emails.

      Before you begin

      Role required: sn_si.admin

      About this task

      Use these options to configure the following user reported phishing settings.
      • Configuration to extract email headers from the email body. (Report Phish submissions.)
      • Filter to select headers.
      • Enable or disable parent-child association.

      Procedure

      1. Navigate to Security Operations > Email Processing > User Reported Phishing Properties.
        User Reported Phishing Properties
      2. Specify the configuration for extracting email headers from the email body:
        • Enter a string that identifies the beginning of the email header.
        • Enter a string that identifies the end of the email header.
          Note: Apply these settings only to headers captured as part of the email body of the phishing email. For instance, if the Wombat plugin has configured with the Microsoft Outlook client, when the user clicks the Report Phish button, the email headers are captured as per the configuration defined here. The header information is not captured if the phishing email is forwarded as an attachment.
      3. Specify filters to eliminate headers that are not required for investigating the security incident.
        • Enter a comma-separated list of email headers that must be captured from the user reported phishing email. If you don't specify any value here, all the header information is captured.
      4. Finally, enable or disable parent-child association.
        • Select Yes to indicate that child security incidents must be created when user reported phishing emails are aggregated. If you select No, child security incidents are not created, but the user reported phishing emails are associated with the security incident and the security incident record is updated. See Transform user-reported phishing emails to security incidents for more information on how the child security incidents are created.

      Phishing email records created from user reported phishing emails

      User reported phishing emails are converted to security incidents based on the email matching rules that have been defined.

      When a new phishing email is reported, the following actions take place:
      • An email record is created in the sys_email table.
      • The Create Phishing Email inbound action runs on the email record and uses the Email Matching Rules (see Set up ingestion rules for User Reported Phishing) to determine if it is a phishing email.
      • When it has been identified as a phishing email, a phishing email record is created in the sn_si_phishing_email table.
      • Finally, the Transform user-reported phishing emails to security incidents flow is applied to convert the phishing email record to a security incident.

      To view the email details, navigate to Security Incident > Show All Phishing Emails. A list of phishing email records are displayed. Click the date link in the Created column to view the email record.


      Phishing email with ToRule
      Table 1. Security Incident Phishing Email Details
      Field Name Description
      Number The number assigned to the user-reported phishing email.
      Subject The subject of the email. The subject rule is useful in simulated phishing campaigns or tests. In this case, organizations send deceptive emails to their own staff to test their response to phishing and similar email attacks.

      In simulated phishing email tests, if the Microsoft Outlook email client with the Wombat plugin is being used, the user can click the Report Phish button to report the phishing email. The email is sent to the Security Operations team with Simulated Phishing appended to the Subject of the email. This is used to identify the email as a simulated phishing email.

      From The email address from where this phishing email originated. This information is available if the phishing email is forwarded as .EML file attachment or if the original headers are embedded in the email.

      If the user forwarded the phishing email directly, the From address may not be available.

      Reported by The email id of the user who reported this phishing email. Click the Information icon to view additional details.
      Message id The id assigned to the message.
      Matched URP rule The User Reported Phishing rule that is to be applied on this email. Click the Information icon to view additional details.
      URP ingestion rule

      As you can see, in this example, the Condition field shows that the ToRule is applied on this email and a security incident is created. See Set up ingestion rules for User Reported Phishing for more information on defining email matching rules.

      State When a new phishing email record is created in the sn_si_phishing_email table, the State field is set to New. When this email record is converted to a security incident (see Transform user-reported phishing emails to security incidents), the State field is updated to Processed.
      Header origin This field indicates how the email headers originated or how the user reported the phishing email:
      • Email Header: The user forwarded the phishing email to the security operations team.
      • Email Text Body:
        • The user clicked on the Report Phish option (if the Wombat plugin has been configured with the email client).
        • Based on the User Reported Phishing rule defined, the phishing email is forwarded to the security operations team.
      • EML Attachment Header:
        • Attachment: The user forwarded the email as an attachment (.EML file).
        • Service catalog submission: The user downloaded the email as a .EML file to the desktop and then uploaded it to a specified location. The security incident is then created from the email.
      • EML Attachment Body:
        • The user clicked on the Report Phish option (if the Wombat plugin has been configured with the email client).
        • Based on the User Reported Phishing rule defined, the phishing email is forwarded as an attachment to the security operations team.
      Security Incident This field is blank when the user-reported-phishing email is first reported. When the Transform user-reported phishing emails to security incidents flow has been executed, this email is converted to a security incident record and the number of this record is displayed here.
      Raw headers This field shows the complete header information extracted from the email as defined in the Define User Reported Phishing properties page. The headers are parsed into key value pairs and displayed in the Phishing Email Headers list.
      Phishing email headers
      Body This is the body of the user-reported phishing email.

      Transform user-reported phishing emails to security incidents

      The Transform Phishing Email to Security Incident flow is a new flow that converts or transforms phishing email records to security incidents.

      Before you begin

      Note: To enable the User Reported Phishing functionality, you must make a copy of the flow and activate it. If you have created custom inbound actions and custom flows to handle user reported phishing submissions, flow modifications suggested here are not required.
      • Role required: sn_si.admin
      • Flow Designer spoke must be installed.

      About this task

      This flow is automatically launched when a user reported phishing email record with the State set to New is created. This flow contains the logic to:
      • Aggregate security incidents.
      • Update security incidents with relevant notes.
      • Add header data.
      • Create child incidents as required.

      Procedure

      • Navigate to Flow Designer > Designer to view the flows available with the Security Operations spoke.
        Security Operations Flows
      • Click the Transform Phishing Email to Security Incidents link to view the flow.
      • This flow is provided with the base system and is in Read Only mode and cannot be used. Click the more icon More icon, make a copy of the flow and open it for your use. You can now make changes to your flow, such as modifying trigger conditions or actions, or adding and removing actions. After making the necessary changes, you must activate ( See Activate a Security Incident Response flow) the flow so that it can be executed.
        Transform Phishing Email to Security Incidents flow

        This figure shows the trigger and the steps executed with the flow. The-right hand panel shows the data flow. Click on an icon to expand the step and view the details.

      • Click the Trigger icon. In the first step, you define or set the trigger for the flow. Specify the conditions for the trigger and task to be performed when the conditions are met. This flow is initiated when a New record is uploaded to the sn_si_phishing_email table.
        Transform flow: trigger
      • In step 1, the flow verifies if the Create child incidents for aggregated email submissions? flag is enabled or disabled in the Transform user-reported phishing emails to security incidents page.
        Transform flow: Action 1
      • In step 2, the oldest parent security incident is identified. Notice the icon in step 2. This indicates that the Phishing Email Aggregation Subflow will be executed as part of this step.
        Transform flow: Action 2

        Click the action designer icon to see a detailed view of the action. This subflow checks the phishing email and matches it with an existing security incident based on the specified criteria.

        Transform flow: Phishing Email Aggregation subflow
        These two actions are performed when this subflow is executed. Click on the link of the first action to view additional details.
        Transform flow: Subflow: Action
        This action checks the emails that match the criteria for the new incoming email based on conditions such as:
        • Security Incident State is not Closed.
        • Subject or From value match the email matching rule conditions defined (See Set up ingestion rules for User Reported Phishing).
        If these conditions are met, you can see the number of records that match the criteria in the Max Results field. The oldest or the first record in the list is designated as the parent record against which the security incidents will be aggregated.
      • Step 3 is applicable only if the Create child incidents for aggregated email submissions? flag was set to No in the Transform user-reported phishing emails to security incidents page. In this case, the phishing email is associated with the security incident record and the flow ends.

        Transform flow: Action 3
      • If the Create child incidents for aggregated email submissions? was set to Yes, the flow continues to run and a new security incident is created based on the user-reported phishing email.
        Transform flow: Action 4
      • In step 5, users who received the phishing email (employees in the To and CC list of the phishing email) are added to the Affected Users related list in the security incident record.
        Transform form: Action 4
      • In step 6, allow listed observables are filtered from the list of observables in the security incident. These allow listed observables will not be added to the security incident.
        Transform flow: Filter allow listed obeservables
      • In step 7, unknown observables from the user-reported phishing email are identified and added to the Observables related list.
        Transform flow: Add observables
      • In step 8, an email search query is generated which is a combination of the Subject and the From address of the email. This information is useful in identifying the employees in the organization who have been phished.
        Transform flow: Create email search query
      • In step 9, the user reported phishing email is associated with the security incident and the security incident record (created in step 4) is updated.
        Transform flow: Update security incident record
      • In step 10, the parent security incident is identified and a check is made to see if it is an open security incident record.
        Transform flow: Look up security incident record
      • If the parent security is active, notes are added to the child and the parent security incident records indicating how they are associated with each other.
      • In step 12, if no Affected Users were found (in step 5 of the flow), a worknote is added and the security incident record is updated.
        Transform flow: Add worknote for unmatched users
      • In step 13, a worknote is added with the list of allow listed observables.
        Transform flow: Add list of allow listed observables

      What to do next

      You can click Test to simulate the actions in the flow before it is published. After testing the flow, click Activate to activate the flow so that it can be executed.

      Click Executions to view the execution details of the flow.


      Transform flow: Execution details

      When the flow has been executed, the phishing email record is converted to a security incident. See Security incident records created from phishing email records

      Security incident records created from phishing email records

      Phishing email records stored in the sn_si_phishing_email table are converted to security incidents records.

      To view the security incident associated with the phishing email record, click Security incident > Phishing Email > Show All Phishing emails.


      Phishing email table

      Click the link in the Security Incident column associated with the phishing email record. The security incident details are displayed.


      Security incident associated with the phishing email record

      Related lists

      Scroll down to the Related Links section of the security incident and click Show All related list. View details like child security incidents, affected users, associated phishing emails.

      Child security incidents

      Click the Child Security Incidents tab. You can see a list of child security incidents associated with the parent security incident based on the aggregation logic that has been applied. For every child record added, an automated system activity is added (in the Worknote section) to the parent record. This notifies the security analyst about the aggregated child record.
      Note: You can see the child security incidents here only if the Create child incidents for aggregated emails submissions flag is set to Yes in the User Reported Phishing Properties page. See Define User Reported Phishing properties for details.

      Child security incidents

      Associated phishing emails

      Click the Associated Phish Emails tab. You see a list of phishing email records (duplicate records) associated with the parent phishing email record.
      Associcated phishing email records

      Associated phishing email headers

      Click the Associated Phish Emails tab. You see the phishing email header details that have been captured as part of the security incident. You can view the rolled-up headers of all child records and phishing email records aggregated to the parent security incident.
      Associated phishing email headers

      Whitelisted observables

      As the Transform user-reported phishing emails to security incidents flow is being executed, you can monitor the status of the security incident. When certain observables are marked as whitelisted, they are not added to the Observables Related list. By whitelisting the observables, you can ensure that only the important details are displayed. For example, if www.google.com is one of the URLs that has been whitelisted, the following system message is displayed.
      Whitelisted observables

      Whitelisting observables ensures that only the important observables are monitored.

      Capturing unmatched users

      Some email ids in the To and CC list of the phishing email may not belong to users in the organization. These email ids are categorized as unmatched users and are not included in the Affected Users Related list. A worknote indicating that these are unmatched users is displayed.
      Unmatched users

      User Reported Phishing in the Security Analyst Workspace

      You can view security incidents associated with the phishing email records in the Security Analyst Workspace.

      Navigate to Security Incident > New UI. The workspace opens in a separate browser tab. Click on the security incident associated with the phishing email record to view the security incident.
      URP security incident: New UI
      Click the binoculars icon. The original phishing email is displayed.
      URP security incident: New UI - phishing email
      In the Explore tab, click Incidents > Child Security Incidents.
      URP security incident: New UI - child security incidents
      Click Incidents > Associated Phish Headers > . You can view the rolled up headers of all child records and phishing email records aggregated to the parent security incident.
      URP: New UI - Email headers
      Click on the phishing email link to view the phishing email record associated with the security incident.
      URP: New UI: phishing email record
      Click the Incident Timeline tab.
      URP: New UI: worknotes
      You can view the system updates that highlight:
      • Identified duplicate child records.
      • Whitelisted observables.
      • Unmatched users who received the phishing email but do not belong to the Affected Users list.

      Frequently Asked Questions

      This section covers some of the frequently asked questions about the enhanced User Reported Phishing feature.

      1. I have installed the new Security Incident Response spoke but I cannot view any user reported phishing incidents.

        By default, the User Reported Phishing functionality has been disabled.

        To enable this feature, you must make a copy of the read-only Transform user-reported phishing emails to security incidents flow and activate it before use.

      2. While ingesting phishing emails and converting them into security incidents, what precautionary measures are used to handle malicious links and attachments in the phishing emails?

        The ServiceNow anti-virus scanner scans such malicious attachments and links. However, to ensure that security analysts can investigate the incidents accurately, the Security Incident Response application captures all the artefacts that are part of a phishing email. But the User Reported Phishing functionality mutes the malicious links in the phishing email so that security analysts don't accidentally click these links. Regarding malicious attachments, security analysts must be cautious about downloading them.

      3. Do we capture all malicious files that are part of the phishing emails for security incident enrichment?

        Yes, we capture all files from the phishing emails. You can view these details are available as part of security incident observables in the form of a file hash.

      4. Do we send malicious files and links from phishing emails to a sandbox instance for investigation?

        Currently, we do not support out-of-the-box sandbox integrations for investigating malicious files and links.

      5. Is there a time window or a trigger that defines the duration in which incoming duplicate phishing email records are associated with a parent security incident?

        Duplicate phishing email records are aggregated only to an active parent security incident. If the parent incident is closed or canceled, then the incoming new duplicate phishing email will be created as a new security incident. However, in this scenario, within the new security incident, you can view the closed or canceled parent security incident in the Similar Security Incident related list.

        Note: This behavior can be configured using the flow designer.
      6. Does the User Report Phishing feature support the use of only the Microsoft Outlook Wombat plugin to capture email header details?

        The User Reported functionality has been built to parse email headers and complies with RFC822 standards. So, similar to the Wombat plugin, all other Microsoft Outlook plugins that capture email headers based on RFC822 standards are supported.

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login