AlertOps and GuardDuty

AlertOps’ alert management system can be integrated with GuardDuty to receive and respond to critical (predefined status mappings) alarms/alerts through email, SMS, push notification or phone alerts. AlertOps would ensure that the alert would reach the appropriate team by using proper workflows, escalation policies and schedules. Based on your ruleset, incidents can be automatically opened and closed, depending on whether GuardDuty reports a problem or a recovery.

The above scenario and scope for integration is due to the fact that AlertOps has a very flexible and simple API/Webhook configuration feature that can be leveraged with GuardDuty’s monitoring and action capabilities. 

GuardDuty – Basics

As you know already, GuardDuty is a security monitoring service that analyzes CloudTrail logs, VPC logs, S3, and DNS logs to generate and report security findings for your AWS account. It starts monitoring immediately (after it is enabled) and is a regional service.  

Amazon CloudWatch

While GuardDuty generates potential security findings by continuously monitoring different data sources, CloudWatch is used to build event rules to send alerts to external parties (through SNS topics). Amazon CloudWatch is a monitoring service for cloud resources of Amazon Web Services (AWS) and the applications that you run on it. It can be used to collect, track and monitor metrics, log files, set alarms and automatically react to changes in resources of your AWS environment.

GuardDuty creates an event for Amazon CloudWatch Events when any change in findings takes place. Finding changes that will create a CloudWatch event include newly generated findings or newly aggregated findings. Events are emitted on a best effort basis. Every GuardDuty finding is assigned a finding ID. GuardDuty creates a CloudWatch event for every finding with a unique finding ID. All subsequent occurrences of an existing finding are aggregated to the original finding.

By using CloudWatch events with GuardDuty, you can automate tasks to help you respond to security issues revealed by GuardDuty findings.

Amazon Simple Notification Service (SNS)

It is important to know this service that AWS provides for the purpose of notifications since GuardDuty does not directly send out notifications to an external service in case of an issue. Instead, we need to create an SNS topic that will receive the notification and then send out the incident information to an external service (in this case AlertOps). AlertOps must be subscribed to the ‘SNS Topic’ to receive payload from it.

Amazon SNS is a pub-sub functionality and provides a fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication. The pub-sub functionality provides ‘Topics’ for push-based messaging between applications and many other types of systems. Topics can fanout messages to a lot of subscriber systems and in this case, a HTTPS endpoint.

AlertOps has to be subscribed to a particular SNS Topic in order to recieve messages from the topic and manage them accordingly. This SNS topic would be attached to a CloudWatch/GuardDuty event rule, that would execute this particular topic, when an issue occurs.

AlertOps -  Inbound Integration

To configure an Inbound Integration in AlertOps to receive alerts from CloudWatch/SNS

1. Under 'Configuration' select 'Integrations'. From the Inbound Integration section, select 'API' from the dropdown and then click the 'Add API' button.
2. Select AWS Guard Duty  from the list of available integration options.
3. Once you select the integration, you can then specify basic settings like the integration name, escalation policy, names of the recipients/groups for which the alerts must be assigned to.
4. Once you click save, the API Integration will be created, and you will be given a unique URL which acts as the access point and needs to be configured at the source (in this case the SNS Topic), to send notifications. You can find the integration you just created, and you can give advanced settings and define various configurations for the alerts to be received and processed. For example, you can define when to open and close alerts based on the response obtained from the API call, filters etc.
5. Make a note of the API URL, which will be used in SNS topic, so it calls a HTTP POST request to this URL with the body in JSON format containing the event specific information. Alerts will be recorded in the ‘Inbound Log’ section table. AlertOps automatically creates an alert when the severity is 5 to 10 (as per the definition in the screenshot below). If an alert-status matches an already opened alert, AlertOps will identify this as a duplicate and will be recorded as “Mapped Appended”. The incident will also be closed automatically when the severity 0 is received.
6. As you can see in the below screenshot, AlertOps will open an alert when the ‘Message^severity’ field from the JSON payload received (mapped to SourceStatus), contains the values 5 to 10. You can similarly define URL mappings as you want, owing to the flexibility provided by AlertOps’ API integrations. You can also test the generated URL.

Configuration of GuardDuty/AWS SNS for AlertOps Integration

Now that we have setup AlertOps with the AWS GuardDuty API Inbound Integration, along with a unique API URL; we can now define a Webhook connection in Amazon SNS to access this API and send out event notifications to AlertOps.

Let’s recall what we have done so far – we have enabled GuardDuty so that it monitors logs and sends events to CloudWatch; we have also set up an inbound integration in AlertOps and have a unique URL to which these events must send notifications to.

However, CloudWatch doesn’t send event information directly to an external client, instead it sends the notification to an attached SNS Topic, which in turn would connect to an external HTTPS endpoint and push the notification (refer to the previous section for a high-level flow diagram). Let us configure an SNS topic and attach it to the CloudWatch event rule.

Create an SNS Topic and Subscription

1. Go to Services – select Amazon SNS.
2. In the left tab – select Topics – Create Topic
3. Select Standard – Give a name to the topic. You can configure other options as you need to.
4. Once you create the topic, in the left tab – select Subscriptions – Create Subscription
5. In the Topic ARN option, select the name of the topic you just created.
6. For protocol – select HTTPS, and in the endpoint – paste the API URL which you obtained when you created the inbound integration. You can configure other options as you need to.
7. Once you create the subscription, go to Topics, select the topic you created – you must have a screen as below,
8. In the “Subscriptions” section, you will have a status that says, “Pending Confirmation”. This means that AlertOps hasn’t yet subscribed to this topic to receive notifications. (The below screenshot shows “Confirmed”)