Design the test cases for the AWS integration tests

[CarlosRS9]

Taking into account the different Tiers defined in https://github.com/wazuh/wazuh-qa/issues/3332 we should list and design the different test cases we want to add for the tiers agreed to implement.

Check the following issues to get an idea of the manual tests we want to automate:

• https://github.com/wazuh/wazuh/issues/12529
• https://github.com/wazuh/wazuh/issues/13325
• https://github.com/wazuh/wazuh/issues/14376

Tasks

• [x] Create CloudTrail integration test cases
• [x] Create VPC integration test cases
• [x] Create Config integration test cases
• [x] Create ALB, CLB and NLB integration test cases
• [x] Create KMS integration test cases
• [x] Create Macie integration test cases
• [x] Create TrustedAdvisor integration test cases
• [x] Create GuardDuty integration test cases
• [x] Create WAF integration test cases
• [x] Create Server Access integration test cases
• [x] Create Inspector integration test cases
• [x] Create CloudWatch Logs integration test cases
• [x] Create Umbrella integration test cases
• [x] Create Parser integration test cases

[nico-stefani]

CloudTrail Test Cases

Tier 0

• CloudTrail integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa cloudtrail-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• CloudTrail integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa cloudtrail-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• CloudTrail integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa cloudtrail-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa cloudtrail-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• CloudTrail integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa cloudtrail-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa cloudtrail-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa cloudtrail-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• CloudTrail integration works properly with path_suffix option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *AWSLogs/test_suffix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path_suffix with data	Only the contents of *test_suffix* are processed and sent to analysisd	ossec.conf ```XML no qa cloudtrail-tests date-to-test test_suffix ```
  Use an existing path_suffix without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa cloudtrail-tests date-to-test empty_suffix ```
  Use an inexisting path_suffix	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa cloudtrail-tests date-to-test inexistent_suffix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs in the bucket for the *test_suffix* 1. Check the database was created and updated accordingly

• CloudTrail integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa cloudtrail-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa cloudtrail-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa cloudtrail-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• CloudTrail integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa cloudtrail-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• CloudTrail integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket cloudtrail-tests \ --type cloudtrail \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket cloudtrail-tests \ --type cloudtrail \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket cloudtrail-tests \ --type cloudtrail \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket cloudtrail-tests \ --type cloudtrail \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

VPC Flow Test Cases

Tier 0

• VPC Flow integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa vpcflow-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• VPC Flow integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa vpcflow-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• VPC Flow integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa vpcflow-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa vpcflow-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• VPC Flow integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa vpcflow-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa vpcflow-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa vpcflow-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• VPC Flow integration works properly with path_suffix option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *AWSLogs/test_suffix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path_suffix with data	Only the contents of *test_suffix* are processed and sent to analysisd	ossec.conf ```XML no qa vpcflow-tests date-to-test test_suffix ```
  Use an existing path_suffix without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa vpcflow-tests date-to-test empty_suffix ```
  Use an inexisting path_suffix	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa vpcflow-tests date-to-test inexistent_suffix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs in the bucket for the *test_suffix* 1. Check the database was created and updated accordingly

• VPC Flow integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa vpcflow-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa vpcflow-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa vpcflow-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• VPC Flow integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa vpcflow-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• VPC Flow integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket vpcflow-tests \ --type vpcflow \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket vpcflow-tests \ --type vpcflow \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket vpcflow-tests \ --type vpcflow \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket vpcflow-tests \ --type vpcflow \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

ALB Test Cases

Tier 0

• ALB integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa alb-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• ALB integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa alb-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• ALB integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa alb-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa alb-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• ALB integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa alb-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa alb-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa alb-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• ALB integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa alb-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa alb-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa alb-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• ALB integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa alb-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• ALB integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket alb-tests \ --type alb \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket alb-tests \ --type alb \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket alb-tests \ --type alb \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket alb-tests \ --type alb \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

CLB Test Cases

Tier 0

