Automate all the Security

Talk at the Continuous Lifecycle Conference - London May 2016

Photo on slide two by the very talented Tom Garnett of tgarnett.com

Transcript

1. Automate all the security! Kat McIvor katrina.mcivor@qa.com
2. Kat McIvor (Samperi) @Kaiylie Principal Technologist – DevOps at QA Ltd PhD in Computer Science / Intelligent Agents (come talk to me about game agents and building maps!) Who am I?
3. Write some code Test Locally Push to Source Control Build and test on server Build Container Push to deployment Monitor
4. Write some code Test Locally Push to Source Control Build and test on server Build Container Push to deployment Monitor Security!?
5. Security should not be left until the end Plan from the start Test throughout
6. Humans are terrible at repetitive tasks!
8. Leaning in over Always Saying “No” Data & Security Science over Fear, Uncertainty and Doubt Open Contribution & Collaboration over Security-Only Requirements Consumable Security Services with APIs over Mandated Security Controls & Paperwork Business Driven Security Scores over Rubber Stamp Security Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities 24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident Shared Threat Intelligence over Keeping Info to Ourselves Compliance Operations over Clipboards & Checklists Call to action - http://www.devsecops.org/
12. Security as code? Why not!
13. My Security Policy The host machine should be configured according to best practices Apache should be installed Git should not be installed Port 80 should be open Port 8080 should not be open
14. Security in Config Management
15. Using Test Kitchen: Security in Config Management control_group 'webserver' do control 'apache working and listening on port 80' do it 'is installed' do expect(package('apache2')).to be_installed end it 'should be listening on port 80' do expect(port(80)).to be_listening end end … end
16. Security in Containers
17. Who built the image? What was in the Dockerfile?
18. What base image was used? How do you know what is inside that?
19. How do you even know you got the right base image?
20. Which user are you running as – inside and out?
21. Have the contents of the container changed?
22. Automated tools for identifying problems - Docker Bench - Identify problems on the docker host Security in Containers - Host
23. Scan your Dockerfiles or running containers for problems with ServerSpec Security in Containers - Dockerfile describe "Dockerfile" do describe package('apache2') do it { should be_installed } end it 'should not expose random ports' do expect(@image.json['ContainerConfig']['ExposedPorts']).to contain_exactly(["80/tcp", {}]) end end end
24. SecComp in the Docker engine Security in Containers – When running { "defaultAction" : "SCMP_ACT_ALLOW", "syscalls": [ { "name" : "chmod", "action" : "SCMP_ACT_ERRNO" } ] } $ docker run --security-opt seccomp:chmod.json busybox \ chmod 400 /etc/hostname chmod: /etc/hostname: Operation not permitted
25. When should you do your testing?
26. Before being built Dockerfile / Ansible Config / Puppet Manifest / Chef Recipe
27. While being built Jenkins / GoCD / Travis
28. When in production Monitoring – Changes in containers, config drift
29. module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch = ' '; len = len - str.length; while (++i < len) { str = ch + str; } return str; }
31. Security policy as code Automate the tests Understand your supply chain
32. katrina.mcivor@qa.com @Kaiylie Find me over coffee!