Support

Careers

10 Practical Security Tips for DevOps (Part 1)

Posted Mar 17 2015

James Brown

More organisations are embracing DevOps and automation to realise compelling business benefits, such as more frequent feature releases, increased application stability, and more productive resource utilization. However, many security and compliance monitoring tools have not kept up. In fact, they often represent the largest single remaining barrier to continuous delivery.

By working with the DevOps team, you can ensure that the production environment is more predictable, auditable and more secure than before. The key is to integrate your security requirements into the DevOps pipeline; however, as part of that integration you will need to change the way you work. A normal approach of checklists, templates, manual processes etc will not scale. With the speed of cloud deployments, you will need to automate and use tools and scripts. This will allow you to move as fast as the DevOps team needs you to.

For security professionals, it is key to understand that instead of validating the end solution, you need to validate the pipeline. If you are happy that the pipeline is building the solution in a way that meets you security goals, you can be confident that this will be repeated every time a developer needs to get source code into production.10 Practical Security Tips for DevOps

1. Architecture and Design

During architecture and design the development teams will be attempting to rapidly iterate against the requirements whilst building out the Cloud infrastructure. It is at this point that security teams need to get involved to understand the scope of what teams are looking at; different elements of the infrastructure need protection in different ways. Learn and understand the shared security model – Amazon S3 is very different in protecting EBS storage on an EC2 instance, the barriers between IaaS and PaaS are rapidly breaking down, and each has a different security paradigm.

Threat Modelling can be done against the different components. This will allow security teams to define the threats against the different components and what elements are going to be needed further up the DevOps pipeline to secure them.

ACTION: Work with the architecture to understand the cloud components being used, and the security controls required for each. Take this further by using techniques like Threat Modelling.

2. Static code analysis + Code Reviews

Code reviews are a common part of DevOps, Security team should educate colleagues on secure coding techniques so that they can include this into their secure code reviews. However, many of these items can be validated by using Static Code analysis as part of the build process. This is where the source code or a partially compiled version of the source code can be checked for potential vulnerabilities. Many potential security vulnerabilities can be picked up at this point, and if they fail the checks – it breaks the build. Developers will quickly change coding techniques to meet the requirements.

ACTION: Understand what the current code review process is and ensure that there are security elements within that. Likewise investigate what Static Code Analysis tools are available and if they can be used.

3. Audit of Chef Cookbooks / CloudFormation Scripts

You will hear the phrase ‘infrastructure as code’ a lot in the DevOps world. This is where the infrastructure is built in a highly automated way using scripts and configuration files. The advantage of this for a security professional is that automated checks can be run against these scripts. If a developer creates an infrastructure script to create a storage bucket with public access to the internet, this can raise an error. Combine this with the threat modelling where you have identified potential issues (like marking a storage bucket as public) and you have a very powerful tool to validate the infrastructure every time a developer makes a change.

ACTION: Use the automation tools to ensure that the infrastructure is being built to meet the security standards.

4. Security Testing post build

Automated builds and unit tests running after check-in are a core part of DevOps. This is where security teams can add-in security testing tools to automate the validation of the build (https://www.owasp.org/index.php/Appendix_A:_Testing_Tools ). The reason why automated build and testing is so key in DevOps is that the shorter the time between a developer checking in code and a test failing, the less time it will take for the developer to fix the issue. The same holds true for security vulnerabilities; running tests at the end of the project can inject significant delays as developers struggle to identify the issues and fix the bug. Identifying the issue within minutes of a developer checking the code in reduces the time taken to identify and fix the issue.

Let’s move from ‘Infrastructure as Code’ to ‘Secure Infrastructure as Code’. If you are creating and building servers via scripting, let’s also add in the scripts to lockdown the OS as well. The risk of applying OS hardening at the end of the project is that the application stops working. If it is applied at the beginning of the project, firstly, issues are identified up front, and secondly, if the hardening has to be relaxed, it can be identified early, and security teams can work with the developer to potentially find another way of performing the function. If it occurs late in the project, the development team will force the issue through.

ACTION: Review the automation scripts to ensure that the OS is being deployed in a secure way and any changes to this standard are controlled. Use resources like SANS Linux Security Checklist or CIS Benchmark.