• CLB integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa clb-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• CLB integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa clb-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• CLB integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa clb-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa clb-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• CLB integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa clb-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa clb-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa clb-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• CLB integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa clb-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa clb-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa clb-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• CLB integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa clb-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• CLB integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket clb-tests \ --type clb \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket clb-tests \ --type clb \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket clb-tests \ --type clb \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket clb-tests \ --type clb \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

NLB Test Cases

Tier 0

• NLB integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa nlb-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• NLB integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa nlb-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• NLB integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa nlb-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa nlb-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• NLB integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa nlb-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa nlb-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa nlb-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• NLB integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa nlb-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa nlb-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa nlb-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• NLB integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa nlb-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• NLB integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket nlb-tests \ --type nlb \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket nlb-tests \ --type nlb \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket nlb-tests \ --type nlb \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket nlb-tests \ --type nlb \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

Macie Test Cases

Tier 0

• Macie integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa macie-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Macie integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa macie-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• Macie integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa macie-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa macie-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Macie integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa macie-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa macie-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa macie-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• Macie integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa macie-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa macie-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa macie-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• Macie integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa macie-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• Macie integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket macie-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket macie-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket macie-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket macie-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

Trusted Advisor Test Cases

Tier 0

• Trusted Advisor integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa trusted-advisor-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Trusted Advisor integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa trusted-advisor-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• Trusted Advisor integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa trusted-advisor-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa trusted-advisor-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Trusted Advisor integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa trusted-advisor-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa trusted-advisor-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa trusted-advisor-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• Trusted Advisor integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa trusted-advisor-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa trusted-advisor-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa trusted-advisor-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• Trusted Advisor integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa trusted-advisor-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• Trusted Advisor integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket trusted-advisor-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket trusted-advisor-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket trusted-advisor-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket trusted-advisor-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

Guard Duty Test Cases

Tier 0

• Guard Duty integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa guard-duty-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Guard Duty integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa guard-duty-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• Guard Duty integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa guard-duty-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa guard-duty-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Guard Duty integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa guard-duty-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa guard-duty-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa guard-duty-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• Guard Duty integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa guard-duty-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa guard-duty-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa guard-duty-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• Guard Duty integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa guard-duty-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• Guard Duty integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket guard-duty-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket guard-duty-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket guard-duty-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket guard-duty-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

WAF Test Cases

Tier 0

• WAF integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa waf-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• WAF integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa waf-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• WAF integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa waf-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa waf-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• WAF integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa waf-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa waf-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa waf-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• WAF integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa waf-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa waf-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa waf-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• WAF integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa waf-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• WAF integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket waf-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket waf-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket waf-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket waf-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

Server Access Test Cases

Tier 0

• Server Access integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa server-access-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Server Access integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa server-access-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• Server Access integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa server-access-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa server-access-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Server Access integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa server-access-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa server-access-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa server-access-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• Server Access integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa server-access-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa server-access-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa server-access-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• Server Access integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa server-access-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• Server Access integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket server-access-tests \ --type server_access \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket server-access-tests \ --type server_access \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket server-access-tests \ --type server_access \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket server-access-tests \ --type server_access \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

Config Test Cases

Tier 0

