A+: AMI’s, Automation & AWS
A few weeks ago, I attended AWS re:Invent 2016 with nine of my colleagues. If you have never been, re:Invent is pretty cool, not your typical conference, and the number of attendees keeps growing year after year. To put it into perspective, 8,000 people attended re:Invent three years ago, while this year that number jumped to over 30,000. In other words, if you have an interest in cloud computing, re:Invent is not a waste of time. So, what exactly is this conference all about? AWS re:Invent is a conference where attendees can find the latest in cloud technology, participate in new technology driven sessions, and get the opportunity to have AWS specific questions answered by other peers and subject matter experts in the field. This year, we noticed a few constant topics that were the buzz amongst conference attendees. The most notable of them was the topic of automation and the best methods for implementation within a cloud environment. Cloud practitioners at re:Invent expressed a strong desire for automation to emerge as a key component of cloud computing, where its implementation could prove the necessity for machine-human interaction becoming obsolete, one play at a time. In the world of cloud security, automation provides effective, reliable, and repeatable methods of ensuring uniformity throughout a cloud environment. Typically, these methods include secure baselines, AMI automation, and the continuous monitoring of vulnerability management and compliance. When all their powers are combined, specific configuration settings allow for the improvement and reliability of workloads in an environment that relies more on automated tasks rather than human intervention.
In a cloud environment, it is prudent for not only security professionals but development and operations professionals, to embrace the importance of automation as it has the capability to make their lives easier. Security automation in a cloud environment simplifies the task of building a secure baseline, while ensuring continuous compliance with the necessary STIGS or other benchmarks that they have been modeled after. Compliance can be ensured by beginning with a custom AMI or deploying an instance from an AWS built AMI, and applying a “first run” security baseline deployment. There is a myriad of security configurations that need to be applied to ensure compliance requirements are met (changing or disabling default accounts and passwords, disabling non-essential services, etc.). In addition to baseline security settings, there are many environments that require specific security configurations that need to be applied as well. Part of the beauty of the cloud is that it is not a one size fits all solution from a requirements perspective. Therefore, the same can be said for the security of the resources used. This task can be daunting if attempted to be tackled through a manual process and nearly impossible to ensure continuous compliance as systems change throughout their lifecycle.
Ansible, STIGS, GitHub repo
MindPoint Group has achieved this integration with the deployment process on the project we’re working on and, through our partnership with Ansible, has aimed at developing secure configuration baseline roles to allow others to achieve the same results. MindPoint Group has created plays that can be used for “first run” deployment of applying the STIGs to images or instances. These plays can also be utilized as “continuous monitoring” of compliance with those STIGS. Using Ansible, one can either reapply the configuration settings or generate a report showing compliance status. This allows the security team to manage the library of baselines in the same manner that the operations team is managing the deployment process. Additionally, Ansible can provision an instance using the latest and greatest installation material to include a task in the deployment playbook used to apply any available future updates. In general, the result of injecting continuous deployment of secure configurations in the deployment pipeline equates to a highly secure environment with a uniform security posture.
When the Ansible playbook for deploying a system, or an update to a system, has been completed, it can be run through build testing to ensure that the system works both functionally and as intended, in terms of security. Once tests are passed and the system is put into operation, any deviations from the security baseline would be treated as a deviation from the approved code baseline and would pose a potential risk to keeping the system running properly. In this environment, re-applying the baseline using Ansible will tend to be viewed as constructive, rather than destructive. Once a role has been defined which will apply the baseline, and you integrate that role (among others) into the playbook for deploying your systems, then hopefully you’re keeping those playbooks under version control. Since the role for applying the baseline is a part of the process, the typical response to a deviation from “our approved codebase” is generally going to differ from a deviation from “the approved secure configuration baseline.”
Continuous Monitoring and Vulnerability Management
During the lifecycle of systems in your environment, there is a continuous game of cat and mouse with vulnerabilities as well as a definite need to monitor and remediate systems susceptible to those vulnerabilities. Continuous monitoring enables security professionals, among others, to see a continuous stream of near real-time snapshots depicting the state of risk to their security, data, network, end points, and even cloud devices and applications. It is critical that your vulnerability scanning and management systems stay in sync with the moving target of your cloud inventory. As of today, not many vulnerability scanning systems have the native ability to sync with Cloud Service Providers. Using continuous monitoring for event and vulnerability detection is expanding the external discussions about what continuous monitoring includes.
In the absence of built-in functionality, MindPoint Group has developed the ability to automate these tasks using Ansible in combination with the AWS CLI and applicable vulnerability scanning system APIs. Having an accurate inventory ensures the data returned from scanning efforts is complete, accurate, and insightful. Continuous monitoring is the ever-vigilant eyes of security professionals used to monitor and ensure current elements in the environment are relevant to avoid potential impacts today or in the future. Without continuous monitoring constantly evaluating the security state of an environment, it is quite possible for gaps in security to go undiscovered for long periods of time, resulting in an environment susceptible to exploits. With continuous monitoring, gaps would be noticed during routine upgrade cycles, or when monitoring system checks determine the need for new patch levels. Continuous monitoring does not imply true, real-time 24 x 7, nonstop monitoring and reporting. Instead, it means implementing monitoring and oversight processes that provide a clear picture of a security state at any given time, while also providing a myriad of control effectiveness over that period.
Automation with AMI’s used in AWS is a goal, not to replace humans with machines, but to reduce the reliance and necessity of humans repeatedly securing AMIs resulting in improved reliability of your workloads.
- Diversity and Inclusion - December 1, 2019
- MindPoint Group Achieving Diversity Without Mandate…What’s in the Secret Sauce? - August 26, 2018
- A Tale Of Two Tools: When Splunk met SecurityCenter - July 18, 2018