Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

@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

Slide 3

Slide 3 text

@ysmithnd CYBER OPERATIONS OFFICER, USAF PLEASED TO MEET YOU

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

@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?”

Slide 7

Slide 7 text

@ysmithND THE COMMON REFRAIN

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

@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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

@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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

HYPOTHESIS OUR LANGUAGE IS OUT OF SYNC WITH THE BUSINESS

Slide 14

Slide 14 text

@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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

#HOTTAKES

Slide 18

Slide 18 text

@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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

@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

Slide 22

Slide 22 text

@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

Slide 23

Slide 23 text

@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

Slide 24

Slide 24 text

QUICK DEMO THIS IS FINE…EVERYTHING IS FINE

Slide 25

Slide 25 text

LESSONS LEARNED OUTCOMES

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

@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

Slide 28

Slide 28 text

@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

Slide 29

Slide 29 text

RECOMMENDATIONS

Slide 30

Slide 30 text

@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

Slide 31

Slide 31 text

@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

Slide 32

Slide 32 text

REFERENCES MORE INFO RESOURCES &

Slide 33

Slide 33 text

@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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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