Software Security Testing

(1)

Software Security Testing

Elizabeth Sanders

Department of Electrical & Computer Engineering Missouri University of Science and Technology

[email protected]

(2)

Pop Quiz

• What topics am I covering today?

(3)

Pop Quiz

• What topics am I covering today?

• If you said any of the following then you are correct

– Software Security Testing

• Risk-based Testing

– Static Analysis for Security – Software Penetration Testing

20 November 2015 Software Security Testing 3

(4)

Software Security Development

Overview

• Risk-based security tests

• Static analysis

• Penetration testing

(5)

Software Security Development

Overview

• Risk-based security tests

– Identifying risks in the system and creating tests driven by those risks

– Provides a higher level of software security assurance

• Static analysis

• Penetration testing

(6)

Software Security Development

Overview

• Risk-based security tests

• Static analysis

– Tool that scans through a file searching for security vulnerabilities

• Penetration testing

(7)

Software Security Development

Overview

• Risk-based security tests

• Static analysis

• Penetration testing

– Objective is to find security weaknesses that would give access to the computer’s features and data

(8)

Risk-Based Security Tests

Introduction

• Identifying risks in the system and creating tests driven by those risks

• Provides a higher level of software security assurance

[PM2004]

(9)

Risk-Based Security Tests

What’s So Different About Security?

• Relative to the information and services being protected

• Risk analysis at the design level

• Vulnerabilities are errors that an attacker can exploit

– Two types of vulnerabilities

• Bugs at the implementation level

• Flaws at the design level

(10)

Risk-Based Security Tests

What’s So Different About Security?

• Bugs at the implementation level

– Easy to exploit

• Flaws at the design level

– Hardest defect to handle – Most prevalent and critical

– Flaws almost always lead to security risk

(11)

Risk-Based Security Tests

Security Testing

• Two approaches

– Testing security mechanisms to ensure that their functionality is implemented correctly

– Perform risk-based security tests

(12)

Risk-Based Security Tests

How to Approach Security Testing

• Who should do security testing?

– Someone who has experience

– They have to think like an attacker

• How

– White-box testing

• Analyzing and understanding source code and the design

• Very effective at finding programming errors

– Black-box testing

• Analyzing a running program by probing it with various inputs

• If you are able to break the program then there is a security problem

(13)

(14)

Static Analysis for Security

Overview

• Catching implementation bugs early

• Aim for good, not perfect

• Approaches to static analysis

[CM2004]

(15)

Static Analysis for Security

Catching Implementation Bugs Early

• Used to identify common code errors automatically before a program is released

• Static analysis tools

– used to examine the text of a program without attempting to execute it

– Much faster than manual auditing

– Can be applied before the program is completed

(16)

Static Analysis for Security

Aim for Good… Not Perfect

• Static Analysis can’t solve all of the problems

– It only looks for a set of patterns or rules in the code

• Example

– If a rule hasn’t been written yet to find a problem – Then, the tool will never find that problem

• Rice Theorem

– Static analysis problems are undecidable in the worst case

(17)

Static Analysis for Security

Approaches to Static Analysis

• Utility Grep

– Uses a list of good search strings

– But it doesn’t understand anything about the files it scans

• Lexical Analysis tools

– Uses ITS4, FlawFinder, and RATS

• Which do the steps of a compiler

• then match the results against a library

• Abstract Syntax Tree (AST)

– Understand the basic semantics of the program

(18)

Static Analysis for Security

Approaches to Static Analysis

• Local analysis

– One program at a time

– Doesn’t look at relationships between functions

• Module-level analysis

– One class at a time

– Examines relationships between functions – Doesn’t analyze calls between modules

• Global analysis

– Analyzes the entire program

– Looks at all relationships between functions

(19)

Penetration Testing

Overview

• Used to find the real vulnerabilities in the system

• Also known as Ethical Hacking

– You have permission to attack this network

20 November 2015 Software Security Testing

[ASM2005]

19

(20)

Penetration Testing

Penetration Testing Today

• Typically a security consultant will come in and do the testing

• Issues with penetration testing

– Incorrect interpretation of results – Scope of the test is narrow

• thus only finding a small amount of bugs

– Validity of tests

• Tests can’t be repeated thus results can’t be repeated

– Testing at the end of the software development cycle

• Fixing the bugs is costly

(21)

Penetration Testing

A Better Approach

• Use of structured tests based on perceived risks

• Make use of tools

– To vet software code in source or in binary form

• Used to identify implementation-level bugs

– Dynamic Analysis tools to observe a system

• Once the faults are discovered it will report them to the tester

– Benefits of using tools

• Performs most of the grunt work

• The output provided by the tools are very useful

(22)

Penetration Testing

A Better Approach

• Test software at different levels

– Component level testing

• Use static and dynamic analysis tools

• Overall Goal is to

– Misuse the component’s assets

– Violate inter-component assumptions – Probe risks

– Unit level testing

• Benefit of breaking system security down in to several parts

– System level testing

• Analyze the system in its deployed environment

• Identify inter-component issues

• Assessing the security risk inherent at the design level

(23)

Penetration Testing

A Better Approach

• Integrate with the development cycle

– Mitigation strategy

• Finding the bugs

• Exploring how the bugs made it into the code

• Address and identify vulnerabilities in the code base

• Use test results to evaluate progress in fixing bugs

– Iterative security penetration tests should reveal fewer and less severe flaws in the system

(24)

Conclusion

• Risk-based Testing

– Used to solve problems during production

• Static Analysis

– Should be applied regularly as part of the development process

• Penetration Testing

– Most useful when integrated during the development process

– Results can help improve design, implementation, and deployment practices

(25)

References and Further Reading

Software Security Testing 20 November 2015

• [PM2004] Bruce Potter and Gary McGraw, “Software Security

Testing,” IEEE Security and Privacy, Volume 2, Issue 5, pp. 81 – 85, September/October 2004.

• [CM2004] Brian Chess and Gary McGraw, “Static Analysis for

Security,” IEEE Security and Privacy, Volume 2, Issue 6, pp. 76 – 79, November/December 2004.

• [ASM2005] Brad Arkin, Scott Stender, and Gary McGraw, “Software Penetration Testing,” IEEE Security and Privacy, Volume 3, Issue 1, pp.

84 – 87, January/February 2004.

25

(26)