These proven strategies will help you establish and improve your software security program. They have been accumulated through years of consulting & advising companies and government agencies of all sizes & types on their software security programs. Each strategy will be presented with context of when to apply it, why it works, and why less successful strategies fail.

1. Success Strategies for
Software Security Programs
@BankimTejani
#LASCON2013
Thursday, 24 October, 2013
1

2. Background
Began career as a software developer
Transitioned to information security & software security
Worked to establish software security programs
Trained developers, architects, managers, and security teams
Currently: Senior Security Architect at ServiceMesh
Thursday, 24 October, 2013
2

3. Scoping
Compliance
Triage
Incident response
Punishing development
teams
Magic tools you can buy
Thursday, 24 October, 2013
Proactive iterative
improvement
Repeatability & predictability
Empowering development
Hardened software
Using tools effectively
3

4. Success Strategies
Developer Education & Learning
Software Security Roadmap
Integration to Development Teams’ SDLC(s)
Use Tools Effectively
Join the Development Team
Thursday, 24 October, 2013
4

5. Developer Education
Thursday, 24 October, 2013
5

6. Developer Education
Security is an afterthought in developer education
Top curriculums still treat security as advanced topic
Organizations invest little in skills development
Training can check boxes or teach, but rarely both
Thursday, 24 October, 2013
6

7. Training Options
Formats
Computer-based training
In-person lecture courses
In-person workshops
Lunch & Learn
Tribal
Thursday, 24 October, 2013
7

8. Case Study: Learning
Org 1
Org 2
Mandatory CBT
awareness training
1 developer per team
received in person
technical training on
generic code
Thursday, 24 October, 2013
All developers received in
person technical training
Their application was the
primary code used
Specific focus on fixing
top issues in their code
8

9. Case Study: Learning
Org 1
Org 2
Development continued as
normal
Fixed 10x the requested
number of issues
Few issues got fixed
Proactively identified
problem areas and sought
help if needed
Relied on security to tell
them what to do
Re-applied good patterns
to new code
Thursday, 24 October, 2013
9

10. Developer Education Tips
Must have buy-in from
management
Vendors can help, but
choose wisely
Invest in everyone, not
subsets
Use your own code, where
possible
Commit to follow-up actions
Developers move & change,
so refreshers needed
Thursday, 24 October, 2013
10

11. Software Security Roadmap
Thursday, 24 October, 2013
11

12. Software Security Roadmap
Year 1
Year 2
Year 3
SQL Injection
Race conditions
Error handling
XSS
Unreleased resources
Dead code removal
Web server configuration Additional configuration
Log forging
Other Injections
Session related issues
Thursday, 24 October, 2013
Information leaks
API abuse
12

13. Software Security Roadmap
Identify & communicate software security goals
Make security a planned requirement
Empower & reward teams to be ahead of the curve
Reduce untimely security blockers
Achievable, measurable results
Thursday, 24 October, 2013
13

14. Case Study
Org 1
Identified 3 top issues for
year 1, based on prior
audits & incidents
Prioritized future years, as
a rough draft
Trained developers only
on current priorities
Thursday, 24 October, 2013
Org 2
Actively avoided
prioritizing
Crafted a metric weighting
vendor-provided criticality
Created arbitrary success
line of vulnerability density
14

15. Case Study
Org 1
Significant drop in key
issues
Top development teams
planned ahead, got
rewarded
Trained developers only
on current priorities
Thursday, 24 October, 2013
Org 2
Development teams
gamed the system, did
minimum
Failed internal audit
Expended too much
political capital to rearchitect program
15

16. Roadmap Tips
Must have buy-in from management
One roadmap isn’t likely to fit all teams & app types
Negotiation is a good thing
Roadmap should drive investment in tools & training
Thursday, 24 October, 2013
16

17. Integration to SDLC(s)
Thursday, 24 October, 2013
17

18. Integration to SDLC(s)
Software security is an ex post facto activity
SDLCs are methodologies that aim to make software
development predictable & manageable
Types: Waterfall, Spiral, Agile, Extreme, etc
Empowering security in development necessitates having
security managed in their SDLC
Thursday, 24 October, 2013
18

19. Secure SDLC Activities
Thursday, 24 October, 2013
19

20. SDLC Integration Tips
Treat security changes and
features as product
requirements
Business priorities drive
SDLCs, so security must be
tied to business goals
Requires security to be part
of the development team
Thursday, 24 October, 2013
Processes don’t change,
they evolve
Every activity must be
planned, manageable, and
achievable
Opportunity for security
team to learn & grow
Trying is succeeding
20

21. Use Tools Effectively
Thursday, 24 October, 2013
21

22. Use Tools Effectively
Software security tools:
Static analysis
Ability to find vulnerabilities
greatly exceeds the ability to
fix applications
Dynamic analysis
There are no bad tools
Testing & attack tools
Selecting the right tool for
the right job isn’t easy
Scanners & checkers
Thursday, 24 October, 2013
22

23. Tool Selection & Usage
Software Security Roadmap should drive selection criteria
Different software stacks often require different tools
Empower teams to integrate tools into their SDLC
Structure usage & success around roadmap & training
Thursday, 24 October, 2013
23

24. Case Study
Team A
Had quality-centric static
analysis in place
Forced to adopt a
security-centric static
analysis tool
Wasted time & energy to
implement something with
little tangible gain
Thursday, 24 October, 2013
Team B
Automated static
analysis tool to run with
every weekly build
Re-configured results to
align to agreed roadmap
Measured improvement
against roadmap every
release
24

25. Tool Tips
Vendors are neither friend
nor foe
Tune settings and results to
fit your roadmap & SDLC
Automation is often more
valuable than ease of use
Enable users to quickly go to
actionable items
Thursday, 24 October, 2013
A quicker feedback cycle is
vital to developer
productivity
False positives happen, get
over it
False negative happen, plan
for it
25

26. Join the Development Team!
Thursday, 24 October, 2013
26

27. Join the Development Team!
Core concept of DevOps, Rugged models
Move security from corporate function to a development team
or product function
Requires security teams to contribute to software goals
Take ownership and drive improvements
Thursday, 24 October, 2013
27

28. Lessons Learned
Prioritizing is a continuous balancing act
Credibility improves when you’re a peer, not oversight
Security improvements can happen organically
More vulnerabilities averted at early stages
Opportunities evolved as a result
Thursday, 24 October, 2013
28

29. Questions?
@bankimtejani, #lascon2013
bankim.tejani@owasp.org
Thursday, 24 October, 2013
29