Automating Endpoint Protection with Ansible

Enterprise security isn’t a homogeneous entity; it’s a portfolio of multi-vendor solutions run by disparate and often siloed teams. With so many different layers, automation proved to be effective in helping security operations teams to integrate and share accountability.

Automated processes and workflows simplify and accelerate shared processes, like investigation & response and, if enabled with a platform with the right characteristics, encourage a more open culture of collaboration.

Red Hat Ansible Automation Platform caters to this growing importance of security with Ansible security automation: our answer to the lack of integration across the IT security industry. If you are new to the topic, a good place to start is our investigation enrichment blog. A good follow up is our blog post about threat hunting, extending the application of Ansible security automation to multiple teams across the IT department.

The Ansible security automation initiative grew significantly over the last two years, adding more partners and covering additional domains and use cases. If you want to know more about what is available, have a look at the supported Collections that can be accessed via cloud.redhat.com for more details. The most recent addition to our security automation initiative was Continue reading

Getting started with Ansible security automation: Threat Hunting

AnsibleFest has just wrapped up, with a whole track dedicated to security automation, our answer to the lack of integration across the IT security industry. If you’re looking for a use case to start with, our investigation enrichment blog will give you yet another example of where Ansible can facilitate typical operational challenges of security practitioners.

Ansible security automation is about integrating various security technologies with each other. One part of this challenge is the technical complexity: different products, interfaces, workflows, etc. But another equally important part is getting the processes of different teams in the security organization aligned. After all, one sign of successful automation is the deployment across team boundaries.

This is especially true with threat hunting activities: when security analysts suspect a malicious activity or want to prove a hypothesis, they need to work with rules and policies to fine tune the detection and identification. This involves changes and configurations on various target systems managed by different teams.

In this blog post, we will start with a typical day-to-day security operations challenge and walk through some example threat hunting steps - adding more teams and products over the course to finally show how Red Hat Ansible Automation Continue reading

Security Channel at AnsibleFest 2020

Security automation is an area that encompasses different practices, such as investigation & response, security compliance, hardening, etc. While security is a prominent topic now more than ever, all of these activities also greatly benefit from automation. 

For the second year at AnsibleFest, we will have a channel dedicated to security automation. We talked with channel Lead Massimo Ferrari to learn more about the security automation channel and the sessions within it. 

Security Channel

The sessions in this channel will show you how to introduce and consume Red Hat Ansible Automation Platform in different stages of maturity of your security organization as well as using it to share processes through cross-functional teams. Sessions include guidance from customers, Red Hat subject matter experts and certified partners.

What will Attendees learn?

The target audience is security professionals who want to learn how Ansible can support and simplify their activities, and automation experts tasked with expanding the footprint of their automation practice and support security teams in their organization. This track is focused on customer stories and technical guidance on response & remediation, security operations and vulnerability management use cases. 

Content is suitable for both automation veterans and Continue reading

Getting Started with IBM QRadar and Red Hat Ansible Automation Platform

IBM Security QRadar is a Security Information and Event Management (SIEM), which can help security teams to accurately detect and prioritize threats across the organization, providing intelligent insights that enable organisations to respond quickly to reduce the impact of incidents. By consolidating log events and network flow data from thousands of devices, endpoints, users and applications distributed throughout your network, QRadar correlates all this different information and aggregates related events into single alerts to accelerate incident analysis and remediation. 

Ansible and QRadar, better together

Ansible is the open and powerful language security teams can use to interoperate across the various security technologies involved in their day-to-day activities.

Customers can take advantage of the IBM QRadar Content Collection to create sophisticated security workflows through the automation of the following functionalities:

• Log sources configuration
• Offense rules enablement
• Offense management

Ansible allows security organizations to integrate QRadar into automated security processes, enabling them to automate QRadar configuration deployments in recurring situations like automated test environments, but also in large scale deployments where similar tasks have to be rolled out and managed across multiple nodes.

Security practitioners can automate investigation activities enabling QRadar to programmatically access newdata sources. Also, they now have Continue reading

Getting started with Ansible security automation: Investigation Enrichment

Last November we introduced Ansible security automation as our answer to the lack of integration across the IT security industry. Let's have a closer look at one of the scenarios where Ansible can facilitate typical operational challenges of security practitioners.

