Help with duplicate automated incident

AwanishK
Tera Contributor

3 hours ago

Hi Community.

 

I am working on an incident which is regarding duplicate automated incident creation. So, the issue is Amazon GuardDuty is creating duplicate incidents for same issue and assigning to different groups which leads to confusion between teams.

 

I am attaching a screenshot which shows the work note of the autonomous incident. The problem is I am unable to find the root of these alerts/integrations. I have not worked with automated incident creation and would appreciate any help on where to look for the root cause.

The incident's contact type is 'Automated Alert' and the caller is an AWS bot. The short description/description always reads '[Amazon GuardDuty Finding] Recon:EC2/PortProbeUnprotectedPort - Finding Severity: Low'.

Preview file
125 KB
0 Helpfuls
  • 93 Views
1 REPLY 1

Itallo Brandão
Giga Guru

2 hours ago

Hi @AwanishK,

Based on the screenshot and the text format ("Hello, This is an automatic update notification..."), this looks highly likely to be coming from an Inbound Email Action or the AWS Service Management Connector failing to deduplicate the findings.

Here is the step-by-step to find the root cause and stop the duplicates:

1. Identify the Source (Email vs. API)

  • Open one of the duplicate incidents.

  • Right-click the header -> History -> Calendar.

  • Look at the very first entry (CREATE). Who is the user in the "Updated by" / "Created by" field?

    • If it is "guest" or "system": It is likely an Email Inbound Action.

    • If it is a specific user (e.g., aws_integration): It is likely a REST API or the AWS Connector App.

2. Scenario A: It is coming via Email (Most Likely) The text in your screenshot says "Count: 1210". GuardDuty sends emails every time the count increases.

  • The Issue: If the Subject Line of the email changes (e.g., includes the timestamp or count) and there is no ServiceNow Watermark (Ref:MSG...) in the body, ServiceNow treats it as a New Email instead of a Reply.

  • The Fix:

    1. Go to System Policy > Email > Inbound Actions.

    2. Search for the script that sets contact_type to "Automated Alert".

    3. You need to modify the script to search for an existing active incident with the same "GuardDuty Finding ID" (you might need to extract this ID from the email body using Regex and store it in a Correlation ID field) before creating a new one.

3. Scenario B: It is the AWS Connector If you are using the official AWS Service Management Connector:

  • Navigate to System Import Sets > Administration > Transform Maps.

  • Search for maps related to "AWS" or "GuardDuty".

  • Check the Coalesce field.

  • The Fix: Ensure that the "Finding ID" (unique ID from AWS) is set to Coalesce = True. If the integration is not coalescing on a unique ID, it will create a new record for every update payload sent by AWS.

Why different groups? Since duplicates are being created, your Assignment Rules or Flows run freshly on every new ticket. If the payload contains different data (e.g., different Source IP or Region), your rules might be routing them differently each time. Fixing the deduplication (preventing the new ticket) will solve the assignment issue automatically.

If this response helps you solve the issue, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards,
Brandão.

0 Helpfuls