• Config integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa config-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Config integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa config-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• Config integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa config-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa config-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Config integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa config-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa config-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa config-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• Config integration works properly with path_suffix option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *AWSLogs/test_suffix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path_suffix with data	Only the contents of *test_suffix* are processed and sent to analysisd	ossec.conf ```XML no qa config-tests date-to-test test_suffix ```
  Use an existing path_suffix without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa config-tests date-to-test empty_suffix ```
  Use an inexisting path_suffix	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa config-tests date-to-test inexistent_suffix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs in the bucket for the *test_suffix* 1. Check the database was created and updated accordingly

• Config integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa config-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa config-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa config-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• Config integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa config-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• Config integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket config-tests \ --type config \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket config-tests \ --type config \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket config-tests \ --type config \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket config-tests \ --type config \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

KMS Test Cases

Tier 0

• KMS integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa kms-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• KMS integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa kms-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• KMS integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa kms-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa kms-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• KMS integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa kms-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa kms-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa kms-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• KMS integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa kms-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa kms-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa kms-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• KMS integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa kms-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• KMS integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket kms-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket kms-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket kms-tests \ --type custom \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket kms-tests \ --type custom \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

Umbrella Test Cases

Tier 0

• Umbrella integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa umbrella-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Umbrella integration works properly with remove_from_bucket

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Cases	Expected Result	Configuration
  Use an existing bucket, upload a file and consume it	The uploaded file was removed after the execution	ossec.conf ```XML no yes qa umbrella-tests ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the uploaded log was removed by the module after the execution

• Umbrella integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs with timestamps older than the date specified in the configuration. * There are already logs with timestamps more recent timestamp than the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Don't set a date in the configuration	Only the log uploaded during execution is processed	ossec.conf ```XML no qa umbrella-tests ```
  Set a date for which there are logs available in the bucket	All logs with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa umbrella-tests date-to-test ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Upload a log file to the test bucket for the day of the test execution 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the logs whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Umbrella integration works properly with path option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration inside of *test_prefix*. ### Cases

  Cases	Expected Result	Configuration
  Use an existing path with data	Only the contents of *test_prefix* are processed and sent to analysisd	ossec.conf ```XML no qa umbrella-tests date-to-test test_prefix ```
  Use an existing path without data	No logs were processed. No logs were sent analysisd	ossec.conf ```XML no qa umbrella-tests date-to-test empty_prefix ```
  Use an inexisting path	No logs were processed. No logs were sent analysisd. A message warning that the path does not exist should be displayed	ossec.conf ```XML no qa umbrella-tests date-to-test inexistent_prefix ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a path that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd 1. Check the database was created and updated accordingly, using the correct path for each entry

• Umbrella integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration for different regions. ### Cases

  Cases	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa umbrella-tests date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa umbrella-tests date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa umbrella-tests date-to-test fake-region-1 ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket for the specified region 1. Check the database was created and updated accordingly

• Umbrella integration works properly with discard_regex option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already logs generated after the date specified in the configuration. ### Cases

  Cases	Expected Result	Configuration
  Set a regex to one field	Fetch logs excluding the ones that match with the regex	ossec.conf ```XML no qa umbrella-tests date-to-test REGEX_TO_APPLY ```

  ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the `ossec.log` waiting until the wazuh service is restarted or there is a timeout 1. Monitor the `ossec.log` waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were forwarded to analysisd, only logs stored in the bucket and skips the ones that match with regex 1. Check the database was created and updated accordingly

Tier 1

• Umbrella integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already logs generated after the date specified in the configurations. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `s3_cloudtrail.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket umbrella-tests \ --type cisco_umbrella \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --bucket umbrella-tests \ --type cisco_umbrella \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `3` and check there were no duplicates 1. Call the module with `only_logs_after` set with an early date than setted in `3` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --bucket umbrella-tests \ --type cisco_umbrella \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Upload a log file to the test bucket for the day of the test execution 1. Call the module without `only_logs_after` and check that only the uploaded logs were processed and the last marker is specified in the DB. ```bash /var/ossec/wodles/aws/aws-s3 --bucket umbrella-tests \ --type cisco_umbrella \ --aws_profile qa \ --debug 2 ``` 1. Delete the uploaded log file. This must be done even if the test fails

[nico-stefani]

CloudWatch Logs Test Cases

Tier 0

• CloudWatch integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  Use an existent log stream	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa cloudwatch_qa ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• CloudWatch integration works properly with remove_log_stream

  ### Pre-conditions * There are already configured credentials for the `qa` profile * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  Create a log group, generate events and consume it	The created log group was removed after the execution	ossec.conf ```XML no qa cloudwatch_qa yes ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Make sure that the created log group was removed by the module after the execution

