Securing your Infrastructure - One unit test at a time

Talk from #DevSecCon in London about adopting security policy as code by starting with a single unit test

Transcript

1. Securing Your Infrastructure Puppet Labs Gareth Rushgrove One unit test at a time
2. Common Problems Start by admitting we have a problem
3. Gareth Rushgrove Security in the news
4. Gareth Rushgrove Security in the news II
5. Gareth Rushgrove I’ll stop now
6. Individual ownership Silos Out of date documentation Shadow IT Gareth Rushgrove - - - -
7. Individual ownership Silos Out of date documentation Shadow IT Gareth Rushgrove - - - -
8. Individual ownership Silos Out of date documentation Shadow IT Gareth Rushgrove - - - -
9. Individual ownership Silos Out of date documentation Shadow IT Gareth Rushgrove - - - -
10. EVERYTHING IS TERRIBLE
11. Stories from System Administrators Maybe a path to follow
12. Gareth Rushgrove
13. Infrastructure as code Gareth Rushgrove
14. From manual and error prone interactions $ ls /etc/apache2/conf.d default.conf $ vim /etc/apache2/conf.d/default.conf $ service apache2 restart
15. Gareth Rushgrove Other tools exist :) To declarative modeling of infrastructure
16. Gareth Rushgrove Other tools exist :) To a common set of primatives
17. Gareth Rushgrove Other tools exist :) To a community of shared code working across platforms
18. Why Code It’s not about the programming
19. Definitive Versionable Reviewable Shareable Gareth Rushgrove - - - -
20. Definitive Versionable Reviewable Shareable Gareth Rushgrove - - - -
21. Definitive Versionable Reviewable Shareable Gareth Rushgrove - - - -
22. Definitive Versionable Reviewable Shareable Gareth Rushgrove - - - -
23. Start With A Test Tests are about design as much as quality
24. Gareth Rushgrove 2010 vintage devops
25. Replace constant meetings interpreting policy with testable code Gareth Rushgrove
26. Replace occasionally accessed spreadsheets with constantly running programs Gareth Rushgrove
27. Unit testing tools exist for all languages Gareth Rushgrove
28. Examples Some ideas
29. Web applications Gareth Rushgrove
30. An example test for checking for SQL injection vulnerabilities Scenario: The application should not contain SQL injection vulnerabilities Meta: @id scan_sql_injection @cwe-89 Given a scanner with all policies disabled And the SQL-Injection policy is enabled And the attack strength is set to High And the alert threshold is set to Low When the scanner is run And the XML report is written to the file sql_injection.xml Then no Medium or higher risk vulnerabilities should be present
31. An example test for checking for XSS. Lots more build-in Scenario: The application should not contain XSS vulnerabilities Meta: @id scan_sql_injection @cwe-89 Given a scanner with all policies disabled And the Cross-Site-Scripting policy is enabled And the attack strength is set to High When the scanner is run Then no Medium or higher risk vulnerabilities should be present
32. Gareth Rushgrove continuumsecurity/bdd-security
33. Public facing ports Gareth Rushgrove
34. Discovered open port 22/tcp on 45.56.74.113 Completed Connect Scan at 07:09, 3.31s elapsed (12 total ports) Nmap scan report for www.puppetlabs.com (45.56.74.113) Host is up (0.082s latency). rDNS record for 45.56.74.113: li924-113.members.linode.com PORT STATE SERVICE 20/tcp filtered ftp-data 21/tcp filtered ftp 22/tcp open ssh 23/tcp filtered telnet 25/tcp filtered smtp 80/tcp open http 110/tcp filtered pop3 443/tcp open https 512/tcp filtered exec 522/tcp filtered ulp 1080/tcp filtered socks 8080/tcp open http-proxy Standard nmap output requires manual analysis
35. it 'has only a limited number of open ports' do expect(@open_ports.count).to eq(3) end it 'exposes a web server' do expect(@open_ports).to include('80/tcp') expect(@open_ports).to include('443/tcp') end it 'exposes an SSH server' do expect(@open_ports).to include('22/tcp') end it 'rejects email traffic' do expect(@closed_ports).to include('25/tcp') end Using a unit testing framework we can make explicit assertions
36. www.puppetlabs.com from 192.168.1.10 has only a limited number of open ports (FAILED - 3) exposes a web server exposes an SSH server rejects accept email traffic (FAILED - 4) Anyone can run the tests and understand what is expected and what is currently broken
37. CMDB assertions Gareth Rushgrove
38. (expect installed-on-all-clients? "auditd") A one line test to check auditd is installed everywhere
39. (expect (every? ubuntu? (facts "operatingsystem"))) A one line test to check all machines are using the permitted Operating System
40. (expect latest-on-all-clients? "openssh") A one line test to check we’re running the latest version of Open SSH everywhere
41. (expect running-on-all-clients? "selinux") Because people seem to like to disable SELinux
42. Test your OPSEC Gareth Rushgrove
43. Gareth Rushgrove Checked in AWS keys
44. Gareth Rushgrove Personal .bash_profile
45. Gareth Rushgrove GitRob
46. Conclusion Remember one thing
47. Next time you have a security issue, write a test Gareth Rushgrove
48. Share the test with developers and operators when talking about the issue Gareth Rushgrove
49. After the issue is resolved find a way of keeping the test running all the time Gareth Rushgrove
50. Security policy as code Gareth Rushgrove
51. Questions? And thanks for listening