At the start of a DevOps cloud adoption project, there is usually some friction between security and development teams. It can take an enterprise months, even years, to fully integrate security teams into faster development cycles—time that enterprises cannot afford. The solution DevSecOps, a set of practices designed to bring security teams up to speed and leverage new ways to protect clouds.
The good news is that enterprises are already building the tools and processes security teams need to succeed. Here are five tips to help you integrate the DevOps and security teams:
1. Identify the challenge. When DevOps processes are limited to a single business unit or team, maintaining security practices is fairly simple. The problem comes when the entire security organization -- that has likely been exposed sporadically to DevOps -- is expected to develop new company-wide processes and standardize security methodologies.
Here’s what what typically happens when you apply old security processes to DevOps teams: The central security organization develops cloud-specific security documentation and inserts themselves at various stages of the sprint (often the testing phase). This involves manually ensuring that cloud resource configurations meet specifications. And it takes weeks from identifying a new cloud security vulnerability to documenting the fix to deploying the fix, creating delays and slowing deployment.
It is easy to see that the culprit in this scenario is manual security work. When operations builds systems manually, they do manual network and configuration work, which has the potential for errors and therefore must be manually checked. When security teams identify a problem, they must manually document the solution which must be manually deployed, instance by instance, in your environment. This burns hours that security teams should be spending in more valuable efforts.
2. Expose security teams to DevOps early. Once the security organization has identified the challenge -- or is already feeling the repercussions of slow security services -- the next step is education. Security teams need to be exposed to DevOps technologies and methodologies, which in turn leads to a period of learning about cloud development and deployment tools.
The light bulb goes off when security teams realize that DevOps tools -- like configuration management -- can actually be used to improve governance. In fact, before configuration management tools like Puppet and Chef were used to automate deployment pipelines, they were used by security professionals to implement and guarantee security configurations on servers. Witnessing the power of declarative configuration languages resonates with security professionals by providing new and exciting solutions to their daily tribulations.
3. Centralize the solution. When security professionals see the power of DevOps to improve their daily workloads, resistance usually fades. At this stage, they begin to develop more mature practices around security-as-code.
What is security-as-code Certain aspects of basic system security, like network configurations and access policies, can and should be modular, scripted templates that are available for reuse in a tool like AWS CloudFormation or Troposphere combined with a configuration management tool like Puppet, Chef, or Ansible. These tools allow security professionals to “hard code” best practices into every build rather than enforcing best practices post facto. Moving security testing and auditing closer to the code both increases the value of security professionals and decreases the cost of remediation.
4. Protect your security team’s time. Once your security team has worked together with operations to “bake” their security practices into templates, they no longer need to review every single new environment. That is because those templates are kept in a central repository, used on every single new environment, and changes or alterations must be checked out as a branch and submitted for approval. Security professionals only need to review changes to a single template, not review and test the thousands of instances created based on those templates.
The outcome You have outlawed manual configuration work and significantly reduced the risk of an operations engineer can make a manual, uncounted error (like forgetting a critical security configuration). And in the meantime, you have refocused your security team on what matters and not on manual, repetitive, and unproductive work.
5. Break your own software. After you build security-as-code, the final critical component of DevSecOps is to not trust it. No system -- even one with little human interaction and high governance -- is error-free. The only way to discover these flaws is continual testing.
Part of your central IT team must form a “red team” that tries to get access to your environment through both social engineering and brute force. This also helps security teams convince developers and engineers to take immediate action (because getting hacked is embarrassing for any DevOps team).
There is a reason DevSecOps is rising in popularity: it is the only well-defined methodology that addresses the security of the cloud in an enterprise DevOps setting. Whether this evolution takes place during cloud planning or after interaction between security and DevOps teams has already developed, it is a crucial step towards securing cloud resources.
Logicworks is a leading cloud automation and managed services provider with 22+ years of experience helping enterprises transform IT. As an AWS Premier Consulting Partner, Logicworks specializes in hybrid and managed AWS solutions for the healthcare, financial, legal and commerce industries. For more information visit: http://www.logicworks.net/