$30 off During Our Annual Pro Sale. View Details »

Checking and rechecking - security policy in code

Checking and rechecking - security policy in code

Short talk from CyberUK in Practice

Gareth Rushgrove

May 25, 2016
Tweet

More Decks by Gareth Rushgrove

Other Decks in Technology

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