Maintaining control by letting go - security and devops

Talk at Infosecurity Europe all about the intersection of security and devops, focusing on the continuous delivery pipeline as an opportunity for conversation and automated security testing.

Transcript

1. Maintaining control by letting go Puppet Labs Gareth Rushgrove Security in a devops world
2. @garethr
3. Gareth Rushgrove
4. Introduction
5. We can build more secure systems, not just react to problems better Gareth Rushgrove
6. Shadow IT Gareth Rushgrove Security VS
7. Self-service Gareth Rushgrove Security VS
8. VS Rapid software development Gareth Rushgrove Security
9. VS Rapid software deployment Gareth Rushgrove Security
10. VS New tools and technologies Gareth Rushgrove Security
11. Security as a solitary gatekeeper for all changes to production doesn’t scale Gareth Rushgrove
12. Automation can help scale security expertise Gareth Rushgrove
13. Automation is also the perfect middle-ground to build better relationships between security, development and operations Gareth Rushgrove
14. This talk
15. The importance of shared tools to collaboration Gareth Rushgrove
16. Examples of applying infrastructure as code, and other software practices to security problems Gareth Rushgrove
17. What the security community can learn from the successes of Devops Gareth Rushgrove
18. WARNING This talk will feature code but is not about software development Gareth Rushgrove
19. Sharing tools and practices Bringing developers, operations and security together
20. Why share? - Common language between teams - Builds trust amongst team members - Avoid duplication of effort and data - Limits the number of systems Gareth Rushgrove
21. Example: Infrastructure as Code Gareth Rushgrove
22. Gareth Rushgrove The architecture docs Your mental model Reality The developers mental model = = = =
23. Gareth Rushgrove The architecture docs Your mental model Reality The developers mental model = = = =
24. Gareth Rushgrove
25. Gareth Rushgrove Puppet code Reality =
26. An unambiguous description of your infrastructure, stored in version control Gareth Rushgrove
27. Puppet is a domain specific language, designed to describe your infrastructure configuration
28. Gareth Rushgrove From files up to higher level constructs like applications running in IIS
29. And from host level resources to remote resources like DNS records or AWS Autoscaling Groups
30. Machines check they match the model every half an hour, and automatically remediate and report any differences Gareth Rushgrove
31. Gareth Rushgrove You can see what is changing across your infrastructure, all from the Puppet Enterprise Console
32. Shared resource between operations and development Gareth Rushgrove
33. Shared resource between operations, development, security and anyone with a stake in the infrastructure Gareth Rushgrove
34. “The constant discussion between software and infrastructure teams really helps us proactively find issues before deploying to production.”
35. All of the configuration information ends up in PuppetDB. How might that be of interest to a security team? Gareth Rushgrove
36. (The framework for this is about 20 lines of code and could be written by any good developer in an hour) Gareth Rushgrove
37. (expect installed-on-all-clients? "auditd") A one line test to check auditd is installed everywhere
38. (expect running-on-all-clients? "selinux") Because people seem to like to disable SELinux
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
41. Hook the tests into your operations teams monitoring system and security can get alerts when tests fail Gareth Rushgrove
42. Combine existing operations data with developers willingness to write code and the security teams knowledge of potential threats Gareth Rushgrove
43. Embrace pipelines Security testing in continuous delivery pipelines
44. Gareth Rushgrove
45. “We went from all-hands-on- deck, war-room sort of deployments to non-events” Gareth Rushgrove Jez Miller, Heartland Payment Systems, Puppet Enterprise Customer
46. Gareth Rushgrove Regular releases reduce risk
47. As applicable to changes to web applications as infrastructure, end user devices, network hardware and more Gareth Rushgrove
48. Gareth Rushgrove Login to a computer Make change
49. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Deploy
50. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Deploy Deploy to staging Preflight checks
51. Gareth Rushgrove Write the code Check syntax Check style Unit tests Acceptance tests Deploy Security tests
52. Automate where possible, so manual effort is focused on high risk work Gareth Rushgrove
53. Gareth Rushgrove Acceptance tests Deploy Security tests Manual review by security Automated security tests Automated security tests Is this a high risk change?
54. What is a high risk change? - Change to firewall policy? - Change to authentication code? - Change to SSH configuration? - New user added? Gareth Rushgrove
55. The important thing is the discussion with colleagues in development and operations Gareth Rushgrove
56. Turn security practices into standard processes Gareth Rushgrove
57. Turn standard processes into automated steps Gareth Rushgrove
58. Unit tests for security concerns Applying development practices to security
59. Once you know about the pipeline, you can add steps related to security Gareth Rushgrove
60. Ensure security policy is implemented in practice Gareth Rushgrove
61. Catch security problems before they hit production Gareth Rushgrove
62. Replace occasionally accessed spreadsheets with constantly running code Gareth Rushgrove
63. Useful in different contexts: - Production monitoring system - Tests in development - Smoke tests for deployment Gareth Rushgrove
64. Test your network Because everyone likes an open port Gareth Rushgrove
65. Gareth Rushgrove
66. 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
67. Gareth Rushgrove Security tests Run network security tests
68. 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
69. 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
70. Test your supply chain Checking packages for vulnerabilities Gareth Rushgrove
71. Old versions of third libraries might have known vulnerabilities Gareth Rushgrove
72. Gareth Rushgrove rubysec/bundler-audit
73. Gareth Rushgrove Security tests Run network security tests Check for vulnerable packages
74. source "https://rubygems.org" gem "bundler-audit" gem "rake" gem "pry" group :vulnerable do gem "actionpack", "=3.2.10" end An example Gemfile, a list of ruby packages used in an application or environment, with a vulnerable package
75. Name: actionpack Version: 3.2.10 Advisory: OSVDB-103440 Name: actionpack Version: 3.2.10 Advisory: OSVDB-89026 Criticality: High URL: http://osvdb.org/show/osvdb/89026 Description: Ruby on Rails contains a flaw in params_parser.rb of the Action Pack. The issue is triggered when a type casting error occurs during the parsing of parameters. This may allow a remote attacker to potentially execute arbitrary code. Solution: upgrade to ~> 2.3.15, ~> 3.0.19, ~> 3.1.10, >= 3.2.11 An example report from bunder-audit
76. Test your web applications Checking for XSS, SQLi and more Gareth Rushgrove
77. Gareth Rushgrove continuumsecurity/bdd-security
78. 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
79. 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
80. Test what you deploy, not just what you write Gareth Rushgrove
81. Gareth Rushgrove Security tests Run network security tests Check for vulnerable packages Run web application security tests
82. Gareth Rushgrove Security tests Run network security tests Check for vulnerable packages Run web application security tests Static analysis Metrics analysis SSL config
83. These are just quick examples. The point is automated testing and security go together incredibly well Gareth Rushgrove
84. And embracing the pipeline means you can add small steps easily Gareth Rushgrove
85. Conclusions
86. Focus efforts on the mechanism for change, over individual changes Gareth Rushgrove
87. Focus on steps in the pipeline. No single tool will fix all problems Gareth Rushgrove
88. Favour tools (open source, in-house or commercial) with APIs that can be integrated into a pipeline Gareth Rushgrove
89. Developers have never been more interested in security, use that Gareth Rushgrove
90. Adding steps into a continuous delivery pipeline is the perfect opportunity for a conversation Gareth Rushgrove
91. Доверяй, но проверяй
92. Questions? And thanks for listening