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

Compliance And Security Testing

Compliance And Security Testing

You have written your next application using the latest frameworks, technologies and deployed it on your favourite cloud provider. The sky is the limit and with full confidence you put your application into production. After some time you see unexpected behaviour and even security breaches. How can this happen?? You are using Spring, Java, Groovy, Docker and are a heck of a programmer. It could not be your fault or is it?

This talk will make you, as a developer, aware of your liability and duty of care on the applications and infrastructure that you create. It will introduce you to tools that enable you to quickly identify possible compliance and security issues.

- Cloud infrastructure best practice and compliance scanning
- Docker container security and compliance testing
- Application analyses (code quality, dependency management, license overviews)
- How to integrate application analyses, cloud infrastructure scanning and container security in your DevOps pipeline

Marco Pas

May 28, 2019
Tweet

More Decks by Marco Pas

Other Decks in Programming

Transcript

  1. About Me • Marco Pas • Happy Coder/Software Architect/ DevOps

    Engineer • Prototype / First of a kind development • Doing fun and interesting stuff • @ Philips Research
  2. Research Areas • Consumer products • HealthCare Some innovations •

    Medical X-ray tube • Mixed Tapes / CD / DVD • Ambilight TV • Airfloss
  3. Our profession • Developers • Product Managers • Agilists •

    Testers • Architects • Managers • ...
  4. Sometimes we make mistakes int getRandomize(int randMax) { srand (

    time(NULL) ); int randNum; = rand() % randMax + 1; return 2; /* :) */ }
  5. We also like to write stories // When I wrote

    this, only God and I understood what I was doing // Now, God only knows -------------------------------------------------------------------------------- // Happy debugging suckers -------------------------------------------------------------------------------- // Drunk, fix later -------------------------------------------------------------------------------- // This code sucks, you know it and I know it.
  6. Liability in negligence Duty of care • Detailed testing of

    the software before commercial release • Appropriate use of automated testing and code quality tools • Notifying customers who have been potentially affected by a defect in the software
  7. The Programmer's Oath1 We need to regulate ourselves or others

    will • I will, not produce harmful code. • I will, not knowingly allow code that is defective either in behavior or structure to accumulate. • I will, fearlessly and relentlessly improve my creations at every opportunity. 1 The Programmer's Oath - https://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html
  8. Compliance & Security Testing Validate, weather the system developed meets

    the organization’s prescribed standards or not. Automate!
  9. Application Code • Coding Standards • Quality Attributes • Bugs,

    Code Smells, Coverage, Duplication • Security Issues • Predictive Analytics and social patterns
  10. SonarQube2 • Continuous Inspection • Issue detection • Multi-language •

    Centralized: • Coding Standards • Quality Attributes 2 SonarQube - https://www.sonarqube.org/
  11. Include SonarQube + Test Coverage // file: build.gradle plugins {

    ... id "org.sonarqube" version "2.7.1" id "jacoco" } sonarqube { properties { property "sonar.coverage.jacoco.xmlReportPaths", "$buildDir/reports/jacoco/test/jacocoTestReport.xml" property "sonar.coverage.exclusions", ["**/Application.java"] } } jacocoTestReport { reports { xml.enabled true } }
  12. Application Code • ✅ Coding Standards • ✅ Quality Attributes

    • Bugs, Code Smells, Coverage, Duplication • ✅ Security Issues • Predictive Analytics and social patterns
  13. Every commit leaves a trace • Which part of the

    code might become bottlenecks? • Which parts of the code will be hard to maintain? • What is the technical risk when a developer leaves the project? • Which parts of the code should we improve to get a real productivity and quality gain? • How is the knowledge distribution between teams in your codebase?
  14. Application Code • ✅ Coding Standards • ✅ Quality Attributes

    • Bugs, Code Smells, Coverage, Duplication • ✅ Security Issues • ✅ Predictive Analytics and social patterns
  15. import com.github.jk1.license.render.* plugins { ... id 'org.owasp.dependencycheck' version '5.0.0-M3.1' id

    'com.github.jk1.dependency-license-report' version '1.6' } licenseReport { renderers = [new InventoryHtmlReportRenderer()] }
  16. Containers • Correctly build? • Trusted and safe? • Does

    not expose and strange ports? • Contains the correct application and settings? How do we test and verify?
  17. Docker Build File FROM openjdk:11-jdk-slim RUN mkdir -p /app COPY

    *.jar /app/application.jar WORKDIR /app ENTRYPOINT ["java","-Dmicronaut.server.port=8020", "-jar","application.jar"] Image ➡ Container
  18. Goss4 • YAML based serverspec alternative for validating a server’s

    configuration • Writing tests by allowing the user to generate tests from the current system state • Test suite can be executed, waited- on, or served as a health endpoint • Runs on the target!! 4 Goss - Quick and Easy server testing/validation - https://github.com/ aelsabbahy/goss
  19. Creating/Running tests // create/edit tests $ dgoss edit <container-name> INFO:

    Run goss add/autoadd to add resources # goss add http http://localhost:8020/helloworld/ # exit INFO: Copied '/goss/goss.yaml' from container to '.' // run test $ dgoss run <container-name>
  20. Creating/Running tests // create/edit tests $ dgoss edit <container-name> INFO:

    Run goss add/autoadd to add resources # goss add http http://localhost:8020/helloworld/ # exit INFO: Copied '/goss/goss.yaml' from container to '.' // run test $ dgoss run <container-name>
  21. Creating/Running tests // create/edit tests $ dgoss edit <container-name> INFO:

    Run goss add/autoadd to add resources # goss add http http://localhost:8020/helloworld/ # exit INFO: Copied '/goss/goss.yaml' from container to '.' // run test $ dgoss run <container-name>
  22. Inspec - compliance as code InSpec is an open-source testing

    framework for infrastructure with a human-readable language for specifying compliance, security and other policy requirements.
  23. Why Inspec • It's open source • Development supported by

    Chef Software Inc. • Awesome community (Slack) • Resourch rich!! • Can run anywhere (local machine, over ssh, docker, winrm) • Written in Ruby
  24. Questions and answers InSpec provides an incredibly easy way to

    answer questions such as: • Is package “myapp” installed, “myservice” running? • Is the SSH server configured to only accept protocol version 2? • Is the “maxallowedpacket” setting in the “mysql” section of “/etc/my.cnf” set to “16M”?
  25. Simple test(s) describe file('/etc/myapp.conf') do it { should exist }

    its ('mode') { should cmp '0644' } end describe package('nginx') do it { should be_installed } end describe port.where { protocol =~ /tcp/ && port > 22 && port < 80 } do it { should_not be_listening } end
  26. Targets # Login to remote machine using ssh as root

    $ inspec shell -t ssh://[email protected]:11022 # Login to hostname on port 1234 as user using given ssh key $ inspec shell -t ssh://user@hostname:1234 -i /path/to/user_key # Login to windowsmachine over WinRM as UserName $ inspec shell -t winrm://UserName:Password@windowsmachine:1234 # Login to a Docker container $ inspec shell -t docker://container_id When no target then local is assumed!
  27. Docker resource examples describe docker_image('alpine:latest') do it { should exist

    } its('id') { should eq 'sha256:4a415e...a526' } its('repo') { should eq 'alpine' } its('tag') { should eq 'latest' } end describe docker.images do its('repositories') { should_not include 'insecure_repository' } end describe docker.containers do its('images') { should_not include 'this-image-should-not-be-used-anymore:latest' } end
  28. Docker resource examples describe docker_image('alpine:latest') do it { should exist

    } its('id') { should eq 'sha256:4a415e...a526' } its('repo') { should eq 'alpine' } its('tag') { should eq 'latest' } end describe docker.images do its('repositories') { should_not include 'insecure_repository' } end describe docker.containers do its('images') { should_not include 'this-image-should-not-be-used-anymore:latest' } end
  29. Docker resource examples describe docker_image('alpine:latest') do it { should exist

    } its('id') { should eq 'sha256:4a415e...a526' } its('repo') { should eq 'alpine' } its('tag') { should eq 'latest' } end describe docker.images do its('repositories') { should_not include 'insecure_repository' } end describe docker.containers do its('images') { should_not include 'this-image-should-not-be-used-anymore:latest' } end
  30. Inspec Profiles6 Describe best configuration practices for specific services •

    SSH • Linux • Docker • Postgress • ... 6 DevSec.io - https://dev-sec.io
  31. Inspec Controls container_name = attribute('container_name', description: 'Name of the container

    to be tested.', default: 'Please specify with ATTRIBUTES FLAG --attrs') control "001-container-should-be-running" do impact 1.0 title "Container should be running." desc "The container should be running." describe docker_container(container_name) do it { should exist } it { should be_running } end end
  32. Vulnerability Static Analysis for Containers7 • Open Source • Scan

    layers in images • Whitelist support • Easy integration into CI/CD pipelines 7 Clair Container Scan - https://github.com/coreos/clair
  33. Whitelist support generalwhitelist: #Approve CVE for any image CVE-2017-6055: XML

    CVE-2017-5586: OpenText images: ubuntu: #Apprive CVE only for ubuntu image, regardles of the version CVE-2017-5230: Java CVE-2017-5230: XSX alpine: CVE-2017-3261: SE
  34. Scout Suite • Open Source • Stable and actively maintained

    • Multi-cloud • Amazon Web Services • Microsoft Azure • Google Cloud Platform • Python
  35. Compliance notes • does not require AWS/Azure/GCO users, to complete

    and submit the AWS Vulnerability / Penetration Testing or contact Microsoft/Google to begin testing But please read the Acceptable Use Policy and the Terms of Service
  36. Why do quality tools often fail • Resistance • There

    is other important work to do • The tools are to slow • They dont work correctly • Coding standards just suck • Management is trying to execute a blame game • Nasty corner cases
  37. Conclusion Be aware that software is everywhere! You influence peoples

    lives! So do your utmost best to make them secure and "bug" free. Invest in code analysis, etc.. Take your duty seriously!!
  38. Thank you! All sources for the presentation can be found

    at: • https://github.com/mpas/compliance-and-security-testing