Getting started with Ansible security automation: Incident Response

Technological advancements are intended to bring more control, agility and velocity to organizations. However, adopting these new technologies and techniques, such as cloud computing and microservices, increases an organization’s security footprint, bringing greater risk of security breaches. 

Cyberattacks potentially expose organizations to financial loss, reputational damage, legal liability, and business continuity risk. As a result, security teams are under increased pressure to help proactively protect organizations against cyberattacks and maintain a more consistent, rapid incident response framework to respond to security breaches. 

In our previous blogs in this series, we explored how Ansible security automation enables security teams to automate and simplify investigation enrichment and threat hunting practices. We also discussed and provided our answer to the lack of integration across the IT security industry.

In this blog post, we’ll have a closer look at incident response and how Ansible security automation empowers security teams to respond effectively to security breaches.

What is an incident response, and why is it so difficult?

Incident response is the approach and techniques that security departments implement to neutralize and mitigate cyberattacks, and is a core responsibility of the security team. Recent news headlines are rife with high-profile security breaches and the immense monetary and reputational damage due to ineffective security breach responses.

Security departments need to respond to a cyberattack rapidly and conclusively, but are hindered in providing a coordinated response due to the lack of integration and orchestration between varying security products and tools. This lack of integration leads to incident responses being prone to human error, inconsistencies and delayed or unsuccessful remediations for the security threat.

Ansible security automation enables security departments to provide a more consistent, integrated and rapid response to security incidents. It empowers security practitioners and teams to automate and integrate their complex requirements and capabilities in a self-service manner across the IT organization, providing a holistic and coordinated incident response.

Our Simple Lab Environment

We’ll use the same demo environment used in the previous blogs to walk through a typical incident response scenario:

• Snort - Intrusion Detection System (IDS).
• Checkpoint  Next Generation Firewall (NGFW).
• IBM QRadar - Security Information and Event Management (SIEM).
• ‘Attacker’ machine to simulate the cyberattack.

The demo environment is a simplified example of a real-world enterprise security architecture, which can be more complex and include additional vendor-specific tools.

The Incident

Let’s imagine that we’re part of the IDPS team. As part of this team, our responsibilities include monitoring, configuring and managing the IDPS devices within our organization. We’re also accountable for updating our devices and tools with the latest rules to prohibit possible cyber attacks and act on security alerts if they occur.

While scanning our Snort logs, we identify alerts with the Attempted Administrator Privilege Gain message, as in the example below. 

