Tracking the Progress of an SDL ProgramLessons from the Gym<br />Cassio Goldschmidt<br />June 29th, 2009<br />
Introduction<br />2<br />
Who am I?<br />Cassio Goldschmidt<br />Sr. Manager, Product Security<br />Chapter Leader, OWASP Los Angeles<br />Education...
Typical Project Lifecycle<br />4<br />DESIGN<br />CODE<br />TEST<br />SUPPORT<br />
How your workout looks like<br />5<br />May 13th Workout<br />Exercise: Pile Squat<br />Repetitions: 35<br />Weight: 20 lb...
How your METRICS should look like<br />6<br />May 13thSec. Metrics<br />Exercise type:<br />CWE<br />Exercise: Pile Squat<...
How your METRICS should look like<br />7<br />May 13thSec. Metrics<br />Number of Reps:<br />Number of Findings<br />CWE: ...
How your METRICS should look like<br />8<br />May 13thSec. Metrics<br />Exercise Intensity:<br />CVSS<br />CWE: 79 - XSS<b...
How your METRICS should look like<br />9<br />May 13thSec. Metrics<br />CWE: 20 – Input Val<br />Findings: 1<br />CVSS: 8....
Common Weakness Enumeration<br />
Common Weakness EnumerationWhat is it?<br />A common language for describing software security weaknesses<br />Maintained ...
Common Weakness EnumerationPortion of CWE structure<br />12<br />
Common Weakness EnumerationWhat data is available for each CWE?<br />Weakness description<br />Applicable platforms and pr...
Common Weakness Enumeration How useful is this information?<br />14<br />Pie Chart showing the frequency of CWEs<br />foun...
Common Vulnerability Scoring System<br />
Objective (and “perfect enough”) metric<br />A universal way to convey vulnerability severity<br />Can be used for competi...
17<br />Common Vulnerability Scoring System (CVSS)BASE Vector<br />Exploitability<br />Impact<br />Sample Score: 7.5<br />...
18<br />Common Vulnerability Scoring System (CVSS)The Calculator<br />
Training and Metrics. <br />
Training and MetricsA special activity in the SDL<br />20<br /><ul><li>Security training is what food is to a workout
Same workout metrics do not apply
Quality of your intake affects overall performance
Staff needs ongoing training</li></li></ul><li>Training and Metrics Security Learning Process<br />21<br />
Training and Metrics Security Learning Process<br />22<br />Understand who is the audience<br /><ul><li> Previous knowledg...
 Programming languages in use
 Supported platforms
 Type of product</li></li></ul><li>Training and Metrics Security Learning Process<br />23<br />Train everyone involved in ...
 QA: Security Testing, Tools
 Managers: Secure Development Lifecycle (also known as Symmunize)</li></li></ul><li>Training and Metrics Security Learning...
Upcoming SlideShare
Loading in …5
×

Tracking the Progress of an SDL Program: Lessons from the Gym

1,096 views

Published on

This presentation is from the 29 June 2009 OWASP Minneapolis-St. Paul (MSP) chapter meeting.