A big portion of security practitioners' daily activity is dedicated to investigative tasks. Enrichment is one of those tasks, and could be both repetitive and time-consuming, making it a perfect candidate for automation. Streamlining these processes can free up their analysts to focus on more strategic tasks, accelerate the response in time-sensitive situations and reduce human errors. However, in many large organizations , the multiple security solutions aspect of these activities are not integrated with each other. Hence, different teams may be in charge of different aspects of IT security, sometimes with no processes in common.

That often leads to manual work and interaction between people of different teams which can be error-prone and above all, slow. So when something suspicious happens and further attention is needed, security teams spend a lot of valuable time operating on many different security solutions and coordinating work with other teams, instead of focusing on the suspicious activity directly.

In this blog post we Continue reading

Getting Started With Ansible Hub

In the past, Ansible content such as roles, modules and plugins was usually consumed in two ways: the modules were part of the Ansible package, and roles could be found in Galaxy. However, as time went on the current method of content distribution had challenges with scale for both contributors and consumers of Ansible content. Dylan described this in a blog post worth reading.

Recent releases of Ansible started a journey towards better content management. In previous Ansible releases, each and every module was strictly tied to the release schedule of Ansible and community, customer, and partner feedback demonstrated that the release schedule of content needed to evolve.  Ansible content collections allow our Ansible contributors to create specialized content without being tied to a specific release cycle of the Ansible product, making it easier to plan and deliver. For Ansible newcomers, the collections come “pre-packaged” with modules and playbooks around common use cases like networking and security, making it easier to get off the ground with Ansible. If you want to learn more about Ansible content collections, check out our series about collections!

The introduction of collections to the Ansible ecosystem solves a number of challenges for access to Continue reading

Getting Started With Automation Hub

In the past, Ansible content such as roles, modules and plugins was usually consumed in two ways: the modules were part of the Ansible package, and roles could be found in Galaxy. However, as time went on the current method of content distribution had challenges with scale for both contributors and consumers of Ansible content. Dylan described this in a blog post worth reading.

Recent releases of Ansible started a journey towards better content management. In previous Ansible releases, each and every module was strictly tied to the release schedule of Ansible and community, customer, and partner feedback demonstrated that the release schedule of content needed to evolve.  Ansible content collections allow our Ansible contributors to create specialized content without being tied to a specific release cycle of the Ansible product, making it easier to plan and deliver. For Ansible newcomers, the collections come “pre-packaged” with modules and playbooks around common use cases like networking and security, making it easier to get off the ground with Ansible. If you want to learn more about Ansible content collections, check out our series about collections!

The introduction of collections to the Ansible ecosystem solves a number of challenges for access to Continue reading

Using Ansible and Ansible Tower with shared roles

Roles are an essential part of Ansible, and help in structuring your automation content. The idea is to have clearly defined roles for dedicated tasks. During your automation code, the roles will be called by the Ansible Playbooks.

Since roles usually have a well defined purpose, they make it easy to reuse your code for yourself, but also in your team. And you can even share roles with the global community. In fact, the Ansible community created Ansible Galaxy as a central place to display, search and view Ansible roles from thousands of people.

So what does a role look like? Basically it is a predefined structure of folders and files to hold your automation code. There is a folder for your templates, a folder to keep files with tasks, one for handlers, another one for your default variables, and so on:

tasks/ 
handlers/ 
files/ 
templates/ 
vars/ 
defaults/ 
meta/

In folders which contain Ansible code - like tasks, handlers, vars, defaults - there are main.yml files. Those contain the relevant Ansible bits. In case of the tasks directory, they often include other yaml files within the same directory. Roles even provide ways to test your automation code - in Continue reading

Using Ansible to manage RHEL 5 yesterday, today and tomorrow

With the release of Ansible 2.4, we now require that managed nodes have a Python version of at least 2.6. Most notable, this leaves RHEL 5 users asking how to manage RHEL 5 systems in the future - since it only provides Python 2.4.

Background

With the release of Ansible 2.4 in September 2017, we have moved to support Python 2.6 or higher on the managed nodes. This means previous support for Python-2.4 or Python-2.5 is no longer available:

Support for Python-2.4 and Python-2.5 on the managed system's side was dropped. If you need to manage a system that ships with Python-2.4 or Python-2.5, you'll need to install Python-2.6 or better on the managed system.

This was bound to happen at some point in time because Python 2.6 was released almost 10 years ago, and most systems in production these days are based upon 2.6 or newer version. Furthermore, Python 3 is getting more and more traction, and in the long term we need to be able to support it. However, as the official Python documentation shows, code that runs on both Python 2. Continue reading