Your SlideShare is downloading. ×
0
Treating Security Vulnerabilities As Software Defects

SANS What Works In AppSec 2010

Friday February 5th, 2010
Agenda
•   Something Most Security Vendors Won’t Tell You
•   The Wrong Way to Do It
•   A More Excellent Way
•   Strategi...
Something Most Security Vendors Won’t Tell You




                                                 2
Something Most Security Vendors Won’t Tell You

Finding Vulnerabilities is Easy

Fixing Vulnerabilities is Valuable




  ...
The Wrong Way to Do It




                         4
The Wrong Way to Do It
Dan: What is your application security strategy
A: We bought Scanner XYZ
Dan: Cool! Have you starte...
Why Is This Bad?
•   PDFs are blobs
•   Email is infinitely ignorable
•   Lumps all vulnerabilities together
•   No guidan...
A More Excellent Way




                       7
A More Excellent Way
• Treat (Application) Security Vulnerabilities as Software Defects

• Why?
   – Developers have to fi...
What Makes a Good Security Defect?




                                     9
What Makes a Good Security Defect?
•   Why do I care?
•   Scope
•   Where is it?
•   How do I fix it?




                ...
Why Do I Care?




                 11
Why Do I Care?
• Do not rely solely on the defect to communicate this
    – Simply pumping defects into the defect trackin...
Scope




        13
Scope
• Defects that take 5 minutes to fix take far longer to administer
    – Especially with mature (elaborate) QA proce...
Where Is It?




               15
Where Is It?
• Providing location information removes a “barrier” to fixing
• Better location information leads to quicker...
How Do I Fix It?




                   17
How Do I Fix It?
• Prescriptive guidance is required here
   – Removes a reason not to fix
   – Leads to consistency
• Doe...
Why Is This Approach Better?
•   Defects are structured data
•   Defects are durable
•   Vulnerabilities have been portion...
Strategies




             20
Strategies
• Group by location
• Group by type
• Group by severity




                      21
Grouping By Location
• By file/URL or by directory
• Pros:
    – Helpful if there is one “owner” for that area of the code...
Grouping By Type
• By vulnerability type (XSS, SQL injection, authorization issue, etc)
• Pros:
    – Similar vulnerabilit...
Grouping By Severity
• High, medium, low
• Pros:
   – Can help you game certain metric programs
• Cons:
   – Least tied to...
Strategies (continued)
• Combine more than one
   – Group by type or severity and then by location




                   ...
What About BIG Issues?
• Serious issues can map to multiple defects
• REALLY serious issues can map to enterprise change m...
What About Non-Software Vulnerabilities?
• Transition to change management systems rather than defect tracking
  systems

...
Demo




       28
Contact
Dan Cornell
dan@denimgroup.com
(210) 572-4400
@danielcornell

Web: www.denimgroup.com
Blog: blog.denimgroup.com
Vu...
Upcoming SlideShare
Loading in...5
×

Treating Security Vulnerabilities As Software Defects

3,570

Published on