Cassio Goldschmidt of Symantec talked about defining consistent metrics for tracking security vulnerabilities throughout the security development lifecycle.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,096
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Forcing muscle growth is a long process which requires high intensity weight training and high mental concentration. While the ultimate goal is often clear, one of the greatest mistakes bodybuilders consistently make is to overlook the importance of tracking their weight lifting progress.  Like a successful bodybuilding workout, a security development lifecycle program must consistently log simple to obtain, yet meaningful metrics throughout the entire process. Good metrics must lack subjectivity and clearly aid decision makers to determine areas that need improvement. In this pragmatic presentation we’ll discuss metrics used at Symantec, the world’s largest security ISV, to classify and appropriately compare security vulnerabilities found in different phases of the SDL by different teams working in different locations and in different products. We’ll also discuss how to easily provide decision makers different views of the same data and verify whether the process is indeed catching critical vulnerabilities internally and how the numbers compare with the competition.
  • Cassio Goldschmidt is senior manager of the product security team under the Office of the CTO at Symantec Corporation. In this role he leads efforts across the company to ensure the secure development of software products. His responsibilities include managing Symantec’s internal secure software development process, training, threat modeling and penetration testing. Cassio’s background includes over 13 years of technical and managerial experience in the software industry.  During the seven years he has been with Symantec, he has helped to architect, design and develop several top selling product releases, conducted numerous security classes, and coordinated various penetration tests. Cassio is also internationally known for leading the OWASP chapter in Los Angeles.Cassio represents Symantec on the SAFECode technical committee and (ISC)2 in the development of the CSSLP certification. He holds a bachelor degree in computer science from PontificiaUniversidadeCatolica do Rio Grande Do Sul, a masters degree in software engineering from Santa Clara University, and a masters of business administration from the University of Southern California.
  • Tracking the Progress of an SDL Program: Lessons from the Gym

    1. 1. Tracking the Progress of an SDL ProgramLessons from the Gym<br />Cassio Goldschmidt<br />June 29th, 2009<br />
    2. 2. Introduction<br />2<br />
    3. 3. Who am I?<br />Cassio Goldschmidt<br />Sr. Manager, Product Security<br />Chapter Leader, OWASP Los Angeles<br />Education<br />MBA, USC<br />MS Software Engineering, SCU<br />BS Computer Science, PUCRS<br />Certified Software Sec. Lifecycle Professional – CSSLP, (ISC)2<br />When I’m not in the office…<br />Volleyball (Indoor, Beach)<br />Coding<br />Gym…<br />3<br />
    4. 4. Typical Project Lifecycle<br />4<br />DESIGN<br />CODE<br />TEST<br />SUPPORT<br />
    5. 5. How your workout looks like<br />5<br />May 13th Workout<br />Exercise: Pile Squat<br />Repetitions: 35<br />Weight: 20 lbs<br />Exercise: Barbell Squat<br />Repetitions: 35<br />Weight: 150 lbs<br />Exercise: Rev. Curl<br />Repetitions: 20<br />Weight: 25 lbs<br />
    6. 6. How your METRICS should look like<br />6<br />May 13thSec. Metrics<br />Exercise type:<br />CWE<br />Exercise: Pile Squat<br />Repetitions: 35<br />Weight: 20 lbs<br />Exercise: Barbell Squat<br />Repetitions: 35<br />Weight: 150 lbs<br />Exercise: Rev. Curl<br />Repetitions: 20<br />Weight: 25 lbs<br />
    7. 7. How your METRICS should look like<br />7<br />May 13thSec. Metrics<br />Number of Reps:<br />Number of Findings<br />CWE: 79 - XSS<br />Repetitions: 35<br />Weight: 20 lbs<br />Exercise: Barbell Squat<br />Repetitions: 35<br />Weight: 150 lbs<br />Exercise: Rev. Curl<br />Repetitions: 20<br />Weight: 25 lbs<br />
    8. 8. How your METRICS should look like<br />8<br />May 13thSec. Metrics<br />Exercise Intensity:<br />CVSS<br />CWE: 79 - XSS<br />Findings: 10<br />Weight: 20 lbs<br />Exercise: Barbell Squat<br />Repetitions: 35<br />Weight: 150 lbs<br />Exercise: Rev. Curl<br />Repetitions: 20<br />Weight: 25 lbs<br />
    9. 9. How your METRICS should look like<br />9<br />May 13thSec. Metrics<br />CWE: 20 – Input Val<br />Findings: 1<br />CVSS: 8.6<br />DESIGN<br />Threat Model<br />CWE: 79 - XSS<br />Findings: 3<br />CVSS: <br />TEST<br />Pen Test<br />CWE: 314<br />Findings: 1<br />CVSS: 2.3<br />Support<br />Vul. Mgmt<br />
    10. 10. Common Weakness Enumeration<br />
    11. 11. Common Weakness EnumerationWhat is it?<br />A common language for describing software security weaknesses<br />Maintained by the MITRE Corporation with support from the National Cyber Security Division (DHS). <br />Hierarchical<br />Each individual CWE represents a single vulnerability type<br />Deeper levels of the tree provide a finer granularity<br />Higher levels provide a broad overview of a vulnerability<br />11<br />
    12. 12. Common Weakness EnumerationPortion of CWE structure<br />12<br />
    13. 13. Common Weakness EnumerationWhat data is available for each CWE?<br />Weakness description<br />Applicable platforms and programming languages<br />Common Consequences<br />Likelihood of Exploit<br />Coding Examples<br />Potential Mitigations<br />Related Attacks<br />Time of Introduction<br />Taxonomy Mapping<br />13<br />Link to CWE Page on XSS<br />
    14. 14. Common Weakness Enumeration How useful is this information?<br />14<br />Pie Chart showing the frequency of CWEs<br />found in penetration tests<br />
    15. 15. Common Vulnerability Scoring System<br />
    16. 16. Objective (and “perfect enough”) metric<br />A universal way to convey vulnerability severity<br />Can be used for competitive analysis<br />CVSS score ranges between 0.0 and 10.0<br />Can be expressed as high, medium, low as well<br />Composed of 3 vectors<br />Base<br />Represents general vulnerability severity: Intrinsic and immutable<br />Temporal<br />Time-dependent qualities of a vulnerability<br />Environmental<br />Qualities of a vulnerability specific to a particular IT environment<br />16<br />Common Vulnerability Scoring System (CVSS)What is it?<br />
    17. 17. 17<br />Common Vulnerability Scoring System (CVSS)BASE Vector<br />Exploitability<br />Impact<br />Sample Score: 7.5<br />Sample Vector: (AV:N/AC:L/Au:N/C:P/I:P/A:P)<br />Every CVSS score should be accompanied by the corresponding vector<br />
    18. 18. 18<br />Common Vulnerability Scoring System (CVSS)The Calculator<br />
    19. 19. Training and Metrics. <br />
    20. 20. Training and MetricsA special activity in the SDL<br />20<br /><ul><li>Security training is what food is to a workout
    21. 21. Same workout metrics do not apply
    22. 22. Quality of your intake affects overall performance
    23. 23. Staff needs ongoing training</li></li></ul><li>Training and Metrics Security Learning Process<br />21<br />
    24. 24. Training and Metrics Security Learning Process<br />22<br />Understand who is the audience<br /><ul><li> Previous knowledge about secure coding and secure testing
    25. 25. Programming languages in use
    26. 26. Supported platforms
    27. 27. Type of product</li></li></ul><li>Training and Metrics Security Learning Process<br />23<br />Train everyone involved in the SDL<br /><ul><li> Developers: Secure Coding, Threat Model
    28. 28. QA: Security Testing, Tools
    29. 29. Managers: Secure Development Lifecycle (also known as Symmunize)</li></li></ul><li>Training and Metrics Security Learning Process<br />24<br />Quality Assurance - Capture the flag<br /><ul><li> Use Beta software
    30. 30. Approximately 3 hours long
    31. 31. Top 3 finders receive prizes and are invited to explain what techniques and tools they used to find the vulnerabilities to the rest of the group</li></li></ul><li>Training and Metrics Security Learning Process<br />25<br />Pos Class Survey<br /><ul><li> Anonymous
    32. 32. Metrics
    33. 33. Class content
    34. 34. Instructor knowledge
    35. 35. Exercises </li></li></ul><li>Training and Metrics Security awareness is more than training<br />26<br />Knowledge Sharing Activities<br />Tech Exchanges<br />Cutting Edge<br />CTO Newsletter Articles<br />
    36. 36. Conclusions and final thoughts<br />
    37. 37. Why This Approach Makes Sense?<br />28<br />DESIGN<br />CODE<br />TEST<br />SUPPORT<br /><ul><li>Compare Apples to Apples
    38. 38. Quantify results in a meaningful way to “C” executives
    39. 39. Past results can be used to explain impact of new findings
    40. 40. Can be simplified to a number from 1-10 or semaphore (green, yellow and red).
    41. 41. Can be used for competitive analysis
    42. 42. Harder to game CVSS
    43. 43. CWE can be easily mapped to different taxonomies</li></li></ul><li>Thank You!<br />Cassio Goldschmidt<br />cassio_goldschmidt@symantec.com<br />cassio@owasp.org<br />Copyright © 2007 Symantec Corporation. All rights reserved.  Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries.  Other names may be trademarks of their respective owners.<br />This document is provided for informational purposes only and is not intended as advertising.  All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law.  The information in this document is subject to change without notice.<br />

    ×