How Sec Can Convince DevOps To Believe In The Boogeyman (B-Sides SF)
-
Upload
leifdreizler -
Category
Technology
-
view
172 -
download
0
Transcript of How Sec Can Convince DevOps To Believe In The Boogeyman (B-Sides SF)
How Sec Can Convince DevOps To Believe In The Boogeyman
Sr. AppSec Engineer@leifdreizler
Sr. Security Engineer@leifdreizler
Your Elastic Security Team
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
What’s a bug bounty program?
A Brief History of Bug Bounty Programs
These brands (and others) trust Bugcrowd
• 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
How did we get here?
Old School Thinking
Fast forward to 2015CLOUD / SaaS
MOBILE / BYOD DISTRIBUTED/SOA
AGILE / LEAN
Move Security as Close to the Code as Possible
The New Fence
Ops Don’t break anything
Dev and Ops teams traditionally had different goals
Devs Build all the things
• 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
The Double Edged Sword
Ops Don’t break anything
Dev, Ops, and Sec teams have different goals
Sec Break Everything
Devs Build all the things
We’re different…
Builders Breakers
…and that’s good.
You’re [built | incentivized | driven] to do completely opposite things.
Difficult to Navigate
Developer Incentive
Push this feature by this deadline because $REASON.
Ops Incentive
Push this feature by this deadline because $REASON.
Security Incentive
• 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:
The real developer problem
I don’t believe in the boogeyman
The real Ops Problem
Push this feature by this deadline because $REASON.
The real security problem
• 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
Status quo
• Developer checklists
• Check-in testing/CI tests
• Security awareness training
• Pentesting/VA/SCA/outsourced things
BLOCKERS
So security people do this…
(and let’s be honest, we quite enjoy it too…)
It doesn’t work over the long term.
Integrating Security into DevOps
start simple, take small steps,
leverage easy wins
The Secret
“developers have to care about the security of every
line of code”
Educate developers about the security implications of the
code they write
“everyone has to care about process”
• Make everyone part of the same team • Diversify your scrum team • Implement a fire fighting team
Decrease friction between Dev, Ops,
and Sec
500 devs != 5 security engs
Protect staff from phishing
Monitor/scan server infrastructure
Respond to ongoing security threats
AND review 500 dev * # lines of code per day!
Security Responsibilities
Peer code reviews (Pull Requests) TDD Applied to Security
Static Application Security Testing Dynamic Application Security Testing
Improve the Security Process
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
introduce crowd sourcing
Bug Bounty Programs Responsible Disclosure
Crowdsourced Penetration Test
…because people are the new automation
[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…
assume it’s broken
Instructure received 8x the number of unique vulnerabilities compared to previous pen tests
Lots of bugs == great dev training
Aggregate vulnerabilities by category to focus on areas of improvement
Software is always going to have bugs
Let’s head them off at the pass…
[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
History
0
125
250
375
500
1995 2000 2005 2010 2015
Adoption of bug bounty and vulnerability disclosure programs.
Bug bounties are awesome…
Minimize Investment
Maximize Quality
Accelerate RO(security)I
Makes a Statement
It’s not just about being cost-effective, or loud…
It’s about leveling the playing field…
…but bug bounties are hard.
Plan ahead
The mistake *everyone* makes:
VULNERABILITY DATAPEOPLE
[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!
The Golden Rule:
Touch the code ==
Pay the bug
Align expectations before you engage
Bug bounties create controlled incidents…
[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
Mozilla
Thanks to @mwcoates http://www.slideshare.net/michael_coates/bug-bounty-programs-for-the-web
Clearing their assurance debt
Boogeymanbelief
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.
Great things happen when you tighten the security feedback loop between your engineers, and what
they consider to be the outside world
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
Questions?
Responsible Disclosure Flex Bug Bounty
We’re hiring!