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.

Transcript

1. devel(oper)
   LESSONS LEARNED IN BUILDING AN APPLICATION SECURITY MODULE
   Empathy for the
   yolonda smith
   

   View Slide

2. @ysmithnd
   

   View Slide

3. @ysmithnd
   STORY TIME
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

8. @ysmithnd
   are we the
   baddies?
   

   View Slide

9. @ysmithnd
   THEORY TIME
   

   View Slide

10. @ysmithnd
    can changing how
    we talk about
    security help us fix
    these issues for
    good?
    

    View Slide

11. @ysmithnd
    what’s my motivation?
    

    View Slide

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
    

    View Slide

13. @ysmithnd
    security
    product
    engineering
    design
    A VENN DIAGRAM OF PERSONAS : IN PRACTICE
    

    View Slide

14. @ysmithnd
    Puppet | State of DevOps Report
    

    View Slide

15. @ysmithnd
    Puppet | State of DevOps Report
    

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

22. @ysmithnd
    IT’S 8 AM ON THURSDAY MORNING.
    WE NEED TO HAVE AN MVP BY 5 PM ON MONDAY
    

    View Slide

23. @ysmithnd
    GO!
    this is fine…everything is fine
    

    View Slide

24. @ysmithnd
    how did we
    do?
    

    View Slide

25. @ysmithnd
    Product Engineering Design Security
    met all
    requirements
    on time
    does it work?
    

    View Slide

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%
    

    View Slide

27. @ysmithnd
    LESSONS LEARNED
    

    View Slide

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

    View Slide

29. @ysmithnd
    what we owe
    each other
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

34. @ysmithnd
    resources &
    references
    

    View Slide

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
    

    View Slide

36. QUESTIONS
    fight me
    @ysmithnd darkmsph1t yolonda.io yolonda-smith
    

    View Slide

37. devel(oper)
    LESSONS LEARNED IN BUILDING AN APPLICATION SECURITY MODULE
    Empathy for the
    yolonda smith
    

    View Slide