Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How to use DevSecOps to smooth cloud deployment

Jason McKay, SVP and Chief Technology Officer, Logicworks | March 9, 2016
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.

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.


Previous Page  1  2 

Sign up for CIO Asia eNewsletters.