Compliance And Security Testing

Slide 1

Slide 1 text

Are you aware? Aware of your liability as a software engineer !

Slide 2

Slide 2 text

About Me • Marco Pas • Happy Coder/Software Architect/ DevOps Engineer • Prototype / First of a kind development • Doing fun and interesting stuff • @ Philips Research

Slide 3

Slide 3 text

Research Areas • Consumer products • HealthCare Some innovations • Medical X-ray tube • Mixed Tapes / CD / DVD • Ambilight TV • Airﬂoss

Slide 4

Slide 4 text

Lets start with an essential question! What are we?

Slide 5

Slide 5 text

Professionals

Slide 6

Slide 6 text

Our profession • Developers • Product Managers • Agilists • Testers • Architects • Managers • ...

Slide 7

Slide 7 text

We are all proud of the things we create

Slide 8

Slide 8 text

We as software engineers are awesome ...

Slide 9

Slide 9 text

We have fun Exception up = new Exception("Something is really wrong."); throw up;

Slide 10

Slide 10 text

Sometime we are ignorant catch (Exception e) { //who cares? }

Slide 11

Slide 11 text

Sometimes we make mistakes int getRandomize(int randMax) { srand ( time(NULL) ); int randNum; = rand() % randMax + 1; return 2; /* :) */ }

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

But are you also aware of the consequences

Slide 14

Slide 14 text

Software is everywhere and is a challenge/problem Lets look at some recent challenges ->

Slide 15

Slide 15 text

Stalled motor Lack of oxygen Philips Respironics

Slide 16

Slide 16 text

Delayed or overdosed medicine Product recall CareFusion

Slide 17

Slide 17 text

Software bug assists Bank Heist $81 million Bangladesh Bank

Slide 18

Slide 18 text

Killing 8500 Patients "On Paper" St. Mary’s Mercy Medical Center

Slide 19

Slide 19 text

Releasing 3200 prisoners too early Michigan Dept. of Corrections

Slide 20

Slide 20 text

Network going down 30 million users affected O2

Slide 21

Slide 21 text

Revealing affairs Pushing notiﬁcations Uber

Slide 22

Slide 22 text

Missile strike State wide alarm Hawaii

Slide 23

Slide 23 text

Car emission if (test) then lower emission Volkswagen

Slide 24

Slide 24 text

Money laundering possible after 10 warnings ING Banking

Slide 25

Slide 25 text

How does this effect us?

Slide 26

Slide 26 text

Law/regulation is coming! We are are becoming liable for the work that we do!

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Hygiene

Slide 30

Slide 30 text

How to deploy and enforce hygiene?

Slide 31

Slide 31 text

Compliance & Security Testing Validate, weather the system developed meets the organization’s prescribed standards or not. Automate!

Slide 32

Slide 32 text

Hygiene levels Application Code Used Libraries / Dependencies Containers Deployment

Slide 33

Slide 33 text

Application Code • Coding Standards • Quality Attributes • Bugs, Code Smells, Coverage, Duplication • Security Issues • Predictive Analytics and social patterns

Slide 34

Slide 34 text

SonarQube2 • Continuous Inspection • Issue detection • Multi-language • Centralized: • Coding Standards • Quality Attributes 2 SonarQube - https://www.sonarqube.org/

Slide 35

Slide 35 text

SonarQube Overview

Slide 36

Slide 36 text

Bad Ex.

Slide 37

Slide 37 text

Pull Request Feedback

Slide 38

Slide 38 text

Quality Gates

Slide 39

Slide 39 text

Deﬁne your own quality gates to ensure compliance

Slide 40

Slide 40 text

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 } }

Slide 41

Slide 41 text

Demo SonarQube

Slide 42

Slide 42 text

Application Code • ✅ Coding Standards • ✅ Quality Attributes • Bugs, Code Smells, Coverage, Duplication • ✅ Security Issues • Predictive Analytics and social patterns

Slide 43

Slide 43 text

Predictive Analysis 3 3 CodeScene - https://codescene.io/

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

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?

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Hotspots

Slide 49

Slide 49 text

Knowledge distribution

Slide 50

Slide 50 text

Demo CodeScene

Slide 51

Slide 51 text

Application Code • ✅ Coding Standards • ✅ Quality Attributes • Bugs, Code Smells, Coverage, Duplication • ✅ Security Issues • ✅ Predictive Analytics and social patterns

Slide 52

Slide 52 text

Hygiene levels Application Code Used Libraries / Dependencies Containers Deployment

Slide 53

Slide 53 text

Used Libraries / Dependencies • License Management • Security Incidents (CVE)

Slide 54

Slide 54 text

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()] }

Slide 55

Slide 55 text

Demo License Management / Security Incidents

Slide 56

Slide 56 text

Used Libraries / Dependencies • ✅ License Management • ✅ Security Incidents (CVE)

Slide 57

Slide 57 text

Hygiene levels Application Code Used Libraries / Dependencies Containers Deployment

Slide 58

Slide 58 text

Containers • Correctly build? • Trusted and safe? • Does not expose and strange ports? • Contains the correct application and settings? How do we test and verify?

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

Goss4 • YAML based serverspec alternative for validating a server’s conﬁguration • 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

Slide 61

Slide 61 text

Goss Overview

Slide 62

Slide 62 text

Simple test! // file: goss.yaml http: http://localhost:8020/helloworld/: status: 200

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Creating/Running tests // create/edit tests $ dgoss edit 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

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Demo Goss

Slide 69

Slide 69 text

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.

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Questions and answers InSpec provides an incredibly easy way to answer questions such as: • Is package “myapp” installed, “myservice” running? • Is the SSH server conﬁgured to only accept protocol version 2? • Is the “maxallowedpacket” setting in the “mysql” section of “/etc/my.cnf” set to “16M”?

Slide 72

Slide 72 text

Demo Inspec Shell

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

Inspec Resources • Operating System • Amazon WebServices • Azure • Google Cloud

Slide 75

Slide 75 text

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!

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Inspec Profiles6 Describe best configuration practices for specific services • SSH • Linux • Docker • Postgress • ... 6 DevSec.io - https://dev-sec.io

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

Demo Inspec

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

Clair Overview

Slide 84

Slide 84 text

CVE Data Sources

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

Demo Clair

Slide 87

Slide 87 text

Hygiene Levels Application Code Used Libraries / Dependencies Containers Deployment

Slide 88

Slide 88 text

Deployment • Multicloud • Best practices per vendor • Auditing

Slide 89

Slide 89 text

Scout Suite • Open Source • Stable and actively maintained • Multi-cloud • Amazon Web Services • Microsoft Azure • Google Cloud Platform • Python

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

Demo ScoutSuite

Slide 92

Slide 92 text

The human factor

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

Conclusion Be aware that software is everywhere! You inﬂuence peoples lives! So do your utmost best to make them secure and "bug" free. Invest in code analysis, etc.. Take your duty seriously!!

Slide 95

Slide 95 text

Q & A

Slide 96

Slide 96 text

Thank you! All sources for the presentation can be found at: • https://github.com/mpas/compliance-and-security-testing