Security Automation with Red Hat Ansible Automation Platform

Updated -

Red Hat Ansible security automation is as a set of Ansible collections of roles and modules dedicated to security teams. It provide a faster, more efficient and streamlined way to automate the processes for the identification, triage, and response to security events. This effort targets integrations for automating and orchestrating enterprise security solutions not specifically designed to talk to each other and is more complex and higher-value than the application of a security baseline (PCI, STIG, CIS) to a server.

Platform Compatibility Matrix

Certified Ansible security content can be found via your access to the Automation Hub at as follows:

Type Platform Vendor Product Version Ansible Version Collections in Hub/docs
SIEM Splunk Enterprise Security 7.2.6+ 2.9 splunk/enterprise_security
SIEM IBM QRadar QRadar SIEM 7.3.1+ 2.9 ibm/qradar
Enterprise Firewalls Check Point Next Generation Firewall R80+ 2.9 check_point/mgmt
Enterprise Firewalls Fortinet Fortigate: NGFW FortiOS 6.0 2.3 minimum, 2.9 recomended fortinet/fortios
Enterprise Firewalls Cisco Firepower Threat Defense 6.4 2.7 minimum, 2.9 recommended FTD modules docs
Enterprise Firewalls Cisco ASA 9.12.3 2.9.10 cisco/asa
Enterprise Firewalls F5 Advanced Firewall Manager BIG-IP 12.1+ 2.7 minimum, 2.9 recommended F5 modules docs
IDPS Check Point IPS Blade R80+ 2.9 check_point/mgmt
IDPS Fortinet Fortigate: IPS IPS Engine 4.0, AVS engine 6.0 2.8 minimum, 2.9 recomended fortinet/fortios
PAM CyberArk Identity Management CyberArk PAS 10.0+ 2.9 cyberark/pas
PAM Syncope Identity Management Apache Syncope 2.1.X 2.8.5 minimum, 2.9 recomended tirasa/syncope
Endpoint Protection Trend Micro Deep Security 12.5.855+ 2.9.10 trendmicro/deepsec

Those collections can be consumed via ansible-galaxy - see Using collections
for a more in-depth documentation.

Getting Started - where to get it!

Additional content is provided as an exemplary guidance to use Ansible security automation via Ansible Galaxy at Currently the following roles are available:

Role Name Description
acl_manager Ansible role to manage access control lists for many firewall devices
ids_config Intrusion Detection System Configuration Role
ids_install A role to install many different Intrusion Detection Systems, these are defined as "providers" to the Role.
ids_rule Ansible role to manage rules and signatures for Intrusion Detection Systems
ids_rule_facts Intrusion Detection System Rule maintenance
log_manager Role to manage logs in multiple firewall devices

They can be installed with the ansible-galaxy tool.

Use case examples

Automating firewall rules

Given a Check Point NGFW, a typical use case is to add a whiltelist entry in the firewall configuration to allow traffic from a certain machine to another.

- name: Whitelist attacker
  hosts: checkpoint

    source_ip: "{{ hostvars['serverA']['private_ip'] }}"
    destination_ip: "{{ hostvars['serverB']['private_ip'] }}"

    - name: Create source IP host object
        name: "asa-{{ source_ip }}"
        ip_address: "{{ source_ip }}"

    - name: Create destination IP host object
        name: "asa-{{ destination_ip }}"
        ip_address: "{{ destination_ip }}"

    - name: Create access rule to allow access from source to destination
        auto_install_policy: yes
        auto_publish_session: yes
        layer: Network
        position: top
        name: "asa-accept-{{ source_ip }}-to-{{ destination_ip }}"
        source: "asa-{{ source_ip }}"
        destination: "asa-{{ destination_ip }}"
        action: accept

    - name: Install policy
        policy_package: standard
        install_on_all_cluster_members_or_fail: yes
      failed_when: false

This playbook first add the source and destination IPs are added as variables to the playbook. Then the actual tasks follow, where a source and destination object are defined, and afterwards the actual access rule between those is defined. Last we make sure the policy is actually deployed.

Add IDPS rule

Given a Snort IDPS environment, a typical use case is to manage rules. To ease rule management, as part of the Ansible security automation offering IDPS roles are offered. In a first step those need to be installed:

[student@ansible ~]$ ansible-galaxy install ansible_security.ids_rule
- downloading role 'ids_rule', owned by ansible_security
- downloading role from
- extracting ansible_security.ids_rule to /home/student/.ansible/roles/ansible_security.ids_rule
- ansible_security.ids_rule (master) was installed successfully

These roles can work with multiple IDPS providers, so the corresponding playbook needs to have a variable stating the actual IDPS provider. Afterwards, the role is imported and the new IDPS rule is handed over via defined variables:

- name: Add Snort rule
  hosts: snort
  become: yes

    ids_provider: snort

    - name: Add snort password attack rule
        name: "ansible_security.ids_rule"
        ids_rule: 'alert tcp any any -> any any (msg:"Attempted /etc/passwd Attack"; uricontent:"/etc/passwd"; classtype:attempted-user; sid:99000004; priority:1; rev:1;)'
        ids_rules_file: '/etc/snort/rules/local.rules'
        ids_rule_state: present

Change a SIEM rule

Using SIEMs, the rules to correlate and trigger on events are sometimes activated or disabled. Automating QRadar with Ansible requires the appropriate modules and connection plugins which are provided in a collection that needs to be installed first:

[student@ansible ~]$ ansible-galaxy collection install ibm.qradar
Process install dependency map
Starting collection install process
Installing 'ibm.qradar:0.0.1' to '/home/student/.ansible/collections/ansible_collections/ibm/qradar'

In the actual playbook, the first task identifies the rule, and the second task acts on the findings of the first task, in this case deactivating the rule.

- name: Change QRadar rule state
  hosts: qradar
    - ibm.qradar

    - name: get info about qradar rule
        name: "Potential DDoS Against Single Host (TCP)"
      register: rule_info

    - name: disable rule by id
        state: disabled
        id: "{{ rule_info.rules[0]['id'] }}"