Rolling Out an Enterprise
Source Code Review Program
Dan Cornell

Agenda
• Background
• How Not To Do It
• Technology Concerns
• People and Process Concerns
• Questions
1

Background
• Denim Group
– Develop Secure Software
• Ground Up Development
• Software Security Remediation
– Help Organizations Deal with Software Risk
• Code Review and Application Assessments
• Application Penetration Testing
• Training – Instructor-Led and ThreadStrong eLearning
• Security in the SDLC
• Dan Cornell
– Principal at Denim Group
– Developer by background: Java 2 Certified Programmer, MCSD
– OWASP: Chapter Lead, Global Membership Committee, Open Review Project
2

How Not To Do It
• Q: What are you all doing to address application security concerns in
your organization?
• A: We b
A W bought “XYZ Scanner”
ht S ”
• Q: Okay… Are you actually using it?
• A: We ran some scans
• Q: And how did that go?
• A: Oh we found some stuff…
• Q: How did you address those issues?
• A: I think we sent the report to the developers. Not sure what they did
with them. I guess I ought to check in on that…
3

What Are Your Goals?
• Common Answers
– Meet compliance or regulatory requirements
– Address software risk
• Keep in Mind
– Compliance != Security
– “Checkbox” mentality
Checkbox
– Look for opportunities to leverage compliance budget to increase actual security
4

Initial Considerations
• Every organization is different
– Development practices: Agile, waterfall, cowboy-code
– Control environment: Security IT audit compliance
Security, audit,
– Most important: Organizational values. What is important and how do things get
done?
– Not necessarily “Core Values” but certainly related
• You must overcome resistance
5

Static Analysis: Advantages and Disadvantages
• Advantages:
– Have access to the actual instructions the software will be executing
• No need to guess or interpret behavior
• Full access to all of the software’s possible behaviors
– Speeds remediation – You know exactly where the vulnerabilities are in the code
• Disadvantages:
g
– Require access to source code or at least binary code
• Typically need access to enough software artifacts to execute a build
– Typically require proficiency running software builds
– Will not fi d i
t find issues related t operational d l
l t d to ti l deployment environments
t i t

Dynamic, Static and Manual Testing

Components
8

Technology
• Majority of the focus tends to be here
– For better or for worse
• What l
Wh t languages require support?
i t?
– Java, .NET, C/C++, PHP, Python, Ruby, Perl, Smalltalk, COBOL, etc
• What application architectures are supported?
– W b web services, thi k li t system software
Web, b i thick-client, t ft
9

Where Is All the Code, Anyway?
• Must Know In Order to Define Scope
• How Is Software Developed In Your Organization?
– Centralized development team under IT
– Separate development groups under different lines of business
• Don’t Forget
– ERP d l
deployments often contain custom code th t can h
t ft t i t d that have vulnerabilities
l biliti
– Portal deployments (SharePoint) also often have custom code
10

Before You Select Technologies?
• Questions
– Who will run the tool?
– When will it be run?
– What will be done with the results?
• If you haven’t answered these – you aren’t ready to deploy
– It won t be used
won’t
– Nothing will be done with the results
– You may fool your auditors…
– … but you won’t fool attackers
11

Who Runs the Scans?
• Common Options
– Security Team
– Development Team
– Quality Assurance Team
– Combination
– Outsourced
• Keep in Mind
– Source code scanning tools are not “fire and forget” so effective users need training
– Need to know how each scan will be used
12

When Are Scans Run?
• Common Options
– Developers at their workstations
– Continuous integration
– Integrated into nightly build
– Prior to the end of an iteration or release
• Keep in Mind
– Scans of large applications can take a long time to complete
– Developers may only have a portion of the code on their workstations
– Waiting until late in the process make timely remediation impossible
13

Interpreting Results
• Scanning Tools All Return False Positives
– Except during sales engineer demos
• Scans Must Be Manually R i
S M tB M ll Reviewed
d
– Culling false positives can be time-consuming
– Trained analysts can work through this process pretty quickly
14

Tuning Scans
• What Rules Are Used?
– Standard rule set
– Subset of the standard rule set (often based on compliance requirements)
• Are Custom Rules Used?
– Organization-wide
– Per-application
15

What Gets Fixed?
• Common Options
– Everything (yeah, right)
– Tool based standard (“All HOT and MEDIUM level issues )
Tool-based ( All issues”)
– Negotiated between development and security teams: “Risk Poker”
• Keep in Mind
– Finding the vulnerabilities is only the first step
– Often have to provide guidance to developers on fixing vulnerabilities
16

Incremental Progress
• Scanning Programs Evolve Over Time
– Start with proof-of-concept or limited deployment
– Expand from there
• Strategies
– Riskiest applications first
– Compliance mandates first (or only)
– Require for all new applications, incorporate legacy portfolio over time
– Development group by development group
17

Other Topics
• Manual Code Reviews
– Critical to catch business logic issues
– Often done by team leads – but do they have specific security guidance
• Integrating Source Code Review With Dynamic Assessments
18

Questions / Contact Information
Dan Cornell
dan@denimgroup.com
Twitter: @d i l
T itt @danielcornell
ll
(210) 572-4400
Web:
W b www.denimgroup.com
d i
Blog: denimgroup.typepad.com
19