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.

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.
   • UserID Rule: Filter emails that have been sent from a specific email id.

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

1. Navigate to Security Operations > Email Processing > 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.

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

• Navigate to Flow Designer > Designer to view the flows available with the Security Operations spoke.
  
• 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 , 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.
  

  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.
  
• 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.
  
• 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.
  

  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.

  

  These two actions are performed when this subflow is executed. Click on the link of the first action to view additional details.
  
  

  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.
  
  
  
• 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.
  
  
• 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.
  
  
• In step 6, whitelisted observables are filtered from the list of observables in the security incident. These whitelisted observables will not be added to the security incident.
  
  
• In step 7, unknown observables from the user-reported phishing email are identified and added to the Observables related list.
  
  
• 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.
  
  
• 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.
  
  
• In step 10, the parent security incident is identified and a check is made to see if it is an open 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.
  
  
• In step 13, a worknote is added with the list of whitelisted 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.

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