Rolling Out An Enterprise Source Code Review Program


Published on

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.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Rolling Out An Enterprise Source Code Review Program

  1. 1. Rolling Out an Enterprise Source Code Review Program Dan Cornell
  2. 2. Agenda • Background • How Not To Do It • Technology Concerns • People and Process Concerns • Questions 1
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Dynamic, Static and Manual Testing
  9. 9. Components 8
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. Questions / Contact Information Dan Cornell Twitter: @d i l T itt @danielcornell ll (210) 572-4400 Web: W b d i Blog: 19