Success Strategies for Software Security Programs@BankimTejani#LASCON2013
1Thursday, 24 October, 2013
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
2Thursday, 24 October, 2013
ScopingCompliance
Triage
Incident response
Punishing development teams
Magic tools you can buy
Proactive iterative improvement
Repeatability & predictability
Empowering development
Hardened software
Using tools effectively
3Thursday, 24 October, 2013
Success Strategies
Developer Education & Learning
Software Security Roadmap
Integration to Development Teams’ SDLC(s)
Use Tools Effectively
Join the Development Team
4Thursday, 24 October, 2013
Developer Education
5Thursday, 24 October, 2013
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
6Thursday, 24 October, 2013
Training OptionsFormats
Computer-based training
In-person lecture courses
In-person workshops
Lunch & Learn
Tribal
7Thursday, 24 October, 2013
Case Study: LearningOrg 1
Mandatory CBT awareness training
1 developer per team received in person technical training on generic code
Org 2
All developers received in person technical training
Their application was the primary code used
Specific focus on fixing top issues in their code
8Thursday, 24 October, 2013
Case Study: LearningOrg 1
Development continued as normal
Few issues got fixed
Relied on security to tell them what to do
Org 2
Fixed 10x the requested number of issues
Proactively identified problem areas and sought help if needed
Re-applied good patterns to new code
9Thursday, 24 October, 2013
Developer Education Tips
Must have buy-in from management
Invest in everyone, not subsets
Commit to follow-up actions
Vendors can help, but choose wisely
Use your own code, where possible
Developers move & change, so refreshers needed
10Thursday, 24 October, 2013
Software Security Roadmap
11Thursday, 24 October, 2013
Software Security RoadmapYear 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 Information leaks
Session related issues API abuse
12Thursday, 24 October, 2013
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
13Thursday, 24 October, 2013
Case StudyOrg 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
Org 2
Actively avoided prioritizing
Crafted a metric weighting vendor-provided criticality
Created arbitrary success line of vulnerability density
14Thursday, 24 October, 2013
Case StudyOrg 1
Significant drop in key issues
Top development teams planned ahead, got rewarded
Trained developers only on current priorities
Org 2
Development teams gamed the system, did minimum
Failed internal audit
Expended too much political capital to re-architect program
15Thursday, 24 October, 2013
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
16Thursday, 24 October, 2013
Integration to SDLC(s)
17Thursday, 24 October, 2013
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
18Thursday, 24 October, 2013
Secure SDLC Activities
19Thursday, 24 October, 2013
SDLC Integration TipsTreat 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
Processes don’t change, they evolve
Every activity must be planned, manageable, and achievable
Opportunity for security team to learn & grow
Trying is succeeding
20Thursday, 24 October, 2013
Use Tools Effectively
21Thursday, 24 October, 2013
Use Tools EffectivelySoftware security tools:
Static analysis
Dynamic analysis
Testing & attack tools
Scanners & checkers
Ability to find vulnerabilities greatly exceeds the ability to fix applications
There are no bad tools
Selecting the right tool for the right job isn’t easy
22Thursday, 24 October, 2013
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
23Thursday, 24 October, 2013
Case StudyTeam 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
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
24Thursday, 24 October, 2013
Tool TipsVendors 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
A quicker feedback cycle is vital to developer productivity
False positives happen, get over it
False negative happen, plan for it
25Thursday, 24 October, 2013
Join the Development Team!
26Thursday, 24 October, 2013
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
27Thursday, 24 October, 2013
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
28Thursday, 24 October, 2013
Questions?@bankimtejani, #[email protected]
29Thursday, 24 October, 2013