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
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
3. @ysmithnd CYBER OPERATIONS OFFICER, USAF PLEASED TO MEET YOU
4. @ysmithnd CYBER OPERATIONS OFFICER, USAF RECOVERING PRODUCT MANAGER, PWNIE EXPRESS PLEASED TO MEET YOU
5. @ysmithnd CYBER OPERATIONS OFFICER, USAF RECOVERING PRODUCT MANAGER, PWNIE EXPRESS LEAD INFOSEC ANALYST, TARGET PLEASED TO MEET YOU
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?”
7. @ysmithND THE COMMON REFRAIN
8. @ysmithnd ARE WE THE BADDIES? obvious baddie “SECURITY” IS PART OF THE PROBLEM
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
10. @ysmithND WE’RE MAKING THIS TOO HARD (STILL)
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
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”
13. HYPOTHESIS OUR LANGUAGE IS OUT OF SYNC WITH THE BUSINESS
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
15. @ysmithnd product engineering WORLDS COLLIDING A VENN DIAGRAM OF PERSONAS : IDEALLY? security
16. @ysmithnd WORLDS COLLIDING A VENN DIAGRAM OF PERSONAS: A COMPROMISE security product engineering
17. #HOTTAKES
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
19. @ysmithND LET’S PLAY A GAME DUNGEON MASTER OF ENGINEERING
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.
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
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
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
24. QUICK DEMO THIS IS FINE…EVERYTHING IS FINE
25. LESSONS LEARNED OUTCOMES
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%
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
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
29. RECOMMENDATIONS
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
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
32. REFERENCES MORE INFO RESOURCES &
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
34. QUESTIONS FIGHT ME @ysmithnd darkmsph1t yolonda.io yolonda-smith
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