Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Success Strategies for
Software Security Programs
@BankimTejani
#LASCON2013
Thursday, 24 October, 2013

1
Background
Began career as a software developer
Transitioned to information security & software security
Worked to establi...
Scoping
Compliance
Triage
Incident response
Punishing development
teams
Magic tools you can buy

Thursday, 24 October, 201...
Success Strategies
Developer Education & Learning
Software Security Roadmap
Integration to Development Teams’ SDLC(s)
Use ...
Developer Education

Thursday, 24 October, 2013

5
Developer Education
Security is an afterthought in developer education
Top curriculums still treat security as advanced to...
Training Options
Formats
Computer-based training
In-person lecture courses
In-person workshops
Lunch & Learn
Tribal

Thurs...
Case Study: Learning
Org 1

Org 2

Mandatory CBT
awareness training
1 developer per team
received in person
technical trai...
Case Study: Learning
Org 1

Org 2

Development continued as
normal

Fixed 10x the requested
number of issues

Few issues g...
Developer Education Tips
Must have buy-in from
management

Vendors can help, but
choose wisely

Invest in everyone, not
su...
Software Security Roadmap

Thursday, 24 October, 2013

11
Software Security Roadmap
Year 1

Year 2

Year 3

SQL Injection

Race conditions

Error handling

XSS

Unreleased resource...
Software Security Roadmap
Identify & communicate software security goals
Make security a planned requirement
Empower & rew...
Case Study
Org 1
Identified 3 top issues for
year 1, based on prior
audits & incidents
Prioritized future years, as
a rough...
Case Study
Org 1
Significant drop in key
issues
Top development teams
planned ahead, got
rewarded
Trained developers only
o...
Roadmap Tips
Must have buy-in from management
One roadmap isn’t likely to fit all teams & app types
Negotiation is a good t...
Integration to SDLC(s)

Thursday, 24 October, 2013

17
Integration to SDLC(s)
Software security is an ex post facto activity
SDLCs are methodologies that aim to make software
de...
Secure SDLC Activities

Thursday, 24 October, 2013

19
SDLC Integration Tips
Treat security changes and
features as product
requirements
Business priorities drive
SDLCs, so secu...
Use Tools Effectively

Thursday, 24 October, 2013

21
Use Tools Effectively
Software security tools:
Static analysis

Ability to find vulnerabilities
greatly exceeds the ability...
Tool Selection & Usage
Software Security Roadmap should drive selection criteria
Different software stacks often require di...
Case Study
Team A
Had quality-centric static
analysis in place
Forced to adopt a
security-centric static
analysis tool
Was...
Tool Tips
Vendors are neither friend
nor foe
Tune settings and results to
fit your roadmap & SDLC
Automation is often more
...
Join the Development Team!

Thursday, 24 October, 2013

26
Join the Development Team!
Core concept of DevOps, Rugged models
Move security from corporate function to a development te...
Lessons Learned
Prioritizing is a continuous balancing act
Credibility improves when you’re a peer, not oversight
Security...
Questions?
@bankimtejani, #lascon2013
bankim.tejani@owasp.org
Thursday, 24 October, 2013

29
Upcoming SlideShare
Loading in …5
×

5 Proven Success Strategies for your Software Security Program - LASCON 2013

579 views

Published on

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.

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

5 Proven Success Strategies for your Software Security Program - LASCON 2013

  1. 1. Success Strategies for Software Security Programs @BankimTejani #LASCON2013 Thursday, 24 October, 2013 1
  2. 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. 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. 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. 5. Developer Education Thursday, 24 October, 2013 5
  6. 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. 7. Training Options Formats Computer-based training In-person lecture courses In-person workshops Lunch & Learn Tribal Thursday, 24 October, 2013 7
  8. 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. 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. 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. 11. Software Security Roadmap Thursday, 24 October, 2013 11
  12. 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. 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. 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. 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. 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. 17. Integration to SDLC(s) Thursday, 24 October, 2013 17
  18. 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. 19. Secure SDLC Activities Thursday, 24 October, 2013 19
  20. 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. 21. Use Tools Effectively Thursday, 24 October, 2013 21
  22. 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. 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. 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. 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. 26. Join the Development Team! Thursday, 24 October, 2013 26
  27. 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. 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. 29. Questions? @bankimtejani, #lascon2013 bankim.tejani@owasp.org Thursday, 24 October, 2013 29

×