Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Securing your Infrastructure - One unit test at a time

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

98234c645fe8c935edc0fec0186d28b8?s=128

Gareth Rushgrove

October 22, 2015
Tweet

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