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
   Y O L O N D A S M I T H
   

   View Slide

2. @ysmithnd
   HOUSEKEEPING
   WHAT WE’LL COVER TODAY
   ▸ about me
   ▸ A day in the life
   ▸ are we the baddies?
   ▸ personas involved in applied information security
   ▸ what are they saying that we aren’t saying?
   ▸ let’s play a game: dungeon master of engineering
   ▸ outcomes
   ▸ summary & recommendations
   

   View Slide

3. @ysmithnd
   CYBER OPERATIONS OFFICER, USAF
   PLEASED TO MEET YOU
   

   View Slide

4. @ysmithnd
   CYBER OPERATIONS OFFICER, USAF
   RECOVERING PRODUCT MANAGER,
   PWNIE EXPRESS
   PLEASED TO MEET YOU
   

   View Slide

5. @ysmithnd
   CYBER OPERATIONS OFFICER, USAF
   RECOVERING PRODUCT MANAGER,
   PWNIE EXPRESS
   LEAD INFOSEC ANALYST, TARGET
   PLEASED TO MEET YOU
   

   View Slide

6. @ysmithND
   THE COMMON REFRAIN
   “That’s handled somewhere
   else [downstream/
   upstream/some other made
   up place]”
   “Is this really that big of a
   problem? What’s the
   likelihood that anyone will
   ever find this?”
   “Where does it say we have
   to do that?”
   

   View Slide

7. @ysmithND
   THE COMMON REFRAIN
   

   View Slide

8. @ysmithnd
   ARE WE THE BADDIES?
   obvious baddie
   “SECURITY” IS PART OF THE PROBLEM
   

   View Slide

9. @ysmithnd
   TL;DR: YES
   IS ‘SECURITY' PART OF THE PROBLEM?
   ▸ Tech stacks have changed, but we’re still seeing the same security
   issues
   ▸ Guidance is plentiful but is vague, out-dated, condescending or
   contradictory
   ▸ Security solutions & metrics are built around the product, but not
   fully part of the product, thus not tied to the product’s success
   

   View Slide

10. @ysmithND
    WE’RE MAKING THIS TOO
    HARD (STILL)
    

    View Slide

11. @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.”
    actual developer
    FROM THE SOURCE
    

    View Slide

12. @ysmithnd
    COMPARE & CONTRAST
    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
    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”
    

    View Slide

13. HYPOTHESIS
    OUR LANGUAGE IS OUT OF SYNC WITH THE BUSINESS
    

    View Slide

14. @ysmithnd
    WORLDS COLLIDING
    A VENN DIAGRAM OF PERSONAS : REALITY
    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
    

    View Slide

15. @ysmithnd
    product
    engineering
    WORLDS COLLIDING
    A VENN DIAGRAM OF PERSONAS : IDEALLY?
    security
    

    View Slide

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

    View Slide

17. #HOTTAKES
    

    View Slide

18. @ysmithnd
    FLIP THE TABLE IF YOU MUST
    HOT TAKES
    ▸ To secure the business, we should learn the business
    ▸ That means a change in communication style, goals & success criteria
    ▸ You shouldn’t need to be a security expert to build a secure product
    ▸ Security solutions should contribute to the success of the product, not
    the other way around
    ▸ Security metrics should dovetail to match those of the business
    

    View Slide

19. @ysmithND
    LET’S PLAY A GAME
    DUNGEON MASTER OF ENGINEERING
    

    View Slide

20. @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

21. @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
    mobile stack, a Webstack, or a native application stack
    

    View Slide

22. @ysmithnd
    DUNGEON MASTER OF ENGINEERING
    FLASH SALE REQUIREMENTS
    1. Want to cover web AND mobile…but 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
    IT’S 8 AM ON THURSDAY MORNING. THE PLATFORM HAS TO BE LIVE BY 5 AM LOCAL TIME ON MONDAY
    

    View Slide

23. @ysmithnd
    RULES OF ENGAGEMENT
    EXPERIMENT CONTROLS
    ▸ Assume limited-knowledge or background in security or security tools
    ▸ Tech stack used should offer (relatively) low barrier to entry and yet…
    ▸ Be real-world applicable
    ▸ Confront security questions as they come up
    ▸ “No buy/partner decisions: the application itself must be secure, not add-
    ons or post-development scans
    

    View Slide

24. QUICK DEMO
    THIS IS FINE…EVERYTHING IS FINE
    

    View Slide

25. LESSONS LEARNED
    OUTCOMES
    

    View Slide

26. @ysmithnd
    EXPERIMENT RESULTS
    SECURITY COVERAGE MAP
    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
    HOW’D I DO?
    PROJECT OUTCOMES
    ▸ Building a ‘secure’ app was not easy! Biggest challenges:
    ▸ Knowing if I had implemented guidance sufficiently
    ▸ Dealing with contradicting/conflicting remediation recommendations
    ▸ “Security” is a spectrum
    ▸ The app is as secure as is needed for the product/business to operate
    

    View Slide

28. @ysmithnd
    HOW’D I DO?
    GENERAL OUTCOMES
    ▸ Since concluding this experiment
    ▸ Quantity => my engagement with developers & product owners has
    increased 10x.
    ▸ Quality => conversations about security risk centered in context to their
    application
    ▸ Improved adoption of appropriate security tools
    ▸ Finding closure rate improved across all products I consult on
    

    View Slide

29. RECOMMENDATIONS
    

    View Slide

30. @ysmithnd
    SUMMARY 1
    RECOMMENDATIONS
    ▸ To secure the business, you have to know the business
    ▸ Main Priorities
    1. Protect the Customer
    2. Protect the Roadmap
    3. Protect the Pipeline
    ▸ Let’s remove the word “just” from our vocabulary
    

    View Slide

31. @ysmithnd
    SUMMARY 2
    RECOMMENDATIONS
    ▸ Working With Developers
    ▸ Avoid the ‘oogey-boogey’ dance: talk about what’s real
    ▸ Describe risk in terms that matter to the product
    ▸ Remember: your tools don’t have your context
    ▸ Working with Business Partners
    ▸ Make friends with the product manager/owner—they decide what goes
    on the roadmap
    ▸ Describe risk in terms that matter to the business
    

    View Slide

32. REFERENCES
    MORE INFO
    RESOURCES
    &
    

    View Slide

33. @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
    

    View Slide

34. QUESTIONS
    FIGHT ME
    @ysmithnd darkmsph1t yolonda.io yolonda-smith
    

    View Slide

35. DEVEL(OPER)
    LESSONS LEARNED IN BUILDING AN APPLICATION SECURITY MODULE
    EMPATHY
    FOR THE
    Y O L O N D A S M I T H
    

    View Slide