System Hardening with Ansible
In this article, we talk about the key points of the security hardening process, such as automation, outlined by an industry leader.
Join the DZone community and get the full member experience.Join For Free
The DevOps pipeline is constantly changing. Therefore relevant security controls must be applied contextually.
We want to be secure, but I think all of us would rather spend our time developing and deploying software. Keeping up with server updates and all of the other security tasks is like cleaning your home - you know it has to be done, but you really just want to enjoy your clean home. The good news is you can hire a “service” to keep your application security up-to-date, giving you more time to develop.
At the recent All Day DevOps conference, Akash Mahajan (@makash), a Founder/Director at Appsecco, discussed how to harden your system’s security. In addition to his role at Appsecco, Akash is also involved as a local leader with the Open Web Application Security Project (OWASP).
During his presentation, Akash mentioned the OWASP Top 10 Security Vulnerabilities list, zeroing in on #5 - Security Misconfiguration. To determine if you comply with the guidelines, #5 on the list asks:
- Is any of your software out of date?
- Are there any unnecessary features enabled/installed including ports, services, accounts, pages, or privileges?
- Are default accounts and their passwords enabled/unchanged?
- Are security settings and libraries not set to secure values?
I am sure no one reading this article still uses the default administrator password, but can we say the same of your peers? Have you gotten around to installing the latest software patches on your server?
If a task can be automated, developers automate it. So we should automate our security tasks too, where we can. OWASP provides guidance here, suggesting you should:
- Have a repeatable security hardening process.
- Ensure your development, QA, and production servers are configured identically but with different passwords.
- Automate the process to minimize the effort required to setup a new secure environment.
- Implement a process for deploying all new software updates and patches in a timely manner to each deployed environment.
- Run scans and audits periodically to help detect future misconfigurations or missing patches.
This is all part of security hardening, which is, “the process where we identify default configuration present on a system and apply changes that will change the configuration to secure values.” This can be applied to your network, transport, application, and kernel networking parameters.
Ansible is one of the solutions Akash likes to work with, but there are others solutions on the market that provide similar value. Without trying to endorse or evaluate one solution over another, let me share some perspectives from Akash’s experience with his tool set.
Why does he like it? It boils down to playbooks. An Ansible playbook is a codified security document, allowing you to describe the desired state of a system, rather than the specific steps of how to get to that state. As Akash points out, things change - it is better to have the end state described rather than have to change commands when the system changes.
Other advantages of playbooks include:
- Playbooks are written in YAML providing us with a structure that we can learn and train on.
- Playbooks are text files, so we can use Git for version control.
- Managing playbooks is just like managing any software project.
- Playbooks are infrastructure as code, but for security.
- Playbooks consist of roles, a key aspect of security.
- Numerous playbooks are available as open source.
The bottom line is you can, and you should automate your security hardening process. Your users and other stakeholders will thank you, and, most of all, you will thank yourself because you can spend more time on the things you love to do.
Ansible is just one example of a solution that can be used to automate your security tasks. If you want to know more, Akash goes into further detail on getting started with Ansible in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free-of-charge.
This blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps at Massive Scale.” Next week, look for “Operationalizing a Red Team for Fun and Profit,” delivered by Intuit’s own Ian Allison.
Published at DZone with permission of Derek Weeks, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.