Monitoring & Logging

I created the projectzero-prod-datalake-msegrt S3 bucket in eu-north-1 to serve as the centralized storage location for security logs and findings.

I configured the S3 bucket with ACLs disabled and Block Public Access enabled to prevent security telemetry from being exposed publicly. Default server-side encryption using SSE-S3 was enabled to protect stored logs at rest.

I created dedicated S3 prefixes to separate security telemetry by source, keeping the data lake organized for downstream ingestion and analysis.

I configured an S3 bucket policy allowing GuardDuty and CloudTrail to write security telemetry to their designated prefixes while keeping the data lake private.

I created a dedicated IAM user, projectzero-wazuh-s3-user, to provide Wazuh with controlled access to the S3 security data lake. I then created and attached the projectzero-wazuh-s3-read-policy, granting only the S3 permissions required to retrieve and process security telemetry.

I configured the AWS CLI on projectzero-sec-box, the security monitoring server hosting Wazuh, using the credentials for the dedicated projectzero-wazuh-s3-user IAM account. The credentials were configured under the root user so the Wazuh AWS integration can authenticate to AWS and retrieve security telemetry from the S3 data lake.

On projectzero-sec-box, I configured a Wazuh Index State Management (ISM) policy to automatically delete wazuh-alerts-* indices after 14 days. This provides controlled log retention while limiting storage consumption within the lab environment.

I created the projectzero-prod-management-trail multi-region trail and configured it to deliver logs to the cloudtrail/ prefix of the existing projectzero-prod-datalake-msegrt S3 security data lake. I enabled management read/write events and Lambda write data events to capture security-relevant AWS activity.

I configured an S3 lifecycle rule for the cloudtrail/ prefix within the projectzero-prod-datalake-msegrt security data lake to manage CloudTrail log retention. The rule removes noncurrent object versions after 14 days, providing controlled retention while limiting unnecessary storage consumption within the lab environment.

I verified that CloudTrail logs were being delivered to the cloudtrail/ prefix within the projectzero-prod-datalake-msegrt security data lake. The generated AWSLogs/ structure confirms that CloudTrail is successfully writing telemetry to the configured bucket.

I configured the Wazuh AWS S3 integration to retrieve CloudTrail telemetry from the cloudtrail/ prefix using the previously configured AWS credentials. The integration runs every 10 minutes and processes logs stored in the centralized S3 security data lake.

After restarting the Wazuh Manager, I verified that the AWS S3 integration was successfully connecting to the data lake and fetching logs for processing.

I created the trancejedi IAM user to generate test AWS activity and validate the complete CloudTrail monitoring pipeline. I confirmed that the IAM activity was captured by CloudTrail, delivered through the S3 data lake, and successfully ingested into Wazuh.

I updated the existing projectzero-wazuh-s3-read-policy to include the ec2:DescribeFlowLogs permission, allowing Wazuh to query VPC Flow Log metadata while retaining its existing access to the centralized projectzero-prod-datalake-msegrt S3 security data lake.

I enabled VPC Flow Logs on projectzero-prod-vpc to capture both accepted and rejected network traffic. The flow log was configured to deliver telemetry to the vpc-flow/ prefix within the existing projectzero-prod-datalake-msegrt S3 security data lake.

I configured a dedicated S3 lifecycle rule for the vpc-flow/ prefix within projectzero-prod-datalake-msegrt to permanently remove noncurrent object versions after 14 days, helping control storage consumption within the lab environment.

I verified that VPC Flow Log telemetry was being delivered to the vpc-flow/ prefix within the projectzero-prod-datalake-msegrt security data lake, confirming that network flow logging was successfully writing data to the configured S3 destination.

I configured the Wazuh AWS S3 integration to retrieve VPC Flow Logs from the vpc-flow/ prefix using the previously configured AWS credentials. The integration polls the centralized S3 security data lake every 10 minutes for new VPC Flow Log telemetry.

After saving the configuration and restarting the Wazuh Manager, I verified that the AWS S3 module initialized the vpcflow integration and began retrieving telemetry from the configured S3 bucket.

I confirmed that VPC Flow Log events were successfully ingested into Wazuh and available for analysis. The resulting events provided visibility into accepted and rejected network flows across projectzero-prod-vpc.