Michael Gavin Senior Analyst Forrester Research

TeleconferenceApplication Security TestingMichael Gavin

Senior Analyst

Forrester Research

November 14, 2006. Call in at 12:55 pm Eastern Time

2Entire contents © 2006 Forrester Research, Inc. All rights reserved.

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



Data parsing vulnerabilities

• Buffer and heap overflows

• Proprietary formats and protocols

• Format string vulnerabilities

• Integer overflow vulnerabilities



Information disclosure

• Plain text password storage

• Accessible temporary files

• Data left in memory

• Swap file contents and incomplete deletion



Network communications vulnerabilities

• Impersonation, spoofing, and man-in-the-middle

• Race conditions

• Network based information disclosure



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



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


Michael Gavin

+1 617/613-6376

[email protected]

www.forrester.com

Thank you


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

Documents

Michael Gavin Senior Analyst Forrester Research