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

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


ScopingCompliance

Triage

Incident response

Punishing development teams

Magic tools you can buy

Proactive iterative improvement

Repeatability & predictability

Empowering development

Hardened software

Using tools effectively


Success Strategies

Developer Education & Learning

Software Security Roadmap

Integration to Development Teams’ SDLC(s)

Use Tools Effectively

Join the Development Team


Developer Education


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


Training OptionsFormats

Computer-based training

In-person lecture courses

In-person workshops

Lunch & Learn

Tribal


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


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


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




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



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


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


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


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


Integration to SDLC(s)


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


Secure SDLC Activities


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


Use Tools Effectively


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


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


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


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


Join the Development Team!


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


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


Questions?@bankimtejani, #[email protected]


mailto:[email protected]

mailto:[email protected]