While talking about Azure Sentinel with cybersecurity professionals we do get the occasional regretful comment on how Sentinel sounds like a great product but their organization has invested significantly in AWS services so implicitly, Sentinel is out-of-scope of potential security controls for their infrastructure.
AWS offers the CloudWatch service that is able to collect performance data, events and logs from a wide range of AWS services, including VMs, storage, databases, CloudTrail, Security Hub, GuardDuty, etc. potentially any service. CloudWatch can also raise alerts triggered by thresholds reached in the data it collects as well as provide dashboards with various types of visualizations. However, is CloudWatch a SIEM? To answer that question, let’s look at the traditional SIEM functionality:
SIEM Architecture
From this diagram, we can see that AWS CloudWatch is still missing some critical components that would qualify it as a SIEM: ability to collect logs from network and security devices, full log management and retention capabilities, data enrichment and arguably a more functional user interface. However, its ability to aggregate events and logs from a wide range of AWS services allows it to be a central point of contact for 3rd party applications that can provide enhanced analytical capabilities.
To test a potential integration with Azure Sentinel, we have configured AWS CloudWatch to collect logs from an EC2 VM hosting an Apache website. From the same VM (Linux-based) we’ve also configured the CloudWatch agent to collect the Linux audit logs. We’ve also configured AWS CloudTrail and Security Hub to send its logs to CloudWatch and GuardDuty to send its findings to dedicated CloudWatch logs.
With the data collecting in CloudWatch, we built a custom log collector that is capable of polling the CloudWatch logs at regular intervals and send the updates directly to Azure Sentinel.
The collector is based on a combination of scheduled AWS log downloads using https://github.com/jorgebastida/awslogs and Elastic Filebeat and Logstash. Here are is the script (scheduled in cron) to retrieve the relevant logs:
As per the script above, the AWSLogs is used to retrieve Apache, audit, CloudTrail and GuardDuty logs every minute. Once the logs are retrieved, Filebeat sends to new log entries to a server running Logstash that parses each log entry accordingly and sends it to Sentinel using the Log Analytics Logstash plugin. The logs are onboarded as custom logs (CloudWatchApache_CL, CloudWatchAudit_CL, CloudWatchCloudTrail_CL, CloudWatchGuardDuty_CL) so some data enrichment provided by Microsoft (such as mapping against know malicious IPs) will not be available.
Azure Sentinel does offer a native AWS CloudTrail data connector however, CloudTrail provides only a subset of AWS logging data (related to user activity). CloudTrail can send its logs to CloudWatch but not the other way around.
With the data received by Azure Sentinel, one can quickly build relevant use cases to monitor the wealth of data provided by CloudWatch, allowing AWS users to benefit the services of a powerful cloud-based SIEM product without significant redesign of their AWS logging infrastructure.
Sample Azure Sentinel dashboard using AWS CloudWatch logs:
Of course, the data behind all these dashboards can be used for alerts, reports, playbooks, SOAR and all the other goodies offered by a fully-fledged SIEM.