Developer-First SecurityAndy Chou

CTO and Founder

Coverity

Copyright Coverity, Inc., 2013

2

Developer Priorities

Building featureson schedule

that delight users

that don’t crash or become unreliable

that perform well and scale up

that can be efficiently maintained

and don’t have security holes.

Security can be Complex

<a href="javascript:hello('${input}')"> HTML Contexts Stack

Single quoted JavaScript string

JavaScript code

URI

Double quoted HTML attribute value

Single Quoted JavaScript String

URI

Double Quoted HTML Attribute Value

JavaScript Code

input = ');alert('bad

input = %27);alert(%27bad

4

I’m feeling lucky

5

CVEs: 1995-2013

1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013

Low Severity 1 9 19 22 113 98 190 153 100 208 454 515 231 186 199 278 260 511 426

Med Severity 6 21 88 90 357 471 714 999 749 1274 2437 3332 3125 2607 2814 2267 2069 3013 2450

High Severity 18 45 145 134 424 451 773 1004 678 969 2040 2761 3158 2839 2719 2094 1821 1765 1518

500

1500

2500

3500

4500

5500

6500

# CV

Es

* There is some debate about the validity of this data, but nobody would argue we have security anywhere near licked

11/2013

6

What’s Usually Done

• Ignore it.

• Wait until the application is about to ship – then pen test.

• Wait until deployment – and pray.

• Hope that security people will find all the vulnerabilities for us.

Developer view of developer Security view of developer

7

Stuck

in a time box

8

Communicating with Security People• Ask how to remediate.

• Leverage bug tracking systems.

• Tell them your timeframe for design, coding, and testing.

• Give access to your code and how to build it easily.

• Share architecture diagrams.

• Prepare a testing environment.

• Budget time to fix the issues that come back.

• Know what you don’t know – ask questions about anything you don’t fully understand, especially how to fix.

• Move away from the “prove it’s exploitable” attitude and toward positive “how can I fix it properly”

9

Fix Earlier = Cheaper

Re-quire-ments

Design Coding Quality Assurance

Release

1x 3x 5x10x

30-100x

It pays to address securityweaknesses as soon as they are introduced

* Based on NIST report “The Economic Impacts of Inadequate Infrastructure for Software Testing”

10

We Need a New Persona for Attackers

11

Security in Embedded in All Development Activities

Security Requiremen

ts

Train Design Code Test

Threat Modeling

Attack Surface

Reduction

Supply Chain

Static Analysis

Security Testing

Focused Developer Training

12

Threat Modeling Starts with Architecture

Data flows

Components

Trust Boundaries

Assets

(Actors – not shown)

13

Analyze for Threats

AbuseCases

Top-N list

Your friendlysecurity expert

• Set aside time for threat modeling• Treat it as part of the design process• Incrementally update it• Get key architects involved• Make developers accessible

DevelopersArchitects

14

Behind the Curtain: No Magic

STRIDE = { Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege}

DREAD(x) = Avg(Damage potential(x), Reproducibility(x), Exploitability(x), Affected users(x), Discoverability(x))

AbuseCases

AbuseCases Top-N list

“Elaborate possible threats”

“Educated guess of risk”

15

Example: XML External Entity (XXE)

16

The Highly Sophisticated

Swiss Cheese Model

17

CWE Top 25Applicable Find and Fix Mitigations

Design Review SA DA

Code Review

Pen Test CSP HSTS

[1] SQL Injection ✗ ✗ ✗[2] OS Command Injection ✗ ✗[3] Classic Buffer Overflow ✗[4] Cross-site Scripting ✗ ✗ ✗[5] Missing Authentication for Critical Function ✗ ✗ ✗[6] Missing Authorization ✗ ✗ ✗[7] Use of Hard-coded Credentials ✗[8] Missing Encryption of Sensitive Data ✗ ✗ ✗ ✗[9] Unrestricted Upload of File with Dangerous Type ✗[10] Reliance on Untrusted Inputs in a Security Decision ✗ ✗[11] Execution with Unnecessary Privileges ✗ ✗[12] Cross-Site Request Forgery (CSRF) ✗[13] Path Traversal ✗[14] Download of Code Without Integrity Check ✗[15] Incorrect Authorization ✗ ✗[16] Inclusion of Functionality from Untrusted Control Sphere ✗ ✗[17] Incorrect Permission Assignment for Critical Resource ✗[18] Use of Potentially Dangerous Function ✗[19] Use of a Broken or Risky Cryptographic Algorithm ✗[20] Incorrect Calculation of Buffer Size ✗[21] Improper Restriction of Excessive Authentication Attempts ✗[22] URL Redirection to Untrusted Site ('Open Redirect') ✗[23] Uncontrolled Format String ✗[24] Integer Overflow or Wraparound ✗[25] Use of a One-Way Hash without a Salt ✗

18

Top Design-Time Mitigations

Choice of programming language

• C/C++ has memory corruption

Choice of Frameworks

• Ask for an expert opinion.

• Keep frameworks up to date.

Choice of Templating

• Contextual auto-escaping helps prevent XSS.

• Warning: only HTML escaping isn’t enough in all cases. For example, Ruby’s ERB only does this (and not quite right…)

Web Applications• Content Security Policy (CSP)

• Makes exploitation of XSS harder.

• Requires refactoring of inline scripts.

• X-Frame-Options (XFO)

• The fix for clickjacking.

Native Applications• Stack protection, DEP, ASLR,

etc.

• Secure compiler and runtime options give big bang for buck.

Databases• Object-Relational Mapping

(ORM) helps but still need to be vigilant about any explicit query-like strings.

19

Top Code-Time Fixes

Input validation

• Check inputs are actually within their expected data type

• Misconception: data is “clean” and “safe” after input validation. Not always so!!

• Security by Serendipity is good, but not enough.

• When input validation fails, assume the data is malicious and treat accordingly.

Output Escaping• Escape metacharacters when

putting string data into another parser.

String x = Input()

HTML: Escape.html(x)

JS String: Escape.jsString(x)

CSS String: Escape.cssString(x)

URI query parm: Escape.uri(x)

Nested contexts: seek help

20

Static Analysis

Code

Static Analysis

char *p

if (x == 0)

p = 0 p = foo()

if(x != 0)

s=*p

true false

falsetrue

...

return

Defects

• It’s about automation and built-in knowledge.• One of the few tools that work in the inner loop of development.• Make sure it gets tuned, configured, deployed, and adopted.

21

+1 works while you sleep

22

Supply Chain

Developer

3rd Party

Open Source

• Keep dependencies up to date• Check for CVEs and security

notifications• Due diligence before selecting

open source projects

23

End of Tour

Security Requiremen

ts

Train Design Code Test

Threat Modeling

Attack Surface

Reduction

Supply Chain

Static Analysis

Security Testing

Focused Developer Training

24

Program Behaviors on Two Axes

25

A Typical Program

26

Development Responsibility Includes a Lot of Security

27

How to Get Started with Security

• Specialize: assign a developer from your team to learn about security for the specific technologies you are using. Reward it.

• Apply common mitigations. Automate as much of the “find and fix” process as possible.

• Start a discussion among your team about the attacker persona and abuse cases.

• Look for security expertise when hiring developers.

• Adapt a Secure Development Lifecycle to your development processes. See SafeCode’s Agile stories for security: http://www.safecode.org

28

Resources: Learning More

Microsoft SDL

http://www.microsoft.com/security/sdl (Secure Development Lifecycle)

OWASP

http://www.owasp.org (web apps; focus on the cheat sheets)

SafeCode

http://www.safecode.org (excellent security-focused Agile stories)

CWE

http://cwe.mitre.org (taxonomy of security weaknesses)

Security blogs

http://security.coverity.com (Coverity Security Research Lab blog)

Thank YouAndy Chouandy@coverity.com@_achou

Want to try Coverity on your code? For a free trial, visit:

www.coverity.com