This document discusses software security and outlines a 4 step plan to improve it. It begins by recommending studying successful security initiatives at other companies. The second step is to inventory your own applications to understand what data and services they involve. The third step is to incorporate security practices into agile development processes and use tools to help scale this. The final step is to drive a security-focused culture change and have plans for incident response.

1. Who Owns
Software
Security?
Tim Buntel
@tbuntel

2. (obligatory)
About
Me
Smarter
in
the
City

3. 2010 2013
Injection1
Injection
Broken Auth & Session
Mgmt2
Cross Site Scripting
(XSS)
Cross Site Scripting
(XSS)
3
Broken Auth & Session
Mgmt
Insecure Direct Obj
References
4
Insecure Direct Obj
References
h2p://starwars.wikia.com/

4. Applica<on
Security
Risks,
Frozen
in
Time
OWASP
Top
10
–
2010
(old)
OWASP
Top
10
–
2013
(New)
2010-­‐A1
–
InjecCon
2013-­‐A1
–
InjecCon
2010-­‐A2
–
Cross
Site
ScripCng
(XSS)
2013-­‐A2
–
Broken
AuthenCcaCon
and
Session
Management
2010-­‐A3
–
Broken
AuthenCcaCon
and
Session
Management
2013-­‐A3
–
Cross
Site
ScripCng
(XSS)
2010-­‐A4
–
Insecure
Direct
Object
References
2013-­‐A4
–
Insecure
Direct
Object
References
2010-­‐A5
–
Cross
Site
Request
Forgery
(CSRF)
2013-­‐A5
–
Security
MisconfiguraCon
2010-­‐A6
–
Security
MisconfiguraCon
2013-­‐A6
–
SensiCve
Data
Exposure
2010-­‐A7
–
Insecure
Cryptographic
Storage
2013-­‐A7
–
Missing
FuncCon
Level
Access
Control
2010-­‐A8
–
Failure
to
Restrict
URL
Access
2013-­‐A8
–
Cross-­‐Site
Request
Forgery
(CSRF)
2010-­‐A9
–
Insufficient
Transport
Layer
ProtecCon
2013-­‐A9
–
Using
Known
Vulnerable
Components
(NEW)
2010-­‐A10
–
Unvalidated
Redirects
and
Forwards
(NEW)
2013-­‐A10
–
Unvalidated
Redirects
and
Forwards
3
Primary
Changes:
§ Merged:
2010-­‐A7
and
2010-­‐A9
-­‐>
2013-­‐A6
§ Added
New
2013-­‐A9:
Using
Known
Vulnerable
Components
§ 2010-­‐A8
broadened
to
2013-­‐A7
renamed
combined

5. BIG PROBLEM?
At least 1Billion records of PII were leaked in 2014

6. Still! Breaches by SQLi into 2015
3rd most common attack
type (after DDoS and
Malware)

7. Do you scan
your apps for
cybersecurity
vulnerabilities
before making
them available?
No
40%
How much do
you budget
towards securing
mobile apps
built for
customers?
$0

8. FIX THE DAMNED SOFTWARE!

9. “It seems that
application security is
just not considered to
be as important as
network security, even
though vulnerabilities in
applications are
consistently being
exploited by hackers of
all types in order to
access network
resources and data.” Michael Cobb in SearchSecurity

10. Why?
Time
to
market
Training
Cost
Tools
Agile

11. Time to Market
Duh.
Are You Under Pressure to Release New
Applications Faster, and Why?
Yes, Customer demand
Yes, Competitive actions
Yes, Revenue shortfalls
No
Sorry, I was just f*&%ing with you, it’s YES
60%
60%
19%
6%
6%

12. Training? What Training?
No "secure development
lifecycle" in the vast majority of
universities' degree program
How many years of software
development experience do
you have?
>12 years!
34%
4-12 years!
30%
How much previous application
security training have you
received?
None
30%
<1 day
20%
>3 days
25%
1-3 days
25%

13. No Tools?

14. Problematic Tools
$$
“Security Team”
vs

15. New Tools?
• Endpoint profiling
• Endpoint forensics
• Network forensics
• “Secure” platforms

16. LOCK THE DAMNED DOOR!

17. Agile?
h2p://www.expertprogrammanagement.com/
Pen Testing
DAST
Enterprise
SAST
Network
protection

18. But I don’t have anything worth
hacking!
PII
VC$ Consulting
Acquisition

19. But enough about the
problems…
The Quality Metaphor

20. QA
Quality Then

21. Quality Today
• Patterns, frameworks, and good
design
• Do it early, do it often (and automate
it)
• High quality people make high quality
software
• It’s everyone’s responsibility
Doing it right is actually quicker in the end!

22. GOOD SOFTWARE IS SECURE.
SECURE SOFTWARE IS GOOD SOFTWARE.

23. Your
4
Step
Plan!
YOUR 4 STEP PLAN
1. Study successes
2. Inventory yourself
3. Make it agile
4. Drive the culture

24. Describes
software
security
initiatives at
67 well-
known
companies
https://www.bsimm.com
1
Study Successes

25. 112 activities organized in twelve practices
1

26. 1
Study Successes
• Java
• Node
• Rails
• .NET
failures

27. Know your stack!
Your Code
Frameworks
Languages
Third Party Services
OSS
“Technical
debt”
2

28. Know your app
• Store a password
• Login a user
• Upload a photo
• Display user contributed content
• Concatenate strings
• What’s secret? Credentials for DB access,
machine accts, etc. – “Principle of Least
Privilege”
What data is moving where?
2

29. Agile Quality == Agile Security
Add
security to
your
“definition
of done”
3

30. Tools (help) scale the process
“Incorporate static analysis into the code review
process in order to make code review more efficient
and more consistent.”
3
IDE’s with
“checkers”
“Near-real-
time” tools
Build tools
IntelliJ
Klocwork, Codiscope,
Coverity
Brakeman

31. Culture; the toughest part
1. Even a little security
is better than none.
Don't wait for a “big
initiative”
2. Don’t make security
a “special event”
3. Get trained! Train
Champions.
4. Have a plan for
when something
does go wrong
4

32. GOOD SOFTWARE IS SECURE.
SECURE SOFTWARE IS GOOD SOFTWARE.

33. Thanks!
tim@buntel.com
@tbuntel
www.codiscope.com