Contenu connexe Similaire à Security Testing for Testing Professionals (20) Security Testing for Testing Professionals1. TM
Half-day Tutorials
5/6/2014 1:00:00 PM
Security Testing for Testing
Professionals
Presented by:
Jeff Payne
Coveros, Inc.
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888-268-8770 ∙ 904-278-0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
2. Jeff Payne
Coveros, Inc.
Jeff Payne is CEO and founder of Coveros, Inc., a software company that builds secure software
applications using agile methods. Since its inception in 2008, Coveros has become a market leader
in secure agile principles and has been recognized by Inc. magazine as one of the fastest growing
private US companies. Prior to founding Coveros, Jeff was chairman of the board, CEO, and
cofounder of Cigital, Inc., a market leader in software security consulting. Jeff has published more
than thirty papers on software development and testing, and testified before Congress on issues of
national importance, including intellectual property rights, cyber terrorism, and software quality.
3. 1© Copyright 2013 Coveros Corporation. All rights reserved.
Security Testing
for Testing Professional
4. 2© Copyright 2013 Coveros, Inc.. All rights reserved.
Trainer
Jeffery Payne
jeff.payne@coveros.com
Twitter: @jefferyepayne
Jeffery Payne is CEO and founder of Coveros, Inc., a software company that
helps organizations accelerate the delivery of secure, reliable software. Coveros
uses agile development methods and a proven software assurance framework to
build security and quality into software from the ground up. Prior to founding
Coveros, Jeffery was Chairman of the Board, CEO, and co-founder of Cigital, Inc.
Under his direction, Cigital became a leader in software security and software
quality solutions, helping clients mitigate the risk of software failure. Jeffery is a
recognized software expert and popular speaker at both business and technology
conferences on a variety of software quality, security, and agile development
topics. He has also testified before Congress on issues of national importance,
including intellectual property rights, cyber-terrorism, Software research funding,
and software quality.
5. 3© Copyright 2013 Coveros, Inc.. All rights reserved.
Coveros helps organizations accelerate the delivery of secure, reliable
software
Our consulting services:
– Agile software development
– Application security
– Software quality assurance
– Software process improvement
Our key markets:
– Financial services
– Healthcare
– Defense
– Critical Infrastructure
Areas of Expertise
About Coveros
6. 4© Copyright 2013 Coveros, Inc.. All rights reserved.
Agenda
Introduction to Security Testing
– Information security
– Software security
– Risk assessment
– Security testing
Security Requirements & Planning
– Functional security requirements
– Non-functional security requirements
– Test planning
Testing for Common Attacks
Integrating Security Testing into the Software Process
7. 5© Copyright 2013 Coveros, Inc.. All rights reserved.
Introduction to Security Testing
8. 6© Copyright 2013 Coveros, Inc.. All rights reserved.
When you hear the term “Information Security” …
What do you think it means?
What comes to mind?
What is Information Security?
9. 7© Copyright 2013 Coveros, Inc.. All rights reserved.
Definition of Information Security
Information Security means protecting information and
information systems from unauthorized access, use,
disclosure, disruption, modification, perusal, inspection,
recording or destruction.
The key concepts of Information Security include:
– Confidentiality
– Integrity
– Availability
– Authenticity
– Non-Repudiation
What is Information Security?
10. 8© Copyright 2013 Coveros, Inc.. All rights reserved.
The Software Security Problem
Our IT systems are not castles any longer!
11. 9© Copyright 2013 Coveros, Inc.. All rights reserved.
Why Software Security is Important
RISK IS
EVERYWHERE!
12. 10© Copyright 2013 Coveros, Inc.. All rights reserved.
Common Security Nomenclature
Understanding Risk
Risk: a possible future event which, if it occurs, will lead to an undesirable outcome
Threat: A potential cause of an undesirable outcom
Asset: Data, application, network, physical location, etc. that a threat may wish to
access, steal, destroy, or deny others access to
Vulnerability: Any weakness, administrative process, or act of physical exposure
that makes an information asset susceptible to exploit by a threat.
An exploit is a piece of software, a chunk of data, or sequence of commands that
takes advantage of a vulnerability in order to cause unintended or unanticipated
behavior to occur on computer software, hardware, or something electronic.
Attack: the approach taken by a threat to exploit a vulnerability
– Denial of service, spoofing, tampering, escalation of privilege
13. 11© Copyright 2013 Coveros, Inc.. All rights reserved.
Risk Assessment
A risk assessment is commonly carried out by a team of
people who have subject area knowledge of the business /
product and information security
Possible connections between identified threats and system
assets are examined and the risk of exposure is
determined:
– Impact: the consequence of an asset being exposed
– Likelihood: the likelihood that a threat can compromise an asset
Residual risks are those that
have been deemed acceptable
and are not mitigated
Risk assessment is a process
not a one time activity
Understanding Risk
14. 12© Copyright 2013 Coveros, Inc.. All rights reserved.
Business Risk: Loss of Customer Trust
– Professional hacker is able to access bank account information for all
banking customers due to poor authentication mechanisms in the on-
line banking application
– Business impacts $: High Impact as an estimated that 20% of
reserves will be taken out of bank by customers if hack is revealed
– Likelihood: High Likelihood as appropriate authentication
mechanisms are not built into the banking application
Technical Risk: Lack of Authentication Mechanisms
– Inadequate use of
Examples of Risks
Understanding Risk
15. 13© Copyright 2013 Coveros, Inc.. All rights reserved.
Identifying Threats and Assets
Break into teams of 2-3 people.
Each team will identify potential threats, assets, and risks to
a software application described on the next slide.
Exercise Time Limit: 15 Minutes
Exercise #1
16. 14© Copyright 2013 Coveros, Inc.. All rights reserved.
Your company, SecureTelco, has developed an instant
messaging program to be used by corporations and government
agencies to chat securely about sensitive subjects
SecureChat requires users to sign up with an account prior to
using the system. After authenticating with a username and
password, each user can message other users and expect their
conversations to be private.
Users have the ability to add/remove friends from their IM list,
search for friends based on their email, block users from IMing
them, become “invisible” to all users on demand.
Messages archives and activities logs document user behavior
and can be retrieved by the user or a SecreTelco Administrator
through the application or by the administrative console,
respectively.
Software Application
Exercise #1 – Identifying Threats, Assets, Risks
17. 15© Copyright 2013 Coveros, Inc.. All rights reserved.
Questions to answer
Threats
– What threats exist for this application?
– I.e. who might want to compromise it?
– Which of the threats you’ve identified are the highest priority to
protect the system against and why?
Assets
– What important information resides within this application that would
motivate a threat to try and compromise it?
– Which of the assets you’ve identified are the highest priority to
protect and why?
Business Risks
– If a particular threat is able to access an asset, what is the business
consequence in $$$$?
Exercise #1 – Identifying Threats, Assets, Risks
18. 16© Copyright 2013 Coveros, Inc.. All rights reserved.
Threats to system
(H/M/L)
Business Risks Assets of interest
(H/M/L)
Exercise Results
19. 17© Copyright 2013 Coveros, Inc.. All rights reserved.
Security Testing is testing used to determine whether an
information system protects its assets from its threats.
Security Testing is not a silver bullet for your enterprise
security. Security Testing doesn’t fix your security, it only
makes you aware of it. Security must be built into your
software
A sound Security Testing process performs testing
activities:
– Before development begins
– During requirements definition and software design
– During implementation
– During deployment
– During maintenance and operations
Security Testing
20. 18© Copyright 2013 Coveros, Inc.. All rights reserved.
Provides a level of confidence that your system performs
securely within specifications.
Security Testing is a preventative way to find small issues
before they become big, expensive ones.
– The 2007 CSI Computer Crime and Security Survey performed an
analysis of the average cost of a web security breach. The average
loss reported in the survey was $350,424.
Security Testing ensures that people in your organization
understand and obey security policies.
If involved right from the first phase of system development
life cycle, security testing can help eliminate flaws in the
design and implementation of the system.
Why is it important?
Security Testing
21. 19© Copyright 2013 Coveros, Inc.. All rights reserved.
Major goals of security testing
– Test the security features of a system
– Test the security properties of a system
– Test whether the system is implemented in a secure fashion
Security features are controls you’ve implemented to protect
your system
– Authentication, Authorization, Encryption, etc.
Security properties are closely associated with non-
functional security requirements
Secure implementation means the software does not have
embedded vulnerabilities due to poor design or coding
practices
Aspects of Security Testing
Security Testing
23. 21© Copyright 2013 Coveros, Inc.. All rights reserved.
Security Requirements
Definition of Functional Requirements
Functional Requirements: Statements of services the
system should provide, how the system should react to
particular inputs and how the system should behave in
particular situations. In many cases, functional
requirements explicitly state what the system should not do.
Where does Security fit in?
Functional Security Requirements
Additions to Functional Requirements to reduce the chance
of inserting vulnerabilities into code
24. 22© Copyright 2013 Coveros, Inc.. All rights reserved.
Security Requirements
Definition of Functional Security Requirements
Functional Security Requirements describe functional
requirements that provide security controls to mitigate the
risk that threats and improperly access assets
Examples
Two factor authentication for logins
Use of encryption to protect data communication
Logging of system usage to detect anomalous behavior
Access control for important files
25. 23© Copyright 2013 Coveros, Inc.. All rights reserved.
Functional requirements that do not fully specify what the
system should not do and/or what to do in the face of all
error conditions, are not secure.
Additions to these requirements are necessary to assure a
secure system is built
Examples:
– Error and Exception Handling
– Input Validation
– Secure Reboot
– Secure Application Configurations
Security Additions to Functional Requirements
Security Requirements
26. 24© Copyright 2013 Coveros, Inc.. All rights reserved.
Use cases describe functionality of how someone might use
a system
Misuse cases describe how someone might (perhaps
unintentionally) do something in the system with a negative
security impact
Abuse cases describe how a malicious attacker might
deliberately misuse your system to his advantage
We use misuse and abuse cases to understand what our
system must protect against and help design more
comprehensive security tests
Misuse and Abuse Cases
Security Requirements across Functionality
27. 25© Copyright 2013 Coveros, Inc.. All rights reserved.
SecureChat Use Cases (High Level)
Example of Use Cases
Authenticate
Users
Chat with
Friends
Update Friend
List
View Logged
Chat Sessions
Register as a
User
SecureChat
User
Administrator
Edit User
Profile
Reset
Passwords
Create/Delete
Accounts
28. 26© Copyright 2013 Coveros, Inc.. All rights reserved.
Scenario
– SecureChat User authenticates with user and password
– User chooses friend from Friend List that is on-line
– User corresponds with friend (back and forth)
– User logs off
Misuse / abuse case #1 for scenario
– Secure User types in incorrect user id on authentication screen
– System pops up “Invalid User” error box and returns user to
authentication screen
Misuse/abuse case #2 for scenario
– SecureChat User authenticates with user and password
– User chooses friend from Friend List that is not on-line
– System does not allow selection of off-line Friend
Chat Use Case
Example of Use Case
29. 27© Copyright 2013 Coveros, Inc.. All rights reserved.
Security Requirements
Break into same teams as before.
Analyze requirements for login process (on next slide) and:
– Modify existing requirements to make them more secure
– Add additional requirements that are missing
– Think about system misuses to make sure you have thought
through everything
Create one test case for each requirement you finalize
Exercise Time Limit: 15 Minutes
Exercise #2 – Defining Security Requirements
30. 28© Copyright 2013 Coveros, Inc.. All rights reserved.
SecureChat Authentication Requirements
– When a user attempts to authenticate with a valid username and an
invalid password, the application shall not authenticate the user and
return them to the authentication page.
– The system must alert the user that their attempt to authenticate has
failed due to an incorrect password (“Invalid Password”) utilizing the
standard error text formatting.
– When a user attempts to authenticate with a invalid username, the
application shall not authenticate the user and return them to the
authentication page.
– The system must alert the user that their attempt to authenticate has
failed due to an incorrect username (“Invalid Username”) utilizing the
standard error text formatting.
– What a user attempts to authenticate using a username and a valid
password, the application shall authenticate the user and redirect them
to the homepage.
Functional Security Requirement Examples
Exercise
31. 29© Copyright 2013 Coveros, Inc.. All rights reserved.
Secure Authentication
Requirements
Sample Tests
Exercise Results
32. 30© Copyright 2013 Coveros, Inc.. All rights reserved.
Security Requirements
Definition of Non-Functional Requirements
Non-Functional Requirements: End-to-end constraints on
the services or functions offered by the system.
Availability, Reliability, Performance, Scalability, Testability,
Security
Where does Security fit in?
Specific aspects of availability and reliability affect the
security of your systems
Application must comply with security regulations and
standards (HIPAA, GLB, PCI)
33. 31© Copyright 2013 Coveros, Inc.. All rights reserved.
Non-Functional Requirements
Example Non-functional Security Requirements
Confidential data will not be accessible by users other than
through the SecureChat client
SecureChat shall have an availability of 99.9% at all times
All communication with the Securechat central server must
be encrypted using 128-bit encryption
SecureChat shall process a minimum of 8 transactions per
second.
All SecureChat code shall be reviewed against our internal
coding standards prior to release
34. 32© Copyright 2013 Coveros, Inc.. All rights reserved.
Security Test Planning
Functional security tests based upon the functional security
requirements should be planned, designed, and executed along
with the rest of the functional testing
– Typically covered by a combination of unit, feature, and integration testing
activities
– Don’t forget integration … COTS security features are often integrated
incorrectly
Non-functional security tests should be planned, designed, and
executed as followed:
– Unit level: secure code scanning to identify vulnerabilities
– Feature level: web application security testing plus any specific non-
functional security requirements that can be performed at this level
– Integration/System levels: more of the above based upon threats & risks
– System level: end-to-end testing and penetration testing that must be
done a production-like environment
What goes where
35. 33© Copyright 2013 Coveros, Inc.. All rights reserved.
Testing to Mitigate Common Attacks
36. 34© Copyright 2013 Coveros, Inc.. All rights reserved.
Input Validation
Most common application security weakness: failure to
properly validate input
– From client
– From environment (often overlooked)
Leads to many of the major vulnerabilities found in
applications
– Interpreter injection (SQL, JavaScript, XML, Command, …)
– Locale/Unicode attacks
– File system attacks
– Buffer overflows
Data from a client application or a user should never be
trusted as they are susceptible to injection attacks
Common Attacks
37. 35© Copyright 2013 Coveros, Inc.. All rights reserved.
Injection attacks result when input from a user is interpreted
by a command processor or formed to manipulate the
program stack/heap
– These are, by far, the most rampant category of attacks over the past
20 years
What are Injection Attacks?
Common Attacks
<body><p>
<?
$msg = “Hi, “ + $name + “.”;
echo $msg
?>
</p></body>
<body><p>
Hi, Joe.
</p></body>
$name = Joe
<body><p>
Hi,
<script src=“http://www.bad.com/attack.js”/>.
</p></body>
$name = <script src=“http://bad.com/attack.js”/>
38. 36© Copyright 2013 Coveros, Inc.. All rights reserved.
Input Validation Approaches
Accept Known Good
– Check the data is one of a set of tightly constrained known good values
– “Whitelist” validation
– Only works when set of good values is small or previously identified
Reject Known Bad
– Reject strings that contain potentially unacceptable characters (ex. If
you’re not expecting JavaScript, reject %3f)
– “Blacklist” validation
– A dangerous strategy because the possible set of bad data is infinite;
causes constant maintenance of blacklist
Sanitize
– Rather than accept or reject, change the input into an acceptable
format
– Sound software engineering practice
Validating Input
39. 37© Copyright 2013 Coveros, Inc.. All rights reserved.
A very common vulnerability
Allows an attacker to inject script into a vulnerable web
system that attacks the user
Cross-Site Scripting (XSS)
Common Input Attack #1
Type your name: Joe
http://myweb.com/index.php
Hi, Joe!
http://myweb.com/index.php?name=Joe
What happens if we type our name as:
<script>alert(“Joe Hacker!”)</script>
Reflective vs. Stored XSS
40. 38© Copyright 2013 Coveros, Inc.. All rights reserved.
Testing for Reflected Cross-Site Scripting
Identify existing scripting engines in your software
Craft input to trigger visible HTML output you can validate
– <h1>Jeff</h1> to try and highlight text
– <script>alert(“Hi”)</script> to try and pop up alert box
Cross Site Scripting
Stored Cross-Site Scripting
Identify existing scripting engines in your software
Craft input to trigger visible output that is stored in an
internal database (same tests as above)
Perform second input to see if script was stored and
executed
Check that ALL scripting engines cannot execute input!
41. 39© Copyright 2013 Coveros, Inc.. All rights reserved.
SQL Injection
What is SQL Injection?
– An SQL injection attack consists of the insertion or “injection” of an
SQL query via input data from the client to the application. A
successful exploit could read sensitive data, modify data, execute
administrative operations, recover the content to a given file and, in
some cases, issue commands to the operating system.
Types of SQL Injection
– Inband – Data is extracted using the same channel that is used to
inject SQL code. In the simplest form, the retrieved data is
presented directly to the application web page.
– Out-of-band – Data is retrieved using a different channel (e.g., an
email with the results of the query is generated and sent to the
tester).
– Inferential – Data is not transferred, but the tester is able to
reconstruct the information by sending particular requests and
observing the resulting behavior of the DB Server.
Common Input Attack #2
42. 40© Copyright 2013 Coveros, Inc.. All rights reserved.
SQL Injection Example
Consider the following SQL query:
– SELECT * FROM Users WHERE Username='$username' AND
Password='$password'
Assume the values of the input fields are obtained from the
user through a web form. Suppose we insert the following
Username and Password values:
– $username = 1' or '1' = '1
– $password = 1' or '1' = '1
The query will be:
– SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND
Password='1' OR '1' = '1'
Common Attack #2: SQL Injection
43. 41© Copyright 2013 Coveros, Inc.. All rights reserved.
SQL Injection Example (cont.)
Another test involves the use of the UNION operator. We
suppose for our examples that the query executed from the
server is the following:
– SELECT Name, Phone, Address FROM Users WHERE Id=$id
We will set the following Id value:
– $id = 1 UNION ALL SELECT creditCardNumber,1,1 FROM
CreditCardTable
NOTE: we have selected other two values. These two values are necessary, in order
to avoid a syntax error.
We will have the following query:
– SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION
ALL SELECT creditCardNumber,1,1 FROM CreditCardTable
The keyword ALL can be used to get around the DISTINCT
keyword.
SQL Injection
44. 42© Copyright 2013 Coveros, Inc.. All rights reserved.
Testing for SQL Injection (cont.)
Where to look for SQL Injection
– Authentication forms: Chances are high that the user credentials
are checked against a database that contains all usernames and
passwords (or their password hashes)
– Search Engines: Strings submitted could be used in a query that
extracts relevant records from a database.
– E-Commerce Sites: Products and their characteristics are very likely
to be stored in a database.
– Use your inherent knowledge of your application to pinpoint your
testing efforts.
SQL Injection
45. 43© Copyright 2013 Coveros, Inc.. All rights reserved.
Command Injection
Command injection attacks occur when inputs are allowed to
execute operating system shell commands and inputs is not
properly controlled.
Most dangerous when valid inputs execute as administrator / root
Example
– Ping 127.0.0.1 returns ping information and is a valid input
– cat /etc/passwd returns the contents of the password file and is
disallowed
– Ping 127.0.0.1;cat /etc/passwd may trick the program into giving up
the password by not noticing that multiple commands are being input
Input Attack #3
46. 44© Copyright 2013 Coveros, Inc.. All rights reserved.
Testing for all cases of injection attacks can be laborious
There are lots of tools out there to help
Leverage tools but also make sure validation code is correct
Understand architecture to test unique components that
include scripting / executable capabilities
Use Tools!
Common Attacks
47. 45© Copyright 2013 Coveros, Inc.. All rights reserved.
Integrating Security into Your Testing
Process
48. 46© Copyright 2013 Coveros, Inc.. All rights reserved.
How do you add Security in?
Software Development Life Cycle
Define Use/Abuse
cases
Security
requirements
Assess
threats and
assets
Design Threat
modeling
Security test
planning
Develop
Deploy
Static
Analysis
Risk-based
security
testing
Penetration
testing
49. 47© Copyright 2013 Coveros, Inc.. All rights reserved.
Classes of Tools
Risk-based security testing tools
– Proactive web app scanners
– Proxies
– Fuzzers
Secure code scanning tools
Threat modeling (planning tool)
Network scanning tools
Password Crackers
Tools to Support Security Testing
50. 48© Copyright 2013 Coveros, Inc.. All rights reserved.
Web Application Scanners and Proxies
Where to use?
– Looking for XSS, Injection and input validation vulnerabilities; some
tools will attempt to actively exploit vulnerabilities.
Free Tools
– Zed Attack Proxy
– Nikto
– W3af
– Paros
– Skipfish
– Wapiti
– wfuzz
Paid Tools
– Netsparker
– WebSecurify
– Big Commercial: IBM AppScan, Cenzic Hailstorm, HP WebInspect
Tools to Support Security Testing
51. 49© Copyright 2013 Coveros, Inc.. All rights reserved.
Password Crackers & Brute Force Tools
Where to use?
– When you want to break the default credentials or test your
authentication mechanisms against common security tools.
Free Tools
– THC Hydra
– Cain and Abel
– Wfuzz
Paid Tools
– John the Ripper
Tools to Support Security Testing
52. 50© Copyright 2013 Coveros, Inc.. All rights reserved.
Network Security Tools
Where to use?
– Scanning for mis-configurations
– Testing for OS, application and network vulnerabilities
Free Tools
– OpenVAS
Paid Tools
– Nessus
– Core Impact
Tools to Support Security Testing
54. 52© Copyright 2013 Coveros, Inc.. All rights reserved.
OWASP Foundation, “OWASP Testing Guide v3”,
https://www.owasp.org/index.php/OWASP_Testing_Project, 2008
Hope and Walther, “Web Security Testing Cookbook: Systematic Techniques to
Find Problems Fast,” O’Reilly, 2008
Whittaker and Thompson, “How to Break Software Security,” Addison-Wesley,
2003
Schneier, Bruce, “Secrets and Lies: Digital Security in a Networked World,”
Wiley, 2000
References
55. 53© Copyright 2013 Coveros, Inc.. All rights reserved.
Questions?
Contact Information:
http://www.coveros.com
info@coveros.com
703.431.2920