Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How Sec Can Convince DevOps To Believe In The Boogeyman (B-Sides SF)

919 views

Published on

Presented at B-Sides SF 2015:

Leif Dreizler, BugCrowd, explores the inherent differences between the hacker and developer mentality. In this discussion, the audience will hear from a former breaker and fixer of security flaws on how developers who acknowledge the existence of ‘The Boogeyman’ come that much closer to being active participants in ensuring their company’s security, rather than passive victims.

Published in: Technology
  • Login to see the comments

  • Be the first to like this

How Sec Can Convince DevOps To Believe In The Boogeyman (B-Sides SF)

  1. 1. How Sec Can Convince DevOps To Believe In The Boogeyman
  2. 2. Sr. AppSec Engineer @leifdreizler
  3. 3. Sr. Security Engineer @leifdreizler
  4. 4. Your Elastic Security Team
  5. 5. So What Does Bugcrowd Actually Do? • Incorporate up to 16,000 freelance security researchers as part of a public or private engagement • Run a crowd sourced pen test • Manage an ongoing bug bounty program
  6. 6. What’s a bug bounty program?
  7. 7. A Brief History of Bug Bounty Programs
  8. 8. These%brands%(and%others)%trust%Bugcrowd
  9. 9. • A brief introduction to DevOps • How to incorporate Sec into DevOps • Accelerating your RO (security) I • What’s in it for me (as a security person)? Things we’ll cover
  10. 10. How did we get here?
  11. 11. Fast forward to 2015 CLOUD / SaaS MOBILE / BYOD DISTRIBUTED/SOA AGILE / LEAN
  12. 12. Move Security as Close to the Code as Possible The New Fence
  13. 13. Ops Don’t break anything Dev and Ops teams traditionally had different goals Devs Build all the things
  14. 14. • core to agile software development • deploy code frequently/continuously • increase speed of release cycles • reduce time to fix bugs • reduces ‘tension’ between stability and new features DevOps
  15. 15. The Double Edged Sword
  16. 16. Ops Don’t break anything Dev, Ops, and Sec teams
 have different goals Sec Break Everything Devs Build all the things
  17. 17. We’re different… Builders Breakers …and that’s good.
  18. 18. You’re [built | incentivized | driven] to do completely opposite things.
  19. 19. Difficult to Navigate
  20. 20. Developer Incentive Push this feature by this 
 deadline because $REASON.
  21. 21. Ops Incentive Push this feature by this 
 deadline because $REASON.
  22. 22. Security Incentive
  23. 23. • Good guys who think like bad guys tend to overestimate the ability for everyone else to think like a bad guy. • Doesn’t make security people “better”. Does make us useful (and annoying if you don’t buy-in to what we’re saying). • Tip: The next time you feel like calling a developer “dumb”, build and launch a product first. Side note:
  24. 24. The real developer problem I don’t believe in 
 the boogeyman
  25. 25. The real Ops Problem Push this feature by this 
 deadline because $REASON.
  26. 26. The real security problem
  27. 27. • Security vendors for making this even harder. • Fear, Uncertainty, & Doubt works as a awareness tool, but FUD fatigue is very, very real. A Big Thanks
  28. 28. Status quo • Developer checklists • Check-in testing/CI tests • Security awareness training • Pentesting/VA/SCA/outsourced things BLOCKERS
  29. 29. So security people do this… (and let’s be honest, we quite enjoy it too…)
  30. 30. It doesn’t work over the long term.
  31. 31. Integrating Security into DevOps
  32. 32. start simple, take small steps, leverage easy wins The Secret
  33. 33. “developers have to care about the security of every line of code”
  34. 34. Educate developers about the security implications of the code they write
  35. 35. “everyone has to care about process” • Make everyone part of the same team • Diversify your scrum team • Implement a fire fighting team
  36. 36. Decrease friction
 between Dev, Ops, and Sec
  37. 37. 500 devs != 5 security engs
  38. 38. Protect staff from phishing
 Monitor/scan server infrastructure Respond to ongoing security threats AND review 500 dev * # lines of code per day! Security Responsibilities
  39. 39. Peer code reviews (Pull Requests) TDD Applied to Security Static Application Security Testing Dynamic Application Security Testing Improve the Security Process
  40. 40. Server side input validation failure when client side validation exists Validation for hidden fields, radio buttons, or drop down menus Blatant SQLi or XSS Browsing to /admin/login.php or other honeypot URIs App Layer IDS src: OWASP Proactive Controls
  41. 41. introduce crowd sourcing 
 Bug Bounty Programs Responsible Disclosure Crowdsourced Penetration Test
  42. 42. …because people are the new automation
  43. 43. [REDACTED] eCommerce provider • Long time customer of [EXPENSIVE WEB APP SCANNER] getting “clean results” • Researcher gained super admin access through a chained attack within 24 hours of launch • They thought they were doing a great job at writing secure code…
  44. 44. assume it’s broken
  45. 45. Instructure received 8x the number of unique vulnerabilities compared to previous pen tests
  46. 46. Lots of bugs == great dev training
  47. 47. Aggregate vulnerabilities by category to focus on areas of improvement
  48. 48. Software is always going to have bugs
  49. 49. Let’s head them off at the pass…
  50. 50. [REDACTED] Financial Services • Extortion attempt from Eastern Europe • Resolved by creating a “one man bug bounty” (we didn’t tell him he was the only one though…) • Bug received in 15 mins
  51. 51. History 0 125 250 375 500 1995 2000 2005 2010 2015 Adoption of bug bounty and vulnerability disclosure programs.
  52. 52. Bug bounties are awesome…
  53. 53. Minimize Investment Maximize Quality Accelerate RO(security)I Makes a Statement
  54. 54. It’s not just about being cost-effective, or loud…
  55. 55. It’s about leveling the playing field…
  56. 56. …but bug bounties are hard.
  57. 57. Plan ahead
  58. 58. The mistake *everyone* makes: VULNERABILITY DATA PEOPLE
  59. 59. [REDACTED] Digital Advertising • Engaged Bugcrowd to help them assess the state of the code • So many valid vulnerabilities submitted they shut down the bounty in 24 hours • Thrilled with the results!
  60. 60. The Golden Rule: Touch the code == Pay the bug
  61. 61. Align expectations before you engage
  62. 62. Bug bounties create controlled incidents…
  63. 63. [REDACTED] Online Marketplace • The DevOps and Security teams watched vulns being submitted in real time • Non-security minded people learned a lot from the process • Great insight into how ‘good guys that think like bad guys’ work
  64. 64. Mozilla Thanks to @mwcoates http://www.slideshare.net/michael_coates/bug-bounty-programs-for-the-web Clearing their assurance debt Boogeyman belief
  65. 65. DevOpsSec feeling confident? Try a Gamified Pentest 1. Create a pool that benefits your engineering team (team drinks, party, event, whatever) 2. Replace an existing pentest w/ a time-boxed bug bounty program 3. Pay out from the reward pool 4. What ever the hackers don’t get, DevOpsSec gets to keep.
  66. 66. Great things happen when you tighten the security feedback loop between your engineers, and what they consider to be the outside world
  67. 67. Conclusion • Bug bounties are cost effective, and highly marketable, but that’s not the full story… • …they create controlled incidents that can powerfully impact the security awareness of your builders. • Allow people that have historically been ‘builders’ to see how ‘breakers’ think • Get DevOps to believe in and defeat the boogeyman
  68. 68. Questions? Responsible Disclosure Flex Bug Bounty
  69. 69. W e’re hiring! jobs@ bugcrowd.com

×