DevBeat 2013 - Developer-first Security
•Download as PPTX, PDF•
0 likes•2,359 views
The document discusses how to integrate security into the software development process. It recommends treating security as part of design from the beginning through activities like threat modeling, rather than as an afterthought. It provides examples of common vulnerabilities and mitigations that can be implemented at the requirements, design, code, and testing phases like input validation, output escaping, and static analysis. The document advocates finding and fixing issues earlier and communicating regularly with security experts.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to DevBeat 2013 - Developer-first Security
Similar to DevBeat 2013 - Developer-first Security (20)
Recently uploaded
Recently uploaded (20)
DevBeat 2013 - Developer-first Security
- 1. Developer-First Security Andy Chou CTO and Founder Coverity Copyright Coverity, Inc., 2013
- 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. 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
- 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. 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
- 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. 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. We Need a New Persona for Attackers 10
- 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. 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. 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. 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. 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
- 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. 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. 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. 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
- 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. 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. Program Behaviors on Two Axes 24
- 26. Development Responsibility Includes a Lot of Security 26
- 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. 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
- 30. Want to try Coverity on your code? For a free trial, visit: www.coverity.com