Case study with F5 example

Configure Event-Driven Ansible rulebooks to automatically mitigate threats detected by monitoring tools like Elasticsearch or Kibana. Triggering F5 security solutions immediately stops potential attacks and helps ensure secure application delivery.

This agentless automation system uses existing transport mechanisms, such as APIs and webhooks, for easier interoperability. F5 content collections for Event-Driven Ansible are developed by F5 and certified by Red Hat to ensure reliable automation and support. Together, F5 and Red Hat help organizations to reduce risk, achieve a faster mean time to resolution, and ultimately free up limited resources to focus on high-value tasks.

Drive responses from logging events
Copy link

Ansible validated content provides pre-tested, trusted Roles and playbooks for secure, consistent infrastructure management. Use this content out-of-the-box to reduce the time needed for custom development, such as automating Event-Driven Ansible’s response to log events.

Use case: AWS CloudTrail
Copy link

Configure Event-Driven Ansible rulebooks to automatically monitor and secure your AWS CloudTrail logs. Triggering actions to re-enable encryption or restore deleted trails helps ensure your sensitive data remains protected and compliant.

AWS CloudTrail is a service that logs all the API calls made in your AWS account, including API calls made by other AWS services. By default, CloudTrail logs are stored in an S3 bucket in an unencrypted form. To verify that your CloudTrail logs are secure, enable encryption for CloudTrail logs using AWS KMS. Enable encryption for CloudTrail logs by creating a KMS key that is used to encrypt the S3 bucket where your CloudTrail logs are stored. Then configure CloudTrail to use this key to encrypt the logs.

With encryption enabled, all CloudTrail logs are automatically encrypted when they are written to the S3 bucket. The logs can only be decrypted using the KMS key that you specified. This establishes that your logs are secure and can only be accessed by authorized users and services.

Encrypting AWS CloudTrail logs is important for several reasons:

  • Protection of sensitive information: CloudTrail logs contain a wealth of information about the AWS account, including API calls, user identities, and resource information. Encrypting CloudTrail logs helps protect this sensitive information from unauthorized access or tampering.
  • Compliance requirements: Many compliance standards, such as HIPAA and PCI DSS, require log encryption to protect sensitive information. Encrypting CloudTrail logs enables compliance with these standards.
  • Prevent tampering: CloudTrail’s log encryption helps prevent logs from being tampered with. This helps maintain log integrity and an accurate record of all API calls made to your AWS account.
  • Secure data: CloudTrail log’s encryption provides an additional layer of security for data. In the event that your S3 bucket is compromised, the encrypted logs cannot be accessed without the encryption key.

The Event-Driven Ansible rulebook is comprised of the following components to assist in actions on the log files:

  • Sources: define which event source will be used
  • Rules: define which conditionals will be matched from the event source
  • Actions: trigger events when conditions are met

In the following example, the rulebook implements a ruleset with three rules as follows:

Rule #1: Enable trail encryption

This rule handles the case when trail encryption is disabled. It is triggered when an UpdateTrail operation is performed on the trail and the parameters contained in the UpdateTrail request match these conditions:

event.CloudTrailEvent.requestParameters.kmsKeyId=="" AND event.CloudTrailEvent.requestParameters.name==vars.cloudtrail_name.

The action that is taken to mitigate this drift will run the

'playbooks/eda/aws_restore_cloudtrail_encryption.yml playbook` This playbook runs the Ansible validated role cloud.aws_ops.enable_cloudtrail_encryption_with_kms that re-enables the trail’s encryption, restoring the system to its status quo.

Rule#2: Re-create the trail

This rule handles the case when the trail is deleted.

When the following conditions are met:

event.CloudTrailEvent.eventName=="DeleteTrail" AND event.CloudTrailEvent.requestParameters.name==vars.cloudtrail_name

The action is running the playbooks/eda/aws_restore_cloudtrail.yml playbook. This playbook runs the Ansible validated content cloud.aws_ops.awsconfig_multiregion_cloudtrail role first, which re-creates the trail and then the cloud.aws_ops.enable_cloudtrail_encryption_with_kms role, to enable the encryption on the newly created trail.

Rule#3: Cancels the deletion of the KMS key and re-enables it

This rule responds to the case of a KMS key being deleted or disabled. This results in the condition

event.CloudTrailEvent.eventName=="ScheduleKeyDeletion" OR event.CloudTrailEvent.eventName=="DisableKey"

When someone attempts to delete a KMS key intentionally or accidentally, a ScheduleKeyDeletion event is displayed in AWS CloudTrail. The KMS key is not deleted immediately, because deleting a KMS key is destructive and potentially dangerous. AWS KMS requires setting a 7–30 day waiting period. This situation is handled promptly by running playbooks/eda/aws_restore_kms_key.yml playbook, which cancels the deletion of the KMS key. Similarly, when the KMS key is disabled, the playbook reactivates it to restore the original state of the system. The playbook sets the KMS key ARN and uses it to determine whether to cancel the KMS key deletion, to re-enable the KMS key, or both.

Ansible validated content for cloud.aws_ops and Event-Driven Ansible create many opportunities for automated issue resolution and observation of cloud computing environments, helping you to easily automate, mitigate security issues, and maximize your mastery of cloud environments. For more information on using rulebooks, see Validated content for Event-Driven ansible for AWS.