Learn Wazuh - Cloud Security: AWS, Azure, and GCP Integration

#Introduction

In the previous episode 11, we finished discussing compliance, from GDPR, NIST, HIPAA, to PCI DSS. Now we move to an area just as important in the modern era: cloud security.

The cloud is a very dynamic environment. Resources move around, resize, and can be born and die within seconds. Old security models that relied on physical firewalls are clearly insufficient. In episode 12, we discuss how Wazuh reads security signals from the three biggest providers: AWS, Azure, and GCP.

Our focus isn't only configuration, but also the data flow. We'll see how cloud events enter Wazuh, get normalized into alerts, then appear in the dashboard. Let's start with the most widely used provider, AWS.

#Why Cloud Integration Matters

Before touching configuration, it's important to understand why cloud integration is a flagship Wazuh feature.

• Cross visibility: Wazuh combines endpoint events and cloud events in a single view.
• Anomaly detection: suspicious activity like root account usage immediately becomes an alert.
• Compliance: many of the standards we discussed in episode 11 require an audit trail for the cloud.
• Fast response: the combination of rules and active response can close gaps before they spread.

#AWS Integration

The AWS module in Wazuh is the aws-s3 wodle. As its name suggests, this module polls events from S3 buckets containing logs of various AWS services: CloudTrail for API calls, GuardDuty for machine learning findings, S3 access logs, CloudWatch, and AWS Config. You can define several buckets at once, each with its own type and polling interval.

#Setting Up IAM Roles and Credentials

Wazuh needs credentials to read the bucket. The safest approach is a cross-account IAM role with minimal permissions, only s3:GetObject and s3:ListBucket. That role is then referenced in the module configuration, or you can use an access key and secret key temporarily.

#Configuring the aws-s3 Module in ossec.conf

Add the wodle block in /var/ossec/etc/ossec.conf. This section tells the manager which buckets to poll and how often.

ossec.conf aws-s3 section

<ossec_config>
  <wodle name="aws-s3">
    <disabled>no</disabled>
    <interval>10m</interval>
    <bucket type="cloudtrail">
      <name>wazuh-cloudtrail</name>
      <path>s3://wazuh-cloudtrail</path>
      <iam_role_arn>arn:aws:iam::123456789012:role/wazuh-reader</iam_role_arn>
    </bucket>
    <bucket type="guardduty">
      <name>wazuh-guardduty</name>
      <path>s3://wazuh-guardduty</path>
      <iam_role_arn>arn:aws:iam::123456789012:role/wazuh-reader</iam_role_arn>
    </bucket>
  </wodle>
</ossec_config>

After changing ossec.conf, restart the manager so the configuration is read.

systemctl restart wazuh-manager

The aws-s3 module works on a polling cycle. At each interval, it checks the bucket, picks up new events, processes them into alerts, then stores the last read position. If the event volume is large, shorten the interval. If the bucket is quiet, lengthen it to save resources. Make sure the bucket is receiving events before enabling the module, for example by enabling CloudTrail via the aws CLI.

#Azure Integration

The Azure module in Wazuh is the azure-logs module. This module reads two main source types:

• Activity Logs: Azure control plane activity, like VM creation or policy changes.
• Microsoft Defender for Cloud: security findings already collected by Defender.

#Setting Up a Service Principal

Azure access is done through a service principal. Create an app in Microsoft Entra ID, then grant it the Reader role on the subscription using the az CLI.

az ad sp create-for-rbac --name wazuh-reader --role Reader

That command's output contains appId, password, and tenant. All three values are used in the module configuration.

#Configuring the azure-logs Module

ossec.conf azure-logs section

<ossec_config>
  <wodle name="azure-logs">
    <disabled>no</disabled>
    <interval>10m</interval>
    <application_id>11111111-aaaa-bbbb-cccc-dddddddddddd</application_id>
    <tenant_domain>your-tenant.onmicrosoft.com</tenant_domain>
    <client_secret>p4ssw0rdEXAMPLE</client_secret>
    <la_type>azure_activity_logs</la_type>
    <tag>azure-activity</tag>
  </wodle>
</ossec_config>

Once the configuration is done, restart the manager. The module will pull events from Log Analytics and forward them to the rules engine.

#GCP Integration

GCP takes a different approach. Instead of polling buckets, Wazuh subscribes to messages from Google Cloud Pub/Sub. The provider streams audit logs to a topic, and the module reads the subscription. Use the gcloud CLI to create the topic and subscription.

gcloud pubsub topics create wazuh-audit-log
gcloud pubsub subscriptions create wazuh-audit-sub --topic wazuh-audit-log

#Configuring the gcp-pubsub Module

ossec.conf gcp-pubsub section

<ossec_config>
  <wodle name="gcp-pubsub">
    <disabled>no</disabled>
    <project_id>my-gcp-project</project_id>
    <subscription_name>wazuh-audit-sub</subscription_name>
    <credentials_file>/etc/wazuh/gcp-credentials.json</credentials_file>
    <max_messages>10</max_messages>
  </wodle>
</ossec_config>

The gcp-credentials.json file is a service account key with pubsub.subscriber permission. Store it outside any public directory and make sure only the wazuh user can read it.

#Audit Logs and the Security Command Center

GCP has two important security sources: Cloud Audit Logs, which record admin activity, and the Security Command Center, which aggregates security findings from various sources. Both can be routed to the same topic so Wazuh reads them in a single stream. Set up export filters in Cloud Logging so only relevant events are sent.

#Detecting Cloud Events in the Dashboard

All incoming cloud events become documents in the indexer and can be searched in Discover. Create a saved query with filters like data.aws.source or data.azure.tenantId to separate providers, and use the rule.mitre.id field to group alerts by ATT&CK technique. An example query to find root account activity in AWS:

data.aws.source: cloudtrail AND userIdentity.type: Root

Typical alerts that often appear in real deployments include security group changes, new access key creation, and unusual activity outside working hours.

#Credentials Best Practices

Credentials are the heart of cloud integration. A few rules we hold to in production:

• Use cross-account IAM roles with minimal permissions, not permanent access keys.
• For GCP, use a service account with the narrowest possible scope.
• Rotate secrets regularly and never put them in a repository.
• Monitor Wazuh's own logs to make sure the cloud modules never fail authentication.

#Conclusion

In episode 12, we covered Wazuh integration with the three cloud providers. For AWS, the aws-s3 module reads CloudTrail, GuardDuty, S3 access logs, and CloudWatch from S3 buckets. For Azure, the azure-logs module reads activity logs and Defender findings via a service principal. For GCP, the gcp-pubsub module subscribes to Pub/Sub topics containing audit logs and the Security Command Center.

Key takeaways:

• Cloud modules read events from buckets, Log Analytics, or Pub/Sub, not directly from provider APIs.
• Configuration is done through wodles in /var/ossec/etc/ossec.conf.
• IAM roles and service accounts should have minimal permissions.
• Polling intervals need to be adjusted to the event volume.
• All cloud events enter the indexer and can be analyzed in the dashboard.
• Credentials must never end up in a repository.

With the cloud connected, the next challenge is container environments. In episode 13, we'll discuss Wazuh integration with Docker and Kubernetes, from monitoring containers to deploying Wazuh in a K8s cluster. Stay tuned!