Security Testing for Test Professionals

TN
Half‐day Tutorial
6/4/2013 1:00 PM

"Security Testing for Test
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

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, cyberterrorism,
and software quality.

Security Testing
for Test Professional

© Copyright 2013 Coveros Corporation. All rights reserved.

1

About Coveros
 Coveros helps organizations accelerate the delivery of secure, reliable
software
 Our consulting services:
–
–
–
–

Agile software development
Application security
Software quality assurance
Software process improvement

Areas of Expertise

 Our key markets:
–
–
–
–

Financial services
Healthcare
Defense
Critical Infrastructure

© Copyright 2013 Coveros, Inc.. All rights reserved.

2

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


3

Trainer

Jeffery Payne
jeff.payne@coveros.com

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.


4

Introduction to Security Testing


5

What is Information Security?

When you hear the term “Information Security” or
“Security Testing” …
What do you think it means?
What comes to mind?


6

What is Information Security?
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


7

The Software Security Problem
Our IT systems are not castles any longer!


8

Why Software Security is Important


9

Understanding Risk
How to Define Security Risk in Software
 Common Security Nomenclature
– Risk: a possible future event which, if it occurs, will lead to an
undesirable outcome
– Threat: A potential cause of an undesirable outcome
– 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


10

Understanding Risk
Risk Assessment
 A risk assessment is commonly carried out by a team of
people who have subject area knowledge of the business
and product. Members of the team provide a qualitative
analysis based on informed opinion of threats that will later
be used in a more quantitative analysis.
 The team should also define what is an acceptable amount
of risk that the organization can assume. We assume we
can’t identify all risks nor eliminate them; this is often
referred to as residual risk.


11

Exercise
Risk Assessment
 Break into teams of 2-3 people.
 Each team will identify potential threats to a software
application described on the next slide.
– Who would want to compromise this application?
– What assets would they be after if they did?

 Once each threat is identified, provide impact and likelihood
ratings (High, Medium, Low) for each threat.
– Justify your answers

 Exercise Time Limit: 15 Minutes


12

Exercise
Risk Assessment
 Your company, SecureTelco, has developed an instant
messaging program to be used for private use in customers
homes and for companies and government agencies.
 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 contact
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.

13

Exercise
Risk Assessment Questions
 Business / Mission Motivation
– What is the importance/criticality of the system?
– What assets exist in the system?
– What is the impact if C, I, A principles violated?

 User Capabilities and Exposure
– How is access different for user roles?
– What operations can each performed by different users?

 Threat Motivation
–
–
–
–

Why might someone attack the system?
Who might want to attack? (insiders, outsiders)
What might attackers accomplish?
What’s the cost of failure?

14

Exercise
Risk Assessment Discussion
 What threats exist for this application?
 Do other teams agree with your assessment?
 Did you cover confidentiality, integrity, authenticity,
availability and non-repudiation? Why or why not?
 Did your assessment cover the ‘administrative console’ as
well?


15

Security Testing
What? How?
 Security Testing is testing used to determine whether an
information system protects its data 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

16

Security Testing
Why is it important?
 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.

17

Security Testing
Aspects of Security Testing
 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 nonfunctional security requirements
 Secure implementation means the software does not have
embedded vulnerabilities due to poor design or coding
practices

18

Security Testing
Testing Aspects of Security
 Testing security features/controls is most akin to normal
functional testing
– Functional security requirements drive this testing
– Integration of security features into overall application

 Testing security properties requires tests that cross many
features of the system
– Develop tests based on non-functional security requirements and
identified risks / threats
– Tests that assure the implementation does not include known flaws
and vulnerabilities


19

Security Requirements


20

What are Security Requirements?
What is a Security Requirement?
 Security Requirements describe functional and nonfunctional requirements that need to be satisfied in order to
achieve the security attributes of an IT system or
application.

What does that mean?
 Functional Security Requirements
 Additions to functional requirements that define what
