$30 off During Our Annual Pro Sale. View Details »

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.

ysmithND

May 18, 2019
Tweet

More Decks by ysmithND

Other Decks in Technology

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