Christien Rioux's keynote presentation slides from BSidesLV 2013 explores how to build a better hacker manager. Using his own career arch as a baseline Christien explores the evolution of how he became a hacker and transitioned into the management role he currently holds at Veracode. We all encounter different crossroads in life and the one constant we can count on is change. In defining success it's important to; separate business and personal goals, understand the factors that influence these and study how we can make the best decisions to achieve our goals. He breaks down the effects that hacker culture can have on companies and how many negative effects can also be turned positive. Finishing with his own Ten Commandments of Hacker Management, enjoy the presentation! You can follow Christien on Twitter: @dildog

1. The Security Industry
How To Survive Becoming Management

2. WHAT HAPPENS
TO HACKERS THAT GO PRO
?

3. A Little Back Story
The Personal Case Study Of Dil
An Accidental Hacker Manager

4. My name is Christien Rioux.
Opinions are my own, not my company’s
but they are probably right, regardless.
HI!
Understanding my recommendations requires
understanding my history a bit, pardon my ego briefly.
WHO IS THIS GUY?

5. GROWING UP
Born in West Virginia, Raised In Maine
Nothing to do but system programming
Circa 1983, learned my first programming language:
Applesoft Floating Point BASIC on the Apple ][+,
followed by 6502 assembler
Spent 4 years in high school writing a CRPG
Lost it in a hard drive crash
Learned valuable lesson about backing up
Father brought home display models of computers from store

6. SCHOOL
MIT: BS in CS
Picked terrible handle, laughed out of #hack on IRC
Wrote possibly the first public stack overflow advisory for Windows
Wrote a search engine at MIT for my senior project
Graduated in 1998
Worked for a financial startup
Found I loved security and left after 11 months
without giving up my fingerprints to the man

7. GET A JOB, KID
L0pht Heavy Industries
First to go full time at end of 1998
L0phtCrack, AntiSniff, Numerous advisories
Tao Of Windows Buffer Overflow, Back Orifice 2000
@stake
Along with 20 other people, founded @stake in 2000
Acquired in 2004 by Symantec
Spun out Veracode in 2005

8. MAKE IT REAL
Veracode
Acquired funding and launched Veracode in 2006
Started as Chief Scientist
Now also Chief Innovation Officer
Initial author of the Veracode Static Binary Analyzer
Architect for Veracode Mobile, iOS platform lead

9. The Effects Of Time
How Dil Lost His Hair

10. T+0 YEARS
Job Title: Programmer
Publications: None
Motivation: Get a job,
figure out what’s going on
Hair: Brown, Sassy, Side-Part

11. T+5 YEARS
Job Title: Hacker
Publications: Advisories,
password auditing tools, etc.
Motivation: Get in the
media as much as possible.
Hair: Unix Sysadmin

12. T+10 YEARS
Job Title: Security Researcher
Publications: Binary analysis
software
Motivation: Do something
impossible
Hair: Receding Muppet Blue

13. T+15 YEARS
Job Title: Chief Scientist
Publications: Mobile software
analyzer, speaking, the
occasional 0-day
Motivation: Improve the state
of the industry
Hair: Migrating to ears/nose

14. YOUR FATE IS NOT SEALED
These changes are not just due to time,
many are consequences of decisions we have chosen to make.
I’ve made certain choices,
you will likely make completely different ones.
Only through introspection can we answer the question:
How do we build a better hacker manager?
Management was never my intention, but a consequence of valuing the
implementation of my own ideas. It had to happen.

15. The Growth Of The
Security Industry
How Time Is Shaping Us

16. TIMELINE
Physical Security (Since the beginning of recorded history)
Gestation Period for the Internet And Computers (1960-1980)
Computer Security Gets Real: The Morris Worm (1988)
Network Security (1990-2000)
The @stake Effect (2000-2004)
Security Architecture (2005-2010)
(Big) Data Security and Application Security (2010-Today)

17. OPERATIONAL MODELS
Consultancy / Boutique
Pure manual services
Tech-assisted manual services
Pen Testing, Architecture review
Product Sales
Developer/SDLC
Enterprise Targeted
End-User Targeted
Infrastructure
Enterprise
Security Department
Security on IT Team
Security QA for Engineering
Software As A Service
Recurring revenue model
Full automation
Outsourced Security

18. How Do We Define
Success?
Business v.s. Personal

19. BUSINESS SUCCESS FACTORS
Shareholder Value
Market Leadership
What these have in common is: accurate and frequent measurement
“You can’t improve what you can’t measure”
Stability And Predictability

20. HEIGHTOFLINE
DISTANCE FROM LEFT

21. EXIT STRATEGY
Run Out Of Money
Angry VCs
Sad founders
Fire sale of everything
Start applying for dumb job
Build Quick
Little to no investment
Sell early
Time is right, get lucky
Tight timeframe
Long Haul
Long term multiple round investment
Weathering the storm
Get mature
Go public or get bought
“Lifestyle Company”
Long term multiple round investment
Slow drain on personal money
Remain private, die old
Go public, die old
Survive and transfer company
through nepotism.

22. PERSONAL SUCCESS FACTORS

23. PERSONAL GOALS
What motivates you? Why are you doing this?
Altruism? Money? Fame? Boredom? Ego?
Do you like your job?
Where do you want to be in 5, 10, 15 years?
And once you do get some money, how are you going to
not act like one of those ‘people with money’?
Getting famous sounds like a good idea
but once you’re famous, it’s quite hard to turn that into money.

24. WHAT IS GOOD ENOUGH?
Success is different for everyone, but we tend to agree
that money != happiness. As money can be an enabler for
future success, it is a reasonable goal.
I tend to think that happiness is a requirement to build
wealth, as the fortitude required to grow your career
requires that you LOVE what you are doing.
What is good enough?
Is there a perfect job/role/project?

25. SCHOOL?
Gotta get a job eventually.
If you don’t want to do security for a living, feel free to skip this
section. My guess is if you’re here, you care.
If you hack all the time you will get bad grades.
This is not all bad, but may have unintended consequences.
Graduate.
Chances are you are not Steve Jobs or Bill Gates.
Nothing looks worse than someone
who can’t finish what they started.

26. The Effect Of Hacker
Culture On Companies
Side-Effects, Intentional And Not

27. SKEPTICISM
Healthy
“Prove to me that you’ve done some work securing that machine
before we put it out on the Internet.”
Unhealthy
“Everyone has faults. It is only a matter of time before I discover
yours, and exploit it, leaving you a powerless pariah to your
occupation.”

28. PARANOIA
Healthy
“We should conduct full security reviews of the software with each
quarterly release, and automated reviews with every minor
release.”
Unhealthy
“I think the Sales and Marketing team have it out for the
Engineering team.”

29. MAKER ETHICS
Independence
One good engineer or security expert or consultant can make all
the difference working on his/her own.
Idea generation / IP Factory
New product ideas come from good brainstorming and careful
attention to detail.

30. ENCOURAGING HACKER CULTURE
Google Time
20% of employees time is spent on non-work projects, many of
which end up benefiting Google.
Hackathons
~3 day ‘hacking runs’ where all work projects are stopped and
people work on non-work ideas, some work related, some not
work related and share them with the company.
Security Awareness Training
People with the awareness shouldn’t be afraid to speak up. We
tend to be condescending toward the teeming clueless masses. We
should at least show them how to evolve.

31. ROLE PROGRESSION
Individual Contributor
Project Lead
Middle Management
Executive Management
Founders, CEOs, and Board Members “oh my”
Beware The Peter Principle

32. The Ten Commandments
Of Hacker Management
Management Survival Tips

33. RULE #1
Thou shalt appear presentable,
approachable, and kind.
Appearance, it matters. Your first impression matters.
A good manager avoids the troll-under-the-bridge
image that we tend to embrace as hacker ‘outsiders’.

34. RULE #2
Thou shalt be a good team leader
and a good individual contributor.
Make the team better than the sum of their parts,
else why are you there at all?

35. RULE #3
Thou shalt prioritize the team you are on,
rather than the team you lead.
When forced to prioritize, you should focus on supporting
the team(s) you are on. Being a leader comes second to
being a good contributor, since you should not be afraid to
delegate to the best of your direct reports.

36. RULE #4
Thou shalt in be inclusive of many skillsets
and expertise in your organization.
It takes all kinds of people.
Surrounding yourself with really smart people
all the time guarantees that the
‘boring work’ will never get done.

37. RULE #5
Thou shalt embrace time and
project management techniques.
We love to take on impossible projects that take an infinite
amount of time, don’t we? Do not bite off more than you
can chew. You are not invincible. Keeping your team all
together with tools will keep your schedules realistic.

38. RULE #6
Thou shalt not depend on
‘rock stars’ and ‘hero coders’.
We love to take on impossible projects that take an infinite
amount of time, don’t we? Do not bite off more than you
can chew. You are not invincible. Keeping your team all
together with tools will keep your schedules realistic.

39. RULE #7
Thou shalt embrace process.
Learn Agile, Scrum and all that other shit.
Get with Kanban, learn some tools to help you with it.
Get religion around process.
The best departments have a ‘single point of entry’ for
communications with people outside the department.
Think ‘abstraction barrier’ not ‘silo’.

40. RULE #8
Thou shalt not require perfection,
for it is the mortal enemy
of ‘good enough’.
Raising the bar is what our industry is all about. If you think
you’re going to ‘win’ or ‘catch the bad guy’ you’re not
thinking this through. Same goes for your projects, and your
interactions with your team.
Recognize ‘good enough’ when you see it.

41. RULE #9
Thou Shalt Trust But Verify
Give people a chance to do the right thing.
Security people tend to turn into micro-managers.
That doesn’t mean that work should be accepted
without review, but let people do their job, dammit!

42. RULE #10
Thou shalt give feedback well,
and take feedback even better.
Management isn’t easy, because personalities
and interpersonal relationships are hard.
It’s about giving and receiving feedback. Hackers don’t necessarily
like criticism from people that don’t know their stuff.
So, know your stuff, know how to give feedback
and be a good hacker manager.

43. THANK YOU
FOR YOUR TIME, ENJOY BSIDES!