Empathy for the Devel(oper): Lessons Learned Building an Application Security Module

Empathy for the Devel(oper): Lessons Learned Building an Application Security Module

Security teams spend a lot of time focused on the results and impact of what happens when there's a security failure. In turn, we have a bad habit of 'Monday-Morning-Quarterback'ing all the things that should have happened to prevent the security failure in the first place. But have you ever attempted to fully implement all of the security advice that's out there in conjunction with business priorities? Well, I did. In this presentation, I will share what I learned about what it takes to get application security right from design to delivery, how to communicate about REAL risk (without the FUD) and why we should eliminate the word "just" from our solutioning.

F9d3545dd612c6e8c037202e285a21cd?s=128

ysmithND

June 07, 2019
Tweet

Transcript

  1. devel(oper) LESSONS LEARNED IN BUILDING AN APPLICATION SECURITY MODULE Empathy

    for the yolonda smith
  2. @ysmithnd

  3. @ysmithnd STORY TIME

  4. @ysmithnd “WE GOT A FINDING ABOUT METHOD OVERRIDE, BUT THE

    RECOMMENDATIONS [IN THE REPORT] WEREN’T USEFUL, SO I DECIDED TO DO SOME INDEPENDENT RESEARCH TO SEE IF I COULD FIGURE IT OUT. I ENDED UP EVEN MORE CONFUSED AND I STILL DON’T KNOW HOW TO PREVENT METHOD OVERRIDE ABUSE. I FEEL LIKE I WASTED VALUABLE TIME.” front-end developer FROM THE SOURCE
  5. @ysmithnd WHAT HE GOT ▸ “Attackers may bypass server protections

    against dangerous HTTP verbs using override techniques.” ▸ “The attack works by using a trusted HTTP verb such as GET or POST, but adds request headers such as X-HTTP-Method, X-HTTP-Method- Override, or X-Method-Override to provide a restricted verb such as PUT or DELETE. Doing so will force the request to be interpreted by the target application using the verb in the request header instead of the actual HTTP verb. In certain cases, the restricted verb may also be used in query or post parameters instead of a request header” WHAT HE WAS LOOKING FOR ‣ A concise explanation of why method override is a security vulnerability & which specific methods are considered ‘dangerous’ ‣ An explanation of the actual risk to the overall product & the business ‣ A recommendation of the best place to resolve the issue in the technology stack
  6. @ysmithnd 88% Breaches from one of nine patterns 52% Breaches

    featured ‘hacking’ as the primary action 6% Breaches as a result of exploiting a vulnerability
  7. @ysmithnd THIS is the bad place ▸ Tech stacks have

    changed, but security issues haven’t ▸ Guidance is plentiful but is vague, out- dated, condescending or contradictory ▸ Security solutions aren’t part of the product’s lifecycle
  8. @ysmithnd are we the baddies?

  9. @ysmithnd THEORY TIME

  10. @ysmithnd can changing how we talk about security help us

    fix these issues for good?
  11. @ysmithnd what’s my motivation?

  12. @ysmithnd security attack defense vulnerability findings forensics threat prevent, detect

    respond product competition cost of goods total addressable market revenue ‘the funnel’ customer acquisition cost risk engineering velocity prevention vs cure throughput technical debt churn cycle time serviceability A VENN DIAGRAM OF PERSONAS : LANGUAGE MATTERS
  13. @ysmithnd security product engineering design A VENN DIAGRAM OF PERSONAS

    : IN PRACTICE
  14. @ysmithnd Puppet | State of DevOps Report

  15. @ysmithnd Puppet | State of DevOps Report

  16. @ysmithnd security product engineering design A VENN DIAGRAM OF PERSONAS

    : A COMPROMISE
  17. @ysmithnd let’s play a game The trolley problem

  18. @ysmithnd YOU’RE A FULL STACK DEVELOPER AT A GAME RETAILER.

    THE BUSINESS WANTS TO DRIVE *MORE* INTEREST IN SOME OF THEIR LESS POPULAR GAMES AND BELIEVES THAT THEY CAN DO IT BY RUNNING A FLASH SALE ON BOTH WEB AND MOBILE PLATFORMS. EXISTING CUSTOMERS WILL GET 10% OFF WHILE *NEW* CUSTOMERS WILL GET 30% OFF. TO TRULY DISTINGUISH THE OFFER, IT WILL BE RUN AS A POP-UP SALE, HELD ALMOST ENTIRELY SEPARATELY FROM THE MAIN SALES FUNNEL.
  19. @ysmithnd “full 1 • stack • developer ” /fool/ /stack/

    /dəˈveləpər/ an engineer who can handle all the work of databases, servers, systems engineering, and clients. Depending on the project, what customers need may be a m o b i l e s t a c k , a w e b s t a c k , o r a n a t i v e application stack
  20. @ysmithnd 1. WEB is primary focus 2. Customers should be

    able to log into existing account and/or register for a new account 3. Needs to keep track of customer movement around the site 4. Want to be able to suggest/promote *new* games & platforms on sister sites 5. Must use existing payment pattern (can’t extend PCI scope) 6. Secure flash sale requirements
  21. @ysmithnd ▸ Assume limited-knowledge or background in security or security

    tools ▸ Confront security questions as they come up ▸ No buy/partner decisions: the application itself must be secure experiment controls
  22. @ysmithnd IT’S 8 AM ON THURSDAY MORNING. WE NEED TO

    HAVE AN MVP BY 5 PM ON MONDAY
  23. @ysmithnd GO! this is fine…everything is fine

  24. @ysmithnd how did we do?

  25. @ysmithnd Product Engineering Design Security met all requirements on time

    does it work?
  26. @ysmithnd EXPERIMENT RESULTS HOW SECURE ARE WE? Generic App’s Requirements

    Technical Implications Primary Source of Influence Coverage of OWASP Recommendations Login & Registration Authentication, Input Validation, Database Queries NodeJS Authentication with Password and JWT in Express AC => 5/20 req; IV => 0/37 req; DB = > 0/3* req Profile Management Authorization, Method Override Node.js - Role Based Authorization Tutorial… Authorization => N/A MO => 0/2* req Session Management/Tracking Cookies, Tokens Nodejs Security Checklist “Sessions” => 35 req Cookies => 5/12 req Tokens => API Push/Fetch CORS, Key Management CORS, Cross-Origin Resource Sharing CORS => 6/7 req Keys => 2/34 req Delivery Caching Cache Poisoning Leveraging Various X-Headers 2/3 Transport TLS, Headers Securing Node.js apps with SSL/TLS TLS => 0/23 req 25% 42% 0% 85% 66% 0%
  27. @ysmithnd LESSONS LEARNED

  28. @ysmithnd “goodness” rots “goodness” isn’t binary “being good” not that

    simple
  29. @ysmithnd what we owe each other

  30. @ysmithnd Protect the Roadmap Protect the Pipeline Protect the Customer

    main priorities
  31. @ysmithnd Consider security risk from customer’s perspective embarrass? inconvenience? harm?

    Protect the Customer main priorities
  32. @ysmithnd Protect the Roadmap Consider how security initiatives actually benefit

    the business Make friends with the PM Show up with the data main priorities
  33. @ysmithnd Protect the Pipeline Consider how security initiatives actually affect

    the product avoid the ‘oogey boogey’ dance embrace & engage in ’shift left’ main priorities
  34. @ysmithnd resources & references

  35. @ysmithnd LEVEL UP YOUR SKILLS LEARN THE LANGUAGE OF THE

    BUSINESS https://www.udemy.com/share/1003OW/ LEARN THE LANGUAGE OF THE PIPELINE https://www.udemy.com/share/100TOG/ https://medium.com/@therealchrisrutherford/nodejs-authentication-with-passport-and-jwt-in-express-3820e256054f https://jasonwatmore.com/post/2018/11/28/nodejs-role-based-authorization-tutorial-with-example-api https://blog.risingstack.com/node-js-security-checklist/ https://flaviocopes.com/cors/ https://www.fastly.com/security-advisories/cache-poisoning-leveraging-various-x-headers blog.usejournal.com EXPERIMENT REFERENCES STATE OF DEVOPS REPORT, 2018 https://puppet.com/resources/whitepaper/state-of- devops-report
  36. QUESTIONS fight me @ysmithnd darkmsph1t yolonda.io yolonda-smith

  37. devel(oper) LESSONS LEARNED IN BUILDING AN APPLICATION SECURITY MODULE Empathy

    for the yolonda smith