Software Security for Project Managers: What Do You Need To Know?

3,029 views

Published on

Application-level vulnerabilities have been responsible for a number of very public data breaches and are increasingly a target for a variety of types of attackers. This presentation demonstrates some of the security vulnerabilities that are often introduced during software development projects. It also looks at activities that can help identify these vulnerabilities as well as prevent them from being introduced in the first place. Attendees will take away from the presentation an understanding of software security risks as well as where assurance activities can be included in the project plan to help increase the security of software being developed with a minimum of impact to project schedules and budgets.

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,029
On SlideShare
0
From Embeds
0
Number of Embeds
714
Actions
Shares
0
Downloads
81
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software Security for Project Managers: What Do You Need To Know?

  1. 1. Software Security for Project Managers:! What Do You Need to Know?! ! Dan Cornell! CTO, Denim Group! @danielcornell© Copyright 2012 Denim Group - All Rights Reserved
  2. 2. My Background •  Dan Cornell, founder and CTO of Denim Group •  Software developer by background (Java, .NET, etc) •  OWASP San Antonio, Global Membership Committee© Copyright 2012 Denim Group - All Rights Reserved 2
  3. 3. Denim Group Background •  Secure software services and products company –  Builds secure software –  Helps organizations assess and mitigate risk of in-house developed and third party software –  Provides classroom training and e-Learning so clients can build software securely •  Software-centric view of application security –  Application security experts are practicing developers –  Development pedigree translates to rapport with development managers –  Business impact: shorter time-to-fix application vulnerabilities •  Culture of application security innovation and contribution –  Develops open source tools to help clients mature their software security programs •  Remediation Resource Center, ThreadFix –  OWASP national leaders & regular speakers at RSA, SANS, OWASP, ISSA, CSI –  World class alliance partners accelerate innovation to solve client problems© Copyright 2012 Denim Group - All Rights Reserved 3
  4. 4. Application Security in the News •  Heartland Payment Systems – Financial Data Compromise –  http://voices.washingtonpost.com/securityfix/2009/01/ payment_processor_breach_may_b.html •  PayPal – Cross Site Scripting –  http://news.netcraft.com/archives/2006/07/20/ paypal_xss_exploit_available_for_two_years.html •  T-Mobile – SQL Injection –  http://www.pcworld.com/article/119851/ paris_hilton_victim_of_tmobiles_web_flaws.html •  IKEA – Database Downloaded –  http://news.cnet.com/2100-1017-245372.html© Copyright 2012 Denim Group - All Rights Reserved 4
  5. 5. Demonstration •  How do attackers view your web applications? •  RiskE Utility site© Copyright 2012 Denim Group - All Rights Reserved 5
  6. 6. Application Security Defined© Copyright 2012 Denim Group - All Rights Reserved 6
  7. 7. Application Security Defined •  A common definition – "Ensuring that an attacker cannot compromise an applications resources or data". –  Too narrow –  Not very actionable •  A better definition – "Ensuring that custom application code performs as expected under the entire range of possible inputs"© Copyright 2012 Denim Group - All Rights Reserved 7
  8. 8. Software Implementation – Perfect World Actual Functionality Intended Functionality© Copyright 2012 Denim Group - All Rights Reserved 8
  9. 9. Software Implementation – Real World Actual Intended Functionality Functionality Built Bugs Features Unintended And Undocumented Functionality© Copyright 2012 Denim Group - All Rights Reserved 9
  10. 10. Application Security is Different •  Quality Assurance? –  The processes are similar –  The goals are not •  Traditional Information Security? Network Security? –  The goals are similar –  The processes are not© Copyright 2012 Denim Group - All Rights Reserved 10
  11. 11. Quality Assurance vs. Security Assurance •  Both are evolving practices –  Tools and techniques are continually improving •  Quality and Security Assurance both require continual effort –  You cannot declare software 100% bug-free –  You similarly cannot declare an application 100% secure •  Both are often managed by dedicated teams in addition to the development team© Copyright 2012 Denim Group - All Rights Reserved 11
  12. 12. Quality Assurance vs. Security Assurance •  QA, even excellent QA, does not account for security •  QA essentially compares an application to its "intent", its requirements –  Is the functionality there? –  Is it reliable in corner cases? –  Is the performance acceptable? •  Attackers are interested in what the application DOES that it is NOT SUPPOSED to do –  I can access my transaction data. Can I access someone elses as well? –  I can enter a data query string. Can I twist it into a data tampering command? –  I can upload documents. Can I also upload server pages? Overwrite their content?© Copyright 2012 Denim Group - All Rights Reserved 12
  13. 13. Traditional Security vs. Application Security •  Traditional Information Security shares the same goals –  Confidentiality –  Integrity –  Availability •  Network and application security experts must continually keep up with the latest threats© Copyright 2012 Denim Group - All Rights Reserved 13
  14. 14. Traditional Security vs. Application Security •  Traditional Information Security has a "measure and maintain" culture –  Track servers, workstations, devices –  Manage advisories, patches, configurations –  Monitor the systems in operation •  Application development has a "build" culture –  Create something that did not exist before –  Get it working on time and within budget •  Application threats are as unique as the applications themselves© Copyright 2012 Denim Group - All Rights Reserved 14
  15. 15. Why Does Application Security Matter? •  Critical Systems are Internet-facing •  Most applications have serious design or coding flaws •  Laws and Regulations© Copyright 2012 Denim Group - All Rights Reserved 15
  16. 16. Critical Systems are Internet Facing •  More and more business have moved to online commerce –  Hard goods, soft goods –  Flight check-in –  Personals –  Pizza Delivery •  This has tremendous advantages –  Cost of doing business goes down –  Market barriers are lower© Copyright 2012 Denim Group - All Rights Reserved 16
  17. 17. Critical Systems are Internet Facing •  What are the drawbacks? –  Systems no longer have an "air" gap, personal interaction –  Physical security and personal scrutiny matter less •  Imagine an ATM machine in the desert…© Copyright 2012 Denim Group - All Rights Reserved 17
  18. 18. Most applications have serious flaws •  70%+ according to studies performed by @Stake and Foundstone •  Too many development teams treat application security as a "check box" –  "This site is certified secure" labels on web pages •  Too few development teams regard security as fundamental as design or QA© Copyright 2012 Denim Group - All Rights Reserved 18
  19. 19. Laws and Regulations •  New laws and regulations govern how data is stored and made available –  HIPAA –  Sarbanes Oxley –  California SB-1386 –  PCI •  Failing to comply can have legal repercussions and damage trust from partners© Copyright 2012 Denim Group - All Rights Reserved 19
  20. 20. Application Security Goals •  Confidentiality •  Integrity •  Availability •  A flaw can be considered a security vulnerability when one of the goals is compromised© Copyright 2012 Denim Group - All Rights Reserved 20
  21. 21. Confidentiality •  Ensuring that information is accessible only to those authorized to have access •  Compromises –  Spoofing Identity –  Direct Object Reference –  Forced Browsing –  Database compromise –  Packet Sniffing •  This is not limited to information the application directly manages –  What about phishing? –  An attacker can use an application to manipulate users© Copyright 2012 Denim Group - All Rights Reserved 21
  22. 22. Integrity •  Information should only be modified by those users authorized to modify it •  Compromises –  Injection –  Direct Object Reference –  Malicious File Execution –  Cross Site Request Forgery •  There is a lot of crossover with Confidentiality, but many threats to Integrity are unique© Copyright 2012 Denim Group - All Rights Reserved 22
  23. 23. Availability •  The system is online and responding to user requests for valid users at all times it is supposed to •  Compromises –  Malicious File Execution –  Buffer Overflow –  Lockout Exploits •  Threats are not limited to "bringing down" an application server –  What about forcing an exception? –  What about saturating sockets between web and application servers?© Copyright 2012 Denim Group - All Rights Reserved 23
  24. 24. What Goes Wrong? •  Failure in Design •  Failure in Implementation© Copyright 2012 Denim Group - All Rights Reserved 24
  25. 25. Causes of Application Security Vulnerabilities •  Failure in Design –  Poor decisions about trust –  Unspoken assumptions –  Not accounting for failure •  Failure in Implementation –  Insecure coding techniques –  Insecure configuration –  Poor deployment practices© Copyright 2012 Denim Group - All Rights Reserved 25
  26. 26. Types of Vulnerabilities •  Logical Vulnerabilities –  Surface due to insecure program logic –  Typically due to poor decisions about trust –  Most "scanner" tools are powerless to find logical vulnerabilities –  Remediation: architecture and design changes •  Technical Vulnerabilities –  Surface due to insecure programming techniques –  Typically due to poor input handling and input validation –  Most "scanner" tools primarily find technical vulnerabilities –  Remediation: coding changes© Copyright 2012 Denim Group - All Rights Reserved 26
  27. 27. Common Application Vulnerabilities •  Logical –  Poor Authentication –  Direct Object References –  Unchecked Input •  Technical –  Cross Site Scripting –  Injection Flaws –  Insecure Communications •  Logical or Technical –  Information Leakage –  Poor Cryptographic Storage –  Poor Configuration Management© Copyright 2012 Denim Group - All Rights Reserved 27
  28. 28. Software Assurance Maturity Model (OpenSAMM) •  Open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks racing the organization •  Useful for: –  Evaluating an organization’s existing software security practices –  Building a balanced software security program in well-defined iterations –  Demonstrating concrete improvements to a security assurance program –  Defining and measuring security-related activities within an organization •  Main website: –  http://www.opensamm.org/© Copyright 2012 Denim Group - All Rights Reserved 28
  29. 29. SAMM Business Functions •  Start with the core activities tied to any organization performing software development •  Named generically, but should resonate with any developer or manager [This slide content © Pravir Chandra] © Copyright 2012 Denim Group - All Rights Reserved
  30. 30. SAMM Security Practices •  From each of the Business Functions, 3 Security Practices are defined •  The Security Practices cover all areas relevant to software security assurance •  Each one is a silo for improvement [This slide content © Pravir Chandra] © Copyright 2012 Denim Group - All Rights Reserved
  31. 31. Conclusions / Questions Dan Cornell dan@denimgroup.com Twitter: @danielcornell www.denimgroup.com www.denimgroup.com/threadfix code.google.com/p/threadfix (210) 572-4400© Copyright 2012 Denim Group - All Rights Reserved 31

×