Ansible security automation resource modules

Security professionals are increasingly adopting automation as a way to help unify security operations into structured workflows that can reduce operational complexity, human error, time to respond and can be integrated into existing SIEM (Security Information and Event Management) or SOAR (Security Orchestration Automation and Response) platforms.

In October of 2019 the Ansible network automation team introduced the concept of resource modules.

So what exactly is a "resource module?" Sections of a device's configuration can be thought of as a resource provided by that device. Network resource modules are intentionally scoped to configure a single resource and can be combined as building blocks to configure complex network services.

Keep in mind that the first network automation modules could either execute arbitrary commands on target devices, or read in the device configuration from a file and deploy it. These modules were quite generic and provided no fine-tuning of certain services or resources.

In contrast, resource modules can make network automation easier and more consistent for those automating multiple platforms in production by avoiding large configuration file templates covering all kinds of configuration. Instead they focus on the task at hand, providing separate building blocks which can be used to describe complex configurations.

The same principle can be applied in the security space, and we started exploring the possibility with Ansible security automation.

Resource modules in security automation

In security automation, many Collections already have more refined modules targeting use cases or workflows of the corresponding target environment. Therefore, there is little standardization or generic abstraction in terms of product agnostic resources.

For example, if you have a closer look at our investigation enrichment blog post, you will see that while we used a certain amount of modules, those were usually very product specific and didn't offer much in terms of generic resources.

At the same time, security automation does cover many tasks where resource modules can add a lot of value. Whether it is granting and denying access to networks via Access Control Lists (ACLs) or policies, the management of rules in IDPS systems or the log forwarding of nodes to a central SIEM: all those tasks are often executed on a well-defined resource across multiple products, which makes these tasks good candidates to be helped by resource modules.

Security automation resource modules for Access Control Lists

Following this line of thought we have started to introduce ACLs resource modules within Ansible. ACLs can help provide a first layer of security when applied to interfaces, or globally as access rules, as they permit or deny traffic flows in firewalls.

Within an ACL the order of Access Control Entries (ACEs) are crucial since based on the ACEs sequence/order, appliances decide whether traffic is allowed or not. Given this background, an ACL resource module provides the same level of functionality that a user can achieve when manually changing the configuration on a corresponding device. However, the ACL resource module comes with the advantages of Ansible:

Automating things using Ansible can accelerate the time to become productive.
Ansible is powerful and users can automate a wide variety of tasks, at both the user or enterprise level. This helps to orchestrate the complete app lifecycle including the ACLs, and makes the security automation part of the app deployment process and the entire technical business process.
Ansible has agentless architecture which uses the native communication protocols of the managed target nodes. This avoids the need to introduce and install new software and new security protocols in the managed environments.
Last but not least, with the help of Ansible's fact gathering, the data structures of managed nodes can be collected and made accessible in an efficient manner.

Please note that the naming convention for the new ACL resource modules uses the plural form instead of singular: "acls" instead of "acl". If the platform you're automating has modules with both names, the plural form of the module is the newer one corresponding to the resource module initiative. The singular form of the module will likely be deprecated in a future release. This distinction was introduced to ease the transition to resource modules and avoid disruption of the current automated workflows.

Example: Cisco ASA ACLs

A good way to understand the new ACLs resource modules is via an example. For this, let's have a look at the Cisco ASA Collection which targets the Cisco Adaptive Security Appliance family of security devices. In this Collection you will find a module called asa_acls which is the resource module to manage named or numbered ACLs on ASA devices.

As an example, let's first check the current documentation. For that, we can use the capability of the module to gather the existing ACLs configuration:

---
- name: Get structured data
  hosts: cisco
  gather_facts: false
  collections:
   - cisco.asa

  tasks:
  - name: Gather facts
    asa_acls:
      state: gathered
      register: gather
  - name: output data
    debug:
      vars: “{{ gather }}”

The output will be something along the lines of:

- acls:
   - aces:
       - destination:
           address: 192.0.3.0
           netmask: 255.255.255.0
           port_protocol:
                 eq: www
         grant: deny
…

Note that the output generated this way is purely focused on the resource at hand - ACLs. This is in contrast to a generic fact gathering wheremore data is provided, making it difficult to keep an overview and handle the data subsequently.

Given the configuration at hand, let's assume for the sake of this example that we analyze the gathered configuration, and want to make a change to it. The next configuration looks like:

- acls:
  - name: global_access
    acl_type: extended
    aces:
    - grant: deny
      line: 1
      protocol_options:
        tcp: true
      source:
        address: 192.0.4.0
        netmask: 255.255.255.0
        port_protocol:
          eq: telnet
      destination:
        address: 192.0.5.0
        netmask: 255.255.255.0
        port_protocol:
          eq: www

This configuration describes that access from a defined source to a target is denied. Note that this entire definition is mostly product agnostic and can be used with other systems as well.

Given this description is available as the variable acls this can be deployed with the cisco_acls module:

---
- name: Replace ACLs device configuration
  hosts: cisco
  gather_facts: false
  collections:
   - cisco.asa

  tasks:
  - name: Replaces device configuration of listed acls
    asa_acls:
      config: “{{ acls }}”
      state: replaced

As you see it is possible to apply an existing resource description to an existing device. Resource modules allow the user to read in existing configuration and convert that into a structured data model. These data models can be used as a base to further deploy changed configuration on the target nodes.

Takeaways

Security professionals are in need of unification of their operational workflows. Automation helps - even more so if the platform it is running on provides a simpler means to control otherwise rather complex structures. The Ansible security automation resource modules provided are a building block in standardizing automation actions.