With a deployed AWS sensor, USM Anywhere automatically discovers a number of out-of-box AWS logs when you have enabled them within your AWS subscription.
AWS CloudTrail provides a complete audit log for all actions taken with the Amazon API, either through the web UI, the CLIASCII text-based interface to an operating system or device, that allows execution of commands to perform operations such as administration, configuration, or other maintenance operations., or an SDK. Ongoing monitoring of this log gives you visibility of end-user and automated actions in your environment. This helps you quickly detect abuse cases and security incidents, such as a user trying to make changes to an AWS account that are inconsistent with their privileges.
USM Anywhere automatically detects AWS CloudTrail, and retrieves your CloudTrail logs across all regions by default. USM Anywhere also provides you the credentials to access your CloudTrail logs securely.
CloudTrail event names are automatically extracted from the logs. If you want to generate an alarm for certain CloudTrail event types, you can create an alarm rule and define the matching conditions for these potential events. For more information, see Managing Collected CloudTrail Event Logs.
Note: If you choose not to enable AWS CloudTrail, USM Anywhere processes all stored logs at initial start up. For information about enabling AWS CloudTrail, see the Amazon documentation.
The USM Anywhere Sensor automatically detects AWS Elastic Load Balancing (ELB) logs after you've enabled the AWS Classic Load Balancer in AWS. The Classic Load Balancer (formerly Elastic Load Balancer) logs provide an easy, yet effective way to monitor HTTP traffic for threats. The AWS Classic Load Balancer Access Logs provide insight into who is accessing your web resources. They also help you identify common abuse patterns and use of automated hacking tools, such as web application scanners. To learn how to enable Classic Load Balancer logging in AWS, refer to the Amazon documentation.
Important: You must enable Classic Load Balancer logs for every ELB that you want to monitor.
Unlike other AWS log collection jobs, you never schedule a new ELB job. After USM Anywhere examines your ELB logs, it creates jobs according to the logging configuration. After you enable these logs in USM Anywhere, it analyzes them and displays events.
AWS CloudWatch monitors applications, such as CloudTrail, and systems using log data, aggregating and storing application logs. This utility lets you transport log files from your running S3 Access Log instances to a place where USM Anywhere can access them without your having to change any network access settings.
Note: If you choose to enable CloudWatch in your AWS environment, you should make sure that you are not collecting more data than you need because this service incurs AWS costs based upon usage. Refer to the pricing information to plan and configure your usage.
CloudWatch Logs are useful, because you can easily configure them to process additional metadata with the log files. They also make moving log files around EC2 easy. AWS S3 and CloudWatch locations can automatically generate events based on CloudTrail, S3, ELB Access, and other security logs.
Follow the appropriate procedures for your operating system to configure the CloudWatch Logs Agent to use the EC2Config service.
- MS Windows — Sending Logs, Events, and Performance Counters to Amazon CloudWatch
- Linux — Install and Configure the CloudWatch Logs Agent on a Running EC2 Linux Instance
The default CloudWatch jobs in USM Anywhere assume the following group names and that all streams within a given group should be parsed using the mapped plugin. Make sure to configure your CloudWatch agents to use these group names and to keep the log types the same within a given log group.
|CloudWatch log group name||Plugin|
|IIS-Logs||Microsoft IIS plugin|
|Linux-Audit-Logs||Linux Auditd plugin|
|Linux-Auth-Logs||Linux SUDO plugin|
|Windows-System-Logs||AWS Windows plugin|
Important: If you want to collect other log types through CloudWatch and create a custom log collection job, streams should be separated from each other by data type.
For non-syslog data, all of the streams in the same group must be of the same type so that USM Anywhere can use a designated plugin to parse the collected raw log data. You can then set up a log collection job for each group using the correct plugin for the log data in that group.
Amazon Simple Storage Service (Amazon S3) is object storage with a simple web service interface that you can use to store and retrieve any amount of data from anywhere on the web. Organizations running an AWS environment typically use it as the primary storage for their cloud-native applications, as a bulk repository, as a target for backup and recovery, and as a log-term archive location.
Amazon S3 has the ability to provide complete access logs for all actions taken in an S3 bucket. When you enable this capability, it gives you insight into who is accessing the data, and what actions are being taken.
To learn how to enable S3 Access Logging, see Amazon's documentation.
Note: In AWS, you must enable S3 Access Logging in every S3 bucket that you want to monitor.
In Amazon EC2, it can be difficult to create direct network connections between isolated parts of your environment. Amazon S3 provides a convenient way to move application logs from an EC2 instance to an S3 bucket. Buckets are used to store objects, which consist of data and metadata that describes the data. You then configure the USM Anywhere Sensor to retrieve and process the log files.
You'll want to synchronize logs from your instance with an Amazon S3 bucket. There are multiple ways to do this. The easiest method is to use the AWS CLI documented by Amazon. You then create a script similar to the following example and configure it to run periodically as a cron job.
aws s3 sync "<path_to_log>" "S3://<bucket_name>/<storage_path>/"
For detailed information about creating S3 Access collection jobs in USM Anywhere, see Creating a New AWS S3 Access Collection Job.