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

Post on 08-Aug-2015

172 views 0 download

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!

jobs@bugcrowd.com