the software should not do.
 Non-Functional Security Requirements
 Additional non-functional requirements that define what
overall security the system must provide

21

Functional Requirements
Your Standard Definition
 Functional Requirements: These are 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 some cases, the functional
requirements may also have explicitly state what the system
should not do.

Where does the Security fit in?
 Security features should already have functional
requirements associated with them
 Don’t assume they are good or adequately address what
the software should not do
 Misuse and abuse cases should be defined to understand
risks that a threat may utilize to attack the system
 Make sure you check all features for misuse cases

22

Functional Security Requirements
Security Features (aka Security Controls)
 Part of your security requirements involve security features,
or security controls, that help protect your system
 They define the way your system will behave with respect to
other security properties and non-functional requirements
 Examples:
–
–
–
–
–
–

Authentication and Identity Management
Authorization and Access Control
Input Validation & Encoding
Encryption
Error and Exception Handling
Auditing and Logging

23

Misuse and Abuse Cases
 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 security tests

24

Exercise
 Break into teams of 2-3 people.
 Each team will identify potential misuse cases with the
following security requirements, if any exist.
 If a misuse case is identified, write a replacement or
additional functional requirement(s).
– It would be best to make sure no misuse cases can be derived from
your new requirement(s).

 Exercise Time Limit: 15 Minutes


25

Exercise
Functional Security Requirement Examples
 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.

26

Exercise
Functional Security Requirements Discussion
 How could an attacker attempt to thwart the system?
 What are the core information security concepts we should be
concerned with?
 What issues exist with the current requirements?
 How would you fix the current requirements?
 How might we test to determine whether the requirement handles
the abuse case?

27

Exercise
Formal Authentication Use/Misuse Case Artifact
Enter username
and password

Threatens

SecureChat
User

User
authentication

Brute Force
Attack

Mitigates
Show generic
error message

Guess User
Accounts
Mitigates

Lock account
after N failed
login attempts

SecureChat
Server

Hacker

Mitigates
Dictionary
Attacks
Mitigates

Validate
password
minimum
length and
complexity

28

Non-Functional Requirements
Your Standard Definition
 Non-Functional Requirements: These are constraints on
the services or functions offered by the system.
 Availability, Reliability, Performance, Scalability, Testability,
Security

Where does Security fit in?
 Security is one of the cross-cutting concerns that must be
addressed during testing
 Threat modeling, architectural analysis, and code analysis
are often used to enumerate risks and drive non-functional
security testing
 Tools can assist testing professionals with these efforts
 Conformance with standards and regulations

29

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

30

Security Test Planning
What goes where
 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 nonfunctional 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

31

Testing to Mitigate Common Attacks


32

Common Attacks
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

33

Common Attacks
What are Injection Attacks?
 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
$name = Joe
<body><p>
Hi, Joe.
</p></body>

<body><p>
<?
$msg = “Hi, “ + $name + “.”;
echo $msg
$name = <script src=“http://bad.com/attack.js”/>
?>
<body><p>
</p></body>
Hi,
<script src=“http://www.bad.com/attack.js”/>.
</p></body>

34

Common Attacks
Common Input Mistakes
 Input characters that aren’t expected
– More input than expected
– Different input than expected
– Executable input that is unexected

 Input encoded strings
– Automatically converted/decoded by browsers and other
frameworks

These “mistakes” are what attackers leverage to trigger input
vulnerabilities in our systems

35

Common Attacks
Types of Input Validation
 Integrity Checks – Ensure that the data has not been tampered
with and is the same as before.
– Integrity checks must be included wherever data passes from a trusted
to a less trusted boundary, such as from the application to the user's
browser in a hidden field, or to a third party payment gateway, such as
a transaction ID used internally upon return.
– The type of integrity control (checksum, HMAC, encryption, digital
signature) should be directly related to the risk of the data transiting the
trust boundary.

 Validation - Ensure that the data is strongly typed, correctly
