As cloud development and deployment practices move faster and become more agile, security teams have realized that the only effective ways to secure cloud application and system deployments are to develop security controls that integrate into the deployment pipeline, and to automate as much as possible. Many in the security community have dubbed this approach security as code, a take on the infrastructure as code mentality of defining all virtual and cloud-based stack components as configurable elements that are treated as just another software definition and managed in configuration files and templates.
However, many security teams struggle with how to get started down this path. Most security professionals don't come from software development backgrounds, and this can create a disconnect with DevOps teams that use highly automated and agile tools and processes to integrate, test and deploy code into the cloud.
It's important to keep in mind that most DevOps engineers and developers want their deployments to be as secure as possible, but they need security to integrate with their environments, not implement roadblocks and use slow, unwieldy tools and processes that can cripple scalability and speed.
To that end, security teams should start by learning the DevOps tools in use within the DevOps environment. Today, this will often include Jenkins, Chef, Puppet, Salt, Ansible, GitHub and many others. Security teams do not need to be experts on all these DevOps tools, but will need to consider the following:
- The DevOps tools that are used to store and manage code. If Jenkins is used to build integration with GitHub, for example, security teams will need to know how permissions are managed, what sorts of logs are available on Jenkins when code is checked in and pushed out, etc. Additionally, source code scanning and review should be integrated at this level to ensure no secrets or cryptographic keys are being included in the code.
- The tools that are used to create and manage server configuration and deployment orchestration. Chef, Puppet and Ansible are common choices in many environments, and all have their own definition languages and varied configuration files. Security teams need to integrate configuration settings and security policies into definition files within these platforms.
Fortunately, all of the major configuration and automation tools have readily available configuration templates and policy assessment templates that align with the Center for Internet Security benchmarks, Defense Information Systems Agency Security Technical Implementation Guides and other industry best practices and requirements.
- The DevOps tools that are used to store and access credentials and keys. Sound DevOps practices mandate the use of a separate platform for controlling credentials and keys, such as HashiCorp Vault or Ansible Tower. It is critical to monitor and carefully control all access to these platforms, and security teams should have the ability to independently audit access and send logs to a remote logging repository.
Once a version of server and application stack elements is approved, security teams should strive to have an immutable infrastructure, where deployments are pushed out, and any subsequent attempts to change it are ignored until the next approved build revision is defined. Many of the aforementioned DevOps tools support this natively. For instance, if an Ansible playbook is used to generate a server configuration, running the playbook again will not cause any additional changes or issues.
To successfully integrate into the development and deployment process, security teams need to make sure at least one team member is dedicated most (or, ideally, all) of the time to working side-by-side with the DevOps team. This approach, sometimes called DevSecOps, ensures that all changes and updates are secured properly long before any code is promoted to production or any systems are built in secure cloud environments.
This entire deployment pipeline integration is only one half of the process, however. Security teams will also need to incorporate an automated feedback loop for systems and application stacks running in the cloud, which will be covered in part two.
Find out how cloud orchestration and automation make multicloud possible
Learn about the role automation can play in moving cloud workloads
Discover how to streamline cloud operations with Google automation tools