Security Automation with Red Hat Ansible Automation Platform

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 cloud.redhat.com as follows:

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 galaxy.ansible.com/ansible_security. Currently the following roles are available:

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

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

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

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

    - name: Create access rule to allow access from source to destination
      checkpoint_access_rule:
        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
      cp_mgmt_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 https://github.com/ansible-security/ids_rule/archive/master.tar.gz
- 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

  vars:
    ids_provider: snort

  tasks:
    - name: Add snort password attack rule
      include_role:
        name: "ansible_security.ids_rule"
      vars:
        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
  collections:
    - ibm.qradar

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

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