syntaxed, within length boundaries, contains only permitted
characters or that numbers are correctly signed and within
boundary ranges.
– Validation must be performed on every tier. For example, the
presentation layer should validate web related issues, persistence
layers should validate for persistence issues, etc.


36

Validating Input
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

37

Common Input Attack #1
Cross-Site Scripting
 A very common vulnerability
 Allows an attacker to inject script into a vulnerable web
system that attacks the user
 Example:
http://myweb.com/index.php

http://myweb.com/index.php?name=Joe

Type your name: Joe

Hi, Joe!

 What happens if we type our name as:
<script>alert(“Joe Hacker!”)</script>


38

Cross Site Scripting
Reflected Cross-Site Scripting
 Testing for Reflected Cross-Site Scripting
– Reflected Cross Site Scripting (XSS) is another name for nonpersistent XSS, where the attack doesn’t load with the vulnerable
web application but is originated by the victim loading the offending
URI using the victim’s credentials.
 Commonly, an attacker creates and tests an offending URI, in which the victim
loads the URI on their browser.
 Attackers typically leverage these vulnerabilities to install key loggers, steal
victim cookies, perform clipboard theft and change the content of the page

– Testing Process
 Detect Input Vectors
 Analyze Each input vector to detect potential vulnerabilities. Input data is
typically harmless, but triggers web browser responses.
 Report on Findings
 Analyze report and attempt to exploit with an attack that has a realistic impact on
web application security.


39

Stored Cross-Site Scripting
 Testing for Stored Cross-Site Scripting
– Stored XSS is the most dangerous type. Web applications that
allow users to store data are potentially exposed to this type of
attack.
 This occurs when a web application gathers malicious input and stores,
unfiltered, that input in a data store for later use. As a consequence the
malicious data will appear to be part of the web site and run on the user’s
browser.
 The more privileges the end user has the more dangerous this attack is.

– Testing Process






Identify input forms
Analyze HTML Code
Test for Stored XSS
Report on Findings
Analyze report and attempt to exploit with an attack that has a realistic impact on
web application security.


40

Cross Site Scripting Patterns (cont.)
 Testing for DOM-Based Cross Site Scripting
– DOM-based XSS is the name for bugs which are the result of active
content on a page, typically obtaining user input and doing
something unsafe with it to lead to a XSS bug.
 In comparison to other cross site scripting vulnerabilities (reflected and stored
XSS), where an unsanitized parameter is passed by the server, returned to the
user and executed in the context of the user’s browser, a DOM based cross site
scripting vulnerability controls the flow of the code by using elements of the
Document Object Model (DOM) along with code crafted by the attacker to
change the flow.

– Manual testing is almost always required for this type of XSS attack
and requires knowledge of the code, especially around any use of
JavaScript.


41

Cross Site Scripting Patterns (cont.)
 Testing for Cross Site Flashing
– ActionScript is the language used by Flash applications when
dealing with interactive needs due to some poor implementation
patterns.
 New versions of Flash player are often released to mitigate some attacks, but
poor programming practices often still result in exploits.

– Manual testing is almost always required for this type of XSS attack
and requires knowledge of the code, especially around any use of
ActionScript.


42

Common Input Attack #2
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.


43

Common Attack #2: SQL Injection
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'


44

SQL Injection
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.


45

SQL Injection
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.


46

Common Attacks
Use Tools!
 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


47

Integrating Security into Your Testing
Process


48

Software Development Life Cycle
How do you add Security in?

Define

Use/Abuse
cases

Security
requirements

Design

Threat
modeling

Security test
planning

Develop

Static
Analysis

Risk-based
security
testing

Deploy

Assess
threats and
assets

Penetration
testing

49

Tools to Support Security Testing
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


50

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


51

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


52

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


53

Wrap-Up


54

References
 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


55

Questions?
Contact Information:
http://www.coveros.com
info@coveros.com
703.431.2920

56

Security Testing for Test Professionals

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to Security Testing for Test Professionals

Similar to Security Testing for Test Professionals (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Security Testing for Test Professionals