Building Rugged Software in a DevOps World

Slide 1

Slide 1 text

Building Rugged Software in a DevOps World Matt Konda @mkonda

Slide 2

Slide 2 text

OWASP?

Slide 3

Slide 3 text

Introduction 1997 2006 2014 Consultant Engineer Software Architect Director of Engineering Rabble Rouser: Perl Java Applet C++ J2EE J2EE  Spring Analytics Certiﬁcate Authority Vulnerability Scanner Penetration Test Manager Pricing Retail Banking Manufacturing Pharma Healthcare Research Ruby Rails Chicago BSides 2011, 2012 Defcon Skytalk OWASP Chicago, MSP 2013 AppSec USA 2012, 2013 ChicagoRuby 2013 Secure 360 Lone Star Ruby 2013 WindyCityRails 2013 Chicago JUG 2014 RailsConf 2014 Converge 2014 Chicago Coder Conference 2015 MS in CS Founder Consultant Agile Clojure Graph Database Trying to hack a business model that succeeds while helping developers. Domains: Projects: DevOps / Automation Training Coaching Code Review Plugged in to SDLC Consulting Assessments @mkonda [email protected] DevOps Growing

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

Rugged

Slide 6

Slide 6 text

Reminiscent of the Agile Manifesto Perhaps?

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

This was a setup. Chicago style.

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

But in Chicago, we make the best of every situation.

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

I recognize that software has become a foundation of our modern world. I recognize the awesome responsibility that comes with this foundational role. I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended. I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic and national security. I recognize these things – and I choose to be rugged.

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Threat model

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

DevOps / Continuous Delivery

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

What does a delivery pipeline really look like?

Slide 24

Slide 24 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 28

Slide 28 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 29

Slide 29 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 30

Slide 30 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 31

Slide 31 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

Database What does a delivery pipeline really look like? AppServ1 AppServ2 AppServN WebServ1 WebServ2 WebServ3 LB1 LB2

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

continuous delivery

Slide 36

Slide 36 text

Running Pipeline from Docker 1. docker-machine create --driver virtualbox default 2. eval $(docker-machine env default) 3. docker pull owasp/pipeline:0.8.7 4. docker run —rm owasp/pipeline:0.8.7 -h 5. docker run —rm owasp/pipeline:0.8.7 -t brakeman https://github.com/Jemurai/ triage.git

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

Some Speciﬁcs Around Process

Slide 39

Slide 39 text

Security in the SDLC • Building software is a process. • The best way to make software secure is to make security part of the process. • There are many ways to do this - none is perfect. • Find a way to make the security ﬁt your process.

Slide 40

Slide 40 text

Requirements Design Code Test Maintenance Classic Waterfall Delivery

Slide 41

Slide 41 text

Requirements Design Code Test Maintenance Classic Waterfall Delivery Security

Slide 42

Slide 42 text

Story Continuous Delivery: The Unit of Work is a Story Requirements Design Code Test

Slide 43

Slide 43 text

Story Continuous Delivery: The Unit of Work is a Story Requirements Design Code Test Security Requirements Security Unit Tests Exploratory Testing Static Analysis on Commit Code Review Threat model / attack surface Checklists Understand Dependencies

Slide 44

Slide 44 text

continuous delivery

Slide 45

Slide 45 text

Classic security sees this and wants to …

Slide 46

Slide 46 text

continuous delivery

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

Think incremental

Slide 49

Slide 49 text

Fully clean start each time

Slide 50

Slide 50 text

Being able to deploy quickly is my #1 security feature. - Nick Galbreath

Slide 51

Slide 51 text

Automate security tools

Slide 52

Slide 52 text

continuous delivery Security Tool Automation: Code analysis Security unit tests Dynamic scanning etc.

Slide 53

Slide 53 text

continuous delivery Security Tests Run Exploratory Testing Includes Security

Slide 54

Slide 54 text

Integrations

Slide 55

Slide 55 text

pre-commit

Slide 56

Slide 56 text

Running Pipeline on a Git Hook 1. Copy /hooks/pre-commit to your project in /.git/hooks 2. chmod +x pre-commit 3. Edit pre-commit to reflect your path and tools 4. Regular process: 1. Change a 2. git add 3. git commit -m “Testing”

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

chat ops

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

Jenkins

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

Recap of “Tasks” • File: AV, FIM • Code: • Ruby/Rails: brakeman, bundler-audit • JavaScript: NodeSecurityProject, eslint, retire.js • Java: owasp-dependency-check • Checkmarx • Live: ZAP

