Many security baseline processes are rife with challenges. Whether organizations use scripts to manually brute-force their system-level compliance baseline, or perhaps leverage the all-too-common “Gold Disk” approach, routine security baseline compliance remediation remains largely an unsolved and constant challenge even for the most mature of IT organizations.

Even for organizations that are using an existing management tool to help with their security baselining, issues frequently arise around how to identify systems that require baselining as they come online, and then immediately recognize what needs to be done on those systems in order to verify their compliance.

To add to the challenge, applying a baseline to a newly deployed server or application is one thing, but validating compliance throughout the server and application lifecycle typically requires a separate set of tools or processes, or at very least scripts that are smart enough to smartly change the existing state of a server or application without impacting its availability.

MindPoint Group knew there was a better way. The security folks at MindPoint group are leveraging the power and simplicity of Ansible to bring automation to the problem of security baselines. And thanks to Ansible’s design, the work that MindPoint group has done is as useful for existing systems as it is for new. We’ve collectively started with the DISA STIG for Red Hat Enterprise Linux 6, but will soon be expanding to other baselines such as the CIS benchmark, and other operating systems.

Given MindPoint Group’s expertise in using Automation to repeatedly and securely apply and remediate various security baseline standards, who better than MindPoint Group CEO Matt Shepherd to talk about why automation is the only way to ensure compliance?

When Ansible was first founded three years ago, the underlying premise was to simplify some of the complexity in the existing DevOps tools. The mere idea of needing a strong developer toolset to automate your IT infrastructure was an overwhelming concept for most. I believe this is one of the underlying reasons that the majority of the IT shops are still using home-crafted scripts to automate updates to their infrastructure and shying away from having to add more complexity to an already complex world.

The well known quote from, Dieter Rams, the famous industrial designer, saying: “Less but Better”, has become somewhat of a guiding principle for Ansible. Being able to achieve in few lines of YAML script, during lunch hour what you can’t do in days of writing code with others.

In fact, not only do we apply that principle to our products in general, but to other operational things we do at Ansible, Inc. - from our internal communication to the onboarding process of new employees to how we handle customer support tickets. We are building an organization and an enterprise product based on simplicity. In fact, I’ve become a strong believer in the notion that complex organizations tend to naturally drift towards creating complex products, while the opposite is also true.

Just as in Dieter’s principle of design around usefulness, aesthetic and minimal design, the Ansible mantra is about giving the user that first amazing experience of “this is so easy to use and it works”, similar to that experience of getting your first iPhone or iPad. The experience of minimal effort needed in achieving goals beyond what was expected.

The need for simplicity in an open source project has also played a key role for us. Allowing contributors to quickly ramp up their understanding of the baseline of the Ansible project, only to turn around and contribute back to the project is one of the reasons why Ansible is now among the top 10 open source projects and has a strong list of over a thousand contributors. Of course, the challenge lies in the fact that not all contributors are the same, and not every contribution builds on our story of simplicity. The weight then shifts in being careful in pulling random requests into the product while continuing to set standards and rebuilding frameworks that would make contributions easier to incorporate.

As we add higher-level enterprise extensions into the Ansible Tower product, it becomes more challenging to continue to maintain a level of simplicity. The downward pressure from enterprise companies incorporating new features that would potentially add complexity in the code base. As with most IT products, complexity only increases as integration with the necessary technology ecosystem, and support for large customers grow.

The Ansible engineering management team has to constantly check the boxes:

1) Is the new technology necessary and will it serve the many versus the few?

2) Will this technology create unnecessary complexity?

3) Is there an easier path to take?

Simple products that serve a real need will always have the upper hand. Maintaining the simplicity of a software product that has to serve complex IT environments at scale is a tall order for any company out there, no matter how big. Ansible today, after years in the open, has consistently maintained that simplicity aspect, although at times at a cost. This, I’m convinced of now, has been the leading factor in the amazing adoption trend we realized in the last two years and continue to see today.

I’d love to hear from you - what are your thoughts about Ansible and how we can keep it as simple and accessible as possible?

Ansible architect and craft beer connoisseur Jonathan Davila played a critical role in working with our trusted security partner MindPoint Group to get our joint automated security baseline project off the ground. With our release this week of the DISA STIG for RHEL 6, we’ve immediately improved the lives of Government IT admins that struggle to ensure their systems are compliant.

Merely building the Ansible role for Red Hat Enterprise Linux 6 (And CentOS variants) STIG required more than writing and organizing a collection of playbooks. In order to ensure that the role actually achieved the remediation goal, we needed to validate and verify updates through a continuous integration testing process that leverages the DISA-provided SCAP/OVAL definitions.

You can learn more about the mechanics of how Jonathan and the MindPoint Group built the STIG Role, along with technical details about how to replicate this testing method in your own environment here.

Want to learn more about the how and why? Jonathan also penned a LinkedIn article with his own thoughts about why this is an important step in the right direction for any IT organization that’s concerned about automagically applying and validating security baselines.

If you missed our Ansible Training webinar today, or were not able to sign-up before it filled up, we were able to record the session. If you were able to attend, we hope you enjoyed it and learned about how to use Ansible.

We'll be announcing the next session soon, so follow us on Twitter for updates.

Ansible has teamed with security consultancy MindPoint Group to develop, release, and support a set of Ansible Roles that will save IT organizations considerable amounts of time when applying and maintaining security baselines such as the DISA STIG or CIS benchmark to IT environments.

Why MindPoint Group? That answer is simple. MindPoint Group has a singular focus which has led to an excellent reputation for delivering end-to-end security solutions to commercial and government clients alike.This focus, coupled with their love of Ansible, made MindPoint Group a natural choice for partnering on the development of free-and-open security baseline roles and playbooks.

The best part? This relationship is already helping Ansible users.

The first Role is for the DISA STIG on RHEL 6 (and variant systems) and is now available in Ansible Galaxy. This Role enables customers to automate the application and management of STIG-compliant systems in their environments, all the while leveraging Ansible’s agentless management framework. When applied using Ansible, the RHEL 6 STIG Role automates a significant amount of the manual and redundant scripting and remediation that IT organizations often rely on to ensure they meet the STIG OS requirements.

Releasing this important Role is just the beginning. Along with Role updates to support other operating systems, we'll also be creating Roles to cover additional security baselines, and eventually, specific application baseline requirements.

We're excited to be working together to help bring the reality of automated security baselines to the large community of Ansible users. Over the next several weeks, we'll be releasing additional content discussing how automation and security go hand-in-hand, so check back frequently!