Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 4. Event-Driven Ansible for reacting to security-related events

Ansible security automation enables the integration of multiple security technologies. This integration is technically complex and challenging, as it brings together different products, interfaces, and workflows and requires the alignment of different team processes within the security organization. Event-Driven Ansible resolves these challenges.

4.1. Use of Event-Driven Ansible for security
Copy link

Event-Driven Ansible is a powerful automation framework that enables organizations to respond to real-time events dynamically. It listens for triggers from various sources, evaluates conditions, and executes automated responses using Ansible Playbooks.

In the context of security operations, Event-Driven Ansible enables rapid incident response, threat mitigation, and system hardening by automating reactions to security-related events. Event-driven automation is the process of responding automatically to changing conditions in an IT environment, enabling faster issue resolution and reducing routine, repetitive tasks. Event-Driven Ansible connects sources of events with corresponding actions using rules. Its decision-making capabilities receive an “event” from a monitoring tool and trigger the required action. Ansible Rulebooks define the source of the event and, using “if-this-then-that” instructions, explains the action to take when the event is encountered. Ansible Rulebooks map event conditions to an action, like running a playbook or directly executing a module. Through Ansible, this event-driven automation process is applied to security-related events for event-driven security. An extensive set of monitoring tools is required to promptly identify and address any security risk. When these tools identify an issue or concern, an event-driven automation solution delivers log sources back to a Security Information and Event Management (SIEM) system for human intervention, triage, or resolution. Example automated event-driven threat responses include shutting ports, IPs, or devices. If your event source is watching network routers and discovers that a router is not responding, it recognizes this as an event. Event-Driven Ansible receives this event and matches the event to the condition defined by the rule in the Rulebook, which in this case would be “if an event indicating ‘no response’ is encountered, then reset the router”. Event-Driven Ansible triggers the instructions in the Rulebook and the router is reset, restoring it to normal function. This can happen at any time without human intervention.

Event-Driven Ansible can automate the following common security use cases:

  • Enterprise firewalls
  • Intrusion Detection and Prevention Systems (IDPS)
  • Security Information and Event Management (SIEM) systems
  • Privileged Access Management (PAM) tools
  • Endpoint Protection Platform (EPP)
  • Threat detection and response
  • Automated incident response
  • Zero Trust Network Access (ZTNA)
  • Compliance and hardening
  • Phishing mitigation

The following is an example workflow scenario using Event-Driven Ansible for detection of and response to unauthorized SSH access:

  1. Event Source: A security monitoring tool detects multiple failed SSH login attempts.
  2. Trigger: The event is sent to Event-Driven Ansible.
  3. Event-Driven Ansible rulebook evaluation: If the failed login count exceeds a threshold, execute an Ansible Playbook.
  4. Automated response actions:
  5. Block the source IP in the firewall.
  6. Send a notification to security teams.
  7. Collect logs for forensic analysis.

4.2. Case Study with F5
Copy link

Event-driven automation provides immediate response to suspicious activity. The versatility of Event-Driven Ansible is demonstrated by the F5 Application Delivery and Security Platform. When unusual or malicious activity is detected within the F5 Application Delivery and Security Platform through event monitoring tools such as Elasticsearch and Kibana, Event-Driven Ansible rulebooks respond immediately to stop a potential attack by using F5 solutions such as F5 Advanced WAF and BIG-IP Application Security Manager.

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.

4.2.1. Security operations use cases
Copy link

The following security operations use cases benefit from automation with F5 and Event-Driven Ansible:

4.2.2. Enriched security investigations
Copy link

Cyberattacks are perpetual threats to organizations, and security tools generate more alerts than understaffed security teams can investigate. Organizations can generate significant savings by enabling their security teams to identify and remediate issues more efficiently through automation. A common first step for security automation is to expedite the investigation phase of potential security incidents by following pre-defined investigation playbooks. When a new security event triggers an Ansible rulebook, automated workflows gather and correlate data from multiple F5 solutions to significantly decrease the amount of time that the security analyst must spend on the investigation, which results in a faster mean time to identify and contain an incident.

4.2.3. Improved threat hunting
Copy link

Enterprises manage a large number of endpoint devices. This attack surface exposes an organization to multiple threat vectors. Many security teams lack the resources to invest in proactive threat hunting, but by using automation to monitor and correlate threat data and produce actionable insights, security teams can prevent security issues more effectively and quickly detect threat exposure.

4.2.4. Faster response to security incidents
Copy link

In the context of automated cyberattacks, immediate threat response is vital. Security teams can use automation that executes pre-built, verified workflows for instant response to contain or prevent security incidents, which reduces attacker dwell time and damage. Rules determine which workflows to trigger based on specific events. When the event is detected, automation takes effect to remediate the issue, prevent attacker access, quarantine endpoints, or update security policies to prevent future occurrences. For example, if a malicious user is detected trying to access an application, event monitoring can trigger an Ansible Rulebook that instructs F5 Advanced WAF to block the malicious user while continuing to allow application access by legitimate users.

4.3. Example using F5 and Event-Driven Ansible
Copy link

Example code using F5 and Event-Driven Ansible is available on GitHub. This code notes each instance of the watcher finding a match in its filter and then copies the source IP from that code into a CSV list. The list is then sent as a variable within the webhook along with the message to execute the code.

This high level workflow is described in the following diagram and code workflow example:

+ F5 and Ansible workflow

The workflow steps are:

  1. The F5 BIG-IP pushes the monitoring logs to Elastic.
  2. Elastic takes that data and stores it while using a watcher with its filters and criteria.
  3. The Watcher detects an event that matches its criteria and sends the webhook with payload to Event-Driven Ansible.
  4. Event-Driven Ansible’s rulebook triggers from the event which triggers a job template within Ansible Automation Platform, that sends the payload provided by Elastic.
  5. Ansible Automation Platform’s template executes a playbook to secure the F5 BIG-IP using the payload provided by Event-Driven Ansible (originally provided by Elastic).

4.3.1. Driving responses from logging events
Copy link

Ansible validated content is a collection of pre-tested, validated, and trusted Ansible Roles and playbooks. This content is designed to make it easier to provide a secure, reliable, and consistent way to manage infrastructure across deployments. The validated content can be used out-of-the-box, reducing the time and effort required to create custom Ansible content. The following use case provides an example for Event-Driven Ansible’s response to log events.

4.3.2. Use case: AWS CloudTrail
Copy link

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.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat