security testing for test professionals

TL PM Tutorial

10/14/2014 1:00: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 ∙ [email protected] ∙ 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 was 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. Follow Jeff on Twitter @jefferyepayne.

1 © Copyright 2013 Coveros Corporation. All rights reserved.

Security Testing

for Testing Professional

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

Trainer

Jeffery Payne [email protected]

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.


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


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


Introduction to Security Testing


When you hear the term “Information Security” …

What do you think it means?

What comes to mind?

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

What is Information Security?


The Software Security Problem

Our IT systems are not castles any longer!


Why Software Security is Important

RISK IS

EVERYWHERE!


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


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


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


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


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


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


Threats to system

(H/M/L)

Business Risks Assets of interest

(H/M/L)

Exercise Results


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


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


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


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



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


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



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


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


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



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


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


Secure Authentication

Requirements

Sample Tests

Exercise Results



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)


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


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


Testing to Mitigate 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

Common 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

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”/>


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


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


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!


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


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


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


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


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


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


Integrating Security into Your Testing

Process


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


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


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



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



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



Wrap-Up


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


Questions?

Contact Information:

http://www.coveros.com

[email protected]

703.431.2920

security testing for test professionals

Technology

software security consulting

reliable software

software company

pm security testing

founder of coveros

variety of software

software quality solutions

founding coveros