Implementing a SIEM in AWS (2024)
A Security Information and Event Management (SIEM) system provides real-time monitoring, analysis, and reporting of security-related events in an IT infrastructure. It combines both Security Information Management (SIM) and Security Event Monitoring (SEM), offering centralized log management, analytics, and compliance capabilities.
Key features of a SIEM system include:
Centralized log collection: Collects event logs from diverse sources such as servers, network devices, and applications.
Real-time monitoring: Continuously monitors the IT infrastructure for security-related events or suspicious activity.
Event correlation: Identifies relationships among different security incidents and consolidates them into meaningful alerts.
Threat detection and response: Detects, analyzes, and responds to potential threats in real-time based on predefined rules and policies.
Compliance reporting: Helps organizations ensure compliance with various industry regulations and standards such as HIPAA by generating customizable reports.
User behavior analytics: Analyzes user activity patterns to detect any deviations that may indicate insider threats or compromise.
In summary, a SIEM system plays a crucial role in enhancing security posture, detecting and responding to threats faster, and maintaining compliance within the organization's IT infrastructure.
Historically, cloud platforms such as AWS have provided basic SIEM-like capabilities in their foundational services, while security and log management vendors provided robust alternatives. In regulated industries such as healthcare and financial services, using multiple vendors to manage sensitive data increases the burden of compliance and risk management. Not surprisingly, AWS has been evolving its platform’s SIEM capabilities based on customer feedback. For example, AWS used the open source version of Elasticsearch to create the OpenSearch project which eventually was offered as a managed service. Recently, AWS GuardDuty rolled out run-time monitoring of ECS/EKS containers and EC2 instances (with limited OS support as of March 2024).
In this article, we’ll evaluate several approaches for implementing a SIEM in AWS that make use of several AWS services as well as open source solutions.
Solution One: Security Hub + CloudWatch Logs
AWS Security Hub started out as a security posture assessment service, helping organizations align the configuration of AWS accounts with several security frameworks (example: NIST SP 800-53). Security Hub now does what its name actually implies, aggregating security findings from multiple AWS services.
CloudWatch Logs provides the capability to store logs from other services and create filters and alerts on matches of specific text patterns. Many AWS services provide an option to configure logging to a custom CloudWatch Logs group. For EC2 instances, you can install the CloudWatch agent and configure it to collect server logs from any directory or Windows Events.
Solution Overview
Enable security-related auditing and security AWS services
Configure CloudWatch Logs and integrations
Create CloudWatch Logs filters and CloudWatch Alarms
Create SNS topics and subscriptions
Details
First, enable CloudTrail, ensuring multi-region support is enabled and logs are saved to both CloudWatch Logs (short term retention, used for detecting patterns in events to trigger alerts) and S3 (more cost effective for long term retention). Enable additional services such as AWS Config, GuardDuty, IAM (Access Analyzer), Inspector, and Macie. Finally, activate Security Hub, turning on one or more standards such as AWS Foundational Security Best Practices, Center for Internet Security (CIS) AWS Foundations Benchmark, and National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5.
Within 24 hours, you’ll see a list of findings that should be remediated in other services (or suppressed, if not applicable). It is possible to leverage services like EventBridge and Lambda functions to automatically remediate findings. AWS provides a solution, Automated Security Response on AWS, that can handle most findings. If going the manual remediation route, EventBridge can be used to send a message to an SNS alert for any Security Hub finding.
Security Hub does not ingest CloudWatch Logs, so any security-related events must be parsed with a different solution. CloudWatch Logs support filtering (for the “standard” retention tier) and creating metric filters. Since CloudTrail is configured to publish its events to CloudWatch Logs, you can create filters and alarms for things like Console logins, authentication failures, VPC security changes, and so on. AWS provides examples of how to create these filters as part of the Security Hub documentation for CloudWatch. Corresponding CloudWatch Alarms can be created to route alerts through the Simple Notification Service (SNS) and distributed to email subscriptions or external API endpoints. Slack and Teams can be ideal destinations for these types of alerts.
The above pattern is not just limited to processing CloudTrail events. Recall that the CloudWatch agent can bring in logs from EC2 instances. You can create custom filters to detect SSH authentication events, changes to system packages, and significant events in Web server logs.
The primary disadvantage of this solution is that a portion of your security events will not be accessible in Security Hub, requiring you to collect the CloudWatch Logs related events from your email inbox (or Slack/Teams). This can become tedious during risk assessments and audits. So, let’s look at a more integrated solution…
Solution Two: An OpenSearch-Backed SIEM
AWS published a blog post back in 2022 about using the OpenSearch managed service with Security Hub to aggregate security events as part of a SIEM implementation. At the time, Security Hub was mostly limited to verifying compliance against its security controls and did not source as many AWS services as it does today. AWS also provided a CloudFormation template for the solution in a public repository.
Figure 1: Example of Amazon on OpenSearch SIEM Dashboard
The key advantages of this solution include:
a more comprehensive dashboard compared to what Security Hub offers
ability to ingest CloudTrail logs directly (from S3) instead of relying on CloudWatch Logs
integration with other AWS services that don’t provide the option to publish to CloudWatch logs and/or don’t integrate with Security Hub
integration with other log types such as Apache and Nginx, avoiding the need to send them to CloudWatch Logs first
Clearly, there is more overhead in deploying and managing this solution, and a production-grade OpenSearch cluster with the supporting services listed in the solution architecture will drive up the monthly costs significantly, depending on instance types used, data retention period, and the amount of data being processed.
This solution also does not include any threat response functionality. Recall, that an ideal SIEM will be able to respond to potential threats in real-time based on predefined rules and policies. Let’s look at another option…
Solution Three: Wazuh Open Source SIEM
Wazuh is an open source fork of the OSSEC intrusion detection system (IDS) project with significantly more features to offer. It uses the open source OpenSearch project (Elasticsearch and Splunk are supported) for its backend storage. Wazuh provides integrations with many AWS services and useful dashboards including one specific to HIPAA compliance.
Because Wazuh’s foundation is an IDS, it provides a unique capability compared to the above solutions. The product can be configured to automatically respond to real-time threats, for example, blocking malicious network events. Wazuh also includes file integrity monitoring, a requirement that often comes up in security certifications like SOC2 and HITRUST.
Figure 2: Wazuh dashboard summarizing security events for several servers
Figure 3: Wazuh dashboard with HIPAA-specific functionality
Similar to solution two, higher monthly costs will be a factor when deploying the Wazuh stack to your AWS environment. However, its flexible deployment options (virtual machines, Docker containers, Kubernetes) provide the ability to fine tune costs.
Other Options
The security marketplace is replete with SIEMs and other product suites that include similar features. Some vendors are investing heavily into AI to cut down on noisy alerts and to be able to help security engineers focus on the most important security incidents. If HIPAA compliance is applicable to your deployment, there are additional considerations involved:
Can the vendor sign a Business Associate Agreement?
Can the solution be deployed to a VPC in your AWS account to keep organizational data siloed? If not, how is data protected and what kinds of controls are in place to ensure sensitive data is not accessible by other vendor customers, contractors, and other unauthorized individuals?
What does the vendor’s disaster recovery plan look like? What are the RPO and RTO objectives?
How do costs increase in response to scaling of infrastructure resources and growth of data over time?
It is expected that AWS will continue evolving Security Hub to do more. Meanwhile, we like Wazuh based on our collective experiences with the OSSEC IDS, its AWS integrations, and HIPAA compliance reporting features. Wazuh reduces some of the burden associated with security incident management and organizational risk management.
