Top Banner
LONDON 2015 Join the conversation #devseccon An experiment in Agile Threat Modelling Fraser Scott
50

DevSecCon Talk: An experiment in agile Threat Modelling

Feb 10, 2017

Download

Technology

zeroXten
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: DevSecCon Talk: An experiment in agile Threat Modelling

LONDON 2015Join the conversation #devseccon

An experiment inAgile Threat Modelling

Fraser Scott

Page 2: DevSecCon Talk: An experiment in agile Threat Modelling
Page 3: DevSecCon Talk: An experiment in agile Threat Modelling

To err is human

Page 4: DevSecCon Talk: An experiment in agile Threat Modelling

To propagate error to all serverin automatic way is #devops

@DEVOPS_BORAT

Page 5: DevSecCon Talk: An experiment in agile Threat Modelling

Systematic identification of threats and actions

Page 6: DevSecCon Talk: An experiment in agile Threat Modelling

Build better and more robust systems and services

Page 7: DevSecCon Talk: An experiment in agile Threat Modelling

Threat Modeling: Designing for Security

Adam Shostack

Page 8: DevSecCon Talk: An experiment in agile Threat Modelling

Overview

1. What are you building?2. What can go wrong?3. What should you do about the things that can go wrong?

4. Did you do a good job of 1-3?

Page 9: DevSecCon Talk: An experiment in agile Threat Modelling

Whiteboard

Page 10: DevSecCon Talk: An experiment in agile Threat Modelling

Data Flow Diagram

Page 11: DevSecCon Talk: An experiment in agile Threat Modelling

Trust boundaries

Page 12: DevSecCon Talk: An experiment in agile Threat Modelling

Assets

Systems – access to data & pivoting Customer records (i.e. PII) Product data Credentials

Page 13: DevSecCon Talk: An experiment in agile Threat Modelling

Attackers

Script kiddies Hackivists Professional criminals ChinNation states

Page 14: DevSecCon Talk: An experiment in agile Threat Modelling

Software

The thing that actually delivers

value to your organisation

Page 15: DevSecCon Talk: An experiment in agile Threat Modelling

Elevation of Privilege

Page 16: DevSecCon Talk: An experiment in agile Threat Modelling

STRIDESpoofing identityTampering with dataRepudiationInformation disclosureDenial of serviceElevation of privilege

Page 17: DevSecCon Talk: An experiment in agile Threat Modelling

STRIDE EXAMPLESSquatting on a socket or port used by an

application

Altering pricing in a product database

Removing an attack from unauthenticated local

logs

Reading unencrypted network traffic

Running expensive queries

&admin=1

Page 18: DevSecCon Talk: An experiment in agile Threat Modelling

MitigateEliminateTransferAccept

ACTIONS

Page 19: DevSecCon Talk: An experiment in agile Threat Modelling

MeasurementValidationKeep up to

date

GOOD JOB?

Page 20: DevSecCon Talk: An experiment in agile Threat Modelling

Waterfall

Page 21: DevSecCon Talk: An experiment in agile Threat Modelling

Agile

Page 22: DevSecCon Talk: An experiment in agile Threat Modelling
Page 23: DevSecCon Talk: An experiment in agile Threat Modelling
Page 24: DevSecCon Talk: An experiment in agile Threat Modelling
Page 25: DevSecCon Talk: An experiment in agile Threat Modelling

Distributed developers

Convenient

Self documenting

Page 26: DevSecCon Talk: An experiment in agile Threat Modelling

R-SpecCucumber

BDD-SecurityGAUNTLT

Page 27: DevSecCon Talk: An experiment in agile Threat Modelling

R-Spec

# in spec/calculator_spec.rbRSpec.describe Calculator do describe '#add' do it 'returns the sum of its arguments' do expect(Calculator.new.add(1, 2)).to eq(3) end endend

Page 28: DevSecCon Talk: An experiment in agile Threat Modelling

Cucumber

Feature: Refund item Scenario: Jeff returns a faulty microwave Given Jeff has bought a microwave for $100 And he has a receipt When he returns the microwave Then Jeff should be refunded $10

Page 29: DevSecCon Talk: An experiment in agile Threat Modelling

BDD-Security

Scenario: Present the login form itself over an HTTPS connectionMeta: @id auth_login_form_over_ssl @cwe-295-auth @browser_onlyGiven a new browser instanceAnd the client/browser is configured to use an intercepting proxyAnd the proxy logs are clearedAnd the login pageAnd the HTTP request-response containing the login formThen the protocol should be HTTPS

Page 30: DevSecCon Talk: An experiment in agile Threat Modelling

GAUNTLT# nmap-simple.attackFeature: simple nmap attack to check for open ports

Background: Given "nmap" is installed And the following profile: | name | value | | hostname | example.com |

Scenario: Check standard web ports When I launch an "nmap" attack with: """ nmap -F <hostname> """ Then the output should match /80.tcp\s+open/ Then the output should not match: """ 25\/tcp\s+open """

Page 31: DevSecCon Talk: An experiment in agile Threat Modelling

Code-driven threat modelling

Page 32: DevSecCon Talk: An experiment in agile Threat Modelling

