Checking and rechecking - security policy in code

Short talk from CyberUK in Practice

Transcript

1. (without introducing more risk) Checking and rechecking Puppet Gareth Rushgrove Turning security policy into code
2. (without introducing more risk) Gareth Rushgrove @garethr
3. (without introducing more risk) Gareth Rushgrove
4. (without introducing more risk) Security vs High Performance IT The problem in context
5. Shadow IT Gareth Rushgrove Security VS
6. Self-service Gareth Rushgrove Security VS
7. Rapid software development Gareth Rushgrove Security VS
8. VS Continuous deployment Gareth Rushgrove Security
9. VS New tools and technologies Gareth Rushgrove Security
10. (without introducing more risk) 30x Gareth Rushgrove More frequent deployments Faster lead times than their peers 200x 2015 State of DevOps Report
11. (without introducing more risk) 60x Gareth Rushgrove Change success rate Faster mean time to recover 168x 2015 State of DevOps Report
12. (without introducing more risk) Siloed teams Long cycle times Poor visibility Manual processes Gareth Rushgrove Cross-functional teams Short cycle times Fast feedback Automated processes
13. (without introducing more risk) Policy in code Applying software practices to security
14. Security policy is often just a stack of paper Gareth Rushgrove
15. Providing instruction without implementation is no longer enough Gareth Rushgrove
16. Gareth Rushgrove Your mental model Reality Engineers mental model = = = =
17. 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 Rather than saying “the firewall should be configured thusly”
18. (expect running-on-all-clients? "selinux") Rather than saying “you have to run SELinux”
19. (expect (every? redhat? (facts "operatingsystem"))) Rather than saying “you must be running the approved operating system”
20. def test_passwd_file(File): passwd = File("/etc/passwd") assert passwd.contains("root") assert passwd.user == "root" assert passwd.group == "root" assert passwd.mode == 0o644 Rather than saying “the passwd file should only be accessible by root”
21. package { 'openssh': ensure => latest } Rather than saying “we should have the latest version of openssh installed”
22. control 'os-04' do impact 1.0 title 'Dot in PATH variable' desc 'Do not include the current working directory in PATH variable. This makes it easier for an attacker to gain extensive rigths by executing a Trojan program' describe os_env('PATH') do its('split') { should_not include('') } its('split') { should_not include('.') } end end Rather than saying “PATH should not include the current directory”
23. Rather than saying “please don’t introduce 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
24. (without introducing more risk) Conclusions Things to consider during the panel
25. Describing policy in code can: - Reduce cost and time per release - Make testing repeatable - Make time for the things that can’t be automated Gareth Rushgrove
26. Embracing software means: - Closer collaboration between policy makers and practitioners - No arguments about semantics - Potential for sharing and reuse Gareth Rushgrove
27. Gareth Rushgrove Software is eating the world (of security)
28. (without introducing more risk) Thanks Happy to take questions later