Penetration testing and code reviews are useful for identifying software security vulnerabilities, but for these vulnerabilities to actually be fixed they typically must be communicated to developers for remediation. This lunch and learn discusses real-world strategies for bundling security vulnerabilities into software defects and communicating them to development teams for maximum clarity and impact.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,570
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
48
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Treating Security Vulnerabilities As Software Defects"

  1. 1. Treating Security Vulnerabilities As Software Defects SANS What Works In AppSec 2010 Friday February 5th, 2010
  2. 2. Agenda • Something Most Security Vendors Won’t Tell You • The Wrong Way to Do It • A More Excellent Way • Strategies • Demo • Questions? 1
  3. 3. Something Most Security Vendors Won’t Tell You 2
  4. 4. Something Most Security Vendors Won’t Tell You Finding Vulnerabilities is Easy Fixing Vulnerabilities is Valuable 3
  5. 5. The Wrong Way to Do It 4
  6. 6. The Wrong Way to Do It Dan: What is your application security strategy A: We bought Scanner XYZ Dan: Cool! Have you started using it? A: Yes. The analyst who wanted us to buy it ran a bunch of scans when we got the license key. Dan: All right! Did you find anything? A: Oh yeah! We found all sorts of scary stuff. Dan: Well what did you do about it? A: We sent the PDF report to the development team and told them to fix the problems. Dan: Were they successful? A: I don’t know. I guess I should check in on that… 5
  7. 7. Why Is This Bad? • PDFs are blobs • Email is infinitely ignorable • Lumps all vulnerabilities together • No guidance for developers • Just plain rude 6
  8. 8. A More Excellent Way 7
  9. 9. A More Excellent Way • Treat (Application) Security Vulnerabilities as Software Defects • Why? – Developers have to fix the issues eventually – Developers understand defects – Even most “loosely-structured” development teams have defect tracking systems 8
  10. 10. What Makes a Good Security Defect? 9
  11. 11. What Makes a Good Security Defect? • Why do I care? • Scope • Where is it? • How do I fix it? 10
  12. 12. Why Do I Care? 11
  13. 13. Why Do I Care? • Do not rely solely on the defect to communicate this – Simply pumping defects into the defect tracking system is unlikely to be effective • Provide context • Provide steps to reproduce – Automated if possible • Transparency! 12
  14. 14. Scope 13
  15. 15. Scope • Defects that take 5 minutes to fix take far longer to administer – Especially with mature (elaborate) QA processes • Maximum time: 16 hours – http://www.joelonsoftware.com/items/2007/10/26.html • Target: 1-16 hours – Long enough to be an actual task, short enough to be predictable – Defects for technical vulnerabilities should be shorter – Defects for logical vulnerabilities can be longer 14
  16. 16. Where Is It? 15
  17. 17. Where Is It? • Providing location information removes a “barrier” to fixing • Better location information leads to quicker fix times • Dynamic analysis: attack surface location – Vulnerability type, URL, possibly parameter – (For web applications) • Static analysis: code location – Filename – Line (and hopefully column) – Include actual code if possible in case underlying codebase has changed 16
  18. 18. How Do I Fix It? 17
  19. 19. How Do I Fix It? • Prescriptive guidance is required here – Removes a reason not to fix – Leads to consistency • Does your organization have an ESAPI? Does it address this issue? 18
  20. 20. Why Is This Approach Better? • Defects are structured data • Defects are durable • Vulnerabilities have been portioned out into tractable chunks of “work” • We have provided prescriptive guidance • Communicates with developers via systems they already use 19
  21. 21. Strategies 20
  22. 22. Strategies • Group by location • Group by type • Group by severity 21
  23. 23. Grouping By Location • By file/URL or by directory • Pros: – Helpful if there is one “owner” for that area of the code – Can help to minimize requirements for QA regression testing • Cons: – Different vulnerability types require different fixes – Can be hard to keep things straight 22
  24. 24. Grouping By Type • By vulnerability type (XSS, SQL injection, authorization issue, etc) • Pros: – Similar vulnerabilities often have very similar fixes – Economies of assembly lines – get Henry Ford on vulnerabilities – Approach with a “punchlist” mentality • Cons: – There can be LOTS of vulnerabilities of a given type if bad coding idioms are in use 23
  25. 25. Grouping By Severity • High, medium, low • Pros: – Can help you game certain metric programs • Cons: – Least tied to how developers work – Different types of vulnerabilities – Cutting across functional areas 24
  26. 26. Strategies (continued) • Combine more than one – Group by type or severity and then by location 25
  27. 27. What About BIG Issues? • Serious issues can map to multiple defects • REALLY serious issues can map to enterprise change management initiatives 26
  28. 28. What About Non-Software Vulnerabilities? • Transition to change management systems rather than defect tracking systems 27
  29. 29. Demo 28
  30. 30. Contact Dan Cornell dan@denimgroup.com (210) 572-4400 @danielcornell Web: www.denimgroup.com Blog: blog.denimgroup.com Vuln Mgr: vulnerabilitymanager.denimgroup.com 29
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×