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
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