rolling out an enterprise source code review program
DESCRIPTION
Source code review technology has rapidly advanced over the past several years and offers great promise of helping organizations detect and address software security defects. However, many organizations stumble as they try to roll out these technologies because they fail to understand the people and process issues that must also be addressed. This talk will present lessons learned from the creation of several enterprise source code review programs, including: identifying all sources of custom code in an organization including custom extensions to ERP systems and enterprise portals, selecting the first round of applications to scan and successfully interpreting results and driving resolution to identified issues.TRANSCRIPT
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• 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 CornellDan 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 W b ht “XYZ S ”• A: We bought “XYZ Scanner”
• 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?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 requirementsAddress software risk– Address software risk
• Keep in Mind– Compliance != Security– “Checkbox” mentality– Checkbox mentality– Look for opportunities to leverage compliance budget to increase actual security
4
Initial Considerations• Every organization is different
– Development practices: Agile, waterfall, cowboy-codeControl environment: Security IT audit compliance– Control environment: Security, IT audit, compliance
– 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• 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 t fi d i l t d t ti l d l t i t– Will not find issues related to operational deployment environments
Dynamic, Static and Manual Testing
Components
8
Technology• Majority of the focus tends to be here
– For better or for worse
Wh t l i t?• What languages require support?– Java, .NET, C/C++, PHP, Python, Ruby, Perl, Smalltalk, COBOL, etc
• What application architectures are supported?W b b i thi k li t t ft– Web, web services, thick-client, system software
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 ForgetERP d l t ft t i t d th t h l biliti– ERP deployments often contain custom code that can have vulnerabilities
– Portal deployments (SharePoint) also often have custom code
10
Before You Select Technologies?• Questions
– Who will run the tool?When will it be run?– 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– It won t be used– 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 TeamDevelopment 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 workstationsContinuous integration– Continuous integration
– Integrated into nightly build– Prior to the end of an iteration or release
• Keep in MindKeep 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
S M t B M ll R i d• Scans Must Be Manually Reviewed– 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 setSubset of the standard rule set (often based on compliance requirements)– Subset of the standard rule set (often based on compliance requirements)
• Are Custom Rules Used?– Organization-wide– Per-application– Per-application
15
What Gets Fixed?• Common Options
– Everything (yeah, right)Tool based standard (“All HOT and MEDIUM level issues”)– Tool-based standard ( All HOT and MEDIUM level issues )
– Negotiated between development and security teams: “Risk Poker”
• Keep in Mind– Finding the vulnerabilities is only the first step– 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 deploymentExpand from there– Expand from there
• Strategies– Riskiest applications first– Compliance mandates first (or only)– 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 issuesOften done by team leads but do they have specific security guidance– Often done by team leads – but do they have specific security guidance
• Integrating Source Code Review With Dynamic Assessments
18
Questions / Contact InformationDan [email protected] itt @d i l llTwitter: @danielcornell(210) 572-4400
W b d iWeb: www.denimgroup.comBlog: denimgroup.typepad.com
19