Introducing New Relic I/O, your hub for instant observability. Find a quickstart for your stack

Monitor the security of your AWS environment with GuardDuty, CloudTrail, and New Relic One

5 min read

Cloud computing provides many benefits, including flexibility and scalability, but you also have to deal with potential security issues due to misconfiguration or malicious actors. If you are using Amazon Web Services (AWS), Amazon GuardDuty can help you address these issues. In this post, you will learn how to combine GuardDuty with AWS CloudTrail and New Relic One to monitor your cloud services for threats. 

Amazon GuardDuty is a threat detection service that protects your AWS accounts, workloads, and data, while CloudTrail is a service that allows you to monitor and log activity across your AWS infrastructure.

By integrating these tools with New Relic’s observability platform, you can:

  • Correlate AWS security and compliance events with the rest of your telemetry data, including metrics, events, logs, and traces.
  • Visualize these events in New Relic One dashboards and programmable apps for reporting and display purposes.
  • Alert your teams for faster resolution of security events.
  • Retain data related to GuardDuty findings in New Relic beyond the quotas provided by AWS.

The next image shows a visualization of GuardDuty’s reported security issues in a New Relic dashboard.

Dashboard shows visualization of GuardDuty security issues in New Relic One.

Setting up AWS GuardDuty

To set up AWS GuardDuty with New Relic Logs, you need to configure Amazon EventBridge to receive events from GuardDuty, then set up an Amazon Kinesis Firehose delivery stream to receive events from EventBridge and stream them to New Relic Logs. The architecture is pictured in the next illustration.

Boxes show that information flows from GuardDuty to EventBridge to Kinesis to New Relic Logs.

It's time to prepare GuardDuty to send alerts via EventBridge and a Kinesis Firehose delivery stream. Here are the steps:

  1. Create a Kinesis Firehose delivery stream to send logs from AWS to New Relic.
  2. Enable GuardDuty for AWS accounts you want to monitor.
  3. Create a rule in EventBridge. As shown in the next image, define the pattern by selecting the following:  
  • The Event matching pattern should be Pre-defined pattern by service.
  •  The Service provider should be AWS.
  • The Service name should be GuardDuty.
  • The Event type should be All Events.
The Define pattern screen with configuration included.
  1. For Select targets, select Firehose delivery stream and choose the stream you created in step one.
Select targets screen.
  1. In New Relic One, click on the Query your data button and enter the following NRQL query:

    FROM Log SELECT * WHERE detail.service.serviceName = 'guardduty'

    If no data is displayed, verify whether GuardDuty has reported any findings yet in the GuardDuty console. Each finding will become a single log entry in New Relic One.

Setting up CloudTrail

New Relic One provides an integration for CloudTrail which uses API polling to capture events. Use this guide to connect your AWS account to New Relic One using the API polling method to start capturing CloudTrail events in your New Relic One account.

If you’re already using CloudWatch Metric Streams to receive metric data from Amazon CloudWatch, you still need to configure an API polling integration to receive CloudTrail events (since these are events, not metrics). Just make sure that when you create the API polling integration, you only check the CloudTrail checkbox to prevent duplicate metrics.

Check CloudTrail when selecting which AWS services to monitor.

Adding a dashboard visualization

In order to report on these findings, you need to install AWS Security & Compliance from the Quickstarts dashboard library. 

In New Relic One, select the magnifying glass to the right of Apps in the top navigation menu and search for Quickstarts. If you haven’t used Quickstarts before, you will be given an option to enable them.

Search for and select quickstarts.
  1. Search for AWS Security and import the dashboard into your account.

Here are some use cases for this integration once you have completed the setup steps.

SSH Brute Force Attacks

FROM Log SELECT * WHERE detail.type = 'UnauthorizedAccess:EC2/SSHBruteForce' SINCE 7 days ago

GuardDuty detects SSH brute force attacks. Brute force attacks involve an attacker attempting to gain access to an Amazon Elastic Compute Cloud instance via SSH by guessing the password using a dictionary of potential passwords.

Examples of GuardDuty detecting brute force attacks.

One way to mitigate these attacks is to set up key-based SSH authentication or use a security group that only allows SSH connections from a known IP address such as a bastion host.

Public or anonymous access granted to S3 Buckets

FROM Log SELECT * WHERE detail.type = 'Policy:S3/BucketAnonymousAccessGranted' SINCE 7 days ago

Publicly accessible S3 buckets have been the source of many famous data breaches and security incidents. Attackers can potentially access sensitive data stored in unsecure S3 buckets. GuardDuty detects changes to S3 bucket configurations and highlights potential misconfigurations that could lead to issues.

Alerting on findings from GuardDuty

By using NRQL alerts, you can get notifications when GuardDuty surfaces any of these findings. Using the examples above, here are the queries you would use for an alert.

Public or anonymous access granted to S3 buckets

FROM Log SELECT count(*) WHERE detail.type = 'Policy:S3/BucketAnonymousAccessGranted'

SSH brute force attacks

FROM Log SELECT count(*) WHERE detail.type = 'UnauthorizedAccess:EC2/SSHBruteForce'

Set a static threshold of 1 to be notified each time GuardDuty finds a security event, as shown in the next image.

Set condition threshold for above 1 at least once in 2 minutes.

Conclusion

When you integrate AWS security and compliance events into your New Relic One account, you get visibility into security issues in your AWS environment. You can speed up remediation by alerting the right team members and correlating events with other sources of telemetry such as logs and metrics.