“ThreatSpec”

Page 33: DevSecCon Talk: An experiment in agile Threat Modelling

ComponentsTrust boundariesThreatsMitigationsOther stuff

Page 34: DevSecCon Talk: An experiment in agile Threat Modelling

Exposes WebApp:FileSystem to arbitrary file writes with insufficient path validation

Mitigates WebApp:FileSystem against unauthorised access with strict file permissions

Page 35: DevSecCon Talk: An experiment in agile Threat Modelling

\s*(?:\/\/|\#)\s*Mitigates (?<component>.+?) against (?<threat>.+?) with (?<mitigation>.+?)\s*(?:\((?<ref>.*?)\))?\s*$

Page 36: DevSecCon Talk: An experiment in agile Threat Modelling

// ThreatSpec TMv0.1 for ExpandKey// Mitigates App:Crypto against Use of Password Hash With Insufficient Computational Effort (CWE-916) with PBKDF2 provided by standard package// Mitigates App:Crypto against Use of a One-Way Hash without a Salt (CWE-759) with salt create by function// Mitigates App:Crypto against Use of a One-Way Hash with a Predictable Salt (CWE-760) with salt created with good PRNG

// ExpandKey is an opinionated helper function to cryptographically expand a key using a 128 bit salt and PBKDF2.// If the salt is of 0 length, it generates a new salt, and returns the expanded key and salt as byte arrays.//// A salt should only be provided as part of a decryption or verification process. When using ExpandKey to create a new key, let ExpandKey generate the salt. This is to lessen the risk of a weak or non-unique salt being used.func ExpandKey(key, salt []byte) ([]byte, []byte, error) { if len(salt) == 0 { var err error salt, err = RandomBytes(16) // TODO Shouldn't be hardcoded i guess if err != nil { return nil, nil, err } } newKey := pbkdf2.Key(key, salt, 100000, 32, sha256.New) return newKey, salt, nil}

Page 37: DevSecCon Talk: An experiment in agile Threat Modelling

ThreatSpec TMv0.1 for ExpandKey

Mitigates App:Crypto against Use of Password Hash With Insufficient Computational Effort (CWE-916) with PBKDF2 provided by standard package

Mitigates App:Crypto against Use of a One-Way Hash without a Salt (CWE-759) with salt create by function

Mitigates App:Crypto against Use of a One-Way Hash with a Predictable Salt (CWE-760) with salt created with good PRNG

Page 38: DevSecCon Talk: An experiment in agile Threat Modelling

# ThreatSpec Report for ...

# Analysis* Functions found: 2771* Functions covered: 4.11% (114)* Functions tested: 6.14% (7)

# Components## App Crypto### Threat: Use of Insufficiently Random Values (CWE-330)* Mitigation: standard package which uses secure implementation (github.com/pki-io/core:crypto:RandomBytes in ./_vendor/src/github.com/pki-io/core/crypto/helpers.go:74)

### Threat: Use of Password Hash With Insufficient Computational Effort (CWE-916)* Mitigation: PBKDF2 provided by standard package (github.com/pki-io/core:crypto:ExpandKey in ./_vendor/src/github.com/pki-io/core/crypto/helpers.go:123)

### Threat: Use of a One-Way Hash without a Salt (CWE-759)* Mitigation: salt create by function (github.com/pki-io/core:crypto:ExpandKey in ./_vendor/src/github.com/pki-io/core/crypto/helpers.go:123)

### Threat: Use of a One-Way Hash* Mitigation: a Predictable Salt (CWE-760) with salt created with good PRNG

Page 39: DevSecCon Talk: An experiment in agile Threat Modelling
Page 40: DevSecCon Talk: An experiment in agile Threat Modelling

$ callgraph *.go | ./threatspec.rb *.go

Page 41: DevSecCon Talk: An experiment in agile Threat Modelling
Page 42: DevSecCon Talk: An experiment in agile Threat Modelling
Page 43: DevSecCon Talk: An experiment in agile Threat Modelling

Workflow

Devs write ThreatSpec as they write new functions and tests

Review by security or senior devs

Review of generated reports and DFDs

Page 44: DevSecCon Talk: An experiment in agile Threat Modelling

Code-Driven

Page 45: DevSecCon Talk: An experiment in agile Threat Modelling

Problems?

Starting point – rough DFDComplexity of generated DFDExternal libraries etcDynamic call flows

Page 46: DevSecCon Talk: An experiment in agile Threat Modelling

The good stuff

Dev and Sec working together

Bigger picture

Model and code in sync

Page 47: DevSecCon Talk: An experiment in agile Threat Modelling

In conclusion...

Page 48: DevSecCon Talk: An experiment in agile Threat Modelling

Threat modelling is awesome

You should probably be doing it

Get people involved

Find an approach that works for you

Code-driven threat modelling may work

Page 49: DevSecCon Talk: An experiment in agile Threat Modelling

The future?

Improvements Ceremony

Infrastructure as code

Page 50: DevSecCon Talk: An experiment in agile Threat Modelling

LONDON 2015Join the conversation #devseccon

threatspec.org

Image credits available at http://threatspec.org/credits.html

Thank You