Security practitioners know that the threats that face an organization are always active, and that while defenders need to get everything right, a good attacker only needs to get one thing right. That’s all well and good for security practitioners, but what about the rest of the company? How do you transform security from a rather inconvenient checklist, to a nascent awareness of the threat? How do you get those responsible for providing your attack surface to ‘actually care about whether it’s secure or not?
Welcome to the blue team! How building a better hacker accidentally built a better defender.
Welcome to the blue team…
(How building a better hacker accidentally
built a better defender)
Casey Ellis - Converge Detroit 2014
JABAH (Just Another Blonde Aussie Hacker)
Recovering pentester turned solution architect turned sales guy turned
Wife and two kids now living in San Francisco
Founder and CEO of Bugcrowd
Before we begin…
• I’m not here to sell you anything.
• Let’s be real.
• I’m not a developer. I’m a 100% breaker. So I’m
speaking to security folks in front of developers.
This will hopefully help all of you.
• Who here builds for a living?
• Who here breaks for a living?
• Who does both? Seriously? You poor bugger.
Very different actually…
and we don’t want to change that.
You’re paid to do completely
the opposite things.
Push this feature by this
deadline because $REASON.
Make sure dev doesn’t do anything "
that lets the bad guys in.
• Those who think like bad guys *greatly*
overestimate the ability for everyone else to think
like a bad guy.
• Doesn’t make security people “better”. Does make
us useful (and really, really annoying).
• Tip: The next time you feel like calling a developer
“dumb”, build and launch a product ﬁrst.
All this security shit
slows us down
Why won’t they take "
• Development contributes to products which make
money. No dev = no product = no money = no job
= no beuno.
• Security minimizes risk of loss. No security = More
risk… but *maybe* nothing will happen.
• This driver for prioritization happens all. the. time.
The real developer problem
I don’t believe in
The real security problem
I don’t have the time/energy/people skills/resources "
to convince you that the boogeyman is real.
• Thanks to every security vendor ever for making
this even harder.
• FUD works, but FUD fatigue is real.
• Developer checklists
• Check-in testing/CI tests
• Security awareness training
• Pentesting/VA/outsourced things
So we do this…
(and let’s be honest, we quite enjoy it too…)
…and about introducing your
devs to this guy.
Egor Homakov (@homakov)
aka “that guy who totally owned
Github that time”
Good guy who thinks like a bad guy
“I wonder what his next-door
neighbor can do?”
An idea: Gamify your SDLC
• Create a pot that beneﬁts your dev team (team
drinks, party, event, whatever) and have bug
bounties paid from it. What ever the hackers don’t
get, the devs keep.
• Level up: Pilot it with internal teams.
The Golden Rule:
Touch the code
reward the bug
The mistake *everyone* makes:
• Bug bounties are cost effective, and highly
marketable… but that’s not the full story…
• …the psychology of external disclosure is
completely different to internal security training,
and it’s extremely effective.
• Go start one.
• More tips and tricks at https://blog.bugcrowd.com