DevBeat 2013 - Developer-first Security

2,117 views

Published on

Few developers pay attention to security, in spite of the unstoppable tide of security defects in code. Big money is being spent by governments to buy bugs, and exploits have become a new class of weapon in the arsenal of militaries around the world. It is high time that developers pay attention. In these slides, Coverity CTO & co-founder Andy Chou presents a model for how developers can begin to think about security, including some of the most common types of weaknesses that are still plaguing our applications. For each weakness, a concrete code example helps illustrate the bug and what to do about it. From there, he goes up a level and discuss why developers need to begin to "own security" and change the culture from within in order to make a dent in the security problems we face.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,117
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DevBeat 2013 - Developer-first Security

  1. 1. Developer-First Security Andy Chou CTO and Founder Coverity Copyright Coverity, Inc., 2013
  2. 2. Developer Priorities Building features on 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. 2
  3. 3. Security can be Complex <a href="javascript:hello('${input}')"> Single Quoted JavaScript String JavaScript Code HTML Contexts Stack Single quoted JavaScript string JavaScript code URI URI Double Quoted HTML Attribute Value input = ');alert('bad input = %27);alert(%27bad Double quoted HTML attribute value
  4. 4. 4
  5. 5. CVEs: 1995-2013 7000 6000 5000 11/2013 # CVEs 4000 3000 2000 1000 0 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 High Severity 18 45 145 134 424 451 773 1,004 678 969 2,040 2,761 3,158 2,839 2,719 2,094 1,821 1,765 1,518 Med Severity 6 21 88 90 357 471 714 999 749 Low Severity 1 9 19 22 113 98 190 153 100 1,274 2,437 3,332 3,125 2,607 2,814 2,267 2,069 3,013 2,450 208 454 515 231 186 199 278 260 511 426 * There is some debate about the validity of this data, but nobody would argue we have security anywhere near licked 5
  6. 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 6 Security view of developer
  7. 7. 7
  8. 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” 8
  9. 9. Fix Earlier = Cheaper 30-100x It pays to address security weaknesses as soon as they are introduced 1x 3x Requirements Design 5x Coding 10x Quality Assurance * Based on NIST report “The Economic Impacts of Inadequate Infrastructure for Software Testing” 9 Release
  10. 10. We Need a New Persona for Attackers 10
  11. 11. Security in Embedded in All Development Activities Security Requirements Train Focused Developer Training 11 Design Code Threat Modeling Supply Chain Attack Surface Reduction Static Analysis Test Security Testing
  12. 12. Threat Modeling Starts with Architecture web Internal network Trust Boundaries CIM DB Data flows File System jdbc browser hibernate http controllers CIM JSON conf-push REST API Commit Interface WS LDAP http Components http/soap WS client Cache (Actors – not shown) 12 web server Assets
  13. 13. Analyze for Threats web Your friendly security expert Internal network CIM DB File System • • • • • jdbc browser hibernate http controllers CIM JSON conf-push REST API Commit Interface WS LDAP http http/soap WS client Set aside time for threat modeling Treat it as part of the design process Incrementally update it Get key architects involved Make developers accessible Cache web server Developers Architects Abuse Cases 13 Top-N list
  14. 14. Behind the Curtain: No Magic “Elaborate possible threats” web Internal network CIM DB File System jdbc browser hibernate http controllers CIM JSON conf-push REST API Commit Interface WS LDAP http http/soap WS client Cache web server STRIDE = { Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege } Abuse Cases “Educated guess of risk” Abuse Cases 14 DREAD(x) = Avg(Damage potential(x), Reproducibility(x), Exploitability(x), Affected users(x), Discoverability(x)) Top-N list
  15. 15. Example: XML External Entity (XXE) web Internal network CIM DB 3 - Access to config files File System jdbc 2 - Entity reference to system file browser hibernate http controllers CIM JSON conf-push REST API Commit Interface WS LDAP http http/soap WS client 1 - XML parser misconfiguration Cache web server 15
  16. 16. 16
  17. 17. CWE Top 25 Find and Fix Applicable Design Review [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] 17 SQL Injection OS Command Injection Classic Buffer Overflow Cross-site Scripting Missing Authentication for Critical Function Missing Authorization Use of Hard-coded Credentials Missing Encryption of Sensitive Data Unrestricted Upload of File with Dangerous Type Reliance on Untrusted Inputs in a Security Decision Execution with Unnecessary Privileges Cross-Site Request Forgery (CSRF) Path Traversal Download of Code Without Integrity Check Incorrect Authorization Inclusion of Functionality from Untrusted Control Sphere Incorrect Permission Assignment for Critical Resource Use of Potentially Dangerous Function Use of a Broken or Risky Cryptographic Algorithm Incorrect Calculation of Buffer Size Improper Restriction of Excessive Authentication Attempts URL Redirection to Untrusted Site ('Open Redirect') Uncontrolled Format String Integer Overflow or Wraparound Use of a One-Way Hash without a Salt SA DA ✗ ✗ ✗ ✗ ✗ Mitigations Code Review Pen Test CSP HSTS ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗
  18. 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…) 18 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 querylike strings.
  19. 19. Top Code-Time Fixes Input validation • Check inputs are actually within their expected data type Output Escaping • Escape metacharacters when putting string data into another parser. • 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. 19 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. 20. Static Analysis Code Defects char *p if (x == 0) Static Analysis true p=0 false p = foo() if(x != 0) true false ... s=*p return • 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. 20
  21. 21. 21
  22. 22. Supply Chain 3rd Party Developer Open Source • Keep dependencies up to date • Check for CVEs and security notifications • Due diligence before selecting open source projects 22
  23. 23. End of Tour Security Requirements Train Focused Developer Training 23 Design Code Threat Modeling Supply Chain Attack Surface Reduction Static Analysis Test Security Testing
  24. 24. Program Behaviors on Two Axes 24
  25. 25. A Typical Program 25
  26. 26. Development Responsibility Includes a Lot of Security 26
  27. 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 27
  28. 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) 28
  29. 29. Thank You Andy Chou andy@coverity.com @_achou
  30. 30. Want to try Coverity on your code? For a free trial, visit: www.coverity.com

×