• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Michael Gavin Senior Analyst Forrester Research
 

Michael Gavin Senior Analyst Forrester Research

on

  • 1,298 views

 

Statistics

Views

Total Views
1,298
Views on SlideShare
1,298
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Michael Gavin Senior Analyst Forrester Research Michael Gavin Senior Analyst Forrester Research Presentation Transcript

    • November 14, 2006. Call in at 12:55 pm Eastern Time Michael Gavin Senior Analyst Forrester Research Teleconference Application Security Testing
    • Theme By testing applications for security issues you can fix flaws before attackers can find them.
    • Agenda
      • What’s different about security testing?
      • Why perform security testing?
      • Who should be doing this testing?
      • What are we looking for anyway?
      • Learn how, when, and where to find security issues
      • What tools are available to help?
    • What’s different about security testing?
      • Most software testing attempts to prove that software works as intended, meets certain criteria.
      • Security testing attempts to prove that software can be made to do something unintended.
      • When you find a security issue, keep testing! Determine what you can break from there.
      • Developers try to build things, testers validate built software and try to break it in certain ways.
        • Both should understand common vulnerabilities and attacks, and learn how to break software security.
    • Security and software
      • Secure software provides:
        • Confidentiality
          • Access is only allowed if authorized
        • Integrity
          • Assurance that data is complete and accurate
        • Availability
          • Assets are available when needed
      • Security testing must find where confidentiality, integrity, and availability can be defeated
    • Why perform security testing?
      • Web application vulnerabilities accounted for 69% of the vulnerabilities disclosed between July 2005 and June 2006.*
      • Vulnerabilities in software afford an attacker the same privileges granted to that software.
      • Network defenses must let software perform its functions — they don’t know if it has been compromised.
      * Source: Symantec Internet Threat Report, Volumes IX and X
    • Who should be doing this testing?
      • Software security experts should help in all phases of security testing.
      • Developers can, and usually should, validate the use of secure program techniques during builds.
      • Developers can, and usually should, test for security when doing unit testing.
      • Anyone who does integration testing or system testing should also perform security testing.
      • QA should also test for security prior to sign-off.
    • What are we looking for anyway?
      • Flaws in software dependencies.
      • Software design flaws and design decisions with security consequences.
      • Software implementation flaws and choices with security consequences.
      • Ways to bypass security controls, e.g., authentication, authorization, encryption, and logging.
      Based upon “How To Break Software Security,” Whittaker & Thompson, Addison-Wesley, 2004
    • What are we looking for anyway? (continued)
      • System level attacks
      • Data parsing vulnerabilities
      • Information disclosure
      • Network communications vulnerabilities
      • When appropriate: Web application vulnerabilities
      Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
    • System level attacks
      • Permission problems
      • Default or weak passwords
      • Shells, scripts, and macros
      • Dynamic linking and loading
      Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
    • Data parsing vulnerabilities
      • Buffer and heap overflows
      • Proprietary formats and protocols
      • Format string vulnerabilities
      • Integer overflow vulnerabilities
      Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
    • Information disclosure
      • Plain text password storage
      • Accessible temporary files
      • Data left in memory
      • Swap file contents and incomplete deletion
      Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
    • Network communications vulnerabilities
      • Impersonation, spoofing, and man-in-the-middle
      • Race conditions
      • Network based information disclosure
      Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
    • Web application vulnerabilities
      • Cross-site scripting
      • Forceful browsing
      • Parameter tampering, cookie poisoning, and hidden field manipulation
      • SQL injection vulnerabilities
      • Additional server side security issues
      • Additional client side security issues
      Based upon “The Software Vulnerability Guide,” Thompson & Chase, Charles River Media, 2005
    • Learn how, when, and where to find security issues
      • How:
        • Fault injection, malicious inputs, etc.
        • Help is available — publications and Web references. See bibliography slides. Also tools and consultants.
      • When:
        • Throughout the software development life cycle. See slide regarding who should perform security testing.
      • Where:
        • Ideally in the lab, but in production is sometimes necessary
        • Preferably as close to the source code as possible
    • Manual steps to improve software security
      • Security design review, threat modeling, abuse and misuse cases
      • Secure coding checklists and secure code reviews
      • Security assessments and penetration tests
    • What tools are available to help?
      • Network tools
        • Scanners to find software running in the environment
        • Sniffers to observe and manipulate software communications
      • Protocol implementation test tools
      • Source code tools
        • Development tools, e.g. strict compiler warnings
        • Source code analysis tools
    • What tools are available to help? (continued)
      • Debugging and reverse engineering tools
        • Decompilers, disassemblers, hex editors, debuggers, interpreters
        • Binary scanners,
        • API and system monitors
    • What tools are available to help? (continued)
      • Penetration testing tools
        • Password crackers
        • Fuzzers
        • Security scanners
          • OS, service, network, application, database
        • Proxy servers
      • Automated penetration testing tools
      • Exploit development tools
    • Tool vendors and products
      • Protocol testing tools
        • Codenomicon
      • Source code scanners
        • Compuware, DevPartner SecurityChecker
        • Coverity, Prevent
        • Fortify, Source Code Analysis
        • Klocwork, Klocwork K7
        • Ounce Labs, The Ounce Solution
        • Parasoft, JTest, C++test, .TEST
        • Secure Software, Code Assure Workbench
    • Tool vendors and products (continued)
      • Debuggers
        • DataRescue, IDA Pro Disassembler and Debugger
        • NuMega SoftIce
        • OllyDbg
      • Reverse engineering
        • Imagix 4D
        • Sabre Security, BinDiff, BinNavi, BinAudit
        • See http://www.woodmann.com/crackz/Tools.htm
    • Tool vendors and products (continued)
      • Penetration testing tools
        • Numerous. See http://www.securityfocus.com/tools , http://www.datastronghold.com/articles/PenetrationTestingTools.html , and http://sectools.org/ and for the more common tools
      • Automated penetration testing tools
        • Core Security, Core Impact
        • Immunity Security, Canvas
        • Open Source, MetaSploit
          • MetaSploit is actually an exploit development tool but it also excels at automated penetration testing
    • Tool vendors and products (continued)
      • Software scanners
        • Application Security, AppDetective (Database programs)
        • Compuware, DevPartner Security Checker
        • Coverity, Extend
        • Fortify, Tracer and Tester
    • Tool vendors and products (continued)
      • Web application scanners
        • Acunetix, Web Vulnerability Scanner
        • Cenzic, Cenzic Hailstorm
        • Compuware, Security Checker?
        • NT Objectives, NTO Spider
        • Open Source, nikto, wikto, Paros proxy
        • Parasoft, WebKing, SOAtest
        • SPI Dynamics, WebInspect
        • Watchfire, AppScan
        • WhiteHat Security, WhiteHat Sentinel
    • Security testing consultants
      • Aspect Security
      • Cigital
      • Fishnet Security
      • Neohapsis
      • Security Innovation
      • Solutionary
      • System Experts
      • Verisign
    • Current and future trends
      • Attacking the client
      • Attacking the server
      • Attacking both — AJAX!
      • Attacking Web authentication and authorization
      • Attacking application datastores
      • Attacking Web application management systems
      • Improved man in the middle attacks
      • Attacking Web services
    • Recommendations
      • Perform periodic penetration tests and/or security assessments against software programs
      • Periodically review application users and privileges
      • Stage and test application updates prior to deployment
      • Assign responsibility for security testing in each phase of the SDLC
      • Create a virtual software security team consisting of those responsible individuals
    • Thank you Michael Gavin +1 617/613-6376 [email_address] www.forrester.com
    • Selected Forrester bibliography
      • January 24, 2006, “Trends 2006: Application Security Testing”
      • September 15, 2005 “Take Careful Inventory Before Adopting Standalone Quality Tools”
      • May 27, 2005, Best Practices “To Secure Web Applications, Start With The OWASP Top Ten”
      • May 16, 2005, Best Practices “Software Quality Is Everybody’s Business”
    • Recommended Web sites
      • OSSTMM Open Source Security Testing Methodology Manual, http://www.isecom.org
      • Professional Security Testers, http://www.professionalsecuritytesters.org/
      • Application Security, http://SearchAppSecurity.techtarget.com
      • OWASP (Open Web Application Security Project), http://www.owasp.org
      • WASC (Web Application Security Consortium), http://www.webappsec.org
      • Web Site Security, http://www.cgi.com
    • Selected bibliography
      • “ Threat Classification,” Web Application Security Consortium (WASC) http://www.webappsec.org/projects/threat/
      • “ Learning Guide: Application security testing techniques” SearchAppSecurity.com http://searchappsecurity.techtarget.com/general/0,295582,sid92_gci1215847,00.html?Offer=ASwn920aslg
      • “ Threat Modeling,” Swiderski and Snyder, Microsoft Press, 2004
      • “ How To Break Software Security,” Whittaker and Thompson, Addison-Wesley, 2003
    • Selected bibliography
      • “The Software Vulnerability Guide,” Thompson and Chase, Charles River Media, 2005
      • “Gray Hat Hacking,” Harris, et. al., Osborne, 2005
      • “Exploiting Software: How to Break Code,” Hoglund and McGraw, Addison-Wesley, 2004
      • “Hacking Web Applications Exposed,” Scambray, et. al., Osborne, 2006
      • “How To Break Web Software: Functional and Security Testing of Web Applications and Web Services,” Andrews and Whittaker, Addison-Wesley, 2006