• CloudWatch integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already generated tests events, for a period of 14 days, in the log group `cloudwatch_qa` and log stream `test_stream` ### Cases

  Case	Expected Result	Configuration
  Don't set a date in the configuration	Only the events generated during execution is processed	ossec.conf ```XML no qa cloudwatch_qa ```
  Set a date for which there are logs available in the bucket	All events with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa cloudwatch_qa date-to-test ```

  ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the events whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• CloudWatch integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already generated tests events, for a period of 14 days, in the log group `cloudwatch_qa` and log stream `test_stream` for different regions ### Cases

  Case	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa cloudwatch_qa date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa cloudwatch_qa date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa cloudwatch_qa date-to-test fake-region-1 ```

  ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only events stored in the log group for the specified region 1. Check the database was created and updated accordingly
• CloudWatch integration works properly with aws_log_groups option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already generated tests events, for a period of 14 days, in the log groups `cloudwatch_qa` and `cloudwatch_qa_1` ### Cases

  Case	Expected Result	Configuration
  Use multiple aws_log_groups with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa cloudwatch_qa,cloudwatch_qa_1 date-to-test us-east-1 ```
  Use an non-existant aws_log_groups	No logs should be processed. A message warning that the log group does not exist should be displayed	ossec.conf ```XML no qa inexistent_log_group date-to-test us-east-1 ```

  ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only events stored in the log group for the specified region 1. Check the database was created and updated accordingly

Tier 1

• CloudWatch integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already generated tests events, for a period of 14 days, in the log group `cloudwatch_qa` and log stream `test_stream` for different regions ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --service cloudwatchlogs \ --aws_log_groups cloudwatch_qa \ --aws_profile qa \ --debug 2 ``` 1. Generate logs to the log group for the day of the test execution 1. Call the module with the same parameters in `2` and check that the generated logs were processed 1. Call the module with the same parameters in `2` and check that no logs were processed, there were no duplicates 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --service cloudwatchlogs \ --aws_log_groups cloudwatch_qa \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `6` and check there were no duplicates 1. Call the module with `only_logs_after` set with an older date than setted in `6` and check that old logs were processed without duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --service cloudwatchlogs \ --aws_log_groups cloudwatch_qa \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set with an early date than setted in `6` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --service cloudwatchlogs \ --aws_log_groups cloudwatch_qa \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Delete the generated logs. This must be done even if the test fails

[nico-stefani]

Inspector Logs Test Cases

Tier 0