Slide 73

Slide 73 text

Continuous Integration

Slide 74

Slide 74 text

No content

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

Checklists

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

No content

Slide 82

Slide 82 text

Let’s talk about adversaries…

Slide 83

Slide 83 text

No content

Slide 84

Slide 84 text

This year, organized crime became the most frequently seen threat actor for Web App Attacks. Source: Verizon 2015 Data Breach Investigations Report

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

Testing

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

continuous delivery Since its easy to provision we can do security testing safely in a new env.

Slide 91

Slide 91 text

Audit tools

Slide 92

Slide 92 text

continuous delivery Deployment checks includes security audit checks.

Slide 93

Slide 93 text

Self documenting for regulatory and compliance!

Slide 94

Slide 94 text

Chaos tools

Slide 95

Slide 95 text

Change is good

Slide 96

Slide 96 text

continuous delivery Change is happening. It can be an opportunity instead of a hassle.

Slide 97

Slide 97 text

Complexity is an enemy

Slide 98

Slide 98 text

continuous delivery Small releases reduce complexity. Decomposition to micro-services reduces dependencies and complexity. Right now, security hurts.

Slide 99

Slide 99 text

Shared responsibility

Slide 100

Slide 100 text

continuous delivery Another principle of software delivery: build security in! Done means secure! Empowered to do security right!

Slide 101

Slide 101 text

Event based model … (Reactive)

Slide 102

Slide 102 text

Commit • Security Unit Tests • Static Code Analysis (Pipeline) • Security Requirements • Check Dependencies • Code Review • Checklists

Slide 103

Slide 103 text

Deploy • Scripted Provisioning / Built in Change Control • Provisioning Auditing (Chef Audit, hardening.io) • Gauntlt

Slide 104

Slide 104 text

Periodic • Full app analysis (static, manual pen test) • Secure Development Training • Baseline Security Requirements Review • ASVS Review • Data Science on Results

Slide 105

Slide 105 text

No content

Slide 106

Slide 106 text

Security Incident

Slide 107

Slide 107 text

So how do tests make our code rugged?

Slide 108

Slide 108 text

Demo cucumber --name "person is restricted from putting input into a field that will be executed by the system"

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

Root cause def destroy @project = Project.find(params[:id]) name = @project.name `rm /tmp/#{name}.log` @project.destroy respond_to do |format| format.html { redirect_to projects_url } format.json { head :no_content } end end What if @project.name is : "; cat /etc/passwd > public/passwd.html;”

Slide 111

Slide 111 text

How many people here Write tests?

Slide 112

Slide 112 text

How many people here Use TDD?

Slide 113

Slide 113 text

How many people here Use BDD?

Slide 114

Slide 114 text

How many people here currently write security tests?

Slide 115

Slide 115 text

rspec

Slide 116

Slide 116 text

No content

Slide 117

Slide 117 text

No content

Slide 118

Slide 118 text

Feature Scenario Given When Then

Slide 119

Slide 119 text

Feature: person is restricted from accessing project they do not own Scenario: person accesses a project that is not theirs Given a new project created by a user When a different person attempts to access the project Then the system should prevent access

Slide 120

Slide 120 text

Demo cucumber --name "person is restricted from accessing project they do not own"

Slide 121

Slide 121 text

No content

Slide 122

Slide 122 text

Given(/^a new project created by a user$/) do uuid = SecureRandom.uuid @user1 = "fb_user_1_#{uuid}@jemurai.com" register_as_user(@user1, "password") new_project("Insecure Direct Object Reference #{uuid}", "Forceful Browsing Desc") @url = current_url end When(/^a different person attempts to access the project$/) do logout(@user1) uuid = SecureRandom.uuid @user2 = "fb_user_2_#{uuid}@jemurai.com" register_as_user(@user2, "password") end Then(/^the system should prevent access$/) do visit @url expect(page).not_to have_content "Forceful Browsing Desc" end

Slide 123

Slide 123 text

Handy http://localhost:3000/projects?name=%27A%27%29%20or%201=1%20-- def index email = current_user.email conditions = "owner LIKE '#{email}'" if params[:name] conditions = "name like #{params[:name]} " + conditions end @projects = Project.find(:all, :conditions=>conditions) respond_to do |format| format.html # index.html.erb format.json { render json: @projects } end end SELECT "projects".* FROM "projects" WHERE (name like 'A') or 1=1 -- owner LIKE '[email protected]') For illustration

