Page 1
Dev(Sec)Ops and the Hunter/Farmer model
Fabrizio Zeno Cornelli
CODEMOTION MILAN - SPECIAL EDITION 10 – 11 NOVEMBER 2017
Page 2
Thanks to Randall Munroe: xkcd.com
Page 3
Get a Good Password
$ dd if=/dev/random count=1
| base64 | cut -c1-22
c4EdYgLedpD30qKJ6YAKjQ
Use 128 bit
Page 4
$ gsort -R ˜/dict/words.txt
| head -4 | paste -sd ‘-‘ -
Get a Good Password
Use dictionary
Page 5
11 bits to index words.txt?
128/11 !" 12
Get a Good Password
How many words?
Page 6
Why Password0! Is not good?
Page 7
HOW TO CRACK A PASSWORD
Page 9
How passwords work
stored[user] = hash(password)
hash(password) !" stored[user] $→ auth
Page 10
How to crack a password
Retrieve stored hashes
Deduce hash
Plaintext? Done :
- Bruteforce attack
- Dictionary attack
Page 11
Brute force Attack
Test every single possible password.
From ‘a’ up to ‘ZZZZZZZZ..ZZZ’
Page 12
Dictionary Attack
hash(guess) !" stored $→ (^-^)
$ john stored.txt
Page 13
stored = set(‘abFZSxKKdq5s6’, ‘ulMGRyl03i2gm’ …)
dic = [‘password’, ‘12345’, …]
rules = [‘:’, ‘u’, … ‘so0’, ‘cAz[0-9][!$§]’]
_guesses = jexpand(dic, rules) # [‘password’, ‘PASSWORD’, …, ‘passw0rd’, ‘Password0!’…]
[ g for g in _guesses if hash(g) in stored ]
How to crack a password
Page 16
FABRIZIO [email protected]
Page 17
CV
CTO, Enterprise srl
DEV / QA Manager, HT
Consultant, from 2016
Page 19
DEVELOPER“if it ain’t broke, don’t fix it”
Page 21
Design then code (and test)
Page 22
High level languagesGood PracticesRTFMFrameworks and Libraries
Progra()ing skills (some languages)
Page 23
Don’t reinvent the wheel
Page 24
DRIVEN BY Sense of order Growth Collaboration Planning/OCD issues
Page 25
Dev Proverbs
The ends does not justify the mean
Choose two: good, fast, cheap
Any fool can write code that a computer can understand. Good progra()ers write code that humans can understand. [M. Fowler]
Page 26
HACKER“shit happens”
Page 27
Deconstructive: Reverse Engineer
Page 29
Subvert the manual
Page 30
Shortcut / quick and dirty
Page 31
Must be the first
Page 32
Low level Languages
(C, asm)
Page 33
DRIVEN BY Challenge Showing off Boring issues
Page 34
Hacking Proverbs
the ends justify the means
a clever person solves a problem, a wise person avoids it
a lot goes a shecat to the grease, that she leaves the little arm
Page 35
Comparative table
Deductive Inductive
Deconstructive Constructive
Reverse Engineering Progra()ing skills
Lateral Thinking Good Practice
Shortcut Design then code
Subvert the manual RTFM
Shortcut Frameworks and libs
Incautious Conservative
Low level lang High level lang
Hacker Developer
Page 37
Discipline / Focus
Page 41
Farmer Hunter model
B2B Sales model
Page 42
Hunter focused on creating new sales opportunities, prospecting and closing. “eat what they kill.”
Page 43
Farmer manages and sells to existing relationships. account manager
Page 44
Hunter vs FarmerTake charge Let things develop
Aggressive Laid Back
Prospector Planner
Competitive Collaborative
Always be closing So, what do you think
Individualist Team player
Short term Long term
Risky Safe
Page 45
Hunter vs Farmer
Really a coincidence? Is there any anthropologic root?
Page 46
STONE AGEanthropologic session
Page 47
Small clans
Nomadic
Hunters
Page 48
Resources Developer
Languageand politics
Villages and cities
Farmers
Page 49
Hunter vs Farmer
nomadic / autonomy permanent settlements
innovation tradition
initiative patience
indipendence collaboration
Page 50
Are we changed?
We still “feel” the connection with cats and dogs
Trium Brain theory (Paul MacLean)
Page 51
PALEOLITHIC HUNTER HACKER
Page 52
NEOLITHIC FARMER DEVELOPER
Page 53
Are we Hunters or Farmers?
Both of them
Page 54
Be a hunter get your POC
Page 55
Be a farmer: evolve an idea to a product
Page 56
Make your team
0
20
40
60
80
POC Project Dev Maintain/PT
Hunter Farmer
Page 57
DEVSECOPS“hunter as a service”
Page 58
Defenders cannot win
Page 59
Defenders cannot win
Defending is more difficult
Attackers can abuse any vulnerability
Page 60
Multi Layer defence
Page 61
Multi Layer defence
Defending is expensive
How can I prove that I’m secure?
Page 62
Popper’s refutability
Page 63
Popper’s refutability
the inherent possibility that a statement can be proven false
- Halting problem
- “this system is secure”
Page 64
Popper’s refutability
POSITIVISM
proof $→ true
REFUTABILITY
paradox $→ false
Page 65
DevSecOps’ Refutability
each part should be testable and tested
devsecops is the continuous invalidation process
Page 67
security by obscurity
Page 68
Russell’s inductivist turkey PART 1
Page 69
Russell’s inductivist turkey PART 2
Page 71
Hiring
“I’m looking for a hacker”
“We need a developer”
Page 72
Hiring
You have a few hours to match
Does your candidate fits your job needs?
Does your job appeal to the candidate?
Is your candidate a person or a resource?
Page 74
1,2,3,4,5?
That's amazing! I've got the same combination on my luggage.
Page 75
Thanks
Fabio Sangiovanni
Mariachiara Pezzotti
Federico Gandellini
Luciano Colosio
Page 76
THANK YOUhacked potato for you
(no animal was harmed in the making of this presentation)