AWS GuardDuty Integration via API

Guide to Retrieving AWS GuardDuty API Credentials for Logsign USO Integration

To integrate AWS GuardDuty logs into Logsign USO via API, users need to provide the following credentials:

• Access Key
• Secret Key
• Region
• Detector ID

This guide explains how users can retrieve these credentials from the AWS Management Console.

1. Getting the Access Key & Secret Key

To make API calls, an IAM user with appropriate permissions must generate an Access Key and Secret Key.

Create an IAM User or IAM Role

1. Log in to the AWS Management Console.
2. Navigate to the IAM service.
3. Go to the Users section and create a new user or select an existing one.
4. In the Permissions tab, assign the following permissions:

• AmazonGuardDutyReadOnlyAccess
• AWSGuardDutyFullAccess (if administrative access is needed)
• AWSGuardDutyReadOnlyAccess (if only read access is required)

5. Open the Security credentials tab.
6. Click Create access key.
7. Select Programmatic access.
8. Click Create key and save both the Access Key ID and Secret Access Key.

(Secret Key will only be shown once—store it securely!)

Where to Find It?

• AWS Console → IAM → Users → [User Name] → Security Credentials

2. Retrieving the AWS Region

GuardDuty operates in specific AWS regions, and users must specify the correct Region for API calls.

Find the Active AWS GuardDuty Region

1. Log in to the AWS Management Console.
2. Open the GuardDuty service.
3. Click on the region selector in the upper-right corner.
4. Choose the region where GuardDuty is active.

Example Regions:

• us-east-1 (N. Virginia)
• us-west-2 (Oregon)
• eu-central-1 (Frankfurt)

Where to Find It?

• AWS Console → Upper-Right Menu → Region Selector

3. Finding the Detector ID

Each AWS account can have one or more Detectors in GuardDuty. The Detector ID is required for API requests.

Locate the GuardDuty Detector ID

1. Log in to the AWS Management Console.
2. Open the GuardDuty service.
3. Navigate to the GuardDuty Dashboard.
4. Click on the Detectors tab.
5. Find and copy the Detector ID.

Where to Find It?

• AWS Console → GuardDuty → Detectors

Summary

To successfully integrate AWS GuardDuty logs into Logsign USO via API, users need to retrieve specific credentials from the AWS Management Console:

• Access Key & Secret Key: These credentials can be obtained by navigating to the IAM service in AWS. Users should go to the Users section, select the relevant user, and find the Security Credentials tab, where they can create and manage access keys.
• Region: The AWS region where GuardDuty is active can be found in the AWS Management Console at the upper-right corner of the interface. Users should select the appropriate region from the Region Selector menu.
• Detector ID: The unique Detector ID for GuardDuty can be located within the GuardDuty service. Users should open the GuardDuty Dashboard, go to the Detectors section, and copy the relevant Detector ID.

By following these steps, users can obtain the necessary credentials to configure API access for GuardDuty log integration with Logsign USO.

Settings > Data Collection > API > AWS GuardDuty

You can then add your source to Logsign USO by processing the data you have obtained in the specified fields.

Incidents and Alert Rules

Each GuardDuty finding collected by this integration is also turned into a Logsign incident. A finding that Logsign has already seen updates the incident it belongs to instead of opening a new one, so a finding whose severity or count changes on the AWS side stays a single incident in Logsign.

When a finding opens a new incident, Logsign additionally sends an alert-shaped copy of that finding through the parser. The copy carries the identifier of the incident that was just created. If it matches one of your alert rules, the action rules attached to that alert rule run against the existing GuardDuty incident rather than creating a second, duplicate incident for the same finding.

What this means in practice:

• You can write alert rules against GuardDuty findings and attach action rules (notification, ticketing, response integrations) to them, and they will act on the incident the poller already created.
• You will not see two incidents for the same finding when an alert rule matches it.
• Findings that update an existing incident do not re-trigger the alert copy; only newly created incidents do.

This is the same mechanism used by the IBM QRadar EDR and HarfangLab EDR integrations. Incident creation itself is unchanged; nothing needs to be configured on the AWS side for it.