[ec2-user@ip-172-16-11-22 ~]$ journalctl -u snort -f
-- Logs begin at Sun 2019-09-22 14:24:07 UTC. --
Sep 22 21:03:03 ip-172-16-115-120.ec2.internal snort[22192]: [1:99000030:1] Attempted SQL Injection [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 172.17.78.163:53376 -> 172.17.23.180:80

The alert we discovered needs immediate investigation by a security analyst, and we promptly notify them to investigate further.

The Investigation

Now, let’s put our security analyst hats on. As an analyst, we‘re responsible for identifying, classifying and responding to security anomalies in our organization. Analysts often use a SIEM for a consolidated view of logs and events to help identify potential security threats.

Collating information from multiple sources and gathering inputs from various teams or individuals is easier said than done! The analyst may need to make phone calls, arrange meetings and complete arduous manual processes before obtaining the insight required to address a security anomaly effectively. 

In our example, the analyst would need to reach out to several security teams and ask them to forward logs to IBM QRadar for further investigation. Unfortunately, this step requires manual configuration changes on devices, further delaying our response to a potentially serious security threat.

Using Ansible security automation, however, we can automate the changes, driving more consistent device configurations and accelerating our response to the security threat.

To illustrate this, we’ll initially create a playbook using the ansible_security.ids_config role and the ibm.qradar Collection to automate forwarding our Snort logs to IBM QRadar.

---
- name: Configure snort for external logging
  hosts: snort
  become: true
  vars:
    ids_provider: "snort"
    ids_config_provider: "snort"
    ids_config_remote_log: true
    ids_config_remote_log_destination: "{{ hostvars['qradar']['private_ip'] }}"
    ids_config_remote_log_procotol: udp
    ids_install_normalize_logs: false

  tasks:
    - name: import ids_config role
      include_role:
        name: "ansible_security.ids_config"

- name: Add Snort log source to QRadar
  hosts: qradar
  collections:
    - ibm.qradar

  tasks:
    - name: Add snort remote logging to QRadar
      qradar_log_source_management:
        name: "Snort rsyslog source - {{ hostvars['snort']['private_ip'] }}"
        type_name: "Snort Open Source IDS"
        state: present
        description: "Snort rsyslog source"
… Output Omitted...

We’re also receiving alerts of suspicious activity from our endpoint protection solution, Trend Micro Deep Security. As a result, we’ll need to incorporate and analyze these logs in IBM QRadar too.

Red Hat Ansible Automation Platform provides a certified Ansible Content Collection for Trend Micro Deep Security that we can implement to automate forwarding our Trend Micro Deep Security logs for further analysis.

Ansible Content Collections are the preferred framework for packaging, distributing and consuming Ansible content. Please have a look at our Ansible Content Collections blog for more information.

We’ll create a playbook to automate forwarding Trend Micro Deep Security logs to IBM QRadar.

- name: Forward Trend Micro Deep Security logs to IBM QRadar
  hosts: trendmicro

  collections:
	- trendmicro.deepsec

  tasks:
  - name: Create new Trend Micro Syslog Config for QRadar
	trendmicro.deepsec.deepsec_syslog:
  	state: present
  	name: QRADAR_SYSLOG
  	facility: syslog
  	event_format: leef
  	direct: false
  	server: "{{ hostvars['qradar']['private_ip'] }}"
  	port: 514
  	transport: udp
  	description: Syslog Api request from Ansible

- name: Add Trend Micro log source to QRadar
  hosts: qradar

  collections:
	- ibm.qradar

  tasks:
	- name: Add Trend Micro remote logging to QRadar
  	qradar_log_source_management:
    	name: "Trend Micro Deep Security Ansible"
    	type_name: "Trend Micro Deep Security"
    	state: present
    	description: "Trend Micro Deep Security log source"
      identifier:"{{ hostvars['trendmicro']['private_ip']|regex_replace('\\.','-')|regex_replace('^(.*)$', 'ip-\\1') }}"

… Output Omitted...

Ansible security automation enabled the security teams to simplify the configuration changes necessary to forward events and logs from multiple sources to the SIEM, accelerating, identifying and analyzing the potential cyberattacks attack. As a result, we now have all the information necessary to evaluate and classify the security threat. 

IBM QRadar creates offenses based on preconfigured rules that analyze logs and events. In our example, the forwarded Snort and Trend Micro logs are indeed generating offenses, as illustrated below.

After further investigation of the offenses, we’ve verified that this is undoubtedly a SQL injection cyberattack. It’s now our responsibility to minimize the impact and neutralize the security breach as soon as possible.

Neutralizing the Attack

Our analysis in IBM QRadar indicates that the SQL injection attack is originating from a single IP address. This insight is vital! We can neutralize the cyberattack by blocking the attacker’s IP address.

The firewall team is responsible for making the necessary configuration changes to implement our planned countermeasures. 

Involving the firewall team usually requires an additional manual step that decelerates our remediation response time. In addition, critical information, such as the attacker’s IP address, is shared statically between security teams and is prone to human error. These inconsistencies can completely invalidate our response to the SQL injection attack.

However, with Ansible Automation Platform, we can make all the necessary contextual information dynamically available for reuse in multi-step automation scenarios. Ansible Automation Platform gathers data, known as Ansible facts, that provides information such as IP addresses and system configurations from remote systems that security teams can securely reuse in additional automation steps.

We’ll create a playbook that will block the attacker’s source IP address on our checkpoint firewall and use Ansible facts to dynamically input the IP address details instead of a static, manual handover to the firewall team.

We’re using a simplified approach in our demonstration by utilizing the hostvars['attacker']['private_ip2']  Ansible fact, which in our lab translates to 172.17.199.94,  gathered from our attacker lab machine.  However, Ansible Automation Platform offers extensive features and capabilities to accomplish this in large-scale production scenarios.

---
- name: Block attacker
  hosts: checkpoint

  vars:
    source_ip: "{{ hostvars['attacker']['private_ip2'] }}"
    destination_ip: "{{ hostvars['snort']['private_ip2'] }}"

  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 deny 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: drop

… Output Omitted...

We can also verify that the playbook successfully created the new firewall access rule via the Check Point firewall interface.

Executing the playbook blocked the attacker’s source IP address and successfully neutralized the cyberattack!

Key Takeaways

Let’s take a step back and imagine the monumental effort that the security practitioners and teams would require to mitigate the security breach without automation. 

Manual handovers, inaccurate data and attempting to orchestrate multiple security products would significantly reduce the security department’s ability to effectively and rapidly respond to the SQL injection attack.

Security departments must react effectively and concisely to security breaches. A successful response requires a multi-faceted approach involving multiple teams with varying skill sets and numerous security products that usually lack integration. 

Ansible security automation equips security teams to provide an incident response to cyberattacks holistically, accurately and rapidly by collating multiple security products and disciplines within the enterprise through curated and certified Collections, roles and modules.

Where To Go Next

There are plenty of resources to explore further how Ansible Automation Platform helps security teams:

• Simplify your Security Operations Center ebook.
• Automating Endpoint Protection with Ansible blog written by Roland Wolters on how Ansible security automation can help security teams automate endpoint protection.
• More information is available on the Ansible security automation landing page.