Slide 124

Slide 124 text

No content

Slide 125

Slide 125 text

Slide 126

Slide 126 text

new_project("XSS Name #{@field} #{uniq}","XSS Desc #{@field}"+ uniq) click_link 'Edit' fill_in @field, :with => @value click_button "Update Project" if @result == "xss" # This should have xss in it...did it stick? alerted = false begin page.driver.browser.switch_to.alert.accept alerted = true rescue end if alerted fail("XSS Used to create Popup in #{@field} with #{@value}") else puts "Good news, no xss where expected." end else expect(page).to have_content @value end

Slide 127

Slide 127 text

Demo cucumber --name "user is prevented from putting XSS in project form fields"

Slide 128

Slide 128 text

No content

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

Tests in app Rails Application rspec / cucumber

Slide 131

Slide 131 text

Tests out of app Rails Application: Triage Cucumber | SWTF

Slide 132

Slide 132 text

Tests out of app Rails Application: Triage (Insecure) Cucumber | SWTF Rails Application: Triage (Secure)

Slide 133

Slide 133 text

This means they can be easily adapted to test different apps

Slide 134

Slide 134 text

Demo cucumber --name "user is protected from malicious content and having their page framed"

Slide 135

Slide 135 text

No content

Slide 136

Slide 136 text

Feature: user is protected from malicious content and having their page framed A user wants to be sure that effective browser protections are enabled in order to ensure that their information is safe. @javascript Scenario Outline: check for secure headers attempt Given a new project created by a user And the page is "" When the header is "" Then the header value should be "" Scenarios: headers in pages | page | header | result | | projects/ | X-Frame-Options | DENY | | projects/ | X-XSS-Protection | 1 |

Slide 137

Slide 137 text

cookies = Capybara.current_session.driver.browser.manage.all_cookies csrf_token = Capybara.current_session.driver.browser.find_element(:xpath, "//meta[@name='csrf-token']").attribute('content'); # Switch mode to net::http uri = URI.parse(url) http = Net::HTTP.new(uri.host, uri.port) http.verify_mode = OpenSSL::SSL::VERIFY_NONE request = Net::HTTP::Post.new(uri.request_uri) request['Cookie'] = cookies request.set_form_data( { "_method" => "put", "authenticity_token" => "#{csrf_token}", "project[name]"=> "header updated and verified", "commit"=>"Update Project" }) response = http.request(request) ... if response[@header] == @result #pass else fail("Header #{@header} not set to #{@result} as expected. Instead was #{response[@header]}.") end

Slide 138

Slide 138 text

Demo cucumber --name "users favorite album is in cookie"

Slide 139

Slide 139 text

No content

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

Simplified Steps • Injection: inject commands into fields and detect functions being called. • XSS: inject scripts into fields and detect that alerts are thrown • Mass assignment: set raw form data with net::http and send it to see how the server responds • CSRF: alter CSRF token and send otherwise valid request • Headers: interact with system and verify that headers are being set • Sensitive Data: open session cookie and inspect

Slide 142

Slide 142 text

accountability

Slide 143

Slide 143 text

culture

Slide 144

Slide 144 text

Security Examples

Slide 145

Slide 145 text

SELECT "orders".* FROM "orders" WHERE (rewards_code = 'a') union select id, 'product', 1, 1, 'cc', 'cvv', 'expiration', email as first_name, encrypted_password as last_name, created_at, updated_at, id, 'reward' from users; --')

Slide 146

Slide 146 text

Getting Rugged? Train. Search for string concatenation: +, append prefer parameterized queries! Do code review. Use static analysis. Use web app scanning.

Slide 147

Slide 147 text

Output Encoding < < > >

Slide 148

Slide 148 text

Getting Rugged? Train. Search for {{{, innerHTML, .raw, utext, etc. Do code review. Use static analysis. Use web app scanning.

Slide 149

Slide 149 text

Insecure Direct Object Reference Hani Joanne Salary Record Salary Record ? Authorization fail!

Slide 150

Slide 150 text

No content

Slide 151

Slide 151 text

No content

Slide 152

Slide 152 text

• https://speakerdeck.com/mkonda/security-automation-pipeline • https://speakerdeck.com/mkonda/security-from-inception-1 • https://speakerdeck.com/mkonda/real-world-security-testing