• Inspector integration works properly using the default configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  Use a configured inspector service	The module is invoked with the expected parameters and no error occurs	ossec.conf ```XML no qa ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check no error messages are present in the `ossec.log`

• Inspector integration works properly with only_logs_after option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already generated tests events for a period of 14 days ### Cases

  Case	Expected Result	Configuration
  Don't set a date in the configuration	Only the events generated during execution is processed	ossec.conf ```XML no qa ```
  Set a date for which there are logs available in the bucket	All events with a timestamp greater than the only_logs_after value are processed	ossec.conf ```XML no qa date-to-test ```

  ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. Check the expected number of events were sent to analysisd. Only the events whose timestamp is greater than the date specified in the configuration should be processed 1. Check the database was created and updated accordingly

• Inspector integration works properly with regions option

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. * There are already generated tests events for a period of 14 days ### Cases

  Case	Expected Result	Configuration
  Use a region with data	Only the logs for the specified region are processed	ossec.conf ```XML no qa date-to-test region-1 ```
  Use multiple regions with data	Only the logs for the specified regions are processed	ossec.conf ```XML no qa date-to-test region-1,region-2 ```
  Use an non-existant region	No logs should be processed. A message warning that the region does not exist should be displayed	ossec.conf ```XML no qa date-to-test fake-region-1 ```

  ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called with the correct parameters 1. If a region that does not exist was specified, make sure that a message is displayed in the `ossec.log` warning the user 1. Check the expected number of events were forwarded to analysisd, only events stored in the log group for the specified region 1. Check the database was created and updated accordingly

Tier 1

• Inspector integration don't fetch logs that already were processed

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * There are already generated tests events, for a period of 14 days. ### Cases |Case|Expected Result| |----|-----------| |Call the AWS module multiple times with different `only_logs_after` values|No duplicates were processed| ### Steps 1. Delete the `aws_services.db` file using a fixture 1. Call the module without `only_logs_after` and check that no logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --service inspector \ --aws_profile qa \ --debug 2 ``` 1. Generate logs for the day of the test execution 1. Call the module with the same parameters in `2` and check that the generated logs were processed 1. Call the module with the same parameters in `2` and check that no logs were processed, there were no duplicates 1. Call the module with `only_logs_after` set in the past and check that the expected number of logs were processed: ```bash /var/ossec/wodles/aws/aws-s3 --service inspector \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with the same parameters in `6` and check there were no duplicates 1. Call the module with `only_logs_after` set with an older date than setted in `6` and check that old logs were processed without duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --service inspector \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Call the module with `only_logs_after` set with an early date than setted in `6` and check that no logs were processed, there were no duplicates: ```bash /var/ossec/wodles/aws/aws-s3 --service inspector \ --only_logs_after \ --aws_profile qa \ --debug 2 ``` 1. Delete the generated logs. This must be done even if the test fails

[nico-stefani]

Parser Test Cases

Tier 0

• The ossec.conf parser detects when a mandatory parameter is not present

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  bucket and service tags are missing	Command for bucket and service weren't invoked	ossec.conf ```XML no ```
  type parameter inside bucket tag is missing	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no qa cloudtrail-tests ```
  type parameter inside service tag is missing	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa cloudwatch-qa ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command wasn't called and error message was displayed in `ossec.log`
• The ossec.conf parser handles correctly when parameters has no values

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  Set an empty value for type in tag bucket	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no ```
  Set an empty value for type in tag service	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no ```
  Set an empty value for name in tag bucket	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no qa ```
  Set an empty value for only_logs_after in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa ```
  Set an empty value for only_logs_after in tag service	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa ```
  Set an empty value for regions in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa ```
  Set an empty value for regions in tag service	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa ```
  Set an empty value for path in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa ```
  Set an empty value for path_suffix in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command wasn't called and error message was displayed in `ossec.log`
• The ossec.conf parser handles correctly when invalid values are used

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  Set an invalid value for remove_from_bucket	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no nein ```
  Set an invalid value for type in tag bucket	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no ```
  Set an invalid value for type in tag service	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no ```
  Set an invalid value for name in tag bucket	An error occurs and was displayed in `ossec.log`	ossec.conf ```XML no qa invalid_bucket_name ```
  Set an invalid value for only_logs_after in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa JUL-10 ```
  Set an invalid value for only_logs_after in tag service	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa JUL-10 ```
  Set an invalid value for regions in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa invalid_value ```
  Set an invalid value for regions in tag service	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa invalid_value ```
  Set an invalid value for path in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa invalid_value ```
  Set an invalid value for path_suffix in tag bucket	An error occurs and was displayed in `ossec.log	ossec.conf ```XML no qa invalid_value ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command wasn't called and error message was displayed in `ossec.log`
• The ossec.conf parser handles correctly when several bucket and service tags are used in the same configuration

  ### Pre-conditions * There are already configured credentials for the `qa` profile. * Debug mode is enabled in the internal_configuration file. ### Cases

  Case	Expected Result	Configuration
  Have two valid buckets and two valid services configured	The command is invoked two times for buckets and two times for services	ossec.conf ```XML no qa cloudtrail-tests qa vpcflow-tests qa cloudwatch-qa qa ```

  ### Steps 1. Apply the test case configuration to the `ossec.conf` 1. Restart wazuh-manager service 1. Monitor the ossec.log waiting until the wazuh service is restarted or there is a timeout 1. Monitor the ossec.log waiting until the module is triggered or there is a timeout 1. Check the command was called the expected number of times