DevOps and Security #c9d9

What are some of the best practices for building security as an integral part of your tools and practices throughout your delivery pipeline?

On Tuesday I participated in an online panel on the subject of DevOps and Security, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps.

Watch a recording of the panel:

Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE and E*TRADE by automating their build, test and deployment processes.

Below are a few insights from my contribution to the panel:

Securing your code

Two things come to my mind, the first is security, especially security in your source code is something that you need to bring into your team, need to educate about a lot, you need to get into new techniques, iterate over the thing you already have security-wise in your source code, so a big part of it in my opinion is education of the team to get everybody aware of the security issues that can arise when running source code.

The other thing, we are talking about DevOps and DevOps is also automation for me and that raises the question “how can we automate the security of our source code?” So one thing that comes to my mind is to check the dependencies, whatever dependencies that are coming together and bundle it in your application. Check them automatically for known issues or security issues.

Secure your Environments

Two points: The first is a secure infrastructure, a secure environment for running applications. That’s an infrastructure that is defined by code and that is part of your deployment pipeline, that means having pure reviews for security-relevant infrastructure parts like authorization tools, cloud services and stuff like that, and then to deploy those things automatically to production to avoid human failure, to have a machine do all that work and also to have automated testing for the security configurations, testing infrastructure and also in combination with the application. That is the most important thing in my opinion, to have a continuous deployment pipeline and build security into that.

The other thing is what I see working a lot with AWS, I don’t know if you ever tried to configure the Identity and Access Management service to handle authorization to different services and also configure the VPCs and security hooks and all that stuff, if your security configuration gets too complex then you are totally lost. For me, keep it simple is true for a security configuration especially, so if you are not able to define a simple and secure security configuration, then I bet I will find a hole in your security configuration. If someone added a rule later to work around an issue and actually open everything to the world. Those are the two things for me, automation through infrastructure as code, and the other thing is keep it simple so you have the simplest security configuration that is possible and still secure.

Secure Your Process

My idea on security process or securing the process of bringing a software into this world, is the idea to do Agile, the idea is to iterate on your products where you are used to improve them step by step and sometimes I wonder why we are not using the same process to improve security. As iterations on our security are getting better step by step because there is no such thing as 100% security, so it means we have to start with the basics and then we have to get better and better. Probably our product owners are not happy with investing huge amounts of developer time to get to a security level that is extremely high, so we need to start small and then iterate and keep getting better and better, that’s is something that’s important to me.

One example from my day to day work is, we are doing a monthly review of our network and firewall configuration, everyone from developers to DevOps engineers sitting together and they review our firewall and network configuration. Each month they find something that is worth improving, so of course the system is changing, people add new configuration, new firewall rules and also, because another DevOps engineer looks at the same rules and sees an issue in there. That is why I think it is important to have a process of iterating over your security, infrastructure or relevant parts of the infrastructure and to increase security step by step.

Improve Visibility and Compliance

If compliance rules are sometimes hard to communicate to the whole organization especially if your teams are changing a lot, so one thing that I like is to have compliance rules as code, and check your infrastructure and your application against them. One concrete example I can give is I’m working with infrastructure code tool from AWS called CloudFormation, a small tool that just allows me to define a compliance rule and then check it before the code of the infrastructure gets deployed, it means you can actually check if something is compliant against your rule sets before it comes to production, that’s in my opinion a very important part because often compliance is something you look at after things happen, so you check if everything is okay right now, and you are not checking if things will be all right after we build this deployment.